Content for &nbsp; TS 23.228 &nbsp; Word version:&nbsp; 19.0.0

UE (A) initiates an IMS session towards User B, via the session path for IMS and the session is analysed at the S-CSCF of UE (A).

S-CSCF for user A determines via DNS (or other mechanism) that the User B's domain cannot be communicated via IPv6 but can be via IPv4.

Step 2a.

S-CSCF forwards the request to IMS-ALG.

The IMS-ALG then acquires the necessary resources from the TrGW such as the IPv4 address and ports on behalf of user A so that User A can communicate with user B transparently.

The IMS-ALG continues IMS signalling towards User B network where User A's IPv6 address/port information is replaced by IPv4 information.

When User (B) responds to the session initiation requests, the IMS-ALG will replace the IPv4 address/port information of User (B) with its own IPv6 information for signalling and with TrGW IPv6 information for the media path as the contact information of User (B) and forward the request to S-CSCF of UE (A). Session signalling path is then established between the UE and the S-CSCF, the S-CSCF and the IMS-ALG, the IMS-ALG and the external network for User B.

Figure I.3: Terminating IPv4 SIP session towards an IPv6 IMS user

The media path is established between the UE (A) and the TrGW, via the IP-CAN, and then between the TrGW and user B.

At session release, the IP address/Port information will be released for reuse by other sessions.

I.3.1.2 Terminating Session Flows from IPv4 SIP network p. 250

The following session flow shows an example of a terminating session from an IPv4 SIP client towards an IPv6 IMS client. In order for the IPv6 IMS client to be reachable by the IPv4 network, it is assumed that the IPv4 network discovers (via mechanism such as DNS query) the IMS-ALG as the entry point to the IPv6 IMS network.

Reproduction of 3GPP TS 23.228, Fig. I.3: Terminating IPv4 SIP session towards an IPv6 IMS user

In the IMS-ALG, a terminating session is received. IMS-ALG determines either via DNS query or via pre-configuration the appropriate I-CSCF for the user (B) in the IMS network.

IMS-ALG also communicates with TrGW to get the mapping of IPv6 address and ports on behalf of user (A) and replaces the User (A) information in the incoming SIP message and forwards the message towards S-CSCF. From S-CSCF point of view, it continues setting up the IMS session like any other IMS sessions.

The incoming session arrives in the S-CSCF for the user (B).

Session set up continues as usual in the IMS domain towards user (B).

When UE (B) responds to the session initiation requests, the IMS-ALG will replace the IPv6 address/port information of User (B) with its own IPv4 information for signalling and with TrGW IPv4 information for the media path as contact information of UE (B) and forward the request towards the network of User (A). Session signalling path is established between User (B) and S-CSCF, S-CSCF and I-CSCF/IMS-ALG and IMS-ALG and the external User (A)'s network.

Figure I.4: Proactive transcoding invocation

Media path is established between UE (B) and the TrGW, via the IP-CAN, and then between the TrGW and User (A).

At session release, the IP address/Port information will be released for reuse by other sessions.

I.3.2 Configuration independence between operator networks p. 251

The THIG functionality may be used to hide the network topology from other operators. It shall be possible to restrict the following information from being passed outside of an operator's network: addresses of operator network entities.

The specific mechanism chosen needs to take into account the following separate aspects:

Network management:

In the case that network details (i.e. S-CSCF addresses) are visible by other external network elements, any (temporary or permanent) changes to the network topology need to be propagated to network elements outside of the operator's network. This is highly undesirable from a network management perspective.

Network scalability:

Establishing security associations on a pair-wise basis among all CSCFs is likely to be unscalable. The security associations shall be independent of the number of network elements.

Competitively aspects:

The operational details of an operator's network are sensitive business information that operators are reluctant to share with their competitors. While there may be situations (partnerships or other business relations) where the sharing of such information is appropriate, the possibility should exist for an operator to determine whether or not the internals of its network need to be hidden.

Security aspects:

Network element hiding may help to reduce the vulnerability of the overall system to external attacks (e.g. denial of service attacks). Further work is needed in this area.

I.3.3 Transcoding Support for Interworking |R8| p. 251

I.3.3.1 General p. 251

The IBCF/TrGw provides the necessary function for codec transcoding, when required by interworking agreement and session information, in order to establish communication between end points belonging to different IMS domains. These transcoding procedures are applicable to both the originating and the terminating side of the session or (in inter-network scenarios) in a transit network

Transcoding shall only be performed in the case where a common codec cannot be negotiated between the two UEs.

