Closed Bug 1036305 Opened 10 years ago Closed 6 years ago

[B2G] refine WebAPI for Cdma multiparty call scenario

Categories

(Firefox OS Graveyard :: RIL, defect)

Product:
Firefox OS Graveyard
Component:
RIL
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(tracking-b2g:backlog)

Status:
RESOLVED WONTFIX
Project Flags:
tracking-b2g backlog

People

(Reporter: hsinyi, Unassigned)

References

(
URL
)

Details

(Whiteboard: [grooming])

Attachments

(4 files, 1 obsolete file)

WebAPI for CDMA multiparty call (prior to FxOS v2.2)
72 bytes, text/plain
Details
nsITelephonyService CDMA multiparty call change
1.34 KB, patch
hsinyi
: feedback+
Details | Diff | Splinter Review
internal cdma state transition
55.98 KB, image/png
Details
Interface proposal on Etherpad Lite
57 bytes, text/plain
Details 
The idea showed up again on bug 1029721 comment 10.

I've been thinking about moving the current cdma call waiting API to what we have for gsm. Current API works well on answering and switching calls, but as it provides less information, we've seen some problems:
1) When user rejects the second call, the API and TelephonyService have no idea. That also leads other components monitoring TelephonyService, e.g. BT, to some trouble. If we change the API, then when user rejects the cdma incoming call, BT module as well as TelephonyService knows that. And it's TelephonyService's responsibility to make sure API's behaviour, like CDMA 3-way call.
2) The call log (bug 1029721) is another example. Gecko could do the best guess to provide the most precise information such as call duration if modem doesn't provide customized message.
3) Not being able to provide more call states. If partners want to know specific states of the second call as they require in cdma 3-way call (it's possible with customization), the current API isn't flexible enough.
Hsin-Yi, we are not really a fan of GSM style APIs for CDMA as its an extra burden on the code to fake the calls and makes the code ugly. Would like to talk to you over the video chat to clarify.
(In reply to Anshul from comment #1)
> Hsin-Yi, we are not really a fan of GSM style APIs for CDMA as its an extra
> burden on the code to fake the calls and makes the code ugly. Would like to
> talk to you over the video chat to clarify.

Hi Anshul,

Thanks for the feedback.

Agree with you the gsm style APIs require more work on gecko/platform implementation. But in the mean time, I am still thinking about the use scenarios and the known issues as listed in comment 0. So it is a potential solution, but not a conclusion. :) Let's talk more and see if we could come out a better solution which fits the requirement and also eases implementation.
Summary: [B2G] refine WebAPI for Cdma call waiting scenario → [B2G] refine WebAPI for Cdma multiparty call scenario
Just my 2p. Since most of our issues stem from fundamental incompatibilities between an API designed for GSM operation and the constraints of CDMA technology it might be worthy to completely split them and not pretend they have things in common. We've already plenty of CDMA-specific code in the dialer so trying to mimic the current API is not going to help us. Let's make a clean break and turn a CDMA TelephonyCall into something different that has only the states and methods supported by a CDMA network. This would allow us to express specific states (e.g. call waiting, 3-way calling) that would have no meaning in a GSM network as well as exposing proper methods to handle them (e.g. a switch() function to switch calls in call-waiting mode instead of (ab)using hold()/resume() like we do now).
The original idea, to provide a generic API, was hopefully let application adaptive to different network technologies without worrying the radio tech too much. However, even UX spec requires distinct user behaviour, agree that ambition makes less sense. 

In addition to the incompatibility problem we want to resolve, comment 0 describes several issues that I believe worth being considered all together, especially call log in CDMA, see [1]. Since Gaia now relies on system message to log call information, we might need a new webidl for call info apart from TelephonyCall.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1000485#c6
Hi Hsin-Yi,

I'm attaching a proposed change, for the purpose of discussion, what we think would address the issues with the CDMA multiparty calling at the commercial RIL layer.  Although the change is small, the behaviour would be quite different.

On CDMA, calls to hold/resume/conference/etc. would all fail as only flash() would be supported.  Notices for flash completion and call-waiting would continue as expected and no other signaling for ongoing calls would occur.  I would recommend a corresponding change to webidl, as per our offline discussions, but that's not strictly necessary.

Wrt call-log, inspection of call-log behaviour of commercial devices for a set of requirements is the right way to proceed.  The key is to get data backing up the assumptions that must be made.  This can be done by anyone with a commercial CDMA device.

Michael

Michael
Attachment #8527829 - Flags: review?(htsai)
Comment on attachment 8527829 [details] [diff] [review]
nsITelephonyService CDMA multiparty call change

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

Hello Michael, thanks for the sharing! :) For the internal API nsITelephonyService.idl, 'sendFlash' makes sense.

