Have RTPEngine play DTMF over 101 telephone-event

[Vlad Paiu]

Hello,

In my current OpenSIPS script, at offer time I am passing the inject-DTMF flag and then at a later time I am calling the 'play DTMF' functionality.

The SDP both in the offer and the answer contains telephone-event.

In looks like RTPEngine is putting the PCMU codec in transcode mode, and chosing to play DTMF in-band as PCMU : 

rtpengine[90912]: DEBUG: [4933aaf64d9457a2...@10.57.16.84:5060/gK04b60017/1]: [codec] Created transcode context for PCMU/8000 (0) -> PCMU/8000 (0) with DTMF output -1

rtpengine[90912]: DEBUG: [4933aaf64d9457a2...@10.57.16.84:5060]: [core] DTMF injection: Using PT 0/0 -> 0 (-1), SSRC 407945e7

Is there any way to make RTPEngine do the playing of DTMF over the telephone-event ? I have tried passing transcode=telephone-event flags at offer time, but with no luck.

Regards,

Vlad

[Richard Fuchs]

It should do that already automatically. Are you on a recent/LTS version? What else does the log say?

Cheers

[Vlad Paiu]

Thanks for the reply.

I'm on 11.5.1 - should I consider updating ?

Attaching full debug logs for the above callid.

[Richard Fuchs]

On 12/12/2024 14.15, Vlad Paiu wrote:
> Thanks for the reply.
>
> I'm on 11.5.1 - should I consider updating ?
> Attaching full debug logs for the above callid.

The log is missing the SDP contents.

11.5 is fine as long as you're on the latest patch level. 12.5 would be
better, but both are LTS and so shouldn't have known issues.

Cheers

[Vlad Paiu]

the offer is : 

o=root 1024909126 1024909126 IN IP4 8.8.8.8.
s=Asterisk PBX 11.25.0-f97c578e.
c=IN IP4 8.8.8.8.
t=0 0.
m=audio 16334 RTP/AVP 0 101.
a=rtpmap:0 PCMU/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=sendrecv.
a=rtcp:16335

the answer is : 

o=Sonus_UAC 134364 842362 IN IP4 9.9.9.9.
s=SIP Media Capabilities.
c=IN IP4 9.9.9.9.
t=0 0.
m=audio 61410 RTP/AVP 0 101.
a=rtpmap:0 PCMU/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
a=sendrecv.
a=ptime:20.

I still see rtpengine playing over PT 0: 


rtpengine[90912]: DEBUG: [1cb924b66d8d0c6c...@10.40.8.42:5060/gK08e7e4cd/1]: [codec] Using passthrough handler for telephone-event/8000 (101) with DTMF 101, CN -1
rtpengine[90912]: DEBUG: [1cb924b66d8d0c6c...@10.40.8.42:5060/gK08e7e4cd/1]: [codec] Using passthrough handler with new SSRC for telephone-event/8000

... 
{ "code": "*", "volume": "5", "duration": "1000", "pause": "100", "call-id": "1cb924b66d8d0c6c...@10.40.8.42:5060", "received-from": [ "IP4", "1
0.40.8.42" ], "from-tag": "as5e8057e5", "to-tag": "gK08e7e4cd", "command": "play DTMF" }
/var/log/syslog:57532:Dec 16 10:51:18 voicetest-rtp01 rtpengine[90912]: DEBUG: [1cb924b66d8d0c6c...@10.40.8.42:5060]: [core] DTMF injection: Using PT 0/0 -> 0 (-1), SSRC e58b6d4

Unsure if there's specific rtpengine flags I need to pass to make DTMF just be played over telephone-event in case it's present in both offer&answer ?

[Vlad Paiu]

Don't mean to spam, disregard the old example - a more fresh example would be 

offer ( called with  "flags": [ "symmetric", "inject-DTMF", "codec-transcode-telephone-event", "SDES-off" ] )
v=0.
o=root 1674705706 1674705706 IN IP4 10.57.16.51.
s=Asterisk PBX 11.25.0-d54f11fc.
c=IN IP4 10.57.16.51.
t=0 0.
m=audio 13448 RTP/AVP 0 101.

a=rtpmap:0 PCMU/8000.
a=rtpmap:0 PCMU/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.

a=silenceSupp:off - - - -.
a=ptime:20.
a=sendrecv.

answer ( called with "flags": [ "symmetric", "inject-DTMF", "codec-transcode-telephone-event", "trust-address", "SDES-off" ] ), replied with RTPEngine port 5048 : 

v=0.
o=Sonus_UAC 512528 434278 IN IP4 10.200.2.20.
s=SIP Media Capabilities.
c=IN IP4 8.8.8.8.
t=0 0.
m=audio 12072 RTP/AVP 0 101.

a=rtpmap:0 PCMU/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
a=sendrecv.
a=ptime:20

Now the debug logs from play dtmf look a bit better : 

/var/log/syslog:154948:Dec 16 13:06:30 voicetest-rtp01 rtpengine[2180989]: DEBUG: [1c682c39781f4d58...@10.57.16.51:5060]: [core] Unconfirming peer address for local 8.8.8.8:5048 (DTMF playback)
/var/log/syslog:154949:Dec 16 13:06:30 voicetest-rtp01 rtpengine[2180989]: DEBUG: [1c682c39781f4d58...@10.57.16.51:5060]: [core] DTMF injection: Using PT 0/0 -> 0 (101), SSRC 86ec9388
/var/log/syslog:154950:Dec 16 13:06:30 voicetest-rtp01 rtpengine[2180989]: DEBUG: [1c682c39781f4d58...@10.57.16.51:5060]: [core] Injecting RFC DTMF event #10 for 300 ms (vol -5) from 'gK049457fb' (media #1) into RTP PT 0, SSRC 86ec9388
/var/log/syslog:154951:Dec 16 13:06:30 voicetest-rtp01 rtpengine[2180989]: DEBUG: [1c682c39781f4d58...@10.57.16.51:5060]: [transcoding] DTMF event state change: code 42, volume -5, TS 31200
/var/log/syslog:154952:Dec 16 13:06:30 voicetest-rtp01 rtpengine[2180989]: DEBUG: [1c682c39781f4d58...@10.57.16.51:5060]: [core] DTMF DSP code event: event 42, volume -5
/var/log/syslog:154953:Dec 16 13:06:30 voicetest-rtp01 rtpengine[2180989]: DEBUG: [1c682c39781f4d58...@10.57.16.51:5060]: [transcoding] DTMF event state change: code 0, volume 0, TS 33440
/var/log/syslog:154954:Dec 16 13:06:30 voicetest-rtp01 rtpengine[2180989]: DEBUG: [1c682c39781f4d58...@10.57.16.51:5060]: [core] DTMF DSP end event: event 42, volume -5, duration 2240

Still, when tracing the full RTP stream in wireshark,  I do not see anything for rtp.p_type == 101 , as if RTPEngine is not originating any DTMF over telephone-event.

Pretty stuck here.

[Vlad Paiu]

As I'm debugging through the RTPEngine code, it seems the DTMF gen on the caller->callee flow is bound to having caller->callee rtp in the first place.. if the caller side is not generating any RTP at all ( total lack of RTP packets ), is there any way for RTPEngine to just inject the DTMF ?

[Richard Fuchs]

On 17/12/2024 09.25, Vlad Paiu wrote:
> As I'm debugging through the RTPEngine code, it seems the DTMF gen on
> the caller->callee flow is bound to having caller->callee rtp in the
> first place.. if the caller side is not generating any RTP at all (
> total lack of RTP packets ), is there any way for RTPEngine to just
> inject the DTMF ?

No that is not supported right now. I believe there is a comment in the
code indicating that this still needs to be implemented. You should also
see an error or warning message in the log if that is the reason for the
lack of DTMF.

Cheers