Media transcoding services can be triggered proactively (before the session request is sent to the called UE) or reactively (after the session request has been sent to, and rejected by, the called UE).

The IBCF may allocate a TrGW before sending the SDP Offer to the terminating UE or it may allocate the TrGW upon receiving the SDP answer. The protocol solutions should ensure that the called party is not alerted until resources for transcoding are seized and user plane connection towards the calling party is established to avoid ghost ringing or voice clipping.

If the IBCF is configured per local policy to use proactive transcoding, the IBCF shall add codecs to the offer. When inserting additional codec(s), the network should be able to indicate the preferred codec order.

If the IBCF is configured per local policy to use reactive transcoding, the IBCF shall first determine the codecs supported by the calling and called UEs so that insertion of the TrGW is performed when necessary, if not required for any other interconnect function. This means that the IBCF shall trigger a new offer/answer to the terminating UE, based on the initial offer from the originating UE but including additional codecs supported by the TrGW in the same manner as for the proactive support.

I.3.3.2 Session Flows p. 252

I.3.3.2.1 Proactive transcoding support |R9| p. 252

The following example session flow shows a proactive transcoding support scenario where an IBCF acting as an exit point allocates a TrGW prior to signalling towards the entry point of the other operator's network. The IBCF inserts additional codecs in the SIP signalling. The calling UE capabilities are contained in the SDP offer. Based on the interworking agreement between IM CN subsystems, terminating IBCFs acting as the network entry points may also insert additional codecs in the SIP signalling.

The IBCF and TrGW in Figure I.4 below may be located in the originating network (the IBCF acts as an exit point), or in the terminating network (the IBCF acts as an entry point). There can also be additional IBCF's and TrGW's (not shown) in the case of scenarios involving transit networks.

Reproduction of 3GPP TS 23.228, Fig. I.4: Proactive transcoding invocation

UE (A) initiates an IMS session towards User B, via the session path for IMS and the session is analysed at the IMS network of UE (A).

The IMS network of UE (A) determines that the User B's domain need be communicated via IBCF and forwards the request to the IBCF.

The IBCF checks the SIP message and decides whether additional codec(s) need be inserted into SIP message based on the session information (such as ICSI , SDP) and interworking agreement. When inserting additional codec(s), the network should be able to indicate the preferred codec order. A TrGW is allocated.

The IBCF generates a new SIP message towards User B network based on the received SIP message where additional codec(s) have been added and where the transport address and port information has been altered to indicate the addresses associated by the TrGW.

User (B) selects a codec from the offer modified by IBCF, and responds with an SDP answer.

Figure I.5: Reactive transcoding invocation

When receiving the SDP answer, if the IBCF invoked the TrGW in step 3, it now configures the TrGW with address and port towards UE (B). The IBCF checks if the agreed codec belongs to the original offer it received in step 3 or it is one of the codecs that was added by IBCF. If the agreed codec was added by the IBCF, the IBCF configures the TrGW to enable the transcoding functionality. Otherwise, the IBCF will not invoke the transcoding function.

Step 7.

The IBCF generates a new response message back to UE (A) based on the received response message where the codec received from peer side has been replaced with the selected codec.

Step 8.

Session signalling path is established between User (A) and IBCF, IBCF and User (B).

Step 9.

The media path is established between the UE (A) and the TrGW, and then between the TrGW and user B.

At session release, the codec transcoding resource will be released.

I.3.3.2.2 Reactive transcoding support |R9| p. 254

The following example session flow shows a reactive transcoding scenario where IBCF located at the network exit point first determines if a session can be established without addition of transcoding options and, will insert additional codecs in the SIP signalling only after failure to establish a session due to lack of a common codec. Based on the interworking agreement between IM CN subsystems the terminating IBCF may also perform this function.

Reproduction of 3GPP TS 23.228, Fig. I.5: Reactive transcoding invocation

UE (A) initiates an IMS session towards User B, and the session is analysed at the IBCF. The SDP offer is forwarded toward User B without the proactive addition of transcoding options.

A subsequent entity in the signalling path determines that it does not support any codec in the SDP offer and answers with an appropriate error response. This response may include a list of supported codecs.

Based on the response, the IBCF detects the need for reactive transcoding invocation.

The IBCF instructs the TrGW to allocate media processing resources for the session, allocate appropriate transcoding resources for the session and bridge the media flows between the calling and called party endpoints.

Based on the response from the TrGW, the IBCF creates a new SDP offer that contains the codec and transport address information received from the TrGW. If no information about supported codecs was available from the error response, the IBCF may offer all codecs supported by the transcoding device. The IBCF sends this SDP offer towards UE (B).