I have a customer with an old Asterisk 13 (chan_sip) server and have been experiencing DTMF issues.
PCAP file shows the DTMF entry made by the SIP Peer is being passed to the incoming caller channel. Using either DTMFMode=info or DTMFmode=RFC2833 has the same result.
It has been a back an forth with the voice carrier and they come back to me and said to change the following:
a=rtpmap:96 telephone-event/8000 – Suggested change for rtpmap:101
What setting should I change that will allow the a=rtpmap:96 to change to a=rtpmap:101?
You would need to change the source code. In any case, I thought that 101 was the default for chan_sip. 96 upwards are dynamically allocated codes. Anything that assumes a fixed assignment is broken.
This SDP only applies if you have dtmfmode=rfc2833.
I’m not really sure I understand what you are saying here. Please provide the actual logs demonstrating this, or, at least, the precise evidence, from those logs.
Hi
Below is what I mean by the pcap trace is showing the DTMF signal sent to the carrier:
I have done about 6 different tests and every INVITE does have the RTPMAP=101.
v=0
o=PortaSIP 41688168 758663966 IN IP4 102.33.217.165
s=-
t=0 0
m=audio 17620 RTP/AVP 8 101
c=IN IP4 102.33.217.165
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
You are correct in that 101 is the default for Chan_sip.
I am going back to the carrier, they are missing something on their equipment.
You appear to be receiving inband DTMF.
I misread the original message as saying you needed to change from 96 to 101. 101 is where chan_sip always starts, and you can’t change it. If things are breaking because of this, the provider’s system needs to be fixed, as there is no fixed number for telephone events. the a= line is there to tell the other side that which number is actually being used.
You should not get any reference to telephone events in the SDP if you request dtmfmode=info
You haven’t shown how they responded. They should have responded with the same number as in the request.
If they are broken, I’d suggest setting dtmfmode to inband.
I seem to remember that chan_pjsip uses 96 as its first dynamic payload type, and you should be using chan_pjsip, as chan_sip is no longer supported by the official Asterisk project.
I have DTMFmode=info on the trunk to the carrier, on the SIP Peer and the end device.
I will test setting the trunk to the carrier to DTMFmode=inband and see if it makes any different.
