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
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
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.
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.