A.5.7 Signalling flow for termination directed to CS domain, unsuccessful delivery, redirect to IM CN Subsystem

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

Figure A.5.7-1 illustrates an example signalling flow of a voice call to a VCC UE coming in through the CS domain. Upon being anchored in the IM CN subsystem the decision on domain selection resulted in the CS domain being the selected domain for call delivery. However, the terminating call cannot be completed and in this example flow the domain selection function of the VCC application is consulted again. The IM CN subsystem is subsequently selected to complete the terminating call.

In this example, the terminating UE is in his/her HPLMN.

In this example, this PLMN does not utilise terminating CAMEL service logic. Rather this example illustrates HSS(HLR) directed call diversion to the IM CN subsystem where the HSS(HLR), through internal network implementation, can obtain the IMRN

In this example, the failure to complete the terminating call establishment is due to the VMSC having initiated the paging procedure fails to get a respond from the UE in the course of normal and extended paging.

In this example, when the MSC fails to complete the terminating call establishment, the MSC returns the ISUP RELEASE message with an appropriate cause value to the MGCF that will allow the MGCF to map to an appropriate SIP method and indication that indicates that the user is currently not reachable.

In this example, when the VCC Application receives the indication that delivery of the terminating call through the selected CS domain cannot be completed, the VCC application performs an implementation option to attempt delivery of the terminating call through the IM CN Subsystem. This implementation option further interacts with operator dependent policies.

Figure A.5.7-1: Terminating call coming in through CS domain, CS domain selected for call delivery, call delivery unsuccessful, domain for call delivery reselected

Figure A.5.7-1: Terminating call coming in through CS domain, CS domain selected for call delivery, call delivery unsuccessful, domain for call delivery reselected (continued)

The details of the signalling flows are as follows:

1. ISUP IAM (coming into this PLMN through the CS domain)

A call request makes an entry into this PLMN. First entry point is the GMSC. This ISUP IAM contains the MSISDN of the called party.

In this example the MSISDN is +1-212-123-2222.

2. MAP SEND_ROUTING_INFORMATION (GMSC to HSS/HLR)

GMSC makes a query to the HSS/HLR for routeing information for onward routeing of the incoming call request. This GMSC query SEND_ROUTING_INFORMATION contains the MSISDN of the called party.

3. Derivation of IMRN

Internal network actions – not indicated here as those actions are implementation and network dependent – are taken. The result is that (for this example) a decision is make to route the call further onwards into the IM CN subsystem.

In particular an IMRN is obtained in these internal network actions.

For this example the derived IMRN is +1-241-555-3333.

NOTE 1: It is an implementation and network option whether the derivation of the IMRN takes in the decision to anchor the call to the DTF.

4. MAP SEND_ROUTING_INFORMATION_RESULT (HSS/HLR to GMSC)

The HSS/HLR replies to the query by GMSC with the SEND_ROUTING_INFORMATION_RESULT providing with it the IMRN

5. ISUP IAM (GMSC to MGCFa)

GMSC sends out IAM (IMRN). The IMRN is that which will direct the routeing of the IAM to the MGCF. In this example, the IAM (IMRN = +1-241-555-3333) is routed to MGCFa.

6. SIP INVITE (MGCFa towards the CSAF through the intermediate IM CN subsystem) – see example in table A.5.7-6

The MGCF interworks the IAM (IMRN) into the appropriate SIP message and initiates the SIP INVITE towards the CSAF via the intermediate IM CN subsystem entities.

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

Table A.5.7-6: INVITE request

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

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

7. H.248 interaction with the MGW

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

8. SIP 100 (Trying) response (Intermediate IM CN subsystem entities to MGCFa)

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

There is no VCC specific content to this request.

9. SIP INVITE request (intermediate IM CN subsystem entities to the CSAF) – see example in table A.5.7-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.5.7-9: SIP INVITE request (intermediate IM CN subsystem entities to the CSAF)

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

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

Max-Forwards: 69

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

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

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

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

11. Retrieval of the called party details from IMRN

From the IMRN the CSAF retrieves the called party details. This retrieval process is implementation dependent.

NOTE 2: It is a further implementation dependent option whether the decision to anchor the call such that VCC feature can be made available to the called party is made at this step.

12. Interaction between CSAF and DTF

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

13. Anchoring

The DTF performs the anchoring of the session.

14. Interaction between the DTF and DSF

In this example, information is exchanged between the DTF and DSF. The nature of this signalling is outside the scope of this version of the specification.

15. Domain selection

A decision has now to be made on which domain the terminating call is to be delivered. This decision is implementation specific.

For this example, the decision is to deliver the terminating call through the CS domain.

16. Derivation of the CSRN

Having made the decision of delivering the call (for this example) in the CS domain, the DSF derives the CSRN. The CSRN will allow the call to be routed further into the CS domain. The derivation of the CSRN is implementation specific.

For this example, the CSRN = +1-241-555-4444

17. Interaction between the DTF and DSF

In this example, information is exchanged between the DTF and DSF. The nature of this signalling is outside the scope of this version of the specification.

18. SIP INVITE (DTF towards the MGCFb through the intermediate IM CN subsystem entities) – see example in table A.5.7-14

Having derived the CSRN, the DTF now acts a B2BUA and initiates an INVITE with the CSRN as the request URI, and sends it 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.

Table A.5.7-14: INVITE request

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

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

Max-Forwards: 68

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

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:dtf2.home2.net>

Allow:

Content-Type:

Content-Length: (…)

v=

o=

s=

c=

t=

m=

b=

a=

a=

a=

a=

a=

a=

a=

a=

19. Evaluation of initial Filter Criteria

In this example there are no further matches of Service Point Triggers that cause further routeing to other Application Server.

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

21. SIP INVITE request (intermediate IM CN subsystem entities to MGCFb)

The intermediate IM CN subsystem entities deliver the SIP INVITE request to the MGCF. In this example this is a different MCGF than the MGCF which receives the ISUP IAM carrying the IMRN. In this example the SIP INVITE request with the CSRN is directed to MGCFb.

This example flow involving different MGCF further illustrates a pragmatic example of call distribution to different MGCFs of one network.

22. SIP 100 (Trying) response (MGCFb to intermediate IM CN subsystem entities)

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

There is no VCC specific content to this response.

23. ISUP IAM (MGCFb to VMSC)

The MGCF interworks the SIP INVITE request to the ISUP and initiates the ISUP IAM carrying the CSRN towards the VMSC.

24. H.248 interaction with the MGW

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

25. Retrieval of the called party details from CSRN

The VMSC can from the CSRN retrieve the details of the called party and with that initiates a paging procedure towards the terminating UE.

26. ISUP ACM (VMSC to MGCFb)

With the determination that the address is complete and that the terminating UE details are valid the VMSC returns to the MGCF the ISUP ACM message. There is no VCC specific content in this message.

27a -f. Propagation of indication of address complete back to calling side

The SIP endpoints complete SDP offer/answer procedures, and any exchange of alerting indication, in accordance with standard basic call procedures. VCC imposes no restriction on this operation.

MGCFa then sends the ISUP ACM back to the originating side through the GMSC.

28. VMSC concludes that terminating call attempt has failed

MSC conclude that paging procedure has failed when mobile did not respond to normal or extended paging.

29. ISUP REL (VMSC to MGCFb)

VMSC concluding that terminating call is unsuccessful, provides a ISUP REL to the MGCFb. The ISUP REL will carry the reason for release indicating that the terminating call attempt is unsuccessful.

30. H.248 interaction for bearer release

MGCFb interacts with MGWb to release the allocated resources which will now not be needed.

31. ISUP RLC COM (MGCFb to VMSC)

MGCFb having interacted with MGWb to release the resources return ISUP RLC COM to indicate that the MGCFb has now completed its release.

32. SIP 4xx (MGCFb towards DTF through the intermediate IM CN subsystem entities)

MGCFb indicate the release back towards the originator – in this case the DTF. This the MGCFb does by interworking the ISUP message to a SIP 4xx response sent to the intermediate IM CN subsystem entities.

33. SIP 4xx (Intermediate IM CN subsystem to DTF)

The SIP 4xx is forwarded to the VCC application by the intermediate IM CN subsystem entities.

34. Interaction between the DTF and DSF

In this example, information is exchanged between the DTF and DSF. The nature of this signalling is outside the scope of this version of the specification.

35. DSF determines next cause of action

In this example, the DSF decides to re-attempt delivery of the terminating call in the IM CN subsystem. This implementation option is further driven by an operator policy that will influence the decision of whether to re-attempt delivering the terminating call and limit the number of re-attempts to guard against unnecessary and endless looping.

36. Interaction between the DTF and DSF

In this example, information is exchanged between the DTF and DSF. The nature of this signalling is outside the scope of this version of the specification.

37. SIP INVITE request (DTF to terminating UE through the intermediate IM CN subsystem entities) – see example in table A.5.7-37

The DTF sends the SIP INVITE request to the intermediate IM CN subsystem entities serving the terminating user within the IM CN subsystem.

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 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 sets the value of the Route header with SIP URI of S-CSCF including the original dialog identifier.

In the case where the Request-URI of the SIP INVITE request contains a tel-URL, the S-CSCF (next hop) will have to translate to a globally routeable SIP-URI before applying it as Request-URI of the outgoing SIP INVITE request toward the terminating user.

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

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

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

Max-Forwards: 70

Route: <sip:o-id@s-cscf.home1.net;lr>

Record-Route: <sip:dtf2.home2.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

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

38. Evaluation of initial filter criteria

The first INVITE request to the terminating UE will be seen by the S-CSCF of the terminating UE as a new session.

NOTE 3: As part of its filter criteria, care is now taken that this SIP INVITE request will not be routed back to the DTF for anchoring decision. Thus the S-CSCF can know that this SIP INVITE request must not be sent back to the DTF thanks to the original dialog identifier that has been newly included in the request.

39. 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 in this response.

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

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

Table A.5.7-34: 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 pcscf1.home1.net:5088;comp=sigcomp;branch=z9hG4bK876t12.1,
SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK764z87.1,
SIP/2.0/UDP sip:dtf2.home2.net; branch=z9jG4bK332b23.3

Max-Forwards: 68

Route:

Record-Route: < pcscf1.home1.net>, < scscf1.home1.net>, <sip:dtf2.home2.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

41. Signalling flows completing SIP call to terminating UE and interworked back to originating side

The signalling flows here on till the completion of the call and utilisation of the media resources are in accordance with step 21 through to step 33 of subclause A.5.4, and Figure A.5.4-1.