SIP.js DTMF RTP not working

[Jeremy Fall]

Hi all,

We are attempting to send DTMF via RTP using the SessionDescriptionHandler.sendDTMF() function.  But, it's throwing an error that it's not available:

logger-factory.js:85 DOMException: Failed to execute 'insertDTMF' on 'RTCDTMFSender': The 'canInsertDTMF' attribute is false: this sender cannot send DTMF.

Looking at the INVITE, there is no rtpmap:101 feature being advertised, so I tried to append it on UserAgentOptions.sessionDescriptionHandlerFactoryOptions:

        userAgentOptions.sessionDescriptionHandlerFactoryOptions = {

            modifiers: [(description) => {

                console.info(description);

                description.sdp += "\na=rtpmap:101 telephone-event/8000";

                return Promise.resolve(description);

            }]

        };

But, that makes no difference on the INVITE message.  In fact, when you modify anything on sessionDescriptionHandlerFactoryOptions it appears to be completely ignored.

Any ideas?

[Eric Green]

Does the platform you are using support in band DTMF?

[Matt McGinnis]

Hi Eric,

Yes, the platform does support DTMF relay. The problem we are running into is that one of our carrier partners only supports rtpmap 101 and the SIP.js client in our web browser offers up 126. Thus we are unable to negotiate the proper DTMF payload type to interoperate even though we support dynamic ranges. Other carriers support 126 and dynamic payload, just not this one.

Is there a way to configure SIP.js to offer rtpmap 101 on the offer for outbound calls?

[Eric Green]

I see. I am not aware of any way to force webrtc to use rtpmap 101 for DTMF. 

Potentially you could write a modifier. The modifier would have to modify the SDP between createOffer and setLocalDescription. The modifier would have to remove the DTMF that is in the dynamic range and add it to 101 - removing anything else that is potentially there. No guarantee any of this would work and it feels pretty fragile IMO.

You could do an invite w/o SDP. This flips the offer/answer model in the SDP so that the far end (in your case the carrier) can offer whatever they want and then the browser will just answer it. Your carrier should send an offer with DTMF wherever they want and the browsers should be pretty happy with it.

The last option is you can gateway the media using something like rtpengine, or gateway the entire call using something like freeswitch. You should probably be doing this anyway to deal with wonkiness of carriers or clients. Configure your infrastructure to deal with all the wonkiness and make the changes that you need to make to be compatible with all carriers and clients.