822210 - B2G CDMA: support call waiting

Status: RESOLVED FIXED

(Firefox OS Graveyard :: RIL, defect)

Description

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

Call waiting of CDMA/EVDO is little bit different from GSM/WCDMA. We shall use "RIL_UNSOLICITED_CDMA_CALL_WAITING" to get the notification of a waiting call, and we need to use "RIL_REQUEST_CDMA_FLASH" to accept/reject it.

The most challenging part of supporting cdma call waiting could be the accurate notification of call state change because it is not known what the status of the call is after a call waiting is answered or a switch between calls.

Comment 1

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

cdma waiting call is quite different from gsm. In gsm, the waiting call occupies a separate connection. The waiting call has its call state and connection, while the 1st connected call also has his owns. However, this is not the case in cdma. 

In cdma, the waiting call shares the same connection with the 1st connected call. User thought he has two calls, while in RIL/operator there is only one connection. RIL receives notification about the cdma waiting call from the operator only when the waiting call first comes. Hereafter, RIL doesn't know anything about the specific state change of a single call even user switches calls or one call is released, until both calls are released.

Due to the obvious difference b/w gsm and cdma, I am thinking of two proposals:
1) We, I mean RIL, create a fake call object when receiving the cdma call waiting notification from the network. Then RIL notifies DOM of a new incoming call. 
** Pros: No changes in Telephony API. Logic of gaia implementation is almost the same, rare change there.
** Cons: The call state isn't synchronous with the operator. RIL should take care of fake call and call state transition by itself. Maintaining the fake call state might be an issue because we got almost nothing from the network. For example, how do we know when to change the waiting call state to disconnected when the remote party hangs it up as we got nothing from the network? 

2) We follow the cdma network behaviour. We don't create a fake object representing the waiting call, simply sending the waiting call notification to DOM instead.
** Pros: RIL is synchronous with the network. RIL reacts according to responses from the network. Implementation would be clear.
** Cons: Need to add a new call waiting event in Telephony API. The event might be redundant in gsm, but essential in cdma. Need changes in gaia, but not sure the feasibility that cdma and gsm code exist in the same file.

I am personally inclined to #2 with the aspect of RIL. Any thoughts?

Comment 2

[Shian-Yow Wu [:swu]]

If adding new event in Telephony API is better for long term, we should go with it as earlier as possible.  For this reason, proposal 2 seems to be a better approach.

Comment 3

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

Attachment: Working branch

Working branch of Proposal#2

Changes cover:
1) nsIDOMTelephony.idl change -- add callwaiting event
2) using simple event codegen to create callwaiting event
3) Telephony DOM impl
4) RIL impl

Comment 4

[Ken Chang[:kenkai]]

I don't think it is reasonable to fake things to eliminate the fundamental protocol differences in RIL. If this issue is because of the fundamental difference between GSM and CDMA network, proposal 2 is better.
But is it possible to send this new waiting event only when the phone camps on CDMA network?

Comment 5

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

(In reply to Ken Chang from comment #4)
> I don't think it is reasonable to fake things to eliminate the fundamental
> protocol differences in RIL. If this issue is because of the fundamental
> difference between GSM and CDMA network, proposal 2 is better.
> But is it possible to send this new waiting event only when the phone camps
> on CDMA network?

We can send the new waiting event only for cdma, but do we want to have an event in nsIDOMTelephony.idl which is dispatched only in cdma? I am not sure.

Comment 7

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

Attachment: Part 1 - idl change - add oncallwaiting event

Comment 8

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

Comment on attachment 747903 [details] [diff] [review]
Part 1 - idl change - add oncallwaiting event

Hi Jonas,

Per partner's request, we are going to support cdma feature.

Due to the very difference between gsm, we need to add one more callwaiting event. Please see my comment #1 for details. 

And even this event is just additional for gsm, I am thinking that we should dispatch the event on both cdma and gsm networks, since I guess it's not a good idea that we reveal something very specific to the hardware or protocol in WebAPI level.

How do you think about this?

Comment 9

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

Comment on attachment 747903 [details] [diff] [review]
Part 1 - idl change - add oncallwaiting event

Cancelling the review request since I am thinking that we would have to come out a thorough picture of how to handle cdma and gsm networks first.

Comment 10

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

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #9)
> Comment on attachment 747903 [details] [diff] [review]
> Part 1 - idl change - add oncallwaiting event
> 
> Cancelling the review request since I am thinking that we would have to come
> out a thorough picture of how to handle cdma and gsm networks first.

Okay, I think the question seems easy here. Simply return an error if user requests a function not supported on a network. However, regarding the case of call waiting, we still need a different solution, i.e. attachment #747903 [details] [diff] [review].

Comment 11

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

Comment on attachment 747903 [details] [diff] [review]
Part 1 - idl change - add oncallwaiting event

Hi Jonas,

I am asking for review again. Please refer to comment #8 for more explanation. Thanks :)

Comment 12

[Anshul]

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #1)
> cdma waiting call is quite different from gsm. In gsm, the waiting call
> occupies a separate connection. The waiting call has its call state and
> connection, while the 1st connected call also has his owns. However, this is
> not the case in cdma. 
> 
> In cdma, the waiting call shares the same connection with the 1st connected
> call. User thought he has two calls, while in RIL/operator there is only one
> connection. RIL receives notification about the cdma waiting call from the
> operator only when the waiting call first comes. Hereafter, RIL doesn't know
> anything about the specific state change of a single call even user switches
> calls or one call is released, until both calls are released.
> 
> Due to the obvious difference b/w gsm and cdma, I am thinking of two
> proposals:
> 1) We, I mean RIL, create a fake call object when receiving the cdma call
> waiting notification from the network. Then RIL notifies DOM of a new
> incoming call. 
> ** Pros: No changes in Telephony API. Logic of gaia implementation is almost
> the same, rare change there.
> ** Cons: The call state isn't synchronous with the operator. RIL should take
> care of fake call and call state transition by itself. Maintaining the fake
> call state might be an issue because we got almost nothing from the network.
> For example, how do we know when to change the waiting call state to
> disconnected when the remote party hangs it up as we got nothing from the
> network? 
Sorry to jump in here Hsin-Yi, but I don't think there is any way to know if one of the calls in call waiting scenario is hungup by the network for CDMA. How does proposal #2 help in this regard?

