A.4.2 User calling into a conference

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

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

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

A.4.2.1.1 Conference URI resolved by the terminating home network

Figure A.4.2.1.1-1: User calling into a conference – network MRFC/AS is not located in user’s home network – conference URI resolved by the terminating home network

Figure A.4.2.1.1-1 shows an user calling into a conference by using a conference URI. The focus of that conference is at a MRFC/AS which are located in another network. The conference URI in this example cannot be resolved by the originating home network.

The details of the flows are as follows:

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

A UE wants to join a conference. For this purpose the UE is aware of the related conference URI that was obtained by means outside the present document (e.g. 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.capable of sending two simultaneous video streams, either H261 or The UE sends the INVITE request to the P-CSCF.

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

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

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

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

INVITE sip:conference1@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:conference1@home2.net>

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 127 INVITE

Require: sec-agree

Proxy-Require: sec-agree

Supported: precondition, 100rel, 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, 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 URI.

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

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

Table A.4.2.1.1-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.4.2.1.1-3

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

Table A.4.2.1.1-3: INVITE request (P-CSCF to S-CSCF)

INVITE sip:conference1@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: (…)

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

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

Table A.4.2.1.1-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.4.2.1.1-6

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

As the S-CSCF 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.2.1.1-6: INVITE request (S-CSCF to I-CSCF)

INVITE sip:conference1@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: (…)

7. 100 (Trying) response (I-CSCF to S-CSCF) – see example in table A.4.2.1.1-7 (related to table A.4.2.1.1-6)

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

Table A.4.2.1.1-7: 100 (Trying) response (MRFC/AS 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 sends a query to the HSS to find out the MRFC/AS at which the conference has been created. The HSS responds with the address of the MRFC/AS at which the conference is hosted. The HSS responds with the address of the MRFC/AS.

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

Table A.4.2.1.1-8a provides the parameters in the SIP INVITE request, which are sent to the HSS.

Table A.4.2.1.1-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.4.2.1.1-8b provides the parameters sent from the HSS that need to be mapped to SIP INVITE and sent to MRFC/AS.

Table A.4.2.1.1-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.4.2.1.1-9

I-CSCF forwards the INVITE request to the MRFC/AS that was resolved during the PSI location query (8). The I-CSCF does not re-write the Request URI.

Table A.4.2.1.1-9: INVITE request (I-CSCF to MRFC/AS)

INVITE sip:conference1@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

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: (…)

10. 100 (Trying) response (MRFC/AS to I-CSCF) – see example in table A.4.2.1.1-10 (related to table A.4.2.1.1-9)

The MRFC/AS responds to the INVITE request (9) with a 100 (Trying) response provisional response.

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

SIP/2.0 100 (Trying) response

From:

To:

Call-ID:

CSeq:

Content-Length: 0

11. H.248 interaction to create conference connection resources for UE#1

MRFC initiates a H.248 interaction to create an connection point for UE#1 in MRFP.

12. 183 (Session Progress) response (MRFC/AS to I-CSCF) – see example in table A.4.2.1.1-12 (related to table A.4.2.1.1-9)

The media stream capabilities of the conference are returned along the signalling path, in a 183 (Session Progress) provisional response (to 9).

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

SIP/2.0 183 Session Progress

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:conference1@home2.net>; tag=314159

Call-ID:

CSeq:

Require: precondition, 100rel

Contact: <sip:conference1@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 this header and populates the icid parameters with an unique value and the terminating Inter Operator Identifier (IOI) for the home network of the MRFC/AS and puts back the originating IOI.

P-Charging-Function-Addresses: The MRFC/AS populates the P-Charging-Function-Addresses header field to be passed to the I-CSCF.

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

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

Table A.4.2.1.1-13: 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:

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

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

Table A.4.2.1.1-14: 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:

15. 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 (38) based on operator local policy.

16. 183 (Session Progress) response (P-CSCF to UE) – see example in table A.4.2.1.1-16

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

Table A.4.2.1.1-16: 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:

17. Resource reservation

The originating UE sets up the bearer in accordance with the media description received SDP.

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

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.4.2.1.1-18: PRACK request (UE to P-CSCF)

PRACK sip:conference1@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:conference1@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

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

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

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

Table A.4.2.1.1-19: PRACK request (P-CSCF to S-CSCF)

PRACK sip:conference1@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:

20. PRACK request (S-CSCF to I-CSCF) – see example in table A.4.2.1.1-20

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

As the S-CSCF 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.2.1.1-20: PRACK request (S-CSCF to I-CSCF)

PRACK sip:conference1@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:

21. PRACK request (I-CSCF to MRFC/AS) – see example in table A.4.2.1.1-21

I-CSCF forwards the PRACK request to the MRFC/AS that was resolved during the PSI location query (8).

Table A.4.2.1.1-21: PRACK request (I-CSCF to MRFC/AS)

PRACK sip:conference1@home2.net SIP/2.0

Max-Forwards: 67

From:

To:

Call-ID:

Cseq:

Require:

RAck:

Content-Length:

22. 200 (OK) response (MRFC/AS to I-CSCF) – see example in table A.4.2.1.1-22 (related to table A.4.2.1.1‑21)

The MRFC/AS acknowledges the PRACK request (21) with a 200 (OK) response.

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

SIP/2.0 200 OK

From:

To:

Call-ID:

CSeq:

Content-Length: 0

23. H.248 interaction to modify connection for UE#1

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 (I-CSCF to S-CSCF) – see example in table A.4.2.1.1-24

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

Table A.4.2.1.1-24: 200 (OK) response (I-CSCF to S-CSCF)

SIP/2.0 200 OK

From:

To:

Call-ID:

CSeq:

Content-Length:

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

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

Table A.4.2.1.1-25: 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:

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

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

Table A.4.2.1.1-26: 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:

27. UPDATE request (UE to P-CSCF) – see example in table A.4.2.1.1-27

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.4.2.1.1-27: UPDATE request (UE to P-CSCF)

UPDATE sip:conference1@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:conference1@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/AVPF 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/AVPF 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

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

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

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

Table A.4.2.1.1-28: UPDATE request (P-CSCF to S-CSCF)

UPDATE sip:conference1@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:

29. UPDATE request (S-CSCF to I-CSCF) – see example in table A.4.2.1.1-29

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

As the S-CSCF 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.2.1.1-29: UPDATE request (S-CSCF to I-CSCF)

UPDATE sip:conference1@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:

30. UPDATE request (I-CSCF to MRFC/AS) – see example in table A.4.2.1.1-30

I-CSCF forwards the UPDATE request to the MRFC/AS that was resolved during the PSI location query (8). The I-CSCF does not re-write the Request URI.

Table A.4.2.1.1-30: UPDATE request (I-CSCF to MRFC/AS)

UPDATE sip:conference1@home2.net SIP/2.0

Max-Forwards: 67

From:

To:

Call-ID:

Cseq:

Content-Type:

Content-Length:

31. 200 (OK) response (MRFC/AS to I-CSCF) – see example in table A.4.2.1.1-31 (related to table A.4.2.1.1‑30)

The MRFC/AS acknowledges the UPDATE request (30) with a 200 (OK) response.

Table A.4.2.1.1-31: 200 (OK) response (MRFC/AS to I-CSCF)

SIP/2.0 200 OK

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.

32. H.248 interaction to modify connection

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

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

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

Table A.4.2.1.1-31: 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

From:

To:

Call-ID:

CSeq:

Content-Type: application/sdp

Content-Length: (…)

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

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

Table A.4.2.1.1-34: 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:

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

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

Table A.4.2.1.1-35: 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:

36. 200 (OK) response (MRFC/AS to I-CSCF) – see example in table A.4.2.1.1-36 (related to table A.4.2.1.1-9)

After the success modification of the session (32), the MRFC/AS sends a 200 (OK) response final response to the INVITE request (9) to the I-CSCF.

Table A.4.2.1.1-36: 200 (OK) response (MRFC/AS to I-CSCF)

SIP/2.0 200 OK

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

From:

To:

Call-ID:

CSeq: 127 INVITE

Contact: <sip:conference1@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

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

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

Table A.4.2.1.1-37: 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:

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

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

Table A.4.2.1.1-38: 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:

39. Approval of QoS commit

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

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

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.4.2.1.1-40: 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:

41. ACK request (UE to P-CSCF) – see example in table A.4.2.1.1-41

The UE starts the media flow for this session, and responds to the 200( OK) response (40) with an ACK request sent to the P-CSCF.

Table A.4.2.1.1-41: ACK request (UE to P-CSCF)

ACK sip:conference1@home2.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:conference1@home2.net>;tag=314159

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 127 ACK

Content-Length: 0

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

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

Table A.4.2.1.1-42: ACK request (P-CSCF to S-CSCF)

ACK sip:conference1@home2.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:

43. ACK request (S-CSCF to I-CSCF) – see example in table A.4.2.1.1-43

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

As the S-CSCF 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.2.1.1-43: ACK request (S-CSCF to I-CSCF)

ACK sip:conference1@home2.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:

44. ACK request (I-CSCF to MRFC/AS) – see example in table A.4.2.1.1-44

I-CSCF forwards the ACK request to the MRFC/AS that was resolved during the PSI location query (8). The I-CSCF does not re-write the Request URI.

Table A.4.2.1.1-44: ACK request (I-CSCF to MRFC/AS)

ACK sip:conference1@home2.net:2342 SIP/2.0

Max-Forwards: 67

From:

To:

Call-ID:

Cseq:

Content-Length:

A.4.2.1.2 Conference URI can be resolved by the originating home network

Figure A.4.2.1.2-1: User calling into a conference – MRFC/AS is not located in user’s home network –
conference URI can be resolved by the originating home network

Figure A.4.2.1.2-1 shows an user calling into a conference by using a conference URI. The focus of that conference is at a MRFC/AS which are located in another network. The conference URI in this example can be resolved by the originating home network.

The details of the flows are as follows:

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

A UE wants to join a conference. For this purpose the UE is aware of the related conference URI that was obtained by means outside the present document.

The UEindicates 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.

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

INVITE sip:conference1@mrfc2.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:conference1@mrfc2.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:MP4V-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 URI.

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

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

Table A.4.2.1.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.4.2.1.2-3

The INVITE request is forwarded to the S-CSCF.

Table A.4.2.1.2-3: INVITE request (P-CSCF to S-CSCF)

INVITE sip:conference1@mrfc2.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: (…)

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

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

Table A.4.2.1.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 MRFC/AS) – see example in table A.4.2.1.2-6

S-CSCF forwards the INVITE request to the MRFC/AS based on the Request URI of the INVITE request. The S-CSCF does not re-write the Request URI.

Table A.4.2.1.2-6: INVITE request (S-CSCF to MRFC/AS)

INVITE sip:conference1@mrfc2.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

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: (…)

7. 100 (Trying) response (MRFC/AS to S-CSCF) – see example in table A.4.2.1.2-7 (related to table A.4.2.1.2‑6)

The MRFC/AS responds to the INVITE request (6) with a 100 (Trying) response provisional response.

Table A.4.2.1.2-7: 100 (Trying) response (MRFC/AS 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. H.248 interaction to create conference connection resources for UE#1

MRFC initiates a H.248 interaction to create an connection point for UE#1 in MRFP.

9. 183 (Session Progress) response (MRFC/AS to S-CSCF) – see example in table A.4.2.1.2-9 (related to table A.4.2.1.2-6)

The media stream capabilities of the conference are returned along the signalling path, in a 183 (Session Progress) provisional response (to 6).

Table A.4.2.1.2-9: 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=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:conference1@mrfc2.home2.net>; tag=314159

Call-ID:

CSeq:

Require: precondition, 100rel

Contact: <sip:conference1@mrfc2.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::1111:2222:3333:4444

s=-

c=IN IP6 5555::1111:2222:3333:4444

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-Function-Addresses: The MRFC/AS populates the P-Charging-Function-Addresses header field to be passed to the S-CSCF.

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

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

Table A.4.2.1.2-10: 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:

11. 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 to the INVITE request (30) based on operator local policy.

12. 183 (Session Progress) response (P-CSCF to UE) – see example in table A.4.2.1.2-12

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

Table A.4.2.1.2-12: 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:

13. Resource reservation

The originating UE sets up the bearer in accordance with the media description received SDP.

14. PRACK request (UE to P-CSCF) – see example in table A.4.2.1.2-14

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.4.2.1.2-14: PRACK request (UE to P-CSCF)

PRACK sip:conference1@mrfc2.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:conference1@mrfc2.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

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

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

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

Table A.4.2.1.2-15: PRACK request (P-CSCF to S-CSCF)

PRACK sip:conference1@mrfc2.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:

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

S-CSCF forwards the PRACK request to the MRFC/AS based on the Request URI of the PRACK request. The S-CSCF does not re-write the Request URI.

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

PRACK sip:conference1@mrfc2.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:

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

The MRFC/AS acknowledges the PRACK request (16) with a 200 (OK) response.

Table A.4.2.1.2-17: 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

18. H.248 interaction to modify connection for UE#1

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

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

Table A.4.2.1.2-19: 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:

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

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

Table A.4.2.1.2-20: 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:

21. UPDATE request (UE to P-CSCF) – see example in table A.4.2.1.2-21

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.4.2.1.2-21: UPDATE request (UE to P-CSCF)

UPDATE sip:conference1@mrfc2.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:conference1@mrfc2.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

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

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

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

Table A.4.2.1.2-22: UPDATE request (P-CSCF to S-CSCF)

UPDATE sip:conference1@mrfc2.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:

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

S-CSCF forwards the UPDATE request to the MRFC/AS based on the Request URI of the UPDATE request. The S-CSCF does not re-write the Request URI.

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

UPDATE sip:conference1@mrfc2.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:

24. 200 (OK) response (MRFC/AS to S-CSCF) – see example in table A.4.2.1.2-24 (related to table A.4.2.1.2‑23)

The MRFC/AS acknowledges the UPDATE request (23) with a 200 (OK) response.

Table A.4.2.1.2-24: 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.

25. H.248 interaction to modify connection

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

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

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

Table A.4.2.1.2-26: 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:

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

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

Table A.4.2.1.2-27: 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:

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

After the success modification of the session (25), the MRFC/AS sends a 200 (OK) response final response to the INVITE request (6) to the I-CSCF.

Table A.4.2.1.2-28: 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@mrfc2.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

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

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

Table A.4.2.1.2-29: 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:

30. Approval of QoS commit

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

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

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.4.2.1.2-31: 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:

32. ACK request (UE to P-CSCF) – see example in table A.4.2.1.2-32

The UE starts the media flow for this session, and responds to the 200 (OK) response (31) with an ACK request sent to the P-CSCF.

Table A.4.2.1.2-32: ACK request (UE to P-CSCF)

ACK sip:conference1@mrfc2.home2.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:conference1@mrfc2.home2.net>;tag=314159

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 127 ACK

Content-Length: 0

Cseq: is required to be the same value as Cseq contained in original INVITE request (3).

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

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

Table A.4.2.1.2-33: ACK request (P-CSCF to S-CSCF)

ACK sip:conference1@mrfc2.home2.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:

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

S-CSCF forwards the ACK request to the MRFC/AS based on the Request URI of the ACK request. The S-CSCF does not re-write the Request URI.

Table A.4.2.1.2-34: ACK request (S-CSCF to MRFC/AS)

ACK sip:conference1@mrfc2.home2.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: