Dtmf detection issue asterisk 11.5

Asterisk Asterisk Support
1

Hi:

I recently updated Elastix 2.3 to 2.4, which upgraded asterisk from 1.8.11.0 to 11.5.0.

I have a sip trunk to my IP provider Telmex. It happens now that when I receive a call from another provider, DTMF tones are not detected. It works fine with calls from Telmex. Previous version was working fine with any inbound call.

After sip and rtp debug I found that in 11.5.0 I receive from Telmex payload type 97 for DTMF and I reply with payload type 101 for DTMF on incoming calls. This causes that peer sends payload 101 for DTMF but I’m expecting 97, so DTMF is not detected.

In 1.8.11 I reply with payload type 97 for incoming calls, although I use 101 in outgoing calls.

How can this be fixed?

This is rtp debug output for both versions:

Here call starts

<— SIP read from UDP:10.8.53.18:62593 —>
INVITE sip:7431088@192.168.150.2:5060 SIP/2.0
Via: SIP/2.0/UDP 10.8.53.18:5060;branch=z9hG4bK31685162B
Remote-Party-ID: sip:3002206941@10.8.53.18;party=calling;screen=no;privacy=off
From: sip:3002206941@10.8.53.18;tag=BC46FB48-1CB2
To: sip:7431088@192.168.150.2
Date: Mon, 28 Oct 2013 18:02:07 GMT
Call-ID: E503BFD9-3F3111E3-9D34CE53-23FA0091@10.8.53.18
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE: 3600
Cisco-Guid: 3842148233-1060180451-2637090387-0603586705
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1382983327
Contact: sip:3002206941@10.8.53.18:5060
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 69
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 410

v=0
o=CiscoSystemsSIP-GW-UserAgent 5103 6184 IN IP4 10.8.53.18
s=SIP Call
c=IN IP4 10.8.53.18
t=0 0
m=audio 17490 RTP/AVP 8 0 18 4 101 97 19
c=IN IP4 10.8.53.18
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:4 G723/8000
a=fmtp:4 bitrate=6.3;annexa=yes
a=rtpmap:101 G726-32/8000
a=rtpmap:97 telephone-event/8000 <— Payload type 97 is proposed for dtmf signaling
a=fmtp:97 0-15
a=rtpmap:19 CN/8000
<------------->

Response from 11.5.0

<— Reliably Transmitting (NAT) to 10.8.53.18:62593 —>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.8.53.18:5060;branch=z9hG4bK31685162B;received=10.8.53.18;rport=62593
From: sip:3002206941@10.8.53.18;tag=BC46FB48-1CB2
To: sip:7431088@192.168.150.2;tag=as2ee2b77a
Call-ID: E503BFD9-3F3111E3-9D34CE53-23FA0091@10.8.53.18
CSeq: 101 INVITE
Server: FPBX-2.8.1(11.5.0)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Session-Expires: 3600;refresher=uas
Contact: sip:7431088@192.168.150.2:5060
Content-Type: application/sdp
Require: timer
Content-Length: 237

v=0
o=root 1487456071 1487456071 IN IP4 192.168.150.2
s=Asterisk PBX 11.5.0
c=IN IP4 192.168.150.2
t=0 0
m=audio 15982 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000 <— Look at this!!
a=fmtp:101 0-16
a=ptime:20
a=sendrecv

<------------>
This is rtp TYPE 101 not detecting DTMF:

[Oct 28 13:03:26] VERBOSE[3982][C-00000035] res_rtp_asterisk.c: Sent RTP packet to 10.8.53.18:17490 (type 00, seq 063767, ts 109280, len 000160)
[Oct 28 13:03:26] VERBOSE[3982][C-00000035] res_rtp_asterisk.c: Got RTP packet from 10.8.53.18:17490 (type 101, seq 023155, ts 2225409544, len 000004)
[Oct 28 13:03:26] VERBOSE[3982][C-00000035] res_rtp_asterisk.c: Sent RTP packet to 10.8.53.18:17490 (type 00, seq 063768, ts 109440, len 000160)
[Oct 28 13:03:26] VERBOSE[3982][C-00000035] res_rtp_asterisk.c: Got RTP packet from 10.8.53.18:17490 (type 101, seq 023156, ts 2225409544, len 000004)
[Oct 28 13:03:26] VERBOSE[3982][C-00000035] res_rtp_asterisk.c: Sent RTP packet to 10.8.53.18:17490 (type 00, seq 063769, ts 109600, len 000160)
[Oct 28 13:03:26] VERBOSE[3982][C-00000035] res_rtp_asterisk.c: Got RTP packet from 10.8.53.18:17490 (type 101, seq 023157, ts 2225409544, len 000004)
[Oct 28 13:03:26] VERBOSE[3982][C-00000035] res_rtp_asterisk.c: Sent RTP packet to 10.8.53.18:17490 (type 00, seq 063770, ts 109760, len 000160)

Comparison Response from 1.8.11

<— Reliably Transmitting (NAT) to 10.8.53.18:50501 —>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.8.53.18:5060;branch=z9hG4bK3192414B7;received=10.8.53.18;rport=50501
From: sip:3002206941@10.8.53.18;tag=BD53A964-21A5
To: sip:7431088@192.168.150.2;tag=as4676be19
Call-ID: E454B823-3F5A11E3-A5B5CE53-23FA0091@10.8.53.18
CSeq: 101 INVITE
Server: FPBX-2.8.1(1.8.11.0)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Contact: sip:7431088@192.168.150.2:5060
Content-Type: application/sdp
Content-Length: 236

v=0
o=root 2136984952 2136984952 IN IP4 192.168.150.2
s=Asterisk PBX 1.8.11.0
c=IN IP4 192.168.150.2
t=0 0
m=audio 13308 RTP/AVP 0 97
a=rtpmap:0 PCMU/8000
a=rtpmap:97 telephone-event/8000 <— Look at this
a=fmtp:97 0-16
a=ptime:20
a=sendrecv

<------------>
rtp response TYPE 97, detecting DTMF

[Oct 28 17:57:44] VERBOSE[10275] res_rtp_asterisk.c: Got RTP packet from 10.8.53.18:24674 (type 97, seq 011704, ts 2366239904, len 000004)
[Oct 28 17:57:44] VERBOSE[10275] res_rtp_asterisk.c: Got RTP RFC2833 from 10.8.53.18:24674 (type 97, seq 011704, ts 2366239904, len 000004, mark 1, event 00000005, end 0, duration 00160)
[Oct 28 17:57:44] DEBUG[10275] res_rtp_asterisk.c: - RTP 2833 Event: 00000005 (len = 4)
[Oct 28 17:57:44] VERBOSE[10275] res_rtp_asterisk.c: Sent RTP packet to 10.8.53.18:24674 (type 00, seq 005184, ts 065120, len 000160)
[Oct 28 17:57:44] VERBOSE[10275] res_rtp_asterisk.c: Got RTP packet from 10.8.53.18:24674 (type 97, seq 011705, ts 2366239904, len 000004)
[Oct 28 17:57:44] VERBOSE[10275] res_rtp_asterisk.c: Got RTP RFC2833 from 10.8.53.18:24674 (type 97, seq 011705, ts 2366239904, len 000004, mark 0, event 00000005, end 0, duration 00320)
[Oct 28 17:57:44] DEBUG[10275] res_rtp_asterisk.c: - RTP 2833 Event: 00000005 (len = 4)
[Oct 28 17:57:44] VERBOSE[10275] res_rtp_asterisk.c: Sent RTP packet to 10.8.53.18:24674 (type 00, seq 005185, ts 065280, len 000160)
[Oct 28 17:57:44] VERBOSE[10275] res_rtp_asterisk.c: Got RTP packet from 10.8.53.18:24674 (type 97, seq 011706, ts 2366239904, len 000004)
[Oct 28 17:57:44] VERBOSE[10275] res_rtp_asterisk.c: Got RTP RFC2833 from 10.8.53.18:24674 (type 97, seq 011706, ts 2366239904, len 000004, mark 0,

There is another issue with alaw codec in 11.5.0. I disabled this codec in my trunk because there is no sound with some providers. Perhaps this has the same cause (i.e. sending rtp type 00 when the other end is expecting type 08). I have not documented this bug yet because it is a production system and there is no time enough for troubleshooting.

I got back to 1.8.11 and will stay there while this issue is solved.

Best Regards.

I’d appreciate your comments.

D. Alvarez

2

There is a recent bug report for this on issues.asterisk.org/jira/browse/ASTERISK-22789

However your traces do not show a bug. It is only a SHOULD violation not a MUST violation to respond with a different payload type, and there are circumstances (which don’t apply here) where it would actually be necessary to respond with a different payload type.

Unless the peer is sending the telephone events with payload type 101, it is the one that is at fault. Payload types and codecs represent what the user agent expects to receive.

You should probably “me too” the bug report, which should increase its priority, but you would have a better case if you could show that the remote party is not at fault.

The existing bug report does contain a case where it is actually violating the standards.

3

David:

Thank yo very much for your answer.

It’s quite difficult to convince the other providers (there are more than 5 main providers in my country) that they are wrong even when they send payload 97 with previous Asterisk version. It seems that my provider doesn’t mind with the 101 as it sends 97 for dtmf.

When I receive calls from my provider it works fine. Problem is with bridged calls from other providers. They send the payload that my system reports when answering calls. If it reports 97 they will send 97, and 101 when 101 is reported. Perhaps symmetry is required in these cases.

Something similar happens when I allow alaw.

My provider recommended to recompile rtp.c and change dtmf payload to 97, but if I do so, there is no way to continue with automatic updates.

Best Regards

4

Please remember that this is a peer support forum. It is not a good way of reaching anyone who might fix the problem.

5

David:

What is the right way to report this kind of problems?

Best Regards

6

In this case, as there is already a bug report covering a more serious case of this issue (although in that case there is clearly a bug), the correct process is to add a “me too” comment onto that bug report (URI already given). Generally the more people reporting a problem with the Digium supported part of Asterisk, the higher is going to be the priority of fixing it. If you can demonstrate your case is actually a bug, that would be better, but still you need to add to the existing report.

If your problem had existed in isolation, as you have no evidence of a bug, you would either need to gather evidence that the problem was due to Asterisk, (i.e… that the telephone events were arriving with the payload type in the SDP sent by Asterisk, but Asterisk was ignoring them, rather than that the other system was ignoring Asterisk’s selection of payload type), in which case you would need to submit a bug report on issues.asterisk.org/jira/, with all the supporting log files, or you would need to raise the issue as a feature request on the developer mailing list, or on the developer IRC channel. (You could also look for past statements that the intent was to treat the SHOULD , in the specification, as a MUST.)

7

David:

I got a JIRA account and added a comment on the issue. It is exactly what is happening to me.

Thank you very much!!

P.S I’d still have to document the alaw issue, perhaps it has the same cause…