A.5.1 Signalling flows for termination to a CS UE registered in IMS using an MSC Server enhanced for ICS – multiple codecs used

24.2923GPPIP Multimedia (IM) Core Network (CN) subsystem Centralized Services (ICS)Release 17Stage 3TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

Figure A.5.1-1 shows the termination of a call to a CS UE via the MSC Server enhanced for ICS. Codec negotiation is performed.

Figure A.5.1-1: CS UE Termination with CS media using an MSC Server enhanced for ICS (with codec negotiation)

The details of the signalling flows are as follows:

1. SIP INVITE request (from the originating IM CN subsystem to intermediate IM CN subsystem entities) – see example in table A.5.1-1

The SIP INVITE request is sent by the originating IM CN subsystem to the intermediate IM CN subsystem entities.

Table A.5.1-1: SIP INVITE request (originating IM CN subsystem to intermediate IM CN subsystem entities)

INVITE sip:user2_public1@home1.net SIP/2.0

Via: SIP/2.0/UDP icscf2_s.home2.net;branch=z9hG4bK871y12.1, SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.home1.net;branch=z9hG4bK431h23.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Max-Forwards: 67

Route: <sip:scscf1.home1.net;lr>

Record-Route: <sip:scscf1.home2.net;lr>, <sip:pcscf1.home2.net;lr>

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11

P-Asserted-Identity: "John Doe" <sip:user1_public1@home1.net>, <tel:+1-212-555-1111>

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"; orig-ioi=home1.net

P-Asserted-Service: urn:urn-7:3gpp-service.ims.icsi.mmtel

Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3gpp-service.ims.icsi.mmtel"

Privacy: none

From: <sip:user1_public1@home2.net>;tag=171828

To: <tel:+1-212-555-2222>

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 127 INVITE

Supported: 100rel, precondition, gruu, 199

Accept: applicatiom/sdp,application/3gpp-ims+xml

Contact: <sip:user1_public1@home1.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>;+g.3gpp.icsi-ref="urn%3Aurn-7%3gpp-service.ims.icsi.mmtel">

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE

Content-Type: application/sdp

Content-Length: (…)

v=0

o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ddd

s=-

c=IN IP6 5555::aaa:bbb:ccc:ddd

t=0 0

m=video 3400 RTP/AVP 98 99

b=AS:75

a=curr:qos local none

a=curr:qos remote none

a=des:qos mandatory local sendrecv

a=des:qos none remote sendrecv

a=inactive

a=rtpmap:98 H263

a=fmtp:98 profile-level-id=0

a=rtpmap:99 MP4V-ES

m=audio 3456 RTP/AVP 97 0 96

b=AS:25.4

a=curr:qos local none

a=curr:qos remote none

a=des:qos mandatory local sendrecv

a=des:qos none remote sendrecv

a=rtpmap:97 AMR

a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2

a=rtpmap:96 telephone-event

a=maxptime:20

Request-URI: the SIP URI or tel URI of the called party. In this example the SIP URI of the called party is included, which might have been translated from a tel URI by the S-CSCF in the originating IM CN subsystem.

P-Asserted-Service and Contact: the ICSI defined for MMtel is included as this flow assumes a 3GPP R8 IMS UE originator. This for example purposes only, the ICSI might not be included for other originator types.

2. SIP 100 (Trying) response (from intermediate IM CN subsystem entities to the originating IM CN subsystem)

The intermediate IM CN subsystem entities respond to the originating IM CN subsystem with a SIP 100 (Trying) response. There is no ICS specific content in this response.

3. Evaluation of initial filter criteria

The S-CSCF evaluates initial filter criteria for the CS user and as a result routes the SIP INVITE request towards the SCC AS.

4. SIP INVITE request (from intermediate IM CN subsystem entities to SCC AS) – see example in table A.5.1-4.

The intermediate IM CN subsystem entities route the SIP INVITE request to the SCC AS.

Table A.5.1-4: SIP INVITE request (intermediate IM CN subsystem entities to SCC AS)

INVITE sip:user2_public1@home1.net SIP/2.0

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b33.1, icscf1_s.home1.net;branch=z9hG4bK871y12.1, SIP/2.0/UDP scscf1.home2.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.home2.net;branch=z9hG4bK431h23.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Max-Forwards: 66

Route: <sip:sccas.home1.net;lr>, <sip:cb03a0s09a2sdfglkj490333@scscf1.home1.net;lr>;orig-dialog-id="O:73935718_92645110-712786jd246395302d-zKE"

