A.5.2 Signalling flows for termination to the IM CN subsystem

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

Figure A.5.2-1 shows the termination of a call that is capable of being subject to VCC, where the calling party call has been routed through the IM CN subsystem and where the called party is terminating in its home IM CN subsystem.

Figure A.5.2-1: Terminating call directed to IM CN subsystem

The details of the signalling flows are as follows:

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

In this example the originating UE initiates a voice call through its home IM CN subsystem (home1) with a terminating UE which is VCC capable who is in a different network (home2). There is no specific VCC information in the SIP INVITE request from the originating UE.

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

Table A.5.2-1: SIP INVITE request (from the originating IM CN subsystem)

INVITE sip:user2_public1@home2.net SIP/2.0

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

Max-Forwards: 67

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

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

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

P-Access-Network-Info:

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

Privacy: none

Supported: precondition

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

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

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 127 INVITE

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

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

Content-Type: application/sdp

Content-Length: (…)

v=0

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

s=-

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

t=0 0

m=audio 3456 RTP/AVP 97 96

b=AS:25.4

a=curr:qos local none

a=curr:qos remote none

a=des:qos mandatory local sendrecv

a=des:qos 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

2. Evaluation of initial filter criteria

In this example, and by evaluation of the initial filter criteria, the terminating user’s S-CSCF routes to the address of the DTF, as the received request is a terminating INVITE request.

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

The terminating user’s S-CSCF adds a set of routeing related headers in order to receive the SIP INVITE request back, to route the present request to the DTF and to maintain itself on the route for all subsequent requests.

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

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

INVITE sip:user2_public1@home2.net SIP/2.0

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

Max-Forwards: 66

Route: <sip:dtf2.home2.net;lr>, <sip:scscf2.home2.net;lr>;dia-id=6574839201

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

P-Asserted-Identity:

P-Access-Network-Info:

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

orig-ioi="type 3ashome1.net"

Privacy:

Supported:

From:

To:

Call-ID:

Cseq:

Contact:

Allow:

Content-Type:

Content-Length: (…)

v=

o=

s=

c=

t=

m=

b=

a=

a=

a=

a=

a=

a=

a=

a=

4. Session anchoring

The DTF decides to perform session anchoring decision based on operator specified criteria.

5. Interaction between the DTF and DSF

Information is exchanged between the DTF and DSF. The nature of this signalling is outside the scope of this version of the specification. Alternative procedures for invoking the DSF are possible, for example, further evaluation of filter criteria when the outgoing request from the DTF after anchoring is sent back to the S-CSCF.

6. The DSF selects the terminating domain

The DSF performs domain selection based on operator and user preferences, registration and call states; in this example the DSF selects the terminating IM CN subsystem to terminate the voice call.

7. Interaction between the DTF and DSF

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

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

The DTF acts as a routeing B2BUA, it initiates the outgoing request and places the called party number in the Request-URI and the To header.

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.

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

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

INVITE sip:user2_public1@home2.net SIP/2.0

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

Max-Forwards: 65

Route: <sip:scscf2.home2.net;lr>;dia-id=6574839201

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

P-Asserted-Identity:

P-Access-Network-Info:

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

Privacy:

Supported:

From:

To:

Call-ID:

Cseq:

Contact:

Allow:

Content-Type:

Content-Length: (…)

v=

o=

s=

c=

t=

m=

b=

a=

a=

a=

a=

a=

a=

a=

a=

No more triggering is required in the initial filter criteria, the IM CN subsystem will route the SIP INVITE request to the terminating user based on its SIP-URI. The SIP AS that implements the DSF or the combination of the DTF and DSF acting as a B2BUA – which performs the third-party call control – needs to be the last located application server to ensure that all application servers that need to remain in the path of a call after domain transfer will do so.

9. SIP INVITE (intermediate IM CN subsystem entities to VCC UE) – see example in table A.5.2-10

The terminating user’s intermediate IM CN subsystem entities forward the SIP INVITE request towards the terminating VCC UE.

Table A.5.2-10: SIP INVITE request (intermediate IM CN subsystem entities to VCC UE)

INVITE sip:[5555::eee:fff:aaa:bbb]:8805;comp=sigcomp SIP/2.0

Via: SIP/2.0/UDP pcscf2.home2.net:5088;comp=sigcomp;branch=z9hG4bK876t12.1, SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK764z87.1, SIP/2.0/UDP sip:dtf2.home2.net; branch=z9jG4bK332b23.3, SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP icscf2_s.home2.net;branch=z9hG4bK871y12.1, SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.home1.net;branch=z9hG4bK431h23.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Max-Forwards: 63

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

P-Asserted-Identity:

Privacy:

Supported:

From:

To:

Call-ID:

Cseq:

Require:

Supported:

Contact:

Allow:

P-Called-Party-ID:

P-Media-Authorization:

Content-Type:

Content-Length:

v=

o=

s=

c=

t=

m=

b=

a=

a=

a=

a=

a=

a=

a=

a=

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

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

There is no VCC specific content to this response.

11, 12, 13 and 14. Reliable exchange of SDP (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.

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

When the called party answers, the UE sends a SIP 200 (OK) final response to the SIP INVITE request (8) to the intermediate IM CN subsystem entities, and starts the media flow(s) for this session.

There is no VCC specific content to this response.

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

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

The DTF sends the SIP 200 (OK) response back 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 response.

18. SIP 200 (OK) response (to originating IM CN subsystem)

The terminating user’s intermediate IM CN subsystem entities, forwards the SIP 200 (OK) final response along the signalling path back to the calling user through the originating IM CN subsystem.

There is no VCC specific content to this response.

19. SIP ACK request (from the originating IM CN subsystem)

The calling user responds to the SIP 200 (OK) final response with an ACK request through the originating IM CN subsystem to the intermediate IM CN subsystem entities of the terminating user.

There is no VCC specific content to this request.

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

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

The DTF sends the SIP ACK request back 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.

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

The intermediate IM CN subsystem entities forward the SIP ACK request to the terminating VCC UE.

There is no VCC specific content to this request.