Aknow and I also had a chat about the whole API (including WebAPI) design. The proposal will be posted later.

The patch's direction looks right, so I mark it f+, instead of r+, because we might need to review it again (e.g. clientId argument) once the whole architecture design is firmed.
Attachment #8527829 - Flags: review?(htsai) → feedback+
Thanks Hsin-Yi.  Please add me to review your proposal when you have it ready.
Hi Gabriele and Michael,

Please see the following proposal and provide some feedback.
The general idea is to unifying gsm and cdma logic.

// Webidl

interface Telephony {
  // One manager for each sim-modem pair.
  Sequence<CallManager> managers;
};

interface CallManager : EventTarget {
  // For cdma 3-way calls, simply calls dial() again. Note that the return
  // TelephonyCall will be the same one.
  Promise<TelephonyCall or MMICall> dial(DOMString number);

  // Can only fulfill emergency calls.
  Promise<TelephonyCall> dialEmergency(DOMString number);

  // If there is a pending incoming/waiting call that need to handle
  readonly attribute TelephonyCallId? incomingCallId;
  Promise answer();  // answer incoming.
  Promise reject();  // reject incoming.

  // gsm: Swap between active and held, cdma: swap between call waiting
  readonly attribute boolean canSwap;
  Promise swap();

  readonly attribute boolean canConference;
  Promise joinConference(); 
  Promise endConference();

  readonly attribute CallsList calls;
  //readonly attribute sequence<TelephonyCall> calls;

  attribute EventHandler onstatechange;
  attribute EventHandler oncallchange;    // CallChangeEvent
  attribute EventHandler oncallincoming;  // CallIncomingEvent
};

interface TelephonyCallId {
  readonly attribute DOMString number;
  readonly attribute CallIdPresentation numberPresentation;
  readonly attribute DOMString name;
  readonly attribute CallIdPresentation namePresentation;
};

// Fire the event if any of fields in the call changed.
interface CallChangeEvent : Event {
  readonly attribute Call call;
};

// Fire the event if there is an incoming/waiting call.
interface CallIncomingEvent: Event {
  readonly attribute TelephonyCallId incomingCallId;
};

enum CallState {
    // "incoming",
    "dialing",
    "alerting",
    "active",
    "disconnected",
    "held"
};

interface TelephonyCall {
  readonly attribute unsigned long serviceId;

  // For cdma call waiting, 3-way call, there may be more than 1 id in a call
  readonly attribute sequence<TelephonyCallId> callIds;

  readonly attribute boolean emergency;
  readonly attribute CallState state;
  readonly attribute DisconnectReason disconnectReason;
  readonly attribute boolean isConference;

  Promise hangup();
  Promise separate();  // Separate the call from conference. (only for gsm).
};


// Internal idl

interface nsITelephonyListener : nsISupports
{ 
  const unsigned short STATE_IDLE = 0;
  const unsigned short STATE_CONNECTED = 1;
  const unsigned short STATE_CDMA_WAITING = 2;
  const unsigned short STATE_CDMA_THREEWAY = 3;
  const unsigned short STATE_CDMA_CONFERENCE = 4;

  // notify the internal state, dom will set 'canSwap' and 'canConference' accordingly.
  // for cdma, see attachment 8529693 [details]
  // for gsm, it will either be STATE_IDLE or STATE_CONNECTED
  void notifyStateChange(in unsigned short state)

