Internet DRAFT - draft-even-avtext-flow-control-to-zero

draft-even-avtext-flow-control-to-zero






AVTEXT WG                                                        R. Even
Internet-Draft                                      >Huawei Technologies
Updates: RFC5104 (if approved)                          January 24, 2013
Intended status: Standards Track
Expires: July 28, 2013


                      Pausing an RTP Media Stream
             draft-even-avtext-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 28, 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 28, 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 28, 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 28, 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 28, 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
   >Huawei Technologies
   Tel Aviv,
   Israel

   Email: roni.even@mail01.huawei.com





Even                      Expires July 28, 2013                 [Page 5]