No audio on caller side when both side support speex/8000 only
Hi, Owe to the network bandwidth limitations (running on cellular phones ip link) we are using speex/8000 as our voice codec. However, when both parties are using that codec the sound is not to be heard on the caller side. looking at the log dumps one can see that a) at the caller side, it supports speex/8000 in pt=102 and receives from the server speex/8000 in pt=102 b) at the callee side FreeSwitch supports support speex/8000 in pt=98 although it receives from the client speex/8000 in pt=102 When the voice starts caller sends RTP with pt=102 and expect to receive RTP with pt=102, while the callee sends RTP with pt=98 and expect to receive RTP with pt=102. The RTP packets that received in the caller side are with pt=98 instead of 102 and thusly the client drops them. Attached are the 2 files recorded from a call between 2 pjsip clients that support only speex/8000 codec. un_FSCallerSide-speexClient.TXT – is the caller side SIP messages. un_FSAnswerSide-speexClient.TXT – is the answer side of SIP messages. Is there anything can be done at the configuration level to avoid this? Thanks in advance for your help /tzury
Hi, Owe to the network bandwidth limitations (running on cellular phones ip link) we are using speex/8000 as our voice codec. However, when both parties are using that codec the sound is not to be heard on the caller side. looking at the log dumps one can see that a) at the caller side, it supports speex/8000 in pt=102 and receives from the server speex/8000 in pt=102 b) at the callee side FreeSwitch supports support speex/8000 in pt=98 although it receives from the client speex/8000 in pt=102 When the voice starts caller sends RTP with pt=102 and expect to receive RTP with pt=102, while the callee sends RTP with pt=98 and expect to receive RTP with pt=102. The RTP packets that received in the caller side are with pt=98 instead of 102 and thusly the client drops them. ############### LOG DUMPS ############### ############### CALLER SIDE ## start msg (TX) INVITE sip:1002@SERVER_DOMAIN SIP/2.0 Via: SIP/2.0/UDP X.X.X.X:64680;rport;branch=z9hG4bKPj3caad40720064a8f124c21cf99b8b1c1 Max-Forwards: 70 From: sip:1001@SERVER_DOMAIN;tag=6d6ef114e663e48226f2b1e598313a2e To: sip:1002@SERVER_DOMAIN Contact: <sip:1001@X.X.X.X:64680> Call-ID: 1473e9e828658e3fb0370fabf2ce8986 CSeq: 23264 INVITE Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS Supported: replaces, 100rel, timer, norefersub Session-Expires: 1800 Min-SE: 90 Content-Type: application/sdp Content-Length: 264 v=0 o=- 3461521040 3461521040 IN IP4 X.X.X.X s=pjmedia c=IN IP4 X.X.X.X t=0 0 a=X-nat:8 m=audio 64976 RTP/AVP 102 101 a=rtcp:64980 IN IP4 X.X.X.X a=rtpmap:102 speex/8000 a=sendrecv a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 --end msg-- ## start msg (RX) SIP/2.0 200 OK Via: SIP/2.0/UDP 10.171.9.67:5060;rport=64680;branch=z9hG4bKPje8deea3c8476457603fe0cc301731002 From: <sip:1001@SERVER_DOMAIN>;tag=6d6ef114e663e48226f2b1e598313a2e To: <sip:1002@SERVER_DOMAIN>;tag=06ym4113FFcHQ Call-ID: 1473e9e828658e3fb0370fabf2ce8986 CSeq: 23265 INVITE Contact: <sip:mod_sofia@X.X.X.X:5060;transport=udp> User-Agent: FreeSWITCH-mod_sofia/1.0.3-exported Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE, REGISTER, INFO, PUBLISH Require: timer Supported: timer, precondition, path, replaces Allow-Events: talk, presence, dialog, call-info, sla, include-session-description, presence.winfo, message-summary, refer Session-Expires: 1800;refresher=uac Min-SE: 120 Content-Type: application/sdp Content-Disposition: session Content-Length: 268 v=0 o=FreeSWITCH 4446028933093139022 3405868075899860026 IN IP4 X.X.X.X s=FreeSWITCH c=IN IP4 X.X.X.X t=0 0 m=audio 26664 RTP/AVP 102 101 a=rtpmap:102 speex/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - a=ptime:20 --end msg-- ############### CALLEE SIDE ## start msg (RX) INVITE sip:1002@X.X.X.X:5060 SIP/2.0 Via: SIP/2.0/UDP X.X.X.X;rport;branch=z9hG4bKgvD702De7e0Se Max-Forwards: 69 From: "Extension 1001" <sip:1001@X.X.X.X>;tag=2rH67Q3aa1rpe To: <sip:1002@X.X.X.X:5060> Call-ID: e56c2918-17ad-122d-de9e-40402384297d CSeq: 120120747 INVITE Contact: <sip:mod_sofia@X.X.X.X:5060> User-Agent: FreeSWITCH-mod_sofia/1.0.3-exported Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE, REGISTER, INFO, PUBLISH Supported: timer, precondition, path, replaces Allow-Events: talk, presence, dialog, call-info, sla, include-session-description, presence.winfo, message-summary, refer Content-Type: application/sdp Content-Disposition: session Content-Length: 415 Remote-Party-ID: "Extension 1001" <sip:1001@X.X.X.X>;screen=yes;privacy=off v=0 o=FreeSWITCH 4131815555116427886 953315150658749217 IN IP4 X.X.X.X s=FreeSWITCH c=IN IP4 X.X.X.X t=0 0 m=audio 26662 RTP/AVP 98 0 8 3 9 99 103 101 13 a=rtpmap:98 SPEEX/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:3 GSM/8000 a=rtpmap:9 G722/8000 a=rtpmap:99 SPEEX/16000 a=rtpmap:103 SPEEX/32000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtpmap:13 CN/8000 a=ptime:20 --end msg-- ## start msg (TX) SIP/2.0 200 OK Via: SIP/2.0/UDP X.X.X.X;rport=5060;received=X.X.X.X;branch=z9hG4bKgvD702De7e0Se Call-ID: e56c2918-17ad-122d-de9e-40402384297d From: "Extension 1001" <sip:1001@X.X.X.X>;tag=2rH67Q3aa1rpe To: <sip:1002@X.X.X.X>;tag=e4f9fb648edef1c48dbc8b8b474409e6 CSeq: 120120747 INVITE Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS Contact: <sip:X.X.X.X:5060> Supported: replaces, 100rel, timer, norefersub Content-Type: application/sdp Content-Length: 256 v=0 o=- 3461503025 3461503026 IN IP4 X.X.X.X s=pjmedia c=IN IP4 X.X.X.X t=0 0 a=X-nat:5 m=audio 4000 RTP/AVP 102 101 a=rtcp:4001 IN IP4 X.X.X.X a=rtpmap:102 speex/8000 a=sendrecv a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 --end msg-- Attached are the 2 files recorded from a call between 2 pjsip clients that support only speex/8000 codec. un_FSCallerSide-speexClient.TXT – is the caller side SIP messages. un_FSAnswerSide-speexClient.TXT – is the answer side of SIP messages. Is there anything can be done at the configuration level to avoid this? Thanks in advance for your help /tzury
This looks and sounds like a case where pjsip isn't listening to our SDP. If we 200 OK with speex on 102 and the far end starts sending it on 98 then I suspect the client is broken if I'm not mistaken. /b On Sep 9, 2009, at 6:19 AM, Tzury Bar Yochay wrote:
Hi,
Owe to the network bandwidth limitations (running on cellular phones ip link) we are using speex/8000 as our voice codec.
However, when both parties are using that codec the sound is not to be heard on the caller side.
looking at the log dumps one can see that
a) at the caller side, it supports speex/8000 in pt=102 and receives from the server speex/8000 in pt=102 b) at the callee side FreeSwitch supports support speex/8000 in pt=98 although it receives from the client speex/8000 in pt=102
When the voice starts caller sends RTP with pt=102 and expect to receive RTP with pt=102, while the callee sends RTP with pt=98 and expect to receive RTP with pt=102.
The RTP packets that received in the caller side are with pt=98 instead of 102 and thusly the client drops them.
Attached are the 2 files recorded from a call between 2 pjsip clients that support only speex/8000 codec.
un_FSCallerSide-speexClient.TXT – is the caller side SIP messages.
un_FSAnswerSide-speexClient.TXT – is the answer side of SIP messages.
Is there anything can be done at the configuration level to avoid this? Thanks in advance for your help
/tzury <un_FSAnswerSide-speexClient.TXT><un_FSCallerSide- speexClient.TXT>_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch- users http://www.freeswitch.org
This looks and sounds like a case where pjsip isn't listening to our SDP. If we 200 OK with speex on 102 and the far end starts sending it on 98 then I suspect the client is broken if I'm not mistaken.
/b
Could be, anyhow, note that this happens only both side using speex/8000. If one party uses a different codec the problem does not exists. Moreover, these same two clients (with speex/8000) works fine when connected to iptel.org. The most concerning fact is that a=rtpmap:98 SPEEX/8000 sent by FS to the callee even though the caller sent a=rtpmap:102 SPEEX/8000. Does this make any sense?
This looks and sounds like a case where pjsip isn't listening to our SDP. If we 200 OK with speex on 102 and the far end starts sending it on 98 then I suspect the client is broken if I'm not mistaken.
/b
Brian, The original "a=rtpmap:98 SPEEX/8000" is generated by FS and NOT by the client.
participants (2)
-
Brian West
-
Tzury Bar Yochay