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

[Michael Collins]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20110615/de15dabc/attachment.html