869772 - [B2G][CDMA] Send the burst DTMF in CDMA network.

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: RIL, defect)

Description

[Ken Chang[:kenkai]]

We may need this interface, REQUEST_CDMA_BURST_DTMF, to send the burst DTMF in CDMA network.

Comment 1

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Per my previous test, REQUEST_DTMF_START and REQUEST_DTMF_STOP work fine on CDMA as well.

As REQUEST_CDMA_BURST_DTMF takes duration of the dtmf tone as one input parameter that is different from the behaviour of our current WebAPI, WebAPI change needs to be discussed first if we want to support this request.

Comment 2

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Now, we use mozTelephony.startTone() and mozTelephony.stopTone() to control sending DTMF. The underlying ril requests are RIL_REQUEST_DTMF_START and RIL_REQUEST_DTMF_STOP. They are working fine on both gsm and cdma per my test.

There's another ril request RIL_REQUEST_CDMA_BURST_DTMF, which adopts parameters of ON and OFF duration. 

To support user story bug 890816, I think we can have either way:
1) We don't expose new dtmf tone API to Telephony API, instead, we keep using startTone() and stopTone(). Gaia should take care of the tone duration control. Gaia easily maintains a timer, and when time's up, it calls stopTone() to stop sending DTMF, rather than depending on user behaviour.

2) We expose an additional dtmf API, sendTone(DTMFTone, duration, ... ), to Telephony API. Gaia calls sendTone() to control the tone duration, which is not depending on user behaviour either, just same as option 1.

I would say I am inclined to option 1 if we don't see technical difficulty in achieving that, since it's always not so good to have redundant APIs.

Anshul, may I have your insights here? Is option 1 feasible? Thank you.

Comment 3

[Anshul]

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #2)
> Now, we use mozTelephony.startTone() and mozTelephony.stopTone() to control
> sending DTMF. The underlying ril requests are RIL_REQUEST_DTMF_START and
> RIL_REQUEST_DTMF_STOP. They are working fine on both gsm and cdma per my
> test.
> 
> There's another ril request RIL_REQUEST_CDMA_BURST_DTMF, which adopts
> parameters of ON and OFF duration. 
> 
> To support user story bug 890816, I think we can have either way:
> 1) We don't expose new dtmf tone API to Telephony API, instead, we keep
> using startTone() and stopTone(). Gaia should take care of the tone duration
> control. Gaia easily maintains a timer, and when time's up, it calls
> stopTone() to stop sending DTMF, rather than depending on user behaviour.
> 
Hsin-Yi, the option number 1 should work. However please note the following.
1. For normal(short) duration gaia should play the local tone for a specified interval instead of waiting for the key up event. Android plays the tone for 120ms (not sure if this is per a spec). 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.

Hope this helps.

> 2) We expose an additional dtmf API, sendTone(DTMFTone, duration, ... ), to
> Telephony API. Gaia calls sendTone() to control the tone duration, which is
> not depending on user behaviour either, just same as option 1.
> 
> I would say I am inclined to option 1 if we don't see technical difficulty
> in achieving that, since it's always not so good to have redundant APIs.
> 
> Anshul, may I have your insights here? Is option 1 feasible? Thank you.

Comment 4

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Anshul from comment #3)
> (In reply to Hsin-Yi Tsai [:hsinyi] from comment #2)
> > Now, we use mozTelephony.startTone() and mozTelephony.stopTone() to control
> > sending DTMF. The underlying ril requests are RIL_REQUEST_DTMF_START and
> > RIL_REQUEST_DTMF_STOP. They are working fine on both gsm and cdma per my
> > test.
> > 
> > There's another ril request RIL_REQUEST_CDMA_BURST_DTMF, which adopts
> > parameters of ON and OFF duration. 
> > 
> > To support user story bug 890816, I think we can have either way:
> > 1) We don't expose new dtmf tone API to Telephony API, instead, we keep
> > using startTone() and stopTone(). Gaia should take care of the tone duration
> > control. Gaia easily maintains a timer, and when time's up, it calls
> > stopTone() to stop sending DTMF, rather than depending on user behaviour.
> > 
> Hsin-Yi, the option number 1 should work. However please note the following.
> 1. For normal(short) duration gaia should play the local tone for a
> specified interval instead of waiting for the key up event. Android plays
> the tone for 120ms (not sure if this is per a spec). 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.
> 
> Hope this helps.
> 

It does. Thank you for the response.

Comment 5

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Thank to Anshul's response.

koi- because I don't think this bug blocks the user story bug 890816. From the discussion above, we can use the existing startTone() and stopTone() to achieve the user story (see comment #3). It is a nicer solution from the aspect of API, IMO.

Comment 6

[Kai-Chih Hu [:khu]]

So, are you proposing to have another Bugzilla case with the new solution for this user story and koi+ it?

Comment 7

[Hsin-Yi Tsai (she/her) [:hsinyi]]

No, the current gecko is fine. Gaia work is all we need to support that user story.

Comment 8

[Kai-Chih Hu [:khu]]

Awesome! Thank you, Hsinyi!

Comment 9

[Ken Chang[:kenkai]]

According to the comment 7, we should be able to close this bug.