> 
> 2) We follow the cdma network behaviour. We don't create a fake object
> representing the waiting call, simply sending the waiting call notification
> to DOM instead.
> ** Pros: RIL is synchronous with the network. RIL reacts according to
> responses from the network. Implementation would be clear.
> ** Cons: Need to add a new call waiting event in Telephony API. The event
> might be redundant in gsm, but essential in cdma. Need changes in gaia, but
> not sure the feasibility that cdma and gsm code exist in the same file.
> 
> I am personally inclined to #2 with the aspect of RIL. Any thoughts?

Comment 13

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

(In reply to Anshul from comment #12)
> (In reply to Hsin-Yi Tsai [:hsinyi] from comment #1)
> > cdma waiting call is quite different from gsm. In gsm, the waiting call
> > occupies a separate connection. The waiting call has its call state and
> > connection, while the 1st connected call also has his owns. However, this is
> > not the case in cdma. 
> > 
> > In cdma, the waiting call shares the same connection with the 1st connected
> > call. User thought he has two calls, while in RIL/operator there is only one
> > connection. RIL receives notification about the cdma waiting call from the
> > operator only when the waiting call first comes. Hereafter, RIL doesn't know
> > anything about the specific state change of a single call even user switches
> > calls or one call is released, until both calls are released.
> > 
> > Due to the obvious difference b/w gsm and cdma, I am thinking of two
> > proposals:
> > 1) We, I mean RIL, create a fake call object when receiving the cdma call
> > waiting notification from the network. Then RIL notifies DOM of a new
> > incoming call. 
> > ** Pros: No changes in Telephony API. Logic of gaia implementation is almost
> > the same, rare change there.
> > ** Cons: The call state isn't synchronous with the operator. RIL should take
> > care of fake call and call state transition by itself. Maintaining the fake
> > call state might be an issue because we got almost nothing from the network.
> > For example, how do we know when to change the waiting call state to
> > disconnected when the remote party hangs it up as we got nothing from the
> > network? 
> Sorry to jump in here Hsin-Yi, but I don't think there is any way to know if
> one of the calls in call waiting scenario is hungup by the network for CDMA.
> How does proposal #2 help in this regard?
> 

Thank you for the question, Anshul. Yes, no way to know that situation no matter we take proposal #1 or #2. 

What Proposal #2 tries to do is very simple, totally following cdma networking behaviour, i.s. we send a waiting call notification but we don't create any fake call object for that. So we avoid some problems with maintaining fake call objects.

> 
> 
> > 2) We follow the cdma network behaviour. We don't create a fake object
> > representing the waiting call, simply sending the waiting call notification
> > to DOM instead.
> > ** Pros: RIL is synchronous with the network. RIL reacts according to
> > responses from the network. Implementation would be clear.
> > ** Cons: Need to add a new call waiting event in Telephony API. The event
> > might be redundant in gsm, but essential in cdma. Need changes in gaia, but
> > not sure the feasibility that cdma and gsm code exist in the same file.
> > 
> > I am personally inclined to #2 with the aspect of RIL. Any thoughts?

Comment 14

[Anshul]

Hsin-Yi, is there a UX for CDMA call waiting scenarios? If there is could you please point me to the document?

Comment 15

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

(In reply to Anshul from comment #14)
> Hsin-Yi, is there a UX for CDMA call waiting scenarios? If there is could
> you please point me to the document?

I am asking our UX team for the information. Will keep you updated :)

