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:
Quote from: OZOi on July 30, 2012, 01:04:17 pm
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.
Navigation
[0] Message Index
[#] Next page