A.1 Normal cases

24.6043GPPCommunication Diversion (CDIV) using IP Multimedia (IM) Core Network (CN) subsystemProtocol specificationRelease 18TS

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

A.1.1 Communication Forwarding unconditional

Figure A.1 shows an example signalling flow for a successful communication forwarding unconditional based on an AS providing the forwarding.

Figure A.1: CFU AS based normal case

User B has activated the CFU service.

User A is sending a communication request towards User B:

1) Initial INVITE request towards User B. – see example in table A.1.1-1.

Table A.1.1-1: INVITE request (UE A to P-CSCF)

INVITE sip:user2_public1@home1.net;gr=2ad8950e-48a5-4a74-8d99-ad76cc7fc74c SIP/2.0

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

Max-Forwards: 70

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

P-Preferred-Identity: "John Doe" <sip:user1_public1@home1.net>

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

Privacy: none

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

To: sip:user2_public1@home1.net;gr=2ad8950e-48a5-4a74-8d99-ad76cc7fc74c

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 127 INVITE

Require: sec-agree

Proxy-Require: sec-agree

Supported: precondition, 100rel, gruu, 199

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

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

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

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

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

Content-Type: application/sdp

Content-Length: (…)

v=0

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

s=-

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

t=0 0

m=video 3400 RTP/AVP 98 99

a=tcap:1 RTP/AVPF

a=pcfg:1 t=1

b=AS:75

a=curr:qos local none

a=curr:qos remote none

a=des:qos mandatory local sendrecv

a=des:qos none remote sendrecv

a=inactive

a=rtpmap:98 H263

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

a=rtpmap:99 MP4V-ES

m=audio 3456 RTP/AVP 97 96

a=tcap:1 RTP/AVPF

a=pcfg:1 t=1

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=inactive

a=rtpmap:97 AMR

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

a=rtpmap:96 telephone-event

2) Initial INVITE request towards User B. The URI-B is subscribed to the CFU service.

3 to 4) Using the IFC the initial INVITE request is forwarded to the AS.

5) Procedures for CFU are executed.

6 to 8) Depending on the value of subscription option “Originating user receives notification that his communication has been diverted (forwarded or deflected)”, a 181 (Call Is Being Forwarded) response is sent towards the User A indicating that the communication is diverted.

9) An initial INVITE request including URI-C as destination is sent back to the S-CSCF. Additional the History-Info header is included. – see example in table A.1.1-9.

Table A.1.1-9: INVITE request (AS to S-CSCF)

INVITE sip:User-C@example.com;cause=302 SIP/2.0

Via: SIP/2.0/UDP as.home1.net;branch=z9hG4bK712z34.1,

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

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

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

P-Asserted-Identity: "John Doe" <sip:user1_public1@home1.net>

Privacy:

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

To: sip:user2_public1@home1.net;gr=2ad8950e-48a5-4a74-8d99-ad76cc7fc74c

Call-ID:

Cseq:

Require:

Proxy-Require:

Supported:

Security-Verify:

Contact:

Allow:

Accept:

Accept-Contact:

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

History-Info: <sip:user2_public1@home1.net;gr=2ad8950e-48a5-4a74-8d99-ad76cc7fc74c; >;index=1,<sip:User-C@example.com;cause=302>;index=1.1;mp=1

Content-Type:

Content-Length:

10) S-CSCF looks up to the HSS to identify the location of User-C.

11 to 12) The communication is routed towards User-C.

13 to 18) The 200 (OK) response is sent back to the User-A.

19 to 24) The ACK request is send back to User-B.

25) RTP media is established.

A.1.2 Communication Deflection

Figures A.2a and A.2b describe the Immediate CD feature the only difference compared to a regular CD is that in the regular CD case the "302 (Moved Temporarily) Moved Temporarily" is preceded by a "180 (Ringing) Ringing".

Figure A.2a

Figure A.2b

User B has activated the CD service.

User A is sending a communication request towards User B:

1 to 2) Initial INVITE request towards User B. The URI-B is subscribed to the CD service. – see example in table A.1.1-1

2a to 3) Using IFC the initial INVITE request is forwarded to the AS.

4 to 7) The initial INVITE request is forwarded to User B due to normal communication procedures.

8 to 10) A 302 (Moved Temporarily) response with a contact header including the URI of the forwarded to user is sent back to the AS.

11) The CD logic is executed.

12 to 14) Depending on the value of subscription option "Originating user receives notification that his communication has been diverted (forwarded or deflected)", a 181 (Call Is Being Forwarded) response is sent towards the User A indicating that the communication is diverted.

15) An initial INVITE request including URI-C as destination is sent back to the S-CSCF. Additional the History-Info header field is included. – see example in table A.1.2-15.

Table A.1.2-15: INVITE request (AS to S-CSCF)

INVITE sip:User-C@example.com;cause=480 SIP/2.0

Via: SIP/2.0/UDP as.home1.net;branch=z9hG4bK712z34.1,

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

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

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

P-Asserted-Identity: "John Doe" <sip:user1_public1@home1.net>

P-Access-Network-Info:

Privacy:

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

To: sip:user2_public1@home1.net;gr=2ad8950e-48a5-4a74-8d99-ad76cc7fc74c

Call-ID:

Cseq:

Require:

Proxy-Require:

Supported:

Security-Verify:

Contact:

Allow:

Accept:

Accept-Contact:

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

History-Info: <sip:user2_public1@home1.net;gr=2ad8950e-48a5-4a74-8d99-ad76cc7fc74c?Reason=sip%3Bcause=302>;index=1,<sip:User-C@example.com;cause=480>;index=1.1;mp=1

Content-Type:

Content-Length:

16 to 18) An initial INVITE request including URI-C as destination is routed to UE C.

19 to 24) A 180 (Ringing) response is sent back to the originating user including a History-Info header field as shown above. If no restriction is given the diverted to user will be presented at the UE of user A.

25 to 30) The 200 (OK) response is sent back to the User-A.

31 to 36) The ACK request is sent back to User-B.

37) RTP media is established.

A.1.3 Communication forwarding on no reply

Figures A.3a and A.3b shows an example signalling flow for a successful communication forwarding on no reply based on an AS providing the forwarding as described in bullet 2) of the subclause 4.5.2.6.3.

Figure A.3a

Figure A.3b

User B has activated the CFNR service.

User A is sending a communication request towards User B:

1 to 2) Initial INVITE request towards User B. The URI-B is subscribed to the CFU service. – see example in table A.1.1-1

3) Using the IFC the initial INVITE request is forwarded to the AS.

4) The initial INVITE request is forwarded to User B due to normal communication procedures.

5 to 6) The initial INVITE request is forwarded to User B due to normal communication procedures.

7 to 9) A 180 (Ringing) response is sent back to the AS indicating that the terminating UE is ringing.

10) The no-reply timer in the AS is started.

11 to 13) The previous 180 (Ringing) response is sent towards the originating user indicating that the terminating UE is ringing.

14) The timer expires.

15 to 17) In this case, the option to not continue ringing the forwarding user applies, therefore to release the communication to User B the AS sends a CANCEL request

18 to 20) The 200 (OK) response for the CANCEL request is sent back to the AS.

21 to 23) Depending on the value of subscription option "Originating user receives notification that his communication has been diverted (forwarded or deflected)", a 181 (Call Is Being Forwarded) response is sent towards the User A indicating that the communication is diverted.

24 to 26) A 487 (Request Terminated) response with a ACK request finalize the termination of the dialog between AS and UE:B.

27 to 29) The ACK for the 487 (Request Terminated) response is sent back to User-B.

30) An initial INVITE request including URI-C as destination is sent back to the S-CSCF. Additional the History-Info header is included. – see example in table A.1.3-28.

Table A.1.3-28: INVITE request (AS to S-CSCF)

INVITE sip:User-C@example.com;target=sip:user2_public1@home1.net%3bgr%362ad8950e-48a5-4a74-8d99-ad76cc7fc74;cause 408 SIP/2.0

Via: SIP/2.0/UDP as.home1.net;branch=z9hG4bK712z34.1,

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

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

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

P-Asserted-Identity: "John Doe" <sip:user1_public1@home1.net>

P-Access-Network-Info:

Privacy:

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

To: sip:user2_public1@home1.net;gr=2ad8950e-48a5-4a74-8d99-ad76cc7fc74c

Call-ID:

Cseq:

Require:

Proxy-Require:

Supported:

Security-Verify:

Contact:

Allow:

Accept:

Accept-Contact:

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

History-Info: <sip:user2_public1@home1.net;gr=2ad8950e-48a5-4a74-8d99-ad76cc7fc74c;>;index=1,<sip:User-C@example.com;target=sip:user2_public1@home1.net%3bgr%362ad8950e-48a5-4a74-8d99-ad76cc7fc74;cause=408>;index=1.1;mp=1

Content-Type:

Content-Length:

32 to 34) An initial INVITE request including URI-C as destination is routed to UE C.

34 to 19) A 180 (Ringing) response is sent back to the originating user including a History-Info header as shown above. If no restriction is given the diverted to user will be presented at the UE of User A.

40 to 45) The 200 (OK) response from User-C is sent back to the User-A.

46 to 51) The ACK request is sent back to User-C.

52) RTP media is established.

A.1.4 Communication Forwarding on Busy

Figures A.4a and A.4b shows an example signalling flow for a successful communication forwarding on busy based on an AS providing the forwarding.

Figure A.4a

Figure A.4b

A.1.5 Communication Forwarding Not Logged-in (CFNL)

