Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 23.228  Word version:  18.4.0

Top   Top   Up   Prev   Next
1…   3…   4…   4.2.4…   4.3…   4.4…   4.13…   4.16…   5…   5.2…   5.3…   5.4…   5.4.7…   5.4.8…   5.4a…   5.5…   5.5.3…   5.6…   5.6.3…   5.7…   5.7.3…   5.7.5…   5.7.8…   5.8…   5.10…   5.11…   5.11.3…   5.11.3.3   5.11.3.4   5.11.4…   5.11.5…   5.11.5.3…   5.11.6…   5.12…   5.16…   5.16.2…   5.19…   5.20…   A…   E…   E.2.2…   G…   G.5…   H   I…   J…   K…   L…   M…   M.3…   N…   P…   Q…   Q.2.5…   R…   S…   T…   U…   U.2…   V…   W…   X…   Y…   Z…   AA…   AA.3…   AB…   AC…   AC.7…   AC.7.2…   AC.7.2.2   AC.7.2.3…   AC.7.4…   AC.9…

 

5.11.3.3  Codec or media characteristics flow change requiring new resources and/or authorizationp. 166

After the multi-media session is established, it is possible for either endpoint to change the set of media flows or media characteristics (e.g. codecs) for media flow(s). If the change requires different resources beyond those previously reserved, then it is necessary to perform the resource reservation and bearer establishment procedures. If the reservation request fails for whatever reason, the original multi-media session remains in progress.
The flow presented here assumes that Policy and Charging Control is in use.
Reproduction of 3GPP TS 23.228, Fig. 5.32: Codec or media flow change - new reservation
Up
The detailed procedure is as follows:
Step 1.
UE#1 inserts the revised set of codecs to a SDP payload. The inserted codec(s) shall reflect the UE#1's terminal capabilities and user preferences for the session. It builds a SDP 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.
Step 2.
UE#1 sends an INVITE message to P-CSCF#1 containing this SDP.
Step 3.
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 modification attempt. This rejection shall contain sufficient information for the originating UE to re-attempt session modification with media parameters that are allowed by local policy of P-CSCF#1's network according to the procedures specified in RFC 3261.
In this flow described in Figure 5.32 above the P-CSCF#1 allows the initial session modification attempt to continue.
Step 4.
P-CSCF#1 forwards the INVITE message to S-CSCF#1.
Step 5.
S-CSCF#1 examines the media parameters. If S-CSCF#1 finds media parameters that local policy or the originating user's subscriber profile does not allow to be used within an IMS session, it rejects the session modification attempt. This rejection shall contain sufficient information for the originating UE to re-attempt session modification with media parameters that are allowed by the originating user's subscriber profile and by local policy of S-CSCF#1's network according to the procedures specified in RFC 3261.
In this flow described in Figure 5.32 above the S-CSCF#1 allows the initial session modification attempt to continue.
Step 6.
S-CSCF#1 forwards the INVITE, through the S-S Session Flow Procedures, to S-CSCF#2.
Step 7.
S-CSCF#2 examines the media parameters. If S-CSCF#2 finds media parameters that local policy or the terminating user's subscriber profile does not allow to be used within an IMS session, it rejects the session modification attempt. This rejection shall contain sufficient information for the originating UE to re-attempt session modification with media parameters that are allowed by the terminating user's subscriber profile and by local policy of S-CSCF#2's network according to the procedures specified in RFC 3261.
In this flow described in Figure 5.32 above the S-CSCF#2 allows the initial session modification attempt to continue.
Step 8.
S-CSCF#3 forwards the INVITE message to P-CSCF#2.
Step 9.
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 modification attempt. This rejection shall contain sufficient information for the originating UE to re-attempt session modification with media parameters that are allowed by local policy of P-CSCF#2's network according to the procedures specified in RFC 3261.
In this flow described in Figure 5.32 above the P-CSCF#2 allows the initial session modification attempt to continue.
Step 10.
P-CSCF#2 forwards the INVITE message to UE#2.
Step 11.
UE#2 determines the complete set of codecs that it is capable of supporting for this session. It determines the intersection with those appearing in the SDP in the INVITE message. For each media flow that is not supported, UE#2 inserts a SDP entry for media (m= line) with port=0. For each media flow that is supported, UE#2 inserts a SDP entry with an assigned port and with the codecs in common with those in the SDP from UE#1.
Step 12.
UE#2 returns the SDP listing common media flows and codecs to P-CSCF#2. It may additionally provide more codecs than originally offered and then the offered set need to be renegotiated.
Step 13.
P-CSCF#2 increases the authorization for the QoS resources, if needed, for the remaining media flows and codec choices.
Step 14.
P-CSCF#2 forwards the SDP response to S-CSCF#2 toward the originating end along the signalling path.
Step 15.
P-CSCF#1 increases the authorization for the QoS resources, if needed, for the remaining media flows and codec choices.
Step 16.
P-CSCF#1 forwards the SDP response to UE#1.
Step 17.
UE#1 determines which media flows should be used for this session, and which codecs should be used for each of those media flows. If there was more than one media flow, or if there was more than one choice of codec for a media flow, then UE#1 must include an SDP in the response message by including SDP to UE#2.
Step 18.
UE#1 sends the offered SDP message to UE#2, including the SDP from step #17 if needed.
Step 19.
UE#1 and UE#2 reserve the resources needed for the added or changed media flows. If the reservation is successfully completed by UE#1, it stops transmitting any deleted media streams. If UE#1 has sent a new media offer in step 18, it would for example wait for the response in step 20 prior to reserving resources.
Step 20.
If UE#1 has sent an updated offer of SDP in step 18, then UE#2 responds to the offer and P-CSCF#1 authorizes the offered SDP sent by UE#2.
Step 21.
UE#1 sends the Resource Reservation Successful message with final SDP to UE#2, via the signalling path through the CSCFs.
Step 22.
UE#2 stops sending the media streams to be deleted, and initialises its media receivers for the new codec.
Step 23.
UE#2 sends the 200-OK final response to UE#1, along the signalling path.
Step 24.
UE#1 starts sending media using the new codecs. UE#1 also releases any excess resources no longer needed.
Step 25.
UE#1 sends the SIP final acknowledgement, ACK, to UE#2 along the signalling path.
Step 26.
UE#2 starts sending media using the new codecs. UE#2 also releases any excess resources no longer needed.
Up

Up   Top   ToC