  void notifyCallChange(in unsigned long clientId,
                        in unsigned long callIndex,
                        in unsigned short callState,
                        in AString number,
                        in unsigned short numberPresentation,
                        in AString name,
                        in unsigned short namePresentation,
                        in boolean isOutgoing,
                        in boolean isEmergency,
                        in boolean isConference)

  void notifyIncoming(in unsigned long clientId,
                      in AString number,
                      in unsigned short numberPresentation,
                      in AString name,
                      in unsigned short namePresentation);

  // notify the pending incoming call is already be handled.
  void notifyIncomingHandled();
};


Note
----

1. active is removed
    - active could be determined by TelephonyCall.state

2. conferenceGroup is removed.
    - there is no conferenceGroup in cdma    
    - could be determined by check isConference in TelephonyCall.
    - the group consist of calls with their isConference == true

2. The status of canSwap, canConference may be changed if 'statechange' event fired


gsm/cdma common
---------------

Case 1. Automatically select proper service when dialing emergency call
    - Gecko cannot select the sim because we now have separated CallManager
    - User could loop all CallManagers and perform CallManager.dialEmergency
    - Just see which one could fulfill the request

case 2: Incoming call.

1. Fire 'callincoming' event on CallManager
    - CallManager.incomingCallId is set.
    - At this time, the incoming call will not be place into CallManager.calls
2. User need to handle the incoming call.
    - CallManager.answer()
    - CallManager.reject()
3. Place the call into CallManager.calls if user answer it. 


gsm scenario
------------

case 1: Swap calls (swap between active and held)

1. canSwap indicates if the user could swap the calls at this time.
    - dom has the enough information to set the flag
    - condition: has at least two lines (two calls, 1 call and 1 conference)
2. CallManager.swap()

case 2: Conference

1. canConference indicates if the user could conference current calls.
    - dom has the enough information to set the flag
    - condition: has at least two lines (two calls, 1 call and 1 conference)
2. CallManager.conference()
3. Perform operations when conference exists
    - TelephonyCall.hangup()
    - TelephonyCall.separate() 
    - CallManager.endConference()  // all calls in conference will be hungup


cdma scenario
-------------

case 1. Cdma call waiting

0. Have 1 call.
1. Fire 'callincoming' event on CallManager
    - CallManager.incomingCallId is set.
    - At this time, the number of total calls will be 1.
2. User need to handle the incoming call.
    - CallManager.answer()
    - CallManager.reject()
3. User answer the call by CallManager.answer()
    - Number of total calls is still 1
    - nsITelephonyListener.notifyStateChange(STATE_WAITING), Set canSwap to true
    - Phone number of new call will be appended to callIds.
    - Fire callchange event
4. One of the remote party may hang up the call. However, NW will not notify us.
    - In this case, canSwap remains true but calling swap() may not get the expected result.
    - call waiting could happen again. Repeat 1-4

case 2. Cdma 3-way call.

0. Have 1 call.
2. call CallManager.dial() for 2nd call.
    - Number of total calls is still 1
    - nsITelephonyListener.notifyStateChange(STATE_THREEWAY), Set canConference to true
    - Phone number of new call will be appended to callIds.
    - Fire callchange event
3. CallManager.joinConference()
    - nsITelephonyListener.notifyStateChange(STATE_CONFERENCE), Set canConference to false
    - Set TelephonyCall.isConference to true
    - Fire callchange event
