[playDTMF] RTPEngine keep sending DTMF tone instead of negotiated RFC 2833

[xquanluu]

RTPEngine Version: Version: 11.4.1.4+0~mr11.4.1.4 git-HEAD-e6f05259

We have a case that Rtpengien <---> SBC and SDP negotiated on RFC 2833.

We request Rtpengine to inject DTMF:

Nov 17 13:17:45 ip-10-0-35-194 rtpengine[2761360]: INFO: [827a545e-ffee-123c-5f96-028d3aae2477]: [control] Received command 'play DTMF' from 127.0.0.1:6000 Nov 17 13:17:45 ip-10-0-35-194 rtpengine[2761360]: DEBUG: [827a545e-ffee-123c-5f96-028d3aae2477]: [control] Dump for 'play DTMF' from 127.0.0.1:6000: { "call-id": "827a545e-ffee-123c-5f96-028d3aae2477", "code": "1", "command": "play DTMF", "duration": "100", "from-tag": "XZ32g93v93vQm", "record call": "no", "replace": [ "origin", "session-connection" ] }

But RTP engine keep sending DTMF Tone

Nov 17 13:17:45 ip-10-0-35-194 rtpengine[2761360]: DEBUG: [827a545e-ffee-123c-5f96-028d3aae2477]: [core] Injecting RFC DTMF event #1 for 100 ms (vol -9999) from 'XZ32g93v93vQm' (media #1) into RTP PT 0, SSRC 9d5ede25

Do you have any idea on that ? dtmf.log

I attached here Rtpengine log.

[zenichev]

@xquanluu I'm not sure I get your question correct. Can you elaborate what exactly happens? You claim that rtpengine keeps on sending DTMF tone, means stuck for an infinite sending of the tone, or what?

From the given log I don't see the issue for the moment.

[xquanluu]

Hi @zenichev

Thank you so much for looking into this issue.

I'm expecting that rtpengine should send DTMF on telephony-event (RFC 2833) instead of DTMF tone, both caller and callee already accepted telephony-event as a channel for DTMF but rtpengine still use DTMF tone.

[zenichev]

@xquanluu Which flags do you provide for the offer and answer during negotiations?

You might try to use the inject-DTMF flag during establishing the call, so during the offer/answer. This will mark the call for DTMF injection (it has to be used in both offer and answer messages).

For more information see: https://rtpengine.readthedocs.io/en/latest/ng_control_protocol.html#play-dtmf-message

[xquanluu]

yes I did enable that flag in flags. you can chec below log:

And I have tried with inject-DTMF and the one mentioned in document inject DTMF, both are having same result

dtmf_log1.txt

Offer: Nov 20 08:57:01 ip-10-0-35-194 rtpengine[2939310]: DEBUG: [s1caankdfogdjgjme3cp]: [control] Dump for 'offer' from 127.0.0.1:7000: { "DTLS": "off", "ICE": "remove", "SDES": "off", "call-id": "s1caankdfogdjgjme3cp", "command": "offer", "direction": [ "public", "private" ], "flags": [ "media handover", "port latching", "inject DTMF" ], "from-tag": "7rreb2tp8s", "record call": "no", "replace": [ "origin", "session-connection" ], "rtcp-mux": [ "accept" ], "sdp": "v=0#015#012o=- 1789375246040709354 2 IN IP4 127.0.0.1#015#012s=-#015#012t=0 0#015#012a=group:BUNDLE 0#015#012a=extmap-allow-mixed#015#012a=msid-semantic: W ...

Anser:

Nov 20 08:57:03 ip-10-0-35-194 rtpengine[2939310]: DEBUG: [9c4e7183-0225-123d-db8f-028d3aae2477]: [control] Dump for 'answer' from 127.0.0.1:6000: { "DTLS": "off", "ICE": "remove", "SDES": "off", "call-id": "9c4e7183-0225-123d-db8f-028d3aae2477", "command": "answer", "flags": [ "single codec", "inject DTMF" ], "from-tag": "p2yrXpr0KK50F", "record call": "no", "replace": [ "origin", "session-connection" ], "rtcp-mux": [ "demux" ], "sdp": "v=0#015#012o=xhoaluu2 2701 119 IN IP4 192.168.1.4#015#012s=Talk#015#012c=IN IP4 192.168.1.4#015#012t=0 0#015#012m=audio 49776 RTP/AVP 0 8 101#015#012a=rtpmap:101 telephone-event/8000#015#012a=rtcp:5 ...

[zenichev]

@xquanluu could be a bug, not sure right now. I will have to check this out. I will keep you posted.

[xquanluu]

Thanks @zenichev a lot.

I'm waiting for hearing back from you.

[rfuchs]

There's a mismatch in payload types for telephone-event in the SDPs involved.

There's two answers, one from mgc7S0pSS1rUr and then a second one from BRmuh6e

The first one correctly accepts payload type 126 as telephone-event/8000 but the second one uses type 101 for telephone-event/8000 which was never offered. So from rtpengine's POV there is no DTMF payload type present.

[xquanluu]

Thank you so much @rfuchs

Let me test again and make sure that both legs have same type for telephone-event. I will keep you updated shortly

[xquanluu]

Thanks @rfuchs a lot for your help.

It's working now. I'm closing this ticket