Record-Route: <sip:scscf1.home1.net;lr>, <sip:scscf1.home2.net;lr>, <sip:pcscf1.home2.net;lr>

P-Access-Network-Info:

P-Asserted-Identity:

P-Charging-Vector:

P-Asserted-Service:

Accept-Contact:

Privacy:

From:

To:

Call-ID:

Cseq:

Supported:

Accept:

Contact:

Allow:

Content-Type:

Content-Length: (…)

v=0

5. SIP 100 (Trying) response (from SCC AS to intermediate IM CN subsystem entities)

The SCC AS responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response. There is no ICS specific content in this response.

6. SIP INVITE request (from SCC AS to intermediate IM CN subsystem entities) – see example in table A.5.1-6

The SCC AS acting as a routing B2BUA generates a SIP INVITE request based upon the received SIP INVITE request and sends it to the intermediate IM CN subsystem entities.

Table A.5.1-6: SIP INVITE request (SCC AS to intermediate IM CN subsystem entities)

INVITE sip:user2_public1@home1.net SIP/2.0

Via: SIP/2.0/UDP sccas.home1.net;branch=z9hG4bKnas34r5

Max-Forwards: 65

Route: <sip:cb03a0s09a2sdfglkj490333@scscf1.home1.net;lr>;orig-dialog-id="O:73935718_92645110-712786jd246395302d-zKE"Record-Route:<sip:sccas.home1.net;lr>

P-Access-Network-Info:

P-Asserted-Identity:

P-Charging-Function-Addresses: ccf=[5555::b99:c88:d77:e66]; ccf=[5555::a55:b44:c33:d22]; ecf=[5555::1ff:2ee:3dd:4ee]; ecf=[5555::6aa:7bb:8cc:9dd]

P-Charging-Vector:

P-Asserted-Service:

Accept-Contact:*;+g.3gpp.ics="server"

Privacy:

From:<sip:user1_public1@home2.net>;tag=274890

To:

Call-ID:

Cseq:

Supported:

Accept:

Contact:

Allow:

Content-Type:

Content-Length: (…)

Via: the SCC AS, acting as a B2BUA, replaces the Via header field with one containing only its own SIP URI.

Contact: In this example the SCC AS includes the contents of the Contact header from the received SIP INVITE request No more triggering is required in the initial filter criteria, the IM CN subsystem will route the SIP INVITE request to the terminating user.

7. SIP 100 (Trying) response (from intermediate IM CN subsystem entities to SCC AS)

The intermediate IM CN subsystem entities respond to the SCC AS with a SIP 100 (Trying) response. There is no ICS specific content in this response.

8. SIP INVITE request (from intermediate IM CN subsystem entities to MSC Server enhanced for ICS) – see example in table A.5.1-8

The intermediate IM CN subsystem entities route the SIP INVITE request to the MSC Server enhanced for ICS.

Table A.5.1-8: SIP INVITE request (intermediate IM CN subsystem entities to MSC Server enhanced for ICS)

INVITE sip:+358504821437@msc2.home1.net SIP/2.0

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK433b44.1, SIP/2.0/UDP sccas.home1.net;branch=z9hG4bKnas34r5

Max-Forwards: 64

Route: <sip:msc2.home1.net;lr>

Record-Route: <sip:scscf1.home1.net;lr>,<sip:sccas.home1.net;lr>

P-Asserted-Identity:

P-Charging-Function-Addresses:

P-Charging-Vector:

P-Asserted-Service:

P-Called-Party-ID: <sip:user2_public1@home1.net>

Accept-Contact:

Privacy:

From:

To:

Call-ID:

Cseq:

Supported:

Accept:

Contact:

Allow:

Content-Type:

Content-Length: (…)

v=0

Request-URI: the S-CSCF replaces the Request-URI with the registered contact address by the MSC Server enhanced for ICS during registration.

9. SIP 100 (Trying) response (from MSC Server enhanced for ICS to intermediate IM CN subsystem entities)

The MSC Server enhanced for ICS responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response. There is no ICS specific content in this response.

10. SETUP message (from MSC Server enhanced for ICS to CS UE)

The MSC Server enhanced for ICS identities the subscriber using the Request-URI and initiates the paging procedure towards the terminating CS UE. After the CS UE has successfully accessed the network, the MSC Server enhanced for ICS sends a SETUP message towards the CS UE according to 3GPP TS 24.008 [7], providing the interworking as described in 3GPP TS 29.292 [24].

Specifically for this signalling flow, the SETUP message includes:

