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