User story: "As a user, I need to be able to select DTMF tone type (normal vs long)·" Acceptance criteria: "User should be able to select DTMF tone type (normal vs long)·"

I don't really get this. Now, we are providing startTone() and stopTone() to send DTMF tone. The tone duration depends on the user input, e.g. how long he presses the button. Any scenario or use cases that user would like to indicate a very specific duration instead of depending on the actual user behaviour?

Sandip, none of us knows the definition of this user story. Can you provide more information about this? Thanks.

There are some systems (carrier voicemails etc) that respond to only short or long DTMF tones. This is about having a settings UI where the user can select what type of tones that would like. The default here is decided by the OEM/carriers, but we should have that UI.

Hi Sandip, How about duration of the long and short tones should be? For example, short tone should last 300ms while long one should last 600ms? Thanks.

(In reply to echu from comment #4) > Hi Sandip, > > How about duration of the long and short tones should be? For example, short > tone should last 300ms while long one should last 600ms? > > Thanks. That is also my question. If we don't have spec. for this user story, we don't have idea of how to implement it.

Talked about Sandip. Need to talk with Ashnul about the definition of normal/long DTMF.

Hi Anshul, any comment?

Please see https://bugzilla.mozilla.org/show_bug.cgi?id=869772#c3

update test case ETA date based on UX ETA date 9/6.

update test case URL.

According to the comment 7 of bug 869772, we should be able to close this bug, bug 869772, and 891746. And then QA can do the test.

Hi Kevin, We need you here. After reading the discuss in bug 869772, I cannot tell whether we need a UI in setting(maybe Call setting) for DTMF tone, letting user to set it as short or long type, which is similar to Android design. I know the acceptance criteria mention it already, but not real clear for the team. Can you specify it again? 1. Will there be a setting for user to choose short or long type? 2. What is the duration of short type? Dev need a specific number such as 300ms. Thanks.

Based on https://bugzilla.mozilla.org/show_bug.cgi?id=869772#c3, it looks like we can use 120ms. Anshul and/or Sandip, what do you think? For the UI, as far as I know, Sandip is proposing to have an UI for this.

We still need to have an UI for this bug. Reopen this bug.

Please note that per bug 869772 comment 3, gaia needs to do: 1) add a settings UI for choosing NORMAL or LONG type of DTMF tone 2) in dialer app, for normal(short) duration gaia should play the local tone for a specified interval instead of waiting for the key up event. For long duration the behavior is the same as we currently have which is to start the tone on key down and stop the tone on key up.

To add to what Hsin-Yi said, the NORMAL tone is only specific to CDMA.

hi sandip, according to the comment #13, normal tone can be set as 120ms. how about the duration for long tone? is it fine to use the same behavior as we currently have which is to start the tone on key down and stop the tone on key up?

Please see the answer in comment #15.

Hi Sandip, since we can not get the long tones Spec., here is my proposal for this user story. We add 1 option, the short tone disable/enable, in settings. If user enables the short tone, the dialler send a tone with 120ms. If user disables the short tone, the dialler will base on our current design to handle the tone. Does it make sense to you?

Agree with Commentx #19. Also Per Comment #8 from Anshul. Let's also check with our OEM partner(s) if this works for them.

Neo, please provide UX. Thanks.

Please check menu tree. In Settings--> Sound

(In reply to Neo Hsieh from comment #22) > Created attachment 797719 [details] > Menu_tree.zip > > Please check menu tree. In Settings--> Sound Neo, please see comment 19.

Sandip, since the spec. is not clear, I would like to remove gaia's implementation from this user story. Once we have carrier's detail requirements, we can start gaia's implementation.

Ken, what part of the UX is not clear? Can the dialer not play the tone for 120ms like Android does for normal tone and retain the current behavior for the long tone. We can always change it once you have more concrete requirements.

(In reply to Anshul from comment #25) > Ken, what part of the UX is not clear? Can the dialer not play the tone for > 120ms like Android does for normal tone and retain the current behavior for > the long tone. We can always change it once you have more concrete > requirements. Can you tell me which partner wants this design? If not, let's start Gaia implementation when we know the "REAL" requirement.

Ken, I agree there are no concrete requirements but the implementation I am proposing is what Android does and most likely would be close to what the future OEM would want. This implementation would give us a chance to test this feature much earlier and help complete the CDMA support in FFOS.

I have tested the Sharp's device and Nexus 4. There aren't this user story in those devices. Also, I don't see this user story is in the Android native UI. So this user story isn't "must have" in some carriers' features list. We should implement it after getting the detail requirements so that we don't waste double efforts in one user story.

Ken, Nexus 4 may not have this, but again that device was not targeted for any particular carrier. What is the problem with implementing what Anshul suggested in #27? We can at least have a proof of concept. The OEM changes there-on if any should not be large but we will get this item off our plate for now rather than fully postponing it.

The problems are 1. This isn't a common user story. We should focus on the common user story. So I wonder if we really need to have this user story now? 2. What kind of concept do we want to prove in this user story? Sending a tone, I think we already have in Firefox OS. The different requirements will introduce different software design and architecture. For example, carrier may ask to have 2 configurations for tone type, carrier may ask one more configuration for turning off tone, or carrier may ask different tone duration. I don't think our current design can prove anything for these requirements. I am not against doing this user story. But we have to be clear to know what can we get from this user story and why should we do this. If we still need to do another implementation after getting a detail information, why do we have to implement this non-real user story now? I still think we should leave this user story to when we get the detail requirement.

(In reply to Ken Chang from comment #19) > Hi Sandip, since we can not get the long tones Spec., here is my proposal > for this user story. We add 1 option, the short tone disable/enable, in > settings. If user enables the short tone, the dialler send a tone with > 120ms. If user disables the short tone, the dialler will base on our current > design to handle the tone. Does it make sense to you? We can finish this one in this week.

All dependent Bugs are close. Close this user story.

Test completed on Wasabi Gaia: c6b4cc05b2de6884a652c1c5ab8401216ffa46c1 Gecko: 78b3dbc50a8cddea792b6c2870c0bfbe3726335c BuildID 20130917062051 Version 26.0a1 Bug 917196 needs to be fixed.

Verified on wasabi. Gaia: 8ff13cf43d185104a000bab68f5eef589b5d8684 Gecko: 41e8c46cb1b8b9b3058b1cbf6525c020bebfc4f0 BuildID 20131120031537 Version 26.0