Open a jira for it so that the bug can be registered and tracked. http://jira.freeswitch.org/ -Steve On 26 April 2011 15:16, Jyotshna Cherukuri <jcherukuri_necc@yahoo.com>wrote:
Hi ,
I am working with the latest revision of Freeswitch and I am having one way audio problem using SILK/8000 codec on B-leg of the call after Session Refresh or on HOLD. This is due to the fact that when FS sends an INVITE out to B-leg it sends 98 in its SDP offer and B-leg responds back with same code but with payload type "120"
[ Offer ] v=0 o=FreeSWITCH 1303773966 1303773967 IN IP4 192.168.2.10 s=FreeSWITCH c=IN IP4 192.168.2.10 t=0 0 m=audio 33766 RTP/AVP 98 9 101 a=rtpmap:98 SILK/8000 a=fmtp:98 useinbandfec=1;usedtx=0 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - a=ptime:20
[ Answer ]
v=0 o=- 3512815772 3512815773 IN IP4 192.168.4.121 s=pjmedia c=IN IP4 192.168.4.121 t=0 0 a=X-nat:0 m=audio 4002 RTP/AVP 120 96 a=rtcp:4003 IN IP4 192.168.4.121 a=rtpmap:120 silk/8000 a=fmtp:120 useinbandfec=1;usedtx=0 a=sendrecv a=rtpmap:96 telephone-event/8000 a=fmtp:96 0-15
Freeswitch handles this properly on the initial offer/answer as its using this patch (tell rtp stack about what remote payload type to expect when the receiving end follows the stupid SHOULD as WONT and sends a different dynamic payload number than the one in the offer)
After one min into the call because Session Timers are enabled Freeswitch sends a Session Refresh with payload type now setting to "120"
[Refresh Offer] v=0 o=FreeSWITCH 1303773966 1303773967 IN IP4 192.168.2.10 s=FreeSWITCH c=IN IP4 192.168.2.10 t=0 0 m=audio 33766 RTP/AVP 120 96 9 a=rtpmap:120 SILK/8000 a=fmtp:120 useinbandfec=1;usedtx=0 a=rtpmap:96 telephone-event/8000 a=fmtp:96 0-16 a=silenceSupp:off - - - - a=ptime:20
The remote end then starts sending RTP packets with payload number "120" in its RTP header and FS stops processing these packets and as a result is resulting in one-way audio issue.
Any help is appreciated.
Thanks in advance Regards Jyotshna
P.S : The issue starts even when the remote end presses" HOLD" as it sends INVITE on hold with "120" and FS responds back with "120" in its answer.
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org