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

[Kristian Kielhofner]

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