[Freeswitch-users] no-way audio when accepting a call with iLBC

[Stanislav Kutil]

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 at 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 at 78.80.18.10:10142>;rinstance=018EE99B
Max-Forwards: 69
From: "Extension 1205" <sip:1205 at pbx.acrobits.cz>;tag=43Bm32867KUBS
To: <sip:1203 at 192.168.1.245:4956;rinstance=018EE99B>
Call-ID: 2ec155bb-f612-122f-3292-001a929b68ca
CSeq: 26276632 INVITE
Contact: <sip:mod_sofia at 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 at 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 at 192.168.1.245:4956>
From: "Extension 1205" <sip:1205 at pbx.acrobits.cz>;tag=43Bm32867KUBS
Call-ID: 2ec155bb-f612-122f-3292-001a929b68ca
CSeq: 26276632 INVITE
To: <sip:1203 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20120401/63586541/attachment.html