5.11.3 Procedures for codec and media characteristics flow negotiations

23.2283GPPIP Multimedia Subsystem (IMS)Release 18Stage 2TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

5.11.3.0 General

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

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.

Figure 5.30: Codec negotiation during initial session establishment

The detailed procedure is as follows:

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.

2. UE#1 sends the initial INVITE message to P‑CSCF#1 containing this SDP

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 IETF RFC 3261 [12].

In this flow described in Figure 5.30 above the P‑CSCF#1 allows the initial session initiation attempt to continue.

NOTE 1: Whether the P‑CSCF should interact with PCRF/PCF in this step is based on operator policy.

4. P‑CSCF#1 forwards the INVITE message to S‑CSCF#1

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 IETF RFC 3261 [12].

In this flow described in Figure 5.30 above the S‑CSCF#1 allows the initial session initiation attempt to continue.

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

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 IETF RFC 3261 [12].
In this flow described in Figure 5.30 above the S‑CSCF#2 allows the initial session initiation attempt to continue.

8. S‑CSCF#2 forwards the INVITE message to P‑CSCF#2.

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 IETF RFC 3261 [12].

In this flow described in Figure 5.30 above the P‑CSCF#2 allows the initial session initiation attempt to continue.

NOTE 2: Whether the P‑CSCF should interact with PCRF/PCF in this step is based on operator policy.

10. P‑CSCF#2 forwards the INVITE message to UE#2.

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.

12. UE#2 returns the SDP listing common media flows and codecs to P‑CSCF#2

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

14. P‑CSCF#2 forwards the SDP response to S‑CSCF#2.

15. S‑CSCF#2 forwards the SDP response to S‑CSCF#1.

16. S‑CSCF#1 forwards the SDP response to P‑CSCF#1.

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

18. P‑CSCF#1 forwards the SDP response to UE#1.

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.

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

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.

Figure 5.31: Codec or media flow change – same reservation

The detailed procedure is as follows:

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.

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.

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 5.11.3.1). UE#2 stops sending the media streams to be deleted, and initialises its media receivers for the new codec.

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

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

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

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

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.

Figure 5.32: Codec or media flow change – new reservation

The detailed procedure is as follows:

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.

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

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 IETF RFC 3261 [12].
In this flow described in Figure 5.32 above the P‑CSCF#1 allows the initial session modification attempt to continue.

NOTE 1: Whether the P‑CSCF interacts with PCRF/PCF in this step is based on operator policy.

4. P‑CSCF#1 forwards the INVITE message to S‑CSCF#1.

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 IETF RFC 3261 [12].
In this flow described in Figure 5.32 above the S‑CSCF#1 allows the initial session modification attempt to continue.

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

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 IETF RFC 3261 [12].
In this flow described in Figure 5.32 above the S‑CSCF#2 allows the initial session modification attempt to continue.

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

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 IETF RFC 3261 [12].
In this flow described in Figure 5.32 above the P‑CSCF#2 allows the initial session modification attempt to continue.

NOTE 2: If session modification request indicates no requirements for resource reservation or that the required resources are already available on the originating side, the P‑CSCF#2 can send updated session information to PCRF/PCF whenever SDP offer is contained in the session establishment request, as in such cases no SDP answer is received before the PCRF/PCF is requested to authorize the required QoS resources. Otherwise, whether the P‑CSCF interacts with PCRF/PCF in this step is based on operator policy.

10. P‑CSCF#2 forwards the INVITE message to UE#2.

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.

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

NOTE 3: P‑CSCF can additionally authorize the resources in step 9.

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

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

16. P‑CSCF#1 forwards the SDP response to UE#1.

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.

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

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.

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.

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

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

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

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

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

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

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.

Figure 5.33: Multimedia session flow – addition of another media

Step-by-step processing of this end-to-end session flow is as follows:

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.

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.

3. S‑CSCF#1 validates the service profile, and invokes whatever service logic is appropriate for this session attempt.

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.

5. S‑CSCF#2 validates the service profile, and invokes whatever service logic is appropriate for this session attempt.

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.

7. P‑CSCF#2 remembers (from the registration procedure) the address of UE#2 and forwards the INVITE to UE#2.

NOTE 1: If session modification request indicates no requirements for resource reservation or that the required resources are already available on the originating side, the P‑CSCF#2 can send updated session information to PCRF/PCF whenever SDP offer is contained in the session establishment request, as in such cases no SDP answer is received before the PCRF/PCF is requested to authorize the required QoS resources. Otherwise, whether the P‑CSCF interacts with PCRF/PCF in this step is based on operator policy.

8. UE#2 returns the media stream capabilities of the destination to the session originator, along the signalling path established by the INVITE message.

9. P‑CSCF#2 authorizes the QoS resources required for this additional media.

NOTE 2: P‑CSCF can additionally authorize the resources in step 7.

10. P‑CSCF#2 forwards the SDP to S‑CSCF#2.

11. S‑CSCF#2 forwards the SDP to S‑CSCF#1.

12. S‑CSCF#1 forwards the SDP message to P‑CSCF#1.

13. P‑CSCF#1 authorizes the additional resources necessary for this new media.

14. P‑CSCF#1 forwards the SDP message to the originating endpoint, UE#1.

15-19. The originator decides the offered set of media streams for this media addition, and sends the offered SDP to P‑CSCF#1.

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.

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.

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.

25a. P‑CSCF#1 authorizes any additional media for the proposed SDP.

26. P‑CSCF#1 forwards the message to UE#1.

27-31. UE#1 sends the final agreed SDP to UE#2 via the established path.

32-35. UE#2 responds to the offered final media.

35a. P‑CSCF#1 authorizes the media agreed.

36. The response is forwarded to UE#1.

37. UE#2 may optionally delay the session establishment in order to alert the user to the incoming additional media.

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.

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.

40. S‑CSCF#2 forwards the message to S‑CSCF#1.

41. S‑CSCF#1 forwards the message to P‑CSCF#1.

42. P‑CSCF#1 forwards the message to UE#1.

43. UE#1 indicates to the originator that the media addition is being delayed due to alerting. Typically this involves playing a ringback sequence.

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.

44a. After sending the 200-OK, UE#2 may initiate the new media flow(s).

45. P‑CSCF#2 enables the media flows authorized for this additional media.

46. P‑CSCF#2 forwards the final response to S‑CSCF#2.

47. S‑CSCF#2 forwards the final response to S‑CSCF#1.

48. S‑CSCF#1 forwards the final response to P‑CSCF#1.

49. P‑CSCF#1 enables the media flows authorized for this additional media.

50. P‑CSCF#1 forwards the final response to UE#1.

51. UE#1 starts the media flow(s) for this additional media.

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.

53. P‑CSCF#1 forwards the ACK to S‑CSCF#1

54. S‑CSCF#1 forwards the ACK to S‑CSCF#2.

55. S‑CSCF#2 forwards the ACK to P‑CSCF#2.

56. P‑CSCF#2 forwards the ACK to UE#2.