in bypass_media mode, 2833 payload type modified by freeswitch!
Hi All, I use freeswitch to bridge one incoming call to other target phone number. I use bypass_media mode. So the rtp is not go through the freeswitch, By I notice that When LegB reply 183 or 200 SDP message. Freeswitch change it 2833 telephone-event payload type. and forwarding the message to caller. This make the caller use wrong dtmf payload type to send dtmf What wrong with that? How can fix it? Any information or help is welcome. information with "sofia global siptrace on" http://pastebin.freeswitch.org/16496 Thanks Best Regards Qingquan -- Using Gmail? Please read this important notice: http://www.fsf.org/campaigns/jstrap/gmail?40922.
You have a mail issue. Check your spam... 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 15/06/2011 à 03:55, qingquan luo a écrit :
Hi All,
I use freeswitch to bridge one incoming call to other target phone number. I use bypass_media mode. So the rtp is not go through the freeswitch, By I notice that When LegB reply 183 or 200 SDP message. Freeswitch change it 2833 telephone-event payload type. and forwarding the message to caller. This make the caller use wrong dtmf payload type to send dtmf
What wrong with that? How can fix it? Any information or help is welcome.
information with "sofia global siptrace on" http://pastebin.freeswitch.org/16496
Thanks
Best Regards
Qingquan
-- Using Gmail? Please read this important notice: http://www.fsf.org/campaigns/jstrap/gmail?40922. _______________________________________________ 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
Hi David, Thank you for reminder, I resend this mail in mail list, Because I can not reply preview mail( I make a mistake to subscribe this mail list in Daily Digest mode.) So I need resend this mail for require help. For this issue, I has paste sip debug output in: information with "sofia global siptrace on" http://pastebin.freeswitch.org/16496 Thanks On Wed, Jun 15, 2011 at 3:15 PM, David Ponzone <david.ponzone@ipeva.fr>wrote:
You have a mail issue. Check your spam...
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 15/06/2011 à 03:55, qingquan luo a écrit :
Hi All,
I use freeswitch to bridge one incoming call to other target phone number. I use bypass_media mode. So the rtp is not go through the freeswitch, By I notice that When LegB reply 183 or 200 SDP message. Freeswitch change it 2833 telephone-event payload type. and forwarding the message to caller. This make the caller use wrong dtmf payload type to send dtmf
What wrong with that? How can fix it? Any information or help is welcome.
information with "sofia global siptrace on" http://pastebin.freeswitch.org/16496
Thanks
Best Regards
Qingquan
-- Using Gmail? Please read this important notice: http://www.fsf.org/campaigns/jstrap/gmail?40922. _______________________________________________ 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
-- Using Gmail? Please read this important notice: http://www.fsf.org/campaigns/jstrap/gmail?40922.
QQ, I don't see that FreeSWITCH is doing anything incorrect here. According to RFC3264, the offerer (FreeSWITCH) sends an SDP and in the case of RTP, the answerer (GRSIP Gateway) must use the payload type offered, even if the answerer uses a different payload type when it sends a telephone-event. http://tools.ietf.org/html/rfc3264#section-6.1 Specifically near the end: "In the case of RTP, it MUST use the payload type numbers from the offer, even if they differ from those in the answer." Technically, FreeSWITCH isn't "changing" anything anyway. The originator of the call (Vox Callcontrol) is the one who chose PT 101 in the INVITE that it sent to FreeSWITCH. FS is just passing that along without modifying it. I think you need to contact the people running the gateway and make sure that they understand that they are not following RFC3264 if they're rejecting telephone-events in PT 101 simply because they prefer to send in PT 110. Also, if your Vox Callcontrol client has any configuration options then maybe you can tell it to use PT 110 for RFC2833 DTMFs. It is a bit of a workaround but this is SIP, so no one is expecting perfection. :) -MC On Wed, Jun 15, 2011 at 12:23 AM, qingquan luo <qingquan@globalroam.com>wrote:
Hi David, Thank you for reminder, I resend this mail in mail list, Because I can not reply preview mail( I make a mistake to subscribe this mail list in Daily Digest mode.) So I need resend this mail for require help.
For this issue, I has paste sip debug output in:
information with "sofia global siptrace on" http://pastebin.freeswitch.org/16496
Thanks
On Wed, Jun 15, 2011 at 3:15 PM, David Ponzone <david.ponzone@ipeva.fr>wrote:
You have a mail issue. Check your spam...
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 15/06/2011 à 03:55, qingquan luo a écrit :
Hi All,
I use freeswitch to bridge one incoming call to other target phone number. I use bypass_media mode. So the rtp is not go through the freeswitch, By I notice that When LegB reply 183 or 200 SDP message. Freeswitch change it 2833 telephone-event payload type. and forwarding the message to caller. This make the caller use wrong dtmf payload type to send dtmf
What wrong with that? How can fix it? Any information or help is welcome.
information with "sofia global siptrace on" http://pastebin.freeswitch.org/16496
Thanks
Best Regards
Qingquan
-- Using Gmail? Please read this important notice: http://www.fsf.org/campaigns/jstrap/gmail?40922. _______________________________________________ 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
-- Using Gmail? Please read this important notice: http://www.fsf.org/campaigns/jstrap/gmail?40922.
_______________________________________________ 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
Michael, This isn't an SDP offer/answer issue with FreeSWITCH. Even if there were underlying offer/answer issues between the endpoints FreeSWITCH is in bypass_media mode and it shouldn't care about the SDP because by definition (bypass_media) the SDP is "pass through" between the two remote endpoints. The specific issue lies in the 183 w/ SDP at line 207. It has rfc2833 payload type 110. When FreeSWITCH forwards this to the other end (line 276) the SDP is untouched (expected with bypass_media) EXCEPT the rfc2833 payload type has been changed to 101 (unexpected with bypass_media). It does this again with the 200 OK. All other SDP params are passed through - media address, port, codec, goofy session name, and even the SER rtpproxy attributes. I'll admit the remote end/proxy is doing some strange stuff - 100, 101, 183, then 180, etc but this does look like a strange bypass_media bug in FreeSWITCH. The RFC2833 payload type should be forwarded between the two remote endpoints without being modified by FreeSWITCH - just like all of the other SDP parameters (or any part of the SIP body, for that matter). On Wed, Jun 15, 2011 at 5:09 PM, Michael Collins <msc@freeswitch.org> wrote:
QQ, I don't see that FreeSWITCH is doing anything incorrect here. According to RFC3264, the offerer (FreeSWITCH) sends an SDP and in the case of RTP, the answerer (GRSIP Gateway) must use the payload type offered, even if the answerer uses a different payload type when it sends a telephone-event. http://tools.ietf.org/html/rfc3264#section-6.1 Specifically near the end: "In the case of RTP, it MUST use the payload type numbers
from the offer, even if they differ from those in the answer."
Technically, FreeSWITCH isn't "changing" anything anyway. The originator of the call (Vox Callcontrol) is the one who chose PT 101 in the INVITE that it sent to FreeSWITCH. FS is just passing that along without modifying it. I think you need to contact the people running the gateway and make sure that they understand that they are not following RFC3264 if they're rejecting telephone-events in PT 101 simply because they prefer to send in PT 110. Also, if your Vox Callcontrol client has any configuration options then maybe you can tell it to use PT 110 for RFC2833 DTMFs. It is a bit of a workaround but this is SIP, so no one is expecting perfection. :) -MC
-- Kristian Kielhofner
Ah, quite right. I'd file this in Jira. Hopefully it's not buried deep in the Sofia stack... -MC On Wed, Jun 15, 2011 at 2:58 PM, Kristian Kielhofner <kris@kriskinc.com>wrote:
Michael,
This isn't an SDP offer/answer issue with FreeSWITCH. Even if there were underlying offer/answer issues between the endpoints FreeSWITCH is in bypass_media mode and it shouldn't care about the SDP because by definition (bypass_media) the SDP is "pass through" between the two remote endpoints.
The specific issue lies in the 183 w/ SDP at line 207. It has rfc2833 payload type 110. When FreeSWITCH forwards this to the other end (line 276) the SDP is untouched (expected with bypass_media) EXCEPT the rfc2833 payload type has been changed to 101 (unexpected with bypass_media). It does this again with the 200 OK. All other SDP params are passed through - media address, port, codec, goofy session name, and even the SER rtpproxy attributes. I'll admit the remote end/proxy is doing some strange stuff - 100, 101, 183, then 180, etc but this does look like a strange bypass_media bug in FreeSWITCH. The RFC2833 payload type should be forwarded between the two remote endpoints without being modified by FreeSWITCH - just like all of the other SDP parameters (or any part of the SIP body, for that matter).
On Wed, Jun 15, 2011 at 5:09 PM, Michael Collins <msc@freeswitch.org> wrote:
QQ, I don't see that FreeSWITCH is doing anything incorrect here. According to RFC3264, the offerer (FreeSWITCH) sends an SDP and in the case of RTP, the answerer (GRSIP Gateway) must use the payload type offered, even if the answerer uses a different payload type when it sends a telephone-event. http://tools.ietf.org/html/rfc3264#section-6.1 Specifically near the end: "In the case of RTP, it MUST use the payload type numbers
from the offer, even if they differ from those in the answer."
Technically, FreeSWITCH isn't "changing" anything anyway. The originator of the call (Vox Callcontrol) is the one who chose PT 101 in the INVITE that it sent to FreeSWITCH. FS is just passing that along without modifying it. I think you need to contact the people running the gateway and make sure that they understand that they are not following RFC3264 if they're rejecting telephone-events in PT 101 simply because they prefer to send in PT 110. Also, if your Vox Callcontrol client has any configuration options then maybe you can tell it to use PT 110 for RFC2833 DTMFs. It is a bit of a workaround but this is SIP, so no one is expecting perfection. :) -MC
-- Kristian Kielhofner
_______________________________________________ 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
However, there is not really any rule anywhere that states that bypass media will not touch the packets. All of the packets/sdp are still subject to SIP SOA model so if you pass a remote sdp into the lib, sofia will parse and modify it. The idea of bypass media is to bypass the media by advertising the proper codecs/addrs to arrange point to point media and there is no assurance that the packets will not be modified. However, There is a sofia param called "enable-soa" and a variable sip_enable_soa for per call basis which can be set to false to disable SIP SOA from sofia and most likely result in untouched exchange of SDP. try this in your dialplan <action application="set" data="bypass_media=true"/> <action application="export" data="sip_enable_soa=false"/> On Wed, Jun 15, 2011 at 5:11 PM, Michael Collins <msc@freeswitch.org> wrote:
Ah, quite right. I'd file this in Jira. Hopefully it's not buried deep in the Sofia stack... -MC
On Wed, Jun 15, 2011 at 2:58 PM, Kristian Kielhofner <kris@kriskinc.com> wrote:
Michael,
This isn't an SDP offer/answer issue with FreeSWITCH. Even if there were underlying offer/answer issues between the endpoints FreeSWITCH is in bypass_media mode and it shouldn't care about the SDP because by definition (bypass_media) the SDP is "pass through" between the two remote endpoints.
The specific issue lies in the 183 w/ SDP at line 207. It has rfc2833 payload type 110. When FreeSWITCH forwards this to the other end (line 276) the SDP is untouched (expected with bypass_media) EXCEPT the rfc2833 payload type has been changed to 101 (unexpected with bypass_media). It does this again with the 200 OK. All other SDP params are passed through - media address, port, codec, goofy session name, and even the SER rtpproxy attributes. I'll admit the remote end/proxy is doing some strange stuff - 100, 101, 183, then 180, etc but this does look like a strange bypass_media bug in FreeSWITCH. The RFC2833 payload type should be forwarded between the two remote endpoints without being modified by FreeSWITCH - just like all of the other SDP parameters (or any part of the SIP body, for that matter).
On Wed, Jun 15, 2011 at 5:09 PM, Michael Collins <msc@freeswitch.org> wrote:
QQ, I don't see that FreeSWITCH is doing anything incorrect here. According to RFC3264, the offerer (FreeSWITCH) sends an SDP and in the case of RTP, the answerer (GRSIP Gateway) must use the payload type offered, even if the answerer uses a different payload type when it sends a telephone-event. http://tools.ietf.org/html/rfc3264#section-6.1 Specifically near the end: "In the case of RTP, it MUST use the payload type numbers
from the offer, even if they differ from those in the answer."
Technically, FreeSWITCH isn't "changing" anything anyway. The originator of the call (Vox Callcontrol) is the one who chose PT 101 in the INVITE that it sent to FreeSWITCH. FS is just passing that along without modifying it. I think you need to contact the people running the gateway and make sure that they understand that they are not following RFC3264 if they're rejecting telephone-events in PT 101 simply because they prefer to send in PT 110. Also, if your Vox Callcontrol client has any configuration options then maybe you can tell it to use PT 110 for RFC2833 DTMFs. It is a bit of a workaround but this is SIP, so no one is expecting perfection. :) -MC
-- Kristian Kielhofner
_______________________________________________ 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
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
And FTR, this *is* on the wiki - I just didn't know about it. :) http://wiki.freeswitch.org/wiki/Channel_Variables#SDP_Manipulation (Last item) -MC On Wed, Jun 15, 2011 at 3:47 PM, Anthony Minessale < anthony.minessale@gmail.com> wrote:
However, there is not really any rule anywhere that states that bypass media will not touch the packets. All of the packets/sdp are still subject to SIP SOA model so if you pass a remote sdp into the lib, sofia will parse and modify it. The idea of bypass media is to bypass the media by advertising the proper codecs/addrs to arrange point to point media and there is no assurance that the packets will not be modified.
However,
There is a sofia param called "enable-soa" and a variable sip_enable_soa for per call basis which can be set to false to disable SIP SOA from sofia and most likely result in untouched exchange of SDP.
try this in your dialplan
<action application="set" data="bypass_media=true"/> <action application="export" data="sip_enable_soa=false"/>
On Wed, Jun 15, 2011 at 5:11 PM, Michael Collins <msc@freeswitch.org> wrote:
Ah, quite right. I'd file this in Jira. Hopefully it's not buried deep in the Sofia stack... -MC
On Wed, Jun 15, 2011 at 2:58 PM, Kristian Kielhofner <kris@kriskinc.com> wrote:
Michael,
This isn't an SDP offer/answer issue with FreeSWITCH. Even if there were underlying offer/answer issues between the endpoints FreeSWITCH is in bypass_media mode and it shouldn't care about the SDP because by definition (bypass_media) the SDP is "pass through" between the two remote endpoints.
The specific issue lies in the 183 w/ SDP at line 207. It has rfc2833 payload type 110. When FreeSWITCH forwards this to the other end (line 276) the SDP is untouched (expected with bypass_media) EXCEPT the rfc2833 payload type has been changed to 101 (unexpected with bypass_media). It does this again with the 200 OK. All other SDP params are passed through - media address, port, codec, goofy session name, and even the SER rtpproxy attributes. I'll admit the remote end/proxy is doing some strange stuff - 100, 101, 183, then 180, etc but this does look like a strange bypass_media bug in FreeSWITCH. The RFC2833 payload type should be forwarded between the two remote endpoints without being modified by FreeSWITCH - just like all of the other SDP parameters (or any part of the SIP body, for that matter).
On Wed, Jun 15, 2011 at 5:09 PM, Michael Collins <msc@freeswitch.org> wrote:
QQ, I don't see that FreeSWITCH is doing anything incorrect here.
According
to RFC3264, the offerer (FreeSWITCH) sends an SDP and in the case of RTP, the answerer (GRSIP Gateway) must use the payload type offered, even if the answerer uses a different payload type when it sends a telephone-event. http://tools.ietf.org/html/rfc3264#section-6.1 Specifically near the end: "In the case of RTP, it MUST use the payload type numbers
from the offer, even if they differ from those in the answer."
Technically, FreeSWITCH isn't "changing" anything anyway. The originator of the call (Vox Callcontrol) is the one who chose PT 101 in the INVITE that it sent to FreeSWITCH. FS is just passing that along without modifying it. I think you need to contact the people running the gateway and make sure that they understand that they are not following RFC3264 if they're rejecting telephone-events in PT 101 simply because they prefer to send in PT 110. Also, if your Vox Callcontrol client has any configuration options then maybe you can tell it to use PT 110 for RFC2833 DTMFs. It is a bit of a workaround but this is SIP, so no one is expecting perfection. :) -MC
-- Kristian Kielhofner
_______________________________________________ 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
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire
AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
_______________________________________________ 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
Hi All, Thank you all for spend time on this question. I has try use export sip_enable_soa=false, And It work perfectly. Thanks a lot. Respect for your work and your production. -Qingquan On Thu, Jun 16, 2011 at 7:29 AM, Michael Collins <msc@freeswitch.org> wrote:
And FTR, this *is* on the wiki - I just didn't know about it. :)
http://wiki.freeswitch.org/wiki/Channel_Variables#SDP_Manipulation (Last item)
-MC
On Wed, Jun 15, 2011 at 3:47 PM, Anthony Minessale < anthony.minessale@gmail.com> wrote:
However, there is not really any rule anywhere that states that bypass media will not touch the packets. All of the packets/sdp are still subject to SIP SOA model so if you pass a remote sdp into the lib, sofia will parse and modify it. The idea of bypass media is to bypass the media by advertising the proper codecs/addrs to arrange point to point media and there is no assurance that the packets will not be modified.
However,
There is a sofia param called "enable-soa" and a variable sip_enable_soa for per call basis which can be set to false to disable SIP SOA from sofia and most likely result in untouched exchange of SDP.
try this in your dialplan
<action application="set" data="bypass_media=true"/> <action application="export" data="sip_enable_soa=false"/>
On Wed, Jun 15, 2011 at 5:11 PM, Michael Collins <msc@freeswitch.org> wrote:
Ah, quite right. I'd file this in Jira. Hopefully it's not buried deep in the Sofia stack... -MC
On Wed, Jun 15, 2011 at 2:58 PM, Kristian Kielhofner <kris@kriskinc.com
wrote:
Michael,
This isn't an SDP offer/answer issue with FreeSWITCH. Even if there were underlying offer/answer issues between the endpoints FreeSWITCH is in bypass_media mode and it shouldn't care about the SDP because by definition (bypass_media) the SDP is "pass through" between the two remote endpoints.
The specific issue lies in the 183 w/ SDP at line 207. It has rfc2833 payload type 110. When FreeSWITCH forwards this to the other end (line 276) the SDP is untouched (expected with bypass_media) EXCEPT the rfc2833 payload type has been changed to 101 (unexpected with bypass_media). It does this again with the 200 OK. All other SDP params are passed through - media address, port, codec, goofy session name, and even the SER rtpproxy attributes. I'll admit the remote end/proxy is doing some strange stuff - 100, 101, 183, then 180, etc but this does look like a strange bypass_media bug in FreeSWITCH. The RFC2833 payload type should be forwarded between the two remote endpoints without being modified by FreeSWITCH - just like all of the other SDP parameters (or any part of the SIP body, for that matter).
On Wed, Jun 15, 2011 at 5:09 PM, Michael Collins <msc@freeswitch.org> wrote:
QQ, I don't see that FreeSWITCH is doing anything incorrect here.
According
to RFC3264, the offerer (FreeSWITCH) sends an SDP and in the case of RTP, the answerer (GRSIP Gateway) must use the payload type offered, even if the answerer uses a different payload type when it sends a telephone-event. http://tools.ietf.org/html/rfc3264#section-6.1 Specifically near the end: "In the case of RTP, it MUST use the payload type numbers
from the offer, even if they differ from those in the answer."
Technically, FreeSWITCH isn't "changing" anything anyway. The originator of the call (Vox Callcontrol) is the one who chose PT 101 in the INVITE that it sent to FreeSWITCH. FS is just passing that along without modifying it. I think you need to contact the people running the gateway and make sure that they understand that they are not following RFC3264 if they're rejecting telephone-events in PT 101 simply because they prefer to send in PT 110. Also, if your Vox Callcontrol client has any configuration options then maybe you can tell it to use PT 110 for RFC2833 DTMFs. It is a bit of a workaround but this is SIP, so no one is expecting perfection. :) -MC
-- Kristian Kielhofner
_______________________________________________ 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
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire
AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
_______________________________________________ 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
-- Using Gmail? Please read this important notice: http://www.fsf.org/campaigns/jstrap/gmail?40922.
I didn't know about this parameter either. Is it new? I'd argue that it should be enabled by default when bypass_media is in enabled. If not, it leaves open cases such as this one where you can't win - some parameters of the SDP will be changed but not others? If FreeSWITCH is completely rewriting the SDP and handling the media to account for differences in the RTP streams that's fine (normal media mode). If FreeSWITCH is rewriting some SDP params without handling the media it leaves the endpoints in a broken state that no one would ever want. In this case FreeSWITCH changed the SDP to say 2833 is payload type 101 when the RTP stream from the remote end would clearly have it at payload type 110! The endpoints would end up completely confused... I think this parameter has some purpose and I always enjoy having extra knobs to turn. However, it should be enabled by default when bypass_media is in use (to be disabled selectively by users in cases where they need to, for some reason). What about proxy_media? As far as I can tell the same thing would happen there (or worse). The SDP would (probably) get changed and the media would be proxied through FreeSWITCH but the RTP and SDP would not agree on payload type (same as now). From what it sounds like this soa parameter is not compatible with proxy_media (hands off SDP) so what would happen there? On Wed, Jun 15, 2011 at 7:29 PM, Michael Collins <msc@freeswitch.org> wrote:
And FTR, this *is* on the wiki - I just didn't know about it. :) http://wiki.freeswitch.org/wiki/Channel_Variables#SDP_Manipulation (Last item) -MC
-- Kristian Kielhofner
Certainly looks like a bug. Make sure you're running latest and open an issue on JIRA. On Tue, Jun 14, 2011 at 9:55 PM, qingquan luo <qingquan@globalroam.com> wrote:
Hi All, I use freeswitch to bridge one incoming call to other target phone number. I use bypass_media mode. So the rtp is not go through the freeswitch, By I notice that When LegB reply 183 or 200 SDP message. Freeswitch change it 2833 telephone-event payload type. and forwarding the message to caller. This make the caller use wrong dtmf payload type to send dtmf What wrong with that? How can fix it? Any information or help is welcome. information with "sofia global siptrace on" http://pastebin.freeswitch.org/16496 Thanks
Best Regards
Qingquan -- Using Gmail? Please read this important notice: http://www.fsf.org/campaigns/jstrap/gmail?40922.
_______________________________________________ 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)
-
Anthony Minessale
-
David Ponzone
-
Kristian Kielhofner
-
Michael Collins
-
qingquan luo