<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=koi8-r">
<META content="MSHTML 6.00.3790.2817" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>Hi folks,</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Currently I'm playing with broken DTMFs in
chan_h323 and got next minds to discuss (as I remember I shown my minds
about VL-DTMF somewhere already, before 1.4 was released). This is my
story.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Old days we had AST_FRAME_DTMF message only, which
denotes transmission of single DTMF digit regardless of its
duration.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Immediately before 1.4 beta was released a code for
support variable-length DTMF (VL-DTMF) which intended to transmit DTMF
digits and care about its duration as accurate as possible. To support
this feature, two new types of frame was added - AST_FRAME_DTMF_BEGIN and
AST_FRAME_DTMF_END with meaningful names. But some channels and old
versions of Asterisk don't have support for such events, and some channels have
options to provide optional DTMF tone duration in single event (example of such
channels includes chan_sip and chan_h323). To resolve compatibility problems,
old AST_FRAME_DTMF was associated to AST_FRAME_DTMF_END (and frame code assigned
to AST_FRAME_DTMF_END was equal to "old days" AST_FRAME_DTMF). To pass duration
information, channel driver should translate this value to number of
8KHz samples occuped by tone and assign to .samples field. When channel
which transmits DTMF provides support for VL-DTMF, Asterisk should
expand single AST_FRAME_DTMF_END<duration> frame into two frames -
AST_FRAME_DTMF_BEGIN and AST_FRAME_DTMF_END which distanced in time by
<duration> milliseconds.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>In real life first impelentation of VL-DTMF was a
bit far from description shown above. Internally (within Asterisk core) only
AST_FRAME_DTMF_BEGIN and AST_FRAME_DTMF_END frames are in use. If a channel
which receives DTMF from endpoint and needs to pass it through Asterisk do not
have <duration> information or just have single frame, AST_FRAME_DTMF,
Asterisk core provides "emulation" to generate fake AST_FRAME_DTMF_BEGIN frame
and delays AST_FRAME_DTMF (which is equal to AST_FRAME_DTMF_END) for
<duration> (pointed by channel driver or assumed by Asterisk from default
value) milliseconds. Channel driver which don't support for transmission VL-DTMF
to client, uses only AST_FRAME_DTMF (=AST_FRAME_DTMF_END) event. As result, we
have:</FONT></DIV>
<DIV><FONT face=Arial size=2>1) to provide time lag in distribution of single
AST_FRAME_DTMF event between boxes (because each box will delay it for
<duration> milliseconds);</FONT></DIV>
<DIV><FONT face=Arial size=2>2) API isn't allow to pass <duration>
information on transmission of DTMF_END event;</FONT></DIV>
<DIV><FONT face=Arial size=2>3) applications still use AST_FRAME_DTMF
(=AST_FRAME_DTMF_END) so they reacts to keypress after key
unpressed.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Which sort of problems follow from above? A
few:</FONT></DIV>
<DIV><FONT face=Arial size=2>1) we always make a delay when peer channel isn't
support dual-event scheme;</FONT></DIV>
<DIV><FONT face=Arial size=2>2) peer channel should calculate DTMF duration
itself (for SIP INFO/H.323 signal events) by remembering times of DTMF_BEGIN and
DTMF_END events;</FONT></DIV>
<DIV><FONT face=Arial size=2>3) applications get AST_FRAME_DTMF_BEGIN
transparently (because they react to AST_FRAME_DTMF only), which could cause
some side effects (for example, Echo() application).</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>In the near time ago there was update for VL-DTMF
code to support end-to-end passing of single-event DTMFs with support of
passing <duration> information together with
AST_FRAME_DTMF/AST_FRAME_DTMF_END event. So, positions 1) and 2) of problem list
shown above should be solved, BUT we still have position 3) opened.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>To resolve last issue, application should react on
first DTMF event (BEGIN) only and silently ignore second event (END). This can
be easily done by re-assigning AST_FRAME_DTMF from AST_FRAME_DTMF_END to
AST_FRAME_DTMF_BEGIN. How it will impact existing applications? Lets
examine...</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>When both channels support two-event
scheme:</FONT></DIV>
<DIV><FONT face=Arial size=2>BEGIN<fake duration> -> bridge ->
BEGIN<fake duration></FONT></DIV>
<DIV><FONT face=Arial size=2>END<real duration> -> bridge ->
END<real duration></FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>When transmitting channel support single-event
scheme with duration:</FONT></DIV>
<DIV><FONT face=Arial size=2>BEGIN<fake duration> -> bridge ->
/dev/null</FONT></DIV>
<DIV><FONT face=Arial size=2>END<real duration> -> bridge ->
AST_FRAME_DTMF<real duration></FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>When transmitting channel support single-event
scheme but don't support duration bypassing (applications are sort of such
objects):</FONT></DIV>
<DIV><FONT face=Arial size=2>BEGIN<fake duration> -> bridge ->
AST_FRAME_DTMF<fake duration></FONT></DIV>
<DIV><FONT face=Arial size=2>END<real duration> -> bridge ->
/dev/null</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>When receiving channel support single-event scheme
with duration but transmitting channel support two-event scheme (bridge
generates END event itself):</FONT></DIV>
<DIV><FONT face=Arial size=2>BEGIN<duration> -> bridge ->
BEGIN<duration></FONT></DIV>
<DIV><FONT face=Arial
size=2>...audio...
-> bridge (generates END<duration>)->
END<duration></FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>When receiving channel support single-event scheme
without duration but transmitting channel support two-event scheme (bridge
generates END event itself too and replaces missing duration as
pre-defined value, for example, 100 ms):</FONT></DIV>
<DIV><FONT face=Arial size=2>BEGIN<0> -> bridge (<0> ->
<std duration>) -> BEGIN<std duration></FONT></DIV>
<DIV><FONT face=Arial size=2>...audio... ->
bridge (generates END<std duration>) -> END<std
duration></FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>When both channels support single-event scheme with
duration:</FONT></DIV>
<DIV><FONT face=Arial size=2>BEGIN<duration> -> bridge ->
BEGIN<duration></FONT></DIV>
<DIV><FONT face=Arial size=2>...audio... -> bridge (generates
END<duration>) -> /dev/null</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>When receiving channel support single-event scheme
with duration while transmitting support single-event too but without
duration:</FONT></DIV>
<DIV><FONT face=Arial size=2>BEGIN<duration> -> bridge ->
BEGIN<duration> (transmitting channel just ignores <duration>
value)</FONT></DIV>
<DIV><FONT face=Arial size=2>...audio... -> bridge (generates
END<duration>) -> /dev/null</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>When transmitting channel support single-event
scheme without duration while transmitting side support full single-event
scheme:</FONT></DIV>
<DIV><FONT face=Arial size=2>BEGIN<0> -> bridge (<0> ->
<std duration>) -> BEGIN<std duration></FONT></DIV>
<DIV><FONT face=Arial size=2>...audio... -> bridge (generates END<std
duration>) -> /dev/null</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>When both channels supports single-event scheme
without duration:</FONT></DIV>
<DIV><FONT face=Arial size=2>BEGIN<0> -> bridge (<0> ->
<std duration>) -> BEGIN<std duration> (<std duration>
value ignored)</FONT></DIV>
<DIV><FONT face=Arial size=2>...audio... -> bridge (generates END<std
duration>) -> /dev/null</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>When bridge placed into "DTMF transmission" state
(before it generates END event itself) and receives another BEGIN event, it
immediately generates END event for currently generating DTMF and handles
new BEGIN event as usual.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2><fake duration> should be very huge value
(some hours, for example) to be sure that bridge will stay in "DTMF
transmission" state until END event (or new BEGIN event) will be
received.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Because we send DTMF event(s) as soon as we get it,
there should no timing problems with IAX or other channels. One real
problem is to support existing unclear implementation of VLDTMF in shipped 1.4
builds.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Functionality of the bridge could be described by
next schematic code:</FONT></DIV>
<DIV><FONT face=Arial size=2>switch(frame.type) {</FONT></DIV>
<DIV><FONT face=Arial size=2> case AST_FRAME_DTMF_BEGIN:</FONT></DIV>
<DIV><FONT face=Arial size=2> {</FONT></DIV>
<DIV><FONT face=Arial size=2> // Remember current time for
forced END generation</FONT></DIV>
<DIV><FONT face=Arial size=2> time_t now =
time(NULL);</FONT></DIV>
<DIV><FONT face=Arial size=2> // We should use default
duration if it is not specified by receiver</FONT></DIV>
<DIV><FONT face=Arial size=2> if(frame.len == 0)</FONT></DIV>
<DIV><FONT face=Arial size=2> frame.len =
AST_DEFAULT_DTMF_DURATION;</FONT></DIV>
<DIV><FONT face=Arial size=2> if(chan.dtmf.end_sched >= 0)
{ // This means we placed to "DTMF transmission" state because
we always set up timer for this state</FONT></DIV>
<DIV><FONT face=Arial size=2> size_t
duration;</FONT></DIV>
<DIV><FONT face=Arial size=2>
ast_sched_destroy(&chan.sched, chan.dtmf.end_sched);</FONT></DIV>
<DIV><FONT face=Arial size=2> // Just to be sure
we clean-up everything after us</FONT></DIV>
<DIV><FONT face=Arial size=2> chan.dtmf.end_sched
= -1;</FONT></DIV>
<DIV><FONT face=Arial size=2> // Calculate real
DTMF duration</FONT></DIV>
<DIV><FONT face=Arial size=2> duration = now
- chan.dtmf.end_start_time;</FONT></DIV>
<DIV><FONT face=Arial size=2> // Pass END event to
transmitting channel</FONT></DIV>
<DIV><FONT face=Arial size=2>
peerchan->tech->send_digit_end(peerchan, chan.dtmf.digit,
duration);</FONT></DIV>
<DIV><FONT face=Arial size=2> }</FONT></DIV>
<DIV><FONT face=Arial size=2> // Send BEGIN event to
transmitting channel</FONT></DIV>
<DIV><FONT face=Arial size=2>
peerchan->tech->send_digit_begin(peerchan, frame.subtype,
frame.len);</FONT></DIV>
<DIV><FONT face=Arial size=2> // If we supposed to send END
event, remember all required information and perform transition to "DTMF
transmission" state</FONT></DIV>
<DIV><FONT face=Arial size=2> if
(peerchan->tech->send_digit_end) {</FONT></DIV>
<DIV><FONT face=Arial size=2> // Add
scheduler for generating END event</FONT></DIV>
<DIV><FONT face=Arial size=2> chan.dtmf.end_sched
= ast_sched_add(&chan.sched, frame.len, dtmf_end_generate,
chan);</FONT></DIV>
<DIV><FONT face=Arial size=2> // Remember
parameters to generate END event correctly</FONT></DIV>
<DIV><FONT face=Arial size=2> chan.dtmf.digit =
frame.subtype;</FONT></DIV>
<DIV><FONT face=Arial size=2> chan.dtmf.duration =
frame.len;</FONT></DIV>
<DIV><FONT face=Arial size=2>
chan.dtmf.end_start_time = now;</FONT></DIV>
<DIV><FONT face=Arial size=2> }</FONT></DIV>
<DIV><FONT face=Arial size=2> break;</FONT></DIV>
<DIV><FONT face=Arial size=2> case AST_FRAME_DTMF_END:</FONT></DIV>
<DIV><FONT face=Arial size=2> if (chan.dtmf.end_sched)
{</FONT></DIV>
<DIV><FONT face=Arial size=2>
<DIV><FONT face=Arial size=2> // Exit from "DTMF
transmission" state,</FONT> abort timer</FONT></DIV></DIV>
<DIV><FONT face=Arial size=2>
ast_sched_destroy(&chan.sched, chan.dtmf.end_sched);</FONT></DIV>
<DIV><FONT face=Arial size=2> chan.dtmf.end_sched
= -1;</FONT></DIV>
<DIV><FONT face=Arial size=2> // Peer supports
two-event DTMF transmission, then send END event</FONT></DIV>
<DIV><FONT face=Arial size=2> if
(peerchan->tech->send_digit_end)</FONT></DIV>
<DIV><FONT face=Arial size=2>
<DIV><FONT face=Arial size=2>
peerchan->tech->send_digit_end(peerchan, chan.dtmf.digit,
chan.dtmf.duration);</FONT></DIV>
<DIV> }</DIV>
<DIV>
<DIV><FONT face=Arial size=2> // Ignore END event if we sent
it already by timer</FONT></DIV> break;</DIV>
<DIV>...</DIV>
<DIV>}</DIV>
<DIV> </DIV>
<DIV>int dtmf_end_generate(void *arg)</DIV>
<DIV>{</DIV>
<DIV> struct ast_channel *chan = (struct ast_channel *)arg;</DIV>
<DIV> struct ast_channel *peerchan = ast_bridgedpeer(chan);</DIV>
<DIV> </DIV>
<DIV> // Timer is fired, exit from "DTMF transmission" state</DIV>
<DIV> chan->dtmf.end_sched = -1;</DIV>
<DIV> </DIV>
<DIV> // Send END event if peer supports for two-event DTMF
transmission</DIV>
<DIV>
<DIV><FONT face=Arial size=2> if
(peerchan->tech->send_digit_end)</FONT></DIV>
<DIV><FONT face=Arial size=2>
<DIV><FONT face=Arial size=2>
peerchan->tech->send_digit_end(peerchan, chan->dtmf.digit,
chan->dtmf.duration);</FONT></DIV>
<DIV> </DIV>
<DIV> // Do not re-schedule event generation</DIV>
<DIV> return 0;</DIV></FONT></DIV></DIV>
<DIV>}</DIV></FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>WBR,</FONT></DIV>
<DIV><FONT face=Arial size=2>Paul.</FONT></DIV></BODY></HTML>