A.4.3 User getting invited to a conference

24.1473GPPConferencing using the IP Multimedia (IM) Core Network (CN) subsystemRelease 17Stage 3TS

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

A.4.3.1 MRFC/AS is not located in user’s home network

A.4.3.1.1 Conference Participant referring another user to a conference

Figure A.4.3.1.1-1 shows how UE#1 refers UE#2 to a conference. UE#1 has created a conference by using the mechanisms described in subclause 6.2, and UE#1 has learned the conference URI that identifies this conference.

Figure A.4.3.1.1-1: User inviting another user to a conference by
sending a REFER request to the other user

The details of the flows are as follows:

1. UE#1 creates a conference

UE#1 creates a conference as described in subclause 6.3.2. Once the conference creation is accomplished, UE#1 has learned the conference URI allocated for this conference.

2. REFER request (UE to P-CSCF) – see example in table A.4.3.1.1-2

A UE has created a conference and learned the conference URI. Now the UE wants to invite another UE to that conference.

Table A.4.3.1.1-2: REFER request (UE to P-CSCF)

REFER sip:user2_public1@home2.net 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:orig@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@home2.net>

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 127 REFER

Require: sec-agree

Refer-To: <sip:conference1@mrfc1.home1.net;method=INVITE>

Referred-By: <sip:user1_public1@home1.net>

Proxy-Require: sec-agree

Supported: gruu

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>

Content-Length: 0

Request-URI: contains the public user identity of UE#2.

Via: contains the IP address or FQDN of the originating UE.

Refer-To: contains the conference URI as learned during the conference establishment. Additionally the "method" uri parameter indicates that the other user is requested to send an INVITE request to this conference URI.

Referred-By: contains the public user identity of the referring user, as in this example the referring user has decided to indicate its own identity to the referred user.

3. REFER request (P-CSCF to S-CSCF) – see example in table A.4.3.1.1-3

The P-CSCF forwards the REFER request to the S-CSCF.

Table A.4.3.1.1-3: REFER request (P-CSCF to S-CSCF)

REFER sip:user2_public1@home2.net SIP/2.0

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

Max-Forwards: 69

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

Record-Route: <sip:pcscf1.visited1.net;lr>

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

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

P-Access-Network-Info:

Privacy:

From:

To:

Call-ID:

Cseq:

Refer-To:

Referred-By:

Supported:

Contact:

Content-Length:

4. Evaluation of initial Filter Criteria

The S-CSCF validates the service profile of this subscriber and evaluates the initial filter criteria.

