And FTR, this *is* on the wiki - I just didn't know about it. :)

http://wiki.freeswitch.org/wiki/Channel_Variables#SDP_Manipulation

(Last item)

-MC

On Wed, Jun 15, 2011 at 3:47 PM, Anthony Minessale <anthony.minessale@gmail.com> wrote:

However, there is not really any rule anywhere that states that bypass
media will not touch the packets.
All of the packets/sdp are still subject to SIP SOA model so if you
pass a remote sdp into the lib, sofia will parse and modify it.
The idea of bypass media is to bypass the media by advertising the
proper codecs/addrs to arrange point to point media and there is no
assurance that the packets will not be modified.

However,

There is a sofia param called "enable-soa" and a variable
sip_enable_soa for per call basis which can be set to false to disable
SIP SOA from sofia and most likely result in untouched exchange of
SDP.

try this in your dialplan

<action application="set" data="bypass_media=true"/>
<action application="export" data="sip_enable_soa=false"/>

On Wed, Jun 15, 2011 at 5:11 PM, Michael Collins <msc@freeswitch.org> wrote:
> 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@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@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
>
>
> _______________________________________________
> 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
>
>

--
Anthony Minessale II

FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/
Twitter: http://twitter.com/FreeSWITCH_wire

AIM: anthm
MSN:anthony_minessale@hotmail.com
GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888@conference.freeswitch.org
googletalk:conf+888@conference.freeswitch.org
pstn:+19193869900

_______________________________________________
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

_______________________________________________
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