+ A multiparty call (also commonly referred to as a + conference call) is a telephony call with multiple + remote party participants, which is controlled as a single telephony + call, i.e. it can be held, activated, + disconnected from all participants. Other calls can be joined + with a multiparty call. +
++ Every multiparty call has a unique conference id that + identifies a multiparty call in the system. +
++ A remote party id uniquely identifies a participant + (a.k.a. remote party) in a telephony call in the given telephony + service, such as a phone number. +
++ This of the API version supports GSM multiparty calls and CDMA 3-way + calls. +
++ In the API, a multiparty call is represented by any object that + implements the ConferenceCall interface. +
+
+ The following needs to be described in an algorithm: For multiparty
+ calls, the implementation MUST generate a unique identifier stored in
+ the callId attribute. In GSM, the callId of
+ any participating call could be used in a multiparty operation, and
+ the telephony network will reply with using the same value. But for
+ forward compatibility reasons, the implementation MUST generate a
+ separate callId value for the multiparty call, which
+ MUST be unique in the system and the local call history. For GSM
+ multiparty functionality, The implementation MUST map this to an
+ appropriate transaction identifier accepted by the telephony service.
+ Also, the transaction identifiers received from the network MUST be
+ mapped back by the implementation to the unique conference call
+ identifier of the multiparty call.
+
+ For call setup on received calls, the following call states MUST be + supported in this order: +
+"incoming"/"waiting".
+ "accepted".
+ "active".
+
+ On received calls, telephony protocols also use a
+ "ringing" state, set by the mobile terminal when local
+ call alerting starts, in order to notify the remote party about the
+ ongoing alerting (ringing can actually be e.g. a beep, ring tone, or
+ vibration pattern). This is considered to be responsibility of
+ implementations: if the modem expects this state to be set,
+ implementations MUST make sure to set it. Dialer applications are not
+ expected to set this state in the current version of the
+ specification.
+
+ CDMA cannot report all these states in the expected sequence. The + ‘connected’ state (i.e. when the mobile station send the Service + Connect Completion Message or Connect Order, depending on whether the + call is mobile originated or terminated) is immediately followed by + voice media transmission – there is transition to ‘active’ before the + media arrives. Therefore it should be up to the implementation to + determine which events to fire and in which order. Dialer + applications need to be prepared to handle such cases.
Upon a new incoming or waiting call, the user agent MUST @@ -674,53 +756,13 @@
- A multiparty call (also commonly referred to as a - conference call) is a telephony call with multiple - remote party participants, which is controlled as a single telephony - call, i.e. it can be held, activated, - disconnected from all participants. Other calls can be joined - with a multiparty call. -
-- Every multiparty call has a unique conference id that - identifies a multiparty call in the system. -
-- A remote party id uniquely identifies a participant - (a.k.a. remote party) in a telephony call in the given telephony - service, such as a phone number. -
-- This of the API version supports GSM multiparty calls and CDMA 3-way - calls. -
-- In the API, a multiparty call is represented by any object that - implements the ConferenceCall interface. -
-
- The following needs to be described in an algorithm: For multiparty
- calls, the implementation MUST generate a unique identifier stored in
- the callId attribute. In GSM, the callId of
- any participating call could be used in a multiparty operation, and
- the telephony network will reply with using the same value. But for
- forward compatibility reasons, the implementation MUST generate a
- separate callId value for the multiparty call, which
- MUST be unique in the system and the local call history. For GSM
- multiparty functionality, The implementation MUST map this to an
- appropriate transaction identifier accepted by the telephony service.
- Also, the transaction identifiers received from the network MUST be
- mapped back by the implementation to the unique conference call
- identifier of the multiparty call.
-
- Whenever there is a change in the state attribute the user - agent MUST: -
-statechange with the new value of the state attribute.
- - For call setup on received calls, the following call states MUST be - supported in this order: -
-"incoming"/"waiting".
- "accepted".
- "active".
-
- On received calls, telephony protocols also use a
- "ringing" state, set by the mobile terminal when local
- call alerting starts, in order to notify the remote party about the
- ongoing alerting (ringing can actually be e.g. a beep, ring tone, or
- vibration pattern). This is considered to be responsibility of
- implementations: if the modem expects this state to be set,
- implementations MUST make sure to set it. Dialer applications are not
- expected to set this state in the current version of the
- specification.
-
- CDMA cannot report all these states in the expected sequence. The - ‘connected’ state (i.e. when the mobile station send the Service - Connect Completion Message or Connect Order, depending on whether the - call is mobile originated or terminated) is immediately followed by - voice media transmission – there is transition to ‘active’ before the - media arrives. Therefore it should be up to the implementation to - determine which events to fire and in which order. Dialer - applications need to be prepared to handle such cases. -
-- For call setup on dialed calls, the following call states MUST be - supported in this order: -
-"dialing".
- "alerting".
- "active".
-
- 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. -
-
- When a call monitoring task, previously referred to as
- TCallControl is notified that a dialed call is in
- the process of being connected, it MUST set state to
- "connecting".
-
- When TCallControl is informed that the connection
- has been established and the call is active, it MUST set
- state to "active".
-
- If there is any error during method calls, then the error - steps MUST be executed. -
-
- 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: -
-state of telCall to
- "disconnected".
- statechange at the telCall object.
- disconnected at the telCall object.
-
- 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. -
-+ Whenever there is a change in the state attribute the user + agent MUST: +
+statechange with the new value of the state attribute.
+ + For call setup on dialed calls, the following call states MUST be + supported in this order: +
+"dialing".
+ "alerting".
+ "active".
+
+ 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: +
+state of telCall to
+ "disconnected".
+ statechange at the telCall object.
+ disconnected at the telCall object.
+
+ 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. +
+