Content for TS 23.228 Word version: 19.0.0

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… AC.10…

5.11.3 Procedures for codec and media characteristics flow negotiations 5.11.3.0 General 5.11.3.1 Codec and media characteristics flow negotiation during initial session establishment 5.11.3.2 Codec or media characteristics flow change within the existing reservation
...

5.11.3 Procedures for codec and media characteristics flow negotiations p. 162

5.11.3.0 General |R6| p. 162

This clause gives information flows for:

the procedures for determining the set of negotiated characteristics between the endpoints of a multi-media session, determining the initial media characteristics (including common codecs) to be used for the multi-media session, and
the procedures for modifying a session within the existing resources reservation or with a new resources reservation (adding/deleting a media flow, changing media characteristics including codecs, changing bandwidth requirements) when the session is already established.

5.11.3.1 Codec and media characteristics flow negotiation during initial session establishment p. 163

Initial session establishment in the IM CN subsystem must determine a negotiated set of media characteristics (including a common codec or set of common codecs for multi-media sessions) that will be used for the session. This is done through an end-to-end message exchange to determine the complete set of media characteristics, then the decision is made by the session initiator as to the initial set of media flows.

The session initiator includes an SDP in the SIP INVITE message that lists every media characteristics (including codecs) that the originator is willing to support for this session. When the message arrives at the destination endpoint, it responds with the media characteristics (e.g. common subset of codecs) that it is also willing to support for the session. Media authorization is performed for these media characteristics. The session initiator, upon receiving the common subset, determines the media characteristics (including codecs) to be used initially.

The negotiation may take multiple media offered and answered between the end points until the media set is agreed upon.

Once the session is established, the procedures of clause 5.11.3.2 may be used by either endpoint to change to a different media characteristic (e.g. codec) that was included in the initial session description, and for which no additional resources are required for media transport. The procedures of clause 5.11.3.3 may be used by either endpoint to change the session, which requires resources beyond those allocated to the existing session.

The flow presented here assumes that Policy and Charging Control is in use.

Reproduction of 3GPP TS 23.228, Fig. 5.30: Codec negotiation during initial session establishment

Figure 5.30: Codec negotiation during initial session establishment

The detailed procedure is as follows:

Step 1.

UE#1 inserts the codec(s) to a SDP payload. The inserted codec(s) shall reflect the UE#1's terminal capabilities and user preferences for the session capable of supporting for this 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 the initial 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 initiation attempt. This rejection shall contain sufficient information for the originating UE to re-attempt session initiation 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.30 above the P-CSCF#1 allows the initial session initiation 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 initiation attempt. This rejection shall contain sufficient information for the originating UE to re-attempt session initiation 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.30 above the S-CSCF#1 allows the initial session initiation 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 initiation attempt. This rejection shall contain sufficient information for the originating UE to re-attempt session initiation 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.30 above the S-CSCF#2 allows the initial session initiation attempt to continue.

Step 8.

S-CSCF#2 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 initiation attempt. This rejection shall contain sufficient information for the originating UE to re-attempt session initiation 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.30 above the P-CSCF#2 allows the initial session initiation 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

Step 13.

P-CSCF#2 authorizes the QoS resources for the remaining media flows and codec choices.

Step 14.

P-CSCF#2 forwards the SDP response to S-CSCF#2.

Step 15.

S-CSCF#2 forwards the SDP response to S-CSCF#1.

Step 16.

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

Step 17.

P-CSCF#1 authorizes the QoS resources for the remaining media flows and codec choices.

Step 18.

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

Step 19.

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 need to renegotiate the codecs by sending another offer to reduce codec to one with the UE#2.

Step 20-24.

UE#1 sends the "Offered SDP" message to UE#2, along the signalling path established by the INVITE request

The remainder of the multi-media session completes identically to a single media/single codec session, if the negotiation results in a single codec per media.

5.11.3.2 Codec or media characteristics flow change within the existing reservation p. 165

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 flows. If the change is within the resources already reserved, then it is only necessary to synchronise the change with the other endpoint. Note that an admission control decision will not fail if the new resource request is within the existing reservation.

The flow presented here assumes that Policy and Charging Control is in use.

Reproduction of 3GPP TS 23.228, Fig. 5.31: Codec or media flow change - same reservation

Figure 5.31: Codec or media flow change - same reservation

The detailed procedure is as follows:

Step 1.

UE#1 determines that a new media stream is desired, or that a change is needed in the codec in use for an existing media stream. UE#1 evaluates the impact of this change, and determines the existing resources reserved for the session are adequate. UE#1 builds a revised SDP that includes all the common media flows determined by the initial negotiation, but assigns a codec and port number only to those to be used onward. UE#1 stops transmitting media streams on those to be dropped from the session.

Step 2-6.

UE#1 sends an INVITE message through the signalling path to UE#2. At each step along the way, the CSCFs recognise the SDP is a proper subset of that previously authorized, and take no further action.

Step 7.

UE#2 receives the INVITE message, and agrees that it is a change within the previous resource reservation. (If not, it would respond with a SDP message, following the procedures of clause 5.11.3.1). UE#2 stops sending the media streams to be deleted, and initialises its media receivers for the new codec.

Step 8-12.

UE#2 forwards a 200-OK final response to the INVITE message along the signalling path back to UE#1.

Step 13.

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

Step 14-18.

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

Step 19.

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