5. REFER request (S-CSCF to I-CSCF in UE#2 home network) – see example in table A.4.3.1.1-5

The S-CSCF performs an analysis of the destination address, and determines the network operator to whom the destination subscriber belongs. Since the originating operator does not desire to keep their internal configuration hidden, the S-CSCF forwards the REFER request directly to the destination network.

Table A.4.3.1.1-5: REFER request (S-CSCF to I-CSCF)

REFER sip:user2_public1@home2.net SIP/2.0

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

Max-Forwards: 68

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

P-Asserted-Identity: "John Doe" <sip:user1_public1@home1.net>, <tel:+358-50-4821437>

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

Privacy:

From:

To:

Call-ID:

Cseq:

Refer-To:

Referred-By:

Supported:

Contact:

Content-Length:

6. REFER request (I-CSCF towards S-CSCF of UE#2) – see example in table A.4.3.1.1-6

The I-CSCF performs a Cx location query to the HSS (not shown in this flow) to find out the S-CSCF of UE#2.

The I-CSCF then forwards the REFER request to that S-CSCF that will handle the session termination.

Table A.4.3.1.1-6: REFER request (I-CSCF towards S-CSCF of UE#2)

REFER sip:user2_public1@home2.net SIP/2.0

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

Max-Forwards: 67

Route: <sip:scscf2.home2.net;lr>

Record-Route:

P-Asserted-Identity:

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

Privacy:

From:

To:

Call-ID:

Cseq:

Refer-To:

Referred-By:

Supported:

Contact:

Content-Length:

7. 200 (OK) response to REFER (S-CSCF of UE#2 to I-CSCF) – see example in table A.4.3.1.1-7

UE#2 home network indicates that it has received the REFER request by sending a 200 (OK) response. This means that UE#2 home network has begun to process the request. This does not mean, however, that the referred-to resource would have been contacted.

Table A.4.3.1.1-7: 200 (OK) response to REFER (S-CSCF of UE#2 to I-CSCF)

SIP/2.0 200 OK

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

P-Asserted-Identity: "John Smith" <sip:user2_public1@home2.net>, <tel:+1-212-555-2222>

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=123551024"; icid-generated-at=[5555::f5f:e4e:d3d:c2c]; orig-ioi=home1.net; term-ioi=home2.net

P-Charging-Function-Addresses: ccf=[5555::b99:c88:d77:e66]; ccf=[5555::a55:b44:c33:d22]; ecf=[5555::1ff:2ee:3dd:4cc]; ecf=[5555::6aa:7bb:8cc:9dd]

Privacy:none

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

To: <sip:user2_public1@home2.net>;tag=151170

Call-ID: cb03a0s09a2sdfglkj490333

CSeq: 127 REFER

Contact:user2_public1@home2.net;gr=urn:uuid:2ad8950e-48a5-4a74-8d99-ad76cc7fc74;comp=sigcomp>

Content-Length:0

8. 200 (OK) response to REFER (I-CSCF to S-CSCF) – see example in table A.4.3.1.1-8

The I-CSCF forwards the response to the S-CSCF.

Table A.4.3.1.1-8: 200 (OK) response to REFER (I-CSCF to S-CSCF)

SIP/2.0 200 OK

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

Record-Route:

P-Asserted-Identity:

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

Privacy:

From:

To:

Call-ID:

CSeq:

Contact:

Content-Length:

9. 200 (OK) response (S-CSCF to P-CSCF) – see example in table A.4.3.1.1-9

The S-CSCF forwards the response to the P-CSCF.

Table A.4.3.1.1-9: 200 (OK) response (S-CSCF to P-CSCF)

SIP/2.0 200 OK

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

Record-Route:

P-Asserted-Identity:

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

Privacy:

From:

To:

Call-ID:

CSeq:

Contact:

Content-Length:

10. 200 (OK) response to REFER (P-CSCF to UE#1) – see example in table A.4.3.1.1-10

The P-CSCF forwards the response to the UE.

Table 6.3.3.1-10: 200 (OK) response to REFER (P-CSCF to UE#1)

SIP/2.0 200 OK

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

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

P-Asserted-Identity:

Privacy:

From:

To:

Call-ID:

CSeq:

Contact:

Content-Length:0

11. NOTIFY request (from S-CSCF of UE#2 to S-CSCF) – see example in table A.4.3.1.1-11

S-SCSF receives a NOTIFY request corresponding the REFER request. The NOTIFY request contains information about the progress of the REFER request processing. The body of the NOTIFY request contains a fragment of the response as received by the notifying UE for the request that was initiated due to the REFER request. The NOTIFY request is forwarded to the P-CSCF.

Table A.4.3.1.1-11: NOTIFY request (from S-CSCF of UE#2 to S-CSCF)

NOTIFY sip:user1_public1@home1.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 ;comp=sigcomp SIP/2.0

Via: SIP/2.0/UDP scscf2.home2.net;branch= z9hG4bK764z87.1, SIP/2.0/UDP pcscf2.visited2.net;branch=z9hG4bK234223.1, SIP/2.0/UDP [5555::eee:fff:aaa:bbb]:8805;comp=sigcomp;branch=z9hG4bK23dh42.1

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

Max-Forwards: 68

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

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

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

From: <sip:user2_public1@home2.net>;tag=151170

Call-ID: cb03a0s09a2sdfglkj490333

CSeq: 42 NOTIFY

Subscription-State: active;expires:7200

Event: refer

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

Content-Length: (…)

Content-Type: message/sipfrag

SIP/2.0 100 (Trying) response

12. NOTIFY request (from S-CSCF to P-CSCF) – see example in table A.4.3.1.1-12

The S-CSCF forwards the message to the P-CSCF.

Table: A.4.3.1.1-12: NOTIFY request (from S-CSCF to P-CSCF)

NOTIFY sip:[5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp SIP/2.0

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK23436s.1, SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK764z87.1, SIP/2.0/UDP pcscf2.visited2.net;branch=z9hG4bK234223.1, SIP/2.0/UDP [5555::eee:fff:aaa:bbb]:8805;comp=sigcomp;branch=z9hG4bK23dh42.1

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

P-Charging-Function-Addresses: ccf=[5555::b99:c88:d77:e66]; ccf=[5555::a55:b44:c33:d22]; ecf=[5555::1ff:2ee:3dd:4cc]; ecf=[5555::6aa:7bb:8cc:9dd]

Max-Forwards: 67

Route: <sip:pcscf1.visited1.net;lr>

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

To:

From:

Call-ID:

CSeq:

Subscription-State:

Event:

Contact:

Content-Length: (…)

Content-Type:

(…)

13. NOTIFY request (from P-CSCF to UE#1) – see example in table A.4.3.1.1-13

The P-CSCF forwards the message to UE#1.

Table A.4.3.1.1-13: NOTIFY request (from P-CSCF to UE#1)

NOTIFY sip:[5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp SIP/2.0

Via: SIP/2.0/UDP pcscf1.visited1.net:7531;comp=sigcomp;branch=z9hG4bK23433.1, SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK23436s.1, SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK764z87.1, SIP/2.0/UDP pcscf2.visited2.net;branch=z9hG4bK234223.1, SIP/2.0/UDP [5555::eee:fff:aaa:bbb]:8805;comp=sigcomp;branch=z9hG4bK23dh42.1

Max-Forwards: 66

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

To:

From:

Call-ID:

CSeq:

Subscription-State:

Event:

Contact:

Content-Length: (…)

Content-Type:

(…)

14. 200 (OK) response (UE to P-CSCF) – see example in table A.4.3.1.1-14

The UE acknowledges the NOTIFY request with a 200 (OK) response to the P-CSCF.

Table A.4.3.1.1-14: 200 (OK) response (UE to P-CSCF)

SIP/2.0 200 OK

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

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

From:

To:

Call-ID:

CSeq:

Content-Length: 0

15. 200 (OK) response (P-CSCF to S-CSCF) – see example in table A.4.3.1.1-15

The P-CSCF forwards the 200 (OK) response to the S-CSCF.

Table A.4.3.1.1-15: 200 (OK) response (P-CSCF to S-CSCF)

SIP/2.0 200 OK

Record-Route:

P-Access-Network-Info:

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

From:

To:

Call-ID:

CSeq:

Content-Length: 0

16. 200 (OK) response (S-CSCF to S-CSCF of UE#2) – see example in table A.4.3.1.1-16

The S-CSCF forwards the 200 (OK) response to the S-CSCF of UE#2 according to the information in the Via field.

Table A.4.3.1.1-16: 200 (OK) response (S-CSCF to S-CSCF of UE#2)

SIP/2.0 200 OK

Via: SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK764z87.1, SIP/2.0/UDP pcscf2.visited2.net;branch=z9hG4bK234223.1, SIP/2.0/UDP [5555::eee:fff:aaa:bbb]:8805;comp=sigcomp;branch=z9hG4bK23dh42.1Record-Route:

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

From:

To:

Call-ID:

CSeq:

Content-Length: 0

17. UE#2 joins the conference.

UE#2 joins the conference. The message flows are depicted in subclause 6.3.2.

18. NOTIFY request (from S-CSCF of UE#2 to S-CSCF) – see example in table A.4.3.1.1-18

S-SCSF receives a NOTIFY request corresponding the REFER request.

Table A.4.3.1.1-18: NOTIFY request (from S-CSCF of UE#2 to S-CSCF)

NOTIFY sip:user1_public1@home1.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 ;comp=sigcomp SIP/2.0

Via: SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK23d244.1, SIP/2.0/UDP pcscf2.visited2.net;branch=z9hG4bK234223.1, SIP/2.0/UDP [5555::eee:fff:aaa:bbb]:8805;comp=sigcomp;branch=z9hG4bK23dh42.1

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

Max-Forwards: 68

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

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

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

From: <sip:user2_public1@home2.net>;tag=151170

Call-ID: cb03a0s09a2sdfglkj490333

CSeq: 43 NOTIFY

Subscription-State: terminated

Event: refer

Content-Length: (…)

Content-Type: message/sipfrag

SIP/2.0 200 OK

Subscription–State: indicates that the implicit subscription to the refer event has been terminated.

19. NOTIFY request (from S-CSCF to P-CSCF) – see example in table A.4.3.1.1-19

The S-CSCF forwards the NOTIFY request to the P-CSCF.

Table A.4.3.1.1-19: NOTIFY request (from S-CSCF to P-CSCF)

NOTIFY sip:[5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp SIP/2.0

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK23436s.1, SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK23d244.1, SIP/2.0/UDP pcscf2.visited2.net;branch=z9hG4bK234223.1, SIP/2.0/UDP [5555::eee:fff:aaa:bbb]:8805;comp=sigcomp;branch=z9hG4bK23dh42.1

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

P-Charging-Function-Addresses: ccf=[5555::b99:c88:d77:e66]; ccf=[5555::a55:b44:c33:d22]; ecf=[5555::1ff:2ee:3dd:4cc]; ecf=[5555::6aa:7bb:8cc:9dd]

Max-Forwards: 67

Route: <sip:pcscf1.visited1.net;lr>

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

To:

From:

Call-ID:

CSeq:

Subscription-State:

Event:

Content-Length: (…)

Content-Type:

(…)

20. NOTIFY request (from P-CSCF to UE#1) – see example in table A.4.3.1.1-20

The P-CSCF forwards the NOTIFY request to UE#1.

Table A.4.3.1.1-20: NOTIFY request (from P-CSCF to UE#1)

NOTIFY sip:[5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp SIP/2.0

Via: SIP/2.0/UDP pcscf1.visited1.net:7531;comp=sigcomp;branch=z9hG4bK23433.1, SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK23436s.1, SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK23d244.1, SIP/2.0/UDP pcscf2.visited2.net;branch=z9hG4bK234223.1, SIP/2.0/UDP [5555::eee:fff:aaa:bbb]:8805;comp=sigcomp;branch=z9hG4bK23dh42.1

Max-Forwards: 66

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

To:

From:

Call-ID:

CSeq:

Subscription-State:

Event:

Content-Length: (…)

Content-Type:

(…)

21. 200 (OK) response (UE to P-CSCF) – see example in table A.4.3.1.1-21

The UE acknowledges the NOTIFY request with a 200 (OK) response to the P-CSCF.

Table A.4.3.1.1-21: 200 (OK) response (UE to P-CSCF)

SIP/2.0 200 OK

Via: SIP/2.0/UDP pcscf1.visited1.net:7531;comp=sigcomp;branch=z9hG4bK23433.1, SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK23436s.1, SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK23d244.1, SIP/2.0/UDP pcscf2.visited2.net;branch=z9hG4bK234223.1, SIP/2.0/UDP [5555::eee:fff:aaa:bbb]:8805;comp=sigcomp;branch=z9hG4bK23dh42.1

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

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

From:

To:

Call-ID:

CSeq:

Content-Length: 0

22. 200 (OK) response (P-CSCF to S-CSCF) – see example in table A.4.3.1.1-22

The P-CSCF forwards the 200 (OK) response to the S-CSCF.

Table A.4.3.1.1-22: 200 (OK) response (P-CSCF to S-CSCF)

SIP/2.0 200 OK

Record-Route:

P-Access-Network-Info:

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

From:

To:

Call-ID:

CSeq:

Content-Length: 0

23. 200 (OK) response (S-CSCF to S-CSCF of UE#2) – see example in table A.4.3.1.1-23

The S-CSCF forwards the 200 (OK) response to the home network of UE#2 according to the information in the Via field.

Table A.4.3.1.1-23: 200 (OK) response (S-CSCF to S-SCSF of UE#2)

SIP/2.0 200 OK

Via: SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK23d244.1, SIP/2.0/UDP pcscf2.visited2.net;branch=z9hG4bK234223.1, SIP/2.0/UDP [5555::eee:fff:aaa:bbb]:8805;comp=sigcomp;branch=z9hG4bK23dh42.1

Record-Route:

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

From:

To:

Call-ID:

CSeq:

Content-Length: 0

A.4.3.1.2 User getting referred to a conference by a conference participant

Figure A.4.3.1.2-1 shows how UE#2 gets referred to a conference by receiving a REFER request from a conference participant. The REFER request contains the conference URI where UE#2 should use when joining the conference.

Figure A.4.3.1.2-1: User getting invited to a conference by receiving a REFER request.

The details of the flows are as follows:

1. REFER request (S-CSCF of UE#1 to I-CSCF) – see example in table A.4.3.1.2-1

REFER request is sent by the S-CSCF of UE#1 to UE#2 home network. S-SCSF of UE#1 has resolved the address of I-CSCF as the entry point to UE#2 home network. See subclause 6.3.3.1.1 for originating side of the call flow.

Table A.4.3.1.2-1: REFER request (S-CSCF of UE#1 to I-CSCF)

REFER sip:user2_public1@home2.net SIP/2.0

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

Max-Forwards: 68

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

P-Asserted-Identity: "John Doe" <sip:user1_public1@home1.net>, <tel:+358-50-4821437>

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

Privacy: none

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

To: <sip:user2_public1@home2.net>

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 127 REFER

Refer-To: <sip:conference1@mrfc1.home1.net;method=INVITE>

Referred-By: <sip:user1_public1@home1.net>

Supported: gruu

Contact: <sip:user1_public1@home1.net; gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 ;comp=sigcomp>

Content-Length: 0

Request-URI: contains the public user identity of UE#2.

Referred-By: contains the public user identity of the referring user, as in this example the referring user has decided to indicate its own identity to the referred user.

2. The I-CSCF performs HSS query

The I-CSCF performs HSS query to find out the S-CSCF serving UE#2.

3. REFER request (I-CSCF to S-CSCF) – see example in table A.4.3.1.2-3

After finding out the S-CSCF assigned to UE#2, the I-CSCF forwards the REFER request to that S-CSCF. The I-CSCF does not add itself to the Record-route since it does not have to remain on the signalling path for subsequent requests within the same dialog.

Table A.4.3.1.2-3: REFER request (I-CSCF to S-CSCF)

REFER sip:user2_public1@home2.net SIP/2.0

Max-Forwards: 67

Record-Route:

Route: <sip:scscf2.home2.net;lr>

P-Asserted-Identity:

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

Privacy:

From:

To:

Call-ID:

Cseq:

Refer-To:

Referred-By

Supported:

Contact:

Content-Length:

(…)

4. Evaluation of initial Filter Criteria

The S-CSCF validates the service profile of this subscriber, and evaluates the initial Filter Criteria.

5. REFER request (S-CSCF to P-CSCF) – see example in table A.4.3.1.2-5

The S-CSCF remembers (from registration procedures) the contact address of UE#2 and determines the P‑CSCF assigned for UE#2 and routes the REFER request there.

Table A.4.3.1.2-5: REFER request (S-CSCF to P-CSCF)

REFER sip:[5555::eeee:ffff:aaaa:bbbb]:8805;comp=sigcomp SIP/2.0

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

Max-Forwards: 66

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

Route: <pcscf2.visited2.net;lr>

P-Asserted-Identity:

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

P-Charging Function-Addresses: ccf=[5555::b99:c88:d77:e66]; ccf=[5555::a55:b44:c33:d22]; ecf=[5555::1ff:2ee:3dd:4cc]; ecf=[5555::6aa:7bb:8cc:9dd]

Privacy:

From:

To:

Call-ID:

Cseq:

Refer-To:

Referred-By:

Supported:

Contact:

P-Called-Party-ID: <sip:user2_public1@home2.net>

Content-Length:

(…)

6. REFER request (P-CSCF to UE#2) – see example in table A.4.3.1.2-6

The P-CSCF forwards the request to UE#2.

Table A.4.3.1.2-6: REFER request (P-CSCF to UE#2)

REFER sip:[5555::eeee:ffff:aaaa:bbbb]:8805;comp=sigcomp SIP/2.0

Via: SIP/2.0/UDP pcscf2.visited2.net:5088;comp=sigcomp;branch=z9hG4bK249354.1, SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK234974.3, SIP/2.0/UDP icscf2.home2.net;branch=z9hG4bK871y12.1, SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Max-Forwards: 65

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

P-Asserted-Identity:

Privacy:

From:

To:

Call-ID:

Cseq:

Refer-To:

Referred-By:

Supported:

Contact:

P-Called-Party-ID:

Content-Length:

(…)

7. 200 (OK) response to REFER (UE#2 to P-CSCF) – see example in table A.4.3.1.2-7

UE#2 accepts the REFER request by sending a 200 (OK) response.

Table A.4.3.1.2-7: 200 (OK) response to REFER (UE#2 to P-CSCF)

SIP/2.0 200 OK

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

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

Privacy=none

From:

To: <sip:user2_public1@home2.net>;tag=151170

Call-ID:

CSeq:

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

Content-Length:0

8. 200 (OK) response to REFER (P-CSCF to S-CSCF) – see example in table A.4.3.1.2-8

The P-CSCF forwards the 200 (OK) response to the S-CSCF.

Table A.4.3.1.2-8: 200 (OK) response to REFER (P-CSCF to S-CSCF)

SIP/2.0 200 OK

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

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

P-Asserted-Identity: "John Smith" <sip:user2_public1@home2.net

P-Access-Network-Info:

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

Privacy:

From:

To:

Call-ID:

CSeq:

Contact:

Content-Length:0

9. 200 (OK) response to REFER (S-CSCF to I-CSCF) – see example in table A.4.3.1.2-9

The S-CSCF forwards the 200 (OK) response to the I-CSCF.

Table A.4.3.1.2-9: 200 (OK) response to REFER (S-CSCF to I-CSCF)

SIP/2.0 200 OK

Record-Route:

P-Asserted-Identity: "John Smith" <sip:user2_public1@home2.net>, <tel:+1-212-555-2222>

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=123551024"; orig-ioi=home2.net term-ioi=visited2.net

P-Charging-Function-Addresses: ccf=[5555::b99:c88:d77:e66]; ccf=[5555::a55:b44:c33:d22]; ecf=[5555::1ff:2ee:3dd:4cc]; ecf=[5555::6aa:7bb:8cc:9dd]

Privacy:

From:

To:

Call-ID:

CSeq:

Contact:

Content-Length:0

10. 200 (OK) response to REFER (I-CSCF to UE#1 home network) – see example in table A.4.3.1.2-10

The I-CSCF forwards the 200 (OK) response to S-CSCF of UE#1.

Table A.4.3.1.2-10: 200 (OK) response to REFER (I-CSCF to S-CSCF of UE#1)

SIP/2.0 200 OK

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

Record-Route:

P-Asserted-Identity:

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=123551024"; orig-ioi=home2.net term-ioi=visited2.net

Privacy:

From:

To:

Call-ID:

CSeq:

Contact:

Content-Length:0

11. NOTIFY request (from UE#2 to P-CSCF) – see example in table A.4.3.1.2-11

UE#2 creates a subscription and sends a notification of the status of the refer event.

Table A.4.3.1.2-11: NOTIFY request (from UE#2 to P-CSCF)

NOTIFY sip:user1_public1@home1.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 ;comp=sigcomp SIP/2.0

Via: SIP/2.0/UDP [5555::eee:fff:aaa:bbb]:8805;comp=sigcomp;branch=z9hG4bK23dh42.1

Max-Forwards: 70

Route: <sip:pcscf2.home2.net:5088;lr>,<sip:scscf2.home2.net;lr>, <sip:scscf1.home1.net;lr>, <sip:pcscf1.visited1.net;lr>

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

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

From: <sip:user2_public1@home2.net>;tag=151170

Call-ID: cb03a0s09a2sdfglkj490333

CSeq: 42 NOTIFY

Subscription-State: active;expires:7200

Event: refer

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

Content-Length: (…)

Content-Type: message/sipfrag

SIP/2.0 100 (Trying) response

12. NOTIFY request (from P-CSCF to S-CSCF) – see example in table A.4.3.1.2-12

The P-CSCF forwards the NOTIFY request to the S-CSCF.

Table: A.4.3.1.2-12: NOTIFY request (from P-CSCF to S-CSCF)

NOTIFY sip:user1_public1@home1.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 ;comp=sigcomp SIP/2.0

Via: SIP/2.0/UDP pcscf2.visited2.net;branch=z9hG4bK234223.1, SIP/2.0/UDP [5555::eee:fff:aaa:bbb]:8805;comp=sigcomp;branch=z9hG4bK23dh42.1

Max-Forwards: 69

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

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

Record-Route: <sip:pcscf2.visited2.net;lr>

P-Access-Network-Info:

To:

From:

Call-ID:

CSeq:

Subscription-State:

Event:

Contact:

Content-Length: (…)

Content-Type:

(…)

13. NOTIFY request (from S-CSCF to UE#1 home network) – see example in table A.4.3.1.2-13

The S-CSCF forwards the NOTIFY request to UE#1 home network (S-CSCF#1).

Table A.4.3.1.2-13: NOTIFY request (from S-CSCF to UE#1 home network)

NOTIFY sip: user1_public1@home1.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 ;comp=sigcomp SIP/2.0

Via: SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK764z87.1, SIP/2.0/UDP pcscf2.visited2.net;branch=z9hG4bK234223.1, SIP/2.0/UDP [5555::eee:fff:aaa:bbb]:8805;comp=sigcomp;branch=z9hG4bK23dh42.1

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

Max-Forwards: 68

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

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

To:

From:

Call-ID:

CSeq:

Subscription-State:

Event:

Contact:

Content-Length: (…)

Content-Type:

(…)

14. 200 (OK) response (S-CSCF of UE#1 to S-CSCF) – see example in table A.4.3.1.2-14

The S-CSCF receives a 200 (OK) response to the NOTIFY request from UE#1’s home network.

Table A.4.3.1.2-14: 200 (OK) response (S-CSCF to S-CSCF)

SIP/2.0 200 OK

Via: SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK764z87.1, SIP/2.0/UDP pcscf2.visited2.net;branch=z9hG4bK234223.1, SIP/2.0/UDP [5555::eee:fff:aaa:bbb]:8805;comp=sigcomp;branch=z9hG4bK23dh42.1

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

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

From:

To:

Call-ID:

CSeq:

Content-Length: 0

15. 200 (OK) response (S-CSCF to P-CSCF) – see example in table A.4.3.1.2-15

The S-CSCF forwards the 200 (OK) response to the P-CSCF.

Table A.4.3.1.2-15: 200 (OK) response (S-CSCF to P-CSCF)

SIP/2.0 200 OK

Via: SIP/2.0/UDP pcscf2.visited2.net;branch=z9hG4bK234223.1, SIP/2.0/UDP [5555::eee:fff:aaa:bbb]:8805;comp=sigcomp;branch=z9hG4bK23dh42.1

Record-Route:

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

From:

To:

Call-ID:

CSeq:

Content-Length: 0

16. 200 (OK) response (P-CSCF to UE#2) – see example in table A.4.3.1.2-16

The P-CSCF forwards the 200 (OK) response to UE#2.

Table A.4.3.1.2-16: 200 (OK) response (P-CSCF to UE#2)

SIP/2.0 200 OK

Via: SIP/2.0/UDP [5555::eee:fff:aaa:bbb]:8805;comp=sigcomp;branch=z9hG4bK23dh42.1

Record-Route:

From:

To:

Call-ID:

CSeq:

Content-Length: 0

17. UE#2 joins the conference.

UE#2 joins the conference. The message flows are depicted in subclause 6.3.2.

18. NOTIFY request (from UE#2 to P-CSCF) – see example in table A.4.3.1.2-18

P-SCSF receives a NOTIFY request from UE#2 indicating the status of the refer event.

Table A.4.3.1.2-18: NOTIFY request (from UE#2 to P-CSCF)

NOTIFY sip:user1_public1@home1.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 ;comp=sigcomp SIP/2.0

Via: SIP/2.0/UDP [5555::eee:fff:aaa:bbb]:8805;comp=sigcomp;branch=z9hG4bK23dh42.1

Max-Forwards: 70

Route: <sip:pcscf2.visited2.net:5088;lr>,<sip:scscf2.home2.net;lr>, <sip:scscf1.home1.net;lr>, <sip:pcscf1.visited1.net;lr>

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

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

From: <sip:user2_public1@home2.net>;tag=151170

Call-ID: cb03a0s09a2sdfglkj490333

CSeq: 43 NOTIFY

Subscription-State: terminated

Event: refer

Content-Length: (…)

Content-Type: message/sipfrag

SIP/2.0 200 OK

19. NOTIFY request (from P-CSCF to S-CSCF) – see example in table A.4.3.1.2-19

The P-CSCF forwards the NOTIFY request to the S-CSCF.

Table A.4.3.1.2-19: NOTIFY request (from P-CSCF to S-CSCF)

NOTIFY sip:user1_public1@home1.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 ;comp=sigcomp SIP/2.0

Via: SIP/2.0/UDP pcscf2.visited2.net;branch=z9hG4bK234223.1, SIP/2.0/UDP [5555::eee:fff:aaa:bbb]:8805;comp=sigcomp;branch=z9hG4bK23dh42.1

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

Max-Forwards: 69

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

Record-Route: <sip:pcscf2.visited2.net;lr>P-Access-Network-Info:

To:

From:

Call-ID:

CSeq:

Subscription-State:

Event:

Content-Length: (…)

Content-Type:

(…)

20. NOTIFY request (from S-CSCF to S-CSCF of UE#1) – see example in table A.4.3.1.2-20

The S-CSCF forwards the NOTIFY request to UE#1’s home network.

Table A.4.3.1.2-20: NOTIFY request (from S-CSCF to S-CSCF of UE#1)

NOTIFY sip:user1_public1@home1.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 ;comp=sigcomp SIP/2.0

Via: SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK23d244.1, SIP/2.0/UDP pcscf2.visited2.net;branch=z9hG4bK234223.1, SIP/2.0/UDP [5555::eee:fff:aaa:bbb]:8805;comp=sigcomp;branch=z9hG4bK23dh42.1

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

Max-Forwards: 68

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

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

To:

From:

Call-ID:

CSeq:

Subscription-State:

Event:

Content-Length: (…)

Content-Type:

(…)

21. 200 (OK) response (S-CSCF of UE#1 to S-CSCF) – see example in table A.4.3.1.2-21

The S-CSCF receives a 200 (OK) response to the NOTIFY request from UE#1 home network.

Table A.4.3.1.2-21: 200 (OK) response (S-CSCF of UE#1 to S-CSCF)

SIP/2.0 200 OK

Via: SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK23d244.1, SIP/2.0/UDP pcscf2.visited2.net;branch=z9hG4bK234223.1, SIP/2.0/UDP [5555::eee:fff:aaa:bbb]:8805;comp=sigcomp;branch=z9hG4bK23dh42.1

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

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

From:

To:

Call-ID:

CSeq:

Content-Length: 0

22. 200 (OK) response (P-CSCF to S-CSCF) – see example in table A.4.3.1.2-22

The S-CSCF forwards the 200 (OK) response to the P-CSCF.

Table A.4.3.1.2-22: 200 (OK) response (S-CSCF to P-CSCF)

SIP/2.0 200 OK

Via: SIP/2.0/UDP pcscf2.visited2.net;branch=z9hG4bK234223.1, SIP/2.0/UDP [5555::eee:fff:aaa:bbb]:8805;comp=sigcomp;branch=z9hG4bK23dh42.1

Record-Route:

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

From:

To:

Call-ID:

CSeq:

Content-Length:

23. 200 (OK) response (P-CSCF to UE#2) – see example in table A.4.3.1.2-23

The P-CSCF forwards the 200 (OK) response to UE#2.

Table A.4.3.1.2-23: 200 (OK) response (P-CSCF UE#2)

SIP/2.0 200 OK

Via: SIP/2.0/UDP [5555::eee:fff:aaa:bbb]:8805;comp=sigcomp;branch=z9hG4bK23dh42.1

Record-Route:

From:

To:

Call-ID:

CSeq:

Content-Length:

A.4.3.1.3 MRFC/AS invites a user to a conference

Figure A.4.3.1.3-1 shows an MRFC/AS inviting a user to a conference. The invitation is sent as a result of user1@home1.net sending a REFER request to the MRFC/AS. The MRFC/AS is located in a different network than user’s S-CSCF.

Figure A.4.3.1.3-1: MRFC/AS inviting a user to a conference – MRFC/AS routes directly to I-CSCF

The details of the flows are as follows:

1. INVITE request (MRFC/AS to I-CSCF) – see example in table A.4.3.1.3-1

In this example, the MRFC/AS is capable of resolving the terminating users I-CSCF address for this request. As a result of a DNS query, it has received the address of the I-CSCF as the next hop.

The MRFC/AS invites a user to a conference as it received a REFER request from another user.

The MRFC/AS determines the codecs that are applicable for this conference. It builds a SDP Offer containing bandwidth requirements and characteristics of each, and assigns local port numbers for each possible media flow. Multiple media flows may be offered, and for each media flow (m= line in SDP). In this example, there is only one codec per media offered.

For this example, it is assumed that MRFC/AS is willing to establish a multimedia session comprising a video stream and an audio stream. The video stream supports H.263. The audio stream supports the AMR codec.

The MRFC/AS indicates that it supports precondition and it indicates that it supports reliable provisional responses. However, it does not use the "Require” header for these capabilities.

The UE does not have available the resources that are necessary to transport the media.

For this example it is assumed, that signalling encryption was negotiated between UE and P‑CSCF in the security mode set-up procedure during the last successful authentication. This option will only be shown in this example.

Table A.4.3.1.3-1: INVITE request (MRFC/AS to I-CSCF)

INVITE sip:user2_public1@home2.net SIP/2.0

Via: SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK23273846

Max-Forwards: 70

P-Asserted-Identity: <sip:conference1@mrfc1.home1.net>

P-Charging-Vector: ####

Privacy: none

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

To: <sip:user2_public1@home2.net>

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 127 INVITE

Supported: precondition, 100rel

Referred-By: <sip:user1_public1@home1.net>

Contact: <sip:conference1@mrfc1.home1.net>;isfocus

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY, PUBLISH

Allow-Events: conference, pending-additions

Content-Type: application/sdp

Content-Length: (…)

v=0

o=- 2987933615 2987933615 IN IP6 5555::abc:def:abc:abc

s=-

c=IN IP6 5555::abc:def:abc:def

t=0 0

m=video 10001 RTP/AVP 98

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

m=audio 6544 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=inactive

a=rtpmap:97 AMR

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

a=rtpmap:96 telephone-event

Request-URI: contains the public user identity of UE#2.

P-Asserted-Identity: contains the asserted identity as configured in the MRFC/AS.

Contact: contains the conference URI for the conference allocated at the MRFC/AS and the "isfocus" feature parameter.

Allow-Events: The MRFC/AS indicates support for the "conference" and "pending-additions" event packages

Referred-By: contains the same value as received in the Referred-By in the REFER request that was received from the user that requested the MRFC/AS send the INVITE request.

2. 100 (Trying) response (I-CSCF to MRFC/AS) – see example in table A.4.3.1.3-2

The I-CSCF responds to the INVITE request with a 100 (Trying) provisional response.

Table A.4.3.1.3-2: 100 (Trying) response (I-CSCF to MRFC/AS)

SIP/2.0 100 Trying

Via: SIP/2.0/UDP conference1@mrfc1.home1.net;branch=z9hG4bK23273846

From:

To:

Call-ID:

CSeq:

Content-Length: 0

3. Cx: User Location Query procedure

The I-CSCF sends a query to the HSS to find out the S-CSCF of the called user. The HSS responds with the address of the current S-CSCF for the terminating subscriber.

For detailed message flows see 3GPP TS 29.228 [12].

4. INVITE request (I-CSCF to S-CSCF) – see example in table A.4.3.1.3-4

The INVITE request is forwarded to the S-CSCF.

Table A.4.3.1.3-4: INVITE request (I-CSCF to S-CSCF)

INVITE sip:user2_public1@home2.net SIP/2.0

Via: SIP/2.0/UDP icscf2.home2.net;branch=z9hG4bK241d17.2, SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK23273846

Max-Forwards: 69

P-Asserted-Identity:

P-Charging-Vector:

Privacy:

From:

To:

Call-ID:

Cseq:

Supported:

Referred-By:

Contact:

Allow:

Allow-Events:

Content-Type:

Content-Length: (…)

5. 100 (Trying) response (S-CSCF to I-CSCF) – see example in table 6.2.2.2-5

The S-CSCF responds to the INVITE request (3) with a 100 (Trying) provisional response.

Table 6.2.2.2-5: 100 (Trying) response (S-CSCF to I-CSCF)

SIP/2.0 100 Trying

Via: SIP/2.0/UDP icscf2.home2.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK23273846

From:

To:

Call-ID:

CSeq:

Content-Length: 0

6. Evaluation of initial filter criteria

The S-CSCF validates the service profile of this subscriber and evaluates the initial filter criteria.

7. INVITE request (S-CSCF to P-CSCF) – see example in table A.4.3.1.3-7

S-CSCF remembers (from registration procedures) the contact address of UE#2 and determines the P-CSCF assigned for UE#2 and routes message there.

Table A.4.3.1.3-7: INVITE request (S-CSCF to P-CSCF)

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

Via: SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP icscf2.home2.net;branch=z9hG4bK241d17.2, SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK23273846

Max-Forwards: 68

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

P-Asserted-Identity:

P-Charging-Vector: ####

Privacy:

From:

To:

Call-ID:

Cseq:

Supported:

Referred-By:

Contact:

Allow:

Allow-Events:

P-Called-Party-ID: <sip:user2_public1@home2.net>

Content-Type:

Content-Length: (…)

8. 100 (Trying) response (P-CSCF to S-CSCF) – see example in table A.4.3.1.3-8

The P-CSCF responds to the INVITE request (6) with a 100 (Trying) provisional response.

Table A.4.3.1.3-8: 100 (Trying) response (P-CSCF to S-CSCF)

SIP/2.0 100 Trying

Via: SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP icscf2.home2.net;branch=z9hG4bK241d17.2, SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK23273846

From:

To:

Call-ID:

CSeq:

Content-Length: 0

9. INVITE request (P-CSCF to UE#2) – see example in table A.4.3.1.3-9

P-CSCF forwards the request to UE#2.

Table A.4.3.1.3-9: INVITE request (P-CSCF to UE#2)

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

Via: SIP/2.0/UDP pcscf2.visited2.net:5088;comp=sigcomp;branch=z9hG4bK240f34.1 SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP icscf2.home2.net;branch=z9hG4bK241d17.2, SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK23273846

Max-Forwards: 67

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

P-Asserted-Identity:

Privacy:

From:

To:

Call-ID:

Cseq:

Supported:

Referred-By:

Contact:

Allow:

Allow-Events:

P-Called-Party-ID:

Content-Type:

Content-Length: (…)

10. 100 (Trying) response (UE#2 to P-CSCF) – see example in table A.4.3.1.3-10

UE#2 responds to the INVITE request (9) with a 100 (Trying) provisional response.

Table A.4.3.1.3-10: 100 (Trying) response (UE#2 to P-CSCF)

SIP/2.0 100 Trying

From:

To:

Call-ID:

CSeq:

Content-Length: 0

11. 183 (Session Progress) response (UE#2 to P-CSCF) – see example in table A.4.3.1.3-11

UE#2 determines the complete set of codecs that it is capable of supporting for this session. It determines the intersection with those appearing in the SDP in the INVITE request.

The UE responds with a 183 (Session Progress) response containing SDP back to the originator. This response is sent to the P-CSCF.

Table A.4.3.1.3-11: 183 (Session Progress) response (UE#2 to P-CSCF)

SIP/2.0 183 Session Progress

Via: SIP/2.0/UDP pcscf2.visited2.net:5088;comp=sigcomp;branch=z9hG4bK240f34.1, SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP icscf2.home2.net;branch=z9hG4bK241d17.2, SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK23273846

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

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

Privacy: none

From:

To: <sip:user2_public1@home2.net>; tag=314159

Call-ID:

CSeq:

Require: precondition, 100rel

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

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

RSeq: 9021

Content-Type: application/sdp

Content-Length: (…)

v=0

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

s=-

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

t=0 0

m=video 3400 RTP/AVP 98

b=AS:75

a=curr:qos local none

a=curr:qos remote none

a=des:qos mandatory local sendrecv

a=des:qos mandatory remote sendrecv

a=inactive

a=conf:qos remote sendrecv

a=rtpmap:98 H263

a=fmtp:98 profile-level-id=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 mandatory remote sendrecv

a=inactive

a=conf:qos remote sendrecv

a=rtpmap:97 AMR

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

a=rtpmap:96 telephone-event

12. Authorize QoS resources

The P-CSCF authorizes the resources necessary for this session. The approval of QoS commitment either happens at this stage or after 200 (OK) response of INVITE request (31) based on operator local policy.

13. 183 (Session Progress) response (P-CSCF to S-CSCF) – see example in table A.4.3.1.3-13

The P-CSCF forwards the 183 (Session Progress) response to the S-CSCF.

Table A.4.3.1.3-13: 183 (Session Progress) response (P-CSCF to S-CSCF)

SIP/2.0 183 Session Progress

Via: SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP icscf2.home2.net;branch=z9hG4bK241d17.2, SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK23273846

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

P-Asserted-Identity: "John Smith" <sip:user2_public1@home2.net>

P-Access-Network-Info:

P-Charging-Vector: ####

Privacy:

From:

To:

Call-ID:

CSeq:

Require:

Contact:

Allow:

RSeq:

Content-Type:

Content-Length:

14. 183 (Session Progress) response (S-CSCF to I-CSCF) – see example in table A.4.3.1.3-14

The S-CSCF forwards the 183 (Session Progress) response to I-CSCF.

Table A.4.3.1.3-14: 183 (Session Progress) response (S-CSCF to I-CSCF)

SIP/2.0 183 Session Progress

Via: SIP/2.0/UDP icscf2.home2.net;branch=z9hG4bK241d17.2, SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK23273846

Record-Route:

P-Asserted-Identity: "John Smith" <sip:user2_public1@home2.net>, <tel:+1-212-555-2222>

P-Charging-Vector: ####

P-Charging-Function-Addresses: ####

Privacy:

From:

To:

Call-ID:

CSeq:

Require:

Contact:

Allow:

RSeq:

Content-Type:

Content-Length:

15. 183 (Session Progress) response (I-CSCF to MRFC/AS) – see example in table A.4.3.1.3-15

The I-CSCF forwards the 183 (Session Progress) response to the MRFC/AS.

Table A.4.3.1.3-15: 183 (Session Progress) response (I-CSCF to MRFC/AS)

SIP/2.0 183 Session Progress

Via: SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK23273846

Record-Route:

P-Asserted-Identity:

Privacy:

From:

To:

Call-ID:

CSeq:

Require:

Contact:

Allow:

RSeq:

Content-Type:

Content-Length:

16. PRACK request (MRFC/AS to S-CSCF) – see example in table A.4.3.1.3-16

The MRFC/AS determines which media flows should be used for this session, and which codecs should be used for each of those media flows.

Since there is no change in the media characteristics, the MRFC/AS does not include any new SDP offer in the PRACK request sent to UE#2.

The MRFC/AS sends the PRACK request to the S-CSCF of UE#2 according to the Record-Route header received in 183 Session progress (15).

Table A.4.3.1.3-16: PRACK request (MRFC/AS to S-CSCF)

PRACK sip:user2_public1@home2.net;gr=urn:uuid:2ad8950e-48a5-4a74-8d99-ad76cc7fc74 ;comp=sigcomp SIP/2.0

Via: SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK23273846

Max-Forwards: 70

Route: <sip:scscf2.home2.net;lr>, <sip:pcscf2.visited2.net;lr>

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

To: <sip:user2_public1@home2.net>;tag=314159

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 128 PRACK

RAck: 9021 127 INVITE

Content-Length: 0

Request-URI: takes the value of the Contact header of the received 183 (Session Progress) response.

17. Resource reservation

After determining the media streams, the MRFC/AS initiates the reservation procedures for the resources needed for this session.

18. PRACK request (S-CSCF to P-CSCF) – see example in table A.4.3.1.3-18

The P-CSCF forwards the PRACK request to the P-CSCF.

Table A.4.3.1.3-18: PRACK request (S-CSCF to P-CSCF)

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

Via: SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK23273846

Max-Forwards: 69

Route: <sip:pcscf2.visited2.net;lr>

From:

To:

Call-ID:

Cseq:

RAck:

Content-Length:

19. PRACK request (P-CSCF to UE#2) – see example in table A.4.3.1.3-19

The P-CSCF forwards the PRACK request to UE#2.

Table A.4.3.1.3-19: PRACK request (P-CSCF to UE#2)

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

Via: SIP/2.0/UDP pcscf2.visited2.net:5088;comp=sigcomp;branch=z9hG4bK240f34.1, SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK23273846

Max-Forwards: 68

From:

To:

Call-ID:

Cseq:

RAck:

Content-Length:

20. 200 (OK) response (UE#2 to P-CSCF) – see example in table A.4.3.1.3-20 (related to table A.4.3.1.3-19)

UE#2 acknowledges the PRACK request (19) with a 200 (OK) response.

Table A.4.3.1.3-20: 200 (OK) response (UE#2 to P-CSCF)

SIP/2.0 200 OK

Via: SIP/2.0/UDP pcscf2.visited2.net:5088;comp=sigcomp;branch=z9hG4bK240f34.1, SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK23273846

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

From:

To:

Call-ID:

CSeq:

Content-Length: 0

21. 200 (OK) response (P-CSCF to S-CSCF) – see example in table A.4.3.1.3-21

The P-CSCF forwards the 200 (OK) response to the S-CSCF.

Table A.4.3.1.3-21: 200 (OK) response (P-CSCF to S-CSCF)

SIP/2.0 200 OK

Via: SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK23273846

From:

To:

Call-ID:

CSeq:

Content-Type:

Content-Length:

22. 200 (OK) response (S-CSCF to MRFC/AS) – see example in table A.4.3.1.3-22

The S-CSCF forwards the 200 (OK) response to the MRFC/AS.

Table A.4.3.1.3-22: 200 (OK) response (S-CSCF to MRFC/AS)

SIP/2.0 200 OK

Via: SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK23273846

P-Access-Network-Info:

From:

To:

Call-ID:

CSeq:

Content-Type:

Content-Length:

23. UPDATE request (MRFC/AS to S-CSCF) – see example in table A.4.3.1.3-23

When the resource reservation in step (17) is completed, the MRFC/AS sends the UPDATE request to UE#2.

Table A.4.3.1.3-23: UPDATE request (MRFC/AS to S-CSCF)

UPDATE sip:user2_public1@home2.net;gr=urn:uuid:2ad8950e-48a5-4a74-8d99-ad76cc7fc74 ;comp=sigcomp SIP/2.0

Via: SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK23273846

Max-Forwards: 70

Route: <sip:scscf2.home2.net;lr>, <sip:pcscf2.visited2.net;lr>

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

To: <sip:user2_public1@home2.net>;tag=314159

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 129 UPDATE

Content-Type: application/sdp

Content-Length: (…)

v=0

o=- 2987933615 2987933617 IN IP6 5555::abc:def:abc:abc

s=-

c=IN IP6 5555::abc:def:abc:def

t=0 0

m=video 0 RTP/AVP 98

b=AS:75

a=curr:qos local sendrecv

a=curr:qos remote none

a=des:qos mandatory local sendrecv

a=des:qos mandatory remote sendrecv

a=rtpmap:98 H263

a=fmtp:98 profile-level-id=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 mandatory remote sendrecv

a=rtpmap:97 AMR

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

a=rtpmap:96 telephone-event

Request-URI: takes the value of the Contact header of the received 183 (Session Progress) response.

24. UPDATE request (S-CSCF to P-CSCF) – see example in table A.4.3.1.3-24

The S-CSCF forwards the UPDATE request to the P-CSCF.

Table A.4.3.1.3-24: UPDATE request (S-CSCF to P-CSCF)

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

Via: SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK23273846

Max-Forwards: 69

Route: <sip:pcscf2.visited2.net;lr>

From:

To:

Call-ID:

Cseq:

Content-Type:

Content-Length:

25. UPDATE request (P-CSCF to UE#2) – see example in table A.4.3.1.3-25

The P-CSCF forwards the UPDATE request to UE#2.

Table A.4.3.1.3-25: UPDATE request (P-CSCF to UE#2)

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

Via: SIP/2.0/UDP pcscf2.visited2.net:5088;comp=sigcomp;branch=z9hG4bK240f34.1, SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK23273846

Max-Forwards: 68

From:

To:

Call-ID:

Cseq:

Content-Type:

Content-Length:

26. 200 (OK) response (UE#2 to P-CSCF) – see example in table A.4.3.1.3-26 (related to table A.4.3.1.3-25)

UE#2 acknowledges the UPDATE request (25) with a 200 (OK) response.

Table A.4.3.1.3-26: 200 (OK) response (UE#2 to P-CSCF)

SIP/2.0 200 OK

Via: SIP/2.0/UDP pcscf2.visited2.net:5088;comp=sigcomp;branch=z9hG4bK240f34.1, SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK23273846

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

From:

To:

Call-ID:

CSeq:

Content-Type: application/sdp

Content-Length: (…)

v=0

o=- 2987933623 2987933625 IN IP6 5555:: aaa:bbb:ccc:ddd

s=-

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

t=0 0

m=video 0 RTP/AVPF 98

b=AS:75

a=curr:qos local sendrecv

a=curr:qos remote sendrecv

a=des:qos mandatory local sendrecv

a=des:qos mandatory remote sendrecv

a=rtpmap:98 H263

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

m=audio 6544 RTP/AVPF 97 96

b=AS:25.4

a=curr:qos local sendrecv

a=curr:qos remote sendrecv

a=des:qos mandatory local sendrecv

a=des:qos mandatory remote sendrecv

a=rtpmap:97 AMR

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

a=rtpmap:96 telephone-event

27. 200 (OK) response (P-CSCF to S-CSCF) – see example in table A.4.3.1.3-27

The P-CSCF forwards the 200 (OK) response to the S-CSCF.

Table A.4.3.1.3-27: 200 (OK) response (P-CSCF to S-CSCF)

SIP/2.0 200 OK

Via: SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK23273846

P-Access-Network-Info:

From:

To:

Call-ID:

CSeq:

Content-Type:

Content-Length:

28. 200 (OK) response (S-CSCF to MRFC/AS) – see example in table A.4.3.1.3-28

The S-CSCF forwards the 200 (OK) response to the MRFC/AS.

Table A.4.3.1.3-28: 200 (OK) response (S-CSCF to MRFC/AS)

SIP/2.0 200 OK

Via: SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK23273846

From:

To:

Call-ID:

CSeq:

Content-Type:

Content-Length:

29. H.248 interaction to modify connection

MRFC initiates a H.248 interaction to connect through the multimedia processing resources for UE#2 in MRFP.

30. 200 (OK) response (UE#2 to P-CSCF) – see example in table A.4.3.1.3-30 (related to table A.4.3.1.3-9)

UE#2 sends a 200 (OK) response final response to the INVITE request (9) to the P-CSCF.

Table 6.2.2.2-30: 200 (OK) response (UE#2 to P-CSCF)

SIP/2.0 200 OK

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

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

From:

To:

Call-ID:

CSeq: 127 INVITE

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

Content-Length:0

31. Approval of QoS commit

The P-CSCF approves the commitment of the QoS resources if it was not approved already in step (12).

32. 200 (OK) response (P-CSCF to S-CSCF) – see example in table A.4.3.1.3-32

The P-CSCF forwards the 200 (OK) response to the S-CSCF.

Table A.4.3.1.3-32: 200 (OK) response (P-CSCF to S-CSCF)

SIP/2.0 200 OK

Via: SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP icscf2.home2.net;branch=z9hG4bK241d17.2, SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK23273846

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

P-Access-Network-Info:

From:

To:

Call-ID:

CSeq:

Contact:

Content-Length:0

33. 200 (OK) response (S-CSCF to I-CSCF) – see example in table A.4.3.1.3-33

The S-CSCF sends a 200 (OK) response final response along the signalling path back to I-CSCF.

Table A.4.3.1.3-33: 200 (OK) response (S-CSCF to I-CSCF)

SIP/2.0 200 OK

Via: SIP/2.0/UDP icscf2.home2.net;branch=z9hG4bK241d17.2, SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK23273846

Record-Route:

From:

To:

Call-ID:

CSeq:

Contact:

Content-Length:

34. 200 (OK) response (I-CSCF to MRFC/AS) – see example in table A.4.3.1.3-34

The I-CSCF forwards the 200 (OK) response final response to the session originator.

Table 6.2.2.2-34: 200 (OK) response (I-CSCF to MRFC/AS)

SIP/2.0 200 OK

Via: SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK23273846

Record-Route:

From:

To:

Call-ID:

CSeq:

Contact:

Content-Length:

35. ACK request (MRFC/AS to S-CSCF) – see example in table A.4.3.1.3-35

The MRFC/AS responds to the 200 (OK) response (35) with an ACK request sent to the S-CSCF.

Table A.4.3.1.3-35: ACK request (MRFC/AS to S-CSCF)

ACK sip: user2_public1@home2.net;gr=urn:uuid:2ad8950e-48a5-4a74-8d99-ad76cc7fc74 ;comp=sigcomp SIP/2.0

Via: SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK23273846

Max-Forwards: 70

Route: <sip:scscf2.home2.net;lr>, <sip:pcscf2.visited2.net;lr>

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

To: <sip:user2_public1@home2.net>;tag=314159

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 127 ACK

Content-Length: 0

36. ACK request (S-CSCF to P-CSCF) – see example in table A.4.3.1.3-36

The S-CSCF forwards the ACK request to the P-CSCF.

Table A.4.3.1.3-36: ACK request (S-CSCF to P-CSCF)

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

Via: SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK23273846

Max-Forwards: 69

Route: <sip:pcscf2.visited2.net;lr>

From:

To:

Call-ID:

Cseq:

Content-Length:

37. ACK request (P-CSCF to UE#2) – see example in table A.4.3.1.3-37

The P-CSCF forwards the ACK request to the UE#2.

Table A.4.3.1.3-37: ACK request (P-CSCF to UE#2)

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

Via: SIP/2.0/UDP pcscf2.visited2.net:5088;comp=sigcomp;branch=z9hG4bK240f34.1, SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK23273846

Max-Forwards: 68

From:

To:

Call-ID:

Cseq:

Content-Length:

A.4.3.1.4 MRFC/AS refers a user to a conference

Figure A.4.3.1.4-1 shows how MRFC/AS refers UE#2 to a conference by sending a REFER request to UE#2. The MRFC/AS has created a conference and allocated a conference URI.

In this example, the MRFC/AS is not capable of resolving the Request-URI and therefore routes the request first to the S-CSCF in its own network.

Figure A.4.3.1.4-1: MRFC/AS inviting another user to a conference by
sending a REFER request to UE#2

The details of the flows are as follows:

1. REFER request (MRFC/AS to S-CSCF) – see example in table A.4.3.1.4-1

The MRFC/AS wants to invite another user to a conference by sending a REFER request to that user.

Table A.4.3.1.4-1: REFER request (MRFC/AS to S-CSCF)

REFER sip: user2_public1@home2.net SIP/2.0

Via: SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK23273846

Max-Forwards: 70

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

P-Asserted-Identity: <sip:conference1@mrfc1.home1.net>

P-Charging-Vector: ####

Privacy: none

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

To: <sip:user2_public1@home2.net>

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 127 REFER

Refer-To: <conference1@mrfc1.home1.net;method=INVITE>

Referred-By: <sip:user1_public1@home1.net>

Contact: <sip:conference1@mrfc1.home1.net>;isfocus

Content-Length: 0

Request-URI: contains the public user identity of UE#2.

P-Asserted-Identity: contains the asserted identity as configured in the MRFC/AS.

P-Charging-Vector: the MRFC/AS inserts this header and populates the icid parameters with a globally unique value and includes the originating network identifier.

Refer-To: contains the conference URI. Additionally the method uri parameter indicates that the UE#2 shall send an INVITE request to this URI.

Referred-By: contains the public user identity of the user, on which behalf the MRFC/AS sends the REFER message.

Contact: contains the conference URI for the conference allocated at the MRFC/AS and the "isfocus" feature parameter.

2. REFER request (S-CSCF to I-CSCF) – see example in table A.4.3.1.4-2

The REFER request is forwarded to the I-CSCF.

Table A.4.3.1.4-2: REFER request (S-CSCF to I-CSCF)

REFER sip:user2_public1@home2.net SIP/2.0

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

Max-Forwards: 69

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

P-Asserted-Identity: <sip:conference1@mrfc1.home1.net>

P-Charging-Vector:

Privacy:

From:

To:

Call-ID:

Cseq:

Refer-To:

Referred-By:

Contact:

Content-Length:

3. Cx: User Location Query procedure

The I-CSCF sends a query to the HSS to find out the S-CSCF of the called user. The HSS responds with the address of the current S-CSCF for the terminating subscriber.

For detailed message flows see 3GPP TS 29.228 [12]

4. REFER request (I-CSCF to S-CSCF) – see example in table A.4.3.1.4-4

The I-CSCF forwards the REFER request to the address obtained during HSS query. The I-CSCF adds itself to the Via, but not to the Record-Route header as it will not need to stay on the signalling path for subsequent requests.

Table A.4.3.1.4-4: REFER request (I-CSCF to S-CSCF)

REFER sip:user2_public1@home2.net SIP/2.0

Via: SIP/2.0/UDP icscf2.home2.net;branch=z9hG4bK231234.5, SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK23273846

Max-Forwards: 68

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

P-Asserted-Identity:

P-Charging-Vector:

Privacy:

From:

To:

Call-ID:

Cseq:

Refer-To:

Referred-By:

Contact:

Content-Length:

5. Evaluation of Initial Filter criteria

S-CSCF validates the service profile of this subscriber and evaluates the initial filter criteria.

6. REFER request (S-CSCF to P-CSCF) – see example in table A.4.3.1.4-6

The S-CSCF remembers (from registration procedures) the contact address of UE#2 and determines the P‑CSCF assigned for UE#2 and routes the message there. The S-CSCF adds itself to the Via and Record-Route headers.

Table A.4.3.1.4-6: REFER request (S-CSCF to P-CSCF)

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

Via: SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK234974.3, SIP/2.0/UDP icscf2.home2.net;branch=z9hG4bK231234.5, SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK23273846

Max-Forwards: 67

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

P-Asserted-Identity:

P-Charging-Vector: ####

Privacy:

From:

To:

Call-ID:

Cseq:

Refer-To:

Referred-By:

Contact:

P-Called-Party-ID: <sip:user2_public1@home2.net>

Content-Length:

7. REFER request (P-CSCF to UE#2) – see example in table A.4.3.1.4-7

The P-CSCF forwards the request to UE#2.

Table A.4.3.1.4-7: REFER request (P-CSCF to UE#2)

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

Via: SIP/2.0/UDP pcscf2.visited2.net:5088;comp=sigcomp;branch=z9hG4bK249354.1, SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK234974.3, SIP/2.0/UDP icscf2.home2.net;branch=z9hG4bK231234.5, SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK23273846

Max-Forwards: 66

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

P-Asserted-Identity:

Privacy:

From:

To:

Call-ID:

Cseq:

Refer-To:

Referred-By:

Contact:

P-Called-Party-ID:

Content-Length:

8. 200 (OK) response to REFER (UE#2 to P-CSCF) – see example in table A.4.3.1.4-8

UE# accepts the REFER request by sending a 200 (OK) response.

Table A.4.3.1.4-8: 200 (OK) response to REFER (UE#2 to P-CSCF)

SIP/2.0 200 OK

Via: SIP/2.0/UDP pcscf2.visited2.net:5088;comp=sigcomp;branch=z9hG4bK249354.1, SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK234974.3, SIP/2.0/UDP icscf2.home2.net;branch=z9hG4bK231234.5, SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK23273846

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

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

Privacy:none

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

To: <sip:user2_public1@home2.net>;tag=151170

Call-ID: cb03a0s09a2sdfglkj490333

CSeq: 127 REFER

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

Content-Length:0

9. 200 (OK) response to REFER (P-CSCF to S-CSCF) – see example in table A.4.3.1.4-9

The P-CSCF forwards the response to the S-CSCF.

Table A.4.3.1.4-9: 200 (OK) response to REFER (P-CSCF to S-CSCF)

SIP/2.0 200 OK

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

P-Access-Network-Info:

P-Asserted-Identity: <sip:user2_public1@home2.net>

P-Charging-Vector: ####

Privacy:

From:

To:

Call-ID:

CSeq:

Contact:

Content-Length:

10. 200 (OK) response to REFER (S-CSCF to I-CSCF) – see example in table A.4.3.1.4-10

The S-CSCF forwards the response to the I-CSCF.

Table A.4.3.1.4-10: 200 (OK) response to REFER (S-CSCF to I-CSCF)

SIP/2.0 200 OK

Via: SIP/2.0/UDP icscf2.home2.net;branch=z9hG4bK231234.5, SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK23273846

Record-Route:

P-Asserted-Identity: "John Smith" <sip:user2_public1@home2.net; <tel:+1-212-555-2222>

P-Charging-Vector: ####

P-Charging-Function-Addresses: ####

Privacy:

From:

To:

Call-ID:

CSeq:

Contact:

Content-Length:

11. 200 (OK) response to REFER (I-CSCF to S-CSCF) – see example in table A.4.3.1.4-11

The I-CSCF forwards the response to the S-CSCF.

Table A.4.3.1.4-11: 200 (OK) response to REFER (I-CSCF to S-CSCF)

SIP/2.0 200 OK

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

Record-Route:

P-Asserted-Identity:

P-Charging-Vector:

Privacy:

From:

To:

Call-ID:

CSeq:

Contact:

Content-Length:

12. 200 (OK) response to REFER (S-CSCF to MRFC/AS) – see example in table A.4.3.1.4-12

The S-CSCF forwards the response to the MRFC/AS.

Table A.4.3.1.4-12: 200 (OK) response to REFER (S-CSCF to MRFC/AS)

SIP/2.0 200 OK

Via: SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK23273846

Record-Route:

P-Asserted-Identity:

P-Charging-Vector:

Privacy:

From:

To:

Call-ID:

CSeq:

Contact:

Content-Length:

13. NOTIFY request (UE#2 to P-CSCF) – see example in table A.4.3.1.4-13

According to RFC 3515 [17], UE#2 creates a subscription and sends a notification of the status of the refer.

Table A.4.3.1.4-13: NOTIFY request (from UE#2 to P-CSCF)

NOTIFY sip:conference1@mrfc1.home1.net SIP/2.0

Via: SIP/2.0/UDP [5555::eee:fff:aaa:bbb]:8805;comp=sigcomp;branch=z9hG4bK23dh42.1

Max-Forwards: 70

Route: <sip:pcscf2.visited2.net:5088;lr>, <sip:scscf2.home2.net;lr>, <sip:scscf1.home1.net;lr>

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

To: <sip:conference1@mrfc1.home1.net >;tag=171828

From: <sip:user2_public1@home2.net>;tag=151170

Call-ID: cb03a0s09a2sdfglkj490333

CSeq: 42 NOTIFY

Subscription-State: active;expires:7200

Event: refer

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

Content-Length: (…)

Content-Type: message/sipfrag

SIP/2.0 100 Trying

14. NOTIFY request (from P-CSCF to S-CSCF) – see example in table A.4.3.1.4-14

The P-CSCF forwards the message to the S-CSCF.

Table: A.4.3.1.4-14: NOTIFY request (from P-CSCF to S-CSCF)

NOTIFY sip:conference1@mrfc1.home1.net SIP/2.0

Via: SIP/2.0/UDP pcscf2.visited2.net;branch=z9hG4bK234223.1, SIP/2.0/UDP [5555::eee:fff:aaa:bbb]:8805;comp=sigcomp;branch=z9hG4bK23dh42.1

Max-Forwards: 69

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

Record-Route: <sip:pcscf2.visited2.net;lr>

P-Access-Network-Info:

To:

From:

Call-ID:

CSeq:

Subscription-State:

Event:

Contact:

Content-Length: (…)

Content-Type:

(…)

15. NOTIFY request (from S-CSCF to S-CSCF – see example in table A.4.3.1.4-15

The S-CSCF forwards the message to the S-CSCF.

Table A.4.3.1.4-15: NOTIFY request (from S-CSCF to S-CSCF)

NOTIFY sip:conference1@mrfc1.home1.net SIP/2.0

Via: SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK764z87.1, SIP/2.0/UDP pcscf2.visited2.net;branch=z9hG4bK234223.1, SIP/2.0/UDP [5555::eee:fff:aaa:bbb]:8805;comp=sigcomp;branch=z9hG4bK23dh42.1

Max-Forwards: 68

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

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

To:

From:

Call-ID:

CSeq:

Subscription-State:

Event:

Contact:

Content-Length: (…)

Content-Type:

(…)

16. NOTIFY request (from S-CSCF to MRFC/AS- see example in table A.4.3.1.4-16

The S-CSCF forwards the message to the MRFC/AS.

Table A.4.3.1.4-16: NOTIFY request (from S-CSCF to MRFC/AS)

NOTIFY sip:conference1@mrfc1.home1.net SIP/2.0

Max-Forwards: 67

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

To:

From:

Call-ID:

CSeq:

Subscription-State:

Event:

Contact:

Content-Length: (…)

Content-Type:

(…)

17. 200 (OK) response (MRFC/AS to S-CSCF) – see example in table A.4.3.1.4-17

The MRFC/AS acknowledges the NOTIFY request with a 200 (OK) response to the S-CSCF.

Table A.4.3.1.4-17: 200 (OK) response (MRFC/AS to S-CSCF)

SIP/2.0 200 OK

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

From:

To:

Call-ID:

CSeq:

Content-Length: 0

18. 200 (OK) response (S-CSCF to S-CSCF) – see example in table A.4.3.1.4-18

The S-CSCF forwards the 200 (OK) response to the S-CSCF.

Table A.4.3.1.4-18: 200 (OK) response (S-CSCF to S-CSCF)

SIP/2.0 200 OK

Via: SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK764z87.1, SIP/2.0/UDP pcscf2.visited2.net;branch=z9hG4bK234223.1, SIP/2.0/UDP [5555::eee:fff:aaa:bbb]:8805;comp=sigcomp;branch=z9hG4bK23dh42.1

Record-Route:

From:

To:

Call-ID:

CSeq:

Content-Length:

19. 200 (OK) response (S-CSCF to P-CSCF) – see example in table A.4.3.1.4-19

The S-CSCF forwards the 200 (OK) response to the P-CSCF.

Table A.4.3.1.4-19: 200 (OK) response (S-CSCF to P-CSCF)

SIP/2.0 200 OK

Via: SIP/2.0/UDP pcscf2.visited2.net;branch=z9hG4bK234223.1, SIP/2.0/UDP [5555::eee:fff:aaa:bbb]:8805;comp=sigcomp;branch=z9hG4bK23dh42.1

Record-Route:

From:

To:

Call-ID:

CSeq:

Content-Length:

20. 200 (OK) response (P-CSCF to UE#2) – see example in table A.4.3.1.4-20

The P-CSCF forwards the 200 (OK) response to UE#2.

Table A.4.3.1.4-20: 200 (OK) response (P-CSCF to UE#2)

SIP/2.0 200 OK

Via: SIP/2.0/UDP [5555::eee:fff:aaa:bbb]:8805;comp=sigcomp;branch=z9hG4bK23dh42.1

Record-Route:

From:

To:

Call-ID:

CSeq:

Content-Length:

21. UE#2 joins the conference.

UE#2 joins the conference as described in subclause 5.3.1.4.

22. NOTIFY request (UE#2 to P-CSCF) – see example in table A.4.3.1.4-22

The P-CSCF receives a NOTIFY request from UE#2 indicating the status of the refer.

Table A.4.3.1.4-22: NOTIFY request (from UE#2 to P-CSCF)

NOTIFY sip:conference1@mrfc1.home1.net SIP/2.0

Via: SIP/2.0/UDP [5555::eee:fff:aaa:bbb]:8805;comp=sigcomp;branch=z9hG4bK23dh42.1

Max-Forwards: 70

Route: <sip:pcscf2.visited2.net:5088;lr>, <sip:scscf2.home2.net;lr>, <sip:scscf1.home1.net;lr>

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

To: <sip:conference1@mrfc1.home1.net >;tag=171828

From: <sip:user2_public1@home2.net>;tag=151170

Call-ID: cb03a0s09a2sdfglkj490333

CSeq: 42 NOTIFY

Subscription-State: terminated

Event: refer

Content-Length: (…)

Content-Type: message/sipfrag

SIP/2.0 200 OK

23. NOTIFY request (from P-CSCF to S-CSCF) – see example in table A.4.3.1.4-23

The P-CSCF forwards the message to the S-CSCF.

Table: A.4.3.1.4-23: NOTIFY request (from P-CSCF to S-CSCF)

NOTIFY sip:conference1@mrfc1.home1.net SIP/2.0

Via: SIP/2.0/UDP pcscf2.visited2.net;branch=z9hG4bK234223.1, SIP/2.0/UDP [5555::eee:fff:aaa:bbb]:8805;comp=sigcomp;branch=z9hG4bK23dh42.1

Max-Forwards: 69

P-Access-Network-Info:

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

Record-Route: <sip:pcscf2.visited2.net;lr>

To:

From:

Call-ID:

CSeq:

Subscription-State:

Event:

Content-Length: (…)

Content-Type:

(…)

24. NOTIFY request (from S-CSCF to S-CSCF – see example in table A.4.3.1.4-24

The S-CSCF forwards the message to the S-CSCF.

Table A.4.3.1.4-24: NOTIFY request (from S-CSCF to S-CSCF)

NOTIFY sip:conference1@mrfc1.home1.net SIP/2.0

Via: SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK764z87.1, SIP/2.0/UDP pcscf2.visited2.net;branch=z9hG4bK234223.1, SIP/2.0/UDP [5555::eee:fff:aaa:bbb]:8805;comp=sigcomp;branch=z9hG4bK23dh42.1

Max-Forwards: 68

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

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

To:

From:

Call-ID:

CSeq:

Subscription-State:

Event:

Content-Length: (…)

Content-Type:

(…)

25. NOTIFY request (from S-CSCF to MRFC/AS- see example in table A.4.3.1.4-25

The S-CSCF forwards the message to the MRFC/AS.

Table A.4.3.1.4-25: NOTIFY request (from S-CSCF to MRFC/AS)

NOTIFY sip:conference1@mrfc1.home1.net SIP/2.0

Max-Forwards: 67

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

To:

From:

Call-ID:

CSeq:

Subscription-State:

Event:

Content-Length: (…)

Content-Type:

(…)

26. 200 (OK) response (MRFC/AS to S-CSCF) – see example in table A.4.3.1.4-26

The MRFC/AS acknowledges the NOTIFY request with a 200 (OK) response to the S-CSCF.

Table A.4.3.1.4-26: 200 (OK) response (MRFC/AS to S-CSCF)

SIP/2.0 200 OK

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

From:

To:

Call-ID:

CSeq:

Content-Length: 0

27. 200 (OK) response (S-CSCF to S-CSCF) – see example in table A.4.3.1.4-27

The S-CSCF forwards the 200 (OK) response to the S-CSCF.

Table A.4.3.1.4-27: 200 (OK) response (S-CSCF to S-CSCF)

SIP/2.0 200 OK

Via: SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK764z87.1, SIP/2.0/UDP pcscf2.visited2.net;branch=z9hG4bK234223.1, SIP/2.0/UDP [5555::eee:fff:aaa:bbb]:8805;comp=sigcomp;branch=z9hG4bK23dh42.1

Record-Route:

From:

To:

Call-ID:

CSeq:

Content-Length:

28. 200 (OK) response (S-CSCF to P-CSCF) – see example in table A.4.3.1.4-28

The S-CSCF forwards the 200 (OK) response to the P-CSCF.

Table A.4.3.1.4-28: 200 (OK) response (S-CSCF to P-CSCF)

SIP/2.0 200 OK

Via: SIP/2.0/UDP pcscf2.visited2.net;branch=z9hG4bK234223.1, SIP/2.0/UDP [5555::eee:fff:aaa:bbb]:8805;comp=sigcomp;branch=z9hG4bK23dh42.1

Record-Route:

From:

To:

Call-ID:

CSeq:

Content-Length:

29. 200 (OK) response (P-CSCF to UE#2) – see example in table A.4.3.1.4-29

The P-CSCF forwards the 200 (OK) response to UE#2.

Table A.4.3.1.4-29: 200 (OK) response (P-CSCF to UE#2)

SIP/2.0 200 OK

Via: SIP/2.0/UDP [5555::eee:fff:aaa:bbb]:8805;comp=sigcomp;branch=z9hG4bK23dh42.1

Record-Route:

From:

To:

Call-ID:

CSeq:

Content-Length: