And FTR, this *is* on the wiki - I just didn&#39;t know about it. :)<div><br></div><div><a href="http://wiki.freeswitch.org/wiki/Channel_Variables#SDP_Manipulation">http://wiki.freeswitch.org/wiki/Channel_Variables#SDP_Manipulation</a></div>
<div>(Last item)</div><div><br></div><div>-MC<br><br><div class="gmail_quote">On Wed, Jun 15, 2011 at 3:47 PM, Anthony Minessale <span dir="ltr">&lt;<a href="mailto:anthony.minessale@gmail.com">anthony.minessale@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">However, there is not really any rule anywhere that states that bypass<br>
media will not touch the packets.<br>
All of the packets/sdp are still subject to SIP SOA model so if you<br>
pass a remote sdp into the lib, sofia will parse and modify it.<br>
The idea of bypass media is to bypass the media by advertising the<br>
proper codecs/addrs to arrange point to point media and there is no<br>
assurance that the packets will not be modified.<br>
<br>
However,<br>
<br>
There is a sofia param called &quot;enable-soa&quot; and a variable<br>
sip_enable_soa for per call basis which can be set to false to disable<br>
SIP SOA from sofia and most likely result in untouched exchange of<br>
SDP.<br>
<br>
try this in your dialplan<br>
<br>
&lt;action application=&quot;set&quot; data=&quot;bypass_media=true&quot;/&gt;<br>
&lt;action application=&quot;export&quot; data=&quot;sip_enable_soa=false&quot;/&gt;<br>
<div><div></div><div class="h5"><br>
<br>
<br>
<br>
On Wed, Jun 15, 2011 at 5:11 PM, Michael Collins &lt;<a href="mailto:msc@freeswitch.org">msc@freeswitch.org</a>&gt; wrote:<br>
&gt; Ah, quite right. I&#39;d file this in Jira. Hopefully it&#39;s not buried deep in<br>
&gt; the Sofia stack...<br>
&gt; -MC<br>
&gt;<br>
&gt; On Wed, Jun 15, 2011 at 2:58 PM, Kristian Kielhofner &lt;<a href="mailto:kris@kriskinc.com">kris@kriskinc.com</a>&gt;<br>
&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; Michael,<br>
&gt;&gt;<br>
&gt;&gt;  This isn&#39;t an SDP offer/answer issue with FreeSWITCH.  Even if there<br>
&gt;&gt; were underlying offer/answer issues between the endpoints FreeSWITCH<br>
&gt;&gt; is in bypass_media mode and it shouldn&#39;t care about the SDP because by<br>
&gt;&gt; definition (bypass_media) the SDP is &quot;pass through&quot; between the two<br>
&gt;&gt; remote endpoints.<br>
&gt;&gt;<br>
&gt;&gt;  The specific issue lies in the 183 w/ SDP at line 207.  It has<br>
&gt;&gt; rfc2833 payload type 110.  When FreeSWITCH forwards this to the other<br>
&gt;&gt; end (line 276) the SDP is untouched (expected with bypass_media)<br>
&gt;&gt; EXCEPT the rfc2833 payload type has been changed to 101 (unexpected<br>
&gt;&gt; with bypass_media).  It does this again with the 200 OK.  All other<br>
&gt;&gt; SDP params are passed through - media address, port, codec, goofy<br>
&gt;&gt; session name, and even the SER rtpproxy attributes.  I&#39;ll admit the<br>
&gt;&gt; remote end/proxy is doing some strange stuff - 100, 101, 183, then<br>
&gt;&gt; 180, etc but this does look like a strange bypass_media bug in<br>
&gt;&gt; FreeSWITCH.  The RFC2833 payload type should be forwarded between the<br>
&gt;&gt; two remote endpoints without being modified by FreeSWITCH - just like<br>
&gt;&gt; all of the other SDP parameters (or any part of the SIP body, for that<br>
&gt;&gt; matter).<br>
&gt;&gt;<br>
&gt;&gt; On Wed, Jun 15, 2011 at 5:09 PM, Michael Collins &lt;<a href="mailto:msc@freeswitch.org">msc@freeswitch.org</a>&gt;<br>
&gt;&gt; wrote:<br>
&gt;&gt; &gt; QQ,<br>
&gt;&gt; &gt; I don&#39;t see that FreeSWITCH is doing anything incorrect here. According<br>
&gt;&gt; &gt; to<br>
&gt;&gt; &gt; RFC3264, the offerer (FreeSWITCH) sends an SDP and in the case of RTP,<br>
&gt;&gt; &gt; the<br>
&gt;&gt; &gt; answerer (GRSIP Gateway) must use the payload type offered, even if the<br>
&gt;&gt; &gt; answerer uses a different payload type when it sends a telephone-event.<br>
&gt;&gt; &gt; <a href="http://tools.ietf.org/html/rfc3264#section-6.1" target="_blank">http://tools.ietf.org/html/rfc3264#section-6.1</a><br>
&gt;&gt; &gt; Specifically near the end:<br>
&gt;&gt; &gt; &quot;In the case of RTP, it MUST use the payload type numbers<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;    from the offer, even if they differ from those in the answer.&quot;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Technically, FreeSWITCH isn&#39;t &quot;changing&quot; anything anyway. The originator<br>
&gt;&gt; &gt; of<br>
&gt;&gt; &gt; the call (Vox Callcontrol) is the one who chose PT 101 in the INVITE<br>
&gt;&gt; &gt; that it<br>
&gt;&gt; &gt; sent to FreeSWITCH. FS is just passing that along without modifying it.<br>
&gt;&gt; &gt; I think you need to contact the people running the gateway and make sure<br>
&gt;&gt; &gt; that they understand that they are not following RFC3264 if they&#39;re<br>
&gt;&gt; &gt; rejecting telephone-events in PT 101 simply because they prefer to send<br>
&gt;&gt; &gt; in<br>
&gt;&gt; &gt; PT 110. Also, if your Vox Callcontrol client has any configuration<br>
&gt;&gt; &gt; options<br>
&gt;&gt; &gt; then maybe you can tell it to use PT 110 for RFC2833 DTMFs. It is a bit<br>
&gt;&gt; &gt; of a<br>
&gt;&gt; &gt; workaround but this is SIP, so no one is expecting perfection. :)<br>
&gt;&gt; &gt; -MC<br>
&gt;&gt;<br>
&gt;&gt; --<br>
&gt;&gt; Kristian Kielhofner<br>
&gt;&gt;<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; FreeSWITCH-users mailing list<br>
&gt;&gt; <a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
&gt;&gt; <a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
&gt;&gt; UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
&gt;&gt; <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; FreeSWITCH-users mailing list<br>
&gt; <a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
&gt; <a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
&gt; UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
&gt; <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
&gt;<br>
&gt;<br>
<br>
<br>
<br>
</div></div>--<br>
Anthony Minessale II<br>
<br>
FreeSWITCH <a href="http://www.freeswitch.org/" target="_blank">http://www.freeswitch.org/</a><br>
ClueCon <a href="http://www.cluecon.com/" target="_blank">http://www.cluecon.com/</a><br>
Twitter: <a href="http://twitter.com/FreeSWITCH_wire" target="_blank">http://twitter.com/FreeSWITCH_wire</a><br>
<br>
AIM: anthm<br>
<a href="mailto:MSN%3Aanthony_minessale@hotmail.com">MSN:anthony_minessale@hotmail.com</a><br>
GTALK/JABBER/<a href="mailto:PAYPAL%3Aanthony.minessale@gmail.com">PAYPAL:anthony.minessale@gmail.com</a><br>
IRC: <a href="http://irc.freenode.net" target="_blank">irc.freenode.net</a> #freeswitch<br>
<br>
FreeSWITCH Developer Conference<br>
<a href="mailto:sip%3A888@conference.freeswitch.org">sip:888@conference.freeswitch.org</a><br>
<a href="mailto:googletalk%3Aconf%2B888@conference.freeswitch.org">googletalk:conf+888@conference.freeswitch.org</a><br>
pstn:+19193869900<br>
<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>