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]
