From f25cdfcac6f763f271ef15aba53f55a0da7721cc Mon Sep 17 00:00:00 2001 From: Marcos Caceres Date: Mon, 24 Jun 2013 20:41:53 +0100 Subject: [PATCH] More text reshufle (including #176) --- index.html | 273 ++++++++++++++++++++++++----------------------------- 1 file changed, 121 insertions(+), 152 deletions(-) diff --git a/index.html b/index.html index bbd19b0..8901f12 100644 --- a/index.html +++ b/index.html @@ -146,6 +146,12 @@

XMPP conference support.

+

+ It is under discussion whether a system message should be propagated + when a CDMA telephony call is active, since not all CDMA networks + support concurrent services. Therefore, many applications will lose + their data connection when the end user is in a voice call. +

@@ -548,27 +554,46 @@

The call is being split from a multiparty call. -

- Since call state transitions depend on protocol, network equipment, - modem, etc., the implementation MUST NOT fire error events on assumed - erroneous state transitions. MUST always re-synchronize any eventual - internal states to the current call state reported by the telephony - system. The implementation MUST NOT set the call state to any other - value than specified in the descriptions of the methods of this - interface. -

-

- Since call states can differ depending on - the protocol, do we need to expose the service and the protocol used - for making the call? See issue 125. -

-

- Note that compliant implementations may not be reporting such events - when they occur (e.g. OTA SIM update or hot-swappable SIM cards). - See issue - 127. -

+ +
+

+ State changes +

+

+ Whenever there is a change in the state attribute the + user agent MUST: +

+
    +
  1. + Queue a task to fire an event named + statechange with the new value of the state + attribute. +
    2. +
+

+ Since call state transitions depend on protocol, network equipment, + modem, etc., the implementation MUST NOT fire error events on + assumed erroneous state transitions. MUST always re-synchronize any + eventual internal states to the current call state reported by the + telephony system. The implementation MUST NOT set the call state to + any other value than specified in the descriptions of the methods + of this interface. +

+

+ Since call states can differ depending on + the protocol, do we need to expose the service and the protocol + used for making the call? See issue + 125. +

+

+ Note that compliant implementations may not be reporting such + events when they occur (e.g. OTA SIM update or hot-swappable SIM + cards). See issue + 127. +

+

@@ -663,7 +688,7 @@

calls either by a policy, or by the user by choosing which call to accept.

-

+

For call setup on received calls, the following call states MUST be supported in this order:

@@ -749,6 +774,29 @@

user agent relying on the default telephony service of the implementation.

+

+ For call setup on dialed calls, the following call states MUST be + supported in this order: +

+
    +
  1. + "dialing". +
    2. +
  2. + "alerting". +
    3. +
  3. + "active". +
    4. +
+

+ On the telephony services which support the "connecting" + call state (e.g. GSM and CDMA, for call routing, forwarding, + voicemail handling etc), implementations SHOULD support this state + too, between the "dialing" and "alerting" + states. Dialer applications can associate the protocol with the + telephony service used for the call. +

@@ -762,6 +810,35 @@

Disconnecting calls

+

+ When TCallControl is notified of actual call + disconnection of the Call object telCall, it MUST + follow the next steps: +

+
    +
  1. Set the state of telCall to + "disconnected". +
    2. +
  2. + Queue a task to fire an event named + statechange at the telCall object. +
    3. +
  3. + Queue a task to fire an event named + disconnected at the telCall object. +
    4. +
  4. Remove the telCall object from the calls array. +
    5. +
+

+ The param attribute of the disconnected + event MUST be set to the DisconnectReason, if available, or + otherwise it MUST be set to null. At least the following + values MUST be supported for the disconnect reason: + "local", "remote" and + "network". The rest of the DisconnectReason + values SHOULD be supported. +

@@ -1566,6 +1643,18 @@

releasing the multiparty call, and each participating TelephonyCall object.

+

+ If the telephony service is CDMA, throw "NotSupported" DOMError. +

+

+ Depending on the protocol, there may be restrictions on methods. For + instance, GSM does not permit disconnecting a held call. Also, + disconnecting a participant in a held multiparty call is not + supported. Also, if the controlling party disconnects in IS-41 3-way + call in CDMA, then all parties are disconnected, and it is not + possible for the controlling party to disconnect only one participant + (that participant must choose to hang up). +

@@ -1924,6 +2013,11 @@

The redirect() method

+

+ The telephony service in use needs to have the call deflection + feature enabled in order for this method to succeed. For instance, in + GSM, the Call Deflection supplementary service needs to be active. +

The redirect() method initiates deflecting an incoming or waiting telephone call to a remote party. The method takes one @@ -1953,6 +2047,11 @@

The transfer() method

+

+ The telephony service needs to have the call transfer feature + enabled in order for this method to succeed. For instance, in GSM, + the Call Transfer supplementary service needs to be active. +

The transfer() method Initiates transferring the call to a new call between the remote party of this call and another remote @@ -2805,140 +2904,10 @@

TelephonyService Interface

Temp space for text

-

- The TelephonyManager object MUST queue a task - TCallControl for each TelephonyCall or - ConferenceCall object it manages, which MUST listen to any event - that results in changing the call, and upon such events, follow the - steps described in this specification. -

Represents the [[!DTMF]] tone. Its value can be any of the following characters: 0-9; A-D; *; #.

-

- The task TCallControl MUST listen to any event that - results in a call disconnection, and upon such events, follow the steps - described for handling disconnected - calls. -

-

- In this final state ("disconnected"), the implementation MUST throw an - InvalidStateError exception when any method call is - attempted. -

-

- "multiparty call" state: The call is locked in a ConferenceCall - object and MUST NOT be managed any more using this object. While in - this state, the implementation MUST throw an - InvalidStateError exception when any method call is - attempted. -

-
-

- Whenever there is a change in the state attribute the user - agent MUST: -

-
    -
  1. - Queue a task to fire an event named - statechange with the new value of the state attribute. -
    2. -
-

- For call setup on dialed calls, the following call states MUST be - supported in this order: -

-
    -
  1. - "dialing". -
    2. -
  2. - "alerting". -
    3. -
  3. - "active". -
    4. -
-

- On the telephony services which support the "connecting" - call state (e.g. GSM and CDMA, for call routing, forwarding, - voicemail handling etc), implementations SHOULD support this state - too, between the "dialing" and "alerting" - states. Dialer applications can associate the protocol with the - telephony service used for the call. -

-

- It is under discussion whether a system message should be propagated - when a CDMA telephony call is active, since not all CDMA networks - support concurrent services. Therefore, many applications will lose - their data connection when the end user is in a voice call. -

-

- Depending on the protocol, there may be restrictions on methods. For - instance, GSM does not permit disconnecting a held call. Also, - disconnecting a participant in a held multiparty call is not - supported. In such case, the error steps MUST be executed. - Also, if the controlling party disconnects in IS-41 3-way call in - CDMA, then all parties are disconnected, and it is not possible for - the controlling party to disconnect only one participant (that - participant must choose to hang up). Therefore if the telephony - service is CDMA, when invoking the disconnect() method - of a TelephonyCall object participating in a - ConferenceCall the error steps MUST - be executed. -

-

- When TCallControl is notified of actual call - disconnection of the Call object telCall, it MUST - follow the next steps: -

-
    -
  1. Set the state of telCall to - "disconnected". -
    2. -
  2. - Queue a task to fire an event named - statechange at the telCall object. -
    3. -
  3. - Queue a task to fire an event named - disconnected at the telCall object. -
    4. -
  4. Remove the telCall object from the calls array. -
    5. -
-

- The param attribute of the disconnected - event MUST be set to the DisconnectReason, if available, or - otherwise it MUST be set to null. At least the following - values MUST be supported for the disconnect reason: - "local", "remote" and - "network". The rest of the DisconnectReason - values SHOULD be supported. -

-

- When TCallControl is notified that the call has - been put on hold it MUST set state to - "held". -

-

- When TCallControl detects that the call has being - actually resumed it MUST set state to - "active". -

-

- The telephony service in use must have the call deflection feature - enabled in order that this method could succeed. For instance, in - GSM, the Call Deflection supplementary service must be active. -

-

- The telephony service in use must have the call transfer - feature enabled in order that this method could succeed. For - instance, in GSM, the Call Transfer supplementary service must be - active. -

-