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.