[Freeswitch-users] payload type mismatch with bridge command

[John Narduchi]

I simplified this a bit by taking the node IVR app out of the equation and
am able to replicate the same behavior with a simple xml dialplan.

<action application="answer"/>
<action application="sleep" data="500"/>
<action application="playback" data="conference/Welcome.wav"/>
<action application="sleep" data="500"/>
<action application="set" data="bypass_media=true"/>
<action application="bridge" data="sofia/external/$1 at 10.10.10.10"/>

Obviously i'm missing something stupid here. I have combed the docs but
can't seem to figure out the config i need to fix this scenario.

After the bridge command executes and the reinvites are sent out to the two
endpoints renegotiating the new media IP taking FS out of the media path, A
leg has the telephone-event attribute that came in on the initial invite,
in my case 96 but the B leg goes out on attribute 101. Causing DMTF not
work after bridge. Any input on this would be much appreciate. Thanks!

On Tue, Aug 1, 2017 at 5:01 PM John Narduchi <johnnarduchi at gmail.com> wrote:

> Hello, question about a 2833 DTMF situation I'm running into. We run a IVR
> in node.js using the outbound event socket. The node IVR answers the call,
> captures some digits from caller and then bridges with bypass_media=true
> the b leg out to a conferencing server, taking freeswitch out of the media
> path and all works well except.. for one scenario.
>
> When we receive telephone-events/8000 on a attribute other than 101 we end
> up with a payload type mismatch on a and b leg.
>
> With the bridge command the b leg always seems to offer what is specified
> in the rfc2833-pt setting of corresponding sip_profile.
>
> My question is, is there a way to configure FS to offer telephone-event on
> the same attribute in the b leg that came in on initial invite of a leg
> with bridge command on a answered call? Or possibly renegotiate the payload
> type if needed at time of bridge command? If so any examples for that.
>
> Sorry my SIP knowledge is not the best so please forgive if i am missing
> something here. Configs are vanilla and tested on latest FS version 1.6.19.
>
> Thanks!
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20170803/e72b2cd8/attachment.html>