[Bug 24902] interface for precomposed dial-strings

[bugzilla-daemon at freedesktop.org]

http://bugs.freedesktop.org/show_bug.cgi?id=24902





--- Comment #11 from Will Thompson <will.thompson at collabora.co.uk>  2010-02-17 09:49:27 PST ---
A spec cabal of smcv, cassidy, sjoerd and myself seemed generally keener on the
dtmf2 branch too.

Recurring question: do we really care which content the DTMF tones are going to
be sent over? How is a UI ever going to know which one the user meant? Can we
just make it an interface on the channel with no stream IDs, and say it's up to
the CM?

If we did that, then we could in principle use the same interface on Call, and
just say that on call the stream IDs are ignored... Saves having two
interfaces, at the cost of a bit of cruft. Relatedly, we could glue
MultipleTones() onto this existing interface in any case.

Alternatively, can we get rid of start/stop entirely in favour of SendMultiple?
Do we want to support people playing happy birthday to their friends? smcv
suggests not; wjt suggests that we do, and given that that's the API we
currently have implemented in a bunch of places...

Regarding overlapping calls: first, we could say that only the channel's
handler should be using this interface. Then we can say that calling
StartTone(3), StopTone(), StartTone(4), StopTone() is the same as if you omit
the first StopTone()? We don't support sending >1 tone at the same time, so the
CM should queue them if it hasn't finished playing the current tone.

What's the use case for SendingTones? It's racy for the UI to change its
behaviour based on it, like muting the microphone. But it's probably fine for
informational purposes.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.