I am investigating one issue on our production system where the customer complained that DTMF didn’t work. Since it is not the direct rtp from where the call was initiated. One thing which I confirmed that the SDP was negotiated with 101 telephone event.
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute Fieldname: rtpmap
Media Format: 101
MIME Type: telephone-event
Sample Rate: 8000
Media Attribute (a): fmtp:101 0-16
Media Attribute Fieldname: fmtp
Media Format: 101 [telephone-event]
Media format specific parameters: 0-16
But when the device started to sent the RTP events, it came with payload type 116 which was not the same as negotiated but its not against the RFC2833 and the Asterisk box should honour it without any issue.
Based on my findings, whiel the DTMF issue was reported when I checked the asterisk logs there is one thing which is unusual.
[Dec 6 10:33:18] DEBUG[24419][C-00001ebf] chan_sip.c: Bogus frame of format ‘g719’ received from ‘SIP/43-94.247.102.134-00001f0b’!
I am not sure why Asterisk is not able to interpret the correct binding and think this is related to DTMF issue reported. Can someone guide me there is anything needed on Asterisk side to avoid this?
You haven’t shown the full SDP negotiation from both sides, but each side can’t just use a dynamic payload without having negotiated it in the SDP. You also haven’t stated what version of Asterisk.
Thanks for your response. Please see the complete SDP information for the 200OK message which was negotiated. The Asterisk version is mentioned in the in Session Name.
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): root 20145291 20145292 IN IP4 x.x.x.x
Session Name (s): Asterisk PBX 13.38.3
Connection Information (c): IN IP4 x.x.x.x
Time Description, active time (t): 0 0
Media Description, name and address (m): audio 18618 RTP/AVP 8 101
Media Attribute (a): rtpmap:8 PCMA/8000
Media Attribute Fieldname: rtpmap
Media Format: 8
MIME Type: PCMA
Sample Rate: 8000
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute Fieldname: rtpmap
Media Format: 101
MIME Type: telephone-event
Sample Rate: 8000
Media Attribute (a): fmtp:101 0-16
Media Attribute Fieldname: fmtp
Media Format: 101 [telephone-event]
Media format specific parameters: 0-16
Media Attribute (a): ptime:20
Media Attribute Fieldname: ptime
Media Attribute Value: 20
Media Attribute (a): maxptime:150
Media Attribute Fieldname: maxptime
Media Attribute Value: 150
Media Attribute (a): sendrecv
[Generated Call-ID: 3dc27e6943689efd7c289df52347a053@x.x.x.x:5060]
Below are the RTP packets which were mark and I saw the Payload Type was 116 which I believe is the reason for Bogus frame of format G719. I need your thoughts about it as I think that is the reason DTMF was not detected.
You were asked for the complete negotiation (although negotiation is not a particular accurate description), not just one side. In particular, one needs to see what you sent to know what payload types could be incoming. There can be additional, or even missing, codec types in your offer.
Generally it is best to use the raw message, e.g as logged by Asterisk itself. The output you have provide includes some interpretation, possibly from wireshark.
Neither chan_sip, not Asterisk 13 are currently supported. End of life for Asterisk 13 was over three years ago. You should reproduce on chan_pjsip, and at least Asterisk 20. (However first impressions are that this is something that has to be fixed outside of Asterisk.)
Your logs are over-redacted. I don’t think x.x.x.x always refers to the same address. We need to be able to distinguish between addresses, and to to know what each address represents (and whether private, public, or shared). Typically we might need to know which was Asterisk, which was each of the phones involved, which was the ITSP, and which, if any, was a router.
G.719 has no default payload type number, and you are only offering to accept G.711 (A-law), and telephony events (RFC 2833). Whilst it would be interesting to see the full contents of the problem RTP packets, I would suggest the only reasonable assumptions are code corruption or hardware failure.
It’s so long since Asterisk 13 was last touched that it is most unlikely that a simple bug would not have been reported, and no-one will be interested in debugging a RAM corruption issue in and end of life version.
We understand that the Asterisk 13 is out of support. Basically what we wanted to know if someone has ever observed RFC2833 DTMF being misinterpreted as G719 which we saw in this scenario?