Figures A.5 shows an example signalling flow for a successful communication forwarding on not logged-in based on an AS providing the forwarding.

Figure A.5

A.1.6 Void

A.1.7 Service configuration

Figure A.7: Service configuration example

1. HTTP GET request (UE to AP) – see example in table A.1.7-1

The UE wants to retrieve the supported conditions and actions for communication diversion from the AS.

Table A.1.7-1: HTTP GET request (UE to AP)

GET /simservs.ngn.etsi.org/users/sip:user1@home1.net/simservs.xml/~~/simservs/communication-diversion-serv-cap HTTP/1.1

Host: xcap.mnc012.mcc345.ipxuni.3gppnetwork.org

Date: Thu, 16 Jun 2011 10:50:33 GMT

X-3GPP-Intended-Identity: "sip:user1@home1.net"

2. HTTP 401 (Unathorized) response (AP to UE) – see example in table A.1.7-2

Upon receiving an unauthorized HTTP GET request the AP authenticates the UE.

Table A.1.7-2: HTTP 401 (Unathorized) request (AP to UE)

HTTP/1.1 401 Unauthorized

Date: Thu, 16 Jun 2011 10:50:34 GMT

WWW-Authenticate: Digest realm="xcap.mnc012.mcc345.ipxuni.3gppnetwork.org", nonce="47364c23432d2e131a5fb210812c", qop=auth-int

Content-Length: 0

3. HTTP GET request (UE to AP) – see example in table A.1.7-3

The UE repeats the HTTP GET request including the Authorization header.

Table A.1.7-3: HTTP GET request (UE to AP)

GET /simservs.ngn.etsi.org/users/sip:user1@home1.net/simservs.xml/~~/simservs/communication-diversion-serv-cap HTTP/1.1

Host: xcap.mnc012.mcc345.ipxuni.3gppnetwork.org

Date: Thu, 16 Jun 2011 10:50:36 GMT

Authorization: Digest realm="xcap.mnc012.mcc345.ipxuni.3gppnetwork.org", nonce="47364c23432d2e131a5fb210812c", username="sip:user1@home1.net", qop=auth-int,
uri="/simservs.ngn.etsi.org/users/sip:user1@home1.net/simservs.xml/~~/simservs/communication-diversion-serv-cap", response="2c8ee200cec7f6e966c932a9242554e4", cnonce="dcd99agsfgfsa8b7102dd2f0e8b1", nc=00000001

X-3GPP-Intended-Identity: "sip:user1@home1.net"

4. HTTP GET request (AP to AS) – see example in table A.1.7-4

The AP forwards the HTTP GET request to the AS.

Table A.1.7-4: HTTP GET request (AP to AS)

GET /simservs.ngn.etsi.org/users/sip:user1@home1.net/simservs.xml/~~/simservs/communication-diversion-serv-cap HTTP/1.1

Host: xcap.mnc012.mcc345.ipxuni.3gppnetwork.org

Via: HTTP/1.1 ap.home1.net

Date: Thu, 16 Jun 2011 10:50:38 GMT

X-3GPP-Asserted-Identity: "sip:user1@home1.net"

5. HTTP 200 (OK) response (AS to AP) – see example in table A.1.7-5

The AS returns the supported conditions and actions for communication diversion.

The <serv-cap-media> child element of the <serv-cap-conditions> element describes that audio and video media are allowed to be used as Communication Diversion rule conditions. The other child elements of the <serv-cap-conditions> element list the conditions that are not provisioned for the user. If a service capability for a condition is not listed from the list of conditions specified in subclause 4.9.1.3 then the condition is provisioned for the user. The following conditions are provisioned: busy, not-registered, no-answer, not-reachable.

The <serv-cap-target> child element of the <serv-cap-actions> element describes that the target needs to correspond to a telephone number. The other child elements of the <serv-cap-actions> element list the actions that are not provisioned for the user. If a service capability for an action is not listed from the list of actions specified in subclause 4.9.1.4 then the action is provisioned for the user. In this example, there are no other actions provisioned.

Table A.1.7-5: HTTP 200 (OK) response (AS to AP)

HTTP/1.1 200 OK

Date: Thu, 16 Jun 2011 10:50:40 GMT

Etag: "eti87"

Content-Type: application/xcap-el+xml; charset="utf-8"

Content-Length: (…)

<communication-diversion-serv-cap active="true">

<serv-cap-conditions>

<serv-cap-anonymous provisioned="false"></serv-cap-anonymous>

<serv-cap-external-list provisioned="false"></serv-cap-external-list>

<serv-cap-identity provisioned="false"></serv-cap-identity>

<serv-cap-media>

<media>audio</media>

<media>video</media>

</serv-cap-media>

<serv-cap-presence-status provisioned="false"></serv-cap-presence-status>

