[Bug 24902] interface for precomposed dial-strings
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Tue Feb 2 00:42:38 CET 2010
http://bugs.freedesktop.org/show_bug.cgi?id=24902
--- Comment #2 from Andres Salomon <dilinger at collabora.co.uk> 2010-02-01 15:42:37 PST ---
(In reply to comment #1)
> This API is merely a shortcut for DTMF. Rather than individually calling
> DTMF.StartTone and DTMF.StopTone, the DialStrings interface allows one to send
> a batch of tones to the modem.
>
> - SendDialString(u:Stream_ID, s:DialString, u:Duration, u:Pause
This should probably be merged into a DTMF spec. Stream_ID should be dropped
(as we're planning to do for DTMF).
>
> The DialString arg here is a string of DTMF tones; each tone is (theoretically)
> played for Duration ms, followed by Pause ms of silence (in actuality for
> something like a GSM modem that knows how to handle a DTMF string, the
> Pause/Duration arguments end up being ignored unless the hardware API accepts
> them).
>
> - CancelDialString(u:Stream_ID)
If SendDialString is added to DTMF, I don't see why StopTone couldn't be used
in place of CancelDialString. It simplifies the interface a lot; StopTone
stops any tones from playing, whether it's a single tone (started w/
StartTone), or a set of tones (started w/ SendDialString).
>
> - GetCurrentDialStrings(Stream_ID) => a{us}:Dial_Strings
>
> A map of Stream_ID to DialStrings currently being sent.
I'm not convinced that this is useful. I'm also not convinced that it's not
racy for a client to be using this to make any decisions about handling
dialstrings. I suggest dropping it.
>
> - signal SendingDialString(u:Stream_ID, s:Dial_String)
>
> - signal StoppedDialString(u:Stream_ID, b:SucessfullySent)
>
> SuccessfullySent is false if the dialstring was cancelled.
>
Both of thee seem like important things to support. Stream_ID should be
dropped. Signals should probably trigger regardless of whether SendDialString
has been sent, as it is conceivable that the Channel may have the handle
1234567890p123 (where the string following the 'p' is meant to be DTMF tones
that are played automatically after a call connection has been made). Is it
worth sending these signals in response to StartTone/StopTone as well?
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the telepathy-bugs
mailing list