[Standards] UPDATED: XEP-0181 (Jingle DTMF)

Peter Saint-Andre stpeter at stpeter.im
Wed Apr 23 13:49:37 UTC 2008


Paul Witty wrote:
> Peter Saint-Andre wrote:
>> Paul Witty wrote:
>>  
>>> If a button-down action is followed by a button-up
>>> action with a different set of parameters, it is not clear which ones we
>>> should use.  The addition of duration also confuses
>>> matters if a message is received with a duration of e.g. 1000ms, and
>>> then 50ms later there is a button-up action.
>>>     
>>
>> Does it even make sense to include button-up? Everything can probably be
>> handled with button-down and durations.
>>
>>
>>   
> Indeed, it seems that having both the real-time button up/down and
> duration methods of recreating timings is unnecessary.  I quite like the
> up/down approach, because it means you can be more responsive (taking
> actions on button down instead of up, rotating through letters on screen
> by holding down the number if using DTMF to do alphanumeric entry). 
> Except that the nature of TCP makes no guarantee about the timing of the
> messages, so our recreation of the DTMF may be incorrect.  Also, if the
> Jingle client runs on a PC, chances are that DTMF events will be created
> by single button clicks, and so not support varied durations.

Right.

> So I'd have no objections to getting rid of button-up events, and just
> making DTMF message have the compulsory parameter 'code' , and optional
> 'volume' and 'duration' properties, with sensible well-defined defaults
> if not present (100ms duration, I don't have any opinion about volume,
> as I wouldn't be using it).

That seems reasonable. I'll look at RFC 4733 etc. again to determine
reasonable defaults for duration (100ms is probably good enough but I'd
like to double-check).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20080423/0a1c6211/attachment.bin>


More information about the Standards mailing list