no-way audio when accepting a call with iLBC
I'm experiencing no-way audio when using iLBC codec with FS. interesting snippet from the dump: we receive this INVITE, note iLBC is included both as payload 98 and payload 102. INVITE sip:1203@192.168.1.245:4956;rinstance=018EE99B SIP/2.0 Via: SIP/2.0/UDP 93.185.48.4;rport;branch=z9hG4bKSvyXBN2p9cZNp Route: <sip:1203@78.80.18.10:10142>;rinstance=018EE99B Max-Forwards: 69 From: "Extension 1205" <sip:1205@pbx.acrobits.cz>;tag=43Bm32867KUBS To: <sip:1203@192.168.1.245:4956;rinstance=018EE99B> Call-ID: 2ec155bb-f612-122f-3292-001a929b68ca CSeq: 26276632 INVITE Contact: <sip:mod_sofia@93.185.48.4:5060> User-Agent: FreeSWITCH-mod_sofia/1.1.beta1-git-a239914 2012-03-26 10-53-39 -0500 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: 486 X-FS-Support: update_display,send_info Remote-Party-ID: "Extension 1205" <sip:1205@pbx.acrobits.cz>;party=calling;screen=yes;privacy=off v=0 o=FreeSWITCH 1333204589 1333204590 IN IP4 93.185.48.4 s=FreeSWITCH c=IN IP4 93.185.48.4 t=0 0 m=audio 20804 RTP/AVP 0 8 9 98 3 99 100 102 101 13 a=rtpmap:98 iLBC/8000 a=fmtp:98 mode=20 a=rtpmap:99 G7221/32000 a=fmtp:99 bitrate=48000 a=rtpmap:100 G7221/16000 a=fmtp:100 bitrate=32000 a=rtpmap:102 iLBC/8000 a=fmtp:102 mode=20 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 m=video 22668 RTP/AVP 34 103 a=rtpmap:34 H263/90000 a=rtpmap:103 H264/90000 we pick 102 version: SIP/2.0 200 OK Via: SIP/2.0/UDP 93.185.48.4;rport=5060;branch=z9hG4bKSvyXBN2p9cZNp;received=93.185.48.4 Contact: <sip:1203@192.168.1.245:4956> From: "Extension 1205" <sip:1205@pbx.acrobits.cz>;tag=43Bm32867KUBS Call-ID: 2ec155bb-f612-122f-3292-001a929b68ca CSeq: 26276632 INVITE To: <sip:1203@192.168.1.245:4956;rinstance=018EE99B>;tag=8466C9086B8AF5AE5586CEC0F3CFB45C Allow: OPTIONS, INVITE, ACK, REFER, CANCEL, BYE, NOTIFY Supported: replaces, path Content-Type: application/sdp Content-Length: 307 v=0 o=- 03870 51862 IN IP4 10.39.33.21 s=tinvgxd c=IN IP4 10.39.33.21 t=0 0 m=audio 51132 RTP/AVP 102 101 a=rtpmap:101 TELEPHONE-EVENT/8000 a=rtpmap:102 ILBC/8000 a=fmtp:101 0-15 a=fmtp:102 mode=20 a=ptime:20 a=sendrecv m=video 0 RTP/AVP 34 103 a=rtpmap:103 H264/90000 a=rtpmap:34 H263/90000 the NAT traversal feature of FS to send audio back to where it is send does not kick in in this case so the iLBC stream from us is ignored by FS and iLBC stream from FS goes to some private IP (we are not on the same private network as FS) 1) as soon as we send a re-INVITE it fixes itself (now only 102 is included) 2) If we declare the correct public IP in the SDP it also works. 3) other codecs work fine So to me the problem can either be the dual payload, or iLBC vs ILBC. I think the latter is correct btw. Thanks, Stan
participants (1)
-
Stanislav Kutil