7 Bearer control

26.2363GPPPacket switched conversational multimedia applicationsTransport protocolsTS

The media control is based on declaration of terminal media capability sets in SDP part of appropriate SIP messages. The usage of bearer bandwidth can be effectively controlled by adjusting the media type encoder bit rates.

7.1 Bandwidth

The bandwidth information of each media type shall be carried in SDP messages in both session and media type level during codec negotiation, session establishment and resource reallocation. Note that for RTP based applications, ‘b=AS:’ gives the RTP "session bandwidth” (including UDP/IP overhead) as defined in section 6.2 of [3].

The bandwidth for RTCP traffic shall be described using the "RS" and "RR" SDP bandwidth modifiers at media level, as specified by [28]. Therefore, a conversational multimedia terminal shall include the "b=RS:" and "b=RR:" fields in SDP, and shall be able to interpret them. There shall be a limit on the allowed RTCP bandwidth for a session signalled by the terminal. This limit is defined as follows:

  • 4000 bps for the RS field (at media level);
  • 3000 bps for the RR field (at media level).

If the session described in the SDP is a point-to-point speech only session (see clause 7.4), the UE should request the deactivation of RTCP by setting its RTCP bandwidth modifier to zero.

If a UE receives SDP bandwidth modifiers for RTCP equal to zero from the originating UE, it should reply (via the SIP protocol) by setting its RTCP bandwidth using SDP bandwidth modifiers with values equal to zero.

7.2 QoS negotiation

The QoS architecture and concept is specified in 3GPP TS 23.107 [9]. The end-to-end QoS framework involving GPRS and UMTS is specified in 3GPP TS 23.207 [10]. The applicable general QoS mechanism and service description for the GPRS in GSM and UMTS is specified in 3GPP TS 23.060 [11].

7.3 RTP receiver

The RTP receiver implementation shall also include an RTCP implementation.

The RTP receiver implementation and functionality including lost and delayed packet processing as well as jitter buffer is out of scope of the present document.

7.4 RTP sender

The RTP sender implementation shall also include an RTCP implementation.

To facilitate traversal of NAT and Firewall gateways, RTP sender implementations should transmit their RTP stream from the same IP address and port on which it has advertised to receive RTP in its SDP. Similarly, RTCP sender implementations should transmit their RTCP stream from the same IP address port on which it has advertised to receive RTCP in its SDP a=rtcp attribute.

RTCP packets should be sent for all types of multimedia sessions except for point-to-point speech only sessions (i.e., using AMR and the AMR-WB codecs where synchronization with other RTP transported media or remote end-point aliveness information are not needed). For point-to-point speech only sessions, a UE should not send RTCP packets. Turning off RTCP can be done by setting to zero the SDP bandwidth modifiers (RR and RS) described in clause 7.1.When RTCP is turned off (for point-to-point speech only sessions) and the media is put on hold, the terminal should re-negotiate the RTCP bandwidth with SDP bandwidth modifiers values greater than zero, and send RTCP packets to the other end, following the rules given below. This allows the remote end to detect link aliveness during hold. When media is resumed, the resuming terminal should turn off the RTCP sending again through a re-negotiation of the RTCP bandwidth with SDP bandwidth modifiers (as described in clause 7.1) equal to zero.

When RTCP is turned off (for point-to-point speech only sessions) and if sending of an additional associated RTP flow becomes required and both RTP flows need to be synchronized, or if transport feedback due to lack of end-to-end QoS guarantees is needed, a terminal should re-negotiate the bandwidth for RTCP by sending an SDP with the RS bandwidth modifier greater than zero.

Note: For speech sessions where RTCP is not turned off, to reduce the potential disruption of RTCP onto the RTP flow, it is beneficial to keep the RTCP bandwidth and the size of RTCP packets as small as possible. RTCP packet size can be minimized by only using the optional parts of RTCP (according to [3]) which are required by the application. A practical size limit for the RTCP sender is in the order of 2 to 5 times the RTP packet size. Additionally, the RTCP sender can attempt to schedule RTCP packets during speech inactivity periods. For example, if an RTCP packet is scheduled at a future time and a silence period starts, this RTCP packet could be sent immediately. The subsequent RTCP packets would be scheduled according to the normal rules (i.e. as if the previous packet was sent as originally scheduled).

Annex A (informative):
Optional enhancements

This annex is intended for informational purposes only. This is not an integral part of the present document.