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.

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@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!