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.