SIP - SDP handshake - DTMF error

Dear all,

Please find below a scenario that has problems on an Asterisk implementation I am currently developing.

The signaling below corresponds to an outgoing call from Asterisk to Provider (my mobile phone). The architecture uses also an Opensips between the Asterisk and the IMS of the Provider; however, Opensips is just a proxy that forwards the messages.

My configuration (Asterisk version 17.7) includes PJSIP channels that are setup using

dtmf_mode = auto
disallow = all
allow = alaw
allow = ulaw
direct_media = yes
inband_progress = yes
language = en

The problem arises on capturing DTMF pressed on my mobile phone. Please note that the error exists only on outgoing calls. I have run many scenarios of incoming calls towards Asterisk and there are no issues (note: on incoming, the DTMFs are inband as RTP g711a packets)

The detailed SIP signaling of the outgoing call is the following:

Asterisk sends to Provider INVITE with

m=audio 14638 RTP/AVP 8 0 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv

Provider replies with 183 PROGRESS with

m=audio 10688 RTP/AVP 8 103
b=AS:80
b=RS:612
b=RR:1837
a=rtpmap:8 PCMA/8000
a=rtpmap:103 telephone-event/16000
a=fmtp:103 0-15
a=ptime:20
a=maxptime:150
a=sendrecv

and then provider connects with 200 OK (no SPD parameters).

Now, provider wants to re-negotiate SDP via UPDATE SDP with

m=audio 10688 RTP/AVP 8 101
b=AS:80
b=RS:2000
b=RR:6000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15,32,36
a=ptime:20
a=maxptime:50
a=rtcp-xr
a=sendrecv

and Asterisk accepts the re-negotiation with 200 OK and parameters

m=audio 14638 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv

New UPDATE SDP from provider with data

m=audio 10688 RTP/AVP 8 103
b=AS:80
b=RS:612
b=RR:1837
a=rtpmap:8 PCMA/8000
a=rtpmap:103 telephone-event/16000
a=fmtp:103 0-15
a=ptime:20
a=maxptime:150
a=sendrecv

which Asterisk accepts via 200 OK with parameters

m=audio 14638 RTP/AVP 8
a=rtpmap:8 PCMA/8000
a=ptime:20
a=maxptime:150
a=sendrecv

Regarding RTP signaling, Asterisk receives and sends RTP packets of payload type 8, which are processed correctly. Therefore, the audio communication between the two parties is fine.

However, when I press DTMF on my mobile phone, Provider sends the DTMF as RTP Events of Type 103

User Datagram Protocol, Src Port: 10688, Dst Port: 14638
Real-Time Transport Protocol
[Stream setup by SDP (frame 3089)]
10.. .... = Version: RFC 1889 Version (2)
..0. .... = Padding: False
...0 .... = Extension: False
.... 0000 = Contributing source identifiers count: 0
1... .... = Marker: True
Payload type: DynamicRTP-Type-103 (103)
Sequence number: 4787
[Extended sequence number: 70323]
Timestamp: 2522661136
Synchronization Source identifier: 0x880e5608 (2282640904)
Payload: 010a0050
VSS Monitoring Ethernet trailer, Source Port: 0

From my point of view, since Asterisk has not accepted (on UPDATE SDP signaling) the dynamic payload type 103 (or its parameters), it does not wait for such RTP packets. Thus, it ignores the DTMF sent and processes them as simple audio
[Dec 25 10:10:28] VERBOSE[76381][C-00000020] res_rtp_asterisk.c: Got RTP packet from xxx.xxx.xxx.xxx:xxxxx (type 103, seq 012095, ts 856064752, len 000004)

The outcome is that I cannot perform Background() or WaitExten() on Asterisk’s dialplan.

My main question is if the above SIP signaling is correct.

Asterisk has not responded positively to the dynamic type 103; however, Provider selects this type to send the DTMF as specific RTP events. Is this allowed?

If this signaling is valid and acceptable, what is the correct Asterisk configuration, in order to capture the DTFM sent as RTP of Dynamic Type 103?

Thank you in advance for your time and effort.

There is no configuration to allow it, as Asterisk does not currently support telephone-event at a rate of 16000. It only supports 8000. This is why the 200 OK does not negotiate it. Code would have to be written to allow it to work.

1 Like

Also, SDP isn’t actually a negotiation. On the exchanges you have shown, the provider can only send telephony events with codec number 101 and rate 8000. It is Asterisk that will be unable to send telephony events to the provider. If the provider is sending with codec 103, I believe it is broken, as Asterisk hasn’t offered to accept codec 103.

However, shouldn’t Asterisk be sending Unacceptable Here, in response to the 16000 rate? Or is in band always acceptable?

Asterisk would treat it as an unknown codec, so it would effectively be ignored. Unacceptable would only occur if there was nothing in common.

1 Like

OK, I understand that Asterisk cannot handle 16KHz rate and therefore does not accept a codec with this rate.
However, is the above signaling correct according to RFC standards? Can the Provider send the DTMFs as a dynamic event, although Asterisk has not accepted it?

It can’t send media that uses a payload type not listed in the SDP sent by Asterisk and expect the receiver to know what to do with it.

As the number is dynamic, it can’t even expect the receiver to know what the format is.

2 Likes

OK, it is now clear.
Thank you all for your answers.