Content for TS 23.228 Word version: 18.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.6…
5.6.3…
5.7…
5.7.3…
5.7.5…
5.8…
5.11…
5.11.3…
5.11.4…
5.11.5…
5.11.6…
5.12…
5.16…
5.19
5.20…
A…
E…
E.2.2…
G…
G.5…
H…
J…
L…
N…
Q…
Q.2.5…
R…
S…
U…
U.2…
V…
Y…
Z…
AA…
AA.3…
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.3 Codec or media characteristics flow change requiring new resources and/or authorization
5.11.3.4 Sample MM session flow - addition of another media
...
...
5.11.3 Procedures for codec and media characteristics flow negotiations p. 161
5.11.3.0 General |R6| p. 161
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. 162
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.
The detailed procedure is as follows:
Step 1.
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.
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 [12].
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 [12].
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 [12].
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 [12].
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
5.11.3.2 Codec or media characteristics flow change within the existing reservation p. 164
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.
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
5.11.3.3 Codec or media characteristics flow change requiring new resources and/or authorization 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 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.
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 [12].
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 [12].
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 [12].
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 [12].
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.
5.11.3.4 Sample MM session flow - addition of another media p. 168
For this end-to-end session flow, we assume the originator is a UE located within the service area of the network operator to whom the UE is subscribed. The UE has already established an IM CN session and is generating an invite to add another media (e.g., video to a voice call) to the already established session. Note that the invite to add media to an existing session could be originated by either end. The invite, and subsequent flows, are assumed to follow the path determined when the initial session was established. Any I-CSCFs that were included in the initial session would be included in this session.
The originating party addresses a destination that is a subscriber of the same network operator.
The destination party is a UE located within the service area of the network operator to which it is subscribed.
The flow presented here assumes that Policy and Charging Control is in use.
Step-by-step processing of this end-to-end session flow is as follows:
Step 1.
UE#1 sends a SIP INVITE request, containing new SDP for the new media and including the original SDP, to P-CSCF#1, which was obtained from the CSCF discovery procedures.
Step 2.
P-CSCF#1 forwards the INVITE to the next hop name/address, as determined from the registration procedures. In this case the next hop is S-CSCF#1 within the same operator's network.
Step 3.
S-CSCF#1 validates the service profile, and invokes whatever service logic is appropriate for this session attempt.
Step 4.
S-CSCF#1 recognises that this invite applies to an existing session. It therefore forwards the INVITE along the existing path to S-CSCF#2.
Step 5.
S-CSCF#2 validates the service profile, and invokes whatever service logic is appropriate for this session attempt.
Step 6.
S-CSCF#2 remembers (from the registration procedure) the next hop CSCF for this UE. It forwards the INVITE to P-CSCF#2 in the home network.
Step 7.
P-CSCF#2 remembers (from the registration procedure) the address of UE#2 and forwards the INVITE to UE#2.
Step 8.
UE#2 returns the media stream capabilities of the destination to the session originator, along the signalling path established by the INVITE message.
Step 9.
P-CSCF#2 authorizes the QoS resources required for this additional media.
Step 10.
P-CSCF#2 forwards the SDP to S-CSCF#2.
Step 11.
S-CSCF#2 forwards the SDP to S-CSCF#1.
Step 12.
S-CSCF#1 forwards the SDP message to P-CSCF#1.
Step 13.
P-CSCF#1 authorizes the additional resources necessary for this new media.
Step 14.
P-CSCF#1 forwards the SDP message to the originating endpoint, UE#1.
Step 15-19.
The originator decides the offered set of media streams for this media addition, and sends the offered SDP to P-CSCF#1.
Step 20.
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 initiates the resource reservation procedures for the resources necessary for this additional media as shown in Figure 5.33. Otherwise, the IP-CAN initiates the reservation of required resources after step 9.
Step 21.
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. After determining the offered set of media streams for this additional media, in step #15 above, UE#1 initiates the reservation procedures for the additional resources needed for this new media as shown in Figure 5.33. Otherwise, the IP-CAN#1 initiates the reservation of required resources after step 13.
Step 22-25.
When the terminating side has successfully reserved the needed resources, it sends the "reservation successful" message to UE#1 along the signalling path established by the INVITE message. The message is sent first to P-CSCF#1.
Step 25a.
P-CSCF#1 authorizes any additional media for the proposed SDP.
Step 26.
P-CSCF#1 forwards the message to UE#1.
Step 27-31.
UE#1 sends the final agreed SDP to UE#2 via the established path.
Step 32-35.
UE#2 responds to the offered final media.
Step 35a.
P-CSCF#1 authorizes the media agreed.
Step 36.
The response is forwarded to UE#1.
Step 37.
UE#2 may optionally delay the session establishment in order to alert the user to the incoming additional media.
Step 38.
If UE#2 performs alerting, it sends a ringing indication to the originator via the signalling path. The message is sent first to P-CSCF#2.
Step 39.
P-CSCF#2 forwards the ringing message to S-CSCF#2.S-CSCF#2 invokes whatever service logic is appropriate for this ringing flow.
Step 40.
S-CSCF#2 forwards the message to S-CSCF#1.
Step 41.
S-CSCF#1 forwards the message to P-CSCF#1.
Step 42.
P-CSCF#1 forwards the message to UE#1.
Step 43.
UE#1 indicates to the originator that the media addition is being delayed due to alerting. Typically this involves playing a ringback sequence.
Step 44.
When the destination party accepts the additional media, UE#2 sends a SIP 200-OK final response along the signalling path back to the originator. The message is sent first to P-CSCF#2.
Step 44a.
After sending the 200-OK, UE#2 may initiate the new media flow(s).
Step 45.
P-CSCF#2 enables the media flows authorized for this additional media.
Step 46.
P-CSCF#2 forwards the final response to S-CSCF#2.
Step 47.
S-CSCF#2 forwards the final response to S-CSCF#1.
Step 48.
S-CSCF#1 forwards the final response to P-CSCF#1.
Step 49.
P-CSCF#1 enables the media flows authorized for this additional media.
Step 50.
P-CSCF#1 forwards the final response to UE#1.
Step 51.
UE#1 starts the media flow(s) for this additional media.
Step 52.
UE#1 responds to the final response with a SIP ACK message, which is passed to the destination via the signalling path. The message is sent first to P-CSCF#1.
Step 53.
P-CSCF#1 forwards the ACK to S-CSCF#1
Step 54.
S-CSCF#1 forwards the ACK to S-CSCF#2.
Step 55.
S-CSCF#2 forwards the ACK to P-CSCF#2.
Step 56.
P-CSCF#2 forwards the ACK to UE#2.
