[Bug 24902] interface for precomposed dial-strings

[bugzilla-daemon at freedesktop.org]

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

--- Comment #16 from Senko Rasic <senko at senko.net> 2010-04-15 08:05:29 PDT ---
Here's a summary and my suggestions, from a POV of someone first reading
through this yesterday:

1. Using existing Channel.DTMF interface vs creating Call.Content.DTMF

Although using Call.Content.DTMF looks cleaner, the fact is that if we do that,
we'll end up with two basically same interfaces, except one has a few extra
methods/signals. Otherwhere in the spec, we only have this if the new/expanded
interface has a lot more features (and is more complicated to use and is not
always needed for simple clients), e.g. Text vs Messages. In this case,
however, we'd just be duplicating almost-but-not-quite the same functionality.
Unless we plan to deprecate Channel.DTMF quickly, I'm more for reusing and
extending the existing one.

2. Do we care about calls with >1 audio streams?

IMHO we don't. If there are multiple audio streams, I guess the natural thing
to do is send tones on all of them (that support it). If we can't make a
realistic use case where we'd want to send tones only to a subset (reading the
bug comments I didn't see any, maybe the spec cabal discussed that), IMHO we
better not try to be too much future-ready.

Btw since we have to keep the Stream_ID parameter to ensure backwards
compatibility (but ignore it), we can, if we think that's a good idea,
repurpose it again (e.g. an invalid ID meaning send to all, a specific ID
meaning send to only that stream).

3. SendMultiple/StartTone/StopTone and the signals

It makes sense to treat SendMultiple() for fire&forget use cases, and still
retain StartTone/StopTone for the interactive dialpad use (if we're using the
existing interface, they're there already with the same semantics).

As we don't support queueing or overlaping tones, we can mandate that
SendMultiple/StartTone only be called if there are no tones currently being
sent (and since explicit is better than implicit - require that any previous
playback is stopped before new StartTone call), and that StopTone stops any
sending.

Relatedly - are we certain we can cancel queued-up tones on all protocols? If
no, StopTone shouldn't say "immediately stops tone sending" and should instead
ys "immediately stops tone sending if StartTone is used; for SendMultiple,
attempts to cancel the send; the client shouldn't assume the tones are stopped
before StoppedTones is emitted".

I've created another branch (dtmf3 in my repo) implementing the above things:
http://git.collabora.co.uk/?p=user/ptlo/tp-spec-senko/.git;a=shortlog;h=refs/heads/dtmf3

I've taken a definitive stance on how to define this, hopefully we can say
"yes" or "no" to specific points, polish this (or dtmf2) according to that, and
badger this into submission^Wmergeable state.

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