From Even.roni@huawei.com Mon Jul 4 11:32:35 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE291F0C83 for ; Mon, 4 Jul 2011 11:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bhe30ZnOtktk for ; Mon, 4 Jul 2011 11:32:34 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 76D9E1F0C34 for ; Mon, 4 Jul 2011 11:32:34 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LNT00H63NI9HI@szxga04-in.huawei.com> for avtext@ietf.org; Tue, 05 Jul 2011 02:32:33 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LNT002L3NI90Q@szxga04-in.huawei.com> for avtext@ietf.org; Tue, 05 Jul 2011 02:32:33 +0800 (CST) Received: from windows8d787f9 (bzq-79-176-43-124.red.bezeqint.net [79.176.43.124]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LNT00JNQNI2UD@szxml11-in.huawei.com>; Tue, 05 Jul 2011 02:32:33 +0800 (CST) Date: Mon, 04 Jul 2011 21:30:14 +0300 From: Roni Even In-reply-to: To: "'DRAGE, Keith (Keith)'" , avtext@ietf.org Message-id: <005e01cc3a78$6ee88340$4cb989c0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-us Content-transfer-encoding: quoted-printable Thread-index: Acwnh4FBkyy8xdLASmWhGVojp31o8wJ/8+8wAjwfCeA= References: <4DF23F7E.2070903@ericsson.com> Subject: Re: [avtext] Consensus call on RTP Splicing direction forward X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 18:32:35 -0000 Hi, I think that Dave and Colin who had interest in this work both said that = if non detectability is not an issue than the mixer approach make sense, = the CSRC can help with monitoring while on the other side the splicer can = make it harder to detect by not sending the CSRC. I think that it will be good to update the current draft with the requirements based on the discussion and do the mixer as first step. We can later look if and how to address the best way to support a good enough non detectable case. Roni > -----Original Message----- > From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On > Behalf Of DRAGE, Keith (Keith) > Sent: Thursday, June 23, 2011 12:25 PM > To: avtext@ietf.org > Subject: Re: [avtext] Consensus call on RTP Splicing direction forward >=20 > [As WG chair] >=20 > Magnus sent out this call a couple of weeks back and we haven't seen > very many responses. >=20 > If you have not already responded, please do so. >=20 > Regards >=20 > Keith >=20 > > -----Original Message----- > > From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On > Behalf > > Of Magnus Westerlund > > Sent: 10 June 2011 17:00 > > To: avtext@ietf.org > > Subject: [avtext] Consensus call on RTP Splicing direction forward > > > > Hi, > > > > We have had this ongoing discussion on the mailing list around the > RTP > > Splicing and the pro-and-cons for two major solutions. To try to get > to > > some decision on what the WG should focus on I would like to ask the > WG > > to indicate their preference for what should be done here. The > options > > are three on a high level. And this is for an informational document > > that explains how you use the existing RTP features to accomplish > > splicing. > > > > A) Focus only on RTP Translator based solution > > > > B) Focus only on RTP Mixer based solution > > > > C) Define both Mixer and Translator based solutions. > > > > A) is pretty well described in the individual draft: > > https://datatracker.ietf.org/doc/draft-xia-avtext-splicing-for-rtp/ > > > > The trade-offs and limiations of A and B has been fairly well > discussed > > in the following email list discussion. > > http://www.ietf.org/mail-archive/web/avtext/current/msg00046.html > > > > So if you aren't familiar with the topic already please review the > above > > and then indicate your position no later than the 26th of June. > > > > Independently of the choice that solution will have to discuss the > pros > > and cons of that method and what properties it has. > > > > Cheers > > > > Magnus Westerlund > > > > = --------------------------------------------------------------------- > - > > Multimedia Technologies, Ericsson Research EAB/TVM > > = --------------------------------------------------------------------- > - > > Ericsson AB | Phone +46 10 7148287 > > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > > = --------------------------------------------------------------------- > - > > > > _______________________________________________ > > avtext mailing list > > avtext@ietf.org > > https://www.ietf.org/mailman/listinfo/avtext > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From internet-drafts@ietf.org Mon Jul 4 15:44:36 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A68421F87E1; Mon, 4 Jul 2011 15:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2MejDqsM4pC0; Mon, 4 Jul 2011 15:44:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0042F21F876C; Mon, 4 Jul 2011 15:44:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110704224435.7299.5368.idtracker@ietfa.amsl.com> Date: Mon, 04 Jul 2011 15:44:35 -0700 Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-mixer-to-client-audio-level-03.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 22:44:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Extensions Work= ing Group of the IETF. Title : A Real-Time Transport Protocol (RTP) Header Extension fo= r Mixer-to- Client Audio Level Indication Author(s) : Emil Ivov Enrico Marocco Jonathan Lennox Filename : draft-ietf-avtext-mixer-to-client-audio-level-03.txt Pages : 16 Date : 2011-07-04 This document describes a mechanism for RTP-level mixers in audio conferences to deliver information about the audio level of individual participants. Such audio level indicators are transported in the same RTP packets as the audio data they pertain to. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avtext-mixer-to-client-audio= -level-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtext-mixer-to-client-audio-= level-03.txt From internet-drafts@ietf.org Mon Jul 4 15:44:37 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9966121F87E8; Mon, 4 Jul 2011 15:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HDx9F3dB4nxL; Mon, 4 Jul 2011 15:44:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D98621F876C; Mon, 4 Jul 2011 15:44:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110704224437.6992.51260.idtracker@ietfa.amsl.com> Date: Mon, 04 Jul 2011 15:44:37 -0700 Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-client-to-mixer-audio-level-03.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 22:44:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Extensions Work= ing Group of the IETF. Title : A Real-Time Transport Protocol (RTP) Header Extension fo= r Client-to- Mixer Audio Level Indication Author(s) : Jonathan Lennox Emil Ivov Enrico Marocco Filename : draft-ietf-avtext-client-to-mixer-audio-level-03.txt Pages : 11 Date : 2011-07-04 This document defines a mechanism by which packets of Real-Time Transport Protocol (RTP) audio streams can indicate, in an RTP header extension, the audio level of the audio sample carried in the RTP packet. In large conferences, this can reduce the load on an audio mixer or other middlebox which wants to forward only a few of the loudest audio streams, without requiring it to decode and measure every stream that is received. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avtext-client-to-mixer-audio= -level-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtext-client-to-mixer-audio-= level-03.txt From emil@sip-communicator.org Mon Jul 4 15:47:47 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53EF31F0C37 for ; Mon, 4 Jul 2011 15:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.722 X-Spam-Level: X-Spam-Status: No, score=-2.722 tagged_above=-999 required=5 tests=[AWL=-0.877, BAYES_00=-2.599, FRT_FOLLOW1=1.332, FRT_FOLLOW2=0.422, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4OcZoDV5cLqq for ; Mon, 4 Jul 2011 15:47:46 -0700 (PDT) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id 0B42521F876A for ; Mon, 4 Jul 2011 15:47:45 -0700 (PDT) Received: by fxe4 with SMTP id 4so6728464fxe.27 for ; Mon, 04 Jul 2011 15:47:45 -0700 (PDT) Received: by 10.223.160.131 with SMTP id n3mr388115fax.111.1309819665049; Mon, 04 Jul 2011 15:47:45 -0700 (PDT) Received: from porcinet.local (shm67-5-88-165-90-188.fbx.proxad.net [88.165.90.188]) by mx.google.com with ESMTPS id h1sm4873397fag.11.2011.07.04.15.47.43 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Jul 2011 15:47:44 -0700 (PDT) Message-ID: <4E12430E.9020507@jitsi.org> Date: Tue, 05 Jul 2011 00:47:42 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; bg; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Magnus Westerlund References: <4E01E8F5.6050808@ericsson.com> In-Reply-To: <4E01E8F5.6050808@ericsson.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "avtext@ietf.org" , draft-ietf-avtext-mixer-to-client-audio-level@tools.ietf.org Subject: Re: [avtext] Comments on draft-ietf-avtext-mixer-to-client-audio-level-02 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 22:47:47 -0000 Hey Magnus, Keith, all, We have just submitted new versions of the level drafts that we hope would address most of the comments expressed on the list. Diff2 available here: http://tools.ietf.org/rfcdiff?url2=draft-ietf-avtext-mixer-to-client-audio-level-03.txt http://tools.ietf.org/rfcdiff?url2=draft-ietf-avtext-client-to-mixer-audio-level-03.txt Comments inline: Magnus Westerlund commented on mixer-to-client: > Hi, > > I reviewed the draft and have some comments. Thanks! > 1. The intended status says Informational. This document is intended for > standards track. Fixed. > 2. Section 3, paqe 4: > " Note that in some cases a mixer may be sending an RTP audio stream > that only contains audio level information and no actual audio. > Updating a (web) interface conference module may be one reason for > this to happen." > > My question would what value you stick into the payload type field if > you have no payload only header? It is not obvious that you can do this > without configuring a payload format that either is valid for a zero > length payload or define a specific for that case. Agreed. Removed. > 3. Section 4 and 5. I find the definition confusing, especially as > important rules of the actual format comes in later sections. > a) First of all it is not written in generic engough way to support > both the short and long format. > b) The actual extension formats that is the payload is in the next > section. Including important rules, like that the CSRC list shall be > mapped against the level list. > > I would recommend that Section 4 and 5 is merged and that a more ordered > structure to the definition of the header extensions is made. Where > field values are clearly defined including explicit length in bits. And > where the rules around it is separated from the basic field definitions. OK, we've merged sections 4 and 5 into a single "Audio Levels" section. We've described use of the extension with both the one-byte and the two-byte header formats and added example for both of them. We've also modified the corresponding section in the client-to-mixer draft so that both are now almost identical, which is also what Keith advised in an earlier exchange. > 4. Section 5. I think the dBov definition needs to be really clear. Yes, > the convention is amplitudes are squared when doing dB calculation. But > it is not clear if this is done for the single highest value in the > measured range, or if it is done as an average over the measured range. > Please provide a definition or a reference. Well, we've mostly been using it as an average. A root mean square to be precise. We've modified one of the paragraphs to read as follows: The audio level header extension only carries the level of the audio in the RTP payload of the packet it is associated with, with no long-term averaging or smoothing applied. That level is measured as a root mean square of all the samples in the measured range. We hope that this text, combined with the reference implementation should clear all doubts. However, to be perfectly honest, I am not completely convinced that we should specify this. Maybe we could have this as RECOMMENDED leaving the door open to alternative measurement mechanisms? > 5. Section 5 and Section 3: > > I would note that the folllowing text in section 5: > The audio level header extension only carries the level of the audio > in the RTP payload of the packet it is associated with, with no long- > term averaging or smoothing applied. > > Makes it impossible for the following to be done: > Note that in some cases a mixer may be sending an RTP audio stream > that only contains audio level information and no actual audio. > Updating a (web) interface conference module may be one reason for > this to happen. > > This as there is no duration of audio indicated, only a first sample. Agreed. Text already removed as per comment 2. > 6. Section 5: > "The audio level for digital silence, for example for a muted audio > source, MAY be represented as 127 (-127 dBov), regardless of the > dynamic range of the encoded audio format." > > I don't like this MAY. To me it appears to only complicate > implementations. Either you mandate the behavior so that one can trust > sources muted by the application to always carry value 127. Or one > anyway need to have noise level detector so that one can determine when > there is signal above the noise level. One may have to have that anyway, > but I think we should consider if we want clear MUTED indication here or > not. You are right. Mandating it would probably be best. Changed to MUST. > 7. Section 6. > "Presence of the above attribute in the SDP description of a media > stream indicates that some or all RTP packets in that stream would > contain the audio level information RTP extension header." > > To me this sentence is a mix between a usage rule: > "some or all packets may contain the header extension" and a signaling > rule: The presence of the attribute indicates the usage of the audio > level header extension. > > In addition it not is the attribute per say that indicate it, it is the > attribute with the given URI is used to indicate that a particular value > is bound to identify the header extension defined in this doc. OK. Changed to: Presence of the above attribute in the SDP description of a media stream indicates that RTP packets in that stream, which contain the level extension defined in this document, will be carrying them with an ID of 7. If this doesn't work then we can simply remove it. This is, after all, only comfort text meant to assist implementors. Rules of use and signalling are inherited from 5285 anyway. > 8. Section 6. > "This speicification does not define use of the audio level extensions > in video streams. Therefore, the extension defined in this document > SHOULD NOT be advertised in anything but audio streams." > > First spelling error of specification. Fixed. > Secondly, we also have media types like text, where I also don't see a > logical mapping. Thus I wonder if this should be formulated in a way > that avoids being media specific. I also wonder if there is any point in > leaving the hole with "SHOULD NOT"? Either skip using that and formulate > that it is only defined for audio streams, or some other way? OK, so how about: This specification only defines use of the audio level extensions in audio streams. They MUST NOT be advertised with other media types such as video or text for example. > 9. Section 7: > I am missing a reference to the VBR consideration that I think contains > a much better and complete explanation to the issue with just energy > level or similar phonetic structure indicators. Added. Magnus Westerlund commented on mixer-to-client: > 1. Section 3. > "The two-byte header defined in RFC 5285 [RFC5285] may also be used." > > I think that it should be stated up front that header extensions per > definitions can be used with either of the header formats. In addition I > think one needs to separate a bit clearer what is framework and what is > the new parts. Addressed as with the mixer-to-client draft. > 2. Section 3. I think the dBov definition needs to be really clear. Yes, > the convention is amplitudes are squared when doing dB calculation. But > it is not clear if this is done for the single highest value in the > measured range, or if it is done as an average over the measured range. > Please provide a definition or a reference. Addressed as with the mixer-to-client draft. > 3. Section 5: > "The audio level for digital silence, for example for a muted audio > source, MAY be represented as 127 (-127 dBov), regardless of the > dynamic range of the encoded audio format." > > I don't like this MAY. To me it appears to only complicate > implementations. Either you mandate the behavior so that one can trust > sources muted by the application to always carry value 127. Or one > anyway need to have noise level detector so that one can determine when > there is signal above the noise level. One may have to have that anyway, > but I think we should consider if we want clear MUTED indication here or > not. Mandated as with the mixer-to-client draft. > 4. Section 3: > In addition, a flag bit (labeled V) indicates whether the encoder > believes the audio packet contains voice activity (1) or does not > (0). The voice activity detection algorithm is unspecified and left > implementation-specific. > > Would it be of interest to have an signalling parameter for an > implementation to indicate its algorithm? My personal opinion is that, if this is deemed necessary, it can probably be handled in a separate draft at a later stage. This would also allow some level of negotiation, again, if people find this necessary. Any other thoughts? > 5. Section 8.2: > I think both the encrypted header extension and the VBR audio is likely > normative references as they either is recommend solution or a > description of the issue. I don't know. Header encryption is only one way of handling this. There's also DTLS, IPsec and even VPN. So in that respect it seems to me that this method is best seen here as an example. Keith commented on mixer-to-client > Section 6. > > This speicification does not define use of the audio level extensions > in video streams. Therefore, the extension defined in this document > SHOULD NOT be advertised in anything but audio streams. > > Typo: "specification" Fixed. Keith commented on client-to-mixer > Section 3. > > Implementations MAY choose to measure audio levels prior to encoding > them in the payload carried in the RTP payload, e.g. on raw linear > PCM input. > > "MAY" defines an option. Is this really defining an option or just indicating a possibility, as in "can". Also raised by Magnus. Reply above. Cheers, Emil From xiajinwei@huawei.com Mon Jul 4 18:34:31 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1861C1F0C62 for ; Mon, 4 Jul 2011 18:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMJuKQ5ncvqh for ; Mon, 4 Jul 2011 18:34:30 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 1A01A1F0C96 for ; Mon, 4 Jul 2011 18:34:30 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LNU0054E70E31@szxga03-in.huawei.com> for avtext@ietf.org; Tue, 05 Jul 2011 09:33:51 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LNU00EZ570EW4@szxga03-in.huawei.com> for avtext@ietf.org; Tue, 05 Jul 2011 09:33:50 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml207-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ABT11289; Tue, 05 Jul 2011 09:33:49 +0800 (CST) Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 05 Jul 2011 09:33:47 +0800 Received: from x65217 (10.138.41.84) by smtpscn.huawei.com (10.82.67.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 05 Jul 2011 09:33:48 +0800 Date: Tue, 05 Jul 2011 09:33:48 +0800 From: Jinwei Xia In-reply-to: <005e01cc3a78$6ee88340$4cb989c0$%roni@huawei.com> X-Originating-IP: [10.138.41.84] To: 'Roni Even' , "'DRAGE, Keith (Keith)'" , avtext@ietf.org Message-id: <001601cc3ab3$96abf2f0$54298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Thread-index: Acwnh4FBkyy8xdLASmWhGVojp31o8wJ/8+8wAjwfCeAADsRhIA== X-CFilter-Loop: Reflected Subject: Re: [avtext] Consensus call on RTP Splicing direction forward X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 01:34:31 -0000 Hi, I am also eager to know the direction of next step work. Thank your understanding. Jinwei > -----Original Message----- > From: avtext-bounces@ietf.org=20 > [mailto:avtext-bounces@ietf.org] On Behalf Of Roni Even > Sent: Tuesday, July 05, 2011 2:30 AM > To: 'DRAGE, Keith (Keith)'; avtext@ietf.org > Subject: Re: [avtext] Consensus call on RTP Splicing direction forward >=20 > Hi, > I think that Dave and Colin who had interest in this work=20 > both said that if non detectability is not an issue than the=20 > mixer approach make sense, the CSRC can help with monitoring=20 > while on the other side the splicer can make it harder to=20 > detect by not sending the CSRC. > I think that it will be good to update the current draft with=20 > the requirements based on the discussion and do the mixer as=20 > first step. >=20 > We can later look if and how to address the best way to=20 > support a good enough non detectable case. >=20 > Roni >=20 > > -----Original Message----- > > From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On=20 > > Behalf Of DRAGE, Keith (Keith) > > Sent: Thursday, June 23, 2011 12:25 PM > > To: avtext@ietf.org > > Subject: Re: [avtext] Consensus call on RTP Splicing=20 > direction forward > >=20 > > [As WG chair] > >=20 > > Magnus sent out this call a couple of weeks back and we=20 > haven't seen=20 > > very many responses. > >=20 > > If you have not already responded, please do so. > >=20 > > Regards > >=20 > > Keith > >=20 > > > -----Original Message----- > > > From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On > > Behalf > > > Of Magnus Westerlund > > > Sent: 10 June 2011 17:00 > > > To: avtext@ietf.org > > > Subject: [avtext] Consensus call on RTP Splicing direction forward > > > > > > Hi, > > > > > > We have had this ongoing discussion on the mailing list around the > > RTP > > > Splicing and the pro-and-cons for two major solutions. To=20 > try to get > > to > > > some decision on what the WG should focus on I would like=20 > to ask the > > WG > > > to indicate their preference for what should be done here. The > > options > > > are three on a high level. And this is for an=20 > informational document=20 > > > that explains how you use the existing RTP features to accomplish=20 > > > splicing. > > > > > > A) Focus only on RTP Translator based solution > > > > > > B) Focus only on RTP Mixer based solution > > > > > > C) Define both Mixer and Translator based solutions. > > > > > > A) is pretty well described in the individual draft: > > >=20 > https://datatracker.ietf.org/doc/draft-xia-avtext-splicing-for-rtp/ > > > > > > The trade-offs and limiations of A and B has been fairly well > > discussed > > > in the following email list discussion. > > > http://www.ietf.org/mail-archive/web/avtext/current/msg00046.html > > > > > > So if you aren't familiar with the topic already please review the > > above > > > and then indicate your position no later than the 26th of June. > > > > > > Independently of the choice that solution will have to discuss the > > pros > > > and cons of that method and what properties it has. > > > > > > Cheers > > > > > > Magnus Westerlund > > > > > >=20 > -------------------------------------------------------------------- > > > - > > - > > > Multimedia Technologies, Ericsson Research EAB/TVM > > >=20 > -------------------------------------------------------------------- > > > - > > - > > > Ericsson AB | Phone +46 10 7148287 > > > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > > > SE-164 80 Stockholm, Sweden| mailto:=20 > magnus.westerlund@ericsson.com > > >=20 > -------------------------------------------------------------------- > > > - > > - > > > > > > _______________________________________________ > > > avtext mailing list > > > avtext@ietf.org > > > https://www.ietf.org/mailman/listinfo/avtext > > _______________________________________________ > > avtext mailing list > > avtext@ietf.org > > https://www.ietf.org/mailman/listinfo/avtext >=20 > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From keith.drage@alcatel-lucent.com Wed Jul 6 07:23:57 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23AAD21F85FB for ; Wed, 6 Jul 2011 07:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DEVmXiTB8TjP for ; Wed, 6 Jul 2011 07:23:56 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 135F821F85FF for ; Wed, 6 Jul 2011 07:23:55 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p66ENiPP011832 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 6 Jul 2011 16:23:54 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Wed, 6 Jul 2011 16:23:44 +0200 From: "DRAGE, Keith (Keith)" To: "avtext@ietf.org" Date: Wed, 6 Jul 2011 16:23:43 +0200 Thread-Topic: WGLC for draft-ietf-avtext-mixer-to-client-audio-level-03 Thread-Index: Acw754Yn7pPN7TuEQcKIjxIWevbr8g== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Cc: "draft-ietf-avtext-mixer-to-client-audio-level@tools.ietf.org" Subject: [avtext] WGLC for draft-ietf-avtext-mixer-to-client-audio-level-03 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 14:23:57 -0000 (As WG cochair) This is to announce a Working Group Last Call on=20 draft-ietf-avtext-mixer-to-client-audio-level-03 (Do note this is two parallel calls on two related drafts) Please review and supply comments by Wednesday 20th July 2011. It is helpful if you make some attempt to categorise uour comments, e.g. Ma= jor, Minor technical, Editorial. If you review the document and find no issue with the current version, then= it is helpful to send a mail to the WG chairs saying so as this helps us a= ssess the level of review. Regards Keith P.S. The intent is to allow any identified show stoppers to be discussed at= the face to face in Quebec, so the earlier such comments are made the bett= er. From keith.drage@alcatel-lucent.com Wed Jul 6 07:24:05 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3307D21F861D for ; Wed, 6 Jul 2011 07:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNm7VAs7R2WQ for ; Wed, 6 Jul 2011 07:24:04 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE8521F8606 for ; Wed, 6 Jul 2011 07:24:04 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p66ENrVG032470 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 6 Jul 2011 16:24:01 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 6 Jul 2011 16:23:45 +0200 From: "DRAGE, Keith (Keith)" To: "avtext@ietf.org" Date: Wed, 6 Jul 2011 16:22:11 +0200 Thread-Topic: WGLC for draft-ietf-avtext-client-to-mixer-audio-level-03 Thread-Index: Acw754oCukrRz8mKRv6+C/Uib2y4hg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Cc: "draft-ietf-avtext-client-to-mixer-audio-level@tools.ietf.org" Subject: [avtext] WGLC for draft-ietf-avtext-client-to-mixer-audio-level-03 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 14:24:05 -0000 (As WG cochair) This is to announce a Working Group Last Call on=20 draft-ietf-avtext-client-to-mixer-audio-level-03 (Do note this is two parallel calls on two related drafts) Please review and supply comments by Wednesday 20th July 2011. It is helpful if you make some attempt to categorise uour comments, e.g. Ma= jor, Minor technical, Editorial. If you review the document and find no issue with the current version, then= it is helpful to send a mail to the WG chairs saying so as this helps us a= ssess the level of review. Regards Keith P.S. The intent is to allow any identified show stoppers to be discussed at= the face to face in Quebec, so the earlier such comments are made the bett= er. From internet-drafts@ietf.org Mon Jul 11 13:42:10 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91BBA11E8236; Mon, 11 Jul 2011 13:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3MO6OywTR33h; Mon, 11 Jul 2011 13:42:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3296011E81C2; Mon, 11 Jul 2011 13:42:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110711204210.20962.96313.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 13:42:10 -0700 Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-multiple-clock-rates-01.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 20:42:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Extensions Work= ing Group of the IETF. Title : Support for multiple clock rates in an RTP session Author(s) : Marc Petit-Huguenin Filename : draft-ietf-avtext-multiple-clock-rates-01.txt Pages : 10 Date : 2011-07-11 This document clarifies the RTP specification when different clock rates are used in an RTP session. It also provides guidance on how to interoperate with legacy RTP implementations that use multiple clock rates. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avtext-multiple-clock-rates-= 01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtext-multiple-clock-rates-0= 1.txt From petithug@acm.org Mon Jul 11 13:46:50 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF40121F8BD5 for ; Mon, 11 Jul 2011 13:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.5 X-Spam-Level: X-Spam-Status: No, score=-102.5 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zpyz03eAylCa for ; Mon, 11 Jul 2011 13:46:49 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 16E4F11E8257 for ; Mon, 11 Jul 2011 13:46:43 -0700 (PDT) Received: from [IPv6:2001:55c:4c15:5f80:213:d4ff:fe04:3e08] (unknown [IPv6:2001:55c:4c15:5f80:213:d4ff:fe04:3e08]) by implementers.org (Postfix) with ESMTPS id EA8AE2199E; Mon, 11 Jul 2011 22:45:20 +0200 (CEST) Message-ID: <4E1B612F.8010206@acm.org> Date: Mon, 11 Jul 2011 13:46:39 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110626 Iceowl/1.0b2 Icedove/3.1.11 MIME-Version: 1.0 To: Magnus Westerlund References: <20110607073530.16031.92596.idtracker@ietfa.amsl.com> <4DF60B9E.90909@ericsson.com> In-Reply-To: <4DF60B9E.90909@ericsson.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "avtext@ietf.org" Subject: Re: [avtext] Comments on draft-ietf-avtext-multiple-clock-rates-00.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 20:46:50 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I just released a new version of this draft that incorporate the two first points below. Unfortunately, and I apologize for that, I did not had the time to work on the two remaining points. I will have more time to work on that before Taipei and we should still be on time for the submission in December as per the charter. On 06/13/2011 06:07 AM, Magnus Westerlund wrote: > Hi, > > I have reviewed this WG 00 version, and thanks the other for taking my > comments into consideration in the previous version. > > I have some additional comments and suggestions for improvements. > However I think it is important that we get input from the WG on these > questions. > > The below are my views as an individual, not WG chair. > > 1. Section 1: > "This document first tries to list in Section 2 and subsections all > the various algorithms used by existing RTP implementations." > > Wouldn't it better to state that this section "lists all known > algorithms used in RTP implementations of the time of writing." Or > something like this. To avoid using "all" without a qualifier. > > 2. Section 4.1: >> Each time the clock rate changes, the start_offset and capture_start >> values are calculated with the following formulas: >> >> start_offset = (capture_time - capture_start) * previous_clock_rate >> capture_start = capture_time > > I think it is important to elaborate on what "capture_time" is in this > formula. That it is the capture time of the first instant the new > timestamp rate is going to be used. > > 3. Section 4.1: > > I am still not quite happy about these recommendations: > > An RTP Sender with RTCP turned on MUST use a different SSRC for each > different clock rate. > > Because in more advanced applications like video conferencing with > centralized mixing the impact of switching SSRC is so big. It can > involved the following mechanisms that will be effected: > > - Any connection to application logic, side boards etc. > - The issue that who a SSRC becomes unknown until an CNAME is > distributed to everyone that needs to know, that include speaker > indication using CSRC. > - RTP retransmission, that needs to use another SSRC and then acquire > the binding using CNAME is SSRC multiplexed. > - The fact that switching and "BYE" an SSRC prevents an receiver to > request retransmission of the packet that has been lost but not yet > delivered when the SSRC is given up. > - TMMBR limiations set on a SSRC value that needs to be transfered to > the new one. > > So I think "MUST" is way to strict as rule. Especially as there are > rules that make this problem much less an issue as soon as > implementations has been updated. But that will be a bit more work as we > should also include clarifications and fixes on the found issues around > RTCP clock rate switches. And recommendations for how to avoid the issue > in the future. > > 4. Section 4.2: > > D(i,j) = (arrival_time_j * clock_rate_i - timestamp_j) - > (arrival_time_i * clock_rate_i - timestamp_i) > > > I think it is important that this is expanded a bit. > > First of all that we will only avoid an error if "j" is the first packet > for the new Timestamp Rate. Thus we should likely discuss how one gets > this value to be a sane one in any RTCP report. Likely by doing the > calculation twice, one up to the switch and then a second time from the > switch forward. > > If one doesn't get the packet which is first of the switch, then I think > we should consider if we need to discuss how one use the two nearest SRs > to calculate the actual point of the switch. > > If my math hasn't gone wrong I think > > NTP_of_Switch = (TS_j-TS_i+ R_i*N_i - R_j*N_j)/(R_i-R_j) > > Where i is an RTCP SR prior to the switch and j is an RTCP SR after the > switch and TS is the timestamp value, N the NTP value and R the > timestamp rate at that moment. > > What I don't know is how robust this is to a non-consistent method of > timestamp value switch. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk4bYS0ACgkQ9RoMZyVa61dr+wCfXzdHZFbSujt/M/Uctj2Mucat 8GsAn3HFCjlc2VEaSJOa+8Ke2abr0kd7 =sS1Z -----END PGP SIGNATURE----- From kpfleming@digium.com Tue Jul 12 15:05:02 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A94BF1F0C38 for ; Tue, 12 Jul 2011 15:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tKnKYla1Zskl for ; Tue, 12 Jul 2011 15:04:57 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id 764621F0C36 for ; Tue, 12 Jul 2011 15:04:46 -0700 (PDT) Received: from zimbra.digium.internal ([10.24.55.203] helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1Qgl4P-0002SZ-Nz for avtext@ietf.org; Tue, 12 Jul 2011 17:04:45 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id BBFE7D82A3 for ; Tue, 12 Jul 2011 17:04:45 -0500 (CDT) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJYRwRuyh5+7 for ; Tue, 12 Jul 2011 17:04:45 -0500 (CDT) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id D84D4D8024 for ; Tue, 12 Jul 2011 17:04:44 -0500 (CDT) Message-ID: <4E1CC4FC.1010909@digium.com> Date: Tue, 12 Jul 2011 17:04:44 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: avtext@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [avtext] WGLC for draft-ietf-avtext-client-to-mixer-audio-level-03 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 22:05:02 -0000 On 07/06/2011 09:22 AM, DRAGE, Keith (Keith) wrote: > (As WG cochair) > > This is to announce a Working Group Last Call on > > draft-ietf-avtext-client-to-mixer-audio-level-03 > > (Do note this is two parallel calls on two related drafts) > > Please review and supply comments by Wednesday 20th July 2011. > > It is helpful if you make some attempt to categorise uour comments, e.g. Major, Minor technical, Editorial. > > If you review the document and find no issue with the current version, then it is helpful to send a mail to the WG chairs saying so as this helps us assess the level of review. Editorial: Paragraph 2 of Section 3 - "using the one or the two-byte header" seems to be a bit hard to parse. Maybe "using either the one-byte or the two-byte header format" would be better? Last paragraph of Section 3 - 'noice' should be 'noise' Minor technical: Should there be any text included to indicate that a mixer receiving RTP packets with these header extensions should recognize that an SSRC change means that the client's behavior regarding this extension may also change? For example, when the session is first established, the client may be using the 'V' flag to reliably indicate the presence of voice in the audio payload... but after an SSRC change to a new client source, the 'V' flag may no longer be used at all. The 'design guidance' section does warn implementors that they may need to double-check the audio level (and 'V' flags) reported by the client, but a specific warning that this will almost always be necessary after an SSRC change might be useful as well. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From kpfleming@digium.com Tue Jul 12 15:18:36 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0CF211E808D for ; Tue, 12 Jul 2011 15:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZwJ3CXwtKd23 for ; Tue, 12 Jul 2011 15:18:31 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id 853ED21F8C28 for ; Tue, 12 Jul 2011 15:18:31 -0700 (PDT) Received: from zimbra.digium.internal ([10.24.55.203] helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1QglHj-0002cs-8c for avtext@ietf.org; Tue, 12 Jul 2011 17:18:31 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 4246ED82A3 for ; Tue, 12 Jul 2011 17:18:31 -0500 (CDT) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9j-49QgQp5dW for ; Tue, 12 Jul 2011 17:18:30 -0500 (CDT) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id C9094D8024 for ; Tue, 12 Jul 2011 17:18:30 -0500 (CDT) Message-ID: <4E1CC836.4060803@digium.com> Date: Tue, 12 Jul 2011 17:18:30 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: avtext@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [avtext] WGLC for draft-ietf-avtext-mixer-to-client-audio-level-03 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 22:18:36 -0000 On 07/06/2011 09:23 AM, DRAGE, Keith (Keith) wrote: > (As WG cochair) > > This is to announce a Working Group Last Call on > > draft-ietf-avtext-mixer-to-client-audio-level-03 > > (Do note this is two parallel calls on two related drafts) > > Please review and supply comments by Wednesday 20th July 2011. > > It is helpful if you make some attempt to categorise uour comments, e.g. Major, Minor technical, Editorial. > > If you review the document and find no issue with the current version, then it is helpful to send a mail to the WG chairs saying so as this helps us assess the level of review. Editorial: Paragraph 1 of Section 3: no comma necessary after "More advanced mechanisms" Paragraph 2 of Section 4 - "using the one or the two-byte header" seems to be a bit hard to parse. Maybe "using either the one-byte or the two-byte header format" would be better? Paragraph 3 of Section 4 - 'adn' should be 'and' Paragraph 4 of Section 4 - 'noice' should be 'noise' -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From keith.drage@alcatel-lucent.com Wed Jul 13 06:29:32 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5F4A11E80EC for ; Wed, 13 Jul 2011 06:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.199 X-Spam-Level: X-Spam-Status: No, score=-106.199 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L1ViJ15rsp-p for ; Wed, 13 Jul 2011 06:29:32 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by ietfa.amsl.com (Postfix) with ESMTP id 74D9311E80E9 for ; Wed, 13 Jul 2011 06:29:27 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p6DDSq7M010286 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 13 Jul 2011 15:29:25 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 13 Jul 2011 15:29:24 +0200 From: "DRAGE, Keith (Keith)" To: "avtext@ietf.org" Date: Wed, 13 Jul 2011 15:29:23 +0200 Thread-Topic: IETF#81 - AVTEXT agenda Thread-Index: AcxBYODbTs80dxYqS+OqLYQ1ZmwBiw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Subject: [avtext] IETF#81 - AVTEXT agenda X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 13:29:33 -0000 The agenda is currently as follows (please note that times may be adjusted = between now and the meeting, also please note that the slot is always subje= ct to change): Audio/Video Transport Extensions (avtext) =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=3D=3D=3D=3D=3D=3D=3D=3D=3D WEDNESDAY, July 27, 2011 1510-1610 Afternoon Session II 205 ABC Personnel =20 Chairs: Magnus Westerlund Keith Drage =20 Area Director: Gonzalo Camarillo =20 Mailing List =20 Address: avtext@ietf.org=20 To Subscribe: https://www.ietf.org/mailman/listinfo/avtext=20 Archive: http://www.ietf.org/mail-archive/web/avtext/=20 Jabber Chat =20 Room Address: xmpp:avtext@jabber.ietf.org=20 Logs: http://jabber.ietf.org/logs/avtext/=20 Agenda ------ 15:10 - 15:20 Agenda Bash and Status=09 WG chairs 15:20 - 15:40 Audio Levels =09 Emil Ivov / Jonathan Lennox Issues arising from WG last call draft-ietf-avtext-client-to-mixer-audio-level-03 draft-ietf-avtext-mixer-to-client-audio-level-03 15:40 - 15:50 Splicing =09 Jinwei Xia Direction forward draft-xia-avtext-splicing-for-rtp-00 15:50 - 16:05 IEEE 1588/802.1AS Synchronisation for RTP Streams Aidan Williams Of interest to working group? draft-williams-avtext-avbsync-01 16:05 - 16:10 Not allocated 16:10 Close The following documents will not be separately discussed although comments = are always welcome on the mailing list. We need reviewers for draft-ietf-av= text-rams-scenarios-00 draft-ietf-avtext-multiple-clock-rates-01 draft-ietf-avtext-rams-scenarios-00 From keith.drage@alcatel-lucent.com Wed Jul 13 06:31:36 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5586811E80E9 for ; Wed, 13 Jul 2011 06:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.206 X-Spam-Level: X-Spam-Status: No, score=-106.206 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04lzMEV8Jx9g for ; Wed, 13 Jul 2011 06:31:36 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1FB21F8789 for ; Wed, 13 Jul 2011 06:31:35 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p6DDTWhZ027262 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 13 Jul 2011 15:31:29 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 13 Jul 2011 15:31:20 +0200 From: "DRAGE, Keith (Keith)" To: "avtext@ietf.org" Date: Wed, 13 Jul 2011 15:31:19 +0200 Thread-Topic: WGLC for draft-ietf-avtext-client-to-mixer-audio-level-03 Thread-Index: Acw754oCukrRz8mKRv6+C/Uib2y4hgFeYIyw Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: "draft-ietf-avtext-client-to-mixer-audio-level@tools.ietf.org" Subject: Re: [avtext] WGLC for draft-ietf-avtext-client-to-mixer-audio-level-03 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 13:31:36 -0000 A reminder of this WGLC - please review as we'd like to get these out of th= e door soon after IETF#81 Regards Keith > -----Original Message----- > From: DRAGE, Keith (Keith) > Sent: 06 July 2011 15:22 > To: 'avtext@ietf.org' > Cc: 'draft-ietf-avtext-client-to-mixer-audio-level@tools.ietf.org' > Subject: WGLC for draft-ietf-avtext-client-to-mixer-audio-level-03 >=20 > (As WG cochair) >=20 > This is to announce a Working Group Last Call on >=20 > draft-ietf-avtext-client-to-mixer-audio-level-03 >=20 > (Do note this is two parallel calls on two related drafts) >=20 > Please review and supply comments by Wednesday 20th July 2011. >=20 > It is helpful if you make some attempt to categorise uour comments, e.g. > Major, Minor technical, Editorial. >=20 > If you review the document and find no issue with the current version, > then it is helpful to send a mail to the WG chairs saying so as this help= s > us assess the level of review. >=20 > Regards >=20 > Keith >=20 > P.S. The intent is to allow any identified show stoppers to be discussed > at the face to face in Quebec, so the earlier such comments are made the > better. From keith.drage@alcatel-lucent.com Wed Jul 13 06:32:11 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFEB021F861D for ; Wed, 13 Jul 2011 06:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.212 X-Spam-Level: X-Spam-Status: No, score=-106.212 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTGNf0zgZRmP for ; Wed, 13 Jul 2011 06:32:11 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 296CA21F85AB for ; Wed, 13 Jul 2011 06:32:10 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p6DDUrSc028171 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 13 Jul 2011 15:32:08 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Wed, 13 Jul 2011 15:31:42 +0200 From: "DRAGE, Keith (Keith)" To: "avtext@ietf.org" Date: Wed, 13 Jul 2011 15:31:41 +0200 Thread-Topic: WGLC for draft-ietf-avtext-mixer-to-client-audio-level-03 Thread-Index: Acw754Yn7pPN7TuEQcKIjxIWevbr8gFeaUUg Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: "draft-ietf-avtext-mixer-to-client-audio-level@tools.ietf.org" Subject: Re: [avtext] WGLC for draft-ietf-avtext-mixer-to-client-audio-level-03 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 13:32:11 -0000 A reminder of this WGLC - please review as we'd like to get these out of th= e door soon after IETF#81 Regards Keith > -----Original Message----- > From: DRAGE, Keith (Keith) > Sent: 06 July 2011 15:18 > To: avtext@ietf.org > Cc: 'draft-ietf-avtext-mixer-to-client-audio-level@tools.ietf.org' > Subject: WGLC for draft-ietf-avtext-mixer-to-client-audio-level-03 >=20 > (As WG cochair) >=20 > This is to announce a Working Group Last Call on >=20 > draft-ietf-avtext-mixer-to-client-audio-level-03 >=20 > (Do note this is two parallel calls on two related drafts) >=20 > Please review and supply comments by Wednesday 20th July 2011. >=20 > It is helpful if you make some attempt to categorise uour comments, e.g. > Major, Minor technical, Editorial. >=20 > If you review the document and find no issue with the current version, > then it is helpful to send a mail to the WG chairs saying so as this help= s > us assess the level of review. >=20 > Regards >=20 > Keith >=20 > P.S. The intent is to allow any identified show stoppers to be discussed > at the face to face in Quebec, so the earlier such comments are made the > better. From magnus.westerlund@ericsson.com Wed Jul 13 07:38:57 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6758D21F89CC for ; Wed, 13 Jul 2011 07:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.22 X-Spam-Level: X-Spam-Status: No, score=-106.22 tagged_above=-999 required=5 tests=[AWL=-0.221, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8oaCAuFQDnS5 for ; Wed, 13 Jul 2011 07:38:56 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9FF21F89BE for ; Wed, 13 Jul 2011 07:38:56 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-b1-4e1dadfe8b7f Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 33.B1.20773.EFDAD1E4; Wed, 13 Jul 2011 16:38:54 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Wed, 13 Jul 2011 16:38:54 +0200 Message-ID: <4E1DADFD.7060309@ericsson.com> Date: Wed, 13 Jul 2011 16:38:53 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "avtext@ietf.org" References: In-Reply-To: X-Enigmail-Version: 1.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-avtext-mixer-to-client-audio-level@tools.ietf.org" Subject: Re: [avtext] WGLC for draft-ietf-avtext-mixer-to-client-audio-level-03 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 14:38:57 -0000 Hi, I have reviewed this version and I think it is in good shape and ready for publication. I have one editorial comment. 1. Editorial Section 4. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID | len=2 |0| level 1 |0| level 2 |0| level 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The bit numbering isn't aligned and I guess that may have helped masking an issue in that the ID+Len fields are 9 bits, and that level 3 is only 6. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Wed Jul 13 08:22:22 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C75BA11E811E for ; Wed, 13 Jul 2011 08:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.511 X-Spam-Level: X-Spam-Status: No, score=-106.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5V6IWQydkv9C for ; Wed, 13 Jul 2011 08:22:21 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id BA2C921F8797 for ; Wed, 13 Jul 2011 08:22:16 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-83-4e1db827bb7b Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 60.76.20773.728BD1E4; Wed, 13 Jul 2011 17:22:15 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Wed, 13 Jul 2011 17:22:15 +0200 Message-ID: <4E1DB825.80700@ericsson.com> Date: Wed, 13 Jul 2011 17:22:13 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "avtext@ietf.org" , "draft-ietf-avtext-client-to-mixer-audio-level@tools.ietf.org" References: In-Reply-To: X-Enigmail-Version: 1.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [avtext] WGLC for draft-ietf-avtext-client-to-mixer-audio-level-03 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 15:22:22 -0000 Hi, I have reviewed this new version and have the following comments: >From my previous review that I don't believe got answered. 1. Section 3: In addition, a flag bit (labeled V) indicates whether the encoder believes the audio packet contains voice activity (1) or does not (0). The voice activity detection algorithm is unspecified and left implementation-specific. Would it be of interest to have an signalling parameter for an implementation to indicate its algorithm? The reason I am coming back to this, is that if you don't know if it is used, how can you then use the V bit. Is V=0 because there is no voice activity or because there is no VAD implemented. One can also expand the question to what a media sender without VAD should set as value for V. 2. Section 6. "One solution is header extension encryption [I-D.lennox-avtcore-srtp-encrypted-header-ext]." I think the formulation of also pointing to lower layer solution is appropriate. If one uses DTLS (without SRTP based media protection), TLS, IPsec etc then this information would not be visible. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From musgravepj@gmail.com Thu Jul 14 10:58:47 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 569FB21F8CA2 for ; Thu, 14 Jul 2011 10:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kz5lvCXw5+u7 for ; Thu, 14 Jul 2011 10:58:46 -0700 (PDT) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id 3678D11E8098 for ; Thu, 14 Jul 2011 10:58:43 -0700 (PDT) Received: by fxe4 with SMTP id 4so1655099fxe.27 for ; Thu, 14 Jul 2011 10:58:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4RftLsQ/fAEMtMD28ehxAoVL2S3Q922gxPoqQZA2Gzs=; b=M6uDzppDtHdYSPturM3m9PWR1zZ1UttNfsNJxUygLr5sl6c7T8Ra6gETxroE8E5hWM aX0ZPqieEIsbRp1dOmBvNZ6SNchnnFiAvTvzNrhnTlABAAGPDBRwsuDn4KD8YRLXlwqK /LKKue43SOaD3zUX/FxVRYBgqhntTAHY/QJwg= MIME-Version: 1.0 Received: by 10.223.6.198 with SMTP id a6mr3868968faa.128.1310666322132; Thu, 14 Jul 2011 10:58:42 -0700 (PDT) Received: by 10.223.103.71 with HTTP; Thu, 14 Jul 2011 10:58:42 -0700 (PDT) In-Reply-To: References: Date: Thu, 14 Jul 2011 13:58:42 -0400 Message-ID: From: Peter Musgrave To: "DRAGE, Keith (Keith)" Content-Type: multipart/alternative; boundary=000e0cd3ff928cbf3204a80b489b Cc: "avtext@ietf.org" , "draft-ietf-avtext-mixer-to-client-audio-level@tools.ietf.org" Subject: Re: [avtext] WGLC for draft-ietf-avtext-mixer-to-client-audio-level-03 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 17:58:47 -0000 --000e0cd3ff928cbf3204a80b489b Content-Type: text/plain; charset=ISO-8859-1 HI, I have read the latest copy and do not have any issues. Regards, Peter Musgrave On Wed, Jul 13, 2011 at 9:31 AM, DRAGE, Keith (Keith) < keith.drage@alcatel-lucent.com> wrote: > A reminder of this WGLC - please review as we'd like to get these out of > the door soon after IETF#81 > > Regards > > Keith > > > -----Original Message----- > > From: DRAGE, Keith (Keith) > > Sent: 06 July 2011 15:18 > > To: avtext@ietf.org > > Cc: 'draft-ietf-avtext-mixer-to-client-audio-level@tools.ietf.org' > > Subject: WGLC for draft-ietf-avtext-mixer-to-client-audio-level-03 > > > > (As WG cochair) > > > > This is to announce a Working Group Last Call on > > > > draft-ietf-avtext-mixer-to-client-audio-level-03 > > > > (Do note this is two parallel calls on two related drafts) > > > > Please review and supply comments by Wednesday 20th July 2011. > > > > It is helpful if you make some attempt to categorise uour comments, e.g. > > Major, Minor technical, Editorial. > > > > If you review the document and find no issue with the current version, > > then it is helpful to send a mail to the WG chairs saying so as this > helps > > us assess the level of review. > > > > Regards > > > > Keith > > > > P.S. The intent is to allow any identified show stoppers to be discussed > > at the face to face in Quebec, so the earlier such comments are made the > > better. > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext > --000e0cd3ff928cbf3204a80b489b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable HI,=A0

I have read the latest copy and do not have any i= ssues.=A0

Regards,=A0

Pet= er Musgrave

On Wed, Jul 13, 2011 at 9:31 = AM, DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.com> wrote:<= br>
A reminder of this WGLC - please review as = we'd like to get these out of the door soon after IETF#81

Regards

Keith

> -----Original Message-----
> From: DRAGE, Keith (Keith)
> Sent: 06 July 2011 15:18
> To: avtext@ietf.org
> Cc: 'draft-ietf-avtext-mixer-to-client-audio-level@tools.ietf= .org'
> Subject: WGLC for draft-ietf-avtext-mixer-to-client-audio-level-03
>
> (As WG cochair)
>
> This is to announce a Working Group Last Call on
>
> draft-ietf-avtext-mixer-to-client-audio-level-03
>
> (Do note this is two parallel calls on two related drafts)
>
> Please review and supply comments by Wednesday 20th July 2011.
>
> It is helpful if you make some attempt to categorise uour comments, e.= g.
> Major, Minor technical, Editorial.
>
> If you review the document and find no issue with the current version,=
> then it is helpful to send a mail to the WG chairs saying so as this h= elps
> us assess the level of review.
>
> Regards
>
> Keith
>
> P.S. The intent is to allow any identified show stoppers to be discuss= ed
> at the face to face in Quebec, so the earlier such comments are made t= he
> better.
_______________________________________________

--000e0cd3ff928cbf3204a80b489b-- From jonathan@vidyo.com Thu Jul 14 15:49:54 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 186D721F8B25 for ; Thu, 14 Jul 2011 15:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J5jAGH+ucDQ2 for ; Thu, 14 Jul 2011 15:49:53 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 9730621F8B20 for ; Thu, 14 Jul 2011 15:49:53 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 2AD0F416EAC; Thu, 14 Jul 2011 18:49:53 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB028.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 9C03E416EB7; Thu, 14 Jul 2011 18:49:52 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB028.mail.lan ([10.110.17.28]) with mapi; Thu, 14 Jul 2011 18:48:39 -0400 From: Jonathan Lennox To: Magnus Westerlund Date: Thu, 14 Jul 2011 18:49:47 -0400 Thread-Topic: [avtext] WGLC for draft-ietf-avtext-client-to-mixer-audio-level-03 Thread-Index: AcxCeCU8MGYF6AWDQVCVJZpoz1rxyQ== Message-ID: <93F75C14-BCA5-498E-969A-96AC9AB5373C@vidyo.com> References: <4E1DB825.80700@ericsson.com> In-Reply-To: <4E1DB825.80700@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-avtext-client-to-mixer-audio-level@tools.ietf.org" , "avtext@ietf.org" Subject: Re: [avtext] WGLC for draft-ietf-avtext-client-to-mixer-audio-level-03 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 22:49:54 -0000 On Jul 13, 2011, at 11:22 AM, Magnus Westerlund wrote: > Hi, >=20 > I have reviewed this new version and have the following comments: >=20 > From my previous review that I don't believe got answered. >=20 > 1. Section 3: > In addition, a flag bit (labeled V) indicates whether the encoder > believes the audio packet contains voice activity (1) or does not > (0). The voice activity detection algorithm is unspecified and left > implementation-specific. >=20 > Would it be of interest to have an signalling parameter for an > implementation to indicate its algorithm? I'm not sure whether the algorithm, specifically, is useful (it'd require e= stablishing an IANA registry of specific VAD algorithms), but I could imagi= ne that some way of indicating VAD used/not-used could be useful. An alternative would be to mandate that use of the extension implies that y= ou're sending meaningful VAD. > 2. Section 6. > "One solution is header > extension encryption [I-D.lennox-avtcore-srtp-encrypted-header-ext]." >=20 > I think the formulation of also pointing to lower layer solution is > appropriate. If one uses DTLS (without SRTP based media protection), > TLS, IPsec etc then this information would not be visible. Okay. The intention is to follow the same general pattern as srtp-not-mand= atory, so we'll see if we can re-use some language from there, and also ref= erence it. -- Jonathan Lennox jonathan@vidyo.com From magnus.westerlund@ericsson.com Fri Jul 15 07:01:58 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7456E21F8770 for ; Fri, 15 Jul 2011 07:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.523 X-Spam-Level: X-Spam-Status: No, score=-106.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pTahhXzINJCf for ; Fri, 15 Jul 2011 07:01:58 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 7A2A921F8766 for ; Fri, 15 Jul 2011 07:01:53 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-a7-4e204850b76c Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 11.B3.09774.058402E4; Fri, 15 Jul 2011 16:01:52 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Fri, 15 Jul 2011 16:01:51 +0200 Message-ID: <4E20484B.30009@ericsson.com> Date: Fri, 15 Jul 2011 16:01:47 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Jonathan Lennox References: <4E1DB825.80700@ericsson.com> <93F75C14-BCA5-498E-969A-96AC9AB5373C@vidyo.com> In-Reply-To: <93F75C14-BCA5-498E-969A-96AC9AB5373C@vidyo.com> X-Enigmail-Version: 1.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-avtext-client-to-mixer-audio-level@tools.ietf.org" , "avtext@ietf.org" Subject: Re: [avtext] WGLC for draft-ietf-avtext-client-to-mixer-audio-level-03 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 14:01:58 -0000 On 2011-07-15 00:49, Jonathan Lennox wrote: > > On Jul 13, 2011, at 11:22 AM, Magnus Westerlund wrote: > >> Hi, >> >> I have reviewed this new version and have the following comments: >> >> From my previous review that I don't believe got answered. >> >> 1. Section 3: In addition, a flag bit (labeled V) indicates whether >> the encoder believes the audio packet contains voice activity (1) >> or does not (0). The voice activity detection algorithm is >> unspecified and left implementation-specific. >> >> Would it be of interest to have an signalling parameter for an >> implementation to indicate its algorithm? > > I'm not sure whether the algorithm, specifically, is useful (it'd > require establishing an IANA registry of specific VAD algorithms), > but I could imagine that some way of indicating VAD used/not-used > could be useful. > > An alternative would be to mandate that use of the extension implies > that you're sending meaningful VAD. Yes, I think signalling if a client use VAD or not would be most appropriate solution. > >> 2. Section 6. "One solution is header extension encryption >> [I-D.lennox-avtcore-srtp-encrypted-header-ext]." >> >> I think the formulation of also pointing to lower layer solution >> is appropriate. If one uses DTLS (without SRTP based media >> protection), TLS, IPsec etc then this information would not be >> visible. > > Okay. The intention is to follow the same general pattern as > srtp-not-mandatory, so we'll see if we can re-use some language from > there, and also reference it. In this case you could just copy the corresponding sentence from the mixer to client draft. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From keith.drage@alcatel-lucent.com Tue Jul 19 15:00:17 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71FE821F85EE for ; Tue, 19 Jul 2011 15:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.199 X-Spam-Level: X-Spam-Status: No, score=-106.199 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1KFQ+fkMmj5v for ; Tue, 19 Jul 2011 15:00:16 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 8269F21F85EA for ; Tue, 19 Jul 2011 15:00:16 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p6JM0BJo014819 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 20 Jul 2011 00:00:14 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Tue, 19 Jul 2011 23:59:42 +0200 From: "DRAGE, Keith (Keith)" To: "avtext@ietf.org" Date: Tue, 19 Jul 2011 23:59:41 +0200 Thread-Topic: WGLC comments on draft-ietf-avtext-client-to-mixer-audio-level-03 Thread-Index: AcxGWZHUj8Ff96BISw235MSak+L0jA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Cc: "draft-ietf-avtext-client-to-mixer-audio-level@tools.ietf.org" Subject: [avtext] WGLC comments on draft-ietf-avtext-client-to-mixer-audio-level-03 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 22:00:17 -0000 No technical issues identifies. These are primarily editorial. 1) Normative references to RFC 3550. At the moment the only reference in th= e text is in section 1, which is really meant to be a description section, = and the reference here cannot really be inferred to be normative. I have no= doubt you probably do need this as a normative reference, but it is curren= tly carried implicitly in the normative reference to RFC 5285 made at the s= tart of section 3. Why not add an explicit reference to RFC 3550 to the fir= st paragraph there. 2) Section 1 Need to remove non RFC 2119 usage of lower case "should". In a centralized Real-Time Transport Protocol (RTP) [RFC3550] audio conference, an audio mixer or forwarder receives audio streams from many or all of the conference participants. It then selectively forwards some of them to other participants in the conference. In large conferences, it is possible that such a server might be receiving a large number of streams, of which only a few should be forwarded to the other conference participants. Believed what is meant here is "...of which only a few are intended to be f= orwarded...". 3) Section 5 This appears to be intended as an informative section. Therefore use of low= er case "should" and "must" that might be mistaken for normative language a= re best avoided. Mixers and forwarders generally should not base audio forwarding decisions directly on packet-by-packet audio level information, but rather should apply some analysis of the audio levels and trends. This general rule applies whether audio levels are provided by endpoints (as defined in this document), or are calculated at a server, as would be done in the absence of this information. This section discusses several issues that mixers and forwarders may wish to take into account. (Note that this section provides design guidance only, and is not normative.) Additionally, different participants may have their audio input set differently. It may be useful to apply some sort of automatic gain control to the audio levels. There are a number of possible approaches to acheiving this, e.g. by measuring peak audio levels, by average audio levels during speech, or by measuring background audio levels (average audio level levels during non-speech). Is best rendered as: It is not desirable that mixers and forwarders base audio forwarding decisions directly on packet-by-packet audio level information, and=20 instead, better to apply some analysis of the audio levels and trends. This general rule applies whether audio levels are provided by endpoints (as defined in this document), or are calculated at a server, as would be done in the absence of this information. This section discusses several issues that mixers and forwarders may wish to take into account. (Note that this section provides design guidance only, and is not normative.) Additionally, different participants can have their audio input set differently. It can be useful to apply some sort of automatic gain control to the audio levels. There are a number of possible approaches to achieving this, e.g. by measuring peak audio levels, by average audio levels during speech, or by measuring background audio levels (average audio level levels during non-speech). Note also typo in "acheiving" 4) Section 6 A malicious endpoint could choose to set the values in this header extension falsely, so as to falsely claim that audio or voice is or is not present. It is not clear what could be gained by falsely claiming that audio is not present, but an endpoint falsely claiming that audio is present could perform a denial-of-service attack on an audio conference, so as to send silence to suppress other conference members' audio. Thus, a device relying on audio level data from untrusted endpoints SHOULD periodically audit the level information transmitted, taking appropriate corrective action if endpoints appear to be sending incorrect data. =20 Suggest a minor rewording of the requirement as follows as " if endpoints a= ppear to be sending incorrect data" cannot be part of the condition. A malicious endpoint could choose to set the values in this header extension falsely, so as to falsely claim that audio or voice is or is not present. It is not clear what could be gained by falsely claiming that audio is not present, but an endpoint falsely claiming that audio is present could perform a denial-of-service attack on an audio conference, so as to send silence to suppress other conference members' audio. If a device relies on audio level data from untrusted endpoints, then the device SHOULD periodically audit the level= =20 information transmitted, taking appropriate corrective action. This provides a level of protection against endpoints sending incorrect data.= =20 5) Section 6 (Note that as it is valid for an endpoint to choose to measure audio levels prior to encoding, some degree of discrepancy SHOULD be tolerated.) Preceding a "SHOULD" with "Note..." and putting it in parentheses is liable= to lead to lack of clarity as to whether it is normative or informative. I= suggest it is probably informative and it should be reworded accordingly. Regards Keith From keith.drage@alcatel-lucent.com Tue Jul 19 15:00:46 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 560E421F8606 for ; Tue, 19 Jul 2011 15:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.203 X-Spam-Level: X-Spam-Status: No, score=-106.203 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0uVPPyLs9kX for ; Tue, 19 Jul 2011 15:00:45 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 7508C21F85EE for ; Tue, 19 Jul 2011 15:00:45 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p6JM0iwa014998 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 20 Jul 2011 00:00:44 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Tue, 19 Jul 2011 23:59:41 +0200 From: "DRAGE, Keith (Keith)" To: "avtext@ietf.org" Date: Tue, 19 Jul 2011 23:59:40 +0200 Thread-Topic: WGLC comments on draft-ietf-avtext-mixer-to-client-audio-level-03 Thread-Index: AcxGWYhFTLxOTelQT+aB39UQPFG48Q== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Cc: "draft-ietf-avtext-mixer-to-client-audio-level@tools.ietf.org" Subject: [avtext] WGLC comments on draft-ietf-avtext-mixer-to-client-audio-level-03 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 22:00:46 -0000 No technical issues identifies. These are editorial. 1) Section 3: According to RFC 3550 [RFC3550] a mixer is expected to include in outgoing RTP packets a list of identifiers (CSRC IDs) indicating the sources that contributed to the resulting stream. The presence of such CSRC IDs allows RTP clients to determine, in a binary way, the active speaker(s) in any given moment. RTCP also provides a basic mechanism to map the CSRC IDs to user identities through the CNAME field. More advanced mechanisms, may exist depending on the signaling protocol used to establish and control a conference. In the case of the Session Initiation Protocol [RFC3261] for example, the Event Package for Conference State [RFC4575] defines a tag which binds CSRC IDs to media streams and SIP URIs. Change "may" to "can" to avoid using RFC 2119 language. According to RFC 3550 [RFC3550] a mixer is expected to include in outgoing RTP packets a list of identifiers (CSRC IDs) indicating the sources that contributed to the resulting stream. The presence of such CSRC IDs allows RTP clients to determine, in a binary way, the active speaker(s) in any given moment. RTCP also provides a basic mechanism to map the CSRC IDs to user identities through the CNAME field. More advanced mechanisms, can exist depending on the signaling protocol used to establish and control a conference. In the case of the Session Initiation Protocol [RFC3261] for example, the Event Package for Conference State [RFC4575] defines a tag which binds CSRC IDs to media streams and SIP URIs. 2) Section 3: It may sometimes happen that a conference involves more than a single mixer. In such cases each of the mixers MAY choose to relay the CSRC list and audio-level information they receive from peer mixers (as long as the total CSRC count remains below 16). Given that the maximum audio level is not precisely defined by this specification, it is likely that in such situations average audio levels would be perceptibly different for the participants located behind the different mixers. Change "may" to "can" to avoid using RFC 2119 language. It can sometimes happen that a conference involves more than a single mixer. In such cases each of the mixers MAY choose to relay the CSRC list and audio-level information they receive from peer mixers (as long as the total CSRC count remains below 16). Given that the maximum audio level is not precisely defined by this specification, it is likely that in such situations average audio levels would be perceptibly different for the participants located behind the different mixers. 3) Section 4 Audio levels in this document are defined in the same manner as is audio noise level in the RTP Payload Comfort Noise specification [RFC3389]. In the comfort noice specification, the overall magnitude of the noise level in comfort noise is encoded into the first byte of the payload, with spectral information about the noise in subsequent bytes. This specification's audio level parameter is defined so as to be identical to the comfort noise payload's noise-level byte. Typo "noice" --> "noise" 4) Section 8 Presumably "dispatch" --> "avt" or "avtext". 5) Section A.1 "singal" --> "single" 6) Section A.1 * @param overload the overload (point) of signal. * For example, overload may be {@link Byte#MAX_VALUE} * for 8-bit signed samples or {@link Short#MAX_VALUE} for * 16-bit signed samples. * Change "may" to "can" to avoid using RFC 2119 language. * @param overload the overload (point) of signal. * For example, overload can be {@link Byte#MAX_VALUE} * for 8-bit signed samples or {@link Short#MAX_VALUE} for * 16-bit signed samples. * Regards Keith From keith.drage@alcatel-lucent.com Wed Jul 20 03:21:47 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9156821F8754 for ; Wed, 20 Jul 2011 03:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.209 X-Spam-Level: X-Spam-Status: No, score=-106.209 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSWFa1gBl01C for ; Wed, 20 Jul 2011 03:21:47 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id DD11821F86E1 for ; Wed, 20 Jul 2011 03:21:40 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p6KALdxX011802 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 20 Jul 2011 12:21:39 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 20 Jul 2011 12:21:39 +0200 From: "DRAGE, Keith (Keith)" To: "avtext@ietf.org" Date: Wed, 20 Jul 2011 12:21:39 +0200 Thread-Topic: WGLC for draft-ietf-avtext-client-to-mixer-audio-level-03 and draft-ietf-avtext-mixer-to-client-audio-level-03 Thread-Index: AcxGxs/FxHx/ZbzDSl2VANo1s+o7hA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Subject: [avtext] WGLC for draft-ietf-avtext-client-to-mixer-audio-level-03 and draft-ietf-avtext-mixer-to-client-audio-level-03 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 10:21:47 -0000 (As WG cochair) We set a deadline for working group last call comments on the above two dra= fts of today. So if you still have comments in the works, please get them p= osted to the list with all due speed. A day or two is not going to make much difference, but if you have any show= stoppers, it would be nice to know about them earlier. It would also be good if a few more people who had read the draft and had n= o comments would identify this to the chairs. Regards Keith From stewe@stewe.org Wed Jul 20 03:38:59 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29CAE21F876F for ; Wed, 20 Jul 2011 03:38:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZrHGjqFEQzP for ; Wed, 20 Jul 2011 03:38:58 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id 8F28421F86FF for ; Wed, 20 Jul 2011 03:38:55 -0700 (PDT) Received: from [172.20.140.16] (unverified [130.192.232.18]) by stewe.org (SurgeMail 3.9e) with ESMTP id 15206-1743317 for multiple; Wed, 20 Jul 2011 12:38:54 +0200 User-Agent: Microsoft-MacOutlook/14.12.0.110505 Date: Wed, 20 Jul 2011 03:38:46 -0700 From: Stephan Wenger To: "DRAGE, Keith (Keith)" , "avtext@ietf.org" Message-ID: Thread-Topic: [avtext] WGLC for draft-ietf-avtext-client-to-mixer-audio-level-03 and draft-ietf-avtext-mixer-to-client-audio-level-03 In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Originating-IP: 130.192.232.18 X-Authenticated-User: stewe@stewe.org Subject: Re: [avtext] WGLC for draft-ietf-avtext-client-to-mixer-audio-level-03 and draft-ietf-avtext-mixer-to-client-audio-level-03 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 10:38:59 -0000 I scanned over these docs during a long flight last week, and was happy with them. Had not enough time (due to ongoing JCT-VC/MPEG meeting) to create minor/editorial comments. Stephan On 7.20.2011 03:21 , "DRAGE, Keith (Keith)" wrote: >(As WG cochair) > >We set a deadline for working group last call comments on the above two >drafts of today. So if you still have comments in the works, please get >them posted to the list with all due speed. > >A day or two is not going to make much difference, but if you have any >show stoppers, it would be nice to know about them earlier. > >It would also be good if a few more people who had read the draft and had >no comments would identify this to the chairs. > >Regards > >Keith >_______________________________________________ >avtext mailing list >avtext@ietf.org >https://www.ietf.org/mailman/listinfo/avtext From keith.drage@alcatel-lucent.com Thu Jul 21 09:08:53 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6331D21F89B8 for ; Thu, 21 Jul 2011 09:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.216 X-Spam-Level: X-Spam-Status: No, score=-104.216 tagged_above=-999 required=5 tests=[AWL=-1.967, BAYES_00=-2.599, HELO_EQ_FR=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DbzX993PmPWw for ; Thu, 21 Jul 2011 09:08:53 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id B53D121F898F for ; Thu, 21 Jul 2011 09:08:52 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p6LG8nEb007877 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 21 Jul 2011 18:08:50 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 21 Jul 2011 18:08:50 +0200 From: "DRAGE, Keith (Keith)" To: "avtext@ietf.org" Date: Thu, 21 Jul 2011 18:08:48 +0200 Thread-Topic: Revised agenda for AVTEXT Thread-Index: AcxHwHmuoZyguaq2R3WkGNmBd10m0g== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84 Subject: [avtext] Revised agenda for AVTEXT X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 16:08:53 -0000 (As WG cochair) Please note the revised agenda at=20 http://www.ietf.org/proceedings/81/agenda/avtext.txt The change is to reduce the time for the audio level drafts (as we have had= very few WGLC comments) and to host the PAYLOAD discussion which would oth= erwise have been done by AVTCORE on Wednesday morning. That gives AVTCORE a bit more flexibility to deal with other urgent issues. No item has been removed from the agenda. Regards Keith From john.elwell@siemens-enterprise.com Fri Jul 22 06:37:45 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D49F821F89C1 for ; Fri, 22 Jul 2011 06:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.164 X-Spam-Level: X-Spam-Status: No, score=-104.164 tagged_above=-999 required=5 tests=[AWL=-1.565, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YuPeFujjlurg for ; Fri, 22 Jul 2011 06:37:45 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3825521F89B8 for ; Fri, 22 Jul 2011 06:37:45 -0700 (PDT) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 50EAD1EB8463 for ; Fri, 22 Jul 2011 15:37:40 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 22 Jul 2011 15:37:40 +0200 From: "Elwell, John" To: "avtext@ietf.org" Date: Fri, 22 Jul 2011 15:37:39 +0200 Thread-Topic: WGLC on client-to-mixer Thread-Index: AcxH/D5EgnLg71k1Qw6OZTS/hMHp9g== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [avtext] WGLC on client-to-mixer X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 13:37:46 -0000 Looks ready to go. John John Elwell Tel: +44 1908 817801 (office and mobile) Email: john.elwell@siemens-enterprise.com http://www.siemens-enterprise.com/uk/ Siemens Enterprise Communications Limited. Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ. Registered No: 5903714, England. Siemens Enterprise Communications Limited is a Trademark Licensee of Siemen= s AG. From john.elwell@siemens-enterprise.com Fri Jul 22 06:37:45 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E11C521F89B8 for ; Fri, 22 Jul 2011 06:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.136 X-Spam-Level: X-Spam-Status: No, score=-104.136 tagged_above=-999 required=5 tests=[AWL=-1.537, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTkZxxfrmefu for ; Fri, 22 Jul 2011 06:37:45 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3821A21F89A1 for ; Fri, 22 Jul 2011 06:37:45 -0700 (PDT) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 535301EB8464 for ; Fri, 22 Jul 2011 15:37:40 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 22 Jul 2011 15:37:40 +0200 From: "Elwell, John" To: "avtext@ietf.org" Date: Fri, 22 Jul 2011 15:37:39 +0200 Thread-Topic: WGLC on mixer to client Thread-Index: AcxH/jBuBeYfua47RW2VtPf7DJ/5eA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [avtext] WGLC on mixer to client X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 13:37:46 -0000 Looks ready to go apart from a couple of minor comment: " This document describes an RTP header extension that allows mixers to indicate the audio-level of every conference participant (CSRC) in addition to simply indicating their on/off status." Perhaps "every conference participant" should be "every contributing confer= ence participant", since it is only those participants whose CSRCs are incl= uded. " Conferencing clients that support audio level indicators and have no mixing capabilities would not be able to content for this audio level extension and would hence have to always include the direction parameter in the "extmap" attribute with a value of "recvonly"." The words "to content" do not parse. Perhaps it should say "to provide cont= ent". John John Elwell Tel: +44 1908 817801 (office and mobile) Email: john.elwell@siemens-enterprise.com http://www.siemens-enterprise.com/uk/ Siemens Enterprise Communications Limited. Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ. Registered No: 5903714, England. Siemens Enterprise Communications Limited is a Trademark Licensee of Siemen= s AG. From mramalho@cisco.com Mon Jul 25 10:56:06 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF9621F8BD1; Mon, 25 Jul 2011 10:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.178 X-Spam-Level: X-Spam-Status: No, score=-0.178 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2kNDa-7KuZz; Mon, 25 Jul 2011 10:56:04 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 99C7C21F8B7F; Mon, 25 Jul 2011 10:56:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mramalho@cisco.com; l=11450; q=dns/txt; s=iport; t=1311616564; x=1312826164; h=mime-version:subject:date:message-id:from:to; bh=KZSx7MZ33bJTSHZ6lKB11Ze4gKXC8yVXH/znNZwYheM=; b=LeAHbrdTlLn9wWHSS8OErmN087hnjsUFYiHu7DDydDaWrNo1u8nMmgzI HWnZlkrjglDQQavu7OMkC4uaRuPIE1Q5z90vYIhC8bEatAm/JNi0M9eBc pFeoCSrMsrzgLACrqbGzwRSzDuq5W0Nyw7g2sRS5O6y3dN7OFfAmIsRlc c=; X-Files: image001.gif : 837 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFADmtLU6tJV2c/2dsb2JhbAA2AQEDBQ8BDAoIAQI6JAQBJgEBAwYPFAEHAQUNBAEHAgkkFwEFARUBCgIbgjakfHeqZZ4ZAoM7giNfBIdVg0GCYYoJi24 X-IronPort-AV: E=Sophos;i="4.67,263,1309737600"; d="gif'147?scan'147,208,217,147";a="6206983" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 25 Jul 2011 17:56:04 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p6PHu4oU018874; Mon, 25 Jul 2011 17:56:04 GMT Received: from xmb-rcd-209.cisco.com ([72.163.62.216]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Jul 2011 12:56:03 -0500 X-Mimeole: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: DTNW EO41 FxPH GjGs J5WL Os6u Py1x SVRg U+DP YY6y ZG4x Z7yI dQYM dWo+ eDA3 fimX; 3; YQB2AHQAQABpAGUAdABmAC4AbwByAGcAOwBhAHYAdABlAHgAdABAAGkAZQB0AGYALgBvAHIAZwA7AHAAYQB5AGwAbwBhAGQAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {8AD51F7B-5C7F-4DC9-8806-E319DC357319}; bQByAGEAbQBhAGwAaABvAEAAYwBpAHMAYwBvAC4AYwBvAG0A; Mon, 25 Jul 2011 17:55:56 GMT; ZAByAGEAZgB0AC0AcgBhAG0AYQBsAGgAbwAtAHAAYQB5AGwAbwBhAGQALQBnADcAMQAxADAALQAwADAAIAB0AG8AIABiAGUAIABkAGkAcwBjAHUAcwBzAGUAZAAgAGkAbgAgAEEAVgBUAEUAWABUAA== MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CC4AF4.1E89FDC9" x-cr-puzzleid: {8AD51F7B-5C7F-4DC9-8806-E319DC357319} Content-class: urn:content-classes:message Date: Mon, 25 Jul 2011 12:55:56 -0500 Message-ID: <999109E6BC528947A871CDEB5EB908A00444F743@XMB-RCD-209.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ramalho-payload-g7110-00 to be discussed in AVTEXT Thread-Index: AcxK9Bp9BfwrLmXySG2KIyD5u4pbDw== From: "Michael Ramalho (mramalho)" To: "IETF AVTCore WG" , , X-OriginalArrivalTime: 25 Jul 2011 17:56:03.0342 (UTC) FILETIME=[1EA3AAE0:01CC4AF4] Subject: [avtext] draft-ramalho-payload-g7110-00 to be discussed in AVTEXT X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 17:56:06 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC4AF4.1E89FDC9 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CC4AF4.1E89FDC9" ------_=_NextPart_002_01CC4AF4.1E89FDC9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [Apologies for cross posting AVT lists - reason below] =20 All, =20 I will be discussing issues contained in draft-ramalho-payload g7110-00 at the AVT extensions timeslot on Wednesday afternoon. =20 This draft is a payload WG draft, but there isn't a payload meeting at IETF 81. And this draft was previously scheduled to be discussed the AVT core timeslot prior to its being moved to AVTEXT (thus the reason for the cross post to all AVT groups). Roni and Ali encouraged me to say a few words prior to the discussion this week. =20 G.711.0 is a stateless and lossless compression of G.711 VoIP RTP payloads. Thus it is a compression algorithm tailored for G.711. When negotiated end-to-end it is negotiated "as if it were a codec". =20 However, being lossless and stateless, G.711.0 can be applied anywhere within an end-to-end G.711 negotiated session. When applied in this manner, it suffers no voice quality degradation relative to G.711 (duh, its lossless). =20 Most of the open issues in the draft relate to the use of G.711.0 within the context of an and-to-end G.711 negotiated session. =20 I look forward to comments generated from the discussion of this draft for those cases. =20 Regards, =20 Michael Ramalho =20 =20 Michael Ramalho Technical Leader Product Development mramalho@cisco.com =20 Phone: +1 919 476 2038 Mobile: +1 941 544 2844 Cisco Systems, Inc. 4564 Tuscana Drive Sarasota, FL 34241-4201 United States http://ramalho.webhop.info Skype: mramalho_mar42 =20 =20 =09 =09 =20 =20 ------_=_NextPart_002_01CC4AF4.1E89FDC9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

[Apologies for cross posting AVT lists – = reason below]

 

All,

 

I will be discussing issues contained in = draft-ramalho-payload g7110-00 at the AVT extensions timeslot on Wednesday = afternoon.

 

This draft is a payload WG draft, but there = isn’t a payload meeting at IETF 81. And this draft was previously scheduled to = be discussed  the AVT core timeslot prior to its being moved to AVTEXT = (thus the reason for the cross post to all AVT groups). Roni and Ali encouraged me = to say a few words prior to the discussion this week.

 

G.711.0 is a stateless and lossless compression of = G.711 VoIP RTP payloads. Thus it is a compression algorithm tailored for G.711. = When negotiated end-to-end it is negotiated “as if it were a = codec”.

 

However, being lossless and stateless, G.711.0 can = be applied anywhere within an end-to-end G.711 negotiated session. When = applied in this manner, it suffers no voice quality degradation relative to G.711 = (duh, its lossless).

 

Most of the open issues in the draft relate to the = use of G.711.0 within the context of an and-to-end G.711 negotiated = session.

 

I look forward to comments generated from the = discussion of this draft for those cases.

 

Regards,

 

Michael Ramalho

 

3D"http://www.cisco.com/swa/i/logo.gif"

= Michael Ramalho
Technical Leader
Product Development
mramalho@cisco.com
Phone: +1 919 476 2038
Mobile: +1 941 544 2844

= Cisco Systems, Inc.
4564 Tuscana Drive
Sarasota, FL 34241-4201
United States
http://ramalho.webhop.info
Skype: mramalho_mar42

 

 

 

 

------_=_NextPart_002_01CC4AF4.1E89FDC9-- ------_=_NextPart_001_01CC4AF4.1E89FDC9 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.gif Content-Location: image001.gif R0lGODlhbgBJAMQAAP///3OXqtapqq1MTcmRki9mgZkAALpqbMl/f6g5O/Xq6+vX2OTIyaMqK/nz 9OW/v5sVFsbV3Nfh5p0PD5kFBf78/P38/Pz6+v/+/rZdXpcKDKAhIvv396QvMO/g4Ny4uSH5BAAA AAAALAAAAABuAEkAQAX/ICCOZGmeaKqubOu+cCzPdG3feK6nkln8pp5LSPoVgrucsbQsAp1HKPM5 alapImtyy+16SwKDmJBCiBEWgMUsPgg8JMHEQCGTMACP2HDgiBQZYglfOQ+GDy2HhiqKKI2EkJGS k5SVlpeYmZpfWkpYmypEV1GjU6QjolmfnZ0AqZWvrj6fski2UiWxsZkcHxkNYg0IABUibAjFIgsH wAYNBwokvb8QEMIOJAwICQYQCQgLoCgLHWIdHwoKCwzExmdpGBwcxRgDYhkXAOTm6OoMfg4CiRGg wAOBOXzEKVzIsKHDhxAjSpxIsaKNCAEibMGo0WKLVjdAVgxQIICpEiRN/7JIeZIEy4WsVsk8BSAm TZstLb0csVMVzZ4AgALtJLQkRY4bM3pcupDAHgMduA1Q484AGmJO7x04kCCaCAIaxFCISmGAVwZP u+1pEK5hVgPYUBxLQ4yBvacfvlIwMCFuCbRi2I34sHfDQ0BpDUyFNxfABTZPGwgGACjsU7MiLLx9 ukEA08+gQ4seTbq06dOoU6tezbq169evd92QHRooDtujRdbQDZr3DN8RkeIaIXxFcZ8ljkPEOVwF 81ILlT9HTkL6zJwilE+aXvN68+43vUO3xL28eOrj0VdSbp0me6XV4acH8L6jRNw28IumXYM/7P8k PJLIISkIWIKBD3GwmcIYiwGAQWP6cJMWHCIoCEFamInwQTNPdYCIQwqUM8YCC3zgWTKNOXAAg14p kA9lIkJAAIkmYsPBim0YcsBeVjn0llcnQAjYHh14phdfQGazx2QAEGaAYQ2FMVAZ75BggTZ7HFCM HHQYWcICeyAjgormPASZYgN00CAAjV0gwAEEEACZlsbwCMEAaWb4wFMJJMDjBkwypAABErbRzoNn FFPBghnkRcKgCVimwQF+VSDAXXw1CuCmnHbq6aeghirqqDiEAAA7 ------_=_NextPart_001_01CC4AF4.1E89FDC9-- From keith.drage@alcatel-lucent.com Mon Jul 25 15:48:46 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1564F11E80E7 for ; Mon, 25 Jul 2011 15:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.03 X-Spam-Level: X-Spam-Status: No, score=-106.03 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WvQ3Yq4xdgA2 for ; Mon, 25 Jul 2011 15:48:45 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 407D911E80E3 for ; Mon, 25 Jul 2011 15:48:41 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p6PMmeqX000319 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 26 Jul 2011 00:48:40 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Tue, 26 Jul 2011 00:48:19 +0200 From: "DRAGE, Keith (Keith)" To: "avtext@ietf.org" Date: Tue, 26 Jul 2011 00:48:17 +0200 Thread-Topic: Calling all AVTEXT presenters Thread-Index: AcxLHPIT0ZvUeJenQ3qvA9wmf+FK2A== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Subject: [avtext] Calling all AVTEXT presenters X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 22:48:46 -0000 (As AVTEXT cochair) Can we please have any slide presentations for AVTEXT by lunchtime local ti= me tomorrow so that we can get them uploaded to the meeting materials site. Keith From keith.drage@alcatel-lucent.com Tue Jul 26 08:24:51 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26EBE11E811C for ; Tue, 26 Jul 2011 08:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.04 X-Spam-Level: X-Spam-Status: No, score=-104.04 tagged_above=-999 required=5 tests=[AWL=-1.791, BAYES_00=-2.599, HELO_EQ_FR=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLt3TLjQtgVC for ; Tue, 26 Jul 2011 08:24:50 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 4106B11E8135 for ; Tue, 26 Jul 2011 08:24:48 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p6QFOhFR009421 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 26 Jul 2011 17:24:47 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Tue, 26 Jul 2011 17:24:46 +0200 From: "DRAGE, Keith (Keith)" To: "avtext@ietf.org" Date: Tue, 26 Jul 2011 17:24:44 +0200 Thread-Topic: Presentation slides for Wednesday session Thread-Index: AcxLqCWNciW681AnR127/jelyXxWZw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84 Subject: [avtext] Presentation slides for Wednesday session X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 15:24:51 -0000 (As AVTEXT cochair) These should now all be uploaded.=20 For those participating remotely we have included the audio streaming and j= abber links on the status slides - that information is also available elsew= here. Any issues let the chairs know as soon as possible. We will also be looking for volunteer notetakers and a jabber scribe. If no= one volunteers early we will compel volunteers at the start of the session! Regards Keith From mramalho@cisco.com Tue Jul 26 10:02:03 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 268E81F0C36; Tue, 26 Jul 2011 10:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[AWL=1.211, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9KuMOGVTxGJD; Tue, 26 Jul 2011 10:02:02 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 23EB31F0C35; Tue, 26 Jul 2011 10:02:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mramalho@cisco.com; l=6156; q=dns/txt; s=iport; t=1311699722; x=1312909322; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=MBQ7FyXq8UIIXOTbLBj38/GOqZYvQgVyw8NO+cmHlyA=; b=cLvIXOnUzNpW1OiHgs7LduWMaj37dlmwNYONpsrEj7l+ahheExRQfa8/ m2pkVuEQLXb4xa9k5RJqxk/6jma9MYkfnXNW/yb0Gkubg34fmUOH9HveP /uiUwfSXhGWrUunF8llwQ8TAEmBpaMc6pe8yOqD3/ROZP4VAajcJSQ5LL M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuYAANXxLk6tJXG9/2dsb2JhbAArCwEBAQECAQEBAREBIQo6CwUHBQIBCQ4DBAEBCwYjAQYBExgjDggBAQUBFgwSCZdUj1p3iHwEowqeY4VhXwSHV5Ari24 X-IronPort-AV: E=Sophos;i="4.67,270,1309737600"; d="scan'208";a="6558096" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 26 Jul 2011 17:02:01 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6QH21JZ001856; Tue, 26 Jul 2011 17:02:01 GMT Received: from xmb-rcd-209.cisco.com ([72.163.62.216]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Jul 2011 12:02:01 -0500 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Jul 2011 12:01:52 -0500 Message-ID: <999109E6BC528947A871CDEB5EB908A0044E2EEB@XMB-RCD-209.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [payload] draft-ramalho-payload-g7110-00 to be discussed inAVTEXT Thread-Index: AcxLnfa5ON9/+YDUQsu+wdrgliSsAgAFt/Iw References: From: "Michael Ramalho (mramalho)" To: "Hadriel Kaplan" , X-OriginalArrivalTime: 26 Jul 2011 17:02:01.0157 (UTC) FILETIME=[BC8F3F50:01CC4BB5] Cc: avtext@ietf.org, payload@ietf.org Subject: Re: [avtext] [payload] draft-ramalho-payload-g7110-00 to be discussed inAVTEXT X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 17:02:03 -0000 Hadriel, Thank you for asking your question. Re: "Have any IPR disclosures been submitted to the IETF for this?" For the G.711.0 IETF payload draft, no. In the ITU-T there are four IPR disclosures for G.711.0 - one for each of the collaborating companies. However, Cisco had hoped for a disclosures to be filed at either the IETF or the ITU-T by IETF 81 by all four collaborating companies explicitly stating that G.711.0 for "consumer software terminals" (e.g., softclients) be royalty-free. We hope such a statement will be released in the near future. RE: "For one, just to be able to do this requires sniffing SDP " Not true. Virtually every implementation using G.711 I have found in practice uses the STATIC payload type of 0 or 8 for G.711. Thus every RTP packet with PT =3D [ 0 | 8 ] can only have a G.711 = payload inside of it. When G.711.0 is negotiated end to end, it will have its own media line. The suggested "hint" in the G.711 SDP is not to "signal G.711.0", but rather for middleboxes like NATs/Firewalls/etc. to "expect G.711" in either uncompressed (real G.711 with PT =3D [0 | 8]) or compressed (with PT =3D Q) form as equivalents. Part of the reason for the "hint in the G.711 SDP" is because SBCs will likely strip the G.711.0 m line from the SDP because it doesn't know about G.711.0 and only let the m line for G.711 to pass ... it might just let an unrecognized G.711 attribute through. I would like to get opinions for the group and appreciate your question. Re: SRTP Yep, the raw G.711 needs to be in the clear for the compression to work. Note that the PT is in the clear with SRTP (because the RTP header is in the clear) ... and thus SRTP should be able to encrypt G.711.0 without issues. Re: "Cut out the "In the Middle" section". That is a possibility. However I can say that we have explicit customer requests that IF such a compression is likely to be used by "in the middle entities" (i.e., service providers or administrative domains within a service provider), that we provide guidance on how to accomplish that compression so that everyone does it the same way. I also agree that keeping it in the draft will cause heartburn relative to its absence ;-). But I've got customers to please. And I have thick skin ;-). Re: "Middleboxes are a pain" Yes they are; but the are also a fact of life. I have a longer talk in which I enumerate the issues related to SBCs ... but that talk is inappropriate for the IETF slot (at least that is what I have been told). Thanks again, Michael Ramalho -----Original Message----- From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Tuesday, July 26, 2011 10:12 AM To: draft-ramalho-payload-g7110@tools.ietf.org Cc: avtext@ietf.org; payload@ietf.org Subject: Re: [payload] draft-ramalho-payload-g7110-00 to be discussed inAVTEXT [sorry for cross-posting, but this draft is going to be presented in avtext] Hi, I read this draft and I have a couple comments, as follows: 1) Have any IPR disclosures been submitted to the IETF for this? I ask because I believe there are several submitted to ITU for this codec. 2) The stuff in section 6 on "In the Middle" is really controversial, and arguably a very bad idea. =20 For one, just to be able to do this requires sniffing SDP which is only possible if it's in cleartext, and if the sniffer can reassemble fragments or stream segments, and if the sniffer is guaranteed to be in the path for all SDP exchanges between the parties for ever. And to be able to really do it you have to *modify* the SDP which is a whole different ballgame. =20 And then there's the way in which the draft describes doing it, by inserting an fmtp attribute line of the new payload type, which is wrong in my opinion - it should either replace the payload type in the m-line and add the original 711a/u-law info as a new attribute, or better yet add the new payload type as another option in the m-line and wait for an SDP answer to choose (for protocols that have an offer/answer model). Otherwise the middlebox has to know another middlebox is in the call path a priori. And then there's the problem of SRTP: if SRTP prevents the middlebox from doing the compression, the middlebox needs to know when SRTP is going to be used by inspecting SDP, which isn't as straightforward as looking for "SAVP" in the m-line... e.g. the endpoints could be using RFC 5939. =20 In summary: I would remove this idea/section from the draft. Publishing a draft defining the payload format and media type for G.711.0 is fairly straight-forward and non-controversial (I think), but going beyond that to "support" this man-in-the-middle thing is going to cause you heartburn and delay getting the basic stuff published as an RFC. Just my 2 cents. -hadriel On Jul 25, 2011, at 12:55 PM, Michael Ramalho wrote: > This draft is a payload WG draft, but there isn't a payload meeting at IETF 81. And this draft was previously scheduled to be discussed the AVT core timeslot prior to its being moved to AVTEXT (thus the reason for the cross post to all AVT groups). Roni and Ali encouraged me to say a few words prior to the discussion this week. >=20 > G.711.0 is a stateless and lossless compression of G.711 VoIP RTP payloads. Thus it is a compression algorithm tailored for G.711. When negotiated end-to-end it is negotiated "as if it were a codec". >=20 > However, being lossless and stateless, G.711.0 can be applied anywhere within an end-to-end G.711 negotiated session. When applied in this manner, it suffers no voice quality degradation relative to G.711 (duh, its lossless). >=20 > Most of the open issues in the draft relate to the use of G.711.0 within the context of an and-to-end G.711 negotiated session. >=20 > I look forward to comments generated from the discussion of this draft for those cases. >=20 _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload From HKaplan@acmepacket.com Tue Jul 26 07:11:54 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1125E21F8CB2; Tue, 26 Jul 2011 07:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.389 X-Spam-Level: X-Spam-Status: No, score=-2.389 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id molQ6hVkKhx4; Tue, 26 Jul 2011 07:11:53 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id AE39121F8BF2; Tue, 26 Jul 2011 07:11:52 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 26 Jul 2011 10:11:51 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Tue, 26 Jul 2011 10:11:51 -0400 From: Hadriel Kaplan To: "draft-ramalho-payload-g7110@tools.ietf.org" Date: Tue, 26 Jul 2011 10:11:49 -0400 Thread-Topic: draft-ramalho-payload-g7110-00 to be discussed in AVTEXT Thread-Index: AcxLnfa5ON9/+YDUQsu+wdrgliSsAg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAgAAAUAAAAFR X-Mailman-Approved-At: Tue, 26 Jul 2011 10:32:57 -0700 Cc: "avtext@ietf.org" , "payload@ietf.org" Subject: Re: [avtext] draft-ramalho-payload-g7110-00 to be discussed in AVTEXT X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 14:11:54 -0000 [sorry for cross-posting, but this draft is going to be presented in avtext= ] Hi, I read this draft and I have a couple comments, as follows: 1) Have any IPR disclosures been submitted to the IETF for this? I ask bec= ause I believe there are several submitted to ITU for this codec. 2) The stuff in section 6 on "In the Middle" is really controversial, and a= rguably a very bad idea. =20 For one, just to be able to do this requires sniffing SDP which is only pos= sible if it's in cleartext, and if the sniffer can reassemble fragments or = stream segments, and if the sniffer is guaranteed to be in the path for all= SDP exchanges between the parties for ever. And to be able to really do i= t you have to *modify* the SDP which is a whole different ballgame. =20 And then there's the way in which the draft describes doing it, by insertin= g an fmtp attribute line of the new payload type, which is wrong in my opin= ion - it should either replace the payload type in the m-line and add the o= riginal 711a/u-law info as a new attribute, or better yet add the new paylo= ad type as another option in the m-line and wait for an SDP answer to choos= e (for protocols that have an offer/answer model). Otherwise the middlebox= has to know another middlebox is in the call path a priori. And then there's the problem of SRTP: if SRTP prevents the middlebox from d= oing the compression, the middlebox needs to know when SRTP is going to be = used by inspecting SDP, which isn't as straightforward as looking for "SAVP= " in the m-line... e.g. the endpoints could be using RFC 5939. =20 In summary: I would remove this idea/section from the draft. Publishing a = draft defining the payload format and media type for G.711.0 is fairly stra= ight-forward and non-controversial (I think), but going beyond that to "sup= port" this man-in-the-middle thing is going to cause you heartburn and dela= y getting the basic stuff published as an RFC. Just my 2 cents. -hadriel On Jul 25, 2011, at 12:55 PM, Michael Ramalho wrote: > This draft is a payload WG draft, but there isn=92t a payload meeting at = IETF 81. And this draft was previously scheduled to be discussed the AVT c= ore timeslot prior to its being moved to AVTEXT (thus the reason for the cr= oss post to all AVT groups). Roni and Ali encouraged me to say a few words = prior to the discussion this week. >=20 > G.711.0 is a stateless and lossless compression of G.711 VoIP RTP payload= s. Thus it is a compression algorithm tailored for G.711. When negotiated e= nd-to-end it is negotiated =93as if it were a codec=94. >=20 > However, being lossless and stateless, G.711.0 can be applied anywhere wi= thin an end-to-end G.711 negotiated session. When applied in this manner, i= t suffers no voice quality degradation relative to G.711 (duh, its lossless= ). >=20 > Most of the open issues in the draft relate to the use of G.711.0 within = the context of an and-to-end G.711 negotiated session. >=20 > I look forward to comments generated from the discussion of this draft fo= r those cases. >=20 From keith.drage@alcatel-lucent.com Tue Jul 26 10:37:54 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B487511E8119 for ; Tue, 26 Jul 2011 10:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.962 X-Spam-Level: X-Spam-Status: No, score=-103.962 tagged_above=-999 required=5 tests=[AWL=-1.713, BAYES_00=-2.599, HELO_EQ_FR=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rV6qXdNxPvI9 for ; Tue, 26 Jul 2011 10:37:54 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id E15F811E8117 for ; Tue, 26 Jul 2011 10:37:53 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p6QHbhR1027530 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 26 Jul 2011 19:37:52 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Tue, 26 Jul 2011 19:37:45 +0200 From: "DRAGE, Keith (Keith)" To: "avtext@ietf.org" Date: Tue, 26 Jul 2011 19:37:44 +0200 Thread-Topic: Crossposting PAYLOAD Thread-Index: AcxLuroAPr0vf378ROah1SpLgmouUQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84 Subject: [avtext] Crossposting PAYLOAD X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 17:37:54 -0000 (As AVTEXT cochair) While the PAYLOAD presentation is piggybacking on the AVTEXT session, pleas= e only post comments on PAYLOAD drafts to the PAYLOAD mailing list. Regards Keith From mramalho@cisco.com Tue Jul 26 13:32:22 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C18721F881C; Tue, 26 Jul 2011 13:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.394 X-Spam-Level: X-Spam-Status: No, score=-1.394 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPAckP0h6+MZ; Tue, 26 Jul 2011 13:32:21 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9441421F87C7; Tue, 26 Jul 2011 13:32:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mramalho@cisco.com; l=4759; q=dns/txt; s=iport; t=1311712341; x=1312921941; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=RW6rrr7zAq0vcj+dfzI+dQGphYj98qc9NkhU6EzYo5E=; b=EVBDvX0dmZQIoJsJ4ftmiytgRA9/3XX0fExp+7ABjbDOsmYplgeYmP9S mG78iD5JCs+I9yebyefhY+Q+DUyUuHMgW5vY67xRrKCJJWfgRAdKqaGBq JMtJGwEUvu2pDEz2xAGGJpBW02bXK8ZzL4AdlO5wuemJL5SsldMlCEQao g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuYAAAsjL06tJXG9/2dsb2JhbAA1AQEBAQIBFAEhCkUFBwUCAQkOAwQBAQsGDhUBBgETOw4IAQEFFwwbl06PXHeIfKM3nlWDNoIrXwSHV5Ari24 X-IronPort-AV: E=Sophos;i="4.67,271,1309737600"; d="scan'208";a="6636156" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 26 Jul 2011 20:32:21 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6QKWKwX017186; Tue, 26 Jul 2011 20:32:21 GMT Received: from xmb-rcd-209.cisco.com ([72.163.62.216]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Jul 2011 15:32:20 -0500 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Jul 2011 15:32:19 -0500 Message-ID: <999109E6BC528947A871CDEB5EB908A0044E3025@XMB-RCD-209.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [payload] draft-ramalho-payload-g7110-00 to be discussed inAVTEXT Thread-Index: AcxLvJwjeXPLpU4bTWeQAtZHOf9AMwAEX9Zg References: <999109E6BC528947A871CDEB5EB908A0044E2EEB@XMB-RCD-209.cisco.com> From: "Michael Ramalho (mramalho)" To: "Hadriel Kaplan" X-OriginalArrivalTime: 26 Jul 2011 20:32:20.0171 (UTC) FILETIME=[1E13F9B0:01CC4BD3] Cc: avtext@ietf.org, payload@ietf.org, draft-ramalho-payload-g7110@tools.ietf.org Subject: Re: [avtext] [payload] draft-ramalho-payload-g7110-00 to be discussed inAVTEXT X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 20:32:22 -0000 Hadriel, Thanks for the volley. Comments in-line below (w/ MAR:). Michael -----Original Message----- From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 Sent: Tuesday, July 26, 2011 1:51 PM To: Michael Ramalho (mramalho) Cc: draft-ramalho-payload-g7110@tools.ietf.org; avtext@ietf.org; payload@ietf.org Subject: Re: [payload] draft-ramalho-payload-g7110-00 to be discussed inAVTEXT On Jul 26, 2011, at 1:01 PM, Michael Ramalho (mramalho) wrote: > RE: "For one, just to be able to do this requires sniffing SDP " >=20 > Not true. Virtually every implementation using G.711 I have found in > practice uses the STATIC payload type of 0 or 8 for G.711. >=20 > Thus every RTP packet with PT =3D [ 0 | 8 ] can only have a G.711 payload > inside of it. Sorry I should have been explicit. It needs to sniff to detect the PT of the G.711.0 payload. I.e., for the example diagram figure 4 in the draft, device E needs to sniff the SDP offer to determine what the "Q" value is, and device C needs to do the same for the SDP answer for the reverse media stream. MAR: Thanks for the clarification. Yes, you have got it right (one exception shortly). SBCs normally "sniff SDP", so that might not be an issue for them. But in the case where there are multiple SBCs in the end-to-end path, one or more of them may strip out the G.711.0 m line (as you have it below) before a given SBC sees the end-to-end SDP. MAR: As an aside, some network providers may "configure PT =3D Q" in = their networks to make things easier (at the downside of not allowing their applications to use PT =3D Q), although that would not be recommended = (in the IETF or in general). MAR: Lastly, the compression can be applied in specific topologies - when there are no middleboxes that deny flows based on RTP PT changes - by tunnel endpoints that know how to compress/decompress G.711/G.711.0. This tunneling is unspecified magic in the draft. It can also be used in many of the same topologies where multi-hop header compression is employed. >=20 > When G.711.0 is negotiated end to end, it will have its own media line. Ummm... I'm confused. The example in the draft is: m=3Daudio RTP/AVP 0 a=3Drtpmap: 0 PCMU a=3Dfmtp:0 G7110 =3D Q <<< the G.711 SDP hint Are you saying that it's really this?: m=3Daudio 49120 RTP/AVP 0 a=3Drtpmap:0 PCMU a=3Dfmtp:0 G7110 =3D Q m=3Daudio 49120 RTP/AVP 99 a=3Drtpmap:99 G7110/8000 a=3Dptime:20 a=3Dfmtp:98 complaw=3Dmu MAR: Precisely ... one m-line for G.711 (in your case mu-law) and one m-line for G.711.0 (complaw=3Dmu, PT =3D 99). The "hint" is in the G.711 m-line (and the draft says so ... but you example makes it more clear .. thanks). MAR: I want to know if anyone "objects" to a new fmtp parameter "G7110/8000". Worse case, if an SBC doesn't like that parameter, it could strip it with no harm to setting up a G.711 flow. > The suggested "hint" in the G.711 SDP is not to "signal G.711.0", but > rather for middleboxes like NATs/Firewalls/etc. to "expect G.711" in > either uncompressed (real G.711 with PT =3D [0 | 8]) or compressed = (with > PT =3D Q) form as equivalents. But they're NOT equivalent. For all intents and purposes G.711.0 is a different codec from G.711, afaict. MAR: OK .. we are even now .. I should have been more explicit here ;-). MAR: While I believe the best "in the middle" use cases are when SBCs are involved in the (lossless) transcode ... there are SOME LIMITED cases in which SPs desire to switch from G.711 to G.711.0 though such boxes without the transcode and without signaling (so-called "in-media methods"). Such SPs account for the bandwidth savings relative to G.711 in their traffic engineering. Like I said earlier, I have a longer talk on the subject and would be happy to discuss further. Perhaps I should have asked for a slot in the behave WG for these issues? That it can be implemented as a bump-in-the-wire without full DSPs matters not. The most logical thing for a middlebox to do would be to handle it exactly like it handles middlebox-provided transcoding/transrating cases today, with normal SDP modifications/behavior, no? (and by that I mean act as a first-class participant in SDP, by inserting/adding codecs into the same m-line, and handling offer/answer appropriately) MAR: See my last comment; there may be exceptions for specific customers and topologies. Indeed, the reason for the "hint" is precisely to inform devices such as SBCs that the switch from PT=3D0 to PT=3D99 (your = example) could occur naturally, so please don't kill the flow. MAR: Thanks again for your commentary, I appreciate it. -hadriel From mramalho@cisco.com Wed Jul 27 10:36:13 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2458121F8A4B; Wed, 27 Jul 2011 10:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.546 X-Spam-Level: X-Spam-Status: No, score=-1.546 tagged_above=-999 required=5 tests=[AWL=-0.147, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7fw9MOZ+8QYj; Wed, 27 Jul 2011 10:36:12 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 50CA621F8A30; Wed, 27 Jul 2011 10:36:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mramalho@cisco.com; l=5819; q=dns/txt; s=iport; t=1311788172; x=1312997772; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=gkcgh0RX3GcfxB0yPyqp8PBwbGv9tl1T7Sl9ax+FjKU=; b=OoszJHsOxKZdlcMHvGFwRrntnn7KsjIPIa57s5Wxqa2rM3c3d5WuaLC4 IzjugesWwcZUexHhC5UMgQN6GrsD0+LcvDEKneoUHAoKGrkOa0ZE0obfv Md3xOyZ+bKcHNIjp8cdIzx6Cna//NO/0/B6wxxbUod95RVZk43UnIGp3Q Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuAAACBMME6tJXG8/2dsb2JhbAA1AQEBAQIBFAEYCQpFBQcFAgEJDgMEAQELBiMBBgETOw4IAQEFFwwbl1mPSHeIfKNWnm2FYV8Eh1eQLotw X-IronPort-AV: E=Sophos;i="4.67,277,1309737600"; d="scan'208";a="7078934" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 27 Jul 2011 17:36:05 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6RHa5Zk010784; Wed, 27 Jul 2011 17:36:05 GMT Received: from xmb-rcd-209.cisco.com ([72.163.62.216]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Jul 2011 12:36:04 -0500 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Jul 2011 12:36:03 -0500 Message-ID: <999109E6BC528947A871CDEB5EB908A0044E33C1@XMB-RCD-209.cisco.com> In-Reply-To: <23FA88EE-A4E7-4A57-93BA-8B91501050F6@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [payload] draft-ramalho-payload-g7110-00 to be discussed inAVTEXT Thread-Index: AcxMH/HOYigxaGnNRSO18vl/0yq1kwAYoP3w References: <999109E6BC528947A871CDEB5EB908A0044E2EEB@XMB-RCD-209.cisco.com> <999109E6BC528947A871CDEB5EB908A0044E3025@XMB-RCD-209.cisco.com> <23FA88EE-A4E7-4A57-93BA-8B91501050F6@acmepacket.com> From: "Michael Ramalho (mramalho)" To: "Hadriel Kaplan" X-OriginalArrivalTime: 27 Jul 2011 17:36:04.0291 (UTC) FILETIME=[A8C68130:01CC4C83] Cc: avtext@ietf.org, payload@ietf.org, draft-ramalho-payload-g7110@tools.ietf.org Subject: Re: [avtext] [payload] draft-ramalho-payload-g7110-00 to be discussed inAVTEXT X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 17:36:13 -0000 Hadriel, Re: Put G.711.0 on one m-line. If others believe, as you do, that having G.711.0 on it's own m-line is actually worse (in the sense of the probability of it being stripped out) than having in on the same m-line as G.711 ... I am OK with that. Do others have an opinion? I am inclined to go with your recommendation if no one objects. Re: "Are you saying that there's a GRE or MPLS tunnel between C and E, and that C knows a priori (without SIP/SDP) that RTP it sends goes through E, and that C knows a priori that E is capable of G.711.0 decompression to 711a/u-law?" A tunnel of some sort ... including WAAS-like tunnels in enterprise use cases. The question of how the end tunnels (Box C and E) "find themselves" is purposely left outside the scope of the draft. What I am hoping for is that we can specify some principals for how you compress/decompress so that the flow to the "G.711.0 unaware" endpoints don't know it occurred. Better text is always welcome. Thanks again, Michael -----Original Message----- From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 Sent: Wednesday, July 27, 2011 1:42 AM To: Michael Ramalho (mramalho) Cc: draft-ramalho-payload-g7110@tools.ietf.org; avtext@ietf.org; payload@ietf.org Subject: Re: [payload] draft-ramalho-payload-g7110-00 to be discussed inAVTEXT On Jul 26, 2011, at 4:32 PM, Michael Ramalho (mramalho) wrote: > MAR: Thanks for the clarification. Yes, you have got it right (one > exception shortly). SBCs normally "sniff SDP", so that might not be an > issue for them. But in the case where there are multiple SBCs in the > end-to-end path, one or more of them may strip out the G.711.0 m line > (as you have it below) before a given SBC sees the end-to-end SDP. I think the odds of an SBC stripping out something would be far less if this weren't encoded as two m-lines for the same media type (audio). I.e., just do normal SDP like this: m=3Daudio 49120 RTP/AVP 0 99 a=3Dptime:20 a=3Drtpmap:99 G7110/8000 a=3Dfmtp:99 complaw=3Dmu > MAR: As an aside, some network providers may "configure PT =3D Q" in their > networks to make things easier (at the downside of not allowing their > applications to use PT =3D Q), although that would not be recommended (in > the IETF or in general). But even if you fixed a PT for G.711.0, wouldn't you still need to sniff the SDP to learn the IP/port of the media? Or are you just going to guess that if the packet looks like RTP it is RTP?=20 > MAR: Lastly, the compression can be applied in specific topologies - > when there are no middleboxes that deny flows based on RTP PT changes - > by tunnel endpoints that know how to compress/decompress G.711/G.711.0. > This tunneling is unspecified magic in the draft. It can also be used in > many of the same topologies where multi-hop header compression is > employed. I don't understand what you mean, or why that matters. All I have to go by is the diagram in the draft: ********************** * * |------------| |--------------------| * |---------------| * | A: | | B: | * | C: G.711.0 | * | SENDING |--->| ZERO OR MORE |---->| Compression | * | G.711 | | ROUTING AND/OR | * | PT=3D[0|8] | * | ENDPOINT | | SWITCHING HOPS | * | CHANGED TO | * | | | AND/OR MIDDLEBOXES | * | PT =3D Q | * |____________| |____________________| * |_______________| * * | * * | * ********* * | * * | * * V * * |--------------------| * * | D: | * G.711.0 * | ZERO OR MORE | * COMPRESSION * | ROUTING AND/OR | * SEGMENT * | SWITCHING HOPS | * (payload * | AND/OR MIDDLEBOXES | * only) * |____________________| * * | * * | * *********** | * * | * * V * |------------| |--------------------| * |---------------| * | G: | | F: | * | E: G.711.0 | * | RECEIVING |<---| ZERO OR MORE |<----| DECOMPRESSION | * | G.711 | | ROUTING AND/OR | * | PT =3D Q | * | ENDPOINT | | SWITCHING HOPS | * | CHANGED BACK | * | | | AND/OR MIDDLEBOXES | * | TO PT=3D[0|8] | * |____________| |____________________| * |_______________| * * * ********************** Are you saying that there's a GRE or MPLS tunnel between C and E, and that C knows a priori (without SIP/SDP) that RTP it sends goes through E, and that C knows a priori that E is capable of G.711.0 decompression to 711a/u-law? -hadriel From magnus.westerlund@ericsson.com Wed Jul 27 13:59:55 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EDDE11E80B4 for ; Wed, 27 Jul 2011 13:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.492 X-Spam-Level: X-Spam-Status: No, score=-106.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QAvtS2NQHWrz for ; Wed, 27 Jul 2011 13:59:54 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 0643611E814B for ; Wed, 27 Jul 2011 13:59:53 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-47-4e307c48d236 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id AB.17.20773.84C703E4; Wed, 27 Jul 2011 22:59:53 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Wed, 27 Jul 2011 22:59:52 +0200 Message-ID: <4E307C46.20003@ericsson.com> Date: Wed, 27 Jul 2011 16:59:50 -0400 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "avtext@ietf.org" X-Enigmail-Version: 1.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [avtext] Confirming WG consensus on draft-xia-avtext-splicing-for-rtp-00 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 20:59:55 -0000 WG, In todays AVTEXT WG session we had some discussion on the way forward for the splicing solution. We did ask two consensus questions. There was consensus to use mixer in user detectable case. There was consensus to use mixer also in the user non-detectable case. In other words using mixers in all cases of splicing. This email is to confirm this WG consensus decision please provide any comments within 2 weeks. Magnus Westerlund WG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From keith.drage@alcatel-lucent.com Fri Jul 29 10:51:34 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5DB21F8A80 for ; Fri, 29 Jul 2011 10:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.942 X-Spam-Level: X-Spam-Status: No, score=-105.942 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CFB3Ftev8NKE for ; Fri, 29 Jul 2011 10:51:33 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC2B21F8A7A for ; Fri, 29 Jul 2011 10:51:31 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p6THpUX8011789 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 29 Jul 2011 19:51:30 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Fri, 29 Jul 2011 19:51:30 +0200 From: "DRAGE, Keith (Keith)" To: "avtext@ietf.org" Date: Fri, 29 Jul 2011 19:51:29 +0200 Thread-Topic: Implementations of audio level drafts Thread-Index: AcxOGCToAmS5fuq6SMaxWDuLK2ZMuw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Subject: [avtext] Implementations of audio level drafts X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 17:51:34 -0000 We're starting to think about the publication request on the audio level dr= afts: draft-ietf-avtext-client-to-mixer-audio-level draft-ietf-avtext-mixer-to-client-audio-level For that it would be useful to know if anyone has implementation experience= of these documents. Either send a message to the chairs (avtext-chairs@too= ls.ietf.org) or to the list if you consider you have some useful work in th= is area. Note that this information does not have to be specific. What we are intere= sted in is has implementation been performed that would have identified err= ors in the protocol specification. Text along the lines of "I know of 3 com= mercial deployments" or "I know of a bench model" are perfectly adequate if= you don't want to advertise. Regards Keith From keith.drage@alcatel-lucent.com Fri Jul 29 11:19:31 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB1321F8745 for ; Fri, 29 Jul 2011 11:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.952 X-Spam-Level: X-Spam-Status: No, score=-105.952 tagged_above=-999 required=5 tests=[AWL=0.297, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZBw1SmREki5 for ; Fri, 29 Jul 2011 11:19:31 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id E254C21F86EC for ; Fri, 29 Jul 2011 11:19:30 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p6TIJTJk015714 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 29 Jul 2011 20:19:29 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Fri, 29 Jul 2011 20:19:29 +0200 From: "DRAGE, Keith (Keith)" To: "avtext@ietf.org" Date: Fri, 29 Jul 2011 20:19:27 +0200 Thread-Topic: Current status of audio level drafts after face to face meeting (and confirmation of decisions) Thread-Index: AcxOHA0FyN1Q97awT36erlqh4jxIsA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Subject: [avtext] Current status of audio level drafts after face to face meeting (and confirmation of decisions) X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 18:19:31 -0000 For: draft-ietf-avtext-mixer-to-client-audio-level The WGLC has been held and the comments made are mainly editorial. The docu= ment will be updated shortly to address these comments, and the document is= ready for publication request. A poll in the meeting identified a signific= ant number of people had read the WGLC version, and that it was ready for p= ublication. draft-ietf-avtext-client-to-mixer-audio-level The WGLC has been held.=20 There is one significant technical enhancement to be made, where the propos= al is to define an SDP extension to Indicate Voice Activity Detection (VAD)= support (or lack of). This was the mechanism that had support in the face = to face meeting, and I'll use this message to seek confirmation of that dec= ision on the list. We'll try and get this extension text to the list. We will get the next ver= sion of the draft reviewed by MMUSIC experts for this SDP content. The document will be updated shortly. A poll in the meeting identified a si= gnificant number of people had read the WGLC version, and that it was ready= for publication. Apart from this MMUSIC review we will be looking to do the publication requ= est shortly. And if you have issues with the face-to-face meeting decision to use an SDP= extension to Indicate Voice Activity Detection (VAD) support then please p= ost to the list as soon as possible. Regards Keith From kpfleming@digium.com Fri Jul 29 13:58:31 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0687321F8B8D for ; Fri, 29 Jul 2011 13:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4CUGwQ3ZTTT for ; Fri, 29 Jul 2011 13:58:25 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id 79C0D21F8B14 for ; Fri, 29 Jul 2011 13:58:24 -0700 (PDT) Received: from zimbra.digium.internal ([10.24.55.203] helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1Qmu8W-0002Y4-Cg for avtext@ietf.org; Fri, 29 Jul 2011 15:58:24 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 68CB4D82A3 for ; Fri, 29 Jul 2011 15:58:24 -0500 (CDT) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GimTTTTY0GMs for ; Fri, 29 Jul 2011 15:58:23 -0500 (CDT) Received: from [172.16.58.20] (unknown [207.96.251.20]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id B300CD8024 for ; Fri, 29 Jul 2011 15:58:23 -0500 (CDT) Message-ID: <4E331EE9.6030005@digium.com> Date: Fri, 29 Jul 2011 16:58:17 -0400 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: avtext@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [avtext] Current status of audio level drafts after face to face meeting (and confirmation of decisions) X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 20:58:31 -0000 On 07/29/2011 02:19 PM, DRAGE, Keith (Keith) wrote: > For: > > draft-ietf-avtext-mixer-to-client-audio-level > > The WGLC has been held and the comments made are mainly editorial. The document will be updated shortly to address these comments, and the document is ready for publication request. A poll in the meeting identified a significant number of people had read the WGLC version, and that it was ready for publication. > > draft-ietf-avtext-client-to-mixer-audio-level > > The WGLC has been held. > > There is one significant technical enhancement to be made, where the proposal is to define an SDP extension to Indicate Voice Activity Detection (VAD) support (or lack of). This was the mechanism that had support in the face to face meeting, and I'll use this message to seek confirmation of that decision on the list. > > We'll try and get this extension text to the list. We will get the next version of the draft reviewed by MMUSIC experts for this SDP content. > > The document will be updated shortly. A poll in the meeting identified a significant number of people had read the WGLC version, and that it was ready for publication. > > Apart from this MMUSIC review we will be looking to do the publication request shortly. > > And if you have issues with the face-to-face meeting decision to use an SDP extension to Indicate Voice Activity Detection (VAD) support then please post to the list as soon as possible. I presume you mean SDP 'parameter' here, right? Would this parameter indicate: * that the offerer has VAD ability and will employ it for reporting audio levels * that the offerer wishes the answerer to employ VAD if it can when it reports audio levels * that the offerer *requires* the answerer to employ VAD when it reports audio levels * something else? Sorry, I missed the meeting yesterday and I don't think the minutes have been posted yet or I'd have consulted them before replying :-) -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From emil@sip-communicator.org Fri Jul 29 14:06:48 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCBDF21F89B8 for ; Fri, 29 Jul 2011 14:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXHdwuNr1UOJ for ; Fri, 29 Jul 2011 14:06:47 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9915B21F89A1 for ; Fri, 29 Jul 2011 14:06:47 -0700 (PDT) Received: by wyj26 with SMTP id 26so89424wyj.31 for ; Fri, 29 Jul 2011 14:06:46 -0700 (PDT) Received: by 10.227.57.68 with SMTP id b4mr2277942wbh.82.1311973606012; Fri, 29 Jul 2011 14:06:46 -0700 (PDT) Received: from porcinet.local ([2a01:e35:8a55:abc0:21e:c2ff:fe1b:2fe]) by mx.google.com with ESMTPS id u22sm1687495weq.39.2011.07.29.14.06.44 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Jul 2011 14:06:45 -0700 (PDT) Message-ID: <4E3320E3.7070609@jitsi.org> Date: Fri, 29 Jul 2011 23:06:43 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; bg; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "Kevin P. Fleming" References: <4E331EE9.6030005@digium.com> In-Reply-To: <4E331EE9.6030005@digium.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: avtext@ietf.org Subject: Re: [avtext] Current status of audio level drafts after face to face meeting (and confirmation of decisions) X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 21:06:48 -0000 Hey Kevin, =D0=9D=D0=B0 29.07.11 22:58, Kevin P. Fleming =D0=BD=D0=B0=D0=BF=D0=B8=D1= =81=D0=B0: > On 07/29/2011 02:19 PM, DRAGE, Keith (Keith) wrote: >> For: >> >> draft-ietf-avtext-mixer-to-client-audio-level >> >> The WGLC has been held and the comments made are mainly editorial. The= document will be updated shortly to address these comments, and the docu= ment is ready for publication request. A poll in the meeting identified a= significant number of people had read the WGLC version, and that it was = ready for publication. >> >> draft-ietf-avtext-client-to-mixer-audio-level >> >> The WGLC has been held. >> >> There is one significant technical enhancement to be made, where the p= roposal is to define an SDP extension to Indicate Voice Activity Detectio= n (VAD) support (or lack of). This was the mechanism that had support in = the face to face meeting, and I'll use this message to seek confirmation = of that decision on the list. >> >> We'll try and get this extension text to the list. We will get the nex= t version of the draft reviewed by MMUSIC experts for this SDP content. >> >> The document will be updated shortly. A poll in the meeting identified= a significant number of people had read the WGLC version, and that it wa= s ready for publication. >> >> Apart from this MMUSIC review we will be looking to do the publication= request shortly. >> >> And if you have issues with the face-to-face meeting decision to use a= n SDP extension to Indicate Voice Activity Detection (VAD) support then p= lease post to the list as soon as possible. >=20 > I presume you mean SDP 'parameter' here, right? Jonathan will be posting a detailed description here but basically it will be a parameter in the line that advertises support for the level extension. > Would this parameter indicate: >=20 > * that the offerer has VAD ability and will employ it for reporting=20 > audio levels If set accordingly - yes. It could also be set to mean that the offerer is not planning on using VAD. > * that the offerer wishes the answerer to employ VAD if it can when it = > reports audio levels >=20 > * that the offerer *requires* the answerer to employ VAD when it report= s=20 > audio levels This is not the intention and we should probably make it clear in the text that using the vad param is only meant for extension senders. (Good point btw!) Cheers, Emil --=20 http://jitsi.org From jonathan@vidyo.com Fri Jul 29 14:32:38 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F1A911E80AD for ; Fri, 29 Jul 2011 14:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.868 X-Spam-Level: X-Spam-Status: No, score=-1.868 tagged_above=-999 required=5 tests=[AWL=-0.469, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0SRfNKYJni4z for ; Fri, 29 Jul 2011 14:32:38 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 99F5011E80AC for ; Fri, 29 Jul 2011 14:32:37 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 3D2C1554265 for ; Fri, 29 Jul 2011 17:32:33 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB027.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id D7341554244 for ; Fri, 29 Jul 2011 17:32:32 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB027.mail.lan ([10.110.17.27]) with mapi; Fri, 29 Jul 2011 17:32:27 -0400 From: Jonathan Lennox To: "avtext@ietf.org" Date: Fri, 29 Jul 2011 17:32:31 -0400 Thread-Topic: Proposed resolution of the presence of VAD in client-to-mixer audio levels Thread-Index: AcxONwZ98BYJ1/+1R2m5xYlzQSTcKg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [avtext] Proposed resolution of the presence of VAD in client-to-mixer audio levels X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 21:32:38 -0000 In the working group session on Wednesday, there was a conclusion that it w= ould be best to signal in SDP whether an endpoint is putting meaningful VAD= data into the client-to-mixer audio level extension. My proposal is as follows. Please give feedback on whether this satisfies = everyone's objections and requirements. There is an optional "vad" parameter defined as the extension attributes fi= eld for the "urn:ietf:params:rtp-hdrext:ssrc-audio-level" header extension = element. It takes the form "vad=3Don" if the creator of the audio level ext= ension is providing VAD information, and "vad=3Doff" if it is not. If vad=3Don is specified, the V bit in the audio header extension element i= s defined as in the current draft. If vad=3Doff is specified, the value of= the V bit is unspecified and MUST be ignored by receivers. If the extension attribute is not specified, the default is vad=3Don. This parameter is signaled in the extension attributes; it matches RFC 5285= 's BNF in SDP.=20 An SDP answer MUST include the same value of the vad=3D parameter as was co= ntained in the offer (for the same extension-ID value), if the answer accep= ted the extension. An endpoint MAY negotiate either or both variants of the extension, with th= e two forms having different extension ID values, using the standard RFC 52= 85 mechanisms. Example SDP (showing both the syntax and the double-negotiation): a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level vad=3Don a=3Dextmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level vad=3Doff -- Jonathan Lennox jonathan@vidyo.com From wwwrun@rfc-editor.org Fri Jul 29 15:20:18 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 497B611E80EE; Fri, 29 Jul 2011 15:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.216 X-Spam-Level: X-Spam-Status: No, score=-102.216 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6VL5it15QlGj; Fri, 29 Jul 2011 15:20:17 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id CCF3711E80EC; Fri, 29 Jul 2011 15:20:13 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id BC54198C538; Fri, 29 Jul 2011 15:20:11 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110729222011.BC54198C538@rfc-editor.org> Date: Fri, 29 Jul 2011 15:20:11 -0700 (PDT) Cc: avtext@ietf.org, rfc-editor@rfc-editor.org Subject: [avtext] RFC 6332 on Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs) X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 22:20:18 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6332 Title: Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs) Author: A. Begen, E. Friedrich Status: Standards Track Stream: IETF Date: July 2011 Mailbox: abegen@cisco.com, efriedri@cisco.com Pages: 16 Characters: 35217 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-avtext-multicast-acq-rtcp-xr-06.txt URL: http://www.rfc-editor.org/rfc/rfc6332.txt In most RTP-based multicast applications, the RTP source sends inter- related data. Due to this interdependency, randomly joining RTP receivers usually cannot start consuming the multicast data right after they join the session. Thus, they often experience a random acquisition delay. An RTP receiver can use one or more different approaches to achieve rapid acquisition. Yet, due to various factors, performance of the rapid acquisition methods usually varies. Furthermore, in some cases, the RTP receiver can do a simple multicast join (in other cases, it is compelled to do so). For quality reporting, monitoring, and diagnostic purposes, it is important to collect detailed information from the RTP receivers about their acquisition and presentation experiences. This document addresses this issue by defining a new report block type, called the Multicast Acquisition (MA) report block, within the framework of RTP Control Protocol (RTCP) Extended Reports (XRs) (RFC 3611). This document also defines the necessary signaling of the new MA report block type in the Session Description Protocol (SDP). [STANDARDS-TRACK] This document is a product of the Audio/Video Transport Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From stephen.botzko@gmail.com Fri Jul 29 15:47:14 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14CF711E80BF for ; Fri, 29 Jul 2011 15:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.76 X-Spam-Level: X-Spam-Status: No, score=-2.76 tagged_above=-999 required=5 tests=[AWL=-0.362, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYc7MqDUym72 for ; Fri, 29 Jul 2011 15:47:13 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4BFE111E8096 for ; Fri, 29 Jul 2011 15:47:13 -0700 (PDT) Received: by vxi40 with SMTP id 40so3835314vxi.31 for ; Fri, 29 Jul 2011 15:47:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kE0XWLLwsT7EZdelrzVFgjgr1iykOjWgXmztbloUVrQ=; b=M/kWYMlQ/koa6UelVOSRJqMyV/fbM3YNnlCtaF9xPNMTBAYKlYUp/tAnH7fDWFdDdC 8MpKkHq0HlKH+L1u6Y1gtjXlySvSJCFqF637t+h6GqUTSPWynwD1pCy1N4+duN7X0lcQ a/CKGaxuYXduCUcwbfyqft6B8QRW4RBwudGV0= MIME-Version: 1.0 Received: by 10.52.175.229 with SMTP id cd5mr2086382vdc.197.1311979630893; Fri, 29 Jul 2011 15:47:10 -0700 (PDT) Received: by 10.52.185.71 with HTTP; Fri, 29 Jul 2011 15:47:10 -0700 (PDT) In-Reply-To: References: Date: Fri, 29 Jul 2011 18:47:10 -0400 Message-ID: From: Stephen Botzko To: Jonathan Lennox Content-Type: multipart/alternative; boundary=bcaec5171e2dda1a4604a93d0fdf Cc: "avtext@ietf.org" Subject: Re: [avtext] Proposed resolution of the presence of VAD in client-to-mixer audio levels X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 22:47:14 -0000 --bcaec5171e2dda1a4604a93d0fdf Content-Type: text/plain; charset=ISO-8859-1 It might make sense to have senders set V=0 when vad=off, rather than leave it unspecified. Also, if the far-end doesn't accept the extension (doesn't return vad= in the answer), I would assume that V should be set to 0 anyway, and VAD is off. So I would question the default being VAD=on. Having the default value of on, when then far-end doesn't understand / accept the extension seems incorrect. Regards, Stephen Botzko On Fri, Jul 29, 2011 at 5:32 PM, Jonathan Lennox wrote: > In the working group session on Wednesday, there was a conclusion that it > would be best to signal in SDP whether an endpoint is putting meaningful VAD > data into the client-to-mixer audio level extension. > > My proposal is as follows. Please give feedback on whether this satisfies > everyone's objections and requirements. > > There is an optional "vad" parameter defined as the extension attributes > field for the "urn:ietf:params:rtp-hdrext:ssrc-audio-level" header extension > element. It takes the form "vad=on" if the creator of the audio level > extension is providing VAD information, and "vad=off" if it is not. > > If vad=on is specified, the V bit in the audio header extension element is > defined as in the current draft. If vad=off is specified, the value of the > V bit is unspecified and MUST be ignored by receivers. > > If the extension attribute is not specified, the default is vad=on. > > This parameter is signaled in the extension attributes; it matches RFC > 5285's BNF in SDP. > > An SDP answer MUST include the same value of the vad= parameter as was > contained in the offer (for the same extension-ID value), if the answer > accepted the extension. > > An endpoint MAY negotiate either or both variants of the extension, with > the two forms having different extension ID values, using the standard RFC > 5285 mechanisms. > > Example SDP (showing both the syntax and the double-negotiation): > > a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level vad=on > a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level vad=off > > -- > Jonathan Lennox > jonathan@vidyo.com > > > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext > --bcaec5171e2dda1a4604a93d0fdf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It might make sense to have senders set V=3D0 when vad=3Doff, rather than l= eave it unspecified.

Also, if the far-end doesn't accept the ext= ension (doesn't return vad=3D in the answer), I would assume that V sho= uld be set to 0 anyway, and VAD is off.=A0 So I would question the default = being VAD=3Don.=A0 Having the default value of on, when then far-end doesn&= #39;t understand / accept the extension seems incorrect.

Regards,
Stephen Botzko

On Fri, Ju= l 29, 2011 at 5:32 PM, Jonathan Lennox <jonathan@vidyo.com> wrote:
In the working group session on Wednesday, there was a conclusion that it w= ould be best to signal in SDP whether an endpoint is putting meaningful VAD= data into the client-to-mixer audio level extension.

My proposal is as follows. =A0Please give feedback on whether this satisfie= s everyone's objections and requirements.

There is an optional "vad" parameter defined as the extension att= ributes field for the "urn:ietf:params:rtp-hdrext:ssrc-audio-level&quo= t; header extension element. It takes the form "vad=3Don" if the = creator of the audio level extension is providing VAD information, and &quo= t;vad=3Doff" if it is not.

If vad=3Don is specified, the V bit in the audio header extension element i= s defined as in the current draft. =A0If vad=3Doff is specified, the value = of the V bit is unspecified and MUST be ignored by receivers.

If the extension attribute is not specified, the default is vad=3Don.

This parameter is signaled in the extension attributes; it matches RFC 5285= 's <extensionattributes> BNF in SDP.

An SDP answer MUST include the same value of the vad=3D parameter as was co= ntained in the offer (for the same extension-ID value), if the answer accep= ted the extension.

An endpoint MAY negotiate either or both variants of the extension, with th= e two forms having different extension ID values, using the standard RFC 52= 85 mechanisms.

Example SDP (showing both the syntax and the double-negotiation):

a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level vad=3Don
a=3Dextmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level vad=3Doff

--
Jonathan Lennox
jonathan@vidyo.com


_______________________________________________
avtext mailing list
avtext@ietf.org
= https://www.ietf.org/mailman/listinfo/avtext

--bcaec5171e2dda1a4604a93d0fdf-- From jonathan@vidyo.com Fri Jul 29 16:18:11 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CACF221F8B53 for ; Fri, 29 Jul 2011 16:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.842 X-Spam-Level: X-Spam-Status: No, score=-1.842 tagged_above=-999 required=5 tests=[AWL=-0.443, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynWxJ14OJPzg for ; Fri, 29 Jul 2011 16:18:06 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id C4F6021F8B51 for ; Fri, 29 Jul 2011 16:18:06 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 69123417216; Fri, 29 Jul 2011 19:18:06 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB023.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id EC4624171FA; Fri, 29 Jul 2011 19:18:05 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB023.mail.lan ([10.110.17.23]) with mapi; Fri, 29 Jul 2011 19:17:55 -0400 From: Jonathan Lennox To: Stephen Botzko Date: Fri, 29 Jul 2011 19:18:05 -0400 Thread-Topic: [avtext] Proposed resolution of the presence of VAD in client-to-mixer audio levels Thread-Index: AcxORcUn1q2lnQZETBWFYIkiNfvSTQ== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "avtext@ietf.org" Subject: Re: [avtext] Proposed resolution of the presence of VAD in client-to-mixer audio levels X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 23:18:11 -0000 On Jul 29, 2011, at 6:47 PM, Stephen Botzko wrote: > It might make sense to have senders set V=3D0 when vad=3Doff, rather than= leave it unspecified. The motivation for leaving it unspecified was to allow a no-op conversion f= rom vad=3Don to vad=3Doff. To be sure, (byte & 0x7f) or (byte | 0x80) isn'= t a very computationally-expensive operation, though.=20 If we do want to set the bit to a fixed value, I think it'd be better to se= t V=3D1, since if someone's somehow confused about the setting of the vad= =3D flag, they're better off incorrectly interpreting a packet as having vo= ice when it doesn't, rather than incorrectly interpreting it as not having = voice when it does. =20 > Also, if the far-end doesn't accept the extension (doesn't return vad=3D = in the answer), I would assume that V should be set to 0 anyway, and VAD is= off. So I would question the default being VAD=3Don. Having the default = value of on, when then far-end doesn't understand / accept the extension se= ems incorrect. An answer with an extmap attribute whose vad=3D value -- specified as the e= xtensionattributes on urn:ietf:params:rtp-hdrext:ssrc-audio-level -- doesn'= t match the corresponding extmap attribute in the offer would be an invalid= answer, under the rules I've proposed. (It's not clear whether this is tru= e in general for extmaps' extensionattributes values in RFC 5285, but it se= ems like it would be a good idea for it to be). If you don't understand or don't want to use a extension header element, or= you don't like the vad=3D value offered, you simply don't include the rele= vant extmap attribute in the SDP answer. (This is the standard RFC 5285 of= fer/answer procedure.) -- Jonathan Lennox jonathan@vidyo.com From stephen.botzko@gmail.com Fri Jul 29 16:24:24 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A051321F8BF2 for ; Fri, 29 Jul 2011 16:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.736 X-Spam-Level: X-Spam-Status: No, score=-2.736 tagged_above=-999 required=5 tests=[AWL=-0.338, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKZZJn8VF4if for ; Fri, 29 Jul 2011 16:24:24 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id E0B8321F8BF1 for ; Fri, 29 Jul 2011 16:24:23 -0700 (PDT) Received: by vws12 with SMTP id 12so3830185vws.31 for ; Fri, 29 Jul 2011 16:24:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=f7Nxq17zjtS/34Vo98R+g9FxJ7hmRs+LQwyRh4PEPxk=; b=syp4fPE0xhvuYvJ7MCdjBu+zlRI61mszfXtzLWi4/MGFjKpvLKKTWoCF5df5BlB9BQ le1uKOm9LssHwAxGDfDPHuhvSCGa1sdVrGbE7/6zxKBgT8L8jhQLlj5X9IOlr8KjbBWf SRaqOm2HH0kMd4a+nqLQP//y10h34B5Tyn4jk= MIME-Version: 1.0 Received: by 10.52.23.1 with SMTP id i1mr2020530vdf.398.1311981863305; Fri, 29 Jul 2011 16:24:23 -0700 (PDT) Received: by 10.52.185.71 with HTTP; Fri, 29 Jul 2011 16:24:23 -0700 (PDT) In-Reply-To: References: Date: Fri, 29 Jul 2011 19:24:23 -0400 Message-ID: From: Stephen Botzko To: Jonathan Lennox Content-Type: multipart/alternative; boundary=20cf307cfc80ea007804a93d9402 Cc: "avtext@ietf.org" Subject: Re: [avtext] Proposed resolution of the presence of VAD in client-to-mixer audio levels X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 23:24:24 -0000 --20cf307cfc80ea007804a93d9402 Content-Type: text/plain; charset=ISO-8859-1 in-line Stephen Botzko On Fri, Jul 29, 2011 at 7:18 PM, Jonathan Lennox wrote: > > On Jul 29, 2011, at 6:47 PM, Stephen Botzko wrote: > > > It might make sense to have senders set V=0 when vad=off, rather than > leave it unspecified. > > The motivation for leaving it unspecified was to allow a no-op conversion > from vad=on to vad=off. To be sure, (byte & 0x7f) or (byte | 0x80) isn't a > very computationally-expensive operation, though. > > If we do want to set the bit to a fixed value, I think it'd be better to > set V=1, since if someone's somehow confused about the setting of the vad= > flag, they're better off incorrectly interpreting a packet as having voice > when it doesn't, rather than incorrectly interpreting it as not having voice > when it does. > that is reasonable. > > > Also, if the far-end doesn't accept the extension (doesn't return vad= in > the answer), I would assume that V should be set to 0 anyway, and VAD is > off. So I would question the default being VAD=on. Having the default > value of on, when then far-end doesn't understand / accept the extension > seems incorrect. > > An answer with an extmap attribute whose vad= value -- specified as the > extensionattributes on urn:ietf:params:rtp-hdrext:ssrc-audio-level -- > doesn't match the corresponding extmap attribute in the offer would be an > invalid answer, under the rules I've proposed. (It's not clear whether this > is true in general for extmaps' extensionattributes values in RFC 5285, but > it seems like it would be a good idea for it to be). > > If you don't understand or don't want to use a extension header element, or > you don't like the vad= value offered, you simply don't include the relevant > extmap attribute in the SDP answer. (This is the standard RFC 5285 > offer/answer procedure.) > > Yes So if vad is not included in the SDP answer, than vad is off? > > -- > Jonathan Lennox > jonathan@vidyo.com > > > --20cf307cfc80ea007804a93d9402 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable in-line
Stephen Botzko

On Fri, Jul 29,= 2011 at 7:18 PM, Jonathan Lennox <jonathan@vidyo.com> wrote:

On Jul 29, 2011, at 6:47 PM, Stephen Botzko wrote:

> It might make sense to have senders set V=3D0 when vad=3Doff, rather t= han leave it unspecified.

The motivation for leaving it unspecified was to allow a no-op conver= sion from vad=3Don to vad=3Doff. =A0To be sure, (byte & 0x7f) or (byte = | 0x80) isn't a very computationally-expensive operation, though.

If we do want to set the bit to a fixed value, I think it'd be better t= o set V=3D1, since if someone's somehow confused about the setting of t= he vad=3D flag, they're better off incorrectly interpreting a packet as= having voice when it doesn't, rather than incorrectly interpreting it = as not having voice when it does.
=A0
that is reasonable.

> Also, if the far-end doesn't accept the extension (doesn't ret= urn vad=3D in the answer), I would assume that V should be set to 0 anyway,= and VAD is off. =A0So I would question the default being VAD=3Don. =A0Havi= ng the default value of on, when then far-end doesn't understand / acce= pt the extension seems incorrect.

An answer with an extmap attribute whose vad=3D value -- specified as= the extensionattributes on urn:ietf:params:rtp-hdrext:ssrc-audio-level -- = doesn't match the corresponding extmap attribute in the offer would be = an invalid answer, under the rules I've proposed. (It's not clear w= hether this is true in general for extmaps' extensionattributes values = in RFC 5285, but it seems like it would be a good idea for it to be).

If you don't understand or don't want to use a extension header ele= ment, or you don't like the vad=3D value offered, you simply don't = include the relevant extmap attribute in the SDP answer. =A0(This is the st= andard RFC 5285 offer/answer procedure.)

Yes=A0 So if vad is no= t included in the SDP answer, than vad is off?

--
Jonathan Lennox
jonathan@vidyo.com



--20cf307cfc80ea007804a93d9402-- From jonathan@vidyo.com Fri Jul 29 16:36:38 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1D611E807E for ; Fri, 29 Jul 2011 16:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dk3f7gYLm1nH for ; Fri, 29 Jul 2011 16:36:37 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE3F21F8B00 for ; Fri, 29 Jul 2011 16:36:37 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 502AC553717; Fri, 29 Jul 2011 19:36:37 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB016.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id CBFF2553675; Fri, 29 Jul 2011 19:36:36 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB016.mail.lan ([10.110.17.16]) with mapi; Fri, 29 Jul 2011 19:36:32 -0400 From: Jonathan Lennox To: Stephen Botzko Date: Fri, 29 Jul 2011 19:36:35 -0400 Thread-Topic: [avtext] Proposed resolution of the presence of VAD in client-to-mixer audio levels Thread-Index: AcxOSFrl6CnL3Kd3QLyVMHy1XcEC9g== Message-ID: <6ADD3479-AE6B-43C8-9705-484DE78026F4@vidyo.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_6ADD3479AE6B43C89705484DE78026F4vidyocom_" MIME-Version: 1.0 Cc: "avtext@ietf.org" Subject: Re: [avtext] Proposed resolution of the presence of VAD in client-to-mixer audio levels X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 23:36:38 -0000 --_000_6ADD3479AE6B43C89705484DE78026F4vidyocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Jul 29, 2011, at 7:24 PM, Stephen Botzko wrote: On Fri, Jul 29, 2011 at 7:18 PM, Jonathan Lennox > wrote: An answer with an extmap attribute whose vad=3D value -- specified as the e= xtensionattributes on urn:ietf:params:rtp-hdrext:ssrc-audio-level -- doesn'= t match the corresponding extmap attribute in the offer would be an invalid= answer, under the rules I've proposed. (It's not clear whether this is tru= e in general for extmaps' extensionattributes values in RFC 5285, but it se= ems like it would be a good idea for it to be). If you don't understand or don't want to use a extension header element, or= you don't like the vad=3D value offered, you simply don't include the rele= vant extmap attribute in the SDP answer. (This is the standard RFC 5285 of= fer/answer procedure.) Yes So if vad is not included in the SDP answer, than vad is off? If the extmap isn't included in the SDP answer, then the whole audio level = extension header is off, i.e. must not be used. If the extmap is included in the SDP answer, then whether to set the V bit = in the header extension element is controlled by the value of the parameter= in the answer, which must match its value in the offer. This parameter only controls the contents of the extension header; this doe= sn't in any way signal or control "vad" in the sense of whether either endp= oint should use silence suppression or discontinuous transmission or comfor= t noise or anything like that. Would it be clearer to name the attribute something like "vbit" rather than= "vad", to emphasize that this is only specifying the contents of the heade= r extension element, not anything else? -- Jonathan Lennox jonathan@vidyo.com --_000_6ADD3479AE6B43C89705484DE78026F4vidyocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
On Jul 29, 2= 011, at 7:24 PM, Stephen Botzko wrote:

On Fri, Jul 29, 2011 at 7:18 PM, Jonathan Lennox <jonathan@vidyo.com> wrote:

An answer with an extmap attribute whose vad=3D value -- specified as= the extensionattributes on urn:ietf:params:rtp-hdrext:ssrc-audio-level -- = doesn't match the corresponding extmap attribute in the offer would be an i= nvalid answer, under the rules I've proposed. (It's not clear whether this = is true in general for extmaps' extensionattributes values in RFC 5285, but= it seems like it would be a good idea for it to be).

If you don't understand or don't want to use a extension header element, or= you don't like the vad=3D value offered, you simply don't include the rele= vant extmap attribute in the SDP answer.  (This is the standard RFC 52= 85 offer/answer procedure.)

Yes  So if vad is= not included in the SDP answer, than vad is off?

If the extmap isn't included in the SDP answer,= then the whole audio level extension header is off, i.e. must not be used.=

If the extmap is included in the SDP answer, then= whether to set the V bit in the header extension element is controlled by = the value of the parameter in the answer, which must match its value in the= offer.

This parameter only controls the contents = of the extension header; this doesn't in any way signal or control "vad" in= the sense of whether either endpoint should use silence suppression or dis= continuous transmission or comfort noise or anything like that.
<= br>
Would it be clearer to name the attribute something like "vbi= t" rather than "vad", to emphasize that this is only specifying the content= s of the header extension element, not anything else?

--
Jonathan Lennox
jonathan@vidyo.com

= --_000_6ADD3479AE6B43C89705484DE78026F4vidyocom_-- From keith.drage@alcatel-lucent.com Fri Jul 29 17:51:47 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A24FD11E80D3 for ; Fri, 29 Jul 2011 17:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.962 X-Spam-Level: X-Spam-Status: No, score=-105.962 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9uaq1XHn8LqU for ; Fri, 29 Jul 2011 17:51:47 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id AB9E111E80B8 for ; Fri, 29 Jul 2011 17:51:46 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p6U0pdcK012182 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 30 Jul 2011 02:51:40 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Sat, 30 Jul 2011 02:51:39 +0200 From: "DRAGE, Keith (Keith)" To: "Kevin P. Fleming" , "avtext@ietf.org" Date: Sat, 30 Jul 2011 02:51:38 +0200 Thread-Topic: [avtext] Current status of audio level drafts after face to face meeting (and confirmation of decisions) Thread-Index: AcxOMks/6FpQYX0UQe+jt3CAyI20iAAIFNEQ Message-ID: References: <4E331EE9.6030005@digium.com> In-Reply-To: <4E331EE9.6030005@digium.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Subject: Re: [avtext] Current status of audio level drafts after face to face meeting (and confirmation of decisions) X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2011 00:51:47 -0000 More specific details have been posted by Jonathan. Yes it means a SDP parameter. The notes are not yet available but I suspect they will not give a great de= al of detail behind the decision. I think the general opinion was that peop= le wanted something explicit. Regards Keith > -----Original Message----- > From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On Behalf > Of Kevin P. Fleming > Sent: 29 July 2011 21:58 > To: avtext@ietf.org > Subject: Re: [avtext] Current status of audio level drafts after face to > face meeting (and confirmation of decisions) >=20 > On 07/29/2011 02:19 PM, DRAGE, Keith (Keith) wrote: > > For: > > > > draft-ietf-avtext-mixer-to-client-audio-level > > > > The WGLC has been held and the comments made are mainly editorial. The > document will be updated shortly to address these comments, and the > document is ready for publication request. A poll in the meeting > identified a significant number of people had read the WGLC version, and > that it was ready for publication. > > > > draft-ietf-avtext-client-to-mixer-audio-level > > > > The WGLC has been held. > > > > There is one significant technical enhancement to be made, where the > proposal is to define an SDP extension to Indicate Voice Activity > Detection (VAD) support (or lack of). This was the mechanism that had > support in the face to face meeting, and I'll use this message to seek > confirmation of that decision on the list. > > > > We'll try and get this extension text to the list. We will get the next > version of the draft reviewed by MMUSIC experts for this SDP content. > > > > The document will be updated shortly. A poll in the meeting identified = a > significant number of people had read the WGLC version, and that it was > ready for publication. > > > > Apart from this MMUSIC review we will be looking to do the publication > request shortly. > > > > And if you have issues with the face-to-face meeting decision to use an > SDP extension to Indicate Voice Activity Detection (VAD) support then > please post to the list as soon as possible. >=20 > I presume you mean SDP 'parameter' here, right? >=20 > Would this parameter indicate: >=20 > * that the offerer has VAD ability and will employ it for reporting > audio levels >=20 > * that the offerer wishes the answerer to employ VAD if it can when it > reports audio levels >=20 > * that the offerer *requires* the answerer to employ VAD when it reports > audio levels >=20 > * something else? >=20 > Sorry, I missed the meeting yesterday and I don't think the minutes have > been posted yet or I'd have consulted them before replying :-) >=20 > -- > Kevin P. Fleming > Digium, Inc. | Director of Software Technologies > Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpflemin= g > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > Check us out at www.digium.com & www.asterisk.org > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From keith.drage@alcatel-lucent.com Fri Jul 29 17:58:44 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35AD421F8B07; Fri, 29 Jul 2011 17:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.672 X-Spam-Level: X-Spam-Status: No, score=-103.672 tagged_above=-999 required=5 tests=[AWL=-2.023, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_93=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qf1YJsRmDVYb; Fri, 29 Jul 2011 17:58:43 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [62.23.212.42]) by ietfa.amsl.com (Postfix) with ESMTP id A03AB21F8B02; Fri, 29 Jul 2011 17:58:42 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p6U0wd1H032483 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 30 Jul 2011 02:58:40 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Sat, 30 Jul 2011 02:58:40 +0200 From: "DRAGE, Keith (Keith)" To: "rfc-editor@rfc-editor.org" , "ietf-announce@ietf.org" , "rfc-dist@rfc-editor.org" Date: Sat, 30 Jul 2011 02:58:37 +0200 Thread-Topic: [avtext] RFC 6332 on Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs) Thread-Index: AcxOPgEv74AkQzrLTw+TODfzoXBGigAFZWTg Message-ID: References: <20110729222011.BC54198C538@rfc-editor.org> In-Reply-To: <20110729222011.BC54198C538@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84 Cc: "avtext@ietf.org" Subject: Re: [avtext] RFC 6332 on Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs) X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2011 00:58:44 -0000 Thanks to Ali Begen and Eric Friedrich for progressing this through to a pu= blished document. Keith > -----Original Message----- > From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On Behalf > Of rfc-editor@rfc-editor.org > Sent: 29 July 2011 23:20 > To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org > Cc: avtext@ietf.org; rfc-editor@rfc-editor.org > Subject: [avtext] RFC 6332 on Multicast Acquisition Report Block Type for > RTP Control Protocol (RTCP) Extended Reports (XRs) >=20 >=20 > A new Request for Comments is now available in online RFC libraries. >=20 >=20 > RFC 6332 >=20 > Title: Multicast Acquisition Report Block Type > for RTP Control Protocol (RTCP) Extended > Reports (XRs) > Author: A. Begen, E. Friedrich > Status: Standards Track > Stream: IETF > Date: July 2011 > Mailbox: abegen@cisco.com, > efriedri@cisco.com > Pages: 16 > Characters: 35217 > Updates/Obsoletes/SeeAlso: None >=20 > I-D Tag: draft-ietf-avtext-multicast-acq-rtcp-xr-06.txt >=20 > URL: http://www.rfc-editor.org/rfc/rfc6332.txt >=20 > In most RTP-based multicast applications, the RTP source sends inter- > related data. Due to this interdependency, randomly joining RTP > receivers usually cannot start consuming the multicast data right > after they join the session. Thus, they often experience a random > acquisition delay. An RTP receiver can use one or more different > approaches to achieve rapid acquisition. Yet, due to various > factors, performance of the rapid acquisition methods usually varies. > Furthermore, in some cases, the RTP receiver can do a simple > multicast join (in other cases, it is compelled to do so). For > quality reporting, monitoring, and diagnostic purposes, it is > important to collect detailed information from the RTP receivers > about their acquisition and presentation experiences. This document > addresses this issue by defining a new report block type, called the > Multicast Acquisition (MA) report block, within the framework of RTP > Control Protocol (RTCP) Extended Reports (XRs) (RFC 3611). This > document also defines the necessary signaling of the new MA report > block type in the Session Description Protocol (SDP). [STANDARDS-TRACK] >=20 > This document is a product of the Audio/Video Transport Extensions Workin= g > Group of the IETF. >=20 > This is now a Proposed Standard Protocol. >=20 > STANDARDS TRACK: This document specifies an Internet standards track > protocol for the Internet community,and requests discussion and > suggestions > for improvements. Please refer to the current edition of the Internet > Official Protocol Standards (STD 1) for the standardization state and > status of this protocol. Distribution of this memo is unlimited. >=20 > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >=20 > For searching the RFC series, see http://www.rfc- > editor.org/rfcsearch.html. > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. >=20 > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. >=20 >=20 > The RFC Editor Team > Association Management Solutions, LLC >=20 >=20 > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext