Built ID 20130823171628 Device: Ikura QC RIL version: "ro.build.firmware_revision=V1.01.00.01.019.180" gaia commit: 4916f82 Merge branch 'zte/ics_strawberry_cdr' of ssh://10.67.16.41:29418/quic/lf/releases/gaia into ics_strawberry_cdr gecko commit: a1c2bb0 ZRL modify ACCEPT Http head for MMS There is no option to dial a pause in DuT. Normally, reference phones allow it by long pressing the "*" key.

Adding to backlog to be properly prioritized. Thanks!

For tracking purposes - A user also reported and requested this feature in the SUMO forums: https://support.mozilla.org/en-US/questions/1003251 The user mentions that he has a lot of "Programmed contacts" set to automatically dial into conference calls, using commas for 5-second pauses, and that this does not work on Firefox OS (it works on Android, Symbian, iPhone, Windows Phone). USER'S VERBATIM: I am trying out the ZTE Open C for work, but have found a limitation that seems to be a showstopper alltogether I have a bunch of numbers coded into my SIM, which is for conference calls. The numbers are in a format like xxx-xxx-xxx,,1234567# where xxx-xxx-xxx is the number for a conference call service and 1234567# is the passcode for my conference. What it does on all my prior phones (Symbian, Android, Win phone) is dial xxx-xxx-xxx, wait 10 seconds (5 sec pr comma) and then send the 1234567# as if I was inputting it like on a normal dialpad. When I dial these from FFOS it tells me it is an invalid phone number. I have too many of these to memorize and use them frequently so there is no way for me to use this phone without them I am open to suggestions that requires changing code and so on. Any ideas ?

Is this ',' pause command really an in-call mmi command handled by the gsm stuff? I suggested this could probably be implemented in the FE using mozTelephony.dial and mozTelephony.startTone. For example for 123456,,789 would be something like: mozTelephony.dial('123456'); javascript waits for 10 seconds because of ',,' mozTelephony.startTone('7'); mozTelephony.startTone('8'); mozTelephony.startTone('9'); Although, maybe this is not the right place to put this logic at all. If this is handled by the telephony API how it would be used? like this? mozTelephony.startTone('123456,,789')

Hi David, I'm afraid that the details regarding implementation and coding of this feature are beyond my understanding. I will just mention that although I don't see a problem in implementing it with "commas", this character is not currently available in the Dialer keyboard. Thanks for looking into this! =) - Ralph

According to the description, reference phone uses '*' . Can we use it instead of "commas"? Please keep in mind that this kind of numbers can be stored in contacts. We should allow to dial them from kepad and contacts menu.

