Changes

<h2> Proposed API </h2><p>(lkcl29dec11: remember also to include data calls as well as voice calls, so that internet access can be initiated)</p><p>navigator.telephony would return an object with the following interface

TelephonyCall dial(DOMString number); // Returns a object in &quot;"dialing&quot; " state attribute boolean muted; // Should these live on the call/group? attribute boolean speakerEnabled; attribute any active; // Active call, for now. Could be a group in the future. readonly attribute TelephonyCall[] calls; void startTone(DOMString tone); void stopTone(); attribute Function onincoming; attribute Function oncallschanged; } interface TelephonyCall&#160;: EventTarget { readonly attribute DOMString number; readonly attribute DOMString state; // &quot;"dialing&quot;", &quot;"ringing&quot;", &quot;"busy&quot;", &quot;"connecting&quot;", &quot;"connected&quot;", &quot;"disconnecting&quot;", &quot;"disconnected&quot;", &quot;"incoming&quot;" attribute Function onstatechange; attribute Function onringing; attribute Function onbusy; attribute Function onconnecting; attribute Function onconnected; attribute Function ondisconnecting; attribute Function ondisconnected; void answer(); // Should this make the call the active one? void hangUp(); } interface CallEvent&#160;: Event { readonly attribute TelephonyCall call; }

<h1> Proposal: Enhance telephony call states to hold a call </h1><ul><li> The diagram below shows the current design of B2G telephony call states (white blocks) and the proposal for holding a call (yellow blocks). </li></ul><ul><li> We propose the waiting state because the extra waiting state helps the application understand that there has already been another connected call. If we only have the incoming state, then the application will need to retrieve extra information to know whether there is another call or not.</li></ul><ul><li>State transition in detail:</li></ul><ul><li><ul><li>Scenario #1: There is no other call on-line (current design)<br />When a remote party dials, a new call is generated with its call index (no. 1), and the call state now is CALL_STATE_INCOMING.<br />When user answers/hangs up the call, the call state is eventually pushed to CALL_STATE_CONNECTED/CALL_STATE_DISCONNECTED according to user's decision.<br />**Scenario #2: There is already a call on-line<br />When the third party dials, a new call is generated with its call index. Since there is already a call on-line, the new call's index is no. 2. And the state of Call no. 2 is CALL_STATE_WAITING. When user answers the new call (call no. 2), its state is going to be transferred to CALL_STATE_CONNECTED. In the meanwhile, the state of the originally connected call (call no. 1) should be forced to CALL_STATE_HELD. |Answer()| an INCOMING call and |Answer()| a WAITING call are different.<br />**Scenario #3: User wants to hold a call when there's no waiting call<br />User can |HoldCall()| to change the call state from CALL_STATE_CONNECTED to CALL_STATE_HELD. User can |ResumeCall()| to make a call from CALL_STATE_HELD back to <br />CALL_STATE_CONNECTED.</li></ul></li></ul><p><img src="/images/3/3f/Proposal_TelephonyCallStates.png" _fck_mw_filename="Proposal TelephonyCallStates.png" alt="" /><br />