[asterisk-dev] [svn-commits] mjordan: testsuite/asterisk/trunk r3711 - /asterisk/trunk/tests/channels/SIP/...

[Olle E. Johansson]

16 apr 2013 kl. 16:48 skrev Matthew Jordan <mjordan at digium.com>:

> On 04/16/2013 09:38 AM, Olle E. Johansson wrote:
>> 
>> 16 apr 2013 kl. 16:33 skrev SVN commits to the Digium repositories <svn-commits at lists.digium.com>:
>> 
>>> Asterisk 12 uses DTMFBegin/DTMFEnd. In this case, we only really care
>>> about the DTMFEnd events - so subscribe for those and treat them as
>>> if they were the DTMF event in previous versions of Asterisk
>> 
>> Please notice that this is not the solution we will have. I have a large patch that adds DTMFcontinue in order to
>> properly handle DTMF. I don't know if that's relevant here, but we need to move that patch forward to fix a lot
>> of DTMF issues.
>> 
>> In this code we have 
>> 
>> DTMF Begin
>> DTMF continue - repeated for as long as we get DTMF in
>> DTMF End
>> 
>> The DTMF continue has a duration data field, that is needed to handle playout on the other side of the bridge.
>> 
>> Just to update you in case it matters for this code.
>> 
> 
> Luckily, this is just AMI's representation of DTMF. It's just responding
> to whatever the core (over the Stasis-Core message bus) tells it to do -
> which, even with a DTMF continue, would still include a Begin/End. So
> this should be okay with any changes we make to DTMF.
> 
> While the core would make use of a DTMF continue, I'm not sure if
> sending a DTMF continue makes a lot of sense for external applications.
> Right now, of course, that isn't really even an option, but it could
> certainly be added if there was a need for it.

The only thing that matters is that if a DTMF continue comes with no
preceding DTMF begin, we should send a DTMF begin to stasis...

Packet loss can lead to interesting situations.

/O