[Bug 24902] interface for precomposed dial-strings

[bugzilla-daemon at freedesktop.org]

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





--- Comment #12 from Olivier Crête <tester at tester.ca>  2010-02-17 09:56:02 PST ---
(In reply to comment #11)
> 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.

Why would you ever want to put it on the Channel instead of on the Content? Can
you have a useful Call channel with no content?


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

Imho, the CM should just forward the tones to the streaming implementation
which will decide when to play them.

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

I think the use case is to display a banner "sending DTMF" (like Fremantle
does)


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