SOLVED DTMF # key missing

[ewdpb]

Hey all.

I need some guidance on how to troubleshoot a problem with DTMF. I have an IVR app that uses # as termination key when collecting digits from the user. It all works through my voip.ms trunks but when I connect through a SIP trunk with Audiocodes the pound (#) is just not recognized. On Wireshark traces and freeswitch logs I can confirmed that I do not receive the pound.

I notice that when the call comes through the Audiocodes SIP trunk, I get:

switch_core_media.c:5508 Set telephone-event payload to 97@8000
switch_core_media.c:5909 sofia/internal/anonymous@192.168.abc.xxx Set 2833 dtmf send payload to 97 recv payload to 97

While for my voip.ms trunk (or a direct registered endpoint) I get:

switch_core_media.c:5508 Set telephone-event payload to 101@8000
sofia/internal/4001@mydomain.labs.com:5060 Set 2833 dtmf send payload to 101 recv payload to 101

The payload type 101 to 97 is the only difference I can see.So, I am not sure I am right but I was guessing that if I can get payload type 101 on the Audicodes trunk I should be OK.

Does it make sense?

Is there anyway I can force my SIP trunk to negotiate in the SIP profile to use 101?

Am I barking up the right tree here?

Thanks!

 

[ewdpb]

I actually just figured I could force my endpoint to use Payload Type 97. I tested and it actually worked (I got the # key). So, that is probably not the thing I should be looking into.

Any idea on what to look at would be really welcome.

 

[Adrian Fretwell]

Just quoting the payload type when the type is in the dynamic payload range is meaningless, let me try to explain...

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 (or 97) you will also see attributes to describe what a 101 (or 97) is. For example:

a = rtpmap:101 telephone-event/8000

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

So:

m = audio 12345 RTP/AVP 8 101
a = rtpmap:8 PCMA/8000
a = rtpmap:101 telephone-event/8000
a = fmtp:101 0-15
a = sendrecv

is just as valid and means the same thing as

m = audio 12345 RTP/AVP 8 97
a = rtpmap:8 PCMA/8000
a = rtpmap:97 telephone-event/8000
a = fmtp:97 0-15
a = sendrecv

I hope that makes things a little clearer for you.

 

[ewdpb]

Hi @Adrian Fretwell . Thanks very much for takinf the time to reply in such detail. Yes, it all makes sense. I thought the PT had something to do but it foes not. In the end, we found out that it was an Alcatel switch the one not sendinf the # at all to Audiocodes in the first place.

In any case, this was very educative. Thanks again!

 

[gking77]

I had this issue with AudioCodes MediaPack devices before. Try lowering the gain levels a bit in your Tel Profile and IP profile. I found that sometimes the default gain is too high and can provide unstable DTMF on the analog line.

 

[gking77]

If you are using AudioCodes IP phone, obviously my comment is no help. But for analog media packs, seen that issue many times.

 

[ewdpb]

Thank you @gking77 . These are IP phones. Thank you for taking the time to reply though, that is always very much appreciated.