Comment 16

[Sandip Kamat]

Adding Casey from UX team to review this as a part of CDMA UX support on v1.2

Comment 17

[Casey Yee]

To understand better the behavioral difference in how call waiting works on CDMA, I need to understand the call states that are supported in GSM that are not supported on CDMA.  Can someone detail those for me?   Ideally we preserve the UX that we have currently for call waiting and only adjust for the differences in how the feature is supported.  I would also like to know how this behavior is typically supported on competing devices.

Comment 18

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Comment on attachment 747903 [details] [diff] [review]
Part 1 - idl change - add oncallwaiting event

Review of attachment 747903 [details] [diff] [review]:
-----------------------------------------------------------------

In CDMA, when there's a callwaiting, is the waiting call already connected? If so, should CallWaitingEvent contain a TelephonyCall object rather than a just a number?

Either way, you can use event_impl_gen.conf.in to generate the implementation of the new event, though maybe that's living in a separate patch?

Comment 19

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

(In reply to Jonas Sicking (:sicking) from comment #18)
> Comment on attachment 747903 [details] [diff] [review]
> Part 1 - idl change - add oncallwaiting event
> 
> Review of attachment 747903 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> In CDMA, when there's a callwaiting, is the waiting call already connected?
> If so, should CallWaitingEvent contain a TelephonyCall object rather than a
> just a number?
> 

In cdma, the waiting call shares the same connection with the 1st connected call. User thought he has two calls, but actually in RIL/operator there is only *one* connection, that said only one real call in backend. That's why we can only provide number in CallWaitingEvent rather than a TelephonyCall object of that waiting call, since we don't have that waiting call in backend. It's technique difference between CDMA and GSM. Please see comment #1 for more details.

> Either way, you can use event_impl_gen.conf.in to generate the
> implementation of the new event, though maybe that's living in a separate
> patch?

Yes, I am using that in my WIP. Thank you for the suggestion. :)

Comment 20

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

(In reply to Casey Yee [:cyee] from comment #17)
> To understand better the behavioral difference in how call waiting works on
> CDMA, I need to understand the call states that are supported in GSM that
> are not supported on CDMA.  Can someone detail those for me?   Ideally we
> preserve the UX that we have currently for call waiting and only adjust for
> the differences in how the feature is supported.  I would also like to know
> how this behavior is typically supported on competing devices.

Hi cyee,

I have been trying to explain the difference between gsm and cdma in comment #1. Please let me know if that isn't clear enough or you need more information. :)

Comment 21

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Hi Hsin-Yi,

Thanks, comment #1 explains things well. I do have some followup questions though.

> 1) We, I mean RIL, create a fake call object when receiving the cdma call
> waiting notification from the network. Then RIL notifies DOM of a new
> incoming call. 

Rather than faking the telephony call in the RIL, how about we fake it in the Telephony DOM API instead? It seems like the DOM API is generally simpler than the RIL, so taking on some more complexity there doesn't seem like it would be too bad? It obviously wouldn't address all of the issues that you list below, but maybe it would address some of them?

> ** Pros: No changes in Telephony API. Logic of gaia implementation is almost
> the same, rare change there.
> ** Cons: The call state isn't synchronous with the operator. RIL should take
> care of fake call and call state transition by itself. Maintaining the fake
> call state might be an issue because we got almost nothing from the network.
> For example, how do we know when to change the waiting call state to
> disconnected when the remote party hangs it up as we got nothing from the
> network? 

Is there no way to know that the waiting call has disconnected? In current CDMA phones, what does the UI look like? Does the UI simply show forever that there's another incoming call, and when the user presses the button to answer it, the UI shows some sort of error message?

Ideally I think it's good if we can keep the same API for CDMA and GSM. But only if we can do so sensibly. I.e. it's not ok if that means that we end up with an API that works poorly and doesn't let us build the UI that we want to have.

But I don't think we should be afraid of putting a little bit of complexity in the DOM API. To a limit of course, if things are so complicated to implement that we have to spend a lot of time on it, or will end up with a bunch of bugs, then that's not good.

But the point of having DOM APIs is so that we can hide some of the complexity from the UI developers.

Comment 22

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

Attachment: CDMA android UI - 1) 1st call

Comment 23

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

Attachment: CDMA android UI - 2) 2nd call incoming

Comment 24

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

Attachment: CDMA android UI - 3) accepting 2nd call

Now 1st call is put on hold, and we are talking to the 2nd call. Since no signal tells who we are talking to, UI is able to simply show '正在通話 (connected)' without the exact number of the conversation partner.

Comment 25

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

Attachment: CDMA android UI - 4) switch two calls

This shows the image after we press the switch button. 1st is resumed and 2nd call is on hold now. Note, the UI is exactly the same as 3). We have no idea who we are talking to in CDMA call waiting scenario.

Comment 26

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Hsin-Yi, what is the UI like if the user doesn't accept the second call? How long will the UI show that there's another incoming call?

What is the UI like if the second incoming call hangs up very quickly? I.e. hangs up before the user switches to answer the second call?

Comment 27

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

Attachment: CDMA android UI - 5) 2nd call is released by the remote party

Okay, now 2nd call has been released by the remote party, but UI still remains as 3) and 4). That's because in CDMA call waiting scenario, we have only one real connection. We have no idea when and whether a call is released by the remote party. 

And note that, in CDMA call waiting scenario, we have no way to hang up a specified call. All we can do is hang up both of them at the same time by pressing the red button.

Comment 28

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

Attachment: CDMA android UI - 6) hang up the remaining call

UI displays "通話結束 (call ended)" and the number of the remaining call.

Comment 29

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

(In reply to Jonas Sicking (:sicking) from comment #26)
> Hsin-Yi, what is the UI like if the user doesn't accept the second call? How
> long will the UI show that there's another incoming call?
> 
> What is the UI like if the second incoming call hangs up very quickly? I.e.
> hangs up before the user switches to answer the second call?

Ha, that's another good question!
In CDMA, we don't know whether/when the 2nd incoming call is released even in this case. So, if the 2nd call is released before we answer it, the UI still looks like |Created attachment 762479 [details] CDMA android UI - 2) 2nd call incoming|, until users clicks 'reject' button. And some APP will set a timeout to transit the UI image back to 'connected' screen.

Comment 30

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

(In reply to Jonas Sicking (:sicking) from comment #21)
> Hi Hsin-Yi,
> 
> Thanks, comment #1 explains things well. I do have some followup questions
> though.
> 
> > 1) We, I mean RIL, create a fake call object when receiving the cdma call
> > waiting notification from the network. Then RIL notifies DOM of a new
> > incoming call. 
> 
> Rather than faking the telephony call in the RIL, how about we fake it in
> the Telephony DOM API instead? It seems like the DOM API is generally
> simpler than the RIL, so taking on some more complexity there doesn't seem
> like it would be too bad? It obviously wouldn't address all of the issues
> that you list below, but maybe it would address some of them?
> 

For me, it's not a problem where we fake the telephony call. The main concern I have is "is it a good idea that we fake it?" "What would we expect from the faked call object?" "Is a fake call object helpful in our API design?" "Is it feasible?"

It would be great that we can not only have a fake call object but also maintain its call state transition. But the truth is it's hardly possible. 

If we have a fake waiting call object, we answer the 2nd call as what we do via gsm TelephonyAPI, fakeCall::Answer(). All we can do is change the fakaCall.state from 'incoming' to 'connected' when the request is successfully sent to modem. But that doesn't necessarily reflect the fact. Request being sent to carrier doesn't equal carrier reacting as expected. We can do the same for hold(), resume() and disconnect() but we face the same difficulty.

So IMO the first question would be: do we think it's tolerate that the call state of that fake call object is no guarantee of the truth?

> > ** Pros: No changes in Telephony API. Logic of gaia implementation is almost
> > the same, rare change there.
> > ** Cons: The call state isn't synchronous with the operator. RIL should take
> > care of fake call and call state transition by itself. Maintaining the fake
> > call state might be an issue because we got almost nothing from the network.
> > For example, how do we know when to change the waiting call state to
> > disconnected when the remote party hangs it up as we got nothing from the
> > network? 
> 
> Is there no way to know that the waiting call has disconnected? In current
> CDMA phones, what does the UI look like? Does the UI simply show forever
> that there's another incoming call, and when the user presses the button to
> answer it, the UI shows some sort of error message?
> 

I've already attached some current UI images. :)

> Ideally I think it's good if we can keep the same API for CDMA and GSM. But
> only if we can do so sensibly. I.e. it's not ok if that means that we end up
> with an API that works poorly and doesn't let us build the UI that we want
> to have.
> 
> But I don't think we should be afraid of putting a little bit of complexity
> in the DOM API. To a limit of course, if things are so complicated to
> implement that we have to spend a lot of time on it, or will end up with a
> bunch of bugs, then that's not good.
> 
> But the point of having DOM APIs is so that we can hide some of the
> complexity from the UI developers.

Totally agree with your point of having DOM APIs!

Comment 31

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

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #30)
> (In reply to Jonas Sicking (:sicking) from comment #21)
> > Hi Hsin-Yi,
> > 
> > Thanks, comment #1 explains things well. I do have some followup questions
> > though.
> > 
> > > 1) We, I mean RIL, create a fake call object when receiving the cdma call
> > > waiting notification from the network. Then RIL notifies DOM of a new
> > > incoming call. 
> > 
> > Rather than faking the telephony call in the RIL, how about we fake it in
> > the Telephony DOM API instead? It seems like the DOM API is generally
> > simpler than the RIL, so taking on some more complexity there doesn't seem
> > like it would be too bad? It obviously wouldn't address all of the issues
> > that you list below, but maybe it would address some of them?
> > 
> 
> For me, it's not a problem where we fake the telephony call. The main
> concern I have is "is it a good idea that we fake it?" "What would we expect
> from the faked call object?" "Is a fake call object helpful in our API
> design?" "Is it feasible?"
> 
> It would be great that we can not only have a fake call object but also
> maintain its call state transition. But the truth is it's hardly possible. 
> 
> If we have a fake waiting call object, we answer the 2nd call as what we do
> via gsm TelephonyAPI, fakeCall::Answer(). All we can do is change the
> fakaCall.state from 'incoming' to 'connected' when the request is
> successfully sent to modem. But that doesn't necessarily reflect the fact.
> Request being sent to carrier doesn't equal carrier reacting as expected. We
> can do the same for hold(), resume() and disconnect() but we face the same
> difficulty.
> 
> So IMO the first question would be: do we think it's tolerate that the call
> state of that fake call object is no guarantee of the truth?
> 

And if we don't want to have a fake object, then another question is how we are going to answer it and reject it? Current API/proposal seems not enough...

Comment 32

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

The fact that CDMA doesn't let you hang up just one of the two calls means that we can't really expose the current telephony API and fake two separate Call objects. The existing API lets you hang up the two calls independently.

Even if we did fake other parts of the API, we could never fake that behavior.

So sadly it seems like we're stuck with using a different API for CDMA. Sadness :(

We need to expose more information through the API though, so that the app can switch between the two calls but on the same Call object. Possibly by placing information on the Call object indicating all the numbers that are being handled by it.

But please work with the team building the dialer app for that.

Comment 33

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

(In reply to Jonas Sicking (:sicking) from comment #32)
> The fact that CDMA doesn't let you hang up just one of the two calls means
> that we can't really expose the current telephony API and fake two separate
> Call objects. The existing API lets you hang up the two calls independently.
> 
> Even if we did fake other parts of the API, we could never fake that
> behavior.
> 
> So sadly it seems like we're stuck with using a different API for CDMA.
> Sadness :(
> 
> We need to expose more information through the API though, so that the app
> can switch between the two calls but on the same Call object. Possibly by
> placing information on the Call object indicating all the numbers that are
> being handled by it.
> 

Thanks for the comment, Jonas :)

I am going to add a new attribute nsIDOMTelephonyCall.secondNumber for CDMA waiting scenario so that we could have all information in one call object. Sounds good?

Another question is: should we fire callwaiting event on gsm as well? I guess no, since this event is only additional on gsm and gaia doesn't really want to have a duplicate notification?  
 
> But please work with the team building the dialer app for that.

Sure. I will, with both gaia and UX devs. :)

Comment 34

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

Hi guys,

Due to huge difference b/w gsm and cdma, sadly we need to have a different telephony API. I am trying to explain what the API may look like and how to use that. Please let me know if you have any opinions or questions. And see if it works for the app development.

According to the long long long discussion and explanation above, Jonas and I came to agree to fire a 'callwaiting' event, carrying the waiting call number. We won't fake another call object for that due to cdma technology restriction. So, though we are talking to *two* remote parties, in dialer app, there is only *one* call object. Please keep that in mind and forget what gsm looks like, otherwise you might be driven crazy ;-) 

So, assume we already have the 1st call connected. (var call = mozTelephony.calls[0])
When a waiting call comes in, gecko will:
1) Fire 'callwaiting' event to notify dialer app
2) Update |call.secondNumber| of the 1st call (nsIDOMTelephonyCall.secondNumber is a new attribute going to be added)

Gaia:
* Before we accept the waiting call
1) To get the call waiting number: 'callwaiting' event or call.secondNumber 
2) To answer the waiting call: call.hold(). This will put the 1st call on hold, but please note that on CDMA networks, this does not guarantee that an actual switch between calls took place, because there is no acknowledgement to the module. 
3) To reject the waiting call: NO way to do this! All we can do is remove the incoming call screen when pressing the reject button. So that the user won't be bothered all the time.
4) To know the waiting call is released by the remote party before we answer it: NO way to know. Some APP will set a timeout to transit the UI image back to 'connected' screen.

* After we accept the waiting call
1) To hangup : call.hangup(). Both calls will be released. No way to hang up an individual one.
2) To switch : call.hold(). Same, no acknowledgement of the switch.

Let me know if any questions or comments. Thank you :)

Reference: 
1) http://www.3gpp2.org/Public_html/specs/S.R0006-507-A_v1.0_070624.pdf
2) CDMA AT command: http://www.sendsms.com.cn/download/CDMA_AT_178.pdf Section 8.5

Comment 35

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

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #34)
> Hi guys,
> 
> Due to huge difference b/w gsm and cdma, sadly we need to have a different
> telephony API. I am trying to explain what the API may look like and how to
> use that. Please let me know if you have any opinions or questions. And see
> if it works for the app development.
> 
> According to the long long long discussion and explanation above, Jonas and
> I came to agree to fire a 'callwaiting' event, carrying the waiting call
> number. We won't fake another call object for that due to cdma technology
> restriction. So, though we are talking to *two* remote parties, in dialer
> app, there is only *one* call object. Please keep that in mind and forget
> what gsm looks like, otherwise you might be driven crazy ;-) 
> 
> So, assume we already have the 1st call connected. (var call =
> mozTelephony.calls[0])
> When a waiting call comes in, gecko will:
> 1) Fire 'callwaiting' event to notify dialer app
> 2) Update |call.secondNumber| of the 1st call
> (nsIDOMTelephonyCall.secondNumber is a new attribute going to be added)
> 
> Gaia:
> * Before we accept the waiting call
> 1) To get the call waiting number: 'callwaiting' event or call.secondNumber 
> 2) To answer the waiting call: call.hold(). This will put the 1st call on
> hold, but please note that on CDMA networks, this does not guarantee that an
> actual switch between calls took place, because there is no acknowledgement
> to the module. 
> 3) To reject the waiting call: NO way to do this! All we can do is remove
> the incoming call screen when pressing the reject button. So that the user
> won't be bothered all the time.
> 4) To know the waiting call is released by the remote party before we answer
> it: NO way to know. Some APP will set a timeout to transit the UI image back
> to 'connected' screen.
> 
> * After we accept the waiting call
> 1) To hangup : call.hangup(). Both calls will be released. No way to hang up
> an individual one.
> 2) To switch : call.hold(). Same, no acknowledgement of the switch.

  3) To know the waiting call is released by the remote party: NO way to know. 

> 
> Let me know if any questions or comments. Thank you :)
> 
> Reference: 
> 1) http://www.3gpp2.org/Public_html/specs/S.R0006-507-A_v1.0_070624.pdf
> 2) CDMA AT command: http://www.sendsms.com.cn/download/CDMA_AT_178.pdf
> Section 8.5

Comment 36

[Gabriele Svelto [:gsvelto] (PTO)]

Adding Etienne Segonzac (:etienne) to the CC list because he's the Dialer module owner and he's very likely interested in the discussion and work happening on this bug.

Comment 37

[Gabriele Svelto [:gsvelto] (PTO)]

I've had some time to read through this bug and examine the dialer app so I'll try to describe how these API changes might be handled in the dialer app and what kind of impact that will have.

In general the dialer app relies heavily on the fact that every call has its own object to handle waiting calls and such. The |oncallschanged| callback functions as a hub to handle the various situations (a new call was added, one was removed, etc...) with specific behavior depending on how many calls are there; we also have specialized functions for the situations where the action depends on waiting calls being there (e.g. hold-and-answer, hangup-and-answer, etc...). All of these functions rely on having one call object per actual call and this means that introducing CDMA support will require adding dedicated paths to handle the different state (single call object, two numbers, no idea who's connected and who's not).

In general I'm in favor of the detailed proposal in comment #35 because I think we should not fake any state (that's an excellent way of introducing impossible to debug issues) however this will require some major re-factoring of the dialer. This will almost certainly require dedicated paths for CDMA - alas the Android dialer has them too - and we'll need the appropriate UX for the CDMA-specific situations.

As a third option we might consider changing the API in a way that doesn't add a new event but instead provides a different TelephonyCall object when on CDMA networks. I.e. when a new call is incoming we trigger |oncallschanged| as usual but now the first call has non-null |secondNumber| property and behaves differently (i.e. resume() is a no-op, hold() switches between the calls, etc..). This would allow us to keep some of the infrastructure consistent (hangUp(), |ondisconnected| and friends would still behave as if there's only one call) and limit the number of changes to the API.

Comment 38

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

