idnits 2.17.1 draft-even-flow-control-to-zero-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The abstract seems to indicate that this document updates RFC5104, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (January 3, 2013) is 4125 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-05) exists of draft-westerlund-avtext-rtp-stream-pause-03 -- Obsolete informational reference (is this intentional?): RFC 5117 (Obsoleted by RFC 7667) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVTEXT WG R. Even 3 Internet-Draft January 3, 2013 4 Updates: RFC5104 (if approved) 5 Intended status: Standards Track 6 Expires: July 7, 2013 8 Pausing an RTP Media Stream 9 draft-even-flow-control-to-zero-00.txt 11 Abstract 13 In Real-time multimedia applications using multiple media streams in 14 point to point and multipoint calls can benefit from options that 15 will enable them to pause and resume media streams as well as to 16 indicate a mute state. This document describes the difference 17 between pause and mute and describes how to provide this required 18 functionality. This document updates RFC5104. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on July 7, 2013. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Pause and Resume . . . . . . . . . . . . . . . . . . . . . . . 4 57 4. Mute and Not Rendered . . . . . . . . . . . . . . . . . . . . . 4 58 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 59 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 60 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 61 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 63 8.2. Informative References . . . . . . . . . . . . . . . . . . 5 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 1. Introduction 68 Real-time multimedia communication topologies are typical point to 69 point or multipoint. The multipoint call may use an MCU or an RTP 70 mixer as specified in [RFC5117]. the call one of the parties may want 71 to stop receiving one of the media stream temporarily. In order to 72 do it the receiver will want the sender to stop sending media. 74 In the point to point case the receiver can ask the sender to reduce 75 the media rate to zero and later ask for a new bit rate. 77 In the multipoint case, the central mixer if not using one of the 78 streams may ask the sender to stop sending similar to the point to 79 point case. A multipoint conference participant receiving streams 80 from the MCU or RTP mixer behave like a point to point receiver in 81 this case asking the MCU or RTP mixer to stop sending media. For a 82 discussion on the use case look at section 3 of 83 [I-D.westerlund-avtext-rtp-stream-pause]. 85 During a point to point or multipoint call a sender may mute his 86 microphone or camera but still continue to send media which may be 87 some syntactic media. The receivers will benefit if they receive an 88 indication about this state so it can also indicate to the user that 89 the other side is muted. If the receiver is not rendering a stream 90 it may indicate to the sender that he is not being seen or heard at 91 the moment even though he is receiving the media stream. 93 To summarize there is a need for a pause and resume commands and for 94 mute and not rendered indications. 96 All this messages are used for temporary flow change during the call 97 and are intended to go end to end. The recommended proposal is to 98 use RTCP Codec Control Messages [RFC5104] to achieve this 99 functionality. 101 The document updates the current TMMBR message in [RFC5104] and adds 102 new indications for the mute and not rendered states. 104 2. Terminology 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in RFC2119[RFC2119] and 109 indicate requirement levels for compliant RTP implementations. 111 3. Pause and Resume 113 TMMBR as specified in [RFC5104] is used by video conferencing systems 114 for flow control. It will be useful if the same method can be used 115 for pause and resume. 117 For the pause request using TMMBR with bit rate "0" will make an RTP 118 media sender stop sending an RTP stream if it is used by others that 119 have not requested a pause. This is not a problem for the point to 120 point case and in the RTP media receiver to MCU/RTP mixer case in 121 section 3 of [I-D.westerlund-avtext-rtp-stream-pause] since there is 122 a single receiver on each call. The MCU / RTP mixer may send a pause 123 request to the RTP media sender if he is not using the RTP stream for 124 creating an outgoing stream. 126 RFC5104 [RFC5104] provides guidelines on how to apply an increase in 127 the temporary rate change when there are multiple receivers. It 128 recommends delaying the rate increase allowing all receivers to agree 129 with the change. The major reason for it is that RFC5104 [RFC5104] 130 allows using TMMBR to request a bandwidth that is higher than the 131 current one negotiated using SDP "b" attribute. 133 This document recommends that in order to create consistency between 134 the SDP negotiated bandwidth and TMMBR it will not be allowed to ask 135 in TMMBR for a bandwidth that is higher than the SDP negotiated one. 136 This may also be important for intermediaries that monitor bandwidth 137 usage based on SDP. Based on this change there is also no need for 138 the single receiver case to delay the increase in bandwidth when 139 resuming the media stream in the point to point or RTP media receiver 140 to MCU/ Mixer case. Note that TMMBR is request for maximum and the 141 MCU/ Mixer may send at a lower rate if he cannot provide a higher 142 rate based on the bit rate of the sender of this RTP media stream. 144 The MCU / Mixer may negotiate a higher bit rate using TMMBR / TMBBN 145 based on mixing /transcoding model supported. 147 The RTP media stream receiver will signal Pause by TMMBR with zero 148 value and Resume using TMMBR with the maximum bit rate that the 149 receiver wants. 151 4. Mute and Not Rendered 153 Place holder to add new indications if people feel that these 154 indications will be useful. 156 5. Acknowledgements 158 place holder 160 6. IANA Considerations 162 TBD 164 7. Security Considerations 166 TBD. 168 8. References 170 8.1. Normative References 172 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 173 Requirement Levels", BCP 14, RFC 2119, March 1997. 175 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 176 "Codec Control Messages in the RTP Audio-Visual Profile 177 with Feedback (AVPF)", RFC 5104, February 2008. 179 8.2. Informative References 181 [I-D.westerlund-avtext-rtp-stream-pause] 182 Akram, A., Burman, B., Grondal, D., and M. Westerlund, 183 "RTP Media Stream Pause and Resume", 184 draft-westerlund-avtext-rtp-stream-pause-03 (work in 185 progress), October 2012. 187 [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, 188 January 2008. 190 Author's Address 192 Roni Even 193 Tel Aviv, 194 Israel 196 Email: ron.even.tlv@gmail.com