(In reply to David Garcia [:davidg] from comment #3) > Is this ',' pause command really an in-call mmi command handled by the gsm > stuff? This is not a MMI in call command. This feature should use DTMF tones which dialler app is supporting now. The pause regardless if we decide to use '*', ',', or any other command, is just a 5 sec pause in the dialer... before starting the dialing of the DTMF tones. Are you sure we need bug 890912 to implement this feature?

You are right, I misread the description. Sorry about that. So this is a DTMF Control digit separator [1], right? [1] http://www.etsi.org/deliver/etsi_gts/02/0207/05.00.00_60/gsmts_0207v050000p.pdf

(In reply to Fernando Jiménez Moreno [:ferjm] from comment #7) > You are right, I misread the description. Sorry about that. So this is a > DTMF Control digit separator [1], right? > > [1] > http://www.etsi.org/deliver/etsi_gts/02/0207/05.00.00_60/gsmts_0207v050000p. > pdf Yes, thanks for the document!

In and Android 4.4, in the dial number screen, there is an "add 2 second pause" option that adds a "," to the number. I guess what FangChen meant, is that in reference phones because there is no ',' key, you press '*' for some seconds to get a ',' in the number. Seems that this is how it works on iPhone[1] As we don't have a menu for additional options in the dialer (like android), maybe we should follow the long pressing '*' approach. In contacts editor you can already insert a ',' in the number long pressing '6'. It seems a bit confusing to me that in contacts editor you have to long press '6', and in the dialer you have to long press '*'. What do you think? [1] http://support.apple.com/kb/HT4515

It could be implemented on the gaia side, but I'd like to check with the RIL developers first :) Hsin-Yi what do you think?

Ha, so many mid-air collisions.

(In reply to Etienne Segonzac (:etienne) from comment #11) > It could be implemented on the gaia side, but I'd like to check with the RIL > developers first :) > Hsin-Yi what do you think? Doing on gaia side sounds good! +1 with comment 3, gaia parsing the magic string and calling telephony.dial() and telephony.startTone() accordingly!

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #13) > (In reply to Etienne Segonzac (:etienne) from comment #11) > > It could be implemented on the gaia side, but I'd like to check with the RIL > > developers first :) > > Hsin-Yi what do you think? > > Doing on gaia side sounds good! +1 with comment 3, gaia parsing the magic > string and calling telephony.dial() and telephony.startTone() accordingly! Hsin-yi, Gecko should be the correct owner of this feature and not Gaia. There are wild and wait characters as well that complicates the logic enough for Gecko to be involved

(In reply to Anshul from comment #14) > (In reply to Hsin-Yi Tsai [:hsinyi] from comment #13) > > (In reply to Etienne Segonzac (:etienne) from comment #11) > > > It could be implemented on the gaia side, but I'd like to check with the RIL > > > developers first :) > > > Hsin-Yi what do you think? > > > > Doing on gaia side sounds good! +1 with comment 3, gaia parsing the magic > > string and calling telephony.dial() and telephony.startTone() accordingly! > Hsin-yi, Gecko should be the correct owner of this feature and not Gaia. > There are wild and wait characters as well that complicates the logic enough > for Gecko to be involved Hi Anshul, I'd like it be on the gaia side because it looks to me "pause character" isn't defined from the spec point of view (correct me if I am wrong). Letting gaia control different UI spec and taking advantage of Telephony API looks flexible, doable and sensible to our reference platform. I don't get your comment clearly. Could you give an example when we would encounter a problem if doing this on gaia? Thanks!

Hello Hsin-Yi, lets discuss this during our vidyo call this week.

Per discussion with Hsinyi and Anshul, it makes sense to implement from GAIA rather than Gecko. NI? to Wilfred to consider putting in roadmap of comms features.

I would like to work in this bug

(In reply to David Garcia [:davidg] from comment #18) > I would like to work in this bug We would need UX spec first!

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #19) > (In reply to David Garcia [:davidg] from comment #18) > > I would like to work in this bug > > We would need UX spec first! Ups, sorry Hsin-Yi. I thought the proposed solution was to long press '*'. In the contacts application, it is already possible to enter pauses when editing a phone number. The problem is the dialer doesn't recognize it as a valid phone number and doesn't dial it. I can start to work on that part while we get a spec from UX for the dialer screen. Do you think it should be handled in this bug? Or shall I open a new one for contacts with ','? Thanks!

(In reply to David Garcia [:davidg] from comment #20) > (In reply to Hsin-Yi Tsai [:hsinyi] from comment #19) > > (In reply to David Garcia [:davidg] from comment #18) > > > I would like to work in this bug > > > > We would need UX spec first! > > Ups, sorry Hsin-Yi. I thought the proposed solution was to long press '*'. > Hi David, The proposal indeed looks good to me, and it is commonly adopted. But in case you implement the design the UX dislikes, it's always better to get their agreement first, especially we have a different UI in other App, i.e. Contacts. It's fine to address the character parsing in this bug. But to have a thorough feature support, in addition to recognize the 'pause' character, I guess we also need UX confirmation about when and how Dialer displays those DTMF characters. > In the contacts application, it is already possible to enter pauses when > editing a phone number. The problem is the dialer doesn't recognize it as a > valid phone number and doesn't dial it. > I can start to work on that part while we get a spec from UX for the dialer > screen. > Do you think it should be handled in this bug? Or shall I open a new one for > contacts with ','? > > Thanks!

Hi Carrie, we are really interested in launching this feature as this is a certification waiver. Right now including "," in Contact application when editing a phone number and doing long press on "*" character (a "," will be displayed when doing that) to include a pause in the Dialer is what our UX team proposes, but, of course we need you to confirm if it's ok with you or do you have another plans about including this pause

Hi Maria, I'm fine with long-pressing the * in Dialer to include a pause, but how can we adopt the "," in Contact APP while editing the phone number? The current keypad in Contact APP doesn't have "," either. I've checked IPhone, they can switch their kaypad for punctuation input in Contacts. Do you have any proposal from the UX side on this issue? Thanks

(In reply to Carrie Wang [:carrie] from comment #23) > Hi Maria, > > > I'm fine with long-pressing the * in Dialer to include a pause, but how can > we adopt the "," in Contact APP while editing the phone number? The current > keypad in Contact APP doesn't have "," either. > I've checked IPhone, they can switch their kaypad for punctuation input in > Contacts. Do you have any proposal from the UX side on this issue? Thanks Are you checking master branch in FxOS? Recently a new dialpad was launched, and in the "6" Key you have a the "," character, so just long pressing that key you already have the pause :)

oh yes, I've checked the latest version, the keypad has changed. So I think I'm fine with the solution. Thanks!

This patch allows you to type ',' (aka DTMF control digits separator) in the dialer long pressing '*'. Also allows telephony_helper to dial numbers with ',' in it. It dials the phone number before the first ',' as usual, and when the call is answered, it dials the rest of the number using DTMF tones. When a ',' is found it waits 3 seconds before playing the next digit, as specified in [1]. [1] http://www.etsi.org/deliver/etsi_gts/02/0207/05.00.00_60/gsmts_0207v050000p.pdf

Comment on attachment 8461354 [details] github PR Forwarding to Doug to follow this new feature.

Comment on attachment 8461354 [details] github PR Thanks for this patch. I left some comments on the PR.

Comment on attachment 8461354 [details] github PR Thanks for review Doug. I fixed all the problems you commented except for one thing I didn't understand very well, about the onconnected callback not being necessary,

Comment on attachment 8461354 [details] github PR You're getting really close. I left some more comments on the PR. BTW, thank you for throwing in a good amount of tests. I think everything we need is covered. I was tempted to ask for tests for getBaseDigitsFromNumber and getDtmfDigitsFromNumber, but I consider them to be internal implementation details, and they're covered indirectly by other tests.

Comment on attachment 8461354 [details] github PR Fixed the comments. Thanks Doug!

Comment on attachment 8461354 [details] github PR Thanks, looks good!

Also, this could use a demo.

I have a question, when user call to phone number for example: 688688668,,,895,,,98, can user see this phone number with "," in call log screen?, and in connected screen ? Please a need info UX

Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1050184

Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1050189

Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1050194

(In reply to Loli from comment #36) > I have a question, when user call to phone number for example: > 688688668,,,895,,,98, can user see this phone number with "," in call log > screen?, and in connected screen ? > > Please a need info UX I also have a question: can user see the DTMF numbers when we send out the tones?

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #40) > (In reply to Loli from comment #36) > > I have a question, when user call to phone number for example: > > 688688668,,,895,,,98, can user see this phone number with "," in call log > > screen?, and in connected screen ? > > > > Please a need info UX > > I also have a question: can user see the DTMF numbers when we send out the > tones? I mean, as a user, I'd like to see, otherwise I have no idea of the process. ni Carrie :)

Backed out in https://github.com/mozilla-b2g/gaia/commit/a8f9b8347f4d44deadfc22fc0537181191985266 for followup bugs and design issues.

Hsin-Yi, We are currently having problems playing the DTMF tones with the right duration (120ms). This is because the telephony API has a startTone method and a stopTone method, that needs to be called exactly at the time you want to stop playing the tone. From javascript this is quite tricky, because when the application goes to background, setTimeout minimum resolution is 1 second. There is a sendTones[1] method defined in the standard, that allows you to specify the duration of the tones played instead of having to call stopTone from Javascript. Are there any plans or chance to have this method implemented? Thanks! :) [1] http://www.w3.org/2012/sysapps/telephony/#the-sendtones-method

(In reply to David Garcia [:davidg] PTO 9th-24th Aug from comment #43) > Hsin-Yi, > > We are currently having problems playing the DTMF tones with the right > duration (120ms). > This is because the telephony API has a startTone method and a stopTone > method, that needs to be called exactly at the time you want to stop playing > the tone. From javascript this is quite tricky, because when the application > goes to background, setTimeout minimum resolution is 1 second. > There is a sendTones[1] method defined in the standard, I would say this is not the standard. It's still in the editing process ;) > that allows you to > specify the duration of the tones played instead of having to call stopTone > from Javascript. > Are there any plans or chance to have this method implemented? > Moz internally discussed this issue several times. We haven't implemented it yet because we didn't see a strong reason to have this API, which is kinda duplicate of startTone/stopTone. But considering the case we are facing now, it makes sense to re-visit this API request again. :) In addition to sendTone(), I think we still want to keep startTone/stopTone APIs for better user interaction. sendTone() provides a nice solution to per-defined tone duration use cases; startTone/stopTone are for the cases that depend on the physical user behaviour. Make sense? > Thanks! :) > > [1] http://www.w3.org/2012/sysapps/telephony/#the-sendtones-method

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #44) > (In reply to David Garcia [:davidg] PTO 9th-24th Aug from comment #43) > > Hsin-Yi, > > > > We are currently having problems playing the DTMF tones with the right > > duration (120ms). > > This is because the telephony API has a startTone method and a stopTone > > method, that needs to be called exactly at the time you want to stop playing > > the tone. From javascript this is quite tricky, because when the application > > goes to background, setTimeout minimum resolution is 1 second. > > There is a sendTones[1] method defined in the standard, > > I would say this is not the standard. It's still in the editing process ;) > > > that allows you to > > specify the duration of the tones played instead of having to call stopTone > > from Javascript. > > Are there any plans or chance to have this method implemented? > > > > Moz internally discussed this issue several times. We haven't implemented it > yet because we didn't see a strong reason to have this API, which is kinda > duplicate of startTone/stopTone. But considering the case we are facing now, > it makes sense to re-visit this API request again. :) > > In addition to sendTone(), I think we still want to keep startTone/stopTone > APIs for better user interaction. > sendTone() provides a nice solution to per-defined tone duration use cases; ^^^^^^^^^^^ typo: pre-defined > startTone/stopTone are for the cases that depend on the physical user > behaviour. Make sense? > > > > Thanks! :) > > > > [1] http://www.w3.org/2012/sysapps/telephony/#the-sendtones-method

Hi, I'd suggest displaying the exact numbers that user has input from the dialpad so that he would take it as a reference and also he can tap to call back from call log as well (we don't want to loose this feature in this case). Hence, the call log, dialer, in-call screen and the connecting screen should display these numbers. Thanks!

From comment 46, that means we need more changes from the RIL. We need to be able to do telephony.dial('688688668,,,895,,,98') and have all the telephony APIs return the full number that was typed by the user. This full number could be a new attribute on calls (and the dictionary passed to telephony-call-ended handlers). Or we could change the current number attribute. In any case, this is a lot more work than just enabling to dial a pause. So we could implement all of this in one release or go progressively and handle pause dialing first, then implement the interaction changes.

This has blown up a bit so I'm removing it from any sprint planning until it's figured out more and David is back from PTO.

To recap, The main problem is that the tone duration (300 ms) needs to be controlled by the dialer app using startTone/stopTone methods. When the dialer application goes to background after call screen pops up, we can not accurately call stopTone at the right time using setTimeout, so after few seconds we start hearing long tones (1 second) instead of the short ones (300 ms). I tried to get a cpu lock in the dialer app but it doesn't seemed to change anything. I think the main options we have to fix this are: - We move the tone playing part to the call screen. The dialer communicates with the callscreen someway to tell it that some dtmf tones need to be played during the call. The good thing about this solution is that no changes in the RIL are needed. The bad part is that is more work in the gaia side. - As discused in comment 43 and comment 44, sentTones method could be implemented in the RIL. As sendTones allows you to set the duration of the tone, you no longer need to call stopTone manually later. This will work very easily with the current patch, but this method needs to be implemented in the RIL. - As Anthony suggested, make dial method in telephony support pauses like this telephony.dial('688688668,,,895,,,98'). At the beginning of the bug before we started implementing it, this solution was discarded in favor of implementing it in the gaia side. What do you think Hsin-Yi, Anthony?

(In reply to David Garcia [:davidg] from comment #50) > To recap, > The main problem is that the tone duration (300 ms) needs to be controlled > by the dialer app using startTone/stopTone methods. When the dialer > application goes to background after call screen pops up, we can not > accurately call stopTone at the right time using setTimeout, so after few > seconds we start hearing long tones (1 second) instead of the short ones > (300 ms). > I tried to get a cpu lock in the dialer app but it doesn't seemed to change > anything. > > I think the main options we have to fix this are: > > - We move the tone playing part to the call screen. The dialer communicates > with the callscreen someway to tell it that some dtmf tones need to be > played during the call. The good thing about this solution is that no > changes in the RIL are needed. The bad part is that is more work in the gaia > side. > - As discused in comment 43 and comment 44, sentTones method could be > implemented in the RIL. As sendTones allows you to set the duration of the > tone, you no longer need to call stopTone manually later. This will work > very easily with the current patch, but this method needs to be implemented > in the RIL. This looks good from the platform API's point of view. > - As Anthony suggested, make dial method in telephony support pauses like > this telephony.dial('688688668,,,895,,,98'). At the beginning of the bug > before we started implementing it, this solution was discarded in favor of > implementing it in the gaia side. > I wasn't a big fan of this because 1) comment 15 and 2) another similar feature "dialling <<waiting>>". I know here we are just talking about "dialling <<pause>>." I also understand Anthony proposed |telephony.dial('688688668,,,895,,,98')| is because of the UX requirement - saving the whole string in call log. But, I believe we need to consider the similar "dialling <<wait>>" feature at the same time. The difference between dialling <<pause>> and dialling <<wait>> is in latter, a phone needs to ask for user's confirmation before sending out the DTMF tones. In this case, if we take this approach, both gecko and gaia will need to parse the string, while gecko will only handle the prefix part (dial out that part), and gaia will be the one to control the timing of sending the succeeding DTMF tones. Not sure if we could have another way so that we don't need to parse the string twice. No matter which way we like, I agree that more gecko work needs to be involved. I am not sure about your target date for this, but just for your kind information, our team's resource is nearly occupied in 2.1, even 2.2. > What do you think Hsin-Yi, Anthony?

I'm not sure we need to parse the strings twice. What about this API: partial interface TelephonyCall { attribute string number; // only the number that we call attribute string numberComposed; // full number including pause and/or wait attribute string afterPause; // only the DTMF part attribute string afterWait; // only the DTMF part }; and then, we could just have some if (call.afterPause) and if (call.afterWait) checks in Gaia.

I also commented on bug 1050189, but maybe it makes more sense to ask here. Android only displays the main phone number (no pauses) in the call log, and there is a single entry in the call log for that number no matter if you put pauses in the number or not. Are we sure we want to display pause symbols in call log, and that we want to display different entries in the call log when you dial the same number but using pauses?

(In reply to Carrie Wang [:carrie] from comment #46) > Hi, I'd suggest displaying the exact numbers that user has input from the > dialpad so that he would take it as a reference and also he can tap to call > back from call log as well (we don't want to loose this feature in this > case). Hence, the call log, dialer, in-call screen and the connecting screen > should display these numbers. > > Thanks! Please see comment 53. Sorry, I forgot to hit reply and ni?

ok, I've checked this bug and also 1050189, I'd agree that we show only the phone numbers to keep things simple as comment 48 said. So if users tap the call log, it will dial out but they should input the symbols again to make a call with pause (which means by tapping the call log, we only dial out the main phone numbers). Thanks!

Sorry for the late response. :( I'm simply clearing NI since we don't seem need telephony.dial() api change per latest UX opinion comment 55.

Hi guys, I prepared a new PR synchronised with the Gecko patch validated and proposed by Albert in bug 722841 (see https://bugzilla.mozilla.org/show_bug.cgi?id=722841#c34). As you will see, it is Promise-oriented on the Gecko and on the Gaia side ;)

Comment on attachment 8538408 [details] Pull request 26874 Redirecting to Gabriele.

Comment on attachment 8538408 [details] Pull request 26874 This is generally quite good but I've left some nits to address in the bug and I'd like to see the mock call you've implemented replaced with the mock we already have before landing this.

Comment on attachment 8538408 [details] Pull request 26874 I've had a look at the updated PR and it's looking good. Feel free to land on a green try unless you want to wait for the gecko patches to land first.

Hi! So according to what we have discussed in the PR and once I implemented and pushed the comments I received from Gabrielle (thanks about them, BTW, they were really helpful ;)), this patch would be ready to land once its backend counterpart (bug 722841, currently under review) also lands ;) Consequently, I'll wait until the patch for bug 722841 lands before landing this once to assure everything works as expected :) Thank you very much to everyone involved ;)

Hi Germán, I just played this and patch on bug 722841. Everything works well, thank you.:) However, I noticed that in your code [1], there's a timeout function for pause which seems not necessary to me, because the new API will deal with "pauseDuration" too. Wondering if the code needs a little revision. [1] https://github.com/gtorodelvalle/gaia/commit/d45c26451691e7d24c6cc16d54ae495738c048e4#diff-5103fd344bb675ceaf85e469d6f3022bR78

(In reply to Hsin-Yi Tsai (OOO Jan. 8 ~ Jan. 13) [:hsinyi] from comment #62) > Hi Germán, > I just played this and patch on bug 722841. Everything works well, thank > you.:) > However, I noticed that in your code [1], there's a timeout function for > pause which seems not necessary to me, because the new API will deal with > "pauseDuration" too. Wondering if the code needs a little revision. > > > [1] > https://github.com/gtorodelvalle/gaia/commit/ > d45c26451691e7d24c6cc16d54ae495738c048e4#diff- > 5103fd344bb675ceaf85e469d6f3022bR78 Hi Hsin-Yi, Yeah, you are absolutely right. At a first attempt, the pauses between the tone groups where managed by Gaia but in the latest version of the patch (see attachment 8538408 [details] ) and as agreed with Albert, who I guess agreed on it with you :p, the pauses are passed to and applied by Gecko ;) Thank you very much for your comment!

Once bug 722841 landed last night and after heavily testing the Gecko part covered by that bug and the Gaia part covered by this one, I'm just waiting for the tests to pass to land this patch in master ;)

Given the good state, let's target to get it landed before FLR.

Landed in master: https://github.com/mozilla-b2g/gaia/commit/ba501d6764ae42d2d5cda41243ae31b32a379e72

Tested with today build in Flame( Gecko-7a1f501.Gaia-9946a49) I can enter in my conference bridge by entering first a contact in phonebook with phonenumber plus PIN number. Thanks everyone for your good work!