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