Bug - with TCP transport configured OBi sends ACK via UDP
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?
Navigation
[0] Message Index
[#] Next page
[*] Previous page