5.7a Procedures for the establishment of sessions without preconditions
23.2283GPPIP Multimedia Subsystem (IMS)Release 18Stage 2TS
5.7a.1 General
These clauses present the general end-to-end session flow procedures without preconditions. The flow in clause 5.7a.2 is applicable to services without real-time QoS requirements before session becomes active, and thus do not need to set-up dedicated IP‑CAN bearers but can use existing IP‑CAN bearers, and to services which do not require that the terminating endpoint obtains a SIP‑level notification when the originating endpoint’s IP‑CAN bearer becomes available.
NOTE: The flows in clauses 5.6 and 5.7 apply for services with real-time QoS requirements before session becomes active.
Note that the flows in these clauses do not show the use of a THIG. If a THIG is used, the use is completely analogous to the use in clauses 5.5, 5.6 and 5.7.
5.7a.2 Procedures for the establishment of sessions without preconditions – no resource reservation required before session becomes active
Figure 5.19h: End-to-end session flow procedure without preconditions – no resource reservation required before session becomes active
1. UE#1 sends the SIP INVITE request, containing an initial SDP, to the P‑CSCF#1 determined via the P‑CSCF discovery mechanism. The initial SDP may represent one or more media for a multi-media session. It should be noted that a media offer without preconditions in general implies that the offering entity might expect to receive incoming media for any of the offered media as soon as the offer is received by the other endpoint. Therefore either an existing IP‑CAN bearer is assumed to be available for use or the application is implemented such that incoming media is not expected until some later point in time.
2. P‑CSCF#1 examines the media parameters. If P‑CSCF#1 finds media parameters not allowed to be used within an IMS session (based on P‑CSCF local policies, or if available bandwidth authorization limitation information coming from the PCRF/PCF), it rejects the session initiation attempt.
NOTE 0a: Whether the P‑CSCF should interact with PCRF/PCF in this step is based on operator policy.
3. P‑CSCF#1 forwards the INVITE request to S‑CSCF#1 along the path determined upon UE#1’s most recent registration procedure.
4. Based on operator policy S‑CSCF#1 validates the user’s service profile and may invoke whatever service control logic is appropriate for this INVITE request. This may include routing the INVITE request to an Application Server, which processes the request further on.
5. S‑CSCF#1 forwards INVITE request to I‑CSCF#2.
6. I‑CSCF#2 performs Location Query procedure with the HSS to acquire the S‑CSCF address of the destination user (S‑CSCF#2).
7. I‑CSCF#2 forwards the INVITE request to S‑CSCF#2.
8. Based on operator policy S‑CSCF#2 validates the user’s service profile and may invoke whatever service control logic is appropriate for this INVITE request. This may include routing the INVITE request to an Application Server, which processes the request further on.
9. S‑CSCF#2 forwards the INVITE request to P‑CSCF#2 along the path determined upon UE#2’s most recent registration procedure.
10. P‑CSCF#2 examines the media parameters. If P‑CSCF#2 finds media parameters not allowed to be used within an IMS session (based on P‑CSCF local policies, or if available bandwidth authorization limitation information coming from the PCRF/PCF), it rejects the session initiation attempt.
NOTE 0b: Whether the P‑CSCF should interact with PCRF/PCF in this step is based on operator policy.
11. P‑CSCF#2 forwards the INVITE request to UE#2.
12. – 17. UE#2 may optionally generate a ringing message towards UE#1.
18. Depending on the bearer establishment mode selected for the IP‑CAN session, resource reservation shall be initiated either by the UE or by the IP‑CAN itself. UE#2 may reserve a dedicated IP‑CAN bearer for media based on the media parameters received in the SDP offer as shown in Figure 5.19h. Otherwise, the IP‑CAN#2 initiates the reservation of required resources after step 20 instead.
NOTE 1: The sequential ordering of 18 and 19 does not indicate that these steps are necessarily performed one after the other. If step 19 is performed before step 18 is finished, UE#2 shall use an existing IP‑CAN bearer to send and receive media unless the application is such that a new bearer is not needed until some later point in time. If step 18 is performed successfully, media are sent and received by UE#2 on the dedicated IP‑CAN bearer.
19. UE#2 accepts the session with a 200 OK response. The 200 OK response is sent to P‑CSCF#2.
20. Based on operator policy P‑CSCF#2 may instruct PCRF/PCF to authorize the resources necessary for this session.
21. – 24. The 200 OK response traverses back to UE#1.
25. Based on operator policy P‑CSCF#1 may instruct the PCRF/PCF to authorize the resources necessary for this session.
26. P‑CSCF#1 forwards the 200 OK response to UE#1.
27. – 31. UE#1 acknowledges the 200 OK with an ACK, which traverses back to UE#2.
32. Depending on the bearer establishment mode selected for the IP‑CAN session, resource reservation shall be initiated either by the UE or by the IP‑CAN itself. UE#1 may reserve a dedicated IP‑CAN bearer for media based on the media parameters received in the SDP answer as shown in Figure 5.19h. Otherwise, the IP‑CAN#1 initiates the reservation of required resources after step 25.
NOTE 2: The sequential ordering of 27 and 32 does not indicate that these steps are necessarily performed one after the other. If step 32 is performed successfully, media are sent and received by UE#1 on the reserved dedicated IP‑CAN bearer. UE#1 may also use an existing IP‑CAN bearer to send and receive media.