I sent only SIP-INFO (which the extension was not configured for). 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.
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. Is anyone aware of any documentation related to asterisk or FreePBX that clarifies these fields for FreePBX or Asterisk?īasically 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. 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). if the extension was being used in some type of trunking scenario) ? Basically trying to understand what I’m seeing here.ĭoes 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. 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. What I observed, is that Asterisk still sees the SIP INFO even when the extension is set to RFC2833. I did NOT change my extension DTMF Signalling on the extension - it is still RFC2833. I changed my DTMF on a Yealink phone from RFC2833 to be SIP INFO. Han an interesting scenario which was causing me some RTP issues - so while I was having those issues, I tried a couple things.
0 kommentar(er)
