A.4 Signalling flows demonstrating session-based messaging

24.2473GPPMessaging service using the IP Multimedia (IM) Core Network (CN) subsystemRelease 17Stage 3TS

A.4.1 Introduction

This clause provides signalling flows for session-based messaging, established both with and without preconditions.

How the signalling flow for session-based messaging looks like depends on the following:

a) at what point in time the IP-CAN for the media component (MSRP) is set up; or

b) whether preconditions and reliable provisional responses are used or not.

A.4.2 Establishing a session for session-based messaging without preconditions

Figure A.4.2-1 shows the establishment of an MSRP session between two users without the usage of preconditions and reliable provisional responses as well as the first message being sent over the established connection.

It is assumed that both the originating UE and terminating UE are using an IP-CAN with a separate bearer for SIP signalling which means that each UE needs to reserve a new IP-CAN bearer for the message session media component prior to sending the first MSRP message.

Figure A.4.2-1: Establishment of MSRP session

The details of the signalling flows are as follows:

1. INVITE request (UE#1 to P-CSCF#1) – see example in table A.4.2-1

The originating UE wants to initiate a session-based message session with the terminating UE. The originating UE creates a local MSRP URL, which can be used for the communication between the two user agents. It builds a SDP Offer containing the generated MSRP URL and assigns a local port number for the MSRP communication.

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

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

Require: sec-agree

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>

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

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

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=message 2855 TCP/MSRP*

a=accept-types:message/cpim text/plain text/html

a=path:msrp://[5555::aaa:bbb:ccc:ddd]:2855/s111271;tcp

a=max-size:131072

a=msrp-cema

a=setup:active

SDP The SDP contains a set of content types supported by UE#1 and desired by the user at UE#1 for this session in the accept-types attribute and indicates the maximum size message that can be received by UE#1 in the max-size attribute.

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

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

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

SIP/2.0 100 Trying

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

From:

To:

Call-ID:

CSeq:

Content-Length: 0

3. INVITE request (P-CSCF#1 to S-CSCF#1) – see example in table A.4.2-3

The INVITE request is forwarded to the S-CSCF.

Table A.4.2-3: INVITE request (P-CSCF#1 to S-CSCF#1)

INVITE 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-Access-Network-Info:

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

Privacy:

From:

To:

Call-ID:

Cseq:

Supported:

Contact:

Allow:

Accept:

Content-Type:

Content-Length: (…)

v=

o=

s=

c=

t=

m=

a=

a=

a=

4. 100 (Trying) response (S-CSCF#1 to P-CSCF#1) – see example in table A.4.2-4

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

Table A.4.2-4: 100 (Trying) response (S-CSCF#1 to P-CSCF#1)

SIP/2.0 100 Trying

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

From:

To:

Call-ID:

CSeq:

Content-Length: 0

5. Evaluation of initial filter criteria

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

6. INVITE request (S-CSCF#1 to I-CSCF#2) – see example in table A.41-6

S-CSCF#1 forwards the INVITE request to the I-CSCF#2.

Table A.4.2-6: INVITE request (S-CSCF#1 to I-CSCF#2)

INVITE 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:+1-212-555-1111>

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

Privacy:

From:

To:

Call-ID:

Cseq:

Supported:

Contact:

Allow:

Accept:

Content-Type:

Content-Length: (…)

v=

o=

s=

c=

t=

m=

a=

a=

a=

7. 100 (Trying) response (I-CSCF#2 to S-CSCF#1) – see example in table A.4.2-7

I-CSCF#2 sends a 100 (Trying) response provisional response to S-CSCF#1.

Table A.4.2-7: 100 (Trying) response (I-CSCF#2 to S-CSCF#1)

SIP/2.0 100 Trying

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

From:

To:

Call-ID:

CSeq:

Content-Length: 0

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

9. INVITE request (I-CSCF#2 to S-CSCF#2) – see example in table A.4.2-9

I-CSCF#2 forwards the INVITE request to the S-CSCF#2 that will handle the session termination.

Table A.4.2-9: INVITE request (I-CSCF#2 to S-CSCF#2)

INVITE sip:user2_public1@home2.net SIP/2.0

Via: SIP/2.0/UDP icscf2_s.home2.net;branch=z9hG4bK871y12.1, SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.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:

Privacy:

From:

To:

Call-ID:

Cseq:

Supported:

Contact:

Allow:

Accept:

Content-Type:

Content-Length:

v=

o=

s=

c=

t=

m=

a=

a=

a=

10. 100 (Trying) response (S-CSCF#2 to I-CSCF#2) – see example in table A.4.2-10

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

Table A.4.2-10: 100 (Trying) response (S-CSCF#2 to I-CSCF#2)

SIP/2.0 100 Trying

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

From:

To:

Call-ID:

CSeq:

Content-Length: 0

11. Evaluation of initial filter criteria

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

12. INVITE request (S-CSCF#2 to P-CSCF#2) – see example in table A.4.2-12

S-CSCF#2 forwards the INVITE request, as determined by the termination procedure. S-CSCF#2 remembers (from the registration procedure) the UE Contact address and the next hop CSCF for this UE.

Table A.4.2-12: INVITE request (S-CSCF#2 to P-CSCF#2)

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

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

Max-Forwards: 66

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

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

P-Asserted-Identity:

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

Privacy:

From:

To:

Call-ID:

Cseq:

Supported:

Contact:

Allow:

Accept:

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

Content-Type:

Content-Length: (…)

v=

o=

s=

c=

t=

m=

a=

a=

a=

13. 100 (Trying) response (P-CSCF#2 to S-CSCF#2) – see example in table A.4.2-13

S-CSCF#2 receives a 100 (Trying) response provisional response to the INVITE request.

Table A.4.2-13: 100 (Trying) response (P-CSCF#2 to S-CSCF#2)

SIP/2.0 100 Trying

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

From:

To:

Call-ID:

CSeq:

Content-Length: 0

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

P-CSCF#2 forwards the INVITE request to the terminating UE.

Table A.4.2-14: INVITE request (P-CSCF#2 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=z9hG4bK361k21.1, SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK764z87.1, SIP/2.0/UDP icscf2_s.home2.net;branch=z9hG4bK871y12.1, SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.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:

Supported:

Contact:

Allow:

Accept:

P-Called-Party-ID:

Content-Type:

Content-Length: (…)

v=

o=

s=

c=

t=

m=

a=

a=

a=

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

The terminating UE sends a 100 (Trying) response provisional response to P-CSCF#2.

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

SIP/2.0 100 Trying

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

From:

To:

Call-ID:

CSeq:

Content-Length: 0

16. Reserve IP-CAN bearer for media

The terminating UE accepts the message session. The terminating UE reserves an IP-CAN bearer for the message session media component.

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

After reserving an IP-CAN bearer for the message session media component the terminating UE sends a 200 (OK) response for the INVITE request containing SDP that indicates that the terminating UE has accepted the message session and listens on the MSRP TCP port returned in the path attribute in the answer for a TCP SETUP from the originating UE.

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

SIP/2.0 200 OK

Via: SIP/2.0/UDP pcscf2.visited2.net:5088;comp=sigcomp;branch=z9hG4bK361k21.1, SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK764z87.1, SIP/2.0/UDP icscf2_s.home2.net;branch=z9hG4bK871y12.1, SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.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:5088;lr;comp=sigcomp>>, <sip:scscf2.home2.net;lr>, <sip:scscf1.home1.net;lr>, <sip:pcscf1.visited1.net;lr>

Privacy: none

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

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

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

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 127 INVITE

Supported: gruu

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

Content-Type: application/sdp

Content-Length: (…)

v=0

o=- 2987933615 2987933617 IN IP6 5555:: eee:fff:aaa:bbb

s=-

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

t=0 0

m=message 2855 TCP/MSRP *

a=accept-types:text/plain text/html message/cpim

a=path:msrp://[5555::eee:fff:aaa:bbb]:2855/s234167;tcp

a=max-size:65536

a=msrp-cema

a=setup:passive

SDP The SDP contains the set of offered content types supported by UE#2 and desired by the user at UE#2 for this session in the accept-types attribute and indicates the maximum size message that can be received by UE#2 in the max-size attribute.

18. 200 (OK) response (P-CSCF#2 to S-CSCF#2) – see example in table A.4.2-18

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

Table A.4.2-18: 200 (OK) response (P-CSCF#2 to S-CSCF#2)

SIP/2.0 200 OK

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

Record-Route:

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

Privacy:

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

P-Access-Network-Info:

From:

To:

Call-ID:

CSeq:

Supported:

Contact:

Allow:

Content-Type:

Content-Length:

v=

o=

s=

c=

t=

m=

a=

a=

a=

19. 200 (OK) response (S-CSCF#2 to I-CSCF#2) – see example in table A.4.2-19

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

Table A.4.2-19: 200 (OK) response (S-CSCF#2 to I-CSCF#2)

SIP/2.0 200 OK

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

Record-Route:

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

Privacy:

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"; 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]

From:

To:

Call-ID:

CSeq:

Supported:

Contact:

Allow:

Content-Type:

Content-Length:

v=

o=

s=

c=

t=

m=

a=

a=

a=

20. 200 (OK) response (I-CSCF#2 to S-CSCF#1) – see example in table A.4.2-20

I-CSCF#2 forwards the 200 (OK) response to S-CSCF#1.

Table A.4.2-20: 200 (OK) response (I-CSCF#2 to S-CSCF#1)

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:

Privacy: none

P-Charging-Vector:

From:

To:

Call-ID:

CSeq:

Supported:

Contact:

Allow:

Content-Type:

Content-Length:

v=

o=

s=

c=

t=

m=

a=

a=

a=

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

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

Table A.4.2-21: 200 (OK) response (S-CSCF#1 to P-CSCF#1)

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:

Privacy:

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

From:

To:

Call-ID:

CSeq:

Require:

Supported:

Contact:

Allow:

Content-Type:

Content-Length:

v=

o=

s=

c=

t=

m=

a=

a=

a=

22. 200 (OK) response (P-CSCF#1 to UE#1) – see example in table A.4.2-22

P-CSCF#1 forwards the 200 (OK) response to the originating UE.

Table A.4.2-22: 200 (OK) response (P-CSCF#1 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:

Require:

Supported:

Contact:

Allow:

Content-Type:

Content-Length:

v=

o=

s=

c=

t=

m=

a=

a=

a=

23. ACK request (UE#1 to P-CSCF#1) – see example in table A.4.2-23

The UE responds to the 200 (OK) response with an ACK request sent to the P-CSCF#1.

Table A.4.2-23: ACK request (UE#1 to P-CSCF#1)

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

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

Max-Forwards: 70

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

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

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

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

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 127 ACK

Content-Length: 0

24. ACK request (P-CSCF#1 to S-CSCF#1) – see example in table A.4.2-24

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

Table A.4.2-24: ACK request (P-CSCF#1 to S-CSCF#1)

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

P-Access-Network-Info:

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

From:

To:

Call-ID:

Cseq:

Content-Length:

25. ACK request (S-CSCF#1 to S-CSCF#2) – see example in table A.4.2-25

The S-CSCF#1 forwards the ACK request to the S-CSCF#2.

Table A.4.2-25: ACK request (S-CSCF#1 to S-CSCF#2)

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

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

From:

To:

Call-ID:

Cseq:

Content-Length:

26. ACK request (S-CSCF#2 to P-CSCF#2) – see example in table A.4.2-26

S-CSCF#1 forwards the ACK request to P-CSCF#2.

Table A.4.2-26: ACK request (S-CSCF#2 to P-CSCF#2)

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

Via: SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK764z87.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:pcscf2.visited2.net;lr>

From:

To:

Call-ID:

Cseq:

Content-Length:

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

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

Table A.4.2-27: ACK request (P-CSCF#2 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=z9hG4bK361k21.1, SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK764z87.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

From:

To:

Call-ID:

Cseq:

Content-Length:

28. Reserve IP-CAN bearer for media

The originating UE reserves an IP-CAN bearer for the message session media component.

29. TCP setup

The originating UE establishes a TCP connection using the IP-CAN bearers established in step 16 and step 28 to the host address and the port as specified in the MSRP URL received in the SDP Answer from the terminating UE.

30. MSRP SEND request (UE#1 to UE#2) – see example in table A.4.2-30

The originating UE sends the first message over the MSRP session with an MSRP SEND request using the established TCP connection.

Table A.4.2-30: MSRP SEND request (UE#1 to UE#2)

MSRP d93kswow SEND

To-path:msrp://[5555::eee:fff:aaa:bbb]: 3333/s234167;tcp

From-path:msrp://[5555::aaa:bbb:ccc:ddd]:2855/s111271;tcp

Message-ID: 8822

Byte-Range: 1-77/77

Content-Type: "text/plain"

those are my principles. If you don’t like them I have others – Groucho Marx.

——-d93kswow$

To-path: The sender’s remote path

From-path: The sender’s local URL

Message-ID: A unique message ID for MSRP message.

Byte-Range: The Byte Range for this message.

Content-Type: The format of the body of the request.

31. MSRP 200 (OK) response (UE#2 to UE#1) – see example in table A.4.2-31

The terminating UE acknowledges the reception of the MSRP SEND request with an MSRP 200 (OK) response using the established TCP connection.

Table A.4.2-31: MSRP 200 (OK) response (UE#2 to UE#1)

MSRP d93kswow 200 OK

To-path:msrp://[5555::aaa:bbb:ccc:ddd]:2855/s111271;tcp

From-path:msrp://[5555::eee:fff:aaa:bbb]:3333/s234167;tcp

——-d93kswow$

A.4.3 Establishing a session for session-based messaging with Intermediate Nodes

Figure A.4.3-1 shows the establishment of a MSRP session between two users with intermediate nodes being added to the signalling path as well as the first message being sent over the established connection.

It is assumed that both the originating UE and terminating UE are using an IP-CAN with a separate bearer for SIP signalling which means that each UE needs to reserve a new IP-CAN bearer for the message session media component.

This example is simplified, the MRFC and MRFP functions are shown as combined with AS#1 and AS#2 in this example.

Figure A.4.3-1: Establishment of MSRP session with Intermediate Nodes

The details of the signalling flows are as follows:

1. INVITE request (UE#1 to P-CSCF#1) – see example in table A.4.3-1

The originating UE#1 wants to initiate a session-based message session with the terminating UE#2. UE#1 creates a local MSRP URL, which can be used for the communication between the two user agents. It builds a SDP Offer containing the generated MSRP URL and assigns a local port number for the MSRP communication.

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

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

Require: sec-agree

Proxy-Require: sec-agree

Supported: gruu

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi=87654321; port1=7531

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

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

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

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=message 2855 TCP/MSRP *

a=accept-types:message/cpim text/plain text/html

a=path:msrp://[5555::aaa:bbb:ccc:ddd]:2855/s111271;tcp

a=max-size:131072

a=msrp-cema

a=setup:active

SDP The SDP contains the set of content types supported by UE#1 and desired by the user at UE#1 for this session in the accept-types attribute and indicates the maximum size message that can be received by UE#1 in the max-size attribute.

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

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

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

SIP/2.0 100 Trying

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

From:

To:

Call-ID:

CSeq:

Content-Length: 0

3. INVITE request (P-CSCF#1 to S-CSCF#1) – see example in table A.4.3-3

The INVITE request is forwarded to the S-CSCF.

Table A.4.3-3: INVITE request (P-CSCF#1 to S-CSCF#1)

INVITE 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-Access-Network-Info:

P-Charging-Vector: ####

Privacy:

From:

To:

Call-ID:

Cseq:

Supported:

Contact:

Allow:

Accept:

Content-Type:

Content-Length: (…)

v=

o=

s=

c=

t=

m=

a=

a=

a=

4. 100 (Trying) response (S-CSCF#1 to P-CSCF#1) – see example in table A.4.3-4

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

Table A.4.3-4: 100 (Trying) response (S-CSCF#1 to P-CSCF#1)

SIP/2.0 100 Trying

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

From:

To:

Call-ID:

CSeq:

Content-Length: 0

5. Evaluation of initial filter criteria

S-CSCF#1 validates the service profile of this subscriber and evaluates the initial filter criteria. For sip:user1_public1@home1.net S-CSCF#1 has origination initial filter criteria with service points of interest of Method = INVITE request and SDP m= ‘message’ and ‘msrp’ protocol that informs the S-CSCF to route the INVITE request to the AS sip:as1.home1.net.

6. INVITE request (S-CSCF#1 to AS#1) – see example in table A.4.3-6

S-CSCF#1 forwards the INVITE request to the AS#1.

Table A.4.3-6: INVITE request (S-CSCF#1 to AS#1)

INVITE sip:user2_public1@home2.net SIP/2.0

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK344a65.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

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

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

P-Asserted-Identity: "John Doe" <sip:user1_public1@home1.net>, <tel:+1-212-555-1111>

P-Access-Network-Info:

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

Privacy:

From:

To:

Call-ID:

Cseq:

Supported:

Contact:

Allow:

Accept:

Content-Type:

Content-Length: (…)

v=

o=

s=

c=

t=

m=

a=

a=

a=

7. 100 (Trying) response (AS#1 to S-CSCF#1) – see example in table A.4.3-7

AS#1 sends a 100 (Trying) response provisional response to S-CSCF#1.

Table A.4.3-7: 100 (Trying) response (AS#1 to S-CSCF#1)

SIP/2.0 100 Trying

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK344a65.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

From:

To:

Call-ID:

CSeq:

Content-Length: 0

AS#1 establishes a TCP connection using the IP-CAN bearers established in step 1 to the host address and port as specified in the MSRP URL received in the SDP Offer from the originating UE#1.

8. INVITE request (AS#1 to S-CSCF#1) – see example in table A.4.3-8

AS#1 sends a new INVITE request to the S-CSCF#1 with the session attribute containing a unique URL for the AS#1 to receive media on.

Table A.4.3-8: INVITE request (AS#1 to S-CSCF#1)

INVITE sip:user2_public1@home2.net SIP/2.0

Via: SIP/2.0/UDP as1.home1.net;branch=z9hG4bK240f34.1

Max-Forwards: 70

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

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

P-Asserted-Identity: "John Doe" <sip:user1_public1@home1.net>, <tel:+1-212-555-1111>

P-Charging-Vector: ####

Privacy: none

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

To: <sip:user2_public1@home2.net>

Call-ID: s09a233cbsdfglkj490303a0

Cseq: 278 INVITE

Supported:

Contact:

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

Accept:

Content-Type: application/sdp

Content-Length: (…)

v=0

o=- 2987933620 2987933620 IN IP6 7777::eee:ddd:ccc:aaa

s=-

c=IN IP6 7777::eee:ddd:ccc:aaa

t=0 0

m=message 3927 TCP/MSRP *

a=accept-types:message/cpim text/plain text/html

a=path:msrp://[7777::eee:ddd:ccc:aaa]:3927/s222371;tcp

a=max-size:65536

a=msrp-cema

a=setup:active

Record-Route The AS#1 includes a Record-Route header containing its SIP URI.

SDP The SDP contains the set of offered content types allowed by the policy of network home1 in the accept-types attribute and indicates the maximum size message that can be received by UE#1 and allowed by the policy of network home1 in the max-size attribute.

9. 100 (Trying) response (S-CSCF#1 to AS#1) – see example in table A.4.3-9

S-CSCF#1 sends a 100 (Trying) response provisional response to AS#1.

Table A.4.3-9: 100 (Trying) response (S-CSCF#1 to AS#1)

SIP/2.0 100 Trying

Via: SIP/2.0/UDP as1.home1.net;branch=z9hG4bK240f34.1

From:

To:

Call-ID:

CSeq:

Content-Length: 0

10. INVITE request (S-CSCF#1 to I-CSCF#2) – see example in table A.4.3-10

S-CSCF#1 forwards the INVITE request to the I-CSCF#2. As the S-CSCF#1 does not know whether the I-CSCF at home2.net is a loose router or not, it does not introduce a Route header.

Table A.4.3-10: INVITE request (S-CSCF#1 to I-CSCF#2)

INVITE sip:user2_public1@home2.net SIP/2.0

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

Max-Forwards: 69

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

P-Asserted-Identity:

P-Charging-Vector: ####

Privacy:

From:

To:

Call-ID:

Cseq:

Supported:

Contact:

Allow:

Accept:

Content-Type:

Content-Length:

v=

o=

s=

c=

t=

m=

a=

a=

11. 100 (Trying) response (I-CSCF#2 to S-CSCF#1) – see example in table A.4.3-11

I-CSCF#2 sends a 100 (Trying) response provisional response to S-CSCF#1.

Table A.4.3-11: 100 (Trying) response (I-CSCF#1 to S-CSCF#1)

SIP/2.0 100 Trying

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

From:

To:

Call-ID:

CSeq:

Content-Length: 0

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

13. INVITE request (I-CSCF#2 to S-CSCF#2) – see example in table A.4.3-13

I-CSCF#2 forwards the INVITE request to the S-CSCF#2 that will handle the session termination.

Table A.4.3-13: INVITE request (I-CSCF#2 to S-CSCF#2)

INVITE sip:user2_public1@home2.net SIP/2.0

Via: SIP/2.0/UDP icscf2_s.home2.net;branch=z9hG4bK871y12.1, SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP as1.home1.net;branch=z9hG4bK240f34.1

Max-Forwards: 68

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

Record-Route:

P-Asserted-Identity:

P-Charging-Vector:

Privacy:

From:

To:

Call-ID:

Cseq:

Supported:

Contact:

Allow:

Accept:

Content-Type:

Content-Length:

v=

o=

s=

c=

t=

m=

a=

a=

a=

NOTE: The I-CSCF does not add itself to the Record-Route header, as it has no need to remain in the signalling path once the session is established.

14. 100 (Trying) response (S-CSCF#2 to I-CSCF#2) – see example in table A.4.3-14

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

Table A.4.3-14: 100 (Trying) response (S-CSCF#2 to I-CSCF#2)

SIP/2.0 100 Trying

Via: SIP/2.0/UDP icscf2_s.home2.net;branch=z9hG4bK871y12.1, SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP as1.home1.net;branch=z9hG4bK240f34.1

From:

To:

Call-ID:

CSeq:

Content-Length: 0

15. Evaluation of initial filter criteria

S-CSCF#2 validates the service profile of this subscriber and evaluates the initial filter criteria. For sip:user2_public1@home2.net S-CSCF#2 has termination initial filter criteria with service points of interest of Method = INVITE request and SDP m = ‘message’ and ‘msrp’ protocol that informs the S-CSCF to route the INVITE request to the AS sip:as2.home2.net.

16. INVITE request (S-CSCF#2 to AS#2) – see example in table A.4.3-16

S-CSCF#2 forwards the INVITE request to AS#2

Table A.4.3-16: INVITE request (S-CSCF#2 to AS#2)

INVITE sip:user2_public1@home2.net SIP/2.0

Via: SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK764z87.1, SIP/2.0/UDP icscf2_s.home2.net;branch=z9hG4bK871y12.1, SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP as1.home1.net;branch=z9hG4bK240f34.1

Max-Forwards: 67

Route: <sip:as2.home2.net;lr>,<sip:s09a233cbsdfglkj490303a0@scscf2.home2.net;lr>

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

P-Asserted-Identity:

P-Charging-Vector:

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

Privacy:

From:

To:

Call-ID:

Cseq:

Supported:

Contact:

Allow:

Accept:

Content-Type:

Content-Length: (…)

v=

o=

s=

c=

t=

m=

a=

a=

a=

17. 100 (Trying) response (AS#2 to S-CSCF#2) – see example in table A.4.3-17

S-CSCF#2 receives a 100 (Trying) response provisional response to the INVITE request.

Table A.4.3-17: 100 (Trying) response (AS#2 to S-CSCF#2)

SIP/2.0 100 Trying

Via: SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK764z87.1, SIP/2.0/UDP icscf2_s.home2.net;branch=z9hG4bK871y12.1, SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP as1.home1.net;branch=z9hG4bK240f34.1

From:

To:

Call-ID:

CSeq:

Content-Length: 0

18. INVITE request (AS#2 to S-CSCF#2) – see example in table A.4.3-18

AS#2 sends a new INVITE request to the S-CSCF#2 with the session attribute containing a unique URL for the AS#2 to receive media on.

Table A.4.3-18: INVITE request (AS#2 to S-CSCF#2)

INVITE sip:user2_public1@home2.net SIP/2.0

Via: SIP/2.0/UDP as2.home2.net;branch=z9hG4bK348923.1

Max-Forwards: 70

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

Record-Route: <sip:as2.home2.net;lr>

P-Asserted-Identity:

P-Charging-Vector: ####

Privacy: none

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

To: <sip:user2_public1@home2.net>

Call-ID: 0s09glkj4903a2sdf33cb03a

Cseq: 210 INVITE

Supported:

Contact:

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

Accept:

Content-Type: application/sdp

Content-Length: (…)

v=0

o=- 2987933630 2987933630 IN IP6 9999::ccc:aaa:bbb:ddd

s=-

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

t=0 0

m=message 3333 TCP/MSRP *

a=accept-types:message/cpim text/plain text/html

a=path:msrp://[9999::ccc:aaa:bbb:ddd]:3333/s317121;tcp

a=max-size:32768

a=msrp-cema

a=setup:active

Record-Route The AS#1 includes a Record-Route header containing its SIP URI.

SDP The SDP contains the set of offered content types allowed by the policy of network home2 in the accept-types attribute and indicates the maximum size message that can be received by UE#1 and allowed by the policy of network home2 in the max-size attribute.

19. 100 (Trying) response (S-CSCF#2 to AS#2) – see example in table A.4.3-19

S-CSCF#2 receives a 100 (Trying) response provisional response to the INVITE request.

Table A.4.3-19: 100 (Trying) response (S-CSCF#2 to AS#2)

SIP/2.0 100 Trying

Via: SIP/2.0/UDP as2.home2.net;branch=z9hG4bK348923.1

From:

To:

Call-ID:

CSeq:

Content-Length: 0

20. INVITE request (S-CSCF#2 to P-CSCF#2) – see example in table A.4.3-20

S-CSCF#2 forwards the INVITE request, as determined by the termination procedure. S-CSCF#2 remembers (from the registration procedure) the UE Contact address and the next hop CSCF for this UE.

Table A.4.3-20: INVITE request (S-CSCF#2 to P-CSCF#2)

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

Via: SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK764z87.1, SIP/2.0/UDP as2.home2.net;branch=z9hG4bK348923.1

Max-Forwards: 69

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

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

P-Asserted-Identity:

P-Charging-Vector:

Privacy:

From:

To:

Call-ID:

Cseq:

Supported:

Contact:

Allow:

Accept:

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

Content-Type:

Content-Length: (…)

v=

o=

s=

c=

t=

m=

a=

a=

a=

21. 100 (Trying) response (P-CSCF#2 to S-CSCF#2) – see example in table A.4.3-21

S-CSCF#2 receives a 100 (Trying) response provisional response to the INVITE request.

Table A.4.3-21: 100 (Trying) response (P-CSCF#2 to S-CSCF#2)

SIP/2.0 100 Trying

Via: SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK764z87.1, SIP/2.0/UDP as2.home2.net;branch=z9hG4bK348923.1

From:

To:

Call-ID:

CSeq:

Content-Length: 0

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

P-CSCF#2 forwards the INVITE request to the terminating UE.

Table A.4.3-22: INVITE request (P-CSCF#2 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=z9hG4bK361k21.1, SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK764z87.1, SIP/2.0/UDP as2.home2.net;branch=z9hG4bK348923.1

Max-Forwards: 68

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

P-Asserted-Identity:

Privacy:

From:

To:

Call-ID:

Cseq:

Supported:

Contact:

Allow:

Accept:

P-Called-Party-ID:

Content-Type:

Content-Length: (…)

v=

o=

s=

c=

t=

m=

a=

a=

a=

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

UE#2 sends a 100 (Trying) response provisional response to P-CSCF#2.

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

SIP/2.0 100 Trying

Via: SIP/2.0/UDP pcscf2.visited2.net:5088;comp=sigcomp;branch=z9hG4bK361k21.1, SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK764z87.1, SIP/2.0/UDP as2.home2.net;branch=z9hG4bK348923.1

From:

To:

Call-ID:

CSeq:

Content-Length: 0

24. Reserve IP-CAN bearer for media

The terminating UE#2 accepts the message session and. UE#2 reserves an IP-CAN bearer for the message session media component.

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

After reserving an IP-CAN bearer for the message session media component, the terminating UE#2 sends a 200 (OK) response for the INVITE request containing SDP that indicates that UE#2 has accepted the message session and listens on the MSRP TCP port returned in the path attribute in the answer for a TCP SETUP from AS#2.

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

SIP/2.0 200 OK

Via: SIP/2.0/UDP pcscf2.visited2.net:5088;comp=sigcomp;branch=z9hG4bK361k21.1, SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK764z87.1, SIP/2.0/UDP as2.home2.net;branch=z9hG4bK348923.1

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

Privacy: none

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

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

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

Call-ID: 0s09glkj4903a2sdf33cb03a

Cseq: 210 INVITE

Supported: gruu

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

Content-Type: application/sdp

Content-Length: (…)

v=0

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

s=-

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

t=0 0

m=message 2855 TCP/MSRP *

a=accept-types:text/plain text/html message/cpim

a=path:msrp://[5555::eee:fff:aaa:bbb]:2855/s417121;tcp

a=max-size:65536

a=msrp-cema

a=setup:passive

SDP The SDP contains the set of offered content types supported by UE#2 and desired by the user at UE#2 for this session in the accept-types attribute and indicates the maximum size message that can be received by UE#2 in the max-size attribute.

26. 200 (OK) response (P-CSCF#2 to S-CSCF#2) – see example in table A.4.3-26

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

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

SIP/2.0 200 OK

Via: SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK764z87.1, SIP/2.0/UDP as2.home2.net;branch=z9hG4bK348923.1

Record-Route:

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

Privacy:

P-Charging-Vector: ####

P-Access-Network-Info:

From:

To:

Call-ID:

CSeq:

Supported:

Contact:

Allow:

Content-Type:

Content-Length:

v=

o=

s=

c=

t=

m=

a=

a=

a=

27. 200 (OK) response (S-CSCF#2 to AS#2) – see example in table A.4.3-27

S-CSCF#2 forwards the 200 (OK) response to AS#2.

Table A.4.3-27: 200 (OK) response (S-CSCF#2 to AS#2)

SIP/2.0 200 OK

Via: SIP/2.0/UDP as2.home2.net;branch=z9hG4bK348923.1

Record-Route:

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

Privacy:

P-Charging-Vector: ####

From:

To:

Call-ID:

CSeq:

Supported:

Contact:

Allow:

Content-Type:

Content-Length:

v=

o=

s=

c=

t=

m=

a=

a=

a=

28. ACK request (AS#2 to S-CSCF#2) – see example in table A.4.3-28

AS#2 generates a new ACK request and sends it to S-CSCF#2.

Table A.4.3-28: ACK request (AS#2 to S-CSCF#2)

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

Via: SIP/2.0/UDP as2.home2.net;branch=z9hG4bK348923.1

Max-Forwards: 70

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

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

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

Call-ID: 0s09glkj4903a2sdf33cb03a

Cseq: 210 ACK

Content-Length: 0

29. ACK request (S-CSCF#2 to P-CSCF#2) – see example in table A.4.3-29

S-CSCF#1 forwards the ACK request to P-CSCF#2.

Table A.4.3-29: ACK request (S-CSCF#2 to P-CSCF#2)

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

Via: SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK764z87.1, SIP/2.0/UDP as2.home2.net;branch=z9hG4bK348923.1

Max-Forwards: 69

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

From:

To:

Call-ID:

Cseq:

Content-Length:

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

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

Table A.4.3-30: ACK request (P-CSCF#2 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=z9hG4bK361k21.1, SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK764z87.1, SIP/2.0/UDP as2.home2.net;branch=z9hG4bK348923.1

Max-Forwards: 68

From:

To:

Call-ID:

Cseq:

Content-Length:

31. TCP setup

AS#2 establishes a TCP connection using the IP-CAN bearers established in step 24 to the host address and port as specified in the MSRP URL received in the SDP Answer from UE#2.

32. 200 (OK) response (AS#2 to S-CSCF#2) – see example in table A.4.3-32

AS#2 generates a 200 (OK) response to S-CSCF#2.

Table A.4.3-32: 200 (OK) response (AS#2 to S-CSCF#2)

SIP/2.0 200 OK

Via: SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK764z87.1, SIP/2.0/UDP icscf2_s.home2.net;branch=z9hG4bK871y12.1, SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP as1.home1.net;branch=z9hG4bK240f34.1

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

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

Privacy:

P-Charging-Vector: ####

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

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

Call-ID: s09a233cbsdfglkj490303a0

CSeq: 278 INVITE

Supported: gruu

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

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

Content-Type: application/sdp

Content-Length: (…)

v=0

o=- 2987933640 2987933640 IN IP6 9999::ccc:aaa:bbb:ddd

s=-

c=IN IP6 9999::ccc:aaa:bbb:dddt=0 0

m=message 2855 TCP/MSRP *

a=accept-types:message/cpim text/plain text/html

a=path:msrp://[9999::ccc:aaa:bbb:ddd]:2855/s317122;tcp

a=max-size:32768

a=msrp-cema

a=setup:passive

SDP The SDP contains the set of answered content types supported by UE#2 in the accept-types attribute and indicates the maximum size message that can be received by UE#2 and allowed by the policy of network home2 in the max-size attribute.

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

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

Table A.4.3-33: 200 (OK) response (S-CSCF#2 to I-CSCF#2)

SIP/2.0 200 OK

Via: SIP/2.0/UDP icscf2_s.home2.net;branch=z9hG4bK871y12.1, SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP as1.home1.net;branch=z9hG4bK240f34.1

Record-Route:

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

Privacy:

P-Charging-Vector: ####

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

From:

To:

Call-ID:

CSeq:

Supported

Contact:

Allow:

Content-Type:

Content-Length:

v=

o=

s=

c=

t=

m=

a=

a=

a=

34. 200 (OK) response (I-CSCF#2 to S-CSCF#1) – see example in table A.4.3-34

I-CSCF#2 forwards the 200 (OK) response to S-CSCF#1.

Table A.4.3-34: 200 (OK) response (I-CSCF#2 to S-CSCF#1)

SIP/2.0 200 OK

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

Record-Route:

P-Asserted-Identity:

Privacy: none

P-Charging-Vector:

From:

To:

Call-ID:

CSeq:

Supported:

Contact:

Allow:

Content-Type:

Content-Length:

v=

o=

s=

c=

t=

m=

a=

a=

a=

35. 200 (OK) response (S-CSCF#1 to AS#1) – see example in table A.4.3-35

S-CSCF#1 forwards the 200 (OK) response to AS#1.

Table A.4.3-35: 200 (OK) response (S-CSCF#1 to AS#1)

SIP/2.0 200 OK

Via: SIP/2.0/UDP as1.home1.net;branch=z9hG4bK240f34.1

Record-Route:

P-Asserted-Identity:

Privacy:

P-Charging-Vector:

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

From:

To:

Call-ID:

CSeq:

Supported:

Contact:

Allow:

Content-Type:

Content-Length:

v=

o=

s=

c=

t=

m=

a=

a=

a=

36. ACK request (AS#1 to S-CSCF#1) – see example in table A.4.3-36

AS#1 generates an ACK request and sends it to S-CSCF#1.

Table A.4.3-36: ACK request (AS#1 to S-CSCF#1)

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

Via: SIP/2.0/UDP as1.home1.net;branch=z9hG4bK240f34.1

Max-Forwards: 70

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

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

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

Call-ID: s09a233cbsdfglkj490303a0

Cseq: 278 ACK

Content-Length: 0

37. ACK request (S-CSCF#1 to S-CSCF#2) – see example in table A.4.3-37

The S-CSCF#1 forwards the ACK request to S-CSCF#2.

Table A.4.3-37: ACK request (S-CSCF#1 to S-CSCF#2)

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

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK344a65.1, SIP/2.0/UDP as1.home1.net;branch= z9hG4bK240f34.1

Max-Forwards: 69

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

From:

To:

Call-ID:

Cseq:

Content-Length:

38. ACK request (S-CSCF#2 to AS#2) – see example in table A.4.3-38

The S-CSCF#2 forwards the ACK request to the AS#2.

Table A.4.3-38: ACK request (S-CSCF#2 to AS#2)

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

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK344a65.1, SIP/2.0/UDP as1.home1.net;branch=z9hG4bK240f34.1

Max-Forwards: 68

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

From:

To:

Call-ID:

Cseq:

Content-Length:

39. TCP setup

AS#1 establishes a TCP connection to the host address and port as specified in the MSRP URL received in the SDP Answer from the AS#2.

40. 200 (OK) response (AS#1 to S-CSCF#1) – see example in table A.4.3-40

AS#1 generates a 200 (OK) response and sends it to S-CSCF#1.

Table A.4.3-40: 200 (OK) response (AS#1 to S-CSCF#1)

SIP/2.0 200 OK

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK344a65.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:as1.home1.net;lr>, <sip:scscf1.home1.net;lr>, <sip:pcscf1.visited1.net;lr>

P-Asserted-Identity:

Privacy:

P-Charging-Vector: ####

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

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

Call-ID: cb03a0s09a2sdfglkj490333

CSeq: 127 INVITE

Supported

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

Allow:

Content-Type:

Content-Length:

v=0

o=- 2987933642 2987933642 IN IP6 7777::eee:ddd:ccc:aaa

s=-

c=IN IP6 7777::eee:ddd:ccc:aaa

t=0 0

m=message 3927 TCP/MSRP *

a=accept-types:message/cpim text/plain text/html

a=path:msrp://[7777::eee:ddd:ccc:aaa]:3927/s222372;tcp

a=max-size:32768

a=msrp-cema

a=setup:passive

SDP The SDP contains the set of answered content types supported by UE#2 in the accept-types attribute and indicates the maximum size message that can be received by UE#2 and allowed by the policy of network home1 in the max-size attribute.

41. 200 (OK) response (S-CSCF#1 to P-CSCF#1) – see example in table A.4.3-41

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

Table A.4.3-41: 200 (OK) response (S-CSCF#1 to P-CSCF#1)

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:

Privacy:

P-Charging-Vector: ####

From:

To:

Call-ID:

CSeq:

Require:

Supported

Contact:

Allow:

Content-Type:

Content-Length:

v=

o=

s=

c=

t=

m=

a=

a=

a=

42. 200 (OK) response (P-CSCF#1 to UE#1) – see example in table A.4.3-42

P-CSCF#1 forwards the 200 (OK) response to UE#1

Table A.4.3-42: 200 (OK) response (P-CSCF#1 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:as1.home1.net;lr>, <sip:scscf1.home1.net;lr>, <sip:pcscf1.visited1.net:7531;lr;comp=sigcomp>

P-Asserted-Identity:

Privacy:

From:

To:

Call-ID:

CSeq:

Require:

Supported

Contact:

Allow:

Content-Type:

Content-Length:

v=

o=

s=

c=

t=

m=

a=

a=

a=

43. ACK request (UE#1 to P-CSCF#1) – see example in table A.4.3-43

The UE responds to the 200 (OK) response with an ACK request sent to the P-CSCF#1.

Table A.4.3-43: ACK request (UE#1 to P-CSCF#1)

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

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

Max-Forwards: 70

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

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

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

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

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 127 ACK

Content-Length: 0

44. ACK request (P-CSCF#1 to S-CSCF#1) – see example in table A.4.3-44

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

Table A.4.3-44: ACK request (P-CSCF#1 to S-CSCF#1)

ACK sip:user2_public1@home2.net;gr=urn:uuid:2ad8950e-48a5-4a74-8d99-ad76cc7fc74 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

P-Access-Network-Info:

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

From:

To:

Call-ID:

Cseq:

Content-Length:

45. ACK request (S-CSCF#1 to AS#1) – see example in table A.4.3-45

The S-CSCF#1 forwards the ACK request to AS#1.

Table A.4.3-45: ACK request (S-CSCF#1 to AS#1)

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

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK344a65.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

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

From:

To:

Call-ID:

Cseq:

Content-Length:

46. Reserve IP-CAN bearer for media

UE#1 reserves an IP-CAN bearer for the message session media component.

47. TCP setup

Originating UE#1 establishes a TCP connection using the IP-CAN bearers established in step 46 to the host address and port as specified in the MSRP URL received in the SDP Answer from AS#1.

48. MSRP SEND (UE#1 to AS#1) – see example in table A.4.3-48

The originating UE sends the first message over the MSRP session with a MSRP SEND request using the established TCP connection.

Table A.4.3-48: MSRP SEND (UE#1 to AS#1)

MSRP 34kjf94 SEND

To-path:msrp://[7777::eee:ddd:ccc:aaa]:3927/s222372;tcp

From-path:msrp://[5555::aaa:bbb:ccc:ddd]:2855/s111271;tcp

Message-ID: 8822

Byte-Range: 1-89/89

Content-Type: "text/plain"

I will never be a member of a club that accepts people like me as members – Groucho Marx.

——-34kjf94$

To-path: The sender’s remote path.

From-path: The sender’s local URL.

Message-ID: A unique message ID for MSRP message.

Byte-Range: The Byte Range for this message.

Content-Type: The format of the body of the request.

49. MSRP SEND (AS#1 to AS#2) – see example in table A.4.3-49

AS#1 forwards the first MSRP SEND request to AS#2 over the MSRP session using the established TCP connection.

Table A.4.3-49: MSRP SEND (AS#1 to AS#2)

MSRP shfsoi3 SEND

To-path:msrp://[9999::ccc:aaa:bbb:ddd]:3333/s317122;tcp

From-path:msrp://[7777::eee:ddd:ccc:aaa]:3927/s222371;tcp

Message-ID: 2832

Byte-Range: 1-89/89

Content-Type: "text/plain"

I will never be a member of a club that accepts people like me as members – Groucho Marx.

——-shfsoi3$

To-path: The sender’s remote path.

From-path: The sender’s local URL.

Message-ID: A unique message ID for MSRP message.

Byte-Range: The Byte Range for this message.

Content-Type: The format of the body of the request.

50. MSRP SEND (AS#2 to UE#2) – see example in table A.4.3-50

AS#2 forwards the first MSRP SEND request to UE#2 over the MSRP session using the established TCP connection.

Table A.4.3-50: MSRP SEND (AS#2 to UE#2)

MSRP 2oid4sf SEND

To-path:msrp://[5555::eee:fff:aaa:bbb]:3335/s417121;tcp

From-path:msrp://[9999::ccc:aaa:bbb:ddd]:3333/s317121;tcp

Message-ID: 3311

Byte-Range: 1-89/89

Content-Type: "text/plain"

I will never be a member of a club that accepts people like me as members – Groucho Marx.

——-2oid4sf$

To-path: The sender’s remote path.

From-path: The sender’s local URL.

Message-ID: A unique message ID for MSRP message.

Byte-Range: The Byte Range for this message.

Content-Type: The format of the body of the request.

51. MSRP 200 (OK) response (UE#2 to AS#2) – see example in table A.4.3-51

The receiving UE#2 acknowledges the reception of the MSRP SEND request with a MSRP 200 (OK) response sent using the established TCP connection.

Table A.4.3-51: MSRP 200 (OK) response (UE#2 to AS#2)

MSRP 2oid4sf 200 OK

To-path:msrp://[9999::ccc:aaa:bbb:ddd]:3333/s317121;tcp

From-path:msrp://[5555::eee:fff:aaa:bbb]:3335/s417121;tcp

——–2oid4sf2j32ri3$

52. MSRP 200 (OK) response (AS#2 to AS#1) – see example in table A.4.3-52

AS#2 acknowledges the reception of the MSRP SEND request with a MSRP 200 (OK) response to AS#1 using the established TCP connection.

Table A.4.3-52: MSRP 200 (OK) response (AS#2 to AS#1)

MSRP shfsoi3 200 OK

To-path:msrp://[7777::eee:ddd:ccc:aaa]:3927/s222371;tcp

From-path:msrp://[9999::ccc:aaa:bbb:ddd]:3333/s317122;tcp

——-hfsoi3$

53. MSRP 200 (OK) response (AS#1 to UE#1) – see example in table A.4.3-53

AS#1 acknowledges the reception of the MSRP SEND request with a MSRP 200 (OK) response to UE#1 sent using the established TCP connection.

Table A.4.3-53: MSRP 200 (OK) response (AS#1 to UE#1)

MSRP 34kjf94 200 OK

To-path:msrp://[555::aaa:bbb:ccc:ddd]:2855/s111271;tcp

From-path:msrp://[7777::eee:ddd:ccc:aaa]:3927/s222372;tcp

——-34kjf94$

A.4.4 Establishing a session for session-based messaging with preconditions

This signalling flow is not provided as it is the same as the session establishment flows with preconditions in 3GPP TS 24.228 [4] except that the SDP contents are for setting up MSRP sessions over TCP rather than RTP sessions over UDP.