Ah, quite right. I'd file this in Jira. Hopefully it's not buried deep in the Sofia stack...<div><br></div><div>-MC<br><br><div class="gmail_quote">On Wed, Jun 15, 2011 at 2:58 PM, Kristian Kielhofner <span dir="ltr"><<a href="mailto:kris@kriskinc.com">kris@kriskinc.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Michael,<br>
<br>
This isn't an SDP offer/answer issue with FreeSWITCH. Even if there<br>
were underlying offer/answer issues between the endpoints FreeSWITCH<br>
is in bypass_media mode and it shouldn't care about the SDP because by<br>
definition (bypass_media) the SDP is "pass through" between the two<br>
remote endpoints.<br>
<br>
The specific issue lies in the 183 w/ SDP at line 207. It has<br>
rfc2833 payload type 110. When FreeSWITCH forwards this to the other<br>
end (line 276) the SDP is untouched (expected with bypass_media)<br>
EXCEPT the rfc2833 payload type has been changed to 101 (unexpected<br>
with bypass_media). It does this again with the 200 OK. All other<br>
SDP params are passed through - media address, port, codec, goofy<br>
session name, and even the SER rtpproxy attributes. I'll admit the<br>
remote end/proxy is doing some strange stuff - 100, 101, 183, then<br>
180, etc but this does look like a strange bypass_media bug in<br>
FreeSWITCH. The RFC2833 payload type should be forwarded between the<br>
two remote endpoints without being modified by FreeSWITCH - just like<br>
all of the other SDP parameters (or any part of the SIP body, for that<br>
matter).<br>
<div class="im"><br>
On Wed, Jun 15, 2011 at 5:09 PM, Michael Collins <<a href="mailto:msc@freeswitch.org">msc@freeswitch.org</a>> wrote:<br>
> QQ,<br>
> I don't see that FreeSWITCH is doing anything incorrect here. According to<br>
> RFC3264, the offerer (FreeSWITCH) sends an SDP and in the case of RTP, the<br>
> answerer (GRSIP Gateway) must use the payload type offered, even if the<br>
> answerer uses a different payload type when it sends a telephone-event.<br>
> <a href="http://tools.ietf.org/html/rfc3264#section-6.1" target="_blank">http://tools.ietf.org/html/rfc3264#section-6.1</a><br>
> Specifically near the end:<br>
> "In the case of RTP, it MUST use the payload type numbers<br>
><br>
> from the offer, even if they differ from those in the answer."<br>
><br>
> Technically, FreeSWITCH isn't "changing" anything anyway. The originator of<br>
> the call (Vox Callcontrol) is the one who chose PT 101 in the INVITE that it<br>
> sent to FreeSWITCH. FS is just passing that along without modifying it.<br>
> I think you need to contact the people running the gateway and make sure<br>
> that they understand that they are not following RFC3264 if they're<br>
> rejecting telephone-events in PT 101 simply because they prefer to send in<br>
> PT 110. Also, if your Vox Callcontrol client has any configuration options<br>
> then maybe you can tell it to use PT 110 for RFC2833 DTMFs. It is a bit of a<br>
> workaround but this is SIP, so no one is expecting perfection. :)<br>
> -MC<br>
<br>
</div>--<br>
<font color="#888888">Kristian Kielhofner<br>
</font><div><div></div><div class="h5"><br>
_______________________________________________<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
</div></div></blockquote></div><br></div>