From mailnull@www1.ietf.org Tue Apr 1 10:57:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23185 for ; Tue, 1 Apr 2003 10:57:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31GLhV16177 for avt-archive@odin.ietf.org; Tue, 1 Apr 2003 11:21:43 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31GJmK15944; Tue, 1 Apr 2003 11:19:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31GI2K15727 for ; Tue, 1 Apr 2003 11:18:02 -0500 Received: from mail.pel.panasonic.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22960 for ; Tue, 1 Apr 2003 10:53:41 -0500 (EST) Received: from atrgreyj (vw1.pel.panasonic.de [10.78.238.55]) by mail.pel.panasonic.de (__________PEL__Mail-Server__________) with SMTP id <0HCO008FV9IZAG@panasonic.de> for avt@ietf.org; Tue, 1 Apr 2003 17:54:36 +0200 (MET DST) Date: Tue, 01 Apr 2003 17:54:36 +0200 From: Jose Rey Subject: RE: [AVT] SDP signaling for RTCP XR format In-reply-to: <3E885013.4090804@era.ericsson.se> To: Magnus Westerlund Cc: IETF AVT WG Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=utf-8 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h31GI2K15728 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Magnus, please see my asnwers inline, I cut much of the text for readibility. > Yes, I will try to clarify this. My intention is that the SDP > parameters > should be used if there is SDP signaling available for this > application. > The one exception is that application foo always uses these reports. > And since you are running the client for application foo it > knows that > it shall use the report formats. > > >To solve this, why not declare some kind of attribute in SDP > that defines the set of feedback messages that the > application needs of? > > > > You mean in the general case for like SDES information types, etc.? I think Colin's comment solves this question: > RTP allows applications to send new types of RTCP packet, > even if these are > not explicitly signalled. RTCP XR shouldn't impose additional > restrictions. > > Colin --- --- As to the behaviour in O/A model, I went over it again and this is what I got: * answers to offers of cat1-params (sendonly from O->A): if present in response -> SHOULD be sent; if not present -> MAY be sent, whereby - this last MAY allows for undeclared use of any extension and, - the SHOULD is based on the supposition that if both the offerer and answerer declare a cat1-param it is because it should be better(or even necessary) for the streaming session and will be used, otherwise the A could omit it. * answers to offers of cat2-params (sendonly from O->A): whether present in answer or not-> MAY be sent; - this is more flexible since the decision (and probably the benefit) on whether to use cat2-params lies at the receiver. A MUST would avoid sending an undeclared extension and also it cannot be assumed the sender is reporting on all extensions it supports. Moreover, it should be stated that answerer must have some mechanism to realize that if feedback of cat2 being sent doesn't not get an answer then it should stop doing so. Is this complete? Comments? > > No, I think you are missing one thing where the DLRR blocks > can become > enormous. If you are part of an ASM group with 100 > participants and they > all send the Receiver Timestamp block in there RTCP reports. Normally > you will send on average at the same pace as all others. > Therefore your > DLRR response will contain 100 sources. As everybody is doing > this the > average RTCP size will be large. Therefore the usage of > option 1 below > seems to be limited to small groups. When using option 2 only > a few out > of all sending the Receiver Timestamp block actually answers with the > delay information. Therefore only the sender reporting will > be effected > by this. > Ok, I was missing that. > I hesitant to write policy that actually is application or profile > dependent. However defining a default behavior I find > acceptable with a > side note that this can be replaced by application or profile > specifications. > Yes , the last sentence reflects my intention. cheers, José _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Apr 2 06:34:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04382 for ; Wed, 2 Apr 2003 06:34:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h32BwjH30235 for avt-archive@odin.ietf.org; Wed, 2 Apr 2003 06:58:45 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32Bv8K30163; Wed, 2 Apr 2003 06:57:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32BthK30108 for ; Wed, 2 Apr 2003 06:55:43 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04276 for ; Wed, 2 Apr 2003 06:31:00 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h32BXQrs008356; Wed, 2 Apr 2003 13:33:26 +0200 (MEST) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2A4RQ9B2; Wed, 2 Apr 2003 13:33:27 +0200 Message-ID: <3E8ACA89.90000@era.ericsson.se> Date: Wed, 02 Apr 2003 13:33:29 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Timur Friedman CC: IETF AVT WG Subject: Re: [AVT] SDP signaling for RTCP XR format References: <200303311546.h2VFkivm002320@purple.nge.isi.edu> <00cc01c2f7b7$dd92daa0$a648e384@lip6.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi See below: Timur Friedman wrote: >Colin Perkins wrote: > > > >>--> Magnus Westerlund writes: >>... >> >> >>>>2.- Just curious, why are the report blocks used without signaling? It >>>>would be helpful to include the reason for this in the draft (if it's >>>> >>>> >not > > >>>>there already and I missed it) >>>> >>>> >>>As I understand it the use case for having report blocks without >>>signaling is that you know that you are using application foo. Foo has >>>defined that we will use certain report blocks. Then it is not necessary >>>to use the signaling, which may in fact not exist. Certain report blocks >>>may be used to discover if the other end parts understand them. For >>>example the RTT measurement can be tried a few times to see if any >>>receiver responds to them. >>> >>> >>RTP allows applications to send new types of RTCP packet, even if these >> >> >are > > >>not explicitly signalled. RTCP XR shouldn't impose additional >> >> >restrictions. > >The draft will be sure to specify that SDP signalling is an optional >mechanism, to avoid any confusion. > >- Timur > > > Yes, there is a couple of different approaches here. I agree that the usage of SDP signaling is optional. And the usage needs to be decided on application level. However I think that if your application is using SDP signaling, the signaling needs to be followed. Otherwise it is impossible to have meaningful signaling. For example take the RTT functionality. If you understand it and the arranger of a multicast session decides that only senders SHALL or SHOULD respond with DLRR packets. Unless the signaling allows us to use normative language to that effect the whole signaling is useless. Sending DLRR packets from all receiver is problem in multicast groups. Therefore there is need for using SHOULD or SHALL in the signaling description. However there seem to be need to clarify that the usage of the signaling is optional and depends on the application. Any comments on this? Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Apr 2 06:47:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05340 for ; Wed, 2 Apr 2003 06:47:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h32CBYQ31785 for avt-archive@odin.ietf.org; Wed, 2 Apr 2003 07:11:34 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32CA9K31721; Wed, 2 Apr 2003 07:10:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32C9qK31696 for ; Wed, 2 Apr 2003 07:09:52 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05071 for ; Wed, 2 Apr 2003 06:45:08 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h32BlZUE009917; Wed, 2 Apr 2003 13:47:35 +0200 (MEST) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2A4KXNNV; Wed, 2 Apr 2003 13:47:36 +0200 Message-ID: <3E8ACDDA.4060207@era.ericsson.se> Date: Wed, 02 Apr 2003 13:47:38 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jose Rey CC: IETF AVT WG Subject: Re: [AVT] SDP signaling for RTCP XR format References: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Jose, Comments below: Jose Rey wrote: >Hi Magnus, > > >please see my asnwers inline, I cut much of the text for readibility. > > > >>Yes, I will try to clarify this. My intention is that the SDP >>parameters >>should be used if there is SDP signaling available for this >>application. >>The one exception is that application foo always uses these reports. >>And since you are running the client for application foo it >>knows that >>it shall use the report formats. >> >> >> >>>To solve this, why not declare some kind of attribute in SDP >>> >>> >>that defines the set of feedback messages that the >>application needs of? >> >> >>You mean in the general case for like SDES information types, etc.? >> >> > >I think Colin's comment solves this question: > > > > RTP allows applications to send new types of RTCP packet, > > even if these are > > not explicitly signalled. RTCP XR shouldn't impose additional > > restrictions. > > > > Colin > >--- >--- > >As to the behaviour in O/A model, I went over it again and this is what I got: > >* answers to offers of cat1-params (sendonly from O->A): if present in response -> SHOULD be sent; if not present -> MAY be sent, whereby > - this last MAY allows for undeclared use of any extension and, > - the SHOULD is based on the supposition that if both the offerer and answerer declare a cat1-param it is because it should be better(or even necessary) for the streaming session and will be used, otherwise the A could omit it. > > Yes, I can agree with this. There is no significant harm in sending XR blocks that are not desired. However I think one should have a good motivation why one would not signal this. I would like to have some cautioning wording regarding the MAY. That one should have some reason why one sends them after all. >* answers to offers of cat2-params (sendonly from O->A): whether present in answer or not-> MAY be sent; >- this is more flexible since the decision (and probably the benefit) on whether to use cat2-params lies at the receiver. A MUST would avoid sending an undeclared extension and also it cannot be assumed the sender is reporting on all extensions it supports. > > I think one should make a firm distinction here. If one uses the SDP signaling and declares a cat-2 functionality in a offer, then the answerer knows that it supports the functionality. If not included a answerer MAY try but the situation is unknown. There is also need for a receiver of SDP to follow any declaration if present. To avoid this miss use of RTCP bandwidth any receiver of the SDP MUST follow the declaration that DLRR blocks SHALL NOT be sent. >Moreover, it should be stated that answerer must have some mechanism to realize that if feedback of cat2 being sent doesn't not get an answer then it should stop doing so. Is this complete? Comments? > > > I agree, however I think this belongs in the section on the XR block definition. Stop sending timestamp reports if no one is answering. And don't send DLRR blocks unless someone is sending timestamp reports. > > I think we are converging on intentions and what needs to be clarified. I will updated the text a republish it. However I suffer from a cold and do not know how much I can work. I will do my best to provide an updated text as soon as possible. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Apr 2 07:40:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07142 for ; Wed, 2 Apr 2003 07:40:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h32D4qc02514 for avt-archive@odin.ietf.org; Wed, 2 Apr 2003 08:04:52 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32D4TK02492; Wed, 2 Apr 2003 08:04:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32D3BK02415 for ; Wed, 2 Apr 2003 08:03:11 -0500 Received: from mail.pel.panasonic.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07119 for ; Wed, 2 Apr 2003 07:38:25 -0500 (EST) Received: from atrgreyj (vw1.pel.panasonic.de [10.78.238.55]) by mail.pel.panasonic.de (__________PEL__Mail-Server__________) with SMTP id <0HCP00I83V7YEG@panasonic.de> for avt@ietf.org; Wed, 2 Apr 2003 14:40:47 +0200 (MET DST) Date: Wed, 02 Apr 2003 14:40:48 +0200 From: Jose Rey Subject: RE: [AVT] SDP signaling for RTCP XR format In-reply-to: <3E8ACDDA.4060207@era.ericsson.se> To: Magnus Westerlund Cc: IETF AVT WG Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=UTF-8 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h32D3CK02416 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Magnus, see inline, > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@era.ericsson.se] > Sent: Wednesday, April 02, 2003 1:48 PM > To: Jose Rey > Cc: IETF AVT WG > Subject: Re: [AVT] SDP signaling for RTCP XR format > > > Hi Jose, > > Comments below: > > Jose Rey wrote: > > >Hi Magnus, > > > > > >please see my asnwers inline, I cut much of the text for readibility. > > > > > > > >>Yes, I will try to clarify this. My intention is that the SDP > >>parameters > >>should be used if there is SDP signaling available for this > >>application. > >>The one exception is that application foo always uses > these reports. > >>And since you are running the client for application foo it > >>knows that > >>it shall use the report formats. > >> > >> > >> > >>>To solve this, why not declare some kind of attribute in SDP > >>> > >>> > >>that defines the set of feedback messages that the > >>application needs of? > >> > >> > >>You mean in the general case for like SDES information types, etc.? > >> > >> > > > >I think Colin's comment solves this question: > > > > > > > RTP allows applications to send new types of RTCP packet, > > > even if these are > > > not explicitly signalled. RTCP XR shouldn't impose additional > > > restrictions. > > > > > > Colin > > > >--- > >--- > > > >As to the behaviour in O/A model, I went over it again and > this is what I got: > > > >* answers to offers of cat1-params (sendonly from O->A): if > present in response -> SHOULD be sent; if not present -> MAY > be sent, whereby > > - this last MAY allows for undeclared use of any extension and, > > - the SHOULD is based on the supposition that if both the > offerer and answerer declare a cat1-param it is because it > should be better(or even necessary) for the streaming session > and will be used, otherwise the A could omit it. > > > > > > Yes, I can agree with this. There is no significant harm in > sending XR > blocks that are not desired. However I think one should have a good > motivation why one would not signal this. I would like to have some > cautioning wording regarding the MAY. That one should have > some reason > why one sends them after all. > > >* answers to offers of cat2-params (sendonly from O->A): > whether present in answer or not-> MAY be sent; > >- this is more flexible since the decision (and probably the > benefit) on whether to use cat2-params lies at the receiver. > A MUST would avoid sending an undeclared extension and also > it cannot be assumed the sender is reporting on all > extensions it supports. > > > I think one should make a firm distinction here. If one uses the SDP > signaling and declares a cat-2 functionality in a offer, then the > answerer knows that it supports the functionality. If not included a > answerer MAY try but the situation is unknown. There is also > need for a > receiver of SDP to follow any declaration if present. To > avoid this miss > use of RTCP bandwidth any receiver of the SDP MUST follow the > declaration that DLRR blocks SHALL NOT be sent. > I am not sure I understand this paragraph. You want to prohibit it if not present in the offer? For that we should require that O always lists ALL of the extensions it supports, so that it makes no sense for A to request a cat-2 parameter. Makes this requirement sense? Also for other future cat-2 parameters? If > >Moreover, it should be stated that answerer must have some > mechanism to realize that if feedback of cat2 being sent > doesn't not get an answer then it should stop doing so. Is > this complete? Comments? > > > > > > > I agree, however I think this belongs in the section on the XR block > definition. Stop sending timestamp reports if no one is > answering. And > don't send DLRR blocks unless someone is sending timestamp reports. > Yes. > > > > > I think we are converging on intentions and what needs to be > clarified. > I will updated the text a republish it. However I suffer from > a cold and > do not know how much I can work. I will do my best to provide an > updated text as soon as possible. Don't worry, just get well first :) cheers, José > > Best Regards > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research ERA/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se > > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Apr 2 16:24:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09924 for ; Wed, 2 Apr 2003 16:24:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h32Lmwm20507 for avt-archive@odin.ietf.org; Wed, 2 Apr 2003 16:48:58 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32LmHK20442; Wed, 2 Apr 2003 16:48:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32LktK20337 for ; Wed, 2 Apr 2003 16:46:55 -0500 Received: from isis.lip6.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09765 for ; Wed, 2 Apr 2003 16:21:59 -0500 (EST) Received: from tibre.lip6.fr (tibre.lip6.fr [132.227.74.2]) by isis.lip6.fr (8.12.9/jtpda-5.4+victor) with ESMTP id h32LORqq026225 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) ; Wed, 2 Apr 2003 23:24:27 +0200 X-pt: isis.lip6.fr Received: from doris (doris [132.227.72.166]) by tibre.lip6.fr (8.11.6p2/8.11.6) with SMTP id h32LORp26241; Wed, 2 Apr 2003 23:24:27 +0200 (CEST) Message-ID: <004501c2f94d$78a2ac00$a648e384@lip6.fr> From: "Timur Friedman" To: "Magnus Westerlund" Cc: "IETF AVT WG" References: <200303311546.h2VFkivm002320@purple.nge.isi.edu> <00cc01c2f7b7$dd92daa0$a648e384@lip6.fr> <3E8ACA89.90000@era.ericsson.se> Subject: Re: [AVT] SDP signaling for RTCP XR format Date: Wed, 2 Apr 2003 21:24:25 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Scanned-By: isis.lip6.fr Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Magnus Westerlund wrote, quoting Timur Friedman : > >The draft will be sure to specify that SDP signalling is an optional > >mechanism, to avoid any confusion. > > > >- Timur > > > > > > > Yes, there is a couple of different approaches here. > > I agree that the usage of SDP signaling is optional. And the usage needs > to be decided on application level. However I think that if your > application is using SDP signaling, the signaling needs to be followed. Agreed that if the application is using SDP signalling and XR packets then it must adhere to the SDP signalling mechanism defined for XR packets. We'll be sure to state this. - Timur Friedman _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Apr 2 16:27:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10142 for ; Wed, 2 Apr 2003 16:27:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h32LqGl20857 for avt-archive@odin.ietf.org; Wed, 2 Apr 2003 16:52:16 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32LlRK20361; Wed, 2 Apr 2003 16:47:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32Lj2K20225 for ; Wed, 2 Apr 2003 16:45:02 -0500 Received: from isis.lip6.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09717 for ; Wed, 2 Apr 2003 16:20:05 -0500 (EST) Received: from tibre.lip6.fr (tibre.lip6.fr [132.227.74.2]) by isis.lip6.fr (8.12.9/jtpda-5.4+victor) with ESMTP id h32LMWqq026103 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) ; Wed, 2 Apr 2003 23:22:32 +0200 X-pt: isis.lip6.fr Received: from doris (doris [132.227.72.166]) by tibre.lip6.fr (8.11.6p2/8.11.6) with SMTP id h32LMWp26213; Wed, 2 Apr 2003 23:22:32 +0200 (CEST) Message-ID: <004401c2f94d$344ec250$a648e384@lip6.fr> From: "Timur Friedman" To: "Jose Rey" , "Magnus Westerlund" Cc: "IETF AVT WG" References: Subject: Re: [AVT] SDP signaling for RTCP XR format Date: Wed, 2 Apr 2003 21:22:29 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Scanned-By: isis.lip6.fr Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jose Rey wrote, quoting Magnus Westerlund: > > I agree, however I think this belongs in the section on the XR block > > definition. Stop sending timestamp reports if no one is > > answering. And > > don't send DLRR blocks unless someone is sending timestamp reports. > > > > Yes. How would we define the time after which an application, having received no DLRRs, should stop sending Timestamp Report blocks? The time period seems to me highly application dependent, and so best left out of the document. Agreed that a DLRR block makes no sense in the absence of a Timestamp Report block. - Timur Friedman _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Apr 2 16:34:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10460 for ; Wed, 2 Apr 2003 16:34:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h32LwXt21451 for avt-archive@odin.ietf.org; Wed, 2 Apr 2003 16:58:33 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32Lv6K21341; Wed, 2 Apr 2003 16:57:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32LuuK21320 for ; Wed, 2 Apr 2003 16:56:56 -0500 Received: from isis.lip6.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10394 for ; Wed, 2 Apr 2003 16:31:59 -0500 (EST) Received: from tibre.lip6.fr (tibre.lip6.fr [132.227.74.2]) by isis.lip6.fr (8.12.9/jtpda-5.4+victor) with ESMTP id h32LYRqq026739 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) ; Wed, 2 Apr 2003 23:34:27 +0200 X-pt: isis.lip6.fr Received: from doris (doris [132.227.72.166]) by tibre.lip6.fr (8.11.6p2/8.11.6) with SMTP id h32LYRp26461; Wed, 2 Apr 2003 23:34:27 +0200 (CEST) Message-ID: <005301c2f94e$de57b350$a648e384@lip6.fr> From: "Timur Friedman" To: "Magnus Westerlund" , "Jose Rey" Cc: "IETF AVT WG" References: <3E87F4CC.7080704@era.ericsson.se> Subject: Re: [AVT] SDP signaling for RTCP XR format Date: Wed, 2 Apr 2003 21:34:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Scanned-By: isis.lip6.fr Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Magnus Westerlund wrote: > Here one issue actually surface. Is it the right thing to restrict a > receiver to not send DLRR report block unless the usage has been > explicitly signaled in multicast? The reason why I see a need to > restrict it is the potential to create enormous report blocks in large > multicast groups. And the only result is that the different receivers > will determine there RTT to other receivers which seems to be rather > pointless in most application. It seems that you would in fact like to > control this operation to a few different operation modes in multicast. > 1. fully meshed, both senders and receivers return DLRR blocks. > 2. Sender only, only senders return DLRR blocks. > 3. functionality off, no one responds with DLRR blocks. > > Should we define such a distinction in the signaling? I agree that the signalling should allow each of these modes. But also the mode in which certain receivers calculate RTTs amongst themselves. While many applications might not use this mode, we do not want to unnecessarily rule it out. Here are two examples of when the mode could be used. First, receivers might measure RTTs amongst themselves as a prelude to some of them becoming senders (multicast "repair servers", retansmitting lost packets, for instance). Second, a network monitoring tool might wish to measure its RTT to certain receivers. - Timur Friedman _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Apr 3 13:30:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05763 for ; Thu, 3 Apr 2003 13:30:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h33IWvB12495 for avt-archive@odin.ietf.org; Thu, 3 Apr 2003 13:32:57 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33IWNK12460; Thu, 3 Apr 2003 13:32:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33IUpK12292 for ; Thu, 3 Apr 2003 13:30:51 -0500 Received: from snap.CS.Berkeley.EDU (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05678 for ; Thu, 3 Apr 2003 13:27:58 -0500 (EST) Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.11.6/8.9.3-ZUUL) id h33ITKG21170 for avt@ietf.org; Thu, 3 Apr 2003 10:29:20 -0800 Date: Thu, 3 Apr 2003 10:29:20 -0800 From: John Lazzaro Message-Id: <200304031829.h33ITKG21170@snap.CS.Berkeley.EDU> To: avt@ietf.org Subject: [AVT] MWPP and the marker bit ... Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Hi everyone, Looking for input on the following MWPP issue ... From the draft-ietf-avt-mpeg4-simple-07.txt: Marker (M) bit: The M bit is set to 1 to indicate that the RTP packet payload contains either the final fragment of a fragmented Access Unit or one or more complete Access Units. MWPP needs 1-packet-per-access-unit semantics to work properly, and so MWPP defines the M bit to always 1 for mpeg4-generic use. Up until now, I've also defined the M bit to always be 1 for "native MWPP streams" (mwpp MIME type), on the theory the confusion that would come from having two different M bit uses for the different MIME types outweighs the advantage of using the M bit for something useful. However, the recent discussion on the list over voice-codec M bit use has made me wonder if I should instead define the M bit for the mwpp MIME type to have a meaning akin to the voice-spurt M bit meaning. For mwpp, this semantic would be "any packet that codes at least one new MIDI command", and the purpose would be to let receivers quickly distinguish empty "guard packets" from packets with new data. Any input one way or the other is appreciated -- I'm undecided at this point ... ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro ------------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Apr 3 13:50:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06743 for ; Thu, 3 Apr 2003 13:50:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h33Iqi515509 for avt-archive@odin.ietf.org; Thu, 3 Apr 2003 13:52:44 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33IqHK15484; Thu, 3 Apr 2003 13:52:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33Ip9K15443 for ; Thu, 3 Apr 2003 13:51:09 -0500 Received: from snap.CS.Berkeley.EDU (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06666 for ; Thu, 3 Apr 2003 13:48:14 -0500 (EST) Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.11.6/8.9.3-ZUUL) id h33Inet21246 for avt@ietf.org; Thu, 3 Apr 2003 10:49:40 -0800 Date: Thu, 3 Apr 2003 10:49:40 -0800 From: John Lazzaro Message-Id: <200304031849.h33Inet21246@snap.CS.Berkeley.EDU> To: avt@ietf.org Subject: [AVT] Take two: MWPP and the marker bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Hi everyone, Looks like my mailer truncated the posting I just sent to the list, let's try again ... --- Hi everyone, Looking for input on the following MWPP issue ... MWPP supports two MIME types: mpeg4-generic for MPEG work and mwpp for general use. From draft-ietf-avt-mpeg4-simple-07.txt: Marker (M) bit: The M bit is set to 1 to indicate that the RTP packet payload contains either the final fragment of a fragmented Access Unit or one or more complete Access Units. MWPP needs "one access unit per packet" semantics for the recovery journal to work, as so for mpeg4-generic use M is defined to 1 for all packets. Currently, M is also defined to 1 for all packets for use with the mwpp MIME type, on the theory that the confusion that would result from two separate M bit definitions is best avoided. However, reading over the recent list discussion on voice codec marker bit use, I'm wondering if I should reverse this decision, and define M bit semantics for the mwpp MIME type that are in the spirit of voice-codec use (for MWPP, the right definition is to use the M bit to differentiate packets with new MIDI data from empty "guard" packets). Any input on this decision is appreciated, I'm undecided at the point ... ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro ------------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Apr 4 18:01:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11379 for ; Fri, 4 Apr 2003 18:01:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h34N4QF28371 for avt-archive@odin.ietf.org; Fri, 4 Apr 2003 18:04:26 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34N3j828240; Fri, 4 Apr 2003 18:03:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34N1I827988 for ; Fri, 4 Apr 2003 18:01:18 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11152; Fri, 4 Apr 2003 17:57:48 -0500 (EST) Message-Id: <200304042257.RAA11152@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , avt@ietf.org From: The IESG Date: Fri, 04 Apr 2003 17:57:48 -0500 Subject: [AVT] Protocol Action: Enhanced Compressed RTP (CRTP) for links with high delay, packet loss and reordering to Proposed Standard Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , The IESG has approved the Internet-Draft 'Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering' as a Proposed Standard. This document is the product of the Audio Video Transport Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. Technical Summary This document describes a header compression scheme for point to point links with packet loss and long delays. It is based on Compressed Real-time Transport Protocol (CRTP), the IP/UDP/RTP header compression described in RFC 2508. Original CRTP does not perform well on such links: packet loss results in context corruption and due to the long delay, excessive packets are discarded before the context is repaired. To correct the behavior of CRTP over such links, a few extensions to the protocol are specified here. The extensions aim to reduce context corruption by changing the way the compressor updates the context at the decompressor: updates are repeated and include updates to full and differential context parameters. With these extensions, ECRTP performs well over links with packet loss, packet reordering and long delays. The distinction is made that ECRTP is robust for links with reordering such as tunnels and multihop, and it is also robust for cellular links with high loss but that ROHC (RFC 3095) is expected "to be the preferred compression mechanism over links where compression efficiency is important" and packet misordering is infrequent. Working Group Summary The working group supported advancement of this document. There were no Last Call concerns with the document, but Area Director comments resulted in clarifications on IPv6, Security considerations, and applicability. Protocol Quality/Review This document was reviewed for the IESG by Allison Mankin. The Transport Area seeks information about implementations of ECRTP and their performance. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Apr 4 21:40:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16603 for ; Fri, 4 Apr 2003 21:40:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h352hck12668 for avt-archive@odin.ietf.org; Fri, 4 Apr 2003 21:43:38 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h352dr812478; Fri, 4 Apr 2003 21:39:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h352cR812440 for ; Fri, 4 Apr 2003 21:38:27 -0500 Received: from ns.live.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16368 for ; Fri, 4 Apr 2003 21:34:54 -0500 (EST) Received: from ns.live.com (localhost.live.com [127.0.0.1]) by ns.live.com (8.12.9/8.12.5) with ESMTP id h352bM4N031035; Fri, 4 Apr 2003 18:37:22 -0800 (PST) (envelope-from rsf@ns.live.com) Received: (from rsf@localhost) by ns.live.com (8.12.9/8.12.3/Submit) id h352bIlj030959; Fri, 4 Apr 2003 18:37:18 -0800 (PST) Message-Id: <4.3.1.1.20030404170117.00b796d0@laptop-localhost> X-Sender: rsf@laptop-localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 04 Apr 2003 18:36:33 -0800 To: thh@dolby.com, jasonfl@microsoft.com From: Ross Finlayson Cc: avt@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [AVT] Some comments on Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , I have recently been reviewing (& implementing) the proposed RTP payload format for AC-3 Audio , and I have a number of comments: 1/ This is now an official AVT Working Group item, correct? If so, the file name of future drafts should have the form "draft-avt-rtp-ac3-*.txt". 2/ I don't see any real need for the "NDU" (number of data units) byte at the front of each RTP payload. If an incoming RTP packet contains more than one 'data unit' (frame), then the receiver already needs to figure out the frame boundaries within the packet (presumably by computing the size of each frame from its internal header bytes). In doing this, he can count how many frames are present - but knowing this count in advance provides no useful information. 3/ The rules for how fragmented frames are packed into RTP packets are not made clear. In particular, can a RTP packet legally contain the following: - n (>=1) complete frames, followed by an initial fragment of a following frame? or - the trailing fragment of a frame, followed by one or more complete frames (or the initial fragment of a following frame)? In most existing RTP payload formats, to simplify the packing rules, neither of these cases is allowed. I.e., most RTP payload formats (that support multiple frames per packet, with fragmentation) specify that a RTP packet must contain either (i) one or more complete frames, or (ii) exactly one partial fragment of a frame (and nothing more). The document should explain exactly what the packing rules are for this payload format. 4/ What value should the "RDT" field (in the Data Unit Header) take if the data unit does not contain any redundant data (i.e., if the "TYP" field is 00)? Should "RDT" be 000 in this case? (It probably doesn't matter, but it should be specified.) In general, it's not clear which of the 4x8=32 possible combinations of the (2-bit) "TYP" field and the (3-bit) "RDT" field are actually legal. 5/ What value should the "B" bit have if the 'data unit' is a complete frame (i.e., not fragmented)? Presumably the "B" bit should be 1 in this case (because it will, of course, contain the 5/8 point). But the description of "B" is a little ambiguous, because it says "set to 1 if the packet contains an AC-3 *fragment* consisting of..." 6/ The "F" bit, as currently specified, seems mostly useless. Consider, for example, the case where a single frame is fragmented over three RTP packets. The first packet has F==1, M==0 The second packet has F==1, M==0 The third packet has F==1, M==1 (where M is the RTP header's "M" bit.) If the first of these packets gets lost, then the receiver will not be able to tell whether the second packet is the start of a new frame, or (as is actually the case) the middle of a frame. (I suppose it could figure this out by checking for the AC3 'syncword' at the start, but then you wouldn't really need the "F" bit at all.) I suggest that you replace the "F" bit with a "S" (start of frame) bit. This bit would be set to 1 iff the 'data unit' is the start of a frame (or a complete frame). I.e., using the example above, the first packet would have S==1, M==0 The second packet would have S==0, M==0 The third packet would have S==0, M==1 (The fourth possible case S==1, M==1 would indicate that the packet contains (one or more) *complete* frames.) 7/ The "T" (time code present) bit doesn't seem particularly useful. It requires that a sending implementation have detailed knowledge of the internals of AC3 frames, which seems unnecessary. Instead, I suggest omitting this bit, and leaving it up to the receiver to figure out - from the internals of each frame - whether it contains a time code (because this is something that it presumably needs to do anyway). 8/ As noted in 2/ above, each receiver needs to figure out where the boundaries between 'data units' are in each incoming RTP packet. Can the receiver easily do this even when the data unit(s) contain redundant/interleaved data - i.e., if "TYP" is 01 or 10? This wasn't clear to me, and I think you should provide a more detailed explanation (and perhaps even some 'pseudo-code') that describes how a receiver should parse incoming packets. 9/ I found the definition of the '5/8 point' a little confusing: "...the 5/8ths point is defined as: 5/8-framesize = truncate(framesize/2) + truncate(framesize/8)" When I first saw this, I thought that "5/8-framesize" was part of the formula - i.e., with a division and a subtraction operation! Instead, I suggest changing the definition to: "...the 5/8ths point, P, is defined as: P = truncate(framesize/2) + truncate(framesize/8)" 10/ Re. Section 4.2: "SDP usage": Having the number of channels be specified in a separate "a=fmtp:" line is unorthodox. It's far more common (and actually suggested in the SDP specification) for the number of channels to be specified at the end of the "a=rtpmap:" line - e.g.: m=audio 49000 RTP/AVP 100 a=rtpmap:100 ac3/48000/6 I hope this helps... Ross. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Apr 7 07:21:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15536 for ; Mon, 7 Apr 2003 07:21:21 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h37BPW701822 for avt-archive@odin.ietf.org; Mon, 7 Apr 2003 07:25:32 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37BLa801568; Mon, 7 Apr 2003 07:21:36 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37BF2801263 for ; Mon, 7 Apr 2003 07:15:02 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15043; Mon, 7 Apr 2003 07:10:21 -0400 (EDT) Message-Id: <200304071110.HAA15043@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: avt@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 07 Apr 2003 07:10:21 -0400 Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-retransmission-07.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Retransmission Payload Format Author(s) : J. Rey et al. Filename : draft-ietf-avt-rtp-retransmission-07.txt Pages : 27 Date : 2003-4-4 RTP retransmission is an effective packet loss recovery technique for real-time applications with relaxed delay bounds. This document describes an RTP payload format for performing retransmissions. Retransmitted RTP packets are sent in a separate stream from the original RTP stream. It is assumed that feedback from receivers to senders is available. In particular, it is assumed that RTCP feedback as defined in the extended RTP profile for RTCP-based feedback (denoted RTP/AVPF), is available in this memo. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-retransmission-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-retransmission-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-retransmission-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-4160448.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-retransmission-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-retransmission-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-4160448.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Apr 8 10:11:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11881 for ; Tue, 8 Apr 2003 10:11:27 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h38EGBR28552 for avt-archive@odin.ietf.org; Tue, 8 Apr 2003 10:16:11 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38EFV828524; Tue, 8 Apr 2003 10:15:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38E96828251 for ; Tue, 8 Apr 2003 10:09:06 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10545; Tue, 8 Apr 2003 10:03:51 -0400 (EDT) Message-Id: <200304081403.KAA10545@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: avt@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 08 Apr 2003 10:03:51 -0400 Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-clearmode-00.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP payload format for a 64 kbit/s transparent call Author(s) : R. Kreuter Filename : draft-ietf-avt-rtp-clearmode-00.txt Pages : 7 Date : 2003-4-7 This document describes how to carry 64 kbit/s data streams trans- parently in RTP packets, using a pseudo-codec called 'Clearmode'. It also serves as registration for a related MIME type called 'audio/clearmode'. 'Clearmode' is a basic feature of VoIP media gateways. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-clearmode-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-clearmode-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-clearmode-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-7124945.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-clearmode-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-clearmode-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-7124945.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Apr 8 11:12:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17965 for ; Tue, 8 Apr 2003 11:12:02 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h38FGmU02162 for avt-archive@odin.ietf.org; Tue, 8 Apr 2003 11:16:48 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38FFR802070; Tue, 8 Apr 2003 11:15:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38FES801931 for ; Tue, 8 Apr 2003 11:14:28 -0400 Received: from lodmsg01.corp.audiocodes.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17433 for ; Tue, 8 Apr 2003 11:09:10 -0400 (EDT) X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AVT] I-D ACTION:draft-ietf-avt-rtp-clearmode-00.txt Date: Tue, 8 Apr 2003 18:09:01 +0200 Message-ID: <14B7C5B03853404495D29CFA4A54B21C360E83@lodmsg01.corp.audiocodes.com> Thread-Topic: [AVT] I-D ACTION:draft-ietf-avt-rtp-clearmode-00.txt Thread-Index: AcL95E6FU7OUhV4+Tbu+Gm1F54pInwABIgMA From: "Nurit Shenhar" To: Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h38FES801932 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi There are some applications which define the CLEARMODE name as CCD. Are there also others which use CLEARMODE? If no, can the name be changed to CCD? Nurit -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Tuesday, April 08, 2003 4:04 PM Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-clearmode-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP payload format for a 64 kbit/s transparent call Author(s) : R. Kreuter Filename : draft-ietf-avt-rtp-clearmode-00.txt Pages : 7 Date : 2003-4-7 This document describes how to carry 64 kbit/s data streams trans- parently in RTP packets, using a pseudo-codec called 'Clearmode'. It also serves as registration for a related MIME type called 'audio/clearmode'. 'Clearmode' is a basic feature of VoIP media gateways. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-clearmode-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-clearmode-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-clearmode-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Apr 9 02:32:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15864 for ; Wed, 9 Apr 2003 02:32:59 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h396c2d16299 for avt-archive@odin.ietf.org; Wed, 9 Apr 2003 02:38:02 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h396b3815479; Wed, 9 Apr 2003 02:37:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h396Vd815156 for ; Wed, 9 Apr 2003 02:31:39 -0400 Received: from gorilla.mchh.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11642 for ; Wed, 9 Apr 2003 02:26:05 -0400 (EDT) Received: from moody.mchh.siemens.de ([139.21.205.85]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id IAA00423; Wed, 9 Apr 2003 08:28:35 +0200 (MET DST) Received: from mchh273e.demchh201e.icn.siemens.de (mchh273e.mchh.siemens.de [139.21.200.83]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id IAA04283; Wed, 9 Apr 2003 08:28:35 +0200 (MET DST) Received: by mchh273e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id ; Wed, 9 Apr 2003 08:28:16 +0200 Message-ID: From: Kreuter Ruediger To: "'Nurit Shenhar'" , Kreuter Ruediger Cc: avt@ietf.org Subject: AW: [AVT] I-D ACTION:draft-ietf-avt-rtp-clearmode-00.txt Date: Wed, 9 Apr 2003 08:28:15 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h396Ve815157 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi, what are these applications ? Ruediger > -----Ursprüngliche Nachricht----- > Von: Nurit Shenhar [mailto:NuritS@audiocodes.com] > Gesendet: Dienstag, 8. April 2003 18:09 > An: ruediger.kreuter@siemens.com > Cc: avt@ietf.org > Betreff: RE: [AVT] I-D ACTION:draft-ietf-avt-rtp-clearmode-00.txt > > > Hi > > There are some applications which define the CLEARMODE name > as CCD. Are there also others which use CLEARMODE? If no, can > the name be changed to CCD? > > Nurit > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Tuesday, April 08, 2003 4:04 PM > Cc: avt@ietf.org > Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-clearmode-00.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the Audio/Video Transport > Working Group of the IETF. > > Title : RTP payload format for a 64 kbit/s > transparent call > Author(s) : R. Kreuter > Filename : draft-ietf-avt-rtp-clearmode-00.txt > Pages : 7 > Date : 2003-4-7 > > This document describes how to carry 64 kbit/s data streams trans- > parently in RTP packets, using a pseudo-codec called 'Clearmode'. > It also serves as registration for a related MIME type called > 'audio/clearmode'. > 'Clearmode' is a basic feature of VoIP media gateways. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-clearmo de-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-clearmode-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-clearmode-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Apr 11 17:14:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00768 for ; Fri, 11 Apr 2003 17:14:50 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3BLL9T31665 for avt-archive@odin.ietf.org; Fri, 11 Apr 2003 17:21:09 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BLJH831484; Fri, 11 Apr 2003 17:19:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BLDR831296 for ; Fri, 11 Apr 2003 17:13:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00528 for ; Fri, 11 Apr 2003 17:06:37 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1945ln-0005vq-00 for avt@ietf.org; Fri, 11 Apr 2003 17:09:11 -0400 Received: from telchemy.com ([66.155.69.251]) by ietf-mx with esmtp (Exim 4.12) id 1945ln-0005vZ-00 for avt@ietf.org; Fri, 11 Apr 2003 17:09:11 -0400 Received: from TELWS104 [64.238.103.215] by telchemy.com with ESMTP (SMTPD32-7.14) id AED153B001A; Fri, 11 Apr 2003 17:08:33 -0400 Reply-To: From: "Alan Clark" To: "'Timur Friedman'" , "'Colin Perkins'" , "'Stephen Casner'" , "'Magnus Westerlund'" Cc: "'IETF AVT WG'" Subject: RE: [AVT] SDP signaling for RTCP XR format Date: Fri, 11 Apr 2003 17:04:14 -0400 Message-ID: <005401c3006d$e8f68090$6801a8c0@telchemy.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <005301c2f94e$de57b350$a648e384@lip6.fr> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3BLDR831297 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Timur, Colin, Steve At the recent IETF meeting we agreed that the existing draft was getting fairly stable - there were some good detail points brought up during the AVT discussion however these were easily accomodated. We also agreed at the AVT meeting to include some simple SDP signaling at Magnus' request however felt at the time that this would be fairly straightforward and would not take much time. The discussion on SDP appears to be getting much more involved than anticipated and there is no apparent end in sight. I would like to propose that we move to a final draft without SDP in order that we can reach closure. In San Francisco we discussed the idea of creating a separate document to describe the use of SDP for negotiating reporting/ feedback for RTP XR, RTCP and other mechanisms. This was suggested precisely because of some concern that the negotiation mechanism could get complex and that there were a wider variety of scenarios than anticipated .. which appears to be the case. Regards Alan Clark -----Original Message----- From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Timur Friedman Sent: Wednesday, April 02, 2003 2:34 PM To: Magnus Westerlund; Jose Rey Cc: IETF AVT WG Subject: Re: [AVT] SDP signaling for RTCP XR format Magnus Westerlund wrote: > Here one issue actually surface. Is it the right thing to restrict a > receiver to not send DLRR report block unless the usage has been > explicitly signaled in multicast? The reason why I see a need to > restrict it is the potential to create enormous report blocks in large > multicast groups. And the only result is that the different receivers > will determine there RTT to other receivers which seems to be rather > pointless in most application. It seems that you would in fact like to > control this operation to a few different operation modes in multicast. > 1. fully meshed, both senders and receivers return DLRR blocks. > 2. Sender only, only senders return DLRR blocks. > 3. functionality off, no one responds with DLRR blocks. > > Should we define such a distinction in the signaling? I agree that the signalling should allow each of these modes. But also the mode in which certain receivers calculate RTTs amongst themselves. While many applications might not use this mode, we do not want to unnecessarily rule it out. Here are two examples of when the mode could be used. First, receivers might measure RTTs amongst themselves as a prelude to some of them becoming senders (multicast "repair servers", retansmitting lost packets, for instance). Second, a network monitoring tool might wish to measure its RTT to certain receivers. - Timur Friedman _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Apr 11 17:43:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01835 for ; Fri, 11 Apr 2003 17:43:00 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3BLnK001446 for avt-archive@odin.ietf.org; Fri, 11 Apr 2003 17:49:20 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BLmh801419; Fri, 11 Apr 2003 17:48:43 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BLiM801231 for ; Fri, 11 Apr 2003 17:44:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01724 for ; Fri, 11 Apr 2003 17:37:32 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1946Fj-0006B9-00 for avt@ietf.org; Fri, 11 Apr 2003 17:40:07 -0400 Received: from ip72.usw4.rb1.bel.nwlink.com ([209.20.232.72] helo=bels002.mediator.com) by ietf-mx with esmtp (Exim 4.12) id 1946Fi-0006As-00 for avt@ietf.org; Fri, 11 Apr 2003 17:40:06 -0400 Received: from bays02.mediator.com ([172.16.100.252]) by bels002.mediator.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 11 Apr 2003 14:39:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Subject: RE: [AVT] RTCP XR Date: Fri, 11 Apr 2003 14:39:31 -0700 Message-ID: <30A6344AEBFC85429C30FF6C9C501CD1139138@bays02.mediator.com> Thread-Topic: [AVT] SDP signaling for RTCP XR format Thread-Index: AcMAcThuu68hIOOpTk2nP67sPYAscwAAU2BQ From: "Gamze Seckin" To: "IETF AVT WG" Cc: , "Timur Friedman" , "Colin Perkins" , "Stephen Casner" , "Magnus Westerlund" X-OriginalArrivalTime: 11 Apr 2003 21:39:33.0948 (UTC) FILETIME=[D7927FC0:01C30072] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h3BLiM801232 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit hi, Regarding the draft rtcp xr, has there been an attempt/discussion to include any video/audio streaming quality metrics? -gamze -----Original Message----- From: Alan Clark [mailto:alan@telchemy.com] Sent: Friday, April 11, 2003 2:04 PM To: 'Timur Friedman'; 'Colin Perkins'; 'Stephen Casner'; 'Magnus Westerlund' Cc: 'IETF AVT WG' Subject: RE: [AVT] SDP signaling for RTCP XR format Timur, Colin, Steve At the recent IETF meeting we agreed that the existing draft was getting fairly stable - there were some good detail points brought up during the AVT discussion however these were easily accomodated. We also agreed at the AVT meeting to include some simple SDP signaling at Magnus' request however felt at the time that this would be fairly straightforward and would not take much time. The discussion on SDP appears to be getting much more involved than anticipated and there is no apparent end in sight. I would like to propose that we move to a final draft without SDP in order that we can reach closure. In San Francisco we discussed the idea of creating a separate document to describe the use of SDP for negotiating reporting/ feedback for RTP XR, RTCP and other mechanisms. This was suggested precisely because of some concern that the negotiation mechanism could get complex and that there were a wider variety of scenarios than anticipated .. which appears to be the case. Regards Alan Clark -----Original Message----- From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Timur Friedman Sent: Wednesday, April 02, 2003 2:34 PM To: Magnus Westerlund; Jose Rey Cc: IETF AVT WG Subject: Re: [AVT] SDP signaling for RTCP XR format Magnus Westerlund wrote: > Here one issue actually surface. Is it the right thing to restrict a > receiver to not send DLRR report block unless the usage has been > explicitly signaled in multicast? The reason why I see a need to > restrict it is the potential to create enormous report blocks in large > multicast groups. And the only result is that the different receivers > will determine there RTT to other receivers which seems to be rather > pointless in most application. It seems that you would in fact like to > control this operation to a few different operation modes in multicast. > 1. fully meshed, both senders and receivers return DLRR blocks. > 2. Sender only, only senders return DLRR blocks. > 3. functionality off, no one responds with DLRR blocks. > > Should we define such a distinction in the signaling? I agree that the signalling should allow each of these modes. But also the mode in which certain receivers calculate RTTs amongst themselves. While many applications might not use this mode, we do not want to unnecessarily rule it out. Here are two examples of when the mode could be used. First, receivers might measure RTTs amongst themselves as a prelude to some of them becoming senders (multicast "repair servers", retansmitting lost packets, for instance). Second, a network monitoring tool might wish to measure its RTT to certain receivers. - Timur Friedman _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Apr 11 17:48:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01978 for ; Fri, 11 Apr 2003 17:48:57 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3BLtI901707 for avt-archive@odin.ietf.org; Fri, 11 Apr 2003 17:55:18 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BLsf801650; Fri, 11 Apr 2003 17:54:41 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BLmx801427 for ; Fri, 11 Apr 2003 17:48:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01823 for ; Fri, 11 Apr 2003 17:42:08 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1946KB-0006CR-00 for avt@ietf.org; Fri, 11 Apr 2003 17:44:43 -0400 Received: from telchemy.com ([66.155.69.251]) by ietf-mx with esmtp (Exim 4.12) id 1946KA-0006CO-00 for avt@ietf.org; Fri, 11 Apr 2003 17:44:42 -0400 Received: from TELWS104 [64.238.103.215] by telchemy.com with ESMTP (SMTPD32-7.14) id A7255C6001A; Fri, 11 Apr 2003 17:44:05 -0400 Reply-To: From: "Alan Clark" To: "'Gamze Seckin'" , "'IETF AVT WG'" Subject: RE: [AVT] RTCP XR Date: Fri, 11 Apr 2003 17:39:46 -0400 Message-ID: <005f01c30072$dfdf7020$6801a8c0@telchemy.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0060_01C30051.58CDD020" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-MS-TNEF-Correlator: 000000009988B8DB99EF5848818B736CCB599E2124C7AD00 In-Reply-To: <30A6344AEBFC85429C30FF6C9C501CD1139138@bays02.mediator.com> Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0060_01C30051.58CDD020 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The VoIP metrics could be applied to streaming video and audio. For streaming audio you would basically ignore the effects of delay and = focus on listening quality metrics. =20 For streaming video the same approach can be used however it may be advantageous to set the gmin value to say 128, due to the increased sensitivity of video to packet loss. There was some suggestion at the = IETF meeting to use the jitter buffer levels to provide feedback to the transmitter and help to manage packet flows. Regards Alan Clark Telchemy -----Original Message----- From: Gamze Seckin [mailto:gamze@vidiator.com] Sent: Friday, April 11, 2003 5:40 PM To: IETF AVT WG Cc: alan@telchemy.com; Timur Friedman; Colin Perkins; Stephen Casner; Magnus Westerlund Subject: RE: [AVT] RTCP XR=20 hi, Regarding the draft rtcp xr, has there been an attempt/discussion to = include any video/audio streaming quality metrics? -gamze -----Original Message----- From: Alan Clark [mailto:alan@telchemy.com] Sent: Friday, April 11, 2003 2:04 PM To: 'Timur Friedman'; 'Colin Perkins'; 'Stephen Casner'; 'Magnus Westerlund' Cc: 'IETF AVT WG' Subject: RE: [AVT] SDP signaling for RTCP XR format Timur, Colin, Steve At the recent IETF meeting we agreed that the existing draft was getting fairly stable - there were some good detail points brought up during the = AVT discussion however these were easily accomodated. =20 We also agreed at the AVT meeting to include some simple SDP signaling = at Magnus' request however felt at the time that this would be fairly straightforward and would not take much time. The discussion on SDP = appears to be getting much more involved than anticipated and there is no = apparent end in sight. =20 I would like to propose that we move to a final draft without SDP in = order that we can reach closure. In San Francisco we discussed the idea of creating a separate document to describe the use of SDP for negotiating reporting/ feedback for RTP XR, RTCP and other mechanisms. This was suggested precisely because of some concern that the negotiation = mechanism could get complex and that there were a wider variety of scenarios than anticipated .. which appears to be the case. Regards Alan Clark -----Original Message----- From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Timur Friedman Sent: Wednesday, April 02, 2003 2:34 PM To: Magnus Westerlund; Jose Rey Cc: IETF AVT WG Subject: Re: [AVT] SDP signaling for RTCP XR format Magnus Westerlund wrote: > Here one issue actually surface. Is it the right thing to restrict a > receiver to not send DLRR report block unless the usage has been > explicitly signaled in multicast? The reason why I see a need to > restrict it is the potential to create enormous report blocks in large > multicast groups. And the only result is that the different receivers > will determine there RTT to other receivers which seems to be rather > pointless in most application. It seems that you would in fact like to > control this operation to a few different operation modes in = multicast. > 1. fully meshed, both senders and receivers return DLRR blocks. > 2. Sender only, only senders return DLRR blocks. > 3. functionality off, no one responds with DLRR blocks. > > Should we define such a distinction in the signaling? I agree that the signalling should allow each of these modes. But also = the mode in which certain receivers calculate RTTs amongst themselves. = While many applications might not use this mode, we do not want to = unnecessarily rule it out. Here are two examples of when the mode could be used. First, receivers might measure RTTs amongst themselves as a prelude to some of them = becoming senders (multicast "repair servers", retansmitting lost packets, for instance). Second, a network monitoring tool might wish to measure its = RTT to certain receivers. - Timur Friedman _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt ------=_NextPart_000_0060_01C30051.58CDD020 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+Ii8VAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANMHBAALABEAJwAAAAUAJgEB A5AGADwOAAAlAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADAC4AAAAAAAMANgAA AAAAHgBwAAEAAAAPAAAAW0FWVF0gUlRDUCBYUiAAAAIBcQABAAAAFgAAAAHDAHLfQil5MW1/Ek+S mbigw4hS5NAAAAIBHQwBAAAAFwAAAFNNVFA6QUxBTkBURUxDSEVNWS5DT00AAAsAAQ4AAAAAQAAG DgByVsNyAMMBAgEKDgEAAAAYAAAAAAAAAJmIuNuZ71hIgYtzbMtZniHCgAAAAwAUDgEAAAALAB8O AQAAAAIBCRABAAAAFQoAABEKAAAIEwAATFpGdbY/lhADAAoAcmNwZzEyNeIyA0N0ZXgFQQEDAff/ CoACpAPkBxMCgA/zAFAEVj8IVQeyESUOUQMBAgBjaOEKwHNldDIGAAbDESX2MwRGE7cwEiwRMwjv Cfe2OxgfDjA1ESIMYGMAUPMLCQFkMzYWUAumCuMKgABUaGUgVm9JUGogB4B0BRBjBCAFoHWQbGQg Yh1wYXALUEMIkB6gdG8gcx4AZYRhbQuAZyB2aQEABx+AAHAeoGF1ZGlvcC4gIEYFsR+oIOMg0nkI YCB3HnRhDdEHQMBseSBpZ24FsB1wLnQdYQERBZB0BCBvZj4gAQALYCPAIKICEGN1PyTxA6AfIB+g CfAgAnF1+QdAaXQjwB3lITEc9Bz09yFsIEQkUnMf4B7TA2AA0D5oHlADkR7BJhAfQWhv+HdldhKB J1Ad0CVxHsLsZHYAcAGQZyBwJhEfcvsUICRDZx/xIDAHQApQH2PzJXEOIDgsJTAvNCRSC4CfBQAf 0CvSFBAAgXRpIECfJ2ElESnVH4AKsGNrLkHfF7AEECExHVEkIXcjUCkg8wNwKlF1Zy2gH6AhEAOg wmEuVElFVEYd0RQg7yACH3ErwSRDaidQDrAFwKxidSShBcBsLEFsLePvKuEgQiXQCeBkI0AzEDBW Px4AAHEf8DeDIKIdYGxwrx9iA4EtkTLmZhewdyfwUSg6UmVnCxFzKDpB5wtgEhELYHJrHPUlUBPQ WGVteSg6HPQtQbJP/QUQZwuAB0AF0AeQKnAtoEdBsyiVA2E6IEcf4HrvHXAGYDMQLtFbAMADEB9w djo+AEQxQCBBBzAfcHLyLgWgbV0c9AZgAjBD8G9DsCBQJXAwAEEq4AMRMQYxMAAB0DAzIDU6cjQW UFBNHPVFQDXUQSBWVCBXRxz0Q2N3Q/AHQABwQA6wQDRGQjv/M8AHcAhwR0IJgAOBTDAIUFsfIAOg UASQRKFzTDBT3Q6wcB1gEhEjUG4EkBkw1R0DTS2QbiYRVzUBBJDHCkAgsEaVdWJqJMFD8FRSRUPw W0ohXQfwVDJDHcBYUigrKDpoad4sPS8hADaCHWFkOnABgMYgACAN8CB4cjAAE+B/LeEz4x7ATpED kTVwDrBt/QUwLyEABPAmEACQJkEfcb8w0QpAOTEAcCPAIEMvIkT7H6gnHT9A+0VjQP9CD0MePz8Y RNdLL0aPR59IoDI6VDA0SQsnTFwnTDAnf01bZ1JOTGdST5Qc9FAIJz1KiCdJ2WslUQ9SEFNE/x3A AJAj8CcxIBECEAXAUjb7bxEAwHRTHx1ATGIwAE1TvzAATkEsUD5bLlQYIGNjkf813CwwHuAJwh9R E+AuVA7A/yaBIAJWBDQyLaACQG7TC3CfUFAjwB+gAaA4QCAtVyXnLDAkITRzZ28EcCUxAZDZAxFw bwuAJOFiA2A00PpoBUB1O5AwIAUQVZVKIv9YmSwWJFE28XkzMREDECWB/mNi4QRwNXAJgCgNUABL Ef80cHUWNXVKIjY5WXY0dAdw3wtQRFFuSzVxT5Qnc6EnEP81ASwHJLBFIDVmMcAqkXWV/wQAItY5 QXfmOnAj4HtQbxG/NDALICCTIuQkAC5RYTMg/x3QGtArMIdyM6R8miZBbjL/HvEf0BQAH2IewXdW i5MEYPskIQuAdgbwLFB1c1fCMcD+YwUgf2Igk1c0iDEkAB7i/wrAc+IJ8B6gLtFucXtQKA3+SSLV HyCLYTi0epA28zVx73TxBGAsUB9iYSXQXwN2tfsnUCwQdQVAbjIu0QWwBIF/lgcrUh/BKyIzYQhw jBJJ/41RA5FDsABwkNAE8B+AdPH/WJV1YzCxAQCXECURMPI2Y/+XEBQQCrF/YSUwJfEHgHPx/x9x AQAE8h7BJFI24iURbjL/bxJO8HnQMcCd1BggepAAIP0gAS85WG8UUmIwAFIzIKL/ixAz4R3RE9ED ADqgM5SIMv80QjTUH0Eq4AWQBAAlUCzi/yOAoHU0cwWgMOAEknWXoWe/JkGlFx5Vd1EeUYPSeJFF /zV0eQaXEAPwmQItUAiBMgSfBPAJ8K4RM3CQPyAuITD+d1QwKyGNvCRSI4AUED0fHz4vPzxdv17P Qx5hdnSWLS0wH/FArjFmLgWwJyAgYYe4j11PA6BCZfUT4GwlIE8lIExTQ1ZM1CtjKlAAZE7wc2QZ MDLdZOczZYxPn0wwSpXSsyDvQIVK4knfbQhlbb9uz2/fXyiFwM8i0ANgDrA6KDo+/CBIM/ICIJHS NMAe0STQvycheBIIcHfQc9AhMEkEIP8skXNziaKIAjaEGCAfoQ3g/4bhylZzsjHQfaIfgIsCMXHx HqBETFJSkKIkHrAXsP85wVBwOEAEEaA0PBJW8leS78pWDsAfEZDQdHgSxaMfQd8u0UxwRSAjcR+g P4xDMQL/JkGwkCPAlJAUEK1iTvAfQ//PGM6VLJGIMSRSepAmoaGh/wMgH3GdoyRxJAEEYCYR0Tr/ zPEmUQrALaDKVtWHLqB7EfpwJ/FBkWQmMSOxznHVkf/ZRDV1IQA38nPiz5azhcqw/wPwI6B6EgSQ H/EkMyQhUjD/SkAfcaS04TewhddBpZCOJf+ekTPhylZ6k9Ij1VIzcIbh/x8CI4A1IszB0HLlg3Wi Iqj/LtHMgTNBlSTKVqixHgAG8P+IBJWwBJCqJJbkB9HgmOy4XwRi54TVlrJVyrAxITBm7x6AI7EH gR1gZDAABuAkUP/Qg+TCIKLkaBggy+AEodDj+9wE8EcyITBjgZkC3xIwAO/fE/I285/0qDPw4jDg NSL7JzQlEGYwAJIhyyLOcXqQvyCwiEGYAfd/ypHKVlOYIf8ekZwSARDi8jTAsMJ8kjZh//kjkxIq M8WmXIuUkHUjdYj/xZTF4/GAHnMjkSwgfnErIe8lEX3U7yMhMUKYQYDDJFH/tbQVYpMSsJSo4XpB meLkhv8jgSYAC2CeseOR8pEVYCAQv4YBJFGlkCVQLFAn8ldUMP84QAXlWfLoKfKQH/B7QosC/zbk iDEVYjAAnBLQNDQwn0S/UHBO8HPQtxFH8UCFch6A/zCx7mGYQLJbytOSgR9gIuD/dhEf4IPhJPOw kE6RJFIGQ/8eZyvCITJ38B+gMADhPQxU/yqQ0yCaoQjfCeX+cPKRpwL/WaMfcqhyBBSrAKexqHAg Aeu1tPI2KN14IqIhd+EuIfpy4YIiFXJ4UDqUIAIzYft0ADL0czAAxjG1tE3xHgH9c9Ap9VKosfGx 14ISQWFR/xfBJ1DGQDZ07DEMVPsg8YD/O6MW9SdQ8pDjkbW02mIHPu+yW3iwZnwQ+l8pDyofKurT s/Vaoi9WMnNUOnLRU/ZXIcF0skfeIrW0uiG5B4dT1Vgg3lA6Ly93MIDb8NC5Fi9hkmchL5UQdlL/ xjBagLowKE8zrzS/K38sj78tny6vL78wzzHfVBB9PXAAAAAeAEIQAQAAAD0AAAA8MzBBNjM0NEFF QkZDODU0MjlDMzBGRjZDOUM1MDFDRDExMzkxMzhAYmF5czAyLm1lZGlhdG9yLmNvbT4AAAAAAwAJ WQEAAAALAACACCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAAAAMAAoAIIAYAAAAAAMAAAAAAAABG AAAAABCFAAAAAAAAAwAHgAggBgAAAAAAwAAAAAAAAEYAAAAAUoUAAH1uAQAeAAmACCAGAAAAAADA AAAAAAAARgAAAABUhQAAAQAAAAQAAAA5LjAACwARgAggBgAAAAAAwAAAAAAAAEYAAAAABoUAAAAA AAADABKACCAGAAAAAADAAAAAAAAARgAAAAABhQAAAAAAAAsAG4AIIAYAAAAAAMAAAAAAAABGAAAA AA6FAAAAAAAAAwAcgAggBgAAAAAAwAAAAAAAAEYAAAAAEYUAAAAAAAADAB6ACCAGAAAAAADAAAAA AAAARgAAAAAYhQAAAAAAAAIB+A8BAAAAEAAAAJmIuNuZ71hIgYtzbMtZniECAfoPAQAAABAAAACZ iLjbme9YSIGLc2zLWZ4hAgH7DwEAAACSAAAAAAAAADihuxAF5RAaobsIACsqVsIAAG1zcHN0LmRs bAAAAAAATklUQfm/uAEAqgA32W4AAABDOlxEb2N1bWVudHMgYW5kIFNldHRpbmdzXGFsYW5cTG9j YWwgU2V0dGluZ3NcQXBwbGljYXRpb24gRGF0YVxNaWNyb3NvZnRcT3V0bG9va1xtYWlsYm94LnBz dAAAAAMA/g8FAAAAAwANNP03AAACAX8AAQAAADEAAAAwMDAwMDAwMDk5ODhCOERCOTlFRjU4NDg4 MThCNzM2Q0NCNTk5RTIxMjRDN0FEMDAAAAAAAwAGEL9YQAgDAAcQ0gwAAAMAEBAAAAAAAwAREAAA AAAeAAgQAQAAAGUAAABUSEVWT0lQTUVUUklDU0NPVUxEQkVBUFBMSUVEVE9TVFJFQU1JTkdWSURF T0FOREFVRElPRk9SU1RSRUFNSU5HQVVESU9ZT1VXT1VMREJBU0lDQUxMWUlHTk9SRVRIRUVGRkVD AAAAAEmY ------=_NextPart_000_0060_01C30051.58CDD020-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Apr 11 17:57:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02258 for ; Fri, 11 Apr 2003 17:57:56 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3BM4HO02118 for avt-archive@odin.ietf.org; Fri, 11 Apr 2003 18:04:17 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BM3i802095; Fri, 11 Apr 2003 18:03:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BLxh801932 for ; Fri, 11 Apr 2003 17:59:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02135 for ; Fri, 11 Apr 2003 17:52:52 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1946UZ-0006Fl-00 for avt@ietf.org; Fri, 11 Apr 2003 17:55:27 -0400 Received: from ip72.usw4.rb1.bel.nwlink.com ([209.20.232.72] helo=bels002.mediator.com) by ietf-mx with esmtp (Exim 4.12) id 1946UY-0006Fi-00 for avt@ietf.org; Fri, 11 Apr 2003 17:55:26 -0400 Received: from bays02.mediator.com ([172.16.100.252]) by bels002.mediator.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 11 Apr 2003 14:54:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AVT] RTCP XR Date: Fri, 11 Apr 2003 14:54:54 -0700 Message-ID: <30A6344AEBFC85429C30FF6C9C501CD113913A@bays02.mediator.com> Thread-Topic: [AVT] RTCP XR Thread-Index: AcMAct9CKXkxbX8ST5KZuKDDiFLk0AAAUfdQ From: "Gamze Seckin" To: , "IETF AVT WG" X-OriginalArrivalTime: 11 Apr 2003 21:54:56.0309 (UTC) FILETIME=[FD579E50:01C30074] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3BLxh801933 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit I agree, however there could be more than loss to determine streaming quality, especially if the receiver is a mobile handset for example. You would want (if possible) codec specific information (like freezes, corruptions) or number of buffering etc. It could be also a good idea to separate this information from the VoIP block since the report-trigger requirements could be different, and VoIP block has much more than the streaming block would need. -thanks -g Gamze Seckin, Ph.D. Director of Research Vidiator Technology (US) Inc., The multimedia technology company of Hutchison Whampoa Limited office:650.390.9989 x27 fax:650.390.9911 This e-mail is a confidential communication. If you are not the intended recipient of this e-mail, please return the message to the sender and delete the original. Thank you. -----Original Message----- From: Alan Clark [mailto:alan@telchemy.com] Sent: Friday, April 11, 2003 2:40 PM To: Gamze Seckin; 'IETF AVT WG' Subject: RE: [AVT] RTCP XR The VoIP metrics could be applied to streaming video and audio. For streaming audio you would basically ignore the effects of delay and focus on listening quality metrics. For streaming video the same approach can be used however it may be advantageous to set the gmin value to say 128, due to the increased sensitivity of video to packet loss. There was some suggestion at the IETF meeting to use the jitter buffer levels to provide feedback to the transmitter and help to manage packet flows. Regards Alan Clark Telchemy -----Original Message----- From: Gamze Seckin [mailto:gamze@vidiator.com] Sent: Friday, April 11, 2003 5:40 PM To: IETF AVT WG Cc: alan@telchemy.com; Timur Friedman; Colin Perkins; Stephen Casner; Magnus Westerlund Subject: RE: [AVT] RTCP XR hi, Regarding the draft rtcp xr, has there been an attempt/discussion to include any video/audio streaming quality metrics? -gamze -----Original Message----- From: Alan Clark [mailto:alan@telchemy.com] Sent: Friday, April 11, 2003 2:04 PM To: 'Timur Friedman'; 'Colin Perkins'; 'Stephen Casner'; 'Magnus Westerlund' Cc: 'IETF AVT WG' Subject: RE: [AVT] SDP signaling for RTCP XR format Timur, Colin, Steve At the recent IETF meeting we agreed that the existing draft was getting fairly stable - there were some good detail points brought up during the AVT discussion however these were easily accomodated. We also agreed at the AVT meeting to include some simple SDP signaling at Magnus' request however felt at the time that this would be fairly straightforward and would not take much time. The discussion on SDP appears to be getting much more involved than anticipated and there is no apparent end in sight. I would like to propose that we move to a final draft without SDP in order that we can reach closure. In San Francisco we discussed the idea of creating a separate document to describe the use of SDP for negotiating reporting/ feedback for RTP XR, RTCP and other mechanisms. This was suggested precisely because of some concern that the negotiation mechanism could get complex and that there were a wider variety of scenarios than anticipated .. which appears to be the case. Regards Alan Clark -----Original Message----- From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Timur Friedman Sent: Wednesday, April 02, 2003 2:34 PM To: Magnus Westerlund; Jose Rey Cc: IETF AVT WG Subject: Re: [AVT] SDP signaling for RTCP XR format Magnus Westerlund wrote: > Here one issue actually surface. Is it the right thing to restrict a > receiver to not send DLRR report block unless the usage has been > explicitly signaled in multicast? The reason why I see a need to > restrict it is the potential to create enormous report blocks in large > multicast groups. And the only result is that the different receivers > will determine there RTT to other receivers which seems to be rather > pointless in most application. It seems that you would in fact like to > control this operation to a few different operation modes in multicast. > 1. fully meshed, both senders and receivers return DLRR blocks. > 2. Sender only, only senders return DLRR blocks. > 3. functionality off, no one responds with DLRR blocks. > > Should we define such a distinction in the signaling? I agree that the signalling should allow each of these modes. But also the mode in which certain receivers calculate RTTs amongst themselves. While many applications might not use this mode, we do not want to unnecessarily rule it out. Here are two examples of when the mode could be used. First, receivers might measure RTTs amongst themselves as a prelude to some of them becoming senders (multicast "repair servers", retansmitting lost packets, for instance). Second, a network monitoring tool might wish to measure its RTT to certain receivers. - Timur Friedman _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Apr 11 18:15:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03708 for ; Fri, 11 Apr 2003 18:15:17 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3BMLcX03589 for avt-archive@odin.ietf.org; Fri, 11 Apr 2003 18:21:38 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BMLA803571; Fri, 11 Apr 2003 18:21:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BMGa803444 for ; Fri, 11 Apr 2003 18:16:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03163 for ; Fri, 11 Apr 2003 18:09:44 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1946kt-0006K5-00 for avt@ietf.org; Fri, 11 Apr 2003 18:12:19 -0400 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com ident=root) by ietf-mx with esmtp (Exim 4.12) id 1946kt-0006K2-00 for avt@ietf.org; Fri, 11 Apr 2003 18:12:19 -0400 Received: from [68.100.8.94] (account marshall_eubanks HELO multicasttech.com) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 1674512; Fri, 11 Apr 2003 17:40:42 -0400 Date: Fri, 11 Apr 2003 18:12:17 -0400 Subject: Re: [AVT] RTCP XR Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "'Gamze Seckin'" , "'IETF AVT WG'" To: From: Marshall Eubanks In-Reply-To: <005f01c30072$dfdf7020$6801a8c0@telchemy.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello; Can you give references to the additional metric you have in mind ? Regards Marshall Eubanks On Friday, April 11, 2003, at 05:39 PM, Alan Clark wrote: > > The VoIP metrics could be applied to streaming video and audio. For > streaming audio you would basically ignore the effects of delay and > focus on > listening quality metrics. > > For streaming video the same approach can be used however it may be > advantageous to set the gmin value to say 128, due to the increased > sensitivity of video to packet loss. There was some suggestion at the > IETF > meeting to use the jitter buffer levels to provide feedback to the > transmitter and help to manage packet flows. > > Regards > > Alan Clark > Telchemy > > > -----Original Message----- > From: Gamze Seckin [mailto:gamze@vidiator.com] > Sent: Friday, April 11, 2003 5:40 PM > To: IETF AVT WG > Cc: alan@telchemy.com; Timur Friedman; Colin Perkins; Stephen Casner; > Magnus Westerlund > Subject: RE: [AVT] RTCP XR > > > > hi, > > Regarding the draft rtcp xr, has there been an attempt/discussion to > include > any video/audio streaming quality metrics? > > -gamze > > -----Original Message----- > From: Alan Clark [mailto:alan@telchemy.com] > Sent: Friday, April 11, 2003 2:04 PM > To: 'Timur Friedman'; 'Colin Perkins'; 'Stephen Casner'; 'Magnus > Westerlund' > Cc: 'IETF AVT WG' > Subject: RE: [AVT] SDP signaling for RTCP XR format > > > Timur, Colin, Steve > > At the recent IETF meeting we agreed that the existing draft was > getting > fairly stable - there were some good detail points brought up during > the AVT > discussion however these were easily accomodated. > > We also agreed at the AVT meeting to include some simple SDP signaling > at > Magnus' request however felt at the time that this would be fairly > straightforward and would not take much time. The discussion on SDP > appears > to be getting much more involved than anticipated and there is no > apparent > end in sight. > > I would like to propose that we move to a final draft without SDP in > order > that we can reach closure. In San Francisco we discussed the idea of > creating a separate document to describe the use of SDP for negotiating > reporting/ feedback for RTP XR, RTCP and other mechanisms. This was > suggested precisely because of some concern that the negotiation > mechanism > could get complex and that there were a wider variety of scenarios than > anticipated .. which appears to be the case. > > Regards > > Alan Clark > > > -----Original Message----- > From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Timur > Friedman > Sent: Wednesday, April 02, 2003 2:34 PM > To: Magnus Westerlund; Jose Rey > Cc: IETF AVT WG > Subject: Re: [AVT] SDP signaling for RTCP XR format > > > Magnus Westerlund wrote: > >> Here one issue actually surface. Is it the right thing to restrict a >> receiver to not send DLRR report block unless the usage has been >> explicitly signaled in multicast? The reason why I see a need to >> restrict it is the potential to create enormous report blocks in large >> multicast groups. And the only result is that the different receivers >> will determine there RTT to other receivers which seems to be rather >> pointless in most application. It seems that you would in fact like to >> control this operation to a few different operation modes in >> multicast. >> 1. fully meshed, both senders and receivers return DLRR blocks. >> 2. Sender only, only senders return DLRR blocks. >> 3. functionality off, no one responds with DLRR blocks. >> >> Should we define such a distinction in the signaling? > > I agree that the signalling should allow each of these modes. But > also the > mode in which certain receivers calculate RTTs amongst themselves. > While > many applications might not use this mode, we do not want to > unnecessarily > rule it out. > > Here are two examples of when the mode could be used. First, receivers > might measure RTTs amongst themselves as a prelude to some of them > becoming > senders (multicast "repair servers", retansmitting lost packets, for > instance). Second, a network monitoring tool might wish to measure its > RTT > to certain receivers. > > - Timur Friedman > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > T.M. Eubanks Multicast Technologies, Inc. e-mail : tme@multicasttech.com http://www.multicasttech.com Our New Multicast Workshop : http://www.multicasttech.com/workshop Test your network for multicast : http://www.multicasttech.com/mt/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Apr 11 20:10:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06224 for ; Fri, 11 Apr 2003 20:10:06 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3C0GUA10584 for avt-archive@odin.ietf.org; Fri, 11 Apr 2003 20:16:30 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3C0G7810570; Fri, 11 Apr 2003 20:16:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3C0Bs810461 for ; Fri, 11 Apr 2003 20:11:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06070 for ; Fri, 11 Apr 2003 20:05:00 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1948YR-0006mi-00 for avt@ietf.org; Fri, 11 Apr 2003 20:07:35 -0400 Received: from ip72.usw4.rb1.bel.nwlink.com ([209.20.232.72] helo=bels002.mediator.com) by ietf-mx with esmtp (Exim 4.12) id 1948YR-0006mR-00 for avt@ietf.org; Fri, 11 Apr 2003 20:07:35 -0400 Received: from bays02.mediator.com ([172.16.100.252]) by bels002.mediator.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 11 Apr 2003 17:07:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AVT] RTCP XR Date: Fri, 11 Apr 2003 17:07:02 -0700 Message-ID: <30A6344AEBFC85429C30FF6C9C501CD113913F@bays02.mediator.com> Thread-Topic: [AVT] RTCP XR Thread-Index: AcMAd2yNw7ENz+g4QIue08OWWOApzAACGjQQ From: "Gamze Seckin" To: "Marshall Eubanks" , Cc: "IETF AVT WG" X-OriginalArrivalTime: 12 Apr 2003 00:07:04.0508 (UTC) FILETIME=[72EAC7C0:01C30087] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3C0Bt810462 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Marshall and all, There are not many of them, but definitely worth separating them form the VoIP metrics for efficiency purposes. We presented a set of parameters in 3gpp sa4 (in sa25 and sa25bis, documents 30008 and 30130, accessible via www.3gpp.org) in an collaborated work with 3 UK. Actually a new version is due end-of this month i can forward you the updated document/link soon. We proposed to send the information back over rtsp , but having an rtcp extension is also a valuable approach, we believe. -g Gamze Seckin, Ph.D. Director of Research Vidiator Technology (US) Inc., The multimedia technology company of Hutchison Whampoa Limited office:650.390.9989 x27 fax:650.390.9911 This e-mail is a confidential communication. If you are not the intended recipient of this e-mail, please return the message to the sender and delete the original. Thank you. -----Original Message----- From: Marshall Eubanks [mailto:tme@multicasttech.com] Sent: Friday, April 11, 2003 3:12 PM To: alan@telchemy.com Cc: Gamze Seckin; 'IETF AVT WG' Subject: Re: [AVT] RTCP XR Hello; Can you give references to the additional metric you have in mind ? Regards Marshall Eubanks On Friday, April 11, 2003, at 05:39 PM, Alan Clark wrote: > > The VoIP metrics could be applied to streaming video and audio. For > streaming audio you would basically ignore the effects of delay and > focus on > listening quality metrics. > > For streaming video the same approach can be used however it may be > advantageous to set the gmin value to say 128, due to the increased > sensitivity of video to packet loss. There was some suggestion at the > IETF > meeting to use the jitter buffer levels to provide feedback to the > transmitter and help to manage packet flows. > > Regards > > Alan Clark > Telchemy > > > -----Original Message----- > From: Gamze Seckin [mailto:gamze@vidiator.com] > Sent: Friday, April 11, 2003 5:40 PM > To: IETF AVT WG > Cc: alan@telchemy.com; Timur Friedman; Colin Perkins; Stephen Casner; > Magnus Westerlund > Subject: RE: [AVT] RTCP XR > > > > hi, > > Regarding the draft rtcp xr, has there been an attempt/discussion to > include > any video/audio streaming quality metrics? > > -gamze > > -----Original Message----- > From: Alan Clark [mailto:alan@telchemy.com] > Sent: Friday, April 11, 2003 2:04 PM > To: 'Timur Friedman'; 'Colin Perkins'; 'Stephen Casner'; 'Magnus > Westerlund' > Cc: 'IETF AVT WG' > Subject: RE: [AVT] SDP signaling for RTCP XR format > > > Timur, Colin, Steve > > At the recent IETF meeting we agreed that the existing draft was > getting > fairly stable - there were some good detail points brought up during > the AVT > discussion however these were easily accomodated. > > We also agreed at the AVT meeting to include some simple SDP signaling > at > Magnus' request however felt at the time that this would be fairly > straightforward and would not take much time. The discussion on SDP > appears > to be getting much more involved than anticipated and there is no > apparent > end in sight. > > I would like to propose that we move to a final draft without SDP in > order > that we can reach closure. In San Francisco we discussed the idea of > creating a separate document to describe the use of SDP for negotiating > reporting/ feedback for RTP XR, RTCP and other mechanisms. This was > suggested precisely because of some concern that the negotiation > mechanism > could get complex and that there were a wider variety of scenarios than > anticipated .. which appears to be the case. > > Regards > > Alan Clark > > > -----Original Message----- > From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Timur > Friedman > Sent: Wednesday, April 02, 2003 2:34 PM > To: Magnus Westerlund; Jose Rey > Cc: IETF AVT WG > Subject: Re: [AVT] SDP signaling for RTCP XR format > > > Magnus Westerlund wrote: > >> Here one issue actually surface. Is it the right thing to restrict a >> receiver to not send DLRR report block unless the usage has been >> explicitly signaled in multicast? The reason why I see a need to >> restrict it is the potential to create enormous report blocks in large >> multicast groups. And the only result is that the different receivers >> will determine there RTT to other receivers which seems to be rather >> pointless in most application. It seems that you would in fact like to >> control this operation to a few different operation modes in >> multicast. >> 1. fully meshed, both senders and receivers return DLRR blocks. >> 2. Sender only, only senders return DLRR blocks. >> 3. functionality off, no one responds with DLRR blocks. >> >> Should we define such a distinction in the signaling? > > I agree that the signalling should allow each of these modes. But > also the > mode in which certain receivers calculate RTTs amongst themselves. > While > many applications might not use this mode, we do not want to > unnecessarily > rule it out. > > Here are two examples of when the mode could be used. First, receivers > might measure RTTs amongst themselves as a prelude to some of them > becoming > senders (multicast "repair servers", retansmitting lost packets, for > instance). Second, a network monitoring tool might wish to measure its > RTT > to certain receivers. > > - Timur Friedman > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > T.M. Eubanks Multicast Technologies, Inc. e-mail : tme@multicasttech.com http://www.multicasttech.com Our New Multicast Workshop : http://www.multicasttech.com/workshop Test your network for multicast : http://www.multicasttech.com/mt/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Sat Apr 12 15:48:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03817 for ; Sat, 12 Apr 2003 15:48:44 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3CJtW819111 for avt-archive@odin.ietf.org; Sat, 12 Apr 2003 15:55:32 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3CJt4819078; Sat, 12 Apr 2003 15:55:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3CJp7818982 for ; Sat, 12 Apr 2003 15:51:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03734 for ; Sat, 12 Apr 2003 15:43:49 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 194QxD-0002KF-00 for avt@ietf.org; Sat, 12 Apr 2003 15:46:23 -0400 Received: from wireless248.east.isi.edu ([65.123.202.248] helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 194QxD-0002KC-00 for avt@ietf.org; Sat, 12 Apr 2003 15:46:23 -0400 Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with ESMTP id h3CJkDmI001607; Sat, 12 Apr 2003 15:46:18 -0400 (EDT) (envelope-from csp@purple.nge.isi.edu) Message-Id: <200304121946.h3CJkDmI001607@purple.nge.isi.edu> To: alan@telchemy.com cc: "'Timur Friedman'" , "'Stephen Casner'" , "'Magnus Westerlund'" , "'IETF AVT WG'" Subject: Re: [AVT] SDP signaling for RTCP XR format In-Reply-To: Your message of "Fri, 11 Apr 2003 17:04:14 EDT." <005401c3006d$e8f68090$6801a8c0@telchemy.com> Date: Sat, 12 Apr 2003 15:46:13 -0400 From: Colin Perkins Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Alan, --> "Alan Clark" writes: >At the recent IETF meeting we agreed that the existing draft was getting >fairly stable - there were some good detail points brought up during the >AVT discussion however these were easily accomodated. > >We also agreed at the AVT meeting to include some simple SDP signaling at >Magnus' request however felt at the time that this would be fairly >straightforward and would not take much time. The discussion on SDP >appears to be getting much more involved than anticipated and there is no >apparent end in sight. > >I would like to propose that we move to a final draft without SDP in order >that we can reach closure. In San Francisco we discussed the idea of >creating a separate document to describe the use of SDP for negotiating >reporting/ feedback for RTP XR, RTCP and other mechanisms. This was >suggested precisely because of some concern that the negotiation mechanism >could get complex and that there were a wider variety of scenarios than >anticipated .. which appears to be the case. We should certainly consider this, as one way of meeting the ITU deadline. Before we go down this path, though, I'd like to see some discussion of the use cases for RTCP XR packets: in which scenarios is the signalling needed? If typical scenarios require signalling, then we have no choice but to move forward with the SDP extensions and their integration with SIP/RTSP. On the other hand, if signalling is only required in unusual cases, it is much easier to separate into a new draft. Regards, Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Sat Apr 12 20:27:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08321 for ; Sat, 12 Apr 2003 20:27:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3D0YA701580 for avt-archive@odin.ietf.org; Sat, 12 Apr 2003 20:34:10 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3D0Xi801559; Sat, 12 Apr 2003 20:33:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3D0T2801450 for ; Sat, 12 Apr 2003 20:29:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08278 for ; Sat, 12 Apr 2003 20:21:39 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 194VI4-00036h-00 for avt@ietf.org; Sat, 12 Apr 2003 20:24:13 -0400 Received: from www.telchemy.com ([66.155.69.251] helo=telchemy.com) by ietf-mx with esmtp (Exim 4.12) id 194VI4-00036X-00 for avt@ietf.org; Sat, 12 Apr 2003 20:24:12 -0400 Received: from alansnotebook [66.156.13.125] by telchemy.com with ESMTP (SMTPD32-7.14) id AE026A70210; Sat, 12 Apr 2003 20:23:30 -0400 From: "Alan Clark" To: "Colin Perkins" Cc: "'Timur Friedman'" , "'Stephen Casner'" , "'Magnus Westerlund'" , "'IETF AVT WG'" Subject: RE: [AVT] SDP signaling for RTCP XR format Date: Sat, 12 Apr 2003 20:26:15 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <200304121946.h3CJkDmI001607@purple.nge.isi.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Colin, Excellent advice - I'll put some thoughts together this weekend. Regards Alan -----Original Message----- From: Colin Perkins [mailto:csp@csperkins.org] Sent: Saturday, April 12, 2003 3:46 PM To: alan@telchemy.com Cc: 'Timur Friedman'; 'Stephen Casner'; 'Magnus Westerlund'; 'IETF AVT WG' Subject: Re: [AVT] SDP signaling for RTCP XR format Alan, --> "Alan Clark" writes: >At the recent IETF meeting we agreed that the existing draft was getting >fairly stable - there were some good detail points brought up during the >AVT discussion however these were easily accomodated. > >We also agreed at the AVT meeting to include some simple SDP signaling at >Magnus' request however felt at the time that this would be fairly >straightforward and would not take much time. The discussion on SDP >appears to be getting much more involved than anticipated and there is no >apparent end in sight. > >I would like to propose that we move to a final draft without SDP in order >that we can reach closure. In San Francisco we discussed the idea of >creating a separate document to describe the use of SDP for negotiating >reporting/ feedback for RTP XR, RTCP and other mechanisms. This was >suggested precisely because of some concern that the negotiation mechanism >could get complex and that there were a wider variety of scenarios than >anticipated .. which appears to be the case. We should certainly consider this, as one way of meeting the ITU deadline. Before we go down this path, though, I'd like to see some discussion of the use cases for RTCP XR packets: in which scenarios is the signalling needed? If typical scenarios require signalling, then we have no choice but to move forward with the SDP extensions and their integration with SIP/RTSP. On the other hand, if signalling is only required in unusual cases, it is much easier to separate into a new draft. Regards, Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Sun Apr 13 16:53:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05606 for ; Sun, 13 Apr 2003 16:53:26 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3DL0jU15139 for avt-archive@odin.ietf.org; Sun, 13 Apr 2003 17:00:45 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3DL0A814982; Sun, 13 Apr 2003 17:00:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3DKrG814521 for ; Sun, 13 Apr 2003 16:53:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05346 for ; Sun, 13 Apr 2003 16:45:26 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 194oOO-00067n-00 for avt@ietf.org; Sun, 13 Apr 2003 16:48:00 -0400 Received: from www.routeexplorer.org ([65.192.41.10] helo=mailman.packetdesign.com) by ietf-mx with esmtp (Exim 4.12) id 194oON-00067i-00 for avt@ietf.org; Sun, 13 Apr 2003 16:47:59 -0400 Received: from packetdesign.com (main-fw-eth1.packetdesign.com [192.168.0.254]) by mailman.packetdesign.com (8.12.8/8.12.8) with ESMTP id h3DKlCSR027795; Sun, 13 Apr 2003 13:47:13 -0700 (PDT) (envelope-from casner@acm.org) Date: Sun, 13 Apr 2003 13:48:04 -0700 (PDT) From: Stephen Casner To: AVT WG Message-ID: <20030413134251.D26225-200000@oak.packetdesign.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-738478263-1050266884=:26225" Subject: [AVT] Draft minutes for first IETF56 AVT session Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-738478263-1050266884=:26225 Content-Type: TEXT/PLAIN; charset=US-ASCII Attached are the minutes for the first session (Wednesday afternoon) of the AVT meeting at IETF 56 in San Francisco. Colin is separately writing the minutes for the second session. These minutes need to be turned in by the end of the day tomorrow (Monday), so any comments you can provide quickly would be appreciated. -- Steve --0-738478263-1050266884=:26225 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="minutes.txt" Content-ID: <20030413134804.X26225@oak.packetdesign.com> Content-Description: Content-Disposition: attachment; filename="minutes.txt" Content-Transfer-Encoding: BASE64 QXVkaW8vVmlkZW8gVHJhbnNwb3J0IFdvcmtpbmcgR3JvdXAgTWludXRlcw0K DQpSZXBvcnRlZCBieSBTdGVwaGVuIENhc25lciBhbmQgQ29saW4gUGVya2lu cw0KDQpUaGUgQVZUIHdvcmtpbmcgZ3JvdXAgbWV0IGluIHR3byBzZXNzaW9u cyBhdCB0aGUgNTZ0aCBJRVRGIG1lZXRpbmcgaW4NClNhbiBGcmFuY2lzY28u ICBJbiB0aGUgZmlyc3Qgc2Vzc2lvbiwgdGhlIGdyb3VwIGRpc2N1c3NlZCB0 aGUgc3RhdHVzDQpvZiBzZXZlcmFsIGRvY3VtZW50cyBpbiBwcm9ncmVzcyBp bmNsdWRpbmcgdGhlIHByb2ZpbGUgZm9yIFNlY3VyZSBSVFAsDQpwbHVzIFJU UCBmcmFtaW5nIG92ZXIgVENQLCBtdWx0aXBsZSBSVENQIGV4dGVuc2lvbnMs IGFuZCB0d28gdmlkZW8NCnBheWxvYWQgZm9ybWF0cy4gIEluIHRoZSBzZWNv bmQgc2Vzc2lvbiwgdGhlIGRpc2N1c3Npb24gY292ZXJlZCBzZXZlbg0KcGF5 bG9hZCBmb3JtYXRzIHJlbGF0ZWQgdG8gYXVkaW8gKGluY2x1ZGluZyBNSURJ IGFuZCBkaXN0cmlidXRlZA0Kc3BlZWNoIHJlY29nbml0aW9uKS4NCg0KICBJ bnRyb2R1Y3Rpb24sIERvY3VtZW50IFN0YXR1cywgYW5kIE9wZW4gSXNzdWVz DQoNClRoaXMgbWVldGluZyBiZWdhbiB3aXRoIGFuIHVwZGF0ZSBieSBTdGV2 ZSBDYXNuZXIgb24gZG9jdW1lbnQNCnB1YmxpY2F0aW9uIHN0YXR1cy4gIFR3 byBtb21lbnRvdXMgc3RlcHMgd2VyZSBhY2hpZXZlZCBpbiB0aGUgZGF5cw0K cHJlY2VkaW5nIHRoZSBtZWV0aW5nOiAgVGhlIHJldmlzZWQgUlRQIHNwZWNp ZmljYXRpb24gYW5kIEEvViBwcm9maWxlDQoocmV2aXNpb25zIG9mIFJGQyAx ODg5IGFuZCAxODkwKSB3ZXJlIGFwcHJvdmVkIGJ5IHRoZSBJRVNHIGZvcg0K cHVibGljYXRpb24gYXMgRHJhZnQgU3RhbmRhcmRzLCBhbmQgdGhlIHBheWxv YWQgZm9ybWF0IGZvciBNUEVHLTQgd2FzDQpzdWJtaXR0ZWQgYnkgdGhlIHdv cmtpbmcgZ3JvdXAgdG8gdGhlIElFU0cgd2l0aCBhIHJlcXVlc3QgZm9yDQpw dWJsaWNhdGlvbiBhcyBhIFByb3Bvc2VkIFN0YW5kYXJkLiAgVGhlIFJUUCBz cGVjIGFuZCBBL1YgcHJvZmlsZSBoYWQNCmJlZW4gdGVudGF0aXZlbHkgYXBw cm92ZWQgYmVmb3JlIHRoZSBwcmV2aW91cyBtZWV0aW5nLCBidXQgdGhlcmUg d2VyZQ0Kc2V2ZXJhbCAiUkZDIEVkaXRvciBub3RlIiBjbGFyaWZpY2F0aW9u cyByZXF1ZXN0ZWQgYnkgdGhlIElFU0cuICBJbg0KYWRkaXRpb24sIGEgbnVt YmVyIG9mIHF1ZXN0aW9ucyByZWdhcmRpbmcgdGhlIHRleHQgaGF2ZSBiZWVu IHBvc3RlZCB0bw0KdGhlIFdHIG1haWxpbmcgbGlzdCBkdXJpbmcgdGhlIElF U0cgcmV2aWV3LiAgQ29uc2VxdWVudGx5LCBTdGV2ZQ0KQ2FzbmVyIHdyb3Rl IGNsYXJpZmljYXRpb25zIHRvIGFkZHJlc3MgdGhlc2UgcXVlc3Rpb25zIGFu ZCBXRw0KcGFydGljaXBhbnRzIGRpc2N1c3NlZCB0aGVtIG9uIHRoZSBtYWls aW5nIGxpc3QgYWZ0ZXIgdGhlIHByZXZpb3VzDQptZWV0aW5nLiAgVWx0aW1h dGVseSwgdGhlcmUgd2VyZSBlbm91Z2ggY2hhbmdlcyB0aGF0IHRoZSBJRVNH IGFncmVlZA0KdGhhdCB0aGUgZHJhZnRzIGNvdWxkIGJlIHJldmlzZWQgYmVm b3JlIHN1Ym1pc3Npb24gdG8gdGhlIFJGQyBlZGl0b3I6DQpkcmFmdC1pZXRm LWF2dC1ydHAtbmV3LTEyIGFuZCBkcmFmdC1pZXRmLWF2dC1wcm9maWxlLW5l dy0xMy4gIFRoZSBJRVNHDQpnYXZlIGZpbmFsIGFwcHJvdmFsIG9mIHRoZXNl IHJldmlzZWQgZHJhZnRzIGFuZCBzZW50IHRoZW0gdG8gdGhlIFJGQw0KRWRp dG9yLiAgU3RldmUgYnJpZWZseSByZXZpZXdlZCB0aGUgbGlzdCBvZiBjaGFu Z2VzIGF0IHRoaXMgbWVldGluZw0KYW5kIGFza2VkIHRob3NlIHdobyBtYWRl IGNvbW1lbnRzIGluIHRoZSBtYWlsaW5nIGxpc3QgZGlzY3Vzc2lvbiB0bw0K dmVyaWZ5IHRoYXQgdGhlIHJlc3VsdHMgYXJlIHNhdGlzZmFjdG9yeS4NCg0K V2UgY29udGludWVkIHRoZSBwYXR0ZXJuIG9mIHB1Ymxpc2hpbmcgYXQgbGVh c3Qgb25lIFJGQyBzaW5jZSB0aGUgbGFzdA0KbWVldGluZyAoUkZDIDM0OTcg b24gdGhlIHBheWxvYWQgZm9ybWF0IGZvciBTTVBURS0yOTJNIHZpZGVvKSwg YW5kDQpmb3VyIG90aGVyIGRyYWZ0cyBhcmUgaW4gdGhlIFJGQyBlZGl0b3Ig cXVldWUgKHRoZSBNSU1FIHJlZ2lzdHJhdGlvbg0KZm9yIHRoZSBwYXlsb2Fk IGZvcm1hdHMgaW4gdGhlIFJUUCBwcm9maWxlIGFuZCB0aGUgU0RQIGJhbmR3 aWR0aA0KbW9kaWZpZXJzIGZvciBSVENQIGJhbmR3aWR0aCwgYm90aCB3YWl0 aW5nIGZvciB0aGUgUlRQIHNwZWNpZmljYXRpb24sDQphbmQgdGhlIHBheWxv YWQgZm9ybWF0cyBmb3IgRVZSQy9TTVYgYW5kIEVUU0kgRVMgMjAxIDEwOCBE U1IpLiAgRm91cg0KZHJhZnRzIGFyZSB3aXRoIHRoZSBJRVNHIChFQ1JUUCB3 aGljaCBpcyBpbiBMYXN0IENhbGwsIFRDUlRQLCBTUlRQLA0KYW5kIE1QRUct NCkuDQoNClNldmVyYWwgZHJhZnRzIGFyZSBlaXRoZXIgaW4gV0cgbGFzdCBj YWxsIG9yIG1heSBiZSByZWFkeS4gIFRoZSBkcmFmdA0Kb24gUlRDUCBGZWVk YmFjayBwcm9maWxlIEFWUEYgKGRyYWZ0LWlldGYtYXZ0LXJ0Y3AtZmVlZGJh Y2stMDUpIGhhcw0KYmVlbiBpbiBsYXN0IGNhbGwgZm9yIHNvbWUgdGltZSBh bmQgaXMgYXdhaXRpbmcgYSBmaW5hbCByZXZpc2lvbi4gIFRoZQ0KY29tcGFu aW9uIGRyYWZ0IHdoaWNoIHJlcG9ydHMgb24gc2ltdWxhdGlvbnMgdG8gdmFs aWRhdGUgdGhlIHByb3RvY29sDQpkZXNpZ24gaGFzIGJlZW4gcmV2aXNlZCAo ZHJhZnQtYnVybWVpc3Rlci1hdnQtcnRjcC1mZWVkYmFjay1zaW0tMDEpDQph bmQgd2lsbCBiZSBwdWJsaXNoZWQgYXMgSW5mb3JtYXRpb25hbCBhdCB0aGUg c2FtZSB0aW1lLiAgVGhlIFJUUA0KUmV0cmFuc21pc3Npb24gZHJhZnQsIHdo aWNoIHVzZXMgdGhlIEFWUEYsIGhhcyBiZWVuIHJldmlzZWQgYmFzZWQgb24N CldHIGNvbW1lbnRzIGFuZCBpcyByZWFkeSBmb3IgV0cgbGFzdCBjYWxsIHdo ZW4gdGhlIEFWUEYgZHJhZnQgaXMNCnVwZGF0ZWQuICBUd28gZHJhZnRzIG9u IFVuZXZlbiBMZXZlbCBQcm90ZWN0aW9uIGFuZCBVbmVxdWFsIEVyYXN1cmUN ClByb3RlY3Rpb24gYXJlIGJlaW5nIGNvbnNpZGVyZWQgdG9nZXRoZXIgYXMg YWx0ZXJuYXRpdmUgbWV0aG9kczsgYSBuZXcNCmFwcHJvYWNoIGlzIHByb3Bv c2VkIGZvciBVTFAgdG8gcmV2aXNlIFJGQyAyNzMzIHRvIGZpeCBpdHMNCm5v bi1zdGFuZGFyZCB1c2Ugb2YgUlRQIGhlYWRlciBiaXRzLCBidXQgdGhpcyB3 YXMgbm90IGNvbXBsZXRlZCBiZWZvcmUNCnRoZSBtZWV0aW5nLiAgTGFzdGx5 LCBkcmFmdC1pZXRmLWF2dC1ydGNwLXJlcG9ydC1leHRucy0wMyBvbiBSVENQ DQpFeHRlbmRlZCBSZXBvcnRzIChYUikgd2FzIGRpc2N1c3NlZCBhdCB0aGlz IG1lZXRpbmcgdG8gY29uc2lkZXINCndoZXRoZXIgaXQgaXMgcmVhZHkgZm9y IGxhc3QgY2FsbC4NCg0KDQogIFNlY3VyZSBSZWFsLXRpbWUgVHJhbnNwb3J0 IFByb3RvY29sDQoNCk1hcmsgQmF1Z2hlciByZXBvcnRlZCB0aGF0IFNSVFAg KGRyYWZ0LWlldGYtYXZ0LXNydHAtMDUpIHdhcyBzdWJtaXR0ZWQNCnRvIHRo ZSBJRVNHIGluIG1pZC0yMDAyIGFuZCBJRVRGIExhc3QgQ2FsbCB3YXMgaXNz dWVkLCBidXQgdGhlDQpTZWN1cml0eSBhbmQgVHJhbnNwb3J0IEFyZWEgRGly ZWN0b3JzIGV4cHJlc3NlZCBjb25jZXJucyByZWdhcmRpbmcgdGhlDQppbnRl cmFjdGlvbiBiZXR3ZWVuIHRoZSBlbmNyeXB0aW9uIGNpcGhlcnMgYW5kIGF1 dGhlbnRpY2F0aW9uLiAgVGhvc2UNCmNvbmNlcm5zIHdlcmUgZGlzY3Vzc2Vk IGF0IHRoZSBwcmV2aW91cyBJRVRGIEFWVCBtZWV0aW5nIGFuZA0Kc3Vic2Vx dWVudGx5IHdpdGggdGhlIEFEcy4gIE1hcmsgc3VtbWFyaXplZCB0aGUgYWdy ZWVkIG1vZGlmaWNhdGlvbnM6DQphdXRoZW50aWNhdGlvbiB1c2luZyBhbiA4 MC1iaXQgTUFDIGlzIG1hbmRhdGVkIGZvciBTUlRDUCBhbmQgdGhlDQpkZWZh dWx0IGZvciBTUlRQLCBidXQgdXNlciBtYXkgY2hvb3NlIG51bGwgYXV0aGVu dGljYXRpb24gZm9yIFNSVFAuDQpQcmVjaXNlIGxhbmd1YWdlIHdpbGwgYmUg Y3JhZnRlZCBmb3IgdGhlIGRyYWZ0IGFib3V0IHdoZW4gdGhpcyBpcw0KYWNj ZXB0YWJsZSBhbmQgdG8gbWFrZSBjbGVhciB0aGUgcmlza3MuICBEaXNjdXNz aW9uIG9mIGVycm9yIHRvbGVyYW5jZQ0Kd2lsbCBiZSByZW1vdmVkIGZyb20g dGhlIGRyYWZ0LCBldmVuIHRob3VnaCBpdCB3YXMgb25lIG9mIHRoZSBvcmln aW5hbA0KZGVzaWduIHJlcXVpcmVtZW50cywgYmVjYXVzZSBpdCBoYXMgYmVj b21lIGEgcG9pbnQgb2YgY29udHJvdmVyc3kgZHVlDQp0byBpdHMgZGVwZW5k ZW5jZSBvbiBjaGFuZ2VzIGF0IHNldmVyYWwgb3RoZXIgbGF5ZXJzIG9mIHRo ZSBwcm90b2NvbA0Kc3RhY2suICBPdGhlciBjb25zaWRlcmF0aW9ucyBhcmUg c3VmZmljaWVudCB0byBqdXN0aWZ5IHRoZSBkZXNpZ24NCmRlY2lzaW9ucy4g IEF1dG9tYXRpYyBrZXkgbWFuYWdlbWVudCBpcyBtYW5kYXRlZCB0byBlbnN1 cmUgdGhhdCB0aGUNCmtleSBzdHJlYW1zIGFyZSBub3QgcmVwZWF0ZWQgaW4g b3JkZXIgdG8gYXZvaWQgYSBzZXJpb3VzIGZhaWx1cmUgY2FzZQ0Kd2l0aCB0 aGUgZGVmYXVsdCBjb3VudGVyIG1vZGUgY2lwaGVyLiAgVGhlIGF1dGhvcnMg YWxzbyByZXF1ZXN0ZWQNCnBlcm1pc3Npb24gdG8gbWFrZSBzb21lIHNtYWxs IGNoYW5nZXMvY2xhcmlmaWNhdGlvbnMgcmVmbGVjdGluZyByZWNlbnQNCmZl ZWRiYWNrIGZyb20gaW1wbGVtZW50ZXJzOyB0aGVzZSB3aWxsIGJlIHNlbnQg aW4gYSBzZXBhcmF0ZSBub3RlIHRvDQp0aGUgbGlzdC4gIE1hcmsgc3RhdGVk IHRoZSBhdXRob3JzJyBpbnRlbnRpb24gdG8gcHJvZHVjZSBhIG5ldyBkcmFm dA0KaW4gYSBjb3VwbGUgb2Ygd2Vla3MuICBTdGV2ZSBDYXNuZXIgcmVwb3J0 ZWQgdGhhdCBvdXIgQUQgQWxsaXNvbg0KTWFua2luIGhhZCBtZW50aW9uZWQg aW4gYSBzaWRlIGNvbnZlcnNhdGlvbiBhdCB0aGlzIG1lZXRpbmcgdGhhdCBz aGUNCndhbnRzIHRoaXMgZHJhZnQgdG8gZ28gYWhlYWQgcXVpY2tseS4NCg0K ICAgDQogIEZyYW1pbmcgUlRQIG92ZXIgQ29ubmVjdGlvbi1PcmllbnRlZCBU cmFuc3BvcnQNCg0KSm9obiBMYXp6YXJvIHByZXNlbnRlZCBkcmFmdC1sYXp6 YXJvLWF2dC1ydHAtZnJhbWluZy1jb250cmFucy0wMCwgYQ0KbmV3IGRyYWZ0 IHRoYXQgcmVzdGF0ZXMgdGhlIGRlc2NyaXB0aW9uIG9mIFJUUCBmcmFtaW5n IG92ZXIgVENQIHRoYXQNCndhcyByZW1vdmVkIHdoZW4gdGhlIFJUUC9BVlAg UHJvZmlsZSAoUkZDIDE4OTApIHdhcyByZXZpc2VkIHNpbmNlIG5vDQpyZXBv cnQgb2YgaW50ZXJvcGVyYWJpbGl0eSBvZiB0aGUgZmVhdHVyZSB3YXMgb2J0 YWluZWQuICBJdCBpcyBub3cNCmNsYWltZWQgdGhhdCB0aGVyZSBhcmUgaW1w bGVtZW50YXRpb25zLCBzbyBpdCB3b3VsZCBiZSBhcHByb3ByaWF0ZSB0bw0K aGF2ZSBpdCBkb2N1bWVudGVkLiAgQXMgdGhpcyBkcmFmdCB3YXMgcHJlcGFy ZWQsIHR3byByZWxhdGVkIHByb2JsZW1zDQpiZWNhbWUgYXBwYXJlbnQ6ICAx KSB0aGUgTU1VU0lDIGNvbWVkaWEgZHJhZnQgc3BlY2lmaWVzIFNEUCBzZXNz aW9uDQpkZXNjcmlwdGlvbnMgdXNpbmcgVENQIHRyYW5zcG9ydCwgYnV0IGRv ZXMgbm90IHNwZWNpZnkgYSBmb3JtYXQNCnBhcmFtZXRlciB0byBpbmRpY2F0 ZSBSVFAvQVZQIGluc2lkZSB0aGUgVENQOyBhbmQgMikgUlRTUCAoUkZDIDIz MjYpDQpzcGVjaWZpZXMgYSBzaW5nbGUgVENQIGNvbm5lY3Rpb24gY2Fycnlp bmcgaW50ZXJsZWF2ZWQgY29udHJvbCBhbmQNCmRhdGEsIGJ1dCBub3Qgc2Vw YXJhdGUgZGF0YSBzdHJlYW1zIGNhcnJpZWQgaW4gVENQLiAgVGhpcyBkcmFm dA0KaW5jbHVkZXMgc2VjdGlvbnMgdG8gYWRkcmVzcyB0aGVzZSBsYXN0IHR3 byB0b3BpY3MsIGJ1dCBpdCBpcyBhbiBvcGVuDQppc3N1ZSBmb3IgdGhlIFdH IHdoZXRoZXIgdGhlc2Ugc2hvdWxkIGJlIGtlcHQgb3IgYWJhbmRvbmVkLg0K DQpBcyBhbiBhbHRlcm5hdGl2ZSB0byB0aGlzICJjbGFzc2ljYWwiIGZyYW1p bmcgb2YgUlRQIGluIFRDUCB1c2luZyBhDQoxNi1iaXQgZnJhbWUgbGVuZ3Ro IGZpZWxkIGJldHdlZW4gZnJhbWVzLCBzb21lIHBlb3BsZSBoYXZlIHN1Z2dl c3RlZA0Kb24gdGhlIG1haWxpbmcgbGlzdCB0aGF0IHRoZSBtdWx0aXBsZXhl ZCBmcmFtaW5nIHNwZWNpZmllZCBpbiBSVFNQIGJlDQp1c2VkIGluc3RlYWQu ICBKb2huIGFza2VkIGZvciBpbnB1dCBmcm9tIHRoZSBncm91cCB3aGV0aGVy IG9uZSBvciB0aGUNCm90aGVyIChvciBib3RoIG9yIG5laXRoZXIpIGFwcHJv YWNoIHNob3VsZCBiZSBmb2xsb3dlZC4gIFN0ZXZlIENhc25lcg0Kbm90ZWQg dGhhdCB0aGUgVENQIGZyYW1pbmcgd2FzIHJlbW92ZWQgaW4gdGhlIHByb2Zp bGUgcmV2aXNpb24gZHVlIHRvDQpsYWNrIG9mIGludGVyb3AsIGFuZCBhc2tl ZCB3aGV0aGVyIHRoZXJlIHJlYWxseSBpcyBzdWZmaWNpZW50IGludGVyZXN0 DQpub3cgdG8gd2FycmFudCBwdWJsaXNoaW5nIGEgc3BlYy4gIEpvaG4gcmVw bGllZCB0aGF0IHRoaXMgaXMgbmVlZGVkIGluDQpNSURJIG92ZXIgUlRQIChz ZWUgTVdQUCwgbGF0ZXIpIGJlY2F1c2UgbXVjaCBvZiB0aGUgdXNlciBjb21t dW5pdHkgaXMNCnVuY29tZm9ydGFibGUgd2l0aCBVRFAuICBSb3NzIEZpbmxh eXNvbiBzcG9rZSBpbiBmYXZvciBvZiB1c2luZyB0aGUNClJUU1AgZnJhbWlu ZyB3aGljaCBpcyBpbXBsZW1lbnRlZCBpbiBzZXZlcmFsIFJUU1Agc2VydmVy cyBpbmNsdWRpbmcNCkFwcGxlJ3MgYW5kIGhpcyBvd24gKExpdmUuY29tKS4g IEhlbm5pbmcgU2NodWx6cmlubmUgY291bnRlcmVkIHRoYXQgaXQNCmlzIG9u bHkgcmVhbGx5IGFwcGxpY2FibGUgaWYgdGhlcmUncyBhIGNvbnRyb2wgcHJv dG9jb2wgaW4gdGhlIHNhbWUNCnN0cmVhbSwgYW5kIHN1Z2dlc3RlZCB0aGF0 IHdlIGp1c3Qgc3BlY2lmeSB0aGUgImNsYXNzaWNhbCIgZnJhbWluZyBub3cN CmFuZCBsZWF2ZSBmb3IgdGhlIGZ1dHVyZSBhIHNwZWNpZmljYXRpb24gb2Yg aG93IFJUU1AgZnJhbWluZyBjYW4gYmUNCnVzZWQgc2VwYXJhdGVseSBmcm9t IFJUU1AgKHJlcXVpcmluZyBhIGRpZmZlcmVudCBmb3JtYXQgcGFyYW1ldGVy IGluDQpTRFAgdG8gaW5kaWNhdGUgdGhhdCBmcmFtaW5nKS4gIE9uZSByZWFz b24gaXMgdGhhdCBSVFNQIGlzIHVuZGVyZ29pbmcNCnVwZGF0ZSBub3cuICBS b3NzIHN1Z2dlc3RlZCB0aGF0IHNwZWNpZnlpbmcgYSBkZWZhdWx0ICJjaGFu bmVsIElEIg0Kd291bGQgc3VmZmljZSBmb3IgdXNpbmcgUlRTUCBmcmFtaW5n IHdpdGhvdXQgYSBjb250cm9sIHByb3RvY29sLCBidXQNCm90aGVycyB3ZXJl IGNvbmNlcm5lZCB0aGF0IHRoZXJlIHdvdWxkIGJlIGEgZGVzaXJlIHRvIHVz ZSBtdWx0aXBsZXhpbmcNCndpdGggb3RoZXIgY29udHJvbCBwcm90b2NvbHMg d2hlcmUgdGhlIHN5bnRheCBvZiB0aGUgUlRTUCBmcmFtaW5nDQp3b3VsZCBj b25mbGljdCwgc28gaXQgaXMgbm90IGdlbmVyYWwuICBDb2xpbiBQZXJraW5z IHN1bW1hcml6ZWQgdGhlDQpkaXNjdXNzaW9uIGJ5IHNheWluZyB0aGF0IHRo aXMgZHJhZnQgc2hvdWxkIHJlc3RyaWN0IGl0c2VsZiB0byB0aGUNCmNsYXNz aWNhbCBmcmFtaW5nIGFuZCBsZWF2ZSB0aGUgUlRTUCBmcmFtaW5nIHRvIGJl IHNwZWNpZmllZCBzb21ld2hlcmUNCmVsc2UgaWYgdGhlcmUgaXMgaW50ZXJl c3Qgb3IgZHJvcHBlZC4gIFRoZSBTRFAgZm9ybWF0IHBhcmFtZXRlciAiVENQ DQpSVFAvQVZQIiB3b3VsZCBpbmRpY2F0ZSB0aGlzIHNpbXBsZSBjYXNlOyBv dGhlciBwYXJhbWV0ZXJzIGNvdWxkIGJlDQpkZWZpbmVkIGZvciBtdWx0aXBs ZXhlZCBmcmFtaW5nIGFzIG5lZWRlZC4NCg0KUmVnYXJkaW5nIHRoZSBvdGhl ciBwcm9ibGVtIG9mIHNwZWNpZnlpbmcgaG93IGRhdGEgY2FuIGJlIGNhcnJp ZWQgaW4NCnNlcGFyYXRlIFRDUCBzdHJlYW1zIHVuZGVyIFJUU1AsIEpvaG4g Y29uY2x1ZGVkIGFuZCBNYWdudXMgV2VzdGVybHVuZA0KYWdyZWVkIHRoYXQg dGhpcyBzaG91bGQgYmUgbGVmdCB0byB0aGUgcmV2aXNlZCBSVFAgc3BlY2lm aWNhdGlvbi4NCg0KICAgDQogIFJUQ1AgRXh0ZW5kZWQgUmVwb3J0cyAoWFIp DQoNClRpbXVyIEZyaWVkbWFuIHJldmlld2VkIHRoZSBjaGFuZ2VzIHRvIHRo ZSBSVENQIHJlcG9ydGluZyBleHRlbnNpb25zDQppbiBkcmFmdC1pZXRmLWF2 dC1ydGNwLXJlcG9ydC1leHRucy0wMiB3aXRoIG1pbm9yIGFkZGl0aW9uYWwg dXBkYXRlcw0KaW4gLTAzLiAgVGhlIFJUQ1AgcGFja2V0IHR5cGUgbnVtYmVy IGlzIGNoYW5nZWQgdG8gMjA3IHRvIGF2b2lkIHRoZQ0KY29uZmxpY3Qgd2l0 aCB0aGUgUlRDUCBGZWVkYmFjayBkcmFmdCwgYW5kIHRoZSBudW1iZXJpbmcg YW5kIHN0cnVjdHVyZQ0Kb2YgYSBmZXcgb2YgdGhlIHJlcG9ydCBibG9ja3Mg aGF2ZSBiZWVuIHNpbXBsaWZpZWQuICBUaGVyZSBhcmUgc2V2ZXJhbA0Kb3Bl biBpc3N1ZXMgcmVnYXJkaW5nIHRoZSAtMDMgcmV2aXNpb24sIHRoZSBmaXJz dCBvZiB3aGljaCBpcyB0aGF0IHRoZQ0KdGl0bGUgd2FzIGNoYW5nZWQgdG8g YXZvaWQgdGhlIG5lZWQgdG8gc3BlbGwgb3V0IHRoZSBSVENQIGFjcm9ueW0u DQpTdGV2ZSBDYXNuZXIgZmVlbHMgdGhhdCB0aGUgdGl0bGUgc2hvdWxkIHJl bWFpbiBSVENQIGJlY2F1c2UgdGhhdCBpcw0KdGhlIGFjY3VyYXRlIHRvcGlj LiAgVGhlIHRpdGxlIHdvdWxkIGJlICJSVFAgQ29udHJvbCBQcm90b2NvbCAo UlRDUCkNCkV4dGVuZGVkIFJlcG9ydHMiLCB3aGljaCBpcyBub3QgdG9vIGxv bmcuICBTZWN0aW9uIDQuMyBzcGVjaWZpZXMgaG93DQpwYWNrZXQgYXJyaXZh bCB0aW1lc3RhbXBzIGluIFJUUCB0aW1lc3RhbXAgZm9ybWF0IG1heSBiZSBy ZXBvcnRlZA0KYmFjazsgTWFnbnVzIFdlc3Rlcmx1bmQgaGFzIHN1Z2dlc3Rl ZCB0aGF0IHRoZXNlIHRpbWVzdGFtcHMgc2hvdWxkIGJlDQpjb252ZXJ0ZWQg dG8gc29tZSBmaXhlZCB1bml0cyB0byBhdm9pZCBwcm9ibGVtcyBpZiB0aGUg UlRQIHRpbWVzdGFtcA0KY2xvY2sgcmF0ZSBjaGFuZ2VzLiAgU3RldmUgQ2Fz bmVyIHNhaWQgdGhhdCBpcyBub3QgdXN1YWxseSBkb25lDQpiZWNhdXNlIGl0 IGNhdXNlcyBhIG51bWJlciBvZiBvdGhlciBjb21wbGljYXRpb25zLCBhbmQg dGhhdCB5b3Ugc2hvdWxkDQpiZSBhYmxlIHRvIHVzZSB0aGUgc2VxdWVuY2Ug bnVtYmVycyB0aGF0IGFyZSByZXR1cm5lZCB3aXRoIHRoZQ0KdGltZXN0YW1w cyB0byBzZWxlY3QgdGhlIGNvcnJlY3QgcmF0ZS4gIEhvd2V2ZXIsIFN0ZXZl IGFza2VkIGZvcg0KY2xhcmlmaWNhdGlvbiBpbiB0aGUgdGV4dCB0aGF0IHRo ZXNlIGFyZSBhcnJpdmFsIHRpbWVzdGFtcHMsIG5vdCB0aGUNCnNlbmRlcidz IHRpbWVzdGFtcHMuDQoNCkluIFNlY3Rpb24gNC40LCB0aGUgZGVmaW5pdGlv biBvZiBzdGFuZGFyZCBkZXZpYXRpb24gYW5kIFRUTCB3aWxsIGJlDQpjbGFy aWZpZWQuICBUaGUgdmFyaWFibGUgZ2VvbWV0cnkgb2YgdGhpcyBwYWNrZXQg dHlwZSwgaW5kaWNhdGVkIGJ5IGENCmJpdCBmaWVsZCwgd2FzIHNpbXBsaWZp ZWQgdG8gYSBzaW5nbGUgZm9ybWF0LiAgU29tZSBwZW9wbGUgd291bGQNCnBy ZWZlciB0aGUgc3BhY2Ugc2F2aW5ncyBvZiB0aGUgdmFyaWFibGUgZm9ybWF0 LCB3aGlsZSBvdGhlcnMgcHJlZmVyDQp0aGUgc2ltcGxpY2l0eS4gIFN0ZXZl IHN1Z2dlc3RlZCB0aGF0IGlmIHBhcnRpY3VsYXIgc3Vic2V0cyBhcmUgbW9z dA0KdXNlZnVsLCB0aGVuIHRob3NlIHN1YnNldHMgc2hvdWxkIGJlIGRlZmlu ZWQgYXMgZGlzdGluY3QgYmxvY2sgdHlwZXMuDQoNCkFsYW4gQ2xhcmsgZGlz Y3Vzc2VkIHRoZSBjaGFuZ2VzIHRvIHRoZSBWb0lQIG1ldHJpY3MgaW4gU2Vj dGlvbiA0LjcuDQpJbiAtMDIsIGVjaG8gbGV2ZWwgbWVhc3VyZW1lbnRzIHdl cmUgYWRkZWQgc2luY2UgYSBudW1iZXIgb2YNCmltcGxlbWVudGF0aW9ucyBw cm9kdWNlIHRoYXQgZGF0YS4gIEluIC0wMywgdG8gc3VwcG9ydCBmb3INCnNh bXBsZS1iYXNlZCBjb2RlY3MgYXMgd2VsbCBhcyBmcmFtZS1iYXNlZCBjb2Rl Y3MsIHRoZSBqaXR0ZXIgYnVmZmVyDQptZXRyaWMgd2FzIGNoYW5nZWQgdG8g dW5pdHMgb2YgdGltZSAoNW1zKSByYXRoZXIgdGhhbiBmcmFtZXMuICBBDQpj b3VwbGUgb2YgcGVvcGxlIHJhaXNlZCB0aGUgcXVlc3Rpb24gd2hldGhlciB0 aGUgNW1zIHVuaXQgc2hvdWxkIGJlDQoxbXMgaW5zdGVhZC4gIEFsYW4gcmVz cG9uZGVkIHRoYXQgNW1zIHNlZW1lZCBhIGJldHRlciB0cmFkZW9mZiBiZXR3 ZWVuDQpyZXNvbHV0aW9uIGFuZCByYW5nZSBmb3IgdGhlIHBlcmZvcm1hbmNl IGVmZmVjdHMgdG8gYmUgbWVhc3VyZWQuICBJdA0KY291bGQgYmUgZG9uZSwg YnV0IHdvdWxkIHJlcXVpcmUgaW5jcmVhc2luZyB0aHJlZSBmaWVsZHMgZnJv bSA4IHRvIDE2DQpiaXRzLiAgQW53YXIgPz8/IGFza2VkIGFib3V0IHRoZSBy ZXF1aXJlbWVudCB0aGF0IGFsbCBmaWVsZHMgb2YgdGhlDQpWb0lQIHJlcG9y dCBibG9jayBiZSBzdXBwb3J0ZWQuICBBbGFuIHJlc3BvbmRlZCB0aGF0IGFs dGhvdWdoIHRoZQ0KYmxvY2sgc3RydWN0dXJlIGlzIGZpeGVkLCBzb21lIG9m IHRoZSBmaWVsZHMgYWxsb3cgYW4gInVuZGVmaW5lZCINCnZhbHVlIGZvciB1 c2Ugd2hlbiB0aGUgbWV0cmljIGRvZXMgbm90IGFwcGx5LiAgU3RldmUgQ2Fz bmVyIGFza2VkIGZvcg0KdGhlIHVzZSBvZiB0aGUgdW5kZWZpbmVkIHZhbHVl IHRvIGJlIGNsYXJpZmllZC4gIEFud2FyIGFsc28gYXNrZWQgaWYNCnRoZXJl IHdvdWxkIGJlIGEgWFIgYmxvY2sgdHlwZSBmb3Igb25lLXdheSBkZWxheS4g IFRpbXVyIHJlc3BvbmRlZA0KdGhhdCB0aGlzIGNvdWxkIGJlIGFkZGVkIGlu IHRoZSBmdXR1cmUgaWYgc29tZW9uZSBkZXZlbG9wcyBhIG1ldGhvZA0KdGhh dCBwcm92ZXMgdXNlZnVsLiAgUGhpbGlwcGUgR2VudHJpYyB3YW50cyB0byBn ZXQgcmVwb3J0cyBvZg0KaW5zdGFudGFuZW91cyBmaWxsIGxldmVsIHJhdGhl ciB0aGFuIGF2ZXJhZ2U7IEFsYW4gc2FpZCB0aGUgY29sbGVjdGlvbg0Kb2Yg bWVhc3VyZXMgc2hvdWxkIGFsbG93IHRoaXMgdG8gYmUgZGV0ZXJtaW5lZC4N Cg0KU3RldmUgQ2FzbmVyIHJhaXNlZCBhIGZldyBpc3N1ZXMgcmVnYXJkaW5n IHRoZSBjb21wbGV0ZW5lc3Mgb2YgdGhlDQpkcmFmdCBhbmQgdGhlIG1lcmdp bmcgb2YgdGhlIFZvSVAgbWV0cmljcyB3aXRoIHRoZSBvdGhlciBzZWN0aW9u cy4NClRoZSBWb0lQIG1ldHJpY3MgaW5jbHVkZSBhIG1lYXN1cmUgb2Ygcm91 bmQgdHJpcCB0aW1lLCBidXQgYXMNCnNwZWNpZmllZCwgdGhpcyBpcyBvbmx5 IHBvc3NpYmxlIGlmIGRhdGEgaXMgYmVpbmcgdHJhbnNtaXR0ZWQgaW4gYm90 aA0KZGlyZWN0aW9ucy4gIFRoZSBkcmFmdCBuZWVkcyB0byBleHBsYWluIHRo YXQsIG9yIHRvIGV4cGxhaW4gd2hhdCB0byBkbw0KaWYgdGhhdCdzIG5vdCB0 aGUgY2FzZS4gIFRoZSBWb0lQIHNlY3Rpb24gY291bGQgcmVmZXIgdG8gdGhl IHRoZQ0Kbm9uLXNlbmRlciBSVFQgbWVhc3VyZW1lbnQgbWV0aG9kIGluIFNl Y3Rpb24gNC41LCBidXQgaXQgZG9lc24ndC4gIFRoZQ0KZHJhZnQgbmVlZHMg YW4gYXBwbGljYWJpbGl0eSBzdGF0ZW1lbnQgYXQgdGhlIHRvcCB0byBleHBs YWluIHdoaWNoIG9mDQp0aGUgdG9vbHMgaW4gdGhpcyB0b29sYm94IHNob3Vs ZCBiZSB1c2VkIGluIHdoaWNoIHNpdHVhdGlvbnMsIGFuZCBob3cNCnRoZXkg d291bGQgYmUgdXNlZC4gIFRoZSBkcmFmdCBzaG91bGQgYmUgY2FyZWZ1bCB0 byBhdm9pZCB1bnN0YXRlZA0KYXNzdW1wdGlvbnMgYWJvdXQgdGhlIHVzZSBj YXNlcy4gIEFub3RoZXIgcHJvYmxlbSBpcyB0aGF0IFNlY3Rpb24gNC43DQpn aXZlcyBydWxlcyBmb3IgaG93IG9mdGVuIHRoZSBWb0lQIG1ldHJpYyBibG9j a3MgbXVzdCBiZSBzZW50LiAgVGhpcw0KZHJhZnQgaXMgbm90IGFsbG93ZWQg dG8gc2F5IHRoYXQuICBUaGUgUlRQIHNwZWMgZGVmaW5lcyB0aGUgYmFzaWMg UlRDUA0KcGFja2V0IHRpbWluZywgYW5kIHRoZSBSVENQIEZlZWRiYWNrIHBy b2ZpbGUgZGVmaW5lcyBhbHRlcm5hdGUgdGltaW5nDQp1bmRlciBhIG1vcmUg cmVzdHJpY3RpdmUgdXNlIGNhc2UuICBUaGlzIGRyYWZ0IGNvdWxkIHJlZmVy IHRvIHVzZQ0KdW5kZXIgdGhlIFJUQ1AgRmVlZGJhY2sgcHJvZmlsZSwgYnV0 IGl0IGNhbid0IHNwZWNpZnkgdGltaW5nIG9mIGl0cw0Kb3duLiAgQWxhbiBy ZXNwb25kZWQgdGhhdCB0aGlzIHdvdWxkIGJlIGRvbmUsIGFuZCBjb21tZW50 ZWQgdGhhdCBpbg0Kc29tZSBjYXNlcyB0aGUgbW9yZSB1c2VmdWwgaW5mb3Jt YXRpb24gaW4gdGhlIFZvSVAgcmVwb3J0IGJsb2NrIHdvdWxkDQphbGxvdyBs ZXNzIGZyZXF1ZW50IHJlcG9ydGluZywgc2F2aW5nIGJhbmR3aWR0aC4gIFN0 ZXZlIGFncmVlZCB0aGF0IGl0DQp3b3VsZCBiZSBnb29kIHRvIGFkZCBhIHNl bnRlbmNlIHBvaW50aW5nIHRoaXMgb3V0IGJlY2F1c2UgdGhlDQppbmNyZWFz ZWQgaW4gUlRDUCBwYWNrZXQgc2l6ZSBjYXVzZWQgYnkgdGhlIGluY2x1c2lv biBvZiB0aGUgVm9JUA0KbWV0cmljcyB3aWxsIG1lYW4gdGhhdCB0aGUgaW50 ZXJ2YWwgYmV0d2VlbiBSVENQIHBhY2tldHMgaXMgaW5jcmVhc2VkLg0KDQpB IG1vcmUgY29tcGxpY2F0ZWQgaXNzdWUgcmFpc2VkIGJ5IE1hZ251cyBXZXN0 ZXJsdW5kIGlzIHRoYXQgdGhlIGRyYWZ0DQpzaG91bGQgc3BlY2lmeSBTRFAg c2lnbmFsaW5nIGZvciBpdHMgdXNlLiAgVGhpcyBpcyBhIHZhbGlkIHJlcXVl c3QsDQpidXQgbWlnaHQgaW50cm9kdWNlIHRvbyBtdWNoIGRlbGF5IGluIGNv bXBsZXRpbmcgdGhlIGRyYWZ0LiAgQ29saW4NClBlcmtpbnMgcG9pbnRlZCBv dXQgdGhlIG5lZWQgdG8gdXBkYXRlIHRoZSBkb2N1bWVudCBxdWlja2x5IGlu IG9yZGVyDQp0byBtZWV0IGEgTWF5IGRlYWRsaW5lIGZvciBjb25zaWRlcmF0 aW9uIGJ5IElUVSBILjQ2MC45LiAgVGhlDQpzcGVjaWZpY2F0aW9uIG9mIFNE UCBzaWduYWxpbmcgY291bGQgYmUgYSBzZXBhcmF0ZSBkcmFmdCwgYnV0IGl0 DQphcHBlYXJzIGZlYXNpYmxlIHRvIGluY2x1ZGUgYSBzcGVjaWZpY2F0aW9u IG9mIFNEUCBmb3IgcG9pbnQtdG8tcG9pbnQNCmFwcGxpY2F0aW9ucyBhbmQg bGVhdmUgbW9yZSBjb21wbGljYXRlZCBzY2VuYXJpb3MgZm9yIGEgc2VwYXJh dGUNCmRyYWZ0Lg0KDQoNCiAgUlRDUCBFeHRlbnNpb25zIGZvciBTU00gd2l0 aCB1bmljYXN0IGZlZWRiYWNrDQoNCkp1bGlhbiBDaGVzdGVyZmllbGQgZGlz Y3Vzc2VkIHVwZGF0ZXMgaW4gZHJhZnQtaWV0Zi1hdnQtcnRjcHNzbS0wMw0K d2hpY2ggaW50cm9kdWNlcyBzb21lIGFkZGl0aW9uYWwgc3VtbWFyeSBzdGF0 aXN0aWNzLCBzb21lDQpjbGFyaWZpY2F0aW9ucyBhbmQgZXhhbXBsZXMgb2Yg c2VjdXJpdHkgcmVxdWlyZW1lbnRzIGFuZCBob3cgdGhlDQpzZWN1cml0eSBt ZXRob2RzIHNob3VsZCBiZSB1c2VkIGZvciBSVFNQIGFuZCBTSVAgc2Vzc2lv bnMsIGFuZCB1cGRhdGVzDQp0byB0aGUgSUFOQSBjb25zaWRlcmF0aW9ucy4g IFRoZSBuZXcgc3VtbWFyeSBzdWItYmxvY2tzIGFyZSBJUHY2DQpmZWVkYmFj ayBhZGRyZXNzLCBCWUUgbGlzdCwgYW5kIFJUQ1AgcmVjZWl2ZXIgYmFuZHdp ZHRoLiAgVGhpcw0KcmV2aXNpb24gaXMgbm93IGFsaWduZWQgd2l0aCB0aGUg UlRDUCBYUiBmb3JtYXQgdGhhdCBUaW11ciBqdXN0DQpwcmVzZW50ZWQsIGFz IHdhcyBzdWdnZXN0ZWQgaW4gYSBwcmV2aW91cyBBVlQgbWVldGluZy4gIFN0 ZXZlIENhc25lcg0KY2xhcmlmaWVkIHRoYXQgdGhlIHJlYXNvbiBmb3IgdGhl IHN1Z2dlc3Rpb24gd2FzIG5vdCB0byBzYXZlIGFuIFJUQ1ANCnBhY2tldCB0 eXBlIGNvZGUgcG9pbnQsIHJhdGhlciB0byBhc2sgaWYgdGhlIHNhbWUgcmVw b3J0aW5nIG1lY2hhbmlzbXMNCmNvdWxkIGJlIHNoYXJlZCBmb3IgYm90aCBw dXJwb3NlcyByYXRoZXIgdGhhbiBkZWZpbmluZyBkaWZmZXJlbnQgb25lcy4N CklmIHRoZXJlIGlzIG5vIGZlYXNpYmxlIG1lcmdpbmcgb2YgZnVuY3Rpb25h bGl0eSwgdGhlbiB0aGVyZSBpcyBub3QgYQ0KcmVxdWlyZW1lbnQgdG8gZml0 IHRoZSBTU00gcmVwb3J0cyBpbnRvIHRoZSBYUiBibG9jayBzdHJ1Y3R1cmUg d2l0aA0KZXh0cmEgb3ZlcmhlYWQuICBUaGUgYXV0aG9ycyB3aWxsIHJlY29u c2lkZXIgdGhpcyBpc3N1ZS4NCg0KU29tZSBvcGVuIGlzc3VlcyByZW1haW4g Zm9yIHRoZSBkcmFmdDogY2xhcmlmaWNhdGlvbiB0aGF0IHRoZSBzZW5kZXIN Cm11c3QgZm9yd2FyZCBhIGdyb3VwIHNpemUgcmVwb3J0IHdoZW5ldmVyIHRo ZSBzaXplIGNoYW5nZXMgdG8gYWxsb3cNCmNvcnJlY3Qgb3BlcmF0aW9uIG9m IFJUUCB0aW1lciByZWNvbnNpZGVyYXRpb24gcnVsZXM7IHJlcG9ydGluZyBp biB0aGUNCnN1bW1hcnkgd2hhdCB0aGUgZGF0YSBjb3JyZXNwb25kcyB0byBp biB0ZXJtcyBvZiBzYW1wbGUgZ3JvdXAgc2l6ZSBhbmQNCnJlY2VpdmVyIHJl cG9ydCBhZ2U7IGFuZCB0aGUgYWxpZ25tZW50IHdpdGggWFIuICBUaGUgYXV0 aG9ycyB3b3VsZA0KbGlrZSB0byBrbm93IHdoZXRoZXIgdGhlcmUgYXJlIGFu eSBvdGhlciBpbXBsZW1lbnRhdGlvbnMgb2YgdGhpcw0KZHJhZnQsIGFuZCB3 aGV0aGVyIGl0IHdpbGwgYmUgY29uc2lkZXJlZCByZWFkeSBmb3IgV0cgbGFz dCBjYWxsIHdoZW4NCnRoZXNlIG9wZW4gaXNzdWVzIGhhdmUgYmVlbiBhZGRy ZXNzZWQuDQoNClRpbXVyIEZyaWVkbWFuIHN1Z2dlc3RzIHVzaW5nIFhSIGJs b2NrIHR5cGUgOCByYXRoZXIgdGhhbiAxMC4gIEpvaG4NCkxhenphcm8gYXNr ZWQgYWJvdXQgc3VtbWFyaXphdGlvbiBvZiB0aGUgImV4dGVuZGVkIGhpZ2hl c3Qgc2VxdWVuY2UNCm51bWJlciIgZmllbGQgZnJvbSBSVENQIHJlcG9ydHMu ICBNV1BQIHVzZXMgdGhpcyB2YWx1ZTsgaGUgd291bGQgd2FudA0KdGhlIHN1 bW1hcnkgdG8gYmUgdGhlIG1pbmltdW0gdmFsdWUgcmVwb3J0ZWQgYnkgcmVj ZWl2ZXJzLiAgSGUgd2lsbA0KdGhpbmsgYWJvdXQgdGhlIGRldGFpbHMgYW5k IG1ha2UgYSBzdWdnZXN0aW9uLiAgU3RldmUgQ2FzbmVyIGFza2VkIGhvdw0K dGhlIHN1bW1hcml6YXRpb24gbWV0aG9kcyBpbiB0aGlzIGRyYWZ0IGNvbXBh cmUgd2l0aCB0aGUgc3VtbWFyaXphdGlvbg0KbWV0aG9kcyBpbiB0aGUgWFIg ZHJhZnQuICBFdmUgU2Nob29sZXIgcmVzcG9uZGVkIHRoYXQgdGhlIG5hdHVy ZSBvZg0KdGhlIHN1bW1hcnkgbWV0aG9kcyBpbiB0aGUgdHdvIGRyYWZ0cyBp cyBkaWZmZXJlbnQuICBUaGUgWFIgZHJhZnQNCnJlcG9ydHMgc2FtcGxpbmcg b2YgZGF0YSwgd2hpbGUgU1NNIHJlcG9ydHMgbWF0aGVtYXRpY2FsDQpkaXN0 cmlidXRpb25zLiAgVGhlIGF1dGhvcnMgb2YgYm90aCBkcmFmdHMgYWdyZWVk IHRvIG1lZXQgYWZ0ZXIgdGhlDQpzZXNzaW9uIHRvIGRpc2N1c3MgdGhpcyBp biBtb3JlIGRldGFpbC4gIFN0ZXZlIGNvbW1lbnRlZCB0aGF0IHRoZQ0KcmVh c29uIGZvciByYWlzaW5nIHRoZSBwb2ludCB3YXMgdGhhdCBpZiB0aGVyZSBp cyBubyBjb21tb24NCmFwcGxpY2FiaWxpdHkgb2YgdGhlIHR3byBtZXRob2Rz LCB0aGVuIGJpbmRpbmcgdGhlbSB0b2dldGhlciBkb2VzIG5vdA0KbWFrZSBz ZW5zZS4NCg0KICAgDQogIFJUUCBQYXlsb2FkIEZvcm1hdCBmb3IgSlZUIFZp ZGVvDQoNClN0ZXBoYW4gV2VuZ2VyIGRpc2N1c3NlZCBkcmFmdC1pZXRmLWF2 dC1ydHAtaDI2NC0wMS4gIFRoZSBzcGVjIGZvciB0aGUNCkpWVCBjb2RlYyBp dHNlbGYgd2FzIGZpbmFsaXplZCBpbiBhIG1lZXRpbmcgdGhlIHByZXZpb3Vz IHdlZWsgd2l0aA0KYWNjZXB0YW5jZSBmb3IgSVNPIEZESVMgc3RhdHVzIGFu ZCB3aXRoICJDb25zZW50IiBpbiB0aGUgSVRVLVQgZHVlIG9uDQpNYXJjaCAy OCwgc28gaXQgaXMgbm93IHRpbWUgdG8gZmluYWxpemUgdGhlIHBhY2tldGl6 YXRpb24gaGVyZSBhbmQNClN0ZXBoYW4gaG9wZXMgdG8gYWNjZWxlcmF0ZSB0 aGUgcHJvY2Vzcy4gIEEgLTAyIHJldmlzaW9uIGlzIHRvIGJlDQpwcm9kdWNl ZCBzaG9ydGx5LCBhbmQgcGVyaGFwcyBvbmUgbW9yZSByZXZpc2lvbiBpZiB0 aGVyZSBhcmUgY29tbWVudHMuDQpUaGUgaG9wZSBpcyB0byBnbyB0byBXRyBs YXN0IGNhbGwgYmVmb3JlIHRoZSBuZXh0IG1lZXRpbmcuICBUaGVyZSB3ZXJl DQptYW55IGVkaXRvcmlhbCBjaGFuZ2VzIGZyb20gLTAwLCBwbHVzIGEgZmV3 IHRlY2huaWNhbCBhZGRpdGlvbnMuDQpGcmFnbWVudGF0aW9uIHdhcyBhZGRl ZCwgYnV0IG5lZWRzIG1vcmUgZGVzY3JpcHRpb24gYW5kIGFuIGV4YW1wbGUu ICBBDQoiZGVjb2Rpbmcgb3JkZXIgbnVtYmVyIiB3YXMgYWRkZWQgdG8gZmFj aWxpdGF0ZSBzb21lIHNwZWNpYWwgaGFuZGxpbmcNCm9mIHRoZSBwYWNrZXRz IHdpdGhvdXQgbmVlZGluZyB0byBkZWNvZGUgdGhlIGJpdHN0cmVhbSwgYnV0 IHRoZQ0KZGVzY3JpcHRpb24gaW4gdGhpcyByZXZpc2lvbiBpcyBpbmFkZXF1 YXRlLiAgQSBzZWN0aW9uIHdhcyBhZGRlZCBvbg0KTUlNRSByZWdpc3RyYXRp b24gYW5kIFNEUCB1c2FnZSwgYnV0IHRoaXMgbWF5IGFsc28gbmVlZCByZWZp bmVtZW50Lg0KDQpUaGUgbWFpbiBpc3N1ZSBmb3IgdGhpcyBwYXlsb2FkIGZv cm1hdCBpcyBpbnRlcm9wZXJhYmlsaXR5IHdpdGggdGhlDQpNUEVHLTQgU2lt cGxlIHBheWxvYWQgZm9ybWF0LiAgQSBuZXcgaW5mb3JtYXRpb25hbCBkcmFm dCB3aWxsIGJlDQp3cml0dGVuIHRvIGRlc2NyaWJlIGhvdyB0aGlzIGludGVy b3BlcmF0aW9uIG1heSBiZSBkb25lLiAgQ29saW4NClBlcmtpbnMgYXNrZWQg d2hldGhlciBpbnRlcm9wZXJhdGlvbiB3aXRoIFJGQyAzMDE2IGlzIHBvc3Np YmxlIGFuZA0KdGhlcmUgaXMgYW55IHByZXNzdXJlIGZvciB0aGlzLiAgU3Rl cGhhbiByZXBsaWVkIHRoYXQgaGUgdGhvdWdodCBub3QsDQpidXQgd2lsbCBp bnZlc3RpZ2F0ZSBmb3IgdGhlIGludGVyb3AgZHJhZnQuICBBcyB0aGUgaDI2 NC0wMSBkcmFmdCBub3cNCnN0YW5kcywgaXQgaXMgcG9zc2libGUgdG8gdHJh bnNtaXQgYSBzdWJzZXQgb2YgSlZUIGluIE1QRUctNCBTaW1wbGUNCmFjY2Vz cyB1bml0IGZyYWdtZW50cywgYWx0aG91Z2ggdGhlIHV0aWxpdHkgb2YgdGhp cyBpcyBub3QgY2xlYXIuICBJdA0Kd2FzIGFsc28gYWdyZWVkIGF0IHRoZSBK VlQgbWVldGluZyB0byBhZGQgYSBuZXcgZm9ybSBvZiBTVEFQIHRvIGFsbG93 DQptb3JlIHVzZWZ1bCBpbnRlcm9wZXJhdGlvbi4gIEJ1dCBpdCBoYXMgYWxz byBiZWVuIHN1Z2dlc3RlZCB0aGF0IHRoaXMNCnBheWxvYWQgZm9ybWF0IHNo b3VsZCByZS1tb2RlbCB0aGUgaW50ZXJsZWF2aW5nIG9mIE1QRUctNCBTaW1w bGUgYW5kDQp0aGF0IHRoZSBTVEFQL01UQVAgc3ludGF4IHNob3VsZCBiZSBh bGlnbmVkIHdpdGggTVBFRy00IFNpbXBsZS4gIFRoaXMNCndvdWxkIGFjaGll dmUgc3ludGFjdGljIGFsaWdubWVudCBhbGxvd2luZyBzb21lIHJlLXVzZSBv ZiBjb2RlLCBidXQNCnRoZXJlIHdvdWxkIGJlIGEgaHVnZSBzZW1hbnRpYyBk aWZmZXJlbmNlLiAgRGF2ZSBTaW5nZXIgZXhwcmVzc2VkIHRoZQ0KcG9zaXRp b24gdGhhdCB0aGlzIGRyYWZ0IHNob3VsZCBiZSBtYWRlIHRoZSBiZXN0IGl0 IGNhbiBiZSBmb3IgSC4yNjQNCmZpcnN0LCBhbmQgdGhlbiBjb25zaWRlciBp bnRlcm9wLiAgVGhlIG9ubHkgc29saWQgcmVxdWlyZW1lbnQgZm9yDQppbnRl cm9wIGlzIHRoYXQgaXQgbXVzdCBiZSBwb3NzaWJsZSBmb3IgYSB2aWRlbyBz dHJlYW0gdXNpbmcgdGhpcw0KcGF5bG9hZCBmb3JtYXQgdG8gYmUgcGFydCBv ZiBhbiBNUEVHLTQgcHJlc2VudGF0aW9uLiAgVGhhdCBpcyBhbHJlYWR5DQpw b3NzaWJsZS4gIEl0IHdhcyBhZ3JlZWQgbm90IHRvIGludHJvZHVjZSBteXRo aWNhbCBzaW1pbGFyaXRpZXMuDQoNCkF0IHRoZSBwcmV2aW91cyBBVlQgbWVl dGluZywgU3RlcGhhbiB3YXMgcmVzaXN0aW5nIHRoZSBhZGRpdGlvbiBvZg0K bWVkaWEtdW5hd2FyZSBmcmFnbWVudGF0aW9uLCBidXQgaGFzIGFkZGVkIGl0 IGluIHRoaXMgcmV2aXNpb24gYmVjYXVzZQ0KaXQgbWF5IGJlIG5lY2Vzc2Fy eSB0byB0cmFuc3BvcnQgYSBOQUxVIG9mIHNpemUgZ3JlYXRlciB0aGFuIDY0 S0INCndoaWNoIGlzIHRoZSBtb3N0IHRoYXQgSVB2NCBmcmFnbWVudGF0aW9u IGNhbiBoYW5kbGUuICBJbiBhZGRpdGlvbiwgaW4NCnRoZXJlIG1heSBiZSBj b250ZW50IHByZS1yZWNvcmRlZCB3aXRoIGEgTkFMVSBzaXplIHRoYXQgZG9l cyBub3QgZml0DQp0aGUgTVRVIHNpemUgb2YgYSBkZWxpdmVyeSBuZXR3b3Jr LiAgRG9pbmcgdGhlIGZyYWdtZW50YXRpb24gYXQgdGhlDQphcHBsaWNhdGlv biBsYXllciBhbGxvd3MgYXBwbGljYXRpb24gb2YgdG9vbHMgc3VjaCBhcyBS RkMgMjczMyBGRUMgZm9yDQpiZXR0ZXIgcHJvdGVjdGlvbiBlZmZpY2llbmN5 Lg0KDQpUaGUgc2VjdXJpdHkgc2VjdGlvbiBvZiB0aGUgZG9jdW1lbnQgbmVl ZHMgdG8gYmUgZXhwYW5kZWQgYmV5b25kIHRoZQ0KbWluaW1hbCB0ZXh0IGlu IC0wMS4gIFRoZSBtYWluIGlzc3VlIGlzIHRoZSB2dWxuZXJhYmlsaXR5IG9m IFBhcmFtZXRlcg0KU2V0cyB3aGVuIHRyYW5zbWl0dGVkIGluLWJhbmQuICBU aGlzIGlzIGFkZHJlc3NlZCBpbiB0aGUgY29kZWMgc3BlYywNCmFuZCBDb2xp biBQZXJraW5zIHNhaWQgYSBub3JtYXRpdmUgcmVmZXJlbmNlIGNvdWxkIGJl IG1hZGUgdG8gdGhhdC4NClN0ZXZlIENhc25lciBhc2tlZCB3aHkgdGhlIGlu LWJhbmQgdHJhbnNtaXNzaW9uIG9mIFBhcmFtZXRlciBTZXRzDQpzaG91bGQg YmUgYWxsb3dlZCBhdCBhbGwsIGdpdmVuIHRoYXQgdGhlIGRyYWZ0IHNheXMg aXQgaXMgYSBiYWQgaWRlYS4NClN0ZXBoYW4gcmVwbGllZCB0aGF0IGl0IGlz IG5lY2Vzc2FyeSBpbiBzb21lIHNjZW5hcmlvcyBpbnZvbHZpbmcNCmdhdGV3 YXlzLiAgUGhpbGlwcGUgR2VudHJpYyBleHByZXNzZWQgc2VyaW91cyBjb25j ZXJuIHRoYXQgaWYgdGhpcw0KcHJhY3RpY2UgaXMgYWxsb3dlZCB0aGVuIHBl b3BsZSB3aWxsIHVzZSBpdCB3aGVuIGl0IHNob3VsZG4ndCBiZSB1c2VkLA0K YW5kIGl0IHdpbGwgY2F1c2UgZW5kbGVzcyBoZWFkYWNoZXMgc2ltaWxhciB0 byB0aG9zZSBhbHJlYWR5IHNlZW4gd2l0aA0KUkZDIDMwMTYuICBTdGVwaGFu IHNhaWQgdGhlIGRyYWZ0IHdpbGwgc2F5IFNIT1VMRCBOT1QgdG8gZGlzY291 cmFnZQ0KaXRzIHVzZS4gIFRoZSBjb2RlYyBzcGVjIGFsc28gaW5jbHVkZXMg dGhlIG1lYW5zIHRvIHRyYW5zbWl0IGRhdGEgb2YNCnVua25vd24gdHlwZSB0 aGF0IG1heSBvciBtYXkgbm90IGJlIGFjdGl2ZSBpbmZvcm1hdGlvbiwgZm9y IGV4YW1wbGUgYQ0Kc2V0LXRvcCBib3ggc29mdHdhcmUgdXBkYXRlIHRoYXQg Y291bGQgY29udGFpbiBhIHZpcnVzLiAgU3RlcGhhbiBhc2tzDQpmb3IgaGVs cCBvbiBzZWN1cml0eSBsYW5ndWFnZSB0byBhZGRyZXNzIHRoaXMgcHJvYmxl bS4NCg0KQW5vdGhlciBvcGVuIGlzc3VlIGlzIHZpZGVvIGNvbmZlcmVuY2lu ZyBzdXBwb3J0LiAgU3RlcGhhbiB3b3VsZCBsaWtlDQp0byBzcGVjaWZ5IE1J TUUgY29kZXBvaW50cyBmb3IgbGV2ZWxzIG9mIG9wZXJhdGlvbiBiZXlvbmQg dGhvc2UNCmluY2x1ZGVkIGluIHRoZSBjb2RlYyBzcGVjLCBlLmcuIDcwNHg1 NzYgaW1hZ2VzIGF0IDcuNSBmcHMuICBDb2xpbg0KYXNrZWQgd2hldGhlciB0 aGVzZSBtb2RlcyB3aWxsIGJlIGFkZGVkIGluIGZ1dHVyZSByZXZpc2lvbnMg b2YgdGhlDQpjb2RlYyBzcGVjLCB3aGljaCB3b3VsZCByZXN1bHQgaW4gdHdv IHdheXMgdG8gc3BlY2lmeSB0aGUgc2FtZSBtb2RlLg0KU3RlcGhhbiBzYWlk IG5vLiAgVGhlcmUgaXMgYWxzbyBhIHF1ZXN0aW9uIHdoZXRoZXIgdGhpcyBw YXlsb2FkIGZvcm1hdA0KaXMgdGhlIHJpZ2h0IHBsYWNlIHRvIHNwZWNpZnkg d2hldGhlciB0aGUgcmVzcG9uc2UgdG8gYSByZXF1ZXN0IGZvciBhDQpmdWxs IGludHJhZnJhbWUgaXMgbWFuZGF0b3J5LiAgSXQgd2FzIGFncmVlZCB0aGF0 IHRoaXMgcGF5bG9hZCBmb3JtYXQNCmNhbm5vdCBzcGVjaWZ5IHRoYXQgYmVj YXVzZSBpdCBpcyBzdWJqZWN0IHRvIGNvbmdlc3Rpb24gY29udHJvbC4NCkNv bGluIHNhaWQgdGhpcyB0b3BpYyB3aWxsIGJlIGRpc2N1c3NlZCBzZXBhcmF0 ZWx5IGluIGNvbWUgY29tYmluYXRpb24NCm9mIEFWVCBhbmQgTU1VU0lDLg0K DQpUaGUgbGFzdCBvcGVuIGlzc3VlIGlzIHJlZ2FyZGluZyB0aW1lc3RhbXBz IGZvciBGaWVsZCBtb2RlLCB3aGVyZQ0KdGhlcmUgbWF5IGJlIHNlcGFyYXRl IHNhbXBsaW5nIGluc3RhbnRzIGZvciB0aGUgdHdvIGZpZWxkcyBvZiBhDQpw aWN0dXJlLiAgRGlzY3Vzc2lvbiByZXF1aXJlcyBkZXRhaWxlZCBrbm93bGVk Z2Ugb2YgSC4yNjQsIHNvIHdhcw0KZGVmZXJyZWQuDQoNCiAgIA0KICBSVFAg UGF5bG9hZCBGb3JtYXQgZm9yIHVuY29tcHJlc3NlZCB2aWRlbw0KDQpMYWRh biBHaGFyYWkgcmV2aWV3ZWQgdGhlIG1vZGlmaWNhdGlvbnMsIGFkZGl0aW9u cywgYW5kIHJlbWFpbmluZyBvcGVuDQppc3N1ZXMgZm9yIGRyYWZ0LWlldGYt YXZ0LXVuY29tcC12aWRlby0wMi4gIFRoZSBwYXlsb2FkIGhlYWRlciBub3cN CmV4dGVuZHMgdGhlIHNlcXVlbmNlIG51bWJlciBpbiB0aGUgUlRQIGhlYWRl ciB0byAzMiBiaXRzIHRvDQphY2NvbW1vZGF0ZSBoaWdoIGRhdGEgcmF0ZXMu ICBBZGRpdGlvbmFsIGNvbG9yIGNvZGluZ3MgZm9yIDQ6MToxIGFuZA0KNDoy OjAgaW50ZXJsYWNlZCBhbmQgcHJvZ3Jlc3NpdmUgd2VyZSBhZGRlZCwgYW5k IHNlcGFyYXRlIHRpbWVzdGFtcHMNCmFyZSBzcGVjaWZpZWQgb24gaW50ZXJs YWNlZCBmaWVsZHMgdG8gYWNjb21tb2RhdGUgcmV2ZXJzaW5nIDM6Mg0KcHVs bGRvd24gKGFuIGlzc3VlIHRoYXQgd2FzIHJhaXNlZCBhdCB0aGUgcHJldmlv dXMgbWVldGluZykuICBUaGUNCmRyYWZ0IG5vdyBzcGVjaWZpZXMgcmVxdWly ZWQgYW5kIG9wdGlvbmFsIFNEUCBwYXJhbWV0ZXJzIChyYXRlLA0KcGdyb3Vw LCBjb2xvci1tb2RlLCBldGMuKSBhbmQgY292ZXJzIGNvbmdlc3Rpb24gY29u dHJvbCBpbiBTZWN1cml0eQ0KQ29uc2lkZXJhdGlvbnMgKGEgc2VyaW91cyBp c3N1ZSBmb3IgdmVyeSBoaWdoIGRhdGEgcmF0ZXMpLg0KDQpUaGVyZSBhcmUg c29tZSBvcGVuIGlzc3Vlcy4gIEF0IHRoZSBwcmV2aW91cyBJRVRGIGl0IHdh cyBzdWdnZXN0ZWQNCnRoYXQgYSBwbGFuYXIgdmlkZW8gbW9kZSBiZSBhZGRl ZCB0byB0aGUgZHJhZnQsIGkuZS4sIHNlbmRpbmcgWSwgQ2INCmFuZCBDciBw bGFuZXMgc2VwYXJhdGVseS4gIFRoaXMgcmVxdWlyZXMgYSAyLWJpdCBmaWVs ZCwgd2hpY2ggY291bGQgYmUNCnN0b2xlbiBmcm9tIHRoZSBsZW5ndGggZmll bGQsIHRvIGluZGljYXRlIHdoaWNoIHBsYW5lLiAgVGhlIG1haW4NCmNvbmNl cm4gaXMgdGhhdCBhIHN1YnN0YW50aWFsIHBvcnRpb24gb2YgdGhlIGRyYWZ0 IHJlbGF0ZWQgdG8gcGdyb3Vwcw0KYW5kIGNvbG9yIHN1YnNhbXBsaW5nIHdv dWxkIGJlIGlycmVsZXZhbnQgdG8gdGhpcyBtb2RlLiAgRG9lcyBpdCBtYWtl DQpzZW5zZSB0byBjb21iaW5lIHRoZXNlIGRpc3BhcmF0ZSBtb2RlcyBpbiBv bmUgZHJhZnQ/ICBTdGVwaGFuIFdlbmdlcg0KcmVjb21tZW5kZWQga2VlcGlu ZyB0aGVtIHNlcGFyYXRlLiAgVHdvIGJpdHMgbWF5IG5vdCBiZSBlbm91Z2gg c2luY2UNCnRoZXJlIGFyZSBzb21lIGNvbG9yIG1vZGVscyB3aXRoIG1vcmUg dGhhbiA0IHBsYW5lcywgYW5kIHRoZSBwbGFuZQ0KbnVtYmVyaW5nIHdvdWxk IG5lZWQgdG8gYmUgc3BlY2lmaWVkIGZvciBhbGwgdGhlc2UgbW9kZWxzLiAg SGUgYWxzbw0KZmVsdCB0aGlzIHdvdWxkIG5vdCBiZSB1c2VkIGJlY2F1c2Ug ZGlzcGxheSBzeXN0ZW1zIGFyZSBidWlsdCB0bw0KcmVjZWl2ZSBkYXRhIGlu IHRoYXQgZm9ybS4gIFBoaWxpcHBlIEdlbnRyaWMgY291bnRlcmVkIHRoYXQg c3lzdGVtcw0KZG9pbmcgcHJvY2Vzc2luZywgcmF0aGVyIHRoYW4gZGlzcGxh eSwgZG8gb3BlcmF0ZSBvbiB0aGUgcGxhbmVzDQpzZXBhcmF0ZWx5LCBhbmQg c2luY2UgdGhleSBvcGVyYXRlIGF0IGdpZ2FiaXQgcmF0ZXMsIHNhdmluZyBt ZW1vcnkNCnNodWZmbGluZyBpcyBpbXBvcnRhbnQuICBIb3dldmVyLCBhZnRl ciBzb21lIHN0dWR5IGhlIGNvbmNsdWRlZCB0aGF0DQp0aGUgaW1wbGVtZW50 YXRpb25zIGRpZmZlciBzbyBtdWNoIHRoYXQgYSBzaW5nbGUgZm9ybWF0IHdv bid0IGhlbHAuDQpJdCB3YXMgYWdyZWVkIHRvIGRyb3AgcGxhbmFyIG1vZGUu DQoNCk9uIHRoZSBvdGhlciBoYW5kLCB0aGUgZ3JvdXAgZmVsdCBpdCB3YXMg d29ydGh3aGlsZSB0byBrZWVwIHRoZQ0KZGV0YWlsZWQgbGlzdGluZyBvZiBw Z3JvdXAgdmFsdWVzIHJhdGhlciB0aGFuIGp1c3QgdGhlIHRleHQgZXhwbGFp bmluZw0KdGhlIHJ1bGVzIGZvciBkZXRlcm1pbmluZyB0aGUgdmFsdWVzLiAg TGFkYW4gYXNrZWQgaWYgYW55b25lIGhhcw0KYWRkaXRpb25hbCBjb2xvciBz dWJzYW1wbGluZyBvciBjb2xvcmltZXRyeSB2YWx1ZXMgdGhhdCBzaG91bGQg YmUNCmluY2x1ZGVkIGluIHRoZSBkcmFmdC4gIFN0ZXBoYW4gV2VuZ2VyIHNh aWQgaGUgaGFkIHNldmVyYWwgdGhhdCBoZQ0Kd291bGQgZGlzY3VzcyBhZnRl ciB0aGUgbWVldGluZy4gIFN0ZXZlIENhc25lciBzYWlkIHRoZSBkcmFmdCBu ZWVkcyB0bw0Kc3BlY2lmeSB0aGUgbWVhbnMgZm9yIGRlZmluaW5nIGFuZCBy ZWdpc3RlcmluZyBuZXcgdmFsdWVzIGFmdGVyIHRoZQ0KZHJhZnQgaXMgcHVi bGlzaGVkLg0KDQpUaGUgbGFzdCBxdWVzdGlvbiB3YXMgd2hldGhlciB0aGVy ZSBzaG91bGQgYmUgYSBtZWFucyB0byBpbmRlcGVuZGVudGx5DQpyZXByZXNl bnQgU01QVEUgdGltZWNvZGVzLCBvciBhcmUgdGhlIFJUUCBhbmQgUlRDUCBT UCB0aW1lc3RhbXBzDQpzdWZmaWNpZW50LiAgRGF2ZSBTaW5nZXIgc2FpZCB0 aGUgU01QVEUgdGltZWNvZGVzIGFyZSByZXF1aXJlZCBmb3INCnNvbWUgdmlk ZW8gYXBwbGljYXRpb25zIGJlY2F1c2UgdGhleSBjYW4gaGF2ZSBnYXBzIGlu IGVkaXRlZCBwcm9ncmFtcywNCmJ1dCBpdCBpcyBvcnRob2dvbmFsIHRvIHRo ZSBkYXRhIGZvcm1hdCBvZiB0aGUgdmlkZW8uICBDb2xpbiBQZXJraW5zDQph c2tlZCB3aGV0aGVyIHRoZSBOUFQgbWFwcGluZyBpbiBSVFNQIHNvbHZlcyB0 aGlzIHByb2JsZW0gb3Igd2hldGhlcg0Kc29tZSBtZWFucyBpcyBuZWVkZWQg aW4gdGhlIHBheWxvYWQgZm9ybWF0LiAgUGhpbGlwcGUgR2VudHJpYyBzYWlk DQp0aGlzIGlzIHJlYWxseSBuZWVkZWQgZm9yIHN0dWRpbyB3b3JrLCBhbmQg cmVjb21tZW5kZWQgdGhhdCB0aGVyZSBiZSBhDQpzZXBhcmF0ZSBwYXlsb2Fk IGZvcm1hdCBkZWZpbmVkIGZvciBjYXJyeWluZyBqdXN0IHRoZSBTTVBURSB0 aW1lY29kZXMNCnRoYXQgY291bGQgdGhlbiBiZSBzeW5jaHJvbml6ZWQgd2l0 aCBSVFAgbWVjaGFuaXNtcyB0byBhbnkgcGF5bG9hZA0KZm9ybWF0LiAgQ29s aW4gcmVjYWxsZWQgYSBwcm9wb3NhbCBmb3IgdGhhdCBhIGNvdXBsZSBvZiB5 ZWFycyBhZ28sIGFuZA0Kc3VnZ2VzdGVkIHRoYXQgd2UgcmVzdXJyZWN0IGl0 LiAgU3RlcGhhbiBhZHZpc2VkIHdlIG5lZWQgaW5wdXQgb24gcmVhbA0KdXNh Z2UgY2FzZXMgaW4gb3JkZXIgdG8gcHJvZHVjZSBhbnl0aGluZyB1c2VmdWwu ICBKb2huIExhenphcm8gc2FpZA0KdGhhdCBNSURJIHRpbWVjb2RlcyBhcmUg U01QVEUgdGltZWNvZGVzIGVuY29kZWQgaW4gTUlESSwgYW5kIE1XUFANCnBy b3ZpZGVzIGEgbWVhbnMgdG8gdHJhbnNwb3J0IHRoZXNlIHdpdGggcmVzaWxp ZW5jeS4gIFRoaXMgd291bGQgYmUgYQ0Kc29sdXRpb24sIHBlcmhhcHMgYSBn cm9zcyBvbmUuDQo= --0-738478263-1050266884=:26225-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Sun Apr 13 18:16:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07842 for ; Sun, 13 Apr 2003 18:16:27 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3DMNnC20532 for avt-archive@odin.ietf.org; Sun, 13 Apr 2003 18:23:49 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3DMMO820483; Sun, 13 Apr 2003 18:22:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3DMJL820410 for ; Sun, 13 Apr 2003 18:19:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07377 for ; Sun, 13 Apr 2003 18:11:30 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 194pjg-0006Ps-00 for avt@ietf.org; Sun, 13 Apr 2003 18:14:04 -0400 Received: from snap.cs.berkeley.edu ([128.32.34.209] ident=root) by ietf-mx with esmtp (Exim 4.12) id 194pjf-0006Pp-00 for avt@ietf.org; Sun, 13 Apr 2003 18:14:03 -0400 Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.11.6/8.9.3-ZUUL) id h3DMDpV22738 for avt@ietf.org; Sun, 13 Apr 2003 15:13:51 -0700 Date: Sun, 13 Apr 2003 15:13:51 -0700 From: John Lazzaro Message-Id: <200304132213.h3DMDpV22738@snap.CS.Berkeley.EDU> To: avt@ietf.org Subject: [AVT] Re: Draft minutes for first IETF56 AVT session Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , > Stephen Casner writes: > > Audio/Video Transport Working Group Minutes [...] > > RTP Payload Format for uncompressed video [...] > > The last question was whether there should be a means > to independently represent SMPTE timecodes [...] > > Stephan advised we need input on real usage cases in > order to produce anything useful. I'd recommend this paper -- it was very useful in helping me think through how MTC (MIDI Time Code, i.e. SMPTE 12M over MIDI 1.0 DIN cables) sent over MWPP could end up being used in multi-stream RTP sessions: Terry K, Todd C. An open model for audio elementary stream encoding in a DTV distribution chain. [Journal Paper] SMPTE Journal-Society of Motion Picture & Television Engineers, vol.107, no.11, Nov. 1998, pp.950-60. Publisher: Soc. Motion Picture & Telev. Eng, USA. Abstract This paper addresses issues of audio distribution for modern digital television (DTV) systems focusing on digital broadcast systems. In particular, a model is described for handling audio and video elementary streams in existing distribution networks. The model supports new system architectures that allow audio and video coding to take place at many points in the distribution chain. It covers both physical and logical interface formats, synchronization with associated video signals, and carriage of metadata associated with the audio. The model also demonstrates that many audio features of new digital delivery formats can be exploited by existing broadcast systems with minimal additional equipment investment. It makes use of existing AES and SMPTE standards; however, new standards and recommended practices to support the open model may be desired by the industry. Specific recommendations are discussed. In addition, examples of systems applying the model to DTV broadcast facilities are described including examples of products that implement the audio coding function using the model. ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro ------------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Sun Apr 13 23:23:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11209 for ; Sun, 13 Apr 2003 23:23:26 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3E3Ur103742 for avt-archive@odin.ietf.org; Sun, 13 Apr 2003 23:30:53 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3E3UI803727; Sun, 13 Apr 2003 23:30:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3E3Oh803557 for ; Sun, 13 Apr 2003 23:24:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11103 for ; Sun, 13 Apr 2003 23:16:46 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 194uV5-00076v-00 for avt@ietf.org; Sun, 13 Apr 2003 23:19:19 -0400 Received: from dial162.east.isi.edu ([65.114.169.162] helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 194uUx-00076m-00 for avt@ietf.org; Sun, 13 Apr 2003 23:19:11 -0400 Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with ESMTP id h3E3IqOJ007563; Sun, 13 Apr 2003 23:18:53 -0400 (EDT) (envelope-from csp@purple.nge.isi.edu) Message-Id: <200304140318.h3E3IqOJ007563@purple.nge.isi.edu> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Stephen Casner cc: AVT WG Subject: Re: [AVT] Draft minutes for first IETF56 AVT session In-Reply-To: Your message of "Sun, 13 Apr 2003 13:48:04 PDT." <20030413134251.D26225-200000@oak.packetdesign.com> Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="==_Exmh_4543271920" Date: Sun, 13 Apr 2003 23:18:52 -0400 From: Colin Perkins Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This is a multipart MIME message. --==_Exmh_4543271920 Content-Type: text/plain; charset=us-ascii --> Stephen Casner writes: > >Attached are the minutes for the first session (Wednesday afternoon) >of the AVT meeting at IETF 56 in San Francisco. Colin is separately >writing the minutes for the second session. > >These minutes need to be turned in by the end of the day tomorrow >(Monday), so any comments you can provide quickly would be >appreciated. Here is a revision, including the second session. Colin --==_Exmh_4543271920 Content-Type: text/plain ; name="minutes.txt"; charset=us-ascii Content-Description: minutes.txt Content-Disposition: attachment; filename="minutes.txt" Audio/Video Transport Working Group Minutes Reported by Stephen Casner and Colin Perkins The AVT working group met in two sessions at the 56th IETF meeting in San Francisco. In the first session, the group discussed the status of several documents in progress including the profile for Secure RTP, plus RTP framing over TCP, multiple RTCP extensions, and two video payload formats. In the second session, the discussion covered seven payload formats related to audio (including MIDI and distributed speech recognition). Introduction, Document Status, and Open Issues This meeting began with an update by Steve Casner on document publication status. Two momentous steps were achieved in the days preceding the meeting: The revised RTP specification and A/V profile (revisions of RFC 1889 and 1890) were approved by the IESG for publication as Draft Standards, and the payload format for MPEG-4 was submitted by the working group to the IESG with a request for publication as a Proposed Standard. The RTP spec and A/V profile had been tentatively approved before the previous meeting, but there were several "RFC Editor note" clarifications requested by the IESG. In addition, a number of questions regarding the text have been posted to the WG mailing list during the IESG review. Consequently, Steve Casner wrote clarifications to address these questions and WG participants discussed them on the mailing list after the previous meeting. Ultimately, there were enough changes that the IESG agreed that the drafts could be revised before submission to the RFC editor: draft-ietf-avt-rtp-new-12 and draft-ietf-avt-profile-new-13. The IESG gave final approval of these revised drafts and sent them to the RFC Editor. Steve briefly reviewed the list of changes at this meeting and asked those who made comments in the mailing list discussion to verify that the results are satisfactory. We continued the pattern of publishing at least one RFC since the last meeting (RFC 3497 on the payload format for SMPTE-292M video), and four other drafts are in the RFC editor queue (the MIME registration for the payload formats in the RTP profile and the SDP bandwidth modifiers for RTCP bandwidth, both waiting for the RTP specification, and the payload formats for EVRC/SMV and ETSI ES 201 108 DSR). Four drafts are with the IESG (ECRTP which is in Last Call, TCRTP, SRTP, and MPEG-4). Several drafts are either in WG last call or may be ready. The draft on RTCP Feedback profile AVPF (draft-ietf-avt-rtcp-feedback-05) has been in last call for some time and is awaiting a final revision. The companion draft which reports on simulations to validate the protocol design has been revised (draft-burmeister-avt-rtcp-feedback-sim-01) and will be published as Informational at the same time. The RTP Retransmission draft, which uses the AVPF, has been revised based on WG comments and is ready for WG last call when the AVPF draft is updated. Two drafts on Uneven Level Protection and Unequal Erasure Protection are being considered together as alternative methods; a new approach is proposed for ULP to revise RFC 2733 to fix its non-standard use of RTP header bits, but this was not completed before the meeting. Lastly, draft-ietf-avt-rtcp-report-extns-03 on RTCP Extended Reports (XR) was discussed at this meeting to consider whether it is ready for last call. Secure Real-time Transport Protocol Mark Baugher reported that SRTP (draft-ietf-avt-srtp-05) was submitted to the IESG in mid-2002 and IETF Last Call was issued, but the Security and Transport Area Directors expressed concerns regarding the interaction between the encryption ciphers and authentication. Those concerns were discussed at the previous IETF AVT meeting and subsequently with the ADs. Mark summarized the agreed modifications: authentication using an 80-bit MAC is mandated for SRTCP and the default for SRTP, but user may choose null authentication for SRTP. Precise language will be crafted for the draft about when this is acceptable and to make clear the risks. Discussion of error tolerance will be removed from the draft, even though it was one of the original design requirements, because it has become a point of controversy due to its dependence on changes at several other layers of the protocol stack. Other considerations are sufficient to justify the design decisions. Automatic key management is mandated to ensure that the key streams are not repeated in order to avoid a serious failure case with the default counter mode cipher. The authors also requested permission to make some small changes/clarifications reflecting recent feedback from implementers; these will be sent in a separate note to the list. Mark stated the authors' intention to produce a new draft in a couple of weeks. Steve Casner reported that our AD Allison Mankin had mentioned in a side conversation at this meeting that she wants this draft to go ahead quickly. Framing RTP over Connection-Oriented Transport John Lazzaro presented draft-lazzaro-avt-rtp-framing-contrans-00, a new draft that restates the description of RTP framing over TCP that was removed when the RTP/AVP Profile (RFC 1890) was revised since no report of interoperability of the feature was obtained. It is now claimed that there are implementations, so it would be appropriate to have it documented. As this draft was prepared, two related problems became apparent: 1) the MMUSIC comedia draft specifies SDP session descriptions using TCP transport, but does not specify a format parameter to indicate RTP/AVP inside the TCP; and 2) RTSP (RFC 2326) specifies a single TCP connection carrying interleaved control and data, but not separate data streams carried in TCP. This draft includes sections to address these last two topics, but it is an open issue for the WG whether these should be kept or abandoned. As an alternative to this "classical" framing of RTP in TCP using a 16-bit frame length field between frames, some people have suggested on the mailing list that the multiplexed framing specified in RTSP be used instead. John asked for input from the group whether one or the other (or both or neither) approach should be followed. Steve Casner noted that the TCP framing was removed in the profile revision due to lack of interop, and asked whether there really is sufficient interest now to warrant publishing a spec. John replied that this is needed in MIDI over RTP (see MWPP, later) because much of the user community is uncomfortable with UDP. Ross Finlayson spoke in favor of using the RTSP framing which is implemented in several RTSP servers including Apple's and his own (Live.com). Henning Schulzrinne countered that it is only really applicable if there's a control protocol in the same stream, and suggested that we just specify the "classical" framing now and leave for the future a specification of how RTSP framing can be used separately from RTSP (requiring a different format parameter in SDP to indicate that framing). One reason is that RTSP is undergoing update now. Ross suggested that specifying a default "channel ID" would suffice for using RTSP framing without a control protocol, but others were concerned that there would be a desire to use multiplexing with other control protocols where the syntax of the RTSP framing would conflict, so it is not general. Colin Perkins summarized the discussion by saying that this draft should restrict itself to the classical framing and leave the RTSP framing to be specified somewhere else if there is interest or dropped. The SDP format parameter "TCP RTP/AVP" would indicate this simple case; other parameters could be defined for multiplexed framing as needed. Regarding the other problem of specifying how data can be carried in separate TCP streams under RTSP, John concluded and Magnus Westerlund agreed that this should be left to the revised RTP specification. RTCP Extended Reports (XR) Timur Friedman reviewed the changes to the RTCP reporting extensions in draft-ietf-avt-rtcp-report-extns-02 with minor additional updates in -03. The RTCP packet type number is changed to 207 to avoid the conflict with the RTCP Feedback draft, and the numbering and structure of a few of the report blocks have been simplified. There are several open issues regarding the -03 revision, the first of which is that the title was changed to avoid the need to spell out the RTCP acronym. Steve Casner feels that the title should remain RTCP because that is the accurate topic. The title would be "RTP Control Protocol (RTCP) Extended Reports", which is not too long. Section 4.3 specifies how packet arrival timestamps in RTP timestamp format may be reported back; Magnus Westerlund has suggested that these timestamps should be converted to some fixed units to avoid problems if the RTP timestamp clock rate changes. Steve Casner said that is not usually done because it causes a number of other complications, and that you should be able to use the sequence numbers that are returned with the timestamps to select the correct rate. However, Steve asked for clarification in the text that these are arrival timestamps, not the sender's timestamps. In Section 4.4, the definition of standard deviation and TTL will be clarified. The variable geometry of this packet type, indicated by a bit field, was simplified to a single format. Some people would prefer the space savings of the variable format, while others prefer the simplicity. Steve suggested that if particular subsets are most useful, then those subsets should be defined as distinct block types. Alan Clark discussed the changes to the VoIP metrics in Section 4.7. In -02, echo level measurements were added since a number of implementations produce that data. In -03, to support for sample-based codecs as well as frame-based codecs, the jitter buffer metric was changed to units of time (5ms) rather than frames. A couple of people raised the question whether the 5ms unit should be 1ms instead. Alan responded that 5ms seemed a better tradeoff between resolution and range for the performance effects to be measured. It could be done, but would require increasing three fields from 8 to 16 bits. Anwar ??? asked about the requirement that all fields of the VoIP report block be supported. Alan responded that although the block structure is fixed, some of the fields allow an "undefined" value for use when the metric does not apply. Steve Casner asked for the use of the undefined value to be clarified. Anwar also asked if there would be a XR block type for one-way delay. Timur responded that this could be added in the future if someone develops a method that proves useful. Philippe Gentric wants to get reports of instantaneous fill level rather than average; Alan said the collection of measures should allow this to be determined. Steve Casner raised a few issues regarding the completeness of the draft and the merging of the VoIP metrics with the other sections. The VoIP metrics include a measure of round trip time, but as specified, this is only possible if data is being transmitted in both directions. The draft needs to explain that, or to explain what to do if that's not the case. The VoIP section could refer to the the non-sender RTT measurement method in Section 4.5, but it doesn't. The draft needs an applicability statement at the top to explain which of the tools in this toolbox should be used in which situations, and how they would be used. The draft should be careful to avoid unstated assumptions about the use cases. Another problem is that Section 4.7 gives rules for how often the VoIP metric blocks must be sent. This draft is not allowed to say that. The RTP spec defines the basic RTCP packet timing, and the RTCP Feedback profile defines alternate timing under a more restrictive use case. This draft could refer to use under the RTCP Feedback profile, but it can't specify timing of its own. Alan responded that this would be done, and commented that in some cases the more useful information in the VoIP report block would allow less frequent reporting, saving bandwidth. Steve agreed that it would be good to add a sentence pointing this out because the increased in RTCP packet size caused by the inclusion of the VoIP metrics will mean that the interval between RTCP packets is increased. A more complicated issue raised by Magnus Westerlund is that the draft should specify SDP signaling for its use. This is a valid request, but might introduce too much delay in completing the draft. Colin Perkins pointed out the need to update the document quickly in order to meet a May deadline for consideration by ITU H.460.9. The specification of SDP signaling could be a separate draft, but it appears feasible to include a specification of SDP for point-to-point applications and leave more complicated scenarios for a separate draft. RTCP Extensions for SSM with unicast feedback Julian Chesterfield discussed updates in draft-ietf-avt-rtcpssm-03 which introduces some additional summary statistics, some clarifications and examples of security requirements and how the security methods should be used for RTSP and SIP sessions, and updates to the IANA considerations. The new summary sub-blocks are IPv6 feedback address, BYE list, and RTCP receiver bandwidth. This revision is now aligned with the RTCP XR format that Timur just presented, as was suggested in a previous AVT meeting. Steve Casner clarified that the reason for the suggestion was not to save an RTCP packet type code point, rather to ask if the same reporting mechanisms could be shared for both purposes rather than defining different ones. If there is no feasible merging of functionality, then there is not a requirement to fit the SSM reports into the XR block structure with extra overhead. The authors will reconsider this issue. Some open issues remain for the draft: clarification that the sender must forward a group size report whenever the size changes to allow correct operation of RTP timer reconsideration rules; reporting in the summary what the data corresponds to in terms of sample group size and receiver report age; and the alignment with XR. The authors would like to know whether there are any other implementations of this draft, and whether it will be considered ready for WG last call when these open issues have been addressed. Timur Friedman suggests using XR block type 8 rather than 10. John Lazzaro asked about summarization of the "extended highest sequence number" field from RTCP reports. MWPP uses this value; he would want the summary to be the minimum value reported by receivers. He will think about the details and make a suggestion. Steve Casner asked how the summarization methods in this draft compare with the summarization methods in the XR draft. Eve Schooler responded that the nature of the summary methods in the two drafts is different. The XR draft reports sampling of data, while SSM reports mathematical distributions. The authors of both drafts agreed to meet after the session to discuss this in more detail. Steve commented that the reason for raising the point was that if there is no common applicability of the two methods, then binding them together does not make sense. RTP Payload Format for JVT Video Stephan Wenger discussed draft-ietf-avt-rtp-h264-01. The spec for the JVT codec itself was finalized in a meeting the previous week with acceptance for ISO FDIS status and with "Consent" in the ITU-T due on March 28, so it is now time to finalize the packetization here and Stephan hopes to accelerate the process. A -02 revision is to be produced shortly, and perhaps one more revision if there are comments. The hope is to go to WG last call before the next meeting. There were many editorial changes from -00, plus a few technical additions. Fragmentation was added, but needs more description and an example. A "decoding order number" was added to facilitate some special handling of the packets without needing to decode the bitstream, but the description in this revision is inadequate. A section was added on MIME registration and SDP usage, but this may also need refinement. The main issue for this payload format is interoperability with the MPEG-4 Simple payload format. A new informational draft will be written to describe how this interoperation may be done. Colin Perkins asked whether interoperation with RFC 3016 is possible and there is any pressure for this. Stephan replied that he thought not, but will investigate for the interop draft. As the h264-01 draft now stands, it is possible to transmit a subset of JVT in MPEG-4 Simple access unit fragments, although the utility of this is not clear. It was also agreed at the JVT meeting to add a new form of STAP to allow more useful interoperation. But it has also been suggested that this payload format should re-model the interleaving of MPEG-4 Simple and that the STAP/MTAP syntax should be aligned with MPEG-4 Simple. This would achieve syntactic alignment allowing some re-use of code, but there would be a huge semantic difference. Dave Singer expressed the position that this draft should be made the best it can be for H.264 first, and then consider interop. The only solid requirement for interop is that it must be possible for a video stream using this payload format to be part of an MPEG-4 presentation. That is already possible. It was agreed not to introduce mythical similarities. At the previous AVT meeting, Stephan was resisting the addition of media-unaware fragmentation, but has added it in this revision because it may be necessary to transport a NALU of size greater than 64KB which is the most that IPv4 fragmentation can handle. In addition, in there may be content pre-recorded with a NALU size that does not fit the MTU size of a delivery network. Doing the fragmentation at the application layer allows application of tools such as RFC 2733 FEC for better protection efficiency. The security section of the document needs to be expanded beyond the minimal text in -01. The main issue is the vulnerability of Parameter Sets when transmitted in-band. This is addressed in the codec spec, and Colin Perkins said a normative reference could be made to that. Steve Casner asked why the in-band transmission of Parameter Sets should be allowed at all, given that the draft says it is a bad idea. Stephan replied that it is necessary in some scenarios involving gateways. Philippe Gentric expressed serious concern that if this practice is allowed then people will use it when it shouldn't be used, and it will cause endless headaches similar to those already seen with RFC 3016. Stephan said the draft will say SHOULD NOT to discourage its use. The codec spec also includes the means to transmit data of unknown type that may or may not be active information, for example a set-top box software update that could contain a virus. Stephan asks for help on security language to address this problem. Another open issue is video conferencing support. Stephan would like to specify MIME codepoints for levels of operation beyond those included in the codec spec, e.g. 704x576 images at 7.5 fps. Colin asked whether these modes will be added in future revisions of the codec spec, which would result in two ways to specify the same mode. Stephan said no. There is also a question whether this payload format is the right place to specify whether the response to a request for a full intraframe is mandatory. It was agreed that this payload format cannot specify that because it is subject to congestion control. Colin said this topic will be discussed separately in come combination of AVT and MMUSIC. The last open issue is regarding timestamps for Field mode, where there may be separate sampling instants for the two fields of a picture. Discussion requires detailed knowledge of H.264, so was deferred. RTP Payload Format for uncompressed video Ladan Gharai reviewed the modifications, additions, and remaining open issues for draft-ietf-avt-uncomp-video-02. The payload header now extends the sequence number in the RTP header to 32 bits to accommodate high data rates. Additional color codings for 4:1:1 and 4:2:0 interlaced and progressive were added, and separate timestamps are specified on interlaced fields to accommodate reversing 3:2 pulldown (an issue that was raised at the previous meeting). The draft now specifies required and optional SDP parameters (rate, pgroup, color-mode, etc.) and covers congestion control in Security Considerations (a serious issue for very high data rates). There are some open issues. At the previous IETF it was suggested that a planar video mode be added to the draft, i.e., sending Y, Cb and Cr planes separately. This requires a 2-bit field, which could be stolen from the length field, to indicate which plane. The main concern is that a substantial portion of the draft related to pgroups and color subsampling would be irrelevant to this mode. Does it make sense to combine these disparate modes in one draft? Stephan Wenger recommended keeping them separate. Two bits may not be enough since there are some color models with more than 4 planes, and the plane numbering would need to be specified for all these models. He also felt this would not be used because display systems are built to receive data in that form. Philippe Gentric countered that systems doing processing, rather than display, do operate on the planes separately, and since they operate at gigabit rates, saving memory shuffling is important. However, after some study he concluded that the implementations differ so much that a single format won't help. It was agreed to drop planar mode. On the other hand, the group felt it was worthwhile to keep the detailed listing of pgroup values rather than just the text explaining the rules for determining the values. Ladan asked if anyone has additional color subsampling or colorimetry values that should be included in the draft. Stephan Wenger said he had several that he would discuss after the meeting. Steve Casner said the draft needs to specify the means for defining and registering new values after the draft is published. The last question was whether there should be a means to independently represent SMPTE timecodes, or are the RTP and RTCP SP timestamps sufficient. Dave Singer said the SMPTE timecodes are required for some video applications because they can have gaps in edited programs, but it is orthogonal to the data format of the video. Colin Perkins asked whether the NPT mapping in RTSP solves this problem or whether some means is needed in the payload format. Philippe Gentric said this is really needed for studio work, and recommended that there be a separate payload format defined for carrying just the SMPTE timecodes that could then be synchronized with RTP mechanisms to any payload format. Colin recalled a proposal for that a couple of years ago, and suggested that we resurrect it. Stephan advised we need input on real usage cases in order to produce anything useful. John Lazzaro said that MIDI timecodes are SMPTE timecodes encoded in MIDI, and MWPP provides a means to transport these with resiliency. This would be a solution, perhaps a gross one. RTP Payload Format for a 64 kbit/s transparent call The second session started with a discussion of the RTP Payload format for 64 kbps transparent calls (draft-kreuter-avt-rtp-clearmode-02.txt) by Ruediger Kreuter. This draft describes a single 64kbps clearmode connection, and MIME type registration. It is distinct from Nx64kbps transport (draft-vainshtein-cesopsn-XX.txt) work which is done in the PWE3 working group. The MIME type "audio/clearmode" is registered. Ruediger asked if this is appropriate? Flemming Andreason said yes, using "audio" as the MIME type makes things easier in SDP since it can be included in the same media stream as other codecs. Ruediger also noted that the ITU use "audio" for this, as do existing products, so that helps compatibility. Ruediger noted that Magnus Westerlund sent a number of comments on the draft. Due to these he will include the "maxptime" parameter, and an explanation of the mapping from MIME parameters to SDP parameters. The chairs asked if there were objections to making this a work item? None were raised, so the next version will be submitted as an AVT work item, subject to area director approval. Colin Perkins noted that it is necessary to avoid overlap with work in PWE3 (i.e. limit this to a single 64kbps channel) if we are to accept it as a work item. The MIDI Wire Protocol Packetization (MWPP) John Lazzaro discussed MWPP (draft-ietf-avt-mwpp-midi-rtp-06.txt) and coding guidelines (draft-lazzaro-avt-mwpp-coding-guidelines-02.txt). He noted that he has been in discussion with the MMA and AMEI (the MIDI manufacturers associations for the US and Japan), and is incorporating their feedback as appropriate. He also noted that IEEE P1639 has related work, solving the problem at layer 2, and outlined differences between the two approaches. John noted that equipment today uses MIDI cables, asynchronous serial cables, which do not use timestamps. Instead, the timing of the signal on the wire denoted the media timing. People want pseudo-wire emulation in RTP, so they can use the precise packet times when operating on a LAN or other low-jitter environment. Wants a parameter to indicate that the sender is "precision", so the last command in the packet indicates the sending time. The other issue is synchronization between direct digital audio output and synth MIDI output. Options are to use an external clock sync, and slave everything to it, or to specify packet buffer latency and use manual calibration. There was much discussion around this subject between John, Magnus Westerlund, Steve Casner and Colin Perkins. This leant towards the first option: somehow convey the mapping between RTP timestamp and an external sync clock, and use the external clock to determine when to playout the media. Steve Casner gave a reference to the BBN synchronization protocol (J. Escobar, C. Partridge and D. Deutsch, Flow Synchronization Protocol, IEEE/ACM Transactions on Networking, Volume 2, Number 2, April 1994), which is an example of this approach. Colin Perkins noted that RTSP has a similar signalling mechanism, to convey a mapping between RTP timestamps and a SMPTE timecode. John noted that MWPP may also be used with SIP, so a more general parameter may be useful, but is nervous about splitting this out into a separate document due to feature creep. It may be appropriate for the MWPP document to outline the form of the solution, but to leave the actual solution to a different document (since the solution to synchronizing playout from multiple sources is more general than MWPP). RTP Payload Format for ATRAC-X Matthew Romaine discussed draft-hatanaka-avt-rtp-atracx-01.txt, the RTP payload format for ATRAC-X. A number of questions were raised at the last meeting: ambiguity in the timestamp definition, concern that the reasoning behind the multiplexing was not convincing, the reason why RFC 2198 was not used for redundancy, and concern about possible decoding ambiguity when fragmentation is used. Since then, the timestamp and sample rate have been clarified, the redundant data framework has been modified, a new method of multi-channel data decomposition has been introduced, and the reasons for multiplexing have been solidified. The timestamp now corresponds to the presentation time in milliseconds and the sample rate must now be identical for all streams. Steve Casner asked why milliseconds are used for the presentation time rather than the sample clock rate? Will revisit. The RFC 2198 redundancy format has a lot of overhead, because of the payload headers, and its block length field (10 bits) is too short, so redundancy is included in the payload format. Multi-channel decomposition is now included, allowing rate adaptation at the sender, which can drop the less important channels based on feedback from the receiver, and allowing for multi-channel presentations to be split across multiple ATRAC-X streams if they use more channels than are supported by the codec. There was some confusion over the terminology, with Steve Casner and Colin Perkins asking questions for clarification whether the multiple streams are from one source, or multiple sources. The draft will be updated to clarify the distinction between ATRAC-X streams and RTP streams. Steve Casner expressed concern that the payload format is inflexible in the way streams are multiplexed: for example layered coding is typically implemented by layered data across several RTP sessions, but the payload format sends the multiple layers within a single RTP stream. It would be appropriate to consider scenarios other than unicast streaming to ensure the design is does not unduely constrain future applications. RTP Payload Format for iLBC Speech Alan Duric discussed iLBC speech (draft-ietf-avt-rtp-ilbc-01.txt and draft-ietf-avt-ilbc-codec-01.txt). Since the last meeting, the codec and payload format have been tested at the SIPit 12 interop event, with several interoperable implementations; a 20ms frame size mode has been introduced into the codec (with 4 blocks of 160 samples); and the PLC has been enhanced. The SDP now includes a "mode=" attribute to indicate if 20ms or 30ms frame sizes is preferred (the default, if the attribute is not present, is 30ms for backwards compatibility). Steve Casner asked if the frame size can be distinguished in-band? Not without breaking the backwards compatibility. Steve asked how the zero value - support both - is used? Not clear, maybe just list it as "reserved". Colin Perkins asked if the "a=ptime" attribute can be used instead? No due to ambiguity with 60ms packets (2x30ms or 3x20ms). The current open issue is VAD and comfort noise generation. No interest at present, so they plan to drop this. Steve Casner noted that comfort noise frames would need to be indicated in-band? Yes, this needs to be considered how they can be distinguished. May be possible to use the existing comfort noise payload format. See also http://www.iLBCfreeware.org/ for source code and more info. RTP Payload Format for the Speex Codec Greg Herlein was scheduled to discuss the Speex codec and payload format (draft-herlein-speex-rtp-profile-00.txt), but couldn't reach the meeting due to traffic disruption caused by anti-war protests in the city. Steve Casner briefly outlined the codec and payload format, and asked for any comments to be sent to the mailing list. RTP Payload Format for RGL Codec Michael Ramalho discussed the RGL codec (draft-ramalho-rgl-desc-01.txt) and payload format (draft-ramalho-rgl-rtpformat-01.txt). He started with a brief introduction to the codec, which provides lossless compression for G.711. The output of the RGL codec is variable rate. Arbitrary input can be compressed, and the output will be at most one octet larger than the input (and usually will be much smaller). The first octet of the compressed output will never match one of a set of reserved values (0x3e, 0x5e, 0x7e, 0x9e, 0xbe, 0xde and 0xfe). These reserved values are used in the payload format to indicate a particular bundled format: bundling of one, two or three RGL frames per packet is signalled by one of these reserved values, and a less efficient, but generic, format is signalled by another value, and allows an arbitrary number of frames per packet. Steve Casner asked if the codec is likely to switch between single- and multi-frame modes? It may be possible to distinguish the bundling at session setup time, to avoid the need for reserved byte codes (as is done by the EVRC payload format). Magnus Westerlund also noted that one can always distinguish the format using different RTP payload types, so it may not be necessary to use the reserved codes. Magnus Westerlund asked if the generic format, or something similar with a count of the number of frames in the packet, can be used in all cases? This is possible, but the overhead may be too large. Magnus noted that, if the type octet was removed, the size would be the same in almost all cases, and the format would be simpler. Steve Casner noted that this is rather complex, with several different formats. That is a detraction, that could be fixed using two payload types (one frame per packet; multiple frames per packet). Michael noted that it is desirable that the number of samples in the payload headers matches the "a=ptime" attribure in the SDP. Also, he noted that there is a missing parameter for a-law or u-law. More information is available at http://www.vovida.org/ RTP Payload Format for ETSI ES 202 050 DSR Qiaobing Xie discussed draft-xie-avt-dsr-es202050-00.txt, which is a new encoding scheme for distributed speech recognition. The draft uses exactly the same format as that used in the previous DSR payload format RFC-to-be, although the contents of the frame pairs, and the MIME type, are different. Accept as a work item? Yes, subject to area director approval. Steve Casner asked if this draft cannot be simplified more, being just a reference to the previous DSR payload format and registration of the new MIME type? Qiaobing wished to clarify a couple of points that were unclear in the previous draft, and so copied the text and added a diagram for explanation. Steve said it would be appropriate to insert the change into the other draft, as an RFC editor note, to ensure that both are clear. File format for EVRC/SMV vs QCP Steve Casner noted that there is a proposal to change the file format for the EVRC/SMV payload format (currently with the RFC Editor) to be that defined in draft-garudadri-qcp-00.txt. Steve asked for an "ego-free" evaluation of which format makes most sense, or if we should accept both formats? It was asked if the QCP file format has IPR associated with it, and if the implementations are independent. Randall Gellens replied, noting that he is still researching these issues and cannot give a definitive answer, but that he thinks the QCP implementations are independent and is not aware of any IPR on QCP. Randall also noted that he was unaware of the QCP format when working on the EVRC/SMV payload format. The QCP format has been in use for several years, by other applications, but the MIME type has not been registered. It may be necessary to register this, for use with QCELP for example, even if it is not used for the EVRC/SMV payload format. There may be implementations using this with EVRC/SMV though. It is unclear if the EVRC/SMV format is used as currently specified, but 3GPP-2 may be considering this. Steve Casner asked if we can get clarification from 3GPP-2 on their plans for the file format? We may be able to get a liaison statement from 3GPP-2, stating their needs? No decision was made, but it is hoped that input from 3GPP can help to resolve the issues. Other discussion Since there was time left at the end of the session - due to missing the Speex discussion - Steve Casner asked if there were any other topics that the group wished to discuss? It was asked if it is possible to add new items to the RTCP reporting extensions draft (e.g. for video quality assessment)? Not at this time, because that draft is complete and we don't wish to delay it. Extensions may be written as new drafts though. John Lazzaro asked when the AVT group might close, since the charter is open ended due to the addition of new payload formats? Steve noted that we have fairly broad license to work on payload formats, but need area director approval for other new work items. Colin Perkins noted that the current charter lists getting RTP to Draft Standard as the main goal of the group. This is now complete, so we should be considering future work items. Stephan Wenger asked if it is appropriate to consider moving existing payload formats to draft standard? Yes, or to historic if they are no longer useful. There was some discussion of how the H.263 format can move to draft standard. Magnus Westerlund noted that NAT boxes present a challenge. Should the AVT group work to define "symmetric RTP"? Steve replied that it should probably be defined in the control protcols that use RTP, since they may have differing interpretations of the term. Magnus noted that there is a lot of commonality between the protocols, so a separate draft may be warrented, and there is the issue of address binding? Something to be discussed offline. Colin Perkins noted that the group may also wish to consider mapping RTP onto DCCP as a future work item. Transport over PR-SCTP was suggested as another possible work item. These are long term goals, not something we should rush into, but something to consider as those other protocols are developed. - * - --==_Exmh_4543271920-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Apr 14 04:45:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28152 for ; Mon, 14 Apr 2003 04:45:33 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3E8r7n02814 for avt-archive@odin.ietf.org; Mon, 14 Apr 2003 04:53:07 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3E8qk802798; Mon, 14 Apr 2003 04:52:46 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3E8ps802769 for ; Mon, 14 Apr 2003 04:51:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28136 for ; Mon, 14 Apr 2003 04:43:51 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 194zbb-0000lc-00 for avt@ietf.org; Mon, 14 Apr 2003 04:46:23 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.wise.edt.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 194zbb-0000lZ-00 for avt@ietf.org; Mon, 14 Apr 2003 04:46:23 -0400 Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3E8kQI3017237; Mon, 14 Apr 2003 10:46:26 +0200 (MEST) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2VDN5J0B; Mon, 14 Apr 2003 10:46:26 +0200 Message-ID: <3E9A7565.8080903@era.ericsson.se> Date: Mon, 14 Apr 2003 10:46:29 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Colin Perkins CC: "'IETF AVT WG'" Subject: Re: [AVT] SDP signaling for RTCP XR format References: <200304121946.h3CJkDmI001607@purple.nge.isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, Back in the office, I have continued my work on updating the XR format text. Colin Perkins wrote: >We should certainly consider this, as one way of meeting the ITU deadline. >Before we go down this path, though, I'd like to see some discussion of the >use cases for RTCP XR packets: in which scenarios is the signalling needed? >If typical scenarios require signalling, then we have no choice but to move >forward with the SDP extensions and their integration with SIP/RTSP. On the >other hand, if signalling is only required in unusual cases, it is much >easier to separate into a new draft. > > > I have one use case for the SDP signaling. This is the 3GPP streaming service (PSS). There exist different releases which include different functionality and some of that functionality is optional. In Release 6 of PSS there is a proposal for bit-rate adaptation based on RTCP feedback and server decision. It is proposed that as a part of the adaptation functionality some of the XR blocks should be used. In this case it is very useful for a server to tell the client that it desires the client to send XR blocks and which. In that way the client avoids having to try to guess or infer that it shall send the XR blocks or not. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Apr 14 11:03:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08451 for ; Mon, 14 Apr 2003 11:03:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3EFAkW28913 for avt-archive@odin.ietf.org; Mon, 14 Apr 2003 11:10:46 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EFA5828819; Mon, 14 Apr 2003 11:10:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EF48827625 for ; Mon, 14 Apr 2003 11:04:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08215 for ; Mon, 14 Apr 2003 10:55:57 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1955Ph-0002kS-00 for avt@ietf.org; Mon, 14 Apr 2003 10:58:29 -0400 Received: from telchemy.com ([66.155.69.251]) by ietf-mx with esmtp (Exim 4.12) id 1955Ph-0002k5-00 for avt@ietf.org; Mon, 14 Apr 2003 10:58:29 -0400 Received: from TELWS104 [64.238.103.215] by telchemy.com with ESMTP (SMTPD32-7.14) id AC691D6D01BE; Mon, 14 Apr 2003 10:57:45 -0400 Reply-To: From: "Alan Clark" To: "'Magnus Westerlund'" , "'Colin Perkins'" Cc: "'IETF AVT WG'" Subject: RE: [AVT] SDP signaling for RTCP XR format Date: Mon, 14 Apr 2003 10:53:18 -0400 Message-ID: <007b01c30295$964e1c70$6801a8c0@telchemy.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <3E9A7565.8080903@era.ericsson.se> Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit My concern is that, whilst there may be some examples of scenarios which would benefit from SDP signalling, is the identification of all such scenarios and the discussion of their issues and ramifications for RTCP XR going to be an unbounded and indefinite discussion? Originally we agreed to put a simple SDP signalling definition in by way of example - this seems to have been extended into a more general discussion. Can we establish a firm goal for either completing the SDP text or deciding that the number of scenarios warrants a separate discussion/draft? Alan -----Original Message----- From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Magnus Westerlund Sent: Monday, April 14, 2003 4:46 AM To: Colin Perkins Cc: 'IETF AVT WG' Subject: Re: [AVT] SDP signaling for RTCP XR format Hi, Back in the office, I have continued my work on updating the XR format text. Colin Perkins wrote: >We should certainly consider this, as one way of meeting the ITU deadline. >Before we go down this path, though, I'd like to see some discussion of the >use cases for RTCP XR packets: in which scenarios is the signalling needed? >If typical scenarios require signalling, then we have no choice but to move >forward with the SDP extensions and their integration with SIP/RTSP. On the >other hand, if signalling is only required in unusual cases, it is much >easier to separate into a new draft. > > > I have one use case for the SDP signaling. This is the 3GPP streaming service (PSS). There exist different releases which include different functionality and some of that functionality is optional. In Release 6 of PSS there is a proposal for bit-rate adaptation based on RTCP feedback and server decision. It is proposed that as a part of the adaptation functionality some of the XR blocks should be used. In this case it is very useful for a server to tell the client that it desires the client to send XR blocks and which. In that way the client avoids having to try to guess or infer that it shall send the XR blocks or not. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Apr 14 11:35:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09562 for ; Mon, 14 Apr 2003 11:35:08 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3EFgou31604 for avt-archive@odin.ietf.org; Mon, 14 Apr 2003 11:42:50 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EFgC831555; Mon, 14 Apr 2003 11:42:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EFf2831472 for ; Mon, 14 Apr 2003 11:41:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09452 for ; Mon, 14 Apr 2003 11:32:50 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1955zO-00030K-00 for avt@ietf.org; Mon, 14 Apr 2003 11:35:22 -0400 Received: from wireless252.east.isi.edu ([65.123.202.252] helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 1955zO-00030H-00 for avt@ietf.org; Mon, 14 Apr 2003 11:35:22 -0400 Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with ESMTP id h3EFZPOJ009897; Mon, 14 Apr 2003 11:35:25 -0400 (EDT) (envelope-from csp@purple.nge.isi.edu) Message-Id: <200304141535.h3EFZPOJ009897@purple.nge.isi.edu> To: alan@telchemy.com cc: "'Magnus Westerlund'" , "'IETF AVT WG'" Subject: Re: [AVT] SDP signaling for RTCP XR format In-Reply-To: Your message of "Mon, 14 Apr 2003 10:53:18 EDT." <007b01c30295$964e1c70$6801a8c0@telchemy.com> Date: Mon, 14 Apr 2003 11:35:25 -0400 From: Colin Perkins Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Alan, I'm not so concerned about the number of scenarios, but rather those that we expect to be commonly used. How do you expect RTCP XR to be used? Colin --> "Alan Clark" writes: > >My concern is that, whilst there may be some examples of scenarios which >would benefit from SDP signalling, is the identification of all such >scenarios and the discussion of their issues and ramifications for RTCP XR >going to be an unbounded and indefinite discussion? > >Originally we agreed to put a simple SDP signalling definition in by way of >example - this seems to have been extended into a more general discussion. > >Can we establish a firm goal for either completing the SDP text or deciding >that the number of scenarios warrants a separate discussion/draft? > >Alan > > >-----Original Message----- >From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Magnus >Westerlund >Sent: Monday, April 14, 2003 4:46 AM >To: Colin Perkins >Cc: 'IETF AVT WG' >Subject: Re: [AVT] SDP signaling for RTCP XR format > > >Hi, > >Back in the office, I have continued my work on updating the XR format >text. > >Colin Perkins wrote: > >>We should certainly consider this, as one way of meeting the ITU deadline. >>Before we go down this path, though, I'd like to see some discussion of the >>use cases for RTCP XR packets: in which scenarios is the signalling needed? >>If typical scenarios require signalling, then we have no choice but to move >>forward with the SDP extensions and their integration with SIP/RTSP. On the >>other hand, if signalling is only required in unusual cases, it is much >>easier to separate into a new draft. >> >> >> > >I have one use case for the SDP signaling. This is the 3GPP streaming > service (PSS). There exist different releases which include different >functionality and some of that functionality is optional. In Release 6 >of PSS there is a proposal for bit-rate adaptation based on RTCP >feedback and server decision. It is proposed that as a part of the >adaptation functionality some of the XR blocks should be used. In this >case it is very useful for a server to tell the client that it desires >the client to send XR blocks and which. In that way the client avoids >having to try to guess or infer that it shall send the XR blocks or not. > >Best Regards > >Magnus Westerlund > >Multimedia Technologies, Ericsson Research ERA/TVA/A >---------------------------------------------------------------------- >Ericsson AB | Phone +46 8 4048287 >Torshamsgatan 23 | Fax +46 8 7575550 >S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se > > > >_______________________________________________ >Audio/Video Transport Working Group >avt@ietf.org >https://www1.ietf.org/mailman/listinfo/avt > >_______________________________________________ >Audio/Video Transport Working Group >avt@ietf.org >https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Apr 14 12:03:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10336 for ; Mon, 14 Apr 2003 12:03:00 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3EGAg201647 for avt-archive@odin.ietf.org; Mon, 14 Apr 2003 12:10:42 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EGA1801589; Mon, 14 Apr 2003 12:10:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EG2s800331 for ; Mon, 14 Apr 2003 12:02:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10160 for ; Mon, 14 Apr 2003 11:54:42 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1956KY-00039v-00 for avt@ietf.org; Mon, 14 Apr 2003 11:57:15 -0400 Received: from telchemy.com ([66.155.69.251]) by ietf-mx with esmtp (Exim 4.12) id 1956KY-00039f-00 for avt@ietf.org; Mon, 14 Apr 2003 11:57:14 -0400 Received: from TELWS104 [64.238.103.215] by telchemy.com with ESMTP (SMTPD32-7.14) id AA3966A01D4; Mon, 14 Apr 2003 11:56:41 -0400 Reply-To: From: "Alan Clark" To: "'Colin Perkins'" Cc: "'Magnus Westerlund'" , "'IETF AVT WG'" Subject: RE: [AVT] SDP signaling for RTCP XR format Date: Mon, 14 Apr 2003 11:52:14 -0400 Message-ID: <008a01c3029d$d256c9d0$6801a8c0@telchemy.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <200304141535.h3EFZPOJ009897@purple.nge.isi.edu> Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Colin I expect that one of the major uses of RTCP XR would be to support the fault and performance management of IP phones, addressing both enterprise and carrier applications, and potentially residential gateways that support VoIP. There is a strong need within the industry for a low cost means of monitoring user perceived quality - this can be very economically implemented using RTCP XR. There are specific cases, for example IP Centrex, where the absence of an RTCP XR-like protocol is severely impacting the ability of service providers to detect problems that affect user perceived quality and hence is affecting the speed with which these services are deployed. I certainly don't regard RTCP XR as a research or experimental tool, but as a protocol that has some very real and immediate applications that will help to speed deployment of VoIP. I am also the editor for several emerging TIA standards related to VoIP CPE management and have already introduced the RTCP XR draft to the group as forming a good basis for our work. Regards Alan Clark -----Original Message----- From: Colin Perkins [mailto:csp@csperkins.org] Sent: Monday, April 14, 2003 11:35 AM To: alan@telchemy.com Cc: 'Magnus Westerlund'; 'IETF AVT WG' Subject: Re: [AVT] SDP signaling for RTCP XR format Alan, I'm not so concerned about the number of scenarios, but rather those that we expect to be commonly used. How do you expect RTCP XR to be used? Colin --> "Alan Clark" writes: > >My concern is that, whilst there may be some examples of scenarios which >would benefit from SDP signalling, is the identification of all such >scenarios and the discussion of their issues and ramifications for RTCP XR >going to be an unbounded and indefinite discussion? > >Originally we agreed to put a simple SDP signalling definition in by way of >example - this seems to have been extended into a more general discussion. > >Can we establish a firm goal for either completing the SDP text or deciding >that the number of scenarios warrants a separate discussion/draft? > >Alan > > >-----Original Message----- >From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Magnus >Westerlund >Sent: Monday, April 14, 2003 4:46 AM >To: Colin Perkins >Cc: 'IETF AVT WG' >Subject: Re: [AVT] SDP signaling for RTCP XR format > > >Hi, > >Back in the office, I have continued my work on updating the XR format >text. > >Colin Perkins wrote: > >>We should certainly consider this, as one way of meeting the ITU deadline. >>Before we go down this path, though, I'd like to see some discussion of the >>use cases for RTCP XR packets: in which scenarios is the signalling needed? >>If typical scenarios require signalling, then we have no choice but to move >>forward with the SDP extensions and their integration with SIP/RTSP. On the >>other hand, if signalling is only required in unusual cases, it is much >>easier to separate into a new draft. >> >> >> > >I have one use case for the SDP signaling. This is the 3GPP streaming > service (PSS). There exist different releases which include different >functionality and some of that functionality is optional. In Release 6 >of PSS there is a proposal for bit-rate adaptation based on RTCP >feedback and server decision. It is proposed that as a part of the >adaptation functionality some of the XR blocks should be used. In this >case it is very useful for a server to tell the client that it desires >the client to send XR blocks and which. In that way the client avoids >having to try to guess or infer that it shall send the XR blocks or not. > >Best Regards > >Magnus Westerlund > >Multimedia Technologies, Ericsson Research ERA/TVA/A >---------------------------------------------------------------------- >Ericsson AB | Phone +46 8 4048287 >Torshamsgatan 23 | Fax +46 8 7575550 >S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se > > > >_______________________________________________ >Audio/Video Transport Working Group >avt@ietf.org >https://www1.ietf.org/mailman/listinfo/avt > >_______________________________________________ >Audio/Video Transport Working Group >avt@ietf.org >https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Apr 14 12:03:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10358 for ; Mon, 14 Apr 2003 12:03:17 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3EGAxc01665 for avt-archive@odin.ietf.org; Mon, 14 Apr 2003 12:10:59 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EGA8801625; Mon, 14 Apr 2003 12:10:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EG4k800587 for ; Mon, 14 Apr 2003 12:04:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10208 for ; Mon, 14 Apr 2003 11:56:34 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1956MM-0003At-00 for avt@ietf.org; Mon, 14 Apr 2003 11:59:06 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.wise.edt.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 1956ML-0003Aq-00 for avt@ietf.org; Mon, 14 Apr 2003 11:59:05 -0400 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3EFxAI3011473 for ; Mon, 14 Apr 2003 17:59:10 +0200 (MEST) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2VAMJ7T0; Mon, 14 Apr 2003 17:58:32 +0200 Message-ID: <3E9ADA9F.3090406@era.ericsson.se> Date: Mon, 14 Apr 2003 17:58:23 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF AVT WG Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] RTCP XR updated SDP section. Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, Here is an updated text of the SDP signaling of the RTCP XR format. Please read and comment. I think that I have addressed the comments I received. I am sorry that I has taken this time but I have been ill. Best Regards Magnus. ---------------------------------- 5. SDP Signaling This section defines an SDP attribute that can be used for signaling in applications utilizing SDP [s3]. This is signaling is defined to be used with Offer-Answer [s1] and for applications using SDP to describe media and transport configurations, like in SAP [s4] and RTSP [s5]. There exist other potential signaling methods, which are not defined here. The XR blocks MAY be used without prior signaling. This is in line with other RTCP packet types and follows the normal rules as written in [7]. Reasons for this can be an application that requires that one or more XR block is always used. This may require the application to define this, if all implementations of this application must work in the same way. However for applications that is configured at session initiation, the use of some type of signaling is RECOMMENDED. If any future defined report block does not allow usage without signaling, so should be noted and motivated in its specification. If an application is using the SDP signaling defined here it needs to be done as defined below. It is the usage of SDP for signaling the are optional, not if one is going to follow it or not, if used. If SDP signaling is used in an environment where XR blocks are only implemented by some fraction of the participants, the one's not implementing the XR blocks will ignore the SDP attribute. 5.1 The SDP attribute This section defines one new SDP attribute "rtcp-xr" that can be used to signal the participants in a media session that it should utilize any specified XR block(s). This attribute can in the future be easily extended with new parameters to cover any new reporting formats. Friedman et al. Standards Track FORMFEED[Page 32] Internet-Draft RTCP XR 2 March 2003 The RTCP XR format's SDP attribute is defined below in ABNF [s2]. It is an session and media level attribute. When specified at session level it applies to all media blocks part of the session. Any media level specification MUST replace an session level specification, if present, for that media block. rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)] CRLF xr-format = pckt-loss-rle / dupp-rle / recv-ts / stat-sum / rcv-rtt / voip-stat / format-ext pckt-loss-rle = "rle-pckt" ["=" max-size] dupp-rle = "rle-dup" ["=" max-size] recv-ts = "recv-ts" ["=" max-size] stat-sum = "stat-sum" recv-rtt = "recv-rtt" "=" recv-rtt-mode [":" max-size] voip-stat = "voip-sum" max-size = 1*DIGIT ; Maximum block size in bytes recv-rtt-mode = "all" / "sender" format-ext = non-ws-string non-ws-string = 1*(%x21-FF) The "rtcp-xr" attribute contains zero, one or more XR block related parameter. Each parameter defines its own interpretation as this will depend on the XR block(s). The attribute is extensible so that any future XR block can define its own parameter(s). There may be XR blocks where an "rtcp-xr" parameter is not applicable. However, for any future defined formats the need of a parameter SHALL be evaluated. The defined "rtcp-xr" parameters belong to two categories. The first category, the unilateral parameters, corresponds to reporting blocks that simple reports on the RTP stream and related things. The second category, collaborative parameters, represents XR block(s) that requires more than one party to perform an action to accomplish the functionality, like the RTT measuring functionality for a RTP receiver. These collaborative functionalities MAY use two or more different XR blocks, that together provide the functionality. Friedman et al. Standards Track FORMFEED[Page 33] Internet-Draft RTCP XR 2 March 2003 For the unilateral category, this document defines the following parameters. The parameter names and their corresponding XR format is given in table 1. Parameter name XR format (Nr and Name) -------------------------- rle-pckt 1 Loss RLE Report Block rle-dup 2 Duplicate RLE Report Block recv-ts 3 Timestamp Report Block stat-sum 4 Statistics Summary Report Block voip-sum 7 VoIP Metrics Report Block Table 1. The unilateral parameters and their XR formats. The "rle-pckt", "rle-dup", and "recv-ts" parameters MAY specify an integer value. This value indicates the largest size the whole report block SHOULD have in bytes. This shall be seen as an indication that thinning shall be applied if necessary to meet the target size. Any functionality belongs to the collaborative category, if it consist of one initiator block, and one or more types of response blocks. The functionality SHOULD include signaling to indicate which receivers that are required to respond to the initiator block. The collaborative category, currently consist only of the RTT measuring for RTP receivers functionality, which uses the XR formats "Receiver Timestamp Report Block" (5) and "DLRR Report Block" (6). These two formats and their functionality is represented by the "recv-rtt" parameter. This parameter takes first a mode value and optionally a maximum size for the DLRR report block. The mode values: "all" indicates that both RTP senders and receivers MAY send DLRR blocks. "sender" indicates that only active RTP senders MAY send DLRR blocks, i.e. non RTP senders SHALL NOT send DLRR blocks. If a maximum size in bytes is included any sent DLRR block SHALL NOT exceed the given size. The DLRR block sender SHOULD report on different timestamp sources in a round robin fashion if not all sources can be reported on due to size limitations. Any XR-block not represented in the parameter list of the attribute SHALL NOT be sent. This is required so that bandwidth is not wasted and may be specially important for collaborative parameters, where a initiator block otherwise could trigger responses from all participants in a large multicast group. The "rtcp-xr" attributes parameter list MAY be empty. This is useful Friedman et al. Standards Track FORMFEED[Page 34] Internet-Draft RTCP XR 2 March 2003 in cases where one needs to signal that one understands the SDP signaling but do not want to use any of the XR functionality. One such example could be a SIP controlled session where one want to stop using all XR blocks and therefore remove all parameters in the re- invite's SDP. If one do not desire to use any XR blocks from the beginning it is RECOMMENDED that one does not include the "rtcp-xr" attribute at all. 5.2 Usage in Offer-Answer When having reporting blocks, it is in the interest of the sender of media, to request that the receiver sends reports on this media stream. However the interpretation will be dependent on any direction attribute. In the below definition, text applying for media stream with "sendrecv" attributes does also apply to media streams without any direction attribute. The definitions apply only for media streams with a unicast destination, unless otherwise noted. For media streams in offers with a "sendonly" or a "sendrecv" attribute the inclusion of "rtcp-xr" attributes with parameters belonging to the unilateral category, has the interpretation that the receiver of the offer SHOULD send the XR formats corresponding to the parameter to the sender of these streams. When doing the answer the answerer MAY include the "rtcp-xr" attribute with any unilateral parameter for media streams with the "sendrecv" attribute to request that the offerer SHOULD send the corresponding XR blocks from the offerer to the answerer. For media streams in offers with "recvonly" attribute the offerer MAY include any unilateral parameters, this declare its capability of sending the corresponding XR block. If the answerer includes a "rtcp-xr" attribute with an unilateral parameter the offerer SHOULD send the corresponding XR block. For media streams with multicast destinations the inclusion of an "rtcp-xr attribute with any unilateral parameters means that any media recipient SHOULD send the corresponding XR block(s). For an SDP offer with media streams containing the "rtcp-xr" attribute with an collaborative parameter, like "recv-rtt", the offerer declares itself capable of receiving the indicated initiator ("Receiver Timestamp Report Block") and send responses using the responder block ("DLRR Report Block"). This means that the offerer has offered a situation where: The answerer MAY send the indicated initiator and the offerer SHOULD send the response block(s) if an initiator is received. The sending of a response can be preveted, as the offerer may not belong to the group that has been declared by the parameter to be allowed to send. The response may also be prevented Friedman et al. Standards Track FORMFEED[Page 35] Internet-Draft RTCP XR 2 March 2003 by other factors, like congestion control or MTU. The Answerer MAY include a collaborative parameter, like "recv-rtt" in the answer, and thereby declare its capability to receive and respond according to the indicated functionality. If a collaborative functionality is declared by the Answerer the Offerer MAY send the initiator block to the Answerer and the Answerer SHOULD receive the initiator block and send the corresponding response block(s). For an SDP offer with media streams with multicast destinations containing the "rtcp-xr" attribute with an collaborative parameter, the parameter needs to indicate which participants that should respond to a received initiator. A SDP offerer according to above has the interpretation that the indicated participants SHOULD send a response if a initiator is received. A participant MAY send a initiator block. A participant not indicated to respond for a functionality SHALL NOT send any response. The answerer to a session with multicast destination SHALL NOT include any collaborative parameters in the response. If one receives an SDP offer and understands the "rtcp-xr" attribute but does not want to use any XR functionality or it does not apply in the answer, the answerer SHOULD include an "rtcp-xr" attribute without parameters. This allows a party to declare capability to understand the signaling, and not request any functionality. 5.3 Usage out-side of Offer/Answer This applies to the usage of SDP that is currently defined in SAP and RTSP where SDP is used to declare what applies for a multi-media presentation. This SDP applies to how a receiver of these media streams shall behave to receive the media and under what rules. Therefore the usage of the "rtcp-xr" format is simpler in this case then compared to offer/answer, however the functionality goal is the same. For media streams having the "rtcp-xr" attribute with any unilateral parameter, the receiver of this media stream SHOULD send the corresponding XR block. If the attribute contains a collaborative parameter, the participants indicated by the collaborative parameter SHOULD send the response blocks, if the functionalities initiator block is received. A session participant MAY send initiator block if the collaborative parameter indicates that any participants will send responses. When the "rtcp-xr" attribute is present no other XR blocks than the ones indicated by parameters to the attribute SHALL be used. This means that inclusion of a "rtcp-xr" attribute without any parameter, tells a participant that he SHALL NOT send any XR blocks at all. Friedman et al. Standards Track FORMFEED[Page 36] Internet-Draft RTCP XR 2 March 2003 6. IANA Considerations This document defines a new RTCP packet type, the extended report (XR) type, within the existing Internet Assigned Numbers Authority (IANA) registry of RTP RTCP Control Packet Types. This document also defines a new IANA registry: the registry of RTP XR Block Types. Within this new registry, this document defines an initial set of seven block types and describes how the remaining types are to be allocated. Further this document defines a new SDP attribute "a=rtcp-xr" to be registered, and for its parameters a IANA registry is defined. 6.1 XR Packet Type The IANA SHALL register the RTP extended report (XR) packet defined by this document as packet type 207 in the registry of RTP RTCP Control Packet types (PT). 6.2 RTP XR Block Type Registry The IANA SHALL create the RTP XR Block Type Registry to cover the name space of the extended report block type (BT) field specified in Section 3 of this document. The BT field contains eight bits, allowing 256 values. The IANA SHALL manage the RTP XR Block Type Registry according to the Specification Required policy of RFC 2434 [6]. Future specifications SHOULD attribute block type values in strict numeric order following the values attributed in this document: BT name -- ---- 1 Loss RLE Report Block 2 Duplicate RLE Report Block 3 Timestamp Report Block 4 Statistics Summary Report Block 5 Receiver Timestamp Report Block 6 DLRR Report Block 7 VoIP Metrics Report Block The BT value 255 is reserved for future extensions. Furthermore, future specifications SHOULD avoid the value 0. Doing so facilitates packet validity checking, since an all-zeros field might commonly be found in an ill-formed packet. 6.3 The "rtcp-xr" SDP attribute Friedman et al. Standards Track FORMFEED[Page 37] Internet-Draft RTCP XR 2 March 2003 One SDP attribute is to be registered using the below information: SDP Attribute ("att-field"): Attribute name: rtcp-xr Long form: RTP Extended Report Parameters Type of name: att-field Type of attribute: Session and Media level Subject to charset: No Purpose: See this document Reference: This document Values: See this document and registrations below The attribute has an extensible parameter field and therefore a registry for these parameters are needed. IANA is requested to create one "rtcp-xr" SDP parameter registry and register the defined values. This registry is managed according to the Specification Required policy of RFC 2434. Any registration MUST contain the following information: - Contact information of the one doing the registration, including at least name, address, and email. - An ABNF definition of the parameter, in accordance with the "format-ext" definition. - A description of what the parameter represents and how it shall be interpreted, both normally and in Offer/Answer. This document registers the six parameters defined in chapter 5.1, "rle-pckt", "rle-dup", "recv-ts", "stat-sum", "voip-sum", and "recv- rtt". -- Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Apr 14 12:05:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10457 for ; Mon, 14 Apr 2003 12:05:58 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3EGDfW01857 for avt-archive@odin.ietf.org; Mon, 14 Apr 2003 12:13:41 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EGD4801826; Mon, 14 Apr 2003 12:13:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EGCl801783 for ; Mon, 14 Apr 2003 12:12:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10424 for ; Mon, 14 Apr 2003 12:04:34 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1956U6-0003DL-00 for avt@ietf.org; Mon, 14 Apr 2003 12:07:06 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.wise.edt.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 1956U6-0003DF-00 for avt@ietf.org; Mon, 14 Apr 2003 12:07:06 -0400 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3EG78Rs026402; Mon, 14 Apr 2003 18:07:08 +0200 (MEST) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2VAMKAD9; Mon, 14 Apr 2003 18:07:04 +0200 Message-ID: <3E9ADC97.80406@era.ericsson.se> Date: Mon, 14 Apr 2003 18:06:47 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Colin Perkins CC: alan@telchemy.com, "'IETF AVT WG'" Subject: Re: [AVT] SDP signaling for RTCP XR format References: <200304141535.h3EFZPOJ009897@purple.nge.isi.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, When I wrote the SDP section I have considered the following use cases: - RTSP controlled streaming. - Mbone type lecture session with extra feedback. - SIP controlled conversational sessions. Two parties. Are there any more that we really need to consider? I would imagine that some more obscure cases may also very well work. The SIP case may be the weakest as I don't have practical experience of SIP/SDP. So I would really appreciate review by someone that has that background. Best Regards Magnus Colin Perkins wrote: >Alan, > >I'm not so concerned about the number of scenarios, but rather those that >we expect to be commonly used. How do you expect RTCP XR to be used? > >Colin > > > > -- Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Apr 15 16:38:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10955 for ; Tue, 15 Apr 2003 16:38:32 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3FKkmP02951 for avt-archive@odin.ietf.org; Tue, 15 Apr 2003 16:46:48 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FKkC802931; Tue, 15 Apr 2003 16:46:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FKht802819 for ; Tue, 15 Apr 2003 16:43:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10887 for ; Tue, 15 Apr 2003 16:35:09 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195XBT-0004SJ-00 for avt@ietf.org; Tue, 15 Apr 2003 16:37:39 -0400 Received: from ns.live.com ([66.80.62.34]) by ietf-mx with esmtp (Exim 4.12) id 195XBS-0004SG-00 for avt@ietf.org; Tue, 15 Apr 2003 16:37:38 -0400 Received: from ns.live.com (localhost.live.com [127.0.0.1]) by ns.live.com (8.12.9/8.12.5) with ESMTP id h3FKbc13098140; Tue, 15 Apr 2003 13:37:38 -0700 (PDT) (envelope-from rsf@ns.live.com) Received: (from rsf@localhost) by ns.live.com (8.12.9/8.12.3/Submit) id h3FKbamW098104; Tue, 15 Apr 2003 13:37:36 -0700 (PDT) Message-Id: <4.3.1.1.20030415132720.00cb6480@laptop-localhost> X-Sender: rsf@laptop-localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 15 Apr 2003 13:37:30 -0700 To: Julian.chesterfield@cl.cam.ac.uk, schooler@research.att.com, jo@tellique.com From: Ross Finlayson Cc: avt@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [AVT] Minor change needed to "draft-ietf-avt-rtcpssm" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Julian et al., As you know, section 10.2 of your "RTCP SSM" Internet Draft references the "SDP source filter" draft - the current version of which can be found at . Note that the syntax of SDP source filters has changed somewhat since you wrote section 10.2. So, please change both occurrences of a=incl: to a=source-filter: incl Ross. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Apr 16 23:13:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24973 for ; Wed, 16 Apr 2003 23:13:20 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3H3MFn15725 for avt-archive@odin.ietf.org; Wed, 16 Apr 2003 23:22:15 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3H3LY815702; Wed, 16 Apr 2003 23:21:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GF0M827330 for ; Wed, 16 Apr 2003 11:00:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04390 for ; Wed, 16 Apr 2003 10:51:11 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195oIA-0001yq-00 for avt@ietf.org; Wed, 16 Apr 2003 10:53:42 -0400 Received: from h-135-207-24-32.research.att.com ([135.207.24.32] helo=mailman.research.att.com) by ietf-mx with esmtp (Exim 4.12) id 195oIA-0001yd-00 for avt@ietf.org; Wed, 16 Apr 2003 10:53:42 -0400 Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mailman.research.att.com (8.12.8/8.12.8) with ESMTP id h3GEpbkd002936; Wed, 16 Apr 2003 10:51:37 -0400 Received: from research.att.com (pc-griffin.research.att.com [135.207.26.230]) by bigmail.research.att.com (8.11.6+Sun/8.11.6) with ESMTP id h3GErGV07257; Wed, 16 Apr 2003 10:53:16 -0400 (EDT) Message-ID: <3E9D6B64.8D902E4E@research.att.com> Date: Wed, 16 Apr 2003 10:40:36 -0400 From: Tim Griffin X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: avt@ietf.org, rmt@lbl.gov, mboned@network-services.uoregon.edu, rm@openmash.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] CFP: 11th IEEE International Conference on Network Protocols (ICNP'03) Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit CALL FOR PAPERS 11th IEEE International Conference on Network Protocols (ICNP'03) Atlanta, Georgia November 4-7, 2003 http://icnp03.cc.gatech.edu ICNP is a highly selective conference dealing with all aspects of communication protocols including design, specification, analysis, verification, implementation, and performance. The program consists of a full day of tutorials followed by a single three-day track of peer-reviewed papers, including a limited number of invited talks and panels. The web page will contain up-to-date information on the conference program and tutorials. High-quality papers dealing with any aspect of network protocols are solicited for submission to the conference. Topics of particular interest include, but are not limited to: protocol testing and analysis protocol design and implementation network measurement and monitoring ad-hoc and sensor networks peer-to-peer/overlay protocols routing protocols wireless and mobile networks security multimedia distributed gaming QoS signaling flow and congestion control active/programmable networks IMPORTANT DATES: Register title, abstract and author affiliations: May 9, 2003 Paper submission (hard deadline): May 16, 2003 Acceptance: July 25, 2003 Camera ready: August 25, 2003 GENERAL CO-CHAIRS: Kevin Almeroth, UC Santa Barbara Ken Calvert, U. of Kentucky PROGRAM CO-CHAIRS: Jorg Liebeherr, U. of Virginia Ellen Zegura, Georgia Tech PROGRAM COMMITTEE: Kevin Almeroth, UC Santa Barbara Mostafa Ammar, Georgia Tech Paul Barford, U. of Wisconsin Bobby Bhattacharjee, U. of Maryland Ernst Biersack, Eurecom John Byers, Boston University Andrew Campbell, Columbia University Reuven Cohen, Technion John Crowcroft, U. of Cambridge Constantinos Dovrolis, Georgia Tech Wolfgang Effelsberg, U. of Mannheim Magda El Zarki, UC Irvine Michalis Faloutsos, UC Riverside Serge Fdida, U. of Pierre and Marie Curie Lixin Gao, U. of Massachusetts Timothy G. Griffin, AT&T Research Katie Guo, Bell Labs Teruo Higashino, Osaka University Sugih Jamin, U. of Michigan Ed Knightly, Rice University Jim Kurose, U. of Massachusetts Tom Laporta, Penn State University Brian Levine, U. of Massachusetts Steven Low, CalTech Ibrahim Matta, Boston University Sue Moon, Sprint ATL Klara Nahrstedt, U. of Illinois Venkat Padmanabhan, Microsoft Research Kihong Park, Purdue University Sanjoy Paul, Bell Labs Jennifer Rexford, AT&T Research Dan Rubenstein, Columbia University Srini Seshan, CMU R. Srikant, U. of Illinois Rolf Stadler, Royal Institute of Technology Ioannis Stavrakakis, University of Athens Peter Steenkiste, CMU Joe Touch, ISI Don Towsley, U. of Massachusetts Hassan Ural, U. of Ottawa Jim Xu, Georgia Tech David Yau, Purdue University _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Apr 16 23:15:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25088 for ; Wed, 16 Apr 2003 23:15:31 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3H3ORZ15860 for avt-archive@odin.ietf.org; Wed, 16 Apr 2003 23:24:27 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3H3Nf815793; Wed, 16 Apr 2003 23:23:41 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3H38u815278 for ; Wed, 16 Apr 2003 23:08:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24830 for ; Wed, 16 Apr 2003 22:59:30 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195zey-0004r4-00 for avt@ietf.org; Wed, 16 Apr 2003 23:02:00 -0400 Received: from isis.lip6.fr ([132.227.60.2] ident=root) by ietf-mx with esmtp (Exim 4.12) id 195zew-0004r1-00 for avt@ietf.org; Wed, 16 Apr 2003 23:01:58 -0400 Received: from tibre.lip6.fr (tibre.lip6.fr [132.227.74.2]) by isis.lip6.fr (8.12.9/jtpda-5.4+victor) with ESMTP id h3H31pqq002822 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) ; Thu, 17 Apr 2003 05:01:51 +0200 X-pt: isis.lip6.fr Received: from doris (doris [132.227.72.166]) by tibre.lip6.fr (8.11.6p2/8.11.6) with ESMTP id h3H31op04333; Thu, 17 Apr 2003 05:01:50 +0200 (CEST) From: Timur Friedman To: avt@ietf.org Date: Thu, 17 Apr 2003 05:01:48 +0200 User-Agent: KMail/1.4.3 Cc: "Kevin C. Almeroth" , Ramon Caceres , Alan Clark , Robert Cole , Nick Duffield , Kaynam Hedayat , Kamil Sarac , Magnus Westerlund , Colin Perkins , Stephen Casner MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="------------Boundary-00=_0FWG70E3FSRIR5YRS3YC" Message-Id: <200304170501.48235.timur.friedman@lip6.fr> X-Scanned-By: isis.lip6.fr Subject: [AVT] draft-ietf-avt-rtcp-report-extns-04.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --------------Boundary-00=_0FWG70E3FSRIR5YRS3YC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable AVT colleagues, We have just submitted version 4 of the RTP Control Protocol Extended Rep= orts=20 (RTCP XR) draft to Internet-Drafts@ietf.org (also attached here). At thi= s=20 point, as discussed in San Francisco, we hope to proceed to working group= =20 last call. Below is a list of changes from version 3. At the following URL is a PDF= =20 letter-format version of the draft: http://www-rp.lip6.fr/site_rp/_publications/378-draft-ietf-avt-rtcp-repor= t-extns-04.pdf Regards, Timur Friedman List of changes: * Addition of an applicability statement section. * Addition of an SDP signalling section. * Fixed a major item that was overlooked: the definition of the "SSRC of source" field was missing from the blocks that used this field. Also, the field was entirely missing from the VoIP Metrics Report Block, which ordinarily should use it. The length of the VoIP Metrics Report Block was adjusted accordingly. * Clarified the different roles performed by the report blocks that were known as the Timestamp Report Block and Receiver Timestamp Report Block. The names were too similar, and did not reflect the completely different roles played by the blocks. The blocks have been renamed the Packet Receipt Times Report Block and the Receiver Reference Time Report Block, respectively. Some explanatory text has been added, and in particular the RTP timestamp fields have been renamed Receipt time of packet, and their correspondence with RTP data packet timestamps discussed. * Reorganized the discussion of the block types to fall into three categories: detailed packet-by-packet reports, reference time reports, and statistical reports. To accomodate this categorization, the Statistics Summary Report Block was moved to accompany the VoIP Metrics Report Block. As the description of the Statistics Summary Report Block now follows that of the Packet Receipt Times Report Block and the Receiver Reference Time Report Block, these three have had their block type numbers changed so as to remain consecutive in the document. * Generalized the TTL reporting in the Statistics Summary Report Block to cover IPv6 Hop Limit values as well. This necessitated the introduction of a two bit flag, which is 0 if no values are reported, 1 if IPv4 TTL values are reported, and 2 if IPv6 Hop Limit values are reported. A flag value of 3 is undefined and disallowed. * Additional explanatory text has been provided in the Introduction, and to introduce the XR packet format. * Renamed the type-specific data field of the block framework to "type-specific block contents". Just to be clear that what might be considered metadata, such as SSRC values, can perfectly well go here. * For the VoIP Metrics Report Block, eliminated the following language: "An implementation that sends these blocks SHOULD send at least one every ten seconds for the duration of the call, SHOULD send one whenever a codec type change or other significant change occurs, SHOULD send one when significant call quality degradation is detected and SHOULD send one upon call termination." We cannot specify RTCP packet sending intervals that do not correspond with the underlying RTCP rules. --------------Boundary-00=_0FWG70E3FSRIR5YRS3YC Content-Type: text/plain; charset="us-ascii"; name="draft-ietf-avt-rtcp-report-extns-04.txt" Content-Disposition: attachment; filename="draft-ietf-avt-rtcp-report-extns-04.txt" Content-Transfer-Encoding: quoted-printable INTERNET-DRAFT 16 April 2003 Internet Engineering Task Force Expires: 16 October 2003 Audio/Video Transport Working Group Timur Friedman, Paris 6 Ramon Caceres, ShieldIP Alan Clark, Telchemy Editors RTP Control Protocol Extended Reports (RTCP XR) draft-ietf-avt-rtcp-report-extns-04.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document defines the Extended Report (XR) packet type for the RTP Control Protocol (RTCP), and defines how the use of XR packets can be signaled by an application if it employs the Session Description Protocol (SDP). XR packets are composed of report blocks, and seven block types are defined here. The purpose of the extended reporting format is to convey information that supplements the six statistics that are contained in the report blocks used by Friedman et al. Standards Track [Page 1] =0C Internet-Draft RTCP XR April 2003 RTCP's Sender Report (SR) and Receiver Report (RR) packets. Some applications, such as multicast inference of network characteristics (MINC) or voice over IP (VoIP) monitoring, require other and more detailed statistics. In addition to the block types defined here, additional block types may be defined in the future by adhering to the framework that this document provides. Table of Contents 1. Introduction .............................................. 3 1.1 Applicability ............................................. 4 1.2 Terminology ............................................... 6 2. XR Packet Format .......................................... 6 3. Extended Report Block Framework ........................... 8 4. Extended Report Blocks .................................... 9 4.1 Loss RLE Report Block ..................................... 9 4.1.1 Run Length Chunk .......................................... 15 4.1.2 Bit Vector Chunk .......................................... 15 4.1.3 Terminating Null Chunk .................................... 15 4.2 Duplicate RLE Report Block ................................ 16 4.3 Packet Receipt Times Report Block ......................... 17 4.4 Receiver Reference Time Report Block ...................... 20 4.5 DLRR Report Block ......................................... 21 4.6 Statistics Summary Report Block ........................... 22 4.7 VoIP Metrics Report Block ................................. 25 4.7.1 Packet Loss and Discard Metrics ........................... 26 4.7.2 Burst Metrics ............................................. 27 4.7.3 Delay Metrics ............................................. 29 4.7.4 Signal Related Metrics .................................... 30 4.7.5 Call Quality or Transmission Quality Metrics .............. 33 4.7.6 Configuration Parameters .................................. 34 4.7.7 Jitter Buffer Parameters .................................. 35 5. SDP Signaling ............................................. 36 5.1 The SDP Attribute ......................................... 36 5.2 Usage in Offer/Answer ..................................... 39 5.3 Usage Outside of Offer/Answer ............................. 40 6. IANA Considerations ....................................... 41 6.1 XR Packet Type ............................................ 41 6.2 RTCP XR Block Type Registry ............................... 41 6.3 The "rtcp-xr" SDP Attribute ............................... 42 7. Security Considerations ................................... 43 A. Algorithms ................................................ 44 A.1 Sequence Number Interpretation ............................ 44 A.2 Example Burst Packet Loss Calculation ..................... 45 Intellectual Property ..................................... 47 Full Copyright Statement .................................. 48 Acknowledgments ........................................... 48 Contributors .............................................. 48 Friedman et al. Standards Track [Page 2] =0C Internet-Draft RTCP XR April 2003 Authors' Addresses ........................................ 49 References ................................................ 51 Normative References ...................................... 51 Non-Normative References .................................. 52 1. Introduction This document defines the Extended Report (XR) packet type for the RTP Control Protocol (RTCP) [10], and defines how the use of XR packets can be signaled by an application if it employs the Session Description Protocol (SDP) [4]. XR packets convey information beyond that already contained in the reception report blocks of RTCP's sender report (SR) or Receiver Report (RR) packets. The information is of use across RTP profiles, and so is not appropriately carried in SR or RR profile-specific extensions. Information used for network management falls into this category, for instance. The definition is broken out over the three sections that follow the Introduction. Section 2 defines the XR packet as consisting of an eight octet header followed by a series of components called report blocks. Section 3 defines the common format, or framework, consisting of a type and a length field, required for all report blocks. Section 4 defines several specific report block types. Other block types can be defined in future documents as the need arises. The report block types defined in this document fall into three categories. The first category consists of packet-by-packet reports on received or lost RTP packets. Reports in the second category convey reference time information between RTP participants. In the third category, reports convey metrics relating to packet receipts, that are summary in nature but that are more detailed, or of a different type, than that conveyed in existing RTCP packets. All told, seven report block formats are defined by this document. Of these, three are packet-by-packet block types: - Loss RLE Report Block (Section 4.1): Run length encoding of reports concerning the losses and receipts of RTP packets. - Duplicate RLE Report Block (Section 4.2): Run length encoding of reports concerning duplicates of received RTP packets. - Packet Receipt Times Report Block (Section 4.3): A list of reception timestamps of RTP packets. There are two reference time related block types: Friedman et al. Standards Track [Page 3] =0C Internet-Draft RTCP XR April 2003 - Receiver Reference Time Report Block (Section 4.4): Receiver-end wallclock timestamps. Together with the DLRR Report Block mentioned next, these allow non-senders to calculate round-trip times. - DLRR Report Block (Section 4.5): The delay since the last Receiver Reference Time Report Block was received. An RTP data sender that receives a Receiver Reference Time Report Block can respond with a DLRR Report Block, in much the same way as, in the mechanism already defined for RTCP [10, Section 6.3.1], an RTP data receiver that receives a sender's NTP timestamp can respond by filling in the DLSR field of an RTCP reception report block. Finally, this document defines two summary metric block types: - Statistics Summary Report Block (Section 4.6): Statistics on RTP packet sequence numbers, losses, duplicates, jitter, and TTL or Hop Limit values. - VoIP Metrics Report Block (Section 4.7): Metrics for monitoring Voice over IP (VoIP) calls. Before proceeding to the XR packet and report block definitions, this document provides an applicability statement (Section 1.1) that describes the contexts in which these report blocks can be used. It also defines (Section 1.2) the normative use of key words, such as MUST and SHOULD, as they are employed in this document. Following the definitions of the various report blocks, this document describes how applications that employ SDP can signal their use (Section 5). The document concludes with a discussion (Section 6) of numbering considerations for the Internet Assigned Numbers Authority (IANA), of security considerations (Section 7), and with appendices that provide examples of how to implement algorithms discussed in the text. 1.1 Applicability The XR packets are useful across multiple applications, and for that reason are not defined as profile-specific extensions to RTCP sender or Receiver Reports [10, Section 6.4.3]. Nonetheless, they are not of use in all contexts. In particular, the VoIP metrics report block (Section 4.7) is specific to voice applications, though it can be employed over a wide variety of such applications. The VoIP metrics report block can be applied to any conversational, multicast or broadcast application for which the use of RTP and RTCP is specified. The use of conversational metrics (Section 4.7.5), including the R factor (as described by the E Model defined in [3]) Friedman et al. Standards Track [Page 4] =0C Internet-Draft RTCP XR April 2003 and the mean opinion score for conversational quality (MOS-CQ), in applications other than simple two party calls is not defined, and hence these metrics should be identified as unavailable in conferencing, multicast and broadcast applications. The packet-by-packet report block types, Loss RLE (Section 4.1), Duplicate RLE (Section 4.2), and Packet Receipt Times (Section 4.3), have been defined with network tomography applications, such as multicast inference of network characteristics (MINC) [11], in mind. MINC requires detailed packet receipt traces from multicast session receivers in order to infer the gross structure of the multicast distribution tree and the parameters, such as loss rates and delays, that apply to paths between the branching points of that tree. Any real time multicast multimedia application can use the packet-by- packet report block types. Such an application could employ a MINC inference subsystem that would provide it with multicast tree topology information. One potential use of such a subsystem would be for the identification of high loss regions in the multicast tree and the identification of multicast session participants well situated to provide retransmissions of lost packets. Detailed packet-by-packet reports do not necessarily have to consume disproportionate bandwidth with respect to other RTCP packets. An application can cap the size of these blocks. A mechanism called "thinning" is provided for these report blocks, and can be used to ensure that they adhere to a size limit by restricting the number of packets reported upon within any sequence number interval. The rationale for, and use of this mechanism is described in [13]. Furthermore, applications might not require report blocks from all receivers in order to answer such important questions as where in the multicast tree there are paths that exceed a defined loss rate threshold. Intelligent decisions regarding which receivers send these report blocks can further restrict the portion of RTCP bandwidth that they consume. The packet-by-packet report blocks can also be used by dedicated network monitoring applications. For such an application, it might be appropriate to allow more than 5% of RTP data bandwidth to be used for RTCP packets, thus allowing proportionately larger and more detailed report blocks. Nothing in the packet-by-packet block types restricts their use to multicast applications. In particular, they could be used for network tomography similar to MINC, but using striped unicast packets. In addition, if it were found useful, they could be used for applications limited to two participants. Friedman et al. Standards Track [Page 5] =0C Internet-Draft RTCP XR April 2003 One use to which the packet-by-packet reports are not immediately suited is for data packet acknowledgments as part of a packet retransmission mechanism. The reason is that the packet accounting technique suggested for these blocks differs from the packet accounting normally employed by RTP. In order to favor measurement applications, an effort is made to interpret as little as possible at the data receiver, and leave the interpretation as much as possible to participants that receive the report blocks. Thus, for example, a packet with an anomalous SSRC ID or an anomalous sequence number might be excluded by normal RTP accounting, but would be reported upon for network monitoring purposes. The Statistics Summary Report Block (Section 4.6) has also been defined with network monitoring in mind. This block type can be used equally well for reporting on unicast and multicast packet reception. The reference time related block types were conceived for receiver- based TCP-friendly multicast congestion control [17]. By allowing data receivers to calculate their round trip times to senders, they help the receivers estimate the downstream bandwidth they should request. Note that if every receiver is to send Receiver Reference Time Report Blocks (Section 4.4), a sender might potentially send a number of DLRR Report Blocks (Section 4.5) equal to the number of receivers whose RTCP packets have arrived at the sender within its reporting interval. As the number of participants in a multicast session increases, an application should use discretion regarding which participants send these blocks, and how frequently. The SDP signaling defined for XR packets in this document (Section 5) was done so with three use scenarios in mind: a Real Time Streaming Protocol (RTSP) controlled streaming application, a one-to-many multicast multimedia application such as a course lecture with enhanced feedback, and a Session Initiation Protocol (SIP) controlled conversational session involving two parties. Applications that employ SDP are free to use additional SDP signaling for cases not covered here. In addition, applications are free to use signaling mechanisms other than SDP. 1.2 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1] and indicate requirement levels for compliance with this specification. 2. XR Packet Format An XR packet consists of a header of two 32-bit words, followed by a Friedman et al. Standards Track [Page 6] =0C Internet-Draft RTCP XR April 2003 number, possibly zero, of extended report blocks. This type of packet is laid out in a manner consistent with other RTCP packets, as concerns the essential version, packet type, and length information. XR packets are thus backwards compatibility with RTCP receiver implementations that do not recognize them, but that ought to be able to parse past them using the length information. A padding field and an SSRC/CSRC field are also provided in the same locations that they appear in other RTCP packets, for simplicity. The format is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=3D2|P|reserved | PT=3DXR=3D207 | length = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC/CSRC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : report blocks : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ version (V): 2 bits Identifies the version of RTP. This specification applies to RTP version two. padding (P): 1 bit If the padding bit is set, this XR packet contains some additional padding octets at the end. The semantics of this field are identical to the semantics of the padding field in the SR packet, as defined by the RTP specification. reserved: 5 bits This field is reserved for future definition. In the absence of such definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver. packet type (PT): 8 bits Contains the constant 207 to identify this as an RTCP XR packet. This value is registered with the Internet Assigned Numbers Authority (IANA), as described in Section 5.1. length: 16 bits As described for the RTCP Sender Report (SR) packet (see Section 6.3.1 of the RTP specification [10]). Briefly, the length of this XR packet in 32-bit words minus one, including the header and any padding. Friedman et al. Standards Track [Page 7] =0C Internet-Draft RTCP XR April 2003 SSRC/CSRC: 32 bits The synchronization source identifier for the originator of this XR packet. report blocks: variable length. Zero or more extended report blocks. In keeping with the extended report block framework defined below, each block MUST consist of one or more 32-bit words. 3. Extended Report Block Framework Extended report blocks are stacked, one after the other, at the end of an XR packet. An individual block's length is a multiple of 4 octets. The XR header's length field describes the total length of the packet, including these extended report blocks. Each block has block type and length fields that facilitate parsing. A receiving application can demultiplex the blocks based upon their type, and can use the length information to locate each successive block, even in the presence of block types it does not recognize. An extended report block has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT | type-specific | block length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : type-specific block contents : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block type (BT): 8 bits Identifies the block format. Seven block types are defined in Section 4. Additional block types may be defined in future specifications. This field's name space is managed by the Internet Assigned Numbers Authority (IANA), as described in Section 5.2. type-specific: 8 bits The use of these bits is determined by the block type definition. block length: 16 bits The length of this report block including the header, in 32-bit words minus one. If the block type definition permits, zero is an acceptable value, signifying a block that consists of only Friedman et al. Standards Track [Page 8] =0C Internet-Draft RTCP XR April 2003 the BT, type-specific, and block length fields, with a null type-specific block contents field. type-specific block contents: variable length The use of this field is defined by the particular block type, subject to the constraint that it MUST be a multiple of 32 bits long. If the block type definition permits, It MAY be zero bits long. 4. Extended Report Blocks This section defines seven extended report blocks: block types for reporting upon received packet losses and duplicates, packet reception times, receiver reference time information, receiver inter- report delays, detailed reception statistics, and voice over IP (VoIP) metrics. An implementation SHOULD ignore incoming blocks with types either not relevant or unknown to it. Additional block types MUST be registered with the Internet Assigned Numbers Authority (IANA) [7], as described in Section 5.2. 4.1 Loss RLE Report Block This block type permits detailed reporting upon individual packet receipt and loss events. Such reports can be used, for example, for multicast inference of network characteristics (MINC) [11]. With MINC, one can discover the topology of the multicast tree used for distributing a source's RTP packets, and of the loss rates along links within that tree. Or they could be used to provide raw data to a network management application. Since a Boolean trace of lost and received RTP packets is potentially lengthy, this block type permits the trace to be compressed through run length encoding. To further reduce block size, loss event reports can be systematically dropped from the trace in a mechanism called thinning that is described below and that is studied in [13]. A participant that generates a Loss RLE Report Block should favor accuracy in reporting on observed events over interpretation of those events whenever possible. Interpretation should be left to those who observe the report blocks. Following this approach implies that accounting for Loss RLE Report Blocks will differ from the accounting for the generation of the SR and RR packets described in the RTP specification [10] in the following two areas: per-sender accounting and per-packet accounting. In its per-sender accounting, an RTP session participant SHOULD NOT make the receipt of a threshold minimum number of RTP packets a condition for reporting upon the sender of those packets. This Friedman et al. Standards Track [Page 9] =0C Internet-Draft RTCP XR April 2003 accounting technique differs from the technique described in Section 6.2.1 and Appendix A.1 of the RTP specification that allows a threshold to determine whether a sender is considered valid. In its per-packet accounting, an RTP session participant SHOULD treat all sequence numbers as valid. This accounting technique differs from the technique described in Appendix A.1 of the RTP specification that suggests ruling a sequence number valid or invalid on the basis of its contiguity with the sequence numbers of previously received packets. Sender validity and sequence number validity are interpretations of the raw data. Such interpretations are justified in the interest, for example, of excluding the stray old packet from an unrelated session from having an effect upon the calculation of the RTCP transmission interval. The presence of stray packets might, on the other hand, be of interest to a network monitoring application. One accounting interpretation that is still necessary is for a participant to decide whether the 16 bit sequence number has rolled over. Under ordinary circumstances this is not a difficult task. For example, if packet number 65,535 (the highest possible sequence number) is followed shortly by packet number 0, it is reasonable to assume that there has been a rollover. However it is possible that the packet is an earlier one (from 65,535 packets earlier). It is also possible that the sequence numbers have rolled over multiple times, either forward or backward. The interpretation becomes more difficult when there are large gaps between the sequence numbers, even accounting for rollover, and when there are long intervals between received packets. The per-packet accounting technique mandated here is for a participant to keep track of the sequence number of the packet most recently received from a sender. For the next packet that arrives from that sender, the sequence number MUST be judged to fall no more than 32,768 packets ahead or behind the most recent one, whichever choice places it closer. In the event that both choices are equally distant (only possible when the distance is 32,768), the choice MUST be the one that does not require a rollover. Appendix A.1 presents an algorithm that implements this technique. Each block reports on a single RTP data packet source, identified by its SSRC. The receiver that is supplying the report is identified in the header of the RTCP packet. Choice of beginning and ending RTP packet sequence numbers for the trace is left to the application. These values are reported in the block. The last sequence number in the trace MAY differ from the Friedman et al. Standards Track [Page 10] =0C Internet-Draft RTCP XR April 2003 sequence number reported on in any accompanying SR or RR report. Note that because of sequence number wraparound the ending sequence number MAY be less than the beginning sequence number. A Loss RLE Report Block MUST NOT be used to report upon a range of 65,534 or greater in the sequence number space, as there is no means to identify multiple wraparounds. The trace described by a Loss RLE report consists of a sequence of Boolean values, one for each sequence number of the trace. A value of one represents a packet receipt, meaning that one or more packets having that sequence number have been received since the most recent wraparound of sequence numbers (or since the beginning of the RTP session if no wraparound has been judged to have occurred). A value of zero represents a packet loss, meaning that there has been no packet receipt for that sequence number as of the time of the report. If a packet with a given sequence number is received after a report of a loss for that sequence number, a later Loss RLE report MAY report a packet receipt for that sequence number. The encoding itself consists of a series of 16 bit units called chunks that describe sequences of packet receipts or losses in the trace. Each chunk either specifies a run length or a bit vector, or is a null chunk. A run length describes between 1 and 16,383 events that are all the same (either all receipts or all losses). A bit vector describes 15 events that may be mixed receipts and losses. A null chunk describes no events, and is used to round out the block to a 32 bit word boundary. The mapping from a sequence of lost and received packets into a sequence of chunks is not necessarily unique. For example, the following trace covers 45 packets, of which the 22nd and 24th have been lost and the others received: 1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1111 1 One way to encode this would be: bit vector 1111 1111 1111 111 bit vector 1111 1101 0111 111 bit vector 1111 1111 1111 111 null chunk Another way to encode this would be: Friedman et al. Standards Track [Page 11] =0C Internet-Draft RTCP XR April 2003 run of 21 receipts bit vector 0101 1111 1111 111 run of 9 receipts null chunk The choice of encoding is left to the application. As part of this freedom of choice, applications MAY terminate a series of run length and bit vector chunks with a bit vector chunk that runs beyond the sequence number space described by the report block. For example, if the 44th packet in the same sequence were lost: 1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1110 1 This could be encoded as: run of 21 receipts bit vector 0101 1111 1111 111 bit vector 1111 1110 1000 000 null chunk In this example, the last five bits of the second bit vector describe a part of the sequence number space that extends beyond the last sequence number in the trace. These bits have been set to zero. All bits in a bit vector chunk that describe a part of the sequence number space that extends beyond the last sequence number in the trace MUST be set to zero, and MUST be ignored by the receiver. A null packet MUST appear at the end of a Loss RLE Report Block if the number of run length plus bit vector chunks is odd. The null chunk MUST NOT appear in any other context. Caution should be used in sending Loss RLE Report Blocks because, even with the compression provided by run length encoding, they can easily consume bandwidth out of proportion with normal RTCP packets. The block type includes a mechanism, called thinning, that allows an application to limit report sizes. A thinning value, T, selects a subset of packets within the sequence number space: those with sequence numbers that are multiples of 2^T. Packet reception and loss reports apply only to those packets. T can vary between 0 and 15. If T is zero then every packet in the sequence number space is reported upon. If T is fifteen then one in Friedman et al. Standards Track [Page 12] =0C Internet-Draft RTCP XR April 2003 every 32,768 packets is reported upon. Suppose that the trace just described begins at sequence number 13,821. The last sequence number in the trace is 13,865. If the trace were to be thinned with a thinning value of T=3D2, then the following sequence numbers would be reported upon: 13,824, 13,828, 13,832, 13,836, 13,840, 13,844, 13,848, 13,852, 13,856, 13,860, 13,864. The thinned trace would be as follows: 1 1 1 1 1 0 1 1 1 1 0 This could be encoded as follows: bit vector 1111 1011 1100 000 null chunk The last four bits in the bit vector, representing sequence numbers 13,868, 13,872, 13,876, and 13,880, extend beyond the trace and are thus set to zero and are ignored by the receiver. With thinning, the loss of the 22nd packet goes unreported because its sequence number, 13,842, is not a multiple of four. Packet receipts for all sequence numbers that are not multiples of four also go unreported. However, in this example thinning has permitted the Loss RLE Report Block to be shortened by one 32 bit word. Choice of the thinning value is left to the application. The Loss RLE Report Block has the following format: Friedman et al. Standards Track [Page 13] =0C Internet-Draft RTCP XR April 2003 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=3D1 | rsvd. | T | block length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | begin_seq | end_seq | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | chunk 1 | chunk 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | chunk n-1 | chunk n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block type (BT): 8 bits A Loss RLE Report Block is identified by the constant 1. rsvd.: 4 bits This field is reserved for future definition. In the absence of such definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver. thinning (T): 4 bits The amount of thinning performed on the sequence number space. Only those packets with sequence numbers 0 mod 2^T are reported on by this block. A value of 0 indicates that there is no thinning, and all packets are reported on. The maximum thinning is one packet in every 32,768 (amounting to two packets within each 16-bit sequence space). block length: 16 bits Defined in Section 3. SSRC of source: 32 bits The SSRC of the RTP data packet source being reported upon by this report block. begin_seq: 16 bits The first sequence number that this block reports on. end_seq: 16 bits The last sequence number that this block reports on plus one. chunk i: 16 bits There are three chunk types: run length, bit vector, and Friedman et al. Standards Track [Page 14] =0C Internet-Draft RTCP XR April 2003 terminating null, defined in the following sections. If the chunk is all zeroes then it is a terminating null chunk. Otherwise, the leftmost bit of the chunk determines its type: 0 for run length and 1 for bit vector. 4.1.1 Run Length Chunk 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C|R| run length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ chunk type (C): 1 bit A zero identifies this as a run length chunk. run type (R): 1 bit Zero indicates a run of 0s. One indicates a run of 1s. run length: 14 bits A value between 1 and 16,383. The value MUST not be zero for a run length chunk (zeroes in both the run type and run length fields would make the chunk a terminating null chunk). Run lengths of 15 or less MAY be described with a run length chunk despite the fact that they could also be described as part of a bit vector chunk. 4.1.2 Bit Vector Chunk 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C| bit vector | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ chunk type (C): 1 bit A one identifies this as a bit vector chunk. bit vector: 15 bits The vector is read from left to right, in order of increasing sequence number (with the appropriate allowance for wraparound). 4.1.3 Terminating Null Chunk Friedman et al. Standards Track [Page 15] =0C Internet-Draft RTCP XR April 2003 This chunk is all zeroes. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.2 Duplicate RLE Report Block This block type permits per-sequence-number reports on duplicates in a source's RTP packet stream. Such information can be used for network diagnosis, and provide an alternative to packet losses as a basis for multicast tree topology inference. The Duplicate RLE Report Block format is identical to the Loss RLE Report Block format. Only the interpretation is different, in that the information concerns packet duplicates rather than packet losses. The trace to be encoded in this case also consists of zeros and ones, but a zero here indicates the presence of duplicate packets for a given sequence number, whereas a one indicates that no duplicates were received. The existence of a duplicate for a given sequence number is determined over the entire reporting period. For example, if packet number 12,593 arrives, followed by other packets with other sequence numbers, the arrival later in the reporting period of another packet numbered 12,593 counts as a duplicate for that sequence number. The duplicate does not need to follow immediately upon the first packet of that number. Care must be taken that a report does not cover a range of 65,534 or greater in the sequence number space. No distinction is made between the existence of a single duplicate packet and multiple duplicate packets for a given sequence number. Note also that since there is no duplicate for a lost packet, a loss is encoded as a one in a Duplicate RLE Report Block. The Duplicate RLE Report Block has the following format: Friedman et al. Standards Track [Page 16] =0C Internet-Draft RTCP XR April 2003 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=3D2 | rsvd. | T | block length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | begin_seq | end_seq | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | chunk 1 | chunk 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | chunk n-1 | chunk n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block type (BT): 8 bits A Duplicate RLE Report Block is identified by the constant 2. rsvd.: 4 bits This field is reserved for future definition. In the absence of such definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver. thinning (T): 4 bits As defined in Section 4.1. block length: 16 bits Defined in Section 3. SSRC of source: 32 bits As defined in Section 4.1. begin_seq: 16 bits As defined in Section 4.1. end_seq: 16 bits As defined in Section 4.1. chunk i: 16 bits As defined in Section 4.1. 4.3 Packet Receipt Times Report Block This block type permits per-sequence-number reports on packet receipt times for a given source's RTP packet stream. Such information can be used for MINC inference of the topology of the multicast tree used Friedman et al. Standards Track [Page 17] =0C Internet-Draft RTCP XR April 2003 to distribute the source's RTP packets, and of the delays along the links within that tree. It can also be used to measure partial path characteristics and to model distributions for packet jitter. Packet receipt times are expressed in the same units as used in the RTP timestamps of data packets. This is so that, for each packet, one can establish both the send time and the receipt time in comparable terms. Note, however, that as an RTP sender ordinarily initializes its time to a value chosen at random, there can be no expectation that reported send and receipt times will differ by an amount equal to the one-way delay between sender and receiver. The reported times can nonetheless be useful for the purposes mentioned above. At least one packet MUST have been received for each sequence number reported upon in this block. If this block type is used to report receipt times for a series of sequence numbers that includes lost packets, several blocks are required. If duplicate packets have been received for a given sequence number, and those packets differ in their receipt times, any time other than the earliest MUST NOT be reported. This is to ensure consistency among reports. Times reported in RTP timestamp format consume more bits than loss or duplicate information, and do not lend themselves to run length encoding. The use of thinning is encouraged to limit the size of Packet Receipt Times Report Blocks. The Packet Receipt Times Report Block has the following format: Friedman et al. Standards Track [Page 18] =0C Internet-Draft RTCP XR April 2003 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=3D3 | rsvd. | T | block length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | begin_seq | end_seq | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receipt time of packet begin_seq | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receipt time of packet (begin_seq + 1) mod 65536 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receipt time of packet (end_seq - 1) mod 65536 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block type (BT): 8 bits A Packet Receipt Times Report Block is identified by the constant 3. rsvd.: 4 bits This field is reserved for future definition. In the absence of such definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver. thinning (T): 4 bits As defined in Section 4.1. block length: 16 bits Defined in Section 3. SSRC of source: 32 bits As defined in Section 4.1. begin_seq: 16 bits As defined in Section 4.1. end_seq: 16 bits As defined in Section 4.1. Receipt time of packet i: 32 bits The receipt time of the packet with sequence number i at the receiver. The modular arithmetic shown in the packet format diagram is to allow for sequence number rollover. It is preferable for the time value to be established at the link Friedman et al. Standards Track [Page 19] =0C Internet-Draft RTCP XR April 2003 layer interface, or in any case as close as possible to the wire arrival time. Units and format are the same as for the timestamp in RTP data packets. As opposed to RTP data packet timestamps, in which nominal values may be used instead of system clock values in order to convey information useful for periodic playout, the receipt times should reflect the actual time as closely as possible. For a session, if the RTP timestamp is chosen at random, the first receipt time value SHOULD also be chosen at random, and subsequent timestamps offset from this value. On the other hand, if the RTP timestamp is meant to reflect the reference time at the sender, then the receipt time SHOULD be as close as possible to the reference time at the receiver. 4.4 Receiver Reference Time Report Block This block extends RTCP's timestamp reporting so that non-senders may also send timestamps. It recapitulates the NTP timestamp fields from the RTCP Sender Report [10, Sec. 6.3.1]. A non-sender may estimate its round trip time (RTT) to other participants, as proposed in [17], by sending this report block and receiving DLRR Report Blocks (see next section) in reply. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=3D4 | reserved | block length =3D 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NTP timestamp, most significant word | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NTP timestamp, least significant word | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block type (BT): 8 bits A Receiver Reference Time Report Block is identified by the constant 4. reserved: 8 bits This field is reserved for future definition. In the absence of such definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver. block length: 16 bits The constant 2, in accordance with the definition of this field in Section 3. Friedman et al. Standards Track [Page 20] =0C Internet-Draft RTCP XR April 2003 NTP timestamp: 64 bits Indicates the wallclock time when this block was sent so that it may be used in combination with timestamps returned in DLRR Report Blocks (see next section) from other receivers to measure round-trip propagation to those receivers. Receivers should expect that the measurement accuracy of the timestamp may be limited to far less than the resolution of the NTP timestamp. The measurement uncertainty of the timestamp is not indicated as it may not be known. A report block sender that can keep track of elapsed time but has no notion of wallclock time may use the elapsed time since joining the session instead. This is assumed to be less than 68 years, so the high bit will be zero. It is permissible to use the sampling clock to estimate elapsed wallclock time. A report sender that has no notion of wallclock or elapsed time may set the NTP timestamp to zero. 4.5 DLRR Report Block This block extends RTCP's delay since last Sender Report (DLSR) mechanism [10, Sec. 6.3.1] so that non-senders may also calculate round trip times, as proposed in [17]. It is termed DLRR for delay since last Receiver Report, and may be sent in response to a Receiver Timestamp Report Block (see previous section) from a receiver to allow that receiver to calculate its round trip time to the respondent. The report consists of one or more 3 word sub-blocks: one sub-block per Receiver Report. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=3D5 | reserved | block length | +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D= +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ | SSRC_1 (SSRC of first receiver) | sub- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ bloc= k | last RR (LRR) | 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | delay since last RR (DLRR) | +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D= +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ | SSRC_2 (SSRC of second receiver) | sub- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ bloc= k : ... : 2 +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D= +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ block type (BT): 8 bits A DLRR Report Block is identified by the constant 5. Friedman et al. Standards Track [Page 21] =0C Internet-Draft RTCP XR April 2003 reserved: 8 bits This field is reserved for future definition. In the absence of such definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver. block length: 16 bits Defined in Section 3. last RR timestamp (LRR): 32 bits The middle 32 bits out of 64 in the NTP timestamp (as explained in the previous section) received as part of a Receiver Reference Time Report Block from participant SSRC_n. If no such block has been received, the field is set to zero. delay since last RR (DLRR): 32 bits The delay, expressed in units of 1/65536 seconds, between receiving the last Receiver Reference Time Report Block from participant SSRC_n and sending this DLRR Report Block. If no Receiver Reference Time Report Block has been received yet from SSRC_n, the DLRR field is set to zero (or the DLRR is omitted entirely). Let SSRC_r denote the receiver issuing this DLRR Report Block. Participant SSRC_n can compute the round-trip propagation delay to SSRC_r by recording the time A when this Receiver Timestamp Report Block is received. It calculates the total round-trip time A-LSR using the last SR timestamp (LSR) field, and then subtracting this field to leave the round-trip propagation delay as A-LSR-DLSR. This is illustrated in [10, Fig. 2]. 4.6 Statistics Summary Report Block This block reports statistics beyond the information carried in the standard RTCP packet format, but not as fine grained as that carried in the report blocks previously described. Information is recorded about lost packets, duplicate packets, jitter measurements, and TTL or Hop Limit values. Such information can be useful for network management. The report block contents are dependent upon a series of flags bit carried in the first part of the header. Not all parameters need to be reported in each block. Flags indicate which are and which are not reported. The fields corresponding to unreported parameters MUST be set to zero. The receiver MUST ignore any Statistics Summary Report Block with a non-zero value in any field flagged as unreported. The Statistics Summary Report Block has the following format: Friedman et al. Standards Track [Page 22] =0C Internet-Draft RTCP XR April 2003 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=3D6 |L|D|J|ToH|rsvd.| block length =3D 9 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | begin_seq | end_seq | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | lost_packets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | dup_packets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | min_jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | max_jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | avg_jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | dev_jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | min_ttl_or_hl | max_ttl_or_hl | avg_ttl_or_hl | dev_ttl_or_hl | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block type (BT): 8 bits A Statistics Summary Report Block is identified by the constant 6. loss report flag (L): 1 bit Bit set to 1 if the lost_packets field contains a report, 0 otherwise. duplicate report flag (D): 1 bit Bit set to 1 if the dup_packets field contains a report, 0 otherwise. jitter flag (J): 1 bit Bit set to 1 if the min_jitter, max_jitter, avg_jitter, and dev_jitter fields all contain reports, 0 if none of them do. TTL or Hop Limit flag (ToH): 2 bits This field is set to 0 if none of the fields min_ttl_or_hl, max_ttl_or_hl, avg_ttl_or_hl, or dev_ttl_or_hl contain reports. If the field is non-zero then all of these fields contain reports. The value 1 signifies that they report on IPv4 TTL values. The value 2 signifies that they report on IPv6 Hop Limit values. This value 3 is undefined and MUST NOT be used. Friedman et al. Standards Track [Page 23] =0C Internet-Draft RTCP XR April 2003 rsvd.: 3 bits This field is reserved for future definition. In the absence of such definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver. block length: 16 bits The constant 9, in accordance with the definition of this field in Section 3. SSRC of source: 32 bits As defined in Section 4.1. begin_seq: 16 bits As defined in Section 4.1. end_seq: 16 bits As defined in Section 4.1. lost_packets: 32 bits Number of lost packets in the above sequence number interval. dup_packets: 32 bits Number of duplicate packets in the above sequence number interval. min_jitter: 32 bits The minimum relative transit time between two packets in the above sequence number interval. All jitter values are measured as the difference between a packet's RTP timestamp and the reporter's clock at the time of arrival, measured in the same units. max_jitter: 32 bits The maximum relative transit time between two packets in the above sequence number interval. avg_jitter: 32 bits The average relative transit time between each two packet series in the above sequence number interval. dev_jitter: 32 bits The standard deviation of the relative transit time between each two packet series in the above sequence number interval. min_ttl_or_hl: 8 bits The minimum TTL or Hop Limit value of data packets in the sequence number range. Friedman et al. Standards Track [Page 24] =0C Internet-Draft RTCP XR April 2003 max_ttl_or_hl: 8 bits The maximum TTL or Hop Limit value of data packets in the sequence number range. avg_ttl_or_hl: 8 bits The average TTL or Hop Limit value of data packets in the sequence number range. dev_ttl_or_hl: 8 bits The standard deviation of TTL or Hop Limit values of data packets in the sequence number range. 4.7 VoIP Metrics Report Block The VoIP Metrics Report Block provides metrics for monitoring voice over IP (VoIP) calls. These metrics include packet loss and discard metrics, delay metrics, analog metrics, and voice quality metrics. The block reports separately on packets lost on the IP channel, and those that have been received but then discarded by the receiving jitter buffer. It also reports on the combined effect of losses and discards, as both have equal effect on call quality. In order to properly assess the quality of a Voice over IP call it is desirable to consider the degree of burstiness of packet loss [14]. Following a Gilbert-Elliott model [3], a period of time, bounded by lost and/or discarded packets, with a high rate of losses and/or discards is a "burst," and a period of time between two bursts is a "gap." Bursts correspond to periods of time during which the packet loss rate is high enough to produce noticeable degradation in audio quality. Gaps correspond to periods of time during which only isolated lost packets may occur, and in general these can be masked by packet loss concealment. Delay reports include the transit delay between RTCP end points and the VoIP end system processing delays, both of which contribute to the user perceived delay. Additional metrics include signal, echo, noise, and distortion levels. Call quality metrics include R factors (as described by the E Model defined in [3]) and mean opinion scores (MOS scores). Implementations MUST provide values for all the fields defined here. For certain metrics, if the value is undefined or unknown, then the specified default or unknown field value MUST be provided. The block is encoded as seven 32-bit words: Friedman et al. Standards Track [Page 25] =0C Internet-Draft RTCP XR April 2003 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=3D7 | reserved | block length =3D 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | loss rate | discard rate | burst density | gap density | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | burst duration | gap duration | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | round trip delay | end system delay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | signal level | noise level | RERL | Gmin | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | R factor | ext. R factor | MOS-LQ | MOS-CQ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RX config | reserved | JB nominal | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | JB maximum | JB abs max | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block type (BT): 8 bits A VoIP Metrics Report Block is identified by the constant 7. reserved: 8 bits This field is reserved for future definition. In the absence of such definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver. block length: 16 bits The constant 8, in accordance with the definition of this field in Section 3. SSRC of source: 32 bits As defined in Section 4.1. The remaining fields are described in the following six sections: Packet Loss and Discard Metrics, Delay Metrics, Signal Related Metrics, Call Quality or Transmission Quality Metrics, Configuration Metrics, and Jitter Buffer Parameters. 4.7.1 Packet Loss and Discard Metrics It is very useful to distinguish between packets lost by the network and those discarded due to jitter. Both have equal effect on the quality of the voice stream however having separate counts helps Friedman et al. Standards Track [Page 26] =0C Internet-Draft RTCP XR April 2003 identify the source of quality degradation. These fields MUST be populated. loss rate: 8 bits The fraction of RTP data packets from the source lost since the beginning of reception, expressed as a fixed point number with the binary point at the left edge of the field. This value is calculated by dividing the total number of packets lost (after the effects of applying any error protection such as FEC) by the total number of packets expected, multiplying the result of the division by 256, limiting the maximum value to 255 (to avoid overflow), and taking the integer part. The numbers of duplicated packets and discarded packets do not enter into this calculation. Since receivers cannot be required to maintain unlimited buffers, a receiver MAY categorize late-arriving packets as lost. The degree of lateness that triggers a loss SHOULD be significantly greater than that which triggers a discard. discard rate: 8 bits The fraction of RTP data packets from the source that have been discarded since the beginning of reception, due to late or early arrival, under-run or overflow at the receiving jitter buffer. This value is expressed as a fixed point number with the binary point at the left edge of the field. It is calculated by dividing the total number of packets discarded (excluding duplicate packet discards) by the total number of packets expected, multiplying the result of the division by 256, limiting the maximum value to 255 (to avoid overflow), and taking the integer part. 4.7.2 Burst Metrics A burst, informally, is a period of high packet losses and/or discards. Formally, a burst is defined as a longest sequence of packets bounded by lost or discarded packets with the constraint that within a burst any sequence of successive packets that were received, and not discarded due to delay variation, is of length less than a value Gmin. A gap, informally, is a period of low packet losses and/or discards. Formally, a gap is defined as any of the following: (a) the period from the start of an RTP session to the receipt time of the last received packet before the first burst, (b) the period from the end of the last burst to either the time of the report or the end of the RTP session, whichever comes first, or (c) the period of time between two bursts. Friedman et al. Standards Track [Page 27] =0C Internet-Draft RTCP XR April 2003 For the purpose of determining if a lost or discarded packet near the start or end of an RTP session is within a gap or a burst it is assumed that the RTP session is preceded and followed by at least Gmin received packets, and that the time of the report is followed by at least Gmin received packets. A gap has the property that any lost or discarded packets within the gap must be preceded and followed by at least Gmin packets that were received and not discarded. This gives a maximum loss/discard density within a gap of: 1 / (Gmin + 1). A Gmin value of 16 is RECOMMENDED as it results in gap characteristics that correspond to good quality (i.e. low packet loss rate, a minimum distance of 16 received packets between lost packets) and hence differentiates nicely between good and poor quality periods. For example, a 1 denotes a received, 0 a lost, and X a discarded packet in the following pattern covering 64 packets: 11110111111111111111111X111X1011110111111111111111111X111111111 |---------gap----------|--burst---|------------gap------------| The burst consists of the twelve packets indicated above, starting at a discarded packet and ending at a lost packet. The first gap starts at the beginning of the session and the second gap ends at the time of the report. If the packet spacing is 10 ms and the Gmin value is the recommended value of 16, the burst duration is 120 ms, the burst density 0.33, the gap duration 230 ms + 290 ms =3D 520 ms, and the gap density 0.04. This would result in reported values as follows (see field descriptions for semantics and details on how these are calculated): loss density 12, which corresponds to 5% discard density 12, which corresponds to 5% burst density 84, which corresponds to 33% gap density 10, which corresponds to 4% burst duration 120, value in milliseconds gap duration 520, value in milliseconds burst density: 8 bits The fraction of RTP data packets within burst periods since the beginning of reception that were either lost or discarded. This value is expressed as a fixed point number with the binary point Friedman et al. Standards Track [Page 28] =0C Internet-Draft RTCP XR April 2003 at the left edge of the field. It is calculated by dividing the total number of packets lost or discarded (excluding duplicate packet discards) within burst periods by the total number of packets expected within the burst periods, multiplying the result of the division by 256, limiting the maximum value to 255 (to avoid overflow), and taking the integer part. gap density: 8 bits The fraction of RTP data packets within inter-burst gaps since the beginning of reception that were either lost or discarded. The value is expressed as a fixed point number with the binary point at the left edge of the field. It is calculated by dividing the total number of packets lost or discarded (excluding duplicate packet discards) within gap periods by the total number of packets expected within the gap periods, multiplying the result of the division by 256, limiting the maximum value to 255 (to avoid overflow), and taking the integer part. burst duration: 16 bits The mean duration, expressed in milliseconds, of the burst periods that have occurred since the beginning of reception. The duration of each period is calculated based upon the packets that mark the beginning and end of that period. It is equal to the timestamp of the end packet, plus the duration of the end packet, minus the timestamp of the beginning packet. If the actual values are not available, estimated values MUST be used. If there have been no burst periods, the burst duration value MUST be zero. gap duration: 16 bits The mean duration, expressed in milliseconds, of the gap periods that have occurred since the beginning of reception. The duration of each period is calculated based upon the packet that marks the end of the prior burst and the packet that marks the beginning of the subsequent burst. It is equal to the timestamp of the subsequent burst packet, minus the timestamp of the prior burst packet, plus the duration of the prior burst packet. If the actual values are not available, estimated values MUST be used. In the case of a gap that occurs at the beginning of reception, the sum of the timestamp of the prior burst packet and the duration of the prior burst packet are replaced by the reception start time. In the case of a gap that occurs at the end of reception, the timestamp of the subsequent burst packet is replaced by the reception end time. If there have been no gap periods, the gap duration value MUST be zero. 4.7.3 Delay Metrics Friedman et al. Standards Track [Page 29] =0C Internet-Draft RTCP XR April 2003 For the purpose of the following definitions, the RTP interface is the interface between the RTP instance and the voice application (i.e. FEC, de-interleaving, de-multiplexing, jitter buffer). For example, the time delay due to RTP payload multiplexing would be considered to be part of the voice application or end-system delay whereas delay due to multiplexing RTP frames within a UDP frame would be considered part of the RTP reported delay. This distinction is consistent with the use of RTCP for delay measurements. round trip delay: 16 bits The most recently calculated round trip time between RTP interfaces, expressed in milliseconds. This value MAY be measured using RTCP, the DLRR method defined in Section 4.5 of this document or other approaches. If RTCP is used then the reported delay value is the time of receipt of the most recent RTCP packet from source SSRC, minus the LSR (last SR) time reported in its SR (Sender Report), minus the DLSR (delay since last SR) reported in its SR. A non-zero LSR value is required in order to calculate round trip delay. A value of 0 is permissible, however this field MUST be populated as soon as a delay estimate is available. end system delay: 16 bits The most recently estimated end system delay, expressed in milliseconds. End system delay is defined as the total encoding, decoding and jitter buffer delay determined at the reporting endpoint. This is the time required for an RTP frame to be buffered, decoded, converted to analog form, looped back at the local analog interface, encoded, and made available for transmission as an RTP frame. The manner in which this value is estimated is implementation dependent. This parameter MUST be provided in all VoIP metrics reports. Note that the one way symmetric VoIP segment delay may be calculated from the round trip and end system delays as follows. If the round trip delay is denoted RTD and the end system delays associated with the two endpoints are ESD(A) and ESD(B) then: one way symmetric voice path delay =3D ( RTD + ESD(A) + ESD(B) ) / 2 4.7.4 Signal Related Metrics The following metrics are intended to provide real time information related to the non-packet elements of the voice over IP system to assist with the identification of problems affecting call quality. The values identified below must be determined for the received audio Friedman et al. Standards Track [Page 30] =0C Internet-Draft RTCP XR April 2003 signal. The information required to populate these fields may not be available in all systems, although it is strongly recommended that this data SHOULD be provided to support problem diagnosis. signal level: 8 bits The voice signal relative level is defined as the ratio of the signal level to a reference digital milliwatt, expressed in decibels as a signed integer in two's complement form. This is measured only for packets containing speech energy. The intent of this metric is not to provide a precise measurement of the signal level but to provide a real time indication that the signal level may be excessively high or low. signal level =3D 10 Log10 ( rms talkspurt power (mW) ) A value of 127 indicates that this parameter is unavailable. Typical values should be generally in the -15 to -20 dBm range. noise level: 8 bits The noise level is defined as the ratio of the silent period background noise level to a reference digital milliwatt, expressed in decibels as a signed integer in two's complement form. noise level =3D 10 Log10 ( rms silence power (mW) ) A value of 127 indicates that this parameter is unavailable. residual echo return loss (RERL): 8 bits The residual echo return loss is defined as the sum of the measured echo return loss (ERL) and the echo return loss enhancement (ERLE) expressed in dB as a signed integer in two's complement form. It defines the ratio of a transmitted voice signal that is reflected back to the talker. A low level of echo return loss (say less than 20 dB) in conjunction with some delay can lead to hollowness or audible echo. A high level of echo return loss (say over 40 dB) is preferable. The ERL and ERLE parameters are often available directly from the echo canceler contained within the VoIP end system. They relate to the echo on the external network attached to the end point. In the case of a VoIP gateway this would be line echo that typically occurs at 2-4 wire conversion points in the network. Echo return loss from typical 2-4 wire conversions can be in the 8-12 dB range. A line echo canceler can provide an ERLE of 30 dB or more and hence reduce this to 40-50 dB. In the case of an IP phone this could be residual acoustic echo from speakerphone operation, and may more Friedman et al. Standards Track [Page 31] =0C Internet-Draft RTCP XR April 2003 correctly be termed terminal coupling loss (TCL). A typical handset would result in 40-50 dB of echo due to acoustic feedback. Typical values for RERL are as follows: (i) IP gateway connected to circuit switched network with 2 wire loop Without echo cancellation, typical 2-4 wire converter ERL of 12 dB RERL =3D ERL + ERLE =3D 12 + 0 =3D 12 dB (ii) IP gateway connected to circuit switched network with 2 wire loop With echo canceler that improves echo by 30 dB RERL =3D ERL + ERLE =3D 12 + 30 =3D 42 dB (iii) IP phone with conventional handset Acoustic coupling from handset speaker to microphone 40 dB Residual echo return loss =3D TCL =3D 40 dB If we denote the "local" end of the VoIP path as A and the remote end as B and if the sender loudness rating (SLR) and receiver loudness rating (RLR) are known for A (default values 8 dB and 2 dB respectively), then the echo loudness level at end A (talker echo loudness rating or TELR) is given by: TELR(A) =3D SRL(A) + ERL(B) + ERLE(B) + RLR(A) TELR(B) =3D SRL(B) + ERL(A) + ERLE(A) + RLR(B) Hence in order to incorporate echo into a voice quality estimate at the A end of a VoIP connection it is desirable to send the ERL + ERLE value from B to A. For an IP phone with handset this metric MUST be set to the designed or measured terminal coupling loss, which would typically be 40-50 dB. For a PC softphone or speakerphone this metric MUST be set to either the value reported by the acoustic echo canceler or to 127 to indicate an undefined value. For an IP gateway with ERL and ERLE measurements this metric MUST be reported as ERL + ERLE. For an IP gateway without ERL and ERLE measurement capability then this metric MUST be reported as 12 dB if line echo cancellation is disabled and 40 dB if line echo cancellation is enabled. Gmin See Configuration Parameters (Section 4.7.6, below). Friedman et al. Standards Track [Page 32] =0C Internet-Draft RTCP XR April 2003 4.7.5 Call Quality or Transmission Quality Metrics The following metrics are direct measures of the call quality or transmission quality, and incorporate the effects of codec type, packet loss, discard, burstiness, delay etc. These metrics may not be available in all systems however SHOULD be provided in order to support problem diagnosis. R factor: 8 bits The R factor is a voice quality metric describing the segment of the call that is carried over this RTP session. It is expressed as an integer in the range 0 to 100, with a value of 94 corresponding to "toll quality" and values of 50 or less regarded as unusable. This metric is defined as including the effects of delay, consistent with ITU-T G.107 [6] and ETSI TS 101 329-5 [3]. A value of 127 indicates that this parameter is unavailable. ext. R factor: 8 bits The external R factor is a voice quality metric describing the segment of the call that is carried over a network segment external to the RTP segment, for example a cellular network. Its values are interpreted in the same manner as for the RTP R factor. This metric is defined as including the effects of delay, consistent with ITU-T G.107 [6] and ETSI TS 101 329-5 [3], and relates to the outward voice path from the Voice over IP termination for which this metrics block applies. A value of 127 indicates that this parameter is unavailable. Note that an overall R factor may be estimated from the RTP segment R factor and the external R factor, as follows: R total =3D RTP R factor + ext. R factor - 94 MOS-LQ: 8 bits The estimated mean opinion score for listening quality (MOS-LQ) is a voice quality metric on a scale from 1 to 5, in which 5 represents excellent and 1 represents unacceptable. This metric is defined as not including the effects of delay and can be compared to MOS scores obtained from listening quality (ACR) tests. It is expressed as an integer in the range 10 to 50, corresponding to MOS x 10. For example, a value of 35 would correspond to an estimated MOS score of 3.5. A value of 127 indicates that this parameter is unavailable. Friedman et al. Standards Track [Page 33] =0C Internet-Draft RTCP XR April 2003 MOS-CQ: 8 bits The estimated mean opinion score for conversational quality (MOS-CQ) is defined as including the effects of delay and other effects that would affect conversational quality. The metric may be calculated by converting an R factor determined according to ITU-T G.107 [6] or ETSI TS 101 329-5 [3] into an estimated MOS using the equation specified in G.107. It is expressed as an integer in the range 10 to 50, corresponding to MOS x 10, as for MOS-LQ. A value of 127 indicates that this parameter is unavailable. 4.7.6 Configuration Parameters Gmin: 8 bits The gap threshold. This field contains the value used for this report block to determine if a gap exists. The recommended value of 16 corresponds to a burst period having a minimum density of 6.25% of lost or discarded packets, which may cause noticeable degradation in call quality; during gap periods, if packet loss or discard occurs, each lost or discarded packet would be preceded by and followed by a sequence of at least 16 received non-discarded packets. Note that lost or discarded packets that occur within Gmin packets of a report being generated may be reclassified as being part of a burst or gap in later reports. ETSI TS 101 329-5 [3] defines a computationally efficient algorithm for measuring burst and gap density using a packet loss/discard event driven approach. This algorithm is reproduced in Appendix A.2 of the present document. Gmin MUST not be zero and MUST be provided. receiver configuration byte (RX config): 8 bits This byte consists of the following fields: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |PLC|JBA|JB rate| +-+-+-+-+-+-+-+-+ packet loss concealment (PLC): 2 bits Standard (11) / enhanced (10) / disabled (01) / unspecified (00). When PLC =3D 11 then a simple replay or interpolation algorithm is being used to fill-in the missing packet. This is typically able to conceal isolated lost packets with loss rates under 3%. When PLC =3D 10 then an enhanced interpolation algorithm is being used. This would Friedman et al. Standards Track [Page 34] =0C Internet-Draft RTCP XR April 2003 typically be able to conceal lost packets for loss rates of 10% or more. When PLC =3D 01 then silence is inserted in place of lost packets. When PLC =3D 00 then no information is available concerning the use of PLC however for some codecs this may be inferred. jitter buffer adaptive (JBA): 2 bits Adaptive (11) / non-adaptive (10) / reserved (01)/ unknown (00). When the jitter buffer is adaptive then its size is being dynamically adjusted to deal with varying levels of jitter. When non-adaptive, the jitter buffer size is maintained at a fixed level. When either adaptive or non- adaptive modes are specified then the jitter buffer size parameters below MUST be specified. jitter buffer rate (JB rate): 4 bits J =3D adjustment rate (0-15). This represents the implementation specific adjustment rate of a jitter buffer in adaptive mode. This parameter is defined in terms of the approximate time taken to fully adjust to a step change in peak to peak jitter from 30 ms to 100 ms such that: adjustment time =3D 2 * J * frame size (ms) This parameter is intended only to provide a guide to the degree of "aggressiveness" of a an adaptive jitter buffer and may be estimated. A value of 0 indicates that the adjustment time is unknown for this implementation. reserved: 8 bits This field is reserved for future definition. In the absence of such definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver. 4.7.7 Jitter Buffer Parameters jitter buffer nominal delay (JB nominal): 16 bits This is the current nominal jitter buffer delay in milliseconds, which corresponds to the nominal jitter buffer delay for packets that arrive exactly on time. This parameter MUST be provided for both fixed and adaptive jitter buffer implementations. jitter buffer maximum delay (JB maximum): 16 bits This is the current maximum jitter buffer delay corresponding to the earliest arriving packet that would not be discarded. In simple queue implementations this may correspond to the nominal size. In adaptive jitter buffer implementations this value may dynamically vary up to JB abs max (see below). This parameter Friedman et al. Standards Track [Page 35] =0C Internet-Draft RTCP XR April 2003 MUST be provided for both fixed and adaptive jitter buffer implementations. jitter buffer absolute maximum delay (JB abs max): 16 bits This is the absolute maximum delay that the adaptive jitter buffer can reach under worst case jitter conditions. This parameter MUST be provided for adaptive jitter buffer implementations and its value MUST be set to JB maximum for fixed jitter buffer implementations. 5. SDP Signaling This section defines Session Description Protocol (SDP) [4] signaling for XR blocks that can be employed by applications that utilize SDP. This signaling is defined to be used either by applications that implement the SDP Offer/Answer model [9] or by applications that use SDP to describe media and transport configurations in connection with such protocols as the Session Announcement Protocol (SAP) [15] or the Real Time Streaming Protocol (RTSP) [16]. There exist other potential signaling methods, which are not defined here. The XR blocks MAY be used without prior signaling. This is consistent with the rules governing other RTCP packet types, as described in [10]. An example in which signaling would not be used is an application that always requires the use of one or more XR blocks. However for applications that are configured at session initiation, the use of some type of signaling is recommended. Note that, although the use of SDP signaling for XR blocks may be optional, if used it MUST be used as defined here. If SDP signaling is used in an environment where XR blocks are only implemented by some fraction of the participants, the ones not implementing the XR blocks will ignore the SDP attribute. 5.1 The SDP Attribute This section defines one new SDP attribute "rtcp-xr" that can be used to signal participants in a media session that they should use the specified XR blocks. This attribute can be easily extended in the future with new parameters to cover any new report blocks. The RTCP XR blocks SDP attribute is defined below in Augmented Backus-Naur Form (ABNF) [2]. It is both a session and a media level attribute. When specified at session level, it applies to all media level blocks in the session. Any media level specification MUST replace a session level specification, if one is present, for that media block. Friedman et al. Standards Track [Page 36] =0C Internet-Draft RTCP XR April 2003 rtcp-xr-attrib =3D "a=3D" "rtcp-xr" ":" [xr-format *(SP xr-format)] CR= LF xr-format =3D pkt-loss-rle / pkt-dup-rle / pkt-rcpt-times / rcvr-rtt / stat-summary / voip-metrics / format-ext pkt-loss-rle =3D "pkt-loss-rle" ["=3D" max-size] pkt-dup-rle =3D "pkt-dup-rle" ["=3D" max-size] pkt-rcpt-times =3D "pkt-rcpt-times" ["=3D" max-size] rcvr-rtt =3D "rcvr-rtt" "=3D" rcvr-rtt-mode [":" max-size] stat-summary =3D "stat-summary" voip-metrics =3D "voip-metrics" max-size =3D 1*DIGIT ; maximum block size in octets rcvr-rtt-mode =3D "all" / "sender" format-ext =3D non-ws-string non-ws-string =3D 1*(%x21-FF) The "rtcp-xr" attribute contains zero, one, or more XR block related parameters. Each parameter signals functionality for an XR block, or a group of XR blocks. The attribute is extensible so that parameters can be defined for any future XR block (and a parameter should be defined for every future block). Each "rtcp-xr" parameter belongs to one of two categories. The first category, the unilateral parameters, are for report blocks that simply report on the RTP stream and related metrics. The second category, collaborative parameters, are for XR blocks that involve actions by more than one party in order to carry out their functions. Round trip time (RTT) measurement is an example of collaborative functionality. An RTP data packet receiver sends a Receiver Reference Time Report Block (Section 4.4). A participant that receives this block sends a DLRR Report Block (Section 4.5) in response, allowing the receiver to calculate its RTT to that participant. As this example illustrates, collaborative functionality may be implemented by two or more different XR blocks. The collaborative functionality of several XR blocks may be governed by a single "rtcp-xr" parameter. For the unilateral category, this document defines the following Friedman et al. Standards Track [Page 37] =0C Internet-Draft RTCP XR April 2003 parameters. The parameter names and their corresponding XR formats are as follows: Parameter name XR block (block type and name) -------------- ------------------------------------ pkt-loss-rle 1 Loss RLE Report Block pkt-dup-rle 2 Duplicate RLE Report Block pkt-rcpt-times 3 Packet Receipt Times Report Block stat-summary 6 Statistics Summary Report Block voip-metrics 7 VoIP Metrics Report Block The "pkt-loss-rle", "pkt-dup-rle", and "pkt-rcpt-times" parameters MAY specify an integer value. This value indicates the largest size the whole report block SHOULD have in octets. This shall be seen as an indication that thinning shall be applied if necessary to meet the target size. Blocks in the collaborative category are classified as initiator blocks or response blocks. Signaling SHOULD indicate which participants are required to respond to the initiator block. A party that wishes to receive response blocks from those participants can trigger this by sending an initiator block. The collaborative category currently consists only of one functionality, namely the RTT measurement mechanism for RTP data receivers. The collective functionality of the Receiver Reference Time Report Block and DLRR Report Block is represented by the "rcvr- rtt" parameter. This parameter takes as its arguments a mode value and, optionally, a maximum size for the DLRR report block. The mode value "all" indicates that both RTP data senders and data receivers MAY send DLRR blocks, while the mode value "sender" indicates that only active RTP senders MAY send DLRR blocks, i.e. non RTP senders SHALL NOT send DLRR blocks. If a maximum size in octets is included, any DLRR Report Blocks that are sent SHALL NOT exceed the specified size. If size limitations mean that a DLRR Report Block sender cannot report in one block upon all participants from which it has received a Receiver Reference Time Report Block then it SHOULD report on participants in a round robin fashion across several report intervals. The "rtcp-xr" attributes parameter list MAY be empty. This is useful in cases in which an application needs to signal that it understands the SDP signaling but does not wish to avail itself of XR functionality. For example, an application in a SIP controlled session could signal that it wishes to stop using all XR blocks by removing all applicable SDP parameters in a re-INVITE message that it sends. If XR blocks are not to be used at all from the beginning of Friedman et al. Standards Track [Page 38] =0C Internet-Draft RTCP XR April 2003 a session, it is RECOMMENDED that the "rtcp-xr" attribute not be supplied at all. When the "rtcp-xr" attribute is present, participants SHOULD NOT send XR blocks other than the ones indicated by the parameters. This means that inclusion of a "rtcp-xr" attribute without any parameters tells a participant that it SHOULD NOT send any XR blocks at all. The purpose is to conserve bandwidth. This is especially important when collaborative parameters are applied to a large multicast group: the sending of an initiator block could potentially trigger responses from all participants. There are, however, contexts in which it makes sense to send an XR block in the absence of a parameter signaling its use. For instance, an application might be designed so as to send certain report blocks without negotiation, while using SDP signaling to negotiate the use of other blocks. 5.2 Usage in Offer/Answer In the Offer/Answer context [9], the interpretation of SDP signaling for XR packets depends upon the direction attribute that is signaled: "recvonly", "sendrecv", or "sendonly" [4]. If no direction attribute is supplied then "sendrecv" is assumed. This section applies only to unicast media streams, except where noted. Discussion of unilateral parameters is followed by discussion of collaborative parameters in this section. For "sendonly" and "sendrecv" media stream offers that specify unilateral "rtcp-xr" attribute parameters, the answerer SHOULD send the corresponding XR blocks. For "sendrecv" offers, the answerer MAY include the "rtcp-xr" attribute in its response, and specify any unilateral parameters in order to request that the offerer send the corresponding XR blocks. The offerer SHOULD send these blocks. For "recvonly" media stream offers, the offerer's use of the "rtcp- xr" attribute in connection with unilateral parameters indicates that the offerer is capable of sending the corresponding XR blocks. If the answerer responds with an "rtcp-xr" attribute, the offerer SHOULD send XR blocks for each specified unilateral parameter that was in its offer. For multicast media streams, the inclusion of an "rtcp-xr" attribute with unilateral parameters means that every media recipient SHOULD send the corresponding XR blocks. An SDP offer with a collaborative parameter declares the offerer capable of receiving the corresponding initiator and replying with the appropriate responses. For example, an offer that specifies the "rcvr-rtt" parameter means that the offerer is prepared to receive Friedman et al. Standards Track [Page 39] =0C Internet-Draft RTCP XR April 2003 Receiver Reference Time Report Blocks and to send DLRR Report Blocks. An offer of a collaborative parameter means that the answerer MAY send the initiator, and, having received the initiator, the offerer SHOULD send the responses. There are exceptions to the rule that an offerer of a collaborative parameter should send responses. For instance, the collaborative parameter might specify a mode that excludes the offerer. Or congestion control or maximum transmission unit considerations might militate against the offerer's response. By including a collaborative parameter in its answer, the answerer declares its ability to receive initiators and to send responses. The offerer MAY then send initiators, to which the answerer SHOULD reply with responses. As for the offer of a collaborative parameter, there are exceptions to the rule that the answerer should reply. When making an SDP offer of a collaborative parameter for a multicast media stream, the offerer SHOULD specify which participants are to respond to a received initiator. A participant that is not specified SHOULD NOT send responses. Otherwise, undue bandwidth might be consumed. The offer indicates that each participant that is specified SHOULD respond if it receives an initiator. It also indicates that a specified participant MAY send an initiator block. An SDP answer for a multicast media stream SHOULD include all collaborative parameters that are present in the offer and that are supported by the answerer. It SHOULD NOT include any collaborative parameter that is absent from the offer. If a participant receives an SDP offer and understands the "rtcp-xr" attribute but does not wish to implement XR functionality offered, its answer SHOULD include an "rtcp-xr" attribute without parameters. By doing so, the party declares that at a minimum that it is capable of understanding the signaling. 5.3 Usage Outside of Offer/Answer SDP can be employed outside of the Offer/Answer context, for instance for multimedia sessions that are announced through the Session Announcement Protocol (SAP) [15], or streamed through the Real Time Streaming Protocol (RTSP) [16]. The signaling model is simpler, as the sender does not negotiate parameters, but the functionality that is expected from specifying the "rtcp-xr" attribute is the same as in Offer/Answer. When a unilateral parameter is specified for the "rtcp-xr" attribute associated with a media stream, the receiver of that stream SHOULD Friedman et al. Standards Track [Page 40] =0C Internet-Draft RTCP XR April 2003 send the corresponding XR block. When a collaborative parameter is specified, only the participants indicated by the mode value in the collaborative parameter are concerned. Each such participant that receives an initiator block SHOULD send the corresponding response block. Each such participant MAY also send initiator blocks. 6. IANA Considerations This document defines a new RTCP packet type, the Extended Report (XR) type, within the existing Internet Assigned Numbers Authority (IANA) registry of RTP RTCP Control Packet Types. This document also defines a new IANA registry: the registry of RTCP XR Block Types. Within this new registry, this document defines an initial set of seven block types and describes how the remaining types are to be allocated. Further, this document defines a new SDP attribute, "rtcp-xr", within the existing IANA registry of SDP Parameters. It defines a new IANA registry, the registry of RTCP XR SDP Parameters, and an initial set of six parameters, and describes how additional parameters are to be allocated. 6.1 XR Packet Type The XR packet type defined by this document is registered with the IANA as packet type 207 in the registry of RTP RTCP Control Packet types (PT). 6.2 RTCP XR Block Type Registry This document creates an IANA registry called the RTCP XR Block Type Registry to cover the name space of the Extended Report block type (BT) field specified in Section 3. The BT field contains eight bits, allowing 256 values. The RTCP XR Block Type Registry is to be managed by the IANA according to the Specification Required policy of RFC 2434 [8]. Future specifications SHOULD attribute block type values in strict numeric order following the values attributed in this document: Friedman et al. Standards Track [Page 41] =0C Internet-Draft RTCP XR April 2003 BT name -- ---- 1 Loss RLE Report Block 2 Duplicate RLE Report Block 3 Packet Receipt Times Report Block 4 Receiver Reference Time Report Block 5 DLRR Report Block 6 Statistics Summary Report Block 7 VoIP Metrics Report Block The BT value 255 is reserved for future extensions. Furthermore, future specifications SHOULD avoid the value 0. Doing so facilitates packet validity checking, since an all-zeros field might commonly be found in an ill-formed packet. 6.3 The "rtcp-xr" SDP Attribute This SDP attribute "rtcp-xr" defined by this document is registered with the IANA registry of SDP Parameters as follows: SDP Attribute ("att-field"): Attribute name: rtcp-xr Long form: RTP Control Protocol Extended Report Parameters Type of name: att-field Type of attribute: session and media level Subject to charset: no Purpose: see Section 5 of this document Reference: this document Values: see this document and registrations below The attribute has an extensible parameter field and therefore a registry for these parameters is required. This document creates an IANA registry called the RTCP XR SDP Parameters Registry. It contains the six parameters defined in Section 5.1: "pkt-loss-rle", "pkt-dup-rle", "pkt-rcpt-times", "stat-summary", "voip-metrics", and "recv-rtt". Additional parameters are to be added to this registry in accordance with the Specification Required policy of RFC 2434 [8]. Any registration MUST contain the following information: - Contact information of the one doing the registration, including at least name, address, and email. - An Augmented Backus-Naur Form (ABNF) [2] definition of the Friedman et al. Standards Track [Page 42] =0C Internet-Draft RTCP XR April 2003 parameter, in accordance with the "format-ext" definition. - A description of what the parameter represents and how it shall be interpreted, both normally and in Offer/Answer. 7. Security Considerations This document extends the RTCP reporting mechanism. The security considerations that apply to RTCP reports also apply to XR reports. This section details the additional security considerations that apply to the extensions. The extensions introduce heightened confidentiality concerns. Standard RTCP reports contain a limited number of summary statistics. The information contained in XR reports is both more detailed and more extensive (covering a larger number of parameters). The per- packet report blocks and the VoIP Metrics Report Block provide examples. The per-packet information contained in Loss RLE, Duplicate RLE, and Packet Receipt Times Report Blocks facilitates multicast inference of network characteristics (MINC) [11]. Such inference can reveal the gross topology of a multicast distribution tree, as well as parameters, such as the loss rates and delays, along paths between branching points in that tree. Such information might be considered sensitive to autonomous system administrators. The VoIP Metrics Report Block provides information on the quality of ongoing voice calls. Though such information might be carried in application specific format in standard RTP sessions, making it available in a standard format here makes it more available to potential eavesdroppers. No new mechanisms are introduced in this document to ensure confidentiality. Encryption procedures, such as those being suggested for a Secure RTCP (SRTCP) [12] at the time that this document was written, can be used when confidentiality is a concern to end hosts. Given that RTCP traffic can be encrypted by the end hosts, autonomous systems must be prepared for the fact that certain aspects of their network topology can be revealed. Any encryption or filtering of XR report blocks entails a loss of monitoring information to third parties. For example, a network that establishes a tunnel to encrypt VoIP Report Blocks denies that information to the service providers traversed by the tunnel. The service providers cannot then monitor or respond to the quality of the VoIP calls that they carry, potentially creating problems for the network's users. As a default, XR packets SHOULD NOT be encrypted or Friedman et al. Standards Track [Page 43] =0C Internet-Draft RTCP XR April 2003 filtered. The extensions also make certain denial of service attacks easier. This is because of the potential to create RTCP packets much larger than average with the per packet reporting capabilities of the Loss RLE, Duplicate RLE, and Timestamp Report Blocks. Because of the automatic bandwidth adjustment mechanisms in RTCP, if some session participants are sending large RTCP packets, all participants will see their RTCP reporting intervals lengthened, meaning they will be able to report less frequently. To limit the effects of large packets, even in the absence of denial of service attacks, applications SHOULD place an upper limit on the size of the XR report blocks they employ. The "thinning" techniques described in Section 4.1 permit the packet-by-packet report blocks to adhere to a predefined size limit. A. Algorithms A.1 Sequence Number Interpretation This the algorithm suggested by Section 4.1 for keeping track of the sequence numbers from a given sender. It implements the accounting practice required for the generation of Loss RLE Report Blocks. This algorithm keeps track of 16 bit sequence numbers by translating them into a 32 bit sequence number space. The first packet received from a source is considered to have arrived roughly in the middle of that space. Each packet that follows is placed either ahead or behind the prior one in this 32 bit space, depending upon which choice would place it closer (or, in the event of a tie, which choice would not require a rollover in the 16 bit sequence number). // The reference sequence number is an extended sequence number // that serves as the basis for determining whether a new 16 bit // sequence number comes earlier or later in the 32 bit sequence // space. u_int32 _src_ref_seq; bool _uninitialized_src_ref_seq; // Place seq into a 32-bit sequence number space based upon a // heuristic for its most likely location. u_int32 extend_seq(const u_int16 seq) { u_int32 extended_seq, seq_a, seq_b, diff_a, diff_b; if(_uninitialized_src_ref_seq) { // This is the first sequence number received. Place // it in the middle of the extended sequence number Friedman et al. Standards Track [Page 44] =0C Internet-Draft RTCP XR April 2003 // space. _src_ref_seq =3D seq | 0x80000000u; _uninitialized_src_ref_seq =3D false; extended_seq =3D _src_ref_seq; } else { // Prior sequence numbers have been received. // Propose two candidates for the extended sequence // number: seq_a is without wraparound, seq_b with // wraparound. seq_a =3D seq | (_src_ref_seq & 0xFFFF0000u); if(_src_ref_seq < seq_a) { seq_b =3D seq_a - 0x00010000u; diff_a =3D seq_a - _src_ref_seq; diff_b =3D _src_ref_seq - seq_b; } else { seq_b =3D seq_a + 0x00010000u; diff_a =3D _src_ref_seq - seq_a; diff_b =3D seq_b - _src_ref_seq; } // Choose the closer candidate. If they are equally // close, the choice is somewhat arbitrary: we choose // the candidate for which no rollover is necessary. if(diff_a < diff_b) { extended_seq =3D seq_a; } else { extended_seq =3D seq_b; } // Set the reference sequence number to be this most // recently-received sequence number. _src_ref_seq =3D extended_seq; } // Return our best guess for a 32-bit sequence number that // corresponds to the 16-bit number we were given. return extended_seq; } A.2 Example Burst Packet Loss Calculation. This is an algorithm for measuring the burst characteristics for the VoIP Metrics Report Block (Section 4.7). It is reproduced from ETSI TS 101 329-5 [3]. The algorithm is event driven and hence extremely Friedman et al. Standards Track [Page 45] =0C Internet-Draft RTCP XR April 2003 computationally efficient. Given the following definition of states: state 1 =3D received a packet during a gap state 2 =3D received a packet during a burst state 3 =3D lost a packet during a burst state 4 =3D lost an isolated packet during a gap The "c" variables below correspond to state transition counts, i.e. c14 is the transition from state 1 to state 4. It is possible to infer one of a pair of state transition counts to an accuracy of 1 which is generally sufficient for this application. "pkt" is the count of packets received since the last packet was declared lost or discarded and "lost" is the number of packets lost within the current burst. "packet_lost" and "packet_discarded" are Boolean variables that indicate if the event that resulted in this function being invoked was a lost or discarded packet. if(packet_lost) { loss_count++; } if(packet_discarded) { discard_count++; } if(!packet_lost && !packet_discarded) { pkt++; } else { if(pkt >=3D gmin) { if(lost =3D=3D 1) { c14++; } else { c13++; } lost =3D 1; c11 +=3D pkt; } else { lost++; if(pkt =3D=3D 0) { c33++; } else { Friedman et al. Standards Track [Page 46] =0C Internet-Draft RTCP XR April 2003 c23++; c22 +=3D (pkt - 1); } } pkt =3D 0; } At each reporting interval the burst and gap metrics can be calculated as follows. // Calculate additional transition counts. c31 =3D c13; c32 =3D c23; ctotal =3D c11 + c14 + c13 + c22 + c23 + c31 + c32 + c33; // Calculate burst and densities. p32 =3D c32 / (c31 + c32 + c33); if((c22 + c23) < 1) { p23 =3D 1; } else { p23 =3D 1 - c22/(c22 + c23); } burst_density =3D 256 * p23 / (p23 + p32); gap_density =3D 256 * c14 / (c11 + c14); // Calculate burst and gap durations in ms m =3D frameDuration_in_ms * framesPerRTPPkt; gap_length =3D (c11 + c14 + c13) * m / c13; burst_length =3D ctotal * m / c13 - lgap; /* calculate loss and discard densities */ loss_density =3D 256 * loss_count / ctotal; discard_density =3D 256 * discard_count / ctotal; Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP 11 [5]. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such Friedman et al. Standards Track [Page 47] =0C Internet-Draft RTCP XR April 2003 proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgments We thank the following people: Colin Perkins, Steve Casner, and Henning Schulzrinne for their considered guidance; Sue Moon for helping foster collaboration between the authors; Mounir Benzaid for drawing our attention to the reporting needs of MLDA; Dorgham Sisalem and Adam Wolisz for encouraging us to incorporate MLDA block types; and Jose Rey for valuable review of the SDP Signaling section. Contributors Friedman et al. Standards Track [Page 48] =0C Internet-Draft RTCP XR April 2003 The following people are the authors of this document: Kevin Almeroth, UCSB Ramon Caceres, ShieldIP Alan Clark, Telchemy Robert Cole, AT&T Labs Nick Duffield, AT&T Labs-Research Timur Friedman, Paris 6 Kaynam Hedayat, Brix Networks Kamil Sarac, UT Dallas Magnus Westerlund, Ericsson The principal people to contact regarding the individual report blocks described in this document are as follows: sec. report block principal contributors ---- ------------ ---------------------- 4.1 Loss RLE Report Block Friedman, Caceres, Duffield 4.2 Duplicate RLE Report Block Friedman, Caceres, Duffield 4.3 Packet Receipt Times Report Block Friedman, Caceres, Duffield 4.4 Receiver Reference Time Report Block Friedman 4.5 DLRR Report Block Friedman 4.6 Statistics Summary Report Block Almeroth, Sarac 4.7 VoIP Metrics Report Block Clark, Cole, Hedayat The principal person to contact regarding the SDP signaling described in this document is Magnus Westerlund. Authors' Addresses Kevin Almeroth Department of Computer Science University of California Santa Barbara, CA 93106 USA Ramon Caceres ShieldIP, Inc. 11 West 42nd Street, 31st Floor New York, NY 10036 USA Friedman et al. Standards Track [Page 49] =0C Internet-Draft RTCP XR April 2003 Alan Clark Telchemy Incorporated 3360 Martins Farm Road, Suite 200 Suwanee, GA 30024 USA Tel: +1 770 614 6944 Fax: +1 770 614 3951 Robert Cole AT&T Labs 330 Saint Johns Street, 2nd Floor Havre de Grace, MD 21078 USA Tel: +1 410 939 8732 Fax: +1 410 939 8732 Nick Duffield AT&T Labs-Research 180 Park Avenue, P.O. Box 971 Florham Park, NJ 07932-0971 USA Tel: +1 973 360 8726 Fax: +1 973 360 8050 Timur Friedman Universite Pierre et Marie Curie (Paris 6) Laboratoire LiP6-CNRS 8, rue du Capitaine Scott 75015 PARIS France Tel: +33 1 44 27 71 06 Fax: +33 1 44 27 74 95 Kaynam Hedayat Brix Networks 285 Mill Road Chelmsford, MA 01824 USA Tel: +1 978 367 5600 Fax: +1 978 367 5700 Kamil Sarac Department of Computer Science (ES 4.207) Eric Jonsson School of Engineering & Computer Science University of Texas at Dallas Richardson, TX 75083-0688 USA Tel: +1 972 883 2337 Fax: +1 972 883 2349 Friedman et al. Standards Track [Page 50] =0C Internet-Draft RTCP XR April 2003 Magnus Westerlund Ericsson Research, Corporate Unit Ericsson Radio Systems AB SE-164 80 Stockholm Sweden Tel: +46 8 404 82 87 Fax: +46 8 757 55 50 References The references are divided into normative references and non- normative references. Normative References [1] S. Bradner, "Key words for use in RFCs to indicate requirement levels," BCP 14, RFC 2119, IETF, March 1997. [2] D. Crocker, P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Engineering Task Force, November 1997. [3] ETSI, "Quality of Service (QoS) measurement methodologies," ETSI TS 101 329-5 V1.1.1 (2000-11), November 2000. [4] M. Handley, V. Jacobson, "SDP: Session Description Protocol", RFC 2327, Internet Engineering Task Force, April 1998. [5] R. Hovey and S. Bradner, "The Organizations Involved in the IETF Standards Process," best current practice BCP 11, RFC 2028, IETF, October 1996. [6] ITU-T, "The E-Model, a computational model for use in transmission planning," Recommendation G.107 (05/00), May 2000. [7] J. Reynolds and J. Postel, "Assigned Numbers," standard STD 2, RFC 1700, IETF, October 1994. [8] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs," best current practice BCP 26, RFC 2434, IETF, October 1998. [9] J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with the Session Description Protocol (SDP)", RFC 3264, Internet Engineering Task Force, June 2002. [10] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A transport protocol for real-time applications," RFC 1889, IETF, February 1996. Friedman et al. Standards Track [Page 51] =0C Internet-Draft RTCP XR April 2003 Non-Normative References [11] A. Adams, T. Bu, R. Caceres, N. G. Duffield, T. Friedman, J. Horowitz, F. Lo Presti, S. B. Moon, V. Paxson, and D. Towsley, "The Use of End-to-End Multicast Measurements for Characterizing Internal Network Behavior," IEEE Communications Magazine, May 2000. [12] Baugher, McGrew, Oran, Blom, Carrara, Naslund, and Norrman, "The Secure Real-time Transport Protocol," Internet-Draft draft-ietf-avt- srtp-05.txt, June 2002. Note: this is is a work in progress. [13] R. Caceres, N. G. Duffield, and T. Friedman, "Impromptu measurement infrastructures using RTP," Proc. IEEE Infocom 2002. [14] A. D. Clark, "Modeling the Effects of Burst Packet Loss and Recency on Subjective Voice Quality," Proc. IP Telephony Workshop 2001. [15] M. Handley, C. Perkins, E. Whelan, "Session Announcement Protocol", RFC 2974, Internet Engineering Task Force, October 2000. [16] H. Schulzrinne, R. Lanphier, and A. Rao, "Real time streaming protocol (RTSP)," RFC 2326, Internet Engineering Task Force, Apr. 1998. [17] D. Sisalem and A. Wolisz, "MLDA: A TCP-friendly Congestion Control Framework for Heterogeneous Multicast Environments", Proc. IWQoS 2000. Friedman et al. Standards Track [Page 52] =0C --------------Boundary-00=_0FWG70E3FSRIR5YRS3YC-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Apr 17 18:19:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11869 for ; Thu, 17 Apr 2003 18:19:06 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3HMSPW14706 for avt-archive@odin.ietf.org; Thu, 17 Apr 2003 18:28:25 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HMLp814338; Thu, 17 Apr 2003 18:21:51 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HMK5814252 for ; Thu, 17 Apr 2003 18:20:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11040 for ; Thu, 17 Apr 2003 18:10:16 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196HcZ-0003AC-00 for avt@ietf.org; Thu, 17 Apr 2003 18:12:43 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 196HcZ-0003A9-00 for avt@ietf.org; Thu, 17 Apr 2003 18:12:43 -0400 Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h3HMCu1M005043 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Thu, 17 Apr 2003 18:12:57 -0400 (EDT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by bart.cs.columbia.edu (8.12.9/8.12.6) with ESMTP id h3HMCuqY029073 for ; Thu, 17 Apr 2003 18:12:56 -0400 (EDT) Message-ID: <3E9F26CA.3090508@cs.columbia.edu> Date: Thu, 17 Apr 2003 18:12:26 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030401 X-Accept-Language: en-us, en MIME-Version: 1.0 To: avt@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] Firewire for real-time video Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Does anybody have experience with using FireWire for real-time video, e.g., to feed video into vic on Windows from a digital video camera? Thanks. Henning _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Apr 17 19:08:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13685 for ; Thu, 17 Apr 2003 19:08:17 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3HNHZb18403 for avt-archive@odin.ietf.org; Thu, 17 Apr 2003 19:17:35 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HNCF818258; Thu, 17 Apr 2003 19:12:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HNBT818236 for ; Thu, 17 Apr 2003 19:11:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13536 for ; Thu, 17 Apr 2003 19:01:41 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196IQJ-0003Vm-00 for avt@ietf.org; Thu, 17 Apr 2003 19:04:07 -0400 Received: from m205-237.dsl.tsoft.com ([198.144.205.237] helo=lists.herlein.com ident=root) by ietf-mx with esmtp (Exim 4.12) id 196IQI-0003Vj-00 for avt@ietf.org; Thu, 17 Apr 2003 19:04:07 -0400 Received: from tux.herlein.com (tux.herlein.com [192.168.70.50]) by lists.herlein.com (8.11.6/8.11.3/SuSE Linux 8.11.1-0.5) with ESMTP id h3HMikC05906; Thu, 17 Apr 2003 15:44:46 -0700 Date: Thu, 17 Apr 2003 16:04:08 -0700 (PDT) From: Greg Herlein To: Henning Schulzrinne cc: avt@ietf.org Subject: Re: [AVT] Firewire for real-time video In-Reply-To: <3E9F26CA.3090508@cs.columbia.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , > Does anybody have experience with using FireWire for real-time video, > e.g., to feed video into vic on Windows from a digital video camera? I looked at this last year and found that Firewire-capable cameras that could be controlled (ie, focus.aperture, etc) were *really* expensive (multiple thousands of dollars) and that the average consumer DV cam could not support anything other than playback features. If that has changed, I'd like to know about it too! There are several libraries on the linux side for pulling Firewire streams right off the camera in playback mode... there must be some for Win32. To ask a related question, does anyone know if there is a tape drive for miniDV tapes that can be used directly in a PC (ideally PCI bus or USB interface?). Once a tape is created, it's crazy to have to use the camera to play it so it can be ripped onto spinning storage. Greg _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Apr 17 22:28:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17203 for ; Thu, 17 Apr 2003 22:28:37 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3I2c0Y30497 for avt-archive@odin.ietf.org; Thu, 17 Apr 2003 22:38:00 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3I2ba830489; Thu, 17 Apr 2003 22:37:36 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3I2b0829598 for ; Thu, 17 Apr 2003 22:37:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17186 for ; Thu, 17 Apr 2003 22:27:06 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196Ld7-0004CV-00 for avt@ietf.org; Thu, 17 Apr 2003 22:29:33 -0400 Received: from koganei.wide.ad.jp ([202.249.37.254] helo=ns.koganei.wide.ad.jp) by ietf-mx with esmtp (Exim 4.12) id 196Ld6-0004CS-00 for avt@ietf.org; Thu, 17 Apr 2003 22:29:32 -0400 Received: from koganei.wide.ad.jp (tweedledee.koganei.wide.ad.jp [202.249.37.72]) (authenticated bits=0) by ns.koganei.wide.ad.jp (8.12.8/8.12.6) with ESMTP id h3I2RdPf065873; Fri, 18 Apr 2003 11:27:39 +0900 (JST) (envelope-from ikob@koganei.wide.ad.jp) Date: Fri, 18 Apr 2003 11:29:49 +0900 Subject: Re: [AVT] Firewire for real-time video Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: avt@ietf.org To: Henning Schulzrinne From: Katsushi Kobayashi In-Reply-To: <3E9F26CA.3090508@cs.columbia.edu> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit See: http://www.sfc.wide.ad.jp/DVTS/ If you can accept Japanese page, http://www.fatware.co.jp/ On 2003.Apr.18, at 07:12 AM, Henning Schulzrinne wrote: > Does anybody have experience with using FireWire for real-time video, > e.g., to feed video into vic on Windows from a digital video camera? > > Thanks. > > Henning > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Apr 18 07:19:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08655 for ; Fri, 18 Apr 2003 07:19:57 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3IBTUt07601 for avt-archive@odin.ietf.org; Fri, 18 Apr 2003 07:29:30 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3IBT6807586; Fri, 18 Apr 2003 07:29:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3IBP8807484 for ; Fri, 18 Apr 2003 07:25:08 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08301; Fri, 18 Apr 2003 07:15:05 -0400 (EDT) Message-Id: <200304181115.HAA08301@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: avt@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 18 Apr 2003 07:15:04 -0400 Subject: [AVT] I-D ACTION:draft-ietf-avt-rtcp-report-extns-04.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Control Protocol Extended Reports (RTCP XR) Author(s) : T. Friedman et al. Filename : draft-ietf-avt-rtcp-report-extns-04.txt Pages : 52 Date : 2003-4-17 This document defines the Extended Report (XR) packet type for the RTP Control Protocol (RTCP), and defines how the use of XR packets can be signaled by an application if it employs the Session Description Protocol (SDP). XR packets are composed of report blocks, and seven block types are defined here. The purpose of the extended reporting format is to convey information that supplements the six statistics that are contained in the report blocks used by RTCP's Sender Report (SR) and Receiver Report (RR) packets. Some applications, such as multicast inference of network characteristics (MINC) or voice over IP (VoIP) monitoring, require other and more detailed statistics. In addition to the block types defined here, additional block types may be defined in the future by adhering to the framework that this document provides. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcp-report-extns-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtcp-report-extns-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtcp-report-extns-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-17132020.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtcp-report-extns-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtcp-report-extns-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-17132020.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Apr 18 09:36:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13260 for ; Fri, 18 Apr 2003 09:36:33 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3IDk9217003 for avt-archive@odin.ietf.org; Fri, 18 Apr 2003 09:46:09 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3IDjc816979; Fri, 18 Apr 2003 09:45:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3IDgV816884 for ; Fri, 18 Apr 2003 09:42:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13213 for ; Fri, 18 Apr 2003 09:32:25 -0400 (EDT) From: Dirk.Trossen@nokia.com Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196W0x-0007Wb-00 for avt@ietf.org; Fri, 18 Apr 2003 09:34:51 -0400 Received: from mgw-dax1.ext.nokia.com ([63.78.179.216]) by ietf-mx with esmtp (Exim 4.12) id 196W0w-0007WY-00 for avt@ietf.org; Fri, 18 Apr 2003 09:34:50 -0400 Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3IDZ4116574 for ; Fri, 18 Apr 2003 08:35:04 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 18 Apr 2003 08:35:04 -0500 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 18 Apr 2003 08:34:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AVT] Firewire for real-time video Date: Fri, 18 Apr 2003 09:34:42 -0400 Message-ID: Thread-Topic: [AVT] Firewire for real-time video Thread-Index: AcMFLsvpUvYth3g3R5qAzvQ/ZxsDQgAf15tA To: , X-OriginalArrivalTime: 18 Apr 2003 13:34:43.0856 (UTC) FILETIME=[456AF900:01C305AF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3IDgW816885 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Henning, I did some experiments some years ago (when Firewire 400 was still experimental). At that time, I used the card's SDK directly, which allowed for receiving the synchronous data directly in a block of memory. VFW-compatible integration (which is probably what you need if you want to feed it directly into vic without changing the vic code) was not possible at this time. I don't know whether or not this has changed though. However, opening a small window in Windows that displays a VFW-compatible source, is quite easy to do. If your Firewire card allows for VFW integration, it should display the video right away. Regards, Dirk >-----Original Message----- >From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >Sent: Thursday, April 17, 2003 6:12 PM >To: avt@ietf.org >Subject: [AVT] Firewire for real-time video > > >Does anybody have experience with using FireWire for real-time video, >e.g., to feed video into vic on Windows from a digital video camera? > >Thanks. > >Henning > >_______________________________________________ >Audio/Video Transport Working Group >avt@ietf.org >https://www1.ietf.org/mailman/listinfo/avt > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Apr 18 10:14:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15141 for ; Fri, 18 Apr 2003 10:14:52 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3IEOTQ19227 for avt-archive@odin.ietf.org; Fri, 18 Apr 2003 10:24:29 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3IEO5819200; Fri, 18 Apr 2003 10:24:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3IEL3819116 for ; Fri, 18 Apr 2003 10:21:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14751 for ; Fri, 18 Apr 2003 10:10:55 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196WcD-0007hz-00 for avt@ietf.org; Fri, 18 Apr 2003 10:13:21 -0400 Received: from telchemy.com ([66.155.69.251]) by ietf-mx with esmtp (Exim 4.12) id 196WcD-0007hk-00 for avt@ietf.org; Fri, 18 Apr 2003 10:13:21 -0400 Received: from TELWS104 [64.238.103.215] by telchemy.com with ESMTP (SMTPD32-7.14) id A7E7B8A01A4; Fri, 18 Apr 2003 10:12:55 -0400 Reply-To: From: "Alan Clark" To: , "'Colin Perkins'" , "'Stephen Casner'" Subject: RE: [AVT] I-D ACTION:draft-ietf-avt-rtcp-report-extns-04.txt Date: Fri, 18 Apr 2003 10:08:16 -0400 Message-ID: <003201c305b3$f5e3ae90$6801a8c0@telchemy.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200304181115.HAA08301@ietf.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Colin, Steve The new (and hopefully) final RTCP XR draft has emerged, complete with SDP signaling, I would like to propose that this be considered for last call. Regards Alan Clark Telchemy _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Apr 18 19:47:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01253 for ; Fri, 18 Apr 2003 19:47:21 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3INv9T23260 for avt-archive@odin.ietf.org; Fri, 18 Apr 2003 19:57:09 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3INul823133; Fri, 18 Apr 2003 19:56:47 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3INpA823014 for ; Fri, 18 Apr 2003 19:51:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01074 for ; Fri, 18 Apr 2003 19:40:51 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196fVk-00021B-00 for avt@ietf.org; Fri, 18 Apr 2003 19:43:16 -0400 Received: from [131.107.65.240] (helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 196fVj-000211-00 for avt@ietf.org; Fri, 18 Apr 2003 19:43:15 -0400 Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with ESMTP id h3INgwTA004329; Fri, 18 Apr 2003 19:42:58 -0400 (EDT) (envelope-from csp@purple.nge.isi.edu) Message-Id: <200304182342.h3INgwTA004329@purple.nge.isi.edu> To: avt@ietf.org cc: casner@acm.org Date: Fri, 18 Apr 2003 16:42:58 -0700 From: Colin Perkins Subject: [AVT] WG Last call: draft-ietf-avt-rtcp-report-extns-04.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This is to announce a working group last call on the RTP Control Protocol Extended Reports (draft-ietf-avt-rtcp-report-extns-04.txt). Please send any final comments on this draft to the mailing list by Monday 28th April 2003. At that time, we will consider if it is appropriate to request publication of this draft as a proposed standard RFC. I have a number of concerns regarding the clarity of specification of the Voice-over-IP metrics, which I will send as last call comments in the next couple of days. -- Colin Perkins http://csperkins.org/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Apr 21 19:04:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07784 for ; Mon, 21 Apr 2003 19:04:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3LNFWO04650 for avt-archive@odin.ietf.org; Mon, 21 Apr 2003 19:15:32 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LNEW804571; Mon, 21 Apr 2003 19:14:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LNAZ804408 for ; Mon, 21 Apr 2003 19:10:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07349 for ; Mon, 21 Apr 2003 18:58:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 197kHf-0004Ng-00 for avt@ietf.org; Mon, 21 Apr 2003 19:01:11 -0400 Received: from mail.utstar.com ([65.200.123.6]) by ietf-mx with esmtp (Exim 4.12) id 197kHe-0004Nc-00 for avt@ietf.org; Mon, 21 Apr 2003 19:01:10 -0400 Received: from balanew ([172.16.40.43]) by mail.utstar.com (8.11.3/8.11.3) with ESMTP id h3LN1ZF07453; Mon, 21 Apr 2003 19:01:35 -0400 (EDT) Reply-To: From: "Balasubramanian Pitchandi" To: Cc: Date: Mon, 21 Apr 2003 19:01:32 -0400 Organization: UTStarcom Inc Message-ID: <006101c30859$f39585c0$2b2810ac@balanew> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0062_01C30838.6C83E5C0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Subject: [AVT] Status of draft-kreuter-avt-rtp-clearmode-02.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0062_01C30838.6C83E5C0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hello, I was wondering if this draft is still being considered as an action item for the Working Group. We are in need of an assignment for the "Clear Mode" (bit exact data with no encoding) codec to be used in our products. I could not find this draft in the IETF draft index and in the AVT WG home page as well. Please let me know the status of the draft. Thanks, Bala ______________________ Bala Pitchandi UTStarcom Inc. ------=_NextPart_000_0062_01C30838.6C83E5C0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hello,

 

I was wondering if this draft is still being = considered as an action item for the Working Group. We are in need of an assignment = for the “Clear Mode” (bit exact data with no encoding) codec to be used in our = products.

 

I could not find this draft in the IETF draft index = and in the AVT WG home page as well.

 

Please let me know the status of the = draft.

 

Thanks,

Bala

______________________

Bala = Pitchandi

UTStarcom = Inc.

------=_NextPart_000_0062_01C30838.6C83E5C0-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Apr 21 19:24:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08253 for ; Mon, 21 Apr 2003 19:24:29 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3LNZkY05295 for avt-archive@odin.ietf.org; Mon, 21 Apr 2003 19:35:46 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LNZD805279; Mon, 21 Apr 2003 19:35:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LNW6805215 for ; Mon, 21 Apr 2003 19:32:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08185 for ; Mon, 21 Apr 2003 19:20:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 197kcU-0004bY-00 for avt@ietf.org; Mon, 21 Apr 2003 19:22:42 -0400 Received: from wireless228.east.isi.edu ([65.123.202.228] helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 197kcT-0004bV-00 for avt@ietf.org; Mon, 21 Apr 2003 19:22:41 -0400 Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with ESMTP id h3LNMvGt048670; Mon, 21 Apr 2003 19:22:57 -0400 (EDT) (envelope-from csp@purple.nge.isi.edu) Message-Id: <200304212322.h3LNMvGt048670@purple.nge.isi.edu> To: bs@utstar.com cc: avt@ietf.org, ruediger.kreuter@siemens.com Subject: Re: [AVT] Status of draft-kreuter-avt-rtp-clearmode-02.txt In-Reply-To: Your message of "Mon, 21 Apr 2003 19:01:32 EDT." <006101c30859$f39585c0$2b2810ac@balanew> Date: Mon, 21 Apr 2003 19:22:57 -0400 From: Colin Perkins Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --> "Balasubramanian Pitchandi" writes: >I was wondering if this draft is still being considered as an action item >for the Working Group. We are in need of an assignment for the "Clear Mode" >(bit exact data with no encoding) codec to be used in our products. > >I could not find this draft in the IETF draft index and in the AVT WG home >page as well. > >Please let me know the status of the draft. The draft filename changed to draft-ietf-avt-rtp-clearmode-00.txt when it was accepted as an AVT work item. It is still under consideration by the group (and may change before the final RFC is issued). Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Apr 22 03:33:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29009 for ; Tue, 22 Apr 2003 03:33:57 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3M7jOD14932 for avt-archive@odin.ietf.org; Tue, 22 Apr 2003 03:45:24 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3M7hq814858; Tue, 22 Apr 2003 03:43:52 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3M7ex814712 for ; Tue, 22 Apr 2003 03:40:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28853 for ; Tue, 22 Apr 2003 03:29:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 197sFP-000778-00 for avt@ietf.org; Tue, 22 Apr 2003 03:31:23 -0400 Received: from adsl-66-159-193-111.dslextreme.com ([66.159.193.111] helo=server.hyervision.com) by ietf-mx with esmtp (Exim 4.12) id 197sFO-000774-00 for avt@ietf.org; Tue, 22 Apr 2003 03:31:22 -0400 Received: from WIND (hyervision.com [66.159.193.111]) by server.hyervision.com (8.12.6/8.12.6) with ESMTP id h3M7MxeH011886; Tue, 22 Apr 2003 00:22:59 -0700 (PDT) From: "Adam Li" To: Cc: "'Scott Bradner'" , "'Allison Mankin'" , , , , Date: Tue, 22 Apr 2003 00:31:29 -0700 Organization: UCLA Message-ID: <000801c308a1$345d6a40$657ba8c0@divxnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3M7f2814737 Subject: [AVT] The storage format of EVRC/SMV vocoder (resent) Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Dear Steve, Colin, AVT'ers, The issue of the storage format of the EVRC and SMV vocoders in the MIME registration has came up a while ago, and has caused the last minute holding of the MIME registration for these two vocoders. The issue has been discussed thoroughly here on the mailing list in the San Francisco meeting. The reasons of each side of the argument have been well presented. Now it may be time to make a decision? Like many other issues in our AVT WG, the decision here is ultimately relying on the judgment of our chairs. During the two and half years that this draft is being developed in the AVT, the course of the draft has benefited greatly from your guidance. After the open and ego-free discuss that our chairs called upon at the meeting session, it may be another good time to hear the opinions from the chairs and get some help on the decision from their experience and vision on which one will reflect the consensus of the AVT and would be most beneficial to the whole Internet and telecom industry who will use our specification. Below is the summary of the rationales for each of the choices: draft-ieft-avt-evrc-smv-03.txt | draft-garudadri-qcp-00.txt ------------------------------------+-------------------------------- (1) Mature specification, been | (1) Brand new ID developed for 2.5 years in AVT | ------------------------------------+-------------------------------- (2) Covers both EVRC and SMV | (2) Only cover EVRC ------------------------------------+-------------------------------- (3) Referred to by 3GPP2(*) FFMS | (3) specifications | ------------------------------------+-------------------------------- (4) Implemented and used by many 3G | (4) Supported in Eudora telecom operators (e.g., SKT, | KTF, LGT). The interoperability | has been tested among them. | ------------------------------------+-------------------------------- (5) Simple and efficient design, | (5) quick to implement | ------------------------------------+-------------------------------- (6) Registration already in IANA, | (6) ------------------------------------+-------------------------------- (7) Supported and developed by 7 | (7) Supported and developed by companies and universities | Qualcomm (including Qualcomm) | ------------------------------------+-------------------------------- (8) No IP related to this format | (8) IP situation unclear ------------------------------------+-------------------------------- (*) ERVC and SMV are both vocoders developed and defined in the international consortium 3GPP2 (http://www.3gpp2.org) for the next generation wireless network cdma2000. Thank you very much. Adam PS. This is a resent of the previous message, which did not seem to go through maybe because of the long cc list. If you think anyone is missed out, please let me know. Thanks. > -----Original Message----- > From: Adam Li [mailto:adamli@icsl.ucla.edu] > Sent: Saturday, March 15, 2003 9:20 PM > To: 'Ietf-Avt' > Cc: 'casner@acm.org'; 'Scott Bradner'; 'Colin Perkins'; 'Allison > Mankin'; 'randy@qualcomm.com'; 'mccap@lucent.com'; > 'mdturner@lucent.com'; 'smathai@lucent.com'; 'lioy@qualcomm.com'; > 'zeng@packetvideo.com'; 'sherwood@packetvideo.com'; > 'villa@icsl.ucla.edu'; 'yllee@samsung.com'; 'jeonghoon@samsung.com'; > 'tom.hiller@lucent.com'; 'David.Leon@nokia.com'; > 'nleung@qualcomm.com'; 'dgal@lucent.com'; 'ajayrajkumar@lucent.com'; > 'Lars-Erik.Jonsson@epl.ericsson.se'; 'magnus.westerlund@era- > t.ericsson.se'; 'vbharga@cisco.com'; 'craig.greer@nokia.com'; > 'magda@qualcomm.com'; 'casner@acm.org'; 'ned.freed@mrochek.com'; > 'mankin@psg.com'; 'hgarudad@qualcomm.com'; 'csp@isi.edu'; > 'jlee@nextreaming.com'; 'sakazawa@kddilabs.jp'; 'tsgc@3gpp2.org' > Subject: Issues for the file format for EVRC/SMV vocoder > > Hi folks, > > The topic of the file format for EVRC/SMV vocoders hopefully will be > discussed in this meeting at San Francisco. Below is a list of the > issues that might be related to this topic. They are listed here as > potential issues for you to consider before the discussion at the > meeting. > > (1) Technically differences. Is there much difference in efficiency > and performance between the format in draft-ietf-avt-evrc-smv and > draft-garudadri-qcp? Are the differences simply on the file syntax? > > (2) Completeness. For EVRC codec data, formats defined in both > document can handle it. For SMV codec data, the format defined in > draft-ietf-avt-evrc-smv is currently the only file format that > handles SMV data. draft-garudadri-qcp does not handle SMV at this > time. > > (3) Maturity of the format definition. draft-ietf-avt-evrc-smv has > its first version submitted to AVT on November 2000. It has been > actively worked on all these years, and is co-authored by people > from seven companies and universities. It is currently on the RFC > editor's queue. draft-garudadri-qcp is submitted in February 2003. > Will there be concerns about the maturity of the drafts, > particularly the handling of SMV codec hasn't been written in the > later draft yet? > > (4) The recognition. Since EVRC and SMV codec are designed in 3GPP2 > for their CDMA networks, formats recognized by them are likely to be > the most widely used format for those codecs. Which of the formats, > as defined in draft-ietf-avt-evrc-smv and draft-garudadri-qcp, has > been considered by 3GPP2 for the format for storing EVRC and SMV > data? > > (5) Document organization. Even though this is a rather minor point, > but would there be enough reasons to trade-off for the additional > complexity for having the MIME registration of EVRC/SMV refering to > a separate and yet to be complete draft? > > Draft-ietf-avt-evrc-smv is currently on the RFC editor's queue. If > we want to consider deleting the file format that is in the draft > for almost two years in the last minute before it becomes an RFC and > using another yet to be complete new draft instead, we should be > providing ourselves with the clear justification for doing so. > > I will not be there for the discussion unfortunately since I have > not made the plan to attend in advance. However, I hope the list of > potential issues above might be useful for us to discuss and > consider. > > Wish we have a fruitful meeting in San Francisco. > > Adam _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Apr 22 13:29:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17307 for ; Tue, 22 Apr 2003 13:29:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3MHf1L24471 for avt-archive@odin.ietf.org; Tue, 22 Apr 2003 13:41:01 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MHe1824427; Tue, 22 Apr 2003 13:40:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MHcB824336 for ; Tue, 22 Apr 2003 13:38:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17244 for ; Tue, 22 Apr 2003 13:26:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1981Z9-0003Lv-00 for avt@ietf.org; Tue, 22 Apr 2003 13:28:23 -0400 Received: from wireless228.east.isi.edu ([65.123.202.228] helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 1981Z9-0003Ls-00 for avt@ietf.org; Tue, 22 Apr 2003 13:28:23 -0400 Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with ESMTP id h3MHRNGt057310; Tue, 22 Apr 2003 13:27:23 -0400 (EDT) (envelope-from csp@purple.nge.isi.edu) Message-Id: <200304221727.h3MHRNGt057310@purple.nge.isi.edu> To: "Adam Li" cc: avt@ietf.org, "'Scott Bradner'" , "'Allison Mankin'" , craig.greer@nokia.com, jlee@nextreaming.com, sakazawa@kddilabs.jp, keith.miller@nokia.com Subject: Re: [AVT] The storage format of EVRC/SMV vocoder (resent) In-Reply-To: Your message of "Tue, 22 Apr 2003 00:31:29 PDT." <000801c308a1$345d6a40$657ba8c0@divxnetworks.com> Date: Tue, 22 Apr 2003 13:27:23 -0400 From: Colin Perkins Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Adam, The format specified in draft-garudadri-qcp-00.txt clearly needs to be published, and to have a MIME type registered, since it has been used by several applications for some years now. What is unclear is whether draft-ieft-avt-evrc-smv-03.txt should refer to that format, or if it should continue to use the alternative format. The usual arguments apply: having two formats is clearly worse than one, but there may be technical or political reasons why the new format is to be preferred for some uses. As the minutes from the recent AVT meeting note, the main users of the format in draft-ieft-avt-evrc-smv-03.txt seem to be 3GPP2. It is currently unclear if they have implementations of the file format, and if they chose it for technical reasons or because it it was the only format they knew. We are hoping to get input from them, to clarify their position. Colin --> "Adam Li" writes: > >The issue of the storage format of the EVRC and SMV vocoders in the MIME >registration has came up a while ago, and has caused the last minute >holding of the MIME registration for these two vocoders. The issue has >been discussed thoroughly here on the mailing list in the San Francisco >meeting. The reasons of each side of the argument have been well >presented. Now it may be time to make a decision? > >Like many other issues in our AVT WG, the decision here is ultimately >relying on the judgment of our chairs. During the two and half years >that this draft is being developed in the AVT, the course of the draft >has benefited greatly from your guidance. After the open and ego-free >discuss that our chairs called upon at the meeting session, it may be >another good time to hear the opinions from the chairs and get some help >on the decision from their experience and vision on which one will >reflect the consensus of the AVT and would be most beneficial to the >whole Internet and telecom industry who will use our specification. > >Below is the summary of the rationales for each of the choices: > > draft-ieft-avt-evrc-smv-03.txt | draft-garudadri-qcp-00.txt >------------------------------------+-------------------------------- >(1) Mature specification, been | (1) Brand new ID > developed for 2.5 years in AVT | >------------------------------------+-------------------------------- >(2) Covers both EVRC and SMV | (2) Only cover EVRC >------------------------------------+-------------------------------- >(3) Referred to by 3GPP2(*) FFMS | (3) > specifications | >------------------------------------+-------------------------------- >(4) Implemented and used by many 3G | (4) Supported in Eudora > telecom operators (e.g., SKT, | > KTF, LGT). The interoperability | > has been tested among them. | >------------------------------------+-------------------------------- >(5) Simple and efficient design, | (5) > quick to implement | >------------------------------------+-------------------------------- >(6) Registration already in IANA, | (6) >------------------------------------+-------------------------------- >(7) Supported and developed by 7 | (7) Supported and developed by > companies and universities | Qualcomm > (including Qualcomm) | >------------------------------------+-------------------------------- >(8) No IP related to this format | (8) IP situation unclear >------------------------------------+-------------------------------- > >(*) ERVC and SMV are both vocoders developed and defined in the >international consortium 3GPP2 (http://www.3gpp2.org) for the next >generation wireless network cdma2000. > >Thank you very much. > >Adam > >PS. This is a resent of the previous message, which did not seem to go >through maybe because of the long cc list. If you think anyone is missed >out, please let me know. Thanks. > >> -----Original Message----- >> From: Adam Li [mailto:adamli@icsl.ucla.edu] >> Sent: Saturday, March 15, 2003 9:20 PM >> To: 'Ietf-Avt' >> Cc: 'casner@acm.org'; 'Scott Bradner'; 'Colin Perkins'; 'Allison >> Mankin'; 'randy@qualcomm.com'; 'mccap@lucent.com'; >> 'mdturner@lucent.com'; 'smathai@lucent.com'; 'lioy@qualcomm.com'; >> 'zeng@packetvideo.com'; 'sherwood@packetvideo.com'; >> 'villa@icsl.ucla.edu'; 'yllee@samsung.com'; 'jeonghoon@samsung.com'; >> 'tom.hiller@lucent.com'; 'David.Leon@nokia.com'; >> 'nleung@qualcomm.com'; 'dgal@lucent.com'; 'ajayrajkumar@lucent.com'; >> 'Lars-Erik.Jonsson@epl.ericsson.se'; 'magnus.westerlund@era- >> t.ericsson.se'; 'vbharga@cisco.com'; 'craig.greer@nokia.com'; >> 'magda@qualcomm.com'; 'casner@acm.org'; 'ned.freed@mrochek.com'; >> 'mankin@psg.com'; 'hgarudad@qualcomm.com'; 'csp@isi.edu'; >> 'jlee@nextreaming.com'; 'sakazawa@kddilabs.jp'; 'tsgc@3gpp2.org' >> Subject: Issues for the file format for EVRC/SMV vocoder >> >> Hi folks, >> >> The topic of the file format for EVRC/SMV vocoders hopefully will be >> discussed in this meeting at San Francisco. Below is a list of the >> issues that might be related to this topic. They are listed here as >> potential issues for you to consider before the discussion at the >> meeting. >> >> (1) Technically differences. Is there much difference in efficiency >> and performance between the format in draft-ietf-avt-evrc-smv and >> draft-garudadri-qcp? Are the differences simply on the file syntax? >> >> (2) Completeness. For EVRC codec data, formats defined in both >> document can handle it. For SMV codec data, the format defined in >> draft-ietf-avt-evrc-smv is currently the only file format that >> handles SMV data. draft-garudadri-qcp does not handle SMV at this >> time. >> >> (3) Maturity of the format definition. draft-ietf-avt-evrc-smv has >> its first version submitted to AVT on November 2000. It has been >> actively worked on all these years, and is co-authored by people >> from seven companies and universities. It is currently on the RFC >> editor's queue. draft-garudadri-qcp is submitted in February 2003. >> Will there be concerns about the maturity of the drafts, >> particularly the handling of SMV codec hasn't been written in the >> later draft yet? >> >> (4) The recognition. Since EVRC and SMV codec are designed in 3GPP2 >> for their CDMA networks, formats recognized by them are likely to be >> the most widely used format for those codecs. Which of the formats, >> as defined in draft-ietf-avt-evrc-smv and draft-garudadri-qcp, has >> been considered by 3GPP2 for the format for storing EVRC and SMV >> data? >> >> (5) Document organization. Even though this is a rather minor point, >> but would there be enough reasons to trade-off for the additional >> complexity for having the MIME registration of EVRC/SMV refering to >> a separate and yet to be complete draft? >> >> Draft-ietf-avt-evrc-smv is currently on the RFC editor's queue. If >> we want to consider deleting the file format that is in the draft >> for almost two years in the last minute before it becomes an RFC and >> using another yet to be complete new draft instead, we should be >> providing ourselves with the clear justification for doing so. > >> I will not be there for the discussion unfortunately since I have >> not made the plan to attend in advance. However, I hope the list of >> potential issues above might be useful for us to discuss and >> consider. >> >> Wish we have a fruitful meeting in San Francisco. >> >> Adam > > >_______________________________________________ >Audio/Video Transport Working Group >avt@ietf.org >https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Apr 22 13:40:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17714 for ; Tue, 22 Apr 2003 13:40:02 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3MHpeo25264 for avt-archive@odin.ietf.org; Tue, 22 Apr 2003 13:51:40 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MHo6825070; Tue, 22 Apr 2003 13:50:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MHmU824872 for ; Tue, 22 Apr 2003 13:48:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17479 for ; Tue, 22 Apr 2003 13:36:21 -0400 (EDT) From: keith.miller@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1981j8-0003PH-00 for avt@ietf.org; Tue, 22 Apr 2003 13:38:42 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1981j7-0003PC-00 for avt@ietf.org; Tue, 22 Apr 2003 13:38:42 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h3MHd4D18969 for ; Tue, 22 Apr 2003 20:39:04 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 22 Apr 2003 20:39:03 +0300 Received: from daebh002.NOE.Nokia.com ([172.18.242.232]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 22 Apr 2003 20:39:02 +0300 Received: from daebe003.NOE.Nokia.com ([172.18.242.199]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 22 Apr 2003 12:38:57 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AVT] The storage format of EVRC/SMV vocoder (resent) Date: Tue, 22 Apr 2003 12:38:56 -0500 Message-ID: <8146199999A6384A8231B07B6E51D0BB10B3C5@daebe003.americas.nokia.com> Thread-Topic: [AVT] The storage format of EVRC/SMV vocoder (resent) Thread-Index: AcMI9K0Z8YORjqSnQkCCcaY1DUtXYwAAJCgA To: , Cc: , , , , , X-OriginalArrivalTime: 22 Apr 2003 17:38:57.0534 (UTC) FILETIME=[0D57C9E0:01C308F6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3MHmV824877 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit All, This issue was discussed at the last 3GPP2 (April 14-18) meeting by the group developing the 3GPP2 file format specification. It was decided that both formats should be published, but that Qualcomm would request a different MIME type for the EVRC storage in .QCP (maybe EVRC_QCP). Hari Garudadri is expected to submit an updated draft for ".QCP". Of course we need Qualcomm to verify this. regards, KEith Miller Chair 3GPP2 TSG-C 1.2 WG -----Original Message----- From: ext Colin Perkins [mailto:csp@csperkins.org] Sent: 22 April, 2003 12:27 PM To: Adam Li Cc: avt@ietf.org; 'Scott Bradner'; 'Allison Mankin'; Greer Craig (Nokia/Dallas); jlee@nextreaming.com; sakazawa@kddilabs.jp; Miller Keith (NRC/Dallas) Subject: Re: [AVT] The storage format of EVRC/SMV vocoder (resent) Adam, The format specified in draft-garudadri-qcp-00.txt clearly needs to be published, and to have a MIME type registered, since it has been used by several applications for some years now. What is unclear is whether draft-ieft-avt-evrc-smv-03.txt should refer to that format, or if it should continue to use the alternative format. The usual arguments apply: having two formats is clearly worse than one, but there may be technical or political reasons why the new format is to be preferred for some uses. As the minutes from the recent AVT meeting note, the main users of the format in draft-ieft-avt-evrc-smv-03.txt seem to be 3GPP2. It is currently unclear if they have implementations of the file format, and if they chose it for technical reasons or because it it was the only format they knew. We are hoping to get input from them, to clarify their position. Colin --> "Adam Li" writes: > >The issue of the storage format of the EVRC and SMV vocoders in the MIME >registration has came up a while ago, and has caused the last minute >holding of the MIME registration for these two vocoders. The issue has >been discussed thoroughly here on the mailing list in the San Francisco >meeting. The reasons of each side of the argument have been well >presented. Now it may be time to make a decision? > >Like many other issues in our AVT WG, the decision here is ultimately >relying on the judgment of our chairs. During the two and half years >that this draft is being developed in the AVT, the course of the draft >has benefited greatly from your guidance. After the open and ego-free >discuss that our chairs called upon at the meeting session, it may be >another good time to hear the opinions from the chairs and get some help >on the decision from their experience and vision on which one will >reflect the consensus of the AVT and would be most beneficial to the >whole Internet and telecom industry who will use our specification. > >Below is the summary of the rationales for each of the choices: > > draft-ieft-avt-evrc-smv-03.txt | draft-garudadri-qcp-00.txt >------------------------------------+-------------------------------- >(1) Mature specification, been | (1) Brand new ID > developed for 2.5 years in AVT | >------------------------------------+-------------------------------- >(2) Covers both EVRC and SMV | (2) Only cover EVRC >------------------------------------+-------------------------------- >(3) Referred to by 3GPP2(*) FFMS | (3) > specifications | >------------------------------------+-------------------------------- >(4) Implemented and used by many 3G | (4) Supported in Eudora > telecom operators (e.g., SKT, | > KTF, LGT). The interoperability | > has been tested among them. | >------------------------------------+-------------------------------- >(5) Simple and efficient design, | (5) > quick to implement | >------------------------------------+-------------------------------- >(6) Registration already in IANA, | (6) >------------------------------------+-------------------------------- >(7) Supported and developed by 7 | (7) Supported and developed by > companies and universities | Qualcomm > (including Qualcomm) | >------------------------------------+-------------------------------- >(8) No IP related to this format | (8) IP situation unclear >------------------------------------+-------------------------------- > >(*) ERVC and SMV are both vocoders developed and defined in the >international consortium 3GPP2 (http://www.3gpp2.org) for the next >generation wireless network cdma2000. > >Thank you very much. > >Adam > >PS. This is a resent of the previous message, which did not seem to go >through maybe because of the long cc list. If you think anyone is missed >out, please let me know. Thanks. > >> -----Original Message----- >> From: Adam Li [mailto:adamli@icsl.ucla.edu] >> Sent: Saturday, March 15, 2003 9:20 PM >> To: 'Ietf-Avt' >> Cc: 'casner@acm.org'; 'Scott Bradner'; 'Colin Perkins'; 'Allison >> Mankin'; 'randy@qualcomm.com'; 'mccap@lucent.com'; >> 'mdturner@lucent.com'; 'smathai@lucent.com'; 'lioy@qualcomm.com'; >> 'zeng@packetvideo.com'; 'sherwood@packetvideo.com'; >> 'villa@icsl.ucla.edu'; 'yllee@samsung.com'; 'jeonghoon@samsung.com'; >> 'tom.hiller@lucent.com'; 'David.Leon@nokia.com'; >> 'nleung@qualcomm.com'; 'dgal@lucent.com'; 'ajayrajkumar@lucent.com'; >> 'Lars-Erik.Jonsson@epl.ericsson.se'; 'magnus.westerlund@era- >> t.ericsson.se'; 'vbharga@cisco.com'; 'craig.greer@nokia.com'; >> 'magda@qualcomm.com'; 'casner@acm.org'; 'ned.freed@mrochek.com'; >> 'mankin@psg.com'; 'hgarudad@qualcomm.com'; 'csp@isi.edu'; >> 'jlee@nextreaming.com'; 'sakazawa@kddilabs.jp'; 'tsgc@3gpp2.org' >> Subject: Issues for the file format for EVRC/SMV vocoder >> >> Hi folks, >> >> The topic of the file format for EVRC/SMV vocoders hopefully will be >> discussed in this meeting at San Francisco. Below is a list of the >> issues that might be related to this topic. They are listed here as >> potential issues for you to consider before the discussion at the >> meeting. >> >> (1) Technically differences. Is there much difference in efficiency >> and performance between the format in draft-ietf-avt-evrc-smv and >> draft-garudadri-qcp? Are the differences simply on the file syntax? >> >> (2) Completeness. For EVRC codec data, formats defined in both >> document can handle it. For SMV codec data, the format defined in >> draft-ietf-avt-evrc-smv is currently the only file format that >> handles SMV data. draft-garudadri-qcp does not handle SMV at this >> time. >> >> (3) Maturity of the format definition. draft-ietf-avt-evrc-smv has >> its first version submitted to AVT on November 2000. It has been >> actively worked on all these years, and is co-authored by people >> from seven companies and universities. It is currently on the RFC >> editor's queue. draft-garudadri-qcp is submitted in February 2003. >> Will there be concerns about the maturity of the drafts, >> particularly the handling of SMV codec hasn't been written in the >> later draft yet? >> >> (4) The recognition. Since EVRC and SMV codec are designed in 3GPP2 >> for their CDMA networks, formats recognized by them are likely to be >> the most widely used format for those codecs. Which of the formats, >> as defined in draft-ietf-avt-evrc-smv and draft-garudadri-qcp, has >> been considered by 3GPP2 for the format for storing EVRC and SMV >> data? >> >> (5) Document organization. Even though this is a rather minor point, >> but would there be enough reasons to trade-off for the additional >> complexity for having the MIME registration of EVRC/SMV refering to >> a separate and yet to be complete draft? >> >> Draft-ietf-avt-evrc-smv is currently on the RFC editor's queue. If >> we want to consider deleting the file format that is in the draft >> for almost two years in the last minute before it becomes an RFC and >> using another yet to be complete new draft instead, we should be >> providing ourselves with the clear justification for doing so. > >> I will not be there for the discussion unfortunately since I have >> not made the plan to attend in advance. However, I hope the list of >> potential issues above might be useful for us to discuss and >> consider. >> >> Wish we have a fruitful meeting in San Francisco. >> >> Adam > > >_______________________________________________ >Audio/Video Transport Working Group >avt@ietf.org >https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Apr 22 14:12:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19178 for ; Tue, 22 Apr 2003 14:12:41 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3MIOLb28093 for avt-archive@odin.ietf.org; Tue, 22 Apr 2003 14:24:21 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MIN4827975; Tue, 22 Apr 2003 14:23:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MIFe827647 for ; Tue, 22 Apr 2003 14:15:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18802 for ; Tue, 22 Apr 2003 14:03:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19829Q-0003m2-00 for avt@ietf.org; Tue, 22 Apr 2003 14:05:52 -0400 Received: from wireless228.east.isi.edu ([65.123.202.228] helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 19829P-0003lz-00 for avt@ietf.org; Tue, 22 Apr 2003 14:05:51 -0400 Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with ESMTP id h3MI4vGt058058; Tue, 22 Apr 2003 14:04:57 -0400 (EDT) (envelope-from csp@purple.nge.isi.edu) Message-Id: <200304221804.h3MI4vGt058058@purple.nge.isi.edu> To: keith.miller@nokia.com cc: adamli@icsl.ucla.edu, avt@ietf.org, sob@harvard.edu, mankin@psg.com, craig.greer@nokia.com, jlee@nextreaming.com, sakazawa@kddilabs.jp Subject: Re: [AVT] The storage format of EVRC/SMV vocoder (resent) In-Reply-To: Your message of "Tue, 22 Apr 2003 12:38:56 CDT." <8146199999A6384A8231B07B6E51D0BB10B3C5@daebe003.americas.nokia.com> Date: Tue, 22 Apr 2003 14:04:57 -0400 From: Colin Perkins Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Keith, Are there minutes of this meeting available? I'd like to understand the rationale behind the choice (especially the choice of changing the MIME type, since "audio/qcp" seems appropriate). Colin --> keith.miller@nokia.com writes: >All, > >This issue was discussed at the last 3GPP2 (April 14-18) meeting by the group developing the 3GPP2 >file format specification. It was decided that both formats should be published, but >that Qualcomm would request a different MIME type for the EVRC storage in .QCP >(maybe EVRC_QCP). Hari Garudadri is expected to submit an updated >draft for ".QCP". Of course we need Qualcomm to verify this. > >regards, >KEith Miller >Chair 3GPP2 TSG-C 1.2 WG > >-----Original Message----- >From: ext Colin Perkins [mailto:csp@csperkins.org] >Sent: 22 April, 2003 12:27 PM >To: Adam Li >Cc: avt@ietf.org; 'Scott Bradner'; 'Allison Mankin'; Greer Craig >(Nokia/Dallas); jlee@nextreaming.com; sakazawa@kddilabs.jp; Miller Keith >(NRC/Dallas) >Subject: Re: [AVT] The storage format of EVRC/SMV vocoder (resent) > > >Adam, > >The format specified in draft-garudadri-qcp-00.txt clearly needs to be >published, and to have a MIME type registered, since it has been used by >several applications for some years now. > >What is unclear is whether draft-ieft-avt-evrc-smv-03.txt should refer to >that format, or if it should continue to use the alternative format. The >usual arguments apply: having two formats is clearly worse than one, but >there may be technical or political reasons why the new format is to be >preferred for some uses. > >As the minutes from the recent AVT meeting note, the main users of the >format in draft-ieft-avt-evrc-smv-03.txt seem to be 3GPP2. It is currently >unclear if they have implementations of the file format, and if they chose >it for technical reasons or because it it was the only format they knew. We >are hoping to get input from them, to clarify their position. > >Colin > > > > >--> "Adam Li" writes: >> >>The issue of the storage format of the EVRC and SMV vocoders in the MIME >>registration has came up a while ago, and has caused the last minute >>holding of the MIME registration for these two vocoders. The issue has >>been discussed thoroughly here on the mailing list in the San Francisco >>meeting. The reasons of each side of the argument have been well >>presented. Now it may be time to make a decision? >> >>Like many other issues in our AVT WG, the decision here is ultimately >>relying on the judgment of our chairs. During the two and half years >>that this draft is being developed in the AVT, the course of the draft >>has benefited greatly from your guidance. After the open and ego-free >>discuss that our chairs called upon at the meeting session, it may be >>another good time to hear the opinions from the chairs and get some help >>on the decision from their experience and vision on which one will >>reflect the consensus of the AVT and would be most beneficial to the >>whole Internet and telecom industry who will use our specification. >> >>Below is the summary of the rationales for each of the choices: >> >> draft-ieft-avt-evrc-smv-03.txt | draft-garudadri-qcp-00.txt >>------------------------------------+-------------------------------- >>(1) Mature specification, been | (1) Brand new ID >> developed for 2.5 years in AVT | >>------------------------------------+-------------------------------- >>(2) Covers both EVRC and SMV | (2) Only cover EVRC >>------------------------------------+-------------------------------- >>(3) Referred to by 3GPP2(*) FFMS | (3) >> specifications | >>------------------------------------+-------------------------------- >>(4) Implemented and used by many 3G | (4) Supported in Eudora >> telecom operators (e.g., SKT, | >> KTF, LGT). The interoperability | >> has been tested among them. | >>------------------------------------+-------------------------------- >>(5) Simple and efficient design, | (5) >> quick to implement | >>------------------------------------+-------------------------------- >>(6) Registration already in IANA, | (6) >>------------------------------------+-------------------------------- >>(7) Supported and developed by 7 | (7) Supported and developed by >> companies and universities | Qualcomm >> (including Qualcomm) | >>------------------------------------+-------------------------------- >>(8) No IP related to this format | (8) IP situation unclear >>------------------------------------+-------------------------------- >> >>(*) ERVC and SMV are both vocoders developed and defined in the >>international consortium 3GPP2 (http://www.3gpp2.org) for the next >>generation wireless network cdma2000. >> >>Thank you very much. >> >>Adam >> >>PS. This is a resent of the previous message, which did not seem to go >>through maybe because of the long cc list. If you think anyone is missed >>out, please let me know. Thanks. >> >>> -----Original Message----- >>> From: Adam Li [mailto:adamli@icsl.ucla.edu] >>> Sent: Saturday, March 15, 2003 9:20 PM >>> To: 'Ietf-Avt' >>> Cc: 'casner@acm.org'; 'Scott Bradner'; 'Colin Perkins'; 'Allison >>> Mankin'; 'randy@qualcomm.com'; 'mccap@lucent.com'; >>> 'mdturner@lucent.com'; 'smathai@lucent.com'; 'lioy@qualcomm.com'; >>> 'zeng@packetvideo.com'; 'sherwood@packetvideo.com'; >>> 'villa@icsl.ucla.edu'; 'yllee@samsung.com'; 'jeonghoon@samsung.com'; >>> 'tom.hiller@lucent.com'; 'David.Leon@nokia.com'; >>> 'nleung@qualcomm.com'; 'dgal@lucent.com'; 'ajayrajkumar@lucent.com'; >>> 'Lars-Erik.Jonsson@epl.ericsson.se'; 'magnus.westerlund@era- >>> t.ericsson.se'; 'vbharga@cisco.com'; 'craig.greer@nokia.com'; >>> 'magda@qualcomm.com'; 'casner@acm.org'; 'ned.freed@mrochek.com'; >>> 'mankin@psg.com'; 'hgarudad@qualcomm.com'; 'csp@isi.edu'; >>> 'jlee@nextreaming.com'; 'sakazawa@kddilabs.jp'; 'tsgc@3gpp2.org' >>> Subject: Issues for the file format for EVRC/SMV vocoder >>> >>> Hi folks, >>> >>> The topic of the file format for EVRC/SMV vocoders hopefully will be >>> discussed in this meeting at San Francisco. Below is a list of the >>> issues that might be related to this topic. They are listed here as >>> potential issues for you to consider before the discussion at the >>> meeting. >>> >>> (1) Technically differences. Is there much difference in efficiency >>> and performance between the format in draft-ietf-avt-evrc-smv and >>> draft-garudadri-qcp? Are the differences simply on the file syntax? >>> >>> (2) Completeness. For EVRC codec data, formats defined in both >>> document can handle it. For SMV codec data, the format defined in >>> draft-ietf-avt-evrc-smv is currently the only file format that >>> handles SMV data. draft-garudadri-qcp does not handle SMV at this >>> time. >>> >>> (3) Maturity of the format definition. draft-ietf-avt-evrc-smv has >>> its first version submitted to AVT on November 2000. It has been >>> actively worked on all these years, and is co-authored by people >>> from seven companies and universities. It is currently on the RFC >>> editor's queue. draft-garudadri-qcp is submitted in February 2003. >>> Will there be concerns about the maturity of the drafts, >>> particularly the handling of SMV codec hasn't been written in the >>> later draft yet? >>> >>> (4) The recognition. Since EVRC and SMV codec are designed in 3GPP2 >>> for their CDMA networks, formats recognized by them are likely to be >>> the most widely used format for those codecs. Which of the formats, >>> as defined in draft-ietf-avt-evrc-smv and draft-garudadri-qcp, has >>> been considered by 3GPP2 for the format for storing EVRC and SMV >>> data? >>> >>> (5) Document organization. Even though this is a rather minor point, >>> but would there be enough reasons to trade-off for the additional >>> complexity for having the MIME registration of EVRC/SMV refering to >>> a separate and yet to be complete draft? >>> >>> Draft-ietf-avt-evrc-smv is currently on the RFC editor's queue. If >>> we want to consider deleting the file format that is in the draft >>> for almost two years in the last minute before it becomes an RFC and >>> using another yet to be complete new draft instead, we should be >>> providing ourselves with the clear justification for doing so. >> >>> I will not be there for the discussion unfortunately since I have >>> not made the plan to attend in advance. However, I hope the list of >>> potential issues above might be useful for us to discuss and >>> consider. >>> >>> Wish we have a fruitful meeting in San Francisco. >>> >>> Adam >> >> >>_______________________________________________ >>Audio/Video Transport Working Group >>avt@ietf.org >>https://www1.ietf.org/mailman/listinfo/avt >_______________________________________________ >Audio/Video Transport Working Group >avt@ietf.org >https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Apr 23 02:47:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05749 for ; Wed, 23 Apr 2003 02:47:10 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3N6x4t28606 for avt-archive@odin.ietf.org; Wed, 23 Apr 2003 02:59:04 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N6w3828526; Wed, 23 Apr 2003 02:58:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N6tH828413 for ; Wed, 23 Apr 2003 02:55:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05657 for ; Wed, 23 Apr 2003 02:42:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198E0H-0000lq-00 for avt@ietf.org; Wed, 23 Apr 2003 02:45:13 -0400 Received: from hyervision.com ([66.159.193.111] helo=server.hyervision.com) by ietf-mx with esmtp (Exim 4.12) id 198E0F-0000lk-00 for avt@ietf.org; Wed, 23 Apr 2003 02:45:12 -0400 Received: from WIND (hyervision.com [66.159.193.111]) by server.hyervision.com (8.12.6/8.12.6) with ESMTP id h3N6adeH002581; Tue, 22 Apr 2003 23:36:40 -0700 (PDT) From: "Adam Li" To: "'Colin Perkins'" Cc: , "'Scott Bradner'" , "'Allison Mankin'" , , , , Subject: RE: [AVT] The storage format of EVRC/SMV vocoder (resent) Date: Tue, 22 Apr 2003 23:45:12 -0700 Organization: UCLA Message-ID: <000b01c30963$e88ccde0$657ba8c0@divxnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <200304221727.h3MHRNGt057310@purple.nge.isi.edu> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3N6tI828414 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Dear Colin, Thank you very much for your email. We all have agreed on the fact that .QCP is used by Eudora while .EVC/.SMV are used by 3G service providers. However, I have difficulty seeing the rationale for your opinion that the registration of .QCP is clearly needed while the registration of .EVC/.SMV is the opposite. Would you mind explain to us AVT'ers your rationales and pointing out the factors that we missed in the discussion so we can better understand your opinions? With all the factors that have been expressed on this issue which are summarized in the previous email, it does not seem that the major consensus is inclining that way. Maybe we missed something? Your opinion is very much appreciated. Adam > -----Original Message----- > From: avt-admin@ietf.org [mailto:avt-admin@ietf.org] On Behalf Of > Colin Perkins > Sent: Tuesday, April 22, 2003 10:27 AM > To: Adam Li > Cc: avt@ietf.org; 'Scott Bradner'; 'Allison Mankin'; > craig.greer@nokia.com; jlee@nextreaming.com; sakazawa@kddilabs.jp; > keith.miller@nokia.com > Subject: Re: [AVT] The storage format of EVRC/SMV vocoder (resent) > > Adam, > > The format specified in draft-garudadri-qcp-00.txt clearly needs to > be > published, and to have a MIME type registered, since it has been > used by > several applications for some years now. > > What is unclear is whether draft-ieft-avt-evrc-smv-03.txt should > refer to > that format, or if it should continue to use the alternative format. > The > usual arguments apply: having two formats is clearly worse than one, > but > there may be technical or political reasons why the new format is to > be > preferred for some uses. > > As the minutes from the recent AVT meeting note, the main users of > the > format in draft-ieft-avt-evrc-smv-03.txt seem to be 3GPP2. It is > currently > unclear if they have implementations of the file format, and if they > chose > it for technical reasons or because it it was the only format they > knew. We > are hoping to get input from them, to clarify their position. > > Colin > > > > > --> "Adam Li" writes: > > > >The issue of the storage format of the EVRC and SMV vocoders in the > MIME > >registration has came up a while ago, and has caused the last > minute > >holding of the MIME registration for these two vocoders. The issue > has > >been discussed thoroughly here on the mailing list in the San > Francisco > >meeting. The reasons of each side of the argument have been well > >presented. Now it may be time to make a decision? > > > >Like many other issues in our AVT WG, the decision here is > ultimately > >relying on the judgment of our chairs. During the two and half > years > >that this draft is being developed in the AVT, the course of the > draft > >has benefited greatly from your guidance. After the open and ego- > free > >discuss that our chairs called upon at the meeting session, it may > be > >another good time to hear the opinions from the chairs and get some > help > >on the decision from their experience and vision on which one will > >reflect the consensus of the AVT and would be most beneficial to > the > >whole Internet and telecom industry who will use our specification. > > > >Below is the summary of the rationales for each of the choices: > > > > draft-ieft-avt-evrc-smv-03.txt | draft-garudadri-qcp-00.txt > >------------------------------------+------------------------------ > -- > >(1) Mature specification, been | (1) Brand new ID > > developed for 2.5 years in AVT | > >------------------------------------+------------------------------ > -- > >(2) Covers both EVRC and SMV | (2) Only cover EVRC > >------------------------------------+------------------------------ > -- > >(3) Referred to by 3GPP2(*) FFMS | (3) > > specifications | > >------------------------------------+------------------------------ > -- > >(4) Implemented and used by many 3G | (4) Supported in Eudora > > telecom operators (e.g., SKT, | > > KTF, LGT). The interoperability | > > has been tested among them. | > >------------------------------------+------------------------------ > -- > >(5) Simple and efficient design, | (5) > > quick to implement | > >------------------------------------+------------------------------ > -- > >(6) Registration already in IANA, | (6) > >------------------------------------+------------------------------ > -- > >(7) Supported and developed by 7 | (7) Supported and developed > by > > companies and universities | Qualcomm > > (including Qualcomm) | > >------------------------------------+------------------------------ > -- > >(8) No IP related to this format | (8) IP situation unclear > >------------------------------------+------------------------------ > -- > > > >(*) ERVC and SMV are both vocoders developed and defined in the > >international consortium 3GPP2 (http://www.3gpp2.org) for the next > >generation wireless network cdma2000. > > > >Thank you very much. > > > >Adam > > > >PS. This is a resent of the previous message, which did not seem to > go > >through maybe because of the long cc list. If you think anyone is > missed > >out, please let me know. Thanks. > > > >> -----Original Message----- > >> From: Adam Li [mailto:adamli@icsl.ucla.edu] > >> Sent: Saturday, March 15, 2003 9:20 PM > >> To: 'Ietf-Avt' > >> Cc: 'casner@acm.org'; 'Scott Bradner'; 'Colin Perkins'; 'Allison > >> Mankin'; 'randy@qualcomm.com'; 'mccap@lucent.com'; > >> 'mdturner@lucent.com'; 'smathai@lucent.com'; 'lioy@qualcomm.com'; > >> 'zeng@packetvideo.com'; 'sherwood@packetvideo.com'; > >> 'villa@icsl.ucla.edu'; 'yllee@samsung.com'; > 'jeonghoon@samsung.com'; > >> 'tom.hiller@lucent.com'; 'David.Leon@nokia.com'; > >> 'nleung@qualcomm.com'; 'dgal@lucent.com'; > 'ajayrajkumar@lucent.com'; > >> 'Lars-Erik.Jonsson@epl.ericsson.se'; 'magnus.westerlund@era- > >> t.ericsson.se'; 'vbharga@cisco.com'; 'craig.greer@nokia.com'; > >> 'magda@qualcomm.com'; 'casner@acm.org'; 'ned.freed@mrochek.com'; > >> 'mankin@psg.com'; 'hgarudad@qualcomm.com'; 'csp@isi.edu'; > >> 'jlee@nextreaming.com'; 'sakazawa@kddilabs.jp'; 'tsgc@3gpp2.org' > >> Subject: Issues for the file format for EVRC/SMV vocoder > >> > >> Hi folks, > >> > >> The topic of the file format for EVRC/SMV vocoders hopefully will > be > >> discussed in this meeting at San Francisco. Below is a list of > the > >> issues that might be related to this topic. They are listed here > as > >> potential issues for you to consider before the discussion at the > >> meeting. > >> > >> (1) Technically differences. Is there much difference in > efficiency > >> and performance between the format in draft-ietf-avt-evrc-smv and > >> draft-garudadri-qcp? Are the differences simply on the file > syntax? > >> > >> (2) Completeness. For EVRC codec data, formats defined in both > >> document can handle it. For SMV codec data, the format defined in > >> draft-ietf-avt-evrc-smv is currently the only file format that > >> handles SMV data. draft-garudadri-qcp does not handle SMV at this > >> time. > >> > >> (3) Maturity of the format definition. draft-ietf-avt-evrc-smv > has > >> its first version submitted to AVT on November 2000. It has been > >> actively worked on all these years, and is co-authored by people > >> from seven companies and universities. It is currently on the RFC > >> editor's queue. draft-garudadri-qcp is submitted in February 2003. > >> Will there be concerns about the maturity of the drafts, > >> particularly the handling of SMV codec hasn't been written in the > >> later draft yet? > >> > >> (4) The recognition. Since EVRC and SMV codec are designed in > 3GPP2 > >> for their CDMA networks, formats recognized by them are likely to > be > >> the most widely used format for those codecs. Which of the > formats, > >> as defined in draft-ietf-avt-evrc-smv and draft-garudadri-qcp, > has > >> been considered by 3GPP2 for the format for storing EVRC and SMV > >> data? > >> > >> (5) Document organization. Even though this is a rather minor > point, > >> but would there be enough reasons to trade-off for the additional > >> complexity for having the MIME registration of EVRC/SMV refering > to > >> a separate and yet to be complete draft? > >> > >> Draft-ietf-avt-evrc-smv is currently on the RFC editor's queue. > If > >> we want to consider deleting the file format that is in the draft > >> for almost two years in the last minute before it becomes an RFC > and > >> using another yet to be complete new draft instead, we should be > >> providing ourselves with the clear justification for doing so. > > > >> I will not be there for the discussion unfortunately since I have > >> not made the plan to attend in advance. However, I hope the list > of > >> potential issues above might be useful for us to discuss and > >> consider. > >> > >> Wish we have a fruitful meeting in San Francisco. > >> > >> Adam > > > > > >_______________________________________________ > >Audio/Video Transport Working Group > >avt@ietf.org > >https://www1.ietf.org/mailman/listinfo/avt > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Apr 23 09:53:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18589 for ; Wed, 23 Apr 2003 09:53:12 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3NE5G226895 for avt-archive@odin.ietf.org; Wed, 23 Apr 2003 10:05:16 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NE4d826836; Wed, 23 Apr 2003 10:04:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NE3Q826761 for ; Wed, 23 Apr 2003 10:03:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18460 for ; Wed, 23 Apr 2003 09:50:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198KgS-0003we-00 for avt@ietf.org; Wed, 23 Apr 2003 09:53:12 -0400 Received: from wireless228.east.isi.edu ([65.123.202.228] helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 198KgS-0003wb-00 for avt@ietf.org; Wed, 23 Apr 2003 09:53:12 -0400 Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with ESMTP id h3NDqHGt070574; Wed, 23 Apr 2003 09:52:17 -0400 (EDT) (envelope-from csp@purple.nge.isi.edu) Message-Id: <200304231352.h3NDqHGt070574@purple.nge.isi.edu> To: "Adam Li" cc: avt@ietf.org, "'Scott Bradner'" , "'Allison Mankin'" , craig.greer@nokia.com, jlee@nextreaming.com, sakazawa@kddilabs.jp, keith.miller@nokia.com Subject: Re: [AVT] The storage format of EVRC/SMV vocoder (resent) In-Reply-To: Your message of "Tue, 22 Apr 2003 23:45:12 PDT." <000b01c30963$e88ccde0$657ba8c0@divxnetworks.com> Date: Wed, 23 Apr 2003 09:52:17 -0400 From: Colin Perkins Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Adam, My understanding is that there have been implementations of the QCP format for several years now, but the MIME type has not been registered. The MIME type should be registered, to document this use. This is independent of whether the EVRC/SMV file format is also registered. Colin --> "Adam Li" writes: >Dear Colin, > >Thank you very much for your email. We all have agreed on the fact that >.QCP is used by Eudora while .EVC/.SMV are used by 3G service providers. > >However, I have difficulty seeing the rationale for your opinion that >the registration of .QCP is clearly needed while the registration of >.EVC/.SMV is the opposite. Would you mind explain to us AVT'ers your >rationales and pointing out the factors that we missed in the discussion >so we can better understand your opinions? > >With all the factors that have been expressed on this issue which are >summarized in the previous email, it does not seem that the major >consensus is inclining that way. Maybe we missed something? > >Your opinion is very much appreciated. > >Adam > > >> -----Original Message----- >> From: avt-admin@ietf.org [mailto:avt-admin@ietf.org] On Behalf Of >> Colin Perkins >> Sent: Tuesday, April 22, 2003 10:27 AM >> To: Adam Li >> Cc: avt@ietf.org; 'Scott Bradner'; 'Allison Mankin'; >> craig.greer@nokia.com; jlee@nextreaming.com; sakazawa@kddilabs.jp; >> keith.miller@nokia.com >> Subject: Re: [AVT] The storage format of EVRC/SMV vocoder (resent) >> >> Adam, >> >> The format specified in draft-garudadri-qcp-00.txt clearly needs to >> be >> published, and to have a MIME type registered, since it has been >> used by >> several applications for some years now. >> >> What is unclear is whether draft-ieft-avt-evrc-smv-03.txt should >> refer to >> that format, or if it should continue to use the alternative format. >> The >> usual arguments apply: having two formats is clearly worse than one, >> but >> there may be technical or political reasons why the new format is to >> be >> preferred for some uses. >> >> As the minutes from the recent AVT meeting note, the main users of >> the >> format in draft-ieft-avt-evrc-smv-03.txt seem to be 3GPP2. It is >> currently >> unclear if they have implementations of the file format, and if they >> chose >> it for technical reasons or because it it was the only format they >> knew. We >> are hoping to get input from them, to clarify their position. >> >> Colin >> >> >> >> >> --> "Adam Li" writes: >> > >> >The issue of the storage format of the EVRC and SMV vocoders in the >> MIME >> >registration has came up a while ago, and has caused the last >> minute >> >holding of the MIME registration for these two vocoders. The issue >> has >> >been discussed thoroughly here on the mailing list in the San >> Francisco >> >meeting. The reasons of each side of the argument have been well >> >presented. Now it may be time to make a decision? >> > >> >Like many other issues in our AVT WG, the decision here is >> ultimately >> >relying on the judgment of our chairs. During the two and half >> years >> >that this draft is being developed in the AVT, the course of the >> draft >> >has benefited greatly from your guidance. After the open and ego- >> free >> >discuss that our chairs called upon at the meeting session, it may >> be >> >another good time to hear the opinions from the chairs and get some >> help >> >on the decision from their experience and vision on which one will >> >reflect the consensus of the AVT and would be most beneficial to >> the >> >whole Internet and telecom industry who will use our specification. >> > >> >Below is the summary of the rationales for each of the choices: >> > >> > draft-ieft-avt-evrc-smv-03.txt | draft-garudadri-qcp-00.txt >> >------------------------------------+------------------------------ >> -- >> >(1) Mature specification, been | (1) Brand new ID >> > developed for 2.5 years in AVT | >> >------------------------------------+------------------------------ >> -- >> >(2) Covers both EVRC and SMV | (2) Only cover EVRC >> >------------------------------------+------------------------------ >> -- >> >(3) Referred to by 3GPP2(*) FFMS | (3) >> > specifications | >> >------------------------------------+------------------------------ >> -- >> >(4) Implemented and used by many 3G | (4) Supported in Eudora >> > telecom operators (e.g., SKT, | >> > KTF, LGT). The interoperability | >> > has been tested among them. | >> >------------------------------------+------------------------------ >> -- >> >(5) Simple and efficient design, | (5) >> > quick to implement | >> >------------------------------------+------------------------------ >> -- >> >(6) Registration already in IANA, | (6) >> >------------------------------------+------------------------------ >> -- >> >(7) Supported and developed by 7 | (7) Supported and developed >> by >> > companies and universities | Qualcomm >> > (including Qualcomm) | >> >------------------------------------+------------------------------ >> -- >> >(8) No IP related to this format | (8) IP situation unclear >> >------------------------------------+------------------------------ >> -- >> > >> >(*) ERVC and SMV are both vocoders developed and defined in the >> >international consortium 3GPP2 (http://www.3gpp2.org) for the next >> >generation wireless network cdma2000. >> > >> >Thank you very much. >> > >> >Adam >> > >> >PS. This is a resent of the previous message, which did not seem to >> go >> >through maybe because of the long cc list. If you think anyone is >> missed >> >out, please let me know. Thanks. >> > >> >> -----Original Message----- >> >> From: Adam Li [mailto:adamli@icsl.ucla.edu] >> >> Sent: Saturday, March 15, 2003 9:20 PM >> >> To: 'Ietf-Avt' >> >> Cc: 'casner@acm.org'; 'Scott Bradner'; 'Colin Perkins'; 'Allison >> >> Mankin'; 'randy@qualcomm.com'; 'mccap@lucent.com'; >> >> 'mdturner@lucent.com'; 'smathai@lucent.com'; 'lioy@qualcomm.com'; >> >> 'zeng@packetvideo.com'; 'sherwood@packetvideo.com'; >> >> 'villa@icsl.ucla.edu'; 'yllee@samsung.com'; >> 'jeonghoon@samsung.com'; >> >> 'tom.hiller@lucent.com'; 'David.Leon@nokia.com'; >> >> 'nleung@qualcomm.com'; 'dgal@lucent.com'; >> 'ajayrajkumar@lucent.com'; >> >> 'Lars-Erik.Jonsson@epl.ericsson.se'; 'magnus.westerlund@era- >> >> t.ericsson.se'; 'vbharga@cisco.com'; 'craig.greer@nokia.com'; >> >> 'magda@qualcomm.com'; 'casner@acm.org'; 'ned.freed@mrochek.com'; >> >> 'mankin@psg.com'; 'hgarudad@qualcomm.com'; 'csp@isi.edu'; >> >> 'jlee@nextreaming.com'; 'sakazawa@kddilabs.jp'; 'tsgc@3gpp2.org' >> >> Subject: Issues for the file format for EVRC/SMV vocoder >> >> >> >> Hi folks, >> >> >> >> The topic of the file format for EVRC/SMV vocoders hopefully will >> be >> >> discussed in this meeting at San Francisco. Below is a list of >> the >> >> issues that might be related to this topic. They are listed here >> as >> >> potential issues for you to consider before the discussion at the >> >> meeting. >> >> >> >> (1) Technically differences. Is there much difference in >> efficiency >> >> and performance between the format in draft-ietf-avt-evrc-smv and >> >> draft-garudadri-qcp? Are the differences simply on the file >> syntax? >> >> >> >> (2) Completeness. For EVRC codec data, formats defined in both >> >> document can handle it. For SMV codec data, the format defined in >> >> draft-ietf-avt-evrc-smv is currently the only file format that >> >> handles SMV data. draft-garudadri-qcp does not handle SMV at this >> >> time. >> >> >> >> (3) Maturity of the format definition. draft-ietf-avt-evrc-smv >> has >> >> its first version submitted to AVT on November 2000. It has been >> >> actively worked on all these years, and is co-authored by people >> >> from seven companies and universities. It is currently on the RFC >> >> editor's queue. draft-garudadri-qcp is submitted in February 2003. >> >> Will there be concerns about the maturity of the drafts, >> >> particularly the handling of SMV codec hasn't been written in the >> >> later draft yet? >> >> >> >> (4) The recognition. Since EVRC and SMV codec are designed in >> 3GPP2 >> >> for their CDMA networks, formats recognized by them are likely to >> be >> >> the most widely used format for those codecs. Which of the >> formats, >> >> as defined in draft-ietf-avt-evrc-smv and draft-garudadri-qcp, >> has >> >> been considered by 3GPP2 for the format for storing EVRC and SMV >> >> data? >> >> >> >> (5) Document organization. Even though this is a rather minor >> point, >> >> but would there be enough reasons to trade-off for the additional >> >> complexity for having the MIME registration of EVRC/SMV refering >> to >> >> a separate and yet to be complete draft? >> >> >> >> Draft-ietf-avt-evrc-smv is currently on the RFC editor's queue. >> If >> >> we want to consider deleting the file format that is in the draft >> >> for almost two years in the last minute before it becomes an RFC >> and >> >> using another yet to be complete new draft instead, we should be >> >> providing ourselves with the clear justification for doing so. >> > >> >> I will not be there for the discussion unfortunately since I have >> >> not made the plan to attend in advance. However, I hope the list >> of >> >> potential issues above might be useful for us to discuss and >> >> consider. >> >> >> >> Wish we have a fruitful meeting in San Francisco. >> >> >> >> Adam >> > >> > >> >_______________________________________________ >> >Audio/Video Transport Working Group >> >avt@ietf.org >> >https://www1.ietf.org/mailman/listinfo/avt >> _______________________________________________ >> Audio/Video Transport Working Group >> avt@ietf.org >> https://www1.ietf.org/mailman/listinfo/avt > >_______________________________________________ >Audio/Video Transport Working Group >avt@ietf.org >https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Apr 23 16:37:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05836 for ; Wed, 23 Apr 2003 16:37:36 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3NKdsk29532 for avt-archive@odin.ietf.org; Wed, 23 Apr 2003 16:39:54 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NKd0829497; Wed, 23 Apr 2003 16:39:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NKbh829321 for ; Wed, 23 Apr 2003 16:37:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05764 for ; Wed, 23 Apr 2003 16:34:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198QzU-0007GF-00 for avt@ietf.org; Wed, 23 Apr 2003 16:37:16 -0400 Received: from ns.live.com ([66.80.62.34]) by ietf-mx with esmtp (Exim 4.12) id 198QzT-0007GC-00 for avt@ietf.org; Wed, 23 Apr 2003 16:37:15 -0400 Received: from ns.live.com (localhost.live.com [127.0.0.1]) by ns.live.com (8.12.9/8.12.5) with ESMTP id h3NKbeRG084895 for ; Wed, 23 Apr 2003 13:37:40 -0700 (PDT) (envelope-from rsf@ns.live.com) Received: (from rsf@localhost) by ns.live.com (8.12.9/8.12.3/Submit) id h3NKbeV0084894; Wed, 23 Apr 2003 13:37:40 -0700 (PDT) Message-Id: <4.3.1.1.20030423133004.00c5bb60@laptop-localhost> X-Sender: rsf@laptop-localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 23 Apr 2003 13:32:40 -0700 To: avt@ietf.org From: Ross Finlayson Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [AVT] Minor formatting nit in draft-ietf-avt-profile-new-13.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Section "6 Payload Type Definitions" refers to Tables 4 and 5. However, those tables actually appear in the middle of the following section: "7 RTP over TCP and Similar Byte Stream Protocols". Confusing... Ross. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Apr 23 18:37:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12156 for ; Wed, 23 Apr 2003 18:37:02 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3NMdLq06018 for avt-archive@odin.ietf.org; Wed, 23 Apr 2003 18:39:21 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NMcU805966; Wed, 23 Apr 2003 18:38:30 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NMY0805013 for ; Wed, 23 Apr 2003 18:34:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12071 for ; Wed, 23 Apr 2003 18:31:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198Sny-0000V0-00 for avt@ietf.org; Wed, 23 Apr 2003 18:33:30 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx with esmtp (Exim 4.12) id 198Snx-0000Ux-00 for avt@ietf.org; Wed, 23 Apr 2003 18:33:29 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h3NMU67t029775 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 23 Apr 2003 15:30:06 -0700 (PDT) Received: from [129.46.74.134] (loud.qualcomm.com [129.46.74.134]) by magus.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h3NMTwhg017487; Wed, 23 Apr 2003 15:29:58 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <000801c308a1$345d6a40$657ba8c0@divxnetworks.com> References: <000801c308a1$345d6a40$657ba8c0@divxnetworks.com> X-Mailer: Eudora for Mac OS X v6.0a Date: Wed, 23 Apr 2003 15:29:55 -0700 To: "Adam Li" , From: Randall Gellens Subject: Re: [AVT] The storage format of EVRC/SMV vocoder (resent) Cc: "'Scott Bradner'" , "'Allison Mankin'" , , , , Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b25 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , At 12:31 AM -0700 4/22/03, Adam Li wrote: > Below is the summary of the rationales for each of the choices: > > draft-ieft-avt-evrc-smv-03.txt | draft-garudadri-qcp-00.txt > ------------------------------------+-------------------------------- > (1) Mature specification, been | (1) Brand new ID > developed for 2.5 years in AVT | I'm not sure it makes sense to call a specification "mature" based on the amount of time between inception and standardization. That is, I believe "mature" refers to the amount of time multiple interoperating implementations have been deployed. I also do not believe it is accurate to imply that the qcp format is not mature simply because the Internet Draft is new. In reality, the specification has been available for some years now, and there are a number of implementations which do interoperate. > ------------------------------------+-------------------------------- > (2) Covers both EVRC and SMV | (2) Only cover EVRC The qcp format covers QCELP 13K as well as EVRC. An updated version covers SMV as well. > ------------------------------------+-------------------------------- > (3) Referred to by 3GPP2(*) FFMS | (3) > specifications | My understanding is that the 3GPP2 FFMS specifications refer to both (it is waiting on RFC publications for both). > ------------------------------------+-------------------------------- > (4) Implemented and used by many 3G | (4) Supported in Eudora > telecom operators (e.g., SKT, | > KTF, LGT). The interoperability | > has been tested among them. | The qcp format is supported by PureVoice and QuickTime, both available on Windows and Macs. Also, a large number of CDMA handsets deployed today create and play qcp files and use this to interoperate. A number of services and tools on the web use the qcp format (often calling it PureVoice). My information on the implementation of the evrc-smv draft's format is that Nextreaming uses this as an internal intermediate format prior to generating ".3g2" files (as specified in the 3GPP2 FFMS specification, which include both formats). That is, my understanding is that this implementation is not used to exchange data. If my understanding is not correct, please let me know. Can you please provide more information on the telecom operators (e.g., SKT, KTF, LGT) implementations that you refer to, and if these implementations are used to exchange data in the format specified in the evrc-smv draft? > ------------------------------------+-------------------------------- > (5) Simple and efficient design, | (5) > quick to implement | The text in the qcp draft is more confusing than it should be. An updated version is about to be published which replaces the pseudo-C description with clear ABNF, showing that the two formats are actually very close. In essence, the qcp format is the same as the evrc-smv format, except that some additional data is present at the start of the file. But in both formats, individual vocoder frames are stored with a preceding byte which describes the frame size. > ------------------------------------+-------------------------------- > (6) Registration already in IANA, | (6) > ------------------------------------+-------------------------------- > (7) Supported and developed by 7 | (7) Supported and developed by > companies and universities | Qualcomm > (including Qualcomm) | The qcp format is supported/implemented by QuickTime, PureVoice, and numerous handset vendors and operators, plus a number of web services. > ------------------------------------+-------------------------------- > (8) No IP related to this format | (8) IP situation unclear There is no IP associated with the the qcp format. (The draft includes an explicit statement that it is in full compliance with all provisions of Section 10 of RFC2026.) > ------------------------------------+-------------------------------- > > (*) ERVC and SMV are both vocoders developed and defined in the > international consortium 3GPP2 (http://www.3gpp2.org) for the next > generation wireless network cdma2000. > > Thank you very much. > > Adam > > PS. This is a resent of the previous message, which did not seem to go > through maybe because of the long cc list. If you think anyone is missed > out, please let me know. Thanks. > >> -----Original Message----- >> From: Adam Li [mailto:adamli@icsl.ucla.edu] >> Sent: Saturday, March 15, 2003 9:20 PM >> To: 'Ietf-Avt' >> Cc: 'casner@acm.org'; 'Scott Bradner'; 'Colin Perkins'; 'Allison >> Mankin'; 'randy@qualcomm.com'; 'mccap@lucent.com'; >> 'mdturner@lucent.com'; 'smathai@lucent.com'; 'lioy@qualcomm.com'; >> 'zeng@packetvideo.com'; 'sherwood@packetvideo.com'; >> 'villa@icsl.ucla.edu'; 'yllee@samsung.com'; 'jeonghoon@samsung.com'; >> 'tom.hiller@lucent.com'; 'David.Leon@nokia.com'; >> 'nleung@qualcomm.com'; 'dgal@lucent.com'; 'ajayrajkumar@lucent.com'; >> 'Lars-Erik.Jonsson@epl.ericsson.se'; 'magnus.westerlund@era- >> t.ericsson.se'; 'vbharga@cisco.com'; 'craig.greer@nokia.com'; >> 'magda@qualcomm.com'; 'casner@acm.org'; 'ned.freed@mrochek.com'; >> 'mankin@psg.com'; 'hgarudad@qualcomm.com'; 'csp@isi.edu'; >> 'jlee@nextreaming.com'; 'sakazawa@kddilabs.jp'; 'tsgc@3gpp2.org' >> Subject: Issues for the file format for EVRC/SMV vocoder >> >> Hi folks, >> >> The topic of the file format for EVRC/SMV vocoders hopefully will be >> discussed in this meeting at San Francisco. Below is a list of the >> issues that might be related to this topic. They are listed here as >> potential issues for you to consider before the discussion at the >> meeting. >> >> (1) Technically differences. Is there much difference in efficiency >> and performance between the format in draft-ietf-avt-evrc-smv and >> draft-garudadri-qcp? Are the differences simply on the file syntax? >> >> (2) Completeness. For EVRC codec data, formats defined in both >> document can handle it. For SMV codec data, the format defined in >> draft-ietf-avt-evrc-smv is currently the only file format that >> handles SMV data. draft-garudadri-qcp does not handle SMV at this >> time. >> >> (3) Maturity of the format definition. draft-ietf-avt-evrc-smv has >> its first version submitted to AVT on November 2000. It has been >> actively worked on all these years, and is co-authored by people >> from seven companies and universities. It is currently on the RFC >> editor's queue. draft-garudadri-qcp is submitted in February 2003. >> Will there be concerns about the maturity of the drafts, >> particularly the handling of SMV codec hasn't been written in the >> later draft yet? >> >> (4) The recognition. Since EVRC and SMV codec are designed in 3GPP2 >> for their CDMA networks, formats recognized by them are likely to be >> the most widely used format for those codecs. Which of the formats, >> as defined in draft-ietf-avt-evrc-smv and draft-garudadri-qcp, has >> been considered by 3GPP2 for the format for storing EVRC and SMV >> data? >> >> (5) Document organization. Even though this is a rather minor point, >> but would there be enough reasons to trade-off for the additional >> complexity for having the MIME registration of EVRC/SMV refering to >> a separate and yet to be complete draft? >> >> Draft-ietf-avt-evrc-smv is currently on the RFC editor's queue. If >> we want to consider deleting the file format that is in the draft >> for almost two years in the last minute before it becomes an RFC and >> using another yet to be complete new draft instead, we should be >> providing ourselves with the clear justification for doing so. >> >> I will not be there for the discussion unfortunately since I have >> not made the plan to attend in advance. However, I hope the list of >> potential issues above might be useful for us to discuss and >> consider. >> >> Wish we have a fruitful meeting in San Francisco. >> >> Adam > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Apr 23 18:39:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12245 for ; Wed, 23 Apr 2003 18:39:07 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3NMfQA06117 for avt-archive@odin.ietf.org; Wed, 23 Apr 2003 18:41:26 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NMep806094; Wed, 23 Apr 2003 18:40:51 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NMbH805422 for ; Wed, 23 Apr 2003 18:37:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12108 for ; Wed, 23 Apr 2003 18:34:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198Sr8-0000VU-00 for avt@ietf.org; Wed, 23 Apr 2003 18:36:46 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx with esmtp (Exim 4.12) id 198Sr8-0000VR-00 for avt@ietf.org; Wed, 23 Apr 2003 18:36:46 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h3NMXL7t029892 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 23 Apr 2003 15:33:22 -0700 (PDT) Received: from [129.46.74.134] (loud.qualcomm.com [129.46.74.134]) by sabrina.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h3NMXHtf012810; Wed, 23 Apr 2003 15:33:18 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <200304221804.h3MI4vGt058058@purple.nge.isi.edu> References: <200304221804.h3MI4vGt058058@purple.nge.isi.edu> X-Mailer: Eudora for Mac OS X v6.0a Date: Wed, 23 Apr 2003 15:33:15 -0700 To: Colin Perkins , keith.miller@nokia.com, Ned Freed From: Randall Gellens Subject: Re: [AVT] The storage format of EVRC/SMV vocoder (resent) Cc: adamli@icsl.ucla.edu, avt@ietf.org, sob@harvard.edu, mankin@psg.com, craig.greer@nokia.com, jlee@nextreaming.com, sakazawa@kddilabs.jp Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b25 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , At 2:04 PM -0400 4/22/03, Colin Perkins wrote: > Are there minutes of this meeting available? I'd like to understand the > rationale behind the choice (especially the choice of changing the MIME > type, since "audio/qcp" seems appropriate). Regarding the MIME type, "audio/qcp" was the initial suggested MIME type, but there was pushback based on the principle that MIME types should describe the content, not the format. In general, neglect of this principle reduces interoperability, since it then means that an implementation that supports a certain MIME type may not be able to handle content received in that MIME type. So, in accordance with the principle, it makes sense to use "audio/qcelp" for QCELP 13K data in this format, "audio/evrc-qcp" for EVRC data stored in the QCP format, and "audio/smv-qcp" for SMV data in the QCP format. I suppose "audio/qcelp" plus "audio/qcp" with a mandatory parameter for the codec included, which could only be SMV or EVRC, not QCELP, could also work. I've added Ned Freed to the distribution list to get his views, as the IANA-designated MIME expert. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Apr 23 18:41:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12338 for ; Wed, 23 Apr 2003 18:41:04 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3NMhMG06237 for avt-archive@odin.ietf.org; Wed, 23 Apr 2003 18:43:22 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NMgq806204; Wed, 23 Apr 2003 18:42:52 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NMdH806014 for ; Wed, 23 Apr 2003 18:39:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12149 for ; Wed, 23 Apr 2003 18:36:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198St5-0000Vj-00 for avt@ietf.org; Wed, 23 Apr 2003 18:38:47 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx with esmtp (Exim 4.12) id 198St4-0000Vg-00 for avt@ietf.org; Wed, 23 Apr 2003 18:38:46 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h3NMZEJo020842; Wed, 23 Apr 2003 15:35:14 -0700 (PDT) Received: from [129.46.74.134] (loud.qualcomm.com [129.46.74.134]) by sabrina.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h3NMZ8tf013133; Wed, 23 Apr 2003 15:35:10 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <000b01c30963$e88ccde0$657ba8c0@divxnetworks.com> References: <000b01c30963$e88ccde0$657ba8c0@divxnetworks.com> X-Mailer: Eudora for Mac OS X v6.0a Date: Wed, 23 Apr 2003 15:33:49 -0700 To: "Adam Li" , "'Colin Perkins'" From: Randall Gellens Subject: RE: [AVT] The storage format of EVRC/SMV vocoder (resent) Cc: , "'Scott Bradner'" , "'Allison Mankin'" , , , , Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b25 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , At 11:45 PM -0700 4/22/03, Adam Li wrote: > We all have agreed on the fact that > .QCP is used by Eudora while .EVC/.SMV are used by 3G service providers. This isn't accurate. As I noted in my earlier message to the list, the QCP format is used by QuickTime and PureVoice, as well as a large number of CDMA handsets, and a number of web services. (Please see my earlier message for more detailed comments.) -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Misery loves company, but company does not reciprocate. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Apr 23 21:58:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17992 for ; Wed, 23 Apr 2003 21:58:51 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3O21En17998 for avt-archive@odin.ietf.org; Wed, 23 Apr 2003 22:01:14 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3O20A817921; Wed, 23 Apr 2003 22:00:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3O1vO817816 for ; Wed, 23 Apr 2003 21:57:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17787 for ; Wed, 23 Apr 2003 21:54:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198Vyk-0001tf-00 for avt@ietf.org; Wed, 23 Apr 2003 21:56:50 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx with esmtp (Exim 4.12) id 198Vyj-0001tc-00 for avt@ietf.org; Wed, 23 Apr 2003 21:56:49 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h3O1rOJo029202; Wed, 23 Apr 2003 18:53:25 -0700 (PDT) Received: from [129.46.74.134] (vpn-10-50-0-43.qualcomm.com [10.50.0.43]) by magus.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h3O1rChg021831; Wed, 23 Apr 2003 18:53:16 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <8146199999A6384A8231B07B6E51D0BB10B3C5@daebe003.americas.nokia.com> References: <8146199999A6384A8231B07B6E51D0BB10B3C5@daebe003.americas.nokia.com> X-Mailer: Eudora for Mac OS X v6.0a Date: Wed, 23 Apr 2003 18:50:01 -0700 To: keith.miller@nokia.com, , From: Randall Gellens Subject: RE: [AVT] The storage format of EVRC/SMV vocoder (resent) Cc: , , , , , Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b25 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , At 12:38 PM -0500 4/22/03, keith.miller@nokia.com wrote: > This issue was discussed at the last 3GPP2 (April 14-18) meeting by > the group developing the 3GPP2 > file format specification. It was decided that both formats should > be published, but > that Qualcomm would request a different MIME type for the EVRC > storage in .QCP > (maybe EVRC_QCP). Hari Garudadri is expected to submit an updated > draft for ".QCP". Of course we need Qualcomm to verify this. Yes, this was the agreed resolution; an updated qcp draft will be published. See my earlier message to the list for the MIME type discussion. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- I make a fortune from criticizing the policy of the government, and then hand it over to the government in taxes to keep it going. --George Bernard Shaw _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Apr 24 01:14:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23575 for ; Thu, 24 Apr 2003 01:14:35 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3O5H2r30494 for avt-archive@odin.ietf.org; Thu, 24 Apr 2003 01:17:02 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3O5Eq830327; Thu, 24 Apr 2003 01:14:52 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NNXY808852 for ; Wed, 23 Apr 2003 19:33:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14281 for ; Wed, 23 Apr 2003 19:30:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198Tja-00010L-00 for avt@ietf.org; Wed, 23 Apr 2003 19:33:02 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx with esmtp (Exim 4.12) id 198Tja-00010I-00 for avt@ietf.org; Wed, 23 Apr 2003 19:33:02 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h3NNXP7t002947 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 23 Apr 2003 16:33:26 -0700 (PDT) Received: from san.rr.com (ramin.qualcomm.com [129.46.73.69]) by neophyte.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h3NNXOjp027216 for ; Wed, 23 Apr 2003 16:33:24 -0700 (PDT) Message-ID: <3EA7227B.8010902@san.rr.com> Date: Wed, 23 Apr 2003 16:32:11 -0700 From: ramin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030419 X-Accept-Language: en-us, en MIME-Version: 1.0 To: avt@ietf.org Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] RTP timestamp Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit
Assuming that both sender and receiver have access to accurate time, is there any reason not to let the RTP timestamp reflect the real time (w/ the resolution specified in the profile and with a start time agreed upon by both sender and receiver)? 

Thank you,

-Ramin
 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Apr 24 04:35:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08237 for ; Thu, 24 Apr 2003 04:35:49 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3O8cLX23098 for avt-archive@odin.ietf.org; Thu, 24 Apr 2003 04:38:21 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3O8bg822975; Thu, 24 Apr 2003 04:37:42 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3O8Z2822106 for ; Thu, 24 Apr 2003 04:35:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08141 for ; Thu, 24 Apr 2003 04:32:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198cBP-0003pr-00 for avt@ietf.org; Thu, 24 Apr 2003 04:34:19 -0400 Received: from hyervision.com ([66.159.193.111] helo=server.hyervision.com) by ietf-mx with esmtp (Exim 4.12) id 198cBO-0003po-00 for avt@ietf.org; Thu, 24 Apr 2003 04:34:18 -0400 Received: from WIND (hyervision.com [66.159.193.111]) by server.hyervision.com (8.12.6/8.12.6) with ESMTP id h3O8PZeH016226; Thu, 24 Apr 2003 01:25:36 -0700 (PDT) From: "Adam Li" To: "'Colin Perkins'" Cc: , "'Scott Bradner'" , "'Allison Mankin'" , , , , Subject: RE: [AVT] The storage format of EVRC/SMV vocoder (resent) Date: Thu, 24 Apr 2003 01:34:12 -0700 Organization: UCLA Message-ID: <000a01c30a3c$5555fcc0$657ba8c0@divxnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <200304231352.h3NDqHGt070574@purple.nge.isi.edu> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3O8Z3822108 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Dear Colin, Thank you very much for your email. I completely agree with you that these two drafts are rather independent drafts which are not necessarily exclusive of each other. As you mentioned, both formats have been used by one or more applications in the software and telecom industries, and we all agree with you that it will be very helpful to listen to the opinions of the industries which will rely upon IETF for the protocol standards. The registration MIME type of the EVRC and SMV codec has been halted at IANA in the last minute because of the new draft on this storage format issue. From the perspective of participants in IETF and as engineers/researchers, we all wish to see the RTP payload format for these codecs being used rather than proprietary formats being implemented in the systems which will cause the interoperability problems later. It will be particularly disturbing if this would happen while the international standards are waiting to replace the "Work in progress" with "RFC xxxx". The RTP payload type specification for EVRC and SMV has been in working in AVT for 2.5 years, and is now stalled at RFC editor's queue. Two and a half years is a long time in the telecommunication industry, and it is a long time for Internet community too. I believe whatever proposal one supports, we all hope to see a swift ending to this issue with a fair conclusion while giving each of the proposed format the objective consideration it deserves. Thank you very much, Adam > -----Original Message----- > From: avt-admin@ietf.org [mailto:avt-admin@ietf.org] On Behalf Of > Colin Perkins > Sent: Wednesday, April 23, 2003 6:52 AM > To: Adam Li > Cc: avt@ietf.org; 'Scott Bradner'; 'Allison Mankin'; > craig.greer@nokia.com; jlee@nextreaming.com; sakazawa@kddilabs.jp; > keith.miller@nokia.com > Subject: Re: [AVT] The storage format of EVRC/SMV vocoder (resent) > > Adam, > > My understanding is that there have been implementations of the QCP > format > for several years now, but the MIME type has not been registered. > The MIME > type should be registered, to document this use. > > This is independent of whether the EVRC/SMV file format is also > registered. > > Colin > > > > --> "Adam Li" writes: > >Dear Colin, > > > >Thank you very much for your email. We all have agreed on the fact > that > >.QCP is used by Eudora while .EVC/.SMV are used by 3G service > providers. > > > >However, I have difficulty seeing the rationale for your opinion > that > >the registration of .QCP is clearly needed while the registration > of > >.EVC/.SMV is the opposite. Would you mind explain to us AVT'ers > your > >rationales and pointing out the factors that we missed in the > discussion > >so we can better understand your opinions? > > > >With all the factors that have been expressed on this issue which > are > >summarized in the previous email, it does not seem that the major > >consensus is inclining that way. Maybe we missed something? > > > >Your opinion is very much appreciated. > > > >Adam > > > > > >> -----Original Message----- > >> From: avt-admin@ietf.org [mailto:avt-admin@ietf.org] On Behalf Of > >> Colin Perkins > >> Sent: Tuesday, April 22, 2003 10:27 AM > >> To: Adam Li > >> Cc: avt@ietf.org; 'Scott Bradner'; 'Allison Mankin'; > >> craig.greer@nokia.com; jlee@nextreaming.com; sakazawa@kddilabs.jp; > >> keith.miller@nokia.com > >> Subject: Re: [AVT] The storage format of EVRC/SMV vocoder (resent) > >> > >> Adam, > >> > >> The format specified in draft-garudadri-qcp-00.txt clearly needs > to > >> be > >> published, and to have a MIME type registered, since it has been > >> used by > >> several applications for some years now. > >> > >> What is unclear is whether draft-ieft-avt-evrc-smv-03.txt should > >> refer to > >> that format, or if it should continue to use the alternative > format. > >> The > >> usual arguments apply: having two formats is clearly worse than > one, > >> but > >> there may be technical or political reasons why the new format is > to > >> be > >> preferred for some uses. > >> > >> As the minutes from the recent AVT meeting note, the main users > of > >> the > >> format in draft-ieft-avt-evrc-smv-03.txt seem to be 3GPP2. It is > >> currently > >> unclear if they have implementations of the file format, and if > they > >> chose > >> it for technical reasons or because it it was the only format > they > >> knew. We > >> are hoping to get input from them, to clarify their position. > >> > >> Colin > >> > >> > >> > >> > >> --> "Adam Li" writes: > >> > > >> >The issue of the storage format of the EVRC and SMV vocoders in > the > >> MIME > >> >registration has came up a while ago, and has caused the last > >> minute > >> >holding of the MIME registration for these two vocoders. The > issue > >> has > >> >been discussed thoroughly here on the mailing list in the San > >> Francisco > >> >meeting. The reasons of each side of the argument have been well > >> >presented. Now it may be time to make a decision? > >> > > >> >Like many other issues in our AVT WG, the decision here is > >> ultimately > >> >relying on the judgment of our chairs. During the two and half > >> years > >> >that this draft is being developed in the AVT, the course of the > >> draft > >> >has benefited greatly from your guidance. After the open and > ego- > >> free > >> >discuss that our chairs called upon at the meeting session, it > may > >> be > >> >another good time to hear the opinions from the chairs and get > some > >> help > >> >on the decision from their experience and vision on which one > will > >> >reflect the consensus of the AVT and would be most beneficial to > >> the > >> >whole Internet and telecom industry who will use our > specification. > >> > > >> >Below is the summary of the rationales for each of the choices: > >> > > >> > draft-ieft-avt-evrc-smv-03.txt | draft-garudadri-qcp- > 00.txt > >> >------------------------------------+--------------------------- > --- > >> -- > >> >(1) Mature specification, been | (1) Brand new ID > >> > developed for 2.5 years in AVT | > >> >------------------------------------+--------------------------- > --- > >> -- > >> >(2) Covers both EVRC and SMV | (2) Only cover EVRC > >> >------------------------------------+--------------------------- > --- > >> -- > >> >(3) Referred to by 3GPP2(*) FFMS | (3) > >> > specifications | > >> >------------------------------------+--------------------------- > --- > >> -- > >> >(4) Implemented and used by many 3G | (4) Supported in Eudora > >> > telecom operators (e.g., SKT, | > >> > KTF, LGT). The interoperability | > >> > has been tested among them. | > >> >------------------------------------+--------------------------- > --- > >> -- > >> >(5) Simple and efficient design, | (5) > >> > quick to implement | > >> >------------------------------------+--------------------------- > --- > >> -- > >> >(6) Registration already in IANA, | (6) > >> >------------------------------------+--------------------------- > --- > >> -- > >> >(7) Supported and developed by 7 | (7) Supported and > developed > >> by > >> > companies and universities | Qualcomm > >> > (including Qualcomm) | > >> >------------------------------------+--------------------------- > --- > >> -- > >> >(8) No IP related to this format | (8) IP situation unclear > >> >------------------------------------+--------------------------- > --- > >> -- > >> > > >> >(*) ERVC and SMV are both vocoders developed and defined in the > >> >international consortium 3GPP2 (http://www.3gpp2.org) for the > next > >> >generation wireless network cdma2000. > >> > > >> >Thank you very much. > >> > > >> >Adam > >> > > >> >PS. This is a resent of the previous message, which did not seem > to > >> go > >> >through maybe because of the long cc list. If you think anyone > is > >> missed > >> >out, please let me know. Thanks. > >> > > >> >> -----Original Message----- > >> >> From: Adam Li [mailto:adamli@icsl.ucla.edu] > >> >> Sent: Saturday, March 15, 2003 9:20 PM > >> >> To: 'Ietf-Avt' > >> >> Cc: 'casner@acm.org'; 'Scott Bradner'; 'Colin Perkins'; > 'Allison > >> >> Mankin'; 'randy@qualcomm.com'; 'mccap@lucent.com'; > >> >> 'mdturner@lucent.com'; 'smathai@lucent.com'; > 'lioy@qualcomm.com'; > >> >> 'zeng@packetvideo.com'; 'sherwood@packetvideo.com'; > >> >> 'villa@icsl.ucla.edu'; 'yllee@samsung.com'; > >> 'jeonghoon@samsung.com'; > >> >> 'tom.hiller@lucent.com'; 'David.Leon@nokia.com'; > >> >> 'nleung@qualcomm.com'; 'dgal@lucent.com'; > >> 'ajayrajkumar@lucent.com'; > >> >> 'Lars-Erik.Jonsson@epl.ericsson.se'; 'magnus.westerlund@era- > >> >> t.ericsson.se'; 'vbharga@cisco.com'; 'craig.greer@nokia.com'; > >> >> 'magda@qualcomm.com'; 'casner@acm.org'; > 'ned.freed@mrochek.com'; > >> >> 'mankin@psg.com'; 'hgarudad@qualcomm.com'; 'csp@isi.edu'; > >> >> 'jlee@nextreaming.com'; 'sakazawa@kddilabs.jp'; > 'tsgc@3gpp2.org' > >> >> Subject: Issues for the file format for EVRC/SMV vocoder > >> >> > >> >> Hi folks, > >> >> > >> >> The topic of the file format for EVRC/SMV vocoders hopefully > will > >> be > >> >> discussed in this meeting at San Francisco. Below is a list of > >> the > >> >> issues that might be related to this topic. They are listed > here > >> as > >> >> potential issues for you to consider before the discussion at > the > >> >> meeting. > >> >> > >> >> (1) Technically differences. Is there much difference in > >> efficiency > >> >> and performance between the format in draft-ietf-avt-evrc-smv > and > >> >> draft-garudadri-qcp? Are the differences simply on the file > >> syntax? > >> >> > >> >> (2) Completeness. For EVRC codec data, formats defined in both > >> >> document can handle it. For SMV codec data, the format defined > in > >> >> draft-ietf-avt-evrc-smv is currently the only file format that > >> >> handles SMV data. draft-garudadri-qcp does not handle SMV at > this > >> >> time. > >> >> > >> >> (3) Maturity of the format definition. draft-ietf-avt-evrc-smv > >> has > >> >> its first version submitted to AVT on November 2000. It has > been > >> >> actively worked on all these years, and is co-authored by > people > >> >> from seven companies and universities. It is currently on the > RFC > >> >> editor's queue. draft-garudadri-qcp is submitted in February > 2003. > >> >> Will there be concerns about the maturity of the drafts, > >> >> particularly the handling of SMV codec hasn't been written in > the > >> >> later draft yet? > >> >> > >> >> (4) The recognition. Since EVRC and SMV codec are designed in > >> 3GPP2 > >> >> for their CDMA networks, formats recognized by them are likely > to > >> be > >> >> the most widely used format for those codecs. Which of the > >> formats, > >> >> as defined in draft-ietf-avt-evrc-smv and draft-garudadri-qcp, > >> has > >> >> been considered by 3GPP2 for the format for storing EVRC and > SMV > >> >> data? > >> >> > >> >> (5) Document organization. Even though this is a rather minor > >> point, > >> >> but would there be enough reasons to trade-off for the > additional > >> >> complexity for having the MIME registration of EVRC/SMV > refering > >> to > >> >> a separate and yet to be complete draft? > >> >> > >> >> Draft-ietf-avt-evrc-smv is currently on the RFC editor's queue. > >> If > >> >> we want to consider deleting the file format that is in the > draft > >> >> for almost two years in the last minute before it becomes an > RFC > >> and > >> >> using another yet to be complete new draft instead, we should > be > >> >> providing ourselves with the clear justification for doing so. > >> > > >> >> I will not be there for the discussion unfortunately since I > have > >> >> not made the plan to attend in advance. However, I hope the > list > >> of > >> >> potential issues above might be useful for us to discuss and > >> >> consider. > >> >> > >> >> Wish we have a fruitful meeting in San Francisco. > >> >> > >> >> Adam > >> > > >> > > >> >_______________________________________________ > >> >Audio/Video Transport Working Group > >> >avt@ietf.org > >> >https://www1.ietf.org/mailman/listinfo/avt > >> _______________________________________________ > >> Audio/Video Transport Working Group > >> avt@ietf.org > >> https://www1.ietf.org/mailman/listinfo/avt > > > >_______________________________________________ > >Audio/Video Transport Working Group > >avt@ietf.org > >https://www1.ietf.org/mailman/listinfo/avt > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Apr 24 12:45:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23139 for ; Thu, 24 Apr 2003 12:45:52 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3OGmXD24833 for avt-archive@odin.ietf.org; Thu, 24 Apr 2003 12:48:33 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OGlq824811; Thu, 24 Apr 2003 12:47:53 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OGks824770 for ; Thu, 24 Apr 2003 12:46:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23122 for ; Thu, 24 Apr 2003 12:43:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198jrF-0007Dr-00 for avt@ietf.org; Thu, 24 Apr 2003 12:46:01 -0400 Received: from massive.its.bldrdoc.gov ([132.163.64.201]) by ietf-mx with esmtp (Exim 4.12) id 198jrE-0007DX-00 for avt@ietf.org; Thu, 24 Apr 2003 12:46:00 -0400 Received: from boreas ([132.163.65.223]) by massive.its.bldrdoc.gov (8.12.8p1/8.12.8) with ESMTP id h3OGjtcc000836 for ; Thu, 24 Apr 2003 10:45:55 -0600 (MDT) From: "Mark McFarland" To: Date: Thu, 24 Apr 2003 10:43:26 -0600 Organization: The Institute for Telecommunication Sciences Message-ID: <006001c30a80$a11bc830$df41a384@boreas> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0061_01C30A4E.56815830" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [AVT] Most efficent way to send RTP voice packets? Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0061_01C30A4E.56815830 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Guidance is requested for the TR-8 Project 25 ISSI Messages TSB (and = other interface TSBs yet to be drafted) about a preferred use of 3 voice = messages per RTP message: =20 The draft states now that 3 voice messages will be used per RTP message, = but this has been chosen rather arbitrarly. Does anybody have any experience = in this area as to how many voice messages should be sent per RTP messages? = Or even some "testing" strageties so I can look into this myself (as the = resuts will most likely depend upon the available bandwidth). =20 Thanks! mark =20 Mark McFarland=20 Electronics Engineer=20 United States Department of Commerce=20 National Telecommunications & Information Administration=20 The Institute for Telecommunication Sciences=20 Boulder, CO=20 mailing address:=20 ITS-P=20 325 Broadway=20 Boulder, CO 80305=20 phone: 303/497-4132=20 =20 ------=_NextPart_000_0061_01C30A4E.56815830 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Message
Guidance is=20 requested for the TR-8 Project 25 ISSI Messages TSB (and other interface = TSBs=20 yet to be drafted) about a preferred use of 3 voice messages per RTP=20 message:
 
The = draft states=20 now that 3 voice messages will be used per RTP message, but this = has been=20 chosen rather arbitrarly. Does anybody have any experience in this = area as=20 to how many voice messages should be sent per RTP messages?  Or = even some=20 "testing" strageties so I can look into this myself (as the resuts will = most=20 likely depend upon the available bandwidth).
 
Thanks!
mark
 
Mark McFarland
Electronics Engineer
United = States=20 Department of Commerce
National Telecommunications & Information = Administration
The Institute for Telecommunication Sciences =
Boulder, CO=20

mailing address:
ITS-P
325 Broadway
Boulder, CO = 80305=20

phone: 303/497-4132
 
------=_NextPart_000_0061_01C30A4E.56815830-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Apr 24 14:20:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25985 for ; Thu, 24 Apr 2003 14:20:42 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3OINO831808 for avt-archive@odin.ietf.org; Thu, 24 Apr 2003 14:23:24 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OIMb831780; Thu, 24 Apr 2003 14:22:37 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OILU831748 for ; Thu, 24 Apr 2003 14:21:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25920 for ; Thu, 24 Apr 2003 14:18:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198lKl-00005Q-00 for avt@ietf.org; Thu, 24 Apr 2003 14:20:35 -0400 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 198lKk-00005N-00 for avt@ietf.org; Thu, 24 Apr 2003 14:20:34 -0400 Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h3OIL1BD027155 for ; Thu, 24 Apr 2003 11:21:01 -0700 (MST) Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id LAA10868 for ; Thu, 24 Apr 2003 11:21:01 -0700 (MST)] Received: from motorola.com (d50-39f8.cig.mot.com [160.47.57.248]) by il27exb01.cig.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id 2DANZ5HS; Thu, 24 Apr 2003 13:21:01 -0500 Message-ID: <3EA82B34.6BECF014@motorola.com> Date: Thu, 24 Apr 2003 13:21:40 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: AVT List Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] parameter registration with IANA Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, I wonder whether all the media parameters defined in an AVT RFC are registered with IANA or just some of them. For instance, in RFC3267 (AMR and AMR-WB formats), there are quite a few parameters defined in section 8 (e.g., octet-align, mode-set, ...), but I only see one of them (maxptime) defined at the IANA page . Am I looking at the wrong page? I'd appreciate it if some one could explain how this IANA thing works here to me. thanks, -Qiaobing _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Apr 24 16:05:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01358 for ; Thu, 24 Apr 2003 16:05:24 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3OK8AA07349 for avt-archive@odin.ietf.org; Thu, 24 Apr 2003 16:08:10 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OK6s806406; Thu, 24 Apr 2003 16:06:54 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OK41806286 for ; Thu, 24 Apr 2003 16:04:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00936 for ; Thu, 24 Apr 2003 16:00:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198mvw-0000lF-00 for avt@ietf.org; Thu, 24 Apr 2003 16:03:04 -0400 Received: from wireless228.east.isi.edu ([65.123.202.228] helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 198mvv-0000lB-00 for avt@ietf.org; Thu, 24 Apr 2003 16:03:03 -0400 Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with ESMTP id h3OK3LMj027084; Thu, 24 Apr 2003 16:03:21 -0400 (EDT) (envelope-from csp@purple.nge.isi.edu) Message-Id: <200304242003.h3OK3LMj027084@purple.nge.isi.edu> To: Qiaobing Xie cc: AVT List Subject: Re: [AVT] parameter registration with IANA In-Reply-To: Your message of "Thu, 24 Apr 2003 13:21:40 CDT." <3EA82B34.6BECF014@motorola.com> Date: Thu, 24 Apr 2003 16:03:21 -0400 From: Colin Perkins Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --> Qiaobing Xie writes: >Hi, > >I wonder whether all the media parameters defined in an AVT RFC are >registered with IANA or just some of them. > >For instance, in RFC3267 (AMR and AMR-WB formats), there are quite a few >parameters defined in section 8 (e.g., octet-align, mode-set, ...), but >I only see one of them (maxptime) defined at the IANA page >. Am I looking at the >wrong page? I'd appreciate it if some one could explain how this IANA >thing works here to me. It's a little confusing, certainly. The parameters from RFC 3267 that are on the IANA page are SDP attributes (e.g. a=maxptime:). The parameters that go under a=fmtp: are not listed (they should be included with the MIME type registration for "audio/amr", which is currently just references the RFC). Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Apr 24 18:29:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08446 for ; Thu, 24 Apr 2003 18:29:37 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3OMWQN17747 for avt-archive@odin.ietf.org; Thu, 24 Apr 2003 18:32:26 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OMVj817726; Thu, 24 Apr 2003 18:31:46 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OMUd817625 for ; Thu, 24 Apr 2003 18:30:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08236 for ; Thu, 24 Apr 2003 18:27:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198pDl-0002My-00 for avt@ietf.org; Thu, 24 Apr 2003 18:29:37 -0400 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 198pDl-0002Mv-00 for avt@ietf.org; Thu, 24 Apr 2003 18:29:37 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h3OMU4PP020453 for ; Thu, 24 Apr 2003 15:30:04 -0700 (MST) Received: from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id h3OMTipG026036 for ; Thu, 24 Apr 2003 17:29:45 -0500 Received: from motorola.com (d50-39f8.cig.mot.com [160.47.57.248]) by il27exb01.cig.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id 2DAN5D6P; Thu, 24 Apr 2003 17:30:01 -0500 Message-ID: <3EA86592.C2529628@motorola.com> Date: Thu, 24 Apr 2003 17:30:42 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Colin Perkins CC: AVT List Subject: Re: [AVT] parameter registration with IANA References: <200304242003.h3OK3LMj027084@purple.nge.isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > ... The parameters that > go under a=fmtp: are not listed (they should be included with the MIME type > registration for "audio/amr", which is currently just references the RFC). Colin, So, this means that IANA will not collectively manage any format specific parameters. Thanks and regards, -Qiaobing > > Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Apr 24 18:31:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08618 for ; Thu, 24 Apr 2003 18:31:41 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3OMYVp17844 for avt-archive@odin.ietf.org; Thu, 24 Apr 2003 18:34:31 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OMY6817831; Thu, 24 Apr 2003 18:34:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OMXl817811 for ; Thu, 24 Apr 2003 18:33:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08487 for ; Thu, 24 Apr 2003 18:30:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198pGo-0002Qm-00 for avt@ietf.org; Thu, 24 Apr 2003 18:32:46 -0400 Received: from wireless228.east.isi.edu ([65.123.202.228] helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 198pGo-0002Qj-00 for avt@ietf.org; Thu, 24 Apr 2003 18:32:46 -0400 Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with ESMTP id h3OMX9Mj030156; Thu, 24 Apr 2003 18:33:09 -0400 (EDT) (envelope-from csp@purple.nge.isi.edu) Message-Id: <200304242233.h3OMX9Mj030156@purple.nge.isi.edu> To: Qiaobing Xie cc: AVT List Subject: Re: [AVT] parameter registration with IANA In-Reply-To: Your message of "Thu, 24 Apr 2003 17:30:42 CDT." <3EA86592.C2529628@motorola.com> Date: Thu, 24 Apr 2003 18:33:09 -0400 From: Colin Perkins Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --> Qiaobing Xie writes: >> ... The parameters that >> go under a=fmtp: are not listed (they should be included with the MIME type >> registration for "audio/amr", which is currently just references the RFC). > >So, this means that IANA will not collectively manage any format >specific parameters. They're specific to the payload format, and are registered as part of the MIME registration for the payload format. There is no need for collective management. Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Apr 25 03:08:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29364 for ; Fri, 25 Apr 2003 03:08:20 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3P7BJC31862 for avt-archive@odin.ietf.org; Fri, 25 Apr 2003 03:11:19 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P7Ar831815; Fri, 25 Apr 2003 03:10:54 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P78P831660 for ; Fri, 25 Apr 2003 03:08:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29227 for ; Fri, 25 Apr 2003 03:04:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198xIg-0005eW-00 for avt@ietf.org; Fri, 25 Apr 2003 03:07:14 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.wise.edt.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 198xIf-0005eT-00 for avt@ietf.org; Fri, 25 Apr 2003 03:07:13 -0400 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3P77aRs015924; Fri, 25 Apr 2003 09:07:41 +0200 (MEST) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id JSHA0A0Q; Fri, 25 Apr 2003 09:07:37 +0200 Message-ID: <3EA8DE7C.3010703@era.ericsson.se> Date: Fri, 25 Apr 2003 09:06:36 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Casner CC: IETF AVT WG Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] Errors in draft-ietf-avt-rtcp-bw-05.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Steve I think I have located two errors in the draft. They are located in section 5, the example: 1. Isn't the values for RR and RS wrong. I believe they should change place. If one reads the text below the values in the audio media block should be equal to the default values. That would mean 1.25 % of session to RS, which is 800. While RR should be 2400 or equal to 3.75%. 2. This does also concern the text below the example. In my interpretation there is difference between including both RR and RS and leaving them out while you have the bit-rates equal to the default 3.75 and 1.25 %. When you have the RR and RS in place the 1/4 active sender rule is not in place. While when you don't have them it will be in place. Therefore there will be a significant difference in how you assign the bit-rate. Also I think that one could clarify this difference. I hope there is possibility to fix these errors before the publication. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Apr 25 08:44:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07028 for ; Fri, 25 Apr 2003 08:44:01 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3PCl6h22321 for avt-archive@odin.ietf.org; Fri, 25 Apr 2003 08:47:06 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PCke822271; Fri, 25 Apr 2003 08:46:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P6Rn828283 for ; Fri, 25 Apr 2003 02:27:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28554 for ; Fri, 25 Apr 2003 02:24:22 -0400 (EDT) From: ned.freed@mrochek.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198wfP-0005Ao-00 for avt@ietf.org; Fri, 25 Apr 2003 02:26:39 -0400 Received: from mauve.mrochek.com ([209.55.107.55]) by ietf-mx with esmtp (Exim 4.12) id 198wfN-0005Ag-00 for avt@ietf.org; Fri, 25 Apr 2003 02:26:38 -0400 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KV4FYRL1CG007FVT@mauve.mrochek.com> for avt@ietf.org; Thu, 24 Apr 2003 23:26:04 -0700 (PDT) Date: Thu, 24 Apr 2003 23:21:09 -0700 (PDT) Subject: Re: [AVT] The storage format of EVRC/SMV vocoder (resent) In-reply-to: "Your message dated Wed, 23 Apr 2003 15:33:15 -0700" To: Randall Gellens Cc: Colin Perkins , keith.miller@nokia.com, Ned Freed , adamli@icsl.ucla.edu, avt@ietf.org, sob@harvard.edu, mankin@psg.com, craig.greer@nokia.com, jlee@nextreaming.com, sakazawa@kddilabs.jp Message-id: <01KV4GBU52QE007FVT@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed Content-transfer-encoding: 7BIT References: <200304221804.h3MI4vGt058058@purple.nge.isi.edu> Content-Transfer-Encoding: 7BIT Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT > At 2:04 PM -0400 4/22/03, Colin Perkins wrote: > > Are there minutes of this meeting available? I'd like to understand the > > rationale behind the choice (especially the choice of changing the MIME > > type, since "audio/qcp" seems appropriate). > Regarding the MIME type, "audio/qcp" was the initial suggested MIME > type, but there was pushback based on the principle that MIME types > should describe the content, not the format. In general, neglect of > this principle reduces interoperability, since it then means that an > implementation that supports a certain MIME type may not be able to > handle content received in that MIME type. Yes, although there's sometimes a fine line between content differences and the use of different content options. The standard example is PostScript, which has numerous optional facilities, so many that describing them all in either parameters or in subtype names is clearly impractical. > So, in accordance with > the principle, it makes sense to use "audio/qcelp" for QCELP 13K data > in this format, "audio/evrc-qcp" for EVRC data stored in the QCP > format, and "audio/smv-qcp" for SMV data in the QCP format. > I suppose "audio/qcelp" plus "audio/qcp" with a mandatory parameter > for the codec included, which could only be SMV or EVRC, not QCELP, > could also work. I've added Ned Freed to the distribution list to > get his views, as the IANA-designated MIME expert. (FYI, I'm on the AVT list already...) I tend to lean towards separate types myself, but either way will work. Ned _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Apr 25 14:24:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18090 for ; Fri, 25 Apr 2003 14:24:41 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3PIRri17000 for avt-archive@odin.ietf.org; Fri, 25 Apr 2003 14:27:53 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PIRC816981; Fri, 25 Apr 2003 14:27:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PIPE816942 for ; Fri, 25 Apr 2003 14:25:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18042 for ; Fri, 25 Apr 2003 14:21:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1997rQ-0002hB-00 for avt@ietf.org; Fri, 25 Apr 2003 14:23:48 -0400 Received: from www.route-explorer.net ([65.192.41.10] helo=mailman.packetdesign.com) by ietf-mx with esmtp (Exim 4.12) id 1997rP-0002h1-00 for avt@ietf.org; Fri, 25 Apr 2003 14:23:47 -0400 Received: from ash.packetdesign.com (ash.packetdesign.com [192.168.0.243]) by mailman.packetdesign.com (8.12.8/8.12.8) with ESMTP id h3PINYvW071024; Fri, 25 Apr 2003 11:23:35 -0700 (PDT) (envelope-from casner@acm.org) Date: Fri, 25 Apr 2003 11:23:34 -0700 (PDT) From: Stephen Casner To: Magnus Westerlund cc: IETF AVT WG In-Reply-To: <3EA8DE7C.3010703@era.ericsson.se> Message-ID: <20030425110714.C77830-100000@ash.packetdesign.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [AVT] Re: Errors in draft-ietf-avt-rtcp-bw-05.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Magnus > I think I have located two errors in the draft. They are located in > section 5, the example: > > 1. Isn't the values for RR and RS wrong. I believe they should change > place. If one reads the text below the values in the audio media block > should be equal to the default values. That would mean 1.25 % of session > to RS, which is 800. While RR should be 2400 or equal to 3.75%. You are right, these are swapped. Thanks for finding this error. > 2. This does also concern the text below the example. In my > interpretation there is difference between including both RR and RS and > leaving them out while you have the bit-rates equal to the default 3.75 > and 1.25 %. When you have the RR and RS in place the 1/4 active sender > rule is not in place. While when you don't have them it will be in > place. Therefore there will be a significant difference in how you > assign the bit-rate. Also I think that one could clarify this difference. I'm not sure what point you are making. Is it that the 1/4 active sender rule says that the active senders get _at least_ 1/4 of the RTCP bandwidth but that if RS is specified the active senders would never get more than that? It was my intention that the behavior be the same when RS and RR are specified, or even if just one is specified. These bw specifiers just set the two input values to the algorithm. However, I see that the document does not make this clear. Do you think there is a reason that the behavior I inteded will not work? > I hope there is possibility to fix these errors before the publication. I believe so. -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Sun Apr 27 16:30:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01363 for ; Sun, 27 Apr 2003 16:30:06 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3RKYJp27662 for avt-archive@odin.ietf.org; Sun, 27 Apr 2003 16:34:19 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3RKWS827615; Sun, 27 Apr 2003 16:32:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3RKTh827381 for ; Sun, 27 Apr 2003 16:29:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01332 for ; Sun, 27 Apr 2003 16:24:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 199sjx-0006I6-00 for avt@ietf.org; Sun, 27 Apr 2003 16:27:13 -0400 Received: from flawless.real.com ([207.188.7.222]) by ietf-mx with esmtp (Exim 4.12) id 199sjx-0006I3-00 for avt@ietf.org; Sun, 27 Apr 2003 16:27:13 -0400 Received: from raven.dev.prognet.com ([::ffff:172.22.22.16]) (TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by flawless.real.com with esmtp; Sun, 27 Apr 2003 13:27:06 -0700 Date: Sun, 27 Apr 2003 13:31:07 -0700 (PDT) From: Aaron Colwell To: avt@ietf.org Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] RTP collision resolution Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I've been reading through the RFC 1889 and draft-ietf-avt-rtp-new-12.txt and I still can't quite figure out a few things about the SSRC collision resolution algorithm. I will first start with the simple case where there is one sender in the RTP session. In this case there is only one sending SSRC and the "send a BYE for the old SSRC and pick a new SSRC" is pretty clear and easy for the client to figure out what is happening. Does the sender keep the same sequence number and timestamp offset across this switch? My current assumption is that it does, but I could not find that explicitly stated anywhere. Is that assumption correct? I hope so since it might cause all sorts of problems for certain payload types like interleaved AMR. The second case that I am confused about is when there are more than one sender in an RTP session. For this example I'll use the case where we are doing SSRC multiplexing of a stream and a retransmission stream. In this case both SSRCs are associated with the same CNAME. In the highly unlikely chance that both SSRCs conflict with existing SSRCs in the session, how will the client resolve the proper transition of both of these SSRCs to new SSRCs? The only way that I can think of to resolve this would be to use the payload type. Is that how the resolution should happen? My third case is similar to my second case. I have seen examples in the archives where people talk about using SSRC multiplexing for a lecture type environment where there is a SSRC assigned to a lecturer, and a SSRC assigned to a question microphone. In this scenario, the two SSRCs likely have the same payload type so the resolution mechanism from case 2 would not work. How is the client supposed to resolve the transitions in this case? Do all of these sources have the same CNAME? If not, then the resolution can be done based on the CNAME. I was under the impression that the CNAME would be the same for all the SSRCs in this scenario though. One final question about SSRC multiplexing in general. Is it assumed that all SSRCs associated with the same CNAME should be mixed together on the client side? Any clarification people can provide on these questions would be great. Thanks, Aaron _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Apr 28 02:59:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22467 for ; Mon, 28 Apr 2003 02:59:08 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3S73Zg12879 for avt-archive@odin.ietf.org; Mon, 28 Apr 2003 03:03:35 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3S71s812810; Mon, 28 Apr 2003 03:01:54 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3S70N812578 for ; Mon, 28 Apr 2003 03:00:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22447 for ; Mon, 28 Apr 2003 02:55:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19A2a4-0000v7-00 for avt@ietf.org; Mon, 28 Apr 2003 02:57:40 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.wise.edt.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19A2a4-0000v3-00 for avt@ietf.org; Mon, 28 Apr 2003 02:57:40 -0400 Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3S6wCRs021015; Mon, 28 Apr 2003 08:58:12 +0200 (MEST) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id JZBTCBAN; Mon, 28 Apr 2003 08:58:12 +0200 Message-ID: <3EACD0C1.1050803@era.ericsson.se> Date: Mon, 28 Apr 2003 08:57:05 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Casner CC: IETF AVT WG References: <20030425110714.C77830-100000@ash.packetdesign.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] Re: Errors in draft-ietf-avt-rtcp-bw-05.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Steve, Stephen Casner wrote: >>2. This does also concern the text below the example. In my >>interpretation there is difference between including both RR and RS and >>leaving them out while you have the bit-rates equal to the default 3.75 >>and 1.25 %. When you have the RR and RS in place the 1/4 active sender >>rule is not in place. While when you don't have them it will be in >>place. Therefore there will be a significant difference in how you >>assign the bit-rate. Also I think that one could clarify this difference. >> >> > >I'm not sure what point you are making. Is it that the 1/4 active >sender rule says that the active senders get _at least_ 1/4 of the >RTCP bandwidth but that if RS is specified the active senders would >never get more than that? > >It was my intention that the behavior be the same when RS and RR are >specified, or even if just one is specified. These bw specifiers just >set the two input values to the algorithm. However, I see that the >document does not make this clear. > >Do you think there is a reason that the behavior I inteded will not >work? > > The interpretation of your draft that I and other in 3GPP SA4 have made, is that when you use both RR and RS you don't use the 1/4 active sender rule. If both the values are specified one simple plugs them in as the values for each group. I think there are a good reason for doing this interpretation. 1. Unless one disables the 1/4 rule it is impossible to turn off RTCP receiver reports in cases where there are more then one 1/4 senders, which include the so important 1 to 1 case. 2. It becomes impossible to set unsymmetric RTCP bit-rates in 1-1 cases. This would be a problem in for example streaming cases where one might desire to control the bit-rate in each direction. This can be especially important in use cases over wireless links that need rather good control over bit-rate. So based on these arguments I would suggest that you actually clarify the draft in this direction. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Apr 28 16:17:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13391 for ; Mon, 28 Apr 2003 16:17:54 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3SKMcl09811 for avt-archive@odin.ietf.org; Mon, 28 Apr 2003 16:22:38 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SKLs809787; Mon, 28 Apr 2003 16:21:55 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SKK3809703 for ; Mon, 28 Apr 2003 16:20:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13317 for ; Mon, 28 Apr 2003 16:14:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AF3g-000599-00 for avt@ietf.org; Mon, 28 Apr 2003 16:17:04 -0400 Received: from wireless228.east.isi.edu ([65.123.202.228] helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 19AF3f-00058x-00 for avt@ietf.org; Mon, 28 Apr 2003 16:17:03 -0400 Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with ESMTP id h3SKHcfP011789 for ; Mon, 28 Apr 2003 16:17:38 -0400 (EDT) (envelope-from csp@purple.nge.isi.edu) To: avt@ietf.org Date: Mon, 28 Apr 2003 16:17:38 -0400 Message-ID: <11788.1051561058@purple.nge.isi.edu> From: Colin Perkins Subject: [AVT] Comments on draft-ietf-avt-rtcp-report-extns-04.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Please consider the following as my last call comments on the RTCP XR draft. The working group last call is due to end today - if you have comments on this draft, please send them shortly. Colin - The draft needs an explicit statement that the standard RTCP timing rules apply, and that use of the extended report blocks will likely increase the reporting interval. - The second paragraph of section 1.1 talks about "broadcast" sessions. I assume that one-to-many streaming is intended, but the text should be clarified since broadcast IP is presumably not used. - First paragraph of section 2: "thus backwards compatibility with" -> "this backwards compatible with" - The packet format in section 2 has an "SSRC/CSRC" field; this should presumably be "SSRC" only? (diagram and text following) - In explanation of the DLRR field in section 4.5 mentions LSR and DLSR in a couple of places. Should be talking about LRR and DLRR? - Second paragraph of section 4.6 "The fields corresponding to unreported parameters MUST be set to zero" may be clearer as "...MUST be present, but are set to zero"? - In section 4.6, the avg_jitter and avt_ttl_or_hl fields are listed as being the "average" of a particular statistic. Which average is used? I assume the mean, but should clarify. - Section 4.7, second paragraph: "between RTCP end points" -> "between RTP end points" - I don't understand the first paragraph of section 4.7.2; please reword for clarity. - The example of page 28 reference loss density and discard density, but these do not appear to be defined? (they're briefly mentioned earlier in the section, but are not reported) - In section 4.7.3, the round trip delay is calculated in milliseconds, but the discussion talk about calculating it using RTCP LSR/DLSR. Can you confirm that milliseconds are intended? And, if so, note in the explanation that a units conversion is needed. - In section 4.7.3, the end system delay estimate makes the assumption that the system can send and receive, and that it has a local analog interface to loop-back audio. Neither of these are necessarily valid. Accordingly, the I'd like to see the "MUST be provided" turn into a SHOULD, and some explanation of what to do if the data cannot be provided. - In section 4.7.4, the signal and noise levels are defined as a ratio in terms of a "reference digital milliwatt" and "rms talkspurt power (mW)". Can you clarify the definition of these terms? I wouldn't know how to calculate them, in the PC-based implementation I'm familiar with. - In section 4.7.4, the definition of the residual echo return loss is not clear, and seems to assume particular implmentations of gateway devices. Recommend separating the normative definition of the field out from the non-normative examples of how it might be measured in particular cases. - In section 4.7.5, the fields are mostly 8 bits, with only a subset of values being legal. Would it be appropriate to use smaller fields in some cases? What should receivers do if they receive a report where a field has an illegal value? - In section 4.7.5, the chosen values for the PLC are not contiguous: I can indicate a PLC that can conceal less than 3% (standard PLC), or more than 10% (enhanced PLC), but nothing in the middle. Is there intended to be a "better-than-standard but not quite enhanced" range? How does this relate to the "unspecified" category? - In section 4.7.6, the jitter buffer rate assumes that the jitter buffer can cope with a step change in jitter from 30ms to 100ms. This seems to be somewhat aggressive? - In section 4.7.7, the units for the "JB max" and "JB abs max" fields are not specified. Also, what is reported if the "JB abs max" is larger than the maximum expressible value? - In section 5.1, need a reference to the definitions of DIGIT and CRLF. - Section 6.2 should define what information needs to be included in any new registrations of attribute block types. There is, presumably, some minimum degree of specification that is required for interoperability? - In section 6.2, if the BT value of 255 is reserved for future extension, it becomes necessary to indicate how it might be extended. I expect that this space is large enough, that we don't have to worry about reserving the block. - End of section 6.3, talks about an ABNF definition of new parameters, in accordance3 with the "format-ext" definition. It needs to reference the location of the "format-ext" definition. - Section 7 needs to reference the standard RTCP reporting mechanism, when it says that the security considerations therein apply. - In section 7, I'm not sure it's appropriate to mandate that XR packets SHOULD NOT be encrypted or filtered. - Appendix A.2: If differences are found, or if the ETSI spec is updated, what happens? - References: RFC 1700 is listed as Historic in my copy of the RFC index. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Apr 28 17:01:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14496 for ; Mon, 28 Apr 2003 17:01:31 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3SL6Gr13644 for avt-archive@odin.ietf.org; Mon, 28 Apr 2003 17:06:16 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SL5I813596; Mon, 28 Apr 2003 17:05:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SFdF820022 for ; Mon, 28 Apr 2003 11:39:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04814 for ; Mon, 28 Apr 2003 11:34:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AAg1-0003WG-00 for avt@ietf.org; Mon, 28 Apr 2003 11:36:21 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 19AAg1-0003WD-00 for avt@ietf.org; Mon, 28 Apr 2003 11:36:21 -0400 Received: (from christos@localhost) by boreas.isi.edu (8.11.6p2/8.11.2) id h3SFa7s16960; Mon, 28 Apr 2003 08:36:07 -0700 (PDT) From: Christos Papadopoulos Message-Id: <200304281536.h3SFa7s16960@boreas.isi.edu> To: christos@ISI.EDU Date: Mon, 28 Apr 2003 08:36:07 -0700 (PDT) Cc: almeroth@cs.ucsb.edu (Kevin Almeroth) X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] Call For Participation: NOSSDAV 2003 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit NOSSDAV 2003: CALL FOR PARTICIPATION The 13th International Workshop on Network and Operating Systems Support for Digital Audio and Video (NOSSDAV 2003) Held in conjuction with IWQOS Sponsored by ACM SIGMM June 1-3, 2003 Monterey, California http://www.nossdav.org/2003 We are pleased to invite you to participate to NOSSDAV 2003, held in conjuction with IWQOS. Registration and local information are now available via the NOSSDAV WWW page. Please note that early registration and hotel cutoff date is MAY 10, 2003. PROGRAM SCHEDULE Sunday June 1: 5:00 PM Registration Monday June 2: 08:00 AM Registration 08:00-09:00 AM Breakfast 09:00-10:00 AM Session 1 (Keynote) 10:00-10:30 AM Break 10:30-Noon Session 2 (Video Adaptation) Noon-1:30 PM Lunch 1:30-3:30 PM Session 3 (Content Management) 3:30-4:00 PM Break 4:00-5:00 PM Session 4 (Conferencing) Tuesday June 3: 08:00 AM Registration 08:00-09:00 AM Breakfast 09:00-10:30 AM Session 5 (QoS and Congestion Control) 10:30-11:00 AM Break 11:00-Noon Session 6 (User Perception in Audio) Noon-1:30 PM Lunch 1:30-3:00 PM Session 7 (Panel) 3:00-3:30 PM Break 3:30-5:30 PM Session 8 (Peer to Peer Systems) ________________________________________________________________________ ACCEPTED PAPERS Session 1: Keynote ------------------- Why Johnny Can't Multicast: Lessons about the Evolution of the Internet - Mostafa H. Ammar Session 2: Video Adaptation ---------------------------- User-Perceived Quality-Aware Adaptive Delivery of MPEG-4 Content. - Liam Murphy, Nicola Cranley, Philip Perry Receiver Initiated Just-in-Time Tree Adaptation for Rich Media Distribution. - Zhichen Xu, Chunqiang Tang, Sujata Banerjee, Sung-Ju Lee Rate-Distortion Framework for Scalable Internet Video Streaming. - Min Dai, Dmitri Loguinov Session 3: Content Management ------------------------------ Design and Implementation of a Distributed Content Management System. - Chuck Cranor, Rick Ethington, Amit Sehgal, David Shur, Cormac Sreenan, Kobus van der Merwe MediSyn: A Synthetic Streaming Media Service Workload Generator. - Wenting Tang, Yun Fu, Lucy Cherkasova, Amin Vahdat Adaptive and Lazy Segmentation Based Proxy Caching for Streaming Media Delivery. - Songqing Chen, Bo Shen, Susie Wee, Xiaodong Zhang Dynamic Program Insertion in High Quality Video over IP. - Taehyun Kim, Jack Brassil Session 4: Conferencing ------------------------ A Protocol for Reliable Decentralized Conferencing. - Jonathan Lennox, Henning Schulzrinne Ubiquitous Computing Using SIP. - Stylianos Sidiroglou, Xiaotao Wu, Stefan Berger, Henning Schulzrinne Session 5: QoS and Congestion Control -------------------------------------- Quality-Adaptive Media Streaming by Priority Drop. - Charles Krasic, Jonathan Walpole, Wu-chi Feng Adjusting Forward Error Correction for TCP-Friendly Streaming MPEG. - Huahui Wu Improving TCP Smoothness by Synchronized and Measurement-based Congestion Avoidance. - Chi Zhang Session 6: User Perception in Audio ------------------------------------ A Source and Channel Rate Adaptation Algorithm for AMR in VoIP Using the Emodel. - Johnny Matta, Christine Pepin, Khosrow Lashkari, Ravi Jain Loss Concealment for Multi-Channel Streaming Audio. - Rishi Sinha, Christos Papadopoulos, Chris Kyriakakis Session 7: Panel ----------------- - TBA Session 8: Peer to Peer Systems -------------------------------- A Reputation System for Peer-to-Peer Networks. - Minaxi Gupta, Paul Judge, Mostafa Ammar PALS: Peer to Peer Adaptive Layered Streaming. - Reza Rejaie, Antonio Ortega Layered Peer-to-Peer Streaming. - Yi Cui, Klara Nahrstedt Borg: a Hybrid Protocol for Scalable Application-level Multicast in Peer-to-Peer Networks. - Rongmei Zhang, Y. Charlie Hu _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Apr 28 19:34:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18986 for ; Mon, 28 Apr 2003 19:34:15 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3SNd2C26259 for avt-archive@odin.ietf.org; Mon, 28 Apr 2003 19:39:02 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SNbv826176; Mon, 28 Apr 2003 19:37:57 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SNaR825277 for ; Mon, 28 Apr 2003 19:36:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18822 for ; Mon, 28 Apr 2003 19:31:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AI7f-0006Em-00 for avt@ietf.org; Mon, 28 Apr 2003 19:33:23 -0400 Received: from telchemy.com ([66.155.69.251]) by ietf-mx with esmtp (Exim 4.12) id 19AI7f-0006EU-00 for avt@ietf.org; Mon, 28 Apr 2003 19:33:23 -0400 Received: from TELWS104 [64.238.103.215] by telchemy.com with ESMTP (SMTPD32-7.14) id AA3B1E90150; Mon, 28 Apr 2003 19:33:15 -0400 Reply-To: From: "Alan Clark" To: "'Colin Perkins'" , "Timur Friedman \(E-mail\)" Cc: Subject: RE: [AVT] Comments on draft-ietf-avt-rtcp-report-extns-04.txt Date: Mon, 28 Apr 2003 19:28:05 -0400 Message-ID: <00ca01c30ddd$d250ccb0$6801a8c0@telchemy.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <11788.1051561058@purple.nge.isi.edu> Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Colin Thanks for the comments - I've responded on those related to VoIP Regards Alan Clark - The draft needs an explicit statement that the standard RTCP timing rules apply, and that use of the extended report blocks will likely increase the reporting interval. [Alan] Suggest adding to Section 1.1 paragraph 1 "The XR report blocks defined in this document MUST be sent within the defined guidelines for RTCP reporting intervals. In certain applications the use of RTCP XR payloads may mean that less frequent reports are needed in order to provide a sufficient degree of feedback on performance." - The second paragraph of section 1.1 talks about "broadcast" sessions. I assume that one-to-many streaming is intended, but the text should be clarified since broadcast IP is presumably not used. [Alan] Suggest either (i) replacing "broadcast" with "one-to-many streaming" (ii) delete broadcast as multicast will cover most cases - First paragraph of section 2: "thus backwards compatibility with" -> "this backwards compatible with" - The packet format in section 2 has an "SSRC/CSRC" field; this should presumably be "SSRC" only? (diagram and text following) - In explanation of the DLRR field in section 4.5 mentions LSR and DLSR in a couple of places. Should be talking about LRR and DLRR? - Second paragraph of section 4.6 "The fields corresponding to unreported parameters MUST be set to zero" may be clearer as "...MUST be present, but are set to zero"? - In section 4.6, the avg_jitter and avt_ttl_or_hl fields are listed as being the "average" of a particular statistic. Which average is used? I assume the mean, but should clarify. - Section 4.7, second paragraph: "between RTCP end points" -> "between RTP end points" [Alan] Agreed - I don't understand the first paragraph of section 4.7.2; please reword for clarity. [Alan] "A burst is a period during which a high proportion of packets are either lost in transit or discarded due to late arrival. A burst is defined as a longest sequence that (a) starts with a lost or discarded packet, (b) does not contain any occurrences of Gmin or more consecutive received (and not discarded) packets, and (c) ends with a lost or discarded packet." - The example of page 28 reference loss density and discard density, but these do not appear to be defined? (they're briefly mentioned earlier in the section, but are not reported) [Alan] these should be "loss rate" and "discard rate", both of which are defined in section 4.7.1 - In section 4.7.3, the round trip delay is calculated in milliseconds, but the discussion talk about calculating it using RTCP LSR/DLSR. Can you confirm that milliseconds are intended? And, if so, note in the explanation that a units conversion is needed. [Alan] The use of milliseconds was intentional. Suggest changing second sentence of "round trip delay" definition to: "This value MAY be measured using RTCP or the DLRR method defined in Section 4.5 of this document, in which case it is necessary to convert the units of measurement from NTP to milliseconds, or other approaches." - In section 4.7.3, the end system delay estimate makes the assumption that the system can send and receive, and that it has a local analog interface to loop-back audio. Neither of these are necessarily valid. Accordingly, the I'd like to see the "MUST be provided" turn into a SHOULD, and some explanation of what to do if the data cannot be provided. [Alan] This was defined as an estimated rather than measured delay, and can typically be determined by adding known framing and encode/decode delays - it was not intended that it be measured literally. We can change the wording to clarify. "The most recently estimated end system delay, expressed in milliseconds. End system delay is defined as the sum of the total sample accumulation and encoding delay associated with the sending direction and the jitter buffer, decoding and playout buffer delay associated with the receiving direction; this delay MAY be estimated or measured. This value MUST be provided in all VoIP metrics reports." - In section 4.7.4, the signal and noise levels are defined as a ratio in terms of a "reference digital milliwatt" and "rms talkspurt power (mW)". Can you clarify the definition of these terms? I wouldn't know how to calculate them, in the PC-based implementation I'm familiar with. [Alan] The term "digital milliwatt" is widely used in both PCM and VoIP systems to denote the digital representation of a 0 dBm0 signal. I've not yet found the official definition of it, although it may originate in an IEEE standard - we can substitute a 0dBm0 reference signal. Suggest:- for "signal level" and "noise level" change "digital milliwatt" to "0 dBm0 reference [18]" add reference [18] TIA/EIA-810-A Transmission Requirements for Narrowband Voice over IP and Voice over PCM Digital Wireline Telephones, December 2000 - In section 4.7.4, the definition of the residual echo return loss is not clear, and seems to assume particular implmentations of gateway devices. Recommend separating the normative definition of the field out from the non-normative examples of how it might be measured in particular cases. [Alan] This should be typical of VoIP gateways with line echo cancellers and isn't specific to any implementations. I've checked with a number of echo canceller software developers and the parameters are typically available as ERL and ERLE in dB or in some format that can easily be converted. Suggest clarifying the wording to: The residual echo return loss is defined as the sum of the measured echo return loss (ERL) and the echo return loss enhancement (ERLE) of the echo canceller (if present) expressed in dB as a signed integer in 2's complement form. The residual echo return loss relates to the effective echo level that a user would hear. The amount of echo that can occur in analog loops can be significant, and therefore echo cancellers are typically used to try and eliminate or reduce the audible echo. The amount of echo is typically described as a "echo return loss" (i.e. ratio between the transmitted signal level and the received echo level) expressed in dB. The effectiveness of an echo canceller is normally described in terms of "echo return loss enhancement", i.e. an echo canceller increases the effective echo return loss and makes the audible echo smaller. Hence the residual echo return loss (RERL) is the sum of the echo return loss (ERL) and the echo return loss enhancement (ERLE) expressed in dB. - In section 4.7.5, the fields are mostly 8 bits, with only a subset of values being legal. Would it be appropriate to use smaller fields in some cases? What should receivers do if they receive a report where a field has an illegal value? [Alan] I suggest keeping these as 8 bit, otherwise we would need to handle 6 bit values. We could change the "A value of" sentences to read "A value of 127 indicates that this parameter is unavailable. Values other than 127 and the valid range defined above MUST not be sent and MUST be ignored by the receiving system." - In section 4.7.5, the chosen values for the PLC are not contiguous: I can indicate a PLC that can conceal less than 3% (standard PLC), or more than 10% (enhanced PLC), but nothing in the middle. Is there intended to be a "better-than-standard but not quite enhanced" range? How does this relate to the "unspecified" category? [Alan] There is a continuum of possibilities in terms of PLC effectiveness. "Standard" in this case refers to algorithms that use some form of last packet replay with attenuation and filtering/smoothing. "Enhanced" refers to algorithms that use some form of error correction(sometimes introducing additional delay or bandwidth overhead). "Unspecified" simply means that the CODEC details are outside the domain of knowledge of the RTCP XR reporting instance - they are typically internal to a DSP. I think the standard and enhanced definitions cover what is used in the industry today, and generally implementors could figure out which to use. - In section 4.7.6, the jitter buffer rate assumes that the jitter buffer can cope with a step change in jitter from 30ms to 100ms. This seems to be somewhat aggressive? [Alan] Let's hope people aren't using 10BaseT and hubs for VoIP!! :-) Many adaptive jitter buffers max out at 200-400mS although they would typically operate in the 20-50mS range. As the description suggests, this is intended to be an easily measured parameter that provides a guide to the JB ramp time, in reality jitter/PDV would not behave quite this way. - In section 4.7.7, the units for the "JB max" and "JB abs max" fields are not specified. Also, what is reported if the "JB abs max" is larger than the maximum expressible value? [Alan] Suggested changes jitter buffer maximum delay... This is the current maximum jitter buffer delay in milliseconds which corresponds to the earliest arriving packet that would not be discarded. In simple queue....... jitter buffer absolute maximum delay... This is the absolute maximum delay in milliseconds that the adaptive jitter buffer can reach under worst case conditions. If this value exceeds 65535 milliseconds then it shall be limited to 65535. This parameter MUST.... - In section 5.1, need a reference to the definitions of DIGIT and CRLF. - Section 6.2 should define what information needs to be included in any new registrations of attribute block types. There is, presumably, some minimum degree of specification that is required for interoperability? - In section 6.2, if the BT value of 255 is reserved for future extension, it becomes necessary to indicate how it might be extended. I expect that this space is large enough, that we don't have to worry about reserving the block. - End of section 6.3, talks about an ABNF definition of new parameters, in accordance3 with the "format-ext" definition. It needs to reference the location of the "format-ext" definition. - Section 7 needs to reference the standard RTCP reporting mechanism, when it says that the security considerations therein apply. - In section 7, I'm not sure it's appropriate to mandate that XR packets SHOULD NOT be encrypted or filtered. [Alan] Isn't SHOULD an advisory qualifier, unlike MUST? The goal is to encourage implementors to turn encryption of RTCP off when sending RTCP XR reports as this is desirable from a network management perspective. - Appendix A.2: If differences are found, or if the ETSI spec is updated, what happens? [Alan] We are refering to a specific dated release of the ETSI spec. The VoIP metrics payload is actually substantially more comprehensive than the ETSI spec, which only relates to methods for calculating R factors. We should make the reference at the end of the second paragraph in 4.7 "(as described by the E Model defined in [6,3]) and.." - References: RFC 1700 is listed as Historic in my copy of the RFC index. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt