Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TS 23.231  Word version:  17.0.0

Top   Top   Up   Prev   Next
1…   4…   4.4.2   4.4.3   4.4.4   4.4.5…   6…   6.1.2…   6.2…   6.2.2…   7…   7.2.3   7.2.4…   7.3…   8…   9…   13…   14…   15…

 

13  Interactions with Other Servicesp. 51

13.1  Enhanced Multi-Level Precedence and Pre-emption service (eMLPP)p. 51

No impact.

13.2  Call Deflection Servicep. 51

The procedures specified for the Call Deflection service in TS 23.205, clause 13.2 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.
  • Optimized or deferred MGW selection may apply for the establishment of the bearer towards the forwarded-to subscriber, as specified in clauses 4.4.2 and 4.4.3.
  • If there is no need for the (G)MSC server to manipulate the bearer, the (G)MSC server may apply MGW bypass as specified in clause 4.4.5. Whilst this is true for CD prior to the assignment, after the assignment, the MSC behaviour should be the same as CFNRy.
Up

13.3  Line identification Servicesp. 51

13.3.1  Calling Line Identification Presentation (CLIP)p. 51

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

13.3.2  Calling Line Identification Restriction (CLIR)p. 51

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

13.3.3  Connected Line Identification Presentation (COLP)p. 52

No impact.

13.3.4  Connected Line Identification Restriction (COLR)p. 52

No impact.

13.4  Call Forwarding Servicesp. 52

13.4.0  Principlesp. 52

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.
Up

13.4.1  Call Forwarding Unconditional (CFU)p. 52

13.4.2  Call Forwarding on mobile subscriber Busy (CFB)p. 52

13.4.2.1  Network Determined User Busy (NDUB)p. 52

13.4.2.1.1  Initial INVITEp. 52
The MSC server shall indicate that preconditions have not been met if either of the following conditions is satisfied before sending the INVITE:
  • the incoming INVITE indicated that the remote preconditions had not been met and no new SDP indicating otherwise had since been received, or
  • MGW selection is required for this call and the incoming side RTP connection point has not been yet successfully reserved and configured in the MGW.
13.4.2.1.2  Confirmation of bearer establishmentp. 52
If the outgoing INVITE indicated that preconditions are yet to be met, the new SDP indicating that the pre-conditions have now been satisfied will be sent when both following conditions are satisfied:
  1. Either:
    1. The incoming INVITE indicated that the remote preconditions were yet to be satisfied, and new SDP indicating that these preconditions have been met has been received, or
    2. The incoming INVITE did not include any preconditions information or indicated that remote preconditions had been met
    and
  2. Either:
    1. The incoming side RTP connection point has been successfully reserved and configured in the MGW.
    2. MGW selection is not required for this call.
Up

13.4.2.2  User Determined User Busy (UDUB)p. 53

13.4.2.2.1  Initial INVITEp. 53
The MSC server shall indicate that preconditions have not been met if either of the following conditions is satisfied before sending the INVITE:
  • the incoming INVITE indicated that the remote preconditions had not been met and no new SDP message indicating otherwise had since been received, or
  • MGW selection is required for this call and the incoming side RTP connection point has not been yet successfully reserved and configured in the MGW.
Up
13.4.2.2.2  Confirmation of bearer establishmentp. 53
If the outgoing INVITE indicated that preconditions are yet to be met, the new SDP indicating that the pre-conditions have now been satisfied will be sent when both following conditions are satisfied:
  1. Either:
    1. The incoming INVITE indicated that the remote preconditions were yet to be satisfied, and new SDP indicating that these preconditions have been met has been received, or
    2. The incoming INVITE did not include any preconditions information or indicated that remote preconditions had been met
    and
  2. Either
    1. The incoming side RTP connection point has been successfully reserved and configured in the MGW.
    2. MGW selection is not required for this call.
Up

13.4.3  Call Forwarding on No Reply (CFNRy)p. 53

13.4.3.1  Initial INVITEp. 53

Following the possible generation of in-band information, the MSC server shall not include any preconditions in the INVITE message because the incoming side bearer has already been established.

13.4.4  Call Forwarding on mobile subscriber Not Reachable (CFNRc)p. 54

13.4.4.1  Initial INVITEp. 54

The MSC server shall indicate that preconditions have not been met if either of the following conditions is satisfied before sending the INVITE:
  • the incoming INVITE indicated that the remote preconditions had not been met and no new SDP message indicating otherwise had since been received, or
  • MGW selection is required for this call and the incoming side RTP connection point has not been yet successfully reserved and configured in the MGW.

13.4.4.2  Confirmation of bearer establishmentp. 54

If the outgoing INVITE indicated that preconditions are yet to be met, and new SDP indicating that the pre-conditions have now been satisfied will be sent when both following conditions are satisfied:
  1. Either:
    1. The incoming INVITE indicated that the remote preconditions were yet to be satisfied, and new SDP indicating that these preconditions have been met has been received, or
    2. The incoming INVITE did not include any preconditions information or indicated that remote preconditions had been met
    and
  2. Either
    1. The incoming side RTP connection point has been successfully reserved and configured in the MGW.
    2. MGW selection is not required for this call.
Up

13.5  Call Waiting (CW)p. 54

The procedures specified for Call Waiting services in TS 23.205, clause 13.5 shall be followed with the modifications:
  • The procedures of "Hold request" for the Call Hold service in clause 13.6 applies for Existing call on hold.
  • The call establishment and call clearing procedures defined in clauses 6 and 7 shall be applied.
Up

13.6  Call Hold (CH)p. 54

13.6.1  Principlesp. 54

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.
Up

13.6.2  Hold Requestp. 54

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.
Up

13.6.3  Retrieval Requestp. 55

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.
Up

13.7  Multiparty (MPTY)p. 55

13.7.1  Introductionp. 55

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.
Up

13.7.2  Beginning the Multi Party callp. 55

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.
Up

13.7.3  Managing an active Multi Party callp. 56

13.7.4  Disconnectp. 56

13.7.5  Failure handling in MSC serverp. 56

13.7.6  Example 1p. 56

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.
Copy of original 3GPP image for 3GPP TS 23.231, Fig. 13.7.6.1: Multi Party call (Network model)
Figure 13.7.6.1: Multi Party call (Network model)
(⇒ copy of original 3GPP image)
Up
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.
Copy of original 3GPP image for 3GPP TS 23.231, Fig. 13.7.6.2: Information flow for multi party call, internal IP bearer (message sequence chart)
Up

13.8  Closed User Group (CUG)p. 58

No impact.

13.9  Advice of Charge (AoC)p. 58

No impact.

13.10  User-to-User Signalling (UUS)p. 59

User to User signalling is supported through ISUP encapsulation, as specified by ITU-T Q.1912.5 [9].

13.11  Call Barring Servicesp. 59

13.11.1  Barring of outgoing callsp. 59

No impact.

13.11.2  Barring of incoming calls other than Anonymous Call Rejectionp. 59

No impact.

13.11.3  Anonymous Call Rejection (ACR) |R11|p. 59

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.
Up

13.12  Explicit Call Transfer (ECT)p. 59

The procedures specified in clause 13.12 of TS 23.205 shall be applied. The example service flow is as shown in the following clause.

13.12.1  Examplep. 59

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.
Copy of original 3GPP image for 3GPP TS 23.231, Fig. 13.12.1: ECT service flow
Figure 13.12.1: ECT service flow
(⇒ copy of original 3GPP image)
Up

13.13  Completion of Calls to Busy Subscriber (CCBS)p. 60

The procedures specified for the Completion of Calls to Busy Subscriber service in TS 23.205, clause 13.13 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.
Up

13.14  Multiple Subscriber Profile (MSP)p. 60

No impact.

13.15  Multicallp. 60

13.16  Calling Name Presentation (CNAP)p. 60

No impact.

13.17  Alternate Speech/Faxp. 60

13.18  Modification of the Access Bearerp. 61

13.19  GSM Faxp. 61

13.20  Voice group call service (VGCS), Voice broadcast service (VBS)p. 61

The procedures specified for the VGCS/VBS supplementary service in TS 23.205, clause 13.20 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 VGCS Multiparty Bridge context shall be in accordance with the standard SIP-I based Nc external bearer setup procedures. The Establish Bearer and Prepare Bearer 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 VGCS Multiparty Bridge context following the standard SIP-I based 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.
Up

Up   Top   ToC