idnits 2.17.1 draft-wu-avtcore-multisrc-endpoint-adver-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 22, 2012) is 4204 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) == Unused Reference: 'RFC4585' is defined on line 325, but no explicit reference was found in the text == Unused Reference: 'RFC5285' is defined on line 330, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-avtcore-multi-media-rtp-session-00' is defined on line 335, but no explicit reference was found in the text == Unused Reference: 'I-D.lennox-avtcore-rtp-multi-stream' is defined on line 340, but no explicit reference was found in the text == Unused Reference: 'I-D.wu-avtcore-multiplex-multisource-endpoint' is defined on line 346, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4595 (ref. 'RFC4585') ** Obsolete normative reference: RFC 5285 (Obsoleted by RFC 8285) == Outdated reference: A later version (-13) exists of draft-ietf-avtcore-multi-media-rtp-session-00 == Outdated reference: A later version (-02) exists of draft-lennox-avtcore-rtp-multi-stream-00 Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Audio/Video Transport Working Group Q. Wu 3 Internet-Draft R. Even 4 Intended status: Standards Track Huawei 5 Expires: April 25, 2013 October 22, 2012 7 Advertisement for multi-source endpoint multiplexing multiple media type 8 in the same RTP session 9 draft-wu-avtcore-multisrc-endpoint-adver-02.txt 11 Abstract 13 When two endpoints with multiple media sources are in communication, 14 each media source or each receiver within either endpoint may send or 15 receive reception report independently. This may incur a lot of 16 duplicated reception report to and from the endpoint with multiple 17 sources. This document discusses how to tackle these problems and 18 propose three phases for suppressing reception reports. 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 April 25, 2013. 37 Copyright Notice 39 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.1. Standards Language . . . . . . . . . . . . . . . . . . . . 4 57 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 58 3.1. Report Source Grouping . . . . . . . . . . . . . . . . . . 5 59 3.2. Report Source Election . . . . . . . . . . . . . . . . . . 5 60 3.3. Report Source Advertisement . . . . . . . . . . . . . . . 5 61 4. Protocol formats . . . . . . . . . . . . . . . . . . . . . . . 7 62 4.1. SDES item for Reception Report Sending . . . . . . . . . . 7 63 4.1.1. RRS: Reception Report Sending SDES Item . . . . . . . 7 64 4.2. SDES item for Reception Report Monitoring . . . . . . . . 7 65 4.2.1. RRM: Reception Report Monitoring SDES Item . . . . . . 8 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 68 6.1. New RTCP SDES Type values . . . . . . . . . . . . . . . . 10 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 71 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 74 1. Introduction 76 For some applications that use unicast transport, e.g., in RTCWeb 77 application, an endpoint with multiple media sources (i.e.,multiple- 78 source hosts, e.g., a client with several cameras) may use a 79 different SSRC for each medium but sending them in the same RTP 80 session, which reduces communication failure due to NAT and firewall 81 when using multiple RTP sessions or transport flows. 83 However when two endpoints with multiple media sources are in 84 communication, each media source within either endpoint may send 85 reception report independently and the receiving endpoint may not 86 know the reception reports received from different media source are 87 from the same sending endpoint. This creates the following three 88 problems: 90 o An endpoint with multiple media sources involved in one RTP 91 session may send the reception report with duplicated information 92 about the same remote media source from each of local media 93 sources. 95 o An endpoint with multiple media sources involved in one RTP 96 session may receive the reception report with duplicated 97 information about the same local media source from each of remote 98 media sources. 100 o An endpoint with multiple media sources involved in one RTP 101 session also may send reception reports about one of its own media 102 sources from another of its own (This is also referred to as RTCP 103 self-reporting). Such reception reports cause additional 104 redundant traffic travelling over the link between sending 105 endpoints and receiving endpoint, which changes the report 106 interval and may affect the media qualities. 108 This document discusses how to tackle these problems. Three phases 109 for suppressing reception reports are proposed. 111 o Grouping of media sources originate from a single endpoint and 112 classifying these media sources into multiple groups. 114 o Electing one single SSRC for reception report sending and one 115 single SSRC for reception report monitoring based on local policy. 117 o Advertising the SSRC that is used either for reception report 118 sending or reception report monitoring. 120 2. Terminology 122 2.1. Standards Language 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in RFC 2119 [RFC2119]. 128 3. Protocol Overview 130 In order to suppress unnecessary reception reports to and from multi- 131 source endpoint, multi-source endpoint should group media sources 132 originating from a single endpoint and elect one or a set of 133 specified SSRCs for reception report processing (e.g., reception 134 report sending, reception report receiving and reception report 135 monitoring). 137 3.1. Report Source Grouping 139 When an endpoint with multiple sources multiplexes multiple media 140 types in the same RTP session, the media source originating from the 141 same endpoint should be grouped together. Similarly the endpoint 142 with multiple sources may have multiple one or more than one report 143 source for monitoring. These report sources for monitoring should 144 also be grouped together. Therefore an endpoint with multiple 145 sources should at least split all its own media sources or receivers 146 into two groups(i.e., split SSRCs into two groups): One is sending 147 group, the other is monitoring group. Each group may have one or 148 several group members. Each group member is identified by a 149 different SSRC. 151 3.2. Report Source Election 153 When grouping for each endpoint with multiple sources is available, 154 in order to prevent group members receiving duplicated data, one or 155 more than one group member MUST be elected from sending group as 156 report source for reception report sending. When one report source 157 leaves the session or is down, another candidate report source can 158 replace instead. If the monitoring is used, each endpoint with 159 multiple sources MUST have at least one report source for monitoring 160 purpose. One or more than one reporting sources MUST be selected 161 from monitoring group for monitoring use. 163 Each endpoint with multiple sources at least has one SSRC for 164 reception report sending. If the monitoring is used, the endpoint 165 with multiple sources should choose another SSRC from monitoring 166 group as monitoring report source. 168 3.3. Report Source Advertisement 170 When report sources are elected for reception report sending, and 171 monitoring purpose respectively, it is necessary to signal which 172 report source is used for which purpose. 174 In this document we define two new SDES items to advertise the 175 reporting sources from endpoint with multiple sources that are used 176 for reception report sending and monitoring respectively (See section 177 5.1 and section 5.2 for protocol format details). 179 When those report sources are advertised, the selected report source 180 can send reception report about the same remote media source on 181 behalf of the media sources of its own, which prevent duplicated 182 reception report sent from all the local media sources of its own for 183 the same event. 185 If the other media source which is not selected as report source 186 knows or understands the advertised report source, it should suppress 187 the reception report for the same event. 189 If the other media source which is not selected as report source does 190 not know or understand the advertised report source and detects the 191 need to send reception report, this media source should wait for a 192 (short) random dithering interval to check whether it sees a 193 corresponding reception report message from any other receiver or 194 other media sources of its own reporting the same event. If a 195 corresponding reception report for the same event is received from 196 other media sources or any other receivers, it should refrain from 197 sending the reception report message. 199 In order to prevent duplicated reception report sent from one of its 200 own media sources to another of its own within the same endpoint with 201 multiple sources(i.e., self-reporting), the report source should know 202 the other media sources of its own and suppress sending the reception 203 report on the remote source to its own media sources. 205 Editor's note: Current draft does not discuss topologies like source 206 projection mixer where the mixer keeps the original ssrc so even 207 though they arrive from the mixer they have different CNAMEs. It 208 will be useful to discuss those topologies in the future version. 210 4. Protocol formats 212 Editor's note: It is not clear if you need to signal which one is 213 used or what is the group but if needed it may be better to allow the 214 sender to indicate which SSRCs are part of a group. It will also 215 require an negotiation in the offer/answer to verify that this mode 216 is supported by the stream senders. 218 4.1. SDES item for Reception Report Sending 220 This sub-section defines the format of the Reception Report Sending 221 SDES item. The SDES item is carried in the RTCP SDES packet. The 222 packet format for the RTCP SDES is defined in Section 6.5 of 223 [RFC3550]. Each SDES packet is composed of a header with fixed- 224 length fields for version, source count, packet type (PT), and 225 length, followed by zero or more chunks. Each chunk consists of an 226 SSRC/CSRC identifier followed by zero or more SDES items. If this 227 SDES item is carried, the CNAME SDES item should also be carried 228 together with this SDES item in the same chunk. In the SDES packet, 229 the PT field is set to SDES(202). 231 4.1.1. RRS: Reception Report Sending SDES Item 233 0 1 2 3 234 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | RRS=TBD | length | Candidate Report Source SSRC 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | .... 239 +-+-+-+-+-+-+-+-+ 241 The Reception Report Sending Item is not mandatory item and intended 242 for indicating the elected report source for an endpoint with 243 multiple sources, which is responsible for reception report sending. 244 The SSRC/CSRC identifier included in the same chunk (at the beginning 245 of this chunk) as the item is the SSRC of elected sending report 246 source. Additionally, this item may carry one or more than one 247 Candidate Report Source SSRCs. The candidate Report Source SSRC 248 follows the same format as SSRC/CSRC identifier defined in RFC3550. 249 Its length is described by the length field. The value of the length 250 field does not include the two octet SDES item header. This item 251 MUST be ignored by applications that are not configured to make use 252 of it. 254 4.2. SDES item for Reception Report Monitoring 256 This sub-section defines the format of the Reception Report 257 Monitoring SDES item. The SDES item is carried in the RTCP SDES 258 packet. The packet format for the RTCP SDES is defined in Section 259 6.5 of [RFC3550].Each SDES packet is composed of a header with fixed- 260 length fields for version, source count, packet type (PT), and 261 length, followed by zero or more chunks. Each chunk consists of an 262 SSRC/CSRC identifier followed by zero or more SDES items. If this 263 SDES item is carried, the CNAME SDES item should also be carried 264 together with this SDES item in the same chunk. In the SDES packet, 265 the PT field is set to SDES(202). 267 4.2.1. RRM: Reception Report Monitoring SDES Item 269 0 1 2 3 270 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | RRM=TBD | length | Candidate Report Source SSRC 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | .... 275 +-+-+-+-+-+-+-+-+ 277 The Reception Report Sending Item is not mandatory item and intended 278 for indicating the report source for an endpoint, which is 279 responsible for reception report monitoring. The SSRC/CSRC 280 identifier included in the same chunk as the item (at the beginning 281 of this chunk) is the SSRC of elected sending report source. 282 Additionally, this item may carry one or more than one Candidate 283 Report Source SSRCs. The candidate Report Source SSRC follows the 284 same format as SSRC/CSRC identifier defined in RFC3550. Its length 285 is described by the length field. The value of the length field does 286 not include the two octet SDES item header. This item MUST be 287 ignored by applications that are not configured to make use of it. 289 5. Security Considerations 291 RTCP reports can contain sensitive information, including information 292 about report source grouping for endpoint with multiple source and 293 member of a session established between two or more endpoints. 294 Therefore, the use of security mechanisms with RTP, as documented in 295 Section 9 of [RFC3550] applies. 297 6. IANA Considerations 299 New SDES types for RTCP SDES are subject to IANA registration. For 300 general guidelines on IANA considerations for RTCP SDES, refer 301 to[RFC3550]. 303 6.1. New RTCP SDES Type values 305 This document assigns two additional SDES type in the IANA "RTCP SDES 306 Item Types Registry" to the new SDES items as follow: 308 abbrev. name value 309 RRSS: Reception Report Sending Source TBD 310 RRRS: Reception Report Monitoring Source TBD 312 [Note to RFC Editor: please replace RRSS and RRMS with the IANA 313 provided RTCP SDES Item Types.] 315 7. References 317 7.1. Normative References 319 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 320 Requirement Levels", March 1997. 322 [RFC3550] Schulzrinne, H., "RTP: A Transport Protocol for Real-Time 323 Applications", RFC 3550, July 2003. 325 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 326 "Extended RTP Profile for Real-time Transport Control 327 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4595, 328 July 2006. 330 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 331 Header Extensions", RFC 5285, July 2008. 333 7.2. Informative References 335 [I-D.ietf-avtcore-multi-media-rtp-session-00] 336 Westerlund, M., "Multiple Media Types in an RTP Session", 337 ID draft-ietf-avtcore-multi-media-rtp-session-00, 338 October 2012. 340 [I-D.lennox-avtcore-rtp-multi-stream] 341 Lennox, J. and M. Westerlund, "Real-Time Transport 342 Protocol (RTP) Considerations for Endpoints Sending 343 Multiple Media Streams", 344 ID draft-lennox-avtcore-rtp-multi-stream-00, July 2012. 346 [I-D.wu-avtcore-multiplex-multisource-endpoint] 347 Wu, Q., "Bandwidth and RTCP timing issues for multi-source 348 endpoint", 349 ID draft-wu-avtcore-multiplex-multisource-endpoint-01, 350 October 2012. 352 Authors' Addresses 354 Qin Wu 355 Huawei 356 101 Software Avenue, Yuhua District 357 Nanjing, Jiangsu 210012 358 China 360 Email: sunseawq@huawei.com 362 Roni Even 363 Huawei 364 14 David Hamelech 365 Tel, Aviv 64953 366 Israel 368 Email: ron.even.tlv@gmail.com