search

sysapps / telephony

API to manage telephony calls
15 stars 12 forks source link

Call waiting support on CDMA #204

Open hsinyi opened 11 years ago

hsinyi commented 11 years ago

Hi all,

Mozilla has been working on CDMA support recently. And we found that due to the very difference in CDMA network technology, we need to expose an additional attribute 'secondNumber' to TelephonyCall for well addressing CDMA call waiting.

For more background and mozilla's solution, please see [1] and [2]. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=822210#c34 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=822210#c40

zolkis commented 11 years ago

I agree this should be solved in the Telephony API, rather than in telephony middleware. I also agree that it should be solved by changing the TelephonyCall object with a new, specific property, and signal that change on the object through an event.

Then, based on the discussion I think there is a misunderstanding about the callschanged event. We need to update the spec to make it clear that it refers to the calls array being changed, i.e. new calls are added, or calls have been removed from the array/sequence.

Then, the solution in the W3C Telephony API should not be too specific to CDMA, and should not be too specific to this one use case. I would rather use a more generic, parametrized API, which handles the specifics in parameters.

Based on the last two arguments, I would be in favor of introducing a 'callchanged' or 'propertychanged' event on TelephonyCall, with two parameters, the name of the property changed, and the new value of the property. Or, and object parameter, with property/value list that have changed on the TelephonyCall object. This would solve the CDMA use case by firing propertychanged(cdmaCallWaiting, number), which means that TelephonyCall object has a 'cdmaCallWaiting' property when the protocol is CDMA, with the value 'number'. This mechanism would also make possible to accomodate similar protocol differences in the future. BTW the propertyChanged signal is standard in both telephony middleware API's we are using, so I would say that has been a gap in the W3C Telephony API so far, and this use case makes it a good time to fill it.

@marcoscaceres , @efullea : what's your opinion?

zolkis commented 11 years ago

Another way to approach GSM vs CDMA differences would be to use different objects for them, i.e. extending TelephonyCall to TelephonyCallGsm and TelephonyCallCdma, respectively, with possibly different states, property list, and behaviour. Similary, ConferenceCall would be extended to ConferenceGsm, and ConferenceCdma, respectively.

zolkis commented 11 years ago

@hsinyi: any update on this?

I understand the solution you made in FxOS, but for standardization I would go with a slightly different approach: instead of mapping this out in the API, handle it in the API implementation. In the use case you described, based on the spec the implementation should create a second TelephonyCall object (not in RIL), and record the user's choice of rejecting or accepting. Once the call is rejected by the user in CDMA, the call can be marked as disconnected (eventually after a timeout): it is only a matter of time the network will anyway disconnect it. Once the waiting call is accepted, proceed according to the normal state changes (have to detect audio in order to put the call on 'active'). We could use the protocol property on TelephonyService object (or replicate it on TelephonyCall too) to tell which protocol the states are, so dialers would know this was a CDMA call.

hsinyi commented 11 years ago

@zolkis,

I also think it's a great idea that API implementation handles it. However we didn't do that in mozilla API because we didn't get a method to determine which call is active.

Regarding accepting/rejecting a waiting call, it makes sense to me. Regarding detecting a'active' call, would you please share more details about the audio detection in this case?

About one of the two calls (after accepting a waiting call) being released by the remote party, how would you like to handle this? Simply make sure both are moved to 'disconnected' at the end?

zolkis commented 11 years ago

However we didn't do that in mozilla API because we didn't get a method to determine which call is active.

I guess the best effort method is to keep track of the user's choice (in TelephonyCall objects) and what has been told the RIL. So it's guesswork.

Regarding detecting an 'active' call, would you please share more details about the audio detection in this case?

For the 'normal' course of actions with a single call, this gives just a hint, but probably won't help solving the waiting line case at all. There may be audio already in dialing phase (voicemail, etc), so the best an implementation could do is to consider it part of the call in CDMA (since the user is part of the signalling in a way :), i.e. set the 'active' state early. I have not tried this in practice, but if you do and you find it makes the situation manageable, we could make a recommendation note for implementations.

About one of the two calls (after accepting a waiting call) being released by the remote party, how would you like to handle this? Simply make sure both are moved to 'disconnected' at the end?

I am not sure I understand. If the active call is hung, that's normal case - update to disconnected. If the held call is hung, I expect the same - update to disconnected.

zolkis commented 11 years ago

@hsinyi: expanding a bit on the previous. The call waiting flow in CDMA [1]:

  1. The MSC sends a Flash with Information message to the BS to alert the MS that there is a call waiting.
  2. The BS takes the information from the MSC and sends a Flash with Information message to the MS. 3a. The MS sends the Flash with Information message to the BS to indicate the acceptance of the second call. 3a.1. The BS sends a Flash with Information message to the MSC. The MSC then places the original call on hold and connects the second call to the MS. 3a.2. To toggle between the two callers, the MS sends the Flash with Information message to the BS. 3a.3. The BS sends a Flash with Information message to the MSC. The MSC then places the second call on hold and reconnects the original call to the MS. 3b. Similarly, when the waiting call is rejected, the MS sends the Flash with Information message to the BS to indicate the rejection of the second call.

So what the implementation should do:

[1] http://www.3gpp2.org/public_html/specs/A.S0013-0_v1.0.pdf , section 3.4.4. Other references are perhaps more up to date, but the essence is the same.

hsinyi commented 10 years ago

@zolkis thanks for this. After more internal discussion with mozilla ril team, I agree that we should move on as your previous suggestion.

Just one minor implementation issue: after the waiting call has been accepted, then no matter user hangs up either call, both calls are released eventually.