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.
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.
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.
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.
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.
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.
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.
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#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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.