The procedures specified ITU-T Q.1912.5 [9] for profile C shall be applied.

The procedures specified ITU-T Q.1912.5 [9] for profile C shall be applied.

No impact.

No impact.

The procedures specified for Call Forwarding services in TS 23.205, clause 13.4 shall be followed, with the following modifications:

• The call establishment and call clearing procedures defined in clauses 6 and 7 shall be applied;
• The procedures for providing in-band information defined in clause 14.6 shall be applied.
• Failure handling in GMSC and MSC Server shall be supported as specified for basic mobile originating and terminating calls.
• Optimized or Deferred MGW selection may apply for the incoming side bearer establishment and for the establishment of the bearer towards the forwarded-to subscriber, as specified in clauses 4.4.2 and 4.4.3.
• MGW bypass may apply if there is no need for the (G)MSC server to manipulate the bearer or insert inband information and if the call forwarding condition is detected before the incoming side bearer is established.
• The modifications specified in the following clauses shall be applied.

The network model and message sequence specified in TS 23.205, clause 13.4 also apply with the exception that the ISUP ACM/CPG messages are encapsulated within a SIP 183 Session Progress response.

See TS 23.205, clause 13.4.1.

The procedures specified for the Call Hold supplementary service in TS 23.205, clause 13.6 shall be followed, with the following modifications:

• The call establishment and call clearing procedures defined in clauses 6 and 7 shall be applied;
• If an announcement is to be applied to the held party the procedures defined in clause 14.6 shall be applied.
• The Call Hold service shall be supported through ISUP encapsulation and generation of SDP offer as specified by ITU-T Q.1912.5 [9] for profile C.

The SDP offer and encapsulated ISUP CPG message shall be sent within:

• UPDATE message if Hold request occurred before answer (200 OK final response with encapsulated ANM);
• re-INVITE message if Hold request occurred after answer (200 OK final response with encapsulated ANM or CON).

The hold procedure shall be performed by changing the SDP attribute:

• "a=sendonly", if the stream was previously a sendrecv media stream;
• "a=inactive", if the stream was previously a recvonly media stream.

The SDP offer and encapsulated ISUP CPG message shall be sent within:

• UPDATE message if Retrieval request occurred before answer (200 OK final response with encapsulated ANM);
• re-INVITE message if Retrieval request occurred after answer (200 OK final response with encapsulated ANM or CON).

The retrieval procedure shall be performed by changing the SDP attribute:

• "a=sendrecv", if the stream was previously a sendonly media stream, or the attribute can be omitted, since sendrecv is the default;
• "a=recvonly", if the stream was previously an inactive media stream.

The procedures specified for the Multi Party supplementary service in TS 23.205, clause 13.7 shall be followed, with the following modifications:

• If the MGW only supports SIP-I associated Nb, the procedures for establishing the internal Nb bearer between the peripheral context and the Multiparty bridge context shall be in accordance with the standard SIP-I based Nc external bearer setup procedures. The Establish Bearer, Prepare Bearer, Tunnel Information Up and Tunnel Information Down procedures shall be replaced by the Reserve RTP Connection Point, Reserve and Configure RTP Connection Point, Configure RTP connection point.
• If the MGW supports combinations of SIP-I and BICC associated Nb, the MSC-S may establish the internal Nb bearer between the peripheral context and the Multiparty bridge following the standard SIP-I nased Nc or BICC based Nc external bearer setup procedures.
• The MSC-S knows whether the MGW supports SIP-I and/or BICC associated Nb through local configuration data.
• The hold and retrieval of users shall be encoded as described in clause 13.6, with further clarifications in clause 13.7.2.

See TS 23.205, clause 13.7.1. The CPG to inform an active user of the conference establishment shall be encoded in a SIP INFO. For a user on hold, the following applies:

