12:23 < pessi> smcv: 'w' should probably send something to ui, and ui should decide when to continue ... 12:25 < smcv> ugh, in that case we need a TonesWaiting(s) signal and some way to resume 12:25 < smcv> I'd be inclined to say it goes like this: 12:25 < smcv> suppose InitialTones (or tail of TargetID) is 1234w5678w90 12:26 < smcv> when the call connects, the DTMF beeper sends 1234 12:26 < smcv> then emits TonesWaiting("5678w90") 12:26 < smcv> at this point the DTMF player is idle 12:27 < pessi> smcv: sounds fine this far 12:27 < smcv> the UI can either ignore the signal, or respect the signal by (waiting for the user and) calling SendMultipleTones("5678w90") 12:27 < smcv> at that point the CM plays 5678 and emits TonesWaiting("90") 12:27 < smcv> and the UI can call SendMultipleTones("90") to finish the sequence off? Bug #28413 should both be considered to be blocked by this one (unless we knock out the support for MultipleTones in Gabble for now), because if we start adding possible dialstring runes after CM releases implement MultipleTones, we'll also have to add some sort of capability discovery for the runes the CM understands. Bug #30505 is blocked by this regardless.
Proposed spec: http://people.freedesktop.org/~smcv/telepathy-spec-dtmf/spec/ http://git.collabora.co.uk/?p=user/smcv/telepathy-spec-smcv.git;a=shortlog;h=refs/heads/dtmf I have sketchy implementations in Gabble nearly ready to go (Bug #28413).
Looks totally rad, dude!
Updated branch r+ from Jonny on IRC and merged, will be in 0.21.3.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.