[Linphone-developers] Re: Wait between DTMF tones in linphonec

[grodriguez]

Hello John,

On 03/03/2011 18:41, John Wimer wrote:
> On 01/03/2011 11:55 AM, Guillermo Rodriguez Garcia wrote: 
>> Hello all,
>> 
>> I am writing an application that uses linphone and needs to send DTMF codes
>> to operate a remote device. While looking at linphonec, I noticed that a 
>> pause of 1 second is inserted between tones (console/commands.c, function
>> linphonec_parse_command_line).
>> 
>> This makes the sending of DTMF codes very slow, especially when the sequence
>> contains several digits. Since the tones are not actually being transmitted
>> as audio, I thought that the pause could be removed / shortened. However when
>> I tried this, the other end had problems detecting the DTMF codes. This
>> happened both with RFC2833 and with SIP INFO. I also verified that the same
>> problem occurs when both ends are running linphone.
>> 
>> Can someone explain why is this pause needed, and why does it need to be one
>> second? I could not find any reason for this, specially if SIP INFO is used.
> 
> The delay is to allow the SIP INFO message to be received and
> confirmed before sending the next message. 1 second is completely
> arbitrary and using a delay-based approach is not actually reliable.
> The correct implementation would be to have a queue of to-be-sent
> dtmf codes so the next one would be sent as soon as the in-flight one
> is ACKed.
> 
> Even then, it can take a long time to send long dtmf sequences. If
> your endpoints support it, you might want to use a single SIP INFO
> message to send the entire sequence by using application/dtmf instead
> of application/dtmf-info. However, that is even less standard.

Thank you for the pointer. I didn't know about application/dtmf at all. If
this is supported by the remote device then this might be a good solution.

Anyway I'm still puzzled, your answer explains why the pause is there for
SIP INFO (even though it is not a reliable approach), but any ideas on why
is it needed for RFC2833? I found it is also required in this case.

Thanks again,

G Rodriguez