Bug - with TCP transport configured OBi sends ACK via UDP
hwittenb:
I ran additional tests. I ran a test with an outbound call thru voip provider callwithus and also an outbound call with pbxes. I monitored the packets with WireShark. In both tests the call completed OK and was not cut off.
On the test with callwithus the ACK to the Sip 200 OK after the call was answered was sent via udp. In my test the voip provider accepted the ACK as normal signalling and it didn't affect the call. Other signalling was via tcp.
I did a further test with an outbound call to PBXes and the OBi sent an ACK using tcp after receiving the Sip 200 from PBXes after the call was answered. I was using the same SP2 configuration except for the proxy/userid setup. I'm not sure of why in one case the OBi ACK responding to the Sip 200 OK with udp and the other case with tcp.
OZOi:
@hwittenb, thank you for making those tests.
Some SIP servers may accept sudden transport switch from TCP to UDP and back. Others - don't and they cut the call off as a result. And I can't blame them. They have negotiated with OBi to use TCP and expect it to be used since that...
Why in the hell OBi sends that ACK via UDP channel?
It's a bug and it must be fixed.
hwittenb:
Quote from: OZOi on March 20, 2013, 11:55:51 am
Why in the hell OBi sends that ACK via UDP channel?
It appears to me that in my test the difference between the OBi110 sending the ACK response to the Sip 200 via udp in the CallCentric case and via tcp in the PBXes case was due to the Contact: uri in the Sip 200 Header sent by the server.
In the CallCentric case the Contact: said
<sip:.............;transport=udp>
and in the PBXes case the Contact: said
<sip:................;transport=tcp>
In the log posted (by OZOi) however the Sip 200 OK Contact does say Contact: <sip: ....;transport=tcp> so that doesn't explain why the OBi responded using udp to the FreeSwitch server.
OZOi:
Yes, indeed. Contact explicitly says <sip: ....;transport=tcp>
It's not only wrong, but it may simply do not work in cases, including:
* there is no UDP:5060 port opened on SIP server
* Without keep-alive packets NAT hole in the router could be closed for unexpected UDP packet, coming from OBi.
etc.
paul_c:
I'm seeing a similar problem, I wonder if there has been a resolution to this yet.?
Navigation
[0] Message Index
[*] Previous page