• A CPG to inform the user on hold of the conference establishment shall be sent.
• A CPG to retrieve the user on hold may be sent. The retrieval of the user on hold may also be combined with the conference call establishement in a single CPG.
• a re-INVITE to activate the held media shall be sent.
  • If only a CPG to inform the user on hold of the conference establishment is sent, the re-INVITE shall encapsulate this CPG.
  • If only a single CPG to inform the user on hold of the conference establishment and to retrieve the user on hold is sent, the re-INVITE shall encapsulate this CPG.
  • If seperate CPGs to inform the user on hold of the conference establishment and to retrieve the user on hold are sent, the re-INVITE shall encapsulate the CPG to retrieve the user on hold. The CPG to inform the user on hold of the conference establishment shall be encapsulated in a SIP INFO.

See TS 23.205, clause 13.7.2.

See TS 23.205, clause 13.7.3.

See TS 23.205, clause 13.7.4.

In this example, the procedures for establishing the internal Nb bearer between the peripheral context and the Multiparty bridge context are in accordance with the standard external bearer setup procedures specified for SIP-I based Nc. Figure 13.7.6.1 shows the network model for multi party call. The "squared" line represents the call control signalling. The "dotted" line represents the bearer control signalling and the bearer. Note that for a TDM access there is no separation between the call and bearer control signalling. In the following example it is assumed that each party participating in the Multi Party conference is handled in a separate context representing the call leg between the Multi Party bridge and the Multi Party participant. The Multi Party bridge itself is handled in a separate context. This separation to several contexts is done in order to simplify interactions with other functionality, such as handover, even though other implementation options are not excluded.

For the purposes of the information flow diagrams it is assumed that there are only two remote parties. Party A is the subscriber controlling the Multi Party service (served mobile subscriber). Party B is the held party and party C is the active party. It is assumed that the Multi Party bridge is located in the MGW that has been selected for the served mobile subscriber. Figure 13.7.6.2 shows the message sequence example for the beginning of multi party call. When the served mobile subscriber invokes a Multi Party service the MSC server requests the MGW to create a separate context for the Multi Party bridge. The MSC server seizes a bearer termination for each party in that context. In addition, each call leg is represented by a separate context. Therefore the parties in the active call will be split in separate contexts. The MSC server requests the MGW to create a new context and to move the bearer termination for the served mobile subscriber from the active call context to the new context. To connect the parties to the Multi Party bridge the MSC server requests the MGW to establish internal Nb connections with the PCM codec between the bearer terminations in the Multi Party bridge context and the call leg contexts, using the standard external bearer setup procedures of SIP-I based Nc. The held party is informed about the retrieval of the held call, and the both remote parties are informed about the multi party call establishment.

No impact.

No impact.

The call shall be handled as for other call barring procedures, with the additions as specified for the Anonymous Call Rejection service in TS 23.205, clause 13.11.3 shall be followed, and with the following modifications:

• the procedures for providing in-band information defined in clause 14.6 shall be applied;
• the GMSC Server shall send a 183 message with encapsulated ACM or CPG including cause no. 24 before applying the announcement;
• after the announcement has been completed, the GMSC server shall initiate the call clearing according to clause 7.

Party A is the subscriber controlling the Explicit Call Transfer Call (served mobile subscriber). Party B is the first remote called party (held party). Party C is the second remote called party. MSC-A, MSC-B and MSC-C is the MSC server served for Party A, Party B and Party C respectively. After a call between Party A with Party B has been established successfully and Party B is held, a new call between party A with Party C is established successfully. After getting the ECT request, MSC-A initiates the ECT service procedure by changing through the connection between Party B with Party C. After receiving an ECT request from Party A UE, MSC-A shall retrieve Party B from hold by using a re-INVITE request and through-connection the bearer terminations between Party B and Party C. Additionally, MSC-A sends ECT notifications to MSC-B and MSC-C using INFO requests. Figure 13.12.1 is an example service flow diagram for the ECT service.

See TS 23.205, clause 13.18.1.

See TS 23.205, clause 13.18.2.