[Standards] UPDATED: XEP-0181 (Jingle DTMF)
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.
> 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).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards