Content for TS 23.228 Word version: 19.0.0

1… 3… 4… 4.2.4… 4.3… 4.4… 4.13… 4.16… 5… 5.2… 5.3… 5.4… 5.4.7… 5.4.8… 5.4a… 5.5… 5.5.3… 5.6… 5.6.3… 5.7… 5.7.3… 5.7.5… 5.7.8… 5.8… 5.10… 5.11… 5.11.3… 5.11.3.3 5.11.3.4 5.11.4… 5.11.5… 5.11.5.3… 5.11.6… 5.12… 5.16… 5.16.2… 5.19… 5.20… A… E… E.2.2… G… G.5… H I… J… K… L… M… M.3… N… P… Q… Q.2.5… R… S… T… U… U.2… V… W… X… Y… Z… AA… AA.3… AB… AC… AC.7… AC.7.2… AC.7.2.2 AC.7.2.3… AC.7.4… AC.9… AC.10…

5.4 Procedures for IP multi-media sessions 5.4.0 General 5.4.1 Bearer interworking concepts 5.4.2 Interworking with Internet 5.4.2a IP version interworking 5.4.3 Interworking with PSTN 5.4.4 Requirements for IP multi-media session control 5.4.5 Session Path Information 5.4.5.1 Session Path Information during Registration and Session Initiation 5.4.5.2 P-CSCF in the Session Path 5.4.5.3 S-CSCF in the Session Path 5.4.6 End-user preferences and terminal capabilities 5.4.6.0 General 5.4.6.1 Objectives 5.4.6.2 End-user expectations 5.4.6.3 Mechanism for bearer establishment 5.4.6.4 Session progress indication to the originating UE
...

5.4 Procedures for IP multi-media sessions p. 88

5.4.0 General |R6| p. 88

Basic IMS sessions between users will always involve two S-CSCFs (one S-CSCF for each). The session flow is decomposed into two parts: an origination part between the UE & the S-CSCF and termination part between the S-CSCF and the UE, including all network elements in the path.

A basic session between a user and a PSTN endpoint involves an S-CSCF for the UE, a BGCF to select the PSTN gateway, and an MGCF for the PSTN.

The session flow is decomposed into three parts - an origination part, an inter-Serving-CSCF/ MGCF part, and a termination part. The origination part covers all network elements between the UE (or PSTN) and the S-CSCF for that UE (or MGCF serving the MGW). The termination part covers all network elements between the S-CSCF for the UE (or MGCF serving the MGW) and the UE (or PSTN).

5.4.1 Bearer interworking concepts p. 88

Voice bearers from the IM CN subsystem need to be connected with the voice bearers of other networks. Elements such as Media Gateway Functions (MGW) are provided to support such bearer interworking. One of the functions of the MGW may be to support transcoding between a codec used by the UE in the IM CN subsystem and the codec being used in the network of the other party.

Default codecs to be supported within the UE are IP-CAN dependent and hence are defined in the respective IP-CAN specific documents. The use of default codecs within the UE enables the IM CN subsystem to interwork with other networks on an end to end basis or through transcoding.

The IM CN subsystem is also able to interwork with the CS networks (e.g. PSTN, ISDN, CS domain of some PLMN) by supporting transcoding in the IMS MGW element. Furthermore to allow interworking between users of the IM CN subsystem and IP multimedia fixed terminals and other codecs may (this is implementation dependent) be supported by the MGW.

In order to support existing network capabilities, it is required that IMS supports endpoints (e.g. UE, MRFP, MGCF for interworking with the PSTN) able to send or receive DTMF tone indications using the bearer, i.e. inband signalling. An additional element for bearer interworking is the interworking of these DTMF tones and out-of-band signalling between one network and another. In such a case, the MGW shall provide tone generation and may provide detection under the control of the MGCF.

5.4.2 Interworking with Internet p. 88

Depending on operator policy, the S-CSCF may forward the SIP request or response to another SIP server located within an ISP domain outside of the IM CN subsystem.

It is possible that the external SIP client does not support one or more of the SIP extensions required for IMS end points to set up IMS sessions (e.g. Preconditions, Update, 100Rel) as described in TS 24.229, then the UE or other SIP user agents within the IMS should be able to fall back to SIP procedures which allow interworking towards the external client. Depending on the home network operator policy, the network may restrict session initiation requests towards and from external SIP clients without the support of SIP extensions defined for IMS sessions.

5.4.2a IP version interworking |R6| p. 89

Following interworking scenarios exist:

Application Level Interworking

It should be possible for users connected to an IMS network to communicate with users that are connected to SIP based networks that use a different IP version via interworking or that are in a separate addressing range (e.g. NA(P)T functionality is set at the border of the IMS). Annex I describes in more detail how such interworking is performed for IMS.

Transport Level Interworking

Inter-working also includes tunnelling level interconnection of IMS networks via transit networks that use a different IP version using for example, configured tunnels as described in TS 23.221. Figure 5.5b below shows an example configuration scenario where two IPv6 IMS networks are connected via an IPv4 network.

Reproduction of 3GPP TS 23.228, Fig. 5.5b: Example tunnelling of IPv6 traffic over IPv4 networks

Figure 5.5b: Example tunnelling of IPv6 traffic over IPv4 networks

5.4.3 Interworking with PSTN p. 89

The S-CSCF, possibly in conjunction with an Application Server, shall determine that the session should be forwarded to the PSTN. The S-CSCF will forward the Invite information flow to the BGCF in the same network.

The BGCF selects the network in which the interworking should occur, and the selection of the interworking network is based on local policy.

If the BGCF determines that the interworking should occur in the same network, then the BGCF selects the MGCF which will perform the interworking, otherwise the BGCF forward the invite information flow to the BGCF in the selected network.

The MGCF will perform the interworking to the PSTN and control the MG for the media conversions.

The high level overview of the network initiated PSTN interworking process is shown in Figure 5.6.

Reproduction of 3GPP TS 23.228, Fig. 5.6: Network based PSTN interworking breakout process

Figure 5.6: Network based PSTN interworking breakout process

5.4.4 Requirements for IP multi-media session control p. 90

In order for operators to be able to offer a "carrier-grade" IP multimedia service, and to require bearers whose features (e.g. Bandwidth) are coherent with the media components negotiated through CSCFs, the following features shall be offered:

Both end points of the session shall be able to negotiate (according to service /UE settings,) which resources (i.e. which media components) need to be established before the destination party is alerted. The session signalling shall ensure that these resources (including IP-Connectivity Access Network resources and IP multimedia backbone resources) are made available or reserved before the destination UE rings.
This should nevertheless not prevent the UE from offering to the end-user the choice of accepting or rejecting the components of the session before establishing the bearers.
Depending on regulatory requirements, the IP multimedia service shall be able to charge the originating party for the IP-Connectivity Access Network service of both originating and destination side or when reverse charging applies to charge the terminating party for the IP-Connectivity Access Network service of both originating and terminating side. This implies that it should be easy to correlate CDR held by the IP-Connectivity Access Network service with a session.
The session control function of IP multimedia network of an operator (CSCF) shall be able (according to operator choice) to have a strict control (e.g. on source /destination IP address, QoS) on the flows associated with session established through SIP entering the IP multimedia bearer network from IP-Connectivity Access Network service. This does not mean that CSCF is the enforcement point (which actually is the Gateway between the IP-Connectivity Access Network and the IP multimedia network) but that the CSCF may be the final decision point for this control.
The session control and bearer control mechanisms shall allow the session control to decide when user plane traffic between end-points of a SIP session may start/shall stop. This allows this traffic to start/stop in synchronisation with the start/stop of charging for a session.
The IP-Connectivity Access Network service shall be able to notify the IP multimedia session control when the IP-Connectivity Access Network service has either modified or suspended or released the bearer(s) of a user associated with a session (because e.g. the user is no longer reachable).
The solution shall comply with the architectural rules relating to separation of bearer level, session control level, and service level.

5.4.5 Session Path Information p. 91

5.4.5.1 Session Path Information during Registration and Session Initiation |R6| p. 91

During registration and session initiation there are SIP mechanisms, which provide the means to determine the session path.

After registration the P-CSCF stores the S-CSCF name, possibly IBCF names and the S-CSCF stores the P-CSCF name and possibly IBCF names (see 4.3.4) as part of the UE related information.

There is a need to store the session path that is determined during the session initiation request in order to route the subsequent session requests through this determined path. This is needed in order to route these session requests through certain nodes, e.g. the ones performing Service Control, or interconnect functions. CSCFs are assumed to perform certain actions:

CSCFs (Proxy and Serving) store a certain part of the session path determined during session initiation. This allows CSCFs to generate requests that traverse all elements on a Route path.
The P-CSCF shall check correct usage of the header values. Should an UE build inaccurate header(s) in a SIP request, the P-CSCF may reject the request. If an operator policy requires enforcing the routes stored in P-CSCF, the P-CSCF shall overwrite the header(s) provided by the UE with the appropriate values.

5.4.5.2 P-CSCF in the Session Path |R6| p. 91

All SIP signalling to or from the UE traverses the P-CSCF.

5.4.5.3 S-CSCF in the Session Path |R6| p. 91

All initial requests to or from the UE traverse the S-CSCF assigned to the UE. The S-CSCF uses the "Record-Route" mechanism defined in RFC 3261 to remain in the signalling path for subsequent requests too; in short terms: the S-CSCF "record-routes". This is considered the default behaviour for all IMS communication. However, if Application Servers under operator control guarantee the home control of the session, then it may not be required that all subsequent requests traverse the S-CSCF. In such cases the operator may choose that the S-CSCF does not "record-route". The detailed record-route behaviour is configured in the S-CSCF, e.g. on a per-service basis. The S-CSCF decides whether it performs record-routing or not based on operator configuration in the S-CSCF.

See also Annex F for background information.

5.4.6 End-user preferences and terminal capabilities p. 91

5.4.6.0 General |R6| p. 91

Due to different capabilities of the originating and terminating terminals, it might not be possible to establish all the media suggested by the originator for a particular session. In addition, the destination user may have different preferences of type of media depending on who is originating and on the situation e.g. being in a meeting or driving the car, etc.

5.4.6.1 Objectives p. 91

The general objectives concerning terminal capabilities and end-user behaviour are listed below.

The capabilities of the terminal have impact on the SDP description in the SIP session flows, since different terminals may support different media types (such as video, audio, application or data) and may have implemented different set of codecs for audio and video. Note that the capabilities of the terminal may change when an external device, such as a video camera is attached to the terminal.
The configuration of the terminal changes the capabilities of the terminal. This can be done by attaching external devices or possibly by a user setting of certain parameters or profiles in the terminal.
The preferences of the destination user may depend on who is originating the session and on the situation. Cost, associated with the session, may also be another factor, i.e. depending on time of the day or day of the week etc. Due to this reason the user may want to accept or reject certain media components.
The available resources in the network play an important role, as certain media streams, consuming high bandwidth, may be denied. Therefore, before the user is alerted that the session set up is successful, it is assumed that the network has guaranteed and has reserved the needed resources for one or several media streams of the session. This does not preclude the possibility for the user to indicate his/her preferences regarding the session also after the alerting, in which case the initial resource reservations may have to be modified.
End-to-end quality of service may be provided by using a variety of mechanisms, including guaranteed end-to-end QoS and best effort. The network may not be able to guarantee the requested end-to-end QoS. This may be the case when the user is establishing sessions through the public Internet. On the other hand, certain sessions, with the agreement of the initiating and terminating endpoints, should have the right to go through even without having the requested QoS guarantee.

5.4.6.2 End-user expectations p. 92

From the end-user point of view the following user interactions can be listed:

For outgoing sessions, it is assumed that the user would like to select certain parameters that define the proposed session. This can be pre-configured as preferences or defined on a per session basis.
For incoming sessions, it is assumed that the terminal will establish a dialogue with the user. Such dialogue allows the user to manually accept some of the proposed parameters by the originator. This is typically media type (audio, video, whiteboard) and different quality parameters per media type. As an alternative, the user preferences may be pre-configured.
Before establishing or accepting a new session, the user may define or agree on the following parameters. Some of these parameters may be pre-configured and others are defined on a per session basis.
1. Type of media, i.e. audio, video, whiteboard, etc. This represents the user preferences of media types.
2. Combination of QoS attributes and selection of codec. This represents the quality of the media component, the cost and the probability of availability of resources both in the access network and in the core network.
3. Subset of capabilities used in the terminal. Terminals can have different set of capabilities. However, the user may or may not want to use the maximum set of capabilities. For instance, a user might want to establish a low cost video session with a small window on the screen.
4. End-to-end quality of service. For certain media streams, the user may want assured end-to-end QoS while for other streams the QoS may be optional or even not desired at all (best effort).

5.4.6.3 Mechanism for bearer establishment p. 92

In order to fulfil the above requirements, it is needed that the destination user can be pre-alerted before the bearer establishment and negotiation and IP-Connectivity Access Network bearer activation has taken place. This gives room for the destination user to choose the media streams and codecs required before an expensive resource (as the air interface is) is established.

Figure 5.7 shows the mechanism for the bearer establishment in which the pre-alerting occurs before the initial bearer creation procedures are performed. Furthermore, a user interaction may also occur after the initial bearers are created as shown in Figure 5.7. If the session originator receives multiple provisional responses for the same session indicating that the session has been forked in the network, the UE may choose to process a pre-configured number of responses. In the case of multiple responses, the resources requested by the UE shall be the "logical OR" (i.e. least upper bound) of the resources indicated in the multiple responses to avoid allocation of unnecessary resources. The UE shall never request more resources then was originally proposed in the Original INVITE.

The "Other x-CSCFs" entity in Figure 5.7 comprises several CSCFs: I-CSCF and S-CSCFs. For the sake of simplicity only the IP-Connectivity Access Network is shown, and the Policy Decision Functions have been omitted from the diagram.

Reproduction of 3GPP TS 23.228, Fig. 5.7: Bearer establishment showing optional pre-alerting

Figure 5.7: Bearer establishment showing optional pre-alerting

Step 1.

UE(A) starts a Session Initiation procedure to UE(B) that includes an SDP proposal.

The steps 2-4 are optional and may depend on terminal implementation and/or terminal pre-configured settings.

Step 2.

The user at UE(B) is pre-alerted.

Step 3.

An indication of the pre-alerting may be sent towards UE(A).

Step 4.

User at UE(B) will then interact and express his/her wishes regarding the actual session.

Step 5.

UE(B) generates accepted SDP based on terminal settings, terminal pre-configured profiles and optionally the user's wishes.

Step 6.

The accepted SDP is forwarded to UE(A) in the payload of a reliable SIP response.

Step 7.

Initial bearer creation procedure is performed. During this bearer creation step the resources in the UE(A)'s and UE(B)'s IP-CANs are reserved. Bearer resources in external networks may also be reserved at this point.

The steps 8-10 are also optional and may be skipped.

Step 8.

Terminal at UE(B) starts ringing.

Step 9.

The alerting indication is sent towards UE(A).

Step 10.

User at UE(B) may interact and express his/her wishes regarding the actual session.

Step 11.

UE(A) and UE(B) may perform bearer modification procedure at this point, if the initial bearers reserved in step 7 and the wishes of user at UE(B) are different. During this bearer modification step the resources in the IP-CANs of UE(A) and UE(B) may be modified, and the resource reservation in the external network may also be modified.

Step 12.

Session initiation procedure is acknowledged.

5.4.6.4 Session progress indication to the originating UE p. 94

The pre-alerting or alerting indications returned to the originating UE shall enable the originating UE to inform the calling user of the session progress prior to the arrival of the incoming media (for example the originating UE may synthesise ringing locally).