[asterisk-dev] DTMF detection and generation code

[Vahan Yerkanian]

Dan Evans wrote:
> RFC2833 is just trying to reproduce the key press without making 
> assumptions, and in particular it is NOT asumming that length has no 
> relevance.  In my experience, Asterisk's 'normalization' of RFC2833 
> input when it relays DTMF's reduces the robustness of the input and in 
> effect, adds to the probability of dropped DTMF key presses.

Exactly. And if the route contains several Asterisk servers, you can 
wave your DTMFs goodbye.

> Asterisk now relays a six packet sequence of RCF2833 events for each DTMF 
> received (it used to send even fewer), regardless of the number of input 
> events.  I have captured a lot of relayed DTMF events, and when events 
> are dropped, most often they are the leading events in the sequence.  If 
> the leading three are dropped, the DTMF key is effectively dropped.  If 
> Asterisk simply relayed all the events it received, it would at least 
> not be a contributer to the reduction in reliability.

On some of my installations, I have an ugly kludge which increases the 
number of packets sent to 15, it was the only solution with the used 
gateways. This depends on the network topology and the jitter.

> Of course, the situation is different when Asterisk needs to originate 
> the event; still, if possible, I think it should try to replicate the 
> duration.  But in the relay situation, it should definitely send what it 
> receives.

Fully agree. IMHO, the best aproach would be using packet dumps to learn 
how the most popular gateway hardware processes the DTMF, possibly even 
introducing a per-user/per-peer configuration option to change 
Asterisk's DTMF behavior to match the other side. E.g. dtmfstyle=sipura 
  or dtmfstyle=cisco, etc. Might be the best way in our non-ideal world.

Vahan