(In reply to Gabriele Svelto [:gsvelto] from comment #37)
> 
> As a third option we might consider changing the API in a way that doesn't
> add a new event but instead provides a different TelephonyCall object when
> on CDMA networks. I.e. when a new call is incoming we trigger
> |oncallschanged| as usual but now the first call has non-null |secondNumber|
> property and behaves differently (i.e. resume() is a no-op, hold() switches
> between the calls, etc..). This would allow us to keep some of the
> infrastructure consistent (hangUp(), |ondisconnected| and friends would
> still behave as if there's only one call) and limit the number of changes to
> the API.

Making use of existing |callschanged| event seems another good option! It helps maintain a unified API between gsm and cdma networks. So, once gaia gets the call object from |callschanged| event, the API usage is basically the same as comment #34. Except the event itself, I don't see anything different from the proposal in comment #34. Is my understanding correct?

Comment 39

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

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #38)
> (In reply to Gabriele Svelto [:gsvelto] from comment #37)
> > 
> > As a third option we might consider changing the API in a way that doesn't
> > add a new event but instead provides a different TelephonyCall object when
> > on CDMA networks. I.e. when a new call is incoming we trigger
> > |oncallschanged| as usual but now the first call has non-null |secondNumber|
> > property and behaves differently (i.e. resume() is a no-op, hold() switches
> > between the calls, etc..). This would allow us to keep some of the
> > infrastructure consistent (hangUp(), |ondisconnected| and friends would
> > still behave as if there's only one call) and limit the number of changes to
> > the API.
> 
> Making use of existing |callschanged| event seems another good option! It
> helps maintain a unified API between gsm and cdma networks. So, once gaia
> gets the call object from |callschanged| event, the API usage is basically
> the same as comment #34. Except the event itself, I don't see anything
> different from the proposal in comment #34. Is my understanding correct?

And seems like no matter which proposal we take, having dedicated paths for cdma is inevitable as the UX is definitely not the same.

Comment 40

[Gabriele Svelto [:gsvelto] (PTO)]

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #38)
> Making use of existing |callschanged| event seems another good option! It
> helps maintain a unified API between gsm and cdma networks. So, once gaia
> gets the call object from |callschanged| event, the API usage is basically
> the same as comment #34. Except the event itself, I don't see anything
> different from the proposal in comment #34. Is my understanding correct?

Yes, the idea is to only add the nsIDOMTelephonyCall.secondNumber field and use |callschanged| to notify the client code that the field has changed.

> And seems like no matter which proposal we take, having dedicated paths for
> cdma is inevitable as the UX is definitely not the same.

Yes, we've got no way around it.

Comment 41

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

(In reply to Gabriele Svelto [:gsvelto] from comment #40)
> (In reply to Hsin-Yi Tsai [:hsinyi] from comment #38)
> > Making use of existing |callschanged| event seems another good option! It
> > helps maintain a unified API between gsm and cdma networks. So, once gaia
> > gets the call object from |callschanged| event, the API usage is basically
> > the same as comment #34. Except the event itself, I don't see anything
> > different from the proposal in comment #34. Is my understanding correct?
> 
> Yes, the idea is to only add the nsIDOMTelephonyCall.secondNumber field and
> use |callschanged| to notify the client code that the field has changed.
> 

Cool! That sounds good to me as well. :)

> > And seems like no matter which proposal we take, having dedicated paths for
> > cdma is inevitable as the UX is definitely not the same.
> 
> Yes, we've got no way around it.

Comment 42

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

Attachment: part1 - idl

Adding TelephonyCall.secondNumber and using |callschanged| to notify the client code that the field has changed (i.e. a waiting call is coming). See comment #34 and comment #40 for details.

Comment 43

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

Attachment: part2 - telephony DOM

Updating TelephonyCall.secondNumber when notifyCdmaCallWaiting() is called.

Comment 44

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

Attachment: part3 - ril impl

Comment 45

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

Attachment: part4 - BT impl

Comment 46

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

Comment on attachment 783039 [details] [diff] [review]
part1 - idl

Hi Ben and Jonas, 

This is also a v1.2 feature. I am following the discussion above (comment #34 and comment #40). Could you please help review this? Thank you.

Comment 47

[Gina Yeh [:gyeh] [:ginayeh]]

Comment on attachment 783046 [details] [diff] [review]
part4 - BT impl

Review of attachment 783046 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks :)

Comment 48

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

(In reply to Gina Yeh [:gyeh] [:ginayeh] from comment #47)
> Comment on attachment 783046 [details] [diff] [review]
> part4 - BT impl
> 
> Review of attachment 783046 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Thanks :)

Thank you, Gina :P

Comment 49

[Vicamo Yang [:vicamo][:vyang]]

Comment on attachment 783043 [details] [diff] [review]
part3 - ril impl

Review of attachment 783043 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/system/gonk/ril_worker.js
@@ +1920,5 @@
>      if (call && call.state == CALL_STATE_ACTIVE) {
> +      if (this._isCdma) {
> +        Buf.newParcel(REQUEST_CDMA_FLASH);
> +        Buf.writeUint32(1);
> +        Buf.writeUint32("");

Please use |Buf.writeString("")| instead.

Comment 50

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

Attachment: part3 - ril impl (v2)

Addressed reviewer's comment.

Comment 51

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

Comment on attachment 784728 [details] [diff] [review]
part3 - ril impl (v2)

Vicamo, your comment has been addressed. Please help review it again. Thank you!

Comment 52

[Vicamo Yang [:vicamo][:vyang]]

Comment on attachment 784728 [details] [diff] [review]
part3 - ril impl (v2)

Review of attachment 784728 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/system/gonk/RadioInterfaceLayer.js
@@ +933,5 @@
>          this.handleCallDisconnected(message.call);
>          break;
> +      case "cdmaCallWaiting":
> +          gMessageManager.sendTelephonyMessage("RIL:CdmaCallWaiting",
> +                                               this.clientId, message.number);

nit: indentation

Comment 53

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Comment on attachment 783040 [details] [diff] [review]
part2 - telephony DOM

Review of attachment 783040 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/telephony/Telephony.cpp
@@ +564,5 @@
> +{
> +  nsRefPtr<TelephonyCall> callToNotify;
> +  for (uint32_t index = 0; index < mCalls.Length(); index++) {
> +     nsRefPtr<TelephonyCall>& call = mCalls[index];
> +     if (call->CallState() == nsITelephonyProvider::CALL_STATE_CONNECTED) {

Couldn't you just check mActive?

@@ +571,5 @@
> +     }
> +  }
> +
> +  if (!callToNotify) {
> +    return NS_ERROR_UNEXPECTED;

You should always have something here, right? Can we assert that?

::: dom/telephony/TelephonyCall.cpp
@@ +265,5 @@
>      return NS_OK;
>    }
>  
> +  if (!mSecondNumber.IsEmpty()) {
> +    // Use TelephonyCall::Hold() to switch between two remote parties instead.

Maybe NS_WARNING here.

Comment 54

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

Attachment: part1 - idl, sr=sicking, r=bent

Based on bug 888592, webidl.

Comment 55

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

Comment on attachment 786265 [details] [diff] [review]
part1 - idl, sr=sicking, r=bent

Hi Ben, the idl part has been review granted. However I am thinking that you might want to take a look at it since I rebase it on bug 888592, the webidl version. Thank you.

Comment 56

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

Attachment: part2 - telephony dom (v2)

Comment 57

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

(In reply to ben turner [:bent] from comment #53)
> Comment on attachment 783040 [details] [diff] [review]
> part2 - telephony DOM
> 
> Review of attachment 783040 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: dom/telephony/Telephony.cpp
> @@ +564,5 @@
> > +{
> > +  nsRefPtr<TelephonyCall> callToNotify;
> > +  for (uint32_t index = 0; index < mCalls.Length(); index++) {
> > +     nsRefPtr<TelephonyCall>& call = mCalls[index];
> > +     if (call->CallState() == nsITelephonyProvider::CALL_STATE_CONNECTED) {
> 
> Couldn't you just check mActive?
> 

Indeed. Nice suggestion.

> @@ +571,5 @@
> > +     }
> > +  }
> > +
> > +  if (!callToNotify) {
> > +    return NS_ERROR_UNEXPECTED;
> 
> You should always have something here, right? Can we assert that?
> 

MOZ_ASSERT done.

> ::: dom/telephony/TelephonyCall.cpp
> @@ +265,5 @@
> >      return NS_OK;
> >    }
> >  
> > +  if (!mSecondNumber.IsEmpty()) {
> > +    // Use TelephonyCall::Hold() to switch between two remote parties instead.
> 
> Maybe NS_WARNING here.

The condition, i.e. !mSecondNumber.IsEmpty(), won't be touched in fact. Removing the code.

Thank you for the review.

Comment 58

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

Attachment: part3 - ril impl (v3). r=vicamo

Comment addressed.

Comment 59

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Comment on attachment 786269 [details] [diff] [review]
part2 - telephony dom (v2)

Review of attachment 786269 [details] [diff] [review]:
-----------------------------------------------------------------

r=me with this change:

::: dom/telephony/Telephony.cpp
@@ +559,5 @@
> +      mActiveCall->CallState() == nsITelephonyProvider::CALL_STATE_CONNECTED) {
> +    callToNotify = mActiveCall;
> +  }
> +
> +  MOZ_ASSERT(callToNotify);

Hm, wait, if this is assertable then your code should just do this:

  MOZ_ASSERT(mActiveCall &&
             mActiveCall->CallState() == nsITelephonyProvider::CALL_STATE_CONNECTED);

  nsRefPtr<TelephonyCall> callToNotify = mActiveCall;

Comment 60

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

Attachment: part2 - telephony dom (v3). r=bent

Comment 59 addressed.

Comment 61

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

Thanks for the review!
try: https://tbpl.mozilla.org/?tree=Try&rev=c69fe6fb5870

Comment 62

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

https://hg.mozilla.org/integration/b2g-inbound/rev/3af6bb32ac84
https://hg.mozilla.org/integration/b2g-inbound/rev/a50e396cb60a
https://hg.mozilla.org/integration/b2g-inbound/rev/fef9f66d8ae9
https://hg.mozilla.org/integration/b2g-inbound/rev/73f6186de869

Comment 63

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/3af6bb32ac84
https://hg.mozilla.org/mozilla-central/rev/a50e396cb60a
https://hg.mozilla.org/mozilla-central/rev/fef9f66d8ae9
https://hg.mozilla.org/mozilla-central/rev/73f6186de869