[Bug 24902] interface for precomposed dial-strings

[bugzilla-daemon at freedesktop.org]

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

--- Comment #17 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-04-21 08:25:57 PDT ---
(In reply to comment #16)
> I'm more for reusing and extending the existing one.

Will, Sjoerd and I agree - keep it as a Channel interface.

> 2. Do we care about calls with >1 audio streams?
> 
> IMHO we don't.

We agree.

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

We agree.

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

We agree.

Issue: suppose you have the phone number 12345p987 in your address book (i.e.
dial 12345, wait, send 987 as DTMF to select extension 987). Two routes we
could go here:

* Require the address book to know about phones, and make a request with
{TargetID: "12345", InitialDTMF: "987" }

* Make a request with { TargetID: "12345p987" } and have the CM interpret it

The latter needs changes to TpBaseConnection, to have it not delete the
requested (non-normalized) TargetID from the request as it currently does.
(Currently, TargetID is removed, and replaced with a TargetHandle.) We can do
that, though.

In either case, 12345p987 should normalize to 12345, and hence the NewChannels
signal (and the channel's immutable properties) should contain { TargetID:
"12345", InitialDTMF: "987" }.

Spec cabal consensus is to have telephonic CMs support both of these modes.

API needing to be added is:

* InitialDTMF (immutable and requestable) (could be InitialTones or something -
bikeshed)

* some way to know (state-recovery) that you're already sending, so you can
wait to not be sending before making the dial pad widget sensitive - we propose
a property CurrentlySendingTones: b with change notification via SendingTones,
StoppedTones.

We should ask the telephonic CM implementors who's responsible for playing
feedback to the user on HardwareStreaming CMs.

People who know about Farsight need to ponder how we get feedback played on
HardwareStreaming=FALSE CMs. There are two cases here:

* the DTMF is sent in the signalling: the CM needs to poke the streaming
implementation and say "play audible feedback for 'one two hash star' but don't
send it";

* the DTMF is sent in-band in the RTP: the CM needs to poke the streaming
implementation and say "emit 'one two hash star' in your RTP and also play
audible feedback for it".

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