4. CallManager.endConference()
Flags: needinfo?(mschwart)
Flags: needinfo?(gsvelto)
Lots of changes here, I'll leave the ni? flag for now as I need to spend some time checking the interactions with the dialer. This seems like a pretty drastic change though, we'll have to be careful not to break stuff.
(In reply to Szu-Yu Chen [:aknow] from comment #10)
> Case 1. Automatically select proper service when dialing emergency call
>     - Gecko cannot select the sim because we now have separated CallManager
>     - User could loop all CallManagers and perform CallManager.dialEmergency
>     - Just see which one could fulfill the request

Lower layers will do best effort attempts to make a call in the emergency case so we need to understand how the API will behave if we attempt a call on CallManager 1 and the call is establish on CallManager 2.

> case 2: Incoming call.
> 
> 1. Fire 'callincoming' event on CallManager
>     - CallManager.incomingCallId is set.
>     - At this time, the incoming call will not be place into
> CallManager.calls
> 2. User need to handle the incoming call.
>     - CallManager.answer()
>     - CallManager.reject()
> 3. Place the call into CallManager.calls if user answer it.

Why not create a call object on incoming as well?  Just trying to understand your design.  Looks like an attempt to combine the CDMA call-waiting behaviour with GSM incoming/cw?

> case 1. Cdma call waiting
> 
> 0. Have 1 call.
> 1. Fire 'callincoming' event on CallManager
>     - CallManager.incomingCallId is set.
>     - At this time, the number of total calls will be 1.
> 2. User need to handle the incoming call.
>     - CallManager.answer()
>     - CallManager.reject()
> 3. User answer the call by CallManager.answer()
>     - Number of total calls is still 1
>     - nsITelephonyListener.notifyStateChange(STATE_WAITING), Set canSwap to
> true
>     - Phone number of new call will be appended to callIds.
>     - Fire callchange event
> 4. One of the remote party may hang up the call. However, NW will not notify
> us.
>     - In this case, canSwap remains true but calling swap() may not get the
> expected result.
>     - call waiting could happen again. Repeat 1-4

Missing from here and your diagram is that the user can also dial three-way

>   readonly attribute CallsList calls;
>   //readonly attribute sequence<TelephonyCall> calls;

How this will be used is not clearly defined by the API.  For example, will back to back CW stack up in the list?  What about CW followed by 3-way will the list expand to include both?

> 0. Have 1 call.
> 2. call CallManager.dial() for 2nd call.
>     - Number of total calls is still 1
>     - nsITelephonyListener.notifyStateChange(STATE_THREEWAY), Set
> canConference to true
>     - Phone number of new call will be appended to callIds.
>     - Fire callchange event
> 3. CallManager.joinConference()
>     - nsITelephonyListener.notifyStateChange(STATE_CONFERENCE), Set
> canConference to false
>     - Set TelephonyCall.isConference to true
>     - Fire callchange event
> 4. CallManager.endConference()

Remember, the user can initiate a 3-way from the 3-way or conference states as well.  Will call.hangUp work?

>   // notify the pending incoming call is already be handled.
>   void notifyIncomingHandled();

What is this for?

Good effort on the first cut.  Since we have so many GSM-only functions, why not include flash for CDMA?
Flags: needinfo?(mschwart)
> > Case 1. Automatically select proper service when dialing emergency call
> >     - Gecko cannot select the sim because we now have separated CallManager
> >     - User could loop all CallManagers and perform CallManager.dialEmergency
> >     - Just see which one could fulfill the request
> 
> Lower layers will do best effort attempts to make a call in the emergency
> case so we need to understand how the API will behave if we attempt a call
> on CallManager 1 and the call is establish on CallManager 2.

Yes, it's a good question and I will think about it. I just think that separating to several CallMangers is a better way because we don't have to provide the parameter 'serviceId' in each API call. But the problem you raised is inevitable, we need to come out the solution.

> > case 2: Incoming call.
> > 
> > 1. Fire 'callincoming' event on CallManager
> >     - CallManager.incomingCallId is set.
> >     - At this time, the incoming call will not be place into
> > CallManager.calls
> > 2. User need to handle the incoming call.
> >     - CallManager.answer()
> >     - CallManager.reject()
> > 3. Place the call into CallManager.calls if user answer it.
> 
> Why not create a call object on incoming as well?  Just trying to understand
> your design.  Looks like an attempt to combine the CDMA call-waiting
> behaviour with GSM incoming/cw?

Yeh, I was attempting to provide a way that could unify handling incoming/waiting call on both gsm and cdma. After further thinking, I feel that putting the incoming call into CallManager.calls won't cause any problem.

> > case 1. Cdma call waiting
> > 
> > 0. Have 1 call.
> > 1. Fire 'callincoming' event on CallManager
> >     - CallManager.incomingCallId is set.
> >     - At this time, the number of total calls will be 1.
> > 2. User need to handle the incoming call.
> >     - CallManager.answer()
> >     - CallManager.reject()
> > 3. User answer the call by CallManager.answer()
> >     - Number of total calls is still 1
> >     - nsITelephonyListener.notifyStateChange(STATE_WAITING), Set canSwap to
> > true
> >     - Phone number of new call will be appended to callIds.
> >     - Fire callchange event
> > 4. One of the remote party may hang up the call. However, NW will not notify
> > us.
> >     - In this case, canSwap remains true but calling swap() may not get the
> > expected result.
> >     - call waiting could happen again. Repeat 1-4
> 
> Missing from here and your diagram is that the user can also dial three-way

What I mean is that after answering the waiting call (CDMA-WAITING state), the call waiting event may happens again. In that case, whether the user answer() or reject() the waiting call, the state remains CDMA-WAITING. This part is missing in the diagram.

We could make the API available to make 3-way call at this moment. However, AFAIK, the feature is blocked from UI.

> 
> >   readonly attribute CallsList calls;
> >   //readonly attribute sequence<TelephonyCall> calls;
> 
> How this will be used is not clearly defined by the API.  For example, will
> back to back CW stack up in the list?  What about CW followed by 3-way will
> the list expand to include both?

No. In these cases, we will only have one call object. I remembered that one of the reasons why we want to refine the cdma API is to get rid of fake call objects. So instead of serveral call objects, we decied to put a list of callIds in one call.

> 
> > 0. Have 1 call.
> > 2. call CallManager.dial() for 2nd call.
> >     - Number of total calls is still 1
> >     - nsITelephonyListener.notifyStateChange(STATE_THREEWAY), Set
> > canConference to true
> >     - Phone number of new call will be appended to callIds.
> >     - Fire callchange event
> > 3. CallManager.joinConference()
> >     - nsITelephonyListener.notifyStateChange(STATE_CONFERENCE), Set
> > canConference to false
> >     - Set TelephonyCall.isConference to true
> >     - Fire callchange event
> > 4. CallManager.endConference()
> 
> Remember, the user can initiate a 3-way from the 3-way or conference states
> as well.  Will call.hangUp work?

We don't have the UI feature to hangup the last call in a conference. So calling hangup() will disconnect all the calls.

> 
> >   // notify the pending incoming call is already be handled.
> >   void notifyIncomingHandled();
> 
> What is this for?

For cdma call waiting, there will be no state change after user's action, no matter answer() or reject(). So we need a way to inform other Telephonies (in different windows) that one of the Telephony has already handled the call. They are not allowed to answer or reject it again. Therefore, after receiving this notification, we simply clear the attribute 'TelephonyCallId' of each Telephony.

> 
> Good effort on the first cut.  Since we have so many GSM-only functions, why
> not include flash for CDMA?

In my opinion, flash() will appear in internal interface but not webidl. The logic behind flash is really complicated and not easy to understand by api user. Instead of that, we provide swap(), joinConference() in web level and they maps to flash() command in TelephonyService.

Actually, we don't have so many gsm-only functions. The only one I can see is TelephonyCall.separate().
(In reply to Szu-Yu Chen [:aknow] from comment #13)
> > Lower layers will do best effort attempts to make a call in the emergency
> > case so we need to understand how the API will behave if we attempt a call
> > on CallManager 1 and the call is establish on CallManager 2.
> 
> Yes, it's a good question and I will think about it. I just think that
> separating to several CallMangers is a better way because we don't have to
> provide the parameter 'serviceId' in each API call. But the problem you
> raised is inevitable, we need to come out the solution.

I agree the serviceId's are clunky.  One simple idea is to add a dial() function to Telephony.  We could return the CallManager as well as the Call.

> > Missing from here and your diagram is that the user can also dial three-way
> 
> What I mean is that after answering the waiting call (CDMA-WAITING state),
> the call waiting event may happens again. In that case, whether the user
> answer() or reject() the waiting call, the state remains CDMA-WAITING. This
> part is missing in the diagram.

I think you did capture that.  What I think you may have missed is that from the call-waiting state, the user should be able to enter Three-Way.  The logic behind this is that a user may have dropped out as you mention in #4.

> 
> We could make the API available to make 3-way call at this moment. However,
> AFAIK, the feature is blocked from UI.

Let's please focus on supporting the spec behaviour as opposed to the current UI behaviour.

> > >   readonly attribute CallsList calls;
> > >   //readonly attribute sequence<TelephonyCall> calls;
> > 
> > How this will be used is not clearly defined by the API.  For example, will
> > back to back CW stack up in the list?  What about CW followed by 3-way will
> > the list expand to include both?
> 
> No. In these cases, we will only have one call object. I remembered that one
> of the reasons why we want to refine the cdma API is to get rid of fake call
> objects. So instead of serveral call objects, we decied to put a list of
> callIds in one call.

Yes, the question is exactly which callIds will be in the list and when.

> > > 4. CallManager.endConference()
> > 
> > Remember, the user can initiate a 3-way from the 3-way or conference states
> > as well.  Will call.hangUp work?
> 
> We don't have the UI feature to hangup the last call in a conference. So calling hangup() will disconnect all the calls.

Just to be clear, TelephonyCall::hangUp will hang-up all calls?  That makes sense to me but might be confusing for folks using this model.

Note that swap() is available in Three-Way and Conference as well.

> > >   // notify the pending incoming call is already be handled.
> > >   void notifyIncomingHandled();
> > 
> > What is this for?
> 
> For cdma call waiting, there will be no state change after user's action, no
> matter answer() or reject(). So we need a way to inform other Telephonies
> (in different windows) that one of the Telephony has already handled the
> call. They are not allowed to answer or reject it again. Therefore, after
> receiving this notification, we simply clear the attribute 'TelephonyCallId'
> of each Telephony.

So TelephonyCallId is only populated during the Incoming Call-Waiting state (not on your list and as opposed to the Ongoing Call-Waiting state)?

> > Good effort on the first cut.  Since we have so many GSM-only functions, why
> > not include flash for CDMA?
> 
> In my opinion, flash() will appear in internal interface but not webidl. The
> logic behind flash is really complicated and not easy to understand by api
> user. Instead of that, we provide swap(), joinConference() in web level and
> they maps to flash() command in TelephonyService.
> 
> Actually, we don't have so many gsm-only functions. The only one I can see
> is TelephonyCall.separate().

Mapping flash to swap/joinConference/dial might be confusing as the results are unknown and inconsistent with their behaviour on a different technology.  By using a different API, flash, no such confusion would exist.
We had some discussion with Gabriele and got a new proposal. I will attach it at the end of the comment and response to the question first.

(In reply to Michael Schwartz [:m4] from comment #14)
> (In reply to Szu-Yu Chen [:aknow] from comment #13)
> > > Lower layers will do best effort attempts to make a call in the emergency
> > > case so we need to understand how the API will behave if we attempt a call
> > > on CallManager 1 and the call is establish on CallManager 2.
> > 
> > Yes, it's a good question and I will think about it. I just think that
> > separating to several CallMangers is a better way because we don't have to
> > provide the parameter 'serviceId' in each API call. But the problem you
> > raised is inevitable, we need to come out the solution.
> 
> I agree the serviceId's are clunky.  One simple idea is to add a dial()
> function to Telephony.  We could return the CallManager as well as the Call.

Now, we have dialEmergency() under Telephony. The function return a promise resolved as a call and there is a serviceId inside which could be used to identify the corresponding CallManager.

> > > Missing from here and your diagram is that the user can also dial three-way
> > 
> > What I mean is that after answering the waiting call (CDMA-WAITING state),
> > the call waiting event may happens again. In that case, whether the user
> > answer() or reject() the waiting call, the state remains CDMA-WAITING. This
> > part is missing in the diagram.
> 
> I think you did capture that.  What I think you may have missed is that from
> the call-waiting state, the user should be able to enter Three-Way.  The
> logic behind this is that a user may have dropped out as you mention in #4.

flash() is exposed and we are not going to maintain the cdma state in gecko so there is no restrictions anymore.

> > We could make the API available to make 3-way call at this moment. However,
> > AFAIK, the feature is blocked from UI.
> 
> Let's please focus on supporting the spec behaviour as opposed to the
> current UI behaviour.

Support in new API.

> 
> > > >   readonly attribute CallsList calls;
> > > >   //readonly attribute sequence<TelephonyCall> calls;
> > > 
> > > How this will be used is not clearly defined by the API.  For example, will
> > > back to back CW stack up in the list?  What about CW followed by 3-way will
> > > the list expand to include both?
> > 
> > No. In these cases, we will only have one call object. I remembered that one
> > of the reasons why we want to refine the cdma API is to get rid of fake call
> > objects. So instead of serveral call objects, we decied to put a list of
> > callIds in one call.
> 
> Yes, the question is exactly which callIds will be in the list and when.

For cdma call waiting, the id of the second call will be added into the list when it happenes (before the user's action).

> > > > 4. CallManager.endConference()
> > > 
> > > Remember, the user can initiate a 3-way from the 3-way or conference states
> > > as well.  Will call.hangUp work?
> > 
> > We don't have the UI feature to hangup the last call in a conference. So calling hangup() will disconnect all the calls.
> 
> Just to be clear, TelephonyCall::hangUp will hang-up all calls?  That makes
> sense to me but might be confusing for folks using this model.

We have another function called hangupAll() which might be more meaningful.

> Note that swap() is available in Three-Way and Conference as well.
> 
> > > >   // notify the pending incoming call is already be handled.
> > > >   void notifyIncomingHandled();
> > > 
> > > What is this for?
> > 
> > For cdma call waiting, there will be no state change after user's action, no
> > matter answer() or reject(). So we need a way to inform other Telephonies
> > (in different windows) that one of the Telephony has already handled the
> > call. They are not allowed to answer or reject it again. Therefore, after
> > receiving this notification, we simply clear the attribute 'TelephonyCallId'
> > of each Telephony.
> 
> So TelephonyCallId is only populated during the Incoming Call-Waiting state
> (not on your list and as opposed to the Ongoing Call-Waiting state)?

Sorry, I meant incomingCallId, which will be popuated for incoming call and waiting call as well.

> > > Good effort on the first cut.  Since we have so many GSM-only functions, why
> > > not include flash for CDMA?
> > 
> > In my opinion, flash() will appear in internal interface but not webidl. The
> > logic behind flash is really complicated and not easy to understand by api
> > user. Instead of that, we provide swap(), joinConference() in web level and
> > they maps to flash() command in TelephonyService.
> > 
> > Actually, we don't have so many gsm-only functions. The only one I can see
> > is TelephonyCall.separate().
> 
> Mapping flash to swap/joinConference/dial might be confusing as the results
> are unknown and inconsistent with their behaviour on a different technology.
> By using a different API, flash, no such confusion would exist.

Yes, you are right. We add flash().



// Webidl

interface Telephony {
  // Can only fulfill emergency calls.
  Promise<TelephonyCall> dialEmergency(DOMString number);

  // One manager for each sim-modem pair.
  Sequence<CallManager> managers;
};

interface CallManger : EventTarget {
  // For cdma 3-way calls, simply calls dial() again. Note that the return
  // TelephonyCall will be the same one.
  Promise<TelephonyCall or MMICall> dial(DOMString number);
  Promise hangupAll();
  Promise answer();  // answer incoming.
  Promise reject();  // reject incoming.

  // If there is a pending incoming/waiting call that need to handle
  readonly attribute TelephonyCallId? incomingCallId;
  readonly attribute CallsList calls;

  attribute EventHandler oncallchange;    // CallChangeEvent
  attribute EventHandler oncallincoming;  // CallIncomingEvent
};

interface GsmCallManager : CallManger {
  Promise swap();
  Promise startConference();
  Promise hangupConference();
};

interface CdmaCallManager : CallManger {
  Promise flash();
};

interface TelephonyCallId {
  readonly attribute DOMString number;
  readonly attribute CallIdPresentation numberPresentation;
  readonly attribute DOMString name;
  readonly attribute CallIdPresentation namePresentation;
};

// Fire the event if any of fields in the call changed.
interface CallChangeEvent : Event {
  readonly attribute Call call;
};

// Fire the event if there is an incoming/waiting call.
interface CallIncomingEvent: Event {
  readonly attribute TelephonyCallId incomingCallId;
};

enum CallState {
    "incoming",
    "dialing",
    "alerting",
    "active",
    "disconnected",
    "held"
};

interface TelephonyCall {
  readonly attribute unsigned long serviceId;

  // For cdma call waiting, 3-way call, there may be more than 1 id in a call
  readonly attribute sequence<TelephonyCallId> callIds;

  readonly attribute boolean emergency;
  readonly attribute CallState state;
  readonly attribute DisconnectReason disconnectReason;
  readonly attribute boolean? isConference; // only for gsm

  Promise hangup();
  Promise separate();  // Separate the call from conference. (only for gsm).
};


// Internal idl

interface nsITelephonyListener : nsISupports
{
  void notifyCallChange(in unsigned long clientId,
                        in unsigned long callIndex,
                        in unsigned short callState,
                        in AString number,
                        in unsigned short numberPresentation,
                        in AString name,
                        in unsigned short namePresentation,
                        in boolean isOutgoing,
                        in boolean isEmergency,
                        in boolean isConference)

  void notifyIncoming(in unsigned long clientId,
                      in AString number,
                      in unsigned short numberPresentation,
                      in AString name,
                      in unsigned short namePresentation);

  // notify the pending incoming call is already be handled.
  void notifyIncomingHandled();
};
interface Telephony {
  Sequence<CallManager> managers;
  attribute EventHandler onmanagerchange; // naming could be discussed
};

There will be N managers if we have N SIM. Each of them is one of the following: GsmCallManager, CdmaCallManager, or null. Adding null is for the case that radio is not available on that SIM. In that case, we don't know the exact technlogy and all the actions are not allowed on this CallManager. Therefore, we decided to set it to null. Once the radio changed to on, the corresponding CallManager will be created. That means we will need an event to notify our client so I add "onmanagerchange" in Telephony interface.
[Tracking Requested - why for this release]:
tracking-b2g: --- → ?
Clearing my needinfo as we discussed the previous proposal in person and the outcome was basically the new one.
Flags: needinfo?(gsvelto)
Thanks Gabriele for the discussion :)

Hi Anshul,
We'd like to move the refinement work forward in the first quarter. We've answered :m4's questions on etherpad, attachment 8532645 [details]. Is it possible that your team could take a look and provide feedback again by the end of this month? Do appreciate your help!
Flags: needinfo?(anshulj)
Yes Hsin-Yi, let me work with M4 and review the proposal and your comments.
Flags: needinfo?(anshulj) → needinfo?(mschwart)
blocking-b2g: --- → backlog
Whiteboard: [grooming]
(In reply to Hsin-Yi Tsai [:hsinyi] from comment #20)
> Thanks Gabriele for the discussion :)
> 
> Hi Anshul,
> We'd like to move the refinement work forward in the first quarter. We've
> answered :m4's questions on etherpad, attachment 8532645 [details]. Is it
> possible that your team could take a look and provide feedback again by the
> end of this month? Do appreciate your help!

Hi :m4,

Sorry for pining you again. But since it past January, any updates on this? Thank you.
(In reply to Hsin-Yi Tsai [:hsinyi] from comment #22)

Thank you for your hard work and sorry for my slow responses.  I've responded in the etherpad.
Flags: needinfo?(mschwart)
(In reply to Michael Schwartz [:m4] from comment #23)
> (In reply to Hsin-Yi Tsai [:hsinyi] from comment #22)
> 
> Thank you for your hard work and sorry for my slow responses.  I've
> responded in the etherpad.

Michael, I think we can go with your comment on "flash() with string". But we also have some concerns on the android generic state proposal. Please find our responses in details on the etherpad, thank you for the discussion.
Flags: needinfo?(mschwart)
blocking-b2g: backlog → ---
Thanks for your replies.  I replied again but only this remains:

  readonly attribute sequence<TelephonyCallId> callIds;

If we keep that for CDMA conference calling then could we add a comment that says the list may be incorrect?
Flags: needinfo?(mschwart)

        Attachment #8532645 -
        Attachment is obsolete: true

    
    

    
  
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: