A.4 Signalling flows for call origination

24.2063GPPStage 3TSVoice call continuity between Circuit Switched (CS) and IP Multimedia Subsystem (IMS)

A.4.1 Introduction

The signalling flows for call origination demonstrate how a VCC UE, on originating a call, is anchored for the purposes of a future domain transfer. The following signalling flows are included:

– subclause A.4.2 shows the successful anchoring for a call originated using the IM CN subsystem;

– subclause A.4.3 shows the successful anchoring for a call originated using the CS domain, by routeing the call to the IM CN subsystem using CAMEL;

– subclause A.4.4 shows the successful anchoring for a call originated using the CS domain, by routeing the call to the IM CN subsystem using CAMEL and routeing the call from the VCC application to the terminating subscriber using information received in the SIP History-Info header;

– subclause A.4.5 shows a call originated from the CS domain for which the anchoring is denied; the call is continued in the CS domain; and

– subclause A.4.6 shows the origination of a call in the CS domain that is capable of being subject to VCC when the user is not currently registered within the IMS CN subsystem.

A.4.2 Signalling flows for origination from the IM CN subsystem

Figure A.4.2-1: Signalling flow for origination from the IM CN subsystem

1. Determination of call establishment domain

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

The VCC UE initiates the IM CN subsystem call towards the destination UE by sending a SIP INVITE request to the intermediate IM CN subsystem entities.

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

