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/
smime.p7s
Description: S/MIME Cryptographic Signature
