[Bug 24902] interface for precomposed dial-strings

[bugzilla-daemon at freedesktop.org]

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





--- Comment #13 from Andres Salomon <dilinger at collabora.co.uk>  2010-02-17 16:06:27 PST ---
(In reply to comment #11)
> 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?

I'd prefer it to be an interface on the channel interface, but I don't feel
strongly about it one way or the other.

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

I think it's important from a UI perspective to hear tones when one holds down
a key.  This is helpful when navigating an automated phone system ("press 1 to
hear this in english.  pará español,  empuje el número 2, ...").  When one
eventually gets frustrated at the phone menu and starts mashing 0 repeatedly,
one would not want to deprive the user of the satisfaction of hearing those
angry tones.


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

I don't have a problem w/ a StartTone call implicitly ending any prior playing
tones, I just wouldn't want to see the kind of situation where someone mashes
buttons on their phone (accidentally or not), and the CM then proceeds to spend
the next 20s playing queued-up tones.  MultipleTones() is meant to
automatically take care of timings; StartTone/StopTone is meant to happen
immediately.

What happens when MultipleTones is running, and StartTone(3) is called?  Should
that quietly truncate the currently playing tone string?


> 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'm imagining things like a UI number display.  You're at a phone menu, dialing
your fedex tracking number (followed by the #).  StartTone(5), StopTone(),
StartTone(4), StopTone, StartTone(3), etc...   How does the UI know whether the
tone actually ended up being played?  SendingTones informs you that the number
has been played, and therefore the UI should display the played number.

For newly placed calls like '3214p123', SendingTones is an indicator to the UI
that the call's not quite ready for user input; StoppedTones tells the UI that
the call is ready for the user to mangle.  I don't think stuff like muting need
be handled at the UI level; the CM is presumably capable of muting any audio
while playing tones (if necessary).



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