rtpmap line missing on answer
I have a freeswitch system that (for the most part) works flawlessly for me. However, I need to have an additional rtpmap line in the SDP when a call is answered. My client sends the following SDP upon answering the call : m=audio 17214 RTP/AVP 0 19 101 100 c=IN IP4 192.168.98.79 a=rtpmap:0 PCMU/8000 a=rtpmap:19 CN/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtpmap:100 X-NSE/8000 a=fmtp:100 192-194 Freeswitch forwards the following SDP to the external gateway : m=audio 20654 RTP/AVP 0 19 101 c=IN IP4 66.223.187.208 a=rtpmap:0 PCMU/8000 a=rtpmap:19 CN/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 The other information appears fine. Everything works, but my client-side is not receiving the a=rtpmap:100 line. This issue appears regardless of whether or not I'm in proxy mode, bypass mode, or neither. Using "sip_append_audio_sdp" has no effect on the answering SDP, only the initial offer. Any ideas? Thanks in advance,
Sean, X-NSE is the Clear Channel codec from Cisco. I suspect FreeSWITCH does not support it, and as such, it can't be offered to leg B. Perhaps there is a way to enable in outbound codecs as bypass, but I really doubt so. Though, you could try to enable late-negotiation where client and gateway will negotiate together. David Ponzone Direction Technique email: david.ponzone@ipeva.fr tel: 01 74 03 18 97 gsm: 06 66 98 76 34 Service Client IPeva tel: 0811 46 26 26 www.ipeva.fr - www.ipeva-studio.com Ce message et toutes les pièces jointes sont confidentiels et établis à l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisée est interdite. Tout message électronique est susceptible d'altération. IPeva décline toute responsabilité au titre de ce message s'il a été altéré, déformé ou falsifié. Si vous n'êtes pas destinataire de ce message, merci de le détruire immédiatement et d'avertir l'expéditeur. Le 20/05/2011 à 20:54, Sean Eichhorn a écrit :
I have a freeswitch system that (for the most part) works flawlessly for me. However, I need to have an additional rtpmap line in the SDP when a call is answered. My client sends the following SDP upon answering the call : m=audio 17214 RTP/AVP 0 19 101 100 c=IN IP4 192.168.98.79 a=rtpmap:0 PCMU/8000 a=rtpmap:19 CN/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtpmap:100 X-NSE/8000 a=fmtp:100 192-194
Freeswitch forwards the following SDP to the external gateway : m=audio 20654 RTP/AVP 0 19 101 c=IN IP4 66.223.187.208 a=rtpmap:0 PCMU/8000 a=rtpmap:19 CN/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16
The other information appears fine. Everything works, but my client-side is not receiving the a=rtpmap:100 line. This issue appears regardless of whether or not I’m in proxy mode, bypass mode, or neither.
Using "sip_append_audio_sdp” has no effect on the answering SDP, only the initial offer.
Any ideas?
Thanks in advance, _______________________________________________ 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
Yes, I understand that this is the Cisco proprietary codec. The problem is that between two Cisco systems the SIP endpoints will not use this protocol if it is not sent in the SDP. The *original* SDP does contain the codec, but when the call is answered, another SDP is sent. This SDP is altered by Freeswitch and all codecs other than the selected codec, NTE, and comfort noise are removed. It might not be Freeswitch doing it. I’m digging into the source and it looks like it might be the Sofia-SIP library. The funny thing is that it works in one direction, but not the other. FS subscriber -> CIDR defined static SIP endpoint (WORKS!) CIDR defined SIP endpoint -> FS Subscriber (Doesn’t work) It seems that one of the major differences is that the subscriber answers with a 200 OK, whereas the CIDR endpoint answers with a 183. I’m currently searching to see if there is a way to change the response type, but so far no luck. Sean Eichhorn General Communications Inc. IP Telephony Engineer (907) 868-6902 -No telephony products were harmed in the making of the message- From: David Ponzone [mailto:david.ponzone@ipeva.fr] Sent: Friday, May 20, 2011 01:03 To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] rtpmap line missing on answer Sean, X-NSE is the Clear Channel codec from Cisco. I suspect FreeSWITCH does not support it, and as such, it can't be offered to leg B. Perhaps there is a way to enable in outbound codecs as bypass, but I really doubt so. Though, you could try to enable late-negotiation where client and gateway will negotiate together. David Ponzone Direction Technique email: david.ponzone@ipeva.fr<mailto:david.ponzone@ipeva.fr> tel: 01 74 03 18 97 gsm: 06 66 98 76 34 Service Client IPeva tel: 0811 46 26 26 www.ipeva.fr<BLOCKED::http://www.ipeva.fr/> - www.ipeva-studio.com<BLOCKED::http://www.ipeva-studio.com/> Ce message et toutes les pièces jointes sont confidentiels et établis à l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisée est interdite. Tout message électronique est susceptible d'altération. IPeva décline toute responsabilité au titre de ce message s'il a été altéré, déformé ou falsifié. Si vous n'êtes pas destinataire de ce message, merci de le détruire immédiatement et d'avertir l'expéditeur. Le 20/05/2011 à 20:54, Sean Eichhorn a écrit : I have a freeswitch system that (for the most part) works flawlessly for me. However, I need to have an additional rtpmap line in the SDP when a call is answered. My client sends the following SDP upon answering the call : m=audio 17214 RTP/AVP 0 19 101 100 c=IN IP4 192.168.98.79 a=rtpmap:0 PCMU/8000 a=rtpmap:19 CN/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtpmap:100 X-NSE/8000 a=fmtp:100 192-194 Freeswitch forwards the following SDP to the external gateway : m=audio 20654 RTP/AVP 0 19 101 c=IN IP4 66.223.187.208 a=rtpmap:0 PCMU/8000 a=rtpmap:19 CN/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 The other information appears fine. Everything works, but my client-side is not receiving the a=rtpmap:100 line. This issue appears regardless of whether or not I’m in proxy mode, bypass mode, or neither. Using "sip_append_audio_sdp” has no effect on the answering SDP, only the initial offer. Any ideas? Thanks in advance, _______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto: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
Who is answering the call? Are you sure they're not choosing a different codec from the ones offered in the INVITE? -Steve On 23 May 2011 16:52, Sean Eichhorn <seichhorn@gci.com> wrote:
Yes, I understand that this is the Cisco proprietary codec. The problem is that between two Cisco systems the SIP endpoints will not use this protocol if it is not sent in the SDP. The **original** SDP does contain the codec, but when the call is answered, another SDP is sent. This SDP is altered by Freeswitch and all codecs other than the selected codec, NTE, and comfort noise are removed.
It might not be Freeswitch doing it. I’m digging into the source and it looks like it might be the Sofia-SIP library.
The funny thing is that it works in one direction, but not the other.
FS subscriber -> CIDR defined static SIP endpoint (WORKS!)
CIDR defined SIP endpoint -> FS Subscriber (Doesn’t work)
It seems that one of the major differences is that the subscriber answers with a 200 OK, whereas the CIDR endpoint answers with a 183.
I’m currently searching to see if there is a way to change the response type, but so far no luck.
Sean Eichhorn
General Communications Inc.
IP Telephony Engineer
(907) 868-6902
-No telephony products were harmed in the making of the message-
*From:* David Ponzone [mailto:david.ponzone@ipeva.fr] *Sent:* Friday, May 20, 2011 01:03 *To:* FreeSWITCH Users Help *Subject:* Re: [Freeswitch-users] rtpmap line missing on answer
Sean,e
X-NSE is the Clear Channel codec from Cisco.
I suspect FreeSWITCH does not support it, and as such, it can't be offered to leg B.
Perhaps there is a way to enable in outbound codecs as bypass, but I really doubt so.
Though, you could try to enable late-negotiation where client and gateway will negotiate together.
David Ponzone Direction Technique
email: david.ponzone@ipeva.fr
tel: 01 74 03 18 97
gsm: 06 66 98 76 34
Service Client IPeva
tel: 0811 46 26 26
*www.ipeva.fr* - *www.ipeva-studio.com*
*Ce message et toutes les pièces jointes sont confidentiels et établis à l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisée est interdite. Tout message électronique est susceptible d'altération. IPeva décline toute responsabilité au titre de ce message s'il a été altéré, déformé ou falsifié. Si vous n'êtes pas destinataire de ce message, merci de le détruire immédiatement et d'avertir l'expéditeur.*
* *
Le 20/05/2011 à 20:54, Sean Eichhorn a écrit :
I have a freeswitch system that (for the most part) works flawlessly for me. However, I need to have an additional rtpmap line in the SDP when a call is answered.
My client sends the following SDP upon answering the call :
m=audio 17214 RTP/AVP 0 19 101 100
c=IN IP4 192.168.98.79
a=rtpmap:0 PCMU/8000
a=rtpmap:19 CN/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:100 X-NSE/8000
a=fmtp:100 192-194
Freeswitch forwards the following SDP to the external gateway :
m=audio 20654 RTP/AVP 0 19 101
c=IN IP4 66.223.187.208
a=rtpmap:0 PCMU/8000
a=rtpmap:19 CN/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
The other information appears fine. Everything works, but my client-side is not receiving the a=rtpmap:100 line.
This issue appears regardless of whether or not I’m in proxy mode, bypass mode, or neither.
Using "sip_append_audio_sdp” has no effect on the answering SDP, only the initial offer.
Any ideas?
Thanks in advance,
_______________________________________________ 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
_______________________________________________ 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
Yeah, they're negotiating the same codec on both sides. The problem is the way Cisco handles the negotiation. Here's an example of what I see in Freeswitch: Received from CALLED : SIP/2.0 200 OK Via: SIP/2.0/UDP A.B.C.D;rport;branch=z9hG4bKXZZ18p8tD03cS From: "pending" <sip:xxxxxxxx02@A.B.C.D>;tag=NH1HrNe744HSB To: <sip:sean@E.F.G.H:5060>;tag=622555CC-408 Date: Mon, 23 May 2011 23:50:56 GMT Call-ID: 69258f8c-0038-122f-19ba-000c29c18d38 CSeq: 12760849 INVITE Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER Allow-Events: telephone-event Contact: <sip:xxxxxxxx75@E.F.G.H:5060> Supported: replaces Supported: sdp-anat Server: Cisco-SIPGateway/IOS-12.x Content-Type: application/sdp Content-Disposition: session;handling=required Content-Length: 311 v=0 o=CiscoSystemsSIP-GW-UserAgent 4080 7999 IN IP4 E.F.G.H s=SIP Call c=IN IP4 E.F.G.H t=0 0 m=audio 17122 RTP/AVP 0 19 101 100 c=IN IP4 E.F.G.H a=rtpmap:0 PCMU/8000 a=rtpmap:19 CN/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtpmap:100 X-NSE/8000 a=fmtp:100 192-194 Sent to CALLING : SIP/2.0 200 OK Via: SIP/2.0/UDP I.J.K.L:5060;branch=z9hG4bK4C2B6C64 From: <sip:xxxxxxxx02@ I.J.K.L >;tag=9020153C-21B3 To: <sip:xxxxxxxx75@A.B.C.D>;tag=m87rptX37UU6F Call-ID: AFADEF2E-84CC11E0-B1D4F23A-27804614@ I.J.K.L CSeq: 101 INVITE Contact: <sip:xxxxxxxx75@ A.B.C.D:5060;transport=udp> User-Agent: GCI 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 Min-SE: 1800 Content-Type: application/sdp Content-Disposition: session Content-Length: 261 Remote-Party-ID: "Outbound Call" <sip:sean@ A.B.C.D >;party=calling;privacy=off;screen=no v=0 o=FreeSWITCH 1995227603 1995227604 IN IP4 A.B.C.D s=FreeSWITCH c=IN IP4 A.B.C.D t=0 0 m=audio 24636 RTP/AVP 0 19 101 c=IN IP4 A.B.C.D a=rtpmap:0 PCMU/8000 a=rtpmap:19 CN/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 This is not the case when the call direction is reversed. Like I said, the only difference appears to be that one direction is responding with a 183 while this one is responding with a 200.
Sean, can you show us the same packets, but for an incoming call (that works, if I understood you correctly) ? David Ponzone Direction Technique email: david.ponzone@ipeva.fr tel: 01 74 03 18 97 gsm: 06 66 98 76 34 Service Client IPeva tel: 0811 46 26 26 www.ipeva.fr - www.ipeva-studio.com Ce message et toutes les pièces jointes sont confidentiels et établis à l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisée est interdite. Tout message électronique est susceptible d'altération. IPeva décline toute responsabilité au titre de ce message s'il a été altéré, déformé ou falsifié. Si vous n'êtes pas destinataire de ce message, merci de le détruire immédiatement et d'avertir l'expéditeur. Le 24/05/2011 à 01:53, Sean Eichhorn a écrit :
Yeah, they’re negotiating the same codec on both sides. The problem is the way Cisco handles the negotiation. Here’s an example of what I see in Freeswitch:
Received from CALLED :
SIP/2.0 200 OK Via: SIP/2.0/UDP A.B.C.D;rport;branch=z9hG4bKXZZ18p8tD03cS From: "pending" <sip:xxxxxxxx02@A.B.C.D>;tag=NH1HrNe744HSB To: <sip:sean@E.F.G.H:5060>;tag=622555CC-408 Date: Mon, 23 May 2011 23:50:56 GMT Call-ID: 69258f8c-0038-122f-19ba-000c29c18d38 CSeq: 12760849 INVITE Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER Allow-Events: telephone-event Contact: <sip:xxxxxxxx75@E.F.G.H:5060> Supported: replaces Supported: sdp-anat Server: Cisco-SIPGateway/IOS-12.x Content-Type: application/sdp Content-Disposition: session;handling=required Content-Length: 311
v=0 o=CiscoSystemsSIP-GW-UserAgent 4080 7999 IN IP4 E.F.G.H s=SIP Call c=IN IP4 E.F.G.H t=0 0 m=audio 17122 RTP/AVP 0 19 101 100 c=IN IP4 E.F.G.H a=rtpmap:0 PCMU/8000 a=rtpmap:19 CN/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtpmap:100 X-NSE/8000 a=fmtp:100 192-194
Sent to CALLING : SIP/2.0 200 OK Via: SIP/2.0/UDP I.J.K.L:5060;branch=z9hG4bK4C2B6C64 From: <sip:xxxxxxxx02@ I.J.K.L >;tag=9020153C-21B3 To: <sip:xxxxxxxx75@A.B.C.D>;tag=m87rptX37UU6F Call-ID: AFADEF2E-84CC11E0-B1D4F23A-27804614@ I.J.K.L CSeq: 101 INVITE Contact: <sip:xxxxxxxx75@ A.B.C.D:5060;transport=udp> User-Agent: GCI 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 Min-SE: 1800 Content-Type: application/sdp Content-Disposition: session Content-Length: 261 Remote-Party-ID: "Outbound Call" <sip:sean@ A.B.C.D >;party=calling;privacy=off;screen=no
v=0 o=FreeSWITCH 1995227603 1995227604 IN IP4 A.B.C.D s=FreeSWITCH c=IN IP4 A.B.C.D t=0 0 m=audio 24636 RTP/AVP 0 19 101 c=IN IP4 A.B.C.D a=rtpmap:0 PCMU/8000 a=rtpmap:19 CN/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16
This is not the case when the call direction is reversed. Like I said, the only difference appears to be that one direction is responding with a 183 while this one is responding with a 200.
_______________________________________________ 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
Yep, no problem. Here it is. Same endpoints. The only thing that changed is the call direction. Received Message : SIP/2.0 200 OK Via: SIP/2.0/UDP A.B.C.D;rport;branch=z9hG4bK5Qtv3B04eS46g From: "Test 2" <sip:xxxxxxxx75@A.B.C.D>;tag=yy2XQKXSy7gtN To: <sip:xxxxx02@I.J.K.L>;tag=93BEF648-1A8B Date: Tue, 24 May 2011 16:37:23 GMT Call-ID: b7967af6-00c4-122f-19ba-000c29c18d38 CSeq: 12790979 INVITE Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER Allow-Events: telephone-event Remote-Party-ID: <sip:xxxxx02@I.J.K.L>;party=called;screen=no;privacy=off Contact: <sip:xxxxx02@I.J.K.L:5060> Supported: replaces Supported: sdp-anat Server: Cisco-SIPGateway/IOS-12.x Content-Type: application/sdp Content-Disposition: session;handling=required Content-Length: 334 v=0 o=CiscoSystemsSIP-GW-UserAgent 6942 3511 IN IP4 I.J.K.L s=SIP Call c=IN IP4 I.J.K.L t=0 0 m=audio 17046 RTP/AVP 18 19 101 100 c=IN IP4 I.J.K.L a=rtpmap:18 G729/8000 a=rtpmap:19 CN/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtpmap:100 X-NSE/8000 a=fmtp:100 192-194 Sent Message : SIP/2.0 200 OK Via: SIP/2.0/UDP E.F.G.H:5060;branch=z9hG4bK9E31DBF From: "Test 2" <sip:xxxxxxxx75@A.B.C.D>;tag=65BCD9B0-115E To: <sip:xxxxx02@A.B.C.D>;tag=XN94Nrcp1yt7S Call-ID: A4A3C9E0-855A11E0-8237C79A-B2A2FA42@E.F.G.H CSeq: 102 INVITE Contact: <sip:xxxxx02@A.B.C.D:5060;transport=udp> User-Agent: GCI 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 Min-SE: 1800 Content-Type: application/sdp Content-Disposition: session Content-Length: 333 Remote-Party-ID: "xxxxx02" <sip:xxxxx02@A.B.C.D>;party=calling;privacy=off;screen=no v=0 o=FreeSWITCH 3912792884 3912792885 IN IP4 A.B.C.D s=FreeSWITCH c=IN IP4 A.B.C.D t=0 0 m=audio 27728 RTP/AVP 18 100 19 101 c=IN IP4 A.B.C.D a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:100 X-NSE/8000 a=fmtp:100 192-194 a=rtpmap:19 CN/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of David Ponzone Sent: Monday, May 23, 2011 09:42 To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] rtpmap line missing on answer Sean, can you show us the same packets, but for an incoming call (that works, if I understood you correctly) ? David Ponzone Direction Technique email: david.ponzone@ipeva.fr<mailto:david.ponzone@ipeva.fr> tel: 01 74 03 18 97 gsm: 06 66 98 76 34 Service Client IPeva tel: 0811 46 26 26 www.ipeva.fr<BLOCKED::http://www.ipeva.fr/> - www.ipeva-studio.com<BLOCKED::http://www.ipeva-studio.com/> Ce message et toutes les pièces jointes sont confidentiels et établis à l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisée est interdite. Tout message électronique est susceptible d'altération. IPeva décline toute responsabilité au titre de ce message s'il a été altéré, déformé ou falsifié. Si vous n'êtes pas destinataire de ce message, merci de le détruire immédiatement et d'avertir l'expéditeur. Le 24/05/2011 à 01:53, Sean Eichhorn a écrit : Yeah, they’re negotiating the same codec on both sides. The problem is the way Cisco handles the negotiation. Here’s an example of what I see in Freeswitch: Received from CALLED : SIP/2.0 200 OK Via: SIP/2.0/UDP A.B.C.D;rport;branch=z9hG4bKXZZ18p8tD03cS From: "pending" <sip:xxxxxxxx02@A.B.C.D>;tag=NH1HrNe744HSB To: <sip:sean@E.F.G.H:5060>;tag=622555CC-408 Date: Mon, 23 May 2011 23:50:56 GMT Call-ID: 69258f8c-0038-122f-19ba-000c29c18d38 CSeq: 12760849 INVITE Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER Allow-Events: telephone-event Contact: <sip:xxxxxxxx75@E.F.G.H:5060> Supported: replaces Supported: sdp-anat Server: Cisco-SIPGateway/IOS-12.x Content-Type: application/sdp Content-Disposition: session;handling=required Content-Length: 311 v=0 o=CiscoSystemsSIP-GW-UserAgent 4080 7999 IN IP4 E.F.G.H s=SIP Call c=IN IP4 E.F.G.H t=0 0 m=audio 17122 RTP/AVP 0 19 101 100 c=IN IP4 E.F.G.H a=rtpmap:0 PCMU/8000 a=rtpmap:19 CN/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtpmap:100 X-NSE/8000 a=fmtp:100 192-194 Sent to CALLING : SIP/2.0 200 OK Via: SIP/2.0/UDP I.J.K.L:5060;branch=z9hG4bK4C2B6C64 From: <sip:xxxxxxxx02@ I.J.K.L >;tag=9020153C-21B3 To: <sip:xxxxxxxx75@A.B.C.D>;tag=m87rptX37UU6F Call-ID: AFADEF2E-84CC11E0-B1D4F23A-27804614@ I.J.K.L CSeq: 101 INVITE Contact: <sip:xxxxxxxx75@ A.B.C.D:5060;transport=udp> User-Agent: GCI 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 Min-SE: 1800 Content-Type: application/sdp Content-Disposition: session Content-Length: 261 Remote-Party-ID: "Outbound Call" <sip:sean@ A.B.C.D >;party=calling;privacy=off;screen=no v=0 o=FreeSWITCH 1995227603 1995227604 IN IP4 A.B.C.D s=FreeSWITCH c=IN IP4 A.B.C.D t=0 0 m=audio 24636 RTP/AVP 0 19 101 c=IN IP4 A.B.C.D a=rtpmap:0 PCMU/8000 a=rtpmap:19 CN/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 This is not the case when the call direction is reversed. Like I said, the only difference appears to be that one direction is responding with a 183 while this one is responding with a 200. _______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto: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
Sean, can you check the configuration of the SIP profile used by both legs ? Perhaps you have late-negotiation enabled in one of them ? David Ponzone Direction Technique email: david.ponzone@ipeva.fr tel: 01 74 03 18 97 gsm: 06 66 98 76 34 Service Client IPeva tel: 0811 46 26 26 www.ipeva.fr - www.ipeva-studio.com Ce message et toutes les pièces jointes sont confidentiels et établis à l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisée est interdite. Tout message électronique est susceptible d'altération. IPeva décline toute responsabilité au titre de ce message s'il a été altéré, déformé ou falsifié. Si vous n'êtes pas destinataire de ce message, merci de le détruire immédiatement et d'avertir l'expéditeur. Le 24/05/2011 à 18:31, Sean Eichhorn a écrit :
Yep, no problem. Here it is. Same endpoints. The only thing that changed is the call direction.
Received Message : SIP/2.0 200 OK Via: SIP/2.0/UDP A.B.C.D;rport;branch=z9hG4bK5Qtv3B04eS46g From: "Test 2" <sip:xxxxxxxx75@A.B.C.D>;tag=yy2XQKXSy7gtN To: <sip:xxxxx02@I.J.K.L>;tag=93BEF648-1A8B Date: Tue, 24 May 2011 16:37:23 GMT Call-ID: b7967af6-00c4-122f-19ba-000c29c18d38 CSeq: 12790979 INVITE Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER Allow-Events: telephone-event Remote-Party-ID: <sip:xxxxx02@I.J.K.L>;party=called;screen=no;privacy=off Contact: <sip:xxxxx02@I.J.K.L:5060> Supported: replaces Supported: sdp-anat Server: Cisco-SIPGateway/IOS-12.x Content-Type: application/sdp Content-Disposition: session;handling=required Content-Length: 334
v=0 o=CiscoSystemsSIP-GW-UserAgent 6942 3511 IN IP4 I.J.K.L s=SIP Call c=IN IP4 I.J.K.L t=0 0 m=audio 17046 RTP/AVP 18 19 101 100 c=IN IP4 I.J.K.L a=rtpmap:18 G729/8000 a=rtpmap:19 CN/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtpmap:100 X-NSE/8000 a=fmtp:100 192-194
Sent Message :
SIP/2.0 200 OK Via: SIP/2.0/UDP E.F.G.H:5060;branch=z9hG4bK9E31DBF From: "Test 2" <sip:xxxxxxxx75@A.B.C.D>;tag=65BCD9B0-115E To: <sip:xxxxx02@A.B.C.D>;tag=XN94Nrcp1yt7S Call-ID: A4A3C9E0-855A11E0-8237C79A-B2A2FA42@E.F.G.H CSeq: 102 INVITE Contact: <sip:xxxxx02@A.B.C.D:5060;transport=udp> User-Agent: GCI 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 Min-SE: 1800 Content-Type: application/sdp Content-Disposition: session Content-Length: 333 Remote-Party-ID: "xxxxx02" <sip:xxxxx02@A.B.C.D>;party=calling;privacy=off;screen=no
v=0 o=FreeSWITCH 3912792884 3912792885 IN IP4 A.B.C.D s=FreeSWITCH c=IN IP4 A.B.C.D t=0 0 m=audio 27728 RTP/AVP 18 100 19 101 c=IN IP4 A.B.C.D a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:100 X-NSE/8000 a=fmtp:100 192-194 a=rtpmap:19 CN/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16
From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of David Ponzone Sent: Monday, May 23, 2011 09:42 To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] rtpmap line missing on answer
Sean,
can you show us the same packets, but for an incoming call (that works, if I understood you correctly) ?
David Ponzone Direction Technique email: david.ponzone@ipeva.fr tel: 01 74 03 18 97 gsm: 06 66 98 76 34
Service Client IPeva tel: 0811 46 26 26 www.ipeva.fr - www.ipeva-studio.com
Ce message et toutes les pièces jointes sont confidentiels et établis à l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisée est interdite. Tout message électronique est susceptible d'altération. IPeva décline toute responsabilité au titre de ce message s'il a été altéré, déformé ou falsifié. Si vous n'êtes pas destinataire de ce message, merci de le détruire immédiatement et d'avertir l'expéditeur.
Le 24/05/2011 à 01:53, Sean Eichhorn a écrit :
Yeah, they’re negotiating the same codec on both sides. The problem is the way Cisco handles the negotiation. Here’s an example of what I see in Freeswitch:
Received from CALLED :
SIP/2.0 200 OK Via: SIP/2.0/UDP A.B.C.D;rport;branch=z9hG4bKXZZ18p8tD03cS From: "pending" <sip:xxxxxxxx02@A.B.C.D>;tag=NH1HrNe744HSB To: <sip:sean@E.F.G.H:5060>;tag=622555CC-408 Date: Mon, 23 May 2011 23:50:56 GMT Call-ID: 69258f8c-0038-122f-19ba-000c29c18d38 CSeq: 12760849 INVITE Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER Allow-Events: telephone-event Contact: <sip:xxxxxxxx75@E.F.G.H:5060> Supported: replaces Supported: sdp-anat Server: Cisco-SIPGateway/IOS-12.x Content-Type: application/sdp Content-Disposition: session;handling=required Content-Length: 311
v=0 o=CiscoSystemsSIP-GW-UserAgent 4080 7999 IN IP4 E.F.G.H s=SIP Call c=IN IP4 E.F.G.H t=0 0 m=audio 17122 RTP/AVP 0 19 101 100 c=IN IP4 E.F.G.H a=rtpmap:0 PCMU/8000 a=rtpmap:19 CN/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtpmap:100 X-NSE/8000 a=fmtp:100 192-194
Sent to CALLING : SIP/2.0 200 OK Via: SIP/2.0/UDP I.J.K.L:5060;branch=z9hG4bK4C2B6C64 From: <sip:xxxxxxxx02@ I.J.K.L >;tag=9020153C-21B3 To: <sip:xxxxxxxx75@A.B.C.D>;tag=m87rptX37UU6F Call-ID: AFADEF2E-84CC11E0-B1D4F23A-27804614@ I.J.K.L CSeq: 101 INVITE Contact: <sip:xxxxxxxx75@ A.B.C.D:5060;transport=udp> User-Agent: GCI 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 Min-SE: 1800 Content-Type: application/sdp Content-Disposition: session Content-Length: 261 Remote-Party-ID: "Outbound Call" <sip:sean@ A.B.C.D >;party=calling;privacy=off;screen=no
v=0 o=FreeSWITCH 1995227603 1995227604 IN IP4 A.B.C.D s=FreeSWITCH c=IN IP4 A.B.C.D t=0 0 m=audio 24636 RTP/AVP 0 19 101 c=IN IP4 A.B.C.D a=rtpmap:0 PCMU/8000 a=rtpmap:19 CN/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16
This is not the case when the call direction is reversed. Like I said, the only difference appears to be that one direction is responding with a 183 while this one is responding with a 200.
_______________________________________________ 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
_______________________________________________ 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
Actually, I just found another interesting piece of the puzzle. On the outbound call (that works), the gateway responds with a 183/SDP message. The inbound call (that doesn’t work) returns a 180 Ringing/NO SDP message. Both legs are using the same profile, so I don’t think that’s an issue. For some reason though, if a 183/SDP is sent, Freeswitch forwards the rtpmap attribute. If no 183 is detected, it deletes the attribute. From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of David Ponzone Sent: Tuesday, May 24, 2011 01:12 To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] rtpmap line missing on answer Sean, can you check the configuration of the SIP profile used by both legs ? Perhaps you have late-negotiation enabled in one of them ? David Ponzone Direction Technique email: david.ponzone@ipeva.fr<mailto:david.ponzone@ipeva.fr> tel: 01 74 03 18 97 gsm: 06 66 98 76 34 Service Client IPeva tel: 0811 46 26 26 www.ipeva.fr<BLOCKED::http://www.ipeva.fr/> - www.ipeva-studio.com<BLOCKED::http://www.ipeva-studio.com/> Ce message et toutes les pièces jointes sont confidentiels et établis à l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisée est interdite. Tout message électronique est susceptible d'altération. IPeva décline toute responsabilité au titre de ce message s'il a été altéré, déformé ou falsifié. Si vous n'êtes pas destinataire de ce message, merci de le détruire immédiatement et d'avertir l'expéditeur.
FWIW, you can use "pre_answer" to send 183 w/SDP from FS; "ring_ready" will send 180. See the early media article on the wiki for more information. -MC On Tue, May 24, 2011 at 2:33 PM, Sean Eichhorn <seichhorn@gci.com> wrote:
Actually, I just found another interesting piece of the puzzle.
On the outbound call (that works), the gateway responds with a 183/SDP message.
The inbound call (that doesn’t work) returns a 180 Ringing/NO SDP message.
Both legs are using the same profile, so I don’t think that’s an issue. For some reason though, if a 183/SDP is sent, Freeswitch forwards the rtpmap attribute. If no 183 is detected, it deletes the attribute.
*From:* freeswitch-users-bounces@lists.freeswitch.org [mailto: freeswitch-users-bounces@lists.freeswitch.org] *On Behalf Of *David Ponzone *Sent:* Tuesday, May 24, 2011 01:12
*To:* FreeSWITCH Users Help *Subject:* Re: [Freeswitch-users] rtpmap line missing on answer
Sean,
can you check the configuration of the SIP profile used by both legs ?
Perhaps you have late-negotiation enabled in one of them ?
David Ponzone Direction Technique
email: david.ponzone@ipeva.fr
tel: 01 74 03 18 97
gsm: 06 66 98 76 34
Service Client IPeva
tel: 0811 46 26 26
*www.ipeva.fr* - *www.ipeva-studio.com*
*Ce message et toutes les pièces jointes sont confidentiels et établis à l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisée est interdite. Tout message électronique est susceptible d'altération. IPeva décline toute responsabilité au titre de ce message s'il a été altéré, déformé ou falsifié. Si vous n'êtes pas destinataire de ce message, merci de le détruire immédiatement et d'avertir l'expéditeur.*
* *
_______________________________________________ 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
You'll need to use proxy media to pass NSE across a bridge: http://wiki.freeswitch.org/wiki/Proxy_Media Please keep in mind there are several advantages and disadvantages to using this media mode. On Fri, May 20, 2011 at 2:54 PM, Sean Eichhorn <seichhorn@gci.com> wrote:
I have a freeswitch system that (for the most part) works flawlessly for me. However, I need to have an additional rtpmap line in the SDP when a call is answered.
My client sends the following SDP upon answering the call :
m=audio 17214 RTP/AVP 0 19 101 100
c=IN IP4 192.168.98.79
a=rtpmap:0 PCMU/8000
a=rtpmap:19 CN/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:100 X-NSE/8000
a=fmtp:100 192-194
Freeswitch forwards the following SDP to the external gateway :
m=audio 20654 RTP/AVP 0 19 101
c=IN IP4 66.223.187.208
a=rtpmap:0 PCMU/8000
a=rtpmap:19 CN/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
The other information appears fine. Everything works, but my client-side is not receiving the a=rtpmap:100 line.
This issue appears regardless of whether or not I’m in proxy mode, bypass mode, or neither.
Using "sip_append_audio_sdp” has no effect on the answering SDP, only the initial offer.
Any ideas?
Thanks in advance,
_______________________________________________ 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
-- Kristian Kielhofner
participants (5)
-
David Ponzone
-
Kristian Kielhofner
-
Michael Collins
-
Sean Eichhorn
-
Steven Ayre