[Spce-user] ngcp-sems sendto error

[Julian Seifert]

Hi everybody,

We are fairly new to sipwise so please excuse if we are doing some obvious mistake here.
We were already playing with earlier versions of sipwise-ce in our lab environment
for quite some time now and today we just tried to give 3.8.2 a chance. 

We are using the vmware image and its quite vanilla. We simply configured static
network settings changed some passwords (all following the documentation)

We added contacts,contracts etc. and our SIP-Peer we use in our lab environment
for outgoing/incoming call handoff.

For that we entered the necessary (including authentication) data via the webinterface
and, still following the handbook here and applied the settings(user,domain,pwd) manually to the 
template file. (/etc/ngcp-config/templates/etc/ngcp-sems/etc/reg_agent.conf.tt2)

We finalized the setup by running ngcpcfg apply. 
Peering relationship did not establish. 


We confirmed if ngcp-sems was running and binding to sockets etc.:

root at spce:~# ps auxw |grep -ie ngcp-sems 
sems      4390  1.0  0.1 220936 14880 ?        Sl   Jul07  18:33 /usr/sbin/ngcp-sems -P /var/run/ngcp-sems/ngcp-sems.pid -u sems -g sems -f /etc/ngcp-sems/sems.conf
root     12470  0.0  0.0   9848  1920 pts/0    S+   23:32   0:00 grep -ie ngcp-sems
root at spce:~# netstat -anp | grep -ie sems
tcp        0      0 127.0.0.1:5080          0.0.0.0:*               LISTEN      4390/ngcp-sems  
tcp        0      0 127.0.0.1:8090          0.0.0.0:*               LISTEN      4390/ngcp-sems  
udp        0      0 127.0.0.1:5040          0.0.0.0:*                           4390/ngcp-sems  
udp        0      0 127.0.0.1:5080          0.0.0.0:*                           4390/ngcp-sems  
unix  3      [ ]         STREAM     VERBUNDEN     14690    4390/ngcp-sems    
(couple of more unix streams)


As we investigated we found the following message in /var/log/ngcp/sems.log

root at spce:~# tail -n 10 /var/log/ngcp/sems.log 

Jul  8 23:31:39 spce ngcp-sems[4390]: [#7f714da50700] [sendto, udp_trsp.cpp:179] ERROR:  sendto(11;212.X.X.X:5060): Invalid argument
Jul  8 23:31:39 spce ngcp-sems[4390]: [#7f714da50700] [send_request, trans_layer.cpp:1308] ERROR:  Error from transport layer
Jul  8 23:31:49 spce ngcp-sems[4390]: [#7f714da50700] [sendto, udp_trsp.cpp:179] ERROR:  sendto(11;212.X.X.X:5060): Invalid argument
Jul  8 23:31:49 spce ngcp-sems[4390]: [#7f714da50700] [send_request, trans_layer.cpp:1308] ERROR:  Error from transport layer
Jul  8 23:31:59 spce ngcp-sems[4390]: [#7f714da50700] [sendto, udp_trsp.cpp:179] ERROR:  sendto(11;212.X.X.X:5060): Invalid argument
Jul  8 23:31:59 spce ngcp-sems[4390]: [#7f714da50700] [send_request, trans_layer.cpp:1308] ERROR:  Error from transport layer
Jul  8 23:32:09 spce ngcp-sems[4390]: [#7f714da50700] [sendto, udp_trsp.cpp:179] ERROR:  sendto(11;212.X.X.X:5060): Invalid argument
Jul  8 23:32:09 spce ngcp-sems[4390]: [#7f714da50700] [send_request, trans_layer.cpp:1308] ERROR:  Error from transport layer
Jul  8 23:32:19 spce ngcp-sems[4390]: [#7f714da50700] [sendto, udp_trsp.cpp:179] ERROR:  sendto(11;212.X.X.X:5060): Invalid argument
Jul  8 23:32:19 spce ngcp-sems[4390]: [#7f714da50700] [send_request, trans_layer.cpp:1308] ERROR:  Error from transport layer

we then proceeded to analyze the situation via strace to look why the sendto call fails.

root at spce:~# killall -9 ngcp-sems
root at spce:~# !ps
ps auxw |grep -ie ngcp-sems 
root     12596  0.0  0.0   9844  1968 pts/0    S+   23:32   0:00 grep -ie ngcp-sems
root at spce:~# strace -o /tmp/ngcp-sems.trace -ff /usr/sbin/ngcp-sems -P /var/run/ngcp-sems/ngcp-sems.pid -u sems -g sems -f /etc/ngcp-sems/sems.conf
Configuration:
       log level:           INFO (2)
       log to stderr:       no
       configuration file:  /etc/ngcp-sems/sems.conf
       plug-in path:        /usr/lib/ngcp-sems/plug-in/
       daemon mode:         yes
       daemon UID:          sems
       daemon GID:          sems
       application:         $(apphdr)


Looking through the traces we found the following information:
root at spce:/tmp# grep -ie "send.*= -1" *trace*
ngcp-sems.trace.12864:sendto(11, "REGISTER sip:sip.easybell.de SIP"..., 429, 0, {sa_family=AF_INET, sin_port=htons(5060), sin_addr=inet_addr("212.X.X.X")}, 16) = -1 EINVAL (Invalid argument)
ngcp-sems.trace.12864:sendto(11, "REGISTER sip:sip.easybell.de SIP"..., 429, 0, {sa_family=AF_INET, sin_port=htons(5060), sin_addr=inet_addr("212.X.X.X")}, 16) = -1 EINVAL (Invalid argument)
root at spce:/tmp# grep -ie "socket.*= 11" *trace*
ngcp-sems.trace.12856:socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 11
root at spce:/tmp# grep -ie "bind.11.*" *trace*
ngcp-sems.trace.12856:bind(11, {sa_family=AF_INET, sin_port=htons(5080), sin_addr=inet_addr("127.0.0.1")}, 16) = 0

It actually looks as if ngcp-sems was binding the socket it uses for outgoing communication to source address 127.0.0.1

root at spce:/tmp# cat /etc/ngcp-sems/sems.conf | grep -ie 127
sip_ip=127.0.0.1

seems to confirm this. 
So SHOULD this actually be 127.0.0.1 or should we simply add our external address?
Should ngcp-sems connect to kamailio(using it as proxy?) instead of our SIP-Peer directly? (which is what it apparently tries?)

maybe you guys can give us a hint what we are doing wrong/how we can fix it.

kind regards,

  Julian