<serv-cap-rule-deactivated provisioned="false"></serv-cap-rule-deactivated>

<serv-cap-validity provisioned="false"></serv-cap-validity>

</serv-cap-conditions>

<serv-cap-actions>

<serv-cap-target>

<telephony-type/>

</serv-cap-target>

<serv-cap-notify-caller provisioned="false">

</serv-cap-notify-caller>

<serv-cap-notify-served-user provisioned="false">

</serv-cap-notify-served-user>

<serv-cap-notify-served-user-on-outbound-call provisioned="false">

</serv-cap-notify-served-user-on-outbound-call>

<serv-cap-reveal-identity-to-caller provisioned="false">

</serv-cap-cap-reveal-identity-to-caller>

<serv-cap-reveal-served-user-identity-to-caller provisioned="false">

</serv-cap-reveal-served-user-identity-to-caller>

<serv-cap-reveal-identity-to-target provisioned="false">

</serv-cap-reveal-identity-to-target>

</serv-cap-actions>

</communication-diversion-serv-cap>

6. HTTP 200 (OK) response (AP to UE) – see example in table A.1.7-6

The AP routes the HTTP 200 (OK) response to the UE.

Table A.1.7-6: HTTP 200 (OK) response (AP to UE)

HTTP/1.1 200 OK

Via: HTTP/1.1 ap.home1.net

Date: Thu, 16 Jun 2011 10:50:42 GMT

Authentication-Info: nextnonce="e966c32a924255e42c8ee20ce7f6"

Etag: "eti87"

Content-Type: application/simservs+xml; charset="utf-8"

Content-Length: (…)

(…)

7. HTTP PUT request (UE to AP) – see example in table A.1.7-7

The UE creates a new rule to activate the CFU service. If a rule with id="rule1" previously existed then the new rule replaces that rule. The rule has an empty <conditions> element.

Table A.1.7-7: HTTP PUT request (UE to AP)

PUT /simservs.ngn.etsi.org/users/sip:user1@home1.net/simservs.xml/~~/simservs/communication-diversion/ruleset/rule%5b@id=%22rule1%22%5d HTTP/1.1

Host: xcap.mnc012.mcc345.ipxuni.3gppnetwork.org

Date: Thu, 16 Jun 2011 10:52:33 GMT

Authorization: Digest realm="xcap.mnc012.mcc345.ipxuni.3gppnetwork.org", nonce="e966c32a924255e42c8ee20ce7f6", username="sip:user1@home1.net", qop=auth-int,
uri="/simservs.ngn.etsi.org/users/sip:user1@home1.net/simservs.xml/~~/simservs/communication-diversion/ruleset", response="adq3283hww88whhjw98822333ddd32", cnonce="wqesatt874873j3gg3kk39944hhhee", nc=00000001

X-3GPP-Intended-Identity: sip:user1@home1.net

Content-Type: application/xcap-el+xml; charset="utf-8"

Content-Length: (…)

<cp:rule id="rule1">

<cp:conditions>

</cp:conditions>

<cp:actions>

<forward-to>

<notify-caller>true</notify-caller>

</forward-to>

</cp:actions>

</cp:rule>

8. HTTP PUT request (AP to AS) – see example in table A.1.7-8

The AP forwards the HTTP PUT request to the AS.

Table A.1.7-8: HTTP PUT request (AP to AS)

PUT /simservs.ngn.etsi.org/users/sip:user1@home1.net/simservs.xml/~~/simservs/communication-diversion/ruleset/rule%5b@id=%22rule1%22%5d HTTP/1.1

Host: xcap.mnc012.mcc345.ipxuni.3gppnetwork.org

Via: HTTP/1.1 ap.home1.net

Date: Thu, 16 Jun 2011 10:52:35 GMT

X-3GPP-Asserted-Identity: sip:user1@home1.net

Content-Type: application/xcap-el+xml; charset="utf-8"

Content-Length: (…)

(…)

9. HTTP 200 (OK) response (AS to AP) – see example in table A.1.7-9

The AS acknowledges the addition of the new CFU rule with a HTTP 200 (OK) response.

Table A.1.7-9: HTTP 200 (OK) response (AS to AP)

HTTP/1.1 200 OK

Date: Thu, 16 Jun 2011 10:52:37 GMT

Etag: "efefefef"

Content-Length: 0

10. HTTP 200 (OK) response (AP to UE) – see example in table A.1.7-10

The AP routes the HTTP 200 (OK) response to the UE.

Table A.1.7-10: 200 (OK) response (AP to UE)

HTTP/1.1 200 OK

Via: HTTP/1.1 ap.home1.net

Date: Thu, 16 Jun 2011 10:52:38 GMT

Authentication-Info: nextnonce="737jkjssj733hjjk3hjk3999ss3kj"

Etag: "efefefef"

Content-Length: 0