[Bug 28413] Gabble DTMF

Fri Oct 8 13:38:08 CEST 2010

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

--- Comment #6 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-10-08 04:38:08 PDT ---
12:06 < pessi> smcv: 'p' and perhaps ','  for 3 second pause?
12:07 < smcv> pessi: both, with the same semantics, or what?
12:08 < pessi> for sending dtmfs, yes
12:08 < barisione> smcv, pessi: I'm not entirely sure what you are talking 
                   about, but there are other things, like X and W
12:09 < smcv> pessi: is it always always 3 seconds, or should the CM be able to 
              override?
2:10 < pessi> ',' as first pause means "send rest as dtmf when call is 
               alerting" and "p" (or X) send as dtmf when call was connected 
12:10 < smcv> pessi: and indeed can you offer any opinion on the beep lengths 
              that Gabble uses? it'scurrently a 200ms tone and a 100ms gap
12:11 < pessi> and "W" means that stop here and let user decide when to send 
               rest of the string
12:11 < smcv> pessi: so for Telepathy, I don't think "wait" really makes sense
12:11 < pessi> smcv: we use same values
12:12 < smcv> wow, my randomly guessed values were right!
12:12 < pessi> smcv: it is more an ui issue
12:12 < smcv> pessi: so the plan I had for initial DTMF was:
12:12 < pessi> but there is a stupid 3gpp feature called FDN where you have to 
               tell modem in advance which DTMF digits you plan to send
12:13 < smcv> we alter telepathy-glib so it keeps the TargetID in the mapping 
              given to CMs
12:13 < smcv> more or less all CMs ignore it
12:13 < smcv> but telephony CMs can look at it and chop it up into phone number 
              and initial DTMF blob if they want to
12:13 < sjoerd> pessi: so you tell the modem what you plan to tell it, and 
                later on you tell it, now actually send these ?
12:13 < smcv> e.g.
12:14 < pessi> sjoerd: yes
12:14 < smcv> if you want to call +44123456 and send ##ABCD, you'd dial 
              "+44123456p##ABCD" right?
12:14 < sjoerd> pessi: awesome...
12:15 < smcv> then our idea was that -ring would look at the TargetID and go 
              "there's more here than I thought there would be", and treat it 
              as if it had been TargetID = +4412346, InitialTones ##ABCD
12:15 < pessi> sjoerd: it has added benefit of including all those DDTMF things 
               in your call history 
12:15 < smcv> (I haven't implemented InitialTones in Gabble yet either)
12:15 < smcv> then the TpDTMFPlayer would only have to play the ##ABCD part I 
              think?
12:16 < smcv> does that sound workable, and if we do that, do we still need p, 
              w, comma?
12:16 < pessi> smcv: yep, that sounds ok
12:16 < smcv> indeed, are there any other things we might need? barisione 
              mentioned X?
12:17 < pessi> X is sip thing, it means same as p, send dtmf digits once call 
               is connected
12:17 < pessi> it is never in the InitialTones part
12:17 < smcv> so P and X are synonyms, and mean "wait for call to connect, then 
              play"
12:17 < smcv> and the TpDTMFPlayer should never need to see them
12:17 < pessi> ..but later p means pause
12:18 < smcv> ugh, ok
12:18 < pessi> ;)
12:18 < smcv> so the first p (or x) is the break point between the phone number 
              and the InitialTones
12:18 < pessi> or ","
12:18 < pessi> or "w"
12:19 < smcv> pessi: should we just treat any member of [pxwPXW,] as "sleep 3"?
12:20 < smcv> pessi: (and, implementation detail, ring also uses them to cut 
              the InitialTones off the TargetID, but when it does that it 
              should delete the separator)
12:23 < pessi> smcv: 'w' should probably send something to ui, and ui should 
               decide when to continue
12:23 < pessi> but for [pPxX,] yes
12:23 < smcv> pessi: W doesn't sound like it should be in Telepathy at all tbh
12:24 < smcv> pessi: oh, except you want to be able to pass it through the 
              TargetID?
12:24 < pessi> yep
12:25 < smcv> ugh, in that case we need a TonesWaiting(s) signal and some way 
              to resume
12:25 < smcv> I'd be inclined to say it goes like this:
12:25 < smcv> suppose InitialTones (or tail of TargetID) is 1234w5678w90
12:26 < smcv> when the call connects, the DTMF beeper sends 1234
12:26 < smcv> then emits TonesWaiting("5678w90")
12:26 < smcv> at this point the DTMF player is idle
12:27 < pessi> smcv: sounds fine this far
12:27 < smcv> the UI can either ignore the signal, or respect the signal by 
              (waiting for the user and) calling SendMultipleTones("5678w90")
12:27 < smcv> at that point the CM plays 5678 and emits TonesWaiting("90")
12:27 < smcv> and the UI can call SendMultipleTones("90") to finish the 
              sequence off?
12:27 < smcv> this is much more complicated than I hoped it'd be
12:28 < smcv> let me note that on the bug
12:28 < Robot101> smcv: is that really easier than just saying -> 
                  TonesWaiting("true") <- CarryOn() ...?
12:28 < smcv> Robot101: it reduces it to an already-solved problem? :-)
12:28 < smcv> the UI can either play the suggested tones or do something else
12:28 < smcv> oh, bah, state recovery though
12:29 < smcv> if the UI doesn't exist yet, it'll miss the signal
12:29 < smcv> the other possibility would be that the DMTF player holds more 
              state (the fact that it has a "w" string ready to go)
12:30 < smcv> and calling SendMultipleTones or StartTone will fail, until you 
              have either called StopTone to cancel the "w" string, or called 
              CarryOn
12:33 < pessi> smcv: I like the TonesWaiting signal (and property?) better..
12:33 < smcv> pessi: yeah it'll have to have a mutable property :-(

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