[Freeswitch-users] in bypass_media mode, 2833 payload type modified by freeswitch!

[qingquan luo]

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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at hotmail.com
>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>> IRC: irc.freenode.net #freeswitch
>>
>> FreeSWITCH Developer Conference
>> sip:888 at conference.freeswitch.org
>> googletalk:conf+888 at conference.freeswitch.org
>> pstn:+19193869900
>>
>> _______________________________________________
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users at 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 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20110616/b5ad0be7/attachment-0001.html