AVTEXT WG R. Even Internet-Draft January 3, 2013 Updates: RFC5104 (if approved) Intended status: Standards Track Expires: July 7, 2013 Pausing an RTP Media Stream draft-even-flow-control-to-zero-00.txt Abstract In Real-time multimedia applications using multiple media streams in point to point and multipoint calls can benefit from options that will enable them to pause and resume media streams as well as to indicate a mute state. This document describes the difference between pause and mute and describes how to provide this required functionality. This document updates RFC5104. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 7, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Even Expires July 7, 2013 [Page 1] Internet-Draft RTP Pause stream January 2013 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Pause and Resume . . . . . . . . . . . . . . . . . . . . . . . 4 4. Mute and Not Rendered . . . . . . . . . . . . . . . . . . . . . 4 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 8.2. Informative References . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 Even Expires July 7, 2013 [Page 2] Internet-Draft RTP Pause stream January 2013 1. Introduction Real-time multimedia communication topologies are typical point to point or multipoint. The multipoint call may use an MCU or an RTP mixer as specified in [RFC5117]. the call one of the parties may want to stop receiving one of the media stream temporarily. In order to do it the receiver will want the sender to stop sending media. In the point to point case the receiver can ask the sender to reduce the media rate to zero and later ask for a new bit rate. In the multipoint case, the central mixer if not using one of the streams may ask the sender to stop sending similar to the point to point case. A multipoint conference participant receiving streams from the MCU or RTP mixer behave like a point to point receiver in this case asking the MCU or RTP mixer to stop sending media. For a discussion on the use case look at section 3 of [I-D.westerlund-avtext-rtp-stream-pause]. During a point to point or multipoint call a sender may mute his microphone or camera but still continue to send media which may be some syntactic media. The receivers will benefit if they receive an indication about this state so it can also indicate to the user that the other side is muted. If the receiver is not rendering a stream it may indicate to the sender that he is not being seen or heard at the moment even though he is receiving the media stream. To summarize there is a need for a pause and resume commands and for mute and not rendered indications. All this messages are used for temporary flow change during the call and are intended to go end to end. The recommended proposal is to use RTCP Codec Control Messages [RFC5104] to achieve this functionality. The document updates the current TMMBR message in [RFC5104] and adds new indications for the mute and not rendered states. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119[RFC2119] and indicate requirement levels for compliant RTP implementations. Even Expires July 7, 2013 [Page 3] Internet-Draft RTP Pause stream January 2013 3. Pause and Resume TMMBR as specified in [RFC5104] is used by video conferencing systems for flow control. It will be useful if the same method can be used for pause and resume. For the pause request using TMMBR with bit rate "0" will make an RTP media sender stop sending an RTP stream if it is used by others that have not requested a pause. This is not a problem for the point to point case and in the RTP media receiver to MCU/RTP mixer case in section 3 of [I-D.westerlund-avtext-rtp-stream-pause] since there is a single receiver on each call. The MCU / RTP mixer may send a pause request to the RTP media sender if he is not using the RTP stream for creating an outgoing stream. RFC5104 [RFC5104] provides guidelines on how to apply an increase in the temporary rate change when there are multiple receivers. It recommends delaying the rate increase allowing all receivers to agree with the change. The major reason for it is that RFC5104 [RFC5104] allows using TMMBR to request a bandwidth that is higher than the current one negotiated using SDP "b" attribute. This document recommends that in order to create consistency between the SDP negotiated bandwidth and TMMBR it will not be allowed to ask in TMMBR for a bandwidth that is higher than the SDP negotiated one. This may also be important for intermediaries that monitor bandwidth usage based on SDP. Based on this change there is also no need for the single receiver case to delay the increase in bandwidth when resuming the media stream in the point to point or RTP media receiver to MCU/ Mixer case. Note that TMMBR is request for maximum and the MCU/ Mixer may send at a lower rate if he cannot provide a higher rate based on the bit rate of the sender of this RTP media stream. The MCU / Mixer may negotiate a higher bit rate using TMMBR / TMBBN based on mixing /transcoding model supported. The RTP media stream receiver will signal Pause by TMMBR with zero value and Resume using TMMBR with the maximum bit rate that the receiver wants. 4. Mute and Not Rendered Place holder to add new indications if people feel that these indications will be useful. Even Expires July 7, 2013 [Page 4] Internet-Draft RTP Pause stream January 2013 5. Acknowledgements place holder 6. IANA Considerations TBD 7. Security Considerations TBD. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", RFC 5104, February 2008. 8.2. Informative References [I-D.westerlund-avtext-rtp-stream-pause] Akram, A., Burman, B., Grondal, D., and M. Westerlund, "RTP Media Stream Pause and Resume", draft-westerlund-avtext-rtp-stream-pause-03 (work in progress), October 2012. [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, January 2008. Author's Address Roni Even Tel Aviv, Israel Email: ron.even.tlv@gmail.com Even Expires July 7, 2013 [Page 5]