Table A.4.2-2: SIP INVITE request (VCC 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: <tel: +1-212-555-1111>

P-Access-Network-Info:IEEE-802.11b

Privacy: none

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

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

Call-ID: cb03a0s09a2sdfglkj490333

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; port1=7531

Contact: < sip:[5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp >

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: the tel-URI of the destination

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

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

There is no VCC specific content to this response.

4. Evaluation of initial filter criteria

In this example, and by evaluation of the initial filter criteria, as this is an originating SIP INVITE request for a registered VCC user the S-CSCF routes the SIP INVITE request to the DTF.

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

The intermediate IM CN subsystem entities send the SIP INVITE request to the DTF.

As part of this operation, the S-CSCF adds the address of the DTF and the original dialog identifier. The S-CSCF will include the original dialog identifier as a part of the second topmost Route header. The Request-URI includes the tel-URI of the destination.

Table A.4.2-5: SIP INVITE request (intermediate IM CN subsystem entities to VCC application)

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

Route: <sip:dtf1.home1.net;lr>,<sip:cb03a0s09a2sdfglkj490333@scscf1.home1.net;lr>

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

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

P-Access-Network-Info:

Privacy: none

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

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]

From:

To:

Call-ID:

Cseq: 127

Supported:

Contact:

Allow:

Content-Type:

Content-Length: (…)

v=0

o=

s=

c=

t=

m=

b=

a=

a=

a=

a=

a=

a=

a=

a=

6. SIP 100 (Trying) response (DTF to intermediate IM CN subsystem entities)

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

There is no VCC specific content to this response.

7. Anchoring decision

The DTF performs the anchoring.

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

Since the service execution continues as an originating case the DTF, after executing the anchoring, sends the SIP INVITE request with a Route header that includes the original call identifier in the Route header to the intermediate IM CN subsystem entities.

The DTF works in this case as a routeing B2BUA. In particular, the To and From header fields remain unchanged. It will not include any entry in the Record-Route header. The AS does not change any codecs.

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

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

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

Via: SIP/2.0/UDP dtf1.home1.net; branch=z9hG4bK332b23.3;

Max-Forwards: 66

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

P-Asserted-Identity:

P-Access-Network-Info:

Privacy: none

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

P-Charging-Function-Addresses:

From:

To:

Call-ID:

Cseq: 127

Supported:

Contact:<sip:[7777::eee:ddd:ccc:aaa]>

Allow:

Content-Type:

Content-Length: (…)

v=0

o=

s=

c=

t=

m=

b=

a=

a=

a=

a=

a=

a=

a=

a=

Request-URI: includes the tel-URI of the destination.

Contact: address of the DTF.

9. SIP 100 (Trying) response (intermediate IM CN subsystem entities to DTF)

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

There is no VCC specific content to this response.

10. Evaluation of initial filter criteria

In this example, the S-CSCF continues the triggering from the next trigger point (originating request registered user) in the initial filter criteria. Since no more triggering is required in the initial filter criteria, the IM CN subsystem will do a ENUM look up and get the SIP-URI for the destination user.

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

The intermediate IM CN subsystem sends a SIP INVITE request towards the terminating side.

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

INVITE sip:user2_public1@home2.net SIP/2.0

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

Max-Forwards: 65

Record-Route:sip.scscf1.home1.net

P-Asserted-Identity:

Privacy: none

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

From

To:

Call-ID

Cseq:

Supported:

Contact:

Allow:

Content-Type:

Content-Length: (…)

v=0

o=

s=

c=

t=

m=

b=

a=

a=

a=

a=

a=

a=

a=

a=

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

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

There is no VCC specific content to this response.

13a-d. SIP 183 (Session Progress) response / SIP PRACK request / SIP 200 (OK) response / SIP 180 (Ringing) response

The SIP endpoints complete SDP offer/answer procedures, including any reservation of bearer resource on the IP-CAN, and any exchange of alerting indication, in accordance with standard basic call procedures. VCC imposes no restriction on this operation.

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

The terminating side processing forwards a SIP 200 (OK) response to the intermediate IM CN subsystem entities.

There is no VCC specific content to this response.

15. SIP 200 (OK) response (intermediate IM CN subsystem entities to DTF)

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

There is no VCC specific content to this response.

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

The DTF forwards the SIP 200 (OK) response to the intermediate IM CN subsystem entities, using the content of the Via header in the received SIP INVITE request (step 5).

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

There is no VCC specific content to this response.

17. SIP 200 (OK) response (intermediate IM CN subsystem entities to VCC UE)

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

There is no VCC specific content to this response.

18. SIP ACK request (VCC UE to intermediate IM CN subsystem entities)

The VCC UE completes the dialog creation with a SIP ACK request sent to the intermediate IM CN subsystem entities.

There is no VCC specific content to this request.

19. SIP ACK request-(intermediate IM CN subsystem entities to DTF)

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

There is no VCC specific content to this request.

20. SIP ACK request (DTF to intermediate IM CN subsystem entities)

The DTF forwards the SIP ACK request to the intermediate IM CN subsystem entities.

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

There is no VCC specific content to this request.

21. 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 VCC specific content to this request.

A.4.3 Signalling flows for origination from CS domain

Figure A.4.3-1 shows the origination of a call in the CS domain that is capable of being subject to VCC.

Figure A.4.3-1: CS call origination from the VCC user

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 VCC UE based on a combination of user policy, and access technology availability, decides to establish the call using the CS domain.

2. SETUP message (VCC UE to VMSC)

After establishment of the MM connection, the VCC 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 Called Party Number information element identifies the intended recipient of the call, and the Bearer Capability information element and the Supported Codec List information element identify an intended call that can be subject to VCC.

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

3. Origination triggers

4. CAMEL IDP (VMSC to gsmSCF)

The VMSC triggers a CAMEL activity which results in sending a CAMEL IDP message to the gsmSCF. The CAMEL IDP message contains at least:

– the calling party number;

– the called party number; and

– that the call is voice only.

5. Anchor decision

The gsmSCF invokes the service logic to determine whether the call needs to be rerouted to IMS for VCC. The CAMEL service function allocates an IMRN and returns it to the gsmSCF.

6. CAMEL service function to CSAF interaction

Communication is required between the CAMEL service function and the CSAF in order to ensure that the nature of the call associated with the IMRN is known by the CSAF. The signalling to support this communication is not specified in this version of the specification.

7. CAMEL CONNECT (gsmSCF to VMSC)

The gsmSCF responds to the CAMEL IDP message with a CAMEL CONNECT message containing:

– the Destination Routeing Address set to the IMRN.

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

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

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

Table A.4.3-9: 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>

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, for which VCC can be applied. See table 10a of 3GPP TS 29.163 [10]

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

The IMRN is a PSI. The intermediate IM CN subsystem entities are configured to route this PSI to the CSAF. 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.3-10: SIP INVITE request (intermediate IM CN subsystem entities to CSAF)

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:csaf1.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: (…)

v=

o=

s=

c=

t=

m=

b=

a=

a=

a=

a=

a=

a=

a=

a=

11. SIP 100 (Trying) response (CSAF to intermediate IM CN subsystem entities)

There is no VCC specific content to this response.

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

12. Session anchoring

The CSAF and DTF in combination act as an initiating B2BUA. The CSAF 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 of the outgoing request.

The CSAF and DTF in combination decide that this call will be anchored, based on the type of call and operator preferences.

The DTF found by the IMRN need not be the most appropriate AS to support the handover of the call on behalf of the UE in the IM CN subsystem. In these cases it is possible that the VCC application redirects the call to another applications server which provides the future transfer functions on behalf of the VCC user. How this occurs is outside the scope of this document.

13. Interaction between CSAF and DTF

Information is exchanged between the CSAF and the DTF. The nature of this signalling is outside the scope of this version of the specification. In this example, the subsequent flows assume that a visit has been made to the S-CSCF, in association with the triggering of initial filter criteria, in order to reach the DTF.

14. VCC application

The CSAF and DTF in combination act as an initiating B2BUA. The DTF anchors the call to provide VCC functionality.

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

The DTF 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.

The DTF sets the value of the Contact header with the address of the DTF that will provide the transfer functionality needed to support VCC.

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

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

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

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

Max-Forwards: 66

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

P-Asserted-Identity:

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

Privacy:

From:

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

Call-ID: dc14b1t10b3teghmlk501444

Cseq:

Supported:

Contact: <sip:dtf1.home1.net>

Allow:

Content-Type:

Content-Length: (…)

v=

o=

s=

c=

t=

m=

b=

a=

a=

a=

a=

a=

a=

a=

a=

Contact header: The Contact header represents the contact of the DTF.

16. SIP 100 (Trying) response (intermediate IM CN subsystem entities to DTF)

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

There is no VCC specific content to this response.

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

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.3-17: 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 scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP dtf1.home1.net;branch=z9hG4bK312a32.1

Max-Forwards: 65

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: (…)

v=

o=

s=

c=

t=

m=

b=

a=

a=

a=

a=

a=

a=

a=

a=

18. 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 VCC specific content to this response.

19. 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 VCC specific actions associated with this step.

The DTF and CSAF modify the message in accordance with initiating B2BUA functionality, e.g. mapping of From, To, Cseq and Call-ID headers from one side of the B2BUA to the other.

20. 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 VCC specific content to this response.

21. SIP 200 (OK) response (intermediate IM CN subsystem entities to DTF)

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

There is no VCC specific content to this response.

22. Interaction between DTF and CSAF

Information is exchanged between the CSAF and the DTF. The nature of this signalling is outside the scope of this version of the specification.

The DTF and CSAF modify the message in accordance with initiating B2BUA functionality, e.g. mapping of From, To, Cseq and Call-ID headers from one side of the B2BUA to the other.

23. SIP 200 (OK) response (CSAF to intermediate IM CN subsystem entities)

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

There is no VCC specific content to this response.

24. 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 VCC specific content to this response.

25. 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 VCC specific content to this response.

26. CONNECT message (VMSC to VCC UE)

The VMSC sends a CONNECT message to the VCC UE.

There is no VCC specific content to this response.

27. CONNECT ACKNOWLEDGE message (VCC UE to VMSC)

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

There is no VCC specific content to this response.

28. 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 VCC specific content to this response.

29. H.248 interaction with the MGW

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

30. SIP ACK request (intermediate IM CN subsystem entities to CSAF)

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

There is no VCC specific content to this response.

31. Interaction between CSAF and DTF

Information is exchanged between the CSAF and the DTF. The nature of this signalling is outside the scope of this version of the specification.

The DTF and CSAF modify the message in accordance with initiating B2BUA functionality, e.g. mapping of From, To, Cseq and Call-ID headers from one side of the B2BUA to the other.

32. SIP ACK request (DTF to intermediate IM CN subsystem entities)

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

There is no VCC specific content to this response.

33. 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 VCC specific content to this response.

A.4.4 Signalling flows for origination from CS domain, using ISUP call diversion mechanisms

Figure A.4.4-1 shows the origination of a call in the CS domain that is capable of being subject to VCC. In the example below it is assumed that the gsmSCF based on the service key returns the parameters Original Called Party ID, Redirecting Party and Redirection information. Further it is assumed that the corresponding ISUP parameters are later on mapped in the MGCF to appropriate SIP header fields.

Figure A.4.4-1: CS call origination from the VCC user

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 VCC UE based on a combination of user policy, and access technology availability, decides to establish the call using the CS domain.

2. SETUP message (VCC UE to VMSC)

After establishment of the MM connection, the VCC UE#1 initiates the CS call towards UE#2 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 Called Party Number information element identifies the intended recipient of the call, and the Bearer Capability information element and the Supported Codec List information element identify an intended call that can be subject to VCC.

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

3. Origination triggers

4. CAMEL IDP (VMSC to CAMEL service function)

On receipt of the SETUP message, the VMSC triggers a CAMEL activity which results in sending a CAMEL IDP message to the gsmSCF. The CAMEL IDP message contains at least:

– the calling party number;

– service key assigned to the subscriber;

– the called party number; and

– that the call is voice only.

5. Anchor decision

The CAMEL service function decides that this call will be anchored, based on the type of call and operator preferences.

6. CAMEL CONNECT (gsmSCF to VMSC)

The CAMEL service function in this example causes the gsmSCF to respond to the CAMEL IDP message with a CAMEL CONNECT message containing:

– the Destination Routing Address set to the IMRN;

– the Original Called Party ID;

– Redirecting Party ID; and

– Redirection Information.

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

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

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

– Redirection information = [(Redirecting indicator = call diverted, all redirection info presentation restricted), (Original redirection reason = unknown), (Redirection counter = 1), Redirecting reason = unknown)]

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

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

The MGCF initiates a SIP INVITE request, containing an initial SDP. The MGCF in this example needs to support call diversion.

Table A.4.4-8: 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>

History-Info: <tel:+1-212-555-2222>; index=1, < tel:+1-212-555-2222>;\cause=404; index=1.1

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 domain signalling.

P-Asserted-Identity: The MGCF inserts the tel-URL containing the calling party 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, for which VCC can be applied. See table 10a of 3GPP TS 29.163 [10].

History-Info: The MGCF inserts the original called party number and an entry for the redirecting number as received from the CS network.

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

The IMRN is a PSI. The intermediate IM CN subsystem entities are configured to route this PSI to the CSAF. 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.4-9: SIP INVITE request (intermediate IM CN subsystem entities to CSAF)

INVITE tel:+1-212-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:csaf1.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:

History-Info:

Allow:

Content-Type:

Content-Length: (…)

v=

o=

s=

c=

t=

m=

b=

a=

a=

a=

a=

a=

a=

a=

a=

10. SIP 100 (Trying) response (CSAF to intermediate IM CN subsystem entities)

There is no VCC specific content to this response.

11. VCC application

The CSAF and DTF in combination act as an initiating B2BUA. The CSAF places the original call party number in the Request-URI and the To header of the outgoing request and removes the History-Info header.

