http://permalink.gmane.org/gmane.ietf.avt hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.ietf.avt/13902 <pre>Hi all, Roni just pointed out that the name of the draft didn't follow the proper naming mechanism and the AVTCORE name was not included. Sorry about that. I have resubmitted the draft with the proper name: http://www.ietf.org/id/draft-gross-avtcore-leap-second-00.txt Thanks, Ray From: avt-bounces&lt; at &gt;ietf.org [mailto:avt-bounces&lt; at &gt;ietf.org] On Behalf Of Brandenburg, R. (Ray) van Sent: woensdag 23 mei 2012 9:51 To: avt&lt; at &gt;ietf.org Subject: [AVTCORE] New version (-01) of Leap Seconds draft Hi all, I've just uploaded a new version of the Leap Seconds draft (http://www.ietf.org/id/draft-gross-leap-second-01.txt). The draft is meant as a small update to RFC3550 that improves RTP's reliability in the vicinity of a leap second. Among others it includes some requirements for RTP senders/receivers to have a functioning communicating channel to receive leap second scheduling updates (which, if not implemented, could mean a long-term discrepancy between sender and receiver of 1 second) and other requirements dealing </pre> Brandenburg, R. (Ray) van 2012-05-23T08:59:53 http://permalink.gmane.org/gmane.ietf.avt/13901 <pre>Hi all, I've just uploaded a new version of the Leap Seconds draft (http://www.ietf.org/id/draft-gross-leap-second-01.txt). The draft is meant as a small update to RFC3550 that improves RTP's reliability in the vicinity of a leap second. Among others it includes some requirements for RTP senders/receivers to have a functioning communicating channel to receive leap second scheduling updates (which, if not implemented, could mean a long-term discrepancy between sender and receiver of 1 second) and other requirements dealing with the short term effects of a leap second. In this -01 version of the draft we have included more references and fixed a lot of typos. Thanks to Steve Allen for his contributions. Best regards, Ray This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer _______________________________________________ Audio/Video Transport Core Maintenance avt&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/avt </pre> Brandenburg, R. (Ray) van 2012-05-23T07:51:20 http://permalink.gmane.org/gmane.ietf.avt/13900 <pre>Hi, AVTcore have the following milestone: Nov 2012 - Submit RTP Clock Source Signaling as Proposed Standard The chairs propose to adopt http://tools.ietf.org/html/draft-williams-avtcore-clksrc-00 as the initial document to address this milestone. The document will also be reviewed by the SDP directorate. There are no other documents addressing this milestone so please let the chairs know if you support this action by June 6th Thanks Roni Even _______________________________________________ Audio/Video Transport Core Maintenance avt&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/avt </pre> Roni Even 2012-05-23T07:39:27 http://permalink.gmane.org/gmane.ietf.avt/13899 <pre>FYI, ITU-T SG16 has a work item for such kind of middleboxes and performance monitoring support: http://www.itu.int/ITU-T/workprog/wp_item.aspx?isn=8407 "Guidelines on the use of H.248 capabilities for performance monitoring in RTP networks in H.248 Profiles" ... and the ITU-T work is referring to MONARCH. -Albrecht Audio/Video Transport Core Maintenance avt&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/avt </pre> Albrecht Schwarz 2012-05-23T02:16:33 http://permalink.gmane.org/gmane.ietf.avt/13898 <pre>Hi,Albrecht: Thank for sharing, I have been aware of this work being progressed in SG 16. Regards! -Qin ----- Original Message ----- From: Albrecht Schwarz To: Colin Perkins ; Qin Wu Cc: avt&lt; at &gt;ietf.org Sent: Wednesday, May 23, 2012 10:16 AM Subject: Re: [AVTCORE] Subject: AD review of draft-ietf-avtcore-monarch-13 FYI, ITU-T SG16 has a work item for such kind of middleboxes and performance monitoring support: http://www.itu.int/ITU-T/workprog/wp_item.aspx?isn=8407 "Guidelines on the use of H.248 capabilities for performance monitoring in RTP networks in H.248 Profiles" ... and the ITU-T work is referring to MONARCH. -Albrecht ---------------------------------------------------------------------------- Von: Colin Perkins &lt;csp&lt; at &gt;csperkins.org&gt; An: Qin Wu &lt;bill.wu&lt; at &gt;huawei.com&gt; CC: Albrecht Schwarz &lt;albrechtschwarz&lt; at &gt;yahoo.de&gt;; avt&lt; at &gt;ietf.org Gesendet: 13:04 Dienstag, 22.Mai 2012 Betreff: Re: [AVTCORE] Subject: AD review</pre> Qin Wu 2012-05-23T03:23:35 http://permalink.gmane.org/gmane.ietf.avt/13897 <pre>Hi, Take Robert,Colin and Albrechet's comments into account, I propose to rewrite section 3.3 with the following changes: OLD TEXT: " 3.3. RTP Sender/Receiver entities located in network nodes The location of the RTP Sender/Receiver entities may impact a set of meaningful metrics. For instance, application level metrics for QoE related performance parameters are under most conditions measured at the user device that receives RTP data packets. However in some cases, given the factors ( "measurement point location", "measurement model location", "awareness of content information", etc [P.NAMS]) taken into account, such metrics may be measured in a network node instead of a user device. " NEW TEXT: " 3.3. Measurement point of the RTP monitor within the network. The RTP monitors are spread across a single domain(e.g., network domain) or multiple domains (e.g., between network domain and service domain)in the network. The performance Metrics reported from the RTP monitor can be div</pre> Qin Wu 2012-05-23T03:22:03 http://permalink.gmane.org/gmane.ietf.avt/13896 <pre>[Qin]: One improvement to definitions of Interval Metrics, Cumulative Metrics and Sampled Metrics to get alignment with draft-ietf-xrblock-rtcp-xr-meas-identity since based on draft-ietf-xrblock-rtcp-xr-meas-identity, in some case,the measurement interval for a metric is different from the RTCP reporting interval, in such case, Measurement information block in the draft-ietf-xrblock-rtcp-xr-meas-identity can be used to specify such measurement interval. The proposed improvement is described as follows: " Interval metrics: Metrics calculated based on values measured over the course of a single reporting interval. This may be the most recent RTCP reporting interval ([RFC3550], section 6.2) or some other interval signalled using an RTCP Measurement Information XR Block [draft-ietf-xrblock-rtcp-xr-meas-identity]. An example interval metric is the count of the number of RTP packets lost over the course of the last RTCP reporting interval. Cumulative metrics: Metrics derived from cumulative measurements taken </pre> Qin Wu 2012-05-23T01:30:57 http://permalink.gmane.org/gmane.ietf.avt/13895 <pre>Furthermore, the issues raised in the following document should be addressed in section #3: http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/CWC-GCM/Ferguson2.pdf It basically means the modes with authentication tags smaller than 16 octets MUST NOT be used with AES-GCM. In light of that, I question the value of supporting a GCM based mode for SRTP. Thanks, --Felix _______________________________________________ Audio/Video Transport Core Maintenance avt&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/avt </pre> Wyss, Felix 2012-05-22T14:05:30 http://permalink.gmane.org/gmane.ietf.avt/13894 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF. Title : RTCP for inter-destination media synchronization Author(s) : Ray van Brandenburg Hans Stokking Fernando Boronat Mario Montagud Kevin Gross Filename : draft-ietf-avtcore-idms-04.txt Pages : 21 Date : 2012-05-22 This document gives information on an RTCP Packet Type and RTCP XR Block Type including associated SDP parameters for Inter-Destination Media Synchronization (IDMS). The RTCP XR Block Type, registered with IANA based on an ETSI specification, is used to collect media playout information from participants in a group playing-out (watching, listening, etc.) a specific RTP media stream. The RTCP packet type specified by this document is used to di</pre> internet-drafts< at >ietf.org 2012-05-22T11:57:41 http://permalink.gmane.org/gmane.ietf.avt/13893 <pre>I also don't agree with deleting Section 3.3 from the monarch draft. The architecture needs to be clear that there are valid scenarios for RTP monitoring within a network, either in some middlebox that comprises part of an RTP session, or in a third-party monitoring device used for network management purposes. Section 3.3 is a reasonable place to discuss these, and to explain why the metrics that can be reported from middleboxes are different to those that can be captured at end systems. Colin On 22 May 2012, at 07:53, Qin Wu wrote: P and RTCP traffic but does not make itself visible to the RTP Session participants (i.e., the third party monitor depicted in figure 1) can act as the can be monitored using RTCP. In the ASM case, the monitor is a member of the multicast group and listens to RTCP XR reports from all members of the ASM spans over more than one RTCP report intervals. Sampled metrics Metrics of which the reported values only apply to the value of a continuously measured or this document </pre> Colin Perkins 2012-05-22T11:04:33 http://permalink.gmane.org/gmane.ietf.avt/13892 <pre>Hi, I got a request to progress this document towards WG last call. So while we chairs are cleaning up some administrative stuff, like getting a milestone in place. I thought the authors should get something to do and thus reviewed the draft. 1) Section 1.1 "Crypto Context For the purposes of this document a crypto context is the outcome of any process which results in authentication of each participant in the SRTP session and possession by each partcipant of a shared secret master key and a shared master salt." What is the definition of participant here, SSRC, endpoint, user, or system? Please correct the "partcipant" spelling error also. 2) Section 1.1, crypto context: " Ciper Contest" I guess should be Crypto Context. 3) Section 1.1. is the text for crypto context really accurate as the document does define protection profiles for both DTLS-SRTP and Security description. 4) I am missing pro</pre> Magnus Westerlund 2012-05-22T08:18:27 http://permalink.gmane.org/gmane.ietf.avt/13891 <pre>Hi,: ----- Original Message ----- From: "Albrecht Schwarz" &lt;albrechtschwarz&lt; at &gt;yahoo.de&gt; To: &lt;bill.wu&lt; at &gt;huawei.com&gt; Cc: &lt;avt&lt; at &gt;ietf.org&gt;; &lt;rjsparks&lt; at &gt;nostrum.com&gt; Sent: Tuesday, May 22, 2012 11:18 AM Subject: Re: [AVTCORE] Subject: AD review of draft-ietf-avtcore-monarch-13 Dear All, concerning the resolution proposal for clause 3.3: I don't agree in just deleting again that section! There was quite a long debate for incorporating such a clause. The original text proposal was much more detailed. Perhaps the shortening to just a single paragraph is the main cause for unclarity. Thus, instead of removing previous agreed text, we just rather extend it again. [Qin]: The reason I propose to remove the section 3.3 is a. I think Robert is correct. The set of meaningful metrics isn't changed at all wherever you collect them. It seems little sense to say "the location of the RTP Sender/Receiver entities may impact a set of meaningful metrics. " b. Where to gather or measure metrics can be indicated by the defin</pre> Qin Wu 2012-05-22T06:53:29 http://permalink.gmane.org/gmane.ietf.avt/13890 <pre>Hi,Robert: Thank for your valuable review. please see my replies inline belows. Regards! -Qin ----- Original Message ----- From: "Robert Sparks" &lt;rjsparks&lt; at &gt;nostrum.com&gt; To: "IETF AVTCore WG" &lt;avt&lt; at &gt;ietf.org&gt;; &lt;draft-ietf-avtcore-monarch&lt; at &gt;tools.ietf.org&gt; Sent: Wednesday, May 16, 2012 7:13 AM Subject: [AVTCORE] Subject: AD review of draft-ietf-avtcore-monarch-13 [Qin]: Agree. [Qin]: Okay. [Qin]: Agree, I propose to remove the figure 1 and squeeze the section 3.1 as follows: " 3.1. Overview The RTP monitoring architecture comprises the following two key functional components shown below: o RTP Monitor o RTP Metric Block Structure RTP Monitor is the functional component defined in the Real-time Transport Protocol [RFC3550]. It acts as a source of information gathered for monitoring purposes and exchanges information with the other RTP monitors using RTCP Metric Blocks. According to the definition of monitor in the RTP Protocol [RFC3550], the end sy</pre> Qin Wu 2012-05-18T10:37:56 http://permalink.gmane.org/gmane.ietf.avt/13889 <pre>The IESG has approved the following document: - 'Explicit Congestion Notification (ECN) for RTP over UDP' (draft-ietf-avtcore-ecn-for-rtp-08.txt) as Proposed Standard This document is the product of the Audio/Video Transport Core Maintenance Working Group. The IESG contact persons are Robert Sparks and Gonzalo Camarillo. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-avtcore-ecn-for-rtp/ Technical Summary This memo specifies how Explicit Congestion Notification (ECN) can be used with the Real-time Transport Protocol (RTP) running over UDP, using RTP Control Protocol (RTCP) as a feedback mechanism. It defines a new RTCP Extended Report (XR) block for periodic ECN feedback, a new RTCP transport feedback message for timely reporting of congestion events, and a Session Traversal Utilities for NAT (STUN) extension used in the optional initialization method using Interactive Connectivity Establishment (ICE). Signalling and procedures for negotiation of cap</pre> The IESG 2012-05-16T21:25:58 http://permalink.gmane.org/gmane.ietf.avt/13888 <pre>Summary: There are issues to resolve with a revised ID before progressing to IETF LC. It's a struggle to see the _architecture_ this document is supposed to describe. I suspect most of the working group energy went into Section 5 (the guidelines for writing XR block definitions) - the rest of the document needs a similar level of attention to detail. There are two major issues that I've tagged with a (*). I followed a mostly document-order flow instead of grouping the major issues at the top. (*) Given the document's title, it should be very easy to answer "What is the monitoring architecture?" for people who are reading this draft for the first time. The key message is that the monitoring architecture consists of Monitors that exchange information using RTCP Metric Blocks. The text should say that. There is a lot of prose in section 3 and visual detail in the diagram in Figure 1 that makes that extremely difficult to see. Simplifying the figure by removing the details about applications and t</pre> Robert Sparks 2012-05-15T23:13:39 http://permalink.gmane.org/gmane.ietf.avt/13887 <pre>AVT experts, Let me make a request for review on the draft " The ARIA Algorithm and Its Use with the Secure Real-time Transport Protocol(SRTP) ". Any comments would be appreciated. http://tools.ietf.org/html/draft-ietf-avtcore-aria-srtp-00 Woo-Hwan Kim ---------- Forwarded message ---------- From: &lt;internet-drafts&lt; at &gt;ietf.org&gt; Date: 2012/5/15 Subject: New Version Notification for draft-ietf-avtcore-aria-srtp-00.txt To: whkim5&lt; at &gt;ensec.re.kr Cc: ds_kwon&lt; at &gt;ensec.re.kr, dongchan&lt; at &gt;ensec.re.kr, jhpark&lt; at &gt;ensec.re.kr, jklee&lt; at &gt;ensec.re.kr A new version of I-D, draft-ietf-avtcore-aria-srtp-00.txt has been successfully submitted by Woo-Hwan Kim and posted to the IETF repository. Filename: draft-ietf-avtcore-aria-srtp Revision: 00 Title: The ARIA Algorithm and Its Use with the Secure Real-time Transport Protocol(SRTP) Creation date: 2012-05-15 WG ID: avtcore Number of pages: 10 Abstract: This document describes the use of the ARIA block cipher algorithm within the Secure Real-time Tr</pre> Woo-Hwan Kim 2012-05-15T08:31:58 http://permalink.gmane.org/gmane.ietf.avt/13885 <pre>There are also a number of editorial changes, and the removal of 2119 keywords from the requirements section. Please review the changes carefully. All the discusses have cleared. I'll send in the approval notice Wednesday unless I hear from the list otherwise. RjS On 5/14/12 8:16 AM, Magnus Westerlund wrote: _______________________________________________ Audio/Video Transport Core Maintenance avt&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/avt </pre> Robert Sparks 2012-05-14T18:20:48 http://permalink.gmane.org/gmane.ietf.avt/13884 <pre>WG, This version is intended to address the discuss and comments from IESG. A Diff is available here: http://tools.ietf.org/rfcdiff?url2=draft-ietf-avtcore-ecn-for-rtp-08 The main technical change is for the ABNF for future extension of the ecn-capable-rtp attribute which now allows escaping in the quoted list. Cheers Magnus On 2012-05-14 10:50, internet-drafts&lt; at &gt;ietf.org wrote: </pre> Magnus Westerlund 2012-05-14T13:16:34 http://permalink.gmane.org/gmane.ietf.avt/13882 <pre>I support it too. Varun. On 8.5.2012, at 23.54, "Bill Ver Steeg (versteb)" &lt;versteb&lt; at &gt;cisco.com&gt; wrote: I support it also Bill VerSteeg *From:* avt-bounces&lt; at &gt;ietf.org [mailto:avt-bounces&lt; at &gt;ietf.org] *On Behalf Of *Kevin Gross *Sent:* Sunday, May 06, 2012 12:18 AM *To:* Magnus Westerlund *Cc:* IETF AVTCore WG *Subject:* Re: [AVTCORE] Adopting a WG item for RTP stream duplication? I support creating a WG item for this. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com &lt;http://www.avanw.com/&gt;, www.X192.org On Wed, Apr 25, 2012 at 8:46 AM, Magnus Westerlund &lt; magnus.westerlund&lt; at &gt;ericsson.com&gt; wrote: WG, In Paris we took a hum on adopting a WG item for RTP Stream Duplication. The problem this tries to address is described in https://datatracker.ietf.org/doc/draft-begen-avtcore-rtp-duplication/ The result in the meeting room was minuted as: A fair amount of people supporting a WG item, none against. See more about this item (Agenda Item 10) in the minutes http://www</pre> Varun Singh 2012-05-08T20:56:15 http://permalink.gmane.org/gmane.ietf.avt/13881 <pre>I support it also Bill VerSteeg From: avt-bounces&lt; at &gt;ietf.org [mailto:avt-bounces&lt; at &gt;ietf.org] On Behalf Of Kevin Gross Sent: Sunday, May 06, 2012 12:18 AM To: Magnus Westerlund Cc: IETF AVTCore WG Subject: Re: [AVTCORE] Adopting a WG item for RTP stream duplication? I support creating a WG item for this. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com &lt;http://www.avanw.com/&gt; , www.X192.org On Wed, Apr 25, 2012 at 8:46 AM, Magnus Westerlund &lt;magnus.westerlund&lt; at &gt;ericsson.com&gt; wrote: WG, In Paris we took a hum on adopting a WG item for RTP Stream Duplication. The problem this tries to address is described in https://datatracker.ietf.org/doc/draft-begen-avtcore-rtp-duplication/ The result in the meeting room was minuted as: A fair amount of people supporting a WG item, none against. See more about this item (Agenda Item 10) in the minutes http://www.ietf.org/proceedings/83/minutes/minutes-83-avtcore.htm Thus I would like to ask the rest of the WG if they sup</pre> Bill Ver Steeg (versteb 2012-05-08T20:54:07 http://permalink.gmane.org/gmane.ietf.avt/13880 <pre>Sorry, a link would be helpful. https://datatracker.ietf.org/doc/draft-gross-leap-second/ Kevin Gross On Tue, May 8, 2012 at 9:39 AM, Kevin Gross &lt;kevin.gross&lt; at &gt;avanw.com&gt; wrote: _______________________________________________ Audio/Video Transport Core Maintenance avt&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/avt </pre> Kevin Gross 2012-05-08T15:54:29 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.avt