linphone-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Kosek Dan
Subject: Re: [Linphone-developers] Re: Wait between DTMF tones in linphonec
Date: Tue, 4 Jan 2011 08:31:37 -0500

Take a look at RFC 2833

http://www.faqs.org/rfcs/rfc2833.html

Section 3.8/3.9 show have to send multiple digits in one packet, though I 
haven't checked how this is implemented in Linphone, it should at least help 
you understand what should be happening.

Best regards,

Dan
Dan Kosek: VoicePlex - Travelerâ„¢ - Reachâ„¢
Contact Info: address@hidden - 240.345.9000


On Jan 4, 2011, at 3:21 AM, address@hidden wrote:

> 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
> 
> 
> _______________________________________________
> Linphone-developers mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/linphone-developers




reply via email to

[Prev in Thread] Current Thread [Next in Thread]