I'm experiencing intermittent failures with OBi100 processing INVITE requests. Time to time it works as it should, while other times it simply doesn't.
I'm making calls via FreeSWITCH. OBi is registered and is getting INVITE requests from it.
Let's begin with how it works (from detailed logs, made by FS):
1. FS sends INVITE request to OBi
2. OBi replies with SIP/2.0 100 Trying
3. OBi replies with SIP/2.0 180 Ringing
...
How it doesn't:
1. FS sends INVITE request to OBi
2. FS sends INVITE request to OBi
3. FS sends INVITE request to OBi
...
In second case there is no any replies received from OBi.
Note:
both calls were made from the same SIP phone in 5 sec between them. First call worked, while second doesn't. In both cases INVITE request, sent by FS to OBi, is almost completely identical (except timestamps and ID's).
Here is example of such INVITE request:
INVITE sip:105@XX.XX.XX.XX:11934 SIP/2.0
Via: SIP/2.0/UDP XX.XX.XX.XX;rport;branch=z9hG4bK34e2Kyj47QeUa
Max-Forwards: 69
From: "phone" <sip:102@domain.tld>;tag=9jytU7X1gK1yK
To: <sip:105@XX.XX.XX.XX:11934>
Call-ID: ac7b23e3-47d5-122f-3b99-dd59b1c756f9
CSeq: 16697887 INVITE
Contact: <sip:mod_sofia@XX.XX.XX.XX:5060>
User-Agent: FreeSWITCH-mod_sofia/1.0.head-git-
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, precondition, path, replaces
Allow-Events: talk, hold, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 413
X-FS-Support: update_display
Remote-Party-ID: "phone" <sip:102@domain.tld>;party=calling;screen=yes;privacy=off
v=0
o=FreeSWITCH 1314043110 1314043111 IN IP4 XX.XX.XX.XX
s=FreeSWITCH
c=IN IP4 XX.XX.XX.XX
t=0 0
m=audio 24792 RTP/AVP 98 99 100 102 9 0 8 3 101 13
a=rtpmap:98 iLBC/8000
a=fmtp:98 mode=30
a=rtpmap:99 iLBC/8000
a=fmtp:99 mode=30
a=rtpmap:100 G7221/32000
a=fmtp:100 bitrate=48000
a=rtpmap:102 G7221/16000
a=fmtp:102 bitrate=32000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:30
What could be wrong with that request, so OBi may just ignore it (in some cases) and / or react to it properly later?
If there is problem with unsupported codec or with double lines of iLBC attributes or anything similar, codec related, I guess OBi should respond with something like "SIP/2.0 488 Not Acceptable Here". And I've seen it some times. But why it may completely ignore INVITE request (actually multiple repeated identical requests sent by FS to OBI one by one) and there is no any reply back from OBi at all???
Here is one more and perhaps related question. Does OBi have any problem with INVITE requests that FS may send (and it does it by default), which has multiple m= lines in SDP? For example:
v=0
o=FreeSWITCH 1314027030 1314027031 IN IP4 XX.XX.XX.XX
s=FreeSWITCH
c=IN IP4 XX.XX.XX.XX
t=0 0
m=audio 19574 RTP/AVP 98 99 101 13
a=rtpmap:98 iLBC/8000
a=fmtp:98 mode=30
a=rtpmap:99 iLBC/8000
a=fmtp:99 mode=30
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:30
m=audio 19574 RTP/AVP 18 100 102 9 0 8 3 101 13
a=rtpmap:100 G7221/32000
a=fmtp:100 bitrate=48000
a=rtpmap:102 G7221/16000
a=fmtp:102 bitrate=32000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
Will it create any trouble for OBi, so it just stop its processing or anything like that?
I could re-configure FS to avoid that if it makes trouble for OBi.
Please note, that the case mentioned in the beginning of this post doesn't use any multiple m= lines. And OBi may still not send any replies to FS anyway...
I guess it is very important, that OBi should send a reply ("SIP/2.0 100 Trying" and "SIP/2.0 180 Ringing" or "SIP/2.0 488 Not Acceptable Here") in any case. Please help with a bug fix or suggestion...
SoftwareVersion 1.2.1 (Build: 2384)
