18 Aug
2006
18 Aug
'06
3:37 a.m.
Hello all.
I've been doing some experimentation with both CVS HEAD and 0.9.6 of
SER and version 1.1.0 of OpenSER.
It appears that there is a TCP bug in SER which has been fixed in
OpenSER. I've seen various posts in the past on the serdev and the
serusers lists regarding this issue but with no definitive solution.
Are there any plans to merge some of the great work of the OpenSER
developers back into SER, such as this fix for TCP?
Below is the logfile I receive when I try to place a call from a UDP
to a TCP device using CVS HEAD of SER. The same routing logic in
ser.cfg works perfectly in openser.cfg.
Aug 17 19:03:33 testbox /usr/sbin/ser[32534]: ERROR:
tcp_blocking_connect: poll error: flags 18
Aug 17 19:03:33 testbox /usr/sbin/ser[32534]: ERROR:
tcp_blocking_connect: SO_ERROR (113) No route to host
Aug 17 19:03:33 testbox /usr/sbin/ser[32534]: ERROR: tcpconn_connect:
tcp_blocking_connect failed
Aug 17 19:03:33 testbox /usr/sbin/ser[32534]: ERROR: tcp_send: connect failed
Aug 17 19:03:33 testbox /usr/sbin/ser[32534]: msg_send: ERROR: tcp_send failed
Aug 17 19:03:33 testbox /usr/sbin/ser[32534]: ERROR: t_forward_nonack:
sending request failed
Aug 17 19:03:33 sg1test /usr/sbin/ser[32534]: ERROR: sl_reply_error
used: Unfortunately error on sending to next hop occurred (477/SL)
Does anyone have any ideas on how to get this fixed in CVS HEAD of
SER? I've tried some backporting of the changes to the tcp_* files
from OpenSER to SER but have not had any luck as of yet as I'm not
fully sure of how the code is supposed to be handling each case. This
is to say that I'm just looking at code differences without really
understanding how the code is supposed to work.
I'm happy to do anything I can to help get this resolved in SER's CVS HEAD.
Thanks!
-Curt
19 Aug
19 Aug
2:45 p.m.
On Aug 17, 2006 at 19:37, Curt Moore <tgrman21(a)gmail.com> wrote:
Hello all.
I've been doing some experimentation with both CVS HEAD and 0.9.6 of
SER and version 1.1.0 of OpenSER.
It appears that there is a TCP bug in SER which has been fixed in
OpenSER. I've seen various posts in the past on the serdev and the
serusers lists regarding this issue but with no definitive solution.
Are there any plans to merge some of the great work of the OpenSER
developers back into SER, such as this fix for TCP?
The great work in openser tcp is just applying selective patches from
ser. Looking through the cvs log there are only 2 small changes that do not
come from ser: bind before connect (with debatable usefulness, you can
make a case for it or against it and I am on the "against" side) and the
possibility to set the timers individually for each tcp connection (they
claim it helps for nat traversal and usrloc (?)).
Disclaimer: I do not want to imply that openser developer do not do
great work :-) It just happens that tcp is the wrong example, since
99.9999% from the code is from ser.
Below is the logfile I receive when I try to place a call from a UDP
to a TCP device using CVS HEAD of SER. The same routing logic in
ser.cfg works perfectly in openser.cfg.
Aug 17 19:03:33 testbox /usr/sbin/ser[32534]: ERROR:
tcp_blocking_connect: poll error: flags 18
Aug 17 19:03:33 testbox /usr/sbin/ser[32534]: ERROR:
tcp_blocking_connect: SO_ERROR (113) No route to host
Aug 17 19:03:33 testbox /usr/sbin/ser[32534]: ERROR: tcpconn_connect:
tcp_blocking_connect failed
Aug 17 19:03:33 testbox /usr/sbin/ser[32534]: ERROR: tcp_send: connect
failed
Aug 17 19:03:33 testbox /usr/sbin/ser[32534]: msg_send: ERROR: tcp_send
failed
Aug 17 19:03:33 testbox /usr/sbin/ser[32534]: ERROR: t_forward_nonack:
sending request failed
Aug 17 19:03:33 sg1test /usr/sbin/ser[32534]: ERROR: sl_reply_error
used: Unfortunately error on sending to next hop occurred (477/SL)
This looks like a tcp connect error and not like a ser bug.
Are you sure the ip routing is properly set on your host?
Are you sure this is not the other way arround (openser binds on an
interface before connecting and that's how you could get this error, ser
on the other hand doesn't do this, so it should work in all the cases)?
Could you send me ser.cfg and a detailed description on what exactly are
you doing when you get this error (so that I can reproduce it myself)?
The whole ser log, a packet dump (both tcp and udp) and the outputs of
/sbin/ifconfig and /sbin/route will also help.
Does anyone have any ideas on how to get this fixed in CVS HEAD of
SER? I've tried some backporting of the changes to the tcp_* files
from OpenSER to SER but have not had any luck as of yet as I'm not
fully sure of how the code is supposed to be handling each case. This
is to say that I'm just looking at code differences without really
understanding how the code is supposed to work.
I'm happy to do anything I can to help get this resolved in SER's CVS HEAD.
Thanks,
Andrei
21 Aug
21 Aug
1:21 p.m.
Andrei Pelinescu-Onciul wrote:
...
ser. Looking through the cvs log there are only 2
small changes that do not
come from ser: bind before connect (with debatable usefulness, you can
make a case for it or against it and I am on the "against" side) and the
Hi Andrei!
What is the case against it? IIRC this was necessary to use a certain
local IP address for outgoing TCP connections. (Which is a MUST in
certain firewall scenarios).
regards
Klaus
8:28 p.m.
On 8/19/06, Andrei Pelinescu-Onciul <andrei(a)iptel.org> wrote:
This could explain what's going on. The server does have 2 interfaces
but I'm only binding to 1 of the IP addresses, which happens to be a
virtual IP address on the interface, if that matters. On that IP I'm
using both TCP and UDP on port 5060.
On Aug 17, 2006 at 19:37, Curt Moore
<tgrman21(a)gmail.com> wrote:
I did not want that to sound like I meant that the SER developers are
not also doing a great job. :-)
Hello all.
I've been doing some experimentation with both CVS HEAD and 0.9.6 of
SER and version 1.1.0 of OpenSER.
It appears that there is a TCP bug in SER which has been fixed in
OpenSER. I've seen various posts in the past on the serdev and the
serusers lists regarding this issue but with no definitive solution.
Are there any plans to merge some of the great work of the OpenSER
developers back into SER, such as this fix for TCP?
The great work in openser tcp is just applying selective patches from
ser. Looking through the cvs log there are only 2 small changes that do not
come from ser: bind before connect (with debatable usefulness, you can
make a case for it or against it and I am on the "against" side) and the
possibility to set the timers individually for each tcp connection (they
claim it helps for nat traversal and usrloc (?)).
Disclaimer: I do not want to imply that openser developer do not do
great work :-) It just happens that tcp is the wrong example, since
99.9999% from the code is from ser.
Below is the logfile I receive when I try to place a call from a UDP
to a TCP device using CVS HEAD of SER. The same routing logic in
ser.cfg works perfectly in openser.cfg.
Aug 17 19:03:33 testbox /usr/sbin/ser[32534]: ERROR:
tcp_blocking_connect: poll error: flags 18
Aug 17 19:03:33 testbox /usr/sbin/ser[32534]: ERROR:
tcp_blocking_connect: SO_ERROR (113) No route to host
Aug 17 19:03:33 testbox /usr/sbin/ser[32534]: ERROR: tcpconn_connect:
tcp_blocking_connect failed
Aug 17 19:03:33 testbox /usr/sbin/ser[32534]: ERROR: tcp_send: connect
failed
Aug 17 19:03:33 testbox /usr/sbin/ser[32534]: msg_send: ERROR: tcp_send
failed
Aug 17 19:03:33 testbox /usr/sbin/ser[32534]: ERROR: t_forward_nonack:
sending request failed
Aug 17 19:03:33 sg1test /usr/sbin/ser[32534]: ERROR: sl_reply_error
used: Unfortunately error on sending to next hop occurred (477/SL)
This looks like a tcp connect error and not like a ser bug.
Are you sure the ip routing is properly set on your host?
Are you sure this is not the other way arround (openser binds on an
interface before connecting and that's how you could get this error, ser
on the other hand doesn't do this, so it should work in all the cases)?
Could you send me ser.cfg and a detailed description on what exactly are
you doing when you get this error (so that I can reproduce it myself)?
The whole ser log, a packet dump (both tcp and udp) and the outputs of
/sbin/ifconfig and /sbin/route will also help.
My setup is a SER server acting as a UDP/TCP SIP proxy, which relays
SIP messages, via dispatcher, to a farm of Asterisk servers using SIP
UDP. If a TCP UA sends a message to SER, it will correctly forward it
using UDP to one of the Asterisk servers. The problem arises whenever
Asterisk sends a SIP UDP message back to SER for forwarding to the TCP
UA. The problem is that upon trying to relay the TCP message, SER will
produce the TCP errors described above. It sounds like the binding
issue you described above.
I'll send the debug info off-list.
Thanks for your help.
-Curt
6671
days inactive
6674
days old
3 comments
3 participants
participants (3)
-
Andrei Pelinescu-Onciul -
Curt Moore -
Klaus Darilion