Han an interesting scenario which was causing me some RTP issues - so while I was having those issues, I tried a couple things. I changed my DTMF on a Yealink phone from RFC2833 to be SIP INFO.
I did NOT change my extension DTMF Signalling on the extension - it is still RFC2833.
What I observed, is that Asterisk still sees the SIP INFO even when the extension is set to RFC2833.
So it worked - should it have worked? I have no RTP packets so there’s no way RFC2833 was somehow “leaking” through in the RTP stream. Basically trying to understand what I’m seeing here.
Question 1.
Does that mean the extension setting is ineffective? I’ve seen a LOT of people obsess over that setting over the years - OR does it mean that setting controlls what generation method would be used on that extensions tones were being generated on teh Asterisk side to send back to the device (i.e. if the extension was being used in some type of trunking scenario) ?
Question 2.
Many Asterisk / FreePBX notes / articles talk about “SIP INFO” - but not many of them seem to indicate anything about the INFO Type (DTMF-Relay / DTMF / Telephone-Event) or the DTMF Payload Type (which defaults to 101). Is anyone aware of any documentation related to asterisk or FreePBX that clarifies these fields for FreePBX or Asterisk?
Basically curious if those relate to any settings or if those defaults elsewhere should be noted / used if we see anything else on any other equipment, etc.
It helps to think of connections to the PBX as “independent but related”. Settings and the like need to reasonably match, but they can be directionally independent. Because of that, setting your setting on one end differently from the other end may or may not cause problems based on the device connected and what it is expecting/sending.
As to the payload types, there are quite a few good “Asterisk” books out there that talk to the different component parts of SIP protocol, but going back to the RFCs for SIP would probably be a better choice. Everything you’re going to find is going to be derived from the community’s negotiations that are codified there.
Thanks Dave - I’ve read a couple of the books over the years… but many of them seem at odds with reality or contradict one another - I’ve also taken a crack at the RFC’s - that’s not really the point here - just that the parameter while set on the extension doesn’t clearly (to me at least) indicate if it IS in fact only for touch tones sent back to the session client.
Many books for instance they refer to RFC2833 as “out of band” when in fact they use special RTP packets which are “in-band” but coded. http://www.ietf.org/rfc/rfc2833.txt
What it comes down to is:
I set an extension for RFC2833
I sent only SIP-INFO (which the extension was not configured for).
The process worked perfectly.
So… What is the setting for if anything / does it matter?
And for Q2, we seem to have a specific (non-editable) implementation of sip-info as a choice - the default values I’ve seen above SEEM to work - but they aren’t the values everyone seems to use - so maybe they should be documented?
People in forums often get hung up when someone has touchtone problems - I’ve seen people ask what settings were in use on the extension - and yet it doesn’t seem to matter.
It makes sense that it would matter more on upstream trunks (if I try to send RFC2833 and the carrier accepts only sip-info then they won’t understand my data).
