A.3 Flows demonstrating the creation of a conference
24.1473GPPConferencing using the IP Multimedia (IM) Core Network (CN) subsystemRelease 17Stage 3TS
A.3.1 Introduction
Clause A.3 covers the flows that show how a user can create conferences at a MRFC/AS.
A.3.2 User automatically creating a conference with a conference factory URI
A.3.2.1 MRFC/AS is located in user’s home network
Figure A.3.2.1-1: User automatically creating a conference with a conference factory URI – MRFC/AS is located in user’s home network
Figure A.3.2.1-1 shows an user creating a conference by using a conference-factory URI. The conference is created at a MRFC/AS of the users home network.
The details of the flows are as follows:
1. INVITE request (UE to P-CSCF) – see example in table A.3.2.1-1
A UE wants to create a conference. For this purpose the UE is aware of a conference-factory URI that was obtained by means outside the present document (e.g. due to pre-configuration or via other protocols, such as http).
The UE determines the complete set of codecs that it is capable of supporting for this conference. It builds a SDP Offer containing bandwidth requirements and characteristics of each, and assigns local port numbers for each possible media flow. Multiple media flows may be offered, and for each media flow (m= line in SDP), there may be multiple codec choices offered.
For this example, it is assumed that UE#1 is willing to establish a multimedia session comprising a video stream and an audio stream. The video stream supports two codecs, either H.263 or MPEG-4 Visual. The audio stream supports the AMR codec. The UE sends the INVITE request to the P-CSCF.
The UE indicates that it supports precondition and it indicates that it supports reliable provisional responses. However, it does not use the "Require” header for these capabilities.
The UE does not have available the resources that are necessary to transport the media.
For this example it is assumed, that signalling encryption was negotiated between UE and P‑CSCF in the security mode set-up procedure during the last successful authentication. This option will only be shown in this example.
Table A.3.2.1-1: INVITE request (UE to P-CSCF)
INVITE sip:conference-factory1@mrfc1.home1.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:conference-factory1@mrfc1.home1.net>
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 127 INVITE
Require: sec-agree
Proxy-Require: sec-agree
Supported: precondition, 100rel, gruu, 199
Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi-c=98765432; spi-s=87654321; port-c=8642; port-s=7531
Contact: <sip:user1_public1@home1.net; gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 ;comp=sigcomp>
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY
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=video 3400 RTP/AVP 98 99
b=AS:75
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos none remote sendrecv
a=inactive
a=rtpmap:98 H263
a=fmtp:98 profile-level-id=0
a=rtpmap:99:MPVMP4V-ES
m=audio 3456 RTP/AVP 97 96
b=AS:25.4
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos none remote sendrecv
a=inactive
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; maxframes=2
a=rtpmap:96 telephone-event
Request-URI: contains the conference factory URI.
2. 100 (Trying) response (P-CSCF to UE) – see example in table A.3.2.1-2
The P-CSCF responds to the INVITE request (1) with a 100 (Trying) provisional response.
Table A.3.2.1-2: 100 (Trying) response (P-CSCF to UE)
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 to S-CSCF) – see example in table A.3.2.1-3
The P-CSCF forwards the INVITE request to the S-CSCF.
Table A.3.2.1-3: INVITE request (P-CSCF to S-CSCF)
INVITE sip:conference-factory1@mrfc1.home1.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=
b=
a=
a=
a=
a=
a=
a=
a=
a=
m=
b=
a=
a=
a=
a=
a=
a=
a=
a=
4. 100 (Trying) response (S-CSCF to P-CSCF) – see example in table A.3.2.1-4
The S-CSCF responds to the INVITE request (3) with a 100 (Trying) provisional response.
Table A.3.2.1-4: 100 (Trying) response (S-CSCF to P-CSCF)
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
The S-CSCF validates the service profile of this subscriber and evaluates the initial filter criteria.
6. INVITE request (S-CSCF to MRFC/AS) – see example in table A.3.2.1-6
The S-CSCF forwards the INVITE request to the MRFC/AS that is indicated in the host part of the Request URI. The S-CSCF does not re-write the Request URI.
Table A.3.2.1-6: INVITE request (S-CSCF to MRFC/AS)
INVITE sip:conference-factory1@mrfc1.home1.net SIP/2.0
Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
Max-Forwards: 68
Record-Route: <sip:scscf1.home1.net;lr>, <sip:pcscf1.visited1.net;lr>
P-Asserted-Identity: "John Doe" <sip:user1_public1@home1.net>, <tel:+358-50-4821437>
P-Access-Network-Info:
P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"; orig-ioi=home1.net
P-Charging-Function-Addresses: ccf=[5555::b99:c88:d77:e66]; ccf=[5555::a55:b44:c33:d22]; ecf=[5555::1ff:2ee:3dd:4cc]; ecf=[5555::6aa:7bb:8cc:9dd]
Privacy:
From:
To:
Call-ID:
Cseq:
Supported:
Contact:
Allow:
Accept:
Content-Type:
Content-Length: (…)
v=
o=
s=
c=
t=
m=
b=
a=
a=
a=
a=
a=
a=
a=
a=
m=
b=
a=
a=
a=
a=
a=
a=
a=
a=
7. 100 (Trying) response (MRFC/AS to S-CSCF) – see example in table A.3.2.1-7 (related to table A.3.2.1-6)
The MRFC/AS responds to the INVITE request (6) with a 100 (Trying) provisional response.
Table A.3.2.1-7: 100 (Trying) response (MRFC/AS to S-CSCF)
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. Allocate conference URI
The MRFC/AS allocates a conference URI, based on local information and information gained from the conference-factory URI, as well as information gained from other elements of the SIP signalling.
9. H.248 interaction to create connection
The MRFC initiates a H.248 interaction to create an IMS connection point for UE#1 in MRFP and to determine media capabilities of the MRFP.
10. 183 (Session Progress) response (MRFC/AS to S-CSCF) – see example in table A.3.2.1-13 (related to table A.3.2.1-6)
The MRFC determines the complete set of codecs that it is capable of supporting for this conference. It determines the intersection with those appearing in the SDP in the INVITE request.
The media stream capabilities of the destination are returned along the signalling path, in a 183 (Session Progress) provisional response (to 6).
Table A.3.2.1-10: 183 (Session Progress) response (MRFC/AS to S-CSCF)
SIP/2.0 183 Session Progress
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: <sip:scscf1.home1.net;lr>, <sip:pcscf1.visited1.net;lr>
P-Asserted-Identity: "Conference Server" <sip:mrfc1.home1.net>
P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"; orig-ioi=home1.net; term-ioi=home1.net
P-Charging-Function-Addresses: ccf=[5555::b99:c88:d77:e66]; ccf=[5555::a55:b44:c33:d22]; ecf=[5555::1ff:2ee:3dd:4cc]; ecf=[5555::6aa:7bb:8cc:9dd]
Privacy: none
From:
To: <sip:conference-factory1@mrfc1.home1.net>; tag=314159
Call-ID:
CSeq:
Require: precondition, 100rel
Contact: <sip:lmaa234269@mrfc1.home1.net>;isfocus
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY, PUBLISH
RSeq: 9021
Content-Type: application/sdp
Content-Length: (…)
v=0
o=- 2987933623 2987933623 IN IP6 5555::aaa:bbb:ccc:ddd
s=-
c=IN IP6 5555::eee:fff:aaa:bbb
t=0 0
m=video 10001 RTP/AVP 98 99
b=AS:75
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=inactive
a=conf:qos remote sendrecv
a=rtpmap:98 H263
a=fmtp:98 profile-level-id=0
a=rtpmap:99 MP4V-ES
m=audio 6544 RTP/AVP 97 96
b=AS:25.4
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=inactive
a=conf:qos remote sendrecv
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; maxframes=2
a=rtpmap:96 telephone-event
Contact: Contains the IP address or FQDN of the MRFC/AS and a temporary identifier of the conference being created in the user part. The URI for the allocated conference is not indicated yet. The "isfocus" feature parameter is included, as this temporary contact is still a conference URI.
P-Charging-Vector: The MRFC/AS inserts this header and populates the icid parameters with a unique value and populates the term-ioi parameter with the identifier of its own network.
P-Charging-Function-Address: The MRFC/AS stores the P-Charging-Function-Addresses header field to be passed to the S-CSCF.
11. 183 (Session Progress) response (S-CSCF to P-CSCF) – see example in table A.3.2.1-11
The S-CSCF forwards the 183 (Session Progress) response to the P-CSCF.
Table A.3.2.1-11: 183 (Session Progress) response (S-CSCF to P-CSCF)
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
Record-Route:
P-Asserted-Identity:
P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"
P-Charging-Function-Addresses: ccf=[5555::b99:c88:d77:e66]; ccf=[5555::a55:b44:c33:d22]; ecf=[5555::1ff:2ee:3dd:4cc]; ecf=[5555::6aa:7bb:8cc:9dd]
Privacy:
From:
To:
Call-ID:
CSeq:
Require:
Contact:
Allow:
RSeq:
Content-Type:
Content-Length:
v=
o=
s=
c=
t=
m=
b=
a=
a=
a=
a=
a=
a=
a=
a=
a=
a=
m=
b=
a=
a=
a=
a=
a=
a=
a=
a=
a=
12. Authorize QoS Resources
The P-CSCF authorizes the resources necessary for this session. The approval of QoS commitment either happens at this stage or after the 200 (OK) response of INVITE request (39) based on operator local policy.
13 183 (Session Progress) response (P-CSCF to UE) – see example in table A.3.2.1-13
The P-CSCF forwards the 183 (Session Progress) response to the originating endpoint.
Table A.3.2.1-13: 183 (Session Progress) response (P-CSCF to UE)
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
Record-Route: <sip:scscf1.home1.net;lr>, <sip:pcscf1.visited1.net:7531;lr;comp=sigcomp>
P-Asserted-Identity:
Privacy:
From:
To:
Call-ID:
CSeq:
Require:
Contact:
Allow:
RSeq:
Content-Type:
Content-Length:
v=
o=
s=
c=
t=
m=
b=
a=
a=
a=
a=
a=
a=
a=
a=
a=
a=
m=
b=
a=
a=
a=
a=
a=
a=
a=
a=
a=
14. Resource reservation
The originating UE sets up the bearer in accordance with the media description received SDP.
15. PRACK request (UE to P-CSCF) – see example in table A.3.2.1-15
The PRACK request does not carry SDP as the final codec decision is already made as part of the initial offer/answer exchange.
Table A.3.2.1-15: PRACK request (UE to P-CSCF)
PRACK sip:lmaa234269@mrfc1.home1.net 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> From: <sip:user1_public1@home1.net>; tag=171828
To: <sip:conference-factory1@mrfc1.home1.net>;tag=314159
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 128 PRACK
Require: precondition, sec-agree
Proxy-Require: sec-agree
Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi-c=98765432; spi-s=87654321; port-c=8642; port-s=7531
RAck: 9021 127 INVITE
Content-Length: 0
16. PRACK request (P-CSCF to S-CSCF) – see example in table A.3.2.1-16
The P-CSCF forwards the PRACK request to the S-CSCF.
Table A.3.2.1-16: PRACK request (P-CSCF to S-CSCF)
PRACK sip:lmaa234269@mrfc1.home1.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
P-Access-Network-Info:
Route: <sip:scscf1.home1.net;lr>
From:
To:
Call-ID:
Cseq:
Require: precondition
RAck:
Content-Length:
17. PRACK request (S-CSCF to MRFC/AS) – see example in table A.3.2.1-17
The S-CSCF forwards the PRACK request to the MRFC/AS.
Table A.3.2.1-17: PRACK request (S-CSCF to MRFC/AS)
PRACK sip:lmaa234269@mrfc1.home1.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
P-Access-Network-Info:
From:
To:
Call-ID:
Cseq:
Require:
RAck:
Content-Length:
18. 200 (OK) response (MRFC/AS to S-CSCF) – see example in table A.3.2.1-18 (related to table A.3.2.1-17)
The MRFC/AS acknowledges the PRACK request (17) with a 200 (OK) response.
Table A.3.2.1-18: 200 (OK) response (MRFC/AS to S-CSCF)
SIP/2.0 200 OK
Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
From:
To:
Call-ID:
CSeq:
Content-Length: 0
19. H.248 interaction to modify connection
MRFC initiates a H.248 interaction to modify the connection established in step #9 and instructs MRFP to reserve the multimedia processing resources for UE#1 according to the preceding resource negotiation between the UE#1 and the MRFC.
20. 200 (OK) response (S-CSCF to P-CSCF) – see example in table A.3.2.1-20
The S-CSCF forwards the 200 (OK) response to the P-CSCF.
Table A.3.2.1-20: 200 (OK) response (S-CSCF to P-CSCF)
SIP/2.0 200 OK
Via: SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
From:
To:
Call-ID:
CSeq:
Content-Length:
21. 200 (OK) response (P-CSCF to UE) – see example in table A.3.2.1-21
The P-CSCF forwards the 200 (OK) response to the UE.
Table A.3.2.1-21: 200 (OK) response (P-CSCF to UE)
SIP/2.0 200 OK
Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
From:
To:
Call-ID:
CSeq:
Content-Length:
22. UPDATE request (UE to P-CSCF) – see example in table A.3.2.1-22
When the resource reservation is completed, the UE sends the UPDATE request to the MRFC/AS, via the signalling path established by the INVITE request.
Table A.3.2.1-22: UPDATE request (UE to P-CSCF)
UPDATE sip:lmaa234269@mrfc1.home1.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:scscf1.home1.net;lr>
P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11
From: <sip:user1_public1@home1.net>; tag=171828
To: <sip:conference-factory1@mrfc1.home1.net>;tag=314159
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 129 UPDATE
Require: sec-agree
Proxy-Require: sec-agree
Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi-c=98765432; spi-s=87654321; port-c=8642; port-s=7531
Content-Type: application/sdp
Content-Length: (…)
v=0
o=- 2987933615 2987933617 IN IP6 5555::aaa:bbb:ccc:ddd
s=-
c=IN IP6 5555::aaa:bbb:ccc:ddd
t=0 0
m=video 0 RTP/AVP 98
b=AS:75
a=curr:qos local sendrecv
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=rtpmap:98 H263
a=fmtp:98 profile-level-id=0
m=audio 3456 RTP/AVP 97 96
b=AS:25.4
a=curr:qos local sendrecv
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; maxframes=2
a=rtpmap:96 telphone-event
23. UPDATE request (P-CSCF to S-CSCF) – see example in table A.3.2.1-23
The P-CSCF forwards the UPDATE request to the S-CSCF.
Table A.3.2.1-23: UPDATE request (P-CSCF to S-CSCF)
UPDATE sip:lmaa234269@mrfc1.home1.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
P-Access-Network-Info:
P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"; ggsn=[5555::4b4:3c3:2d2:1e1]; pdp-sig=no; gcid=723084371; auth-token=43876559; flow-id=3
Route: <sip:scscf1.home1.net;lr>
From:
To:
Call-ID:
Cseq:
Content-Type:
Content-Length:
v=
o=
s=
c=
t=
m=
m=
m=
b=
a=
a=
a=
a=
a=
a=
m=
b=
a=
a=
a=
a=
a=
a=
a=
24. UPDATE request (S-CSCF to MRFC/AS) – see example in table A.3.2.1-24
The S-CSCF forwards the UPDATE request to the MRFC/AS.
Table A.3.2.1-24: UPDATE request (S-CSCF to MRFC/AS)
UPDATE sip:lmaa234269@mrfc1.home1.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
P-Access-Network-Info:
From:
To:
Call-ID:
Cseq:
Content-Type:
Content-Length:
v=
o=
s=
c=
t=
m=
m=
m=
b=
a=
a=
a=
a=
a=
a=
m=
b=
a=
a=
a=
a=
a=
a=
a=
25. 200 (OK) response (MRFC/ASto S-CSCF) – see example in table A.3.2.1-25 (related to table A.3.2.1-24)
The MRFC/AS acknowledges the UPDATE request (24) with a 200 (OK) response.
Table A.3.2.1-25: 200 (OK) response (MRFC/AS to S-CSCF)
SIP/2.0 200 OK
Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
From:
To:
Call-ID:
CSeq:
Content-Type: application/sdp
Content-Length: (…)
v=0
o=- 2987933623 2987933625 IN IP6 5555::aaa:bbb:ccc:ddd
s=-
c=IN IP6 5555::eee:fff:aaa:bbb
t=0 0
m=video 0 RTP/AVP 98
b=AS:75
a=curr:qos local sendrecv
a=curr:qos remote sendrecv
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=rtpmap:98 H263
a=fmtp:98 profile-level-id=0
m=audio 6544 RTP/AVP 97 96
b=AS:25.4
a=curr:qos local sendrecv
a=curr:qos remote sendrecv
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; maxframes=2
a=rtpmap:96 telephone-event
The SDP indicates that the resource reservation was successful both in the local and the remote segment.
26. H.248 interaction to modify connection
MRFC initiates a H.248 interaction to connect through the multimedia processing resources for UE#1 in MRFP.
27. 200 (OK) response (S-CSCF to P-CSCF) – see example in table A.3.2.1-27
The S-CSCF forwards the 200 (OK) response to the P-CSCF.
Table A.3.2.1-27: 200 (OK) response (S-CSCF to P-CSCF)
SIP/2.0 200 OK
Via: SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
From:
To:
Call-ID:
CSeq:
Content-Type:
Content-Length:
v=
o=
s=
c=
t=
m=
b=
a=
a=
a=
a=
a=
a=
m=
b=
a=
a=
a=
a=
a=
a=
a=
28. 200 (OK) response (P-CSCF to UE) – see example in table A.3.2.1-28
The P-CSCF forwards the 200 (OK) response to the UE.
Table A.3.2.1-28: 200 (OK) response (P-CSCF to UE)
SIP/2.0 200 OK
Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
From:
To:
Call-ID:
CSeq:
Content-Type:
Content-Length:
v=
o=
s=
c=
t=
m=
b=
a=
a=
a=
a=
a=
a=
m=
b=
a=
a=
a=
a=
a=
a=
a=
29. 200 (OK) response (MRFC/AS to S-CSCF) – see example in table A.3.2.1-29 (related to table A.3.2.1-6)
After the success modification of the session (26), the MRFC/AS sends a 200 (OK) response final response to the INVITE request (6) to the S-CSCF.
Table A.3.2.1-29: 200 (OK) response (MRFC/AS to S-CSCF)
SIP/2.0 200 OK
Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
Record-Route: <sip:scscf1.home1.net;lr>, <sip:pcscf1.visited1.net;lr>
From:
To:
Call-ID:
CSeq: 127 INVITE
Contact: <sip:conference1@mrfc1.home1.net>;isfocus
Allow-Events: conference, pending-additions
Content-Length:0
Contact: Contains the conference URI for the conference allocated at the MRFC/AS and the "isfocus" feature parameter.
Allow-Events: The MRFC/AS indicates support for the "conference" and "pending-additions" event packages.
30. 200 (OK) response (S-CSCF to P-CSCF) – see example in table A.3.2.1-30
The S-CSCF sends a 200 (OK) response final response along the signalling path back to the P-CSCF.
Table A.3.2.1-30: 200 (OK) response (S-CSCF to P-CSCF)
SIP/2.0 200 OK
Via: SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
Record-Route:
From:
To:
Call-ID:
CSeq:
Contact:
Allow-Events:
Content-Length:
31. Approval of QoS commit
The P-CSCF approves the commitment of the QoS resources if it was not approved already in step (12).
32. 200 (OK) response (P-CSCF to UE) – see example in table A.3.2.1-32
The P-CSCF forwards the 200 (OK) response final response to the session originator. The UE can start the media flow(s) for this session.
Table A.3.2.1-32: 200 (OK) response (P-CSCF to UE)
SIP/2.0 200 OK
Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
Record-Route: <sip:scscf1.home1.net;lr>, <sip:pcscf1.visited1.net:7531;lr;comp=sigcomp>
From:
To:
Call-ID:
CSeq:
Contact:
Allow-Events:
Content-Length:
33. ACK request (UE to P-CSCF) – see example in table A.3.2.1-33
The UE starts the media flow for this session, and responds to the 200( OK) response (32) with an ACK request sent to the P-CSCF.
Table A.3.2.1-33: ACK request (UE to P-CSCF)
ACK sip:conference1@mrfc1.home1.net:2342 SIP/2.0
Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
Max-Forwards: 70
Route: <sip:pcscf1.visited1.net:7531;lr;comp=sigcomp>, <sip:scscf1.home1.net;lr>From: <sip:user1_public1@home1.net>; tag=171828
To: <sip:conference-factory1@mrfc1.home1.net>;tag=314159
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 127 ACK
Content-Length: 0
34. ACK request (P-CSCF to S-CSCF) – see example in table A.3.2.1-34
The P-CSCF forwards the ACK request to the S-CSCF.
Table A.3.2.1-34: ACK request (P-CSCF to S-CSCF)
ACK sip:conference1@mrfc1.home1.net:2342 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:scscf1.home1.net;lr>
From:
To:
Call-ID:
Cseq:
Content-Length:
35. ACK request (S-CSCF to MRFC/AS) – see example in table A.3.2.1-35
The S-CSCF forwards the ACK request to the MRFC/AS.
Table A.3.2.1-35: ACK request (S-CSCF to MRFC/AS)
ACK sip:conference1@mrfc1.home1.net:2342 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
From:
To:
Call-ID:
Cseq:
Content-Length:
A.3.2.2 MRFC/AS is not located in user’s home network
Figure A.3.2.2-1 shows an user creating a conference by using a conference-factory URI. The conference is created at a MRFC/AS located in a different network than user’s S-CSCF.
Figure A.3.2.2-1: User automatically creating a conference with a conference factory URI –
MRFC/AS is not located in user’s home network
The details of the flows are as follows:
1. INVITE request (UE to P-CSCF) – see example in table A.3.2.2-1
A UE wants to create a conference to a MRFC/AS in other network. For this purpose the UE is aware of a conference-factory URI that was obtained by means outside the present document (e.g. due to pre-configuration or via other protocols, such as http)
The UE determines the complete set of codecs that it is capable of supporting for this conference. It builds a SDP Offer containing bandwidth requirements and characteristics of each, and assigns local port numbers for each possible media flow. Multiple media flows may be offered, and for each media flow (m= line in SDP), there may be multiple codec choices offered.
For this example, it is assumed that the UE is willing to establish a multimedia session comprising a video stream and an audio stream. The video stream supports two codecs, either H.263 or MPEG-4 Visual. The audio stream supports the AMR codec. The UE sends the INVITE request to the P-CSCF.
The UE indicates that it supports precondition and it indicates that it supports reliable provisional responses. However, it does not use the "Require" header for these capabilities.
The UE does not have available the resources that are necessary to transport the media.
For this example it is assumed, that signalling encryption was negotiated between UE and P‑CSCF in the security mode set-up procedure during the last successful authentication. This option will only be shown in this example.
Table A.3.2.2-1: INVITE request (UE to P-CSCF)
INVITE sip:conference-factory@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:conference-factory@home2.net>
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 127 INVITE
Require: sec-agree
Proxy-Require: sec-agree
Supported: precondition, 100rel, gruu, 199
Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi-c=98765432; spi-s=87654321; port-c=8642; port-s=7531
Contact: <sip: user1_public1@home1.net; gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 ;comp=sigcomp>
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY
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=video 3400 RTP/AVP 98 99
b=AS:75
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos none remote sendrecv
a=inactive
a=rtpmap:98 H263
a=fmtp:98 profile-level-id=0
a=rtpmap:99:MPVMP4V-ES
m=audio 3456 RTP/AVP 97 96
b=AS:25.4
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos none remote sendrecv
a=inactive
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; maxframes=2
a=rtpmap:96 telephone-event
Request-URI: contains the conference factory URI.
2. 100 (Trying) response (P-CSCF to UE) – see example in table A.3.2.2-2
The P-CSCF responds to the INVITE request (1) with a 100 (Trying) response provisional response.
Table A.3.2.2-2: 100 (Trying) response (P-CSCF to UE)
SIP/2.0 100 (Trying) response
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 to S-CSCF) – see example in table A.3.2.2-3
The P-CSCF forwards the INVITE request to the S-CSCF.
Table A.3.2.2-3: INVITE request (P-CSCF to S-CSCF)
INVITE sip:conference-factory@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=
b=
a=
a=
a=
a=
a=
a=
a=
a=
m=
b=
a=
a=
a=
a=
a=
a=
a=
a=
4. 100 (Trying) response (S-CSCF to P-CSCF) – see example in table A.3.2.2-4
The S-CSCF responds to the INVITE request (3) with a 100 (Trying) response provisional response.
Table A.3.2.2-4: 100 (Trying) response (S-CSCF to P-CSCF)
SIP/2.0 100 (Trying) response
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
The S-CSCF validates the service profile of this subscriber and evaluates the initial filter criteria.
6. INVITE request (S-CSCF to I-CSCF) – see example in table A.3.2.2-6
S-CSCF determines the network where the INVITE request should be forwarded. The S-CSCF resolves the I‑CSCF as the next hop for this request.
Table A.3.2.2-6: INVITE request (S-CSCF to I-CSCF)
INVITE sip:conference-factory@home2.net SIP/2.0
Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
Max-Forwards: 68
Record-Route: <sip:scscf1.home1.net;lr>, <sip:pcscf1.visited1.net;lr>
P-Asserted-Identity: "John Doe" <sip:user1_public1@home1.net>, <tel:+358-50-4821437>
P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=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=
b=
a=
a=
a=
a=
a=
a=
a=
a=
m=
b=
a=
a=
a=
a=
a=
a=
a=
a=
7. 100 (Trying) response (I-CSCF to S-CSCF) – see example in table A.3.2.2-7
The I-CSCF responds to the INVITE request (6) with a 100 (Trying) response provisional response.
Table A.3.2.2-7: 100 (Trying) response (I-CSCF to S-CSCF)
SIP/2.0 100 (Trying) response
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. Public service identity (PSI) location query
The I-CSCF resolves the conference-factory URI. In this example the I-CSCF queries HSS to resolve the MRFC/AS PSI to be contacted. The HSS responds with the address of the MRFC/AS.
For detailed message flows see 3GPP TS 29.228 [12] .
Table A.3.2.2-8a provides the parameters in the SIP INVITE request, which are sent to the HSS.
Table A.3.2.2-8a Cx: User location query procedure (I-CSCF to HSS)
Message source and destination |
Cx: Information element name |
Information source in SIP INVITE |
Description |
I-CSCF to HSS |
Public Service Identity (PSI) |
Request-URI: |
This information element indicates the public user identity |
Table A.3.2.2-8b provides the parameters sent from the HSS that need to be mapped to SIP INVITE and sent to MRFC/AS.
Table A.3.2.2-8b Cx: User location query procedure (HSS to I-CSCF)
Message source and destination |
Cx: Information element name |
Mapping to SIP header in SIP INVITE |
Description |
HSS to I-CSCF |
MRFC/AS address |
IP packet destination address |
This information element indicates the MRFC/AS address which serves the PSI. |
9. INVITE request (I-CSCF to MRFC/AS) – see example in table A.3.2.2-9
I-CSCF forwards the INVITE request to the MRFC/AS. The I-CSCF does not add itself to the Record-Route header since it does not need to stay on the signalling path for subsequent requests.
Table A.3.2.2-9: INVITE request (I-CSCF to MRFC/AS)
INVITE sip:conference-factory@home2.net SIP/2.0
Via: SIP/2.0/UDP icscf1.home2.net;branch=z9hG4bK32f432.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
Record-Route: <sip:scscf1.home1.net;lr>, <sip:pcscf1.visited1.net;lr>
P-Asserted-Identity:
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=
b=
a=
a=
a=
a=
a=
a=
a=
a=
m=
b=
a=
a=
a=
a=
a=
a=
a=
a=
10. 100 (Trying) response (MRFC/AS to I-CSCF) – see example in table A.3.2.2-10 (related to table A.3.2.2-9)
The MRFC/AS responds to the INVITE request (6) with a 100 (Trying) response provisional response.
Table A.3.2.2-10: 100 (Trying) response (MRFC/AS to I-CSCF)
SIP/2.0 100 (Trying) response
Via: SIP/2.0/UDP icscf1.home2.net;branch=z9hG4bK32f432.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. Allocate conference URI
MRFC/AS allocates a conference URI, based on local information and information gained from the conference-factory URI, as well as information gained from other elements of the SIP signalling.
12. H.248 interaction to create connection
MRFC initiates a H.248 interaction to create an connection point for UE#1 in MRFP and to determine media capabilities of MRFP.
13. 183 (Session Progress) response (MRFC/AS to I-CSCF) – see example in table A.3.2.2-13 (related to table A.3.2.2-9)
The MRFC determines the complete set of codecs that it is capable of supporting for this conference. It determines the intersection with those appearing in the SDP in the INVITE request.
The media stream capabilities of the destination are returned along the signalling path, in a 183 (Session Progress) provisional response (to 8).
Table A.3.2.2-13: 183 (Session Progress) response (MRFC/AS to I-CSCF)
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP icscf1.home2.net;branch=z9hG4bK32f432.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:scscf1.home1.net;lr>, <sip:pcscf1.visited1.net;lr>
P-Asserted-Identity: "Conference Server" <sip:mrfc1.home2.net>
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]
Privacy: none
From:
To: <sip:conference-factory1@home2.net>; tag=314159
Call-ID:
CSeq:
Require: precondition, 100rel
Contact: <sip:conference1@mrfc1.home2.net>;isfocus
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY, PUBLISH
RSeq: 9021
Content-Type: application/sdp
Content-Length: (…)
v=0
o=- 2987933623 2987933623 IN IP6 5555::aaa:bbb:ccc:ddd
s=-
c=IN IP6 5555::eee:fff:aaa:bbb
t=0 0
m=video 10001 RTP/AVP 98 99
b=AS:75
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=inactive
a=conf:qos remote sendrecv
a=rtpmap:98 H263
a=fmtp:98 profile-level-id=0
a=rtpmap:99 MP4V-ES
m=audio 6544 RTP/AVP 97 96
b=AS:25.4
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=inactive
a=conf:qos remote sendrecv
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; maxframes=2
a=rtpmap:96 telephone-event
Contact: Contains the conference URI for the conference allocated at the MRFC/AS and the "isfocus" feature parameter.
P-Charging-Vector: The MRFC/AS inserts the originating IOI parameter received and populates the terminating IOI parameter with its own network.
P-Charging-Function-Addresses: The MRFC/AS inserts the P-Charging-Function-Addresses header field to be passed to the I-CSCF.
14. 183 (Session Progress) response (I-CSCF to S-CSCF) – see example in table A.3.2.2-14
The I-CSCF forwards the 183 (Session Progress) response to the P-CSCF.
Table A.3.2.2-14: 183 (Session Progress) response (I-CSCF to S-CSCF)
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
Record-Route:
P-Asserted-Identity:
P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"; orig-ioi=home1.net; term-ioi=home2.net
Privacy:
From:
To:
Call-ID:
CSeq:
Require:
Contact:
Allow:
RSeq:
Content-Type:
Content-Length:
v=
o=
s=
c=
t=
m=
b=
a=
a=
a=
a=
a=
a=
a=
a=
a=
a=
m=
b=
a=
a=
a=
a=
a=
a=
a=
a=
a=
15. 183 (Session Progress) response (S-CSCF to P-CSCF) – see example in table A.3.2.2-15
The S-CSCF forwards the 183 (Session Progress) response to the P-CSCF.
Table A.3.2.2-15: 183 (Session Progress) response (S-CSCF to P-CSCF)
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
Record-Route:
P-Asserted-Identity:
P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024";
Privacy:
From:
To:
Call-ID:
CSeq:
Require:
Contact:
Allow:
RSeq:
Content-Type:
Content-Length:
v=
o=
s=
c=
t=
m=
b=
a=
a=
a=
a=
a=
a=
a=
a=
a=
a=
m=
b=
a=
a=
a=
a=
a=
a=
a=
a=
a=
16. Authorize QoS Resources
The P-CSCF authorizes the resources necessary for this session. The approval of QoS commitment either happens at this stage or after 200 (OK) response of INVITE request (34) based on operator local policy.
17. 183 (Session Progress) response (P-CSCF to UE) – see example in table A.3.2.2-17
The P-CSCF forwards the 183 (Session Progress) response to the originating endpoint.
Table A.3.2.2-17: 183 (Session Progress) response (P-CSCF to UE)
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
Record-Route: <sip:scscf1.home1.net;lr>, <sip:pcscf1.visited1.net:7531;lr;comp=sigcomp>
P-Asserted-Identity:
Privacy:
From:
To:
Call-ID:
CSeq:
Require:
Contact:
RSeq:
Content-Type:
Content-Length:
v=
o=
s=
c=
t=
m=
b=
a=
a=
a=
a=
a=
a=
a=
a=
a=
a=
m=
b=
a=
a=
a=
a=
a=
a=
a=
a=
a=
18. Resource reservation
The originating UE sets up the bearer in accordance with the media description received SDP.
19. PRACK request (UE to P-CSCF) – see example in table A.3.2.2-19
The PRACK request does not carry SDP as the final codec decision is already made as part of the initial offer/answer exchange.
Table A.3.2.2-19: PRACK request (UE to P-CSCF)
PRACK sip:conference1@mrfc1.home2.net 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>
From: <sip:user1_public1@home1.net>; tag=171828
To: <sip:conference-factory1@home2.net>;tag=314159
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 128 PRACK
Require: precondition, sec-agree
Proxy-Require: sec-agree
Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi-c=98765432; spi-s=87654321; port-c=8642; port-s=7531
RAck: 9021 127 INVITE
Content-Length: 0
20. PRACK request (P-CSCF to S-CSCF) – see example in table A.3.2.2-20
The P-CSCF forwards the PRACK request to the S-CSCF.
Table A.3.2.2-20: PRACK request (P-CSCF to S-CSCF)
PRACK sip:conference1@mrfc1.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
P-Access-Network-Info:
Route: <sip:scscf1.home1.net;lr>
From:
To:
Call-ID:
Cseq:
Require: precondition
RAck:
Content-Length:
21. PRACK request (S-CSCF to MRFC/AS) – see example in table A.3.2.2-21
The S-CSCF resolves the Request-URI and forwards the PRACK request directly to the MRFC/AS.
Table A.3.2.2-21: PRACK request (S-CSCF to MRFC/AS)
PRACK sip:conference1@mrfc1.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
From:
To:
Call-ID:
Cseq:
Require:
RAck:
Content-Length:
22. 200 (OK) response (MRFC/AS to S-CSCF) – see example in table A.3.2.2-22 (related to table A.3.2.2-21)
The MRFC/AS acknowledges the PRACK request (20) with a 200 (OK) response.
Table A.3.2.2-22: 200 (OK) response (MRFC/AS to S-CSCF)
SIP/2.0 200 OK
Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
From:
To:
Call-ID:
CSeq:
Content-Length: 0
23. H.248 interaction to modify connection
MRFC initiates a H.248 interaction to modify the connection established in step #11 and instructs MRFP to reserve the multimedia processing resources for UE#1 according to the preceding resource negotiation between the UE#1 and the MRFC.
24. 200 (OK) response (S-CSCF to P-CSCF) – see example in table A.3.2.2-24
The S-CSCF forwards the 200 (OK) response to the P-CSCF.
Table A.3.2.2-24: 200 (OK) response (S-CSCF to P-CSCF)
SIP/2.0 200 OK
Via: SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
From:
To:
Call-ID:
CSeq:
Content-Length:
25. 200 (OK) response (P-CSCF to UE) – see example in table A.3.2.2-25
The P-CSCF forwards the 200 (OK) response to the UE.
Table A.3.2.2-25: 200 (OK) response (P-CSCF to UE)
SIP/2.0 200 OK
Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
From:
To:
Call-ID:
CSeq:
Content-Length:
26. UPDATE request (UE to P-CSCF) – see example in table A.3.2.2-26
When the resource reservation is completed, the UE sends the UPDATE request to the MRFC/AS, via the signalling path established by the INVITE request.
Table A.3.2.2-26: UPDATE request (UE to P-CSCF)
UPDATE sip:conference1@mrfc1.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:scscf1.home1.net;lr>
P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11
From: <sip:user1_public1@home1.net>; tag=171828
To: <sip:conference-factory1@home2.net>;tag=314159
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 129 UPDATE
Require: sec-agree
Proxy-Require: sec-agree
Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi-c=98765432; spi-s=87654321; port-c=8642; port-s=7531
Content-Type: application/sdp
Content-Length: (…)
v=0
o=- 2987933615 2987933617 IN IP6 5555::aaa:bbb:ccc:ddd
s=-
c=IN IP6 5555::aaa:bbb:ccc:ddd
t=0 0
m=video 0 RTP/AVP 98
b=AS:75
a=curr:qos local sendrecv
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=rtpmap:98 H263
a=fmtp:98 profile-level-id=0
m=audio 3456 RTP/AVP 97 96
b=AS:25.4
a=curr:qos local sendrecv
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; maxframes=2
a=rtpmap:96 telphone-event
27. UPDATE request (P-CSCF to S-CSCF) – see example in table A.3.2.2-27
The P-CSCF forwards the UPDATE request to the S-CSCF.
Table A.3.2.2-27: UPDATE request (P-CSCF to S-CSCF)
UPDATE sip:conferece1@mrfc1.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
P-Access-Network-Info:
P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"; ggsn=[5555::4b4:3c3:2d2:1e1]; pdp-sig=no; gcid=723084371; auth-token=43876559; flow-id=3
Route: <sip:scscf1.home1.net;lr>
From:
To:
Call-ID:
Cseq:
Content-Type:
Content-Length:
v=
o=
s=
c=
t=
m=
m=
m=
b=
a=
a=
a=
a=
a=
a=
m=
b=
a=
a=
a=
a=
a=
a=
a=
28. UPDATE request (S-CSCF to MRFC/AS) – see example in table A.3.2.2-28
The S-CSCF forwards the UPDATE request to the MRFC/AS.
Table A.3.2.2-28: UPDATE request (S-CSCF to MRFC/AS)
UPDATE sip:conference1@mrfc1.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
From:
To:
Call-ID:
Cseq:
Content-Type:
Content-Length:
v=
o=
s=
c=
t=
m=
m=
m=
b=
a=
a=
a=
a=
a=
a=
m=
b=
a=
a=
a=
a=
a=
a=
a=
29. 200 (OK) response (MRFC/ASto S-CSCF) – see example in table A.3.2.2-29 (related to table A.3.2.2-28)
The MRFC/AS acknowledges the UPDATE request (27) with a 200 (OK) response.
Table A.3.2.2-29: 200 (OK) response (MRFC/AS to S-CSCF)
SIP/2.0 200 OK
Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
From:
To:
Call-ID:
CSeq:
Content-Type: application/sdp
Content-Length: (…)
v=0
o=- 2987933623 2987933625 IN IP6 5555::aaa:bbb:ccc:ddd
s=-
c=IN IP6 5555::eee:fff:aaa:bbb
t=0 0
m=video 0 RTP/AVP 98
b=AS:75
a=curr:qos local sendrecv
a=curr:qos remote sendrecv
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=rtpmap:98 H263
a=fmtp:98 profile-level-id=0
m=audio 6544 RTP/AVP 97 96
b=AS:25.4
a=curr:qos local sendrecv
a=curr:qos remote sendrecv
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; maxframes=2
a=rtpmap:96 telephone-event
The SDP indicates that the resource reservation was successful both in the local and the remote segment.
30. H.248 interaction to modify connection
MRFC initiates a H.248 interaction to connect through the multimedia processing resources for UE#1 in MRFP.
31. 200 (OK) response (S-CSCF to P-CSCF) – see example in table A.3.2.2-31
The S-CSCF forwards the 200 (OK) response to the P-CSCF.
Table A.3.2.2-31: 200 (OK) response (S-CSCF to P-CSCF)
SIP/2.0 200 (OK)
Via: SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
From:
To:
Call-ID:
CSeq:
Content-Type:
Content-Length:
v=
o=
s=
c=
t=
m=
b=
a=
a=
a=
a=
a=
a=
m=
b=
a=
a=
a=
a=
a=
a=
a=
32. 200 (OK) response (P-CSCF to UE) – see example in table A.3.2.2-32
The P-CSCF forwards the 200 (OK) response to the UE.
Table A.3.2.2-32: 200 (OK) response (P-CSCF to UE)
SIP/2.0 200 OK
Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
From:
To:
Call-ID:
CSeq:
Content-Type:
Content-Length:
v=
o=
s=
c=
t=
m=
b=
a=
a=
a=
a=
a=
a=
m=
b=
a=
a=
a=
a=
a=
a=
a=
33. 200 (OK) response (MRFC/AS to I-CSCF) – see example in table A.3.2.2-33 (related to table A.3.2.2-9)
After the success modification of the session (29), the MRFC/AS sends a 200 (OK) response final response to the INVITE request (8) to the I-CSCF.
Table A.3.2.2-33: 200 (OK) response (MRFC/AS to I-CSCF)
SIP/2.0 200 OK
Via: SIP/2.0/UDP icscf1.home2.net;branch=z9hG4bK32f432.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:scscf1.home1.net;lr>, <sip:pcscf1.visited1.net;lr>
From:
To:
Call-ID:
CSeq: 127 INVITE
Contact: <sip:conference1@mrfc1.home2.net>;isfocus
Allow-Events: conference, pending-additions
Content-Length:0
Contact: Contains the conference URI for the conference allocated at the MRFC/AS and the "isfocus" feature parameter.
Allow-Events: The MRFC/AS indicates support for the "conference" and "pending-additions" event packages.
34. 200 (OK) response (I-CSCF to S-CSCF) – see example in table A.3.2.2-34
The I-CSCF forwards the 200(OK) response to the S-CSCF
Table A.3.2.2-34: 200 (OK) response (I-CSCF to S-CSCF)
SIP/2.0 200 OK
Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
Record-Route:
From:
To:
Call-ID:
CSeq:
Contact:
Allow-Events:
Content-Length:0
35. 200 (OK) response (S-CSCF to P-CSCF) – see example in table A.3.2.2-35
The S-CSCF sends a 200 (OK) response final response along the signalling path back to the P-CSCF.
Table A.3.2.2-35: 200 (OK) response (S-CSCF to P-CSCF)
SIP/2.0 200 OK
Via: SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
Record-Route:
From:
To:
Call-ID:
CSeq:
Contact:
Allow-Events:
Content-Length:
36. Approval of QoS commit
The P-CSCF approves the commitment of the QoS resources if it was not approved already in step (12).
37. 200 (OK) response (P-CSCF to UE) – see example in table A.3.2.2-37
The P-CSCF forwards the 200 (OK) response final response to the session originator. The UE can start the media flow(s) for this session.
Table A.3.2.2-37: 200 (OK) response (P-CSCF to UE)
SIP/2.0 200 OK
Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
Record-Route: <sip:scscf1.home1.net;lr>, <sip:pcscf1.visited1.net:7531;lr;comp=sigcomp>
From:
To:
Call-ID:
CSeq:
Contact:
Allow-Events:
Content-Length:
38. ACK request (UE to P-CSCF) – see example in table A.3.2.2-38
The UE starts the media flow for this session, and responds to the 200 (OK) response (32) with an ACK request sent to the P-CSCF.
Table A.3.2.2-38: ACK request (UE to P-CSCF)
ACK sip:conference1@mrfc1.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:scscf1.home1.net;lr>
From: <sip:user1_public1@home1.net>; tag=171828
To: <sip:conference-factory1@home2.net>;tag=314159
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 127 ACK
Content-Length: 0
39. ACK request (P-CSCF to S-CSCF) – see example in table A.3.2.2-39
The P-CSCF forwards the ACK request to the S-CSCF.
Table A.3.2.2-39: ACK request (P-CSCF to S-CSCF)
ACK sip:conference1@mrfc1.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:scscf1.home1.net;lr>
From:
To:
Call-ID:
Cseq:
Content-Length:
40. ACK request (S-CSCF to MRFC/AS) – see example in table A.3.2.2-40
The S-CSCF forwards the ACK request to the MRFC/AS.
Table A.3.2.2-40: ACK request (S-CSCF to MRFC/AS)
ACK sip:conference1@mrfc1.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
From:
To:
Call-ID:
Cseq:
Content-Length:
A.3.3 User automatically creating a conference with a conference URI
The call flows for a user automatically creating a conference with a conference URI look identical to the call flows for conference creation with a conference-factory URI (see subclause A.3.2), besides the URIs carried in the Request URI and Contact header fields.
A.3.4 User creating a conference by manually dialling
The call flows for a user creating a conference by manually dialling into the IMS look identical to the call flows for conference creation with a conference-factory URI (see subclause A.3.2), besides the URIs carried in the Request URI and Contact header fields.
A.3.5 User creating a conference from two existing connections (Three-way session), users in different networks
Subclause 5.3.1.3.3 of the present document shows that the creation of a Three-way session is a local issue at the UE which results in a combination of other procedures (conference creation, conference participant invitation to conference, session release).
A.3.6 User automatically creating a conference with a conference factory URI and inviting some users to the newly-created conference
This flow shows how a user can create a conference using a conferece factory URI and simultaneously invite some users to the newly created conference, all using a single INVITE request.
Figure A.3.6-1: User automatically creating a conference with a conference factory URI – MRFC/AS is located in user’s home network
Figure A.3.6-1 shows an user creating a conference by using a conference-factory URI and simultaneouslt inviting some users to that conference. The conference is created at a MRFC/AS of the users home network.
The details of the flows are as follows:
1. INVITE request (UE to P-CSCF) – see example in table A.3.6-1
A UE wants to create a conference. For this purpose the UE is aware of a conference-factory URI that was obtained by means outside the present document (e.g. due to pre-configuration or via other protocols, such as http).
The UE wants also to invite some users to this conference in an expedite manner, avoiding the cumbersome manual invitation to each of these users. Thus it builds a URI list including the SIP URIs of the users that are to be invited and includes it in the message body of the INVITE request for conference creation.
That the invited users have previously given consent to the inviting user to invite them.
The UE determines the complete set of codecs that it is capable of supporting for this conference. It builds a SDP Offer containing bandwidth requirements and characteristics of each, and assigns local port numbers for each possible media flow. Multiple media flows can be offered, and for each media flow (m= line in SDP), there can be multiple codec choices offered.
For this example, it is assumed that the UE is willing to establish a multimedia session comprising an audio stream only. The audio stream supports the AMR codec. The UE sends the INVITE request to the P-CSCF.
The UE indicates that it supports precondition and it indicates that it supports reliable provisional responses. However, it does not use the "Require” header for these capabilities.
The UE does not have available the resources that are necessary to transport the media.
For this example it is assumed, that signalling encryption was negotiated between UE and P‑CSCF in the security mode set-up procedure during the last successful authentication. This option will only be shown in this example.
Table A.3.6-1: INVITE request (UE to P-CSCF)
INVITE sip:conference-factory1@mrfc1.home1.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:conference-factory1@mrfc1.home1.net>
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 127 INVITE
Require: sec-agree, recipient-list-invite
Proxy-Require: sec-agree
Supported: precondition, 100rel, gruu, 199
Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi-c=98765432; spi-s=87654321; port-c=8642; port-s=7531
Contact: <sip:user1_public1@home1.net; gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 ;comp=sigcomp>
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY
Accept:application/sdp, application/3gpp-ims+xml
Content-Type: multipart/mixed;boundary="boundary1"
Content-Length: (…)
–boundary1
Content-Type: application/sdp
v=0
o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ddd
s=-
c=IN IP6 5555::aaa:bbb:ccc:ddd
t=0 0
m=audio 3456 RTP/AVP 97 96
b=AS:25.4
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos none remote sendrecv
a=inactive
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; maxframes=2
a=rtpmap:96 telephone-event
–boundary1
Content-Type: application/resource-lists+xml
Content-Disposition: recipient-list
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
xmlns:cp="urn:ietf:params:xml:ns:copycontrol">
<list>
<entry uri="sip:user2_public1@home1.net" cp:copyControl="to" />
<entry uri="sip:user3_public1@home1.net" cp:copyControl="to"
cp:anonymize="true"/>
<entry uri="sip:user1_public1@foreign.com" cp:copyControl="to"
cp:anonymize="true"/>
</list>
</resource-lists>
–boundary1–
Request-URI: contains the conference factory URI.
Content-Type: contains the specification of the MIME content with the string used as part separator
2. 100 (Trying) response (P-CSCF to UE) – see example in table A.3.6-2
The P-CSCF responds to the INVITE request (1) with a 100 (Trying) provisional response.
Table A.3.6-2: 100 (Trying) response (P-CSCF to UE)
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 to S-CSCF) – see example in table A.3.6-3
The P-CSCF forwards the INVITE request to the S-CSCF.
Table A.3.6-3: INVITE request (P-CSCF to S-CSCF)
INVITE sip:conference-factory1@mrfc1.home1.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:
Require: recipient-list-invite
Supported:
Contact:
Allow:
Accept:
Content-Type:
Content-Length: (…)
–boundary1
Content-Type:
v=
o=
s=
c=
t=
m=
b=
a=
a=
a=
a=
a=
a=
a=
a=
–boundary1
Content-Type:
Content-Disposition:
<?xml …?>
<resource-lists>
…
</resource-lists>
–boundary1
4. 100 (Trying) response (S-CSCF to P-CSCF) – see example in table A.3.6-4
The S-CSCF responds to the INVITE request (3) with a 100 (Trying) provisional response.
Table A.3.6-4: 100 (Trying) response (S-CSCF to P-CSCF)
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
The S-CSCF validates the service profile of this subscriber and evaluates the initial filter criteria.
6. INVITE request (S-CSCF to MRFC/AS) – see example in table A.3.6-6
The S-CSCF forwards the INVITE request to the MRFC/AS that is indicated in the host part of the Request URI. The S-CSCF does not re-write the Request URI.
Table A.3.6-6: INVITE request (S-CSCF to MRFC/AS)
INVITE sip:conference-factory1@mrfc1.home1.net SIP/2.0
Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
Max-Forwards: 68
Record-Route: <sip:scscf1.home1.net;lr>, <sip:pcscf1.visited1.net;lr>
P-Asserted-Identity: "John Doe" <sip:user1_public1@home1.net>, <tel:+358-50-4821437>
P-Access-Network-Info:
P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"; orig-ioi=typ3home1.net;orig-ioi=homei.net
P-Charging-Function-Addresses: ccf=[5555::b99:c88:d77:e66]; ccf=[5555::a55:b44:c33:d22]; ecf=[5555::1ff:2ee:3dd:4cc]; ecf=[5555::6aa:7bb:8cc:9dd]
Privacy:
From:
To:
Call-ID:
Cseq:
Require:
Supported:
Contact:
Allow:
Accept:
Content-Type:
Content-Length: (…)
–boundary1
Content-Type:
v=
o=
s=
c=
t=
m=
b=
a=
a=
a=
a=
a=
a=
a=
a=
–boundary1
Content-Type:
Content-Disposition:
<?xml …?>
<resource-lists>
…
</resource-lists>
–boundary1
7. 100 (Trying) response (MRFC/AS to S-CSCF) – see example in table A.3.6-7 (related to table A.3.6-6)
The MRFC/AS responds to the INVITE request (6) with a 100 (Trying) provisional response.
Table A.3.6-7: 100 (Trying) response (MRFC/AS to S-CSCF)
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. Allocate conference URI
The MRFC/AS allocates a conference URI, based on local information and information gained from the conference-factory URI, as well as information gained from other elements of the SIP signalling.
9. H.248 interaction to create connection
The MRFC initiates a H.248 interaction to create an IMS connection point for UE#1 in MRFP and to determine media capabilities of the MRFP.
10. Invite users to conference
Once the conference URI is allocated the MRFC/AS checks that the users identified by the SIP URIs in the body of the INVITE request from UE#1 have consented to be invited by UE#1. Provided they have previously consented, the users identified by the SIP URIs in the body of the INVITE request from UE#1 are invited to join the conference. To do this the MRFC/AS follows the procedure shown in A.4.3.1.3 setting the Request-URI to the users: sip:user2_public1@home1.net, sip:user3_public1@home1.net and sip:user1_public1@foreign.net.
Notice that the three invitations would be sent simultaneously if the MRFC/AS does support it (see section 5.3.2.5.3). Notice also that it is not necessary that the MRFC/AS waits for the completion of the invitation procedures before continuing with step 11, i.e. the three invitations and the procedure being described in the present flow can run in parallel.
11. 183 (Session Progress) response (MRFC/AS to S-CSCF) – see example in table A.3.6-13 (related to table A.3.6-6)
The MRFC determines the complete set of codecs that it is capable of supporting for this conference. It determines the intersection with those appearing in the SDP in the INVITE request.
The media stream capabilities of the destination are returned along the signalling path, in a 183 (Session Progress) provisional response (to 6).
Table A.3.6-10: 183 (Session Progress) response (MRFC/AS to S-CSCF)
SIP/2.0 183 Session Progress
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: <sip:scscf1.home1.net;lr>, <sip:pcscf1.visited1.net;lr>
P-Asserted-Identity: "Conference Server" <sip:mrfc1.home1.net>
P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"; orig-ioi=home1.net; orig-ioi=type3home1.net; term-ioi=home1.net; term-ioi=type3as1.net
P-Charging-Function-Addresses: ccf=[5555::b99:c88:d77:e66]; ccf=[5555::a55:b44:c33:d22]; ecf=[5555::1ff:2ee:3dd:4cc]; ecf=[5555::6aa:7bb:8cc:9dd]
Privacy: none
From:
To: <sip:conference-factory1@mrfc1.home1.net>; tag=314159
Call-ID:
CSeq:
Require: precondition, 100rel
Contact: <sip:lmaa234269@mrfc1.home1.net>;isfocus
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY, PUBLISH
RSeq: 9021
Content-Type: application/sdp
Content-Length: (…)
v=0
o=- 2987933623 2987933623 IN IP6 5555::aaa:bbb:ccc:ddd
s=-
c=IN IP6 5555::eee:fff:aaa:bbb
t=0 0
m=audio 6544 RTP/AVP 97 96
b=AS:25.4
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=inactive
a=conf:qos remote sendrecv
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; maxframes=2
a=rtpmap:96 telephone-event
Contact: Contains the IP address or FQDN of the MRFC/AS and a temporary identifier of the conference being created in the user part. The URI for the allocated conference is not indicated yet. The "isfocus" feature parameter is included, as this temporary contact is still a conference URI.
P-Charging-Vector: The MRFC/AS inserts this header and populates the icid parameters with a unique value and populates the term-ioi parameter with the identifier of its own network.
P-Charging-Function-Address: The MRFC/AS stores the P-Charging-Function-Addresses header field to be passed to the S-CSCF.
11. 183 (Session Progress) response (S-CSCF to P-CSCF) – see example in table A.3.6-11
The S-CSCF forwards the 183 (Session Progress) response to the P-CSCF.
Table A.3.6-11: 183 (Session Progress) response (S-CSCF to P-CSCF)
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
Record-Route:
P-Asserted-Identity:
P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"
P-Charging-Function-Addresses: ccf=[5555::b99:c88:d77:e66]; ccf=[5555::a55:b44:c33:d22]; ecf=[5555::1ff:2ee:3dd:4cc]; ecf=[5555::6aa:7bb:8cc:9dd]
Privacy:
From:
To:
Call-ID:
CSeq:
Require:
Contact:
Allow:
RSeq:
Content-Type:
Content-Length:
v=
o=
s=
c=
t=
m=
a=
b=
a=
a=
a=
a=
a=
a=
a=
a=
a=
12. Authorize QoS Resources
The P-CSCF authorizes the resources necessary for this session. The approval of QoS commitment either happens at this stage or after the 200 (OK) response of INVITE request (39) based on operator local policy.
13 183 (Session Progress) response (P-CSCF to UE) – see example in table A.3.6-13
The P-CSCF forwards the 183 (Session Progress) response to the originating endpoint.
Table A.3.6-13: 183 (Session Progress) response (P-CSCF to UE)
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
Record-Route: <sip:scscf1.home1.net;lr>, <sip:pcscf1.visited1.net:7531;lr;comp=sigcomp>
P-Asserted-Identity:
Privacy:
From:
To:
Call-ID:
CSeq:
Require:
Contact:
Allow:
RSeq:
Content-Type:
Content-Length:
v=
o=
s=
c=
t=
m=
a=
b=
a=
a=
a=
a=
a=
a=
a=
a=
a=
14. Resource reservation
The originating UE sets up the bearer in accordance with the media description received SDP.
15. PRACK request (UE to P-CSCF) – see example in table A.3.6-15
The PRACK request does not carry SDP as the final codec decision is already made as part of the initial offer/answer exchange.
Table A.3.6-15: PRACK request (UE to P-CSCF)
PRACK sip:lmaa234269@mrfc1.home1.net 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> From: <sip:user1_public1@home1.net>; tag=171828
To: <sip:conference-factory1@mrfc1.home1.net>;tag=314159
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 128 PRACK
Require: precondition, sec-agree
Proxy-Require: sec-agree
Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi-c=98765432; spi-s=87654321; port-c=8642; port-s=7531
RAck: 9021 127 INVITE
Content-Length: 0
16. PRACK request (P-CSCF to S-CSCF) – see example in table A.3.6-16
The P-CSCF forwards the PRACK request to the S-CSCF.
Table A.3.6-16: PRACK request (P-CSCF to S-CSCF)
PRACK sip:lmaa234269@mrfc1.home1.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
P-Access-Network-Info:
Route: <sip:scscf1.home1.net;lr>
From:
To:
Call-ID:
Cseq:
Require: precondition
RAck:
Content-Length:
17. PRACK request (S-CSCF to MRFC/AS) – see example in table A.3.6-17
The S-CSCF forwards the PRACK request to the MRFC/AS.
Table A.3.6-17: PRACK request (S-CSCF to MRFC/AS)
PRACK sip:lmaa234269@mrfc1.home1.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
P-Access-Network-Info:
From:
To:
Call-ID:
Cseq:
Require:
RAck:
Content-Length:
18. 200 (OK) response (MRFC/AS to S-CSCF) – see example in table A.3.6-18 (related to table A.3.6-17)
The MRFC/AS acknowledges the PRACK request (17) with a 200 (OK) response.
Table A.3.6-18: 200 (OK) response (MRFC/AS to S-CSCF)
SIP/2.0 200 OK
Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
From:
To:
Call-ID:
CSeq:
Content-Length: 0
19. H.248 interaction to modify connection
MRFC initiates a H.248 interaction to modify the connection established in step #9 and instructs MRFP to reserve the multimedia processing resources for UE#1 according to the preceding resource negotiation between the UE#1 and the MRFC.
20. 200 (OK) response (S-CSCF to P-CSCF) – see example in table A.3.6-20
The S-CSCF forwards the 200 (OK) response to the P-CSCF.
Table A.3.6-20: 200 (OK) response (S-CSCF to P-CSCF)
SIP/2.0 200 OK
Via: SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
From:
To:
Call-ID:
CSeq:
Content-Length:
21. 200 (OK) response (P-CSCF to UE) – see example in table A.3.6-21
The P-CSCF forwards the 200 (OK) response to the UE.
Table A.3.6-21: 200 (OK) response (P-CSCF to UE)
SIP/2.0 200 OK
Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
From:
To:
Call-ID:
CSeq:
Content-Length:
22. UPDATE request (UE to P-CSCF) – see example in table A.3.6-22
When the resource reservation is completed, the UE sends the UPDATE request to the MRFC/AS, via the signalling path established by the INVITE request.
Table A.3.6-22: UPDATE request (UE to P-CSCF)
UPDATE sip:lmaa234269@mrfc1.home1.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:scscf1.home1.net;lr>
P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11
From: <sip:user1_public1@home1.net>; tag=171828
To: <sip:conference-factory1@mrfc1.home1.net>;tag=314159
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 129 UPDATE
Require: sec-agree
Proxy-Require: sec-agree
Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi-c=98765432; spi-s=87654321; port-c=8642; port-s=7531
Content-Type: application/sdp
Content-Length: (…)
v=0
o=- 2987933615 2987933617 IN IP6 5555::aaa:bbb:ccc:ddd
s=-
c=IN IP6 5555::aaa:bbb:ccc:ddd
t=0 0
m=audio 3456 RTP/AVP 97 96
b=AS:25.4
a=curr:qos local sendrecv
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; maxframes=2
a=rtpmap:96 telphone-event
23. UPDATE request (P-CSCF to S-CSCF) – see example in table A.3.6-23
The P-CSCF forwards the UPDATE request to the S-CSCF.
Table A.3.6-23: UPDATE request (P-CSCF to S-CSCF)
UPDATE sip:lmaa234269@mrfc1.home1.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
P-Access-Network-Info:
P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"; ggsn=[5555::4b4:3c3:2d2:1e1]; pdp-sig=no; gcid=723084371; auth-token=43876559; flow-id=3
Route: <sip:scscf1.home1.net;lr>
From:
To:
Call-ID:
Cseq:
Content-Type:
Content-Length:
v=
o=
s=
c=
t=
m=
b=
a=
a=
a=
a=
a=
a=
a=
24. UPDATE request (S-CSCF to MRFC/AS) – see example in table A.3.6-24
The S-CSCF forwards the UPDATE request to the MRFC/AS.
Table A.3.6-24: UPDATE request (S-CSCF to MRFC/AS)
UPDATE sip:lmaa234269@mrfc1.home1.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
P-Access-Network-Info:
From:
To:
Call-ID:
Cseq:
Content-Type:
Content-Length:
v=
o=
s=
c=
t=
m=
b=
a=
a=
a=
a=
a=
a=
a=
25. 200 (OK) response (MRFC/ASto S-CSCF) – see example in table A.3.6-25 (related to table A.3.6-24)
The MRFC/AS acknowledges the UPDATE request (24) with a 200 (OK) response.
Table A.3.6-25: 200 (OK) response (MRFC/AS to S-CSCF)
SIP/2.0 200 OK
Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
From:
To:
Call-ID:
CSeq:
Content-Type: application/sdp
Content-Length: (…)
v=0
o=- 2987933623 2987933625 IN IP6 5555::aaa:bbb:ccc:ddd
s=-
c=IN IP6 5555::eee:fff:aaa:bbb
t=0 0
m=audio 6544 RTP/AVP 97 96
b=AS:25.4
a=curr:qos local sendrecv
a=curr:qos remote sendrecv
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; maxframes=2
a=rtpmap:96 telephone-event
The SDP indicates that the resource reservation was successful both in the local and the remote segment.
26. H.248 interaction to modify connection
MRFC initiates a H.248 interaction to connect through the multimedia processing resources for UE#1 in MRFP.
27. 200 (OK) response (S-CSCF to P-CSCF) – see example in table A.3.6-27
The S-CSCF forwards the 200 (OK) response to the P-CSCF.
Table A.3.6-27: 200 (OK) response (S-CSCF to P-CSCF)
SIP/2.0 200 OK
Via: SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
From:
To:
Call-ID:
CSeq:
Content-Type:
Content-Length:
v=
o=
s=
c=
t=
m=
b=
a=
a=
a=
a=
a=
a=
a=
28. 200 (OK) response (P-CSCF to UE) – see example in table A.3.6-28
The P-CSCF forwards the 200 (OK) response to the UE.
Table A.3.6-28: 200 (OK) response (P-CSCF to UE)
SIP/2.0 200 OK
Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
From:
To:
Call-ID:
CSeq:
Content-Type:
Content-Length:
v=
o=
s=
c=
t=
m=
b=
a=
a=
a=
a=
a=
a=
a=
29. 200 (OK) response (MRFC/AS to S-CSCF) – see example in table A.3.6-29 (related to table A.3.6-6)
After the success modification of the session (26), the MRFC/AS sends a 200 (OK) response final response to the INVITE request (6) to the S-CSCF.
Table A.3.6-29: 200 (OK) response (MRFC/AS to S-CSCF)
SIP/2.0 200 OK
Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
Record-Route: <sip:scscf1.home1.net;lr>, <sip:pcscf1.visited1.net;lr>
From:
To:
Call-ID:
CSeq: 127 INVITE
Contact: <sip:conference1@mrfc1.home1.net>;isfocus
Allow-Events: conference, pending-additions
Content-Length:0
Contact: Contains the conference URI for the conference allocated at the MRFC/AS and the "isfocus" feature parameter.
Allow-Events: The MRFC/AS indicates support for the "conference" and "pending-additions" event packages
30. 200 (OK) response (S-CSCF to P-CSCF) – see example in table A.3.6-30
The S-CSCF sends a 200 (OK) response final response along the signalling path back to the P-CSCF.
Table A.3.6-30: 200 (OK) response (S-CSCF to P-CSCF)
SIP/2.0 200 OK
Via: SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
Record-Route:
From:
To:
Call-ID:
CSeq:
Contact:
Allow-Events:
Content-Length:
31. Approval of QoS commit
The P-CSCF approves the commitment of the QoS resources if it was not approved already in step (12).
32. 200 (OK) response (P-CSCF to UE) – see example in table A.3.6-32
The P-CSCF forwards the 200 (OK) response final response to the session originator. The UE can start the media flow(s) for this session.
Table A.3.6-32: 200 (OK) response (P-CSCF to UE)
SIP/2.0 200 OK
Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
Record-Route: <sip:scscf1.home1.net;lr>, <sip:pcscf1.visited1.net:7531;lr;comp=sigcomp>
From:
To:
Call-ID:
CSeq:
Contact:
Allow-Events:
Content-Length:
33. ACK request (UE to P-CSCF) – see example in table A.3.6-33
The UE starts the media flow for this session, and responds to the 200( OK) response (32) with an ACK request sent to the P-CSCF.
Table A.3.6-33: ACK request (UE to P-CSCF)
ACK sip:conference1@mrfc1.home1.net:2342 SIP/2.0
Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
Max-Forwards: 70
Route: <sip:pcscf1.visited1.net:7531;lr;comp=sigcomp>, <sip:scscf1.home1.net;lr>From: <sip:user1_public1@home1.net>; tag=171828
To: <sip:conference-factory1@mrfc1.home1.net>;tag=314159
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 127 ACK
Content-Length: 0
34. ACK request (P-CSCF to S-CSCF) – see example in table A.3.6-34
The P-CSCF forwards the ACK request to the S-CSCF.
Table A.3.6-34: ACK request (P-CSCF to S-CSCF)
ACK sip:conference1@mrfc1.home1.net:2342 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:scscf1.home1.net;lr>
From:
To:
Call-ID:
Cseq:
Content-Length:
35. ACK request (S-CSCF to MRFC/AS) – see example in table A.3.6-35
The S-CSCF forwards the ACK request to the MRFC/AS.
Table A.3.6-35: ACK request (S-CSCF to MRFC/AS)
ACK sip:conference1@mrfc1.home1.net:2342 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
From:
To:
Call-ID:
Cseq:
Content-Length: