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.