– Calling Party BCD Number information element = [(Numbering plan identifier = ISDN/telephony numbering plan), (type of number = international number ), (Presentation indicator=presentation allowed), (Screening indicator=network provided), (Number digits = 1212551111)]

– Bearer Capability 1 information element = [(information transfer capability = speech)]

11. CALL CONFIRMED message (from CS UE to MSC Server enhanced for ICS)

The CS UE sends a CALL CONFIRMED message towards the MSC Server enhanced for ICS according to 3GPP TS 24.008 [7]. Specifically for this signalling flow, the CALL CONFIRMED message includes:

– Supported Codec List information element = {[(SysID 1 = UMTS), (Codec Bitmap for SysID 1 = UMTS AMR2)], [(SysID 2 = GSM), (Codec Bitmap for SysID 2 = FR AMR, GSM EFR, GSM FR)]}

In this example, no Bearer Capability 1 information element is returned.

As the node terminating the out of band transcoder control procedures as specified in 3GPP TS 23.153 [4A], the MSC Server enhanced for ICS selects a single selected codec.

12. Reserve / Configure RTP (from MSC Server enhanced for ICS to CS-MGW)

The MSC Server enhanced for ICS performs CS-MGW selection and requests the CS-MGW to prepare for network side bearer establishment. The MSC Server enhanced for ICS removes the video media description from the SDP offer and then requests reservation and configuration of a local RTP endpoint. The MSC Server enhanced for ICS also sends the selected speech codec and the remote user plane RTP information received from the SDP offer to the CS-MGW. The MSC Server enhanced for ICS receives the local RTP endpoint information from the CS-MGW.

13. SIP 183 (Session Progress) response (from MSC Server enhanced for ICS to intermediate IM CN subsystem entities) – see example in table A.5.1-13

The MSC Server enhanced for ICS returns an SDP answer. The video media description has been removed and only the audio media description is included.

Table A.5.1-13: SIP 183 (Session Progress) response (MSC Server enhanced for ICS to intermediate IM CN subsystem entities)

SIP/2.0 183 Session Progress

Via: SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK433b44.1, SIP/2.0/UDP sccas.home1.net;branch=z9hG4bKnas34r5

Record-Route: <sip:scscf1.home1.net;lr>, <sip:sccas.home1.net;lr>

P-Asserted-Identity: <sip:user2_public1@home1.net>

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"

From:

To: <tel:+1-212-555-2222>;tag=314159

Call-ID:

Cseq:

Require: 100rel

Contact:<sip:user2_public1@home1.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>;+g.3gpp.icsi-ref="urn%3Aurn-7%3gpp-service.ims.icsi.mmtel";+g.3gpp.ics="server"

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER

Rseq: 9021

Content-Type: application/sdp

Content-Length: (…)

v=0

o=- 2987933623 2987933623 IN IP6 5555::eee:fff:aaa:bbb

s=-

c=IN IP6 5555::eee:fff:aaa:bbb

t=0 0

m=video 0 RTP/AVP 98 99

m=audio 6544 RTP/AVP 97 96

b=AS:25.4

a=curr:qos local none

a=curr:qos remote none

a=des:qos mandatory local sendrecv

a=des: qos mandatory remote sendrecv

a=conf:qos remote sendrecv

a=rtpmap:97 AMR

a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2

a=rtpmap:96 telephone-event

a=maxptime:20

P-Asserted-Identity: the value taken from the P-Called-Party-ID header field in the INVITE request.

The SDP answer in the 183 (Session Progress) response contains a single selected codec and a request for confirmation of when remote preconditions are met.

14-16. SIP 183 (Session Progress) response (from intermediate IM CN subsystem entities to SCC AS)

The SIP 183 (Session Progress) response is routed to the originating IM CN subsystem via the SCC AS and intermediate IM CN subsystem entities. In this example the SCC AS includes the contents of the Contact header from the received SIP 183 (Session Progress) response except the g.3gpp.ics media feature tag which is removed by the SCC AS. When sending the SIP 183 (Session Progress) response to the initial INVITE request (i.e. received in step 4 above), the SCC AS includes its SIP URI in the Record-Route header field and forwards the SIP 183 (Session Progress) response to the originating IM CN subsystem.

17-20. SIP PRACK request and SIP 200 (OK) response

The SIP PRACK request and its SIP 200 (OK) response are routed end-to-end between the originating IM CN subsystem, intermediate IM CN subsystem entities, SCC AS and MSC Server enhanced for ICS. There is no specific ICS content in these messages. In this example the SCC AS includes the contents of the Contact header from the received SIP PRACK request.

