A.4 Signalling flows for call origination

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

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

A.4.1 Signalling flows for ICS UE origination with CS media using Gm reference point when using an MSC Server enhanced for ICS

Figure A.4.1-1 shows the origination of a call from an ICS UE using CS bearers controlled through the IM CN subsystem. In this example the MSC Server is enhanced for ICS and is capable of translating NAS signalling received from the ICS UE to SIP and vice versa. If the MSC is not enhanced for ICS, translation of NAS signalling to ISUP is required before routing towards a MGCF for interworking with the IM CN subsystem, as shown in subclause A.4.2.

Figure A.4.1-1: ICS UE Origination with CS media using Gm reference point when using an MSC Server enhanced for ICS

The details of the signalling flows are as follows:

1. Determination of call establishment

As a result of some stimulus to establish a session with voice media, the ICS UE based on a combination of user policy, and access technology availability, decides to establish the service control signalling using the IM CN subsystem.

The ICS UE initiates service control signalling in the IM CN subsystem towards the SCC AS by sending a SIP INVITE request to the intermediate IM CN subsystem entities.

2. SIP INVITE request (ICS UE to intermediate IM CN subsystem entities) – see example in table A.4.1-2.

Table A.4.1-2: SIP INVITE request (ICS UE to intermediate IM CN subsystem entities)

INVITE tel:+1-212-555-2222 SIP/2.0

Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Max-Forwards: 70

Route: <sip:pcscf1.home1.net:7531;lr;comp=sigcomp>, <sip:orig@scscf1.home1.net;lr>

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

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

Privacy: none

From: <sip:user2_public1@home1.net>;tag=171828

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

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 127 INVITE

Supported: 100rel, precondition, 199, gruu

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

Require: sec-agree

Proxy-Require: sec-agree

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

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

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi=87654321; port=7531

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="principal"

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

c=PSTN – –

t=0 0

m=audio 9 PSTN –

a=setup:active

a=connection:new

a=cs-correlation:callerid:+358504821437

a=curr: qos local none

a=curr: qos remote none

a=des: qos mandatory local sendrcv

a=des: qos mandatory remote sendrcv

a=inactive

Request-URI: the SIP URI or tel URI of the called party. In this example the tel URI of the called party is included in the tel URI.

The SDP included in this SIP INVITE request indicates that the session is to be setup using CS bearers as described in IETF RFC 7195 [36].

3. SIP 100 (Trying) response (intermediate IM CN subsystem entities to ICS UE)

The intermediate IM CN subsystem entities respond to the ICS UE with a SIP 100 (Trying) response

There is no ICS specific content in this response.

4. Evaluation of initial filter criteria

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

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

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

INVITE tel:+1-212-555-2222 SIP/2.0

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

Max-Forwards: 68

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:pcscf1.home1.net;lr>

P-Asserted-Identity: <sip:user2_public1@home1.net>,<tel:+358-50-4821437>

P-Access-Network-Info:

Privacy:

From:

To:

Call-ID:

Cseq:

Supported:

Accept:

Require:

Proxy-Require:

Accept-Contact:

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

Security-Verify:

Contact:

Allow:

Content-Type:

Content-Length: (…)

v=0

6. SIP 100 (Trying) response (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.

7. SCC AS allocates an SCC AS PSI DN to the ICS UE

The SCC AS stores the information received in the initial INVITE request and associates an SCC AS PSI DN with this request. The SCC AS PSI DN is returned in a SIP to the ICS UE together with an inidcation that CS bearer establishment is to be initiated by the ICS UE. For this example the SCC AS PSI DN is chosen as +1212556666.

8. SIP 183 (Session Progress) response (SCC AS to intermediate IM CN subsystem entities) – see example in table A.4.1-8

Table A.4.1-8: SIP 183 (Session Progress) response (SCC AS to intermediate IM CN subsystem entities)

SIP/2.0 183 Session Progress

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

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

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

Privacy: none

From: <tel:+1-212-555-1111>;tag=171828

To: <sip:user2_public1@home1.net>

Call-ID:

CSeq:

Require: 100rel, precondition

Contact:<sip:sccas.home1.net>

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

Content-Type: application/sdp

Content-Length: (…)

v=0

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

s=-

c=PSTN E164 +12125556666

t=0 0

m=audio – PSTN –

a=setup:passive

a=connection:new

a=cs-correlation:callerid

a=curr: qos local none

a=curr: qos remote none

a=des: qos mandatory sendrcv

a=inactive

The SCC AS PSI DN is returned in the SDP body using the mechanisms described in IETF RFC 7195 [36].

9. SIP 183 (Session Progress) response (intermediate IM CN subsystem entities to ICS UE)

The SIP 183 (Session Progress) response is routed towards the ICS UE from the intermediate IM CN subsystem entities.

10. SIP PRACK request and SIP 200 (OK) response

The ICS UE sends a SIP PRACK request towards the SCC AS via the intermediate IM CN subsystem entities as a result of receiving the reliably sent SIP 183 (Session Progress) response containing the SDP answer.

Upon receipt of the SIP PRACK request, the SCC AS responds with a SIP 200 (OK) response towards the ICS UE via the intermediate IM CN subsystem entities.

The is no ICS specific content in these SIP messages.

NOTE: In the event that the SCC AS does not receive a PRACK request, the SCC AS is capable of handling a new SIP INVITE request sent from the ICS UE as per normal SIP procedures. In this case a new SCC AS PSI DN would be returned to the ICS UE in the SIP 183 (Session Progress) response.

11. ICS UE proceeds to setup CS bearers

Upon receipt of the SCC AS PSI DN, the ICS UE proceeds with setting up the call using CS bearers.

12. SETUP message (ICS UE to MSC Server enhanced for ICS)

The ICS UE initiates the call over CS bearers by sending a SETUP message to the MSC Server enhanced for ICS.

Specifically for this signalling flow, the SETUP message includes:

– Called Party Number information element = [(Numbering plan identifier = ISDN/telephony numbering plan), (type of number = international number ), (Number digits = 1212556666)] . The Called Party Number information element is set to the SCC AS PSI DN.

– Bearer Capability information element = [(information transfer capability = speech), (speech versions = FR AMR, GSM EFR, GSM FR)]

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

The MSC Server enhanced for ICS knows the calling party number corresponding to the UE.

13. CALL PROCEEDING message (MSC Server enhanced for ICS to ICS UE)

Upon receipt of the SETUP message from the ICS UE, the MSC Server enhanced for ICSresponds with a CALL PROCEEDING message. There is no ICS specific content in this message.

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

The MSC Server enhanced for ICS maps the received SETUP message to a SIP INVITE request which is addressed to the IUA PSI DN.

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

INVITE tel:+1-212-555-6666 SIP/2.0

Via: SIP/2.0/UDP msc1.hom1.net;branch=z9hG4bKnashds7

Max-Forwards: 70

Route: <sip:icscf1.home1.net:lr>

P-Asserted-Identity: <sip:user2_public1@home1.net>,<tel:+358-50-4821437>

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

P-Access-Network-Info:

Privacy: none

From: <sip:user2_public1@home1.net>;tag=171828

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

Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6

Cseq: 127 INVITE

Supported: 100rel, precondition, gruu, 199

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

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

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

Content-Type: application/sdp

Content-Length: (…)

v=0

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

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

t=0 0

m=audio 3456 RTP/AVP 97 96

b=AS:25.4

a=curr:qos local sendrecv

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: SCC AS PSI DN as received in the SETUP message

P-Asserted-Identity: The MSC Server enhanced for ICS inserts the tel-URI containing the subscriber number, as received from the ICS UE

Accept-Contact: The MSC Server enhanced for ICS includes the mmtel feature tag in the INVITE request .

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

SDP: The SDP contains preconfigured set of codecs supported by the MGW.

15. SIP 100 (Trying) response (intermediate IM CN subsystem entities to enahanced MSC Server)

The intermediate IM CN subsystem entities respond to the MSC Server enhanced for ICS with a SIP 100 (Trying) response.

There is no ICS specific content in this response.

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

The SIP INVITE request is routed towards the SCC AS.

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

INVITE tel:+1-212-555-6666 SIP/2.0

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP icscf1.home1.net;branch=z9hG4bKdwe534, SIP/2.0/UDP msc1.hom1.net;branch=z9hG4bKnashds7

Max-Forwards: 68

Route: <sip:sccas1.home1.net:lr>, <sip:scscf1.home1.net;lr>;orig-dialog-id="yuflsae80r3rb3fh31ondyr829cnyr381cn932YDWref0w0-wwtg374"

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

P-Asserted-Identity: <sip:user2_public1@home1.net>,<tel:+358-50-4821437>

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: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"; orig-ioi="type 3home1.net"

P-Access-Network-Info:

Privacy: none

From:

To:

Call-ID:

Cseq:

Supported:

Accept-Contact:

P-Asserted-Service:

Contact: Allow:

Content-Type:

Content-Length:

17. SIP 100 (Trying) response (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.

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

The SCC AS acting as a routing B2BUA, generates a SIP INVITE request based upon the received SIP INVITE request and the information previously stored against this session and routes it towards UE B via the intermediate IM CN subsystem entities.

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

INVITE tel:+1-212-555-2222 SIP/2.0

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

Max-Forwards: 67

Route: <sip:scscf1.home1.net:lr>;orig-dialog-id="yuflsae80r3rb3fh31ondyr829cnyr381cn932YDWref0w0-wwtg374"

Record-Route: <sip: sccas1.home1.net;lr>

P-Asserted-Identity: <sip:user2_public1@home1.net>,<tel:+358-50-4821437>

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: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"; orig-ioi="type3home1.net"

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

Privacy: none

From: <sip:user2_public1@home1.net>;tag=274890

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

Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6

Cseq: 127 INVITE

Supported: 100rel, precondition, gruu, 199

Require: sec-agree

Proxy-Require: sec-agree

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

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

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi=87654321; port=7531

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"

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:eee

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

t=0 0

m=audio 3456 RTP/AVP 97 96

b=AS:25.4

a=curr:qos local sendrecv

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 SCC AS replaces the SCC AS PSI DN with the tel URI of the called party which was stored from the initial SIP INVITE request sent in step 2.

Contact: In this example the SCC AS includes the contents of the Contact header from the received SIP INVITE request except the g.3gpp.ics media feature tag which is removed by the SCC AS.

Record-Route: The SCC AS includes a Record-Route header field that contains its SIP URI and specifies the address where the SCC AS will receive subsequent in-dialog SIP requests originating from the UE B.

19. SIP 100 (Trying) response (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.

20. SIP INVITE request (intermediate IM CN subsystem entities to UE B)

The intermediate IM CN subsystem entities route the SIP INVITE request to UE B.

21. SIP 100 (Trying) response (UE B to intermediate IM CN subsystem entities)

UE B responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response.

There is no ICS specific content in this response.

22-23. SIP 180 (Ringing) response (UE B to SCC AS via intermediate IM CN subsystem entities)

UE B responds to the received SIP INVITE request with a SIP 180 (Ringing) response. The response contains no SDP body and contains no ICS specific content.

24-25. SIP 180 (Ringing) response (SCC AS to ICS UE A via intermediate IM CN subsystem entities)

Upon receiving the SIP 180 (Ringing) response from the terminating UE, the SCC AS sends a SIP 180 (Ringing) response to the ICS UE A via the intermediate IM CN subsystem entities. The response is associated with the SIP INVITE in step 2 and contains no ICS specific content. In this example the SCC AS includes in the Contact header field the contents of the Contact header field received in the SIP 180 (Ringing) response from the terminating side. Furthermore, the SIP 180 (Ringing) contains no SDP body.

26. SIP 200 (OK) response (UE B to to intermediate IM CN subsystem entities) – see example in table A.4.1-26

The terminating side sends an SDP answer in a SIP 200 (OK) response to the received SIP INVITE request.

Table A.4.1-26: SIP 200 (OK) response (UE B to intermediate IM CN subsystem entities)

SIP/2.0 200 OK

Via: SIP/2.0/UDP pcscf2.visited2.net:5088;comp=sigcomp;branch=z9hG4bK361k21.1, scscf2.home1.net;branch=z9hG4bK764z87.1, icscf1.home1.net;branch=z9hG4bK871y12.1, SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP sccas1.home1.net;branch= z9hG4bKnas34r5

Record-Route: <sip:pcscf2.visited2.net:5088;lr;comp=sigcomp>, <sip:scscf2.visited2.net;lr>, <sip:scscf1.home1.net;lr>, <sip: sccas1.home1.net;lr>

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

Privacy: none

From: <tel:+1-212-555-1111>;tag=274890

To: <sip:user2_public1@home1.net>;tag=4fa328

Call-ID:

CSeq:

Require: 100rel, precondition

Contact: <sip:user2_public1@home2.net;gr=urn:uuid:2ad8950e-48a5-4a74-8d99-ad76cc7fc74>; +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=- 2987933623 2987933623 IN IP6 5555::ggg:fff:aaa:bbb

s=-

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

t=0 0

m=audio 3456 RTP/AVP 97 96

b=AS:25.4

a=curr:qos local sendrcv

a=curr:qos remote sendrcv

a=des:qos mandatory local sendrecv

a=des:qos mandatory remote sendrecv

a=rtpmap:97 AMR

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

a=maxptime:20

27. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS)

The SIP 200 (OK) response from UE is routed towards the SCC AS.

28-29. SIP 200 (OK) response (SCC AS to MSC Server enhanced for ICS via intermediate IM CN subsystem entities)

The SDP answer received in the SIP 200 (OK) response is routed to the MSC Server enhanced for ICS via the intermediate IM CN subsystem entities. In this example the SCC AS includes in the Contact header field the contents of the Contact header field received in the SIP 200 (OK) response from the terminating side.

30. CONNECT message (MSC Server enhanced for ICS to ICS UE)

The MSC Server enhanced for ICS maps the received SIP 200 (OK) response to a CONNECT message. There is no ICS specific content in this message.

31. CONNECT ACKNOWLEDGMENT (ICS UE A to MSC Server enhanced for ICS)

The ICS UE A sends a CONNECT ACKNOWLEDGMENT message upon receiving the CONNECT message.

32-33. SIP ACK request (MSC Server enhanced for ICS to SCC AS via intermediate IM CN subsystem entities)

Upon receiving the CONNECT ACKNOWLEDGEMENT from the ICS UE A, the MSC Server enhanced for ICS forwards a SIP ACK request to the SCC AS via the intermediate IM CN Subsystem entities.

There is no ICS specific content in this request.

34-35. SIP 200 (OK) response (SCC AS to ICS UE A via intermediate IM CN subsystem entities)

The SCC AS responds with a SIP 200 (OK) response to the initial INVITE request sent by the ICS UE A in the step 2. Since the SDP answer was previously sent in the SIP 183 (Session Progress) response, the SIP 200 (OK) response contains no SDP body. In this example the SCC AS includes in the Contact header field the contents of the Contact header field received in the SIP 200 (OK) response from the terminating side.

36-37. SIP ACK request (ICS UE A to SCC AS via intermediate IM CN subsystem entities)

The ICS UE A sends a SIP ACK request to the SCC AS via the intermediate IM CN subsystem entities. There is no ICS specific content in this response.

38-39. SIP ACK request (SCC AS to UE B via intermediate IM CN subsystem entities)

The SCC AS sends a SIP ACK request to UE B via the IM CN subsystem entities. There is no ICS specific content in this response.

A.4.2 Signalling flows for ICS UE origination with CS media using Gm reference point when using an MSC Server not enhanced for ICS

Figure A.4.2-1 shows the origination of a call from an ICS UE using CS bearers controlled through the IM CN subsystem. In this example the MSC Server is not enhanced for ICS thus translation at the MGCF of ISUP message to SIP messages is required.

Figure A.4.2-1: ICS UE Origination with CS media using Gm reference point when using an MSC Server not enhanced for ICS

The details of the signalling flows are as follows:

1-13: These steps are identical to steps 1-13 described in subclause A.4.1.

14. ISUP IAM (MSC Server not enhanced for ICS to MGCF)

The MSC Server not enhanced for ICS maps the received SETUP message to an ISUP IAM message that is routed towards the MGCF.

Specifically for this signalling flow, the IAM includes:

– Called Party Number parameter = [Numbering plan identifier = ISDN/telephony numbering plan], (type of number = international number), (Number digits = 12125556666)]. The Called Party Number is set to the SCC AS PSI DN, as received in the SETUP message.

– Calling Party Number parameter = [(Numbering plan identifier = ISDN/telephony numbering plan), (type of number = international number), (Number digits = 12125551111)]

15. SIP INVITE request (MGCF to intermediate IM CN subsystem entities) – see example in table A.4.2-15

The MGCF interworks the received IAM message to a SIP INVITE request which is addressed to the SCC AS PSI DN.

Table A.4.2-15: SIP INVITE request (MGCF to intermediate IM CN subsystem entities)

INVITE tel:+1-212-555-6666 SIP/2.0

Via: SIP/2.0/UDP mgcf1.hom1.net;branch=z9hG4bKnashds7

Max-Forwards: 70

Route: <sip:icscf1.home1.net:lr>

P-Asserted-Identity: <tel: +1-212-555-1111>

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

Privacy: none

From: <tel:+358-50-4821437>;tag=171828

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

Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6

Cseq: 127 INVITE

Supported: 100rel, precondition, gruu, 199

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

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

Contact: <sip:mgcf1.home1.net>;+g.3gpp.icsi-ref="urn%3Aurn-7%3gpp-service.ims.icsi.mmtel"

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

Content-Type: application/sdp

Content-Length: (…)

v=0

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

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

t=0 0

m=audio 3456 RTP/AVP 97 96

b=AS:25.4

a=curr:qos local sendrecv

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: SCC AS PSI DN as received in the SETUP message

P-Asserted-Identity: The MGCF inserts the tel-URI containing the subscriber number, as received from the ICS UE

SDP: The SDP contains preconfigured set of codecs supported by the MGW.

16. SIP 100 (Trying) response (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.

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

The SIP INVITE request is routed towards the SCC AS.

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

INVITE tel:+1-212-555-6666 SIP/2.0

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP icscf1.home1.net;branch=z9hG4bKdwe534, SIP/2.0/UDP mgcf1.hom1.net;branch=z9hG4bKnashds7

Max-Forwards: 68

Route: <sip:sccas1.home1.net:lr>, <sip:scscf1.home1.net;lr>;orig-dialog-id="yuflsae80r3rb3fh31ondyr829cnyr381cn932YDWref0w0-wwtg374"

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

P-Asserted-Identity: <tel: +1-212-555-1111>

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: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"; orig-ioi="type 3home1.net"

P-Access-Network-Info:

Privacy: none

From: <tel: +1-212-555-1111>;tag=171828

To:

Call-ID:

Cseq: 127 INVITE

Supported:

Require:

Proxy-Require:

Accept-Contact:

P-Asserted-Service:

Security-Verify:

Contact:

Allow:

Content-Type:

Content-Length:

v=0

18. SIP 100 (Trying) response (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.

19-28. These steps are identical to steps 18-27 described in subclause A.4.1.

29-30. SIP 200 (OK) response (SCC AS to MGCF via intermediate IM CN subsystem entities)

The SDP answer received in the SIP 200 (OK) response is routed to the MGCF via the intermediate IM CN subsystem entities.

31. ISUP ANM message (MGCF to MSC Server not enhanced for ICS)

On receipt of the SIP 200 (OK) response, the MGCF generates an ISUP ANM message and sends this to the MSC Server not enhanced for ICS.

There is no ICS specific content in this message.

32-33. These steps are identical to steps 30-31 described in subclause A.4.1.

34-35. SIP ACK request (MGCF to SCC AS via intermediate IM CN subsystem entities)

On receipt of the SIP 200 (OK) response, the MGCF sends a SIP ACK request to the SCC AS via the intermediate IM CN Subsystem entities.

There is no ICS specific content in this request.

36-41. These steps are identical to steps 34-39 described in subclause A.4.1.

A.4.3 Signalling flows for CS UE origination when using an MSC Server enhanced for ICS — multiple codecs used

Figure A.4.3-1 shows the origination of a call from a CS UE which uses NAS signalling towards the MSC Server enhanced for ICS. The CS UE is controlled by an MSC Server enhanced for ICS. In this example the CS UE supports more than one speech codec. The MSC Server enhanced for ICS is supporting codec negotiation. The MSC Server is enhanced for ICS and is capable of translating NAS signalling received from the CS UE to SIP and vice versa.

Figure A.4.3-1: CS UE Origination with CS media when using an MSC Server enhanced for ICS – multiple codecs used

The details of the signalling flows are as follows:

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

As a result of some stimulus to establish a session with voice media, the CS UE initiates service control signalling towards the MSC Server enhanced for ICS by sending a SETUP message.

Specifically for this signalling flow, the SETUP message includes:

– Called Party Number information element = [(Numbering plan identifier = ISDN/telephony numbering plan), (type of number = international number ), (Number digits =12125552222)]

– Bearer Capability information element = [(information transfer capability = speech), (speech versions = FR AMR, GSM EFR, GSM FR)]

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

The MSC Server enhanced for ICS knows the calling party number corresponding to the CS UE

2. Call proceeding message (MSC Server enhanced for ICS to CS UE)

The MSC Server enhanced for ICS acknowledges the receipt of the SETUP message by sending a call proceeding message to the CS UE.

3-4. Provide IP addresses and RTP information

The MSC Server enhanced for ICS provides the media gateway with the possible codecs. The MGW provides the MSC Server enhanced for ICS with media information eg IP information and RTP information.

5. SIP INVITE request (MSC Server enhanced for ICS to IM CN subsystem entities) – see example in table A.4.3-5.

Table A.4.3-5: SIP INVITE request (MSC Server enhanced for ICS to IMS CN subsystem entities)

INVITE tel:+1-212-555-2222 SIP/2.0

Via: SIP/2.0/UDP emsc1.home1.net;branch=z9hG4bK332b23.1

Max-Forwards: 68

Route: sip:orig@scscf1.home1.net;lr>

P-Asserted-Identity: <sip:user2_public1@home1.net>,<tel:+358-50-4821437>

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

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

Privacy: none

From: <sip:user2_public1@home1.net>;tag=171828

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

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 127 INVITE

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"

Supported: 100rel, precondition, gruu, 199

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

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

Content-Type: application/sdp

Content-Length: (…)

v=0

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

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

t=0 0

m=audio 49152 RTP/AVP 97 98 99 100

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/8000/1

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

a=rtpmap:98 GSM-EFR/8000/1

a=rtpmap:99 GSM/8000/1

a=ptime:20

a=rtpmap:100 telephone-event

a=maxptime:240

Request-URI: SCC AS PSI DN as received in the SETUP message

P-Asserted-Identity: The MSC Server enhanced for ICS enhanced for ICS inserts the tel-URI containing the subscriber number stored in the MSC.

Accept-Contact: The MSC Server enhanced for ICS includes the mmtel feature tag in the INVITE request .

P-Asserted -Service: The MSC Server enhanced for ICS includes the mmtel ICSI value in the INVITE request.

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

SDP: The MSC Server enhanced for ICS includes the codecs and IP addresses and port address as received from the MGW.

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

The intermediate IM CN subsystem entities respond to the MSC Server enhanced for ICS with a SIP 100 (Trying) response

There is no ICS specific content in this response.

7. Evaluation of initial filter criteria

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

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

Table A.4.3-8: SIP INVITE request (IM CN subsystem entities to SCC AS)

INVITE tel:+1-212-555-2222 SIP/2.0

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1,

SIP/2.0/UDP emsc1.home1.net;branch=z9hG4bK332b23.1

Max-Forwards: 67

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>,

P-Asserted-Identity:

P-Access-Network-Info:

P-Charging-Vector:

From:

To:

Call-ID:

Cseq:

P-Asserted-Service:

Accept-Contact:

Supported:

Contact:

Allow:

Content-Type:

Content-Length: (…)

v=0

9. SIP 100 (Trying) response (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.

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

Table A.4.3-10: SIP INVITE request (SCC AS to IMS CN subsystem entities)

INVITE tel:+1-212-555-2222 SIP/2.0

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

SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1,

SIP/2.0/UDP emsc1.home1.net;branch=z9hG4bK332b23.1

Max-Forwards: 66

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

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

P-Asserted-Identity:

P-Access-Network-Info:

P-Charging-Vector:

Privacy:

From: <sip:user2_public1@home1.net>;tag=274890

Call-ID:

Cseq:

Supported:

Accept:

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"

P-Asserted-Service:

Accept-Contact:

Allow:

Content-Type:

Content-Length: (…)

v=0

11. SIP 100 (Trying) response (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.

12. SIP INVITE request (intermediate IM CN subsystem entities to IMS UE)

The intermediate IM CN subsystem entities route the SIP INVITE request to IMS UE.

13. SIP 100 (Trying) response (IMS UE to intermediate IM CN subsystem entities)

IMS UE responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response.

There is no ICS specific content in this response.

14 SIP 183 (Session Progress) response (IMS UE to intermediate IM CN subsystem entities) – see example in table A.4.3-14

Table A.4.3-14: SIP 183 (Session Progress) response (IMS UE to intermediate IM CN subsystem entities)

SIP/2.0 183 Session Progress

Via: SIP/2.0/UDP pcscf2.home1.net;branch=z9hG4bK240f34.1,

SIP/2.0/UDP scscf2.home1.net;branch=z9hG4bK332b23.1,

SIP/2.0/UDP SIP/2.0/UDP sccas1.home1.net;branch=z9hG4bKnas34r5,

SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1,

SIP/2.0/UDP emsc1.home1.net;branch=z9hG4bK332b23.1

Record-Route: <sip:pcscf2.home1.net;lr>,<sip:scscf2.home1.net;lr>,

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

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

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

Privacy: none

From: < sip:user2_public1@home1.net >;tag=274890

To: <sip:tel:+1-212-555-2222>;tag=4fa328

Call-ID:

CSeq:

Require: 100rel, precondition

Contact: <sip:user2_public1@home2.net;gr=urn:uuid:2ad8950e-48a5-4a74-8d99-ad76cc7fc74>;+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

s=-

m=audio 49152 RTP/AVP 97 100

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/8000/1

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

a=rtpmap:100 telephone-event

a=maxptime:240

15-17. SIP 183 (Session Progress) response (From IMS UE to MSC Server enhanced for ICS via IM-CN subsystem)

The SIP 183 (Session Progress) response is routed towards the MSC Server enhanced for ICS via the intermediate IM CN subsystem entities.

18. SIP PRACK request and SIP 200 (OK) response see example in table A.4.3-18.

After the speech codec has been determined the MSC Server enhanced for ICS indicates that precondition is met.

Table A.4.3-18: PRACK request (from MSC Server enhanced for ICS to intermediate IM CN entities)

PRACK <sip: :user2_public1@home2.net;gr=urn:uuid:2ad8950e-48a5-4a74-8d99-ad76cc7fc74>

Via:SIP/2.0/UDP emsc1.home1.net;branch=z9hG4bK332b23.1

Max-Forwards: 70

P-Access-Network-Info:

Route::<sip:scscf1.home1.net>,<sip:sccas1.home1.net>; <sip:scscf2.home1.net;lr> <sip;pcscf1.home1.net;lr>

From:

To:

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-Type:

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=audio 49152 RTP/AVP 97 100

a=curr:qos local sendrececv

a=curr:qos remote none

a=des:qos mandatory local sendrecv

a=des:qos mandatory remote sendrecv

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

a=rtpmap:100 telephone-event

a=maxptime:240

19-20 Setup radio bearer

At the receipt of the SDP answer with the codec the MSC Server enhanced for ICS indicates the selected codec to the MGW. The MGW releases earlier booked codecs. In this scenario the bearer is set up to the CS UE.

21 RAB Assignment

The MSC Server enhanced for ICS sets up the radio bearer. It indicates in the NAS synchronisation indicator bit the selected codec to the CS UE.

22-24. SIP PRACK 200 (OK) (PRACK)

The PRACK request and its corresponding 200 are sent between MSC Server enhanced for ICS and the IMS UE.

25-28. SIP 180 (Ringing) response (IMS UE to MSC Server enhanced for ICS via intermediate IM CN subsystem entities)

IMS UE responds to the received SIP INVITE request with a SIP 180 (Ringing) response and alert UE 2.

The response contains no SDP body and contains no ICS specific content.

In this example the SCC AS includes in the Contact header field the contents of the Contact header field received in the SIP 180 (Ringing) response from the terminating side.

29-30. Send ringing tone.

At the receipt of the SIP 180 (Ringing) response the MSC Server enhanced for ICS orders the MGW to send a ringing tone towards CS UE.

31 Alerting (MSC Server enhanced for ICS to CS UE)

The MSC Server enhanced for ICS sends an alerting message to the CS UE.

32-35 SIP 200 (OK) (INVITE) from IMS UE to MSC Server enhanced for ICS via intermediate IM CN subsystem entities

When IMS UE answers the call the IMS UE sends a SIP 200 (OK) response to the received SIP INVITE request.

In this example the SCC AS includes in the Contact header field the contents of the Contact header field received in the SIP 200 (OK) response from the terminating side.

36-39 SIP ACK request (from IMS UE to MSC Server enhanced for ICS via intermediate IM CN subsystem entities)

40-41. Through connection in both directions

At the receipt of the SIP 200 (OK) (INVITE) the MSC Server enhanced for ICS through connect in both direction.

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

The MSC Server enhanced for ICS maps the received SIP 200 (OK) response to a CONNECT message.

There is no ICS specific content in this message.

43. CONNECT ACKNOWLEDGMENT (ICS UE A to MSC Server enhanced for ICS)

The ICS UE A sends a CONNECT ACKNOWLEDGMENT message upon receiving the CONNECT message.

There is no ICS specific content in this request.

A.4.4 Signalling flows for CS UE origination when using an MSC Server enhanced for ICS – one codec used

Figure A.4.4-1 shows the origination of a call from a CS UE which uses NAS signalling towards the MSC Server enhanced for ICS. The CS UE is controlled by an MSC Server enhanced for ICS. In this example the CS UE supports one speech codec. The MSC Server enhanced for ICS is not supporting codec negotiation. The MSC Server is enhanced for ICS and is capable of translating NAS signalling received from the CS UE to SIP and vice versa.

Figure A.4.4-1: CS UE Origination with CS media using an MSC Server enhanced for ICS – one codec used

The details of the signalling flows are as follows:

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

As a result of some stimulus to establish a session with voice media, The CS UE initiates service control signalling towards the MSC Server enhanced for ICS by sending a SETUP message.

Specifically for this signalling flow, the SETUP message includes:

– Called Party Number information element = [(Numbering plan identifier = ISDN/telephony numbering plan), (type of number = international number ), (Number digits =12125552222)]

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

The MSC Server enhanced for ICS knows the calling party number corresponding to the UE.

2. Call proceeding message (MSC Server enhanced for ICS to CS UE)

The MSC Server enhanced for ICS acknowledges the receipt of the SETUP message by sending a call proceeding message to the CS UE.

3-4. Interaction with the MGW to get media information eg address and port information is performed.

5. RAB Assignment(From MSC Server enhanced for ICS to the CS UE)

The MSC Server enhanced for ICS will send the selected codec to the CS UE in NAS synchronisation indicator bit in the RAB assignment message.

6. SIP INVITE request (MSC Server enhanced for ICS to IM CN subsystem entities) for detailed description see table A.4.4.6

Table A.4.4-6: SIP INVITE request (MSC Server enhanced for ICS to IMS CN subsystem entities)

INVITE tel:+1-212-555-2222 SIP/2.0

Via: SIP/2.0/UDP emsc1.home1.net;branch=z9hG4bK332b23.1

Max-Forwards: 68

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

P-Asserted-Identity: <tel:+1-212-555-1111>

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

Privacy: none

From: <sip:user2_public1@home1.net>;tag=171828

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

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 127 INVITE

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"

Supported: 100rel, precondition, gruu, 199

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"

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

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

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

Content-Type: application/sdp

Content-Length: (…)

v=0

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

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

t=0 0

m=audio 49152 RTP/AVP 97 100

b=AS:25.4

a=curr:qos local sendrecv

a=curr:qos remote none

a=des:qos mandatory local sendrecv

a=des:qos none remote sendrecv

a=rtpmap:97 AMR/8000/1

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

a=ptime:20

a=rtpmap:100 telephone-event

a=maxptime:240

Request-URI: SCC AS PSI DN as received in the SETUP message.

P-Asserted-Identity: The MSC Server enhanced for ICS inserts the tel-URI containing the telephone number stored in the MSC.

Accept-Contact: The MSC Server enhanced for ICS includes the mmtel feature tag in the INVITE request.

P-Asserted-Service: The MSC Server enhanced for ICS includes the mmtel ICSI value in INVITE request.

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 feature tag g.3gpp.ics set to "server".

SDP: The MSC Server enhanced for ICS includes the codec and IP addresses and port address as received from the MGW.

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

The intermediate IM CN subsystem entities respond to the MSC Server enhanced for ICS with a SIP 100 (Trying) response.

There is no ICS specific content in this response.

8. Evaluation of initial filter criteria

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

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

Table A.4.4-9: SIP INVITE request (IMS CN subsystem entities to SCC AS)

INVITE tel:+1-212-555-2222 SIP/2.0

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1

SIP/2.0/UDP emsc1.home1.net;branch=z9hG4bK332b23.1,

Max-Forwards: 67

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>

P-Asserted-Identity:

P-Access-Network-Info:

Privacy:

From:

To:

Call-ID:

Cseq:

P-Asserted-Service:

Accept-Contact:

Supported:

Contact:

Allow:

P-Access-Network-Info:

P-Charging-Vector:

Content-Type:

Content-Length: (…)

v=0

10. SIP 100 (Trying) response (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.

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

Table A.4.4-11: SIP INVITE request (SCC AS to IMS CN subsystem entities)

INVITE tel:+1-212-555-2222 SIP/2.0

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

SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1

SIP/2.0/UDP emsc1.home1.net;branch=z9hG4bK332b23.1

Max-Forwards: 66

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

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

P-Asserted-Identity:

Privacy:

From: <sip:user2_public1@home1.net>;tag=274890

To:

Call-ID:

Cseq:

Supported:

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"

P-Asserted- Service:

Accept-contact:

Allow:

P-Access-Network-Info:

P-Charging-Vector:

Content-Type:

Content-Length: (…)

v=0

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

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.

13. SIP INVITE request (intermediate IM CN subsystem entities to IMS UE)

The intermediate IM CN subsystem entities route the SIP INVITE request to IMS UE.

14. SIP 100 (Trying) response (UE B to intermediate IM CN subsystem entities)

UE B responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response.

There is no ICS specific content in this response.

15-18. SIP 180 (Ringing) response (UE B to MSC Server enhanced for ICS via intermediate IM CN subsystem entities)

UE B responds to the received SIP INVITE request with a SIP 180 (Ringing) response and alerts IMS UE. The response contains no SDP body and contains no ICS specific content.

In this example the SCC AS includes in the Contact header field the contents of the Contact header field received in the SIP 180 (Ringing) response from the terminating side. The SIP 180 (Ringing) response also includes the Record-Route header field(s) that was constructed by the SCC AS adding its SIP URI to the saved Record-Route header field(s) that was received in the initial SIP INVITE request in step 9.

19-20. Send ringing tone.

At the receipt of the SIP 180 (Ringing) response the MSC Server enhanced for ICS orders the MGW to send a ringing tone towards CS UE.

21. Alerting (MSC Server enhanced for ICS to CS UE)

The MSC Server enhanced for ICS sends an alerting message to the UE.

22-25 SIP 200 OK (INVITE) from MSC Server enhanced for ICS to IMS UE via intermediate IM CN subsystem entities

IMS UE sends a SIP 200 (OK) response to the received SIP INVITE request when IMS UE answers the call. The SIP 200 (OK) also include the SDP answer.

In this example the SCC AS includes in the Contact header field the contents of the Contact header field received in the SIP 200 (OK) response from the terminating side.

26-27- Through connection in both directions

At the receipt of the SIP 200 (OK) (INVITE) the MSC Server enhanced for ICS orders the MGW to through connects in both directions.

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

The MSC Server enhanced for ICS maps the received SIP 200 (OK) response to a CONNECT message. There is no ICS specific content in this message.

29. CONNECT ACKNOWLEDGMENT (CS UE to MSC Server enhanced for ICS)

The CS UE A sends a CONNECT ACKNOWLEDGMENT message upon receiving the CONNECT message.

30-33. SIP ACK request (MSC Server enhanced for ICS to IMS UE via intermediate IM CN subsystem entities)

Upon receiving the CONNECT ACKNOWLEDGEMENT from the CS UE A, the MSC Server enhanced for ICS forwards a SIP ACK request to the SCC AS via the intermediate IM CN Subsystem entities.

There is no ICS specific content in this request.

A.4.5 Signalling flows for CS UE origination when using an MSC Server not enhanced for ICS

Figure A.4.5-1 shows the origination of a call in the CS domain when using an MSC server not enhanced for ICS. The originating UE can be an ICS UE or can be a UE without ICS capabilities.

Figure A.4.5-1: CS UE origination when using an MSC Server not enhanced for ICS

The details of the signalling flows are as follows:

1 Determination of call establishment domain

As a result of some stimulus to establish a full-duplex, voice-only call, the UE based on a combination of user policy, and access technology availability, decides to establish the call using the CS domain.

2. SETUP message (UE to VMSC)

After establishment of the MM connection, the UE initiates the CS call towards the destination UE by sending out the SETUP message.

Specifically for this signalling flow, the SETUP message includes:

– Called Party Number information element = [(Numbering plan identifier = ISDN/telephony numbering plan), (type of number = international number ), (Number digits = 12125552222)]

– Bearer Capability information element = [(information transfer capability = speech), (speech versions = FR AMR, GSM EFR, GSM FR)]

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

The VMSC knows the calling party number corresponding to the UE.

3. Origination triggers

4. Redirection to IM CN subsystem

The call is redirected to the IM CN subsystem. The mechanism for redirection is out of scope of ICS requirements and can be based upon the use of an IP Multimedia Routing Number (IMRN) for redirecting the signalling towards the SCC AS. How an IMRN is retrieved is outside the scope of this specification.

5. ISUP IAM (VMSC to MGCF)

The VMSC initiates the CS call towards the MGCF by sending out the IAM message.

Specifically for this signalling flow, the IAM includes:

– Called Party Number parameter = [(Numbering plan identifier = ISDN/telephony numbering plan), (type of number = international number ), (Number digits = 12415553333)]

– Calling Party Number parameter = [(Numbering plan identifier = ISDN/telephony numbering plan), (type of number = international number ), (Number digits = 12125551111)]

– USI parameter = 3.1 kHz audio

The Called Party Number parameter represents the IMRN allocated for this call.

6. SIP INVITE request (MGCF to intermediate IM CN subsystem entities) – see example in table A.4.5-6

The MGCF initiates a SIP INVITE request, containing an initial SDP to the intermediate IM CN subsystem entities.

Table A.4.5-6: SIP INVITE request (MGCF to intermediate IM CN subsystem entities)

INVITE tel:+1-241-555-3333 SIP/2.0

Via: SIP/2.0/UDP mgcf1.home1.net;branch=z9hG4bK779s24.0

Max-Forwards: 70

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

P-Asserted-Identity: <tel:+1-212-555-1111>

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

Privacy: none

From: <tel:+1-212-555-1111>;tag=171828

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

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 127 INVITE

Supported: 100rel, precondition

Contact: <sip:mgcf1.home1.net>;+g.3gpp.icsi-ref="urn%3Aurn-7%3gpp-service.ims.icsi.mmtel"

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

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=audio 3456 RTP/AVP 97 96

b=AS:25.4

a=curr:qos local sendrecv

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: Contains the IMRN, as obtained from CS Networks signalling.

P-Asserted-Identity: The MGCF inserts the tel URL containing the subscriber number, as received from the CS network.

SDP: The SDP contains a preconfigured set of codecs supported by the MGW based on what is received in the ISUP. The codecs selected are speech codecs. See table 10a of 3GPP TS 29.163 [10]

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

The IMRN is a PSI. The intermediate IM CN subsystem entities are configured to route this PSI to the SCC AS. In this particular case, the I-CSCF performs the routeing over the Ma interface. For this example, there is no IBCF before the I-CSCF and no intermediate entities Record-Route the request.

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

INVITE tel:+1-241-555-3333 SIP/2.0

Via: SIP/2.0/UDP mgcf1.home1.net;branch=z9hG4bK779s24.0, SIP/2.0/UDP icscf1_s.home1.net;branch=z9hG4bK312a32.1

Max-Forwards: 69

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

P-Asserted-Identity:

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

Privacy:

From:

To:

Call-ID:

Cseq:

Supported:

Contact:

Allow:

Content-Type:

Content-Length: (…)

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

There is no ICS specific content to this response.

The SCC AS responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response.

9. Retrieve original calling and called party information

The SCC AS acts as a routeing B2BUA. The SCC AS retrieves the original called party number and calling party number associated with the IMRN and places the called party number in the Request-URI and the To header field of the outgoing request.

How to retrieve the original called party and calling party numbers associated with the IMRN are considered to be out of scope of this specification.

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

The SCC AS forwards the SIP INVITE request to the S-CSCF serving the originating user within the IM CN subsystem. In this case it is assumed that the user is registered within the IM CN subsystem.

In this example the SCC AS includes the contents of the Contact header from the received SIP INVITE request The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, To, Cseq and Call-ID header fields from one side of the B2BUA to the other.

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

INVITE tel:+1-212-555-2222 SIP/2.0

Via: SIP/2.0/UDP;branch=z9hG4bK312a32.1

Max-Forwards: 68

Route: <sip:s-cscf.home1.net;lr;orig>

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

P-Asserted-Identity:

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

Privacy:

From: <tel:+1-212-555-1111>;tag=274890

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

Call-ID: dc14b1t10b3teghmlk501444

Cseq:

Supported:

Contact:

Allow:

Content-Type:

Content-Length: (…)

Contact: In this example the SCC AS includes the contents of the Contact header from the received SIP INVITE request

11. SIP 100 (Trying) response (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 content to this response.

12. SIP INVITE request (intermediate IM CN subsystem entities to terminating side processing) – see example in table A.4.5-12

The intermediate IM CN subsystem entities route the SIP INVITE request to the terminating side processing. In this example, there is no intermediate IBCF and none of the intermediate entities Record-Route.

Table A.4.5-12: SIP INVITE request (intermediate IM CN subsystem entities to terminating side processing)

INVITE tel:+1-212-555-2222 SIP/2.0

Via: SIP/2.0/UDP;branch=z9hG4bK312a32.1

Max-Forwards: 68Record-Route:<sip:sccas.home1.net;lr>

P-Asserted-Identity:

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

Privacy:

From:

To:

Call-ID:

Cseq:

Supported:

Contact:

Allow:

Content-Type:

Content-Length: (…)

13. SIP 100 (Trying) response (terminating side processing to intermediate IM CN subsystem entities)

The terminating side processing responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response.

There is no ICS specific content to this response.

14. SIP 180 (Ringing) response, ISUP ACM and ALERTING message (terminating side processing to VCC UE)

The call is successfully delivered to the terminating UE, which begins alerting the user. Normal SIP, ISUP and access signalling messages are transferred to indicate this is occurring. At or before this time, completion of negotiation of the bearer (e.g. as indicated by SDP in SIP) occurs. There is no ICS specific actions associated with this step.

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, To, Cseq and Call-ID header fields from one side of the B2BUA to the other.

In this example the SCC AS includes in the Contact header field the contents of the Contact header field received in the SIP 180 (Ringing) response from the terminating side.

15. SIP 200 (OK) response (terminating side processing to intermediate IM CN subsystem entities)

A SIP 200 (OK) response is received from the terminating side processing by the intermediate IM CN subsystem entities.

There is no ICS specific content to this response.

16. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS)

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SCC AS.

There is no ICS specific content to this response.

17. SIP 200 (OK) response (SCC AS intermediate to IM CN subsystem entities)

The SCC AS forwards the SIP (200) OK response back to the intermediate IM CN subsystem entities.

The UE modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, To, Cseq and Call-ID header fields from one side of the B2BUA to the other.

In this example the SCC AS includes in the Contact header field the contents of the Contact header field received in the SIP 200 (OK) response from the terminating side

There is no ICS specific content to this response.

18. SIP 200 (OK) response (intermediate IM CN subsystem entities to MGCF)

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the MGCF.

There is no ICS specific content to this response.

19. ISUP ANM (MGCF to VMSC)

On receipt of the SIP 200 (OK) response, the MGCF generates an ISUP ANM message and sends this to the VMSC.

There is no ICS specific content to this response.

20. CONNECT message (VMSC to UE)

The VMSC sends a CONNECT message to the UE.

There is no ICS specific content to this response.

21. CONNECT ACKNOWLEDGE message (UE to VMSC)

The UE generates the CONNECT ACKNOWLEDGE message on receipt of the CONNECT message.

There is no ICS specific content to this response.

22. SIP ACK request (MGCF to intermediate IM CN subsystem entities)

The MGCF generates a SIP ACK request on receipt of the SIP 200 (OK) response and sends it back to the intermediate IM CN subsystem entities.

There is no ICS specific content to this response.

23. H.248 interaction with the MGW

The MGCF interacts with the MGW for the necessary resource allocation.

24. SIP ACK request (intermediate IM CN subsystem entities to SCC AS)

The intermediate IM CN subsystem entities forward the SIP ACK request to the SCC AS.

There is no ICS specific content to this response.

25. SIP ACK request (SCC AS to intermediate IM CN subsystem entities)

The SCC AS forwards the SIP ACK request back to the intermediate IM CN subsystem entities.

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, To, Cseq and Call-ID header fields from one side of the B2BUA to the other.

There is no VCC specific content to this response.

26. SIP ACK request (intermediate IM CN subsystem entities to terminating side processing)

The intermediate IM CN subsystem entities forward the SIP ACK request to the terminating side processing.

There is no ICS specific content to this response.

A.4.6 Signalling flows for ICS UE origination when using I1 interface

Figure A.4.6-1 shows ICS UE origination signalling flows using I1 when the MSC server. The MSC server can be enhanced for ICS but need not be.

Figure A.4.6-1: ICS UE origination signalling flows

The details of the signalling flows are as follows:

1. Determination of call establishment

2. I1 Invite message (ICS UE to intermediate IM CN subsystem entities).

The ICS UE initiates service control signalling in the IM CN subsystem towards the SCC AS by sending an I1 Invite message.

Specifically for this signalling flow, the I1 Invite message includes:

– Protocol Information = 0x11

– Message Type = I1 Invite

– Reason = MO (0x000)

– Call ID = (0x100)

– Sequence-ID = (0x1)

– To-id = [(international number), (12125556666)]

– From-id = [(international number), (12125551111)]

7. SCC AS allocates an IUA PSI DN to the ICS UE

The SCC AS stores the information received in the initial I1 Invite message and associates an IUA PSI DN with this request. The IUA PSI DN is returned in a I1 Progress message to the ICS UE together with an indication that CS bearer establishment is to be initiated by the ICS UE. For this example the IUA PSI DN is chosen as +1212556666.

8. I1 Progress message (SCC AS to ICS UE via I1 protocol)

Specifically for this signalling flow, the I1 Progress message includes:

– Protocol Information = 0x11

– Message Type = I1 Progress

– Reason = 0x0 183

– Call ID = (0x100)

– Sequence-ID = 0x1

– SCC-AS-id information element = [(Code specific = E.164 number), (number digits = 1212556666)]. This is the allocated SCC AS PSI DN

– Session-identifier information element = [(Code specific = E.164 number), (number digits = 1212557777)]. This is the allocated SCC AS STI

11. ICS UE proceeds to setup CS bearers

Upon receipt of the IUA PSI DN, the ICS UE proceeds with setting up the call using CS bearers.

12. CC SETUP message (ICS UE to MSC server)

The ICS UE initiates the call over CS bearers by sending a CC SETUP message to the MSC server.

Specifically for this signalling flow, the CC SETUP message includes:

1) Called Party Number information element = [(Numbering plan identifier = ISDN/telephony numbering plan), (type of number = international number ), (Number digits = 1212556666)]. The Called Party Number information element is set to the IUA PSI DN.

2) Bearer Capability information element = [(information transfer capability = speech), (speech versions = FR AMR, GSM EFR, GSM FR)]

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

The MSC server knows the calling party number corresponding to the UE.

13. CC CALL PROCEEDING message (MSC server to ICS UE)

Upon receipt of the CC SETUP message from the ICS UE, the MSC server responds with a CC CALL PROCEEDING message. There is no ICS specific content in this message.

14. SIP INVITE request (MSC server to intermediate IM CN subsystem entities via MGCF) – see example in table A.4.6-14

The MSC server maps the received CC SETUP message to an ISUP IAM. The MGCF maps the ISUP IAM to a SIP INVITE request which is addressed to the IUA PSI DN.

Table A.4.6-14: SIP INVITE request (MSC server to intermediate IM CN subsystem entities)

INVITE tel:+1-212-555-6666 SIP/2.0

Via: SIP/2.0/UDP mgcf1.home1.net;branch=z9hG4bKnashds7

Max-Forwards: 70

Route: <sip:icscf1.home1.net:lr>

P-Asserted-Identity: <tel: +1-212-555-1111>

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

P-Access-Network-Info:

Privacy: none

From: <tel: +1-212-555-1111>;tag=171828

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

Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6

Cseq: 127 INVITE

Supported: 100rel, precondition

Contact:

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:eee

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

t=0 0

m=audio 3456 RTP/AVP 97 96

b=AS:25.4

a=curr:qos local sendrecv

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: UAI PSI DN as received in the SETUP message

P-Asserted-Identity: The MSC server inserts the tel-URI containing the subscriber number, as received from the ICS UE

SDP: The SDP contains preconfigured set of codecs supported by the MGW.

15. SIP 100 (Trying) response (intermediate IM CN subsystem entities to MGCF)

The intermediate IM CN subsystem entities respond to the MGCF with a SIP 100 (Trying) response.

There is no ICS specific content in this response.

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

The SIP INVITE request is routed towards the SCC AS.

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

INVITE tel:+1-212-555-6666 SIP/2.0

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP icscf1.home1.net;branch=z9hG4bKdwe534, SIP/2.0/UDP mgcf1.hom1.net;branch=z9hG4bKnashds7

Max-Forwards: 68

Route: <sip:sccas1.home1.net:lr>, <sip:scscf1.home1.net;lr>;orig-dialog-id="yuflsae80r3rb3fh31ondyr829cnyr381cn932YDWref0w0-wwtg374"

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

P-Asserted-Identity: <tel: +1-212-555-1111>

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: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"; orig-ioi="type 3home1.net"

P-Access-Network-Info:

Privacy: none

From: <tel: +1-212-555-1111>;tag=171828

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

Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6

Cseq: 127 INVITE

Supported:

Require:

Proxy-Require:

Security-Verify:

Contact:

Allow:

Content-Type:

Content-Length:

v=0

17. SIP 100 (Trying) response (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.

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

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

INVITE tel:+1-212-555-2222 SIP/2.0

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

Max-Forwards: 67

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

P-Asserted-Identity: <tel: +1-212-555-1111>

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: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"; orig-ioi="type3home1.net"

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

Privacy: none

From: <tel: +1-212-555-1111>;tag=171828

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

Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6

Cseq: 127 INVITE

Supported: 100rel, precondition

Require: sec-agree

Proxy-Require: sec-agree

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi=87654321; port=7531

Contact:

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:eee

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

t=0 0

m=audio 3456 RTP/AVP 97 96

b=AS:25.4

a=curr:qos local sendrecv

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 SCC AS replaces the IUA PSI DN with the tel URI of the called party which was stored from the initial SIP INVITE request sent in step 2.

19. SIP 100 (Trying) response (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.

20. SIP INVITE request (intermediate IM CN subsystem entities to UE B)

The intermediate IM CN subsystem entities route the SIP INVITE request to UE B.

21. SIP 100 (Trying) response (UE B to intermediate IM CN subsystem entities)

UE B responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response.

There is no ICS specific content in this response.

22-23. SIP 180 (Ringing) response (UE B to SCC AS via intermediate IM CN subsystem entities)

UE B responds to the received SIP INVITE request with a SIP 180 (Ringing) response. The response contains no SDP body and contains no ICS specific content.

24. I1 Progress message (SCC AS to ICS UE A via using I1 protocol) – see example in table A.4.6-24

Upon receiving the SIP 180 (Ringing) response from the terminating UE, the SCC AS sends an I1 Progress message to the ICS UE A using the I1 protocol. The response is associated with the SIP INVITE in step 2.

Specifically for this signalling flow, the I1 Progress message includes:

– Protocol Information = 0x11

– Message Type = I1 Progress

– Reason = 0x0 180

– Call ID = (0x100)

– Sequence-ID = 0x1

26. SIP 200 (OK) response (UE B to to intermediate IM CN subsystem entities) – see example in table A.4.6-26

The terminating side sends an SDP answer in a SIP 200 (OK) response to the received SIP INVITE request.

Table A.4.6-26: SIP 200 (OK) response (UE B to intermediate IM CN subsystem entities)

SIP/2.0 200 OK

Record-Route: <sip:pcscf2.visited2.net:5088;lr;comp=sigcomp>, <sip:scscf2.visited2.net;lr>, <sip:scscf1.home1.net;lr>

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

Privacy: none

From: <tel: +1-212-555-1111>;tag=171828

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

Call-ID:

CSeq:

Require: 100rel, precondition

Contact:

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

Content-Type: application/sdp

Content-Length: (…)

v=0

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

s=-

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

t=0 0

m=audio 3456 RTP/AVP 97 96

b=AS:25.4

a=curr:qos local sendrcv

a=curr:qos remote sendrcv

a=des:qos mandatory local sendrecv

a=des:qos mandatory remote sendrecv

a=rtpmap:97 AMR

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

a=maxptime:20

27. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS)

The SIP 200 (OK) response from UE is routed towards the SCC AS.

28-29. SIP 200 (OK) response (SCC AS to MSC server via intermediate IM CN subsystem entities and)

The SDP answer received in the SIP 200 (OK) response is routed to the MSC server via the intermediate IM CN subsystem entities and MGCF. The MGCF maps the SIP 200 (OK) response into a ISUP ANM.

30. CC CONNECT message (MSC server to ICS UE)

The enhanced MSC server maps the received SIP 200 (OK) to a CC CONNECT message. There is no ICS specific content in this message.

31. CC CONNECT ACKNOWLEDGMENT (ICS UE A to MSC Server)

The ICS UE A sends a CC CONNECT ACKNOWLEDGMENT message upon receiving the CONNECT message.

32-33. SIP ACK request (MGCF to SCC AS via intermediate IM CN subsystem entities)

The MGCF forwards a SIP ACK request to the SCC AS via the intermediate IM CN Subsystem entities.

There is no ICS specific content in this request.

34. I1 Success message (SCC AS to ICS UE A via I1 protocol) – see example in table A.4.6-34

The SCC AS responds with an I1 Success message to the initial I1 Invite message sent by the ICS UE A in the step 2.

Specifically for this signalling flow, the I1 Success message includes:

– Protocol Information = 0x11

– Message Type = I1 Success

– Reason = 0x0

– Call ID = (0x100)

– Sequence-ID = 0x3

35-36. SIP ACK request (SCC AS to UE B via intermediate IM CN subsystem entities)

The SCC AS sends a SIP ACK request to UE B via the IM CN subsystem entities. There is no ICS specific content in this response.