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

[Michael Collins]

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