21-24. SIP UPDATE request and SIP 200 (OK) response

When the originating endpoint has completed its resource reservation, the intermediate IM CN subsystem entities receive an UPDATE request. The UPDATE request and its SIP 200 (OK) response are routed end-to-end between the originating IM CN subsystem, intermediate IM CN subsystem entities, SCC AS and MSC Server enhanced for ICS. There is no specific ICS content in these messages. In this example the SCC AS includes the contents of the Contact header from the received SIP UPDATE request.

25. Assignment

The MSC Server enhanced for ICS performs access bearer assignment.

For UTRAN access this involves invocation of the Prepare Bearer and Change Through Connection procedures with the CS-MGW, followed by sending a RAB ASSIGNMENT REQUEST message to the UTRAN. The NAS Synchronization Indicator information element is included to identify the selected codec and codec configuration.

For GERAN access this involves invocation of the Reserve Circuit and Change Through Connection procedures with the CS-MGW, followed by sending a ASSIGNMENT REQUEST to the GERAN.

26. ALERTING message (from CS UE to MSC Server enhanced for ICS)

The CS UE sends an ALERTING message to the MSC Server enhanced for ICS according to 3GPP TS 24.008 [7].

27. Start tone (from MSC Server enhanced for ICS to CS-MGW)

The MSC Server enhanced for ICS instructs the CS-MGW to start ringback tone.

28. SIP 180 (Ringing) response (from MSC Server enhanced for ICS to intermediate IM CN subsystem entities) – see example in table A.5.1-28

The MSC Server enhanced for ICS does not include "100rel" in the Require header field as the 180 (Ringing) response does not contain SDP and therefore need not be sent reliably.

Table A.5.1-28: SIP 180 (Ringing) response (MSC Server enhanced for ICS to intermediate IM CN subsystem entities)

SIP/2.0 180 Ringing

Via: SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK433b44.1, SIP/2.0/UDP sccas2.home2.net;branch=z9hG4bKnas34r5

From:

To: <sip:user1_public1@home1.net>;tag=314159

Call-ID:

Cseq:

Rseq: 9022

Content-Length: 0

29-31. SIP 180 (Ringing) response (from intermediate IM CN subsystem entities to SCC AS)

The SIP 180 (Ringing) response is routed to the originating IM CN subsystem via the SCC AS and intermediate IM CN subsystem entities.

32. CONNECT message (from CS UE to MSC Server enhanced for ICS)

The CS UE sends a CONNECT message to the MSC Server enhanced for ICS according to 3GPP TS 24.008 [7].

33. Stop tone and through connect (from MSC Server enhanced for ICS to CS-MGW)

The MSC Server enhanced for ICS instructs the CS-MGW to stop ringback tone and to through connect the bearer.

34. SIP 200 (OK) response (from MSC Server enhanced for ICS to intermediate IM CN subsystem entities) – see example in table A.5.1-34

Table A.5.1-34: SIP 200 (OK) response (MSC Server enhanced for ICS to intermediate IM CN subsystem entities)

SIP/2.0 200 OK

Via: SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK433b44.1, SIP/2.0/UDP sccas2.home2.net;branch=z9hG4bKnas34r5

From:

To: <sip:user1_public1@home1.net>;tag=314159

Call-ID:

Cseq:

Contact: <

sip:user2_public1@home1.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>;+g.3gpp.icsi-ref="urn%3Aurn-7%3gpp-service.ims.icsi.mmtel";+g.3gpp.ics="server"

Content-Length: 0

Contact: the MSC Server enhanced for ICS includes the GRUU received at registration, the media feature tag g.3gpp.icsi-ref set to "urn%3Aurn-7%3gpp-service.ims.icsi.mmtel" and the media feature tag g.3gpp.ics set to "server".

35-37. SIP 200 (OK) response

The 200 (OK) response is routed to the originating IM CN subsystem via the SCC AS and intermediate IM CN subsystem entities. In this example the SCC AS includes the contents of the Contact header from the received SIP 200 (OK) response except the g.3gpp.ics media feature tag which is removed by the SCC AS.

38. CONNECT ACK request (from MSC Server enhanced for ICS to CS UE)

After through-connecting the traffic channel, the MSC Server enhanced for ICS sends a CONNECT ACKNOWLEDGEMENT message to the CS UE according to 3GPP TS 24.008 [7].

39-42. SIP ACK request

A SIP ACK request is routed end-to-end from the originating IM CN subsystem to the MSC Server enhanced for ICS. There is no ICS specific content in this message.