Bug - with TCP transport configured OBi sends ACK via UDP

[OZOi]

Trying to use TCP transport with OBi and I'm getting the weird problem.

I make call from OBi. After call is accepted by receiver, SIP server sends OK/INVITE message to OBi. Everything is fine up to this poing. But now OBi sends ACK message back to SIP server using UDP (and not TCP !!!) channel (different port, different transport). After 30 sec of multiple attempts of SIP server to get via TCP channel mandatory ACK reply from OBi, it finally drops the call by sending BYE to both legs of the call...

How to fix the problem?

OBi100, fw: v1-3-0.2711.

[Ostracus]

Hmmm, wonder if "ProxyServerTransport" may be the issue?

[OZOi]

To use TCP transport you have to go to Service Providers | ITSP Profile A | SIP and set ProxyServerTransport to TCP. Then OBi starts using TCP connection for almost every messages, it sends/receives. But when it receives incoming calls it sends required ACK message back to SIP sever using UDP channel. Why is that? That creates the problem - without receiving the ACK message SIP server could terminate the call (in my case, it always does it after 30 sec).

My guess is - if you try TLS transport (similar to TCP), it probably will exhibit similar behaviur too...

BTW, how to check what particular transport is currently used? There is no any indication of it in Status | System Status page. It'd be nice, if OBi could put corresponding status (e.g. udp | tcp | tls) in Status string within SP1 Service Status...

[pc44]

BTW, how to check what particular transport is currently used? There is no any indication of it in Status | System Status page. It'd be nice, if OBi could put corresponding status (e.g. udp | tcp | tls) in Status string within SP1 Service Status...

OZOi,

If you check the Status -> Call Status during the call, the RTP Transport protocol is specified there.  This is on the Call Status page, not the System Status page.  When placing a test call just now via GV, the OBI's Call Status indicated UDP transport for my call.

Hope it helps,
pc44

[OZOi]

pc44, thank you for reply.

Yes, indeed "Call Status" page shows "RTP Transport", used during the active call. But in this thread I'm not talking about RTP transport. It's all about SIP transport (configured via "ProxyServerTransport" option). If TCP transport is configured, all SIP communications (messages like REGISTER, INVITE, OK/INVITE, ACK, etc) should be sent via TCP channel (not via UDP). And because it's SIP related, it'd be logical to see transport type on the "System Status" page for each of SIP services. For example they could display this string:
"Registered (server=IP.ADD.RES.SRV:5060; expire in 513s, transport=tcp)"

But the most important thing - if I set SIP transport to TCP, all outgoing calls are terminated in 30 sec after accepting the call. It's because OBi100 suddenly sends required ACK message via UDP, while it's configured to use TCP transport...

Do you see that problem?

To check it:
1. Go to Service Providers | ITSP Profile A/B | SIP and set ProxyServerTransport to TCP.
2. Make outbound call
3. Watch for ACK message, that OBi100 sends to SIP server (now it goes via UDP, not TCP)
4. Call is terminated by SIP server, because it doesn't get ACK message as required response to OK/INVITE.

Of cause the action in p.4 may depend of how the particular SIP server reacts on missing ACK messages. In my case it drops the call after 30 sec, making it impractical to use OBi100 for any outbound calls.

[QBZappy]

OZOi,

Totally a shot in the dark, further down that screen you have referenced there seems to be some control that may or may not be connected to that switch. Experiment with this. Those settings are not clear.

X_ProxyRequire (comma separated list of proxy-require options) <- Try TCP

If this parameter is not blank, OBi will include a Proxy-Require header stating the value of this parameter in all SIP requests sent to the ITSP (OBi guide)

[OZOi]

QBZappy - thank you for suggestion.

I'm I bit confused here. How it could fix OBi100 problem and particularly force it to send ACK message via TCP? But I'm desparate and tried it anyway

In Service Providers | ITSP Profile A/B | SIP page I've set:
"X_ProxyRequire"="tcp" (if that's what you've meant)
and got this result (log from SIP server side):
-------------------------------------------------------------------------------
send 1193 bytes to tcp/[IP.ADD.RES.OBI]:24047 at 21:02:50.909390:
   SIP/2.0 200 OK
   CSeq: 8002 INVITE

recv 612 bytes from udp/[IP.ADD.RES.OBI]:18097 at 21:02:50.919405:
   ACK sip:1002@IP.ADD.RES.SIP:5060;transport=tcp SIP/2.0
   CSeq: 8002 ACK
   User-Agent: OBIHAI/OBi100-1.3.0.2711
   Proxy-Require: tcp
-------------------------------------------------------------------------------
As we see the ACK reply now contains "Proxy-Require: tcp" string, additionally to its normal set of common fields. But it did not change the fact, that ACK reply is sent via UDP, and not via TCP (note the "tcp" in "send" and "udp" in "recv" lines as well as different ports used - 24047 and 18097).

But again, I'm still open for any other ideas, that will fix the problem

[Ostracus]

Assuming you can't get Obihai to make whatever changes are needed, you can always run OpenSER on  something like a computer or router.

