c=IN IP4 10.152.41.4^M
t=0 0^M
m=audio 15808 RTP/AVP 8 116^M
a=rtpmap:8 PCMA/8000^M
a=rtpmap:116 telephone-event/8000^M
a=fmtp:116 0-16^M
a=ptime:20^M
a=sendrecv^M
i checked with both rfc2833 and inband modes?
can any help on this?
Whatever sent that SDP is offering to accept RFC2833… There is no evidence one way or the other as to how Asterisk is actually configured or if and how it is receiving digits.
cant get you. can u pls be specific david. i am using asterisk-1.6. and provider is sending the dtmf which i have shown in the sdp sent earlier.
The above is an SDP offer or answer which negotiated DTMF. Without the full SIP trace it’s hard to get the full idea of what has actually happened. Additionally an “rtp set debug on” will show you when DTMF is actually received over RTP.
You’re also using a VERY old version of Asterisk which is no longer supported.
Asterisk 1.6 is well past end of life, although it shouldn’t make a difference.
Your log does not show anyone sending DTMF, It shows someone offering to receive it using RFC 2833 They are offering to receive it on a port that Asterisk wouldn’t normally use. Whilst I think there are bugs in that area in early versions of Asterisk, I think they only affect direct media… I think 1.6.1.0, at least can handle telephone events on ports other than 101 when direct media is not involved.
You need to provide your sip.conf.
I would also suggest that you use wireshark to capture the SIP and RTP and identify how the peer is actually sending RTP.
thanks for quick suggestions.
The asterisk same version was working fine earlier.
my sip.conf is as below
[general]
context=default
bindport=5060
rtptimeout=60
rtpholdtimeout=300
rtpkeepalive=5
bindaddr=10.152.41.4
srvlookup=no
qualify=yes
allowguest=yes
callcounter=yes
allowexternalinvites=yes
disallow=all
allow=all
externip=10.152.41.4
useragent=PBX
sdpsession=PBX
dtmfmode=inband
relaxdtmf=yes
canreinvite=no
;externip=10.152.41.4:5060
localnet=10.152.41.4/255.255.255.0
nat=yes
unable to attach the traces here. pls suggest
This will cause the RFC 2833 offer to be ignored. The calling party should fall back to something else, although it might be INFO. If it doesn’t fall back, I would expect you to have warnings about unknown codecs in your logs.
allowguest=yes is normally inadvisable on security grounds, and specifying an externip on the localnet is weird.
thanks david. i also checked with rfc2833.
havent tried with INFO.
i have below lines on my traces
"Non-codec capabilities (dtmf): us - 0x1
(telephone-event), peer - 0x1 (telephone-event), combined -
0x1 (telephone-event)"
i have uploaded traces in the below link
https://www.sendspace.com/file/3jryxe
i have installed the latest version of asterisk-13.7.2.
having same issue as addressed earlier.
my sip.conf now is as below
[general]
context=default
bindport=5060
rtptimeout=300
rtpholdtimeout=300
rtpkeepalive=5
bindaddr=10.152.41.4
srvlookup=no
qualify=yes
callcounter=yes
allowexternalinvites=yes
disallow=all
allow=all
externhost=10.152.41.4
externaddr=10.152.41.4:5060
defaultip=10.152.41.4
useragent=PBX
sdpsession=PBX
dtmfmode=rfc2833
relaxdtmf=yes
canreinvite=no
localnet=10.152.41.4/255.255.255.0
nat=no
pls help if any changes needed to get the dtmf.
Anyone came across the above issue?
I also checked with dtmfmode as “auto”. still had same issue.
Atlast Its resolved.
i found that it was the connectivity problem with my bearer ip, which is sending the RTP to my system.
Thanks for all ur suggestion.