Can anyone explain me what is most important difference between rfc2833 dtmfmode`` and the other options at dtmfmode? And what exactly happens when I use nat setting as yes and in the same time also the qualify to yes option. I mention that I use these settings at sip type=friend subscriber and iax type=friend subscriber.
For SIP, at least, those settings relate to a channel driver (chan_sip) that is not supported by the core project. It only has community support, which means bugs are unlikely to be fixed. If possible, you should be using chan_pjsip, instead.
The advantage of rfc 2833 is that it is standardised and pretty much universally supported. Use it unless the other side doesn’t support it. It causes special start and stop tone packets to be sent in the media stream,which identify the digit or signal, rather than representing the audio tone.
inband will not work with most codecs, as they are designed for speech, but inband tries to send the tones using codec used for speech.
info sends DTMF in the signalling channel, and I seem to remember that there is no official standard.
nat=yes is deprecated.
nat=* is rarely needed; it should not be needed in the common case of Asterisk behind NAT and an ITSP on the public network.
The defaults of auto_comedia, and auto_force_rport should handle many of the other cases where NAT is used and the peer doesn’t properly compensate. They turn into the following two if Asterisk sees evidence that the peer is inside NAT, but Asterisk is outside.
comedia causes Asterisk to change the media destination address if it finds that the source IP address is not that at which the SDP says the peer will accept media. Only one party can, effectively, do this, as media has to get through in order for the correct address to be learned.
force_rport causes Asterisk to pretend that the rport parameter was set on the Via header, and to send replies to the actual source address, rather than that specified in the header.
qualify and nat parameters are not related. qualify causes OPTIONS to be sent periodically, to test the connectivity. yes causes it to use the default value for the acceptable round trip time. The measured round trip time is used to adjust timers used to detect lost responses. Because it results in frequent transmissions, it may help keep transient firewall openings and NAT rules, in routers, live.
At least for chan_sip, type=friend is usually the wrong setting It causes Asterisk to prefer a match on the From: user field over the IP address, on INVITEs. This removes one hurdle for toll fraudsters, as they can use their real source IP address when trying to inject INVITEs, so don’t have to dead reckon responses, and it isn’t too difficult to guess reasonable extension numbers. Also, if you have the common case (although not good for security) of having the device name the same as the caller ID number for a device, and you use the same numbers on both ends of a trunk, calls get matched against the corresponding local device, rather than the trunk, and, typically, there is an authentication failure.
Except in special cases, you should use type=peer, which only matches INVITEs against IP addresses, but will still match REGISTER against the sip.conf section name.
1 Like
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.