12. Interaction between CSAF and DTF

Information is exchanged between the CSAF and the DTF. The nature of this signalling is outside the scope of this version of the specification. In this example, the subsequent flows assume that a visit has been made to the S-CSCF, in association with the the triggering of initial filter criteria, in order to reach the DTF.

13. VCC application

The CSAF and DTF in combination act as an initiating B2BUA. The DTF anchors the call to provide VCC functionality.

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

The DTF 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.

The DTF sets the value of the Contact header with the address of the DTF that will provide the transfer functionality needed to support VCC.

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

Table A.4.4-14: SIP INVITE request (DTF to intermediate IM CN subsystem entities)

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

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

Max-Forwards: 66

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

P-Asserted-Identity:

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

Privacy:

From:

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

Call-ID: dc14b1t10b3teghmlk501444

Cseq:

Supported:

Contact: <sip:dtf1.home1.net>

Allow:

Content-Type:

Content-Length: (…)

v=

o=

s=

c=

t=

m=

b=

a=

a=

a=

a=

a=

a=

a=

a=

Contact header: The Contact header represents the contact of the DTF.

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

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

There is no VCC specific content to this response.

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

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

Table A.4.4-16: 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 scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP dtf1.home1.net;branch=z9hG4bK312a32.1

Max-Forwards: 65

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: (…)

