From mailnull@www1.ietf.org Thu Jan 2 15:09:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13067 for ; Thu, 2 Jan 2003 15:09:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h02KHtQ18305 for avt-archive@odin.ietf.org; Thu, 2 Jan 2003 15:17:55 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02KGlJ18266; Thu, 2 Jan 2003 15:16:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02KDWJ18155 for ; Thu, 2 Jan 2003 15:13:32 -0500 Received: from snap.CS.Berkeley.EDU (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12965 for ; Thu, 2 Jan 2003 15:04:34 -0500 (EST) Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.9.3/8.9.3-ZUUL) id MAA29597 for avt@ietf.org; Thu, 2 Jan 2003 12:07:02 -0800 Date: Thu, 2 Jan 2003 12:07:02 -0800 From: John Lazzaro Message-Id: <200301022007.MAA29597@snap.CS.Berkeley.EDU> To: avt@ietf.org Subject: [AVT] retransmission notes ... Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Hi everyone, Recently read over draft-ietf-avt-rtp-retransmission-03.txt, a few observations: [1] The apt SDP usage seems to indicate that a session cannot assign the same PTYPE value for two streams in a session, even if these streams both use the same codec + parameters. [2] The semantics for multiple payload numbers on an m= line shown in Section 8.4 seem to imply that the streams corresponding to both payload numbers on the m= line are sent simultaneously. I'm wondering about compatibility issues regarding these two points. For example, RFC 3388 Section 7.4 (on FID semanics) seems to use the ability of two streams in a session to have the same PTYPE number to execute some of its semantics. So, [1] may make it impossible to use these semantics and retransmission in the same session. Although, the lack of dynamic payload examples in 3388 makes it hard to say for sure if this is an issue -- maybe parsers of FID SDP are supposed to track down the dynamic payload definitions and compare mime-types? I can't come up with a complementary example for [2], but I listed it in case someone else reading can ... (maybe offer/answer semantics?). Usually, only one of the PTYPEs on the m= line is being sent at one time, but senders may switch between them, but [2] above is different. -- Overall, the document reads well. Editorially, the last sentence in the first full paragraph on page 7 could use a rewrite, as could the second paragraph Section 6.3 -- both are unclear unless you already know what the text is trying to say. ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro ------------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Jan 2 19:35:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18098 for ; Thu, 2 Jan 2003 19:35:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h030hlL03836 for avt-archive@odin.ietf.org; Thu, 2 Jan 2003 19:43:47 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h030gBJ03756; Thu, 2 Jan 2003 19:42:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h030ejJ03711 for ; Thu, 2 Jan 2003 19:40:45 -0500 Received: from chiron.nge.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17944 for ; Thu, 2 Jan 2003 19:31:43 -0500 (EST) Received: from chiron (csp@localhost) by chiron.nge.isi.edu (8.11.6/8.11.6) with ESMTP id h030YtF23801 for ; Thu, 2 Jan 2003 19:34:55 -0500 Message-Id: <200301030034.h030YtF23801@chiron.nge.isi.edu> To: avt@ietf.org From: Colin Perkins Date: Thu, 02 Jan 2003 19:34:55 -0500 Subject: [AVT] Comments on draft-ietf-avt-rtp-retransmission-04.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , I've just read the -04 version of the retransmission draft. It seems to be in reasonably good shape, but I do have some questions and comments: - At the end of section 3.1, after discussing the choice between SSRC and session multiplexing, the draft states "both multiplexing approaches SHOULD be supported". Is this intended to be a requirement for both the sender and receiver? - In section 4, the draft mentions the possibility that the retransmission stream may include packets with multiple clock rates. How is this to be signalled in the SDP? - In section 4, the draft states that and profile-specific payload header must be included in the retransmitted packet. Is this sent before the OSN payload header or after it? - Section 4 is unclear how RTCP for the retransmission stream is handled. Is the sender expected to send periodic SDES and SR reports? BYEs? - In section 5.3, the description of how to associate streams when SSRC multiplexing is used seems error-prone. Would it not be possible to signal the mapping explicitly? - In section 6.1, when the original and retransmission streams are sent in the same RTP session, how are the RTCP timing rules modified? Does the sender get twice the RTCP bandwidth since it appears as two SSRCs? - In section 6.2, a pointer to the RTCP Reporting Extensions draft may be appropriate, since that defines a receiver RTT report. - In section 8, note that the correct syntax is "a=fmtp: ...". - In section 12, how does this draft affect SRTP? Is it possible to use the two formats together? I also think it would be appropriate if this draft describes the level of reliability that can be expected from a session using retransmission, and perhaps describes when this is acceptable, and when TCP should be used? Regards, Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Jan 6 17:11:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16976 for ; Mon, 6 Jan 2003 17:11:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h06MLTN20197 for avt-archive@odin.ietf.org; Mon, 6 Jan 2003 17:21:29 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06MJDJ19880; Mon, 6 Jan 2003 17:19:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06MCnJ19397 for ; Mon, 6 Jan 2003 17:12:49 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16580 for ; Mon, 6 Jan 2003 17:01:53 -0500 (EST) From: David.Leon@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h06M5M802944 for ; Mon, 6 Jan 2003 16:05:22 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 6 Jan 2003 16:05:04 -0600 Received: from daebe008.NOE.Nokia.com ([172.18.242.238]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 6 Jan 2003 16:05:03 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AVT] retransmission notes ... Date: Mon, 6 Jan 2003 16:05:02 -0600 Message-ID: <7CA3477F476D7F4FB82F02960B79CEBD017E4F5E@daebe008.americas.nokia.com> Thread-Topic: [AVT] retransmission notes ... Thread-Index: AcKynJQzWswlXFNnR/iURKp6SxgA6gDJKeSw To: X-OriginalArrivalTime: 06 Jan 2003 22:05:03.0901 (UTC) FILETIME=[AA408CD0:01C2B5CF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h06MCnJ19398 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit John, Thanks for the comments. Answers below: > > Hi everyone, > > Recently read over draft-ietf-avt-rtp-retransmission-03.txt, > a few observations: > > [1] The apt SDP usage seems to indicate that a session cannot > assign the same PTYPE value for two streams in a session, even > if these streams both use the same codec + parameters. No. If two streams use the same codec and parameters, they can use the same payload type value. The confusion may stem from the fact that declaring a single payload type in the m line is enough to send multiple RTP streams of this payload type in the same session. In other words, you don't need to declare the payload type twice if you want to send two streams. Note that in this case, one must be sure to associate a retransmission stream with the correct original stream as explained in Section 5.3. > [2] The semantics for multiple payload numbers on an m= line > shown in Section 8.4 seem to imply that the streams corresponding > to both payload numbers on the m= line are sent simultaneously. There's no such requirement. Both payload types could be sent concurrently or there could be switching between different payload types in the RTP stream. > > I'm wondering about compatibility issues regarding these two points. > > For example, RFC 3388 Section 7.4 (on FID semanics) seems to use the > ability of two streams in a session to have the same PTYPE number to > execute some of its semantics. So, [1] may make it impossible to use I don't get this point. > these semantics and retransmission in the same session. Although, the This is probably true. You can use the FID semantics for only one purpose within a session e.g. radio bearer selection or DTMF tones as explained in the FID document or retransmission. I think it's a limitation we can live with. > lack of dynamic payload examples in 3388 makes it hard to say for sure > if this is an issue -- maybe parsers of FID SDP are supposed to track > down the dynamic payload definitions and compare mime-types? > > I can't come up with a complementary example for [2], but I listed it > in case someone else reading can ... (maybe offer/answer semantics?). > Usually, only one of the PTYPEs on the m= line is being sent at one > time, but senders may switch between them, but [2] above is different. > Do the answers to point [1] and [2] above answer these objections to the use of the FID semantics for the grouping of the original and retransmission session? Let me know if anything is still unclear. > > Overall, the document reads well. Editorially, the last sentence in > the first full paragraph on page 7 could use a rewrite, as could the > second paragraph Section 6.3 -- both are unclear unless you already > know what the text is trying to say. Thanks for pointing this out. We'll try to improve the text. David. > > -------------------------------------------------------------- > ----------- > John Lazzaro -- Research Specialist -- CS Division -- EECS -- > UC Berkeley > lazzaro [at] cs [dot] berkeley [dot] edu > www.cs.berkeley.edu/~lazzaro > -------------------------------------------------------------- > ----------- > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Jan 6 19:00:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19378 for ; Mon, 6 Jan 2003 19:00:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h070BM426955 for avt-archive@odin.ietf.org; Mon, 6 Jan 2003 19:11:22 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h070AGJ26867; Mon, 6 Jan 2003 19:10:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07053J26115 for ; Mon, 6 Jan 2003 19:05:03 -0500 Received: from snap.CS.Berkeley.EDU (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19197 for ; Mon, 6 Jan 2003 18:54:04 -0500 (EST) Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.9.3/8.9.3-ZUUL) id PAA12834 for avt@ietf.org; Mon, 6 Jan 2003 15:56:20 -0800 Date: Mon, 6 Jan 2003 15:56:20 -0800 From: John Lazzaro Message-Id: <200301062356.PAA12834@snap.CS.Berkeley.EDU> To: avt@ietf.org Subject: RE: [AVT] retransmission notes ... Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , > David.Leon@nokia.com writes: > > No. If two streams use the same codec and parameters, they can use the > same payload type value. Oh, OK -- then the five.example.com example in Section 7.4.1 of RFC 3388 should work OK in conjunction with retransmission ... ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro ------------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Jan 7 16:11:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28877 for ; Tue, 7 Jan 2003 16:11:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h07LM0318731 for avt-archive@odin.ietf.org; Tue, 7 Jan 2003 16:22:00 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07LGoJ18552; Tue, 7 Jan 2003 16:16:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07LEQJ18487 for ; Tue, 7 Jan 2003 16:14:26 -0500 Received: from mailman.packetdesign.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28685 for ; Tue, 7 Jan 2003 16:03:02 -0500 (EST) Received: from ash.packetdesign.com (ash.packetdesign.com [192.168.0.243]) by mailman.packetdesign.com (8.12.3/8.12.3) with ESMTP id h07L5ae4072682; Tue, 7 Jan 2003 13:05:36 -0800 (PST) (envelope-from casner@acm.org) Date: Tue, 7 Jan 2003 13:05:36 -0800 (PST) From: Stephen Casner To: AVT WG Message-ID: <20030107124926.M73937-100000@ash.packetdesign.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [AVT] Final edits to RTP spec and A/V profile Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , I am making the final edits to the RTP specification (draft-ietf-avt-rtp-new-11) and the RTP A/V profile (draft-ietf-avt-profile-new-12) to incorporate the comments made by the IESG during their review. During the period that these documents were under IESG review, there have been a few requests for clarifications from WG members and other RTP implementers. I have prepared edits to try to provide more clarity. These edits do not make any change to the intended meaning of the documents, but they are significant enough (and tricky enough to get exactly right) that I want to review them with the WG first. I will send several messages, each with one edit so that they can be discussed individually. This is the first one. This edit is a revision/expansion of the definition of an RTP session to try to remove the ambibuity that Mike Taylor explained in his message to the list last October (message appended below). Others before him have also found the original definition insufficient. The new version is longer, but is it better? Might it trigger other potential misconceptions as it tries to remove the ones I knew about? -- Steve Old: RTP session: The association among a set of participants communicating with RTP. For each participant, the session is defined by a particular pair of destination transport addresses (one network address plus a port pair for RTP and RTCP). The destination transport address pair may be common for all participants, as in the case of IP multicast, or may be different for each, as in the case of individual unicast network addresses and port pairs. In a multimedia session, each medium is carried in a separate RTP session with its own RTCP packets. The multiple RTP sessions are distinguished by different port number pairs and/or different multicast addresses. New: RTP session: An association among a set of participants communicating with RTP. A participant may be involved in multiple RTP sessions at the same time. A single RTP session is defined by a particular pair of destination transport addresses (one network address plus a port pair for RTP and RTCP). The destination transport address pair may be common for all participants in the session, as in the case of IP multicast, or may be different for each, as in the case of individual unicast network addresses and port pairs. In a multimedia session, each medium is carried in a separate RTP session with its own RTCP packets. The multiple RTP sessions are distinguished by different port number pairs and/or different multicast addresses. Each RTP session defines a distinct space of SSRC identifiers (defined next) because the session is received by a participant on a distinct pair of destination transport addresses (RTP and RTCP). One RTP session includes the set of participants that can receive an SSRC identifier transmitted by one of the participants either in RTP (SSRC or CSRC) or RTCP. That may be only two participants in a point-to-point unicast RTP session, or a larger number connected by IP multicast, multi-unicast to shared destination transport addresses, or through an RTP mixer or translator. (Definitions of CSRC, mixer and translator follow.) > Date: Fri, 11 Oct 2002 16:25:14 -0700 > From: Mike Taylor > To: avt@ietf.org > Subject: [AVT] What is an RTP Session? > > Hi, > > I'm an RTP newbie and I'm trying to understand just what constitutes > an RTP session when the participants are using unicast rather > than multicast. I find the description in RFC 1889 quite ambiguous. > > "RTP session: The association among a set of participants > communicating with RTP. For each participant, the session is > defined by a particular pair of destination transport addresses > (one network address plus a port pair for RTP and RTCP). The > destination transport address pair may be common for all > participants, as in the case of IP multicast, or may be > different for each, as in the case of individual unicast network > addresses plus a common port pair. In a multimedia session, > each medium is carried in a separate RTP session with its own > RTCP packets. The multiple RTP sessions are distinguished by > different port number pairs and/or different multicast > addresses." > > Perhaps this paragraph would be clearer if the definition of > "participant" was made clear. The use of participant in the 1st > sentence might be interpreted to mean a participant in a conference > consisting of multiple RTP sessions. But the very next sentence > refers to "the session" which suggests that indeed there are > multiple participants in a single RTP session. This makes sense for > multicast, but my problem is I find it confusing in a multipoint > unicast scenario (I'm assuming its peer-to-peer which might be part > of my problem, but read on). > > Dissecting the paragraph we have: > > "For each participant, the session is > defined by a particular pair of destination transport addresses > (one network address plus a port pair for RTP and RTCP). " > > This would seem to suggest that the triplet rtp_port, rtcp_port> defines a session from the perspective of a > given participant. But then it seems to me that with unicast RTP > can never be more than two participants in a single session > (assuming each participant is using a different computer and hence > has a different network address). Each participant sees the session > as defined by its peer's IP address and the RTP and RTCP ports it > uses to send RTP and/or RTCP to the peer. > > But the same paragraph goes on to say > > "The destination transport address pair may be common for all > participants, as in the case of IP multicast, or may be > different for each, as in the case of individual unicast network > addresses plus a common port pair. " > > This latter sentence seems to contradict the former and suggests > that for each participant in a multipoint unicast session the > session is defined by an array of triplets of the form: > > > > > ..... > > I suppose that the author of the RFC would have assumed that for a > multi-party conference using unicast there would be an RTP mixer > terminating all sources, combining them, and sending them to all > participants. Thus, for each participant there would only be a > single session, and it would be defined by the net address and port > pair of the mixer node. Still, I'd like to know if anyone is aware > of whether any consensus has been arrived at on this issue of what > defines the session in the multi-point unicast case, with no mixer. > > Furthermore, does anyone know of any commercial or public domain > voice conferencing apps that can create multipoint unicast > peer-to-peer conferences? I've been experimenting with MS > NetMeeting and have found that it only supports audio between 2 > parties in a multi-party conference. Perhaps this issue hasn't been > viewed as important because nobody is supporting a peer-to-peer > multi-party conference? > > Thanks in advance, > > Mike Taylor _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Jan 7 18:15:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02711 for ; Tue, 7 Jan 2003 18:15:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h07NQD326875 for avt-archive@odin.ietf.org; Tue, 7 Jan 2003 18:26:13 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07NKKJ26540; Tue, 7 Jan 2003 18:20:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07NHdJ26398 for ; Tue, 7 Jan 2003 18:17:39 -0500 Received: from mailman.packetdesign.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02348 for ; Tue, 7 Jan 2003 18:06:12 -0500 (EST) Received: from ash.packetdesign.com (ash.packetdesign.com [192.168.0.243]) by mailman.packetdesign.com (8.12.3/8.12.3) with ESMTP id h07N8pe4027867; Tue, 7 Jan 2003 15:08:51 -0800 (PST) (envelope-from casner@acm.org) Date: Tue, 7 Jan 2003 15:08:51 -0800 (PST) From: Stephen Casner To: AVT WG Message-ID: <20030107144628.B73937-100000@ash.packetdesign.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [AVT] RTP: explanation of "sampling instant" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Here is the second edit to the RTP spec. In Section 5.1, I've added text at the end of the specification of the "timestamp" field in the RTP header to explain the notion of "sampling instant" better. Do you think this helps or hinders? Should I cut the last paragraph? I included it to give an idea how sampling relates to prerecorded media. -- Steve OLD: timestamp: 32 bits The timestamp reflects the sampling instant of the first octet in the RTP data packet. The sampling instant MUST be derived from a clock that increments monotonically and linearly in time to allow synchronization and jitter calculations (see Section 6.4.1). The resolution of the clock MUST be sufficient for the desired synchronization accuracy and for measuring packet arrival jitter (one tick per video frame is typically not sufficient). The clock frequency is dependent on the format of data carried as payload and is specified statically in the profile or payload format specification that defines the format, or MAY be specified dynamically for payload formats defined through non-RTP means. If RTP packets are generated periodically, the nominal sampling instant as determined from the sampling clock is to be used, not a reading of the system clock. As an example, for fixed-rate audio the timestamp clock would likely increment by one for each sampling period. If an audio application reads blocks covering 160 sampling periods from the input device, the timestamp would be increased by 160 for each such block, regardless of whether the block is transmitted in a packet or dropped as silent. The initial value of the timestamp SHOULD be random, as for the sequence number. Several consecutive RTP packets will have equal timestamps if they are (logically) generated at once, e.g., belong to the same video frame. Consecutive RTP packets MAY contain timestamps that are not monotonic if the data is not transmitted in the order it was sampled, as in the case of MPEG interpolated video frames. (The sequence numbers of the packets as transmitted will still be monotonic.) NEW ADDITION: The sampling instant is chosen as the point of reference for the RTP timestamp because it is known to the transmitting endpoint and has a common definition for all media independent of encoding delays or other processing. The purpose is to allow synchronized presentation of all media sampled at the same time. Comparing RTP timestamps from different media is not effective because they have independent random offsets and may advance at different rates. Instead, for each medium the RTP timestamp is related to the sampling instant by pairing it with a timestamp from a reference clock (wallclock) that represents the time when the data corresponding to the RTP timestamp was sampled. The reference clock is shared by all media to be synchronized. The timestamp pairs are not transmitted in every data packet, but at a lower rate in RTCP SR packets as described in Section 6.4. Applications transmitting stored data rather than data sampled in real time typically use a virtual clock to determine when the next frame or other unit of each medium in the stored data should be presented. In this case, the sampling instant would be the presentation time for each unit, and it would be related to the wallclock time at which the unit was determined to be ready for presentation. Live and prerecorded media can also be synchronized, for example in a live audio narration of prerecorded video. The video would be presented locally to the narrator as well as transmitted using RTP. The sampling instant of the video would be established by referencing the timestamp of the video frame to the wallclock time when the video frame is presented locally and the corresponding audio is sampled. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Jan 7 18:21:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02965 for ; Tue, 7 Jan 2003 18:21:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h07NWLQ27157 for avt-archive@odin.ietf.org; Tue, 7 Jan 2003 18:32:21 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07NR7J26932; Tue, 7 Jan 2003 18:27:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07NQTJ26892 for ; Tue, 7 Jan 2003 18:26:29 -0500 Received: from mailman.packetdesign.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02690 for ; Tue, 7 Jan 2003 18:15:02 -0500 (EST) Received: from ash.packetdesign.com (ash.packetdesign.com [192.168.0.243]) by mailman.packetdesign.com (8.12.3/8.12.3) with ESMTP id h07NHbe4043629; Tue, 7 Jan 2003 15:17:37 -0800 (PST) (envelope-from casner@acm.org) Date: Tue, 7 Jan 2003 15:17:37 -0800 (PST) From: Stephen Casner To: AVT WG Message-ID: <20030107151203.W73937-100000@ash.packetdesign.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [AVT] RTP: SSRC multiplexing for same medium Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , At Yokohama, we discussed multiplexing streams distinguished by different SSRC identifiers within one RTP session. This discussion was in the context of the retransmission draft. One or more people requested that a sentence be added to Section 5.2 in the RTP spec to say that SSRC multiplexing was OK for streams of the same medium (vs. different media which is the primary emphasis of that section). Here is the sentence I added. Is it a good idea or bad idea to add this? If you think adding such a statement is a good idea, does this sentence say the right thing? -- Steve OLD: Using a different SSRC for each medium but sending them in the same RTP session would avoid the first three problems but not the last two. NEW ADDITION: It may be appropriate to multiplex streams of the same medium using different SSRC values in one RTP session in scenarios where the last two problems do not apply. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Jan 7 18:23:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03055 for ; Tue, 7 Jan 2003 18:23:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h07NY1v27241 for avt-archive@odin.ietf.org; Tue, 7 Jan 2003 18:34:01 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07NU3J27060; Tue, 7 Jan 2003 18:30:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07NTTJ27016 for ; Tue, 7 Jan 2003 18:29:29 -0500 Received: from mailman.packetdesign.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02805 for ; Tue, 7 Jan 2003 18:18:03 -0500 (EST) Received: from ash.packetdesign.com (ash.packetdesign.com [192.168.0.243]) by mailman.packetdesign.com (8.12.3/8.12.3) with ESMTP id h07NKce4049778; Tue, 7 Jan 2003 15:20:38 -0800 (PST) (envelope-from casner@acm.org) Date: Tue, 7 Jan 2003 15:20:38 -0800 (PST) From: Stephen Casner To: AVT WG Message-ID: <20030107151834.M73937-100000@ash.packetdesign.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [AVT] RTP: Note regarding SSM Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , One of the IESG comments (this one from Harald Alvestrand) was a request to add the following "non-normative note" at the end of Section 6 where RTCP is introduced (i.e., just before 6.1). Does anyone object? Non-normative note: In the multicast routing approach called Source-Specific Multicast (SSM), only one or a few senders send multicast data, and receivers may not send multicast. The recommendations here accommodate SSM only through Section 6.2's option of turning off receivers' RTCP entirely. Future work will specify adaptation of RTCP for SSM so that feedback from receivers can be maintained. -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Jan 7 18:39:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03647 for ; Tue, 7 Jan 2003 18:39:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h07NoZ328495 for avt-archive@odin.ietf.org; Tue, 7 Jan 2003 18:50:35 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07NjAJ28286; Tue, 7 Jan 2003 18:45:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07NidJ28252 for ; Tue, 7 Jan 2003 18:44:39 -0500 Received: from mailman.packetdesign.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03520 for ; Tue, 7 Jan 2003 18:33:12 -0500 (EST) Received: from ash.packetdesign.com (ash.packetdesign.com [192.168.0.243]) by mailman.packetdesign.com (8.12.3/8.12.3) with ESMTP id h07NZne4077441; Tue, 7 Jan 2003 15:35:49 -0800 (PST) (envelope-from casner@acm.org) Date: Tue, 7 Jan 2003 15:35:49 -0800 (PST) From: Stephen Casner To: AVT WG Message-ID: <20030107152501.G73937-100000@ash.packetdesign.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [AVT] RTP: control traffic adds to session bandwidth Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Magnus Westerlund pointed out that the text in Section 6.2 of the RTP spec regarding session bandwidth was not clear about whether the control traffic (RTCP) bandwidth was in addition to or included in the session bandwidth. Does this make the answer clear? -- Steve OLD: The control traffic should be limited to a small and known fraction of the session bandwidth: small so that the primary function of the transport protocol to carry data is not impaired; known so that the control traffic can be included in the bandwidth specification given to a resource reservation protocol, and so that each participant can independently calculate its share. It is RECOMMENDED that the fraction of the session bandwidth allocated to RTCP be fixed at 5%. It is also RECOMMENDED that 1/4 of the RTCP bandwidth be dedicated to participants that are sending data so that in sessions with a large number of receivers but a small number of senders, newly joining participants will more quickly receive the CNAME for the sending sites. When the proportion of senders is greater than 1/4 of the participants, the senders get their proportion of the full RTCP bandwidth. While the values of these and other constants in the interval calculation are not critical, all participants in the session MUST use the same values so the same interval will be calculated. Therefore, these constants SHOULD be fixed for a particular profile. NEW: (new/changed text marked by ^^^) The control traffic should be limited to a small and known fraction of the session bandwidth: small so that the primary function of the transport protocol to carry data is not impaired; known so that the control traffic can be included in the bandwidth specification given to a resource reservation protocol, and so that each participant can independently calculate its share. The control traffic bandwidth is ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ in addition to the session bandwidth for the data traffic. It is ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ RECOMMENDED that the fraction of the session bandwidth added for RTCP ^^^^^^^^^ be fixed at 5%. It is also RECOMMENDED that 1/4 of the RTCP bandwidth be dedicated to participants that are sending data so that in sessions with a large number of receivers but a small number of senders, newly joining participants will more quickly receive the CNAME for the sending sites. When the proportion of senders is greater than 1/4 of the participants, the senders get their proportion of the full RTCP bandwidth. While the values of these and other constants in the interval calculation are not critical, all participants in the session MUST use the same values so the same interval will be calculated. Therefore, these constants SHOULD be fixed for a particular profile. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Jan 7 19:09:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04590 for ; Tue, 7 Jan 2003 19:09:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h080K2v30399 for avt-archive@odin.ietf.org; Tue, 7 Jan 2003 19:20:02 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h080FJJ30200; Tue, 7 Jan 2003 19:15:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h080DOJ29994 for ; Tue, 7 Jan 2003 19:13:24 -0500 Received: from mailman.packetdesign.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04297 for ; Tue, 7 Jan 2003 19:01:56 -0500 (EST) Received: from ash.packetdesign.com (ash.packetdesign.com [192.168.0.243]) by mailman.packetdesign.com (8.12.3/8.12.3) with ESMTP id h0804UNh030208; Tue, 7 Jan 2003 16:04:30 -0800 (PST) (envelope-from casner@acm.org) Date: Tue, 7 Jan 2003 16:04:30 -0800 (PST) From: Stephen Casner To: AVT WG Message-ID: <20030107154352.Y73937-100000@ash.packetdesign.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [AVT] RTP: When to turn off RTCP reception reports Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Numerous times we have had discussions on this mailing list regarding whether sending RTCP is "required". We've answered with the reasons behind both SR for data senders and RR for receivers. Igor Curcio cited the specific paragraph that appears both in Section 6.2 of the RTP spec and in Section 1 of draft-ietf-avt-rtcp-bw-05.txt regarding the ability to turn off RTCP RRs by allocating zero bandwidth for them, and asked that we clarify there that, in general, RTCP reports should not be turned off. I've added text in the RTP spec to do this. If you all agree that this is a good addition, I will ask the RFC Editor to insert it into rtcp-bw as well. -- Steve OLD: Using two parameters allows RTCP reception reports to be turned off entirely for a particular session by setting the RTCP bandwidth for non-data-senders to zero while keeping the RTCP bandwidth for data senders non-zero so that sender reports can still be sent for inter- media synchronization. This may be appropriate for systems operating on unidirectional links or for sessions that don't require feedback on the quality of reception. NEW: Using two parameters allows RTCP reception reports to be turned off entirely for a particular session by setting the RTCP bandwidth for non-data-senders to zero while keeping the RTCP bandwidth for data senders non-zero so that sender reports can still be sent for inter- media synchronization. Turning off RTCP reception reports is NOT RECOMMENDED because they are needed for the functions listed at the beginning of Section 6, particularly reception quality feedback and congestion control. However, doing so may be appropriate for systems operating on unidirectional links or for sessions that don't require feedback on the quality of reception or liveness of receivers and that have other means to avoid congestion. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Jan 7 19:23:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04989 for ; Tue, 7 Jan 2003 19:23:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h080Y0I31068 for avt-archive@odin.ietf.org; Tue, 7 Jan 2003 19:34:00 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h080ScJ30863; Tue, 7 Jan 2003 19:28:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h080RsJ30813 for ; Tue, 7 Jan 2003 19:27:54 -0500 Received: from mailman.packetdesign.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04813 for ; Tue, 7 Jan 2003 19:16:26 -0500 (EST) Received: from ash.packetdesign.com (ash.packetdesign.com [192.168.0.243]) by mailman.packetdesign.com (8.12.3/8.12.3) with ESMTP id h080IxtE056354; Tue, 7 Jan 2003 16:18:59 -0800 (PST) (envelope-from casner@acm.org) Date: Tue, 7 Jan 2003 16:18:59 -0800 (PST) From: Stephen Casner To: AVT WG Message-ID: <20030107160727.D73937-100000@ash.packetdesign.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [AVT] RTP: IPv6 examples for RTCP SDES CNAME Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , At the suggestion of Peter Barany, I added explanation and examples of IPv6 address formats to the IPv4 cases that were already there for the format of the RTCP SDES CNAME item. I expect these are not controversial. Is this IPv6 address officially designated for use in document examples as 192.0.2.0/24 is for IPv4? Use of a real address is generally not advised. -- Steve For example, the standard ASCII representation of an IP Version 4 address is "dotted decimal", also known as dotted quad, and for IP Version 6, addresses are textually represented as eight groups of four hexadecimal digits separated by colons. ... Examples are "doe@sleepy.megacorp.com", "doe@192.0.2.89" or "doe@2201:056D::112E:144A:1E24" for a multi-user system. On a system with no user name, examples would be "sleepy.megacorp.com", "192.0.2.89" or "2201:056D::112E:144A:1E24". _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Jan 7 19:32:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05352 for ; Tue, 7 Jan 2003 19:32:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h080hA132262 for avt-archive@odin.ietf.org; Tue, 7 Jan 2003 19:43:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h080dHJ32013; Tue, 7 Jan 2003 19:39:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h080c0J31908 for ; Tue, 7 Jan 2003 19:38:00 -0500 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05129 for ; Tue, 7 Jan 2003 19:26:31 -0500 (EST) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id h080Trfm022824 for ; Tue, 7 Jan 2003 16:29:53 -0800 (PST) Received: from [10.32.254.182] (stealth-10-32-254-182.cisco.com [10.32.254.182]) by mira-sjc5-9.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with SMTP id HQC00128; Tue, 7 Jan 2003 16:30:18 -0800 (PST) Date: Tue, 07 Jan 2003 19:29:35 -0500 From: "David R. Oran" To: AVT WG Subject: Re: [AVT] RTP: When to turn off RTCP reception reports Message-ID: <106827870.1041967775@[10.32.254.182]> In-Reply-To: <20030107154352.Y73937-100000@ash.packetdesign.com> References: <20030107154352.Y73937-100000@ash.packetdesign.com> X-Mailer: Mulberry/3.0.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I believe the new wording is an improvement and support including it in the RFC. Dave. --On Tuesday, January 07, 2003 4:04 PM -0800 Stephen Casner wrote: > Numerous times we have had discussions on this mailing list regarding > whether sending RTCP is "required". We've answered with the reasons > behind both SR for data senders and RR for receivers. > > Igor Curcio cited the specific paragraph that appears both in Section > 6.2 of the RTP spec and in Section 1 of draft-ietf-avt-rtcp-bw-05.txt > regarding the ability to turn off RTCP RRs by allocating zero > bandwidth for them, and asked that we clarify there that, in general, > RTCP reports should not be turned off. I've added text in the RTP > spec to do this. If you all agree that this is a good addition, I > will ask the RFC Editor to insert it into rtcp-bw as well. > > -- Steve > > OLD: > > Using > two parameters allows RTCP reception reports to be turned off > entirely for a particular session by setting the RTCP bandwidth for > non-data-senders to zero while keeping the RTCP bandwidth for data > senders non-zero so that sender reports can still be sent for inter- > media synchronization. This may be appropriate for systems operating > on unidirectional links or for sessions that don't require feedback > on the quality of reception. > > NEW: > > Using > two parameters allows RTCP reception reports to be turned off > entirely for a particular session by setting the RTCP bandwidth for > non-data-senders to zero while keeping the RTCP bandwidth for data > senders non-zero so that sender reports can still be sent for inter- > media synchronization. Turning off RTCP reception reports is NOT > RECOMMENDED because they are needed for the functions listed at the > beginning of Section 6, particularly reception quality feedback and > congestion control. However, doing so may be appropriate for systems > operating on unidirectional links or for sessions that don't require > feedback on the quality of reception or liveness of receivers and > that have other means to avoid congestion. > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt ------------------------ David R. Oran Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 Office: +1 978 264 2048 VoIP: +1 408 571 4576 Email: oran@cisco.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Jan 7 19:35:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05537 for ; Tue, 7 Jan 2003 19:35:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h080kTv32467 for avt-archive@odin.ietf.org; Tue, 7 Jan 2003 19:46:29 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h080h4J32260; Tue, 7 Jan 2003 19:43:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h080gSJ32243 for ; Tue, 7 Jan 2003 19:42:28 -0500 Received: from mailman.packetdesign.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05311 for ; Tue, 7 Jan 2003 19:30:59 -0500 (EST) Received: from ash.packetdesign.com (ash.packetdesign.com [192.168.0.243]) by mailman.packetdesign.com (8.12.3/8.12.3) with ESMTP id h080Xaoj082745; Tue, 7 Jan 2003 16:33:36 -0800 (PST) (envelope-from casner@acm.org) Date: Tue, 7 Jan 2003 16:33:36 -0800 (PST) From: Stephen Casner To: AVT WG Message-ID: <20030107162229.J73937-100000@ash.packetdesign.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [AVT] RTP: Confidentiality mechanisms Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , In Section 9.1 of the RTP spec on Confidentiality, I added "redrawn for each unit" to clarify that RTCP packets can't use just one random number for all packets. In addition, I've added two statements requested by the IESG. -- Steve OLD: For RTCP, a 32-bit random number MUST be prepended to the unit before encryption to deter known plaintext attacks. For RTP, no prefix is required because the sequence number and timestamp fields are initialized with random offsets. NEW: For RTCP, a 32-bit random number redrawn for each unit MUST be prepended to the unit before encryption to deter known plaintext attacks. For RTP, no prefix is required because the sequence number and timestamp fields are initialized with random offsets. This is considered to be a weak initialization vector (IV), because of poor randomness properties. In addition, if the subsequent field, the SSRC, can be manipulated by an enemy, there is further weakness of the encryption method. OLD: Other encryption algorithms MAY be specified dynamically for a session by non-RTP means. It is RECOMMENDED that stronger encryption algorithms such as Triple-DES be used in place of the default algorithm. NEW ADDITION: In particular, an AES profile taking into account known plaintext and CBC plaintext manipulation concerns will be the correct choice in future. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Jan 7 19:51:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06183 for ; Tue, 7 Jan 2003 19:51:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0812HL00484 for avt-archive@odin.ietf.org; Tue, 7 Jan 2003 20:02:17 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0810CJ00412; Tue, 7 Jan 2003 20:00:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h080xtJ00359 for ; Tue, 7 Jan 2003 19:59:55 -0500 Received: from mailman.packetdesign.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06082 for ; Tue, 7 Jan 2003 19:48:26 -0500 (EST) Received: from ash.packetdesign.com (ash.packetdesign.com [192.168.0.243]) by mailman.packetdesign.com (8.12.3/8.12.3) with ESMTP id h080p2oj013616; Tue, 7 Jan 2003 16:51:02 -0800 (PST) (envelope-from casner@acm.org) Date: Tue, 7 Jan 2003 16:51:02 -0800 (PST) From: Stephen Casner To: AVT WG Message-ID: <20030107163847.E73937-100000@ash.packetdesign.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [AVT] Profile: Silence suppression is allowed by default Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Over the past year we have had a few discussions on the AVT list regarding silence suppression and comfort noise for various payload formats. Sharma Kanchinadham and Anoop Tripathi asked (separately) for the optional MIME parameters for G723 and G729 audio to be changed such that the default for "allow comfort noise frames" was NO. Sharma also asked for a similar parameter to be added for PCMU to indicate whether silence suppression was allowed, and for the default to be NO. I explained that we could not make these changes because silence suppression has always been an assumed capability for all of the audio encodings. It's one of the fundamental reasons for using packets to carry voice in the first place. Changing the default now would create a backwards incompatibility. Furthermore, a receiver must always be prepared to recover gracefully when it receives no data because packets may be lost. To make this more explicit, I added the following paragraphs at the beginning of Section 4.1 in the A/V profile: Since the ability to suppress silence is one of the primary motivations for using packets to transmit voice, the RTP header carries both a sequence number and a timestamp to allow a receiver to distinguish between lost packets and periods of time when no data was transmitted. Discontiguous transmission (silence suppression) MAY be used with any audio payload format. Receivers MUST accept silence suppression unless its use is restricted by signaling specified elsewhere. (Even if the transmitter does not suppress silence, the receiver must be prepared to handle periods when no data is present since packets may be lost.) Some payload formats define a "silence insertion descriptor" or "comfort noise" frame to specify parameters for artificial noise that may be generated during a period of silence to approximate the background noise at the source. For other payload formats, a generic Comfort Noise (CN) payload format is specified in RFC 3389 [9]. When the CN payload format is used with another payload format, different values in the RTP payload type field distinguish comfort-noise packets from those of the selected payload format. In addition, I added the following first sentence in the four places where the sentences similar to the second one appear in G723 and G729*: Receivers MUST accept comfort noise frames if restriction of their use has not been signaled. The MIME registration for G729 in RFC YYYY [7] specifies a parameter that MAY be used with MIME or SDP to restrict the use of comfort noise frames. Are these acceptable? -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Jan 7 20:02:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06441 for ; Tue, 7 Jan 2003 20:02:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h081D8k01552 for avt-archive@odin.ietf.org; Tue, 7 Jan 2003 20:13:08 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08199J01319; Tue, 7 Jan 2003 20:09:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0818uJ01301 for ; Tue, 7 Jan 2003 20:08:56 -0500 Received: from chiron.nge.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06284 for ; Tue, 7 Jan 2003 19:57:27 -0500 (EST) Received: from chiron (csp@localhost) by chiron.nge.isi.edu (8.11.6/8.11.6) with ESMTP id h0810fh24078; Tue, 7 Jan 2003 20:00:42 -0500 Message-Id: <200301080100.h0810fh24078@chiron.nge.isi.edu> To: jan.vandermeer@philips.com cc: avt@ietf.org From: Colin Perkins Date: Tue, 07 Jan 2003 20:00:41 -0500 Subject: [AVT] Comments on draft-ietf-avt-mpeg4-simple-06.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Jan, I think the MPEG-4 payload format is in good shape now. I have a number of editorial comments below, mostly trying to tighten the language of the new interleaving section and clarifying some of the examples. Colin - Need to make it clear that the interleaving pattern at the bottom of page 7 is an example, and that other patterns are possible. Suggest changing "Assume that..." to "For example, if we assume that..." - The first paragraph of section 3.2.3.2 "Interleaving" is unclear. I suggest rewriting it as follows: Unless prohibited by the signalled mode, a sender MAY interleave Access Units. Receivers that are capable of receiving modes that support interleaving MUST be able to decode interleaved Access Units. (The last sentance of the original paragraph was redundant with the explanation that followed). - The second paragraph of section 3.2.3.2 starts "When a sender interleaves Access Units, then the transmitter needs to...". This could be rewritten as "When a sender interleaves Access Units, it needs to..." - The formula at the top of page 17 has a non-ASCII character, which does not display correctly. I assume it should be a minus sign? - I find the explanation of the "constantDuration" parameter in the three paragraphs following the formula on page 17 to be unclear. I suggest the following rewording: The MIME parameter "constantDuration" SHOULD be used to signal that Access Units have a constant time duration, see section 4.1. If the "constantDuration" parameter is present, the receiver can reconstruct the original Access Unit timing based solely on the RTP timestamp and AU-Index-delta. Accordingly, when transmitting Access Units of constant duration, the AU-Index, if present, MUST be set to the value 0. Receivers of constant duration Access Units MUST use the RTP timestamp to determine the index of the first AU in the RTP packet. The AU-Index-delta header and the signalled "constantDuration" are used to reconstruct AU timing. If the "constantDuration" parameter is not present, then Access Units are assumed to have a variable duration. In this case, the transmitter MUST use the AU-Index to encode the index information required for re-ordering, and the receiver MUST use that value to determine the index of the first AU in the RTP packet. The number of bits of the AU-Index field MUST be chosen so that valid index information is provided at the applied interleaving scheme, without causing problems due to roll-over of the AU-Index field. In addition, the CTS-delta MUST be coded in the AU header for each non-first AU in the RTP packet, so that receivers can place the AUs correctly in time. - Section 4.1 defines the "ConstantDuration" parameter, but the text refers to it as "constantDuration". They should be consistant. - In section 3.3.2, the draft should mention that the a=fmtp: line has been split for presentation in the RFC, and is actually a single long line. Also, "BIFSConfiguration()" should be replaced by an example of the hexadecimal string, and the text "BIFSConfiguration() is the hexadecimal string as defined in ISO/IEC 14496-1" replaced by "The hexadeciaml string in the 'config=' parameter is the result of the BIFSConfiguration() function defined in ISO/IEC 14496-1", or similar. [Similar comments apply to the examples in the other modes] - In section 3.3.3, the draft might say "Interleaving MUST NOT be used with this mode" instead of "there is no support for interleaving". A similar comment applies to section 3.3.4 where "optional interleaving" could be "OPTIONAL interleaving". - In section 3.3.5, "frames MUST not be fragmented" -> "...MUST NOT..." _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Jan 7 21:05:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08547 for ; Tue, 7 Jan 2003 21:05:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h082GGX05284 for avt-archive@odin.ietf.org; Tue, 7 Jan 2003 21:16:16 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h082EjJ05243; Tue, 7 Jan 2003 21:14:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h082DNJ05194 for ; Tue, 7 Jan 2003 21:13:23 -0500 Received: from purple.nge.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08386 for ; Tue, 7 Jan 2003 21:01:51 -0500 (EST) Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.6/8.12.6) with ESMTP id h082319F027154; Tue, 7 Jan 2003 21:03:01 -0500 (EST) (envelope-from csp@purple.nge.isi.edu) Message-Id: <200301080203.h082319F027154@purple.nge.isi.edu> To: Stephen Casner cc: AVT WG Subject: Re: [AVT] RTP: IPv6 examples for RTCP SDES CNAME In-Reply-To: Your message of "Tue, 07 Jan 2003 16:18:59 PST." <20030107160727.D73937-100000@ash.packetdesign.com> Date: Tue, 07 Jan 2003 21:03:01 -0500 From: Colin Perkins Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --> Stephen Casner writes: >At the suggestion of Peter Barany, I added explanation and examples of >IPv6 address formats to the IPv4 cases that were already there for the >format of the RTCP SDES CNAME item. I expect these are not >controversial. Is this IPv6 address officially designated for use in >document examples as 192.0.2.0/24 is for IPv4? Use of a real address >is generally not advised. > > -- Steve > > For example, the standard ASCII > representation of an IP Version 4 address is "dotted decimal", also > known as dotted quad, and for IP Version 6, addresses are textually > represented as eight groups of four hexadecimal digits separated by > colons. ... I suspect this description is not sufficient, since formats like FF01::101 and ::13.1.68.3 are allowed by RFC 2373. We should probably reference that definition directly. Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Jan 7 21:11:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08874 for ; Tue, 7 Jan 2003 21:11:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h082Mbg05501 for avt-archive@odin.ietf.org; Tue, 7 Jan 2003 21:22:37 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h082K7J05409; Tue, 7 Jan 2003 21:20:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h082JeJ05369 for ; Tue, 7 Jan 2003 21:19:40 -0500 Received: from purple.nge.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08684 for ; Tue, 7 Jan 2003 21:08:08 -0500 (EST) Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.6/8.12.6) with ESMTP id h082BK9F027395; Tue, 7 Jan 2003 21:11:20 -0500 (EST) (envelope-from csp@purple.nge.isi.edu) Message-Id: <200301080211.h082BK9F027395@purple.nge.isi.edu> To: Stephen Casner cc: AVT WG Subject: Re: [AVT] RTP: Confidentiality mechanisms In-Reply-To: Your message of "Tue, 07 Jan 2003 16:33:36 PST." <20030107162229.J73937-100000@ash.packetdesign.com> Date: Tue, 07 Jan 2003 21:11:20 -0500 From: Colin Perkins Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --> Stephen Casner writes: >In Section 9.1 of the RTP spec on Confidentiality, I added "redrawn >for each unit" to clarify that RTCP packets can't use just one random >number for all packets. In addition, I've added two statements >requested by the IESG. Looks reasonable. I suggest a small addition to the second change, to indicate that stronger security is under development. >OLD: > For RTCP, a 32-bit random number MUST be > prepended to the unit before encryption to deter known plaintext > attacks. For RTP, no prefix is required because the sequence number > and timestamp fields are initialized with random offsets. > >NEW: > For RTCP, a 32-bit random number redrawn for > each unit MUST be prepended to the unit before encryption to deter > known plaintext attacks. For RTP, no prefix is required because the > sequence number and timestamp fields are initialized with random > offsets. This is considered to be a weak initialization vector (IV), > because of poor randomness properties. In addition, if the > subsequent field, the SSRC, can be manipulated by an enemy, there is > further weakness of the encryption method. > > > >OLD: > Other encryption algorithms MAY be > specified dynamically for a session by non-RTP means. It is > RECOMMENDED that stronger encryption algorithms such as Triple-DES be > used in place of the default algorithm. >NEW ADDITION: > In particular, an AES > profile taking into account known plaintext and CBC plaintext > manipulation concerns will be the correct choice in future. ^ is under development, and Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Jan 7 23:03:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11728 for ; Tue, 7 Jan 2003 23:03:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h084EFY11110 for avt-archive@odin.ietf.org; Tue, 7 Jan 2003 23:14:15 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h084CTJ11076; Tue, 7 Jan 2003 23:12:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h084BXJ11035 for ; Tue, 7 Jan 2003 23:11:33 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11665 for ; Tue, 7 Jan 2003 23:00:01 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.81]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0843FYH026745; Tue, 7 Jan 2003 23:03:16 -0500 (EST) Message-ID: <3E1BA302.3020803@dynamicsoft.com> Date: Tue, 07 Jan 2003 23:03:14 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Casner CC: AVT WG Subject: Re: [AVT] Profile: Silence suppression is allowed by default References: <20030107163847.E73937-100000@ash.packetdesign.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I think this addition is great. I have seen this issue come up all the time. Some comments on the wording inline: Stephen Casner wrote: > To make this more explicit, I added the following paragraphs at the > beginning of Section 4.1 in the A/V profile: > > Since the ability to suppress silence is one of the primary > motivations for using packets to transmit voice, the RTP header > carries both a sequence number and a timestamp to allow a receiver to > distinguish between lost packets and periods of time when no data was > transmitted. Discontiguous transmission (silence suppression) MAY be > used with any audio payload format. Receivers MUST accept silence > suppression unless its use is restricted by signaling specified > elsewhere. Since silence suppression is just the absence of packets, its not clear what it means to "accept" it. > (Even if the transmitter does not suppress silence, the > receiver must be prepared to handle periods when no data is present > since packets may be lost.) This sentence and the previous appear contradictory to me. The previous says that you won't need to handle silence suppression if signaling says its not in use, but this sentence says you need it anyway. I would propose the last two sentences be replaced with: Receivers MUST be prepared to handle the absence of packets for an arbitrary period of time in order to accomodate silence suppression at the sender. This applies even if silence suppression is not in use (which can be known to the receiver through signaling, outside the scope of this specification), because packet loss cannot be distinguished from silence suppression. > > Some payload formats define a "silence insertion descriptor" or > "comfort noise" frame to specify parameters for artificial noise that > may be generated during a period of silence to approximate the > background noise at the source. For other payload formats, a generic > Comfort Noise (CN) payload format is specified in RFC 3389 [9]. When > the CN payload format is used with another payload format, different > values in the RTP payload type field distinguish comfort-noise > packets from those of the selected payload format. I assume [9] is an informative reference, not normative. > > In addition, I added the following first sentence in the four places > where the sentences similar to the second one appear in G723 and G729*: > > Receivers MUST accept comfort noise frames if restriction of their > use has not been signaled. The MIME registration for G729 in > RFC YYYY [7] specifies a parameter that MAY be used with MIME or SDP > to restrict the use of comfort noise frames. Presumably RFC YYYY [7] will be at proposed. The above text seems to me to provide a normative reference to that specification. A draft standard cannot have a normative reference to a proposed standard. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Jan 7 23:07:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11790 for ; Tue, 7 Jan 2003 23:07:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h084ImA11278 for avt-archive@odin.ietf.org; Tue, 7 Jan 2003 23:18:48 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h084H7J11227; Tue, 7 Jan 2003 23:17:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h084GKJ11196 for ; Tue, 7 Jan 2003 23:16:20 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11761 for ; Tue, 7 Jan 2003 23:04:48 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.81]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h08484YH026752; Tue, 7 Jan 2003 23:08:05 -0500 (EST) Message-ID: <3E1BA422.9070408@dynamicsoft.com> Date: Tue, 07 Jan 2003 23:08:02 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Casner CC: AVT WG Subject: Re: [AVT] RTP: IPv6 examples for RTCP SDES CNAME References: <20030107160727.D73937-100000@ash.packetdesign.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit One comment. As per the latest I-D nits guidelines: http://www.ietf.org/ID-nits.html domain names outside of rfc2606 are not allowed. Thus, I suggest changing megacorp.com to example.com. -Jonathan R. Stephen Casner wrote: > At the suggestion of Peter Barany, I added explanation and examples of > IPv6 address formats to the IPv4 cases that were already there for the > format of the RTCP SDES CNAME item. I expect these are not > controversial. Is this IPv6 address officially designated for use in > document examples as 192.0.2.0/24 is for IPv4? Use of a real address > is generally not advised. > > -- Steve > > For example, the standard ASCII > representation of an IP Version 4 address is "dotted decimal", also > known as dotted quad, and for IP Version 6, addresses are textually > represented as eight groups of four hexadecimal digits separated by > colons. ... > > Examples are "doe@sleepy.megacorp.com", "doe@192.0.2.89" or > "doe@2201:056D::112E:144A:1E24" for a multi-user system. On a system > with no user name, examples would be "sleepy.megacorp.com", > "192.0.2.89" or "2201:056D::112E:144A:1E24". > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Jan 7 23:08:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11824 for ; Tue, 7 Jan 2003 23:08:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h084Jwe11312 for avt-archive@odin.ietf.org; Tue, 7 Jan 2003 23:19:58 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h084I4J11262; Tue, 7 Jan 2003 23:18:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h084HUJ11243 for ; Tue, 7 Jan 2003 23:17:30 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11770 for ; Tue, 7 Jan 2003 23:05:58 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.81]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0849FYH026755; Tue, 7 Jan 2003 23:09:15 -0500 (EST) Message-ID: <3E1BA468.4040801@dynamicsoft.com> Date: Tue, 07 Jan 2003 23:09:12 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David R. Oran" CC: AVT WG Subject: Re: [AVT] RTP: When to turn off RTCP reception reports References: <20030107154352.Y73937-100000@ash.packetdesign.com> <106827870.1041967775@[10.32.254.182]> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I concur. -Jonathan R. David R. Oran wrote: > I believe the new wording is an improvement and support including it in > the RFC. > > Dave. > > --On Tuesday, January 07, 2003 4:04 PM -0800 Stephen Casner > wrote: > >> Numerous times we have had discussions on this mailing list regarding >> whether sending RTCP is "required". We've answered with the reasons >> behind both SR for data senders and RR for receivers. >> >> Igor Curcio cited the specific paragraph that appears both in Section >> 6.2 of the RTP spec and in Section 1 of draft-ietf-avt-rtcp-bw-05.txt >> regarding the ability to turn off RTCP RRs by allocating zero >> bandwidth for them, and asked that we clarify there that, in general, >> RTCP reports should not be turned off. I've added text in the RTP >> spec to do this. If you all agree that this is a good addition, I >> will ask the RFC Editor to insert it into rtcp-bw as well. >> >> -- Steve >> >> OLD: >> >> Using >> two parameters allows RTCP reception reports to be turned off >> entirely for a particular session by setting the RTCP bandwidth for >> non-data-senders to zero while keeping the RTCP bandwidth for data >> senders non-zero so that sender reports can still be sent for inter- >> media synchronization. This may be appropriate for systems operating >> on unidirectional links or for sessions that don't require feedback >> on the quality of reception. >> >> NEW: >> >> Using >> two parameters allows RTCP reception reports to be turned off >> entirely for a particular session by setting the RTCP bandwidth for >> non-data-senders to zero while keeping the RTCP bandwidth for data >> senders non-zero so that sender reports can still be sent for inter- >> media synchronization. Turning off RTCP reception reports is NOT >> RECOMMENDED because they are needed for the functions listed at the >> beginning of Section 6, particularly reception quality feedback and >> congestion control. However, doing so may be appropriate for systems >> operating on unidirectional links or for sessions that don't require >> feedback on the quality of reception or liveness of receivers and >> that have other means to avoid congestion. >> >> _______________________________________________ >> Audio/Video Transport Working Group >> avt@ietf.org >> https://www1.ietf.org/mailman/listinfo/avt > > > ------------------------ > David R. Oran > Cisco Systems > 7 Ladyslipper Lane > Acton, MA 01720 > Office: +1 978 264 2048 > VoIP: +1 408 571 4576 > Email: oran@cisco.com > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Jan 7 23:20:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12133 for ; Tue, 7 Jan 2003 23:20:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h084VLI11733 for avt-archive@odin.ietf.org; Tue, 7 Jan 2003 23:31:21 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h084TBJ11557; Tue, 7 Jan 2003 23:29:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h084SJJ11530 for ; Tue, 7 Jan 2003 23:28:19 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12005 for ; Tue, 7 Jan 2003 23:16:46 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.81]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h084K3YH026762; Tue, 7 Jan 2003 23:20:04 -0500 (EST) Message-ID: <3E1BA6F0.7000708@dynamicsoft.com> Date: Tue, 07 Jan 2003 23:20:01 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Casner CC: AVT WG Subject: Re: [AVT] RTP: SSRC multiplexing for same medium References: <20030107151203.W73937-100000@ash.packetdesign.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I generally support the idea of multiplexing using SSRC. However, I found the text a bit inadequate for a couple of reasons: 1. multiplexing using different SSRC for the same media on the same RTP session is going to be the default case for multicast sessions, no? The text makes it sound like such a thing is an exception. Its true for unicast, but this section seems multicast-centric anyway. 2. Does this text imply that an RTP receiver MUST be prepared to receive multiple multiplexed streams on a single session? I expect most implementations today using unicast are not prepared for that (although I believe they should be) My apologies if these were already discussed during Yokohama; I believe I missed that session. -Jonathan R. Stephen Casner wrote: > At Yokohama, we discussed multiplexing streams distinguished by > different SSRC identifiers within one RTP session. This discussion > was in the context of the retransmission draft. One or more people > requested that a sentence be added to Section 5.2 in the RTP spec to > say that SSRC multiplexing was OK for streams of the same medium > (vs. different media which is the primary emphasis of that section). > Here is the sentence I added. Is it a good idea or bad idea to add > this? If you think adding such a statement is a good idea, does this > sentence say the right thing? > > -- Steve > > OLD: > Using a different SSRC for each medium but sending them in the same > RTP session would avoid the first three problems but not the last > two. > NEW ADDITION: > It may be appropriate to multiplex streams of the same medium > using different SSRC values in one RTP session in scenarios where the > last two problems do not apply. > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Jan 7 23:31:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12283 for ; Tue, 7 Jan 2003 23:31:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h084gqe12756 for avt-archive@odin.ietf.org; Tue, 7 Jan 2003 23:42:52 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h084f7J12673; Tue, 7 Jan 2003 23:41:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h084epJ12658 for ; Tue, 7 Jan 2003 23:40:51 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12245 for ; Tue, 7 Jan 2003 23:29:18 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.81]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h084WZYH026765; Tue, 7 Jan 2003 23:32:35 -0500 (EST) Message-ID: <3E1BA9E0.5060104@dynamicsoft.com> Date: Tue, 07 Jan 2003 23:32:32 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Casner CC: AVT WG Subject: Re: [AVT] RTP: explanation of "sampling instant" References: <20030107144628.B73937-100000@ash.packetdesign.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I think that adding some additional explanation would help, but I found certain aspects of the text confusing. Specific comments inline: Stephen Casner wrote: > NEW ADDITION: > The sampling instant is chosen as the point of reference > for the RTP timestamp because it is known to the > transmitting endpoint and has a common definition for all > media independent of encoding delays or other processing. It took me three reads to parse this. I would propose a comma: The sampling instance is chosen as the point of reference for the RTP timestamp because it is known to the transmitting endpoint and has a common definition for all media, independent of encoding delays or other processing > The purpose is to allow synchronized presentation of all > media sampled at the same time. Comparing RTP timestamps > from different media is not effective because they have > independent random offsets and may advance at different > rates. Aren't these two sentences contradictory? The first says its for synchronized presentation, and the second says it can't be used for that because they have random offsets and advance at different rates. I always thought that the reason we had a separate RTP timestamp and wallclock timestamp was overhead. Because fine granularity is needed for each wallclock time, it requires too many bits to send in each RTP packet. Rather, a timestamp whose granularity is exactly matched to the media is used, and then correlated to the less efficient wallclock time in the infrequent RTCP packets. > Instead, for each medium the RTP timestamp is > related to the sampling instant by pairing it with a > timestamp from a reference clock (wallclock) that > represents the time when the data corresponding to the RTP > timestamp was sampled. The reference clock is shared by > all media to be synchronized. The timestamp pairs are not > transmitted in every data packet, but at a lower rate in > RTCP SR packets as described in Section 6.4. > > Applications transmitting stored data rather than data > sampled in real time typically use a virtual clock to > determine when the next frame or other unit of each medium > in the stored data should be presented. I think "determine" is the wrong word here. Its the receiver that determines when to present it. The sender indicates when it should be presented. So, I would propose: Applications transmitting stored data rather than data sampled in real time typically use a virtual clock to indicate when the next frame (or other unit of each medium) in the stored data should be presented. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Jan 7 23:55:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12677 for ; Tue, 7 Jan 2003 23:55:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0856Cf13448 for avt-archive@odin.ietf.org; Wed, 8 Jan 2003 00:06:12 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0854QJ13396; Wed, 8 Jan 2003 00:04:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0853EJ13364 for ; Wed, 8 Jan 2003 00:03:14 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12639 for ; Tue, 7 Jan 2003 23:51:41 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.81]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h084swYH026779; Tue, 7 Jan 2003 23:54:59 -0500 (EST) Message-ID: <3E1BAF20.8020709@dynamicsoft.com> Date: Tue, 07 Jan 2003 23:54:56 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Casner CC: AVT WG Subject: Re: [AVT] Final edits to RTP spec and A/V profile References: <20030107124926.M73937-100000@ash.packetdesign.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I also think clarification is much needed on this point. I personally remain confused :(. Comments inline. Stephen Casner wrote: > New: > RTP session: An association among a set of participants > communicating with RTP. A participant may be involved in > multiple RTP sessions at the same time. A single RTP > session is defined by a particular pair of destination > transport addresses (one network address plus a port pair > for RTP and RTCP). This definition differs fundamentally from the old. It says that a session is unique to a particular destination address. Previously, each participant in a session could potentially have the same destination address (multicast) or different ones. Now, different ones would imply different sessions. I will note that this new definition is more consistent with my understanding, but it isn't entirely consistent with text that follows: The destination transport address pair > may be common for all participants in the session, as in > the case of IP multicast, or may be different for each, as > in the case of individual unicast network addresses and > port pairs. This directly contradicts the previous sentence. In a multimedia session, each medium is > carried in a separate RTP session with its own RTCP > packets. The multiple RTP sessions are distinguished by > different port number pairs and/or different multicast > addresses. Each RTP session defines a distinct space of > SSRC identifiers (defined next) because the session is > received by a participant on a distinct pair of destination > transport addresses (RTP and RTCP). One RTP session > includes the set of participants that can receive an SSRC > identifier transmitted by one of the participants either in > RTP (SSRC or CSRC) or RTCP. This is consistent with the one destination IP/port = one session view. That may be only two > participants in a point-to-point unicast RTP session, But this, to me, contradicts the above statement. In a point-to-point case, only one user receives the media that is transmitted. By the above definition, this RTP session therefore includes this one participant. or a > larger number connected by IP multicast, multi-unicast to > shared destination transport addresses, or through an RTP > mixer or translator. (Definitions of CSRC, mixer and > translator follow.) Is multi-unicast ever defined elsewhere? I don't think so. Anyway, I do not understand what "multi-unicast to shared destination transport addresses" means. My definition of multi-unicast was a "full-mesh" of connectivity. If there are N participants, each one would be listening for RTP traffic on N separate addresses, one for each sender. That corresponds to a total of N(N-1) RTP sessions based on the session=destination IP/port definition. Each user using a common destination address to receive all the media would constitute N RTP sessions based on this definition. However, that configuration is not what I would expect. You would lose the ability to correlate a media stream (that is, a sequence of RTP packets with a single SSRC) with the SIP dialog which set it up, a key capability I believe. This would also constitute "SSRC multiplexing" (see another message sent by Steve on this subject) which anyway seemed to still be discouraged. So, I am still confused, I'm afraid. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Jan 8 00:51:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15439 for ; Wed, 8 Jan 2003 00:51:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0862Jj16651 for avt-archive@odin.ietf.org; Wed, 8 Jan 2003 01:02:19 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0860SJ16547; Wed, 8 Jan 2003 01:00:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h085xTJ16475 for ; Wed, 8 Jan 2003 00:59:30 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15400 for ; Wed, 8 Jan 2003 00:47:55 -0500 (EST) Received: from cscoamera13263.cisco.com (sjc-vpn1-345.cisco.com [10.21.97.89]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id h085oajT012800; Tue, 7 Jan 2003 21:50:36 -0800 (PST) Message-Id: <5.1.1.5.2.20030107213509.04b7e9e8@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Tue, 07 Jan 2003 21:51:08 -0800 To: Stephen Casner From: Mark Baugher Subject: Re: [AVT] RTP: Note regarding SSM Cc: AVT WG In-Reply-To: <20030107151834.M73937-100000@ash.packetdesign.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Steve, At 03:20 PM 1/7/2003 -0800, Stephen Casner wrote: >One of the IESG comments (this one from Harald Alvestrand) was a >request to add the following "non-normative note" at the end of >Section 6 where RTCP is introduced (i.e., just before 6.1). Does >anyone object? > > Non-normative note: In the multicast routing approach > called Source-Specific Multicast (SSM), only one or a few > senders send multicast data, and receivers may not send > multicast. It has been awhile since I read the SSM I-Ds, but this does not sound right to me. I scanned the documents in http://www.ietf.org/html.charters/ssm-charter.html and cannot find anything about multicast receivers being prevented from sending multicast packets (a multicast sender is also a receiver, right?). SSM defines an (S,G) "channel" that allows receivers to select certain senders to group G. I don't know where it is specified that receivers may not send multicast. Mark >The recommendations here accommodate SSM only > through Section 6.2's option of turning off receivers' RTCP > entirely. Future work will specify adaptation of RTCP for > SSM so that feedback from receivers can be maintained. > > -- Steve > >_______________________________________________ >Audio/Video Transport Working Group >avt@ietf.org >https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Jan 8 01:07:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15715 for ; Wed, 8 Jan 2003 01:06:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h086I3A17809 for avt-archive@odin.ietf.org; Wed, 8 Jan 2003 01:18:03 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h086GMJ17735; Wed, 8 Jan 2003 01:16:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h086F3J17677 for ; Wed, 8 Jan 2003 01:15:03 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15663 for ; Wed, 8 Jan 2003 01:03:27 -0500 (EST) Received: from cscoamera13263.cisco.com ([10.21.83.213]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id h0866AjT022112 for ; Tue, 7 Jan 2003 22:06:10 -0800 (PST) Message-Id: <5.1.1.5.2.20030107220519.049d25c0@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Tue, 07 Jan 2003 22:06:42 -0800 To: AVT WG From: Mark Baugher Subject: Re: [AVT] RTP: Note regarding SSM In-Reply-To: <5.1.1.5.2.20030107213509.04b7e9e8@mira-sjc5-6.cisco.com> References: <20030107151834.M73937-100000@ash.packetdesign.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , At 09:51 PM 1/7/2003 -0800, Mark Baugher wrote: >Steve, > >At 03:20 PM 1/7/2003 -0800, Stephen Casner wrote: >>One of the IESG comments (this one from Harald Alvestrand) was a >>request to add the following "non-normative note" at the end of >>Section 6 where RTCP is introduced (i.e., just before 6.1). Does >>anyone object? >> >> Non-normative note: In the multicast routing approach >> called Source-Specific Multicast (SSM), only one or a few >> senders send multicast data, and receivers may not send >> multicast. > >It has been awhile since I read the SSM I-Ds, but this does not sound >right to me. I scanned the documents in >http://www.ietf.org/html.charters/ssm-charter.html and cannot find >anything about multicast receivers being prevented from sending multicast >packets (a multicast sender is also a receiver, right?). excuse me, a sender that joins/subscribes to (S,G) is also a receiver. Mark >SSM defines an (S,G) "channel" that allows receivers to select certain >senders to group G. I don't know where it is specified that receivers may >not send multicast. > >Mark > >>The recommendations here accommodate SSM only >> through Section 6.2's option of turning off receivers' RTCP >> entirely. Future work will specify adaptation of RTCP for >> SSM so that feedback from receivers can be maintained. >> >> -- Steve >> >>_______________________________________________ >>Audio/Video Transport Working Group >>avt@ietf.org >>https://www1.ietf.org/mailman/listinfo/avt > >_______________________________________________ >Audio/Video Transport Working Group >avt@ietf.org >https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Jan 8 03:09:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13016 for ; Wed, 8 Jan 2003 03:09:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h088KTf02872 for avt-archive@odin.ietf.org; Wed, 8 Jan 2003 03:20:29 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h088IHJ02708; Wed, 8 Jan 2003 03:18:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h088FSJ02620 for ; Wed, 8 Jan 2003 03:15:28 -0500 Received: from mailman.packetdesign.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12930 for ; Wed, 8 Jan 2003 03:03:50 -0500 (EST) Received: from packetdesign.com (main-fw-eth1.packetdesign.com [192.168.0.254]) by mailman.packetdesign.com (8.12.3/8.12.3) with ESMTP id h0886LkB050157; Wed, 8 Jan 2003 00:06:21 -0800 (PST) (envelope-from casner@acm.org) Date: Wed, 8 Jan 2003 00:19:15 -0800 (PST) From: Stephen Casner To: AVT WG Message-ID: <20030108001817.M20595-100000@oak.packetdesign.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [AVT] Profile: G726 payload format Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , We've discussed the issue of sample packing order for G726 payload format in a sequence of steps on this list. The conclusion was sent in a message on November 14. As I said in that message we would do, I have added a note explaining the incompatibility and referring to an alternate set of payload formats called AAL2-G726 to be defined in a separate document, as well as a note deprecating the use of static payload type 2 for G726-32. In addition, I took Simao Campos's suggestion to clarify which bits in the diagrams are LSBs. At the time we decided on this conclusion, Allison Mankin suggested that the AAL2-G726-* payload formats could be added into the RTP profile itself so readers of the profile would have complere information on both formats. However, there are some issues that would result: - Nobody has actually implemented any of the names AAL2-G726-* yet since we just made that up, therefore we don't have two interoperating implementations as required for Draft Standard (which is the status at which the profile is to be published). - The MIME subtypes for the payload formats in the profile draft are registered via draft-ietf-avt-rtp-mime-06 which is already at the RFC Editor. We'd need to send an RFC Editor note to add the registrations for AAL2-G726-* into that draft, which would cause a bunch of sections to be renumbered, which has to be done manually in the way the RFC Editor prepares documents. Therefore, I believe it would be better to define the AAL2-G726-* payload formats in a new document that we should publish as a Proposed Standard post haste. My resulting edits follow. First, the note: Note that the "little-endian" direction in which samples are packed into octets in the G726-16, -24, -32 and -48 payload formats specified here is consistent with ITU-T Recommendation X.420, but is the opposite of what is specified in ITU-T Recommendation I.366.2 Annex E for ATM AAL2 transport. A second set of RTP payload formats matching the packetization of I.366.2 Annex E and identified by MIME subtypes AAL2-G726-16, -24, -32 and -48 will be specified in a separate document. Second, the deprecation of static payload type 2, in Section 6: Payload type 2 was assigned to G721 in RFC 1890 and to its equivalent successor G726-32 in draft versions of this specification, but its use is now deprecated and that static payload type is marked reserved due to conflicting use for the payload formats G726-32 and AAL2-G726-32 (see Section 4.5.4). In the "Changes from RFC 1890" appendix: o The payload format for G721 was renamed to G726-32 following the ITU-T renumbering, and the payload format description for G726 was expanded to include the -16, -24 and -40 data rates. Because of confusion regarding draft revisions of this document, some implementations of these G726 payload formats packed samples into octets starting with the most significant bit rather than the least significant bit as specified here. To partially resolve this incompatibility, new payload formats named AAL2-G726-16, -24, -32 and -48 will be specified in a separate document (see note in Section 4.5.4), and use of static payload type 2 is deprecated as explained in Section 6. Finally, the clarification of the diagrams: An example of the packing scheme for G726-32 codewords is as shown, where bit 7 is the least significant bit of the first octet, and bit A3 is the least significant bit of the first codeword: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- |B B B B|A A A A|D D D D|C C C C| ... |0 1 2 3|0 1 2 3|0 1 2 3|0 1 2 3| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- An example of the packing scheme for G726-24 codewords follows, where again bit 7 is the least significant bit of the first octet, and bit A2 is the least significant bit of the first codeword: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- |C C|B B B|A A A|F|E E E|D D D|C|H H H|G G G|F F| ... |1 2|0 1 2|0 1 2|2|0 1 2|0 1 2|0|0 1 2|0 1 2|0 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Are these changes sufficient? (I realize they won't be satisfying to those who wanted a different conclusion.) -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Jan 8 03:24:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13278 for ; Wed, 8 Jan 2003 03:24:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h088Zsf03504 for avt-archive@odin.ietf.org; Wed, 8 Jan 2003 03:35:54 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h088YDJ03462; Wed, 8 Jan 2003 03:34:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h088XIJ03418 for ; Wed, 8 Jan 2003 03:33:18 -0500 Received: from mailman.packetdesign.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13234 for ; Wed, 8 Jan 2003 03:21:39 -0500 (EST) Received: from packetdesign.com (main-fw-eth1.packetdesign.com [192.168.0.254]) by mailman.packetdesign.com (8.12.3/8.12.3) with ESMTP id h088OGkB078202; Wed, 8 Jan 2003 00:24:17 -0800 (PST) (envelope-from casner@acm.org) Date: Wed, 8 Jan 2003 00:37:10 -0800 (PST) From: Stephen Casner To: AVT WG Message-ID: <20030108003558.N20595-100000@oak.packetdesign.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [AVT] Profile: G.729 vs G.729A Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , In October, I received a message from Don Stanwyck who was seriously concerned because the RTP A/V profile and draft-ietf-avt-rtp-mime-06 did not specify any way to signal G.729A as distinct from G.729. My interpretation of his concern was that because we only have a MIME type "G729" that an endpoint which only implemented the less-complex G.729A algorithm would not be compliant. He assumed that negotiating G729 payload format implied a resource commitment for the more complex algorithm. The reason we define only one payload format and one MIME type for RTP is that the G.729 and G.729A algorithms are interoperable. To make this clear, I have added the following text: OLD A reduced-complexity version of the G.729 algorithm is specified in Annex A to Rec. G.729. The speech coding algorithms in the main body of G.729 and in G.729 Annex A are fully interoperable with each other, so there is no need to further distinguish between them. NEW ADDITION: An implementation that signals or accepts use of G729 payload format may implement either G.729 or G.729A unless restricted by additional signaling specified elsewhere related specifically to the encoding rather than the payload format. -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Jan 8 03:32:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13480 for ; Wed, 8 Jan 2003 03:32:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h088hjR04404 for avt-archive@odin.ietf.org; Wed, 8 Jan 2003 03:43:45 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h088g4J04379; Wed, 8 Jan 2003 03:42:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h088fsJ04363 for ; Wed, 8 Jan 2003 03:41:54 -0500 Received: from mailman.packetdesign.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13393 for ; Wed, 8 Jan 2003 03:30:15 -0500 (EST) Received: from packetdesign.com (main-fw-eth1.packetdesign.com [192.168.0.254]) by mailman.packetdesign.com (8.12.3/8.12.3) with ESMTP id h088WpkB091704; Wed, 8 Jan 2003 00:32:51 -0800 (PST) (envelope-from casner@acm.org) Date: Wed, 8 Jan 2003 00:45:44 -0800 (PST) From: Stephen Casner To: AVT WG Message-ID: <20030108004243.V20595-100000@oak.packetdesign.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [AVT] That's all Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , OK, that's all of my edit notes: [AVT] Final edits to RTP spec and A/V profile [AVT] RTP: explanation of "sampling instant" [AVT] RTP: Note regarding SSM [AVT] RTP: SSRC multiplexing for same medium [AVT] RTP: control traffic adds to session bandwidth [AVT] RTP: When to turn off RTCP reception reports [AVT] RTP: IPv6 examples for RTCP SDES CNAME [AVT] RTP: Confidentiality mechanisms [AVT] Profile: Silence suppression is allowed by default [AVT] Profile: G726 payload format [AVT] Profile: G.729 vs G.729A Thanks to those of you who have already commented on several of these messages. I will respond tomorrow. -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Jan 8 06:11:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16487 for ; Wed, 8 Jan 2003 06:11:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08BN2213949 for avt-archive@odin.ietf.org; Wed, 8 Jan 2003 06:23:02 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08BKwJ13881; Wed, 8 Jan 2003 06:20:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08BJSJ13817 for ; Wed, 8 Jan 2003 06:19:28 -0500 Received: from multicasttech.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16460 for ; Wed, 8 Jan 2003 06:07:48 -0500 (EST) Received: from [68.100.8.94] (account marshall_eubanks HELO localhost) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 1569629; Wed, 08 Jan 2003 06:10:52 -0500 Date: Wed, 8 Jan 2003 06:10:50 -0500 Subject: Re: [AVT] RTP: Note regarding SSM Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: AVT WG To: Stephen Casner From: Marshall Eubanks In-Reply-To: <20030107151834.M73937-100000@ash.packetdesign.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dear Stephen; On Tuesday, January 7, 2003, at 06:20 PM, Stephen Casner wrote: > One of the IESG comments (this one from Harald Alvestrand) was a > request to add the following "non-normative note" at the end of > Section 6 where RTCP is introduced (i.e., just before 6.1). Does > anyone object? > > Non-normative note: In the multicast routing approach > called Source-Specific Multicast (SSM), only one or a few I do not like "a few" here. There is one sender per channel. True, there can be multiple channels, but then it is not limited to "a few", and, of course, there is nothing stopping the receivers from sending on their own channel. I would change this sentence to In the multicast routing approach called Source-Specific Multicast (SSM), there is only one sender per "channel" (source - group pair), and receivers cannot use multicast to communicate directly with other channel members. > senders send multicast data, and receivers may not send > multicast. The recommendations here accommodate SSM only > through Section 6.2's option of turning off receivers' RTCP > entirely. Future work will specify adaptation of RTCP for > SSM so that feedback from receivers can be maintained. > > -- Steve > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > Regards Marshall Eubanks T.M. Eubanks Multicast Technologies, Inc. 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@multicasttech.com http://www.multicasttech.com Test your network for multicast : http://www.multicasttech.com/mt/ Status of Multicast on the Web : http://www.multicasttech.com/status/index.html _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Jan 8 09:40:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21204 for ; Wed, 8 Jan 2003 09:40:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08EppB26547 for avt-archive@odin.ietf.org; Wed, 8 Jan 2003 09:51:51 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08EoeJ26497; Wed, 8 Jan 2003 09:50:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08EnrJ26441 for ; Wed, 8 Jan 2003 09:49:53 -0500 Received: from purple.nge.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21162 for ; Wed, 8 Jan 2003 09:38:06 -0500 (EST) Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.6/8.12.6) with ESMTP id h08Ef69F031015; Wed, 8 Jan 2003 09:41:06 -0500 (EST) (envelope-from csp@purple.nge.isi.edu) Message-Id: <200301081441.h08Ef69F031015@purple.nge.isi.edu> To: Jonathan Rosenberg cc: Stephen Casner , AVT WG Subject: Re: [AVT] Profile: Silence suppression is allowed by default In-Reply-To: Your message of "Tue, 07 Jan 2003 23:03:14 EST." <3E1BA302.3020803@dynamicsoft.com> Date: Wed, 08 Jan 2003 09:41:06 -0500 From: Colin Perkins Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --> Jonathan Rosenberg writes: >I think this addition is great. I have seen this issue come up all the >time. Some comments on the wording inline: > >Stephen Casner wrote: > >> To make this more explicit, I added the following paragraphs at the >> beginning of Section 4.1 in the A/V profile: >> >> Since the ability to suppress silence is one of the primary >> motivations for using packets to transmit voice, the RTP header >> carries both a sequence number and a timestamp to allow a receiver to >> distinguish between lost packets and periods of time when no data was >> transmitted. Discontiguous transmission (silence suppression) MAY be >> used with any audio payload format. Receivers MUST accept silence >> suppression unless its use is restricted by signaling specified >> elsewhere. > >Since silence suppression is just the absence of packets, its not clear >what it means to "accept" it. > >> (Even if the transmitter does not suppress silence, the >> receiver must be prepared to handle periods when no data is present >> since packets may be lost.) > >This sentence and the previous appear contradictory to me. The previous >says that you won't need to handle silence suppression if signaling says >its not in use, but this sentence says you need it anyway. > >I would propose the last two sentences be replaced with: > >Receivers MUST be prepared to handle the absence of packets for an >arbitrary period of time in order to accomodate silence suppression at >the sender. This applies even if silence suppression is not in use >(which can be known to the receiver through signaling, outside the scope >of this specification), because packet loss cannot be distinguished from >silence suppression. This is not accurate either, since you can distinguish loss from silence suppression using the sequence number. We could change the last few words to "because packet loss may cause arbitrary gaps in reception", or similar? Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Jan 8 09:54:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21552 for ; Wed, 8 Jan 2003 09:54:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08F5lI27216 for avt-archive@odin.ietf.org; Wed, 8 Jan 2003 10:05:47 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08F18J27001; Wed, 8 Jan 2003 10:01:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08AchJ11771 for ; Wed, 8 Jan 2003 05:38:43 -0500 Received: from co1.dslextreme.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15885 for ; Wed, 8 Jan 2003 05:27:03 -0500 (EST) Received: from WIND (hyervision.com [66.159.193.111]) by co1.dslextreme.com (8.12.2/8.12.2) with ESMTP id h08AOUTk006127; Wed, 8 Jan 2003 02:25:00 -0800 From: "Adam Li" To: "'Adam Li'" , "'Stephen Casner'" , "'Allison Mankin'" , , Cc: "'Pete McCann'" , "'Michael D. Turner'" , "'Randall Gellens'" , "'Stinson S Mathai'" , "'Marcello Lioy'" , "'Thomas Zeng'" , "'Greg Sherwood'" , "'John D. Villasenor'" , "'Yung Lyul Lee'" , "'Jeong-Hoon Park'" , "'Miller Keith \(NRC/Dallas\)'" , "'Tom Hiller'" , "'Leon David \(NRC/Dallas\)'" , "'Nikolai Leung'" , "'Dan Gal'" , , "'Lars-Erik Jonsson \(EPL\)'" , , "'Vivek Bhargava'" , "'Greer Craig \(Nokia/Dallas\)'" , "'Magda L. Espelien'" Date: Wed, 8 Jan 2003 02:28:32 -0800 Organization: UCLA Message-ID: <000201c2b700$b1e345e0$6c7ba8c0@divxnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Importance: Normal In-Reply-To: <000c01c2b626$beace6d0$6c7ba8c0@divxnetworks.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Subject: [AVT] draft-ietf-avt-evrc-smv change request Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dear AVTers, The following are some changes we proposed to be made to the draft-ietf-avt-evrc-smv. These are small changes to clarify the text and enable easier accommodation of EVRC/SMV codec update in the future without changing the payload format specification. The changes have no effect on the payload format for the current version of the EVRC/SMV codec. The changes are made to Section 10 of the draft "Mode Request". (The line numbers are referring to draft version -03). * On Paragraph 3 Line 3, replace word "non-zero" with "valid"; * On Paragraph 3 Line 7, remove word "non-zero"; * On Paragraph 3 Line 8, replace "until the requested mode has changed" with "until the request mode is different"; * In Paragraph 5, remove the second sentence "Value above '100' ..."; * In Paragraph 6, remove the second sentence "Value above '101' ...". The complete text of the modified version can be found at ftp://ftp.icsl.ucla.edu/pub/EVRC/draft-ietf-avt-evrc-smv-04.txt. Thank you very much. Adam _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Jan 8 10:11:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21897 for ; Wed, 8 Jan 2003 10:11:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08FMdO28559 for avt-archive@odin.ietf.org; Wed, 8 Jan 2003 10:22:39 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08FLFJ28456; Wed, 8 Jan 2003 10:21:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08FJgJ28362 for ; Wed, 8 Jan 2003 10:19:42 -0500 Received: from zsc3s004.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21820 for ; Wed, 8 Jan 2003 10:07:56 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h08FB9608043; Wed, 8 Jan 2003 07:11:09 -0800 (PST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h08FBLd19630; Wed, 8 Jan 2003 09:11:21 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Jan 2003 09:11:08 -0600 Message-ID: <1B54FA3A2709D51195C800508BF9386A080B36A8@zrc2c000.us.nortel.com> From: "Peter Barany" To: "'Stephen Casner'" , AVT WG Subject: RE: [AVT] RTP: IPv6 examples for RTCP SDES CNAME Date: Wed, 8 Jan 2003 09:11:06 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2B728.2AEE2460" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2B728.2AEE2460 Content-Type: text/plain; charset="ISO-8859-1" Hi Stephen, FYI. The IPv6 address that I used in the suggested text that I sent to the IETF AVT WG reflector can also be found in an example in RFC 3266 "Support for IPv6 in Session Description Protocol (SDP)" (see Section 4 of RFC 3266). Don't know if this addresses your concern or not. Thanks. Regards, Pete -----Original Message----- From: Stephen Casner [mailto:casner@acm.org] Sent: Tuesday, January 07, 2003 6:19 PM To: AVT WG Subject: [AVT] RTP: IPv6 examples for RTCP SDES CNAME At the suggestion of Peter Barany, I added explanation and examples of IPv6 address formats to the IPv4 cases that were already there for the format of the RTCP SDES CNAME item. I expect these are not controversial. Is this IPv6 address officially designated for use in document examples as 192.0.2.0/24 is for IPv4? Use of a real address is generally not advised. -- Steve For example, the standard ASCII representation of an IP Version 4 address is "dotted decimal", also known as dotted quad, and for IP Version 6, addresses are textually represented as eight groups of four hexadecimal digits separated by colons. ... Examples are "doe@sleepy.megacorp.com", "doe@192.0.2.89" or "doe@2201:056D::112E:144A:1E24" for a multi-user system. On a system with no user name, examples would be "sleepy.megacorp.com", "192.0.2.89" or "2201:056D::112E:144A:1E24". _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt ------_=_NextPart_001_01C2B728.2AEE2460 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [AVT] RTP: IPv6 examples for RTCP SDES CNAME

Hi Stephen,

FYI. The IPv6 address that I used in the suggested = text that I sent to the IETF AVT WG reflector can also be found in an = example in RFC 3266 "Support for IPv6 in Session Description = Protocol (SDP)" (see Section 4 of RFC 3266). Don't know if this = addresses your concern or not. Thanks.

Regards,

Pete

-----Original Message-----
From: Stephen Casner [mailto:casner@acm.org]
Sent: Tuesday, January 07, 2003 6:19 PM
To: AVT WG
Subject: [AVT] RTP: IPv6 examples for RTCP SDES = CNAME


At the suggestion of Peter Barany, I added = explanation and examples of
IPv6 address formats to the IPv4 cases that were = already there for the
format of the RTCP SDES CNAME item.  I expect = these are not
controversial.  Is this IPv6 address officially = designated for use in
document examples as 192.0.2.0/24 is for IPv4?  = Use of a real address
is generally not advised.

          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;         -- Steve

   For example, the standard ASCII
   representation of an IP Version 4 = address is "dotted decimal", also
   known as dotted quad, and for IP = Version 6, addresses are textually
   represented as eight groups of four = hexadecimal digits separated by
   colons.  ...

   Examples are = "doe@sleepy.megacorp.com", "doe@192.0.2.89" = or
   = "doe@2201:056D::112E:144A:1E24" for a multi-user = system.  On a system
   with no user name, examples would be = "sleepy.megacorp.com",
   "192.0.2.89" or = "2201:056D::112E:144A:1E24".

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt

------_=_NextPart_001_01C2B728.2AEE2460-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Jan 8 10:39:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22692 for ; Wed, 8 Jan 2003 10:39:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08Foa330498 for avt-archive@odin.ietf.org; Wed, 8 Jan 2003 10:50:36 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08FkAJ30250; Wed, 8 Jan 2003 10:46:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08FjjJ30228 for ; Wed, 8 Jan 2003 10:45:45 -0500 Received: from zsc3s004.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22497 for ; Wed, 8 Jan 2003 10:33:58 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h08FbA612529; Wed, 8 Jan 2003 07:37:11 -0800 (PST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h08FbMd24079; Wed, 8 Jan 2003 09:37:22 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Jan 2003 09:37:09 -0600 Message-ID: <1B54FA3A2709D51195C800508BF9386A080B36AA@zrc2c000.us.nortel.com> From: "Peter Barany" To: "'Colin Perkins'" , Stephen Casner Cc: AVT WG Subject: RE: [AVT] RTP: IPv6 examples for RTCP SDES CNAME Date: Wed, 8 Jan 2003 09:37:06 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2B72B.CCAB72A0" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2B72B.CCAB72A0 Content-Type: text/plain; charset="ISO-8859-1" Colin, Agreed. Perhaps the clarification below will address your concern: > For example, the standard ASCII > representation of an IP Version 4 address is "dotted decimal", also > known as dotted quad, and for IP Version 6, addresses are textually > represented as eight groups of four hexadecimal digits separated by > colons, where a contiguous sequence of 16-bit blocks set to "0" in the > colon hexadecimal format can be compressed to "::" (this zero compression > can only be used to compress a single contiguous sequence of 16-bit blocks > within an IP Version 6 address). Regards, Pete -----Original Message----- From: Colin Perkins [mailto:csp@csperkins.org] Sent: Tuesday, January 07, 2003 8:03 PM To: Stephen Casner Cc: AVT WG Subject: Re: [AVT] RTP: IPv6 examples for RTCP SDES CNAME --> Stephen Casner writes: >At the suggestion of Peter Barany, I added explanation and examples of >IPv6 address formats to the IPv4 cases that were already there for the >format of the RTCP SDES CNAME item. I expect these are not >controversial. Is this IPv6 address officially designated for use in >document examples as 192.0.2.0/24 is for IPv4? Use of a real address >is generally not advised. > > -- Steve > > For example, the standard ASCII > representation of an IP Version 4 address is "dotted decimal", also > known as dotted quad, and for IP Version 6, addresses are textually > represented as eight groups of four hexadecimal digits separated by > colons. ... I suspect this description is not sufficient, since formats like FF01::101 and ::13.1.68.3 are allowed by RFC 2373. We should probably reference that definition directly. Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt ------_=_NextPart_001_01C2B72B.CCAB72A0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [AVT] RTP: IPv6 examples for RTCP SDES CNAME

Colin,

Agreed. Perhaps the clarification below will address = your concern:

>   For example, the standard = ASCII
>   representation of an IP Version 4 = address is "dotted decimal", also
>   known as dotted quad, and for IP = Version 6, addresses are textually
>   represented as eight groups of four = hexadecimal digits separated by
>   colons, where a contiguous sequence = of 16-bit blocks set to "0" in the
>   colon hexadecimal format can be = compressed to "::" (this zero compression
>   can only be used to compress a = single contiguous sequence of 16-bit blocks
>   within an IP Version 6 = address).

Regards,

Pete

-----Original Message-----
From: Colin Perkins [mailto:csp@csperkins.org]
Sent: Tuesday, January 07, 2003 8:03 PM
To: Stephen Casner
Cc: AVT WG
Subject: Re: [AVT] RTP: IPv6 examples for RTCP SDES = CNAME


--> Stephen Casner writes:
>At the suggestion of Peter Barany, I added = explanation and examples of
>IPv6 address formats to the IPv4 cases that were = already there for the
>format of the RTCP SDES CNAME item.  I = expect these are not
>controversial.  Is this IPv6 address = officially designated for use in
>document examples as 192.0.2.0/24 is for = IPv4?  Use of a real address
>is generally not advised.
>
>          = ;            = ;            = ;            = ;          -- Steve
>
>   For example, the standard = ASCII
>   representation of an IP Version 4 = address is "dotted decimal", also
>   known as dotted quad, and for IP = Version 6, addresses are textually
>   represented as eight groups of four = hexadecimal digits separated by
>   colons.  ...

I suspect this description is not sufficient, since = formats like FF01::101
and ::13.1.68.3 are allowed by RFC 2373. We should = probably reference that
definition directly.

Colin
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt

------_=_NextPart_001_01C2B72B.CCAB72A0-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Jan 8 10:56:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22989 for ; Wed, 8 Jan 2003 10:56:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08G7u731782 for avt-archive@odin.ietf.org; Wed, 8 Jan 2003 11:07:56 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08G5SJ31129; Wed, 8 Jan 2003 11:05:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08G1cJ30909 for ; Wed, 8 Jan 2003 11:01:38 -0500 Received: from accord-ntsrv3.accord.co.il (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22860 for ; Wed, 8 Jan 2003 10:49:51 -0500 (EST) Received: by ACCORD-NTSRV3 with Internet Mail Service (5.5.2656.59) id ; Wed, 8 Jan 2003 17:52:49 +0200 Message-ID: From: "Even, Roni" To: "'Stephen Casner'" , AVT WG Subject: RE: [AVT] RTP: SSRC multiplexing for same medium Date: Wed, 8 Jan 2003 17:52:48 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Hi, Does it mean that you are saying that it is OK to multiplex RTP from different sources. For example audio stream from two different sources coming to the same RTP port. I thought that it is better to let the transport layer handle the multiplexing in the network. Thanks Roni Even > -----Original Message----- > From: Stephen Casner [mailto:casner@acm.org] > Sent: Wednesday, January 08, 2003 1:18 AM > To: AVT WG > Subject: [AVT] RTP: SSRC multiplexing for same medium > > > At Yokohama, we discussed multiplexing streams distinguished by > different SSRC identifiers within one RTP session. This discussion > was in the context of the retransmission draft. One or more people > requested that a sentence be added to Section 5.2 in the RTP spec to > say that SSRC multiplexing was OK for streams of the same medium > (vs. different media which is the primary emphasis of that section). > Here is the sentence I added. Is it a good idea or bad idea to add > this? If you think adding such a statement is a good idea, does this > sentence say the right thing? > > -- Steve > > OLD: > Using a different SSRC for each medium but sending them in the same > RTP session would avoid the first three problems but not the last > two. > NEW ADDITION: > It may be appropriate to multiplex streams of the same medium > using different SSRC values in one RTP session in > scenarios where the > last two problems do not apply. > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Jan 8 10:57:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23037 for ; Wed, 8 Jan 2003 10:57:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08G9Eq31894 for avt-archive@odin.ietf.org; Wed, 8 Jan 2003 11:09:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08G83J31854; Wed, 8 Jan 2003 11:08:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08G7dJ31753 for ; Wed, 8 Jan 2003 11:07:39 -0500 Received: from accord-ntsrv3.accord.co.il (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22969 for ; Wed, 8 Jan 2003 10:55:51 -0500 (EST) Received: by ACCORD-NTSRV3 with Internet Mail Service (5.5.2656.59) id ; Wed, 8 Jan 2003 17:58:50 +0200 Message-ID: From: "Even, Roni" To: "'Jonathan Rosenberg'" , Stephen Casner Cc: AVT WG Subject: RE: [AVT] RTP: SSRC multiplexing for same medium Date: Wed, 8 Jan 2003 17:58:49 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Hi, One of the reasons mentioned for supporting it in Yokohama was to solve a problem of IP stack that do not handle the "select" on multiple ports very well. Is this a good reason for supporting unicast multiplexing in RTP. I am not an expert on QoS but will there be a problem with QoS protocols that will not be able to give different QoS for different users. Thanks Roni Even Polycom > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Wednesday, January 08, 2003 6:20 AM > To: Stephen Casner > Cc: AVT WG > Subject: Re: [AVT] RTP: SSRC multiplexing for same medium > > > I generally support the idea of multiplexing using SSRC. However, I > found the text a bit inadequate for a couple of reasons: > > 1. multiplexing using different SSRC for the same media on > the same RTP > session is going to be the default case for multicast > sessions, no? The > text makes it sound like such a thing is an exception. Its true for > unicast, but this section seems multicast-centric anyway. > > 2. Does this text imply that an RTP receiver MUST be prepared > to receive > multiple multiplexed streams on a single session? I expect most > implementations today using unicast are not prepared for that > (although > I believe they should be) > > My apologies if these were already discussed during Yokohama; > I believe > I missed that session. > > -Jonathan R. > > > Stephen Casner wrote: > > At Yokohama, we discussed multiplexing streams distinguished by > > different SSRC identifiers within one RTP session. This discussion > > was in the context of the retransmission draft. One or more people > > requested that a sentence be added to Section 5.2 in the RTP spec to > > say that SSRC multiplexing was OK for streams of the same medium > > (vs. different media which is the primary emphasis of that section). > > Here is the sentence I added. Is it a good idea or bad idea to add > > this? If you think adding such a statement is a good idea, > does this > > sentence say the right thing? > > > > -- Steve > > > > OLD: > > Using a different SSRC for each medium but sending them > in the same > > RTP session would avoid the first three problems but not the last > > two. > > NEW ADDITION: > > It may be appropriate to multiplex streams of the same medium > > using different SSRC values in one RTP session in > scenarios where the > > last two problems do not apply. > > > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www1.ietf.org/mailman/listinfo/avt > > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Jan 8 11:15:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23526 for ; Wed, 8 Jan 2003 11:15:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08GQUw00350 for avt-archive@odin.ietf.org; Wed, 8 Jan 2003 11:26:30 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08GPUJ32750; Wed, 8 Jan 2003 11:25:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08GO4J32673 for ; Wed, 8 Jan 2003 11:24:04 -0500 Received: from chiron.nge.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23470 for ; Wed, 8 Jan 2003 11:12:17 -0500 (EST) Received: from chiron (csp@localhost) by chiron.nge.isi.edu (8.11.6/8.11.6) with ESMTP id h08GFTK24678; Wed, 8 Jan 2003 11:15:29 -0500 Message-Id: <200301081615.h08GFTK24678@chiron.nge.isi.edu> To: "Peter Barany" cc: Stephen Casner , AVT WG Subject: Re: [AVT] RTP: IPv6 examples for RTCP SDES CNAME In-Reply-To: Your message of "Wed, 08 Jan 2003 09:37:06 CST." <1B54FA3A2709D51195C800508BF9386A080B36AA@zrc2c000.us.nortel.com> Date: Wed, 08 Jan 2003 11:15:29 -0500 From: Colin Perkins Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Pete, --> "Peter Barany" writes: >Agreed. Perhaps the clarification below will address your concern: > >> For example, the standard ASCII >> representation of an IP Version 4 address is "dotted decimal", also >> known as dotted quad, and for IP Version 6, addresses are textually >> represented as eight groups of four hexadecimal digits separated by >> colons, where a contiguous sequence of 16-bit blocks set to "0" in the >> colon hexadecimal format can be compressed to "::" (this zero compression >> can only be used to compress a single contiguous sequence of 16-bit blocks >> within an IP Version 6 address). Definitely better. Is the ::10.0.0.1 form of IPv6 address still legal though? Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Jan 8 11:30:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23913 for ; Wed, 8 Jan 2003 11:30:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08GfxQ01870 for avt-archive@odin.ietf.org; Wed, 8 Jan 2003 11:41:59 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08GfHJ01823; Wed, 8 Jan 2003 11:41:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08GcuJ01626 for ; Wed, 8 Jan 2003 11:38:56 -0500 Received: from chiron.nge.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23775 for ; Wed, 8 Jan 2003 11:27:08 -0500 (EST) Received: from chiron (csp@localhost) by chiron.nge.isi.edu (8.11.6/8.11.6) with ESMTP id h08GULu24712; Wed, 8 Jan 2003 11:30:21 -0500 Message-Id: <200301081630.h08GULu24712@chiron.nge.isi.edu> To: "Even, Roni" cc: "'Stephen Casner'" , AVT WG Subject: Re: [AVT] RTP: SSRC multiplexing for same medium In-Reply-To: Your message of "Wed, 08 Jan 2003 17:52:48 +0200." Date: Wed, 08 Jan 2003 11:30:21 -0500 From: Colin Perkins Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --> "Even, Roni" writes: >Hi, >Does it mean that you are saying that it is OK to multiplex RTP from >different sources. For example audio stream from two different sources >coming to the same RTP port. I thought that it is better to let the That has always been legal, and is the norm for multicast sessions. The addition is intended to make it clear that FEC data and/or retransmissions from a single source can be multiplexed along with the original data. Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Jan 8 11:48:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24605 for ; Wed, 8 Jan 2003 11:48:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08Gxxv03003 for avt-archive@odin.ietf.org; Wed, 8 Jan 2003 11:59:59 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08GxJJ02967; Wed, 8 Jan 2003 11:59:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08GwHJ02911 for ; Wed, 8 Jan 2003 11:58:17 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24546 for ; Wed, 8 Jan 2003 11:46:30 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h08GnhAv007290; Wed, 8 Jan 2003 17:49:43 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZGNBTQG9; Wed, 8 Jan 2003 17:49:43 +0100 Message-ID: <3E1C56A7.2070608@era.ericsson.se> Date: Wed, 08 Jan 2003 17:49:43 +0100 X-Sybari-Trust: b94271e3 1864f774 f8c9f798 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Even, Roni" CC: "'Stephen Casner'" , AVT WG Subject: Re: [AVT] RTP: SSRC multiplexing for same medium References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, I think we need to get this definition very clear and clarify a couple of things. So lets make an example of how I have interpreted what's right and wrong in RTP multiplexing: Case A: A receiver has an IP address (interface) and a port pair (RTP and RTCP). All RTP messages coming in on the RTP port is going to the same RTP session. Lets say that this RTP session is intended for Audio. So RTP messages coming from host A's microphone 1 (lecturer) is sent with SSRC A1. Host A also has a second microphone, nr 2 (for questions in the lecture hall). The RTP stream from microphone 2 at host A will use SSRC A2 when sending. There are also some listeners out there on the internet receiving this session. When the user at host B wants to ask a question he uses his mic and sends a audio stream with SSRC B1. These are all media streams belonging to the same RTP session and using SSRC multiplexing in what I believe is the intended way. Because SSRC A1 and A2 it is what distinguish the packets from host A from each other. They will otherwise have the same source and port and being received at the same RTP session. It is after all logical to have all these three sources in the same session as all participating in the lecture would like to hear all questions and the lecturer, they form a session. Case B: It is not intended and strongly argued against sending also the video flow(s) to the same RTP session (destination/port) as the audio. The reason is that this is another media, which has other properties and may be controlled independent of the audio. See also chapter 5.2. Case C: Know we comes to the interesting case that resulted in some debate, retransmission. As retransmission works in a proper way when sent in a way that makes it possible to distinguish from the original flow some multiplexing must happen. Due to the need for uninterrupted original RTP sequence numbers the multiplexing can't be the payload type which seems to be the most obvious one. Therefore some other multiplexing is needed. First, use another RTP session, works without problems, avoiding all the pitfalls in 5.2. However creating a completely new RTP session and using more ports are rather expensive in terms of resources. So looking at the retransmission flow one can state that this is in fact the same media as in the original flow + some extra wrapping. Therefore the reasons in section 5.2 of RTP spec does not apply. It is after all this case above that the extra sentence tries to address. However it seems evident that there is a lack of a clear explanation of the first case (A), which is actually the recommended one. However to explain this in much fewer words than above I don't think I am capable of. Even, Roni wrote: >Hi, >Does it mean that you are saying that it is OK to multiplex RTP from >different sources. For example audio stream from two different sources >coming to the same RTP port. I thought that it is better to let the >transport layer handle the multiplexing in the network. > Yes, it is allowed to multiplex RTP streams from different sources as long as the they are of the same media and based on the "same" session declaration, i.e. using the same media codecs and configurations. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Jan 8 12:27:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26901 for ; Wed, 8 Jan 2003 12:27:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08HcZo06563 for avt-archive@odin.ietf.org; Wed, 8 Jan 2003 12:38:35 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08HY3J05715; Wed, 8 Jan 2003 12:34:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08HWQJ05637 for ; Wed, 8 Jan 2003 12:32:26 -0500 Received: from zsc3s004.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26246 for ; Wed, 8 Jan 2003 12:20:36 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h08HNm621760; Wed, 8 Jan 2003 09:23:48 -0800 (PST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h08HO0d02106; Wed, 8 Jan 2003 11:24:00 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Jan 2003 11:23:47 -0600 Message-ID: <1B54FA3A2709D51195C800508BF9386A080B36AB@zrc2c000.us.nortel.com> From: "Peter Barany" To: "'Colin Perkins'" Cc: Stephen Casner , AVT WG Subject: RE: [AVT] RTP: IPv6 examples for RTCP SDES CNAME Date: Wed, 8 Jan 2003 11:23:40 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2B73A.B00AD000" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2B73A.B00AD000 Content-Type: text/plain; charset="ISO-8859-1" Colin, Regarding ::10.0.0.1, I believe this is a valid representation of an IPv4 compatible address. However, let me take another stab at amending the text below to account for this an additional rules (e.g.., there are 3 forms for representing IPv6 addresses as text strings). Another way around this would be to refer to the appropriate IETF IPv6 WG document in order to account for all of the variations/rules. What do you think? NOTE: RFC 2373 (which is a Proposed Standard) has been advanced to Draft Standard (draft-ietf-ipngwg-addr-arch-v3-11.txt), approved for publication on Oct. 29, 2002 (RFC #?). Regards, Pete New text below (this should fix/account for everything): >> For example, the standard ASCII >> representation of an IP Version 4 address is "dotted decimal", also >> known as dotted quad, and for IP Version 6, the preferred method for >> representing addresses textually is as eight groups of four hexadecimal >> digits separated by colons, where (1) it is not necessary to write the >> leading zeros in an individual field; (2) a contiguous sequence of 16-bit >> blocks set to "0" in the colon hexadecimal format can be compressed to "::" >> ("::" can only appear once in an address); (3) in a mixed environment of >> IPv4 and IPv6 nodes, an alternative method for textually representing IP Version 6 >> addresses is as six groups of four hexadecimal digits separated by colons >> for the six high-order 16-bit pieces of the address and "dotted decimal" >> for the four low-order 8-bit pieces of the address (standard IPv4 representation). -----Original Message----- From: Colin Perkins [mailto:csp@isi.edu] Sent: Wednesday, January 08, 2003 10:15 AM To: Barany, Peter [RICH1:2H16:EXCH] Cc: Stephen Casner; AVT WG Subject: Re: [AVT] RTP: IPv6 examples for RTCP SDES CNAME Pete, --> "Peter Barany" writes: >Agreed. Perhaps the clarification below will address your concern: > >> For example, the standard ASCII >> representation of an IP Version 4 address is "dotted decimal", also >> known as dotted quad, and for IP Version 6, addresses are textually >> represented as eight groups of four hexadecimal digits separated by >> colons, where a contiguous sequence of 16-bit blocks set to "0" in the >> colon hexadecimal format can be compressed to "::" (this zero compression >> can only be used to compress a single contiguous sequence of 16-bit blocks >> within an IP Version 6 address). Definitely better. Is the ::10.0.0.1 form of IPv6 address still legal though? Colin ------_=_NextPart_001_01C2B73A.B00AD000 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [AVT] RTP: IPv6 examples for RTCP SDES CNAME

Colin,

Regarding ::10.0.0.1, I believe this is a valid = representation of an IPv4 compatible address. However, let me take = another stab at amending the text below to account for this an = additional rules (e.g.., there are 3 forms for representing IPv6 = addresses as text strings). Another way around this would be to refer = to the appropriate IETF IPv6 WG document in order to account for all of = the variations/rules. What do you think? NOTE: RFC 2373 (which is a = Proposed Standard) has been advanced to Draft Standard = (draft-ietf-ipngwg-addr-arch-v3-11.txt), approved for publication on = Oct. 29, 2002 (RFC #?).

Regards,

Pete

New text below (this should fix/account for = everything):

>>   For example, the standard = ASCII
>>   representation of an IP Version = 4 address is "dotted decimal", also
>>   known as dotted quad, and for = IP Version 6, the preferred method for
>>   representing addresses = textually is as eight groups of four hexadecimal
>>   digits separated by colons, = where (1) it is not necessary to write the
>>   leading zeros in an individual = field; (2) a contiguous sequence of 16-bit
>>   blocks set to "0" in = the colon hexadecimal format can be compressed to "::"
>>   ("::" can only appear = once in an address); (3) in a mixed environment of
>>   IPv4 and IPv6 nodes, an = alternative method for textually representing IP Version 6
>>   addresses is as six groups of = four hexadecimal digits separated by colons
>>   for the six high-order 16-bit = pieces of the address and "dotted decimal"
>>   for the four low-order 8-bit = pieces of the address (standard IPv4 representation).

-----Original Message-----
From: Colin Perkins [mailto:csp@isi.edu]
Sent: Wednesday, January 08, 2003 10:15 AM
To: Barany, Peter [RICH1:2H16:EXCH]
Cc: Stephen Casner; AVT WG
Subject: Re: [AVT] RTP: IPv6 examples for RTCP SDES = CNAME


Pete,

--> "Peter Barany" writes:
>Agreed. Perhaps the clarification below will = address your concern:
>
>>   For example, the standard = ASCII
>>   representation of an IP Version = 4 address is "dotted decimal", also
>>   known as dotted quad, and for = IP Version 6, addresses are textually
>>   represented as eight groups of = four hexadecimal digits separated by
>>   colons, where a contiguous = sequence of 16-bit blocks set to "0" in the
>>   colon hexadecimal format can be = compressed to "::" (this zero compression
>>   can only be used to compress a = single contiguous sequence of 16-bit blocks
>>   within an IP Version 6 = address).

Definitely better. Is the ::10.0.0.1 form of IPv6 = address still legal
though?

Colin

------_=_NextPart_001_01C2B73A.B00AD000-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Jan 8 12:29:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27036 for ; Wed, 8 Jan 2003 12:29:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08HeKG06721 for avt-archive@odin.ietf.org; Wed, 8 Jan 2003 12:40:20 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08Hb5J05954; Wed, 8 Jan 2003 12:37:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08HagJ05851 for ; Wed, 8 Jan 2003 12:36:42 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26786 for ; Wed, 8 Jan 2003 12:24:53 -0500 (EST) Received: from cscoamera13263.cisco.com (sjc-vpn4-45.cisco.com [10.21.80.45]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id h08HRYjT002904; Wed, 8 Jan 2003 09:27:34 -0800 (PST) Message-Id: <5.1.1.5.2.20030108090228.02200a08@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 08 Jan 2003 09:22:36 -0800 To: Marshall Eubanks From: Mark Baugher Subject: Re: [AVT] RTP: Note regarding SSM Cc: AVT WG In-Reply-To: References: <20030107151834.M73937-100000@ash.packetdesign.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , At 06:10 AM 1/8/2003 -0500, Marshall Eubanks wrote: >Dear Stephen; > >On Tuesday, January 7, 2003, at 06:20 PM, Stephen Casner wrote: > >>One of the IESG comments (this one from Harald Alvestrand) was a >>request to add the following "non-normative note" at the end of >>Section 6 where RTCP is introduced (i.e., just before 6.1). Does >>anyone object? >> >> Non-normative note: In the multicast routing approach >> called Source-Specific Multicast (SSM), only one or a few > >I do not like "a few" here. There is one sender per channel. True, there >can be multiple channels, but then it is not limited to "a few", and, of >course, >there is nothing stopping the receivers from sending on their own channel. > >I would change this sentence to > >In the multicast routing approach called Source-Specific Multicast (SSM), >there is only >one sender per "channel" (source - group pair), and receivers cannot use >multicast >to communicate directly with other channel members. I think this sentence is a good replacement. It might be more clear to write "source address, group address pair" in place of "source - group pair" and replace "other channel members" with "members of a channel having a source address other than its own." Mark >> senders send multicast data, and receivers may not send >> multicast. The recommendations here accommodate SSM only >> through Section 6.2's option of turning off receivers' RTCP >> entirely. Future work will specify adaptation of RTCP for >> SSM so that feedback from receivers can be maintained. >> >> -- Steve >> >>_______________________________________________ >>Audio/Video Transport Working Group >>avt@ietf.org >>https://www1.ietf.org/mailman/listinfo/avt > Regards > Marshall Eubanks > >T.M. Eubanks >Multicast Technologies, Inc. >10301 Democracy Lane, Suite 410 >Fairfax, Virginia 22030 >Phone : 703-293-9624 Fax : 703-293-9609 >e-mail : tme@multicasttech.com >http://www.multicasttech.com > >Test your network for multicast : >http://www.multicasttech.com/mt/ > Status of Multicast on the Web : > http://www.multicasttech.com/status/index.html > >_______________________________________________ >Audio/Video Transport Working Group >avt@ietf.org >https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Jan 8 14:14:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02790 for ; Wed, 8 Jan 2003 14:14:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08JPOu15066 for avt-archive@odin.ietf.org; Wed, 8 Jan 2003 14:25:24 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08JIdJ14680; Wed, 8 Jan 2003 14:18:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08JHYJ14644 for ; Wed, 8 Jan 2003 14:17:34 -0500 Received: from chiron.nge.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02386 for ; Wed, 8 Jan 2003 14:05:43 -0500 (EST) Received: from chiron (csp@localhost) by chiron.nge.isi.edu (8.11.6/8.11.6) with ESMTP id h08J8sk25810; Wed, 8 Jan 2003 14:08:54 -0500 Message-Id: <200301081908.h08J8sk25810@chiron.nge.isi.edu> To: "Peter Barany" cc: Stephen Casner , AVT WG Subject: Re: [AVT] RTP: IPv6 examples for RTCP SDES CNAME In-Reply-To: Your message of "Wed, 08 Jan 2003 11:23:40 CST." <1B54FA3A2709D51195C800508BF9386A080B36AB@zrc2c000.us.nortel.com> Date: Wed, 08 Jan 2003 14:08:54 -0500 From: Colin Perkins Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Seems reasonable. Colin --> "Peter Barany" writes: >Colin, > >Regarding ::10.0.0.1, I believe this is a valid representation of an IPv4 >compatible address. However, let me take another stab at amending the text >below to account for this an additional rules (e.g.., there are 3 forms for >representing IPv6 addresses as text strings). Another way around this would >be to refer to the appropriate IETF IPv6 WG document in order to account for >all of the variations/rules. What do you think? NOTE: RFC 2373 (which is a >Proposed Standard) has been advanced to Draft Standard >(draft-ietf-ipngwg-addr-arch-v3-11.txt), approved for publication on Oct. >29, 2002 (RFC #?). > >Regards, > >Pete > >New text below (this should fix/account for everything): > >>> For example, the standard ASCII >>> representation of an IP Version 4 address is "dotted decimal", also >>> known as dotted quad, and for IP Version 6, the preferred method for >>> representing addresses textually is as eight groups of four hexadecimal >>> digits separated by colons, where (1) it is not necessary to write the >>> leading zeros in an individual field; (2) a contiguous sequence of >16-bit >>> blocks set to "0" in the colon hexadecimal format can be compressed to >"::" >>> ("::" can only appear once in an address); (3) in a mixed environment >of >>> IPv4 and IPv6 nodes, an alternative method for textually representing >IP Version 6 >>> addresses is as six groups of four hexadecimal digits separated by >colons >>> for the six high-order 16-bit pieces of the address and "dotted >decimal" >>> for the four low-order 8-bit pieces of the address (standard IPv4 >representation). > >-----Original Message----- >From: Colin Perkins [mailto:csp@isi.edu] >Sent: Wednesday, January 08, 2003 10:15 AM >To: Barany, Peter [RICH1:2H16:EXCH] >Cc: Stephen Casner; AVT WG >Subject: Re: [AVT] RTP: IPv6 examples for RTCP SDES CNAME > > >Pete, > >--> "Peter Barany" writes: >>Agreed. Perhaps the clarification below will address your concern: >> >>> For example, the standard ASCII >>> representation of an IP Version 4 address is "dotted decimal", also >>> known as dotted quad, and for IP Version 6, addresses are textually >>> represented as eight groups of four hexadecimal digits separated by >>> colons, where a contiguous sequence of 16-bit blocks set to "0" in the >>> colon hexadecimal format can be compressed to "::" (this zero >compression >>> can only be used to compress a single contiguous sequence of 16-bit >blocks >>> within an IP Version 6 address). > >Definitely better. Is the ::10.0.0.1 form of IPv6 address still legal >though? > >Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Jan 8 14:59:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04698 for ; Wed, 8 Jan 2003 14:59:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08KARS18280 for avt-archive@odin.ietf.org; Wed, 8 Jan 2003 15:10:27 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08K4ZJ17468; Wed, 8 Jan 2003 15:04:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08K3xJ17434 for ; Wed, 8 Jan 2003 15:03:59 -0500 Received: from multicasttech.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04303 for ; Wed, 8 Jan 2003 14:52:05 -0500 (EST) Received: from dhcp-office-44.multicasttech.com (account marshall_eubanks [63.105.122.236] verified) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 1569953; Wed, 08 Jan 2003 14:55:22 -0500 Date: Wed, 8 Jan 2003 14:55:21 -0500 Subject: Re: [AVT] RTP: Note regarding SSM Content-Type: multipart/alternative; boundary=Apple-Mail-3--675987855 Mime-Version: 1.0 (Apple Message framework v482) Cc: AVT WG To: Mark Baugher From: Marshall Eubanks In-Reply-To: <5.1.1.5.2.20030108090228.02200a08@mira-sjc5-6.cisco.com> Message-Id: <1EB2DEFC-2343-11D7-BB72-0030656561EA@multicasttech.com> X-Mailer: Apple Mail (2.482) Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --Apple-Mail-3--675987855 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Dear Mark; On Wednesday, January 8, 2003, at 12:22 PM, Mark Baugher wrote: > At 06:10 AM 1/8/2003 -0500, Marshall Eubanks wrote: >> Dear Stephen; >> >> On Tuesday, January 7, 2003, at 06:20 PM, Stephen Casner wrote: >> >>> One of the IESG comments (this one from Harald Alvestrand) was a >>> request to add the following "non-normative note" at the end of >>> Section 6 where RTCP is introduced (i.e., just before 6.1). Does >>> anyone object? >>> >>> Non-normative note: In the multicast routing approach >>> called Source-Specific Multicast (SSM), only one or a few >> >> I do not like "a few" here. There is one sender per channel. True, >> there >> can be multiple channels, but then it is not limited to "a few", and, >> of course, >> there is nothing stopping the receivers from sending on their own >> channel. >> >> I would change this sentence to >> >> In the multicast routing approach called Source-Specific Multicast >> (SSM), there is only >> one sender per "channel" (source - group pair), and receivers cannot >> use multicast >> to communicate directly with other channel members. > > I think this sentence is a good replacement. It might be more clear to > write "source address, group address pair" in I agree > place of "source - group pair" and replace "other channel members" with > "members of a channel having a source address other than its own." This does not sound too clear, and is not quite correct - a receiver can have more than IP address - How about In the multicast routing approach called Source-Specific Multicast (SSM), there is only one sender per "channel" (a source address, group address pair), and receivers (except for the channel source) cannot use multicast to communicate directly with other channel members. Marshall > > Mark > > >>> senders send multicast data, and receivers may not send >>> multicast. The recommendations here accommodate SSM only >>> through Section 6.2's option of turning off receivers' RTCP >>> entirely. Future work will specify adaptation of RTCP for >>> SSM so that feedback from receivers can be maintained. >>> >>> -- Steve >>> >>> _______________________________________________ >>> Audio/Video Transport Working Group >>> avt@ietf.org >>> https://www1.ietf.org/mailman/listinfo/avt >> Regards >> Marshall Eubanks >> >> T.M. Eubanks >> Multicast Technologies, Inc. >> 10301 Democracy Lane, Suite 410 >> Fairfax, Virginia 22030 >> Phone : 703-293-9624 Fax : 703-293-9609 >> e-mail : tme@multicasttech.com >> http://www.multicasttech.com >> >> Test your network for multicast : >> http://www.multicasttech.com/mt/ >> Status of Multicast on the Web : >> http://www.multicasttech.com/status/index.html >> >> _______________________________________________ >> Audio/Video Transport Working Group >> avt@ietf.org >> https://www1.ietf.org/mailman/listinfo/avt > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > Regards Marshall Eubanks This e-mail may contain confidential and proprietary information of Multicast Technologies, Inc, subject to Non-Disclosure Agreements T.M. Eubanks Multicast Technologies, Inc 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@multicasttech.com http://www.multicasttech.com Test your network for multicast : http://www.multicasttech.com/mt/ Status of Multicast on the Web : http://www.multicasttech.com/status/index.html --Apple-Mail-3--675987855 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit Dear Mark; On Wednesday, January 8, 2003, at 12:22 PM, Mark Baugher wrote: At 06:10 AM 1/8/2003 -0500, Marshall Eubanks wrote: Dear Stephen; On Tuesday, January 7, 2003, at 06:20 PM, Stephen Casner wrote: One of the IESG comments (this one from Harald Alvestrand) was a request to add the following "non-normative note" at the end of Section 6 where RTCP is introduced (i.e., just before 6.1). Does anyone object? Non-normative note: In the multicast routing approach called Source-Specific Multicast (SSM), only one or a few I do not like "a few" here. There is one sender per channel. True, there can be multiple channels, but then it is not limited to "a few", and, of course, there is nothing stopping the receivers from sending on their own channel. I would change this sentence to In the multicast routing approach called Source-Specific Multicast (SSM), there is only one sender per "channel" (source - group pair), and receivers cannot use multicast to communicate directly with other channel members. I think this sentence is a good replacement. It might be more clear to write "source address, group address pair" in I agree place of "source - group pair" and replace "other channel members" with "members of a channel having a source address other than its own." This does not sound too clear, and is not quite correct - a receiver can have more than IP address - How about 0000,6363,1212In the multicast routing approach called Source-Specific Multicast (SSM), there is only one sender per "channel" (a 0000,0000,DEDEsource address, group address0000,6363,1212 pair), and receivers (except for the channel source) cannot use multicast to communicate directly with other channel members. Marshall Mark senders send multicast data, and receivers may not send multicast. The recommendations here accommodate SSM only through Section 6.2's option of turning off receivers' RTCP entirely. Future work will specify adaptation of RTCP for SSM so that feedback from receivers can be maintained. -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt Regards Marshall Eubanks T.M. Eubanks Multicast Technologies, Inc. 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@multicasttech.com http://www.multicasttech.com Test your network for multicast : http://www.multicasttech.com/mt/ Status of Multicast on the Web : http://www.multicasttech.com/status/index.html _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt Times New Roman Regards Marshall Eubanks This e-mail may contain confidential and proprietary information of Multicast Technologies, Inc, subject to Non-Disclosure Agreements T.M. Eubanks Multicast Technologies, Inc 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@multicasttech.com http://www.multicasttech.com Test your network for multicast : http://www.multicasttech.com/mt/ Status of Multicast on the Web : http://www.multicasttech.com/status/index.html --Apple-Mail-3--675987855-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Jan 8 15:16:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05626 for ; Wed, 8 Jan 2003 15:16:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08KSGJ19072 for avt-archive@odin.ietf.org; Wed, 8 Jan 2003 15:28:16 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08KMgJ18888; Wed, 8 Jan 2003 15:22:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08KJpJ18691 for ; Wed, 8 Jan 2003 15:19:51 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05144 for ; Wed, 8 Jan 2003 15:07:58 -0500 (EST) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h08KBFFp003186 for ; Wed, 8 Jan 2003 12:11:15 -0800 (PST) Received: from [10.32.254.182] (stealth-10-32-254-182.cisco.com [10.32.254.182]) by mira-sjc5-9.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with SMTP id HSJ00282; Wed, 8 Jan 2003 12:11:46 -0800 (PST) Date: Wed, 08 Jan 2003 15:11:02 -0500 From: "David R. Oran" To: AVT WG Subject: Re: [AVT] Profile: Silence suppression is allowed by default Message-ID: <177714620.1042038662@[10.32.254.182]> In-Reply-To: <20030107163847.E73937-100000@ash.packetdesign.com> References: <20030107163847.E73937-100000@ash.packetdesign.com> X-Mailer: Mulberry/3.0.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Works for me. Good clarification. --On Tuesday, January 07, 2003 4:51 PM -0800 Stephen Casner wrote: > Over the past year we have had a few discussions on the AVT list > regarding silence suppression and comfort noise for various payload > formats. Sharma Kanchinadham and Anoop Tripathi asked (separately) > for the optional MIME parameters for G723 and G729 audio to be changed > such that the default for "allow comfort noise frames" was NO. Sharma > also asked for a similar parameter to be added for PCMU to indicate > whether silence suppression was allowed, and for the default to be NO. > > I explained that we could not make these changes because silence > suppression has always been an assumed capability for all of the audio > encodings. It's one of the fundamental reasons for using packets to > carry voice in the first place. Changing the default now would create > a backwards incompatibility. Furthermore, a receiver must always be > prepared to recover gracefully when it receives no data because > packets may be lost. > > To make this more explicit, I added the following paragraphs at the > beginning of Section 4.1 in the A/V profile: > > Since the ability to suppress silence is one of the primary > motivations for using packets to transmit voice, the RTP header > carries both a sequence number and a timestamp to allow a receiver to > distinguish between lost packets and periods of time when no data was > transmitted. Discontiguous transmission (silence suppression) MAY be > used with any audio payload format. Receivers MUST accept silence > suppression unless its use is restricted by signaling specified > elsewhere. (Even if the transmitter does not suppress silence, the > receiver must be prepared to handle periods when no data is present > since packets may be lost.) > > Some payload formats define a "silence insertion descriptor" or > "comfort noise" frame to specify parameters for artificial noise that > may be generated during a period of silence to approximate the > background noise at the source. For other payload formats, a generic > Comfort Noise (CN) payload format is specified in RFC 3389 [9]. When > the CN payload format is used with another payload format, different > values in the RTP payload type field distinguish comfort-noise > packets from those of the selected payload format. > > In addition, I added the following first sentence in the four places > where the sentences similar to the second one appear in G723 and G729*: > > Receivers MUST accept comfort noise frames if restriction of their > use has not been signaled. The MIME registration for G729 in > RFC YYYY [7] specifies a parameter that MAY be used with MIME or SDP > to restrict the use of comfort noise frames. > > Are these acceptable? > > -- Steve > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt ------------------------ David R. Oran Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 Office: +1 978 264 2048 VoIP: +1 408 571 4576 Email: oran@cisco.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Jan 8 17:14:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09737 for ; Wed, 8 Jan 2003 17:14:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08MPuN27247 for avt-archive@odin.ietf.org; Wed, 8 Jan 2003 17:25:56 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08MJmJ26977; Wed, 8 Jan 2003 17:19:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08MIoJ26933 for ; Wed, 8 Jan 2003 17:18:50 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09554 for ; Wed, 8 Jan 2003 17:06:56 -0500 (EST) Received: from cscoamera13263.cisco.com (sjc-vpn1-270.cisco.com [10.21.97.14]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id h08M9bjT013027; Wed, 8 Jan 2003 14:09:37 -0800 (PST) Message-Id: <5.1.1.5.2.20030108140851.021d84a0@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 08 Jan 2003 14:10:10 -0800 To: Stephen Casner From: Mark Baugher Subject: Re: [AVT] RTP: Confidentiality mechanisms Cc: AVT WG In-Reply-To: <20030107162229.J73937-100000@ash.packetdesign.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Steve Has any thought been given to dropping the confidentiality specification altogether? Are there real implementations using it? Mark At 04:33 PM 1/7/2003 -0800, Stephen Casner wrote: >In Section 9.1 of the RTP spec on Confidentiality, I added "redrawn >for each unit" to clarify that RTCP packets can't use just one random >number for all packets. In addition, I've added two statements >requested by the IESG. > > -- Steve > >OLD: > For RTCP, a 32-bit random number MUST be > prepended to the unit before encryption to deter known plaintext > attacks. For RTP, no prefix is required because the sequence number > and timestamp fields are initialized with random offsets. > >NEW: > For RTCP, a 32-bit random number redrawn for > each unit MUST be prepended to the unit before encryption to deter > known plaintext attacks. For RTP, no prefix is required because the > sequence number and timestamp fields are initialized with random > offsets. This is considered to be a weak initialization vector (IV), > because of poor randomness properties. In addition, if the > subsequent field, the SSRC, can be manipulated by an enemy, there is > further weakness of the encryption method. > > > >OLD: > Other encryption algorithms MAY be > specified dynamically for a session by non-RTP means. It is > RECOMMENDED that stronger encryption algorithms such as Triple-DES be > used in place of the default algorithm. >NEW ADDITION: > In particular, an AES > profile taking into account known plaintext and CBC plaintext > manipulation concerns will be the correct choice in future. > >_______________________________________________ >Audio/Video Transport Working Group >avt@ietf.org >https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Jan 8 17:16:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09797 for ; Wed, 8 Jan 2003 17:16:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08MSKG27368 for avt-archive@odin.ietf.org; Wed, 8 Jan 2003 17:28:20 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08MN3J27119; Wed, 8 Jan 2003 17:23:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08MMTJ27103 for ; Wed, 8 Jan 2003 17:22:29 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09636 for ; Wed, 8 Jan 2003 17:10:34 -0500 (EST) Received: from cscoamera13263.cisco.com (sjc-vpn1-270.cisco.com [10.21.97.14]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id h08MDGjT017438; Wed, 8 Jan 2003 14:13:16 -0800 (PST) Message-Id: <5.1.1.5.2.20030108141243.021d2dc8@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 08 Jan 2003 14:13:46 -0800 To: Marshall Eubanks From: Mark Baugher Subject: Re: [AVT] RTP: Note regarding SSM Cc: AVT WG In-Reply-To: <1EB2DEFC-2343-11D7-BB72-0030656561EA@multicasttech.com> References: <5.1.1.5.2.20030108090228.02200a08@mira-sjc5-6.cisco.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_64913811==.ALT" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --=====================_64913811==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed hi Marshall At 02:55 PM 1/8/2003 -0500, Marshall Eubanks wrote: <...> >How about > >In the multicast routing approach called Source-Specific Multicast (SSM), >there is only >one sender per "channel" (a source address, group address pair), and >receivers >(except for the channel source) cannot use multicast >to communicate directly with other channel members. This sounds fine to me. Mark >Marshall > > >>Mark >> >> >>> >>>>senders send multicast data, and receivers may not send >>>> multicast. The recommendations here accommodate SSM only >>>> through Section 6.2's option of turning off receivers' RTCP >>>> entirely. Future work will specify adaptation of RTCP for >>>> SSM so that feedback from receivers can be maintained. >>>> >>>> -- Steve >>>> >>>>_______________________________________________ >>>>Audio/Video Transport Working Group >>>>avt@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/avt >>>> >>> Regards >>> Marshall Eubanks >>> >>>T.M. Eubanks >>>Multicast Technologies, Inc. >>>10301 Democracy Lane, Suite 410 >>>Fairfax, Virginia 22030 >>>Phone : 703-293-9624 Fax : 703-293-9609 >>>e-mail : tme@multicasttech.com >>>http://www.multicasttech.com >>> >>>Test your network for multicast : >>>http://www.multicasttech.com/mt/ >>>Status of Multicast on the Web : >>>http://www.multicasttech.com/status/index.html >>> >>> >>>_______________________________________________ >>>Audio/Video Transport Working Group >>>avt@ietf.org >>>https://www1.ietf.org/mailman/listinfo/avt >>> >> >>_______________________________________________ >>Audio/Video Transport Working Group >>avt@ietf.org >>https://www1.ietf.org/mailman/listinfo/avt >> > Regards > Marshall Eubanks > >This e-mail may contain confidential and proprietary information of >Multicast Technologies, Inc, subject to Non-Disclosure Agreements > > >T.M. Eubanks >Multicast Technologies, Inc >10301 Democracy Lane, Suite 410 >Fairfax, Virginia 22030 >Phone : 703-293-9624 Fax : 703-293-9609 >e-mail : tme@multicasttech.com >http://www.multicasttech.com > >Test your network for multicast : >http://www.multicasttech.com/mt/ >Status of Multicast on the Web : >http://www.multicasttech.com/status/index.html > --=====================_64913811==.ALT Content-Type: text/html; charset="us-ascii" hi Marshall

At 02:55 PM 1/8/2003 -0500, Marshall Eubanks wrote:
<...>
How about

In the multicast routing approach called Source-Specific Multicast (SSM), there is only
one sender per "channel" (a source address, group address pair), and receivers
(except for the channel source) cannot use multicast
to communicate directly with other channel members.

This sounds fine to me.

Mark


Marshall


Mark


       
senders send multicast data, and receivers may not send
        multicast.  The recommendations here accommodate SSM only
        through Section 6.2's option of turning off receivers' RTCP
        entirely.  Future work will specify adaptation of RTCP for
        SSM so that feedback from receivers can be maintained.

                                                        -- Steve

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt
                                 Regards
                                 Marshall Eubanks

T.M. Eubanks
Multicast Technologies, Inc.
10301 Democracy Lane, Suite 410
Fairfax, Virginia 22030
Phone : 703-293-9624       Fax     : 703-293-9609
e-mail : tme@multicasttech.com
http://www.multicasttech.com

Test your network for multicast :
http://www.multicasttech.com/mt/
Status of Multicast on the Web  :
http://www.multicasttech.com/status/index.html

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt
                                Regards
                                 Marshall Eubanks

This e-mail may contain confidential and proprietary information of
Multicast Technologies, Inc, subject to Non-Disclosure Agreements


T.M. Eubanks
Multicast Technologies, Inc
10301 Democracy Lane, Suite 410
Fairfax, Virginia 22030
Phone : 703-293-9624       Fax     : 703-293-9609
e-mail : tme@multicasttech.com
http://www.multicasttech.com

Test your network for multicast :
http://www.multicasttech.com/mt/
Status of Multicast on the Web  :
http://www.multicasttech.com/status/index.html </blockquote></x-html>
--=====================_64913811==.ALT-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Jan 8 17:48:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11311 for ; Wed, 8 Jan 2003 17:48:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08MxjN29438 for avt-archive@odin.ietf.org; Wed, 8 Jan 2003 17:59:45 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08MsPJ29177; Wed, 8 Jan 2003 17:54:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08MqGJ29054 for ; Wed, 8 Jan 2003 17:52:16 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10763 for ; Wed, 8 Jan 2003 17:40:22 -0500 (EST) Received: from dynamicsoft.com ([63.113.47.242]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h08MhcYH027369; Wed, 8 Jan 2003 17:43:39 -0500 (EST) Message-ID: <3E1CA992.1050300@dynamicsoft.com> Date: Wed, 08 Jan 2003 17:43:30 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Colin Perkins CC: Stephen Casner , AVT WG Subject: Re: [AVT] Profile: Silence suppression is allowed by default References: <200301081441.h08Ef69F031015@purple.nge.isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit inline. Colin Perkins wrote: > --> Jonathan Rosenberg writes: >>I would propose the last two sentences be replaced with: >> >>Receivers MUST be prepared to handle the absence of packets for an >>arbitrary period of time in order to accomodate silence suppression at >>the sender. This applies even if silence suppression is not in use >>(which can be known to the receiver through signaling, outside the scope >>of this specification), because packet loss cannot be distinguished from >>silence suppression. > > > This is not accurate either, since you can distinguish loss from silence > suppression using the sequence number. Not until the point at which you get that next packet. But at that point, yes, you are correct. We could change the last few words > to "because packet loss may cause arbitrary gaps in reception", or similar? How about, "because packet loss may cause arbitrary gaps in reception which cannot be distinguished from silence suppression until the arrival of the next packet." -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Jan 8 17:50:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11477 for ; Wed, 8 Jan 2003 17:50:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08N2If29570 for avt-archive@odin.ietf.org; Wed, 8 Jan 2003 18:02:18 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08Mv4J29330; Wed, 8 Jan 2003 17:57:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08Mu5J29295 for ; Wed, 8 Jan 2003 17:56:05 -0500 Received: from chiron.nge.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11003 for ; Wed, 8 Jan 2003 17:44:09 -0500 (EST) Received: from chiron (csp@localhost) by chiron.nge.isi.edu (8.11.6/8.11.6) with ESMTP id h08MlNJ27608; Wed, 8 Jan 2003 17:47:23 -0500 Message-Id: <200301082247.h08MlNJ27608@chiron.nge.isi.edu> To: Jonathan Rosenberg cc: Stephen Casner , AVT WG Subject: Re: [AVT] Profile: Silence suppression is allowed by default In-Reply-To: Your message of "Wed, 08 Jan 2003 17:43:30 EST." <3E1CA992.1050300@dynamicsoft.com> Date: Wed, 08 Jan 2003 17:47:22 -0500 From: Colin Perkins Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --> Jonathan Rosenberg writes: >inline. > >Colin Perkins wrote: >> --> Jonathan Rosenberg writes: > >>>I would propose the last two sentences be replaced with: >>> >>>Receivers MUST be prepared to handle the absence of packets for an >>>arbitrary period of time in order to accomodate silence suppression at >>>the sender. This applies even if silence suppression is not in use >>>(which can be known to the receiver through signaling, outside the scope >>>of this specification), because packet loss cannot be distinguished from >>>silence suppression. >> >> >> This is not accurate either, since you can distinguish loss from silence >> suppression using the sequence number. > >Not until the point at which you get that next packet. But at that >point, yes, you are correct. > >We could change the last few words >> to "because packet loss may cause arbitrary gaps in reception", or similar? > >How about, "because packet loss may cause arbitrary gaps in reception >which cannot be distinguished from silence suppression until the arrival >of the next packet." Works for me. Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Jan 8 19:35:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15281 for ; Wed, 8 Jan 2003 19:35:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h090kT702987 for avt-archive@odin.ietf.org; Wed, 8 Jan 2003 19:46:29 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h090dJJ02713; Wed, 8 Jan 2003 19:39:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h090bcJ02599 for ; Wed, 8 Jan 2003 19:37:38 -0500 Received: from mail4.nec.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14759 for ; Wed, 8 Jan 2003 19:25:40 -0500 (EST) Received: from netkeeper.sj.nec.com (netkeeper.sj.nec.com [131.241.31.2]) by mail4.nec.com (/) with ESMTP id h090Srv22115; Wed, 8 Jan 2003 16:28:53 -0800 (PST) Received: from renoir.ccrl.sj.nec.com (localhost [127.0.0.1]) by netkeeper.sj.nec.com (8.9.1a/8.9.1) with ESMTP id QAA05013; Wed, 8 Jan 2003 16:28:48 -0800 (PST) Received: from localhost (alfa.ccrl.sj.nec.com [131.241.79.205]) by renoir.ccrl.sj.nec.com (8.9.3+Sun/8.9.3) with ESMTP id QAA05645; Wed, 8 Jan 2003 16:28:48 -0800 (PST) Date: Wed, 08 Jan 2003 16:28:48 -0800 (PST) Message-Id: <20030108.162848.112624410.hino@ccrl.sj.nec.com> To: casner@acm.org Cc: avt@ietf.org Subject: Re: [AVT] Final edits to RTP spec and A/V profile From: Koji Hino In-Reply-To: <20030107124926.M73937-100000@ash.packetdesign.com> References: <20030107124926.M73937-100000@ash.packetdesign.com> Organization: Silicon Valley Office, NEC Laboratories America, Inc. X-Mailer: Mew version 3.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit From: Stephen Casner Date: Tue, 7 Jan 2003 13:05:36 -0800 (PST) :> New: :> The multiple RTP sessions are distinguished by :> different port number pairs and/or different multicast :> addresses. When I read this first time, I feel some ambiguousness about 'and/or'. Just after that, I think it is obvious that in multicast case, two sessions with different multicast address and same port number should be distinguished, because of existence of 'or'. Is this correct? If so, I think it is better to separate the sentence to point-to-point case and multicast case, for smooth understanding. Ex. For point-to-point unicast case, the multiple RTP sessions are distinguished by different port number pairs. For multicast case, the multiple RTP sessions are distinguished by different port number pairs or different multicast addresses, or both of them. Just my thought... Koji Best regards, ==================================================================== Koji HINO(HINO is my family name) NEC Laboratories America, Inc. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Jan 8 20:07:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16247 for ; Wed, 8 Jan 2003 20:07:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h091Iv104619 for avt-archive@odin.ietf.org; Wed, 8 Jan 2003 20:18:57 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h091D7J04466; Wed, 8 Jan 2003 20:13:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h091CmJ04413 for ; Wed, 8 Jan 2003 20:12:48 -0500 Received: from mailman.packetdesign.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16123 for ; Wed, 8 Jan 2003 20:00:49 -0500 (EST) Received: from ash.packetdesign.com (ash.packetdesign.com [192.168.0.243]) by mailman.packetdesign.com (8.12.3/8.12.3) with ESMTP id h0913gkB087500; Wed, 8 Jan 2003 17:03:42 -0800 (PST) (envelope-from casner@acm.org) Date: Wed, 8 Jan 2003 17:03:42 -0800 (PST) From: Stephen Casner To: Jonathan Rosenberg cc: AVT WG Subject: Re: [AVT] Final edits to RTP spec and A/V profile In-Reply-To: <3E1BAF20.8020709@dynamicsoft.com> Message-ID: <20030108111315.V76233-100000@ash.packetdesign.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Jonathan (and everyone), As I said in my intro, these definitions are tricky to get exactly right. Your comments confirm that. One problem I recognize now is that some people read this text thinking about "participant" from the receiver perspective, and others from the sender perspective: how many ports do I receive on in one session, vs. how many ports do I send to in one session. We realized a long time ago that these two different viewpoints was a fundamental problem in SDP descriptions of unicast sessions. On multiple occasions, the question has been asked: how many RTP sessions are there in a conference of more than two participants implemented with with unicast "connections". But we've never really discussed this question in detail in the WG (that I recall, anyway). Maybe that is because we (at least some of us) were pushing hard to make IP multicast work. Anyway, here's how I view it: - The key determining factor is that SSRC identifiers must be unique within an RTP session. - The parameters that define an RTP session must be such that a receiver can tell to which session an incoming packet belongs, so it knows in which space to look up the SSRC identifier. The source IP address and port are _not_ candidate parameters because they may be modified by intermediate devices. (We included the SSRC in the RTP header to keep RTP independent of lower-level addressing even before NAT occurred.) So, one could implement a full-mesh unicast conference where a receiver uses the same local (destination) port number to receive packets from all the other participants. This is what I meant by "multi-unicast to shared destination transport addresses". In response to Mike Taylor's original message, John Lazzaro described how sfront does this for MIDI, but also cautioned about problems with this design. In this design, the receiver depends upon the SSRC to distinguish the other participants, just as it would in a conference implemented with IP multicast. Therefore, there is only one SSRC space and only one RTP session. Alternatively, one could implement the conference such that each receiver uses N-1 different ports to receive from the other participants. Since the destination port number distinguishes each sender, this implementation could be defined as N(N-1)/2 RTP sessions each with a distinct SSRC spaces. Each pair would be treated as a point-to-point call, and RTCP would carry a reception report for traffic from the other end. HOWEVER, if we want to use reception reports to diagnose distribution problems in the same way that we imagined for IP multicast, then each participant would send reception reports about all N-1 other participants to each of them, and the RTCP interval would be calculated based on N participants. Clearly then the SSRC space is shared, so it has to be one RTP session. It seems like this mode should be allowed, but it conflicts with both the old and new definitions of an RTP session being defined by a particular pair of destination transport addresses. Also, I imagine that only a subset of these modes may have been considered in SIP. Should the definition of "RTP session" be further modified so that it covers this multi-unicast-with-separate-ports mode? Or is that mode "wrong" in some way? It doesn't seem wrong to me. On the other hand, at the RTP level, we can't tell the application anything about how it should know that the N-1 peers should be associated into one session. I have some specific responses to your points inline. > > New: > > RTP session: An association among a set of participants > > communicating with RTP. A participant may be involved in > > multiple RTP sessions at the same time. A single RTP > > session is defined by a particular pair of destination > > transport addresses (one network address plus a port pair > > for RTP and RTCP). > > This definition differs fundamentally from the old. It says that a > session is unique to a particular destination address. Previously, each > participant in a session could potentially have the same destination > address (multicast) or different ones. Now, different ones would imply > different sessions. That was not my intent. I removed the initial phrase "For each participant" because that seemed to be contributing to the ambiguity for Mike Taylor, but that may have been a mistake. Of course, now in my intro above, I am questioning this sentence even futher. > I will note that this new definition is more > consistent with my understanding, but it isn't entirely consistent with > text that follows: > > > The destination transport address pair > > may be common for all participants in the session, as in > > the case of IP multicast, or may be different for each, as > > in the case of individual unicast network addresses and > > port pairs. > > This directly contradicts the previous sentence. No, I meant for the two sentences to work together. This one generalizes the first in that the particular pair of addresses may be different for each participant. But you are right that this needs to be written better. Also, this sentence can mean two different things: - Sender perspective: To each of the participants in a multi-unicast session, I send to a different port number. - Receiver perspective: From each of the other participants in a multi-unicast session, I receive on a different port number. Maybe this sentence only works when N = 2. > > In a multimedia session, each medium is > > carried in a separate RTP session with its own RTCP > > packets. The multiple RTP sessions are distinguished by > > different port number pairs and/or different multicast > > addresses. Each RTP session defines a distinct space of > > SSRC identifiers (defined next) because the session is > > received by a participant on a distinct pair of destination > > transport addresses (RTP and RTCP). One RTP session > > includes the set of participants that can receive an SSRC > > identifier transmitted by one of the participants either in > > RTP (SSRC or CSRC) or RTCP. > > This is consistent with the one destination IP/port = one session view. The last of the sentences in this group was my attempt to capture the notion that the key determining factor is that SSRC identifiers must be unique within an RTP session. It might not be clear enough. > > That may be only two > > participants in a point-to-point unicast RTP session, > > But this, to me, contradicts the above statement. In a point-to-point > case, only one user receives the media that is transmitted. By the above > definition, this RTP session therefore includes this one participant. No, the SSRC is also sent back in an RR so the sender receives its own SSRC, too. My intention was the union of the N sets considering each of the N participants as the sender of an SSRC. I thought the union was implied in that sentence by the inclusion of SSRCs in RTCP. > > or a > > larger number connected by IP multicast, multi-unicast to > > shared destination transport addresses, or through an RTP > > mixer or translator. (Definitions of CSRC, mixer and > > translator follow.) > > Is multi-unicast ever defined elsewhere? I don't think so. No, that term does not appear anywhere else in the document. > Anyway, I do > not understand what "multi-unicast to shared destination transport > addresses" means. My definition of multi-unicast was a "full-mesh" of > connectivity. If there are N participants, each one would be listening > for RTP traffic on N separate addresses, one for each sender. That > corresponds to a total of N(N-1) RTP sessions based on the > session=destination IP/port definition. Each user using a common > destination address to receive all the media would constitute N RTP > sessions based on this definition. I mentioned both scenarios in my intro. I think it is N(N-1)/2 sessions rather than N(N-1) for the first case and 1 rather than N for the second because the SSRC identifiers get returned in RTCP. Maybe we need to make sure we have a common understanding for the simplest case first: a point-to-point call between two participants is only 1 RTP session because we share RTCP sender and receiver information in the same packet (obviously therefore sent to the same port). That ties the two directions together. Does the definition conflict with that? > However, that configuration is not > what I would expect. You would lose the ability to correlate a media > stream (that is, a sequence of RTP packets with a single SSRC) with the > SIP dialog which set it up, a key capability I believe. This is an important question. SIP is not the only means to establish an RTP session, and we want RTP to be general enough to implement the media communication requirements of a variety of control protocols, but that means we have to define terms and concepts within RTP without depending upon concepts of the control protocols to help us. > This would also > constitute "SSRC multiplexing" (see another message sent by Steve on > this subject) which anyway seemed to still be discouraged. I don't see any of these scenarios as "SSRC multiplexing" because they are only implementations of the IP multicast model when the only tool you have is unicast. The intention is that all of the audio streams received by one participant should be mixed, for example. The kind of "SSRC multiplexing" that I have objected to is when totally independent streams are multiplexed in one session. Some might see that distinction as arbitrary, but the idea is that if you force those streams together this way, you won't be able to separate them somewhere when you figure out later on that you want to do so (e.g., for the reasons in the last bullet of Section 5.2). > So, I am still confused, I'm afraid. Probably even more now. Perhaps it was unwise for me to open this question, but sweeping ambiguity under the rug isn't right, either. -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Jan 8 20:29:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16534 for ; Wed, 8 Jan 2003 20:29:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h091eqU05909 for avt-archive@odin.ietf.org; Wed, 8 Jan 2003 20:40:52 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h091ZAJ05159; Wed, 8 Jan 2003 20:35:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h091YTJ05115 for ; Wed, 8 Jan 2003 20:34:29 -0500 Received: from mailman.packetdesign.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16440 for ; Wed, 8 Jan 2003 20:22:30 -0500 (EST) Received: from ash.packetdesign.com (ash.packetdesign.com [192.168.0.243]) by mailman.packetdesign.com (8.12.3/8.12.3) with ESMTP id h091PEkB021866; Wed, 8 Jan 2003 17:25:14 -0800 (PST) (envelope-from casner@acm.org) Date: Wed, 8 Jan 2003 17:25:14 -0800 (PST) From: Stephen Casner To: Koji Hino cc: avt@ietf.org Subject: Re: [AVT] Final edits to RTP spec and A/V profile In-Reply-To: <20030108.162848.112624410.hino@ccrl.sj.nec.com> Message-ID: <20030108172438.Y76233-100000@ash.packetdesign.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , That's a good suggestion, thanks. -- Steve On Wed, 8 Jan 2003, Koji Hino wrote: > From: Stephen Casner > Date: Tue, 7 Jan 2003 13:05:36 -0800 (PST) > :> New: > > :> The multiple RTP sessions are distinguished by > :> different port number pairs and/or different multicast > :> addresses. > > When I read this first time, I feel some ambiguousness about > 'and/or'. Just after that, I think it is obvious that in multicast > case, two sessions with different multicast address and same port > number should be distinguished, because of existence of 'or'. Is this > correct? > > If so, I think it is better to separate the sentence to point-to-point > case and multicast case, for smooth understanding. Ex. > > For point-to-point unicast case, the multiple RTP sessions are > distinguished by different port number pairs. For multicast case, the > multiple RTP sessions are distinguished by different port number pairs > or different multicast addresses, or both of them. > > Just my thought... > > Koji > > Best regards, > ==================================================================== > Koji HINO(HINO is my family name) > NEC Laboratories America, Inc. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Jan 8 20:55:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16751 for ; Wed, 8 Jan 2003 20:55:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09276806814 for avt-archive@odin.ietf.org; Wed, 8 Jan 2003 21:07:06 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0921bJ06560; Wed, 8 Jan 2003 21:01:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0920YJ06517 for ; Wed, 8 Jan 2003 21:00:34 -0500 Received: from mailman.packetdesign.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16682 for ; Wed, 8 Jan 2003 20:48:34 -0500 (EST) Received: from ash.packetdesign.com (ash.packetdesign.com [192.168.0.243]) by mailman.packetdesign.com (8.12.3/8.12.3) with ESMTP id h091pVkB064822; Wed, 8 Jan 2003 17:51:31 -0800 (PST) (envelope-from casner@acm.org) Date: Wed, 8 Jan 2003 17:51:31 -0800 (PST) From: Stephen Casner To: Jonathan Rosenberg cc: AVT WG Subject: Re: [AVT] RTP: explanation of "sampling instant" In-Reply-To: <3E1BA9E0.5060104@dynamicsoft.com> Message-ID: <20030108172801.W76233-100000@ash.packetdesign.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , On Tue, 7 Jan 2003, Jonathan Rosenberg wrote: > It took me three reads to parse this. I would propose a comma: > > The sampling instance is chosen as the point of reference for the RTP > timestamp because it is known to the transmitting endpoint and has a > common definition for all media, independent of encoding delays or other > processing Yes, that is better. How about this: The sampling instance is chosen as the point of reference for the RTP timestamp because it is known to the transmitting endpoint and because it has a common definition for all media, independent of encoding delays or other processing. > > The purpose is to allow synchronized presentation of all > > media sampled at the same time. Comparing RTP timestamps > > from different media is not effective because they have > > independent random offsets and may advance at different > > rates. > > Aren't these two sentences contradictory? The first says its for > synchronized presentation, and the second says it can't be used for that > because they have random offsets and advance at different rates. Well, what I meant in the first sentence was: The purpose of choosing the sampling instance as the point of reference is to allow synchronized presentation of all media sampled at the same time. I don't think this conflicts with the second sentence, though perhaps there should be a paragraph break between them. > I always thought that the reason we had a separate RTP timestamp and > wallclock timestamp was overhead. Because fine granularity is needed for > each wallclock time, it requires too many bits to send in each RTP > packet. Rather, a timestamp whose granularity is exactly matched to the > media is used, and then correlated to the less efficient wallclock time > in the infrequent RTCP packets. Both overhead and accuracy. Some people were concerned about off-by-one errors if we used a clock that did not tick at the natural rate of the media. There was a long debate about this. > > Instead, for each medium the RTP timestamp is > > related to the sampling instant by pairing it with a > > timestamp from a reference clock (wallclock) that > > represents the time when the data corresponding to the RTP > > timestamp was sampled. The reference clock is shared by > > all media to be synchronized. The timestamp pairs are not > > transmitted in every data packet, but at a lower rate in > > RTCP SR packets as described in Section 6.4. > > > > Applications transmitting stored data rather than data > > sampled in real time typically use a virtual clock to > > determine when the next frame or other unit of each medium > > in the stored data should be presented. > > I think "determine" is the wrong word here. Its the receiver that > determines when to present it. The sender indicates when it should be > presented. So, I would propose: > > Applications transmitting stored data rather than data sampled in real > time typically use a virtual clock to indicate when the next frame (or > other unit of each medium) in the stored data should be presented. What you wrote is true. But what I was after was the notion that the sender uses the virtual clock to determine when to take the next unit of data out of the file and send it. But I was afraid that if I used that phrasing, people would say the RTP timestamp should be the transmit time. It's not, it is the presentation timestamp from the file. The sender is running through the file as if the data would be decoded and presented locally according to the virtual clock, but instead the data is transmitted. Depending on the encoding, the timestamp in the file to which the sender compares the virtual clock may be a presentation timestamp or a decoding timestamp. -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Jan 8 21:46:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17628 for ; Wed, 8 Jan 2003 21:46:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h092vxs10000 for avt-archive@odin.ietf.org; Wed, 8 Jan 2003 21:57:59 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h092vFJ09981; Wed, 8 Jan 2003 21:57:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h092ukJ09948 for ; Wed, 8 Jan 2003 21:56:46 -0500 Received: from mailman.packetdesign.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17609 for ; Wed, 8 Jan 2003 21:44:45 -0500 (EST) Received: from ash.packetdesign.com (ash.packetdesign.com [192.168.0.243]) by mailman.packetdesign.com (8.12.3/8.12.3) with ESMTP id h092lmkB051866; Wed, 8 Jan 2003 18:47:48 -0800 (PST) (envelope-from casner@packetdesign.com) Date: Wed, 8 Jan 2003 18:47:48 -0800 (PST) From: Stephen Casner To: AVT WG Subject: Re: [AVT] RTP: SSRC multiplexing for same medium In-Reply-To: <3E1C56A7.2070608@era.ericsson.se> Message-ID: <20030108180259.G76233-100000@ash.packetdesign.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Answering several messages at once, inline... On Tue, 7 Jan 2003, Jonathan Rosenberg wrote: > I generally support the idea of multiplexing using SSRC. However, I > found the text a bit inadequate for a couple of reasons: > > 1. multiplexing using different SSRC for the same media on the same RTP > session is going to be the default case for multicast sessions, no? The > text makes it sound like such a thing is an exception. Its true for > unicast, but this section seems multicast-centric anyway. This is a good point. There should be a sentence or two about this. > 2. Does this text imply that an RTP receiver MUST be prepared to receive > multiple multiplexed streams on a single session? I expect most > implementations today using unicast are not prepared for that (although > I believe they should be) No, it would be inappropriate to make that a MUST. We do say, in Section 6: RTP application designers SHOULD avoid mechanisms that can only work in unicast mode and will not scale to larger numbers. On Wed, 8 Jan 2003, Even, Roni wrote: > Does it mean that you are saying that it is OK to multiplex RTP from > different sources. For example audio stream from two different sources > coming to the same RTP port. I thought that it is better to let the > transport layer handle the multiplexing in the network. Yes, when those sources are in unrelated sessions. As Jonathan and Colin mentioned, in a many-to-many IP multicast session the different sources do all arrive on one port and are demultiplexed based on SSRC. More below. On Wed, 8 Jan 2003, Even, Roni wrote: > One of the reasons mentioned for supporting it in Yokohama was to solve a > problem of IP stack that do not handle the "select" on multiple ports very > well. Is this a good reason for supporting unicast multiplexing in RTP. I am > not an expert on QoS but will there be a problem with QoS protocols that > will not be able to give different QoS for different users. Indeed, QoS is one of the reasons given in Section 5.2. In Yokohama we talked about SSRC multiplexing in two contexts. One resulted from the discussion of RTP retransmission, and the question was whether we should allow SSRC original data packets and retransmissions of those packets to be multiplexed in one RTP session using different SSRC identifiers. We decided that was OK because both kinds of those packets should get the same treatment in the network and should go to the same destination process. So keeping them together is logical. Also, the FEC (RFC 2733) already suggests an option to use SSRC multiplexing to carry original and FEC packets in one RTP session. The second SSRC multiplexing topic is the one to which Roni refers; it was one I presented as a leftover topic that had been bounced from an earlier meeting. The original form of the request that triggered the discussion was for an even bigger change, namely to make the SSRC id be part of the tuple that distinguishes an RTP session. We can't do that because it precludes the multicast case. But the motivation for the request was, as Roni mentions, to work around inefficient implementations of port demultiplexing in some operating systems. If you use a linear search to match ports to sockets, things really slow down with a lot of ports! Here's a little more explanation of the scenario. In an application with two (or maybe even N) VoIP gateways sending a bunch of streams between/among themselves, each GW could receive all of the streams on one socket if the SSRC identifiers could be coordinated and kept distinct for each stream to allow demultiplexing based on SSRC. Maybe the socket would be unconnected to receive from multiple gateways, or maybe there would be one connected socket per GW peer. Managing the SSRC id space might be tricky in the N-way case, but I'm sure you could define a control protocol to manage it. This scheme will work, and we can't keep anyone from implementing it, but it does not fit right with the notion of how multiplexing should be done in RTP, as Roni mentions. We said it seemed like a better idea to fix the operating systems in question. On Wed, 8 Jan 2003, Magnus Westerlund wrote: > I think we need to get this definition very clear and clarify a couple > of things. So lets make an example of how I have interpreted what's > right and wrong in RTP multiplexing: [snip of Magnus's good explanation of three cases] > It is after all this case above that the extra sentence tries to > address. However it seems evident that there is a lack of a clear > explanation of the first case (A), which is actually the recommended > one. However to explain this in much fewer words than above I don't > think I am capable of. Yes, I need to add something about the multicast case (A). As I said in my first message in this series, getting the wording exactly right is tricky. I should add that doing it concisely is even harder. I'm trying to do this without turning the RTP spec into a book. (Side note to Colin: smiley). -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Jan 8 22:30:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18129 for ; Wed, 8 Jan 2003 22:30:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h093gCR12371 for avt-archive@odin.ietf.org; Wed, 8 Jan 2003 22:42:12 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h093fYJ12349; Wed, 8 Jan 2003 22:41:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h093eZJ12329 for ; Wed, 8 Jan 2003 22:40:35 -0500 Received: from mailman.packetdesign.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18108 for ; Wed, 8 Jan 2003 22:28:33 -0500 (EST) Received: from ash.packetdesign.com (ash.packetdesign.com [192.168.0.243]) by mailman.packetdesign.com (8.12.3/8.12.3) with ESMTP id h093VckB017763; Wed, 8 Jan 2003 19:31:39 -0800 (PST) (envelope-from casner@acm.org) Date: Wed, 8 Jan 2003 19:31:38 -0800 (PST) From: Stephen Casner To: Marshall Eubanks cc: AVT WG Subject: Re: [AVT] RTP: Note regarding SSM In-Reply-To: <1EB2DEFC-2343-11D7-BB72-0030656561EA@multicasttech.com> Message-ID: <20030108193014.E76233-100000@ash.packetdesign.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , On Wed, 8 Jan 2003, Marshall Eubanks wrote: > How about > > In the multicast routing approach called Source-Specific Multicast > (SSM), there is only > one sender per "channel" (a source address, group address pair), and > receivers > (except for the channel source) cannot use multicast > to communicate directly with other channel members. Thanks, I'll use that. Please note that the original wording came from Harald, but I think he would accept this as a replacement. -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Jan 8 23:13:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18949 for ; Wed, 8 Jan 2003 23:13:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h094Omw14312 for avt-archive@odin.ietf.org; Wed, 8 Jan 2003 23:24:48 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h094OEJ14302; Wed, 8 Jan 2003 23:24:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h094NSJ14282 for ; Wed, 8 Jan 2003 23:23:28 -0500 Received: from mailman.packetdesign.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18930 for ; Wed, 8 Jan 2003 23:11:27 -0500 (EST) Received: from ash.packetdesign.com (ash.packetdesign.com [192.168.0.243]) by mailman.packetdesign.com (8.12.3/8.12.3) with ESMTP id h094EUkB080051; Wed, 8 Jan 2003 20:14:30 -0800 (PST) (envelope-from casner@acm.org) Date: Wed, 8 Jan 2003 20:14:30 -0800 (PST) From: Stephen Casner To: AVT WG Message-ID: <20030108200144.K76233-100000@ash.packetdesign.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [AVT] Comment on draft-ietf-avt-smpte292-video-08.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This comment was triggered by an email from Chuck Harrison, which was intern triggerd by one of my questions in the RTP spec/profile series. Please take these comments as arriving under the IESG Last Call. draft-ietf-avt-smpte292-video-08.txt includes the following paragraph in its Section 6: RFC1889 recommends transmission of RTCP packets every 5 seconds or at a reduced minimum in seconds of 360 divided by the session bandwidth in kilobits/second. At 1.485 Gbps the reduced minimum interval computes to 0.2ms or 4028 packets per second. I have three comments on this: - I'm not sure why I did not trip on this before, but RFC 1889 does _not_ recommend transmission of RTCP packets every 5 seconds. It recommends RTCP transmission based on a scalable timer with 50% randomization and a minimum _average_ interval of 5 seconds. It is way too tempting already for implementers to put in a fixed 5-second timer. Let's not reinforce that error. - RFC 1889 does _not_ include the scaling of the minimum interval. That was added in draft-ietf-avt-rtp-new. If smpte292-video gets to RFC first, well... - Maybe it would appropriate to add another sentence saying that 4028 is likely to be excessive for most applications and perhaps suggesting another value. The rate only needs to be fast enough to track clock skew and to provide enough packets during the 23-second octet-count wrap interval to reliably track the wraps. -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Jan 8 23:34:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19308 for ; Wed, 8 Jan 2003 23:34:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h094jcY15523 for avt-archive@odin.ietf.org; Wed, 8 Jan 2003 23:45:38 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h094ikJ15492; Wed, 8 Jan 2003 23:44:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h094hbJ15459 for ; Wed, 8 Jan 2003 23:43:37 -0500 Received: from mailman.packetdesign.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19279 for ; Wed, 8 Jan 2003 23:31:35 -0500 (EST) Received: from ash.packetdesign.com (ash.packetdesign.com [192.168.0.243]) by mailman.packetdesign.com (8.12.3/8.12.3) with ESMTP id h094YdkB010004; Wed, 8 Jan 2003 20:34:40 -0800 (PST) (envelope-from casner@acm.org) Date: Wed, 8 Jan 2003 20:34:39 -0800 (PST) From: Stephen Casner To: Peter Barany cc: AVT WG Subject: RE: [AVT] RTP: IPv6 examples for RTCP SDES CNAME In-Reply-To: <1B54FA3A2709D51195C800508BF9386A080B36AB@zrc2c000.us.nortel.com> Message-ID: <20030108202911.X76233-100000@ash.packetdesign.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , On Wed, 8 Jan 2003, Peter Barany wrote: > Regarding ::10.0.0.1, I believe this is a valid representation of an IPv4 > compatible address. However, let me take another stab at amending the text > below to account for this an additional rules (e.g.., there are 3 forms for > representing IPv6 addresses as text strings). Another way around this would > be to refer to the appropriate IETF IPv6 WG document in order to account for > all of the variations/rules. What do you think? NOTE: RFC 2373 (which is a > Proposed Standard) has been advanced to Draft Standard > (draft-ietf-ipngwg-addr-arch-v3-11.txt), approved for publication on Oct. > 29, 2002 (RFC #?). Peter, Thanks for the expanded text, but I think we don't want to go into that much detail here. Your alternate suggestion is better. I suggest the following: For example, the standard ASCII representation of an IP Version 4 address is "dotted decimal", also known as dotted quad, and for IP Version 6, addresses are textually represented as groups of hexadecimal digits separated by colons (with variations as detailed in RFC 2373). -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Jan 9 02:05:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29461 for ; Thu, 9 Jan 2003 02:05:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h097HHm31041 for avt-archive@odin.ietf.org; Thu, 9 Jan 2003 02:17:17 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h097GfJ30819; Thu, 9 Jan 2003 02:16:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h097CSJ26017 for ; Thu, 9 Jan 2003 02:12:28 -0500 Received: from mailman.packetdesign.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22442 for ; Thu, 9 Jan 2003 02:00:22 -0500 (EST) Received: from packetdesign.com (main-fw-eth1.packetdesign.com [192.168.0.254]) by mailman.packetdesign.com (8.12.3/8.12.3) with ESMTP id h0973OkB096286; Wed, 8 Jan 2003 23:03:25 -0800 (PST) (envelope-from casner@acm.org) Date: Wed, 8 Jan 2003 23:16:32 -0800 (PST) From: Stephen Casner To: Colin Perkins cc: AVT WG Subject: Re: [AVT] RTP: Confidentiality mechanisms In-Reply-To: <200301080211.h082BK9F027395@purple.nge.isi.edu> Message-ID: <20030108230403.D20713-100000@oak.packetdesign.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , On Tue, 7 Jan 2003, Colin Perkins wrote: > Looks reasonable. I suggest a small addition to the second change, to > indicate that stronger security is under development. [snip] > >NEW ADDITION: > > In particular, an AES > > profile taking into account known plaintext and CBC plaintext > > manipulation concerns will be the correct choice in future. > ^ is under development, and These wording I showed was verbatim from the message Allison sent requesting these changes. I'm not sure to what she was referring, but I interpreted "profile" to be in the AES domain, not RTP domain. If that's correct, then I don't think your addition is needed. I'm guessing from your comment that you interpret this as referring to the SRTP profile, but that is really past development, except perhaps for tweaks for IESG approval. If SRTP is indeed what Allison meant as well, then I think we should refer to it by name. -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Jan 9 02:17:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02398 for ; Thu, 9 Jan 2003 02:17:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h097TXc32598 for avt-archive@odin.ietf.org; Thu, 9 Jan 2003 02:29:33 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h097TBJ32545; Thu, 9 Jan 2003 02:29:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h097KjJ31650 for ; Thu, 9 Jan 2003 02:20:45 -0500 Received: from mailman.packetdesign.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02146 for ; Thu, 9 Jan 2003 02:08:39 -0500 (EST) Received: from packetdesign.com (main-fw-eth1.packetdesign.com [192.168.0.254]) by mailman.packetdesign.com (8.12.3/8.12.3) with ESMTP id h097BdkB004198; Wed, 8 Jan 2003 23:11:39 -0800 (PST) (envelope-from casner@acm.org) Date: Wed, 8 Jan 2003 23:24:46 -0800 (PST) From: Stephen Casner To: Mark Baugher cc: AVT WG Subject: Re: [AVT] RTP: Confidentiality mechanisms In-Reply-To: <5.1.1.5.2.20030108140851.021d84a0@mira-sjc5-6.cisco.com> Message-ID: <20030108231811.N20713-100000@oak.packetdesign.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Mark, > Has any thought been given to dropping the confidentiality > specification altogether? Are there real implementations using it? Indeed there are two independent interoperable implementations, or it would have been removed for Draft Standard. I think the description of the existing mechanism is adequately qualified (as in constrainted). -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Jan 9 03:00:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03156 for ; Thu, 9 Jan 2003 03:00:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h098CAX03295 for avt-archive@odin.ietf.org; Thu, 9 Jan 2003 03:12:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h098BEJ03261; Thu, 9 Jan 2003 03:11:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h098A4J03199 for ; Thu, 9 Jan 2003 03:10:04 -0500 Received: from mailman.packetdesign.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03098 for ; Thu, 9 Jan 2003 02:57:56 -0500 (EST) Received: from packetdesign.com (main-fw-eth1.packetdesign.com [192.168.0.254]) by mailman.packetdesign.com (8.12.3/8.12.3) with ESMTP id h0980UkB051035; Thu, 9 Jan 2003 00:00:31 -0800 (PST) (envelope-from casner@packetdesign.com) Date: Thu, 9 Jan 2003 00:13:38 -0800 (PST) From: Stephen Casner To: Henning Schulzrinne , Jonathan Rosenberg cc: AVT WG Subject: Re: [AVT] Profile: Silence suppression is allowed by default In-Reply-To: <3E1BA302.3020803@dynamicsoft.com> Message-ID: <20030108234328.A20713-100000@oak.packetdesign.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Replies two both responses, inline... On Tue, 7 Jan 2003, Henning Schulzrinne wrote: > > Since the ability to suppress silence is one of the primary > > motivations for using packets to transmit voice, the RTP header > > carries both a sequence number and a timestamp to allow a receiver to > > distinguish between lost packets and periods of time when no data was > > transmitted. Discontiguous transmission (silence suppression) MAY be > > used with any audio payload format. Receivers MUST accept silence > > suppression unless its use is restricted by signaling specified > > I'm not sure what 'accept silence suppression' means, precisely. I would > say something more concrete and general, as in You and Jonathan are right that "accept" is not the best word. > MUST deal gracefully with gaps in the timestamp sequence, i.e., periods > for which no audio data is available, due to sender silence suppression > or lost packets. I don't think we can dictate grace, though. > > elsewhere. (Even if the transmitter does not suppress silence, the > > receiver must be prepared to handle periods when no data is present > > since packets may be lost.) > > > > Some payload formats define a "silence insertion descriptor" or > > "comfort noise" frame to specify parameters for artificial noise that > > Do any in the current profile? If not, may add a half-sentence to > prevent hunting... Yes, G.723 and G.729. I'll add the half-sentence. On Tue, 7 Jan 2003, Jonathan Rosenberg wrote: > > Since the ability to suppress silence is one of the primary > > motivations for using packets to transmit voice, the RTP header > > carries both a sequence number and a timestamp to allow a receiver to > > distinguish between lost packets and periods of time when no data was > > transmitted. Discontiguous transmission (silence suppression) MAY be > > used with any audio payload format. Receivers MUST accept silence > > suppression unless its use is restricted by signaling specified > > elsewhere. > > Since silence suppression is just the absence of packets, its not clear > what it means to "accept" it. Right. > > (Even if the transmitter does not suppress silence, the > > receiver must be prepared to handle periods when no data is present > > since packets may be lost.) > > This sentence and the previous appear contradictory to me. The previous > says that you won't need to handle silence suppression if signaling says > its not in use, but this sentence says you need it anyway. Well, I don't see them as contradictory; the second is more of a warning that even if you come up with some signaling to disallow silence suppression, it's not going to do you any good because packets might be lost, so you might as well not bother. And that's why we made the default be that silence suppression is allowed. So there! > I would propose the last two sentences be replaced with: > > Receivers MUST be prepared to handle the absence of packets for an > arbitrary period of time in order to accomodate silence suppression at > the sender. This applies even if silence suppression is not in use > (which can be known to the receiver through signaling, outside the scope > of this specification), because packet loss cannot be distinguished from > silence suppression. Sorry, I don't really like this approach because it conflicts with what I said in the first sentence. Here's how I would like to revise the paragraph: Since the ability to suppress silence is one of the primary motivations for using packets to transmit voice, the RTP header carries both a sequence number and a timestamp to allow a receiver to distinguish between lost packets and periods of time when no data was transmitted. Discontiguous transmission (silence suppression) MAY be used with any audio payload format. Receivers MUST assume that senders may suppress silence unless its use is restricted by signaling specified elsewhere. (Even if the transmitter does not suppress silence, the receiver must be prepared to handle periods when no data is present since packets may be lost.) > > Some payload formats define a "silence insertion descriptor" or > > "comfort noise" frame to specify parameters for artificial noise that > > may be generated during a period of silence to approximate the > > background noise at the source. For other payload formats, a generic > > Comfort Noise (CN) payload format is specified in RFC 3389 [9]. When > > the CN payload format is used with another payload format, different > > values in the RTP payload type field distinguish comfort-noise > > packets from those of the selected payload format. > > I assume [9] is an informative reference, not normative. Yes. You'll be able to tell by its position in the references section. :-) This is the same as for all the other payload format RFCs that are referenced. I address this in the Introduction section: This document also defines a set of encodings and payload formats for audio and video. These payload format descriptions are included here only as a matter of convenience since they are too small to warrant separate documents. Use of these payload formats is NOT REQUIRED to use this profile. Only the binding of some of the payload formats to static payload type numbers in Tables 4 and 5 is normative. Since the profile has been approved, the IESG must have agreed with this assessment. > > In addition, I added the following first sentence in the four places > > where the sentences similar to the second one appear in G723 and G729*: > > > > Receivers MUST accept comfort noise frames if restriction of their > > use has not been signaled. The MIME registration for G729 in > > RFC YYYY [7] specifies a parameter that MAY be used with MIME or SDP > > to restrict the use of comfort noise frames. > > Presumably RFC YYYY [7] will be at proposed. The above text seems to me > to provide a normative reference to that specification. A draft standard > cannot have a normative reference to a proposed standard. Indeed, the reason we put the MIME definitions into the separate RFC was to allow the profile to go to Draft Standard while the MIME definitions were new material at Proposed. The idea is that the use of MIME or SDP is not required (you can use any other method of signaling instead), therefore the reference is not normative. Again, the second sentence is in the document as already approved. -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Jan 9 03:20:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03433 for ; Thu, 9 Jan 2003 03:20:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h098W7L04289 for avt-archive@odin.ietf.org; Thu, 9 Jan 2003 03:32:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h098VZJ04251; Thu, 9 Jan 2003 03:31:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0927CJ06943 for ; Wed, 8 Jan 2003 21:07:12 -0500 Received: from mms1.broadcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16744 for ; Wed, 8 Jan 2003 20:55:12 -0500 (EST) Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom MMS1 SMTP Relay (MMS v5.5.0)); Wed, 08 Jan 2003 17:58:01 -0700 Received: from nt-rmna-exch.ca.broadcom.com ( nt-rmna-exch.ca.broadcom.com [10.136.192.25]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id RAA20408; Wed, 8 Jan 2003 17:58:17 -0800 (PST) Received: by nt-rmna-exch.ca.broadcom.com with Internet Mail Service ( 5.5.2653.19) id ; Wed, 8 Jan 2003 17:58:19 -0800 Message-ID: <725301F4D1E9D411A69F0002A507428E0166D0CF@nt-rmna-exch.ca.broadcom.com> From: "Zhenfu Lin" To: "'schulzrinne@cs.columbia.edu'" , "'scott.petrack@edial.com'" cc: "'avt@ietf.org'" Date: Wed, 8 Jan 2003 17:58:18 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 120208A3866059-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] Question on MFR1 in draft-ietf-avt-rfc2833bis-02.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello editors. I have a couple of quesions regard MFR1. 1) What is the frequency pair for MF R1 S3 in Table 6 of draft-ietf-avt-rfc2833bis-02.txt? (I am guessing that it is frequency pair 700/1700 Hz.) 2) Both KP and KP1 refer to the same frequency pair, namely 1100/1700 Hz. In Table 6, KP is mapped to 138 and KP1 is mapped to 139. So, frequency pair 1100/1700 Hz maps to two codes (138 and 139). - a: Does this mean that one of these codes is used when a RFC 2833 packet is generated? Which one should be used? - b: Does this mean that the receiver is prepared to receive both codes, and map both to the frequency pair 1100/1700 Hz? Thank you. Zhenfu _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Jan 9 04:52:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05601 for ; Thu, 9 Jan 2003 04:52:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09A46m10473 for avt-archive@odin.ietf.org; Thu, 9 Jan 2003 05:04:06 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09A2bJ10394; Thu, 9 Jan 2003 05:02:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09A1gJ10361 for ; Thu, 9 Jan 2003 05:01:42 -0500 Received: from accord-ntsrv3.accord.co.il (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05559 for ; Thu, 9 Jan 2003 04:49:31 -0500 (EST) Received: by ACCORD-NTSRV3 with Internet Mail Service (5.5.2656.59) id ; Thu, 9 Jan 2003 11:52:29 +0200 Message-ID: From: "Even, Roni" To: "'Stephen Casner'" , AVT WG Subject: RE: [AVT] RTP: SSRC multiplexing for same medium Date: Thu, 9 Jan 2003 11:52:28 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Steve, I would like to draw another scenario, There is a mixer in an endpoint or a conferencing bridge that can support more then one mixing session. the mixer receives many input streams, for simplicity let's say that they are all G.711. Two cases. 1. Do you see the mixer receiving all the streams that are to be mixed together in one port. 2. Do you see the mixer using one port to receive all streams that may belong to different mixing sessions. So that this mixer will have only one receive port for audio. Roni Even > -----Original Message----- > From: Stephen Casner [mailto:casner@packetdesign.com] > Sent: Thursday, January 09, 2003 4:48 AM > To: AVT WG > Subject: Re: [AVT] RTP: SSRC multiplexing for same medium > > > Answering several messages at once, inline... > > On Tue, 7 Jan 2003, Jonathan Rosenberg wrote: > > > I generally support the idea of multiplexing using SSRC. However, I > > found the text a bit inadequate for a couple of reasons: > > > > 1. multiplexing using different SSRC for the same media on > the same RTP > > session is going to be the default case for multicast > sessions, no? The > > text makes it sound like such a thing is an exception. Its true for > > unicast, but this section seems multicast-centric anyway. > > This is a good point. There should be a sentence or two about this. > > > 2. Does this text imply that an RTP receiver MUST be > prepared to receive > > multiple multiplexed streams on a single session? I expect most > > implementations today using unicast are not prepared for > that (although > > I believe they should be) > > No, it would be inappropriate to make that a MUST. We do say, in > Section 6: > > RTP application designers SHOULD avoid mechanisms that can only > work in unicast mode and will not scale to larger numbers. > > > On Wed, 8 Jan 2003, Even, Roni wrote: > > > Does it mean that you are saying that it is OK to multiplex RTP from > > different sources. For example audio stream from two > different sources > > coming to the same RTP port. I thought that it is better to let the > > transport layer handle the multiplexing in the network. > > Yes, when those sources are in unrelated sessions. As Jonathan and > Colin mentioned, in a many-to-many IP multicast session the different > sources do all arrive on one port and are demultiplexed based on SSRC. > More below. > > > On Wed, 8 Jan 2003, Even, Roni wrote: > > > One of the reasons mentioned for supporting it in Yokohama > was to solve a > > problem of IP stack that do not handle the "select" on > multiple ports very > > well. Is this a good reason for supporting unicast > multiplexing in RTP. I am > > not an expert on QoS but will there be a problem with QoS > protocols that > > will not be able to give different QoS for different users. > > Indeed, QoS is one of the reasons given in Section 5.2. > > In Yokohama we talked about SSRC multiplexing in two contexts. One > resulted from the discussion of RTP retransmission, and the question > was whether we should allow SSRC original data packets and > retransmissions of those packets to be multiplexed in one RTP session > using different SSRC identifiers. We decided that was OK because both > kinds of those packets should get the same treatment in the network > and should go to the same destination process. So keeping them > together is logical. Also, the FEC (RFC 2733) already suggests an > option to use SSRC multiplexing to carry original and FEC packets in > one RTP session. > > The second SSRC multiplexing topic is the one to which Roni refers; it > was one I presented as a leftover topic that had been bounced from an > earlier meeting. The original form of the request that triggered the > discussion was for an even bigger change, namely to make the SSRC id > be part of the tuple that distinguishes an RTP session. We can't do > that because it precludes the multicast case. But the motivation for > the request was, as Roni mentions, to work around inefficient > implementations of port demultiplexing in some operating systems. If > you use a linear search to match ports to sockets, things really slow > down with a lot of ports! > > Here's a little more explanation of the scenario. In an application > with two (or maybe even N) VoIP gateways sending a bunch of streams > between/among themselves, each GW could receive all of the streams on > one socket if the SSRC identifiers could be coordinated and kept > distinct for each stream to allow demultiplexing based on SSRC. Maybe > the socket would be unconnected to receive from multiple gateways, or > maybe there would be one connected socket per GW peer. Managing the > SSRC id space might be tricky in the N-way case, but I'm sure you > could define a control protocol to manage it. > > This scheme will work, and we can't keep anyone from implementing it, > but it does not fit right with the notion of how multiplexing should > be done in RTP, as Roni mentions. We said it seemed like a better > idea to fix the operating systems in question. > > > On Wed, 8 Jan 2003, Magnus Westerlund wrote: > > > I think we need to get this definition very clear and > clarify a couple > > of things. So lets make an example of how I have interpreted what's > > right and wrong in RTP multiplexing: > > [snip of Magnus's good explanation of three cases] > > > It is after all this case above that the extra sentence tries to > > address. However it seems evident that there is a lack of a clear > > explanation of the first case (A), which is actually the recommended > > one. However to explain this in much fewer words than above I don't > > think I am capable of. > > Yes, I need to add something about the multicast case (A). As I said > in my first message in this series, getting the wording exactly right > is tricky. I should add that doing it concisely is even harder. I'm > trying to do this without turning the RTP spec into a book. > (Side note to Colin: smiley). > > -- Steve > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Jan 9 08:12:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08674 for ; Thu, 9 Jan 2003 08:12:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09DO2e22137 for avt-archive@odin.ietf.org; Thu, 9 Jan 2003 08:24:02 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09DMgJ22094; Thu, 9 Jan 2003 08:22:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09DJRJ21965 for ; Thu, 9 Jan 2003 08:19:27 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08556 for ; Thu, 9 Jan 2003 08:07:14 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h09DATKV028868; Thu, 9 Jan 2003 14:10:29 +0100 (MET) Received: from era.ericsson.se (research-pi6vzu.ki.sw.ericsson.se [147.214.181.170]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZGNLSW5J; Thu, 9 Jan 2003 14:10:29 +0100 Message-ID: <3E1D74C4.1090409@era.ericsson.se> Date: Thu, 09 Jan 2003 14:10:28 +0100 X-Sybari-Trust: 18020194 1864f774 d5511081 00000138 From: =?ISO-8859-1?Q?Mats_N=E4slund?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Casner CC: AVT WG Subject: Re: [AVT] RTP: Confidentiality mechanisms References: <20030107162229.J73937-100000@ash.packetdesign.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi, Stephen Casner wrote: > In Section 9.1 of the RTP spec on Confidentiality, I added "redrawn > for each unit" to clarify that RTCP packets can't use just one random > number for all packets. In addition, I've added two statements > requested by the IESG. > > -- Steve > > OLD: > For RTCP, a 32-bit random number MUST be > prepended to the unit before encryption to deter known plaintext > attacks. For RTP, no prefix is required because the sequence number > and timestamp fields are initialized with random offsets. > > NEW: > For RTCP, a 32-bit random number redrawn for > each unit MUST be prepended to the unit before encryption to deter > known plaintext attacks. For RTP, no prefix is required because the > sequence number and timestamp fields are initialized with random > offsets. This is considered to be a weak initialization vector (IV), > because of poor randomness properties. In addition, if the > subsequent field, the SSRC, can be manipulated by an enemy, there is > further weakness of the encryption method. I have some problem with this wording. I assume we are talking CBC mode(?) I think the text confuses the real issues with using CBC. First: > each unit MUST be prepended to the unit before encryption to deter > known plaintext attacks. This might signal: "It's okay to use a cipher that does not resist known plaintext attacks, as long as a rand is prepended".¨ It is *not* ok to use such a cipher, neither does the prepend fix that problem: the next input block, p2, *might* still be known and the previous cipher text block, c1, is certainly known too, so the input to the 2nd block, c1 XOR p2, will be known anyway. However, the issue with CBC is that the initial IV must be random for existing security arguments to hold. Therefore, I assume that what we really want to say is that in the absence of a truly random IV, we must randomize the first plaintext block. This is indeed indicated in the sequel of the above text, but has nothing to do with known plaintext attacks: even with a random IV, that IV will in typical CBC appl. be known to an attacker anyway, and is not the issue. The only issue is to (sufficiently) "randomize the starting point". Next, > For RTP, no prefix is required because the > sequence number and timestamp fields are initialized with random > offsets. This is (strictly speaking) not true. The existing security arguments for CBC fail if a "counter" type value is used for the IV: even if the first IV is random, following packet IVs may be highly correlated to the first one. This does not mean that there is an "attack" on what you propose (you are probably helped by the fact that the "IV" is never seen by the attacker), I merely claim that it is not clear that it is a "sound" way of doing it. At the very least, the caveats should be pointed out. Best, /Mats _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Jan 9 09:52:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13153 for ; Thu, 9 Jan 2003 09:52:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09F47J28545 for avt-archive@odin.ietf.org; Thu, 9 Jan 2003 10:04:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09F15J28372; Thu, 9 Jan 2003 10:01:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09ExiJ28280 for ; Thu, 9 Jan 2003 09:59:44 -0500 Received: from zsc3s004.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12879 for ; Thu, 9 Jan 2003 09:47:28 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h09EogY16437; Thu, 9 Jan 2003 06:50:43 -0800 (PST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h09Eos716870; Thu, 9 Jan 2003 08:50:54 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Jan 2003 08:50:41 -0600 Message-ID: <1B54FA3A2709D51195C800508BF9386A080B36AF@zrc2c000.us.nortel.com> From: "Peter Barany" To: "'Stephen Casner'" Cc: AVT WG Subject: RE: [AVT] RTP: IPv6 examples for RTCP SDES CNAME Date: Thu, 9 Jan 2003 08:50:37 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2B7EE.78F58150" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2B7EE.78F58150 Content-Type: text/plain; charset="ISO-8859-1" Stephen, I agree. But as I mentioned, RFC 2373 has been replaced/updated by the Draft Standard "draft-ietf-ipngwg-addr-arch-v3-11.txt" (approved for publication on Oct. 29, 2002). Don't know the RFC #. We probably should reference the Draft Standard if possible. Thanks. Regards, Pete -----Original Message----- From: Stephen Casner [mailto:casner@acm.org] Sent: Wednesday, January 08, 2003 10:35 PM To: Barany, Peter [RICH1:2H16:EXCH] Cc: AVT WG Subject: RE: [AVT] RTP: IPv6 examples for RTCP SDES CNAME On Wed, 8 Jan 2003, Peter Barany wrote: > Regarding ::10.0.0.1, I believe this is a valid representation of an IPv4 > compatible address. However, let me take another stab at amending the text > below to account for this an additional rules (e.g.., there are 3 forms for > representing IPv6 addresses as text strings). Another way around this would > be to refer to the appropriate IETF IPv6 WG document in order to account for > all of the variations/rules. What do you think? NOTE: RFC 2373 (which is a > Proposed Standard) has been advanced to Draft Standard > (draft-ietf-ipngwg-addr-arch-v3-11.txt), approved for publication on Oct. > 29, 2002 (RFC #?). Peter, Thanks for the expanded text, but I think we don't want to go into that much detail here. Your alternate suggestion is better. I suggest the following: For example, the standard ASCII representation of an IP Version 4 address is "dotted decimal", also known as dotted quad, and for IP Version 6, addresses are textually represented as groups of hexadecimal digits separated by colons (with variations as detailed in RFC 2373). -- Steve ------_=_NextPart_001_01C2B7EE.78F58150 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [AVT] RTP: IPv6 examples for RTCP SDES CNAME

Stephen,

I agree. But as I mentioned, RFC 2373 has been = replaced/updated by the Draft Standard = "draft-ietf-ipngwg-addr-arch-v3-11.txt" (approved for = publication on Oct. 29, 2002). Don't know the RFC #. We probably should = reference the Draft Standard if possible. Thanks.

Regards,

Pete

-----Original Message-----
From: Stephen Casner [mailto:casner@acm.org]
Sent: Wednesday, January 08, 2003 10:35 PM
To: Barany, Peter [RICH1:2H16:EXCH]
Cc: AVT WG
Subject: RE: [AVT] RTP: IPv6 examples for RTCP SDES = CNAME


On Wed, 8 Jan 2003, Peter Barany wrote:

> Regarding ::10.0.0.1, I believe this is a valid = representation of an IPv4
> compatible address. However, let me take = another stab at amending the text
> below to account for this an additional rules = (e.g.., there are 3 forms for
> representing IPv6 addresses as text strings). = Another way around this would
> be to refer to the appropriate IETF IPv6 WG = document in order to account for
> all of the variations/rules. What do you think? = NOTE: RFC 2373 (which is a
> Proposed Standard) has been advanced to Draft = Standard
> (draft-ietf-ipngwg-addr-arch-v3-11.txt), = approved for publication on Oct.
> 29, 2002 (RFC #?).

Peter,

Thanks for the expanded text, but I think we don't = want to go into
that much detail here.  Your alternate = suggestion is better.  I
suggest the following:

   For example, the standard ASCII = representation of an IP Version 4
   address is "dotted decimal", = also known as dotted quad, and for IP
   Version 6, addresses are textually = represented as groups of
   hexadecimal digits separated by colons = (with variations as detailed
   in RFC 2373).

          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;         -- Steve

------_=_NextPart_001_01C2B7EE.78F58150-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Jan 9 11:07:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16021 for ; Thu, 9 Jan 2003 11:07:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09GJDb02599 for avt-archive@odin.ietf.org; Thu, 9 Jan 2003 11:19:13 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09GGfJ02418; Thu, 9 Jan 2003 11:16:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09GF5J02339 for ; Thu, 9 Jan 2003 11:15:05 -0500 Received: from mailman.packetdesign.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15862 for ; Thu, 9 Jan 2003 11:02:47 -0500 (EST) Received: from packetdesign.com (main-fw-eth1.packetdesign.com [192.168.0.254]) by mailman.packetdesign.com (8.12.3/8.12.3) with ESMTP id h09G5mkB097096; Thu, 9 Jan 2003 08:05:55 -0800 (PST) (envelope-from casner@acm.org) Date: Thu, 9 Jan 2003 08:19:01 -0800 (PST) From: Stephen Casner To: "Even, Roni" cc: AVT WG Subject: RE: [AVT] RTP: SSRC multiplexing for same medium In-Reply-To: Message-ID: <20030109081246.G20858-100000@oak.packetdesign.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Roni, > I would like to draw another scenario, > There is a mixer in an endpoint or a conferencing bridge that can support > more then one mixing session. the mixer receives many input streams, for > simplicity let's say that they are all G.711. > > Two cases. > > 1. Do you see the mixer receiving all the streams that are to be mixed > together in one port. Certainly yes in the case of IP multicast. The first mixers that were implemented received from multiple sources on multicast, mixed and optionally re-encoded at a lower rate, and then transmitted the result over unicast. Those implementations covered only one mixing session in one process, but you could run multiple instances of the process on the same machine using different ports. Multiple sources sending unicast to the same port on the mixer also seems to work in an equivalent way. > 2. Do you see the mixer using one port to receive all streams that may > belong to different mixing sessions. So that this mixer will have only one > receive port for audio. No. This is he kind of multiplexing that we are trying to suppress. You might be able to make it work if you have a way to coordinate SSRC selection among all the participants in all the sessions, but it does not fit the RTP design. -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Jan 9 13:07:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19415 for ; Thu, 9 Jan 2003 13:07:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09IJbw11331 for avt-archive@odin.ietf.org; Thu, 9 Jan 2003 13:19:37 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09IISJ11275; Thu, 9 Jan 2003 13:18:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09IH4J11226 for ; Thu, 9 Jan 2003 13:17:04 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19364 for ; Thu, 9 Jan 2003 13:04:45 -0500 (EST) From: David.Leon@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h09I84E01564 for ; Thu, 9 Jan 2003 12:08:04 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 9 Jan 2003 12:07:57 -0600 Received: from daebe008.NOE.Nokia.com ([172.18.242.238]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 9 Jan 2003 10:07:04 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AVT] Comments on draft-ietf-avt-rtp-retransmission-04.txt Date: Thu, 9 Jan 2003 12:07:04 -0600 Message-ID: <7CA3477F476D7F4FB82F02960B79CEBD017E4F66@daebe008.americas.nokia.com> Thread-Topic: [AVT] Comments on draft-ietf-avt-rtp-retransmission-04.txt Thread-Index: AcKywRo8Vy2aiK1ZQp2I8fHKhj8CuAFOUFEg To: X-OriginalArrivalTime: 09 Jan 2003 18:07:04.0858 (UTC) FILETIME=[EA84BFA0:01C2B809] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h09IH4J11227 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Colin, Thanks for the review. > > I've just read the -04 version of the retransmission draft. > It seems to be > in reasonably good shape, but I do have some questions and comments: > > - At the end of section 3.1, after discussing the choice > between SSRC and > session multiplexing, the draft states "both multiplexing > approaches > SHOULD be supported". Is this intended to be a requirement > for both the > sender and receiver? Yes. We can write this explicitly. > > - In section 4, the draft mentions the possibility that the > retransmission > stream may include packets with multiple clock rates. How > is this to be > signalled in the SDP? The retransmission RTP stream is no different from the original RTP stream in this regard. If multiple payload types are used, each payload type must be declared in the SDP and its clockrate is given by the rtpmap attribute. > > - In section 4, the draft states that and profile-specific > payload header > must be included in the retransmitted packet. Is this sent > before the > OSN payload header or after it? The retransmission payload header should precede the payload of the original packet, including its payload header. This needs to be clarified in the draft. > > - Section 4 is unclear how RTCP for the retransmission > stream is handled. > Is the sender expected to send periodic SDES and SR reports? BYEs? We have been working under the assumption that the retransmission stream MUST follow the same RTCP rules as any other RTP stream. We can of course write this in the draft. My understanding is that a payload format cannot modify the RTCP rules. Only a profile document can specify different rules. Is it so? > > - In section 5.3, the description of how to associate > streams when SSRC > multiplexing is used seems error-prone. Would it not be possible to > signal the mapping explicitly? There could only be an error in the association if two streams use the same CNAME, same payload type and retransmit the same packet number at the same time. The probability is intuitively very low, in particular given that these two streams should have chosen different initial packet sequence numbers. If in addition the receiver follows the draft recommendation of not requesting the same sequence number for these two streams at the same time, the risk of the association to fail seems negligible. The only way I can see how to make the mapping more explicit, would be to add the original stream SSRC in the retransmission payload header. This would make the payload header 6 bytes instead of 2 bytes. I'd rather keep the payload header as it is now. > > - In section 6.1, when the original and retransmission > streams are sent > in the same RTP session, how are the RTCP timing rules > modified? Does > the sender get twice the RTCP bandwidth since it appears > as two SSRCs? Here again, we thought that the RTP retransmission stream had to be treated like any other RTP stream as far as the RTCP timing rules are concerned. This means that we can't specify the fraction of the RTCP bandwidth available for the retransmission stream separatly. The original stream and the retransmission stream are seen as two independent senders that are sharing the RTCP bandwidths allocated to senders in the session as would any other sender do. > > - In section 6.2, a pointer to the RTCP Reporting Extensions > draft may be > appropriate, since that defines a receiver RTT report. > My concern is that this would introduce one more dependency. > - In section 8, note that the correct syntax is > "a=fmtp: ...". Could you please point out which line in Section 8 is incorrect? > > - In section 12, how does this draft affect SRTP? Is it > possible to use > the two formats together? We'll try to draft something on that. My understanding is that the retransmission stream is seen as any other stream by SRTP and there should thus be no problem. > > I also think it would be appropriate if this draft describes > the level of > reliability that can be expected from a session using > retransmission, and > perhaps describes when this is acceptable, and when TCP > should be used? Ok. Thanks. David. > > Regards, > Colin > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Jan 9 17:12:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28092 for ; Thu, 9 Jan 2003 17:12:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09MO0I30662 for avt-archive@odin.ietf.org; Thu, 9 Jan 2003 17:24:00 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09MMuJ30631; Thu, 9 Jan 2003 17:22:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09MLoJ30608 for ; Thu, 9 Jan 2003 17:21:50 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28021 for ; Thu, 9 Jan 2003 17:09:25 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.156]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h09MCRYH028279; Thu, 9 Jan 2003 17:12:28 -0500 (EST) Message-ID: <3E1DF3C7.1020408@dynamicsoft.com> Date: Thu, 09 Jan 2003 17:12:24 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Casner CC: Henning Schulzrinne , AVT WG Subject: Re: [AVT] Profile: Silence suppression is allowed by default References: <20030108234328.A20713-100000@oak.packetdesign.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Stephen Casner wrote: > Sorry, I don't really like this approach because it conflicts with > what I said in the first sentence. Here's how I would like to revise > the paragraph: > > Since the ability to suppress silence is one of the primary > motivations for using packets to transmit voice, the RTP header > carries both a sequence number and a timestamp to allow a receiver > to distinguish between lost packets and periods of time when no data > was transmitted. Discontiguous transmission (silence suppression) > MAY be used with any audio payload format. Receivers MUST assume > that senders may suppress silence unless its use is restricted by > signaling specified elsewhere. (Even if the transmitter does not > suppress silence, the receiver must be prepared to handle periods > when no data is present since packets may be lost.) OK. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Jan 9 20:48:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03448 for ; Thu, 9 Jan 2003 20:48:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0A203t10637 for avt-archive@odin.ietf.org; Thu, 9 Jan 2003 21:00:03 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A1xJJ10561; Thu, 9 Jan 2003 20:59:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A1uMJ10457 for ; Thu, 9 Jan 2003 20:56:22 -0500 Received: from purple.nge.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03398 for ; Thu, 9 Jan 2003 20:43:51 -0500 (EST) Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.6/8.12.6) with ESMTP id h09MgKZC003180; Thu, 9 Jan 2003 17:42:20 -0500 (EST) (envelope-from csp@purple.nge.isi.edu) Message-Id: <200301092242.h09MgKZC003180@purple.nge.isi.edu> To: Stephen Casner cc: AVT WG Subject: Re: [AVT] RTP: Confidentiality mechanisms In-Reply-To: Your message of "Wed, 08 Jan 2003 23:16:32 PST." <20030108230403.D20713-100000@oak.packetdesign.com> Date: Thu, 09 Jan 2003 17:42:20 -0500 From: Colin Perkins Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --> Stephen Casner writes: >On Tue, 7 Jan 2003, Colin Perkins wrote: > >> Looks reasonable. I suggest a small addition to the second change, to >> indicate that stronger security is under development. >[snip] >> >NEW ADDITION: >> > In particular, an AES >> > profile taking into account known plaintext and CBC plaintext >> > manipulation concerns will be the correct choice in future. >> ^ is under development, and > >These wording I showed was verbatim from the message Allison sent >requesting these changes. I'm not sure to what she was referring, but >I interpreted "profile" to be in the AES domain, not RTP domain. If >that's correct, then I don't think your addition is needed. > >I'm guessing from your comment that you interpret this as referring to >the SRTP profile, but that is really past development, except perhaps >for tweaks for IESG approval. If SRTP is indeed what Allison meant as >well, then I think we should refer to it by name. I assumed SRTP was meant, and would be happy for it to be referenced by name (provided it is completed in time). Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Jan 9 20:56:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03575 for ; Thu, 9 Jan 2003 20:56:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0A28d911689 for avt-archive@odin.ietf.org; Thu, 9 Jan 2003 21:08:39 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A284J11635; Thu, 9 Jan 2003 21:08:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A271J11003 for ; Thu, 9 Jan 2003 21:07:01 -0500 Received: from mailman.packetdesign.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03526 for ; Thu, 9 Jan 2003 20:54:33 -0500 (EST) Received: from ash.packetdesign.com (ash.packetdesign.com [192.168.0.243]) by mailman.packetdesign.com (8.12.3/8.12.3) with ESMTP id h0A1viOM040032; Thu, 9 Jan 2003 17:57:44 -0800 (PST) (envelope-from casner@acm.org) Date: Thu, 9 Jan 2003 17:57:44 -0800 (PST) From: Stephen Casner To: Colin Perkins cc: AVT WG Subject: Re: [AVT] RTP: Confidentiality mechanisms In-Reply-To: <200301092242.h09MgKZC003180@purple.nge.isi.edu> Message-ID: <20030109175256.T78079-100000@ash.packetdesign.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Colin, > I assumed SRTP was meant, and would be happy for it to be referenced by > name (provided it is completed in time). What I meant was that we could say something like this: In particular, a profile called "Secure Real-time Transport Protocol" is being developed to take into account known plaintext and CBC plaintext manipulation concerns, and will be the correct choice in the future. I believe this could be published without any dependency concerns. But first, I need to clarify that this is what Allison meant. -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Jan 9 22:39:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06009 for ; Thu, 9 Jan 2003 22:39:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0A3pT016996 for avt-archive@odin.ietf.org; Thu, 9 Jan 2003 22:51:29 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A3ncJ16949; Thu, 9 Jan 2003 22:49:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A3m2J16890 for ; Thu, 9 Jan 2003 22:48:02 -0500 Received: from purple.nge.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05980 for ; Thu, 9 Jan 2003 22:35:30 -0500 (EST) Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.6/8.12.6) with ESMTP id h0A3ckZC009194; Thu, 9 Jan 2003 22:38:46 -0500 (EST) (envelope-from csp@purple.nge.isi.edu) Message-Id: <200301100338.h0A3ckZC009194@purple.nge.isi.edu> To: David.Leon@nokia.com cc: avt@ietf.org Subject: Re: [AVT] Comments on draft-ietf-avt-rtp-retransmission-04.txt In-Reply-To: Your message of "Thu, 09 Jan 2003 12:07:04 CST." <7CA3477F476D7F4FB82F02960B79CEBD017E4F66@daebe008.americas.nokia.com> Date: Thu, 09 Jan 2003 22:38:46 -0500 From: Colin Perkins Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Hi, (inline) --> David.Leon@nokia.com writes: ... >> - Section 4 is unclear how RTCP for the retransmission stream is handled. >> Is the sender expected to send periodic SDES and SR reports? BYEs? > >We have been working under the assumption that the retransmission stream >MUST follow the same RTCP rules as any other RTP stream. We can of course >write this in the draft. My understanding is that a payload format cannot >modify the RTCP rules. Only a profile document can specify different rules. >Is it so? Yes, but the draft gave me the impression something different was intended. A sentence to clarify would be helpful. >> - In section 5.3, the description of how to associate streams when SSRC >> multiplexing is used seems error-prone. Would it not be possible to >> signal the mapping explicitly? > >There could only be an error in the association if two streams use the >same CNAME, same payload type and retransmit the same packet number at the >same time. The probability is intuitively very low, in particular given >that these two streams should have chosen different initial packet sequence >numbers. If in addition the receiver follows the draft recommendation of >not requesting the same sequence number for these two streams at the same >time, the risk of the association to fail seems negligible. > >The only way I can see how to make the mapping more explicit, would be to >add the original stream SSRC in the retransmission payload header. This >would make the payload header 6 bytes instead of 2 bytes. I'd rather keep >the payload header as it is now. Can we not prohibit the situation from occuring? You can always choose to use non-clashing payload types, to avoid the problem? >> - In section 6.1, when the original and retransmission streams are sent >> in the same RTP session, how are the RTCP timing rules modified? Does >> the sender get twice the RTCP bandwidth since it appears as two SSRCs? > >Here again, we thought that the RTP retransmission stream had to be >treated like any other RTP stream as far as the RTCP timing rules are >concerned. This means that we can't specify the fraction of the RTCP >bandwidth available for the retransmission stream separatly. The original >stream and the retransmission stream are seen as two independent senders >that are sharing the RTCP bandwidths allocated to senders in the session as >would any other sender do. Okay, but the draft says "the receiver sends report blocks for the original and the retransmission streams in the same RTCP RR packet". It is not clear that two separate RTP sessions are used. >> - In section 6.2, a pointer to the RTCP Reporting Extensions draft may be >> appropriate, since that defines a receiver RTT report. > >My concern is that this would introduce one more dependency. Doesn't have to be a normative reference... >> - In section 8, note that the correct syntax is >> "a=fmtp: ...". > >Could you please point out which line in Section 8 is incorrect? It says: a=fmtp : rtx-time= but should be: a=fmtp: rtx-time= (i.e. the ":" is in the wrong place) >> - In section 12, how does this draft affect SRTP? Is it possible to use >> the two formats together? > >We'll try to draft something on that. My understanding is that the >retransmission stream is seen as any other stream by SRTP and there should >thus be no problem. I was not clear if retransmitting packets caused problems for SRTP; maybe one of the SRTP authors can comment on any potential security issue? Cheers, Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Jan 9 23:18:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06782 for ; Thu, 9 Jan 2003 23:18:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0A4UFx19074 for avt-archive@odin.ietf.org; Thu, 9 Jan 2003 23:30:15 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A4TFJ19039; Thu, 9 Jan 2003 23:29:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A4T0J19017 for ; Thu, 9 Jan 2003 23:29:00 -0500 Received: from mailman.packetdesign.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06764 for ; Thu, 9 Jan 2003 23:16:28 -0500 (EST) Received: from ash.packetdesign.com (ash.packetdesign.com [192.168.0.243]) by mailman.packetdesign.com (8.12.3/8.12.3) with ESMTP id h0A4JKOM084229; Thu, 9 Jan 2003 20:19:29 -0800 (PST) (envelope-from casner@acm.org) Date: Thu, 9 Jan 2003 20:19:20 -0800 (PST) From: Stephen Casner To: Jonathan Rosenberg cc: AVT WG Subject: Re: [AVT] Final edits to RTP spec and A/V profile In-Reply-To: <20030108111315.V76233-100000@ash.packetdesign.com> Message-ID: <20030109145946.S78079-100000@ash.packetdesign.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Here's another crack at the RTP session definition. The existing definition in RFC 1889 contains the following sentences: For each participant, the session is defined by a particular pair of destination transport addresses (one network address plus a port pair for RTP and RTCP). The multiple RTP sessions are distinguished by different port number pairs and/or different multicast addresses. Considering my discussion in email yesterday of full-mesh multi-unicast conferences, perhaps the first sentence was too restrictive. Perhaps the salient point from these sentences is the following: Different RTP sessions will not have the same destination address and port pair, but a single RTP session may be composed of multiple destination addresses and/or port pairs. My intention in all of the edits I proposed was not to change the meaning of any of the text (or our collective understanding of what the text failed to say), but only to clarify. It is important not to do so since the IESG has approved the drafts in their current state. Well, if something is broken, we should fix it, but then the IESG needs to agree with the fix, and a big change would require cycling at Proposed Standard rather than advancing to Draft Standard. So, would it be an incompatible change to say an RTP session may be composed of multiple addresses/ports? I think if you consider RTP translators and mixers, then you realize that the original definition was already too restrictive. For example, consider an N-party audio conference implemented as an RTP mixer with one unicast connection to each participant. The mixer is also a participant in the teleconference because it has an SSRC of its own that it uses to transmit the mixed audio to the other participants. This conference is all one session: the SSRC identifiers are distributed among all the participants in the CSRC list and therefore must be in one space. Yet, for the mixer, the RTP session is composed of N different ports (the addresses may all be the same or may not, depending on whether the mixer has multiple interfaces). So, how about the following revised definition: RTP session: An association among a set of participants communicating with RTP. A participant may be involved in multiple RTP sessions at the same time. In a multimedia session, each medium is carried in a separate RTP session with its own RTCP packets. The multiple RTP sessions are distinguished by reception of each using a distinct pair of destination transport addresses, where a pair of transport addresses comprises one network address plus a pair of ports for RTP and RTCP. The destination transport address pair may be common for all participants in a session, as in the case of IP multicast, or may be different for each, as in the case of individual unicast network addresses and port pairs. In the unicast case, a participant may receive from all other participants using the same pair of ports, or may use a distinct pair of ports for each. The distinguishing feature of an RTP session is that each defines a distinct space of SSRC identifiers (defined next). The set of participants included in one RTP session consists of those that can receive an SSRC identifier transmitted by any one of the participants either in RTP (either as the SSRC or a CSRC, also defined below) or in RTCP. For example, consider a three-party conference implemented using unicast UDP with each participant receiving from the other two on separate port pairs. If each participant sends RTCP feedback about data received from one other participant only back to that participant, then the conference is composed of three separate point- to-point RTP sessions. If each participant provides RTCP feedback about its reception of one other participant to both of the other particpants, then the conference is composed of one multi-party RTP session. The latter case simulates the behavior that would occur IP multicast communication among the three participants. -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Jan 10 03:23:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20618 for ; Fri, 10 Jan 2003 03:23:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0A8ZQS09529 for avt-archive@odin.ietf.org; Fri, 10 Jan 2003 03:35:26 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A8Z2J09510; Fri, 10 Jan 2003 03:35:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A8XmJ09438 for ; Fri, 10 Jan 2003 03:33:48 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20575 for ; Fri, 10 Jan 2003 03:21:10 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0A8ORAv002714; Fri, 10 Jan 2003 09:24:27 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZQ1FZWHW; Fri, 10 Jan 2003 09:24:27 +0100 Message-ID: <3E1E833B.5060805@era.ericsson.se> Date: Fri, 10 Jan 2003 09:24:27 +0100 X-Sybari-Trust: 1abffecd 1864f774 21c82a8a 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Colin Perkins CC: David.Leon@nokia.com, avt@ietf.org Subject: Re: [AVT] Comments on draft-ietf-avt-rtp-retransmission-04.txt References: <200301100338.h0A3ckZC009194@purple.nge.isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, as usual, see below: Colin Perkins wrote: >--> David.Leon@nokia.com writes: > > >>> - In section 5.3, the description of how to associate streams when SSRC >>> multiplexing is used seems error-prone. Would it not be possible to >>> signal the mapping explicitly? >>> >>> >>There could only be an error in the association if two streams use the >>same CNAME, same payload type and retransmit the same packet number at the >>same time. The probability is intuitively very low, in particular given >>that these two streams should have chosen different initial packet sequence >>numbers. If in addition the receiver follows the draft recommendation of >>not requesting the same sequence number for these two streams at the same >>time, the risk of the association to fail seems negligible. >> >>The only way I can see how to make the mapping more explicit, would be to >>add the original stream SSRC in the retransmission payload header. This >>would make the payload header 6 bytes instead of 2 bytes. I'd rather keep >>the payload header as it is now. >> >> > >Can we not prohibit the situation from occuring? You can always choose to >use non-clashing payload types, to avoid the problem? > > Yes, you must use non colliding PTs however this is not the problem. The problem is if you have multiple senders doing SSRC multiplexing. When first receiving a retransmission packet you need to bind this new SSRC to the original streams SSRC so you know what stream the retransmission repairs. The current proposal is to rely on the CNAME to know which SSRCs that comes from the same host. You also verify that retransmission packet belongs to a certain original stream by matching the OSN (Original Sequence Number) so that they actually match what you have requested. The corner case here is if a certain host using the same CNAME for two different sources (two SSRCs) sending with the same codec and both transmit at the same time. With an non negligible probability there can be losses in both original streams for the first requested retransmission (before binding between SSRCs are established) with identical RTP sequence numbers. In this case the request must not be sent for both losses. One has to first send one of them listen for response, verify it and make the binding, then request the other retransmission. And actually this mechanism is not 100% infallible. In multicast sessions with one sender and many requesters and the retransmissions goes out on the multicast, a sender can be requested to retransmit both streams with equal sequence number at the same time. However this probability is not that big, but as it exist the draft should recommend receiver to continue evaluate the mapping. To me it seems that any mechanism for evaluating this can never be 100 % sure that the mapping is correct. But in my view this becomes only problematic in multicast sessions with SSRC multiplexing and retransmissions going out to all participants. In all unicast cases the mechanism proposed will work as there is a single requester that can ensure that two outstanding request for different streams does not have the same sequence number until the mapping is firmly established. So my proposal is to add a note saying: SSRC multiplexing SHALL NOT be used in multicast sessions where retransmission packets are sent in other ways then exclusively by unicast to the requester. This is due to possibility for erroneous mapping of the original SSRC to the retransmission SSRC. Use session multiplexing instead to avoid this ambiguity. I think this is significant better than the 100% always working solution of adding a 32 bit Original SSRC field in the retransmission payload. > > >>> - In section 6.2, a pointer to the RTCP Reporting Extensions draft may be >>> appropriate, since that defines a receiver RTT report. >>> >>> >>My concern is that this would introduce one more dependency. >> >> > >Doesn't have to be a normative reference... > > I agree, put it in as an informative one. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Jan 10 03:25:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20655 for ; Fri, 10 Jan 2003 03:25:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0A8bID09886 for avt-archive@odin.ietf.org; Fri, 10 Jan 2003 03:37:18 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A8a6J09573; Fri, 10 Jan 2003 03:36:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A8ZiJ09553 for ; Fri, 10 Jan 2003 03:35:44 -0500 Received: from mailman.packetdesign.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20614 for ; Fri, 10 Jan 2003 03:23:07 -0500 (EST) Received: from packetdesign.com (main-fw-eth1.packetdesign.com [192.168.0.254]) by mailman.packetdesign.com (8.12.3/8.12.3) with ESMTP id h0A8QFOM031584; Fri, 10 Jan 2003 00:26:16 -0800 (PST) (envelope-from casner@acm.org) Date: Fri, 10 Jan 2003 00:39:36 -0800 (PST) From: Stephen Casner To: =?ISO-8859-1?Q?Mats_N=E4slund?= cc: AVT WG Subject: Re: [AVT] RTP: Confidentiality mechanisms In-Reply-To: <3E1D74C4.1090409@era.ericsson.se> Message-ID: <20030110002722.Q21230-100000@oak.packetdesign.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by www1.ietf.org id h0A8ZiJ09554 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Mats, I appreciate your input. > I have some problem with this wording. I assume we are talking CBC > mode(?) I think the text confuses the real issues with using CBC. Yes, we are talking DES CBC by default. As the section explains, this is only there to document existing practice (i.e., for backward compatibility). Mark asked earlier whether this whole section should be removed; I don't think so, but it may be that more needs to be said about this method being rudimentary and subject to replacement. > First: > > > each unit MUST be prepended to the unit before encryption to deter > > known plaintext attacks. > > This might signal: "It's okay to use a cipher that does not > resist known plaintext attacks, as long as a rand is prepended".¨ I am probably responsible for these words, and I think they were written in 1995. I only know epsilon about security now, and I knew less then. I am happy to change this to say something more appropriate about why the random prepend is required. > It is *not* ok to use such a cipher, neither does the prepend fix > that problem: the next input block, p2, *might* still be known and > the previous cipher text block, c1, is certainly known too, so the > input to the 2nd block, c1 XOR p2, will be known anyway. > > However, the issue with CBC is that the initial IV must be random > for existing security arguments to hold. Therefore, I assume that > what we really want to say is that in the absence of a truly random > IV, we must randomize the first plaintext block. This is indeed > indicated in the sequel of the above text, but has nothing to do with > known plaintext attacks: even with a random IV, that IV will in > typical CBC appl. be known to an attacker anyway, and is not the > issue. The only issue is to (sufficiently) "randomize the starting > point". Just saying this phase doesn't seem very informative or convincing, either. > Next, > > > For RTP, no prefix is required because the > > sequence number and timestamp fields are initialized with random > > offsets. > > This is (strictly speaking) not true. The existing security arguments > for CBC fail if a "counter" type value is used for the IV: even if > the first IV is random, following packet IVs may be highly correlated > to the first one. This does not mean that there is an "attack" on what > you propose (you are probably helped by the fact that the "IV" is > never seen by the attacker), I merely claim that it is not clear that > it is a "sound" way of doing it. At the very least, the caveats > should be pointed out. Again, I'd be happy to point out the caveats. The sentence I added at IESG request about this approach being weak was for that purpose. The IV is zero in this scheme, as mentioned in a later paragraph. -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Jan 10 09:55:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29600 for ; Fri, 10 Jan 2003 09:55:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0AF7Sa05072 for avt-archive@odin.ietf.org; Fri, 10 Jan 2003 10:07:28 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AF5qJ04440; Fri, 10 Jan 2003 10:05:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AF4vJ04379 for ; Fri, 10 Jan 2003 10:04:57 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29554 for ; Fri, 10 Jan 2003 09:52:12 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0AEtRKV023215; Fri, 10 Jan 2003 15:55:27 +0100 (MET) Received: from era.ericsson.se (research-pi6vzu.ki.sw.ericsson.se [147.214.181.170]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZQ1F7XPP; Fri, 10 Jan 2003 15:55:27 +0100 Message-ID: <3E1EDEDE.70904@era.ericsson.se> Date: Fri, 10 Jan 2003 15:55:26 +0100 X-Sybari-Trust: c9e3bc57 1864f774 21c82a8a 00000138 From: =?ISO-8859-1?Q?Mats_N=E4slund?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Casner CC: AVT WG , David McGrew , Mark Baugher Subject: Re: [AVT] RTP: Confidentiality mechanisms References: <20030110002722.Q21230-100000@oak.packetdesign.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Steve, Stephen Casner wrote: [snip] >> >>However, the issue with CBC is that the initial IV must be random >>for existing security arguments to hold. Therefore, I assume that >>what we really want to say is that in the absence of a truly random >>IV, we must randomize the first plaintext block. This is indeed >>indicated in the sequel of the above text, but has nothing to do with >>known plaintext attacks: even with a random IV, that IV will in >>typical CBC appl. be known to an attacker anyway, and is not the >>issue. The only issue is to (sufficiently) "randomize the starting >>point". > > > Just saying this phase doesn't seem very informative or convincing, > either. Agree. >>Next, >> >> > For RTP, no prefix is required because the >> > sequence number and timestamp fields are initialized with random >> > offsets. >> >>This is (strictly speaking) not true. The existing security arguments >>for CBC fail if a "counter" type value is used for the IV: even if >>the first IV is random, following packet IVs may be highly correlated >>to the first one. This does not mean that there is an "attack" on what >>you propose (you are probably helped by the fact that the "IV" is >>never seen by the attacker), I merely claim that it is not clear that >>it is a "sound" way of doing it. At the very least, the caveats >>should be pointed out. > > > Again, I'd be happy to point out the caveats. The sentence I added at > IESG request about this approach being weak was for that purpose. > > The IV is zero in this scheme, as mentioned in a later paragraph. Here is something along the lines I would like to see: What we want to do is to point out that CBC is a secure way to encrypt assuming that IVs are independent and random (and, of course, assuming the cipher itself is secure). This is well-known and follows from [BDJR] (at least in a certain, reasonable model). What RTP spec. proposes is to replace the IV by randomization of the first plaintext block. For RTCP, the spec. prepends 32 bits of randomness (*independently* for each packet). This will do part of the job, but corresponds to only having a short IV which may limit the achievable security somewhat (basically, after "only" 2^16 packets, a collision is likely to occur which may leak some information). For RTP, it is stated that the prepend is not needed as SEQ, TS are random. However, notice that they are *not* independent from packet to packet. (I am not sure, but I've heard of video app's where the TS can even stay fixed for two packets in a row.) Also, they only consitute at most 48 bits of randomness, and may cycle/wrap quite quickly. Had a "real" IV (sent along in the clear) been used in this way (as a counter) it is clear that it would limit the security, see [BDJR], at least theoretically. In your case, no IV is actually ever sent in the clear, so I cannot immediately see that it introduces additional weaknesses. One would, however, need to verify that this is indeed OK. Summing up, I would like to see something like (others, please comment): Secure CBC mode requires that the first block of each packet be XORed with random, independent, IVs of the same size as the cipher's block size. For RTCP, this is (partially) achieved by prepending each packet by a 32-bit random string, independently chosen for each packet. For RTP, the fact that the timestamp and sequence number start from random values are used to this end, and no prepend is done. It should however be noted that the randomness in both cases (RTP, RTCP) is limited, and for RTP, consecutive packets will not be independently randomized. High-security applications SHOULD consider other, more conventional, protection means. I would also like to connect to the discussion of need for integrity protection that we currently have for the SRTP profile. Note that the suggested use of CBC gives very limited integrity protection. An attacker flipping bits of the first block of ciphertext will produce "controlled" flips of the directly following block. He will, however, also then create random flips in the first decrypted plaintext block. For RTCP, half of these bits will be assumed to be random anyway (due to the prepend). So the prob. that he creates something "readable" is not too big. For sure, he succeeds with prob. at least 2^(-32), though it could be even bigger some times. Reference: [BDJR] Bellare, M., Desai, A., Jokipii, E., and Rogaway, P., "A Concrete Treatment of Symmetric Encryption: Analysis of DES Modes of Operation", Proceedings 38th IEEE FOCS, pp. 394-403, 1997. Best, /Mats _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Jan 10 11:06:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01982 for ; Fri, 10 Jan 2003 11:06:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0AGISG10411 for avt-archive@odin.ietf.org; Fri, 10 Jan 2003 11:18:28 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AGHuJ10399; Fri, 10 Jan 2003 11:17:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AGGlJ10320 for ; Fri, 10 Jan 2003 11:16:47 -0500 Received: from mailman.packetdesign.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01904 for ; Fri, 10 Jan 2003 11:04:01 -0500 (EST) Received: from packetdesign.com (main-fw-eth1.packetdesign.com [192.168.0.254]) by mailman.packetdesign.com (8.12.3/8.12.3) with ESMTP id h0AG6oOM042541; Fri, 10 Jan 2003 08:06:51 -0800 (PST) (envelope-from casner@acm.org) Date: Fri, 10 Jan 2003 08:20:17 -0800 (PST) From: Stephen Casner To: =?ISO-8859-1?Q?Mats_N=E4slund?= cc: AVT WG , David McGrew , Mark Baugher Subject: Re: [AVT] RTP: Confidentiality mechanisms In-Reply-To: <3E1EDEDE.70904@era.ericsson.se> Message-ID: <20030110081200.G21277-100000@oak.packetdesign.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Mats, Thanks for the additional details. One question: For RTP, the SSRC, which follows the SEQ and TS, is also randomly chosen and unknown to the attacker if both RTP and RTCP are encrypted. But it does not change from packet to packet. Does that contribute anything to the security? -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Jan 10 11:59:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03685 for ; Fri, 10 Jan 2003 11:59:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0AHBwM14564 for avt-archive@odin.ietf.org; Fri, 10 Jan 2003 12:11:58 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AH98J14478; Fri, 10 Jan 2003 12:09:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AH82J14424 for ; Fri, 10 Jan 2003 12:08:02 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03578 for ; Fri, 10 Jan 2003 11:55:14 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0AGwUAv003939; Fri, 10 Jan 2003 17:58:30 +0100 (MET) Received: from era.ericsson.se (research-pi6vzu.ki.sw.ericsson.se [147.214.181.170]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZGNL7GQ2; Fri, 10 Jan 2003 17:58:30 +0100 Message-ID: <3E1EFBB6.8050404@era.ericsson.se> Date: Fri, 10 Jan 2003 17:58:30 +0100 X-Sybari-Trust: 5fe5a631 1864f774 21c82a8a 00000138 From: =?ISO-8859-1?Q?Mats_N=E4slund?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Casner CC: AVT WG , David McGrew , Mark Baugher Subject: Re: [AVT] RTP: Confidentiality mechanisms References: <20030110081200.G21277-100000@oak.packetdesign.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Steve, Stephen Casner wrote: > Mats, > > Thanks for the additional details. One question: For RTP, the SSRC, > which follows the SEQ and TS, is also randomly chosen and unknown to > the attacker if both RTP and RTCP are encrypted. But it does not > change from packet to packet. Does that contribute anything to the > security? Not much. With CBC (using 3DES as I understand is the default), the SSRC will not go into "the IV", but rather into the second block: note that since DES has 64-bit blocks, the first block will be filled by 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ which makes up for the 64-bits. If SEQ/TS wraps or repeats, you will still get a collision in the first block which can be detected. If that is serious or not in practice can be discussed, but it is generally considered as a "problem" (e.g. it leaks the information that the two packets started with the same thing). Clearly, the fact that you have something random and unknown in the second block can't hurt, though I am not sure how much it really helps. With a larger block size (e.g. AES 128) it will add to the randomization *per* session, but as you say it is then fixed and the inter-packet dependence is the same as before. Cheers, /Mats _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Jan 10 16:25:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16800 for ; Fri, 10 Jan 2003 16:25:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0ALbpb31338 for avt-archive@odin.ietf.org; Fri, 10 Jan 2003 16:37:51 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ALbAJ30983; Fri, 10 Jan 2003 16:37:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ALMEJ30034 for ; Fri, 10 Jan 2003 16:22:14 -0500 Received: from [209.116.240.194] (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16272 for ; Fri, 10 Jan 2003 16:09:22 -0500 (EST) Received: from mail.nab.org by [209.116.240.194] via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Fri, 10 Jan 2003 16:11:16 -0500 Received: (private information removed) Message-ID: <5A659834E1607E4EBD72FCE2FE5C9CF101134FE4@mail.NAB.ORG> From: "Allison, Art" Date: Fri, 10 Jan 2003 16:09:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [AVT] ATSC RFI on advanced coding Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , The ATSC posted a RFI for video and audio coding for robust transport on 13 December 2002. It can be found at http://www.atsc.org/T3S6_202r5.pdf and has a due date of 20 January, 2003. Art ::{) Art Allison Director Advanced Engineering NAB 1771 N St NW Washington DC 20036 202 429 5418 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Jan 10 16:26:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16849 for ; Fri, 10 Jan 2003 16:26:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0ALcnp31445 for avt-archive@odin.ietf.org; Fri, 10 Jan 2003 16:38:49 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ALapJ30649; Fri, 10 Jan 2003 16:36:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AEIAJ01591 for ; Fri, 10 Jan 2003 09:18:10 -0500 Received: from boreas.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28377; Fri, 10 Jan 2003 09:05:25 -0500 (EST) Received: (from christos@localhost) by boreas.isi.edu (8.11.6/8.11.2) id h0AE8B611170; Fri, 10 Jan 2003 06:08:11 -0800 (PST) From: Christos Papadopoulos Message-Id: <200301101408.h0AE8B611170@boreas.isi.edu> To: christos@ISI.EDU (Christos Papadopoulos) Date: Fri, 10 Jan 2003 06:08:11 -0800 (PST) Cc: almeroth@cs.ucsb.edu (Kevin Almeroth) X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] CALL FOR PAPERS: NOSSDAV 2003 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Our sincere apologies if you receive multiple copies. ------------------------------------------------------------------------ The 13th International Workshop on Network and Operating Systems Support for Digital Audio and Video (NOSSDAV 2003) June 1-3, 2003 California, USA http://www.nossdav.org/2003 CALL FOR PAPERS Important Dates --------------- Submission Deadline (HARD): February 14, 2003 (midnight PST) Acceptance Notification : March 31, 2003 Camera Ready Deadline : April 25, 2003 Objectives ---------- The 13th International Workshop on Network and Operating Systems Support for Digital Audio and Video (NOSSDAV) brings together researchers, developers and practitioners from academia and industry to present and discuss new ideas and future directions in networking and operating systems support for all forms of networked human interaction. From large immersive environments to portable wireless multimedia devices, NOSSDAV covers a broad spectrum of cutting edge multimedia research that strongly impacts infrastructure and the human experience. For 12 years, NOSSDAV has proven to be an outstanding forum for researchers and developers involved in building innovative multimedia systems, networks, and applications. NOSSDAV is strategically positioned at the boundaries of applications and the operating system/network, bridging the gap between highly demanding applications and the infrastructure. NOSSDAV invites submissions on all areas of multimedia, but strongly encourages submissions in newly emerging specialized areas such as access grids, advanced telepresence and immersive applications, wireless multimedia, multimedia security, and embedded multimedia devices (e.g., Personal Video Recorders, etc.), among others. While NOSSDAV is primarily a research forum, innovative experimental commercial designs and prototypes are also welcome. To ensure a productive workshop environment, attendance will be limited to about 75 participants who are active in the field. A key aspect of the workshop is that it provides extensive discussion periods during which attendees can informally discuss their current work and future research directions. Traditionally, NOSSDAV has emphasized high quality experimental research based on prototype or real systems. NOSSDAV 2003 will continue this tradition. Submissions ----------- Submissions are sought in any area related to Network and Operating Systems Support for Digital Audio and Video. The topics of interest include, but are not limited to: * ubiquitous multimedia services * peer-to-peer multimedia services * Internet telephony * broadband streaming media content distribution * 3D multimedia and (networked) immersive environments * interactive network games * wireless and ad-hoc network multimedia systems * multimedia information appliances and consumer devices * collaborative conferencing * wireless multimedia * access grids * embedded multimedia devices (e.g., PVRs) * multimedia security * sensory interactive applications * digital rights management We solicit submissions of 5-page extended abstracts of technical papers, work-in-progress reports, and position statements. Papers should identify new problems and explain why they are important, challenge conventional wisdom, advocate a specific solution, and/or report on actual experience with real systems. All submissions will be reviewed by the members of the program committee. Submissions will be selected on the basis of their originality, technical merit and topical relevance, as well as the likelihood that the ideas will lead to insightful technical discussions. Papers submitted to NOSSDAV must not have been published or submitted elsewhere. Please do not submit abbreviated versions of journal or conference papers. Authors of accepted papers will be invited to present at the workshop and publish full-length versions of their papers in the workshop proceedings. All submissions must be made through the web. We suggest that authors use the two-column ACM format for the submissions. Detailed paper submission guidelines will be available here in January. Sincerely, The co-chairs, Christos Papadopoulos, USC, Kevin Almeroth, UCSB, _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Jan 10 18:48:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20194 for ; Fri, 10 Jan 2003 18:48:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0B00Rm07166 for avt-archive@odin.ietf.org; Fri, 10 Jan 2003 19:00:27 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ANwrJ07065; Fri, 10 Jan 2003 18:58:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ANvCJ07020 for ; Fri, 10 Jan 2003 18:57:12 -0500 Received: from mailman.packetdesign.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20117 for ; Fri, 10 Jan 2003 18:44:18 -0500 (EST) Received: from ash.packetdesign.com (ash.packetdesign.com [192.168.0.243]) by mailman.packetdesign.com (8.12.3/8.12.3) with ESMTP id h0ANlQOM036674; Fri, 10 Jan 2003 15:47:26 -0800 (PST) (envelope-from casner@acm.org) Date: Fri, 10 Jan 2003 15:47:25 -0800 (PST) From: Stephen Casner To: AVT WG Subject: Re: [AVT] Final edits to RTP spec and A/V profile In-Reply-To: <20030109145946.S78079-100000@ash.packetdesign.com> Message-ID: <20030110154341.U80020-100000@ash.packetdesign.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Attempt number three on the definition of an RTP session. David Leon made some suggestions, and I fixed some typo problems. Is this clear? And even more important, do you agree with what it specifies? RTP session: An association among a set of participants communicating with RTP. A participant may be involved in multiple RTP sessions at the same time. In a multimedia session, each medium is carried in a separate RTP session with its own RTCP packets. A participant distinguishes multiple RTP sessions by reception of different sessions using different pairs of destination transport addresses, where a pair of transport addresses comprises one network address plus a pair of ports for RTP and RTCP. All participants in an RTP session may share a common destination transport address pair, as in the case of IP multicast, or the pairs may be different for each participant, as in the case of individual unicast network addresses and port pairs. In the unicast case, a participant may receive from all other participants using the same pair of ports, or may use a distinct pair of ports for each. The distinguishing feature of an RTP session is that each defines a distinct space of SSRC identifiers (defined next). The set of participants included in one RTP session consists of those that can receive an SSRC identifier transmitted by any one of the participants either in RTP as the SSRC or a CSRC (also defined below) or in RTCP. For example, consider a three-party conference implemented using unicast UDP with each participant receiving from the other two on separate port pairs. If each participant sends RTCP feedback about data received from one other participant only back to that participant, then the conference is composed of three separate point-to-point RTP sessions. If each participant provides RTCP feedback about its reception of one other participant to both of the other participants, then the conference is composed of one multi-party RTP session. The latter case simulates the behavior that would occur with IP multicast communication among the three participants. -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Jan 10 19:42:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21098 for ; Fri, 10 Jan 2003 19:42:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0B0sQe09659 for avt-archive@odin.ietf.org; Fri, 10 Jan 2003 19:54:26 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0B0rAJ09612; Fri, 10 Jan 2003 19:53:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0B0qkJ09583 for ; Fri, 10 Jan 2003 19:52:46 -0500 Received: from smtp1.sea.theriver.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA21035 for ; Fri, 10 Jan 2003 19:39:50 -0500 (EST) Received: (qmail 24636 invoked from network); 11 Jan 2003 00:42:08 -0000 Received: from sense-sea-focal-dynamic-5-30.oz.net (HELO erols.com) (216.39.135.30) by smtp1.sea.theriver.com with SMTP; 11 Jan 2003 00:42:08 -0000 Message-ID: <3E1F682E.C1762E30@erols.com> Date: Fri, 10 Jan 2003 16:41:18 -0800 From: Chuck Harrison X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Casner CC: AVT WG Subject: Re: [AVT] Final edits to RTP spec and A/V profile References: <20030110154341.U80020-100000@ash.packetdesign.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, Steve, Breaking out the following short definition in section 3 might help first-time readers: Multimedia session: A set of concurrent RTP sessions among a common group of participants. For example, a videoconference connection (which is a multimedia session) may contain an audio RTP session and a video RTP session. I remember once finding RFC1889 confusing because there are several ways "session" is used in the text but only the RTP session had an explicit definition. Cheers, Chuck Stephen Casner wrote: > > Attempt number three on the definition of an RTP session. David Leon > made some suggestions, and I fixed some typo problems. Is this clear? > And even more important, do you agree with what it specifies? > > RTP session: An association among a set of participants > communicating with RTP. A participant may be involved in > multiple RTP sessions at the same time. In a multimedia > session, each medium is carried in a separate RTP session > with its own RTCP packets. A participant distinguishes > multiple RTP sessions by reception of different sessions > using different pairs of destination transport addresses, > where a pair of transport addresses comprises one network > address plus a pair of ports for RTP and RTCP. All > participants in an RTP session may share a common > destination transport address pair, as in the case of IP > multicast, or the pairs may be different for each > participant, as in the case of individual unicast network > addresses and port pairs. In the unicast case, a > participant may receive from all other participants using > the same pair of ports, or may use a distinct pair of ports > for each. > > The distinguishing feature of an RTP session is that each > defines a distinct space of SSRC identifiers (defined > next). The set of participants included in one RTP session > consists of those that can receive an SSRC identifier > transmitted by any one of the participants either in RTP as > the SSRC or a CSRC (also defined below) or in RTCP. For > example, consider a three-party conference implemented > using unicast UDP with each participant receiving from the > other two on separate port pairs. If each participant > sends RTCP feedback about data received from one other > participant only back to that participant, then the > conference is composed of three separate point-to-point RTP > sessions. If each participant provides RTCP feedback about > its reception of one other participant to both of the other > participants, then the conference is composed of one > multi-party RTP session. The latter case simulates the > behavior that would occur with IP multicast communication > among the three participants. > > -- Steve > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Jan 10 22:36:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24418 for ; Fri, 10 Jan 2003 22:36:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0B3mck17688 for avt-archive@odin.ietf.org; Fri, 10 Jan 2003 22:48:38 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0B3m2J17673; Fri, 10 Jan 2003 22:48:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0B3iJJ17587 for ; Fri, 10 Jan 2003 22:44:19 -0500 Received: from snowy.nsw.cmis.CSIRO.AU (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA24212 for ; Fri, 10 Jan 2003 22:31:18 -0500 (EST) From: Silvia.Pfeiffer@csiro.au Received: by snowy.nsw.cmis.CSIRO.AU (SMI-8.6/SMI-SVR4) id OAA16420; Sat, 11 Jan 2003 14:34:34 +1100 Received: from coxs-nh.nsw.cmis.CSIRO.AU(130.155.25.7) via SMTP by snowy.nsw.cmis.CSIRO.AU, id smtpdAAAa0040Y; Sat Jan 11 14:34:30 2003 Received: by coxs-nh.nsw.cmis.csiro.au with Internet Mail Service (5.5.2656.59) id ; Sat, 11 Jan 2003 14:34:29 +1100 Received: from csiro.au (klee.nsw.cmis.csiro.au [130.155.20.11]) by coxs-nh.nsw.cmis.csiro.au with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id CF9H6V5N; Sat, 11 Jan 2003 14:34:27 +1100 To: avt@ietf.org, casner@acm.org, csp@isi.edu, mankin@psg.com Message-ID: <3E202BEF.2176D17B@csiro.au> Date: Sun, 12 Jan 2003 01:36:31 +1100 Organization: CSIRO X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en, de, fr MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] New I-Ds for Ogg technologies (Vorbis over RTP, Ogg file format, Mimetypes) Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello everybody, several new I-Ds have been submitted from the Ogg community this week. The intention of our submissions is to gain IETF standards on the freely available and open media technologies that are developed in the Ogg community (http://www.xiph.org/). Required standards embrace things like container format specifications, rtp transport specifications, and MIME type specifications. The listed I-Ds are the currently existing submissions, which we would like to see discussed here. This is also a request to the Area Directors to progress them onto the standards track. --- The first two I-Ds relate to a persistent container format that was specified to hold Internet transportable media data in a simple way. These should be simple to handle as they have been discussed on this list before and the format is stable: 1) "The application/ogg Media Type" Author(s) : L. Walleij http://www.ietf.org/internet-drafts/draft-walleij-ogg-mediatype-08.txt This is an I-D requesting to register "application/ogg" as a mime-type for any bitstream that conforms to the Ogg bitstream format specification (see I-D below). 2) "The Ogg encapsulation format version 0" Author(s) : S. Pfeiffer http://www.ietf.org/internet-drafts/draft-pfeiffer-ogg-fileformat-01.txt This I-D specifies the Ogg bitstream format version 0, which is a general, freely-available encapsulation format for media streams. It is capable to encapsulate any kind and number of video and audio encoding formats as well as other data streams in a single bitstream. --- The next two I-Ds relate to transporting audio data encoded in the Vorbis format over rtp: 3) "RTP Payload Format for Vorbis Encoded Audio" Author(s) : P. Kerr http://www.ietf.org/internet-drafts/draft-kerr-avt-vorbis-rtp-00.txt This document describes a RTP payload format for transporting Vorbis encoded audio. 4) "The audio/rtp-vorbis MIME Type" Author(s) : B. Short http://www.ietf.org/internet-drafts/draft-short-avt-rtp-vorbis-mime-00.txt This document explains the need for a MIME subtype which identifies a Vorbis audio payload to be used within a Realtime Transport Protocol (RTP) bitstream. This document also provides the necessary information to register audio/rtp-vorbis as a MIME type. --- Regards, Silvia Pfeiffer. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Jan 10 22:47:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24625 for ; Fri, 10 Jan 2003 22:47:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0B3xT217894 for avt-archive@odin.ietf.org; Fri, 10 Jan 2003 22:59:29 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0B3x7J17878; Fri, 10 Jan 2003 22:59:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0B3wCJ17864 for ; Fri, 10 Jan 2003 22:58:12 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24597 for ; Fri, 10 Jan 2003 22:45:12 -0500 (EST) Received: from localhost ([127.0.0.1] helo=psg.com ident=mankin) by psg.com with esmtp (Exim 3.36 #2) id 18XCdH-000Il9-00; Fri, 10 Jan 2003 19:48:27 -0800 To: Silvia.Pfeiffer@csiro.au cc: avt@ietf.org, casner@acm.org, csp@isi.edu In-Reply-To: Message from Silvia.Pfeiffer@csiro.au of "Sun, 12 Jan 2003 01:36:31 +1100." <3E202BEF.2176D17B@csiro.au> Date: Fri, 10 Jan 2003 19:48:20 -0800 From: Allison Mankin Message-Id: Subject: [AVT] Re: New I-Ds for Ogg technologies (Vorbis over RTP, Ogg file format, Mimetypes) Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Silvia, Thank you for the submissions. We were waiting for a format document to go with the media type registration (document 2 to go with docuement 1) and so I will take these into immediate IESG review now. Documents 3 and 4 are entirely new to AVT I believe, and so these are for the working group's discussion. Allison > To: avt@ietf.org, casner@acm.org, csp@isi.edu, mankin@psg.com > Date: Sun, 12 Jan 2003 01:36:31 +1100 > Subject: New I-Ds for Ogg technologies (Vorbis over RTP, Ogg file format, > > Hello everybody, > > several new I-Ds have been submitted from the Ogg community this week. > The intention of our submissions is to gain IETF standards on the freely > available and open media technologies that are developed in the Ogg > community (http://www.xiph.org/). Required standards embrace things like > container format specifications, rtp transport specifications, and MIME > type specifications. The listed I-Ds are the currently existing > submissions, which we would like to see discussed here. This is also a > request to the Area Directors to progress them onto the standards track. > > --- > > The first two I-Ds relate to a persistent container format that was > specified to hold Internet transportable media data in a simple way. > These should be simple to handle as they have been discussed on this > list before and the format is stable: > > 1) "The application/ogg Media Type" > Author(s) : L. Walleij > http://www.ietf.org/internet-drafts/draft-walleij-ogg-mediatype-08.txt > > This is an I-D requesting to register "application/ogg" as a mime-type > for any bitstream that conforms to the Ogg bitstream format > specification (see I-D below). > > > 2) "The Ogg encapsulation format version 0" > Author(s) : S. Pfeiffer > http://www.ietf.org/internet-drafts/draft-pfeiffer-ogg-fileformat-01.txt > > This I-D specifies the Ogg bitstream format version 0, which is a > general, freely-available encapsulation format for media streams. It is > capable to encapsulate any kind and number of video and audio encoding > formats as well as other data streams in a single bitstream. > > --- > > The next two I-Ds relate to transporting audio data encoded in the > Vorbis format over rtp: > > 3) "RTP Payload Format for Vorbis Encoded Audio" > Author(s) : P. Kerr > http://www.ietf.org/internet-drafts/draft-kerr-avt-vorbis-rtp-00.txt > > This document describes a RTP payload format for transporting Vorbis > encoded audio. > > > 4) "The audio/rtp-vorbis MIME Type" > Author(s) : B. Short > http://www.ietf.org/internet-drafts/draft-short-avt-rtp-vorbis-mime-00.txt > > This document explains the need for a MIME subtype which identifies a > Vorbis audio payload to be used within a Realtime Transport Protocol > (RTP) bitstream. This document also provides the necessary information > to register > audio/rtp-vorbis as a MIME type. > > --- > > Regards, > > Silvia Pfeiffer. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Sat Jan 11 10:15:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12889 for ; Sat, 11 Jan 2003 10:15:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0BFSTg26605 for avt-archive@odin.ietf.org; Sat, 11 Jan 2003 10:28:29 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0BFRIJ26557; Sat, 11 Jan 2003 10:27:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0BFPQJ26506 for ; Sat, 11 Jan 2003 10:25:26 -0500 Received: from purple.nge.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12838 for ; Sat, 11 Jan 2003 10:12:07 -0500 (EST) Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.6/8.12.6) with ESMTP id h0BFF4d3001383; Sat, 11 Jan 2003 10:15:08 -0500 (EST) (envelope-from csp@purple.nge.isi.edu) Message-Id: <200301111515.h0BFF4d3001383@purple.nge.isi.edu> To: Allison Mankin cc: Silvia.Pfeiffer@csiro.au, avt@ietf.org, casner@acm.org Subject: Re: [AVT] Re: New I-Ds for Ogg technologies (Vorbis over RTP, Ogg file format, Mimetypes) In-Reply-To: Your message of "Fri, 10 Jan 2003 19:48:20 PST." Date: Sat, 11 Jan 2003 10:15:04 -0500 From: Colin Perkins Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --> Allison Mankin writes: >Silvia, > >Thank you for the submissions. We were waiting for a format document >to go with the media type registration (document 2 to go with >docuement 1) and so I will take these into immediate IESG review now. > >Documents 3 and 4 are entirely new to AVT I believe, and so these >are for the working group's discussion. Documents 3 and 4 are extensions of earlier drafts that have been discussed in AVT. The chairs and authors have been discussing them recently, input on these from the group would be appreciated. Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Sat Jan 11 14:36:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16818 for ; Sat, 11 Jan 2003 14:36:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0BJnO307278 for avt-archive@odin.ietf.org; Sat, 11 Jan 2003 14:49:24 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0BJkkJ07035; Sat, 11 Jan 2003 14:46:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0BJifJ06954 for ; Sat, 11 Jan 2003 14:44:41 -0500 Received: from dlana.elec.gla.ac.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16638 for ; Sat, 11 Jan 2003 14:31:23 -0500 (EST) Received: from webmail ([130.209.176.65] helo=webmail.elec.gla.ac.uk ident=mail) by dlana.elec.gla.ac.uk with esmtp (Exim 4.04) id 18XROy-0000I7-00 for avt@ietf.org; Sat, 11 Jan 2003 19:34:40 +0000 Received: from www-data by webmail.elec.gla.ac.uk with local (Exim 3.12 #1 (Debian)) id 18XSde-0001av-00 for ; Sat, 11 Jan 2003 20:53:54 +0000 To: AVT WG Subject: Re: [AVT] Re: New I-Ds for Ogg technologies (Vorbis over RTP, Ogg file format, Mimetypes) Message-ID: <1042318434.3e208462b6c58@webmail.elec.gla.ac.uk> Date: Sat, 11 Jan 2003 20:53:54 +0000 (GMT) From: Phil Kerr References: <200301111515.h0BFF4d3001383@purple.nge.isi.edu> In-Reply-To: <200301111515.h0BFF4d3001383@purple.nge.isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 81.86.177.17 Content-Transfer-Encoding: 8bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Thanks Colin, The two new I-Ds (Vorbis RTP and its MIME type) are to be merged into one document, with the MIME type changing to audio/vorbis. The next changes to the combined I-D will be to add a missing setup block to the codebook RTCP message and to add a field to indicate the seq id of the RTP stream when the new codebook should be applied for decoding. A new RTCP APP message to cater for stream metadata is also under development. An I-D to cover TCP over RTP was discussed last month and this is of interest to the Vorbis RTP draft as it offers a reliable delivery mechanism for the codebooks, which are critical for stream decoding. I think it would be good to review the code book delivery once this new I-D is available, so section 4 may be subject to a substantial review. Regards Phil Quoting Colin Perkins : > --> Allison Mankin writes: > >Silvia, > > > >Thank you for the submissions. We were waiting for a format document > >to go with the media type registration (document 2 to go with > >docuement 1) and so I will take these into immediate IESG review now. > > > >Documents 3 and 4 are entirely new to AVT I believe, and so these > >are for the working group's discussion. > > Documents 3 and 4 are extensions of earlier drafts that have been > discussed > in AVT. The chairs and authors have been discussing them recently, input > on > these from the group would be appreciated. > > Colin > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Jan 13 03:46:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04579 for ; Mon, 13 Jan 2003 03:46:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0D907o05186 for avt-archive@odin.ietf.org; Mon, 13 Jan 2003 04:00:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0D8xRJ05145; Mon, 13 Jan 2003 03:59:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0D8vBJ05066 for ; Mon, 13 Jan 2003 03:57:11 -0500 Received: from mailserv.intranet.gr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04520 for ; Mon, 13 Jan 2003 03:43:04 -0500 (EST) Received: from mailserv.intranet.gr (localhost [127.0.0.1]) by mailserv.intranet.gr (8.11.3/8.11.3) with ESMTP id h0D8m3H19506 for ; Mon, 13 Jan 2003 10:48:03 +0200 (EET) Received: from aiolos.intranet.gr (aiolos.intranet.GR [146.124.6.7]) by mailserv.intranet.gr (8.11.3/8.11.3) with ESMTP id h0D8m2m19502 for ; Mon, 13 Jan 2003 10:48:02 +0200 (EET) Received: from pcnt189 (pcnt189 [146.124.44.189]) by aiolos.intranet.gr (8.11.4/8.9.0) with SMTP id h0D8lHn00539 for ; Mon, 13 Jan 2003 10:47:17 +0200 (EET) From: "Spiros Spirou" To: "AVT" Subject: Re: [AVT] Final edits to RTP spec and A/V profile Date: Mon, 13 Jan 2003 10:50:59 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, Please see my comments below. > In a multimedia session, each medium is carried > in a separate RTP session with its own RTCP packets. In this sentence the word "session" is used twice but with different meanings. Moreover, if you assign a single meaning to both occurrences then the part before the comma directly contradicts the part after it due to the mutual exclusion of the terms "multimedia" and "each medium". I would suggest a substitution of the first occurrence of "session" with "communication". > The distinguishing feature of an RTP session is that each > defines a distinct space of SSRC identifiers (defined next). Reading this I got the impression that SSRC identifiers used by one session cannot be used by another session. Is this the intended meaning? In this case the reader is left wondering about how a specific subset of SSRC identifiers is reserved from the set of all SSRC identifiers. Up to now I thought that the only constraint for SSRC identifiers was that they should be unique within an RTP session but the same SSRC identifier can transcend sessions. > A participant distinguishes multiple RTP sessions by reception > of different sessions using different pairs of destination > transport addresses, where a pair of transport addresses > comprises one network address plus a pair of ports for RTP and RTCP. > The distinguishing feature of an RTP session is that each > defines a distinct space of SSRC identifiers (defined next). > If each participant sends RTCP feedback about data received from > one other participant only back to that participant, then the > conference is composed of three separate point-to-point RTP > sessions. If each participant provides RTCP feedback about > its reception of one other participant to both of the other > participants, then the conference is composed of one > multi-party RTP session. Each of the 3 aforementioned experts proposes a different distinguishing feature for an RTP session. These are a) the destination transport address, b) the set of SSRC identifiers and c) the scope of RTCP reports respectively. I used to think that the common denominator in an RTP session and what distinguishes from other RTP sessions is only the destination RTP port number. In this way, the RTCP port number is implied by the RTP port, both unicast and multicast cases are covered and the SSRC identifiers are used to distinguish among participants of the session. I am now confused as to what constitutes an RTP session. Regards, Spiros Spirou _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Jan 13 19:53:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00011 for ; Mon, 13 Jan 2003 19:53:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0E17an05075 for avt-archive@odin.ietf.org; Mon, 13 Jan 2003 20:07:36 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E16qJ04403; Mon, 13 Jan 2003 20:06:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E15HJ04338 for ; Mon, 13 Jan 2003 20:05:17 -0500 Received: from chiron.nge.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29978 for ; Mon, 13 Jan 2003 19:50:53 -0500 (EST) Received: from chiron (csp@localhost) by chiron.nge.isi.edu (8.11.6/8.11.6) with ESMTP id h0E0s9S08089; Mon, 13 Jan 2003 19:54:09 -0500 Message-Id: <200301140054.h0E0s9S08089@chiron.nge.isi.edu> To: Phil Kerr cc: AVT WG Subject: Re: [AVT] Re: New I-Ds for Ogg technologies (Vorbis over RTP, Ogg file format, Mimetypes) In-Reply-To: Your message of "Sat, 11 Jan 2003 20:53:54 GMT." <1042318434.3e208462b6c58@webmail.elec.gla.ac.uk> Date: Mon, 13 Jan 2003 19:54:09 -0500 From: Colin Perkins Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Phil, This seems like a reasonable plan for completing the drafts. A couple of comments below. --> Phil Kerr writes: >Thanks Colin, > >The two new I-Ds (Vorbis RTP and its MIME type) are to be merged into one >document, with the MIME type changing to audio/vorbis. > >The next changes to the combined I-D will be to add a missing setup block to the >codebook RTCP message and to add a field to indicate the seq id of the RTP >stream when the new codebook should be applied for decoding. Presumably, an initial codebook can be sent as part of the SDP signalling? >A new RTCP APP message to cater for stream metadata is also under development. > >An I-D to cover TCP over RTP was discussed last month and this is of interest to >the Vorbis RTP draft as it offers a reliable delivery mechanism for the >codebooks, which are critical for stream decoding. I think it would be good to >review the code book delivery once this new I-D is available, so section 4 may >be subject to a substantial review. Yes, definitely. The draft should also discuss the congestion control and reliability requirements for transmission of codebooks. Also, is there an associated video codec? Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Jan 14 02:38:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17734 for ; Tue, 14 Jan 2003 02:38:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0E7qkI07106 for avt-archive@odin.ietf.org; Tue, 14 Jan 2003 02:52:46 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E7pWJ07064; Tue, 14 Jan 2003 02:51:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E7oJJ06990 for ; Tue, 14 Jan 2003 02:50:19 -0500 Received: from mailman.packetdesign.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17701 for ; Tue, 14 Jan 2003 02:35:46 -0500 (EST) Received: from packetdesign.com (main-fw-eth1.packetdesign.com [192.168.0.254]) by mailman.packetdesign.com (8.12.3/8.12.3) with ESMTP id h0E7cvOM053866; Mon, 13 Jan 2003 23:38:58 -0800 (PST) (envelope-from casner@acm.org) Date: Mon, 13 Jan 2003 23:53:11 -0800 (PST) From: Stephen Casner To: Spiros Spirou cc: AVT Subject: Re: [AVT] Final edits to RTP spec and A/V profile In-Reply-To: Message-ID: <20030113230830.N23190-100000@oak.packetdesign.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , On Mon, 13 Jan 2003, Spiros Spirou wrote: > Please see my comments below. Thanks for your comments. > > In a multimedia session, each medium is carried > > in a separate RTP session with its own RTCP packets. > > In this sentence the word "session" is used twice but > with different meanings. Not exactly. The two terms are "multimedia session" and "RTP session". That is, "session" is not a term by itself. But your point is well taken. Chuck Harrison suggested that I include a definition of "multimedia session" as another term, which I agree is a good idea. > > The distinguishing feature of an RTP session is that each > > defines a distinct space of SSRC identifiers (defined next). > > Reading this I got the impression that SSRC identifiers used by > one session cannot be used by another session. Is this the intended > meaning? No. What the text was intended to mean is that each RTP session has its own, separate, whole space of SSRC identifiers. Different RTP sessions may use the same SSRC identifiers independently. I can try revising the words. > > A participant distinguishes multiple RTP sessions by reception > > of different sessions using different pairs of destination > > transport addresses, where a pair of transport addresses > > comprises one network address plus a pair of ports for RTP and RTCP. > > > The distinguishing feature of an RTP session is that each > > defines a distinct space of SSRC identifiers (defined next). > > > If each participant sends RTCP feedback about data received from > > one other participant only back to that participant, then the > > conference is composed of three separate point-to-point RTP > > sessions. If each participant provides RTCP feedback about > > its reception of one other participant to both of the other > > participants, then the conference is composed of one > > multi-party RTP session. > > Each of the 3 aforementioned experts proposes a different distinguishing > feature for an RTP session. These are a) the destination transport address, > b) the set of SSRC identifiers and c) the scope of RTCP reports > respectively. These are all related aspects of an RTP session: - Since each RTP session defineds a separate space of SSRC identifiers, the same SSRC id may be used in two sessions, and therefore those sessions need to be received on different destination transport addresses in order to tell the packets apart. - If an application shares SSRC identifiers across multiple destination transport addresses, then there is just one SSRC identifier space (collisions must be resolved in that space), and one RTP session. > I used to think that the common denominator in an RTP session and what > distinguishes from other RTP sessions is only the destination RTP port > number. That is what RFC 1889 said for both multicast and unicast. For quite some time, draft-ietf-avt-rtp-new changed this for unicast so the port numbers did not have to be common on both ends. This was necessary since there might be allocation conflicts with other protocols. Now, in this most recent expansion of the definition of an RTP session, I've expanded the definition further to allow a single session to use multiple destination transport addresses. This was always necessary (but not previously acknowledged) because an RTP translator or mixer hooks together multiple parts of an RTP session using different destination transport addresses. And, we need to recognize that the multi-unicast example that you quoted is also valid. > In this way, the RTCP port number is implied by the RTP port, both unicast > and multicast cases are covered and the SSRC identifiers are used to > distinguish > among participants of the session. I am now confused as to what constitutes > an RTP session. For typical, simple cases, that is all still true. -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Jan 14 11:28:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01968 for ; Tue, 14 Jan 2003 11:28:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0EGgq711368 for avt-archive@odin.ietf.org; Tue, 14 Jan 2003 11:42:52 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EGeBJ11154; Tue, 14 Jan 2003 11:40:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EGbQJ10843 for ; Tue, 14 Jan 2003 11:37:26 -0500 Received: from dlana.elec.gla.ac.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01415 for ; Tue, 14 Jan 2003 11:22:42 -0500 (EST) Received: from josquin ([130.209.179.66] helo=josquin.elec.gla.ac.uk) by dlana.elec.gla.ac.uk with esmtp (Exim 4.04) id 18YTt2-00062a-00 for avt@ietf.org; Tue, 14 Jan 2003 16:26:00 +0000 Subject: Re: [AVT] Re: New I-Ds for Ogg technologies (Vorbis over RTP, Ogg file format, Mimetypes) From: Phil Kerr To: AVT WG In-Reply-To: <200301140054.h0E0s9S08089@chiron.nge.isi.edu> References: <200301140054.h0E0s9S08089@chiron.nge.isi.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 14 Jan 2003 16:18:43 +0000 Message-Id: <1042561124.27521.303.camel@josquin> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Colin, Thanks for the feedback. Yes, the initial set of codebooks could be sent using SDP and I'll investigate this further. I'll update the draft to highlight this change together with your suggestions concerning congestion control and reliability. Vorbis audio is part of a wider suite of media formats and there are two video components in development, Theora and Tarkin. Theora will probably be the first to reach release-grade and there are discussions ongoing regarding the appropriate I-Ds to support it. Regards Phil On Tue, 2003-01-14 at 00:54, Colin Perkins wrote: > Phil, > > This seems like a reasonable plan for completing the drafts. A couple of > comments below. > > --> Phil Kerr writes: > >Thanks Colin, > > > >The two new I-Ds (Vorbis RTP and its MIME type) are to be merged into one > >document, with the MIME type changing to audio/vorbis. > > > >The next changes to the combined I-D will be to add a missing setup block to the > >codebook RTCP message and to add a field to indicate the seq id of the RTP > >stream when the new codebook should be applied for decoding. > > Presumably, an initial codebook can be sent as part of the SDP signalling? > > >A new RTCP APP message to cater for stream metadata is also under development. > > > >An I-D to cover TCP over RTP was discussed last month and this is of interest to > >the Vorbis RTP draft as it offers a reliable delivery mechanism for the > >codebooks, which are critical for stream decoding. I think it would be good to > >review the code book delivery once this new I-D is available, so section 4 may > >be subject to a substantial review. > > Yes, definitely. The draft should also discuss the congestion control and > reliability requirements for transmission of codebooks. > > Also, is there an associated video codec? > > Colin > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Jan 14 19:59:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17929 for ; Tue, 14 Jan 2003 19:59:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0F1DuO18016 for avt-archive@odin.ietf.org; Tue, 14 Jan 2003 20:13:56 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F1BvJ17960; Tue, 14 Jan 2003 20:11:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F1AfJ17893 for ; Tue, 14 Jan 2003 20:10:41 -0500 Received: from mail-out2.apple.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17874 for ; Tue, 14 Jan 2003 19:55:47 -0500 (EST) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id h0F0x8I01585 for ; Tue, 14 Jan 2003 16:59:08 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 14 Jan 2003 16:59:08 -0800 Received: from [10.169.44.59] (vpn-scv-x4-184.apple.com [17.219.194.184]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id h0F0x7Q10998; Tue, 14 Jan 2003 16:59:07 -0800 (PST) Mime-Version: 1.0 X-Sender: singer@mail.apple.com (Unverified) Message-Id: In-Reply-To: <3E1BA9E0.5060104@dynamicsoft.com> References: <20030107144628.B73937-100000@ash.packetdesign.com> <3E1BA9E0.5060104@dynamicsoft.com> Date: Tue, 14 Jan 2003 16:56:49 -0800 To: Jonathan Rosenberg , Stephen Casner From: Dave Singer Subject: Re: [AVT] RTP: explanation of "sampling instant" Cc: AVT WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , >>Instead, for each medium the RTP timestamp is >> related to the sampling instant by pairing it with a >> timestamp from a reference clock (wallclock) that >> represents the time when the data corresponding to the RTP >> timestamp was sampled. The reference clock is shared by >> all media to be synchronized. The timestamp pairs are not >> transmitted in every data packet, but at a lower rate in >> RTCP SR packets as described in Section 6.4. >> >> Applications transmitting stored data rather than data >> sampled in real time typically use a virtual clock to >> determine when the next frame or other unit of each medium >> in the stored data should be presented. > >I think "determine" is the wrong word here. Its the receiver that >determines when to present it. The sender indicates when it should >be presented. So, I would propose: > >Applications transmitting stored data rather than data sampled in >real time typically use a virtual clock to indicate when the next >frame (or other unit of each medium) in the stored data should be >presented. This has always been my problem about how this is presented; it is an unusual protocol description which describes what happened at the source. Usually protocols describe characteristics of the stream or what the receiver ought to do. In particular, there is no 'sampling instant' for streams sent from disk under rtsp control, for example. However, there is a reference common clock which can be used to relate the RTP timestamps in the various streams. -- David Singer Apple Computer/QuickTime _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Jan 14 20:23:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18331 for ; Tue, 14 Jan 2003 20:23:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0F1cBU19538 for avt-archive@odin.ietf.org; Tue, 14 Jan 2003 20:38:11 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F1aAJ18832; Tue, 14 Jan 2003 20:36:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F1ZuJ18818 for ; Tue, 14 Jan 2003 20:35:56 -0500 Received: from mailman.packetdesign.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18282 for ; Tue, 14 Jan 2003 20:21:02 -0500 (EST) Received: from ash.packetdesign.com (ash.packetdesign.com [192.168.0.243]) by mailman.packetdesign.com (8.12.3/8.12.3) with ESMTP id h0F1OH4k088157; Tue, 14 Jan 2003 17:24:17 -0800 (PST) (envelope-from casner@acm.org) Date: Tue, 14 Jan 2003 17:24:17 -0800 (PST) From: Stephen Casner To: Dave Singer cc: AVT WG Subject: Re: [AVT] RTP: explanation of "sampling instant" In-Reply-To: Message-ID: <20030114171130.F14752-100000@ash.packetdesign.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Dave, > >> Applications transmitting stored data rather than data > >> sampled in real time typically use a virtual clock to > >> determine when the next frame or other unit of each medium > >> in the stored data should be presented. > > > >I think "determine" is the wrong word here. Its the receiver that > >determines when to present it. The sender indicates when it should > >be presented. So, I would propose: > > > >Applications transmitting stored data rather than data sampled in > >real time typically use a virtual clock to indicate when the next > >frame (or other unit of each medium) in the stored data should be > >presented. > > This has always been my problem about how this is presented; it is > an unusual protocol description which describes what happened at the > source. Usually protocols describe characteristics of the stream or > what the receiver ought to do. In particular, there is no 'sampling > instant' for streams sent from disk under rtsp control, for example. > However, there is a reference common clock which can be used to > relate the RTP timestamps in the various streams. I don't think it is a description of what happened at the source. We are choosing what particular reference point in the life of the data represented by the RTP timestamp in the packet corresponds to the associated reference clock timestamp. Choosing a common reference point in the life of the data allows data from separate sources to be related. Specifying some amount of time to be added to the sampling instant in order to hypothesize a presentation instant seems artificial to me, and adds an extra complication. I've proposed some additional text to try to explain the motivation for the choice of reference point, and to explain how "sampling instant" should be interpreted for the case of streams sent from disk. Do you think the words I added made the situation better or worse? Do you have other words to suggest? I already replied to the message you were replying to; I explained why I used the phrase "determine when the next frame or other unit of each medium in the stored data should be presented". How would you describe the process that the sending is doing when it uses a reference clock to determine when it is time for the next piece of data to be transmitted? -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Jan 14 20:59:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18828 for ; Tue, 14 Jan 2003 20:59:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0F2EMY21576 for avt-archive@odin.ietf.org; Tue, 14 Jan 2003 21:14:22 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F2CkJ21508; Tue, 14 Jan 2003 21:12:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F2BHJ21471 for ; Tue, 14 Jan 2003 21:11:17 -0500 Received: from snap.CS.Berkeley.EDU (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18799 for ; Tue, 14 Jan 2003 20:56:22 -0500 (EST) Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.9.3/8.9.3-ZUUL) id RAA14309 for avt@ietf.org; Tue, 14 Jan 2003 17:59:31 -0800 Date: Tue, 14 Jan 2003 17:59:31 -0800 From: John Lazzaro Message-Id: <200301150159.RAA14309@snap.CS.Berkeley.EDU> To: avt@ietf.org Subject: [AVT] draft-lazzaro-avt-mwpp-coding-guidelines-01.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Hi everyone, I sent the draft of the complete MWPP implementation guide off to internet-drafts@ietf.org today. You can download it now from: http://www.cs.berkeley.edu/~lazzaro/sa/pubs/txt/current-guide.txt See the abstract below for details, as well as the I-D change log. Comments are welcome. I'll turn the document around one more time before the March 3 San Francisco cutoff date, and can incorporate your feedback into the revision. Writing this 77-page (!) document added a few more open issues to draft-ietf-avt-mwpp-midi-rtp-05.txt. Next, I'll spend a few days writing the RTP over TCP I-D, and then I'll start working through the open issue list for draft-ietf-avt-mwpp-midi-rtp-05.txt. I expect to submit an -06.txt in time for March 3 deadline. --- INTERNET-DRAFT John Lazzaro January 15, 2003 John Wawrzynek Expires: July 15, 2003 UC Berkeley An Implementation Guide to the MIDI Wire Protocol Packetization (MWPP) Abstract This memo offers non-normative implementation guidance for the MIDI Wire Protocol Packetization (MWPP), an RTP packetization for the MIDI command language. In the main body of the memo, we discuss one MWPP application in detail: an interactive, two-party, single- stream session over unicast UDP transport that uses RTCP. In the Appendices, we discuss specialized implementation issues: MWPP without RTCP, MWPP with TCP, multi-stream sessions, multi-party sessions, and content streaming. --- ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro ------------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Jan 15 04:05:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20544 for ; Wed, 15 Jan 2003 04:05:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0F9KPE25396 for avt-archive@odin.ietf.org; Wed, 15 Jan 2003 04:20:25 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F9IjJ25307; Wed, 15 Jan 2003 04:18:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F9EEJ25170 for ; Wed, 15 Jan 2003 04:14:14 -0500 Received: from coep.org.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA20446 for ; Wed, 15 Jan 2003 03:59:05 -0500 (EST) Received: (qmail 28037 invoked by uid 525); 15 Jan 2003 09:06:19 -0000 Message-ID: <20030115090619.28036.qmail@coep.org.in> From: " Devdutta Bhosale " To: avt@ietf.org Date: Wed, 15 Jan 2003 14:36:19 +0530 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] help for RFC 3016 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hello, We r final year undergrad students of computer engg. And we r currently working on RFC 3016 for mpeg4. RFC 3016 specifies that it enables transport of mpeg4 AV streams without using mpeg systems or mpeg4 system functionality. What is it exactly? An internet draft "RTP-generic" mentions that RFC 3016 may or may not use Sync. layer while RFC 3016 mentions that it does not use sync layer What is it exactly? What types of implementations use RFC 3016 and r there any links to such implementation? _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Jan 15 05:58:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22185 for ; Wed, 15 Jan 2003 05:58:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FBDAm32657 for avt-archive@odin.ietf.org; Wed, 15 Jan 2003 06:13:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FBCiJ32638; Wed, 15 Jan 2003 06:12:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FBBiJ32591 for ; Wed, 15 Jan 2003 06:11:44 -0500 Received: from gw-nl6.philips.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22155; Wed, 15 Jan 2003 05:56:38 -0500 (EST) From: jan.vandermeer@philips.com Received: from smtpscan-nl4.philips.com (smtpscan-nl4.philips.com [130.139.36.24]) by gw-nl6.philips.com (Postfix) with ESMTP id DCFBDA40DF; Wed, 15 Jan 2003 11:59:53 +0100 (MET) Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) by smtpscan-nl4.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id LAA26887; Wed, 15 Jan 2003 11:59:53 +0100 (MET) Received: from ehv501soh.diamond.philips.com (e3soh01.diamond.philips.com [130.139.54.47]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id LAA23864; Wed, 15 Jan 2003 11:59:52 +0100 (MET) To: " Devdutta Bhosale " Cc: avt@ietf.org, avt-admin@ietf.org Subject: Re: [AVT] help for RFC 3016 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Wed, 15 Jan 2003 11:57:53 +0100 X-MIMETrack: Serialize by Router on ehv501soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at 15/01/2003 11:57:56, Serialize complete at 15/01/2003 11:57:56 Content-Type: multipart/alternative; boundary="=_alternative 003C65D8C1256CAF_=" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format. --=_alternative 003C65D8C1256CAF_= Content-Type: text/plain; charset="us-ascii" RFC 3016 does NOT use the MPEG-4 Sync Layer. I don't know "RTP-generic", but I am not aware of any internet draft with the incorrect statement that RFC 3016 may or may not use SL. Jan van der Meer " Devdutta Bhosale " Sent by: avt-admin@ietf.org 2003-01-15 10:06 AM To: avt@ietf.org cc: (bcc: Jan vanderMeer/EHV/CE/PHILIPS) Subject: [AVT] help for RFC 3016 Classification: hello, We r final year undergrad students of computer engg. And we r currently working on RFC 3016 for mpeg4. RFC 3016 specifies that it enables transport of mpeg4 AV streams without using mpeg systems or mpeg4 system functionality. What is it exactly? An internet draft "RTP-generic" mentions that RFC 3016 may or may not use Sync. layer while RFC 3016 mentions that it does not use sync layer What is it exactly? What types of implementations use RFC 3016 and r there any links to such implementation? _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --=_alternative 003C65D8C1256CAF_= Content-Type: text/html; charset="us-ascii"
RFC 3016 does NOT use the MPEG-4 Sync Layer.

I don't know "RTP-generic", but I am not aware of any internet draft with the incorrect statement that RFC 3016 may or may not use SL.

Jan van der Meer







" Devdutta Bhosale " <dbhosale@comp.coep.org.in>

Sent by:
avt-admin@ietf.org

2003-01-15 10:06 AM

       
        To:        avt@ietf.org
        cc:        (bcc: Jan vanderMeer/EHV/CE/PHILIPS)
        Subject:        [AVT] help for RFC 3016

        Classification:        




hello,
We r final year undergrad students of computer engg.
And we r currently working on RFC 3016 for mpeg4.


RFC 3016 specifies that it enables transport of mpeg4 AV streams without
using mpeg systems or mpeg4 system functionality. What is it exactly?

An internet draft "RTP-generic" mentions  that RFC 3016 may or may not use
Sync. layer while RFC 3016 mentions that it does not use sync layer
What is it exactly?

What types of implementations use RFC 3016 and r there any links to such
implementation?

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt

--=_alternative 003C65D8C1256CAF_=-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Jan 15 11:07:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01303 for ; Wed, 15 Jan 2003 11:07:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FGMDJ21856 for avt-archive@odin.ietf.org; Wed, 15 Jan 2003 11:22:13 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGL4J21716; Wed, 15 Jan 2003 11:21:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGF9J21353 for ; Wed, 15 Jan 2003 11:15:10 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00993 for ; Wed, 15 Jan 2003 10:59:58 -0500 (EST) Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0FG3FFr013079; Wed, 15 Jan 2003 08:03:15 -0800 (PST) Received: from MCGREWW2K (dhcp-128-107-163-158.cisco.com [128.107.163.158]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with SMTP id ADE91861; Wed, 15 Jan 2003 08:00:09 -0800 (PST) From: "David A. Mcgrew" To: =?us-ascii?Q?Mats_Naslund?= , "Stephen Casner" Cc: "AVT WG" , "Mark Baugher" Subject: RE: [AVT] RTP: Confidentiality mechanisms Date: Wed, 15 Jan 2003 08:03:14 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <3E1EDEDE.70904@era.ericsson.se> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Mats, thanks for bringing this issue up, more inline: Mats wrote: > Summing up, I would like to see something like (others, please > comment): > > Secure CBC mode requires that the first block of each packet > be XORed with random, independent, IVs of the same size as the > cipher's block size. For RTCP, this is (partially) achieved by > prepending each packet by a 32-bit random string, independently > chosen for each packet. For RTP, the fact that the timestamp and > sequence number start from random values are used to this end, and > no prepend is done. It should however be noted that the randomness > in both cases (RTP, RTCP) is limited, and for RTP, consecutive > packets will not be independently randomized. High-security > applications SHOULD consider other, more conventional, protection > means. Clearly these mechanisms should be deprecated. It might be best to have text that states that fact up front, and then provides the details for the interested reader. It's hard to judge text without knowing where it would go in the document, but your text looks fine. Looking through Section 9.1 of RFC1889 makes me wonder if perhaps the entire confidentiality mechanism described there should be deprecated. It's DES in CBC mode with a 32-bit IV. Because it lacks a full IV, there are attacks which will work against it with less than 2^56 effort. It is certainly good security practice to deprecate weak legacy crypto whenever possible, though perhaps it would be best to wait until there's an accepted alternative for RTP. David _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Jan 15 12:06:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03384 for ; Wed, 15 Jan 2003 12:06:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FHLCA26860 for avt-archive@odin.ietf.org; Wed, 15 Jan 2003 12:21:12 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FHJRJ26749; Wed, 15 Jan 2003 12:19:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FH5sJ25599 for ; Wed, 15 Jan 2003 12:05:54 -0500 Received: from mail.pel.panasonic.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03097 for ; Wed, 15 Jan 2003 11:50:41 -0500 (EST) Received: from atrgreyj (vw1.pel.panasonic.de [10.78.238.55]) by mail.pel.panasonic.de (__________PEL__Mail-Server__________) with SMTP id <0H8R00C9HLKXJB@panasonic.de> for avt@ietf.org; Wed, 15 Jan 2003 17:53:22 +0100 (MET) Date: Wed, 15 Jan 2003 17:53:23 +0100 From: Jose Rey Subject: RE: [AVT] Comments on draft-ietf-avt-rtp-retransmission-04.txt In-reply-to: <3E1E833B.5060805@era.ericsson.se> To: Magnus Westerlund , Colin Perkins Cc: David.Leon@nokia.com, avt@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi all, thanks Colin and Magnus for your comments. Please see mine below. ...snip > The current proposal is to rely on the CNAME to know which SSRCs that > comes from the same host. You also verify that retransmission packet > belongs to a certain original stream by matching the OSN (Original > Sequence Number) so that they actually match what you have requested. > The corner case here is if a certain host using the same > CNAME for two > different sources (two SSRCs) sending with the same codec and both > transmit at the same time. With an non negligible probability > there can > be losses in both original streams for the first requested > retransmission (before binding between SSRCs are established) with > identical RTP sequence numbers. In this case the request must not be > sent for both losses. One has to first send one of them listen for > response, verify it and make the binding, then request the other > retransmission. > > And actually this mechanism is not 100% infallible. In multicast > sessions with one sender and many requesters and the retransmissions > goes out on the multicast, a sender can be requested to > retransmit both > streams with equal sequence number at the same time. However this > probability is not that big, but as it exist the draft should > recommend > receiver to continue evaluate the mapping. To me it seems that any > mechanism for evaluating this can never be 100 % sure that > the mapping > is correct. But in my view this becomes only problematic in multicast > sessions with SSRC multiplexing and retransmissions going out to all > participants. In all unicast cases the mechanism proposed > will work as > there is a single requester that can ensure that two > outstanding request > for different streams does not have the same sequence number > until the > mapping is firmly established. > > So my proposal is to add a note saying: > > SSRC multiplexing SHALL NOT be used in multicast sessions where > retransmission packets are sent in other ways then exclusively by > unicast to the requester. This is due to possibility for erroneous > mapping of the original SSRC to the retransmission SSRC. Use session > multiplexing instead to avoid this ambiguity. > > I think this is significant better than the 100% always > working solution > of adding a 32 bit Original SSRC field in the retransmission payload. > Magnus explains well the problem. Although one could argue the estimated TS (by the receiver) would be helpful to distinguish the two streams in this particular multicast case, there is still a chance that both TSs are equal or close enough so that no distinction is possible. In summary, better keep it simple and working :) The proposed text will be included in the retransmission draft. cheers, Jose _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Jan 15 13:22:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05732 for ; Wed, 15 Jan 2003 13:22:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FIb9g32130 for avt-archive@odin.ietf.org; Wed, 15 Jan 2003 13:37:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FIXQJ31727; Wed, 15 Jan 2003 13:33:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FIWKJ31705 for ; Wed, 15 Jan 2003 13:32:20 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05622 for ; Wed, 15 Jan 2003 13:17:05 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0FIMUt15153 for ; Wed, 15 Jan 2003 20:22:31 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 15 Jan 2003 20:20:21 +0200 Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 15 Jan 2003 20:20:21 +0200 Received: from agni.research.nokia.com (agni.research.nokia.com [172.21.40.24]) by mgw.research.nokia.com (8.9.3/8.9.3) with ESMTP id UAA11998; Wed, 15 Jan 2003 20:20:21 +0200 (EET) Received: from agni.research.nokia.com (localhost [127.0.0.1]) by agni.research.nokia.com (8.12.5/8.12.5) with ESMTP id h0FIKP5p022569; Wed, 15 Jan 2003 20:20:25 +0200 Received: (from ppessi@localhost) by agni.research.nokia.com (8.12.5/8.12.5/Submit) id h0FIKOXU022568; Wed, 15 Jan 2003 20:20:24 +0200 X-Authentication-Warning: agni.research.nokia.com: ppessi set sender to Pekka.Pessi@nokia.com using -f To: Stephen Casner Cc: AVT WG Subject: Re: [AVT] Final edits to RTP spec and A/V profile X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}uZ\JfD\"IG#G{j`hZI;=DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi In-Reply-To: <20030110154341.U80020-100000@ash.packetdesign.com> (Stephen Casner's message of "Fri, 10 Jan 2003 15:47:25 -0800 (PST)") References: <20030110154341.U80020-100000@ash.packetdesign.com> Date: Wed, 15 Jan 2003 20:20:24 +0200 Message-ID: User-Agent: Gnus/5.09001 (Oort Gnus v0.10) XEmacs/21.4 (Honest Recruiter, i386-redhat-linux) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 15 Jan 2003 18:20:21.0215 (UTC) FILETIME=[C3A9AEF0:01C2BCC2] Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Stephen Casner writes: >Attempt number three on the definition of an RTP session. David Leon >made some suggestions, and I fixed some typo problems. Is this clear? >And even more important, do you agree with what it specifies? What is the difference between an RTP cloud (a la section 7) and an RTP session? > RTP session: An association among a set of participants > communicating with RTP. A participant may be involved in > multiple RTP sessions at the same time. In a multimedia > session, each medium is carried in a separate RTP session > with its own RTCP packets. A participant distinguishes > multiple RTP sessions by reception of different sessions > using different pairs of destination transport addresses, > where a pair of transport addresses comprises one network > address plus a pair of ports for RTP and RTCP. Don't we have multiple mediums in a single RTP session, for example, with some MPEG4 packetization? So, s/medium/RTP media type/, or is it then a circular definition? >All > participants in an RTP session may share a common > destination transport address pair, as in the case of IP > multicast, or the pairs may be different for each > participant, as in the case of individual unicast network > addresses and port pairs. In the unicast case, a > participant may receive from all other participants using > the same pair of ports, or may use a distinct pair of ports > for each. I'd drop this text away, as a RTP session can consist of two multicast group connected via a translator or a mixer. I also think translators and mixers that forward CSRCs and SDESs should be mentioned in the definition. Pekka _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Jan 15 15:29:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09248 for ; Wed, 15 Jan 2003 15:29:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FKiO407839 for avt-archive@odin.ietf.org; Wed, 15 Jan 2003 15:44:24 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FKghJ07792; Wed, 15 Jan 2003 15:42:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FKfrJ07748 for ; Wed, 15 Jan 2003 15:41:53 -0500 Received: from purple.nge.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09170 for ; Wed, 15 Jan 2003 15:26:36 -0500 (EST) Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.6/8.12.6) with ESMTP id h0FKTOLo054556; Wed, 15 Jan 2003 15:29:24 -0500 (EST) (envelope-from csp@purple.nge.isi.edu) Message-Id: <200301152029.h0FKTOLo054556@purple.nge.isi.edu> To: Phil Kerr cc: AVT WG Subject: Re: [AVT] Re: New I-Ds for Ogg technologies (Vorbis over RTP, Ogg file format, Mimetypes) In-Reply-To: Your message of "14 Jan 2003 16:18:43 GMT." <1042561124.27521.303.camel@josquin> Date: Wed, 15 Jan 2003 12:29:24 -0800 From: Colin Perkins Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Phil, --> Phil Kerr writes: >Thanks for the feedback. > >Yes, the initial set of codebooks could be sent using SDP and I'll >investigate this further. I'll update the draft to highlight this >change together with your suggestions concerning congestion control and >reliability. Thanks. >Vorbis audio is part of a wider suite of media formats and there are two >video components in development, Theora and Tarkin. Theora will >probably be the first to reach release-grade and there are discussions >ongoing regarding the appropriate I-Ds to support it. Okay, good. It's probably worth considering the development of an RTP payload format reasonably early in the development of the video codec, to ensure that the result is easy to convey in an efficient manner. Cheers, Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Jan 16 05:21:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06181 for ; Thu, 16 Jan 2003 05:21:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GAaNR08626 for avt-archive@odin.ietf.org; Thu, 16 Jan 2003 05:36:23 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GARsJ08233; Thu, 16 Jan 2003 05:27:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GAPpJ08127 for ; Thu, 16 Jan 2003 05:25:51 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06011 for ; Thu, 16 Jan 2003 05:10:15 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0GADZKV027531; Thu, 16 Jan 2003 11:13:35 +0100 (MET) Received: from era.ericsson.se (research-pi6vzu.ki.sw.ericsson.se [147.214.181.170]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZGNNBMZ7; Thu, 16 Jan 2003 11:13:35 +0100 Message-ID: <3E2685CF.6050404@era.ericsson.se> Date: Thu, 16 Jan 2003 11:13:35 +0100 X-Sybari-Trust: 3342d572 9ffcebbb ba5f67bb 00000138 From: =?ISO-8859-1?Q?Mats_N=E4slund?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David A. Mcgrew" CC: Stephen Casner , AVT WG , Mark Baugher Subject: Re: [AVT] RTP: Confidentiality mechanisms References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi David, David A. Mcgrew wrote: > Mats, > > thanks for bringing this issue up, more inline: > > Mats wrote: > >>Summing up, I would like to see something like (others, please >>comment): >> >> Secure CBC mode requires that the first block of each packet >> be XORed with random, independent, IVs of the same size as the >> cipher's block size. For RTCP, this is (partially) achieved by >> prepending each packet by a 32-bit random string, independently >> chosen for each packet. For RTP, the fact that the timestamp and >> sequence number start from random values are used to this end, and >> no prepend is done. It should however be noted that the randomness >> in both cases (RTP, RTCP) is limited, and for RTP, consecutive >> packets will not be independently randomized. High-security >> applications SHOULD consider other, more conventional, protection >> means. > > > Clearly these mechanisms should be deprecated. It might be best to have text > that states that fact up front, and then provides the details for the interested > reader. It's hard to judge text without knowing where it would go in the > document, but your text looks fine. > > Looking through Section 9.1 of RFC1889 makes me wonder if perhaps the entire > confidentiality mechanism described there should be deprecated. It's DES in CBC > mode with a 32-bit IV. Because it lacks a full IV, there are attacks which will > work against it with less than 2^56 effort. It is certainly good security > practice to deprecate weak legacy crypto whenever possible, though perhaps it > would be best to wait until there's an accepted alternative for RTP. I am inclined to agree. It is really a non-standard crypto transform that is described. In fact, one alternative way to conceptually think of the encryption is as follows: 1. The packet header (or part thereof) is prepended with randomness and encrypted in ECB (electronic code book mode). 2. The result of step 1 is used as IV for the CBC encryption of the remainder, using the *same* key as in step 1. It seems to me that defining this new "mode of encryption" is against the AVT WG's earlier stated policy not to define actual crypto transforms. I too would therefore ask the WG to consider removing this altogether, rather than adding the text I proposed. Best, /Mats _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Jan 16 09:51:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12701 for ; Thu, 16 Jan 2003 09:51:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GF6Wx27845 for avt-archive@odin.ietf.org; Thu, 16 Jan 2003 10:06:32 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GF2nJ27700; Thu, 16 Jan 2003 10:02:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GF1NJ27618 for ; Thu, 16 Jan 2003 10:01:23 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12554 for ; Thu, 16 Jan 2003 09:45:41 -0500 (EST) Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0GEn4YH001800; Thu, 16 Jan 2003 09:49:05 -0500 (EST) Message-ID: <3E26C65A.8070603@dynamicsoft.com> Date: Thu, 16 Jan 2003 09:48:58 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Casner CC: AVT WG Subject: Re: [AVT] RTP: explanation of "sampling instant" References: <20030108172801.W76233-100000@ash.packetdesign.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit inline. Stephen Casner wrote: > On Tue, 7 Jan 2003, Jonathan Rosenberg wrote: > > >>It took me three reads to parse this. I would propose a comma: >> >>The sampling instance is chosen as the point of reference for the RTP >>timestamp because it is known to the transmitting endpoint and has a >>common definition for all media, independent of encoding delays or other >>processing > > > Yes, that is better. How about this: > > The sampling instance is chosen as the point of reference for the > RTP timestamp because it is known to the transmitting endpoint and > because it has a common definition for all media, independent of > encoding delays or other processing. OK. > > >>> The purpose is to allow synchronized presentation of all >>> media sampled at the same time. Comparing RTP timestamps >>> from different media is not effective because they have >>> independent random offsets and may advance at different >>> rates. >> >>Aren't these two sentences contradictory? The first says its for >>synchronized presentation, and the second says it can't be used for that >>because they have random offsets and advance at different rates. > > > Well, what I meant in the first sentence was: > > The purpose of choosing the sampling instance as the point of > reference is to allow synchronized presentation of all media > sampled at the same time. > > I don't think this conflicts with the second sentence, though perhaps > there should be a paragraph break between them. Might help. >>>Instead, for each medium the RTP timestamp is >>> related to the sampling instant by pairing it with a >>> timestamp from a reference clock (wallclock) that >>> represents the time when the data corresponding to the RTP >>> timestamp was sampled. The reference clock is shared by >>> all media to be synchronized. The timestamp pairs are not >>> transmitted in every data packet, but at a lower rate in >>> RTCP SR packets as described in Section 6.4. >>> >>> Applications transmitting stored data rather than data >>> sampled in real time typically use a virtual clock to >>> determine when the next frame or other unit of each medium >>> in the stored data should be presented. >> >>I think "determine" is the wrong word here. Its the receiver that >>determines when to present it. The sender indicates when it should be >>presented. So, I would propose: >> >>Applications transmitting stored data rather than data sampled in real >>time typically use a virtual clock to indicate when the next frame (or >>other unit of each medium) in the stored data should be presented. > > > What you wrote is true. But what I was after was the notion that the > sender uses the virtual clock to determine when to take the next unit > of data out of the file and send it. That is not how I interpreted it. > But I was afraid that if I used > that phrasing, people would say the RTP timestamp should be the > transmit time. It's not, it is the presentation timestamp from the > file. Wouldn't it be better to just say that, then? That is, say that its used as the timestamp to guide when its sent, but its not the transmit time, its the presentation time that the receiver will use. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Jan 16 10:54:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14454 for ; Thu, 16 Jan 2003 10:54:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GG9um00906 for avt-archive@odin.ietf.org; Thu, 16 Jan 2003 11:09:56 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GG5SJ32510; Thu, 16 Jan 2003 11:05:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GG4OJ32423 for ; Thu, 16 Jan 2003 11:04:24 -0500 Received: from purple.nge.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14239 for ; Thu, 16 Jan 2003 10:48:41 -0500 (EST) Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.6/8.12.6) with ESMTP id h0GFphH8023819; Thu, 16 Jan 2003 10:51:43 -0500 (EST) (envelope-from csp@purple.nge.isi.edu) Message-Id: <200301161551.h0GFphH8023819@purple.nge.isi.edu> To: =?ISO-8859-1?Q?Mats_N=E4slund?= cc: "David A. Mcgrew" , Stephen Casner , AVT WG , Mark Baugher Subject: Re: [AVT] RTP: Confidentiality mechanisms In-Reply-To: Your message of "Thu, 16 Jan 2003 11:13:35 +0100." <3E2685CF.6050404@era.ericsson.se> Date: Thu, 16 Jan 2003 07:51:43 -0800 From: Colin Perkins Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --> =?ISO-8859-1?Q?Mats_N=E4slund?= writes: >Hi David, > >David A. Mcgrew wrote: >> Mats, >> >> thanks for bringing this issue up, more inline: >> >> Mats wrote: >> >>>Summing up, I would like to see something like (others, please >>>comment): >>> >>> Secure CBC mode requires that the first block of each packet >>> be XORed with random, independent, IVs of the same size as the >>> cipher's block size. For RTCP, this is (partially) achieved by >>> prepending each packet by a 32-bit random string, independently >>> chosen for each packet. For RTP, the fact that the timestamp and >>> sequence number start from random values are used to this end, and >>> no prepend is done. It should however be noted that the randomness >>> in both cases (RTP, RTCP) is limited, and for RTP, consecutive >>> packets will not be independently randomized. High-security >>> applications SHOULD consider other, more conventional, protection >>> means. >> >> >> Clearly these mechanisms should be deprecated. It might be best to have text >> that states that fact up front, and then provides the details for the interested >> reader. It's hard to judge text without knowing where it would go in the >> document, but your text looks fine. >> >> Looking through Section 9.1 of RFC1889 makes me wonder if perhaps the entire >> confidentiality mechanism described there should be deprecated. It's DES in CBC >> mode with a 32-bit IV. Because it lacks a full IV, there are attacks which will >> work against it with less than 2^56 effort. It is certainly good security >> practice to deprecate weak legacy crypto whenever possible, though perhaps it >> would be best to wait until there's an accepted alternative for RTP. > >I am inclined to agree. It is really a non-standard crypto transform >that is described. In fact, one alternative way to conceptually think >of the encryption is as follows: > >1. The packet header (or part thereof) is prepended with randomness > and encrypted in ECB (electronic code book mode). >2. The result of step 1 is used as IV for the CBC encryption of > the remainder, using the *same* key as in step 1. > >It seems to me that defining this new "mode of encryption" is >against the AVT WG's earlier stated policy not to define actual >crypto transforms. I too would therefore ask the WG to consider >removing this altogether, rather than adding the text I proposed. It's included for backwards compatibility. You will note that the draft also says "It is RECOMMENDED that stronger encryption algorithms such as Triple-DES be used in place of the default algorithm", and points to the possible existance of new profiles with additional security. My hope is that applications will migrate to SRTP or some other more secure solution, once those are complete. Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Jan 16 11:06:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14722 for ; Thu, 16 Jan 2003 11:06:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GGLVj01453 for avt-archive@odin.ietf.org; Thu, 16 Jan 2003 11:21:31 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GGCBJ01057; Thu, 16 Jan 2003 11:12:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GGBCJ01011 for ; Thu, 16 Jan 2003 11:11:12 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14491 for ; Thu, 16 Jan 2003 10:55:29 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0GFwnKV001440; Thu, 16 Jan 2003 16:58:49 +0100 (MET) Received: from era.ericsson.se (research-pi6vzu.ki.sw.ericsson.se [147.214.181.170]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZGNN1Q2T; Thu, 16 Jan 2003 16:58:48 +0100 Message-ID: <3E26D6B8.8020809@era.ericsson.se> Date: Thu, 16 Jan 2003 16:58:48 +0100 X-Sybari-Trust: ed7bb0ce 9ffcebbb ba5f67bb 00000138 From: =?ISO-8859-1?Q?Mats_N=E4slund?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Colin Perkins CC: "David A. Mcgrew" , Stephen Casner , AVT WG , Mark Baugher Subject: Re: [AVT] RTP: Confidentiality mechanisms References: <200301161551.h0GFphH8023819@purple.nge.isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Colin, Colin Perkins wrote: > --> =?ISO-8859-1?Q?Mats_N=E4slund?= writes: > >>Hi David, >> >>David A. Mcgrew wrote: >> >>>Mats, >>> >>>thanks for bringing this issue up, more inline: >>> >>>Mats wrote: >>> >>> >>>>Summing up, I would like to see something like (others, please >>>>comment): >>>> >>>> Secure CBC mode requires that the first block of each packet >>>> be XORed with random, independent, IVs of the same size as the >>>> cipher's block size. For RTCP, this is (partially) achieved by >>>> prepending each packet by a 32-bit random string, independently >>>> chosen for each packet. For RTP, the fact that the timestamp and >>>> sequence number start from random values are used to this end, and >>>> no prepend is done. It should however be noted that the randomness >>>> in both cases (RTP, RTCP) is limited, and for RTP, consecutive >>>> packets will not be independently randomized. High-security >>>> applications SHOULD consider other, more conventional, protection >>>> means. >>> >>> >>>Clearly these mechanisms should be deprecated. It might be best to have text >>>that states that fact up front, and then provides the details for the interested >>>reader. It's hard to judge text without knowing where it would go in the >>>document, but your text looks fine. >>> >>>Looking through Section 9.1 of RFC1889 makes me wonder if perhaps the entire >>>confidentiality mechanism described there should be deprecated. It's DES in CBC >>>mode with a 32-bit IV. Because it lacks a full IV, there are attacks which will >>>work against it with less than 2^56 effort. It is certainly good security >>>practice to deprecate weak legacy crypto whenever possible, though perhaps it >>>would be best to wait until there's an accepted alternative for RTP. >> >>I am inclined to agree. It is really a non-standard crypto transform >>that is described. In fact, one alternative way to conceptually think >>of the encryption is as follows: >> >>1. The packet header (or part thereof) is prepended with randomness >> and encrypted in ECB (electronic code book mode). >>2. The result of step 1 is used as IV for the CBC encryption of >> the remainder, using the *same* key as in step 1. >> >>It seems to me that defining this new "mode of encryption" is >>against the AVT WG's earlier stated policy not to define actual >>crypto transforms. I too would therefore ask the WG to consider >>removing this altogether, rather than adding the text I proposed. > > > It's included for backwards compatibility. You will note that the draft > also says "It is RECOMMENDED that stronger encryption algorithms such as > Triple-DES be used in place of the default algorithm", and points to the > possible existance of new profiles with additional security. Note though that the problems comming from the short IV are not really addressed by replacing DES by 3-DES. I.e., one should should at least make clear what the issues are so that implementors do not think that 3-DES will be a "cure" to all problems. Our concern is not so much the cipher transform itself, it is more the use of it. > > My hope is that applications will migrate to SRTP or some other more secure > solution, once those are complete. Agree. Best, /Mats _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Jan 16 11:23:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15206 for ; Thu, 16 Jan 2003 11:23:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GGd9t03109 for avt-archive@odin.ietf.org; Thu, 16 Jan 2003 11:39:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GGYpJ02111; Thu, 16 Jan 2003 11:34:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GGV4J01932 for ; Thu, 16 Jan 2003 11:31:04 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14958 for ; Thu, 16 Jan 2003 11:15:22 -0500 (EST) From: David.Leon@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0GGIUB23148 for ; Thu, 16 Jan 2003 10:18:40 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 16 Jan 2003 10:18:23 -0600 Received: from daebe008.NOE.Nokia.com ([172.18.242.238]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 16 Jan 2003 08:17:25 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AVT] Comments on draft-ietf-avt-rtp-retransmission-04.txt Date: Thu, 16 Jan 2003 10:17:24 -0600 Message-ID: <7CA3477F476D7F4FB82F02960B79CEBD017E4F78@daebe008.americas.nokia.com> Thread-Topic: [AVT] Comments on draft-ietf-avt-rtp-retransmission-04.txt Thread-Index: AcK9OrvGb+un6gJQQeS0jF6xjE2emgAPtPIg To: X-OriginalArrivalTime: 16 Jan 2003 16:17:25.0809 (UTC) FILETIME=[C1FDCA10:01C2BD7A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0GGV4J01933 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Colin, I had missed one of your comments. My answer below: > > >> - In section 6.1, when the original and retransmission > > streams are sent > > >> in the same RTP session, how are the RTCP timing rules > > modified? Does > > >> the sender get twice the RTCP bandwidth since it > > appears as two SSRCs? > > > > > >Here again, we thought that the RTP retransmission stream had to be > > >treated like any other RTP stream as far as the RTCP > timing rules are > > >concerned. This means that we can't specify the fraction > of the RTCP > > >bandwidth available for the retransmission stream separatly. > > The original > > >stream and the retransmission stream are seen as two > > independent senders > > >that are sharing the RTCP bandwidths allocated to senders in > > the session as > > >would any other sender do. > > > > Okay, but the draft says "the receiver sends report blocks > > for the original > > and the retransmission streams in the same RTCP RR packet". > > It is not clear > > that two separate RTP sessions are used. This is the SSRC-multiplexing case so there's a single RTP session. The receiver thus receives two SSRC sources, one for the original stream and one for the retransmission stream in this session. As usual, it should send one report block for each source in its RR packets. Is something creating confusion? Thanks, David. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Jan 16 11:49:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15825 for ; Thu, 16 Jan 2003 11:49:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GH4WN04633 for avt-archive@odin.ietf.org; Thu, 16 Jan 2003 12:04:32 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GGsVJ03921; Thu, 16 Jan 2003 11:54:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GGmoJ03615 for ; Thu, 16 Jan 2003 11:48:50 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15484 for ; Thu, 16 Jan 2003 11:33:07 -0500 (EST) Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0GGaTYH001903; Thu, 16 Jan 2003 11:36:30 -0500 (EST) Message-ID: <3E26DF83.8040909@dynamicsoft.com> Date: Thu, 16 Jan 2003 11:36:19 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Casner CC: Spiros Spirou , AVT Subject: Re: [AVT] Final edits to RTP spec and A/V profile References: <20030113230830.N23190-100000@oak.packetdesign.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit responses inline. Stephen Casner wrote: > These are all related aspects of an RTP session: > > - Since each RTP session defineds a separate space of SSRC > identifiers, the same SSRC id may be used in two sessions, and > therefore those sessions need to be received on different > destination transport addresses in order to tell the packets > apart. > > - If an application shares SSRC identifiers across multiple > destination transport addresses, then there is just one SSRC > identifier space (collisions must be resolved in that space), and > one RTP session. > > >>I used to think that the common denominator in an RTP session and what >>distinguishes from other RTP sessions is only the destination RTP port >>number. > > > That is what RFC 1889 said for both multicast and unicast. For quite > some time, draft-ietf-avt-rtp-new changed this for unicast so the port > numbers did not have to be common on both ends. This was necessary > since there might be allocation conflicts with other protocols. Now, > in this most recent expansion of the definition of an RTP session, > I've expanded the definition further to allow a single session to use > multiple destination transport addresses. This was always necessary > (but not previously acknowledged) because an RTP translator or mixer > hooks together multiple parts of an RTP session using different > destination transport addresses. While I have no problem with this definition in principle, I don't see how it fits in with SDP, not just from a definitional perspective, but from a functional perspective. In particular, it was previously the case that the destination IP/port served as an identifier for the RTP session. Now, that is not the case. From the perspective of a single participant, an RTP session is a *collection* of (ip,port,port+1). This means that, from an SDP perspective, we are now in a scenario where a set of m-lines in SDP constitute the same RTP session. However, there is no identifier that indicates that. The session ID in the SDP, ironically, is not an RTP session ID, since it applies to the whole of SDP. In a multi-unicast conference composed of audio and video, a single SDP might have 3 video m-lines, constituting one RTP session, and 3 audio m-lines, consituting one audio session. Thus, we have no way to signal which m-lines in an SDP are in the same RTP session. Indeed, I am curious whether existing implementations of multi-unicast conferences actually do use the same SSRC on each unicast connection, and generate RR/SR based on the whole collection. Somehow, I doubt it. I suspect each unicast connection is treated as a separate RTP session. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Jan 16 11:58:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16081 for ; Thu, 16 Jan 2003 11:58:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GHDn505867 for avt-archive@odin.ietf.org; Thu, 16 Jan 2003 12:13:49 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GH59J04824; Thu, 16 Jan 2003 12:05:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GH0VJ04271 for ; Thu, 16 Jan 2003 12:00:31 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15778 for ; Thu, 16 Jan 2003 11:44:51 -0500 (EST) Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0GGmCYH001915; Thu, 16 Jan 2003 11:48:13 -0500 (EST) Message-ID: <3E26E241.7060302@dynamicsoft.com> Date: Thu, 16 Jan 2003 11:48:01 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Casner CC: AVT WG Subject: Re: [AVT] RTP: SSRC multiplexing for same medium References: <20030108180259.G76233-100000@ash.packetdesign.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit inline. Stephen Casner wrote: > Answering several messages at once, inline... >>2. Does this text imply that an RTP receiver MUST be prepared to receive >>multiple multiplexed streams on a single session? I expect most >>implementations today using unicast are not prepared for that (although >>I believe they should be) > > > No, it would be inappropriate to make that a MUST. We do say, in > Section 6: > > RTP application designers SHOULD avoid mechanisms that can only > work in unicast mode and will not scale to larger numbers. I have a hard time seeing how this implies that receiving multiple streams on a single session is not a MUST. Indeed, receiving many streams on a single session is how multicast works, so one would imagine that the direct translation of this to unicast, receiving multiple streams on a single port for multi-unicast, would be the recommended approach. If RTP does not mandate that a user be prepared to receive multiple streams on a single session for unicast (even though it does for multicast), I think it needs to say that its up to signaling mechanisms to indicate such a limitation. Of course, SDP has no such mechanism.... -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Jan 16 14:30:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21705 for ; Thu, 16 Jan 2003 14:30:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GJkC517647 for avt-archive@odin.ietf.org; Thu, 16 Jan 2003 14:46:12 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GJd9J17281; Thu, 16 Jan 2003 14:39:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GJbDJ16880 for ; Thu, 16 Jan 2003 14:37:13 -0500 Received: from snap.CS.Berkeley.EDU (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21483 for ; Thu, 16 Jan 2003 14:21:28 -0500 (EST) Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.9.3/8.9.3-ZUUL) id LAA17554 for avt@ietf.org; Thu, 16 Jan 2003 11:24:31 -0800 Date: Thu, 16 Jan 2003 11:24:31 -0800 From: John Lazzaro Message-Id: <200301161924.LAA17554@snap.CS.Berkeley.EDU> To: avt@ietf.org Subject: Re: [AVT] Final edits to RTP spec and A/V profile Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , > Jonathan Rosenberg writes: > > I suspect each unicast connection is treated as a separate RTP session. Sfront currently ships with multi-unicast support, and the implementation is a hybrid of both approaches. A sender does sent the same RTP packet to each receiver, and in this way everything but the lowest layers of the stack believes a true multicast session is underway. Sfront needs to do this, because it lets a sender create and maintain one recovery journal system for all receivers, a big efficiency improvement over N recovery journal systems. However, a receiver doesn't send RTCP RR packets describing a sent stream to all other participants, only to the original sender. This is for efficiency ... BTW, Appendix B of the MWPP guidelines document: http://www.ietf.org/internet-drafts/draft-lazzaro-avt-mwpp-coding-guidelines-01.txt Covers this topic in detail ... ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro ------------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Jan 16 22:05:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00726 for ; Thu, 16 Jan 2003 22:05:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0H3LE013896 for avt-archive@odin.ietf.org; Thu, 16 Jan 2003 22:21:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0H3KCJ13845; Thu, 16 Jan 2003 22:20:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0H3I6J13749 for ; Thu, 16 Jan 2003 22:18:06 -0500 Received: from snap.CS.Berkeley.EDU (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00699 for ; Thu, 16 Jan 2003 22:02:11 -0500 (EST) Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.9.3/8.9.3-ZUUL) id TAA19442 for avt@ietf.org; Thu, 16 Jan 2003 19:05:13 -0800 Date: Thu, 16 Jan 2003 19:05:13 -0800 From: John Lazzaro Message-Id: <200301170305.TAA19442@snap.CS.Berkeley.EDU> To: avt@ietf.org Subject: [AVT] draft-lazzaro-avt-rtp-framing-contrans-00.txt ... Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Hi everyone, Just sent the first draft of the RTP over TCP I-D off to internet-drafts@ietf.org. You can download a copy now from: http://www.cs.berkeley.edu/~lazzaro/sa/pubs/txt/current-contrans.txt See the abstract below for more details. I took the approach of documenting one of the two framing methods that had support on the list during the December discussions, and writing a full I-D for that method (the legacy RTP method). --- INTERNET-DRAFT John Lazzaro January 16, 2003 CS Division Expires: July 16, 2003 UC Berkeley Framing RTP and RTCP Packets over Connection-Oriented Transport Abstract This memo defines a method for framing Real Time Protocol (RTP) and Real Time Control Protocol (RTCP) packets onto connection-oriented transport (such as TCP and TLS). We show how a session description may specify the use of the framing method. We also show how to use the framing method with the Real Time Streaming Protocol (RTSP). ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro ------------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Jan 17 10:31:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26062 for ; Fri, 17 Jan 2003 10:31:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0HFkts08578 for avt-archive@odin.ietf.org; Fri, 17 Jan 2003 10:46:55 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HFjpJ08447; Fri, 17 Jan 2003 10:45:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HFgwJ08326 for ; Fri, 17 Jan 2003 10:42:58 -0500 Received: from gorilla.mchh.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25758 for ; Fri, 17 Jan 2003 10:26:46 -0500 (EST) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id QAA06720; Fri, 17 Jan 2003 16:30:04 +0100 (MET) Received: from mchh168e.mch4.siemens.de ([139.21.130.175]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id QAA23553; Fri, 17 Jan 2003 16:30:06 +0100 (MET) Received: by mchh168e.mch4.siemens.de with Internet Mail Service (5.5.2653.19) id ; Fri, 17 Jan 2003 16:30:06 +0100 Message-ID: From: Euchner Martin ICN M SR 3 To: "'Stephen Casner'" , Allison Mankin , "Steven M. Bellovin" , Euchner Martin ICN M SR 3 Cc: AVT WG Date: Fri, 17 Jan 2003 16:30:01 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [AVT] SRTP security concerns: Status of resolution? Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Dear all, it has been quite silent regarding the pending resolution of the SRTP security concerns as raised during the IETF#55 Atlanta AVT WG meeting. Some discussion took place during the meeting, but seemed to have ceased somehow after IETF#55 closed. Since then, I haven't seen any progress. What is the current status of discussion? Where are we at the moment? In the interest of making progress in these matters, I've attached my notes from the past AVT meeting, summarizing what I've seen on Eric's slides and what I've heard in the discussion. I hope that this captures most of the crucial stuff. * SRTP has unusual design features. * AES counter mode has no integrity protection; thus it is easy to make predictable changes for known-plaintext; especially known syntax. Therefore there is a need for a MAC. * The default MAC is only 32 bits, this is felt as too weak security. Question is if 80 bit HMAC should be mandated. * The "no MAC" option is seen very problematic. * Threats are seen: modified message streams; forged traffic; big problems for other kinds of media. * Latency (i.e. delay): MACs (or IVs) consume bandwidth. * Wireless channels are often noisy; this would result in total packet loss with integrity. As options for resolution two options are envisaged: 1.) FEC after encryption/MAC (not a perfect solution). 2.) Two sets of transforms: * Partial integrity for wireless voice, mandatory integrity protection over control data only. * Full integrity for everything else; an 80 bit MAC should be fine and this should be the default. I believe the latter two issues deserve more clarification and further discussion. It also became obvious that the text should provide some strong security warning for the weaker security mechanisms and should give due considerations of the costs of security in payload (when to turn security off?). Considerations should be given on the environment with some analysis/impact. Do I miss anything? With kind regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Rapporteur Q.G/SG16 | Martin Euchner Phone: +49 89 722 55790 | Siemens AG.....................Fax : +49 89 722 62366 | ICN M SR 3 mailto:Martin.Euchner@siemens.com | mailto:martin.euchner@ties.itu.int | Hofmannstr. 51 Intranet: http://intranet.icn.siemens.de/marketing/cs27/topics/security/ | D-81359 Muenchen Internet: http://www.siemens.de/ | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Stephen Casner [mailto:casner@acm.org] Sent: Thursday, December 19, 2002 12:43 AM To: Allison Mankin; Steven M. Bellovin Cc: AVT WG Subject: [AVT] SRTP MAC question Allison and Steve, In the minutes of the AVT meeting in Atlanta, which were prepared from notes taken during the meeting and a review of the audio tape, we noted the following statements from you as part of the discussion of SRTP security considerations: Mark Baugher asked if changing the default mandatory transforms, adding CBC mode as an option, would satisfy concerns? Steve Bellovin answered that, assuming you meet requirements for safely using counter mode, there is no strong need for CBC mode; the MAC is much more critical. Allison commented that the draft is intended to be general purpose, but is optimized for cellular use. The default transform needs to be suitable for the general case, with a non-optional MAC if counter mode is used, and justification why weaker options are present for cellular operation. I would like to get a clarification of your position: Independent of what transforms are chosen as the defaults, are you saying that if counter mode is selected as the cypher for a particular application, then a MAC MUST also be used? And if so, do you mean to impose a minimum size for the MAC? Note that if your answer is yes, we have a conflict with what a number of people hold as the requirements for some applications. -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Jan 20 13:56:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27279 for ; Mon, 20 Jan 2003 13:56:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0KJDj507535 for avt-archive@odin.ietf.org; Mon, 20 Jan 2003 14:13:45 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KJCrJ07502; Mon, 20 Jan 2003 14:12:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KJ8IJ07351 for ; Mon, 20 Jan 2003 14:08:18 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27073; Mon, 20 Jan 2003 13:50:34 -0500 (EST) Message-Id: <200301201850.NAA27073@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , avt@ietf.org From: The IESG Date: Mon, 20 Jan 2003 13:50:34 -0500 Subject: [AVT] Protocol Action: RTP Payload Format for SMPTE 292M Video to Proposed Standard Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , The IESG has approved the Internet-Draft 'RTP Payload Format for SMPTE 292M Video' as a Proposed Standard. This document is the product of the Audio/Video Transport Working Group. The IESG contact persons are Scott Bradner and Allison Mankin. Technical Summary This document specifies a RTP payload format for encapsulating uncompressed High Definition Television (HDTV) as defined by the Society of Motion Picture and Television Engineers (SMPTE) standard, SMPTE 292M. SMPTE is the main standardizing body in the motion imaging industry and the SMPTE 292M standard defines a bit-serial digital interface for local area HDTV transport and defines a universal medium of interchange for uncompressed High Definition Television (HDTV) between various types of video equipment (cameras, encoders, VTRs, etc.). SMPTE 292M stipulates that the source data be in 10 bit words and the total data rate be either 1.485 Gbps or 1.485/1.001 Gbps. The use of a dedicated serial interconnect is appropriate in a studio environment, but it is desirable to leverage the widespread availability of high bandwidth IP connectivity to allow efficient wide area delivery of area delivery of SMPTE 292M format content. This memo defines a way to do so. Working Group Summary The AVT working group supported publication of this document on the standards track. Protocol Quality This document was reviewed for the IESG by Scott Bradner. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Jan 20 15:09:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29332 for ; Mon, 20 Jan 2003 15:09:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0KKQos11563 for avt-archive@odin.ietf.org; Mon, 20 Jan 2003 15:26:50 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KKQEJ11543; Mon, 20 Jan 2003 15:26:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KKOYJ11488 for ; Mon, 20 Jan 2003 15:24:34 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29291; Mon, 20 Jan 2003 15:06:49 -0500 (EST) Message-Id: <200301202006.PAA29291@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , avt@ietf.org From: The IESG Date: Mon, 20 Jan 2003 15:06:49 -0500 Subject: [AVT] CORRECTION W/ RFC EDITOR NOTE: Protocol Action: RTP Payload Format for SMPTE 292M Video to Proposed Standard Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , **PLEASE NOTE RFC EDITOR NOTE.** The IESG has approved the Internet-Draft 'RTP Payload Format for SMPTE 292M Video' as a Proposed Standard. This document is the product of the Audio/Video Transport Working Group. The IESG contact persons are Scott Bradner and Allison Mankin. Technical Summary This document specifies a RTP payload format for encapsulating uncompressed High Definition Television (HDTV) as defined by the Society of Motion Picture and Television Engineers (SMPTE) standard, SMPTE 292M. SMPTE is the main standardizing body in the motion imaging industry and the SMPTE 292M standard defines a bit-serial digital interface for local area HDTV transport and defines a universal medium of interchange for uncompressed High Definition Television (HDTV) between various types of video equipment (cameras, encoders, VTRs, etc.). SMPTE 292M stipulates that the source data be in 10 bit words and the total data rate be either 1.485 Gbps or 1.485/1.001 Gbps. The use of a dedicated serial interconnect is appropriate in a studio environment, but it is desirable to leverage the widespread availability of high bandwidth IP connectivity to allow efficient wide area delivery of area delivery of SMPTE 292M format content. This memo defines a way to do so. Working Group Summary The AVT working group supported publication of this document on the standards track. Protocol Quality This document was reviewed for the IESG by Scott Bradner. RFC Editor: please make the following changes before publishing this ID Section 6, 1st paragraph OLD: RFC1889 recommends transmission of RTCP packets every 5 seconds or at a reduced minimum in seconds of 360 divided by the session bandwidth in kilobits/second. At 1.485 Gbps the reduced minimum interval computes to 0.2ms or 4028 packets per second. NEW: RTCP SHOULD be used as specified in RFC1889[3], which specifies two limits on the RTCP packet rate: RTCP bandwidth should be limited to 5% of the data rate, and the minimum for the average of the randomized intervals between RTCP packets should be 5 seconds. Considering the high data rate of this payload format, the minimum interval is the governing factor in this case. Section 13, 3rd and 4th paragraphs: OLD: [3] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", IETF, Work in Progress (draft-ietf-avt-rtp-new-11.txt) [4] H. Schulzrinee and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", IETF, Work in progress, (draft-ietf-avt-profile-new-12.txt). NEW: [3] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", IETF, January 1996, RFC1889. [4] H. Schulzrinne and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", IETF, January 1996, RFC1890. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Jan 20 21:31:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07277 for ; Mon, 20 Jan 2003 21:31:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0L2muv01917 for avt-archive@odin.ietf.org; Mon, 20 Jan 2003 21:48:56 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0L2lsJ01876; Mon, 20 Jan 2003 21:47:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0L2kZJ01826 for ; Mon, 20 Jan 2003 21:46:35 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07225 for ; Mon, 20 Jan 2003 21:28:45 -0500 (EST) Received: from localhost ([127.0.0.1] helo=psg.com ident=mankin) by psg.com with esmtp (Exim 3.36 #2) id 18aoCr-000NW2-00; Mon, 20 Jan 2003 18:32:05 -0800 To: casner@acm.org, avt@ietf.org Cc: smb@research.att.com, mankin@psg.com, ekr@rtfm.com Reply-To: mankin@psg.com Date: Mon, 20 Jan 2003 18:32:04 -0800 From: Allison Mankin Message-Id: Subject: [AVT] Re: SRTP MAC question Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Chairs, SRTP authors, AVT WG group, Steve Casner asked me and Steve Bellovin for some written clarifications of our remarks about SRTP from Atlanta. The holidays and some doublechecking slowed us down, but now here are specific responses to the questions Steve posed in that message. (I've appended the original mail, after a security analysis that was prepared by Eric Rescorla for the Security and Transport Areas). The conclusion of Eric Rescorla and Steve Bellovin is that it is not necessary to add a CBC mode to SRTP. But they did conclude that there are very limited circumstances in which the counter mode may be used without a MAC of at least 80 bits, and that applications to be used without a MAC must have accompanying information with specific data about the error frequency in the channel that justifies this usage. So as Area Director, I would like to see such a description added to the current case of SRTP for cellular voice in the i-d being revised. Instead of it being "up to the user's security profile to request authentication" (Section 9.5), it should be there that the MAC is chosen not to be used, and the Security Considerations of this document should provide data justifying the choice. For other profiles without the error rate, the Security advisors have asked for an 80-bit MAC to be the default. Steve Casner's mail mentions that a number of people hold avoidance of use of a MAC as a requirement for some applications. What I request here allows them to have their requirement, it just asks them to substantiate it. In addition, it takes the outcome of the security analysis and ensures that the higher risk of easy integrity attacks is not accidentally imposed by default on applications that may not have the tradeoff made by the SRTP design as written currently. Allison (for myself, Steve Bellovin and Eric Rescorla) ----------- Security Summary of SRTP Discussion by Eric Rescorla Following the AVT WG meeting in Atlanta, a number of people asked me to write up a summary of what Allison, Steve, and I said in the session. The basic principle is that one should attempt to secure traffic to the greatest extent practical. This doesn't mean that you have to apply the absolute possible maximum level of security but it does mean that you have to justify why you didn't do so. This brings us to the issue at hand, namely that the integrity protection in SRTP is a lot weaker than what's generally considered appropriate in Internet protocols. To review, SRTP offers three forms of integrity protection: (1) None (2) 32-bit MAC (3) 128-bit MAC This is made somewhat additionally scary by the fact that it uses CTR mode, which we know to be susceptible to easy integrity attacks. The authors provided a number of qualitative arguments for why this was necessary, generally hinging on performance. Unfortunately, performance decisions are generally quantitative and numbers have been pretty thin on the ground. There seemed to be wide acceptance that a stronger transform should be used for most Internet-style channels that have high capacity and low BER. The debate, as far as I can tell, centers on what's appropriate for constrained and noisy channels (primarily wireless). So, what's needed here is two things: (1) Require some stronger (96-bit? 80-bit?) MAC for general Internet-wide use. (2) Write a Security Considerations section that explains why a lower level of integrity protection is appropriate/required for certain constrained channels. Speaking solely for myself, what I'd like to see is calculations of: (1) The expected capacity of the channel. (2) The expected bit error rate of the channel. (3) The number of damaged packets. (4) The amount of FEC (and corresponding reduction in capacity) required to achieve any given packet loss rate. (5) The effect that this reduction in channel capacity would have on applications. (6) The possible attacks (and their severity) that would be allowed by this design. The idea here is that this analysis would convince the reader that this set of tradeoffs was the right ones. ----------- Forwarded message ---------- Date: Wed, 18 Dec 2002 15:43:07 -0800 (PST) From: Stephen Casner To: Allison Mankin , "Steven M. Bellovin" cc: AVT WG Subject: [AVT] SRTP MAC question Allison and Steve, In the minutes of the AVT meeting in Atlanta, which were prepared from notes taken during the meeting and a review of the audio tape, we noted the following statements from you as part of the discussion of SRTP security considerations: Mark Baugher asked if changing the default mandatory transforms, adding CBC mode as an option, would satisfy concerns? Steve Bellovin answered that, assuming you meet requirements for safely using counter mode, there is no strong need for CBC mode; the MAC is much more critical. Allison commented that the draft is intended to be general purpose, but is optimized for cellular use. The default transform needs to be suitable for the general case, with a non-optional MAC if counter mode is used, and justification why weaker options are present for cellular operation. I would like to get a clarification of your position: Independent of what transforms are chosen as the defaults, are you saying that if counter mode is selected as the cypher for a particular application, then a MAC MUST also be used? And if so, do you mean to impose a minimum size for the MAC? Note that if your answer is yes, we have a conflict with what a number of people hold as the requirements for some applications. -- Steve ------- End of Forwarded Message _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Jan 21 01:06:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12301 for ; Tue, 21 Jan 2003 01:06:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0L6Ngt12500 for avt-archive@odin.ietf.org; Tue, 21 Jan 2003 01:23:42 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0L6MrJ12466; Tue, 21 Jan 2003 01:22:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0L376J02552 for ; Mon, 20 Jan 2003 22:07:06 -0500 Received: from mail-blue.research.att.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07715 for ; Mon, 20 Jan 2003 21:49:16 -0500 (EST) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-blue.research.att.com (Postfix) with ESMTP id 892DC4CEFE; Mon, 20 Jan 2003 21:52:40 -0500 (EST) Received: from berkshire.research.att.com (postal.research.att.com [135.207.23.30]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id VAA26297; Mon, 20 Jan 2003 21:52:38 -0500 (EST) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 925637B4D; Mon, 20 Jan 2003 21:52:37 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: mankin@psg.com Cc: casner@acm.org, avt@ietf.org, ekr@rtfm.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 20 Jan 2003 21:52:37 -0500 Message-Id: <20030121025237.925637B4D@berkshire.research.att.com> Subject: [AVT] Re: SRTP MAC question Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , In message , Allison Mankin writes: > What I request >here allows them to have their requirement, it just asks them to >substantiate it. In addition, it takes the outcome of the security >analysis and ensures that the higher risk of easy integrity attacks is >not accidentally imposed by default on applications that may not have >the tradeoff made by the SRTP design as written currently. Put another way -- and you can quote me on this -- I'm quite willing to accept nominally-insecure options under the following circumstances: *) There is a secure option described in the RFC; *) The RFC clearly delineates the circumstances under which the less-secure option is advisable; *) There is a clear, explicit analysis to show why it's needed in some circumstances; *) There's a thorough explanation of the risks incurred by opting for this choice. In other words -- make sure implementors who aren't security experts understands the cost-benefit tradeoff. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book) _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Jan 21 04:46:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24571 for ; Tue, 21 Jan 2003 04:46:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0LA4O903084 for avt-archive@odin.ietf.org; Tue, 21 Jan 2003 05:04:24 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LA2hJ03025; Tue, 21 Jan 2003 05:02:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LA1rJ02987 for ; Tue, 21 Jan 2003 05:01:53 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24556 for ; Tue, 21 Jan 2003 04:43:54 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0L9lIAv013918; Tue, 21 Jan 2003 10:47:18 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZGN31A40; Tue, 21 Jan 2003 10:47:18 +0100 Message-ID: <3E2D1726.2030405@era.ericsson.se> Date: Tue, 21 Jan 2003 10:47:18 +0100 X-Sybari-Trust: d88679f5 9ffcebbb cd1bde24 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: avt@ietf.org, Scott Bradner Subject: Re: [AVT] CORRECTION W/ RFC EDITOR NOTE: Protocol Action: RTP Payload Format for SMPTE 292M Video to Proposed Standard References: <200301202006.PAA29291@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, I reacted on the below in the RFC editors note that the IESG wrote. The IESG wrote: >**PLEASE NOTE RFC EDITOR NOTE.** >RFC Editor: please make the following changes before publishing this ID > > Section 6, 1st paragraph > OLD: > > RFC1889 recommends transmission of RTCP packets every 5 seconds or at a > reduced minimum in seconds of 360 divided by the session bandwidth in > kilobits/second. At 1.485 Gbps the reduced minimum interval computes to > 0.2ms or 4028 packets per second. > > NEW: > > RTCP SHOULD be used as specified in RFC1889[3], which specifies two > limits on the RTCP packet rate: RTCP bandwidth should be limited to 5% > of the data rate, and the minimum for the average of the randomized > intervals between RTCP packets should be 5 seconds. Considering the > high data rate of this payload format, the minimum interval is the > governing factor in this case. > > Section 13, 3rd and 4th paragraphs: > OLD: > > [3] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, "RTP: A > Transport Protocol for Real-Time Applications", IETF, Work in > Progress (draft-ietf-avt-rtp-new-11.txt) > > [4] H. Schulzrinee and S. Casner, "RTP Profile for Audio and Video > Conferences with Minimal Control", IETF, Work in progress, > (draft-ietf-avt-profile-new-12.txt). > > NEW: > > [3] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, "RTP: A > Transport Protocol for Real-Time Applications", IETF, January 1996, > RFC1889. > > [4] H. Schulzrinne and S. Casner, "RTP Profile for Audio and > Video Conferences with Minimal Control", IETF, January 1996, > RFC1890. > > I know that the referenced rule in the old text relies on one of the updates in the RTP spec about alternative minimal packet distances. So if it needs to be published now it can't have the old text. However I think that using the standard 5 seconds rule is rather useless from a RTCP usage point of view. In a payload format for sending 1.5 Gbit video data per second, a lot of packets will be sent during 5 seconds. So the intention of the SHOULD in the new text seems to me, to be not followed at all. In fact it seems that is should be actually be followed by recommendation to use a shorter minimal interval. But that interval shall not be shorter than what 360*1000/bitrate would give. So I question if this really is a good edit. Would it not be better to clearly point out that another minimal interval than 5 seconds is recommended to be used. Either through a new text not relying on the updated RTP spec or actually refer to the new spec and let the publication hang until RTP as draft standard is published. I guess that people actually going to use this format should give their opinion. From a RTP usage perspective I think this format is a case that really needs another minimal packet interval than 5 seconds and should not be published with the proposed new text. Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Jan 21 12:26:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05965 for ; Tue, 21 Jan 2003 12:26:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0LHhwK02416 for avt-archive@odin.ietf.org; Tue, 21 Jan 2003 12:43:58 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LHgNJ02240; Tue, 21 Jan 2003 12:42:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LHbIJ01678 for ; Tue, 21 Jan 2003 12:37:18 -0500 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05738 for ; Tue, 21 Jan 2003 12:19:09 -0500 (EST) Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id h0LHMVPg022175; Tue, 21 Jan 2003 09:22:31 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AAR90113; Tue, 21 Jan 2003 09:22:33 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA01297; Tue, 21 Jan 2003 09:22:33 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15917.33241.508882.609679@thomasm-u1.cisco.com> Date: Tue, 21 Jan 2003 09:22:33 -0800 (PST) To: "Steven M. Bellovin" Cc: mankin@psg.com, casner@acm.org, avt@ietf.org, ekr@rtfm.com Subject: [AVT] Re: SRTP MAC question In-Reply-To: <20030121025237.925637B4D@berkshire.research.att.com> References: <20030121025237.925637B4D@berkshire.research.att.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit This seems completely reasonable to me. Especially about the part re security novices. Mike Steven M. Bellovin writes: > In message , Allison Mankin writes: > > What I request > > >here allows them to have their requirement, it just asks them to > >substantiate it. In addition, it takes the outcome of the security > >analysis and ensures that the higher risk of easy integrity attacks is > >not accidentally imposed by default on applications that may not have > >the tradeoff made by the SRTP design as written currently. > > Put another way -- and you can quote me on this -- I'm quite willing > to accept nominally-insecure options under the following circumstances: > > *) There is a secure option described in the RFC; > > *) The RFC clearly delineates the circumstances under which the > less-secure option is advisable; > > *) There is a clear, explicit analysis to show why it's needed > in some circumstances; > > *) There's a thorough explanation of the risks incurred by > opting for this choice. > > In other words -- make sure implementors who aren't security experts > understands the cost-benefit tradeoff. > > > --Steve Bellovin, http://www.research.att.com/~smb (me) > http://www.wilyhacker.com (2nd edition of "Firewalls" book) > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Jan 22 10:53:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28716 for ; Wed, 22 Jan 2003 10:53:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0MGBRY32435 for avt-archive@odin.ietf.org; Wed, 22 Jan 2003 11:11:27 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MGAaJ32315; Wed, 22 Jan 2003 11:10:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MG8DJ32184 for ; Wed, 22 Jan 2003 11:08:13 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28586; Wed, 22 Jan 2003 10:49:38 -0500 (EST) Message-Id: <200301221549.KAA28586@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: avt@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 22 Jan 2003 10:49:38 -0500 Subject: [AVT] I-D ACTION:draft-ramalho-rgl-rtpformat-00.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : MPLS Inter-AS Traffic Engineering requirements Author(s) : M. Ramalho Filename : draft-ramalho-rgl-rtpformat-00.txt Pages : 0 Date : 2002-12-6 This document describes the RTP payload format for the RGL Codec described in draft-ramalho-rgl-desc-00.txt [4] and documented fully at www.vovida.org [9]. The necessary details for the use of the RGL codec with SDP are included in this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ramalho-rgl-rtpformat-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ramalho-rgl-rtpformat-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ramalho-rgl-rtpformat-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-22105814.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ramalho-rgl-rtpformat-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ramalho-rgl-rtpformat-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-22105814.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Jan 22 11:22:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29704 for ; Wed, 22 Jan 2003 11:22:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0MGete02013 for avt-archive@odin.ietf.org; Wed, 22 Jan 2003 11:40:55 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MGeKJ01985; Wed, 22 Jan 2003 11:40:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MGdpJ01931 for ; Wed, 22 Jan 2003 11:39:51 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29637; Wed, 22 Jan 2003 11:21:15 -0500 (EST) Message-Id: <200301221621.LAA29637@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: avt@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 22 Jan 2003 11:21:15 -0500 Subject: [AVT] I-D ACTION:draft-ramalho-rgl-rtpformat-00.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : RTP Payload Format for RGL Codec Author(s) : M. Ramalho Filename : draft-ramalho-rgl-rtpformat-00.txt Pages : 18 Date : 2002-12-6 This document describes the RTP payload format for the RGL Codec described in draft-ramalho-rgl-desc-00.txt [4] and documented fully at www.vovida.org [9]. The necessary details for the use of the RGL codec with SDP are included in this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ramalho-rgl-rtpformat-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ramalho-rgl-rtpformat-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ramalho-rgl-rtpformat-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-22113831.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ramalho-rgl-rtpformat-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ramalho-rgl-rtpformat-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-22113831.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Jan 22 17:16:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09486 for ; Wed, 22 Jan 2003 17:16:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0MLuw722433 for avt-archive@odin.ietf.org; Wed, 22 Jan 2003 16:56:58 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MLtAJ22328; Wed, 22 Jan 2003 16:55:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MLrEJ22263 for ; Wed, 22 Jan 2003 16:53:14 -0500 Received: from hafez.nge.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08091 for ; Wed, 22 Jan 2003 16:34:30 -0500 (EST) Received: from hafez (ladan@localhost) by hafez.nge.isi.edu (8.11.6/8.11.6) with ESMTP id h0MLbvO08172; Wed, 22 Jan 2003 16:37:57 -0500 Message-Id: <200301222137.h0MLbvO08172@hafez.nge.isi.edu> To: avt@ietf.org, Scott Bradner Subject: Re: [AVT] CORRECTION W/ RFC EDITOR NOTE: Protocol Action: RTP Payload Format for SMPTE 292M Video to Proposed Standard In-Reply-To: Your message of "Tue, 21 Jan 2003 10:47:18 +0100." <3E2D1726.2030405@era.ericsson.se> Date: Wed, 22 Jan 2003 16:37:57 -0500 From: Ladan Gharai Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Hello Magnus: Please see notes inline. Ladan > Hi, > > I reacted on the below in the RFC editors note that the IESG wrote. > > > The IESG wrote: > > >**PLEASE NOTE RFC EDITOR NOTE.** > >RFC Editor: please make the following changes before publishing this ID > > > > Section 6, 1st paragraph > > OLD: > > > > RFC1889 recommends transmission of RTCP packets every 5 seconds or at a > > reduced minimum in seconds of 360 divided by the session bandwidth in > > kilobits/second. At 1.485 Gbps the reduced minimum interval computes to > > 0.2ms or 4028 packets per second. > > > > NEW: > > > > RTCP SHOULD be used as specified in RFC1889[3], which specifies two > > limits on the RTCP packet rate: RTCP bandwidth should be limited to 5% > > of the data rate, and the minimum for the average of the randomized > > intervals between RTCP packets should be 5 seconds. Considering the > > high data rate of this payload format, the minimum interval is the > > governing factor in this case. > > > > Section 13, 3rd and 4th paragraphs: > > OLD: > > > > [3] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, "RTP: A > > Transport Protocol for Real-Time Applications", IETF, Work in > > Progress (draft-ietf-avt-rtp-new-11.txt) > > > > [4] H. Schulzrinee and S. Casner, "RTP Profile for Audio and Video > > Conferences with Minimal Control", IETF, Work in progress, > > (draft-ietf-avt-profile-new-12.txt). > > > > NEW: > > > > [3] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, "RTP: A > > Transport Protocol for Real-Time Applications", IETF, January 1996, > > RFC1889. > > > > [4] H. Schulzrinne and S. Casner, "RTP Profile for Audio and > > Video Conferences with Minimal Control", IETF, January 1996, > > RFC1890. > > > > > > I know that the referenced rule in the old text relies on one of the > updates in the RTP spec about alternative minimal packet distances. So > if it needs to be published now it can't have the old text. However I > think that using the standard 5 seconds rule is rather useless from a > RTCP usage point of view. In a payload format for sending 1.5 Gbit video > data per second, a lot of packets will be sent during 5 seconds. So the > intention of the SHOULD in the new text seems to me, to be not followed > at all. In fact it seems that is should be actually be followed by > recommendation to use a shorter minimal interval. But that interval > shall not be shorter than what 360*1000/bitrate would give. > > So I question if this really is a good edit. Would it not be better to > clearly point out that another minimal interval than 5 seconds is > recommended to be used. Either through a new text not relying on the > updated RTP spec or actually refer to the new spec and let the > publication hang until RTP as draft standard is published. > > I guess that people actually going to use this format should give their > opinion. From a RTP usage perspective I think this format is a case that > really needs another minimal packet interval than 5 seconds and should > not be published with the proposed new text. The average five second interval is sufficient for the purposes of keeping track of the cumulative number of packets lost and the sender's octet count, from the draft: "It should be noted that the sender's octet count in SR packets wraps around in 23 seconds, and that the cumulative number of packets lost wraps around in 93 seconds. This means these two fields cannot accurately represent octet count and number of packets lost since the beginning of transmission, as defined in RFC1889. Therefore for network monitoring purposes or any other application which requires the sender's octet count and the cumulative number of packets lost since the beginning of transmission, the application itself must keep track of the number of rollovers of these fields via a counter." However, should an application require a finer interval for the RTCP reports, it can do so as specified in the new RTP profile, (as would any other RTP application). > > Regards > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research ERA/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se > > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Jan 23 03:16:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29761 for ; Thu, 23 Jan 2003 03:16:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0N8Z0r04577 for avt-archive@odin.ietf.org; Thu, 23 Jan 2003 03:35:00 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0N8XgJ04548; Thu, 23 Jan 2003 03:33:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0N8VBJ04461 for ; Thu, 23 Jan 2003 03:31:11 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29678 for ; Thu, 23 Jan 2003 03:12:13 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0N8FdAv017983; Thu, 23 Jan 2003 09:15:39 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZGN3T0L6; Thu, 23 Jan 2003 09:15:39 +0100 Message-ID: <3E2FA4AB.2040109@era.ericsson.se> Date: Thu, 23 Jan 2003 09:15:39 +0100 X-Sybari-Trust: 26ed03b3 9ffcebbb a34baef4 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ladan Gharai CC: avt@ietf.org, Scott Bradner Subject: Re: [AVT] CORRECTION W/ RFC EDITOR NOTE: Protocol Action: RTP Payload Format for SMPTE 292M Video to Proposed Standard References: <200301222137.h0MLbvO08172@hafez.nge.isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, Okay, I understand. My main concern was that it is kind of step backwards in the goal to have reasonable reporting intervals for RTCP traffic. But I guess that this problem is solved as soon as AVPF is finished and published. Best Regards Magnus Ladan Gharai wrote: >Hello Magnus: Please see notes inline. > >Ladan > > > > Hi, > > > > I reacted on the below in the RFC editors note that the IESG wrote. > > > > > > The IESG wrote: > > > > >**PLEASE NOTE RFC EDITOR NOTE.** > > >RFC Editor: please make the following changes before publishing this ID > > > > > > Section 6, 1st paragraph > > > OLD: > > > > > > RFC1889 recommends transmission of RTCP packets every 5 seconds or at a > > > reduced minimum in seconds of 360 divided by the session bandwidth in > > > kilobits/second. At 1.485 Gbps the reduced minimum interval computes to > > > 0.2ms or 4028 packets per second. > > > > > > NEW: > > > > > > RTCP SHOULD be used as specified in RFC1889[3], which specifies two > > > limits on the RTCP packet rate: RTCP bandwidth should be limited to 5% > > > of the data rate, and the minimum for the average of the randomized > > > intervals between RTCP packets should be 5 seconds. Considering the > > > high data rate of this payload format, the minimum interval is the > > > governing factor in this case. > > > > > > Section 13, 3rd and 4th paragraphs: > > > OLD: > > > > > > [3] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, "RTP: A > > > Transport Protocol for Real-Time Applications", IETF, Work in > > > Progress (draft-ietf-avt-rtp-new-11.txt) > > > > > > [4] H. Schulzrinee and S. Casner, "RTP Profile for Audio and Video > > > Conferences with Minimal Control", IETF, Work in progress, > > > (draft-ietf-avt-profile-new-12.txt). > > > > > > NEW: > > > > > > [3] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, "RTP: A > > > Transport Protocol for Real-Time Applications", IETF, January 1996, > > > RFC1889. > > > > > > [4] H. Schulzrinne and S. Casner, "RTP Profile for Audio and > > > Video Conferences with Minimal Control", IETF, January 1996, > > > RFC1890. > > > > > > > > > > I know that the referenced rule in the old text relies on one of the > > updates in the RTP spec about alternative minimal packet distances. So > > if it needs to be published now it can't have the old text. However I > > think that using the standard 5 seconds rule is rather useless from a > > RTCP usage point of view. In a payload format for sending 1.5 Gbit video > > data per second, a lot of packets will be sent during 5 seconds. So the > > intention of the SHOULD in the new text seems to me, to be not followed > > at all. In fact it seems that is should be actually be followed by > > recommendation to use a shorter minimal interval. But that interval > > shall not be shorter than what 360*1000/bitrate would give. > > > > So I question if this really is a good edit. Would it not be better to > > clearly point out that another minimal interval than 5 seconds is > > recommended to be used. Either through a new text not relying on the > > updated RTP spec or actually refer to the new spec and let the > > publication hang until RTP as draft standard is published. > > > > I guess that people actually going to use this format should give their > > opinion. From a RTP usage perspective I think this format is a case that > > really needs another minimal packet interval than 5 seconds and should > > not be published with the proposed new text. > > The average five second interval is sufficient for the purposes of > keeping track of the cumulative number of packets lost and the sender's > octet count, from the draft: > > "It should be noted that the sender's octet count in SR packets wraps > around in 23 seconds, and that the cumulative number of packets lost > wraps around in 93 seconds. This means these two fields cannot accurately > represent octet count and number of packets lost since the beginning of > transmission, as defined in RFC1889. Therefore for network monitoring > purposes or any other application which requires the sender's octet count > and the cumulative number of packets lost since the beginning of > transmission, the application itself must keep track of the number of > rollovers of these fields via a counter." > > However, should an application require a finer interval for the RTCP > reports, it can do so as specified in the new RTP profile, (as would any > other RTP application). > > > > > Regards > > > > Magnus Westerlund > > > > Multimedia Technologies, Ericsson Research ERA/TVA/A > > ---------------------------------------------------------------------- > > Ericsson AB | Phone +46 8 4048287 > > Torshamsgatan 23 | Fax +46 8 7575550 > > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se > > > > > > > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www1.ietf.org/mailman/listinfo/avt > >_______________________________________________ >Audio/Video Transport Working Group >avt@ietf.org >https://www1.ietf.org/mailman/listinfo/avt > > > -- Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Jan 23 11:36:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12550 for ; Thu, 23 Jan 2003 11:36:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0NGt6u06692 for avt-archive@odin.ietf.org; Thu, 23 Jan 2003 11:55:06 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NGs7J06594; Thu, 23 Jan 2003 11:54:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NGpPJ06447 for ; Thu, 23 Jan 2003 11:51:25 -0500 Received: from mail.pel.panasonic.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12372 for ; Thu, 23 Jan 2003 11:32:17 -0500 (EST) Received: from atrgreyj (vw1.pel.panasonic.de [10.78.238.55]) by mail.pel.panasonic.de (__________PEL__Mail-Server__________) with SMTP id <0H9600KM1E2B4K@panasonic.de> for avt@ietf.org; Thu, 23 Jan 2003 17:35:00 +0100 (MET) Date: Thu, 23 Jan 2003 17:35:00 +0100 From: Jose Rey To: "Avt@Ietf. Org" Cc: mbaugher@cisco.com, elisabetta.carrara@era.ericsson.se, mcgrew@cisco.com, mats.naslund@era.ericsson.se, karl.norrman@era.ericsson.se, oran@cisco.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 8BIT Subject: [AVT] Security for draft-ietf-avt-rtp-retransmission Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8BIT Hi all, we are doing the final edits to the draft-ietf-avt-rtp-retransmission. We have considered all your comments until the date, but there's something for which we would like to get some feedback on: security. A couple of questions: 1.-As discussed on the list: ... > -----Original Message----- > From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Colin > Perkins > Sent: Friday, January 10, 2003 4:39 AM > To: David.Leon@nokia.com > Cc: avt@ietf.org > Subject: Re: [AVT] Comments on > draft-ietf-avt-rtp-retransmission-04.txt > ...snip... > >> - In section 12, how does this draft affect SRTP? Is it > possible to use > >> the two formats together? > > > >We'll try to draft something on that. My understanding is that the > >retransmission stream is seen as any other stream by SRTP > and there should > >thus be no problem. > > I was not clear if retransmitting packets caused problems for > SRTP; maybe > one of the SRTP authors can comment on any potential security issue? > we don't see any problems (except for SRTCP as below in 2) to use SRTP with RTX since the RTP retransmission packets (with a two byte retransmission payload header) are seen by SRTP as 'normal' RTP packets. Is our assumption correct? 2.-The retransmission payload format needs of the AVPF profile to enable more frequent feedback and to request packets. This profile defines (besides the new timing rules) some general-purpose messages such as ACKs and NACKs and a new RTCP packet format: the early feedback packet, which just contains 1 SR or RR and 1 SDES with just the CNAME. Now, there should be no problem to encrypt/authenticate early packets, according to the SRTP draft: " According to [RFC1889] there is a "recommended" packet format for compound packets. SRTCP MUST be given packets according to that recommendation in the sense that the first part MUST be a sender report or a receiver report. However, the encryption prefix (Section 6.1 of [RFC1889]), a random 32-bit quantity intended to deter known plaintext attacks, MUST NOT be used (see below). " Also there should be no problem to authenticate/encrypt ACKs and NACKs with SRTCP since they are sent in compound RTCP packets starting with an RR or SR packet. Let us know if you disagree with this point. 3.- if a new profile needs be defined, something like "SAVPF", where shall this profile "SAVPF" be specified and registered? wouldn't it be reasonable to do this in the SRTP draft which already registers the "SAVP" profile given that the feedback draft would (presumably) have a similar schedule to the SRTP draft? In this way the question 2. could also be anwered there. 4.- the security section in the retransmission draft already points out the risks of using the same keys across sessions, e.g. two.-time pads and points to the SRTP for solutions. That much is done. Are we missing something else? 5.-It is also pointed out that the Timestamp of the retransmission packets is the same as in the original packets. Since this is random it should be no problem for security. Is this assumption correct? Thanks in advance, José PS: by the way, in draft-05 Rolf Blom's email is the same as Mark Baugher's. Probably a cut&paste error. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Jan 23 15:46:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19634 for ; Thu, 23 Jan 2003 15:46:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0NL4kI24318 for avt-archive@odin.ietf.org; Thu, 23 Jan 2003 16:04:46 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NL2wJ24260; Thu, 23 Jan 2003 16:02:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NL1mJ24223 for ; Thu, 23 Jan 2003 16:01:48 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19600 for ; Thu, 23 Jan 2003 15:42:36 -0500 (EST) Received: from cscoamera13263.cisco.com ([10.21.83.71]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h0NKjxB7004232; Thu, 23 Jan 2003 12:46:00 -0800 (PST) Message-Id: <5.1.1.5.2.20030123123828.09df0cb8@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 23 Jan 2003 12:46:01 -0800 To: Jose Rey From: Mark Baugher Cc: "Avt@Ietf. Org" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0NL1mJ24224 Subject: [AVT] Re: Security for draft-ietf-avt-rtp-retransmission Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit hi Jose, I think that you cannot mention SRTP in this draft because http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-retransmission-04.txt uses the http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcp-feedback-04.txt, which states in its security considerations section "Attacks using false RTCP packets (regular as well as early ones) can be avoided by authenticating all RTCP messages. This can be achieved by using the AVPF profile together with the Secure RTP profile as defined in [17]; as a prerequisite, an appropriate combination of those two profiles (an "SAVPF") needs to be specified. " This is because SRTP is nowhere defined for AVPF. It may be a small problem to adapt SRTP to your RTP profile, but this needs to be done because we only had RTP's AVP in mind when doing SAVP. As http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcp-feedback-04.txt states, something needs to be specified. best regards, Mark At 05:35 PM 1/23/2003 +0100, Jose Rey wrote: >Hi all, > >we are doing the final edits to the draft-ietf-avt-rtp-retransmission. >We have considered all your comments until the date, but there's >something for which we would like to get some feedback on: security. > >A couple of questions: > >1.-As discussed on the list: >... > > -----Original Message----- > > From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Colin > > Perkins > > Sent: Friday, January 10, 2003 4:39 AM > > To: David.Leon@nokia.com > > Cc: avt@ietf.org > > Subject: Re: [AVT] Comments on > > draft-ietf-avt-rtp-retransmission-04.txt > > >...snip... > > > >> - In section 12, how does this draft affect SRTP? Is it > > possible to use > > >> the two formats together? > > > > > >We'll try to draft something on that. My understanding is that the > > >retransmission stream is seen as any other stream by SRTP > > and there should > > >thus be no problem. > > > > I was not clear if retransmitting packets caused problems for > > SRTP; maybe > > one of the SRTP authors can comment on any potential security issue? > > > >we don't see any problems (except for SRTCP as below in 2) to use SRTP >with RTX since the RTP retransmission packets (with a two byte >retransmission payload header) are seen by SRTP as 'normal' RTP packets. >Is our assumption correct? > >2.-The retransmission payload format needs of the AVPF profile to enable >more frequent feedback and to request packets. This profile defines >(besides the new timing rules) some general-purpose messages such as >ACKs and NACKs and a new RTCP packet format: the early feedback packet, >which just contains 1 SR or RR and 1 SDES with just the CNAME. Now, >there should be no problem to encrypt/authenticate early packets, >according to the SRTP draft: > >" > According to [RFC1889] there is a "recommended" packet format for > compound packets. SRTCP MUST be given packets according to that > recommendation in the sense that the first part MUST be a sender > report or a receiver report. However, the encryption prefix (Section > 6.1 of [RFC1889]), a random 32-bit quantity intended to deter known > plaintext attacks, MUST NOT be used (see below). >" > > >Also there should be no problem to authenticate/encrypt ACKs and NACKs >with SRTCP since they are sent in compound RTCP packets starting with an >RR or SR packet. Let us know if you disagree with this point. > > >3.- if a new profile needs be defined, something like "SAVPF", where >shall this profile "SAVPF" be specified and registered? wouldn't it be >reasonable to do this in the SRTP draft which already registers the >"SAVP" profile given that the feedback draft would (presumably) have a >similar schedule to the SRTP draft? In this way the question 2. could >also be anwered there. > >4.- the security section in the retransmission draft already points out >the risks of using the same keys across sessions, e.g. two.-time pads >and points to the SRTP for solutions. That much is done. Are we missing >something else? > >5.-It is also pointed out that the Timestamp of the retransmission >packets is the same as in the original packets. Since this is random it >should be no problem for security. Is this assumption correct? > >Thanks in advance, > > >José > > >PS: by the way, in draft-05 Rolf Blom's email is the same as Mark >Baugher's. Probably a cut&paste error. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Jan 23 17:32:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22427 for ; Thu, 23 Jan 2003 17:32:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0NMpOR31767 for avt-archive@odin.ietf.org; Thu, 23 Jan 2003 17:51:24 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NMn2J31582; Thu, 23 Jan 2003 17:49:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NMl5J31473 for ; Thu, 23 Jan 2003 17:47:05 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22082 for ; Thu, 23 Jan 2003 17:27:38 -0500 (EST) From: David.Leon@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0NMUZB29208 for ; Thu, 23 Jan 2003 16:31:01 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 23 Jan 2003 16:30:23 -0600 Received: from daebe008.NOE.Nokia.com ([172.18.242.238]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 23 Jan 2003 16:29:07 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AVT] Re: Security for draft-ietf-avt-rtp-retransmission Date: Thu, 23 Jan 2003 16:29:06 -0600 Message-ID: <7CA3477F476D7F4FB82F02960B79CEBD01668CFF@daebe008.americas.nokia.com> Thread-Topic: [AVT] Re: Security for draft-ietf-avt-rtp-retransmission Thread-Index: AcLDINTiAUxJPHyBR/KwuRaJnxcyyAADPreQ To: , Cc: X-OriginalArrivalTime: 23 Jan 2003 22:29:07.0575 (UTC) FILETIME=[D7C57870:01C2C32E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0NMl5J31474 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Mark, Thanks for the feedback. Please see answers below. > hi Jose, > I think that you cannot mention SRTP in this draft because > http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-retrans > mission-04.txt > uses the > http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcp-feedba > ck-04.txt, > which states in its security considerations section > "Attacks using false RTCP packets (regular as well as early > ones) can be > avoided by authenticating all RTCP messages. This can be > achieved by using > the AVPF profile together with the Secure RTP profile as > defined in [17]; > as a prerequisite, an appropriate combination of those two > profiles (an > "SAVPF") needs to be specified. " Yes. We are aware that this has to be defined somewhere. This is what Jose meant in point 3 of his mail. >3.- if a new profile needs be defined, something like "SAVPF", where >shall this profile "SAVPF" be specified and registered? wouldn't it be >reasonable to do this in the SRTP draft which already registers the >"SAVP" profile given that the feedback draft would (presumably) have a >similar schedule to the SRTP draft? > > This is because SRTP is nowhere defined for AVPF. It may be a small > problem to adapt SRTP to your RTP profile, but this needs to be done > because we only had RTP's AVP in mind when doing SAVP. What is actually required in order to adapt SRTP for retransmission and AVPF? I think SRTP could be used as it is to encrypt the retransmission packets. As far as SRTCP is concerned, does it need any modifications in order to be able to encrypt the new ACKs and NACKs packets? Thanks, David. > > As > http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcp-feedba > ck-04.txt > states, something needs to be specified. > > best regards, Mark > > At 05:35 PM 1/23/2003 +0100, Jose Rey wrote: > >Hi all, > > > >we are doing the final edits to the > draft-ietf-avt-rtp-retransmission. > >We have considered all your comments until the date, but there's > >something for which we would like to get some feedback on: security. > > > >A couple of questions: > > > >1.-As discussed on the list: > >... > > > -----Original Message----- > > > From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On > Behalf Of Colin > > > Perkins > > > Sent: Friday, January 10, 2003 4:39 AM > > > To: David.Leon@nokia.com > > > Cc: avt@ietf.org > > > Subject: Re: [AVT] Comments on > > > draft-ietf-avt-rtp-retransmission-04.txt > > > > >...snip... > > > > > >> - In section 12, how does this draft affect SRTP? Is it > > > possible to use > > > >> the two formats together? > > > > > > > >We'll try to draft something on that. My understanding > is that the > > > >retransmission stream is seen as any other stream by SRTP > > > and there should > > > >thus be no problem. > > > > > > I was not clear if retransmitting packets caused problems for > > > SRTP; maybe > > > one of the SRTP authors can comment on any potential > security issue? > > > > > > >we don't see any problems (except for SRTCP as below in 2) > to use SRTP > >with RTX since the RTP retransmission packets (with a two byte > >retransmission payload header) are seen by SRTP as 'normal' > RTP packets. > >Is our assumption correct? > > > >2.-The retransmission payload format needs of the AVPF > profile to enable > >more frequent feedback and to request packets. This profile defines > >(besides the new timing rules) some general-purpose messages such as > >ACKs and NACKs and a new RTCP packet format: the early > feedback packet, > >which just contains 1 SR or RR and 1 SDES with just the CNAME. Now, > >there should be no problem to encrypt/authenticate early packets, > >according to the SRTP draft: > > > >" > > According to [RFC1889] there is a "recommended" packet format for > > compound packets. SRTCP MUST be given packets according to that > > recommendation in the sense that the first part MUST be a sender > > report or a receiver report. However, the encryption > prefix (Section > > 6.1 of [RFC1889]), a random 32-bit quantity intended to > deter known > > plaintext attacks, MUST NOT be used (see below). > >" > > > > > >Also there should be no problem to authenticate/encrypt ACKs > and NACKs > >with SRTCP since they are sent in compound RTCP packets > starting with an > >RR or SR packet. Let us know if you disagree with this point. > > > > > >3.- if a new profile needs be defined, something like "SAVPF", where > >shall this profile "SAVPF" be specified and registered? > wouldn't it be > >reasonable to do this in the SRTP draft which already registers the > >"SAVP" profile given that the feedback draft would > (presumably) have a > >similar schedule to the SRTP draft? In this way the question 2. could > >also be anwered there. > > > >4.- the security section in the retransmission draft already > points out > >the risks of using the same keys across sessions, e.g. two.-time pads > >and points to the SRTP for solutions. That much is done. Are > we missing > >something else? > > > >5.-It is also pointed out that the Timestamp of the retransmission > >packets is the same as in the original packets. Since this > is random it > >should be no problem for security. Is this assumption correct? > > > >Thanks in advance, > > > > > >José > > > > > >PS: by the way, in draft-05 Rolf Blom's email is the same as Mark > >Baugher's. Probably a cut&paste error. > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Jan 23 22:15:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28638 for ; Thu, 23 Jan 2003 22:15:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0O3Ymv16608 for avt-archive@odin.ietf.org; Thu, 23 Jan 2003 22:34:48 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0O3Y1J16578; Thu, 23 Jan 2003 22:34:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0O3R6J16382 for ; Thu, 23 Jan 2003 22:27:06 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28464 for ; Thu, 23 Jan 2003 22:07:45 -0500 (EST) Received: from cscoamera13263.cisco.com ([10.21.83.71]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h0O3BAB7017501; Thu, 23 Jan 2003 19:11:10 -0800 (PST) Message-Id: <5.1.1.5.2.20030123190842.09e27210@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 23 Jan 2003 19:11:12 -0800 To: From: Mark Baugher Subject: RE: [AVT] Re: Security for draft-ietf-avt-rtp-retransmission Cc: , In-Reply-To: <7CA3477F476D7F4FB82F02960B79CEBD01668CFF@daebe008.americas .nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0O3R6J16383 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit hi David I think you should remove reference to SRTP and send this I-D on its way rather than hold it and the SRTP I-D up while we analyze the security considerations of AVPF. If someone needs SRTP for AVPF, then they can take the lead to do this specification. If there is no interest in secure AVPF, then no effort needs to be wasted on it. thanks, Mark At 04:29 PM 1/23/2003 -0600, David.Leon@nokia.com wrote: >Hi Mark, > >Thanks for the feedback. Please see answers below. > > > hi Jose, > > I think that you cannot mention SRTP in this draft because > > http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-retrans > > mission-04.txt > > uses the > > http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcp-feedba > > ck-04.txt, > > which states in its security considerations section > > "Attacks using false RTCP packets (regular as well as early > > ones) can be > > avoided by authenticating all RTCP messages. This can be > > achieved by using > > the AVPF profile together with the Secure RTP profile as > > defined in [17]; > > as a prerequisite, an appropriate combination of those two > > profiles (an > > "SAVPF") needs to be specified. " > >Yes. We are aware that this has to be defined somewhere. This is what Jose >meant in point 3 of his mail. > > >3.- if a new profile needs be defined, something like "SAVPF", where > >shall this profile "SAVPF" be specified and registered? wouldn't it be > >reasonable to do this in the SRTP draft which already registers the > >"SAVP" profile given that the feedback draft would (presumably) have a > >similar schedule to the SRTP draft? > > > > > > This is because SRTP is nowhere defined for AVPF. It may be a small > > problem to adapt SRTP to your RTP profile, but this needs to be done > > because we only had RTP's AVP in mind when doing SAVP. > >What is actually required in order to adapt SRTP for retransmission and >AVPF? I think SRTP could be used as it is to encrypt the retransmission >packets. As far as SRTCP is concerned, does it need any modifications in >order to be able to encrypt the new ACKs and NACKs packets? > >Thanks, David. > > > > > > As > > http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcp-feedba > > ck-04.txt > > states, something needs to be specified. > > > > best regards, Mark > > > > At 05:35 PM 1/23/2003 +0100, Jose Rey wrote: > > >Hi all, > > > > > >we are doing the final edits to the > > draft-ietf-avt-rtp-retransmission. > > >We have considered all your comments until the date, but there's > > >something for which we would like to get some feedback on: security. > > > > > >A couple of questions: > > > > > >1.-As discussed on the list: > > >... > > > > -----Original Message----- > > > > From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On > > Behalf Of Colin > > > > Perkins > > > > Sent: Friday, January 10, 2003 4:39 AM > > > > To: David.Leon@nokia.com > > > > Cc: avt@ietf.org > > > > Subject: Re: [AVT] Comments on > > > > draft-ietf-avt-rtp-retransmission-04.txt > > > > > > >...snip... > > > > > > > >> - In section 12, how does this draft affect SRTP? Is it > > > > possible to use > > > > >> the two formats together? > > > > > > > > > >We'll try to draft something on that. My understanding > > is that the > > > > >retransmission stream is seen as any other stream by SRTP > > > > and there should > > > > >thus be no problem. > > > > > > > > I was not clear if retransmitting packets caused problems for > > > > SRTP; maybe > > > > one of the SRTP authors can comment on any potential > > security issue? > > > > > > > > > >we don't see any problems (except for SRTCP as below in 2) > > to use SRTP > > >with RTX since the RTP retransmission packets (with a two byte > > >retransmission payload header) are seen by SRTP as 'normal' > > RTP packets. > > >Is our assumption correct? > > > > > >2.-The retransmission payload format needs of the AVPF > > profile to enable > > >more frequent feedback and to request packets. This profile defines > > >(besides the new timing rules) some general-purpose messages such as > > >ACKs and NACKs and a new RTCP packet format: the early > > feedback packet, > > >which just contains 1 SR or RR and 1 SDES with just the CNAME. Now, > > >there should be no problem to encrypt/authenticate early packets, > > >according to the SRTP draft: > > > > > >" > > > According to [RFC1889] there is a "recommended" packet format for > > > compound packets. SRTCP MUST be given packets according to that > > > recommendation in the sense that the first part MUST be a sender > > > report or a receiver report. However, the encryption > > prefix (Section > > > 6.1 of [RFC1889]), a random 32-bit quantity intended to > > deter known > > > plaintext attacks, MUST NOT be used (see below). > > >" > > > > > > > > >Also there should be no problem to authenticate/encrypt ACKs > > and NACKs > > >with SRTCP since they are sent in compound RTCP packets > > starting with an > > >RR or SR packet. Let us know if you disagree with this point. > > > > > > > > >3.- if a new profile needs be defined, something like "SAVPF", where > > >shall this profile "SAVPF" be specified and registered? > > wouldn't it be > > >reasonable to do this in the SRTP draft which already registers the > > >"SAVP" profile given that the feedback draft would > > (presumably) have a > > >similar schedule to the SRTP draft? In this way the question 2. could > > >also be anwered there. > > > > > >4.- the security section in the retransmission draft already > > points out > > >the risks of using the same keys across sessions, e.g. two.-time pads > > >and points to the SRTP for solutions. That much is done. Are > > we missing > > >something else? > > > > > >5.-It is also pointed out that the Timestamp of the retransmission > > >packets is the same as in the original packets. Since this > > is random it > > >should be no problem for security. Is this assumption correct? > > > > > >Thanks in advance, > > > > > > > > >José > > > > > > > > >PS: by the way, in draft-05 Rolf Blom's email is the same as Mark > > >Baugher's. Probably a cut&paste error. > > > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www1.ietf.org/mailman/listinfo/avt > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Jan 23 23:35:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00134 for ; Thu, 23 Jan 2003 23:35:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0O4sfW20879 for avt-archive@odin.ietf.org; Thu, 23 Jan 2003 23:54:41 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0O4oKJ20725; Thu, 23 Jan 2003 23:50:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0O4kdJ20638 for ; Thu, 23 Jan 2003 23:46:39 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00004 for ; Thu, 23 Jan 2003 23:27:17 -0500 (EST) Received: from localhost ([127.0.0.1] helo=psg.com ident=mankin) by psg.com with esmtp (Exim 3.36 #2) id 18bvUI-0009qw-00; Thu, 23 Jan 2003 20:30:42 -0800 To: Silvia.Pfeiffer@csiro.au, avt@ietf.org, casner@acm.org, csp@isi.edu Cc: harald@alvestrand.no In-Reply-To: Message from Allison Mankin of "Fri, 10 Jan 2003 19:48:20 PST." Date: Thu, 23 Jan 2003 20:30:41 -0800 From: Allison Mankin Message-Id: Subject: [AVT] Re: New I-Ds for Ogg technologies (Vorbis over RTP, Ogg file format, Mimetypes) Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Silvia, AVT WG, Chairs, We IESG passed draft-walleij-ogg-mediatype-08.txt as a Proposed Standard today. It had had a four week Last Call some time back and was not changed, other than now having the internet-draft available to document the fileformat. Congratulations! The accompanying i-d, draft-pfeiffer-ogg-fileformat, was on the agenda as well and Harald Alvestrand raised a technical question that needs to be resolved before we can progress it as Informational. Harald's written question: Technical omission (I think): The document says that the BOS page "contains information to identify the codec type and any additional information to set up the decoding process. The format of that page is therefore dependent on the codec and therefore MUST be given in the encoding specification of that logical bitstream type." It's pretty clear that OGG players can identify which codec is being used. But this document does not say which bytes of the BOS page can be used to identify the codec. (first 4 bytes? first 16 bytes? up to the first NUL?) Thanks, Allison _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Jan 24 02:00:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03077 for ; Fri, 24 Jan 2003 02:00:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0O7Jm206189 for avt-archive@odin.ietf.org; Fri, 24 Jan 2003 02:19:48 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0O7IIJ06109; Fri, 24 Jan 2003 02:18:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0O7EdJ05429 for ; Fri, 24 Jan 2003 02:14:39 -0500 Received: from minotaur.labyrinth.net.au (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01781 for ; Fri, 24 Jan 2003 01:55:14 -0500 (EST) Received: from labyrinth.net.au (omega.labyrinth.net.au [203.9.148.6]) by minotaur.labyrinth.net.au (8.11.6/8.9.3) with SMTP id h0O6wc476725; Fri, 24 Jan 2003 17:58:38 +1100 (EST) Message-Id: <200301240658.h0O6wc476725@minotaur.labyrinth.net.au> Date: Fri, 24 Jan 2003 06:58:38 -0000 To: , , , Subject: Fwd: Re: [AVT] Re: New I-Ds for Ogg technologies (Vorbis over RTP, Ogg file format, Mimetypes) From: "Michael Smith" X-Mailer: TWIG 2.7.3 X-Client-IP: 203.51.185.245 Cc: Reply-To: msmith@xiph.org Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Oops, resending - hit 'reply' instead of 'reply to all'... Allison Mankin said: > Silvia, AVT WG, Chairs, > > We IESG passed draft-walleij-ogg-mediatype-08.txt as a Proposed > Standard today. It had had a four week Last Call some time back and > was not changed, other than now having the internet-draft available to > document the fileformat. Congratulations! > > The accompanying i-d, draft-pfeiffer-ogg-fileformat, was on the agenda > as well and Harald Alvestrand raised a technical question that needs > to be resolved before we can progress it as Informational. Harald's > written question: > > Technical omission (I think): The document says that the BOS page > "contains information to identify the codec type and any additional > information to set up the decoding process. The format of that page > is therefore dependent on the codec and therefore MUST be given in > the encoding specification of that logical bitstream type." I'd suggest a rewording of "and any information ..." to "and MAY contain information to set up the decoding process". Vorbis, for example, contains some but not all of the setup data in this header (BOS page) - most of the setup information is in the 3rd header packet (the codebook packet). This makes it clearer that Ogg doesn't require ALL setup info in the BOS page. Also, the format does not mandate the following, but I think perhaps we should considering strongly suggesting it (it's done by all existing Ogg-encapsulated codecs, and is very useful generally): (something like this) "The BOS page SHOULD also contain information about the type of the output (decompressed) media - for example, for audio, it should contain sample rate and number of channels" (that needs a bit of editorial attention, but I think it'd be a worthwhile addition). > > It's pretty clear that OGG players can identify which codec is being > used. But this document does not say which bytes of the BOS page can > be used to identify the codec. (first 4 bytes? first 16 bytes? up to > the first NUL?) > Again, based on vorbis as an example (for the spec doesn't explicitly state this), any leading part of the data (i.e. packet contents, so these are not the absolute leading bytes in the stream, since there is the page header first) in this first page. Vorbis uses the first 7 bytes (0x01, 0x76, 0x6f, 0x72, 0x62, 0x69, 0x73 -- which is a leading 0x01 followed by the ascii values for "vorbis"), but the intent is to not have a single fixed-size identifier. We should, however, specify a _maximum_ length for this). Mike _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Jan 24 09:05:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19641 for ; Fri, 24 Jan 2003 09:05:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0OEOmo00992 for avt-archive@odin.ietf.org; Fri, 24 Jan 2003 09:24:48 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OEKuJ00844; Fri, 24 Jan 2003 09:20:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OEJxJ00759 for ; Fri, 24 Jan 2003 09:19:59 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19409 for ; Fri, 24 Jan 2003 09:00:26 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0OE3rKX017597; Fri, 24 Jan 2003 15:03:53 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 24 Jan 2003 15:03:53 +0100 Message-ID: <4E85E49D1F0CBF4F96EA08E335750D7D02838B03@Esealnt877.al.sw.ericsson.se> From: "Elisabetta Carrara (EAB)" To: "'rey@panasonic.de'" , "'avt@ietf.org'" Cc: =?iso-8859-1?Q?Mats_N=E4slund_=28EAB=29?= , "Karl Norrman (EAB)" Date: Fri, 24 Jan 2003 15:04:14 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Subject: [AVT] RE: Security for draft-ietf-avt-rtp-retransmission Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Hi! we gave a look at the draft, we have only few remarks. It seems that applying SRTP should be quite straight (however, we have not read AVPF). - there is the two time pad issue for the session-multiplexing (as the SSRC must be the same): the two flows MUST use different master keys - there is no problem in the SSRC-multiplexing case (as the SSRC must be different), i.e. it is possible to use the same master key or different ones. However, the issue is with RTCP, that we understand joint. You can have several alternatives there on how to use the keys, up to you to decide. The simplest is to share the master key between the 3 flows (original RTP, retx, RTCP). - what should be encrypted by SRTP? SRTP encrypts *the RTP payload*. Now, we only read certain parts of the draft, but it was not clear if saying *RTP payload* includes also the OSN field. If it is clear to you, forget the comment. - there should be no problem for the new ACK and NACK messages, as they are placed after a Sender Report or Receiver Report As for the profile issue, we would leave it to the chairmen. Cheers /E et al > > > >> - In section 12, how does this draft affect SRTP? Is it > > possible to use > > >> the two formats together? > > > > > >We'll try to draft something on that. My understanding is that the > > >retransmission stream is seen as any other stream by SRTP > > and there should > > >thus be no problem. > > > > I was not clear if retransmitting packets caused problems for > > SRTP; maybe > > one of the SRTP authors can comment on any potential security issue? > > > > we don't see any problems (except for SRTCP as below in 2) to use SRTP > with RTX since the RTP retransmission packets (with a two byte > retransmission payload header) are seen by SRTP as 'normal' > RTP packets. > Is our assumption correct? > > 2.-The retransmission payload format needs of the AVPF > profile to enable > more frequent feedback and to request packets. This profile defines > (besides the new timing rules) some general-purpose messages such as > ACKs and NACKs and a new RTCP packet format: the early > feedback packet, > which just contains 1 SR or RR and 1 SDES with just the CNAME. Now, > there should be no problem to encrypt/authenticate early packets, > according to the SRTP draft: > > " > According to [RFC1889] there is a "recommended" packet format for > compound packets. SRTCP MUST be given packets according to that > recommendation in the sense that the first part MUST be a sender > report or a receiver report. However, the encryption > prefix (Section > 6.1 of [RFC1889]), a random 32-bit quantity intended to deter known > plaintext attacks, MUST NOT be used (see below). > " > > > Also there should be no problem to authenticate/encrypt ACKs and NACKs > with SRTCP since they are sent in compound RTCP packets > starting with an > RR or SR packet. Let us know if you disagree with this point. > > > 3.- if a new profile needs be defined, something like "SAVPF", where > shall this profile "SAVPF" be specified and registered? wouldn't it be > reasonable to do this in the SRTP draft which already registers the > "SAVP" profile given that the feedback draft would (presumably) have a > similar schedule to the SRTP draft? In this way the question 2. could > also be anwered there. > > 4.- the security section in the retransmission draft already > points out > the risks of using the same keys across sessions, e.g. two.-time pads > and points to the SRTP for solutions. That much is done. Are > we missing > something else? > > 5.-It is also pointed out that the Timestamp of the retransmission > packets is the same as in the original packets. Since this is > random it > should be no problem for security. Is this assumption correct? > > Thanks in advance, > > > José > > > PS: by the way, in draft-05 Rolf Blom's email is the same as Mark > Baugher's. Probably a cut&paste error. > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Jan 24 10:00:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21614 for ; Fri, 24 Jan 2003 10:00:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0OFJ8V05101 for avt-archive@odin.ietf.org; Fri, 24 Jan 2003 10:19:08 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OFEBJ04827; Fri, 24 Jan 2003 10:14:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OFDBJ04783 for ; Fri, 24 Jan 2003 10:13:11 -0500 Received: from purple.nge.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21308 for ; Fri, 24 Jan 2003 09:53:35 -0500 (EST) Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.6/8.12.6) with ESMTP id h0OEus9E007985; Fri, 24 Jan 2003 09:56:54 -0500 (EST) (envelope-from csp@purple.nge.isi.edu) Message-Id: <200301241456.h0OEus9E007985@purple.nge.isi.edu> To: Mark Baugher cc: David.Leon@nokia.com, rey@panasonic.de, avt@ietf.org Subject: Re: [AVT] Re: Security for draft-ietf-avt-rtp-retransmission In-Reply-To: Your message of "Thu, 23 Jan 2003 19:11:12 PST." <5.1.1.5.2.20030123190842.09e27210@mira-sjc5-6.cisco.com> Date: Fri, 24 Jan 2003 09:56:54 -0500 From: Colin Perkins Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Seems reasonable... Colin --> Mark Baugher writes: >hi David > I think you should remove reference to SRTP and send this I-D on its way >rather than hold it and the SRTP I-D up while we analyze the security >considerations of AVPF. If someone needs SRTP for AVPF, then they can take >the lead to do this specification. If there is no interest in secure AVPF, >then no effort needs to be wasted on it. > >thanks, Mark >At 04:29 PM 1/23/2003 -0600, David.Leon@nokia.com wrote: > > >>Hi Mark, >> >>Thanks for the feedback. Please see answers below. >> >> > hi Jose, >> > I think that you cannot mention SRTP in this draft because >> > http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-retrans >> > mission-04.txt >> > uses the >> > http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcp-feedba >> > ck-04.txt, >> > which states in its security considerations section >> > "Attacks using false RTCP packets (regular as well as early >> > ones) can be >> > avoided by authenticating all RTCP messages. This can be >> > achieved by using >> > the AVPF profile together with the Secure RTP profile as >> > defined in [17]; >> > as a prerequisite, an appropriate combination of those two >> > profiles (an >> > "SAVPF") needs to be specified. " >> >>Yes. We are aware that this has to be defined somewhere. This is what Jose >>meant in point 3 of his mail. >> >> >3.- if a new profile needs be defined, something like "SAVPF", where >> >shall this profile "SAVPF" be specified and registered? wouldn't it be >> >reasonable to do this in the SRTP draft which already registers the >> >"SAVP" profile given that the feedback draft would (presumably) have a >> >similar schedule to the SRTP draft? >> >> >> > >> > This is because SRTP is nowhere defined for AVPF. It may be a small >> > problem to adapt SRTP to your RTP profile, but this needs to be done >> > because we only had RTP's AVP in mind when doing SAVP. >> >>What is actually required in order to adapt SRTP for retransmission and >>AVPF? I think SRTP could be used as it is to encrypt the retransmission >>packets. As far as SRTCP is concerned, does it need any modifications in >>order to be able to encrypt the new ACKs and NACKs packets? >> >>Thanks, David. >> >> >> > >> > As >> > http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcp-feedba >> > ck-04.txt >> > states, something needs to be specified. >> > >> > best regards, Mark >> > >> > At 05:35 PM 1/23/2003 +0100, Jose Rey wrote: >> > >Hi all, >> > > >> > >we are doing the final edits to the >> > draft-ietf-avt-rtp-retransmission. >> > >We have considered all your comments until the date, but there's >> > >something for which we would like to get some feedback on: security. >> > > >> > >A couple of questions: >> > > >> > >1.-As discussed on the list: >> > >... >> > > > -----Original Message----- >> > > > From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On >> > Behalf Of Colin >> > > > Perkins >> > > > Sent: Friday, January 10, 2003 4:39 AM >> > > > To: David.Leon@nokia.com >> > > > Cc: avt@ietf.org >> > > > Subject: Re: [AVT] Comments on >> > > > draft-ietf-avt-rtp-retransmission-04.txt >> > > > >> > >...snip... >> > > >> > > > >> - In section 12, how does this draft affect SRTP? Is it >> > > > possible to use >> > > > >> the two formats together? >> > > > > >> > > > >We'll try to draft something on that. My understanding >> > is that the >> > > > >retransmission stream is seen as any other stream by SRTP >> > > > and there should >> > > > >thus be no problem. >> > > > >> > > > I was not clear if retransmitting packets caused problems for >> > > > SRTP; maybe >> > > > one of the SRTP authors can comment on any potential >> > security issue? >> > > > >> > > >> > >we don't see any problems (except for SRTCP as below in 2) >> > to use SRTP >> > >with RTX since the RTP retransmission packets (with a two byte >> > >retransmission payload header) are seen by SRTP as 'normal' >> > RTP packets. >> > >Is our assumption correct? >> > > >> > >2.-The retransmission payload format needs of the AVPF >> > profile to enable >> > >more frequent feedback and to request packets. This profile defines >> > >(besides the new timing rules) some general-purpose messages such as >> > >ACKs and NACKs and a new RTCP packet format: the early >> > feedback packet, >> > >which just contains 1 SR or RR and 1 SDES with just the CNAME. Now, >> > >there should be no problem to encrypt/authenticate early packets, >> > >according to the SRTP draft: >> > > >> > >" >> > > According to [RFC1889] there is a "recommended" packet format for >> > > compound packets. SRTCP MUST be given packets according to that >> > > recommendation in the sense that the first part MUST be a sender >> > > report or a receiver report. However, the encryption >> > prefix (Section >> > > 6.1 of [RFC1889]), a random 32-bit quantity intended to >> > deter known >> > > plaintext attacks, MUST NOT be used (see below). >> > >" >> > > >> > > >> > >Also there should be no problem to authenticate/encrypt ACKs >> > and NACKs >> > >with SRTCP since they are sent in compound RTCP packets >> > starting with an >> > >RR or SR packet. Let us know if you disagree with this point. >> > > >> > > >> > >3.- if a new profile needs be defined, something like "SAVPF", where >> > >shall this profile "SAVPF" be specified and registered? >> > wouldn't it be >> > >reasonable to do this in the SRTP draft which already registers the >> > >"SAVP" profile given that the feedback draft would >> > (presumably) have a >> > >similar schedule to the SRTP draft? In this way the question 2. could >> > >also be anwered there. >> > > >> > >4.- the security section in the retransmission draft already >> > points out >> > >the risks of using the same keys across sessions, e.g. two.-time pads >> > >and points to the SRTP for solutions. That much is done. Are >> > we missing >> > >something else? >> > > >> > >5.-It is also pointed out that the Timestamp of the retransmission >> > >packets is the same as in the original packets. Since this >> > is random it >> > >should be no problem for security. Is this assumption correct? >> > > >> > >Thanks in advance, >> > > >> > > >> > >José >> > > >> > > >> > >PS: by the way, in draft-05 Rolf Blom's email is the same as Mark >> > >Baugher's. Probably a cut&paste error. >> > >> > _______________________________________________ >> > Audio/Video Transport Working Group >> > avt@ietf.org >> > https://www1.ietf.org/mailman/listinfo/avt >> > > >_______________________________________________ >Audio/Video Transport Working Group >avt@ietf.org >https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Jan 24 12:04:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25016 for ; Fri, 24 Jan 2003 12:04:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0OHNgE14165 for avt-archive@odin.ietf.org; Fri, 24 Jan 2003 12:23:42 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OHMeJ14104; Fri, 24 Jan 2003 12:22:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OHLTJ14034 for ; Fri, 24 Jan 2003 12:21:29 -0500 Received: from mail.pel.panasonic.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24951 for ; Fri, 24 Jan 2003 12:01:51 -0500 (EST) Received: from atrgreyj (vw1.pel.panasonic.de [10.78.238.55]) by mail.pel.panasonic.de (__________PEL__Mail-Server__________) with SMTP id <0H98006NIA3KN7@panasonic.de> for avt@ietf.org; Fri, 24 Jan 2003 18:04:33 +0100 (MET) Date: Fri, 24 Jan 2003 18:04:32 +0100 From: Jose Rey Subject: RE: [AVT] RE: Security for draft-ietf-avt-rtp-retransmission In-reply-to: <4E85E49D1F0CBF4F96EA08E335750D7D02838B03@Esealnt877.al.sw.ericsson.se> To: "Elisabetta Carrara (EAB)" , avt@ietf.org Cc: Mats =?ISO-8859-1?Q?N=E4slund_=28EAB=29?= , "Karl Norrman (EAB)" , David Leon Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 8BIT Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8BIT Hi Elisabetta, thanks for your review. See my comments in-line. > > Hi! > we gave a look at the draft, we have only few remarks. > > It seems that applying SRTP should be quite straight (however, > we have not read AVPF). > > - there is the two time pad issue for the > session-multiplexing (as the SSRC > must be the same): the two flows MUST use different master keys > > - there is no problem in the SSRC-multiplexing case (as the > SSRC must be > different), i.e. it is possible to use the same master key or > different ones. > However, the issue is with RTCP, that we understand > joint. You can > have several alternatives there on how to use the keys, > up to you > to decide. The simplest is to share the master key > between the 3 > flows (original RTP, retx, RTCP). OK. > > - what should be encrypted by SRTP? SRTP encrypts *the RTP payload*. > Now, we only read certain parts of the draft, but it > was not clear > if saying *RTP payload* includes also the OSN field. > If it is clear to you, forget the comment. > Saying 'RTP payload' for the retransmission packet also includes the OSN, as this is defined as part of the retransmission payload format for RTP. Thus the OSN would be encrypted without further changes in SRTP. > - there should be no problem for the new ACK and NACK > messages, as they > are placed after a Sender Report or Receiver Report The initial question (3 in my first mail) is actually answered by this statement :) > > As for the profile issue, we would leave it to the chairmen. As Colin said, it seems that another document is the right place to do it. thanks, José > > Cheers > /E et al > > > > > > > > >> - In section 12, how does this draft affect SRTP? Is it > > > possible to use > > > >> the two formats together? > > > > > > > >We'll try to draft something on that. My understanding > is that the > > > >retransmission stream is seen as any other stream by SRTP > > > and there should > > > >thus be no problem. > > > > > > I was not clear if retransmitting packets caused problems for > > > SRTP; maybe > > > one of the SRTP authors can comment on any potential > security issue? > > > > > > > we don't see any problems (except for SRTCP as below in 2) > to use SRTP > > with RTX since the RTP retransmission packets (with a two byte > > retransmission payload header) are seen by SRTP as 'normal' > > RTP packets. > > Is our assumption correct? > > > > 2.-The retransmission payload format needs of the AVPF > > profile to enable > > more frequent feedback and to request packets. This profile defines > > (besides the new timing rules) some general-purpose messages such as > > ACKs and NACKs and a new RTCP packet format: the early > > feedback packet, > > which just contains 1 SR or RR and 1 SDES with just the CNAME. Now, > > there should be no problem to encrypt/authenticate early packets, > > according to the SRTP draft: > > > > " > > According to [RFC1889] there is a "recommended" packet format for > > compound packets. SRTCP MUST be given packets according to that > > recommendation in the sense that the first part MUST be a sender > > report or a receiver report. However, the encryption > > prefix (Section > > 6.1 of [RFC1889]), a random 32-bit quantity intended to > deter known > > plaintext attacks, MUST NOT be used (see below). > > " > > > > > > Also there should be no problem to authenticate/encrypt > ACKs and NACKs > > with SRTCP since they are sent in compound RTCP packets > > starting with an > > RR or SR packet. Let us know if you disagree with this point. > > > > > > 3.- if a new profile needs be defined, something like "SAVPF", where > > shall this profile "SAVPF" be specified and registered? > wouldn't it be > > reasonable to do this in the SRTP draft which already registers the > > "SAVP" profile given that the feedback draft would > (presumably) have a > > similar schedule to the SRTP draft? In this way the > question 2. could > > also be anwered there. > > > > 4.- the security section in the retransmission draft already > > points out > > the risks of using the same keys across sessions, e.g. > two.-time pads > > and points to the SRTP for solutions. That much is done. Are > > we missing > > something else? > > > > 5.-It is also pointed out that the Timestamp of the retransmission > > packets is the same as in the original packets. Since this is > > random it > > should be no problem for security. Is this assumption correct? > > > > Thanks in advance, > > > > > > José > > > > > > PS: by the way, in draft-05 Rolf Blom's email is the same as Mark > > Baugher's. Probably a cut&paste error. > > > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Jan 24 12:04:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25029 for ; Fri, 24 Jan 2003 12:04:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0OHNkp14181 for avt-archive@odin.ietf.org; Fri, 24 Jan 2003 12:23:46 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OHMmJ14121; Fri, 24 Jan 2003 12:22:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OHL3J14019 for ; Fri, 24 Jan 2003 12:21:03 -0500 Received: from pimout1-ext.prodigy.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24944 for ; Fri, 24 Jan 2003 12:01:26 -0500 (EST) Received: from nascar2 (adsl-64-175-107-86.dsl.lsan03.pacbell.net [64.175.107.86]) by pimout1-ext.prodigy.net (8.12.3 da nor stuldap/8.12.3) with SMTP id h0OH4rkZ331612; Fri, 24 Jan 2003 12:04:53 -0500 From: "Mike Taylor" To: "Stephen Casner" , "AVT WG" Subject: RE: [AVT] Final edits to RTP spec and A/V profile Date: Fri, 24 Jan 2003 09:05:31 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20030110154341.U80020-100000@ash.packetdesign.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit My comments below.... > -----Original Message----- > From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Stephen > Casner > Sent: Friday, January 10, 2003 3:47 PM > To: AVT WG > Subject: Re: [AVT] Final edits to RTP spec and A/V profile > > > Attempt number three on the definition of an RTP session. David Leon > made some suggestions, and I fixed some typo problems. Is this clear? > And even more important, do you agree with what it specifies? > > RTP session: An association among a set of participants > communicating with RTP. A participant may be involved in > multiple RTP sessions at the same time. In a multimedia > session, each medium is carried in a separate RTP session > with its own RTCP packets. A participant distinguishes > multiple RTP sessions by reception of different sessions > using different pairs of destination transport addresses, > where a pair of transport addresses comprises one network > address plus a pair of ports for RTP and RTCP. All > participants in an RTP session may share a common > destination transport address pair, as in the case of IP > multicast, or the pairs may be different for each > participant, as in the case of individual unicast network > addresses and port pairs. In the unicast case, a > participant may receive from all other participants using > the same pair of ports, or may use a distinct pair of ports > for each. > > The distinguishing feature of an RTP session is that each > defines a distinct space of SSRC identifiers (defined > next). The set of participants included in one RTP session > consists of those that can receive an SSRC identifier > transmitted by any one of the participants either in RTP as > the SSRC or a CSRC (also defined below) or in RTCP. For > example, consider a three-party conference implemented > using unicast UDP with each participant receiving from the > other two on separate port pairs. If each participant > sends RTCP feedback about data received from one other > participant only back to that participant, then the > conference is composed of three separate point-to-point RTP > sessions. If each participant provides RTCP feedback about > its reception of one other participant to both of the other > participants, then the conference is composed of one > multi-party RTP session. The latter case simulates the > behavior that would occur with IP multicast communication > among the three participants. The above statements about multi-point unicast hit on a nerve for me, so pardon me if I rant just a bit. But having just completed an implementation of RTP/RTCP which I attempted to make very general purpose, and thus tried to support point-to-point unicast, multi-point unicast, as well as multicast, I have to say that the major problem with this RFC is that it mentions the concepts of unicast RTP sessions, and in particular multi-point unicast sessions, but really does little to offer requirements or even guidance about how RTCP should operate in these circumstances. I believe that the draft, and presumably next standard, should not attempt to address multi-point unicast especially, but rather should acknowledge that the RFC only really covers multicast RTP sessions, and that a separate RFC will be needed to address multi-point unicast. Why? For example, so much of the complexity of RTCP revolves around keeping track of the numbers of session members so as to compute the RTCP reporting interval that will maintain the desired bandwidth constraints on RTCP traffic. But is it not the case that the algorithm offered in the RFC for this purpose breaks down in the multi-point unicast case? Isn't the assumption that a given session participant never sends more than one stream of RTCP packets - either receiver reports only, or sender reports only - the latter possibly containing RR blocks? So in a multicast session each participant generates at most one RTCP packet per reporting interval. But as correctly suggested above, in a true multi-point unicast sessions all receivers would have to send RTCP reports about ever stream being received to every other receiver. Otherwise, even in the simplest case of a multi-point unicast session where only one member transmits and all others receive, there will be a gross underestimation of the number of session participants, and thus for a large unicast conference of this type (which one would think in the current multicast-less commercial internet would be the most common scenario) there would be far more bandwidth consumed by RTCP than intended. But if all receivers sent RTCP RRs to all other receivers (I don't know how they find out about one another to achieve this... more later) then unlike the multicast case this implies there will be N*(N-1) RTCP packets sent per reporting interval! Certainly the algorithm in the RFC for computing the RTCP reporting interval doesn't take this into account. So it seems to me that in reality the original, and current draft RTP RFCs, are both really about multicast RTP, and that the new draft should admit this fact and there should be additional RFCs to specify the correct operation of RTP for unicast sessions, and especially for multi-point unicast sessions. Perhaps point-to-point unicast is simple enough that its operation can be covered in an appendix to the current draft. But even there, I think the RFC should explicitly address the fact that the entire algorithm for computing RTCP bandwidth is overkill and unnecessary for a simple point-to-point unicast RTP session. I suggest a separate RFC to deal with multi-point unicast only because I'm sure nobody would want to hold up the advancement of the current draft long enough to deal properly with this scenario. It seems rather difficult for me to believe that in a commercial broadcast style deployment of this technology that anyone would want all receivers sending receiver reports to one another. So I'm thinking that a more realistic scenario for multi-point unicast would involve some centralized control. Obviously, in a broadcast TV scenario where a single transmitter sends unicast RTP to a large number of receivers, then the receivers should learn about how often to send receiver reports back to the transmitter from the transmitter. Why would most of them even care about the other receivers, and security considerations would seem to dictate that they shouldn't be aware of them (I'm sure I want to send my RRs to my nextdoor neighbor's hacker kiddie!). The entire calculation for the reporting interval could be carried out at the transmitter, with some addition RTCP message type being defined that the transmitter would use to tell the receivers the reporting interval. Based on the transmitters knowledge of the estimated RTT to each receiver, it could give different receivers different reporting intervals. Besides, as stated above, even if one took the approach of sending RRs to all other receivers, how would one know how to address these reports without centralized session control anyway? Anyway, nuff said. I feel in summary that the RFC should acknowledge that much of the RTCP content in the current RFC and draft is intended for multicast sessions, and that further work is needed to define proper operation in a multi-point unicast scenario. - Mike > > -- Steve > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Jan 24 15:09:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00869 for ; Fri, 24 Jan 2003 15:09:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0OKSg426413 for avt-archive@odin.ietf.org; Fri, 24 Jan 2003 15:28:42 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OKRmJ26375; Fri, 24 Jan 2003 15:27:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OKQfJ26342 for ; Fri, 24 Jan 2003 15:26:41 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00816 for ; Fri, 24 Jan 2003 15:07:01 -0500 (EST) From: David.Leon@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0OKAVB02393 for ; Fri, 24 Jan 2003 14:10:31 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 24 Jan 2003 14:10:12 -0600 Received: from daebe008.NOE.Nokia.com ([172.18.242.238]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 24 Jan 2003 12:10:11 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AVT] Re: Security for draft-ietf-avt-rtp-retransmission Date: Fri, 24 Jan 2003 14:10:11 -0600 Message-ID: <7CA3477F476D7F4FB82F02960B79CEBD017E4F8D@daebe008.americas.nokia.com> Thread-Topic: [AVT] Re: Security for draft-ietf-avt-rtp-retransmission Thread-Index: AcLDVkS0f0eOSiCeSJSYEs29+aajUAAjOBbA To: Cc: , X-OriginalArrivalTime: 24 Jan 2003 20:10:11.0900 (UTC) FILETIME=[99BC27C0:01C2C3E4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0OKQfJ26343 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Mark, > > hi David > I think you should remove reference to SRTP and send this > I-D on its way > rather than hold it and the SRTP I-D up while we analyze the security > considerations of AVPF. If someone needs SRTP for AVPF, then We of course don't want to delay the completion of SRTP. It's ok for us to remove any reference to SRTP from the retransmission draft. Our main concern was to make sure that there is no reason why retransmissions could not be made to work with SRTP. As Elisabetta's feedback seems to confirm it, this should not be the case. > they can take > the lead to do this specification. If there is no interest > in secure AVPF, > then no effort needs to be wasted on it. We're thus thinking of addressing how retransmission should work with SRTP in a new draft. This draft would in particular define and register SAVPF. David. > > thanks, Mark > At 04:29 PM 1/23/2003 -0600, David.Leon@nokia.com wrote: > > > >Hi Mark, > > > >Thanks for the feedback. Please see answers below. > > > > > hi Jose, > > > I think that you cannot mention SRTP in this draft because > > > http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-retrans > > > mission-04.txt > > > uses the > > > http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcp-feedba > > > ck-04.txt, > > > which states in its security considerations section > > > "Attacks using false RTCP packets (regular as well as early > > > ones) can be > > > avoided by authenticating all RTCP messages. This can be > > > achieved by using > > > the AVPF profile together with the Secure RTP profile as > > > defined in [17]; > > > as a prerequisite, an appropriate combination of those two > > > profiles (an > > > "SAVPF") needs to be specified. " > > > >Yes. We are aware that this has to be defined somewhere. > This is what Jose > >meant in point 3 of his mail. > > > > >3.- if a new profile needs be defined, something like > "SAVPF", where > > >shall this profile "SAVPF" be specified and registered? > wouldn't it be > > >reasonable to do this in the SRTP draft which already registers the > > >"SAVP" profile given that the feedback draft would > (presumably) have a > > >similar schedule to the SRTP draft? > > > > > > > > > > This is because SRTP is nowhere defined for AVPF. It may > be a small > > > problem to adapt SRTP to your RTP profile, but this needs > to be done > > > because we only had RTP's AVP in mind when doing SAVP. > > > >What is actually required in order to adapt SRTP for > retransmission and > >AVPF? I think SRTP could be used as it is to encrypt the > retransmission > >packets. As far as SRTCP is concerned, does it need any > modifications in > >order to be able to encrypt the new ACKs and NACKs packets? > > > >Thanks, David. > > > > > > > > > > As > > > http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcp-feedba > > > ck-04.txt > > > states, something needs to be specified. > > > > > > best regards, Mark > > > > > > At 05:35 PM 1/23/2003 +0100, Jose Rey wrote: > > > >Hi all, > > > > > > > >we are doing the final edits to the > > > draft-ietf-avt-rtp-retransmission. > > > >We have considered all your comments until the date, but there's > > > >something for which we would like to get some feedback > on: security. > > > > > > > >A couple of questions: > > > > > > > >1.-As discussed on the list: > > > >... > > > > > -----Original Message----- > > > > > From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On > > > Behalf Of Colin > > > > > Perkins > > > > > Sent: Friday, January 10, 2003 4:39 AM > > > > > To: David.Leon@nokia.com > > > > > Cc: avt@ietf.org > > > > > Subject: Re: [AVT] Comments on > > > > > draft-ietf-avt-rtp-retransmission-04.txt > > > > > > > > >...snip... > > > > > > > > > >> - In section 12, how does this draft affect SRTP? Is it > > > > > possible to use > > > > > >> the two formats together? > > > > > > > > > > > >We'll try to draft something on that. My understanding > > > is that the > > > > > >retransmission stream is seen as any other stream by SRTP > > > > > and there should > > > > > >thus be no problem. > > > > > > > > > > I was not clear if retransmitting packets caused problems for > > > > > SRTP; maybe > > > > > one of the SRTP authors can comment on any potential > > > security issue? > > > > > > > > > > > > >we don't see any problems (except for SRTCP as below in 2) > > > to use SRTP > > > >with RTX since the RTP retransmission packets (with a two byte > > > >retransmission payload header) are seen by SRTP as 'normal' > > > RTP packets. > > > >Is our assumption correct? > > > > > > > >2.-The retransmission payload format needs of the AVPF > > > profile to enable > > > >more frequent feedback and to request packets. This > profile defines > > > >(besides the new timing rules) some general-purpose > messages such as > > > >ACKs and NACKs and a new RTCP packet format: the early > > > feedback packet, > > > >which just contains 1 SR or RR and 1 SDES with just the > CNAME. Now, > > > >there should be no problem to encrypt/authenticate early packets, > > > >according to the SRTP draft: > > > > > > > >" > > > > According to [RFC1889] there is a "recommended" > packet format for > > > > compound packets. SRTCP MUST be given packets > according to that > > > > recommendation in the sense that the first part MUST > be a sender > > > > report or a receiver report. However, the encryption > > > prefix (Section > > > > 6.1 of [RFC1889]), a random 32-bit quantity intended to > > > deter known > > > > plaintext attacks, MUST NOT be used (see below). > > > >" > > > > > > > > > > > >Also there should be no problem to authenticate/encrypt ACKs > > > and NACKs > > > >with SRTCP since they are sent in compound RTCP packets > > > starting with an > > > >RR or SR packet. Let us know if you disagree with this point. > > > > > > > > > > > >3.- if a new profile needs be defined, something like > "SAVPF", where > > > >shall this profile "SAVPF" be specified and registered? > > > wouldn't it be > > > >reasonable to do this in the SRTP draft which already > registers the > > > >"SAVP" profile given that the feedback draft would > > > (presumably) have a > > > >similar schedule to the SRTP draft? In this way the > question 2. could > > > >also be anwered there. > > > > > > > >4.- the security section in the retransmission draft already > > > points out > > > >the risks of using the same keys across sessions, e.g. > two.-time pads > > > >and points to the SRTP for solutions. That much is done. Are > > > we missing > > > >something else? > > > > > > > >5.-It is also pointed out that the Timestamp of the > retransmission > > > >packets is the same as in the original packets. Since this > > > is random it > > > >should be no problem for security. Is this assumption correct? > > > > > > > >Thanks in advance, > > > > > > > > > > > >José > > > > > > > > > > > >PS: by the way, in draft-05 Rolf Blom's email is the same as Mark > > > >Baugher's. Probably a cut&paste error. > > > > > > _______________________________________________ > > > Audio/Video Transport Working Group > > > avt@ietf.org > > > https://www1.ietf.org/mailman/listinfo/avt > > > > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Jan 24 18:13:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05096 for ; Fri, 24 Jan 2003 18:13:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0ONWXY04616 for avt-archive@odin.ietf.org; Fri, 24 Jan 2003 18:32:33 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ONUcJ04545; Fri, 24 Jan 2003 18:30:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0O9N7J14574 for ; Fri, 24 Jan 2003 04:23:07 -0500 Received: from eikenes.alvestrand.no (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13600 for ; Fri, 24 Jan 2003 04:03:40 -0500 (EST) Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id BDD3E621FB; Fri, 24 Jan 2003 10:07:07 +0100 (CET) Date: Fri, 24 Jan 2003 10:07:07 +0100 From: Harald Tveit Alvestrand To: msmith@xiph.org, Silvia.Pfeiffer@csiro.au, avt@ietf.org, casner@acm.org, csp@isi.edu Subject: Re: Fwd: Re: [AVT] Re: New I-Ds for Ogg technologies (Vorbis over RTP, Ogg file format, Mimetypes) Message-ID: <159850000.1043399227@askvoll.hjemme.alvestrand.no> In-Reply-To: <200301240658.h0O6wc476725@minotaur.labyrinth.net.au> References: <200301240658.h0O6wc476725@minotaur.labyrinth.net.au> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit --On fredag, januar 24, 2003 06:58:38 +0000 Michael Smith wrote: >> >> It's pretty clear that OGG players can identify which codec is being >> used. But this document does not say which bytes of the BOS page can >> be used to identify the codec. (first 4 bytes? first 16 bytes? up to >> the first NUL?) >> > > Again, based on vorbis as an example (for the spec doesn't explicitly > state this), any leading part of the data (i.e. packet contents, so these > are not the absolute leading bytes in the stream, since there is the page > header first) in this first page. Vorbis uses the first 7 bytes (0x01, > 0x76, 0x6f, 0x72, 0x62, 0x69, 0x73 -- which is a leading 0x01 followed by > the ascii values for "vorbis"), but the intent is to not have a single > fixed-size identifier. We should, however, specify a _maximum_ length for > this). followup..... the IETF's been dealing with multilevel protocols for some years, so identifying the "protocol at the next layer" is something we're used to... not trying to say what's the right way, just musing about the problem.... you've basically got two problems: 1) how to make sure there's information enough to identify the codec, and information enough to know when the codec has been uniquely identified? (it would be silly if players refused to play 0x01 + "vorbis" + 0x01 because all the sound they had been tested on had a 0x00 in the position after the "vorbis" string, and the player checked the values of 8 bytes, for instance; otoh, 0x01 + "vorbiz" is probably a different codec, so you should check at least 7 bytes, not 6) (btw, my Linux Mandrake "magic" file claims that the byte after "vorbis" is the 32-bit version number, and zero is the only known value, I think...) 2) how to make sure no two codecs pick the same identifier string? (the "registry" problem) the last is usually not a problem until some name becomes "popular" - but think about the number of formats that have been using the .doc file name ending on the Windows platform for an example of collisions.... if you solve that problem by establishing some kind of registry (rather than "trust to luck and goodwill"), you also have a convenient place to store pointers to the specifications of those formats..... (In my personal .ogg collection, there are no examples of anything but the vorbis codec, unfortunately... and all of it has been encoded with a single codec, so this is not much of a test suite....) Harald _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Jan 24 18:13:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05131 for ; Fri, 24 Jan 2003 18:13:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0ONXDM04659 for avt-archive@odin.ietf.org; Fri, 24 Jan 2003 18:33:13 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ONWEJ04603; Fri, 24 Jan 2003 18:32:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ONOtJ04379 for ; Fri, 24 Jan 2003 18:24:55 -0500 Received: from darkwing.uoregon.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04975 for ; Fri, 24 Jan 2003 18:05:02 -0500 (EST) Received: from minerve (d85-248.uoregon.edu [128.223.85.248]) by darkwing.uoregon.edu (8.12.7/8.12.7) with ESMTP id h0ON8But019855 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 24 Jan 2003 15:08:12 -0800 (PST) From: Timur Friedman To: avt@ietf.org Date: Sat, 25 Jan 2003 01:08:24 +0100 User-Agent: KMail/1.4.3 Cc: Ramon Caceres , Alan Clark , Kevin Almeroth , Kamil Sarac , Robert Cole , Kaynam Hedayat , Nick Duffield References: <200301242135.31937.timur.friedman@lip6.fr> In-Reply-To: <200301242135.31937.timur.friedman@lip6.fr> MIME-Version: 1.0 Message-Id: <200301242156.03464.timur.friedman@lip6.fr> X-UID: 1088 Content-Type: Multipart/Mixed; boundary="------------Boundary-00=_0QT8CSJ3HD64EM2EKKUO" Subject: [AVT] draft-ietf-avt-rtcp-report-extns-02.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --------------Boundary-00=_0QT8CSJ3HD64EM2EKKUO Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, Please find attached the latest version of the (new title) RTP Extended=20 Reports (RTP XR) draft, draft-ietf-avt-rtcp-report-extns-02.txt. This ha= s=20 just been submitted to internet-drafts@ietf.org. We have updated the draf= t=20 based upon comments from this list and from the chairs. We hope to advance to Final Call at the March IETF in San Francisco. You= r=20 comments are most welcome so that we may issue a final draft in good time= =2E Here are the changes since the previous version: * Changed title from RTCP Reporting Extensions to RTP Extended Reports (RTP XR). (Only very well known acronyms may appear in the title without expansion. RTP appears in the titles of several RFCs, RTCP in none to date.) * Reduced author list from seven authors to three editors. Created a Contributors section. Nick Duffield added as author. (No more than fi= ve names allowed on the front page authors list, mentioned by Colin.) * Added Magnus Westerlund, Dorgham Sisalem, and Adam Wolisz to the acknowledgments. * Separated normative from informative references. (Now recommended by the RFC Editor, mentioned by Colin.) * Renumbered the RTP packet type (PT) value for XR packets to 207. This would be the next available value should the RTCP feedback draft, which is in last call, become an RFC. Note that this would require changes to any other drafts based on the XR packet (RTCP Extensions for Single-Source Multicast is one). * Renumbered the block types from 1 to 7, replacing the legacy values. (Requested by Colin in the absence of a clear rationale for the legacy values.) * Rewrote the IANA Considerations section (as recommended by Colin). * Changed the required behavior for the receiver when it sees a non-zero value in a reserved field. Now the receiver must ignore the block or packet that contains this field. Previously the receiver was to ignore the field if they were unaware of any defined semantics for the field. (Allows for future definitions of these fields to call for different behavior on the part of receivers.) * All report blocks now have "Report Block" as part of their name. (This was inconsistent before.) * Some of the subsections of Section 4.7 have been combined. * Sections at the end of the document, such as the references and the copyright statement, have been reordered. References divided into Normative and Non-Normative References. * An appendix has been created for algorithms. The formatting for algorithms has been harmonized. * The discussion of per-sender and per-packet accounting for the Loss RLE Report Block (Section 4.1) has been updated, with an algorithm in the appendix. * Variable geometry removed from the Statistics Summary Report Block (Section 4.4). Now, if a statistic is not reported, the field is set to zero, but the field itself is not removed. This should considerably simplify parsing. * Clarified the wording specifying the length fields. (Thanks to Magnus Westerlund.) * Clarified how late packets are accounted as losses. (Thanks to Henning Schulzrinne and Magnus Westerlund.) * Made begin_seq and end_seq 16 bits in all cases. (Thanks to Magnus Westerlund.) * Clarified what to do if there are losses or duplicates when sending a Timestamp Report Block. (Thanks to Magnus Westerlund.) * Recommendations added to the Security Considerations section. * Gmin recommended value of 16 indicated for VoIP Metrics Report Block (Section 4.7) * RERL calculation corrected in Section 4.7. (Thanks to Magnus Westerlund.) * Burst metrics algorithm modified, and discussion updated. * Field renamed in the VoIP block: doubletalk now residual echo return lo= ss (RERL). Updated discussion of this field. * Fields reordered in VoIP block to better align on 16-bit boundaries. * Document indenting fixed to conform to that of the RTP spec. Regards, Timur Friedman --------------Boundary-00=_0QT8CSJ3HD64EM2EKKUO Content-Type: text/plain; charset="iso-8859-1"; name="draft-ietf-avt-rtcp-report-extns-02.txt" Content-Disposition: attachment; filename="draft-ietf-avt-rtcp-report-extns-02.txt" Content-Transfer-Encoding: quoted-printable INTERNET-DRAFT 24 January 2003 Internet Engineering Task Force Expires: 24 July 2003 Audio/Video Transport Working Group Timur Friedman, Paris 6 Ramon Caceres, ShieldIP Alan Clark, Telchemy Editors RTP Extended Reports (RTP XR) draft-ietf-avt-rtcp-report-extns-02.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document defines the extended report (XR) packet type for the RTP control protocol (RTCP). XR packets are composed of report blocks, and seven block types are defined here. The purpose of the extended reporting format is to convey information that supplements the six statistics that are contained in the report blocks used by RTCP's sender report (SR) and receiver report (RR) packets. Some applications, such as multicast inference of network characteristics Friedman, Caceres, and Clark, eds. [Page 1] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 (MINC) or voice over IP (VoIP) monitoring, require other and more detailed statistics. In addition to the block types defined here, additional block types may be defined in the future by adhereing to the framework that this document provides. Table of Contents 1. Introduction .............................................. 2 1.1 Terminology ............................................... 3 2. XR Packet Format .......................................... 4 3. Extended Report Block Framework ........................... 5 4. Extended Report Blocks .................................... 6 4.1 Loss RLE Report Block ..................................... 6 4.1.1 Run Length Chunk .......................................... 12 4.1.2 Bit Vector Chunk .......................................... 12 4.1.3 Terminating Null Chunk .................................... 12 4.2 Duplicate RLE Report Block ................................ 13 4.3 Timestamp Report Block .................................... 13 4.4 Statistics Summary Report Block ........................... 16 4.5 Receiver Timestamp Report Block ........................... 19 4.6 DLRR Report Block ......................................... 20 4.7 VoIP Metrics Report Block ................................. 21 4.7.1 Packet Loss and Discard Metrics ........................... 23 4.7.2 Burst Metrics ............................................. 23 4.7.3 Delay Metrics ............................................. 26 4.7.4 Signal Related Metrics .................................... 26 4.7.5 Call Quality or Transmission Quality Metrics .............. 29 4.7.6 Configuration Parameters .................................. 30 4.7.7 Jitter Buffer Parameters .................................. 31 5. IANA Considerations ....................................... 32 5.1 XR Packet Type ............................................ 32 5.2 RTP XR Block Type Registry ................................ 32 6. Security Considerations ................................... 33 A. Algorithms ................................................ 34 A.1 Sequence Number Interpretation ............................ 34 A.2 Example Burst Packet Loss Calculation ..................... 35 Intellectual Property ..................................... 37 Full Copyright Statement .................................. 38 Acknowledegments .......................................... 38 Contributors .............................................. 39 Authors' Addresses ........................................ 39 References ................................................ 40 Normative References ...................................... 40 Non-Normative References .................................. 41 1. Introduction This document defines the extended report (XR) packet type for the Friedman, Caceres, and Clark, eds. [Page 2] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 RTP control protocol (RTCP) [7]. XR packets convey information beyond that already contained in the reception report blocks of RTCP's sender report (SR) or receiver report (RR) packets. The information is of use across RTP profiles, and so is not appropriately carried in SR or RR profile-specific extensions. Information used for network management falls into this category, for instance. The definition is broken out over the three following sections of this document, starting with a general framework and finishing with the specific information conveyed. The framework defined by Section 2 contains common header information followed by a series of components called report blocks. Section 3 defines the format common to such blocks. Section 4 defines seven block types. Seven report block formats are defined by this document: - Loss RLE Report Block (Section 4.1): Run length encoding of RTP packet loss reports. - Duplicate RLE Report Block (Section 4.2): Run length encoding of reports of RTP packet duplicates. - Timestamp Report Block (Section 4.3): A list of timestamps of received RTP packets. - Statistics Summary Report Block (Section 4.4): Statistics on RTP packet sequence numbers, losses, duplicates, jitter, and TTL values. - Receiver Timestamp Report Block (Section 4.5): Receiver-end timestamps that complement the sender-end timestamps already defined for RTCP. - DLRR Report Block (Section 4.6): The delay since the last Receiver Timestamp Report Block was received, allowing non-senders to calculate round-trip times. - VoIP Metrics Report Block (Section 4.7): Metrics for monitoring Voice over IP (VoIP) calls. These blocks are defined within a minimal framework: a type field and a length field are common to all XR blocks. The purpose is to maintain flexibility and to keep overhead low. 0ther block formats, beyond the seven defined here, may be defined within this framework as the need arises. 1.1 Terminology Friedman, Caceres, and Clark, eds. [Page 3] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 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 RFC 2119 [1] and indicate requirement levels for compliance with this specification. 2. XR Packet Format The XR packet consists of a header of two 32-bit words, followed by a number, possibly zero, of extended report blocks. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=3D2|P|reserved | PT=3DXP=3D207 | length = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC/CSRC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : report blocks : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ version (V): 2 bits Identifies the version of RTP. This specification applies to RTP version two. padding (P): 1 bit If the padding bit is set, this XR packet contains some additional padding octets at the end. The semantics of this field are identical to the semantics of the padding field in the the SR packet, as defined by the RTP specification. reserved: 5 bits This field is reserved for future definition. In the absence of such definition, the bits in this field MUST be set to zero and the receiver MUST ignore any XR packet with a non-zero value in this field. packet type (PT): 8 bits Contains the constant 207 to identify this as an RTCP XR packet. This value is registered with the Internet Assigned Numbers Authority (IANA), as described in Section 5.1. length: 16 bits As described for the RTP sender report (SR) packet (see Section 6.3.1 of the RTP specification [7]). Briefly, the length of this XR packet in 32-bit words minus one, including the header and any padding. Friedman, Caceres, and Clark, eds. [Page 4] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 SSRC: 32 bits The synchronization source identifier for the originator of this XR packet. report blocks: variable length. Zero or more extended report blocks. In keeping with the extended report block framework defined below, each block MUST consist of one or more 32-bit words. 3. Extended Report Block Framework Extended report blocks are stacked, one after the other, at the end of an XR packet. An individual block's length is a multiple of 4 octets. The XR header's length field describes the total length of the packet, including these extended report blocks. Each block has block type and length fields that facilitate parsing. A receiving application can demultiplex the blocks based upon their type, and can use the length information to locate each successive block, even in the presence of block types it does not recognize. An extended report block has the following format: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT | type-specific | block length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : type-specific data : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block type (BT): 8 bits Identifies the block format. Seven block types are defined in Section 4. Additional block types may be defined in future specifications. This field's name space is managed by the Internet Assigned Numbers Authority (IANA), as described in Section 5.2. type-specific: 8 bits The use of these bits is determined by the block type definition. block length: 16 bits The length of this report block including the header, in 32-bit words minus one. If the block type definition permits, zero is an acceptable value, signifying a block that consists of only Friedman, Caceres, and Clark, eds. [Page 5] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 the BT, type-specific, and block length fields, with a null type-specific data field. type-specific data: variable length The use of this field is defined by the particular block type, subject to the constraint that it MUST be a multiple of 32 bits long. If the block type definition permits, It MAY be zero bits long. 4. Extended Report Blocks This section defines seven extended report blocks: block types for losses, duplicates, packet reception timestamps, detailed reception statistics, receiver timestamps, receiver inter-report delays, and voice over IP (VoIP) metrics. An implementation MAY ignore incoming blocks with types either not relevant or unknown to it. Additional block types MUST be registered with the Internet Assigned Numbers Authority (IANA) [5], as described in Section 5.2. 4.1 Loss RLE Report Block This block type permits detailed reporting upon individual packet receipt and loss events. Such reports can be used, for example, for multicast inference of network characteristics (MINC) [8]. With MINC, one can discover the topology of the multicast tree used for distributing a source's RTP packets, and of the loss rates along links within that tree. Or they could be used to provide raw data to a network management application. Since a Boolean trace of lost and received RTP packets is potentially lengthy, this block type permits the trace to be compressed through run length encoding. To further reduce block size, loss event reports can be systematically dropped from the trace in a mechanism called thinning that is described below and that is studied in [9]. A participant that generates a Loss RLE Report Block should favor accuracy in reporting on observed events over interpretation of those events whenever possible. Interpretation should be left to those who observe the report blocks. Following this approach implies that accounting for Loss RLE Report Blocks will differ from the accounting for the generation of the SR and RR packets described in the RTP specification [7] in the following two areas: per-sender accounting and per-packet accounting. In its per-sender accounting, an RTP session participant SHOULD NOT make the receipt of a threshold minimum number of RTP packets a condition for reporting upon the sender of those packets. This accounting technique differs from the technique described in Section Friedman, Caceres, and Clark, eds. [Page 6] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 6.2.1 and Appendix A.1 of the RTP specification that allows a threshold to determine whether a sender is considered valid. In its per-packet accounting, an RTP session participant SHOULD treat all sequence numbers as valid. This accouting technique differs from the technique described in Appendix A.1 of the RTP specification that suggests ruling a sequence number valid or invalid on the basis of its contiguity with the sequence numbers of previously received packets. Sender validity and sequence number validity are interpretations of the raw data. Such interpretations are justified in the interest, for example, of excluding the stray old packet from an unrelated session from having an effect upon the calculation of the RTCP transmission interval. The presence of stray packets might, on the other hand, be of interest to a network monitoring application. One accounting interpretation that is still necessary is for a participant to decide whether the 16 bit sequence number has rolled over. Under ordinary circumstances this is not a difficult task. For example, if packet number 65,535 (the highest possible sequence number) is followed shortly by packet number 0, it is reasonable to assume that there has been a rollover. However it is possible that the packet is an earlier one (from 65,535 packets earlier). It is also possible that the sequence numbers have rolled over multiple times, either forward or backward. The interpretation becomes more difficult when there are large gaps between the sequence numbers, even accounting for rollover, and when there are long intervals between received packets. The per-packet accounting technique mandated here is for a participant to keep track of the sequence number of the packet most recently received from a sender. For the next packet that arrives from that sender, the sequence number MUST be judged to fall no more than 32,768 packets ahead or behind the most recent one, whichever choice places it closer. In the event that both choices are equally distant (only possible when the distance is 32,768), the choice MUST be the one that does not require a rollover. Appendix A.1 presents an algorithm that implements this technique. Each block reports on a single source, identified by its SSRC. The receiver that is supplying the report is identified in the header of the RTCP packet. Choice of beginning and ending RTP packet sequence numbers for the trace is left to the application. These values are reported in the block. The last sequence number in the trace MAY differ from the sequence number reported on in any accompanying SR or RR report. Friedman, Caceres, and Clark, eds. [Page 7] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 Note that because of sequence number wrap around the ending sequence number MAY be less than the beginning sequence number. A Loss RLE Report Block MUST NOT be used to report upon a range of 65,534 or greater in the sequence number space, as there is no means to identify multiple wrap arounds. The trace described by a Loss RLE report consists of a sequence of Boolean values, one for each sequence number of the trace. A value of one represents a packet receipt, meaning that one or more packets having that sequence number have been received since the most recent wrap around of sequence numbers (or since the beginning of the RTP session if no wrap around has been judged to have occurred). A value of zero represents a packet loss, meaning that there has been no packet receipt for that sequence number as of the time of the report. If a packet with a given sequence number is received after a report of a loss for that sequence number, a later Loss RLE report MAY report a packet receipt for that sequence number. The encoding itself consists of a series of 16 bit units called chunks that describe sequences of packet receipts or losses in the trace. Each chunk either specifies a run length or a bit vector, or is a null chunk. A run length describes between 1 and 16,383 events that are all the same (either all receipts or all losses). A bit vector describes 15 events that may be mixed receipts and losses. A null chunk describes no events, and is used to to round out the block to a 32 bit word boundary. The mapping from a sequence of lost and received packets into a sequence of chunks is not necessarily unique. For example, the following trace covers 45 packets, of which the 22nd and 24th have been lost and the others received: 1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1111 1 One way to encode this would be: bit vector 1111 1111 1111 111 bit vector 1111 1101 0111 111 bit vector 1111 1111 1111 111 null chunk Another way to encode this would be: Friedman, Caceres, and Clark, eds. [Page 8] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 run of 21 receipts bit vector 0101 1111 1111 111 run of 9 receipts null chunk The choice of encoding is left to the application. As part of this freedom of choice, applications MAY terminate a series of run length and bit vector chunks with a bit vector chunk that runs beyond the sequence number space described by the report block. For example, if the 44th packet in the same sequence were lost: 1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1110 1 This could be encoded as: run of 21 receipts bit vector 0101 1111 1111 111 bit vector 1111 1110 1000 000 null chunk In this example, the last five bits of the second bit vector describe a part of the sequence number space that extends beyond the last sequence number in the trace. These bits have been set to zero. All bits in a bit vector chunk that describe a part of the sequence number space that extends beyond the last sequence number in the trace MUST be set to zero, and MUST be ignored by the receiver. A null packet MUST appear at the end of a Loss RLE Report Block if the number of run length plus bit vector chunks is odd. The null chunk MUST NOT appear in any other context. Caution should be used in sending Loss RLE Report Blocks because, even with the compression provided by run length encoding, they can easily consume bandwidth out of proportion with normal RTCP packets. The block type includes a mechanism, called thinning, that allows an application to limit report sizes. A thinning value, T, selects a subset of packets within the sequence number space: those with sequence numbers that are multiples of 2^T. Packet reception and loss reports apply only to those packets. T can vary between 0 and 15. If T is zero then every packet in the sequence number space is reported upon. If T is fifteen then one in Friedman, Caceres, and Clark, eds. [Page 9] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 every 32,768 packets is reported upon. Suppose that the trace just described begins at sequence number 13,821. The last sequence number in the trace is 13,865. If the trace were to be thinned with a thinning value of T=3D2, then the following sequence numbers would be reported upon: 13,824, 13,828, 13,832, 13,836, 13,840, 13,844, 13,848, 13,852, 13,856, 13,860, 13,864. The thinned trace would be as follows: 1 1 1 1 1 0 1 1 1 1 0 This could be encoded as follows: bit vector 1111 1011 1100 000 null chunk The last four bits in the bit vector, representing sequence numbers 13,868, 13,872, 13,876, and 13,880, extend beyond the trace and are thus set to zero and are ignored by the receiver. With thinning, the loss of the 22nd packet goes unreported because its sequence number, 13,842, is not a multiple of four. Packet receipts for all sequence numbers that are not multiples of four also go unreported. However, in this example thinning has permitted the Loss RLE Report Block to be shortened by one 32 bit word. Choice of the thinning value is left to the application. The Loss RLE Report Block has the following format: Friedman, Caceres, and Clark, eds. [Page 10] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=3D1 | rsvd. | T | block length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | begin_seq | end_seq | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | chunk 1 | chunk 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | chunk n-1 | chunk n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block type (BT): 8 bits A Loss RLE Report Block is identified by the constant 1. rsvd.: 4 bits This field is reserved for future definition. In the absence of such definition, the bits in this field MUST be set to zero and the receiver MUST ignore any Loss RLE Report Block with a non- zero value in this field. thinning (T): 4 bits The amount of thinning performed on the sequence number space. Only those packets with sequence numbers 0 mod 2^T are reported on by this block. A value of 0 indicates that there is no thinning, and all packets are reported on. The maximum thinning is one packet in every 32,768 (amounting to two packets within each 16-bit sequence space). block length: 16 bits Defined in Section 3. begin_seq: 16 bits The first sequence number that this block reports on. end_seq: 16 bits The last sequence number that this block reports on plus one. chunk i: 16 bits There are three chunk types: run length, bit vector, and terminating null, defined in the following sections. If the chunk is all zeroes then it is a terminating null chunk. Otherwise, the leftmost bit of the chunk determines its type: 0 Friedman, Caceres, and Clark, eds. [Page 11] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 for run length and 1 for bit vector. 4.1.1 Run Length Chunk 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C|R| run length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ chunk type (C): 1 bit A zero identifies this as a run length chunk. run type (R): 1 bit Zero indicates a run of 0s. One indicates a run of 1s. run length: 14 bits A value between 1 and 16,383. The value MUST not be zero for a run length chunk (zeroes in both the run type and run length fields would make the chunk a terminating null chunk). Run lengths of 15 or less MAY be described with a run length chunk despite the fact that they could also be described as part of a bit vector chunk. 4.1.2 Bit Vector Chunk 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C| bit vector | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ chunk type (C): 1 bit A one identifies this as a bit vector chunk. bit vector: 15 bits The vector is read from left to right, in order of increasing sequence number (with the appropriate allowance for wrap around). 4.1.3 Terminating Null Chunk This chunk is all zeroes. Friedman, Caceres, and Clark, eds. [Page 12] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.2 Duplicate RLE Report Block This block type permits per-sequence-number reports on duplicates in a source's RTP packet stream. Such information can be used for network diagnosis, and provide an alternative to packet losses as a basis for multicast tree topology inference. The Duplicate RLE Report Block format is identical to the Loss RLE Report Block format. Only the interpretation is different, in that the information concerns packet duplicates rather than packet losses. The trace to be encoded in this case also consists of zeros and ones, but a zero here indicates the presence of duplicate packets for a given sequence number, whereas a one indicates that no duplicates were received. The existence of a duplicate for a given sequence number is determined over the entire reporting period. For example, if packet number 12,593 arrives, followed by other packets with other sequence numbers, the arrival later in the reporting period of another packet numbered 12,593 counts as a duplicate for that sequence number. The duplicate does not need to follow immediately upon the first packet of that number. Care must be taken that a report does not cover a range of 65,534 or greater in the sequence number space. No distinction is made between the existance of a single duplicate packet and multiple duplicate packets for a given sequence number. Note also that since there is no duplicate for a lost packet, a loss is encoded as a one in a Duplicate RLE Report Block. The Duplicate RLE Report Block has the following format: Friedman, Caceres, and Clark, eds. [Page 13] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=3D2 | rsvd. | T | block length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | begin_seq | end_seq | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | chunk 1 | chunk 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | chunk n-1 | chunk n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block type (BT): 8 bits A Duplicate RLE Report Block is identified by the constant 2. rsvd.: 4 bits This field is reserved for future definition. In the absence of such definition, the bits in this field MUST be set to zero and the receiver MUST ignore any Duplicate RLE Report Block with a non-zero value in this field. thinning (T): 4 bits As defined in Section 4.1. block length: 16 bits Defined in Section 3. begin_seq: 16 bits As defined in Section 4.1. end_seq: 16 bits As defined in Section 4.1. chunk i: 16 bits As defined in Section 4.1. 4.3 Timestamp Report Block This block type permits per-sequence-number reports on packet receipt timestamps for a given source's RTP packet stream. Such information can be used for MINC inference of the topology of the multicast tree used to distribute the source's RTP packets, and of the delays along the links within that tree. It can also be used to measure partial Friedman, Caceres, and Clark, eds. [Page 14] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 path characteristics and to model distributions for packet jitter. At least one packet MUST have been received for each sequence number reported upon in this block. If this block type is used to report timestamps for a series of sequence numbers that includes lost packets, several blocks are required. If duplicate packets have been received for a given sequence number, and those packets differ in their receiver timestamps, any timestamp other than the earliest MUST NOT be reported. This is to ensure consistency among reports. Timestamps consume more bits than loss or duplicate information, and do not lend themselves to run length encoding. The use of thinning is encouraged to limit the size of Timestamp Report Blocks. The Timestamp Report Block has the following format: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=3D3 | rsvd. | T | block length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | begin_seq | end_seq | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP timestamp 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP timestamp 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP timestamp n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block type (BT): 8 bits A Timestamp Report Block is identified by the constant 3. rsvd.: 4 bits This field is reserved for future definition. In the absence of such definition, the bits in this field MUST be set to zero and the receiver MUST ignore any Timestamp Report Block with a non- zero value in this field. thinning (T): 4 bits As defined in Section 4.1. Friedman, Caceres, and Clark, eds. [Page 15] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 block length: 16 bits Defined in Section 3. begin_seq: 16 bits As defined in Section 4.1. end_seq: 16 bits As defined in Section 4.1. RTP timestamp i: 32 bits The timestamp reflects the packet arrival time at the receiver. It is preferable for the timestamp to be established at the link layer interface, or in any case as close as possible to the wire arrival time. Units and format are the same as for the timestamp in RTP data packets. As opposed to RTP data packet timestamps, in which nominal values may be used instead of system clock values in order to convey information useful for periodic playout, the receiver timestamps should reflect the actual time as closely as possible. The initial value of the timestamp is random, and subsequent timestamps are offset from this value. 4.4 Statistics Summary Report Block This block reports statistics beyond the information carried in the standard RTCP packet format, but not as fine grained as that carried in the report blocks previously described. Information is recorded about lost packets, duplicate packets, jitter measurements, and TTL values (TTL values being taken from the TTL field of IPv4 packets, if the data packets are carried over IPv4). Such information can be useful for network management. The report block contents are dependent upon a bit vector carried in the first part of the header. Not all parameters need to be reported in each block. Flags indicate which are and which are not reported. The fields corresponding to unreported parameters MUST be set to zero. The receiver MUST ignore any Statistics Summary Report Block with a non-zero value in any field flagged as unreported. The Statistics Summary Report Block has the following format: Friedman, Caceres, and Clark, eds. [Page 16] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=3D4 |L|D|J|T|resvd. | block length =3D 9 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | begin_seq | end_seq | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | lost_packets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | dup_packets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | min_jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | max_jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | avg_jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | dev_jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | min_ttl | max_ttl | avg_ttl | dev_ttl | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block type (BT): 8 bits A Statistics Summary Report Block is identified by the constant 4. loss report flag (L): 1 bit Bit set to 1 if the lost_packets field contains a report, 0 otherwise. duplicate report flag (D): 1 bit Bit set to 1 if the dup_packets field contains a report, 0 otherwise. jitter flag (J): 1 bit Bit set to 1 if the min_jitter, max_jitter, avg_jitter, and dev_jitter fields all contain reports, 0 if none of them do. TTL flag (T): 1 bit Bit set to 1 if the min_ttl, max_ttl, avg_ttl, and dev_ttl fields all contain reports, 0 if none of them do. resvd.: 4 bits This field is reserved for future definition. In the absence of such definition, all bits in this field MUST be set to zero, and Friedman, Caceres, and Clark, eds. [Page 17] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 the receiver MUST ignore any Statistics Summary Report Block with a non-zero value in this field. block length: 16 bits The constant 9, in accordance with the definition of this field in Section 3. begin_seq: 16 bits As defined in Section 4.1. end_seq: 16 bits As defined in Section 4.1. lost_packets: 32 bits Number of lost packets in the above sequence number interval. dup_packets: 32 bits Number of duplicate packets in the above sequence number interval. min_jitter: 32 bits The minimum relative transit time between two packets in the above sequence number interval. All jitter values are measured as the difference between a packet's RTP timestamp and the reporter's clock at the time of arrival, measured in the same units. max_jitter: 32 bits The maximum relative transit time between two packets in the above sequence number interval. avg_jitter: 32 bits The average relative transit time between each two packet series in the above sequence number interval. dev_jitter: 32 bits The standard deviation of the relative transit time between each two packet series in the above sequence number interval. min_ttl: 8 bits The minimum TTL value of data packets in sequence number range. max_ttl: 8 bits The maximum TTL value of data packets in sequence number range. avg_ttl: 8 bits The average TTL value of data packets in sequence number range. Friedman, Caceres, and Clark, eds. [Page 18] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 dev_ttl: 8 bits The standard deviation of TTL values of data packets in sequence number range. 4.5 Receiver Timestamp Report Block This block extends RTCP's timestamp reporting so that non-senders may also send timestamps. It recapitulates the NTP timestamp fields from the RTCP Sender Report [7, Sec. 6.3.1]. A non-sender may estimate its RTT to other participants, as proposed in [11], by sending this report block and receiving DLRR Report Blocks (see next section) in reply. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=3D5 | reserved | block length =3D 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NTP timestamp, most significant word | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NTP timestamp, least significant word | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block type (BT): 8 bits A Receiver Timestamp Report Block is identified by the constant 5. reserved: 8 bits This field is reserved for future definition. In the absence of such definition, the bits in this field MUST be set to zero and the receiver MUST ignore any Receiver Timestamp Report Block with a non-zero value in this field. block length: 16 bits The constant 2, in accordance with the definition of this field in Section 3. NTP timestamp: 64 bits Indicates the wallclock time when this block was sent so that it may be used in combination with timestamps returned in DLRR Report Blocks (see next section) from other receivers to measure round-trip propagation to those receivers. Receivers should expect that the measurement accuracy of the timestamp may be limited to far less than the resolution of the NTP timestamp. The measurement uncertainty of the timestamp is not indicated as it may not be known. A report block sender that can keep track Friedman, Caceres, and Clark, eds. [Page 19] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 of elapsed time but has no notion of wallclock time may use the elapsed time since joining the session instead. This is assumed to be less than 68 years, so the high bit will be zero. It is permissible to use the sampling clock to estimate elapsed wallclock time. A report sender that has no notion of wallclock or elapsed time may set the NTP timestamp to zero. 4.6 DLRR Report Block This block extends RTCP's delay since last sender report (DLSR) mechanism [7, Sec. 6.3.1] so that non-senders may also calculate round trip times, as proposed in [11]. It is termed DLRR for delay since last receiver report, and may be sent in response to a Receiver Timestamp Report Block (see previous section) from a receiver to allow that receiver to calculate its round trip time to the respondant. The report consists of one or more 3 word sub-blocks: one sub-block per receiver report. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=3D6 | reserved | block length | +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D= +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ | SSRC_1 (SSRC of first receiver) | sub- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ bloc= k | last RR (LRR) | 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | delay since last RR (DLRR) | +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D= +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ | SSRC_2 (SSRC of second receiver) | sub- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ bloc= k : ... : 2 +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D= +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ block type (BT): 8 bits A DLRR Report Block is identified by the constant 6. reserved: 8 bits This field is reserved for future definition. In the absence of such definition, all bits in this field MUST be set to zero, the receiver MUST ignore any DLRR Report Block with a non-zero value in this field. block length: 16 bits Defined in Section 3. Friedman, Caceres, and Clark, eds. [Page 20] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 last RR timestamp (LRR): 32 bits The middle 32 bits out of 64 in the NTP timestamp (as explained in the previous section) received as part of a Receiver Timestamp Report Block from participant SSRC_n. If no such block has been received, the field is set to zero. delay since last RR (DLRR): 32 bits The delay, expressed in units of 1/65536 seconds, between receiving the last Receiver Timestamp Report Block from participant SSRC_n and sending this DLRR Report Block. If no Receiver Timestamp Report Block has been received yet from SSRC_n, the DLRR field is set to zero (or the DLRR is omitted entirely). Let SSRC_r denote the receiver issuing this DLRR Report Block. Participant SSRC_n can compute the round-trip propagation delay to SSRC_r by recording the time A when this Receiver Timestamp Report Block is received. It calculates the total round-trip time A-LSR using the last SR timestamp (LSR) field, and then subtracting this field to leave the round-trip propagation delay as A-LSR-DLSR. This is illustrated in [7, Fig. 2]. 4.7 VoIP Metrics Report Block The VoIP Metrics Report Block provides metrics for monitoring voice over IP (VoIP) calls. These metrics include packet loss and discard metrics, delay metrics, analog metrics, and voice quality metrics. The block reports separately on packets lost on the IP channel, and those that have been received but then discarded by the receiving jitter buffer. It also reports on the combined effect of losses and discards, as both have equal effect on call quality. In order to properly assess the quality of a Voice over IP call it is desirable to consider the degree of burstiness of packet loss [10]. Following a Gilbert-Elliott model [2], a period of time, bounded by lost and/or discarded packets, with a high rate of losses and/or discards is a "burst," and a period of time between two bursts is a "gap." Bursts correspond to periods of time during which the packet loss rate is high enough to produce noticeable degradation in audio quality. Gaps correspond to periods of time during which only isolated lost packets may occur, and in general these can be masked by packet loss concealment. Delay reports include the transit delay between RTCP end points and the VoIP end system processing delays, both of which contribute to the user perceived delay. Additional metrics include signal, echo, noise, and distortion levels. Call quality metrics include R factors (as described by the E Model defined in [2]) and mean opinion scores (MOS scores). An implementation that sends these blocks SHOULD send at least one Friedman, Caceres, and Clark, eds. [Page 21] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 every ten seconds for the duration of the call, SHOULD send one whenever a CODEC type change or other significant change occurs, SHOULD send one when significant call quality degradation is detected and SHOULD send one upon call termination. Implementations MUST provide values for all the fields defined here. For certain metrics, if the value is undefined or unknown, then the specified default or unknown field value MUST be provided. The block is encoded as seven 32-bit words: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=3D7 | reserved | block length =3D 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | loss rate | discard rate | burst density | gap density | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | burst duration | gap duration | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | round trip delay | end system delay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | signal power | RERL | noise level | Gmin | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | R factor | ext. R factor | MOS-LQ | MOS-CQ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RX config | JB nominal | JB maximum | JB abs max | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block type (BT): 8 bits A VoIP Metrics Report Block is identified by the constant 7. reserved: 8 bits This field is reserved for future definition. In the absence of such definition, all bits in this field MUST be set to zero and the receiver MUST ignore any VoIP Metrics Report Block with a non-zero value in this field. block length: 16 bits The constant 6, in accordance with the definition of this field in Section 3. The remaining fields are described in the following six sections: Packet Loss and Discard Metrics, Delay Metrics, Signal Related Metrics, Call Quality or Transmission Quality Metrics, Configuration Metrics, and Jitter Buffer Parameters. Friedman, Caceres, and Clark, eds. [Page 22] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 4.7.1 Packet Loss and Discard Metrics It is very useful to distinguish between packets lost by the network and those discarded due to jitter. Both have equal effect on the quality of the voice stream however having separate counts helps identify the source of quality degradation. These fields MUST be populated. loss rate: 8 bits The fraction of RTP data packets from the source lost since the beginning of reception, expressed as a fixed point number with the binary point at the left edge of the field. This value is calculated by dividing the total number of packets lost (after the effects of applying any error protection such as FEC) by the total number of packets expected, multiplying the result of the division by 256, limiting the maximum value to 255 (to avoid overflow), and taking the integer part. The numbers of duplicated packets and discarded packets do not enter into this calculation. Since receivers cannot be required to maintain unlimited buffers, a receiver MAY categorize late-arriving packets as lost. The degree of lateness that triggers a loss SHOULD be significantly greater than that which triggers a discard. discard rate: 8 bits The fraction of RTP data packets from the source that have been discarded since the beginning of reception, due to late or early arrival, under-run or overflow at the receiving jitter buffer. This value is expressed as a fixed point number with the binary point at the left edge of the field. It is calculated by dividing the total number of packets discarded (excluding duplicate packet discards) by the total number of packets expected, multiplying the result of the division by 256, limiting the maximum value to 255 (to avoid overflow), and taking the integer part. 4.7.2 Burst Metrics A burst, informally, is a period of high packet losses and/or discards. Formally, a burst is defined as a longest sequence of packets bounded by lost or discarded packets with the constraint that within a burst any sequence of successive packets that were received, and not discarded due to delay variation, is of length less than a value Gmin. A gap, informally, is a period of low packet losses and/or discards. Formally, a gap is defined as any of the following: (a) the period from the start of an RTP session to the receipt time of the last Friedman, Caceres, and Clark, eds. [Page 23] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 received packet before the first burst, (b) the period from the end of the last burst to either the time of the report or the end of the RTP session, whichever comes first, or (c) the period of time between two bursts. For the purpose of determining if a lost or discarded packet near the start or end of an RTP session is within a gap or a burst it is assumed that the RTP session is preceded and followed by at least Gmin received packets, and that the time of the report is followed by at least Gmin received packets. A gap has the property that any lost or discarded packets within the gap must be preceded and followed by at least Gmin packets that were received and not discarded. This gives a maximum loss/discard density within a gap of: 1 / (Gmin + 1). A Gmin value of 16 is RECOMMENDED as it results in gap characteristics that correspond to good quality (i.e. low packet loss rate, a minimum distance of 16 received packets between lost packets) and hence differentiates nicely between good and poor quality periods. For example, a 1 denotes a received, 0 a lost, and X a discarded packet in the following pattern covering 64 packets: 11110111111111111111111X111X1011110111111111111111111X111111111 |---------gap----------|--burst---|------------gap------------| The burst consists of the twelve packets indicated above, starting at a discarded packet and ending at a lost packet. The first gap starts at the beginning of the session and the second gap ends at the time of the report. If the packet spacing is 10 ms and the Gmin value is the recommended value of 16, the burst duration is 120 ms, the burst density 0.33, the gap duration 230 ms + 290 ms =3D 520 ms, and the gap density 0.04. This would result in reported values as follows (see field descriptions for semantics and details on how these are calculated): loss density 12, which corresponds to 5% discard density 12, which corresponds to 5% burst density 84, which corresponds to 33% gap density 10, which corresponds to 4% burst duration 120, value in milliseconds gap duration 520, value in milliseconds Friedman, Caceres, and Clark, eds. [Page 24] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 burst density: 8 bits The fraction of RTP data packets within burst periods since the beginning of reception that were either lost or discarded. This value is expressed as a fixed point number with the binary point at the left edge of the field. It is calculated by dividing the total number of packets lost or discarded (excluding duplicate packet discards) within burst periods by the total number of packets expected within the burst periods, multiplying the result of the division by 256, limiting the maximum value to 255 (to avoid overflow), and taking the integer part. gap density: 8 bits The fraction of RTP data packets within inter-burst gaps since the beginning of reception that were either lost or discarded. The value is expressed as a fixed point number with the binary point at the left edge of the field. It is calculated by dividing the total number of packets lost or discarded (excluding duplicate packet discards) within gap periods by the total number of packets expected within the gap periods, multiplying the result of the division by 256, limiting the maximum value to 255 (to avoid overflow), and taking the integer part. burst duration: 16 bits The mean duration, expressed in milliseconds, of the burst periods that have occurred since the beginning of reception. The duration of each period is calculated based upon the packets that mark the beginning and end of that period. It is equal to the timestamp of the end packet, plus the duration of the end packet, minus the timestamp of the beginning packet. If the actual values are not available, estimated values MUST be used. If there have been no burst periods, the burst duration value MUST be zero. gap duration: 16 bits The mean duration, expressed in milliseconds, of the gap periods that have occurred since the beginning of reception. The duration of each period is calculated based upon the packet that marks the end of the prior burst and the packet that marks the beginning of the subsequent burst. It is equal to the timestamp of the subsequent burst packet, minus the timestamp of the prior burst packet, plus the duration of the prior burst packet. If the actual values are not available, estimated values MUST be used. In the case of a gap that occurs at the beginning of reception, the sum of the timestamp of the prior burst packet and the duration of the prior burst packet are replaced by the reception start time. In the case of a gap that occurs at the end of reception, the timestamp of the subsequent burst packet Friedman, Caceres, and Clark, eds. [Page 25] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 is replaced by the reception end time. If there have been no gap periods, the gap duration value MUST be zero. 4.7.3 Delay Metrics For the purpose of the following definitions, the RTP interface is the interface between the RTP instance and the voice application (i.e. FEC, de-interleaving, de-multiplexing, jitter buffer). For example, the time delay due to RTP payload multiplexing would be considered to be part of the voice application or end-system delay whereas delay due to multiplexing RTP frames within a UDP frame would be considered part of the RTP reported delay. This distinction is consistent with the use of RTCP for delay measurements. round trip delay: 16 bits The most recently calculated round trip time between RTP interfaces, expressed in milliseconds. This value is the time of receipt of the most recent RTCP packet from source SSRC, minus the LSR (last SR) time reported in its SR (sender report), minus the DLSR (delay since last SR) reported in its SR. A non-zero LSR value is REQUIRED in order to calculate round trip delay. A value of 0 is permissible during the first two or three RTCP exchanges as insufficient data may be available to determine delay however MUST be populated as soon as a delay estimate is available. end system delay: 16 bits The most recently estimated end system delay, expressed in milliseconds. End system delay is defined as the total encoding, decoding and jitter buffer delay determined at the reporting endpoint. This is the time required for an RTP frame to be buffered, decoded, converted to analog form, looped back at the local analog interface, encoded, and made available for transmission as an RTP frame. The manner in which this value is estimated is implementation dependent. This parameter MUST be provided in all VoIP metrics reports. Note that the one way symmetric VoIP segment delay may be calculated from the round trip and end system delays as follows. If the round trip delay is denoted RTD and the end system delays associated with the two endpoints are ESD(A) and ESD(B) then: one way symmetric voice path delay =3D ( RTD + ESD(A) + ESD(B) ) / 2 4.7.4 Signal Related Metrics Friedman, Caceres, and Clark, eds. [Page 26] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 The following metrics are intended to provide real time information related to the non-packet elements of the voice over IP system to assist with the identification of problems affecting call quality. The values identified below must be determined for the received audio signal. The information required to populate these fields may not be available in all systems, although it is strongly recommended that this data SHOULD be provided to support problem diagnosis. signal power: 8 bits The voice signal relative level is defined as the ratio of the signal level to overflow signal level, expressed in decibels as a signed integer in two's complement form. This is measured only for packets containing speech energy. The intent of this metric is not to provide a precise measurement of the signal level but to provide a real time indication that the signal level may be excessively high or low. If the full range (overflow level) of the Vocoder's digital to analog conversion function is +/- L and the value of a decoded sample during a talkspurt is V then the signal level is given by: signal level =3D 10 log10 ( mean( abs(V) / L ) ) A value of 127 indicates that this parameter is unavailable. residual echo return loss (RERL): 8 bits The residual echo return loss is defined as the sum of the measured echo return loss (ERL) and the echo return loss enhancement (ERLE) expressed in dB as a signed integer in two's complement form. It defines the ratio of a transmitted voice signal that is reflected back to the talker. A low level of echo return loss (say less than 20 dB) in conjunction with some delay can lead to hollowness or audible echo. A high level of echo return loss (say over 40 dB) is preferable. The ERL and ERLE parameters are often available directly from the echo cancellor contained within the VoIP end system. They relate to the echo on the external network attached to the end point. In the case of a VoIP gateway this would be line echo that typically occurs at 2-4 wire conversion points in the network. Echo return loss from typical 2-4 wire conversions can be in the 8-12 dB range. A line echo cancellor can provide an ERLE of 30 dB or more and hence reduce this to 40-50 dB. In the case of an IP phone this could be residual acoustic echo from speakerphone operation, and may more correctly be termed terminal coupling loss (TCL). A typical handset would result in 40-50 dB of echo due to acoustic feedback. Typical values for RERL are as follows: Friedman, Caceres, and Clark, eds. [Page 27] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 (i) IP gateway connected to circuit switched network with 2 wire loop Without echo cancellation, typical 2-4 wire convertor ERL of 12 dB RERL =3D ERL + ERLE =3D 12 + 0 =3D 12 dB (ii) IP gateway connected to circuit switched network with 2 wire loop With echo cancellor that improves echo by 30 dB RERL =3D ERL + ERLE =3D 12 + 30 =3D 42 dB (iii) IP phone with conventional handset Acoustic coupling from handset speaker to microphone 40 dB Residual echo return loss =3D TCL =3D 40 dB If we denote the "local" end of the VoIP path as A and the remote end as B and if the sender loudness rating (SLR) and receiver loudness rating (RLR) are known for A (default values 8 dB and 2 dB respectively), then the echo loudness level at end A (talker echo loudness rating or TELR) is given by: TELR(A) =3D SRL(A) + ERL(B) + ERLE(B) + RLR(A) TELR(B) =3D SRL(B) + ERL(A) + ERLE(A) + RLR(B) Hence in order to incorporate echo into a voice quality estimate at the A end of a VoIP connection it is desirable to send the ERL + ERLE value from B to A. For an IP phone with handset this metric MUST be set to the designed or measured terminal coupling loss, which would typically be 40-50 dB. For a PC softphone or speakerphone this metric MUST be set to either the value reported by the acoustic echo cancellor or to 127 to indicate an undefined value. For an IP gateway with ERL and ERLE measurements this metric MUST be reported as ERL + ERLE. For an IP gateway without ERL and ERLE measurement capability then this metric MUST be reported as 12 dB if line echo cancellation is disabled and 40 dB if line echo cancellation is enabled. noise level: 8 bits The noise level is defined as the ratio of the silent period back ground noise level to overflow signal power, expressed in decibels as a signed integer in two's complement form. If the full range (overflow level) of the Vocoder's digital to analog conversion function is +/- L and the value of a decoded sample during a silence period is V then the noise level is given by Friedman, Caceres, and Clark, eds. [Page 28] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 noise level =3D 10 log10 ( mean( abs(V) / L ) ) A value of 127 indicates that this parameter is unavailable. Gmin See Configuration Parameters (Section 4.7.6, below). 4.7.5 Call Quality or Transmission Quality Metrics The following metrics are direct measures of the call quality or transmission quality, and incorporate the effects of CODEC type, packet loss, discard, burstiness, delay etc. These metrics may not be available in all systems however SHOULD be provided in order to support problem diagnosis. R factor: 8 bits The R factor is a voice quality metric describing the segment of the call that is carried over this RTP session. It is expressed as an integer in the range 0 to 100, with a value of 94 corresponding to "toll quality" and values of 50 or less regarded as unusable. This metric is defined as including the effects of delay, consistent with ITU-T G.107 [4] and ETSI TS 101 329-5 [2]. A value of 127 indicates that this parameter is unavailable. ext. R factor: 8 bits The external R factor is a voice quality metric describing the seg ment of the call that is carried over a network segment external to the RTP segment, for example a cellular network. Its values are interpreted in the same manner as for the RTP R factor. This metric is defined as including the effects of delay, consistent with ITU-T G.107 [4] and ETSI TS 101 329-5 [2], and relates to the outward voice path from the Voice over IP termination for which this metrics block applies. A value of 127 indicates that this parameter is unavailable. Note that an overall R factor may be estimated from the RTP segment R factor and the external R factor, as follows: R total =3D RTP R factor + ext. R factor - 94 MOS-LQ: 8 bits The estimated mean opinion score for listening quality (MOS-LQ) is a voice quality metric on a scale from 1 to 5, in which 5 represents excellent and 1 represents unacceptable. This metric is defined as not including the effects of delay and can be Friedman, Caceres, and Clark, eds. [Page 29] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 compared to MOS scores obtained from listening quality (ACR) tests. It is expressed as an integer in the range 10 to 50, corresponding to MOS x 10. For example, a value of 35 would correspond to an estimated MOS score of 3.5. A value of 127 indicates that this parameter is unavailable. MOS-CQ: 8 bits The estimated mean opinion score for conversational quality (MOS-CQ) is defined as including the effects of delay and other effects that would affect conversational quality. The metric may be calculated by converting an R factor determined according to ITU-T G.107 [4] or ETSI TS 101 329-5 [2] into an estimated MOS using the equation specified in G.107. It is expressed as an integer in the range 10 to 50, corresponding to MOS x 10, as for MOS-LQ. A value of 127 indicates that this parameter is unavailable. 4.7.6 Configuration Parameters Gmin: 8 bits The gap threshold. This field contains the value used for this report block to determine if a gap exists. The recommended value of 16 corresponds to a burst period having a minimum density of 6.25% of lost or discarded packets, which may cause noticeable degradation in call quality; during gap periods, if packet loss or dis card occurs, each lost or discarded packet would be preceded by and followed by a sequence of at least 16 received non-discarded packets. Note that lost or discarded packets that occur within Gmin packets of a report being generated may be reclassified as being part of a burst or gap in later reports. ETSI TS 101 329-5 [2] defines a computationally efficient algorithm for measuring burst and gap density using a packet loss/discard event driven approach. This algorithm is reproduced in Appendix A.2 of the present document. Gmin MUST not be zero and MUST be provided. receiver configuration byte (RX config): 8 bits This byte consists of the following fields: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |PLC|JBA|JB rate| +-+-+-+-+-+-+-+-+ Friedman, Caceres, and Clark, eds. [Page 30] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 packet loss concealment (PLC): 2 bits Standard (11) / enhanced (10) / disabled (01) / unspecified (00). When PLC =3D 11 then a simple replay or interpolation algorithm is being used to fill-in the missing packet. This is typically able to conceal isolated lost packets with loss rates under 3%. When PLC =3D 10 then an enhanced interpolation algorithm is being used. This would typically be able to conceal lost packets for loss rates of 10% or more. When PLC =3D 01 then silence is inserted in place of lost packets. When PLC =3D 00 then no information is available concerning the use of PLC however for some CODECs this may be inferred. jitter buffer adaptive (JBA): 2 bits Adaptive (11) / non-adaptive (10) / reserved (01)/ unknown (00). When the jitter buffer is adaptive then its size is being dynamically adjusted to deal with varying levels of jitter. When non-adaptive, the jitter buffer size is maintained at a fixed level. When either adaptive or non- adaptive modes are specified then the jitter buffer size parameters below MUST be specified. jitter buffer rate (JB rate): 4 bits J =3D adjustment rate (0-15). This represents the implementation specific adjustment rate of a jitter buffer in adaptive mode. This parameter is defined in terms of the approximate time taken to fully adjust to a step change in peak to peak jitter from 30 ms to 100 ms such that: adjustment time =3D 2 * J * frame size (ms) This parameter is intended only to provide a guide to the degree of "aggressiveness" of a an adaptive jitter buffer and may be estimated. A value of 0 indicates that the adjustment time is unknown for this implementation. 4.7.7 Jitter Buffer Parameters jitter buffer nominal size in frames (JB nominal): 8 bits This is the current nominal fill point within the jitter buffer, which corresponds to the nominal jitter buffer delay for packets that arrive exactly on time. This parameter MUST be provided for both fixed and adaptive jitter buffer implementations. jitter buffer maximum size in frames (JB maximum): 8 bits This is the current maximum jitter buffer level corresponding to the earliest arriving packet that would not be discarded. In simple queue implementations this may correspond to the nominal Friedman, Caceres, and Clark, eds. [Page 31] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 size. In adaptive jitter buffer implementations this value may dynamically vary up to JB abs max (see below). This parameter MUST be provided for both fixed and adaptive jitter buffer implementations. jitter buffer absolute maximum size in frames (JB abs max): 8 bits This is the absolute maximum size that the adaptive jitter buffer can reach under worst case jitter conditions. This parameter MUST be provided for adaptive jitter buffer implementations and its value MUST be set to JB maximum for fixed jitter buffer implementations. 5. IANA Considerations This document defines a new RTP packet type, the extended report (XR) type, within the existing Internet Assigned Numbers Authority (IANA) registry of RTP RTCP Control Packet Types. This document also defines a new IANA registry: the registry of RTP XR Block Types. Within this new registry, this document defines an initial set of seven block types and describes how the remaining types are to be allocated. 5.1 XR Packet Type The IANA SHALL register the RTP extended report (XR) packet defined by this document as packet type 207 in the registry of RTP RTCP Control Packet types (PT). 5.2 RTP XR Block Type Registry The IANA SHALL create the RTP XR Block Type Registry to cover the name space of the extended report block type (BT) field specified in Section 3 of this document. The BT field contains eight bits, allowing 256 values. The IANA SHALL manage the RTP XR Block Type Registry according to the Specification Required policy of RFC 2434 [6]. Future specifications SHOULD attribute block type values in strict numeric order following the values attributed in this document: Friedman, Caceres, and Clark, eds. [Page 32] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 BT name -- ---- 1 Loss RLE Report Block 2 Duplicate RLE Report Block 3 Timestamp Report Block 4 Statistics Summary Report Block 5 Receiver Timestamp Report Block 6 DLRR Report Block 7 VoIP Metrics Report Block Furthermore, future specifications SHOULD avoid the values 0 and 255. Doing so facilitates packet validity checking, since all-zeros and all-ones are values that might commonly be found in ill-formed packets. 6. Security Considerations This document extends the RTCP reporting mechanism. The security considerations that apply to RTCP reports also apply to XR reports. This section details the additional security considerations that apply to the extensions. The extensions introduce heightened confidentiality concerns. Standard RTCP reports contain a limited number of summary statistics. The information contained in XR reports is both more detailed and more extensive (covering a larger number of parameters). The per- packet information contained in Loss RLE, Duplicate RLE, and Timestamp Report Blocks facilitates MINC inference of multicast distribution trees for RTP data packets, and inference of link characteristics such as loss and delay. This inference reveals information that might otherwise be considered confidential to autonomous system administrators. The VoIP Metrics Report Block provides information on the quality of ongoing voice calls. Though such information might be carried in application specific format in standard RTP sessions, making it available in a standard format here makes it more available to potential eavesdroppers. No new mechanisms are introduced in this document to ensure confidentiality. Standard encryption procedures can be used when confidentiality is a concern to end hosts. Autonomous system administrators concerned about the loss of confidentiality regarding their networks can encrypt traffic, or filter it to exclude RTCP packets containing the XR report blocks concerned. Any encryption or filtering of XR report blocks entails a loss of monitoring information to third parties. For example, a network that establishes a tunnel to encrypt VoIP Report Blocks denies that Friedman, Caceres, and Clark, eds. [Page 33] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 information to the service providers traversed by the tunnel. The service providers cannot then monitor or respond to the quality of the VoIP calls that they carry, potentially creating problems for the network's users. As a default, XR packets SHOULD NOT be encrypted or filtered. The extensions also make certain denial of service attacks easier. This is because of the potential to create RTCP packets much larger than average with the per packet reporting capabilities of the Loss RLE, Duplicate RLE, and Timestamp Report Blocks. Because of the automatic bandwidth adjustment mechanisms in RTCP, if some session participants are sending large RTCP packets, all participants will see their RTCP reporting intervals lengthened, meaning they will be able to report less frequently. To limit the effects of large packets, even in the absence of denial of service attacks, applications SHOULD limit the size of XR report blocks and employ the thinning techniques described in this document in order to fit reports into the space available. A. Algorithms A.1 Sequence Number Interpretation This the algorithm suggested by Section 4.1 for keeping track of the sequence numbers from a given sender. It implements the accounting practice required for the generation of Loss RLE Report Blocks. This algorithm keeps track of 16 bit sequence numbers by translating them into a 32 bit sequence number space. The first packet received from a source is considered to have arrived roughly in the middle of that space. Each packet that follows is placed either ahead or behind the prior one in this 32 bit space, depending upon which choice would place it closer (or, in the event of a tie, which choice would not require a rollover in the 16 bit sequence number). // The reference sequence number is an extended sequence number // that serves as the basis for determining whether a new 16 bit // sequence number comes earlier or later in the 32 bit sequence // space. u_int32 _src_ref_seq; bool _uninitialized_src_ref_seq; // Place seq into a 32-bit sequence number space based upon a // heuristic for its most likely location. u_int32 extend_seq(const u_int16 seq) { u_int32 extended_seq, seq_a, seq_b, diff_a, diff_b; if(_uninitialized_src_ref_seq) { Friedman, Caceres, and Clark, eds. [Page 34] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 // This is the first sequence number received. Place // it in the middle of the extended sequence number // space. _src_ref_seq =3D seq | 0x80000000u; _uninitialized_src_ref_seq =3D false; extended_seq =3D _src_ref_seq; } else { // Prior sequence numbers have been received. // Propose two candidates for the extended sequence // number: seq_a is without wraparound, seq_b with // wraparound. seq_a =3D seq | (_src_ref_seq & 0xFFFF0000u); if(_src_ref_seq < seq_a) { seq_b =3D seq_a - 0x00010000u; diff_a =3D seq_a - _src_ref_seq; diff_b =3D _src_ref_seq - seq_b; } else { seq_b =3D seq_a + 0x00010000u; diff_a =3D _src_ref_seq - seq_a; diff_b =3D seq_b - _src_ref_seq; } // Choose the closer candidate. If they are equally // close, the choice is somewhat arbitrary: we choose // the candidate for which no rollover is necessary. if(diff_a < diff_b) { extended_seq =3D seq_a; } else { extended_seq =3D seq_b; } // Set the reference sequence number to be this most // recently-received sequence number. _src_ref_seq =3D extended_seq; } // Return our best guess for a 32-bit sequence number that // corresponds to the 16-bit number we were given. return extended_seq; } A.2 Example Burst Packet Loss Calculation. This is an algorithm for measuring the burst characteristics for the Friedman, Caceres, and Clark, eds. [Page 35] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 VoIP Metrics Report Block (Section 4.7). It is reproduced from ETSI TS 101 329-5 [2]. The algorithm is event driven and hence extremely computationally efficient. Given the following definition of states: state 1 =3D received a packet during a gap state 2 =3D received a packet during a burst state 3 =3D lost a packet during a burst state 4 =3D lost an isolated packet during a gap The "c" variables below correspond to state transition counts, i.e. c14 is the transition from state 1 to state 4. It is possible to infer one of a pair of state transition counts to an accuracy of 1 which is generally sufficient for this application. "pkt" is the count of packets received since the last packet was declared lost or discarded and "lost" is the number of packets lost within the current burst. "packet_lost" and "packet_discarded" are boolean variables that indicate if the event that resulted in this function being invoked was a lost or discarded packet. if(packet_lost) { loss_count++; } if(packet_discarded) { discard_count++; } if(!packet_lost && !packet_discarded) { pkt++; } else { if(pkt >=3D gmin) { if(lost =3D=3D 1) { c14++; } else { c13++; } lost =3D 1; c11 +=3D pkt; } else { lost++; if(pkt =3D=3D 0) { c33++; Friedman, Caceres, and Clark, eds. [Page 36] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 } else { c23++; c22 +=3D (pkt - 1); } } pkt =3D 0; } At each reporting interval the burst and gap metrics can be calculated as follows. // Calculate additional transition counts. c31 =3D c13; c32 =3D c23; ctotal =3D c11 + c14 + c13 + c22 + c23 + c31 + c32 + c33; // Calculate burst and densities. p32 =3D c32 / (c31 + c32 + c33); if((c22 + c23) < 1) { p23 =3D 1; } else { p23 =3D 1 - c22/(c22 + c23); } burst_density =3D 256 * p23 / (p23 + p32); gap_density =3D 256 * c14 / (c11 + c14); // Calculate burst and gap durations in ms m =3D frameDuration_in_ms * framesPerRTPPkt; gap_length =3D (c11 + c14 + c13) * m / c13; burst_length =3D ctotal * m / c13 - lgap; /* calculate loss and discard densities */ loss_density =3D 256 * loss_count / ctotal; discard_density =3D 256 * discard_count / ctotal; Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP 11 [3]. Copies of claims of rights made available for publication and any assurances Friedman, Caceres, and Clark, eds. [Page 37] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgements We thank the following people: Colin Perkins, Steve Casner, and Henning Schulzrinne for their considered guidance; Sue Moon for helping foster collaboration between the authors; Magnus Westerlund for his detailed comments; Mounir Benzaid for drawing our attention to the reporting needs of MLDA; and Dorgham Sisalem and Adam Wolisz for encouraging us to incorporate MLDA block types. Friedman, Caceres, and Clark, eds. [Page 38] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 Contributors The following people are the authors of this document: Kevin Almeroth, UCSB Ramon Caceres, ShieldIP Alan Clark, Telchemy Robert Cole, AT&T Labs Nick Duffield, AT&T Labs-Research Timur Friedman, Paris 6 Kaynam Hedayat, Brix Networks Kamil Sarac, UT Dallas The principal people to contact regarding the individual report blocks described in this document are as follows: sec. report block principal contributors ---- ------------ ---------------------- 4.1 Loss RLE Report Block Friedman, Caceres, Duffield 4.2 Duplicate RLE Report Block Friedman, Caceres, Duffield 4.3 Timestamp Report Block Friedman, Caceres, Duffield 4.4 Statistics Summary Report Block Almeroth, Sarac 4.5 Receiver Timestamp Report Block Friedman 4.6 DLRR Report Block Friedman 4.7 VoIP Metrics Report Block Clark, Cole, Hedayat Authors' Addresses Kevin Almeroth Department of Computer Science University of California Santa Barbara, CA 93106 USA Ramon Caceres ShieldIP, Inc. 11 West 42nd Street, 31st Floor New York, NY 10036 USA Alan Clark Telchemy Incorporated 3360 Martins Farm Road, Suite 200 Suwanee, GA 30024 USA Tel: +1 770 614 6944 Fax: +1 770 614 3951 Friedman, Caceres, and Clark, eds. [Page 39] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 Robert Cole AT&T Labs 330 Saint Johns Street, 2nd Floor Havre de Grace, MD 21078 USA Tel: +1 410 939 8732 Fax: +1 410 939 8732 Nick Duffield AT&T Labs-Research 180 Park Avenue, P.O. Box 971 Florham Park, NJ 07932-0971 USA Tel: +1 973 360 8726 Fax: +1 973 360 8050 Timur Friedman Universite Pierre et Marie Curie (Paris 6) Laboratoire LiP6-CNRS 8, rue du Capitaine Scott 75015 PARIS France Tel: +33 1 44 27 71 06 Fax: +33 1 44 27 74 95 Kaynam Hedayat Brix Networks 285 Mill Road Chelmsford, MA 01824 USA Tel: +1 978 367 5600 Fax: +1 978 367 5700 Kamil Sarac Department of Computer Science (ES 4.207) Eric Jonsson School of Engineering & Computer Science University of Texas at Dallas Richardson, TX 75083-0688 USA Tel: +1 972 883 2337 Fax: +1 972 883 2349 References The references are divided into normative references and non- normative references. Normative References [1] S. Bradner, "Key words for use in RFCs to indicate requirement levels," BCP 14, RFC 2119, IETF, March 1997. Friedman, Caceres, and Clark, eds. [Page 40] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 [2] ETSI, "Quality of Service (QoS) measurement methodologies," ETSI TS 101 329-5 V1.1.1 (2000-11), November 2000. [3] R. Hovey and S. Bradner, "The Organizations Involved in the IETF Standards Process," best current practice BCP 11, RFC 2028, IETF, October 1996. [4] ITU-T, "The E-Model, a computational model for use in transmission planning," Recommendation G.107 (05/00), May 2000. [5] J. Reynolds and J. Postel, "Assigned Numbers," standard STD 2, RFC 1700, IETF, October 1994. [6] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs," best current practice BCP 26, RFC 2434, IETF, October 1998. [7] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A transport protocol for real-time applications," RFC 1889, IETF, February 1996. Non-Normative References [8] A. Adams, T. Bu, R. Caceres, N. G. Duffield, T. Friedman, J. Horowitz, F. Lo Presti, S. B. Moon, V. Paxson, and D. Towsley, "The Use of End-to-End Multicast Measurements for Characterizing Internal Network Behavior," IEEE Communications Magazine, May 2000. [9] R. Caceres, N. G. Duffield, and T. Friedman, "Impromptu measurement infrastructures using RTP," Proc. IEEE Infocom 2002. [10] A. D. Clark, "Modeling the Effects of Burst Packet Loss and Recency on Subjective Voice Quality," Proc. IP Telephony Workshop 2001. [11] D. Sisalem and A. Wolisz, "MLDA: A TCP-friendly Congestion Control Framework for Heterogeneous Multicast Environments", Proc. IWQoS 2000. Friedman, Caceres, and Clark, eds. [Page 41] =0C --------------Boundary-00=_0QT8CSJ3HD64EM2EKKUO-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Sat Jan 25 22:42:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02649 for ; Sat, 25 Jan 2003 22:42:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0Q42FA27534 for avt-archive@odin.ietf.org; Sat, 25 Jan 2003 23:02:15 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0Q414J27508; Sat, 25 Jan 2003 23:01:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0Q3kRJ27214 for ; Sat, 25 Jan 2003 22:46:27 -0500 Received: from mailman.packetdesign.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02223 for ; Sat, 25 Jan 2003 22:26:09 -0500 (EST) Received: from packetdesign.com (main-fw-eth1.packetdesign.com [192.168.0.254]) by mailman.packetdesign.com (8.12.6/8.12.3) with ESMTP id h0Q3S7dv044681; Sat, 25 Jan 2003 19:28:08 -0800 (PST) (envelope-from casner@acm.org) Date: Sat, 25 Jan 2003 19:45:04 -0800 (PST) From: Stephen Casner To: David.Leon@nokia.com cc: mbaugher@cisco.com, , Subject: RE: [AVT] Re: Security for draft-ietf-avt-rtp-retransmission In-Reply-To: <7CA3477F476D7F4FB82F02960B79CEBD017E4F8D@daebe008.americas.nokia.com> Message-ID: <20030125193902.W1972-100000@oak.packetdesign.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , On Fri, 24 Jan 2003 David.Leon@nokia.com wrote: > We're thus thinking of addressing how retransmission should work > with SRTP in a new draft. This draft would in particular define and > register SAVPF. I agree, as apparently we all do, that this is the right approach. It allows both AVPF and SRTP to proceed without any dependency on each other. It will also give time to think about any issues that must be addressed in combining the two profiles, and to test out the idea. From Elisabetta's message, it is clear that there are at least a few words that need to be said to clarify the points she mentioned. That is exactly the kind of thing I envisioned when I have argued on numerous occasions that each _needed_ combination of profiles should be defined as a new profile with a new name, rather than simply specifying a generic means to identify any combination of profiles. -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Jan 27 07:05:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13202 for ; Mon, 27 Jan 2003 07:05:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0RCQHi16795 for avt-archive@odin.ietf.org; Mon, 27 Jan 2003 07:26:17 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RCOoJ16690; Mon, 27 Jan 2003 07:24:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RCKWJ16498 for ; Mon, 27 Jan 2003 07:20:32 -0500 Received: from igloo.df.lth.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13060 for ; Mon, 27 Jan 2003 06:59:34 -0500 (EST) Received: from localhost (triad@localhost) by igloo.df.lth.se (8.10.2+Sun/8.9.3) with ESMTP id h0RC2pt27209; Mon, 27 Jan 2003 13:02:51 +0100 (MET) Date: Mon, 27 Jan 2003 13:02:51 +0100 (MET) From: Linus Walleij To: Harald Tveit Alvestrand cc: msmith@xiph.org, , , , Subject: Re: Fwd: Re: [AVT] Re: New I-Ds for Ogg technologies (Vorbis over RTP, Ogg file format, Mimetypes) In-Reply-To: <159850000.1043399227@askvoll.hjemme.alvestrand.no> Message-ID: X-Justice: You know what you doing. MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , On Fri, 24 Jan 2003, Harald Tveit Alvestrand wrote: > 2) how to make sure no two codecs pick the same identifier string? > (the "registry" problem) This is a natural pointer to the IANA, in case you want to establish something rock-solid. Not that I know if they would like to do this, but it it is to be a widely accepted standard for codec identification, IANA would be the place to store the strings. Someone who knows how registry issues have been handled in the past, please step up. Alternatively, you could list the magic strings available today, and require extensions to file further informational RFCs for the additions. (Sort of sticky and slow in comparison to IANA handling it.) I also would like to hear the "official" Xiph.org view on this subject. Michael? Yours, Linus Walleij _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Jan 27 07:48:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14597 for ; Mon, 27 Jan 2003 07:48:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0RD8uc19842 for avt-archive@odin.ietf.org; Mon, 27 Jan 2003 08:08:56 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RD7KJ19615; Mon, 27 Jan 2003 08:07:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RD4qJ19001 for ; Mon, 27 Jan 2003 08:04:52 -0500 Received: from tx1.wvinternetservices.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14464 for ; Mon, 27 Jan 2003 07:43:53 -0500 (EST) Received: from a (63-144-68-24.citynet.net [63.144.68.24]) by tx1.wvinternetservices.com (8.12.7/8.12.6=Outbound) with SMTP id h0RDpmqI008815 for ; Mon, 27 Jan 2003 08:51:49 -0500 Message-ID: <000701c2c601$f385e2e0$1844903f@a> From: "Bill Cunningham" To: Date: Mon, 27 Jan 2003 07:45:16 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4920.2300 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 Content-Transfer-Encoding: 7bit Subject: [AVT] ADO codecs Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I know I'm tired of trying to watch an av stream and their out of sync. Then back in and out again. If a video requires 5M bitstream to be viewed properly, will codecs ever completely correct this problem? Or will high bandwidth rates? _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Jan 27 11:01:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18256 for ; Mon, 27 Jan 2003 11:01:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0RGLpu31475 for avt-archive@odin.ietf.org; Mon, 27 Jan 2003 11:21:51 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RGEoJ31157; Mon, 27 Jan 2003 11:14:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0R7tWJ32259 for ; Mon, 27 Jan 2003 02:55:32 -0500 Received: from osiris.lip6.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08903 for ; Mon, 27 Jan 2003 02:34:23 -0500 (EST) Received: from tibre.lip6.fr (tibre.lip6.fr [132.227.74.2]) by osiris.lip6.fr (8.12.4/jtpda-5.4+victor) with ESMTP id h0R7bBbk022802 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) ; Mon, 27 Jan 2003 08:37:11 +0100 X-pt: osiris.lip6.fr Received: from minerve.lip6.fr (doris.ipv6.lip6.fr [132.227.72.166]) by tibre.lip6.fr (8.11.6/8.11.3) with ESMTP id h0R7bA326159; Mon, 27 Jan 2003 08:37:10 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by minerve (8.11.6/8.8.6) id h0OKu3v01831; Fri, 24 Jan 2003 21:56:03 +0100 From: Timur Friedman To: avt@ietf.org Date: Fri, 24 Jan 2003 21:56:03 +0100 User-Agent: KMail/1.4.3 Cc: Ramon Caceres , Alan Clark , Kevin Almeroth , Kamil Sarac , Robert Cole , Kaynam Hedayat , Nick Duffield References: <200301242135.31937.timur.friedman@lip6.fr> In-Reply-To: <200301242135.31937.timur.friedman@lip6.fr> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="------------Boundary-00=_FTK8U83HGMQP77OV27MC" Message-Id: <200301242156.03464.timur.friedman@lip6.fr> X-Scanned-By: osiris.lip6.fr Subject: [AVT] draft-ietf-avt-rtcp-report-extns-02.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --------------Boundary-00=_FTK8U83HGMQP77OV27MC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, Please find attached the latest version of the (new title) RTP Extended=20 Reports (RTP XR) draft, draft-ietf-avt-rtcp-report-extns-02.txt. This ha= s=20 just been submitted to internet-drafts@ietf.org. We have updated the draf= t=20 based upon comments from this list and from the chairs. We hope to advance to Final Call at the March IETF in San Francisco. You= r=20 comments are most welcome so that we may issue a final draft in good time= =2E Here are the changes since the previous version: * Changed title from RTCP Reporting Extensions to RTP Extended Reports (RTP XR). (Only very well known acronyms may appear in the title without expansion. RTP appears in the titles of several RFCs, RTCP in none to date.) * Reduced author list from seven authors to three editors. Created a Contributors section. Nick Duffield added as author. (No more than fi= ve names allowed on the front page authors list, mentioned by Colin.) * Added Magnus Westerlund, Dorgham Sisalem, and Adam Wolisz to the acknowledgments. * Separated normative from informative references. (Now recommended by the RFC Editor, mentioned by Colin.) * Renumbered the RTP packet type (PT) value for XR packets to 207. This would be the next available value should the RTCP feedback draft, which is in last call, become an RFC. Note that this would require changes to any other drafts based on the XR packet (RTCP Extensions for Single-Source Multicast is one). * Renumbered the block types from 1 to 7, replacing the legacy values. (Requested by Colin in the absence of a clear rationale for the legacy values.) * Rewrote the IANA Considerations section (as recommended by Colin). * Changed the required behavior for the receiver when it sees a non-zero value in a reserved field. Now the receiver must ignore the block or packet that contains this field. Previously the receiver was to ignore the field if they were unaware of any defined semantics for the field. (Allows for future definitions of these fields to call for different behavior on the part of receivers.) * All report blocks now have "Report Block" as part of their name. (This was inconsistent before.) * Some of the subsections of Section 4.7 have been combined. * Sections at the end of the document, such as the references and the copyright statement, have been reordered. References divided into Normative and Non-Normative References. * An appendix has been created for algorithms. The formatting for algorithms has been harmonized. * The discussion of per-sender and per-packet accounting for the Loss RLE Report Block (Section 4.1) has been updated, with an algorithm in the appendix. * Variable geometry removed from the Statistics Summary Report Block (Section 4.4). Now, if a statistic is not reported, the field is set to zero, but the field itself is not removed. This should considerably simplify parsing. * Clarified the wording specifying the length fields. (Thanks to Magnus Westerlund.) * Clarified how late packets are accounted as losses. (Thanks to Henning Schulzrinne and Magnus Westerlund.) * Made begin_seq and end_seq 16 bits in all cases. (Thanks to Magnus Westerlund.) * Clarified what to do if there are losses or duplicates when sending a Timestamp Report Block. (Thanks to Magnus Westerlund.) * Recommendations added to the Security Considerations section. * Gmin recommended value of 16 indicated for VoIP Metrics Report Block (Section 4.7) * RERL calculation corrected in Section 4.7. (Thanks to Magnus Westerlund.) * Burst metrics algorithm modified, and discussion updated. * Field renamed in the VoIP block: doubletalk now residual echo return lo= ss (RERL). Updated discussion of this field. * Fields reordered in VoIP block to better align on 16-bit boundaries. * Document indenting fixed to conform to that of the RTP spec. Regards, Timur Friedman --------------Boundary-00=_FTK8U83HGMQP77OV27MC Content-Type: text/plain; charset="iso-8859-1"; name="draft-ietf-avt-rtcp-report-extns-02.txt" Content-Disposition: attachment; filename="draft-ietf-avt-rtcp-report-extns-02.txt" Content-Transfer-Encoding: quoted-printable INTERNET-DRAFT 24 January 2003 Internet Engineering Task Force Expires: 24 July 2003 Audio/Video Transport Working Group Timur Friedman, Paris 6 Ramon Caceres, ShieldIP Alan Clark, Telchemy Editors RTP Extended Reports (RTP XR) draft-ietf-avt-rtcp-report-extns-02.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document defines the extended report (XR) packet type for the RTP control protocol (RTCP). XR packets are composed of report blocks, and seven block types are defined here. The purpose of the extended reporting format is to convey information that supplements the six statistics that are contained in the report blocks used by RTCP's sender report (SR) and receiver report (RR) packets. Some applications, such as multicast inference of network characteristics Friedman, Caceres, and Clark, eds. [Page 1] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 (MINC) or voice over IP (VoIP) monitoring, require other and more detailed statistics. In addition to the block types defined here, additional block types may be defined in the future by adhereing to the framework that this document provides. Table of Contents 1. Introduction .............................................. 2 1.1 Terminology ............................................... 3 2. XR Packet Format .......................................... 4 3. Extended Report Block Framework ........................... 5 4. Extended Report Blocks .................................... 6 4.1 Loss RLE Report Block ..................................... 6 4.1.1 Run Length Chunk .......................................... 12 4.1.2 Bit Vector Chunk .......................................... 12 4.1.3 Terminating Null Chunk .................................... 12 4.2 Duplicate RLE Report Block ................................ 13 4.3 Timestamp Report Block .................................... 13 4.4 Statistics Summary Report Block ........................... 16 4.5 Receiver Timestamp Report Block ........................... 19 4.6 DLRR Report Block ......................................... 20 4.7 VoIP Metrics Report Block ................................. 21 4.7.1 Packet Loss and Discard Metrics ........................... 23 4.7.2 Burst Metrics ............................................. 23 4.7.3 Delay Metrics ............................................. 26 4.7.4 Signal Related Metrics .................................... 26 4.7.5 Call Quality or Transmission Quality Metrics .............. 29 4.7.6 Configuration Parameters .................................. 30 4.7.7 Jitter Buffer Parameters .................................. 31 5. IANA Considerations ....................................... 32 5.1 XR Packet Type ............................................ 32 5.2 RTP XR Block Type Registry ................................ 32 6. Security Considerations ................................... 33 A. Algorithms ................................................ 34 A.1 Sequence Number Interpretation ............................ 34 A.2 Example Burst Packet Loss Calculation ..................... 35 Intellectual Property ..................................... 37 Full Copyright Statement .................................. 38 Acknowledegments .......................................... 38 Contributors .............................................. 39 Authors' Addresses ........................................ 39 References ................................................ 40 Normative References ...................................... 40 Non-Normative References .................................. 41 1. Introduction This document defines the extended report (XR) packet type for the Friedman, Caceres, and Clark, eds. [Page 2] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 RTP control protocol (RTCP) [7]. XR packets convey information beyond that already contained in the reception report blocks of RTCP's sender report (SR) or receiver report (RR) packets. The information is of use across RTP profiles, and so is not appropriately carried in SR or RR profile-specific extensions. Information used for network management falls into this category, for instance. The definition is broken out over the three following sections of this document, starting with a general framework and finishing with the specific information conveyed. The framework defined by Section 2 contains common header information followed by a series of components called report blocks. Section 3 defines the format common to such blocks. Section 4 defines seven block types. Seven report block formats are defined by this document: - Loss RLE Report Block (Section 4.1): Run length encoding of RTP packet loss reports. - Duplicate RLE Report Block (Section 4.2): Run length encoding of reports of RTP packet duplicates. - Timestamp Report Block (Section 4.3): A list of timestamps of received RTP packets. - Statistics Summary Report Block (Section 4.4): Statistics on RTP packet sequence numbers, losses, duplicates, jitter, and TTL values. - Receiver Timestamp Report Block (Section 4.5): Receiver-end timestamps that complement the sender-end timestamps already defined for RTCP. - DLRR Report Block (Section 4.6): The delay since the last Receiver Timestamp Report Block was received, allowing non-senders to calculate round-trip times. - VoIP Metrics Report Block (Section 4.7): Metrics for monitoring Voice over IP (VoIP) calls. These blocks are defined within a minimal framework: a type field and a length field are common to all XR blocks. The purpose is to maintain flexibility and to keep overhead low. 0ther block formats, beyond the seven defined here, may be defined within this framework as the need arises. 1.1 Terminology Friedman, Caceres, and Clark, eds. [Page 3] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 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 RFC 2119 [1] and indicate requirement levels for compliance with this specification. 2. XR Packet Format The XR packet consists of a header of two 32-bit words, followed by a number, possibly zero, of extended report blocks. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=3D2|P|reserved | PT=3DXP=3D207 | length = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC/CSRC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : report blocks : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ version (V): 2 bits Identifies the version of RTP. This specification applies to RTP version two. padding (P): 1 bit If the padding bit is set, this XR packet contains some additional padding octets at the end. The semantics of this field are identical to the semantics of the padding field in the the SR packet, as defined by the RTP specification. reserved: 5 bits This field is reserved for future definition. In the absence of such definition, the bits in this field MUST be set to zero and the receiver MUST ignore any XR packet with a non-zero value in this field. packet type (PT): 8 bits Contains the constant 207 to identify this as an RTCP XR packet. This value is registered with the Internet Assigned Numbers Authority (IANA), as described in Section 5.1. length: 16 bits As described for the RTP sender report (SR) packet (see Section 6.3.1 of the RTP specification [7]). Briefly, the length of this XR packet in 32-bit words minus one, including the header and any padding. Friedman, Caceres, and Clark, eds. [Page 4] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 SSRC: 32 bits The synchronization source identifier for the originator of this XR packet. report blocks: variable length. Zero or more extended report blocks. In keeping with the extended report block framework defined below, each block MUST consist of one or more 32-bit words. 3. Extended Report Block Framework Extended report blocks are stacked, one after the other, at the end of an XR packet. An individual block's length is a multiple of 4 octets. The XR header's length field describes the total length of the packet, including these extended report blocks. Each block has block type and length fields that facilitate parsing. A receiving application can demultiplex the blocks based upon their type, and can use the length information to locate each successive block, even in the presence of block types it does not recognize. An extended report block has the following format: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT | type-specific | block length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : type-specific data : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block type (BT): 8 bits Identifies the block format. Seven block types are defined in Section 4. Additional block types may be defined in future specifications. This field's name space is managed by the Internet Assigned Numbers Authority (IANA), as described in Section 5.2. type-specific: 8 bits The use of these bits is determined by the block type definition. block length: 16 bits The length of this report block including the header, in 32-bit words minus one. If the block type definition permits, zero is an acceptable value, signifying a block that consists of only Friedman, Caceres, and Clark, eds. [Page 5] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 the BT, type-specific, and block length fields, with a null type-specific data field. type-specific data: variable length The use of this field is defined by the particular block type, subject to the constraint that it MUST be a multiple of 32 bits long. If the block type definition permits, It MAY be zero bits long. 4. Extended Report Blocks This section defines seven extended report blocks: block types for losses, duplicates, packet reception timestamps, detailed reception statistics, receiver timestamps, receiver inter-report delays, and voice over IP (VoIP) metrics. An implementation MAY ignore incoming blocks with types either not relevant or unknown to it. Additional block types MUST be registered with the Internet Assigned Numbers Authority (IANA) [5], as described in Section 5.2. 4.1 Loss RLE Report Block This block type permits detailed reporting upon individual packet receipt and loss events. Such reports can be used, for example, for multicast inference of network characteristics (MINC) [8]. With MINC, one can discover the topology of the multicast tree used for distributing a source's RTP packets, and of the loss rates along links within that tree. Or they could be used to provide raw data to a network management application. Since a Boolean trace of lost and received RTP packets is potentially lengthy, this block type permits the trace to be compressed through run length encoding. To further reduce block size, loss event reports can be systematically dropped from the trace in a mechanism called thinning that is described below and that is studied in [9]. A participant that generates a Loss RLE Report Block should favor accuracy in reporting on observed events over interpretation of those events whenever possible. Interpretation should be left to those who observe the report blocks. Following this approach implies that accounting for Loss RLE Report Blocks will differ from the accounting for the generation of the SR and RR packets described in the RTP specification [7] in the following two areas: per-sender accounting and per-packet accounting. In its per-sender accounting, an RTP session participant SHOULD NOT make the receipt of a threshold minimum number of RTP packets a condition for reporting upon the sender of those packets. This accounting technique differs from the technique described in Section Friedman, Caceres, and Clark, eds. [Page 6] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 6.2.1 and Appendix A.1 of the RTP specification that allows a threshold to determine whether a sender is considered valid. In its per-packet accounting, an RTP session participant SHOULD treat all sequence numbers as valid. This accouting technique differs from the technique described in Appendix A.1 of the RTP specification that suggests ruling a sequence number valid or invalid on the basis of its contiguity with the sequence numbers of previously received packets. Sender validity and sequence number validity are interpretations of the raw data. Such interpretations are justified in the interest, for example, of excluding the stray old packet from an unrelated session from having an effect upon the calculation of the RTCP transmission interval. The presence of stray packets might, on the other hand, be of interest to a network monitoring application. One accounting interpretation that is still necessary is for a participant to decide whether the 16 bit sequence number has rolled over. Under ordinary circumstances this is not a difficult task. For example, if packet number 65,535 (the highest possible sequence number) is followed shortly by packet number 0, it is reasonable to assume that there has been a rollover. However it is possible that the packet is an earlier one (from 65,535 packets earlier). It is also possible that the sequence numbers have rolled over multiple times, either forward or backward. The interpretation becomes more difficult when there are large gaps between the sequence numbers, even accounting for rollover, and when there are long intervals between received packets. The per-packet accounting technique mandated here is for a participant to keep track of the sequence number of the packet most recently received from a sender. For the next packet that arrives from that sender, the sequence number MUST be judged to fall no more than 32,768 packets ahead or behind the most recent one, whichever choice places it closer. In the event that both choices are equally distant (only possible when the distance is 32,768), the choice MUST be the one that does not require a rollover. Appendix A.1 presents an algorithm that implements this technique. Each block reports on a single source, identified by its SSRC. The receiver that is supplying the report is identified in the header of the RTCP packet. Choice of beginning and ending RTP packet sequence numbers for the trace is left to the application. These values are reported in the block. The last sequence number in the trace MAY differ from the sequence number reported on in any accompanying SR or RR report. Friedman, Caceres, and Clark, eds. [Page 7] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 Note that because of sequence number wrap around the ending sequence number MAY be less than the beginning sequence number. A Loss RLE Report Block MUST NOT be used to report upon a range of 65,534 or greater in the sequence number space, as there is no means to identify multiple wrap arounds. The trace described by a Loss RLE report consists of a sequence of Boolean values, one for each sequence number of the trace. A value of one represents a packet receipt, meaning that one or more packets having that sequence number have been received since the most recent wrap around of sequence numbers (or since the beginning of the RTP session if no wrap around has been judged to have occurred). A value of zero represents a packet loss, meaning that there has been no packet receipt for that sequence number as of the time of the report. If a packet with a given sequence number is received after a report of a loss for that sequence number, a later Loss RLE report MAY report a packet receipt for that sequence number. The encoding itself consists of a series of 16 bit units called chunks that describe sequences of packet receipts or losses in the trace. Each chunk either specifies a run length or a bit vector, or is a null chunk. A run length describes between 1 and 16,383 events that are all the same (either all receipts or all losses). A bit vector describes 15 events that may be mixed receipts and losses. A null chunk describes no events, and is used to to round out the block to a 32 bit word boundary. The mapping from a sequence of lost and received packets into a sequence of chunks is not necessarily unique. For example, the following trace covers 45 packets, of which the 22nd and 24th have been lost and the others received: 1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1111 1 One way to encode this would be: bit vector 1111 1111 1111 111 bit vector 1111 1101 0111 111 bit vector 1111 1111 1111 111 null chunk Another way to encode this would be: Friedman, Caceres, and Clark, eds. [Page 8] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 run of 21 receipts bit vector 0101 1111 1111 111 run of 9 receipts null chunk The choice of encoding is left to the application. As part of this freedom of choice, applications MAY terminate a series of run length and bit vector chunks with a bit vector chunk that runs beyond the sequence number space described by the report block. For example, if the 44th packet in the same sequence were lost: 1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1110 1 This could be encoded as: run of 21 receipts bit vector 0101 1111 1111 111 bit vector 1111 1110 1000 000 null chunk In this example, the last five bits of the second bit vector describe a part of the sequence number space that extends beyond the last sequence number in the trace. These bits have been set to zero. All bits in a bit vector chunk that describe a part of the sequence number space that extends beyond the last sequence number in the trace MUST be set to zero, and MUST be ignored by the receiver. A null packet MUST appear at the end of a Loss RLE Report Block if the number of run length plus bit vector chunks is odd. The null chunk MUST NOT appear in any other context. Caution should be used in sending Loss RLE Report Blocks because, even with the compression provided by run length encoding, they can easily consume bandwidth out of proportion with normal RTCP packets. The block type includes a mechanism, called thinning, that allows an application to limit report sizes. A thinning value, T, selects a subset of packets within the sequence number space: those with sequence numbers that are multiples of 2^T. Packet reception and loss reports apply only to those packets. T can vary between 0 and 15. If T is zero then every packet in the sequence number space is reported upon. If T is fifteen then one in Friedman, Caceres, and Clark, eds. [Page 9] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 every 32,768 packets is reported upon. Suppose that the trace just described begins at sequence number 13,821. The last sequence number in the trace is 13,865. If the trace were to be thinned with a thinning value of T=3D2, then the following sequence numbers would be reported upon: 13,824, 13,828, 13,832, 13,836, 13,840, 13,844, 13,848, 13,852, 13,856, 13,860, 13,864. The thinned trace would be as follows: 1 1 1 1 1 0 1 1 1 1 0 This could be encoded as follows: bit vector 1111 1011 1100 000 null chunk The last four bits in the bit vector, representing sequence numbers 13,868, 13,872, 13,876, and 13,880, extend beyond the trace and are thus set to zero and are ignored by the receiver. With thinning, the loss of the 22nd packet goes unreported because its sequence number, 13,842, is not a multiple of four. Packet receipts for all sequence numbers that are not multiples of four also go unreported. However, in this example thinning has permitted the Loss RLE Report Block to be shortened by one 32 bit word. Choice of the thinning value is left to the application. The Loss RLE Report Block has the following format: Friedman, Caceres, and Clark, eds. [Page 10] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=3D1 | rsvd. | T | block length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | begin_seq | end_seq | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | chunk 1 | chunk 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | chunk n-1 | chunk n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block type (BT): 8 bits A Loss RLE Report Block is identified by the constant 1. rsvd.: 4 bits This field is reserved for future definition. In the absence of such definition, the bits in this field MUST be set to zero and the receiver MUST ignore any Loss RLE Report Block with a non- zero value in this field. thinning (T): 4 bits The amount of thinning performed on the sequence number space. Only those packets with sequence numbers 0 mod 2^T are reported on by this block. A value of 0 indicates that there is no thinning, and all packets are reported on. The maximum thinning is one packet in every 32,768 (amounting to two packets within each 16-bit sequence space). block length: 16 bits Defined in Section 3. begin_seq: 16 bits The first sequence number that this block reports on. end_seq: 16 bits The last sequence number that this block reports on plus one. chunk i: 16 bits There are three chunk types: run length, bit vector, and terminating null, defined in the following sections. If the chunk is all zeroes then it is a terminating null chunk. Otherwise, the leftmost bit of the chunk determines its type: 0 Friedman, Caceres, and Clark, eds. [Page 11] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 for run length and 1 for bit vector. 4.1.1 Run Length Chunk 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C|R| run length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ chunk type (C): 1 bit A zero identifies this as a run length chunk. run type (R): 1 bit Zero indicates a run of 0s. One indicates a run of 1s. run length: 14 bits A value between 1 and 16,383. The value MUST not be zero for a run length chunk (zeroes in both the run type and run length fields would make the chunk a terminating null chunk). Run lengths of 15 or less MAY be described with a run length chunk despite the fact that they could also be described as part of a bit vector chunk. 4.1.2 Bit Vector Chunk 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C| bit vector | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ chunk type (C): 1 bit A one identifies this as a bit vector chunk. bit vector: 15 bits The vector is read from left to right, in order of increasing sequence number (with the appropriate allowance for wrap around). 4.1.3 Terminating Null Chunk This chunk is all zeroes. Friedman, Caceres, and Clark, eds. [Page 12] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.2 Duplicate RLE Report Block This block type permits per-sequence-number reports on duplicates in a source's RTP packet stream. Such information can be used for network diagnosis, and provide an alternative to packet losses as a basis for multicast tree topology inference. The Duplicate RLE Report Block format is identical to the Loss RLE Report Block format. Only the interpretation is different, in that the information concerns packet duplicates rather than packet losses. The trace to be encoded in this case also consists of zeros and ones, but a zero here indicates the presence of duplicate packets for a given sequence number, whereas a one indicates that no duplicates were received. The existence of a duplicate for a given sequence number is determined over the entire reporting period. For example, if packet number 12,593 arrives, followed by other packets with other sequence numbers, the arrival later in the reporting period of another packet numbered 12,593 counts as a duplicate for that sequence number. The duplicate does not need to follow immediately upon the first packet of that number. Care must be taken that a report does not cover a range of 65,534 or greater in the sequence number space. No distinction is made between the existance of a single duplicate packet and multiple duplicate packets for a given sequence number. Note also that since there is no duplicate for a lost packet, a loss is encoded as a one in a Duplicate RLE Report Block. The Duplicate RLE Report Block has the following format: Friedman, Caceres, and Clark, eds. [Page 13] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=3D2 | rsvd. | T | block length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | begin_seq | end_seq | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | chunk 1 | chunk 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | chunk n-1 | chunk n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block type (BT): 8 bits A Duplicate RLE Report Block is identified by the constant 2. rsvd.: 4 bits This field is reserved for future definition. In the absence of such definition, the bits in this field MUST be set to zero and the receiver MUST ignore any Duplicate RLE Report Block with a non-zero value in this field. thinning (T): 4 bits As defined in Section 4.1. block length: 16 bits Defined in Section 3. begin_seq: 16 bits As defined in Section 4.1. end_seq: 16 bits As defined in Section 4.1. chunk i: 16 bits As defined in Section 4.1. 4.3 Timestamp Report Block This block type permits per-sequence-number reports on packet receipt timestamps for a given source's RTP packet stream. Such information can be used for MINC inference of the topology of the multicast tree used to distribute the source's RTP packets, and of the delays along the links within that tree. It can also be used to measure partial Friedman, Caceres, and Clark, eds. [Page 14] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 path characteristics and to model distributions for packet jitter. At least one packet MUST have been received for each sequence number reported upon in this block. If this block type is used to report timestamps for a series of sequence numbers that includes lost packets, several blocks are required. If duplicate packets have been received for a given sequence number, and those packets differ in their receiver timestamps, any timestamp other than the earliest MUST NOT be reported. This is to ensure consistency among reports. Timestamps consume more bits than loss or duplicate information, and do not lend themselves to run length encoding. The use of thinning is encouraged to limit the size of Timestamp Report Blocks. The Timestamp Report Block has the following format: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=3D3 | rsvd. | T | block length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | begin_seq | end_seq | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP timestamp 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP timestamp 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP timestamp n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block type (BT): 8 bits A Timestamp Report Block is identified by the constant 3. rsvd.: 4 bits This field is reserved for future definition. In the absence of such definition, the bits in this field MUST be set to zero and the receiver MUST ignore any Timestamp Report Block with a non- zero value in this field. thinning (T): 4 bits As defined in Section 4.1. Friedman, Caceres, and Clark, eds. [Page 15] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 block length: 16 bits Defined in Section 3. begin_seq: 16 bits As defined in Section 4.1. end_seq: 16 bits As defined in Section 4.1. RTP timestamp i: 32 bits The timestamp reflects the packet arrival time at the receiver. It is preferable for the timestamp to be established at the link layer interface, or in any case as close as possible to the wire arrival time. Units and format are the same as for the timestamp in RTP data packets. As opposed to RTP data packet timestamps, in which nominal values may be used instead of system clock values in order to convey information useful for periodic playout, the receiver timestamps should reflect the actual time as closely as possible. The initial value of the timestamp is random, and subsequent timestamps are offset from this value. 4.4 Statistics Summary Report Block This block reports statistics beyond the information carried in the standard RTCP packet format, but not as fine grained as that carried in the report blocks previously described. Information is recorded about lost packets, duplicate packets, jitter measurements, and TTL values (TTL values being taken from the TTL field of IPv4 packets, if the data packets are carried over IPv4). Such information can be useful for network management. The report block contents are dependent upon a bit vector carried in the first part of the header. Not all parameters need to be reported in each block. Flags indicate which are and which are not reported. The fields corresponding to unreported parameters MUST be set to zero. The receiver MUST ignore any Statistics Summary Report Block with a non-zero value in any field flagged as unreported. The Statistics Summary Report Block has the following format: Friedman, Caceres, and Clark, eds. [Page 16] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=3D4 |L|D|J|T|resvd. | block length =3D 9 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | begin_seq | end_seq | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | lost_packets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | dup_packets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | min_jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | max_jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | avg_jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | dev_jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | min_ttl | max_ttl | avg_ttl | dev_ttl | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block type (BT): 8 bits A Statistics Summary Report Block is identified by the constant 4. loss report flag (L): 1 bit Bit set to 1 if the lost_packets field contains a report, 0 otherwise. duplicate report flag (D): 1 bit Bit set to 1 if the dup_packets field contains a report, 0 otherwise. jitter flag (J): 1 bit Bit set to 1 if the min_jitter, max_jitter, avg_jitter, and dev_jitter fields all contain reports, 0 if none of them do. TTL flag (T): 1 bit Bit set to 1 if the min_ttl, max_ttl, avg_ttl, and dev_ttl fields all contain reports, 0 if none of them do. resvd.: 4 bits This field is reserved for future definition. In the absence of such definition, all bits in this field MUST be set to zero, and Friedman, Caceres, and Clark, eds. [Page 17] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 the receiver MUST ignore any Statistics Summary Report Block with a non-zero value in this field. block length: 16 bits The constant 9, in accordance with the definition of this field in Section 3. begin_seq: 16 bits As defined in Section 4.1. end_seq: 16 bits As defined in Section 4.1. lost_packets: 32 bits Number of lost packets in the above sequence number interval. dup_packets: 32 bits Number of duplicate packets in the above sequence number interval. min_jitter: 32 bits The minimum relative transit time between two packets in the above sequence number interval. All jitter values are measured as the difference between a packet's RTP timestamp and the reporter's clock at the time of arrival, measured in the same units. max_jitter: 32 bits The maximum relative transit time between two packets in the above sequence number interval. avg_jitter: 32 bits The average relative transit time between each two packet series in the above sequence number interval. dev_jitter: 32 bits The standard deviation of the relative transit time between each two packet series in the above sequence number interval. min_ttl: 8 bits The minimum TTL value of data packets in sequence number range. max_ttl: 8 bits The maximum TTL value of data packets in sequence number range. avg_ttl: 8 bits The average TTL value of data packets in sequence number range. Friedman, Caceres, and Clark, eds. [Page 18] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 dev_ttl: 8 bits The standard deviation of TTL values of data packets in sequence number range. 4.5 Receiver Timestamp Report Block This block extends RTCP's timestamp reporting so that non-senders may also send timestamps. It recapitulates the NTP timestamp fields from the RTCP Sender Report [7, Sec. 6.3.1]. A non-sender may estimate its RTT to other participants, as proposed in [11], by sending this report block and receiving DLRR Report Blocks (see next section) in reply. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=3D5 | reserved | block length =3D 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NTP timestamp, most significant word | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NTP timestamp, least significant word | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block type (BT): 8 bits A Receiver Timestamp Report Block is identified by the constant 5. reserved: 8 bits This field is reserved for future definition. In the absence of such definition, the bits in this field MUST be set to zero and the receiver MUST ignore any Receiver Timestamp Report Block with a non-zero value in this field. block length: 16 bits The constant 2, in accordance with the definition of this field in Section 3. NTP timestamp: 64 bits Indicates the wallclock time when this block was sent so that it may be used in combination with timestamps returned in DLRR Report Blocks (see next section) from other receivers to measure round-trip propagation to those receivers. Receivers should expect that the measurement accuracy of the timestamp may be limited to far less than the resolution of the NTP timestamp. The measurement uncertainty of the timestamp is not indicated as it may not be known. A report block sender that can keep track Friedman, Caceres, and Clark, eds. [Page 19] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 of elapsed time but has no notion of wallclock time may use the elapsed time since joining the session instead. This is assumed to be less than 68 years, so the high bit will be zero. It is permissible to use the sampling clock to estimate elapsed wallclock time. A report sender that has no notion of wallclock or elapsed time may set the NTP timestamp to zero. 4.6 DLRR Report Block This block extends RTCP's delay since last sender report (DLSR) mechanism [7, Sec. 6.3.1] so that non-senders may also calculate round trip times, as proposed in [11]. It is termed DLRR for delay since last receiver report, and may be sent in response to a Receiver Timestamp Report Block (see previous section) from a receiver to allow that receiver to calculate its round trip time to the respondant. The report consists of one or more 3 word sub-blocks: one sub-block per receiver report. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=3D6 | reserved | block length | +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D= +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ | SSRC_1 (SSRC of first receiver) | sub- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ bloc= k | last RR (LRR) | 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | delay since last RR (DLRR) | +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D= +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ | SSRC_2 (SSRC of second receiver) | sub- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ bloc= k : ... : 2 +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D= +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ block type (BT): 8 bits A DLRR Report Block is identified by the constant 6. reserved: 8 bits This field is reserved for future definition. In the absence of such definition, all bits in this field MUST be set to zero, the receiver MUST ignore any DLRR Report Block with a non-zero value in this field. block length: 16 bits Defined in Section 3. Friedman, Caceres, and Clark, eds. [Page 20] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 last RR timestamp (LRR): 32 bits The middle 32 bits out of 64 in the NTP timestamp (as explained in the previous section) received as part of a Receiver Timestamp Report Block from participant SSRC_n. If no such block has been received, the field is set to zero. delay since last RR (DLRR): 32 bits The delay, expressed in units of 1/65536 seconds, between receiving the last Receiver Timestamp Report Block from participant SSRC_n and sending this DLRR Report Block. If no Receiver Timestamp Report Block has been received yet from SSRC_n, the DLRR field is set to zero (or the DLRR is omitted entirely). Let SSRC_r denote the receiver issuing this DLRR Report Block. Participant SSRC_n can compute the round-trip propagation delay to SSRC_r by recording the time A when this Receiver Timestamp Report Block is received. It calculates the total round-trip time A-LSR using the last SR timestamp (LSR) field, and then subtracting this field to leave the round-trip propagation delay as A-LSR-DLSR. This is illustrated in [7, Fig. 2]. 4.7 VoIP Metrics Report Block The VoIP Metrics Report Block provides metrics for monitoring voice over IP (VoIP) calls. These metrics include packet loss and discard metrics, delay metrics, analog metrics, and voice quality metrics. The block reports separately on packets lost on the IP channel, and those that have been received but then discarded by the receiving jitter buffer. It also reports on the combined effect of losses and discards, as both have equal effect on call quality. In order to properly assess the quality of a Voice over IP call it is desirable to consider the degree of burstiness of packet loss [10]. Following a Gilbert-Elliott model [2], a period of time, bounded by lost and/or discarded packets, with a high rate of losses and/or discards is a "burst," and a period of time between two bursts is a "gap." Bursts correspond to periods of time during which the packet loss rate is high enough to produce noticeable degradation in audio quality. Gaps correspond to periods of time during which only isolated lost packets may occur, and in general these can be masked by packet loss concealment. Delay reports include the transit delay between RTCP end points and the VoIP end system processing delays, both of which contribute to the user perceived delay. Additional metrics include signal, echo, noise, and distortion levels. Call quality metrics include R factors (as described by the E Model defined in [2]) and mean opinion scores (MOS scores). An implementation that sends these blocks SHOULD send at least one Friedman, Caceres, and Clark, eds. [Page 21] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 every ten seconds for the duration of the call, SHOULD send one whenever a CODEC type change or other significant change occurs, SHOULD send one when significant call quality degradation is detected and SHOULD send one upon call termination. Implementations MUST provide values for all the fields defined here. For certain metrics, if the value is undefined or unknown, then the specified default or unknown field value MUST be provided. The block is encoded as seven 32-bit words: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=3D7 | reserved | block length =3D 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | loss rate | discard rate | burst density | gap density | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | burst duration | gap duration | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | round trip delay | end system delay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | signal power | RERL | noise level | Gmin | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | R factor | ext. R factor | MOS-LQ | MOS-CQ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RX config | JB nominal | JB maximum | JB abs max | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block type (BT): 8 bits A VoIP Metrics Report Block is identified by the constant 7. reserved: 8 bits This field is reserved for future definition. In the absence of such definition, all bits in this field MUST be set to zero and the receiver MUST ignore any VoIP Metrics Report Block with a non-zero value in this field. block length: 16 bits The constant 6, in accordance with the definition of this field in Section 3. The remaining fields are described in the following six sections: Packet Loss and Discard Metrics, Delay Metrics, Signal Related Metrics, Call Quality or Transmission Quality Metrics, Configuration Metrics, and Jitter Buffer Parameters. Friedman, Caceres, and Clark, eds. [Page 22] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 4.7.1 Packet Loss and Discard Metrics It is very useful to distinguish between packets lost by the network and those discarded due to jitter. Both have equal effect on the quality of the voice stream however having separate counts helps identify the source of quality degradation. These fields MUST be populated. loss rate: 8 bits The fraction of RTP data packets from the source lost since the beginning of reception, expressed as a fixed point number with the binary point at the left edge of the field. This value is calculated by dividing the total number of packets lost (after the effects of applying any error protection such as FEC) by the total number of packets expected, multiplying the result of the division by 256, limiting the maximum value to 255 (to avoid overflow), and taking the integer part. The numbers of duplicated packets and discarded packets do not enter into this calculation. Since receivers cannot be required to maintain unlimited buffers, a receiver MAY categorize late-arriving packets as lost. The degree of lateness that triggers a loss SHOULD be significantly greater than that which triggers a discard. discard rate: 8 bits The fraction of RTP data packets from the source that have been discarded since the beginning of reception, due to late or early arrival, under-run or overflow at the receiving jitter buffer. This value is expressed as a fixed point number with the binary point at the left edge of the field. It is calculated by dividing the total number of packets discarded (excluding duplicate packet discards) by the total number of packets expected, multiplying the result of the division by 256, limiting the maximum value to 255 (to avoid overflow), and taking the integer part. 4.7.2 Burst Metrics A burst, informally, is a period of high packet losses and/or discards. Formally, a burst is defined as a longest sequence of packets bounded by lost or discarded packets with the constraint that within a burst any sequence of successive packets that were received, and not discarded due to delay variation, is of length less than a value Gmin. A gap, informally, is a period of low packet losses and/or discards. Formally, a gap is defined as any of the following: (a) the period from the start of an RTP session to the receipt time of the last Friedman, Caceres, and Clark, eds. [Page 23] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 received packet before the first burst, (b) the period from the end of the last burst to either the time of the report or the end of the RTP session, whichever comes first, or (c) the period of time between two bursts. For the purpose of determining if a lost or discarded packet near the start or end of an RTP session is within a gap or a burst it is assumed that the RTP session is preceded and followed by at least Gmin received packets, and that the time of the report is followed by at least Gmin received packets. A gap has the property that any lost or discarded packets within the gap must be preceded and followed by at least Gmin packets that were received and not discarded. This gives a maximum loss/discard density within a gap of: 1 / (Gmin + 1). A Gmin value of 16 is RECOMMENDED as it results in gap characteristics that correspond to good quality (i.e. low packet loss rate, a minimum distance of 16 received packets between lost packets) and hence differentiates nicely between good and poor quality periods. For example, a 1 denotes a received, 0 a lost, and X a discarded packet in the following pattern covering 64 packets: 11110111111111111111111X111X1011110111111111111111111X111111111 |---------gap----------|--burst---|------------gap------------| The burst consists of the twelve packets indicated above, starting at a discarded packet and ending at a lost packet. The first gap starts at the beginning of the session and the second gap ends at the time of the report. If the packet spacing is 10 ms and the Gmin value is the recommended value of 16, the burst duration is 120 ms, the burst density 0.33, the gap duration 230 ms + 290 ms =3D 520 ms, and the gap density 0.04. This would result in reported values as follows (see field descriptions for semantics and details on how these are calculated): loss density 12, which corresponds to 5% discard density 12, which corresponds to 5% burst density 84, which corresponds to 33% gap density 10, which corresponds to 4% burst duration 120, value in milliseconds gap duration 520, value in milliseconds Friedman, Caceres, and Clark, eds. [Page 24] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 burst density: 8 bits The fraction of RTP data packets within burst periods since the beginning of reception that were either lost or discarded. This value is expressed as a fixed point number with the binary point at the left edge of the field. It is calculated by dividing the total number of packets lost or discarded (excluding duplicate packet discards) within burst periods by the total number of packets expected within the burst periods, multiplying the result of the division by 256, limiting the maximum value to 255 (to avoid overflow), and taking the integer part. gap density: 8 bits The fraction of RTP data packets within inter-burst gaps since the beginning of reception that were either lost or discarded. The value is expressed as a fixed point number with the binary point at the left edge of the field. It is calculated by dividing the total number of packets lost or discarded (excluding duplicate packet discards) within gap periods by the total number of packets expected within the gap periods, multiplying the result of the division by 256, limiting the maximum value to 255 (to avoid overflow), and taking the integer part. burst duration: 16 bits The mean duration, expressed in milliseconds, of the burst periods that have occurred since the beginning of reception. The duration of each period is calculated based upon the packets that mark the beginning and end of that period. It is equal to the timestamp of the end packet, plus the duration of the end packet, minus the timestamp of the beginning packet. If the actual values are not available, estimated values MUST be used. If there have been no burst periods, the burst duration value MUST be zero. gap duration: 16 bits The mean duration, expressed in milliseconds, of the gap periods that have occurred since the beginning of reception. The duration of each period is calculated based upon the packet that marks the end of the prior burst and the packet that marks the beginning of the subsequent burst. It is equal to the timestamp of the subsequent burst packet, minus the timestamp of the prior burst packet, plus the duration of the prior burst packet. If the actual values are not available, estimated values MUST be used. In the case of a gap that occurs at the beginning of reception, the sum of the timestamp of the prior burst packet and the duration of the prior burst packet are replaced by the reception start time. In the case of a gap that occurs at the end of reception, the timestamp of the subsequent burst packet Friedman, Caceres, and Clark, eds. [Page 25] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 is replaced by the reception end time. If there have been no gap periods, the gap duration value MUST be zero. 4.7.3 Delay Metrics For the purpose of the following definitions, the RTP interface is the interface between the RTP instance and the voice application (i.e. FEC, de-interleaving, de-multiplexing, jitter buffer). For example, the time delay due to RTP payload multiplexing would be considered to be part of the voice application or end-system delay whereas delay due to multiplexing RTP frames within a UDP frame would be considered part of the RTP reported delay. This distinction is consistent with the use of RTCP for delay measurements. round trip delay: 16 bits The most recently calculated round trip time between RTP interfaces, expressed in milliseconds. This value is the time of receipt of the most recent RTCP packet from source SSRC, minus the LSR (last SR) time reported in its SR (sender report), minus the DLSR (delay since last SR) reported in its SR. A non-zero LSR value is REQUIRED in order to calculate round trip delay. A value of 0 is permissible during the first two or three RTCP exchanges as insufficient data may be available to determine delay however MUST be populated as soon as a delay estimate is available. end system delay: 16 bits The most recently estimated end system delay, expressed in milliseconds. End system delay is defined as the total encoding, decoding and jitter buffer delay determined at the reporting endpoint. This is the time required for an RTP frame to be buffered, decoded, converted to analog form, looped back at the local analog interface, encoded, and made available for transmission as an RTP frame. The manner in which this value is estimated is implementation dependent. This parameter MUST be provided in all VoIP metrics reports. Note that the one way symmetric VoIP segment delay may be calculated from the round trip and end system delays as follows. If the round trip delay is denoted RTD and the end system delays associated with the two endpoints are ESD(A) and ESD(B) then: one way symmetric voice path delay =3D ( RTD + ESD(A) + ESD(B) ) / 2 4.7.4 Signal Related Metrics Friedman, Caceres, and Clark, eds. [Page 26] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 The following metrics are intended to provide real time information related to the non-packet elements of the voice over IP system to assist with the identification of problems affecting call quality. The values identified below must be determined for the received audio signal. The information required to populate these fields may not be available in all systems, although it is strongly recommended that this data SHOULD be provided to support problem diagnosis. signal power: 8 bits The voice signal relative level is defined as the ratio of the signal level to overflow signal level, expressed in decibels as a signed integer in two's complement form. This is measured only for packets containing speech energy. The intent of this metric is not to provide a precise measurement of the signal level but to provide a real time indication that the signal level may be excessively high or low. If the full range (overflow level) of the Vocoder's digital to analog conversion function is +/- L and the value of a decoded sample during a talkspurt is V then the signal level is given by: signal level =3D 10 log10 ( mean( abs(V) / L ) ) A value of 127 indicates that this parameter is unavailable. residual echo return loss (RERL): 8 bits The residual echo return loss is defined as the sum of the measured echo return loss (ERL) and the echo return loss enhancement (ERLE) expressed in dB as a signed integer in two's complement form. It defines the ratio of a transmitted voice signal that is reflected back to the talker. A low level of echo return loss (say less than 20 dB) in conjunction with some delay can lead to hollowness or audible echo. A high level of echo return loss (say over 40 dB) is preferable. The ERL and ERLE parameters are often available directly from the echo cancellor contained within the VoIP end system. They relate to the echo on the external network attached to the end point. In the case of a VoIP gateway this would be line echo that typically occurs at 2-4 wire conversion points in the network. Echo return loss from typical 2-4 wire conversions can be in the 8-12 dB range. A line echo cancellor can provide an ERLE of 30 dB or more and hence reduce this to 40-50 dB. In the case of an IP phone this could be residual acoustic echo from speakerphone operation, and may more correctly be termed terminal coupling loss (TCL). A typical handset would result in 40-50 dB of echo due to acoustic feedback. Typical values for RERL are as follows: Friedman, Caceres, and Clark, eds. [Page 27] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 (i) IP gateway connected to circuit switched network with 2 wire loop Without echo cancellation, typical 2-4 wire convertor ERL of 12 dB RERL =3D ERL + ERLE =3D 12 + 0 =3D 12 dB (ii) IP gateway connected to circuit switched network with 2 wire loop With echo cancellor that improves echo by 30 dB RERL =3D ERL + ERLE =3D 12 + 30 =3D 42 dB (iii) IP phone with conventional handset Acoustic coupling from handset speaker to microphone 40 dB Residual echo return loss =3D TCL =3D 40 dB If we denote the "local" end of the VoIP path as A and the remote end as B and if the sender loudness rating (SLR) and receiver loudness rating (RLR) are known for A (default values 8 dB and 2 dB respectively), then the echo loudness level at end A (talker echo loudness rating or TELR) is given by: TELR(A) =3D SRL(A) + ERL(B) + ERLE(B) + RLR(A) TELR(B) =3D SRL(B) + ERL(A) + ERLE(A) + RLR(B) Hence in order to incorporate echo into a voice quality estimate at the A end of a VoIP connection it is desirable to send the ERL + ERLE value from B to A. For an IP phone with handset this metric MUST be set to the designed or measured terminal coupling loss, which would typically be 40-50 dB. For a PC softphone or speakerphone this metric MUST be set to either the value reported by the acoustic echo cancellor or to 127 to indicate an undefined value. For an IP gateway with ERL and ERLE measurements this metric MUST be reported as ERL + ERLE. For an IP gateway without ERL and ERLE measurement capability then this metric MUST be reported as 12 dB if line echo cancellation is disabled and 40 dB if line echo cancellation is enabled. noise level: 8 bits The noise level is defined as the ratio of the silent period back ground noise level to overflow signal power, expressed in decibels as a signed integer in two's complement form. If the full range (overflow level) of the Vocoder's digital to analog conversion function is +/- L and the value of a decoded sample during a silence period is V then the noise level is given by Friedman, Caceres, and Clark, eds. [Page 28] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 noise level =3D 10 log10 ( mean( abs(V) / L ) ) A value of 127 indicates that this parameter is unavailable. Gmin See Configuration Parameters (Section 4.7.6, below). 4.7.5 Call Quality or Transmission Quality Metrics The following metrics are direct measures of the call quality or transmission quality, and incorporate the effects of CODEC type, packet loss, discard, burstiness, delay etc. These metrics may not be available in all systems however SHOULD be provided in order to support problem diagnosis. R factor: 8 bits The R factor is a voice quality metric describing the segment of the call that is carried over this RTP session. It is expressed as an integer in the range 0 to 100, with a value of 94 corresponding to "toll quality" and values of 50 or less regarded as unusable. This metric is defined as including the effects of delay, consistent with ITU-T G.107 [4] and ETSI TS 101 329-5 [2]. A value of 127 indicates that this parameter is unavailable. ext. R factor: 8 bits The external R factor is a voice quality metric describing the seg ment of the call that is carried over a network segment external to the RTP segment, for example a cellular network. Its values are interpreted in the same manner as for the RTP R factor. This metric is defined as including the effects of delay, consistent with ITU-T G.107 [4] and ETSI TS 101 329-5 [2], and relates to the outward voice path from the Voice over IP termination for which this metrics block applies. A value of 127 indicates that this parameter is unavailable. Note that an overall R factor may be estimated from the RTP segment R factor and the external R factor, as follows: R total =3D RTP R factor + ext. R factor - 94 MOS-LQ: 8 bits The estimated mean opinion score for listening quality (MOS-LQ) is a voice quality metric on a scale from 1 to 5, in which 5 represents excellent and 1 represents unacceptable. This metric is defined as not including the effects of delay and can be Friedman, Caceres, and Clark, eds. [Page 29] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 compared to MOS scores obtained from listening quality (ACR) tests. It is expressed as an integer in the range 10 to 50, corresponding to MOS x 10. For example, a value of 35 would correspond to an estimated MOS score of 3.5. A value of 127 indicates that this parameter is unavailable. MOS-CQ: 8 bits The estimated mean opinion score for conversational quality (MOS-CQ) is defined as including the effects of delay and other effects that would affect conversational quality. The metric may be calculated by converting an R factor determined according to ITU-T G.107 [4] or ETSI TS 101 329-5 [2] into an estimated MOS using the equation specified in G.107. It is expressed as an integer in the range 10 to 50, corresponding to MOS x 10, as for MOS-LQ. A value of 127 indicates that this parameter is unavailable. 4.7.6 Configuration Parameters Gmin: 8 bits The gap threshold. This field contains the value used for this report block to determine if a gap exists. The recommended value of 16 corresponds to a burst period having a minimum density of 6.25% of lost or discarded packets, which may cause noticeable degradation in call quality; during gap periods, if packet loss or dis card occurs, each lost or discarded packet would be preceded by and followed by a sequence of at least 16 received non-discarded packets. Note that lost or discarded packets that occur within Gmin packets of a report being generated may be reclassified as being part of a burst or gap in later reports. ETSI TS 101 329-5 [2] defines a computationally efficient algorithm for measuring burst and gap density using a packet loss/discard event driven approach. This algorithm is reproduced in Appendix A.2 of the present document. Gmin MUST not be zero and MUST be provided. receiver configuration byte (RX config): 8 bits This byte consists of the following fields: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |PLC|JBA|JB rate| +-+-+-+-+-+-+-+-+ Friedman, Caceres, and Clark, eds. [Page 30] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 packet loss concealment (PLC): 2 bits Standard (11) / enhanced (10) / disabled (01) / unspecified (00). When PLC =3D 11 then a simple replay or interpolation algorithm is being used to fill-in the missing packet. This is typically able to conceal isolated lost packets with loss rates under 3%. When PLC =3D 10 then an enhanced interpolation algorithm is being used. This would typically be able to conceal lost packets for loss rates of 10% or more. When PLC =3D 01 then silence is inserted in place of lost packets. When PLC =3D 00 then no information is available concerning the use of PLC however for some CODECs this may be inferred. jitter buffer adaptive (JBA): 2 bits Adaptive (11) / non-adaptive (10) / reserved (01)/ unknown (00). When the jitter buffer is adaptive then its size is being dynamically adjusted to deal with varying levels of jitter. When non-adaptive, the jitter buffer size is maintained at a fixed level. When either adaptive or non- adaptive modes are specified then the jitter buffer size parameters below MUST be specified. jitter buffer rate (JB rate): 4 bits J =3D adjustment rate (0-15). This represents the implementation specific adjustment rate of a jitter buffer in adaptive mode. This parameter is defined in terms of the approximate time taken to fully adjust to a step change in peak to peak jitter from 30 ms to 100 ms such that: adjustment time =3D 2 * J * frame size (ms) This parameter is intended only to provide a guide to the degree of "aggressiveness" of a an adaptive jitter buffer and may be estimated. A value of 0 indicates that the adjustment time is unknown for this implementation. 4.7.7 Jitter Buffer Parameters jitter buffer nominal size in frames (JB nominal): 8 bits This is the current nominal fill point within the jitter buffer, which corresponds to the nominal jitter buffer delay for packets that arrive exactly on time. This parameter MUST be provided for both fixed and adaptive jitter buffer implementations. jitter buffer maximum size in frames (JB maximum): 8 bits This is the current maximum jitter buffer level corresponding to the earliest arriving packet that would not be discarded. In simple queue implementations this may correspond to the nominal Friedman, Caceres, and Clark, eds. [Page 31] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 size. In adaptive jitter buffer implementations this value may dynamically vary up to JB abs max (see below). This parameter MUST be provided for both fixed and adaptive jitter buffer implementations. jitter buffer absolute maximum size in frames (JB abs max): 8 bits This is the absolute maximum size that the adaptive jitter buffer can reach under worst case jitter conditions. This parameter MUST be provided for adaptive jitter buffer implementations and its value MUST be set to JB maximum for fixed jitter buffer implementations. 5. IANA Considerations This document defines a new RTP packet type, the extended report (XR) type, within the existing Internet Assigned Numbers Authority (IANA) registry of RTP RTCP Control Packet Types. This document also defines a new IANA registry: the registry of RTP XR Block Types. Within this new registry, this document defines an initial set of seven block types and describes how the remaining types are to be allocated. 5.1 XR Packet Type The IANA SHALL register the RTP extended report (XR) packet defined by this document as packet type 207 in the registry of RTP RTCP Control Packet types (PT). 5.2 RTP XR Block Type Registry The IANA SHALL create the RTP XR Block Type Registry to cover the name space of the extended report block type (BT) field specified in Section 3 of this document. The BT field contains eight bits, allowing 256 values. The IANA SHALL manage the RTP XR Block Type Registry according to the Specification Required policy of RFC 2434 [6]. Future specifications SHOULD attribute block type values in strict numeric order following the values attributed in this document: Friedman, Caceres, and Clark, eds. [Page 32] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 BT name -- ---- 1 Loss RLE Report Block 2 Duplicate RLE Report Block 3 Timestamp Report Block 4 Statistics Summary Report Block 5 Receiver Timestamp Report Block 6 DLRR Report Block 7 VoIP Metrics Report Block Furthermore, future specifications SHOULD avoid the values 0 and 255. Doing so facilitates packet validity checking, since all-zeros and all-ones are values that might commonly be found in ill-formed packets. 6. Security Considerations This document extends the RTCP reporting mechanism. The security considerations that apply to RTCP reports also apply to XR reports. This section details the additional security considerations that apply to the extensions. The extensions introduce heightened confidentiality concerns. Standard RTCP reports contain a limited number of summary statistics. The information contained in XR reports is both more detailed and more extensive (covering a larger number of parameters). The per- packet information contained in Loss RLE, Duplicate RLE, and Timestamp Report Blocks facilitates MINC inference of multicast distribution trees for RTP data packets, and inference of link characteristics such as loss and delay. This inference reveals information that might otherwise be considered confidential to autonomous system administrators. The VoIP Metrics Report Block provides information on the quality of ongoing voice calls. Though such information might be carried in application specific format in standard RTP sessions, making it available in a standard format here makes it more available to potential eavesdroppers. No new mechanisms are introduced in this document to ensure confidentiality. Standard encryption procedures can be used when confidentiality is a concern to end hosts. Autonomous system administrators concerned about the loss of confidentiality regarding their networks can encrypt traffic, or filter it to exclude RTCP packets containing the XR report blocks concerned. Any encryption or filtering of XR report blocks entails a loss of monitoring information to third parties. For example, a network that establishes a tunnel to encrypt VoIP Report Blocks denies that Friedman, Caceres, and Clark, eds. [Page 33] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 information to the service providers traversed by the tunnel. The service providers cannot then monitor or respond to the quality of the VoIP calls that they carry, potentially creating problems for the network's users. As a default, XR packets SHOULD NOT be encrypted or filtered. The extensions also make certain denial of service attacks easier. This is because of the potential to create RTCP packets much larger than average with the per packet reporting capabilities of the Loss RLE, Duplicate RLE, and Timestamp Report Blocks. Because of the automatic bandwidth adjustment mechanisms in RTCP, if some session participants are sending large RTCP packets, all participants will see their RTCP reporting intervals lengthened, meaning they will be able to report less frequently. To limit the effects of large packets, even in the absence of denial of service attacks, applications SHOULD limit the size of XR report blocks and employ the thinning techniques described in this document in order to fit reports into the space available. A. Algorithms A.1 Sequence Number Interpretation This the algorithm suggested by Section 4.1 for keeping track of the sequence numbers from a given sender. It implements the accounting practice required for the generation of Loss RLE Report Blocks. This algorithm keeps track of 16 bit sequence numbers by translating them into a 32 bit sequence number space. The first packet received from a source is considered to have arrived roughly in the middle of that space. Each packet that follows is placed either ahead or behind the prior one in this 32 bit space, depending upon which choice would place it closer (or, in the event of a tie, which choice would not require a rollover in the 16 bit sequence number). // The reference sequence number is an extended sequence number // that serves as the basis for determining whether a new 16 bit // sequence number comes earlier or later in the 32 bit sequence // space. u_int32 _src_ref_seq; bool _uninitialized_src_ref_seq; // Place seq into a 32-bit sequence number space based upon a // heuristic for its most likely location. u_int32 extend_seq(const u_int16 seq) { u_int32 extended_seq, seq_a, seq_b, diff_a, diff_b; if(_uninitialized_src_ref_seq) { Friedman, Caceres, and Clark, eds. [Page 34] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 // This is the first sequence number received. Place // it in the middle of the extended sequence number // space. _src_ref_seq =3D seq | 0x80000000u; _uninitialized_src_ref_seq =3D false; extended_seq =3D _src_ref_seq; } else { // Prior sequence numbers have been received. // Propose two candidates for the extended sequence // number: seq_a is without wraparound, seq_b with // wraparound. seq_a =3D seq | (_src_ref_seq & 0xFFFF0000u); if(_src_ref_seq < seq_a) { seq_b =3D seq_a - 0x00010000u; diff_a =3D seq_a - _src_ref_seq; diff_b =3D _src_ref_seq - seq_b; } else { seq_b =3D seq_a + 0x00010000u; diff_a =3D _src_ref_seq - seq_a; diff_b =3D seq_b - _src_ref_seq; } // Choose the closer candidate. If they are equally // close, the choice is somewhat arbitrary: we choose // the candidate for which no rollover is necessary. if(diff_a < diff_b) { extended_seq =3D seq_a; } else { extended_seq =3D seq_b; } // Set the reference sequence number to be this most // recently-received sequence number. _src_ref_seq =3D extended_seq; } // Return our best guess for a 32-bit sequence number that // corresponds to the 16-bit number we were given. return extended_seq; } A.2 Example Burst Packet Loss Calculation. This is an algorithm for measuring the burst characteristics for the Friedman, Caceres, and Clark, eds. [Page 35] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 VoIP Metrics Report Block (Section 4.7). It is reproduced from ETSI TS 101 329-5 [2]. The algorithm is event driven and hence extremely computationally efficient. Given the following definition of states: state 1 =3D received a packet during a gap state 2 =3D received a packet during a burst state 3 =3D lost a packet during a burst state 4 =3D lost an isolated packet during a gap The "c" variables below correspond to state transition counts, i.e. c14 is the transition from state 1 to state 4. It is possible to infer one of a pair of state transition counts to an accuracy of 1 which is generally sufficient for this application. "pkt" is the count of packets received since the last packet was declared lost or discarded and "lost" is the number of packets lost within the current burst. "packet_lost" and "packet_discarded" are boolean variables that indicate if the event that resulted in this function being invoked was a lost or discarded packet. if(packet_lost) { loss_count++; } if(packet_discarded) { discard_count++; } if(!packet_lost && !packet_discarded) { pkt++; } else { if(pkt >=3D gmin) { if(lost =3D=3D 1) { c14++; } else { c13++; } lost =3D 1; c11 +=3D pkt; } else { lost++; if(pkt =3D=3D 0) { c33++; Friedman, Caceres, and Clark, eds. [Page 36] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 } else { c23++; c22 +=3D (pkt - 1); } } pkt =3D 0; } At each reporting interval the burst and gap metrics can be calculated as follows. // Calculate additional transition counts. c31 =3D c13; c32 =3D c23; ctotal =3D c11 + c14 + c13 + c22 + c23 + c31 + c32 + c33; // Calculate burst and densities. p32 =3D c32 / (c31 + c32 + c33); if((c22 + c23) < 1) { p23 =3D 1; } else { p23 =3D 1 - c22/(c22 + c23); } burst_density =3D 256 * p23 / (p23 + p32); gap_density =3D 256 * c14 / (c11 + c14); // Calculate burst and gap durations in ms m =3D frameDuration_in_ms * framesPerRTPPkt; gap_length =3D (c11 + c14 + c13) * m / c13; burst_length =3D ctotal * m / c13 - lgap; /* calculate loss and discard densities */ loss_density =3D 256 * loss_count / ctotal; discard_density =3D 256 * discard_count / ctotal; Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP 11 [3]. Copies of claims of rights made available for publication and any assurances Friedman, Caceres, and Clark, eds. [Page 37] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgements We thank the following people: Colin Perkins, Steve Casner, and Henning Schulzrinne for their considered guidance; Sue Moon for helping foster collaboration between the authors; Magnus Westerlund for his detailed comments; Mounir Benzaid for drawing our attention to the reporting needs of MLDA; and Dorgham Sisalem and Adam Wolisz for encouraging us to incorporate MLDA block types. Friedman, Caceres, and Clark, eds. [Page 38] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 Contributors The following people are the authors of this document: Kevin Almeroth, UCSB Ramon Caceres, ShieldIP Alan Clark, Telchemy Robert Cole, AT&T Labs Nick Duffield, AT&T Labs-Research Timur Friedman, Paris 6 Kaynam Hedayat, Brix Networks Kamil Sarac, UT Dallas The principal people to contact regarding the individual report blocks described in this document are as follows: sec. report block principal contributors ---- ------------ ---------------------- 4.1 Loss RLE Report Block Friedman, Caceres, Duffield 4.2 Duplicate RLE Report Block Friedman, Caceres, Duffield 4.3 Timestamp Report Block Friedman, Caceres, Duffield 4.4 Statistics Summary Report Block Almeroth, Sarac 4.5 Receiver Timestamp Report Block Friedman 4.6 DLRR Report Block Friedman 4.7 VoIP Metrics Report Block Clark, Cole, Hedayat Authors' Addresses Kevin Almeroth Department of Computer Science University of California Santa Barbara, CA 93106 USA Ramon Caceres ShieldIP, Inc. 11 West 42nd Street, 31st Floor New York, NY 10036 USA Alan Clark Telchemy Incorporated 3360 Martins Farm Road, Suite 200 Suwanee, GA 30024 USA Tel: +1 770 614 6944 Fax: +1 770 614 3951 Friedman, Caceres, and Clark, eds. [Page 39] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 Robert Cole AT&T Labs 330 Saint Johns Street, 2nd Floor Havre de Grace, MD 21078 USA Tel: +1 410 939 8732 Fax: +1 410 939 8732 Nick Duffield AT&T Labs-Research 180 Park Avenue, P.O. Box 971 Florham Park, NJ 07932-0971 USA Tel: +1 973 360 8726 Fax: +1 973 360 8050 Timur Friedman Universite Pierre et Marie Curie (Paris 6) Laboratoire LiP6-CNRS 8, rue du Capitaine Scott 75015 PARIS France Tel: +33 1 44 27 71 06 Fax: +33 1 44 27 74 95 Kaynam Hedayat Brix Networks 285 Mill Road Chelmsford, MA 01824 USA Tel: +1 978 367 5600 Fax: +1 978 367 5700 Kamil Sarac Department of Computer Science (ES 4.207) Eric Jonsson School of Engineering & Computer Science University of Texas at Dallas Richardson, TX 75083-0688 USA Tel: +1 972 883 2337 Fax: +1 972 883 2349 References The references are divided into normative references and non- normative references. Normative References [1] S. Bradner, "Key words for use in RFCs to indicate requirement levels," BCP 14, RFC 2119, IETF, March 1997. Friedman, Caceres, and Clark, eds. [Page 40] =0C draft-ietf-avt-rtcp-report-extns-02.txt 24 January 2003 [2] ETSI, "Quality of Service (QoS) measurement methodologies," ETSI TS 101 329-5 V1.1.1 (2000-11), November 2000. [3] R. Hovey and S. Bradner, "The Organizations Involved in the IETF Standards Process," best current practice BCP 11, RFC 2028, IETF, October 1996. [4] ITU-T, "The E-Model, a computational model for use in transmission planning," Recommendation G.107 (05/00), May 2000. [5] J. Reynolds and J. Postel, "Assigned Numbers," standard STD 2, RFC 1700, IETF, October 1994. [6] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs," best current practice BCP 26, RFC 2434, IETF, October 1998. [7] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A transport protocol for real-time applications," RFC 1889, IETF, February 1996. Non-Normative References [8] A. Adams, T. Bu, R. Caceres, N. G. Duffield, T. Friedman, J. Horowitz, F. Lo Presti, S. B. Moon, V. Paxson, and D. Towsley, "The Use of End-to-End Multicast Measurements for Characterizing Internal Network Behavior," IEEE Communications Magazine, May 2000. [9] R. Caceres, N. G. Duffield, and T. Friedman, "Impromptu measurement infrastructures using RTP," Proc. IEEE Infocom 2002. [10] A. D. Clark, "Modeling the Effects of Burst Packet Loss and Recency on Subjective Voice Quality," Proc. IP Telephony Workshop 2001. [11] D. Sisalem and A. Wolisz, "MLDA: A TCP-friendly Congestion Control Framework for Heterogeneous Multicast Environments", Proc. IWQoS 2000. Friedman, Caceres, and Clark, eds. [Page 41] =0C --------------Boundary-00=_FTK8U83HGMQP77OV27MC-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Jan 27 15:45:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26010 for ; Mon, 27 Jan 2003 15:45:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0RL6Om16646 for avt-archive@odin.ietf.org; Mon, 27 Jan 2003 16:06:24 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RL4kJ16584; Mon, 27 Jan 2003 16:04:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RL3DJ16537 for ; Mon, 27 Jan 2003 16:03:13 -0500 Received: from mailman.packetdesign.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25962 for ; Mon, 27 Jan 2003 15:42:05 -0500 (EST) Received: from ash.packetdesign.com (ash.packetdesign.com [192.168.0.243]) by mailman.packetdesign.com (8.12.6/8.12.3) with ESMTP id h0RKdeXj078275; Mon, 27 Jan 2003 12:39:41 -0800 (PST) (envelope-from casner@acm.org) Date: Mon, 27 Jan 2003 12:39:40 -0800 (PST) From: Stephen Casner To: Linus Walleij cc: Harald Tveit Alvestrand , , , , Subject: Re: Fwd: Re: [AVT] Re: New I-Ds for Ogg technologies (Vorbis over RTP, Ogg file format, Mimetypes) In-Reply-To: Message-ID: <20030127123432.U76694-100000@ash.packetdesign.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , On Mon, 27 Jan 2003, Linus Walleij wrote: > On Fri, 24 Jan 2003, Harald Tveit Alvestrand wrote: > > > 2) how to make sure no two codecs pick the same identifier string? > > (the "registry" problem) > > This is a natural pointer to the IANA, in case you want to establish > something rock-solid. Not that I know if they would like to do this, but > it it is to be a widely accepted standard for codec identification, IANA > would be the place to store the strings. I agree. And my take is that therefore ogg should not be a MIME subtype. Instead, vorbis should be a MIME subtype, and ogg should be (an aspect of) one encoding for the vorbis subtype, just like the RTP payload format is another encoding for the vorbis subtype. The MIME registration for vorbis can explain these different encodings, and can give the "magic number" string which can be the same as the MIME subtype name (and therefore unique). > Alternatively, you could list the magic strings available today, and > require extensions to file further informational RFCs for the additions. > (Sort of sticky and slow in comparison to IANA handling it.) The magic strings already in use would need to be registered as MIME subtypes (assuming no conflicts with subtypes already registered). -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Jan 27 16:58:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28517 for ; Mon, 27 Jan 2003 16:58:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0RMJUC21752 for avt-archive@odin.ietf.org; Mon, 27 Jan 2003 17:19:30 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RMIbJ21704; Mon, 27 Jan 2003 17:18:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RLsbJ19542 for ; Mon, 27 Jan 2003 16:54:37 -0500 Received: from f1ee40-19.idc1.level3.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27643 for ; Mon, 27 Jan 2003 16:33:28 -0500 (EST) Received: from idc1exc0001.corp.global.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with SMTP id VAA23370; Mon, 27 Jan 2003 21:36:57 GMT Received: from idc1exc0004.corp.global.level3.com ([10.1.6.220]) by idc1exc0001.corp.global.level3.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 27 Jan 2003 14:36:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 27 Jan 2003 14:36:55 -0700 Message-ID: <7AD66BFE16525B479D429E4550AFE56D1987F6@idc1exc0004.corp.global.level3.com> Thread-Topic: RE: RTP Payload Format for SMPTE 292M Video Thread-Index: AcLGTDa2pxoDCTIaEdecSACw0Kdx2w== From: "Schmidt, Erik" To: Cc: X-OriginalArrivalTime: 27 Jan 2003 21:36:56.0884 (UTC) FILETIME=[3762EF40:01C2C64C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0RLsbJ19543 Subject: [AVT] RE: RTP Payload Format for SMPTE 292M Video Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Audio Video Transport Working Group: I am not an engineer so I apologize in advance for my lack of knowledge or for asking this question in the wrong venue. In regards to the Internet draft referenced above has any work been done on the reverse case scenario i.e. a payload format for ATM, Frame or Ethernet over SDI? I would be very interested in learning more about this capability. Best regards, Erik Schmidt Erik Schmidt Corporate Strategy Level 3 Communications 1025 Eldorado Blvd Broomfield, CO 80021 PH: 720-888-6385 FX: 509-561-7525 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Jan 28 06:46:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21928 for ; Tue, 28 Jan 2003 06:46:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0SC7cD13909 for avt-archive@odin.ietf.org; Tue, 28 Jan 2003 07:07:38 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SC77J13478; Tue, 28 Jan 2003 07:07:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SC5OJ13208 for ; Tue, 28 Jan 2003 07:05:24 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21580; Tue, 28 Jan 2003 06:43:58 -0500 (EST) Message-Id: <200301281143.GAA21580@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: avt@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 28 Jan 2003 06:43:58 -0500 Subject: [AVT] I-D ACTION:draft-ietf-avt-rtcp-report-extns-02.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Extended Reports (RTP XR) Author(s) : T. Friedman et al. Filename : draft-ietf-avt-rtcp-report-extns-02.txt Pages : 41 Date : 2003-1-27 This document defines the extended report (XR) packet type for the RTP control protocol (RTCP). XR packets are composed of report blocks, and seven block types are defined here. The purpose of the extended reporting format is to convey information that supplements the six statistics that are contained in the report blocks used by RTCP's sender report (SR) and receiver report (RR) packets. Some applications, such as multicast inference of network characteristics (MINC) or voice over IP (VoIP) monitoring, require other and more detailed statistics. In addition to the block types defined here, additional block types may be defined in the future by adhereing to the framework that this document provides. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcp-report-extns-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtcp-report-extns-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtcp-report-extns-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-27081108.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtcp-report-extns-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtcp-report-extns-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-27081108.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Jan 28 11:47:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00872 for ; Tue, 28 Jan 2003 11:47:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0SH8bj02893 for avt-archive@odin.ietf.org; Tue, 28 Jan 2003 12:08:37 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SH2BJ01751; Tue, 28 Jan 2003 12:02:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SGkKJ00630 for ; Tue, 28 Jan 2003 11:46:20 -0500 Received: from znsgs01r.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29797 for ; Tue, 28 Jan 2003 11:24:47 -0500 (EST) Received: from znsgy0k8.europe.nortel.com (europem01.nt.com [47.165.24.67]) by znsgs01r.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0SGS7B16861; Tue, 28 Jan 2003 16:28:07 GMT Received: from zwcwc012.europe.nortel.com ([47.160.46.124]) by znsgy0k8.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id D5GCLQM9; Tue, 28 Jan 2003 16:28:07 -0000 Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 28 Jan 2003 16:19:49 -0000 Message-ID: <6B78F2524CD7D5118A0402204840075B01B1EF53@zhard0jc.europe.nortel.com> X-Sybari-Space: 00000000 00000000 00000000 From: "Dominic Walker" To: "'casner@acm.org'" , "'csp@isi.edu'" Cc: "'avt@ietf.org'" Date: Tue, 28 Jan 2003 16:19:44 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C6E9.11767732" Subject: [AVT] when will draft-ietf-avt-rfc2833bis-02 become an RFC? Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2C6E9.11767732 Content-Type: text/plain; charset="iso-8859-1" Dear S. Bradner and A. Mankin, Could you tell me by when it is envisioned that the draft RFC : draft-ietf-avt-rfc2833bis-02.txt "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals " would become an RFC? What approval process must it go through in order to become an RFC (Must it be voted at the next IETF meeting)?. Also, would it be called RFC2833 or RFC 2833bis? Regards, Dominic ____________________________________________ Dominic Walker Passport Packet Voice Gateways Carrier Voice over IP Nortel Networks Research London Road, Harlow, Essex, CM17 9NA, UK Tel: (direct) +44 (0)1279 403379 ESN (Internal): 742-3379 Fax:(direct) +44 (0)1279 402885 mailto:dominic.walker@nortelnetworks.com __________________________________________________ Registered Office: Nortel Networks Ltd, Maidenhead Office Park, Westacott Way, Maidenhead, Berkshire SL6 3QH.Registered in England No. 2515751 __________________________________________________________ This message may contain information proprietary to Nortel Networks plc so any unauthorised disclosure, copying or distribution of its contents is strictly prohibited. __________________________________________________________ ------_=_NextPart_001_01C2C6E9.11767732 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable when will draft-ietf-avt-rfc2833bis-02 become an RFC?

Dear S. Bradner and A. Mankin,

Could you tell me by when it is = envisioned that the draft RFC : draft-ietf-avt-rfc2833bis-02.txt = "RTP Payload for DTMF = Digits, Telephony Tones and Telephony Signals " would become an = RFC? What approval process must it go through in order to become an RFC = (Must it be voted at the next IETF meeting)?. Also, would it be called = RFC2833 or RFC 2833bis?

Regards,
Dominic
____________________________________________
Dominic Walker
Passport Packet Voice Gateways
Carrier Voice over IP
Nortel Networks Research
London Road,
Harlow, Essex, CM17 9NA, UK

   Tel: (direct) +44 (0)1279 = 403379
ESN (Internal): 742-3379
 Fax:(direct) +44 (0)1279 = 402885
mailto:dominic.walker@= nortelnetworks.com
__________________________________________________=
Registered = Office:
Nortel Networks = Ltd, Maidenhead Office Park, Westacott Way,
Maidenhead, = Berkshire SL6 3QH.Registered in England No. 2515751
________________________________________________________= __

 This message = may contain information proprietary to Nortel Networks plc
         &n= bsp;      so any unauthorised disclosure, = copying or distribution
         &n= bsp;           &n= bsp;          of its = contents is strictly prohibited.
________________________________________________________= __ =20


------_=_NextPart_001_01C2C6E9.11767732-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Jan 29 07:03:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16870 for ; Wed, 29 Jan 2003 07:03:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0TCPKs20071 for avt-archive@odin.ietf.org; Wed, 29 Jan 2003 07:25:20 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TCHMJ19746; Wed, 29 Jan 2003 07:17:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TCFwJ19674 for ; Wed, 29 Jan 2003 07:15:58 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16657; Wed, 29 Jan 2003 06:54:03 -0500 (EST) Message-Id: <200301291154.GAA16657@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: avt@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 29 Jan 2003 06:54:03 -0500 Subject: [AVT] I-D ACTION:draft-vilhuber-hcoip-00.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IP header compression in IP tunneling protocols Author(s) : J. Vilhuber Filename : draft-vilhuber-hcoip-00.txt Pages : 5 Date : 2003-1-28 Bandwidth consumption of RTP flows can be reduced by tunneling and compressing headers. This draft defines an IP protocol number and a header which can be used to transport IP Header Compressed [IPHC], Compressed RTP [CRTP], and Enhanced Compressed RTP [ECRTP] packets over an arbitrary IP tunnel (IP-in-IP or ESP, for example) to reduce bandwidth consumption for RTP flows. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-vilhuber-hcoip-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-vilhuber-hcoip-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-vilhuber-hcoip-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-28082704.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-vilhuber-hcoip-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-vilhuber-hcoip-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-28082704.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Jan 29 07:07:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16928 for ; Wed, 29 Jan 2003 07:07:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0TCSou20186 for avt-archive@odin.ietf.org; Wed, 29 Jan 2003 07:28:50 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TCL3J19897; Wed, 29 Jan 2003 07:21:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TCG3J19683 for ; Wed, 29 Jan 2003 07:16:03 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16674; Wed, 29 Jan 2003 06:54:08 -0500 (EST) Message-Id: <200301291154.GAA16674@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: avt@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 29 Jan 2003 06:54:08 -0500 Subject: [AVT] I-D ACTION:draft-vilhuber-hcoesp-00.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IP header compression in IPsec ESP Author(s) : J. Vilhuber Filename : draft-vilhuber-hcoesp-00.txt Pages : 8 Date : 2003-1-28 This draft outlines how to use IP Header compression over IP tunnels [HCOIP] inside IPsec ESP [ESP]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-vilhuber-hcoesp-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-vilhuber-hcoesp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-vilhuber-hcoesp-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-28082714.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-vilhuber-hcoesp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-vilhuber-hcoesp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-28082714.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Jan 30 15:31:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09796 for ; Thu, 30 Jan 2003 15:31:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0UKYF627473 for avt-archive@odin.ietf.org; Thu, 30 Jan 2003 15:34:15 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UKWeJ27408; Thu, 30 Jan 2003 15:32:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UJ8rJ22790 for ; Thu, 30 Jan 2003 14:08:53 -0500 Received: from scandium.dolby.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07235 for ; Thu, 30 Jan 2003 14:05:07 -0500 (EST) Received: from platinum.dolby.net ([172.16.33.28]) by 192.168.16.253 with InterScan Messaging Security Suite; Thu, 30 Jan 2003 11:08:01 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C2C892.E7017420" Subject: [AVT] draft-flaks-avt-rtp-ac3-03.txt Date: Thu, 30 Jan 2003 11:07:58 -0800 Message-ID: <5FCCC03CAF7C5C4C8E2F995E3D72E1330167381B@platinum.dolby.net> X-MS-Has-Attach: yes Thread-Topic: [AVT] draft-flaks-avt-rtp-ac3-03.txt Thread-Index: AcLGJNPVyZsHEa9KRaWRq8w0MdI3sQCaw3EQ From: "Hager, Todd" To: Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C2C892.E7017420 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Please find attached the latest version of the RTP Payload Format for AC-3 Streams draft, draft-flaks-avt-rtp-ac3-03.txt. This has just been submitted to internet-drafts@ietf.org.=20 This is the first draft submission with myself replacing Jason Flaks as the document author. Changes are mostly editorial. The single technical change in this revision was made to the NDU field=20 described in 2.1.1. Previously, the NDU was designated as the high 4=20 bits of a byte with the low 4 bits marked as reserved. Now the NDU is an=20 8-bit number so that no bit shifting is required to process it. Next efforts will involve reviewing the redundant data mechanism descibed in 2.3 for conformance with RFC 2198. I expect to issue a -04 release in time for the March 3 deadline. Regards, Todd Hager Dolby Laboratories Internet Draft T. Hager January 2003 Dolby Laboratories Expires: June 2003 J. Flaks Microsoft Corporation RTP Payload Format for AC-3 Streams Abstract=20 This document describes an RTP payload format for transporting AC-3=20 encoded audio data. AC-3 is a high quality multichannel audio coding=20 system used in ATSC HDTV, DVD, film, and other media. The RTP payload=20 format presented in this document provides mechanisms for interleaving=20 redundant data, which can increase packet loss resilience. An=20 intelligent method for fragmenting AC-3 frames that exceed the maximum=20 transfer unit (MTU) is also described.=20 This message (including any attachments) may contain confidential= information intended for a specific individual and purpose. If you are not= the intended recipient, delete this message. If you are not the intended= recipient, disclosing, copying, distributing, or taking any action based= on this message is strictly prohibited. ------_=_NextPart_001_01C2C892.E7017420 Content-Type: text/plain; name="draft-flaks-avt-rtp-ac3-03.txt" Content-Description: draft-flaks-avt-rtp-ac3-03.txt Content-Disposition: attachment; filename="draft-flaks-avt-rtp-ac3-03.txt" Content-Transfer-Encoding: base64 DQoNCg0KDQoNCg0KSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgVC4gSGFnZXINCkphbnVhcnkgMjAwMyAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgRG9sYnkgTGFib3JhdG9yaWVzDQpFeHBpcmVzOiBKdW5l IDIwMDMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBKLiBGbGFr cw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBNaWNy b3NvZnQgQ29ycG9yYXRpb24NCg0KICAgICAgICAgICAgICAgICAgUlRQIFBheWxvYWQgRm9ybWF0 IGZvciBBQy0zIFN0cmVhbXMNCiAgICAgICAgICAgICAgICAgICA8ZHJhZnQtZmxha3MtYXZ0LXJ0 cC1hYzMtMDMudHh0Pg0KDQoNClN0YXR1cyBvZiB0aGlzIE1lbW8gDQoNClRoaXMgZG9jdW1lbnQg aXMgYW4gSW50ZXJuZXQtRHJhZnQgYW5kIGlzIGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCBhbGwg DQpwcm92aXNpb25zIG9mIFNlY3Rpb24gMTAgb2YgUkZDMjAyNi4gDQoNCkludGVybmV0LURyYWZ0 cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nIA0KVGFz ayBGb3JjZSAoSUVURiksIGl0cyBhcmVhcywgYW5kIGl0cyB3b3JraW5nIGdyb3Vwcy4gIE5vdGUg dGhhdCANCm90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlIHdvcmtpbmcgZG9jdW1lbnRz IGFzIA0KSW50ZXJuZXQtRHJhZnRzLiANCg0KSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1 bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggDQptb250aHMgYW5kIG1heSBiZSB1cGRh dGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIA0KZG9jdW1lbnRzIGF0IGFueSB0 aW1lLiBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC0NCkRyYWZ0cyBhcyByZWZl cmVuY2UgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgDQoid29yayBpbiBw cm9ncmVzcy4iIA0KDQpUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUg YWNjZXNzZWQgYXQgDQpodHRwOi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQg DQoNClRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4gYmUg YWNjZXNzZWQgYXQgDQpodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sLiANCg0KVGhlIGtl eSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBO T1QiLCANCiJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FREVEIiwgIk1BWSIsIGFuZCAi T1BUSU9OQUwiIGluIHRoaXMgDQpkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVz Y3JpYmVkIGluIFJGQyAyMTE5IFsxXS4gDQoNCg0KDQpBYnN0cmFjdCANCg0KVGhpcyBkb2N1bWVu dCBkZXNjcmliZXMgYW4gUlRQIHBheWxvYWQgZm9ybWF0IGZvciB0cmFuc3BvcnRpbmcgQUMtMyAN CmVuY29kZWQgYXVkaW8gZGF0YS4gIEFDLTMgaXMgYSBoaWdoIHF1YWxpdHkgbXVsdGljaGFubmVs IGF1ZGlvIGNvZGluZyANCnN5c3RlbSB1c2VkIGluIEFUU0MgSERUViwgRFZELCBmaWxtLCBhbmQg b3RoZXIgbWVkaWEuICBUaGUgUlRQIHBheWxvYWQgDQpmb3JtYXQgcHJlc2VudGVkIGluIHRoaXMg ZG9jdW1lbnQgcHJvdmlkZXMgbWVjaGFuaXNtcyBmb3IgaW50ZXJsZWF2aW5nIA0KcmVkdW5kYW50 IGRhdGEsIHdoaWNoIGNhbiBpbmNyZWFzZSBwYWNrZXQgbG9zcyByZXNpbGllbmNlLiAgQW4gDQpp bnRlbGxpZ2VudCBtZXRob2QgZm9yIGZyYWdtZW50aW5nIEFDLTMgZnJhbWVzIHRoYXQgZXhjZWVk IHRoZSBtYXhpbXVtIA0KdHJhbnNmZXIgdW5pdCAoTVRVKSBpcyBhbHNvIGRlc2NyaWJlZC4gDQoN Cg0KDQoNCkhhZ2VyL0ZsYWtzICAgICAgICAgICAgICAgICBFeHBpcmVzIEp1bmUgMjAwMyAgICAg ICAgICAgICAgICAgICBbUGFnZSAxXQ0KDA0KSW50ZXJuZXQgRHJhZnQgICAgICBSVFAgUGF5bG9h ZCBGb3JtYXQgZm9yIEFDLTMgU3RyZWFtcyAgICAgSmFudWFyeSAyMDAzDQoNCg0KDQowLiBDaGFu Z2UgTG9nIGZvciA8ZHJhZnQtZmxha3MtYXZ0LXJ0cC1hYzMtMDMudHh0Pg0KDQpUaGlzIGlzIHRo ZSBmaXJzdCBkcmFmdCBzdWJtaXNzaW9uIHdpdGggVG9kZCBIYWdlciByZXBsYWNpbmcgSmFzb24g Rmxha3MNCmFzIGF1dGhvci4gTW9zdCBjaGFuZ2VzIGFyZSBlZGl0b3JpYWwgYW5kIGFyZSBub3Qg ZGV0YWlsZWQgaW4gdGhpcyBsb2cuDQoNClRoZSBzaW5nbGUgdGVjaG5pY2FsIGNoYW5nZSBpbiB0 aGlzIHJldmlzaW9uIHdhcyBtYWRlIHRvIHRoZSBORFUgZmllbGQgDQpkZXNjcmliZWQgaW4gMi4x LjEuIFByZXZpb3VzbHksIHRoZSBORFUgd2FzIGRlc2lnbmF0ZWQgYXMgdGhlIGhpZ2ggNCANCmJp dHMgb2YgYSBieXRlIHdpdGggdGhlIGxvdyA0IGJpdHMgbWFya2VkIGFzIHJlc2VydmVkLiAgTm93 IHRoZSBORFUgaXMgYW4gDQo4LWJpdCBudW1iZXIgc28gdGhhdCBubyBiaXQgc2hpZnRpbmcgaXMg cmVxdWlyZWQgdG8gcHJvY2VzcyBpdC4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpIYWdlci9G bGFrcyAgICAgICAgICAgICAgICAgRXhwaXJlcyBKdW5lIDIwMDMgICAgICAgICAgICAgICAgICAg W1BhZ2UgMl0NCgwNCkludGVybmV0IERyYWZ0ICAgICAgUlRQIFBheWxvYWQgRm9ybWF0IGZvciBB Qy0zIFN0cmVhbXMgICAgIEphbnVhcnkgMjAwMw0KDQoNCjEuIEludHJvZHVjdGlvbiANCg0KQUMt MyBpcyBhIGhpZ2ggcXVhbGl0eSBhdWRpbyBjb2RlYyBkZXNpZ25lZCB0byBlbmNvZGUgbXVsdGlw bGUgY2hhbm5lbHMgDQpvZiBhdWRpbyBpbnRvIGEgbG93IGJpdC1yYXRlIGZvcm1hdC4gIEFDLTMg YWNoaWV2ZXMgaXRzIGxhcmdlIA0KY29tcHJlc3Npb24gcmF0aW9zIHZpYSBlbmNvZGluZyBhIG11 bHRpcGxpY2l0eSBvZiBjaGFubmVscyBhcyBhIHNpbmdsZSANCmVudGl0eS4gIERvbGJ5IERpZ2l0 YWwsIHdoaWNoIGlzIGEgYnJhbmRlZCB2ZXJzaW9uIG9mIEFDLTMsIGVuY29kZXMgdXAgDQp0byA1 LjEgY2hhbm5lbHMgb2YgYXVkaW8uDQogDQpBQy0zIGhhcyBiZWVuIGFkb3B0ZWQgYXMgYW4gYXVk aW8gY29tcHJlc3Npb24gc2NoZW1lIGZvciBtYW55IGNvbnN1bWVyIA0KYW5kIHByb2Zlc3Npb25h bCBhcHBsaWNhdGlvbnMuICBJdCBpcyB0aGUgbWFuZGF0b3J5IGNvZGVjIGZvciBEVkQtdmlkZW8s DQpBVFNDIGRpZ2l0YWwgdGVycmVzdHJpYWwgdGVsZXZpc2lvbiwgbGFzZXIgZGlzYywgYW5kIERW RC1hdWRpbyAoYXMgYW4gDQpvcHRpb25hbCBtdWx0aWNoYW5uZWwgYXVkaW8gZm9ybWF0KS4gQUMt MyBpcyBhbHNvIGEgY29tbW9uIGF1ZGlvIGZvcm1hdCANCmZvciBmaWxtLiANCiANCkl0IGlzIGhp Z2hseSBsaWtlbHkgdGhhdCBwZW9wbGUgbWF5IHdpc2ggdG8gc3RyZWFtIEFDLTMgZGF0YSBvdmVy IElQIA0KbmV0d29ya3MuICBBcHBsaWNhdGlvbnMgZm9yIHN0cmVhbWluZyBBQy0zIHJhbmdlIGZy b20gdmlkZW8gb24gZGVtYW5kIHRvDQptdWx0aWNoYW5uZWwgSW50ZXJuZXQgcmFkaW8uICBSVFAg cHJvdmlkZXMgYSBtZWNoYW5pc20gZm9yIHN0cmVhbSANCnN5bmNocm9uaXphdGlvbiBhbmQgaGVu Y2Ugc2VydmVzIGFzIHRoZSBiZXN0IHRyYW5zcG9ydCBzb2x1dGlvbiBmb3IgDQpBQy0zLCB3aGlj aCBpcyBhIGNvZGVjIHByaW1hcmlseSB1c2VkIGluIGF1ZGlvIGZvciB2aWRlbyBhcHBsaWNhdGlv bnMuIA0KVGhlIFJUUCBwYXlsb2FkIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50IGFsc28gcHJv dmlkZXMgYSBtZXRob2Qgb2YgDQplbnN1cmluZyBhIGNvbnRpbnVvdXMgaGlnaCBxdWFsaXR5IEFD LTMgc3RyZWFtLg0KIA0KMS4xIE92ZXJ2aWV3IG9mIEFDLTMgDQogDQpBQy0zIGNhbiBkZWxpdmVy IHVwIHRvIDUuMSBjaGFubmVscyBvZiBhdWRpbyBhdCBkYXRhIHJhdGVzIGFwcHJveGltYXRlbHkN CmVxdWFsIHRvIGhhbGYgb2Ygb25lIFBDTSBjaGFubmVsIFsyXSwgWzZdLCBbN10uIFRoZSAiLjEi IHJlZmVycyB0byBhIA0KYmFuZCBsaW1pdGVkIG9wdGlvbmFsIGxvdy1mcmVxdWVuY3kgZW5oYW5j ZW1lbnQgY2hhbm5lbC4gQUMtMyB3YXMgDQpkZXNpZ25lZCBmb3Igc2lnbmFscyBzYW1wbGVkIGF0 IHJhdGVzIG9mIDMyLCA0NC4xLCBvciA0OCBrSHouIERhdGEgcmF0ZXMNCmNhbiB2YXJ5IGJldHdl ZW4gNjQga2JwcyBhbmQgNjQwIGtwYnMgZGVwZW5kaW5nIHRoZSBudW1iZXIgb2YgY2hhbm5lbHMg DQphbmQgZGVzaXJlZCBxdWFsaXR5Lg0KIA0KQUMtMyBleHBsb2l0cyBwc3ljaG9hY291c3RpYyBw aGVub21lbmEgdGhhdCByZXZlYWwgbGFyZ2UgYW1vdW50cyBvZiANCmluYXVkaWJsZSBpbmZvcm1h dGlvbiBjb250YWluZWQgaW4gYSB0eXBpY2FsIGF1ZGlvIHNpZ25hbC4gIFN1YnN0YW50aWFsIA0K ZGF0YSByZWR1Y3Rpb24gb2NjdXJzIHZpYSB0aGUgcmVtb3ZhbCBvZiBhbGwgaW5hdWRpYmxlIGlu Zm9ybWF0aW9uIA0KY29udGFpbmVkIGluIGFuIGF1ZGlvIHN0cmVhbS4gIFNvdXJjZSBjb2Rpbmcg dGVjaG5pcXVlcyBhcmUgZnVydGhlciB1c2VkDQp0byByZWR1Y2UgdGhlIGRhdGEgdXNlZCB0byBj b2RlIGFuIGF1ZGlvIHNpZ25hbC4NCiANCkxpa2UgbW9zdCBwZXJjZXB0dWFsIGNvZGVycywgQUMt MyBvcGVyYXRlcyBpbiB0aGUgZnJlcXVlbmN5IGRvbWFpbi4gIEEgDQo1MTItcG9pbnQgVERBQyB0 cmFuc2Zvcm0gaXMgdGFrZW4gd2l0aCA1MCUgb3ZlcmxhcCwgcHJvdmlkaW5nIDI1NiBuZXcgDQpm cmVxdWVuY3kgc2FtcGxlcy4gIEZyZXF1ZW5jeSBzYW1wbGVzIGFyZSB0aGVuIGNvbnZlcnRlZCB0 byBleHBvbmVudHMgDQphbmQgbWFudGlzc2FzLiAgRXhwb25lbnRzIGFyZSBkaWZmZXJlbnRpYWxs eSBlbmNvZGVkLiAgTWFudGlzc2FzIGFyZSANCmFsbG9jYXRlZCBhIHZhcnlpbmcgbnVtYmVyIG9m IGJpdHMgZGVwZW5kaW5nIG9uIHRoZSBhdWRpYmlsaXR5IG9mIHRoZSANCnNwZWN0cmFsIGNvbXBv bmVudCBhc3NvY2lhdGVkIHdpdGggaXQuIEF1ZGliaWxpdHkgaXMgZGV0ZXJtaW5lZCB2aWEgYSAN Cm1hc2tpbmcgY3VydmUuICBCaXRzIGZvciBtYW50aXNzYXMgYXJlIGFsbG9jYXRlZCBmcm9tIGEg Z2xvYmFsIGJpdCBwb29sLg0KIA0KMS4yIEFDLTMgQml0c3RyZWFtIA0KIA0KQUMtMyBiaXRzdHJl YW1zIGFyZSBvcmdhbml6ZWQgaW50byBzeW5jaHJvbml6YXRpb24gZnJhbWVzLiAgRWFjaCBBQy0z IA0Kc3luYyBmcmFtZSBjb250YWlucyBhIFN5bmMgSW5mb3JtYXRpb24gKFNJKSBmaWVsZCwgYSBC aXQgU3RyZWFtIA0KSW5mb3JtYXRpb24gKEJTSSkgZmllbGQsIGFuZCA2IGF1ZGlvIGJsb2NrcyAo QUIpIHJlcHJlc2VudGluZyAyNTYgUENNIA0KDQpIYWdlci9GbGFrcyAgICAgICAgICAgICAgICAg RXhwaXJlcyBKdW5lIDIwMDMgICAgICAgICAgICAgICAgICAgW1BhZ2UgM10NCgwNCkludGVybmV0 IERyYWZ0ICAgICAgUlRQIFBheWxvYWQgRm9ybWF0IGZvciBBQy0zIFN0cmVhbXMgICAgIEphbnVh cnkgMjAwMw0KDQoNCnNhbXBsZXMgZm9yIGVhY2ggY2hhbm5lbC4gIFRoZSBlbnRpcmUgZnJhbWUg cmVwcmVzZW50cyBhIHRpbWUgZHVyYXRpb24gDQpvZiAxNTM2IFBDTSBzYW1wbGVzIGFjcm9zcyBh bGwgY29kZWQgY2hhbm5lbHMgKDMyIG1zZWMgQCA0OGtIeiBzYW1wbGUgDQpyYXRlKSBbMl0uIEZp Z3VyZSAxIHNob3dzIHRoZSBBQy0zIGZyYW1lIGZvcm1hdC4gDQoNCg0KKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgDQp8U0kg fEJTSXwgIEFCMCAgfCAgQUIxICB8ICBBQjIgIHwgIEFCMyAgfCAgQUI0ICB8ICBBQjUgIHxBVVh8 Q1JDfA0KKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSsgDQoNCiAgICAgICAgICAgICAgICAgICAgRmlndXJlIDEuIEFDLTMgRnJh bWUgRm9ybWF0DQogDQoNClRoZSBTeW5jaHJvbml6YXRpb24gSW5mb3JtYXRpb24gZmllbGQgY29u dGFpbnMgaW5mb3JtYXRpb24gbmVlZGVkIHRvIA0KYWNxdWlyZSBhbmQgbWFpbnRhaW4gc3luY2hy b25pemF0aW9uLiAgVGhlIEJpdCBTdHJlYW0gSW5mb3JtYXRpb24gZmllbGQgDQpjb250YWlucyBw YXJhbWV0ZXJzIHRoYXQgZGVzY3JpYmUgdGhlIGNvZGVkIGF1ZGlvIHNlcnZpY2UgWzJdLiAgRWFj aCANCmF1ZGlvIGJsb2NrIGFsc28gY29udGFpbnMgZmllbGRzIHRoYXQgZGV0ZXJtaW5lIHRoZSB1 c2FnZSBvZiBibG9jayANCnN3aXRjaGluZywgZGl0aGVyLCBkeW5hbWljIHJhbmdlIGNvbnRyb2ws IGNvdXBsaW5nLCBhbmQgZXhwb25lbnQgDQpzdHJhdGVneS4gIEZpZ3VyZSAyIHNob3dzIHRoZSBm b3JtYXQgb2YgYW4gQUMtMyBhdWRpbyBibG9jay4NCiANCg0KKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgDQp8ICBCbG9jayAg fERpdGhlciB8RHluYW1pYyAgICB8Q291cGxpbmcgfENvdXBsaW5nICAgICB8RXhwb25lbnQgfA0K fCAgc3dpdGNoIHxGbGFncyAgfFJhbmdlIEN0cmwgfFN0cmF0ZWd5IHxDb29yZGluYXRlcyAgfFN0 cmF0ZWd5IHwNCistKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rIA0KfCAgICAgRXhwb25lbnRzICAgICAgIHwgQml0IEFsbG9jYXRp b24gIHwgICAgICAgIE1hbnRpc3NhcyAgICAgIHwgDQp8ICAgICAgICAgICAgICAgICAgICAgfCBQ YXJhbWV0ZXJzICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgfCANCistKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rIA0KDQog DQogICAgICAgICAgICAgICAgICBGaWd1cmUgMi4gQUMtMyBBdWRpbyBCbG9jayBGb3JtYXQNCg0K DQoyLiBSVFAgQUMtMyBQYXlsb2FkIEZvcm1hdCANCiANCkFjY29yZGluZyB0byBbNV0gUlRQIHBh eWxvYWQgZm9ybWF0cyBzaG91bGQgY29udGFpbiBhbiBpbnRlZ3JhbCBudW1iZXIgDQpvZiBhcHBs aWNhdGlvbiBkYXRhIHVuaXRzIChBRFVzKS4gSW4gdGhlIGNvbnRleHQgb2YgYXVkaW8gY29tcHJl c3Npb24gDQphbGdvcml0aG1zIGFuIEFEVSB0eXBpY2FsbHkgcmVmZXJzIHRvIGEgY29kZWMgZnJh bWUuIEluIHRoaXMgY2FzZSBhbiBBRFUNCnNoYWxsIGJlIGVxdWl2YWxlbnQgdG8gYW4gQUMtMyBz eW5jIGZyYW1lLiAgSGVuY2UgZWFjaCBSVFAgcGFja2V0IHdpbGwgDQpjb250YWluIGFuIGludGVn cmFsIG51bWJlciBvZiBBQy0zIGZyYW1lcyB1bmxlc3MgdGhlIEFDLTMgZnJhbWUgc2l6ZSANCmV4 Y2VlZHMgdGhlIG1heGltdW0gdHJhbnNmZXIgdW5pdCAoTVRVKSBvZiB0aGUgdW5kZXJseWluZyBu ZXR3b3JrLiANCg0KSWYgYSBsYXJnZSBBQy0zIGZyYW1lIHJlcXVpcmVzIGZyYWdtZW50YXRpb24g YmVmb3JlIHRyYW5zbWlzc2lvbiANCndpdGhpbiBhbiBSVFAgcGFja2V0LCBzZWN0aW9uIDIuMiBw cm92aWRlcyBndWlkZWxpbmVzIGZvciBjcmVhdGluZyANCnBhcnRpYWwgZnJhbWVzLg0KDQpUbyBj b21wZW5zYXRlIGZvciB0aGUgcG9zc2liaWxpdHkgb2YgbG9zdCBwYWNrZXRzLCBlYWNoIFJUUCBw YWNrZXQNCm1heSBjb250YWluIHJlZHVuZGFudCBhdWRpbyBpbmZvcm1hdGlvbiBpbiBhZGRpdGlv biB0bywgb3IgaW5zdGVhZCBvZiwgDQp0aGUgcHJpbWFyeSBBQy0zIGRhdGEgcGF5bG9hZC4gVGhl c2UgcmVkdW5kYW50IGRhdGEgbWF5IGV4YWN0bHkgDQpyZXBsYWNlIGxvc3QgYXVkaW8gZGF0YSBp biByZXNwb25zZSB0byBhIHJlcXVlc3QgZm9yIHJldHJhbnNtaXNzaW9uLiANCkFsdGVybmF0aXZl bHkgdGhleSBtYXkgcmVwcmVzZW50IGEgY29uc3RhbnQgZGVsYXllZCBzZWNvbmRhcnkgc3RyZWFt IA0KDQpIYWdlci9GbGFrcyAgICAgICAgICAgICAgICAgRXhwaXJlcyBKdW5lIDIwMDMgICAgICAg ICAgICAgICAgICAgW1BhZ2UgNF0NCgwNCkludGVybmV0IERyYWZ0ICAgICAgUlRQIFBheWxvYWQg Rm9ybWF0IGZvciBBQy0zIFN0cmVhbXMgICAgIEphbnVhcnkgMjAwMw0KDQoNCm9mIGxvd2VyLXF1 YWxpdHksIGxvd2VyLWJhbmR3aWR0aCBhdWRpbyB0aGF0IGEgcmVjZWl2ZXIgbWF5IHVzZSBhcyBh IA0Kc3Vic3RpdHV0ZSBmb3IgbG9zdCBwcmltYXJ5IGRhdGEuIFNlY3Rpb24gMi4zIGRlc2NyaWJl cyB0aGUgcG9zc2libGUgDQp0eXBlcyBvZiByZWR1bmRhbnQgZGF0YSBpbiBkZXRhaWwuDQoNCiAN CjIuMSBSVFAgSGVhZGVyIEV4dGVuc2lvbiANCg0KMi4xLjEgTWFpbiBIZWFkZXIgRXh0ZW5zaW9u IA0KICAgICAgICAgICAgICAgICAgICANClRoZSBmb2xsb3dpbmcgaGVhZGVyIGV4dGVuc2lvbiBz aGFsbCBiZSBhdCB0aGUgZnJvbnQgb2YgZXZlcnkgQUMtMyBSVFAgDQpwYXlsb2FkLiAgVGhlIHBy aW1hcnkgcHVycG9zZSBvZiB0aGlzIG1haW4gaGVhZGVyIGlzIHRvIGluZGljYXRlIHRoZSANCm51 bWJlciBvZiBmcmFtZXMgb3IgZnJhZ21lbnRzIHByZXNlbnQgaW4gdGhlIHBhY2tldC4gIFRoZSB0 ZXJtICJEYXRhIA0KVW5pdCIgaXMgdXNlZCB0byByZWZlcmVuY2UgQUMtMyBkYXRhIGJlIHRoZXkg YSBmdWxsIGZyYW1lIG9yIGEgDQpmcmFnbWVudC4gRmlndXJlIDMgc2hvd3MgdGhlIGZvcm1hdCBv ZiB0aGlzIGhlYWRlciBleHRlbnNpb24uDQogDQogICAgICAgICAgICAgICAgICAgICAgICAwIDEg MiAzIDQgNSA2IDcgOCANCiAgICAgICAgICAgICAgICAgICAgICAgICstKy0rLSstKy0rLSstKy0r IA0KICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgIE5EVSAgICAgIHwgIA0KICAgICAgICAg ICAgICAgICAgICAgICAgKy0rLSstKy0rLSstKy0rLSsgDQoNCiAgICAgICAgICAgICAgRmlndXJl IDMuIEFDLTMgUlRQIFBheWxvYWQgSGVhZGVyIEV4dGVuc2lvbg0KDQogDQpOdW1iZXIgb2YgZGF0 YSB1bml0cyAoTkRVKTogQW4gOC1iaXQgZmllbGQgdXNlZCB0byBpbmRpY2F0ZSB0aGUgbnVtYmVy IA0Kb2YgQUMtMyBmcmFtZXMgb3IgZnJhZ21lbnRzIHByZXNlbnQgaW4gdGhlIFJUUCBwYXlsb2Fk LiANCiANCiANCjIuMS4yIERhdGEgVW5pdCBIZWFkZXIgRXh0ZW5zaW9uIA0KIA0KVGhlIGZvbGxv d2luZyBoZWFkZXIgc2hvdWxkIGJlIGluIGZyb250IG9mIGVhY2ggYXVkaW8gZGF0YSB1bml0IChp LmUuIA0KQUMtMyBmcmFtZSBvciBmcmFnbWVudCkgcHJlc2VudCBpbiB0aGUgUlRQIHBhY2tldC4g IFRoZSBmaWVsZHMgc2hvdWxkIA0KYWlkIGluIGhhbmRsaW5nIHJlZHVuZGFudCBkYXRhIGFuZCBm cmFnbWVudGVkIEFDLTMgZnJhbWVzLiANCiAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgMCAxIDIgMyA0IDUgNiA3IDggDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgKy0rLSstKy0rLSstKy0rLSsgDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfFRZUHxGfEJ8IFJEVCB8VHwgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Ky0rLSstKy0rLSstKy0rLSsNCg0KICAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgNC4gQXVk aW8gRGF0YSBVbml0IEhlYWRlcg0KDQoNCiANClR5cGUgZmllbGQgKFRZUCk6IFRoaXMgZmllbGQg aXMgdXNlZCB0byBzcGVjaWZ5IHRoZSB0eXBlIG9mIGRhdGEgDQphc3NvY2lhdGVkIHdpdGggdGhp cyBoZWFkZXIsIHdoaWNoIGNhbiBiZSBBQy0zIGRhdGEsIEFDLTMgZGF0YSBwbHVzIA0KcmVkdW5k YW50IGRhdGEsIG9yIHJlZHVuZGFudCBkYXRhIGFsb25lLiAgVGFibGUgMSBzaG93cyB0aGUgdmFy aW91cyANCnNldHRpbmdzIGZvciBlYWNoIHR5cGUgb2YgZGF0YS4gDQoNCg0KDQoNCg0KSGFnZXIv Rmxha3MgICAgICAgICAgICAgICAgIEV4cGlyZXMgSnVuZSAyMDAzICAgICAgICAgICAgICAgICAg IFtQYWdlIDVdDQoMDQpJbnRlcm5ldCBEcmFmdCAgICAgIFJUUCBQYXlsb2FkIEZvcm1hdCBmb3Ig QUMtMyBTdHJlYW1zICAgICBKYW51YXJ5IDIwMDMNCg0KDQoNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgMDAgLSBBQy0zIGRhdGEgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDAxIC0gQUMtMyBkYXRhICsgcmVkdW5kYW50IGRhdGEgDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIDEwIC0gcmVkdW5kYW50IGRhdGEgDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDExIC0gcmVzZXJ2ZWQgDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBU YWJsZSAxLiBUWVAgZmllbGQgdmFsdWVzDQogDQpGcmFnbWVudCBiaXQgKEYpOiBUaGlzIGJpdCBp cyBzZXQgdG8gMSBpZiB0aGUgY29ycmVzcG9uZGluZyBkYXRhIHVuaXQgaXMNCmFuIEFDLTMgZnJh Z21lbnQuIFNIT1VMRCBUSElTIEJJVCBCRSBTRVQgSUYgVFlQIElTIDAxIG9yIDEwPw0KIA0KQmxv Y2sgMCBCaXQgKEIpOiBUaGlzIGJpdCBpcyBzZXQgdG8gMSBpZiB0aGUgcGFja2V0IGNvbnRhaW5z IGFuIEFDLTMgDQpmcmFnbWVudCBjb25zaXN0aW5nIG9mIHRoZSBmaXJzdCA1Lzh0aHMgb2YgdGhl IGZyYW1lLCB3aGljaCBpcyANCmd1YXJhbnRlZWQgdG8gY29udGFpbiBibG9ja3MgMCBhbmQgMS4g SWYgYW4gQUMtMyBmcmFnbWVudCBpcyByZWNlaXZlZCANCmFuZCB0aGUgQiBiaXQgaXMgbm90IHNl dCwgYW5kIHRoZSBwcmV2aW91cyBmcmFnbWVudCBpcyBsb3N0LCB0aGVuIHRoZSANCmZyYW1lIGlz IHVzZWxlc3MgYW5kIGNhbiBiZSBkaXNjYXJkZWQuICBIb3dldmVyIGlmIHRoZSBmaXJzdCBmcmFn bWVudCBpcw0KcmVjZWl2ZWQsIGFuZCB0aGUgbGF0ZXIgZnJhZ21lbnQgaXMgbG9zdCwgYmxvY2sg MSBjYW4gYmUgcmVwZWF0ZWQgdG8gDQpjb21wbGV0ZSB0aGUgZnJhbWUuDQogDQpSZWR1bmRhbnQg RGF0YSBmaWVsZCAoUkRUKTogVGhpcyAzLWJpdCBmaWVsZCBpbmRpY2F0ZXMgdGhlIHR5cGUgb2Yg DQpyZWR1bmRhbnQgZGF0YSBhc3NvY2lhdGVkIHdpdGggdGhlIGZyYW1lcy4gIFRoZSBmb2xsb3dp bmcgdGFibGUgc2hvd3MgDQp0aGUgdmFyaW91cyBzZXR0aW5ncyBmb3IgZWFjaCB0eXBlIG9mIHJl ZHVuZGFudCBkYXRhLiANCiANCiAgICAgICAgICAgIDAwMCAtIEZ1bGwgZnJhbWUvTG93ZXIgYml0 IHJhdGUgDQogICAgICAgICAgICAwMDEgLSBGdWxsIGZyYW1lL0xvd2VyIGJpdCByYXRlL0Zld2Vy IGNoYW5uZWwgDQogICAgICAgICAgICAwMTAgLSA1Lzh0aHMgZnJhZ21lbnQgDQogICAgICAgICAg ICAwMTEgLSAzLzh0aHMgZnJhZ21lbnQgDQogICAgICAgICAgICAxMDAgLSA1Lzh0aHMgZnJhZ21l bnQvTG93ZXIgYml0IHJhdGUgDQogICAgICAgICAgICAxMDEgLSAzLzh0aHMgZnJhZ21lbnQvTG93 ZXIgYml0IHJhdGUgDQogICAgICAgICAgICAxMTAgLSA1Lzh0aHMgZnJhZ21lbnQvTG93ZXIgYml0 IHJhdGUvZmV3ZXIgY2hhbm5lbHMgDQogICAgICAgICAgICAxMTEgLSAzLzh0aHMgZnJhZ21lbnQv TG93ZXIgYml0IHJhdGUvZmV3ZXIgY2hhbm5lbHMgDQoNCiAgICAgICAgICAgICAgICAgICAgICAg VGFibGUgMi4gUkRUIGZpZWxkIHZhbHVlcw0KICAgICAgICAgDQpUaW1lIENvZGUgQml0IChUKTog VGhpcyBiaXQgaXMgc2V0IHRvIDEgaWYgdGhlIEFDLTMgZGF0YSBjb250YWlucyB0aW1lIA0KY29k ZS4gDQogDQpGaWd1cmUgNSBzaG93cyBob3cgYSBmdWxsIEFDLTMgUlRQIHBheWxvYWQgZm9ybWF0 IHNob3VsZCBhcHBlYXIuIA0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpIYWdlci9GbGFrcyAg ICAgICAgICAgICAgICAgRXhwaXJlcyBKdW5lIDIwMDMgICAgICAgICAgICAgICAgICAgW1BhZ2Ug Nl0NCgwNCkludGVybmV0IERyYWZ0ICAgICAgUlRQIFBheWxvYWQgRm9ybWF0IGZvciBBQy0zIFN0 cmVhbXMgICAgIEphbnVhcnkgMjAwMw0KDQogDQowICAgICAgICAgICAgICAgICAgIDEgICAgICAg ICAgICAgDQowIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgDQorLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsg DQp8ICAgICAgIE5EVSAgICAgfFRZUHxGfEJ8IFJEVCB8VHwgIEFDLTMgRnJhbWUoMSkgICAgICAg ICAgICAgICAgICAgIHwgDQorLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgICAgICAg ICAgICAgICAgICstKy0rLSstKy0rLSstKy0rLSsNCnwgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfCBSZWR1bmRhbnQgZGF0YSAgfCANCistKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst KyANCnxUWVB8RnxCfCBSRFQgfFR8ICAgICAgICAgICAgICAgICAgQUMtMyBGcmFtZSgyKSAgICAg ICAgICAgICAgICAgICAgfCANCistKy0rLSstKy0rLSstKy0rICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKyANCnwgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCBSZWR1bmRhbnQgZGF0YSAgfCANCistKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKyANCnxUWVB8RnxCfCBSRFQgfFR8ICAgICAgICAgICAgICAgICAgQUMtMyBGcmFtZShOKSAg ICAgICAgICAgICAgICAgICAgfCANCistKy0rLSstKy0rLSstKy0rICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKyANCnwgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCBSZWR1bmRhbnQgZGF0YSAgfCANCistKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKyANCg0KICAgICAgICAgICAgICAgICAgICBGaWd1cmUgNS4gRnVsbCBBQy0zIFJUUCBw YXlsb2FkDQoNCg0KICAgDQoyLjIgRnJhZ21lbnRhdGlvbiBvZiBBQy0zIEZyYW1lcyANCiANClRo ZSBzaXplIG9mIEFDLTMgZnJhbWVzIHJlbWFpbiBjb25zdGFudCB0aHJvdWdob3V0IGFuIGVuY29k ZSBwcm9jZWR1cmUgDQpvZiBhIHBhcnRpY3VsYXIgcGllY2Ugb2YgYXVkaW8sIGJ1dCB0aGUgZnJh bWUgc2l6ZSBjYW4gdmFyeSBkZXBlbmRpbmcgDQp1cG9uIHRoZSBzYW1wbGUgcmF0ZSBvZiB0aGUg dW5jb21wcmVzc2VkIGF1ZGlvLCBhbmQgdGhlIGNvbXByZXNzaW9uIA0KcmF0ZSBhcHBsaWVkIGJ5 IHRoZSBlbmNvZGVyLiBBY2NvcmRpbmcgdG8gdGFibGUgNS4xMyBpbiBbMl0sIEFDLTMgDQpmcmFt ZSBzaXplcyByYW5nZSBmcm9tIGEgbWluaW11bSBvZiAxMjggYnl0ZXMgdG8gYSBtYXhpbXVtIG9m IDM4NDAgDQpieXRlcy4gDQogDQpBQy0zIGZyYW1lIHNpemVzIG1heSBiZSBsYXJnZSBlbm91Z2gg dG8gcmVxdWlyZSBmcmFnbWVudGF0aW9uIGJlZm9yZSANCnRyYW5zbWlzc2lvbiB3aXRoaW4gYW4g UlRQIHBhY2tldC4gRm9yIGV4YW1wbGUsIGFuIGF1ZGlvIGZpbGUgc2FtcGxlZCBhdA0KMzIga0h6 IGFuZCBjb21wcmVzc2VkIHdpdGggYSBkZXNpcmVkIGJpdCByYXRlIG9mIDY0MCBrYnBzIHdvdWxk IHByb2R1Y2UgDQpBQy0zIGZyYW1lcyBvZiAzODQwIGJ5dGVzIGVhY2guIFRoaXMgZXhjZWVkcyB0 aGUgc3RhbmRhcmQgMTUwMCBieXRlIE1UVSANCm9mIGFuIEV0aGVybmV0IG5ldHdvcmsgYW5kIHRo ZSAxNDkyIGJ5dGUgTVRVIG9mIHRoZSBQUFBvRSBwcm90b2NvbC4gIEluIA0KWzNdIGl0IGlzIHNw ZWNpZmllZCB0aGF0IGZyYWdtZW50YXRpb24gc2hvdWxkIG5vdCBiZSBsZWZ0IHRvIHRoZSBJUCAN CmxheWVyLCBidXQgaW5zdGVhZCBzaG91bGQgYmUgaGFuZGxlZCBieSB0aGUgYXBwbGljYXRpb24g aXRzZWxmLiANCiANCkFDLTMgZnJhbWVzIHdlcmUgZGVzaWduZWQgdG8gYWNjb21tb2RhdGUgbWVt b3J5IGJ1ZmZlcnMgc21hbGxlciB0aGFuIGFuIA0KZW50aXJlIEFDLTMgZnJhbWUuICBGb3IgdGhp cyByZWFzb24sIGVhY2ggQUMtMyBmcmFtZSBjb250YWlucyB0d28gMTYtYml0DQpDUkMgd29yZHMu ICBDUkMxIGlzIGNvbnRhaW5lZCBpbiB0aGUgc3luY2hyb25pemF0aW9uIGluZm9ybWF0aW9uIChT SSkgDQpoZWFkZXIgbG9jYXRlZCBhdCB0aGUgYmVnaW5uaW5nIG9mIGVhY2ggQUMtMyBmcmFtZS4g Q1JDMSBpcyB0aGUgc2Vjb25kIA0KMTYtYml0IHdvcmQgb2YgdGhlIGZyYW1lLiAgRmlndXJlIDYg c2hvd3MgdGhlIHN0cnVjdHVyZSBvZiB0aGUgU0kgDQpoZWFkZXIuIA0KDQoNCg0KDQoNCg0KDQoN CkhhZ2VyL0ZsYWtzICAgICAgICAgICAgICAgICBFeHBpcmVzIEp1bmUgMjAwMyAgICAgICAgICAg ICAgICAgICBbUGFnZSA3XQ0KDA0KSW50ZXJuZXQgRHJhZnQgICAgICBSVFAgUGF5bG9hZCBGb3Jt YXQgZm9yIEFDLTMgU3RyZWFtcyAgICAgSmFudWFyeSAyMDAzDQoNCiANCjAgICAgICAgICAgICAg ICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMgDQowIDEgMiAz IDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEg DQorLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSsgDQp8ICAgICAgICAgIFNZTkMgV09SRCAgICAgICAgICAgIHwgICAgICAgICAgICAg Q1JDMSAgICAgICAgICAgIHwgDQorLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgDQp8RlNDfEZSTVNJWkVDRCAgfCANCistKy0rLSst Ky0rLSstKy0rIA0KDQogICAgICAgICAgICBGaWd1cmUgNi4gU3luY2hyb25pemF0aW9uIEluZm9y bWF0aW9uIGhlYWRlcg0KDQoNCiANCkNSQzIgaXMgdGhlIGxhc3QgMTYtYml0IHdvcmQgb2YgYW4g QUMtMyBmcmFtZSBhcyBzaG93biBpbiBGaWd1cmUgMS4gIA0KQ1JDMSBhcHBsaWVzIHRvIHRoZSBm aXJzdCA1Lzh0aHMgb2YgdGhlIGZyYW1lIGV4Y2x1ZGluZyB0aGUgc3luYyB3b3JkLiANCkNSQzIg Y292ZXJzIHRoZSByZW1haW5pbmcgMy84dGhzIG9mIHRoZSBmcmFtZSBhcyB3ZWxsIGFzIHRoZSBl bnRpcmUgDQpmcmFtZSAoZXhjbHVkaW5nIHRoZSBzeW5jIHdvcmQpLiANCiANCkFsbCBBQy0zIGVu Y29kZXJzIGVuZm9yY2Ugc3BlY2lmaWMgYmxvY2sgc2l6ZSByZXN0cmljdGlvbnMgdGhhdCANCmd1 YXJhbnRlZSBibG9ja3MgMCBhbmQgMSBhcmUgY29tcGxldGVseSBjb3ZlcmVkIGJ5IENSQzEgWzJd LiBFbnN1cmluZyANCnRoYXQgYmxvY2tzIDAgYW5kIDEgYXJlIGluIHRoZSBmaXJzdCA1Lzh0aHMg b2YgdGhlIGZyYW1lIGlzIG5lY2Vzc2FyeSANCmJlY2F1c2UgYmxvY2sgMCBjb250YWlucyBpbmZv cm1hdGlvbiB0aGF0IGlzIHNoYXJlZCB3aXRoIHRoZSByZW1haW5pbmcgNSANCmJsb2Nrcy4gIFRo ZSBkdWFsIENSQyBhbGxvd3MgZGVjb2RlcnMgdG8gaW1tZWRpYXRlbHkgYmVnaW4gcHJvY2Vzc2lu ZyANCmJsb2NrIDAgd2hlbiB0aGUgNS84dGhzIHBvaW50IGlzIHJlYWNoZWQuIA0KICAgICAgICAg ICANClRoaXMgNS84dGhzIHNwbGl0IGluIGFsbCBBQy0zIGZyYW1lcywgd2hpY2ggd2FzIGludGVu ZGVkIGZvciB0aGUgDQpwb3NzaWJpbGl0eSBvZiBzbWFsbGVyIGlucHV0IGJ1ZmZlcnMgKGFzc3Vt aW5nIGEgZ3VhcmFudGVlZCB0cmFuc3BvcnQgDQpzdHJlYW0gc3VjaCBhcyBTL1BESUYpLCBwcm92 aWRlcyBhIHZlcnkgbG9naWNhbCBmcmFnbWVudGF0aW9uIHVuaXQuIA0KVXNpbmcgdGhlIDUvOHRo cyBwb2ludCBwcm92aWRlcyB0d28gcG9zc2libGUgZ2FpbnMgb3ZlciBhcmJpdHJhcnkgDQpmcmFn bWVudGF0aW9uOiANCiANCiAgICAgICAgMSkgVXNpbmcgNS84dGhzIGZyYWdtZW50YXRpb24sIGlm IHRoZSBzZWNvbmQgZnJhZ21lbnQgaXMgDQogICAgICAgICAgIGRyb3BwZWQsIHRoZSBmaXJzdCBm cmFnbWVudCBjYW4gc3RpbGwgYmUgZGVjb2RlZCBieSBhbiBBQy0zIA0KICAgICAgICAgICBkZWNv ZGVyLiAgQmxvY2sgMSB3aWxsIGJlIHJlcGVhdGVkIGluIHBsYWNlIG9mIGFueSBtaXNzaW5nIA0K ICAgICAgICAgICBibG9ja3MgbG9zdCBpbiB0aGUgc2Vjb25kIGZyYWdtZW50LiANCg0KICAgICAg ICAyKSBJbiBjbG9zZWQgbmV0d29ya3Mgd2l0aCBubyBRb1MgcHJvYmxlbXMsIGl0IG1heSBiZSBw b3NzaWJsZSANCiAgICAgICAgICAgdG8gdXNlIHNtYWxsZXIgYnVmZmVycywgYXMgd2FzIGludGVu ZGVkIGluIHRoZSBvcmlnaW5hbCANCiAgICAgICAgICAgZGVzaWduIG9mIHRoZSA1Lzh0aHMgc3Bs aXQuIA0KICAgICAgICAgICAgICAgICANCkluIFsyXSB0aGUgNS84dGhzIHBvaW50IGlzIGRlZmlu ZWQgYXM6IA0KIA0KICAgICAgICA1LzgtZnJhbWVzaXplID0gdHJ1bmNhdGUoZnJhbWVzaXplLzIp ICsgdHJ1bmNhdGUoZnJhbWVzaXplLzgpIA0KIA0KQWNjb3JkaW5nIHRvIHRhYmxlIDcuMzQgaW4g WzJdLCA1Lzh0aHMgZnJhbWUgc2l6ZXMgY2FuIHJhbmdlIGZyb20gODAgDQpieXRlcyB0byAyNDAw IGJ5dGVzLiAgSGVuY2UgdGhlcmUgYXJlIHN0aWxsIGluc3RhbmNlcyB3aGVyZSB0aGUgNS84dGhz IA0KYm91bmRhcnkgbWF5IGV4Y2VlZCB0aGUgTVRVIG9mIHRoZSB1bmRlcmx5aW5nIG5ldHdvcmsu ICBJbiBhbiBFdGhlcm5ldCANCm5ldHdvcmsgdGhpcyB3b3VsZCBiZSByYXJlIGJlY2F1c2UgdGhl IG1ham9yaXR5IG9mIEFDLTMgZGF0YSBwdWJsaWNseSANCmF2YWlsYWJsZSBpcyBzYW1wbGVkIGF0 IDQ4a0h6IGFuZCBpcyBlbmNvZGVkIGF0IGEgZGF0YSByYXRlIG9mIDM4NGticHMgDQpvciA0NDhr YnBzLiAgVGhpcyBwcm92aWRlcyBhIDUvOHRoc3BvaW50IG9mIDk2MCBieXRlcyBhbmQgMTEyMCBi eXRlcyANCnJlc3BlY3RpdmVseSwgd2hpY2ggd291bGQgYmUgbGVzcyB0aGVuIHRoZSBNVFUgb2Yg YSB0eXBpY2FsIEV0aGVybmV0IA0KDQpIYWdlci9GbGFrcyAgICAgICAgICAgICAgICAgRXhwaXJl cyBKdW5lIDIwMDMgICAgICAgICAgICAgICAgICAgW1BhZ2UgOF0NCgwNCkludGVybmV0IERyYWZ0 ICAgICAgUlRQIFBheWxvYWQgRm9ybWF0IGZvciBBQy0zIFN0cmVhbXMgICAgIEphbnVhcnkgMjAw Mw0KDQoNCm5ldHdvcmsuICBJbiB0aGUgcmFyZSBpbnN0YW5jZXMgd2hlcmUgZXZlbiB0aGUgNS84 dGhzIHBvaW50IGV4Y2VlZHMgdGhlIA0KTVRVLCBBQy0zIGZyYW1lcyBzaG91bGQgYmUgYXJiaXRy YXJpbHkgZnJhZ21lbnRlZCB0byBhIGxlbmd0aCB0aGF0IGlzIA0KbGVzcyB0aGUgTVRVLiANCiAN Ckl0IHNob3VsZCBiZSBub3RlZCB0aGF0IHVzaW5nIDUvOHRocyBmcmFnbWVudGF0aW9uIGluIHRl cm1zIG9mIHNtYWxsZXIgDQpidWZmZXIgc2l6ZXMgaXMgb25seSB1c2VmdWwgaW4gbmV0d29ya3Mg d2hlcmUgdGhlIGludGVyLWFycml2YWwgaml0dGVyIA0KaXMgbGVzcyB0aGFuIHRoZSB0aW1lIG5l ZWRlZCB0byBkZWNvZGUgQmxvY2tzIDAgYW5kIDEgb2YgdGhlIEFDLTMgc3RyZWFtIA0KYW5kIHBs YXkgdGhlIHVuY29tcHJlc3NlZCBhdWRpby4gDQogDQogICAgICAgIEppdHRlckxpbWl0ID0gRGVj b2RlVGltZShCbG9jayAwICYgMSkgKyAyICogKDI1Ni9GcyksIA0KICAgICAgICB3aGVyZSBGcyBp cyB0aGUgc2FtcGxlIHJhdGUgb2YgdGhlIHVuY29tcHJlc3NlZCBhdWRpbyANCiANCiANCjIuMyBE YXRhIFJlc2lsaWVuY3kgDQogDQpUaGlzIHNlY3Rpb24gcHJvdmlkZXMgaW5mb3JtYXRpb24gb24g aG93IHRvIGVuY2Fwc3VsYXRlIHJlZHVuZGFudCBkYXRhIA0KaW50byBhbiBSVFAgcGF5bG9hZCB0 byBlbnN1cmUgdGhlIHJlY2VwdGlvbiBvZiBhbGwgdGhlIEFDLTMgZGF0YSBiZWluZyANCnNlbnQu ICBUaGVyZSBhcmUgc2V2ZXJhbCB0eXBlcyBvZiByZWR1bmRhbnQgZGF0YSB0aGF0IGNhbiBiZSBz ZW50LCB3aGljaA0KYXJlIGRlZmluZWQgaW4gc2VjdGlvbiAyLjEuMiBhbmQgc3BlY2lmaWVkIGZv ciBlYWNoIGRhdGEgdW5pdCBpbiB0aGUgDQpkYXRhIHVuaXQgaGVhZGVyLiAgVGhlIHZhcmlvdXMg dHlwZXMgb2YgcmVkdW5kYW50IGRhdGEgYXJlIGZ1cnRoZXIgDQpkaXNjdXNzZWQgaW4gdGhlIGZv bGxvd2luZyBzZWN0aW9ucy4gDQogDQpBcyBhIGdlbmVyYWwgcnVsZSByZWR1bmRhbnQgZGF0YSBv ZiBhbnkgdHlwZSBzaG91bGQgbmV2ZXIgcmVwZWF0IHByaW1hcnkgDQphdWRpbyBpbmZvcm1hdGlv biBmcm9tIHRoZSBzYW1lIFJUUCBwYXlsb2FkLiANCiANCg0KMi4zLjEgTG93ZXIgQml0IFJhdGUg RGF0YSAgDQogDQpUcmFuc21pdHRpbmcgcmVkdW5kYW50IEFDLTMgZnJhbWVzIGVuY29kZWQgYXQg YSBsb3dlciBkYXRhIHJhdGUgKGFuZCANCnRodXMgcXVhbGl0eSkgdGhhbiB0aGUgcHJpbWFyeSBB Qy0zIGF1ZGlvIGlzIGFuIG9idmlvdXMgbWVhbnMgb2YgDQplbmhhbmNpbmcgZGF0YSByZXNpbGll bmN5LiBUaGlzIGFwcHJvYWNoIGFsbG93cyB0aGUgQUMtMyBkZWNvZGVyIHRvIA0KZGVjb2RlIHRo ZSBsb3dlciBxdWFsaXR5IGZyYW1lIGlmIHRoZSBwYWNrZXQgY29udGFpbmluZyB0aGUgaGlnaC1x dWFsaXR5DQphdWRpbyBpcyBkcm9wcGVkLCBsb3N0LCBvciBhcnJpdmVzIHdpdGggZXJyb3JzLiBI b3dldmVyLCB0aGUgbG93ZXIgDQpxdWFsaXR5IGRhdGEgbWF5IHN0aWxsIHJlcXVpcmUgYW4gdW5k ZXNpcmFibHkgbGFyZ2UgYW1vdW50IG9mIGJhbmR3aWR0aC4NCkFsc28sIHRoZSByZWR1bmRhbnQg ZGF0YSBjYW4gYmUgZXh0cmVtZWx5IGxvdyBxdWFsaXR5LCBlc3BlY2lhbGx5IGluIA0KY2FzZXMg d2hlcmUgbGFyZ2UgbnVtYmVycyBvZiBjaGFubmVscyBhcmUgYmVpbmcgdHJhbnNtaXR0ZWQuIFJl dGFpbmluZyANCnRoZSBvcmlnaW5hbCBudW1iZXIgb2YgY2hhbm5lbHMgYXQgYSBsb3cgZGF0YSBy YXRlIG1heSByZXN1bHQgaW4gc291bmQgDQpxdWFsaXR5IHRoYXQgaXMgc3ViamVjdGl2ZWx5IHVu cGxlYXNhbnQgdG8gbGlzdGVuIHRvLiBSYXRoZXIgdGhhbiBzaW1wbHkNCmxvd2VyIHRoZSBxdWFs aXR5IG9mIGFsbCBjaGFubmVscyB0byBhY2hpZXZlIHJlc3VjZWQgYmFuZHdpZHRoLCBhIG1vcmUg DQpkZXNpcmFibGUgYXBwcm9hY2ggbWF5IGJlIHRvIG1peCB0aGUgbXVsdGlwbGUgY2hhbm5lbHMg ZG93biBpbnRvIHN0ZXJlbyANCmFuZCBlbmNvZGUgdGhlIHJlc3VsdGluZyB0d28tY2hhbm5lbCBh dWRpbyBpbnRvIGxvd2VyIGJpdC1yYXRlLCBidXQgDQpzdWJqZWN0aXZlbHkgbW9yZSBsaXN0ZW5h YmxlLCBBQy0zIGRhdGEuDQogDQoyLjMuMiBMb3dlciBCaXQgUmF0ZSBEYXRhIHdpdGggRmV3ZXIg Q2hhbm5lbHMgDQoNCldoZW4gZW5jb2RpbmcgbXVsdGljaGFubmVsIGF1ZGlvLCBhIHNlY29uZGFy eSB0d28tY2hhbm5lbCB2ZXJzaW9uIG9mIHRoZQ0KYXVkaW8gY2FuIGFsc28gYmUgZW5jb2RlZCBh dCBhIGxvd2VyIGJpdCByYXRlLiAgU2luY2UgdGhlIGF1ZGlvIGlzIA0KcmVkdWNlZCB0byB0d28g Y2hhbm5lbHMsIGl0IGlzIHN0aWxsIHBvc3NpYmxlIHRvIG1haW50YWluIGhpZ2ggcXVhbGl0eSAN CmV2ZW4gYXQgYSBsb3dlciBiaXQgcmF0ZS4gIFRoZSBsb3dlciBiaXQtcmF0ZSB0d28tY2hhbm5l bCB2ZXJzaW9uIGNhbiBiZQ0KaW50ZXJsZWF2ZWQgd2l0aCB0aGUgbXVsdGljaGFubmVsIGF1ZGlv LCBhbmQgd2hlbiBhIHBhY2tldCBpcyBsb3N0IG9yIA0KDQpIYWdlci9GbGFrcyAgICAgICAgICAg ICAgICAgRXhwaXJlcyBKdW5lIDIwMDMgICAgICAgICAgICAgICAgICAgW1BhZ2UgOV0NCgwNCklu dGVybmV0IERyYWZ0ICAgICAgUlRQIFBheWxvYWQgRm9ybWF0IGZvciBBQy0zIFN0cmVhbXMgICAg IEphbnVhcnkgMjAwMw0KDQoNCmNvcnJ1cHRlZCB0aGUgdHdvLWNoYW5uZWwgdmVyc2lvbiBjYW4g YmUgdXNlZCBpbiBpdHMgcGxhY2UuDQoNCg0KMi4zLjMgNS84dGhzIGFuZCAzLzh0aHMgRnJhZ21l bnQgDQogDQpBbm90aGVyIG1ldGhvZCBvZiBzZW5kaW5nIHJlZHVuZGFudCBkYXRhIG1pZ2h0IGlu Y2x1ZGUgZnJhZ21lbnRhdGlvbiBvZiANCnBhY2tldHMgYXQgdGhlIDUvOHRocyBzcGxpdCBhbmQg aW50ZXJsZWF2aW5nIGZyYWdtZW50cyBmcm9tIHByZXZpb3VzIA0KZnJhbWVzLiAgVGhpcyBlbnN1 cmVzIHRoYXQgYWxsIGRhdGEgaXMgc2VudCB0d2ljZSwgd2hpY2ggZGVjcmVhc2VzIHRoZSANCmxp a2VsaWhvb2Qgb2YgbG9zdCBkYXRhLiANCiANCiAgICAgICAgICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgDQpSVFAoWCk6ICB8ICAg IEFDLTMgNS84dGhzIEZyYWdtZW50KG4pfCAgICAgQUMtMyAzLzh0aHMgRnJhZ21lbnQobi0xKSB8 IA0KICAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKyANCiANCiAgICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgDQpSVFAoWCsxKSB8ICAgIEFDLTMg My84dGhzIEZyYWdtZW50KG4pfCAgICAgQUMtMyA1Lzh0aHMgRnJhZ21lbnQobikgICB8IA0KICAg ICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKyANCiANCg0KICAgICAgICAgICAgICAgICBGaWd1cmUgNy4gNS84dGhzIJYgMy84 dGhzIEludGVybGVhdmluZw0KDQoNCiANCkluIGFkZGl0aW9uIGl0IGlzIHBvc3NpYmxlIHRoYXQg b25lIG1heSB3aXNoIHRvIG9ubHkgc2VuZCB0aGUgNS84dGhzIA0KZnJhZ21lbnQgYXMgcmVkdW5k YW50IGRhdGEuICBTaW5jZSB0aGUgNS84dGhzIGZyYWdtZW50IGNhbiBiZSBkZWNvZGVkIG9uDQpp dHMgb3duLCBpdCB3b3VsZCBhbGxvdyBmb3IgcmVkdW5kYW50IGRhdGEgYXQgYSBsb3dlciBvdmVy YWxsIGJpdCByYXRlLiANCkhvd2V2ZXIgYmVjYXVzZSBibG9jayByZXBlYXRzIGFyZSB1c2VkIHdo ZW4gb25seSB0aGUgZmlyc3QgNS84dGhzIGlzIA0KcHJlc2VudCwgdGhlIHF1YWxpdHkgd291bGQg YmUgc2lnbmlmaWNhbnRseSByZWR1Y2VkIGlmIHRoZSByZWR1bmRhbnQgDQpkYXRhIHdhcyB0byBi ZSB1c2VkLiANCiANCiAgICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgDQpSVFAoWCk6ICB8ICAgIEFDLTMgRnJhbWUobikg ICAgICAgICAgfCAgICAgQUMtMyA1Lzh0aHMgRnJhZ21lbnQobi0xKSB8IA0KICAgICAgICAgKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst KyANCg0KICAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKyANClJUUChYKzEpIHwgICAgQUMtMyBGcmFtZShuKzEpICAgICAg ICB8ICAgICBBQy0zIDUvOHRocyBGcmFnbWVudChuKSAgIHwgDQogICAgICAgICArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rIA0KDQog ICAgICAgICAgICAgICAgICAgICBGaWd1cmUgOC4gUmVkdW5kYW50IDUvOHRocyBEYXRhDQoNCg0K IA0KMi4zLjQgNS84dGhzIEZyYWdtZW50IExvd2VyIEJpdCBSYXRlIA0KIA0KRm9sbG93aW5nIHRo ZSBtZXRob2RzIGxpc3RlZCBpbiB0aGUgcHJldmlvdXMgc2VjdGlvbiwgaXQgbWF5IGFsc28gYmUg DQpiZW5lZmljaWFsIHRvIHNlbmQgdGhlIHJlZHVuZGFudCBmcmFnbWVudHMgYXQgYSBsb3dlciBi aXQgcmF0ZS4gSWRlYWxseSANCmEgbG93ZXIgYml0IHJhdGUgdmVyc2lvbiBvZiB0aGUgcHJldmlv dXMgZnJhbWVzIDUvOHRocyBmcmFnbWVudCBjb3VsZCBiZQ0Kc2VudCBhbG9uZywgd2hpY2ggd291 bGQgcHJvdmlkZSBmb3IgYSB2ZXJ5IGxvdyBiaXQgcmF0ZSByZWR1bmRhbnQgZGF0YSANCmNoYW5u ZWwuIA0KIA0KDQpIYWdlci9GbGFrcyAgICAgICAgICAgICAgICAgRXhwaXJlcyBKdW5lIDIwMDMg ICAgICAgICAgICAgICAgICAgW1BhZ2UgMTBdDQoMDQpJbnRlcm5ldCBEcmFmdCAgICAgIFJUUCBQ YXlsb2FkIEZvcm1hdCBmb3IgQUMtMyBTdHJlYW1zICAgICBKYW51YXJ5IDIwMDMNCg0KDQoyLjMu NSA1Lzh0aHMgYW5kIDMvOHRocyBGcmFnbWVudCBMb3dlciBCaXQgUmF0ZSBhbmQgRmV3ZXIgQ2hh bm5lbHMgDQogDQpDb21iaW5pbmcgdGhlIG1ldGhvZHMgZnJvbSAyLjMuMiBhbmQgMi4zLjMgYSB2 ZXJzaW9uIG9mIHRoZSA1Lzh0aHMgDQpmcmFnbWVudCB0aGF0IGlzIGxvd2VyIGluIGJpdCByYXRl IGFuZCBpcyBjb21wb3NlZCBvZiBmZXdlciBjaGFubmVscyBtYXkNCmJlIHNlbnQgYXMgcmVkdW5k YW50IGRhdGEuICBUaGlzIHByb3ZpZGVzIGFuZCBvcHBvcnR1bml0eSBmb3IgbG93IGJpdCANCnJh dGUgcmVkdW5kYW50IGRhdGEgdGhhdCBoYXMgZmV3ZXIgY2hhbm5lbHMgYnV0IGxlc3MgcXVhbGl0 eSANCmRlZ3JhZGF0aW9uLiANCiANCiANCjMgUlRQIGhlYWRlciBmaWVsZHMgDQogDQpQYXlsb2Fk IFR5cGUgKFBUKTogSXQgaXMgZXhwZWN0ZWQgdGhhdCB0aGUgUlRQIHByb2ZpbGUgZm9yIGEgcGFy dGljdWxhciANCmNsYXNzIG9mIGFwcGxpY2F0aW9ucyB3aWxsIGFzc2lnbiBhIHBheWxvYWQgdHlw ZSBmb3IgdGhpcyBlbmNvZGluZywgb3IgDQphbHRlcm5hdGl2ZWx5IGEgcGF5bG9hZCB0eXBlIGlu IHRoZSBkeW5hbWljIHJhbmdlIFs5NiwxMjddIHNoYWxsIGJlIA0KY2hvc2VuLiANCiANCk1hcmtl ciAoTSkgYml0OiAgVGhlIE0gYml0IGlzIHNldCBmb3IgbGFzdCBmcmFnbWVudCBvZiBhbiBBQy0z IGZyYW1lLiANCg0KSW4gaW5zdGFuY2VzIHdoZXJlIG9uZSBvciBtb3JlIGZ1bGwgQUMtMyBmcmFt ZXMgaXMgZW5jYXBzdWxhdGVkIGluIGFuIA0KUlRQIHBhY2tldCB0aGUgTSBiaXQgd2lsbCBiZSBz ZXQgYW5kIHRoZSBmdWxsIGZyYW1lIGl0c2VsZiB3aWxsIGJlIA0KY29uc2lkZXJlZCB0aGUgbGFz dCBmcmFnbWVudC4gDQogDQpFeHRlbnNpb24gKFgpIGJpdDogRGVmaW5lZCBieSB0aGUgUlRQIHBy b2ZpbGUgdXNlZC4gDQoNClRpbWVzdGFtcDogQSAzMi1iaXQgd29yZCB0aGF0IGNvcnJlc3BvbmRz IHRvIHRoZSBzYW1wbGluZyBpbnN0YW50IGZvciANCnRoZSBmaXJzdCBBQy0zIGZyYW1lIGluIGFu IFJUUCBwYWNrZXQuICBBQy0zIGVuY29kZXMgZGF0YSBzYW1wbGVkIGF0IDMyIA0Ka0h6LCA0NC4x IGtIeiwgYW5kIDQ4IGtIei4gIEZyYWdtZW50ZWQgZnJhbWVzIHNoYWxsIG1haW50YWluIHRoZSBz YW1lIA0KdGltZSBzdGFtcCB1bnRpbCB0aGUgbGFzdCBmcmFnbWVudCBpcyBzZW50LiAgVGhlIHN0 YXJ0aW5nIHRpbWVzdGFtcCBpcyANCnNlbGVjdGVkIGF0IHJhbmRvbS4gDQoNCg0KNCBUeXBlcyBh bmQgTmFtZXMgDQoNCjQuMSBNSU1FIHR5cGUgcmVnaXN0cmF0aW9uIA0KDQpNSU1FIG1lZGlhIHR5 cGUgbmFtZTogICAgICAgICAgICAgICAgICAgYXVkaW8NCg0KTUlNRSBzdWJ0eXBlIG5hbWU6ICAg ICAgICAgICAgICAgICAgICAgIGFjMw0KDQpSZXF1aXJlZCBwYXJhbWV0ZXJzOiANCiAgICAgICAg UmF0ZTogRXF1YWwgdG8gdGhlIFJUUCB0aW1lc3RhbXAgY2xvY2sgcmF0ZSBmb3IgdGhlIHBhcnRp Y3VsYXIgDQogICAgICAgIEFDLTMgc3RyZWFtIG9mIGEgZ2l2ZW4gUlRQIHNlc3Npb24uICBJbiB0 aGUgY2FzZSBvbiBhIHNpbmdsZSANCiAgICAgICAgZnJhbWUgcGVyIGEgcGFja2V0LCBhbmQgdGhl IEFDLTMgc3RyZWFtIHdhcyBlbmNvZGVkIGF0IDQ4S2h6IGF0IA0KICAgICAgICBhIGJpdCByYXRl IG9mIDM4NCBrYnBzIHRoZSByYXRlIHBhcmFtZXRlciB3b3VsZCBlcXVhbCAzMiANCiAgICAgICAg bWlsbGlzZWNvbmRzLg0KDQogICAgICAgIEluIHRoZSBjYXNlIG9mIGludGVybGVhdmluZyB0aGUg NS84dGhzIGFuZCAzLzh0aHMgZnJhZ21lbnRzIA0KICAgICAgICBhc3N1bWluZyB0aGUgQUMtMyBm aWxlIHdhcyBlbmNvZGVkIGFnYWluIGF0IDQ4S2h6IHdpdGggYSBiaXQgDQogICAgICAgIHJhdGUg b2YgMzg0IGticHMgdGhlIGNsb2NrIHJhdGUgd291bGQgbmVlZCB0byBiZSBvbmUgaGFsZiBvZiAz MiANCiAgICAgICAgbWlsbGlzZWNvbmRzIG9yIDE2IG1pbGxpc2Vjb25kcy4gIA0KIA0KSGFnZXIv Rmxha3MgICAgICAgICAgICAgICAgIEV4cGlyZXMgSnVuZSAyMDAzICAgICAgICAgICAgICAgICAg IFtQYWdlIDExXQ0KDA0KSW50ZXJuZXQgRHJhZnQgICAgICBSVFAgUGF5bG9hZCBGb3JtYXQgZm9y IEFDLTMgU3RyZWFtcyAgICAgSmFudWFyeSAyMDAzDQoNCg0KT3B0aW9uYWwgcGFyYW1ldGVyczog ICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgQ2hhbm5lbHM6IEhvdyBtYW55IGNoYW5uZWxz IGFyZSBwcmVzZW50IGluIHRoZSBBQzMgc3RyZWFtLg0KICAgICAgICBUaGlzIHdpbGwgYmUgYSBu dW1iZXIgYmV0d2VlbiAxIGFuZCA2LiANCg0KICAgICAgICBQdGltZTogVGhlIGxlbmd0aCBvZiB0 aW1lIGluIG1pbGxpc2Vjb25kcyByZXByZXNlbnRlZCBieSB0aGUgDQogICAgICAgIEFDLTMgZnJh bWUocykgaW4gdGhlIHBhY2tldC4NCiAgICAgICAgIA0KICAgICAgICBNYXhwdGltZTogVGhlIG1h eGltdW0gYW1vdW50IG9mIG1lZGlhIHdoaWNoIGNhbiBiZSBlbmNhcHN1bGF0ZWQgDQogICAgICAg IGluIGVhY2ggUlRQIHBhY2tldCwgZXhwcmVzc2VkIGFzIHRpbWUgaW4gbWlsbGlzZWNvbmRzIA0K IA0KRW5jb2RpbmcgY29uc2lkZXJhdGlvbnM6ICAgICAgICAgICAgICAgICANClRoZSBBQy0zIGJp dHN0cmVhbSBzaGFsbCBiZSBnZW5lcmF0ZWQgYWNjb3JkaW5nIHRvIHRoZSBBQy0zIA0Kc3BlY2lm aWNhdGlvbiBbMl0uICBUaGlzIGJpdHN0cmVhbSBpcyBiaW5hcnkgZGF0YSBhbmQgTVVTVCBiZSBl bmNvZGVkIA0KZm9yIG5vbi1iaW5hcnkgdHJhbnNwb3J0IChmb3IgRW1haWwgb3IgYW55IHRyYW5z cG9ydCB0aGF0IGNhbm5vdCANCmFjY29tbW9kYXRlIGJpbmFyeSBkaXJlY3RseSwgdGhlIEJhc2U2 NCBlbmNvZGluZyBpcyBzdWZmaWNpZW50KS4gVGhpcyANCnR5cGUgaXMgYWxzbyBkZWZpbmVkIGZv ciB0cmFuc2ZlciB2aWEgUlRQLiAgQWxsIFJUUCBwYWNrZXRzIE1VU1QgYmUgDQpwYWNrZXRpemVk IHVzaW5nIHRoZSBSVFAgcGF5bG9hZCBmb3JtYXQgZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQu IA0KIA0KU2VjdXJpdHkgY29uc2lkZXJhdGlvbnM6ICAgICAgICAgICAgICAgICAgICAgICAgc2Vl IHNlY3Rpb24gNSBvZiB0aGlzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBkb2N1bWVudCANCiANCkludGVyb3BlcmFiaWxpdHkgY29uc2lkZXJhdGlvbnM6 ICAgICAgICAgICAgICAgIG5vbmUgDQogDQpQdWJsaXNoZWQgc3BlY2lmaWNhdGlvbjogICAgICAg ICAgICAgICAgICAgICAgICBzZWUgWzJdDQogDQpBcHBsaWNhdGlvbnM6ICAgICAgICAgICAgICAg ICAgICAgICAgICAgIA0KTXVsdGljaGFubmVsIGF1ZGlvIGNvbXByZXNzaW9uIGZvciBhdWRpbyBh bmQgYXVkaW8gZm9yIHZpZGVvIA0KIA0KQWRkaXRpb25hbCBJbmZvcm1hdGlvbjogICAgICAgICAg ICAgICAgIG5vbmUgDQogDQpNYWdpYyBudW1iZXIocyk6ICAgICAgICAgICAgICAgICAgICAgICAg bm9uZSANCkZpbGUgZXh0ZW5zaW9uKHMpOiAgICAgICAgICAgICAgICAgICAgICAuYWMzIA0KTWFj aW50b3NoIEZpbGUgVHlwZSBDb2RlKHMpOiAgICAgICAgICAgIG5vbmUgDQpPYmplY3QgSWRlbnRp ZmllcihzKSBvciBPSUQocyk6ICAgICAgICAgbm9uZSANCiANClBlcnNvbiAmIGVtYWlsIGFkZHJl c3MgdG8gY29udGFjdCBmb3IgZnVydGhlciBpbmZvcm1hdGlvbjoNCiAgIFRvZGQgSGFnZXIgPHRo aEBkb2xieS5jb20+DQogICBJRVRGIEFWVCB3b3JraW5nIGdyb3VwLg0KIA0KSW50ZW5kZWQgVXNh Z2U6ICAgICAgICAgICAgICAgICAgICAgICAgIENPTU1PTiANCiANCkF1dGhvci9DaGFuZ2UgY29u dHJvbGxlcjogICAgICAgICAgICBBdXRob3I6IFRvZGQgSGFnZXIgPHRoaEBkb2xieS5jb20+DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBKYXNvbiBGbGFrcyAN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBDaGFuZ2UgQ29udHJvbGxlcjog SUVURiBBVlQgV0cNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQog DQoNCg0KDQoNCg0KSGFnZXIvRmxha3MgICAgICAgICAgICAgICAgIEV4cGlyZXMgSnVuZSAyMDAz ICAgICAgICAgICAgICAgICAgIFtQYWdlIDEyXQ0KDA0KSW50ZXJuZXQgRHJhZnQgICAgICBSVFAg UGF5bG9hZCBGb3JtYXQgZm9yIEFDLTMgU3RyZWFtcyAgICAgSmFudWFyeSAyMDAzDQoNCiANCjQu MiBTRFAgdXNhZ2UgDQogDQpUaGUgZW5jb2RpbmcgbmFtZSB3aGVuIHVzaW5nIFNEUCBbM10gU0hB TEwgYmUgImFjMyIgKE1JTUUgc3VidHlwZSkuIEFuIA0KZXhhbXBsZSBvZiB0aGUgbWVkaWEgcmVw cmVzZW50YXRpb24gaW4gU0RQIGlzIGdpdmVuIGJlbG93LiANCiANCm0gPSBhdWRpbyA0OTAwMCBS VFAvQVZQIDEwMCANCmEgPSBydHBtYXA6MTAwIGFjMy80ODAwMA0KYSA9IGZtdHA6MTAwIG51bWJl ci1jaGFubmVscz1bMS02XSANCiANCg0KNS4gU2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgDQogDQpJ biBvcmRlciB0byBwcm90ZWN0IGNvcHlyaWdodGVkIG1hdGVyaWFsLCBjZXJ0YWluIHNlY3VyaXR5 IHByZWNhdXRpb25zIA0KbWF5IGJlIG5lY2Vzc2FyeS4gIFRoZSBwYXlsb2FkIGZvcm1hdCBkZXNj cmliZWQgaW4gdGhpcyBkb2N1bWVudCBpcyANCnN1YmplY3QgdG8gdGhlIHNlY3VyaXR5IGNvbnNp ZGVyYXRpb25zIGRlZmluZWQgaW4gWzRdLiBUaGUgc2VjdXJpdHkgDQpjb25zaWRlcmF0aW9ucyBk aXNjdXNzZWQgaW4gWzRdIGltcGx5IHRoZSB1c2FnZSBvZiBlbmNyeXB0aW9uIHRvIHByb3RlY3QN CnRoZSBjb25maWRlbnRpYWxpdHkgb2YgY29udGVudC4gIFN1Y2ggYW4gZW5jcnlwdGlvbiBzY2hl bWUgaXMgaGFybWxlc3MgDQp0byB0aGUgZW5jb2RlZCBhdWRpbyBkYXRhIHByZXN1bWluZyB0aGUg ZGF0YSBpcyBkZWNyeXB0ZWQgYmVmb3JlIGJlaW5nIA0Kc2VudCB0byB0aGUgZGVjb2Rlci4gDQoN Cg0KNi4gTm9ybWF0aXZlIFJlZmVyZW5jZXMgDQoNClsxXSBCcmFkbmVyLCBTLiwgIktleSBXb3Jk cyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGUgUmVxdWlyZW1lbnQgDQpMZXZlbHMiLCBSRkMg MjExOSwgSW50ZXJuZXQgRW5naW5lZXJpbmcgVGFzayBGb3JjZSwgTWFyY2ggMTk5Ny4gDQoNClsy XSBVLlMuIEFkdmFuY2VkIFRlbGV2aXNpb24gU3lzdGVtcyBDb21taXR0ZWUgKEFUU0MpLCAiRGln aXRhbCBBdWRpbyANCkNvbXByZXNzaW9uIChBQy0zKSBTdGFuZGFyZCwiIERvYyBBLzUyLCBEZWNl bWJlciAxOTk1LiANCg0KWzNdIEhhbmRsZXksIE0uIGFuZCBKYWNvYnNvbiwgVi4sICJTRFA6IFNl c3Npb24gRGVzY3JpcHRpb24gUHJvdG9jb2wsIiANClJGQyAyMzI3LCBJbnRlcm5ldCBFbmdpbmVl cmluZyBUYXNrIEZvcmNlLCBBcHJpbCAxOTk4IA0KDQpbNF0gU2NodWx6cmlubmUsIENhc25lciwg RnJlZGVyaWNrLCBhbmQgSmFjb2Jzb24sICJSVFA6IEEgVHJhbnNwb3J0IA0KUHJvdG9jb2wgZm9y IFJlYWwtVGltZSBBcHBsaWNhdGlvbnMsIiBSRkMgMTg4OSwgSW50ZXJuZXQgRW5naW5lZXJpbmcg DQpUYXNrIEZvcmNlLCBGZWJydWFyeSAxOTk2LiANCg0KWzVdIEhhbmRsZXksIE0uIGFuZCBQZXJr aW5zLCBDLiwgIkd1aWRlbGluZXMgZm9yIFdyaXRlcnMgb2YgUlRQIFBheWxvYWQgDQpGb3JtYXQg U3BlY2lmaWNhdGlvbnMsIiBSRkMgMjczNiwgSW50ZXJuZXQgRW5naW5lZXJpbmcgVGFzayBGb3Jj ZSwgDQpEZWNlbWJlciAxOTk5LiAgDQoNCg0KNy4gSW5mb3JtYXRpdmUgUmVmZXJlbmNlcw0KDQpb Nl0gVG9kZCwgQy4gZXQuIGFsLCAiQUMtMzogRmxleGlibGUgUGVyY2VwdHVhbCBDb2RpbmcgZm9y IEF1ZGlvIA0KVHJhbnNtaXNzaW9uIGFuZCBTdG9yYWdlLCIgUHJlcHJpbnQgMzc5NiwgUHJlc2Vu dGVkIGF0IHRoZSA5NnRoIA0KQ29udmVudGlvbiBvZiB0aGUgQXVkaW8gRW5naW5lZXJpbmcgU29j aWV0eSwgTWF5IDE5OTQuIA0KDQpbN10gRmllbGRlciwgTC4gZXQuIGFsLCAiQUMtMiBhbmQgQUMt MzogTG93LUNvbXBsZXhpdHkgVHJhbnNmb3JtLUJhc2VkIA0KQXVkaW8gQ29kaW5nLCIgQ29sbGVj dGVkIFBhcGVycyBvbiBEaWdpdGFsIEF1ZGlvIEJpdC1SYXRlIFJlZHVjdGlvbiwgDQpwcC4gNTQt NzIsIEF1ZGlvIEVuZ2luZWVyaW5nIFNvY2lldHksIFNlcHRlbWJlciAxOTk2LiAgDQoNCkhhZ2Vy L0ZsYWtzICAgICAgICAgICAgICAgICBFeHBpcmVzIEp1bmUgMjAwMyAgICAgICAgICAgICAgICAg ICBbUGFnZSAxM10NCgwNCkludGVybmV0IERyYWZ0ICAgICAgUlRQIFBheWxvYWQgRm9ybWF0IGZv ciBBQy0zIFN0cmVhbXMgICAgIEphbnVhcnkgMjAwMw0KDQoNCjguIEF1dGhvcnMnIEFkZHJlc3Nl cw0KDQpUb2RkIEhhZ2VyIA0KRG9sYnkgTGFib3JhdG9yaWVzIA0KMTAwIFBvdHJlcm8gQXZlIA0K U2FuIEZyYW5jaXNjbywgQ0EgOTQxMDMgDQoNClBob25lOiArMSA0MTUgNTU4IDAxMzYNCkVtYWls OiB0aGhAZG9sYnkuY29tDQoNCkphc29uIEZsYWtzDQpNaWNyb3NvZnQgQ29ycG9yYXRpb24NCjEg TWljcm9zb2Z0IFdheQ0KUmVkbW9uZCwgV0EgOTgwNTINCg0KUGhvbmU6ICsxIDQyNSA3MjIgMjU0 Mw0KRW1haWw6IGphc29uZmxAbWljcm9zb2Z0LmNvbQ0K ------_=_NextPart_001_01C2C892.E7017420-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Jan 31 03:23:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01227 for ; Fri, 31 Jan 2003 03:23:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0V8Qkf09557 for avt-archive@odin.ietf.org; Fri, 31 Jan 2003 03:26:46 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0V8QBJ09542; Fri, 31 Jan 2003 03:26:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0V8OWJ09491 for ; Fri, 31 Jan 2003 03:24:32 -0500 Received: from mailman.packetdesign.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01182 for ; Fri, 31 Jan 2003 03:20:36 -0500 (EST) Received: from packetdesign.com (main-fw-eth1.packetdesign.com [192.168.0.254]) by mailman.packetdesign.com (8.12.6/8.12.3) with ESMTP id h0V8O2Xj090244; Fri, 31 Jan 2003 00:24:03 -0800 (PST) (envelope-from casner@acm.org) Date: Fri, 31 Jan 2003 00:41:59 -0800 (PST) From: Stephen Casner To: Mike Taylor cc: AVT WG Subject: RE: [AVT] Final edits to RTP spec and A/V profile In-Reply-To: Message-ID: <20030129095738.Q3590-100000@oak.packetdesign.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , On Fri, 24 Jan 2003, Mike Taylor wrote: > The above statements about multi-point unicast hit on a nerve for > me, so pardon me if I rant just a bit. Considering that I added the text about multi-point unicast as a result of your query in October, I guess that means I was not very successful in addressing your questions. > But having just completed an implementation of RTP/RTCP which I > attempted to make very general purpose, and thus tried to support > point-to-point unicast, multi-point unicast, as well as multicast, I > have to say that the major problem with this RFC is that it mentions > the concepts of unicast RTP sessions, and in particular multi-point > unicast sessions, but really does little to offer requirements or > even guidance about how RTCP should operate in these circumstances. As the introduction of the RTP spec states, we view RTP as a framework that may be used in different ways for different applications. That is why in my example I described multiple ways that three participants might use RTCP. The space of options may be narrowed by an RTP profile, but more likely it will be an application choice that may also be affected by the capabilities of the control protocol. > I believe that the draft, and presumably next standard, should not > attempt to address multi-point unicast especially, but rather should > acknowledge that the RFC only really covers multicast RTP sessions, > and that a separate RFC will be needed to address multi-point > unicast. Why? > > For example, so much of the complexity of RTCP revolves around > keeping track of the numbers of session members so as to compute the > RTCP reporting interval that will maintain the desired bandwidth > constraints on RTCP traffic. That's true, but we felt that the interval calculation is not really that complex, and therefore it is reasonable to specify its use for all modes so that an implementation would not be written with fixed a RTCP interval for unicast only and then be redeployed for multicast without adding the necessary interval calculation. Granted, adding timer reconsideration in the new draft does make it more complex than the interval calculation is in RFC 1889. > But is it not the case that the algorithm offered in the RFC for > this purpose breaks down in the multi-point unicast case? No, I don't think so (more below). > Isn't the assumption that a given session participant never sends > more than one stream of RTCP packets - either receiver reports only, > or sender reports only - the latter possibly containing RR blocks? > So in a multicast session each participant generates at most one > RTCP packet per reporting interval. Yes and yes. > But as correctly suggested above, in a true multi-point unicast > sessions all receivers would have to send RTCP reports about ever > stream being received to every other receiver. Otherwise, even in > the simplest case of a multi-point unicast session where only one > member transmits and all others receive, there will be a gross > underestimation of the number of session participants, and thus for > a large unicast conference of this type (which one would think in > the current multicast-less commercial internet would be the most > common scenario) there would be far more bandwidth consumed by RTCP > than intended. Depends how you look at it. The scenario you describe is really just a collection of point-to-point unicast sessions that all happen to be carrying the same data at the same time. There are N copies of the data. On each point-to-point session, the combined RTCP traffic from the sender and receiver is constrained to 5% of that data bandwidth. The travesty is having to use unicast rather than multicast for the data, but this is a different story. > But if all receivers sent RTCP RRs to all other receivers (I don't > know how they find out about one another to achieve this... more > later) then unlike the multicast case this implies there will be > N*(N-1) RTCP packets sent per reporting interval! Certainly the > algorithm in the RFC for computing the RTCP reporting interval > doesn't take this into account. Each receiver will be sending N-1 RTCP packets, but the RTCP interval will be roughly N times as long as it would have been in the point-to-point case, so the total bandwidth across the interface to/from the receiver is still what it should be. Remember, the data is N times as much as it would be in the multicast case, too. Granted, if the method used to implement multi-unicast is to send all N-1 packets back-to-back, that is still a problem. But if they are spread out over the interval, it works fine. Here again, it depends upon the scenario. For the situation with one data sender and N receivers, it may not make sense to implement a system this way. On the other hand, for a 3 or 4 party teleconference, it seems perfectly fine, and meets the objectives. > So it seems to me that in reality the original, and current draft > RTP RFCs, are both really about multicast RTP, and that the new > draft should admit this fact and there should be additional RFCs to > specify the correct operation of RTP for unicast sessions, and > especially for multi-point unicast sessions. Perhaps point-to-point > unicast is simple enough that its operation can be covered in an > appendix to the current draft. I don't agree. I think point-to-point is covered. Multi-unicast is a variation that we didn't explicitly mention until I added these details in the RTP session definition, but it was always part of the intended coverage of the protocol. > But even there, I think the RFC > should explicitly address the fact that the entire algorithm for > computing RTCP bandwidth is overkill and unnecessary for a simple > point-to-point unicast RTP session. It may not be necessary, but I claim it is still a good idea and not too hard. > I suggest a separate RFC to deal with multi-point unicast only > because I'm sure nobody would want to hold up the advancement of the > current draft long enough to deal properly with this scenario. I would expect other documents that describe _applications_ that use multi-unicast, with coverage not only for the way in which RTP is to be used, but also how the control signaling is to be done. > It seems rather difficult for me to believe that in a commercial > broadcast style deployment of this technology that anyone would want > all receivers sending receiver reports to one another. So I'm > thinking that a more realistic scenario for multi-point unicast > would involve some centralized control. Obviously, in a broadcast > TV scenario where a single transmitter sends unicast RTP to a large > number of receivers, then the receivers should learn about how often > to send receiver reports back to the transmitter from the > transmitter. Why would most of them even care about the other > receivers, and security considerations would seem to dictate that > they shouldn't be aware of them (I'm sure I want to send my RRs to > my nextdoor neighbor's hacker kiddie!). That may well be. The idea for multicast with a scenario of cooperative receivers is that being able to know that your reception is worse than most peoples lets you know that there is a distribution problem near you. The same applies to some extent with multi-unicast. The rate control still applies to keep the number of packets hitting the sender to be constant independent of session size. Also, there are DoS risks in central control that are avoided by the distributed algorithm. A lot of thought went into this. See draft-ietf-avt-rtcpssm-02.txt for some discussion of the security issues in a related context. > Besides, as stated above, even if one took the approach of sending > RRs to all other receivers, how would one know how to address these > reports without centralized session control anyway? It is more likely to make sense in an application such as teleconferencing which has explicit session control (which may be implemented in a centralized or distributed manner). -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Jan 31 03:23:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01250 for ; Fri, 31 Jan 2003 03:23:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0V8RJ909618 for avt-archive@odin.ietf.org; Fri, 31 Jan 2003 03:27:19 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0V8R5J09591; Fri, 31 Jan 2003 03:27:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0V8PXJ09521 for ; Fri, 31 Jan 2003 03:25:33 -0500 Received: from mailman.packetdesign.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01189 for ; Fri, 31 Jan 2003 03:21:37 -0500 (EST) Received: from packetdesign.com (main-fw-eth1.packetdesign.com [192.168.0.254]) by mailman.packetdesign.com (8.12.6/8.12.3) with ESMTP id h0V8OSXj090271; Fri, 31 Jan 2003 00:24:29 -0800 (PST) (envelope-from casner@acm.org) Date: Fri, 31 Jan 2003 00:42:32 -0800 (PST) From: Stephen Casner To: John Lazzaro cc: avt@ietf.org Subject: Re: [AVT] Final edits to RTP spec and A/V profile In-Reply-To: <200301161924.LAA17554@snap.CS.Berkeley.EDU> Message-ID: <20030129095550.M3590-100000@oak.packetdesign.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , On Thu, 16 Jan 2003, John Lazzaro wrote: > Sfront currently ships with multi-unicast support, and the > implementation is a hybrid of both approaches. A sender does > sent the same RTP packet to each receiver, and in this way > everything but the lowest layers of the stack believes a > true multicast session is underway. Sfront needs to do this, > because it lets a sender create and maintain one recovery > journal system for all receivers, a big efficiency improvement > over N recovery journal systems. > > However, a receiver doesn't send RTCP RR packets describing > a sent stream to all other participants, only to the original > sender. This is for efficiency ... This is really not a multi-party RTP session then, because each pair of participants sees only their two SSRC identifiers in packets exchanged between them. It is an "arranged coincidence" that a given participant uses the same SSRC for all of its point-to-point unicast RTP sessions. How do you avoid collisions in the choice of SSRC identifiers? Is the choice of SSRC coordinated at the time of session establishment? Or does a new participant listen for packets from all of the other participants before choosing its own SSRC? (This can be tricky if multiple participants join at once.) -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Jan 31 03:30:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01290 for ; Fri, 31 Jan 2003 03:30:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0V8XVO09825 for avt-archive@odin.ietf.org; Fri, 31 Jan 2003 03:33:31 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0V8X6J09808; Fri, 31 Jan 2003 03:33:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0V8WYJ09763 for ; Fri, 31 Jan 2003 03:32:34 -0500 Received: from mailman.packetdesign.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01278 for ; Fri, 31 Jan 2003 03:28:38 -0500 (EST) Received: from packetdesign.com (main-fw-eth1.packetdesign.com [192.168.0.254]) by mailman.packetdesign.com (8.12.6/8.12.3) with ESMTP id h0V8W7Xj090481; Fri, 31 Jan 2003 00:32:08 -0800 (PST) (envelope-from casner@acm.org) Date: Fri, 31 Jan 2003 00:50:12 -0800 (PST) From: Stephen Casner To: Dominic Walker cc: "'csp@isi.edu'" , "'avt@ietf.org'" In-Reply-To: <6B78F2524CD7D5118A0402204840075B01B1EF53@zhard0jc.europe.nortel.com> Message-ID: <20030131004403.S4018-100000@oak.packetdesign.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [AVT] Re: when will draft-ietf-avt-rfc2833bis-02 become an RFC? Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , On Tue, 28 Jan 2003, Dominic Walker wrote: > Dear S. Bradner and A. Mankin, > > Could you tell me by when it is envisioned that the draft RFC : > draft-ietf-avt-rfc2833bis-02.txt "RTP Payload for DTMF Digits, Telephony > Tones and Telephony Signals " would become an RFC? What approval process > must it go through in order to become an RFC (Must it be voted at the next > IETF meeting)?. Also, would it be called RFC2833 or RFC 2833bis? You addressed your message to S. Bradner and A. Mankin, but did not send it to them directly. The draft-ietf-avt-rfc2833bis-02.txt was discussed at the IETF meeting in Atlanta, resulting in some changes to be made. The authors will prepare another version, which can happen at any time (does not have to wait for the next meeting). Presuming that version is believed to be complete, a two-week working group last call for comments, and if there are no problems, it would then be submitted with a request for publication. If Allison Mankin finds it ready for full IESG review, then the IESG last call will be issued. If the draft is approved by the IESG, then it will go to the RFC editor. It will be published with a new number, so it will be neither 2833 nor 2833bis. -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Jan 31 14:54:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17019 for ; Fri, 31 Jan 2003 14:54:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0VJvfS15672 for avt-archive@odin.ietf.org; Fri, 31 Jan 2003 14:57:41 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VJuPJ15622; Fri, 31 Jan 2003 14:56:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VJsGJ15574 for ; Fri, 31 Jan 2003 14:54:16 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16942; Fri, 31 Jan 2003 14:50:07 -0500 (EST) Message-Id: <200301311950.OAA16942@ietf.org> To: IETF-Announce: ; Cc: avt@ietf.org From: The IESG Reply-to: iesg@ietf.org Date: Fri, 31 Jan 2003 14:50:07 -0500 Subject: [AVT] Last Call: RTP Payload Format for ETSI ES 201 108 Distributed Speech Recognition Encoding to Proposed Standard Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , The IESG has received a request from the Audio/Video Transport Working Group to consider 'RTP Payload Format for ETSI ES 201 108 Distributed Speech Recognition Encoding' as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-2-14. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-avt-dsr-05.txt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Jan 31 17:49:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21062 for ; Fri, 31 Jan 2003 17:49:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0VMr1t25250 for avt-archive@odin.ietf.org; Fri, 31 Jan 2003 17:53:01 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VMp8J25176; Fri, 31 Jan 2003 17:51:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VMhfJ24995 for ; Fri, 31 Jan 2003 17:43:41 -0500 Received: from snap.CS.Berkeley.EDU (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20802 for ; Fri, 31 Jan 2003 17:39:27 -0500 (EST) Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.9.3/8.9.3-ZUUL) id OAA10060; Fri, 31 Jan 2003 14:42:41 -0800 Date: Fri, 31 Jan 2003 14:42:41 -0800 From: John Lazzaro Message-Id: <200301312242.OAA10060@snap.CS.Berkeley.EDU> To: casner@acm.org, lazzaro@CS.Berkeley.EDU Subject: Re: [AVT] Final edits to RTP spec and A/V profile Cc: avt@ietf.org Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , > Stephen Casner writes: > > How do you avoid collisions in the choice of SSRC identifiers? If a session has N parties, each party is responsible for sending an RTCP unicast stream to each of the other N-1 parties. In this sense, sfront enforces an "all-to-all" session topology, just as true multicast does. So, in steady-state, a party sees an RTCP stream from each of the other parties, which is sufficient for doing SSRC collision detection on its own SSRC. However, compared to a true multicast scenareo, two pieces of information are missing: [1] A party cannot detect the presence of a new session participant by examining the incoming unicast RTCP and RTP flows. Instead, active session management is needed (in the case of sfront, a B2BUA "SIP conference server" that exchanges session descriptions between the parties of a session). [2] Party A cannot sense how well Party B is receiving the RTP stream sent by Party C, because it doesn't see the RTCP traffic flowing between Parties B and C. So, session management is not needed to handle SSRC collisions, but is needed for [1]. In addition, session management information is needed for a party to associate the streams sent to a new party with the streams received from a new party. This information takes the form of the username and address in the origin line of the session description sent in [1], which matches the CNAME of the RTCP packets sent back from the receiver of the streams defined in the session description. Without this information: o A party wouldn't be able to know how to correctly "narrowcast" RTCP RR reports. o A party wouldn't know which RTP and RTCP streams to stop sending when another party exits. In practice, sfront NMP does currently "cheat", and embeds the SSRC into the session ID on the origin line. The use of a single-threaded B2BUA conference server at Berkeley to set up sfront sessions makes it easy for the conference server to see SSRC clashes -- it rejects INVITEs with clashes, with a non-standard SIP header line that tells the new party to choose a new SSRC. But, I don't believe this hack is required ... just as true multicast sessions use the CNAME to associate streams, I'm pretty sure the CNAME is sufficient for doing association in this case too. ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro ------------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt