Content for  TS 23.228  Word version:  19.0.0

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.

UE#1 sends an INVITE message to P-CSCF#1 containing this SDP.

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.

P-CSCF#1 forwards the INVITE message to S-CSCF#1.

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.

S-CSCF#1 forwards the INVITE, through the S-S Session Flow Procedures, to S-CSCF#2.

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.

S-CSCF#3 forwards the INVITE message to P-CSCF#2.

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.

P-CSCF#2 forwards the INVITE message to UE#2.

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.

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.

P-CSCF#2 increases the authorization for the QoS resources, if needed, for the remaining media flows and codec choices.

P-CSCF#2 forwards the SDP response to S-CSCF#2 toward the originating end along the signalling path.

P-CSCF#1 increases the authorization for the QoS resources, if needed, for the remaining media flows and codec choices.

P-CSCF#1 forwards the SDP response to UE#1.

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.

UE#1 sends the offered SDP message to UE#2, including the SDP from step #17 if needed.

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.

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.

UE#1 sends the Resource Reservation Successful message with final SDP to UE#2, via the signalling path through the CSCFs.

UE#2 stops sending the media streams to be deleted, and initialises its media receivers for the new codec.

UE#2 sends the 200-OK final response to UE#1, along the signalling path.

UE#1 starts sending media using the new codecs. UE#1 also releases any excess resources no longer needed.

UE#1 sends the SIP final acknowledgement, ACK, to UE#2 along the signalling path.

UE#2 starts sending media using the new codecs. UE#2 also releases any excess resources no longer needed.