This is probably an issue with DTMF tone detection. It may help if I provide a little background information.
There are three types of DTMF transmission within SIP: RFC 2833, Info, and Inband. RFC 2833 has become the method most commonly used although technically speaking RFC2833 has been replaced by RFC 4733, but it is still generally referred to as RFC 2833.
When using RFC 2833, the DTMF is sent in its own stream specified by an RTP payload type. RTP payload type numbers 0-95 represent static type entries, you can look them up at iana.org (
https://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml)
Technically, with the static payload types you do not need the a=rtpmap and a=fmtp (fmtp just means format parameter) attributes in the SDP because we all know what they are. For example, RTP payload Type 8 is PCMA at 8000 bits per second so the attribute a=rtpmap:8 PCMA/8000 is not required (You will always find it present though).
Because the payload type number space is relatively small and cannot accommodate assignments for all existing and future encodings, numbers 96-127 are allocated as dynamic. What this means in practice is that when you specify one of these dynamic payload types, you must also say what it actually is, using the attributes in the SDP.
So when you see 101 you will also see attributes to describe what a 101 is. For example:
a = rtpmap:101 telephone-event/8000
This tells us that payload type 101 is a telephone event at a bit rate of 8000 bits per second. A telephone event can cover lots of things like On-Hook, Off-Hook etc. not just DTMF keys. When you see the attribute:
a=fmtp:101 0-15
This tells us that events 0-15 will be carried in the payload, these are DTMF named events:
Keys 0 - 9 encoded as events 0 - 9
Key * encoded as event 10
Key # encoded as event 11
Keys A - D encoded as events 12 - 15
The Info method is where the DTMF key is transmitted not as audio or as a separate RTP stream but as a SIP INFO message, example below:
Code:
INFO sip:0123456789@sbc2-eu-c2.a2es.uk:5061;transport=tls SIP/2.0
From: <sip:alice@a2es.uk>;tag=b5f428a
To: <sip:bob@a2es.uk>;tag=5543
Call-ID: s38764532938@10.11.12.13
CSeq: 3 INFO
Content-Length: 24
Content-Type: application/dtmf-relay
Signal=5
Duration=160
Inband, as its name suggests, is exactly that, the DTMF tones are sent within the audio stream of the call, in this situation the inbound audio stream must be continuously scanned and any detected tones acted upon.
We have no control over what is sent in from the PSTN. DTMF transmission is predominantly RFC 2833 but, in the UK, we do still see Inband signalling. Inband signalling is often seen on calls from older analogue lines and from some international routes. On some occasions we will even see a mix of both RFC 2833 and Inband on the same call.
On occasions where an IVR is not reacting to inband DTMF, you can use a dp_tools function called start_dtmf in a dialplan to enable in-band DTMF detection.
https://freeswitch.org/confluence/display/FREESWITCH/mod_dptools:+start_dtmf
I have successfully used the following additional condition group on an inbound route to start DTMF detection if I can't see any evidence of RFC 2833 in the SDP body of the INVITE.
Code:
<condition field="destination_number" expression="^(0123456789)$"/>
<condition field="${switch_r_sdp}" expression="a=rtpmap:(\d+)\stelephone-event/8000" break="never">
<action application="set" data="sip_h_X-dtmf_rtp_pstn_payload=$1"/>
<anti-action application="set" data="sip_h_X-dtmf_rtp_pstn_payload=None"/>
<anti-action application="start_dtmf" data=""/>
I hope that all makes sense.
Adrian.