v=

o=

s=

c=

t=

m=

b=

a=

a=

a=

a=

a=

a=

a=

a=

17. 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 VCC specific content to this response.

18. 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 VCC specific actions associated with this step.

The DTF and CSAF modify the message in accordance with initiating B2BUA functionality, e.g. mapping of From, To, Cseq and Call-ID headers from one side of the B2BUA to the other.

19. 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 VCC specific content to this response.

20. SIP 200 (OK) response (intermediate IM CN subsystem entities to DTF)

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

There is no VCC specific content to this response.

21. Interaction between DTF and CSAF

Information is exchanged between the CSAF and the DTF. The nature of this signalling is outside the scope of this version of the specification.

The DTF and CSAF modify the message in accordance with initiating B2BUA functionality, e.g. mapping of From, To, Cseq and Call-ID headers from one side of the B2BUA to the other.

22. SIP 200 (OK) response (CSAF to intermediate IM CN subsystem entities)

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

There is no VCC specific content to this response.

23. 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 VCC specific content to this response.

24. 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 VCC specific content to this response.

25. CONNECT (VMSC to VCC UE)

The VMSC sends a CONNECT message to the VCC UE.

There is no VCC specific content to this response.

26. CONNECT ACKNOWLEDGE (VCC UE to VMSC)

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

There is no VCC specific content to this response.

27. 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 VCC specific content to this response.

28. H.248 interaction with the MGW

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

29. SIP ACK request (intermediate IM CN subsystem entities to CSAF)

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

There is no VCC specific content to this response.

30. Interaction between CSAF and DTF

Information is exchanged between the CSAF and the DTF. The nature of this signalling is outside the scope of this version of the specification.

The DTF and CSAF modify the message in accordance with initiating B2BUA functionality, e.g. mapping of From, To, Cseq and Call-ID headers from one side of the B2BUA to the other.

31. SIP ACK request (DTF to intermediate IM CN subsystem entities)

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

There is no VCC specific content to this response.

32. 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 VCC specific content to this response.

A.4.5 Signalling flows for origination from CS domain with no anchoring

Figure A.4.5-1 shows the origination of a voice call that is capable of being subject to VCC, with the anchoring of the call in the IM CN subsystem being denied prior to its routeing. The voice call is then continued in the CS domain according to standard procedures.

The anchor decision of such origination calls is subject to operator policy.

As the originating voice call is not anchored in the IM CN subsystem, domain transfer will not be supported for that call.

Figure A.4.5-1: call origination from CS with no anchoring

The details of the signalling flows are as follows:

Steps 1 to 4 are identical to the example in subclause A.4.3.

NOTE 1: When processing the originating calls for subscriber requiring CAMEL support (step 3), the VMSC retrieves the originating CAMEL subscriber information from the VLR that identifies the subscriber as having CAMEL services. As a result the gsmSSF of the VMSC triggers a CAMEL activity toward the gsmSCF.

5. Anchor decision

The CAMEL service function denies the anchoring of the originating call according to the operator policy. In this example the called party number is not in the international format and the home IM CN subsystem has no means to translate the called party number into a proper routable format.

6. CAMEL CONTINUE (gsmSCF to VMSC)

The CAMEL service function causes the gsmSCF to respond to the CAMEL IDP message with a CAMEL CONTINUE message. The CAMEL CONTINUE message contains no parameter.

NOTE 2: On the receipt of the CAMEL CONTINUE message, the VMSC resumes the processing, continues the call in the CS domain according to standard procedures and without any modification of the call parameters.

A.4.6 Signalling flows for origination from CS domain for a user that is not registered within the IM CN subsystem

Figure A.4.6-1 shows the origination of a call in the CS domain that is capable of being subject to VCC when the user is not currently registered within the IM CN subsystem.

Figure A.4.6-1: CS call origination from the VCC user that is not IMS registered

The details of the signalling flows are as follows:

Steps 1 through 14 are identical to those shown in subclause A.4.3.

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

In this example, the VCC user is not registered in the IM CN subsystem. The DTF forwards the SIP INVITE request to the intermediate IM CN subsystem entities, specifically the I-CSCF as for AS originating procedures for unregistered users. The “orig” parameter is added to the Route header.

The DTF sets the value of the Contact header with the address of the DTF that will provide the transfer functionality needed to support VCC.

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

NOTE: The service profile needs to be the same for the originating registered case and the originating unregistered case.

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

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

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

Max-Forwards: 66

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

P-Asserted-Identity:

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

Privacy:

From:

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

Call-ID: dc14b1t10b3teghmlk501444

Cseq:

Supported:

Contact: <sip:dtf1.home1.net>

Allow:

Content-Type:

Content-Length: (…)

v=

o=

s=

c=

t=

m=

b=

a=

a=

a=

a=

a=

a=

a=

a=

Contact header: The Contact header represents the contact of the DTF.

16. SIP 100 (Trying) response (I-CSCF to DTF)

The I-CSCF responds to the DTF with a SIP 100 (Trying) response.

There is no VCC specific content to this response.

17. Intermediate IM CN subsystem processing (selection of S-CSCF)

The intermediate IM CN subsystem entities (I-CSCF) will select a S-CSCF for the unregistered user. The I-CSCF will recognize the “orig” parameter on the Route header and query the HSS for the originating party in P-Asserted-Identity header. The I-CSCF will select a S-CSCF based upon the user capabilities and the capabilities of the S-CSCFs as currently described in 3GPP TS 24.229 [8] subclause 5.3. The I-CSCF forwards the request to the S-CSCF.

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

The intermediate IM CN subsystem entities (S-CSCF) routes 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.6-18: 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 scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP icscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP dtf1.home1.net SIP/2.0/UDP;branch=z9hG4bK312a32.1

Max-Forwards: 64

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: (…)

v=

o=

s=

c=

t=

m=

b=

a=

a=

a=

a=

a=

a=

a=

a=

19. 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 VCC specific content to this response.

20. 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 VCC specific actions associated with this step.

The DTF and CSAF modify the message in accordance with initiating B2BUA functionality, e.g. mapping of From, To, Cseq and Call-ID headers from one side of the B2BUA to the other.

21. 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 VCC specific content to this response.

22. SIP 200 (OK) response (intermediate IM CN subsystem entities to DTF)

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

There is no VCC specific content to this response.

23. Interaction between DTF and CSAF

Information is exchanged between the CSAF and the DTF. The nature of this signalling is outside the scope of this version of the specification.

The DTF and CSAF modify the message in accordance with initiating B2BUA functionality, e.g. mapping of From, To, Cseq and Call-ID headers from one side of the B2BUA to the other.

24. SIP 200 (OK) response (CSAF to intermediate IM CN subsystem entities)

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

There is no VCC specific content to this response.

25. 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 VCC specific content to this response.

26. ISUP ANM (MGCF to VMSC)

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

There is no VCC specific content to this response.

27. CONNECT message (VMSC to VCC UE)

The VMSC sends a CONNECT message to the VCC UE.

There is no VCC specific content to this response.

28. CONNECT ACKNOWLEDGE message (VCC UE to VMSC)

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

There is no VCC specific content to this response.

29. SIP ACK request (MGCF to CSAF)

The MGCF generates a SIP ACK request on receipt of the SIP 200 (OK) response and sends it back to the CSAF.

There is no VCC specific content to this response.

30. H.248 interaction with the MGW

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

31. Interaction between CSAF and DTF

Information is exchanged between the CSAF and the DTF. The nature of this signalling is outside the scope of this version of the specification.

The DTF and CSAF modify the message in accordance with initiating B2BUA functionality, e.g. mapping of From, To, Cseq and Call-ID headers from one side of the B2BUA to the other.

32. SIP ACK request (DTF to intermediate IM CN subsystem entities)

The DTF forwards the SIP ACK request to the intermediate IM CN subsystem entities.

There is no VCC specific content to this response.

33. 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 VCC specific content to this response.