[OZOi]

I sincerely hope that they just will fix the bug

[rogera_bit]

Has newer firmware addressed/fixed this bug? 

[hwittenb]

Has newer firmware addressed/fixed this bug? 

It appears to be the case.  There is some mention of TCP in the Enhancements & Fixes in Maintenance Release information in this forum.  On my OBi110 I changed my SP2 ProxyServerTransport to TCP and monitored a call with syslog and Wireshark.  All the sip signalling is done with TCP including the ACK's and the call does not drop.

[OZOi]

I've just tried to use TCP with OBi100, running the latest firmware 1.3.0 (Build: 2774). And I see, that the problem is not fixed at all. Outbound call is dropped in 30 sec after it's answered.

I watch log in SIP server console (FreeSWITCH, latest build) and see, that when call is answered, INVITE/200 OK message goes via TCP to OBi100 device (confirming that the call has been answered). But OBi replies back ACK message via UDP. Those conversations continue for next 30 sec until finally the call is closed by SIP server (reason - there is no ACK received from OBi100 via TCP).

[QBZappy]

OZOi,

Is
ITSP Profile A
    General
    SIP->ProxyServerTransport <-set to TCP?

[OZOi]

And here is the log, collected from FreeSWITCH console:
-------------------------------------------------------------------------------
send 1295 bytes to tcp/[IP.ADR.WAN.OBI]:29529 at 22:06:04.579657:
  ------------------------------------------------------------------------
  SIP/2.0 200 OK
  Via: SIP/2.0/TCP IP.ADR.LAN.FS:4276;branch=z9hG4bK-5e08f5b0;rport=29529;received=IP.ADR.WAN.OBI
  From: "OBi SP1" <sip:2005@domain.tld>;tag=SP13bdf1fbd4cf1dec5
  To: <sip:2001@domain.tld>;tag=064Ka82rNDp4N
  Call-ID: 64ddfbe7@IP.ADR.LAN.FS
  CSeq: 8002 INVITE
  Contact: <sip:2001@IP.ADR.WAN.FS:5070;transport=tcp>
  User-Agent: FreeSWITCH-mod_sofia/1.3.17+git~20130310T201453Z~05895faa77
  Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
  Supported: timer, precondition, path, replaces
  Allow-Events: talk, hold, conference, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer
  Session-Expires: 120;refresher=uas
  Min-SE: 120
  Content-Type: application/sdp
  Content-Disposition: session
  Content-Length: 365
  Remote-Party-ID: "Outbound Call" <sip:2001@domain.tld>;party=calling;privacy=off;screen=no

  v=0
  o=- 3572719548 3572719549 IN IP4 IP.ADR.WAN.CSS
  s=pjmedia
  c=IN IP4 IP.ADR.WAN.CSS
  t=0 0
  m=audio 4014 RTP/AVP 18 101
  c=IN IP4 IP.ADR.WAN.CSS
  a=rtpmap:18 G729/8000
  a=fmtp:18 annexb=no
  a=rtpmap:101 telephone-event/8000
  a=fmtp:101 0-15
  a=rtcp:4015 IN IP4 IP.ADR.WAN.CSS
  a=zrtp-hash:1.10 1700947ed37d7a37c3c94a83da6b441a80d77dccea7fcc0c113a8d6f72d2aa7f
  ------------------------------------------------------------------------
recv 593 bytes from udp/[IP.ADR.WAN.OBI]:10135 at 22:06:04.609702:
  ------------------------------------------------------------------------
  ACK sip:2001@IP.ADR.WAN.FS:5070;transport=tcp SIP/2.0
  Call-ID: 64ddfbe7@IP.ADR.LAN.FS
  Content-Length: 0
  CSeq: 8002 ACK
  From: "OBi SP1" <sip:2005@domain.tld>;tag=SP13bdf1fbd4cf1dec5
  Max-Forwards: 70
  To: <sip:2001@domain.tld>;tag=064Ka82rNDp4N
  Via: SIP/2.0/TCP IP.ADR.LAN.FS:4276;branch=z9hG4bK-1b6f07d6;rport
  Proxy-Authorization: DIGEST algorithm=MD5,nc=00000001,qop=auth,cnonce="7cbd1fe1110ec270",nonce="a3f6eae2-364f-42d6-974e-9cc2171e5524",realm="domain.tld",response="2689629580d2ff2dd34b031294a16e57",uri="sip:2001@domain.tld:5070",username="2005"
  User-Agent: OBIHAI/OBi100-1.3.0.2774
-------------------------------------------------------------------------------
In the log I've replaced:
IP.ADR.WAN.OBI
IP.ADR.WAN.FS
IP.ADR.WAN.CSS
IP.ADR.LAN.FS
domain.tld
The rest, including port numbers, transport etc. is untouched.

As you can see SIP server sends INVITE/200 OK via TCP transport, while OBi replies ACK via UDP, braking call in next 30 sec.

[OZOi]

@QBZappy, the answer is - yes.

Service Providers | ITSP Profile A | SIP | ProxyServerTransport is set to TCP (default is 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]

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.?