From csp@csperkins.org Fri May 1 02:22:50 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 792F43A6840 for ; Fri, 1 May 2009 02:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCZyldpresiy for ; Fri, 1 May 2009 02:22:49 -0700 (PDT) Received: from lon1-msapost-1.mail.demon.net (lon1-msapost-1.mail.demon.net [195.173.77.180]) by core3.amsl.com (Postfix) with ESMTP id 33C563A67EB for ; Fri, 1 May 2009 02:22:49 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by lon1-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1Lzoya-0000CD-XV; Fri, 01 May 2009 09:24:12 +0000 Message-Id: <3865D904-24F4-44E1-8D7C-BF9B81C89488@csperkins.org> From: Colin Perkins To: Roni Even In-Reply-To: <49fa06b0.0637560a.430f.ffffb534@mx.google.com> Content-Type: multipart/alternative; boundary=Apple-Mail-35-869646260 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 1 May 2009 10:24:11 +0100 References: <49fa06b0.0637560a.430f.ffffb534@mx.google.com> X-Mailer: Apple Mail (2.930.3) Cc: avt@ietf.org, 'Tom Taylor' Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions (RAMS) as a working group item X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 09:22:50 -0000 --Apple-Mail-35-869646260 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit I support this draft being adopted as a working group item, since there's clearly interest in the work. Colin On 30 Apr 2009, at 21:12, Roni Even wrote: > Hi, > I would like to ask if there is interest to adopt Rapid Acquisition > of Multicast RTP Sessions (RAMS) as a working group item. The > suggestion is to start the work usinghttp://tools.ietf.org/html/draft-versteeg-avt-rapid-synchronization-for-rtp-03 > as the initial text for the work. > > I would also like to suggest that Bill Versteeg will be the editor > of the WG document if adopted. > > Please send any feedback to the mailing list by Friday May 8th. If > there will be a consensus we will accept this topic and have the > above draft as the initial document. > > Thanks > Roni Even > AVT co-chair > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt -- Colin Perkins http://csperkins.org/ --Apple-Mail-35-869646260 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I support this draft being = adopted as a working group item, since there's clearly interest in the = work.= --Apple-Mail-35-869646260-- From csp@csperkins.org Fri May 1 02:26:41 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83B833A684A; Fri, 1 May 2009 02:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.544 X-Spam-Level: X-Spam-Status: No, score=-3.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZvZjf9C1Qki; Fri, 1 May 2009 02:26:40 -0700 (PDT) Received: from lon1-msapost-1.mail.demon.net (lon1-msapost-1.mail.demon.net [195.173.77.180]) by core3.amsl.com (Postfix) with ESMTP id CF24C28C167; Fri, 1 May 2009 02:26:01 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by lon1-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1Lzp1h-0001CY-Wo; Fri, 01 May 2009 09:27:25 +0000 Message-Id: <8BEBE133-BC38-4001-8083-190782BF9949@csperkins.org> From: Colin Perkins To: Roni Even In-Reply-To: <49fa9d9c.0305560a.5885.7b1f@mx.google.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 1 May 2009 10:27:24 +0100 References: <04CAD96D4C5A3D48B1919248A8FE0D54066184FC@xmb-sjc-215.amer.cisco.com> <49f9ea83.0637560a.4488.62d2@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D540934913F@xmb-sjc-215.amer.cisco.com> <49fa0498.0405560a.615f.677e@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D540934937B@xmb-sjc-215.amer.cisco.com> <49fa9d9c.0305560a.5885.7b1f@mx.google.com> X-Mailer: Apple Mail (2.930.3) Cc: avt@ietf.org, fecframe@ietf.org Subject: Re: [AVT] [Fecframe] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 09:26:41 -0000 On 1 May 2009, at 07:56, Roni Even wrote: > Hi Ali, > This is up to the WG to decide if they want to have support for SSRC > multiplexing and the implications of this support. I am not sure > what you mean by "we cannot have a parameter", I see only your view > on the list. The grouping mechanism would seem to be sufficient. Why do we need a special-purpose mechanism, when we can reuse a general approach? Colin > If only session multiplexing is allowed then the draft should > clearly state it and in this case I am not sure why you are > registering the video, audio and text media subtypes. > > Roni > > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > Sent: Friday, May 01, 2009 2:45 AM > To: Roni Even; vincent.roca@inrialpes.fr > Cc: avt@ietf.org; fecframe@ietf.org > Subject: RE: [AVT] [Fecframe] FW: New Version Notification for draft- > ietf-fecframe-interleaved-fec-scheme-04 > > Hi Roni, > > Thanks for the references. However, we cannot have a parameter that > will relate the FEC stream to the source as RFC 4588 did with "apt" > since a lot of possibilities (multiple sources and/or multiple > repair flows) are possible with FEC. Instead, we use grouping and > this works just fine in session multiplexing. > > Regarding SSRC multiplexing of source and FEC streams, I don't think > giving an explicit example is needed or it is a good idea for this > draft since SSRC-level grouping is just introduced in 4756bis and it > will include such examples anyway (actually the version I submitted > today includes an example). We should better only provide session > multiplexing examples in this draft. This also emphasizes the > recommended way of doing FEC. > > Reg the registration of the media types and SDP mappings, I believe > the draft has the necessary details. > > BR, > -acbegen > >> -----Original Message----- >> From: Roni Even [mailto:ron.even.tlv@gmail.com] >> Sent: Thursday, April 30, 2009 1:03 PM >> To: Ali C. Begen (abegen); vincent.roca@inrialpes.fr >> Cc: avt@ietf.org; fecframe@ietf.org >> Subject: RE: [AVT] [Fecframe] FW: New Version Notification >> for draft-ietf-fecframe-interleaved-fec-scheme-04 >> >> Ali, >> You can find examples in section 8.6 to 8.8 of RFC 4588, >> notice that there is an optional parameter for the rtx stream >> that defines the relation between the original and the rtx >> stream. Similar solution is also specified for redundant >> encoding red payload type (RFC 2198). You are offering both >> streams with different payload type numbers in the same m-line. >> In this case the media type must be video or audio same as >> the media type of the protected stream. This is why you >> needed the registration for type audio and video >> >> Roni >> >> -----Original Message----- >> From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] >> Sent: Thursday, April 30, 2009 10:01 PM >> To: Roni Even; vincent.roca@inrialpes.fr >> Cc: avt@ietf.org; fecframe@ietf.org >> Subject: RE: [AVT] [Fecframe] FW: New Version Notification >> for draft-ietf-fecframe-interleaved-fec-scheme-04 >> >> Hi Roni, >> >>> I noticed that the fec framework will allow SSRC >> >> Yes, it will not be the recommended way of using FEC, but it >> will be supported. The 4756bis draft also supports it now. >> >>> multiplexing, are you going to specify this in this draft in >>> the SDP offer answer section. >> >> I am not sure what I need to specify additionally in this >> section regarding SSRC multiplexing. Could you let me know if >> there is such an example? >> >>> Maybe you should also discuss when to use application media >>> type and when to use video or audio >> >> I believe the FEC is always application type, we did >> registration for video, audio, etc. since FEC could relate to >> sessions carrying such types. >> >> BR, >> -acbegen >> >>> >>> >>> Roni >>> >>> >>> >>> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On >>> Behalf Of Ali C. Begen (abegen) >>> Sent: Thursday, April 30, 2009 3:54 PM >>> To: vincent.roca@inrialpes.fr >>> Cc: avt@ietf.org; fecframe@ietf.org >>> Subject: Re: [AVT] [Fecframe] FW: New Version Notification >>> for draft-ietf-fecframe-interleaved-fec-scheme-04 >>> >>> >>> >>> Hi Vincent >>> >>> This draft is not an fec scheme so it is not related to fec >>> framework. It is an rtp payload format draft. The wglc has >>> been running almost a month now. If you have comments in this >>> perspective, pls submit them soon. >>> >>> >>> >>> >>> -acbegen >>> >>> ----- Original Message ----- >>> From: Vincent Roca >>> To: Ali C. Begen (abegen) >>> Cc: fecframe@ietf.org ; avt@ietf.org >> >>> Sent: Thu Apr 30 03:58:35 2009 >>> Subject: Re: [Fecframe] FW: New Version Notification for >>> draft-ietf-fecframe-interleaved-fec-scheme-04 >>> >>> Hello Ali, >>> >>> I'm not in favor of finalizing the WGLC for this document. >>> IMHO we must, >>> first of all, finalize the framework document itself. >>> >>> For instance, the terminology used by the interleaved-fec-scheme I-D >>> (section 3.1.) is not in line with the terminology used by the >>> fecframe-framework-03 I-D (Section 2): >>> "Source Flow" vs. "Source data flow" >>> "Repair Flow" vs. "Repair data flow" >>> "Source Symbol" vs. nothing >>> "Repair Symbol" vs. nothing >>> "Source Packet" vs. nothing >>> "Repair Packet" vs. nothing >>> And as I said before, IMHO the terminology proposed in the framework >>> I-D should be discussed too. >>> >>> So let's do things in the right order, especially as the framework >>> WGLC finishes soon. >>> >>> Additionally, I may have some comments for the >>> interleaved-fec-scheme-04 >>> I-D. Since I missed the WGLC deadline, you have the right to >>> blame me ;-) >>> and I apologize in advance. >>> >>> Regards, >>> >>> Vincent >>> >>> >>> Ali C. Begen (abegen) wrote: >>>> This version addresses the comments received from fecframe >>> and avt so far. >>>> >>> http://www.ietf.org/internet-drafts/draft-ietf-fecframe-interl >> eaved-fec-scheme-04.txt >>>> >>>> >>>> Fecframe chairs, >>>> >>>> Could we proceed and finalize WGLC? >>>> >>>> -acbegen >>>> >>>> >>>> -----Original Message----- >>>> From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] >>>> Sent: Wednesday, April 29, 2009 2:56 PM >>>> To: Ali C. Begen (abegen) >>>> Subject: New Version Notification for >>> draft-ietf-fecframe-interleaved-fec-scheme-04 >>>> >>>> >>>> A new version of I-D, >>> draft-ietf-fecframe-interleaved-fec-scheme-04.txt has been >>> successfuly submitted by Ali Begen and posted to the IETF >> repository. >>>> >>>> Filename: draft-ietf-fecframe-interleaved-fec-scheme >>>> Revision: 04 >>>> Title: RTP Payload Format for 1-D >>> Interleaved Parity FEC >>>> Creation_date: 2009-04-29 >>>> WG ID: fecframe >>>> Number_of_pages: 31 >>>> >>>> Abstract: >>>> This document defines a new RTP payload format for the >> Forward Error >>>> Correction (FEC) that is generated by the 1-D interleaved >>> parity code >>>> from a source media encapsulated in RTP. The 1-D >> interleaved parity >>>> code is a systematic code, where a number of repair symbols are >>>> generated from a set of source symbols and sent in a repair flow >>>> separate from the source flow that carries the source >> symbols. The >>>> 1-D interleaved parity code offers a good protection >> against bursty >>>> packet losses at a cost of decent complexity. The new >>> payload format >>>> defined in this document is used (with some exceptions) >> as a part of >>>> the DVB Application-layer FEC specification. >>>> >>> >>>> >>>> >>>> The IETF Secretariat. >>>> >>>> >>>> _______________________________________________ >>>> Fecframe mailing list >>>> Fecframe@ietf.org >>>> https://www.ietf.org/mailman/listinfo/fecframe >>> >>> >> >> > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt -- Colin Perkins http://csperkins.org/ From ron.even.tlv@gmail.com Fri May 1 03:23:05 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4A5B3A6D78; Fri, 1 May 2009 03:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.183 X-Spam-Level: X-Spam-Status: No, score=-2.183 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d5ZM3+JSU23q; Fri, 1 May 2009 03:23:04 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 707513A6C4E; Fri, 1 May 2009 03:23:03 -0700 (PDT) Received: by fxm2 with SMTP id 2so2260882fxm.37 for ; Fri, 01 May 2009 03:24:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=Gzdnw3DdSyydl/WJn3EFuJKqVUVskiZPpSk7lWLZcow=; b=VpmPg8rLzmThtXqCYrpJ7Yv/rws1pa4fIZhMt/PqQkGGd4voZEfFVILLiWB9yAD8c6 SUgpW/6Be1aKuOIwHHJS23qDEhuKAgDxD7T/hYT9P7SqXKyRXMoGQ6oNrEuZDdrUYLxA hEmI+IW7KGodTdItrbOvDfm3GqRhDlYNDt+1E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=X/EMO0Q/UvUxOhEVAk8Wdh4yD+lzl+Q/w783s+nKPcCypustEyTVj/ieD9t+8D4ecG swPjVbJ5rWf7D3ODhWDHjMtTHI4Q3KqqFSmqZTVumvk2bRhdKLZ7472yyj7T47WHiXw3 RgNfclhhcleyhydHql71CORFMTVzqx6IRq93c= Received: by 10.86.86.10 with SMTP id j10mr2771498fgb.37.1241173466324; Fri, 01 May 2009 03:24:26 -0700 (PDT) Received: from windows8d787f9 (bzq-79-177-57-219.red.bezeqint.net [79.177.57.219]) by mx.google.com with ESMTPS id l19sm550988fgb.17.2009.05.01.03.24.19 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 01 May 2009 03:24:25 -0700 (PDT) From: "Roni Even" To: "'Colin Perkins'" References: <04CAD96D4C5A3D48B1919248A8FE0D54066184FC@xmb-sjc-215.amer.cisco.com> <49f9ea83.0637560a.4488.62d2@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D540934913F@xmb-sjc-215.amer.cisco.com> <49fa0498.0405560a.615f.677e@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D540934937B@xmb-sjc-215.amer.cisco.com> <49fa9d9c.0305560a.5885.7b1f@mx.google.com> <8BEBE133-BC38-4001-8083-190782BF9949@csperkins.org> In-Reply-To: <8BEBE133-BC38-4001-8083-190782BF9949@csperkins.org> Date: Fri, 1 May 2009 13:22:18 +0300 Message-ID: <49facdd9.1358560a.4af5.fffff1ed@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnKPwmfVmenxPpkQq6VFXZFKfLSIgABp6gw Content-Language: en-us Cc: avt@ietf.org, fecframe@ietf.org Subject: Re: [AVT] [Fecframe] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 10:23:05 -0000 Colin, I am not sure that grouping will work when you have SSRC multiplexing and both the protected stream and the fec stream are in the same m-line, the mid attribute is per m-line Roni -----Original Message----- From: Colin Perkins [mailto:csp@csperkins.org] Sent: Friday, May 01, 2009 12:27 PM To: Roni Even Cc: 'Ali C. Begen (abegen)'; avt@ietf.org; fecframe@ietf.org Subject: Re: [AVT] [Fecframe] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-04 On 1 May 2009, at 07:56, Roni Even wrote: > Hi Ali, > This is up to the WG to decide if they want to have support for SSRC > multiplexing and the implications of this support. I am not sure > what you mean by "we cannot have a parameter", I see only your view > on the list. The grouping mechanism would seem to be sufficient. Why do we need a special-purpose mechanism, when we can reuse a general approach? Colin > If only session multiplexing is allowed then the draft should > clearly state it and in this case I am not sure why you are > registering the video, audio and text media subtypes. > > Roni > > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > Sent: Friday, May 01, 2009 2:45 AM > To: Roni Even; vincent.roca@inrialpes.fr > Cc: avt@ietf.org; fecframe@ietf.org > Subject: RE: [AVT] [Fecframe] FW: New Version Notification for draft- > ietf-fecframe-interleaved-fec-scheme-04 > > Hi Roni, > > Thanks for the references. However, we cannot have a parameter that > will relate the FEC stream to the source as RFC 4588 did with "apt" > since a lot of possibilities (multiple sources and/or multiple > repair flows) are possible with FEC. Instead, we use grouping and > this works just fine in session multiplexing. > > Regarding SSRC multiplexing of source and FEC streams, I don't think > giving an explicit example is needed or it is a good idea for this > draft since SSRC-level grouping is just introduced in 4756bis and it > will include such examples anyway (actually the version I submitted > today includes an example). We should better only provide session > multiplexing examples in this draft. This also emphasizes the > recommended way of doing FEC. > > Reg the registration of the media types and SDP mappings, I believe > the draft has the necessary details. > > BR, > -acbegen > >> -----Original Message----- >> From: Roni Even [mailto:ron.even.tlv@gmail.com] >> Sent: Thursday, April 30, 2009 1:03 PM >> To: Ali C. Begen (abegen); vincent.roca@inrialpes.fr >> Cc: avt@ietf.org; fecframe@ietf.org >> Subject: RE: [AVT] [Fecframe] FW: New Version Notification >> for draft-ietf-fecframe-interleaved-fec-scheme-04 >> >> Ali, >> You can find examples in section 8.6 to 8.8 of RFC 4588, >> notice that there is an optional parameter for the rtx stream >> that defines the relation between the original and the rtx >> stream. Similar solution is also specified for redundant >> encoding red payload type (RFC 2198). You are offering both >> streams with different payload type numbers in the same m-line. >> In this case the media type must be video or audio same as >> the media type of the protected stream. This is why you >> needed the registration for type audio and video >> >> Roni >> >> -----Original Message----- >> From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] >> Sent: Thursday, April 30, 2009 10:01 PM >> To: Roni Even; vincent.roca@inrialpes.fr >> Cc: avt@ietf.org; fecframe@ietf.org >> Subject: RE: [AVT] [Fecframe] FW: New Version Notification >> for draft-ietf-fecframe-interleaved-fec-scheme-04 >> >> Hi Roni, >> >>> I noticed that the fec framework will allow SSRC >> >> Yes, it will not be the recommended way of using FEC, but it >> will be supported. The 4756bis draft also supports it now. >> >>> multiplexing, are you going to specify this in this draft in >>> the SDP offer answer section. >> >> I am not sure what I need to specify additionally in this >> section regarding SSRC multiplexing. Could you let me know if >> there is such an example? >> >>> Maybe you should also discuss when to use application media >>> type and when to use video or audio >> >> I believe the FEC is always application type, we did >> registration for video, audio, etc. since FEC could relate to >> sessions carrying such types. >> >> BR, >> -acbegen >> >>> >>> >>> Roni >>> >>> >>> >>> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On >>> Behalf Of Ali C. Begen (abegen) >>> Sent: Thursday, April 30, 2009 3:54 PM >>> To: vincent.roca@inrialpes.fr >>> Cc: avt@ietf.org; fecframe@ietf.org >>> Subject: Re: [AVT] [Fecframe] FW: New Version Notification >>> for draft-ietf-fecframe-interleaved-fec-scheme-04 >>> >>> >>> >>> Hi Vincent >>> >>> This draft is not an fec scheme so it is not related to fec >>> framework. It is an rtp payload format draft. The wglc has >>> been running almost a month now. If you have comments in this >>> perspective, pls submit them soon. >>> >>> >>> >>> >>> -acbegen >>> >>> ----- Original Message ----- >>> From: Vincent Roca >>> To: Ali C. Begen (abegen) >>> Cc: fecframe@ietf.org ; avt@ietf.org >> >>> Sent: Thu Apr 30 03:58:35 2009 >>> Subject: Re: [Fecframe] FW: New Version Notification for >>> draft-ietf-fecframe-interleaved-fec-scheme-04 >>> >>> Hello Ali, >>> >>> I'm not in favor of finalizing the WGLC for this document. >>> IMHO we must, >>> first of all, finalize the framework document itself. >>> >>> For instance, the terminology used by the interleaved-fec-scheme I-D >>> (section 3.1.) is not in line with the terminology used by the >>> fecframe-framework-03 I-D (Section 2): >>> "Source Flow" vs. "Source data flow" >>> "Repair Flow" vs. "Repair data flow" >>> "Source Symbol" vs. nothing >>> "Repair Symbol" vs. nothing >>> "Source Packet" vs. nothing >>> "Repair Packet" vs. nothing >>> And as I said before, IMHO the terminology proposed in the framework >>> I-D should be discussed too. >>> >>> So let's do things in the right order, especially as the framework >>> WGLC finishes soon. >>> >>> Additionally, I may have some comments for the >>> interleaved-fec-scheme-04 >>> I-D. Since I missed the WGLC deadline, you have the right to >>> blame me ;-) >>> and I apologize in advance. >>> >>> Regards, >>> >>> Vincent >>> >>> >>> Ali C. Begen (abegen) wrote: >>>> This version addresses the comments received from fecframe >>> and avt so far. >>>> >>> http://www.ietf.org/internet-drafts/draft-ietf-fecframe-interl >> eaved-fec-scheme-04.txt >>>> >>>> >>>> Fecframe chairs, >>>> >>>> Could we proceed and finalize WGLC? >>>> >>>> -acbegen >>>> >>>> >>>> -----Original Message----- >>>> From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] >>>> Sent: Wednesday, April 29, 2009 2:56 PM >>>> To: Ali C. Begen (abegen) >>>> Subject: New Version Notification for >>> draft-ietf-fecframe-interleaved-fec-scheme-04 >>>> >>>> >>>> A new version of I-D, >>> draft-ietf-fecframe-interleaved-fec-scheme-04.txt has been >>> successfuly submitted by Ali Begen and posted to the IETF >> repository. >>>> >>>> Filename: draft-ietf-fecframe-interleaved-fec-scheme >>>> Revision: 04 >>>> Title: RTP Payload Format for 1-D >>> Interleaved Parity FEC >>>> Creation_date: 2009-04-29 >>>> WG ID: fecframe >>>> Number_of_pages: 31 >>>> >>>> Abstract: >>>> This document defines a new RTP payload format for the >> Forward Error >>>> Correction (FEC) that is generated by the 1-D interleaved >>> parity code >>>> from a source media encapsulated in RTP. The 1-D >> interleaved parity >>>> code is a systematic code, where a number of repair symbols are >>>> generated from a set of source symbols and sent in a repair flow >>>> separate from the source flow that carries the source >> symbols. The >>>> 1-D interleaved parity code offers a good protection >> against bursty >>>> packet losses at a cost of decent complexity. The new >>> payload format >>>> defined in this document is used (with some exceptions) >> as a part of >>>> the DVB Application-layer FEC specification. >>>> >>> >>>> >>>> >>>> The IETF Secretariat. >>>> >>>> >>>> _______________________________________________ >>>> Fecframe mailing list >>>> Fecframe@ietf.org >>>> https://www.ietf.org/mailman/listinfo/fecframe >>> >>> >> >> > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt -- Colin Perkins http://csperkins.org/ From jonathan@vidyo.com Fri May 1 08:39:06 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C20828C22D; Fri, 1 May 2009 08:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CE+aDClqwkpR; Fri, 1 May 2009 08:39:04 -0700 (PDT) Received: from mx1.myoutlookonline.com (mx1.myoutlookonline.com [64.95.72.238]) by core3.amsl.com (Postfix) with ESMTP id B31E73A7092; Fri, 1 May 2009 08:36:48 -0700 (PDT) Received: from be150.mail.lan ([10.110.20.150]) by mx1.myoutlookonline.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 1 May 2009 11:38:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 1 May 2009 11:38:07 -0400 Message-ID: <6B55710E7F51AD4B93F336052113B85F8C7C93@be150.mail.lan> In-Reply-To: <49facdd9.1358560a.4af5.fffff1ed@mx.google.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] [Fecframe] FW: New VersionNotification for draft-ietf-fecframe-interleaved-fec-scheme-04 Thread-Index: AcnKPwmfVmenxPpkQq6VFXZFKfLSIgABp6gwAAtB7mA= References: <04CAD96D4C5A3D48B1919248A8FE0D54066184FC@xmb-sjc-215.amer.cisco.com><49f9ea83.0637560a.4488.62d2@mx.google.com><04CAD96D4C5A3D48B1919248A8FE0D540934913F@xmb-sjc-215.amer.cisco.com><49fa0498.0405560a.615f.677e@mx.google.com><04CAD96D4C5A3D48B1919248A8FE0D540934937B@xmb-sjc-215.amer.cisco.com><49fa9d9c.0305560a.5885.7b1f@mx.google.com><8BEBE133-BC38-4001-8083-190782BF9949@csperkins.org> <49facdd9.1358560a.4af5.fffff1ed@mx.google.com> From: "Jonathan Lennox" To: "Roni Even" , "Colin Perkins" X-OriginalArrivalTime: 01 May 2009 15:38:12.0514 (UTC) FILETIME=[D62D3820:01C9CA72] Cc: avt@ietf.org, fecframe@ietf.org Subject: Re: [AVT] [Fecframe] FW: New VersionNotification for draft-ietf-fecframe-interleaved-fec-scheme-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 15:39:06 -0000 The intention is to use ssrc-group (from draft-ietf-mmusic-source-attributes) for ssrc grouping. --=20 Jonathan Lennox Vidyo, Inc jonathan@vidyo.com > -----Original Message----- > From: Roni Even [mailto:ron.even.tlv@gmail.com] > Sent: Friday, May 01, 2009 6:22 AM > To: 'Colin Perkins' > Cc: avt@ietf.org; fecframe@ietf.org > Subject: Re: [AVT] [Fecframe] FW: New VersionNotification for draft- > ietf-fecframe-interleaved-fec-scheme-04 >=20 > Colin, > I am not sure that grouping will work when you have SSRC multiplexing > and > both the protected stream and the fec stream are in the same m-line, > the mid > attribute is per m-line >=20 >=20 > Roni >=20 > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org] > Sent: Friday, May 01, 2009 12:27 PM > To: Roni Even > Cc: 'Ali C. Begen (abegen)'; avt@ietf.org; fecframe@ietf.org > Subject: Re: [AVT] [Fecframe] FW: New Version Notification for > draft-ietf-fecframe-interleaved-fec-scheme-04 >=20 > On 1 May 2009, at 07:56, Roni Even wrote: > > Hi Ali, > > This is up to the WG to decide if they want to have support for SSRC > > multiplexing and the implications of this support. I am not sure > > what you mean by "we cannot have a parameter", I see only your view > > on the list. >=20 > The grouping mechanism would seem to be sufficient. Why do we need a > special-purpose mechanism, when we can reuse a general approach? >=20 > Colin >=20 >=20 >=20 >=20 > > If only session multiplexing is allowed then the draft should > > clearly state it and in this case I am not sure why you are > > registering the video, audio and text media subtypes. > > > > Roni > > > > -----Original Message----- > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > Sent: Friday, May 01, 2009 2:45 AM > > To: Roni Even; vincent.roca@inrialpes.fr > > Cc: avt@ietf.org; fecframe@ietf.org > > Subject: RE: [AVT] [Fecframe] FW: New Version Notification for draft- > > ietf-fecframe-interleaved-fec-scheme-04 > > > > Hi Roni, > > > > Thanks for the references. However, we cannot have a parameter that > > will relate the FEC stream to the source as RFC 4588 did with "apt" > > since a lot of possibilities (multiple sources and/or multiple > > repair flows) are possible with FEC. Instead, we use grouping and > > this works just fine in session multiplexing. > > > > Regarding SSRC multiplexing of source and FEC streams, I don't think > > giving an explicit example is needed or it is a good idea for this > > draft since SSRC-level grouping is just introduced in 4756bis and it > > will include such examples anyway (actually the version I submitted > > today includes an example). We should better only provide session > > multiplexing examples in this draft. This also emphasizes the > > recommended way of doing FEC. > > > > Reg the registration of the media types and SDP mappings, I believe > > the draft has the necessary details. > > > > BR, > > -acbegen > > > >> -----Original Message----- > >> From: Roni Even [mailto:ron.even.tlv@gmail.com] > >> Sent: Thursday, April 30, 2009 1:03 PM > >> To: Ali C. Begen (abegen); vincent.roca@inrialpes.fr > >> Cc: avt@ietf.org; fecframe@ietf.org > >> Subject: RE: [AVT] [Fecframe] FW: New Version Notification > >> for draft-ietf-fecframe-interleaved-fec-scheme-04 > >> > >> Ali, > >> You can find examples in section 8.6 to 8.8 of RFC 4588, > >> notice that there is an optional parameter for the rtx stream > >> that defines the relation between the original and the rtx > >> stream. Similar solution is also specified for redundant > >> encoding red payload type (RFC 2198). You are offering both > >> streams with different payload type numbers in the same m-line. > >> In this case the media type must be video or audio same as > >> the media type of the protected stream. This is why you > >> needed the registration for type audio and video > >> > >> Roni > >> > >> -----Original Message----- > >> From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > >> Sent: Thursday, April 30, 2009 10:01 PM > >> To: Roni Even; vincent.roca@inrialpes.fr > >> Cc: avt@ietf.org; fecframe@ietf.org > >> Subject: RE: [AVT] [Fecframe] FW: New Version Notification > >> for draft-ietf-fecframe-interleaved-fec-scheme-04 > >> > >> Hi Roni, > >> > >>> I noticed that the fec framework will allow SSRC > >> > >> Yes, it will not be the recommended way of using FEC, but it > >> will be supported. The 4756bis draft also supports it now. > >> > >>> multiplexing, are you going to specify this in this draft in > >>> the SDP offer answer section. > >> > >> I am not sure what I need to specify additionally in this > >> section regarding SSRC multiplexing. Could you let me know if > >> there is such an example? > >> > >>> Maybe you should also discuss when to use application media > >>> type and when to use video or audio > >> > >> I believe the FEC is always application type, we did > >> registration for video, audio, etc. since FEC could relate to > >> sessions carrying such types. > >> > >> BR, > >> -acbegen > >> > >>> > >>> > >>> Roni > >>> > >>> > >>> > >>> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > >>> Behalf Of Ali C. Begen (abegen) > >>> Sent: Thursday, April 30, 2009 3:54 PM > >>> To: vincent.roca@inrialpes.fr > >>> Cc: avt@ietf.org; fecframe@ietf.org > >>> Subject: Re: [AVT] [Fecframe] FW: New Version Notification > >>> for draft-ietf-fecframe-interleaved-fec-scheme-04 > >>> > >>> > >>> > >>> Hi Vincent > >>> > >>> This draft is not an fec scheme so it is not related to fec > >>> framework. It is an rtp payload format draft. The wglc has > >>> been running almost a month now. If you have comments in this > >>> perspective, pls submit them soon. > >>> > >>> > >>> > >>> > >>> -acbegen > >>> > >>> ----- Original Message ----- > >>> From: Vincent Roca > >>> To: Ali C. Begen (abegen) > >>> Cc: fecframe@ietf.org ; avt@ietf.org > >> > >>> Sent: Thu Apr 30 03:58:35 2009 > >>> Subject: Re: [Fecframe] FW: New Version Notification for > >>> draft-ietf-fecframe-interleaved-fec-scheme-04 > >>> > >>> Hello Ali, > >>> > >>> I'm not in favor of finalizing the WGLC for this document. > >>> IMHO we must, > >>> first of all, finalize the framework document itself. > >>> > >>> For instance, the terminology used by the interleaved-fec-scheme I- > D > >>> (section 3.1.) is not in line with the terminology used by the > >>> fecframe-framework-03 I-D (Section 2): > >>> "Source Flow" vs. "Source data flow" > >>> "Repair Flow" vs. "Repair data flow" > >>> "Source Symbol" vs. nothing > >>> "Repair Symbol" vs. nothing > >>> "Source Packet" vs. nothing > >>> "Repair Packet" vs. nothing > >>> And as I said before, IMHO the terminology proposed in the > framework > >>> I-D should be discussed too. > >>> > >>> So let's do things in the right order, especially as the framework > >>> WGLC finishes soon. > >>> > >>> Additionally, I may have some comments for the > >>> interleaved-fec-scheme-04 > >>> I-D. Since I missed the WGLC deadline, you have the right to > >>> blame me ;-) > >>> and I apologize in advance. > >>> > >>> Regards, > >>> > >>> Vincent > >>> > >>> > >>> Ali C. Begen (abegen) wrote: > >>>> This version addresses the comments received from fecframe > >>> and avt so far. > >>>> > >>> http://www.ietf.org/internet-drafts/draft-ietf-fecframe-interl > >> eaved-fec-scheme-04.txt > >>>> > >>>> > >>>> Fecframe chairs, > >>>> > >>>> Could we proceed and finalize WGLC? > >>>> > >>>> -acbegen > >>>> > >>>> > >>>> -----Original Message----- > >>>> From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > >>>> Sent: Wednesday, April 29, 2009 2:56 PM > >>>> To: Ali C. Begen (abegen) > >>>> Subject: New Version Notification for > >>> draft-ietf-fecframe-interleaved-fec-scheme-04 > >>>> > >>>> > >>>> A new version of I-D, > >>> draft-ietf-fecframe-interleaved-fec-scheme-04.txt has been > >>> successfuly submitted by Ali Begen and posted to the IETF > >> repository. > >>>> > >>>> Filename: draft-ietf-fecframe-interleaved-fec-scheme > >>>> Revision: 04 > >>>> Title: RTP Payload Format for 1-D > >>> Interleaved Parity FEC > >>>> Creation_date: 2009-04-29 > >>>> WG ID: fecframe > >>>> Number_of_pages: 31 > >>>> > >>>> Abstract: > >>>> This document defines a new RTP payload format for the > >> Forward Error > >>>> Correction (FEC) that is generated by the 1-D interleaved > >>> parity code > >>>> from a source media encapsulated in RTP. The 1-D > >> interleaved parity > >>>> code is a systematic code, where a number of repair symbols are > >>>> generated from a set of source symbols and sent in a repair flow > >>>> separate from the source flow that carries the source > >> symbols. The > >>>> 1-D interleaved parity code offers a good protection > >> against bursty > >>>> packet losses at a cost of decent complexity. The new > >>> payload format > >>>> defined in this document is used (with some exceptions) > >> as a part of > >>>> the DVB Application-layer FEC specification. > >>>> > >>> > >>>> > >>>> > >>>> The IETF Secretariat. > >>>> > >>>> > >>>> _______________________________________________ > >>>> Fecframe mailing list > >>>> Fecframe@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/fecframe > >>> > >>> > >> > >> > > > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt >=20 >=20 >=20 > -- > Colin Perkins > http://csperkins.org/ >=20 >=20 >=20 > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From abegen@cisco.com Fri May 1 09:04:15 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 601753A70F8; Fri, 1 May 2009 09:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.378 X-Spam-Level: X-Spam-Status: No, score=-6.378 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4WncsjtpUFde; Fri, 1 May 2009 09:04:13 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id A78D23A70C6; Fri, 1 May 2009 09:04:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,279,1238976000"; d="scan'208";a="161009828" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 01 May 2009 16:05:37 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n41G5bi2001065; Fri, 1 May 2009 09:05:37 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n41G5bwR008757; Fri, 1 May 2009 16:05:37 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 May 2009 09:05:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 1 May 2009 09:05:11 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54093494E3@xmb-sjc-215.amer.cisco.com> In-Reply-To: <6B55710E7F51AD4B93F336052113B85F8C7C93@be150.mail.lan> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] [AVT] FW: NewVersionNotification for draft-ietf-fecframe-interleaved-fec-scheme-04 Thread-Index: AcnKPwmfVmenxPpkQq6VFXZFKfLSIgABp6gwAAtB7mAAAPAN4A== References: <04CAD96D4C5A3D48B1919248A8FE0D54066184FC@xmb-sjc-215.amer.cisco.com><49f9ea83.0637560a.4488.62d2@mx.google.com><04CAD96D4C5A3D48B1919248A8FE0D540934913F@xmb-sjc-215.amer.cisco.com><49fa0498.0405560a.615f.677e@mx.google.com><04CAD96D4C5A3D48B1919248A8FE0D540934937B@xmb-sjc-215.amer.cisco.com><49fa9d9c.0305560a.5885.7b1f@mx.google.com><8BEBE133-BC38-4001-8083-190782BF9949@csperkins.org><49facdd9.1358560a.4af5.fffff1ed@mx.google.com> <6B55710E7F51AD4B93F336052113B85F8C7C93@be150.mail.lan> From: "Ali C. Begen (abegen)" To: "Jonathan Lennox" , "Roni Even" , "Colin Perkins" X-OriginalArrivalTime: 01 May 2009 16:05:37.0406 (UTC) FILETIME=[AA9BD1E0:01C9CA76] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=11443; t=1241193937; x=1242057937; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20RE=3A=20[Fecframe]=20[AVT]=20FW=3A=20NewVersion Notification=09for=09draft-ietf-fecframe-interleaved-fec-sch eme-04 |Sender:=20; bh=hIL3uqLFmyRfVD92lAyEfbAr9vizIfbadBYCCo+fcFo=; b=eGttK+uWFba41FA2evt7Ec1PlAEwj05v3Uiv7ir5GU9GMX6YdWNO8E0qw5 e1U29dNO3EOA0b9VxmKfrcb7mdAuIc/RnCLqlhzM5hJD5aTthv+SGue4v85X 1TwHSbU4bOgvlXWHsbibIlgOuTtLz+ZLLGi/4ST0+n7FajNyTgHUU=; Authentication-Results: sj-dkim-1; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: avt@ietf.org, fecframe@ietf.org Subject: Re: [AVT] [Fecframe] FW: NewVersionNotification for draft-ietf-fecframe-interleaved-fec-scheme-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 16:04:15 -0000 Yes, this has been discussed in mmusic very recently and I updated the = 4756bis draft accordingly. http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc4756bis-02.txt -acbegen =20 > -----Original Message----- > From: fecframe-bounces@ietf.org=20 > [mailto:fecframe-bounces@ietf.org] On Behalf Of Jonathan Lennox > Sent: Friday, May 01, 2009 8:38 AM > To: Roni Even; Colin Perkins > Cc: avt@ietf.org; fecframe@ietf.org > Subject: Re: [Fecframe] [AVT] FW: NewVersionNotification for=20 > draft-ietf-fecframe-interleaved-fec-scheme-04 >=20 > The intention is to use ssrc-group (from > draft-ietf-mmusic-source-attributes) for ssrc grouping. >=20 > --=20 > Jonathan Lennox > Vidyo, Inc > jonathan@vidyo.com >=20 >=20 > > -----Original Message----- > > From: Roni Even [mailto:ron.even.tlv@gmail.com] > > Sent: Friday, May 01, 2009 6:22 AM > > To: 'Colin Perkins' > > Cc: avt@ietf.org; fecframe@ietf.org > > Subject: Re: [AVT] [Fecframe] FW: New VersionNotification for draft- > > ietf-fecframe-interleaved-fec-scheme-04 > >=20 > > Colin, > > I am not sure that grouping will work when you have SSRC=20 > multiplexing > > and > > both the protected stream and the fec stream are in the same m-line, > > the mid > > attribute is per m-line > >=20 > >=20 > > Roni > >=20 > > -----Original Message----- > > From: Colin Perkins [mailto:csp@csperkins.org] > > Sent: Friday, May 01, 2009 12:27 PM > > To: Roni Even > > Cc: 'Ali C. Begen (abegen)'; avt@ietf.org; fecframe@ietf.org > > Subject: Re: [AVT] [Fecframe] FW: New Version Notification for > > draft-ietf-fecframe-interleaved-fec-scheme-04 > >=20 > > On 1 May 2009, at 07:56, Roni Even wrote: > > > Hi Ali, > > > This is up to the WG to decide if they want to have=20 > support for SSRC > > > multiplexing and the implications of this support. I am not sure > > > what you mean by "we cannot have a parameter", I see only=20 > your view > > > on the list. > >=20 > > The grouping mechanism would seem to be sufficient. Why do we need a > > special-purpose mechanism, when we can reuse a general approach? > >=20 > > Colin > >=20 > >=20 > >=20 > >=20 > > > If only session multiplexing is allowed then the draft should > > > clearly state it and in this case I am not sure why you are > > > registering the video, audio and text media subtypes. > > > > > > Roni > > > > > > -----Original Message----- > > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > > Sent: Friday, May 01, 2009 2:45 AM > > > To: Roni Even; vincent.roca@inrialpes.fr > > > Cc: avt@ietf.org; fecframe@ietf.org > > > Subject: RE: [AVT] [Fecframe] FW: New Version Notification for > draft- > > > ietf-fecframe-interleaved-fec-scheme-04 > > > > > > Hi Roni, > > > > > > Thanks for the references. However, we cannot have a=20 > parameter that > > > will relate the FEC stream to the source as RFC 4588 did=20 > with "apt" > > > since a lot of possibilities (multiple sources and/or multiple > > > repair flows) are possible with FEC. Instead, we use grouping and > > > this works just fine in session multiplexing. > > > > > > Regarding SSRC multiplexing of source and FEC streams, I=20 > don't think > > > giving an explicit example is needed or it is a good idea for this > > > draft since SSRC-level grouping is just introduced in=20 > 4756bis and it > > > will include such examples anyway (actually the version I=20 > submitted > > > today includes an example). We should better only provide session > > > multiplexing examples in this draft. This also emphasizes the > > > recommended way of doing FEC. > > > > > > Reg the registration of the media types and SDP mappings,=20 > I believe > > > the draft has the necessary details. > > > > > > BR, > > > -acbegen > > > > > >> -----Original Message----- > > >> From: Roni Even [mailto:ron.even.tlv@gmail.com] > > >> Sent: Thursday, April 30, 2009 1:03 PM > > >> To: Ali C. Begen (abegen); vincent.roca@inrialpes.fr > > >> Cc: avt@ietf.org; fecframe@ietf.org > > >> Subject: RE: [AVT] [Fecframe] FW: New Version Notification > > >> for draft-ietf-fecframe-interleaved-fec-scheme-04 > > >> > > >> Ali, > > >> You can find examples in section 8.6 to 8.8 of RFC 4588, > > >> notice that there is an optional parameter for the rtx stream > > >> that defines the relation between the original and the rtx > > >> stream. Similar solution is also specified for redundant > > >> encoding red payload type (RFC 2198). You are offering both > > >> streams with different payload type numbers in the same m-line. > > >> In this case the media type must be video or audio same as > > >> the media type of the protected stream. This is why you > > >> needed the registration for type audio and video > > >> > > >> Roni > > >> > > >> -----Original Message----- > > >> From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > >> Sent: Thursday, April 30, 2009 10:01 PM > > >> To: Roni Even; vincent.roca@inrialpes.fr > > >> Cc: avt@ietf.org; fecframe@ietf.org > > >> Subject: RE: [AVT] [Fecframe] FW: New Version Notification > > >> for draft-ietf-fecframe-interleaved-fec-scheme-04 > > >> > > >> Hi Roni, > > >> > > >>> I noticed that the fec framework will allow SSRC > > >> > > >> Yes, it will not be the recommended way of using FEC, but it > > >> will be supported. The 4756bis draft also supports it now. > > >> > > >>> multiplexing, are you going to specify this in this draft in > > >>> the SDP offer answer section. > > >> > > >> I am not sure what I need to specify additionally in this > > >> section regarding SSRC multiplexing. Could you let me know if > > >> there is such an example? > > >> > > >>> Maybe you should also discuss when to use application media > > >>> type and when to use video or audio > > >> > > >> I believe the FEC is always application type, we did > > >> registration for video, audio, etc. since FEC could relate to > > >> sessions carrying such types. > > >> > > >> BR, > > >> -acbegen > > >> > > >>> > > >>> > > >>> Roni > > >>> > > >>> > > >>> > > >>> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > > >>> Behalf Of Ali C. Begen (abegen) > > >>> Sent: Thursday, April 30, 2009 3:54 PM > > >>> To: vincent.roca@inrialpes.fr > > >>> Cc: avt@ietf.org; fecframe@ietf.org > > >>> Subject: Re: [AVT] [Fecframe] FW: New Version Notification > > >>> for draft-ietf-fecframe-interleaved-fec-scheme-04 > > >>> > > >>> > > >>> > > >>> Hi Vincent > > >>> > > >>> This draft is not an fec scheme so it is not related to fec > > >>> framework. It is an rtp payload format draft. The wglc has > > >>> been running almost a month now. If you have comments in this > > >>> perspective, pls submit them soon. > > >>> > > >>> > > >>> > > >>> > > >>> -acbegen > > >>> > > >>> ----- Original Message ----- > > >>> From: Vincent Roca > > >>> To: Ali C. Begen (abegen) > > >>> Cc: fecframe@ietf.org ; avt@ietf.org > > >> > > >>> Sent: Thu Apr 30 03:58:35 2009 > > >>> Subject: Re: [Fecframe] FW: New Version Notification for > > >>> draft-ietf-fecframe-interleaved-fec-scheme-04 > > >>> > > >>> Hello Ali, > > >>> > > >>> I'm not in favor of finalizing the WGLC for this document. > > >>> IMHO we must, > > >>> first of all, finalize the framework document itself. > > >>> > > >>> For instance, the terminology used by the interleaved-fec-scheme > I- > > D > > >>> (section 3.1.) is not in line with the terminology used by the > > >>> fecframe-framework-03 I-D (Section 2): > > >>> "Source Flow" vs. "Source data flow" > > >>> "Repair Flow" vs. "Repair data flow" > > >>> "Source Symbol" vs. nothing > > >>> "Repair Symbol" vs. nothing > > >>> "Source Packet" vs. nothing > > >>> "Repair Packet" vs. nothing > > >>> And as I said before, IMHO the terminology proposed in the > > framework > > >>> I-D should be discussed too. > > >>> > > >>> So let's do things in the right order, especially as=20 > the framework > > >>> WGLC finishes soon. > > >>> > > >>> Additionally, I may have some comments for the > > >>> interleaved-fec-scheme-04 > > >>> I-D. Since I missed the WGLC deadline, you have the right to > > >>> blame me ;-) > > >>> and I apologize in advance. > > >>> > > >>> Regards, > > >>> > > >>> Vincent > > >>> > > >>> > > >>> Ali C. Begen (abegen) wrote: > > >>>> This version addresses the comments received from fecframe > > >>> and avt so far. > > >>>> > > >>> http://www.ietf.org/internet-drafts/draft-ietf-fecframe-interl > > >> eaved-fec-scheme-04.txt > > >>>> > > >>>> > > >>>> Fecframe chairs, > > >>>> > > >>>> Could we proceed and finalize WGLC? > > >>>> > > >>>> -acbegen > > >>>> > > >>>> > > >>>> -----Original Message----- > > >>>> From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > > >>>> Sent: Wednesday, April 29, 2009 2:56 PM > > >>>> To: Ali C. Begen (abegen) > > >>>> Subject: New Version Notification for > > >>> draft-ietf-fecframe-interleaved-fec-scheme-04 > > >>>> > > >>>> > > >>>> A new version of I-D, > > >>> draft-ietf-fecframe-interleaved-fec-scheme-04.txt has been > > >>> successfuly submitted by Ali Begen and posted to the IETF > > >> repository. > > >>>> > > >>>> Filename: draft-ietf-fecframe-interleaved-fec-scheme > > >>>> Revision: 04 > > >>>> Title: RTP Payload Format for 1-D > > >>> Interleaved Parity FEC > > >>>> Creation_date: 2009-04-29 > > >>>> WG ID: fecframe > > >>>> Number_of_pages: 31 > > >>>> > > >>>> Abstract: > > >>>> This document defines a new RTP payload format for the > > >> Forward Error > > >>>> Correction (FEC) that is generated by the 1-D interleaved > > >>> parity code > > >>>> from a source media encapsulated in RTP. The 1-D > > >> interleaved parity > > >>>> code is a systematic code, where a number of repair symbols are > > >>>> generated from a set of source symbols and sent in a=20 > repair flow > > >>>> separate from the source flow that carries the source > > >> symbols. The > > >>>> 1-D interleaved parity code offers a good protection > > >> against bursty > > >>>> packet losses at a cost of decent complexity. The new > > >>> payload format > > >>>> defined in this document is used (with some exceptions) > > >> as a part of > > >>>> the DVB Application-layer FEC specification. > > >>>> > > >>> > > >>>> > > >>>> > > >>>> The IETF Secretariat. > > >>>> > > >>>> > > >>>> _______________________________________________ > > >>>> Fecframe mailing list > > >>>> Fecframe@ietf.org > > >>>> https://www.ietf.org/mailman/listinfo/fecframe > > >>> > > >>> > > >> > > >> > > > > > > _______________________________________________ > > > Audio/Video Transport Working Group > > > avt@ietf.org > > > https://www.ietf.org/mailman/listinfo/avt > >=20 > >=20 > >=20 > > -- > > Colin Perkins > > http://csperkins.org/ > >=20 > >=20 > >=20 > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt >=20 > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe >=20 From versteb@cisco.com Fri May 1 10:38:27 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 534CB3A7097 for ; Fri, 1 May 2009 10:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GbMUlrvC2kwp for ; Fri, 1 May 2009 10:38:26 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 280883A7042 for ; Fri, 1 May 2009 10:38:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,280,1238976000"; d="scan'208,217";a="296649102" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 01 May 2009 17:39:50 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n41HdorU019628; Fri, 1 May 2009 10:39:50 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n41HdmlJ021166; Fri, 1 May 2009 17:39:50 GMT Received: from xmb-rtp-21d.amer.cisco.com ([64.102.31.116]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 May 2009 13:39:47 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9CA83.D23BCE2D" Date: Fri, 1 May 2009 13:39:46 -0400 Message-ID: <81B9B88E2F9D574AA5328A85547CDE91011B45CE@xmb-rtp-21d.amer.cisco.com> In-Reply-To: <49fa06b0.0637560a.430f.ffffb534@mx.google.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions (RAMS)as a working group item Thread-Index: AcnJz//7XHcxZE/BR5mcPjQI3rd8QwAs5fMQ References: <49fa06b0.0637560a.430f.ffffb534@mx.google.com> From: "Bill Ver Steeg (versteb)" To: "Roni Even" , X-OriginalArrivalTime: 01 May 2009 17:39:47.0672 (UTC) FILETIME=[D26DFD80:01C9CA83] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6149; t=1241199590; x=1242063590; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=versteb@cisco.com; z=From:=20=22Bill=20Ver=20Steeg=20(versteb)=22=20 |Subject:=20RE=3A=20[AVT]=20Adopting=20Rapid=20Acquisition= 20of=20Multicast=20RTP=20Sessions=20(RAMS)as=20a=20working=2 0group=20item |Sender:=20; bh=3nKYW3ImoXY3A1lP2VxhqJGCSNjGmF0vu3NDQAOeyc8=; b=av7pMUG3ZqanGSy6yss5nr4sZnoFK73EjDI5h1s5NeADZdIPSnAgyz4iIV Vnih3FXmWSnBJyOJVZJFkkqpMAQWbUnhRUW88AziKoua//9vEBdQfac/0Fx0 y+vArcsq3e; Authentication-Results: sj-dkim-2; header.From=versteb@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: Tom Taylor Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions (RAMS)as a working group item X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 17:38:27 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9CA83.D23BCE2D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It probably goes without saying, but I am very interested in moving this work forward. =20 Bill verSteeg ________________________________ From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Roni Even Sent: Thursday, April 30, 2009 4:13 PM To: avt@ietf.org Cc: 'Tom Taylor' Subject: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions (RAMS)as a working group item Hi, I would like to ask if there is interest to adopt Rapid Acquisition of Multicast RTP Sessions (RAMS) as a working group item. The suggestion is to start the work using http://tools.ietf.org/html/draft-versteeg-avt-rapid-synchronization-for- rtp-03 as the initial text for the work. =20 I would also like to suggest that Bill Versteeg will be the editor of the WG document if adopted. =20 Please send any feedback to the mailing list by Friday May 8th. If there will be a consensus we will accept this topic and have the above draft as the initial document. =20 Thanks Roni Even AVT co-chair ------_=_NextPart_001_01C9CA83.D23BCE2D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
It probably goes without saying, but I am very = interested=20 in moving this work forward.
 
Bill verSteeg

From: avt-bounces@ietf.org=20 [mailto:avt-bounces@ietf.org] On Behalf Of Roni = Even
Sent:=20 Thursday, April 30, 2009 4:13 PM
To: = avt@ietf.org
Cc: 'Tom=20 Taylor'
Subject: [AVT] Adopting Rapid Acquisition of Multicast = RTP=20 Sessions (RAMS)as a working group item

Hi,

I would like to ask if there is interest to adopt = Rapid = Acquisition of=20 Multicast RTP Sessions (RAMS) as a working group item. The suggestion is = to=20 start the work using http://tools.ietf.org/html/draft-versteeg-avt-rapid-synchr= onization-for-rtp-03=20 as the initial text for the work.

 

I would = also like to=20 suggest that Bill Versteeg will be the editor of the WG document if=20 adopted.

 

Please send = any=20 feedback to the mailing list by Friday May 8th. If = there will=20 be a consensus we will accept this topic and have the above draft as the = initial=20 document.

 

Thanks

Roni=20 Even

AVT=20 co-chair

------_=_NextPart_001_01C9CA83.D23BCE2D-- From oritl@microsoft.com Fri May 1 10:55:13 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7C053A6B1F for ; Fri, 1 May 2009 10:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.669 X-Spam-Level: X-Spam-Status: No, score=-9.669 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9mEI973XPi1 for ; Fri, 1 May 2009 10:55:13 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id ED6003A69B2 for ; Fri, 1 May 2009 10:55:12 -0700 (PDT) Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.18.53) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.99.4; Fri, 1 May 2009 10:56:36 -0700 Received: from NA-EXMSG-C122.redmond.corp.microsoft.com ([157.54.61.204]) by TK5-EXHUB-C102.redmond.corp.microsoft.com ([157.54.18.53]) with mapi; Fri, 1 May 2009 10:56:36 -0700 From: Orit Levin To: Roni Even , "avt@ietf.org" Date: Fri, 1 May 2009 10:56:34 -0700 Thread-Topic: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions (RAMS) as a working group item Thread-Index: AcnJz//7XHcxZE/BR5mcPjQI3rd8QwAtUd0Q Message-ID: <97B1CE26CD282D4091802C4E3CBCA1B83D9E2D474D@NA-EXMSG-C122.redmond.corp.microsoft.com> References: <49fa06b0.0637560a.430f.ffffb534@mx.google.com> In-Reply-To: <49fa06b0.0637560a.430f.ffffb534@mx.google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_97B1CE26CD282D4091802C4E3CBCA1B83D9E2D474DNAEXMSGC122re_" MIME-Version: 1.0 Cc: 'Tom Taylor' Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions (RAMS) as a working group item X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 17:55:13 -0000 --_000_97B1CE26CD282D4091802C4E3CBCA1B83D9E2D474DNAEXMSGC122re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As a co-author of one of the earlier drafts on this subject, I support the = adoption of the draft as a new WG item. It incorporates most of the require= ments discussed and agreed upon so far and can also serve as a solid basis = for extensions to the mechanism going forward. Thanks, Orit Levin. From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Roni = Even Sent: Thursday, April 30, 2009 1:13 PM To: avt@ietf.org Cc: 'Tom Taylor' Subject: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions (RAMS) = as a working group item Hi, I would like to ask if there is interest to adopt Rapid Acquisition of Mult= icast RTP Sessions (RAMS) as a working group item. The suggestion is to sta= rt the work using http://tools.ietf.org/html/draft-versteeg-avt-rapid-synch= ronization-for-rtp-03 as the initial text for the work. I would also like to suggest that Bill Versteeg will be the editor of the W= G document if adopted. Please send any feedback to the mailing list by Friday May 8th. If there wi= ll be a consensus we will accept this topic and have the above draft as the= initial document. Thanks Roni Even AVT co-chair --_000_97B1CE26CD282D4091802C4E3CBCA1B83D9E2D474DNAEXMSGC122re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As a co-author of one of= the earlier drafts on this subject, I support the adoption of the draft as a ne= w WG item. It incorporates most of the requirements discussed and agreed upon so= far and can also serve as a solid basis for extensions to the mechanism going f= orward.

 =

Thanks,

Orit Levin. <= /span>

 =

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Roni Even
Sent: Thursday, April 30, 2009 1:13 PM
To: avt@ietf.org
Cc: 'Tom Taylor'
Subject: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions (RAMS) as a working group item

 

Hi,

I would like to ask if there is interest to adopt Rapid Acquisiti= on of Multicast RTP Sessions (RAMS) as a working group item. The suggestion is to start the work using http://tools.ietf.org/html/draft-versteeg-avt-rapid-synchroniz= ation-for-rtp-03 as the initial text for the work.

 

I would also like to suggest that Bill Versteeg will be the editor of the WG document if adopted.

 

Please send any feedback to the mailing list by Friday May 8th. = If there will be a consensus we will accept this topic and have the above draf= t as the initial document.

 

Thanks

Roni Even

AVT co-chair

--_000_97B1CE26CD282D4091802C4E3CBCA1B83D9E2D474DNAEXMSGC122re_-- From oran@cisco.com Fri May 1 11:00:29 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCC7C3A69A8 for ; Fri, 1 May 2009 11:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.595 X-Spam-Level: X-Spam-Status: No, score=-6.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8wqbDlTmWh+W for ; Fri, 1 May 2009 11:00:29 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id F09563A68C9 for ; Fri, 1 May 2009 11:00:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,280,1238976000"; d="scan'208";a="179694457" Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-1.cisco.com with ESMTP; 01 May 2009 18:01:52 +0000 Received: from stealth-10-32-245-158.cisco.com ([10.32.245.158]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id n41I16pe001511; Fri, 1 May 2009 11:01:06 -0700 Message-Id: <258699B2-6365-44F9-9F4B-A6D18E4FE1AE@cisco.com> From: David R Oran To: Roni Even In-Reply-To: <49fa06b0.0637560a.430f.ffffb534@mx.google.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 1 May 2009 14:01:51 -0400 References: <49fa06b0.0637560a.430f.ffffb534@mx.google.com> X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=888; t=1241200867; x=1242064867; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:=20David=20R=20Oran=20 |Subject:=20Re=3A=20[AVT]=20Adopting=20Rapid=20Acquisition= 20of=20Multicast=20RTP=20Sessions=20(RAMS)=20as=20a=20workin g=20group=20item |Sender:=20 |To:=20Roni=20Even=20; bh=KnwQga7iQrRVmVzmoULvp4zC6X5k3emRuCjBKv2MMgo=; b=L+3fQUORZCCv1GUnGr08V5Ru1B5klATxXNwnbNVESZCA09oMTcG0spuCM4 bLDl8zPiuTt/GtWxwX2tqymK37A51bpnJHhPjsdwlsQFPNyvKQL42V32tKpD +9FoVardbC; Authentication-Results: imail.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); Cc: avt@ietf.org, 'Tom Taylor' Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions (RAMS) as a working group item X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 18:00:29 -0000 On Apr 30, 2009, at 4:12 PM, Roni Even wrote: > Hi, > I would like to ask if there is interest to adopt Rapid Acquisition > of Multicast RTP Sessions (RAMS) as a working group item. The > suggestion is to start the work usinghttp://tools.ietf.org/html/draft-versteeg-avt-rapid-synchronization-for-rtp-03 > as the initial text for the work. > For my part, yes. > > I would also like to suggest that Bill Versteeg will be the editor > of the WG document if adopted. > This is fne too. > > Please send any feedback to the mailing list by Friday May 8th. If > there will be a consensus we will accept this topic and have the > above draft as the initial document. > > Thanks > Roni Even > AVT co-chair > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From ron.even.tlv@gmail.com Fri May 1 11:08:17 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75DC53A6B92; Fri, 1 May 2009 11:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.229 X-Spam-Level: X-Spam-Status: No, score=-2.229 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ZbwJ7LhdeLJ; Fri, 1 May 2009 11:08:15 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 2F8513A69B2; Fri, 1 May 2009 11:08:15 -0700 (PDT) Received: by fxm2 with SMTP id 2so2437721fxm.37 for ; Fri, 01 May 2009 11:09:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=hxf6Gvj/LcltY0oJGVR/5dsKiBnECMD7cyC3KJ+/Atc=; b=o6zqRZFn5mQO0SxdXKO9C1jpkBfXgClCipO8v+JtC7kRMt7qw8XR7Ahki5one2lSpG BFx9Cx5Eid6yRNXkBx7BEH9Gxj0shC0LsZdmDT5OJiVRu/ErG/XEFa/7jQLpMM8cd4y+ gom4rv+M39s5ChQ4hU2c1BYWq0B8PpyPnsRxA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=lYlYE58pGdfrdanxIS9ZOsdh4ergtGhxYlNjc89TDjD2mX7lVVWaREQd9LxaWge9Am hmE2V9Y+vjKfLnVyvIlHHVs+uZl1H7JkBfju16g29ho1kR9G7Np7DGwOBHsYXKRvuotz 30lVEX8XPhEoJZmZIpnqctMS9Z1jc8bm/BD3E= Received: by 10.103.108.18 with SMTP id k18mr1790263mum.40.1241201378201; Fri, 01 May 2009 11:09:38 -0700 (PDT) Received: from windows8d787f9 (bzq-79-177-57-219.red.bezeqint.net [79.177.57.219]) by mx.google.com with ESMTPS id j9sm8989816mue.21.2009.05.01.11.09.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 01 May 2009 11:09:37 -0700 (PDT) From: "Roni Even" To: "'Jonathan Lennox'" , "'Colin Perkins'" References: <04CAD96D4C5A3D48B1919248A8FE0D54066184FC@xmb-sjc-215.amer.cisco.com><49f9ea83.0637560a.4488.62d2@mx.google.com><04CAD96D4C5A3D48B1919248A8FE0D540934913F@xmb-sjc-215.amer.cisco.com><49fa0498.0405560a.615f.677e@mx.google.com><04CAD96D4C5A3D48B1919248A8FE0D540934937B@xmb-sjc-215.amer.cisco.com><49fa9d9c.0305560a.5885.7b1f@mx.google.com><8BEBE133-BC38-4001-8083-190782BF9949@csperkins.org> <49facdd9.1358560a.4af5.fffff1ed@mx.google.com> <6B55710E7F51AD4B93F336052113B85F8C7C93@be150.mail.lan> In-Reply-To: <6B55710E7F51AD4B93F336052113B85F8C7C93@be150.mail.lan> Date: Fri, 1 May 2009 21:07:28 +0300 Message-ID: <49fb3ae1.09a1660a.55c1.4898@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnKPwmfVmenxPpkQq6VFXZFKfLSIgABp6gwAAtB7mAABSwIMA== Content-Language: en-us Cc: avt@ietf.org, fecframe@ietf.org Subject: Re: [AVT] [Fecframe] FW: New VersionNotification for draft-ietf-fecframe-interleaved-fec-scheme-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 18:08:17 -0000 Jonathan, Thanks for the reference. I suggest that if ssrc multiplexing is allowed there should be some text referencing the mmusic-source-attribute draft and explaining the limitation comparing to the session multiplexing. Roni Even -----Original Message----- From: Jonathan Lennox [mailto:jonathan@vidyo.com] Sent: Friday, May 01, 2009 6:38 PM To: Roni Even; Colin Perkins Cc: avt@ietf.org; fecframe@ietf.org Subject: RE: [AVT] [Fecframe] FW: New VersionNotification for draft-ietf-fecframe-interleaved-fec-scheme-04 The intention is to use ssrc-group (from draft-ietf-mmusic-source-attributes) for ssrc grouping. -- Jonathan Lennox Vidyo, Inc jonathan@vidyo.com > -----Original Message----- > From: Roni Even [mailto:ron.even.tlv@gmail.com] > Sent: Friday, May 01, 2009 6:22 AM > To: 'Colin Perkins' > Cc: avt@ietf.org; fecframe@ietf.org > Subject: Re: [AVT] [Fecframe] FW: New VersionNotification for draft- > ietf-fecframe-interleaved-fec-scheme-04 > > Colin, > I am not sure that grouping will work when you have SSRC multiplexing > and > both the protected stream and the fec stream are in the same m-line, > the mid > attribute is per m-line > > > Roni > > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org] > Sent: Friday, May 01, 2009 12:27 PM > To: Roni Even > Cc: 'Ali C. Begen (abegen)'; avt@ietf.org; fecframe@ietf.org > Subject: Re: [AVT] [Fecframe] FW: New Version Notification for > draft-ietf-fecframe-interleaved-fec-scheme-04 > > On 1 May 2009, at 07:56, Roni Even wrote: > > Hi Ali, > > This is up to the WG to decide if they want to have support for SSRC > > multiplexing and the implications of this support. I am not sure > > what you mean by "we cannot have a parameter", I see only your view > > on the list. > > The grouping mechanism would seem to be sufficient. Why do we need a > special-purpose mechanism, when we can reuse a general approach? > > Colin > > > > > > If only session multiplexing is allowed then the draft should > > clearly state it and in this case I am not sure why you are > > registering the video, audio and text media subtypes. > > > > Roni > > > > -----Original Message----- > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > Sent: Friday, May 01, 2009 2:45 AM > > To: Roni Even; vincent.roca@inrialpes.fr > > Cc: avt@ietf.org; fecframe@ietf.org > > Subject: RE: [AVT] [Fecframe] FW: New Version Notification for draft- > > ietf-fecframe-interleaved-fec-scheme-04 > > > > Hi Roni, > > > > Thanks for the references. However, we cannot have a parameter that > > will relate the FEC stream to the source as RFC 4588 did with "apt" > > since a lot of possibilities (multiple sources and/or multiple > > repair flows) are possible with FEC. Instead, we use grouping and > > this works just fine in session multiplexing. > > > > Regarding SSRC multiplexing of source and FEC streams, I don't think > > giving an explicit example is needed or it is a good idea for this > > draft since SSRC-level grouping is just introduced in 4756bis and it > > will include such examples anyway (actually the version I submitted > > today includes an example). We should better only provide session > > multiplexing examples in this draft. This also emphasizes the > > recommended way of doing FEC. > > > > Reg the registration of the media types and SDP mappings, I believe > > the draft has the necessary details. > > > > BR, > > -acbegen > > > >> -----Original Message----- > >> From: Roni Even [mailto:ron.even.tlv@gmail.com] > >> Sent: Thursday, April 30, 2009 1:03 PM > >> To: Ali C. Begen (abegen); vincent.roca@inrialpes.fr > >> Cc: avt@ietf.org; fecframe@ietf.org > >> Subject: RE: [AVT] [Fecframe] FW: New Version Notification > >> for draft-ietf-fecframe-interleaved-fec-scheme-04 > >> > >> Ali, > >> You can find examples in section 8.6 to 8.8 of RFC 4588, > >> notice that there is an optional parameter for the rtx stream > >> that defines the relation between the original and the rtx > >> stream. Similar solution is also specified for redundant > >> encoding red payload type (RFC 2198). You are offering both > >> streams with different payload type numbers in the same m-line. > >> In this case the media type must be video or audio same as > >> the media type of the protected stream. This is why you > >> needed the registration for type audio and video > >> > >> Roni > >> > >> -----Original Message----- > >> From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > >> Sent: Thursday, April 30, 2009 10:01 PM > >> To: Roni Even; vincent.roca@inrialpes.fr > >> Cc: avt@ietf.org; fecframe@ietf.org > >> Subject: RE: [AVT] [Fecframe] FW: New Version Notification > >> for draft-ietf-fecframe-interleaved-fec-scheme-04 > >> > >> Hi Roni, > >> > >>> I noticed that the fec framework will allow SSRC > >> > >> Yes, it will not be the recommended way of using FEC, but it > >> will be supported. The 4756bis draft also supports it now. > >> > >>> multiplexing, are you going to specify this in this draft in > >>> the SDP offer answer section. > >> > >> I am not sure what I need to specify additionally in this > >> section regarding SSRC multiplexing. Could you let me know if > >> there is such an example? > >> > >>> Maybe you should also discuss when to use application media > >>> type and when to use video or audio > >> > >> I believe the FEC is always application type, we did > >> registration for video, audio, etc. since FEC could relate to > >> sessions carrying such types. > >> > >> BR, > >> -acbegen > >> > >>> > >>> > >>> Roni > >>> > >>> > >>> > >>> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > >>> Behalf Of Ali C. Begen (abegen) > >>> Sent: Thursday, April 30, 2009 3:54 PM > >>> To: vincent.roca@inrialpes.fr > >>> Cc: avt@ietf.org; fecframe@ietf.org > >>> Subject: Re: [AVT] [Fecframe] FW: New Version Notification > >>> for draft-ietf-fecframe-interleaved-fec-scheme-04 > >>> > >>> > >>> > >>> Hi Vincent > >>> > >>> This draft is not an fec scheme so it is not related to fec > >>> framework. It is an rtp payload format draft. The wglc has > >>> been running almost a month now. If you have comments in this > >>> perspective, pls submit them soon. > >>> > >>> > >>> > >>> > >>> -acbegen > >>> > >>> ----- Original Message ----- > >>> From: Vincent Roca > >>> To: Ali C. Begen (abegen) > >>> Cc: fecframe@ietf.org ; avt@ietf.org > >> > >>> Sent: Thu Apr 30 03:58:35 2009 > >>> Subject: Re: [Fecframe] FW: New Version Notification for > >>> draft-ietf-fecframe-interleaved-fec-scheme-04 > >>> > >>> Hello Ali, > >>> > >>> I'm not in favor of finalizing the WGLC for this document. > >>> IMHO we must, > >>> first of all, finalize the framework document itself. > >>> > >>> For instance, the terminology used by the interleaved-fec-scheme I- > D > >>> (section 3.1.) is not in line with the terminology used by the > >>> fecframe-framework-03 I-D (Section 2): > >>> "Source Flow" vs. "Source data flow" > >>> "Repair Flow" vs. "Repair data flow" > >>> "Source Symbol" vs. nothing > >>> "Repair Symbol" vs. nothing > >>> "Source Packet" vs. nothing > >>> "Repair Packet" vs. nothing > >>> And as I said before, IMHO the terminology proposed in the > framework > >>> I-D should be discussed too. > >>> > >>> So let's do things in the right order, especially as the framework > >>> WGLC finishes soon. > >>> > >>> Additionally, I may have some comments for the > >>> interleaved-fec-scheme-04 > >>> I-D. Since I missed the WGLC deadline, you have the right to > >>> blame me ;-) > >>> and I apologize in advance. > >>> > >>> Regards, > >>> > >>> Vincent > >>> > >>> > >>> Ali C. Begen (abegen) wrote: > >>>> This version addresses the comments received from fecframe > >>> and avt so far. > >>>> > >>> http://www.ietf.org/internet-drafts/draft-ietf-fecframe-interl > >> eaved-fec-scheme-04.txt > >>>> > >>>> > >>>> Fecframe chairs, > >>>> > >>>> Could we proceed and finalize WGLC? > >>>> > >>>> -acbegen > >>>> > >>>> > >>>> -----Original Message----- > >>>> From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > >>>> Sent: Wednesday, April 29, 2009 2:56 PM > >>>> To: Ali C. Begen (abegen) > >>>> Subject: New Version Notification for > >>> draft-ietf-fecframe-interleaved-fec-scheme-04 > >>>> > >>>> > >>>> A new version of I-D, > >>> draft-ietf-fecframe-interleaved-fec-scheme-04.txt has been > >>> successfuly submitted by Ali Begen and posted to the IETF > >> repository. > >>>> > >>>> Filename: draft-ietf-fecframe-interleaved-fec-scheme > >>>> Revision: 04 > >>>> Title: RTP Payload Format for 1-D > >>> Interleaved Parity FEC > >>>> Creation_date: 2009-04-29 > >>>> WG ID: fecframe > >>>> Number_of_pages: 31 > >>>> > >>>> Abstract: > >>>> This document defines a new RTP payload format for the > >> Forward Error > >>>> Correction (FEC) that is generated by the 1-D interleaved > >>> parity code > >>>> from a source media encapsulated in RTP. The 1-D > >> interleaved parity > >>>> code is a systematic code, where a number of repair symbols are > >>>> generated from a set of source symbols and sent in a repair flow > >>>> separate from the source flow that carries the source > >> symbols. The > >>>> 1-D interleaved parity code offers a good protection > >> against bursty > >>>> packet losses at a cost of decent complexity. The new > >>> payload format > >>>> defined in this document is used (with some exceptions) > >> as a part of > >>>> the DVB Application-layer FEC specification. > >>>> > >>> > >>>> > >>>> > >>>> The IETF Secretariat. > >>>> > >>>> > >>>> _______________________________________________ > >>>> Fecframe mailing list > >>>> Fecframe@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/fecframe > >>> > >>> > >> > >> > > > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > > > > -- > Colin Perkins > http://csperkins.org/ > > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From rpantos@apple.com Fri May 1 13:23:25 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3726E3A6C51 for ; Fri, 1 May 2009 13:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Rm8t4bwEaYq for ; Fri, 1 May 2009 13:23:24 -0700 (PDT) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 740AD3A67FD for ; Fri, 1 May 2009 13:23:24 -0700 (PDT) Received: from relay13.apple.com (relay13.apple.com [17.128.113.29]) by mail-out4.apple.com (Postfix) with ESMTP id 89D7F6231F5C for ; Fri, 1 May 2009 13:24:48 -0700 (PDT) Received: from relay13.apple.com (unknown [127.0.0.1]) by relay13.apple.com (Symantec Brightmail Gateway) with ESMTP id 6FD8D2807D; Fri, 1 May 2009 13:24:48 -0700 (PDT) X-AuditID: 1180711d-a96f6bb000000259-43-49fb5a90a04e Received: from bbrat.apple.com (bbrat.apple.com [17.202.36.226]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay13.apple.com (Apple SCV relay) with ESMTP id 51F6728081; Fri, 1 May 2009 13:24:48 -0700 (PDT) Message-Id: <6D5990B2-9100-4AC8-89D3-BDEE27A002E5@apple.com> From: Roger Pantos To: avt@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 1 May 2009 13:24:48 -0700 X-Mailer: Apple Mail (2.935.3) X-Brightmail-Tracker: AAAAAA== Cc: http-live-streaming-review@group.apple.com Subject: [AVT] iPhone streaming Internet-Draft posted X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 20:23:25 -0000 My apologies if this is a bit off-topic - it concerns Audio/Video Transport rather than RTP specifically. I just posted draft-pantos-http-live-streaming-00.txt: This document describes a protocol for transmitting unbounded streams of multimedia data over HTTP. It specifies the data format of the files and the actions to be taken by the server (sender) and the clients (receivers) of the streams. It describes version 1.0 of this protocol. The complete draft is available here: https://datatracker.ietf.org/drafts/draft-pantos-http-live-streaming/ We appreciate feedback on the protocol. Please send it to http-live-streaming-review@group.apple.com. thank you, Roger Pantos Apple, Inc. From root@core3.amsl.com Fri May 1 15:15:01 2009 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D65943A6D74; Fri, 1 May 2009 15:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090501221501.D65943A6D74@core3.amsl.com> Date: Fri, 1 May 2009 15:15:01 -0700 (PDT) Cc: avt@ietf.org Subject: [AVT] I-D Action:draft-ietf-avt-rtp-rfc3984bis-06.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 22:15:01 -0000 --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 H.264 Video Author(s) : Y. Wang, et al. Filename : draft-ietf-avt-rtp-rfc3984bis-06.txt Pages : 100 Date : 2009-05-01 This memo describes an RTP Payload format for the ITU-T Recommendation H.264 video codec and the technically identical ISO/IEC International Standard 14496-10 video codec, excluding the Scalable Video Coding (SVC) extension and the Multivew Video Coding extension, for which the RTP payload formats are defined elsewhere. The RTP payload format allows for packetization of one or more Network Abstraction Layer Units (NALUs), produced by an H.264 video encoder, in each RTP payload. The payload format has wide applicability, as it supports applications from simple low bit-rate conversational usage, to Internet video streaming with interleaved transmission, to high bit-rate video-on-demand. This memo obsoletes RFC 3984. Changes from RFC 3984 are summarized in section 18. Issues on backward compatibility to RFC 3984 are discussed in section 17. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-rfc3984bis-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-avt-rtp-rfc3984bis-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-01150825.I-D@ietf.org> --NextPart-- From yekuiwang@huawei.com Fri May 1 15:43:03 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 408AB3A6D4C for ; Fri, 1 May 2009 15:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.254 X-Spam-Level: X-Spam-Status: No, score=-2.254 tagged_above=-999 required=5 tests=[AWL=0.345, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kDpEhZuqsqgz for ; Fri, 1 May 2009 15:43:02 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 6695C3A6DF3 for ; Fri, 1 May 2009 15:42:45 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIZ00KFCLTJFR@usaga04-in.huawei.com> for avt@ietf.org; Fri, 01 May 2009 17:44:07 -0500 (CDT) Received: from W90946 ([10.51.0.23]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KIZ00E3HLTFI1@usaga04-in.huawei.com> for avt@ietf.org; Fri, 01 May 2009 17:44:07 -0500 (CDT) Date: Fri, 01 May 2009 18:44:02 -0400 From: Ye-Kui Wang In-reply-to: <20090501221501.D65943A6D74@core3.amsl.com> To: avt@ietf.org Message-id: <52E76E47139B4E7BBC8291D063C4E240@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcnKqrvARyFxzd/3QfCVaCFsSVAU9wAAzo5w References: <20090501221501.D65943A6D74@core3.amsl.com> Subject: Re: [AVT] I-D Action:draft-ietf-avt-rtp-rfc3984bis-06.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 22:43:03 -0000 Compared to -05, some IDNits complaints and other minor issues have been fixed. Thanks our chair Tom for pointing out the issues. - The reference to RFC 2119 - Long lines - The obsolete RFC 2429 (replaced by RFC 4629) - Added "Obsoletes RFC 3984" BR, YK > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > Behalf Of Internet-Drafts@ietf.org > Sent: Friday, May 01, 2009 6:15 PM > To: i-d-announce@ietf.org > Cc: avt@ietf.org > Subject: [AVT] I-D Action:draft-ietf-avt-rtp-rfc3984bis-06.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 H.264 Video > Author(s) : Y. Wang, et al. > Filename : draft-ietf-avt-rtp-rfc3984bis-06.txt > Pages : 100 > Date : 2009-05-01 > > This memo describes an RTP Payload format for the ITU-T > Recommendation H.264 video codec and the technically > identical ISO/IEC International Standard 14496-10 video > codec, excluding the Scalable Video Coding (SVC) extension > and the Multivew Video Coding extension, for which the RTP > payload formats are defined elsewhere. > The RTP payload format allows for packetization of one or > more Network Abstraction Layer Units (NALUs), produced by an > H.264 video encoder, in each RTP payload. The payload format > has wide applicability, as it supports applications from > simple low bit-rate conversational usage, to Internet video > streaming with interleaved transmission, to high bit-rate > video-on-demand. > > This memo obsoletes RFC 3984. Changes from RFC 3984 are > summarized in section 18. Issues on backward compatibility > to RFC 3984 are discussed in section 17. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-rfc3984 > bis-06.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail > reader implementation to automatically retrieve the ASCII > version of the Internet-Draft. > From stewe@stewe.org Sat May 2 20:03:02 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8A773A6930; Sat, 2 May 2009 20:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.898 X-Spam-Level: X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[AWL=-1.185, BAYES_05=-1.11, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZBcNIFYdmo9b; Sat, 2 May 2009 20:02:59 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id 79B1C3A6837; Sat, 2 May 2009 20:02:58 -0700 (PDT) Received: from [192.168.1.103] (unverified [75.60.27.134]) by stewe.org (SurgeMail 3.9e) with ESMTP id 256289-1743317 for multiple; Sun, 03 May 2009 05:04:21 +0200 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Sat, 02 May 2009 20:04:17 -0700 From: Stephan Wenger To: "avt@ietf.org" , "fecframe@ietf.org" Message-ID: Thread-Topic: MPEG liaison statement to the IETF Thread-Index: AcnLm9iJ3QTOagKUU02cbiSVJ8NneA== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3324139460_8448992" X-Originating-IP: 75.60.27.134 X-Authenticated-User: stewe@stewe.org Subject: [AVT] MPEG liaison statement to the IETF X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2009 03:03:02 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3324139460_8448992 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi all, MPEG has sent a liaison statement (29n10339) to the IETF related to their intention to work on media transport. I assume it will show up in the IETF=B9s liaison tracker shortly. Meanwhile, if you need a copy and can=B9t pull the MPEG documents yourself, email me. The IETF=B9s email system does not allow me to add the .zip file the statement came in, and it=B9s too big i= n unzipped format. Clearly, there is overlap, if not competition, between AVT=B9s work and what MPEG anticipates, at least for some applications. I=B9m also copying fecframe. While the overlap in this case is less clear, I have reasons to believe that MPEG may touch our interests here as well. Arguably, there is a similar overlap/competition to the work performed in numerous other SDOs. The work appears to be in a very early stage. They are calling for a workshop during their forthcoming London meeting. Perhaps some of you are interested in submitting statements or attending the workshop... Regards, Stephan P.s.: I have an opinion about the intentions and plans behind this statement, but it would be impolite to voice it. --B_3324139460_8448992 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable MPEG liaison statement to the IETF Hi all,
MPEG has sent a liaison statement (29n10339) to the IETF related to their i= ntention to work on media transport.  I assume it will show up in the I= ETF’s liaison tracker shortly.  Meanwhile, if you need a copy and= can’t pull the MPEG documents yourself, email me.  The IETF̵= 7;s email system does not allow me to add the .zip file the statement came i= n, and it’s too big in unzipped format.
Clearly, there is overlap, if not competition, between AVT’s work and= what MPEG anticipates, at least for some applications.  I’m also= copying fecframe.  While the overlap in this case is less clear, I hav= e reasons to believe that MPEG may touch our interests here as well.  A= rguably, there is a similar overlap/competition to the work performed in num= erous other SDOs.  
The work appears to be in a very early stage.  They are calling for a = workshop during their forthcoming London meeting.  Perhaps some of you = are interested in submitting statements or attending the workshop...
Regards,
Stephan
P.s.: I have an opinion about the intentions and plans behind this statemen= t, but it would be impolite to voice it.
 --B_3324139460_8448992-- From Christian.Groves@nteczone.com Sun May 3 19:50:17 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 845F03A69E2 for ; Sun, 3 May 2009 19:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.692 X-Spam-Level: X-Spam-Status: No, score=-2.692 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TrStsaluNPDW for ; Sun, 3 May 2009 19:50:16 -0700 (PDT) Received: from ipmail05.adl2.internode.on.net (ipmail05.adl2.internode.on.net [203.16.214.145]) by core3.amsl.com (Postfix) with ESMTP id 5D8083A68DB for ; Sun, 3 May 2009 19:50:15 -0700 (PDT) Received: from ppp118-208-233-106.lns10.mel6.internode.on.net (HELO [127.0.0.1]) ([118.208.233.106]) by ipmail05.adl2.internode.on.net with ESMTP; 04 May 2009 12:20:54 +0930 Message-ID: <49FE5805.3040107@nteczone.com> Date: Mon, 04 May 2009 12:50:45 +1000 From: Christian Groves User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: avt@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [AVT] Comments on draft-ietf-avt-rtcp-xr-* drafts X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 02:50:17 -0000 Hello Geoff and Alan, I was reading the RTCP-XR drafts to get a feel for the work and to see how these drafts would be supported in the context of H.248.48. I've a few comments/questions: draft-ietf-avt-rtcp-xr-burst-gap-discard-01.txt ----------------------------------------------- In section 5 SDP signalling there's the ABNF "xr-format = xr-format / xr-bgd-block" Is this really valid ABNF? It seems to me to be a circular reference. I know you want to add "xr-bgd-block" to the list of xr-formats Would it be better to simply list the type that is being added in the draft? i.e. "xr-format = xr-bgd-block" This is a general comment for all the drafts. draft-ietf-avt-rtcp-xr-qoe-00 ----------------------------- There's no description of direction in section 3.2?? There also appears to be missing ABNF for the definition of "word" in section 4, although I'm not sure that this the correct ABNF for what is being described. I assume that you want to be able to set the type and calculation algorithm that is required? draft-ietf-avt-rtcp-xr-siglevel-00.txt ------------------------------------ Similar comments to above. Additionally there's a typo in section 5 where you refer to QoE Metrics. Regards, Christian From ingemar.s.johansson@ericsson.com Sun May 3 22:25:27 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 187343A67D1 for ; Sun, 3 May 2009 22:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.91 X-Spam-Level: X-Spam-Status: No, score=-5.91 tagged_above=-999 required=5 tests=[AWL=0.339, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0bE1y6On00w3 for ; Sun, 3 May 2009 22:25:14 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 660803A67A7 for ; Sun, 3 May 2009 22:25:11 -0700 (PDT) X-AuditID: c1b4fb3c-b7b19ae000006089-1e-49fe7c85497c Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id E6.9A.24713.58C7EF94; Mon, 4 May 2009 07:26:29 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 May 2009 07:25:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 4 May 2009 07:25:24 +0200 Message-ID: <130EBB38279E9847BAAAE0B8F9905F8CFA6FA3@esealmw109.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions RAMS) as a working group item Thread-Index: AcnJ7cX9dvCAqDDJSmSRd1TLi6StewCil8zA References: From: "Ingemar Johansson S" To: X-OriginalArrivalTime: 04 May 2009 05:25:24.0832 (UTC) FILETIME=[BA2B6E00:01C9CC78] X-Brightmail-Tracker: AAAAAA== Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions RAMS) as a working group item X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 05:25:30 -0000 Hi I support that this work becomes a WG item.=20 Regards Ingemar >=20 > ------------------------------ >=20 > Message: 3 > Date: Thu, 30 Apr 2009 23:12:34 +0300 > From: "Roni Even" > Subject: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions RAMS) as a working group item > To: > Cc: 'Tom Taylor' > Message-ID: <49fa06b0.0637560a.430f.ffffb534@mx.google.com> > Content-Type: text/plain; charset=3D"us-ascii" >=20 > Hi, >=20 > I would like to ask if there is interest to adopt Rapid=20 > Acquisition of Multicast RTP Sessions (RAMS) as a working=20 > group item. The suggestion is to start the work using > http://tools.ietf.org/html/draft-versteeg-avt-rapid-synchroniz ation-for-rtp- > 03 as the initial text for the work. >=20 > =20 >=20 > I would also like to suggest that Bill Versteeg will be the=20 > editor of the WG document if adopted. >=20 > =20 >=20 > Please send any feedback to the mailing list by Friday May=20 > 8th. If there will be a consensus we will accept this topic=20 > and have the above draft as the initial document. >=20 > =20 >=20 > Thanks >=20 > Roni Even >=20 > AVT co-chair >=20 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL:=20 > >=20 > ------------------------------ From yangpeilin@huawei.com Sun May 3 22:47:24 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75A893A6A0D for ; Sun, 3 May 2009 22:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.015 X-Spam-Level: *** X-Spam-Status: No, score=3.015 tagged_above=-999 required=5 tests=[AWL=-1.138, BAYES_20=-0.74, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03cQs+pnRENr for ; Sun, 3 May 2009 22:47:17 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id F1A303A6950 for ; Sun, 3 May 2009 22:47:11 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJ3009IOUSQGK@szxga02-in.huawei.com> for avt@ietf.org; Mon, 04 May 2009 13:48:26 +0800 (CST) Received: from huawei.com ([172.17.1.31]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJ300KV2USQBX@szxga02-in.huawei.com> for avt@ietf.org; Mon, 04 May 2009 13:48:26 +0800 (CST) Received: from [172.24.1.24] (Forwarded-For: [10.164.12.60]) by szxmc03-in.huawei.com (mshttpd); Mon, 04 May 2009 13:48:26 +0800 Date: Mon, 04 May 2009 13:48:26 +0800 From: Peilin YANG In-reply-to: <49fa06b0.0637560a.430f.ffffb534@mx.google.com> To: Roni Even Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: quoted-printable Content-disposition: inline X-Accept-Language: zh-CN Priority: normal References: <49fa06b0.0637560a.430f.ffffb534@mx.google.com> Cc: avt@ietf.org Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions (RAMS) as a working group item X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 05:47:24 -0000 Hi=2C It is a good thing to adopt this draft as a working group item=2E Regards=2C Peilin *************************************************************************= ***************** This email and its attachments contain confidential information from HUA= WEI=2C which is intended only for the person or entity whose address is l= isted above=2E Any use of the information contained here in any way (incl= uding=2C but not limited to=2C total or partial disclosure=2C reproductio= n=2C or dissemination) by persons other than the intended recipient(s) is= prohibited=2E If you receive this email in error=2C please notify the se= nder by phone or email immediately and delete it! ************************************************************************= ***************** ----- =D4=AD=D3=CA=BC=FE ----- =B7=A2=BC=FE=C8=CB=3A Roni Even =3Cron=2Eeven=2Etlv=40gmail=2Ecom=3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=CE=E5=2C =CE=E5=D4=C2 1=C8=D5=2C 2009 =C9=CF= =CE=E74=3A14 =D6=F7=CC=E2=3A =5BAVT=5D Adopting Rapid Acquisition of Multicast RTP Ses= sions (RAMS) as a working group item =CA=D5=BC=FE=C8=CB=3A avt=40ietf=2Eorg =B3=AD=CB=CD=3A =27Tom Taylor=27 =3Ctom=2Etaylor=40rogers=2Ecom=3E =3E Hi=2C =3E = =3E I would like to ask if there is interest to adopt Rapid = =3E Acquisition of =3E Multicast RTP Sessions (RAMS) as a working group item=2E The = =3E suggestion is to =3E start the work using =3E http=3A//tools=2Eietf=2Eorg/html/draft-versteeg-avt-rapid- =3E synchronization-for-rtp- =3E 03 as the initial text for the work=2E =3E = =3E = =3E = =3E I would also like to suggest that Bill Versteeg will be the editor = =3E of the WG =3E document if adopted=2E =3E = =3E = =3E = =3E Please send any feedback to the mailing list by Friday May 8th=2E If = =3E therewill be a consensus we will accept this topic and have the = =3E above draft as =3E the initial document=2E =3E = =3E = =3E = =3E Thanks =3E = =3E Roni Even =3E = =3E AVT co-chair =3E = =3E From Thomas.Schierl@hhi.fraunhofer.de Mon May 4 00:02:46 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C51863A6B8D for ; Mon, 4 May 2009 00:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.526 X-Spam-Level: X-Spam-Status: No, score=-3.526 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yFIgscNAkTOL for ; Mon, 4 May 2009 00:02:39 -0700 (PDT) Received: from mail.hhi.fraunhofer.de (mail.HHI.FRAUNHOFER.DE [193.174.67.45]) by core3.amsl.com (Postfix) with ESMTP id 9557B3A6B20 for ; Mon, 4 May 2009 00:02:36 -0700 (PDT) Received: by mail.hhi.fraunhofer.de (Postfix, from userid 65534) id 8E1771D890AE; Mon, 4 May 2009 09:04:00 +0200 (CEST) Received: from imsva.hhi.de (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 042D3150036; Mon, 4 May 2009 09:03:58 +0200 (CEST) Received: from [172.19.40.6] (ipamfw.iphhi.de [212.202.149.138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Thomas Schierl", Issuer "Fraunhofer-Gesellschaft Root-CA v2" (not verified)) by mail.hhi.fraunhofer.de (Postfix) with ESMTP id 05F9D1D890A4; Mon, 4 May 2009 09:03:59 +0200 (CEST) Message-ID: <49FE935D.5080205@hhi.fraunhofer.de> Date: Mon, 04 May 2009 09:03:57 +0200 From: Thomas.Schierl@hhi.fraunhofer.de Organization: Fraunhofer HHI User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Roni Even References: <49fa06b0.0637560a.430f.ffffb534@mx.google.com> In-Reply-To: <49fa06b0.0637560a.430f.ffffb534@mx.google.com> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-alterMIME: Yes Cc: avt@ietf.org, 'Tom Taylor' Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions (RAMS) as a working group item X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 07:02:46 -0000
Yes, I support it.

-- 
Thomas Schierl
--------------
Fraunhofer HHI


Roni Even wrote:

Hi,

I would like to ask if there is interest to adopt Rapid Acquisition of Multicast RTP Sessions (RAMS) as a working group item. The suggestion is to start the work using http://tools.ietf.org/html/draft-versteeg-avt-rapid-synchronization-for-rtp-03 as the initial text for the work.

 

I would also like to suggest that Bill Versteeg will be the editor of the WG document if adopted.

 

Please send any feedback to the mailing list by Friday May 8th. If there will be a consensus we will accept this topic and have the above draft as the initial document.

 

Thanks

Roni Even

AVT co-chair


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


----
Visit us at

KIOSK EUROPE EXPO 2009 / May 5-7 / Essen, Germany / Hall 1.0, Booth 3A.21
http://www.kioskeurope-expo.com/

ANGACable 2009 / May 26-28 / Cologne, Germay / Hall 10.2, Booth K15
http://www.angacable.com
From xavier.marjou@gmail.com Mon May 4 00:12:39 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 793733A6C73 for ; Mon, 4 May 2009 00:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqv+Jae3KO-C for ; Mon, 4 May 2009 00:12:38 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id 774CC3A6782 for ; Mon, 4 May 2009 00:12:20 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 9so846505eyd.31 for ; Mon, 04 May 2009 00:13:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Q+ltrk2b2D8dL+jJJ7K4lrP9VugZvz9kbCYIlOcXk8o=; b=eq/o2xA5zwpOu67luxzz62kHNJzTOrShGvzWyZtUY0nuEkvca3fV4lGcv+AIG+peYn dLcWav3PuhA9z6U95lm0GEcRMUXGc/c6uQmP+wUeCDWF1VY4RAVbj14JUqI3BYaSw9GR /34wDUK3wF/vozNAALq7TIzCHPTTog7QQ8zQs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=V3xNYG9TdsdM9EU4/pQbMH1QYA85m5mjhenNnvbgX0CC8yB4FeYUBNrLyTewm02PSN SNpYvEYQHMXNrNdCA13CgXuX2Jf4vZ8RWN1AA6D9gWukOEExSz+XlqGxtYvNYNUn6sXN 3zJs6q+sXWfx1VlwVwtklzLBhuAQVlhg7o44o= MIME-Version: 1.0 Received: by 10.216.73.79 with SMTP id u57mr1542189wed.40.1241421223398; Mon, 04 May 2009 00:13:43 -0700 (PDT) In-Reply-To: <49FE935D.5080205@hhi.fraunhofer.de> References: <49fa06b0.0637560a.430f.ffffb534@mx.google.com> <49FE935D.5080205@hhi.fraunhofer.de> Date: Mon, 4 May 2009 09:13:43 +0200 Message-ID: <458913680905040013i2732e5adq7fd05776ba12f8f8@mail.gmail.com> From: Xavier Marjou To: Roni Even Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: avt@ietf.org, Tom Taylor Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions (RAMS) as a working group item X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 07:12:39 -0000 I also support it. Cheers, Xavier On Mon, May 4, 2009 at 9:03 AM, wrote: > > Yes, I support it. > > -- > Thomas Schierl > -------------- > Fraunhofer HHI > > > Roni Even wrote: > > Hi, > > I would like to ask if there is interest to adopt Rapid Acquisition of > Multicast RTP Sessions (RAMS) as a working group item. The suggestion is to > start the work using > http://tools.ietf.org/html/draft-versteeg-avt-rapid-synchronization-for-rtp-03 > as the initial text for the work. > > > > I would also like to suggest that Bill Versteeg will be the editor of the WG > document if adopted. > > > > Please send any feedback to the mailing list by Friday May 8th. If there > will be a consensus we will accept this topic and have the above draft as > the initial document. > > > > Thanks > > Roni Even > > AVT co-chair > > ________________________________ > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > > > ---- > Visit us at > > KIOSK EUROPE EXPO 2009 / May 5-7 / Essen, Germany / Hall 1.0, Booth 3A.21 > http://www.kioskeurope-expo.com/ > > ANGACable 2009 / May 26-28 / Cologne, Germay / Hall 10.2, Booth K15 > http://www.angacable.com > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > > From tendyntu@huawei.com Mon May 4 00:14:17 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB3463A6988 for ; Mon, 4 May 2009 00:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[AWL=1.562, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xDzoUtZXOiIl for ; Mon, 4 May 2009 00:14:11 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id CD0463A6B7D for ; Mon, 4 May 2009 00:13:43 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJ300MADYT63E@szxga04-in.huawei.com> for avt@ietf.org; Mon, 04 May 2009 15:15:06 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJ3004AOYT61U@szxga04-in.huawei.com> for avt@ietf.org; Mon, 04 May 2009 15:15:06 +0800 (CST) Received: from z61302 ([10.85.208.250]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJ300LKWYT5QR@szxml04-in.huawei.com> for avt@ietf.org; Mon, 04 May 2009 15:15:06 +0800 (CST) Date: Mon, 04 May 2009 15:15:05 +0800 From: Zou ZiXuan In-reply-to: <49fa06b0.0637560a.430f.ffffb534@mx.google.com> To: 'Roni Even' , avt@ietf.org Message-id: <008e01c9cc88$0d1be400$2753ac00$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_55kXK05sE+1fFyGJJZ5oMg)" Content-language: zh-cn Thread-index: AcnJz//7XHcxZE/BR5mcPjQI3rd8QwCt/r2w References: <49fa06b0.0637560a.430f.ffffb534@mx.google.com> Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions (RAMS) as a working group item X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 07:14:17 -0000 ÕâÊÇÒ»·â MIME ¸ñʽµÄ¶à²¿·ÖÓʼþ¡£ --Boundary_(ID_55kXK05sE+1fFyGJJZ5oMg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, I support it to be a working group item. From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Roni Even Sent: Friday, May 01, 2009 4:13 AM To: avt@ietf.org Cc: 'Tom Taylor' Subject: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions (RAMS) as a working group item Hi, I would like to ask if there is interest to adopt Rapid Acquisition of Multicast RTP Sessions (RAMS) as a working group item. The suggestion is to start the work using http://tools.ietf.org/html/draft-versteeg-avt-rapid-synchronization-for- rtp-03 as the initial text for the work. I would also like to suggest that Bill Versteeg will be the editor of the WG document if adopted. Please send any feedback to the mailing list by Friday May 8th. If there will be a consensus we will accept this topic and have the above draft as the initial document. Thanks Roni Even AVT co-chair --Boundary_(ID_55kXK05sE+1fFyGJJZ5oMg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi,

         I support it to be a working group item.

 

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Roni Even
Sent: Friday, May 01, 2009 4:13 AM
To: avt@ietf.org
Cc: 'Tom Taylor'
Subject: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions (RAMS) as a working group item

 

Hi,

I would like to ask if there is interest to adopt Rapid Acquisition of Multicast RTP Sessions (RAMS) as a working group item. The suggestion is to start the work using http://tools.ietf.org/html/draft-versteeg-avt-rapid-synchronization-for-rtp-03 as the initial text for the work.

 

I would also like to suggest that Bill Versteeg will be the editor of the WG document if adopted.

 

Please send any feedback to the mailing list by Friday May 8th. If there will be a consensus we will accept this topic and have the above draft as the initial document.

 

Thanks

Roni Even

AVT co-chair

--Boundary_(ID_55kXK05sE+1fFyGJJZ5oMg)-- From vincent.roca@inrialpes.fr Mon May 4 08:09:09 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B03BF3A6FBF; Mon, 4 May 2009 08:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.181 X-Spam-Level: X-Spam-Status: No, score=-6.181 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSZcfunV5OAj; Mon, 4 May 2009 08:09:08 -0700 (PDT) Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by core3.amsl.com (Postfix) with ESMTP id 9C1D53A6B5F; Mon, 4 May 2009 08:09:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,292,1238968800"; d="txt'?scan'208";a="39426093" Received: from ornon.inrialpes.fr (HELO [194.199.24.115]) ([194.199.24.115]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 May 2009 17:10:31 +0200 Message-ID: <49FF0566.4080000@inrialpes.fr> Date: Mon, 04 May 2009 17:10:30 +0200 From: Vincent Roca User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Marshall Eubanks , "Ali C. Begen (abegen)" References: <04CAD96D4C5A3D48B1919248A8FE0D54066184FC@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: multipart/mixed; boundary="------------050005040300070204020209" Cc: avt@ietf.org, fecframe@ietf.org Subject: Re: [AVT] [Fecframe] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 15:09:09 -0000 This is a multi-part message in MIME format. --------------050005040300070204020209 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello Ali, As promised, here are my comments for your I-D. And sorry for being rather late. Regards, Vincent --------------050005040300070204020209 Content-Type: text/plain; name="fecframe-interleaved-fec-04_comments.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="fecframe-interleaved-fec-04_comments.txt" Comments to draft-ietf-fecframe-interleaved-fec-scheme-04 Vincent - May 3rd, 2009 ---------------------------------------------------------- For discussion... I- Main comments ---------------- 1/** Introduction, p.4 It is said: "Note that the sender MUST transmit the source and repair packets in different source and repair flows, respectively to offer backward compatibility (See Section 4)." The fact that source an repair packets belong to different flows is not sufficient to offer backward compatibility, since the notion of source/repair flow says nothing about the way these flows are transported in transport flows (see Definition, section 3.1). This sentence suggests on the contrary that they are transported independently which is not necessarily the case (cf. last week mailing list thread). I suggest: "Note that the source and repair packets belong to different source and repair flows, and the sender MUST provide a way for the receivers to demultiplex them, even in the case they are sent in the same transport flow (i.e., same source/destination IP/port with UDP). This is required to offer backward compatibility (See Section 4)." I also suggest to clarify the Source/Repair Flow definitions in Section 3.1, to say explicitly that there are different possible mappings to transport flow(s). 2/** Section 4.2, p13: It is said: o Synchronization Source (SSRC): The SSRC value SHALL be randomly assigned as suggested by [RFC3550]. This allows the sender to multiplex the source and repair flows on the same port, or multiplex multiple repair flows on a single port. I suggest to refer to "transport flows", i.e., in case of UDP, the 5-tuple, rather than "port" which is much more imprecise. BTW, do you refer to the source or destination port in the above sentence, and what about the source/destination address? 3/** Fig. 3: Current figure looks like the following: [...] + ------------- | XOR | ------------- = +===+ |C_1| +===+ I don't like the "+ XOR" in the above figure, since it suggests (to me at least) that the {S_1 .. S_XXX} symbols are "summed" with a XOR symbol to produce the C_1. I'd prefer something like: XOR sum of set +-------------+ | S_1 | | S_L+1 | | . | | . | | . | | S_(D-1)xL+1 | +-------------+ = +===+ |C_1| +===+ (and something similar with the 1D/2D I-D) 4/** Section 4.2 "Repair Packets", p12, RTP header clarifications. I don't like the sentences: "This bit is obtained by applying protection to the corresponding XX bits from the RTP headers of the source packets protected by this repair packet". We don't apply any protection to produce this bit, this is the contrary. I suggest: "This bit is equal to the XOR sum of the corresponding XX bits from the RTP headers of the source packets protected by this repair packet". 5/** Section 4.2, p 15: It is said (last sentence): "Instead, a systematic approach is inherently more efficient." I don't like the "systematic" adjective above. I suggest: Instead, providing implicitly the list, thanks to the {base sequence number; D; L} tuple and the knowledge of the associated algorithm, is more efficient." 6/** Section 5.2.1, p21: It is said: "The size of the repair-window is related to how fast the sender will send the repair packets." I don't agree with the wording "how fast". It's more a matter of delay with the transmission of the repair packet for a given source packet than a "bandwidth" issue". I suggest: "The size of the repair-window is related to the maximum delay between the transmission of a source packet and the associated repair packet." 7/** Section 6, p.22: It is said: "This section provides a complete specification of the 1-D interleaved parity code." This is not only a specification of the code, but also of the new RTP payload format for these codes. 8/** Section 6, p.23: It is said: "Note that if the payload lengths of the source packets are not equal, each shorter packet MUST be padded to the length of the longest packet by adding octet 0's at the end. Due to this possible padding and mandatory FEC header, a repair packet usually has a larger size than the source packets it protects. This may cause problems if the resulting repair packet size exceeds the Maximum Transmission Unit (MTU) size of the path over which the repair flow is sent." Several issues: - it's not only a problem of different payload lengths. If two packets have the same payload lengths but different variable length lists/ extensions, then the bit streams will have different length too. The first sentence should be corrected. - we need to define what "the longest packet" means. Is it for this set of source packets (I assume yes) or for all the packets of the session (if this has a meaning)? - we need to define what "length" means. Is it only the payload length, or does it include the various variable length extensions/lists? - a repair packet ALWAYS (rather than "usually") has a larger size than the source packets it protects (even the longest one, because of the additional 16 byte FEC header in that case). 9/** Section 6.3.1, p 25: The following formula is provided to generate the source packet sequence number: p*_snb + i * L This equation should take into account the possible wrapping of this 16-bit RTP sequence number field. I suggest: (p*_snb + i * L) modulo (65536) 10/** Section 6.3.2. "Recovering the RTP Header and Payload", p 25 It is said: 2. For the repair packet associated with set T, compute the bit string in the same fashion except use the PT recovery field instead of the PT field and TS recovery field instead of the Timestamp field, and set the CSRC list, header extension and padding to null regardless of the values of the CC field, X bit and P bit. This is not clear at all to me (even if I understand the intent). The structure of the bit string is the same, but the values are the ones that have been received. So, saying "compute the XXX field in the same fashion..." is misleading, as well as "XXX recovery field". I suggest: 2. For the repair packet associated with set T, construct the bit string similarly, using the values received in the repair packet for the PT and TS fields, ... 11/** Section 6.3.2. "Recovering the RTP Header and Payload", p 25 I also suggest a different ordering, since as such there is an incoherency: In step 1, we cannot "compute the bit string as described in section 6.2", since we still don't know at this stage the maximum length, and so the required padding. But if we switch the order, everything works well. I suggest (reorder + merge): 1. For the repair packet... 2. For each of the source packets, ... If the bit string generated is shorter than the string generated for the repair packet... 12/** Section 6.3.2. "Recovering the RTP Header and Payload", p 25 It is said, in step 14: 14. Take the next 16 bits of the recovered bit string and set Y to whatever unsigned integer this represents (assuming network- order). Take Y bytes from the recovered bit string... Two points: - I suggest saying explicitly that "Y" is a new unsigned integer variable (it was not clear to me when reading it first); - I also suggest saying explicitly that Y must first be converted to host order, otherwise funny things will happen on our little endian machines ;-) To summarize, I suggest: 14. Take the next 16 bits of the recovered bit string and set the new variable Y to whatever unsigned integer this represents (assuming network-order). Convert Y to host byte order and then take Y bytes from the recovered bit string... 13/** Section 13.2 "Informative references" Why is reference RFC2733 in the informative section whereas the goal of this document is to "extend the Forward Error Correction (FEC) header defined in [RFC2733]"? It deserves a Normative Ref IMHO. II- Typos and minor comments ---------------------------- ** Section 3.3: I don't think that the bitwise table of XOR sums is needed. ** Section 6.3. Source Packet Reconstruction, p24: I suggest (1st sentence): ...reconstruct the missing source packets. ^^^^^^ ** Section 6.3.1, p25: if there is only one source packet missing in set T. ^^^^ (removed "is") ** Section 7, SDP example. We can probably remove the extra " " space in "repair-window: 200000" (i.e., like the other parameters). --------------050005040300070204020209-- From ron.even.tlv@gmail.com Mon May 4 14:09:49 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EA1D3A6982 for ; Mon, 4 May 2009 14:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.208 X-Spam-Level: X-Spam-Status: No, score=-2.208 tagged_above=-999 required=5 tests=[AWL=0.390, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gxcbFjEUmrrw for ; Mon, 4 May 2009 14:09:39 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by core3.amsl.com (Postfix) with ESMTP id D4DA33A69D2 for ; Mon, 4 May 2009 14:09:38 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id l26so562388fgb.18 for ; Mon, 04 May 2009 14:11:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:date :message-id:mime-version:content-type:x-mailer:thread-index :content-language; bh=katwORWngf+b08Z2Dizpt4Pkl6Fh3C+1rD4i3+sR9v4=; b=pHXOs6I4ZYSKNiNZY/K7UQJaGxqKHEyxwPvyazI8HfaoO3oTFldN9kxP5DlA/pUqLo 4DIaGvvY7m2+qhNKfkKJ6FyVGEvxYlnf/wCappJLaJOANGSowsT723nlkU8IwR9IxFG1 JrE8TmpTugBgneIkspeXJhLqdtIavM7EEzLsU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:date:message-id:mime-version:content-type :x-mailer:thread-index:content-language; b=dQsPFevHx3bSWikm4XG7nDwm432ONHA8CTO0iiqwu1AOYwt5KRzWUBmp5U7V33xYSu vRxtjN6wIwgOODtBFzNteJPSh2aSVqUkxCbK54n74xeG747jyUzsVr+C67rOnFj5/dIq JXDrYttrjBc/ulLeW+K0S/D9VphUCqBaTEVak= Received: by 10.86.23.20 with SMTP id 20mr6343249fgw.49.1241471462428; Mon, 04 May 2009 14:11:02 -0700 (PDT) Received: from windows8d787f9 (bzq-79-179-118-167.red.bezeqint.net [79.179.118.167]) by mx.google.com with ESMTPS id l19sm7088119fgb.17.2009.05.04.14.10.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 04 May 2009 14:11:02 -0700 (PDT) From: "Roni Even" To: Date: Tue, 5 May 2009 00:08:58 +0300 Message-ID: <49ff59e6.1358560a.4af5.05e3@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_010F_01C9CD15.B4C868D0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnM1Y81eH5hh4rORt+9cpb8aAHZ7wAESgPQAABHA9AABShl8A== Content-Language: en-us Subject: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 21:09:49 -0000 This is a multipart message in MIME format. ------=_NextPart_000_010F_01C9CD15.B4C868D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: Ashish Goyal Sent: Tuesday, May 05, 2009 12:04 AM To: 'avt@ietf.org' Subject: draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level Hi, I am leading an effort of sip video vendors under the aegis of IMTC Sip video parity and working on a BCP document to enhance sip video interoperability. In our discussion today there were some concerns around the section 8.2.2 of 3984bis - specifically around the text "The level part of "profile-level-id" is downgradable, i.e. the answerer MUST maintain the same or a lower level or remove the media format (payload type) completely. " I am writing this mail in the hope that we can amend the 3984 bis so that we can consider it as a reference - rather than having a conflicting BCP document for video. The recommendation from the group was to 1) Consider level parameter as a declaration of receive capabilities and not let it imply the resolution used for transmit 2) Consider the level parameter as either upgradeable or downgradeable - since it's really talking about receive capability. The answerer must not transmit a level higher than the offer - but can provide an answer which contains a level higher than the offer. This would allow the offerer to transmit a higher level than it can receive - if it chooses to. Here is the issue that we are trying to address by having asymmetric support for level. One of the use cases which is well supported by some of the leading video implementers is support for asymmetric video resolutions. The use case where this becomes important is when the calls are made from a video softclient running on a pc. Because of asymmetric compute requirements on encode and decode - the video softclients would be able to typically decode much higher resolution - than they are able to encode. However section 8.2.2 makes this negotiation difficult. Here is how the use case is expected to work. Assume the video device A is able to decode level 3.1 and encode only level 1.1 B is capable of both decoding and encoding level 3.1. A would quote a level of 3.1 in its offer B would respond with level 3.1 in the answer A would send to B video stream at level 1.1 - since A can only encode at level 1.1. B would send level 3.1 to A since A can decode upto level 3.1. Regards, Ashish ------=_NextPart_000_010F_01C9CD15.B4C868D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From:= Ashish = Goyal
Sent: Tuesday, May 05, 2009 12:04 AM
To: 'avt@ietf.org'
Subject: draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level =

 

Hi,

   I am leading an effort of sip video = vendors under the aegis of IMTC Sip video parity and working on a BCP document = to enhance sip video interoperability. In our discussion today there were = some concerns around the section 8.2.2 of 3984bis – specifically around = the text

 

 “The level part of =  "profile-level-id" is downgradable, i.e. the answerer MUST  maintain the same or a = lower level or remove the media format  (payload type) completely. = “

 

 I am writing this mail in the hope that we = can amend the 3984 bis so that we can consider it as a reference – rather = than having a conflicting BCP document for video.

 

   The recommendation from the group was = to

1)      Consider level parameter = as a declaration of receive capabilities and not let it imply the resolution = used for transmit

2)      Consider the level = parameter as either upgradeable or downgradeable – since it’s really = talking about receive capability. The answerer must not transmit a level higher than the offer = – but can provide an answer which contains a level higher than the offer. This = would allow the offerer to transmit a higher level than it can receive – = if it chooses to.

 

  Here is  the issue that we are trying = to address by having asymmetric support for level.

 

  One of the use cases which is well supported = by some of the leading video implementers is support for asymmetric video = resolutions. The use case where this becomes important is when the calls are made = from a video softclient  running on  a pc.  Because of = asymmetric compute requirements on encode and decode – the video softclients = would be able to typically decode much higher resolution – than they are able to = encode.  However section 8.2.2  makes this negotiation = difficult. 

 

 Here is how the use case is expected to work. =

 

  Assume the video device A is able to decode = level 3.1 and encode only level 1.1

  B is capable of both decoding and encoding = level 3.1.

  A would quote a level of 3.1 in its = offer

  B would respond with level 3.1 in the = answer

 

  A would send to B video stream at level 1.1 = – since A can only encode at level 1.1.

  B would send level 3.1 to A since A can = decode upto level 3.1.

 

 

Regards,

Ashish

------=_NextPart_000_010F_01C9CD15.B4C868D0-- From abegen@cisco.com Mon May 4 14:27:42 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DF7C3A67AC; Mon, 4 May 2009 14:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.391 X-Spam-Level: X-Spam-Status: No, score=-6.391 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L1cL1u-KX89B; Mon, 4 May 2009 14:27:40 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id C941B3A6AE2; Mon, 4 May 2009 14:27:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,293,1238976000"; d="scan'208";a="180674154" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 04 May 2009 21:29:07 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n44LT739030835; Mon, 4 May 2009 14:29:07 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n44LT6D0014702; Mon, 4 May 2009 21:29:06 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 May 2009 14:29:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Mon, 4 May 2009 14:27:39 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54093C3454@xmb-sjc-215.amer.cisco.com> In-Reply-To: <49FF0566.4080000@inrialpes.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-04 Thread-Index: AcnMynwidu69tWVRSmm/MDDTLaYEWQAIcLmg References: <04CAD96D4C5A3D48B1919248A8FE0D54066184FC@xmb-sjc-215.amer.cisco.com> <49FF0566.4080000@inrialpes.fr> From: "Ali C. Begen (abegen)" To: "Vincent Roca" , "Marshall Eubanks" X-OriginalArrivalTime: 04 May 2009 21:29:06.0852 (UTC) FILETIME=[5AC77E40:01C9CCFF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=11268; t=1241472547; x=1242336547; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20RE=3A=20[Fecframe]=20FW=3A=20New=20Version=20No tification=20for=09draft-ietf-fecframe-interleaved-fec-schem e-04 |Sender:=20; bh=E3YXyc4//MZHbNSmRfJaveU6h14lxREiZdPnkz03QY4=; b=HWvCCmqSde5eftIuChg/9k81suhjPHMD9Q23zhn1PiJJ3OFO0RRe1WYFI9 FOUVWq8OqLTl13yezGlPY1s0zAgdtPM9XXjNVzXSmpj2UH6b3f0Grlhd8/Je 3GSe2i0Gp0; Authentication-Results: sj-dkim-2; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: avt@ietf.org, fecframe@ietf.org Subject: Re: [AVT] [Fecframe] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 21:27:42 -0000 Thanks for the detailed review. I'll get most of them into the next = revision. I have some comments for some of them, though. Inline. 1/** Introduction, p.4 It is said: "Note that the sender MUST transmit the source and repair packets in different source and repair flows, respectively to offer backward compatibility (See Section 4)." The fact that source an repair packets belong to different flows is not sufficient to offer backward compatibility, since the notion of source/repair flow says nothing about the way these flows are transported in transport flows (see Definition, section 3.1). This sentence suggests on the contrary that they are transported independently which is not necessarily the case (cf. last week mailing list thread). I suggest: "Note that the source and repair packets belong to different source and repair flows, and the sender MUST provide a way for the receivers to demultiplex them, even in the case they are sent in the same transport flow (i.e., same source/destination IP/port with UDP). This is required to offer backward compatibility (See Section 4)." Ali: Sounds good. I also suggest to clarify the Source/Repair Flow definitions in Section 3.1, to say explicitly that there are different possible mappings to transport flow(s). Ali: This should rather go to the framework draft. 2/** Section 4.2, p13: It is said: o Synchronization Source (SSRC): The SSRC value SHALL be randomly assigned as suggested by [RFC3550]. This allows the sender to multiplex the source and repair flows on the same port, or multiplex multiple repair flows on a single port.=20 I suggest to refer to "transport flows", i.e., in case of UDP, the 5-tuple, rather than "port" which is much more imprecise. BTW, do you refer to the source or destination port in the above sentence, and what about the source/destination address? Ali: If two RTP streams are sent to different IP addresses, they are = different RTP sessions anyway. Random SSRCs help when we send two RTP = streams in the same RTP session. Source address/port is irrelevant. So, = I don't see any confusion here. 3/** Fig. 3:=20 Current figure looks like the following: [...] + =20 -------------=20 | XOR | -------------=20 =3D =20 +=3D=3D=3D+ =20 |C_1| =20 +=3D=3D=3D+ =20 I don't like the "+ XOR" in the above figure, since it suggests (to me at least) that the {S_1 .. S_XXX} symbols are "summed" with a XOR symbol to produce the C_1. I'd prefer something like: XOR sum of set +-------------+ | S_1 | | S_L+1 | | . | | . | | . | | S_(D-1)xL+1 | +-------------+ =3D =20 +=3D=3D=3D+ =20 |C_1| =20 +=3D=3D=3D+=20 (and something similar with the 1D/2D I-D) Ali: I believe the context is clear here as the source, repair and = operation are encapsulated differently. 4/** Section 4.2 "Repair Packets", p12, RTP header clarifications. I don't like the sentences: "This bit is obtained by applying protection to the corresponding XX bits from the RTP headers of the source packets protected by this repair packet". We don't apply any protection to produce this bit, this is the contrary. I suggest: "This bit is equal to the XOR sum of the corresponding XX bits from the RTP headers of the source packets protected by this repair packet". Ali: I am sorry but I don't get your point. I could say "applying XOR = operation" but the difference is negligible. 5/** Section 4.2, p 15: It is said (last sentence): "Instead, a systematic approach is inherently more efficient." I don't like the "systematic" adjective above. I suggest: Instead, providing implicitly the list, thanks to the {base sequence number; D; L} tuple and the knowledge of the associated algorithm, is more efficient." Ali: I could say "systematized" if you like it better because systematic = or systematized captures what I would like to say. =20 6/** Section 5.2.1, p21: It is said: "The size of the repair-window is related to how fast the sender will send the repair packets." I don't agree with the wording "how fast". It's more a matter of delay with the transmission of the repair packet for a given source packet than a "bandwidth" issue". I suggest: "The size of the repair-window is related to the maximum delay between the transmission of a source packet and the associated repair packet." Ali: OK 7/** Section 6, p.22: It is said: "This section provides a complete specification of the 1-D interleaved parity code." This is not only a specification of the code, but also of the new RTP payload format for these codes. Ali: OK 8/** Section 6, p.23: It is said: "Note that if the payload lengths of the source packets are not equal, each shorter packet MUST be padded to the length of the longest packet by adding octet 0's at the end. Due to this possible padding and mandatory FEC header, a repair packet usually has a larger size than the source packets it protects. This may cause problems if the resulting repair packet size exceeds the Maximum Transmission Unit (MTU) size of the path over which the repair flow is sent." Several issues: - it's not only a problem of different payload lengths. If two packets have the same payload lengths but different variable length lists/ extensions, then the bit streams will have different length too. The first sentence should be corrected. Ali: Right. - we need to define what "the longest packet" means. Is it for this set of source packets (I assume yes) or for all the packets of the session (if this has a meaning)? Ali: Within this source block and I believe it is pretty clear. - we need to define what "length" means. Is it only the payload length, or does it include the various variable length extensions/lists? Ali: The first item above will take care of this. - a repair packet ALWAYS (rather than "usually") has a larger size than the source packets it protects (even the longest one, because of the additional 16 byte FEC header in that case). Ali: I'd agree with this. But 2733 did not use "always" in the text. Not = sure whether we should stick with it, though. 9/** Section 6.3.1, p 25: The following formula is provided to generate the source packet=20 sequence number: p*_snb + i * L This equation should take into account the possible wrapping of this 16-bit RTP sequence number field. I suggest: (p*_snb + i * L) modulo (65536) Ali: Yes, wrapping should be taken into account. 10/** Section 6.3.2. "Recovering the RTP Header and Payload", p 25 It is said: 2. For the repair packet associated with set T, compute the bit string in the same fashion except use the PT recovery field instead of the PT field and TS recovery field instead of the Timestamp field, and set the CSRC list, header extension and padding to null regardless of the values of the CC field, X bit and P bit. This is not clear at all to me (even if I understand the intent). The structure of the bit string is the same, but the values are the ones that have been received. So, saying "compute the XXX field in the same fashion..." is misleading, as well as "XXX recovery field". I suggest: 2. For the repair packet associated with set T, construct the bit string similarly, using the values received in the repair packet for the PT and TS fields, ... Ali: No. We need to explicitly say the "PT/TS recovery fields" here = since there are also the PT and TS fields in the RTP header. 11/** Section 6.3.2. "Recovering the RTP Header and Payload", p 25 I also suggest a different ordering, since as such there is an incoherency: In step 1, we cannot "compute the bit string as described in section 6.2", since we still don't know at this stage the maximum length, and so the required padding. But if we switch the order, everything works well. I suggest (reorder + merge): 1. For the repair packet... 2. For each of the source packets, ... If the bit string generated is shorter than the string generated for the repair packet... Ali: Not that this is incorrect, but the current text is not incorrect, = either. Padding does not change the bitstring and necessary padding can = always be added. I suggest to keep the current text to be consistent = with 2733. 12/** Section 6.3.2. "Recovering the RTP Header and Payload", p 25 It is said, in step 14: 14. Take the next 16 bits of the recovered bit string and set Y to whatever unsigned integer this represents (assuming network- order). Take Y bytes from the recovered bit string... Two points: - I suggest saying explicitly that "Y" is a new unsigned integer variable (it was not clear to me when reading it first); - I also suggest saying explicitly that Y must first be converted to host order, otherwise funny things will happen on our little endian machines ;-) To summarize, I suggest: 14. Take the next 16 bits of the recovered bit string and set the new variable Y to whatever unsigned integer this represents (assuming network-order). Convert Y to host byte order and then take Y bytes from the recovered bit string... Ali: Sounds good. 13/** Section 13.2 "Informative references" Why is reference RFC2733 in the informative section whereas the goal=20 of this document is to "extend the Forward Error Correction (FEC) header defined in [RFC2733]"? It deserves a Normative Ref IMHO. Ali: Because it has been obsoleted and the fact that the current spec = does not need RFC 2733 to be implemented.=20 II- Typos and minor comments ---------------------------- ** Section 3.3: I don't think that the bitwise table of XOR sums is = needed. ** Section 6.3. Source Packet Reconstruction, p24: I suggest (1st sentence): ...reconstruct the missing source packets. ^^^^^^ Ali: Good idea. ** Section 6.3.1, p25: if there is only one source packet missing in set T.=20 ^^^^ (removed "is") Ali: Good catch. ** Section 7, SDP example. We can probably remove the extra " " space in "repair-window: 200000" (i.e., like the other parameters). Ali: We should.=20 Thanks, -acbegen > -----Original Message----- > From: Vincent Roca [mailto:vincent.roca@inrialpes.fr] > Sent: Monday, May 04, 2009 8:10 AM > To: Marshall Eubanks; Ali C. Begen (abegen) > Cc: avt@ietf.org; fecframe@ietf.org > Subject: Re: [Fecframe] FW: New Version Notification for = draft-ietf-fecframe-interleaved-fec-scheme-04 >=20 > Hello Ali, >=20 > As promised, here are my comments for your I-D. > And sorry for being rather late. > Regards, >=20 > Vincent From yekuiwang@huawei.com Mon May 4 14:54:33 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECA703A69C8 for ; Mon, 4 May 2009 14:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.837 X-Spam-Level: X-Spam-Status: No, score=-1.837 tagged_above=-999 required=5 tests=[AWL=-0.123, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JuvgqaFSMufe for ; Mon, 4 May 2009 14:54:26 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id B442B3A6CBB for ; Mon, 4 May 2009 14:54:26 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJ5009O03L32B@usaga02-in.huawei.com> for avt@ietf.org; Mon, 04 May 2009 14:55:52 -0700 (PDT) Received: from W90946 ([10.193.125.102]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJ5008E23KY70@usaga02-in.huawei.com> for avt@ietf.org; Mon, 04 May 2009 14:55:51 -0700 (PDT) Date: Mon, 04 May 2009 17:55:46 -0400 From: Ye-Kui Wang In-reply-to: <49ff59e6.1358560a.4af5.05e3@mx.google.com> To: 'Roni Even' , avt@ietf.org Message-id: <089AD8684C5E4C2995F01C2527EE7081@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_M+eMYurIrGjTxKexbB8cfg)" Thread-index: AcnM1Y81eH5hh4rORt+9cpb8aAHZ7wAESgPQAABHA9AABShl8AABbg4Q References: <49ff59e6.1358560a.4af5.05e3@mx.google.com> Subject: Re: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 21:54:33 -0000 This is a multi-part message in MIME format. --Boundary_(ID_M+eMYurIrGjTxKexbB8cfg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, The current design in the bis draft (as well as in in RFC 3984) does allow negotiation of asymmetric video solutions using SDP offer/answer. What you need to do is just to separate the sending part (a=sendonly) and the receiving part (=recvonly) in the SDP. Therefore, I don't think there is any problem and any need for change in the regard. BR,YK _____ From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Roni Even Sent: Monday, May 04, 2009 5:09 PM To: avt@ietf.org Subject: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level From: Ashish Goyal Sent: Tuesday, May 05, 2009 12:04 AM To: 'avt@ietf.org' Subject: draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level Hi, I am leading an effort of sip video vendors under the aegis of IMTC Sip video parity and working on a BCP document to enhance sip video interoperability. In our discussion today there were some concerns around the section 8.2.2 of 3984bis - specifically around the text "The level part of "profile-level-id" is downgradable, i.e. the answerer MUST maintain the same or a lower level or remove the media format (payload type) completely. " I am writing this mail in the hope that we can amend the 3984 bis so that we can consider it as a reference - rather than having a conflicting BCP document for video. The recommendation from the group was to 1) Consider level parameter as a declaration of receive capabilities and not let it imply the resolution used for transmit 2) Consider the level parameter as either upgradeable or downgradeable - since it's really talking about receive capability. The answerer must not transmit a level higher than the offer - but can provide an answer which contains a level higher than the offer. This would allow the offerer to transmit a higher level than it can receive - if it chooses to. Here is the issue that we are trying to address by having asymmetric support for level. One of the use cases which is well supported by some of the leading video implementers is support for asymmetric video resolutions. The use case where this becomes important is when the calls are made from a video softclient running on a pc. Because of asymmetric compute requirements on encode and decode - the video softclients would be able to typically decode much higher resolution - than they are able to encode. However section 8.2.2 makes this negotiation difficult. Here is how the use case is expected to work. Assume the video device A is able to decode level 3.1 and encode only level 1.1 B is capable of both decoding and encoding level 3.1. A would quote a level of 3.1 in its offer B would respond with level 3.1 in the answer A would send to B video stream at level 1.1 - since A can only encode at level 1.1. B would send level 3.1 to A since A can decode upto level 3.1. Regards, Ashish --Boundary_(ID_M+eMYurIrGjTxKexbB8cfg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
Hi,
 
The current design in the bis draft (as well as in in RFC 3984) does allow negotiation of asymmetric video solutions using SDP offer/answer. What you need to do is just to separate the sending part (a=sendonly) and the receiving part (=recvonly) in the SDP. Therefore, I don't think there is any problem and any need for change in the regard.
 
BR,YK

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Roni Even
Sent: Monday, May 04, 2009 5:09 PM
To: avt@ietf.org
Subject: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level

From: Ashish Goyal
Sent: Tuesday, May 05, 2009 12:04 AM
To: 'avt@ietf.org'
Subject: draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level

 

Hi,

   I am leading an effort of sip video vendors under the aegis of IMTC Sip video parity and working on a BCP document to enhance sip video interoperability. In our discussion today there were some concerns around the section 8.2.2 of 3984bis – specifically around the text

 

 “The level part of  "profile-level-id" is downgradable, i.e. the answerer MUST  maintain the same or a lower level or remove the media format  (payload type) completely. “

 

 I am writing this mail in the hope that we can amend the 3984 bis so that we can consider it as a reference – rather than having a conflicting BCP document for video.

 

   The recommendation from the group was to

1)      Consider level parameter as a declaration of receive capabilities and not let it imply the resolution used for transmit

2)      Consider the level parameter as either upgradeable or downgradeable – since it’s really talking about receive capability. The answerer must not transmit a level higher than the offer – but can provide an answer which contains a level higher than the offer. This would allow the offerer to transmit a higher level than it can receive – if it chooses to.

 

  Here is  the issue that we are trying to address by having asymmetric support for level.

 

  One of the use cases which is well supported by some of the leading video implementers is support for asymmetric video resolutions. The use case where this becomes important is when the calls are made from a video softclient  running on  a pc.  Because of asymmetric compute requirements on encode and decode – the video softclients would be able to typically decode much higher resolution – than they are able to encode.  However section 8.2.2  makes this negotiation difficult. 

 

 Here is how the use case is expected to work.

 

  Assume the video device A is able to decode level 3.1 and encode only level 1.1

  B is capable of both decoding and encoding level 3.1.

  A would quote a level of 3.1 in its offer

  B would respond with level 3.1 in the answer

 

  A would send to B video stream at level 1.1 – since A can only encode at level 1.1.

  B would send level 3.1 to A since A can decode upto level 3.1.

 

 

Regards,

Ashish

--Boundary_(ID_M+eMYurIrGjTxKexbB8cfg)-- From john.elwell@siemens-enterprise.com Tue May 5 01:46:24 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37ED03A6D02 for ; Tue, 5 May 2009 01:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iHHZ4FDxK9OA for ; Tue, 5 May 2009 01:46:23 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id BC8193A6CF3 for ; Tue, 5 May 2009 01:46:05 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KJ5008DXXPBXQ@siemenscomms.co.uk> for avt@ietf.org; Tue, 05 May 2009 09:47:29 +0100 (BST) Date: Tue, 05 May 2009 09:46:42 +0100 From: "Elwell, John" In-reply-to: <089AD8684C5E4C2995F01C2527EE7081@china.huawei.com> To: Ye-Kui Wang , Roni Even , avt@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D001D8DC97@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level Thread-Index: AcnM1Y81eH5hh4rORt+9cpb8aAHZ7wAESgPQAABHA9AABShl8AABbg4QABZuUcA= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <49ff59e6.1358560a.4af5.05e3@mx.google.com> <089AD8684C5E4C2995F01C2527EE7081@china.huawei.com> Subject: Re: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 08:46:24 -0000 YK, If I understand correctly, you would have two m-lines, one a=3Dsendonly (on which a lower bandwidth is negotiated, say), and one a=3Drecvonly = (on which a higher bandwidth is negotiated, say)? This would really complicate things. For example, I think you would need to assign two different labels (a=3Dlabel attribute), because I don't think the use of the same label for two m-lines is defined. How would you refer to them for floor control purposes? Also you would need to convey two a=3Dcrypto lines for security descriptions if using SRTP. It would also complicate NAT traversal, e.g., if using ICE, I think you would need to treat them as two separate media. John > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On=20 > Behalf Of Ye-Kui Wang > Sent: 04 May 2009 22:56 > To: 'Roni Even'; avt@ietf.org > Subject: Re: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt -=20 > Profile level >=20 > Hi, > =20 > The current design in the bis draft (as well as in in RFC=20 > 3984) does allow negotiation of asymmetric video solutions=20 > using SDP offer/answer. What you need to do is just to=20 > separate the sending part (a=3Dsendonly) and the receiving part=20 > (=3Drecvonly) in the SDP. Therefore, I don't think there is any=20 > problem and any need for change in the regard.=20 > =20 > BR,YK >=20 >=20 > ________________________________ >=20 > From: avt-bounces@ietf.org=20 > [mailto:avt-bounces@ietf.org] On Behalf Of Roni Even > Sent: Monday, May 04, 2009 5:09 PM > To: avt@ietf.org > Subject: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt -=20 > Profile level > =09 > =09 >=20 > From: Ashish Goyal=20 > Sent: Tuesday, May 05, 2009 12:04 AM > To: 'avt@ietf.org' > Subject: draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level=20 >=20 > =20 >=20 > Hi,=20 >=20 > I am leading an effort of sip video vendors under=20 > the aegis of IMTC Sip video parity and working on a BCP=20 > document to enhance sip video interoperability. In our=20 > discussion today there were some concerns around the section=20 > 8.2.2 of 3984bis - specifically around the text >=20 > =20 >=20 > "The level part of "profile-level-id" is=20 > downgradable, i.e. the answerer MUST maintain the same or a=20 > lower level or remove the media format (payload type) completely. " >=20 > =20 >=20 > I am writing this mail in the hope that we can amend=20 > the 3984 bis so that we can consider it as a reference -=20 > rather than having a conflicting BCP document for video.=20 >=20 > =20 >=20 > The recommendation from the group was to >=20 > 1) Consider level parameter as a declaration of=20 > receive capabilities and not let it imply the resolution used=20 > for transmit >=20 > 2) Consider the level parameter as either=20 > upgradeable or downgradeable - since it's really talking=20 > about receive capability. The answerer must not transmit a=20 > level higher than the offer - but can provide an answer which=20 > contains a level higher than the offer. This would allow the=20 > offerer to transmit a higher level than it can receive - if=20 > it chooses to.=20 >=20 > =20 >=20 > Here is the issue that we are trying to address by=20 > having asymmetric support for level.=20 >=20 > =20 >=20 > One of the use cases which is well supported by some=20 > of the leading video implementers is support for asymmetric=20 > video resolutions. The use case where this becomes important=20 > is when the calls are made from a video softclient running=20 > on a pc. Because of asymmetric compute requirements on=20 > encode and decode - the video softclients would be able to=20 > typically decode much higher resolution - than they are able=20 > to encode. However section 8.2.2 makes this negotiation difficult. =20 >=20 > =20 >=20 > Here is how the use case is expected to work.=20 >=20 > =20 >=20 > Assume the video device A is able to decode level 3.1=20 > and encode only level 1.1 >=20 > B is capable of both decoding and encoding level 3.1.=20 >=20 > A would quote a level of 3.1 in its offer >=20 > B would respond with level 3.1 in the answer >=20 > =20 >=20 > A would send to B video stream at level 1.1 - since A=20 > can only encode at level 1.1.=20 >=20 > B would send level 3.1 to A since A can decode upto level 3.1. >=20 > =20 >=20 > =20 >=20 > Regards,=20 >=20 > Ashish >=20 >=20 From spoorthi.ka@globaledgesoft.com Tue May 5 05:32:57 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 845AE3A6C55 for ; Tue, 5 May 2009 05:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.16 X-Spam-Level: X-Spam-Status: No, score=0.16 tagged_above=-999 required=5 tests=[AWL=-0.835, BAYES_50=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R585cpuHkdb8 for ; Tue, 5 May 2009 05:32:56 -0700 (PDT) Received: from gesmail.globaledgesoft.com (gesmail.globaledgesoft.com [203.76.137.4]) by core3.amsl.com (Postfix) with ESMTP id A9C163A6A21 for ; Tue, 5 May 2009 05:32:55 -0700 (PDT) Received: from [172.16.8.111] (unknown [172.16.8.111]) by gesmail.globaledgesoft.com (Postfix) with ESMTP id 75C5F17B424 for ; Tue, 5 May 2009 18:04:19 +0530 (IST) Message-ID: <4A0031E4.4030100@globaledgesoft.com> Date: Tue, 05 May 2009 18:02:36 +0530 From: Spoorthi User-Agent: Thunderbird 2.0.0.17 (X11/20080914) MIME-Version: 1.0 To: avt@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [AVT] Fax over RTP X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 12:32:57 -0000 Hi, Does anybody know about FAX (t.38) over RTP. Plz provide links to the documents to know about t.38 over RTP. Thnx and Rgs, spoorthi From lee_dilkie@mitel.com Tue May 5 06:11:43 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B6C73A6D32 for ; Tue, 5 May 2009 06:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FB+m5YF3nown for ; Tue, 5 May 2009 06:11:42 -0700 (PDT) Received: from smtp.mitel.com (smtp.mitel.com [216.191.234.102]) by core3.amsl.com (Postfix) with ESMTP id EDBC928C220 for ; Tue, 5 May 2009 06:11:36 -0700 (PDT) Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id 4AC392C021; Tue, 5 May 2009 08:39:50 -0400 (EDT) X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com Received: from smtp.mitel.com ([127.0.0.1]) by localhost (smtp.mitel.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82hcC3LPyC3J; Tue, 5 May 2009 08:39:50 -0400 (EDT) Received: from [10.39.164.100] (unknown [10.39.164.100]) by smtp.mitel.com (Postfix) with ESMTP id 207FD2C020; Tue, 5 May 2009 08:39:50 -0400 (EDT) Message-ID: <4A0033A1.9010307@mitel.com> Date: Tue, 05 May 2009 08:40:01 -0400 From: Lee Dilkie User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Spoorthi References: <4A0031E4.4030100@globaledgesoft.com> In-Reply-To: <4A0031E4.4030100@globaledgesoft.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: avt@ietf.org Subject: Re: [AVT] Fax over RTP X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 13:11:43 -0000 I'm curious... What did your last slave die from? Spoorthi wrote: > Hi, > > Does anybody know about FAX (t.38) over RTP. Plz provide links to > the documents to know about t.38 over RTP. > > Thnx and Rgs, > spoorthi > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From Albrecht.Schwarz@alcatel-lucent.de Tue May 5 06:31:41 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53FF63A67ED for ; Tue, 5 May 2009 06:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.363 X-Spam-Level: X-Spam-Status: No, score=-5.363 tagged_above=-999 required=5 tests=[AWL=0.886, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzltfmvbKusB for ; Tue, 5 May 2009 06:31:40 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 60BDA3A6AA8 for ; Tue, 5 May 2009 06:31:10 -0700 (PDT) Received: from FRVELSBHS03.ad2.ad.alcatel.com (frvelsbhs03.dc-m.alcatel-lucent.com [155.132.6.75]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n45DWYfs018848; Tue, 5 May 2009 15:32:34 +0200 Received: from FRVELSMBS23.ad2.ad.alcatel.com ([155.132.6.56]) by FRVELSBHS03.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 May 2009 15:32:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 May 2009 15:32:33 +0200 Message-ID: In-Reply-To: <4A0033A1.9010307@mitel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] Fax over RTP Thread-Index: AcnNg0jmMuVMC49hRJGeBG1ySwr5swAAlMDQ References: <4A0031E4.4030100@globaledgesoft.com> <4A0033A1.9010307@mitel.com> From: "Schwarz Albrecht" To: "Lee Dilkie" , "Spoorthi" X-OriginalArrivalTime: 05 May 2009 13:32:34.0570 (UTC) FILETIME=[F2DD3EA0:01C9CD85] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: avt@ietf.org Subject: Re: [AVT] Fax over RTP X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 13:31:41 -0000 See ITU-T Rec. T.38 (2007), clause 9.2 for Fax/T.38-over-IFT/RTP/UDP =20 Alternative: Fax as VBDoIP service using V.152 with G.711 as VBD codec, i.e. Fax/G.711/RTP/UDP > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On=20 > Behalf Of Lee Dilkie > Sent: Dienstag, 5. Mai 2009 14:40 > To: Spoorthi > Cc: avt@ietf.org > Subject: Re: [AVT] Fax over RTP >=20 > I'm curious... What did your last slave die from? >=20 > Spoorthi wrote: > > Hi, > > > > Does anybody know about FAX (t.38) over RTP. Plz provide links to=20 > > the documents to know about t.38 over RTP. > > > > Thnx and Rgs, > > spoorthi > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt >=20 From tom.taylor@rogers.com Tue May 5 07:06:39 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FE443A6C20 for ; Tue, 5 May 2009 07:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SztkOANLfWBm for ; Tue, 5 May 2009 07:06:38 -0700 (PDT) Received: from smtp125.rog.mail.re2.yahoo.com (smtp125.rog.mail.re2.yahoo.com [206.190.53.30]) by core3.amsl.com (Postfix) with SMTP id A95E13A6936 for ; Tue, 5 May 2009 07:05:47 -0700 (PDT) Received: (qmail 59258 invoked from network); 5 May 2009 14:07:12 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=YC7PiRvjqHkkYTBbIuJw5t6ARoNgdGIMBByDnPA/jqXlh6+UBa44U4ZdZ6JPc2lE0phk+mTBkMEq8Il3aUK7EWiNqIYRO9Q2XOXhiyj9dXHqw2l+NJW+TrsSKJuXAkNTRpb2oeWjumKrlsm3FmlCHTwkCfOu0l2z++xxspF7eT4= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@174.115.211.243 with plain) by smtp125.rog.mail.re2.yahoo.com with SMTP; 5 May 2009 14:07:11 -0000 X-YMail-OSG: seNYNT0VM1lVLZOOuGvjk4S99Wl1IydCGgrYSJteilk2WqCY2ybEQVtukJZoOuMKWw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A004813.20105@rogers.com> Date: Tue, 05 May 2009 10:07:15 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Christian Groves References: <49FE5805.3040107@nteczone.com> In-Reply-To: <49FE5805.3040107@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: avt@ietf.org Subject: Re: [AVT] Comments on draft-ietf-avt-rtcp-xr-* drafts X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 14:06:39 -0000 Good catch on that first ABNF point. The correct notation (see RFC 5234 section 3.3) is xr-format =/ xr-bgd-block Christian Groves wrote: > Hello Geoff and Alan, > > I was reading the RTCP-XR drafts to get a feel for the work and to see > how these drafts would be supported in the context of H.248.48. I've a > few comments/questions: > > draft-ietf-avt-rtcp-xr-burst-gap-discard-01.txt > ----------------------------------------------- > In section 5 SDP signalling there's the ABNF "xr-format = xr-format / > xr-bgd-block" > Is this really valid ABNF? It seems to me to be a circular reference. I > know you want to add "xr-bgd-block" to the list of xr-formats Would it > be better to simply list the type that is being added in the draft? i.e. > "xr-format = xr-bgd-block" > This is a general comment for all the drafts. > > draft-ietf-avt-rtcp-xr-qoe-00 > ----------------------------- > There's no description of direction in section 3.2?? > There also appears to be missing ABNF for the definition of "word" in > section 4, although I'm not sure that this the correct ABNF for what is > being described. I assume that you want to be able to set the type and > calculation algorithm that is required? > > draft-ietf-avt-rtcp-xr-siglevel-00.txt > ------------------------------------ > Similar comments to above. Additionally there's a typo in section 5 > where you refer to QoE Metrics. > > Regards, Christian > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > From jonathan@vidyo.com Tue May 5 07:18:09 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A47B3A6859 for ; Tue, 5 May 2009 07:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OrGmZuF8S3n for ; Tue, 5 May 2009 07:18:08 -0700 (PDT) Received: from mx1.myoutlookonline.com (mx1.myoutlookonline.com [64.95.72.238]) by core3.amsl.com (Postfix) with ESMTP id A5DB53A6A0D for ; Tue, 5 May 2009 07:18:05 -0700 (PDT) Received: from be150.mail.lan ([10.110.20.150]) by mx1.myoutlookonline.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 May 2009 10:19:31 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 May 2009 10:19:29 -0400 Message-ID: <6B55710E7F51AD4B93F336052113B85F8C7F30@be150.mail.lan> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D001D8DC97@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level Thread-Index: AcnM1Y81eH5hh4rORt+9cpb8aAHZ7wAESgPQAABHA9AABShl8AABbg4QABZuUcAAC7QXEA== References: <49ff59e6.1358560a.4af5.05e3@mx.google.com><089AD8684C5E4C2995F01C2527EE7081@china.huawei.com> <0D5F89FAC29E2C41B98A6A762007F5D001D8DC97@GBNTHT12009MSX.gb002.siemens.net> From: "Jonathan Lennox" To: "Elwell, John" , "Ye-Kui Wang" , "Roni Even" , X-OriginalArrivalTime: 05 May 2009 14:19:31.0726 (UTC) FILETIME=[820522E0:01C9CD8C] Subject: Re: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 14:18:09 -0000 I agree with John's analysis of Ye-Kui's statement -- trying to do asymmetric media using separate m=3D lines isn't very practical for a number of reasons. That said, though I think it would be cleaner to have purely receive-only semantics for profile-level-id, I have trouble imagining situations for which the current specification is problematic. The profile-level-id parameter only gives an upper bound on what the bitstream can contain; it's always valid to send a bitstream that uses a lower (more constrained) profile and level than what was negotiated. Thus, I don't see a problem unless an endpoint wants to encode using a *higher* profile or level than it's able to decode. I suppose this could happen for pre-encoded video, hardware-assisted encoding, or the like, but it certainly seems like a more unusual case for bi-directional media. --=20 Jonathan Lennox Vidyo, Inc jonathan@vidyo.com > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Tuesday, May 05, 2009 4:47 AM > To: Ye-Kui Wang; Roni Even; avt@ietf.org > Subject: Re: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level >=20 > YK, >=20 > If I understand correctly, you would have two m-lines, one = a=3Dsendonly > (on which a lower bandwidth is negotiated, say), and one a=3Drecvonly (on > which a higher bandwidth is negotiated, say)? This would really > complicate things. For example, I think you would need to assign two > different labels (a=3Dlabel attribute), because I don't think the use = of > the same label for two m-lines is defined. How would you refer to them > for floor control purposes? Also you would need to convey two = a=3Dcrypto > lines for security descriptions if using SRTP. It would also complicate > NAT traversal, e.g., if using ICE, I think you would need to treat them > as two separate media. >=20 > John >=20 >=20 > > -----Original Message----- > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > > Behalf Of Ye-Kui Wang > > Sent: 04 May 2009 22:56 > > To: 'Roni Even'; avt@ietf.org > > Subject: Re: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - > > Profile level > > > > Hi, > > > > The current design in the bis draft (as well as in in RFC > > 3984) does allow negotiation of asymmetric video solutions > > using SDP offer/answer. What you need to do is just to > > separate the sending part (a=3Dsendonly) and the receiving part > > (=3Drecvonly) in the SDP. Therefore, I don't think there is any > > problem and any need for change in the regard. > > > > BR,YK > > > > > > ________________________________ > > > > From: avt-bounces@ietf.org > > [mailto:avt-bounces@ietf.org] On Behalf Of Roni Even > > Sent: Monday, May 04, 2009 5:09 PM > > To: avt@ietf.org > > Subject: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - > > Profile level > > > > > > > > From: Ashish Goyal > > Sent: Tuesday, May 05, 2009 12:04 AM > > To: 'avt@ietf.org' > > Subject: draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level > > > > > > > > Hi, > > > > I am leading an effort of sip video vendors under > > the aegis of IMTC Sip video parity and working on a BCP > > document to enhance sip video interoperability. In our > > discussion today there were some concerns around the section > > 8.2.2 of 3984bis - specifically around the text > > > > > > > > "The level part of "profile-level-id" is > > downgradable, i.e. the answerer MUST maintain the same or a > > lower level or remove the media format (payload type) completely. " > > > > > > > > I am writing this mail in the hope that we can amend > > the 3984 bis so that we can consider it as a reference - > > rather than having a conflicting BCP document for video. > > > > > > > > The recommendation from the group was to > > > > 1) Consider level parameter as a declaration of > > receive capabilities and not let it imply the resolution used > > for transmit > > > > 2) Consider the level parameter as either > > upgradeable or downgradeable - since it's really talking > > about receive capability. The answerer must not transmit a > > level higher than the offer - but can provide an answer which > > contains a level higher than the offer. This would allow the > > offerer to transmit a higher level than it can receive - if > > it chooses to. > > > > > > > > Here is the issue that we are trying to address by > > having asymmetric support for level. > > > > > > > > One of the use cases which is well supported by some > > of the leading video implementers is support for asymmetric > > video resolutions. The use case where this becomes important > > is when the calls are made from a video softclient running > > on a pc. Because of asymmetric compute requirements on > > encode and decode - the video softclients would be able to > > typically decode much higher resolution - than they are able > > to encode. However section 8.2.2 makes this negotiation difficult. > > > > > > > > Here is how the use case is expected to work. > > > > > > > > Assume the video device A is able to decode level 3.1 > > and encode only level 1.1 > > > > B is capable of both decoding and encoding level 3.1. > > > > A would quote a level of 3.1 in its offer > > > > B would respond with level 3.1 in the answer > > > > > > > > A would send to B video stream at level 1.1 - since A > > can only encode at level 1.1. > > > > B would send level 3.1 to A since A can decode upto level 3.1. > > > > > > > > > > > > Regards, > > > > Ashish > > > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From yekuiwang@huawei.com Tue May 5 07:39:41 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0A333A700E for ; Tue, 5 May 2009 07:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.828 X-Spam-Level: X-Spam-Status: No, score=-1.828 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id noDaIjsAL-93 for ; Tue, 5 May 2009 07:39:34 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id CA0F73A6FE6 for ; Tue, 5 May 2009 07:39:34 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJ6002EGE4CNC@usaga04-in.huawei.com> for avt@ietf.org; Tue, 05 May 2009 09:41:00 -0500 (CDT) Received: from W90946 ([10.193.125.102]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJ60003LE3F2S@usaga04-in.huawei.com> for avt@ietf.org; Tue, 05 May 2009 09:40:59 -0500 (CDT) Date: Tue, 05 May 2009 10:40:25 -0400 From: Ye-Kui Wang In-reply-to: <717562D70E24CF489737F81B0EA234DF0E712574@lsmail.austin.kmvtechnologies.com> To: 'Ashish Goyal' , 'Roni Even' , avt@ietf.org Message-id: <07F83448A6AC4B428694E13E14AB3F9C@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_Q2DgpBi97ZKy2+YRLVMfTw)" Thread-index: AcnM1Y81eH5hh4rORt+9cpb8aAHZ7wAESgPQAABHA9AABShl8AABbg4QAArIxxAAF63JQA== References: <49ff59e6.1358560a.4af5.05e3@mx.google.com> <089AD8684C5E4C2995F01C2527EE7081@china.huawei.com> <717562D70E24CF489737F81B0EA234DF0E712574@lsmail.austin.kmvtechnologies.com> Subject: Re: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 14:39:42 -0000 This is a multi-part message in MIME format. --Boundary_(ID_Q2DgpBi97ZKy2+YRLVMfTw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT I don't see a technical reason why the level part was not specified as a capability parameter in the beginning. However, now it is too late because there are already a huge amount of RFC 3984 implementations taking the level part in the way as specified in RFC 3984 and the bis draft. Unless something is broken, we should not make a change that is not backward compatible, because that will hurt interoperability instead of making better interoperability. BR, YK _____ From: Ashish Goyal [mailto:agoyal@lifesize.com] Sent: Monday, May 04, 2009 11:01 PM To: Ye-Kui Wang; Roni Even; avt@ietf.org Subject: RE: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level The sendonly and recvonly is normally not handled well by some proxies/session border controllers and some UAs. While technically it's possible to do that - it's however not interoperable implementation. Is there a specific reason why the level part is considered non upgradeable? Ashish From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ye-Kui Wang Sent: Tuesday, May 05, 2009 3:26 AM To: 'Roni Even'; avt@ietf.org Subject: Re: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level Hi, The current design in the bis draft (as well as in in RFC 3984) does allow negotiation of asymmetric video solutions using SDP offer/answer. What you need to do is just to separate the sending part (a=sendonly) and the receiving part (=recvonly) in the SDP. Therefore, I don't think there is any problem and any need for change in the regard. BR,YK _____ From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Roni Even Sent: Monday, May 04, 2009 5:09 PM To: avt@ietf.org Subject: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level From: Ashish Goyal Sent: Tuesday, May 05, 2009 12:04 AM To: 'avt@ietf.org' Subject: draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level Hi, I am leading an effort of sip video vendors under the aegis of IMTC Sip video parity and working on a BCP document to enhance sip video interoperability. In our discussion today there were some concerns around the section 8.2.2 of 3984bis - specifically around the text "The level part of "profile-level-id" is downgradable, i.e. the answerer MUST maintain the same or a lower level or remove the media format (payload type) completely. " I am writing this mail in the hope that we can amend the 3984 bis so that we can consider it as a reference - rather than having a conflicting BCP document for video. The recommendation from the group was to 1) Consider level parameter as a declaration of receive capabilities and not let it imply the resolution used for transmit 2) Consider the level parameter as either upgradeable or downgradeable - since it's really talking about receive capability. The answerer must not transmit a level higher than the offer - but can provide an answer which contains a level higher than the offer. This would allow the offerer to transmit a higher level than it can receive - if it chooses to. Here is the issue that we are trying to address by having asymmetric support for level. One of the use cases which is well supported by some of the leading video implementers is support for asymmetric video resolutions. The use case where this becomes important is when the calls are made from a video softclient running on a pc. Because of asymmetric compute requirements on encode and decode - the video softclients would be able to typically decode much higher resolution - than they are able to encode. However section 8.2.2 makes this negotiation difficult. Here is how the use case is expected to work. Assume the video device A is able to decode level 3.1 and encode only level 1.1 B is capable of both decoding and encoding level 3.1. A would quote a level of 3.1 in its offer B would respond with level 3.1 in the answer A would send to B video stream at level 1.1 - since A can only encode at level 1.1. B would send level 3.1 to A since A can decode upto level 3.1. Regards, Ashish --Boundary_(ID_Q2DgpBi97ZKy2+YRLVMfTw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
I don't see a technical reason why the level part was not specified as a capability parameter in the beginning. However, now it is too late because there are already a huge amount of RFC 3984 implementations taking the level part in the way as specified in RFC 3984 and the bis draft. Unless something is broken, we should not make a change that is not backward compatible, because that will hurt interoperability instead of making better interoperability.
 
BR, YK

From: Ashish Goyal [mailto:agoyal@lifesize.com]
Sent: Monday, May 04, 2009 11:01 PM
To: Ye-Kui Wang; Roni Even; avt@ietf.org
Subject: RE: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level

The sendonly and recvonly is normally not handled well by some proxies/session border controllers and some UAs. While technically it’s possible to do that – it’s however not interoperable implementation.

Is there a specific reason why the level part is considered  non upgradeable?

Ashish

 

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ye-Kui Wang
Sent: Tuesday, May 05, 2009 3:26 AM
To: 'Roni Even'; avt@ietf.org
Subject: Re: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level

 

Hi,

 

The current design in the bis draft (as well as in in RFC 3984) does allow negotiation of asymmetric video solutions using SDP offer/answer. What you need to do is just to separate the sending part (a=sendonly) and the receiving part (=recvonly) in the SDP. Therefore, I don't think there is any problem and any need for change in the regard.

 

BR,YK

 

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Roni Even
Sent: Monday, May 04, 2009 5:09 PM
To: avt@ietf.org
Subject: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level

From: Ashish Goyal
Sent: Tuesday, May 05, 2009 12:04 AM
To: 'avt@ietf.org'
Subject: draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level

 

Hi,

   I am leading an effort of sip video vendors under the aegis of IMTC Sip video parity and working on a BCP document to enhance sip video interoperability. In our discussion today there were some concerns around the section 8.2.2 of 3984bis – specifically around the text

 

 “The level part of  "profile-level-id" is downgradable, i.e. the answerer MUST  maintain the same or a lower level or remove the media format  (payload type) completely. “

 

 I am writing this mail in the hope that we can amend the 3984 bis so that we can consider it as a reference – rather than having a conflicting BCP document for video.

 

   The recommendation from the group was to

1)      Consider level parameter as a declaration of receive capabilities and not let it imply the resolution used for transmit

2)      Consider the level parameter as either upgradeable or downgradeable – since it’s really talking about receive capability. The answerer must not transmit a level higher than the offer – but can provide an answer which contains a level higher than the offer. This would allow the offerer to transmit a higher level than it can receive – if it chooses to.

 

  Here is  the issue that we are trying to address by having asymmetric support for level.

 

  One of the use cases which is well supported by some of the leading video implementers is support for asymmetric video resolutions. The use case where this becomes important is when the calls are made from a video softclient  running on  a pc.  Because of asymmetric compute requirements on encode and decode – the video softclients would be able to typically decode much higher resolution – than they are able to encode.  However section 8.2.2  makes this negotiation difficult. 

 

 Here is how the use case is expected to work.

 

  Assume the video device A is able to decode level 3.1 and encode only level 1.1

  B is capable of both decoding and encoding level 3.1.

  A would quote a level of 3.1 in its offer

  B would respond with level 3.1 in the answer

 

  A would send to B video stream at level 1.1 – since A can only encode at level 1.1.

  B would send level 3.1 to A since A can decode upto level 3.1.

 

 

Regards,

Ashish

--Boundary_(ID_Q2DgpBi97ZKy2+YRLVMfTw)-- From vincent.roca@inrialpes.fr Tue May 5 07:44:21 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C924D3A6C2E; Tue, 5 May 2009 07:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.188 X-Spam-Level: X-Spam-Status: No, score=-6.188 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGUR6V6Cn3Im; Tue, 5 May 2009 07:44:20 -0700 (PDT) Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by core3.amsl.com (Postfix) with ESMTP id CC72A3A6A21; Tue, 5 May 2009 07:44:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,297,1238968800"; d="scan'208";a="39486264" Received: from ornon.inrialpes.fr (HELO [194.199.24.115]) ([194.199.24.115]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 May 2009 16:45:44 +0200 Message-ID: <4A005118.40107@inrialpes.fr> Date: Tue, 05 May 2009 16:45:44 +0200 From: Vincent Roca User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <04CAD96D4C5A3D48B1919248A8FE0D54066184FC@xmb-sjc-215.amer.cisco.com> <49FF0566.4080000@inrialpes.fr> <04CAD96D4C5A3D48B1919248A8FE0D54093C3454@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D54093C3454@xmb-sjc-215.amer.cisco.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: Marshall Eubanks , avt@ietf.org, fecframe@ietf.org Subject: Re: [AVT] [Fecframe] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 14:44:21 -0000 Hello Ali, A few answers inline, after removing the points where we agree. Ali C. Begen (abegen) wrote: > 1/** Introduction, p.4 [...] > I also suggest to clarify the Source/Repair Flow definitions in > Section 3.1, to say explicitly that there are different possible > mappings to transport flow(s). > > Ali: This should rather go to the framework draft. VR: Since the intent was to keep this document more or less independent from the framework I-D, it would make sense to put it here too. > 2/** Section 4.2, p13: > It is said: > o Synchronization Source (SSRC): The SSRC value SHALL be randomly > assigned as suggested by [RFC3550]. This allows the sender to > multiplex the source and repair flows on the same port, or > multiplex multiple repair flows on a single port. > > I suggest to refer to "transport flows", i.e., in case of UDP, the > 5-tuple, rather than "port" which is much more imprecise. BTW, do you > refer to the source or destination port in the above sentence, and > what about the source/destination address? > > Ali: If two RTP streams are sent to different IP addresses, they are different > RTP sessions anyway. Random SSRCs help when we send two RTP streams in the same > RTP session. Source address/port is irrelevant. So, I don't see any confusion here. VR: No, there is a confusion. Imagine that the sender uses different destination addresses, but the same destination port. In that case we don't need the SSRC. Saying "on the same port" without saying "and the same destination address" is misleading. I suggest: This allows the sender to multiplex the source and repair flows on the same RTP session (i.e., same destination address and port), or multiplex multiple repair flows on the same RTP session. > 3/** Fig. 3: > Current figure looks like the following: > [...] > + > ------------- > | XOR | > ------------- > = > +===+ > |C_1| > +===+ > > I don't like the "+ XOR" in the above figure, since it suggests (to me > at least) that the {S_1 .. S_XXX} symbols are "summed" with a XOR symbol > to produce the C_1. I'd prefer something like: > > XOR sum of set > +-------------+ > | S_1 | > | S_L+1 | > | . | > | . | > | . | > | S_(D-1)xL+1 | > +-------------+ > = > +===+ > |C_1| > +===+ > > (and something similar with the 1D/2D I-D) > > Ali: I believe the context is clear here as the source, repair and operation are encapsulated differently. VR: you're right, the encapsulation is different, I didn't notice. However I still don't like the XOR box which remains misleading IMHO. But you are the editor, I let you decide. > 4/** Section 4.2 "Repair Packets", p12, RTP header clarifications. > I don't like the sentences: > "This bit is obtained by applying protection to the corresponding > XX bits from the RTP headers of the source packets protected by > this repair packet". > > We don't apply any protection to produce this bit, this is the contrary. > I suggest: > "This bit is equal to the XOR sum of the corresponding XX bits > from the RTP headers of the source packets protected by this > repair packet". > > Ali: I am sorry but I don't get your point. I could say "applying XOR operation" > but the difference is negligible. VR: I don't like "by applying protection" or "by applying XOR operation" in the sentence and prefer my wording. Here also, you are the editor. > 8/** Section 6, p.23: > It is said: > "Note that if the payload lengths of the source packets are not equal, > each shorter packet MUST be padded to the length of the longest > packet by adding octet 0's at the end. Due to this possible padding > and mandatory FEC header, a repair packet usually has a larger size > than the source packets it protects. This may cause problems if the > resulting repair packet size exceeds the Maximum Transmission Unit > (MTU) size of the path over which the repair flow is sent." > > Several issues: > - a repair packet ALWAYS (rather than "usually") has a larger size > than the source packets it protects (even the longest one, because > of the additional 16 byte FEC header in that case). > > Ali: I'd agree with this. But 2733 did not use "always" in the text. Not > sure whether we should stick with it, though. VR: I was not aware of the RFC2733 wording. In any case, if there's a small mistake in this RFC, I don't see any good reason to reproduce it here. > 10/** Section 6.3.2. "Recovering the RTP Header and Payload", p 25 > It is said: > 2. For the repair packet associated with set T, compute the bit > string in the same fashion except use the PT recovery field > instead of the PT field and TS recovery field instead of the > Timestamp field, and set the CSRC list, header extension and > padding to null regardless of the values of the CC field, X bit > and P bit. > This is not clear at all to me (even if I understand the intent). > The structure of the bit string is the same, but the values are the > ones that have been received. So, saying "compute the XXX field in > the same fashion..." is misleading, as well as "XXX recovery field". > > I suggest: > 2. For the repair packet associated with set T, construct the bit > string similarly, using the values received in the repair > packet for the PT and TS fields, ... > > Ali: No. We need to explicitly say the "PT/TS recovery fields" here since > there are also the PT and TS fields in the RTP header. VR: Oups, you're right! I forgot that the "TP (resp. TS) recovery field" comes from the FEC Header. We can perhaps clarify the original wording to avoid such a mistake in the future (even if it's now clear to me): 2. For the repair packet associated with set T, compute the bit string in the same fashion, except that we use the PT (resp. TS) recovery field of the FEC header instead of the PT (resp. Timestamp) field of the RTP header,... > 11/** Section 6.3.2. "Recovering the RTP Header and Payload", p 25 > > I also suggest a different ordering, since as such there is an > incoherency: In step 1, we cannot "compute the bit string as described > in section 6.2", since we still don't know at this stage the maximum > length, and so the required padding. > But if we switch the order, everything works well. > > I suggest (reorder + merge): > 1. For the repair packet... > 2. For each of the source packets, ... If the bit string generated > is shorter than the string generated for the repair packet... > > Ali: Not that this is incorrect, but the current text is not incorrect, > either. Padding does not change the bitstring and necessary padding can > always be added. I suggest to keep the current text to be consistent with 2733. VR: As you want, but I'll swap the order if I implement it ;-) Cheers, Vincent From yekuiwang@huawei.com Tue May 5 07:46:43 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5002D28C23D for ; Tue, 5 May 2009 07:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.364 X-Spam-Level: X-Spam-Status: No, score=-1.364 tagged_above=-999 required=5 tests=[AWL=-0.565, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75cA9-K0Uzl8 for ; Tue, 5 May 2009 07:46:42 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id D6E5A28C24D for ; Tue, 5 May 2009 07:45:51 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJ60026TEEUNC@usaga04-in.huawei.com> for avt@ietf.org; Tue, 05 May 2009 09:47:18 -0500 (CDT) Received: from W90946 ([10.193.125.102]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJ60013JEEO89@usaga04-in.huawei.com> for avt@ietf.org; Tue, 05 May 2009 09:47:18 -0500 (CDT) Date: Tue, 05 May 2009 10:47:12 -0400 From: Ye-Kui Wang In-reply-to: <0D5F89FAC29E2C41B98A6A762007F5D001D8DC97@GBNTHT12009MSX.gb002.siemens.net> To: "'Elwell, John'" , 'Roni Even' , avt@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcnM1Y81eH5hh4rORt+9cpb8aAHZ7wAESgPQAABHA9AABShl8AABbg4QABZuUcAADOPO8A== References: <49ff59e6.1358560a.4af5.05e3@mx.google.com> <089AD8684C5E4C2995F01C2527EE7081@china.huawei.com> <0D5F89FAC29E2C41B98A6A762007F5D001D8DC97@GBNTHT12009MSX.gb002.siemens.net> Subject: Re: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 14:46:43 -0000 John, Yes, your understanding is correct, I meant use of two m-lines. While that is not perfect, I believe changing this fundamental part in a non-backward-compatible way would be much worse, as I explained in the previous email. Making the change can only help to enable asymmetric video solutions more conveniently, but would basically disable communications between any legacy implementation of new implementations. In addition, there might be a technical reason, which I don't know, duing the development of RFC 3984 for the current specification of the level part. BR, YK > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Tuesday, May 05, 2009 4:47 AM > To: Ye-Kui Wang; Roni Even; avt@ietf.org > Subject: RE: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - > Profile level > > YK, > > If I understand correctly, you would have two m-lines, one > a=sendonly (on which a lower bandwidth is negotiated, say), > and one a=recvonly (on which a higher bandwidth is > negotiated, say)? This would really complicate things. For > example, I think you would need to assign two different > labels (a=label attribute), because I don't think the use of > the same label for two m-lines is defined. How would you > refer to them for floor control purposes? Also you would need > to convey two a=crypto lines for security descriptions if > using SRTP. It would also complicate NAT traversal, e.g., if > using ICE, I think you would need to treat them as two separate media. > > John > > > > -----Original Message----- > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > Behalf Of > > Ye-Kui Wang > > Sent: 04 May 2009 22:56 > > To: 'Roni Even'; avt@ietf.org > > Subject: Re: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile > > level > > > > Hi, > > > > The current design in the bis draft (as well as in in RFC > > 3984) does allow negotiation of asymmetric video solutions > using SDP > > offer/answer. What you need to do is just to separate the > sending part > > (a=sendonly) and the receiving part > > (=recvonly) in the SDP. Therefore, I don't think there is > any problem > > and any need for change in the regard. > > > > BR,YK > > > > > > ________________________________ > > > > From: avt-bounces@ietf.org > > [mailto:avt-bounces@ietf.org] On Behalf Of Roni Even > > Sent: Monday, May 04, 2009 5:09 PM > > To: avt@ietf.org > > Subject: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - > Profile level > > > > > > > > From: Ashish Goyal > > Sent: Tuesday, May 05, 2009 12:04 AM > > To: 'avt@ietf.org' > > Subject: draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level > > > > > > > > Hi, > > > > I am leading an effort of sip video vendors under > > the aegis of IMTC Sip video parity and working on a BCP > > document to enhance sip video interoperability. In our > > discussion today there were some concerns around the section > > 8.2.2 of 3984bis - specifically around the text > > > > > > > > "The level part of "profile-level-id" is > > downgradable, i.e. the answerer MUST maintain the same or a > > lower level or remove the media format (payload type) completely. " > > > > > > > > I am writing this mail in the hope that we can amend > > the 3984 bis so that we can consider it as a reference - > > rather than having a conflicting BCP document for video. > > > > > > > > The recommendation from the group was to > > > > 1) Consider level parameter as a declaration of > > receive capabilities and not let it imply the resolution used > > for transmit > > > > 2) Consider the level parameter as either > > upgradeable or downgradeable - since it's really talking > > about receive capability. The answerer must not transmit a > > level higher than the offer - but can provide an answer which > > contains a level higher than the offer. This would allow the > > offerer to transmit a higher level than it can receive - if > > it chooses to. > > > > > > > > Here is the issue that we are trying to address by > > having asymmetric support for level. > > > > > > > > One of the use cases which is well supported by some > > of the leading video implementers is support for asymmetric > > video resolutions. The use case where this becomes important > > is when the calls are made from a video softclient running > > on a pc. Because of asymmetric compute requirements on > > encode and decode - the video softclients would be able to > > typically decode much higher resolution - than they are able > > to encode. However section 8.2.2 makes this negotiation > difficult. > > > > > > > > Here is how the use case is expected to work. > > > > > > > > Assume the video device A is able to decode level 3.1 > > and encode only level 1.1 > > > > B is capable of both decoding and encoding level 3.1. > > > > A would quote a level of 3.1 in its offer > > > > B would respond with level 3.1 in the answer > > > > > > > > A would send to B video stream at level 1.1 - since A > > can only encode at level 1.1. > > > > B would send level 3.1 to A since A can decode upto level 3.1. > > > > > > > > > > > > Regards, > > > > Ashish > > > > > From yekuiwang@huawei.com Tue May 5 08:20:42 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5965D3A6AA8; Tue, 5 May 2009 08:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.788 X-Spam-Level: X-Spam-Status: No, score=-1.788 tagged_above=-999 required=5 tests=[AWL=-0.074, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHv14i8NPjKA; Tue, 5 May 2009 08:20:37 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 4247828C130; Tue, 5 May 2009 08:20:37 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJ600CQ2FZVGO@usaga02-in.huawei.com>; Tue, 05 May 2009 08:21:32 -0700 (PDT) Received: from W90946 ([10.193.125.102]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJ600I6YFYXMG@usaga02-in.huawei.com>; Tue, 05 May 2009 08:21:31 -0700 (PDT) Date: Tue, 05 May 2009 11:20:53 -0400 From: Ye-Kui Wang In-reply-to: To: 'Stephan Wenger' , avt@ietf.org, fecframe@ietf.org Message-id: <2333479506674276BA8D2C5B9A04CD00@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_eoYm4PotupYXz5n/jpxQNw)" Thread-index: AcnLm9iJ3QTOagKUU02cbiSVJ8NneAB+HTYQ References: Subject: Re: [AVT] MPEG liaison statement to the IETF X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 15:20:42 -0000 This is a multi-part message in MIME format. --Boundary_(ID_eoYm4PotupYXz5n/jpxQNw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Information of the planned MPEG workshop can be found at http://www.chiariglione.org/mpeg/hot_news.htm. The background reason for the work item and the workshop can be found in the announcement of the workshop (named Workshop on MMT (MPEG Media Transport) on the website). BR, YK _____ From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Stephan Wenger Sent: Saturday, May 02, 2009 11:04 PM To: avt@ietf.org; fecframe@ietf.org Subject: [AVT] MPEG liaison statement to the IETF Hi all, MPEG has sent a liaison statement (29n10339) to the IETF related to their intention to work on media transport. I assume it will show up in the IETF's liaison tracker shortly. Meanwhile, if you need a copy and can't pull the MPEG documents yourself, email me. The IETF's email system does not allow me to add the .zip file the statement came in, and it's too big in unzipped format. Clearly, there is overlap, if not competition, between AVT's work and what MPEG anticipates, at least for some applications. I'm also copying fecframe. While the overlap in this case is less clear, I have reasons to believe that MPEG may touch our interests here as well. Arguably, there is a similar overlap/competition to the work performed in numerous other SDOs. The work appears to be in a very early stage. They are calling for a workshop during their forthcoming London meeting. Perhaps some of you are interested in submitting statements or attending the workshop... Regards, Stephan P.s.: I have an opinion about the intentions and plans behind this statement, but it would be impolite to voice it. --Boundary_(ID_eoYm4PotupYXz5n/jpxQNw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT MPEG liaison statement to the IETF
Information of the planned MPEG workshop can be found at http://www.chiariglione.org/mpeg/hot_news.htm. The background reason for the work item and the workshop can be found in the announcement of the workshop (named Workshop on MMT (MPEG Media Transport) on the website).
 
BR, YK

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Stephan Wenger
Sent: Saturday, May 02, 2009 11:04 PM
To: avt@ietf.org; fecframe@ietf.org
Subject: [AVT] MPEG liaison statement to the IETF

Hi all,
MPEG has sent a liaison statement (29n10339) to the IETF related to their intention to work on media transport.  I assume it will show up in the IETF’s liaison tracker shortly.  Meanwhile, if you need a copy and can’t pull the MPEG documents yourself, email me.  The IETF’s email system does not allow me to add the .zip file the statement came in, and it’s too big in unzipped format.
Clearly, there is overlap, if not competition, between AVT’s work and what MPEG anticipates, at least for some applications.  I’m also copying fecframe.  While the overlap in this case is less clear, I have reasons to believe that MPEG may touch our interests here as well.  Arguably, there is a similar overlap/competition to the work performed in numerous other SDOs.  
The work appears to be in a very early stage.  They are calling for a workshop during their forthcoming London meeting.  Perhaps some of you are interested in submitting statements or attending the workshop...
Regards,
Stephan
P.s.: I have an opinion about the intentions and plans behind this statement, but it would be impolite to voice it.
--Boundary_(ID_eoYm4PotupYXz5n/jpxQNw)-- From rsf@ns.live555.com Tue May 5 08:38:37 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 588643A6946 for ; Tue, 5 May 2009 08:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id baifsmrV5nmN for ; Tue, 5 May 2009 08:38:36 -0700 (PDT) Received: from ns.live555.com (ns.live555.com [4.79.217.242]) by core3.amsl.com (Postfix) with ESMTP id AFA513A6893 for ; Tue, 5 May 2009 08:38:36 -0700 (PDT) Received: from ns.live555.com (localhost.live555.com [127.0.0.1]) by ns.live555.com (8.14.2/8.14.2) with ESMTP id n45FeKfs004455; Tue, 5 May 2009 08:40:20 -0700 (PDT) (envelope-from rsf@ns.live555.com) Received: (from rsf@localhost) by ns.live555.com (8.14.2/8.14.2/Submit) id n45FeJJS004448; Tue, 5 May 2009 08:40:19 -0700 (PDT) (envelope-from rsf) Mime-Version: 1.0 Message-Id: In-Reply-To: <6D5990B2-9100-4AC8-89D3-BDEE27A002E5@apple.com> References: <6D5990B2-9100-4AC8-89D3-BDEE27A002E5@apple.com> Date: Tue, 5 May 2009 09:39:57 -0600 To: Roger Pantos From: Ross Finlayson Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: http-live-streaming-review@group.apple.com, avt@ietf.org Subject: Re: [AVT] iPhone streaming Internet-Draft posted X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 15:38:37 -0000 >We appreciate feedback on the protocol. Rather than invent yet another protocol, why not just implement a RTSP/RTP client on the iPhone instead? (If you *really* want to do this over HTTP (though ideally only when direct RTSP/RTP connectivity is not available), you could use the RTSP/RTP-over-HTTP hack that QuickTime Player already uses.) After all, there are plenty of people at Apple with expertise on this (but I dunno, perhaps they work in some other group? :-) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From ron.even.tlv@gmail.com Tue May 5 08:43:31 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C50963A6B2F for ; Tue, 5 May 2009 08:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.936 X-Spam-Level: X-Spam-Status: No, score=-0.936 tagged_above=-999 required=5 tests=[AWL=-0.899, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_22=0.6, SARE_RECV_BEZEQINT_B=0.763] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-PE6V6y1QRD for ; Tue, 5 May 2009 08:43:30 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by core3.amsl.com (Postfix) with ESMTP id 449E23A6A89 for ; Tue, 5 May 2009 08:43:30 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 13so1602005fge.18 for ; Tue, 05 May 2009 08:44:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=tjDZhkYEj98H9BQlvGyHvL6Nxr/m7c3eQIsg6aGgyAI=; b=TcAlqLcbZP8VH5lvItmQpif0z5QPrbMlYqOPtZuSGS2IHbXz4SD6NQn2Dc8dRt2u4k f/QwQDVmIOYptXHrd1VkHTXNdUnAfC+t2tQ2km7JP96WlQ2wrIZeEEhjBlSlT7vTY3Dr a5IG1MY0MTPnF4iRLmu7KMmL9YKE1g31n8mE8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; b=oWwTFoi3uh7Gz4pOChP3DDQ5xAxEMi37TWH6nYcQLc3LP1JDegiGJ23aJ/3NPB+lsd d2+Qy9Qu60Kb0P/f+CLJAdihMZkPv3i2YvWr0lYSDqlt8cPx6USJhhyfebSVl3iczwi/ G8LGGHXFOLCDzCKjsdTcThbSTROgDLMbMy2d0= Received: by 10.86.4.7 with SMTP id 7mr263783fgd.46.1241538294585; Tue, 05 May 2009 08:44:54 -0700 (PDT) Received: from windows8d787f9 (bzq-82-81-64-209.red.bezeqint.net [82.81.64.209]) by mx.google.com with ESMTPS id l19sm8649655fgb.7.2009.05.05.08.44.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 05 May 2009 08:44:54 -0700 (PDT) From: "Roni Even" To: "'Ye-Kui Wang'" , "'Elwell, John'" , References: <49ff59e6.1358560a.4af5.05e3@mx.google.com> <089AD8684C5E4C2995F01C2527EE7081@china.huawei.com> <0D5F89FAC29E2C41B98A6A762007F5D001D8DC97@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: Date: Tue, 5 May 2009 18:43:02 +0300 Message-ID: <4a005ef6.1358560a.4934.ffffae26@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnM1Y81eH5hh4rORt+9cpb8aAHZ7wAESgPQAABHA9AABShl8AABbg4QABZuUcAADOPO8AAB/rCw Content-Language: en-us Subject: Re: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 15:43:31 -0000 YK, RFC3984bis did change the behavior concerning the level symmetry. We decided that the level can be downgraded because we thought as far as I remember that there was no reason to answer with higher level since the offerer said it cannot support higher level while lower level is implicit I can understand that it does not matter if the answer has higher level since the answerer will still need to send within the offered level but the offerer can send at higher level if it can. Roni -----Original Message----- From: Ye-Kui Wang [mailto:yekuiwang@huawei.com] Sent: Tuesday, May 05, 2009 5:47 PM To: 'Elwell, John'; 'Roni Even'; avt@ietf.org Subject: RE: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level John, Yes, your understanding is correct, I meant use of two m-lines. While that is not perfect, I believe changing this fundamental part in a non-backward-compatible way would be much worse, as I explained in the previous email. Making the change can only help to enable asymmetric video solutions more conveniently, but would basically disable communications between any legacy implementation of new implementations. In addition, there might be a technical reason, which I don't know, duing the development of RFC 3984 for the current specification of the level part. BR, YK > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Tuesday, May 05, 2009 4:47 AM > To: Ye-Kui Wang; Roni Even; avt@ietf.org > Subject: RE: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - > Profile level > > YK, > > If I understand correctly, you would have two m-lines, one > a=sendonly (on which a lower bandwidth is negotiated, say), > and one a=recvonly (on which a higher bandwidth is > negotiated, say)? This would really complicate things. For > example, I think you would need to assign two different > labels (a=label attribute), because I don't think the use of > the same label for two m-lines is defined. How would you > refer to them for floor control purposes? Also you would need > to convey two a=crypto lines for security descriptions if > using SRTP. It would also complicate NAT traversal, e.g., if > using ICE, I think you would need to treat them as two separate media. > > John > > > > -----Original Message----- > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > Behalf Of > > Ye-Kui Wang > > Sent: 04 May 2009 22:56 > > To: 'Roni Even'; avt@ietf.org > > Subject: Re: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile > > level > > > > Hi, > > > > The current design in the bis draft (as well as in in RFC > > 3984) does allow negotiation of asymmetric video solutions > using SDP > > offer/answer. What you need to do is just to separate the > sending part > > (a=sendonly) and the receiving part > > (=recvonly) in the SDP. Therefore, I don't think there is > any problem > > and any need for change in the regard. > > > > BR,YK > > > > > > ________________________________ > > > > From: avt-bounces@ietf.org > > [mailto:avt-bounces@ietf.org] On Behalf Of Roni Even > > Sent: Monday, May 04, 2009 5:09 PM > > To: avt@ietf.org > > Subject: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - > Profile level > > > > > > > > From: Ashish Goyal > > Sent: Tuesday, May 05, 2009 12:04 AM > > To: 'avt@ietf.org' > > Subject: draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level > > > > > > > > Hi, > > > > I am leading an effort of sip video vendors under > > the aegis of IMTC Sip video parity and working on a BCP > > document to enhance sip video interoperability. In our > > discussion today there were some concerns around the section > > 8.2.2 of 3984bis - specifically around the text > > > > > > > > "The level part of "profile-level-id" is > > downgradable, i.e. the answerer MUST maintain the same or a > > lower level or remove the media format (payload type) completely. " > > > > > > > > I am writing this mail in the hope that we can amend > > the 3984 bis so that we can consider it as a reference - > > rather than having a conflicting BCP document for video. > > > > > > > > The recommendation from the group was to > > > > 1) Consider level parameter as a declaration of > > receive capabilities and not let it imply the resolution used > > for transmit > > > > 2) Consider the level parameter as either > > upgradeable or downgradeable - since it's really talking > > about receive capability. The answerer must not transmit a > > level higher than the offer - but can provide an answer which > > contains a level higher than the offer. This would allow the > > offerer to transmit a higher level than it can receive - if > > it chooses to. > > > > > > > > Here is the issue that we are trying to address by > > having asymmetric support for level. > > > > > > > > One of the use cases which is well supported by some > > of the leading video implementers is support for asymmetric > > video resolutions. The use case where this becomes important > > is when the calls are made from a video softclient running > > on a pc. Because of asymmetric compute requirements on > > encode and decode - the video softclients would be able to > > typically decode much higher resolution - than they are able > > to encode. However section 8.2.2 makes this negotiation > difficult. > > > > > > > > Here is how the use case is expected to work. > > > > > > > > Assume the video device A is able to decode level 3.1 > > and encode only level 1.1 > > > > B is capable of both decoding and encoding level 3.1. > > > > A would quote a level of 3.1 in its offer > > > > B would respond with level 3.1 in the answer > > > > > > > > A would send to B video stream at level 1.1 - since A > > can only encode at level 1.1. > > > > B would send level 3.1 to A since A can decode upto level 3.1. > > > > > > > > > > > > Regards, > > > > Ashish > > > > > From ron.even.tlv@gmail.com Tue May 5 08:44:49 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A1DB3A6DA8 for ; Tue, 5 May 2009 08:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.486 X-Spam-Level: X-Spam-Status: No, score=-0.486 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_22=0.6, SARE_RECV_BEZEQINT_B=0.763] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U92FtVrKXmkZ for ; Tue, 5 May 2009 08:44:48 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by core3.amsl.com (Postfix) with ESMTP id A410A3A6CD6 for ; Tue, 5 May 2009 08:44:47 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 13so1602298fge.18 for ; Tue, 05 May 2009 08:46:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=sgK8uFk5/jTljU4BtXDp7DtkUZ2+tZ1ts/j8JGBqeKk=; b=bHKIDjdOWC4f3uyxBpp4uQRkKqXKWgKwrcSxRUha2NT8G6gznNXuAtWkkQ6++0KVkm j1ikuCr6XLRz8cKofEYeezNIQOgJPBRRRsjHzs34nN09MUbiR9T5EeIcOLVfwZzNqJMv Fn9YgP+MTMp2Y85dh0DsBTDgT7H2Bs++QKbII= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; b=gSrwcESYPAgG+/mHQF2Juwcr1QtXpYZqg4Vnm6cBSRTNnx6egUVzsOaZlLe3uYD/Bj YpLeX53JxRWyOTcbkmUMgh7b1PIkbrm8iUVY/UreRMnw3GUwGs01rZTXYwj2TTzIkTsE CFliQH4CENvF7nethwP7HtmgQoyF53Qr3Tqbk= Received: by 10.86.33.9 with SMTP id g9mr271256fgg.41.1241538371723; Tue, 05 May 2009 08:46:11 -0700 (PDT) Received: from windows8d787f9 (bzq-82-81-64-209.red.bezeqint.net [82.81.64.209]) by mx.google.com with ESMTPS id 4sm8612006fge.8.2009.05.05.08.46.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 05 May 2009 08:46:11 -0700 (PDT) From: "Roni Even" To: "'Jonathan Lennox'" , "'Elwell, John'" , "'Ye-Kui Wang'" , References: <49ff59e6.1358560a.4af5.05e3@mx.google.com><089AD8684C5E4C2995F01C2527EE7081@china.huawei.com> <0D5F89FAC29E2C41B98A6A762007F5D001D8DC97@GBNTHT12009MSX.gb002.siemens.net> <6B55710E7F51AD4B93F336052113B85F8C7F30@be150.mail.lan> In-Reply-To: <6B55710E7F51AD4B93F336052113B85F8C7F30@be150.mail.lan> Date: Tue, 5 May 2009 18:44:18 +0300 Message-ID: <4a005f43.0405560a.2a96.ffff83c3@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnM1Y81eH5hh4rORt+9cpb8aAHZ7wAESgPQAABHA9AABShl8AABbg4QABZuUcAAC7QXEAADYv0g Content-Language: en-us Subject: Re: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 15:44:49 -0000 Jonathan, I think that only the level can be downgraded not the profile Roni -----Original Message----- From: Jonathan Lennox [mailto:jonathan@vidyo.com] Sent: Tuesday, May 05, 2009 5:19 PM To: Elwell, John; Ye-Kui Wang; Roni Even; avt@ietf.org Subject: RE: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level I agree with John's analysis of Ye-Kui's statement -- trying to do asymmetric media using separate m= lines isn't very practical for a number of reasons. That said, though I think it would be cleaner to have purely receive-only semantics for profile-level-id, I have trouble imagining situations for which the current specification is problematic. The profile-level-id parameter only gives an upper bound on what the bitstream can contain; it's always valid to send a bitstream that uses a lower (more constrained) profile and level than what was negotiated. Thus, I don't see a problem unless an endpoint wants to encode using a *higher* profile or level than it's able to decode. I suppose this could happen for pre-encoded video, hardware-assisted encoding, or the like, but it certainly seems like a more unusual case for bi-directional media. -- Jonathan Lennox Vidyo, Inc jonathan@vidyo.com > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Tuesday, May 05, 2009 4:47 AM > To: Ye-Kui Wang; Roni Even; avt@ietf.org > Subject: Re: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level > > YK, > > If I understand correctly, you would have two m-lines, one a=sendonly > (on which a lower bandwidth is negotiated, say), and one a=recvonly (on > which a higher bandwidth is negotiated, say)? This would really > complicate things. For example, I think you would need to assign two > different labels (a=label attribute), because I don't think the use of > the same label for two m-lines is defined. How would you refer to them > for floor control purposes? Also you would need to convey two a=crypto > lines for security descriptions if using SRTP. It would also complicate > NAT traversal, e.g., if using ICE, I think you would need to treat them > as two separate media. > > John > > > > -----Original Message----- > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > > Behalf Of Ye-Kui Wang > > Sent: 04 May 2009 22:56 > > To: 'Roni Even'; avt@ietf.org > > Subject: Re: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - > > Profile level > > > > Hi, > > > > The current design in the bis draft (as well as in in RFC > > 3984) does allow negotiation of asymmetric video solutions > > using SDP offer/answer. What you need to do is just to > > separate the sending part (a=sendonly) and the receiving part > > (=recvonly) in the SDP. Therefore, I don't think there is any > > problem and any need for change in the regard. > > > > BR,YK > > > > > > ________________________________ > > > > From: avt-bounces@ietf.org > > [mailto:avt-bounces@ietf.org] On Behalf Of Roni Even > > Sent: Monday, May 04, 2009 5:09 PM > > To: avt@ietf.org > > Subject: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - > > Profile level > > > > > > > > From: Ashish Goyal > > Sent: Tuesday, May 05, 2009 12:04 AM > > To: 'avt@ietf.org' > > Subject: draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level > > > > > > > > Hi, > > > > I am leading an effort of sip video vendors under > > the aegis of IMTC Sip video parity and working on a BCP > > document to enhance sip video interoperability. In our > > discussion today there were some concerns around the section > > 8.2.2 of 3984bis - specifically around the text > > > > > > > > "The level part of "profile-level-id" is > > downgradable, i.e. the answerer MUST maintain the same or a > > lower level or remove the media format (payload type) completely. " > > > > > > > > I am writing this mail in the hope that we can amend > > the 3984 bis so that we can consider it as a reference - > > rather than having a conflicting BCP document for video. > > > > > > > > The recommendation from the group was to > > > > 1) Consider level parameter as a declaration of > > receive capabilities and not let it imply the resolution used > > for transmit > > > > 2) Consider the level parameter as either > > upgradeable or downgradeable - since it's really talking > > about receive capability. The answerer must not transmit a > > level higher than the offer - but can provide an answer which > > contains a level higher than the offer. This would allow the > > offerer to transmit a higher level than it can receive - if > > it chooses to. > > > > > > > > Here is the issue that we are trying to address by > > having asymmetric support for level. > > > > > > > > One of the use cases which is well supported by some > > of the leading video implementers is support for asymmetric > > video resolutions. The use case where this becomes important > > is when the calls are made from a video softclient running > > on a pc. Because of asymmetric compute requirements on > > encode and decode - the video softclients would be able to > > typically decode much higher resolution - than they are able > > to encode. However section 8.2.2 makes this negotiation difficult. > > > > > > > > Here is how the use case is expected to work. > > > > > > > > Assume the video device A is able to decode level 3.1 > > and encode only level 1.1 > > > > B is capable of both decoding and encoding level 3.1. > > > > A would quote a level of 3.1 in its offer > > > > B would respond with level 3.1 in the answer > > > > > > > > A would send to B video stream at level 1.1 - since A > > can only encode at level 1.1. > > > > B would send level 3.1 to A since A can decode upto level 3.1. > > > > > > > > > > > > Regards, > > > > Ashish > > > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From gherlein@herlein.com Tue May 5 08:55:29 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6CEF3A6C0E for ; Tue, 5 May 2009 08:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.363 X-Spam-Level: X-Spam-Status: No, score=-1.363 tagged_above=-999 required=5 tests=[AWL=0.613, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hlCpgOVA04Iz for ; Tue, 5 May 2009 08:55:28 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by core3.amsl.com (Postfix) with ESMTP id 7EAE23A68EC for ; Tue, 5 May 2009 08:55:28 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 29so3971290wff.31 for ; Tue, 05 May 2009 08:56:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.44.11 with SMTP id r11mr65340wfr.240.1241539006285; Tue, 05 May 2009 08:56:46 -0700 (PDT) In-Reply-To: References: <6D5990B2-9100-4AC8-89D3-BDEE27A002E5@apple.com> Date: Tue, 5 May 2009 08:56:46 -0700 Message-ID: <31d1be720905050856x1819d8f4wda97866f922043b0@mail.gmail.com> From: Greg Herlein To: http-live-streaming-review@group.apple.com, avt@ietf.org Content-Type: multipart/alternative; boundary=000e0cd311a271c7a004692c536d Subject: Re: [AVT] iPhone streaming Internet-Draft posted X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 15:55:29 -0000 --000e0cd311a271c7a004692c536d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I agree with Ross. I cannot see any reason at all to invent a new protocol. If you want to keep the media inside a TCP connection then just interleave it in the RTSP session. If you want to make something really useful then use RTP and support multicast. I personally want a handheld application that I can watch a streaming show sitting in the airport - not over the cellular connection necessarily but over a local hot spot. Hmmm, maybe I should write that for my new Blackberry Bold (whose H.264 decode seems beautiful). Inventing a new protocol - however cool it is - just creates less interoperability and more silo'd world. Perhaps there's a reason for a new protocol? Perhaps Apple could elaborate on what problem they are trying to solve? Greg On Tue, May 5, 2009 at 8:39 AM, Ross Finlayson wrote: > We appreciate feedback on the protocol. >> > > Rather than invent yet another protocol, why not just implement a RTSP/RTP > client on the iPhone instead? > > (If you *really* want to do this over HTTP (though ideally only when direct > RTSP/RTP connectivity is not available), you could use the > RTSP/RTP-over-HTTP hack that QuickTime Player already uses.) > > After all, there are plenty of people at Apple with expertise on this (but > I dunno, perhaps they work in some other group? :-) > -- > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > -- Greg Herlein www.herlein.com --000e0cd311a271c7a004692c536d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I agree with Ross.=A0=A0 I cannot see any reason at all to invent a new pro= tocol.=A0 If you want to keep the media inside a TCP connection then just i= nterleave it in the RTSP session.=A0 If you want to make something really u= seful then use RTP and support multicast.=A0 I personally want a handheld a= pplication that I can watch a streaming show sitting in the airport - not o= ver the cellular connection necessarily but over a local hot spot.=A0=A0 Hm= mm, maybe I should write that for my new Blackberry Bold (whose H.264 decod= e seems beautiful).

Inventing a new protocol - however cool it is - just creates less inter= operability and more silo'd world.=A0

Perhaps there's a rea= son for a new protocol?=A0 Perhaps Apple could elaborate on what problem th= ey are trying to solve?

Greg

On Tue, May 5, 2009 at 8:39 AM, = Ross Finlayson <finlayson@live555.com> wrote:
We appreciate feedback on the protocol.

Rather than invent yet another protocol, why not just implement a RTSP/RTP = client on the iPhone instead?

(If you *really* want to do this over HTTP (though ideally only when direct= RTSP/RTP connectivity is not available), you could use the RTSP/RTP-over-H= TTP hack that QuickTime Player already uses.)

After all, there are plenty of people at Apple with expertise on this (but = I dunno, perhaps they work in some other group? :-)
--

Ross Finlayson
Live Networks, Inc.
http://www.live555.co= m/

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/avt



--
Greg Herlei= n
www.herlein.com
--000e0cd311a271c7a004692c536d-- From yekuiwang@huawei.com Tue May 5 09:38:02 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EDFD3A67F5 for ; Tue, 5 May 2009 09:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.326 X-Spam-Level: X-Spam-Status: No, score=-1.326 tagged_above=-999 required=5 tests=[AWL=-0.527, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0jXFcuKEHsnv for ; Tue, 5 May 2009 09:38:01 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 71CCF3A6CBE for ; Tue, 5 May 2009 09:38:01 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJ6002LDJLRNC@usaga04-in.huawei.com> for avt@ietf.org; Tue, 05 May 2009 11:39:28 -0500 (CDT) Received: from W90946 ([10.193.125.102]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJ6001P1JLNM2@usaga04-in.huawei.com> for avt@ietf.org; Tue, 05 May 2009 11:39:27 -0500 (CDT) Date: Tue, 05 May 2009 12:39:22 -0400 From: Ye-Kui Wang In-reply-to: <4a005ef6.1358560a.4934.ffffae26@mx.google.com> To: 'Roni Even' , "'Elwell, John'" , avt@ietf.org Message-id: <0DB94A632EC341CA965EF492749980C1@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcnM1Y81eH5hh4rORt+9cpb8aAHZ7wAESgPQAABHA9AABShl8AABbg4QABZuUcAADOPO8AAB/rCwAAIBnRA= References: <49ff59e6.1358560a.4af5.05e3@mx.google.com> <089AD8684C5E4C2995F01C2527EE7081@china.huawei.com> <0D5F89FAC29E2C41B98A6A762007F5D001D8DC97@GBNTHT12009MSX.gb002.siemens.net> <4a005ef6.1358560a.4934.ffffae26@mx.google.com> Subject: Re: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 16:38:02 -0000 Roni, The issue here (asymmetry use of level, or more specificically spatial resolution, in sending and receiving) is different from level downgrade. The level downgrade concept is that the answerer can answer an offer SDP with a lower level, and then the lower level is what is agreed. While what was suggested, if I understand correctly, is to have no restriction on the indicated level in an answer, i.e. it can be equal, lower or higher than the indicated level in the offer. BR,YK > -----Original Message----- > From: Roni Even [mailto:ron.even.tlv@gmail.com] > Sent: Tuesday, May 05, 2009 11:43 AM > To: 'Ye-Kui Wang'; 'Elwell, John'; avt@ietf.org > Subject: RE: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - > Profile level > > YK, > RFC3984bis did change the behavior concerning the level > symmetry. We decided that the level can be downgraded because > we thought as far as I remember that there was no reason to > answer with higher level since the offerer said it cannot > support higher level while lower level is implicit I can > understand that it does not matter if the answer has higher > level since the answerer will still need to send within the > offered level but the offerer can send at higher level if it can. > > Roni > > -----Original Message----- > From: Ye-Kui Wang [mailto:yekuiwang@huawei.com] > Sent: Tuesday, May 05, 2009 5:47 PM > To: 'Elwell, John'; 'Roni Even'; avt@ietf.org > Subject: RE: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - > Profile level > > > John, > > Yes, your understanding is correct, I meant use of two > m-lines. While that > is not perfect, I believe changing this fundamental part in a > non-backward-compatible way would be much worse, as I explained in the > previous email. Making the change can only help to enable > asymmetric video > solutions more conveniently, but would basically disable > communications > between any legacy implementation of new implementations. In > addition, there > might be a technical reason, which I don't know, duing the > development of > RFC 3984 for the current specification of the level part. > > BR, YK > > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Tuesday, May 05, 2009 4:47 AM > > To: Ye-Kui Wang; Roni Even; avt@ietf.org > > Subject: RE: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - > > Profile level > > > > YK, > > > > If I understand correctly, you would have two m-lines, one > > a=sendonly (on which a lower bandwidth is negotiated, say), > > and one a=recvonly (on which a higher bandwidth is > > negotiated, say)? This would really complicate things. For > > example, I think you would need to assign two different > > labels (a=label attribute), because I don't think the use of > > the same label for two m-lines is defined. How would you > > refer to them for floor control purposes? Also you would need > > to convey two a=crypto lines for security descriptions if > > using SRTP. It would also complicate NAT traversal, e.g., if > > using ICE, I think you would need to treat them as two > separate media. > > > > John > > > > > > > -----Original Message----- > > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > > Behalf Of > > > Ye-Kui Wang > > > Sent: 04 May 2009 22:56 > > > To: 'Roni Even'; avt@ietf.org > > > Subject: Re: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile > > > level > > > > > > Hi, > > > > > > The current design in the bis draft (as well as in in RFC > > > 3984) does allow negotiation of asymmetric video solutions > > using SDP > > > offer/answer. What you need to do is just to separate the > > sending part > > > (a=sendonly) and the receiving part > > > (=recvonly) in the SDP. Therefore, I don't think there is > > any problem > > > and any need for change in the regard. > > > > > > BR,YK > > > > > > > > > ________________________________ > > > > > > From: avt-bounces@ietf.org > > > [mailto:avt-bounces@ietf.org] On Behalf Of Roni Even > > > Sent: Monday, May 04, 2009 5:09 PM > > > To: avt@ietf.org > > > Subject: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - > > Profile level > > > > > > > > > > > > From: Ashish Goyal > > > Sent: Tuesday, May 05, 2009 12:04 AM > > > To: 'avt@ietf.org' > > > Subject: draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level > > > > > > > > > > > > Hi, > > > > > > I am leading an effort of sip video vendors under > > > the aegis of IMTC Sip video parity and working on a BCP > > > document to enhance sip video interoperability. In our > > > discussion today there were some concerns around the section > > > 8.2.2 of 3984bis - specifically around the text > > > > > > > > > > > > "The level part of "profile-level-id" is > > > downgradable, i.e. the answerer MUST maintain the same or a > > > lower level or remove the media format (payload type) > completely. " > > > > > > > > > > > > I am writing this mail in the hope that we can amend > > > the 3984 bis so that we can consider it as a reference - > > > rather than having a conflicting BCP document for video. > > > > > > > > > > > > The recommendation from the group was to > > > > > > 1) Consider level parameter as a declaration of > > > receive capabilities and not let it imply the resolution used > > > for transmit > > > > > > 2) Consider the level parameter as either > > > upgradeable or downgradeable - since it's really talking > > > about receive capability. The answerer must not transmit a > > > level higher than the offer - but can provide an answer which > > > contains a level higher than the offer. This would allow the > > > offerer to transmit a higher level than it can receive - if > > > it chooses to. > > > > > > > > > > > > Here is the issue that we are trying to address by > > > having asymmetric support for level. > > > > > > > > > > > > One of the use cases which is well supported by some > > > of the leading video implementers is support for asymmetric > > > video resolutions. The use case where this becomes important > > > is when the calls are made from a video softclient running > > > on a pc. Because of asymmetric compute requirements on > > > encode and decode - the video softclients would be able to > > > typically decode much higher resolution - than they are able > > > to encode. However section 8.2.2 makes this negotiation > > difficult. > > > > > > > > > > > > Here is how the use case is expected to work. > > > > > > > > > > > > Assume the video device A is able to decode level 3.1 > > > and encode only level 1.1 > > > > > > B is capable of both decoding and encoding level 3.1. > > > > > > A would quote a level of 3.1 in its offer > > > > > > B would respond with level 3.1 in the answer > > > > > > > > > > > > A would send to B video stream at level 1.1 - since A > > > can only encode at level 1.1. > > > > > > B would send level 3.1 to A since A can decode upto level 3.1. > > > > > > > > > > > > > > > > > > Regards, > > > > > > Ashish > > > > > > > > > > > From alex.giladi@gmail.com Tue May 5 09:57:12 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 892723A6A3D for ; Tue, 5 May 2009 09:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.152 X-Spam-Level: X-Spam-Status: No, score=-2.152 tagged_above=-999 required=5 tests=[AWL=0.447, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ShoCY9RxYNQ2 for ; Tue, 5 May 2009 09:57:11 -0700 (PDT) Received: from mail-bw0-f174.google.com (mail-bw0-f174.google.com [209.85.218.174]) by core3.amsl.com (Postfix) with ESMTP id 3488A3A672F for ; Tue, 5 May 2009 09:57:10 -0700 (PDT) Received: by bwz22 with SMTP id 22so1440000bwz.37 for ; Tue, 05 May 2009 09:58:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=xYe4ryKOmi9hMRUko1AaXFwxtLO7zyDSJh+oHNTBVNw=; b=FeN0mHYOo+Aj6l3pjufoCU+UGxXpk3IliD62hfb6u3tuOTZ/Cf2zLlpc0HikJNFxpb SrwAVhwStENbhUaFnuIhU2DlAqSOT518dDx6rd9hTBOD9CH3mra1UjMm+KNJ7PDfizoa Ah9y7luo/9rYwm8YoUGrX1Zfee3H9A9e4Km/g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=EvhZj3aH52c/BW7al/kwO7vAuRxDr2giHI2lJlEVEtSJeqG8fwT0k/Z6jc1BPnxzwR jTb6jv5B0O9FOvQQ0XZd5o4t5aif7W4XByeUisOKU6em+/LVaMmm7ibb7/3GO1A2AGXt IaobW0VpvFJns4PtzBlCOKaBhZyGLzEFPqqFc= MIME-Version: 1.0 Received: by 10.103.107.1 with SMTP id j1mr234903mum.30.1241542715098; Tue, 05 May 2009 09:58:35 -0700 (PDT) In-Reply-To: <31d1be720905050856x1819d8f4wda97866f922043b0@mail.gmail.com> References: <6D5990B2-9100-4AC8-89D3-BDEE27A002E5@apple.com> <31d1be720905050856x1819d8f4wda97866f922043b0@mail.gmail.com> Date: Tue, 5 May 2009 10:58:35 -0600 Message-ID: <57a9e15d0905050958p210db525qb058fd62d6ea7073@mail.gmail.com> From: Alex Giladi To: Greg Herlein Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: http-live-streaming-review@group.apple.com, avt@ietf.org Subject: Re: [AVT] iPhone streaming Internet-Draft posted X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 16:57:12 -0000 Greg, It's not entirely clear to me, but it looks from #4 that they are looking at progressive download of segments vs. 'real' streaming. I suppose one can do this with RTSP using PLAY request with closed time ranges. One problem that may happen with RTSP is that there may be overzealous firewalls that blocks RTSP, but not HTTP. Alex. On Tue, May 5, 2009 at 9:56 AM, Greg Herlein wrote: > I agree with Ross.=C2=A0=C2=A0 I cannot see any reason at all to invent a= new > protocol.=C2=A0 If you want to keep the media inside a TCP connection the= n just > interleave it in the RTSP session.=C2=A0 If you want to make something re= ally > useful then use RTP and support multicast.=C2=A0 I personally want a hand= held > application that I can watch a streaming show sitting in the airport - no= t > over the cellular connection necessarily but over a local hot spot.=C2=A0= =C2=A0 Hmmm, > maybe I should write that for my new Blackberry Bold (whose H.264 decode > seems beautiful). > > Inventing a new protocol - however cool it is - just creates less > interoperability and more silo'd world. > > Perhaps there's a reason for a new protocol?=C2=A0 Perhaps Apple could el= aborate > on what problem they are trying to solve? > > Greg > > On Tue, May 5, 2009 at 8:39 AM, Ross Finlayson > wrote: >>> >>> We appreciate feedback on the protocol. >> >> Rather than invent yet another protocol, why not just implement a RTSP/R= TP >> client on the iPhone instead? >> >> (If you *really* want to do this over HTTP (though ideally only when >> direct RTSP/RTP connectivity is not available), you could use the >> RTSP/RTP-over-HTTP hack that QuickTime Player already uses.) >> >> After all, there are plenty of people at Apple with expertise on this (b= ut >> I dunno, perhaps they work in some other group? :-) >> -- >> >> Ross Finlayson >> Live Networks, Inc. >> http://www.live555.com/ >> _______________________________________________ >> Audio/Video Transport Working Group >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt > > > > -- > Greg Herlein > www.herlein.com > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > > From ron.even.tlv@gmail.com Tue May 5 10:05:25 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 720BC3A6899 for ; Tue, 5 May 2009 10:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.336 X-Spam-Level: X-Spam-Status: No, score=-0.336 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_22=0.6, SARE_RECV_BEZEQINT_B=0.763] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHGewfadWHIZ for ; Tue, 5 May 2009 10:05:24 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by core3.amsl.com (Postfix) with ESMTP id E2F903A6DD2 for ; Tue, 5 May 2009 10:05:23 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 13so1622371fge.18 for ; Tue, 05 May 2009 10:06:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=D/HRhy6JlRfWgNWTdbeGRSUHu04DJp69ldyIK6/jSu8=; b=xzi52YkX6od9ghuW9iTjjB1En21K7gEWTekQj4Ry372nF/KCvXZgAg6MjQsqJbrodA L1H9Yx7TE7XuIAfu4lQGSsWyXXNNTIHuTUCWvcj9bzIW2Xzd8qtA1pdB+qgUxXil4U9R PI684SYvAHXZBVFQDB+tBe88plW4qvqRqUIfk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; b=LOn5f/fnkBsbe3jjd/R9BWiIJ1cfyEzOt86D7smdKuov/7W7I2si5woCbvTRi+KncT Q3tHXUmbMfOCMuWM/WTXJrYguC3TaggDqAkucNQtC6hsiWoL6MvpQ+9UyfggAn4bHoql PF2Y3e7VchT97/znYJvgT4vp/3BE4FypJF4iE= Received: by 10.86.25.10 with SMTP id 10mr333931fgy.79.1241543207730; Tue, 05 May 2009 10:06:47 -0700 (PDT) Received: from windows8d787f9 (bzq-82-81-64-209.red.bezeqint.net [82.81.64.209]) by mx.google.com with ESMTPS id e20sm8762524fga.15.2009.05.05.10.06.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 05 May 2009 10:06:47 -0700 (PDT) From: "Roni Even" To: "'Ye-Kui Wang'" , "'Elwell, John'" , References: <49ff59e6.1358560a.4af5.05e3@mx.google.com> <089AD8684C5E4C2995F01C2527EE7081@china.huawei.com> <0D5F89FAC29E2C41B98A6A762007F5D001D8DC97@GBNTHT12009MSX.gb002.siemens.net> <4a005ef6.1358560a.4934.ffffae26@mx.google.com> <0DB94A632EC341CA965EF492749980C1@china.huawei.com> In-Reply-To: <0DB94A632EC341CA965EF492749980C1@china.huawei.com> Date: Tue, 5 May 2009 20:04:43 +0300 Message-ID: <4a007227.1438560a.1123.ffffef61@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnM1Y81eH5hh4rORt+9cpb8aAHZ7wAESgPQAABHA9AABShl8AABbg4QABZuUcAADOPO8AAB/rCwAAIBnRAAAPHpEA== Content-Language: en-us Subject: Re: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 17:05:25 -0000 YK, This is also what I understand and my comment was saying that I am not sure why we have only downgrade in the answer in 3984bis. The downgrade option was added in 3984bis, in rfc3984 you had to have the same level in the answer. Roni -----Original Message----- From: Ye-Kui Wang [mailto:yekuiwang@huawei.com] Sent: Tuesday, May 05, 2009 7:39 PM To: 'Roni Even'; 'Elwell, John'; avt@ietf.org Subject: RE: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level Roni, The issue here (asymmetry use of level, or more specificically spatial resolution, in sending and receiving) is different from level downgrade. The level downgrade concept is that the answerer can answer an offer SDP with a lower level, and then the lower level is what is agreed. While what was suggested, if I understand correctly, is to have no restriction on the indicated level in an answer, i.e. it can be equal, lower or higher than the indicated level in the offer. BR,YK > -----Original Message----- > From: Roni Even [mailto:ron.even.tlv@gmail.com] > Sent: Tuesday, May 05, 2009 11:43 AM > To: 'Ye-Kui Wang'; 'Elwell, John'; avt@ietf.org > Subject: RE: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - > Profile level > > YK, > RFC3984bis did change the behavior concerning the level > symmetry. We decided that the level can be downgraded because > we thought as far as I remember that there was no reason to > answer with higher level since the offerer said it cannot > support higher level while lower level is implicit I can > understand that it does not matter if the answer has higher > level since the answerer will still need to send within the > offered level but the offerer can send at higher level if it can. > > Roni > > -----Original Message----- > From: Ye-Kui Wang [mailto:yekuiwang@huawei.com] > Sent: Tuesday, May 05, 2009 5:47 PM > To: 'Elwell, John'; 'Roni Even'; avt@ietf.org > Subject: RE: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - > Profile level > > > John, > > Yes, your understanding is correct, I meant use of two > m-lines. While that > is not perfect, I believe changing this fundamental part in a > non-backward-compatible way would be much worse, as I explained in the > previous email. Making the change can only help to enable > asymmetric video > solutions more conveniently, but would basically disable > communications > between any legacy implementation of new implementations. In > addition, there > might be a technical reason, which I don't know, duing the > development of > RFC 3984 for the current specification of the level part. > > BR, YK > > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Tuesday, May 05, 2009 4:47 AM > > To: Ye-Kui Wang; Roni Even; avt@ietf.org > > Subject: RE: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - > > Profile level > > > > YK, > > > > If I understand correctly, you would have two m-lines, one > > a=sendonly (on which a lower bandwidth is negotiated, say), > > and one a=recvonly (on which a higher bandwidth is > > negotiated, say)? This would really complicate things. For > > example, I think you would need to assign two different > > labels (a=label attribute), because I don't think the use of > > the same label for two m-lines is defined. How would you > > refer to them for floor control purposes? Also you would need > > to convey two a=crypto lines for security descriptions if > > using SRTP. It would also complicate NAT traversal, e.g., if > > using ICE, I think you would need to treat them as two > separate media. > > > > John > > > > > > > -----Original Message----- > > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > > Behalf Of > > > Ye-Kui Wang > > > Sent: 04 May 2009 22:56 > > > To: 'Roni Even'; avt@ietf.org > > > Subject: Re: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile > > > level > > > > > > Hi, > > > > > > The current design in the bis draft (as well as in in RFC > > > 3984) does allow negotiation of asymmetric video solutions > > using SDP > > > offer/answer. What you need to do is just to separate the > > sending part > > > (a=sendonly) and the receiving part > > > (=recvonly) in the SDP. Therefore, I don't think there is > > any problem > > > and any need for change in the regard. > > > > > > BR,YK > > > > > > > > > ________________________________ > > > > > > From: avt-bounces@ietf.org > > > [mailto:avt-bounces@ietf.org] On Behalf Of Roni Even > > > Sent: Monday, May 04, 2009 5:09 PM > > > To: avt@ietf.org > > > Subject: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - > > Profile level > > > > > > > > > > > > From: Ashish Goyal > > > Sent: Tuesday, May 05, 2009 12:04 AM > > > To: 'avt@ietf.org' > > > Subject: draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level > > > > > > > > > > > > Hi, > > > > > > I am leading an effort of sip video vendors under > > > the aegis of IMTC Sip video parity and working on a BCP > > > document to enhance sip video interoperability. In our > > > discussion today there were some concerns around the section > > > 8.2.2 of 3984bis - specifically around the text > > > > > > > > > > > > "The level part of "profile-level-id" is > > > downgradable, i.e. the answerer MUST maintain the same or a > > > lower level or remove the media format (payload type) > completely. " > > > > > > > > > > > > I am writing this mail in the hope that we can amend > > > the 3984 bis so that we can consider it as a reference - > > > rather than having a conflicting BCP document for video. > > > > > > > > > > > > The recommendation from the group was to > > > > > > 1) Consider level parameter as a declaration of > > > receive capabilities and not let it imply the resolution used > > > for transmit > > > > > > 2) Consider the level parameter as either > > > upgradeable or downgradeable - since it's really talking > > > about receive capability. The answerer must not transmit a > > > level higher than the offer - but can provide an answer which > > > contains a level higher than the offer. This would allow the > > > offerer to transmit a higher level than it can receive - if > > > it chooses to. > > > > > > > > > > > > Here is the issue that we are trying to address by > > > having asymmetric support for level. > > > > > > > > > > > > One of the use cases which is well supported by some > > > of the leading video implementers is support for asymmetric > > > video resolutions. The use case where this becomes important > > > is when the calls are made from a video softclient running > > > on a pc. Because of asymmetric compute requirements on > > > encode and decode - the video softclients would be able to > > > typically decode much higher resolution - than they are able > > > to encode. However section 8.2.2 makes this negotiation > > difficult. > > > > > > > > > > > > Here is how the use case is expected to work. > > > > > > > > > > > > Assume the video device A is able to decode level 3.1 > > > and encode only level 1.1 > > > > > > B is capable of both decoding and encoding level 3.1. > > > > > > A would quote a level of 3.1 in its offer > > > > > > B would respond with level 3.1 in the answer > > > > > > > > > > > > A would send to B video stream at level 1.1 - since A > > > can only encode at level 1.1. > > > > > > B would send level 3.1 to A since A can decode upto level 3.1. > > > > > > > > > > > > > > > > > > Regards, > > > > > > Ashish > > > > > > > > > > > From yekuiwang@huawei.com Tue May 5 11:42:41 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 257373A6DF8 for ; Tue, 5 May 2009 11:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWBCi5NnWx0V for ; Tue, 5 May 2009 11:42:40 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id F21C33A6A50 for ; Tue, 5 May 2009 11:42:39 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJ6004IHPDITF@usaga04-in.huawei.com> for avt@ietf.org; Tue, 05 May 2009 13:44:06 -0500 (CDT) Received: from W90946 ([10.193.125.102]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJ6001G0PDC89@usaga04-in.huawei.com> for avt@ietf.org; Tue, 05 May 2009 13:44:06 -0500 (CDT) Date: Tue, 05 May 2009 14:44:00 -0400 From: Ye-Kui Wang In-reply-to: <4a007227.1438560a.1123.ffffef61@mx.google.com> To: 'Roni Even' , "'Elwell, John'" , avt@ietf.org Message-id: <89DD91D94A684E29A915B2F9E243EE70@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcnM1Y81eH5hh4rORt+9cpb8aAHZ7wAESgPQAABHA9AABShl8AABbg4QABZuUcAADOPO8AAB/rCwAAIBnRAAAPHpEAADe+4Q References: <49ff59e6.1358560a.4af5.05e3@mx.google.com> <089AD8684C5E4C2995F01C2527EE7081@china.huawei.com> <0D5F89FAC29E2C41B98A6A762007F5D001D8DC97@GBNTHT12009MSX.gb002.siemens.net> <4a005ef6.1358560a.4934.ffffae26@mx.google.com> <0DB94A632EC341CA965EF492749980C1@china.huawei.com> <4a007227.1438560a.1123.ffffef61@mx.google.com> Subject: Re: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 18:42:41 -0000 Roni, My understanding is that in RFC 3984 the intention was to allow for level downgrade in SDP offer/answer, but there is some inconsistence in that regard and the bis draft clarified the issue. BR, YK > -----Original Message----- > From: Roni Even [mailto:ron.even.tlv@gmail.com] > Sent: Tuesday, May 05, 2009 1:05 PM > To: 'Ye-Kui Wang'; 'Elwell, John'; avt@ietf.org > Subject: RE: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - > Profile level > > YK, > This is also what I understand and my comment was saying that > I am not sure why we have only downgrade in the answer in > 3984bis. The downgrade option was added in 3984bis, in > rfc3984 you had to have the same level in the answer. > Roni > > -----Original Message----- > From: Ye-Kui Wang [mailto:yekuiwang@huawei.com] > Sent: Tuesday, May 05, 2009 7:39 PM > To: 'Roni Even'; 'Elwell, John'; avt@ietf.org > Subject: RE: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - > Profile level > > > Roni, > > The issue here (asymmetry use of level, or more specificically spatial > resolution, in sending and receiving) is different from level > downgrade. The > level downgrade concept is that the answerer can answer an > offer SDP with a > lower level, and then the lower level is what is agreed. > While what was > suggested, if I understand correctly, is to have no restriction on the > indicated level in an answer, i.e. it can be equal, lower or > higher than the > indicated level in the offer. > > BR,YK > > > -----Original Message----- > > From: Roni Even [mailto:ron.even.tlv@gmail.com] > > Sent: Tuesday, May 05, 2009 11:43 AM > > To: 'Ye-Kui Wang'; 'Elwell, John'; avt@ietf.org > > Subject: RE: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - > > Profile level > > > > YK, > > RFC3984bis did change the behavior concerning the level > > symmetry. We decided that the level can be downgraded because > > we thought as far as I remember that there was no reason to > > answer with higher level since the offerer said it cannot > > support higher level while lower level is implicit I can > > understand that it does not matter if the answer has higher > > level since the answerer will still need to send within the > > offered level but the offerer can send at higher level if it can. > > > > Roni > > > > -----Original Message----- > > From: Ye-Kui Wang [mailto:yekuiwang@huawei.com] > > Sent: Tuesday, May 05, 2009 5:47 PM > > To: 'Elwell, John'; 'Roni Even'; avt@ietf.org > > Subject: RE: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - > > Profile level > > > > > > John, > > > > Yes, your understanding is correct, I meant use of two > > m-lines. While that > > is not perfect, I believe changing this fundamental part in a > > non-backward-compatible way would be much worse, as I > explained in the > > previous email. Making the change can only help to enable > > asymmetric video > > solutions more conveniently, but would basically disable > > communications > > between any legacy implementation of new implementations. In > > addition, there > > might be a technical reason, which I don't know, duing the > > development of > > RFC 3984 for the current specification of the level part. > > > > BR, YK > > > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > Sent: Tuesday, May 05, 2009 4:47 AM > > > To: Ye-Kui Wang; Roni Even; avt@ietf.org > > > Subject: RE: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - > > > Profile level > > > > > > YK, > > > > > > If I understand correctly, you would have two m-lines, one > > > a=sendonly (on which a lower bandwidth is negotiated, say), > > > and one a=recvonly (on which a higher bandwidth is > > > negotiated, say)? This would really complicate things. For > > > example, I think you would need to assign two different > > > labels (a=label attribute), because I don't think the use of > > > the same label for two m-lines is defined. How would you > > > refer to them for floor control purposes? Also you would need > > > to convey two a=crypto lines for security descriptions if > > > using SRTP. It would also complicate NAT traversal, e.g., if > > > using ICE, I think you would need to treat them as two > > separate media. > > > > > > John > > > > > > > > > > -----Original Message----- > > > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > > > Behalf Of > > > > Ye-Kui Wang > > > > Sent: 04 May 2009 22:56 > > > > To: 'Roni Even'; avt@ietf.org > > > > Subject: Re: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt > - Profile > > > > level > > > > > > > > Hi, > > > > > > > > The current design in the bis draft (as well as in in RFC > > > > 3984) does allow negotiation of asymmetric video solutions > > > using SDP > > > > offer/answer. What you need to do is just to separate the > > > sending part > > > > (a=sendonly) and the receiving part > > > > (=recvonly) in the SDP. Therefore, I don't think there is > > > any problem > > > > and any need for change in the regard. > > > > > > > > BR,YK > > > > > > > > > > > > ________________________________ > > > > > > > > From: avt-bounces@ietf.org > > > > [mailto:avt-bounces@ietf.org] On Behalf Of Roni Even > > > > Sent: Monday, May 04, 2009 5:09 PM > > > > To: avt@ietf.org > > > > Subject: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - > > > Profile level > > > > > > > > > > > > > > > > From: Ashish Goyal > > > > Sent: Tuesday, May 05, 2009 12:04 AM > > > > To: 'avt@ietf.org' > > > > Subject: draft-ietf-avt-rtp-rfc3984bis-06.txt - > Profile level > > > > > > > > > > > > > > > > Hi, > > > > > > > > I am leading an effort of sip video vendors under > > > > the aegis of IMTC Sip video parity and working on a BCP > > > > document to enhance sip video interoperability. In our > > > > discussion today there were some concerns around the section > > > > 8.2.2 of 3984bis - specifically around the text > > > > > > > > > > > > > > > > "The level part of "profile-level-id" is > > > > downgradable, i.e. the answerer MUST maintain the same or a > > > > lower level or remove the media format (payload type) > > completely. " > > > > > > > > > > > > > > > > I am writing this mail in the hope that we can amend > > > > the 3984 bis so that we can consider it as a reference - > > > > rather than having a conflicting BCP document for video. > > > > > > > > > > > > > > > > The recommendation from the group was to > > > > > > > > 1) Consider level parameter as a declaration of > > > > receive capabilities and not let it imply the resolution used > > > > for transmit > > > > > > > > 2) Consider the level parameter as either > > > > upgradeable or downgradeable - since it's really talking > > > > about receive capability. The answerer must not transmit a > > > > level higher than the offer - but can provide an answer which > > > > contains a level higher than the offer. This would allow the > > > > offerer to transmit a higher level than it can receive - if > > > > it chooses to. > > > > > > > > > > > > > > > > Here is the issue that we are trying to address by > > > > having asymmetric support for level. > > > > > > > > > > > > > > > > One of the use cases which is well supported by some > > > > of the leading video implementers is support for asymmetric > > > > video resolutions. The use case where this becomes important > > > > is when the calls are made from a video softclient running > > > > on a pc. Because of asymmetric compute requirements on > > > > encode and decode - the video softclients would be able to > > > > typically decode much higher resolution - than they are able > > > > to encode. However section 8.2.2 makes this negotiation > > > difficult. > > > > > > > > > > > > > > > > Here is how the use case is expected to work. > > > > > > > > > > > > > > > > Assume the video device A is able to decode level 3.1 > > > > and encode only level 1.1 > > > > > > > > B is capable of both decoding and encoding level 3.1. > > > > > > > > A would quote a level of 3.1 in its offer > > > > > > > > B would respond with level 3.1 in the answer > > > > > > > > > > > > > > > > A would send to B video stream at level 1.1 - since A > > > > can only encode at level 1.1. > > > > > > > > B would send level 3.1 to A since A can > decode upto level 3.1. > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > Ashish > > > > > > > > > > > > > > > > > > > > From 2mkristensen@gmail.com Tue May 5 12:51:43 2009 Return-Path: <2mkristensen@gmail.com> X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CE2F3A683E for ; Tue, 5 May 2009 12:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Paw5Z6IOpR6p for ; Tue, 5 May 2009 12:51:41 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 401E83A65A6 for ; Tue, 5 May 2009 12:51:27 -0700 (PDT) Received: by fxm2 with SMTP id 2so4932276fxm.37 for ; Tue, 05 May 2009 12:52:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=iGWi+RNhVpUgxlUSoYCd3tHN8P36Q3TV9xW3LK7uioQ=; b=wC4PmUqv3/mWZoLlvk9jSqrHnU683GkDr7Z+VbmE1Ub/+HxYnih4tS2XG5dG1zpyQs T1Ilfrp00FniUwesgMFOM2qWJerIuw1gRzuVz+GZ3mgXUQNE6WEOSm/rKF9jPRo7OBwi E1W7l0DOAsvrHb5tzjLDC9JbYlsZrdGwIwPm8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Hds/K4kbg7DVZrzeWvfd1aMp+l3xjPBMG8IygdewbTrgtz6DDxjchMbGYdtdhUygAh tVqsBDAYMjuhcZdiNG/EOoeJSV1ZQQoaemmec/RVmQfdpIdef2wp76JSdUtJxfqih/7x a4n4OWZr3CmZMAscfSHxm+5GpwqKsKPACmono= MIME-Version: 1.0 Received: by 10.223.111.71 with SMTP id r7mr98358fap.59.1241553172182; Tue, 05 May 2009 12:52:52 -0700 (PDT) In-Reply-To: <89DD91D94A684E29A915B2F9E243EE70@china.huawei.com> References: <49ff59e6.1358560a.4af5.05e3@mx.google.com> <089AD8684C5E4C2995F01C2527EE7081@china.huawei.com> <0D5F89FAC29E2C41B98A6A762007F5D001D8DC97@GBNTHT12009MSX.gb002.siemens.net> <4a005ef6.1358560a.4934.ffffae26@mx.google.com> <0DB94A632EC341CA965EF492749980C1@china.huawei.com> <4a007227.1438560a.1123.ffffef61@mx.google.com> <89DD91D94A684E29A915B2F9E243EE70@china.huawei.com> Date: Tue, 5 May 2009 21:52:52 +0200 Message-ID: <7e4b541c0905051252u53ab7198pf7a810052bd8eb27@mail.gmail.com> From: Tom Kristensen <2mkristensen@gmail.com> To: Ye-Kui Wang Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: avt@ietf.org Subject: Re: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 19:51:43 -0000 Yes, existing RFC3984 implementations did already implement a policy allowing level downgrade when building the answer. The bis draft formalizes this behaviour. The profile part had to be kept fixed back then, now and for all future. However, as the level specify receive capabilities and are downgradable I understand the request and wish to upgrade the level - i.e. indicate a "better" ability to decode the stream in the answer than specified by the peer in the offer. Using separate media line with sendonly and recvonly direction attributes is not a good solution at all. -- Tom 2009/5/5 Ye-Kui Wang : > > Roni, > > My understanding is that in RFC 3984 the intention was to allow for level > downgrade in SDP offer/answer, but there is some inconsistence in that > regard and the bis draft clarified the issue. > > BR, YK > >> -----Original Message----- >> From: Roni Even [mailto:ron.even.tlv@gmail.com] >> Sent: Tuesday, May 05, 2009 1:05 PM >> To: 'Ye-Kui Wang'; 'Elwell, John'; avt@ietf.org >> Subject: RE: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - >> Profile level >> >> YK, >> This is also what I understand and my comment was saying that >> I am not sure why we have only downgrade in the answer in >> 3984bis. The downgrade option was added in 3984bis, in >> rfc3984 you had to have the same level in the answer. >> Roni >> >> -----Original Message----- >> From: Ye-Kui Wang [mailto:yekuiwang@huawei.com] >> Sent: Tuesday, May 05, 2009 7:39 PM >> To: 'Roni Even'; 'Elwell, John'; avt@ietf.org >> Subject: RE: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - >> Profile level >> >> >> Roni, >> >> The issue here (asymmetry use of level, or more specificically spatial >> resolution, in sending and receiving) is different from level >> downgrade. The >> level downgrade concept is that the answerer can answer an >> offer SDP with a >> lower level, and then the lower level is what is agreed. >> While what was >> suggested, if I understand correctly, is to have no restriction on the >> indicated level in an answer, i.e. it can be equal, lower or >> higher than the >> indicated level in the offer. >> >> BR,YK >> >> > -----Original Message----- >> > From: Roni Even [mailto:ron.even.tlv@gmail.com] >> > Sent: Tuesday, May 05, 2009 11:43 AM >> > To: 'Ye-Kui Wang'; 'Elwell, John'; avt@ietf.org >> > Subject: RE: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - >> > Profile level >> > >> > YK, >> > RFC3984bis did change the behavior concerning the level >> > symmetry. We decided that the level can be downgraded because >> > we thought as far as I remember that there was no reason to >> > answer with higher level since the offerer said it cannot >> > support higher level while lower level is implicit I can >> > understand that it does not matter if the answer has higher >> > level since the answerer will still need to send within the >> > offered level but the offerer can send at higher level if it can. >> > >> > Roni >> > >> > -----Original Message----- >> > From: Ye-Kui Wang [mailto:yekuiwang@huawei.com] >> > Sent: Tuesday, May 05, 2009 5:47 PM >> > To: 'Elwell, John'; 'Roni Even'; avt@ietf.org >> > Subject: RE: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - >> > Profile level >> > >> > >> > John, >> > >> > Yes, your understanding is correct, I meant use of two >> > m-lines. While that >> > is not perfect, I believe changing this fundamental part in a >> > non-backward-compatible way would be much worse, as I >> explained in the >> > previous email. Making the change can only help to enable >> > asymmetric video >> > solutions more conveniently, but would basically disable >> > communications >> > between any legacy implementation of new implementations. In >> > addition, there >> > might be a technical reason, which I don't know, duing the >> > development of >> > RFC 3984 for the current specification of the level part. >> > >> > BR, YK >> > >> > > -----Original Message----- >> > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >> > > Sent: Tuesday, May 05, 2009 4:47 AM >> > > To: Ye-Kui Wang; Roni Even; avt@ietf.org >> > > Subject: RE: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - >> > > Profile level >> > > >> > > YK, >> > > >> > > If I understand correctly, you would have two m-lines, one >> > > a=sendonly (on which a lower bandwidth is negotiated, say), >> > > and one a=recvonly (on which a higher bandwidth is >> > > negotiated, say)? This would really complicate things. For >> > > example, I think you would need to assign two different >> > > labels (a=label attribute), because I don't think the use of >> > > the same label for two m-lines is defined. How would you >> > > refer to them for floor control purposes? Also you would need >> > > to convey two a=crypto lines for security descriptions if >> > > using SRTP. It would also complicate NAT traversal, e.g., if >> > > using ICE, I think you would need to treat them as two >> > separate media. >> > > >> > > John >> > > >> > > >> > > > -----Original Message----- >> > > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On >> > > Behalf Of >> > > > Ye-Kui Wang >> > > > Sent: 04 May 2009 22:56 >> > > > To: 'Roni Even'; avt@ietf.org >> > > > Subject: Re: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt >> - Profile >> > > > level >> > > > >> > > > Hi, >> > > > >> > > > The current design in the bis draft (as well as in in RFC >> > > > 3984) does allow negotiation of asymmetric video solutions >> > > using SDP >> > > > offer/answer. What you need to do is just to separate the >> > > sending part >> > > > (a=sendonly) and the receiving part >> > > > (=recvonly) in the SDP. Therefore, I don't think there is >> > > any problem >> > > > and any need for change in the regard. >> > > > >> > > > BR,YK >> > > > >> > > > >> > > > ________________________________ >> > > > >> > > > From: avt-bounces@ietf.org >> > > > [mailto:avt-bounces@ietf.org] On Behalf Of Roni Even >> > > > Sent: Monday, May 04, 2009 5:09 PM >> > > > To: avt@ietf.org >> > > > Subject: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - >> > > Profile level >> > > > >> > > > >> > > > >> > > > From: Ashish Goyal >> > > > Sent: Tuesday, May 05, 2009 12:04 AM >> > > > To: 'avt@ietf.org' >> > > > Subject: draft-ietf-avt-rtp-rfc3984bis-06.txt - >> Profile level >> > > > >> > > > >> > > > >> > > > Hi, >> > > > >> > > > I am leading an effort of sip video vendors under >> > > > the aegis of IMTC Sip video parity and working on a BCP >> > > > document to enhance sip video interoperability. In our >> > > > discussion today there were some concerns around the section >> > > > 8.2.2 of 3984bis - specifically around the text >> > > > >> > > > >> > > > >> > > > "The level part of "profile-level-id" is >> > > > downgradable, i.e. the answerer MUST maintain the same or a >> > > > lower level or remove the media format (payload type) >> > completely. " >> > > > >> > > > >> > > > >> > > > I am writing this mail in the hope that we can amend >> > > > the 3984 bis so that we can consider it as a reference - >> > > > rather than having a conflicting BCP document for video. >> > > > >> > > > >> > > > >> > > > The recommendation from the group was to >> > > > >> > > > 1) Consider level parameter as a declaration of >> > > > receive capabilities and not let it imply the resolution used >> > > > for transmit >> > > > >> > > > 2) Consider the level parameter as either >> > > > upgradeable or downgradeable - since it's really talking >> > > > about receive capability. The answerer must not transmit a >> > > > level higher than the offer - but can provide an answer which >> > > > contains a level higher than the offer. This would allow the >> > > > offerer to transmit a higher level than it can receive - if >> > > > it chooses to. >> > > > >> > > > >> > > > >> > > > Here is the issue that we are trying to address by >> > > > having asymmetric support for level. >> > > > >> > > > >> > > > >> > > > One of the use cases which is well supported by some >> > > > of the leading video implementers is support for asymmetric >> > > > video resolutions. The use case where this becomes important >> > > > is when the calls are made from a video softclient running >> > > > on a pc. Because of asymmetric compute requirements on >> > > > encode and decode - the video softclients would be able to >> > > > typically decode much higher resolution - than they are able >> > > > to encode. However section 8.2.2 makes this negotiation >> > > difficult. >> > > > >> > > > >> > > > >> > > > Here is how the use case is expected to work. >> > > > >> > > > >> > > > >> > > > Assume the video device A is able to decode level 3.1 >> > > > and encode only level 1.1 >> > > > >> > > > B is capable of both decoding and encoding level 3.1. >> > > > >> > > > A would quote a level of 3.1 in its offer >> > > > >> > > > B would respond with level 3.1 in the answer >> > > > >> > > > >> > > > >> > > > A would send to B video stream at level 1.1 - since A >> > > > can only encode at level 1.1. >> > > > >> > > > B would send level 3.1 to A since A can >> decode upto level 3.1. >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > Regards, >> > > > >> > > > Ashish >> > > > >> > > > >> > > >> > >> > >> > >> >> >> > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > -- # TANDBERG R&D ## http://www.tandberg.com ### http://folk.uio.no/tomkri/ From abegen@cisco.com Tue May 5 13:39:13 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12F2228C275; Tue, 5 May 2009 13:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.396 X-Spam-Level: X-Spam-Status: No, score=-6.396 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XU6UgHEXPqKM; Tue, 5 May 2009 13:39:10 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id A641F3A6DC2; Tue, 5 May 2009 13:39:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,299,1238976000"; d="scan'208";a="74791579" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 05 May 2009 20:40:37 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n45KebET015148; Tue, 5 May 2009 13:40:37 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n45KebTe018640; Tue, 5 May 2009 20:40:37 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 May 2009 13:40:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Tue, 5 May 2009 13:40:13 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54093C39D9@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-05 Thread-Index: AcnNwXff8G2zzjlBRrCxdg/CrbxxiAAAA8ig From: "Ali C. Begen (abegen)" To: X-OriginalArrivalTime: 05 May 2009 20:40:37.0538 (UTC) FILETIME=[BF1B2820:01C9CDC1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2046; t=1241556037; x=1242420037; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20FW=3A=20New=20Version=20Notification=20for=20=2 0=20=20=20=20=20=20=20=20draft-ietf-fecframe-interleaved-fec -scheme-05=20 |Sender:=20; bh=anoN1MNehcjA7GmaMaiGFfRsRj48aOdKIE1cm8jEaUI=; b=g726bN+HL9DeZ8RFiBS50a5axE/SqMexHap6DvetIp6ukdN3/PnGXn7A0F cfk4bfNP7QNNrqRztgz5AdISoIoFl43fcpCBVQjYAL4CIfpxK/0kGC0IqC1+ EYHWefz4wM; Authentication-Results: sj-dkim-2; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: avt@ietf.org Subject: [AVT] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-05 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 20:39:13 -0000 VGhpcyBhZGRyZXNzZXMgdGhlIGNvbW1lbnRzIGZyb20gVmluY2VudC4NCg0KTWFyc2hhbGwsIGNv dWxkIHdlIGZpbmFsaXplIFdHTEM/DQoNCkJSLA0KLWFjYmVnZW4NCg0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogSUVURiBJLUQgU3VibWlzc2lvbiBUb29sIFttYWlsdG86aWRz dWJtaXNzaW9uQGlldGYub3JnXSANClNlbnQ6IFR1ZXNkYXksIE1heSAwNSwgMjAwOSAxOjM3IFBN DQpUbzogQWxpIEMuIEJlZ2VuIChhYmVnZW4pDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24gZm9yIGRyYWZ0LWlldGYtZmVjZnJhbWUtaW50ZXJsZWF2ZWQtZmVjLXNjaGVtZS0wNSAN Cg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaWV0Zi1mZWNmcmFtZS1pbnRlcmxlYXZl ZC1mZWMtc2NoZW1lLTA1LnR4dCBoYXMgYmVlbiBzdWNjZXNzZnVseSBzdWJtaXR0ZWQgYnkgQWxp IEJlZ2VuIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBk cmFmdC1pZXRmLWZlY2ZyYW1lLWludGVybGVhdmVkLWZlYy1zY2hlbWUNClJldmlzaW9uOgkgMDUN ClRpdGxlOgkJIFJUUCBQYXlsb2FkIEZvcm1hdCBmb3IgMS1EIEludGVybGVhdmVkIFBhcml0eSBG RUMNCkNyZWF0aW9uX2RhdGU6CSAyMDA5LTA1LTA1DQpXRyBJRDoJCSBmZWNmcmFtZQ0KTnVtYmVy X29mX3BhZ2VzOiAzMQ0KDQpBYnN0cmFjdDoNClRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIG5ldyBS VFAgcGF5bG9hZCBmb3JtYXQgZm9yIHRoZSBGb3J3YXJkIEVycm9yDQpDb3JyZWN0aW9uIChGRUMp IHRoYXQgaXMgZ2VuZXJhdGVkIGJ5IHRoZSAxLUQgaW50ZXJsZWF2ZWQgcGFyaXR5IGNvZGUNCmZy b20gYSBzb3VyY2UgbWVkaWEgZW5jYXBzdWxhdGVkIGluIFJUUC4gIFRoZSAxLUQgaW50ZXJsZWF2 ZWQgcGFyaXR5DQpjb2RlIGlzIGEgc3lzdGVtYXRpYyBjb2RlLCB3aGVyZSBhIG51bWJlciBvZiBy ZXBhaXIgc3ltYm9scyBhcmUNCmdlbmVyYXRlZCBmcm9tIGEgc2V0IG9mIHNvdXJjZSBzeW1ib2xz IGFuZCBzZW50IGluIGEgcmVwYWlyIGZsb3cNCnNlcGFyYXRlIGZyb20gdGhlIHNvdXJjZSBmbG93 IHRoYXQgY2FycmllcyB0aGUgc291cmNlIHN5bWJvbHMuICBUaGUNCjEtRCBpbnRlcmxlYXZlZCBw YXJpdHkgY29kZSBvZmZlcnMgYSBnb29kIHByb3RlY3Rpb24gYWdhaW5zdCBidXJzdHkNCnBhY2tl dCBsb3NzZXMgYXQgYSBjb3N0IG9mIGRlY2VudCBjb21wbGV4aXR5LiAgVGhlIG5ldyBwYXlsb2Fk IGZvcm1hdA0KZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50IGlzIHVzZWQgKHdpdGggc29tZSBleGNl cHRpb25zKSBhcyBhIHBhcnQgb2YNCnRoZSBEVkIgQXBwbGljYXRpb24tbGF5ZXIgRkVDIHNwZWNp ZmljYXRpb24uDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KVGhlIElFVEYgU2VjcmV0 YXJpYXQuDQoNCg0K From ron.even.tlv@gmail.com Tue May 5 14:36:39 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 622F53A68FA; Tue, 5 May 2009 14:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JgZ71GAz0477; Tue, 5 May 2009 14:36:38 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by core3.amsl.com (Postfix) with ESMTP id 67E7C3A6DD7; Tue, 5 May 2009 14:36:30 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 13so1678227fge.18 for ; Tue, 05 May 2009 14:37:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=BMYnm9dhApm3kmDc6IFzdNyhlaki3zRBNdMKpigJw2M=; b=VqGitj5x6t612LsWSsH5cUPh+a1hXc7Ax626khHoK2OTnUMWEL/MN+GTKOlDgEb62E /9valNMkqyoFK3ckG4fBxi4bme+jcdPjDNr8ZEXLRPghITWqoW1eLONxgB7y5cM87Dmm YiIZIc8XjTjlCZCgrePehKrNBut6oe6GmnNqc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=w5G8UTz7Uk1AgyyWJZpT+nNQ9ZDpPFxSAKYHq1s+qZvRuB5sI+dvOzDUKpuuknO7Rp GoXD5PibfdbMKDjqQk5TyEBZow3jqtstzc1dOteUI3gI2nOgJLY/YacLLp65Lv7B+pJ+ duqtpSU5ZuR9rlM1O7hAZB5ZTnd4gBLlVmT14= Received: by 10.86.49.16 with SMTP id w16mr633825fgw.4.1241559474745; Tue, 05 May 2009 14:37:54 -0700 (PDT) Received: from windows8d787f9 (bzq-79-180-27-88.red.bezeqint.net [79.180.27.88]) by mx.google.com with ESMTPS id 4sm9221203fge.18.2009.05.05.14.37.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 05 May 2009 14:37:54 -0700 (PDT) From: "Roni Even" To: "'Ali C. Begen \(abegen\)'" , References: <04CAD96D4C5A3D48B1919248A8FE0D54093C39D9@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D54093C39D9@xmb-sjc-215.amer.cisco.com> Date: Wed, 6 May 2009 00:36:01 +0300 Message-ID: <4a00b1b2.0405560a.2c8d.2f0c@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnNwXff8G2zzjlBRrCxdg/CrbxxiAAAA8igAAHGtiA= Content-Language: en-us Cc: avt@ietf.org Subject: Re: [AVT] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-05 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 21:36:39 -0000 Ali, Is there a reason to reference RFC 4756 and not reference also draft-ietf-mmusic-source-attributes if ssrc multiplexing is allowed. Roni -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ali C. Begen (abegen) Sent: Tuesday, May 05, 2009 11:40 PM To: fecframe@ietf.org Cc: avt@ietf.org Subject: [AVT] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-05 This addresses the comments from Vincent. Marshall, could we finalize WGLC? BR, -acbegen -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Tuesday, May 05, 2009 1:37 PM To: Ali C. Begen (abegen) Subject: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-05 A new version of I-D, draft-ietf-fecframe-interleaved-fec-scheme-05.txt has been successfuly submitted by Ali Begen and posted to the IETF repository. Filename: draft-ietf-fecframe-interleaved-fec-scheme Revision: 05 Title: RTP Payload Format for 1-D Interleaved Parity FEC Creation_date: 2009-05-05 WG ID: fecframe Number_of_pages: 31 Abstract: This document defines a new RTP payload format for the Forward Error Correction (FEC) that is generated by the 1-D interleaved parity code from a source media encapsulated in RTP. The 1-D interleaved parity code is a systematic code, where a number of repair symbols are generated from a set of source symbols and sent in a repair flow separate from the source flow that carries the source symbols. The 1-D interleaved parity code offers a good protection against bursty packet losses at a cost of decent complexity. The new payload format defined in this document is used (with some exceptions) as a part of the DVB Application-layer FEC specification. The IETF Secretariat. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www.ietf.org/mailman/listinfo/avt From abegen@cisco.com Tue May 5 15:26:43 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B30A3A6DD2; Tue, 5 May 2009 15:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FzLeb2mWO+K5; Tue, 5 May 2009 15:26:42 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 985243A6E91; Tue, 5 May 2009 15:26:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,299,1238976000"; d="scan'208";a="162163563" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 05 May 2009 22:27:30 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n45MRUtp010289; Tue, 5 May 2009 15:27:30 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n45MRU5r006591; Tue, 5 May 2009 22:27:30 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 May 2009 15:27:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 May 2009 15:26:25 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54093C3ADB@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4a00b1b2.0405560a.2c8d.2f0c@mx.google.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-05 Thread-Index: AcnNwXff8G2zzjlBRrCxdg/CrbxxiAAAA8igAAHGtiAAAddskA== References: <04CAD96D4C5A3D48B1919248A8FE0D54093C39D9@xmb-sjc-215.amer.cisco.com> <4a00b1b2.0405560a.2c8d.2f0c@mx.google.com> From: "Ali C. Begen (abegen)" To: "Roni Even" , X-OriginalArrivalTime: 05 May 2009 22:27:30.0503 (UTC) FILETIME=[AD87F570:01C9CDD0] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2813; t=1241562450; x=1242426450; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20RE=3A=20[AVT]=20FW=3A=20New=20Version=20Notific ation=20for=09draft-ietf-fecframe-interleaved-fec-scheme-05 |Sender:=20; bh=d9rB6gGHvjBAGNC5sekI6L8o5arDJJ9qdMzrARHThJE=; b=A6cAE4OvU5XPxeijjX71QtQGOqpLXwm/Lfvk5kMZrPX3sWqLNMRLt0IsH6 UoMfCjT8oc93t8zCS/JE+J2AF4C66SL7LPBFNZ73M+C6FO7J0SspBVA0TQu7 6vy7KzXOu3; Authentication-Results: sj-dkim-3; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: avt@ietf.org Subject: Re: [AVT] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-05 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 22:26:43 -0000 I wanted to make a reference 4756 for now. Later, I will change it to = 4756bis if we can move quickly on that draft. This way it will be much = cleaner IMO (the new draft includes both session and ssrc multiplexing = scenarios). So, I'd appreciate if you and others could provide comments for 4756bis. -acbegen > -----Original Message----- > From: Roni Even [mailto:ron.even.tlv@gmail.com] > Sent: Tuesday, May 05, 2009 2:36 PM > To: Ali C. Begen (abegen); fecframe@ietf.org > Cc: avt@ietf.org > Subject: RE: [AVT] FW: New Version Notification for = draft-ietf-fecframe-interleaved-fec- > scheme-05 >=20 > Ali, >=20 > Is there a reason to reference RFC 4756 and not reference also > draft-ietf-mmusic-source-attributes if ssrc multiplexing is allowed. >=20 >=20 > Roni >=20 > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Ali C. > Begen (abegen) > Sent: Tuesday, May 05, 2009 11:40 PM > To: fecframe@ietf.org > Cc: avt@ietf.org > Subject: [AVT] FW: New Version Notification for > draft-ietf-fecframe-interleaved-fec-scheme-05 >=20 > This addresses the comments from Vincent. >=20 > Marshall, could we finalize WGLC? >=20 > BR, > -acbegen >=20 >=20 > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Tuesday, May 05, 2009 1:37 PM > To: Ali C. Begen (abegen) > Subject: New Version Notification for > draft-ietf-fecframe-interleaved-fec-scheme-05 >=20 >=20 > A new version of I-D, = draft-ietf-fecframe-interleaved-fec-scheme-05.txt has > been successfuly submitted by Ali Begen and posted to the IETF = repository. >=20 > Filename: draft-ietf-fecframe-interleaved-fec-scheme > Revision: 05 > Title: RTP Payload Format for 1-D Interleaved Parity FEC > Creation_date: 2009-05-05 > WG ID: fecframe > Number_of_pages: 31 >=20 > Abstract: > This document defines a new RTP payload format for the Forward Error > Correction (FEC) that is generated by the 1-D interleaved parity code > from a source media encapsulated in RTP. The 1-D interleaved parity > code is a systematic code, where a number of repair symbols are > generated from a set of source symbols and sent in a repair flow > separate from the source flow that carries the source symbols. The > 1-D interleaved parity code offers a good protection against bursty > packet losses at a cost of decent complexity. The new payload format > defined in this document is used (with some exceptions) as a part of > the DVB Application-layer FEC specification. >=20 >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From ingemar.s.johansson@ericsson.com Tue May 5 23:01:53 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 083323A6B43; Tue, 5 May 2009 23:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.263 X-Spam-Level: X-Spam-Status: No, score=-5.263 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_22=0.6, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DwLcuSCspfLJ; Tue, 5 May 2009 23:01:46 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 98C103A6BF7; Tue, 5 May 2009 23:01:18 -0700 (PDT) X-AuditID: c1b4fb3c-b7b19ae000006089-64-4a012802bf55 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id CE.63.24713.308210A4; Wed, 6 May 2009 08:02:43 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 May 2009 08:02:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 May 2009 08:02:41 +0200 Message-ID: <130EBB38279E9847BAAAE0B8F9905F8C0101DEB0@esealmw109.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level Thread-Index: AcnNjgwsVJyZf+j8TGOd65ziIJFOPwAf8GXQ References: From: "Ingemar Johansson S" To: X-OriginalArrivalTime: 06 May 2009 06:02:42.0864 (UTC) FILETIME=[44F78300:01C9CE10] X-Brightmail-Tracker: AAAAAQAAAZE= Cc: mmusic@ietf.org Subject: Re: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 06:01:53 -0000 Hi In=20 http://tools.ietf.org/id/draft-johansson-mmusic-asymmetric-media-00.txt I proposed an extension to SDP*CapNeg to make it possible to negotiate asymmetric sessions, not only video but also for various audio setups where asymmetry is an issue. I did not get any comments on the list but had a lengthy discussion about the pros and cons with Bob Gilman (Bob, please feel free to speak up :-) The extension builds on SDP*CapNeg but is not anymore backwards compatible in the SDPCapNeg way as one cannot formulate an answer SDP with a conventional SDP. There is however a backwards compatibility in the sense that an enpoint that does not understand the asymmetric extension will fall back to the symmetric version. Regarding 3984bis, there is also a comment in the doc that said draft already has some support for asymmetry. Regards Ingemar PS SDP*CapNeg =3D SDP Capability Negotiation and SDP Media = Capabilities Negotiation >=20 > ---------------------------------------------------------------------- >=20 > Message: 1 > Date: Mon, 04 May 2009 17:55:46 -0400 > From: Ye-Kui Wang > Subject: Re: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile > level > To: 'Roni Even' , avt@ietf.org > Message-ID: <089AD8684C5E4C2995F01C2527EE7081@china.huawei.com> > Content-Type: text/plain; charset=3D"us-ascii" >=20 > Hi, > =20 > The current design in the bis draft (as well as in in RFC=20 > 3984) does allow negotiation of asymmetric video solutions=20 > using SDP offer/answer. What you need to do is just to=20 > separate the sending part (a=3Dsendonly) and the receiving part=20 > (=3Drecvonly) in the SDP. Therefore, I don't think there is any=20 > problem and any need for change in the regard.=20 > =20 > BR,YK >=20 >=20 > _____ =20 >=20 > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On=20 > Behalf Of Roni Even > Sent: Monday, May 04, 2009 5:09 PM > To: avt@ietf.org > Subject: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level >=20 >=20 >=20 > From: Ashish Goyal > Sent: Tuesday, May 05, 2009 12:04 AM > To: 'avt@ietf.org' > Subject: draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level=20 >=20 > =20 >=20 > Hi,=20 >=20 > I am leading an effort of sip video vendors under the=20 > aegis of IMTC Sip video parity and working on a BCP document=20 > to enhance sip video interoperability. In our discussion=20 > today there were some concerns around the section 8.2.2 of=20 > 3984bis - specifically around the text >=20 > =20 >=20 > "The level part of "profile-level-id" is downgradable, i.e.=20 > the answerer MUST maintain the same or a lower level or=20 > remove the media format (payload type) completely. " >=20 > =20 >=20 > I am writing this mail in the hope that we can amend the=20 > 3984 bis so that we can consider it as a reference - rather=20 > than having a conflicting BCP document for video.=20 >=20 > =20 >=20 > The recommendation from the group was to >=20 > 1) Consider level parameter as a declaration of receive=20 > capabilities > and not let it imply the resolution used for transmit >=20 > 2) Consider the level parameter as either upgradeable or=20 > downgradeable > - since it's really talking about receive capability. The=20 > answerer must not transmit a level higher than the offer -=20 > but can provide an answer which contains a level higher than=20 > the offer. This would allow the offerer to transmit a higher=20 > level than it can receive - if it chooses to.=20 >=20 > =20 >=20 > Here is the issue that we are trying to address by having=20 > asymmetric support for level.=20 >=20 > =20 >=20 > One of the use cases which is well supported by some of the=20 > leading video implementers is support for asymmetric video=20 > resolutions. The use case where this becomes important is=20 > when the calls are made from a video softclient running on a=20 > pc. Because of asymmetric compute requirements on encode and=20 > decode - the video softclients would be able to typically=20 > decode much higher resolution - than they are able to encode.=20 > However section 8.2.2 makes this negotiation difficult. =20 >=20 > =20 >=20 > Here is how the use case is expected to work.=20 >=20 > =20 >=20 > Assume the video device A is able to decode level 3.1 and=20 > encode only level 1.1 >=20 > B is capable of both decoding and encoding level 3.1.=20 >=20 > A would quote a level of 3.1 in its offer >=20 > B would respond with level 3.1 in the answer >=20 > =20 >=20 > A would send to B video stream at level 1.1 - since A can=20 > only encode at level 1.1.=20 >=20 > B would send level 3.1 to A since A can decode upto level 3.1. >=20 > =20 >=20 > =20 >=20 > Regards,=20 >=20 > Ashish >=20 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL:=20 > >=20 =20 From gjshep@gmail.com Wed May 6 01:37:02 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EA363A6E07 for ; Wed, 6 May 2009 01:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[AWL=0.502, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlBI9d7rOsV5 for ; Wed, 6 May 2009 01:36:55 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by core3.amsl.com (Postfix) with ESMTP id 3F5D73A69EE for ; Wed, 6 May 2009 01:36:46 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so5855687yxb.49 for ; Wed, 06 May 2009 01:38:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=8OBzMk7fctQXqyzz/SUMOVthqB8s5QPjHbvXotM40CY=; b=aZ6i94oH0TxyQwluPdFAKYcnyeKSZmyh21xCoKqMeivuBw4ZWTF5PnkqW7sK0xtD5m znzVtMEjRkQhkRvQipt4yk5AKN8fAKrOD8m6ezbdijaA1ac5hEyQqzg0J/M+ErmF6hOC YJdPft25Ov2hvSW5T9zKvayju1VloKA9mVZM8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=QQwcj7HQnbL1ITvLsYS/ZNNdf2rkybg/AJk6jd+CHri+INY8JTP8SEazWd8ELoOwza wW/4RpKbeabWVUZCgTj6/bL5S8grLQqOVl3RKpjU7bqTk4ojxjbsrEDSv+kWkumu00kc RFhrpBlJn1IGLlcqjbJ0SPAFYBtklLgs1G3vc= MIME-Version: 1.0 Received: by 10.100.153.6 with SMTP id a6mr2373132ane.29.1241599090684; Wed, 06 May 2009 01:38:10 -0700 (PDT) In-Reply-To: <57a9e15d0905050958p210db525qb058fd62d6ea7073@mail.gmail.com> References: <6D5990B2-9100-4AC8-89D3-BDEE27A002E5@apple.com> <31d1be720905050856x1819d8f4wda97866f922043b0@mail.gmail.com> <57a9e15d0905050958p210db525qb058fd62d6ea7073@mail.gmail.com> Date: Wed, 6 May 2009 01:38:10 -0700 Message-ID: <38c19b540905060138i35ce99b9q4fac697ebe451ced@mail.gmail.com> From: Greg Shepherd To: Alex Giladi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: http-live-streaming-review@group.apple.com, avt@ietf.org Subject: Re: [AVT] iPhone streaming Internet-Draft posted X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gjshep@gmail.com List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 08:37:02 -0000 On Tue, May 5, 2009 at 9:58 AM, Alex Giladi wrote: > Greg, > It's not entirely clear to me, but it looks from #4 that they are > looking at progressive download of segments vs. 'real' streaming. I > suppose one can do this with RTSP using PLAY request with closed time > ranges. > One problem that may happen with RTSP is that there may be overzealous > firewalls that blocks RTSP, but not HTTP. > Alex. This is becoming a sad reality. Despite all the great work developing robust streaming protocols, "streaming" services over the public Internet are increasingly required to adopt HTTP in order to get past firewalls. Welcome to the Port80 network. Greg > On Tue, May 5, 2009 at 9:56 AM, Greg Herlein wrote= : >> I agree with Ross.=A0=A0 I cannot see any reason at all to invent a new >> protocol.=A0 If you want to keep the media inside a TCP connection then = just >> interleave it in the RTSP session.=A0 If you want to make something real= ly >> useful then use RTP and support multicast.=A0 I personally want a handhe= ld >> application that I can watch a streaming show sitting in the airport - n= ot >> over the cellular connection necessarily but over a local hot spot.=A0= =A0 Hmmm, >> maybe I should write that for my new Blackberry Bold (whose H.264 decode >> seems beautiful). >> >> Inventing a new protocol - however cool it is - just creates less >> interoperability and more silo'd world. >> >> Perhaps there's a reason for a new protocol?=A0 Perhaps Apple could elab= orate >> on what problem they are trying to solve? >> >> Greg >> >> On Tue, May 5, 2009 at 8:39 AM, Ross Finlayson >> wrote: >>>> >>>> We appreciate feedback on the protocol. >>> >>> Rather than invent yet another protocol, why not just implement a RTSP/= RTP >>> client on the iPhone instead? >>> >>> (If you *really* want to do this over HTTP (though ideally only when >>> direct RTSP/RTP connectivity is not available), you could use the >>> RTSP/RTP-over-HTTP hack that QuickTime Player already uses.) >>> >>> After all, there are plenty of people at Apple with expertise on this (= but >>> I dunno, perhaps they work in some other group? :-) >>> -- >>> >>> Ross Finlayson >>> Live Networks, Inc. >>> http://www.live555.com/ >>> _______________________________________________ >>> Audio/Video Transport Working Group >>> avt@ietf.org >>> https://www.ietf.org/mailman/listinfo/avt >> >> >> >> -- >> Greg Herlein >> www.herlein.com >> >> _______________________________________________ >> Audio/Video Transport Working Group >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt >> >> > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > From magnus.westerlund@ericsson.com Wed May 6 07:42:09 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11F453A6D3F for ; Wed, 6 May 2009 07:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.176 X-Spam-Level: X-Spam-Status: No, score=-6.176 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2HKE3HG15avA for ; Wed, 6 May 2009 07:42:08 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 9BCE93A6ED0 for ; Wed, 6 May 2009 07:41:06 -0700 (PDT) X-AuditID: c1b4fb3c-b7b19ae000006089-cf-4a01a1d88177 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 0F.05.24713.8D1A10A4; Wed, 6 May 2009 16:42:32 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 May 2009 16:42:31 +0200 Received: from [153.88.50.61] ([153.88.50.61]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 May 2009 16:42:31 +0200 Message-ID: <4A01A1D6.9020206@ericsson.com> Date: Wed, 06 May 2009 16:42:30 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Ye-Kui Wang References: <49ff59e6.1358560a.4af5.05e3@mx.google.com> <089AD8684C5E4C2995F01C2527EE7081@china.huawei.com> <717562D70E24CF489737F81B0EA234DF0E712574@lsmail.austin.kmvtechnologies.com> <07F83448A6AC4B428694E13E14AB3F9C@china.huawei.com> In-Reply-To: <07F83448A6AC4B428694E13E14AB3F9C@china.huawei.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 06 May 2009 14:42:31.0351 (UTC) FILETIME=[E2C0F470:01C9CE58] X-Brightmail-Tracker: AAAAAQAAAZE= Cc: avt@ietf.org Subject: Re: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 14:42:09 -0000 Ye-Kui Wang skrev: > I don't see a technical reason why the level part was not specified as a > capability parameter in the beginning. However, now it is too late > because there are already a huge amount of RFC 3984 implementations > taking the level part in the way as specified in RFC 3984 and the bis > draft. Unless something is broken, we should not make a change that is > not backward compatible, because that will hurt interoperability instead > of making better interoperability. When it comes to RFC 3984 definition, the intention, but which I screwed up in defining was that the profile needs to be symmetric, but the level can be changed. This is a thorny issue, and if you want asymmetric behavior you will need to have separate capability and actual transmission configuration in the SDP. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From ron.even.tlv@gmail.com Wed May 6 08:14:38 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 623033A6D3F for ; Wed, 6 May 2009 08:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.161 X-Spam-Level: X-Spam-Status: No, score=-1.161 tagged_above=-999 required=5 tests=[AWL=0.675, BAYES_00=-2.599, SARE_RECV_BEZEQINT_B=0.763] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVAOjULY1zp4 for ; Wed, 6 May 2009 08:14:37 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 093C13A6E74 for ; Wed, 6 May 2009 08:13:29 -0700 (PDT) Received: by fxm2 with SMTP id 2so184283fxm.37 for ; Wed, 06 May 2009 08:14:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=MuLgg0w2YN81c4cJmLpCFL8tCGlwi7IFespYF/ZoyVg=; b=atpB4zMKlMTh1UkLWeaZSRLILhdDIHlIXiPF0+E1ielHWh6GMXjGwWvMKdcXXCmIck 49PtGVT0b6tqR4KF6IVoN2lzQ+iPgDg1xtJAmn0hMnJTVxzH/M2RP+PaDXhJ3vsrdXDe WkryCXTzeCBpGp2wzTaDUbyvDJ03IAOv96T8I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=qziDzGS3CtaEdS9fDfDaYByC25MZER7QOJBpC0blIiw0xjvBVdqE+LWI6k63qF5p/3 ez3ePbgjYBthhv4cvMPfRUZy0+gyoBmTG+whPWyj/WNQPVtsdNKwOUxmkqhAbCFy8YSa VSMCjOCONFbonHjWz4erB6QNnD2GDnTvCStG8= Received: by 10.86.90.2 with SMTP id n2mr1404688fgb.61.1241622893891; Wed, 06 May 2009 08:14:53 -0700 (PDT) Received: from windows8d787f9 (bzq-82-81-48-161.red.bezeqint.net [82.81.48.161]) by mx.google.com with ESMTPS id e20sm10746345fga.10.2009.05.06.08.14.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 06 May 2009 08:14:53 -0700 (PDT) From: "Roni Even" To: "'Magnus Westerlund'" , "'Ye-Kui Wang'" References: <49ff59e6.1358560a.4af5.05e3@mx.google.com> <089AD8684C5E4C2995F01C2527EE7081@china.huawei.com> <717562D70E24CF489737F81B0EA234DF0E712574@lsmail.austin.kmvtechnologies.com> <07F83448A6AC4B428694E13E14AB3F9C@china.huawei.com> <4A01A1D6.9020206@ericsson.com> In-Reply-To: <4A01A1D6.9020206@ericsson.com> Date: Wed, 6 May 2009 18:14:24 +0300 Message-ID: <4a01a96d.1438560a.1014.ffffe2c7@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnOWOO8Vy6j+02SSaKcDdrzjQtsygAAltpw Content-Language: en-us Cc: avt@ietf.org Subject: Re: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 15:14:38 -0000 Hi Magnus, I think the question that Ashish is trying to ask is not about general asymmetry. The level parameter is signaling a maximum since it implies support for any level below the on in the offer. The level specifies the maximum that the offerer can send and receive. The answerer should = except to receive a stream that is in the level in the offer. Now the answer can reply with a level lower than the one in the offer. = Now the offer should send a stream that is within the level in the answer = since by signaling a specific level it implies that a lower one is also = possible. Still the answerer can send a stream that is within the level signaled = by the offer even though it gave a lower level - this is already asymmetry. = The problem is that the current text says that the level signals the level = that the answerer can receive but also that it can send but the above = description hints that asymmetry may happen even now. Ashish is asking why for the case of offer answer, if the above analysis = is correct why not allow the answerer to specify a level higher than the = one in the offer since it will still have similar result to the case when the answer has a level lower than the offer. =20 And I agree that the implementation today for the offer answer case = follow draft 3984bis Roni -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 Sent: Wednesday, May 06, 2009 5:43 PM To: Ye-Kui Wang Cc: 'Ashish Goyal'; 'Roni Even'; avt@ietf.org Subject: Re: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level Ye-Kui Wang skrev: > I don't see a technical reason why the level part was not specified as = a > capability parameter in the beginning. However, now it is too late > because there are already a huge amount of RFC 3984 implementations > taking the level part in the way as specified in RFC 3984 and the bis > draft. Unless something is broken, we should not make a change that is > not backward compatible, because that will hurt interoperability = instead > of making better interoperability. When it comes to RFC 3984 definition, the intention, but which I screwed up in defining was that the profile needs to be symmetric, but the level can be changed. This is a thorny issue, and if you want asymmetric behavior you will need to have separate capability and actual transmission configuration in the SDP. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From olivier.crete@collabora.co.uk Tue May 5 10:13:30 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED7A528C145 for ; Tue, 5 May 2009 10:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.381 X-Spam-Level: X-Spam-Status: No, score=-1.381 tagged_above=-999 required=5 tests=[AWL=0.318, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hFRJPajhw6YX for ; Tue, 5 May 2009 10:13:30 -0700 (PDT) Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [93.93.131.97]) by core3.amsl.com (Postfix) with ESMTP id 32EB228C102 for ; Tue, 5 May 2009 10:13:30 -0700 (PDT) Received: from [192.168.1.102] (MTLXPQAK-1176055545.sdsl.bell.ca [70.25.46.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bhuna.collabora.co.uk (Postfix) with ESMTP id 6386DDF22 for ; Tue, 5 May 2009 18:14:55 +0100 (BST) From: Olivier =?ISO-8859-1?Q?Cr=EAte?= To: avt@ietf.org Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-rGU+zt8YAIaXmuDLWQsm" Organization: Collabora Date: Tue, 05 May 2009 13:14:53 -0400 Message-Id: <1241543693.1843.12.camel@TesterTop3.tester.ca> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 X-Mailman-Approved-At: Wed, 06 May 2009 08:36:23 -0700 Subject: [AVT] SDP Offer/answer in draft-ietf-avt-rfc3189bis-03 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 17:13:31 -0000 --=-rGU+zt8YAIaXmuDLWQsm Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, The section on SDP Offer/Answer in this draft seems a bit unclear to me. Even though the "encode" paramete is required, it seems to imply that it could not be there: "If the offerer sets a encode type on a=3Dfmtp field, the answerer MUST select one encode type, and reply with selected encode type value. What if the offerer does not set an encode type? I also don't see a mecanism to negotiate the supported encode type? Can it be assumed that if the offerer supports an encode type, it support all lower resolution/framerates ? If the answer is yes, it should be specified. If the answer is no, I guess the answerer should remove any payload it can't understand? P.S. I'm not on the list, please keep me in CC. --=20 Olivier Cr=C3=AAte olivier.crete@collabora.co.uk Collabora Ltd --=-rGU+zt8YAIaXmuDLWQsm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) iEYEABECAAYFAkoAdA0ACgkQHTiOWk7ZorsN3wCfbin3lQXsX+M42ohBJnPgDiWO fl0AnjVywLz0EQylttz6cQwTRY/h8AD6 =lhOQ -----END PGP SIGNATURE----- --=-rGU+zt8YAIaXmuDLWQsm-- From alex.giladi@gmail.com Wed May 6 09:59:08 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A06E3A6B0B for ; Wed, 6 May 2009 09:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cOyDmu--r-PD for ; Wed, 6 May 2009 09:59:00 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 0BEBB28B797 for ; Wed, 6 May 2009 09:56:57 -0700 (PDT) Received: by fxm2 with SMTP id 2so263022fxm.37 for ; Wed, 06 May 2009 09:58:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=rGfBnqDFlelLT8X4q+9WtQ+UlshJuzzoIFfuDBQxark=; b=TYob+yRKyTVYwIsufN+NlueZ7pakMlf6Ho1+XT8cd8C1OZ+bhVZZOmM6nsDJZzkpY5 q9H9WCVsmjuqsmCGQ11tdJPWlzV/wBXOu/MIAx6He9Mxt3GKIeWzUPfbgVrlADv8QkMa PZR+GK/EdcIJAOX/Bi+1PHoWi6sUEVUTMKqIc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=w14P+png69m689lE3fI7GR1rWF8sdBmeKofQtfn0HZ2Wyk3j+wWVeaxneOtYd8rvDw 4nWFL0haUVW2rsanOPcNS6yaNDS/wkVo5WvwaBzc4xAUanlOa8VrOYewQzsiODcW7VZM XqZAmUXoE6kGqvYGTqnwTxA2PVETbZR3Vahvg= MIME-Version: 1.0 Received: by 10.103.227.13 with SMTP id e13mr1029333mur.20.1241629102753; Wed, 06 May 2009 09:58:22 -0700 (PDT) In-Reply-To: <38c19b540905060138i35ce99b9q4fac697ebe451ced@mail.gmail.com> References: <6D5990B2-9100-4AC8-89D3-BDEE27A002E5@apple.com> <31d1be720905050856x1819d8f4wda97866f922043b0@mail.gmail.com> <57a9e15d0905050958p210db525qb058fd62d6ea7073@mail.gmail.com> <38c19b540905060138i35ce99b9q4fac697ebe451ced@mail.gmail.com> Date: Wed, 6 May 2009 10:58:22 -0600 Message-ID: <57a9e15d0905060958k48c816a6id1bb3690648dee5b@mail.gmail.com> From: Alex Giladi To: gjshep@gmail.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: http-live-streaming-review@group.apple.com, avt@ietf.org Subject: Re: [AVT] iPhone streaming Internet-Draft posted X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 16:59:08 -0000 Is there an RTSP-over-HTTP spec? On Wed, May 6, 2009 at 2:38 AM, Greg Shepherd wrote: > On Tue, May 5, 2009 at 9:58 AM, Alex Giladi wrote= : >> Greg, >> It's not entirely clear to me, but it looks from #4 that they are >> looking at progressive download of segments vs. 'real' streaming. I >> suppose one can do this with RTSP using PLAY request with closed time >> ranges. >> One problem that may happen with RTSP is that there may be overzealous >> firewalls that blocks RTSP, but not HTTP. >> Alex. > > This is becoming a sad reality. Despite all the great work developing > robust streaming protocols, "streaming" services over the public > Internet are increasingly required to adopt HTTP in order to get past > firewalls. Welcome to the Port80 network. > > Greg > >> On Tue, May 5, 2009 at 9:56 AM, Greg Herlein wrot= e: >>> I agree with Ross.=C2=A0=C2=A0 I cannot see any reason at all to invent= a new >>> protocol.=C2=A0 If you want to keep the media inside a TCP connection t= hen just >>> interleave it in the RTSP session.=C2=A0 If you want to make something = really >>> useful then use RTP and support multicast.=C2=A0 I personally want a ha= ndheld >>> application that I can watch a streaming show sitting in the airport - = not >>> over the cellular connection necessarily but over a local hot spot.=C2= =A0=C2=A0 Hmmm, >>> maybe I should write that for my new Blackberry Bold (whose H.264 decod= e >>> seems beautiful). >>> >>> Inventing a new protocol - however cool it is - just creates less >>> interoperability and more silo'd world. >>> >>> Perhaps there's a reason for a new protocol?=C2=A0 Perhaps Apple could = elaborate >>> on what problem they are trying to solve? >>> >>> Greg >>> >>> On Tue, May 5, 2009 at 8:39 AM, Ross Finlayson >>> wrote: >>>>> >>>>> We appreciate feedback on the protocol. >>>> >>>> Rather than invent yet another protocol, why not just implement a RTSP= /RTP >>>> client on the iPhone instead? >>>> >>>> (If you *really* want to do this over HTTP (though ideally only when >>>> direct RTSP/RTP connectivity is not available), you could use the >>>> RTSP/RTP-over-HTTP hack that QuickTime Player already uses.) >>>> >>>> After all, there are plenty of people at Apple with expertise on this = (but >>>> I dunno, perhaps they work in some other group? :-) >>>> -- >>>> >>>> Ross Finlayson >>>> Live Networks, Inc. >>>> http://www.live555.com/ >>>> _______________________________________________ >>>> Audio/Video Transport Working Group >>>> avt@ietf.org >>>> https://www.ietf.org/mailman/listinfo/avt >>> >>> >>> >>> -- >>> Greg Herlein >>> www.herlein.com >>> >>> _______________________________________________ >>> Audio/Video Transport Working Group >>> avt@ietf.org >>> https://www.ietf.org/mailman/listinfo/avt >>> >>> >> _______________________________________________ >> Audio/Video Transport Working Group >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt >> > From rjesup@wgate.com Wed May 6 14:08:23 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 431233A68F4 for ; Wed, 6 May 2009 14:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.503 X-Spam-Level: X-Spam-Status: No, score=-1.503 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLutXvv+z8mb for ; Wed, 6 May 2009 14:08:22 -0700 (PDT) Received: from exchange1.wgate.com (pr-66-150-46-254.wgate.com [66.150.46.254]) by core3.amsl.com (Postfix) with ESMTP id 562263A6842 for ; Wed, 6 May 2009 14:08:22 -0700 (PDT) Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 May 2009 17:09:49 -0400 To: Ye-Kui Wang References: <49ff59e6.1358560a.4af5.05e3@mx.google.com> <089AD8684C5E4C2995F01C2527EE7081@china.huawei.com> <0D5F89FAC29E2C41B98A6A762007F5D001D8DC97@GBNTHT12009MSX.gb002.siemens.net> <4a005ef6.1358560a.4934.ffffae26@mx.google.com> <0DB94A632EC341CA965EF492749980C1@china.huawei.com> <4a007227.1438560a.1123.ffffef61@mx.google.com> <89DD91D94A684E29A915B2F9E243EE70@china.huawei.com> From: Randell Jesup Date: Wed, 06 May 2009 17:11:37 -0400 In-Reply-To: <89DD91D94A684E29A915B2F9E243EE70@china.huawei.com> (Ye-Kui Wang's message of "Tue\, 05 May 2009 14\:44\:00 -0400") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 06 May 2009 21:09:49.0457 (UTC) FILETIME=[FDBE8810:01C9CE8E] Cc: avt@ietf.org Subject: Re: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Randell Jesup List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 21:08:23 -0000 Ye-Kui Wang writes: >My understanding is that in RFC 3984 the intention was to allow for level >downgrade in SDP offer/answer, but there is some inconsistence in that >regard and the bis draft clarified the issue. That's correct - Level downgrade was unofficially added/clarified long before the 3984bis effort began. Note that level upgrade would interact (yet again!) with sprop-parameter-sets, though the solution found for 3984bis should work. (I haven't worked out hte use cases; just a gut feeling that it will work.) As mentioned, it would seem that level upgrade would only help in the case of an endpoint that can encode at a higher level than it can/is willing to decode. If encode level == decode level, then offer that. Note that hardware may be able to in theor decode a higher level, but the device may not be able to use the extra resolution and/or framerate. If encode level < decode level (common), then offer the decode level, and send using the encode level. There are some gotchas with this though: a) We're assuming the answerer understands how to level-downgrade b) If using sprop-parameter-sets, we'll want to offer parameter sets for multiple levels (as per 3984bis). Care will need to be taken to ensure compatibility with 3984 endpoints (as is the norm for 3984bis). This is basically normal 3984bis activity. If encode level > decode level (odd - the only cases I can think of that makes sense are: hardware encoder but no hw decoder (weird); pre-encoded outbound video (unusual case); larger sensor than display (example: 1MP sensor and encode ability, but a 640x480 display) - this is the only likely case. I suggest in that case, if possible, implement a post-decode scale and offer the encode level. If that's not sufficient, then we have the tough case. Options are: a) level upgrade on answer (not currently allowed, and now being requested) b) limit answer to offer (wastes camera resolution) c) use two m= lines - but this is an "answer" case, and we can't *add* m-lines, so this only works if two were offered, so this really doesn't help much. Also, if offering two m= lines, you're likely to have real problems with devices that *don't* know how you're using the two streams. Almost all devices will ignore the second stream. My suggestion: offer the encoder level, and scale any received video. It's not an optimum solution, but it retains much more compatibility that other solutions. Alternate if you really want to save bits: add an extension in an offer to the fmtp, level-upgrade-allowed=1. We *could* add that to 3984bis without too many nasty ramifications, I think. -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com "The fetters imposed on liberty at home have ever been forged out of the weapons provided for defence against real, pretended, or imaginary dangers from abroad." - James Madison, 4th US president (1751-1836) From yekuiwang@huawei.com Wed May 6 15:16:32 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FF983A6949 for ; Wed, 6 May 2009 15:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=0.425, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FzqmIbaIAr8T for ; Wed, 6 May 2009 15:16:31 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id B02C93A6941 for ; Wed, 6 May 2009 15:16:09 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJ800ESVTXC1F@usaga04-in.huawei.com> for avt@ietf.org; Wed, 06 May 2009 17:17:36 -0500 (CDT) Received: from W90946 ([10.193.125.102]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJ8001HSTX6L8@usaga04-in.huawei.com> for avt@ietf.org; Wed, 06 May 2009 17:17:36 -0500 (CDT) Date: Wed, 06 May 2009 18:17:30 -0400 From: Ye-Kui Wang In-reply-to: To: 'Randell Jesup' Message-id: <641DD488A4FF471C9CB4815F6518E883@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcnOj+OLgOLMBbf6RSqkhfbBbIl/kQAB7ALA References: <49ff59e6.1358560a.4af5.05e3@mx.google.com> <089AD8684C5E4C2995F01C2527EE7081@china.huawei.com> <0D5F89FAC29E2C41B98A6A762007F5D001D8DC97@GBNTHT12009MSX.gb002.siemens.net> <4a005ef6.1358560a.4934.ffffae26@mx.google.com> <0DB94A632EC341CA965EF492749980C1@china.huawei.com> <4a007227.1438560a.1123.ffffef61@mx.google.com> <89DD91D94A684E29A915B2F9E243EE70@china.huawei.com> Cc: avt@ietf.org Subject: Re: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 22:16:32 -0000 If level upgrade in SDP answer is allowed in the bis draft, then if the offerer is a legacy device, it may consider the answer as illegal. Is the benefit of allowing this big enough to compensate the introduced interoperability issue? BR,YK > -----Original Message----- > From: Randell Jesup [mailto:rjesup@wgate.com] > Sent: Wednesday, May 06, 2009 5:12 PM > To: Ye-Kui Wang > Cc: 'Roni Even'; 'Elwell, John'; avt@ietf.org > Subject: Re: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - > Profile level > > Ye-Kui Wang writes: > >My understanding is that in RFC 3984 the intention was to allow for > >level downgrade in SDP offer/answer, but there is some > inconsistence in > >that regard and the bis draft clarified the issue. > > That's correct - Level downgrade was unofficially > added/clarified long before the 3984bis effort began. > > Note that level upgrade would interact (yet again!) with > sprop-parameter-sets, though the solution found for 3984bis > should work. > (I haven't worked out hte use cases; just a gut feeling that > it will work.) > > As mentioned, it would seem that level upgrade would only > help in the case of an endpoint that can encode at a higher > level than it can/is willing to decode. > > If encode level == decode level, then offer that. Note that > hardware may be able to in theor decode a higher level, but > the device may not be able to use the extra resolution and/or > framerate. > > If encode level < decode level (common), then offer the > decode level, and send using the encode level. There are > some gotchas with this though: > a) We're assuming the answerer understands how to level-downgrade > b) If using sprop-parameter-sets, we'll want to offer > parameter sets for > multiple levels (as per 3984bis). Care will need to be taken to > ensure compatibility with 3984 endpoints (as is the > norm for 3984bis). > > This is basically normal 3984bis activity. > > If encode level > decode level (odd - the only cases I can > think of that makes sense are: hardware encoder but no hw > decoder (weird); pre-encoded outbound video (unusual case); > larger sensor than display (example: 1MP sensor and encode > ability, but a 640x480 display) - this is the only likely > case. I suggest in that case, if possible, implement a > post-decode scale and offer the encode level. If that's not > sufficient, then we have the tough case. Options are: > a) level upgrade on answer (not currently allowed, and now > being requested) > b) limit answer to offer (wastes camera resolution) > c) use two m= lines - but this is an "answer" case, and we > can't *add* > m-lines, so this only works if two were offered, so this really > doesn't help much. Also, if offering two m= lines, > you're likely to > have real problems with devices that *don't* know how > you're using > the two streams. Almost all devices will ignore the > second stream. > > My suggestion: offer the encoder level, and scale any > received video. It's not an optimum solution, but it retains > much more compatibility that other solutions. > > Alternate if you really want to save bits: add an extension > in an offer to the fmtp, level-upgrade-allowed=1. We *could* > add that to 3984bis without too many nasty ramifications, I think. > > -- > Randell Jesup, Worldgate (developers of the Ojo videophone), > ex-Amiga OS team rjesup@wgate.com "The fetters imposed on > liberty at home have ever been forged out of the weapons > provided for defence against real, pretended, or imaginary > dangers from abroad." > - James Madison, 4th US president (1751-1836) > > From rjesup@wgate.com Wed May 6 18:59:14 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 081373A6933 for ; Wed, 6 May 2009 18:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.528 X-Spam-Level: X-Spam-Status: No, score=-1.528 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4m-6g7fYdTyA for ; Wed, 6 May 2009 18:59:13 -0700 (PDT) Received: from exchange1.wgate.com (pr-66-150-46-254.wgate.com [66.150.46.254]) by core3.amsl.com (Postfix) with ESMTP id C66463A6ACC for ; Wed, 6 May 2009 18:59:12 -0700 (PDT) Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 May 2009 22:00:39 -0400 To: Ye-Kui Wang References: <49ff59e6.1358560a.4af5.05e3@mx.google.com> <089AD8684C5E4C2995F01C2527EE7081@china.huawei.com> <0D5F89FAC29E2C41B98A6A762007F5D001D8DC97@GBNTHT12009MSX.gb002.siemens.net> <4a005ef6.1358560a.4934.ffffae26@mx.google.com> <0DB94A632EC341CA965EF492749980C1@china.huawei.com> <4a007227.1438560a.1123.ffffef61@mx.google.com> <89DD91D94A684E29A915B2F9E243EE70@china.huawei.com> <641DD488A4FF471C9CB4815F6518E883@china.huawei.com> From: Randell Jesup Date: Wed, 06 May 2009 22:02:28 -0400 In-Reply-To: <641DD488A4FF471C9CB4815F6518E883@china.huawei.com> (Ye-Kui Wang's message of "Wed\, 06 May 2009 18\:17\:30 -0400") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 07 May 2009 02:00:39.0849 (UTC) FILETIME=[9EFD0990:01C9CEB7] Cc: avt@ietf.org Subject: Re: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Randell Jesup List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 01:59:14 -0000 Ye-Kui Wang writes: >If level upgrade in SDP answer is allowed in the bis draft, then if the >offerer is a legacy device, it may consider the answer as illegal. Is the >benefit of allowing this big enough to compensate the introduced >interoperability issue? There's no legacy issue if level upgrade is enabled by the offerer adding "level-upgrade-allowed=1" (or if there's something else the answer can key off). If the offerer included that, they support it. If not (or 0), the answerer must not upgrade the level. If we decide to do something like this, we could either require supporting level upgrade always (MUST add the fmtp parameter if you're 3984bis-compliant), or allow it only when the offerer wants to support it (add it at the discretion of the offerer). >BR,YK > >> -----Original Message----- >> From: Randell Jesup [mailto:rjesup@wgate.com] >> Sent: Wednesday, May 06, 2009 5:12 PM >> To: Ye-Kui Wang >> Cc: 'Roni Even'; 'Elwell, John'; avt@ietf.org >> Subject: Re: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - >> Profile level >> >> Ye-Kui Wang writes: >> >My understanding is that in RFC 3984 the intention was to allow for >> >level downgrade in SDP offer/answer, but there is some >> inconsistence in >> >that regard and the bis draft clarified the issue. >> >> That's correct - Level downgrade was unofficially >> added/clarified long before the 3984bis effort began. >> >> Note that level upgrade would interact (yet again!) with >> sprop-parameter-sets, though the solution found for 3984bis >> should work. >> (I haven't worked out hte use cases; just a gut feeling that >> it will work.) >> >> As mentioned, it would seem that level upgrade would only >> help in the case of an endpoint that can encode at a higher >> level than it can/is willing to decode. >> >> If encode level == decode level, then offer that. Note that >> hardware may be able to in theor decode a higher level, but >> the device may not be able to use the extra resolution and/or >> framerate. >> >> If encode level < decode level (common), then offer the >> decode level, and send using the encode level. There are >> some gotchas with this though: >> a) We're assuming the answerer understands how to level-downgrade >> b) If using sprop-parameter-sets, we'll want to offer >> parameter sets for >> multiple levels (as per 3984bis). Care will need to be taken to >> ensure compatibility with 3984 endpoints (as is the >> norm for 3984bis). >> >> This is basically normal 3984bis activity. >> >> If encode level > decode level (odd - the only cases I can >> think of that makes sense are: hardware encoder but no hw >> decoder (weird); pre-encoded outbound video (unusual case); >> larger sensor than display (example: 1MP sensor and encode >> ability, but a 640x480 display) - this is the only likely >> case. I suggest in that case, if possible, implement a >> post-decode scale and offer the encode level. If that's not >> sufficient, then we have the tough case. Options are: >> a) level upgrade on answer (not currently allowed, and now >> being requested) >> b) limit answer to offer (wastes camera resolution) >> c) use two m= lines - but this is an "answer" case, and we >> can't *add* >> m-lines, so this only works if two were offered, so this really >> doesn't help much. Also, if offering two m= lines, >> you're likely to >> have real problems with devices that *don't* know how >> you're using >> the two streams. Almost all devices will ignore the >> second stream. >> >> My suggestion: offer the encoder level, and scale any >> received video. It's not an optimum solution, but it retains >> much more compatibility that other solutions. >> >> Alternate if you really want to save bits: add an extension >> in an offer to the fmtp, level-upgrade-allowed=1. We *could* >> add that to 3984bis without too many nasty ramifications, I think. >> >> -- >> Randell Jesup, Worldgate (developers of the Ojo videophone), >> ex-Amiga OS team rjesup@wgate.com "The fetters imposed on >> liberty at home have ever been forged out of the weapons >> provided for defence against real, pretended, or imaginary >> dangers from abroad." >> - James Madison, 4th US president (1751-1836) >> >> -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com "The fetters imposed on liberty at home have ever been forged out of the weapons provided for defence against real, pretended, or imaginary dangers from abroad." - James Madison, 4th US president (1751-1836) From yekuiwang@huawei.com Wed May 6 19:11:46 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83AA93A6A22 for ; Wed, 6 May 2009 19:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZMLrkDY-jBRd for ; Wed, 6 May 2009 19:11:45 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 830A73A6E10 for ; Wed, 6 May 2009 19:10:43 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJ900EHM4SA1F@usaga04-in.huawei.com> for avt@ietf.org; Wed, 06 May 2009 21:12:11 -0500 (CDT) Received: from W90946 ([10.51.0.9]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJ9001AC4S576@usaga04-in.huawei.com> for avt@ietf.org; Wed, 06 May 2009 21:12:10 -0500 (CDT) Date: Wed, 06 May 2009 22:12:05 -0400 From: Ye-Kui Wang In-reply-to: <641DD488A4FF471C9CB4815F6518E883@china.huawei.com> To: 'Randell Jesup' Message-id: <12353240859745DA9EE245BCE39FA679@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcnOj+OLgOLMBbf6RSqkhfbBbIl/kQAB7ALAAAX5DdA= References: <49ff59e6.1358560a.4af5.05e3@mx.google.com> <089AD8684C5E4C2995F01C2527EE7081@china.huawei.com> <0D5F89FAC29E2C41B98A6A762007F5D001D8DC97@GBNTHT12009MSX.gb002.siemens.net> <4a005ef6.1358560a.4934.ffffae26@mx.google.com> <0DB94A632EC341CA965EF492749980C1@china.huawei.com> <4a007227.1438560a.1123.ffffef61@mx.google.com> <89DD91D94A684E29A915B2F9E243EE70@china.huawei.com> <641DD488A4FF471C9CB4815F6518E883@china.huawei.com> Cc: avt@ietf.org Subject: Re: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 02:11:46 -0000 Furthermore, to use one m= line to represent different levels (as capabilities) for sending and receiving, you would need two level parameters. BR, YK > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > Behalf Of Ye-Kui Wang > Sent: Wednesday, May 06, 2009 6:18 PM > To: 'Randell Jesup' > Cc: avt@ietf.org > Subject: Re: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - > Profile level > > > If level upgrade in SDP answer is allowed in the bis draft, > then if the offerer is a legacy device, it may consider the > answer as illegal. Is the benefit of allowing this big enough > to compensate the introduced interoperability issue? > > BR,YK > > > -----Original Message----- > > From: Randell Jesup [mailto:rjesup@wgate.com] > > Sent: Wednesday, May 06, 2009 5:12 PM > > To: Ye-Kui Wang > > Cc: 'Roni Even'; 'Elwell, John'; avt@ietf.org > > Subject: Re: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile > > level > > > > Ye-Kui Wang writes: > > >My understanding is that in RFC 3984 the intention was to > allow for > > >level downgrade in SDP offer/answer, but there is some > > inconsistence in > > >that regard and the bis draft clarified the issue. > > > > That's correct - Level downgrade was unofficially > added/clarified long > > before the 3984bis effort began. > > > > Note that level upgrade would interact (yet again!) with > > sprop-parameter-sets, though the solution found for 3984bis should > > work. > > (I haven't worked out hte use cases; just a gut feeling > that it will > > work.) > > > > As mentioned, it would seem that level upgrade would only > help in the > > case of an endpoint that can encode at a higher level than > it can/is > > willing to decode. > > > > If encode level == decode level, then offer that. Note > that hardware > > may be able to in theor decode a higher level, but the > device may not > > be able to use the extra resolution and/or framerate. > > > > If encode level < decode level (common), then offer the > decode level, > > and send using the encode level. There are some gotchas with this > > though: > > a) We're assuming the answerer understands how to level-downgrade > > b) If using sprop-parameter-sets, we'll want to offer parameter > > sets for > > multiple levels (as per 3984bis). Care will need to > be taken to > > ensure compatibility with 3984 endpoints (as is the norm for > > 3984bis). > > > > This is basically normal 3984bis activity. > > > > If encode level > decode level (odd - the only cases I can think of > > that makes sense are: hardware encoder but no hw decoder (weird); > > pre-encoded outbound video (unusual case); larger sensor > than display > > (example: 1MP sensor and encode ability, but a 640x480 > display) - this > > is the only likely case. I suggest in that case, if possible, > > implement a post-decode scale and offer the encode level. > If that's > > not sufficient, then we have the tough case. Options are: > > a) level upgrade on answer (not currently allowed, and now being > > requested) > > b) limit answer to offer (wastes camera resolution) > > c) use two m= lines - but this is an "answer" case, and we can't > > *add* > > m-lines, so this only works if two were offered, so > this really > > doesn't help much. Also, if offering two m= lines, you're > > likely to > > have real problems with devices that *don't* know how you're > > using > > the two streams. Almost all devices will ignore the second > > stream. > > > > My suggestion: offer the encoder level, and scale any > received video. > > It's not an optimum solution, but it retains much more > compatibility > > that other solutions. > > > > Alternate if you really want to save bits: add an extension in an > > offer to the fmtp, level-upgrade-allowed=1. We *could* add that to > > 3984bis without too many nasty ramifications, I think. > > > > -- > > Randell Jesup, Worldgate (developers of the Ojo > videophone), ex-Amiga > > OS team rjesup@wgate.com "The fetters imposed on liberty at > home have > > ever been forged out of the weapons provided for defence > against real, > > pretended, or imaginary dangers from abroad." > > - James Madison, 4th US president (1751-1836) > > > > > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > From jaehwan@vidiator.com Wed May 6 20:12:32 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA71B3A69E9 for ; Wed, 6 May 2009 20:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.971 X-Spam-Level: X-Spam-Status: No, score=-1.971 tagged_above=-999 required=5 tests=[AWL=0.628, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8+FGROXoE6Z6 for ; Wed, 6 May 2009 20:12:32 -0700 (PDT) Received: from kor1corpmail01.mediator.com (vkimail.vidiator.com [211.189.53.2]) by core3.amsl.com (Postfix) with ESMTP id A3D153A69C4 for ; Wed, 6 May 2009 20:12:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Thu, 7 May 2009 12:13:57 +0900 Message-ID: In-Reply-To: <57a9e15d0905060958k48c816a6id1bb3690648dee5b@mail.gmail.com> References: <6D5990B2-9100-4AC8-89D3-BDEE27A002E5@apple.com><31d1be720905050856x1819d8f4wda97866f922043b0@mail.gmail.com><57a9e15d0905050958p210db525qb058fd62d6ea7073@mail.gmail.com><38c19b540905060138i35ce99b9q4fac697ebe451ced@mail.gmail.com> <57a9e15d0905060958k48c816a6id1bb3690648dee5b@mail.gmail.com> From: "Jaehwan Kim" To: "Alex Giladi" , Cc: http-live-streaming-review@group.apple.com, avt@ietf.org Subject: Re: [AVT] iPhone streaming Internet-Draft posted X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 03:12:32 -0000 aHR0cDovL2RldmVsb3Blci5hcHBsZS5jb20vcXVpY2t0aW1lL2ljZWZsb2UvZGlzcGF0Y2gwMjgu aHRtbA0KDQpQcm9wb3NlZCBsaXZlIEhUVFAgc3RyZWFtaW5nIGJhc2VkIG9uIE1QRUctMiBUUyBs b29rcyBub3QgYmFkLg0KSSBndWVzcyBzdGlsbCBJRVRGIGRvZXNuJ3QgbGlrZSBhIHNvbHV0aW9u IG92ZXJ1c2luZyBIVFRQIHBvcnQsIGJ1dCBhbiBlbmQtdXNlciBzZWVtcyB0byBsaWtlIGEgaGln aCByZXNvbHV0aW9uIHZpZGVvIGJ1dCBubyBsb3NzLCB3aGF0ZXZlciB3ZSB1c2UgYmVoaW5kLiAN Cg0KSmFlaHdhbg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBhdnQtYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmF2dC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg QWxleCBHaWxhZGkNClNlbnQ6IFRodXJzZGF5LCBNYXkgMDcsIDIwMDkgMTo1OCBBTQ0KVG86IGdq c2hlcEBnbWFpbC5jb20NCkNjOiBodHRwLWxpdmUtc3RyZWFtaW5nLXJldmlld0Bncm91cC5hcHBs ZS5jb207IGF2dEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtBVlRdIGlQaG9uZSBzdHJlYW1pbmcg SW50ZXJuZXQtRHJhZnQgcG9zdGVkDQoNCklzIHRoZXJlIGFuIFJUU1Atb3Zlci1IVFRQIHNwZWM/ DQoNCg== From abegen@cisco.com Wed May 6 20:35:09 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56CE328C0DC for ; Wed, 6 May 2009 20:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.402 X-Spam-Level: X-Spam-Status: No, score=-6.402 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4UAoWKRx+lNN for ; Wed, 6 May 2009 20:35:08 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id DF99228C256 for ; Wed, 6 May 2009 20:35:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,306,1238976000"; d="scan'208";a="162752667" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 07 May 2009 03:36:35 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n473aZt9024489; Wed, 6 May 2009 20:36:35 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n473aZtB020191; Thu, 7 May 2009 03:36:35 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 May 2009 20:36:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 May 2009 20:36:30 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540943C031@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] iPhone streaming Internet-Draft posted Thread-Index: AcnOweBflUs/wL87Rm6SCIO3DVYy4gAAwWDg References: <6D5990B2-9100-4AC8-89D3-BDEE27A002E5@apple.com><31d1be720905050856x1819d8f4wda97866f922043b0@mail.gmail.com><57a9e15d0905050958p210db525qb058fd62d6ea7073@mail.gmail.com><38c19b540905060138i35ce99b9q4fac697ebe451ced@mail.gmail.com><57a9e15d0905060958k48c816a6id1bb3690648dee5b@mail.gmail.com> From: "Ali C. Begen (abegen)" To: "Jaehwan Kim" , "Alex Giladi" , X-OriginalArrivalTime: 07 May 2009 03:36:35.0607 (UTC) FILETIME=[05B00270:01C9CEC5] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1219; t=1241667395; x=1242531395; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20RE=3A=20[AVT]=20iPhone=20streaming=20Internet-D raft=20posted |Sender:=20; bh=ZUPI+tACdHNVtay5PLe9EjiDOny2VdAfYsW/61g5Imo=; b=bcLo73SYSkJS6tdk3VypzwePU7JtwweXNtZlO7JEP4Xw3S3pb46M7FhGrZ gEPDlQro8wsjElojmRwGdCkAK1dmhoYZXc+f6RAhzC3kSed2s5h/dHPsB8km xJF/00i9U2; Authentication-Results: sj-dkim-4; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: http-live-streaming-review@group.apple.com, avt@ietf.org Subject: Re: [AVT] iPhone streaming Internet-Draft posted X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 03:35:09 -0000 Where does it say that it uses MPEG2 TS? -acbegen > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Jaehwan Kim > Sent: Wednesday, May 06, 2009 8:14 PM > To: Alex Giladi; gjshep@gmail.com > Cc: http-live-streaming-review@group.apple.com; avt@ietf.org > Subject: Re: [AVT] iPhone streaming Internet-Draft posted >=20 > http://developer.apple.com/quicktime/icefloe/dispatch028.html >=20 > Proposed live HTTP streaming based on MPEG-2 TS looks not bad. > I guess still IETF doesn't like a solution overusing HTTP port, but an = end-user seems to > like a high resolution video but no loss, whatever we use behind. >=20 > Jaehwan >=20 >=20 > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Alex Giladi > Sent: Thursday, May 07, 2009 1:58 AM > To: gjshep@gmail.com > Cc: http-live-streaming-review@group.apple.com; avt@ietf.org > Subject: Re: [AVT] iPhone streaming Internet-Draft posted >=20 > Is there an RTSP-over-HTTP spec? >=20 > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From jaehwan@vidiator.com Wed May 6 21:48:04 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B40CE28C209 for ; Wed, 6 May 2009 21:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.72 X-Spam-Level: X-Spam-Status: No, score=-1.72 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTD1WMGSiTOP for ; Wed, 6 May 2009 21:48:03 -0700 (PDT) Received: from kor1corpmail01.mediator.com (vkimail.vidiator.com [211.189.53.2]) by core3.amsl.com (Postfix) with ESMTP id 130BC28B23E for ; Wed, 6 May 2009 21:48:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 May 2009 13:49:20 +0900 Message-ID: In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540943C031@xmb-sjc-215.amer.cisco.com> References: <6D5990B2-9100-4AC8-89D3-BDEE27A002E5@apple.com><31d1be720905050856x1819d8f4wda97866f922043b0@mail.gmail.com><57a9e15d0905050958p210db525qb058fd62d6ea7073@mail.gmail.com><38c19b540905060138i35ce99b9q4fac697ebe451ced@mail.gmail.com><57a9e15d0905060958k48c816a6id1bb3690648dee5b@mail.gmail.com> <04CAD96D4C5A3D48B1919248A8FE0D540943C031@xmb-sjc-215.amer.cisco.com> From: "Jaehwan Kim" To: "Ali C. Begen (abegen)" , "Alex Giladi" , Cc: http-live-streaming-review@group.apple.com, avt@ietf.org Subject: Re: [AVT] iPhone streaming Internet-Draft posted X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 04:48:04 -0000 Section 4 of the below one(the subject indicates this). http://www.ietf.org/internet-drafts/draft-pantos-http-live-streaming-00. txt Jaehwan -----Original Message----- From: Ali C. Begen (abegen) [mailto:abegen@cisco.com]=20 Sent: Thursday, May 07, 2009 12:37 PM To: Jaehwan Kim; Alex Giladi; gjshep@gmail.com Cc: http-live-streaming-review@group.apple.com; avt@ietf.org Subject: RE: [AVT] iPhone streaming Internet-Draft posted Where does it say that it uses MPEG2 TS? -acbegen > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Jaehwan Kim > Sent: Wednesday, May 06, 2009 8:14 PM > To: Alex Giladi; gjshep@gmail.com > Cc: http-live-streaming-review@group.apple.com; avt@ietf.org > Subject: Re: [AVT] iPhone streaming Internet-Draft posted >=20 > http://developer.apple.com/quicktime/icefloe/dispatch028.html >=20 > Proposed live HTTP streaming based on MPEG-2 TS looks not bad. > I guess still IETF doesn't like a solution overusing HTTP port, but an end-user seems to > like a high resolution video but no loss, whatever we use behind. >=20 > Jaehwan >=20 >=20 > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Alex Giladi > Sent: Thursday, May 07, 2009 1:58 AM > To: gjshep@gmail.com > Cc: http-live-streaming-review@group.apple.com; avt@ietf.org > Subject: Re: [AVT] iPhone streaming Internet-Draft posted >=20 > Is there an RTSP-over-HTTP spec? >=20 > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From rjesup@wgate.com Thu May 7 06:38:37 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 532003A6E6B for ; Thu, 7 May 2009 06:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVRiCOQdyAic for ; Thu, 7 May 2009 06:38:36 -0700 (PDT) Received: from exchange1.wgate.com (pr-66-150-46-254.wgate.com [66.150.46.254]) by core3.amsl.com (Postfix) with ESMTP id 71F763A6CDE for ; Thu, 7 May 2009 06:38:36 -0700 (PDT) Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 May 2009 09:40:03 -0400 To: Ye-Kui Wang References: <49ff59e6.1358560a.4af5.05e3@mx.google.com> <089AD8684C5E4C2995F01C2527EE7081@china.huawei.com> <0D5F89FAC29E2C41B98A6A762007F5D001D8DC97@GBNTHT12009MSX.gb002.siemens.net> <4a005ef6.1358560a.4934.ffffae26@mx.google.com> <0DB94A632EC341CA965EF492749980C1@china.huawei.com> <4a007227.1438560a.1123.ffffef61@mx.google.com> <89DD91D94A684E29A915B2F9E243EE70@china.huawei.com> <641DD488A4FF471C9CB4815F6518E883@china.huawei.com> <12353240859745DA9EE245BCE39FA679@china.huawei.com> From: Randell Jesup Date: Thu, 07 May 2009 09:41:53 -0400 In-Reply-To: <12353240859745DA9EE245BCE39FA679@china.huawei.com> (Ye-Kui Wang's message of "Wed\, 06 May 2009 22\:12\:05 -0400") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 07 May 2009 13:40:03.0459 (UTC) FILETIME=[533FC530:01C9CF19] Cc: avt@ietf.org Subject: Re: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Randell Jesup List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 13:38:37 -0000 Ye-Kui Wang writes: >Furthermore, to use one m= line to represent different levels (as >capabilities) for sending and receiving, you would need two level >parameters. This is no different than supporting level downgrade. If you're using in-band parameter sets, those carry the actual level within them. If you're using out-of-band parameter sets, those are "send" parameters. So an offerer who supports allow-level-upgrade=1 would include in sprop-level-parameter-sets levels above the offer level, up to the maximum sending level the offerer supports. -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com "The fetters imposed on liberty at home have ever been forged out of the weapons provided for defence against real, pretended, or imaginary dangers from abroad." - James Madison, 4th US president (1751-1836) From yekuiwang@huawei.com Thu May 7 07:58:43 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 294553A70E3 for ; Thu, 7 May 2009 07:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rqicDPvD+cGW for ; Thu, 7 May 2009 07:58:42 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 613F228C2A5 for ; Thu, 7 May 2009 07:58:42 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJA00A4M4C3CD@usaga04-in.huawei.com> for avt@ietf.org; Thu, 07 May 2009 10:00:04 -0500 (CDT) Received: from W90946 ([10.193.125.102]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJA007M64BXJG@usaga04-in.huawei.com> for avt@ietf.org; Thu, 07 May 2009 10:00:03 -0500 (CDT) Date: Thu, 07 May 2009 10:59:57 -0400 From: Ye-Kui Wang In-reply-to: To: 'Randell Jesup' Message-id: <5FFF670DD3954D21B977BA0F48460E49@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcnPGZbsk9CURt5uRuikHQT+3hnefwACNwoQ References: <49ff59e6.1358560a.4af5.05e3@mx.google.com> <089AD8684C5E4C2995F01C2527EE7081@china.huawei.com> <0D5F89FAC29E2C41B98A6A762007F5D001D8DC97@GBNTHT12009MSX.gb002.siemens.net> <4a005ef6.1358560a.4934.ffffae26@mx.google.com> <0DB94A632EC341CA965EF492749980C1@china.huawei.com> <4a007227.1438560a.1123.ffffef61@mx.google.com> <89DD91D94A684E29A915B2F9E243EE70@china.huawei.com> <641DD488A4FF471C9CB4815F6518E883@china.huawei.com> <12353240859745DA9EE245BCE39FA679@china.huawei.com> Cc: avt@ietf.org Subject: Re: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 14:58:43 -0000 The word "parameters in "two level parameters" did not mean "parameter sets" :-) To establish an asymmetric (in spatial resolution and level) video communication session between two entities, wherein one side wants to send at a lower level (say, QCIF) but receive at a higher level (say, CIF), while the other side wants to send at CIF and receive at QCIF. Then both the offer and the answer should contain two level parameters, level_a and level_b (level_a < level_b), to indicate the sending and receiving (or reversely) capabilities (or preferences). Simply adding allow-level-upgrade is not clear to me. Assuming that both sides indicate allow-level-upgrade = 1. If the answer contains a higher level, then what is the highest level to use in the direction from the offerer to the answerer and what is the highest level to use in the other direction? The same question applies when the answer contains a lower level. BR, YK > -----Original Message----- > From: Randell Jesup [mailto:rjesup@wgate.com] > Sent: Thursday, May 07, 2009 9:42 AM > To: Ye-Kui Wang > Cc: avt@ietf.org > Subject: Re: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - > Profile level > > Ye-Kui Wang writes: > >Furthermore, to use one m= line to represent different levels (as > >capabilities) for sending and receiving, you would need two level > >parameters. > > This is no different than supporting level downgrade. If > you're using in-band parameter sets, those carry the actual > level within them. If you're using out-of-band parameter > sets, those are "send" parameters. So an offerer who > supports allow-level-upgrade=1 would include in > sprop-level-parameter-sets levels above the offer level, up > to the maximum sending level the offerer supports. > > -- > Randell Jesup, Worldgate (developers of the Ojo videophone), > ex-Amiga OS team rjesup@wgate.com "The fetters imposed on > liberty at home have ever been forged out of the weapons > provided for defence against real, pretended, or imaginary > dangers from abroad." > - James Madison, 4th US president (1751-1836) > > From gherlein@herlein.com Thu May 7 08:05:34 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D992D28C2BF for ; Thu, 7 May 2009 08:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.267 X-Spam-Level: X-Spam-Status: No, score=-1.267 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+pR0rz4Hqh6 for ; Thu, 7 May 2009 08:05:33 -0700 (PDT) Received: from mail-qy0-f195.google.com (mail-qy0-f195.google.com [209.85.221.195]) by core3.amsl.com (Postfix) with ESMTP id CB04528C2AE for ; Thu, 7 May 2009 08:05:31 -0700 (PDT) Received: by qyk33 with SMTP id 33so1390818qyk.29 for ; Thu, 07 May 2009 08:06:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.44.11 with SMTP id r11mr999867wfr.145.1241708813290; Thu, 07 May 2009 08:06:53 -0700 (PDT) In-Reply-To: References: <6D5990B2-9100-4AC8-89D3-BDEE27A002E5@apple.com> <31d1be720905050856x1819d8f4wda97866f922043b0@mail.gmail.com> <57a9e15d0905050958p210db525qb058fd62d6ea7073@mail.gmail.com> <38c19b540905060138i35ce99b9q4fac697ebe451ced@mail.gmail.com> <57a9e15d0905060958k48c816a6id1bb3690648dee5b@mail.gmail.com> <04CAD96D4C5A3D48B1919248A8FE0D540943C031@xmb-sjc-215.amer.cisco.com> Date: Thu, 7 May 2009 08:06:53 -0700 Message-ID: <31d1be720905070806v3f4c376fx2fab65117739f713@mail.gmail.com> From: Greg Herlein To: Jaehwan Kim Content-Type: multipart/alternative; boundary=000e0cd311a2bb0ceb046953dcd8 Cc: http-live-streaming-review@group.apple.com, avt@ietf.org Subject: Re: [AVT] iPhone streaming Internet-Draft posted X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 15:05:34 -0000 --000e0cd311a2bb0ceb046953dcd8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I still think we don't understand the problem that is trying to be solved. Aside from the core problem that is is a redundant protocol, I don't grok some of the small details, like: - in 6.1: "The server MUST divide the stream into individual media files whose duration is approximately equal" - why? - in 6.1: "The server MUST create a URI for each media file that will allow its clients to obtain the file." - why? Divide the stream into many files and then the client has to know the file names and ask one by one? - in 2.0: "To play the stream, the client first obtains the Playlist file and then obtains and plays each media file in the Playlist. It reloads the Playlist file as described in this document to discover additional segments." - in 6.1: "The server MUST create a Playlist file. The Playlist file MUST conform to the format described in Section 3." - in 3.0: "Playlists MUST be Extended M3U Playlist files [M3U]. This document extends the M3U file format by defining additional tags." - so you take an audio playlist format and extend it instead of using something like SMIL? Why? - you specify a means to reload a playlist but not to signal a client that there is a new playlist - so you poll. Poor form. In general, this protocol seems poorly thought out and appears to be trying to solve a problem that has already been solved. RTSP covers everything this does, and supports trick play (this does not). And provides a means to cover AV protocols other than MPEG2. Unless we don't understand the problem trying to be solved? Greg On Wed, May 6, 2009 at 9:49 PM, Jaehwan Kim wrote: > Section 4 of the below one(the subject indicates this). > http://www.ietf.org/internet-drafts/draft-pantos-http-live-streaming-00. > txt > > Jaehwan > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > Sent: Thursday, May 07, 2009 12:37 PM > To: Jaehwan Kim; Alex Giladi; gjshep@gmail.com > Cc: http-live-streaming-review@group.apple.com; avt@ietf.org > Subject: RE: [AVT] iPhone streaming Internet-Draft posted > > Where does it say that it uses MPEG2 TS? > > -acbegen > > > -----Original Message----- > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Jaehwan Kim > > Sent: Wednesday, May 06, 2009 8:14 PM > > To: Alex Giladi; gjshep@gmail.com > > Cc: http-live-streaming-review@group.apple.com; avt@ietf.org > > Subject: Re: [AVT] iPhone streaming Internet-Draft posted > > > > http://developer.apple.com/quicktime/icefloe/dispatch028.html > > > > Proposed live HTTP streaming based on MPEG-2 TS looks not bad. > > I guess still IETF doesn't like a solution overusing HTTP port, but an > end-user seems to > > like a high resolution video but no loss, whatever we use behind. > > > > Jaehwan > > > > > > -----Original Message----- > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Alex Giladi > > Sent: Thursday, May 07, 2009 1:58 AM > > To: gjshep@gmail.com > > Cc: http-live-streaming-review@group.apple.com; avt@ietf.org > > Subject: Re: [AVT] iPhone streaming Internet-Draft posted > > > > Is there an RTSP-over-HTTP spec? > > > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > -- Greg Herlein www.herlein.com --000e0cd311a2bb0ceb046953dcd8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I still think we d= on't understand the problem that is trying to be solved.=A0 Aside from = the core problem that is is a redundant protocol, I don't grok some of = the small details, like:

- in 6.1: "The server MUST divide= the stream into individual media files whose duration is approximately e= qual"
=A0 - why?<= br style=3D"font-family: arial,helvetica,sans-serif;">
- in 6.1: "The server MUST create a=
 URI for each media file that will allow its clients to obtain the file.&qu=
ot;

  - why? Divide the stream into many files and then the client has to know =
the file names and ask one by one?
- in 2.0: "To play the stream, the client fi= rst obtains the Playlist file and then obtains and plays each media file = in the Playlist. It reloads the Playlist file as described in this docum= ent to discover additional segments."

=A0- in 6.1: "The server MUST cre= ate a Playlist file. The Playlist file MUST conform to the format descri= bed in Section 3."
=A0- in 3.0: "= ;Playlists MUST be Extended M3U Playlist files [M3U]. This document exte= nds the M3U file format by defining additional tags."
=A0=A0=A0 - so you= take an audio playlist format and extend it instead of using something lik= e SMIL?=A0 Why?
- you specify a me= ans to reload a playlist but not to signal a client that there is a new pla= ylist - so you poll.=A0 Poor form.

In general, this protocol seems poorly thoug= ht out and appears to be trying to solve a problem that has already been so= lved.=A0 RTSP covers everything this does, and supports trick play (this do= es not).=A0 And provides a means to cover AV protocols other than MPEG2.
Unless we don't understand the problem trying to be solved?<= br style=3D"font-family: arial,helvetica,sans-serif;">
Greg




On Wed, May 6, 2009 a= t 9:49 PM, Jaehwan Kim <jaehwan@vidiator.com> wrote:
Section 4 of the below one(the subject indicates this).
http://www.ietf.org/internet-drafts/draft= -pantos-http-live-streaming-00.
txt

Jaehwan
-----Original Message-----
From: Ali C. Begen (abegen) [mailto:abe= gen@cisco.com]
Sent: Thursday, May 07, 2009 12:37 PM
To: Jaehwan Kim; Alex Giladi; gjshep@gm= ail.com
Cc: http-live= -streaming-review@group.apple.com; avt@= ietf.org
Subject: RE: [AVT] iPhone streaming= Internet-Draft posted

Where does it say that it uses MPEG2 TS?

-acbegen

> -----Original Message-----
> From: avt-bounces@ietf.org= [mailto:avt-bounces@ietf.org] = On Behalf Of
Jaehwan Kim
> Sent: Wednesday, May 06, 2009 8:14 PM
> To: Alex Giladi; gjshep@gmail.com<= /a>
> Cc: http= -live-streaming-review@group.apple.com; avt@ietf.org
> Subject: Re: [AVT] iPhone streaming Internet-Draft posted
>
> http://developer.apple.com/quicktime/icefloe/dispatch= 028.html
>
> Proposed live HTTP streaming based on MPEG-2 TS looks not bad.
> I guess still IETF doesn't like a solution overusing HTTP port, bu= t an
end-user seems to
> like a high resolution video but no loss, whatever we use behind.
>
> Jaehwan
>
>
> -----Original Message-----
> From: avt-bounces@ietf.org= [mailto:avt-bounces@ietf.org] = On Behalf Of
Alex Giladi
> Sent: Thursday, May 07, 2009 1:58 AM
> To: gjshep@gmail.com
> Cc: http= -live-streaming-review@group.apple.com; avt@ietf.org
> Subject: Re: [AVT] iPhone streaming Internet-Draft posted
>
> Is there an RTSP-over-HTTP spec?
>
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/avt



--
Greg Herlei= n
www.herlein.com
--000e0cd311a2bb0ceb046953dcd8-- From ron.even.tlv@gmail.com Thu May 7 08:27:08 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F9623A6B5F for ; Thu, 7 May 2009 08:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.031 X-Spam-Level: X-Spam-Status: No, score=-2.031 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mej15-ItA-SE for ; Thu, 7 May 2009 08:27:03 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id E3C5A3A6898 for ; Thu, 7 May 2009 08:27:02 -0700 (PDT) Received: by fxm2 with SMTP id 2so860138fxm.37 for ; Thu, 07 May 2009 08:28:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=R6Z65DFrWStB/NmjTX4fHlH5XmtAMgyQshNvhcpQEsc=; b=MA0qXT80LkZrWxhKkXWFghu9POKf3aY0ScwBkQqDXlyx4gCwEANJrsqFqf4N1old4S 3R+fA+kdu27NvQXiZO/8+aAELk4T/MXjGvjBbIDBK3zYZgp2oN61lVYMp78wWVOxMwX2 uUOmYbGugMV6XYvRL6qsukkfMDLW7iyigXsjU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=Sn/8YjyB1iLRsy8uj6/gtLiYYs2rZMOEJrTTBvkqKSpW/EIboQ6PagraZjZKrwmlXB mWjMb+jXxHGmiaXeULTrz8DPl8MgJfq8eJNbITlXChkl3zUFPbrrCW+qf4BJ3vw6vurb 3VSTbkrk45MDiq/XQC/zY+OQWPPxyIE94p9Yo= Received: by 10.103.49.12 with SMTP id b12mr1708112muk.65.1241710108809; Thu, 07 May 2009 08:28:28 -0700 (PDT) Received: from windows8d787f9 (bzq-79-176-114-85.red.bezeqint.net [79.176.114.85]) by mx.google.com with ESMTPS id n10sm522449mue.17.2009.05.07.08.28.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 07 May 2009 08:28:28 -0700 (PDT) From: "Roni Even" To: "'Ye-Kui Wang'" , "'Randell Jesup'" References: <49ff59e6.1358560a.4af5.05e3@mx.google.com> <089AD8684C5E4C2995F01C2527EE7081@china.huawei.com> <0D5F89FAC29E2C41B98A6A762007F5D001D8DC97@GBNTHT12009MSX.gb002.siemens.net> <4a005ef6.1358560a.4934.ffffae26@mx.google.com> <0DB94A632EC341CA965EF492749980C1@china.huawei.com> <4a007227.1438560a.1123.ffffef61@mx.google.com> <89DD91D94A684E29A915B2F9E243EE70@china.huawei.com> <641DD488A4FF471C9CB4815F6518E883@china.huawei.com> <12353240859745DA9EE245BCE39FA679@china.huawei.com> <5FFF670DD3954D21B977BA0F48460E49@china.huawei.com> In-Reply-To: <5FFF670DD3954D21B977BA0F48460E49@china.huawei.com> Date: Thu, 7 May 2009 18:28:15 +0300 Message-ID: <4a02fe1c.0aa5660a.5762.3a54@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnPGZbsk9CURt5uRuikHQT+3hnefwACNwoQAAFTGFA= Content-Language: en-us Cc: avt@ietf.org Subject: Re: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 15:27:08 -0000 YK, I think that the issue is not to establish an asymmetric communication where one sides sends qcif and the other cif. Using the level in the offer answer will not help for that since the level is a maximum so even if the offer says it can receive CIF the answerer can send him a qcif picture. What Ashish wants is to be able to declare a higher level in the answer. You can see the other thread I had with Magnus, I think it explains it better. For the case when an endpoint wants to receive a specific picture size you will need some request mechanism, example is by the image attribute draft in mmusic Roni -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ye-Kui Wang Sent: Thursday, May 07, 2009 6:00 PM To: 'Randell Jesup' Cc: avt@ietf.org Subject: Re: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level The word "parameters in "two level parameters" did not mean "parameter sets" :-) To establish an asymmetric (in spatial resolution and level) video communication session between two entities, wherein one side wants to send at a lower level (say, QCIF) but receive at a higher level (say, CIF), while the other side wants to send at CIF and receive at QCIF. Then both the offer and the answer should contain two level parameters, level_a and level_b (level_a < level_b), to indicate the sending and receiving (or reversely) capabilities (or preferences). Simply adding allow-level-upgrade is not clear to me. Assuming that both sides indicate allow-level-upgrade = 1. If the answer contains a higher level, then what is the highest level to use in the direction from the offerer to the answerer and what is the highest level to use in the other direction? The same question applies when the answer contains a lower level. BR, YK > -----Original Message----- > From: Randell Jesup [mailto:rjesup@wgate.com] > Sent: Thursday, May 07, 2009 9:42 AM > To: Ye-Kui Wang > Cc: avt@ietf.org > Subject: Re: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - > Profile level > > Ye-Kui Wang writes: > >Furthermore, to use one m= line to represent different levels (as > >capabilities) for sending and receiving, you would need two level > >parameters. > > This is no different than supporting level downgrade. If > you're using in-band parameter sets, those carry the actual > level within them. If you're using out-of-band parameter > sets, those are "send" parameters. So an offerer who > supports allow-level-upgrade=1 would include in > sprop-level-parameter-sets levels above the offer level, up > to the maximum sending level the offerer supports. > > -- > Randell Jesup, Worldgate (developers of the Ojo videophone), > ex-Amiga OS team rjesup@wgate.com "The fetters imposed on > liberty at home have ever been forged out of the weapons > provided for defence against real, pretended, or imaginary > dangers from abroad." > - James Madison, 4th US president (1751-1836) > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www.ietf.org/mailman/listinfo/avt From yekuiwang@huawei.com Thu May 7 08:38:09 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6220C3A6DE3 for ; Thu, 7 May 2009 08:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.216 X-Spam-Level: X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LIenL+4iYSJD for ; Thu, 7 May 2009 08:38:08 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 6A3193A6CEC for ; Thu, 7 May 2009 08:38:08 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJA00IHD65ZYB@usaga02-in.huawei.com> for avt@ietf.org; Thu, 07 May 2009 08:39:35 -0700 (PDT) Received: from W90946 ([10.193.125.102]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJA00J2Z65ULW@usaga02-in.huawei.com> for avt@ietf.org; Thu, 07 May 2009 08:39:34 -0700 (PDT) Date: Thu, 07 May 2009 11:39:30 -0400 From: Ye-Kui Wang In-reply-to: <4a02fe1c.0aa5660a.5762.3a54@mx.google.com> To: 'Roni Even' , 'Randell Jesup' Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcnPGZbsk9CURt5uRuikHQT+3hnefwACNwoQAAFTGFAAAIuAAA== References: <49ff59e6.1358560a.4af5.05e3@mx.google.com> <089AD8684C5E4C2995F01C2527EE7081@china.huawei.com> <0D5F89FAC29E2C41B98A6A762007F5D001D8DC97@GBNTHT12009MSX.gb002.siemens.net> <4a005ef6.1358560a.4934.ffffae26@mx.google.com> <0DB94A632EC341CA965EF492749980C1@china.huawei.com> <4a007227.1438560a.1123.ffffef61@mx.google.com> <89DD91D94A684E29A915B2F9E243EE70@china.huawei.com> <641DD488A4FF471C9CB4815F6518E883@china.huawei.com> <12353240859745DA9EE245BCE39FA679@china.huawei.com> <5FFF670DD3954D21B977BA0F48460E49@china.huawei.com> <4a02fe1c.0aa5660a.5762.3a54@mx.google.com> Cc: avt@ietf.org Subject: Re: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 15:38:09 -0000 Roni, I understand. Note my wording of "the highest level". BR, YK > -----Original Message----- > From: Roni Even [mailto:ron.even.tlv@gmail.com] > Sent: Thursday, May 07, 2009 11:28 AM > To: 'Ye-Kui Wang'; 'Randell Jesup' > Cc: avt@ietf.org > Subject: RE: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - > Profile level > > YK, > I think that the issue is not to establish an asymmetric > communication where one sides sends qcif and the other cif. > Using the level in the offer answer will not help for that > since the level is a maximum so even if the offer says it can > receive CIF the answerer can send him a qcif picture. > What Ashish wants is to be able to declare a higher level in > the answer. You can see the other thread I had with Magnus, I > think it explains it better. > For the case when an endpoint wants to receive a specific > picture size you will need some request mechanism, example is > by the image attribute draft in mmusic > > Roni > > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > Behalf Of Ye-Kui Wang > Sent: Thursday, May 07, 2009 6:00 PM > To: 'Randell Jesup' > Cc: avt@ietf.org > Subject: Re: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - > Profile level > > > The word "parameters in "two level parameters" did not mean > "parameter sets" > :-) > > To establish an asymmetric (in spatial resolution and level) > video communication session between two entities, wherein one > side wants to send at a lower level (say, QCIF) but receive > at a higher level (say, CIF), while the other side wants to > send at CIF and receive at QCIF. Then both the offer and the > answer should contain two level parameters, level_a and > level_b (level_a < level_b), to indicate the sending and > receiving (or reversely) capabilities (or preferences). > > Simply adding allow-level-upgrade is not clear to me. > Assuming that both sides indicate allow-level-upgrade = 1. If > the answer contains a higher level, then what is the highest > level to use in the direction from the offerer to the > answerer and what is the highest level to use in the other > direction? The same question applies when the answer contains > a lower level. > > > BR, YK > > > -----Original Message----- > > From: Randell Jesup [mailto:rjesup@wgate.com] > > Sent: Thursday, May 07, 2009 9:42 AM > > To: Ye-Kui Wang > > Cc: avt@ietf.org > > Subject: Re: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile > > level > > > > Ye-Kui Wang writes: > > >Furthermore, to use one m= line to represent different levels (as > > >capabilities) for sending and receiving, you would need two level > > >parameters. > > > > This is no different than supporting level downgrade. If > you're using > > in-band parameter sets, those carry the actual level within > them. If > > you're using out-of-band parameter sets, those are "send" > parameters. > > So an offerer who supports allow-level-upgrade=1 would include in > > sprop-level-parameter-sets levels above the offer level, up to the > > maximum sending level the offerer supports. > > > > -- > > Randell Jesup, Worldgate (developers of the Ojo > videophone), ex-Amiga > > OS team rjesup@wgate.com "The fetters imposed on liberty at > home have > > ever been forged out of the weapons provided for defence > against real, > > pretended, or imaginary dangers from abroad." > > - James Madison, 4th US president (1751-1836) > > > > > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > > From root@core3.amsl.com Thu May 7 08:45:02 2009 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 263433A7001; Thu, 7 May 2009 08:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090507154502.263433A7001@core3.amsl.com> Date: Thu, 7 May 2009 08:45:02 -0700 (PDT) Cc: avt@ietf.org Subject: [AVT] I-D Action:draft-ietf-avt-rapid-rtp-sync-01.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 15:45:02 -0000 --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 : Rapid Synchronisation of RTP Flows Author(s) : C. Perkins, T. Schierl Filename : draft-ietf-avt-rapid-rtp-sync-01.txt Pages : 20 Date : 2009-05-07 This memo outlines how RTP multimedia sessions are synchronised, and discusses how rapidly such synchronisation can occur. We show that most RTP sessions can be synchronised immediately, but that the use of video switching multipoint conference units (MCUs) or large source specific multicast (SSM) groups can greatly increase the initial synchronisation delay. This increase in delay can be unacceptable to some applications that use layered and/or multi-description codecs. This memo introduces several mechanisms to reduce the initial synchronisation delay for multimedia sessions. It updates the RTP Control Protocol (RTCP) timing rules to reduce the initial synchronisation delay for SSM sessions. A new feedback packet is defined for use with the Extended RTP Profile for RTCP-based Feedback (RTP/AVPF), allowing video switching MCUs to rapidly request resynchronisation. Two new RTP header extensions are defined to allow rapid synchronisation of late joiners, and guarantee correct timestamp based decoding order recovery for layered codecs in the presence of clock skew. Therefore, a synchronized insertion of RTP header extensions is recommended. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rapid-rtp-sync-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-avt-rapid-rtp-sync-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-07083723.I-D@ietf.org> --NextPart-- From magnus.westerlund@ericsson.com Thu May 7 08:52:40 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97C063A71E8 for ; Thu, 7 May 2009 08:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.181 X-Spam-Level: X-Spam-Status: No, score=-6.181 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61G-+cOSuk8j for ; Thu, 7 May 2009 08:52:38 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 0DD2C3A7214 for ; Thu, 7 May 2009 08:50:42 -0700 (PDT) X-AuditID: c1b4fb3e-b7b7bae000000a45-f4-4a02f7cc775f Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 0A.2B.02629.CC7F20A4; Thu, 7 May 2009 17:01:39 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 May 2009 17:01:29 +0200 Received: from [153.88.50.61] ([153.88.50.61]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 May 2009 17:01:28 +0200 Message-ID: <4A02F7C8.9010709@ericsson.com> Date: Thu, 07 May 2009 17:01:28 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Roni Even References: <49ff59e6.1358560a.4af5.05e3@mx.google.com> <089AD8684C5E4C2995F01C2527EE7081@china.huawei.com> <717562D70E24CF489737F81B0EA234DF0E712574@lsmail.austin.kmvtechnologies.com> <07F83448A6AC4B428694E13E14AB3F9C@china.huawei.com> <4A01A1D6.9020206@ericsson.com> <4a01a96d.1438560a.1014.ffffe2c7@mx.google.com> In-Reply-To: <4a01a96d.1438560a.1014.ffffe2c7@mx.google.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 07 May 2009 15:01:28.0749 (UTC) FILETIME=[B31BDDD0:01C9CF24] X-Brightmail-Tracker: AAAAAQAAAZE= Cc: avt@ietf.org Subject: Re: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 15:52:40 -0000 Roni Even skrev: > Hi Magnus, > I think the question that Ashish is trying to ask is not about general > asymmetry. The level parameter is signaling a maximum since it implies > support for any level below the on in the offer. The level specifies the > maximum that the offerer can send and receive. The answerer should except to > receive a stream that is in the level in the offer. > Now the answer can reply with a level lower than the one in the offer. Now > the offer should send a stream that is within the level in the answer since > by signaling a specific level it implies that a lower one is also possible. > Still the answerer can send a stream that is within the level signaled by > the offer even though it gave a lower level - this is already asymmetry. The > problem is that the current text says that the level signals the level that > the answerer can receive but also that it can send but the above description > hints that asymmetry may happen even now. > Yes, I agree that for this type of parameter in offer/answer you would declare your receiver capability. So what you say is right. > Ashish is asking why for the case of offer answer, if the above analysis is > correct why not allow the answerer to specify a level higher than the one in > the offer since it will still have similar result to the case when the > answer has a level lower than the offer. Yes, that is true. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From root@core3.amsl.com Thu May 7 11:00:01 2009 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id AD13628C256; Thu, 7 May 2009 11:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090507180001.AD13628C256@core3.amsl.com> Date: Thu, 7 May 2009 11:00:01 -0700 (PDT) Cc: avt@ietf.org Subject: [AVT] I-D Action:draft-ietf-avt-rtp-speex-07.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 18:00:01 -0000 --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 the Speex Codec Author(s) : G. Herlein, et al. Filename : draft-ietf-avt-rtp-speex-07.txt Pages : 22 Date : 2009-05-07 Speex is an open-source voice codec suitable for use in Voice over IP (VoIP) type applications. This document describes the payload format for Speex generated bit streams within an RTP packet. Also included here are the necessary details for the use of Speex with the Session Description Protocol (SDP).Editors Note All references to RFC XXXX are to be replaced by references to the RFC number of this memo, when published. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-speex-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-avt-rtp-speex-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-07105258.I-D@ietf.org> --NextPart-- From Thomas.Schierl@hhi.fraunhofer.de Mon May 11 02:39:54 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AD0B3A67DD for ; Mon, 11 May 2009 02:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.165 X-Spam-Level: X-Spam-Status: No, score=-4.165 tagged_above=-999 required=5 tests=[AWL=0.636, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVFxBXin4f44 for ; Mon, 11 May 2009 02:39:53 -0700 (PDT) Received: from mail.hhi.fraunhofer.de (mail.HHI.FRAUNHOFER.DE [193.174.67.45]) by core3.amsl.com (Postfix) with ESMTP id E1DFE3A6358 for ; Mon, 11 May 2009 02:39:52 -0700 (PDT) Received: by mail.hhi.fraunhofer.de (Postfix, from userid 65534) id E93F51D88FBC; Mon, 11 May 2009 11:41:21 +0200 (CEST) Received: from imsva.hhi.de (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 8DEDC150036; Mon, 11 May 2009 11:41:20 +0200 (CEST) Received: from [10.8.0.150] (unknown [10.8.0.150]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Thomas Schierl", Issuer "Fraunhofer-Gesellschaft Root-CA v2" (not verified)) by mail.hhi.fraunhofer.de (Postfix) with ESMTP id B1F9D1D88FA5; Mon, 11 May 2009 11:41:20 +0200 (CEST) Message-ID: <4A07F2BF.6010207@hhi.fraunhofer.de> Date: Mon, 11 May 2009 11:41:19 +0200 From: Thomas.Schierl@hhi.fraunhofer.de Organization: Fraunhofer HHI User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: avt Content-Type: multipart/mixed; boundary="------------030509070702010201090503" X-alterMIME: Yes Cc: Roni Even , Tom Taylor , Colin Perkins Subject: [AVT] [Fwd: I-D Action:draft-ietf-avt-rapid-rtp-sync-01.txt] X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2009 09:39:54 -0000 This is a multi-part message in MIME format. --------------030509070702010201090503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Sorry for the delayed update on "draft-ietf-avt-rapid-rtp-sync". Please find attached the pointer to version -01. We mainly addressed the following issues: - selected fmt=5 for "Rapid Resynchronisation Request" packet - added IANA section 6 - added SDP signaling for header ext. in section 3.3 - extended security section 5 - improved and extended text on specifying use of header ext in 3.2 and 4.2 - improved example in section 4 - removed "access unit" from section 4, since this was SVC specific - clarification of "RTP flow" in introduction section - changed "single source" to "source specific" multicast channel below figure 1 - improved abstract text - fixed figure 1 - editorial improvement throughout the document Best regards, Thomas -- Thomas Schierl -------------- Fraunhofer HHI --- Visit us at ANGACable 2009 / May 26-28 / Cologne, Germay / Hall 10.2, Booth K15 http://www.angacable.com --------------030509070702010201090503 Content-Type: message/rfc822; name="[AVT] I-D Action:draft-ietf-avt-rapid-rtp-sync-01.txt.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="[AVT] I-D Action:draft-ietf-avt-rapid-rtp-sync-01.txt.eml" X-Account-Key: account2 X-Mozilla-Keys: Return-Path: Received: from mail.hhi.fraunhofer.de ([unix socket]) by mail (Cyrus v2.2.3) with LMTP; Thu, 07 May 2009 17:50:21 +0200 X-Sieve: CMU Sieve 2.2 Received: by mail.hhi.fraunhofer.de (Postfix, from userid 65534) id 224171D89014; Thu, 7 May 2009 17:50:21 +0200 (CEST) Received: from imsva.hhi.de (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id A49EC15003F; Thu, 7 May 2009 17:50:18 +0200 (CEST) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mail.hhi.fraunhofer.de (Postfix) with ESMTP id 8216C1D89006; Thu, 7 May 2009 17:50:20 +0200 (CEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 774F128C2AF; Thu, 7 May 2009 08:45:04 -0700 (PDT) X-Original-To: avt@ietf.org Delivered-To: avt@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 263433A7001; Thu, 7 May 2009 08:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090507154502.263433A7001@core3.amsl.com> Date: Thu, 7 May 2009 08:45:02 -0700 (PDT) Cc: avt@ietf.org Subject: [AVT] I-D Action:draft-ietf-avt-rapid-rtp-sync-01.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org --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 : Rapid Synchronisation of RTP Flows Author(s) : C. Perkins, T. Schierl Filename : draft-ietf-avt-rapid-rtp-sync-01.txt Pages : 20 Date : 2009-05-07 This memo outlines how RTP multimedia sessions are synchronised, and discusses how rapidly such synchronisation can occur. We show that most RTP sessions can be synchronised immediately, but that the use of video switching multipoint conference units (MCUs) or large source specific multicast (SSM) groups can greatly increase the initial synchronisation delay. This increase in delay can be unacceptable to some applications that use layered and/or multi-description codecs. This memo introduces several mechanisms to reduce the initial synchronisation delay for multimedia sessions. It updates the RTP Control Protocol (RTCP) timing rules to reduce the initial synchronisation delay for SSM sessions. A new feedback packet is defined for use with the Extended RTP Profile for RTCP-based Feedback (RTP/AVPF), allowing video switching MCUs to rapidly request resynchronisation. Two new RTP header extensions are defined to allow rapid synchronisation of late joiners, and guarantee correct timestamp based decoding order recovery for layered codecs in the presence of clock skew. Therefore, a synchronized insertion of RTP header extensions is recommended. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rapid-rtp-sync-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-avt-rapid-rtp-sync-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-07083723.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www.ietf.org/mailman/listinfo/avt --NextPart-- --------------030509070702010201090503-- From kaz.mishima@gmail.com Mon May 11 02:38:10 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94F083A6AB8 for ; Mon, 11 May 2009 02:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.077 X-Spam-Level: X-Spam-Status: No, score=-1.077 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQIMz4VkTBaQ for ; Mon, 11 May 2009 02:38:09 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by core3.amsl.com (Postfix) with ESMTP id DAF913A6358 for ; Mon, 11 May 2009 02:38:09 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 29so2428335wff.31 for ; Mon, 11 May 2009 02:39:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=VjUbHSkE5Z1C8m397/88g68PhrvvDoASGmpbKHJ6jx0=; b=xWskwQdXXRmYkOOrXGLTcCiI+XEXPovEbSVjV+mtpZNjr1jJbGDnCAxrjUiTP+jGyr KfsNAMAEgLkAOab99cGE9Cb5w0/JkqQIDPAzA9CKB/XF5G6D4Egn37blitD5jpVaC5Ou uc+ZlLpiJ9TeI8O0tcCv1lCatJCfwdbmNygA4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=vCCF9rfix4qNeqWPSLsCiRmdDF7BIgpVtKzAAL9n3eZvkRmccc6UAlSESACLsCOlG5 4PsznUyHpqn09KdoESyCvS8YnSU30qhmXv7MVzkug3GzTa53/pbXO7DBbgdBRzwvCqbi ocbcgZj2fsibqK/8YKbEObyk879mhHMV32CFo= MIME-Version: 1.0 Sender: kaz.mishima@gmail.com Received: by 10.142.192.1 with SMTP id p1mr2788631wff.17.1242034778465; Mon, 11 May 2009 02:39:38 -0700 (PDT) In-Reply-To: <1241543693.1843.12.camel@TesterTop3.tester.ca> References: <1241543693.1843.12.camel@TesterTop3.tester.ca> Date: Mon, 11 May 2009 18:39:38 +0900 X-Google-Sender-Auth: 00a20db565291cf0 Message-ID: <98bbb6930905110239h385e70ddpe2f185b9d051dd85@mail.gmail.com> From: Kazuhiro Mishima To: =?ISO-8859-1?Q?Olivier_Cr=EAte?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: avt@ietf.org Subject: Re: [AVT] SDP Offer/answer in draft-ietf-avt-rfc3189bis-03 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2009 09:39:57 -0000 Hi Olivier, Thank you for your comment. # Sorry for this is not RTP encoding topic I think. In this case (Offerer does not set the type), I think this session will be finished. If some threshold count can be enabled, finished after the threshold count = time. 2009/5/6 Olivier Cr=EAte : > Hello, > > The section on SDP Offer/Answer in this draft seems a bit unclear to me. > Even though the "encode" paramete is required, it seems to imply that it > could not be there: > > "If the offerer sets a encode type on a=3Dfmtp field, the answerer MUST > select one encode type, and reply with selected encode type value. > > What if the offerer does not set an encode type? > > I also don't see a mecanism to negotiate the supported encode type? Can > it be assumed that if the offerer supports an encode type, it support > all lower resolution/framerates ? If the answer is yes, it should be > specified. If the answer is no, I guess the answerer should remove any > payload it can't understand? > > > P.S. I'm not on the list, please keep me in CC. > > -- > Olivier Cr=EAte > olivier.crete@collabora.co.uk > Collabora Ltd > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > > From root@core3.amsl.com Mon May 11 05:00:01 2009 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 976BD3A69A9; Mon, 11 May 2009 05:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090511120001.976BD3A69A9@core3.amsl.com> Date: Mon, 11 May 2009 05:00:01 -0700 (PDT) Cc: avt@ietf.org Subject: [AVT] I-D Action:draft-ietf-avt-rtp-uemclip-05.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2009 12:00:01 -0000 --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 mU-law EMbedded Codec for Low-delay IP communication (UEMCLIP) speech codec Author(s) : Y. Hiwasaki, H. Ohmuro Filename : draft-ietf-avt-rtp-uemclip-05.txt Pages : 24 Date : 2009-05-11 This document describes the RTP payload format of a mU-law EMbedded Coder for Low-delay IP communication (UEMCLIP), an enhanced speech codec of ITU-T G.711. The bitstream has a scalable structure with an embedded u-law bitstream, also known as PCMU, thus providing a handy transcoding operation between narrowband and wideband speech. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-uemclip-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-avt-rtp-uemclip-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-11045709.I-D@ietf.org> --NextPart-- From jean-marc.valin@octasic.com Mon May 11 13:01:38 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59BE63A6F98 for ; Mon, 11 May 2009 13:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.598 X-Spam-Level: X-Spam-Status: No, score=-1.598 tagged_above=-999 required=5 tests=[AWL=1.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjLJUQc1C8Aj for ; Mon, 11 May 2009 13:01:37 -0700 (PDT) Received: from MAILEXCH.octasic.com (mail.octasic.com [216.208.79.2]) by core3.amsl.com (Postfix) with ESMTP id 58E273A6CE4 for ; Mon, 11 May 2009 13:00:42 -0700 (PDT) Received: from [142.138.24.19] ([142.138.24.19]) by MAILEXCH.octasic.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 May 2009 16:02:12 -0400 Message-ID: <4A088444.50403@octasic.com> Date: Mon, 11 May 2009 16:02:12 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Randell Jesup References: <49B52906.5000300@octasic.com> <49B58D1E.702@octasic.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 May 2009 20:02:12.0021 (UTC) FILETIME=[5F63AE50:01C9D273] Cc: avt@ietf.org Subject: [AVT] Request for feedback on draft-valin-celt-rtp-profile-01.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2009 20:01:38 -0000 Hi, We have just updated the CELT RTP profile to take into account the suggestions we got: http://www.ietf.org/internet-drafts/draft-valin-celt-rtp-profile-01.txt Among the changes, we have replaced b:AS= with a bitrate= parameter and only one frame size is now allowed for each dynamic payload. This should solve the problem with early media at the expense of using possibly many payload types. Anything we forgot to address or any new issues? Cheers, Jean-Marc Randell Jesup wrote: > Gregory Maxwell writes: > >> Randell Jesup writes: >> [snip] >> >>> So what then was the "one-byte change in bitrate per frame" then? >>> I was referring to what happens if 10 packets in a row are lost - can the >>> receiver decode a packet that might be 10 bytes smaller or larger? Does it >>> need as input the number of packets lost (if any) since the last decoded >>> packet? >>> >> I'll let JM respond to the rest of your ongoing conversation but I >> wanted to take a crack at clarifying this as I probably caused the >> misunderstanding on this point. >> >> The text "CELT allows for bitrate adjustment in one byte per frame >> increments without any signalling requirement or overhead." is referring >> to the *resolution* of the instantaneous bitrate, not the rate of >> change. >> > > Aha. It's "one byte increments" then, not an "adjustment [of] one byte per > frame". Very different. Thanks. > > >> If the text were changed to say "CELT can encode to any whole number of >> bytes per frame at any time without signalling a change to the decoder" >> would this avoid the potential for misunderstanding? >> > > Yes. > > From abegen@cisco.com Mon May 11 14:07:21 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CC583A683E for ; Mon, 11 May 2009 14:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.407 X-Spam-Level: X-Spam-Status: No, score=-6.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uq01SFTzBQty for ; Mon, 11 May 2009 14:07:20 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 652C13A67EA for ; Mon, 11 May 2009 14:07:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,330,1238976000"; d="scan'208";a="183931817" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 11 May 2009 21:08:51 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n4BL8psC029023 for ; Mon, 11 May 2009 14:08:51 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n4BL8pqn015630 for ; Mon, 11 May 2009 21:08:51 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 May 2009 14:08:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 11 May 2009 14:08:25 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540943CDB9@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Q for 3984bis-06 Thread-Index: AcnSfJ/1ELWteCw8Ru+11Q7xTgafVQ== From: "Ali C. Begen (abegen)" To: X-OriginalArrivalTime: 11 May 2009 21:08:51.0412 (UTC) FILETIME=[AF365140:01C9D27C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1679; t=1242076131; x=1242940131; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20Q=20for=203984bis-06 |Sender:=20; bh=L9+49TEiisyuwl3WUxUFhYgY3rmj1WkGM5hilC6bmvg=; b=zn5gWkpRTyL4gBcyBmhPljT875dJ0vsXHvvf+gXPboxvA4ar5VV74AoY0y FDYTH7xrQ8AWQwiDI4MtMx64d6q/mMDbZOQDtOGrDpLqO6ZPCASyoH3k7a1r 56uyfiKX6k; Authentication-Results: sj-dkim-2; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [AVT] Q for 3984bis-06 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2009 21:07:21 -0000 Page 12 says: Informative note: Because H.264 allows the decoding order to=20 be different from the display order, values of RTP timestamps=20 may not be monotonically non-decreasing as a function of RTP=20 sequence numbers. Furthermore, the value for inter-arrival=20 This is not something specific for H.264 content. It applies to almost = all codecs. A rewording may be beneficial IMO.=20 jitter reported in the RTCP reports may not be a trustworthy=20 indication of the network performance, as the calculation=20 rules for inter-arrival jitter (section 6.4.1 of RFC 3550)=20 assume that the RTP timestamp of a packet is directly=20 proportional to its transmission time. What does it mean that RTP timestamp is proportional to its transmission = time? By "transmission time" do you mean the instant the packet was = sent? By definition, timestamp reflects the sampling instant of the = first octet in the RTP packet. The packets belong to a single video = frame will most likely have the same timestamp. But that does not mean = that they will be transmitted at the same time. RFC 3550 has a simple rule here and says this rule must be followed. The = packets are considered in the order they arrive, not based on their = seqnums in the jitter calculation. And the parameters needed to compute = the interarrival jitter are clock rate, timestamp and arrival-time = timestamp. I suggest a revision for this informative note, or we can simply remove = it since section 6.4.4 of RFC 3550 already provides a = more-than-sufficient explanation.=20 -acbegen From yekuiwang@huawei.com Mon May 11 14:26:16 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11C0F3A683E for ; Mon, 11 May 2009 14:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.232 X-Spam-Level: X-Spam-Status: No, score=-2.232 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A14eQ8X5Hnpe for ; Mon, 11 May 2009 14:26:15 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 225F23A6A4A for ; Mon, 11 May 2009 14:26:15 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJI009K60Y9I3@usaga04-in.huawei.com> for avt@ietf.org; Mon, 11 May 2009 16:27:45 -0500 (CDT) Received: from W90946 ([10.193.125.102]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJI00E590XYH4@usaga04-in.huawei.com> for avt@ietf.org; Mon, 11 May 2009 16:27:40 -0500 (CDT) Date: Mon, 11 May 2009 17:27:34 -0400 From: Ye-Kui Wang In-reply-to: <04CAD96D4C5A3D48B1919248A8FE0D540943CDB9@xmb-sjc-215.amer.cisco.com> To: "'Ali C. Begen (abegen)'" , avt@ietf.org Message-id: <2713212F2F334A15AB3DB03E1BB45156@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcnSfJ/1ELWteCw8Ru+11Q7xTgafVQAAfL5w References: <04CAD96D4C5A3D48B1919248A8FE0D540943CDB9@xmb-sjc-215.amer.cisco.com> Cc: ron.even.tlv@gmail.com, 'Tom Taylor' Subject: Re: [AVT] Q for 3984bis-06 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2009 21:26:16 -0000 Thanks Ali. This is an intact inheritance from RFC 3984. I'd agree to remove the note in the next submission. BTW, AVT Chairs, what is the plan on progressing this and the SVC drafts? BR, YK > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > Behalf Of Ali C. Begen (abegen) > Sent: Monday, May 11, 2009 5:08 PM > To: avt@ietf.org > Subject: [AVT] Q for 3984bis-06 > > Page 12 says: > > Informative note: Because H.264 allows the decoding order to > be different from the display order, values of RTP > timestamps > may not be monotonically non-decreasing as a function of RTP > sequence numbers. Furthermore, the value for inter-arrival > > This is not something specific for H.264 content. It applies > to almost all codecs. A rewording may be beneficial IMO. > > jitter reported in the RTCP reports may not be a trustworthy > indication of the network performance, as the calculation > rules for inter-arrival jitter (section 6.4.1 of RFC 3550) > assume that the RTP timestamp of a packet is directly > proportional to its transmission time. > > What does it mean that RTP timestamp is proportional to its > transmission time? By "transmission time" do you mean the > instant the packet was sent? By definition, timestamp > reflects the sampling instant of the first octet in the RTP > packet. The packets belong to a single video frame will most > likely have the same timestamp. But that does not mean that > they will be transmitted at the same time. > > RFC 3550 has a simple rule here and says this rule must be > followed. The packets are considered in the order they > arrive, not based on their seqnums in the jitter calculation. > And the parameters needed to compute the interarrival jitter > are clock rate, timestamp and arrival-time timestamp. > > I suggest a revision for this informative note, or we can > simply remove it since section 6.4.4 of RFC 3550 already > provides a more-than-sufficient explanation. > > -acbegen > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > From tom.taylor@rogers.com Tue May 12 00:56:39 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA6453A6BF4 for ; Tue, 12 May 2009 00:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7oHSv4hnL2h4 for ; Tue, 12 May 2009 00:56:39 -0700 (PDT) Received: from smtp126.rog.mail.re2.yahoo.com (smtp126.rog.mail.re2.yahoo.com [206.190.53.31]) by core3.amsl.com (Postfix) with SMTP id C76183A6C2E for ; Tue, 12 May 2009 00:56:38 -0700 (PDT) Received: (qmail 14690 invoked from network); 12 May 2009 07:58:08 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=5tdCNpKg7yTR39fh3IG6fwZUu4sv+AY1zLX3rJq8zz1fZQxaeUZHzhbmFWPXl9p3nCUH1rJjT11Sv3+A1BWLXn/lN6BOR7sSLEI+MrhNTGTXIgz0gMoTlctqsvMUWi0SAYDHo2mFp7umoKfZK5JOe3h7sWwZo42caATOGEdlZNo= ; Received: from unknown (HELO ?156.106.219.113?) (tom.taylor@156.106.219.113 with plain) by smtp126.rog.mail.re2.yahoo.com with SMTP; 12 May 2009 07:58:07 -0000 X-YMail-OSG: l8x6v0gVM1m3fMzCjscXWWFiB1aALx0cTw1n0lMmd7LOizZ_EJRZePIDf6fYurWReA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A092C12.8080704@rogers.com> Date: Tue, 12 May 2009 09:58:10 +0200 From: Tom Taylor User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Ye-Kui Wang References: <04CAD96D4C5A3D48B1919248A8FE0D540943CDB9@xmb-sjc-215.amer.cisco.com> <2713212F2F334A15AB3DB03E1BB45156@china.huawei.com> In-Reply-To: <2713212F2F334A15AB3DB03E1BB45156@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ron.even.tlv@gmail.com, avt@ietf.org Subject: Re: [AVT] Q for 3984bis-06 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2009 07:56:39 -0000 I was waiting for the discussion of level upgrade to settle. Should I issue a summary of what I have seen so far? Ye-Kui Wang wrote: > Thanks Ali. This is an intact inheritance from RFC 3984. I'd agree to remove > the note in the next submission. > > BTW, AVT Chairs, what is the plan on progressing this and the SVC drafts? > > BR, YK > >> -----Original Message----- >> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On >> Behalf Of Ali C. Begen (abegen) >> Sent: Monday, May 11, 2009 5:08 PM >> To: avt@ietf.org >> Subject: [AVT] Q for 3984bis-06 >> >> Page 12 says: >> >> Informative note: Because H.264 allows the decoding order to >> be different from the display order, values of RTP >> timestamps >> may not be monotonically non-decreasing as a function of RTP >> sequence numbers. Furthermore, the value for inter-arrival >> >> This is not something specific for H.264 content. It applies >> to almost all codecs. A rewording may be beneficial IMO. >> >> jitter reported in the RTCP reports may not be a trustworthy >> indication of the network performance, as the calculation >> rules for inter-arrival jitter (section 6.4.1 of RFC 3550) >> assume that the RTP timestamp of a packet is directly >> proportional to its transmission time. >> >> What does it mean that RTP timestamp is proportional to its >> transmission time? By "transmission time" do you mean the >> instant the packet was sent? By definition, timestamp >> reflects the sampling instant of the first octet in the RTP >> packet. The packets belong to a single video frame will most >> likely have the same timestamp. But that does not mean that >> they will be transmitted at the same time. >> >> RFC 3550 has a simple rule here and says this rule must be >> followed. The packets are considered in the order they >> arrive, not based on their seqnums in the jitter calculation. >> And the parameters needed to compute the interarrival jitter >> are clock rate, timestamp and arrival-time timestamp. >> >> I suggest a revision for this informative note, or we can >> simply remove it since section 6.4.4 of RFC 3550 already >> provides a more-than-sufficient explanation. >> >> -acbegen >> >> _______________________________________________ >> Audio/Video Transport Working Group >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt >> > > > From Even.roni@huawei.com Tue May 12 02:00:25 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80C943A6D96 for ; Tue, 12 May 2009 02:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.491 X-Spam-Level: X-Spam-Status: No, score=-0.491 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bi2whBCQkIiS for ; Tue, 12 May 2009 02:00:24 -0700 (PDT) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id A8B603A6D47 for ; Tue, 12 May 2009 02:00:24 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJI00AFDX2ZWO@szxga02-in.huawei.com> for avt@ietf.org; Tue, 12 May 2009 17:01:48 +0800 (CST) Received: from huawei.com ([172.17.1.31]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJI00LDQX2ZC8@szxga02-in.huawei.com> for avt@ietf.org; Tue, 12 May 2009 17:01:47 +0800 (CST) Received: from [172.24.1.3] (Forwarded-For: [79.176.114.85]) by szxmc03-in.huawei.com (mshttpd); Tue, 12 May 2009 12:01:47 +0300 Date: Tue, 12 May 2009 12:01:47 +0300 From: Roni Even GW11514 To: avt@ietf.org Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal Cc: ron.even.tlv@gmail.com Subject: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions (RAMS) as a working group item X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2009 09:00:25 -0000 Hi, There was a big support to adopt this work based on the proposed draft. Bill will be the editor and he will submit the initial draft-ietf-avt-rapid-synchronization-for-rtp-00. I hope all people who showed interest in the work will participate in the review of this draft so we can move it fast. Thanks Roni Even 12/5/09 From oran@cisco.com Tue May 12 02:20:13 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9A5128C0FE for ; Tue, 12 May 2009 02:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.605 X-Spam-Level: X-Spam-Status: No, score=-6.605 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3AxsPJkdh9IS for ; Tue, 12 May 2009 02:20:12 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id ECBEE3A692D for ; Tue, 12 May 2009 02:20:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,181,1241395200"; d="scan'208";a="75613786" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 12 May 2009 09:21:44 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n4C9LiJ8011049; Tue, 12 May 2009 02:21:44 -0700 Received: from sjc-vpnasa-179.cisco.com (sjc-vpnasa-179.cisco.com [10.21.104.179]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n4C9LhMO002358; Tue, 12 May 2009 09:21:43 GMT Message-Id: From: David R Oran To: Roni Even GW11514 In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 12 May 2009 11:21:42 +0200 References: X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=599; t=1242120104; x=1242984104; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:=20David=20R=20Oran=20 |Subject:=20Re=3A=20[AVT]=20Adopting=20Rapid=20Acquisition= 20of=20Multicast=20RTP=20Sessions=20(RAMS)=20as=20a=20workin g=20group=20item |Sender:=20; bh=TT8mxQ4yUXH/ObYlc7RsZ6ylfDf4XVHl4CLhj4AyAhg=; b=OijRQFuRgHIXKZLu/RkyC8eovHhnWWAxfC1rod9JJNxhSthHWTpWHqWrJv LeubQGvoUG3ahVV97mVKJcAaLLECmyxfdCB6DWjPm7WDZ/1FHMBRxqLvVn0G 8HZZQjLEnZ; Authentication-Results: sj-dkim-4; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: ron.even.tlv@gmail.com, avt@ietf.org Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions (RAMS) as a working group item X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2009 09:20:13 -0000 Thanks, everyone! On May 12, 2009, at 11:01 AM, Roni Even GW11514 wrote: > > Hi, > There was a big support to adopt this work based on the proposed > draft. > Bill will be the editor and he will submit the initial draft-ietf- > avt-rapid-synchronization-for-rtp-00. > I hope all people who showed interest in the work will participate > in the review of this draft so we can move it fast. > Thanks > Roni Even > > 12/5/09 > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From versteb@cisco.com Tue May 12 06:26:15 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4DA93A6C25 for ; Tue, 12 May 2009 06:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.542 X-Spam-Level: X-Spam-Status: No, score=-6.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ESzOt1AlC5Mq for ; Tue, 12 May 2009 06:26:14 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id B72F93A6CBF for ; Tue, 12 May 2009 06:26:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,182,1241395200"; d="scan'208";a="184259418" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 12 May 2009 13:27:46 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n4CDRkdH012397; Tue, 12 May 2009 06:27:46 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id n4CDRhDl012515; Tue, 12 May 2009 13:27:46 GMT Received: from xmb-rtp-21d.amer.cisco.com ([64.102.31.116]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 May 2009 09:27:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 12 May 2009 09:27:45 -0400 Message-ID: <81B9B88E2F9D574AA5328A85547CDE91013038E4@xmb-rtp-21d.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions (RAMS) as a working group item Thread-Index: AcnS4FBFJRh0kTNdSKKujynDJmWrDwAJMQ/A References: From: "Bill Ver Steeg (versteb)" To: "Roni Even GW11514" , X-OriginalArrivalTime: 12 May 2009 13:27:45.0840 (UTC) FILETIME=[6FA8CB00:01C9D305] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1046; t=1242134866; x=1242998866; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=versteb@cisco.com; z=From:=20=22Bill=20Ver=20Steeg=20(versteb)=22=20 |Subject:=20RE=3A=20[AVT]=20Adopting=20Rapid=20Acquisition= 20of=20Multicast=20RTP=20Sessions=20(RAMS)=20as=20a=20workin g=20group=20item |Sender:=20; bh=D5xtMmoQtsKAj60wRpPd7tAyucSQ8kEPFsdMdgTDkZM=; b=kBpEff9XnXIl5xOBzlMpHYY2gVqJNG919+i3fy06UZT+SO+Zi8/8cI3lTz HDeS2lIpiIPW+PcsT/S7a6Zeg6jMJ38kCOAlZM5oVpinc8Xr02aJwYTVQ00L N+Hyo0Ated; Authentication-Results: sj-dkim-3; header.From=versteb@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: ron.even.tlv@gmail.com Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions (RAMS) as a working group item X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2009 13:26:16 -0000 Excellent news Roni. As discussed during the breakout session and on the list, I suggest we use the name "draft-ietf-avt-rapid-acquisition-for-rtp-00". We want to avoid confusion with the other ongoing "synchronization" AVT drafts. Bill VerSteeg=20 -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Roni Even GW11514 Sent: Tuesday, May 12, 2009 5:02 AM To: avt@ietf.org Cc: ron.even.tlv@gmail.com Subject: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions (RAMS) as a working group item Hi, There was a big support to adopt this work based on the proposed draft. Bill will be the editor and he will submit the initial draft-ietf-avt-rapid-synchronization-for-rtp-00. I hope all people who showed interest in the work will participate in the review of this draft so we can move it fast. Thanks Roni Even 12/5/09 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www.ietf.org/mailman/listinfo/avt From yekuiwang@huawei.com Tue May 12 06:49:04 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2799F3A6DB1 for ; Tue, 12 May 2009 06:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.247 X-Spam-Level: X-Spam-Status: No, score=-2.247 tagged_above=-999 required=5 tests=[AWL=0.352, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smmpDj9CAGHX for ; Tue, 12 May 2009 06:49:03 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 497D93A6784 for ; Tue, 12 May 2009 06:49:03 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJJ006MRAG98Q@usaga02-in.huawei.com> for avt@ietf.org; Tue, 12 May 2009 06:50:34 -0700 (PDT) Received: from W90946 ([10.193.125.102]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJJ00F7MAG3DG@usaga02-in.huawei.com> for avt@ietf.org; Tue, 12 May 2009 06:50:33 -0700 (PDT) Date: Tue, 12 May 2009 09:50:26 -0400 From: Ye-Kui Wang In-reply-to: <4A092C12.8080704@rogers.com> To: 'Tom Taylor' Message-id: <5E07A2E74C0749B7A84371EE422E90C6@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AcnS12m0h4LXrKfCSPuypoWoF4LcBAAMSXzw References: <04CAD96D4C5A3D48B1919248A8FE0D540943CDB9@xmb-sjc-215.amer.cisco.com> <2713212F2F334A15AB3DB03E1BB45156@china.huawei.com> <4A092C12.8080704@rogers.com> Cc: ron.even.tlv@gmail.com, avt@ietf.org Subject: Re: [AVT] Q for 3984bis-06 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2009 13:49:04 -0000 Yes, please go ahead. BR,YK > -----Original Message----- > From: Tom Taylor [mailto:tom.taylor@rogers.com] > Sent: Tuesday, May 12, 2009 3:58 AM > To: Ye-Kui Wang > Cc: 'Ali C. Begen (abegen)'; avt@ietf.org; ron.even.tlv@gmail.com > Subject: Re: [AVT] Q for 3984bis-06 > > I was waiting for the discussion of level upgrade to settle. > Should I issue a summary of what I have seen so far? > > Ye-Kui Wang wrote: > > Thanks Ali. This is an intact inheritance from RFC 3984. > I'd agree to > > remove the note in the next submission. > > > > BTW, AVT Chairs, what is the plan on progressing this and > the SVC drafts? > > > > BR, YK > > > >> -----Original Message----- > >> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] > On Behalf Of > >> Ali C. Begen (abegen) > >> Sent: Monday, May 11, 2009 5:08 PM > >> To: avt@ietf.org > >> Subject: [AVT] Q for 3984bis-06 > >> > >> Page 12 says: > >> > >> Informative note: Because H.264 allows the > decoding order to > >> be different from the display order, values of RTP > >> timestamps > >> may not be monotonically non-decreasing as a > function of RTP > >> sequence numbers. Furthermore, the value for > inter-arrival > >> > >> This is not something specific for H.264 content. It applies to > >> almost all codecs. A rewording may be beneficial IMO. > >> > >> jitter reported in the RTCP reports may not be a > trustworthy > >> indication of the network performance, as the calculation > >> rules for inter-arrival jitter (section 6.4.1 of > RFC 3550) > >> assume that the RTP timestamp of a packet is directly > >> proportional to its transmission time. > >> > >> What does it mean that RTP timestamp is proportional to its > >> transmission time? By "transmission time" do you mean the > instant the > >> packet was sent? By definition, timestamp reflects the sampling > >> instant of the first octet in the RTP packet. The packets > belong to a > >> single video frame will most likely have the same > timestamp. But that > >> does not mean that they will be transmitted at the same time. > >> > >> RFC 3550 has a simple rule here and says this rule must be > followed. > >> The packets are considered in the order they arrive, not based on > >> their seqnums in the jitter calculation. > >> And the parameters needed to compute the interarrival jitter are > >> clock rate, timestamp and arrival-time timestamp. > >> > >> I suggest a revision for this informative note, or we can simply > >> remove it since section 6.4.4 of RFC 3550 already provides a > >> more-than-sufficient explanation. > >> > >> -acbegen > >> > >> _______________________________________________ > >> Audio/Video Transport Working Group > >> avt@ietf.org > >> https://www.ietf.org/mailman/listinfo/avt > >> > > > > > > > From root@core3.amsl.com Tue May 12 10:00:02 2009 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 436873A6A9E; Tue, 12 May 2009 10:00:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090512170002.436873A6A9E@core3.amsl.com> Date: Tue, 12 May 2009 10:00:02 -0700 (PDT) Cc: avt@ietf.org Subject: [AVT] I-D Action:draft-ietf-avt-rapid-acquisition-for-rtp-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2009 17:00:02 -0000 --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 : Unicast-Based Rapid Acquisition of Multicast RTP Sessions Author(s) : B. Steeg, et al. Filename : draft-ietf-avt-rapid-acquisition-for-rtp-00.txt Pages : 37 Date : 2009-05-12 When an RTP receiver joins a primary multicast session, it may need to acquire and parse certain Reference Information before it can process any data sent in the multicast session. Depending on the join time, length of the Reference Information repetition interval, size of the Reference Information as well as the application and transport properties, the time lag before an RTP receiver can usefully consume the multicast data, which we refer to as the Acquisition Delay, varies and may be large. This is an undesirable phenomenon for receivers that frequently switch among different multicast sessions, such as video broadcasts. In this document, we describe a method using the existing RTP and RTCP protocol machinery that reduces the acquisition delay. In this method, an auxiliary unicast RTP session carrying the Reference Information to the receiver precedes/accompanies the primary multicast stream. This unicast RTP flow may be transmitted at a faster than natural rate to further accelerate the acquisition. The motivating use case for this capability is multicast applications that carry real-time compressed audio and video. However, the proposed method can also be used in other types of multicast applications where the acquisition delay is long enough to be a problem. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rapid-acquisition-for-rtp-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-avt-rapid-acquisition-for-rtp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-12094729.I-D@ietf.org> --NextPart-- From singer@apple.com Tue May 12 21:23:46 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00BF43A6A4E for ; Tue, 12 May 2009 21:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SpeP2W6dFSG5 for ; Tue, 12 May 2009 21:23:45 -0700 (PDT) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 4526C3A6971 for ; Tue, 12 May 2009 21:23:45 -0700 (PDT) Received: from relay13.apple.com (relay13.apple.com [17.128.113.29]) by mail-out3.apple.com (Postfix) with ESMTP id 718D1609654E; Tue, 12 May 2009 21:25:17 -0700 (PDT) Received: from relay13.apple.com (unknown [127.0.0.1]) by relay13.apple.com (Symantec Brightmail Gateway) with ESMTP id 57DB328050; Tue, 12 May 2009 21:25:17 -0700 (PDT) X-AuditID: 1180711d-a86f4bb000000259-57-4a0a4ba96100 Received: from [17.202.35.52] (unknown [17.80.153.137]) by relay13.apple.com (Apple SCV relay) with ESMTP id 24D832807D; Tue, 12 May 2009 21:25:13 -0700 (PDT) Mime-Version: 1.0 Message-Id: Date: Wed, 13 May 2009 12:24:12 +0800 To: Ross Finlayson From: David Singer Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Brightmail-Tracker: AAAAAA== Cc: http-live-streaming-review@group.apple.com, avt@ietf.org Subject: Re: [AVT] iPhone streaming Internet-Draft posted X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2009 04:23:46 -0000 Hi, Ross. Thanks for looking at the spec. On May 5, 2009, at 8:39 AM, Ross Finlayson wrote: >>We appreciate feedback on the protocol. > >Rather than invent yet another protocol, why not just implement a >RTSP/RTP client on the iPhone instead? Distributing media as discrete files over HTTP gives content providers a cost-effective way to scale to high demand by using existing CDN and HTTP caching infrastructure. With this goal in mind, we're looking for technical feedback on the specification. thanks, nice to hear from you, -- David Singer Multimedia Standards, Apple Inc. From versteb@cisco.com Wed May 13 05:06:44 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F5DB3A6959 for ; Wed, 13 May 2009 05:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.547 X-Spam-Level: X-Spam-Status: No, score=-6.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MGoNdOwaSfsI for ; Wed, 13 May 2009 05:06:43 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id CD9003A6F8D for ; Wed, 13 May 2009 05:06:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,187,1241395200"; d="scan'208";a="75780667" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 13 May 2009 12:08:10 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n4DC8C11012979 for ; Wed, 13 May 2009 05:08:12 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n4DC8Aih011259 for ; Wed, 13 May 2009 12:08:11 GMT Received: from xmb-rtp-21d.amer.cisco.com ([64.102.31.116]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 May 2009 08:08:11 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 May 2009 08:08:10 -0400 Message-ID: <81B9B88E2F9D574AA5328A85547CDE9101303DA5@xmb-rtp-21d.amer.cisco.com> In-Reply-To: <81B9B88E2F9D574AA5328A85547CDE91013038E4@xmb-rtp-21d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions(RAMS) as a working group item Thread-Index: AcnS4FBFJRh0kTNdSKKujynDJmWrDwAJMQ/AAC+GL9A= References: <81B9B88E2F9D574AA5328A85547CDE91013038E4@xmb-rtp-21d.amer.cisco.com> From: "Bill Ver Steeg (versteb)" To: X-OriginalArrivalTime: 13 May 2009 12:08:11.0352 (UTC) FILETIME=[7C417D80:01C9D3C3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1871; t=1242216492; x=1243080492; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=versteb@cisco.com; z=From:=20=22Bill=20Ver=20Steeg=20(versteb)=22=20 |Subject:=20RE=3A=20[AVT]=20Adopting=20Rapid=20Acquisition= 20of=20Multicast=20RTP=20Sessions(RAMS)=20as=20a=20working=2 0group=20item |Sender:=20; bh=7u28hkqkKtWOpcclk4EUwz1/dEFbZJdPm3x1TCvPQl4=; b=nF6+UYYqjV+kFFcQPApQl5+3oUZUe8AbH7zWllL0us7cihhci37eT1PvRs qGCb7l6VSGDBhhnZrJMAL0qkvMpA2jcblYw0252tCTFCtwuyFlq84q5aZ26B bnsm06y9sY; Authentication-Results: sj-dkim-2; header.From=versteb@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions(RAMS) as a working group item X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2009 12:06:44 -0000 We submitted version -00 of "draft-ietf-avt-rapid-acquisition-for-rtp". This is basically a name change from "draft-versteeg-avt-rapid-synchronization-for-rtp-03" to avoid confusion with other pending "synchronization" drafts. There were some issues remaining from -03 version that have already been identified on the list and technical breakout session. We are planning to address these issues in the next version of the draft. We hope to address the following areas in the next revision of the draft: - Section 7 - Define a method for vendor-specific and generic extensions to RAMS, lay out the intent to use FMT=3D=3D6 for all messages and to = have an (extensible) enumeration of the RAMS sub-FMTs - Section 8 - Elaborate SDP to describe the various use cases for RAMS - Section 13 - Define a single registry (FMT=3D=3D6) for all RAMS transactions, and then define Sub-FMT Values for RAMS Messages. Also define an extensible RAMS TLV space registry - We need to make some typographical corrections, mostly changing from RMS to RAMS. - We need to formalize the TLV definitions and extensions (both vendor and private extensions) - We need to register FMT=3D6 with IANA for RAMS and use sub-FMT values = to identify various RAMS messages - We need to clarify the SDP section based on the earlier discussion. The SDP example is still declarative and we are looking forward to include more examples as we move forward. - The IANA concerns section needs to be updated to reflect how to extend the RAMS protocol. - The unicast/multicast addresses need to be fixed according to the idnits tool.=20 Are there other issues that we need to address in the next revision of the draft? The authors would like to address these high priority issues in the next few days, so timely feedback would be appreciated. =20 Bill VerSteeg From Even.roni@huawei.com Wed May 13 05:22:20 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 913013A6ACF for ; Wed, 13 May 2009 05:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMCBF+pgifZm for ; Wed, 13 May 2009 05:22:19 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 17FE63A6A4F for ; Wed, 13 May 2009 05:21:21 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJL00BGB11U8D@szxga03-in.huawei.com> for avt@ietf.org; Wed, 13 May 2009 20:22:42 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJL00BOC11UWH@szxga03-in.huawei.com> for avt@ietf.org; Wed, 13 May 2009 20:22:42 +0800 (CST) Received: from windows8d787f9 (bzq-79-183-138-74.red.bezeqint.net [79.183.138.74]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJL00M2G11J2F@szxml02-in.huawei.com>; Wed, 13 May 2009 20:22:42 +0800 (CST) Date: Wed, 13 May 2009 15:22:10 +0300 From: Roni Even In-reply-to: <81B9B88E2F9D574AA5328A85547CDE9101303DA5@xmb-rtp-21d.amer.cisco.com> To: "'Bill Ver Steeg (versteb)'" , avt@ietf.org Message-id: <00dc01c9d3c5$7a323aa0$6e96afe0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=US-ASCII Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcnS4FBFJRh0kTNdSKKujynDJmWrDwAJMQ/AAC+GL9AAAGUFAA== References: <81B9B88E2F9D574AA5328A85547CDE91013038E4@xmb-rtp-21d.amer.cisco.com> <81B9B88E2F9D574AA5328A85547CDE9101303DA5@xmb-rtp-21d.amer.cisco.com> Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions(RAMS) as a working group item X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2009 12:22:20 -0000 Bill, Any changes that are not editorial should be presented to the list before they are added to the draft. The changes for section 8 and 13 can be added to the draft. For section 7 please send a suggestion to the list since I am not sure that there was a preferred way to do it. Thanks Roni Even AVT co-chair -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Bill Ver Steeg (versteb) Sent: Wednesday, May 13, 2009 3:08 PM To: avt@ietf.org Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions(RAMS) as a working group item We submitted version -00 of "draft-ietf-avt-rapid-acquisition-for-rtp". This is basically a name change from "draft-versteeg-avt-rapid-synchronization-for-rtp-03" to avoid confusion with other pending "synchronization" drafts. There were some issues remaining from -03 version that have already been identified on the list and technical breakout session. We are planning to address these issues in the next version of the draft. We hope to address the following areas in the next revision of the draft: - Section 7 - Define a method for vendor-specific and generic extensions to RAMS, lay out the intent to use FMT==6 for all messages and to have an (extensible) enumeration of the RAMS sub-FMTs - Section 8 - Elaborate SDP to describe the various use cases for RAMS - Section 13 - Define a single registry (FMT==6) for all RAMS transactions, and then define Sub-FMT Values for RAMS Messages. Also define an extensible RAMS TLV space registry - We need to make some typographical corrections, mostly changing from RMS to RAMS. - We need to formalize the TLV definitions and extensions (both vendor and private extensions) - We need to register FMT=6 with IANA for RAMS and use sub-FMT values to identify various RAMS messages - We need to clarify the SDP section based on the earlier discussion. The SDP example is still declarative and we are looking forward to include more examples as we move forward. - The IANA concerns section needs to be updated to reflect how to extend the RAMS protocol. - The unicast/multicast addresses need to be fixed according to the idnits tool. Are there other issues that we need to address in the next revision of the draft? The authors would like to address these high priority issues in the next few days, so timely feedback would be appreciated. Bill VerSteeg _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www.ietf.org/mailman/listinfo/avt From Even.roni@huawei.com Wed May 13 05:41:39 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECD573A683B for ; Wed, 13 May 2009 05:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BOUFzYtrZA1a for ; Wed, 13 May 2009 05:41:38 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 0BA9F3A6903 for ; Wed, 13 May 2009 05:40:50 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJL008IR1YB3L@szxga03-in.huawei.com> for avt@ietf.org; Wed, 13 May 2009 20:42:11 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJL00BH11YBWJ@szxga03-in.huawei.com> for avt@ietf.org; Wed, 13 May 2009 20:42:11 +0800 (CST) Received: from windows8d787f9 (bzq-79-183-138-74.red.bezeqint.net [79.183.138.74]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJL008PE1XO8P@szxml01-in.huawei.com>; Wed, 13 May 2009 20:42:11 +0800 (CST) Date: Wed, 13 May 2009 15:41:30 +0300 From: Roni Even In-reply-to: <81B9B88E2F9D574AA5328A85547CDE9101303DA5@xmb-rtp-21d.amer.cisco.com> To: "'Bill Ver Steeg (versteb)'" , avt@ietf.org Message-id: <00de01c9d3c8$32b6cad0$98246070$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=US-ASCII Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcnS4FBFJRh0kTNdSKKujynDJmWrDwAJMQ/AAC+GL9AAASCeQA== References: <81B9B88E2F9D574AA5328A85547CDE91013038E4@xmb-rtp-21d.amer.cisco.com> <81B9B88E2F9D574AA5328A85547CDE9101303DA5@xmb-rtp-21d.amer.cisco.com> Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions(RAMS) as a working group item X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2009 12:41:39 -0000 Hi, I have some others issues to add to this list 1. I suggest to add to the RAMS request an optional parameter that will allow the receiver to request that the unicast stream will be sent to the a port specified in this parameter instead of the port offered in the announcement. 2. The issue of RTP/RTCP multiplexing should be discussed, is it mandatory to use it. 3. The issue of FW/NAT traversal for the unicast stream should also be discussed. Thanks Roni Even -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Bill Ver Steeg (versteb) Sent: Wednesday, May 13, 2009 3:08 PM To: avt@ietf.org Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions(RAMS) as a working group item We submitted version -00 of "draft-ietf-avt-rapid-acquisition-for-rtp". This is basically a name change from "draft-versteeg-avt-rapid-synchronization-for-rtp-03" to avoid confusion with other pending "synchronization" drafts. There were some issues remaining from -03 version that have already been identified on the list and technical breakout session. We are planning to address these issues in the next version of the draft. We hope to address the following areas in the next revision of the draft: - Section 7 - Define a method for vendor-specific and generic extensions to RAMS, lay out the intent to use FMT==6 for all messages and to have an (extensible) enumeration of the RAMS sub-FMTs - Section 8 - Elaborate SDP to describe the various use cases for RAMS - Section 13 - Define a single registry (FMT==6) for all RAMS transactions, and then define Sub-FMT Values for RAMS Messages. Also define an extensible RAMS TLV space registry - We need to make some typographical corrections, mostly changing from RMS to RAMS. - We need to formalize the TLV definitions and extensions (both vendor and private extensions) - We need to register FMT=6 with IANA for RAMS and use sub-FMT values to identify various RAMS messages - We need to clarify the SDP section based on the earlier discussion. The SDP example is still declarative and we are looking forward to include more examples as we move forward. - The IANA concerns section needs to be updated to reflect how to extend the RAMS protocol. - The unicast/multicast addresses need to be fixed according to the idnits tool. Are there other issues that we need to address in the next revision of the draft? The authors would like to address these high priority issues in the next few days, so timely feedback would be appreciated. Bill VerSteeg _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www.ietf.org/mailman/listinfo/avt From gherlein@herlein.com Wed May 13 06:03:37 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97D853A67B6 for ; Wed, 13 May 2009 06:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.594 X-Spam-Level: X-Spam-Status: No, score=-1.594 tagged_above=-999 required=5 tests=[AWL=0.382, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5HGOiFNajusi for ; Wed, 13 May 2009 06:03:36 -0700 (PDT) Received: from mail-pz0-f117.google.com (mail-pz0-f117.google.com [209.85.222.117]) by core3.amsl.com (Postfix) with ESMTP id 964F93A6903 for ; Wed, 13 May 2009 06:03:36 -0700 (PDT) Received: by pzk15 with SMTP id 15so211273pzk.29 for ; Wed, 13 May 2009 06:05:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.214.12 with SMTP id m12mr331828wfg.45.1242219907022; Wed, 13 May 2009 06:05:07 -0700 (PDT) In-Reply-To: References: Date: Wed, 13 May 2009 06:05:06 -0700 Message-ID: <31d1be720905130605rd359d6wea0a47f567e4c6ba@mail.gmail.com> From: Greg Herlein To: David Singer Content-Type: multipart/alternative; boundary=000e0cd32d184a7f770469cadc82 Cc: http-live-streaming-review@group.apple.com, Ross Finlayson , avt@ietf.org Subject: Re: [AVT] iPhone streaming Internet-Draft posted X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2009 13:03:37 -0000 --000e0cd32d184a7f770469cadc82 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi David, I addressed some technical questions on May 7 and have had no response from anyone at Apple. Is this spec under active development at Apple? Greg On Tue, May 12, 2009 at 9:24 PM, David Singer wrote: > Hi, Ross. Thanks for looking at the spec. > > On May 5, 2009, at 8:39 AM, Ross Finlayson wrote: > > We appreciate feedback on the protocol. >>> >> >> Rather than invent yet another protocol, why not just implement a RTSP/RTP >> client on the iPhone instead? >> > > Distributing media as discrete files over HTTP gives content providers a > cost-effective way to scale to high demand by using existing CDN and HTTP > caching infrastructure. > > With this goal in mind, we're looking for technical feedback on the > specification. > > thanks, nice to hear from you, > > -- > David Singer > Multimedia Standards, Apple Inc. > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > -- Greg Herlein www.herlein.com --000e0cd32d184a7f770469cadc82 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi David,

I addressed some technical questions on May 7 and have had= no response from anyone at Apple.=A0 Is this spec under active development= at Apple?

Greg

On Tue, May 12, 20= 09 at 9:24 PM, David Singer <singer@apple.com> wrote:
Hi, Ross. Thanks = for looking at the spec.


On May 5, 2009, at 8:39 AM, Ross Finlayson wrote:

We appreciate feedback on the protocol.

Rather than invent yet another protocol, why not just implement a RTSP/RTP = client on the iPhone instead?

Distributing media as discrete files over HTTP gives content providers a co= st-effective way to scale to high demand by using existing CDN and HTTP cac= hing infrastructure.

With this goal in mind, we're looking for technical feedback on the spe= cification.

thanks, nice to hear from you,

--
David Singer
Multimedia Standards, Apple Inc.
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/avt



--
Greg Herlei= n
www.herlein.com
--000e0cd32d184a7f770469cadc82-- From Berlizova@spiritDSP.com Wed May 13 05:45:14 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73A113A6E97 for ; Wed, 13 May 2009 05:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.111 X-Spam-Level: X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[AWL=-0.963, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DiUAV1G-jYJK for ; Wed, 13 May 2009 05:45:08 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id 735713A6D12 for ; Wed, 13 May 2009 05:45:05 -0700 (PDT) Received: from mail-srv.spiritcorp.com (mail-srv.spiritcorp.com [192.168.125.3]) by mail3.spiritcorp.com (8.13.8/8.14.3) with SMTP id n4DCkZRR007587 for ; Wed, 13 May 2009 16:46:36 +0400 (MSD) (envelope-from Berlizova@spiritDSP.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9D3C8.D646451D" Date: Wed, 13 May 2009 16:46:29 +0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ietf-avt-rtp-ipmr-03 Thread-Index: AcnHY9zDr/fCw2IRQrSOnEAtgzkHpwMYdlaQ From: "Elena Berlizova" To: X-Scanned-By: MIMEDefang 2.64 on 192.168.125.15 X-Mailman-Approved-At: Wed, 13 May 2009 08:56:17 -0700 Subject: Re: [AVT] Comments on draft-ietf-avt-rtp-ipmr-03 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2009 12:45:14 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9D3C8.D646451D Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Hi, =20 Please find the responses below: =20 =20 1.=9A=9A=9A=9A=9A=9A=9A=9A The draft should have an author name at the = top, not just SPIRIT SDP, there is an author name at the end Sergey = Ikonin. 2.=9A=9A=9A=9A=9A=9A=9A=9A You describe the payload but it is not clear = to me how do you know the size of each speech frame. It may be good to = explain it if you can. =20 [Comment] The size of coded speech frame is variable. The Encoder's = algorithm decides what size of each frame is and returns it after = encoding. In order to save bandwidth the size is not placed into payload = obviously. But Decoder can calculate size by the content of coded frame = and returns it to the top level application. This way we can get a size = of each frame. Moreover there is a special service function that returns = frame size without total decoding. Should the explanation be inserted = into the draft?=20 =20 3.=9A=9A=9A=9A=9A=9A=9A=9A In section 3 RTP payload format you should = start with a section on RTP header usage. See for example RFC 5404. [Comment] will be corrected=20 4.=9A=9A=9A=9A=9A=9A=9A=9A In the security consideration you can use the = first two paragraph from RFC 5404 security section. [Comment] will be corrected=20 =20 5.=9A=9A=9A=9A=9A=9A=9A=9A You can add a section on congestion control, = this codec can handle congestion so it will be good to mention it. [Comment] will be corrected=20 6.=9A=9A=9A=9A=9A=9A=9A=9A You can add to section 5.2 a subsection on = offer answer considerstions =20 [Comment] We believe all needed signaling is already implemented = in-band. So there is no special consideration in this section indented. Perhaps it'd be reasonable to add something like this: =20 Offer/Answer Considerations No special considerations should be given for the use of IP-MR within = the offer/answer model. =20 =20 Some nits =20 1.=9A=9A=9A=9A=9A=9A=9A=9A In section 2=9A "This making the bit stream = scalable and allows reduce ..." 2.=9A=9A=9A=9A=9A=9A=9A=9A In section 2 " But because of the scalable = nature of IP-MR codec there is no need to duplicate the whole previous = frame - only the core layer may be retransmitted." 3.=9A=9A=9A=9A=9A=9A=9A=9A In section 3.2 "BR (3 bits): base rate for = core layer of frame(s) in this packet using the table for CR. " =20 Yours sincerely=20 Elena Berlizova=20 ________________________________ From: Roni Even [mailto:ron.even.tlv@gmail.com]=20 Sent: Monday, April 27, 2009 10:13 PM To: avt@ietf.org Subject: Comments on draft-ietf-avt-rtp-ipmr-03 =20 Hi,=20 I reviewed the draft and have the following comments most are editorial =20 1. The draft should have an author name at the top, not just SPIRIT = SDP, there is an author name at the end Sergey Ikonin. 2. You describe the payload but it is not clear to me how do you = know the size of each speech frame. It may be good to explain it if you = can. 3. In section 3 RTP payload format you should start with a section = on RTP header usage. See for example RFC 5404. 4. In the security consideration you can use the first two = paragraph from RFC 5404 security section. 5. You can add a section on congestion control, this codec can = handle congestion so it will be good to mention it. 6. You can add to section 5.2 a subsection on offer answer = considerstions =20 Some nits =20 1. In section 2 "This making the bit stream scalable and allows = reduce ..." 2. In section 2 " But because of the scalable nature of IP-MR codec = there is no need to duplicate the whole previous frame - only the core = layer may be retransmitted." 3. In section 3.2 "BR (3 bits): base rate for core layer of = frame(s) in this packet using the table for CR. " =20 =20 Thanks Roni Even =20 =20 =20 =20 =20 =20 ------_=_NextPart_001_01C9D3C8.D646451D Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable

Hi,

 =

Please find the = responses below:

 =

 =

1.=9A=9A=9A=9A=9A= =9A=9A=9A The draft should have an author name at the top, not just SPIRIT SDP, there is an = author name at the end Sergey Ikonin.

2.=9A=9A=9A=9A=9A= =9A=9A=9A You describe the payload but it is not clear to me how do you know the size of each = speech frame. It may be good to explain it if you = can.

 =

[Comment] The size of coded speech frame is variable. The Encoder's algorithm = decides what size of each frame is and returns it after encoding. In order to = save bandwidth the size is not placed into payload obviously. But Decoder can calculate size by the content of coded frame and returns it to the top = level application. This way we can get a size of each frame. Moreover there is = a special service function that returns frame size without total decoding. Should = the explanation be inserted into the draft? =

 =

3.=9A=9A=9A=9A=9A= =9A=9A=9A In section 3 RTP payload format you should start with a section on RTP header usage. = See for example RFC 5404.

[Comment] will be corrected

4.=9A=9A=9A=9A=9A= =9A=9A=9A In the security consideration you can use the first two paragraph from RFC 5404 security section.

[Comment] will be corrected

 =

5.=9A=9A=9A=9A=9A= =9A=9A=9A You can add a section on congestion control, this codec can handle congestion so it = will be good to mention it.

[Comment] will be corrected

6.=9A=9A=9A=9A=9A= =9A=9A=9A You can add to section 5.2 a subsection on offer answer = considerstions

 

[Comment] We believe all needed signaling is already implemented in-band. So there = is no special consideration in this section = indented.

Perhaps it'd be reasonable to add something like = this:

 

Offer/Answer Considerations

No special considerations should be given for the use of IP-MR within the offer/answer model.

 =

 =

Some = nits

 =

1.=9A=9A=9A=9A=9A= =9A=9A=9A In section 2=9A "This making the bit stream scalable and allows reduce = …"

2.=9A=9A=9A=9A=9A= =9A=9A=9A In section 2 " But because of the scalable nature of IP-MR codec there is no = need to duplicate the whole previous frame - only the core layer may be retransmitted."

3.=9A=9A=9A=9A=9A= =9A=9A=9A In section 3.2 "BR (3 bits): base rate for core layer of frame(s) in this packet = using the table for CR. "

 

Yours sincerely
Elena = Berlizova

From: Roni Even [mailto:ron.even.tlv@gmail.com]
Sent: Monday, April 27, = 2009 10:13 PM
To: avt@ietf.org
Subject: Comments on draft-ietf-avt-rtp-ipmr-03

 

Hi,

I reviewed the draft and have the following comments most are = editorial

 

1.      = The draft should have an author name at the top, not just = SPIRIT SDP, there is an author name at the end Sergey = Ikonin.

2.      = You describe the payload but it is not clear to me how do = you know the size of each speech frame. It may be good to explain it if you = can.

3.      = In section 3 RTP payload format you should start with a = section on RTP header usage. See for example RFC 5404.

4.      = In the security consideration you can use the first two = paragraph from RFC 5404 security section.

5.      = You can add a section on congestion control, this codec can = handle congestion so it will be good to mention it.

6.      = You can add to section 5.2 a subsection on offer answer considerstions

 

Some nits

 

1.      = In section 2  "This making the bit stream = scalable and allows reduce …"

2.      = In section 2 " But because of the scalable = nature of IP-MR codec there is no need to duplicate the whole previous = frame - only the core layer may be = retransmitted."

3.      = In section 3.2 "BR (3 bits): base rate for core layer = of frame(s) in this packet using the table for CR. = "

 

 

Thanks

Roni Even

 

 

 

 

 

 

------_=_NextPart_001_01C9D3C8.D646451D-- From Even.roni@huawei.com Wed May 13 10:02:41 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 216E03A6E7A for ; Wed, 13 May 2009 10:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OaW5L75vFXJ for ; Wed, 13 May 2009 10:02:34 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id BF39C3A6DFC for ; Wed, 13 May 2009 10:01:56 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJL00KQUE1IBJ@szxga02-in.huawei.com> for avt@ietf.org; Thu, 14 May 2009 01:03:18 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJL00DZ6E1IXW@szxga02-in.huawei.com> for avt@ietf.org; Thu, 14 May 2009 01:03:18 +0800 (CST) Received: from windows8d787f9 (bzq-79-183-138-74.red.bezeqint.net [79.183.138.74]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJL00JORE0UYV@szxml01-in.huawei.com>; Thu, 14 May 2009 01:03:18 +0800 (CST) Date: Wed, 13 May 2009 20:02:42 +0300 From: Roni Even In-reply-to: To: 'Elena Berlizova' , avt@ietf.org Message-id: <010801c9d3ec$a84ed110$f8ec7330$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_TjOeNBAYqOmyfENVt/wacg)" Content-language: en-us Thread-index: AcnHY9zDr/fCw2IRQrSOnEAtgzkHpwMYdlaQAAl7SgA= References: Subject: Re: [AVT] Comments on draft-ietf-avt-rtp-ipmr-03 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2009 17:02:41 -0000 This is a multipart message in MIME format. --Boundary_(ID_TjOeNBAYqOmyfENVt/wacg) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Hi Elena, I am OK with your responses, on number 2 it will be good to give some explanation in the draft and as for number 6 leave it as is. Please update the draft and I will start WGLC Roni Even From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Elena Berlizova Sent: Wednesday, May 13, 2009 3:46 PM To: avt@ietf.org Subject: Re: [AVT] Comments on draft-ietf-avt-rtp-ipmr-03 Hi, Please find the responses below: 1. The draft should have an author name at the top, not just SPIRIT SDP, there is an author name at the end Sergey Ikonin. 2. You describe the payload but it is not clear to me how do you know the size of each speech frame. It may be good to explain it if you can. [Comment] The size of coded speech frame is variable. The Encoder's algorithm decides what size of each frame is and returns it after encoding. In order to save bandwidth the size is not placed into payload obviously. But Decoder can calculate size by the content of coded frame and returns it to the top level application. This way we can get a size of each frame. Moreover there is a special service function that returns frame size without total decoding. Should the explanation be inserted into the draft? 3. In section 3 RTP payload format you should start with a section on RTP header usage. See for example RFC 5404. [Comment] will be corrected 4. In the security consideration you can use the first two paragraph from RFC 5404 security section. [Comment] will be corrected 5. You can add a section on congestion control, this codec can handle congestion so it will be good to mention it. [Comment] will be corrected 6. You can add to section 5.2 a subsection on offer answer considerstions [Comment] We believe all needed signaling is already implemented in-band. So there is no special consideration in this section indented. Perhaps it'd be reasonable to add something like this: Offer/Answer Considerations No special considerations should be given for the use of IP-MR within the offer/answer model. Some nits 1. In section 2 "This making the bit stream scalable and allows reduce ." 2. In section 2 " But because of the scalable nature of IP-MR codec there is no need to duplicate the whole previous frame - only the core layer may be retransmitted." 3. In section 3.2 "BR (3 bits): base rate for core layer of frame(s) in this packet using the table for CR. " Yours sincerely Elena Berlizova _____ From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: Monday, April 27, 2009 10:13 PM To: avt@ietf.org Subject: Comments on draft-ietf-avt-rtp-ipmr-03 Hi, I reviewed the draft and have the following comments most are editorial 1. The draft should have an author name at the top, not just SPIRIT SDP, there is an author name at the end Sergey Ikonin. 2. You describe the payload but it is not clear to me how do you know the size of each speech frame. It may be good to explain it if you can. 3. In section 3 RTP payload format you should start with a section on RTP header usage. See for example RFC 5404. 4. In the security consideration you can use the first two paragraph from RFC 5404 security section. 5. You can add a section on congestion control, this codec can handle congestion so it will be good to mention it. 6. You can add to section 5.2 a subsection on offer answer considerstions Some nits 1. In section 2 "This making the bit stream scalable and allows reduce ." 2. In section 2 " But because of the scalable nature of IP-MR codec there is no need to duplicate the whole previous frame - only the core layer may be retransmitted." 3. In section 3.2 "BR (3 bits): base rate for core layer of frame(s) in this packet using the table for CR. " Thanks Roni Even --Boundary_(ID_TjOeNBAYqOmyfENVt/wacg) Content-type: text/html; charset=US-ASCII Content-transfer-encoding: quoted-printable

Hi = Elena,

I am OK with your = responses, on number 2 it will be good to give some explanation in the draft and as = for number 6 leave it as is.

Please update the = draft and I will start WGLC

Roni = Even

 

From:= avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Elena Berlizova
Sent: Wednesday, May 13, 2009 3:46 PM
To: avt@ietf.org
Subject: Re: [AVT] Comments on = draft-ietf-avt-rtp-ipmr-03

 

Hi,

 

Please find the responses below:

 

 

1.         The draft = should have an author name at the top, not just SPIRIT SDP, there is an author = name at the end Sergey Ikonin.

2.         You = describe the payload but it is not clear to me how do you know the size of each = speech frame. It may be good to explain it if you can.

 

[Comment] The size of coded speech frame is variable. The = Encoder's algorithm decides what size of each frame is and returns it after = encoding. In order to save bandwidth the size is not placed into payload obviously. = But Decoder can calculate size by the content of coded frame and returns it = to the top level application. This way we can get a size of each frame. = Moreover there is a special service function that returns frame size without total = decoding. Should the explanation be inserted into the draft? =

 

3.         In = section 3 RTP payload format you should start with a section on RTP header usage. See = for example RFC 5404.

[Comment] will be corrected

4.         In the = security consideration you can use the first two paragraph from RFC 5404 security section.

[Comment] will be corrected

 

5.         You can = add a section on congestion control, this codec can handle congestion so it = will be good to mention it.

[Comment] will be corrected

6.         You can = add to section 5.2 a subsection on offer answer = considerstions

 

[Comment] We believe all needed signaling is already = implemented in-band. So there is no special consideration in this section = indented.

Perhaps it'd be reasonable to add something like = this:

 

Offer/Answer Considerations

No special considerations should be given for the use of = IP-MR within the offer/answer model.

 

 

Some nits

 

1.         In = section 2  "This making the bit stream scalable and allows reduce …"

2.         In = section 2 " But because of the scalable nature of IP-MR codec there is no = need to duplicate the whole previous frame - only the core layer may be retransmitted."

3.         In = section 3.2 "BR (3 bits): base rate for core layer of frame(s) in this packet = using the table for CR. "

 

Yours sincerely =
Elena Berlizova =

From:= Roni Even [mailto:ron.even.tlv@gmail.com]
Sent: Monday, April 27, 2009 10:13 PM
To: avt@ietf.org
Subject: Comments on draft-ietf-avt-rtp-ipmr-03

 

Hi,

I reviewed the draft and have the following = comments most are editorial

 

1.       The draft should have an = author name at the top, not just SPIRIT SDP, there is an author name at the end = Sergey Ikonin.

2.       You describe the payload = but it is not clear to me how do you know the size of each speech frame. It may be = good to explain it if you can.

3.       In section 3 RTP payload = format you should start with a section on RTP header usage. See for example RFC = 5404.

4.       In the security = consideration you can use the first two paragraph from RFC 5404 security = section.

5.       You can add a section on congestion control, this codec can handle congestion so it will be good = to mention it.

6.       You can add to section = 5.2 a subsection on offer answer considerstions

 

Some nits

 

1.       In section 2 =  "This making the bit stream scalable and allows reduce = …"

2.       In section 2 " But = because of the scalable nature of IP-MR codec there is no need to duplicate = the whole previous frame - only the core layer may be = retransmitted."

3.       In section 3.2 "BR = (3 bits): base rate for core layer of frame(s) in this packet using the table = for CR. "

 

 

Thanks

Roni Even

 

 

 

 

 

 

--Boundary_(ID_TjOeNBAYqOmyfENVt/wacg)-- From alex.giladi@gmail.com Wed May 13 10:14:57 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37F5E3A6CC4 for ; Wed, 13 May 2009 10:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0L5KkZnzBnWl for ; Wed, 13 May 2009 10:14:56 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id 393CD3A6906 for ; Wed, 13 May 2009 10:14:56 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 9so228385eyd.31 for ; Wed, 13 May 2009 10:16:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=2nlSKKf8jEwyyRjaRYNKPyJxExKipBa0keAJwEHF0ZI=; b=MU0c0hvVCV9NYul4KDlsQFBh3EKGw1pTGAVVMqzxCTDSdqgJCMb9DFgjvFZAsU6vP6 KYHKtO0H6HraYBuuUfQ12E0qBTU77letQXf6PupbVH7HNjso6e8Hfu6WoQ9nJHMQj4z0 o7lOUGgwG/uLhmC52XfdXOYAKtVH73mHx4zzY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=BBu1NplSb+td0Y2Qh14+tBXRpxxALMX928CZv66Wjn9ITOB3hiWie3/LFZNoy9WcdM zIEGwoIReI3UGIWdbN2quYUm8naX0/X9eUzVkts0IS3/Wcb/OdcX5uFhAkVvGMUFP7Ov NKuS3ca0IwrwU28O1VXQffY13u3Wrx3rzX3ds= MIME-Version: 1.0 Received: by 10.216.17.212 with SMTP id j62mr509242wej.132.1242234985136; Wed, 13 May 2009 10:16:25 -0700 (PDT) In-Reply-To: References: Date: Wed, 13 May 2009 13:16:25 -0400 Message-ID: <57a9e15d0905131016k7cddc67aydf0927c03e51f41@mail.gmail.com> From: Alex Giladi To: David Singer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: http-live-streaming-review@group.apple.com, Ross Finlayson , avt@ietf.org Subject: Re: [AVT] iPhone streaming Internet-Draft posted X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2009 17:14:57 -0000 David, But why not re-use RTSP, just embedding it into HTTP? Alex. On Wed, May 13, 2009 at 12:24 AM, David Singer wrote: > Hi, Ross. Thanks for looking at the spec. > > On May 5, 2009, at 8:39 AM, Ross Finlayson wrote: > >>> We appreciate feedback on the protocol. >> >> Rather than invent yet another protocol, why not just implement a RTSP/RTP >> client on the iPhone instead? > > Distributing media as discrete files over HTTP gives content providers a > cost-effective way to scale to high demand by using existing CDN and HTTP > caching infrastructure. > > With this goal in mind, we're looking for technical feedback on the > specification. > > thanks, nice to hear from you, > > -- > David Singer > Multimedia Standards, Apple Inc. > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > From john.lazzaro@gmail.com Wed May 13 14:52:43 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11EB23A6BFF for ; Wed, 13 May 2009 14:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRGdhD9cVBrP for ; Wed, 13 May 2009 14:52:41 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by core3.amsl.com (Postfix) with ESMTP id 876DA3A693D for ; Wed, 13 May 2009 14:52:41 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 3so989061ywj.49 for ; Wed, 13 May 2009 14:54:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=yrhVyzSoXCkwhv0HXLblH7bhk74BO0UWkbaekFzeKqw=; b=xkgbBP2Ud5ewArJ+yBLqFopYuOM6t2YDy3BQ9nTnv9Y/Ro1c24sLnG2KCJj6xFv/SQ MaKG3yfofS/CkU1dSB+/E0gwekJlE6w1dVeEk9v4hAtERaMl7Gh4U/DR0yRVeRJE7TRE hFEIYsIioESiig+7wUyRJUmCJuJ3H9HdIuCVk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=Ju8CWWtj86Omly7Br9wlEPb14buL8tXGRyu+N9DiYhNLeufA/CfaupK1+vsOb7YOaU XAoZywdhijxPfy93JApmUxGkYCPlXCIEvNcxhOnpxM0chwjHnjgia61kRxV3hgfqqVGs AQ0Uobe19FXUk5GDEB+vypvkhZwBThUrsSogQ= MIME-Version: 1.0 Received: by 10.100.166.13 with SMTP id o13mr1882260ane.103.1242251652094; Wed, 13 May 2009 14:54:12 -0700 (PDT) Date: Wed, 13 May 2009 14:54:12 -0700 Message-ID: <302f570905131454t72afdfd0rb5dba388a13c467c@mail.gmail.com> From: John Lazzaro To: avt@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [AVT] iPhone streaming Internet-Draft posted X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2009 21:52:43 -0000 From: Alex Giladi > David, > But why not re-use RTSP, just embedding it into HTTP? > Alex. This was proposed back in 2001 in MMUSIC, and did not reach consensus, see the snippet below from the MMUSIC minutes of IETF 51: 10. Tunneling RTSP/RTP/RTCP in HTTP (draft-gentric-avt-rtsp-http-00.txt) ===================================================== RTSP describes a TCP-based streaming mode. This includes interleaved RTP/RTCP packets. The draft proposal is to extend this to HTTP-only firewalls. Source of proposal: Internet Streaming Media Alliance. The basic proposal is to use HTTP to create a channel in each direction. The authors are looking for more ideas and thoughts on how to proceed. Melinda Shore expressed her disagreement with the proposal, because it raises serious security concerns. Its whole thrust is to violating site security policy. It would be more consistent with network policy to use Jonathan's SIP approach. If the draft is accepted, HTTP might become characterized as "Horrible Trashcan Transport Protocol". Jonathan Rosenberg noted that it is too late to salvage HTTP's reputation: RFC 3093 "IP Over HTTP" already describes how to do it. Mark Handley also expressed his concern with the security implications. Port 554 is allocated for RTSP; managers can open it if they want to. Apparently some firewall vendors already block strange uses of HTTP. Site administrators are aware of this sort of tunneling and are asking firewall vendors for controls. Joerg Ott ruled that the responses he had heard make it clear that the proposal is going nowhere in the MMUSIC WG. -- John Lazzaro http://www.cs.berkeley.edu/~lazzaro john [dot] lazzaro [at] gmail [dot] com From abegen@cisco.com Wed May 13 16:34:35 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD28828C1FF for ; Wed, 13 May 2009 16:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.41 X-Spam-Level: X-Spam-Status: No, score=-6.41 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9D2JIsf0KK2t for ; Wed, 13 May 2009 16:34:34 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 7B8B728C0F7 for ; Wed, 13 May 2009 16:34:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,191,1241395200"; d="scan'208";a="165268543" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 13 May 2009 23:36:07 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n4DNa7VF027967; Wed, 13 May 2009 16:36:07 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n4DNa4dE021613; Wed, 13 May 2009 23:36:07 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 May 2009 16:36:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 May 2009 16:35:49 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54094C3DBF@xmb-sjc-215.amer.cisco.com> In-Reply-To: <00dc01c9d3c5$7a323aa0$6e96afe0$%roni@huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions(RAMS) as a working group item Thread-Index: AcnS4FBFJRh0kTNdSKKujynDJmWrDwAJMQ/AAC+GL9AAAGUFAAAXW2jQ References: <81B9B88E2F9D574AA5328A85547CDE91013038E4@xmb-rtp-21d.amer.cisco.com><81B9B88E2F9D574AA5328A85547CDE9101303DA5@xmb-rtp-21d.amer.cisco.com> <00dc01c9d3c5$7a323aa0$6e96afe0$%roni@huawei.com> From: "Ali C. Begen (abegen)" To: "Roni Even" , "Bill Ver Steeg (versteb)" , X-OriginalArrivalTime: 13 May 2009 23:36:03.0952 (UTC) FILETIME=[94A47700:01C9D423] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4796; t=1242257767; x=1243121767; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20RE=3A=20[AVT]=20Adopting=20Rapid=20Acquisition= 20of=20Multicast=20RTP=09Sessions(RAMS)=20as=20a=20working=2 0group=20item |Sender:=20; bh=GBjhDcClp0deS9iZswk4ZxEFYzxn9pLftED05p5cRIA=; b=V6s6SHgq7qS5FVummvdCV5yy92blet7v3/j3ApNte4/y5k4ik/9TSMIMdv ri9SkFin3NBbGkjYK1CiKv39cNU0MQReB0cRHhREM5N7IKZ0YxvFddvWAurj vT+rEIjLtB; Authentication-Results: sj-dkim-4; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions(RAMS) as a working group item X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2009 23:34:35 -0000 Inline. > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Roni Even > Sent: Wednesday, May 13, 2009 5:22 AM > To: Bill Ver Steeg (versteb); avt@ietf.org > Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP = Sessions(RAMS) as a working > group item >=20 > Bill, > Any changes that are not editorial should be presented to the list = before > they are added to the draft. >=20 > The changes for section 8 and 13 can be added to the draft. OK. =20 > For section 7 please send a suggestion to the list since I am not sure = that > there was a preferred way to do it. As we proposed previously (actually since version -00), we are using TLV = elements to provide the extension mechanism and avoid the problems = associated with using special values in various fields. In the update, = we are saying that the TLV types will be registered with IANA in a new = registry. Some of the available type space is reserved for = vendor-neutral extensions whereas the rest is for private extensions. We = briefly outline the requirements for registering the vendor-neutral = extensions. As proposed by Ingemar previously in the breakout session, we are now = using sub FMT fields to specify the individual RAMS messages (request, = information and termination). So, for the message format we have = something like: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SFMT=3D1 | Optional TLV-encoded Fields | +-+-+-+-+-+-+-+-+ | : Optional TLV-encoded Fields (and Padding, if needed) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 Further RAMS message types could be defined in the future, if needed. We wanna conclude these issues quickly and address the remaining open = items (you mentioned some of them already) in the next revision. BR, -acbegen=20 > Thanks > Roni Even > AVT co-chair >=20 > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Bill > Ver Steeg (versteb) > Sent: Wednesday, May 13, 2009 3:08 PM > To: avt@ietf.org > Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP > Sessions(RAMS) as a working group item >=20 >=20 >=20 > We submitted version -00 of = "draft-ietf-avt-rapid-acquisition-for-rtp". > This is basically a name change from > "draft-versteeg-avt-rapid-synchronization-for-rtp-03" to avoid = confusion > with other pending "synchronization" drafts. >=20 > There were some issues remaining from -03 version that have already = been > identified on the list and technical breakout session. We are planning > to address these issues in the next version of the draft. >=20 > We hope to address the following areas in the next revision of the > draft: >=20 > - Section 7 - Define a method for vendor-specific and generic = extensions > to RAMS, lay out the intent to use FMT=3D=3D6 for all messages and to = have > an (extensible) enumeration of the RAMS sub-FMTs > - Section 8 - Elaborate SDP to describe the various use cases for RAMS > - Section 13 - Define a single registry (FMT=3D=3D6) for all RAMS > transactions, and then define Sub-FMT Values for RAMS Messages. Also > define an extensible RAMS TLV space registry >=20 > - We need to make some typographical corrections, mostly changing from > RMS to RAMS. > - We need to formalize the TLV definitions and extensions (both vendor > and private extensions) > - We need to register FMT=3D6 with IANA for RAMS and use sub-FMT = values to > identify various RAMS messages > - We need to clarify the SDP section based on the earlier discussion. > The SDP example is still declarative and we are looking forward to > include more examples as we move forward. > - The IANA concerns section needs to be updated to reflect how to = extend > the RAMS protocol. > - The unicast/multicast addresses need to be fixed according to the > idnits tool. >=20 > Are there other issues that we need to address in the next revision of > the draft? The authors would like to address these high priority = issues > in the next few days, so timely feedback would be appreciated. >=20 >=20 > Bill VerSteeg > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt >=20 > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From abegen@cisco.com Wed May 13 16:45:17 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22A8328C1FF for ; Wed, 13 May 2009 16:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.412 X-Spam-Level: X-Spam-Status: No, score=-6.412 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZ4QZ9Lk+Hg3 for ; Wed, 13 May 2009 16:45:15 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id E65063A6C4E for ; Wed, 13 May 2009 16:45:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,191,1241395200"; d="scan'208";a="75884186" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 13 May 2009 23:46:48 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n4DNkmdJ024948; Wed, 13 May 2009 16:46:48 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n4DNkea2003599; Wed, 13 May 2009 23:46:48 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 May 2009 16:46:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 May 2009 16:46:18 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54094C3DC9@xmb-sjc-215.amer.cisco.com> In-Reply-To: <00de01c9d3c8$32b6cad0$98246070$%roni@huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions(RAMS) as a working group item Thread-Index: AcnS4FBFJRh0kTNdSKKujynDJmWrDwAJMQ/AAC+GL9AAASCeQAAW+Vvg References: <81B9B88E2F9D574AA5328A85547CDE91013038E4@xmb-rtp-21d.amer.cisco.com><81B9B88E2F9D574AA5328A85547CDE9101303DA5@xmb-rtp-21d.amer.cisco.com> <00de01c9d3c8$32b6cad0$98246070$%roni@huawei.com> From: "Ali C. Begen (abegen)" To: "Roni Even" , "Bill Ver Steeg (versteb)" , X-OriginalArrivalTime: 13 May 2009 23:46:46.0307 (UTC) FILETIME=[13840F30:01C9D425] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4360; t=1242258408; x=1243122408; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20RE=3A=20[AVT]=20Adopting=20Rapid=20Acquisition= 20of=20Multicast=20RTP=09Sessions(RAMS)=20as=20a=20working=2 0group=20item |Sender:=20; bh=GE+lMbQ0/zQ9pOWUcz27UDy4MuaQReEwGR/n/ByshZE=; b=F00B5i+l4U4RmvR+rG+i4ZfWC2qGdwvujK6bYnhq/xmnELht0rrlmZx7Ah LBzv6lrvarne0TvAT9X5ANHFuJKUopVlJW/ZUqwPSmsKNvEjeP00ILKiY+zd ks2zWZYncO; Authentication-Results: sj-dkim-3; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions(RAMS) as a working group item X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2009 23:45:17 -0000 Roni, There are a few other important issues that we need WG input on: - The scenarios where there are multiple SSRC-multiplexed RTP streams in = a single RTP session. Will RAMS apply to individual streams or the whole = session? Similarly, what happens when the same multicast session carries = multiple RTP sessions (same multicast address but different ports). = Clearly, such cases will exist. We have a draft text that discusses = different scenarios and what needs to be done in each such cases. But = before we move forward, we would like to hear WG input. Managing = multiple bursts simultaneously requires some details. - The security section needs to be completed as well as the NAT section. Some comments inline. > I have some others issues to add to this list >=20 > 1. I suggest to add to the RAMS request an optional parameter that = will > allow the receiver to request that the unicast stream will be sent to = the a > port specified in this parameter instead of the port offered in the > announcement. This is tricky. Remember that the RAMS request message goes to the = Feedback Target of the primary multicast session but the burst comes = from the retransmission server. They could be the same entity or = different ones. Any solution should consider this in its design. =20 > 2. The issue of RTP/RTCP multiplexing should be discussed, is it = mandatory > to use it. It is not mandatory. Even if we made it mandatory, it would not help us = with the issue you describe above. Muxing only simplifies NAT traversal. =20 > 3. The issue of FW/NAT traversal for the unicast stream should also be > discussed. Indeed. The NAT section is TBC. -acbegen =20 >=20 > Thanks > Roni Even >=20 > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Bill > Ver Steeg (versteb) > Sent: Wednesday, May 13, 2009 3:08 PM > To: avt@ietf.org > Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP > Sessions(RAMS) as a working group item >=20 >=20 >=20 > We submitted version -00 of = "draft-ietf-avt-rapid-acquisition-for-rtp". > This is basically a name change from > "draft-versteeg-avt-rapid-synchronization-for-rtp-03" to avoid = confusion > with other pending "synchronization" drafts. >=20 > There were some issues remaining from -03 version that have already = been > identified on the list and technical breakout session. We are planning > to address these issues in the next version of the draft. >=20 > We hope to address the following areas in the next revision of the > draft: >=20 > - Section 7 - Define a method for vendor-specific and generic = extensions > to RAMS, lay out the intent to use FMT=3D=3D6 for all messages and to = have > an (extensible) enumeration of the RAMS sub-FMTs > - Section 8 - Elaborate SDP to describe the various use cases for RAMS > - Section 13 - Define a single registry (FMT=3D=3D6) for all RAMS > transactions, and then define Sub-FMT Values for RAMS Messages. Also > define an extensible RAMS TLV space registry >=20 > - We need to make some typographical corrections, mostly changing from > RMS to RAMS. > - We need to formalize the TLV definitions and extensions (both vendor > and private extensions) > - We need to register FMT=3D6 with IANA for RAMS and use sub-FMT = values to > identify various RAMS messages > - We need to clarify the SDP section based on the earlier discussion. > The SDP example is still declarative and we are looking forward to > include more examples as we move forward. > - The IANA concerns section needs to be updated to reflect how to = extend > the RAMS protocol. > - The unicast/multicast addresses need to be fixed according to the > idnits tool. >=20 > Are there other issues that we need to address in the next revision of > the draft? The authors would like to address these high priority = issues > in the next few days, so timely feedback would be appreciated. >=20 >=20 > Bill VerSteeg > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt >=20 > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From abegen@cisco.com Wed May 13 17:35:05 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3AB93A68A3 for ; Wed, 13 May 2009 17:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.414 X-Spam-Level: X-Spam-Status: No, score=-6.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UvzLGABosUmb for ; Wed, 13 May 2009 17:35:04 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id D4EE93A67BD for ; Wed, 13 May 2009 17:35:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,191,1241395200"; d="scan'208";a="165280692" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 14 May 2009 00:36:37 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n4E0abrh015883 for ; Wed, 13 May 2009 17:36:37 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n4E0abDs023801 for ; Thu, 14 May 2009 00:36:37 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 May 2009 17:36:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Wed, 13 May 2009 17:36:31 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54094C3DF7@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-begen-avt-rapid-sync-rtcp-xr-01 Thread-Index: AcnUKoG+5exPU6+kThK+3c2eyekbTAAAA68A From: "Ali C. Begen (abegen)" To: X-OriginalArrivalTime: 14 May 2009 00:36:37.0574 (UTC) FILETIME=[0A732E60:01C9D42C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3802; t=1242261397; x=1243125397; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20draft-begen-avt-rapid-sync-rtcp-xr-01=20 |Sender:=20; bh=8YnEudP4t2kobLjnFP6EleKD/hBUzuHjROVeH0m9N5o=; b=AnQNoqd4QxlPKKWZtItnvp2iW7dTHDZO7McvrFRhMDvQpVNzappdZ92esc sZPbsICNixvJ7m2smfCbyqwuaX7XMt66vxw32sIFnr7fomikX2bKN6jFiAO0 2oIgMFy69d; Authentication-Results: sj-dkim-4; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [AVT] draft-begen-avt-rapid-sync-rtcp-xr-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2009 00:35:06 -0000 SGkgZXZlcnlvbmUsDQoNCkJhc2VkIG9uIHRoZSBjb21tZW50cyByZWNlaXZlZCBmb3IgdGhlIGlu aXRpYWwgdmVyc2lvbiwgd2UgcmV2aXNlZCB0aGUgWFIgZHJhZnQuIFRoaXMgWFIgcmVwb3J0IHBy b3ZpZGVzIGRldGFpbGVkIGluZm8gYWJvdXQgdGhlIGFjcXVpc2l0aW9uIG9mIHRoZSBtdWx0aWNh c3Qgc2Vzc2lvbnMuIA0KDQpJbiB0aGlzIHZlcnNpb24sIHRoZSBYUiByZXBvcnQgY2FuIGJlIHVz ZWQgYm90aCB3aXRoIGFuZCB3aXRob3V0IHRoZSBSQU1TIG1ldGhvZCAoZHJhZnQtaWV0Zi1hdnQt cmFwaWQtYWNxdWlzaXRpb24tZm9yLXJ0cCkuIEl0IGlzIGV4dGVuc2libGUgZW5vdWdoIHRvIGJl IHVzZWQgd2l0aCBhbnkgb3RoZXIgYXBwcm9hY2ggdGhhdCBwcm92aWRlcyByYXBpZCBhY3F1aXNp dGlvbiBhcyB3ZWxsLiBUaHVzLCB3ZSBjaGFuZ2VkIHRoZSBuYW1lIG9mIHRoZSByZXBvcnQgYmxv Y2sgdG8gIk11bHRpY2FzdCBhY3F1aXNpdGlvbi4iIFdlIGNvbXBsZXRlZCBhbGwgbWlzc2luZyBz ZWN0aW9ucy4NCg0KUGxlYXNlIHJldmlldyBpdCBhbmQgcHJvdmlkZSB5b3VyIGZlZWRiYWNrLiBX ZSB3b3VsZCBsaWtlIHRvIGdldCB0aGlzIHdvcmsgYWRvcHRlZCBieSBBVlQgYW5kIGhhdmUgaXQg bW92ZSBmb3J3YXJkIHdpdGggdGhlIFJBTVMgZHJhZnQuDQoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWJlZ2VuLWF2dC1yYXBpZC1zeW5jLXJ0Y3AteHItMDEudHh0 DQoNCi1hY2JlZ2VuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBJRVRGIEkt RCBTdWJtaXNzaW9uIFRvb2wgW21haWx0bzppZHN1Ym1pc3Npb25AaWV0Zi5vcmddIA0KU2VudDog V2VkbmVzZGF5LCBNYXkgMTMsIDIwMDkgNToyNCBQTQ0KVG86IEFsaSBDLiBCZWdlbiAoYWJlZ2Vu KQ0KQ2M6IEVyaWMgRnJpZWRyaWNoIChlZnJpZWRyaSkNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiBmb3IgZHJhZnQtYmVnZW4tYXZ0LXJhcGlkLXN5bmMtcnRjcC14ci0wMSANCg0K DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtYmVnZW4tYXZ0LXJhcGlkLXN5bmMtcnRjcC14 ci0wMS50eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1bHkgc3VibWl0dGVkIGJ5IEFsaSBCZWdlbiBhbmQg cG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtYmVnZW4t YXZ0LXJhcGlkLXN5bmMtcnRjcC14cg0KUmV2aXNpb246CSAwMQ0KVGl0bGU6CQkgTXVsdGljYXN0 IEFjcXVpc2l0aW9uIFJlcG9ydCBCbG9jayBUeXBlIGZvciBSVENQIFhSDQpDcmVhdGlvbl9kYXRl OgkgMjAwOS0wNS0xMw0KV0cgSUQ6CQkgSW5kZXBlbmRlbnQgU3VibWlzc2lvbg0KTnVtYmVyX29m X3BhZ2VzOiAyMA0KDQpBYnN0cmFjdDoNCkluIG1vc3QgUlRQLWJhc2VkIG11bHRpY2FzdCBhcHBs aWNhdGlvbnMsIHRoZSBSVFAgc291cmNlIHNlbmRzIGludGVyLQ0KcmVsYXRlZCBkYXRhLiAgRHVl IHRvIHRoaXMgaW50ZXJkZXBlbmRlbmN5LCByYW5kb21seSBqb2luaW5nIFJUUA0KcmVjZWl2ZXJz IHVzdWFsbHkgY2Fubm90IHN0YXJ0IGNvbnN1bWluZyB0aGUgbXVsdGljYXN0IGRhdGEgcmlnaHQN CmFmdGVyIHRoZXkgam9pbiB0aGUgc2Vzc2lvbi4gIFRodXMsIHRoZXkgb2Z0ZW4gZXhwZXJpZW5j ZSBhIHJhbmRvbQ0KYWNxdWlzaXRpb24gZGVsYXkuICBPbmUgYXBwcm9hY2ggdG8gcmVkdWNlIHRo aXMgZGVsYXkgaXMgdG8gdXNlIGFuDQphdXhpbGlhcnkgdW5pY2FzdCBSVFAgc2Vzc2lvbiB3aXRo IGEgcmV0cmFuc21pc3Npb24gc2VydmVyIHRvIHJlY2VpdmUNCmEgYnVyc3Qgc3RyZWFtIHRoYXQg ZmFjaWxpdGF0ZXMgcmFwaWQgYWNxdWlzaXRpb24gb2YgdGhlIG11bHRpY2FzdA0Kc3RyZWFtLiAg QW4gUlRQIHJlY2VpdmVyIG1heSB1c2UgdGhpcyBhcHByb2FjaCAob3IgYW55IG90aGVyDQphcHBy b2FjaCkgdG8gYWNoaWV2ZSByYXBpZCBhY3F1aXNpdGlvbi4gIFlldCwgZHVlIHRvIHZhcmlvdXMg ZmFjdG9ycywNCnBlcmZvcm1hbmNlIG9mIHRoZSByYXBpZCBhY3F1aXNpdGlvbiBtZXRob2RzIHVz dWFsbHkgdmFyaWVzLg0KRnVydGhlcm1vcmUsIGluIHNvbWUgY2FzZXMgdGhlIFJUUCByZWNlaXZl ciBtYXkgKG9yIG1heSBoYXZlIHRvKSBkbyBhDQpzaW1wbGUgbXVsdGljYXN0IGpvaW4uICBGb3Ig cXVhbGl0eSByZXBvcnRpbmcsIG1vbml0b3JpbmcgYW5kDQpkaWFnbm9zdGljcyBwdXJwb3Nlcywg aXQgaXMgaW1wb3J0YW50IHRvIGNvbGxlY3QgZGV0YWlsZWQgaW5mb3JtYXRpb24NCmZyb20gdGhl IFJUUCByZWNlaXZlcnMgYWJvdXQgdGhlaXIgYWNxdWlzaXRpb24gZXhwZXJpZW5jZXMuICBUaGlz DQpkb2N1bWVudCBhZGRyZXNzZXMgdGhpcyBpc3N1ZSBieSBkZWZpbmluZyBhIG5ldyByZXBvcnQg YmxvY2sgdHlwZSwNCmNhbGxlZCBNdWx0aWNhc3QgQWNxdWlzaXRpb24gKE1BKSBSZXBvcnQgQmxv Y2ssIHdpdGhpbiB0aGUgZnJhbWV3b3JrDQpvZiBSVFAgQ29udHJvbCBQcm90b2NvbCAoUlRDUCkg RXh0ZW5kZWQgUmVwb3J0cyAoWFIpLiAgVGhpcyBkb2N1bWVudA0KYWxzbyBkZWZpbmVzIHRoZSBu ZWNlc3Nhcnkgc2lnbmFsaW5nIG9mIHRoZSBuZXcgTUEgcmVwb3J0IGJsb2NrIHR5cGUNCmluIHRo ZSBTZXNzaW9uIERlc2NyaXB0aW9uIFByb3RvY29sIChTRFApLg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIA0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0Lg0KDQoNCg== From Even.roni@huawei.com Wed May 13 23:54:47 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C4113A6883 for ; Wed, 13 May 2009 23:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.268 X-Spam-Level: X-Spam-Status: No, score=0.268 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, SARE_RECV_BEZEQINT_B=0.763] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZFC9ZFe29Bi for ; Wed, 13 May 2009 23:54:46 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 952B13A67FA for ; Wed, 13 May 2009 23:54:45 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJM004EJGLJV6@szxga02-in.huawei.com> for avt@ietf.org; Thu, 14 May 2009 14:56:07 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJM000SVGLJ2U@szxga02-in.huawei.com> for avt@ietf.org; Thu, 14 May 2009 14:56:07 +0800 (CST) Received: from windows8d787f9 (bzq-82-81-43-87.red.bezeqint.net [82.81.43.87]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJM0030GGL4N7@szxml01-in.huawei.com>; Thu, 14 May 2009 14:56:07 +0800 (CST) Date: Thu, 14 May 2009 09:55:22 +0300 From: Roni Even In-reply-to: <04CAD96D4C5A3D48B1919248A8FE0D54094C3DC9@xmb-sjc-215.amer.cisco.com> To: "'Ali C. Begen (abegen)'" , "'Bill Ver Steeg (versteb)'" , avt@ietf.org Message-id: <000901c9d460$ffeb7620$ffc26260$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcnS4FBFJRh0kTNdSKKujynDJmWrDwAJMQ/AAC+GL9AAASCeQAAW+VvgAA8Nx7A= References: <81B9B88E2F9D574AA5328A85547CDE91013038E4@xmb-rtp-21d.amer.cisco.com> <81B9B88E2F9D574AA5328A85547CDE9101303DA5@xmb-rtp-21d.amer.cisco.com> <00de01c9d3c8$32b6cad0$98246070$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D54094C3DC9@xmb-sjc-215.amer.cisco.com> Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions(RAMS) as a working group item X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2009 06:54:47 -0000 Ali, "This is tricky. Remember that the RAMS request message goes to the Feedback Target of the primary multicast session but the burst comes from the retransmission server. They could be the same entity or different ones. Any solution should consider this in its design." >From the draft " Editor's note: As stated above, FT, Burst Source and Retransmission Source are logical entities. For efficiency and simplicity, they MAY be implemented by a single physical Retransmission Server (RS). In a number of places throughout this document we assume (and explicitly state so) that all three are implemented by the same physical entity and therefore share the same IP address and the port number. The authors look to the AVT community for recommendations on whether this is sufficient or the mechanism has to explicitly address other topologies where FT, Burst Source and Retransmission Source are not co-located." My understanding is that having a single physical entity is the assumption of this work and any other architecture is for further study. BTW: figure 2 has feedback target as part of the retransmission server, I think that you meant retransmission source for the burst. Roni -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ali C. Begen (abegen) Sent: Thursday, May 14, 2009 2:46 AM To: Roni Even; Bill Ver Steeg (versteb); avt@ietf.org Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions(RAMS) as a working group item Roni, There are a few other important issues that we need WG input on: - The scenarios where there are multiple SSRC-multiplexed RTP streams in a single RTP session. Will RAMS apply to individual streams or the whole session? Similarly, what happens when the same multicast session carries multiple RTP sessions (same multicast address but different ports). Clearly, such cases will exist. We have a draft text that discusses different scenarios and what needs to be done in each such cases. But before we move forward, we would like to hear WG input. Managing multiple bursts simultaneously requires some details. - The security section needs to be completed as well as the NAT section. Some comments inline. > I have some others issues to add to this list > > 1. I suggest to add to the RAMS request an optional parameter that will > allow the receiver to request that the unicast stream will be sent to the a > port specified in this parameter instead of the port offered in the > announcement. This is tricky. Remember that the RAMS request message goes to the Feedback Target of the primary multicast session but the burst comes from the retransmission server. They could be the same entity or different ones. Any solution should consider this in its design. > 2. The issue of RTP/RTCP multiplexing should be discussed, is it mandatory > to use it. It is not mandatory. Even if we made it mandatory, it would not help us with the issue you describe above. Muxing only simplifies NAT traversal. > 3. The issue of FW/NAT traversal for the unicast stream should also be > discussed. Indeed. The NAT section is TBC. -acbegen > > Thanks > Roni Even > > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Bill > Ver Steeg (versteb) > Sent: Wednesday, May 13, 2009 3:08 PM > To: avt@ietf.org > Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP > Sessions(RAMS) as a working group item > > > > We submitted version -00 of "draft-ietf-avt-rapid-acquisition-for-rtp". > This is basically a name change from > "draft-versteeg-avt-rapid-synchronization-for-rtp-03" to avoid confusion > with other pending "synchronization" drafts. > > There were some issues remaining from -03 version that have already been > identified on the list and technical breakout session. We are planning > to address these issues in the next version of the draft. > > We hope to address the following areas in the next revision of the > draft: > > - Section 7 - Define a method for vendor-specific and generic extensions > to RAMS, lay out the intent to use FMT==6 for all messages and to have > an (extensible) enumeration of the RAMS sub-FMTs > - Section 8 - Elaborate SDP to describe the various use cases for RAMS > - Section 13 - Define a single registry (FMT==6) for all RAMS > transactions, and then define Sub-FMT Values for RAMS Messages. Also > define an extensible RAMS TLV space registry > > - We need to make some typographical corrections, mostly changing from > RMS to RAMS. > - We need to formalize the TLV definitions and extensions (both vendor > and private extensions) > - We need to register FMT=6 with IANA for RAMS and use sub-FMT values to > identify various RAMS messages > - We need to clarify the SDP section based on the earlier discussion. > The SDP example is still declarative and we are looking forward to > include more examples as we move forward. > - The IANA concerns section needs to be updated to reflect how to extend > the RAMS protocol. > - The unicast/multicast addresses need to be fixed according to the > idnits tool. > > Are there other issues that we need to address in the next revision of > the draft? The authors would like to address these high priority issues > in the next few days, so timely feedback would be appreciated. > > > Bill VerSteeg > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www.ietf.org/mailman/listinfo/avt From Even.roni@huawei.com Thu May 14 00:07:01 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 544CE3A6F22 for ; Thu, 14 May 2009 00:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.268 X-Spam-Level: X-Spam-Status: No, score=0.268 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, SARE_RECV_BEZEQINT_B=0.763] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTtBamkdlODc for ; Thu, 14 May 2009 00:07:00 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id DADFE3A6B9A for ; Thu, 14 May 2009 00:06:59 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJM007IVH1C6P@szxga03-in.huawei.com> for avt@ietf.org; Thu, 14 May 2009 15:05:36 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJM00HY9GT0IE@szxga03-in.huawei.com> for avt@ietf.org; Thu, 14 May 2009 15:00:36 +0800 (CST) Received: from windows8d787f9 (bzq-82-81-43-87.red.bezeqint.net [82.81.43.87]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJM0014ZGR6A3@szxml02-in.huawei.com>; Thu, 14 May 2009 15:00:36 +0800 (CST) Date: Thu, 14 May 2009 09:59:05 +0300 From: Roni Even In-reply-to: <04CAD96D4C5A3D48B1919248A8FE0D54094C3DBF@xmb-sjc-215.amer.cisco.com> To: "'Ali C. Begen (abegen)'" , "'Bill Ver Steeg (versteb)'" , avt@ietf.org Message-id: <000a01c9d461$813bdcb0$83b39610$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcnS4FBFJRh0kTNdSKKujynDJmWrDwAJMQ/AAC+GL9AAAGUFAAAXW2jQAA+eDnA= References: <81B9B88E2F9D574AA5328A85547CDE91013038E4@xmb-rtp-21d.amer.cisco.com> <81B9B88E2F9D574AA5328A85547CDE9101303DA5@xmb-rtp-21d.amer.cisco.com> <00dc01c9d3c5$7a323aa0$6e96afe0$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D54094C3DBF@xmb-sjc-215.amer.cisco.com> Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions(RAMS) as a working group item X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2009 07:07:01 -0000 Hi Ali, I would like to see the text about this extensions mechanism. It was not discussed in the mailing list, what was done in a un-official design team or breakout session is not binding for a WG document. If you have a proposal please bring it forward. It should address the issue of what extensions are allowed, what is the registration procedure for the two types of extensions , do you need a draft describing the extension and so on. It should be discussed before it is added to a working group document. Roni -----Original Message----- From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] Sent: Thursday, May 14, 2009 2:36 AM To: Roni Even; Bill Ver Steeg (versteb); avt@ietf.org Subject: RE: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions(RAMS) as a working group item Inline. > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Roni Even > Sent: Wednesday, May 13, 2009 5:22 AM > To: Bill Ver Steeg (versteb); avt@ietf.org > Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions(RAMS) as a working > group item > > Bill, > Any changes that are not editorial should be presented to the list before > they are added to the draft. > > The changes for section 8 and 13 can be added to the draft. OK. > For section 7 please send a suggestion to the list since I am not sure that > there was a preferred way to do it. As we proposed previously (actually since version -00), we are using TLV elements to provide the extension mechanism and avoid the problems associated with using special values in various fields. In the update, we are saying that the TLV types will be registered with IANA in a new registry. Some of the available type space is reserved for vendor-neutral extensions whereas the rest is for private extensions. We briefly outline the requirements for registering the vendor-neutral extensions. As proposed by Ingemar previously in the breakout session, we are now using sub FMT fields to specify the individual RAMS messages (request, information and termination). So, for the message format we have something like: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SFMT=1 | Optional TLV-encoded Fields | +-+-+-+-+-+-+-+-+ | : Optional TLV-encoded Fields (and Padding, if needed) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Further RAMS message types could be defined in the future, if needed. We wanna conclude these issues quickly and address the remaining open items (you mentioned some of them already) in the next revision. BR, -acbegen > Thanks > Roni Even > AVT co-chair > > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Bill > Ver Steeg (versteb) > Sent: Wednesday, May 13, 2009 3:08 PM > To: avt@ietf.org > Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP > Sessions(RAMS) as a working group item > > > > We submitted version -00 of "draft-ietf-avt-rapid-acquisition-for-rtp". > This is basically a name change from > "draft-versteeg-avt-rapid-synchronization-for-rtp-03" to avoid confusion > with other pending "synchronization" drafts. > > There were some issues remaining from -03 version that have already been > identified on the list and technical breakout session. We are planning > to address these issues in the next version of the draft. > > We hope to address the following areas in the next revision of the > draft: > > - Section 7 - Define a method for vendor-specific and generic extensions > to RAMS, lay out the intent to use FMT==6 for all messages and to have > an (extensible) enumeration of the RAMS sub-FMTs > - Section 8 - Elaborate SDP to describe the various use cases for RAMS > - Section 13 - Define a single registry (FMT==6) for all RAMS > transactions, and then define Sub-FMT Values for RAMS Messages. Also > define an extensible RAMS TLV space registry > > - We need to make some typographical corrections, mostly changing from > RMS to RAMS. > - We need to formalize the TLV definitions and extensions (both vendor > and private extensions) > - We need to register FMT=6 with IANA for RAMS and use sub-FMT values to > identify various RAMS messages > - We need to clarify the SDP section based on the earlier discussion. > The SDP example is still declarative and we are looking forward to > include more examples as we move forward. > - The IANA concerns section needs to be updated to reflect how to extend > the RAMS protocol. > - The unicast/multicast addresses need to be fixed according to the > idnits tool. > > Are there other issues that we need to address in the next revision of > the draft? The authors would like to address these high priority issues > in the next few days, so timely feedback would be appreciated. > > > Bill VerSteeg > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From marshall.eubanks@gmail.com Thu May 14 06:13:18 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B6273A67DD for ; Thu, 14 May 2009 06:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XAzzRTZ3-R5Z for ; Thu, 14 May 2009 06:13:17 -0700 (PDT) Received: from mail-bw0-f174.google.com (mail-bw0-f174.google.com [209.85.218.174]) by core3.amsl.com (Postfix) with ESMTP id 29B843A6F2A for ; Thu, 14 May 2009 06:13:15 -0700 (PDT) Received: by bwz22 with SMTP id 22so1281210bwz.37 for ; Thu, 14 May 2009 06:14:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=KAe5UT/Yc9f7as+Y9eLrP95Bwhr2c5I32/kDyfpmm1A=; b=jWufA5+e35VBh0f+DBzYu1QV15t4+fLEb4VX3QWuKrbfT3mpv/os56x5Nu65KJPMYo RJZJG+ciPVotFBLA0JhnW2DAYKA5cFAWLorhctT4HrQfneFqsxMI0z1uy1qvGT+JFZ4R Ik27eb+R1J1MBd6/mqz5OL/Fycz91xgdOLyLg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ZpC/TaAG0SdNZudWLhkfbZ/HWgbdRbJePw8tK2llK8B/baAY9C6stBML4IZjM4VGGX 7UbBqZgVnn8AvZEcS08rTg7R9l5fAxRfkEOJYMZKqfyxJcolHLMEIbFkge3q5p2a84kP dYOyYHSb1LzszvN251VmF28Aqi1wdzDNP3GUo= MIME-Version: 1.0 Received: by 10.239.152.7 with SMTP id t7mr157729hbb.9.1242306880617; Thu, 14 May 2009 06:14:40 -0700 (PDT) In-Reply-To: References: Date: Thu, 14 May 2009 09:14:40 -0400 Message-ID: From: Marshall Eubanks To: David Singer Content-Type: multipart/alternative; boundary=001485f5cdc2523f800469df1cc9 Cc: http-live-streaming-review@group.apple.com, Ross Finlayson , avt@ietf.org Subject: Re: [AVT] iPhone streaming Internet-Draft posted X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2009 13:13:18 -0000 --001485f5cdc2523f800469df1cc9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear Dave; On Wed, May 13, 2009 at 12:24 AM, David Singer wrote: > Hi, Ross. Thanks for looking at the spec. > > On May 5, 2009, at 8:39 AM, Ross Finlayson wrote: > > We appreciate feedback on the protocol. >>> >> >> Rather than invent yet another protocol, why not just implement a RTSP/RTP >> client on the iPhone instead? >> > > Distributing media as discrete files over HTTP gives content providers a > cost-effective way to scale to high demand by using existing CDN and HTTP > caching infrastructure. > > With this goal in mind, we're looking for technical feedback on the > specification. > To reverse engineer this, does this mean that you are trying to tailor this to cloud CDNs ? Regards Marshall > > thanks, nice to hear from you, > > -- > David Singer > Multimedia Standards, Apple Inc. > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > --001485f5cdc2523f800469df1cc9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Dave;



On Wed, May 13, 2009 at 12:24 AM, David Singer <singer@apple.com> wrote:
Hi, Ross. Thanks for looking at the spec.


On May 5, 2009, at 8:39 AM, Ross Finlayson wrote:

We appreciate feedback on the protocol.

Rather than invent yet another protocol, why not just implement a RTSP/RTP = client on the iPhone instead?

Distributing media as discrete files over HTTP gives content providers a co= st-effective way to scale to high demand by using existing CDN and HTTP cac= hing infrastructure.

With this goal in mind, we're looking for technical feedback on the spe= cification.

To reverse engineer th= is, does this mean that you are trying to tailor this to=A0
cloud= CDNs ?

Regards
Marshall
=A0

thanks, nice to hear from you,

--
David Singer
Multimedia Standards, Apple Inc.
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/avt

--001485f5cdc2523f800469df1cc9-- From abegen@cisco.com Thu May 14 07:40:19 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BC2628C285 for ; Thu, 14 May 2009 07:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.417 X-Spam-Level: X-Spam-Status: No, score=-6.417 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUQw70mANM5e for ; Thu, 14 May 2009 07:40:18 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 3A46028C282 for ; Thu, 14 May 2009 07:40:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,194,1241395200"; d="scan'208";a="185474752" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 14 May 2009 14:41:51 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n4EEfpOd023257; Thu, 14 May 2009 07:41:51 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n4EEfpWp004664; Thu, 14 May 2009 14:41:51 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 May 2009 07:41:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 May 2009 07:41:30 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54094C3F1C@xmb-sjc-215.amer.cisco.com> In-Reply-To: <000901c9d460$ffeb7620$ffc26260$%roni@huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions(RAMS) as a working group item Thread-Index: AcnS4FBFJRh0kTNdSKKujynDJmWrDwAJMQ/AAC+GL9AAASCeQAAW+VvgAA8Nx7AAEHqmYA== References: <81B9B88E2F9D574AA5328A85547CDE91013038E4@xmb-rtp-21d.amer.cisco.com> <81B9B88E2F9D574AA5328A85547CDE9101303DA5@xmb-rtp-21d.amer.cisco.com> <00de01c9d3c8$32b6cad0$98246070$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D54094C3DC9@xmb-sjc-215.amer.cisco.com> <000901c9d460$ffeb7620$ffc26260$%roni@huawei.com> From: "Ali C. Begen (abegen)" To: "Roni Even" , "Bill Ver Steeg (versteb)" , X-OriginalArrivalTime: 14 May 2009 14:41:51.0145 (UTC) FILETIME=[1E180190:01C9D4A2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7000; t=1242312111; x=1243176111; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20RE=3A=20[AVT]=20Adopting=20Rapid=20Acquisition= 20of=20Multicast=09RTP=09Sessions(RAMS)=20as=20a=20working=2 0group=20item |Sender:=20; bh=pbTc2QKY37b+EPfNItEihYCpMl13Q9yh8uaWbN/+OaU=; b=hUOpFs8eX/GsGyf909JZtBk4jHhXMSCRI5jdweFTUHtM4cYjjW2bsR9QxB ZkjW4pPGeipXDqNbNSFHC0Xmob+66toiodrZQsjp2JLEldUgjWa3I5A1xy6j 1DZgqIp4QY; Authentication-Results: sj-dkim-3; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions(RAMS) as a working group item X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2009 14:40:19 -0000 > My understanding is that having a single physical entity is the = assumption > of this work and any other architecture is for further study. Indeed, that is the assumption. I should have said that even when it is = the same entity, the ports could be different. -acbegen > -----Original Message----- > From: Roni Even [mailto:Even.roni@huawei.com] > Sent: Wednesday, May 13, 2009 11:55 PM > To: Ali C. Begen (abegen); Bill Ver Steeg (versteb); avt@ietf.org > Subject: RE: [AVT] Adopting Rapid Acquisition of Multicast RTP = Sessions(RAMS) as a working > group item >=20 > Ali, >=20 > "This is tricky. Remember that the RAMS request message goes to the = Feedback > Target of the primary multicast session but the burst comes from the > retransmission server. They could be the same entity or different = ones. Any > solution should consider this in its design." >=20 > From the draft >=20 > " Editor's note: As stated above, FT, Burst Source and Retransmission > Source are logical entities. For efficiency and simplicity, they = MAY > be implemented by a single physical Retransmission Server (RS). In = a > number of places throughout this document we assume (and explicitly > state so) that all three are implemented by the same physical = entity > and therefore share the same IP address and the port number. The > authors look to the AVT community for recommendations on whether = this > is sufficient or the mechanism has to explicitly address other > topologies where FT, Burst Source and Retransmission Source are not > co-located." >=20 > My understanding is that having a single physical entity is the = assumption > of this work and any other architecture is for further study. >=20 > BTW: figure 2 has feedback target as part of the retransmission = server, I > think that you meant retransmission source for the burst. >=20 > Roni >=20 > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Ali C. > Begen (abegen) > Sent: Thursday, May 14, 2009 2:46 AM > To: Roni Even; Bill Ver Steeg (versteb); avt@ietf.org > Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP > Sessions(RAMS) as a working group item >=20 > Roni, >=20 > There are a few other important issues that we need WG input on: >=20 > - The scenarios where there are multiple SSRC-multiplexed RTP streams = in a > single RTP session. Will RAMS apply to individual streams or the whole > session? Similarly, what happens when the same multicast session = carries > multiple RTP sessions (same multicast address but different ports). = Clearly, > such cases will exist. We have a draft text that discusses different > scenarios and what needs to be done in each such cases. But before we = move > forward, we would like to hear WG input. Managing multiple bursts > simultaneously requires some details. >=20 > - The security section needs to be completed as well as the NAT = section. >=20 > Some comments inline. >=20 > > I have some others issues to add to this list > > > > 1. I suggest to add to the RAMS request an optional parameter that = will > > allow the receiver to request that the unicast stream will be sent = to the > a > > port specified in this parameter instead of the port offered in the > > announcement. >=20 > This is tricky. Remember that the RAMS request message goes to the = Feedback > Target of the primary multicast session but the burst comes from the > retransmission server. They could be the same entity or different = ones. Any > solution should consider this in its design. >=20 > > 2. The issue of RTP/RTCP multiplexing should be discussed, is it = mandatory > > to use it. >=20 > It is not mandatory. Even if we made it mandatory, it would not help = us with > the issue you describe above. Muxing only simplifies NAT traversal. >=20 > > 3. The issue of FW/NAT traversal for the unicast stream should also = be > > discussed. >=20 > Indeed. The NAT section is TBC. >=20 > -acbegen >=20 > > > > Thanks > > Roni Even > > > > -----Original Message----- > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf = Of Bill > > Ver Steeg (versteb) > > Sent: Wednesday, May 13, 2009 3:08 PM > > To: avt@ietf.org > > Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP > > Sessions(RAMS) as a working group item > > > > > > > > We submitted version -00 of = "draft-ietf-avt-rapid-acquisition-for-rtp". > > This is basically a name change from > > "draft-versteeg-avt-rapid-synchronization-for-rtp-03" to avoid = confusion > > with other pending "synchronization" drafts. > > > > There were some issues remaining from -03 version that have already = been > > identified on the list and technical breakout session. We are = planning > > to address these issues in the next version of the draft. > > > > We hope to address the following areas in the next revision of the > > draft: > > > > - Section 7 - Define a method for vendor-specific and generic = extensions > > to RAMS, lay out the intent to use FMT=3D=3D6 for all messages and = to have > > an (extensible) enumeration of the RAMS sub-FMTs > > - Section 8 - Elaborate SDP to describe the various use cases for = RAMS > > - Section 13 - Define a single registry (FMT=3D=3D6) for all RAMS > > transactions, and then define Sub-FMT Values for RAMS Messages. Also > > define an extensible RAMS TLV space registry > > > > - We need to make some typographical corrections, mostly changing = from > > RMS to RAMS. > > - We need to formalize the TLV definitions and extensions (both = vendor > > and private extensions) > > - We need to register FMT=3D6 with IANA for RAMS and use sub-FMT = values to > > identify various RAMS messages > > - We need to clarify the SDP section based on the earlier = discussion. > > The SDP example is still declarative and we are looking forward to > > include more examples as we move forward. > > - The IANA concerns section needs to be updated to reflect how to = extend > > the RAMS protocol. > > - The unicast/multicast addresses need to be fixed according to the > > idnits tool. > > > > Are there other issues that we need to address in the next revision = of > > the draft? The authors would like to address these high priority = issues > > in the next few days, so timely feedback would be appreciated. > > > > > > Bill VerSteeg > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > > > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From onramp123@yahoo.com Thu May 14 22:44:24 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49EE63A70AD for ; Thu, 14 May 2009 22:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5D1KjhMkLIy for ; Thu, 14 May 2009 22:44:23 -0700 (PDT) Received: from n54.bullet.mail.sp1.yahoo.com (n54.bullet.mail.sp1.yahoo.com [98.136.44.32]) by core3.amsl.com (Postfix) with SMTP id 92D943A70AF for ; Thu, 14 May 2009 22:44:23 -0700 (PDT) Received: from [69.147.84.144] by n54.bullet.mail.sp1.yahoo.com with NNFMP; 15 May 2009 05:45:55 -0000 Received: from [68.142.200.224] by t6.bullet.mail.sp1.yahoo.com with NNFMP; 15 May 2009 05:45:55 -0000 Received: from [68.142.201.254] by t5.bullet.mud.yahoo.com with NNFMP; 15 May 2009 05:45:55 -0000 Received: from [127.0.0.1] by omp415.mail.mud.yahoo.com with NNFMP; 15 May 2009 05:45:55 -0000 X-Yahoo-Newman-Id: 443323.18969.bm@omp415.mail.mud.yahoo.com Received: (qmail 88935 invoked from network); 15 May 2009 05:45:55 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Reply-To:From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:X-MimeOLE; b=cYxQuRbaXmKbw9f5v89oltxuma52qZ0XE2LWO5aku9NclAB0y8z0NiXEELvu+YWcqcYDVG/CiyGyD5KC7V0c7q7FW3fcSuszcluECOMxJ0inoHGNsFrIR3ZhO5ewgzmn5yKS5nt6Vc1fW3ktZuw2h7eQjBF9Slk4BKPqCuw5iUg= ; Received: from unknown (HELO sdelaney2) (onramp123@76.176.134.138 with login) by smtp120.plus.mail.mud.yahoo.com with SMTP; 15 May 2009 05:45:54 -0000 X-YMail-OSG: KI.fRxUVM1nREsyTfy2IOVF8ON0JAqsEzoNLW.s.Qtonuu_lfBkHIx8j_l2bBQh9j0fZsRwGtz30wTKvQ_OT8TOZAEKWp5u636qVQ6bzP7chGXvvs9i8VfFA5OLCFDtXeeNXPTsNw1EexO9QjFuNibRFl8R9QPPfYib35z9LoepfXAECiQQRWC7LZF0eWRKm7hjfw8nswAcHCpD0OipKNK0zF73uvWYMr_Ndx2.LQ_PTgubFhMrIkfc94nWSn4fen8_Koqu04pQ6vNTcDNXoLuGrmpjOtJnQLJyhe7ZfHVmirLDd3WdHsOFgPLA27gbWpz2KnQ-- X-Yahoo-Newman-Property: ymail-3 From: "Steve DeLaney" To: Date: Thu, 14 May 2009 22:47:19 -0700 Message-ID: <065a01c9d520$9d277b90$6501a8c0@sdelaney2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcnVIJvMBLCcGrDcSiaPcF+YdKU+8A== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1933 Subject: [AVT] profile-level-id definition X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: onramp123@yahoo.com List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2009 05:46:45 -0000 Hello, we are trying to better understand the definition of profile-level-id under RFC3984 section 8.1 Having browsed the archive threads including "SDP Negotiation based on Profile-Level-Id", I was hoping to get some clarification on this to break down the encoding for profile and level. we are integrating a codec which, when encoding at 1080P60, expresses profile-level-id=42001E as a hardcoded value. to break this down profile_idc 42 is MAIN profile ? level_idc 1E is level 3.0 ? and finally, assuming profiles and levels are authoritatively defined in 14496-10, what section? Thank you for your help. /steverino2 From Even.roni@huawei.com Fri May 15 00:11:17 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16F553A67B7 for ; Fri, 15 May 2009 00:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rqVXSx8FfjVx for ; Fri, 15 May 2009 00:11:16 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 36FDB28C2E4 for ; Fri, 15 May 2009 00:10:53 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJO002YOBSU79@szxga03-in.huawei.com> for avt@ietf.org; Fri, 15 May 2009 15:07:42 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJO0049CBSUBJ@szxga03-in.huawei.com> for avt@ietf.org; Fri, 15 May 2009 15:07:42 +0800 (CST) Received: from windows8d787f9 (bzq-79-177-13-40.red.bezeqint.net [79.177.13.40]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJO00GCABSHNO@szxml01-in.huawei.com>; Fri, 15 May 2009 15:07:42 +0800 (CST) Date: Fri, 15 May 2009 10:07:07 +0300 From: Roni Even In-reply-to: <065a01c9d520$9d277b90$6501a8c0@sdelaney2> To: onramp123@yahoo.com, avt@ietf.org Message-id: <00ad01c9d52b$cb230630$61691290$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcnVIJvMBLCcGrDcSiaPcF+YdKU+8AACk0QQ References: <065a01c9d520$9d277b90$6501a8c0@sdelaney2> Subject: Re: [AVT] profile-level-id definition X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2009 07:11:17 -0000 Hi, The profile and level are defined in H.264 annex A. There you can see the definition for profile_idc and level_idc Roni Even -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Steve DeLaney Sent: Friday, May 15, 2009 8:47 AM To: avt@ietf.org Subject: [AVT] profile-level-id definition Hello, we are trying to better understand the definition of profile-level-id under RFC3984 section 8.1 Having browsed the archive threads including "SDP Negotiation based on Profile-Level-Id", I was hoping to get some clarification on this to break down the encoding for profile and level. we are integrating a codec which, when encoding at 1080P60, expresses profile-level-id=42001E as a hardcoded value. to break this down profile_idc 42 is MAIN profile ? level_idc 1E is level 3.0 ? and finally, assuming profiles and levels are authoritatively defined in 14496-10, what section? Thank you for your help. /steverino2 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www.ietf.org/mailman/listinfo/avt From singer@apple.com Fri May 15 00:40:24 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B4923A6FA9 for ; Fri, 15 May 2009 00:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2mPvSbqSIGqp for ; Fri, 15 May 2009 00:40:23 -0700 (PDT) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 9FFDD3A6E51 for ; Fri, 15 May 2009 00:40:23 -0700 (PDT) Received: from relay16.apple.com (relay16.apple.com [17.128.113.55]) by mail-out3.apple.com (Postfix) with ESMTP id 699C760D1D80; Fri, 15 May 2009 00:41:57 -0700 (PDT) Received: from relay16.apple.com (unknown [127.0.0.1]) by relay16.apple.com (Symantec Brightmail Gateway) with ESMTP id 574385A0005; Fri, 15 May 2009 00:41:57 -0700 (PDT) X-AuditID: 11807137-a91b7bb000005e87-76-4a0d1cc1f443 Received: from [10.177.192.68] (unknown [17.83.209.191]) by relay16.apple.com (Apple SCV relay) with ESMTP id 3B07F558014; Fri, 15 May 2009 00:41:53 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <00ad01c9d52b$cb230630$61691290$%roni@huawei.com> References: <065a01c9d520$9d277b90$6501a8c0@sdelaney2> <00ad01c9d52b$cb230630$61691290$%roni@huawei.com> Date: Fri, 15 May 2009 15:41:19 +0800 To: Roni Even , onramp123@yahoo.com, avt@ietf.org From: David Singer Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Brightmail-Tracker: AAAAAA== Subject: Re: [AVT] profile-level-id definition X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2009 07:40:24 -0000 At 10:07 +0300 15/05/09, Roni Even wrote: >Hi, >The profile and level are defined in H.264 annex A. There you can see the >definition for profile_idc and level_idc >Roni Even and the middle byte is, I believe, the byte containing the constraint_set flags. >-----Original Message----- >From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Steve >DeLaney >Sent: Friday, May 15, 2009 8:47 AM >To: avt@ietf.org >Subject: [AVT] profile-level-id definition > >Hello, > >we are trying to better understand the definition of profile-level-id under >RFC3984 section 8.1 Having browsed the archive threads including "SDP >Negotiation based on Profile-Level-Id", I was hoping to get some >clarification on this to break down the encoding for profile and level. > >we are integrating a codec which, when encoding at 1080P60, expresses >profile-level-id=42001E as a hardcoded value. >to break this down > >profile_idc 42 is MAIN profile ? >level_idc 1E is level 3.0 ? > >and finally, assuming profiles and levels are authoritatively defined in >14496-10, what section? > >Thank you for your help. >/steverino2 > > >_______________________________________________ >Audio/Video Transport Working Group >avt@ietf.org >https://www.ietf.org/mailman/listinfo/avt > >_______________________________________________ >Audio/Video Transport Working Group >avt@ietf.org >https://www.ietf.org/mailman/listinfo/avt -- David Singer Multimedia Standards, Apple Inc. From wiegand@hhi.de Fri May 15 01:10:25 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 223743A6C55 for ; Fri, 15 May 2009 01:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pz9PitmyuuZy for ; Fri, 15 May 2009 01:10:24 -0700 (PDT) Received: from mail.hhi.fraunhofer.de (mail.HHI.FRAUNHOFER.DE [193.174.67.45]) by core3.amsl.com (Postfix) with ESMTP id B2AAE3A69D5 for ; Fri, 15 May 2009 01:10:23 -0700 (PDT) Received: by mail.hhi.fraunhofer.de (Postfix, from userid 65534) id 6546F1D88FF4; Fri, 15 May 2009 10:11:55 +0200 (CEST) Received: from imsva.hhi.de (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 4BCD3150045; Fri, 15 May 2009 10:11:53 +0200 (CEST) Message-Id: From: Thomas Wiegand To: David Singer In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 15 May 2009 10:11:51 +0200 References: <065a01c9d520$9d277b90$6501a8c0@sdelaney2> <00ad01c9d52b$cb230630$61691290$%roni@huawei.com> X-Mailer: Apple Mail (2.930.3) X-alterMIME: Yes Cc: avt@ietf.org, Roni Even Subject: Re: [AVT] profile-level-id definition X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2009 08:10:25 -0000 And you need all three for proper signalling of all profiles and levels: profile_idc constraint_setX_flags level_idc Best regards, Thomas On May 15, 2009, at 9:41 AM, David Singer wrote: > At 10:07 +0300 15/05/09, Roni Even wrote: >> Hi, >> The profile and level are defined in H.264 annex A. There you can >> see the >> definition for profile_idc and level_idc >> Roni Even > > and the middle byte is, I believe, the byte containing the > constraint_set flags. > >> -----Original Message----- >> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf >> Of Steve >> DeLaney >> Sent: Friday, May 15, 2009 8:47 AM >> To: avt@ietf.org >> Subject: [AVT] profile-level-id definition >> >> Hello, >> >> we are trying to better understand the definition of profile-level- >> id under >> RFC3984 section 8.1 Having browsed the archive threads including "SDP >> Negotiation based on Profile-Level-Id", I was hoping to get some >> clarification on this to break down the encoding for profile and >> level. >> >> we are integrating a codec which, when encoding at 1080P60, expresses >> profile-level-id=42001E as a hardcoded value. >> to break this down >> >> profile_idc 42 is MAIN profile ? >> level_idc 1E is level 3.0 ? >> >> and finally, assuming profiles and levels are authoritatively >> defined in >> 14496-10, what section? >> >> Thank you for your help. >> /steverino2 >> >> >> _______________________________________________ >> Audio/Video Transport Working Group >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt >> >> _______________________________________________ >> Audio/Video Transport Working Group >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt > > > -- > David Singer > Multimedia Standards, Apple Inc. > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > --- Visit us at ANGACable 2009 / May 26-28 / Cologne, Germay / Hall 10.2, Booth K15 http://www.angacable.com From root@core3.amsl.com Fri May 15 04:00:01 2009 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4CADA3A70C9; Fri, 15 May 2009 04:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090515110001.4CADA3A70C9@core3.amsl.com> Date: Fri, 15 May 2009 04:00:01 -0700 (PDT) Cc: avt@ietf.org Subject: [AVT] I-D Action:draft-ietf-avt-rtcp-xr-burst-gap-discard-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2009 11:00:01 -0000 --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 : RTCP XR Report Block for Burst/Gap Discard metric Reporting Author(s) : G. Hunt, A. Clark Filename : draft-ietf-avt-rtcp-xr-burst-gap-discard-02.txt Pages : 17 Date : 2009-05-15 This document defines an RTCP XR Report Block that allows the reporting of Burst and Gap Discard metrics for use in a range of RTP applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcp-xr-burst-gap-discard-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-avt-rtcp-xr-burst-gap-discard-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-15035453.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Fri May 15 04:00:01 2009 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4E88F3A70C8; Fri, 15 May 2009 04:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090515110001.4E88F3A70C8@core3.amsl.com> Date: Fri, 15 May 2009 04:00:01 -0700 (PDT) Cc: avt@ietf.org Subject: [AVT] I-D Action:draft-ietf-avt-rtcp-xr-meas-identity-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2009 11:00:01 -0000 --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 : RTCP XR Report Block for Measurement Identity Author(s) : G. Hunt, A. Clark Filename : draft-ietf-avt-rtcp-xr-meas-identity-02.txt Pages : 13 Date : 2009-05-15 This document defines an RTCP XR Report Block carrying parameters which identify a measurement, to which one or more other RTCP XR Report Blocks may refer. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcp-xr-meas-identity-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-avt-rtcp-xr-meas-identity-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-15035720.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Fri May 15 04:00:01 2009 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 55C163A70CB; Fri, 15 May 2009 04:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090515110001.55C163A70CB@core3.amsl.com> Date: Fri, 15 May 2009 04:00:01 -0700 (PDT) Cc: avt@ietf.org Subject: [AVT] I-D Action:draft-ietf-avt-rtcp-xr-burst-gap-loss-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2009 11:00:01 -0000 --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 : RTCP XR Report Block for Burst/Gap Loss metric Reporting Author(s) : G. Hunt, A. Clark Filename : draft-ietf-avt-rtcp-xr-burst-gap-loss-02.txt Pages : 17 Date : 2009-05-15 This document defines an RTCP XR Report Block that allows the reporting of Burst and Gap Loss metrics for use in a range of RTP applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcp-xr-burst-gap-loss-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-avt-rtcp-xr-burst-gap-loss-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-15035903.I-D@ietf.org> --NextPart-- From rjesup@wgate.com Fri May 15 05:27:03 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09E5A28C2E4 for ; Fri, 15 May 2009 05:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.566 X-Spam-Level: X-Spam-Status: No, score=-1.566 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9rc7Qe2ZZ89l for ; Fri, 15 May 2009 05:27:01 -0700 (PDT) Received: from exchange1.wgate.com (pr-66-150-46-254.wgate.com [66.150.46.254]) by core3.amsl.com (Postfix) with ESMTP id 4DF2F3A6AC3 for ; Fri, 15 May 2009 05:26:13 -0700 (PDT) Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 May 2009 08:27:46 -0400 To: onramp123@yahoo.com References: <065a01c9d520$9d277b90$6501a8c0@sdelaney2> From: Randell Jesup Date: Fri, 15 May 2009 08:29:55 -0400 In-Reply-To: <065a01c9d520$9d277b90$6501a8c0@sdelaney2> (Steve DeLaney's message of "Thu\, 14 May 2009 22\:47\:19 -0700") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 15 May 2009 12:27:46.0705 (UTC) FILETIME=[8DA5A010:01C9D558] Cc: avt@ietf.org Subject: Re: [AVT] profile-level-id definition X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Randell Jesup List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2009 12:27:03 -0000 "Steve DeLaney" writes: >Hello, > >we are trying to better understand the definition of profile-level-id under >RFC3984 section 8.1 Having browsed the archive threads including "SDP >Negotiation based on Profile-Level-Id", I was hoping to get some >clarification on this to break down the encoding for profile and level. > >we are integrating a codec which, when encoding at 1080P60, expresses >profile-level-id=42001E as a hardcoded value. >to break this down > >profile_idc 42 is MAIN profile ? >level_idc 1E is level 3.0 ? Others answered what those are. Note: Level 3.0 DOES NOT support the resolution you're using. See http://en.wikipedia.org/wiki/H.264#Levels 3.0 supports a max of 720x480@30 (or just over 60fps at 352x480). You need level 4.2 or above, OR with 3.0 you need to advertise that you do both a larger number of macroblocks/frame, and larger number of macroblocks/second (max-fs and max-mbps if I remember). Also, read the sections (in 3984bis - the draft about to replace 3984) about level negotiation. Profile and constraints are fixed; level has some negotiation possible. -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com "The fetters imposed on liberty at home have ever been forged out of the weapons provided for defence against real, pretended, or imaginary dangers from abroad." - James Madison, 4th US president (1751-1836) From root@core3.amsl.com Fri May 15 05:30:01 2009 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 7AEBB28C100; Fri, 15 May 2009 05:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090515123001.7AEBB28C100@core3.amsl.com> Date: Fri, 15 May 2009 05:30:01 -0700 (PDT) Cc: avt@ietf.org Subject: [AVT] I-D Action:draft-ietf-avt-rtcp-xr-pdv-03.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2009 12:30:01 -0000 --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 : RTCP XR Report Block for Packet Delay Variation Metric Reporting Author(s) : G. Hunt, A. Clark Filename : draft-ietf-avt-rtcp-xr-pdv-03.txt Pages : 15 Date : 2009-05-15 This document defines an RTCP XR Report Block that allows the reporting of Packet Delay Variation metrics for a range of RTP applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcp-xr-pdv-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-avt-rtcp-xr-pdv-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-15051837.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Fri May 15 06:15:02 2009 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 0AB8F3A6D6D; Fri, 15 May 2009 06:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090515131502.0AB8F3A6D6D@core3.amsl.com> Date: Fri, 15 May 2009 06:15:02 -0700 (PDT) Cc: avt@ietf.org Subject: [AVT] I-D Action:draft-ietf-avt-rtcp-xr-concsec-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2009 13:15:02 -0000 --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 : RTCP XR Report Block for Concealed Seconds metric Reporting Author(s) : G. Hunt, A. Clark Filename : draft-ietf-avt-rtcp-xr-concsec-02.txt Pages : 16 Date : 2009-05-15 This document defines an RTCP XR Report Block that allows the reporting of Concealed Seconds metrics primarily for audio applications of RTP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcp-xr-concsec-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-avt-rtcp-xr-concsec-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-15061447.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Fri May 15 06:30:01 2009 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 644AD3A6A8E; Fri, 15 May 2009 06:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090515133001.644AD3A6A8E@core3.amsl.com> Date: Fri, 15 May 2009 06:30:01 -0700 (PDT) Cc: avt@ietf.org Subject: [AVT] I-D Action:draft-ietf-avt-rtcp-xr-delay-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2009 13:30:01 -0000 --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 : RTCP XR Report Block for Delay metric Reporting Author(s) : G. Hunt, A. Clark Filename : draft-ietf-avt-rtcp-xr-delay-02.txt Pages : 14 Date : 2009-05-15 This document defines an RTCP XR Report Block that allows the reporting of Delay metrics for use in a range of RTP applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcp-xr-delay-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-avt-rtcp-xr-delay-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-15061612.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Fri May 15 06:30:01 2009 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6B5563A6837; Fri, 15 May 2009 06:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090515133001.6B5563A6837@core3.amsl.com> Date: Fri, 15 May 2009 06:30:01 -0700 (PDT) Cc: avt@ietf.org Subject: [AVT] I-D Action:draft-ietf-avt-rtcp-xr-discard-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2009 13:30:01 -0000 --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 : RTCP XR Report Block for Discard metric Reporting Author(s) : G. Hunt, A. Clark Filename : draft-ietf-avt-rtcp-xr-discard-02.txt Pages : 14 Date : 2009-05-15 This document defines an RTCP XR Report Block that allows the reporting of a simple discard count metric for use in a range of RTP applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcp-xr-discard-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-avt-rtcp-xr-discard-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-15062026.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Fri May 15 06:30:01 2009 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 75C8C3A6C91; Fri, 15 May 2009 06:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090515133001.75C8C3A6C91@core3.amsl.com> Date: Fri, 15 May 2009 06:30:01 -0700 (PDT) Cc: avt@ietf.org Subject: [AVT] I-D Action:draft-ietf-avt-rtcp-xr-jb-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2009 13:30:01 -0000 --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 : RTCP XR Report Block for Jitter Buffer Metric Reporting Author(s) : G. Hunt, A. Clark Filename : draft-ietf-avt-rtcp-xr-jb-02.txt Pages : 13 Date : 2009-05-15 This document defines an RTCP XR Report Block that allows the reporting of Jitter Buffer metrics for a range of RTP applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcp-xr-jb-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-avt-rtcp-xr-jb-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-15062155.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Fri May 15 06:30:01 2009 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 80A6E3A6C99; Fri, 15 May 2009 06:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090515133001.80A6E3A6C99@core3.amsl.com> Date: Fri, 15 May 2009 06:30:01 -0700 (PDT) Cc: avt@ietf.org Subject: [AVT] I-D Action:draft-ietf-avt-rtcp-xr-loss-conceal-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2009 13:30:01 -0000 --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 : RTCP XR Report Block for Loss Concealment metric Reporting Author(s) : G. Hunt, A. Clark Filename : draft-ietf-avt-rtcp-xr-loss-conceal-02.txt Pages : 15 Date : 2009-05-15 This document defines an RTCP XR Report Block that allows the reporting of Loss Concealment metrics primarily for audio applications of RTP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcp-xr-loss-conceal-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-avt-rtcp-xr-loss-conceal-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-15062259.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Fri May 15 06:30:01 2009 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 8D5DA3A6D4A; Fri, 15 May 2009 06:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090515133001.8D5DA3A6D4A@core3.amsl.com> Date: Fri, 15 May 2009 06:30:01 -0700 (PDT) Cc: avt@ietf.org Subject: [AVT] I-D Action:draft-ietf-avt-rtcp-xr-postrepair-loss-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2009 13:30:01 -0000 --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 : RTCP XR Report Block for Post-Repair Loss metric Reporting Author(s) : G. Hunt, A. Clark Filename : draft-ietf-avt-rtcp-xr-postrepair-loss-02.txt Pages : 14 Date : 2009-05-15 This document defines an RTCP XR Report Block that allows the reporting of a simple post-repair loss count metric for use in a range of RTP applications. It complements the pre-repair loss count metric "cumulative number of packets lost" provided by RFC3550. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcp-xr-postrepair-loss-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-avt-rtcp-xr-postrepair-loss-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-15062421.I-D@ietf.org> --NextPart-- From geoff.hunt@bt.com Fri May 15 06:35:03 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04BCA3A6D74 for ; Fri, 15 May 2009 06:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.976 X-Spam-Level: X-Spam-Status: No, score=-0.976 tagged_above=-999 required=5 tests=[AWL=-0.577, BAYES_50=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbcRwiRKt53O for ; Fri, 15 May 2009 06:34:58 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id D1A5F3A6C99 for ; Fri, 15 May 2009 06:34:56 -0700 (PDT) Received: from E03MVY2-UKDY.domain1.systemhost.net ([193.113.30.60]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 May 2009 14:36:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 15 May 2009 14:36:08 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New drafts posted for -rtcp-xr-* transport metrics thread-index: AcnVYhpnFHQ86ZCyR2ayS2x7hjxH7A== From: To: X-OriginalArrivalTime: 15 May 2009 13:36:29.0272 (UTC) FILETIME=[26E36D80:01C9D562] Subject: [AVT] New drafts posted for -rtcp-xr-* transport metrics X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2009 13:35:03 -0000 New versions of drafts=20 draft-ietf-avt-rtcp-xr-burst-gap-discard-02 draft-ietf-avt-rtcp-xr-burst-gap-loss-02 draft-ietf-avt-rtcp-xr-concsec-02 draft-ietf-avt-rtcp-xr-delay-02 draft-ietf-avt-rtcp-xr-discard-02 draft-ietf-avt-rtcp-xr-jb-02 draft-ietf-avt-rtcp-xr-loss-conceal-02 draft-ietf-avt-rtcp-xr-meas-identity-02 draft-ietf-avt-rtcp-xr-pdv-03 draft-ietf-avt-rtcp-xr-postrepair-loss-02 have been posted. Changes fix the BNF-for-SDP error (Christian Groves' and Tom Taylor's comments of 4th and 5th May), and the new versions also update references. No other changes have been made. Geoff Hunt=20 BT Design Tel: 01473 608325 Email: geoff.hunt@bt.com Web: www.bt.com This email contains BT information, which may be privileged or confidential. It is meant only for the individual(s) or entity named above. If you are not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you have received this email in error, please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 From ingemar.s.johansson@ericsson.com Fri May 15 06:43:58 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 028273A6889 for ; Fri, 15 May 2009 06:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.901 X-Spam-Level: X-Spam-Status: No, score=-5.901 tagged_above=-999 required=5 tests=[AWL=0.348, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvK8AlfT1mQE for ; Fri, 15 May 2009 06:43:56 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 4FAA828C2AC for ; Fri, 15 May 2009 06:43:48 -0700 (PDT) X-AuditID: c1b4fb3e-b7b8fae000000a4a-82-4a0d71e6aa3f Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id E6.18.02634.6E17D0A4; Fri, 15 May 2009 15:45:10 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 May 2009 15:45:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 15 May 2009 15:45:02 +0200 Message-ID: <130EBB38279E9847BAAAE0B8F9905F8C01161DD7@esealmw109.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions(RAMS) as a working group item Thread-Index: AcnUYSMApC4tSs8FRqi/CzKcmRkpWwA/4sVg References: From: "Ingemar Johansson S" To: X-OriginalArrivalTime: 15 May 2009 13:45:03.0093 (UTC) FILETIME=[59264A50:01C9D563] X-Brightmail-Tracker: AAAAAA== Cc: Ingemar Johansson S , "Bill Ver Steeg \(versteb\)" , Even.roni@huawei.com Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions(RAMS) as a working group item X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2009 13:43:58 -0000 Hi As the draft name does not mention multicast or unicast I would like to have the door open for later inclusion of a description of the multicast version or RAMS descibed in=20 http://tools.ietf.org/id/draft-johansson-avt-mcast-based-rams-00.txt into the WG draft.=20 I plan to submit an update of said draft relatively soon which will contain more info regarding signalling and overall functionality. As a consequence of this (and of course, if the group agrees to merge the drafts) there may be a need for a field containing various flags in the header, see http://www.ietf.org/mail-archive/web/avt/current/msg11079.html For more detailed info Regards Ingemar > ------------------------------ >=20 > Message: 2 > Date: Wed, 13 May 2009 16:35:49 -0700 > From: "Ali C. Begen (abegen)" > Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP > Sessions(RAMS) as a working group item > To: "Roni Even" , "Bill Ver Steeg=20 > (versteb)" > , > Message-ID: > =09 > <04CAD96D4C5A3D48B1919248A8FE0D54094C3DBF@xmb-sjc-215.amer.cisco.com> > Content-Type: text/plain; charset=3D"Windows-1252" >=20 > Inline. >=20 > > -----Original Message----- > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On=20 > Behalf Of Roni Even > > Sent: Wednesday, May 13, 2009 5:22 AM > > To: Bill Ver Steeg (versteb); avt@ietf.org > > Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast=20 > RTP Sessions(RAMS) as a working > > group item > >=20 > > Bill, > > Any changes that are not editorial should be presented to=20 > the list before > > they are added to the draft. > >=20 > > The changes for section 8 and 13 can be added to the draft. >=20 > OK. > =20 > > For section 7 please send a suggestion to the list since I=20 > am not sure that > > there was a preferred way to do it. >=20 > As we proposed previously (actually since version -00), we=20 > are using TLV elements to provide the extension mechanism and=20 > avoid the problems associated with using special values in=20 > various fields. In the update, we are saying that the TLV=20 > types will be registered with IANA in a new registry. Some of=20 > the available type space is reserved for vendor-neutral=20 > extensions whereas the rest is for private extensions. We=20 > briefly outline the requirements for registering the=20 > vendor-neutral extensions. >=20 > As proposed by Ingemar previously in the breakout session, we=20 > are now using sub FMT fields to specify the individual RAMS=20 > messages (request, information and termination). So, for the=20 > message format we have something like: >=20 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | SFMT=3D1 | Optional TLV-encoded Fields = | > +-+-+-+-+-+-+-+-+ | > : Optional TLV-encoded Fields (and Padding, if needed) : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > =20 > Further RAMS message types could be defined in the future, if needed. >=20 > We wanna conclude these issues quickly and address the=20 > remaining open items (you mentioned some of them already) in=20 > the next revision. >=20 > BR, > -acbegen=20 >=20 > > Thanks > > Roni Even > > AVT co-chair > >=20 > > -----Original Message----- > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On=20 > Behalf Of Bill > > Ver Steeg (versteb) > > Sent: Wednesday, May 13, 2009 3:08 PM > > To: avt@ietf.org > > Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP > > Sessions(RAMS) as a working group item > >=20 > >=20 > >=20 > > We submitted version -00 of=20 > "draft-ietf-avt-rapid-acquisition-for-rtp". > > This is basically a name change from > > "draft-versteeg-avt-rapid-synchronization-for-rtp-03" to=20 > avoid confusion > > with other pending "synchronization" drafts. > >=20 > > There were some issues remaining from -03 version that have=20 > already been > > identified on the list and technical breakout session. We=20 > are planning > > to address these issues in the next version of the draft. > >=20 > > We hope to address the following areas in the next revision of the > > draft: > >=20 > > - Section 7 - Define a method for vendor-specific and=20 > generic extensions > > to RAMS, lay out the intent to use FMT=3D=3D6 for all messages=20 > and to have > > an (extensible) enumeration of the RAMS sub-FMTs > > - Section 8 - Elaborate SDP to describe the various use=20 > cases for RAMS > > - Section 13 - Define a single registry (FMT=3D=3D6) for all RAMS > > transactions, and then define Sub-FMT Values for RAMS Messages. Also > > define an extensible RAMS TLV space registry > >=20 > > - We need to make some typographical corrections, mostly=20 > changing from > > RMS to RAMS. > > - We need to formalize the TLV definitions and extensions=20 > (both vendor > > and private extensions) > > - We need to register FMT=3D6 with IANA for RAMS and use=20 > sub-FMT values to > > identify various RAMS messages > > - We need to clarify the SDP section based on the earlier=20 > discussion. > > The SDP example is still declarative and we are looking forward to > > include more examples as we move forward. > > - The IANA concerns section needs to be updated to reflect=20 > how to extend > > the RAMS protocol. > > - The unicast/multicast addresses need to be fixed according to the > > idnits tool. > >=20 > > Are there other issues that we need to address in the next=20 > revision of > > the draft? The authors would like to address these high=20 > priority issues > > in the next few days, so timely feedback would be appreciated. > >=20 > >=20 > > Bill VerSteeg > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > >=20 > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt >=20 >=20 > ------------------------------ From root@core3.amsl.com Fri May 15 06:45:01 2009 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B13303A6A6B; Fri, 15 May 2009 06:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090515134501.B13303A6A6B@core3.amsl.com> Date: Fri, 15 May 2009 06:45:01 -0700 (PDT) Cc: avt@ietf.org Subject: [AVT] I-D Action:draft-ietf-avt-rtp-uemclip-06.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2009 13:45:01 -0000 --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 mU-law EMbedded Codec for Low-delay IP communication (UEMCLIP) speech codec Author(s) : Y. Hiwasaki, H. Ohmuro Filename : draft-ietf-avt-rtp-uemclip-06.txt Pages : 24 Date : 2009-05-15 This document describes the RTP payload format of a mU-law EMbedded Coder for Low-delay IP communication (UEMCLIP), an enhanced speech codec of ITU-T G.711. The bitstream has a scalable structure with an embedded u-law bitstream, also known as PCMU, thus providing a handy transcoding operation between narrowband and wideband speech. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-uemclip-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-avt-rtp-uemclip-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-15064450.I-D@ietf.org> --NextPart-- From yekuiwang@huawei.com Fri May 15 07:30:36 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1171D3A70E1 for ; Fri, 15 May 2009 07:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[AWL=0.339, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sjUcoo7pd1A8 for ; Fri, 15 May 2009 07:30:34 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 91A8528C3C4 for ; Fri, 15 May 2009 07:30:10 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJO00JXBWCUD5@usaga02-in.huawei.com> for avt@ietf.org; Fri, 15 May 2009 07:31:43 -0700 (PDT) Received: from W90946 ([10.193.125.102]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJO009OQWCQWI@usaga02-in.huawei.com> for avt@ietf.org; Fri, 15 May 2009 07:31:42 -0700 (PDT) Date: Fri, 15 May 2009 10:31:37 -0400 From: Ye-Kui Wang In-reply-to: To: 'Randell Jesup' , onramp123@yahoo.com Message-id: <50EE6B1C917A4D83BDCD490C8E71B751@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcnVWN97Qg845z1dQJeHwyVQXJ9IKwAELULg References: <065a01c9d520$9d277b90$6501a8c0@sdelaney2> Cc: avt@ietf.org Subject: Re: [AVT] profile-level-id definition X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2009 14:30:36 -0000 > >profile_idc 42 is MAIN profile ? profile_idc 42 (hex) indicates the Baseline Profile. BR, YK > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > Behalf Of Randell Jesup > Sent: Friday, May 15, 2009 8:30 AM > To: onramp123@yahoo.com > Cc: avt@ietf.org > Subject: Re: [AVT] profile-level-id definition > > "Steve DeLaney" writes: > > >Hello, > > > >we are trying to better understand the definition of > profile-level-id > >under > >RFC3984 section 8.1 Having browsed the archive threads > including "SDP > >Negotiation based on Profile-Level-Id", I was hoping to get some > >clarification on this to break down the encoding for profile > and level. > > > >we are integrating a codec which, when encoding at 1080P60, > expresses > >profile-level-id=42001E as a hardcoded value. > >to break this down > > > >profile_idc 42 is MAIN profile ? > >level_idc 1E is level 3.0 ? > > Others answered what those are. > > Note: Level 3.0 DOES NOT support the resolution you're using. > See http://en.wikipedia.org/wiki/H.264#Levels > > 3.0 supports a max of 720x480@30 (or just over 60fps at > 352x480). You need level 4.2 or above, OR with 3.0 you need > to advertise that you do both a larger number of > macroblocks/frame, and larger number of macroblocks/second > (max-fs and max-mbps if I remember). > > Also, read the sections (in 3984bis - the draft about to > replace 3984) about level negotiation. Profile and > constraints are fixed; level has some negotiation possible. > > -- > Randell Jesup, Worldgate (developers of the Ojo videophone), > ex-Amiga OS team rjesup@wgate.com "The fetters imposed on > liberty at home have ever been forged out of the weapons > provided for defence against real, pretended, or imaginary > dangers from abroad." > - James Madison, 4th US president (1751-1836) > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > From versteb@cisco.com Fri May 15 07:48:31 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81D383A6BDD for ; Fri, 15 May 2009 07:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.553 X-Spam-Level: X-Spam-Status: No, score=-6.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TnCQq-dF6US7 for ; Fri, 15 May 2009 07:48:30 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 8A5913A6893 for ; Fri, 15 May 2009 07:48:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,200,1241395200"; d="scan'208";a="305098640" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 15 May 2009 14:49:57 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n4FEnv3p001790; Fri, 15 May 2009 07:49:57 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n4FEntxJ015925; Fri, 15 May 2009 14:49:57 GMT Received: from xmb-rtp-21d.amer.cisco.com ([64.102.31.116]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 May 2009 10:49:56 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 15 May 2009 10:49:55 -0400 Message-ID: <81B9B88E2F9D574AA5328A85547CDE910135C32C@xmb-rtp-21d.amer.cisco.com> In-Reply-To: <130EBB38279E9847BAAAE0B8F9905F8C01161DD7@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] Adopting Rapid Acquisition of Multicast RTPSessions(RAMS) as a working group item Thread-Index: AcnUYSMApC4tSs8FRqi/CzKcmRkpWwA/4sVgAAI4alA= References: <130EBB38279E9847BAAAE0B8F9905F8C01161DD7@esealmw109.eemea.ericsson.se> From: "Bill Ver Steeg (versteb)" To: "Ingemar Johansson S" , X-OriginalArrivalTime: 15 May 2009 14:49:56.0853 (UTC) FILETIME=[6A02EA50:01C9D56C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8122; t=1242398997; x=1243262997; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=versteb@cisco.com; z=From:=20=22Bill=20Ver=20Steeg=20(versteb)=22=20 |Subject:=20RE=3A=20[AVT]=20Adopting=20Rapid=20Acquisition= 20of=20Multicast=20RTPSessions(RAMS)=20as=20a=20working=20gr oup=20item |Sender:=20; bh=TwsVsxoDRYfu8IWwtxJFn/XRJx1fo7xKNU1AzxbgKL4=; b=HEOE+K1cw2+ajDkYrN5K2TjKgJ68wH5TVA0bYVPJOXvSXnKDsILl/Qnkdn 4OLqg5MGrbvFvJ3df43P96grjqH2HEWUU255OwSyu/UPa+tsOjJ6yOLGN5Ze z2lzeD+Rz7; Authentication-Results: sj-dkim-4; header.From=versteb@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: Even.roni@huawei.com Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTPSessions(RAMS) as a working group item X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2009 14:48:31 -0000 Ingemar- I think current RAMS draft should be focused on unicast acceleration methods. It is not clear (at least to me) that there is enough concurrency in RAMS requests to drive a multicast-based acceleration solution. I do have an open mind on this, and could be convinced by data showing a high degree of fine-grained concurrency in time-sensitive join activity. Having said that I do not see a current need for a multicast solution - we should not preclude a subsequent multicast solution, and an analysis of how one would implement a multicast solution using the RAMS primitives would be a good test case for the extensibility of the protocol. Using sub-types for RAMS-R, RAMS-I and RAMS-T (and reserving additional subtypes) is a step in the right direction. Defining an extensible TLV mechanism, which could be used to describe the behavior of the proposed multicast enhancements would also be prudent. In summary, I am broadly OK with having a baseline unicast RAMS solution that allows for extensions. A wide variety of extensions should be possible, and if a multicast extension eventually makes sense we should be sure that the protocol design supports such an extension. Bill verSteeg -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ingemar Johansson S Sent: Friday, May 15, 2009 9:45 AM To: avt@ietf.org Cc: Ingemar Johansson S; Bill Ver Steeg (versteb); Even.roni@huawei.com Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTPSessions(RAMS) as a working group item Hi As the draft name does not mention multicast or unicast I would like to have the door open for later inclusion of a description of the multicast version or RAMS descibed in http://tools.ietf.org/id/draft-johansson-avt-mcast-based-rams-00.txt into the WG draft.=20 I plan to submit an update of said draft relatively soon which will contain more info regarding signalling and overall functionality. As a consequence of this (and of course, if the group agrees to merge the drafts) there may be a need for a field containing various flags in the header, see http://www.ietf.org/mail-archive/web/avt/current/msg11079.html For more detailed info Regards Ingemar > ------------------------------ >=20 > Message: 2 > Date: Wed, 13 May 2009 16:35:49 -0700 > From: "Ali C. Begen (abegen)" > Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP > Sessions(RAMS) as a working group item > To: "Roni Even" , "Bill Ver Steeg=20 > (versteb)" > , > Message-ID: > =09 > <04CAD96D4C5A3D48B1919248A8FE0D54094C3DBF@xmb-sjc-215.amer.cisco.com> > Content-Type: text/plain; charset=3D"Windows-1252" >=20 > Inline. >=20 > > -----Original Message----- > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On=20 > Behalf Of Roni Even > > Sent: Wednesday, May 13, 2009 5:22 AM > > To: Bill Ver Steeg (versteb); avt@ietf.org > > Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast=20 > RTP Sessions(RAMS) as a working > > group item > >=20 > > Bill, > > Any changes that are not editorial should be presented to=20 > the list before > > they are added to the draft. > >=20 > > The changes for section 8 and 13 can be added to the draft. >=20 > OK. > =20 > > For section 7 please send a suggestion to the list since I=20 > am not sure that > > there was a preferred way to do it. >=20 > As we proposed previously (actually since version -00), we=20 > are using TLV elements to provide the extension mechanism and=20 > avoid the problems associated with using special values in=20 > various fields. In the update, we are saying that the TLV=20 > types will be registered with IANA in a new registry. Some of=20 > the available type space is reserved for vendor-neutral=20 > extensions whereas the rest is for private extensions. We=20 > briefly outline the requirements for registering the=20 > vendor-neutral extensions. >=20 > As proposed by Ingemar previously in the breakout session, we=20 > are now using sub FMT fields to specify the individual RAMS=20 > messages (request, information and termination). So, for the=20 > message format we have something like: >=20 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | SFMT=3D1 | Optional TLV-encoded Fields = | > +-+-+-+-+-+-+-+-+ | > : Optional TLV-encoded Fields (and Padding, if needed) : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > =20 > Further RAMS message types could be defined in the future, if needed. >=20 > We wanna conclude these issues quickly and address the=20 > remaining open items (you mentioned some of them already) in=20 > the next revision. >=20 > BR, > -acbegen=20 >=20 > > Thanks > > Roni Even > > AVT co-chair > >=20 > > -----Original Message----- > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On=20 > Behalf Of Bill > > Ver Steeg (versteb) > > Sent: Wednesday, May 13, 2009 3:08 PM > > To: avt@ietf.org > > Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP > > Sessions(RAMS) as a working group item > >=20 > >=20 > >=20 > > We submitted version -00 of=20 > "draft-ietf-avt-rapid-acquisition-for-rtp". > > This is basically a name change from > > "draft-versteeg-avt-rapid-synchronization-for-rtp-03" to=20 > avoid confusion > > with other pending "synchronization" drafts. > >=20 > > There were some issues remaining from -03 version that have=20 > already been > > identified on the list and technical breakout session. We=20 > are planning > > to address these issues in the next version of the draft. > >=20 > > We hope to address the following areas in the next revision of the > > draft: > >=20 > > - Section 7 - Define a method for vendor-specific and=20 > generic extensions > > to RAMS, lay out the intent to use FMT=3D=3D6 for all messages=20 > and to have > > an (extensible) enumeration of the RAMS sub-FMTs > > - Section 8 - Elaborate SDP to describe the various use=20 > cases for RAMS > > - Section 13 - Define a single registry (FMT=3D=3D6) for all RAMS > > transactions, and then define Sub-FMT Values for RAMS Messages. Also > > define an extensible RAMS TLV space registry > >=20 > > - We need to make some typographical corrections, mostly=20 > changing from > > RMS to RAMS. > > - We need to formalize the TLV definitions and extensions=20 > (both vendor > > and private extensions) > > - We need to register FMT=3D6 with IANA for RAMS and use=20 > sub-FMT values to > > identify various RAMS messages > > - We need to clarify the SDP section based on the earlier=20 > discussion. > > The SDP example is still declarative and we are looking forward to > > include more examples as we move forward. > > - The IANA concerns section needs to be updated to reflect=20 > how to extend > > the RAMS protocol. > > - The unicast/multicast addresses need to be fixed according to the > > idnits tool. > >=20 > > Are there other issues that we need to address in the next=20 > revision of > > the draft? The authors would like to address these high=20 > priority issues > > in the next few days, so timely feedback would be appreciated. > >=20 > >=20 > > Bill VerSteeg > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > >=20 > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt >=20 >=20 > ------------------------------ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www.ietf.org/mailman/listinfo/avt From abegen@cisco.com Fri May 15 10:31:46 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82FE43A67D8 for ; Fri, 15 May 2009 10:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.119 X-Spam-Level: X-Spam-Status: No, score=-6.119 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 119cD6UAAcsT for ; Fri, 15 May 2009 10:31:44 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 2C6103A6846 for ; Fri, 15 May 2009 10:30:58 -0700 (PDT) X-Files: rfcdiff.txt : 23415 X-IronPort-AV: E=Sophos;i="4.41,200,1241395200"; d="txt'?scan'208";a="162188369" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 15 May 2009 17:32:32 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n4FHWWbB019480; Fri, 15 May 2009 10:32:32 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n4FHWWgI013711; Fri, 15 May 2009 17:32:32 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 May 2009 10:32:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C9D583.2031B360" Date: Fri, 15 May 2009 10:32:17 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540954DB8A@xmb-sjc-215.amer.cisco.com> In-Reply-To: <000a01c9d461$813bdcb0$83b39610$%roni@huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions(RAMS) as a working group item Thread-Index: AcnS4FBFJRh0kTNdSKKujynDJmWrDwAJMQ/AAC+GL9AAAGUFAAAXW2jQAA+eDnAASHsCkA== References: <81B9B88E2F9D574AA5328A85547CDE91013038E4@xmb-rtp-21d.amer.cisco.com> <81B9B88E2F9D574AA5328A85547CDE9101303DA5@xmb-rtp-21d.amer.cisco.com> <00dc01c9d3c5$7a323aa0$6e96afe0$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D54094C3DBF@xmb-sjc-215.amer.cisco.com> <000a01c9d461$813bdcb0$83b39610$%roni@huawei.com> From: "Ali C. Begen (abegen)" To: "Roni Even" , "Bill Ver Steeg (versteb)" , X-OriginalArrivalTime: 15 May 2009 17:32:31.0960 (UTC) FILETIME=[20821D80:01C9D583] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=38743; t=1242408752; x=1243272752; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20RE=3A=20[AVT]=20Adopting=20Rapid=20Acquisition= 20of=20Multicast=20RTP=09Sessions(RAMS)=20as=20a=20working=2 0group=20item |Sender:=20; bh=45u5e9H8HGRuk95oXGYNgx3E/5QWORGTuWUeSaZTh+Q=; b=EzXEHx0KK4SxveMdqZ/+VfCZSH7/scG09Ew28neDH0Av0nFDP+xsHC6ojl PAcitfg876Kgk3q5LtSHbR+2mttJQF3Ry2YnBfvrnxSUEc1Rpx4ufjEGAnJQ Hoj3ABug+Ewy1q30ONfDbOoCI3lNl99zLXqOsLycGn9R/hQ7PEEx8=; Authentication-Results: sj-dkim-1; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions(RAMS) as a working group item X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2009 17:31:46 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9D583.2031B360 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Roni, All, Here is a diff for sections 7 and 13.=20 Comments are welcome. -acbegen > -----Original Message----- > From: Roni Even [mailto:Even.roni@huawei.com] > Sent: Wednesday, May 13, 2009 11:59 PM > To: Ali C. Begen (abegen); Bill Ver Steeg (versteb); avt@ietf.org > Subject: RE: [AVT] Adopting Rapid Acquisition of Multicast RTP = Sessions(RAMS) as a working > group item >=20 > Hi Ali, > I would like to see the text about this extensions mechanism. It was = not > discussed in the mailing list, what was done in a un-official design = team or > breakout session is not binding for a WG document. >=20 > If you have a proposal please bring it forward. > It should address the issue of what extensions are allowed, what is = the > registration procedure for the two types of extensions , do you need a = draft > describing the extension and so on. > It should be discussed before it is added to a working group document. >=20 > Roni >=20 > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > Sent: Thursday, May 14, 2009 2:36 AM > To: Roni Even; Bill Ver Steeg (versteb); avt@ietf.org > Subject: RE: [AVT] Adopting Rapid Acquisition of Multicast RTP > Sessions(RAMS) as a working group item >=20 > Inline. >=20 > > -----Original Message----- > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf = Of Roni > Even > > Sent: Wednesday, May 13, 2009 5:22 AM > > To: Bill Ver Steeg (versteb); avt@ietf.org > > Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP > Sessions(RAMS) as a working > > group item > > > > Bill, > > Any changes that are not editorial should be presented to the list = before > > they are added to the draft. > > > > The changes for section 8 and 13 can be added to the draft. >=20 > OK. >=20 > > For section 7 please send a suggestion to the list since I am not = sure > that > > there was a preferred way to do it. >=20 > As we proposed previously (actually since version -00), we are using = TLV > elements to provide the extension mechanism and avoid the problems > associated with using special values in various fields. In the update, = we > are saying that the TLV types will be registered with IANA in a new > registry. Some of the available type space is reserved for = vendor-neutral > extensions whereas the rest is for private extensions. We briefly = outline > the requirements for registering the vendor-neutral extensions. >=20 > As proposed by Ingemar previously in the breakout session, we are now = using > sub FMT fields to specify the individual RAMS messages (request, = information > and termination). So, for the message format we have something like: >=20 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | SFMT=3D1 | Optional TLV-encoded Fields = | > +-+-+-+-+-+-+-+-+ | > : Optional TLV-encoded Fields (and Padding, if needed) : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Further RAMS message types could be defined in the future, if needed. >=20 > We wanna conclude these issues quickly and address the remaining open = items > (you mentioned some of them already) in the next revision. >=20 > BR, > -acbegen >=20 > > Thanks > > Roni Even > > AVT co-chair > > > > -----Original Message----- > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf = Of Bill > > Ver Steeg (versteb) > > Sent: Wednesday, May 13, 2009 3:08 PM > > To: avt@ietf.org > > Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP > > Sessions(RAMS) as a working group item > > > > > > > > We submitted version -00 of = "draft-ietf-avt-rapid-acquisition-for-rtp". > > This is basically a name change from > > "draft-versteeg-avt-rapid-synchronization-for-rtp-03" to avoid = confusion > > with other pending "synchronization" drafts. > > > > There were some issues remaining from -03 version that have already = been > > identified on the list and technical breakout session. We are = planning > > to address these issues in the next version of the draft. > > > > We hope to address the following areas in the next revision of the > > draft: > > > > - Section 7 - Define a method for vendor-specific and generic = extensions > > to RAMS, lay out the intent to use FMT=3D=3D6 for all messages and = to have > > an (extensible) enumeration of the RAMS sub-FMTs > > - Section 8 - Elaborate SDP to describe the various use cases for = RAMS > > - Section 13 - Define a single registry (FMT=3D=3D6) for all RAMS > > transactions, and then define Sub-FMT Values for RAMS Messages. Also > > define an extensible RAMS TLV space registry > > > > - We need to make some typographical corrections, mostly changing = from > > RMS to RAMS. > > - We need to formalize the TLV definitions and extensions (both = vendor > > and private extensions) > > - We need to register FMT=3D6 with IANA for RAMS and use sub-FMT = values to > > identify various RAMS messages > > - We need to clarify the SDP section based on the earlier = discussion. > > The SDP example is still declarative and we are looking forward to > > include more examples as we move forward. > > - The IANA concerns section needs to be updated to reflect how to = extend > > the RAMS protocol. > > - The unicast/multicast addresses need to be fixed according to the > > idnits tool. > > > > Are there other issues that we need to address in the next revision = of > > the draft? The authors would like to address these high priority = issues > > in the next few days, so timely feedback would be appreciated. > > > > > > Bill VerSteeg > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > > > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt ------_=_NextPart_001_01C9D583.2031B360 Content-Type: text/plain; name="rfcdiff.txt" Content-Transfer-Encoding: base64 Content-Description: rfcdiff.txt Content-Disposition: attachment; filename="rfcdiff.txt" U2VjdGlvbiA3LiwgcGFyYWdyYXBoIDE6DQpPTEQ6DQoNCiAgICBUaGlzIHNlY3Rpb24gZGVmaW5l cyB0aGUgZm9ybWF0cyBvZiB0aGUgUlRDUCB0cmFuc3BvcnQtbGF5ZXIgZmVlZGJhY2sNCiAgICBt ZXNzYWdlcyB0aGF0IGFyZSBleGNoYW5nZWQgYmV0d2VlbiB0aGUgUmV0cmFuc21pc3Npb24gU2Vy dmVyIChSUykNCiAgICBhbmQgUlRQIFJlY2VpdmVyIChSUikgZHVyaW5nIHJhcGlkIGFjcXVpc2l0 aW9uLiAgVGhlc2UgbWVzc2FnZXMgYXJlDQogICAgcGF5bG9hZC1pbmRlcGVuZGVudCBhbmQgTVVT VCBiZSB1c2VkIGJ5IGFsbCBSVFAtYmFzZWQgbXVsdGljYXN0DQogICAgYXBwbGljYXRpb25zIHRo YXQgc3VwcG9ydCByYXBpZCBhY3F1aXNpdGlvbiByZWdhcmRsZXNzIG9mIHRoZSBwYXlsb2FkDQog ICAgdGhleSBjYXJyeS4NCg0KTkVXOg0KDQogICAgVGhpcyBzZWN0aW9uIGRlZmluZXMgdGhlIGZv cm1hdHMgb2YgdGhlIFJUQ1AgdHJhbnNwb3J0LWxheWVyIGZlZWRiYWNrDQogICAgbWVzc2FnZXMg dGhhdCBhcmUgZXhjaGFuZ2VkIGJldHdlZW4gdGhlIFJldHJhbnNtaXNzaW9uIFNlcnZlciAoUlMp DQogICAgYW5kIFJUUCBSZWNlaXZlciAoUlIpIGR1cmluZyByYXBpZCBhY3F1aXNpdGlvbi4gIFRo ZXNlIG1lc3NhZ2VzIGFyZQ0KICAgIHJlZmVycmVkIHRvIGFzIHRoZSBSQU1TIE1lc3NhZ2VzLiAg VGhleSBhcmUgcGF5bG9hZC1pbmRlcGVuZGVudCBhbmQNCiAgICBNVVNUIGJlIHVzZWQgYnkgYWxs IFJUUC1iYXNlZCBtdWx0aWNhc3QgYXBwbGljYXRpb25zIHRoYXQgc3VwcG9ydA0KICAgIHJhcGlk IGFjcXVpc2l0aW9uIHJlZ2FyZGxlc3Mgb2YgdGhlIHBheWxvYWQgdGhleSBjYXJyeS4NCg0KDQpT ZWN0aW9uIDcuLCBwYXJhZ3JhcGggMjoNCk9MRDoNCg0KICAgIFNwZWNpZmljIHBheWxvYWQgZm9y bWF0cyBhcmUgbm90IGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCwgYnV0IGENCiAgICBmcmFtZXdv cmsgaXMgcHJlc2VudGVkIHRoYXQgYWxsb3dzIHBheWxvYWQtc3BlY2lmaWMgaW5mb3JtYXRpb24g dG8gYmUNCiAgICBpbmNsdWRlZCBpbiB0aGUgZXhjaGFuZ2UuDQoNCk5FVzoNCg0KICAgIFBheWxv YWQtc3BlY2lmaWMgZmVlZGJhY2sgbWVzc2FnZXMgYXJlIG5vdCBkZWZpbmVkIGluIHRoaXMgZG9j dW1lbnQsDQogICAgYnV0IGFuIGV4dGVuc2lvbiBtZWNoYW5pc20gaXMgcHJvdmlkZWQgd2hlcmUg ZnVydGhlciBvcHRpb25hbA0KICAgIHBheWxvYWQtaW5kZXBlbmRlbnQgYW5kIHBheWxvYWQtc3Bl Y2lmaWMgaW5mb3JtYXRpb24gY2FuIGJlIGluY2x1ZGVkDQogICAgaW4gdGhlIGV4Y2hhbmdlLg0K DQoNClNlY3Rpb24gNy4sIHBhcmFncmFwaCAzOg0KT0xEOg0KDQogICAgVGhlIGNvbW1vbiBwYWNr ZXQgZm9ybWF0IGZvciB0aGUgUlRDUCBmZWVkYmFjayBtZXNzYWdlcyBpcyBkZWZpbmVkIGluDQog ICAgU2VjdGlvbiA2LjEgb2YgW1JGQzQ1ODVdLiAgRWFjaCBmZWVkYmFjayBtZXNzYWdlIGhhcyBh IGZpeGVkLWxlbmd0aA0KICAgIGZpZWxkIGZvciB2ZXJzaW9uLCBwYWRkaW5nLCBmZWVkYmFjayBt ZXNzYWdlIHR5cGUgKEZNVCksIHBheWxvYWQgdHlwZQ0KICAgIChQVCksIGxlbmd0aCwgU1NSQyBv ZiBwYWNrZXQgc2VuZGVyLCBTU1JDIG9mIG1lZGlhIHNvdXJjZSBhcyB3ZWxsIGFzDQogICAgYSB2 YXJpYWJsZS1sZW5ndGggZmllbGQgZm9yIGZlZWRiYWNrIGNvbnRyb2wgaW5mb3JtYXRpb24gKEZD SSkuICBJbg0KICAgIHRoZSB0cmFuc3BvcnQtbGF5ZXIgZmVlZGJhY2sgbWVzc2FnZXMsIHRoZSBQ VCBmaWVsZCBpcyBzZXQgdG8gUlRQRkINCiAgICAoMjA1KS4NCg0KTkVXOg0KDQogICAgVGhlIGNv bW1vbiBwYWNrZXQgZm9ybWF0IGZvciB0aGUgUlRDUCBmZWVkYmFjayBtZXNzYWdlcyBpcyBkZWZp bmVkIGluDQogICAgU2VjdGlvbiA2LjEgb2YgW1JGQzQ1ODVdLiAgRWFjaCBmZWVkYmFjayBtZXNz YWdlIGhhcyBhIGZpeGVkLWxlbmd0aA0KICAgIGZpZWxkIGZvciB2ZXJzaW9uLCBwYWRkaW5nLCBm ZWVkYmFjayBtZXNzYWdlIHR5cGUgKEZNVCksIHBheWxvYWQgdHlwZQ0KICAgIChQVCksIGxlbmd0 aCwgU1NSQyBvZiBwYWNrZXQgc2VuZGVyLCBTU1JDIG9mIG1lZGlhIHNvdXJjZSBhcyB3ZWxsIGFz DQogICAgYSB2YXJpYWJsZS1sZW5ndGggZmllbGQgZm9yIGZlZWRiYWNrIGNvbnRyb2wgaW5mb3Jt YXRpb24gKEZDSSkuDQoNCg0KU2VjdGlvbiA3LiwgcGFyYWdyYXBoIDQ6DQpPTEQ6DQoNCiAgICBJ biB0aGUgZmVlZGJhY2sgbWVzc2FnZXMgZGVmaW5lZCBpbiB0aGlzIHNlY3Rpb24sIG9wdGlvbmFs IGV4dGVuc2lvbnMNCiAgICBhcmUgZW5jb2RlZCBieSB1c2luZyBUTFYgZWxlbWVudHMgYXMgZGVz Y3JpYmVkIGJlbG93IGFuZCBza2V0Y2hlZCBpbg0KICAgIEZpZ3VyZSA0Og0KDQpORVc6DQoNCiAg ICBJbiB0aGUgUkFNUyBtZXNzYWdlcywgdGhlIFBUIGZpZWxkIGlzIHNldCB0byBSVFBGQiAoMjA1 KSBhbmQgdGhlIEZNVA0KICAgIGZpZWxkIGlzIHNldCB0byBSQU1TICg2KS4gIEluZGl2aWR1YWwg UkFNUyBtZXNzYWdlcyBhcmUgaWRlbnRpZmllZCBieQ0KICAgIGEgc3ViLWZpZWxkIGNhbGxlZCBT dWIgRmVlZGJhY2sgTWVzc2FnZSBUeXBlIChTRk1UKS4NCiANCiA3LjEuICBFeHRlbnNpb25zDQog DQogICAgVG8gaW1wcm92ZSB0aGUgZnVuY3Rpb25hbGl0eSBvZiB0aGUgUkFNUyBtZXRob2QgaW4g Y2VydGFpbg0KICAgIGFwcGxpY2F0aW9ucywgaXQgbWF5IGJlIGRlc2lyYWJsZSB0byBkZWZpbmUg bmV3IGZpZWxkcyBpbiB0aGUgUkFNUw0KICAgIFJlcXVlc3QsIEluZm9ybWF0aW9uIGFuZCBUZXJt aW5hdGlvbiBtZXNzYWdlcy4gIFN1Y2ggZmllbGRzIE1VU1QgYmUNCiAgICBlbmNvZGVkIGFzIFRM ViBlbGVtZW50cyBhcyBkZXNjcmliZWQgYmVsb3cgYW5kIHNrZXRjaGVkIGluIEZpZ3VyZSA0Og0K DQoNClNlY3Rpb24gNy4sIHBhcmFncmFwaCA2Og0KT0xEOg0KDQogICAgbyAgTGVuZ3RoOiAgQSB0 d28tb2N0ZXQgZmllbGQgdGhhdCBpbmRpY2F0ZXMgdGhlIGxlbmd0aCBvZiB0aGUgVmFsdWUNCiAg ICAgICBmaWVsZCBpbiBvY3RldHMuDQoNCk5FVzoNCg0KICAgIG8gIExlbmd0aDogIEEgdHdvLW9j dGV0IGZpZWxkIHRoYXQgaW5kaWNhdGVzIHRoZSBsZW5ndGggb2YgdGhlIFRMVg0KICAgICAgIGVs ZW1lbnQgZXhjbHVkaW5nIHRoZSBUeXBlIGFuZCBMZW5ndGggZmllbGRzIGluIG9jdGV0cy4gIE5v dGUgdGhhdA0KICAgICAgIHRoaXMgbGVuZ3RoIGRvZXMgbm90IGluY2x1ZGUgYW55IHBhZGRpbmcg dGhhdCBpcyByZXF1aXJlZCBmb3INCiAgICAgICBhbGlnbm1lbnQuDQoNCg0KU2VjdGlvbiA3Liwg cGFyYWdyYXBoIDk6DQpPTEQ6DQoNCiAgICAgICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAg ICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzDQogICAgICAgMCAxIDIgMyA0IDUgNiA3 IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxDQogICAgICAr LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKw0KICAgICAgfCAgICAgVHlwZSAgICAgIHwgICAgICAgICAgICBMZW5ndGggICAgICAg ICAgICAgfCAgICAgVmFsdWUgICAgIHwNCiAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAgICB8ICAgICAgICAg ICAgICAgICAgICAgICAgICBWYWx1ZSBjb250ZC4gICAgICAgICAgICAgICAgICAgICAgICAgLw0K ICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSsNCg0KTkVXOg0KDQogICAgSW4gYW4gUkFNUyBtZXNzYWdlIGFueSB2ZW5k b3ItbmV1dHJhbCBvciBwcml2YXRlIGV4dGVuc2lvbiBNVVNUIGJlDQogICAgcGxhY2VkIGFmdGVy IHRoZSBtYW5kYXRvcnkgZmllbGRzIChpZiBhbnkpLiAgVGhlIHN1cHBvcnQgZm9yDQogICAgZXh0 ZW5zaW9ucyBpcyBPUFRJT05BTC4NCiANCiAgICAgICAwICAgICAgICAgICAgICAgICAgIDEgICAg ICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzDQogICAgICAgMCAxIDIgMyA0IDUg NiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxDQogICAg ICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKw0KICAgICAgfCAgICAgVHlwZSAgICAgIHwgICAgICAgICAgICBMZW5ndGggICAg ICAgICAgICAgfCAgICAgVmFsdWUgICAgIHwNCiAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAgICB8ICAgICAg ICAgICAgICAgICAgICAgICAgICBWYWx1ZSBjb250ZC4gICAgICAgICAgICAgICAgICAgICAgICAg Lw0KICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSsNCg0KDQpTZWN0aW9uIDcuLCBwYXJhZ3JhcGggMTA6DQpPTEQ6DQoN CiAgICAgICAgICAgICAgICAgICAgRmlndXJlIDQ6IFN0cnVjdHVyZSBvZiBhIFRMViBlbGVtZW50 DQogICAgRWRpdG9yJ3Mgbm90ZTogIFRoZSBvcHRpb25hbCBmaWVsZHMgaW4gdGhlIFJBTVMgbWVz c2FnZXMgKGRlZmluZWQNCiAgICBiZWxvdykgd2lsbCBiZSBjb252ZXJ0ZWQgdG8gVExWIGVsZW1l bnRzIGluIGEgbGF0ZXIgdmVyc2lvbiBvZiB0aGlzDQogICAgZG9jdW1lbnQuDQoNCk5FVzoNCg0K ICAgICAgICAgICAgICAgICAgICBGaWd1cmUgNDogU3RydWN0dXJlIG9mIGEgVExWIGVsZW1lbnQN Cg0KDQpTZWN0aW9uIDcuLCBwYXJhZ3JhcGggMTE6DQpPTEQ6DQoNCiA3LjEuICBSQU1TIFJlcXVl c3QNCg0KTkVXOg0KDQogNy4xLjEuICBWZW5kb3ItTmV1dHJhbCBFeHRlbnNpb25zDQoNCg0KU2Vj dGlvbiA3LiwgcGFyYWdyYXBoIDEyOg0KT0xEOg0KDQogICAgVGhlIFJBTVMgUmVxdWVzdCBtZXNz YWdlIGlzIGlkZW50aWZpZWQgYnkgUFQ9UlRQRkIgYW5kIEZNVD02Lg0KDQpORVc6DQoNCiAgICBJ ZiB0aGUgZ29hbCBpbiBkZWZpbmluZyBuZXcgVExWIGVsZW1lbnRzIGlzIHRvIGV4dGVuZCB0aGUN CiAgICBmdW5jdGlvbmFsaXR5IGluIGEgdmVuZG9yLW5ldXRyYWwgbWFubmVyLCB0aGV5IE1VU1Qg YmUgcmVnaXN0ZXJlZA0KICAgIHdpdGggSUFOQSB0aHJvdWdoIHRoZSBndWlkZWxpbmVzIHByb3Zp ZGVkIGluIFNlY3Rpb24gMTMuNC4NCiANCiAgICBUaGUgY3VycmVudCBkb2N1bWVudCBkZWZpbmVz IHNldmVyYWwgdmVuZG9yLW5ldXRyYWwgZXh0ZW5zaW9ucyBpbiB0aGUNCiAgICBmb2xsb3dpbmcg c2VjdGlvbnMuDQogDQogNy4xLjIuICBQcml2YXRlIEV4dGVuc2lvbnMNCiANCiAgICBJdCBpcyBk ZXNpcmFibGUgdG8gYWxsb3cgdmVuZG9ycyB0byB1c2UgcHJpdmF0ZSBleHRlbnNpb25zIGluIFRM Vg0KICAgIGZvcm1hdC4gIEZvciBpbnRlcm9wZXJhYmlsaXR5LCBzdWNoIGV4dGVuc2lvbnMgTVVT VCBOT1QgY29sbGlkZSB3aXRoDQogICAgZWFjaCBvdGhlci4NCiANCiAgICBBIGNlcnRhaW4gcmFu Z2Ugb2YgVExWIFR5cGVzIGlzIHJlc2VydmVkIGZvciBwcml2YXRlIGV4dGVuc2lvbnMNCiAgICAo UmVmZXIgdG8gU2VjdGlvbiAxMy40KS4gIElBTkEgbWFuYWdlbWVudCBmb3IgdGhlc2UgZXh0ZW5z aW9ucyBpcw0KICAgIHVubmVjZXNzYXJ5IGFuZCB0aGV5IGFyZSB0aGUgcmVzcG9uc2liaWxpdHkg b2YgaW5kaXZpZHVhbCB2ZW5kb3JzLg0KIA0KICAgIFRoZSBzdHJ1Y3R1cmUgdGhhdCBNVVNUIGJl IHVzZWQgZm9yIHRoZSBwcml2YXRlIGV4dGVuc2lvbnMgaXMNCiAgICBkZXBpY3RlZCBpbiBGaWd1 cmUgNS4gIEhlcmUsIHRoZSBlbnRlcnByaXNlIG51bWJlcnMgYXJlIHVzZWQgZnJvbQ0KICAgIGh0 dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvZW50ZXJwcmlzZS1udW1iZXJzLiAgVGhpcyB3 aWxsIGVuc3VyZQ0KICAgIHRoZSB1bmlxdWVuZXNzIG9mIHRoZSBwcml2YXRlIGV4dGVuc2lvbnMg YW5kIGF2b2lkIGFueSBjb2xsaXNpb24uDQogDQogICAgICAgMCAgICAgICAgICAgICAgICAgICAx ICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMw0KICAgICAgIDAgMSAyIDMg NCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0K ICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSsNCiAgICAgIHwgICAgICBUeXBlICAgICB8ICAgICAgICAgICAgTGVuZ3Ro ICAgICAgICAgICAgIHwgIEVudC4gTnVtYmVyICB8DQogICAgICArLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICAgfCAg ICAgICAgICAgICAgIEVudC4gTnVtYmVyIGNvbnRkLiAgICAgICAgICAgICAgfCAgICAgVmFsdWUg ICAgIHwNCiAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rDQogICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICBW YWx1ZSBjb250ZC4gICAgICAgICAgICAgICAgICAgICAgICAgLw0KICAgICAgKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAN CiAgICAgICAgICAgICAgICAgRmlndXJlIDU6IFN0cnVjdHVyZSBvZiBhIHByaXZhdGUgZXh0ZW5z aW9uDQogDQogNy4yLiAgUkFNUyBSZXF1ZXN0DQogDQogICAgVGhlIFJBTVMgUmVxdWVzdCBtZXNz YWdlIGlzIGlkZW50aWZpZWQgYnkgU0ZNVD0xLg0KDQoNClNlY3Rpb24gNy4sIHBhcmFncmFwaCAx NToNCk9MRDoNCg0KICAgIFRoZSBGQ0kgZmllbGQgaGFzIHRoZSBzdHJ1Y3R1cmUgZGVwaWN0ZWQg aW4gRmlndXJlIDUuDQoNCk5FVzoNCg0KICAgIFRoZSBGQ0kgZmllbGQgaGFzIHRoZSBzdHJ1Y3R1 cmUgZGVwaWN0ZWQgaW4gRmlndXJlIDYuDQoNCg0KU2VjdGlvbiA3LiwgcGFyYWdyYXBoIDE3Og0K T0xEOg0KDQogICAgICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIg ICAgICAgICAgICAgICAgICAgMw0KICAgICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0 IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KICAgICAgKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAg IHwgICAgICAgICAgICAgICBNaW4gUkFNUyBCdWZmZXIgRmlsbCBSZXF1aXJlbWVudCAgICAgICAg ICAgICAgICB8DQogICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICAgfCAgICAgICAgICAgICAgIE1heCBSQU1T IEJ1ZmZlciBGaWxsIFJlcXVpcmVtZW50ICAgICAgICAgICAgICAgIHwNCiAgICAgICstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r DQogICAgICB8ICAgICAgICAgICAgICAgICAgICAgICBNYXggUmVjZWl2ZSBCaXRyYXRlICAgICAg ICAgICAgICAgICAgICAgfA0KICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgIDogICAgICAgICAgICAgICAg ICAgIChUTFYtZW5jb2RlZCBFeHRlbnNpb25zKSAgICAgICAgICAgICAgICAgICA6DQogICAgICA6 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgOg0KICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSsNCg0KTkVXOg0KDQogICAgICAgMCAgICAgICAgICAgICAg ICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMw0KICAgICAgIDAg MSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5 IDAgMQ0KICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgIHwgICAgU0ZNVD0xICAgICB8ICAgICAgICAgIE9w dGlvbmFsIFRMVi1lbmNvZGVkIEZpZWxkcyAgICAgICAgICB8DQogICAgICArLSstKy0rLSstKy0r LSstKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAg ICAgOiAgICAgIE9wdGlvbmFsIFRMVi1lbmNvZGVkIEZpZWxkcyAoYW5kIFBhZGRpbmcsIGlmIG5l ZWRlZCkgICAgIDoNCiAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQoNCg0KU2VjdGlvbiA3LiwgcGFyYWdyYXBoIDE4 Og0KT0xEOg0KDQogICAgICAgICAgIEZpZ3VyZSA1OiBGQ0kgZmllbGQgc3ludGF4IGZvciB0aGUg UkFNUyBSZXF1ZXN0IG1lc3NhZ2UNCg0KTkVXOg0KDQogICAgICAgICAgIEZpZ3VyZSA2OiBGQ0kg ZmllbGQgc3ludGF4IGZvciB0aGUgUkFNUyBSZXF1ZXN0IG1lc3NhZ2UNCg0KDQpTZWN0aW9uIDcu LCBwYXJhZ3JhcGggMjI6DQpPTEQ6DQoNCiAgICBvICBNYXggUkFNUyBCdWZmZXIgRmlsbCBSZXF1 aXJlbWVudCAoMzIgYml0cyk6ICBPcHRpb25hbCBUTFYgZWxlbWVudA0KICAgICAgIHRoYXQgZGVu b3RlcyB0aGUgbWF4aW11bSBudW1iZXIgb2Ygb2N0ZXRzIG9mIGNvbnRlbnQgdGhlIFJUUA0KICAg ICAgIHJlY2VpdmVyIGNhbiBidWZmZXIgd2l0aG91dCBsb3NpbmcgdGhlIGJ1cnN0IGRhdGEgZHVl IHRvIGJ1ZmZlcg0KICAgICAgIG92ZXJmbG93Lg0KDQpORVc6DQoNCiAgICAgICBUeXBlOiAgVEJE DQogDQogICAgICAgTGVuZ3RoOiAgVEJEDQogICAgbyAgTWF4IFJBTVMgQnVmZmVyIEZpbGwgUmVx dWlyZW1lbnQgKDMyIGJpdHMpOiAgT3B0aW9uYWwgVExWIGVsZW1lbnQNCiAgICAgICB0aGF0IGRl bm90ZXMgdGhlIG1heGltdW0gbnVtYmVyIG9mIG9jdGV0cyBvZiBjb250ZW50IHRoZSBSVFANCiAg ICAgICByZWNlaXZlciBjYW4gYnVmZmVyIHdpdGhvdXQgbG9zaW5nIHRoZSBidXJzdCBkYXRhIGR1 ZSB0byBidWZmZXINCiAgICAgICBvdmVyZmxvdy4NCg0KDQpTZWN0aW9uIDcuLCBwYXJhZ3JhcGgg MjU6DQpPTEQ6DQoNCiAgICBvICBNYXggUmVjZWl2ZSBCaXRyYXRlICgzMiBiaXRzKTogIE9wdGlv bmFsIFRMViBlbGVtZW50IHRoYXQgZGVub3Rlcw0KICAgICAgIHRoZSBtYXhpbXVtIGJpdHJhdGUg KGluIGJpdHMgcGVyIHNlY29uZCkgdGhhdCB0aGUgUlRQIHJlY2VpdmVyIGNhbg0KICAgICAgIHBy b2Nlc3MgdGhlIHVuaWNhc3QgYnVyc3QuICBUaGlzIHJhdGUgc2hvdWxkIGluY2x1ZGUgd2hhdGV2 ZXINCiAgICAgICBrbm93bGVkZ2UgdGhlIHJlY2VpdmVyIGhhcyB0aGF0IHdvdWxkIHByb3ZpZGUg YW4gdXBwZXIgYm91bmQgb24NCiAgICAgICB0aGUgdW5pY2FzdCBidXJzdCBiaXRyYXRlLiAgVGhl IGxpbWl0cyBtYXkgaW5jbHVkZSBsb2NhbCByZWNlaXZlcg0KICAgICAgIGxpbWl0cyBhcyB3ZWxs IGFzIG5ldHdvcmsgbGltaXRzIHRoYXQgYXJlIGtub3duIHRvIHRoZSByZWNlaXZlci4NCg0KTkVX Og0KDQogICAgICAgVHlwZTogIFRCRA0KIA0KICAgICAgIExlbmd0aDogIFRCRA0KIA0KICAgIG8g IE1heCBSZWNlaXZlIEJpdHJhdGUgKDMyIGJpdHMpOiAgT3B0aW9uYWwgVExWIGVsZW1lbnQgdGhh dCBkZW5vdGVzDQogICAgICAgdGhlIG1heGltdW0gYml0cmF0ZSAoaW4gYml0cyBwZXIgc2Vjb25k KSB0aGF0IHRoZSBSVFAgcmVjZWl2ZXIgY2FuDQogICAgICAgcHJvY2VzcyB0aGUgdW5pY2FzdCBi dXJzdC4gIFRoaXMgcmF0ZSBzaG91bGQgaW5jbHVkZSB3aGF0ZXZlcg0KICAgICAgIGtub3dsZWRn ZSB0aGUgcmVjZWl2ZXIgaGFzIHRoYXQgd291bGQgcHJvdmlkZSBhbiB1cHBlciBib3VuZCBvbg0K ICAgICAgIHRoZSB1bmljYXN0IGJ1cnN0IGJpdHJhdGUuICBUaGUgbGltaXRzIG1heSBpbmNsdWRl IGxvY2FsIHJlY2VpdmVyDQogICAgICAgbGltaXRzIGFzIHdlbGwgYXMgbmV0d29yayBsaW1pdHMg dGhhdCBhcmUga25vd24gdG8gdGhlIHJlY2VpdmVyLg0KDQoNClNlY3Rpb24gNy4sIHBhcmFncmFw aCAyNzoNCk9MRDoNCg0KICAgIFRoZSBzZW1hbnRpY3Mgb2YgdGhlIFJBTVMtUiBmZWVkYmFjayBt ZXNzYWdlIGlzIGluZGVwZW5kZW50IG9mIHRoZQ0KICAgIHBheWxvYWQgdHlwZS4NCg0KTkVXOg0K DQogICAgICAgVHlwZTogIFRCRA0KIA0KICAgICAgIExlbmd0aDogIFRCRA0KIA0KICAgIFRoZSBz ZW1hbnRpY3Mgb2YgdGhlIFJBTVMtUiBmZWVkYmFjayBtZXNzYWdlIGlzIGluZGVwZW5kZW50IG9m IHRoZQ0KICAgIHBheWxvYWQgdHlwZS4NCg0KDQpTZWN0aW9uIDcuLCBwYXJhZ3JhcGggMjg6DQpP TEQ6DQoNCiA3LjIuICBSQU1TIEluZm9ybWF0aW9uDQoNCk5FVzoNCg0KIDcuMy4gIFJBTVMgSW5m b3JtYXRpb24NCg0KDQpTZWN0aW9uIDcuLCBwYXJhZ3JhcGggMjk6DQpPTEQ6DQoNCiAgICBUaGUg UkFNUyBJbmZvcm1hdGlvbiBtZXNzYWdlIGlzIGlkZW50aWZpZWQgYnkgUFQ9UlRQRkIgYW5kIEZN VD03Lg0KDQpORVc6DQoNCiAgICBUaGUgUkFNUyBJbmZvcm1hdGlvbiBtZXNzYWdlIGlzIGlkZW50 aWZpZWQgYnkgU0ZNVD0yLg0KDQoNClNlY3Rpb24gNy4sIHBhcmFncmFwaCAzMjoNCk9MRDoNCg0K ICAgIFRoZSBGQ0kgZmllbGQgaGFzIHRoZSBzdHJ1Y3R1cmUgZGVwaWN0ZWQgaW4gRmlndXJlIDYu DQoNCk5FVzoNCg0KICAgIFRoZSBGQ0kgZmllbGQgaGFzIHRoZSBzdHJ1Y3R1cmUgZGVwaWN0ZWQg aW4gRmlndXJlIDcuDQoNCg0KU2VjdGlvbiA3LiwgcGFyYWdyYXBoIDMzOg0KT0xEOg0KDQogICAg ICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAg ICAgICAgMw0KICAgICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAw IDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgIHwgICAgICBNU04g ICAgfFN8ICAgUmVzcG9uc2UgICAgfCAgICAgICAgICAgICBSc3ZkLiAgICAgICAgICAgICB8DQog ICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKw0KICAgICAgfCAgICAgICAgRXh0ZW5kZWQgUlRQIFNlcW51bSBvZiB0aGUg Rmlyc3QgQnVyc3QgUGFja2V0ICAgICAgICAgIHwNCiAgICAgICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAgICB8ICAg ICAgICAgICAgICAgICAgRWFybGllc3QgTXVsdGljYXN0IEpvaW4gVGltZSAgICAgICAgICAgICAg ICAgfA0KICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgQnVy c3QgRHVyYXRpb24gICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICArLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAg ICAgfCAgICAgICAgICAgICAgICAgICAgICAgTWF4IEJ1cnN0IEJpdHJhdGUgICAgICAgICAgICAg ICAgICAgICAgIHwNCiAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAgICA6ICAgICAgICAgICAgICAgICAgICAo VExWLWVuY29kZWQgRXh0ZW5zaW9ucykgICAgICAgICAgICAgICAgICAgOg0KICAgICAgOiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IDoNCiAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rDQoNCk5FVzoNCg0KICAgICAgIDAgICAgICAgICAgICAgICAgICAg MSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMNCiAgICAgICAwIDEgMiAz IDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEN CiAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rDQogICAgICB8ICAgIFNGTVQ9MiAgICAgfCAgICAgIE1TTiAgICB8U3wg ICBSZXNwb25zZSAgICB8ICAgICBSc3ZkLiAgICAgfA0KICAgICAgKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgIHwg ICAgICAgIEV4dGVuZGVkIFJUUCBTZXFudW0gb2YgdGhlIEZpcnN0IEJ1cnN0IFBhY2tldCAgICAg ICAgICB8DQogICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICAgOiAgICAgIE9wdGlvbmFsIFRMVi1lbmNvZGVk IEZpZWxkcyAoYW5kIFBhZGRpbmcsIGlmIG5lZWRlZCkgICAgIDoNCiAgICAgICstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQoN Cg0KU2VjdGlvbiA3LiwgcGFyYWdyYXBoIDM0Og0KT0xEOg0KDQogICAgICAgICBGaWd1cmUgNjog RkNJIGZpZWxkIHN5bnRheCBmb3IgdGhlIFJBTVMgSW5mb3JtYXRpb24gbWVzc2FnZQ0KDQpORVc6 DQoNCiAgICAgICAgIEZpZ3VyZSA3OiBGQ0kgZmllbGQgc3ludGF4IGZvciB0aGUgUkFNUyBJbmZv cm1hdGlvbiBtZXNzYWdlDQoNCg0KU2VjdGlvbiA3LiwgcGFyYWdyYXBoIDQxOg0KT0xEOg0KDQog ICAgICAgMS4gIFN1Y2Nlc3MNCiANCiAgICAgICAyLiAgQmFkX1JlcXVlc3QNCg0KTkVXOg0KDQog ICAgICAgMS4gIFN1Y2Nlc3MNCiAgICAgICAyLiAgQmFkX1JlcXVlc3QNCg0KDQpTZWN0aW9uIDcu LCBwYXJhZ3JhcGggNDU6DQpPTEQ6DQoNCiAgICBvICBSc3ZkICgxNiBiaXRzKTogIFJlc2VydmVk LiAgVGhpcyBmaWVsZCBTSEFMTCBiZSBzZXQgdG8gMC4NCg0KTkVXOg0KDQogICAgbyAgUnN2ZCAo OCBiaXRzKTogIFJlc2VydmVkLiAgVGhpcyBmaWVsZCBTSEFMTCBiZSBzZXQgdG8gMC4NCg0KDQpT ZWN0aW9uIDcuLCBwYXJhZ3JhcGggNTA6DQpPTEQ6DQoNCiAgICBvICBCdXJzdCBEdXJhdGlvbiAo MzIgYml0cyk6ICBPcHRpb25hbCBUTFYgZWxlbWVudCB0aGF0IGRlbm90ZXMgdGhlDQogICAgICAg ZHVyYXRpb24gb2YgdGhlIGJ1cnN0IHRoYXQgUlMgaXMgcGxhbm5pbmcgdG8gc2VuZCAoaW4gUlRQ IHRpY2tzKS4NCiAgICAgICBJbiB0aGUgYWJzZW5jZSBvZiBhZGRpdGlvbmFsIHN0aW11bHVzLCBS UyB3aWxsIHNlbmQgYSBidXJzdCBvZg0KICAgICAgIHRoaXMgZHVyYXRpb24uICBIb3dldmVyLCB0 aGUgYnVyc3QgZHVyYXRpb24gbWF5IGJlIG1vZGlmaWVkIGJ5DQogICAgICAgc3Vic2VxdWVudCBl dmVudHMsIGluY2x1ZGluZyBjaGFuZ2VzIGluIHRoZSBwcmltYXJ5IG11bHRpY2FzdA0KICAgICAg IHN0cmVhbSBhbmQgcmVjZXB0aW9uIG9mIFJBTVMtVCBtZXNzYWdlcy4NCg0KTkVXOg0KDQogICAg ICAgVHlwZTogIFRCRA0KIA0KICAgICAgIExlbmd0aDogIFRCRA0KIA0KICAgIG8gIEJ1cnN0IER1 cmF0aW9uICgzMiBiaXRzKTogIE9wdGlvbmFsIFRMViBlbGVtZW50IHRoYXQgZGVub3RlcyB0aGUN CiAgICAgICBkdXJhdGlvbiBvZiB0aGUgYnVyc3QgdGhhdCBSUyBpcyBwbGFubmluZyB0byBzZW5k IChpbiBSVFAgdGlja3MpLg0KICAgICAgIEluIHRoZSBhYnNlbmNlIG9mIGFkZGl0aW9uYWwgc3Rp bXVsdXMsIFJTIHdpbGwgc2VuZCBhIGJ1cnN0IG9mDQogICAgICAgdGhpcyBkdXJhdGlvbi4gIEhv d2V2ZXIsIHRoZSBidXJzdCBkdXJhdGlvbiBtYXkgYmUgbW9kaWZpZWQgYnkNCiAgICAgICBzdWJz ZXF1ZW50IGV2ZW50cywgaW5jbHVkaW5nIGNoYW5nZXMgaW4gdGhlIHByaW1hcnkgbXVsdGljYXN0 DQogICAgICAgc3RyZWFtIGFuZCByZWNlcHRpb24gb2YgUkFNUy1UIG1lc3NhZ2VzLg0KDQoNClNl Y3Rpb24gNy4sIHBhcmFncmFwaCA1MjoNCk9MRDoNCg0KICAgIG8gIE1heCBCdXJzdCBCaXRyYXRl ICgzMiBiaXRzKTogIE9wdGlvbmFsIFRMViBlbGVtZW50IHRoYXQgZGVub3Rlcw0KICAgICAgIHRo ZSBtYXhpbXVtIGJpdHJhdGUgKGluIGJpdHMgcGVyIHNlY29uZCkgdGhhdCB3aWxsIGJlIHVzZWQg YnkgUlMNCiAgICAgICBmb3IgdGhlIHVuaWNhc3QgYnVyc3QuDQoNCk5FVzoNCg0KICAgICAgIFR5 cGU6ICBUQkQNCiANCiAgICAgICBMZW5ndGg6ICBUQkQNCiANCiAgICBvICBNYXggQnVyc3QgQml0 cmF0ZSAoMzIgYml0cyk6ICBPcHRpb25hbCBUTFYgZWxlbWVudCB0aGF0IGRlbm90ZXMNCiAgICAg ICB0aGUgbWF4aW11bSBiaXRyYXRlIChpbiBiaXRzIHBlciBzZWNvbmQpIHRoYXQgd2lsbCBiZSB1 c2VkIGJ5IFJTDQogICAgICAgZm9yIHRoZSB1bmljYXN0IGJ1cnN0Lg0KDQoNClNlY3Rpb24gNy4s IHBhcmFncmFwaCA1MzoNCk9MRDoNCg0KICAgIFRoZSBzZW1hbnRpY3Mgb2YgdGhlIFJBTVMtSSBm ZWVkYmFjayBtZXNzYWdlIGlzIGluZGVwZW5kZW50IG9mIHRoZQ0KICAgIHBheWxvYWQgdHlwZS4N Cg0KTkVXOg0KDQogICAgICAgVHlwZTogIFRCRA0KIA0KICAgICAgIExlbmd0aDogIFRCRA0KIA0K ICAgIFRoZSBzZW1hbnRpY3Mgb2YgdGhlIFJBTVMtSSBmZWVkYmFjayBtZXNzYWdlIGlzIGluZGVw ZW5kZW50IG9mIHRoZQ0KICAgIHBheWxvYWQgdHlwZS4NCg0KDQpTZWN0aW9uIDcuLCBwYXJhZ3Jh cGggNTU6DQpPTEQ6DQoNCiA3LjMuICBSQU1TIFRlcm1pbmF0aW9uDQoNCk5FVzoNCg0KIDcuNC4g IFJBTVMgVGVybWluYXRpb24NCg0KDQpTZWN0aW9uIDcuLCBwYXJhZ3JhcGggNTY6DQpPTEQ6DQoN CiAgICBUaGUgUkFNUyBUZXJtaW5hdGlvbiBtZXNzYWdlIGlzIGlkZW50aWZpZWQgYnkgUFQ9UlRQ RkIgYW5kIEZNVD04Lg0KDQpORVc6DQoNCiAgICBUaGUgUkFNUyBUZXJtaW5hdGlvbiBtZXNzYWdl IGlzIGlkZW50aWZpZWQgYnkgU0ZNVD0zLg0KDQoNClNlY3Rpb24gNy4sIHBhcmFncmFwaCA2MToN Ck9MRDoNCg0KICAgIFRoZSBGQ0kgZmllbGQgaGFzIHRoZSBzdHJ1Y3R1cmUgZGVwaWN0ZWQgaW4g RmlndXJlIDcuDQoNCk5FVzoNCg0KICAgIFRoZSBGQ0kgZmllbGQgaGFzIHRoZSBzdHJ1Y3R1cmUg ZGVwaWN0ZWQgaW4gRmlndXJlIDguDQoNCg0KU2VjdGlvbiA3LiwgcGFyYWdyYXBoIDYyOg0KT0xE Og0KDQogICAgICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAg ICAgICAgICAgICAgICAgMw0KICAgICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUg NiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KICAgICAgKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgIHwg ICAgICAgICBFeHRlbmRlZCBSVFAgU2VxbnVtIG9mIEZpcnN0IE11bHRpY2FzdCBQYWNrZXQgICAg ICAgICB8DQogICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICAgOiAgICAgICAgICAgICAgICAgICAgKFRMVi1l bmNvZGVkIEV4dGVuc2lvbnMpICAgICAgICAgICAgICAgICAgIDoNCiAgICAgIDogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA6DQog ICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKw0KDQpORVc6DQoNCiAgICAgICAwICAgICAgICAgICAgICAgICAgIDEgICAg ICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzDQogICAgICAgMCAxIDIgMyA0IDUg NiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxDQogICAg ICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKw0KICAgICAgfCAgICBTRk1UPTMgICAgIHwgICAgICAgICAgT3B0aW9uYWwgVExW LWVuY29kZWQgRmllbGRzICAgICAgICAgIHwNCiAgICAgICstKy0rLSstKy0rLSstKy0rICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICA6ICAgICAg T3B0aW9uYWwgVExWLWVuY29kZWQgRmllbGRzIChhbmQgUGFkZGluZywgaWYgbmVlZGVkKSAgICAg Og0KICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSsNCg0KDQpTZWN0aW9uIDcuLCBwYXJhZ3JhcGggNjM6DQpPTEQ6DQoN CiAgICAgICAgIEZpZ3VyZSA3OiBGQ0kgZmllbGQgc3ludGF4IGZvciB0aGUgUkFNUyBUZXJtaW5h dGlvbiBtZXNzYWdlDQoNCk5FVzoNCg0KICAgICAgICAgRmlndXJlIDg6IEZDSSBmaWVsZCBzeW50 YXggZm9yIHRoZSBSQU1TIFRlcm1pbmF0aW9uIG1lc3NhZ2UNCg0KDQpTZWN0aW9uIDcuLCBwYXJh Z3JhcGggNjU6DQpPTEQ6DQoNCiAgICBUaGUgc2VtYW50aWNzIG9mIHRoZSBSQU1TLVQgZmVlZGJh Y2sgbWVzc2FnZSBpcyBpbmRlcGVuZGVudCBvZiB0aGUNCiAgICBwYXlsb2FkIHR5cGUuDQogDQog Ny40LiAgRXh0ZW5zaW9ucw0KIA0KICAgIFRvIGltcHJvdmUgdGhlIGZ1bmN0aW9uYWxpdHkgb2Yg dGhlIFJBTVMgbWV0aG9kIGluIGNlcnRhaW4NCiAgICBhcHBsaWNhdGlvbnMsIGl0IG1heSBiZSBk ZXNpcmFibGUgdG8gZGVmaW5lIG5ldyBmaWVsZHMgaW4gdGhlIFJBTVMNCiAgICBSZXF1ZXN0LCBJ bmZvcm1hdGlvbiBhbmQgVGVybWluYXRpb24gbWVzc2FnZXMuICBTdWNoIGZpZWxkcyBNVVNUIGJl DQogICAgZGVmaW5lZCBhcyBUTFYgZWxlbWVudHMuICBJZiB0aGUgZ29hbCBpbiBkZWZpbmluZyB0 aGVzZSBuZXcgZmllbGRzIGlzDQogICAgdG8gZXh0ZW5kIHRoZSBwcm90b2NvbCBpbiBhIHZlbmRv ci1uZXV0cmFsIG1hbm5lciwgdGhleSBNVVNUIGJlDQogICAgcmVnaXN0ZXJlZCB3aXRoIElBTkEg dGhyb3VnaCBhbiBJbmZvcm1hdGlvbmFsIG9yIGEgU3RhbmRhcmRzLXRyYWNrDQogICAgUkZDLiAg VGhlIHN1cHBvcnQgZm9yIHRoZXNlIG5ldyBmaWVsZHMgaXMgT1BUSU9OQUwuICBJbiBhbiBSQU1T DQogICAgbWVzc2FnZSwgYW55IGV4dGVuc2lvbiBNVVNUIGJlIHBsYWNlZCBhZnRlciBhbnkgZXhp c3RpbmcgbWFuZGF0b3J5DQogICAgZmllbGQgZm9yIHRoYXQgbWVzc2FnZS4NCiANCiAgICBFZGl0 b3IncyBub3RlOiAgV2Ugc2hvdWxkIHNwZWNpZnkgdGhlIHJlcXVpcmVtZW50cyBmb3IgcmVnaXN0 ZXJpbmcNCiAgICBuZXcgVExWIGVsZW1lbnRzLg0KIA0KICAgIEl0IGlzIGFsc28gZGVzaXJhYmxl IHRvIGFsbG93IHZlbmRvcnMgdG8gdXNlIHZlbmRvci1zcGVjaWZpYw0KICAgIGV4dGVuc2lvbnMg KGluIFRMViBmb3JtYXQpIGluIGFueSBvZiB0aGUgUkFNUyBtZXNzYWdlcy4gIEZvcg0KICAgIGlu dGVyb3BlcmFiaWxpdHksIHN1Y2ggZXh0ZW5zaW9ucyBNVVNUIE5PVCBjb2xsaWRlIHdpdGggZWFj aCBvdGhlci4NCiANCiAgICBFZGl0b3IncyBub3RlOiAgU29tZSBhcHByb2FjaGVzIGFyZSBjdXJy ZW50bHkgYmVpbmcgZXhhbWluZWQgZm9yDQogICAgdmVuZG9yLXNwZWNpZmljIGV4dGVuc2lvbnMu ICBBIHBvdGVudGlhbCBzb2x1dGlvbiBpcyBkZXBpY3RlZCBpbg0KICAgIEZpZ3VyZSA4LiAgSW4g dGhpcyBhcHByb2FjaCwgdGhlIGVudGVycHJpc2UgbnVtYmVycyBhcmUgdXNlZCBmcm9tDQogICAg aHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9lbnRlcnByaXNlLW51bWJlcnMuICBUaGlz IHdpbGwgZW5zdXJlDQogICAgdGhlIHVuaXF1ZW5lc3Mgb2YgdGhlIHZlbmRvci1zcGVjaWZpYyBl eHRlbnNpb25zLg0KDQpORVc6DQoNCiAgICAgICBUeXBlOiAgVEJEDQoNCg0KU2VjdGlvbiA3Liwg cGFyYWdyYXBoIDY2Og0KT0xEOg0KDQogICAgICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAg ICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMw0KICAgICAgIDAgMSAyIDMgNCA1IDYg NyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KICAgICAg Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSsNCiAgICAgIDogICAgICAgICAgTWFuZGF0b3J5IEZpZWxkcyBhcyBEZWZpbmVkIGlu IFRoaXMgRG9jdW1lbnQgICAgICAgICA6DQogICAgICA6ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOg0KICAgICAgKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsN CiAgICAgIHwgICBUeXBlID0gVEJEICB8ICAgICAgICAgICAgTGVuZ3RoICAgICAgICAgICAgIHwg IEVudC4gTnVtYmVyICB8DQogICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICAgfCAgICAgICAgICAgICAgIEVu dC4gTnVtYmVyIGNvbnRkLiAgICAgICAgICAgICAgfCAgICAgVmFsdWUgICAgIHwNCiAgICAgICst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rDQogICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICBWYWx1ZSBjb250ZC4gICAg ICAgICAgICAgICAgICAgICAgICAgLw0KICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCg0KTkVXOg0KDQogICAgICAg TGVuZ3RoOiAgVEJEDQoNCg0KU2VjdGlvbiA3LiwgcGFyYWdyYXBoIDY3Og0KT0xEOg0KDQogICAg ICAgICAgICAgRmlndXJlIDg6IFN0cnVjdHVyZSBvZiBhIHZlbmRvci1zcGVjaWZpYyBleHRlbnNp b24NCg0KTkVXOg0KDQogICAgVGhlIHNlbWFudGljcyBvZiB0aGUgUkFNUy1UIGZlZWRiYWNrIG1l c3NhZ2UgaXMgaW5kZXBlbmRlbnQgb2YgdGhlDQogICAgcGF5bG9hZCB0eXBlLg0KDQoNCg0KU2Vj dGlvbiAxMy4sIHBhcmFncmFwaCAxOg0KT0xEOg0KDQogICAgVGhpcyBkb2N1bWVudCByZWdpc3Rl cnMgYSBuZXcgU0RQIGF0dHJpYnV0ZSB2YWx1ZSBhbmQgc2V2ZXJhbCBuZXcNCiAgICBSVENQIHBh Y2tldHMuDQogDQogICAgVGhlIGZvbGxvd2luZyBjb250YWN0IGluZm9ybWF0aW9uIHNoYWxsIGJl IHVzZWQgZm9yIGFsbCByZWdpc3RyYXRpb25zDQogICAgaW4gdGhpcyBkb2N1bWVudDoNCg0KTkVX Og0KDQogICAgVGhlIGZvbGxvd2luZyBjb250YWN0IGluZm9ybWF0aW9uIHNoYWxsIGJlIHVzZWQg Zm9yIGFsbCByZWdpc3RyYXRpb25zDQogICAgaW4gdGhpcyBkb2N1bWVudDoNCg0KDQpTZWN0aW9u IDEzLjIuLCBwYXJhZ3JhcGggMToNCk9MRDoNCg0KICAgIFdpdGhpbiB0aGUgUlRQRkIgcmFuZ2Us IHRoZSBmb2xsb3dpbmcgdGhyZWUgZm9ybWF0IChGTVQpIHZhbHVlcyBhcmUNCiAgICByZWdpc3Rl cmVkOg0KDQpORVc6DQoNCiAgICBXaXRoaW4gdGhlIFJUUEZCIHJhbmdlLCB0aGUgZm9sbG93aW5n IGZvcm1hdCAoRk1UKSB2YWx1ZSBpcw0KICAgIHJlZ2lzdGVyZWQ6DQoNCg0KU2VjdGlvbiAxMy4y LiwgcGFyYWdyYXBoIDI6DQpPTEQ6DQoNCiAgICAgICAgIE5hbWU6ICAgICAgICAgICBSQU1TLVIN CiAgICAgICAgIExvbmcgbmFtZTogICAgICBSYXBpZCBBY3F1aXNpdGlvbiBvZiBNdWx0aWNhc3Qg U2Vzc2lvbnMgUmVxdWVzdA0KICAgICAgICAgVmFsdWU6ICAgICAgICAgIDYNCiAgICAgICAgIFJl ZmVyZW5jZTogICAgICBUaGlzIGRvY3VtZW50DQoNCk5FVzoNCg0KICAgICAgICAgTmFtZTogICAg ICAgICAgIFJBTVMNCiAgICAgICAgIExvbmcgbmFtZTogICAgICBSYXBpZCBBY3F1aXNpdGlvbiBv ZiBNdWx0aWNhc3QgU2Vzc2lvbnMNCiAgICAgICAgIFZhbHVlOiAgICAgICAgICA2DQogICAgICAg ICBSZWZlcmVuY2U6ICAgICAgVGhpcyBkb2N1bWVudA0KDQoNClNlY3Rpb24gMTMuMi4sIHBhcmFn cmFwaCAzOg0KT0xEOg0KDQogICAgICBOYW1lOiAgICAgICAgICAgUkFNUy1JDQogICAgICBMb25n IG5hbWU6ICAgICAgUmFwaWQgQWNxdWlzaXRpb24gb2YgTXVsdGljYXN0IFNlc3Npb25zIEluZm9y bWF0aW9uDQogICAgICBWYWx1ZTogICAgICAgICAgNw0KICAgICAgUmVmZXJlbmNlOiAgICAgIFRo aXMgZG9jdW1lbnQNCg0KTkVXOg0KDQogMTMuMy4gIFNGTVQgVmFsdWVzIGZvciBSQU1TIE1lc3Nh Z2VzIFJlZ2lzdHJ5DQoNCg0KU2VjdGlvbiAxMy4yLiwgcGFyYWdyYXBoIDQ6DQpPTEQ6DQoNCiAg ICAgIE5hbWU6ICAgICAgICAgICBSQU1TLVQNCiAgICAgIExvbmcgbmFtZTogICAgICBSYXBpZCBB Y3F1aXNpdGlvbiBvZiBNdWx0aWNhc3QgU2Vzc2lvbnMgVGVybWluYXRpb24NCiAgICAgIFZhbHVl OiAgICAgICAgICA4DQogICAgICBSZWZlcmVuY2U6ICAgICAgVGhpcyBkb2N1bWVudA0KDQpORVc6 DQoNCiAgICBUaGlzIGRvY3VtZW50IGNyZWF0ZXMgYSBuZXcgc3ViLXJlZ2lzdHJ5IGZvciB0aGUg c3ViLWZlZWRiYWNrIG1lc3NhZ2UNCiAgICB0eXBlIChTRk1UKSB2YWx1ZXMgdG8gYmUgdXNlZCB3 aXRoIHRoZSBGTVQgdmFsdWUgcmVnaXN0ZXJlZCBmb3IgUkFNUw0KICAgIG1lc3NhZ2VzLiAgVGhl IHJlZ2lzdHJ5IGlzIGNhbGxlZCB0aGUgU0ZNVCBWYWx1ZXMgZm9yIFJBTVMgTWVzc2FnZXMNCiAg ICBSZWdpc3RyeS4gIFRoaXMgcmVnaXN0cnkgaXMgdG8gYmUgbWFuYWdlZCBieSB0aGUgSUFOQSBh Y2NvcmRpbmcgdG8NCiAgICB0aGUgU3BlY2lmaWNhdGlvbiBSZXF1aXJlZCBwb2xpY3kgb2YgW1JG QzUyMjZdLg0KIA0KICAgIFRoZSBsZW5ndGggb2YgdGhlIFNGTVQgZmllbGQgaW4gdGhlIFJBTVMg bWVzc2FnZXMgaXMgYSBzaW5nbGUgb2N0ZXQsDQogICAgYWxsb3dpbmcgMjU2IHZhbHVlcy4gIFRo ZSByZWdpc3RyeSBpcyBpbml0aWFsaXplZCB3aXRoIHRoZSBmb2xsb3dpbmcNCiAgICBlbnRyaWVz Og0KIA0KICAgVmFsdWUgTmFtZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgUmVmZXJlbmNlDQogICAtLS0tLSAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSAtLS0tLS0tLS0tLS0tDQogICAxICAgICBSQU1TIFJlcXVl c3QgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUaGlzIGRvY3VtZW50DQog ICAyICAgICBSQU1TIEluZm9ybWF0aW9uICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBUaGlzIGRvY3VtZW50DQogICAzICAgICBSQU1TIFRlcm1pbmF0aW9uICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBUaGlzIGRvY3VtZW50DQogDQogICAgVGhlIFNGTVQgdmFsdWVz IDAgYW5kIDI1NSBhcmUgcmVzZXJ2ZWQgZm9yIGZ1dHVyZSB1c2UuDQogDQogICAgQW55IHJlZ2lz dHJhdGlvbiBmb3IgYW4gdW5hc3NpZ25lZCBTRk1UIHZhbHVlIE1VU1QgY29udGFpbiB0aGUNCiAg ICBmb2xsb3dpbmcgaW5mb3JtYXRpb246DQogDQogICAgbyAgQ29udGFjdCBpbmZvcm1hdGlvbiBv ZiB0aGUgb25lIGRvaW5nIHRoZSByZWdpc3RyYXRpb24sIGluY2x1ZGluZw0KICAgICAgIGF0IGxl YXN0IG5hbWUsIGFkZHJlc3MsIGFuZCBlbWFpbC4NCiANCiAgICBvICBBIGRldGFpbGVkIGRlc2Ny aXB0aW9uIG9mIHdoYXQgdGhlIG5ldyBTRk1UIHJlcHJlc2VudHMgYW5kIGhvdyBpdA0KICAgICAg IHNoYWxsIGJlIGludGVycHJldGVkLg0KIA0KICAgIE5vdGUgdGhhdCBuZXcgUkFNUyBmdW5jdGlv bmFsaXR5IHNob3VsZCBiZSBpbnRyb2R1Y2VkIGJ5IHVzaW5nIHRoZQ0KICAgIGV4dGVuc2lvbiBt ZWNoYW5pc20gd2l0aGluIHRoZSBleGlzdGluZyBSQU1TIG1lc3NhZ2UgdHlwZXMgbm90IGJ5DQog ICAgaW50cm9kdWNpbmcgbmV3IG1lc3NhZ2UgdHlwZXMgdW5sZXNzIGl0IGlzIGFic29sdXRlbHkg bmVjZXNzYXJ5Lg0KIA0KIDEzLjQuICBSQU1TIFRMViBTcGFjZSBSZWdpc3RyeQ0KIA0KICAgIFRo aXMgZG9jdW1lbnQgY3JlYXRlcyBhIG5ldyBJQU5BIFRMViBzcGFjZSByZWdpc3RyeSBmb3IgdGhl IFJBTVMNCiAgICBleHRlbnNpb25zLiAgVGhlIHJlZ2lzdHJ5IGlzIGNhbGxlZCB0aGUgUkFNUyBU TFYgU3BhY2UgUmVnaXN0cnkuDQogICAgVGhpcyByZWdpc3RyeSBpcyB0byBiZSBtYW5hZ2VkIGJ5 IHRoZSBJQU5BIGFjY29yZGluZyB0byB0aGUNCiAgICBTcGVjaWZpY2F0aW9uIFJlcXVpcmVkIHBv bGljeSBvZiBbUkZDNTIyNl0uDQogDQogICAgVGhlIGxlbmd0aCBvZiB0aGUgVHlwZSBmaWVsZCBp biB0aGUgVExWIGVsZW1lbnRzIGlzIGEgc2luZ2xlIG9jdGV0LA0KICAgIGFsbG93aW5nIDI1NiB2 YWx1ZXMuICBUaGUgcmVnaXN0cnkgaXMgaW5pdGlhbGl6ZWQgd2l0aCB0aGUgZm9sbG93aW5nDQog ICAgZW50cmllczoNCiANCiAgICBUeXBlIERlc2NyaXB0aW9uICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFJlZmVyZW5jZQ0KICAgIC0tLS0gLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gLS0tLS0tLS0tLS0tLQ0KICAgIFRCRCAg VEJEICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVGhpcyBk b2N1bWVudA0KICAgIC4uLiAgLi4uDQogDQogICAgVGhlIHJlZ2lzdHJ5IGVudHJpZXMgYXJlIFRC Qy4NCiANCiAgICBUaGUgVFlQRSB2YWx1ZXMgMCBhbmQgMjU1IGFyZSByZXNlcnZlZCBmb3IgZnV0 dXJlIHVzZS4gIFRoZSBUWVBFDQogICAgdmFsdWVzIGJldHdlZW4gKGFuZCBpbmNsdWRpbmcpIDEy OCBhbmQgMjU0IGFyZSByZXNlcnZlZCBmb3IgcHJpdmF0ZQ0KICAgIGV4dGVuc2lvbnMuDQogDQog ICAgQW55IHJlZ2lzdHJhdGlvbiBmb3IgYW4gdW5hc3NpZ25lZCBUWVBFIHZhbHVlIE1VU1QgY29u dGFpbiB0aGUNCiAgICBmb2xsb3dpbmcgaW5mb3JtYXRpb246DQogDQogICAgbyAgQ29udGFjdCBp bmZvcm1hdGlvbiBvZiB0aGUgb25lIGRvaW5nIHRoZSByZWdpc3RyYXRpb24sIGluY2x1ZGluZw0K ICAgICAgIGF0IGxlYXN0IG5hbWUsIGFkZHJlc3MsIGFuZCBlbWFpbC4NCiANCiAgICBvICBBIGRl dGFpbGVkIGRlc2NyaXB0aW9uIG9mIHdoYXQgdGhlIG5ldyBUTFYgZWxlbWVudCByZXByZXNlbnRz IGFuZA0KICAgICAgIGhvdyBpdCBzaGFsbCBiZSBpbnRlcnByZXRlZC4NCg0K ------_=_NextPart_001_01C9D583.2031B360-- From root@core3.amsl.com Fri May 15 14:15:01 2009 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A993028C1B5; Fri, 15 May 2009 14:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090515211501.A993028C1B5@core3.amsl.com> Date: Fri, 15 May 2009 14:15:01 -0700 (PDT) Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-atrac-family-23.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2009 21:15:01 -0000 --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 Adaptive TRansform Acoustic Coding (ATRAC) Family Author(s) : J. Matsumoto, M. Hatanaka Filename : draft-ietf-avt-rtp-atrac-family-23.txt Pages : 35 Date : 2009-5-15 This document describes an RTP payload format for efficient and flexible transporting of audio data encoded with the Adaptive TRansform Audio Coding (ATRAC) family of codecs. Recent enhancements to the ATRAC family of codecs support high quality audio coding with multiple channels. The RTP payload format as presented in this document also includes support for data fragmentation, elementary redundancy measures, and a variation on scalable streaming. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-atrac-family-23.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-avt-rtp-atrac-family-23.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-5-15141232.I-D@ietf.org> --NextPart-- From awells@ambarella.com Fri May 15 16:54:06 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D48DF3A69BB for ; Fri, 15 May 2009 16:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsiOVpZeK6Xi for ; Fri, 15 May 2009 16:54:02 -0700 (PDT) Received: from ambarella-ex.ambarella.net (ambarella-ex.ambarella.net [63.164.14.166]) by core3.amsl.com (Postfix) with ESMTP id 8053D3A6E3A for ; Fri, 15 May 2009 16:54:01 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9D5B8.A3F2C64B" Date: Fri, 15 May 2009 16:55:35 -0700 Message-ID: <90B0CE4312136749B97EBEAF5764F87403A851BA@ambarella-ex.ambarella.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: 3984bis-06 and pic timing SEI Thread-Index: AcnViPVYIaDyXSPpTU2JzIE+Kbz3tgAL3Dww From: "Aaron Wells" To: Subject: [AVT] FW: RE: 3984bis-06 and pic timing SEI X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2009 23:54:06 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9D5B8.A3F2C64B Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable > All, >=20 > Apologies in advance if this retraces old ground: >=20 > I see the following directive in the draft: >=20 > "RTP senders SHOULD NOT transmit picture timing SEI messages for >=20 > pictures that are not supposed to be displayed as multiple=20 > fields." >=20 > I understand this to mean that pic_timing SEI should > not be sent for field pictures.=20 >=20 > If so, this raises a few questions for me: > The picture timing SEI message tells the decoder whether a field is to >=20 > be displayed as a top (pic_struct=3D1) or bottom (pic_struct=3D2) > field. If the RTP sender were to strip these SEI from the stream, > how is this information conveyed to the decoder? >=20 > The standard directs that if pic_stuct_present flag > is set in the SPS, then a picture_timing_SEI message will=20 > be present in every access unit.=20 > Similarly, the SEI message is required if either=20 > nal_hrd_parameters or vcl_hrd_parameters is set to 1. > Is it further intended that the RTP sender also to parse=20 > VUI and mask out these bits? >=20 > If the pic timing SEI message is stripped and if > the h.264 stream contains both field and frame coded video, > then is it expected that the RTP sender parses into each slice > header to determine the picture structure, then selectively > strips the pic timing SEI messages from field pictures? >=20 > If this is the case, how should the pic_struct_present flag > be set in the VUI? >=20 > Why is the immediately preceding directive > "Receivers SHOULD ignore any picture timing SEI messages > included=20 > in access units that have only one display timestamp.=20 > Instead, receivers SHOULD use the RTP timestamp for=20 > synchronizing the display process" > insufficient? >=20 > Thanks >=20 > Aaron >=20 >=20 >=20 >=20 ------_=_NextPart_001_01C9D5B8.A3F2C64B Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable FW: RE: 3984bis-06 and pic timing SEI

All,

Apologies in advance if this retraces = old ground:

I see the following directive in the = draft:

        "RTP senders SHOULD NOT transmit picture timing SEI messages for
       pictures that are not supposed to = be displayed as multiple
       fields."

I understand this to mean that = pic_timing SEI should
not be sent for field pictures. =

If so, this raises a few = questions for me:
The picture timing SEI message = tells the decoder whether a field is to
be displayed as a top = (pic_struct=3D1) or bottom (pic_struct=3D2)
field. If the RTP sender were to = strip these SEI from the stream,
how is this information conveyed = to the decoder?

The standard directs that if = pic_stuct_present flag
is set in the SPS, then a = picture_timing_SEI message will
be present in every access unit. =
Similarly, the SEI message is = required if either
nal_hrd_parameters or = vcl_hrd_parameters is set to 1.
Is it further intended that the = RTP sender also to parse
VUI and mask out these = bits?

If the pic timing SEI message is = stripped and if
the h.264 stream contains both field and frame coded video,
then is it expected that the RTP = sender parses into each slice
header to determine the picture = structure, then selectively
strips the pic timing SEI = messages from field pictures?

If this is the case, how should = the pic_struct_present flag
be set in the VUI?

Why is the immediately preceding = directive
         "Receivers SHOULD ignore any picture timing SEI messages = included
        in = access units that have only one display timestamp.=20
          Instead, receivers SHOULD use the RTP = timestamp for
          synchronizing the display = process"
insufficient?

Thanks

Aaron




------_=_NextPart_001_01C9D5B8.A3F2C64B-- From erwin.davis@gmail.com Sat May 16 20:56:27 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3924B3A6944 for ; Sat, 16 May 2009 20:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMIpTZqlE9WU for ; Sat, 16 May 2009 20:56:26 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by core3.amsl.com (Postfix) with ESMTP id 7251B3A69D7 for ; Sat, 16 May 2009 20:56:19 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so2970916yxb.49 for ; Sat, 16 May 2009 20:57:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=ENIfsz03uG3aSfk+fHcdfcJuEmA7vG3xHxXAQUCWI+4=; b=hDVVnp8aKDR1vXcN+wXDeLE2/dEkYB9CgR6cW7stBR9dYxVhBY2EQlXNJwxNlPJUgU xC5EyhuS0X1D663Sxz1+lnE+9josT36ismsp/80XcFVbRSx18iqk+u9uVsR+mtSP5u6A EyyEc3Ot22+HwBeHdlz/lKvfZfpcGk/hIAUO0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=H1+EKcDsysV41zi8uGHElMMk5QlZy+5oygDq4MLbTc8KEQiOSKNUndfDdawnaPN0wd w2icgc6lZ068A236JxMHoo8a8a9xn0a0k8kRHur2lzQlqRx+0j16SgqZQqNPYpSwrHb9 vt4xN7aIOQeVgWNnCDxgV1P7h2hCKS6s4Nlek= MIME-Version: 1.0 Received: by 10.151.98.8 with SMTP id a8mr9431840ybm.270.1242532671921; Sat, 16 May 2009 20:57:51 -0700 (PDT) Date: Sat, 16 May 2009 20:57:51 -0700 Message-ID: From: Erwin Huang To: avt@ietf.org Content-Type: multipart/alternative; boundary=00151750eee0882d61046a13aeca Subject: [AVT] Looking for Java RTP stack implementation X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2009 03:56:27 -0000 --00151750eee0882d61046a13aeca Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello, I am looking for Java RTP stack implementation (or with JNI wrapper) suitable for RTP media proxy application, either open source or commecial. JMF from Sun is out-date and not supported any more. Thanks in advance for your information, Regards, e --00151750eee0882d61046a13aeca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello,
=A0
I am looking for Java RTP stack implementation (or with=A0JNI wrapper)= suitable for=A0RTP media proxy application, either open source or commecia= l. JMF from Sun is out-date and not supported any more. Thanks in advance f= or your information,
=A0
Regards,
=A0
e
--00151750eee0882d61046a13aeca-- From Even.roni@huawei.com Mon May 18 03:36:18 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25D153A6961 for ; Mon, 18 May 2009 03:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jBjD1b8Hy4I for ; Mon, 18 May 2009 03:36:12 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id B55973A6FFF for ; Mon, 18 May 2009 03:35:51 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJU00K4C5EH5C@szxga04-in.huawei.com> for avt@ietf.org; Mon, 18 May 2009 18:35:05 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJU00C1G5EHBZ@szxga04-in.huawei.com> for avt@ietf.org; Mon, 18 May 2009 18:35:05 +0800 (CST) Received: from windows8d787f9 (bzq-79-181-118-116.red.bezeqint.net [79.181.118.116]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJU000XF5DN3V@szxml01-in.huawei.com>; Mon, 18 May 2009 18:35:05 +0800 (CST) Date: Mon, 18 May 2009 13:34:04 +0300 From: Roni Even In-reply-to: <5ef5d7280905151712w28c996d0v242b60144f5860f6@mail.gmail.com> To: 'Timur Friedman' , 'Tom Taylor' Message-id: <001601c9d7a4$3ce1d010$b6a57030$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_VAd+s1rDXyos9ioZNTboZg)" Content-language: en-us Thread-index: AcnVvB8nEvpwnIUCTFm7nRqM88P0XgB5/WUA References: <5ef5d7280904222031te6b6570r2760491dafee65f@mail.gmail.com> <5ef5d7280904281216h68cda0c7p9039db4ffda7209f@mail.gmail.com> <5ef5d7280905041953v7cd824a2s19cdb325d33942a@mail.gmail.com> <5ef5d7280905151712w28c996d0v242b60144f5860f6@mail.gmail.com> Cc: 'Nick Duffield' , avt@ietf.org, "'CACERES, RAMON \(ATTLABS\)'" Subject: Re: [AVT] misleading RFC 3611 statement on RTCP packet stacking X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 10:36:18 -0000 This is a multipart message in MIME format. --Boundary_(ID_VAd+s1rDXyos9ioZNTboZg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, This sounds like a reasonable suggestion. You can do it this way or maybe to make it simpler change "XR packets supplement the existing RTCP packets, and may be stacked with other RTCP packets to form compound RTCP packets [9, Section 6]." to "XR packets supplement the existing RTCP packets according to RFC 3550[9] Roni Even On Tue, Apr 28, 2009 at 12:16 PM, Timur Friedman wrote: To follow up on our proposal to file an RFC Errata report, here, for more direct comparison, is the RFC 3611 text immediately followed by our suggestion for how it should be read: > "XR packets supplement the existing RTCP packets, and may be stacked with > other RTCP packets to form compound RTCP packets [9, Section 6]." > "XR packets supplement the existing RTCP packets, and stack with other RTCP > packets to form compound RTCP packets, as described in Sec. 6 of RFC 3550 > [9]." Timur On Wed, Apr 22, 2009 at 8:31 PM, Timur Friedman wrote: > Some people are reading RFC 3611 as overriding RFC 3550 on RTCP packet > stacking. > > This is what Sec. 1.1 of RFC 3611 says: > > "XR packets supplement the existing RTCP packets, and may be stacked with > other RTCP packets to form compound RTCP packets [9, Section 6]." > > Reference 9 is RFC 3550, which says: > > "all RTCP packets MUST be sent in a compound packet of at least two > individual packets" > > That is, RFC 3550 says that RTCP packets MUST be stacked into a compound > packet, and some people are reading RFC 3611 as weakening that mandate to > say only that RTCP packets MAY be stacked into a compound packet (but also > MAY NOT, at least in the case of the XR packet). > > As one of the authors of RFC 3611, I can say that it was not my intention to > override RFC 3550. Nor was it the intention of the two of my eight > co-authors who I have discussed this with. Rather, the purpose of this > sentence was to remind the reader that XR packets, like any RTCP packets, > are designed to be stacked, and to helpfully point the reader to the RFC > 3550 section that deals with RTCP packet stacking for further details. > > To the best of my recollection, no discussion in AVT leading up to approval > of RFC 3611 indicates that any group participants at the time believed that > RFC 3611 would override RFC 3550 on RTCP packet stacking. > > Still, I understand how people are reading RFC 3611 in this way. It does say > "may be stacked", and though "may" is not capitalized, it is nonetheless an > RFC 2119 keyword, meaning that the item is truly optional. > > Co-authors Nick Duffield, Ramon Caceres, and myself would like to open > discussion on how to address this situation. We start by suggesting that we > file an RFC Errata report, indicating that the sentence should read instead: > > "XR packets supplement the existing RTCP packets, and stack with other RTCP > packets to form compound RTCP packets, as described in Sec. 6 of RFC 3550 > [9]." > > By dropping the "may", we drop any hint that this RFC overrides the RFC 3550 > stacking mandate. And by adding "as described in Sec. 6 of RFC 3550" we make > clear the informational nature of this sentence. > > Timur Friedman > > --Boundary_(ID_VAd+s1rDXyos9ioZNTboZg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi,

This sounds like a reasonable suggestion. You can do it this way or maybe to make it simpler change

 

"XR packets supplement the existing RTCP packets, and may be stacked with other RTCP packets to form compound RTCP packets [9, Section 6]."

 

to

 

"XR packets supplement the existing RTCP packets according to RFC 3550[9]

 

 

Roni Even

 

 

 

On Tue, Apr 28, 2009 at 12:16 PM, Timur Friedman <timur.friedman@upmc.fr> wrote:

To follow up on our proposal to file an RFC Errata report, here, for
more direct comparison, is the RFC 3611 text immediately followed by
our suggestion for how it should be read:


> "XR packets supplement the existing RTCP packets, and may be stacked with
> other RTCP packets to form compound RTCP packets [9, Section 6]."

> “XR packets supplement the existing RTCP packets, and stack with other RTCP
> packets to form compound RTCP packets, as described in Sec. 6 of RFC 3550
> [9].”

Timur



On Wed, Apr 22, 2009 at 8:31 PM, Timur Friedman <timur.friedman@upmc.fr> wrote:
> Some people are reading RFC 3611 as overriding RFC 3550 on RTCP packet
> stacking.
>
> This is what Sec. 1.1 of RFC 3611 says:
>
> "XR packets supplement the existing RTCP packets, and may be stacked with
> other RTCP packets to form compound RTCP packets [9, Section 6]."
>
> Reference 9 is RFC 3550, which says:
>
> "all RTCP packets MUST be sent in a compound packet of at least two
> individual packets"
>
> That is, RFC 3550 says that RTCP packets MUST be stacked into a compound
> packet, and some people are reading RFC 3611 as weakening that mandate to
> say only that RTCP packets MAY be stacked into a compound packet (but also
> MAY NOT, at least in the case of the XR packet).
>
> As one of the authors of RFC 3611, I can say that it was not my intention to
> override RFC 3550. Nor was it the intention of the two of my eight
> co-authors who I have discussed this with. Rather, the purpose of this
> sentence was to remind the reader that XR packets, like any RTCP packets,
> are designed to be stacked, and to helpfully point the reader to the RFC
> 3550 section that deals with RTCP packet stacking for further details.
>
> To the best of my recollection, no discussion in AVT leading up to approval
> of RFC 3611 indicates that any group participants at the time believed that
> RFC 3611 would override RFC 3550 on RTCP packet stacking.
>
> Still, I understand how people are reading RFC 3611 in this way. It does say
> "may be stacked", and though "may" is not capitalized, it is nonetheless an
> RFC 2119 keyword, meaning that the item is truly optional.
>
> Co-authors Nick Duffield, Ramon Caceres, and myself would like to open
> discussion on how to address this situation. We start by suggesting that we
> file an RFC Errata report, indicating that the sentence should read instead:
>
> “XR packets supplement the existing RTCP packets, and stack with other RTCP
> packets to form compound RTCP packets, as described in Sec. 6 of RFC 3550
> [9].”
>
> By dropping the "may", we drop any hint that this RFC overrides the RFC 3550
> stacking mandate. And by adding "as described in Sec. 6 of RFC 3550" we make
> clear the informational nature of this sentence.
>
> Timur Friedman
>
>

 

 

--Boundary_(ID_VAd+s1rDXyos9ioZNTboZg)-- From wwwrun@core3.amsl.com Mon May 18 06:26:11 2009 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 9D7C73A7036; Mon, 18 May 2009 06:26:11 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20090518132611.9D7C73A7036@core3.amsl.com> Date: Mon, 18 May 2009 06:26:11 -0700 (PDT) Cc: Internet Architecture Board , avt mailing list , avt chair , RFC Editor Subject: [AVT] Protocol Action: 'RTP Payload Format for the Speex Codec' to Proposed Standard X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 13:26:11 -0000 The IESG has approved the following document: - 'RTP Payload Format for the Speex Codec ' as a Proposed Standard This document is the product of the Audio/Video Transport Working Group. The IESG contact persons are Cullen Jennings and Robert Sparks. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-speex-07.txt Technical Summary Speex is an open-source voice codec suitable for use in Voice over IP (VoIP) type applications. This document describes the payload format for Speex generated bit streams within an RTP packet. Also included here are the necessary details for the use of Speex with the Session Description Protocol (SDP). Working Group Summary The initial version of this draft was submitted in February 2002, and was eventually adopted as a working group draft in October 2005. After several false starts and changes in authorship, interest and progress picked up in 2007, leading to the completion of the draft. Adoption of the draft by the working group was delayed due to confusion on which signalling mechanisms should be defined. More recently, discussion has focussed on the detailed use of RTP headers, and media type parameter. The resulting format is a straight-forward RTP payload type specification. Document Quality There are several existing implementations (e.g. Ekiga, gstreamer). A Media type review was conducted starting on 31 March 2008; no issues were raised. Personnel Colin Perkins is the document shepherd. Cullen Jennings is the responsible area director. From ron.even.tlv@gmail.com Mon May 18 00:35:25 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BE6A28C24E for ; Mon, 18 May 2009 00:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s+S42NdTCd6d for ; Mon, 18 May 2009 00:35:24 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by core3.amsl.com (Postfix) with ESMTP id AC6923A69B4 for ; Mon, 18 May 2009 00:35:23 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so450453fga.18 for ; Mon, 18 May 2009 00:36:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=rS0eV286do7ZDjQsJWNBtUXtq1kEobpAQhAzT75qQOk=; b=czhl5OBzx2kPqs0ojoGN9FUug1+NVKcUWlivZvQ/ob8bKVUxB4ROBkSbpa5L6nb9Ih hH65TYdkOnlpdt3GyU0L4qjSDzrCBJy+N7ISh7ovMTo3R/d2BeqnGX2IVcKql+N7GFRc Zw8RVJ1vSgAO9AX9A3OaZItp8xYoXYtNGioXs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; b=nujM4g0cZ/YPvRykOuvogPuRb3PXmBwczu6Cp2HhXGrUmnbOSgAHqRxQsIp+dP8gNu HB0vpRp3p0iiPaZXAWff0IdixDKFSCLIPMH5IBDBtu4sst6Qh/d0RUQIlxNdjio9KhXV lB6y0kvVGtqAY1QZtW8ZDt6nvBpSGUFvB7ca4= Received: by 10.86.51.2 with SMTP id y2mr6460486fgy.3.1242632214690; Mon, 18 May 2009 00:36:54 -0700 (PDT) Received: from windows8d787f9 (bzq-79-181-118-116.red.bezeqint.net [79.181.118.116]) by mx.google.com with ESMTPS id e11sm4178297fga.1.2009.05.18.00.36.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 18 May 2009 00:36:53 -0700 (PDT) From: "Roni Even" To: "'Timur Friedman'" , References: <5ef5d7280904222031te6b6570r2760491dafee65f@mail.gmail.com> <5ef5d7280904281216h68cda0c7p9039db4ffda7209f@mail.gmail.com> In-Reply-To: <5ef5d7280904281216h68cda0c7p9039db4ffda7209f@mail.gmail.com> Date: Mon, 18 May 2009 10:36:19 +0300 Message-ID: <4a111015.0b38560a.1dde.ffffd1b7@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnINe194A2a9ZjsSeqwL4wtuy1JrQPUsp/w Content-Language: en-us X-Mailman-Approved-At: Mon, 18 May 2009 08:05:34 -0700 Subject: Re: [AVT] misleading RFC 3611 statement on RTCP packet stacking X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 07:35:25 -0000 Hi, This sounds like a reasonable suggestion. You can do it this way or maybe to make it simpler change "XR packets supplement the existing RTCP packets, and may be stacked with other RTCP packets to form compound RTCP packets [9, Section 6]." to "XR packets supplement the existing RTCP packets according to RFC 3550[9] Roni Even -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Timur Friedman Sent: Tuesday, April 28, 2009 10:17 PM To: avt@ietf.org Subject: Re: [AVT] misleading RFC 3611 statement on RTCP packet stacking To follow up on our proposal to file an RFC Errata report, here, for more direct comparison, is the RFC 3611 text immediately followed by our suggestion for how it should be read: > "XR packets supplement the existing RTCP packets, and may be stacked with > other RTCP packets to form compound RTCP packets [9, Section 6]." > "XR packets supplement the existing RTCP packets, and stack with other RTCP > packets to form compound RTCP packets, as described in Sec. 6 of RFC 3550 > [9]." Timur On Wed, Apr 22, 2009 at 8:31 PM, Timur Friedman wrote: > Some people are reading RFC 3611 as overriding RFC 3550 on RTCP packet > stacking. > > This is what Sec. 1.1 of RFC 3611 says: > > "XR packets supplement the existing RTCP packets, and may be stacked with > other RTCP packets to form compound RTCP packets [9, Section 6]." > > Reference 9 is RFC 3550, which says: > > "all RTCP packets MUST be sent in a compound packet of at least two > individual packets" > > That is, RFC 3550 says that RTCP packets MUST be stacked into a compound > packet, and some people are reading RFC 3611 as weakening that mandate to > say only that RTCP packets MAY be stacked into a compound packet (but also > MAY NOT, at least in the case of the XR packet). > > As one of the authors of RFC 3611, I can say that it was not my intention to > override RFC 3550. Nor was it the intention of the two of my eight > co-authors who I have discussed this with. Rather, the purpose of this > sentence was to remind the reader that XR packets, like any RTCP packets, > are designed to be stacked, and to helpfully point the reader to the RFC > 3550 section that deals with RTCP packet stacking for further details. > > To the best of my recollection, no discussion in AVT leading up to approval > of RFC 3611 indicates that any group participants at the time believed that > RFC 3611 would override RFC 3550 on RTCP packet stacking. > > Still, I understand how people are reading RFC 3611 in this way. It does say > "may be stacked", and though "may" is not capitalized, it is nonetheless an > RFC 2119 keyword, meaning that the item is truly optional. > > Co-authors Nick Duffield, Ramon Caceres, and myself would like to open > discussion on how to address this situation. We start by suggesting that we > file an RFC Errata report, indicating that the sentence should read instead: > > "XR packets supplement the existing RTCP packets, and stack with other RTCP > packets to form compound RTCP packets, as described in Sec. 6 of RFC 3550 > [9]." > > By dropping the "may", we drop any hint that this RFC overrides the RFC 3550 > stacking mandate. And by adding "as described in Sec. 6 of RFC 3550" we make > clear the informational nature of this sentence. > > Timur Friedman > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www.ietf.org/mailman/listinfo/avt From yekuiwang@huawei.com Mon May 18 08:42:20 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF83A3A6952 for ; Mon, 18 May 2009 08:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.53 X-Spam-Level: X-Spam-Status: No, score=-0.53 tagged_above=-999 required=5 tests=[AWL=-1.416, BAYES_50=0.001, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PmhGR-dBxfyB for ; Mon, 18 May 2009 08:42:20 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id E5ECB3A68FB for ; Mon, 18 May 2009 08:42:19 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJU00CZIJP6VK@usaga02-in.huawei.com> for avt@ietf.org; Mon, 18 May 2009 08:43:55 -0700 (PDT) Received: from W90946 ([10.51.0.87]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJU00I6KJOYAU@usaga02-in.huawei.com> for avt@ietf.org; Mon, 18 May 2009 08:43:54 -0700 (PDT) Date: Mon, 18 May 2009 11:43:44 -0400 From: Ye-Kui Wang In-reply-to: <90B0CE4312136749B97EBEAF5764F87403A851BA@ambarella-ex.ambarella.net> To: 'Aaron Wells' , avt@ietf.org Message-id: <64BD7B1DAF524ACD84CF35826E6399FB@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_TqPJvwoyeN2r1/0eA7+LoQ)" Thread-index: AcnViPVYIaDyXSPpTU2JzIE+Kbz3tgAL3DwwAIW0RFA= References: <90B0CE4312136749B97EBEAF5764F87403A851BA@ambarella-ex.ambarella.net> Subject: Re: [AVT] FW: RE: 3984bis-06 and pic timing SEI X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 15:42:20 -0000 This is a multi-part message in MIME format. --Boundary_(ID_TqPJvwoyeN2r1/0eA7+LoQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Aaron, Good question and convincing analysis. I would agree that the following should be removed. "RTP senders SHOULD NOT transmit picture timing SEI messages for pictures that are not supposed to be displayed as multiple fields." BR,YK _____ From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Aaron Wells Sent: Friday, May 15, 2009 7:56 PM To: avt@ietf.org Subject: [AVT] FW: RE: 3984bis-06 and pic timing SEI All, Apologies in advance if this retraces old ground: I see the following directive in the draft: "RTP senders SHOULD NOT transmit picture timing SEI messages for pictures that are not supposed to be displayed as multiple fields." I understand this to mean that pic_timing SEI should not be sent for field pictures. If so, this raises a few questions for me: The picture timing SEI message tells the decoder whether a field is to be displayed as a top (pic_struct=1) or bottom (pic_struct=2) field. If the RTP sender were to strip these SEI from the stream, how is this information conveyed to the decoder? The standard directs that if pic_stuct_present flag is set in the SPS, then a picture_timing_SEI message will be present in every access unit. Similarly, the SEI message is required if either nal_hrd_parameters or vcl_hrd_parameters is set to 1. Is it further intended that the RTP sender also to parse VUI and mask out these bits? If the pic timing SEI message is stripped and if the h.264 stream contains both field and frame coded video, then is it expected that the RTP sender parses into each slice header to determine the picture structure, then selectively strips the pic timing SEI messages from field pictures? If this is the case, how should the pic_struct_present flag be set in the VUI? Why is the immediately preceding directive "Receivers SHOULD ignore any picture timing SEI messages included in access units that have only one display timestamp. Instead, receivers SHOULD use the RTP timestamp for synchronizing the display process" insufficient? Thanks Aaron --Boundary_(ID_TqPJvwoyeN2r1/0eA7+LoQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT FW: RE: 3984bis-06 and pic timing SEI
Aaron,
 
Good question and convincing analysis. I would agree that the following should be removed.
 

        "RTP senders SHOULD NOT transmit picture timing SEI messages for
       pictures that are not supposed to be displayed as multiple
       fields."

 
BR,YK

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Aaron Wells
Sent: Friday, May 15, 2009 7:56 PM
To: avt@ietf.org
Subject: [AVT] FW: RE: 3984bis-06 and pic timing SEI


All,

Apologies in advance if this retraces old ground:

I see the following directive in the draft:

        "RTP senders SHOULD NOT transmit picture timing SEI messages for
       pictures that are not supposed to be displayed as multiple
       fields."

I understand this to mean that pic_timing SEI should
not be sent for field pictures.

If so, this raises a few questions for me:
The picture timing SEI message tells the decoder whether a field is to
be displayed as a top (pic_struct=1) or bottom (pic_struct=2)
field. If the RTP sender were to strip these SEI from the stream,
how is this information conveyed to the decoder?

The standard directs that if pic_stuct_present flag
is set in the SPS, then a picture_timing_SEI message will
be present in every access unit.
Similarly, the SEI message is required if either
nal_hrd_parameters or vcl_hrd_parameters is set to 1.
Is it further intended that the RTP sender also to parse
VUI and mask out these bits?

If the pic timing SEI message is stripped and if
the h.264 stream contains both field and frame coded video,
then is it expected that the RTP sender parses into each slice
header to determine the picture structure, then selectively
strips the pic timing SEI messages from field pictures?

If this is the case, how should the pic_struct_present flag
be set in the VUI?

Why is the immediately preceding directive
         "Receivers SHOULD ignore any picture timing SEI messages included
        in access units that have only one display timestamp.
          Instead, receivers SHOULD use the RTP timestamp for
          synchronizing the display process"
insufficient?

Thanks

Aaron




--Boundary_(ID_TqPJvwoyeN2r1/0eA7+LoQ)-- From yekuiwang@huawei.com Mon May 18 08:56:28 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D6363A6996 for ; Mon, 18 May 2009 08:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3aksBUefVK8B for ; Mon, 18 May 2009 08:56:27 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id B6A603A6B27 for ; Mon, 18 May 2009 08:56:15 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJU00EPDKCAB3@usaga04-in.huawei.com> for avt@ietf.org; Mon, 18 May 2009 10:57:47 -0500 (CDT) Received: from W90946 ([10.51.0.87]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJU00AV3KC5T5@usaga04-in.huawei.com> for avt@ietf.org; Mon, 18 May 2009 10:57:46 -0500 (CDT) Date: Mon, 18 May 2009 11:57:39 -0400 From: Ye-Kui Wang In-reply-to: <5E07A2E74C0749B7A84371EE422E90C6@china.huawei.com> To: 'Tom Taylor' Message-id: <545DD1B15C9A42F0B1729CC02FFC6348@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcnS12m0h4LXrKfCSPuypoWoF4LcBAAMSXzwATG6vIA= References: <04CAD96D4C5A3D48B1919248A8FE0D540943CDB9@xmb-sjc-215.amer.cisco.com> <2713212F2F334A15AB3DB03E1BB45156@china.huawei.com> <4A092C12.8080704@rogers.com> <5E07A2E74C0749B7A84371EE422E90C6@china.huawei.com> Cc: ron.even.tlv@gmail.com, avt@ietf.org Subject: Re: [AVT] Q for 3984bis-06 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 15:56:28 -0000 Tom, All, Let me try to give a summary of the discussion of level upgrade. To my understanding, there has been no clear conclusion that level upgrade is absolutely needed, and there has been no clear proposal that has no issue. For support of the original use case Ashish Goyal proposed, which is copied below for convenience, there is no need to change anything in the draft "Here is how the use case is expected to work. Assume the video device A is able to decode level 3.1 and encode only level 1.1 B is capable of both decoding and encoding level 3.1. A would quote a level of 3.1 in its offer B would respond with level 3.1 in the answer A would send to B video stream at level 1.1 - since A can only encode at level 1.1. B would send level 3.1 to A since A can decode upto level 3.1." Therefore, my take is not to make any change in this regard. Any different opinions? BR,YK > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > Behalf Of Ye-Kui Wang > Sent: Tuesday, May 12, 2009 9:50 AM > To: 'Tom Taylor' > Cc: ron.even.tlv@gmail.com; avt@ietf.org > Subject: Re: [AVT] Q for 3984bis-06 > > > Yes, please go ahead. > > BR,YK > > > -----Original Message----- > > From: Tom Taylor [mailto:tom.taylor@rogers.com] > > Sent: Tuesday, May 12, 2009 3:58 AM > > To: Ye-Kui Wang > > Cc: 'Ali C. Begen (abegen)'; avt@ietf.org; ron.even.tlv@gmail.com > > Subject: Re: [AVT] Q for 3984bis-06 > > > > I was waiting for the discussion of level upgrade to settle. > > Should I issue a summary of what I have seen so far? > > > > Ye-Kui Wang wrote: > > > Thanks Ali. This is an intact inheritance from RFC 3984. > > I'd agree to > > > remove the note in the next submission. > > > > > > BTW, AVT Chairs, what is the plan on progressing this and > > the SVC drafts? > > > > > > BR, YK > > > > > >> -----Original Message----- > > >> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] > > On Behalf Of > > >> Ali C. Begen (abegen) > > >> Sent: Monday, May 11, 2009 5:08 PM > > >> To: avt@ietf.org > > >> Subject: [AVT] Q for 3984bis-06 > > >> > > >> Page 12 says: > > >> > > >> Informative note: Because H.264 allows the > > decoding order to > > >> be different from the display order, values of RTP > > >> timestamps > > >> may not be monotonically non-decreasing as a > > function of RTP > > >> sequence numbers. Furthermore, the value for > > inter-arrival > > >> > > >> This is not something specific for H.264 content. It applies to > > >> almost all codecs. A rewording may be beneficial IMO. > > >> > > >> jitter reported in the RTCP reports may not be a > > trustworthy > > >> indication of the network performance, as the > calculation > > >> rules for inter-arrival jitter (section 6.4.1 of > > RFC 3550) > > >> assume that the RTP timestamp of a packet is directly > > >> proportional to its transmission time. > > >> > > >> What does it mean that RTP timestamp is proportional to its > > >> transmission time? By "transmission time" do you mean the > > instant the > > >> packet was sent? By definition, timestamp reflects the sampling > > >> instant of the first octet in the RTP packet. The packets > > belong to a > > >> single video frame will most likely have the same > > timestamp. But that > > >> does not mean that they will be transmitted at the same time. > > >> > > >> RFC 3550 has a simple rule here and says this rule must be > > followed. > > >> The packets are considered in the order they arrive, not > based on > > >> their seqnums in the jitter calculation. > > >> And the parameters needed to compute the interarrival jitter are > > >> clock rate, timestamp and arrival-time timestamp. > > >> > > >> I suggest a revision for this informative note, or we can simply > > >> remove it since section 6.4.4 of RFC 3550 already provides a > > >> more-than-sufficient explanation. > > >> > > >> -acbegen > > >> > > >> _______________________________________________ > > >> Audio/Video Transport Working Group avt@ietf.org > > >> https://www.ietf.org/mailman/listinfo/avt > > >> > > > > > > > > > > > > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > From stephen.botzko@gmail.com Mon May 18 09:11:45 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B7BB3A6D28 for ; Mon, 18 May 2009 09:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ig95-stsjrc7 for ; Mon, 18 May 2009 09:11:44 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 5BE4A3A6AFC for ; Mon, 18 May 2009 09:11:23 -0700 (PDT) Received: by fxm2 with SMTP id 2so3337725fxm.37 for ; Mon, 18 May 2009 09:12:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=GGxgXD/Eix9894d2RklASJlIgMd/Bc7s2gqlvDoVbSU=; b=QRvZkSh5qzpuZOcb0EY3xErkOtPlB1vOBHFo2GXp4I4lozZqux/1u8Q0cuIgumybr+ co6x5iUT0JQ2aaHSAyPh7ELoOgMDNQm/EDifUW1sgMQA/ZySk9fJHAMHnpWg3aLl5X+m QhpJ0eY0SjqsZ8a0Y9M7VYR0Eab0ite9gy4XE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Q/lELB0wldmYzkwCPnBMEvd4PSxBaC+p8JdCVPmiyAXf/f3IMnSj69aUURdj4lrll/ xcLL2zuQ1OMtRpA6iBi6syuJr9O1KgfnITboKIc2Xs7uPxDbfJaiYdQMrfxQpX1tLhRB xog0l5UnOCJ/vvmkUCUDhHjfDc0G1HobWO1Iw= MIME-Version: 1.0 Received: by 10.103.197.14 with SMTP id z14mr1600163mup.1.1242663159312; Mon, 18 May 2009 09:12:39 -0700 (PDT) In-Reply-To: <545DD1B15C9A42F0B1729CC02FFC6348@china.huawei.com> References: <04CAD96D4C5A3D48B1919248A8FE0D540943CDB9@xmb-sjc-215.amer.cisco.com> <2713212F2F334A15AB3DB03E1BB45156@china.huawei.com> <4A092C12.8080704@rogers.com> <5E07A2E74C0749B7A84371EE422E90C6@china.huawei.com> <545DD1B15C9A42F0B1729CC02FFC6348@china.huawei.com> Date: Mon, 18 May 2009 12:12:39 -0400 Message-ID: <6e9223710905180912n2986d490pfde029ff32dc99b2@mail.gmail.com> From: stephen botzko To: Ye-Kui Wang Content-Type: multipart/alternative; boundary=0016e649dad22fb2a7046a321087 Cc: ron.even.tlv@gmail.com, Tom Taylor , avt@ietf.org Subject: Re: [AVT] Q for 3984bis-06 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 16:11:45 -0000 --0016e649dad22fb2a7046a321087 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This makes sense to me. Of course it does not apply to profiles, since the profiles are not intended to form a hierarchy. But the levels do form a hierarchy - the ability to decode level 3.1 of a given profile implies the ability to decode all lower levels. Regards, Stephen Botzko On Mon, May 18, 2009 at 11:57 AM, Ye-Kui Wang wrote: > > Tom, All, > > Let me try to give a summary of the discussion of level upgrade. To my > understanding, there has been no clear conclusion that level upgrade is > absolutely needed, and there has been no clear proposal that has no issue. > For support of the original use case Ashish Goyal proposed, which is copied > below for convenience, there is no need to change anything in the draft > > "Here is how the use case is expected to work. > Assume the video device A is able to decode level 3.1 and encode only > level 1.1 > B is capable of both decoding and encoding level 3.1. > A would quote a level of 3.1 in its offer > B would respond with level 3.1 in the answer > A would send to B video stream at level 1.1 - since A can only encode at > level 1.1. > B would send level 3.1 to A since A can decode upto level 3.1." > > Therefore, my take is not to make any change in this regard. Any different > opinions? > > BR,YK > > > -----Original Message----- > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > > Behalf Of Ye-Kui Wang > > Sent: Tuesday, May 12, 2009 9:50 AM > > To: 'Tom Taylor' > > Cc: ron.even.tlv@gmail.com; avt@ietf.org > > Subject: Re: [AVT] Q for 3984bis-06 > > > > > > Yes, please go ahead. > > > > BR,YK > > > > > -----Original Message----- > > > From: Tom Taylor [mailto:tom.taylor@rogers.com] > > > Sent: Tuesday, May 12, 2009 3:58 AM > > > To: Ye-Kui Wang > > > Cc: 'Ali C. Begen (abegen)'; avt@ietf.org; ron.even.tlv@gmail.com > > > Subject: Re: [AVT] Q for 3984bis-06 > > > > > > I was waiting for the discussion of level upgrade to settle. > > > Should I issue a summary of what I have seen so far? > > > > > > Ye-Kui Wang wrote: > > > > Thanks Ali. This is an intact inheritance from RFC 3984. > > > I'd agree to > > > > remove the note in the next submission. > > > > > > > > BTW, AVT Chairs, what is the plan on progressing this and > > > the SVC drafts? > > > > > > > > BR, YK > > > > > > > >> -----Original Message----- > > > >> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] > > > On Behalf Of > > > >> Ali C. Begen (abegen) > > > >> Sent: Monday, May 11, 2009 5:08 PM > > > >> To: avt@ietf.org > > > >> Subject: [AVT] Q for 3984bis-06 > > > >> > > > >> Page 12 says: > > > >> > > > >> Informative note: Because H.264 allows the > > > decoding order to > > > >> be different from the display order, values of RTP > > > >> timestamps > > > >> may not be monotonically non-decreasing as a > > > function of RTP > > > >> sequence numbers. Furthermore, the value for > > > inter-arrival > > > >> > > > >> This is not something specific for H.264 content. It applies to > > > >> almost all codecs. A rewording may be beneficial IMO. > > > >> > > > >> jitter reported in the RTCP reports may not be a > > > trustworthy > > > >> indication of the network performance, as the > > calculation > > > >> rules for inter-arrival jitter (section 6.4.1 of > > > RFC 3550) > > > >> assume that the RTP timestamp of a packet is directly > > > >> proportional to its transmission time. > > > >> > > > >> What does it mean that RTP timestamp is proportional to its > > > >> transmission time? By "transmission time" do you mean the > > > instant the > > > >> packet was sent? By definition, timestamp reflects the sampling > > > >> instant of the first octet in the RTP packet. The packets > > > belong to a > > > >> single video frame will most likely have the same > > > timestamp. But that > > > >> does not mean that they will be transmitted at the same time. > > > >> > > > >> RFC 3550 has a simple rule here and says this rule must be > > > followed. > > > >> The packets are considered in the order they arrive, not > > based on > > > >> their seqnums in the jitter calculation. > > > >> And the parameters needed to compute the interarrival jitter are > > > >> clock rate, timestamp and arrival-time timestamp. > > > >> > > > >> I suggest a revision for this informative note, or we can simply > > > >> remove it since section 6.4.4 of RFC 3550 already provides a > > > >> more-than-sufficient explanation. > > > >> > > > >> -acbegen > > > >> > > > >> _______________________________________________ > > > >> Audio/Video Transport Working Group avt@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/avt > > > >> > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > > > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > --0016e649dad22fb2a7046a321087 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This makes sense to me.=A0

Of course it does not apply to profiles,= since the profiles are not intended to form a hierarchy.=A0 But the levels= do form a hierarchy - the ability to decode level 3.1 of a given profile i= mplies the ability to decode all lower levels.

Regards,
Stephen Botzko

On Mon, Ma= y 18, 2009 at 11:57 AM, Ye-Kui Wang <yekuiwang@huawei.com> wrote:

Tom, All,

Let me try to give a summary of the discussion of level upgrade. To my
understanding, there has been no clear conclusion that level upgrade is
absolutely needed, and there has been no clear proposal that has no issue.<= br> For support of the original use case Ashish Goyal proposed, which is copied=
below for convenience, there is no need to change anything in the draft

"Here is how the use case is expected to work.
=A0Assume the video device A is able to decode level 3.1 and encode only level 1.1
=A0B is capable of both decoding and encoding level 3.1.
=A0A would quote a level of 3.1 in its offer
=A0B would respond with level 3.1 in the answer
=A0A would send to B video stream at level 1.1 - since A can only encode a= t
level 1.1.
=A0B would send level 3.1 to A since A can decode upto level 3.1."
Therefore, my take is not to make any change in this regard. Any different<= br> opinions?

BR,YK

> -----Original Message-----
> From: avt-bounces@ietf.org= [mailto:avt-bounces@ietf.org] = On
> Behalf Of Ye-Kui Wang
> Sent: Tuesday, May 12, 2009 9:50 AM
> To: 'Tom Taylor'
> Cc: ron.even.tlv@gmail.com; avt@ietf.org
> Subject: Re: [AVT] Q for 3984bis-06
>
>
> Yes, please go ahead.
>
> BR,YK
>
> > -----Original Message-----
> > From: Tom Taylor [mailto:tom.taylor@rogers.com]
> > Sent: Tuesday, May 12, 2009 3:58 AM
> > To: Ye-Kui Wang
> > Cc: 'Ali C. Begen (abegen)'; avt@ietf.org; ron.even.tl= v@gmail.com
> > Subject: Re: [AVT] Q for 3984bis-06
> >
> > I was waiting for the discussion of level upgrade to settle.
> > Should I issue a summary of what I have seen so far?
> >
> > Ye-Kui Wang wrote:
> > > Thanks Ali. This is an intact inheritance from RFC 3984.
> > I'd agree to
> > > remove the note in the next submission.
> > >
> > > BTW, AVT Chairs, what is the plan on progressing this and > > the SVC drafts?
> > >
> > > BR, YK
> > >
> > >> -----Original Message-----
> > >> From: avt-bounce= s@ietf.org [mailto:avt-bounces@= ietf.org]
> > On Behalf Of
> > >> Ali C. Begen (abegen)
> > >> Sent: Monday, May 11, 2009 5:08 PM
> > >> To: avt@ietf.org
> > >> Subject: [AVT] Q for 3984bis-06
> > >>
> > >> Page 12 says:
> > >>
> > >> =A0 =A0 =A0 =A0 =A0Informative note: Because H.264 allow= s the
> > decoding order to
> > >> =A0 =A0 =A0 =A0 =A0be different from the display order, = values of RTP
> > >> timestamps
> > >> =A0 =A0 =A0 =A0 =A0may not be monotonically non-decreasi= ng as a
> > function of RTP
> > >> =A0 =A0 =A0 =A0 =A0sequence numbers. =A0Furthermore, the= value for
> > inter-arrival
> > >>
> > >> This is not something specific for H.264 content. It app= lies to
> > >> almost all codecs. A rewording may be beneficial IMO. > > >>
> > >> =A0 =A0 =A0 =A0 =A0jitter reported in the RTCP reports m= ay not be a
> > trustworthy
> > >> =A0 =A0 =A0 =A0 =A0indication of the network performance= , as the
> calculation
> > >> =A0 =A0 =A0 =A0 =A0rules for inter-arrival jitter (secti= on 6.4.1 of
> > RFC 3550)
> > >> =A0 =A0 =A0 =A0 =A0assume that the RTP timestamp of a pa= cket is directly
> > >> =A0 =A0 =A0 =A0 =A0proportional to its transmission time= .
> > >>
> > >> What does it mean that RTP timestamp is proportional to = its
> > >> transmission time? By "transmission time" do y= ou mean the
> > instant the
> > >> packet was sent? By definition, timestamp reflects the s= ampling
> > >> instant of the first octet in the RTP packet. The packet= s
> > belong to a
> > >> single video frame will most likely have the same
> > timestamp. But that
> > >> does not mean that they will be transmitted at the same = time.
> > >>
> > >> RFC 3550 has a simple rule here and says this rule must = be
> > followed.
> > >> The packets are considered in the order they arrive, not=
> based on
> > >> their seqnums in the jitter calculation.
> > >> And the parameters needed to compute the interarrival ji= tter are
> > >> clock rate, timestamp and arrival-time timestamp.
> > >>
> > >> I suggest a revision for this informative note, or we ca= n simply
> > >> remove it since section 6.4.4 of RFC 3550 already provid= es a
> > >> more-than-sufficient explanation.
> > >>
> > >> -acbegen
> > >>
> > >> _______________________________________________
> > >> Audio/Video Transport Working Group avt@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/avt
> > >>
> > >
> > >
> > >
> >
>
>
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt
>


_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/avt

--0016e649dad22fb2a7046a321087-- From rjesup@wgate.com Mon May 18 11:41:40 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 075223A6987 for ; Mon, 18 May 2009 11:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.373 X-Spam-Level: X-Spam-Status: No, score=-0.373 tagged_above=-999 required=5 tests=[AWL=-1.053, BAYES_40=-0.185, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3ynEiz-fbvv for ; Mon, 18 May 2009 11:41:39 -0700 (PDT) Received: from exchange1.wgate.com (pr-66-150-46-254.wgate.com [66.150.46.254]) by core3.amsl.com (Postfix) with ESMTP id 0627F3A6966 for ; Mon, 18 May 2009 11:41:38 -0700 (PDT) Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 May 2009 14:43:14 -0400 To: Ye-Kui Wang References: <04CAD96D4C5A3D48B1919248A8FE0D540943CDB9@xmb-sjc-215.amer.cisco.com> <2713212F2F334A15AB3DB03E1BB45156@china.huawei.com> <4A092C12.8080704@rogers.com> <5E07A2E74C0749B7A84371EE422E90C6@china.huawei.com> <545DD1B15C9A42F0B1729CC02FFC6348@china.huawei.com> From: Randell Jesup Date: Mon, 18 May 2009 14:45:31 -0400 In-Reply-To: <545DD1B15C9A42F0B1729CC02FFC6348@china.huawei.com> (Ye-Kui Wang's message of "Mon\, 18 May 2009 11\:57\:39 -0400") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 18 May 2009 18:43:14.0496 (UTC) FILETIME=[807EFC00:01C9D7E8] Cc: ron.even.tlv@gmail.com, 'Tom Taylor' , avt@ietf.org Subject: Re: [AVT] Q for 3984bis-06 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Randell Jesup List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 18:41:40 -0000 Ye-Kui Wang writes: >Let me try to give a summary of the discussion of level upgrade. To my >understanding, there has been no clear conclusion that level upgrade is >absolutely needed, and there has been no clear proposal that has no issue. How about this (may need a little wordsmithing): Level upgrade An offerer who wishes to allow level-upgrade in the answer can include "max-level=XX" in the fmtp line (XX is the level in hex, as it is in the middle of profile-level-id). An answerer may not increase the level in the response unless the offerer included max-level, and may not increase the level beyond XX. Other receive fmtp parameters such max-fs, etc shall apply to all levels and SHOULD not be lower than the minimum values required by the level specified in max-level. And add max-level to the list of fmtp params. Normal requirements for sprop-parameter-sets/sprop-level-parameter-sets would apply, or in-line as per normal. Simple, will not break any 3984 (or current 3984-bis) answerer. >For support of the original use case Ashish Goyal proposed, which is copied >below for convenience, there is no need to change anything in the draft > >"Here is how the use case is expected to work. > Assume the video device A is able to decode level 3.1 and encode only >level 1.1 > B is capable of both decoding and encoding level 3.1. > A would quote a level of 3.1 in its offer > B would respond with level 3.1 in the answer > A would send to B video stream at level 1.1 - since A can only encode at >level 1.1. > B would send level 3.1 to A since A can decode upto level 3.1." > >Therefore, my take is not to make any change in this regard. Any different >opinions? That use-case doesn't *need* upgrade, agreed.. The one that does (or where you gain an advantage from) is the inverse case, where something limits the size/etc an offerer wants to decode. Here's the relevant case: Assume this is a a device with a fixed LCD size, or configured to play in a small window on a larger display. ------------------------ Assume the video device A is only reasonably able to decode level 2.0, due to display limitations (QCIF LCD), but can encode up to level 3.1. B is capable of both decoding and encoding level 3.1. A would quote a level of 2.0 in its offer, including max-level=1F B would respond with level 3.1 in the answer A would send to B video stream at level 3.1 B would send level 2.0 to A since A can only decode up to level 2.0 Otherwise, A would either need to only offer 2.0 (and only send 2.0), even if it has an HD camera and the destination is an HD room conference system that can display level 5.0. You can't set max-fs lower than the min for the level offered, nor max-mbps, so you can't limit the received bitstream in that manner. In theory you might be able to limit the received bitstream crudely via b=AS:NN, but that's up to the sender to notice, comply with, and even then it doesn't mean they won't send "too large" a framesize at a lower framerate or higher quantization. -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com "The fetters imposed on liberty at home have ever been forged out of the weapons provided for defence against real, pretended, or imaginary dangers from abroad." - James Madison, 4th US president (1751-1836) From yekuiwang@huawei.com Mon May 18 13:48:31 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE57E3A6C48 for ; Mon, 18 May 2009 13:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.018 X-Spam-Level: X-Spam-Status: No, score=-1.018 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7a14L27Qb1NE for ; Mon, 18 May 2009 13:48:30 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id AD1603A6AD8 for ; Mon, 18 May 2009 13:48:30 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJU00JDMXVIH6@usaga04-in.huawei.com> for avt@ietf.org; Mon, 18 May 2009 15:50:06 -0500 (CDT) Received: from W90946 ([10.51.0.87]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJU000H3XVB25@usaga04-in.huawei.com> for avt@ietf.org; Mon, 18 May 2009 15:50:06 -0500 (CDT) Date: Mon, 18 May 2009 16:49:56 -0400 From: Ye-Kui Wang In-reply-to: To: 'Randell Jesup' Message-id: <2068ACFCE9FA4013865E833F38057DDB@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcnX6Jdy3idKalvhTSSBZmyqFzCqrQAECtmg References: <04CAD96D4C5A3D48B1919248A8FE0D540943CDB9@xmb-sjc-215.amer.cisco.com> <2713212F2F334A15AB3DB03E1BB45156@china.huawei.com> <4A092C12.8080704@rogers.com> <5E07A2E74C0749B7A84371EE422E90C6@china.huawei.com> <545DD1B15C9A42F0B1729CC02FFC6348@china.huawei.com> Cc: ron.even.tlv@gmail.com, 'Tom Taylor' , avt@ietf.org Subject: Re: [AVT] Q for 3984bis-06 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 20:48:31 -0000 Inline below. > -----Original Message----- > From: Randell Jesup [mailto:rjesup@wgate.com] > Sent: Monday, May 18, 2009 2:46 PM > To: Ye-Kui Wang > Cc: 'Tom Taylor'; ron.even.tlv@gmail.com; avt@ietf.org > Subject: Re: [AVT] Q for 3984bis-06 > > Ye-Kui Wang writes: > >Let me try to give a summary of the discussion of level > upgrade. To my > >understanding, there has been no clear conclusion that level > upgrade is > >absolutely needed, and there has been no clear proposal that > has no issue. > > How about this (may need a little wordsmithing): > > Level upgrade > > An offerer who wishes to allow level-upgrade in the answer > can include > "max-level=XX" in the fmtp line (XX is the level in hex, > as it is in the > middle of profile-level-id). An answerer may not increase > the level in > the response unless the offerer included max-level, and > may not increase > the level beyond XX. Other receive fmtp parameters such > max-fs, etc > shall apply to all levels and SHOULD not be lower than the minimum > values required by the level specified in max-level. > What is the semantics of max-level? Would the semantics of profile-level-id change? > And add max-level to the list of fmtp params. > > Normal requirements for > sprop-parameter-sets/sprop-level-parameter-sets > would apply, or in-line as per normal. > > Simple, will not break any 3984 (or current 3984-bis) answerer. > > >For support of the original use case Ashish Goyal proposed, which is > >copied below for convenience, there is no need to change anything in > >the draft > > > >"Here is how the use case is expected to work. > > Assume the video device A is able to decode level 3.1 and > encode only > >level 1.1 > > B is capable of both decoding and encoding level 3.1. > > A would quote a level of 3.1 in its offer > > B would respond with level 3.1 in the answer > > A would send to B video stream at level 1.1 - since A can > only encode > >at level 1.1. > > B would send level 3.1 to A since A can decode upto level 3.1." > > > >Therefore, my take is not to make any change in this regard. Any > >different opinions? > > That use-case doesn't *need* upgrade, agreed.. The one that > does (or where you gain an advantage from) is the inverse > case, where something limits the size/etc an offerer wants to decode. > > Here's the relevant case: Assume this is a a device with a > fixed LCD size, or configured to play in a small window on a > larger display. > ------------------------ > Assume the video device A is only reasonably able to decode > level 2.0, due to display limitations (QCIF LCD), but can > encode up to level 3.1. Decoding is different and typically decoupled from display. For example, a mobile device may be equipped with HD recording and decoding capability, but it needs an external HD display (e.g. a TV) to really display HD. However, in the absence of an HD display, the device can still still decode what it recorded but just display it in a small screen. In your example, does the video device has the capability to decoded up to level 3.1 at all? > B is capable of both decoding and encoding level 3.1. > A would quote a level of 2.0 in its offer, including > max-level=1F B would respond with level 3.1 in the answer A > would send to B video stream at level 3.1 B would send level > 2.0 to A since A can only decode up to level 2.0 > > Otherwise, A would either need to only offer 2.0 (and only > send 2.0), even if it has an HD camera and the destination is > an HD room conference system that can display level 5.0. > > You can't set max-fs lower than the min for the level > offered, nor max-mbps, so you can't limit the received > bitstream in that manner. I don't understand this. BR,YK > In theory you might be able to > limit the received bitstream crudely via b=AS:NN, but that's > up to the sender to notice, comply with, and even then it > doesn't mean they won't send "too large" a framesize at a > lower framerate or higher quantization. > > -- > Randell Jesup, Worldgate (developers of the Ojo videophone), > ex-Amiga OS team rjesup@wgate.com "The fetters imposed on > liberty at home have ever been forged out of the weapons > provided for defence against real, pretended, or imaginary > dangers from abroad." > - James Madison, 4th US president (1751-1836) > > From root@core3.amsl.com Mon May 18 16:30:02 2009 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 482C93A68E1; Mon, 18 May 2009 16:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090518233002.482C93A68E1@core3.amsl.com> Date: Mon, 18 May 2009 16:30:02 -0700 (PDT) Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-atrac-family-24.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 23:30:02 -0000 --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 Adaptive TRansform Acoustic Coding (ATRAC) Family Author(s) : J. Matsumoto, M. Hatanaka Filename : draft-ietf-avt-rtp-atrac-family-24.txt Pages : 35 Date : 2009-5-18 This document describes an RTP payload format for efficient and flexible transporting of audio data encoded with the Adaptive TRansform Audio Coding (ATRAC) family of codecs. Recent enhancements to the ATRAC family of codecs support high quality audio coding with multiple channels. The RTP payload format as presented in this document also includes support for data fragmentation, elementary redundancy measures, and a variation on scalable streaming. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-atrac-family-24.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-avt-rtp-atrac-family-24.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-5-18162340.I-D@ietf.org> --NextPart-- From rjesup@wgate.com Tue May 19 07:56:18 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89FA13A6A93 for ; Tue, 19 May 2009 07:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9QeetQ9A8dDp for ; Tue, 19 May 2009 07:56:17 -0700 (PDT) Received: from exchange1.wgate.com (pr-66-150-46-254.wgate.com [66.150.46.254]) by core3.amsl.com (Postfix) with ESMTP id 365DB3A6AEF for ; Tue, 19 May 2009 07:56:17 -0700 (PDT) Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 May 2009 10:57:53 -0400 To: Ye-Kui Wang References: <04CAD96D4C5A3D48B1919248A8FE0D540943CDB9@xmb-sjc-215.amer.cisco.com> <2713212F2F334A15AB3DB03E1BB45156@china.huawei.com> <4A092C12.8080704@rogers.com> <5E07A2E74C0749B7A84371EE422E90C6@china.huawei.com> <545DD1B15C9A42F0B1729CC02FFC6348@china.huawei.com> <2068ACFCE9FA4013865E833F38057DDB@china.huawei.com> From: Randell Jesup Date: Tue, 19 May 2009 10:57:57 -0400 In-Reply-To: <2068ACFCE9FA4013865E833F38057DDB@china.huawei.com> (Ye-Kui Wang's message of "Mon\, 18 May 2009 16\:49\:56 -0400") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 19 May 2009 14:57:53.0367 (UTC) FILETIME=[2FB02E70:01C9D892] Cc: ron.even.tlv@gmail.com, 'Tom Taylor' , avt@ietf.org Subject: Re: [AVT] Q for 3984bis-06 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Randell Jesup List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 14:56:18 -0000 Ye-Kui Wang writes: >> How about this (may need a little wordsmithing): >> >> Level upgrade >> >> An offerer who wishes to allow level-upgrade in the answer >> can include >> "max-level=XX" in the fmtp line (XX is the level in hex, >> as it is in the >> middle of profile-level-id). An answerer may not increase >> the level in >> the response unless the offerer included max-level, and >> may not increase >> the level beyond XX. Other receive fmtp parameters such >> max-fs, etc >> shall apply to all levels and SHOULD not be lower than the minimum >> values required by the level specified in max-level. >> > >What is the semantics of max-level? Would the semantics of profile-level-id >change? max-level is an offerer-only parameter, since it's used by the receiver to generate an answer. It does not change the semantics of profile-level-id (beyond that an answer can use a higher level). >> Here's the relevant case: Assume this is a a device with a >> fixed LCD size, or configured to play in a small window on a >> larger display. >> ------------------------ >> Assume the video device A is only reasonably able to decode >> level 2.0, due to display limitations (QCIF LCD), but can >> encode up to level 3.1. > >Decoding is different and typically decoupled from display. For example, a >mobile device may be equipped with HD recording and decoding capability, but >it needs an external HD display (e.g. a TV) to really display HD. However, >in the absence of an HD display, the device can still still decode what it >recorded but just display it in a small screen. In your example, does the >video device has the capability to decoded up to level 3.1 at all? The video device may have the *capability* to decode level 3.1 (in terms of raw horsepower), but it may not have the capability to both decode and scale it down, and more importantly it may not want to use up the bandwidth and horsepower (at the sender and on the network, and/or it's own battery power) to receive HD when it can only display a much smaller resolution. Think of a battery-powered device w/ 802.11. Why spend the bandwidth on the air to receive HD, and the battery power to decode and scale HD, when you're displaying 640x480 (or lower)? You still may want to send HD if you're calling into an HD conference room or HD-capable endpoint. Also, in a multi-party conference situation, the conference server will want to minimize bits sent and horsepower for encoding streams, so this may be a win. On a more general level, what was the purpose in not allowing upgrade in the first place? I think it wasn't explicit; originally neither downgrade nor upgrade were allowed, and downgrade was dealt with first because there are obvious and more-common uses for downgrade. This should have *no* impact on existing implementations; you can safely ignore max-level when making an answer. >> B is capable of both decoding and encoding level 3.1. >> A would quote a level of 2.0 in its offer, including >> max-level=1F B would respond with level 3.1 in the answer A >> would send to B video stream at level 3.1 B would send level >> 2.0 to A since A can only decode up to level 2.0 >> >> Otherwise, A would either need to only offer 2.0 (and only >> send 2.0), even if it has an HD camera and the destination is >> an HD room conference system that can display level 5.0. >> >> You can't set max-fs lower than the min for the level >> offered, nor max-mbps, so you can't limit the received >> bitstream in that manner. > >I don't understand this. If you offer level 2.1, you are not allowed to use max-fs/etc to restrict the received bitstream to a lower framesize/etc than level 2.1 supports. You can only increase the framesize/etc over the level offered: The value of max-fs MUST be greater than or equal to the value of MaxFS for the level given in Table A-1 of [1]. So you can't say "I support level 2.2 but I only want to receive a framesize of CIF (the max size in level 2.0)". Level 2.2 would allow receiving CIF at ~50fps; if you offer level 2.0 instead, the answerer can't send you anything beyond 30fps. But you can't offer 2.2 without allowing the answerer to send you 4CIF at 12fps, which you would just have to scale down to CIF anyways. This is a real-world case; devices often have more encode horsepower (and camera resolution) than they can actually display when receiving, and they talk to other devices that *can* display that extra resolution.. -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com "The fetters imposed on liberty at home have ever been forged out of the weapons provided for defence against real, pretended, or imaginary dangers from abroad." - James Madison, 4th US president (1751-1836) From jonathan@vidyo.com Tue May 19 08:50:08 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D2703A6AB7 for ; Tue, 19 May 2009 08:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.419 X-Spam-Level: X-Spam-Status: No, score=-3.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-ArQHHpHzQi for ; Tue, 19 May 2009 08:50:04 -0700 (PDT) Received: from mx1.myoutlookonline.com (mx1.myoutlookonline.com [64.95.72.238]) by core3.amsl.com (Postfix) with ESMTP id C38123A6EE4 for ; Tue, 19 May 2009 08:50:03 -0700 (PDT) Received: from be150.mail.lan ([10.110.20.150]) by mx1.myoutlookonline.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 May 2009 11:51:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 19 May 2009 11:51:39 -0400 Message-ID: <6B55710E7F51AD4B93F336052113B85F93D3D2@be150.mail.lan> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] Q for 3984bis-06 Thread-Index: AcnYl0D5TuQ7LKnfQP+jvuxjy0oZOwAAEvhw References: <04CAD96D4C5A3D48B1919248A8FE0D540943CDB9@xmb-sjc-215.amer.cisco.com><2713212F2F334A15AB3DB03E1BB45156@china.huawei.com><4A092C12.8080704@rogers.com><5E07A2E74C0749B7A84371EE422E90C6@china.huawei.com><545DD1B15C9A42F0B1729CC02FFC6348@china.huawei.com><2068ACFCE9FA4013865E833F38057DDB@china.huawei.com> From: "Jonathan Lennox" To: "Randell Jesup" , "Ye-Kui Wang" X-OriginalArrivalTime: 19 May 2009 15:51:39.0853 (UTC) FILETIME=[B2D2DFD0:01C9D899] Cc: ron.even.tlv@gmail.com, Tom Taylor , avt@ietf.org Subject: Re: [AVT] Q for 3984bis-06 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 15:50:08 -0000 Why is max-level (with a value) needed, as opposed to something like level-upgrade-allowed? Remember the level sent by a receiver is still only an upper bound on what the transmitter is allowed to send. Architecturally, I think it would be cleanest if H.264's non sprop-* parameters all have SDP's standard receive-side semantics, rather than offer/answer semantics. --=20 Jonathan Lennox Vidyo, Inc jonathan@vidyo.com > -----Original Message----- > From: Randell Jesup [mailto:rjesup@wgate.com] > Sent: Tuesday, May 19, 2009 10:58 AM > To: Ye-Kui Wang > Cc: ron.even.tlv@gmail.com; 'Tom Taylor'; avt@ietf.org > Subject: Re: [AVT] Q for 3984bis-06 >=20 > Ye-Kui Wang writes: > >> How about this (may need a little wordsmithing): > >> > >> Level upgrade > >> > >> An offerer who wishes to allow level-upgrade in the answer > >> can include > >> "max-level=3DXX" in the fmtp line (XX is the level in hex, > >> as it is in the > >> middle of profile-level-id). An answerer may not increase > >> the level in > >> the response unless the offerer included max-level, and > >> may not increase > >> the level beyond XX. Other receive fmtp parameters such > >> max-fs, etc > >> shall apply to all levels and SHOULD not be lower than the > minimum > >> values required by the level specified in max-level. > >> > > > >What is the semantics of max-level? Would the semantics of profile- > level-id > >change? >=20 > max-level is an offerer-only parameter, since it's used by the receiver > to > generate an answer. It does not change the semantics of profile-level- > id > (beyond that an answer can use a higher level). >=20 > >> Here's the relevant case: Assume this is a a device with a > >> fixed LCD size, or configured to play in a small window on a > >> larger display. > >> ------------------------ > >> Assume the video device A is only reasonably able to decode > >> level 2.0, due to display limitations (QCIF LCD), but can > >> encode up to level 3.1. > > > >Decoding is different and typically decoupled from display. For > example, a > >mobile device may be equipped with HD recording and decoding > capability, but > >it needs an external HD display (e.g. a TV) to really display HD. > However, > >in the absence of an HD display, the device can still still decode > what it > >recorded but just display it in a small screen. In your example, does > the > >video device has the capability to decoded up to level 3.1 at all? >=20 > The video device may have the *capability* to decode level 3.1 (in > terms of > raw horsepower), but it may not have the capability to both decode and > scale > it down, and more importantly it may not want to use up the bandwidth > and > horsepower (at the sender and on the network, and/or it's own battery > power) to receive HD when it can only display a much smaller > resolution. >=20 > Think of a battery-powered device w/ 802.11. Why spend the bandwidth > on > the air to receive HD, and the battery power to decode and scale HD, > when > you're displaying 640x480 (or lower)? You still may want to send HD if > you're calling into an HD conference room or HD-capable endpoint. > Also, in > a multi-party conference situation, the conference server will want to > minimize bits sent and horsepower for encoding streams, so this may be > a > win. >=20 > On a more general level, what was the purpose in not allowing upgrade > in > the first place? I think it wasn't explicit; originally neither > downgrade > nor upgrade were allowed, and downgrade was dealt with first because > there > are obvious and more-common uses for downgrade. >=20 > This should have *no* impact on existing implementations; you can > safely > ignore max-level when making an answer. >=20 > >> B is capable of both decoding and encoding level 3.1. > >> A would quote a level of 2.0 in its offer, including > >> max-level=3D1F B would respond with level 3.1 in the answer A > >> would send to B video stream at level 3.1 B would send level > >> 2.0 to A since A can only decode up to level 2.0 > >> > >> Otherwise, A would either need to only offer 2.0 (and only > >> send 2.0), even if it has an HD camera and the destination is > >> an HD room conference system that can display level 5.0. > >> > >> You can't set max-fs lower than the min for the level > >> offered, nor max-mbps, so you can't limit the received > >> bitstream in that manner. > > > >I don't understand this. >=20 > If you offer level 2.1, you are not allowed to use max-fs/etc to > restrict > the received bitstream to a lower framesize/etc than level 2.1 > supports. > You can only increase the framesize/etc over the level offered: >=20 > The value of max-fs MUST be greater than or equal to the value of > MaxFS > for the level given in Table A-1 of [1]. >=20 > So you can't say "I support level 2.2 but I only want to receive a > framesize of CIF (the max size in level 2.0)". Level 2.2 would allow > receiving CIF at ~50fps; if you offer level 2.0 instead, the answerer > can't > send you anything beyond 30fps. But you can't offer 2.2 without > allowing > the answerer to send you 4CIF at 12fps, which you would just have to > scale > down to CIF anyways. >=20 > This is a real-world case; devices often have more encode horsepower > (and > camera resolution) than they can actually display when receiving, and > they > talk to other devices that *can* display that extra resolution.. >=20 > -- > Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga > OS team > rjesup@wgate.com > "The fetters imposed on liberty at home have ever been forged out of > the weapons > provided for defence against real, pretended, or imaginary dangers from > abroad." > - James Madison, 4th US president (1751-1836) >=20 > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From stephen.botzko@gmail.com Tue May 19 08:51:45 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 221573A6F55 for ; Tue, 19 May 2009 08:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vy-QGJGx8rnD for ; Tue, 19 May 2009 08:51:43 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id B257A3A6AB7 for ; Tue, 19 May 2009 08:51:42 -0700 (PDT) Received: by fxm2 with SMTP id 2so3964162fxm.37 for ; Tue, 19 May 2009 08:53:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=JnSJd21QuyfNa7ou5sfgZ5QV5fNohHn05+1yt18fytU=; b=r0FFV1Dg0FJ/wWdxAjzrW6dOEufDbR5/9aubHYFqIk3fmKPzVvaQqUJFJGPcdAhnZY 4DS4yvaS5pQlDyb9uDW5YpyKYR02ipcRlg6iI8Umg3PGf8Tram4VPGQ82GtdYWqRLLhv TvYtNOCnpxBDOHMRsE9xB5dslxc8PAXWXBha0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Lvik0b9Df3f0E20vhNqz+aMrGz26rlFHDQNPAXsVULhxlH4lWE5m4ZzaXjgtHwm+DP r9ELLcY8fv+D2dxcQc5eqbzJSSQXGfXSC+9vV6Ruf+qSHwjgcAUymeUAGEXmHF+ts2HG KCXI/+TxlsMJvTZf1zT+e4iwqicZABaj0HyVw= MIME-Version: 1.0 Received: by 10.223.105.16 with SMTP id r16mr193659fao.24.1242748396623; Tue, 19 May 2009 08:53:16 -0700 (PDT) In-Reply-To: References: <04CAD96D4C5A3D48B1919248A8FE0D540943CDB9@xmb-sjc-215.amer.cisco.com> <2713212F2F334A15AB3DB03E1BB45156@china.huawei.com> <4A092C12.8080704@rogers.com> <5E07A2E74C0749B7A84371EE422E90C6@china.huawei.com> <545DD1B15C9A42F0B1729CC02FFC6348@china.huawei.com> <2068ACFCE9FA4013865E833F38057DDB@china.huawei.com> Date: Tue, 19 May 2009 11:53:16 -0400 Message-ID: <6e9223710905190853p133b630cud234027c753916ed@mail.gmail.com> From: stephen botzko To: Randell Jesup Content-Type: multipart/alternative; boundary=001636c5b52bb9e4c0046a45e891 Cc: ron.even.tlv@gmail.com, Tom Taylor , avt@ietf.org Subject: Re: [AVT] Q for 3984bis-06 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 15:51:45 -0000 --001636c5b52bb9e4c0046a45e891 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit >>> This is a real-world case; devices often have more encode horsepower (and camera resolution) than they can actually display when receiving, and they talk to other devices that *can* display that extra resolution.. >>> In our experience, the reverse situation is what actually happens - PCs for instance frequently can decode and display HD images, but are often limited to an SD webcam. Can you name a couple of specific real devices that have these HD cameras+encoders and the limited decoders? Steve On Tue, May 19, 2009 at 10:57 AM, Randell Jesup wrote: > Ye-Kui Wang writes: > >> How about this (may need a little wordsmithing): > >> > >> Level upgrade > >> > >> An offerer who wishes to allow level-upgrade in the answer > >> can include > >> "max-level=XX" in the fmtp line (XX is the level in hex, > >> as it is in the > >> middle of profile-level-id). An answerer may not increase > >> the level in > >> the response unless the offerer included max-level, and > >> may not increase > >> the level beyond XX. Other receive fmtp parameters such > >> max-fs, etc > >> shall apply to all levels and SHOULD not be lower than the minimum > >> values required by the level specified in max-level. > >> > > > >What is the semantics of max-level? Would the semantics of > profile-level-id > >change? > > max-level is an offerer-only parameter, since it's used by the receiver to > generate an answer. It does not change the semantics of profile-level-id > (beyond that an answer can use a higher level). > > >> Here's the relevant case: Assume this is a a device with a > >> fixed LCD size, or configured to play in a small window on a > >> larger display. > >> ------------------------ > >> Assume the video device A is only reasonably able to decode > >> level 2.0, due to display limitations (QCIF LCD), but can > >> encode up to level 3.1. > > > >Decoding is different and typically decoupled from display. For example, a > >mobile device may be equipped with HD recording and decoding capability, > but > >it needs an external HD display (e.g. a TV) to really display HD. However, > >in the absence of an HD display, the device can still still decode what it > >recorded but just display it in a small screen. In your example, does the > >video device has the capability to decoded up to level 3.1 at all? > > The video device may have the *capability* to decode level 3.1 (in terms of > raw horsepower), but it may not have the capability to both decode and > scale > it down, and more importantly it may not want to use up the bandwidth and > horsepower (at the sender and on the network, and/or it's own battery > power) to receive HD when it can only display a much smaller resolution. > > Think of a battery-powered device w/ 802.11. Why spend the bandwidth on > the air to receive HD, and the battery power to decode and scale HD, when > you're displaying 640x480 (or lower)? You still may want to send HD if > you're calling into an HD conference room or HD-capable endpoint. Also, in > a multi-party conference situation, the conference server will want to > minimize bits sent and horsepower for encoding streams, so this may be a > win. > > On a more general level, what was the purpose in not allowing upgrade in > the first place? I think it wasn't explicit; originally neither downgrade > nor upgrade were allowed, and downgrade was dealt with first because there > are obvious and more-common uses for downgrade. > > This should have *no* impact on existing implementations; you can safely > ignore max-level when making an answer. > > >> B is capable of both decoding and encoding level 3.1. > >> A would quote a level of 2.0 in its offer, including > >> max-level=1F B would respond with level 3.1 in the answer A > >> would send to B video stream at level 3.1 B would send level > >> 2.0 to A since A can only decode up to level 2.0 > >> > >> Otherwise, A would either need to only offer 2.0 (and only > >> send 2.0), even if it has an HD camera and the destination is > >> an HD room conference system that can display level 5.0. > >> > >> You can't set max-fs lower than the min for the level > >> offered, nor max-mbps, so you can't limit the received > >> bitstream in that manner. > > > >I don't understand this. > > If you offer level 2.1, you are not allowed to use max-fs/etc to restrict > the received bitstream to a lower framesize/etc than level 2.1 supports. > You can only increase the framesize/etc over the level offered: > > The value of max-fs MUST be greater than or equal to the value of MaxFS > for the level given in Table A-1 of [1]. > > So you can't say "I support level 2.2 but I only want to receive a > framesize of CIF (the max size in level 2.0)". Level 2.2 would allow > receiving CIF at ~50fps; if you offer level 2.0 instead, the answerer can't > send you anything beyond 30fps. But you can't offer 2.2 without allowing > the answerer to send you 4CIF at 12fps, which you would just have to scale > down to CIF anyways. > > This is a real-world case; devices often have more encode horsepower (and > camera resolution) than they can actually display when receiving, and they > talk to other devices that *can* display that extra resolution.. > > -- > Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS > team > rjesup@wgate.com > "The fetters imposed on liberty at home have ever been forged out of the > weapons > provided for defence against real, pretended, or imaginary dangers from > abroad." > - James Madison, 4th US president (1751-1836) > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > --001636c5b52bb9e4c0046a45e891 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >>>
This is a real-world case; devices often have more encode h= orsepower (and
camera resolution) than they can actually display when receiving, and they<= br> talk to other devices that *can* display that extra resolution..
>>= ;>

In our experience, the reverse situation is what actually happ= ens - PCs for instance frequently can decode and display HD images, but are= often limited to an SD webcam.
Can you name a couple of specific real devices that have these HD cameras+e= ncoders and the limited decoders?

Steve

On Tue, May 19, 2009 at 10:57 AM, Randell Jesup <= ;rjesup@wgate.com> wrote:=
Ye-Kui Wang <yekuiwang@huawei.c= om> writes:
>> How about this (may need a little wordsmit= hing):
>>
>> =A0 =A0Level upgrade
>>
>> =A0 =A0An offerer who wishes to allow level-upgrade in the answer<= br> >> can include
>> =A0 =A0"max-level=3DXX" in the fmtp line (XX is the leve= l in hex,
>> as it is in the
>> =A0 =A0middle of profile-level-id). =A0An answerer may not increas= e
>> the level in
>> =A0 =A0the response unless the offerer included max-level, and
>> may not increase
>> =A0 =A0the level beyond XX. =A0Other receive fmtp parameters such<= br> >> max-fs, etc
>> =A0 =A0shall apply to all levels and SHOULD not be lower than the = minimum
>> =A0 =A0values required by the level specified in max-level.
>>
>
>What is the semantics of max-level? Would the semantics of profile-leve= l-id
>change?

max-level is an offerer-only parameter, since it's used by the re= ceiver to
generate an answer. =A0It does not change the semantics of profile-level-id=
(beyond that an answer can use a higher level).

>> Here's the relevant case: Assume this is a a device with a
>> fixed LCD size, or configured to play in a small window on a
>> larger display.
>> ------------------------
>> Assume the video device A is only reasonably able to decode
>> level 2.0, due to display limitations (QCIF LCD), but can
>> encode up to level 3.1.
>
>Decoding is different and typically decoupled from display. For example= , a
>mobile device may be equipped with HD recording and decoding capability= , but
>it needs an external HD display (e.g. a TV) to really display HD. Howev= er,
>in the absence of an HD display, the device can still still decode what= it
>recorded but just display it in a small screen. In your example, does t= he
>video device has the capability to decoded up to level 3.1 at all?

The video device may have the *capability* to decode level 3.1 (in te= rms of
raw horsepower), but it may not have the capability to both decode and scal= e
it down, and more importantly it may not want to use up the bandwidth and horsepower (at the sender and on the network, and/or it's own battery power) to receive HD when it can only display a much smaller resolution.
Think of a battery-powered device w/ 802.11. =A0Why spend the bandwidth on<= br> the air to receive HD, and the battery power to decode and scale HD, when you're displaying 640x480 (or lower)? =A0You still may want to send HD = if
you're calling into an HD conference room or HD-capable endpoint. =A0Al= so, in
a multi-party conference situation, the conference server will want to
minimize bits sent and horsepower for encoding streams, so this may be a win.

On a more general level, what was the purpose in not allowing upgrade in the first place? =A0I think it wasn't explicit; originally neither down= grade
nor upgrade were allowed, and downgrade was dealt with first because there<= br> are obvious and more-common uses for downgrade.

This should have *no* impact on existing implementations; you can safely ignore max-level when making an answer.

>> B is capable of both decoding and encoding level 3.1.
>> A would quote a level of 2.0 in its offer, including
>> max-level=3D1F B would respond with level 3.1 in the answer A
>> would send to B video stream at level 3.1 B would send level
>> 2.0 to A since A can only decode up to level 2.0
>>
>> Otherwise, A would either need to only offer 2.0 (and only
>> send 2.0), even if it has an HD camera and the destination is
>> an HD room conference system that can display level 5.0.
>>
>> You can't set max-fs lower than the min for the level
>> offered, nor max-mbps, so you can't limit the received
>> bitstream in that manner.
>
>I don't understand this.

If you offer level 2.1, you are not allowed to use max-fs/etc to rest= rict
the received bitstream to a lower framesize/etc than level 2.1 supports. You can only increase the framesize/etc over the level offered:

=A0 The value of max-fs MUST be greater than or equal to the value of MaxF= S
=A0 for the level given in Table A-1 of [1].

So you can't say "I support level 2.2 but I only want to receive a=
framesize of CIF (the max size in level 2.0)". =A0Level 2.2 would allo= w
receiving CIF at ~50fps; if you offer level 2.0 instead, the answerer can&#= 39;t
send you anything beyond 30fps. =A0But you can't offer 2.2 without allo= wing
the answerer to send you 4CIF at 12fps, which you would just have to scale<= br> down to CIF anyways.

This is a real-world case; devices often have more encode horsepower (and camera resolution) than they can actually display when receiving, and they<= br> talk to other devices that *can* display that extra resolution..

--
Randell Jesup, Worldgate (develope= rs of the Ojo videophone), ex-Amiga OS team
rjesup@wgate.com
"The fetters imposed on liberty at home have ever been forged out of t= he weapons
provided for defence against real, pretended, or imaginary dangers from abr= oad."
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- James Madison, 4th US president (1751-183= 6)

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/avt

--001636c5b52bb9e4c0046a45e891-- From yekuiwang@huawei.com Tue May 19 09:14:15 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD97E3A6A00 for ; Tue, 19 May 2009 09:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVXhl45ckLuC for ; Tue, 19 May 2009 09:14:14 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 829783A6832 for ; Tue, 19 May 2009 09:14:14 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJW00A5GFUDIS@usaga02-in.huawei.com> for avt@ietf.org; Tue, 19 May 2009 09:15:50 -0700 (PDT) Received: from W90946 ([10.193.125.102]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJW0025DFU8BV@usaga02-in.huawei.com> for avt@ietf.org; Tue, 19 May 2009 09:15:49 -0700 (PDT) Date: Tue, 19 May 2009 12:15:43 -0400 From: Ye-Kui Wang In-reply-to: <6B55710E7F51AD4B93F336052113B85F93D3D2@be150.mail.lan> To: 'Jonathan Lennox' , 'Randell Jesup' Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcnYl0D5TuQ7LKnfQP+jvuxjy0oZOwAAEvhwAAEx9IA= References: <04CAD96D4C5A3D48B1919248A8FE0D540943CDB9@xmb-sjc-215.amer.cisco.com> <2713212F2F334A15AB3DB03E1BB45156@china.huawei.com> <4A092C12.8080704@rogers.com> <5E07A2E74C0749B7A84371EE422E90C6@china.huawei.com> <545DD1B15C9A42F0B1729CC02FFC6348@china.huawei.com> <2068ACFCE9FA4013865E833F38057DDB@china.huawei.com> <6B55710E7F51AD4B93F336052113B85F93D3D2@be150.mail.lan> Cc: ron.even.tlv@gmail.com, 'Tom Taylor' , avt@ietf.org Subject: Re: [AVT] Q for 3984bis-06 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 16:14:15 -0000 > Architecturally, I think it would be cleanest if H.264's non > sprop-* parameters all have SDP's standard receive-side > semantics, rather than offer/answer semantics. In that case, sprop-* parameters indicate stream properties, others indicate basically receiving capabilities (I guess this is what you mean by SDP's standard receive-side semantics). If someone wants to indicate sending capabilities, then another group of parameters is needed. Hmm, this way it may work better, but it seems too late to do this now, maybe for future codecs. BR, YK > -----Original Message----- > From: Jonathan Lennox [mailto:jonathan@vidyo.com] > Sent: Tuesday, May 19, 2009 11:52 AM > To: Randell Jesup; Ye-Kui Wang > Cc: ron.even.tlv@gmail.com; Tom Taylor; avt@ietf.org > Subject: RE: [AVT] Q for 3984bis-06 > > Why is max-level (with a value) needed, as opposed to > something like level-upgrade-allowed? Remember the level > sent by a receiver is still only an upper bound on what the > transmitter is allowed to send. > > Architecturally, I think it would be cleanest if H.264's non > sprop-* parameters all have SDP's standard receive-side > semantics, rather than offer/answer semantics. > > -- > Jonathan Lennox > Vidyo, Inc > jonathan@vidyo.com > > > > -----Original Message----- > > From: Randell Jesup [mailto:rjesup@wgate.com] > > Sent: Tuesday, May 19, 2009 10:58 AM > > To: Ye-Kui Wang > > Cc: ron.even.tlv@gmail.com; 'Tom Taylor'; avt@ietf.org > > Subject: Re: [AVT] Q for 3984bis-06 > > > > Ye-Kui Wang writes: > > >> How about this (may need a little wordsmithing): > > >> > > >> Level upgrade > > >> > > >> An offerer who wishes to allow level-upgrade in the answer > > >> can include > > >> "max-level=XX" in the fmtp line (XX is the level in hex, > > >> as it is in the > > >> middle of profile-level-id). An answerer may not increase > > >> the level in > > >> the response unless the offerer included max-level, and > > >> may not increase > > >> the level beyond XX. Other receive fmtp parameters such > > >> max-fs, etc > > >> shall apply to all levels and SHOULD not be lower than the > > minimum > > >> values required by the level specified in max-level. > > >> > > > > > >What is the semantics of max-level? Would the semantics of profile- > > level-id > > >change? > > > > max-level is an offerer-only parameter, since it's used by the > receiver > > to > > generate an answer. It does not change the semantics of > profile-level- > > id > > (beyond that an answer can use a higher level). > > > > >> Here's the relevant case: Assume this is a a device with a > > >> fixed LCD size, or configured to play in a small window on a > > >> larger display. > > >> ------------------------ > > >> Assume the video device A is only reasonably able to decode > > >> level 2.0, due to display limitations (QCIF LCD), but can > > >> encode up to level 3.1. > > > > > >Decoding is different and typically decoupled from display. For > > example, a > > >mobile device may be equipped with HD recording and decoding > > capability, but > > >it needs an external HD display (e.g. a TV) to really display HD. > > However, > > >in the absence of an HD display, the device can still still decode > > what it > > >recorded but just display it in a small screen. In your > example, does > > the > > >video device has the capability to decoded up to level 3.1 at all? > > > > The video device may have the *capability* to decode level 3.1 (in > > terms of > > raw horsepower), but it may not have the capability to both > decode and > > scale > > it down, and more importantly it may not want to use up the > bandwidth > > and > > horsepower (at the sender and on the network, and/or it's > own battery > > power) to receive HD when it can only display a much smaller > > resolution. > > > > Think of a battery-powered device w/ 802.11. Why spend the > bandwidth > > on > > the air to receive HD, and the battery power to decode and scale HD, > > when > > you're displaying 640x480 (or lower)? You still may want to send HD > if > > you're calling into an HD conference room or HD-capable endpoint. > > Also, in > > a multi-party conference situation, the conference server > will want to > > minimize bits sent and horsepower for encoding streams, so > this may be > > a > > win. > > > > On a more general level, what was the purpose in not > allowing upgrade > > in > > the first place? I think it wasn't explicit; originally neither > > downgrade > > nor upgrade were allowed, and downgrade was dealt with first because > > there > > are obvious and more-common uses for downgrade. > > > > This should have *no* impact on existing implementations; you can > > safely > > ignore max-level when making an answer. > > > > >> B is capable of both decoding and encoding level 3.1. > > >> A would quote a level of 2.0 in its offer, including > > >> max-level=1F B would respond with level 3.1 in the answer A > > >> would send to B video stream at level 3.1 B would send level > > >> 2.0 to A since A can only decode up to level 2.0 > > >> > > >> Otherwise, A would either need to only offer 2.0 (and only > > >> send 2.0), even if it has an HD camera and the destination is > > >> an HD room conference system that can display level 5.0. > > >> > > >> You can't set max-fs lower than the min for the level > > >> offered, nor max-mbps, so you can't limit the received > > >> bitstream in that manner. > > > > > >I don't understand this. > > > > If you offer level 2.1, you are not allowed to use max-fs/etc to > > restrict > > the received bitstream to a lower framesize/etc than level 2.1 > > supports. > > You can only increase the framesize/etc over the level offered: > > > > The value of max-fs MUST be greater than or equal to the value of > > MaxFS > > for the level given in Table A-1 of [1]. > > > > So you can't say "I support level 2.2 but I only want to receive a > > framesize of CIF (the max size in level 2.0)". Level 2.2 > would allow > > receiving CIF at ~50fps; if you offer level 2.0 instead, > the answerer > > can't > > send you anything beyond 30fps. But you can't offer 2.2 without > > allowing > > the answerer to send you 4CIF at 12fps, which you would just have to > > scale > > down to CIF anyways. > > > > This is a real-world case; devices often have more encode horsepower > > (and > > camera resolution) than they can actually display when > receiving, and > > they > > talk to other devices that *can* display that extra resolution.. > > > > -- > > Randell Jesup, Worldgate (developers of the Ojo > videophone), ex-Amiga > > OS team > > rjesup@wgate.com > > "The fetters imposed on liberty at home have ever been forged out of > > the weapons > > provided for defence against real, pretended, or imaginary dangers > from > > abroad." > > - James Madison, 4th US president (1751-1836) > > > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > > From rjesup@wgate.com Tue May 19 09:22:30 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C23CD3A6A93 for ; Tue, 19 May 2009 09:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.516 X-Spam-Level: X-Spam-Status: No, score=-1.516 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eE7DTb4ZNJzL for ; Tue, 19 May 2009 09:22:30 -0700 (PDT) Received: from exchange1.wgate.com (pr-66-150-46-254.wgate.com [66.150.46.254]) by core3.amsl.com (Postfix) with ESMTP id C0AE23A688A for ; Tue, 19 May 2009 09:22:29 -0700 (PDT) Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 May 2009 12:24:06 -0400 To: stephen botzko References: <04CAD96D4C5A3D48B1919248A8FE0D540943CDB9@xmb-sjc-215.amer.cisco.com> <2713212F2F334A15AB3DB03E1BB45156@china.huawei.com> <4A092C12.8080704@rogers.com> <5E07A2E74C0749B7A84371EE422E90C6@china.huawei.com> <545DD1B15C9A42F0B1729CC02FFC6348@china.huawei.com> <2068ACFCE9FA4013865E833F38057DDB@china.huawei.com> <6e9223710905190853p133b630cud234027c753916ed@mail.gmail.com> From: Randell Jesup Date: Tue, 19 May 2009 12:24:09 -0400 In-Reply-To: <6e9223710905190853p133b630cud234027c753916ed@mail.gmail.com> (stephen botzko's message of "Tue\, 19 May 2009 11\:53\:16 -0400") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 19 May 2009 16:24:06.0148 (UTC) FILETIME=[3AE7EC40:01C9D89E] Cc: ron.even.tlv@gmail.com, Tom Taylor , avt@ietf.org Subject: Re: [AVT] Q for 3984bis-06 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Randell Jesup List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 16:22:30 -0000 stephen botzko writes: >>>> >This is a real-world case; devices often have more encode horsepower (and >camera resolution) than they can actually display when receiving, and they >talk to other devices that *can* display that extra resolution.. >>>> > >In our experience, the reverse situation is what actually happens - PCs for >instance frequently can decode and display HD images, but are often limited >to an SD webcam. >Can you name a couple of specific real devices that have these HD >cameras+encoders and the limited decoders? Mostly I'm not talking PC's (I agree with you there, though there are cases where it still may make sense, like when displaying video in a portion of the screen). I'm mostly talking mobile and dedicated devices with built-in LCDs; that would include Smartphones, dedicated videophones, "media" tablets, etc. For example, certain devices have been made with two different LCDs; one ~850x480, the other ~480x234, both with VGA-class cameras. Sending VGA content (or really anything beyond CIF) to the 480x234 display is just a waste of bits. If you wanted to and could negotiate it properly, though, you could send higher framerate CIF to that device, while it sends VGA at a lower framerate to a device that can show it. As for the comment about max-level=NN versus level-upgrade-allowed: I'd originally thought level-upgrade-allowed made the most sense, and in fact probably it does - let the answer respond with the highest level they can receive, and the offerer can send at whatever level they support. That's even easier to describe: level-upgrade-allowed=0 or 1: If the offer sets level-upgrade-allowed to 1, then an answer may include any level above the offered level in profile-level-id. The offerer may send at any level up to the level in the answer, and and answerer can send levels only up to the level in the offer. If this is not present or is set to 0, then the answer MUST NOT respond with a level greater than the level in profile-level-id. Note that this only allows the level to be increased in the answer; the profile and constraints are not allowed to change. -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com "The fetters imposed on liberty at home have ever been forged out of the weapons provided for defence against real, pretended, or imaginary dangers from abroad." - James Madison, 4th US president (1751-1836) From wwwrun@core3.amsl.com Tue May 19 10:18:15 2009 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 795DC3A698F; Tue, 19 May 2009 10:18:15 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090519171815.795DC3A698F@core3.amsl.com> Date: Tue, 19 May 2009 10:18:15 -0700 (PDT) Cc: avt@ietf.org Subject: [AVT] Last Call: draft-ietf-avt-rtp-mps (RTP Payload Format for Elementary Streams with MPEG Surround multi- channel audio) to Proposed Standard X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 17:18:15 -0000 The IESG has received a request from the Audio/Video Transport WG (avt) to consider the following document: - 'RTP Payload Format for Elementary Streams with MPEG Surround multi- channel audio ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-06-02. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-mps-02.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17494&rfc_flag=0 From yekuiwang@huawei.com Tue May 19 10:56:16 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E2903A68FE for ; Tue, 19 May 2009 10:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.21 X-Spam-Level: X-Spam-Status: No, score=-2.21 tagged_above=-999 required=5 tests=[AWL=0.389, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0Ka3iOj66Ch for ; Tue, 19 May 2009 10:56:14 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 391883A6F5E for ; Tue, 19 May 2009 10:55:54 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJW0081OKJTX1@usaga02-in.huawei.com> for avt@ietf.org; Tue, 19 May 2009 10:57:30 -0700 (PDT) Received: from W90946 ([10.193.125.102]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJW002AEKJOBV@usaga02-in.huawei.com> for avt@ietf.org; Tue, 19 May 2009 10:57:29 -0700 (PDT) Date: Tue, 19 May 2009 13:57:24 -0400 From: Ye-Kui Wang In-reply-to: To: 'Randell Jesup' , 'stephen botzko' Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcnYnmGPdEyCPS6kStmS4PX354YjzQACnI3Q References: <04CAD96D4C5A3D48B1919248A8FE0D540943CDB9@xmb-sjc-215.amer.cisco.com> <2713212F2F334A15AB3DB03E1BB45156@china.huawei.com> <4A092C12.8080704@rogers.com> <5E07A2E74C0749B7A84371EE422E90C6@china.huawei.com> <545DD1B15C9A42F0B1729CC02FFC6348@china.huawei.com> <2068ACFCE9FA4013865E833F38057DDB@china.huawei.com> <6e9223710905190853p133b630cud234027c753916ed@mail.gmail.com> Cc: ron.even.tlv@gmail.com, 'Tom Taylor' , avt@ietf.org Subject: Re: [AVT] Q for 3984bis-06 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 17:56:16 -0000 I see immediately the following problems with the semantics, without yet considering all possible cases. > level-upgrade-allowed=0 or 1: > If the offer sets level-upgrade-allowed to 1, then > an answer may > include any level above the offered level in > profile-level-id. Only when the offer and the answer both include level-upgrade-allowed equal to 1, it is allowed for the answer to include a higher level. In all other cases, level upgrade is not allowed. > The offerer may send at any level up to the level in > the answer, This does not work with the current semantics of profile-level-id (part of which copied below for convenience). "The profile-level-id parameter indicates the default sub-profile, i.e. the subset of coding tools that may have been used to generate the stream or that the receiver supports, and the default level of the stream or the receiver supports." According to the current semantics of profile-level-id, the level part of the profile-level-id in the offer limits what the offerer can receive. > and and answerer can send levels only up to the level in the > offer. What if the answerer has a receiving capability between the two levels in the offer and the answer or lower than the level in the offer, and it wants the receiving capability expressed? BR, YK > If this is not present or is set to 0, then > the answer > MUST NOT respond with a level greater than the level in > profile-level-id. > > Note that this only allows the level to be increased in the > answer; the profile and constraints are not allowed > to change. > > -----Original Message----- > From: Randell Jesup [mailto:rjesup@wgate.com] > Sent: Tuesday, May 19, 2009 12:24 PM > To: stephen botzko > Cc: Ye-Kui Wang; ron.even.tlv@gmail.com; Tom Taylor; avt@ietf.org > Subject: Re: [AVT] Q for 3984bis-06 > > stephen botzko writes: > >>>> > >This is a real-world case; devices often have more encode horsepower > >(and camera resolution) than they can actually display when > receiving, > >and they talk to other devices that *can* display that extra > resolution.. > >>>> > > > >In our experience, the reverse situation is what actually > happens - PCs > >for instance frequently can decode and display HD images, > but are often > >limited to an SD webcam. > >Can you name a couple of specific real devices that have these HD > >cameras+encoders and the limited decoders? > > Mostly I'm not talking PC's (I agree with you there, though > there are cases where it still may make sense, like when > displaying video in a portion of the screen). I'm mostly > talking mobile and dedicated devices with built-in LCDs; that > would include Smartphones, dedicated videophones, "media" > tablets, etc. > > For example, certain devices have been made with two > different LCDs; one ~850x480, the other ~480x234, both with > VGA-class cameras. Sending VGA content (or really anything > beyond CIF) to the 480x234 display is just a waste of bits. > If you wanted to and could negotiate it properly, though, you > could send higher framerate CIF to that device, while it > sends VGA at a lower framerate to a device that can show it. > > > As for the comment about max-level=NN versus > level-upgrade-allowed: I'd originally thought > level-upgrade-allowed made the most sense, and in fact > probably it does - let the answer respond with the highest > level they can receive, and the offerer can send at whatever > level they support. > > That's even easier to describe: > > level-upgrade-allowed=0 or 1: > If the offer sets level-upgrade-allowed to 1, then > an answer may > include any level above the offered level in > profile-level-id. > The offerer may send at any level up to the level in > the answer, > and and answerer can send levels only up to the level in the > offer. If this is not present or is set to 0, then > the answer > MUST NOT respond with a level greater than the level in > profile-level-id. > > Note that this only allows the level to be increased in the > answer; the profile and constraints are not allowed > to change. > > -- > Randell Jesup, Worldgate (developers of the Ojo videophone), > ex-Amiga OS team rjesup@wgate.com "The fetters imposed on > liberty at home have ever been forged out of the weapons > provided for defence against real, pretended, or imaginary > dangers from abroad." > - James Madison, 4th US president (1751-1836) > > From rjesup@wgate.com Tue May 19 11:58:37 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11AAA3A6C0B for ; Tue, 19 May 2009 11:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.53 X-Spam-Level: X-Spam-Status: No, score=-1.53 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LT3W6VNEx8+9 for ; Tue, 19 May 2009 11:58:36 -0700 (PDT) Received: from exchange1.wgate.com (pr-66-150-46-254.wgate.com [66.150.46.254]) by core3.amsl.com (Postfix) with ESMTP id CD37F3A6A93 for ; Tue, 19 May 2009 11:58:35 -0700 (PDT) Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 May 2009 15:00:11 -0400 To: Ye-Kui Wang References: <04CAD96D4C5A3D48B1919248A8FE0D540943CDB9@xmb-sjc-215.amer.cisco.com> <2713212F2F334A15AB3DB03E1BB45156@china.huawei.com> <4A092C12.8080704@rogers.com> <5E07A2E74C0749B7A84371EE422E90C6@china.huawei.com> <545DD1B15C9A42F0B1729CC02FFC6348@china.huawei.com> <2068ACFCE9FA4013865E833F38057DDB@china.huawei.com> <6e9223710905190853p133b630cud234027c753916ed@mail.gmail.com> From: Randell Jesup Date: Tue, 19 May 2009 15:00:15 -0400 In-Reply-To: (Ye-Kui Wang's message of "Tue\, 19 May 2009 13\:57\:24 -0400") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 19 May 2009 19:00:11.0273 (UTC) FILETIME=[08F49790:01C9D8B4] Cc: ron.even.tlv@gmail.com, 'stephen botzko' , avt@ietf.org, 'Tom Taylor' Subject: Re: [AVT] Q for 3984bis-06 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Randell Jesup List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 18:58:37 -0000 Ye-Kui Wang writes: >I see immediately the following problems with the semantics, without yet >considering all possible cases. > >> level-upgrade-allowed=0 or 1: >> If the offer sets level-upgrade-allowed to 1, then an answer >> may include any level above the offered level in >> profile-level-id. > >Only when the offer and the answer both include level-upgrade-allowed equal >to 1, it is allowed for the answer to include a higher level. In all other >cases, level upgrade is not allowed. Why is level-upgrade-allowed required in the response? The level upgrade is signaled (or not) via the profile-level-id value returned in the answer; there's no need for an additional parameter in the answer. >> The offerer may send at any level up to the level in the >> answer, > >This does not work with the current semantics of profile-level-id (part of >which copied below for convenience). > >"The profile-level-id parameter indicates the default sub-profile, i.e. the >subset of coding tools that may have been used to generate the stream or >that the receiver supports, and the default level of the stream or the >receiver supports." > >According to the current semantics of profile-level-id, the level part of >the profile-level-id in the offer limits what the offerer can receive. Right... That doesn't change; there's no conflict here. The answerer answers with a higher level, but the answerer is still not allowed to *send* a level above that provided in the offer. The answerer may *receive* a stream up to the level they put in the answer. That's the whole point here. >> and and answerer can send levels only up to the level in the >> offer. > >What if the answerer has a receiving capability between the two levels in >the offer and the answer or lower than the level in the offer, and it wants >the receiving capability expressed? Using level-upgrade-allowed=1 (the current proposal) means there is only one level in the offer (profile-level-id). If the answerer wants to downgrade the level in the response, they may do so (as per current), regardless of level-upgrade-allowed. If they want to upgrade it, they can pick whatever level they're willing to receive and respond with that. They will send the level in the offer (or below). Perhaps this table will help: Offer is level "B". I'll use level "A" to indicate a lower level, and "C" for a higher one (A < B < C). I'm assuming the offer includes level-upgrade-allowed=1. Answer level: lower (A) same (B) higher (C) Offerer can send: A B C Answerer can send: A* B B *This could be 'B' if we decide the same asymmetry is allowed for level-downgrade as well, when level-upgrade-allowed=1. (We could rename it level-asymmetry-allowed if we want that ability.) Current behavior, and if there's no level-upgrade-allowed (or it's 0): Answer level: lower (A) same (B) higher (C) Offerer can send: A B Not Allowed Answerer can send: A B Not Allowed >BR, YK > > >> If this is not present or is set to 0, then >> the answer >> MUST NOT respond with a level greater than the level in >> profile-level-id. >> >> Note that this only allows the level to be increased in the >> answer; the profile and constraints are not allowed to change. >> > >> -----Original Message----- >> From: Randell Jesup [mailto:rjesup@wgate.com] >> Sent: Tuesday, May 19, 2009 12:24 PM >> To: stephen botzko >> Cc: Ye-Kui Wang; ron.even.tlv@gmail.com; Tom Taylor; avt@ietf.org >> Subject: Re: [AVT] Q for 3984bis-06 >> >> stephen botzko writes: >> >>>> >> >This is a real-world case; devices often have more encode horsepower >> >(and camera resolution) than they can actually display when >> receiving, >> >and they talk to other devices that *can* display that extra >> resolution.. >> >>>> >> > >> >In our experience, the reverse situation is what actually happens - PCs >> >for instance frequently can decode and display HD images, but are often >> >limited to an SD webcam. Can you name a couple of specific real >> >devices that have these HD cameras+encoders and the limited decoders? >> >> Mostly I'm not talking PC's (I agree with you there, though >> there are cases where it still may make sense, like when >> displaying video in a portion of the screen). I'm mostly >> talking mobile and dedicated devices with built-in LCDs; that >> would include Smartphones, dedicated videophones, "media" >> tablets, etc. >> >> For example, certain devices have been made with two >> different LCDs; one ~850x480, the other ~480x234, both with >> VGA-class cameras. Sending VGA content (or really anything >> beyond CIF) to the 480x234 display is just a waste of bits. >> If you wanted to and could negotiate it properly, though, you >> could send higher framerate CIF to that device, while it >> sends VGA at a lower framerate to a device that can show it. >> >> >> As for the comment about max-level=NN versus >> level-upgrade-allowed: I'd originally thought >> level-upgrade-allowed made the most sense, and in fact >> probably it does - let the answer respond with the highest >> level they can receive, and the offerer can send at whatever >> level they support. >> >> That's even easier to describe: >> >> level-upgrade-allowed=0 or 1: >> If the offer sets level-upgrade-allowed to 1, then an answer >> may include any level above the offered level in >> profile-level-id. The offerer may send at any level up to the >> level in the answer, and and answerer can send levels only up >> to the level in the offer. If this is not present or is set to >> 0, then the answer MUST NOT respond with a level greater than >> the level in profile-level-id. >> >> Note that this only allows the level to be increased in the >> answer; the profile and constraints are not allowed to change. -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com "The fetters imposed on liberty at home have ever been forged out of the weapons provided for defence against real, pretended, or imaginary dangers from abroad." - James Madison, 4th US president (1751-1836) From yekuiwang@huawei.com Tue May 19 13:11:15 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA8B13A6CAB for ; Tue, 19 May 2009 13:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.222 X-Spam-Level: X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[AWL=0.377, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vf7uI0G173Yr for ; Tue, 19 May 2009 13:11:14 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id BB5573A6817 for ; Tue, 19 May 2009 13:10:46 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJW00DE8QSKPM@usaga02-in.huawei.com> for avt@ietf.org; Tue, 19 May 2009 13:12:21 -0700 (PDT) Received: from W90946 ([10.193.125.102]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJW002DWQSFBV@usaga02-in.huawei.com> for avt@ietf.org; Tue, 19 May 2009 13:12:20 -0700 (PDT) Date: Tue, 19 May 2009 16:12:14 -0400 From: Ye-Kui Wang In-reply-to: To: 'Randell Jesup' Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcnYtBCK05Iy2Yo8QueY+U6ZNxgrigABxsSA References: <04CAD96D4C5A3D48B1919248A8FE0D540943CDB9@xmb-sjc-215.amer.cisco.com> <2713212F2F334A15AB3DB03E1BB45156@china.huawei.com> <4A092C12.8080704@rogers.com> <5E07A2E74C0749B7A84371EE422E90C6@china.huawei.com> <545DD1B15C9A42F0B1729CC02FFC6348@china.huawei.com> <2068ACFCE9FA4013865E833F38057DDB@china.huawei.com> <6e9223710905190853p133b630cud234027c753916ed@mail.gmail.com> Cc: ron.even.tlv@gmail.com, 'stephen botzko' , avt@ietf.org, 'Tom Taylor' Subject: Re: [AVT] Q for 3984bis-06 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 20:11:15 -0000 Inline. > -----Original Message----- > From: Randell Jesup [mailto:rjesup@wgate.com] > Sent: Tuesday, May 19, 2009 3:00 PM > To: Ye-Kui Wang > Cc: 'stephen botzko'; ron.even.tlv@gmail.com; 'Tom Taylor'; > avt@ietf.org > Subject: Re: [AVT] Q for 3984bis-06 > > Ye-Kui Wang writes: > >I see immediately the following problems with the semantics, without > >yet considering all possible cases. > > > >> level-upgrade-allowed=0 or 1: > >> If the offer sets level-upgrade-allowed to 1, > then an answer > >> may include any level above the offered level in > >> profile-level-id. > > > >Only when the offer and the answer both include > level-upgrade-allowed > >equal to 1, it is allowed for the answer to include a higher > level. In > >all other cases, level upgrade is not allowed. > > Why is level-upgrade-allowed required in the response? The > level upgrade is signaled (or not) via the profile-level-id > value returned in the answer; there's no need for an > additional parameter in the answer. > For backward compatibility. Inclusion of level-upgrade-allowed to 1 (or another parameter) indicates that an entity is not a legacy device which does not understand the new parameter. Otherwise, you have to make sure that the mechanism works in all the four cases: offerer answerer new new new legacy legacy new legacy legacy Note that these are orthogonal to the three cases your listed below. Basically all the 12 cases (and there are other dimentions of variations, e.g. the last point I made in this email) must be well analyzed for such a seemingly non-backward-compatible change. > >> The offerer may send at any level up to the level in the > >> answer, > > > >This does not work with the current semantics of > profile-level-id (part > >of which copied below for convenience). > > > >"The profile-level-id parameter indicates the default > sub-profile, i.e. > >the subset of coding tools that may have been used to generate the > >stream or that the receiver supports, and the default level of the > >stream or the receiver supports." > > > >According to the current semantics of profile-level-id, the > level part > >of the profile-level-id in the offer limits what the offerer > can receive. > > Right... That doesn't change; there's no conflict here. The > answerer answers with a higher level, but the answerer is > still not allowed to > *send* a level above that provided in the offer. The conflict is at the offerer's side. It includes a lower level, but you are proposing requires that the offerer can receive a higher level. To do this, you must change the current semantics of profile-level-id. > The answerer may > *receive* a stream up to the level they put in the answer. > That's the whole point here. > This point is contradicting with other places, where the answerer may receive a stream up to the level in the offer (not in the answer). > >> and and answerer can send levels only up to the level in the > >> offer. > > > >What if the answerer has a receiving capability between the > two levels > >in the offer and the answer or lower than the level in the > offer, and > >it wants the receiving capability expressed? > > Using level-upgrade-allowed=1 (the current proposal) means > there is only one level in the offer (profile-level-id). If > the answerer wants to downgrade the level in the response, > they may do so (as per current), regardless of > level-upgrade-allowed. If they want to upgrade it, they can > pick whatever level they're willing to receive and respond > with that. They will send the level in the offer (or below). > > Perhaps this table will help: > > Offer is level "B". I'll use level "A" to indicate a lower > level, and "C" > for a higher one (A < B < C). I'm assuming the offer > includes level-upgrade-allowed=1. > > > Answer level: lower (A) same (B) higher (C) > > Offerer can send: A B C > Answerer can send: A* B B > In the right case (the answer includes level C), what if the offerer's receiveing capability is actually lower than C? BR, YK > *This could be 'B' if we decide the same asymmetry is allowed > for level-downgrade as well, when level-upgrade-allowed=1. > (We could rename it level-asymmetry-allowed if we want that ability.) > > > Current behavior, and if there's no level-upgrade-allowed (or it's 0): > > Answer level: lower (A) same (B) higher (C) > > Offerer can send: A B Not Allowed > Answerer can send: A B Not Allowed > > > >BR, YK > > > > > >> If this is not present or is set to 0, then the answer > >> MUST NOT respond with a level greater than the level in > >> profile-level-id. > >> > >> Note that this only allows the level to be > increased in the > >> answer; the profile and constraints are not > allowed to change. > >> > > > >> -----Original Message----- > >> From: Randell Jesup [mailto:rjesup@wgate.com] > >> Sent: Tuesday, May 19, 2009 12:24 PM > >> To: stephen botzko > >> Cc: Ye-Kui Wang; ron.even.tlv@gmail.com; Tom Taylor; avt@ietf.org > >> Subject: Re: [AVT] Q for 3984bis-06 > >> > >> stephen botzko writes: > >> >>>> > >> >This is a real-world case; devices often have more encode > horsepower > >> >(and camera resolution) than they can actually display when > >> receiving, > >> >and they talk to other devices that *can* display that extra > >> resolution.. > >> >>>> > >> > > >> >In our experience, the reverse situation is what actually > happens - > >> >PCs for instance frequently can decode and display HD images, but > >> >are often limited to an SD webcam. Can you name a couple of > >> >specific real devices that have these HD cameras+encoders > and the limited decoders? > >> > >> Mostly I'm not talking PC's (I agree with you there, > though there are > >> cases where it still may make sense, like when displaying > video in a > >> portion of the screen). I'm mostly talking mobile and dedicated > >> devices with built-in LCDs; that would include > Smartphones, dedicated > >> videophones, "media" > >> tablets, etc. > >> > >> For example, certain devices have been made with two > different LCDs; > >> one ~850x480, the other ~480x234, both with VGA-class cameras. > >> Sending VGA content (or really anything beyond CIF) to the 480x234 > >> display is just a waste of bits. > >> If you wanted to and could negotiate it properly, though, > you could > >> send higher framerate CIF to that device, while it sends VGA at a > >> lower framerate to a device that can show it. > >> > >> > >> As for the comment about max-level=NN versus > >> level-upgrade-allowed: I'd originally thought > level-upgrade-allowed > >> made the most sense, and in fact probably it does - let the answer > >> respond with the highest level they can receive, and the > offerer can > >> send at whatever level they support. > >> > >> That's even easier to describe: > >> > >> level-upgrade-allowed=0 or 1: > >> If the offer sets level-upgrade-allowed to 1, > then an answer > >> may include any level above the offered level in > >> profile-level-id. The offerer may send at any > level up to the > >> level in the answer, and and answerer can send > levels only up > >> to the level in the offer. If this is not > present or is set to > >> 0, then the answer MUST NOT respond with a level > greater than > >> the level in profile-level-id. > >> > >> Note that this only allows the level to be > increased in the > >> answer; the profile and constraints are not > allowed to change. > > > -- > Randell Jesup, Worldgate (developers of the Ojo videophone), > ex-Amiga OS team rjesup@wgate.com "The fetters imposed on > liberty at home have ever been forged out of the weapons > provided for defence against real, pretended, or imaginary > dangers from abroad." > - James Madison, 4th US president (1751-1836) > > From rjesup@wgate.com Tue May 19 13:45:38 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 971223A67A7 for ; Tue, 19 May 2009 13:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.543 X-Spam-Level: X-Spam-Status: No, score=-1.543 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rU-a2HMwkIZG for ; Tue, 19 May 2009 13:45:37 -0700 (PDT) Received: from exchange1.wgate.com (pr-66-150-46-254.wgate.com [66.150.46.254]) by core3.amsl.com (Postfix) with ESMTP id 2144A3A6972 for ; Tue, 19 May 2009 13:45:37 -0700 (PDT) Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 May 2009 16:46:46 -0400 To: Ye-Kui Wang References: <04CAD96D4C5A3D48B1919248A8FE0D540943CDB9@xmb-sjc-215.amer.cisco.com> <2713212F2F334A15AB3DB03E1BB45156@china.huawei.com> <4A092C12.8080704@rogers.com> <5E07A2E74C0749B7A84371EE422E90C6@china.huawei.com> <545DD1B15C9A42F0B1729CC02FFC6348@china.huawei.com> <2068ACFCE9FA4013865E833F38057DDB@china.huawei.com> <6e9223710905190853p133b630cud234027c753916ed@mail.gmail.com> From: Randell Jesup Date: Tue, 19 May 2009 16:46:51 -0400 In-Reply-To: (Ye-Kui Wang's message of "Tue\, 19 May 2009 16\:12\:14 -0400") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 19 May 2009 20:46:46.0949 (UTC) FILETIME=[ED134D50:01C9D8C2] Cc: ron.even.tlv@gmail.com, 'stephen botzko' , avt@ietf.org, 'Tom Taylor' Subject: Re: [AVT] Q for 3984bis-06 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Randell Jesup List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 20:45:38 -0000 Ye-Kui Wang writes: >> Ye-Kui Wang writes: >> >I see immediately the following problems with the semantics, without >> >yet considering all possible cases. >> > >> >> level-upgrade-allowed=0 or 1: >> >> If the offer sets level-upgrade-allowed to 1, then an answer >> >> may include any level above the offered level in >> >> profile-level-id. >> > >> >Only when the offer and the answer both include level-upgrade-allowed >> >equal to 1, it is allowed for the answer to include a higher level. In >> >all other cases, level upgrade is not allowed. >> >> Why is level-upgrade-allowed required in the response? The >> level upgrade is signaled (or not) via the profile-level-id >> value returned in the answer; there's no need for an >> additional parameter in the answer. >> > >For backward compatibility. Inclusion of level-upgrade-allowed to 1 (or >another parameter) indicates that an entity is not a legacy device which >does not understand the new parameter. Otherwise, you have to make sure that >the mechanism works in all the four cases: > >offerer answerer >new new >new legacy >legacy new >legacy legacy If the offerer is legacy, then they don't include level-upgrade-allowed, and as stated the answerer is not allowed to upgrade the level. If the answerer is legacy, then they will ignore level-upgrade-allowed, and won't upgrade the level. So those 3 cases are all handled. >Note that these are orthogonal to the three cases your listed below. >Basically all the 12 cases (and there are other dimentions of variations, >e.g. the last point I made in this email) must be well analyzed for such a >seemingly non-backward-compatible change. Please see above. Those additional cases are all covered. >> >> The offerer may send at any level up to the level in the >> >> answer, >> > >> >This does not work with the current semantics of profile-level-id (part >> >of which copied below for convenience). >> > >> >"The profile-level-id parameter indicates the default sub-profile, i.e. >> >the subset of coding tools that may have been used to generate the >> >stream or that the receiver supports, and the default level of the >> >stream or the receiver supports." >> > >> >According to the current semantics of profile-level-id, the level part >> >of the profile-level-id in the offer limits what the offerer can >> >receive. >> >> Right... That doesn't change; there's no conflict here. The answerer >> answers with a higher level, but the answerer is still not allowed to >> *send* a level above that provided in the offer. > >The conflict is at the offerer's side. It includes a lower level, but you >are proposing requires that the offerer can receive a higher level. To do >this, you must change the current semantics of profile-level-id. No, unless we decide to take the option mentioned in my table (change it to "level-asymmetry-allowed"). Then (and only then) could the offerer could receive a level above what they offered. >> The answerer may *receive* a stream up to the level they put in the >> answer. That's the whole point here. > >This point is contradicting with other places, where the answerer may >receive a stream up to the level in the offer (not in the answer). Heh? In current 3984/3984bis usage, if the offer is level 2.0, and the answer is level 1.0, how will the answerer receive anything above level 1.0? Even in my proposal that's not allowed (unless we decide to use level-asymmetry-allowed instead of level-upgrade-allowed). >> >> and and answerer can send levels only up to the level in the >> >> offer. >> > >> >What if the answerer has a receiving capability between the two levels >> >in the offer and the answer or lower than the level in the offer, and >> >it wants the receiving capability expressed? >> >> Using level-upgrade-allowed=1 (the current proposal) means >> there is only one level in the offer (profile-level-id). If >> the answerer wants to downgrade the level in the response, >> they may do so (as per current), regardless of >> level-upgrade-allowed. If they want to upgrade it, they can >> pick whatever level they're willing to receive and respond >> with that. They will send the level in the offer (or below). >> >> Perhaps this table will help: >> >> Offer is level "B". I'll use level "A" to indicate a lower level, and >> "C" for a higher one (A < B < C). I'm assuming the offer includes >> level-upgrade-allowed=1. >> >> >> Answer level: lower (A) same (B) higher (C) >> >> Offerer can send: A B C >> Answerer can send: A* B B >> > >In the right case (the answer includes level C), what if the offerer's >receiveing capability is actually lower than C? Then they shouldn't answer with "C". They should answer with whatever level they do support. The point of this is to allow the answerer to offer to receive a higher level; they get to choose what that level is. >BR, YK > >> *This could be 'B' if we decide the same asymmetry is allowed >> for level-downgrade as well, when level-upgrade-allowed=1. >> (We could rename it level-asymmetry-allowed if we want that ability.) >> >> >> Current behavior, and if there's no level-upgrade-allowed (or it's 0): >> >> Answer level: lower (A) same (B) higher (C) >> >> Offerer can send: A B Not Allowed >> Answerer can send: A B Not Allowed >> >> >> >BR, YK >> > >> > >> >> If this is not present or is set to 0, then the answer >> >> MUST NOT respond with a level greater than the level in >> >> profile-level-id. >> >> >> >> Note that this only allows the level to be >> increased in the >> >> answer; the profile and constraints are not >> allowed to change. >> >> >> > >> >> -----Original Message----- >> >> From: Randell Jesup [mailto:rjesup@wgate.com] >> >> Sent: Tuesday, May 19, 2009 12:24 PM >> >> To: stephen botzko >> >> Cc: Ye-Kui Wang; ron.even.tlv@gmail.com; Tom Taylor; avt@ietf.org >> >> Subject: Re: [AVT] Q for 3984bis-06 >> >> >> >> stephen botzko writes: >> >> >>>> >> >> >This is a real-world case; devices often have more encode >> horsepower >> >> >(and camera resolution) than they can actually display when >> >> receiving, >> >> >and they talk to other devices that *can* display that extra >> >> resolution.. >> >> >>>> >> >> > >> >> >In our experience, the reverse situation is what actually >> happens - >> >> >PCs for instance frequently can decode and display HD images, but >> >> >are often limited to an SD webcam. Can you name a couple of >> >> >specific real devices that have these HD cameras+encoders >> and the limited decoders? >> >> >> >> Mostly I'm not talking PC's (I agree with you there, >> though there are >> >> cases where it still may make sense, like when displaying >> video in a >> >> portion of the screen). I'm mostly talking mobile and dedicated >> >> devices with built-in LCDs; that would include >> Smartphones, dedicated >> >> videophones, "media" >> >> tablets, etc. >> >> >> >> For example, certain devices have been made with two >> different LCDs; >> >> one ~850x480, the other ~480x234, both with VGA-class cameras. >> >> Sending VGA content (or really anything beyond CIF) to the 480x234 >> >> display is just a waste of bits. >> >> If you wanted to and could negotiate it properly, though, >> you could >> >> send higher framerate CIF to that device, while it sends VGA at a >> >> lower framerate to a device that can show it. >> >> >> >> >> >> As for the comment about max-level=NN versus >> >> level-upgrade-allowed: I'd originally thought >> level-upgrade-allowed >> >> made the most sense, and in fact probably it does - let the answer >> >> respond with the highest level they can receive, and the >> offerer can >> >> send at whatever level they support. >> >> >> >> That's even easier to describe: >> >> >> >> level-upgrade-allowed=0 or 1: >> >> If the offer sets level-upgrade-allowed to 1, >> then an answer >> >> may include any level above the offered level in >> >> profile-level-id. The offerer may send at any >> level up to the >> >> level in the answer, and and answerer can send >> levels only up >> >> to the level in the offer. If this is not >> present or is set to >> >> 0, then the answer MUST NOT respond with a level >> greater than >> >> the level in profile-level-id. >> >> >> >> Note that this only allows the level to be >> increased in the >> >> answer; the profile and constraints are not >> allowed to change. >> >> >> -- >> Randell Jesup, Worldgate (developers of the Ojo videophone), >> ex-Amiga OS team rjesup@wgate.com "The fetters imposed on >> liberty at home have ever been forged out of the weapons >> provided for defence against real, pretended, or imaginary >> dangers from abroad." >> - James Madison, 4th US president (1751-1836) >> >> -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com "The fetters imposed on liberty at home have ever been forged out of the weapons provided for defence against real, pretended, or imaginary dangers from abroad." - James Madison, 4th US president (1751-1836) From yekuiwang@huawei.com Tue May 19 14:16:13 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8850428C145 for ; Tue, 19 May 2009 14:16:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.234 X-Spam-Level: X-Spam-Status: No, score=-2.234 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T+qO0DqxFVY1 for ; Tue, 19 May 2009 14:16:12 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 0F1E13A6F11 for ; Tue, 19 May 2009 14:15:52 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJW00DP2TT4PM@usaga02-in.huawei.com> for avt@ietf.org; Tue, 19 May 2009 14:17:28 -0700 (PDT) Received: from W90946 ([10.193.125.102]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJW00J5GTSZ3W@usaga02-in.huawei.com> for avt@ietf.org; Tue, 19 May 2009 14:17:27 -0700 (PDT) Date: Tue, 19 May 2009 17:17:22 -0400 From: Ye-Kui Wang In-reply-to: To: 'Randell Jesup' Message-id: <686CE89178A540B3BBFD761A3DEBC494@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcnYwu993eZkEhZlQDep+mtXo/YEewAAOANg References: <04CAD96D4C5A3D48B1919248A8FE0D540943CDB9@xmb-sjc-215.amer.cisco.com> <2713212F2F334A15AB3DB03E1BB45156@china.huawei.com> <4A092C12.8080704@rogers.com> <5E07A2E74C0749B7A84371EE422E90C6@china.huawei.com> <545DD1B15C9A42F0B1729CC02FFC6348@china.huawei.com> <2068ACFCE9FA4013865E833F38057DDB@china.huawei.com> <6e9223710905190853p133b630cud234027c753916ed@mail.gmail.com> Cc: ron.even.tlv@gmail.com, 'stephen botzko' , avt@ietf.org, 'Tom Taylor' Subject: Re: [AVT] Q for 3984bis-06 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 21:16:13 -0000 I shortened the text. > If the offerer is legacy, then they don't include > level-upgrade-allowed, > and as stated the answerer is not allowed to upgrade the > level. If the > answerer is legacy, then they will ignore > level-upgrade-allowed, and won't > upgrade the level. So those 3 cases are all handled. OK. But it is possible that the answerer is new but does not want to upgrade the level in an offer/answer process. It would be certainly useful that the answerer lets the other side know whether it is new or legacy. Therefore, I'd prefer to include level-upgrade-allowed equal to 1 if the device is new (does understand the parameter and allows level upgrade). Note that something is allowed does not mean it is in use. > >The conflict is at the offerer's side. It includes a lower > level, but you > >are proposing requires that the offerer can receive a higher > level. To do > >this, you must change the current semantics of profile-level-id. > > No, unless we decide to take the option mentioned in my table > (change it to > "level-asymmetry-allowed"). Then (and only then) could the > offerer could > receive a level above what they offered. > Sorry, I mis-read your table. But that just makes a difference on receiving or sending capability, not the conclusion. In the righ case in the table (i.e. offer includes B, and answer includes C). The current semantics say that the offerer would only be able to send B and lower. But you want the offerer to be able to send C which is higher than B. > >> Perhaps this table will help: > >> > >> Offer is level "B". I'll use level "A" to indicate a > lower level, and > >> "C" for a higher one (A < B < C). I'm assuming the offer includes > >> level-upgrade-allowed=1. > >> > >> > >> Answer level: lower (A) same (B) higher (C) > >> > >> Offerer can send: A B C > >> Answerer can send: A* B B > >> > > > >In the right case (the answer includes level C), what if the > offerer's > >receiveing capability is actually lower than C? > > Then they shouldn't answer with "C". They should answer with whatever > level they do support. The point of this is to allow the answerer to > offer to receive a higher level; they get to choose what that > level is. Now with the correct reading of the table. Again, that just makes a difference on receiving or sending capability, not the conclusion. You are basically assuming that the offerer's sending (i.e. encoding) capability is not limited, i.e. it can send whatever high level the answer may include. How can that assumption be correct? BR, YK From singer@apple.com Tue May 19 14:16:21 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C49728C1F9 for ; Tue, 19 May 2009 14:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.184 X-Spam-Level: X-Spam-Status: No, score=-104.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j27uAINcu82l for ; Tue, 19 May 2009 14:16:20 -0700 (PDT) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 637123A6E1B for ; Tue, 19 May 2009 14:16:11 -0700 (PDT) Received: from relay13.apple.com (relay13.apple.com [17.128.113.29]) by mail-out4.apple.com (Postfix) with ESMTP id 7BD1A6452292; Tue, 19 May 2009 14:17:48 -0700 (PDT) Received: from relay13.apple.com (unknown [127.0.0.1]) by relay13.apple.com (Symantec Brightmail Gateway) with ESMTP id 5EEDE28050; Tue, 19 May 2009 14:17:48 -0700 (PDT) X-AuditID: 1180711d-a86f4bb000000259-69-4a1321fb1b79 Received: from [10.177.192.68] (singda.apple.com [17.202.35.52]) by relay13.apple.com (Apple SCV relay) with ESMTP id A19DD28086; Tue, 19 May 2009 14:17:47 -0700 (PDT) Mime-Version: 1.0 Message-Id: Date: Tue, 19 May 2009 14:17:25 -0700 To: Alex Giladi From: David Singer Content-Type: multipart/alternative; boundary="============_-969354629==_ma============" X-Brightmail-Tracker: AAAAAA== Cc: http-live-streaming-review@group.apple.com, avt@ietf.org Subject: Re: [AVT] iPhone streaming Internet-Draft posted X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 21:16:21 -0000 --============_-969354629==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Hi Alex, friends Even when tunneled through HTTP, RTP does not produce discrete files that can be cached and redistributed by CDNs. This is what enables HTTP live streaming to be scaled cost-effectively. On May 13, 2009, at 10:16 AM, Alex Giladi wrote: >David, >But why not re-use RTSP, just embedding it into HTTP? >Alex. > >On Wed, May 13, 2009 at 12:24 AM, David Singer ><singer@apple.com> wrote: > >>Hi, Ross. Thanks for looking at the spec. >> >> >>On May 5, 2009, at 8:39 AM, Ross Finlayson wrote: >> >> >>>>We appreciate feedback on the protocol. >>>> >>> >>>Rather than invent yet another protocol, why not just implement a RTSP/RTP >>> >>>client on the iPhone instead? >>> >> >>Distributing media as discrete files over HTTP gives content providers a >> >>cost-effective way to scale to high demand by using existing CDN and HTTP >> >>caching infrastructure. >> >> >>With this goal in mind, we're looking for technical feedback on the >> >>specification. >> >> >>thanks, nice to hear from you, -- David Singer Multimedia Standards, Apple Inc. --============_-969354629==_ma============ Content-Type: text/html; charset="us-ascii" Re: [AVT] iPhone streaming Internet-Draft posted
Hi Alex, friends

Even when tunneled through HTTP,   RTP does not produce discrete files that can be cached and redistributed by CDNs. This is what enables HTTP live streaming to be scaled cost-effectively.

On May 13, 2009, at 10:16 AM, Alex Giladi wrote:

David,
But why not re-use RTSP, just embedding it into HTTP?
Alex.

On Wed, May 13, 2009 at 12:24 AM, David Singer <singer@apple.com> wrote:
Hi, Ross. Thanks for looking at the spec.

On May 5, 2009, at 8:39 AM, Ross Finlayson wrote:

We appreciate feedback on the protocol.

Rather than invent yet another protocol, why not just implement a RTSP/RTP
client on the iPhone instead?

Distributing media as discrete files over HTTP gives content providers a
cost-effective way to scale to high demand by using existing CDN and HTTP
caching infrastructure.

With this goal in mind, we're looking for technical feedback on the
specification.

thanks, nice to hear from you,

--
David Singer
Multimedia Standards, Apple Inc.
--============_-969354629==_ma============-- From singer@apple.com Tue May 19 14:18:01 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06B403A70BD for ; Tue, 19 May 2009 14:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.234 X-Spam-Level: X-Spam-Status: No, score=-105.234 tagged_above=-999 required=5 tests=[AWL=1.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f09rlSRy6F8G for ; Tue, 19 May 2009 14:17:59 -0700 (PDT) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id BA7083A6E11 for ; Tue, 19 May 2009 14:17:59 -0700 (PDT) Received: from relay15.apple.com (relay15.apple.com [17.128.113.54]) by mail-out4.apple.com (Postfix) with ESMTP id D8BDF6452399; Tue, 19 May 2009 14:19:36 -0700 (PDT) Received: from relay15.apple.com (unknown [127.0.0.1]) by relay15.apple.com (Symantec Brightmail Gateway) with ESMTP id C3C1A5A0002; Tue, 19 May 2009 14:19:36 -0700 (PDT) X-AuditID: 11807136-ae229bb000005f25-e6-4a132268ee99 Received: from [10.177.192.68] (singda.apple.com [17.202.35.52]) by relay15.apple.com (Apple SCV relay) with ESMTP id 6096B558003; Tue, 19 May 2009 14:19:36 -0700 (PDT) Mime-Version: 1.0 Message-Id: Date: Tue, 19 May 2009 14:18:24 -0700 To: Greg Herlein From: David Singer Content-Type: multipart/alternative; boundary="============_-969354520==_ma============" X-Brightmail-Tracker: AAAAAA== Cc: http-live-streaming-review@group.apple.com, avt@ietf.org Subject: Re: [AVT] iPhone streaming Internet-Draft posted X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 21:18:01 -0000 --============_-969354520==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Hello Greg. Here are some answers to your questions: On May 7, 2009, at 8:06 AM, Greg Herlein wrote: >- in 6.1: "The server MUST divide the stream into individual media >files whose duration is approximately equal" > - why? > This duration is used to tune the client retry interval when polling the playlist file. See section 6.2.3. >- in 6.1: "The server MUST create a URI for each media file that >will allow its clients to obtain the file." > > - why? Divide the stream into many files and then the client has >to know the file names and ask one by one? > As discussed earlier the protocol distributes media as discrete files via HTTP to enable use of its caching infrastructure. >- in 2.0: "To play the stream, the client first obtains the Playlist >file and then obtains and plays each media file in the Playlist. It >reloads the Playlist file as described in this document to >discover additional segments." > - in 6.1: "The server MUST create a Playlist file. The Playlist >file MUST conform to the format described in Section 3." > - in 3.0: "Playlists MUST be Extended M3U Playlist files [M3U]. >This document extends the M3U file format by defining additional >tags." > - so you take an audio playlist format and extend it instead of >using something like SMIL? Why? > >- you specify a means to reload a playlist but not to signal a >client that there is a new playlist - so you poll. Poor form. > Our experience is that polling is efficient if the client polls at the right time, and in a real-time playback system it is generally possible to achieve this. We have not found a way to signal the existence of new media files that scales effectively (i.e. to the millions of simultaneous users). -- David Singer Multimedia Standards, Apple Inc. --============_-969354520==_ma============ Content-Type: text/html; charset="us-ascii" Re: [AVT] iPhone streaming Internet-Draft posted
Hello Greg. Here are some answers to your questions:

On May 7, 2009, at 8:06 AM, Greg Herlein wrote:
- in 6.1: "The server MUST divide the stream into individual media files whose duration is approximately equal"
  - why?

This duration is used to tune the client retry interval when polling the playlist file. See section 6.2.3.
- in 6.1: "The server MUST create a URI for each media file that will allow its clients to obtain the file."

  - why? Divide the stream into many files and then the client has to know the file names and ask one by one?
As discussed earlier the protocol distributes media as discrete files via HTTP to enable use of its caching infrastructure.
- in 2.0: "To play the stream, the client first obtains the Playlist file and then obtains and plays each media file in the Playlist. It reloads   the Playlist file as described in this document to discover additional segments."
 - in 6.1: "The server MUST create a Playlist file. The Playlist file MUST conform to the format described in Section 3."
 - in 3.0: "Playlists MUST be Extended M3U Playlist files [M3U]. This document extends the M3U file format by defining additional tags."
    - so you take an audio playlist format and extend it instead of using something like SMIL?  Why?

- you specify a means to reload a playlist but not to signal a client that there is a new playlist - so you poll.  Poor form.

Our experience is that polling is efficient if the client polls at the right time, and in a real-time playback system it is generally possible to achieve this.

We have not found a way to signal the existence of new media files that scales effectively (i.e. to the millions of simultaneous users).
--
David Singer
Multimedia Standards, Apple Inc.
--============_-969354520==_ma============-- From wwwrun@core3.amsl.com Tue May 19 14:53:23 2009 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 0D75E3A7109; Tue, 19 May 2009 14:53:22 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090519215323.0D75E3A7109@core3.amsl.com> Date: Tue, 19 May 2009 14:53:23 -0700 (PDT) Cc: avt@ietf.org Subject: [AVT] Last Call: draft-ietf-avt-app-rtp-keepalive (Application Mechanism for maintaining alive the Network Address Translator (NAT) mappings associated to RTP flows.) to Proposed Standard X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 21:53:23 -0000 The IESG has received a request from the Audio/Video Transport WG (avt) to consider the following document: - 'Application Mechanism for maintaining alive the Network Address Translator (NAT) mappings associated to RTP flows. ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-06-02. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-avt-app-rtp-keepalive-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16154&rfc_flag=0 From rjesup@wgate.com Tue May 19 21:27:34 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2E633A6B04 for ; Tue, 19 May 2009 21:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.554 X-Spam-Level: X-Spam-Status: No, score=-1.554 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kxn9nJQk1oki for ; Tue, 19 May 2009 21:27:33 -0700 (PDT) Received: from exchange1.wgate.com (pr-66-150-46-254.wgate.com [66.150.46.254]) by core3.amsl.com (Postfix) with ESMTP id 91D8C3A6972 for ; Tue, 19 May 2009 21:27:33 -0700 (PDT) Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 May 2009 00:29:10 -0400 To: Ye-Kui Wang References: <04CAD96D4C5A3D48B1919248A8FE0D540943CDB9@xmb-sjc-215.amer.cisco.com> <2713212F2F334A15AB3DB03E1BB45156@china.huawei.com> <4A092C12.8080704@rogers.com> <5E07A2E74C0749B7A84371EE422E90C6@china.huawei.com> <545DD1B15C9A42F0B1729CC02FFC6348@china.huawei.com> <2068ACFCE9FA4013865E833F38057DDB@china.huawei.com> <6e9223710905190853p133b630cud234027c753916ed@mail.gmail.com> <686CE89178A540B3BBFD761A3DEBC494@china.huawei.com> From: Randell Jesup Date: Wed, 20 May 2009 00:29:15 -0400 In-Reply-To: <686CE89178A540B3BBFD761A3DEBC494@china.huawei.com> (Ye-Kui Wang's message of "Tue\, 19 May 2009 17\:17\:22 -0400") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 20 May 2009 04:29:10.0135 (UTC) FILETIME=[854D8870:01C9D903] Cc: ron.even.tlv@gmail.com, 'stephen botzko' , avt@ietf.org, 'Tom Taylor' Subject: Re: [AVT] Q for 3984bis-06 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Randell Jesup List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 04:27:34 -0000 Ye-Kui Wang writes: >I shortened the text. > >> If the offerer is legacy, then they don't include level-upgrade-allowed, >> and as stated the answerer is not allowed to upgrade the level. If the >> answerer is legacy, then they will ignore level-upgrade-allowed, and >> won't upgrade the level. So those 3 cases are all handled. > >OK. But it is possible that the answerer is new but does not want to upgrade >the level in an offer/answer process. It would be certainly useful that the >answerer lets the other side know whether it is new or legacy. Therefore, >I'd prefer to include level-upgrade-allowed equal to 1 if the device is new >(does understand the parameter and allows level upgrade). Note that >something is allowed does not mean it is in use. The answerer could do that, and I don't have a problem with it (it doesn't hurt anything), but I don't see how it's useful in any way. >> >The conflict is at the offerer's side. It includes a lower level, but >> >you are proposing requires that the offerer can receive a higher >> >level. To do this, you must change the current semantics of >> >profile-level-id. >> >> No, unless we decide to take the option mentioned in my table (change it >> to "level-asymmetry-allowed"). Then (and only then) could the offerer >> could receive a level above what they offered. > >Sorry, I mis-read your table. But that just makes a difference on receiving >or sending capability, not the conclusion. In the righ case in the table >(i.e. offer includes B, and answer includes C). The current semantics say >that the offerer would only be able to send B and lower. But you want the >offerer to be able to send C which is higher than B. I don't understand what you're trying to say here. That's the point of level upgrade. And the offerer is still sending at a level specified in the answers profile-level-id. Perhaps you're just saying "yes, this means the offerer might end up sending a stream at a higher level than it offered", which is the whole point of level upgrade. >> >> Perhaps this table will help: >> >> >> >> Offer is level "B". I'll use level "A" to indicate a lower level, >> >> and "C" for a higher one (A < B < C). I'm assuming the offer >> >> includes level-upgrade-allowed=1. >> >> >> >> >> >> Answer level: lower (A) same (B) higher (C) >> >> >> >> Offerer can send: A B C >> >> Answerer can send: A* B B >> >> >> > >> >In the right case (the answer includes level C), what if the offerer's >> >receiveing capability is actually lower than C? >> >> Then they shouldn't answer with "C". They should answer with whatever >> level they do support. The point of this is to allow the answerer to >> offer to receive a higher level; they get to choose what that >> level is. > >Now with the correct reading of the table. Again, that just makes a >difference on receiving or sending capability, not the conclusion. You are >basically assuming that the offerer's sending (i.e. encoding) capability is >not limited, i.e. it can send whatever high level the answer may include. >How can that assumption be correct? You need to think about how level works in H.264. Remember we're only changing level, not constraints or profiles. Levels imply details about the maximum frame size, maximum macroblocks per second, maximum bitrate, etc, and each level is a superset of the next-lower level. Using a level doesn't mean you (as an encoder) have to hit those maximums. If you encode a stream using the parameters of a lower level (i.e. using lower maximums), it's decodable by a higher-level decoder, even if you set the parameter sets to the higher level. Even more importantly, there's no apparent requirement to send exactly the level given by the profile-level-id; sending lower levels (with the correct profile and constraints) appears to be just fine (note that this interacts with parameter-set handling - you need to deal with making sure the decoder has correct parameter sets, as you always do). >From 3984: If the profile-level-id parameter is used to indicate properties of a NAL unit stream, it indicates the profile and level that a decoder has to support in order to comply with [1] when it decodes the stream. and If the profile-level-id parameter is used for capability exchange or session setup procedure, it indicates the profile that the codec supports and the highest level supported for the signaled profile. Note "highest level". And: The level conveyed in the value of the profile-level-id parameter MUST be such that the receiver is fully capable of supporting. and o Parameters used for declaring receiver capabilities are in general downgradable; i.e., they express the upper limit for a sender's possible behavior. Thus a sender MAY select to set its encoder using only lower/lesser or equal values of these parameters. [snip] o Parameters declaring a configuration point are not downgradable, with the exception of the level part of the "profile-level-id" parameter. This expresses values a receiver expects to be used and must be used verbatim on the sender side. So, to summarize, if in response to an offer with level-upgrade-allowed=1, the answer includes a level higher than the offerer supports: * The offerer can encode a stream as if it's a higher level (including parameter sets), but using the encode settings of a lower level that it supports. * The offerer can encode a stream using a lower level, including lower-level parameter sets. In both cases, the parameter sets must be conveyed to the answerer in some manner; the mechanisms that would make the most sense are in-band parameter sets (with all that implies), or using sprop-level-parameter-sets including levels above the level in the offered profile-level-id, so that the answer can select one of those levels and thus install those parameter sets. None of this requires any further modification to 3984bis that I can see - just allowing level-upgrade-allowed (or level-asymmetric-allowed). -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com "The fetters imposed on liberty at home have ever been forged out of the weapons provided for defence against real, pretended, or imaginary dangers from abroad." - James Madison, 4th US president (1751-1836) From rjesup@wgate.com Tue May 19 22:06:21 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 977413A6B09 for ; Tue, 19 May 2009 22:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.564 X-Spam-Level: X-Spam-Status: No, score=-1.564 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWNs7khiKuqf for ; Tue, 19 May 2009 22:06:20 -0700 (PDT) Received: from exchange1.wgate.com (pr-66-150-46-254.wgate.com [66.150.46.254]) by core3.amsl.com (Postfix) with ESMTP id 261C83A6A6F for ; Tue, 19 May 2009 22:06:20 -0700 (PDT) Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 May 2009 01:07:57 -0400 To: Ye-Kui Wang References: <04CAD96D4C5A3D48B1919248A8FE0D540943CDB9@xmb-sjc-215.amer.cisco.com> <2713212F2F334A15AB3DB03E1BB45156@china.huawei.com> <4A092C12.8080704@rogers.com> <5E07A2E74C0749B7A84371EE422E90C6@china.huawei.com> <545DD1B15C9A42F0B1729CC02FFC6348@china.huawei.com> <2068ACFCE9FA4013865E833F38057DDB@china.huawei.com> <6e9223710905190853p133b630cud234027c753916ed@mail.gmail.com> <686CE89178A540B3BBFD761A3DEBC494@china.huawei.com> <1C47D7182AB24F758DC60913784EBD37@china.huawei.com> From: Randell Jesup Date: Wed, 20 May 2009 01:08:01 -0400 In-Reply-To: <1C47D7182AB24F758DC60913784EBD37@china.huawei.com> (Ye-Kui Wang's message of "Wed\, 20 May 2009 00\:54\:42 -0400") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 20 May 2009 05:07:57.0213 (UTC) FILETIME=[F05974D0:01C9D908] Cc: ron.even.tlv@gmail.com, 'stephen botzko' , avt@ietf.org, 'Tom Taylor' Subject: Re: [AVT] Q for 3984bis-06 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Randell Jesup List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 05:06:21 -0000 Ye-Kui Wang writes: >> So, to summarize, if in response to an offer with >> level-upgrade-allowed=1, the answer includes a level higher >> than the offerer supports: >> >> * The offerer can encode a stream as if it's a higher level (including >> parameter sets), but using the encode settings of a lower level that >> it supports. > >So, in your interpretation, the offerer sending a higher level just means >that it sends sequence parameter sets containing the higher level, but the >bitstream characteristics are still restricted by the lower level. How could >this bring any practical usefulness? In the example, offer includes level B >(e.g. spatial resolution up to QVGA), and the answer includes a higher level >C (e.g. spatial resolution up to VGA), then both sides still send and >receive up to QVGA resolution, but the offer includes sequence parameter >sets include the level value C. Why is this useful at all? You asked a different question: >> >Now with the correct reading of the table. Again, that just makes a >> >difference on receiving or sending capability, not the conclusion. You >> >are basically assuming that the offerer's sending (i.e. encoding) >> >capability is not limited, i.e. it can send whatever high level the >> >answer may include. How can that assumption be correct? You asked about sending at "whatever high level the answer may include". My response shows that you don't have to send at an arbitrarily-high level - you can send at the highest level you support. For example, if the offer is 1.3 with level-upgrade-allowed=1, and the answer is level 3.1, then the offerer can send at any level up to and including level 3.1. It could send level 2.0 if that's the highest it can encode. >BR, YK > >> -----Original Message----- >> From: Randell Jesup [mailto:rjesup@wgate.com] >> Sent: Wednesday, May 20, 2009 12:29 AM >> To: Ye-Kui Wang >> Cc: 'stephen botzko'; ron.even.tlv@gmail.com; 'Tom Taylor'; >> avt@ietf.org >> Subject: Re: [AVT] Q for 3984bis-06 >> >> Ye-Kui Wang writes: >> >> >I shortened the text. >> > >> >> If the offerer is legacy, then they don't include >> >> level-upgrade-allowed, and as stated the answerer is not >> allowed to >> >> upgrade the level. If the answerer is legacy, then they >> will ignore >> >> level-upgrade-allowed, and won't upgrade the level. So >> those 3 cases are all handled. >> > >> >OK. But it is possible that the answerer is new but does not want to >> >upgrade the level in an offer/answer process. It would be certainly >> >useful that the answerer lets the other side know whether it >> is new or >> >legacy. Therefore, I'd prefer to include >> level-upgrade-allowed equal to >> >1 if the device is new (does understand the parameter and >> allows level >> >upgrade). Note that something is allowed does not mean it is in use. >> >> The answerer could do that, and I don't have a problem with >> it (it doesn't hurt anything), but I don't see how it's >> useful in any way. >> >> >> >The conflict is at the offerer's side. It includes a lower level, >> >> >but you are proposing requires that the offerer can >> receive a higher >> >> >level. To do this, you must change the current semantics of >> >> >profile-level-id. >> >> >> >> No, unless we decide to take the option mentioned in my >> table (change >> >> it to "level-asymmetry-allowed"). Then (and only then) could the >> >> offerer could receive a level above what they offered. >> > >> >Sorry, I mis-read your table. But that just makes a difference on >> >receiving or sending capability, not the conclusion. In the >> righ case >> >in the table (i.e. offer includes B, and answer includes C). The >> >current semantics say that the offerer would only be able to >> send B and >> >lower. But you want the offerer to be able to send C which >> is higher than B. >> >> I don't understand what you're trying to say here. That's >> the point of level upgrade. And the offerer is still sending >> at a level specified in the answers profile-level-id. >> Perhaps you're just saying "yes, this means the offerer might >> end up sending a stream at a higher level than it offered", >> which is the whole point of level upgrade. >> >> >> >> Perhaps this table will help: >> >> >> >> >> >> Offer is level "B". I'll use level "A" to indicate a >> lower level, >> >> >> and "C" for a higher one (A < B < C). I'm assuming the offer >> >> >> includes level-upgrade-allowed=1. >> >> >> >> >> >> >> >> >> Answer level: lower (A) same (B) higher (C) >> >> >> >> >> >> Offerer can send: A B C >> >> >> Answerer can send: A* B B >> >> >> >> >> > >> >> >In the right case (the answer includes level C), what if the >> >> >offerer's receiveing capability is actually lower than C? >> >> >> >> Then they shouldn't answer with "C". They should answer with >> >> whatever level they do support. The point of this is to allow the >> >> answerer to offer to receive a higher level; they get to >> choose what >> >> that level is. >> > >> >Now with the correct reading of the table. Again, that just makes a >> >difference on receiving or sending capability, not the >> conclusion. You >> >are basically assuming that the offerer's sending (i.e. encoding) >> >capability is not limited, i.e. it can send whatever high >> level the answer may include. >> >How can that assumption be correct? >> >> You need to think about how level works in H.264. >> >> Remember we're only changing level, not constraints or profiles. >> >> Levels imply details about the maximum frame size, maximum >> macroblocks per second, maximum bitrate, etc, and each level >> is a superset of the next-lower level. Using a level doesn't >> mean you (as an encoder) have to hit those maximums. If you >> encode a stream using the parameters of a lower level (i.e. >> using lower maximums), it's decodable by a higher-level >> decoder, even if you set the parameter sets to the higher level. >> >> Even more importantly, there's no apparent requirement to >> send exactly the level given by the profile-level-id; sending >> lower levels (with the correct profile and constraints) >> appears to be just fine (note that this interacts with >> parameter-set handling - you need to deal with making sure >> the decoder has correct parameter sets, as you always do). >> >> From 3984: >> >> If the profile-level-id parameter is used to indicate >> properties of a >> NAL unit stream, it indicates the profile and level that a >> decoder has >> to support in order to comply with [1] when it decodes the stream. >> >> and >> >> If the profile-level-id parameter is used for capability >> exchange or >> session setup procedure, it indicates the profile that the codec >> supports and the highest level supported for the signaled profile. >> >> Note "highest level". And: >> >> The level conveyed in the value of the profile-level-id >> parameter MUST >> be such that the receiver is fully capable of supporting. >> >> and >> o Parameters used for declaring receiver capabilities are >> in general >> downgradable; i.e., they express the upper limit for a sender's >> possible behavior. Thus a sender MAY select to set its encoder >> using only lower/lesser or equal values of these parameters. >> [snip] >> o Parameters declaring a configuration point are not downgradable, >> with the exception of the level part of the "profile-level-id" >> parameter. This expresses values a receiver expects to be used >> and must be used verbatim on the sender side. >> >> >> So, to summarize, if in response to an offer with >> level-upgrade-allowed=1, the answer includes a level higher >> than the offerer supports: >> >> * The offerer can encode a stream as if it's a higher level (including >> parameter sets), but using the encode settings of a lower >> level that it >> supports. >> * The offerer can encode a stream using a lower level, including >> lower-level parameter sets. >> >> In both cases, the parameter sets must be conveyed to the >> answerer in some manner; the mechanisms that would make the >> most sense are in-band parameter sets (with all that >> implies), or using sprop-level-parameter-sets including >> levels above the level in the offered profile-level-id, so >> that the answer can select one of those levels and thus >> install those parameter sets. >> >> None of this requires any further modification to 3984bis >> that I can see - just allowing level-upgrade-allowed (or >> level-asymmetric-allowed). >> >> -- >> Randell Jesup, Worldgate (developers of the Ojo videophone), >> ex-Amiga OS team rjesup@wgate.com "The fetters imposed on >> liberty at home have ever been forged out of the weapons >> provided for defence against real, pretended, or imaginary >> dangers from abroad." >> - James Madison, 4th US president (1751-1836) >> >> -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com "The fetters imposed on liberty at home have ever been forged out of the weapons provided for defence against real, pretended, or imaginary dangers from abroad." - James Madison, 4th US president (1751-1836) From yekuiwang@huawei.com Tue May 19 22:08:13 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B74D3A6A91 for ; Tue, 19 May 2009 22:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.244 X-Spam-Level: X-Spam-Status: No, score=-2.244 tagged_above=-999 required=5 tests=[AWL=0.355, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dB04Ld7EPiyS for ; Tue, 19 May 2009 22:08:12 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 4D8E33A685D for ; Tue, 19 May 2009 22:08:12 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJX00D5OEZCPM@usaga02-in.huawei.com> for avt@ietf.org; Tue, 19 May 2009 21:54:48 -0700 (PDT) Received: from W90946 ([10.47.145.66]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJX00C9GEZ7X5@usaga02-in.huawei.com> for avt@ietf.org; Tue, 19 May 2009 21:54:48 -0700 (PDT) Date: Wed, 20 May 2009 00:54:42 -0400 From: Ye-Kui Wang In-reply-to: To: 'Randell Jesup' Message-id: <1C47D7182AB24F758DC60913784EBD37@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcnZA4ebkr4CC/ImSAG0bgPSt2KleAAAjnzA References: <04CAD96D4C5A3D48B1919248A8FE0D540943CDB9@xmb-sjc-215.amer.cisco.com> <2713212F2F334A15AB3DB03E1BB45156@china.huawei.com> <4A092C12.8080704@rogers.com> <5E07A2E74C0749B7A84371EE422E90C6@china.huawei.com> <545DD1B15C9A42F0B1729CC02FFC6348@china.huawei.com> <2068ACFCE9FA4013865E833F38057DDB@china.huawei.com> <6e9223710905190853p133b630cud234027c753916ed@mail.gmail.com> <686CE89178A540B3BBFD761A3DEBC494@china.huawei.com> Cc: ron.even.tlv@gmail.com, 'stephen botzko' , avt@ietf.org, 'Tom Taylor' Subject: Re: [AVT] Q for 3984bis-06 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 05:08:13 -0000 > So, to summarize, if in response to an offer with > level-upgrade-allowed=1, the answer includes a level higher > than the offerer supports: > > * The offerer can encode a stream as if it's a higher level (including > parameter sets), but using the encode settings of a lower > level that it > supports. So, in your interpretation, the offerer sending a higher level just means that it sends sequence parameter sets containing the higher level, but the bitstream characteristics are still restricted by the lower level. How could this bring any practical usefulness? In the example, offer includes level B (e.g. spatial resolution up to QVGA), and the answer includes a higher level C (e.g. spatial resolution up to VGA), then both sides still send and receive up to QVGA resolution, but the offer includes sequence parameter sets include the level value C. Why is this useful at all? BR, YK > -----Original Message----- > From: Randell Jesup [mailto:rjesup@wgate.com] > Sent: Wednesday, May 20, 2009 12:29 AM > To: Ye-Kui Wang > Cc: 'stephen botzko'; ron.even.tlv@gmail.com; 'Tom Taylor'; > avt@ietf.org > Subject: Re: [AVT] Q for 3984bis-06 > > Ye-Kui Wang writes: > > >I shortened the text. > > > >> If the offerer is legacy, then they don't include > >> level-upgrade-allowed, and as stated the answerer is not > allowed to > >> upgrade the level. If the answerer is legacy, then they > will ignore > >> level-upgrade-allowed, and won't upgrade the level. So > those 3 cases are all handled. > > > >OK. But it is possible that the answerer is new but does not want to > >upgrade the level in an offer/answer process. It would be certainly > >useful that the answerer lets the other side know whether it > is new or > >legacy. Therefore, I'd prefer to include > level-upgrade-allowed equal to > >1 if the device is new (does understand the parameter and > allows level > >upgrade). Note that something is allowed does not mean it is in use. > > The answerer could do that, and I don't have a problem with > it (it doesn't hurt anything), but I don't see how it's > useful in any way. > > >> >The conflict is at the offerer's side. It includes a lower level, > >> >but you are proposing requires that the offerer can > receive a higher > >> >level. To do this, you must change the current semantics of > >> >profile-level-id. > >> > >> No, unless we decide to take the option mentioned in my > table (change > >> it to "level-asymmetry-allowed"). Then (and only then) could the > >> offerer could receive a level above what they offered. > > > >Sorry, I mis-read your table. But that just makes a difference on > >receiving or sending capability, not the conclusion. In the > righ case > >in the table (i.e. offer includes B, and answer includes C). The > >current semantics say that the offerer would only be able to > send B and > >lower. But you want the offerer to be able to send C which > is higher than B. > > I don't understand what you're trying to say here. That's > the point of level upgrade. And the offerer is still sending > at a level specified in the answers profile-level-id. > Perhaps you're just saying "yes, this means the offerer might > end up sending a stream at a higher level than it offered", > which is the whole point of level upgrade. > > >> >> Perhaps this table will help: > >> >> > >> >> Offer is level "B". I'll use level "A" to indicate a > lower level, > >> >> and "C" for a higher one (A < B < C). I'm assuming the offer > >> >> includes level-upgrade-allowed=1. > >> >> > >> >> > >> >> Answer level: lower (A) same (B) higher (C) > >> >> > >> >> Offerer can send: A B C > >> >> Answerer can send: A* B B > >> >> > >> > > >> >In the right case (the answer includes level C), what if the > >> >offerer's receiveing capability is actually lower than C? > >> > >> Then they shouldn't answer with "C". They should answer with > >> whatever level they do support. The point of this is to allow the > >> answerer to offer to receive a higher level; they get to > choose what > >> that level is. > > > >Now with the correct reading of the table. Again, that just makes a > >difference on receiving or sending capability, not the > conclusion. You > >are basically assuming that the offerer's sending (i.e. encoding) > >capability is not limited, i.e. it can send whatever high > level the answer may include. > >How can that assumption be correct? > > You need to think about how level works in H.264. > > Remember we're only changing level, not constraints or profiles. > > Levels imply details about the maximum frame size, maximum > macroblocks per second, maximum bitrate, etc, and each level > is a superset of the next-lower level. Using a level doesn't > mean you (as an encoder) have to hit those maximums. If you > encode a stream using the parameters of a lower level (i.e. > using lower maximums), it's decodable by a higher-level > decoder, even if you set the parameter sets to the higher level. > > Even more importantly, there's no apparent requirement to > send exactly the level given by the profile-level-id; sending > lower levels (with the correct profile and constraints) > appears to be just fine (note that this interacts with > parameter-set handling - you need to deal with making sure > the decoder has correct parameter sets, as you always do). > > From 3984: > > If the profile-level-id parameter is used to indicate > properties of a > NAL unit stream, it indicates the profile and level that a > decoder has > to support in order to comply with [1] when it decodes the stream. > > and > > If the profile-level-id parameter is used for capability > exchange or > session setup procedure, it indicates the profile that the codec > supports and the highest level supported for the signaled profile. > > Note "highest level". And: > > The level conveyed in the value of the profile-level-id > parameter MUST > be such that the receiver is fully capable of supporting. > > and > o Parameters used for declaring receiver capabilities are > in general > downgradable; i.e., they express the upper limit for a sender's > possible behavior. Thus a sender MAY select to set its encoder > using only lower/lesser or equal values of these parameters. > [snip] > o Parameters declaring a configuration point are not downgradable, > with the exception of the level part of the "profile-level-id" > parameter. This expresses values a receiver expects to be used > and must be used verbatim on the sender side. > > > So, to summarize, if in response to an offer with > level-upgrade-allowed=1, the answer includes a level higher > than the offerer supports: > > * The offerer can encode a stream as if it's a higher level (including > parameter sets), but using the encode settings of a lower > level that it > supports. > * The offerer can encode a stream using a lower level, including > lower-level parameter sets. > > In both cases, the parameter sets must be conveyed to the > answerer in some manner; the mechanisms that would make the > most sense are in-band parameter sets (with all that > implies), or using sprop-level-parameter-sets including > levels above the level in the offered profile-level-id, so > that the answer can select one of those levels and thus > install those parameter sets. > > None of this requires any further modification to 3984bis > that I can see - just allowing level-upgrade-allowed (or > level-asymmetric-allowed). > > -- > Randell Jesup, Worldgate (developers of the Ojo videophone), > ex-Amiga OS team rjesup@wgate.com "The fetters imposed on > liberty at home have ever been forged out of the weapons > provided for defence against real, pretended, or imaginary > dangers from abroad." > - James Madison, 4th US president (1751-1836) > > From ingemar.s.johansson@ericsson.com Tue May 19 22:50:45 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9AA13A6C12 for ; Tue, 19 May 2009 22:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.938 X-Spam-Level: X-Spam-Status: No, score=-5.938 tagged_above=-999 required=5 tests=[AWL=0.311, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r9vq5KYVDXQC for ; Tue, 19 May 2009 22:50:43 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 68CF43A6A77 for ; Tue, 19 May 2009 22:50:43 -0700 (PDT) X-AuditID: c1b4fb3e-b7babae000000a46-79-4a139a920314 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 63.91.02630.29A931A4; Wed, 20 May 2009 07:52:19 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 May 2009 07:52:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 20 May 2009 07:52:17 +0200 Message-ID: <130EBB38279E9847BAAAE0B8F9905F8C011EB703@esealmw109.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] Q for 3984bis-06 Thread-Index: AcnYtBWOt1dj9YGXRrCaEA6wxzKsKQAWMJnA References: From: "Ingemar Johansson S" To: X-OriginalArrivalTime: 20 May 2009 05:52:18.0233 (UTC) FILETIME=[2270E290:01C9D90F] X-Brightmail-Tracker: AAAAAA== Cc: rjesup@wgate.com, ron.even.tlv@gmail.com, stephen.botzko@gmail.com, tom.taylor@rogers.com Subject: Re: [AVT] Q for 3984bis-06 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 05:50:45 -0000 Hi I agree with Randell, in fact there are may cellphones today that can both encode and decode at high levels, however the limited screensize (or resolution) of a cell phone makes it useless to send full HD content to a cell phone (unless it is connected to a TV or projector).=20 There are scenarios (not too far fetched IMHO) where a mobile user wish to make a call to his/her friends or his famility who sit in comfortably in front of a 50" TV. This means that we wish to send fullHD in one direction while CIF is propably sufficient in the other direction. This is a highly asymmetric scenario, the work on image attributes in MMUSIC is partly done with this in mind. I tried to address these asymmetric issues in a more generic way in=20 http://tools.ietf.org/id/draft-johansson-mmusic-asymmetric-media-00.txt, it is however quite obvious that it is not too easy to do so, also the interest is quite low.=20 With the above in mind I really believe it would be good if 3984bis could make full asymmetry possible. Regards Ingemar=20 > ------------------------------ >=20 > Message: 2 > Date: Tue, 19 May 2009 12:24:09 -0400 > From: Randell Jesup > Subject: Re: [AVT] Q for 3984bis-06 > To: stephen botzko > Cc: ron.even.tlv@gmail.com, Tom Taylor , > avt@ietf.org > Message-ID: > Content-Type: text/plain; charset=3Dus-ascii >=20 > stephen botzko writes: > >>>> > >This is a real-world case; devices often have more encode horsepower=20 > >(and camera resolution) than they can actually display when=20 > receiving,=20 > >and they talk to other devices that *can* display that extra=20 > resolution.. > >>>> > > > >In our experience, the reverse situation is what actually=20 > happens - PCs=20 > >for instance frequently can decode and display HD images,=20 > but are often=20 > >limited to an SD webcam. > >Can you name a couple of specific real devices that have these HD > >cameras+encoders and the limited decoders? >=20 > Mostly I'm not talking PC's (I agree with you there, though=20 > there are cases where it still may make sense, like when=20 > displaying video in a portion of the screen). I'm mostly=20 > talking mobile and dedicated devices with built-in LCDs; that=20 > would include Smartphones, dedicated videophones, "media" > tablets, etc. >=20 > For example, certain devices have been made with two=20 > different LCDs; one ~850x480, the other ~480x234, both with=20 > VGA-class cameras. Sending VGA content (or really anything=20 > beyond CIF) to the 480x234 display is just a waste of bits. =20 > If you wanted to and could negotiate it properly, though, you=20 > could send higher framerate CIF to that device, while it=20 > sends VGA at a lower framerate to a device that can show it. >=20 >=20 > As for the comment about max-level=3DNN versus=20 > level-upgrade-allowed: I'd originally thought=20 > level-upgrade-allowed made the most sense, and in fact=20 > probably it does - let the answer respond with the highest=20 > level they can receive, and the offerer can send at whatever=20 > level they support. =20 >=20 > That's even easier to describe: >=20 > level-upgrade-allowed=3D0 or 1: > If the offer sets level-upgrade-allowed to 1, then=20 > an answer may > include any level above the offered level in=20 > profile-level-id. > The offerer may send at any level up to the level in=20 > the answer, > and and answerer can send levels only up to the level in the > offer. If this is not present or is set to 0, then=20 > the answer > MUST NOT respond with a level greater than the level in > profile-level-id. =20 >=20 > Note that this only allows the level to be increased in the > answer; the profile and constraints are not allowed=20 > to change. >=20 > -- > Randell Jesup, Worldgate (developers of the Ojo videophone),=20 > ex-Amiga OS team rjesup@wgate.com "The fetters imposed on=20 > liberty at home have ever been forged out of the weapons=20 > provided for defence against real, pretended, or imaginary=20 > dangers from abroad." > - James Madison, 4th US president (1751-1836) >=20 >=20 >=20 From alex.giladi@gmail.com Wed May 20 08:49:22 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DFB13A6D2D for ; Wed, 20 May 2009 08:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=-1.001, BAYES_00=-2.599, MANGLED_TEXT=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id COfe32xozLwF for ; Wed, 20 May 2009 08:49:21 -0700 (PDT) Received: from mail-bw0-f222.google.com (mail-bw0-f222.google.com [209.85.218.222]) by core3.amsl.com (Postfix) with ESMTP id 2E7AF3A6932 for ; Wed, 20 May 2009 08:49:21 -0700 (PDT) Received: by bwz22 with SMTP id 22so495782bwz.37 for ; Wed, 20 May 2009 08:50:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=MS67rdB+n2Y538UcvvGCclZiSYMjYteXPDxqhztt1Gk=; b=m/mP0GopZo34ENzBvjfiTqeUjqiaxnEvJiSnhWIGAibIK2VqKFI6/gGIZHmjXwwmQF NQKvLsZ01NNoJWmWMPk938cWYlElFajm++Eo7QhRhnGhy9kUKzi3r0hdGsLdnIVD0BsJ mKJeIxWSoIBM+HmRGTuXvx/xdpYtS8/LXp2/A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=vA29A9a3YNDJ8/Ypf4zj2P6XZURgHdx+mF7DR/AGIp1mUhNZh1UheuOjXEvct6kj/t WIRY5uK7dSruGtYwJdAEHw87qWd0PiKlZrsfOPQR4kEYx+orFCDVTPlyDNNI+PAzANNv j5AmqR5S9aREkhJ2U1GpFy953YThmHqvX6JvE= MIME-Version: 1.0 Received: by 10.204.64.196 with SMTP id f4mr1339560bki.151.1242834655947; Wed, 20 May 2009 08:50:55 -0700 (PDT) In-Reply-To: References: Date: Wed, 20 May 2009 09:50:55 -0600 Message-ID: <57a9e15d0905200850r52246c7avffb731767d343e2c@mail.gmail.com> From: Alex Giladi To: David Singer , http-live-streaming-review@group.apple.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: avt@ietf.org Subject: Re: [AVT] iPhone streaming Internet-Draft posted X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 15:49:22 -0000 David, Roger: A few of questions regarding the RFC: 3. * Is there some sort of a standardized definition of M3U you are referencing? There is a reference [M3U], which is a link to Wikipedia, which, in turn, is a moving target. 3.1.7. EXT-X-STREAM-INF * What are the requirements on the MPEG-2 TS/PES here? Is PMT expected to be in each file, or do you convey the relevant information separately? * Why do you need to specify the codecs separately, if they are already conveyed in the stream? 4. * E.g. in case of H.264, do you require SPS/PPS/SEI's in the beginning of each file, or only in the beginning of time? If the latter is correct, how do you start playing from an offset? Otherwise, why these parameters cannot change (e.g. switch from 30000/1001 to 24000/1001)? What is the definition of "consistent parameters" in this case? 6.1.3. Providing variant streams * Does this mean that PTS values need to match in all variant streams? What happens in case of different frame rates? Thanks! Alex. From yekuiwang@huawei.com Wed May 20 08:50:20 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E41D3A6932 for ; Wed, 20 May 2009 08:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.255 X-Spam-Level: X-Spam-Status: No, score=-2.255 tagged_above=-999 required=5 tests=[AWL=0.344, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KKqiprGT7YPF for ; Wed, 20 May 2009 08:50:18 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id C0A6E3A6DA0 for ; Wed, 20 May 2009 08:50:18 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJY0027Q9EIQC@usaga04-in.huawei.com> for avt@ietf.org; Wed, 20 May 2009 10:51:55 -0500 (CDT) Received: from W90946 ([10.51.0.1]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJY00D9S9ED1D@usaga04-in.huawei.com> for avt@ietf.org; Wed, 20 May 2009 10:51:54 -0500 (CDT) Date: Wed, 20 May 2009 11:51:47 -0400 From: Ye-Kui Wang In-reply-to: To: 'Randell Jesup' Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcnZCPICoe11EvE0SWm5FzsO7f0Y0AAWLd3w References: <04CAD96D4C5A3D48B1919248A8FE0D540943CDB9@xmb-sjc-215.amer.cisco.com> <2713212F2F334A15AB3DB03E1BB45156@china.huawei.com> <4A092C12.8080704@rogers.com> <5E07A2E74C0749B7A84371EE422E90C6@china.huawei.com> <545DD1B15C9A42F0B1729CC02FFC6348@china.huawei.com> <2068ACFCE9FA4013865E833F38057DDB@china.huawei.com> <6e9223710905190853p133b630cud234027c753916ed@mail.gmail.com> <686CE89178A540B3BBFD761A3DEBC494@china.huawei.com> <1C47D7182AB24F758DC60913784EBD37@china.huawei.com> Cc: ron.even.tlv@gmail.com, 'stephen botzko' , avt@ietf.org, 'Tom Taylor' Subject: Re: [AVT] Q for 3984bis-06 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 15:50:20 -0000 > For example, if the offer is 1.3 with > level-upgrade-allowed=1, and the answer is level 3.1, then > the offerer can send at any level up to and including level > 3.1. It could send level 2.0 if that's the highest it can encode. The whole point is, if the offer contians level 1.3 (per 3984 or the bis draft) with sendrecv or no direction attribute, then level 1.3 is the highest it can both encoded and encode. In this case, it simply cannot encode above level 1.3. Text in 3984: If the profile-level-id parameter is used for capability exchange or session setup procedure, it indicates the profile that the codec supports and the highest level supported for the signaled profile. BR, YK > -----Original Message----- > From: Randell Jesup [mailto:rjesup@wgate.com] > Sent: Wednesday, May 20, 2009 1:08 AM > To: Ye-Kui Wang > Cc: 'stephen botzko'; ron.even.tlv@gmail.com; 'Tom Taylor'; > avt@ietf.org > Subject: Re: [AVT] Q for 3984bis-06 > > Ye-Kui Wang writes: > >> So, to summarize, if in response to an offer with > >> level-upgrade-allowed=1, the answer includes a level > higher than the > >> offerer supports: > >> > >> * The offerer can encode a stream as if it's a higher > level (including > >> parameter sets), but using the encode settings of a > lower level that > >> it supports. > > > >So, in your interpretation, the offerer sending a higher level just > >means that it sends sequence parameter sets containing the higher > >level, but the bitstream characteristics are still restricted by the > >lower level. How could this bring any practical usefulness? In the > >example, offer includes level B (e.g. spatial resolution up > to QVGA), > >and the answer includes a higher level C (e.g. spatial > resolution up to > >VGA), then both sides still send and receive up to QVGA > resolution, but > >the offer includes sequence parameter sets include the level > value C. Why is this useful at all? > > You asked a different question: > > >> >Now with the correct reading of the table. Again, that > just makes a > >> >difference on receiving or sending capability, not the > conclusion. > >> >You are basically assuming that the offerer's sending (i.e. > >> >encoding) capability is not limited, i.e. it can send > whatever high > >> >level the answer may include. How can that assumption be correct? > > You asked about sending at "whatever high level the answer > may include". > My response shows that you don't have to send at an > arbitrarily-high level > - you can send at the highest level you support. > > For example, if the offer is 1.3 with > level-upgrade-allowed=1, and the answer is level 3.1, then > the offerer can send at any level up to and including level > 3.1. It could send level 2.0 if that's the highest it can encode. > > >BR, YK > > > >> -----Original Message----- > >> From: Randell Jesup [mailto:rjesup@wgate.com] > >> Sent: Wednesday, May 20, 2009 12:29 AM > >> To: Ye-Kui Wang > >> Cc: 'stephen botzko'; ron.even.tlv@gmail.com; 'Tom Taylor'; > >> avt@ietf.org > >> Subject: Re: [AVT] Q for 3984bis-06 > >> > >> Ye-Kui Wang writes: > >> > >> >I shortened the text. > >> > > >> >> If the offerer is legacy, then they don't include > >> >> level-upgrade-allowed, and as stated the answerer is not > >> allowed to > >> >> upgrade the level. If the answerer is legacy, then they > >> will ignore > >> >> level-upgrade-allowed, and won't upgrade the level. So > >> those 3 cases are all handled. > >> > > >> >OK. But it is possible that the answerer is new but does > not want to > >> >upgrade the level in an offer/answer process. It would be > certainly > >> >useful that the answerer lets the other side know whether it > >> is new or > >> >legacy. Therefore, I'd prefer to include > >> level-upgrade-allowed equal to > >> >1 if the device is new (does understand the parameter and > >> allows level > >> >upgrade). Note that something is allowed does not mean it > is in use. > >> > >> The answerer could do that, and I don't have a problem with it (it > >> doesn't hurt anything), but I don't see how it's useful in any way. > >> > >> >> >The conflict is at the offerer's side. It includes a > lower level, > >> >> >but you are proposing requires that the offerer can > >> receive a higher > >> >> >level. To do this, you must change the current semantics of > >> >> >profile-level-id. > >> >> > >> >> No, unless we decide to take the option mentioned in my > >> table (change > >> >> it to "level-asymmetry-allowed"). Then (and only then) > could the > >> >> offerer could receive a level above what they offered. > >> > > >> >Sorry, I mis-read your table. But that just makes a difference on > >> >receiving or sending capability, not the conclusion. In the > >> righ case > >> >in the table (i.e. offer includes B, and answer includes C). The > >> >current semantics say that the offerer would only be able to > >> send B and > >> >lower. But you want the offerer to be able to send C which > >> is higher than B. > >> > >> I don't understand what you're trying to say here. That's > the point > >> of level upgrade. And the offerer is still sending at a level > >> specified in the answers profile-level-id. > >> Perhaps you're just saying "yes, this means the offerer > might end up > >> sending a stream at a higher level than it offered", which is the > >> whole point of level upgrade. > >> > >> >> >> Perhaps this table will help: > >> >> >> > >> >> >> Offer is level "B". I'll use level "A" to indicate a > >> lower level, > >> >> >> and "C" for a higher one (A < B < C). I'm assuming > the offer > >> >> >> includes level-upgrade-allowed=1. > >> >> >> > >> >> >> > >> >> >> Answer level: lower (A) same (B) higher (C) > >> >> >> > >> >> >> Offerer can send: A B C > >> >> >> Answerer can send: A* B B > >> >> >> > >> >> > > >> >> >In the right case (the answer includes level C), what if the > >> >> >offerer's receiveing capability is actually lower than C? > >> >> > >> >> Then they shouldn't answer with "C". They should answer with > >> >> whatever level they do support. The point of this is > to allow the > >> >> answerer to offer to receive a higher level; they get to > >> choose what > >> >> that level is. > >> > > >> >Now with the correct reading of the table. Again, that > just makes a > >> >difference on receiving or sending capability, not the > >> conclusion. You > >> >are basically assuming that the offerer's sending (i.e. encoding) > >> >capability is not limited, i.e. it can send whatever high > >> level the answer may include. > >> >How can that assumption be correct? > >> > >> You need to think about how level works in H.264. > >> > >> Remember we're only changing level, not constraints or profiles. > >> > >> Levels imply details about the maximum frame size, maximum > >> macroblocks per second, maximum bitrate, etc, and each level is a > >> superset of the next-lower level. Using a level doesn't > mean you (as > >> an encoder) have to hit those maximums. If you encode a > stream using > >> the parameters of a lower level (i.e. > >> using lower maximums), it's decodable by a higher-level > decoder, even > >> if you set the parameter sets to the higher level. > >> > >> Even more importantly, there's no apparent requirement to send > >> exactly the level given by the profile-level-id; sending > lower levels > >> (with the correct profile and constraints) appears to be just fine > >> (note that this interacts with parameter-set handling - > you need to > >> deal with making sure the decoder has correct parameter > sets, as you > >> always do). > >> > >> From 3984: > >> > >> If the profile-level-id parameter is used to indicate > properties > >> of a > >> NAL unit stream, it indicates the profile and level > that a decoder > >> has > >> to support in order to comply with [1] when it decodes > the stream. > >> > >> and > >> > >> If the profile-level-id parameter is used for > capability exchange > >> or > >> session setup procedure, it indicates the profile that the codec > >> supports and the highest level supported for the > signaled profile. > >> > >> Note "highest level". And: > >> > >> The level conveyed in the value of the profile-level-id > parameter > >> MUST > >> be such that the receiver is fully capable of supporting. > >> > >> and > >> o Parameters used for declaring receiver capabilities are in > >> general > >> downgradable; i.e., they express the upper limit for > a sender's > >> possible behavior. Thus a sender MAY select to set > its encoder > >> using only lower/lesser or equal values of these parameters. > >> [snip] > >> o Parameters declaring a configuration point are not > downgradable, > >> with the exception of the level part of the > "profile-level-id" > >> parameter. This expresses values a receiver expects > to be used > >> and must be used verbatim on the sender side. > >> > >> > >> So, to summarize, if in response to an offer with > >> level-upgrade-allowed=1, the answer includes a level > higher than the > >> offerer supports: > >> > >> * The offerer can encode a stream as if it's a higher > level (including > >> parameter sets), but using the encode settings of a lower level > >> that it > >> supports. > >> * The offerer can encode a stream using a lower level, including > >> lower-level parameter sets. > >> > >> In both cases, the parameter sets must be conveyed to the > answerer in > >> some manner; the mechanisms that would make the most sense are > >> in-band parameter sets (with all that implies), or using > >> sprop-level-parameter-sets including levels above the level in the > >> offered profile-level-id, so that the answer can select > one of those > >> levels and thus install those parameter sets. > >> > >> None of this requires any further modification to 3984bis > that I can > >> see - just allowing level-upgrade-allowed (or > >> level-asymmetric-allowed). > >> > >> -- > >> Randell Jesup, Worldgate (developers of the Ojo > videophone), ex-Amiga > >> OS team rjesup@wgate.com "The fetters imposed on liberty > at home have > >> ever been forged out of the weapons provided for defence against > >> real, pretended, or imaginary dangers from abroad." > >> - James Madison, 4th US president (1751-1836) > >> > >> > > > -- > Randell Jesup, Worldgate (developers of the Ojo videophone), > ex-Amiga OS team > rjesup@wgate.com > "The fetters imposed on liberty at home have ever been forged > out of the weapons > provided for defence against real, pretended, or imaginary > dangers from abroad." > - James Madison, 4th US president (1751-1836) > > From gherlein@herlein.com Wed May 20 09:03:47 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D4B43A6B64 for ; Wed, 20 May 2009 09:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.513 X-Spam-Level: X-Spam-Status: No, score=-1.513 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0KFKPXhQE6l for ; Wed, 20 May 2009 09:03:46 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by core3.amsl.com (Postfix) with ESMTP id 481F43A6867 for ; Wed, 20 May 2009 09:03:46 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 29so182253wff.31 for ; Wed, 20 May 2009 09:05:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.163.12 with SMTP id q12mr493272wfo.224.1242835521539; Wed, 20 May 2009 09:05:21 -0700 (PDT) In-Reply-To: References: Date: Wed, 20 May 2009 09:05:21 -0700 Message-ID: <31d1be720905200905o53281cbja084ea69cf30ec0@mail.gmail.com> From: Greg Herlein To: David Singer Content-Type: multipart/alternative; boundary=0016368e25ccc68e66046a5a3182 Cc: http-live-streaming-review@group.apple.com, avt@ietf.org Subject: Re: [AVT] iPhone streaming Internet-Draft posted X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 16:03:47 -0000 --0016368e25ccc68e66046a5a3182 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Comments inline On Tue, May 19, 2009 at 2:18 PM, David Singer wrote: > Hello Greg. Here are some answers to your questions: > > On May 7, 2009, at 8:06 AM, Greg Herlein wrote: > > - in 6.1: "The server MUST divide the stream into individual media files > whose duration is approximately equal" > - why? > > > This duration is used to tune the client retry interval when polling the > playlist file. See section 6.2.3. > So you force the content to be fragmented (with no direction on how to fragment) just to trigger a playlist reload? > > - in 6.1: "The server MUST create a URI for each media file that will > allow its clients to obtain the file." > > - why? Divide the stream into many files and then the client has to know > the file names and ask one by one? > > As discussed earlier the protocol distributes media as discrete files via > HTTP to enable use of its caching infrastructure. > Yes, it was discussed earlier. John Lazzaro raised some questions that were raised several years ago in regards to this being a bad idea. I have not seen anyone from Apple respond to that. > > - in 2.0: "To play the stream, the client first obtains the Playlist file > and then obtains and plays each media file in the Playlist. It reloads the > Playlist file as described in this document to discover additional > segments." > > - in 6.1: "The server MUST create a Playlist file. The Playlist file MUST > conform to the format described in Section 3." > - in 3.0: "Playlists MUST be Extended M3U Playlist files [M3U]. This > document extends the M3U file format by defining additional tags." > - so you take an audio playlist format and extend it instead of using > something like SMIL? Why? > > - you specify a means to reload a playlist but not to signal a client that > there is a new playlist - so you poll. Poor form. > > > Our experience is that polling is efficient if the client polls at the > right time, and in a real-time playback system it is generally possible to > achieve this. > I'd like to hear more about that. It seems that your real-time polling interval is controlled indirectly by the size of the file (see above). Yet once you provide for trick play this stops being time-based. This seems to be a distinctly weak approach to controlling polling. It would help if you wanted to take this approach to delve into the why behind some of the choices. I infer that you want distinct URI for each file fragment so that you can control caching - but there are other ways to control caching. You could, for example, have a single URI that clients poll to see if there is a new playlist available. The approach you outline seems to have ideas behind it aimed at accomplishing certain things, but those are not called out at all. Those of us that have been working on these kinds of things for years are wondering if you are trying to re-invent the wheel (or just to get a standard for something you already built). > We have not found a way to signal the existence of new media files that > scales effectively (i.e. to the millions of simultaneous users). > Yes, that makes sense. I also raised questions about the choice of playlist format - specifically using a non-standards-based audio playlist format instead of something like SMIL that was designed for this kind of thing. Comments on that? Greg -- Greg Herlein www.herlein.com --0016368e25ccc68e66046a5a3182 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Comments inline

On Tue, May 19, 2009 at 2= :18 PM, David Singer <singer@apple.com> wrote:
Hello Greg. Here are some answers to your questions:

On May 7, 2009, at 8:06 AM, Greg Herlein wrote:
- in 6.1: "The server MUST divide the stream into individual media files whose duration is approximately equal"
=A0 - why?

This duration is used to tune the client retry interval when polling the playlist file. See section 6.2.3.
=
So you force the content to be fragmented (with no direction on how to = fragment) just to trigger a playlist reload?

- in 6.1: "The server MUST create a URI for each media file that will allow its clients to obtain the file."

=A0 - why? Divide the stream into many files and then the client has to know the file names and ask one by one?
As discussed earlier the protocol distributes media as discrete files via HTTP to enable use of its caching infrastructure.

Yes, it was discussed earlier.=A0 John Lazzaro raised som= e questions that were raised several years ago in regards to this being a b= ad idea.=A0 I have not seen anyone from Apple respond to that.
=A0

- in 2.0: "To play the stream, the client first obtains the Playlist file and then obtains and plays each media file in the Playlist. It reloads=A0 =A0the Playlist file as described in this document to discover additional segments."
=A0- in 6.1: "The server MUST create a Playlist file. The Playlist file MUST conform to the format described in Section 3."
=A0- in 3.0: "Playlists MUST be Extended M3U Playlist files [M3U]. This document extends the M3U file format by defining additional tags."
=A0=A0=A0 - so you take an audio playlist format and extend it instead of using something like SMIL?=A0 Why?

- you specify a means to reload a playlist but not to signal a client that there is a new playlist - so you poll.=A0 Poor form.

Our experience is that polling is efficient if the client polls at the right time, and in a real-time playback system it is=A0generally possible to achieve this.

I= 'd like to hear more about that.=A0 It seems that your real-time pollin= g interval is controlled indirectly by the size of the file (see above).=A0= Yet once you provide for trick play this stops being time-based.=A0 This s= eems to be a distinctly weak approach to controlling polling.=A0=A0

It would help if you wanted to take this approach to delve into the why= behind some of the choices.=A0 I infer that you want distinct URI for each= file fragment so that you can control caching - but there are other ways t= o control caching.=A0 You could, for example, have a single URI that client= s poll to see if there is a new playlist available.=A0 The approach you out= line seems to have ideas behind it aimed at accomplishing certain things, b= ut those are not called out at all.=A0 Those of us that have been working o= n these kinds of things for years are wondering if you are trying to re-inv= ent the wheel (or just to get a standard for something you already built).<= br>
<= div>

We have not found a way to signal the existence of new media files that scales effectively (i.e. to the millions of simultaneous users).

Yes, that makes sense.

I al= so raised questions about the choice of playlist format - specifically usin= g a non-standards-based audio playlist format instead of something like SMI= L that was designed for this kind of thing.=A0 Comments on that?

Greg




--
Greg Herlein
www.herlein.com
--0016368e25ccc68e66046a5a3182-- From yekuiwang@huawei.com Wed May 20 09:05:44 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38C0C28C1CB for ; Wed, 20 May 2009 09:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6VCsAl-cpeW for ; Wed, 20 May 2009 09:05:42 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 8E86D3A6D97 for ; Wed, 20 May 2009 09:05:42 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJY00JZSA46VQ@usaga02-in.huawei.com> for avt@ietf.org; Wed, 20 May 2009 09:07:19 -0700 (PDT) Received: from W90946 ([10.51.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJY0033MA42T0@usaga02-in.huawei.com> for avt@ietf.org; Wed, 20 May 2009 09:07:18 -0700 (PDT) Date: Wed, 20 May 2009 12:07:12 -0400 From: Ye-Kui Wang In-reply-to: To: 'Randell Jesup' Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcnZCPICoe11EvE0SWm5FzsO7f0Y0AAWLd3wAAB7VEA= References: <04CAD96D4C5A3D48B1919248A8FE0D540943CDB9@xmb-sjc-215.amer.cisco.com> <2713212F2F334A15AB3DB03E1BB45156@china.huawei.com> <4A092C12.8080704@rogers.com> <5E07A2E74C0749B7A84371EE422E90C6@china.huawei.com> <545DD1B15C9A42F0B1729CC02FFC6348@china.huawei.com> <2068ACFCE9FA4013865E833F38057DDB@china.huawei.com> <6e9223710905190853p133b630cud234027c753916ed@mail.gmail.com> <686CE89178A540B3BBFD761A3DEBC494@china.huawei.com> <1C47D7182AB24F758DC60913784EBD37@china.huawei.com> Cc: ron.even.tlv@gmail.com, 'Tom Taylor' , 'stephen botzko' , avt@ietf.org Subject: Re: [AVT] Q for 3984bis-06 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 16:05:44 -0000 Typo: encoded -> decode. So, the sentence should be as follows. " The whole point is, if the offer contians level 1.3 (per 3984 or the bis draft) with sendrecv or no direction attribute, then level 1.3 is the highest it can both encoded and encode. In this case, it simply cannot encode above level 1.3. " BTW, it is not absolutely prohibited to change the semantics of profile-level-id, I am just saying that you need to change the semantics. In addition, if the encoding/sending capability and the decoding/receiving capability is different, both capabiilties should be expressed. One way is to use different direction attributes (and separate SDP), which was considered not perfect. The other way is, as I mentioned earlier, to use two parameters, one for each. BR, YK > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > Behalf Of Ye-Kui Wang > Sent: Wednesday, May 20, 2009 11:52 AM > To: 'Randell Jesup' > Cc: ron.even.tlv@gmail.com; 'stephen botzko'; avt@ietf.org; > 'Tom Taylor' > Subject: Re: [AVT] Q for 3984bis-06 > > > > For example, if the offer is 1.3 with > level-upgrade-allowed=1, and the > > answer is level 3.1, then the offerer can send at any level > up to and > > including level 3.1. It could send level 2.0 if that's the > highest it > > can encode. > > The whole point is, if the offer contians level 1.3 (per 3984 > or the bis > draft) with sendrecv or no direction attribute, then level > 1.3 is the highest it can both encoded and encode. In this > case, it simply cannot encode above level 1.3. > > Text in 3984: > If the profile-level-id parameter is used for > capability exchange or session setup > procedure, > it indicates the profile that the codec > supports and the highest level > supported for the signaled profile. > > BR, YK > > > -----Original Message----- > > From: Randell Jesup [mailto:rjesup@wgate.com] > > Sent: Wednesday, May 20, 2009 1:08 AM > > To: Ye-Kui Wang > > Cc: 'stephen botzko'; ron.even.tlv@gmail.com; 'Tom Taylor'; > > avt@ietf.org > > Subject: Re: [AVT] Q for 3984bis-06 > > > > Ye-Kui Wang writes: > > >> So, to summarize, if in response to an offer with > > >> level-upgrade-allowed=1, the answer includes a level > > higher than the > > >> offerer supports: > > >> > > >> * The offerer can encode a stream as if it's a higher > > level (including > > >> parameter sets), but using the encode settings of a > > lower level that > > >> it supports. > > > > > >So, in your interpretation, the offerer sending a higher > level just > > >means that it sends sequence parameter sets containing the higher > > >level, but the bitstream characteristics are still > restricted by the > > >lower level. How could this bring any practical usefulness? In the > > >example, offer includes level B (e.g. spatial resolution up > > to QVGA), > > >and the answer includes a higher level C (e.g. spatial > > resolution up to > > >VGA), then both sides still send and receive up to QVGA > > resolution, but > > >the offer includes sequence parameter sets include the level > > value C. Why is this useful at all? > > > > You asked a different question: > > > > >> >Now with the correct reading of the table. Again, that > > just makes a > > >> >difference on receiving or sending capability, not the > > conclusion. > > >> >You are basically assuming that the offerer's sending (i.e. > > >> >encoding) capability is not limited, i.e. it can send > > whatever high > > >> >level the answer may include. How can that assumption > be correct? > > > > You asked about sending at "whatever high level the answer may > > include". > > My response shows that you don't have to send at an > arbitrarily-high > > level > > - you can send at the highest level you support. > > > > For example, if the offer is 1.3 with > level-upgrade-allowed=1, and the > > answer is level 3.1, then the offerer can send at any level > up to and > > including level 3.1. It could send level 2.0 if that's the > highest it > > can encode. > > > > >BR, YK > > > > > >> -----Original Message----- > > >> From: Randell Jesup [mailto:rjesup@wgate.com] > > >> Sent: Wednesday, May 20, 2009 12:29 AM > > >> To: Ye-Kui Wang > > >> Cc: 'stephen botzko'; ron.even.tlv@gmail.com; 'Tom Taylor'; > > >> avt@ietf.org > > >> Subject: Re: [AVT] Q for 3984bis-06 > > >> > > >> Ye-Kui Wang writes: > > >> > > >> >I shortened the text. > > >> > > > >> >> If the offerer is legacy, then they don't include > > >> >> level-upgrade-allowed, and as stated the answerer is not > > >> allowed to > > >> >> upgrade the level. If the answerer is legacy, then they > > >> will ignore > > >> >> level-upgrade-allowed, and won't upgrade the level. So > > >> those 3 cases are all handled. > > >> > > > >> >OK. But it is possible that the answerer is new but does > > not want to > > >> >upgrade the level in an offer/answer process. It would be > > certainly > > >> >useful that the answerer lets the other side know whether it > > >> is new or > > >> >legacy. Therefore, I'd prefer to include > > >> level-upgrade-allowed equal to > > >> >1 if the device is new (does understand the parameter and > > >> allows level > > >> >upgrade). Note that something is allowed does not mean it > > is in use. > > >> > > >> The answerer could do that, and I don't have a problem > with it (it > > >> doesn't hurt anything), but I don't see how it's useful > in any way. > > >> > > >> >> >The conflict is at the offerer's side. It includes a > > lower level, > > >> >> >but you are proposing requires that the offerer can > > >> receive a higher > > >> >> >level. To do this, you must change the current semantics of > > >> >> >profile-level-id. > > >> >> > > >> >> No, unless we decide to take the option mentioned in my > > >> table (change > > >> >> it to "level-asymmetry-allowed"). Then (and only then) > > could the > > >> >> offerer could receive a level above what they offered. > > >> > > > >> >Sorry, I mis-read your table. But that just makes a > difference on > > >> >receiving or sending capability, not the conclusion. In the > > >> righ case > > >> >in the table (i.e. offer includes B, and answer > includes C). The > > >> >current semantics say that the offerer would only be able to > > >> send B and > > >> >lower. But you want the offerer to be able to send C which > > >> is higher than B. > > >> > > >> I don't understand what you're trying to say here. That's > > the point > > >> of level upgrade. And the offerer is still sending at a level > > >> specified in the answers profile-level-id. > > >> Perhaps you're just saying "yes, this means the offerer > > might end up > > >> sending a stream at a higher level than it offered", > which is the > > >> whole point of level upgrade. > > >> > > >> >> >> Perhaps this table will help: > > >> >> >> > > >> >> >> Offer is level "B". I'll use level "A" to indicate a > > >> lower level, > > >> >> >> and "C" for a higher one (A < B < C). I'm assuming > > the offer > > >> >> >> includes level-upgrade-allowed=1. > > >> >> >> > > >> >> >> > > >> >> >> Answer level: lower (A) same (B) > higher (C) > > >> >> >> > > >> >> >> Offerer can send: A B C > > >> >> >> Answerer can send: A* B B > > >> >> >> > > >> >> > > > >> >> >In the right case (the answer includes level C), what if the > > >> >> >offerer's receiveing capability is actually lower than C? > > >> >> > > >> >> Then they shouldn't answer with "C". They should answer with > > >> >> whatever level they do support. The point of this is > > to allow the > > >> >> answerer to offer to receive a higher level; they get to > > >> choose what > > >> >> that level is. > > >> > > > >> >Now with the correct reading of the table. Again, that > > just makes a > > >> >difference on receiving or sending capability, not the > > >> conclusion. You > > >> >are basically assuming that the offerer's sending (i.e. > encoding) > > >> >capability is not limited, i.e. it can send whatever high > > >> level the answer may include. > > >> >How can that assumption be correct? > > >> > > >> You need to think about how level works in H.264. > > >> > > >> Remember we're only changing level, not constraints or profiles. > > >> > > >> Levels imply details about the maximum frame size, maximum > > >> macroblocks per second, maximum bitrate, etc, and each > level is a > > >> superset of the next-lower level. Using a level doesn't > > mean you (as > > >> an encoder) have to hit those maximums. If you encode a > > stream using > > >> the parameters of a lower level (i.e. > > >> using lower maximums), it's decodable by a higher-level > > decoder, even > > >> if you set the parameter sets to the higher level. > > >> > > >> Even more importantly, there's no apparent requirement to send > > >> exactly the level given by the profile-level-id; sending > > lower levels > > >> (with the correct profile and constraints) appears to be > just fine > > >> (note that this interacts with parameter-set handling - > > you need to > > >> deal with making sure the decoder has correct parameter > > sets, as you > > >> always do). > > >> > > >> From 3984: > > >> > > >> If the profile-level-id parameter is used to indicate > > properties > > >> of a > > >> NAL unit stream, it indicates the profile and level > > that a decoder > > >> has > > >> to support in order to comply with [1] when it decodes > > the stream. > > >> > > >> and > > >> > > >> If the profile-level-id parameter is used for > > capability exchange > > >> or > > >> session setup procedure, it indicates the profile > that the codec > > >> supports and the highest level supported for the > > signaled profile. > > >> > > >> Note "highest level". And: > > >> > > >> The level conveyed in the value of the profile-level-id > > parameter > > >> MUST > > >> be such that the receiver is fully capable of supporting. > > >> > > >> and > > >> o Parameters used for declaring receiver capabilities are in > > >> general > > >> downgradable; i.e., they express the upper limit for > > a sender's > > >> possible behavior. Thus a sender MAY select to set > > its encoder > > >> using only lower/lesser or equal values of these > parameters. > > >> [snip] > > >> o Parameters declaring a configuration point are not > > downgradable, > > >> with the exception of the level part of the > > "profile-level-id" > > >> parameter. This expresses values a receiver expects > > to be used > > >> and must be used verbatim on the sender side. > > >> > > >> > > >> So, to summarize, if in response to an offer with > > >> level-upgrade-allowed=1, the answer includes a level > > higher than the > > >> offerer supports: > > >> > > >> * The offerer can encode a stream as if it's a higher > > level (including > > >> parameter sets), but using the encode settings of a > lower level > > >> that it > > >> supports. > > >> * The offerer can encode a stream using a lower level, including > > >> lower-level parameter sets. > > >> > > >> In both cases, the parameter sets must be conveyed to the > > answerer in > > >> some manner; the mechanisms that would make the most sense are > > >> in-band parameter sets (with all that implies), or using > > >> sprop-level-parameter-sets including levels above the > level in the > > >> offered profile-level-id, so that the answer can select > > one of those > > >> levels and thus install those parameter sets. > > >> > > >> None of this requires any further modification to 3984bis > > that I can > > >> see - just allowing level-upgrade-allowed (or > > >> level-asymmetric-allowed). > > >> > > >> -- > > >> Randell Jesup, Worldgate (developers of the Ojo > > videophone), ex-Amiga > > >> OS team rjesup@wgate.com "The fetters imposed on liberty > > at home have > > >> ever been forged out of the weapons provided for defence against > > >> real, pretended, or imaginary dangers from abroad." > > >> - James Madison, 4th US president (1751-1836) > > >> > > >> > > > > > > -- > > Randell Jesup, Worldgate (developers of the Ojo > videophone), ex-Amiga > > OS team rjesup@wgate.com "The fetters imposed on liberty at > home have > > ever been forged out of the weapons provided for defence > against real, > > pretended, or imaginary dangers from abroad." > > - James Madison, 4th US president (1751-1836) > > > > > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > From Even.roni@huawei.com Wed May 20 09:40:01 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6340A3A6BF2 for ; Wed, 20 May 2009 09:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.546 X-Spam-Level: X-Spam-Status: No, score=-1.546 tagged_above=-999 required=5 tests=[AWL=-1.051, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EA-gj68WxWRX for ; Wed, 20 May 2009 09:39:59 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 710CB3A6C93 for ; Wed, 20 May 2009 09:39:59 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJY00LQGBP2KU@szxga03-in.huawei.com> for avt@ietf.org; Thu, 21 May 2009 00:41:26 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJY005DBBP2XK@szxga03-in.huawei.com> for avt@ietf.org; Thu, 21 May 2009 00:41:26 +0800 (CST) Received: from windows8d787f9 (bzq-79-181-118-116.red.bezeqint.net [79.181.118.116]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJY00I1YBOTNC@szxml02-in.huawei.com>; Thu, 21 May 2009 00:41:26 +0800 (CST) Date: Wed, 20 May 2009 19:40:34 +0300 From: Roni Even In-reply-to: To: 'Ye-Kui Wang' , 'Randell Jesup' Message-id: <001501c9d969$b8966fb0$29c34f10$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcnZCPICoe11EvE0SWm5FzsO7f0Y0AAWLd3wAAB7VEAAAMVlMA== References: <04CAD96D4C5A3D48B1919248A8FE0D540943CDB9@xmb-sjc-215.amer.cisco.com> <2713212F2F334A15AB3DB03E1BB45156@china.huawei.com> <4A092C12.8080704@rogers.com> <5E07A2E74C0749B7A84371EE422E90C6@china.huawei.com> <545DD1B15C9A42F0B1729CC02FFC6348@china.huawei.com> <2068ACFCE9FA4013865E833F38057DDB@china.huawei.com> <6e9223710905190853p133b630cud234027c753916ed@mail.gmail.com> <686CE89178A540B3BBFD761A3DEBC494@china.huawei.com> <1C47D7182AB24F758DC60913784EBD37@china.huawei.com> Cc: ron.even.tlv@gmail.com, 'Tom Taylor' , avt@ietf.org, 'stephen botzko' Subject: Re: [AVT] Q for 3984bis-06 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 16:40:01 -0000 YK, An offer of level 1.3 is just an offer, it is not necessarily what the device can do. The reasons for offering a lower level can be due to multiple reasons, like some configuration of the terminal and not based on encoder/decoder performance. Having said that I would like to point out that in most cases you can get higher functionality by using other parameters like offering level 3.1 and using max-fs, max-br and max-cpb parameter to offer support for HD picture (using max-fs and max-cpb) at higher bit rate (based on max-br) which are over level 3.1 according to table A-1 in H.264. This is very typical in video conferencing applications if the offerer cannot support the maxBR for level 4 in table A-1. I think that in this case it is reasonable for the answer to signal level 4 since it gives similar resolution but hinting that it can encode and decode higher bit rate. This will not break interoperability and make it simpler for the answerer. Roni -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ye-Kui Wang Sent: Wednesday, May 20, 2009 7:07 PM To: 'Randell Jesup' Cc: ron.even.tlv@gmail.com; 'Tom Taylor'; 'stephen botzko'; avt@ietf.org Subject: Re: [AVT] Q for 3984bis-06 Typo: encoded -> decode. So, the sentence should be as follows. " The whole point is, if the offer contians level 1.3 (per 3984 or the bis draft) with sendrecv or no direction attribute, then level 1.3 is the highest it can both encoded and encode. In this case, it simply cannot encode above level 1.3. " BTW, it is not absolutely prohibited to change the semantics of profile-level-id, I am just saying that you need to change the semantics. In addition, if the encoding/sending capability and the decoding/receiving capability is different, both capabiilties should be expressed. One way is to use different direction attributes (and separate SDP), which was considered not perfect. The other way is, as I mentioned earlier, to use two parameters, one for each. BR, YK > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > Behalf Of Ye-Kui Wang > Sent: Wednesday, May 20, 2009 11:52 AM > To: 'Randell Jesup' > Cc: ron.even.tlv@gmail.com; 'stephen botzko'; avt@ietf.org; > 'Tom Taylor' > Subject: Re: [AVT] Q for 3984bis-06 > > > > For example, if the offer is 1.3 with > level-upgrade-allowed=1, and the > > answer is level 3.1, then the offerer can send at any level > up to and > > including level 3.1. It could send level 2.0 if that's the > highest it > > can encode. > > The whole point is, if the offer contians level 1.3 (per 3984 > or the bis > draft) with sendrecv or no direction attribute, then level > 1.3 is the highest it can both encoded and encode. In this > case, it simply cannot encode above level 1.3. > > Text in 3984: > If the profile-level-id parameter is used for > capability exchange or session setup > procedure, > it indicates the profile that the codec > supports and the highest level > supported for the signaled profile. > > BR, YK > > > -----Original Message----- > > From: Randell Jesup [mailto:rjesup@wgate.com] > > Sent: Wednesday, May 20, 2009 1:08 AM > > To: Ye-Kui Wang > > Cc: 'stephen botzko'; ron.even.tlv@gmail.com; 'Tom Taylor'; > > avt@ietf.org > > Subject: Re: [AVT] Q for 3984bis-06 > > > > Ye-Kui Wang writes: > > >> So, to summarize, if in response to an offer with > > >> level-upgrade-allowed=1, the answer includes a level > > higher than the > > >> offerer supports: > > >> > > >> * The offerer can encode a stream as if it's a higher > > level (including > > >> parameter sets), but using the encode settings of a > > lower level that > > >> it supports. > > > > > >So, in your interpretation, the offerer sending a higher > level just > > >means that it sends sequence parameter sets containing the higher > > >level, but the bitstream characteristics are still > restricted by the > > >lower level. How could this bring any practical usefulness? In the > > >example, offer includes level B (e.g. spatial resolution up > > to QVGA), > > >and the answer includes a higher level C (e.g. spatial > > resolution up to > > >VGA), then both sides still send and receive up to QVGA > > resolution, but > > >the offer includes sequence parameter sets include the level > > value C. Why is this useful at all? > > > > You asked a different question: > > > > >> >Now with the correct reading of the table. Again, that > > just makes a > > >> >difference on receiving or sending capability, not the > > conclusion. > > >> >You are basically assuming that the offerer's sending (i.e. > > >> >encoding) capability is not limited, i.e. it can send > > whatever high > > >> >level the answer may include. How can that assumption > be correct? > > > > You asked about sending at "whatever high level the answer may > > include". > > My response shows that you don't have to send at an > arbitrarily-high > > level > > - you can send at the highest level you support. > > > > For example, if the offer is 1.3 with > level-upgrade-allowed=1, and the > > answer is level 3.1, then the offerer can send at any level > up to and > > including level 3.1. It could send level 2.0 if that's the > highest it > > can encode. > > > > >BR, YK > > > > > >> -----Original Message----- > > >> From: Randell Jesup [mailto:rjesup@wgate.com] > > >> Sent: Wednesday, May 20, 2009 12:29 AM > > >> To: Ye-Kui Wang > > >> Cc: 'stephen botzko'; ron.even.tlv@gmail.com; 'Tom Taylor'; > > >> avt@ietf.org > > >> Subject: Re: [AVT] Q for 3984bis-06 > > >> > > >> Ye-Kui Wang writes: > > >> > > >> >I shortened the text. > > >> > > > >> >> If the offerer is legacy, then they don't include > > >> >> level-upgrade-allowed, and as stated the answerer is not > > >> allowed to > > >> >> upgrade the level. If the answerer is legacy, then they > > >> will ignore > > >> >> level-upgrade-allowed, and won't upgrade the level. So > > >> those 3 cases are all handled. > > >> > > > >> >OK. But it is possible that the answerer is new but does > > not want to > > >> >upgrade the level in an offer/answer process. It would be > > certainly > > >> >useful that the answerer lets the other side know whether it > > >> is new or > > >> >legacy. Therefore, I'd prefer to include > > >> level-upgrade-allowed equal to > > >> >1 if the device is new (does understand the parameter and > > >> allows level > > >> >upgrade). Note that something is allowed does not mean it > > is in use. > > >> > > >> The answerer could do that, and I don't have a problem > with it (it > > >> doesn't hurt anything), but I don't see how it's useful > in any way. > > >> > > >> >> >The conflict is at the offerer's side. It includes a > > lower level, > > >> >> >but you are proposing requires that the offerer can > > >> receive a higher > > >> >> >level. To do this, you must change the current semantics of > > >> >> >profile-level-id. > > >> >> > > >> >> No, unless we decide to take the option mentioned in my > > >> table (change > > >> >> it to "level-asymmetry-allowed"). Then (and only then) > > could the > > >> >> offerer could receive a level above what they offered. > > >> > > > >> >Sorry, I mis-read your table. But that just makes a > difference on > > >> >receiving or sending capability, not the conclusion. In the > > >> righ case > > >> >in the table (i.e. offer includes B, and answer > includes C). The > > >> >current semantics say that the offerer would only be able to > > >> send B and > > >> >lower. But you want the offerer to be able to send C which > > >> is higher than B. > > >> > > >> I don't understand what you're trying to say here. That's > > the point > > >> of level upgrade. And the offerer is still sending at a level > > >> specified in the answers profile-level-id. > > >> Perhaps you're just saying "yes, this means the offerer > > might end up > > >> sending a stream at a higher level than it offered", > which is the > > >> whole point of level upgrade. > > >> > > >> >> >> Perhaps this table will help: > > >> >> >> > > >> >> >> Offer is level "B". I'll use level "A" to indicate a > > >> lower level, > > >> >> >> and "C" for a higher one (A < B < C). I'm assuming > > the offer > > >> >> >> includes level-upgrade-allowed=1. > > >> >> >> > > >> >> >> > > >> >> >> Answer level: lower (A) same (B) > higher (C) > > >> >> >> > > >> >> >> Offerer can send: A B C > > >> >> >> Answerer can send: A* B B > > >> >> >> > > >> >> > > > >> >> >In the right case (the answer includes level C), what if the > > >> >> >offerer's receiveing capability is actually lower than C? > > >> >> > > >> >> Then they shouldn't answer with "C". They should answer with > > >> >> whatever level they do support. The point of this is > > to allow the > > >> >> answerer to offer to receive a higher level; they get to > > >> choose what > > >> >> that level is. > > >> > > > >> >Now with the correct reading of the table. Again, that > > just makes a > > >> >difference on receiving or sending capability, not the > > >> conclusion. You > > >> >are basically assuming that the offerer's sending (i.e. > encoding) > > >> >capability is not limited, i.e. it can send whatever high > > >> level the answer may include. > > >> >How can that assumption be correct? > > >> > > >> You need to think about how level works in H.264. > > >> > > >> Remember we're only changing level, not constraints or profiles. > > >> > > >> Levels imply details about the maximum frame size, maximum > > >> macroblocks per second, maximum bitrate, etc, and each > level is a > > >> superset of the next-lower level. Using a level doesn't > > mean you (as > > >> an encoder) have to hit those maximums. If you encode a > > stream using > > >> the parameters of a lower level (i.e. > > >> using lower maximums), it's decodable by a higher-level > > decoder, even > > >> if you set the parameter sets to the higher level. > > >> > > >> Even more importantly, there's no apparent requirement to send > > >> exactly the level given by the profile-level-id; sending > > lower levels > > >> (with the correct profile and constraints) appears to be > just fine > > >> (note that this interacts with parameter-set handling - > > you need to > > >> deal with making sure the decoder has correct parameter > > sets, as you > > >> always do). > > >> > > >> From 3984: > > >> > > >> If the profile-level-id parameter is used to indicate > > properties > > >> of a > > >> NAL unit stream, it indicates the profile and level > > that a decoder > > >> has > > >> to support in order to comply with [1] when it decodes > > the stream. > > >> > > >> and > > >> > > >> If the profile-level-id parameter is used for > > capability exchange > > >> or > > >> session setup procedure, it indicates the profile > that the codec > > >> supports and the highest level supported for the > > signaled profile. > > >> > > >> Note "highest level". And: > > >> > > >> The level conveyed in the value of the profile-level-id > > parameter > > >> MUST > > >> be such that the receiver is fully capable of supporting. > > >> > > >> and > > >> o Parameters used for declaring receiver capabilities are in > > >> general > > >> downgradable; i.e., they express the upper limit for > > a sender's > > >> possible behavior. Thus a sender MAY select to set > > its encoder > > >> using only lower/lesser or equal values of these > parameters. > > >> [snip] > > >> o Parameters declaring a configuration point are not > > downgradable, > > >> with the exception of the level part of the > > "profile-level-id" > > >> parameter. This expresses values a receiver expects > > to be used > > >> and must be used verbatim on the sender side. > > >> > > >> > > >> So, to summarize, if in response to an offer with > > >> level-upgrade-allowed=1, the answer includes a level > > higher than the > > >> offerer supports: > > >> > > >> * The offerer can encode a stream as if it's a higher > > level (including > > >> parameter sets), but using the encode settings of a > lower level > > >> that it > > >> supports. > > >> * The offerer can encode a stream using a lower level, including > > >> lower-level parameter sets. > > >> > > >> In both cases, the parameter sets must be conveyed to the > > answerer in > > >> some manner; the mechanisms that would make the most sense are > > >> in-band parameter sets (with all that implies), or using > > >> sprop-level-parameter-sets including levels above the > level in the > > >> offered profile-level-id, so that the answer can select > > one of those > > >> levels and thus install those parameter sets. > > >> > > >> None of this requires any further modification to 3984bis > > that I can > > >> see - just allowing level-upgrade-allowed (or > > >> level-asymmetric-allowed). > > >> > > >> -- > > >> Randell Jesup, Worldgate (developers of the Ojo > > videophone), ex-Amiga > > >> OS team rjesup@wgate.com "The fetters imposed on liberty > > at home have > > >> ever been forged out of the weapons provided for defence against > > >> real, pretended, or imaginary dangers from abroad." > > >> - James Madison, 4th US president (1751-1836) > > >> > > >> > > > > > > -- > > Randell Jesup, Worldgate (developers of the Ojo > videophone), ex-Amiga > > OS team rjesup@wgate.com "The fetters imposed on liberty at > home have > > ever been forged out of the weapons provided for defence > against real, > > pretended, or imaginary dangers from abroad." > > - James Madison, 4th US president (1751-1836) > > > > > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www.ietf.org/mailman/listinfo/avt From yekuiwang@huawei.com Wed May 20 10:23:25 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1502A3A6A7D for ; Wed, 20 May 2009 10:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[AWL=0.326, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXl+4klSqu94 for ; Wed, 20 May 2009 10:23:21 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 3880D3A6B57 for ; Wed, 20 May 2009 10:23:21 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJY0020WDPLQC@usaga04-in.huawei.com> for avt@ietf.org; Wed, 20 May 2009 12:24:57 -0500 (CDT) Received: from W90946 ([10.51.0.1]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJY00DHDDPF1D@usaga04-in.huawei.com> for avt@ietf.org; Wed, 20 May 2009 12:24:57 -0500 (CDT) Date: Wed, 20 May 2009 13:24:49 -0400 From: Ye-Kui Wang In-reply-to: <001501c9d969$b8966fb0$29c34f10$%roni@huawei.com> To: 'Roni Even' , 'Randell Jesup' Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcnZCPICoe11EvE0SWm5FzsO7f0Y0AAWLd3wAAB7VEAAAMVlMAACBtvQ iPlanet-SMTP-Warning: Lines longer than SMTP allows found and truncated. References: <04CAD96D4C5A3D48B1919248A8FE0D540943CDB9@xmb-sjc-215.amer.cisco.com> <2713212F2F334A15AB3DB03E1BB45156@china.huawei.com> <4A092C12.8080704@rogers.com> <5E07A2E74C0749B7A84371EE422E90C6@china.huawei.com> <545DD1B15C9A42F0B1729CC02FFC6348@china.huawei.com> <2068ACFCE9FA4013865E833F38057DDB@china.huawei.com> <6e9223710905190853p133b630cud234027c753916ed@mail.gmail.com> <686CE89178A540B3BBFD761A3DEBC494@china.huawei.com> <1C47D7182AB24F758DC60913784EBD37@china.huawei.com> Cc: ron.even.tlv@gmail.com, 'Tom Taylor' , avt@ietf.org, 'stephen botzko' Subject: Re: [AVT] Q for 3984bis-06 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 17:23:25 -0000 Roni, > -----Original Message----- > From: Roni Even [mailto:Even.roni@huawei.com] > Sent: Wednesday, May 20, 2009 12:41 PM > To: 'Ye-Kui Wang'; 'Randell Jesup' > Cc: ron.even.tlv@gmail.com; 'Tom Taylor'; 'stephen botzko'; > avt@ietf.org > Subject: RE: [AVT] Q for 3984bis-06 > > YK, > An offer of level 1.3 is just an offer, it is not necessarily > what the device can do. The reasons for offering a lower > level can be due to multiple reasons, like some configuration > of the terminal and not based on encoder/decoder performance. > If this is the case, then the current semantics of profile-level-id is simply incorrect as it reads. > Having said that I would like to point out that in most cases > you can get higher functionality by using other parameters > like offering level 3.1 and using max-fs, max-br and max-cpb > parameter to offer support for HD picture (using max-fs and > max-cpb) at higher bit rate (based on max-br) which are over > level 3.1 according to table A-1 in H.264. This is very > typical in video conferencing applications if the offerer > cannot support the maxBR for level 4 in table A-1. Correct. > I think that in this case it is reasonable for the answer to > signal level 4 since it gives similar resolution but hinting > that it can encode and decode higher bit rate. This will not > break interoperability and make it simpler for the answerer. I don't think this is correct according to either RFC 3984 or the bis. As you said earlier, it is allowed to signal level 3.1, and to use those max-* parameters to indicate that the device has higher than 3.1 capability in a particular aspect, but not the other way round. If you signal level 4, there is no way to tell which aspect of the capability is lower than level 4. This is simply not what the spec says. If you think this way should be supported, you must propose it and make it said in the spec. BR, YK > > Roni > > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > Behalf Of Ye-Kui Wang > Sent: Wednesday, May 20, 2009 7:07 PM > To: 'Randell Jesup' > Cc: ron.even.tlv@gmail.com; 'Tom Taylor'; 'stephen botzko'; > avt@ietf.org > Subject: Re: [AVT] Q for 3984bis-06 > > > Typo: encoded -> decode. So, the sentence should be as follows. > > " The whole point is, if the offer contians level 1.3 (per > 3984 or the bis > draft) with sendrecv or no direction attribute, then level > 1.3 is the highest it can both encoded and encode. In this > case, it simply cannot encode above level 1.3. " > > BTW, it is not absolutely prohibited to change the semantics > of profile-level-id, I am just saying that you need to change > the semantics. In addition, if the encoding/sending > capability and the decoding/receiving capability is > different, both capabiilties should be expressed. One way is > to use different direction attributes (and separate SDP), > which was considered not perfect. The other way is, as I > mentioned earlier, to use two parameters, one for each. > > BR, YK > > > -----Original Message----- > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > Behalf Of > > Ye-Kui Wang > > Sent: Wednesday, May 20, 2009 11:52 AM > > To: 'Randell Jesup' > > Cc: ron.even.tlv@gmail.com; 'stephen botzko'; avt@ietf.org; 'Tom > > Taylor' > > Subject: Re: [AVT] Q for 3984bis-06 > > > > > > > For example, if the offer is 1.3 with > > level-upgrade-allowed=1, and the > > > answer is level 3.1, then the offerer can send at any level > > up to and > > > including level 3.1. It could send level 2.0 if that's the > > highest it > > > can encode. > > > > The whole point is, if the offer contians level 1.3 (per > 3984 or the > > bis > > draft) with sendrecv or no direction attribute, then level > > 1.3 is the highest it can both encoded and encode. In this case, it > > simply cannot encode above level 1.3. > > > > Text in 3984: > > If the profile-level-id parameter > is used for > > capability exchange or session setup > > procedure, > > it indicates the profile that the codec > > supports and the highest level > > supported for the signaled profile. > > > > BR, YK > > > > > -----Original Message----- > > > From: Randell Jesup [mailto:rjesup@wgate.com] > > > Sent: Wednesday, May 20, 2009 1:08 AM > > > To: Ye-Kui Wang > > > Cc: 'stephen botzko'; ron.even.tlv@gmail.com; 'Tom Taylor'; > > > avt@ietf.org > > > Subject: Re: [AVT] Q for 3984bis-06 > > > > > > Ye-Kui Wang writes: > > > >> So, to summarize, if in response to an offer with > > > >> level-upgrade-allowed=1, the answer includes a level > > > higher than the > > > >> offerer supports: > > > >> > > > >> * The offerer can encode a stream as if it's a higher > > > level (including > > > >> parameter sets), but using the encode settings of a > > > lower level that > > > >> it supports. > > > > > > > >So, in your interpretation, the offerer sending a higher > > level just > > > >means that it sends sequence parameter sets containing > the higher > > > >level, but the bitstream characteristics are still > > restricted by the > > > >lower level. How could this bring any practical > usefulness? In the > > > >example, offer includes level B (e.g. spatial resolution up > > > to QVGA), > > > >and the answer includes a higher level C (e.g. spatial > > > resolution up to > > > >VGA), then both sides still send and receive up to QVGA > > > resolution, but > > > >the offer includes sequence parameter sets include the level > > > value C. Why is this useful at all? > > > > > > You asked a different question: > > > > > > >> >Now with the correct reading of the table. Again, that > > > just makes a > > > >> >difference on receiving or sending capability, not the > > > conclusion. > > > >> >You are basically assuming that the offerer's sending (i.e. > > > >> >encoding) capability is not limited, i.e. it can send > > > whatever high > > > >> >level the answer may include. How can that assumption > > be correct? > > > > > > You asked about sending at "whatever high level the answer may > > > include". > > > My response shows that you don't have to send at an > > arbitrarily-high > > > level > > > - you can send at the highest level you support. > > > > > > For example, if the offer is 1.3 with > > level-upgrade-allowed=1, and the > > > answer is level 3.1, then the offerer can send at any level > > up to and > > > including level 3.1. It could send level 2.0 if that's the > > highest it > > > can encode. > > > > > > >BR, YK > > > > > > > >> -----Original Message----- > > > >> From: Randell Jesup [mailto:rjesup@wgate.com] > > > >> Sent: Wednesday, May 20, 2009 12:29 AM > > > >> To: Ye-Kui Wang > > > >> Cc: 'stephen botzko'; ron.even.tlv@gmail.com; 'Tom Taylor'; > > > >> avt@ietf.org > > > >> Subject: Re: [AVT] Q for 3984bis-06 > > > >> > > > >> Ye-Kui Wang writes: > > > >> > > > >> >I shortened the text. > > > >> > > > > >> >> If the offerer is legacy, then they don't include > > > >> >> level-upgrade-allowed, and as stated the answerer is not > > > >> allowed to > > > >> >> upgrade the level. If the answerer is legacy, then they > > > >> will ignore > > > >> >> level-upgrade-allowed, and won't upgrade the level. So > > > >> those 3 cases are all handled. > > > >> > > > > >> >OK. But it is possible that the answerer is new but does > > > not want to > > > >> >upgrade the level in an offer/answer process. It would be > > > certainly > > > >> >useful that the answerer lets the other side know whether it > > > >> is new or > > > >> >legacy. Therefore, I'd prefer to include > > > >> level-upgrade-allowed equal to > > > >> >1 if the device is new (does understand the parameter and > > > >> allows level > > > >> >upgrade). Note that something is allowed does not mean it > > > is in use. > > > >> > > > >> The answerer could do that, and I don't have a problem > > with it (it > > > >> doesn't hurt anything), but I don't see how it's useful > > in any way. > > > >> > > > >> >> >The conflict is at the offerer's side. It includes a > > > lower level, > > > >> >> >but you are proposing requires that the offerer can > > > >> receive a higher > > > >> >> >level. To do this, you must change the current > semantics of > > > >> >> >profile-level-id. > > > >> >> > > > >> >> No, unless we decide to take the option mentioned in my > > > >> table (change > > > >> >> it to "level-asymmetry-allowed"). Then (and only then) > > > could the > > > >> >> offerer could receive a level above what they offered. > > > >> > > > > >> >Sorry, I mis-read your table. But that just makes a > > difference on > > > >> >receiving or sending capability, not the conclusion. In the > > > >> righ case > > > >> >in the table (i.e. offer includes B, and answer > > includes C). The > > > >> >current semantics say that the offerer would only be able to > > > >> send B and > > > >> >lower. But you want the offerer to be able to send C which > > > >> is higher than B. > > > >> > > > >> I don't understand what you're trying to say here. That's > > > the point > > > >> of level upgrade. And the offerer is still sending at a level > > > >> specified in the answers profile-level-id. > > > >> Perhaps you're just saying "yes, this means the offerer > > > might end up > > > >> sending a stream at a higher level than it offered", > > which is the > > > >> whole point of level upgrade. > > > >> > > > >> >> >> Perhaps this table will help: > > > >> >> >> > > > >> >> >> Offer is level "B". I'll use level "A" to indicate a > > > >> lower level, > > > >> >> >> and "C" for a higher one (A < B < C). I'm assuming > > > the offer > > > >> >> >> includes level-upgrade-allowed=1. > > > >> >> >> > > > >> >> >> > > > >> >> >> Answer level: lower (A) same (B) > > higher (C) > > > >> >> >> > > > >> >> >> Offerer can send: A B C > > > >> >> >> Answerer can send: A* B B > > > >> >> >> > > > >> >> > > > > >> >> >In the right case (the answer includes level C), > what if the > > > >> >> >offerer's receiveing capability is actually lower than C? > > > >> >> > > > >> >> Then they shouldn't answer with "C". They should > answer with > > > >> >> whatever level they do support. The point of this is > > > to allow the > > > >> >> answerer to offer to receive a higher level; they get to > > > >> choose what > > > >> >> that level is. > > > >> > > > > >> >Now with the correct reading of the table. Again, that > > > just makes a > > > >> >difference on receiving or sending capability, not the > > > >> conclusion. You > > > >> >are basically assuming that the offerer's sending (i.e. > > encoding) > > > >> >capability is not limited, i.e. it can send whatever high > > > >> level the answer may include. > > > >> >How can that assumption be correct? > > > >> > > > >> You need to think about how level works in H.264. > > > >> > > > >> Remember we're only changing level, not constraints or > profiles. > > > >> > > > >> Levels imply details about the maximum frame size, maximum > > > >> macroblocks per second, maximum bitrate, etc, and each > > level is a > > > >> superset of the next-lower level. Using a level doesn't > > > mean you (as > > > >> an encoder) have to hit those maximums. If you encode a > > > stream using > > > >> the parameters of a lower level (i.e. > > > >> using lower maximums), it's decodable by a higher-level > > > decoder, even > > > >> if you set the parameter sets to the higher level. > > > >> > > > >> Even more importantly, there's no apparent requirement to send > > > >> exactly the level given by the profile-level-id; sending > > > lower levels > > > >> (with the correct profile and constraints) appears to be > > just fine > > > >> (note that this interacts with parameter-set handling - > > > you need to > > > >> deal with making sure the decoder has correct parameter > > > sets, as you > > > >> always do). > > > >> > > > >> From 3984: > > > >> > > > >> If the profile-level-id parameter is used to indicate > > > properties > > > >> of a > > > >> NAL unit stream, it indicates the profile and level > > > that a decoder > > > >> has > > > >> to support in order to comply with [1] when it decodes > > > the stream. > > > >> > > > >> and > > > >> > > > >> If the profile-level-id parameter is used for > > > capability exchange > > > >> or > > > >> session setup procedure, it indicates the profile > > that the codec > > > >> supports and the highest level supported for the > > > signaled profile. > > > >> > > > >> Note "highest level". And: > > > >> > > > >> The level conveyed in the value of the profile-level-id > > > parameter > > > >> MUST > > > >> be such that the receiver is fully capable of supporting. > > > >> > > > >> and > > > >> o Parameters used for declaring receiver > capabilities are in > > > >> general > > > >> downgradable; i.e., they express the upper limit for > > > a sender's > > > >> possible behavior. Thus a sender MAY select to set > > > its encoder > > > >> using only lower/lesser or equal values of these > > parameters. > > > >> [snip] > > > >> o Parameters declaring a configuration point are not > > > downgradable, > > > >> with the exception of the level part of the > > > "profile-level-id" > > > >> parameter. This expresses values a receiver expects > > > to be used > > > >> and must be used verbatim on the sender side. > > > >> > > > >> > > > >> So, to summarize, if in response to an offer with > > > >> level-upgrade-allowed=1, the answer includes a level > > > higher than the > > > >> offerer supports: > > > >> > > > >> * The offerer can encode a stream as if it's a higher > > > level (including > > > >> parameter sets), but using the encode settings of a > > lower level > > > >> that it > > > >> supports. > > > >> * The offerer can encode a stream using a lower level, > including > > > >> lower-level parameter sets. > > > >> > > > >> In both cases, the parameter sets must be conveyed to the > > > answerer in > > > >> some manner; the mechanisms that would make the most sense are > > > >> in-band parameter sets (with all that implies), or using > > > >> sprop-level-parameter-sets including levels above the > > level in the > > > >> offered profile-level-id, so that the answer can select > > > one of those > > > >> levels and thus install those parameter sets. > > > >> > > > >> None of this requires any further modification to 3984bis > > > that I can > > > >> see - just allowing level-upgrade-allowed (or > > > >> level-asymmetric-allowed). > > > >> > > > >> -- > > > >> Randell Jesup, Worldgate (developers of the Ojo > > > videophone), ex-Amiga > > > >> OS team rjesup@wgate.com "The fetters imposed on liberty > > > at home have > > > >> ever been forged out of the weapons provided for > defence against > > > >> real, pretended, or imaginary dangers from abroad." > > > >> - James Madison, 4th US president (1751-1836) > > > >> > > > >> > > > > > > > > > -- > > > Randell Jesup, Worldgate (developers of the Ojo > > videophone), ex-Amiga > > > OS team rjesup@wgate.com "The fetters imposed on liberty at > > home have > > > ever been forged out of the weapons provided for defence > > against real, > > > pretended, or imaginary dangers from abroad." > > > - James Madison, 4th US president (1751-1836) > > > > > > > > > > > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > > > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > > From Even.roni@huawei.com Wed May 20 10:59:11 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42A423A6EB4 for ; Wed, 20 May 2009 10:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.073 X-Spam-Level: X-Spam-Status: No, score=-2.073 tagged_above=-999 required=5 tests=[AWL=0.526, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CU60YfxysM32 for ; Wed, 20 May 2009 10:59:09 -0700 (PDT) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id E9EE13A6E1F for ; Wed, 20 May 2009 10:59:08 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJY00KDKFD81E@szxga02-in.huawei.com> for avt@ietf.org; Thu, 21 May 2009 02:00:45 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJY00GJUFD8Q0@szxga02-in.huawei.com> for avt@ietf.org; Thu, 21 May 2009 02:00:44 +0800 (CST) Received: from windows8d787f9 (bzq-79-181-118-116.red.bezeqint.net [79.181.118.116]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJY001GZFCS5X@szxml01-in.huawei.com>; Thu, 21 May 2009 02:00:44 +0800 (CST) Date: Wed, 20 May 2009 20:59:42 +0300 From: Roni Even In-reply-to: To: 'Ye-Kui Wang' , 'Randell Jesup' Message-id: <003401c9d974$cb70c990$62525cb0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcnZCPICoe11EvE0SWm5FzsO7f0Y0AAWLd3wAAB7VEAAAMVlMAACBtvQAAESjxA= iPlanet-SMTP-Warning: Lines longer than SMTP allows found and truncated. References: <04CAD96D4C5A3D48B1919248A8FE0D540943CDB9@xmb-sjc-215.amer.cisco.com> <2713212F2F334A15AB3DB03E1BB45156@china.huawei.com> <4A092C12.8080704@rogers.com> <5E07A2E74C0749B7A84371EE422E90C6@china.huawei.com> <545DD1B15C9A42F0B1729CC02FFC6348@china.huawei.com> <2068ACFCE9FA4013865E833F38057DDB@china.huawei.com> <6e9223710905190853p133b630cud234027c753916ed@mail.gmail.com> <686CE89178A540B3BBFD761A3DEBC494@china.huawei.com> <1C47D7182AB24F758DC60913784EBD37@china.huawei.com> Cc: ron.even.tlv@gmail.com, 'Tom Taylor' , avt@ietf.org, 'stephen botzko' Subject: Re: [AVT] Q for 3984bis-06 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 17:59:11 -0000 YK, The semantics of the parameters now is correct, what I was saying is that there may be a difference between what a device is offering and what the device can do in terms of processing, this can happen due to other decisions like configuration and it may go higher if the other side indicates that it can do so. I think allowing level upgrade by the answerer is what all the people discussing the topic draft are suggesting (Ingemar, Randell, Jonathan, Magnus and others). I just gave another example where it can happen. Maybe clarify that the level is a receive capability will help. Jonathan Lennox even suggests " Architecturally, I think it would be cleanest if H.264's non sprop-* parameters all have SDP's standard receive-side semantics, rather than offer/answer semantics." Roni Even -----Original Message----- From: Ye-Kui Wang [mailto:yekuiwang@huawei.com] Sent: Wednesday, May 20, 2009 8:25 PM To: 'Roni Even'; 'Randell Jesup' Cc: ron.even.tlv@gmail.com; 'Tom Taylor'; 'stephen botzko'; avt@ietf.org Subject: RE: [AVT] Q for 3984bis-06 Roni, > -----Original Message----- > From: Roni Even [mailto:Even.roni@huawei.com] > Sent: Wednesday, May 20, 2009 12:41 PM > To: 'Ye-Kui Wang'; 'Randell Jesup' > Cc: ron.even.tlv@gmail.com; 'Tom Taylor'; 'stephen botzko'; > avt@ietf.org > Subject: RE: [AVT] Q for 3984bis-06 > > YK, > An offer of level 1.3 is just an offer, it is not necessarily > what the device can do. The reasons for offering a lower > level can be due to multiple reasons, like some configuration > of the terminal and not based on encoder/decoder performance. > If this is the case, then the current semantics of profile-level-id is simply incorrect as it reads. > Having said that I would like to point out that in most cases > you can get higher functionality by using other parameters > like offering level 3.1 and using max-fs, max-br and max-cpb > parameter to offer support for HD picture (using max-fs and > max-cpb) at higher bit rate (based on max-br) which are over > level 3.1 according to table A-1 in H.264. This is very > typical in video conferencing applications if the offerer > cannot support the maxBR for level 4 in table A-1. Correct. > I think that in this case it is reasonable for the answer to > signal level 4 since it gives similar resolution but hinting > that it can encode and decode higher bit rate. This will not > break interoperability and make it simpler for the answerer. I don't think this is correct according to either RFC 3984 or the bis. As you said earlier, it is allowed to signal level 3.1, and to use those max-* parameters to indicate that the device has higher than 3.1 capability in a particular aspect, but not the other way round. If you signal level 4, there is no way to tell which aspect of the capability is lower than level 4. This is simply not what the spec says. If you think this way should be supported, you must propose it and make it said in the spec. BR, YK > > Roni > > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > Behalf Of Ye-Kui Wang > Sent: Wednesday, May 20, 2009 7:07 PM > To: 'Randell Jesup' > Cc: ron.even.tlv@gmail.com; 'Tom Taylor'; 'stephen botzko'; > avt@ietf.org > Subject: Re: [AVT] Q for 3984bis-06 > > > Typo: encoded -> decode. So, the sentence should be as follows. > > " The whole point is, if the offer contians level 1.3 (per > 3984 or the bis > draft) with sendrecv or no direction attribute, then level > 1.3 is the highest it can both encoded and encode. In this > case, it simply cannot encode above level 1.3. " > > BTW, it is not absolutely prohibited to change the semantics > of profile-level-id, I am just saying that you need to change > the semantics. In addition, if the encoding/sending > capability and the decoding/receiving capability is > different, both capabiilties should be expressed. One way is > to use different direction attributes (and separate SDP), > which was considered not perfect. The other way is, as I > mentioned earlier, to use two parameters, one for each. > > BR, YK > > > -----Original Message----- > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > Behalf Of > > Ye-Kui Wang > > Sent: Wednesday, May 20, 2009 11:52 AM > > To: 'Randell Jesup' > > Cc: ron.even.tlv@gmail.com; 'stephen botzko'; avt@ietf.org; 'Tom > > Taylor' > > Subject: Re: [AVT] Q for 3984bis-06 > > > > > > > For example, if the offer is 1.3 with > > level-upgrade-allowed=1, and the > > > answer is level 3.1, then the offerer can send at any level > > up to and > > > including level 3.1. It could send level 2.0 if that's the > > highest it > > > can encode. > > > > The whole point is, if the offer contians level 1.3 (per > 3984 or the > > bis > > draft) with sendrecv or no direction attribute, then level > > 1.3 is the highest it can both encoded and encode. In this case, it > > simply cannot encode above level 1.3. > > > > Text in 3984: > > If the profile-level-id parameter > is used for > > capability exchange or session setup > > procedure, > > it indicates the profile that the codec > > supports and the highest level > > supported for the signaled profile. > > > > BR, YK > > > > > -----Original Message----- > > > From: Randell Jesup [mailto:rjesup@wgate.com] > > > Sent: Wednesday, May 20, 2009 1:08 AM > > > To: Ye-Kui Wang > > > Cc: 'stephen botzko'; ron.even.tlv@gmail.com; 'Tom Taylor'; > > > avt@ietf.org > > > Subject: Re: [AVT] Q for 3984bis-06 > > > > > > Ye-Kui Wang writes: > > > >> So, to summarize, if in response to an offer with > > > >> level-upgrade-allowed=1, the answer includes a level > > > higher than the > > > >> offerer supports: > > > >> > > > >> * The offerer can encode a stream as if it's a higher > > > level (including > > > >> parameter sets), but using the encode settings of a > > > lower level that > > > >> it supports. > > > > > > > >So, in your interpretation, the offerer sending a higher > > level just > > > >means that it sends sequence parameter sets containing > the higher > > > >level, but the bitstream characteristics are still > > restricted by the > > > >lower level. How could this bring any practical > usefulness? In the > > > >example, offer includes level B (e.g. spatial resolution up > > > to QVGA), > > > >and the answer includes a higher level C (e.g. spatial > > > resolution up to > > > >VGA), then both sides still send and receive up to QVGA > > > resolution, but > > > >the offer includes sequence parameter sets include the level > > > value C. Why is this useful at all? > > > > > > You asked a different question: > > > > > > >> >Now with the correct reading of the table. Again, that > > > just makes a > > > >> >difference on receiving or sending capability, not the > > > conclusion. > > > >> >You are basically assuming that the offerer's sending (i.e. > > > >> >encoding) capability is not limited, i.e. it can send > > > whatever high > > > >> >level the answer may include. How can that assumption > > be correct? > > > > > > You asked about sending at "whatever high level the answer may > > > include". > > > My response shows that you don't have to send at an > > arbitrarily-high > > > level > > > - you can send at the highest level you support. > > > > > > For example, if the offer is 1.3 with > > level-upgrade-allowed=1, and the > > > answer is level 3.1, then the offerer can send at any level > > up to and > > > including level 3.1. It could send level 2.0 if that's the > > highest it > > > can encode. > > > > > > >BR, YK > > > > > > > >> -----Original Message----- > > > >> From: Randell Jesup [mailto:rjesup@wgate.com] > > > >> Sent: Wednesday, May 20, 2009 12:29 AM > > > >> To: Ye-Kui Wang > > > >> Cc: 'stephen botzko'; ron.even.tlv@gmail.com; 'Tom Taylor'; > > > >> avt@ietf.org > > > >> Subject: Re: [AVT] Q for 3984bis-06 > > > >> > > > >> Ye-Kui Wang writes: > > > >> > > > >> >I shortened the text. > > > >> > > > > >> >> If the offerer is legacy, then they don't include > > > >> >> level-upgrade-allowed, and as stated the answerer is not > > > >> allowed to > > > >> >> upgrade the level. If the answerer is legacy, then they > > > >> will ignore > > > >> >> level-upgrade-allowed, and won't upgrade the level. So > > > >> those 3 cases are all handled. > > > >> > > > > >> >OK. But it is possible that the answerer is new but does > > > not want to > > > >> >upgrade the level in an offer/answer process. It would be > > > certainly > > > >> >useful that the answerer lets the other side know whether it > > > >> is new or > > > >> >legacy. Therefore, I'd prefer to include > > > >> level-upgrade-allowed equal to > > > >> >1 if the device is new (does understand the parameter and > > > >> allows level > > > >> >upgrade). Note that something is allowed does not mean it > > > is in use. > > > >> > > > >> The answerer could do that, and I don't have a problem > > with it (it > > > >> doesn't hurt anything), but I don't see how it's useful > > in any way. > > > >> > > > >> >> >The conflict is at the offerer's side. It includes a > > > lower level, > > > >> >> >but you are proposing requires that the offerer can > > > >> receive a higher > > > >> >> >level. To do this, you must change the current > semantics of > > > >> >> >profile-level-id. > > > >> >> > > > >> >> No, unless we decide to take the option mentioned in my > > > >> table (change > > > >> >> it to "level-asymmetry-allowed"). Then (and only then) > > > could the > > > >> >> offerer could receive a level above what they offered. > > > >> > > > > >> >Sorry, I mis-read your table. But that just makes a > > difference on > > > >> >receiving or sending capability, not the conclusion. In the > > > >> righ case > > > >> >in the table (i.e. offer includes B, and answer > > includes C). The > > > >> >current semantics say that the offerer would only be able to > > > >> send B and > > > >> >lower. But you want the offerer to be able to send C which > > > >> is higher than B. > > > >> > > > >> I don't understand what you're trying to say here. That's > > > the point > > > >> of level upgrade. And the offerer is still sending at a level > > > >> specified in the answers profile-level-id. > > > >> Perhaps you're just saying "yes, this means the offerer > > > might end up > > > >> sending a stream at a higher level than it offered", > > which is the > > > >> whole point of level upgrade. > > > >> > > > >> >> >> Perhaps this table will help: > > > >> >> >> > > > >> >> >> Offer is level "B". I'll use level "A" to indicate a > > > >> lower level, > > > >> >> >> and "C" for a higher one (A < B < C). I'm assuming > > > the offer > > > >> >> >> includes level-upgrade-allowed=1. > > > >> >> >> > > > >> >> >> > > > >> >> >> Answer level: lower (A) same (B) > > higher (C) > > > >> >> >> > > > >> >> >> Offerer can send: A B C > > > >> >> >> Answerer can send: A* B B > > > >> >> >> > > > >> >> > > > > >> >> >In the right case (the answer includes level C), > what if the > > > >> >> >offerer's receiveing capability is actually lower than C? > > > >> >> > > > >> >> Then they shouldn't answer with "C". They should > answer with > > > >> >> whatever level they do support. The point of this is > > > to allow the > > > >> >> answerer to offer to receive a higher level; they get to > > > >> choose what > > > >> >> that level is. > > > >> > > > > >> >Now with the correct reading of the table. Again, that > > > just makes a > > > >> >difference on receiving or sending capability, not the > > > >> conclusion. You > > > >> >are basically assuming that the offerer's sending (i.e. > > encoding) > > > >> >capability is not limited, i.e. it can send whatever high > > > >> level the answer may include. > > > >> >How can that assumption be correct? > > > >> > > > >> You need to think about how level works in H.264. > > > >> > > > >> Remember we're only changing level, not constraints or > profiles. > > > >> > > > >> Levels imply details about the maximum frame size, maximum > > > >> macroblocks per second, maximum bitrate, etc, and each > > level is a > > > >> superset of the next-lower level. Using a level doesn't > > > mean you (as > > > >> an encoder) have to hit those maximums. If you encode a > > > stream using > > > >> the parameters of a lower level (i.e. > > > >> using lower maximums), it's decodable by a higher-level > > > decoder, even > > > >> if you set the parameter sets to the higher level. > > > >> > > > >> Even more importantly, there's no apparent requirement to send > > > >> exactly the level given by the profile-level-id; sending > > > lower levels > > > >> (with the correct profile and constraints) appears to be > > just fine > > > >> (note that this interacts with parameter-set handling - > > > you need to > > > >> deal with making sure the decoder has correct parameter > > > sets, as you > > > >> always do). > > > >> > > > >> From 3984: > > > >> > > > >> If the profile-level-id parameter is used to indicate > > > properties > > > >> of a > > > >> NAL unit stream, it indicates the profile and level > > > that a decoder > > > >> has > > > >> to support in order to comply with [1] when it decodes > > > the stream. > > > >> > > > >> and > > > >> > > > >> If the profile-level-id parameter is used for > > > capability exchange > > > >> or > > > >> session setup procedure, it indicates the profile > > that the codec > > > >> supports and the highest level supported for the > > > signaled profile. > > > >> > > > >> Note "highest level". And: > > > >> > > > >> The level conveyed in the value of the profile-level-id > > > parameter > > > >> MUST > > > >> be such that the receiver is fully capable of supporting. > > > >> > > > >> and > > > >> o Parameters used for declaring receiver > capabilities are in > > > >> general > > > >> downgradable; i.e., they express the upper limit for > > > a sender's > > > >> possible behavior. Thus a sender MAY select to set > > > its encoder > > > >> using only lower/lesser or equal values of these > > parameters. > > > >> [snip] > > > >> o Parameters declaring a configuration point are not > > > downgradable, > > > >> with the exception of the level part of the > > > "profile-level-id" > > > >> parameter. This expresses values a receiver expects > > > to be used > > > >> and must be used verbatim on the sender side. > > > >> > > > >> > > > >> So, to summarize, if in response to an offer with > > > >> level-upgrade-allowed=1, the answer includes a level > > > higher than the > > > >> offerer supports: > > > >> > > > >> * The offerer can encode a stream as if it's a higher > > > level (including > > > >> parameter sets), but using the encode settings of a > > lower level > > > >> that it > > > >> supports. > > > >> * The offerer can encode a stream using a lower level, > including > > > >> lower-level parameter sets. > > > >> > > > >> In both cases, the parameter sets must be conveyed to the > > > answerer in > > > >> some manner; the mechanisms that would make the most sense are > > > >> in-band parameter sets (with all that implies), or using > > > >> sprop-level-parameter-sets including levels above the > > level in the > > > >> offered profile-level-id, so that the answer can select > > > one of those > > > >> levels and thus install those parameter sets. > > > >> > > > >> None of this requires any further modification to 3984bis > > > that I can > > > >> see - just allowing level-upgrade-allowed (or > > > >> level-asymmetric-allowed). > > > >> > > > >> -- > > > >> Randell Jesup, Worldgate (developers of the Ojo > > > videophone), ex-Amiga > > > >> OS team rjesup@wgate.com "The fetters imposed on liberty > > > at home have > > > >> ever been forged out of the weapons provided for > defence against > > > >> real, pretended, or imaginary dangers from abroad." > > > >> - James Madison, 4th US president (1751-1836) > > > >> > > > >> > > > > > > > > > -- > > > Randell Jesup, Worldgate (developers of the Ojo > > videophone), ex-Amiga > > > OS team rjesup@wgate.com "The fetters imposed on liberty at > > home have > > > ever been forged out of the weapons provided for defence > > against real, > > > pretended, or imaginary dangers from abroad." > > > - James Madison, 4th US president (1751-1836) > > > > > > > > > > > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > > > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > > From yekuiwang@huawei.com Wed May 20 11:09:43 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9B183A70A7 for ; Wed, 20 May 2009 11:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.282 X-Spam-Level: X-Spam-Status: No, score=-2.282 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ISUzKNs+ZxQ for ; Wed, 20 May 2009 11:09:41 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id C81613A7099 for ; Wed, 20 May 2009 11:09:41 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJY00C0QFUUI4@usaga02-in.huawei.com> for avt@ietf.org; Wed, 20 May 2009 11:11:18 -0700 (PDT) Received: from W90946 ([10.51.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJY00KL4FUO5S@usaga02-in.huawei.com> for avt@ietf.org; Wed, 20 May 2009 11:11:18 -0700 (PDT) Date: Wed, 20 May 2009 14:11:10 -0400 From: Ye-Kui Wang In-reply-to: <003401c9d974$cb70c990$62525cb0$%roni@huawei.com> To: 'Roni Even' , 'Randell Jesup' Message-id: <86AD8D1859A640A0B27CDF731C805512@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcnZCPICoe11EvE0SWm5FzsO7f0Y0AAWLd3wAAB7VEAAAMVlMAACBtvQAAESjxAAAJ/cEA== iPlanet-SMTP-Warning: Lines longer than SMTP allows found and truncated. References: <04CAD96D4C5A3D48B1919248A8FE0D540943CDB9@xmb-sjc-215.amer.cisco.com> <2713212F2F334A15AB3DB03E1BB45156@china.huawei.com> <4A092C12.8080704@rogers.com> <5E07A2E74C0749B7A84371EE422E90C6@china.huawei.com> <545DD1B15C9A42F0B1729CC02FFC6348@china.huawei.com> <2068ACFCE9FA4013865E833F38057DDB@china.huawei.com> <6e9223710905190853p133b630cud234027c753916ed@mail.gmail.com> <686CE89178A540B3BBFD761A3DEBC494@china.huawei.com> <1C47D7182AB24F758DC60913784EBD37@china.huawei.com> Cc: ron.even.tlv@gmail.com, 'Tom Taylor' , avt@ietf.org, 'stephen botzko' Subject: Re: [AVT] Q for 3984bis-06 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 18:09:43 -0000 Roni, Right, we are discussing possible approaches to acheive level upgrade. The hottest one has been what Randell proposed (level-upgrade-allowed), but it seems that there is something disconnecting Randell and myself, and we are working hard to find that out :-) I believe all the discussions are good to help us making a fully informed decision. BR, YK > -----Original Message----- > From: Roni Even [mailto:Even.roni@huawei.com] > Sent: Wednesday, May 20, 2009 2:00 PM > To: 'Ye-Kui Wang'; 'Randell Jesup' > Cc: ron.even.tlv@gmail.com; 'Tom Taylor'; 'stephen botzko'; > avt@ietf.org > Subject: RE: [AVT] Q for 3984bis-06 > > YK, > > The semantics of the parameters now is correct, what I was > saying is that there may be a difference between what a > device is offering and what the device can do in terms of > processing, this can happen due to other decisions like > configuration and it may go higher if the other side > indicates that it can do so. > > I think allowing level upgrade by the answerer is what all > the people discussing the topic draft are suggesting > (Ingemar, Randell, Jonathan, Magnus and others). I just gave > another example where it can happen. > Maybe clarify that the level is a receive capability will help. > > Jonathan Lennox even suggests " Architecturally, I think it > would be cleanest if H.264's non sprop-* parameters all have > SDP's standard receive-side semantics, rather than > offer/answer semantics." > > Roni Even > -----Original Message----- > From: Ye-Kui Wang [mailto:yekuiwang@huawei.com] > Sent: Wednesday, May 20, 2009 8:25 PM > To: 'Roni Even'; 'Randell Jesup' > Cc: ron.even.tlv@gmail.com; 'Tom Taylor'; 'stephen botzko'; > avt@ietf.org > Subject: RE: [AVT] Q for 3984bis-06 > > > Roni, > > > -----Original Message----- > > From: Roni Even [mailto:Even.roni@huawei.com] > > Sent: Wednesday, May 20, 2009 12:41 PM > > To: 'Ye-Kui Wang'; 'Randell Jesup' > > Cc: ron.even.tlv@gmail.com; 'Tom Taylor'; 'stephen botzko'; > > avt@ietf.org > > Subject: RE: [AVT] Q for 3984bis-06 > > > > YK, > > An offer of level 1.3 is just an offer, it is not necessarily > > what the device can do. The reasons for offering a lower > > level can be due to multiple reasons, like some configuration > > of the terminal and not based on encoder/decoder performance. > > > > If this is the case, then the current semantics of profile-level-id is > simply incorrect as it reads. > > > Having said that I would like to point out that in most cases > > you can get higher functionality by using other parameters > > like offering level 3.1 and using max-fs, max-br and max-cpb > > parameter to offer support for HD picture (using max-fs and > > max-cpb) at higher bit rate (based on max-br) which are over > > level 3.1 according to table A-1 in H.264. This is very > > typical in video conferencing applications if the offerer > > cannot support the maxBR for level 4 in table A-1. > > Correct. > > > I think that in this case it is reasonable for the answer to > > signal level 4 since it gives similar resolution but hinting > > that it can encode and decode higher bit rate. This will not > > break interoperability and make it simpler for the answerer. > > I don't think this is correct according to either RFC 3984 or > the bis. As > you said earlier, it is allowed to signal level 3.1, and to > use those max-* > parameters to indicate that the device has higher than 3.1 > capability in a > particular aspect, but not the other way round. If you signal > level 4, there > is no way to tell which aspect of the capability is lower > than level 4. This > is simply not what the spec says. If you think this way > should be supported, > you must propose it and make it said in the spec. > > BR, YK > > > > > Roni > > > > -----Original Message----- > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > > Behalf Of Ye-Kui Wang > > Sent: Wednesday, May 20, 2009 7:07 PM > > To: 'Randell Jesup' > > Cc: ron.even.tlv@gmail.com; 'Tom Taylor'; 'stephen botzko'; > > avt@ietf.org > > Subject: Re: [AVT] Q for 3984bis-06 > > > > > > Typo: encoded -> decode. So, the sentence should be as follows. > > > > " The whole point is, if the offer contians level 1.3 (per > > 3984 or the bis > > draft) with sendrecv or no direction attribute, then level > > 1.3 is the highest it can both encoded and encode. In this > > case, it simply cannot encode above level 1.3. " > > > > BTW, it is not absolutely prohibited to change the semantics > > of profile-level-id, I am just saying that you need to change > > the semantics. In addition, if the encoding/sending > > capability and the decoding/receiving capability is > > different, both capabiilties should be expressed. One way is > > to use different direction attributes (and separate SDP), > > which was considered not perfect. The other way is, as I > > mentioned earlier, to use two parameters, one for each. > > > > BR, YK > > > > > -----Original Message----- > > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > > Behalf Of > > > Ye-Kui Wang > > > Sent: Wednesday, May 20, 2009 11:52 AM > > > To: 'Randell Jesup' > > > Cc: ron.even.tlv@gmail.com; 'stephen botzko'; avt@ietf.org; 'Tom > > > Taylor' > > > Subject: Re: [AVT] Q for 3984bis-06 > > > > > > > > > > For example, if the offer is 1.3 with > > > level-upgrade-allowed=1, and the > > > > answer is level 3.1, then the offerer can send at any level > > > up to and > > > > including level 3.1. It could send level 2.0 if that's the > > > highest it > > > > can encode. > > > > > > The whole point is, if the offer contians level 1.3 (per > > 3984 or the > > > bis > > > draft) with sendrecv or no direction attribute, then level > > > 1.3 is the highest it can both encoded and encode. In > this case, it > > > simply cannot encode above level 1.3. > > > > > > Text in 3984: > > > If the profile-level-id parameter > > is used for > > > capability exchange or session setup > > > procedure, > > > it indicates the profile that the codec > > > supports and the highest level > > > supported for the signaled profile. > > > > > > BR, YK > > > > > > > -----Original Message----- > > > > From: Randell Jesup [mailto:rjesup@wgate.com] > > > > Sent: Wednesday, May 20, 2009 1:08 AM > > > > To: Ye-Kui Wang > > > > Cc: 'stephen botzko'; ron.even.tlv@gmail.com; 'Tom Taylor'; > > > > avt@ietf.org > > > > Subject: Re: [AVT] Q for 3984bis-06 > > > > > > > > Ye-Kui Wang writes: > > > > >> So, to summarize, if in response to an offer with > > > > >> level-upgrade-allowed=1, the answer includes a level > > > > higher than the > > > > >> offerer supports: > > > > >> > > > > >> * The offerer can encode a stream as if it's a higher > > > > level (including > > > > >> parameter sets), but using the encode settings of a > > > > lower level that > > > > >> it supports. > > > > > > > > > >So, in your interpretation, the offerer sending a higher > > > level just > > > > >means that it sends sequence parameter sets containing > > the higher > > > > >level, but the bitstream characteristics are still > > > restricted by the > > > > >lower level. How could this bring any practical > > usefulness? In the > > > > >example, offer includes level B (e.g. spatial resolution up > > > > to QVGA), > > > > >and the answer includes a higher level C (e.g. spatial > > > > resolution up to > > > > >VGA), then both sides still send and receive up to QVGA > > > > resolution, but > > > > >the offer includes sequence parameter sets include the level > > > > value C. Why is this useful at all? > > > > > > > > You asked a different question: > > > > > > > > >> >Now with the correct reading of the table. Again, that > > > > just makes a > > > > >> >difference on receiving or sending capability, not the > > > > conclusion. > > > > >> >You are basically assuming that the offerer's sending (i.e. > > > > >> >encoding) capability is not limited, i.e. it can send > > > > whatever high > > > > >> >level the answer may include. How can that assumption > > > be correct? > > > > > > > > You asked about sending at "whatever high level the answer may > > > > include". > > > > My response shows that you don't have to send at an > > > arbitrarily-high > > > > level > > > > - you can send at the highest level you support. > > > > > > > > For example, if the offer is 1.3 with > > > level-upgrade-allowed=1, and the > > > > answer is level 3.1, then the offerer can send at any level > > > up to and > > > > including level 3.1. It could send level 2.0 if that's the > > > highest it > > > > can encode. > > > > > > > > >BR, YK > > > > > > > > > >> -----Original Message----- > > > > >> From: Randell Jesup [mailto:rjesup@wgate.com] > > > > >> Sent: Wednesday, May 20, 2009 12:29 AM > > > > >> To: Ye-Kui Wang > > > > >> Cc: 'stephen botzko'; ron.even.tlv@gmail.com; 'Tom Taylor'; > > > > >> avt@ietf.org > > > > >> Subject: Re: [AVT] Q for 3984bis-06 > > > > >> > > > > >> Ye-Kui Wang writes: > > > > >> > > > > >> >I shortened the text. > > > > >> > > > > > >> >> If the offerer is legacy, then they don't include > > > > >> >> level-upgrade-allowed, and as stated the answerer is not > > > > >> allowed to > > > > >> >> upgrade the level. If the answerer is legacy, then they > > > > >> will ignore > > > > >> >> level-upgrade-allowed, and won't upgrade the level. So > > > > >> those 3 cases are all handled. > > > > >> > > > > > >> >OK. But it is possible that the answerer is new but does > > > > not want to > > > > >> >upgrade the level in an offer/answer process. It would be > > > > certainly > > > > >> >useful that the answerer lets the other side know whether it > > > > >> is new or > > > > >> >legacy. Therefore, I'd prefer to include > > > > >> level-upgrade-allowed equal to > > > > >> >1 if the device is new (does understand the parameter and > > > > >> allows level > > > > >> >upgrade). Note that something is allowed does not mean it > > > > is in use. > > > > >> > > > > >> The answerer could do that, and I don't have a problem > > > with it (it > > > > >> doesn't hurt anything), but I don't see how it's useful > > > in any way. > > > > >> > > > > >> >> >The conflict is at the offerer's side. It includes a > > > > lower level, > > > > >> >> >but you are proposing requires that the offerer can > > > > >> receive a higher > > > > >> >> >level. To do this, you must change the current > > semantics of > > > > >> >> >profile-level-id. > > > > >> >> > > > > >> >> No, unless we decide to take the option mentioned in my > > > > >> table (change > > > > >> >> it to "level-asymmetry-allowed"). Then (and only then) > > > > could the > > > > >> >> offerer could receive a level above what they offered. > > > > >> > > > > > >> >Sorry, I mis-read your table. But that just makes a > > > difference on > > > > >> >receiving or sending capability, not the conclusion. In the > > > > >> righ case > > > > >> >in the table (i.e. offer includes B, and answer > > > includes C). The > > > > >> >current semantics say that the offerer would only be able to > > > > >> send B and > > > > >> >lower. But you want the offerer to be able to send C which > > > > >> is higher than B. > > > > >> > > > > >> I don't understand what you're trying to say here. That's > > > > the point > > > > >> of level upgrade. And the offerer is still sending > at a level > > > > >> specified in the answers profile-level-id. > > > > >> Perhaps you're just saying "yes, this means the offerer > > > > might end up > > > > >> sending a stream at a higher level than it offered", > > > which is the > > > > >> whole point of level upgrade. > > > > >> > > > > >> >> >> Perhaps this table will help: > > > > >> >> >> > > > > >> >> >> Offer is level "B". I'll use level "A" to indicate a > > > > >> lower level, > > > > >> >> >> and "C" for a higher one (A < B < C). I'm assuming > > > > the offer > > > > >> >> >> includes level-upgrade-allowed=1. > > > > >> >> >> > > > > >> >> >> > > > > >> >> >> Answer level: lower (A) same (B) > > > higher (C) > > > > >> >> >> > > > > >> >> >> Offerer can send: A B C > > > > >> >> >> Answerer can send: A* B B > > > > >> >> >> > > > > >> >> > > > > > >> >> >In the right case (the answer includes level C), > > what if the > > > > >> >> >offerer's receiveing capability is actually lower than C? > > > > >> >> > > > > >> >> Then they shouldn't answer with "C". They should > > answer with > > > > >> >> whatever level they do support. The point of this is > > > > to allow the > > > > >> >> answerer to offer to receive a higher level; they get to > > > > >> choose what > > > > >> >> that level is. > > > > >> > > > > > >> >Now with the correct reading of the table. Again, that > > > > just makes a > > > > >> >difference on receiving or sending capability, not the > > > > >> conclusion. You > > > > >> >are basically assuming that the offerer's sending (i.e. > > > encoding) > > > > >> >capability is not limited, i.e. it can send whatever high > > > > >> level the answer may include. > > > > >> >How can that assumption be correct? > > > > >> > > > > >> You need to think about how level works in H.264. > > > > >> > > > > >> Remember we're only changing level, not constraints or > > profiles. > > > > >> > > > > >> Levels imply details about the maximum frame size, maximum > > > > >> macroblocks per second, maximum bitrate, etc, and each > > > level is a > > > > >> superset of the next-lower level. Using a level doesn't > > > > mean you (as > > > > >> an encoder) have to hit those maximums. If you encode a > > > > stream using > > > > >> the parameters of a lower level (i.e. > > > > >> using lower maximums), it's decodable by a higher-level > > > > decoder, even > > > > >> if you set the parameter sets to the higher level. > > > > >> > > > > >> Even more importantly, there's no apparent > requirement to send > > > > >> exactly the level given by the profile-level-id; sending > > > > lower levels > > > > >> (with the correct profile and constraints) appears to be > > > just fine > > > > >> (note that this interacts with parameter-set handling - > > > > you need to > > > > >> deal with making sure the decoder has correct parameter > > > > sets, as you > > > > >> always do). > > > > >> > > > > >> From 3984: > > > > >> > > > > >> If the profile-level-id parameter is used to indicate > > > > properties > > > > >> of a > > > > >> NAL unit stream, it indicates the profile and level > > > > that a decoder > > > > >> has > > > > >> to support in order to comply with [1] when it decodes > > > > the stream. > > > > >> > > > > >> and > > > > >> > > > > >> If the profile-level-id parameter is used for > > > > capability exchange > > > > >> or > > > > >> session setup procedure, it indicates the profile > > > that the codec > > > > >> supports and the highest level supported for the > > > > signaled profile. > > > > >> > > > > >> Note "highest level". And: > > > > >> > > > > >> The level conveyed in the value of the profile-level-id > > > > parameter > > > > >> MUST > > > > >> be such that the receiver is fully capable of supporting. > > > > >> > > > > >> and > > > > >> o Parameters used for declaring receiver > > capabilities are in > > > > >> general > > > > >> downgradable; i.e., they express the upper limit for > > > > a sender's > > > > >> possible behavior. Thus a sender MAY select to set > > > > its encoder > > > > >> using only lower/lesser or equal values of these > > > parameters. > > > > >> [snip] > > > > >> o Parameters declaring a configuration point are not > > > > downgradable, > > > > >> with the exception of the level part of the > > > > "profile-level-id" > > > > >> parameter. This expresses values a receiver expects > > > > to be used > > > > >> and must be used verbatim on the sender side. > > > > >> > > > > >> > > > > >> So, to summarize, if in response to an offer with > > > > >> level-upgrade-allowed=1, the answer includes a level > > > > higher than the > > > > >> offerer supports: > > > > >> > > > > >> * The offerer can encode a stream as if it's a higher > > > > level (including > > > > >> parameter sets), but using the encode settings of a > > > lower level > > > > >> that it > > > > >> supports. > > > > >> * The offerer can encode a stream using a lower level, > > including > > > > >> lower-level parameter sets. > > > > >> > > > > >> In both cases, the parameter sets must be conveyed to the > > > > answerer in > > > > >> some manner; the mechanisms that would make the most > sense are > > > > >> in-band parameter sets (with all that implies), or using > > > > >> sprop-level-parameter-sets including levels above the > > > level in the > > > > >> offered profile-level-id, so that the answer can select > > > > one of those > > > > >> levels and thus install those parameter sets. > > > > >> > > > > >> None of this requires any further modification to 3984bis > > > > that I can > > > > >> see - just allowing level-upgrade-allowed (or > > > > >> level-asymmetric-allowed). > > > > >> > > > > >> -- > > > > >> Randell Jesup, Worldgate (developers of the Ojo > > > > videophone), ex-Amiga > > > > >> OS team rjesup@wgate.com "The fetters imposed on liberty > > > > at home have > > > > >> ever been forged out of the weapons provided for > > defence against > > > > >> real, pretended, or imaginary dangers from abroad." > > > > >> - James Madison, 4th US president (1751-1836) > > > > >> > > > > >> > > > > > > > > > > > > -- > > > > Randell Jesup, Worldgate (developers of the Ojo > > > videophone), ex-Amiga > > > > OS team rjesup@wgate.com "The fetters imposed on liberty at > > > home have > > > > ever been forged out of the weapons provided for defence > > > against real, > > > > pretended, or imaginary dangers from abroad." > > > > - James Madison, 4th US president (1751-1836) > > > > > > > > > > > > > > > > > _______________________________________________ > > > Audio/Video Transport Working Group > > > avt@ietf.org > > > https://www.ietf.org/mailman/listinfo/avt > > > > > > > > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > > > > > > > From tom.taylor@rogers.com Wed May 20 11:36:49 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDE8D3A6AC8 for ; Wed, 20 May 2009 11:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yn6BbJe8uZNL for ; Wed, 20 May 2009 11:36:48 -0700 (PDT) Received: from smtp129.rog.mail.re2.yahoo.com (smtp129.rog.mail.re2.yahoo.com [206.190.53.34]) by core3.amsl.com (Postfix) with SMTP id A1CA328C1E7 for ; Wed, 20 May 2009 11:36:19 -0700 (PDT) Received: (qmail 29931 invoked from network); 20 May 2009 18:37:53 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=soyGRrdh5SiOgIaSw9+NxQFj8nEiIBpcXMe0pvHgoilCazTEhqYx/fzGFQnAHjN5EeIKnCvfKRDcLX1W3DRZ085VDBNL5s69SpcjFVOAmSB0/OMkh1jzXLtyB8GmrXlABmD0alwWBC6XM51hIFnlrfOzqGF3biWczPARfxFk6O8= ; Received: from unknown (HELO ?156.106.216.157?) (tom.taylor@156.106.216.157 with plain) by smtp129.rog.mail.re2.yahoo.com with SMTP; 20 May 2009 18:37:52 -0000 X-YMail-OSG: dJHVG.UVM1msWbO47zrh0LXAIVp8oQ6rqkDg9w2XL17UY7qgsWAKW_G7pUhBHIf_rQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A144DFD.1070005@rogers.com> Date: Wed, 20 May 2009 20:37:49 +0200 From: Tom Taylor User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Ye-Kui Wang References: <04CAD96D4C5A3D48B1919248A8FE0D540943CDB9@xmb-sjc-215.amer.cisco.com> <4A092C12.8080704@rogers.com> <5E07A2E74C0749B7A84371EE422E90C6@china.huawei.com> <545DD1B15C9A42F0B1729CC02FFC6348@china.huawei.com> <2068ACFCE9FA4013865E833F38057DDB@china.huawei.com> <6e9223710905190853p133b630cud234027c753916ed@mail.gmail.com> <686CE89178A540B3BBFD761A3DEBC494@china.huawei.com> <1C47D7182AB24F758DC60913784EBD37@china.huawei.com> <86AD8D1859A640A0B27CDF731C805512@china.huawei.com> In-Reply-To: <86AD8D1859A640A0B27CDF731C805512@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'Randell Jesup' , ron.even.tlv@gmail.com, avt@ietf.org, 'Roni Even' , 'stephen botzko' Subject: Re: [AVT] Q for 3984bis-06 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 18:36:49 -0000 I think fairly soon Roni and I are going to have to call a consensus on this one. It's all very well to have discussion, but only if new points are coming out. I'll review the thread once more. Ye-Kui Wang wrote: > Roni, > > Right, we are discussing possible approaches to acheive level upgrade. The > hottest one has been what Randell proposed (level-upgrade-allowed), but it > seems that there is something disconnecting Randell and myself, and we are > working hard to find that out :-) I believe all the discussions are good to > help us making a fully informed decision. > > BR, YK > >> -----Original Message----- >> From: Roni Even [mailto:Even.roni@huawei.com] >> Sent: Wednesday, May 20, 2009 2:00 PM >> To: 'Ye-Kui Wang'; 'Randell Jesup' >> Cc: ron.even.tlv@gmail.com; 'Tom Taylor'; 'stephen botzko'; >> avt@ietf.org >> Subject: RE: [AVT] Q for 3984bis-06 >> >> YK, >> >> The semantics of the parameters now is correct, what I was >> saying is that there may be a difference between what a >> device is offering and what the device can do in terms of >> processing, this can happen due to other decisions like >> configuration and it may go higher if the other side >> indicates that it can do so. >> >> I think allowing level upgrade by the answerer is what all >> the people discussing the topic draft are suggesting >> (Ingemar, Randell, Jonathan, Magnus and others). I just gave >> another example where it can happen. >> Maybe clarify that the level is a receive capability will help. >> >> Jonathan Lennox even suggests " Architecturally, I think it >> would be cleanest if H.264's non sprop-* parameters all have >> SDP's standard receive-side semantics, rather than >> offer/answer semantics." >> >> Roni Even >> -----Original Message----- >> From: Ye-Kui Wang [mailto:yekuiwang@huawei.com] >> Sent: Wednesday, May 20, 2009 8:25 PM >> To: 'Roni Even'; 'Randell Jesup' >> Cc: ron.even.tlv@gmail.com; 'Tom Taylor'; 'stephen botzko'; >> avt@ietf.org >> Subject: RE: [AVT] Q for 3984bis-06 >> >> >> Roni, >> >>> -----Original Message----- >>> From: Roni Even [mailto:Even.roni@huawei.com] >>> Sent: Wednesday, May 20, 2009 12:41 PM >>> To: 'Ye-Kui Wang'; 'Randell Jesup' >>> Cc: ron.even.tlv@gmail.com; 'Tom Taylor'; 'stephen botzko'; >>> avt@ietf.org >>> Subject: RE: [AVT] Q for 3984bis-06 >>> >>> YK, >>> An offer of level 1.3 is just an offer, it is not necessarily >>> what the device can do. The reasons for offering a lower >>> level can be due to multiple reasons, like some configuration >>> of the terminal and not based on encoder/decoder performance. >>> >> If this is the case, then the current semantics of profile-level-id is >> simply incorrect as it reads. >> >>> Having said that I would like to point out that in most cases >>> you can get higher functionality by using other parameters >>> like offering level 3.1 and using max-fs, max-br and max-cpb >>> parameter to offer support for HD picture (using max-fs and >>> max-cpb) at higher bit rate (based on max-br) which are over >>> level 3.1 according to table A-1 in H.264. This is very >>> typical in video conferencing applications if the offerer >>> cannot support the maxBR for level 4 in table A-1. >> Correct. >> >>> I think that in this case it is reasonable for the answer to >>> signal level 4 since it gives similar resolution but hinting >>> that it can encode and decode higher bit rate. This will not >>> break interoperability and make it simpler for the answerer. >> I don't think this is correct according to either RFC 3984 or >> the bis. As >> you said earlier, it is allowed to signal level 3.1, and to >> use those max-* >> parameters to indicate that the device has higher than 3.1 >> capability in a >> particular aspect, but not the other way round. If you signal >> level 4, there >> is no way to tell which aspect of the capability is lower >> than level 4. This >> is simply not what the spec says. If you think this way >> should be supported, >> you must propose it and make it said in the spec. >> >> BR, YK >> >>> Roni >>> >>> -----Original Message----- >>> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On >>> Behalf Of Ye-Kui Wang >>> Sent: Wednesday, May 20, 2009 7:07 PM >>> To: 'Randell Jesup' >>> Cc: ron.even.tlv@gmail.com; 'Tom Taylor'; 'stephen botzko'; >>> avt@ietf.org >>> Subject: Re: [AVT] Q for 3984bis-06 >>> >>> >>> Typo: encoded -> decode. So, the sentence should be as follows. >>> >>> " The whole point is, if the offer contians level 1.3 (per >>> 3984 or the bis >>> draft) with sendrecv or no direction attribute, then level >>> 1.3 is the highest it can both encoded and encode. In this >>> case, it simply cannot encode above level 1.3. " >>> >>> BTW, it is not absolutely prohibited to change the semantics >>> of profile-level-id, I am just saying that you need to change >>> the semantics. In addition, if the encoding/sending >>> capability and the decoding/receiving capability is >>> different, both capabiilties should be expressed. One way is >>> to use different direction attributes (and separate SDP), >>> which was considered not perfect. The other way is, as I >>> mentioned earlier, to use two parameters, one for each. >>> >>> BR, YK >>> >>>> -----Original Message----- >>>> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On >>> Behalf Of >>>> Ye-Kui Wang >>>> Sent: Wednesday, May 20, 2009 11:52 AM >>>> To: 'Randell Jesup' >>>> Cc: ron.even.tlv@gmail.com; 'stephen botzko'; avt@ietf.org; 'Tom >>>> Taylor' >>>> Subject: Re: [AVT] Q for 3984bis-06 >>>> >>>> >>>>> For example, if the offer is 1.3 with >>>> level-upgrade-allowed=1, and the >>>>> answer is level 3.1, then the offerer can send at any level >>>> up to and >>>>> including level 3.1. It could send level 2.0 if that's the >>>> highest it >>>>> can encode. >>>> The whole point is, if the offer contians level 1.3 (per >>> 3984 or the >>>> bis >>>> draft) with sendrecv or no direction attribute, then level >>>> 1.3 is the highest it can both encoded and encode. In >> this case, it >>>> simply cannot encode above level 1.3. >>>> >>>> Text in 3984: >>>> If the profile-level-id parameter >>> is used for >>>> capability exchange or session setup >>>> procedure, >>>> it indicates the profile that the codec >>>> supports and the highest level >>>> supported for the signaled profile. >>>> >>>> BR, YK >>>> >>>>> -----Original Message----- >>>>> From: Randell Jesup [mailto:rjesup@wgate.com] >>>>> Sent: Wednesday, May 20, 2009 1:08 AM >>>>> To: Ye-Kui Wang >>>>> Cc: 'stephen botzko'; ron.even.tlv@gmail.com; 'Tom Taylor'; >>>>> avt@ietf.org >>>>> Subject: Re: [AVT] Q for 3984bis-06 >>>>> >>>>> Ye-Kui Wang writes: >>>>>>> So, to summarize, if in response to an offer with >>>>>>> level-upgrade-allowed=1, the answer includes a level >>>>> higher than the >>>>>>> offerer supports: >>>>>>> >>>>>>> * The offerer can encode a stream as if it's a higher >>>>> level (including >>>>>>> parameter sets), but using the encode settings of a >>>>> lower level that >>>>>>> it supports. >>>>>> So, in your interpretation, the offerer sending a higher >>>> level just >>>>>> means that it sends sequence parameter sets containing >>> the higher >>>>>> level, but the bitstream characteristics are still >>>> restricted by the >>>>>> lower level. How could this bring any practical >>> usefulness? In the >>>>>> example, offer includes level B (e.g. spatial resolution up >>>>> to QVGA), >>>>>> and the answer includes a higher level C (e.g. spatial >>>>> resolution up to >>>>>> VGA), then both sides still send and receive up to QVGA >>>>> resolution, but >>>>>> the offer includes sequence parameter sets include the level >>>>> value C. Why is this useful at all? >>>>> >>>>> You asked a different question: >>>>> >>>>>>>> Now with the correct reading of the table. Again, that >>>>> just makes a >>>>>>>> difference on receiving or sending capability, not the >>>>> conclusion. >>>>>>>> You are basically assuming that the offerer's sending (i.e. >>>>>>>> encoding) capability is not limited, i.e. it can send >>>>> whatever high >>>>>>>> level the answer may include. How can that assumption >>>> be correct? >>>>> You asked about sending at "whatever high level the answer may >>>>> include". >>>>> My response shows that you don't have to send at an >>>> arbitrarily-high >>>>> level >>>>> - you can send at the highest level you support. >>>>> >>>>> For example, if the offer is 1.3 with >>>> level-upgrade-allowed=1, and the >>>>> answer is level 3.1, then the offerer can send at any level >>>> up to and >>>>> including level 3.1. It could send level 2.0 if that's the >>>> highest it >>>>> can encode. >>>>> >>>>>> BR, YK >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Randell Jesup [mailto:rjesup@wgate.com] >>>>>>> Sent: Wednesday, May 20, 2009 12:29 AM >>>>>>> To: Ye-Kui Wang >>>>>>> Cc: 'stephen botzko'; ron.even.tlv@gmail.com; 'Tom Taylor'; >>>>>>> avt@ietf.org >>>>>>> Subject: Re: [AVT] Q for 3984bis-06 >>>>>>> >>>>>>> Ye-Kui Wang writes: >>>>>>> >>>>>>>> I shortened the text. >>>>>>>> >>>>>>>>> If the offerer is legacy, then they don't include >>>>>>>>> level-upgrade-allowed, and as stated the answerer is not >>>>>>> allowed to >>>>>>>>> upgrade the level. If the answerer is legacy, then they >>>>>>> will ignore >>>>>>>>> level-upgrade-allowed, and won't upgrade the level. So >>>>>>> those 3 cases are all handled. >>>>>>>> OK. But it is possible that the answerer is new but does >>>>> not want to >>>>>>>> upgrade the level in an offer/answer process. It would be >>>>> certainly >>>>>>>> useful that the answerer lets the other side know whether it >>>>>>> is new or >>>>>>>> legacy. Therefore, I'd prefer to include >>>>>>> level-upgrade-allowed equal to >>>>>>>> 1 if the device is new (does understand the parameter and >>>>>>> allows level >>>>>>>> upgrade). Note that something is allowed does not mean it >>>>> is in use. >>>>>>> The answerer could do that, and I don't have a problem >>>> with it (it >>>>>>> doesn't hurt anything), but I don't see how it's useful >>>> in any way. >>>>>>>>>> The conflict is at the offerer's side. It includes a >>>>> lower level, >>>>>>>>>> but you are proposing requires that the offerer can >>>>>>> receive a higher >>>>>>>>>> level. To do this, you must change the current >>> semantics of >>>>>>>>>> profile-level-id. >>>>>>>>> No, unless we decide to take the option mentioned in my >>>>>>> table (change >>>>>>>>> it to "level-asymmetry-allowed"). Then (and only then) >>>>> could the >>>>>>>>> offerer could receive a level above what they offered. >>>>>>>> Sorry, I mis-read your table. But that just makes a >>>> difference on >>>>>>>> receiving or sending capability, not the conclusion. In the >>>>>>> righ case >>>>>>>> in the table (i.e. offer includes B, and answer >>>> includes C). The >>>>>>>> current semantics say that the offerer would only be able to >>>>>>> send B and >>>>>>>> lower. But you want the offerer to be able to send C which >>>>>>> is higher than B. >>>>>>> >>>>>>> I don't understand what you're trying to say here. That's >>>>> the point >>>>>>> of level upgrade. And the offerer is still sending >> at a level >>>>>>> specified in the answers profile-level-id. >>>>>>> Perhaps you're just saying "yes, this means the offerer >>>>> might end up >>>>>>> sending a stream at a higher level than it offered", >>>> which is the >>>>>>> whole point of level upgrade. >>>>>>> >>>>>>>>>>> Perhaps this table will help: >>>>>>>>>>> >>>>>>>>>>> Offer is level "B". I'll use level "A" to indicate a >>>>>>> lower level, >>>>>>>>>>> and "C" for a higher one (A < B < C). I'm assuming >>>>> the offer >>>>>>>>>>> includes level-upgrade-allowed=1. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Answer level: lower (A) same (B) >>>> higher (C) >>>>>>>>>>> Offerer can send: A B C >>>>>>>>>>> Answerer can send: A* B B >>>>>>>>>>> >>>>>>>>>> In the right case (the answer includes level C), >>> what if the >>>>>>>>>> offerer's receiveing capability is actually lower than C? >>>>>>>>> Then they shouldn't answer with "C". They should >>> answer with >>>>>>>>> whatever level they do support. The point of this is >>>>> to allow the >>>>>>>>> answerer to offer to receive a higher level; they get to >>>>>>> choose what >>>>>>>>> that level is. >>>>>>>> Now with the correct reading of the table. Again, that >>>>> just makes a >>>>>>>> difference on receiving or sending capability, not the >>>>>>> conclusion. You >>>>>>>> are basically assuming that the offerer's sending (i.e. >>>> encoding) >>>>>>>> capability is not limited, i.e. it can send whatever high >>>>>>> level the answer may include. >>>>>>>> How can that assumption be correct? >>>>>>> You need to think about how level works in H.264. >>>>>>> >>>>>>> Remember we're only changing level, not constraints or >>> profiles. >>>>>>> Levels imply details about the maximum frame size, maximum >>>>>>> macroblocks per second, maximum bitrate, etc, and each >>>> level is a >>>>>>> superset of the next-lower level. Using a level doesn't >>>>> mean you (as >>>>>>> an encoder) have to hit those maximums. If you encode a >>>>> stream using >>>>>>> the parameters of a lower level (i.e. >>>>>>> using lower maximums), it's decodable by a higher-level >>>>> decoder, even >>>>>>> if you set the parameter sets to the higher level. >>>>>>> >>>>>>> Even more importantly, there's no apparent >> requirement to send >>>>>>> exactly the level given by the profile-level-id; sending >>>>> lower levels >>>>>>> (with the correct profile and constraints) appears to be >>>> just fine >>>>>>> (note that this interacts with parameter-set handling - >>>>> you need to >>>>>>> deal with making sure the decoder has correct parameter >>>>> sets, as you >>>>>>> always do). >>>>>>> >>>>>>> From 3984: >>>>>>> >>>>>>> If the profile-level-id parameter is used to indicate >>>>> properties >>>>>>> of a >>>>>>> NAL unit stream, it indicates the profile and level >>>>> that a decoder >>>>>>> has >>>>>>> to support in order to comply with [1] when it decodes >>>>> the stream. >>>>>>> and >>>>>>> >>>>>>> If the profile-level-id parameter is used for >>>>> capability exchange >>>>>>> or >>>>>>> session setup procedure, it indicates the profile >>>> that the codec >>>>>>> supports and the highest level supported for the >>>>> signaled profile. >>>>>>> Note "highest level". And: >>>>>>> >>>>>>> The level conveyed in the value of the profile-level-id >>>>> parameter >>>>>>> MUST >>>>>>> be such that the receiver is fully capable of supporting. >>>>>>> >>>>>>> and >>>>>>> o Parameters used for declaring receiver >>> capabilities are in >>>>>>> general >>>>>>> downgradable; i.e., they express the upper limit for >>>>> a sender's >>>>>>> possible behavior. Thus a sender MAY select to set >>>>> its encoder >>>>>>> using only lower/lesser or equal values of these >>>> parameters. >>>>>>> [snip] >>>>>>> o Parameters declaring a configuration point are not >>>>> downgradable, >>>>>>> with the exception of the level part of the >>>>> "profile-level-id" >>>>>>> parameter. This expresses values a receiver expects >>>>> to be used >>>>>>> and must be used verbatim on the sender side. >>>>>>> >>>>>>> >>>>>>> So, to summarize, if in response to an offer with >>>>>>> level-upgrade-allowed=1, the answer includes a level >>>>> higher than the >>>>>>> offerer supports: >>>>>>> >>>>>>> * The offerer can encode a stream as if it's a higher >>>>> level (including >>>>>>> parameter sets), but using the encode settings of a >>>> lower level >>>>>>> that it >>>>>>> supports. >>>>>>> * The offerer can encode a stream using a lower level, >>> including >>>>>>> lower-level parameter sets. >>>>>>> >>>>>>> In both cases, the parameter sets must be conveyed to the >>>>> answerer in >>>>>>> some manner; the mechanisms that would make the most >> sense are >>>>>>> in-band parameter sets (with all that implies), or using >>>>>>> sprop-level-parameter-sets including levels above the >>>> level in the >>>>>>> offered profile-level-id, so that the answer can select >>>>> one of those >>>>>>> levels and thus install those parameter sets. >>>>>>> >>>>>>> None of this requires any further modification to 3984bis >>>>> that I can >>>>>>> see - just allowing level-upgrade-allowed (or >>>>>>> level-asymmetric-allowed). >>>>>>> >>>>>>> -- >>>>>>> Randell Jesup, Worldgate (developers of the Ojo >>>>> videophone), ex-Amiga >>>>>>> OS team rjesup@wgate.com "The fetters imposed on liberty >>>>> at home have >>>>>>> ever been forged out of the weapons provided for >>> defence against >>>>>>> real, pretended, or imaginary dangers from abroad." >>>>>>> - James Madison, 4th US president (1751-1836) >>>>>>> >>>>>>> >>>>> >>>>> -- >>>>> Randell Jesup, Worldgate (developers of the Ojo >>>> videophone), ex-Amiga >>>>> OS team rjesup@wgate.com "The fetters imposed on liberty at >>>> home have >>>>> ever been forged out of the weapons provided for defence >>>> against real, >>>>> pretended, or imaginary dangers from abroad." >>>>> - James Madison, 4th US president (1751-1836) >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Audio/Video Transport Working Group >>>> avt@ietf.org >>>> https://www.ietf.org/mailman/listinfo/avt >>>> >>> >>> _______________________________________________ >>> Audio/Video Transport Working Group >>> avt@ietf.org >>> https://www.ietf.org/mailman/listinfo/avt >>> >>> >> >> > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > From Even.roni@huawei.com Wed May 20 11:55:25 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3214C28C3B2 for ; Wed, 20 May 2009 11:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.351, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-HX9nmoRylS for ; Wed, 20 May 2009 11:55:23 -0700 (PDT) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id CB88428C381 for ; Wed, 20 May 2009 11:55:22 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJY00KN6HYY1E@szxga02-in.huawei.com> for avt@ietf.org; Thu, 21 May 2009 02:56:59 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJY007BRHYY2I@szxga02-in.huawei.com> for avt@ietf.org; Thu, 21 May 2009 02:56:58 +0800 (CST) Received: from windows8d787f9 (bzq-79-181-118-116.red.bezeqint.net [79.181.118.116]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJY003CPHYH1W@szxml01-in.huawei.com>; Thu, 21 May 2009 02:56:58 +0800 (CST) Date: Wed, 20 May 2009 21:55:59 +0300 From: Roni Even In-reply-to: <86AD8D1859A640A0B27CDF731C805512@china.huawei.com> To: 'Ye-Kui Wang' , 'Randell Jesup' Message-id: <003b01c9d97c$a6746db0$f35d4910$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcnZCPICoe11EvE0SWm5FzsO7f0Y0AAWLd3wAAB7VEAAAMVlMAACBtvQAAESjxAAAJ/cEAABrKOg iPlanet-SMTP-Warning: Lines longer than SMTP allows found and truncated. References: <04CAD96D4C5A3D48B1919248A8FE0D540943CDB9@xmb-sjc-215.amer.cisco.com> <2713212F2F334A15AB3DB03E1BB45156@china.huawei.com> <4A092C12.8080704@rogers.com> <5E07A2E74C0749B7A84371EE422E90C6@china.huawei.com> <545DD1B15C9A42F0B1729CC02FFC6348@china.huawei.com> <2068ACFCE9FA4013865E833F38057DDB@china.huawei.com> <6e9223710905190853p133b630cud234027c753916ed@mail.gmail.com> <686CE89178A540B3BBFD761A3DEBC494@china.huawei.com> <1C47D7182AB24F758DC60913784EBD37@china.huawei.com> Cc: ron.even.tlv@gmail.com, 'stephen botzko' , 'Tom Taylor' , avt@ietf.org Subject: Re: [AVT] Q for 3984bis-06 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 18:55:25 -0000 YK, Does this mean that you are considering adding level upgrade but just arguing the text? Anyhow Tom will need to call for a consensus on the change based on the long discussion starting with the email from Ashish (May 4th) Roni -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ye-Kui Wang Sent: Wednesday, May 20, 2009 9:11 PM To: 'Roni Even'; 'Randell Jesup' Cc: ron.even.tlv@gmail.com; 'Tom Taylor'; avt@ietf.org; 'stephen botzko' Subject: Re: [AVT] Q for 3984bis-06 Roni, Right, we are discussing possible approaches to acheive level upgrade. The hottest one has been what Randell proposed (level-upgrade-allowed), but it seems that there is something disconnecting Randell and myself, and we are working hard to find that out :-) I believe all the discussions are good to help us making a fully informed decision. BR, YK > -----Original Message----- > From: Roni Even [mailto:Even.roni@huawei.com] > Sent: Wednesday, May 20, 2009 2:00 PM > To: 'Ye-Kui Wang'; 'Randell Jesup' > Cc: ron.even.tlv@gmail.com; 'Tom Taylor'; 'stephen botzko'; > avt@ietf.org > Subject: RE: [AVT] Q for 3984bis-06 > > YK, > > The semantics of the parameters now is correct, what I was > saying is that there may be a difference between what a > device is offering and what the device can do in terms of > processing, this can happen due to other decisions like > configuration and it may go higher if the other side > indicates that it can do so. > > I think allowing level upgrade by the answerer is what all > the people discussing the topic draft are suggesting > (Ingemar, Randell, Jonathan, Magnus and others). I just gave > another example where it can happen. > Maybe clarify that the level is a receive capability will help. > > Jonathan Lennox even suggests " Architecturally, I think it > would be cleanest if H.264's non sprop-* parameters all have > SDP's standard receive-side semantics, rather than > offer/answer semantics." > > Roni Even > -----Original Message----- > From: Ye-Kui Wang [mailto:yekuiwang@huawei.com] > Sent: Wednesday, May 20, 2009 8:25 PM > To: 'Roni Even'; 'Randell Jesup' > Cc: ron.even.tlv@gmail.com; 'Tom Taylor'; 'stephen botzko'; > avt@ietf.org > Subject: RE: [AVT] Q for 3984bis-06 > > > Roni, > > > -----Original Message----- > > From: Roni Even [mailto:Even.roni@huawei.com] > > Sent: Wednesday, May 20, 2009 12:41 PM > > To: 'Ye-Kui Wang'; 'Randell Jesup' > > Cc: ron.even.tlv@gmail.com; 'Tom Taylor'; 'stephen botzko'; > > avt@ietf.org > > Subject: RE: [AVT] Q for 3984bis-06 > > > > YK, > > An offer of level 1.3 is just an offer, it is not necessarily > > what the device can do. The reasons for offering a lower > > level can be due to multiple reasons, like some configuration > > of the terminal and not based on encoder/decoder performance. > > > > If this is the case, then the current semantics of profile-level-id is > simply incorrect as it reads. > > > Having said that I would like to point out that in most cases > > you can get higher functionality by using other parameters > > like offering level 3.1 and using max-fs, max-br and max-cpb > > parameter to offer support for HD picture (using max-fs and > > max-cpb) at higher bit rate (based on max-br) which are over > > level 3.1 according to table A-1 in H.264. This is very > > typical in video conferencing applications if the offerer > > cannot support the maxBR for level 4 in table A-1. > > Correct. > > > I think that in this case it is reasonable for the answer to > > signal level 4 since it gives similar resolution but hinting > > that it can encode and decode higher bit rate. This will not > > break interoperability and make it simpler for the answerer. > > I don't think this is correct according to either RFC 3984 or > the bis. As > you said earlier, it is allowed to signal level 3.1, and to > use those max-* > parameters to indicate that the device has higher than 3.1 > capability in a > particular aspect, but not the other way round. If you signal > level 4, there > is no way to tell which aspect of the capability is lower > than level 4. This > is simply not what the spec says. If you think this way > should be supported, > you must propose it and make it said in the spec. > > BR, YK > > > > > Roni > > > > -----Original Message----- > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > > Behalf Of Ye-Kui Wang > > Sent: Wednesday, May 20, 2009 7:07 PM > > To: 'Randell Jesup' > > Cc: ron.even.tlv@gmail.com; 'Tom Taylor'; 'stephen botzko'; > > avt@ietf.org > > Subject: Re: [AVT] Q for 3984bis-06 > > > > > > Typo: encoded -> decode. So, the sentence should be as follows. > > > > " The whole point is, if the offer contians level 1.3 (per > > 3984 or the bis > > draft) with sendrecv or no direction attribute, then level > > 1.3 is the highest it can both encoded and encode. In this > > case, it simply cannot encode above level 1.3. " > > > > BTW, it is not absolutely prohibited to change the semantics > > of profile-level-id, I am just saying that you need to change > > the semantics. In addition, if the encoding/sending > > capability and the decoding/receiving capability is > > different, both capabiilties should be expressed. One way is > > to use different direction attributes (and separate SDP), > > which was considered not perfect. The other way is, as I > > mentioned earlier, to use two parameters, one for each. > > > > BR, YK > > > > > -----Original Message----- > > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > > Behalf Of > > > Ye-Kui Wang > > > Sent: Wednesday, May 20, 2009 11:52 AM > > > To: 'Randell Jesup' > > > Cc: ron.even.tlv@gmail.com; 'stephen botzko'; avt@ietf.org; 'Tom > > > Taylor' > > > Subject: Re: [AVT] Q for 3984bis-06 > > > > > > > > > > For example, if the offer is 1.3 with > > > level-upgrade-allowed=1, and the > > > > answer is level 3.1, then the offerer can send at any level > > > up to and > > > > including level 3.1. It could send level 2.0 if that's the > > > highest it > > > > can encode. > > > > > > The whole point is, if the offer contians level 1.3 (per > > 3984 or the > > > bis > > > draft) with sendrecv or no direction attribute, then level > > > 1.3 is the highest it can both encoded and encode. In > this case, it > > > simply cannot encode above level 1.3. > > > > > > Text in 3984: > > > If the profile-level-id parameter > > is used for > > > capability exchange or session setup > > > procedure, > > > it indicates the profile that the codec > > > supports and the highest level > > > supported for the signaled profile. > > > > > > BR, YK > > > > > > > -----Original Message----- > > > > From: Randell Jesup [mailto:rjesup@wgate.com] > > > > Sent: Wednesday, May 20, 2009 1:08 AM > > > > To: Ye-Kui Wang > > > > Cc: 'stephen botzko'; ron.even.tlv@gmail.com; 'Tom Taylor'; > > > > avt@ietf.org > > > > Subject: Re: [AVT] Q for 3984bis-06 > > > > > > > > Ye-Kui Wang writes: > > > > >> So, to summarize, if in response to an offer with > > > > >> level-upgrade-allowed=1, the answer includes a level > > > > higher than the > > > > >> offerer supports: > > > > >> > > > > >> * The offerer can encode a stream as if it's a higher > > > > level (including > > > > >> parameter sets), but using the encode settings of a > > > > lower level that > > > > >> it supports. > > > > > > > > > >So, in your interpretation, the offerer sending a higher > > > level just > > > > >means that it sends sequence parameter sets containing > > the higher > > > > >level, but the bitstream characteristics are still > > > restricted by the > > > > >lower level. How could this bring any practical > > usefulness? In the > > > > >example, offer includes level B (e.g. spatial resolution up > > > > to QVGA), > > > > >and the answer includes a higher level C (e.g. spatial > > > > resolution up to > > > > >VGA), then both sides still send and receive up to QVGA > > > > resolution, but > > > > >the offer includes sequence parameter sets include the level > > > > value C. Why is this useful at all? > > > > > > > > You asked a different question: > > > > > > > > >> >Now with the correct reading of the table. Again, that > > > > just makes a > > > > >> >difference on receiving or sending capability, not the > > > > conclusion. > > > > >> >You are basically assuming that the offerer's sending (i.e. > > > > >> >encoding) capability is not limited, i.e. it can send > > > > whatever high > > > > >> >level the answer may include. How can that assumption > > > be correct? > > > > > > > > You asked about sending at "whatever high level the answer may > > > > include". > > > > My response shows that you don't have to send at an > > > arbitrarily-high > > > > level > > > > - you can send at the highest level you support. > > > > > > > > For example, if the offer is 1.3 with > > > level-upgrade-allowed=1, and the > > > > answer is level 3.1, then the offerer can send at any level > > > up to and > > > > including level 3.1. It could send level 2.0 if that's the > > > highest it > > > > can encode. > > > > > > > > >BR, YK > > > > > > > > > >> -----Original Message----- > > > > >> From: Randell Jesup [mailto:rjesup@wgate.com] > > > > >> Sent: Wednesday, May 20, 2009 12:29 AM > > > > >> To: Ye-Kui Wang > > > > >> Cc: 'stephen botzko'; ron.even.tlv@gmail.com; 'Tom Taylor'; > > > > >> avt@ietf.org > > > > >> Subject: Re: [AVT] Q for 3984bis-06 > > > > >> > > > > >> Ye-Kui Wang writes: > > > > >> > > > > >> >I shortened the text. > > > > >> > > > > > >> >> If the offerer is legacy, then they don't include > > > > >> >> level-upgrade-allowed, and as stated the answerer is not > > > > >> allowed to > > > > >> >> upgrade the level. If the answerer is legacy, then they > > > > >> will ignore > > > > >> >> level-upgrade-allowed, and won't upgrade the level. So > > > > >> those 3 cases are all handled. > > > > >> > > > > > >> >OK. But it is possible that the answerer is new but does > > > > not want to > > > > >> >upgrade the level in an offer/answer process. It would be > > > > certainly > > > > >> >useful that the answerer lets the other side know whether it > > > > >> is new or > > > > >> >legacy. Therefore, I'd prefer to include > > > > >> level-upgrade-allowed equal to > > > > >> >1 if the device is new (does understand the parameter and > > > > >> allows level > > > > >> >upgrade). Note that something is allowed does not mean it > > > > is in use. > > > > >> > > > > >> The answerer could do that, and I don't have a problem > > > with it (it > > > > >> doesn't hurt anything), but I don't see how it's useful > > > in any way. > > > > >> > > > > >> >> >The conflict is at the offerer's side. It includes a > > > > lower level, > > > > >> >> >but you are proposing requires that the offerer can > > > > >> receive a higher > > > > >> >> >level. To do this, you must change the current > > semantics of > > > > >> >> >profile-level-id. > > > > >> >> > > > > >> >> No, unless we decide to take the option mentioned in my > > > > >> table (change > > > > >> >> it to "level-asymmetry-allowed"). Then (and only then) > > > > could the > > > > >> >> offerer could receive a level above what they offered. > > > > >> > > > > > >> >Sorry, I mis-read your table. But that just makes a > > > difference on > > > > >> >receiving or sending capability, not the conclusion. In the > > > > >> righ case > > > > >> >in the table (i.e. offer includes B, and answer > > > includes C). The > > > > >> >current semantics say that the offerer would only be able to > > > > >> send B and > > > > >> >lower. But you want the offerer to be able to send C which > > > > >> is higher than B. > > > > >> > > > > >> I don't understand what you're trying to say here. That's > > > > the point > > > > >> of level upgrade. And the offerer is still sending > at a level > > > > >> specified in the answers profile-level-id. > > > > >> Perhaps you're just saying "yes, this means the offerer > > > > might end up > > > > >> sending a stream at a higher level than it offered", > > > which is the > > > > >> whole point of level upgrade. > > > > >> > > > > >> >> >> Perhaps this table will help: > > > > >> >> >> > > > > >> >> >> Offer is level "B". I'll use level "A" to indicate a > > > > >> lower level, > > > > >> >> >> and "C" for a higher one (A < B < C). I'm assuming > > > > the offer > > > > >> >> >> includes level-upgrade-allowed=1. > > > > >> >> >> > > > > >> >> >> > > > > >> >> >> Answer level: lower (A) same (B) > > > higher (C) > > > > >> >> >> > > > > >> >> >> Offerer can send: A B C > > > > >> >> >> Answerer can send: A* B B > > > > >> >> >> > > > > >> >> > > > > > >> >> >In the right case (the answer includes level C), > > what if the > > > > >> >> >offerer's receiveing capability is actually lower than C? > > > > >> >> > > > > >> >> Then they shouldn't answer with "C". They should > > answer with > > > > >> >> whatever level they do support. The point of this is > > > > to allow the > > > > >> >> answerer to offer to receive a higher level; they get to > > > > >> choose what > > > > >> >> that level is. > > > > >> > > > > > >> >Now with the correct reading of the table. Again, that > > > > just makes a > > > > >> >difference on receiving or sending capability, not the > > > > >> conclusion. You > > > > >> >are basically assuming that the offerer's sending (i.e. > > > encoding) > > > > >> >capability is not limited, i.e. it can send whatever high > > > > >> level the answer may include. > > > > >> >How can that assumption be correct? > > > > >> > > > > >> You need to think about how level works in H.264. > > > > >> > > > > >> Remember we're only changing level, not constraints or > > profiles. > > > > >> > > > > >> Levels imply details about the maximum frame size, maximum > > > > >> macroblocks per second, maximum bitrate, etc, and each > > > level is a > > > > >> superset of the next-lower level. Using a level doesn't > > > > mean you (as > > > > >> an encoder) have to hit those maximums. If you encode a > > > > stream using > > > > >> the parameters of a lower level (i.e. > > > > >> using lower maximums), it's decodable by a higher-level > > > > decoder, even > > > > >> if you set the parameter sets to the higher level. > > > > >> > > > > >> Even more importantly, there's no apparent > requirement to send > > > > >> exactly the level given by the profile-level-id; sending > > > > lower levels > > > > >> (with the correct profile and constraints) appears to be > > > just fine > > > > >> (note that this interacts with parameter-set handling - > > > > you need to > > > > >> deal with making sure the decoder has correct parameter > > > > sets, as you > > > > >> always do). > > > > >> > > > > >> From 3984: > > > > >> > > > > >> If the profile-level-id parameter is used to indicate > > > > properties > > > > >> of a > > > > >> NAL unit stream, it indicates the profile and level > > > > that a decoder > > > > >> has > > > > >> to support in order to comply with [1] when it decodes > > > > the stream. > > > > >> > > > > >> and > > > > >> > > > > >> If the profile-level-id parameter is used for > > > > capability exchange > > > > >> or > > > > >> session setup procedure, it indicates the profile > > > that the codec > > > > >> supports and the highest level supported for the > > > > signaled profile. > > > > >> > > > > >> Note "highest level". And: > > > > >> > > > > >> The level conveyed in the value of the profile-level-id > > > > parameter > > > > >> MUST > > > > >> be such that the receiver is fully capable of supporting. > > > > >> > > > > >> and > > > > >> o Parameters used for declaring receiver > > capabilities are in > > > > >> general > > > > >> downgradable; i.e., they express the upper limit for > > > > a sender's > > > > >> possible behavior. Thus a sender MAY select to set > > > > its encoder > > > > >> using only lower/lesser or equal values of these > > > parameters. > > > > >> [snip] > > > > >> o Parameters declaring a configuration point are not > > > > downgradable, > > > > >> with the exception of the level part of the > > > > "profile-level-id" > > > > >> parameter. This expresses values a receiver expects > > > > to be used > > > > >> and must be used verbatim on the sender side. > > > > >> > > > > >> > > > > >> So, to summarize, if in response to an offer with > > > > >> level-upgrade-allowed=1, the answer includes a level > > > > higher than the > > > > >> offerer supports: > > > > >> > > > > >> * The offerer can encode a stream as if it's a higher > > > > level (including > > > > >> parameter sets), but using the encode settings of a > > > lower level > > > > >> that it > > > > >> supports. > > > > >> * The offerer can encode a stream using a lower level, > > including > > > > >> lower-level parameter sets. > > > > >> > > > > >> In both cases, the parameter sets must be conveyed to the > > > > answerer in > > > > >> some manner; the mechanisms that would make the most > sense are > > > > >> in-band parameter sets (with all that implies), or using > > > > >> sprop-level-parameter-sets including levels above the > > > level in the > > > > >> offered profile-level-id, so that the answer can select > > > > one of those > > > > >> levels and thus install those parameter sets. > > > > >> > > > > >> None of this requires any further modification to 3984bis > > > > that I can > > > > >> see - just allowing level-upgrade-allowed (or > > > > >> level-asymmetric-allowed). > > > > >> > > > > >> -- > > > > >> Randell Jesup, Worldgate (developers of the Ojo > > > > videophone), ex-Amiga > > > > >> OS team rjesup@wgate.com "The fetters imposed on liberty > > > > at home have > > > > >> ever been forged out of the weapons provided for > > defence against > > > > >> real, pretended, or imaginary dangers from abroad." > > > > >> - James Madison, 4th US president (1751-1836) > > > > >> > > > > >> > > > > > > > > > > > > -- > > > > Randell Jesup, Worldgate (developers of the Ojo > > > videophone), ex-Amiga > > > > OS team rjesup@wgate.com "The fetters imposed on liberty at > > > home have > > > > ever been forged out of the weapons provided for defence > > > against real, > > > > pretended, or imaginary dangers from abroad." > > > > - James Madison, 4th US president (1751-1836) > > > > > > > > > > > > > > > > > _______________________________________________ > > > Audio/Video Transport Working Group > > > avt@ietf.org > > > https://www.ietf.org/mailman/listinfo/avt > > > > > > > > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > > > > > > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www.ietf.org/mailman/listinfo/avt From yekuiwang@huawei.com Wed May 20 12:21:45 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA2BB3A67ED for ; Wed, 20 May 2009 12:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.29 X-Spam-Level: X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 tests=[AWL=0.309, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RrKfiN1dd+4S for ; Wed, 20 May 2009 12:21:43 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id C4B503A6AB1 for ; Wed, 20 May 2009 12:20:48 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJY003B6J5D89@usaga04-in.huawei.com> for avt@ietf.org; Wed, 20 May 2009 14:22:26 -0500 (CDT) Received: from W90946 ([10.51.0.1]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJY009F6J57P4@usaga04-in.huawei.com> for avt@ietf.org; Wed, 20 May 2009 14:22:25 -0500 (CDT) Date: Wed, 20 May 2009 15:22:16 -0400 From: Ye-Kui Wang In-reply-to: <003b01c9d97c$a6746db0$f35d4910$%roni@huawei.com> To: 'Roni Even' , 'Randell Jesup' Message-id: <4F398858F38D4187AA9D7DC67C8C0F09@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcnZCPICoe11EvE0SWm5FzsO7f0Y0AAWLd3wAAB7VEAAAMVlMAACBtvQAAESjxAAAJ/cEAABrKOgAADSAcA= iPlanet-SMTP-Warning: Lines longer than SMTP allows found and truncated. References: <04CAD96D4C5A3D48B1919248A8FE0D540943CDB9@xmb-sjc-215.amer.cisco.com> <2713212F2F334A15AB3DB03E1BB45156@china.huawei.com> <4A092C12.8080704@rogers.com> <5E07A2E74C0749B7A84371EE422E90C6@china.huawei.com> <545DD1B15C9A42F0B1729CC02FFC6348@china.huawei.com> <2068ACFCE9FA4013865E833F38057DDB@china.huawei.com> <6e9223710905190853p133b630cud234027c753916ed@mail.gmail.com> <686CE89178A540B3BBFD761A3DEBC494@china.huawei.com> <1C47D7182AB24F758DC60913784EBD37@china.huawei.com> Cc: ron.even.tlv@gmail.com, 'stephen botzko' , 'Tom Taylor' , avt@ietf.org Subject: Re: [AVT] Q for 3984bis-06 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 19:21:45 -0000 Roni, > Does this mean that you are considering adding level upgrade > but just arguing the text? Yes, unless it is finally concluded that there is no need or there is a big problem that does not worth the addition. BR, YK > -----Original Message----- > From: Roni Even [mailto:Even.roni@huawei.com] > Sent: Wednesday, May 20, 2009 2:56 PM > To: 'Ye-Kui Wang'; 'Randell Jesup' > Cc: ron.even.tlv@gmail.com; 'Tom Taylor'; avt@ietf.org; > 'stephen botzko' > Subject: RE: [AVT] Q for 3984bis-06 > > YK, > Does this mean that you are considering adding level upgrade > but just arguing the text? > > Anyhow Tom will need to call for a consensus on the change > based on the long discussion starting with the email from > Ashish (May 4th) > > Roni > > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > Behalf Of Ye-Kui Wang > Sent: Wednesday, May 20, 2009 9:11 PM > To: 'Roni Even'; 'Randell Jesup' > Cc: ron.even.tlv@gmail.com; 'Tom Taylor'; avt@ietf.org; > 'stephen botzko' > Subject: Re: [AVT] Q for 3984bis-06 > > > Roni, > > Right, we are discussing possible approaches to acheive level > upgrade. The hottest one has been what Randell proposed > (level-upgrade-allowed), but it seems that there is something > disconnecting Randell and myself, and we are working hard to > find that out :-) I believe all the discussions are good to > help us making a fully informed decision. > > BR, YK > > > -----Original Message----- > > From: Roni Even [mailto:Even.roni@huawei.com] > > Sent: Wednesday, May 20, 2009 2:00 PM > > To: 'Ye-Kui Wang'; 'Randell Jesup' > > Cc: ron.even.tlv@gmail.com; 'Tom Taylor'; 'stephen botzko'; > > avt@ietf.org > > Subject: RE: [AVT] Q for 3984bis-06 > > > > YK, > > > > The semantics of the parameters now is correct, what I was > saying is > > that there may be a difference between what a device is > offering and > > what the device can do in terms of processing, this can > happen due to > > other decisions like configuration and it may go higher if > the other > > side indicates that it can do so. > > > > I think allowing level upgrade by the answerer is what all > the people > > discussing the topic draft are suggesting (Ingemar, > Randell, Jonathan, > > Magnus and others). I just gave another example where it can happen. > > Maybe clarify that the level is a receive capability will help. > > > > Jonathan Lennox even suggests " Architecturally, I think it > would be > > cleanest if H.264's non sprop-* parameters all have SDP's standard > > receive-side semantics, rather than offer/answer semantics." > > > > Roni Even > > -----Original Message----- > > From: Ye-Kui Wang [mailto:yekuiwang@huawei.com] > > Sent: Wednesday, May 20, 2009 8:25 PM > > To: 'Roni Even'; 'Randell Jesup' > > Cc: ron.even.tlv@gmail.com; 'Tom Taylor'; 'stephen botzko'; > > avt@ietf.org > > Subject: RE: [AVT] Q for 3984bis-06 > > > > > > Roni, > > > > > -----Original Message----- > > > From: Roni Even [mailto:Even.roni@huawei.com] > > > Sent: Wednesday, May 20, 2009 12:41 PM > > > To: 'Ye-Kui Wang'; 'Randell Jesup' > > > Cc: ron.even.tlv@gmail.com; 'Tom Taylor'; 'stephen botzko'; > > > avt@ietf.org > > > Subject: RE: [AVT] Q for 3984bis-06 > > > > > > YK, > > > An offer of level 1.3 is just an offer, it is not > necessarily what > > > the device can do. The reasons for offering a lower level can be > > > due to multiple reasons, like some configuration of the > terminal and > > > not based on encoder/decoder performance. > > > > > > > If this is the case, then the current semantics of > profile-level-id is > > simply incorrect as it reads. > > > > > Having said that I would like to point out that in most cases you > > > can get higher functionality by using other parameters > like offering > > > level 3.1 and using max-fs, max-br and max-cpb parameter to offer > > > support for HD picture (using max-fs and > > > max-cpb) at higher bit rate (based on max-br) which are > over level > > > 3.1 according to table A-1 in H.264. This is very typical > in video > > > conferencing applications if the offerer cannot support the maxBR > > > for level 4 in table A-1. > > > > Correct. > > > > > I think that in this case it is reasonable for the answer > to signal > > > level 4 since it gives similar resolution but hinting that it can > > > encode and decode higher bit rate. This will not break > > > interoperability and make it simpler for the answerer. > > > > I don't think this is correct according to either RFC 3984 > or the bis. > > As you said earlier, it is allowed to signal level 3.1, and to use > > those max-* parameters to indicate that the device has > higher than 3.1 > > capability in a particular aspect, but not the other way > round. If you > > signal level 4, there is no way to tell which aspect of the > capability > > is lower than level 4. This is simply not what the spec > says. If you > > think this way should be supported, you must propose it and make it > > said in the spec. > > > > BR, YK > > > > > > > > Roni > > > > > > -----Original Message----- > > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] > On Behalf > > > Of Ye-Kui Wang > > > Sent: Wednesday, May 20, 2009 7:07 PM > > > To: 'Randell Jesup' > > > Cc: ron.even.tlv@gmail.com; 'Tom Taylor'; 'stephen botzko'; > > > avt@ietf.org > > > Subject: Re: [AVT] Q for 3984bis-06 > > > > > > > > > Typo: encoded -> decode. So, the sentence should be as follows. > > > > > > " The whole point is, if the offer contians level 1.3 (per > > > 3984 or the bis > > > draft) with sendrecv or no direction attribute, then level > > > 1.3 is the highest it can both encoded and encode. In > this case, it > > > simply cannot encode above level 1.3. " > > > > > > BTW, it is not absolutely prohibited to change the semantics of > > > profile-level-id, I am just saying that you need to change the > > > semantics. In addition, if the encoding/sending > capability and the > > > decoding/receiving capability is different, both > capabiilties should > > > be expressed. One way is to use different direction > attributes (and > > > separate SDP), which was considered not perfect. The > other way is, > > > as I mentioned earlier, to use two parameters, one for each. > > > > > > BR, YK > > > > > > > -----Original Message----- > > > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > > > Behalf Of > > > > Ye-Kui Wang > > > > Sent: Wednesday, May 20, 2009 11:52 AM > > > > To: 'Randell Jesup' > > > > Cc: ron.even.tlv@gmail.com; 'stephen botzko'; > avt@ietf.org; 'Tom > > > > Taylor' > > > > Subject: Re: [AVT] Q for 3984bis-06 > > > > > > > > > > > > > For example, if the offer is 1.3 with > > > > level-upgrade-allowed=1, and the > > > > > answer is level 3.1, then the offerer can send at any level > > > > up to and > > > > > including level 3.1. It could send level 2.0 if that's the > > > > highest it > > > > > can encode. > > > > > > > > The whole point is, if the offer contians level 1.3 (per > > > 3984 or the > > > > bis > > > > draft) with sendrecv or no direction attribute, then level > > > > 1.3 is the highest it can both encoded and encode. In > > this case, it > > > > simply cannot encode above level 1.3. > > > > > > > > Text in 3984: > > > > If the profile-level-id parameter > > > is used for > > > > capability exchange or session setup > > > > procedure, > > > > it indicates the profile that the codec > > > > supports and the highest level > > > > supported for the signaled profile. > > > > > > > > BR, YK > > > > > > > > > -----Original Message----- > > > > > From: Randell Jesup [mailto:rjesup@wgate.com] > > > > > Sent: Wednesday, May 20, 2009 1:08 AM > > > > > To: Ye-Kui Wang > > > > > Cc: 'stephen botzko'; ron.even.tlv@gmail.com; 'Tom Taylor'; > > > > > avt@ietf.org > > > > > Subject: Re: [AVT] Q for 3984bis-06 > > > > > > > > > > Ye-Kui Wang writes: > > > > > >> So, to summarize, if in response to an offer with > > > > > >> level-upgrade-allowed=1, the answer includes a level > > > > > higher than the > > > > > >> offerer supports: > > > > > >> > > > > > >> * The offerer can encode a stream as if it's a higher > > > > > level (including > > > > > >> parameter sets), but using the encode settings of a > > > > > lower level that > > > > > >> it supports. > > > > > > > > > > > >So, in your interpretation, the offerer sending a higher > > > > level just > > > > > >means that it sends sequence parameter sets containing > > > the higher > > > > > >level, but the bitstream characteristics are still > > > > restricted by the > > > > > >lower level. How could this bring any practical > > > usefulness? In the > > > > > >example, offer includes level B (e.g. spatial resolution up > > > > > to QVGA), > > > > > >and the answer includes a higher level C (e.g. spatial > > > > > resolution up to > > > > > >VGA), then both sides still send and receive up to QVGA > > > > > resolution, but > > > > > >the offer includes sequence parameter sets include the level > > > > > value C. Why is this useful at all? > > > > > > > > > > You asked a different question: > > > > > > > > > > >> >Now with the correct reading of the table. Again, that > > > > > just makes a > > > > > >> >difference on receiving or sending capability, not the > > > > > conclusion. > > > > > >> >You are basically assuming that the offerer's > sending (i.e. > > > > > >> >encoding) capability is not limited, i.e. it can send > > > > > whatever high > > > > > >> >level the answer may include. How can that assumption > > > > be correct? > > > > > > > > > > You asked about sending at "whatever high level the > answer may > > > > > include". > > > > > My response shows that you don't have to send at an > > > > arbitrarily-high > > > > > level > > > > > - you can send at the highest level you support. > > > > > > > > > > For example, if the offer is 1.3 with > > > > level-upgrade-allowed=1, and the > > > > > answer is level 3.1, then the offerer can send at any level > > > > up to and > > > > > including level 3.1. It could send level 2.0 if that's the > > > > highest it > > > > > can encode. > > > > > > > > > > >BR, YK > > > > > > > > > > > >> -----Original Message----- > > > > > >> From: Randell Jesup [mailto:rjesup@wgate.com] > > > > > >> Sent: Wednesday, May 20, 2009 12:29 AM > > > > > >> To: Ye-Kui Wang > > > > > >> Cc: 'stephen botzko'; ron.even.tlv@gmail.com; 'Tom > Taylor'; > > > > > >> avt@ietf.org > > > > > >> Subject: Re: [AVT] Q for 3984bis-06 > > > > > >> > > > > > >> Ye-Kui Wang writes: > > > > > >> > > > > > >> >I shortened the text. > > > > > >> > > > > > > >> >> If the offerer is legacy, then they don't include > > > > > >> >> level-upgrade-allowed, and as stated the answerer is not > > > > > >> allowed to > > > > > >> >> upgrade the level. If the answerer is legacy, then they > > > > > >> will ignore > > > > > >> >> level-upgrade-allowed, and won't upgrade the level. So > > > > > >> those 3 cases are all handled. > > > > > >> > > > > > > >> >OK. But it is possible that the answerer is new but does > > > > > not want to > > > > > >> >upgrade the level in an offer/answer process. It would be > > > > > certainly > > > > > >> >useful that the answerer lets the other side know > whether it > > > > > >> is new or > > > > > >> >legacy. Therefore, I'd prefer to include > > > > > >> level-upgrade-allowed equal to > > > > > >> >1 if the device is new (does understand the parameter and > > > > > >> allows level > > > > > >> >upgrade). Note that something is allowed does not mean it > > > > > is in use. > > > > > >> > > > > > >> The answerer could do that, and I don't have a problem > > > > with it (it > > > > > >> doesn't hurt anything), but I don't see how it's useful > > > > in any way. > > > > > >> > > > > > >> >> >The conflict is at the offerer's side. It includes a > > > > > lower level, > > > > > >> >> >but you are proposing requires that the offerer can > > > > > >> receive a higher > > > > > >> >> >level. To do this, you must change the current > > > semantics of > > > > > >> >> >profile-level-id. > > > > > >> >> > > > > > >> >> No, unless we decide to take the option mentioned in my > > > > > >> table (change > > > > > >> >> it to "level-asymmetry-allowed"). Then (and only then) > > > > > could the > > > > > >> >> offerer could receive a level above what they offered. > > > > > >> > > > > > > >> >Sorry, I mis-read your table. But that just makes a > > > > difference on > > > > > >> >receiving or sending capability, not the > conclusion. In the > > > > > >> righ case > > > > > >> >in the table (i.e. offer includes B, and answer > > > > includes C). The > > > > > >> >current semantics say that the offerer would only > be able to > > > > > >> send B and > > > > > >> >lower. But you want the offerer to be able to send C which > > > > > >> is higher than B. > > > > > >> > > > > > >> I don't understand what you're trying to say here. That's > > > > > the point > > > > > >> of level upgrade. And the offerer is still sending > > at a level > > > > > >> specified in the answers profile-level-id. > > > > > >> Perhaps you're just saying "yes, this means the offerer > > > > > might end up > > > > > >> sending a stream at a higher level than it offered", > > > > which is the > > > > > >> whole point of level upgrade. > > > > > >> > > > > > >> >> >> Perhaps this table will help: > > > > > >> >> >> > > > > > >> >> >> Offer is level "B". I'll use level "A" to indicate a > > > > > >> lower level, > > > > > >> >> >> and "C" for a higher one (A < B < C). I'm assuming > > > > > the offer > > > > > >> >> >> includes level-upgrade-allowed=1. > > > > > >> >> >> > > > > > >> >> >> > > > > > >> >> >> Answer level: lower (A) same (B) > > > > higher (C) > > > > > >> >> >> > > > > > >> >> >> Offerer can send: A B > C > > > > > >> >> >> Answerer can send: A* B > B > > > > > >> >> >> > > > > > >> >> > > > > > > >> >> >In the right case (the answer includes level C), > > > what if the > > > > > >> >> >offerer's receiveing capability is actually > lower than C? > > > > > >> >> > > > > > >> >> Then they shouldn't answer with "C". They should > > > answer with > > > > > >> >> whatever level they do support. The point of this is > > > > > to allow the > > > > > >> >> answerer to offer to receive a higher level; they get to > > > > > >> choose what > > > > > >> >> that level is. > > > > > >> > > > > > > >> >Now with the correct reading of the table. Again, that > > > > > just makes a > > > > > >> >difference on receiving or sending capability, not the > > > > > >> conclusion. You > > > > > >> >are basically assuming that the offerer's sending (i.e. > > > > encoding) > > > > > >> >capability is not limited, i.e. it can send whatever high > > > > > >> level the answer may include. > > > > > >> >How can that assumption be correct? > > > > > >> > > > > > >> You need to think about how level works in H.264. > > > > > >> > > > > > >> Remember we're only changing level, not constraints or > > > profiles. > > > > > >> > > > > > >> Levels imply details about the maximum frame size, maximum > > > > > >> macroblocks per second, maximum bitrate, etc, and each > > > > level is a > > > > > >> superset of the next-lower level. Using a level doesn't > > > > > mean you (as > > > > > >> an encoder) have to hit those maximums. If you encode a > > > > > stream using > > > > > >> the parameters of a lower level (i.e. > > > > > >> using lower maximums), it's decodable by a higher-level > > > > > decoder, even > > > > > >> if you set the parameter sets to the higher level. > > > > > >> > > > > > >> Even more importantly, there's no apparent > > requirement to send > > > > > >> exactly the level given by the profile-level-id; sending > > > > > lower levels > > > > > >> (with the correct profile and constraints) appears to be > > > > just fine > > > > > >> (note that this interacts with parameter-set handling - > > > > > you need to > > > > > >> deal with making sure the decoder has correct parameter > > > > > sets, as you > > > > > >> always do). > > > > > >> > > > > > >> From 3984: > > > > > >> > > > > > >> If the profile-level-id parameter is used to indicate > > > > > properties > > > > > >> of a > > > > > >> NAL unit stream, it indicates the profile and level > > > > > that a decoder > > > > > >> has > > > > > >> to support in order to comply with [1] when it decodes > > > > > the stream. > > > > > >> > > > > > >> and > > > > > >> > > > > > >> If the profile-level-id parameter is used for > > > > > capability exchange > > > > > >> or > > > > > >> session setup procedure, it indicates the profile > > > > that the codec > > > > > >> supports and the highest level supported for the > > > > > signaled profile. > > > > > >> > > > > > >> Note "highest level". And: > > > > > >> > > > > > >> The level conveyed in the value of the profile-level-id > > > > > parameter > > > > > >> MUST > > > > > >> be such that the receiver is fully capable of > supporting. > > > > > >> > > > > > >> and > > > > > >> o Parameters used for declaring receiver > > > capabilities are in > > > > > >> general > > > > > >> downgradable; i.e., they express the upper limit for > > > > > a sender's > > > > > >> possible behavior. Thus a sender MAY select to set > > > > > its encoder > > > > > >> using only lower/lesser or equal values of these > > > > parameters. > > > > > >> [snip] > > > > > >> o Parameters declaring a configuration point are not > > > > > downgradable, > > > > > >> with the exception of the level part of the > > > > > "profile-level-id" > > > > > >> parameter. This expresses values a receiver expects > > > > > to be used > > > > > >> and must be used verbatim on the sender side. > > > > > >> > > > > > >> > > > > > >> So, to summarize, if in response to an offer with > > > > > >> level-upgrade-allowed=1, the answer includes a level > > > > > higher than the > > > > > >> offerer supports: > > > > > >> > > > > > >> * The offerer can encode a stream as if it's a higher > > > > > level (including > > > > > >> parameter sets), but using the encode settings of a > > > > lower level > > > > > >> that it > > > > > >> supports. > > > > > >> * The offerer can encode a stream using a lower level, > > > including > > > > > >> lower-level parameter sets. > > > > > >> > > > > > >> In both cases, the parameter sets must be conveyed to the > > > > > answerer in > > > > > >> some manner; the mechanisms that would make the most > > sense are > > > > > >> in-band parameter sets (with all that implies), or using > > > > > >> sprop-level-parameter-sets including levels above the > > > > level in the > > > > > >> offered profile-level-id, so that the answer can select > > > > > one of those > > > > > >> levels and thus install those parameter sets. > > > > > >> > > > > > >> None of this requires any further modification to 3984bis > > > > > that I can > > > > > >> see - just allowing level-upgrade-allowed (or > > > > > >> level-asymmetric-allowed). > > > > > >> > > > > > >> -- > > > > > >> Randell Jesup, Worldgate (developers of the Ojo > > > > > videophone), ex-Amiga > > > > > >> OS team rjesup@wgate.com "The fetters imposed on liberty > > > > > at home have > > > > > >> ever been forged out of the weapons provided for > > > defence against > > > > > >> real, pretended, or imaginary dangers from abroad." > > > > > >> - James Madison, 4th US president (1751-1836) > > > > > >> > > > > > >> > > > > > > > > > > > > > > > -- > > > > > Randell Jesup, Worldgate (developers of the Ojo > > > > videophone), ex-Amiga > > > > > OS team rjesup@wgate.com "The fetters imposed on liberty at > > > > home have > > > > > ever been forged out of the weapons provided for defence > > > > against real, > > > > > pretended, or imaginary dangers from abroad." > > > > > - James Madison, 4th US president (1751-1836) > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Audio/Video Transport Working Group avt@ietf.org > > > > https://www.ietf.org/mailman/listinfo/avt > > > > > > > > > > > > > _______________________________________________ > > > Audio/Video Transport Working Group > > > avt@ietf.org > > > https://www.ietf.org/mailman/listinfo/avt > > > > > > > > > > > > > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > > From john.lazzaro@gmail.com Wed May 20 12:34:57 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5A6C28C1E7 for ; Wed, 20 May 2009 12:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DUf9KVYgFIHb for ; Wed, 20 May 2009 12:34:56 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.244]) by core3.amsl.com (Postfix) with ESMTP id B53D728C1DD for ; Wed, 20 May 2009 12:34:56 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id c3so478924ana.4 for ; Wed, 20 May 2009 12:36:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=CZBjMSDDq5sixzv9VFNHBWlt0d7N7+vANU/jo3g/o90=; b=r7UHXJ8/DzPLonXmrYWZGMMFqV+ze3jdUwTBJ9Vw7QBz7y/gTy3hDmena1GcpRiOVT IirtSQ6/7d6mQwAx1FU0aC0yRsFX2XY37FuFvAi+FoR+hm8isp3Mo90kcq7BdHGF1Bsg TB58ez70ZazG0MY0D1e8o60ED+LXuxSDzllN4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=SHe7fMNBfmxkej25Cjh65CVzIvmsJyMsiouaz85Z4HWKA1lOF+FRcOwcWgte4xFZPr uZQd0y0P43cJ3b6VG+FAu+1rMMXzqyw8Slz6dk6YsAj6VLh+D2nw8UBqF68R2y9eBDCL iCyv5xeQImTO/LGsgUvxsGZ3KFmwMfqivCD50= MIME-Version: 1.0 Received: by 10.100.140.15 with SMTP id n15mr3312775and.83.1242848192143; Wed, 20 May 2009 12:36:32 -0700 (PDT) In-Reply-To: <31d1be720905200905o53281cbja084ea69cf30ec0@mail.gmail.com> References: <31d1be720905200905o53281cbja084ea69cf30ec0@mail.gmail.com> Date: Wed, 20 May 2009 12:36:31 -0700 Message-ID: <302f570905201236i5f827d61ka082a83eee41dcc5@mail.gmail.com> From: John Lazzaro To: Greg Herlein Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: http-live-streaming-review@group.apple.com, David Singer , avt@ietf.org Subject: Re: [AVT] iPhone streaming Internet-Draft posted X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 19:34:58 -0000 On Wed, May 20, 2009 at 9:05 AM, Greg Herlein wrote: > Yes, it was discussed earlier.=A0 John Lazzaro raised some questions that= were > raised several years ago in regards to this being a bad idea.=A0 I have n= ot > seen anyone from Apple respond to that. Just to clarify ... I posted the minutes from the AVT session of the IETF meeting that shot down the earlier RTSP-over-HTTP standardization attempt ... so that newcomers that are proponents of that approach would know the AVT history behind the idea. That was my sole intention, at the moment I'm remaining neutral, since I haven't had time to read the draft (yet). As an aside, Vint Cerf gave a talk here at Berkeley a few years ago, and he was rather pessimistic about the future of media streaming technologies for stored content. He felt that file downloads had won the war for stored audio, and that video would follow the same path once network bandwidth caught up, and that would happen sooner than many people believe. Something to think about ... --=20 John Lazzaro http://www.cs.berkeley.edu/~lazzaro john [dot] lazzaro [at] gmail [dot] com From tom.taylor@rogers.com Thu May 21 00:34:39 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70CC43A6DD3 for ; Thu, 21 May 2009 00:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.53 X-Spam-Level: X-Spam-Status: No, score=-1.53 tagged_above=-999 required=5 tests=[AWL=-0.419, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IIoHQlo7RY3F for ; Thu, 21 May 2009 00:34:38 -0700 (PDT) Received: from smtp125.rog.mail.re2.yahoo.com (smtp125.rog.mail.re2.yahoo.com [206.190.53.30]) by core3.amsl.com (Postfix) with SMTP id 4CA223A6C9A for ; Thu, 21 May 2009 00:34:38 -0700 (PDT) Received: (qmail 9255 invoked from network); 21 May 2009 07:36:14 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding; b=k7U7sJnddZ0DDNWN1IhjxRFY7+Dp+cs8ivIuwxL3JKELPl9967nrEb4Re+gEQhLaAnM2QiIqe7+8Y27hkhXZns6m/mBFL9icie6TTeC6+TocM6/foawkenFbsKJToQ0bQgPd4nAhYX8R89w9kkhb0ikqqxOkSPziOXm3Ogzy3BM= ; Received: from unknown (HELO ?156.106.219.107?) (tom.taylor@156.106.219.107 with plain) by smtp125.rog.mail.re2.yahoo.com with SMTP; 21 May 2009 07:36:14 -0000 X-YMail-OSG: YR.lxqYVM1n0LfE2RGzdaZ121ST6ukGkNe54_pxjw7pRBdUZgNIOi9RT8qvV3KBdnA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A15046C.5080600@rogers.com> Date: Thu, 21 May 2009 09:36:12 +0200 From: Tom Taylor User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: IETF AVT WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [AVT] Consensus on profile-level-id in 3984bis X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 07:34:39 -0000 I find a clear consensus that level upgrade capability is required in 3984bis. I find a consensus that modification of 3984bis is required to provide a practical realization of this capability. That should simplify subsequent discussion. Now I have a couple of questions. 1) Why does a peer care about a given implementation's sending capability? 2) The only interoperability problem I can see is that if a legacy implementation receives an ANSWER with a level higher than it has sent it will view that answer as invalid. Are there any other possible interoperability problems? Tom Taylor From Even.roni@huawei.com Thu May 21 00:53:26 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4985F3A6A9F for ; Thu, 21 May 2009 00:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.284 X-Spam-Level: X-Spam-Status: No, score=-1.284 tagged_above=-999 required=5 tests=[AWL=-0.789, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3fm1fF0riQW for ; Thu, 21 May 2009 00:53:25 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 4EA783A6A6B for ; Thu, 21 May 2009 00:53:25 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJZ002HZHZEG8@szxga04-in.huawei.com> for avt@ietf.org; Thu, 21 May 2009 15:54:50 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJZ00MBVHZEQV@szxga04-in.huawei.com> for avt@ietf.org; Thu, 21 May 2009 15:54:50 +0800 (CST) Received: from windows8d787f9 (bzq-79-181-118-116.red.bezeqint.net [79.181.118.116]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJZ00EGDHYZZ5@szxml01-in.huawei.com>; Thu, 21 May 2009 15:54:50 +0800 (CST) Date: Thu, 21 May 2009 10:53:39 +0300 From: Roni Even In-reply-to: <4A15046C.5080600@rogers.com> To: 'Tom Taylor' , 'IETF AVT WG' Message-id: <006701c9d9e9$51679500$f436bf00$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcnZ5vHYahm+xaYgSwy+KXlWWp6AbwAAcv7w References: <4A15046C.5080600@rogers.com> Subject: Re: [AVT] Consensus on profile-level-id in 3984bis X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 07:53:26 -0000 Tom, Inline Roni -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Tom Taylor Sent: Thursday, May 21, 2009 10:36 AM To: IETF AVT WG Subject: [AVT] Consensus on profile-level-id in 3984bis I find a clear consensus that level upgrade capability is required in 3984bis. I find a consensus that modification of 3984bis is required to provide a practical realization of this capability. That should simplify subsequent discussion. Now I have a couple of questions. 1) Why does a peer care about a given implementation's sending capability? If the peer wants to request a specific mode from the sender, for example by using image attribute mmusic draft. 2) The only interoperability problem I can see is that if a legacy implementation receives an ANSWER with a level higher than it has sent it will view that answer as invalid. Are there any other possible interoperability problems? This is the same as level downgrade which was not allowed in RFC 3984 and added in the bis draft. Please remember that support for a level implies support for lower levels. Tom Taylor _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www.ietf.org/mailman/listinfo/avt From yekuiwang@huawei.com Thu May 21 08:12:18 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 006483A6FBF for ; Thu, 21 May 2009 08:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9KiRloUvVS3D for ; Thu, 21 May 2009 08:12:16 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id DF02E3A6DB3 for ; Thu, 21 May 2009 08:12:16 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KK000CCC2ANNA@usaga02-in.huawei.com> for avt@ietf.org; Thu, 21 May 2009 08:13:35 -0700 (PDT) Received: from W90946 ([10.193.125.102]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KK000DJW2ADPF@usaga02-in.huawei.com> for avt@ietf.org; Thu, 21 May 2009 08:13:34 -0700 (PDT) Date: Thu, 21 May 2009 11:13:25 -0400 From: Ye-Kui Wang In-reply-to: <006701c9d9e9$51679500$f436bf00$%roni@huawei.com> To: 'Roni Even' , 'Tom Taylor' , 'IETF AVT WG' Message-id: <7779AD69A5E54F9F84E473BB4F4E1E71@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcnZ5vHYahm+xaYgSwy+KXlWWp6AbwAAcv7wAA5G9wA= References: <4A15046C.5080600@rogers.com> <006701c9d9e9$51679500$f436bf00$%roni@huawei.com> Subject: Re: [AVT] Consensus on profile-level-id in 3984bis X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 15:12:18 -0000 Another interoperability issue relates to the semantics change of the level part of profile-level-id. Currently, the level part, when used capability exchange or session setup, gives the upper limit of both decoding capability and encoding capability, as seen from the following two paragraphs excerpted from the bis draft (the same in spirit in 3984): "The profile-level-id parameter indicates the default sub-profile, i.e. the subset of coding tools that may have been used to generate the stream or that the receiver supports, and the default level of the stream or the receiver supports." "If the profile-level-id parameter is used for capability exchange or session setup procedure, it indicates the subset of coding tools, which is equal to the default sub-profile, and the highest level, which is equal to the default level, that the codec supports. All levels lower than the default level are also supported by the codec. " When level upgrade is allowed, then this semantics must change, such that the level part basically indicates only the decoding capability. This change of course creates different understandings between the two sides whenever one is legacy and the other is new. We have at least the following options to go to allow for level upgrade (the semantics change above is anyway needed): - To add "level-upgrade-allowed". - To add "level-upgrade-allowed" and another parameter, say sending-capability-level, to indicate the sending capability expressed as a level value. - To go wildly, by making all paramters not starting with "sprop-" as receiving capabilities. Another group of parameters not starting with "sprop-" can be optionally used to indicate sending capabilities. When these sending capability parameters are not present, the sending capabilities are by default equal to the receiving capabilties. A decision needs to be made which one to take. In any case, I hope a proponent could provide relatively mature text, including changes to semantics, offer/answer rules (including parameter sets considerations in offer/answer), declarative usage, SDP examples, and discussion of backward compatibility issues. Note that all the changes will also affect the SVC payload draft, as they basically need to be appropriately integrated to the SVC payload draft. BR, YK > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > Behalf Of Roni Even > Sent: Thursday, May 21, 2009 3:54 AM > To: 'Tom Taylor'; 'IETF AVT WG' > Subject: Re: [AVT] Consensus on profile-level-id in 3984bis > > Tom, > Inline > Roni > > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > Behalf Of Tom Taylor > Sent: Thursday, May 21, 2009 10:36 AM > To: IETF AVT WG > Subject: [AVT] Consensus on profile-level-id in 3984bis > > I find a clear consensus that level upgrade capability is > required in 3984bis. I find a consensus that modification of > 3984bis is required to provide a practical realization of > this capability. That should simplify subsequent discussion. > > Now I have a couple of questions. > > 1) Why does a peer care about a given implementation's > sending capability? > > If the peer wants to request a specific mode from the sender, > for example by using image attribute mmusic draft. > > 2) The only interoperability problem I can see is that if a > legacy implementation receives an ANSWER with a level higher > than it has sent it will view that answer as invalid. Are > there any other possible interoperability problems? > > This is the same as level downgrade which was not allowed in > RFC 3984 and added in the bis draft. Please remember that > support for a level implies support for lower levels. > > > Tom Taylor > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > From tom.taylor@rogers.com Thu May 21 08:59:59 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C542A3A67AE for ; Thu, 21 May 2009 08:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.307 X-Spam-Level: X-Spam-Status: No, score=-2.307 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KjWgYD+c6J9l for ; Thu, 21 May 2009 08:59:58 -0700 (PDT) Received: from smtp131.rog.mail.re2.yahoo.com (smtp131.rog.mail.re2.yahoo.com [206.190.53.36]) by core3.amsl.com (Postfix) with SMTP id 9E9B13A6A7F for ; Thu, 21 May 2009 08:59:58 -0700 (PDT) Received: (qmail 86289 invoked from network); 21 May 2009 16:01:32 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=a0+7GenGUIqG4L5QRvQTzENchH+2ARbf6fJETMHHplNkLwBBH3q8Ony5TLmQbLPlqt4t10ThLQqx5pp6y8zyhqGXESS/6Qkprqjk7Cfgr60qGTvI6hzd03VW2dNgnemjkn+kU4KDY6GTUo7XGnstB97IrNs1XVXIhDIgZuoXn7Y= ; Received: from unknown (HELO ?156.106.219.107?) (tom.taylor@156.106.219.107 with plain) by smtp131.rog.mail.re2.yahoo.com with SMTP; 21 May 2009 16:01:31 -0000 X-YMail-OSG: 27C0z94VM1nIHrzHC92nSCopsHNgvGjTjZAPp.91MqgiX_8ubE2FdnuVq2rTGw6WQA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A157ADA.8060900@rogers.com> Date: Thu, 21 May 2009 18:01:30 +0200 From: Tom Taylor User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: IETF AVT WG References: <4A15046C.5080600@rogers.com> <006701c9d9e9$51679500$f436bf00$%roni@huawei.com> <7779AD69A5E54F9F84E473BB4F4E1E71@china.huawei.com> In-Reply-To: <7779AD69A5E54F9F84E473BB4F4E1E71@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [AVT] Consensus on profile-level-id in 3984bis X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 15:59:59 -0000 It appears that the optimum outcome is to be able to signal both send and receive capability. The legacy approach loses some of this information, since profile-level-id contains the lesser of the two values. In a legacy-new interworking situation it seems unlikely that we can improve on this. That suggests that profile-level-id should retain its current semantics, and one or two new parameters (only one of which would be present in the offer or answer) would indicate two things: a) a value which is higher than the value given in profile-level-id; b) whether that value is a send or receive capability. If it's just one parameter, it would have to be double valued e.g., alternate-level-id="send,". If it is two parameters, the appropriate parameter to include would depend on which whether the capability being reported is send or receive, e.g., send-level-id= or recv-level-id= Another interoperability issue relates to the semantics change of the level > part of profile-level-id. Currently, the level part, when used capability > exchange or session setup, gives the upper limit of both decoding capability > and encoding capability, as seen from the following two paragraphs excerpted > from the bis draft (the same in spirit in 3984): > > "The profile-level-id parameter indicates the default sub-profile, i.e. the > subset of coding tools that may have been used to generate the stream or > that the receiver supports, and the default level of the stream or the > receiver supports." > > "If the profile-level-id parameter is used for capability exchange or > session setup procedure, it indicates the subset of coding tools, which is > equal to the default sub-profile, and the highest level, which is equal to > the default level, that the codec supports. All levels lower than the > default level are also supported by the codec. " > > When level upgrade is allowed, then this semantics must change, such that > the level part basically indicates only the decoding capability. This change > of course creates different understandings between the two sides whenever > one is legacy and the other is new. > > We have at least the following options to go to allow for level upgrade (the > semantics change above is anyway needed): > - To add "level-upgrade-allowed". > - To add "level-upgrade-allowed" and another parameter, say > sending-capability-level, to indicate the sending capability expressed as a > level value. > - To go wildly, by making all paramters not starting with "sprop-" as > receiving capabilities. Another group of parameters not starting with > "sprop-" can be optionally used to indicate sending capabilities. When these > sending capability parameters are not present, the sending capabilities are > by default equal to the receiving capabilties. > > A decision needs to be made which one to take. > > In any case, I hope a proponent could provide relatively mature text, > including changes to semantics, offer/answer rules (including parameter sets > considerations in offer/answer), declarative usage, SDP examples, and > discussion of backward compatibility issues. > > Note that all the changes will also affect the SVC payload draft, as they > basically need to be appropriately integrated to the SVC payload draft. > > BR, YK > ... From yekuiwang@huawei.com Thu May 21 10:58:53 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B4563A6C60 for ; Thu, 21 May 2009 10:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.305 X-Spam-Level: X-Spam-Status: No, score=-2.305 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWj845U7VdDl for ; Thu, 21 May 2009 10:58:52 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 376723A6BAD for ; Thu, 21 May 2009 10:58:52 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KK0008X7A0JKB@usaga02-in.huawei.com> for avt@ietf.org; Thu, 21 May 2009 11:00:19 -0700 (PDT) Received: from W90946 ([10.193.125.102]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KK000D6LA0EPF@usaga02-in.huawei.com> for avt@ietf.org; Thu, 21 May 2009 11:00:18 -0700 (PDT) Date: Thu, 21 May 2009 14:00:14 -0400 From: Ye-Kui Wang In-reply-to: <4A157ADA.8060900@rogers.com> To: 'Tom Taylor' , 'IETF AVT WG' Message-id: <13FD4842BF1E4920B287A7EDFCF8C4FF@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcnaLXxEvh7t+iTETaaFKrABDkILRgAD6Dmw References: <4A15046C.5080600@rogers.com> <006701c9d9e9$51679500$f436bf00$%roni@huawei.com> <7779AD69A5E54F9F84E473BB4F4E1E71@china.huawei.com> <4A157ADA.8060900@rogers.com> Subject: Re: [AVT] Consensus on profile-level-id in 3984bis X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 17:58:53 -0000 This should work. But the semantics profile-level-id still changes. The level part means the same when no the new parameters are not present; however if one, e.g., alternate-level-id="send,", is present, then the correponding capability, the sending capability in this example, is updated by the new parameter. BR, YK > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > Behalf Of Tom Taylor > Sent: Thursday, May 21, 2009 12:02 PM > To: IETF AVT WG > Subject: Re: [AVT] Consensus on profile-level-id in 3984bis > > It appears that the optimum outcome is to be able to signal > both send and receive capability. The legacy approach loses > some of this information, since profile-level-id contains the > lesser of the two values. In a legacy-new interworking > situation it seems unlikely that we can improve on this. > > That suggests that profile-level-id should retain its current > semantics, and one or two new parameters (only one of which > would be present in the offer or > answer) would indicate two things: > a) a value which is higher than the value given in profile-level-id; > b) whether that value is a send or receive capability. > > If it's just one parameter, it would have to be double valued > e.g., alternate-level-id="send,". > > If it is two parameters, the appropriate parameter to include > would depend on which whether the capability being reported > is send or receive, e.g., send-level-id= > or recv-level-id= but never both in the same stream. > > Ye-Kui Wang wrote: > > Another interoperability issue relates to the semantics > change of the > > level part of profile-level-id. Currently, the level part, > when used > > capability exchange or session setup, gives the upper limit of both > > decoding capability and encoding capability, as seen from the > > following two paragraphs excerpted from the bis draft (the > same in spirit in 3984): > > > > "The profile-level-id parameter indicates the default sub-profile, > > i.e. the subset of coding tools that may have been used to generate > > the stream or that the receiver supports, and the default > level of the > > stream or the receiver supports." > > > > "If the profile-level-id parameter is used for capability > exchange or > > session setup procedure, it indicates the subset of coding tools, > > which is equal to the default sub-profile, and the highest level, > > which is equal to the default level, that the codec supports. All > > levels lower than the default level are also supported by > the codec. " > > > > When level upgrade is allowed, then this semantics must > change, such > > that the level part basically indicates only the decoding > capability. > > This change of course creates different understandings > between the two > > sides whenever one is legacy and the other is new. > > > > We have at least the following options to go to allow for level > > upgrade (the semantics change above is anyway needed): > > - To add "level-upgrade-allowed". > > - To add "level-upgrade-allowed" and another parameter, say > > sending-capability-level, to indicate the sending > capability expressed > > as a level value. > > - To go wildly, by making all paramters not starting with > "sprop-" as > > receiving capabilities. Another group of parameters not > starting with > > "sprop-" can be optionally used to indicate sending > capabilities. When > > these sending capability parameters are not present, the sending > > capabilities are by default equal to the receiving capabilties. > > > > A decision needs to be made which one to take. > > > > In any case, I hope a proponent could provide relatively > mature text, > > including changes to semantics, offer/answer rules (including > > parameter sets considerations in offer/answer), declarative > usage, SDP > > examples, and discussion of backward compatibility issues. > > > > Note that all the changes will also affect the SVC payload > draft, as > > they basically need to be appropriately integrated to the > SVC payload draft. > > > > BR, YK > > > ... > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > From john.lazzaro@gmail.com Thu May 21 14:45:12 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21B8D3A6860 for ; Thu, 21 May 2009 14:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3viT+Cx-Xws7 for ; Thu, 21 May 2009 14:45:11 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.245]) by core3.amsl.com (Postfix) with ESMTP id D4E913A6823 for ; Thu, 21 May 2009 14:45:10 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id c3so1013555ana.4 for ; Thu, 21 May 2009 14:46:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=i6so0mkeCJk8UKT4TUGQANn9A/0hulW9nI6G5gll6sE=; b=adHvBHaOK7oSct4FylWIB88M3MtusJ1Rta/WgFy8+4w8EhqwMUIdvpcIrZRS1B3oo5 qLfJ7YZtaT2hb4p3gcBkDC6ctDzcQqi+jkE+E8YInIRS/pU9xY5/Qoho++e/uVf3XL0A k3DJnxud2d3MXluxjC5ngX4lhPCwPLHlFcHLE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=Y0m0hA4JVIuDurWG3HxX0NpDnu9O/CzL1XNasycUeiLy780DJou46TKjRZJTwPRQF8 we/Lw6kqFOJ3b+zSGW26YO50Uk7th1eexJv7kV5EgwIeifO1dyYqjWN6sIExjiP3FjsB bQvQeyL7LLuwIZkmZhUJqi0XCWkVUelk7htwo= MIME-Version: 1.0 Received: by 10.100.141.10 with SMTP id o10mr5737398and.152.1242942404320; Thu, 21 May 2009 14:46:44 -0700 (PDT) Date: Thu, 21 May 2009 14:46:44 -0700 Message-ID: <302f570905211446j7317a6f8o3d1e6a0b405a3568@mail.gmail.com> From: John Lazzaro To: avt@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [AVT] Comments on draft-pantos-http-live-streaming-00.txt ... X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 21:45:12 -0000 Hi everyone, Comments on draft-pantos-http-live-streaming-00.txt below. What jumped out at me was that this is a late-1990s approach to a problem ... but its almost 2010 ... In my view, the I-D is trying to do for audio what the AJAX client code for Google Maps does for image map tiles. Namely, pre-loading short media files over HTTP, to drive a user interface that the user perceives as continuous (and in the Google Maps case, responsive to user input). I haven't looked at HTML5 (yet), but I was under the impression one goal of its audio/video features is to provide the primitives to make it possible to implement the protocol described in draft-pantos-http-live-streaming-00.txt using AJAX techniques. If the feature set isn't there yet in HTML5 to do that, I think the time spent working on this I-D is better spent working within the HTML5 process to get the features that are needed. It seems to me that AJAX is a more natural way to implement this sort of "concatenation of pre-downloaded 10-second files" streaming. If there is AVT consensus that draft-pantos-http-live-streaming-00.txt's general approach is acceptable for a work-item, I'll do a second review of potential technical issues with the protocol itself ... -- John Lazzaro http://www.cs.berkeley.edu/~lazzaro john [dot] lazzaro [at] gmail [dot] com From gherlein@herlein.com Thu May 21 14:55:27 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2DD13A6E2A for ; Thu, 21 May 2009 14:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.695 X-Spam-Level: X-Spam-Status: No, score=-1.695 tagged_above=-999 required=5 tests=[AWL=0.281, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcbj808QMaoN for ; Thu, 21 May 2009 14:55:26 -0700 (PDT) Received: from mail-px0-f193.google.com (mail-px0-f193.google.com [209.85.216.193]) by core3.amsl.com (Postfix) with ESMTP id D0A263A6E71 for ; Thu, 21 May 2009 14:55:26 -0700 (PDT) Received: by pxi31 with SMTP id 31so1156118pxi.29 for ; Thu, 21 May 2009 14:57:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.13.17 with SMTP id q17mr1063011wfi.222.1242943023017; Thu, 21 May 2009 14:57:03 -0700 (PDT) In-Reply-To: <302f570905211446j7317a6f8o3d1e6a0b405a3568@mail.gmail.com> References: <302f570905211446j7317a6f8o3d1e6a0b405a3568@mail.gmail.com> Date: Thu, 21 May 2009 14:57:03 -0700 Message-ID: <31d1be720905211457n48a72e51y8a423a43b4b654dd@mail.gmail.com> From: Greg Herlein To: John Lazzaro Content-Type: multipart/alternative; boundary=001636e0a7fe5cefe0046a7339f8 Cc: avt@ietf.org Subject: Re: [AVT] Comments on draft-pantos-http-live-streaming-00.txt ... X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 21:55:28 -0000 --001636e0a7fe5cefe0046a7339f8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I concur. I'm willing to help look at some of the underpinnings (MPEG slitting/splicing for example) if there's sufficient interest that this *approach* worth further effort. Greg On Thu, May 21, 2009 at 2:46 PM, John Lazzaro wrote: > Hi everyone, > > Comments on draft-pantos-http-live-streaming-00.txt below. > > What jumped out at me was that this is a late-1990s > approach to a problem ... but its almost 2010 ... > > In my view, the I-D is trying to do for audio what the AJAX client code > for Google Maps does for image map tiles. Namely, pre-loading short > media files over HTTP, to drive a user interface that the user > perceives as continuous (and in the Google Maps case, > responsive to user input). > > I haven't looked at HTML5 (yet), but I was under the impression > one goal of its audio/video features is to provide the > primitives to make it possible to implement the protocol > described in draft-pantos-http-live-streaming-00.txt using > AJAX techniques. If the feature set isn't there yet in HTML5 > to do that, I think the time spent working on this I-D is better > spent working within the HTML5 process to get the features that > are needed. It seems to me that AJAX is a more natural way to > implement this sort of "concatenation of pre-downloaded 10-second > files" streaming. > > If there is AVT consensus that draft-pantos-http-live-streaming-00.txt's > general approach is acceptable for a work-item, I'll do a second review > of potential technical issues with the protocol itself ... > > -- > John Lazzaro > http://www.cs.berkeley.edu/~lazzaro > john [dot] lazzaro [at] gmail [dot] com > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > -- Greg Herlein www.herlein.com --001636e0a7fe5cefe0046a7339f8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I concur.=A0 I'm willing to help look at some of the underpinnings (MPE= G slitting/splicing for example) if there's sufficient interest that th= is *approach* worth further effort.

Greg

On Thu, May 21, 2009 at 2:46 PM, John Lazzaro <john.lazzaro@gmail.com> wr= ote:
Hi everyone,

Comments on draft-pantos-http-live-streaming-00.txt below.

What jumped out at me was that this is a late-1990s
approach to a problem ... but its almost 2010 ...

In my view, the I-D is trying to do for audio what the AJAX client code
for Google Maps does for image map tiles. Namely, pre-loading short
media files over HTTP, to drive a user interface that the user
perceives as continuous (and in the Google Maps case,
responsive to user input).

I haven't looked at HTML5 (yet), but I was under the impression
one goal of its audio/video features is to provide the
primitives to make it possible to implement the protocol
described in draft-pantos-http-live-streaming-00.txt using
AJAX techniques. =A0If the feature set isn't there yet in HTML5
to do that, I think the time spent working on this I-D is better
spent working within the HTML5 process to get the features that
are needed. =A0It seems to me that AJAX is a more natural way to
implement this sort of "concatenation of pre-downloaded 10-second
files" streaming.

If there is AVT consensus that draft-pantos-http-live-streaming-00.txt'= s
general approach is acceptable for a work-item, I'll do a second review=
of potential technical issues with the protocol itself ...

--
John Lazzaro
http://= www.cs.berkeley.edu/~lazzaro
john [dot] lazzaro [at] gmail [dot] com
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/avt



--
Greg Herlein
= www.herlein.com
--001636e0a7fe5cefe0046a7339f8-- From jose.rey@eu.panasonic.com Thu May 21 15:21:18 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F11D3A6D6E for ; Thu, 21 May 2009 15:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.898 X-Spam-Level: X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpF+qq+E0kOx for ; Thu, 21 May 2009 15:21:16 -0700 (PDT) Received: from cluster-a.mailcontrol.com (cluster-a.mailcontrol.com [85.115.52.190]) by core3.amsl.com (Postfix) with ESMTP id 6FF663A6DC7 for ; Thu, 21 May 2009 15:21:04 -0700 (PDT) Received: from rly21a.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly21a.srv.mailcontrol.com (MailControl) with ESMTP id n4LMMc0t015158 for ; Thu, 21 May 2009 23:22:40 +0100 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by rly21a.srv.mailcontrol.com (MailControl) id n4LMMaD1014962 for ; Thu, 21 May 2009 23:22:36 +0100 Received: from eundsmtpout01.pan.eu ([168.87.60.202]) by rly21a-eth0.srv.mailcontrol.com (envelope-sender ) (MIMEDefang) with ESMTP id n4LMMYv7014856; Thu, 21 May 2009 23:22:36 +0100 (BST) Received: from eundadmi01.pan.eu ([10.109.33.22]) by eundsmtpout01.pan.eu (Lotus Domino Release 7.0.2) with ESMTP id 2009052200223338-731058 ; Fri, 22 May 2009 00:22:33 +0200 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 7.0.3) with ESMTP id 2009052200222751-208022 ; Fri, 22 May 2009 00:22:27 +0200 Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de; Fri, 22 May 2009 00:21:43 +0200 Received: from [10.12.254.162] ([10.12.254.162]) by lan-ex-02.panasonic.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 May 2009 00:21:41 +0200 From: =?ISO-8859-1?Q?Jos=E9_Rey?= User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <81B9B88E2F9D574AA5328A85547CDE9101071D80@xmb-rtp-21d.amer.cisco.com> <49f1a1d6.190c660a.58fe.ffffa90e@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C80DA@xmb-sjc-215.amer.cisco.com> <49f208e8.05a0660a.5bd2.6764@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C81C9@xmb-sjc-215.amer.cisco.com> <49f211fc.07a5660a.3f7f.ffff8f4a@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8202@xmb-sjc-215.amer.cisco.com> <49f2efa2.1c215e0a.4454.ffffaf91@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8403@xmb-sjc-215.amer.cisco.com> <49f36ee2.0437560a.11df.1eef@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8405@xmb-sjc-215.amer.cisco.com> <49f387ca.0305560a.6657.4be7@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C840A@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D54092C840A@xmb-sjc-215.amer.cisco.com> X-OriginalArrivalTime: 21 May 2009 22:21:41.0583 (UTC) FILETIME=[842AFDF0:01C9DA62] X-TM-AS-Product-Ver: SMEX-7.0.0.1345-5.6.1016-16656.001 X-TM-AS-Result: No--31.507100-5.000000-31 X-TNEFEvaluated: 1 Message-ID: <4A15D40E.80509@eu.panasonic.com> Date: Fri, 22 May 2009 00:22:06 +0200 X-MIMETrack: Itemize by SMTP Server on EUNDADMI01/EUR/Matsushita(Release 7.0.3|September 26, 2007) at 22.05.2009 00:22:32, Serialize by Router on EUNDADMI01/EUR/Matsushita(Release 7.0.3|September 26, 2007) at 22.05.2009 00:22:33, Serialize complete at 22.05.2009 00:22:33, Itemize by SMTP Server on EUNDSMTPOUT01/EUR/PANEXTOUT(Release 7.0.2|September 26, 2006) at 05/22/2009 12:22:33 AM, Serialize by Router on EUNDSMTPOUT01/EUR/PANEXTOUT(Release 7.0.2|September 26, 2006) at 05/22/2009 12:22:35 AM, Serialize complete at 05/22/2009 12:22:35 AM Content-Type: multipart/alternative; boundary="------------060902040200060401030204" X-Scanned-By: MailControl A-06-00-00 (www.mailcontrol.com) on 10.65.1.131 Cc: Roni Even , avt@ietf.org, "Bill Ver Steeg \(versteb\)" Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 22:21:18 -0000 This is a multi-part message in MIME format. --------------060902040200060401030204 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hi all, sorry for jumping in.... I think one of the sources of confusion is that the attribute a=rtcp: is used once for specifying the destination port and once for specifying a receiving port, and in the same SDP (!). The destination port for RAMS-I packets sent by RS and the receiving port for RAMS-T. Which is also why different port numbers are used for RAMS-T and -R packets. I think the use of a=rtcp: in SSM is the problem here. Or the fact that we are mixing unicast and multicast, or both. Hope this helps, JLR Ali C. Begen (abegen) wrote: > > > >> -----Original Message----- >> From: Roni Even [mailto:ron.even.tlv@gmail.com] >> Sent: Saturday, April 25, 2009 2:58 PM >> To: Ali C. Begen (abegen); avt@ietf.org >> Cc: Bill Ver Steeg (versteb) >> Subject: RE: [AVT] New draft of "Rapid Acquisition of >> Multicast RTPSessions (RAMS)" available >> >> Ali, >> I looked at RFC 4570 and I assume that port 41001 is the port for the >> unicast RTCP reports from the receivers and according to >> > > Yes, indeed. > > >> section 3.2.1 of >> that RFC you also should have a RTCP-unicast specification. >> This is for the >> multicast receiver reports. >> > > Correct. We do have that line in our draft at the top right after the grouping lines: > > a=rtcp-unicast:rsi > > BR, > -acbegen > > >> Roni >> >> -----Original Message----- >> From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] >> Sent: Saturday, April 25, 2009 11:30 PM >> To: Roni Even; avt@ietf.org >> Cc: Bill Ver Steeg (versteb) >> Subject: RE: [AVT] New draft of "Rapid Acquisition of >> Multicast RTPSessions >> (RAMS)" available >> >> Here is the SDP. >> >> m=video 41000 RTP/AVPF 98 >> i=Primary Multicast Stream #2 >> c=IN IP4 224.1.1.2/255 >> a=source-filter: incl IN IP4 224.1.1.2 192.0.2.2 >> >> Source (192.0.2.2) sends the rtp packets to the multicast >> group (224.1.1.2) >> with a dest port 41000. >> >> a=rtpmap:98 MP2T/90000 >> a=rtcp:41001 IN IP4 192.0.2.1 >> >> The feedback target (RS) address for this SSM session is >> 192.0.2.1 and its >> port is 41001. This is the address/port where RR sends the RAMS-R, or >> receiver reports for the SSM session. >> >> a=rtcp-fb:98 nack >> a=rtcp-fb:98 nack ssli >> a=ssrc:123321 cname:iptv-ch32@rams.example.com >> a=mid:3 >> m=video 41002 RTP/AVPF 99 >> >> The retransmission packets go to port 41002. This is the port >> RRs listen to >> for retransmission and RAMS. >> >> i=Unicast Retransmission Stream #2 (Ret. and Rapid >> Acq. Support) >> c=IN IP4 192.0.2.1 >> >> This is where the retransmission packets come from, same as >> the feedback >> target (in this example). >> >> a=rtpmap:99 rtx/90000 >> a=rtcp:41003 >> >> This is where the RTCP packets for the retransmission session go. For >> example, RAMS-I goes to this port on RRs. RAMS-T goes to this >> port on RS. >> >> a=fmtp:99 apt=98; rtx-time=5000 >> a=mid:4 >> >> >> -acbegen >> >> >> >>> -----Original Message----- >>> From: Roni Even [mailto:ron.even.tlv@gmail.com] >>> Sent: Saturday, April 25, 2009 1:11 PM >>> To: Ali C. Begen (abegen); avt@ietf.org >>> Cc: Bill Ver Steeg (versteb) >>> Subject: RE: [AVT] New draft of "Rapid Acquisition of >>> Multicast RTPSessions (RAMS)" available >>> >>> Ali, >>> Can you please write three addresses from this strange SDP. >>> >>> 1. The address and port of multicast >>> >>> 2. The address and port of the RS where the RTCP FB should go to >>> >>> 3. The address and port on the RR where the unicast stream >>> should be sent to >>> >>> Roni >>> >>> -----Original Message----- >>> From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] >>> Sent: Saturday, April 25, 2009 11:02 PM >>> To: Roni Even; avt@ietf.org >>> Cc: Bill Ver Steeg (versteb) >>> Subject: RE: [AVT] New draft of "Rapid Acquisition of >>> Multicast RTPSessions >>> (RAMS)" available >>> >>> >>>> Ali, >>>> The example SDP is syntactically correct but it does not >>>> >>> say that the >>> >>>> rtp/rtcp mux will be used and it does not give the >>>> information to where the >>>> unicast stream will be sent when the RR sends a RAMS-R. >>>> >>> To my knowledge, the first line in the following SDP tells >>> the RRs on which >>> port they will receive the retransmission/burst packets. >>> >>> m=video 41002 RTP/AVPF 99 >>> i=Unicast Retransmission Stream #2 (Ret. and Rapid >>> Acq. Support) >>> c=IN IP4 192.0.2.1 >>> a=rtpmap:99 rtx/90000 >>> a=rtcp:41003 >>> a=fmtp:99 apt=98; rtx-time=5000 >>> a=mid:4 >>> >>> There is a typo, you are right. That "a=recvonly" line should >>> only exist in >>> the SDP sent to RRs. In the SDP sent to RS, we should rather have >>> "a=sendonly". I will make this correction in the next version. >>> >>> The feedback target for the SSM session and the RTCP port for the >>> retransmission session are also defined in the SDP. >>> >>> Hope this clarifies. >>> >>> BR, >>> -acbegen >>> >>> >>>> I am not sure why the unicast stream m-line has a port >>>> >>> number with an >>> >>>> attribute of recvonly. What is the use case for that. The >>>> only information >>>> that the RR will need is the RTCP port on the RS to where to >>>> send the RAMS-R >>>> message. >>>> Roni >>>> -----Original Message----- >>>> From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] >>>> Sent: Friday, April 24, 2009 10:37 PM >>>> To: Roni Even; avt@ietf.org >>>> Cc: Bill Ver Steeg (versteb) >>>> Subject: RE: [AVT] New draft of "Rapid Acquisition of >>>> Multicast RTPSessions >>>> (RAMS)" available >>>> >>>> This is a part of an example SDP sent to RS and RR in a SAP >>>> announcement, >>>> for example. So, the SDP describes what both parties should >>>> do (RR cannot >>>> say that he wants to receive this multicast on its favorite >>>> >>> port). The >>> >>>> individual SDPs sent to RR or RS may include other portions >>>> of descriptions >>>> that will contain specific information. >>>> >>>> -acbegen >>>> >>>> >>>>> -----Original Message----- >>>>> From: Roni Even [mailto:ron.even.tlv@gmail.com] >>>>> Sent: Friday, April 24, 2009 12:23 PM >>>>> To: Ali C. Begen (abegen); avt@ietf.org >>>>> Cc: Bill Ver Steeg (versteb) >>>>> Subject: RE: [AVT] New draft of "Rapid Acquisition of >>>>> Multicast RTPSessions (RAMS)" available >>>>> >>>>> Ali, >>>>> I think you get it wrong, this SDP is from the RS and not the >>>>> RR so the RS >>>>> cannot specify to which address it will send it can only >>>>> specify to which >>>>> address it can receive RTP stream. In this SDP the relevant >>>>> information is >>>>> that the request for retransmission will be sent by the RR to >>>>> port 41003 >>>>> Roni >>>>> >>>>> -----Original Message----- >>>>> From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] >>>>> Sent: Friday, April 24, 2009 10:01 PM >>>>> To: Roni Even; avt@ietf.org >>>>> Cc: Bill Ver Steeg (versteb) >>>>> Subject: RE: [AVT] New draft of "Rapid Acquisition of >>>>> Multicast RTPSessions >>>>> (RAMS)" available >>>>> >>>>> Oh, I see. The burst goes to the port that we would >>>>> >>>> normally send the >>>> >>>>> retransmissions. For example, consider the SDP from the draft: >>>>> >>>>> m=video 41000 RTP/AVPF 98 >>>>> i=Primary Multicast Stream #2 >>>>> c=IN IP4 224.1.1.2/255 >>>>> a=source-filter: incl IN IP4 224.1.1.2 192.0.2.2 >>>>> a=rtpmap:98 MP2T/90000 >>>>> a=rtcp:41001 IN IP4 192.0.2.1 >>>>> a=rtcp-fb:98 nack >>>>> a=rtcp-fb:98 nack ssli >>>>> a=ssrc:123321 cname:iptv-ch32@rams.example.com >>>>> a=mid:3 >>>>> m=video 41002 RTP/AVPF 99 >>>>> i=Unicast Retransmission Stream #2 (Ret. and Rapid >>>>> Acq. Support) >>>>> c=IN IP4 192.0.2.1 >>>>> a=recvonly >>>>> a=rtpmap:99 rtx/90000 >>>>> a=rtcp:41003 >>>>> a=fmtp:99 apt=98; rtx-time=5000 >>>>> a=mid:4 >>>>> >>>>> In this case, the burst will go to port 41002 on the RR. >>>>> >>> The RAMS-I >>> >>>>> message(s), which is an RTCP feedback message, will go to >>>>> >>>> port 41003. >>>> >>>>> HTH, >>>>> -acbegen >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Roni Even [mailto:ron.even.tlv@gmail.com] >>>>>> Sent: Friday, April 24, 2009 11:44 AM >>>>>> To: Ali C. Begen (abegen); avt@ietf.org >>>>>> Cc: Bill Ver Steeg (versteb) >>>>>> Subject: RE: [AVT] New draft of "Rapid Acquisition of >>>>>> Multicast RTPSessions (RAMS)" available >>>>>> >>>>>> Ali, >>>>>> I will try to explain in simple way >>>>>> >>>>>> When the RS receives the RAMS-R it need to start sending an >>>>>> RTP stream to >>>>>> the RR. >>>>>> In order to send a unicast packet, the RS needs to know a >>>>>> transport address >>>>>> on the RR to where the RTP stream will be sent. The current >>>>>> draft does not >>>>>> say how the RS knows this address. There is no SDP from RR to >>>>>> RS like you >>>>>> mention in your response. >>>>>> This is why I say that the current draft does not specify a >>>>>> solution that >>>>>> can be implemented as a working solution >>>>>> Roni >>>>>> >>>>>> -----Original Message----- >>>>>> From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] >>>>>> Sent: Friday, April 24, 2009 7:38 PM >>>>>> To: Roni Even; avt@ietf.org >>>>>> Cc: Bill Ver Steeg (versteb) >>>>>> Subject: RE: [AVT] New draft of "Rapid Acquisition of >>>>>> Multicast RTPSessions >>>>>> (RAMS)" available >>>>>> >>>>>> Hi Roni, >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On >>>>>>> Behalf Of Roni Even >>>>>>> Sent: Friday, April 24, 2009 4:24 AM >>>>>>> To: avt@ietf.org >>>>>>> Cc: Bill Ver Steeg (versteb) >>>>>>> Subject: Re: [AVT] New draft of "Rapid Acquisition of >>>>>>> Multicast RTPSessions (RAMS)" available >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I think that the current draft does not give a >>>>>>> >> description of >> >>>>>>> a system that works since there is no text >>>>>>> >> explaining how the >> >>>>>> What do you mean by "a system that works"? >>>>>> >>>>>> >>>>>>> RS knows the unicast transport address on the RR to >>>>>>> >> where to >> >>>>>>> send the stream. >>>>>>> >>>>>> Once RS receives the request packet from an RR, RS knows its >>>>>> address. Ports >>>>>> are defined in the SDP. If you are asking about "NAT" issues, >>>>>> we have a >>>>>> section for it, and we plan to complete it as we move >>>>>> forward. It is not as >>>>>> critical as the other parts for now. >>>>>> >>>>>> >>>>>>> If you mandate the use of RTP/RTCP mux it should say so >>>>>>> otherwise the RAMS-R should have an optional parameter that >>>>>>> supplies this information and a flag for using RTP/RTCP mux. >>>>>>> >>>>>> IMO, we cannot mandate muxing as it is not required to make >>>>>> RAMS work. If >>>>>> muxing is supported, the SDP should reflect it. >>>>>> >>>>>> BR, >>>>>> -acbegen >>>>>> >>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> Roni Even >>>>>>> >>>>>>> >>>>>>> >>>>>>> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On >>>>>>> Behalf Of Bill Ver Steeg (versteb) >>>>>>> Sent: Thursday, April 16, 2009 7:39 PM >>>>>>> To: avt@ietf.org >>>>>>> Subject: [AVT] New draft of "Rapid Acquisition of Multicast >>>>>>> RTP Sessions (RAMS)" available >>>>>>> >>>>>>> >>>>>>> >>>>>>> There is a new draft of the "Rapid Acquisition of Multicast >>>>>>> RTP Sessions (RAMS)" draft available at >>>>>>> >>>>>>> >> http://www.ietf.org/internet-drafts/draft-versteeg-avt-rapid-s >> >>>>>> ynchronization-for-rtp-03.txt >>>>>> >>>>>> >> drafts/draft-versteeg-avt-rapid-synchronization-for-rtp-03.txt> >> >>>>>>> >>>>>>> >>>>>>> We have incorporated the changes from the technical >>>>>>> >> breakout >> >>>>>>> session in San Francisco. The major changes in this version >>>>>>> of the draft include >>>>>>> >>>>>>> 1- Changing the document title to avoid confusion >>>>>>> >> with other >> >>>>>>> ongoing "synchronization" drafts >>>>>>> >>>>>>> 2- changing the message names to reflect the title change >>>>>>> >>>>>>> 3- clarification of the RTCP message semantics, including >>>>>>> changes to the "Request" and "Inform" messages >>>>>>> >>>>>>> 4- additional description/motivation for the >>>>>>> >> various message >> >>>>>>> flows has been added >>>>>>> >>>>>>> 5- RTP/RTCP muxing has been added >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> We hope to make this a Working Group item, and will change >>>>>>> the name of the draft to avoid conflicts with other >>>>>>> "synchronization" drafts at that time. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Bill VerSteeg >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > > --------------060902040200060401030204 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=ISO-8859-1 Hi all,

sorry for jumping in....
 
I think one of the sources of confusion is that the attribute a=rtcp: is used once for specifying the destination port  and once for specifying a receiving port, and in the same SDP (!). The destination port for RAMS-I packets sent by RS and the receiving port for RAMS-T. Which is also why different port numbers are used for RAMS-T and -R packets.

I think the use of a=rtcp: in SSM is the problem here. Or the fact that we are mixing unicast and multicast, or both.

Hope this helps,

JLR




Ali C. Begen (abegen) wrote: 
 

  
-----Original Message-----
From: Roni Even [mailto:ron.even.tlv@gmail.com] 
Sent: Saturday, April 25, 2009 2:58 PM
To: Ali C. Begen (abegen); avt@ietf.org
Cc: Bill Ver Steeg (versteb)
Subject: RE: [AVT] New draft of "Rapid Acquisition of 
Multicast RTPSessions (RAMS)" available

Ali,
I looked at RFC 4570 and I assume that port 41001 is the port for the
unicast RTCP reports from the receivers and according to
    

Yes, indeed.
 
  
section 3.2.1 of
that RFC you also should have a RTCP-unicast specification. 
This is for the
multicast receiver reports.
    

Correct. We do have that line in our draft at the top right after the grouping lines:

	a=rtcp-unicast:rsi

BR,
-acbegen
 
  
Roni

-----Original Message-----
From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] 
Sent: Saturday, April 25, 2009 11:30 PM
To: Roni Even; avt@ietf.org
Cc: Bill Ver Steeg (versteb)
Subject: RE: [AVT] New draft of "Rapid Acquisition of 
Multicast RTPSessions
(RAMS)" available

Here is the SDP.

        m=video 41000 RTP/AVPF 98
        i=Primary Multicast Stream #2
        c=IN IP4 224.1.1.2/255
        a=source-filter: incl IN IP4 224.1.1.2 192.0.2.2

Source (192.0.2.2) sends the rtp packets to the multicast 
group (224.1.1.2)
with a dest port 41000.

        a=rtpmap:98 MP2T/90000
        a=rtcp:41001 IN IP4 192.0.2.1

The feedback target (RS) address for this SSM session is 
192.0.2.1 and its
port is 41001. This is the address/port where RR sends the RAMS-R, or
receiver reports for the SSM session.

        a=rtcp-fb:98 nack
        a=rtcp-fb:98 nack ssli
        a=ssrc:123321 cname:iptv-ch32@rams.example.com
        a=mid:3
        m=video 41002 RTP/AVPF 99

The retransmission packets go to port 41002. This is the port 
RRs listen to
for retransmission and RAMS.

        i=Unicast Retransmission Stream #2 (Ret. and Rapid 
Acq. Support)
        c=IN IP4 192.0.2.1

This is where the retransmission packets come from, same as 
the feedback
target (in this example).

        a=rtpmap:99 rtx/90000
        a=rtcp:41003

This is where the RTCP packets for the retransmission session go. For
example, RAMS-I goes to this port on RRs. RAMS-T goes to this 
port on RS.

        a=fmtp:99 apt=98; rtx-time=5000
        a=mid:4


-acbegen
 

    
-----Original Message-----
From: Roni Even [mailto:ron.even.tlv@gmail.com] 
Sent: Saturday, April 25, 2009 1:11 PM
To: Ali C. Begen (abegen); avt@ietf.org
Cc: Bill Ver Steeg (versteb)
Subject: RE: [AVT] New draft of "Rapid Acquisition of 
Multicast RTPSessions (RAMS)" available

Ali,
Can you please write three addresses from this strange SDP.

1. The address and port of multicast

2. The address and port of the RS where the RTCP FB should go to

3. The address and port on the RR where the unicast stream 
should be sent to

Roni

-----Original Message-----
From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] 
Sent: Saturday, April 25, 2009 11:02 PM
To: Roni Even; avt@ietf.org
Cc: Bill Ver Steeg (versteb)
Subject: RE: [AVT] New draft of "Rapid Acquisition of 
Multicast RTPSessions
(RAMS)" available

      
Ali,
The example SDP is syntactically correct but it does not 
        
say that the
      
rtp/rtcp mux will be used and it does not give the 
information to where the
unicast stream will be sent when the RR sends a RAMS-R. 
        
To my knowledge, the first line in the following SDP tells 
the RRs on which
port they will receive the retransmission/burst packets.

        m=video 41002 RTP/AVPF 99
        i=Unicast Retransmission Stream #2 (Ret. and Rapid 
Acq. Support)
        c=IN IP4 192.0.2.1
        a=rtpmap:99 rtx/90000
        a=rtcp:41003
        a=fmtp:99 apt=98; rtx-time=5000
        a=mid:4

There is a typo, you are right. That "a=recvonly" line should 
only exist in
the SDP sent to RRs. In the SDP sent to RS, we should rather have
"a=sendonly". I will make this correction in the next version.

The feedback target for the SSM session and the RTCP port for the
retransmission session are also defined in the SDP.

Hope this clarifies.

BR,
-acbegen
 
      
I am not sure why the unicast stream m-line has a port 
        
number with an
      
attribute of recvonly. What is the use case for that. The 
only information
that the RR will need is the RTCP port on the RS to where to 
send the RAMS-R
message.
Roni
-----Original Message-----
From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] 
Sent: Friday, April 24, 2009 10:37 PM
To: Roni Even; avt@ietf.org
Cc: Bill Ver Steeg (versteb)
Subject: RE: [AVT] New draft of "Rapid Acquisition of 
Multicast RTPSessions
(RAMS)" available

This is a part of an example SDP sent to RS and RR in a SAP 
announcement,
for example. So, the SDP describes what both parties should 
do (RR cannot
say that he wants to receive this multicast on its favorite 
        
port). The
      
individual SDPs sent to RR or RS may include other portions 
of descriptions
that will contain specific information. 

-acbegen

        
-----Original Message-----
From: Roni Even [mailto:ron.even.tlv@gmail.com] 
Sent: Friday, April 24, 2009 12:23 PM
To: Ali C. Begen (abegen); avt@ietf.org
Cc: Bill Ver Steeg (versteb)
Subject: RE: [AVT] New draft of "Rapid Acquisition of 
Multicast RTPSessions (RAMS)" available

Ali,
I think you get it wrong, this SDP is from the RS and not the 
RR so the RS
cannot specify to which address it will send it can only 
specify to which
address it can receive RTP stream. In this SDP the relevant 
information is
that the request for retransmission will be sent by the RR to 
port 41003
Roni

-----Original Message-----
From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] 
Sent: Friday, April 24, 2009 10:01 PM
To: Roni Even; avt@ietf.org
Cc: Bill Ver Steeg (versteb)
Subject: RE: [AVT] New draft of "Rapid Acquisition of 
Multicast RTPSessions
(RAMS)" available

Oh, I see. The burst goes to the port that we would 
          
normally send the
        
retransmissions. For example, consider the SDP from the draft:

        m=video 41000 RTP/AVPF 98
        i=Primary Multicast Stream #2
        c=IN IP4 224.1.1.2/255
        a=source-filter: incl IN IP4 224.1.1.2 192.0.2.2
        a=rtpmap:98 MP2T/90000
        a=rtcp:41001 IN IP4 192.0.2.1
        a=rtcp-fb:98 nack
        a=rtcp-fb:98 nack ssli
        a=ssrc:123321 cname:iptv-ch32@rams.example.com
        a=mid:3
        m=video 41002 RTP/AVPF 99
        i=Unicast Retransmission Stream #2 (Ret. and Rapid 
Acq. Support)
        c=IN IP4 192.0.2.1
        a=recvonly
        a=rtpmap:99 rtx/90000
        a=rtcp:41003
        a=fmtp:99 apt=98; rtx-time=5000
        a=mid:4

In this case, the burst will go to port 41002 on the RR. 
          
The RAMS-I
      
message(s), which is an RTCP feedback message, will go to 
          
port 41003.
        
HTH,
-acbegen

          
-----Original Message-----
From: Roni Even [mailto:ron.even.tlv@gmail.com] 
Sent: Friday, April 24, 2009 11:44 AM
To: Ali C. Begen (abegen); avt@ietf.org
Cc: Bill Ver Steeg (versteb)
Subject: RE: [AVT] New draft of "Rapid Acquisition of 
Multicast RTPSessions (RAMS)" available

Ali,
I will try to explain in simple way

When the RS receives the RAMS-R it need to start sending an 
RTP stream to
the RR. 
In order to send a unicast packet, the RS needs to know a 
transport address
on the RR to where the RTP stream will be sent. The current 
draft does not
say how the RS knows this address. There is no SDP from RR to 
RS like you
mention in your response.
This is why I say that the current draft does not specify a 
solution that
can be implemented as a working solution
Roni

-----Original Message-----
From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] 
Sent: Friday, April 24, 2009 7:38 PM
To: Roni Even; avt@ietf.org
Cc: Bill Ver Steeg (versteb)
Subject: RE: [AVT] New draft of "Rapid Acquisition of 
Multicast RTPSessions
(RAMS)" available

Hi Roni, 

            
-----Original Message-----
From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On 
Behalf Of Roni Even
Sent: Friday, April 24, 2009 4:24 AM
To: avt@ietf.org
Cc: Bill Ver Steeg (versteb)
Subject: Re: [AVT] New draft of "Rapid Acquisition of 
Multicast RTPSessions (RAMS)" available

Hi,

I think that the current draft does not give a 
              
description of 
    
a system that works since there is no text 
              
explaining how the 
    
What do you mean by "a system that works"? 

            
RS knows the unicast transport address on the RR to 
              
where to 
    
send the stream. 
              
Once RS receives the request packet from an RR, RS knows its 
address. Ports
are defined in the SDP. If you are asking about "NAT" issues, 
we have a
section for it, and we plan to complete it as we move 
forward. It is not as
critical as the other parts for now.
 
            
If you mandate the use of RTP/RTCP mux it should say so 
otherwise the RAMS-R should have an optional parameter that 
supplies this information and a flag for using RTP/RTCP mux.
              
IMO, we cannot mandate muxing as it is not required to make 
RAMS work. If
muxing is supported, the SDP should reflect it.

BR,
-acbegen
 
            
Thanks

Roni Even

 

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On 
Behalf Of Bill Ver Steeg (versteb)
Sent: Thursday, April 16, 2009 7:39 PM
To: avt@ietf.org
Subject: [AVT] New draft of "Rapid Acquisition of Multicast 
RTP Sessions (RAMS)" available

 

There is a new draft of the "Rapid Acquisition of Multicast 
RTP Sessions (RAMS)" draft available at 

              
http://www.ietf.org/internet-drafts/draft-versteeg-avt-rapid-s
    
ynchronization-for-rtp-03.txt <http://www.ietf.org/internet->

            
drafts/draft-versteeg-avt-rapid-synchronization-for-rtp-03.txt> 
    
 

We have incorporated the changes from the technical 
              
breakout 
    
session in San Francisco. The major changes in this version 
of the draft include 

1- Changing the document title to avoid confusion 
              
with other 
    
ongoing "synchronization" drafts

2- changing the message names to reflect the title change

3- clarification of the RTCP message semantics, including 
changes to the "Request" and "Inform" messages

4- additional description/motivation for the 
              
various message 
    
flows has been added

5- RTP/RTCP muxing has been added

 

 

We hope to make this a Working Group item, and will change 
the name of the draft to avoid conflicts with other 
"synchronization" drafts at that time.

 

Bill VerSteeg

 

 


              
            
          
        
      
    
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt
--------------060902040200060401030204-- From root@core3.amsl.com Thu May 21 15:30:01 2009 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 684B13A6A0C; Thu, 21 May 2009 15:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090521223001.684B13A6A0C@core3.amsl.com> Date: Thu, 21 May 2009 15:30:01 -0700 (PDT) Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-ipmr-04.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 22:30:01 -0000 --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 SPIRIT IP-MR Speech Codec Author(s) : S. Ikonin Filename : draft-ietf-avt-rtp-ipmr-04.txt Pages : 16 Date : 2009-5-21 This document specifies the payload format for packetization of SPIRIT IP-MR encoded speech signals into the Real-time Transport Protocol (RTP). The payload format supports transmission of multiple frames per payload and introduced redundancy for robustness against packet loss. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-ipmr-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-avt-rtp-ipmr-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-5-21152213.I-D@ietf.org> --NextPart-- From abegen@cisco.com Thu May 21 16:58:48 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D17B3A680C for ; Thu, 21 May 2009 16:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.067 X-Spam-Level: X-Spam-Status: No, score=-5.067 tagged_above=-999 required=5 tests=[AWL=-1.168, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hHtadkZC+byX for ; Thu, 21 May 2009 16:58:46 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 685303A6AD1 for ; Thu, 21 May 2009 16:58:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,230,1241395200"; d="scan'208";a="77199116" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 22 May 2009 00:00:02 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n4M002XZ010510; Thu, 21 May 2009 17:00:02 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n4M002Qa025972; Fri, 22 May 2009 00:00:02 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 May 2009 17:00:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Thu, 21 May 2009 16:59:54 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54095E153A@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4A15D40E.80509@eu.panasonic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available Thread-Index: AcnaYqqjHO1LimacStOS+9HZ8wJeMAADPRKQ References: <81B9B88E2F9D574AA5328A85547CDE9101071D80@xmb-rtp-21d.amer.cisco.com> <49f1a1d6.190c660a.58fe.ffffa90e@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C80DA@xmb-sjc-215.amer.cisco.com> <49f208e8.05a0660a.5bd2.6764@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C81C9@xmb-sjc-215.amer.cisco.com> <49f211fc.07a5660a.3f7f.ffff8f4a@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8202@xmb-sjc-215.amer.cisco.com> <49f2efa2.1c215e0a.4454.ffffaf91@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8403@xmb-sjc-215.amer.cisco.com> <49f36ee2.0437560a.11df.1eef@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8405@xmb-sjc-215.amer.cisco.com> <49f387ca.0305560a.6657.4be7@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C840A@xmb-sjc-215.amer.cisco.com> <4A15D40E.80509@eu.panasonic.com> From: "Ali C. Begen (abegen)" To: =?Windows-1252?Q?Jos=E9_Rey?= X-OriginalArrivalTime: 22 May 2009 00:00:02.0668 (UTC) FILETIME=[417D1AC0:01C9DA70] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=15518; t=1242950402; x=1243814402; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20RE=3A=20[AVT]=20New=20draft=20of=20=22Rapid=20A cquisition=20of=20Multicast=09RTPSessions=20(RAMS)=22=20avai lable |Sender:=20; bh=b2L7xYn50YAPeRgaUwoXEsuFDPb6jtklv4aY9PTcOhA=; b=rKEntyRCj/2h2ZT/pA1xJSRTWFxCl9NNB/cXNwbxoCIxzW4DsJtIhyFD0E PdEWBLttlrMu4H43auUnhTYNnZ/cKdtOwgfrzzNU3hY2ONPXJNxs4hRr5aNh wJvve/LQIz; Authentication-Results: sj-dkim-3; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: Roni Even , avt@ietf.org, "Bill Ver Steeg \(versteb\)" Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 23:58:48 -0000 Hi Jose, We have separate RTCP ports for the SSM session and the unicast session. = Why is it a problem? The slightly modified SDP for the next version is below: a=3Dgroup:FID 3 4 a=3Drtcp-unicast:rsi m=3Dvideo 41000 RTP/AVPF 98 i=3DPrimary Multicast Stream #2 c=3DIN IP4 233.252.0.2/255 a=3Dsource-filter: incl IN IP4 233.252.0.2 192.0.2.2 a=3Drecvonly a=3Drtpmap:98 MP2T/90000 a=3Drtcp:41001 IN IP4 192.0.2.1 a=3Drtcp-fb:98 nack a=3Drtcp-fb:98 nack ssli a=3Dssrc:123321 cname:iptv-ch32@rams.example.com a=3Dmid:3 m=3Dvideo 41002 RTP/AVPF 99 i=3DUnicast Retransmission Stream #2 (Ret. and Rapid Acq. = Support) c=3DIN IP4 192.0.2.1 a=3Drecvonly a=3Drtpmap:99 rtx/90000 a=3Drtcp:41003 a=3Dfmtp:99 apt=3D98; rtx-time=3D5000 a=3Dmid:4 This is the SDP we send to RR. For RS, a=3Drecvonly will be = a=3Dsendonly. -acbegen > -----Original Message----- > From: Jos=E9 Rey [mailto:jose.rey@eu.panasonic.com] > Sent: Thursday, May 21, 2009 3:22 PM > To: Ali C. Begen (abegen) > Cc: Roni Even; avt@ietf.org; Bill Ver Steeg (versteb) > Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast = RTPSessions (RAMS)" > available >=20 > Hi all, >=20 > sorry for jumping in.... >=20 > I think one of the sources of confusion is that the attribute = a=3Drtcp: is used once for > specifying the destination port and once for specifying a receiving = port, and in the same > SDP (!). The destination port for RAMS-I packets sent by RS and the = receiving port for > RAMS-T. Which is also why different port numbers are used for RAMS-T = and -R packets. >=20 > I think the use of a=3Drtcp: in SSM is the problem here. Or the fact = that we are mixing > unicast and multicast, or both. >=20 > Hope this helps, >=20 > JLR >=20 >=20 >=20 >=20 > Ali C. Begen (abegen) wrote: >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Roni Even [mailto:ron.even.tlv@gmail.com] > Sent: Saturday, April 25, 2009 2:58 PM > To: Ali C. Begen (abegen); avt@ietf.org > Cc: Bill Ver Steeg (versteb) > Subject: RE: [AVT] New draft of "Rapid Acquisition of > Multicast RTPSessions (RAMS)" available >=20 > Ali, > I looked at RFC 4570 and I assume that port 41001 is the port for = the > unicast RTCP reports from the receivers and according to >=20 >=20 >=20 > Yes, indeed. >=20 >=20 >=20 > section 3.2.1 of > that RFC you also should have a RTCP-unicast specification. > This is for the > multicast receiver reports. >=20 >=20 >=20 > Correct. We do have that line in our draft at the top right after the = grouping lines: >=20 > a=3Drtcp-unicast:rsi >=20 > BR, > -acbegen >=20 >=20 >=20 > Roni >=20 > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > Sent: Saturday, April 25, 2009 11:30 PM > To: Roni Even; avt@ietf.org > Cc: Bill Ver Steeg (versteb) > Subject: RE: [AVT] New draft of "Rapid Acquisition of > Multicast RTPSessions > (RAMS)" available >=20 > Here is the SDP. >=20 > m=3Dvideo 41000 RTP/AVPF 98 > i=3DPrimary Multicast Stream #2 > c=3DIN IP4 224.1.1.2/255 > a=3Dsource-filter: incl IN IP4 224.1.1.2 192.0.2.2 >=20 > Source (192.0.2.2) sends the rtp packets to the multicast > group (224.1.1.2) > with a dest port 41000. >=20 > a=3Drtpmap:98 MP2T/90000 > a=3Drtcp:41001 IN IP4 192.0.2.1 >=20 > The feedback target (RS) address for this SSM session is > 192.0.2.1 and its > port is 41001. This is the address/port where RR sends the RAMS-R, = or > receiver reports for the SSM session. >=20 > a=3Drtcp-fb:98 nack > a=3Drtcp-fb:98 nack ssli > a=3Dssrc:123321 cname:iptv-ch32@rams.example.com > a=3Dmid:3 > m=3Dvideo 41002 RTP/AVPF 99 >=20 > The retransmission packets go to port 41002. This is the port > RRs listen to > for retransmission and RAMS. >=20 > i=3DUnicast Retransmission Stream #2 (Ret. and Rapid > Acq. Support) > c=3DIN IP4 192.0.2.1 >=20 > This is where the retransmission packets come from, same as > the feedback > target (in this example). >=20 > a=3Drtpmap:99 rtx/90000 > a=3Drtcp:41003 >=20 > This is where the RTCP packets for the retransmission session go. = For > example, RAMS-I goes to this port on RRs. RAMS-T goes to this > port on RS. >=20 > a=3Dfmtp:99 apt=3D98; rtx-time=3D5000 > a=3Dmid:4 >=20 >=20 > -acbegen >=20 >=20 >=20 >=20 > -----Original Message----- > From: Roni Even [mailto:ron.even.tlv@gmail.com] > Sent: Saturday, April 25, 2009 1:11 PM > To: Ali C. Begen (abegen); avt@ietf.org > Cc: Bill Ver Steeg (versteb) > Subject: RE: [AVT] New draft of "Rapid Acquisition of > Multicast RTPSessions (RAMS)" available >=20 > Ali, > Can you please write three addresses from this strange SDP. >=20 > 1. The address and port of multicast >=20 > 2. The address and port of the RS where the RTCP FB should go to >=20 > 3. The address and port on the RR where the unicast stream > should be sent to >=20 > Roni >=20 > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > Sent: Saturday, April 25, 2009 11:02 PM > To: Roni Even; avt@ietf.org > Cc: Bill Ver Steeg (versteb) > Subject: RE: [AVT] New draft of "Rapid Acquisition of > Multicast RTPSessions > (RAMS)" available >=20 >=20 >=20 > Ali, > The example SDP is syntactically correct but it does not >=20 >=20 > say that the >=20 >=20 > rtp/rtcp mux will be used and it does not give the > information to where the > unicast stream will be sent when the RR sends a RAMS-R. >=20 >=20 > To my knowledge, the first line in the following SDP tells > the RRs on which > port they will receive the retransmission/burst packets. >=20 > m=3Dvideo 41002 RTP/AVPF 99 > i=3DUnicast Retransmission Stream #2 (Ret. and Rapid > Acq. Support) > c=3DIN IP4 192.0.2.1 > a=3Drtpmap:99 rtx/90000 > a=3Drtcp:41003 > a=3Dfmtp:99 apt=3D98; rtx-time=3D5000 > a=3Dmid:4 >=20 > There is a typo, you are right. That "a=3Drecvonly" line should > only exist in > the SDP sent to RRs. In the SDP sent to RS, we should rather have > "a=3Dsendonly". I will make this correction in the next version. >=20 > The feedback target for the SSM session and the RTCP port for the > retransmission session are also defined in the SDP. >=20 > Hope this clarifies. >=20 > BR, > -acbegen >=20 >=20 >=20 > I am not sure why the unicast stream m-line has a port >=20 >=20 > number with an >=20 >=20 > attribute of recvonly. What is the use case for that. The > only information > that the RR will need is the RTCP port on the RS to where to > send the RAMS-R > message. > Roni > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > Sent: Friday, April 24, 2009 10:37 PM > To: Roni Even; avt@ietf.org > Cc: Bill Ver Steeg (versteb) > Subject: RE: [AVT] New draft of "Rapid Acquisition of > Multicast RTPSessions > (RAMS)" available >=20 > This is a part of an example SDP sent to RS and RR in a SAP > announcement, > for example. So, the SDP describes what both parties should > do (RR cannot > say that he wants to receive this multicast on its favorite >=20 >=20 > port). The >=20 >=20 > individual SDPs sent to RR or RS may include other portions > of descriptions > that will contain specific information. >=20 > -acbegen >=20 >=20 >=20 > -----Original Message----- > From: Roni Even [mailto:ron.even.tlv@gmail.com] > Sent: Friday, April 24, 2009 12:23 PM > To: Ali C. Begen (abegen); avt@ietf.org > Cc: Bill Ver Steeg (versteb) > Subject: RE: [AVT] New draft of "Rapid Acquisition of > Multicast RTPSessions (RAMS)" available >=20 > Ali, > I think you get it wrong, this SDP is from the RS and not the > RR so the RS > cannot specify to which address it will send it can only > specify to which > address it can receive RTP stream. In this SDP the relevant > information is > that the request for retransmission will be sent by the RR to > port 41003 > Roni >=20 > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > Sent: Friday, April 24, 2009 10:01 PM > To: Roni Even; avt@ietf.org > Cc: Bill Ver Steeg (versteb) > Subject: RE: [AVT] New draft of "Rapid Acquisition of > Multicast RTPSessions > (RAMS)" available >=20 > Oh, I see. The burst goes to the port that we would >=20 >=20 > normally send the >=20 >=20 > retransmissions. For example, consider the SDP from the draft: >=20 > m=3Dvideo 41000 RTP/AVPF 98 > i=3DPrimary Multicast Stream #2 > c=3DIN IP4 224.1.1.2/255 > a=3Dsource-filter: incl IN IP4 224.1.1.2 192.0.2.2 > a=3Drtpmap:98 MP2T/90000 > a=3Drtcp:41001 IN IP4 192.0.2.1 > a=3Drtcp-fb:98 nack > a=3Drtcp-fb:98 nack ssli > a=3Dssrc:123321 cname:iptv-ch32@rams.example.com > a=3Dmid:3 > m=3Dvideo 41002 RTP/AVPF 99 > i=3DUnicast Retransmission Stream #2 (Ret. and Rapid > Acq. Support) > c=3DIN IP4 192.0.2.1 > a=3Drecvonly > a=3Drtpmap:99 rtx/90000 > a=3Drtcp:41003 > a=3Dfmtp:99 apt=3D98; rtx-time=3D5000 > a=3Dmid:4 >=20 > In this case, the burst will go to port 41002 on the RR. >=20 >=20 > The RAMS-I >=20 >=20 > message(s), which is an RTCP feedback message, will go to >=20 >=20 > port 41003. >=20 >=20 > HTH, > -acbegen >=20 >=20 >=20 > -----Original Message----- > From: Roni Even [mailto:ron.even.tlv@gmail.com] > Sent: Friday, April 24, 2009 11:44 AM > To: Ali C. Begen (abegen); avt@ietf.org > Cc: Bill Ver Steeg (versteb) > Subject: RE: [AVT] New draft of "Rapid Acquisition of > Multicast RTPSessions (RAMS)" available >=20 > Ali, > I will try to explain in simple way >=20 > When the RS receives the RAMS-R it need to start sending > an > RTP stream to > the RR. > In order to send a unicast packet, the RS needs to know a > transport address > on the RR to where the RTP stream will be sent. The > current > draft does not > say how the RS knows this address. There is no SDP from RR > to > RS like you > mention in your response. > This is why I say that the current draft does not specify > a > solution that > can be implemented as a working solution > Roni >=20 > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > Sent: Friday, April 24, 2009 7:38 PM > To: Roni Even; avt@ietf.org > Cc: Bill Ver Steeg (versteb) > Subject: RE: [AVT] New draft of "Rapid Acquisition of > Multicast RTPSessions > (RAMS)" available >=20 > Hi Roni, >=20 >=20 >=20 > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt- > bounces@ietf.org] On > Behalf Of Roni Even > Sent: Friday, April 24, 2009 4:24 AM > To: avt@ietf.org > Cc: Bill Ver Steeg (versteb) > Subject: Re: [AVT] New draft of "Rapid Acquisition of > Multicast RTPSessions (RAMS)" available >=20 > Hi, >=20 > I think that the current draft does not give a >=20 >=20 > description of >=20 >=20 > a system that works since there is no text >=20 >=20 > explaining how the >=20 >=20 > What do you mean by "a system that works"? >=20 >=20 >=20 > RS knows the unicast transport address on the RR to >=20 >=20 > where to >=20 >=20 > send the stream. >=20 >=20 > Once RS receives the request packet from an RR, RS knows > its > address. Ports > are defined in the SDP. If you are asking about "NAT" > issues, > we have a > section for it, and we plan to complete it as we move > forward. It is not as > critical as the other parts for now. >=20 >=20 >=20 > If you mandate the use of RTP/RTCP mux it should say > so > otherwise the RAMS-R should have an optional > parameter that > supplies this information and a flag for using > RTP/RTCP mux. >=20 >=20 > IMO, we cannot mandate muxing as it is not required to > make > RAMS work. If > muxing is supported, the SDP should reflect it. >=20 > BR, > -acbegen >=20 >=20 >=20 > Thanks >=20 > Roni Even >=20 >=20 >=20 > From: avt-bounces@ietf.org [mailto:avt- > bounces@ietf.org] On > Behalf Of Bill Ver Steeg (versteb) > Sent: Thursday, April 16, 2009 7:39 PM > To: avt@ietf.org > Subject: [AVT] New draft of "Rapid Acquisition of > Multicast > RTP Sessions (RAMS)" available >=20 >=20 >=20 > There is a new draft of the "Rapid Acquisition of > Multicast > RTP Sessions (RAMS)" draft available at >=20 >=20 >=20 > http://www.ietf.org/internet-drafts/draft-versteeg-avt-rapid-s >=20 >=20 > ynchronization-for-rtp-03.txt > >=20 >=20 >=20 > drafts/draft-versteeg-avt-rapid-synchronization-for-rtp-03.txt> >=20 >=20 >=20 >=20 > We have incorporated the changes from the technical >=20 >=20 > breakout >=20 >=20 > session in San Francisco. The major changes in this > version > of the draft include >=20 > 1- Changing the document title to avoid confusion >=20 >=20 > with other >=20 >=20 > ongoing "synchronization" drafts >=20 > 2- changing the message names to reflect the title > change >=20 > 3- clarification of the RTCP message semantics, > including > changes to the "Request" and "Inform" messages >=20 > 4- additional description/motivation for the >=20 >=20 > various message >=20 >=20 > flows has been added >=20 > 5- RTP/RTCP muxing has been added >=20 >=20 >=20 >=20 >=20 > We hope to make this a Working Group item, and will > change > the name of the draft to avoid conflicts with other > "synchronization" drafts at that time. >=20 >=20 >=20 > Bill VerSteeg >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt >=20 >=20 From marshall.eubanks@gmail.com Thu May 21 18:37:02 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A05C3A6AA2 for ; Thu, 21 May 2009 18:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6hsCcrRMqDOD for ; Thu, 21 May 2009 18:37:01 -0700 (PDT) Received: from mail-bw0-f174.google.com (mail-bw0-f174.google.com [209.85.218.174]) by core3.amsl.com (Postfix) with ESMTP id 7228B3A6782 for ; Thu, 21 May 2009 18:37:00 -0700 (PDT) Received: by bwz22 with SMTP id 22so1355656bwz.37 for ; Thu, 21 May 2009 18:38:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=O5KwWWEShafldQrofluacwjbIIzfRG/J8EFNPiqo2TQ=; b=EZqks5R44TIc7hkqM9DYq+8dvI+7Ey6bX9LMEhZTu4OEdU4ygErFlpxHwkqYGZvH38 DhjURn8Mwk48UNIIxE9rjXkYCOkLoiouPN2jx4ABqrAcZzTl4GIe6ypcMnXCJPEX4Y0I YFaH9KxU6S+PKH3CZEFAU3H7+Zt84QKnc+1Rg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=OqsNxqCz3LXpHvPwjAIcUvkHPxtFKdE1UgnR6hc14d0Dp3NmTdW7Qcsf73znGprA/6 Faa9svnK1nEnhZ0F933zG1pEq3wSncNHZb0gAHDUCguM5PF7qzwnGSuln5WiU2EIyssS xT+fafg3nOmfZB16czwJmoqYavJycRnodguYU= MIME-Version: 1.0 Received: by 10.239.169.80 with SMTP id n16mr250741hbe.167.1242956309597; Thu, 21 May 2009 18:38:29 -0700 (PDT) In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D54094C3DC9@xmb-sjc-215.amer.cisco.com> References: <81B9B88E2F9D574AA5328A85547CDE91013038E4@xmb-rtp-21d.amer.cisco.com> <81B9B88E2F9D574AA5328A85547CDE9101303DA5@xmb-rtp-21d.amer.cisco.com> <00de01c9d3c8$32b6cad0$98246070$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D54094C3DC9@xmb-sjc-215.amer.cisco.com> Date: Thu, 21 May 2009 21:38:29 -0400 Message-ID: From: Marshall Eubanks To: "Ali C. Begen (abegen)" Content-Type: multipart/alternative; boundary=001636457b704e0d57046a765166 Cc: "Bill Ver Steeg \(versteb\)" , Roni Even , avt@ietf.org Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions(RAMS) as a working group item X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 01:37:02 -0000 --001636457b704e0d57046a765166 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Wed, May 13, 2009 at 7:46 PM, Ali C. Begen (abegen) wrote: > Roni, > > There are a few other important issues that we need WG input on: > > - The scenarios where there are multiple SSRC-multiplexed RTP streams in a > single RTP session. Will RAMS apply to individual streams or the whole > session? Similarly, what happens when the same multicast session carries > multiple RTP sessions (same multicast address but different ports). Clearly, > such cases will exist. We have a draft text that discusses different > scenarios and what needs to be done in each such cases. But before we move > forward, we would like to hear WG input. Managing multiple bursts > simultaneously requires some details. > > - The security section needs to be completed as well as the NAT section. > > Some comments inline. > > > I have some others issues to add to this list > > > > 1. I suggest to add to the RAMS request an optional parameter that will > > allow the receiver to request that the unicast stream will be sent to the > a > > port specified in this parameter instead of the port offered in the > > announcement. > > This is tricky. Remember that the RAMS request message goes to the Feedback > Target of the primary multicast session but the burst comes from the > retransmission server. They could be the same entity or different ones. Any > solution should consider this in its design. > > > 2. The issue of RTP/RTCP multiplexing should be discussed, is it > mandatory > > to use it. > > It is not mandatory. Even if we made it mandatory, it would not help us > with the issue you describe above. Muxing only simplifies NAT traversal. > Sorry for responding late, but I have been digging through this. I would strongly urge that RAMS support unmuxed audio / video. This is common in certain circumstances, and is probably more common in multicast RTP than muxed AV. (One use case is multiple audio tracks, such as different languages, for one video, another is multiple video encodings, such as different aspect ratios, for one audio.) Marshall > > > 3. The issue of FW/NAT traversal for the unicast stream should also be > > discussed. > > Indeed. The NAT section is TBC. > > -acbegen > > > > > Thanks > > Roni Even > > > > -----Original Message----- > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Bill > > Ver Steeg (versteb) > > Sent: Wednesday, May 13, 2009 3:08 PM > > To: avt@ietf.org > > Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP > > Sessions(RAMS) as a working group item > > > > > > > > We submitted version -00 of "draft-ietf-avt-rapid-acquisition-for-rtp". > > This is basically a name change from > > "draft-versteeg-avt-rapid-synchronization-for-rtp-03" to avoid confusion > > with other pending "synchronization" drafts. > > > > There were some issues remaining from -03 version that have already been > > identified on the list and technical breakout session. We are planning > > to address these issues in the next version of the draft. > > > > We hope to address the following areas in the next revision of the > > draft: > > > > - Section 7 - Define a method for vendor-specific and generic extensions > > to RAMS, lay out the intent to use FMT==6 for all messages and to have > > an (extensible) enumeration of the RAMS sub-FMTs > > - Section 8 - Elaborate SDP to describe the various use cases for RAMS > > - Section 13 - Define a single registry (FMT==6) for all RAMS > > transactions, and then define Sub-FMT Values for RAMS Messages. Also > > define an extensible RAMS TLV space registry > > > > - We need to make some typographical corrections, mostly changing from > > RMS to RAMS. > > - We need to formalize the TLV definitions and extensions (both vendor > > and private extensions) > > - We need to register FMT=6 with IANA for RAMS and use sub-FMT values to > > identify various RAMS messages > > - We need to clarify the SDP section based on the earlier discussion. > > The SDP example is still declarative and we are looking forward to > > include more examples as we move forward. > > - The IANA concerns section needs to be updated to reflect how to extend > > the RAMS protocol. > > - The unicast/multicast addresses need to be fixed according to the > > idnits tool. > > > > Are there other issues that we need to address in the next revision of > > the draft? The authors would like to address these high priority issues > > in the next few days, so timely feedback would be appreciated. > > > > > > Bill VerSteeg > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > > > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > --001636457b704e0d57046a765166 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, May 13, 2009 at 7:46 PM, Ali C. = Begen (abegen) <ab= egen@cisco.com> wrote:
Roni,

There are a few other important issues that we need WG input on:

- The scenarios where there are multiple SSRC-multiplexed RTP streams in a = single RTP session. Will RAMS apply to individual streams or the whole sess= ion? Similarly, what happens when the same multicast session carries multip= le RTP sessions (same multicast address but different ports). Clearly, such= cases will exist. We have a draft text that discusses different scenarios = and what needs to be done in each such cases. But before we move forward, w= e would like to hear WG input. Managing multiple bursts simultaneously requ= ires some details.

- The security section needs to be completed as well as the NAT section.
Some comments inline.

> I have some others issues to add to this list
>
> 1. I suggest to add to the RAMS request an optional parameter that wil= l
> allow the receiver to request that the unicast stream will be sent to = the a
> port specified in this parameter instead of the port offered in the > announcement.

This is tricky. Remember that the RAMS request message goes to the Fe= edback Target of the primary multicast session but the burst comes from the= retransmission server. They could be the same entity or different ones. An= y solution should consider this in its design.

> 2. The issue of RTP/RTCP multiplexing should be discussed, is it manda= tory
> to use it.

It is not mandatory. Even if we made it mandatory, it would not help = us with the issue you describe above. Muxing only simplifies NAT traversal.=

Sorry for respondi= ng late, but I have been digging through this.

I would strongly urge that RAMS support=A0unmuxed audio / v= ideo. This is common in certain circumstances, and is probably more=A0commo= n in multicast RTP than muxed AV. (One use case is multiple audio tracks, s= uch as different languages, for one=A0=A0video, another=A0is multiple video= encodings, such=A0as different aspect ratios, for one audio.)

=A0Marshal= l
=A0

> 3. The issue of FW/NAT traversal for the unicast stream should also be=
> discussed.

Indeed. The NAT section is TBC.

-acbegen

>
> Thanks
> Roni Even
>
> -----Original Message-----
> From: avt-bounces@ietf.org= [mailto:avt-bounces@ietf.org] = On Behalf Of Bill
> Ver Steeg (versteb)
> Sent: Wednesday, May 13, 2009 3:08 PM
> To: avt@ietf.org
> Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP
> Sessions(RAMS) as a working group item
>
>
>
> We submitted version -00 of "draft-ietf-avt-rapid-acquisition-for= -rtp".
> This is basically a name change from
> "draft-versteeg-avt-rapid-synchronization-for-rtp-03" to avo= id confusion
> with other pending "synchronization" drafts.
>
> There were some issues remaining from -03 version that have already be= en
> identified on the list and technical breakout session. We are planning=
> to address these issues in the next version of the draft.
>
> We hope to address the following areas in the next revision of the
> draft:
>
> - Section 7 - Define a method for vendor-specific and generic extensio= ns
> to RAMS, lay out the intent to use FMT=3D=3D6 for all messages and to = have
> an (extensible) enumeration of the RAMS sub-FMTs
> - Section 8 - Elaborate SDP to describe the various use cases for RAMS=
> - Section 13 - Define a single registry (FMT=3D=3D6) for all RAMS
> transactions, and then define Sub-FMT Values for RAMS Messages. Also > define an extensible RAMS TLV space registry
>
> - We need to make some typographical corrections, mostly changing from=
> RMS to RAMS.
> - We need to formalize the TLV definitions and extensions (both vendor=
> and private extensions)
> - We need to register FMT=3D6 with IANA for RAMS and use sub-FMT value= s to
> identify various RAMS messages
> - We need to clarify the SDP section based on the earlier discussion.<= br> > The SDP example is still declarative and we are looking forward to
> include more examples as we move forward.
> - The IANA concerns section needs to be updated to reflect how to exte= nd
> the RAMS protocol.
> - The unicast/multicast addresses need to be fixed according to the > idnits tool.
>
> Are there other issues that we need to address in the next revision of=
> the draft? The authors would like to address these high priority issue= s
> in the next few days, so timely feedback would be appreciated.
>
>
> Bill VerSteeg
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt
>
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/avt

--001636457b704e0d57046a765166-- From rjesup@wgate.com Thu May 21 19:02:32 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 092523A6D21 for ; Thu, 21 May 2009 19:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.573 X-Spam-Level: X-Spam-Status: No, score=-1.573 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HnKju66b9cTt for ; Thu, 21 May 2009 19:02:31 -0700 (PDT) Received: from exchange1.wgate.com (pr-66-150-46-254.wgate.com [66.150.46.254]) by core3.amsl.com (Postfix) with ESMTP id B72163A680C for ; Thu, 21 May 2009 19:02:30 -0700 (PDT) Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 May 2009 22:04:08 -0400 To: Tom Taylor References: <4A15046C.5080600@rogers.com> <006701c9d9e9$51679500$f436bf00$%roni@huawei.com> <7779AD69A5E54F9F84E473BB4F4E1E71@china.huawei.com> <4A157ADA.8060900@rogers.com> From: Randell Jesup Date: Thu, 21 May 2009 22:04:19 -0400 In-Reply-To: <4A157ADA.8060900@rogers.com> (Tom Taylor's message of "Thu\, 21 May 2009 18\:01\:30 +0200") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 22 May 2009 02:04:08.0943 (UTC) FILETIME=[97D07FF0:01C9DA81] Cc: IETF AVT WG Subject: Re: [AVT] Consensus on profile-level-id in 3984bis X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Randell Jesup List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 02:02:32 -0000 Tom Taylor writes: >It appears that the optimum outcome is to be able to signal both send and >receive capability. The legacy approach loses some of this information, >since profile-level-id contains the lesser of the two values. In a >legacy-new interworking situation it seems unlikely that we can improve on >this. Well, I'm not sure you can say that a legacy device definitively uses the lesser of send/receive in profile-level-id. Because of the way profile-level-id works, and how H.264 encodes streams, there is no problem with currently specifying a level above what you can "truly" support *sending*. I.e. you can say you can receive and send level 3.0 via profile-level-id, but nothing forces you to use the full limits of level 3.0 when sending. You can send a stream that could be encoded identically in level 2.0; you can even mark it as level 3.0 in the SPS/PPS NAL units. On the other side of the equation, it is the lesser - if you can only receive level 2.0 when all the limits in the received stream are maxed out, you can't use anything above level 2.0 in profile-level-id. (You can *extend* it (such as with max-fs), if you also agree to decode the extension as well.) Those are the *current* semantics of profile-level-id. A legacy device may (or may not) as mentioned over-state it's ability to encode. You could use an parameter that specifies the max sending level supported in an offer (there's no point in an answer I believe). I originally proposed this. However, on reflection, there's very little if anything to gain from that that I can see. A receiver could respond to level-upgrade-allowed=1 (or level-asymmetry-allowed=1) with the highest level it can receive. Now each side knows the highest level the other can receive, and can send up to that level. The only downside I can possibly think of to not knowing the maximum sending ability is that a receiver could perhaps not allocate as many resources if it knew the offerer couldn't send above level N. Example: A: Can receive level 2.0 (small LCD perhaps), can send level 3.0 B: Can receive level 5.0, can send level 3.0 (more common form of send/recv asymmetry) A offers to be with profile-level-id=420014;level-asymmetry-allowed=1 B answers with profile-level-id=420032 A will send at level 3.0 B will send at level 2.0 (and must allocate resources to potentially receive 5.0) If you had a maximum-send-level parameter: A offers to be with profile-level-id=420014;sprop-max-level=1E B answers with profile-level-id=42001E A will send at level 3.0 B will send at level 2.0 (and only has to allocate resources for level 3.0) The question is "is it worth it"? Also, while this may let you limit resources, you may also limit the options of the sender. For example, in the first case above, since A knows B can receive 5.0, A could send a higher frame size than 3.0 supports (perhaps at a lower framerate), even though A can't support sending "full" level 3.1. I should also note that quantizing the maximum level you can send is VERY subjective/arbitrary, because of how the encoding works. See the discussion above about how you don't have to max out the level you're supposedly sending. So my suggestion is to use level-asymmetry-allowed. (See my previous post for how this differs from level-upgrade-allowed - it allows asymmetric levels on level downgrade as well, which is actually probably a more common case.) >That suggests that profile-level-id should retain its current semantics, >and one or two new parameters (only one of which would be present in the >offer or answer) would indicate two things: >a) a value which is higher than the value given in profile-level-id; >b) whether that value is a send or receive capability. > >If it's just one parameter, it would have to be double valued >e.g., alternate-level-id="send,". > >If it is two parameters, the appropriate parameter to include would depend >on which whether the capability being reported is send or receive, >e.g., send-level-id= >or recv-level-id=but never both in the same stream. > >Ye-Kui Wang wrote: >> Another interoperability issue relates to the semantics change of the level >> part of profile-level-id. Currently, the level part, when used capability >> exchange or session setup, gives the upper limit of both decoding capability >> and encoding capability, as seen from the following two paragraphs excerpted >> from the bis draft (the same in spirit in 3984): >> >> "The profile-level-id parameter indicates the default sub-profile, i.e. the >> subset of coding tools that may have been used to generate the stream or >> that the receiver supports, and the default level of the stream or the >> receiver supports." >> >> "If the profile-level-id parameter is used for capability exchange or >> session setup procedure, it indicates the subset of coding tools, which is >> equal to the default sub-profile, and the highest level, which is equal to >> the default level, that the codec supports. All levels lower than the >> default level are also supported by the codec. " >> >> When level upgrade is allowed, then this semantics must change, such that >> the level part basically indicates only the decoding capability. This change >> of course creates different understandings between the two sides whenever >> one is legacy and the other is new. >> >> We have at least the following options to go to allow for level upgrade (the >> semantics change above is anyway needed): - To add >> "level-upgrade-allowed". - To add "level-upgrade-allowed" and another >> parameter, say >> sending-capability-level, to indicate the sending capability expressed as a >> level value. - To go wildly, by making all paramters not starting with >> "sprop-" as >> receiving capabilities. Another group of parameters not starting with >> "sprop-" can be optionally used to indicate sending capabilities. When these >> sending capability parameters are not present, the sending capabilities are >> by default equal to the receiving capabilties. >> >> A decision needs to be made which one to take. >> >> In any case, I hope a proponent could provide relatively mature text, >> including changes to semantics, offer/answer rules (including parameter sets >> considerations in offer/answer), declarative usage, SDP examples, and >> discussion of backward compatibility issues. >> >> Note that all the changes will also affect the SVC payload draft, as they >> basically need to be appropriately integrated to the SVC payload draft. >> >> BR, YK >> >... >_______________________________________________ >Audio/Video Transport Working Group >avt@ietf.org >https://www.ietf.org/mailman/listinfo/avt -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com "The fetters imposed on liberty at home have ever been forged out of the weapons provided for defence against real, pretended, or imaginary dangers from abroad." - James Madison, 4th US president (1751-1836) From yekuiwang@huawei.com Thu May 21 19:43:26 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 565523A6DA7 for ; Thu, 21 May 2009 19:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4V8SNZEhqIyN for ; Thu, 21 May 2009 19:43:25 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 0EFD93A6D9C for ; Thu, 21 May 2009 19:43:25 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KK0007MGYB13C@usaga02-in.huawei.com> for avt@ietf.org; Thu, 21 May 2009 19:45:01 -0700 (PDT) Received: from W90946 ([10.51.0.43]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KK0000D0YAV2P@usaga02-in.huawei.com> for avt@ietf.org; Thu, 21 May 2009 19:45:01 -0700 (PDT) Date: Thu, 21 May 2009 22:44:54 -0400 From: Ye-Kui Wang In-reply-to: To: 'Randell Jesup' , 'Tom Taylor' Message-id: <3221EC0396044781B11D483B77E085A1@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcnagaWORFnAlgzbS9qDh3miKSvlHwABLriw References: <4A15046C.5080600@rogers.com> <006701c9d9e9$51679500$f436bf00$%roni@huawei.com> <7779AD69A5E54F9F84E473BB4F4E1E71@china.huawei.com> <4A157ADA.8060900@rogers.com> Cc: 'IETF AVT WG' Subject: Re: [AVT] Consensus on profile-level-id in 3984bis X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 02:43:26 -0000 Randell, If the following are considered, then let the other side know the sending capability (as well as whether level upgrade is allowed) would be very useful. - One may want to request a specific mode, e.g. a spatial resolution, from the sender, for example by using image attribute mmusic draft. - Video adaptation, in terms of bitrate, frame rate, and/or spatial resolution etc, may happen during the session, and may be initiated by either side. BR, YK > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > Behalf Of Randell Jesup > Sent: Thursday, May 21, 2009 10:04 PM > To: Tom Taylor > Cc: IETF AVT WG > Subject: Re: [AVT] Consensus on profile-level-id in 3984bis > > Tom Taylor writes: > >It appears that the optimum outcome is to be able to signal > both send > >and receive capability. The legacy approach loses some of this > >information, since profile-level-id contains the lesser of the two > >values. In a legacy-new interworking situation it seems > unlikely that > >we can improve on this. > > Well, I'm not sure you can say that a legacy device > definitively uses the lesser of send/receive in > profile-level-id. Because of the way profile-level-id works, > and how H.264 encodes streams, there is no problem with > currently specifying a level above what you can "truly" > support *sending*. I.e. you can say you can receive and send > level 3.0 via profile-level-id, but nothing forces you to use > the full limits of level 3.0 when sending. You can send a > stream that could be encoded identically in level 2.0; you > can even mark it as level 3.0 in the SPS/PPS NAL units. > > On the other side of the equation, it is the lesser - if you > can only receive level 2.0 when all the limits in the > received stream are maxed out, you can't use anything above > level 2.0 in profile-level-id. (You can > *extend* it (such as with max-fs), if you also agree to > decode the extension as well.) > > Those are the *current* semantics of profile-level-id. A > legacy device may (or may not) as mentioned over-state it's > ability to encode. > > You could use an parameter that specifies the max sending > level supported in an offer (there's no point in an answer I > believe). I originally proposed this. However, on > reflection, there's very little if anything to gain from that > that I can see. A receiver could respond to > level-upgrade-allowed=1 (or level-asymmetry-allowed=1) with > the highest level it can receive. Now each side knows the > highest level the other can receive, and can send up to that > level. The only downside I can possibly think of to not > knowing the maximum sending ability is that a receiver could > perhaps not allocate as many resources if it knew the offerer > couldn't send above level N. Example: > > A: Can receive level 2.0 (small LCD perhaps), can send level 3.0 > B: Can receive level 5.0, can send level 3.0 (more common > form of send/recv > asymmetry) > > A offers to be with profile-level-id=420014;level-asymmetry-allowed=1 > B answers with profile-level-id=420032 > > A will send at level 3.0 > B will send at level 2.0 (and must allocate resources to potentially > receive 5.0) > > If you had a maximum-send-level parameter: > > A offers to be with profile-level-id=420014;sprop-max-level=1E > B answers with profile-level-id=42001E > > A will send at level 3.0 > B will send at level 2.0 (and only has to allocate resources > for level 3.0) > > > The question is "is it worth it"? Also, while this may let > you limit resources, you may also limit the options of the > sender. For example, in the first case above, since A knows > B can receive 5.0, A could send a higher frame size than 3.0 > supports (perhaps at a lower framerate), even though A can't > support sending "full" level 3.1. > > I should also note that quantizing the maximum level you can > send is VERY subjective/arbitrary, because of how the > encoding works. See the discussion above about how you don't > have to max out the level you're supposedly sending. > > So my suggestion is to use level-asymmetry-allowed. (See my > previous post for how this differs from level-upgrade-allowed > - it allows asymmetric levels on level downgrade as well, > which is actually probably a more common > case.) > > >That suggests that profile-level-id should retain its current > >semantics, and one or two new parameters (only one of which would be > >present in the offer or answer) would indicate two things: > >a) a value which is higher than the value given in profile-level-id; > >b) whether that value is a send or receive capability. > > > >If it's just one parameter, it would have to be double valued e.g., > >alternate-level-id="send,". > > > >If it is two parameters, the appropriate parameter to include would > >depend on which whether the capability being reported is send or > >receive, e.g., send-level-id= > >or recv-level-id= >but never both in the same stream. > > > >Ye-Kui Wang wrote: > >> Another interoperability issue relates to the semantics > change of the > >> level part of profile-level-id. Currently, the level part, > when used > >> capability exchange or session setup, gives the upper > limit of both > >> decoding capability and encoding capability, as seen from the > >> following two paragraphs excerpted from the bis draft (the > same in spirit in 3984): > >> > >> "The profile-level-id parameter indicates the default sub-profile, > >> i.e. the subset of coding tools that may have been used to > generate > >> the stream or that the receiver supports, and the default level of > >> the stream or the receiver supports." > >> > >> "If the profile-level-id parameter is used for capability > exchange or > >> session setup procedure, it indicates the subset of coding tools, > >> which is equal to the default sub-profile, and the highest level, > >> which is equal to the default level, that the codec supports. All > >> levels lower than the default level are also supported by > the codec. " > >> > >> When level upgrade is allowed, then this semantics must > change, such > >> that the level part basically indicates only the decoding > capability. > >> This change of course creates different understandings between the > >> two sides whenever one is legacy and the other is new. > >> > >> We have at least the following options to go to allow for level > >> upgrade (the semantics change above is anyway needed): - To add > >> "level-upgrade-allowed". - To add "level-upgrade-allowed" > and another > >> parameter, say sending-capability-level, to indicate the sending > >> capability expressed as a level value. - To go wildly, by > making all > >> paramters not starting with "sprop-" as receiving capabilities. > >> Another group of parameters not starting with "sprop-" can be > >> optionally used to indicate sending capabilities. When > these sending > >> capability parameters are not present, the sending > capabilities are > >> by default equal to the receiving capabilties. > >> > >> A decision needs to be made which one to take. > >> > >> In any case, I hope a proponent could provide relatively > mature text, > >> including changes to semantics, offer/answer rules (including > >> parameter sets considerations in offer/answer), declarative usage, > >> SDP examples, and discussion of backward compatibility issues. > >> > >> Note that all the changes will also affect the SVC payload > draft, as > >> they basically need to be appropriately integrated to the > SVC payload draft. > >> > >> BR, YK > >> > >... > >_______________________________________________ > >Audio/Video Transport Working Group > >avt@ietf.org > >https://www.ietf.org/mailman/listinfo/avt > > > -- > Randell Jesup, Worldgate (developers of the Ojo videophone), > ex-Amiga OS team rjesup@wgate.com "The fetters imposed on > liberty at home have ever been forged out of the weapons > provided for defence against real, pretended, or imaginary > dangers from abroad." > - James Madison, 4th US president (1751-1836) > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > From rjesup@wgate.com Thu May 21 20:12:00 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DB333A6A6E for ; Thu, 21 May 2009 20:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.581 X-Spam-Level: X-Spam-Status: No, score=-1.581 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Lmba47xfIwM for ; Thu, 21 May 2009 20:11:58 -0700 (PDT) Received: from exchange1.wgate.com (pr-66-150-46-254.wgate.com [66.150.46.254]) by core3.amsl.com (Postfix) with ESMTP id D1C433A68FD for ; Thu, 21 May 2009 20:11:57 -0700 (PDT) Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 May 2009 23:13:36 -0400 To: Ye-Kui Wang References: <4A15046C.5080600@rogers.com> <006701c9d9e9$51679500$f436bf00$%roni@huawei.com> <7779AD69A5E54F9F84E473BB4F4E1E71@china.huawei.com> <4A157ADA.8060900@rogers.com> <3221EC0396044781B11D483B77E085A1@china.huawei.com> From: Randell Jesup Date: Thu, 21 May 2009 23:13:45 -0400 In-Reply-To: <3221EC0396044781B11D483B77E085A1@china.huawei.com> (Ye-Kui Wang's message of "Thu\, 21 May 2009 22\:44\:54 -0400") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 22 May 2009 03:13:36.0022 (UTC) FILETIME=[4B964B60:01C9DA8B] Cc: 'Tom Taylor' , 'IETF AVT WG' Subject: Re: [AVT] Consensus on profile-level-id in 3984bis X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Randell Jesup List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 03:12:00 -0000 Ye-Kui Wang writes: >If the following are considered, then let the other side know the sending >capability (as well as whether level upgrade is allowed) would be very >useful. > >- One may want to request a specific mode, e.g. a spatial resolution, from >the sender, for example by using image attribute mmusic draft. Does adding a max-send-level actually help you there? How does this interact with how you decide what your max sending level is? As mentioned below, choosing a value for that (other than basing it on resolution alone, and that just might put a lower bound on it) is extremely subjective at best. >- Video adaptation, in terms of bitrate, frame rate, and/or spatial >resolution etc, may happen during the session, and may be initiated by >either side. Again, how would this work in practice, and how would adding it here help? Adaptation within the negotiated limits can occur now, so I don't see the advantage here. If you need to change the maximum limits (why? weren't they properly negotiated to start with?), then you can re-invite. I think we need a concrete example, in order to know if what you're proposing is sufficient - or if it works. I'm quite unclear on how you believe specifying a max send level will help anything, since your list is quite vague. >BR, YK > >> -----Original Message----- >> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On >> Behalf Of Randell Jesup >> Sent: Thursday, May 21, 2009 10:04 PM >> To: Tom Taylor >> Cc: IETF AVT WG >> Subject: Re: [AVT] Consensus on profile-level-id in 3984bis >> >> Tom Taylor writes: >> >It appears that the optimum outcome is to be able to signal >> both send >> >and receive capability. The legacy approach loses some of this >> >information, since profile-level-id contains the lesser of the two >> >values. In a legacy-new interworking situation it seems >> unlikely that >> >we can improve on this. >> >> Well, I'm not sure you can say that a legacy device >> definitively uses the lesser of send/receive in >> profile-level-id. Because of the way profile-level-id works, >> and how H.264 encodes streams, there is no problem with >> currently specifying a level above what you can "truly" >> support *sending*. I.e. you can say you can receive and send >> level 3.0 via profile-level-id, but nothing forces you to use >> the full limits of level 3.0 when sending. You can send a >> stream that could be encoded identically in level 2.0; you >> can even mark it as level 3.0 in the SPS/PPS NAL units. >> >> On the other side of the equation, it is the lesser - if you >> can only receive level 2.0 when all the limits in the >> received stream are maxed out, you can't use anything above >> level 2.0 in profile-level-id. (You can >> *extend* it (such as with max-fs), if you also agree to >> decode the extension as well.) >> >> Those are the *current* semantics of profile-level-id. A >> legacy device may (or may not) as mentioned over-state it's >> ability to encode. >> >> You could use an parameter that specifies the max sending >> level supported in an offer (there's no point in an answer I >> believe). I originally proposed this. However, on >> reflection, there's very little if anything to gain from that >> that I can see. A receiver could respond to >> level-upgrade-allowed=1 (or level-asymmetry-allowed=1) with >> the highest level it can receive. Now each side knows the >> highest level the other can receive, and can send up to that >> level. The only downside I can possibly think of to not >> knowing the maximum sending ability is that a receiver could >> perhaps not allocate as many resources if it knew the offerer >> couldn't send above level N. Example: >> >> A: Can receive level 2.0 (small LCD perhaps), can send level 3.0 >> B: Can receive level 5.0, can send level 3.0 (more common >> form of send/recv >> asymmetry) >> >> A offers to be with profile-level-id=420014;level-asymmetry-allowed=1 >> B answers with profile-level-id=420032 >> >> A will send at level 3.0 >> B will send at level 2.0 (and must allocate resources to potentially >> receive 5.0) >> >> If you had a maximum-send-level parameter: >> >> A offers to be with profile-level-id=420014;sprop-max-level=1E >> B answers with profile-level-id=42001E >> >> A will send at level 3.0 >> B will send at level 2.0 (and only has to allocate resources >> for level 3.0) >> >> >> The question is "is it worth it"? Also, while this may let >> you limit resources, you may also limit the options of the >> sender. For example, in the first case above, since A knows >> B can receive 5.0, A could send a higher frame size than 3.0 >> supports (perhaps at a lower framerate), even though A can't >> support sending "full" level 3.1. >> >> I should also note that quantizing the maximum level you can >> send is VERY subjective/arbitrary, because of how the >> encoding works. See the discussion above about how you don't >> have to max out the level you're supposedly sending. >> >> So my suggestion is to use level-asymmetry-allowed. (See my >> previous post for how this differs from level-upgrade-allowed >> - it allows asymmetric levels on level downgrade as well, >> which is actually probably a more common >> case.) >> >> >That suggests that profile-level-id should retain its current >> >semantics, and one or two new parameters (only one of which would be >> >present in the offer or answer) would indicate two things: >> >a) a value which is higher than the value given in profile-level-id; >> >b) whether that value is a send or receive capability. >> > >> >If it's just one parameter, it would have to be double valued e.g., >> >alternate-level-id="send,". >> > >> >If it is two parameters, the appropriate parameter to include would >> >depend on which whether the capability being reported is send or >> >receive, e.g., send-level-id= >> >or recv-level-id=> >but never both in the same stream. >> > >> >Ye-Kui Wang wrote: >> >> Another interoperability issue relates to the semantics >> change of the >> >> level part of profile-level-id. Currently, the level part, >> when used >> >> capability exchange or session setup, gives the upper >> limit of both >> >> decoding capability and encoding capability, as seen from the >> >> following two paragraphs excerpted from the bis draft (the >> same in spirit in 3984): >> >> >> >> "The profile-level-id parameter indicates the default sub-profile, >> >> i.e. the subset of coding tools that may have been used to >> generate >> >> the stream or that the receiver supports, and the default level of >> >> the stream or the receiver supports." >> >> >> >> "If the profile-level-id parameter is used for capability >> exchange or >> >> session setup procedure, it indicates the subset of coding tools, >> >> which is equal to the default sub-profile, and the highest level, >> >> which is equal to the default level, that the codec supports. All >> >> levels lower than the default level are also supported by >> the codec. " >> >> >> >> When level upgrade is allowed, then this semantics must >> change, such >> >> that the level part basically indicates only the decoding >> capability. >> >> This change of course creates different understandings between the >> >> two sides whenever one is legacy and the other is new. >> >> >> >> We have at least the following options to go to allow for level >> >> upgrade (the semantics change above is anyway needed): - To add >> >> "level-upgrade-allowed". - To add "level-upgrade-allowed" >> and another >> >> parameter, say sending-capability-level, to indicate the sending >> >> capability expressed as a level value. - To go wildly, by >> making all >> >> paramters not starting with "sprop-" as receiving capabilities. >> >> Another group of parameters not starting with "sprop-" can be >> >> optionally used to indicate sending capabilities. When >> these sending >> >> capability parameters are not present, the sending >> capabilities are >> >> by default equal to the receiving capabilties. >> >> >> >> A decision needs to be made which one to take. >> >> >> >> In any case, I hope a proponent could provide relatively >> mature text, >> >> including changes to semantics, offer/answer rules (including >> >> parameter sets considerations in offer/answer), declarative usage, >> >> SDP examples, and discussion of backward compatibility issues. >> >> >> >> Note that all the changes will also affect the SVC payload >> draft, as >> >> they basically need to be appropriately integrated to the >> SVC payload draft. >> >> >> >> BR, YK >> >> >> >... >> >_______________________________________________ >> >Audio/Video Transport Working Group >> >avt@ietf.org >> >https://www.ietf.org/mailman/listinfo/avt >> >> >> -- >> Randell Jesup, Worldgate (developers of the Ojo videophone), >> ex-Amiga OS team rjesup@wgate.com "The fetters imposed on >> liberty at home have ever been forged out of the weapons >> provided for defence against real, pretended, or imaginary >> dangers from abroad." >> - James Madison, 4th US president (1751-1836) >> >> _______________________________________________ >> Audio/Video Transport Working Group >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt >> -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com "The fetters imposed on liberty at home have ever been forged out of the weapons provided for defence against real, pretended, or imaginary dangers from abroad." - James Madison, 4th US president (1751-1836) From jaehwan@vidiator.com Thu May 21 20:26:27 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75C0B3A6925 for ; Thu, 21 May 2009 20:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.04 X-Spam-Level: X-Spam-Status: No, score=-2.04 tagged_above=-999 required=5 tests=[AWL=0.560, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1iNtbgfiTolk for ; Thu, 21 May 2009 20:26:26 -0700 (PDT) Received: from kor1corpmail01.mediator.com (vkimail.vidiator.com [211.189.53.2]) by core3.amsl.com (Postfix) with ESMTP id 0187A3A6DA7 for ; Thu, 21 May 2009 20:26:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 22 May 2009 12:28:01 +0900 Message-ID: In-Reply-To: <302f570905211446j7317a6f8o3d1e6a0b405a3568@mail.gmail.com> References: <302f570905211446j7317a6f8o3d1e6a0b405a3568@mail.gmail.com> From: "Jaehwan Kim" To: "John Lazzaro" , Subject: Re: [AVT] Comments on draft-pantos-http-live-streaming-00.txt ... X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 03:26:27 -0000 Hi John, It's cool idea!( although this playlist file looks=20 not much heavy like an ordinary front page of many=20 famous shopping portal sites, it's worth while). And thanks for the good information about HTML5. I think this draft would need to be enhanced in the end,=20 (no matter what group decides to make it WG item),=20 to consider many good applications already existed=20 in different realm.=20 Just I am thinking a KISS paradigm at the moment. Regards, Jaehwan -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of John Lazzaro Sent: Friday, May 22, 2009 6:47 AM To: avt@ietf.org Subject: [AVT] Comments on draft-pantos-http-live-streaming-00.txt ... Hi everyone, Comments on draft-pantos-http-live-streaming-00.txt below. What jumped out at me was that this is a late-1990s approach to a problem ... but its almost 2010 ... In my view, the I-D is trying to do for audio what the AJAX client code for Google Maps does for image map tiles. Namely, pre-loading short media files over HTTP, to drive a user interface that the user perceives as continuous (and in the Google Maps case, responsive to user input). I haven't looked at HTML5 (yet), but I was under the impression one goal of its audio/video features is to provide the primitives to make it possible to implement the protocol described in draft-pantos-http-live-streaming-00.txt using AJAX techniques. If the feature set isn't there yet in HTML5 to do that, I think the time spent working on this I-D is better spent working within the HTML5 process to get the features that are needed. It seems to me that AJAX is a more natural way to implement this sort of "concatenation of pre-downloaded 10-second files" streaming. If there is AVT consensus that draft-pantos-http-live-streaming-00.txt's general approach is acceptable for a work-item, I'll do a second review of potential technical issues with the protocol itself ... --=20 John Lazzaro http://www.cs.berkeley.edu/~lazzaro john [dot] lazzaro [at] gmail [dot] com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www.ietf.org/mailman/listinfo/avt From Even.roni@huawei.com Thu May 21 21:27:19 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5CB13A6F43 for ; Thu, 21 May 2009 21:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.126 X-Spam-Level: X-Spam-Status: No, score=-1.126 tagged_above=-999 required=5 tests=[AWL=-0.632, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gg4x1XXZrS+G for ; Thu, 21 May 2009 21:27:12 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 9BF473A6FD0 for ; Thu, 21 May 2009 21:27:11 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KK10032Z33RHG@szxga02-in.huawei.com> for avt@ietf.org; Fri, 22 May 2009 12:28:39 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KK10023V33QPK@szxga02-in.huawei.com> for avt@ietf.org; Fri, 22 May 2009 12:28:39 +0800 (CST) Received: from windows8d787f9 (bzq-79-181-118-116.red.bezeqint.net [79.181.118.116]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KK100GIT31PZ1@szxml01-in.huawei.com>; Fri, 22 May 2009 12:28:38 +0800 (CST) Date: Fri, 22 May 2009 07:26:36 +0300 From: Roni Even In-reply-to: To: 'Marshall Eubanks' , "'Ali C. Begen (abegen)'" Message-id: <017a01c9da95$9986cb60$cc946220$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_w8aGTNgbHPPyPmCJoBYJLA)" Content-language: en-us Thread-index: Acnafh3zufQj+F0MTBSIHSx5xANIhgAFy/WA References: <81B9B88E2F9D574AA5328A85547CDE91013038E4@xmb-rtp-21d.amer.cisco.com> <81B9B88E2F9D574AA5328A85547CDE9101303DA5@xmb-rtp-21d.amer.cisco.com> <00de01c9d3c8$32b6cad0$98246070$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D54094C3DC9@xmb-sjc-215.amer.cisco.com> Cc: avt@ietf.org, "'Bill Ver Steeg \(versteb\)'" Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions(RAMS) as a working group item X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 04:27:19 -0000 This is a multipart message in MIME format. --Boundary_(ID_w8aGTNgbHPPyPmCJoBYJLA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Marshalll, By multiplexing we are discussing RTP/RTCP multiplex over the unicast stream and not Audio and video multiplexing. Roni From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Marshall Eubanks Sent: Friday, May 22, 2009 4:38 AM To: Ali C. Begen (abegen) Cc: Bill Ver Steeg (versteb); Roni Even; avt@ietf.org Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions(RAMS) as a working group item On Wed, May 13, 2009 at 7:46 PM, Ali C. Begen (abegen) wrote: Roni, There are a few other important issues that we need WG input on: - The scenarios where there are multiple SSRC-multiplexed RTP streams in a single RTP session. Will RAMS apply to individual streams or the whole session? Similarly, what happens when the same multicast session carries multiple RTP sessions (same multicast address but different ports). Clearly, such cases will exist. We have a draft text that discusses different scenarios and what needs to be done in each such cases. But before we move forward, we would like to hear WG input. Managing multiple bursts simultaneously requires some details. - The security section needs to be completed as well as the NAT section. Some comments inline. > I have some others issues to add to this list > > 1. I suggest to add to the RAMS request an optional parameter that will > allow the receiver to request that the unicast stream will be sent to the a > port specified in this parameter instead of the port offered in the > announcement. This is tricky. Remember that the RAMS request message goes to the Feedback Target of the primary multicast session but the burst comes from the retransmission server. They could be the same entity or different ones. Any solution should consider this in its design. > 2. The issue of RTP/RTCP multiplexing should be discussed, is it mandatory > to use it. It is not mandatory. Even if we made it mandatory, it would not help us with the issue you describe above. Muxing only simplifies NAT traversal. Sorry for responding late, but I have been digging through this. I would strongly urge that RAMS support unmuxed audio / video. This is common in certain circumstances, and is probably more common in multicast RTP than muxed AV. (One use case is multiple audio tracks, such as different languages, for one video, another is multiple video encodings, such as different aspect ratios, for one audio.) Marshall > 3. The issue of FW/NAT traversal for the unicast stream should also be > discussed. Indeed. The NAT section is TBC. -acbegen > > Thanks > Roni Even > > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Bill > Ver Steeg (versteb) > Sent: Wednesday, May 13, 2009 3:08 PM > To: avt@ietf.org > Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP > Sessions(RAMS) as a working group item > > > > We submitted version -00 of "draft-ietf-avt-rapid-acquisition-for-rtp". > This is basically a name change from > "draft-versteeg-avt-rapid-synchronization-for-rtp-03" to avoid confusion > with other pending "synchronization" drafts. > > There were some issues remaining from -03 version that have already been > identified on the list and technical breakout session. We are planning > to address these issues in the next version of the draft. > > We hope to address the following areas in the next revision of the > draft: > > - Section 7 - Define a method for vendor-specific and generic extensions > to RAMS, lay out the intent to use FMT==6 for all messages and to have > an (extensible) enumeration of the RAMS sub-FMTs > - Section 8 - Elaborate SDP to describe the various use cases for RAMS > - Section 13 - Define a single registry (FMT==6) for all RAMS > transactions, and then define Sub-FMT Values for RAMS Messages. Also > define an extensible RAMS TLV space registry > > - We need to make some typographical corrections, mostly changing from > RMS to RAMS. > - We need to formalize the TLV definitions and extensions (both vendor > and private extensions) > - We need to register FMT=6 with IANA for RAMS and use sub-FMT values to > identify various RAMS messages > - We need to clarify the SDP section based on the earlier discussion. > The SDP example is still declarative and we are looking forward to > include more examples as we move forward. > - The IANA concerns section needs to be updated to reflect how to extend > the RAMS protocol. > - The unicast/multicast addresses need to be fixed according to the > idnits tool. > > Are there other issues that we need to address in the next revision of > the draft? The authors would like to address these high priority issues > in the next few days, so timely feedback would be appreciated. > > > Bill VerSteeg > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www.ietf.org/mailman/listinfo/avt --Boundary_(ID_w8aGTNgbHPPyPmCJoBYJLA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Marshalll,

By multiplexing we are discussing RTP/RTCP multiplex over the unicast stream and not Audio and video multiplexing.

 

Roni

 

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Marshall Eubanks
Sent: Friday, May 22, 2009 4:38 AM
To: Ali C. Begen (abegen)
Cc: Bill Ver Steeg (versteb); Roni Even; avt@ietf.org
Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions(RAMS) as a working group item

 

 

On Wed, May 13, 2009 at 7:46 PM, Ali C. Begen (abegen) <abegen@cisco.com> wrote:

Roni,

There are a few other important issues that we need WG input on:

- The scenarios where there are multiple SSRC-multiplexed RTP streams in a single RTP session. Will RAMS apply to individual streams or the whole session? Similarly, what happens when the same multicast session carries multiple RTP sessions (same multicast address but different ports). Clearly, such cases will exist. We have a draft text that discusses different scenarios and what needs to be done in each such cases. But before we move forward, we would like to hear WG input. Managing multiple bursts simultaneously requires some details.

- The security section needs to be completed as well as the NAT section.

Some comments inline.


> I have some others issues to add to this list
>
> 1. I suggest to add to the RAMS request an optional parameter that will
> allow the receiver to request that the unicast stream will be sent to the a
> port specified in this parameter instead of the port offered in the
> announcement.

This is tricky. Remember that the RAMS request message goes to the Feedback Target of the primary multicast session but the burst comes from the retransmission server. They could be the same entity or different ones. Any solution should consider this in its design.


> 2. The issue of RTP/RTCP multiplexing should be discussed, is it mandatory
> to use it.

It is not mandatory. Even if we made it mandatory, it would not help us with the issue you describe above. Muxing only simplifies NAT traversal.

 

Sorry for responding late, but I have been digging through this.

 

I would strongly urge that RAMS support unmuxed audio / video. This is common in certain circumstances, and is probably more common in multicast RTP than muxed AV. (One use case is multiple audio tracks, such as different languages, for one  video, another is multiple video encodings, such as different aspect ratios, for one audio.)

 

 Marshall

 


> 3. The issue of FW/NAT traversal for the unicast stream should also be
> discussed.

Indeed. The NAT section is TBC.

-acbegen


>
> Thanks
> Roni Even
>
> -----Original Message-----
> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Bill
> Ver Steeg (versteb)
> Sent: Wednesday, May 13, 2009 3:08 PM
> To: avt@ietf.org
> Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP
> Sessions(RAMS) as a working group item
>
>
>
> We submitted version -00 of "draft-ietf-avt-rapid-acquisition-for-rtp".
> This is basically a name change from
> "draft-versteeg-avt-rapid-synchronization-for-rtp-03" to avoid confusion
> with other pending "synchronization" drafts.
>
> There were some issues remaining from -03 version that have already been
> identified on the list and technical breakout session. We are planning
> to address these issues in the next version of the draft.
>
> We hope to address the following areas in the next revision of the
> draft:
>
> - Section 7 - Define a method for vendor-specific and generic extensions
> to RAMS, lay out the intent to use FMT==6 for all messages and to have
> an (extensible) enumeration of the RAMS sub-FMTs
> - Section 8 - Elaborate SDP to describe the various use cases for RAMS
> - Section 13 - Define a single registry (FMT==6) for all RAMS
> transactions, and then define Sub-FMT Values for RAMS Messages. Also
> define an extensible RAMS TLV space registry
>
> - We need to make some typographical corrections, mostly changing from
> RMS to RAMS.
> - We need to formalize the TLV definitions and extensions (both vendor
> and private extensions)
> - We need to register FMT=6 with IANA for RAMS and use sub-FMT values to
> identify various RAMS messages
> - We need to clarify the SDP section based on the earlier discussion.
> The SDP example is still declarative and we are looking forward to
> include more examples as we move forward.
> - The IANA concerns section needs to be updated to reflect how to extend
> the RAMS protocol.
> - The unicast/multicast addresses need to be fixed according to the
> idnits tool.
>
> Are there other issues that we need to address in the next revision of
> the draft? The authors would like to address these high priority issues
> in the next few days, so timely feedback would be appreciated.
>
>
> Bill VerSteeg
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt
>
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt

 

--Boundary_(ID_w8aGTNgbHPPyPmCJoBYJLA)-- From abegen@cisco.com Thu May 21 22:18:19 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C84293A7019 for ; Thu, 21 May 2009 22:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.403 X-Spam-Level: X-Spam-Status: No, score=-6.403 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZH-YfcSRW2F for ; Thu, 21 May 2009 22:18:13 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 2B1793A6ADB for ; Thu, 21 May 2009 22:18:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,231,1241395200"; d="scan'208";a="308938994" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 22 May 2009 05:19:26 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n4M5JQS6001044; Thu, 21 May 2009 22:19:26 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n4M5JQHJ028362; Fri, 22 May 2009 05:19:26 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 May 2009 22:19:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Thu, 21 May 2009 22:18:15 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54095E15CC@xmb-sjc-215.amer.cisco.com> In-Reply-To: <017a01c9da95$9986cb60$cc946220$%roni@huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions(RAMS) as a working group item Thread-Index: Acnafh3zufQj+F0MTBSIHSx5xANIhgAFy/WAAAHCRRA= References: <81B9B88E2F9D574AA5328A85547CDE91013038E4@xmb-rtp-21d.amer.cisco.com> <81B9B88E2F9D574AA5328A85547CDE9101303DA5@xmb-rtp-21d.amer.cisco.com> <00de01c9d3c8$32b6cad0$98246070$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D54094C3DC9@xmb-sjc-215.amer.cisco.com> <017a01c9da95$9986cb60$cc946220$%roni@huawei.com> From: "Ali C. Begen (abegen)" To: "Roni Even" , "Marshall Eubanks" X-OriginalArrivalTime: 22 May 2009 05:19:25.0856 (UTC) FILETIME=[DFA38A00:01C9DA9C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6797; t=1242969566; x=1243833566; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20RE=3A=20[AVT]=20Adopting=20Rapid=20Acquisition= 20of=20Multicast=20RTP=09Sessions(RAMS)=20as=20a=20working=2 0group=20item |Sender:=20; bh=AKhAXTlVVaxHb9GmE8RklMf/gEf0etikPRgdALIra9M=; b=Jm9xynN32kDbkRb+Z1KFLJ/FfQ/UXLW74ymV7R3A1LMWO7b5Uw1S+E0KBS kHApXMo+P1CtVPwJDKGqxEKSvSqR4K1l43Qn2lar/9uUVP5MA2ILXYynTk5Z 7Iqk8nvH8W4iC0WJRPGruS2DFyMiHpPmb9E23k3se+YVHcKBjUW2A=; Authentication-Results: sj-dkim-1; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: avt@ietf.org, "Bill Ver Steeg \(versteb\)" Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions(RAMS) as a working group item X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 05:18:20 -0000 Actually, Marshall has a valid concern. You are right that we are = considering RTP/RTCP muxing to ease the NAT traversal. However, there is = also this question what happens when the multicast session carries = multiple RTP streams. Do we rapidly acquire individual streams or = individual RTP sessions or the whole multicast session? I tried to emphasize this question in my email below and I am looking = forward to some input from AVT. Please share your comments. -acbegen=20 > -----Original Message----- > From: Roni Even [mailto:Even.roni@huawei.com] > Sent: Thursday, May 21, 2009 9:27 PM > To: 'Marshall Eubanks'; Ali C. Begen (abegen) > Cc: Bill Ver Steeg (versteb); avt@ietf.org > Subject: RE: [AVT] Adopting Rapid Acquisition of Multicast RTP = Sessions(RAMS) as a working > group item >=20 > Marshalll, >=20 > By multiplexing we are discussing RTP/RTCP multiplex over the unicast = stream and not Audio > and video multiplexing. >=20 >=20 >=20 > Roni >=20 >=20 >=20 > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Marshall Eubanks > Sent: Friday, May 22, 2009 4:38 AM > To: Ali C. Begen (abegen) > Cc: Bill Ver Steeg (versteb); Roni Even; avt@ietf.org > Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP = Sessions(RAMS) as a working > group item >=20 >=20 >=20 >=20 >=20 > On Wed, May 13, 2009 at 7:46 PM, Ali C. Begen (abegen) = wrote: >=20 > Roni, >=20 > There are a few other important issues that we need WG input on: >=20 > - The scenarios where there are multiple SSRC-multiplexed RTP streams = in a single RTP > session. Will RAMS apply to individual streams or the whole session? = Similarly, what > happens when the same multicast session carries multiple RTP sessions = (same multicast > address but different ports). Clearly, such cases will exist. We have = a draft text that > discusses different scenarios and what needs to be done in each such = cases. But before we > move forward, we would like to hear WG input. Managing multiple bursts = simultaneously > requires some details. >=20 > - The security section needs to be completed as well as the NAT = section. >=20 > Some comments inline. >=20 >=20 > > I have some others issues to add to this list > > > > 1. I suggest to add to the RAMS request an optional parameter that = will > > allow the receiver to request that the unicast stream will be sent = to the a > > port specified in this parameter instead of the port offered in the > > announcement. >=20 > This is tricky. Remember that the RAMS request message goes to the = Feedback Target of the > primary multicast session but the burst comes from the retransmission = server. They could > be the same entity or different ones. Any solution should consider = this in its design. >=20 >=20 > > 2. The issue of RTP/RTCP multiplexing should be discussed, is it = mandatory > > to use it. >=20 > It is not mandatory. Even if we made it mandatory, it would not help = us with the issue you > describe above. Muxing only simplifies NAT traversal. >=20 >=20 >=20 > Sorry for responding late, but I have been digging through this. >=20 >=20 >=20 > I would strongly urge that RAMS support unmuxed audio / video. This is = common in certain > circumstances, and is probably more common in multicast RTP than muxed = AV. (One use case > is multiple audio tracks, such as different languages, for one video, = another is multiple > video encodings, such as different aspect ratios, for one audio.) >=20 >=20 >=20 > Marshall >=20 >=20 >=20 >=20 > > 3. The issue of FW/NAT traversal for the unicast stream should also = be > > discussed. >=20 > Indeed. The NAT section is TBC. >=20 > -acbegen >=20 >=20 > > > > Thanks > > Roni Even > > > > -----Original Message----- > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf = Of Bill > > Ver Steeg (versteb) > > Sent: Wednesday, May 13, 2009 3:08 PM > > To: avt@ietf.org > > Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP > > Sessions(RAMS) as a working group item > > > > > > > > We submitted version -00 of = "draft-ietf-avt-rapid-acquisition-for-rtp". > > This is basically a name change from > > "draft-versteeg-avt-rapid-synchronization-for-rtp-03" to avoid = confusion > > with other pending "synchronization" drafts. > > > > There were some issues remaining from -03 version that have already = been > > identified on the list and technical breakout session. We are = planning > > to address these issues in the next version of the draft. > > > > We hope to address the following areas in the next revision of the > > draft: > > > > - Section 7 - Define a method for vendor-specific and generic = extensions > > to RAMS, lay out the intent to use FMT=3D=3D6 for all messages and = to have > > an (extensible) enumeration of the RAMS sub-FMTs > > - Section 8 - Elaborate SDP to describe the various use cases for = RAMS > > - Section 13 - Define a single registry (FMT=3D=3D6) for all RAMS > > transactions, and then define Sub-FMT Values for RAMS Messages. = Also > > define an extensible RAMS TLV space registry > > > > - We need to make some typographical corrections, mostly changing = from > > RMS to RAMS. > > - We need to formalize the TLV definitions and extensions (both = vendor > > and private extensions) > > - We need to register FMT=3D6 with IANA for RAMS and use sub-FMT = values to > > identify various RAMS messages > > - We need to clarify the SDP section based on the earlier = discussion. > > The SDP example is still declarative and we are looking forward to > > include more examples as we move forward. > > - The IANA concerns section needs to be updated to reflect how to = extend > > the RAMS protocol. > > - The unicast/multicast addresses need to be fixed according to the > > idnits tool. > > > > Are there other issues that we need to address in the next revision = of > > the draft? The authors would like to address these high priority = issues > > in the next few days, so timely feedback would be appreciated. > > > > > > Bill VerSteeg > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > > > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt >=20 >=20 From L.Wood@surrey.ac.uk Thu May 21 23:11:44 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89C0D3A6AA0 for ; Thu, 21 May 2009 23:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.335 X-Spam-Level: X-Spam-Status: No, score=-6.335 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDHHq7AR55a6 for ; Thu, 21 May 2009 23:11:43 -0700 (PDT) Received: from mail71.messagelabs.com (mail71.messagelabs.com [193.109.255.131]) by core3.amsl.com (Postfix) with SMTP id B4DE43A68AA for ; Thu, 21 May 2009 23:11:41 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-7.tower-71.messagelabs.com!1242972779!57784317!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [131.227.102.140] Received: (qmail 17636 invoked from network); 22 May 2009 06:12:59 -0000 Received: from ads40.surrey.ac.uk (HELO ads40.surrey.ac.uk) (131.227.102.140) by server-7.tower-71.messagelabs.com with SMTP; 22 May 2009 06:12:59 -0000 Received: from EVS-EC1-NODE4.surrey.ac.uk ([131.227.102.145]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 May 2009 07:12:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9DAA4.5A43CAB2" Date: Fri, 22 May 2009 07:12:58 +0100 Message-ID: <4835AFD53A246A40A3B8DA85D658C4BE7B1032@EVS-EC1-NODE4.surrey.ac.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] Comments on draft-pantos-http-live-streaming-00.txt ... Thread-Index: AcnaXfKgAq96RYWITYyGIZOb97b6owARZt64 References: <302f570905211446j7317a6f8o3d1e6a0b405a3568@mail.gmail.com> From: To: , X-OriginalArrivalTime: 22 May 2009 06:12:59.0330 (UTC) FILETIME=[5B04C220:01C9DAA4] Subject: Re: [AVT] Comments on draft-pantos-http-live-streaming-00.txt ... X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 06:11:44 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9DAA4.5A43CAB2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://tools.ietf.org/id/draft-pantos-http-live-streaming-00.txt There's a mismatch between the goal in the first sentence of the introduction: This document describes a protocol for transmitting unbounded streams of multimedia data over HTTP [RFC2616]. and the focus of this draft on actually being limited to using M3U files. For unbounded streams where the length is not known a priori, I was expecting to see heavy use of HTTP chunking. That is not the problem that this draft is trying to solve. Each media file URI MUST be preceded by an EXTINF tag. Its format is: #EXTINF:, "duration" is an integer that specifies the duration of the media file in seconds. =20 So it's necessary to know how long a file is before specifying it. The draft is not really dealing with an unbounded stream of data, more bringing together separate known resources seamlessly. As John says, that particular problem has been solved by AJAX. cheers, L. <http://www.ee.surrey.ac.uk/Personal/L.Wood/><L.Wood@surrey.ac.uk> -----Original Message----- From: avt-bounces@ietf.org on behalf of John Lazzaro Sent: Thu 2009-05-21 22:46 To: avt@ietf.org Subject: [AVT] Comments on draft-pantos-http-live-streaming-00.txt ... =20 Hi everyone, Comments on draft-pantos-http-live-streaming-00.txt below. What jumped out at me was that this is a late-1990s approach to a problem ... but its almost 2010 ... In my view, the I-D is trying to do for audio what the AJAX client code for Google Maps does for image map tiles. Namely, pre-loading short media files over HTTP, to drive a user interface that the user perceives as continuous (and in the Google Maps case, responsive to user input). I haven't looked at HTML5 (yet), but I was under the impression one goal of its audio/video features is to provide the primitives to make it possible to implement the protocol described in draft-pantos-http-live-streaming-00.txt using AJAX techniques. If the feature set isn't there yet in HTML5 to do that, I think the time spent working on this I-D is better spent working within the HTML5 process to get the features that are needed. It seems to me that AJAX is a more natural way to implement this sort of "concatenation of pre-downloaded 10-second files" streaming. If there is AVT consensus that draft-pantos-http-live-streaming-00.txt's general approach is acceptable for a work-item, I'll do a second review of potential technical issues with the protocol itself ... --=20 John Lazzaro http://www.cs.berkeley.edu/~lazzaro john [dot] lazzaro [at] gmail [dot] com ------_=_NextPart_001_01C9DAA4.5A43CAB2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Diso-8859-1"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 6.5.7653.38"> <TITLE>RE: [AVT] Comments on draft-pantos-http-live-streaming-00.txt = ...

http://tools.ietf.org/id/draft-pantos-http-live-streaming-00.txt
=
There's a mismatch between the goal in the first sentence of
the introduction:

   This document describes a protocol for transmitting = unbounded streams
   of multimedia data over HTTP [RFC2616].

and the focus of this draft on actually being limited to using
M3U files.

For unbounded streams where the length is not known a priori,
I was expecting to see heavy use of HTTP chunking.
That is not the problem that this draft is
trying to solve.

   Each media file URI MUST be preceded by an
   EXTINF tag.  Its format is:

   #EXTINF:<duration>,<title>

   "duration" is an integer that specifies the = duration of the media
   file in seconds. 

So it's necessary to know how long a file is before specifying it.
The draft is not really dealing with an unbounded stream of data,
more bringing together separate known resources seamlessly. As John
says, that particular problem has been solved by AJAX.

cheers,

L.

<http://www.ee.surrey= .ac.uk/Personal/L.Wood/><L.Wood@surrey.ac.uk>



-----Original Message-----
From: avt-bounces@ietf.org on behalf of John Lazzaro
Sent: Thu 2009-05-21 22:46
To: avt@ietf.org
Subject: [AVT] Comments on draft-pantos-http-live-streaming-00.txt = ...

Hi everyone,

Comments on draft-pantos-http-live-streaming-00.txt below.

What jumped out at me was that this is a late-1990s
approach to a problem ... but its almost 2010 ...

In my view, the I-D is trying to do for audio what the AJAX client = code
for Google Maps does for image map tiles. Namely, pre-loading short
media files over HTTP, to drive a user interface that the user
perceives as continuous (and in the Google Maps case,
responsive to user input).

I haven't looked at HTML5 (yet), but I was under the impression
one goal of its audio/video features is to provide the
primitives to make it possible to implement the protocol
described in draft-pantos-http-live-streaming-00.txt using
AJAX techniques.  If the feature set isn't there yet in HTML5
to do that, I think the time spent working on this I-D is better
spent working within the HTML5 process to get the features that
are needed.  It seems to me that AJAX is a more natural way to
implement this sort of "concatenation of pre-downloaded = 10-second
files" streaming.

If there is AVT consensus that = draft-pantos-http-live-streaming-00.txt's
general approach is acceptable for a work-item, I'll do a second = review
of potential technical issues with the protocol itself ...

--
John Lazzaro
http://www.cs.berkeley.edu/~= lazzaro
john [dot] lazzaro [at] gmail [dot] com

------_=_NextPart_001_01C9DAA4.5A43CAB2-- From enrico.marocco@telecomitalia.it Fri May 22 00:58:59 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C63263A6929; Fri, 22 May 2009 00:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.529 X-Spam-Level: X-Spam-Status: No, score=-0.529 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49sZZANQ0MSK; Fri, 22 May 2009 00:58:58 -0700 (PDT) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by core3.amsl.com (Postfix) with ESMTP id 1323D3A68AA; Fri, 22 May 2009 00:58:55 -0700 (PDT) Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.1.340.0; Fri, 22 May 2009 10:00:29 +0200 Received: from [10.229.8.41] (10.229.8.41) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.1.359.3; Fri, 22 May 2009 10:00:28 +0200 Message-ID: <4A165B9F.3020902@telecomitalia.it> Date: Fri, 22 May 2009 10:00:31 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: , X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080301080508080709070102" Subject: [AVT] [Fwd: [dispatch] Yet another problem to dispatch] X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 07:58:59 -0000 --------------ms080301080508080709070102 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Hi, we have just submitted a problem statement whose solution space probably falls somewhere within the scope of AVT and XCON WGs. Any comments, possibly on the dispatch list, will be extremely appreciated. Enrico -------- Original Message -------- Subject: [dispatch] Yet another problem to dispatch Date: Fri, 22 May 2009 00:45:51 +0200 From: Emil Ivov To: dispatch@ietf.org , Marocco Enrico Hey folks, We have been working on client side conference calls for SIP Communicator lately and were thinking about implementing participant sound level indicators. The feature was inspired by Skype's Mac OS X GUI which you can have a look at over here: http://sip-communicator.org/skypeconf/skypeconf.png Since we couldn't find an existing IETF mechanism for a mixer to dispatch information on sound level to conference participants, Enrico and I thought that this may be an issue that is worth addressing through dispatch. After talking to some of you privately and discussing it among ourselves we have decided to come up with a document presenting the issue in some more detail. We are also including short descriptions of what we consider to be possible approaches for resolving it. http://www.ietf.org/internet-drafts/draft-ivov-dispatch-slic-ps-00.txt Comments are most welcome, as well as any show of interest or indications of what you think would be the right place(s) to work on the subject. Thanks, Emil --------------ms080301080508080709070102 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJwTCC AzswggKkoAMCAQICEEIEYmjMZBX3Us1Th/pMjJYwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDMxNjE3NTMwMloX DTEwMDMxNjE3NTMwMlowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEuMCwG CSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEnMCUGCSqGSIb3 DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAvd38YWuquonbz4lP4GKp0qij0v4MgXpK/BW87GvoqHz3iQvO1Tb6f4yEtFel vpK2drtUHWyY+ww6QQSOGJvSWEKTRVX5KsXpN2yNeY4kceezCjsXBvwNPlGHrzJifUByvwzD QSnQLocE1i89x7P2T5brcaGBBgricwQL1Cggg97zp1yGrj2VIJE03GSpEL01d+omAFUou3mx 8R/9XOnGnSlDpcOV6s2Ww3NN07+7sSBaE0vcvlYF8pr1BWDl2JJobG9qpC9DlplpDZOdmsAG u/qwsI0AsucY5ZBFKqzKizQ5PGhrh3u2PHRGNncuHUANF0cPfVs7AHjHjudH7PzU2wIDAQAB o1YwVDBEBgNVHREEPTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJp Y28ubWFyb2Njb0BnbWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQB3 Mi6SymgE1cfsbmr5LWvWVdO58/a0O95kXL2puRn9kGjFN1tAzHQc/UxJs0gIyRRs3gGBR+p6 TT1gmnucO8Ji0gJBMBL+ogcfyaV30hZtUceiRevemXvZW2QOCLdYUf6KdB6ccX7r3a58SRRL l5YTZ7bIhyAEmeI60ioyMI8U5jCCAzswggKkoAMCAQICEEIEYmjMZBX3Us1Th/pMjJYwDQYJ KoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBMB4XDTA5MDMxNjE3NTMwMloXDTEwMDMxNjE3NTMwMlowejEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNv bWl0YWxpYS5pdDEnMCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvd38YWuquonbz4lP4GKp0qij0v4MgXpK /BW87GvoqHz3iQvO1Tb6f4yEtFelvpK2drtUHWyY+ww6QQSOGJvSWEKTRVX5KsXpN2yNeY4k ceezCjsXBvwNPlGHrzJifUByvwzDQSnQLocE1i89x7P2T5brcaGBBgricwQL1Cggg97zp1yG rj2VIJE03GSpEL01d+omAFUou3mx8R/9XOnGnSlDpcOV6s2Ww3NN07+7sSBaE0vcvlYF8pr1 BWDl2JJobG9qpC9DlplpDZOdmsAGu/qwsI0AsucY5ZBFKqzKizQ5PGhrh3u2PHRGNncuHUAN F0cPfVs7AHjHjudH7PzU2wIDAQABo1YwVDBEBgNVHREEPTA7gR9lbnJpY28ubWFyb2Njb0B0 ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0BnbWFpbC5jb20wDAYDVR0TAQH/BAIw ADANBgkqhkiG9w0BAQUFAAOBgQB3Mi6SymgE1cfsbmr5LWvWVdO58/a0O95kXL2puRn9kGjF N1tAzHQc/UxJs0gIyRRs3gGBR+p6TT1gmnucO8Ji0gJBMBL+ogcfyaV30hZtUceiRevemXvZ W2QOCLdYUf6KdB6ccX7r3a58SRRLl5YTZ7bIhyAEmeI60ioyMI8U5jCCAz8wggKooAMCAQIC AQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAm BgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1h aWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQD EyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B 1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79A gAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEa MBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7M DaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk1 3iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIQQgRiaMxkFfdSzVOH+kyMljAJBgUrDgMCGgUAoIIB0DAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA1MjIwODAwMzFaMCMG CSqGSIb3DQEJBDEWBBTw7R1AoUmozq2ps6AnjysoDeLdGDBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBCBGJozGQV91LNU4f6TIyWMIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhBCBGJozGQV91LNU4f6TIyWMA0GCSqGSIb3DQEBAQUABIIBAB3p1tSf0d1j J61YIQr+G5oiAKybdC0Jis3UYfVV9AxDjT6YlKefSBH883EaTPEl+ZgmfEDNzv2Q8bUrmABH A99Z8HR6sHNqkajLW/oqPNFMVbATLrvJn12rv8nCR0GVulMbdqmEvSFocm/cv8NneGSzalGI srTAjr4R+DZuCV919ZA2Lvf+Hw4yYsFvxmU8659qDsTKUhmHN4GUnrFrZLSOLrtc97CY0jSZ wmHiq8K651uSN9JwI3YAfYdWQdRL0DUzvhREIehITzTMZRxj3xLwxZhOSFWthsSet/WgkERV y0mMGCAEdteZf+SAf9vh3L+rcZ043MNSiWfsum0T49kAAAAAAAA= --------------ms080301080508080709070102-- From Berlizova@spiritDSP.com Fri May 22 02:21:27 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACA183A68AA for ; Fri, 22 May 2009 02:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.015 X-Spam-Level: X-Spam-Status: No, score=-2.015 tagged_above=-999 required=5 tests=[AWL=0.583, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UE87kPNXogin for ; Fri, 22 May 2009 02:21:20 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id 1AE0F3A6EB9 for ; Fri, 22 May 2009 02:21:04 -0700 (PDT) Received: from mail-srv.spiritcorp.com (mail-srv.spiritcorp.com [192.168.125.3]) by mail3.spiritcorp.com (8.13.8/8.14.3) with SMTP id n4M9M65t009245; Fri, 22 May 2009 13:22:07 +0400 (MSD) (envelope-from Berlizova@spiritDSP.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9DABE.C36269ED" Date: Fri, 22 May 2009 13:21:59 +0400 Message-ID: In-Reply-To: <010801c9d3ec$a84ed110$f8ec7330$%roni@huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] Comments on draft-ietf-avt-rtp-ipmr-03 Thread-Index: AcnHY9zDr/fCw2IRQrSOnEAtgzkHpwMYdlaQAAl7SgABtJHvsA== References: <010801c9d3ec$a84ed110$f8ec7330$%roni@huawei.com> From: "Elena Berlizova" To: "Roni Even" , X-Scanned-By: MIMEDefang 2.64 on 192.168.125.15 Subject: Re: [AVT] Comments on draft-ietf-avt-rtp-ipmr-03 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 09:21:27 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9DABE.C36269ED Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi=20 The undated version -04 of the Internet draft for Payload format for IP-MR codec has been posted and now it's available at http://tools.ietf.org/html/draft-ietf-avt-rtp-ipmr-04.=20 All the comments have been taken into account.=20 Thank you. =20 Yours sincerely=20 Elena Berlizova=20 ________________________________ From: Roni Even [mailto:Even.roni@huawei.com]=20 Sent: Wednesday, May 13, 2009 9:03 PM To: Elena Berlizova; avt@ietf.org Subject: RE: [AVT] Comments on draft-ietf-avt-rtp-ipmr-03 =20 Hi Elena, I am OK with your responses, on number 2 it will be good to give some explanation in the draft and as for number 6 leave it as is. Please update the draft and I will start WGLC Roni Even =20 From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Elena Berlizova Sent: Wednesday, May 13, 2009 3:46 PM To: avt@ietf.org Subject: Re: [AVT] Comments on draft-ietf-avt-rtp-ipmr-03 =20 Hi, =20 Please find the responses below: =20 =20 1. The draft should have an author name at the top, not just SPIRIT SDP, there is an author name at the end Sergey Ikonin. 2. You describe the payload but it is not clear to me how do you know the size of each speech frame. It may be good to explain it if you can. =20 [Comment] The size of coded speech frame is variable. The Encoder's algorithm decides what size of each frame is and returns it after encoding. In order to save bandwidth the size is not placed into payload obviously. But Decoder can calculate size by the content of coded frame and returns it to the top level application. This way we can get a size of each frame. Moreover there is a special service function that returns frame size without total decoding. Should the explanation be inserted into the draft?=20 =20 3. In section 3 RTP payload format you should start with a section on RTP header usage. See for example RFC 5404. [Comment] will be corrected=20 4. In the security consideration you can use the first two paragraph from RFC 5404 security section. [Comment] will be corrected=20 =20 5. You can add a section on congestion control, this codec can handle congestion so it will be good to mention it. [Comment] will be corrected=20 6. You can add to section 5.2 a subsection on offer answer considerstions =20 [Comment] We believe all needed signaling is already implemented in-band. So there is no special consideration in this section indented. Perhaps it'd be reasonable to add something like this: =20 Offer/Answer Considerations No special considerations should be given for the use of IP-MR within the offer/answer model. =20 =20 Some nits =20 1. In section 2 "This making the bit stream scalable and allows reduce ..." 2. In section 2 " But because of the scalable nature of IP-MR codec there is no need to duplicate the whole previous frame - only the core layer may be retransmitted." 3. In section 3.2 "BR (3 bits): base rate for core layer of frame(s) in this packet using the table for CR. " =20 Yours sincerely=20 Elena Berlizova=20 ________________________________ From: Roni Even [mailto:ron.even.tlv@gmail.com]=20 Sent: Monday, April 27, 2009 10:13 PM To: avt@ietf.org Subject: Comments on draft-ietf-avt-rtp-ipmr-03 =20 Hi,=20 I reviewed the draft and have the following comments most are editorial =20 1. The draft should have an author name at the top, not just SPIRIT SDP, there is an author name at the end Sergey Ikonin. 2. You describe the payload but it is not clear to me how do you know the size of each speech frame. It may be good to explain it if you can. 3. In section 3 RTP payload format you should start with a section on RTP header usage. See for example RFC 5404. 4. In the security consideration you can use the first two paragraph from RFC 5404 security section. 5. You can add a section on congestion control, this codec can handle congestion so it will be good to mention it. 6. You can add to section 5.2 a subsection on offer answer considerstions =20 Some nits =20 1. In section 2 "This making the bit stream scalable and allows reduce ..." 2. In section 2 " But because of the scalable nature of IP-MR codec there is no need to duplicate the whole previous frame - only the core layer may be retransmitted." 3. In section 3.2 "BR (3 bits): base rate for core layer of frame(s) in this packet using the table for CR. " =20 =20 Thanks Roni Even =20 =20 =20 =20 =20 =20 ------_=_NextPart_001_01C9DABE.C36269ED Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi =

The undated = version -04 of the Internet draft for Payload format for IP-MR codec has been posted = and now it’s available at http://too= ls.ietf.org/html/draft-ietf-avt-rtp-ipmr-04.

All the comments = have been taken into account.

Thank = you.

 =

Yours sincerely
Elena = Berlizova

From: Roni Even [mailto:Even.roni@huawei.com]
Sent: Wednesday, May 13, = 2009 9:03 PM
To: Elena Berlizova; = avt@ietf.org
Subject: RE: [AVT] = Comments on draft-ietf-avt-rtp-ipmr-03

 

Hi = Elena,

I am OK with your responses, on = number 2 it will be good to give some explanation in the draft and as for number = 6 leave it as is.

Please update the draft and I = will start WGLC

Roni = Even

 <= /p>

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Elena Berlizova
Sent: Wednesday, May 13, = 2009 3:46 PM
To: avt@ietf.org
Subject: Re: [AVT] = Comments on draft-ietf-avt-rtp-ipmr-03

 

Hi,

 =

Please find the = responses below:

 =

 =

1.  &nb= sp;      The draft should have an author name at the top, not just SPIRIT SDP, = there is an author name at the end Sergey Ikonin.

2.  &nb= sp;      You describe the payload but it is not clear to me how do you know the = size of each speech frame. It may be good to explain it if you = can.

 =

[Comment] The size of coded speech frame is variable. The Encoder's algorithm = decides what size of each frame is and returns it after encoding. In order to = save bandwidth the size is not placed into payload obviously. But Decoder can calculate size by the content of coded frame and returns it to the top = level application. This way we can get a size of each frame. Moreover there is = a special service function that returns frame size without total decoding. = Should the explanation be inserted into the draft? =

 =

3.  &nb= sp;      In section 3 RTP payload format you should start with a section on RTP = header usage. See for example RFC 5404.

[Comment] will be corrected

4.  &nb= sp;      In the security consideration you can use the first two paragraph from = RFC 5404 security section.

[Comment] will be corrected

 =

5.  &nb= sp;      You can add a section on congestion control, this codec can handle = congestion so it will be good to mention it.

[Comment] will be corrected

6.  &nb= sp;      You can add to section 5.2 a subsection on offer answer = considerstions

 

[Comment] We believe all needed signaling is already implemented in-band. So there = is no special consideration in this section = indented.

Perhaps it'd be reasonable to add something like = this:

 

Offer/Answer Considerations

No special considerations should be given for the use of IP-MR within the offer/answer model.

 =

 =

Some = nits

 =

1.  &nb= sp;      In section 2  "This making the bit stream scalable and allows = reduce …"

2.  &nb= sp;      In section 2 " But because of the scalable nature of IP-MR codec = there is no need to duplicate the whole previous frame - only the core layer may = be retransmitted."

3.  &nb= sp;      In section 3.2 "BR (3 bits): base rate for core layer of frame(s) = in this packet using the table for CR. "

 

Yours sincerely
Elena = Berlizova

From: Roni Even [mailto:ron.even.tlv@gmail.com]
Sent: Monday, April 27, = 2009 10:13 PM
To: avt@ietf.org
Subject: Comments on draft-ietf-avt-rtp-ipmr-03

 

Hi,

I reviewed the draft and have the following comments most are = editorial

 

1.      = The draft should have an author name at the top, not just = SPIRIT SDP, there is an author name at the end Sergey = Ikonin.

2.      = You describe the payload but it is not clear to me how do = you know the size of each speech frame. It may be good to explain it if you = can.

3.      = In section 3 RTP payload format you should start with a = section on RTP header usage. See for example RFC 5404.

4.      = In the security consideration you can use the first two = paragraph from RFC 5404 security section.

5.      = You can add a section on congestion control, this codec can = handle congestion so it will be good to mention it.

6.      = You can add to section 5.2 a subsection on offer answer considerstions

 

Some nits

 

1.      = In section 2  "This making the bit stream = scalable and allows reduce …"

2.      = In section 2 " But because of the scalable = nature of IP-MR codec there is no need to duplicate the whole previous = frame - only the core layer may be = retransmitted."

3.      = In section 3.2 "BR (3 bits): base rate for core layer = of frame(s) in this packet using the table for CR. = "

 

 

Thanks

Roni Even

 

 

 

 

 

 

------_=_NextPart_001_01C9DABE.C36269ED-- From Jose.Rey@eu.panasonic.com Fri May 22 07:13:18 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDB563A6AC0 for ; Fri, 22 May 2009 07:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.749 X-Spam-Level: X-Spam-Status: No, score=-0.749 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K+rPI86ZGwiQ for ; Fri, 22 May 2009 07:13:17 -0700 (PDT) Received: from cluster-f.mailcontrol.com (cluster-f.mailcontrol.com [85.115.62.190]) by core3.amsl.com (Postfix) with ESMTP id D9CC83A69C4 for ; Fri, 22 May 2009 07:13:14 -0700 (PDT) Received: from rly41f.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly41f.srv.mailcontrol.com (MailControl) with ESMTP id n4MEESc2017121 for ; Fri, 22 May 2009 15:14:51 +0100 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by rly41f.srv.mailcontrol.com (MailControl) id n4MEDfcj012589 for ; Fri, 22 May 2009 15:13:41 +0100 Received: from eundsmtpout01.pan.eu ([168.87.60.202]) by rly41f-eth0.srv.mailcontrol.com (envelope-sender ) (MIMEDefang) with ESMTP id n4MDha5b032442; Fri, 22 May 2009 15:13:41 +0100 (BST) Received: from eundadmi01.pan.eu ([10.109.33.22]) by eundsmtpout01.pan.eu (Lotus Domino Release 7.0.2) with ESMTP id 2009052216094848-761592 ; Fri, 22 May 2009 16:09:48 +0200 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 7.0.3) with ESMTP id 2009052216094271-241938 ; Fri, 22 May 2009 16:09:42 +0200 Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de; Fri, 22 May 2009 16:08:58 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D54095E153A@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available Thread-Index: AcnaYqqjHO1LimacStOS+9HZ8wJeMAADPRKQABOigeA= References: <81B9B88E2F9D574AA5328A85547CDE9101071D80@xmb-rtp-21d.amer.cisco.com> <49f1a1d6.190c660a.58fe.ffffa90e@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C80DA@xmb-sjc-215.amer.cisco.com> <49f208e8.05a0660a.5bd2.6764@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C81C9@xmb-sjc-215.amer.cisco.com> <49f211fc.07a5660a.3f7f.ffff8f4a@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8202@xmb-sjc-215.amer.cisco.com> <49f2efa2.1c215e0a.4454.ffffaf91@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8403@xmb-sjc-215.amer.cisco.com> <49f36ee2.0437560a.11df.1eef@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8405@xmb-sjc-215.amer.cisco.com> <49f387ca.0305560a.6657.4be7@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C840A@xmb-sjc-215.amer.cisco.com> <4A15D40E.80509@eu.panasonic.com> <04CAD96D4C5A3D48B1919248A8FE0D54095E153A@xmb-sjc-215.amer.cisco.com> To: "Ali C. Begen (abegen)" X-TNEFEvaluated: 1 Message-ID: <1FEB9B9F2EC38343955D02B2AE86AACB011BF41B@lan-ex-02.panasonic.de> Date: Fri, 22 May 2009 16:09:20 +0200 From: "Jose Rey" X-MIMETrack: Itemize by SMTP Server on EUNDADMI01/EUR/Matsushita(Release 7.0.3|September 26, 2007) at 22.05.2009 16:09:46, Serialize by Router on EUNDADMI01/EUR/Matsushita(Release 7.0.3|September 26, 2007) at 22.05.2009 16:09:48, Serialize complete at 22.05.2009 16:09:48, Itemize by SMTP Server on EUNDSMTPOUT01/EUR/PANEXTOUT(Release 7.0.2|September 26, 2006) at 05/22/2009 04:09:48 PM, Serialize by Router on EUNDSMTPOUT01/EUR/PANEXTOUT(Release 7.0.2|September 26, 2006) at 05/22/2009 04:13:40 PM, Serialize complete at 05/22/2009 04:13:40 PM Content-Transfer-Encoding: quoted-printable Content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" X-Scanned-By: MailControl A-06-00-00 (www.mailcontrol.com) on 10.70.1.151 Cc: Roni Even , avt@ietf.org, "Bill Ver Steeg \(versteb\)" Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 14:13:19 -0000 =20 Hi Ali, >=20 > Hi Jose, >=20 > We have separate RTCP ports for the SSM session and the=20 > unicast session. Why is it a problem? In line 19 you say you specify the dst port for RMS-I (41003), on RR. = And you say that would also be the port where the RR sends RMS-T, on RS. = That is mixing the semantics of a=3Drtcp for SSM (listening port at = Feedback Target =3D mcast RTCP dst port) and those of RFC 3605 (dst = port). In other words, you are implicitly assuming that specifies = symmetric RTCP...no? Another thing that was mentioned already: RMS-T is not sent to same = port as RMS-R; is it not the same RTCP session ? Or is this muxing = desired? why? =20 JLR =20 >=20 > The slightly modified SDP for the next version is below: >=20 1> a=3Dgroup:FID 3 4 2> a=3Drtcp-unicast:rsi 3> m=3Dvideo 41000 RTP/AVPF 98 4> i=3DPrimary Multicast Stream #2 5> c=3DIN IP4 233.252.0.2/255 6> a=3Dsource-filter: incl IN IP4 233.252.0.2 192.0.2.2 7> a=3Drecvonly 8> a=3Drtpmap:98 MP2T/90000 9> a=3Drtcp:41001 IN IP4 192.0.2.1 10> a=3Drtcp-fb:98 nack 11> a=3Drtcp-fb:98 nack ssli 12> a=3Dssrc:123321 cname:iptv-ch32@rams.example.com 13> a=3Dmid:3 14> m=3Dvideo 41002 RTP/AVPF 99 15> i=3DUnicast Retransmission Stream #2 (Ret. and Rapid=20 > Acq. Support) 16> c=3DIN IP4 192.0.2.1 17> a=3Drecvonly 18> a=3Drtpmap:99 rtx/90000 19> a=3Drtcp:41003 20> a=3Dfmtp:99 apt=3D98; rtx-time=3D5000 21> a=3Dmid:4 >=20 > This is the SDP we send to RR. For RS, a=3Drecvonly will be = a=3Dsendonly. >=20 > -acbegen >=20 >=20 > > -----Original Message----- > > From: Jos=E9 Rey [mailto:jose.rey@eu.panasonic.com] > > Sent: Thursday, May 21, 2009 3:22 PM > > To: Ali C. Begen (abegen) > > Cc: Roni Even; avt@ietf.org; Bill Ver Steeg (versteb) > > Subject: Re: [AVT] New draft of "Rapid Acquisition of=20 > Multicast RTPSessions (RAMS)" > > available > >=20 > > Hi all, > >=20 > > sorry for jumping in.... > >=20 > > I think one of the sources of confusion is that the=20 > attribute a=3Drtcp:=20 > > is used once for specifying the destination port and once for=20 > > specifying a receiving port, and in the same SDP (!). The=20 > destination=20 > > port for RAMS-I packets sent by RS and the receiving port=20 > for RAMS-T. Which is also why different port numbers are used=20 > for RAMS-T and -R packets. > >=20 > > I think the use of a=3Drtcp: in SSM is the problem here. Or the fact = > > that we are mixing unicast and multicast, or both. > >=20 > > Hope this helps, > >=20 > > JLR > >=20 > >=20 > >=20 > >=20 > > Ali C. Begen (abegen) wrote: > >=20 > >=20 > >=20 > >=20 > >=20 > > -----Original Message----- > > From: Roni Even [mailto:ron.even.tlv@gmail.com] > > Sent: Saturday, April 25, 2009 2:58 PM > > To: Ali C. Begen (abegen); avt@ietf.org > > Cc: Bill Ver Steeg (versteb) > > Subject: RE: [AVT] New draft of "Rapid Acquisition of > > Multicast RTPSessions (RAMS)" available > >=20 > > Ali, > > I looked at RFC 4570 and I assume that port=20 > 41001 is the port for the > > unicast RTCP reports from the receivers and according to > >=20 > >=20 > >=20 > > Yes, indeed. > >=20 > >=20 > >=20 > > section 3.2.1 of > > that RFC you also should have a RTCP-unicast=20 > specification. > > This is for the > > multicast receiver reports. > >=20 > >=20 > >=20 > > Correct. We do have that line in our draft at the top=20 > right after the grouping lines: > >=20 > > a=3Drtcp-unicast:rsi > >=20 > > BR, > > -acbegen > >=20 > >=20 > >=20 > > Roni > >=20 > > -----Original Message----- > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > Sent: Saturday, April 25, 2009 11:30 PM > > To: Roni Even; avt@ietf.org > > Cc: Bill Ver Steeg (versteb) > > Subject: RE: [AVT] New draft of "Rapid Acquisition of > > Multicast RTPSessions > > (RAMS)" available > >=20 > > Here is the SDP. > >=20 > > m=3Dvideo 41000 RTP/AVPF 98 > > i=3DPrimary Multicast Stream #2 > > c=3DIN IP4 224.1.1.2/255 > > a=3Dsource-filter: incl IN IP4 224.1.1.2 192.0.2.2 > >=20 > > Source (192.0.2.2) sends the rtp packets to the=20 > multicast > > group (224.1.1.2) > > with a dest port 41000. > >=20 > > a=3Drtpmap:98 MP2T/90000 > > a=3Drtcp:41001 IN IP4 192.0.2.1 > >=20 > > The feedback target (RS) address for this SSM session is > > 192.0.2.1 and its > > port is 41001. This is the address/port where=20 > RR sends the RAMS-R, or > > receiver reports for the SSM session. > >=20 > > a=3Drtcp-fb:98 nack > > a=3Drtcp-fb:98 nack ssli > > a=3Dssrc:123321 cname:iptv-ch32@rams.example.com > > a=3Dmid:3 > > m=3Dvideo 41002 RTP/AVPF 99 > >=20 > > The retransmission packets go to port 41002.=20 > This is the port > > RRs listen to > > for retransmission and RAMS. > >=20 > > i=3DUnicast Retransmission Stream #2=20 > (Ret. and Rapid > > Acq. Support) > > c=3DIN IP4 192.0.2.1 > >=20 > > This is where the retransmission packets come=20 > from, same as > > the feedback > > target (in this example). > >=20 > > a=3Drtpmap:99 rtx/90000 > > a=3Drtcp:41003 > >=20 > > This is where the RTCP packets for the=20 > retransmission session go. For > > example, RAMS-I goes to this port on RRs.=20 > RAMS-T goes to this > > port on RS. > >=20 > > a=3Dfmtp:99 apt=3D98; rtx-time=3D5000 > > a=3Dmid:4 > >=20 > >=20 > > -acbegen > >=20 > >=20 > >=20 > >=20 > > -----Original Message----- > > From: Roni Even [mailto:ron.even.tlv@gmail.com] > > Sent: Saturday, April 25, 2009 1:11 PM > > To: Ali C. Begen (abegen); avt@ietf.org > > Cc: Bill Ver Steeg (versteb) > > Subject: RE: [AVT] New draft of "Rapid=20 > Acquisition of > > Multicast RTPSessions (RAMS)" available > >=20 > > Ali, > > Can you please write three addresses=20 > from this strange SDP. > >=20 > > 1. The address and port of multicast > >=20 > > 2. The address and port of the RS where=20 > the RTCP FB should go to > >=20 > > 3. The address and port on the RR where=20 > the unicast stream > > should be sent to > >=20 > > Roni > >=20 > > -----Original Message----- > > From: Ali C. Begen (abegen)=20 > [mailto:abegen@cisco.com] > > Sent: Saturday, April 25, 2009 11:02 PM > > To: Roni Even; avt@ietf.org > > Cc: Bill Ver Steeg (versteb) > > Subject: RE: [AVT] New draft of "Rapid=20 > Acquisition of > > Multicast RTPSessions > > (RAMS)" available > >=20 > >=20 > >=20 > > Ali, > > The example SDP is=20 > syntactically correct but it does not > >=20 > >=20 > > say that the > >=20 > >=20 > > rtp/rtcp mux will be used and=20 > it does not give the > > information to where the > > unicast stream will be sent=20 > when the RR sends a RAMS-R. > >=20 > >=20 > > To my knowledge, the first line in the=20 > following SDP tells > > the RRs on which > > port they will receive the=20 > retransmission/burst packets. > >=20 > > m=3Dvideo 41002 RTP/AVPF 99 > > i=3DUnicast Retransmission Stream=20 > #2 (Ret. and Rapid > > Acq. Support) > > c=3DIN IP4 192.0.2.1 > > a=3Drtpmap:99 rtx/90000 > > a=3Drtcp:41003 > > a=3Dfmtp:99 apt=3D98; rtx-time=3D5000 > > a=3Dmid:4 > >=20 > > There is a typo, you are right. That=20 > "a=3Drecvonly" line should > > only exist in > > the SDP sent to RRs. In the SDP sent to=20 > RS, we should rather have > > "a=3Dsendonly". I will make this=20 > correction in the next version. > >=20 > > The feedback target for the SSM session=20 > and the RTCP port for the > > retransmission session are also defined=20 > in the SDP. > >=20 > > Hope this clarifies. > >=20 > > BR, > > -acbegen > >=20 > >=20 > >=20 > > I am not sure why the unicast=20 > stream m-line has a port > >=20 > >=20 > > number with an > >=20 > >=20 > > attribute of recvonly. What is=20 > the use case for that. The > > only information > > that the RR will need is the=20 > RTCP port on the RS to where to > > send the RAMS-R > > message. > > Roni > > -----Original Message----- > > From: Ali C. Begen (abegen)=20 > [mailto:abegen@cisco.com] > > Sent: Friday, April 24, 2009 10:37 PM > > To: Roni Even; avt@ietf.org > > Cc: Bill Ver Steeg (versteb) > > Subject: RE: [AVT] New draft of=20 > "Rapid Acquisition of > > Multicast RTPSessions > > (RAMS)" available > >=20 > > This is a part of an example=20 > SDP sent to RS and RR in a SAP > > announcement, > > for example. So, the SDP=20 > describes what both parties should > > do (RR cannot > > say that he wants to receive=20 > this multicast on its favorite > >=20 > >=20 > > port). The > >=20 > >=20 > > individual SDPs sent to RR or=20 > RS may include other portions > > of descriptions > > that will contain specific information. > >=20 > > -acbegen > >=20 > >=20 > >=20 > > -----Original Message----- > > From: Roni Even=20 > [mailto:ron.even.tlv@gmail.com] > > Sent: Friday, April 24,=20 > 2009 12:23 PM > > To: Ali C. Begen=20 > (abegen); avt@ietf.org > > Cc: Bill Ver Steeg (versteb) > > Subject: RE: [AVT] New=20 > draft of "Rapid Acquisition of > > Multicast RTPSessions=20 > (RAMS)" available > >=20 > > Ali, > > I think you get it=20 > wrong, this SDP is from the RS and not the > > RR so the RS > > cannot specify to which=20 > address it will send it can only > > specify to which > > address it can receive=20 > RTP stream. In this SDP the relevant > > information is > > that the request for=20 > retransmission will be sent by the RR to > > port 41003 > > Roni > >=20 > > -----Original Message----- > > From: Ali C. Begen=20 > (abegen) [mailto:abegen@cisco.com] > > Sent: Friday, April 24,=20 > 2009 10:01 PM > > To: Roni Even; avt@ietf.org > > Cc: Bill Ver Steeg (versteb) > > Subject: RE: [AVT] New=20 > draft of "Rapid Acquisition of > > Multicast RTPSessions > > (RAMS)" available > >=20 > > Oh, I see. The burst=20 > goes to the port that we would > >=20 > >=20 > > normally send the > >=20 > >=20 > > retransmissions. For=20 > example, consider the SDP from the draft: > >=20 > > m=3Dvideo 41000=20 > RTP/AVPF 98 > > i=3DPrimary=20 > Multicast Stream #2 > > c=3DIN IP4 224.1.1.2/255 > > =20 > a=3Dsource-filter: incl IN IP4 224.1.1.2 192.0.2.2 > > a=3Drtpmap:98 MP2T/90000 > > a=3Drtcp:41001 IN=20 > IP4 192.0.2.1 > > a=3Drtcp-fb:98 nack > > a=3Drtcp-fb:98 nack ssli > > a=3Dssrc:123321=20 > cname:iptv-ch32@rams.example.com > > a=3Dmid:3 > > m=3Dvideo 41002=20 > RTP/AVPF 99 > > i=3DUnicast=20 > Retransmission Stream #2 (Ret. and Rapid > > Acq. Support) > > c=3DIN IP4 192.0.2.1 > > a=3Drecvonly > > a=3Drtpmap:99 rtx/90000 > > a=3Drtcp:41003 > > a=3Dfmtp:99=20 > apt=3D98; rtx-time=3D5000 > > a=3Dmid:4 > >=20 > > In this case, the burst=20 > will go to port 41002 on the RR. > >=20 > >=20 > > The RAMS-I > >=20 > >=20 > > message(s), which is an=20 > RTCP feedback message, will go to > >=20 > >=20 > > port 41003. > >=20 > >=20 > > HTH, > > -acbegen > >=20 > >=20 > >=20 > > -----Original=20 > Message----- > > From: Roni Even=20 > [mailto:ron.even.tlv@gmail.com] > > Sent: Friday,=20 > April 24, 2009 11:44 AM > > To: Ali C.=20 > Begen (abegen); avt@ietf.org > > Cc: Bill Ver=20 > Steeg (versteb) > > Subject: RE:=20 > [AVT] New draft of "Rapid Acquisition of > > Multicast=20 > RTPSessions (RAMS)" available > >=20 > > Ali, > > I will try to=20 > explain in simple way > >=20 > > When the RS=20 > receives the RAMS-R it need to start sending an > > RTP stream to > > the RR. > > In order to=20 > send a unicast packet, the RS needs to know a > > transport address > > on the RR to=20 > where the RTP stream will be sent. The current > > draft does not > > say how the RS=20 > knows this address. There is no SDP from RR to > > RS like you > > mention in your=20 > response. > > This is why I=20 > say that the current draft does not specify a > > solution that > > can be=20 > implemented as a working solution > > Roni > >=20 > > -----Original=20 > Message----- > > From: Ali C.=20 > Begen (abegen) [mailto:abegen@cisco.com] > > Sent: Friday,=20 > April 24, 2009 7:38 PM > > To: Roni Even;=20 > avt@ietf.org > > Cc: Bill Ver=20 > Steeg (versteb) > > Subject: RE:=20 > [AVT] New draft of "Rapid Acquisition of > > Multicast RTPSessions > > (RAMS)" available > >=20 > > Hi Roni, > >=20 > >=20 > >=20 > > =09 > -----Original Message----- > > From:=20 > avt-bounces@ietf.org [mailto:avt- bounces@ietf.org] On > > Behalf=20 > Of Roni Even > > Sent:=20 > Friday, April 24, 2009 4:24 AM > > To: avt@ietf.org > > Cc:=20 > Bill Ver Steeg (versteb) > > =09 > Subject: Re: [AVT] New draft of "Rapid Acquisition of > > =09 > Multicast RTPSessions (RAMS)" available > >=20 > > Hi, > >=20 > > I think=20 > that the current draft does not give a > >=20 > >=20 > > description of > >=20 > >=20 > > a=20 > system that works since there is no text > >=20 > >=20 > > explaining how the > >=20 > >=20 > > What do you=20 > mean by "a system that works"? > >=20 > >=20 > >=20 > > RS=20 > knows the unicast transport address on the RR to > >=20 > >=20 > > where to > >=20 > >=20 > > send the stream. > >=20 > >=20 > > Once RS=20 > receives the request packet from an RR, RS knows its > > address. Ports > > are defined in=20 > the SDP. If you are asking about "NAT" > > issues, > > we have a > > section for it,=20 > and we plan to complete it as we move > > forward. It is not as > > critical as the=20 > other parts for now. > >=20 > >=20 > >=20 > > If you=20 > mandate the use of RTP/RTCP mux it should say so > > =09 > otherwise the RAMS-R should have an optional parameter that > > =09 > supplies this information and a flag for using RTP/RTCP mux. > >=20 > >=20 > > IMO, we cannot=20 > mandate muxing as it is not required to make > > RAMS work. If > > muxing is=20 > supported, the SDP should reflect it. > >=20 > > BR, > > -acbegen > >=20 > >=20 > >=20 > > Thanks > >=20 > > Roni Even > >=20 > >=20 > >=20 > > From:=20 > avt-bounces@ietf.org [mailto:avt- bounces@ietf.org] On > > Behalf=20 > Of Bill Ver Steeg (versteb) > > Sent:=20 > Thursday, April 16, 2009 7:39 PM > > To: avt@ietf.org > > =09 > Subject: [AVT] New draft of "Rapid Acquisition of Multicast > > RTP=20 > Sessions (RAMS)" available > >=20 > >=20 > >=20 > > There=20 > is a new draft of the "Rapid Acquisition of Multicast > > RTP=20 > Sessions (RAMS)" draft available at > >=20 > >=20 > >=20 > > =09 > http://www.ietf.org/internet-drafts/draft-versteeg-avt-rapid-s > >=20 > >=20 > > =09 > ynchronization-for-rtp-03.txt > > > >=20 > >=20 > >=20 > > =09 > drafts/draft-versteeg-avt-rapid-synchronization-for-rtp-03.txt> > >=20 > >=20 > >=20 > >=20 > > We have=20 > incorporated the changes from the technical > >=20 > >=20 > > breakout > >=20 > >=20 > > session=20 > in San Francisco. The major changes in this version > > of the=20 > draft include > >=20 > > 1-=20 > Changing the document title to avoid confusion > >=20 > >=20 > > with other > >=20 > >=20 > > ongoing=20 > "synchronization" drafts > >=20 > > 2-=20 > changing the message names to reflect the title change > >=20 > > 3-=20 > clarification of the RTCP message semantics, including > > changes=20 > to the "Request" and "Inform" messages > >=20 > > 4-=20 > additional description/motivation for the > >=20 > >=20 > > various message > >=20 > >=20 > > flows=20 > has been added > >=20 > > 5-=20 > RTP/RTCP muxing has been added > >=20 > >=20 > >=20 > >=20 > >=20 > > We hope=20 > to make this a Working Group item, and will change > > the=20 > name of the draft to avoid conflicts with other > > =09 > "synchronization" drafts at that time. > >=20 > >=20 > >=20 > > Bill VerSteeg > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > >=20 > >=20 >=20 >=20 >=20 Panasonic R=26D Center Germany GmbH 63225 Langen=2C Hessen=2C Germany Reg=3A AG Offenbach =28Hessen=29 HRB 33974 Managing Director=3A Thomas Micke From alex.giladi@gmail.com Fri May 22 07:38:28 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1757D3A6C6E for ; Fri, 22 May 2009 07:38:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.307 X-Spam-Level: X-Spam-Status: No, score=-2.307 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVsDnBhz3xHZ for ; Fri, 22 May 2009 07:38:27 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id DCC543A6B4E for ; Fri, 22 May 2009 07:38:26 -0700 (PDT) Received: by fxm2 with SMTP id 2so1699917fxm.37 for ; Fri, 22 May 2009 07:40:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=7nieW80ZB7d+rfhFEunWZhtkl1y5rpmYUwT8px5Bspo=; b=BKV3aa+1Sy0E4KJkJvcCShysiHEg9LMw4BlWzB5xmy/dK+kOqGbF5sVkY9ayMiwg8e DxAF/wHH/HSPh/vjs3PJzFWiKFmAvr/Vk5SR/8gZf37zdC/vReJkkN4IPLp8+MmzmUeb Dl38UM1XNlrTNDm4JbVEE+0Am7ECc0sjlripw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=oeDGGaJz9ymEJGox8lJtqXVM81wMI4u+Rf0W+V+AeuLjrHT/S187jJBpfZXmN07kTX O97vg18lDR0SBflmI1+TaVQOvYCk+vN4jjJV5s0SwHUWAtfi0n0QDK+u6ZUFHdLuoKOk B4OCWuiBg5IKwmV1XnLWYm/yHrVZhG7wY28rA= MIME-Version: 1.0 Received: by 10.204.71.15 with SMTP id f15mr3691130bkj.42.1243003202407; Fri, 22 May 2009 07:40:02 -0700 (PDT) In-Reply-To: <4835AFD53A246A40A3B8DA85D658C4BE7B1032@EVS-EC1-NODE4.surrey.ac.uk> References: <302f570905211446j7317a6f8o3d1e6a0b405a3568@mail.gmail.com> <4835AFD53A246A40A3B8DA85D658C4BE7B1032@EVS-EC1-NODE4.surrey.ac.uk> Date: Fri, 22 May 2009 08:40:01 -0600 Message-ID: <57a9e15d0905220740y11153968lac5b3660e4e525ea@mail.gmail.com> From: Alex Giladi To: avt@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: ".Wood"@surrey.ac.uk Subject: Re: [AVT] Comments on draft-pantos-http-live-streaming-00.txt ... X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 14:38:28 -0000 On Fri, May 22, 2009 at 12:12 AM, wrote: > http://tools.ietf.org/id/draft-pantos-http-live-streaming-00.txt > ... > =C2=A0=C2=A0 Each media file URI MUST be preceded by an > =C2=A0=C2=A0 EXTINF tag.=C2=A0 Its format is: > > =C2=A0=C2=A0 #EXTINF:, > > =C2=A0=C2=A0 "duration" is an integer that specifies the duration of the = media > =C2=A0=C2=A0 file in seconds. > > So it's necessary to know how long a file is before specifying it. > The draft is not really dealing with an unbounded stream of data, > more bringing together separate known resources seamlessly. My $0.02: * If you break the incoming stream into smaller files, and announce then as they become available, the approach is OK. * Though integer amount of seconds is a *bad* thing to do (since framewise you will be off by up to 60 frames), a normal npt or SMPTE timestamp would do better. Otherwise you require the encoder to produce chunks. Perfectly rounded to a second. Anyway, given 29.97fps framerate and 3-sec files, you'll be off by 1.8 minutes after an hour... --ag From yekuiwang@huawei.com Fri May 22 07:56:47 2009 Return-Path: <yekuiwang@huawei.com> X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F272628C0EF for <avt@core3.amsl.com>; Fri, 22 May 2009 07:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.319 X-Spam-Level: X-Spam-Status: No, score=-2.319 tagged_above=-999 required=5 tests=[AWL=0.280, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v74EOeSuZnWZ for <avt@core3.amsl.com>; Fri, 22 May 2009 07:56:45 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 4B9633A6EC7 for <avt@ietf.org>; Fri, 22 May 2009 07:56:16 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KK100L9GW8FMW@usaga02-in.huawei.com> for avt@ietf.org; Fri, 22 May 2009 07:57:52 -0700 (PDT) Received: from W90946 ([10.193.125.102]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KK100IUZW8AU8@usaga02-in.huawei.com> for avt@ietf.org; Fri, 22 May 2009 07:57:51 -0700 (PDT) Date: Fri, 22 May 2009 10:57:46 -0400 From: Ye-Kui Wang <yekuiwang@huawei.com> In-reply-to: <ybuhbzdygly.fsf@jesup.eng.wgate.com> To: 'Randell Jesup' <rjesup@wgate.com> Message-id: <939A5D7EEE0A410E867078A3117DD3CE@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acnai2n4fl7NmuX9TF2KPnHRrQJu7gAXoQvg References: <4A15046C.5080600@rogers.com> <006701c9d9e9$51679500$f436bf00$%roni@huawei.com> <7779AD69A5E54F9F84E473BB4F4E1E71@china.huawei.com> <4A157ADA.8060900@rogers.com> <ybuljopyjto.fsf@jesup.eng.wgate.com> <3221EC0396044781B11D483B77E085A1@china.huawei.com> <ybuhbzdygly.fsf@jesup.eng.wgate.com> Cc: 'Tom Taylor' <tom.taylor@rogers.com>, 'IETF AVT WG' <avt@ietf.org> Subject: Re: [AVT] Consensus on profile-level-id in 3984bis X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group <avt.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/avt> List-Post: <mailto:avt@ietf.org> List-Help: <mailto:avt-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 22 May 2009 14:56:47 -0000 > -----Original Message----- > From: Randell Jesup [mailto:rjesup@wgate.com] > Sent: Thursday, May 21, 2009 11:14 PM > To: Ye-Kui Wang > Cc: 'Tom Taylor'; 'IETF AVT WG' > Subject: Re: [AVT] Consensus on profile-level-id in 3984bis > > Ye-Kui Wang <yekuiwang@huawei.com> writes: > >If the following are considered, then let the other side know the > >sending capability (as well as whether level upgrade is > allowed) would > >be very useful. > > > >- One may want to request a specific mode, e.g. a spatial > resolution, > >from the sender, for example by using image attribute mmusic draft. > > Does adding a max-send-level actually help you there? Yes. > How does this interact with how you decide what your max sending > level is? You don't decide your max sending level, your max sending level is your max sending capability, a hard capability limit of you. > As mentioned below, choosing a value for that > (other than basing it on resolution alone, and that just > might put a lower bound on it) is extremely subjective at best. > Example: If one side lets the other side know its max sending capability, then the other side would not even try to request a specific capability that is impossible to be satisfied. Otherwise, the other side may just send useless requests. > >- Video adaptation, in terms of bitrate, frame rate, and/or spatial > >resolution etc, may happen during the session, and may be > initiated by > >either side. > > Again, how would this work in practice, and how would adding > it here help? > Adaptation within the negotiated limits can occur now, so I > don't see the advantage here. If you need to change the > maximum limits (why? weren't they properly negotiated to > start with?), then you can re-invite. I think we need a > concrete example, in order to know if what you're proposing > is sufficient - or if it works. I'm quite unclear on how you > believe specifying a max send level will help anything, since > your list is quite vague. > Example The offerer does not tell the answerer its max sending capability, which is level B. A negotiation is done, where the answer includes level C (C>B), and the offerer starts to send at C (actually B, but the answerer may not be sure). After a while, the answerer senses that the connecting bandwidth is higher, and it wants to receive at a higher bitrate, which is still within the limit of level C, but above the limit of B, and sends a meaningless adaption request using re-invite. However, if the offerer does tell the answerer its max sending capability, such meaningless adaption requests are avoided. I believe there are more examples, but I hope this already helps. BR, YK > >BR, YK > > > >> -----Original Message----- > >> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] > On Behalf Of > >> Randell Jesup > >> Sent: Thursday, May 21, 2009 10:04 PM > >> To: Tom Taylor > >> Cc: IETF AVT WG > >> Subject: Re: [AVT] Consensus on profile-level-id in 3984bis > >> > >> Tom Taylor <tom.taylor@rogers.com> writes: > >> >It appears that the optimum outcome is to be able to signal > >> both send > >> >and receive capability. The legacy approach loses some of this > >> >information, since profile-level-id contains the lesser > of the two > >> >values. In a legacy-new interworking situation it seems > >> unlikely that > >> >we can improve on this. > >> > >> Well, I'm not sure you can say that a legacy device > definitively uses > >> the lesser of send/receive in profile-level-id. Because > of the way > >> profile-level-id works, and how H.264 encodes streams, there is no > >> problem with currently specifying a level above what you > can "truly" > >> support *sending*. I.e. you can say you can receive and > send level > >> 3.0 via profile-level-id, but nothing forces you to use the full > >> limits of level 3.0 when sending. You can send a stream > that could > >> be encoded identically in level 2.0; you can even mark it as level > >> 3.0 in the SPS/PPS NAL units. > >> > >> On the other side of the equation, it is the lesser - if > you can only > >> receive level 2.0 when all the limits in the received stream are > >> maxed out, you can't use anything above level 2.0 in > >> profile-level-id. (You can > >> *extend* it (such as with max-fs), if you also agree to decode the > >> extension as well.) > >> > >> Those are the *current* semantics of profile-level-id. A legacy > >> device may (or may not) as mentioned over-state it's ability to > >> encode. > >> > >> You could use an parameter that specifies the max sending level > >> supported in an offer (there's no point in an answer I > believe). I > >> originally proposed this. However, on reflection, there's very > >> little if anything to gain from that that I can see. A receiver > >> could respond to > >> level-upgrade-allowed=1 (or level-asymmetry-allowed=1) with the > >> highest level it can receive. Now each side knows the > highest level > >> the other can receive, and can send up to that level. The only > >> downside I can possibly think of to not knowing the > maximum sending > >> ability is that a receiver could perhaps not allocate as many > >> resources if it knew the offerer couldn't send above level N. > >> Example: > >> > >> A: Can receive level 2.0 (small LCD perhaps), can send level 3.0 > >> B: Can receive level 5.0, can send level 3.0 (more common form of > >> send/recv > >> asymmetry) > >> > >> A offers to be with > profile-level-id=420014;level-asymmetry-allowed=1 > >> B answers with profile-level-id=420032 > >> > >> A will send at level 3.0 > >> B will send at level 2.0 (and must allocate resources to > potentially > >> receive 5.0) > >> > >> If you had a maximum-send-level parameter: > >> > >> A offers to be with profile-level-id=420014;sprop-max-level=1E > >> B answers with profile-level-id=42001E > >> > >> A will send at level 3.0 > >> B will send at level 2.0 (and only has to allocate resources for > >> level 3.0) > >> > >> > >> The question is "is it worth it"? Also, while this may > let you limit > >> resources, you may also limit the options of the sender. For > >> example, in the first case above, since A knows B can > receive 5.0, A > >> could send a higher frame size than 3.0 supports (perhaps > at a lower > >> framerate), even though A can't support sending "full" level 3.1. > >> > >> I should also note that quantizing the maximum level you > can send is > >> VERY subjective/arbitrary, because of how the encoding works. See > >> the discussion above about how you don't have to max out the level > >> you're supposedly sending. > >> > >> So my suggestion is to use level-asymmetry-allowed. (See > my previous > >> post for how this differs from level-upgrade-allowed > >> - it allows asymmetric levels on level downgrade as well, which is > >> actually probably a more common > >> case.) > >> > >> >That suggests that profile-level-id should retain its current > >> >semantics, and one or two new parameters (only one of > which would be > >> >present in the offer or answer) would indicate two things: > >> >a) a value which is higher than the value given in > profile-level-id; > >> >b) whether that value is a send or receive capability. > >> > > >> >If it's just one parameter, it would have to be double > valued e.g., > >> >alternate-level-id="send,<value>". > >> > > >> >If it is two parameters, the appropriate parameter to > include would > >> >depend on which whether the capability being reported is send or > >> >receive, e.g., send-level-id=<value> > >> >or recv-level-id=<value > >> >but never both in the same stream. > >> > > >> >Ye-Kui Wang wrote: > >> >> Another interoperability issue relates to the semantics > >> change of the > >> >> level part of profile-level-id. Currently, the level part, > >> when used > >> >> capability exchange or session setup, gives the upper > >> limit of both > >> >> decoding capability and encoding capability, as seen from the > >> >> following two paragraphs excerpted from the bis draft (the > >> same in spirit in 3984): > >> >> > >> >> "The profile-level-id parameter indicates the default > sub-profile, > >> >> i.e. the subset of coding tools that may have been used to > >> generate > >> >> the stream or that the receiver supports, and the > default level of > >> >> the stream or the receiver supports." > >> >> > >> >> "If the profile-level-id parameter is used for capability > >> exchange or > >> >> session setup procedure, it indicates the subset of > coding tools, > >> >> which is equal to the default sub-profile, and the > highest level, > >> >> which is equal to the default level, that the codec > supports. All > >> >> levels lower than the default level are also supported by > >> the codec. " > >> >> > >> >> When level upgrade is allowed, then this semantics must > >> change, such > >> >> that the level part basically indicates only the decoding > >> capability. > >> >> This change of course creates different understandings > between the > >> >> two sides whenever one is legacy and the other is new. > >> >> > >> >> We have at least the following options to go to allow for level > >> >> upgrade (the semantics change above is anyway needed): - To add > >> >> "level-upgrade-allowed". - To add "level-upgrade-allowed" > >> and another > >> >> parameter, say sending-capability-level, to indicate > the sending > >> >> capability expressed as a level value. - To go wildly, by > >> making all > >> >> paramters not starting with "sprop-" as receiving capabilities. > >> >> Another group of parameters not starting with "sprop-" can be > >> >> optionally used to indicate sending capabilities. When > >> these sending > >> >> capability parameters are not present, the sending > >> capabilities are > >> >> by default equal to the receiving capabilties. > >> >> > >> >> A decision needs to be made which one to take. > >> >> > >> >> In any case, I hope a proponent could provide relatively > >> mature text, > >> >> including changes to semantics, offer/answer rules (including > >> >> parameter sets considerations in offer/answer), > declarative usage, > >> >> SDP examples, and discussion of backward compatibility issues. > >> >> > >> >> Note that all the changes will also affect the SVC payload > >> draft, as > >> >> they basically need to be appropriately integrated to the > >> SVC payload draft. > >> >> > >> >> BR, YK > >> >> > >> >... > >> >_______________________________________________ > >> >Audio/Video Transport Working Group > >> >avt@ietf.org > >> >https://www.ietf.org/mailman/listinfo/avt > >> > >> > >> -- > >> Randell Jesup, Worldgate (developers of the Ojo > videophone), ex-Amiga > >> OS team rjesup@wgate.com "The fetters imposed on liberty > at home have > >> ever been forged out of the weapons provided for defence against > >> real, pretended, or imaginary dangers from abroad." > >> - James Madison, 4th US president (1751-1836) > >> > >> _______________________________________________ > >> Audio/Video Transport Working Group > >> avt@ietf.org > >> https://www.ietf.org/mailman/listinfo/avt > >> > > > -- > Randell Jesup, Worldgate (developers of the Ojo videophone), > ex-Amiga OS team rjesup@wgate.com "The fetters imposed on > liberty at home have ever been forged out of the weapons > provided for defence against real, pretended, or imaginary > dangers from abroad." > - James Madison, 4th US president (1751-1836) > > From alex.giladi@gmail.com Fri May 22 08:01:25 2009 Return-Path: <alex.giladi@gmail.com> X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17D313A6BCF for <avt@core3.amsl.com>; Fri, 22 May 2009 08:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.343 X-Spam-Level: X-Spam-Status: No, score=-2.343 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yLsUPWkoXCht for <avt@core3.amsl.com>; Fri, 22 May 2009 08:01:24 -0700 (PDT) Received: from mail-ew0-f176.google.com (mail-ew0-f176.google.com [209.85.219.176]) by core3.amsl.com (Postfix) with ESMTP id 787C43A69A4 for <avt@ietf.org>; Fri, 22 May 2009 08:00:43 -0700 (PDT) Received: by ewy24 with SMTP id 24so1890120ewy.37 for <avt@ietf.org>; Fri, 22 May 2009 08:02:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=euI/B1rRUi7oa0i9VX97OPtQq0KoFEp0tKYx95n6cN0=; b=ayHuBi3S2ixufN8e2QvScQJkTSLmhfhttxq+pp3XxuI7/qP7JYFEm8VcmluaIRKufH XOZwYYpBgAWYE7qecksXM8c/izKi5QfQgzth2/5PnM94uSG0MBitMT0srtDi0Bb739CA ZTuD8WgCHgwofRMDEpufAUIRHVuCdy/iVTI/8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=BFTeDuav3Zm3bWKEA8KuzmfakmVBPXPmNZg0A47TWbq8o77E5ysYFctuVBzGofI0P/ 2NXjZ49MB1cFlkqA3RAhtysQaU7NwRquC+VqjpqW8aApHcwZA/K9kjiyXauiXYIZobpH +DVKgXfGPE3fOmFbmrP+4sYkqkSyMdt8R/3UY= MIME-Version: 1.0 Received: by 10.216.19.141 with SMTP id n13mr823354wen.47.1243004538467; Fri, 22 May 2009 08:02:18 -0700 (PDT) In-Reply-To: <302f570905211446j7317a6f8o3d1e6a0b405a3568@mail.gmail.com> References: <302f570905211446j7317a6f8o3d1e6a0b405a3568@mail.gmail.com> Date: Fri, 22 May 2009 09:02:18 -0600 Message-ID: <57a9e15d0905220802w58440755m9f9f45856a0dd3bc@mail.gmail.com> From: Alex Giladi <alex.giladi@gmail.com> To: John Lazzaro <john.lazzaro@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: avt@ietf.org Subject: Re: [AVT] Comments on draft-pantos-http-live-streaming-00.txt ... X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group <avt.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/avt> List-Post: <mailto:avt@ietf.org> List-Help: <mailto:avt-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 22 May 2009 15:01:25 -0000 I think having some standardized way of streaming through HTTP is something that actually may be needed on its own. In many contexts you have to resort to a similar approach in some hacky way. We know that people do this, why not have an interoperable / standardized way of doing this? On Thu, May 21, 2009 at 3:46 PM, John Lazzaro <john.lazzaro@gmail.com> wrot= e: > Hi everyone, > > Comments on draft-pantos-http-live-streaming-00.txt below. > > What jumped out at me was that this is a late-1990s > approach to a problem ... but its almost 2010 ... > > In my view, the I-D is trying to do for audio what the AJAX client code > for Google Maps does for image map tiles. Namely, pre-loading short > media files over HTTP, to drive a user interface that the user > perceives as continuous (and in the Google Maps case, > responsive to user input). > > I haven't looked at HTML5 (yet), but I was under the impression > one goal of its audio/video features is to provide the > primitives to make it possible to implement the protocol > described in draft-pantos-http-live-streaming-00.txt using > AJAX techniques. =C2=A0If the feature set isn't there yet in HTML5 > to do that, I think the time spent working on this I-D is better > spent working within the HTML5 process to get the features that > are needed. =C2=A0It seems to me that AJAX is a more natural way to > implement this sort of "concatenation of pre-downloaded 10-second > files" streaming. > > If there is AVT consensus that draft-pantos-http-live-streaming-00.txt's > general approach is acceptable for a work-item, I'll do a second review > of potential technical issues with the protocol itself ... > > -- > John Lazzaro > http://www.cs.berkeley.edu/~lazzaro > john [dot] lazzaro [at] gmail [dot] com > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > From rjesup@wgate.com Fri May 22 08:20:04 2009 Return-Path: <rjesup@wgate.com> X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFDA73A6E14 for <avt@core3.amsl.com>; Fri, 22 May 2009 08:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.588 X-Spam-Level: X-Spam-Status: No, score=-1.588 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qI-eriW2JVN1 for <avt@core3.amsl.com>; Fri, 22 May 2009 08:20:03 -0700 (PDT) Received: from exchange1.wgate.com (pr-66-150-46-254.wgate.com [66.150.46.254]) by core3.amsl.com (Postfix) with ESMTP id EBE383A6CBA for <avt@ietf.org>; Fri, 22 May 2009 08:20:02 -0700 (PDT) Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 May 2009 11:21:25 -0400 To: Ye-Kui Wang <yekuiwang@huawei.com> References: <4A15046C.5080600@rogers.com> <006701c9d9e9$51679500$f436bf00$%roni@huawei.com> <7779AD69A5E54F9F84E473BB4F4E1E71@china.huawei.com> <4A157ADA.8060900@rogers.com> <ybuljopyjto.fsf@jesup.eng.wgate.com> <3221EC0396044781B11D483B77E085A1@china.huawei.com> <ybuhbzdygly.fsf@jesup.eng.wgate.com> <939A5D7EEE0A410E867078A3117DD3CE@china.huawei.com> From: Randell Jesup <rjesup@wgate.com> Date: Fri, 22 May 2009 11:21:36 -0400 In-Reply-To: <939A5D7EEE0A410E867078A3117DD3CE@china.huawei.com> (Ye-Kui Wang's message of "Fri\, 22 May 2009 10\:57\:46 -0400") Message-ID: <ybuhbzdb1tr.fsf@jesup.eng.wgate.com> User-Agent: Gnus/5.101 (Gnus v5.10.10) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 22 May 2009 15:21:25.0719 (UTC) FILETIME=[F8C13E70:01C9DAF0] Cc: 'Tom Taylor' <tom.taylor@rogers.com>, 'IETF AVT WG' <avt@ietf.org> Subject: Re: [AVT] Consensus on profile-level-id in 3984bis X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Randell Jesup <rjesup@wgate.com> List-Id: Audio/Video Transport Working Group <avt.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/avt> List-Post: <mailto:avt@ietf.org> List-Help: <mailto:avt-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 22 May 2009 15:20:05 -0000 Ye-Kui Wang <yekuiwang@huawei.com> writes: >> Ye-Kui Wang <yekuiwang@huawei.com> writes: >> >If the following are considered, then let the other side know the >> >sending capability (as well as whether level upgrade is allowed) would >> >be very useful. >> > >> >- One may want to request a specific mode, e.g. a spatial >> >resolution, from the sender, for example by using image attribute >> >mmusic draft. >> >> Does adding a max-send-level actually help you there? > >Yes. > >> How does this interact with how you decide what your max sending >> level is? > >You don't decide your max sending level, your max sending level is your max >sending capability, a hard capability limit of you. Max capability for what/which? For all parameters simultaneously? Maximum bitrate at maximum framesize at maximum macroblocks/second, with maximum frame-to-frame motion, with maximum motion-estimation-search, etc? I'm not saying you can't choose a maximum, but it's very, very soft - very subjective because encoding is much more variable (and expensive) than decoding. It's (much) easier to estimate a worst-case for decode. >> As mentioned below, choosing a value for that (other than basing it on >> resolution alone, and that just might put a lower bound on it) is >> extremely subjective at best. > >Example: If one side lets the other side know its max sending capability, >then the other side would not even try to request a specific capability that >is impossible to be satisfied. Otherwise, the other side may just send >useless requests. > >> >- Video adaptation, in terms of bitrate, frame rate, and/or spatial >> >resolution etc, may happen during the session, and may be initiated by >> >either side. >> >> Again, how would this work in practice, and how would adding it here >> help? Adaptation within the negotiated limits can occur now, so I don't >> see the advantage here. If you need to change the maximum limits (why? >> weren't they properly negotiated to start with?), then you can >> re-invite. I think we need a concrete example, in order to know if what >> you're proposing is sufficient - or if it works. I'm quite unclear on >> how you believe specifying a max send level will help anything, since >> your list is quite vague. >> > >Example > >The offerer does not tell the answerer its max sending capability, which is >level B. A negotiation is done, where the answer includes level C (C>B), and >the offerer starts to send at C (actually B, but the answerer may not be >sure). After a while, the answerer senses that the connecting bandwidth is >higher, and it wants to receive at a higher bitrate, which is still within >the limit of level C, but above the limit of B, and sends a meaningless >adaption request using re-invite. > >However, if the offerer does tell the answerer its max sending capability, >such meaningless adaption requests are avoided. I believe there are more >examples, but I hope this already helps. That's a plausible case - thanks. However, I think you could have an unintended result if you did that. Lets say that the offerer uses the "worst-case" method to decide on a max-send-level (per above). That level may be well below the limits it could hit when it's not worst case - for example, it may be constrained on framesize or MBPS to level 3.0, but can handle the outgoing bandwidth of level 4.0, and level 5.0 when other parameters aren't worst-case. By limiting to a max-send-level of 3.0, the receiver won't request use of extra bandwidth or 4.0 or 5.0. Note that even if you go and duplicate all the max-* parameters as sprop-max-*, you still wouldn't be able to handle the "I can do this when other parameters are relaxed" case. I also already mentioned this problem below (repeated here): >> >> The question is "is it worth it"? Also, while this may let you limit >> >> resources, you may also limit the options of the sender. For >> >> example, in the first case above, since A knows B can receive 5.0, A >> >> could send a higher frame size than 3.0 supports (perhaps at a lower >> >> framerate), even though A can't support sending "full" level 3.1. I think you can handle the adaptation issue as part of the adaptation design, since there may be other reasons the offerer can't raise the bandwidth (or whatever). >BR, YK > > >> >BR, YK >> > >> >> -----Original Message----- >> >> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] >> On Behalf Of >> >> Randell Jesup >> >> Sent: Thursday, May 21, 2009 10:04 PM >> >> To: Tom Taylor >> >> Cc: IETF AVT WG >> >> Subject: Re: [AVT] Consensus on profile-level-id in 3984bis >> >> >> >> Tom Taylor <tom.taylor@rogers.com> writes: >> >> >It appears that the optimum outcome is to be able to signal >> >> both send >> >> >and receive capability. The legacy approach loses some of this >> >> >information, since profile-level-id contains the lesser >> of the two >> >> >values. In a legacy-new interworking situation it seems >> >> unlikely that >> >> >we can improve on this. >> >> >> >> Well, I'm not sure you can say that a legacy device >> definitively uses >> >> the lesser of send/receive in profile-level-id. Because >> of the way >> >> profile-level-id works, and how H.264 encodes streams, there is no >> >> problem with currently specifying a level above what you >> can "truly" >> >> support *sending*. I.e. you can say you can receive and >> send level >> >> 3.0 via profile-level-id, but nothing forces you to use the full >> >> limits of level 3.0 when sending. You can send a stream >> that could >> >> be encoded identically in level 2.0; you can even mark it as level >> >> 3.0 in the SPS/PPS NAL units. >> >> >> >> On the other side of the equation, it is the lesser - if >> you can only >> >> receive level 2.0 when all the limits in the received stream are >> >> maxed out, you can't use anything above level 2.0 in >> >> profile-level-id. (You can >> >> *extend* it (such as with max-fs), if you also agree to decode the >> >> extension as well.) >> >> >> >> Those are the *current* semantics of profile-level-id. A legacy >> >> device may (or may not) as mentioned over-state it's ability to >> >> encode. >> >> >> >> You could use an parameter that specifies the max sending level >> >> supported in an offer (there's no point in an answer I >> believe). I >> >> originally proposed this. However, on reflection, there's very >> >> little if anything to gain from that that I can see. A receiver >> >> could respond to >> >> level-upgrade-allowed=1 (or level-asymmetry-allowed=1) with the >> >> highest level it can receive. Now each side knows the >> highest level >> >> the other can receive, and can send up to that level. The only >> >> downside I can possibly think of to not knowing the >> maximum sending >> >> ability is that a receiver could perhaps not allocate as many >> >> resources if it knew the offerer couldn't send above level N. >> >> Example: >> >> >> >> A: Can receive level 2.0 (small LCD perhaps), can send level 3.0 >> >> B: Can receive level 5.0, can send level 3.0 (more common form of >> >> send/recv >> >> asymmetry) >> >> >> >> A offers to be with >> profile-level-id=420014;level-asymmetry-allowed=1 >> >> B answers with profile-level-id=420032 >> >> >> >> A will send at level 3.0 >> >> B will send at level 2.0 (and must allocate resources to >> potentially >> >> receive 5.0) >> >> >> >> If you had a maximum-send-level parameter: >> >> >> >> A offers to be with profile-level-id=420014;sprop-max-level=1E >> >> B answers with profile-level-id=42001E >> >> >> >> A will send at level 3.0 >> >> B will send at level 2.0 (and only has to allocate resources for >> >> level 3.0) >> >> >> >> >> >> The question is "is it worth it"? Also, while this may let you limit >> >> resources, you may also limit the options of the sender. For >> >> example, in the first case above, since A knows B can receive 5.0, A >> >> could send a higher frame size than 3.0 supports (perhaps at a lower >> >> framerate), even though A can't support sending "full" level 3.1. >> >> >> >> I should also note that quantizing the maximum level you can send is >> >> VERY subjective/arbitrary, because of how the encoding works. See >> >> the discussion above about how you don't have to max out the level >> >> you're supposedly sending. >> >> >> >> So my suggestion is to use level-asymmetry-allowed. (See my previous >> >> post for how this differs from level-upgrade-allowed - it allows >> >> asymmetric levels on level downgrade as well, which is actually >> >> probably a more common case.) >> >> >> >> >That suggests that profile-level-id should retain its current >> >> >semantics, and one or two new parameters (only one of >> which would be >> >> >present in the offer or answer) would indicate two things: >> >> >a) a value which is higher than the value given in >> profile-level-id; >> >> >b) whether that value is a send or receive capability. >> >> > >> >> >If it's just one parameter, it would have to be double >> valued e.g., >> >> >alternate-level-id="send,<value>". >> >> > >> >> >If it is two parameters, the appropriate parameter to >> include would >> >> >depend on which whether the capability being reported is send or >> >> >receive, e.g., send-level-id=<value> >> >> >or recv-level-id=<value >> >> >but never both in the same stream. >> >> > >> >> >Ye-Kui Wang wrote: >> >> >> Another interoperability issue relates to the semantics >> >> change of the >> >> >> level part of profile-level-id. Currently, the level part, >> >> when used >> >> >> capability exchange or session setup, gives the upper >> >> limit of both >> >> >> decoding capability and encoding capability, as seen from the >> >> >> following two paragraphs excerpted from the bis draft (the >> >> same in spirit in 3984): >> >> >> >> >> >> "The profile-level-id parameter indicates the default >> sub-profile, >> >> >> i.e. the subset of coding tools that may have been used to >> >> generate >> >> >> the stream or that the receiver supports, and the >> default level of >> >> >> the stream or the receiver supports." >> >> >> >> >> >> "If the profile-level-id parameter is used for capability >> >> exchange or >> >> >> session setup procedure, it indicates the subset of >> coding tools, >> >> >> which is equal to the default sub-profile, and the >> highest level, >> >> >> which is equal to the default level, that the codec >> supports. All >> >> >> levels lower than the default level are also supported by >> >> the codec. " >> >> >> >> >> >> When level upgrade is allowed, then this semantics must >> >> change, such >> >> >> that the level part basically indicates only the decoding >> >> capability. >> >> >> This change of course creates different understandings >> between the >> >> >> two sides whenever one is legacy and the other is new. >> >> >> >> >> >> We have at least the following options to go to allow for level >> >> >> upgrade (the semantics change above is anyway needed): - To add >> >> >> "level-upgrade-allowed". - To add "level-upgrade-allowed" >> >> and another >> >> >> parameter, say sending-capability-level, to indicate >> the sending >> >> >> capability expressed as a level value. - To go wildly, by >> >> making all >> >> >> paramters not starting with "sprop-" as receiving capabilities. >> >> >> Another group of parameters not starting with "sprop-" can be >> >> >> optionally used to indicate sending capabilities. When >> >> these sending >> >> >> capability parameters are not present, the sending >> >> capabilities are >> >> >> by default equal to the receiving capabilties. >> >> >> >> >> >> A decision needs to be made which one to take. >> >> >> >> >> >> In any case, I hope a proponent could provide relatively >> >> mature text, >> >> >> including changes to semantics, offer/answer rules (including >> >> >> parameter sets considerations in offer/answer), >> declarative usage, >> >> >> SDP examples, and discussion of backward compatibility issues. >> >> >> >> >> >> Note that all the changes will also affect the SVC payload >> >> draft, as >> >> >> they basically need to be appropriately integrated to the >> >> SVC payload draft. >> >> >> >> >> >> BR, YK >> >> >> >> >> >... >> >> >_______________________________________________ >> >> >Audio/Video Transport Working Group >> >> >avt@ietf.org >> >> >https://www.ietf.org/mailman/listinfo/avt >> >> >> >> >> >> -- >> >> Randell Jesup, Worldgate (developers of the Ojo >> videophone), ex-Amiga >> >> OS team rjesup@wgate.com "The fetters imposed on liberty >> at home have >> >> ever been forged out of the weapons provided for defence against >> >> real, pretended, or imaginary dangers from abroad." >> >> - James Madison, 4th US president (1751-1836) >> >> >> >> _______________________________________________ >> >> Audio/Video Transport Working Group >> >> avt@ietf.org >> >> https://www.ietf.org/mailman/listinfo/avt >> >> >> >> >> -- >> Randell Jesup, Worldgate (developers of the Ojo videophone), >> ex-Amiga OS team rjesup@wgate.com "The fetters imposed on >> liberty at home have ever been forged out of the weapons >> provided for defence against real, pretended, or imaginary >> dangers from abroad." >> - James Madison, 4th US president (1751-1836) >> >> -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com "The fetters imposed on liberty at home have ever been forged out of the weapons provided for defence against real, pretended, or imaginary dangers from abroad." - James Madison, 4th US president (1751-1836) From yekuiwang@huawei.com Fri May 22 10:09:30 2009 Return-Path: <yekuiwang@huawei.com> X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4EAF28C135 for <avt@core3.amsl.com>; Fri, 22 May 2009 10:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.325 X-Spam-Level: X-Spam-Status: No, score=-2.325 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7QEaV2RM7PJo for <avt@core3.amsl.com>; Fri, 22 May 2009 10:09:29 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id D2A473A68B4 for <avt@ietf.org>; Fri, 22 May 2009 10:09:28 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KK2005972DPWP@usaga04-in.huawei.com> for avt@ietf.org; Fri, 22 May 2009 12:10:37 -0500 (CDT) Received: from W90946 ([10.193.125.102]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KK200G832DHM2@usaga04-in.huawei.com> for avt@ietf.org; Fri, 22 May 2009 12:10:37 -0500 (CDT) Date: Fri, 22 May 2009 13:10:29 -0400 From: Ye-Kui Wang <yekuiwang@huawei.com> In-reply-to: <ybuhbzdb1tr.fsf@jesup.eng.wgate.com> To: 'Randell Jesup' <rjesup@wgate.com> Message-id: <0F4BC54357284559B31303B0D730F7E2@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acna8UQGrgzYGcgMRLK6VKOJKU4GPAAA4Spw References: <4A15046C.5080600@rogers.com> <006701c9d9e9$51679500$f436bf00$%roni@huawei.com> <7779AD69A5E54F9F84E473BB4F4E1E71@china.huawei.com> <4A157ADA.8060900@rogers.com> <ybuljopyjto.fsf@jesup.eng.wgate.com> <3221EC0396044781B11D483B77E085A1@china.huawei.com> <ybuhbzdygly.fsf@jesup.eng.wgate.com> <939A5D7EEE0A410E867078A3117DD3CE@china.huawei.com> <ybuhbzdb1tr.fsf@jesup.eng.wgate.com> Cc: 'Tom Taylor' <tom.taylor@rogers.com>, 'IETF AVT WG' <avt@ietf.org> Subject: Re: [AVT] Consensus on profile-level-id in 3984bis X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group <avt.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/avt> List-Post: <mailto:avt@ietf.org> List-Help: <mailto:avt-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 22 May 2009 17:09:30 -0000 I think the root of most of the disputes is, given a video encoder, whether you can label it with a max level. In theory, I think you are right that, given the computing resource of the encoder, it is possible to compromise among parameters. However, in practice, when you get an encoder product (which is typically optimized or even fixed for certain operating range), it would typically be labelled with a profile at a level, and it should not be common that users (of the encoder product) would try to compromise among parameters and see whether it can produce a bitstream with a higher level, and in many cases, the encoder product does not provide enough space for you play around this. The level labelled by the encoder manufacture is usually the max level. There are of course also purely PC software based encoders can be very flexible, and can be configured to be almost any profile and level. But once it is configured to be at a profile and a level and the encoder is initialized, then that level should be used as the max level. BR, YK > -----Original Message----- > From: Randell Jesup [mailto:rjesup@wgate.com] > Sent: Friday, May 22, 2009 11:22 AM > To: Ye-Kui Wang > Cc: 'Tom Taylor'; 'IETF AVT WG' > Subject: Re: [AVT] Consensus on profile-level-id in 3984bis > > Ye-Kui Wang <yekuiwang@huawei.com> writes: > >> Ye-Kui Wang <yekuiwang@huawei.com> writes: > >> >If the following are considered, then let the other side know the > >> >sending capability (as well as whether level upgrade is allowed) > >> >would be very useful. > >> > > >> >- One may want to request a specific mode, e.g. a spatial > >> >resolution, from the sender, for example by using image attribute > >> >mmusic draft. > >> > >> Does adding a max-send-level actually help you there? > > > >Yes. > > > >> How does this interact with how you decide what your max sending > >> level is? > > > >You don't decide your max sending level, your max sending > level is your > >max sending capability, a hard capability limit of you. > > Max capability for what/which? For all parameters simultaneously? > Maximum bitrate at maximum framesize at maximum > macroblocks/second, with maximum frame-to-frame motion, with > maximum motion-estimation-search, etc? > > I'm not saying you can't choose a maximum, but it's very, > very soft - very subjective because encoding is much more > variable (and expensive) than decoding. It's (much) easier > to estimate a worst-case for decode. > > >> As mentioned below, choosing a value for that (other than > basing it > >> on resolution alone, and that just might put a lower bound > on it) is > >> extremely subjective at best. > > > >Example: If one side lets the other side know its max sending > >capability, then the other side would not even try to request a > >specific capability that is impossible to be satisfied. > Otherwise, the > >other side may just send useless requests. > > > >> >- Video adaptation, in terms of bitrate, frame rate, > and/or spatial > >> >resolution etc, may happen during the session, and may be > initiated > >> >by either side. > >> > >> Again, how would this work in practice, and how would > adding it here > >> help? Adaptation within the negotiated limits can occur now, so I > >> don't see the advantage here. If you need to change the > maximum limits (why? > >> weren't they properly negotiated to start with?), then you can > >> re-invite. I think we need a concrete example, in order > to know if > >> what you're proposing is sufficient - or if it works. I'm quite > >> unclear on how you believe specifying a max send level will help > >> anything, since your list is quite vague. > >> > > > >Example > > > >The offerer does not tell the answerer its max sending capability, > >which is level B. A negotiation is done, where the answer includes > >level C (C>B), and the offerer starts to send at C (actually > B, but the > >answerer may not be sure). After a while, the answerer > senses that the > >connecting bandwidth is higher, and it wants to receive at a higher > >bitrate, which is still within the limit of level C, but above the > >limit of B, and sends a meaningless adaption request using re-invite. > > > >However, if the offerer does tell the answerer its max sending > >capability, such meaningless adaption requests are avoided. > I believe > >there are more examples, but I hope this already helps. > > That's a plausible case - thanks. However, I think you could > have an unintended result if you did that. Lets say that the > offerer uses the "worst-case" method to decide on a > max-send-level (per above). That level may be well below the > limits it could hit when it's not worst case - for example, > it may be constrained on framesize or MBPS to level 3.0, but > can handle the outgoing bandwidth of level 4.0, and level 5.0 > when other parameters aren't worst-case. By limiting to a > max-send-level of 3.0, the receiver won't request use of > extra bandwidth or 4.0 or 5.0. Note that even if you go and > duplicate all the max-* parameters as sprop-max-*, you still > wouldn't be able to handle the "I can do this when other > parameters are relaxed" case. > > I also already mentioned this problem below (repeated here): > >> >> The question is "is it worth it"? Also, while this may let you > >> >> limit resources, you may also limit the options of the sender. > >> >> For example, in the first case above, since A knows B > can receive > >> >> 5.0, A could send a higher frame size than 3.0 supports > (perhaps > >> >> at a lower framerate), even though A can't support > sending "full" level 3.1. > > I think you can handle the adaptation issue as part of the > adaptation design, since there may be other reasons the > offerer can't raise the bandwidth (or whatever). > > >BR, YK > > > > > >> >BR, YK > >> > > >> >> -----Original Message----- > >> >> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] > >> On Behalf Of > >> >> Randell Jesup > >> >> Sent: Thursday, May 21, 2009 10:04 PM > >> >> To: Tom Taylor > >> >> Cc: IETF AVT WG > >> >> Subject: Re: [AVT] Consensus on profile-level-id in 3984bis > >> >> > >> >> Tom Taylor <tom.taylor@rogers.com> writes: > >> >> >It appears that the optimum outcome is to be able to signal > >> >> both send > >> >> >and receive capability. The legacy approach loses some of this > >> >> >information, since profile-level-id contains the lesser > >> of the two > >> >> >values. In a legacy-new interworking situation it seems > >> >> unlikely that > >> >> >we can improve on this. > >> >> > >> >> Well, I'm not sure you can say that a legacy device > >> definitively uses > >> >> the lesser of send/receive in profile-level-id. Because > >> of the way > >> >> profile-level-id works, and how H.264 encodes streams, > there is no > >> >> problem with currently specifying a level above what you > >> can "truly" > >> >> support *sending*. I.e. you can say you can receive and > >> send level > >> >> 3.0 via profile-level-id, but nothing forces you to use > the full > >> >> limits of level 3.0 when sending. You can send a stream > >> that could > >> >> be encoded identically in level 2.0; you can even mark > it as level > >> >> 3.0 in the SPS/PPS NAL units. > >> >> > >> >> On the other side of the equation, it is the lesser - if > >> you can only > >> >> receive level 2.0 when all the limits in the received > stream are > >> >> maxed out, you can't use anything above level 2.0 in > >> >> profile-level-id. (You can > >> >> *extend* it (such as with max-fs), if you also agree to > decode the > >> >> extension as well.) > >> >> > >> >> Those are the *current* semantics of profile-level-id. > A legacy > >> >> device may (or may not) as mentioned over-state it's ability to > >> >> encode. > >> >> > >> >> You could use an parameter that specifies the max sending level > >> >> supported in an offer (there's no point in an answer I > >> believe). I > >> >> originally proposed this. However, on reflection, there's very > >> >> little if anything to gain from that that I can see. A > receiver > >> >> could respond to > >> >> level-upgrade-allowed=1 (or level-asymmetry-allowed=1) with the > >> >> highest level it can receive. Now each side knows the > >> highest level > >> >> the other can receive, and can send up to that level. The only > >> >> downside I can possibly think of to not knowing the > >> maximum sending > >> >> ability is that a receiver could perhaps not allocate as many > >> >> resources if it knew the offerer couldn't send above level N. > >> >> Example: > >> >> > >> >> A: Can receive level 2.0 (small LCD perhaps), can send level 3.0 > >> >> B: Can receive level 5.0, can send level 3.0 (more > common form of > >> >> send/recv > >> >> asymmetry) > >> >> > >> >> A offers to be with > >> profile-level-id=420014;level-asymmetry-allowed=1 > >> >> B answers with profile-level-id=420032 > >> >> > >> >> A will send at level 3.0 > >> >> B will send at level 2.0 (and must allocate resources to > >> potentially > >> >> receive 5.0) > >> >> > >> >> If you had a maximum-send-level parameter: > >> >> > >> >> A offers to be with profile-level-id=420014;sprop-max-level=1E > >> >> B answers with profile-level-id=42001E > >> >> > >> >> A will send at level 3.0 > >> >> B will send at level 2.0 (and only has to allocate > resources for > >> >> level 3.0) > >> >> > >> >> > >> >> The question is "is it worth it"? Also, while this may let you > >> >> limit resources, you may also limit the options of the sender. > >> >> For example, in the first case above, since A knows B > can receive > >> >> 5.0, A could send a higher frame size than 3.0 supports > (perhaps > >> >> at a lower framerate), even though A can't support > sending "full" level 3.1. > >> >> > >> >> I should also note that quantizing the maximum level > you can send > >> >> is VERY subjective/arbitrary, because of how the > encoding works. > >> >> See the discussion above about how you don't have to > max out the > >> >> level you're supposedly sending. > >> >> > >> >> So my suggestion is to use level-asymmetry-allowed. (See my > >> >> previous post for how this differs from > level-upgrade-allowed - it > >> >> allows asymmetric levels on level downgrade as well, which is > >> >> actually probably a more common case.) > >> >> > >> >> >That suggests that profile-level-id should retain its current > >> >> >semantics, and one or two new parameters (only one of > >> which would be > >> >> >present in the offer or answer) would indicate two things: > >> >> >a) a value which is higher than the value given in > >> profile-level-id; > >> >> >b) whether that value is a send or receive capability. > >> >> > > >> >> >If it's just one parameter, it would have to be double > >> valued e.g., > >> >> >alternate-level-id="send,<value>". > >> >> > > >> >> >If it is two parameters, the appropriate parameter to > >> include would > >> >> >depend on which whether the capability being reported > is send or > >> >> >receive, e.g., send-level-id=<value> > >> >> >or recv-level-id=<value > >> >> >but never both in the same stream. > >> >> > > >> >> >Ye-Kui Wang wrote: > >> >> >> Another interoperability issue relates to the semantics > >> >> change of the > >> >> >> level part of profile-level-id. Currently, the level part, > >> >> when used > >> >> >> capability exchange or session setup, gives the upper > >> >> limit of both > >> >> >> decoding capability and encoding capability, as seen > from the > >> >> >> following two paragraphs excerpted from the bis draft (the > >> >> same in spirit in 3984): > >> >> >> > >> >> >> "The profile-level-id parameter indicates the default > >> sub-profile, > >> >> >> i.e. the subset of coding tools that may have been used to > >> >> generate > >> >> >> the stream or that the receiver supports, and the > >> default level of > >> >> >> the stream or the receiver supports." > >> >> >> > >> >> >> "If the profile-level-id parameter is used for capability > >> >> exchange or > >> >> >> session setup procedure, it indicates the subset of > >> coding tools, > >> >> >> which is equal to the default sub-profile, and the > >> highest level, > >> >> >> which is equal to the default level, that the codec > >> supports. All > >> >> >> levels lower than the default level are also supported by > >> >> the codec. " > >> >> >> > >> >> >> When level upgrade is allowed, then this semantics must > >> >> change, such > >> >> >> that the level part basically indicates only the decoding > >> >> capability. > >> >> >> This change of course creates different understandings > >> between the > >> >> >> two sides whenever one is legacy and the other is new. > >> >> >> > >> >> >> We have at least the following options to go to > allow for level > >> >> >> upgrade (the semantics change above is anyway > needed): - To add > >> >> >> "level-upgrade-allowed". - To add "level-upgrade-allowed" > >> >> and another > >> >> >> parameter, say sending-capability-level, to indicate > >> the sending > >> >> >> capability expressed as a level value. - To go wildly, by > >> >> making all > >> >> >> paramters not starting with "sprop-" as receiving > capabilities. > >> >> >> Another group of parameters not starting with > "sprop-" can be > >> >> >> optionally used to indicate sending capabilities. When > >> >> these sending > >> >> >> capability parameters are not present, the sending > >> >> capabilities are > >> >> >> by default equal to the receiving capabilties. > >> >> >> > >> >> >> A decision needs to be made which one to take. > >> >> >> > >> >> >> In any case, I hope a proponent could provide relatively > >> >> mature text, > >> >> >> including changes to semantics, offer/answer rules > (including > >> >> >> parameter sets considerations in offer/answer), > >> declarative usage, > >> >> >> SDP examples, and discussion of backward > compatibility issues. > >> >> >> > >> >> >> Note that all the changes will also affect the SVC payload > >> >> draft, as > >> >> >> they basically need to be appropriately integrated to the > >> >> SVC payload draft. > >> >> >> > >> >> >> BR, YK > >> >> >> > >> >> >... > >> >> >_______________________________________________ > >> >> >Audio/Video Transport Working Group avt@ietf.org > >> >> >https://www.ietf.org/mailman/listinfo/avt > >> >> > >> >> > >> >> -- > >> >> Randell Jesup, Worldgate (developers of the Ojo > >> videophone), ex-Amiga > >> >> OS team rjesup@wgate.com "The fetters imposed on liberty > >> at home have > >> >> ever been forged out of the weapons provided for > defence against > >> >> real, pretended, or imaginary dangers from abroad." > >> >> - James Madison, 4th US president (1751-1836) > >> >> > >> >> _______________________________________________ > >> >> Audio/Video Transport Working Group avt@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/avt > >> >> > >> > >> > >> -- > >> Randell Jesup, Worldgate (developers of the Ojo > videophone), ex-Amiga > >> OS team rjesup@wgate.com "The fetters imposed on liberty > at home have > >> ever been forged out of the weapons provided for defence against > >> real, pretended, or imaginary dangers from abroad." > >> - James Madison, 4th US president (1751-1836) > >> > >> > > > -- > Randell Jesup, Worldgate (developers of the Ojo videophone), > ex-Amiga OS team > rjesup@wgate.com > "The fetters imposed on liberty at home have ever been forged > out of the weapons > provided for defence against real, pretended, or imaginary > dangers from abroad." > - James Madison, 4th US president (1751-1836) > > From luby@qualcomm.com Fri May 22 10:19:31 2009 Return-Path: <luby@qualcomm.com> X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3267E28C136 for <avt@core3.amsl.com>; Fri, 22 May 2009 10:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.558 X-Spam-Level: X-Spam-Status: No, score=-103.558 tagged_above=-999 required=5 tests=[AWL=-0.960, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0AMSISP8Oac for <avt@core3.amsl.com>; Fri, 22 May 2009 10:19:15 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 4DC503A68B4 for <avt@ietf.org>; Fri, 22 May 2009 10:19:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=luby@qualcomm.com; q=dns/txt; s=qcdkim; t=1243012854; x=1274548854; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:mime-version:x-ironport-av; z=From:=20"Luby,=20Michael"=20<luby@qualcomm.com>|To:=20"L .Wood@surrey.ac.uk"=20<L.Wood@surrey.ac.uk>,=0D=0A=20=20 =20=20=20=20=20=20"john.lazzaro@gmail.com"=0D=0A=09<john. lazzaro@gmail.com>,=0D=0A=20=20=20=20=20=20=20=20"avt@iet f.org"=20<avt@ietf.org>|CC:=20"Luby,=20Michael"=20<luby@q ualcomm.com>|Date:=20Fri,=2022=20May=202009=2010:20:50=20 -0700|Subject:=20Re:=20[AVT]=20Comments=20on=20draft-pant os-http-live-streaming-00.txt=20...|Thread-Topic:=20[AVT] =20Comments=20on=20draft-pantos-http-live-streaming-00.tx t=20...|Thread-Index:=20AcnaXfKgAq96RYWITYyGIZOb97b6owARZ t64ABeGOeQ=3D|Message-ID:=20<C63C2D02.36FD%luby@qualcomm. com>|In-Reply-To:=20<4835AFD53A246A40A3B8DA85D658C4BE7B10 32@EVS-EC1-NODE4.surrey.ac.uk>|Accept-Language:=20en-US |Content-Language:=20en|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20multipart/alternative=3B=0D=0A=09boundar y=3D"_000_C63C2D0236FDlubyqualcommcom_"|MIME-Version:=201 .0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5623"=3B =20a=3D"18500769"; bh=LmfSrBPZ+IqltF1GdvH8O2SIq8AU0aGW/TFVJUf2e0A=; b=Z5cA/Strm6CJ0IDSpYfuewG7s2hm08yBu2vkptDHhB98ep/BjCs5b+oq gE55H6OYuwPJWasDjO8InP6kdsKtgsFKot8NMwiQtpRtH/6os3//mn/so X4yl2++JXjgoAsmlanX1JraXaH/J5RvkhRmOLo8eHDRZmBKPK5qVVUrZp Y=; X-IronPort-AV: E=McAfee;i="5300,2777,5623"; a="18500769" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 May 2009 10:20:54 -0700 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n4MHKrJe004516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 22 May 2009 10:20:53 -0700 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n4MHKrUE011861 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 22 May 2009 10:20:53 -0700 (PDT) Received: from nasclexhc01.na.qualcomm.com (10.227.147.14) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.1.358.0; Fri, 22 May 2009 10:20:52 -0700 Received: from NASCLEXMB02.na.qualcomm.com ([10.227.144.113]) by nasclexhc01.na.qualcomm.com ([10.227.147.14]) with mapi; Fri, 22 May 2009 10:20:52 -0700 From: "Luby, Michael" <luby@qualcomm.com> To: "L.Wood@surrey.ac.uk" <L.Wood@surrey.ac.uk>, "john.lazzaro@gmail.com" <john.lazzaro@gmail.com>, "avt@ietf.org" <avt@ietf.org> Date: Fri, 22 May 2009 10:20:50 -0700 Thread-Topic: [AVT] Comments on draft-pantos-http-live-streaming-00.txt ... Thread-Index: AcnaXfKgAq96RYWITYyGIZOb97b6owARZt64ABeGOeQ= Message-ID: <C63C2D02.36FD%luby@qualcomm.com> In-Reply-To: <4835AFD53A246A40A3B8DA85D658C4BE7B1032@EVS-EC1-NODE4.surrey.ac.uk> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C63C2D0236FDlubyqualcommcom_" MIME-Version: 1.0 Subject: Re: [AVT] Comments on draft-pantos-http-live-streaming-00.txt ... X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group <avt.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/avt> List-Post: <mailto:avt@ietf.org> List-Help: <mailto:avt-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 22 May 2009 17:19:31 -0000 --_000_C63C2D0236FDlubyqualcommcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm not expressing an opinion on whether this work should move forward at t= his point, but I'll make a couple of comments that everyone may not be awar= e of in terms of traction of this approach. (1) Move Networks is essentially using this approach to provide their strea= ming solution. (Used by ABC for streaming their prime time shows over the = Internet, and many other content providers at this point). (2) This is essentially the approach that Adobe FLASH is taking with their = FLASH servers. Perhaps in response to the market traction that Move Networ= ks was getting. (3) This same approach has also been adopted into Microsoft Silverlight. Now, when I say this same approach, I mean that it can accommodate the foll= owing: (A) Able to use standard servers (or cheap servers in general) to deliver t= he content, so that it can be delivered from a CDN or any other standard se= rver farm. (B) Real-time or Video-on demand streaming. (C) Fast channel change and seek times, i.e., good responsiveness to user A= DD. (D) Able to automatically choose the initial streaming rate to match the in= itial available bandwidth. (E) Able to seamlessly change streaming rate on the fly in reaction to chan= ges in available bandwidth, even within a given content. (F) Able to penetrate firewalls and NATS. (A) is bolded, because it is perhaps the most important motivation for the = approach and why it has become so successful. (B-F) are what have become s= tandard requirements for a true high quality streaming solution over the op= en Internet. Move Networks technology exactly does A-F, using HTTP as the = delivery protocol, much along the conceptual lines described by the draft. = I believe Adobe FLASH may use their proprietary protocols, but essentially= they are achieving A-F using FLASH servers instead of HTTP servers. I kno= w that Silverlight has the functionality, but not sure if they use HTTP or = something else as the delivery protocol. All of these features seem to be = attractive to streaming over the Internet, and is the most popular approach= out there that is actually used in a massive way. Using RTP directly for whatever reason has not caught on. Perhaps some re= asons RTP has not caught on: (a) An ad-hoc scalable infrastructure would ne= ed to be deployed for RTP video streaming, instead of using existing alread= y scalable and deployed infrastructure. CDNs are very adverse to having to= support yet another type of server architecture, and are always trying to = simplify what they need to support, not make it more complicated; (b) Not r= eliable; (c) Firewall/NAT transversal in the deployed Internet is an issue= ; (d) No support for congestion control. With respect to Ajax, it might help with some support for this approach in = the client browser, and thus might be complementary to the proposal, but al= one does not meet the requirements. Mike On 5/21/09 11:12 PM, "L.Wood@surrey.ac.uk" <L.Wood@surrey.ac.uk> wrote: http://tools.ietf.org/id/draft-pantos-http-live-streaming-00.txt There's a mismatch between the goal in the first sentence of the introduction: This document describes a protocol for transmitting unbounded streams of multimedia data over HTTP [RFC2616]. and the focus of this draft on actually being limited to using M3U files. For unbounded streams where the length is not known a priori, I was expecting to see heavy use of HTTP chunking. That is not the problem that this draft is trying to solve. Each media file URI MUST be preceded by an EXTINF tag. Its format is: #EXTINF:<duration>,<title> "duration" is an integer that specifies the duration of the media file in seconds. So it's necessary to know how long a file is before specifying it. The draft is not really dealing with an unbounded stream of data, more bringing together separate known resources seamlessly. As John says, that particular problem has been solved by AJAX. cheers, L. <http://www.ee.surrey.ac.uk/Personal/L.Wood/><L.Wood@surrey.ac.uk> -----Original Message----- From: avt-bounces@ietf.org on behalf of John Lazzaro Sent: Thu 2009-05-21 22:46 To: avt@ietf.org Subject: [AVT] Comments on draft-pantos-http-live-streaming-00.txt ... Hi everyone, Comments on draft-pantos-http-live-streaming-00.txt below. What jumped out at me was that this is a late-1990s approach to a problem ... but its almost 2010 ... In my view, the I-D is trying to do for audio what the AJAX client code for Google Maps does for image map tiles. Namely, pre-loading short media files over HTTP, to drive a user interface that the user perceives as continuous (and in the Google Maps case, responsive to user input). I haven't looked at HTML5 (yet), but I was under the impression one goal of its audio/video features is to provide the primitives to make it possible to implement the protocol described in draft-pantos-http-live-streaming-00.txt using AJAX techniques. If the feature set isn't there yet in HTML5 to do that, I think the time spent working on this I-D is better spent working within the HTML5 process to get the features that are needed. It seems to me that AJAX is a more natural way to implement this sort of "concatenation of pre-downloaded 10-second files" streaming. If there is AVT consensus that draft-pantos-http-live-streaming-00.txt's general approach is acceptable for a work-item, I'll do a second review of potential technical issues with the protocol itself ... -- John Lazzaro http://www.cs.berkeley.edu/~lazzaro john [dot] lazzaro [at] gmail [dot] com --_000_C63C2D0236FDlubyqualcommcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <HTML> <HEAD> <TITLE>Re: [AVT] Comments on draft-pantos-http-live-streaming-00.txt ...</T= ITLE> </HEAD> <BODY> <FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:= 11pt'>I’m not expressing an opinion on whether this work should move = forward at this point, but I’ll make a couple of comments that everyo= ne may not be aware of in terms of traction of this approach.<BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"= ><SPAN STYLE=3D'font-size:11pt'><BR> (1) Move Networks is essentially using this approach to provide their strea= ming solution.  (Used by ABC for streaming their prime time shows over= the Internet, and many other content providers at this point).<BR> <BR> (2) This is essentially the approach that Adobe FLASH is taking with their = FLASH servers.  Perhaps in response to the market traction that Move N= etworks was getting.<BR> <BR> (3) This same approach has also been adopted into Microsoft Silverlight.<BR= > <BR> Now, when I say this same approach, I mean that it can accommodate the foll= owing:<BR> <BR> <B>(A) Able to use standard servers (or cheap servers in general) to delive= r the content, so that it can be delivered from a CDN or any other standard= server farm.<BR> </B>(B) Real-time or Video-on demand streaming.<BR> (C) Fast channel change and seek times, i.e., good responsiveness to user A= DD.<BR> (D) Able to automatically choose the initial streaming rate to match the in= itial available bandwidth.  <BR> (E) Able to seamlessly change streaming rate on the fly in reaction to chan= ges in available bandwidth, even within a given content.<BR> (F) Able to penetrate firewalls and NATS.<BR> <BR> (A) is bolded, because it is perhaps the most important motivation for the = approach and why it has become so successful.  (B-F) are what have bec= ome standard requirements for a true high quality streaming solution over t= he open Internet.  Move Networks technology exactly does A-F, using HT= TP as the delivery protocol, much along the conceptual lines described by t= he draft.  I believe Adobe FLASH may use their proprietary protocols, = but essentially they are achieving A-F using FLASH servers instead of HTTP = servers.  I know that Silverlight has the functionality, but not sure = if they use HTTP or something else as the delivery protocol.  All of t= hese features seem to be attractive to streaming over the Internet, and is = the most popular approach out there that is actually used in a massive way.= <BR> <BR> Using RTP directly for whatever reason has not caught on.   Perha= ps some reasons RTP has not caught on: (a) An ad-hoc scalable infrastructur= e would need to be deployed for RTP video streaming, instead of using exist= ing already scalable and deployed infrastructure.  CDNs are very adver= se to having to support yet another type of server architecture, and are al= ways trying to simplify what they need to support, not make it more complic= ated; (b) Not reliable;  (c) Firewall/NAT transversal in the deployed = Internet is an issue; (d) No support for congestion control.<BR> <BR> With respect to Ajax, it might help with some support for this approach in = the client browser, and thus might be complementary to the proposal, but al= one does not meet the requirements. <BR> </SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial= "><SPAN STYLE=3D'font-size:11pt'>Mike<BR> <BR> <BR> On 5/21/09 11:12 PM, "<a href=3D"L.Wood@surrey.ac.uk">L.Wood@surrey.ac= .uk</a>" <<a href=3D"L.Wood@surrey.ac.uk">L.Wood@surrey.ac.uk</a>&g= t; wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"= ><SPAN STYLE=3D'font-size:11pt'><a href=3D"http://tools.ietf.org/id/draft-p= antos-http-live-streaming-00.txt">http://tools.ietf.org/id/draft-pantos-htt= p-live-streaming-00.txt</a><BR> <BR> There's a mismatch between the goal in the first sentence of<BR> the introduction:<BR> <BR>    This document describes a protocol for transmitting unbou= nded streams<BR>    of multimedia data over HTTP [RFC2616].<BR> <BR> and the focus of this draft on actually being limited to using<BR> M3U files.<BR> <BR> For unbounded streams where the length is not known a priori,<BR> I was expecting to see heavy use of HTTP chunking.<BR> That is not the problem that this draft is<BR> trying to solve.<BR> <BR>    Each media file URI MUST be preceded by an<BR>    EXTINF tag.  Its format is:<BR> <BR>    #EXTINF:<duration>,<title><BR> <BR>    "duration" is an integer that specifies the dur= ation of the media<BR>    file in seconds. <BR> <BR> So it's necessary to know how long a file is before specifying it.<BR> The draft is not really dealing with an unbounded stream of data,<BR> more bringing together separate known resources seamlessly. As John<BR> says, that particular problem has been solved by AJAX.<BR> <BR> cheers,<BR> <BR> L.<BR> <BR> <<a href=3D"http://www.ee.surrey.ac.uk/Personal/L.Wood/><L.Wood@su= rrey.ac.uk">http://www.ee.surrey.ac.uk/Personal/L.Wood/><L.Wood@surre= y.ac.uk</a>><BR> <BR> <BR> <BR> -----Original Message-----<BR> From: <a href=3D"avt-bounces@ietf.org">avt-bounces@ietf.org</a> on behalf o= f John Lazzaro<BR> Sent: Thu 2009-05-21 22:46<BR> To: <a href=3D"avt@ietf.org">avt@ietf.org</a><BR> Subject: [AVT] Comments on draft-pantos-http-live-streaming-00.txt ...<BR> <BR> Hi everyone,<BR> <BR> Comments on draft-pantos-http-live-streaming-00.txt below.<BR> <BR> What jumped out at me was that this is a late-1990s<BR> approach to a problem ... but its almost 2010 ...<BR> <BR> In my view, the I-D is trying to do for audio what the AJAX client code<BR> for Google Maps does for image map tiles. Namely, pre-loading short<BR> media files over HTTP, to drive a user interface that the user<BR> perceives as continuous (and in the Google Maps case,<BR> responsive to user input).<BR> <BR> I haven't looked at HTML5 (yet), but I was under the impression<BR> one goal of its audio/video features is to provide the<BR> primitives to make it possible to implement the protocol<BR> described in draft-pantos-http-live-streaming-00.txt using<BR> AJAX techniques.  If the feature set isn't there yet in HTML5<BR> to do that, I think the time spent working on this I-D is better<BR> spent working within the HTML5 process to get the features that<BR> are needed.  It seems to me that AJAX is a more natural way to<BR> implement this sort of "concatenation of pre-downloaded 10-second<BR> files" streaming.<BR> <BR> If there is AVT consensus that draft-pantos-http-live-streaming-00.txt's<BR= > general approach is acceptable for a work-item, I'll do a second review<BR> of potential technical issues with the protocol itself ...<BR> <BR> --<BR> John Lazzaro<BR> <a href=3D"http://www.cs.berkeley.edu/~lazzaro">http://www.cs.berkeley.edu/= ~lazzaro</a><BR> john [dot] lazzaro [at] gmail [dot] com<BR> <BR> <BR> <BR> </SPAN></FONT></BLOCKQUOTE> </BODY> </HTML> --_000_C63C2D0236FDlubyqualcommcom_-- From alex.giladi@gmail.com Fri May 22 10:31:54 2009 Return-Path: <alex.giladi@gmail.com> X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5177C3A6A4E for <avt@core3.amsl.com>; Fri, 22 May 2009 10:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.726 X-Spam-Level: X-Spam-Status: No, score=-1.726 tagged_above=-999 required=5 tests=[AWL=-0.419, BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFFyAb2i9rWL for <avt@core3.amsl.com>; Fri, 22 May 2009 10:31:53 -0700 (PDT) Received: from mail-ew0-f176.google.com (mail-ew0-f176.google.com [209.85.219.176]) by core3.amsl.com (Postfix) with ESMTP id ECDF63A6A24 for <avt@ietf.org>; Fri, 22 May 2009 10:31:52 -0700 (PDT) Received: by ewy24 with SMTP id 24so1978301ewy.37 for <avt@ietf.org>; Fri, 22 May 2009 10:33:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:cc:content-type :content-transfer-encoding; bh=LQ4lRzE5hUNd7GongAb2MBxcq05enSYnVF0dDgnd6Zs=; b=M0cvgM5BsSzN8N2wjKoX0SyChj+mVetb8R7LYDMYhEO9G5u6AfkJJtbyLXbLK7rYx+ RGuPeswVWXFRF9aZ7MttYVqiiFtYNbvSkvVMCB4xkXqIeMVT1vGFDOL4z6XcFcley243 fy1Tl+MeNPJY40ah47jFWhkqniYuDRqiDeXlU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type:content-transfer-encoding; b=TDidtvRVrCavP6uaDA5SpNmL3F1LrIrB2kuiBneAKe63/XYXw8t6Pj9zEDWIK8toWp vOqDObjLQQszgcM4Zux9iSs9fo+rCLWYA1f1AOziNZUMa8V5vwIzwZnzOek7W9yI3OBo Tapl3p4SGR8E8EyDy0iFSihgjlbVb3ZN/LLnI= MIME-Version: 1.0 Received: by 10.216.30.71 with SMTP id j49mt1143801wea.89.1243013608324; Fri, 22 May 2009 10:33:28 -0700 (PDT) In-Reply-To: <C63C2D02.36FD%luby@qualcomm.com> References: <4835AFD53A246A40A3B8DA85D658C4BE7B1032@EVS-EC1-NODE4.surrey.ac.uk> <C63C2D02.36FD%luby@qualcomm.com> Date: Fri, 22 May 2009 11:33:28 -0600 Message-ID: <57a9e15d0905221033r7540779as77562b7853ca9aea@mail.gmail.com> From: Alex Giladi <alex.giladi@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "avt@ietf.org" <avt@ietf.org>, "L.Wood@surrey.ac.uk" <L.Wood@surrey.ac.uk> Subject: Re: [AVT] Comments on draft-pantos-http-live-streaming-00.txt ... X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group <avt.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/avt> List-Post: <mailto:avt@ietf.org> List-Help: <mailto:avt-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 22 May 2009 17:31:54 -0000 On Fri, May 22, 2009 at 11:20 AM, Luby, Michael <luby@qualcomm.com> wrote: <...> > (2) This is essentially the approach that Adobe FLASH is taking with thei= r > FLASH servers. =C2=A0Perhaps in response to the market traction that Move > Networks was getting. see: http://en.wikipedia.org/wiki/Real_Time_Messaging_Protocol Alex. From wwwrun@core3.amsl.com Fri May 22 11:07:51 2009 Return-Path: <wwwrun@core3.amsl.com> X-Original-To: avt@ietf.org Delivered-To: avt@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 2318728C0FA; Fri, 22 May 2009 11:07:51 -0700 (PDT) X-idtracker: yes To: IETF-Announce <ietf-announce@ietf.org> From: The IESG <iesg-secretary@ietf.org> Message-Id: <20090522180751.2318728C0FA@core3.amsl.com> Date: Fri, 22 May 2009 11:07:51 -0700 (PDT) Cc: avt@ietf.org Subject: [AVT] Last Call: draft-ietf-avt-rtcpssm (RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback) to Proposed Standard X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Audio/Video Transport Working Group <avt.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/avt> List-Post: <mailto:avt@ietf.org> List-Help: <mailto:avt-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 22 May 2009 18:07:51 -0000 The IESG has received a request from the Audio/Video Transport WG (avt) to consider the following document: - 'RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback ' <draft-ietf-avt-rtcpssm-18.txt> as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-06-05. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcpssm-18.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=8551&rfc_flag=0 From john.lazzaro@gmail.com Fri May 22 11:52:58 2009 Return-Path: <john.lazzaro@gmail.com> X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 217953A6E5F for <avt@core3.amsl.com>; Fri, 22 May 2009 11:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-nkrPS-7TyF for <avt@core3.amsl.com>; Fri, 22 May 2009 11:52:57 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.243]) by core3.amsl.com (Postfix) with ESMTP id 3D5243A6BD1 for <avt@ietf.org>; Fri, 22 May 2009 11:52:57 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id c3so1429272ana.4 for <avt@ietf.org>; Fri, 22 May 2009 11:54:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=tTYzFVnz+67HAMwxR/OZ3BZMCB/eexvpD8EfqBdf4Ls=; b=iRJEwMtTN8Uso+woXl6AAQGtsNPObMFkw9/L4T+iLSzfBFFuqYms5hS4v29prqfLT+ jfqabgjqHU4jASkHh2URSXb6VgPWOdVmeYkTmJ3qp497IGzLk93b/z2p4AGDookcY/KA msAY0Biva/nk58mpnYmFnZ3VNPTPSN3bUOQfE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=mAcqDlKBOg2FJlmhN8OAkgv+0uz6LiaVGX92j6Uc9S+fPgg1tWrcM4pE/fk9pn7H2X KzB7S+dzu2aqLfo4hq9sByICeCvUCU1Tgvo/5ZbI8hJO7RFVI2OwCTgi1p66z0Gdannk QP9EBTi7M8oso4rjO3z96Z8722r2fQ8w1rqdY= MIME-Version: 1.0 Received: by 10.100.105.9 with SMTP id d9mr7816463anc.142.1243018472653; Fri, 22 May 2009 11:54:32 -0700 (PDT) In-Reply-To: <C63C2D02.36FD%luby@qualcomm.com> References: <4835AFD53A246A40A3B8DA85D658C4BE7B1032@EVS-EC1-NODE4.surrey.ac.uk> <C63C2D02.36FD%luby@qualcomm.com> Date: Fri, 22 May 2009 11:54:32 -0700 Message-ID: <302f570905221154t7feb4162s6728f9dc2c736592@mail.gmail.com> From: John Lazzaro <john.lazzaro@gmail.com> To: "avt@ietf.org" <avt@ietf.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [AVT] Comments on draft-pantos-http-live-streaming-00.txt ... X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group <avt.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/avt> List-Post: <mailto:avt@ietf.org> List-Help: <mailto:avt-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 22 May 2009 18:52:58 -0000 On Fri, May 22, 2009 at 10:20 AM, Luby, Michael <luby@qualcomm.com> wrote: > Now, when I say this same approach, I mean that it can accommodate the > following: > > (A) Able to use standard servers (or cheap servers in general) to deliver > the content, so that it can be delivered from a CDN or any other standard > server farm. > (B) Real-time or Video-on demand streaming. > (C) Fast channel change and seek times, i.e., good responsiveness to user > ADD. > (D) Able to automatically choose the initial streaming rate to match the > initial available bandwidth. > (E) Able to seamlessly change streaming rate on the fly in reaction to > changes in available bandwidth, even within a given content. > (F) Able to penetrate firewalls and NATS. [...] > With respect to Ajax, it might help with some support for this approach in > the client browser, and thus might be complementary to the proposal, but > alone does not meet the requirements. Given the right set of client browser primitives, could be be more specific about which of your A-F requirements an AJAX approach could not meet, and why? -- John Lazzaro http://www.cs.berkeley.edu/~lazzaro john [dot] lazzaro [at] gmail [dot] com From Even.roni@huawei.com Fri May 22 13:56:15 2009 Return-Path: <Even.roni@huawei.com> X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0AA63A6B0A for <avt@core3.amsl.com>; Fri, 22 May 2009 13:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.073 X-Spam-Level: X-Spam-Status: No, score=-2.073 tagged_above=-999 required=5 tests=[AWL=0.526, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fo1zakNtLb4F for <avt@core3.amsl.com>; Fri, 22 May 2009 13:56:14 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id F3DE43A6812 for <avt@ietf.org>; Fri, 22 May 2009 13:55:47 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KK200IUECVOCZ@szxga04-in.huawei.com> for avt@ietf.org; Sat, 23 May 2009 04:57:24 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KK200JI2CVO4H@szxga04-in.huawei.com> for avt@ietf.org; Sat, 23 May 2009 04:57:24 +0800 (CST) Received: from windows8d787f9 (bzq-79-181-118-116.red.bezeqint.net [79.181.118.116]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KK200F06CTORZ@szxml02-in.huawei.com>; Sat, 23 May 2009 04:57:24 +0800 (CST) Date: Fri, 22 May 2009 23:55:25 +0300 From: Roni Even <Even.roni@huawei.com> In-reply-to: <0F4BC54357284559B31303B0D730F7E2@china.huawei.com> To: 'Ye-Kui Wang' <yekuiwang@huawei.com>, 'Randell Jesup' <rjesup@wgate.com> Message-id: <027101c9db1f$a9842a50$fc8c7ef0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: Acna8UQGrgzYGcgMRLK6VKOJKU4GPAAA4SpwAAoiXVA= References: <4A15046C.5080600@rogers.com> <006701c9d9e9$51679500$f436bf00$%roni@huawei.com> <7779AD69A5E54F9F84E473BB4F4E1E71@china.huawei.com> <4A157ADA.8060900@rogers.com> <ybuljopyjto.fsf@jesup.eng.wgate.com> <3221EC0396044781B11D483B77E085A1@china.huawei.com> <ybuhbzdygly.fsf@jesup.eng.wgate.com> <939A5D7EEE0A410E867078A3117DD3CE@china.huawei.com> <ybuhbzdb1tr.fsf@jesup.eng.wgate.com> <0F4BC54357284559B31303B0D730F7E2@china.huawei.com> Cc: 'Tom Taylor' <tom.taylor@rogers.com>, 'IETF AVT WG' <avt@ietf.org> Subject: Re: [AVT] Consensus on profile-level-id in 3984bis X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group <avt.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/avt> List-Post: <mailto:avt@ietf.org> List-Help: <mailto:avt-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 22 May 2009 20:56:15 -0000 YK, I think you are right that we are now to the root of the discussion. The levels in H.264 annex A specify some compromise in order to allow mass production devices like set top boxes use fixed architecture for example in order to define the frame buffer size on the device and typically will not negotiate the level (mostly streaming applications). On the other side video conferencing systems have much more flexibility and control over the encoder since they are part of a system that considers also the display and network connection when they offer a specific level (which may be lower than the maximum that they can support). Having more control on the encoder allows them to get requests from the remote system to send pictures at specific resolutions and aspect ratios. I think I mentioned before that the offer can offer a low level and add capabilities using the optional parameters, this working point will be between two specified levels from table A-1, higher than the one in the offer but lower than the one above it. I think that in this case if the answer will include the higher level this will still work, and since the encoder is flexible it may take advantage of the new information. Roni -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ye-Kui Wang Sent: Friday, May 22, 2009 8:10 PM To: 'Randell Jesup' Cc: 'Tom Taylor'; 'IETF AVT WG' Subject: Re: [AVT] Consensus on profile-level-id in 3984bis I think the root of most of the disputes is, given a video encoder, whether you can label it with a max level. In theory, I think you are right that, given the computing resource of the encoder, it is possible to compromise among parameters. However, in practice, when you get an encoder product (which is typically optimized or even fixed for certain operating range), it would typically be labelled with a profile at a level, and it should not be common that users (of the encoder product) would try to compromise among parameters and see whether it can produce a bitstream with a higher level, and in many cases, the encoder product does not provide enough space for you play around this. The level labelled by the encoder manufacture is usually the max level. There are of course also purely PC software based encoders can be very flexible, and can be configured to be almost any profile and level. But once it is configured to be at a profile and a level and the encoder is initialized, then that level should be used as the max level. BR, YK > -----Original Message----- > From: Randell Jesup [mailto:rjesup@wgate.com] > Sent: Friday, May 22, 2009 11:22 AM > To: Ye-Kui Wang > Cc: 'Tom Taylor'; 'IETF AVT WG' > Subject: Re: [AVT] Consensus on profile-level-id in 3984bis > > Ye-Kui Wang <yekuiwang@huawei.com> writes: > >> Ye-Kui Wang <yekuiwang@huawei.com> writes: > >> >If the following are considered, then let the other side know the > >> >sending capability (as well as whether level upgrade is allowed) > >> >would be very useful. > >> > > >> >- One may want to request a specific mode, e.g. a spatial > >> >resolution, from the sender, for example by using image attribute > >> >mmusic draft. > >> > >> Does adding a max-send-level actually help you there? > > > >Yes. > > > >> How does this interact with how you decide what your max sending > >> level is? > > > >You don't decide your max sending level, your max sending > level is your > >max sending capability, a hard capability limit of you. > > Max capability for what/which? For all parameters simultaneously? > Maximum bitrate at maximum framesize at maximum > macroblocks/second, with maximum frame-to-frame motion, with > maximum motion-estimation-search, etc? > > I'm not saying you can't choose a maximum, but it's very, > very soft - very subjective because encoding is much more > variable (and expensive) than decoding. It's (much) easier > to estimate a worst-case for decode. > > >> As mentioned below, choosing a value for that (other than > basing it > >> on resolution alone, and that just might put a lower bound > on it) is > >> extremely subjective at best. > > > >Example: If one side lets the other side know its max sending > >capability, then the other side would not even try to request a > >specific capability that is impossible to be satisfied. > Otherwise, the > >other side may just send useless requests. > > > >> >- Video adaptation, in terms of bitrate, frame rate, > and/or spatial > >> >resolution etc, may happen during the session, and may be > initiated > >> >by either side. > >> > >> Again, how would this work in practice, and how would > adding it here > >> help? Adaptation within the negotiated limits can occur now, so I > >> don't see the advantage here. If you need to change the > maximum limits (why? > >> weren't they properly negotiated to start with?), then you can > >> re-invite. I think we need a concrete example, in order > to know if > >> what you're proposing is sufficient - or if it works. I'm quite > >> unclear on how you believe specifying a max send level will help > >> anything, since your list is quite vague. > >> > > > >Example > > > >The offerer does not tell the answerer its max sending capability, > >which is level B. A negotiation is done, where the answer includes > >level C (C>B), and the offerer starts to send at C (actually > B, but the > >answerer may not be sure). After a while, the answerer > senses that the > >connecting bandwidth is higher, and it wants to receive at a higher > >bitrate, which is still within the limit of level C, but above the > >limit of B, and sends a meaningless adaption request using re-invite. > > > >However, if the offerer does tell the answerer its max sending > >capability, such meaningless adaption requests are avoided. > I believe > >there are more examples, but I hope this already helps. > > That's a plausible case - thanks. However, I think you could > have an unintended result if you did that. Lets say that the > offerer uses the "worst-case" method to decide on a > max-send-level (per above). That level may be well below the > limits it could hit when it's not worst case - for example, > it may be constrained on framesize or MBPS to level 3.0, but > can handle the outgoing bandwidth of level 4.0, and level 5.0 > when other parameters aren't worst-case. By limiting to a > max-send-level of 3.0, the receiver won't request use of > extra bandwidth or 4.0 or 5.0. Note that even if you go and > duplicate all the max-* parameters as sprop-max-*, you still > wouldn't be able to handle the "I can do this when other > parameters are relaxed" case. > > I also already mentioned this problem below (repeated here): > >> >> The question is "is it worth it"? Also, while this may let you > >> >> limit resources, you may also limit the options of the sender. > >> >> For example, in the first case above, since A knows B > can receive > >> >> 5.0, A could send a higher frame size than 3.0 supports > (perhaps > >> >> at a lower framerate), even though A can't support > sending "full" level 3.1. > > I think you can handle the adaptation issue as part of the > adaptation design, since there may be other reasons the > offerer can't raise the bandwidth (or whatever). > > >BR, YK > > > > > >> >BR, YK > >> > > >> >> -----Original Message----- > >> >> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] > >> On Behalf Of > >> >> Randell Jesup > >> >> Sent: Thursday, May 21, 2009 10:04 PM > >> >> To: Tom Taylor > >> >> Cc: IETF AVT WG > >> >> Subject: Re: [AVT] Consensus on profile-level-id in 3984bis > >> >> > >> >> Tom Taylor <tom.taylor@rogers.com> writes: > >> >> >It appears that the optimum outcome is to be able to signal > >> >> both send > >> >> >and receive capability. The legacy approach loses some of this > >> >> >information, since profile-level-id contains the lesser > >> of the two > >> >> >values. In a legacy-new interworking situation it seems > >> >> unlikely that > >> >> >we can improve on this. > >> >> > >> >> Well, I'm not sure you can say that a legacy device > >> definitively uses > >> >> the lesser of send/receive in profile-level-id. Because > >> of the way > >> >> profile-level-id works, and how H.264 encodes streams, > there is no > >> >> problem with currently specifying a level above what you > >> can "truly" > >> >> support *sending*. I.e. you can say you can receive and > >> send level > >> >> 3.0 via profile-level-id, but nothing forces you to use > the full > >> >> limits of level 3.0 when sending. You can send a stream > >> that could > >> >> be encoded identically in level 2.0; you can even mark > it as level > >> >> 3.0 in the SPS/PPS NAL units. > >> >> > >> >> On the other side of the equation, it is the lesser - if > >> you can only > >> >> receive level 2.0 when all the limits in the received > stream are > >> >> maxed out, you can't use anything above level 2.0 in > >> >> profile-level-id. (You can > >> >> *extend* it (such as with max-fs), if you also agree to > decode the > >> >> extension as well.) > >> >> > >> >> Those are the *current* semantics of profile-level-id. > A legacy > >> >> device may (or may not) as mentioned over-state it's ability to > >> >> encode. > >> >> > >> >> You could use an parameter that specifies the max sending level > >> >> supported in an offer (there's no point in an answer I > >> believe). I > >> >> originally proposed this. However, on reflection, there's very > >> >> little if anything to gain from that that I can see. A > receiver > >> >> could respond to > >> >> level-upgrade-allowed=1 (or level-asymmetry-allowed=1) with the > >> >> highest level it can receive. Now each side knows the > >> highest level > >> >> the other can receive, and can send up to that level. The only > >> >> downside I can possibly think of to not knowing the > >> maximum sending > >> >> ability is that a receiver could perhaps not allocate as many > >> >> resources if it knew the offerer couldn't send above level N. > >> >> Example: > >> >> > >> >> A: Can receive level 2.0 (small LCD perhaps), can send level 3.0 > >> >> B: Can receive level 5.0, can send level 3.0 (more > common form of > >> >> send/recv > >> >> asymmetry) > >> >> > >> >> A offers to be with > >> profile-level-id=420014;level-asymmetry-allowed=1 > >> >> B answers with profile-level-id=420032 > >> >> > >> >> A will send at level 3.0 > >> >> B will send at level 2.0 (and must allocate resources to > >> potentially > >> >> receive 5.0) > >> >> > >> >> If you had a maximum-send-level parameter: > >> >> > >> >> A offers to be with profile-level-id=420014;sprop-max-level=1E > >> >> B answers with profile-level-id=42001E > >> >> > >> >> A will send at level 3.0 > >> >> B will send at level 2.0 (and only has to allocate > resources for > >> >> level 3.0) > >> >> > >> >> > >> >> The question is "is it worth it"? Also, while this may let you > >> >> limit resources, you may also limit the options of the sender. > >> >> For example, in the first case above, since A knows B > can receive > >> >> 5.0, A could send a higher frame size than 3.0 supports > (perhaps > >> >> at a lower framerate), even though A can't support > sending "full" level 3.1. > >> >> > >> >> I should also note that quantizing the maximum level > you can send > >> >> is VERY subjective/arbitrary, because of how the > encoding works. > >> >> See the discussion above about how you don't have to > max out the > >> >> level you're supposedly sending. > >> >> > >> >> So my suggestion is to use level-asymmetry-allowed. (See my > >> >> previous post for how this differs from > level-upgrade-allowed - it > >> >> allows asymmetric levels on level downgrade as well, which is > >> >> actually probably a more common case.) > >> >> > >> >> >That suggests that profile-level-id should retain its current > >> >> >semantics, and one or two new parameters (only one of > >> which would be > >> >> >present in the offer or answer) would indicate two things: > >> >> >a) a value which is higher than the value given in > >> profile-level-id; > >> >> >b) whether that value is a send or receive capability. > >> >> > > >> >> >If it's just one parameter, it would have to be double > >> valued e.g., > >> >> >alternate-level-id="send,<value>". > >> >> > > >> >> >If it is two parameters, the appropriate parameter to > >> include would > >> >> >depend on which whether the capability being reported > is send or > >> >> >receive, e.g., send-level-id=<value> > >> >> >or recv-level-id=<value > >> >> >but never both in the same stream. > >> >> > > >> >> >Ye-Kui Wang wrote: > >> >> >> Another interoperability issue relates to the semantics > >> >> change of the > >> >> >> level part of profile-level-id. Currently, the level part, > >> >> when used > >> >> >> capability exchange or session setup, gives the upper > >> >> limit of both > >> >> >> decoding capability and encoding capability, as seen > from the > >> >> >> following two paragraphs excerpted from the bis draft (the > >> >> same in spirit in 3984): > >> >> >> > >> >> >> "The profile-level-id parameter indicates the default > >> sub-profile, > >> >> >> i.e. the subset of coding tools that may have been used to > >> >> generate > >> >> >> the stream or that the receiver supports, and the > >> default level of > >> >> >> the stream or the receiver supports." > >> >> >> > >> >> >> "If the profile-level-id parameter is used for capability > >> >> exchange or > >> >> >> session setup procedure, it indicates the subset of > >> coding tools, > >> >> >> which is equal to the default sub-profile, and the > >> highest level, > >> >> >> which is equal to the default level, that the codec > >> supports. All > >> >> >> levels lower than the default level are also supported by > >> >> the codec. " > >> >> >> > >> >> >> When level upgrade is allowed, then this semantics must > >> >> change, such > >> >> >> that the level part basically indicates only the decoding > >> >> capability. > >> >> >> This change of course creates different understandings > >> between the > >> >> >> two sides whenever one is legacy and the other is new. > >> >> >> > >> >> >> We have at least the following options to go to > allow for level > >> >> >> upgrade (the semantics change above is anyway > needed): - To add > >> >> >> "level-upgrade-allowed". - To add "level-upgrade-allowed" > >> >> and another > >> >> >> parameter, say sending-capability-level, to indicate > >> the sending > >> >> >> capability expressed as a level value. - To go wildly, by > >> >> making all > >> >> >> paramters not starting with "sprop-" as receiving > capabilities. > >> >> >> Another group of parameters not starting with > "sprop-" can be > >> >> >> optionally used to indicate sending capabilities. When > >> >> these sending > >> >> >> capability parameters are not present, the sending > >> >> capabilities are > >> >> >> by default equal to the receiving capabilties. > >> >> >> > >> >> >> A decision needs to be made which one to take. > >> >> >> > >> >> >> In any case, I hope a proponent could provide relatively > >> >> mature text, > >> >> >> including changes to semantics, offer/answer rules > (including > >> >> >> parameter sets considerations in offer/answer), > >> declarative usage, > >> >> >> SDP examples, and discussion of backward > compatibility issues. > >> >> >> > >> >> >> Note that all the changes will also affect the SVC payload > >> >> draft, as > >> >> >> they basically need to be appropriately integrated to the > >> >> SVC payload draft. > >> >> >> > >> >> >> BR, YK > >> >> >> > >> >> >... > >> >> >_______________________________________________ > >> >> >Audio/Video Transport Working Group avt@ietf.org > >> >> >https://www.ietf.org/mailman/listinfo/avt > >> >> > >> >> > >> >> -- > >> >> Randell Jesup, Worldgate (developers of the Ojo > >> videophone), ex-Amiga > >> >> OS team rjesup@wgate.com "The fetters imposed on liberty > >> at home have > >> >> ever been forged out of the weapons provided for > defence against > >> >> real, pretended, or imaginary dangers from abroad." > >> >> - James Madison, 4th US president (1751-1836) > >> >> > >> >> _______________________________________________ > >> >> Audio/Video Transport Working Group avt@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/avt > >> >> > >> > >> > >> -- > >> Randell Jesup, Worldgate (developers of the Ojo > videophone), ex-Amiga > >> OS team rjesup@wgate.com "The fetters imposed on liberty > at home have > >> ever been forged out of the weapons provided for defence against > >> real, pretended, or imaginary dangers from abroad." > >> - James Madison, 4th US president (1751-1836) > >> > >> > > > -- > Randell Jesup, Worldgate (developers of the Ojo videophone), > ex-Amiga OS team > rjesup@wgate.com > "The fetters imposed on liberty at home have ever been forged > out of the weapons > provided for defence against real, pretended, or imaginary > dangers from abroad." > - James Madison, 4th US president (1751-1836) > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www.ietf.org/mailman/listinfo/avt From luby@qualcomm.com Fri May 22 14:03:22 2009 Return-Path: <luby@qualcomm.com> X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9650E3A68D9 for <avt@core3.amsl.com>; Fri, 22 May 2009 14:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.421 X-Spam-Level: X-Spam-Status: No, score=-105.421 tagged_above=-999 required=5 tests=[AWL=1.177, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PVUq-yB4lRUY for <avt@core3.amsl.com>; Fri, 22 May 2009 14:03:16 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 0ACB13A6A29 for <avt@ietf.org>; Fri, 22 May 2009 14:03:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=luby@qualcomm.com; q=dns/txt; s=qcdkim; t=1243026295; x=1274562295; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:mime-version:x-ironport-av; z=From:=20"Luby,=20Michael"=20<luby@qualcomm.com>|To:=20Jo hn=20Lazzaro=20<john.lazzaro@gmail.com>,=20"avt@ietf.org" =20<avt@ietf.org>|CC:=20"Luby,=20Michael"=20<luby@qualcom m.com>|Date:=20Fri,=2022=20May=202009=2014:04:44=20-0700 |Subject:=20Re:=20[AVT]=20Comments=20on=20draft-pantos-ht tp-live-streaming-00.txt=20...|Thread-Topic:=20[AVT]=20Co mments=20on=20draft-pantos-http-live-streaming-00.txt=20. ..|Thread-Index:=20AcnbDsip++T2F1csSdSDbo38LBx9/gAEiWik |Message-ID:=20<C63C617C.372F%luby@qualcomm.com> |In-Reply-To:=20<302f570905221154t7feb4162s6728f9dc2c7365 92@mail.gmail.com>|Accept-Language:=20en-US |Content-Language:=20en|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20multipart/alternative=3B=0D=0A=09boundar y=3D"_000_C63C617C372Flubyqualcommcom_"|MIME-Version:=201 .0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5623"=3B =20a=3D"18509991"; bh=DSJwoFGZI/ubduGBdFF22svuYJXmBKVazShq2aiMhmI=; b=qJxDEOop1dJkLykU8MTQiE6WhASbGlFp8TtaAQo8/f+rq/46WwEAaiXR dFe6Uk6EZDm+RYoJZwsbRxXtsnVnlcngjulSd43oqsVVcYTJTENAkZj/B AOIVC29c9QjoNPwyo6UpSpQkoeqCgSZfHCLcaqDjM5j0O6bRzJDRGU32H 4=; X-IronPort-AV: E=McAfee;i="5300,2777,5623"; a="18509991" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 May 2009 14:04:49 -0700 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n4ML4n90022608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 22 May 2009 14:04:49 -0700 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n4ML4mbF025127 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 22 May 2009 14:04:48 -0700 Received: from nasclexhc01.na.qualcomm.com (10.227.147.14) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.1.358.0; Fri, 22 May 2009 14:04:48 -0700 Received: from NASCLEXMB02.na.qualcomm.com ([10.227.144.113]) by nasclexhc01.na.qualcomm.com ([10.227.147.14]) with mapi; Fri, 22 May 2009 14:04:47 -0700 From: "Luby, Michael" <luby@qualcomm.com> To: John Lazzaro <john.lazzaro@gmail.com>, "avt@ietf.org" <avt@ietf.org> Date: Fri, 22 May 2009 14:04:44 -0700 Thread-Topic: [AVT] Comments on draft-pantos-http-live-streaming-00.txt ... Thread-Index: AcnbDsip++T2F1csSdSDbo38LBx9/gAEiWik Message-ID: <C63C617C.372F%luby@qualcomm.com> In-Reply-To: <302f570905221154t7feb4162s6728f9dc2c736592@mail.gmail.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C63C617C372Flubyqualcommcom_" MIME-Version: 1.0 Subject: Re: [AVT] Comments on draft-pantos-http-live-streaming-00.txt ... X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group <avt.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/avt> List-Post: <mailto:avt@ietf.org> List-Help: <mailto:avt-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 22 May 2009 21:03:22 -0000 --_000_C63C617C372Flubyqualcommcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >From my limited understanding of Ajax (and it is very limited, believe me),= it isn't audio/video specific, i.e., it doesn't specify video codecs to be= supported, or video file delivery formats, or describe relationships betwe= en video/audio encoding streams that are required in order to do seamless s= tream transitions, as examples. It seems that Ajax is possibly one of seve= ral ways that one might develop a client to support the functionality, but = it is not streaming specific. I guess it boils down to what is trying to be standardized. If it is a gen= eral method for allowing the proposal to be implemented, then Ajax might be= the answer. If it is instead a standardized way to allow interoperable im= plementations of the proposal by different vendors/actors, i.e., different = content providers use the proposal to prepare their video content for distr= ibution, it is uploaded into and distributed using standard servers, and di= fferent clients written by different parties that implement the proposal ca= n all play out the content, then one would need to specify the range of vid= eo and file formats supported, the metadata video file formats, the relatio= nships between the files for the different video streaming rates, the const= raints on the encoding of those video streams and formatting into files, et= c. Ajax might also be useful in this second case, but I don't think you wo= uld want to standardize all the things that would need to be standardized w= ithin an Ajax setting, as the standardization seems quite video specific, a= nd perhaps it would make more sense to do this type of video-specific audio= /video standardization in the AVT group. On 5/22/09 11:54 AM, "John Lazzaro" <john.lazzaro@gmail.com> wrote: On Fri, May 22, 2009 at 10:20 AM, Luby, Michael <luby@qualcomm.com> wrote: > Now, when I say this same approach, I mean that it can accommodate the > following: > > (A) Able to use standard servers (or cheap servers in general) to deliver > the content, so that it can be delivered from a CDN or any other standard > server farm. > (B) Real-time or Video-on demand streaming. > (C) Fast channel change and seek times, i.e., good responsiveness to user > ADD. > (D) Able to automatically choose the initial streaming rate to match the > initial available bandwidth. > (E) Able to seamlessly change streaming rate on the fly in reaction to > changes in available bandwidth, even within a given content. > (F) Able to penetrate firewalls and NATS. [...] > With respect to Ajax, it might help with some support for this approach i= n > the client browser, and thus might be complementary to the proposal, but > alone does not meet the requirements. Given the right set of client browser primitives, could be be more specific about which of your A-F requirements an AJAX approach could not meet, and why? -- John Lazzaro http://www.cs.berkeley.edu/~lazzaro john [dot] lazzaro [at] gmail [dot] com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www.ietf.org/mailman/listinfo/avt --_000_C63C617C372Flubyqualcommcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <HTML> <HEAD> <TITLE>Re: [AVT] Comments on draft-pantos-http-live-streaming-00.txt ...</T= ITLE> </HEAD> <BODY> <FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:= 11pt'>From my limited understanding of Ajax (and it is very limited, believ= e me), it isn’t audio/video specific, i.e., it doesn’t specify = video codecs to be supported, or video file delivery formats, or describe r= elationships between video/audio encoding streams that are required in orde= r to do seamless stream transitions, as examples.  It seems that Ajax = is possibly one of several ways that one might develop a client to support = the functionality, but it is not streaming specific.<BR> <BR> I guess it boils down to what is trying to be standardized.  If it is = a general method for allowing the proposal to be implemented, then Ajax mig= ht be the answer.  If it is instead a standardized way to allow intero= perable implementations of the proposal by different vendors/actors, i.e., = different content providers use the proposal to prepare their video content= for distribution, it is uploaded into and distributed using standard serve= rs, and different clients written by different parties that implement the p= roposal can all play out the content, then one would need to specify the ra= nge of video and file formats supported, the metadata video file formats, t= he relationships between the files for the different video streaming rates,= the constraints on the encoding of those video streams and formatting into= files, etc.  Ajax might also be useful in this second case, but I don= ’t think you would want to standardize all the things that would need= to be standardized within an Ajax setting, as the standardization seems qu= ite video specific, and perhaps it would make more sense to do this type of= video-specific audio/video standardization in the AVT group. <BR> <BR> <BR> On 5/22/09 11:54 AM, "John Lazzaro" <<a href=3D"john.lazzaro@g= mail.com">john.lazzaro@gmail.com</a>> wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"= ><SPAN STYLE=3D'font-size:11pt'>On Fri, May 22, 2009 at 10:20 AM, Luby, Mic= hael <<a href=3D"luby@qualcomm.com">luby@qualcomm.com</a>> wrote:<BR> > Now, when I say this same approach, I mean that it can accommodate the= <BR> > following:<BR> ><BR> > (A) Able to use standard servers (or cheap servers in general) to deli= ver<BR> > the content, so that it can be delivered from a CDN or any other stand= ard<BR> > server farm.<BR> > (B) Real-time or Video-on demand streaming.<BR> > (C) Fast channel change and seek times, i.e., good responsiveness to u= ser<BR> > ADD.<BR> > (D) Able to automatically choose the initial streaming rate to match t= he<BR> > initial available bandwidth.<BR> > (E) Able to seamlessly change streaming rate on the fly in reaction to= <BR> > changes in available bandwidth, even within a given content.<BR> > (F) Able to penetrate firewalls and NATS.<BR> <BR> [...]<BR> <BR> > With respect to Ajax, it might help with some support for this approac= h in<BR> > the client browser, and thus might be complementary to the proposal, b= ut<BR> > alone does not meet the requirements.<BR> <BR> Given the right set of client browser primitives, could be be more specific= <BR> about which of your A-F requirements an AJAX approach could not meet,<BR> and why?<BR> <BR> --<BR> John Lazzaro<BR> <a href=3D"http://www.cs.berkeley.edu/~lazzaro">http://www.cs.berkeley.edu/= ~lazzaro</a><BR> john [dot] lazzaro [at] gmail [dot] com<BR> _______________________________________________<BR> Audio/Video Transport Working Group<BR> <a href=3D"avt@ietf.org">avt@ietf.org</a><BR> <a href=3D"https://www.ietf.org/mailman/listinfo/avt">https://www.ietf.org/= mailman/listinfo/avt</a><BR> <BR> </SPAN></FONT></BLOCKQUOTE> </BODY> </HTML> --_000_C63C617C372Flubyqualcommcom_-- From john.lazzaro@gmail.com Fri May 22 14:49:23 2009 Return-Path: <john.lazzaro@gmail.com> X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BD033A6FAE for <avt@core3.amsl.com>; Fri, 22 May 2009 14:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K9ixd2i6JALW for <avt@core3.amsl.com>; Fri, 22 May 2009 14:49:16 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.245]) by core3.amsl.com (Postfix) with ESMTP id 944E23A6AE6 for <avt@ietf.org>; Fri, 22 May 2009 14:49:16 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id c3so1496811ana.4 for <avt@ietf.org>; Fri, 22 May 2009 14:50:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=3y+cPii6fx7fZsx45oWsCL06kgVggFlZGM7QylXsjYI=; b=eCP2DDMnM/DeMcrsVG+8bcZ9Dg/Dtfcnx6jPh7nOETaPKc5gG+BIIK7QQni3QT4Zp5 uFB0RcakHDm+0C3LYKAKHQZzzXYuAmx3Z604GLXelqqV/ZKjTVg3n+hv1nShs/A7ZeRZ NfW2IJqC7UAQNsB0WJ82vZk9eIdKhuKubr3kk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=QVu7nL07YJz1ZqqMsgObkEcCHINQNY3+m8oozu/BrYdzLZ8wAKOaQ21O821ueLJoip P+EPur39IGK8YLgfooNhU23JmbMzwAvT6OzyvNTTo/M5c53CDPjZ7jlvOwA6CxE0itlF zxi4N+8NOBJ9uBM65+uS9BT5wBeLdyMlNd+oE= MIME-Version: 1.0 Received: by 10.100.152.12 with SMTP id z12mr8451141and.96.1243029053193; Fri, 22 May 2009 14:50:53 -0700 (PDT) In-Reply-To: <C63C617C.372F%luby@qualcomm.com> References: <302f570905221154t7feb4162s6728f9dc2c736592@mail.gmail.com> <C63C617C.372F%luby@qualcomm.com> Date: Fri, 22 May 2009 14:50:53 -0700 Message-ID: <302f570905221450q1a52cb9o5fd8216332c598a5@mail.gmail.com> From: John Lazzaro <john.lazzaro@gmail.com> To: "avt@ietf.org" <avt@ietf.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [AVT] Comments on draft-pantos-http-live-streaming-00.txt ... X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group <avt.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/avt> List-Post: <mailto:avt@ietf.org> List-Help: <mailto:avt-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 22 May 2009 21:49:23 -0000 On Fri, May 22, 2009 at 2:04 PM, Luby, Michael <luby@qualcomm.com> wrote: > I guess it boils down to what is trying to be standardized. =A0If it is a > general method for allowing the proposal to be implemented, then Ajax mig= ht > be the answer. =A0If it is instead a standardized way to allow interopera= ble > implementations of the proposal by different vendors/actors [...] Thanks. I believe that one step in reaching a decision on moving forward o= n draft-pantos-http-live-streaming-00.txt is to get group consensus what we should be "trying to standardize" in this domain, given the choices you define in the quote above. --=20 John Lazzaro http://www.cs.berkeley.edu/~lazzaro john [dot] lazzaro [at] gmail [dot] com From gherlein@herlein.com Fri May 22 14:49:54 2009 Return-Path: <gherlein@herlein.com> X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B86A63A6947 for <avt@core3.amsl.com>; Fri, 22 May 2009 14:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.833 X-Spam-Level: X-Spam-Status: No, score=-0.833 tagged_above=-999 required=5 tests=[AWL=-0.661, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZE36ghsbSRB9 for <avt@core3.amsl.com>; Fri, 22 May 2009 14:49:47 -0700 (PDT) Received: from mail-px0-f193.google.com (mail-px0-f193.google.com [209.85.216.193]) by core3.amsl.com (Postfix) with ESMTP id 40E293A6E68 for <avt@ietf.org>; Fri, 22 May 2009 14:49:46 -0700 (PDT) Received: by pxi31 with SMTP id 31so1704490pxi.29 for <avt@ietf.org>; Fri, 22 May 2009 14:51:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.50.6 with SMTP id x6mr1632107wfx.195.1243029079578; Fri, 22 May 2009 14:51:19 -0700 (PDT) In-Reply-To: <C63C617C.372F%luby@qualcomm.com> References: <302f570905221154t7feb4162s6728f9dc2c736592@mail.gmail.com> <C63C617C.372F%luby@qualcomm.com> Date: Fri, 22 May 2009 14:51:19 -0700 Message-ID: <31d1be720905221451t844a033ufe37b44884b56f83@mail.gmail.com> From: Greg Herlein <gherlein@herlein.com> To: "avt@ietf.org" <avt@ietf.org> Content-Type: multipart/alternative; boundary=000e0cd1a676bbd9e1046a8742c2 Subject: Re: [AVT] Comments on draft-pantos-http-live-streaming-00.txt ... X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group <avt.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/avt> List-Post: <mailto:avt@ietf.org> List-Help: <mailto:avt-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 22 May 2009 21:49:54 -0000 --000e0cd1a676bbd9e1046a8742c2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit AJAX is probably not relevant to this conversation. AJAX is a technique to poll a server and dynamically update a web page without a full page refresh. Some aspects of AJAX are potentially applicable - like HTTP polling, perhaps getting XML documents back with metadata/instructions, etc. I think if the media is being consumed in a browser then you want these polls to happen in the background so you can make sure you have media queued so that playback is seamless. If I understand it, the objective of this effort is to leverage the web server infrastructure that is already understood and deployed in a way that can transport video. The core use case is a desire to have some video source (which may be psuedo-live or recorded) and deliver it to thousands or millions of users over the existing internet. The desire is to design a protocol that can operate on the traditional port 80 infrastructure in such a way that caching and CDN technology can scale the traffic. Trick play and all playback is handled in the client and is outside the scope of the protocol. If I am correct, is there actually any need for a playlist? I would suggest that all that is needed in a HTTP reply is the URI that will hold the next chunk of media and perhaps a time that the URIl will become active. The client could then invoke the logic to go get that URI at the appropriate time. In fact, this is looking less and less to me like a protocol and more and more like a REST API for a given video service. I'll have to read the doc again to see what kinds of special caching instructions might be needed. I skimmed that part on my earlier read. Thoughts? -- Greg Herlein www.herlein.com --000e0cd1a676bbd9e1046a8742c2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable AJAX is probably not relevant to this conversation.=A0 AJAX is a technique = to poll a server and dynamically update a web page without a full page refr= esh.=A0 Some aspects of AJAX are potentially applicable - like HTTP polling= , perhaps getting XML documents back with metadata/instructions, etc.=A0 I = think if the media is being consumed in a browser then you want these polls= to happen in the background so you can make sure you have media queued so = that playback is seamless.<br> <br>If I understand it, the objective of this effort is to leverage the web= server infrastructure that is already understood and deployed in a way tha= t can transport video.=A0 The core use case is a desire to have some video = source (which may be psuedo-live or recorded) and deliver it to thousands o= r millions of users over the existing internet.=A0=A0 The desire is to desi= gn a protocol that can operate on the traditional port 80 infrastructure in= such a way that caching and CDN technology can scale the traffic.=A0 Trick= play and all playback is handled in the client and is outside the scope of= the protocol.=A0 <br> <br>If I am correct, is there actually any need for a playlist?=A0 I would = suggest that all that is needed in a HTTP reply is the URI that will hold t= he next chunk of media and perhaps a time that the URIl will become active.= =A0 The client could then invoke the logic to go get that URI at the approp= riate time.=A0 In fact, this is looking less and less to me like a protocol= and more and more like a REST API for a given video service.=A0 I'll h= ave to read the doc again to see what kinds of special caching instructions= might be needed.=A0 I skimmed that part on my earlier read.<br> <br>Thoughts?<br clear=3D"all"><br>-- <br>Greg Herlein<br><a href=3D"http:/= /www.herlein.com">www.herlein.com</a><br> --000e0cd1a676bbd9e1046a8742c2-- From john.lazzaro@gmail.com Fri May 22 15:06:55 2009 Return-Path: <john.lazzaro@gmail.com> X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 671B63A6F25 for <avt@core3.amsl.com>; Fri, 22 May 2009 15:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8Fhj1btVo3D for <avt@core3.amsl.com>; Fri, 22 May 2009 15:06:54 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.244]) by core3.amsl.com (Postfix) with ESMTP id 60D553A6F23 for <avt@ietf.org>; Fri, 22 May 2009 15:06:54 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id c3so1503077ana.4 for <avt@ietf.org>; Fri, 22 May 2009 15:08:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=P9d8Zo30ySRQHKK7gO34ZNe6Ma+KNG7Kqqszys7r7rA=; b=NTMl7OdbbImIPR2OqM4heBWuNd/TMcterN9vJpAH1MgjOsMysjUPEeOPc3cKr+gInP 9n1EonEKNtswlUjCoRdn6owpls5L/n+gugIz/ldESvnwdwtb0Ta83+HXHOld9pXTeOmF DlTwUsGs5xprMwoVernuAQLbIZ5mAc2C4Olno= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=CmF56iw9NbXk9U7XJVn93VRALFILxgjkTVyDKHbmS27DlYoubp9X4Eh1yphZ9uUOQo f/CNnBp0m6xQj5hDOhm/kV5wKC//XA8CRYEZ4o9XxbQbmghn7e5VhexrftvfN/t26R1l xe3uX4zy7DjBFl5VXdkXZlYnfPx68ylkHs01k= MIME-Version: 1.0 Received: by 10.100.13.2 with SMTP id 2mr8199744anm.132.1243030110884; Fri, 22 May 2009 15:08:30 -0700 (PDT) In-Reply-To: <31d1be720905221451t844a033ufe37b44884b56f83@mail.gmail.com> References: <302f570905221154t7feb4162s6728f9dc2c736592@mail.gmail.com> <C63C617C.372F%luby@qualcomm.com> <31d1be720905221451t844a033ufe37b44884b56f83@mail.gmail.com> Date: Fri, 22 May 2009 15:08:30 -0700 Message-ID: <302f570905221508q637770ebi89582187526d1594@mail.gmail.com> From: John Lazzaro <john.lazzaro@gmail.com> To: "avt@ietf.org" <avt@ietf.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [AVT] Comments on draft-pantos-http-live-streaming-00.txt ... X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group <avt.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/avt> List-Post: <mailto:avt@ietf.org> List-Help: <mailto:avt-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 22 May 2009 22:06:55 -0000 On Fri, May 22, 2009 at 2:51 PM, Greg Herlein <gherlein@herlein.com> wrote: > AJAX is probably not relevant to this conversation.=A0 AJAX is a techniqu= e to > poll a server and dynamically update a web page without a full page > refresh.=A0 Some aspects of AJAX are potentially applicable - like HTTP > polling, perhaps getting XML documents back with metadata/instructions, > etc.=A0 I think if the media is being consumed in a browser then you want > these polls to happen in the background so you can make sure you have med= ia > queued so that playback is seamless. >From the audio perspective, the last sentence may be a missing piece of the puzzle at the moment -- letting Javascript control the audio output queue in a flexible way to provide artifact-free concatenation of the small audio files that are be= ing downloaded in the background. It's taking what we've learned about creatin= g audio APIs for operating systems over the past few decades, and adapting it to the higher-latency world of scripting languages. --=20 John Lazzaro http://www.cs.berkeley.edu/~lazzaro john [dot] lazzaro [at] gmail [dot] com From abegen@cisco.com Fri May 22 17:25:07 2009 Return-Path: <abegen@cisco.com> X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E7503A6AF5 for <avt@core3.amsl.com>; Fri, 22 May 2009 17:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.906 X-Spam-Level: X-Spam-Status: No, score=-4.906 tagged_above=-999 required=5 tests=[AWL=-1.307, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kfSli+ASgNTr for <avt@core3.amsl.com>; Fri, 22 May 2009 17:25:04 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 886543A68A1 for <avt@ietf.org>; Fri, 22 May 2009 17:25:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,235,1241395200"; d="scan'208";a="168604108" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 23 May 2009 00:26:43 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n4N0QhKs014144; Fri, 22 May 2009 17:26:43 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n4N0QhbA017562; Sat, 23 May 2009 00:26:43 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 May 2009 17:26:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Fri, 22 May 2009 17:26:36 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54095E18BB@xmb-sjc-215.amer.cisco.com> In-Reply-To: <1FEB9B9F2EC38343955D02B2AE86AACB011BF41B@lan-ex-02.panasonic.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available Thread-Index: AcnaYqqjHO1LimacStOS+9HZ8wJeMAADPRKQABOigeAADM4YEA== References: <81B9B88E2F9D574AA5328A85547CDE9101071D80@xmb-rtp-21d.amer.cisco.com> <49f1a1d6.190c660a.58fe.ffffa90e@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C80DA@xmb-sjc-215.amer.cisco.com> <49f208e8.05a0660a.5bd2.6764@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C81C9@xmb-sjc-215.amer.cisco.com> <49f211fc.07a5660a.3f7f.ffff8f4a@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8202@xmb-sjc-215.amer.cisco.com> <49f2efa2.1c215e0a.4454.ffffaf91@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8403@xmb-sjc-215.amer.cisco.com> <49f36ee2.0437560a.11df.1eef@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8405@xmb-sjc-215.amer.cisco.com> <49f387ca.0305560a.6657.4be7@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C840A@xmb-sjc-215.amer.cisco.com> <4A15D40E.80509@eu.panasonic.com> <04CAD96D4C5A3D48B1919248A8FE0D54095E153A@xmb-sjc-215.amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB011BF41B@lan-ex-02.panasonic.de> From: "Ali C. Begen (abegen)" <abegen@cisco.com> To: "Jose Rey" <Jose.Rey@eu.panasonic.com> X-OriginalArrivalTime: 23 May 2009 00:26:43.0743 (UTC) FILETIME=[263782F0:01C9DB3D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=19136; t=1243038403; x=1243902403; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20<abegen@cisco. com> |Subject:=20RE=3A=20[AVT]=20New=20draft=20of=20=22Rapid=20A cquisition=20of=20Multicast=09RTPSessions=20(RAMS)=22=20avai lable |Sender:=20; bh=S9ZNTIZN2h3UzmGcid1FG6s+tDx3+I1umvp8sH2w4RE=; b=1TyRrF81fairTB0srywcYoPqn/l926Qa2Y/YioSbk4mEVbN/dp7Rd+/8D6 UfPLpDrirVrvJkSY1ut9TLfqzdsa2UZy6fBULbbr5Crn28bK8fdWEmRwsjkx hdQAvVQuIO; Authentication-Results: sj-dkim-2; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: Roni Even <ron.even.tlv@gmail.com>, avt@ietf.org, "Bill Ver Steeg \(versteb\)" <versteb@cisco.com> Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group <avt.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/avt> List-Post: <mailto:avt@ietf.org> List-Help: <mailto:avt-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 23 May 2009 00:25:07 -0000 Hi Jose, Indeed, RAMS-R goes to the FT of the new primary session that RR is = interested in acquiring rapidly. Then the unicast session becomes alive = and RS sends RAMS-I message(s) to RR on the RTCP port for the unicast = session. After some time, RR sends the RAMS-T message to the RTCP port = for the unicast session since it is supposed to end the unicast session. = -acbegen > -----Original Message----- > From: Jose Rey [mailto:Jose.Rey@eu.panasonic.com] > Sent: Friday, May 22, 2009 7:09 AM > To: Ali C. Begen (abegen) > Cc: Roni Even; avt@ietf.org; Bill Ver Steeg (versteb) > Subject: RE: [AVT] New draft of "Rapid Acquisition of Multicast = RTPSessions (RAMS)" > available >=20 >=20 > Hi Ali, >=20 > > > > Hi Jose, > > > > We have separate RTCP ports for the SSM session and the > > unicast session. Why is it a problem? >=20 > In line 19 you say you specify the dst port for RMS-I (41003), on RR. = And you say that > would also be the port where the RR sends RMS-T, on RS. That is mixing = the semantics of > a=3Drtcp for SSM (listening port at Feedback Target =3D mcast RTCP dst = port) and those of RFC > 3605 (dst port). In other words, you are implicitly assuming that = specifies symmetric > RTCP...no? >=20 > Another thing that was mentioned already: RMS-T is not sent to same = port as RMS-R; is it > not the same RTCP session ? Or is this muxing desired? why? >=20 > JLR >=20 > > > > The slightly modified SDP for the next version is below: > > > 1> a=3Dgroup:FID 3 4 > 2> a=3Drtcp-unicast:rsi > 3> m=3Dvideo 41000 RTP/AVPF 98 > 4> i=3DPrimary Multicast Stream #2 > 5> c=3DIN IP4 233.252.0.2/255 > 6> a=3Dsource-filter: incl IN IP4 233.252.0.2 192.0.2.2 > 7> a=3Drecvonly > 8> a=3Drtpmap:98 MP2T/90000 > 9> a=3Drtcp:41001 IN IP4 192.0.2.1 > 10> a=3Drtcp-fb:98 nack > 11> a=3Drtcp-fb:98 nack ssli > 12> a=3Dssrc:123321 cname:iptv-ch32@rams.example.com > 13> a=3Dmid:3 > 14> m=3Dvideo 41002 RTP/AVPF 99 > 15> i=3DUnicast Retransmission Stream #2 (Ret. and Rapid > > Acq. Support) > 16> c=3DIN IP4 192.0.2.1 > 17> a=3Drecvonly > 18> a=3Drtpmap:99 rtx/90000 > 19> a=3Drtcp:41003 > 20> a=3Dfmtp:99 apt=3D98; rtx-time=3D5000 > 21> a=3Dmid:4 > > > > This is the SDP we send to RR. For RS, a=3Drecvonly will be = a=3Dsendonly. > > > > -acbegen > > > > > > > -----Original Message----- > > > From: Jos=E9 Rey [mailto:jose.rey@eu.panasonic.com] > > > Sent: Thursday, May 21, 2009 3:22 PM > > > To: Ali C. Begen (abegen) > > > Cc: Roni Even; avt@ietf.org; Bill Ver Steeg (versteb) > > > Subject: Re: [AVT] New draft of "Rapid Acquisition of > > Multicast RTPSessions (RAMS)" > > > available > > > > > > Hi all, > > > > > > sorry for jumping in.... > > > > > > I think one of the sources of confusion is that the > > attribute a=3Drtcp: > > > is used once for specifying the destination port and once for > > > specifying a receiving port, and in the same SDP (!). The > > destination > > > port for RAMS-I packets sent by RS and the receiving port > > for RAMS-T. Which is also why different port numbers are used > > for RAMS-T and -R packets. > > > > > > I think the use of a=3Drtcp: in SSM is the problem here. Or the = fact > > > that we are mixing unicast and multicast, or both. > > > > > > Hope this helps, > > > > > > JLR > > > > > > > > > > > > > > > Ali C. Begen (abegen) wrote: > > > > > > > > > > > > > > > > > > -----Original Message----- > > > From: Roni Even [mailto:ron.even.tlv@gmail.com] > > > Sent: Saturday, April 25, 2009 2:58 PM > > > To: Ali C. Begen (abegen); avt@ietf.org > > > Cc: Bill Ver Steeg (versteb) > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of > > > Multicast RTPSessions (RAMS)" available > > > > > > Ali, > > > I looked at RFC 4570 and I assume that port > > 41001 is the port for the > > > unicast RTCP reports from the receivers and according to > > > > > > > > > > > > Yes, indeed. > > > > > > > > > > > > section 3.2.1 of > > > that RFC you also should have a RTCP-unicast > > specification. > > > This is for the > > > multicast receiver reports. > > > > > > > > > > > > Correct. We do have that line in our draft at the top > > right after the grouping lines: > > > > > > a=3Drtcp-unicast:rsi > > > > > > BR, > > > -acbegen > > > > > > > > > > > > Roni > > > > > > -----Original Message----- > > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > > Sent: Saturday, April 25, 2009 11:30 PM > > > To: Roni Even; avt@ietf.org > > > Cc: Bill Ver Steeg (versteb) > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of > > > Multicast RTPSessions > > > (RAMS)" available > > > > > > Here is the SDP. > > > > > > m=3Dvideo 41000 RTP/AVPF 98 > > > i=3DPrimary Multicast Stream #2 > > > c=3DIN IP4 224.1.1.2/255 > > > a=3Dsource-filter: incl IN IP4 224.1.1.2 192.0.2.2 > > > > > > Source (192.0.2.2) sends the rtp packets to the > > multicast > > > group (224.1.1.2) > > > with a dest port 41000. > > > > > > a=3Drtpmap:98 MP2T/90000 > > > a=3Drtcp:41001 IN IP4 192.0.2.1 > > > > > > The feedback target (RS) address for this SSM session is > > > 192.0.2.1 and its > > > port is 41001. This is the address/port where > > RR sends the RAMS-R, or > > > receiver reports for the SSM session. > > > > > > a=3Drtcp-fb:98 nack > > > a=3Drtcp-fb:98 nack ssli > > > a=3Dssrc:123321 cname:iptv-ch32@rams.example.com > > > a=3Dmid:3 > > > m=3Dvideo 41002 RTP/AVPF 99 > > > > > > The retransmission packets go to port 41002. > > This is the port > > > RRs listen to > > > for retransmission and RAMS. > > > > > > i=3DUnicast Retransmission Stream #2 > > (Ret. and Rapid > > > Acq. Support) > > > c=3DIN IP4 192.0.2.1 > > > > > > This is where the retransmission packets come > > from, same as > > > the feedback > > > target (in this example). > > > > > > a=3Drtpmap:99 rtx/90000 > > > a=3Drtcp:41003 > > > > > > This is where the RTCP packets for the > > retransmission session go. For > > > example, RAMS-I goes to this port on RRs. > > RAMS-T goes to this > > > port on RS. > > > > > > a=3Dfmtp:99 apt=3D98; rtx-time=3D5000 > > > a=3Dmid:4 > > > > > > > > > -acbegen > > > > > > > > > > > > > > > -----Original Message----- > > > From: Roni Even [mailto:ron.even.tlv@gmail.com] > > > Sent: Saturday, April 25, 2009 1:11 PM > > > To: Ali C. Begen (abegen); avt@ietf.org > > > Cc: Bill Ver Steeg (versteb) > > > Subject: RE: [AVT] New draft of "Rapid > > Acquisition of > > > Multicast RTPSessions (RAMS)" available > > > > > > Ali, > > > Can you please write three addresses > > from this strange SDP. > > > > > > 1. The address and port of multicast > > > > > > 2. The address and port of the RS where > > the RTCP FB should go to > > > > > > 3. The address and port on the RR where > > the unicast stream > > > should be sent to > > > > > > Roni > > > > > > -----Original Message----- > > > From: Ali C. Begen (abegen) > > [mailto:abegen@cisco.com] > > > Sent: Saturday, April 25, 2009 11:02 PM > > > To: Roni Even; avt@ietf.org > > > Cc: Bill Ver Steeg (versteb) > > > Subject: RE: [AVT] New draft of "Rapid > > Acquisition of > > > Multicast RTPSessions > > > (RAMS)" available > > > > > > > > > > > > Ali, > > > The example SDP is > > syntactically correct but it does not > > > > > > > > > say that the > > > > > > > > > rtp/rtcp mux will be used and > > it does not give the > > > information to where the > > > unicast stream will be sent > > when the RR sends a RAMS-R. > > > > > > > > > To my knowledge, the first line in the > > following SDP tells > > > the RRs on which > > > port they will receive the > > retransmission/burst packets. > > > > > > m=3Dvideo 41002 RTP/AVPF 99 > > > i=3DUnicast Retransmission Stream > > #2 (Ret. and Rapid > > > Acq. Support) > > > c=3DIN IP4 192.0.2.1 > > > a=3Drtpmap:99 rtx/90000 > > > a=3Drtcp:41003 > > > a=3Dfmtp:99 apt=3D98; rtx-time=3D5000 > > > a=3Dmid:4 > > > > > > There is a typo, you are right. That > > "a=3Drecvonly" line should > > > only exist in > > > the SDP sent to RRs. In the SDP sent to > > RS, we should rather have > > > "a=3Dsendonly". I will make this > > correction in the next version. > > > > > > The feedback target for the SSM session > > and the RTCP port for the > > > retransmission session are also defined > > in the SDP. > > > > > > Hope this clarifies. > > > > > > BR, > > > -acbegen > > > > > > > > > > > > I am not sure why the unicast > > stream m-line has a port > > > > > > > > > number with an > > > > > > > > > attribute of recvonly. What is > > the use case for that. The > > > only information > > > that the RR will need is the > > RTCP port on the RS to where to > > > send the RAMS-R > > > message. > > > Roni > > > -----Original Message----- > > > From: Ali C. Begen (abegen) > > [mailto:abegen@cisco.com] > > > Sent: Friday, April 24, 2009 10:37 PM > > > To: Roni Even; avt@ietf.org > > > Cc: Bill Ver Steeg (versteb) > > > Subject: RE: [AVT] New draft of > > "Rapid Acquisition of > > > Multicast RTPSessions > > > (RAMS)" available > > > > > > This is a part of an example > > SDP sent to RS and RR in a SAP > > > announcement, > > > for example. So, the SDP > > describes what both parties should > > > do (RR cannot > > > say that he wants to receive > > this multicast on its favorite > > > > > > > > > port). The > > > > > > > > > individual SDPs sent to RR or > > RS may include other portions > > > of descriptions > > > that will contain specific information. > > > > > > -acbegen > > > > > > > > > > > > -----Original Message----- > > > From: Roni Even > > [mailto:ron.even.tlv@gmail.com] > > > Sent: Friday, April 24, > > 2009 12:23 PM > > > To: Ali C. Begen > > (abegen); avt@ietf.org > > > Cc: Bill Ver Steeg (versteb) > > > Subject: RE: [AVT] New > > draft of "Rapid Acquisition of > > > Multicast RTPSessions > > (RAMS)" available > > > > > > Ali, > > > I think you get it > > wrong, this SDP is from the RS and not the > > > RR so the RS > > > cannot specify to which > > address it will send it can only > > > specify to which > > > address it can receive > > RTP stream. In this SDP the relevant > > > information is > > > that the request for > > retransmission will be sent by the RR to > > > port 41003 > > > Roni > > > > > > -----Original Message----- > > > From: Ali C. Begen > > (abegen) [mailto:abegen@cisco.com] > > > Sent: Friday, April 24, > > 2009 10:01 PM > > > To: Roni Even; avt@ietf.org > > > Cc: Bill Ver Steeg (versteb) > > > Subject: RE: [AVT] New > > draft of "Rapid Acquisition of > > > Multicast RTPSessions > > > (RAMS)" available > > > > > > Oh, I see. The burst > > goes to the port that we would > > > > > > > > > normally send the > > > > > > > > > retransmissions. For > > example, consider the SDP from the draft: > > > > > > m=3Dvideo 41000 > > RTP/AVPF 98 > > > i=3DPrimary > > Multicast Stream #2 > > > c=3DIN IP4 224.1.1.2/255 > > > > > a=3Dsource-filter: incl IN IP4 224.1.1.2 192.0.2.2 > > > a=3Drtpmap:98 MP2T/90000 > > > a=3Drtcp:41001 IN > > IP4 192.0.2.1 > > > a=3Drtcp-fb:98 nack > > > a=3Drtcp-fb:98 nack ssli > > > a=3Dssrc:123321 > > cname:iptv-ch32@rams.example.com > > > a=3Dmid:3 > > > m=3Dvideo 41002 > > RTP/AVPF 99 > > > i=3DUnicast > > Retransmission Stream #2 (Ret. and Rapid > > > Acq. Support) > > > c=3DIN IP4 192.0.2.1 > > > a=3Drecvonly > > > a=3Drtpmap:99 rtx/90000 > > > a=3Drtcp:41003 > > > a=3Dfmtp:99 > > apt=3D98; rtx-time=3D5000 > > > a=3Dmid:4 > > > > > > In this case, the burst > > will go to port 41002 on the RR. > > > > > > > > > The RAMS-I > > > > > > > > > message(s), which is an > > RTCP feedback message, will go to > > > > > > > > > port 41003. > > > > > > > > > HTH, > > > -acbegen > > > > > > > > > > > > -----Original > > Message----- > > > From: Roni Even > > [mailto:ron.even.tlv@gmail.com] > > > Sent: Friday, > > April 24, 2009 11:44 AM > > > To: Ali C. > > Begen (abegen); avt@ietf.org > > > Cc: Bill Ver > > Steeg (versteb) > > > Subject: RE: > > [AVT] New draft of "Rapid Acquisition of > > > Multicast > > RTPSessions (RAMS)" available > > > > > > Ali, > > > I will try to > > explain in simple way > > > > > > When the RS > > receives the RAMS-R it need to start sending an > > > RTP stream to > > > the RR. > > > In order to > > send a unicast packet, the RS needs to know a > > > transport address > > > on the RR to > > where the RTP stream will be sent. The current > > > draft does not > > > say how the RS > > knows this address. There is no SDP from RR to > > > RS like you > > > mention in your > > response. > > > This is why I > > say that the current draft does not specify a > > > solution that > > > can be > > implemented as a working solution > > > Roni > > > > > > -----Original > > Message----- > > > From: Ali C. > > Begen (abegen) [mailto:abegen@cisco.com] > > > Sent: Friday, > > April 24, 2009 7:38 PM > > > To: Roni Even; > > avt@ietf.org > > > Cc: Bill Ver > > Steeg (versteb) > > > Subject: RE: > > [AVT] New draft of "Rapid Acquisition of > > > Multicast RTPSessions > > > (RAMS)" available > > > > > > Hi Roni, > > > > > > > > > > > > > > -----Original Message----- > > > From: > > avt-bounces@ietf.org [mailto:avt- bounces@ietf.org] On > > > Behalf > > Of Roni Even > > > Sent: > > Friday, April 24, 2009 4:24 AM > > > To: avt@ietf.org > > > Cc: > > Bill Ver Steeg (versteb) > > > > > Subject: Re: [AVT] New draft of "Rapid Acquisition of > > > > > Multicast RTPSessions (RAMS)" available > > > > > > Hi, > > > > > > I think > > that the current draft does not give a > > > > > > > > > description of > > > > > > > > > a > > system that works since there is no text > > > > > > > > > explaining how the > > > > > > > > > What do you > > mean by "a system that works"? > > > > > > > > > > > > RS > > knows the unicast transport address on the RR to > > > > > > > > > where to > > > > > > > > > send the stream. > > > > > > > > > Once RS > > receives the request packet from an RR, RS knows its > > > address. Ports > > > are defined in > > the SDP. If you are asking about "NAT" > > > issues, > > > we have a > > > section for it, > > and we plan to complete it as we move > > > forward. It is not as > > > critical as the > > other parts for now. > > > > > > > > > > > > If you > > mandate the use of RTP/RTCP mux it should say so > > > > > otherwise the RAMS-R should have an optional parameter that > > > > > supplies this information and a flag for using RTP/RTCP mux. > > > > > > > > > IMO, we cannot > > mandate muxing as it is not required to make > > > RAMS work. If > > > muxing is > > supported, the SDP should reflect it. > > > > > > BR, > > > -acbegen > > > > > > > > > > > > Thanks > > > > > > Roni Even > > > > > > > > > > > > From: > > avt-bounces@ietf.org [mailto:avt- bounces@ietf.org] On > > > Behalf > > Of Bill Ver Steeg (versteb) > > > Sent: > > Thursday, April 16, 2009 7:39 PM > > > To: avt@ietf.org > > > > > Subject: [AVT] New draft of "Rapid Acquisition of Multicast > > > RTP > > Sessions (RAMS)" available > > > > > > > > > > > > There > > is a new draft of the "Rapid Acquisition of Multicast > > > RTP > > Sessions (RAMS)" draft available at > > > > > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-versteeg-avt-rapid-s > > > > > > > > > > > ynchronization-for-rtp-03.txt > > > <http://www.ietf.org/internet-> <http://www.ietf.org/internet-> > > > > > > > > > > > > > > drafts/draft-versteeg-avt-rapid-synchronization-for-rtp-03.txt> > > > > > > > > > > > > > > > We have > > incorporated the changes from the technical > > > > > > > > > breakout > > > > > > > > > session > > in San Francisco. The major changes in this version > > > of the > > draft include > > > > > > 1- > > Changing the document title to avoid confusion > > > > > > > > > with other > > > > > > > > > ongoing > > "synchronization" drafts > > > > > > 2- > > changing the message names to reflect the title change > > > > > > 3- > > clarification of the RTCP message semantics, including > > > changes > > to the "Request" and "Inform" messages > > > > > > 4- > > additional description/motivation for the > > > > > > > > > various message > > > > > > > > > flows > > has been added > > > > > > 5- > > RTP/RTCP muxing has been added > > > > > > > > > > > > > > > > > > We hope > > to make this a Working Group item, and will change > > > the > > name of the draft to avoid conflicts with other > > > > > "synchronization" drafts at that time. > > > > > > > > > > > > Bill VerSteeg > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Audio/Video Transport Working Group > > > avt@ietf.org > > > https://www.ietf.org/mailman/listinfo/avt > > > > > > > > > > > > >=20 >=20 > Panasonic R&D Center Germany GmbH > 63225 Langen, Hessen, Germany > Reg: AG Offenbach (Hessen) HRB 33974 > Managing Director: Thomas Micke >=20 From singer@apple.com Fri May 22 18:25:11 2009 Return-Path: <singer@apple.com> X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAC4A3A6A7A for <avt@core3.amsl.com>; Fri, 22 May 2009 18:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUnMVcM0uUPu for <avt@core3.amsl.com>; Fri, 22 May 2009 18:25:09 -0700 (PDT) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id ECA763A6A04 for <avt@ietf.org>; Fri, 22 May 2009 18:25:08 -0700 (PDT) Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out4.apple.com (Postfix) with ESMTP id 50CCA64C06AE for <avt@ietf.org>; Fri, 22 May 2009 18:26:48 -0700 (PDT) Received: from relay11.apple.com (unknown [127.0.0.1]) by relay11.apple.com (Symantec Brightmail Gateway) with ESMTP id 393C62807E for <avt@ietf.org>; Fri, 22 May 2009 18:26:48 -0700 (PDT) X-AuditID: 11807130-a74e0bb0000025da-f3-4a1750d77373 Received: from [10.0.1.8] (unknown [17.151.102.66]) by relay11.apple.com (Apple SCV relay) with ESMTP id D6D1D2807D for <avt@ietf.org>; Fri, 22 May 2009 18:26:47 -0700 (PDT) Mime-Version: 1.0 Message-Id: <p0624080bc63cffcf77fe@[10.0.1.8]> In-Reply-To: <302f570905221508q637770ebi89582187526d1594@mail.gmail.com> References: <302f570905221154t7feb4162s6728f9dc2c736592@mail.gmail.com> <C63C617C.372F%luby@qualcomm.com> <31d1be720905221451t844a033ufe37b44884b56f83@mail.gmail.com> <302f570905221508q637770ebi89582187526d1594@mail.gmail.com> Date: Fri, 22 May 2009 18:26:21 -0700 To: "avt@ietf.org" <avt@ietf.org> From: David Singer <singer@apple.com> Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Brightmail-Tracker: AAAAAA== Subject: Re: [AVT] Comments on draft-pantos-http-live-streaming-00.txt ... X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group <avt.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/avt> List-Post: <mailto:avt@ietf.org> List-Help: <mailto:avt-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 23 May 2009 01:25:12 -0000 Well, not really comments on the draft; more to thank Mike for pointing out that there is a 'question' in the industry, and that perhaps existing techniques ('pure' RTP or MPEG-2 Transport or existing file download) are not working so well. A few people at MPEG have noticed this as well, and are also asking the question. It's by no means clear what should be done, or where, or by whom, but they are stepping up to holding an open workshop. I don't get the sense from the organizers that there is any kind of 'position' being taken here (yet), not even on whether or where something should be done, let alone what. Have a look at this page and see whether some of you would like to write something (separately, jointly), or attend: <http://multimediacommunication.blogspot.com/2009/04/workshop-on-mmt-modern-media-transport.html> -- David Singer Multimedia Standards, Apple Inc. From Even.roni@huawei.com Sat May 23 05:18:15 2009 Return-Path: <Even.roni@huawei.com> X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 306AC3A6ADD for <avt@core3.amsl.com>; Sat, 23 May 2009 05:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.401 X-Spam-Level: X-Spam-Status: No, score=0.401 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9MOg+8Byhlb for <avt@core3.amsl.com>; Sat, 23 May 2009 05:18:13 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id D81113A686D for <avt@ietf.org>; Sat, 23 May 2009 05:18:12 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KK300HX2JL0X5@szxga03-in.huawei.com> for avt@ietf.org; Sat, 23 May 2009 20:19:48 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KK300CH1JL0Z1@szxga03-in.huawei.com> for avt@ietf.org; Sat, 23 May 2009 20:19:48 +0800 (CST) Received: from windows8d787f9 (bzq-79-179-42-107.red.bezeqint.net [79.179.42.107]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KK300EHJJKKJX@szxml01-in.huawei.com>; Sat, 23 May 2009 20:19:48 +0800 (CST) Date: Sat, 23 May 2009 15:18:32 +0300 From: Roni Even <Even.roni@huawei.com> In-reply-to: <04CAD96D4C5A3D48B1919248A8FE0D54095E18BB@xmb-sjc-215.amer.cisco.com> To: "'Ali C. Begen (abegen)'" <abegen@cisco.com>, 'Jose Rey' <Jose.Rey@eu.panasonic.com> Message-id: <02a001c9dba0$a5559730$f000c590$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=ISO-8859-1 Content-language: en-us Content-transfer-encoding: quoted-printable Thread-index: AcnaYqqjHO1LimacStOS+9HZ8wJeMAADPRKQABOigeAADM4YEAArEjmQ iPlanet-SMTP-Warning: Lines longer than SMTP allows found and truncated. References: <81B9B88E2F9D574AA5328A85547CDE9101071D80@xmb-rtp-21d.amer.cisco.com> <49f1a1d6.190c660a.58fe.ffffa90e@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C80DA@xmb-sjc-215.amer.cisco.com> <49f208e8.05a0660a.5bd2.6764@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C81C9@xmb-sjc-215.amer.cisco.com> <49f211fc.07a5660a.3f7f.ffff8f4a@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8202@xmb-sjc-215.amer.cisco.com> <49f2efa2.1c215e0a.4454.ffffaf91@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8403@xmb-sjc-215.amer.cisco.com> <49f36ee2.0437560a.11df.1eef@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8405@xmb-sjc-215.amer.cisco.com> <49f387ca.0305560a.6657.4be7@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C840A@xmb-sjc-215.amer.cisco.com> <4A15D40E.80509@eu.panasonic.com> <04CAD96D4C5A3D48B1919248A8FE0D54095E153A@xmb-sjc-215.amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB011BF41B@lan-ex-02.panasonic.de> <04CAD96D4C5A3D48B1919248A8FE0D54095E18BB@xmb-sjc-.com> Cc: 'Roni Even' <ron.even.tlv@gmail.com>, avt@ietf.org, "'Bill Ver Steeg \(versteb\)'" <versteb@cisco.com> Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group <avt.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/avt> List-Post: <mailto:avt@ietf.org> List-Help: <mailto:avt-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 23 May 2009 12:18:15 -0000 Hi, I also have concerns about having the unicast Transport addresses for = the RR RTCP and RTP receive port. I think that we should first talk about the NAT/FW issue and than define = the requirements and solutions. My assumption is that the retransmission server has a publicly reachable address while the receivers may sit behind NATs and will not have a = publicly reachable address. Note that the RAMS flow starts from the receiver by RAMS-R so a response = to the transport address from where the RAMS-R came should work (RTCP is bi-directional in this case). On the other hand the unicast data flow is = to the receiver so the receiver will need to provide a reachable transport address. Roni -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Ali C. Begen (abegen) Sent: Saturday, May 23, 2009 3:27 AM To: Jose Rey Cc: Roni Even; avt@ietf.org; Bill Ver Steeg (versteb) Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast = RTPSessions (RAMS)" available Hi Jose, Indeed, RAMS-R goes to the FT of the new primary session that RR is interested in acquiring rapidly. Then the unicast session becomes alive = and RS sends RAMS-I message(s) to RR on the RTCP port for the unicast = session. After some time, RR sends the RAMS-T message to the RTCP port for the unicast session since it is supposed to end the unicast session.=20 -acbegen > -----Original Message----- > From: Jose Rey [mailto:Jose.Rey@eu.panasonic.com] > Sent: Friday, May 22, 2009 7:09 AM > To: Ali C. Begen (abegen) > Cc: Roni Even; avt@ietf.org; Bill Ver Steeg (versteb) > Subject: RE: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" > available >=20 >=20 > Hi Ali, >=20 > > > > Hi Jose, > > > > We have separate RTCP ports for the SSM session and the > > unicast session. Why is it a problem? >=20 > In line 19 you say you specify the dst port for RMS-I (41003), on RR. = And you say that > would also be the port where the RR sends RMS-T, on RS. That is mixing = the semantics of > a=3Drtcp for SSM (listening port at Feedback Target =3D mcast RTCP dst = port) and those of RFC > 3605 (dst port). In other words, you are implicitly assuming that specifies symmetric > RTCP...no? >=20 > Another thing that was mentioned already: RMS-T is not sent to same = port as RMS-R; is it > not the same RTCP session ? Or is this muxing desired? why? >=20 > JLR >=20 > > > > The slightly modified SDP for the next version is below: > > > 1> a=3Dgroup:FID 3 4 > 2> a=3Drtcp-unicast:rsi > 3> m=3Dvideo 41000 RTP/AVPF 98 > 4> i=3DPrimary Multicast Stream #2 > 5> c=3DIN IP4 233.252.0.2/255 > 6> a=3Dsource-filter: incl IN IP4 233.252.0.2 192.0.2.2 > 7> a=3Drecvonly > 8> a=3Drtpmap:98 MP2T/90000 > 9> a=3Drtcp:41001 IN IP4 192.0.2.1 > 10> a=3Drtcp-fb:98 nack > 11> a=3Drtcp-fb:98 nack ssli > 12> a=3Dssrc:123321 cname:iptv-ch32@rams.example.com > 13> a=3Dmid:3 > 14> m=3Dvideo 41002 RTP/AVPF 99 > 15> i=3DUnicast Retransmission Stream #2 (Ret. and Rapid > > Acq. Support) > 16> c=3DIN IP4 192.0.2.1 > 17> a=3Drecvonly > 18> a=3Drtpmap:99 rtx/90000 > 19> a=3Drtcp:41003 > 20> a=3Dfmtp:99 apt=3D98; rtx-time=3D5000 > 21> a=3Dmid:4 > > > > This is the SDP we send to RR. For RS, a=3Drecvonly will be = a=3Dsendonly. > > > > -acbegen > > > > > > > -----Original Message----- > > > From: Jos=E9 Rey [mailto:jose.rey@eu.panasonic.com] > > > Sent: Thursday, May 21, 2009 3:22 PM > > > To: Ali C. Begen (abegen) > > > Cc: Roni Even; avt@ietf.org; Bill Ver Steeg (versteb) > > > Subject: Re: [AVT] New draft of "Rapid Acquisition of > > Multicast RTPSessions (RAMS)" > > > available > > > > > > Hi all, > > > > > > sorry for jumping in.... > > > > > > I think one of the sources of confusion is that the > > attribute a=3Drtcp: > > > is used once for specifying the destination port and once for > > > specifying a receiving port, and in the same SDP (!). The > > destination > > > port for RAMS-I packets sent by RS and the receiving port > > for RAMS-T. Which is also why different port numbers are used > > for RAMS-T and -R packets. > > > > > > I think the use of a=3Drtcp: in SSM is the problem here. Or the = fact > > > that we are mixing unicast and multicast, or both. > > > > > > Hope this helps, > > > > > > JLR > > > > > > > > > > > > > > > Ali C. Begen (abegen) wrote: > > > > > > > > > > > > > > > > > > -----Original Message----- > > > From: Roni Even [mailto:ron.even.tlv@gmail.com] > > > Sent: Saturday, April 25, 2009 2:58 PM > > > To: Ali C. Begen (abegen); avt@ietf.org > > > Cc: Bill Ver Steeg (versteb) > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of > > > Multicast RTPSessions (RAMS)" available > > > > > > Ali, > > > I looked at RFC 4570 and I assume that port > > 41001 is the port for the > > > unicast RTCP reports from the receivers and according to > > > > > > > > > > > > Yes, indeed. > > > > > > > > > > > > section 3.2.1 of > > > that RFC you also should have a RTCP-unicast > > specification. > > > This is for the > > > multicast receiver reports. > > > > > > > > > > > > Correct. We do have that line in our draft at the top > > right after the grouping lines: > > > > > > a=3Drtcp-unicast:rsi > > > > > > BR, > > > -acbegen > > > > > > > > > > > > Roni > > > > > > -----Original Message----- > > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > > Sent: Saturday, April 25, 2009 11:30 PM > > > To: Roni Even; avt@ietf.org > > > Cc: Bill Ver Steeg (versteb) > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of > > > Multicast RTPSessions > > > (RAMS)" available > > > > > > Here is the SDP. > > > > > > m=3Dvideo 41000 RTP/AVPF 98 > > > i=3DPrimary Multicast Stream #2 > > > c=3DIN IP4 224.1.1.2/255 > > > a=3Dsource-filter: incl IN IP4 224.1.1.2 192.0.2.2 > > > > > > Source (192.0.2.2) sends the rtp packets to the > > multicast > > > group (224.1.1.2) > > > with a dest port 41000. > > > > > > a=3Drtpmap:98 MP2T/90000 > > > a=3Drtcp:41001 IN IP4 192.0.2.1 > > > > > > The feedback target (RS) address for this SSM session is > > > 192.0.2.1 and its > > > port is 41001. This is the address/port where > > RR sends the RAMS-R, or > > > receiver reports for the SSM session. > > > > > > a=3Drtcp-fb:98 nack > > > a=3Drtcp-fb:98 nack ssli > > > a=3Dssrc:123321 cname:iptv-ch32@rams.example.com > > > a=3Dmid:3 > > > m=3Dvideo 41002 RTP/AVPF 99 > > > > > > The retransmission packets go to port 41002. > > This is the port > > > RRs listen to > > > for retransmission and RAMS. > > > > > > i=3DUnicast Retransmission Stream #2 > > (Ret. and Rapid > > > Acq. Support) > > > c=3DIN IP4 192.0.2.1 > > > > > > This is where the retransmission packets come > > from, same as > > > the feedback > > > target (in this example). > > > > > > a=3Drtpmap:99 rtx/90000 > > > a=3Drtcp:41003 > > > > > > This is where the RTCP packets for the > > retransmission session go. For > > > example, RAMS-I goes to this port on RRs. > > RAMS-T goes to this > > > port on RS. > > > > > > a=3Dfmtp:99 apt=3D98; rtx-time=3D5000 > > > a=3Dmid:4 > > > > > > > > > -acbegen > > > > > > > > > > > > > > > -----Original Message----- > > > From: Roni Even [mailto:ron.even.tlv@gmail.com] > > > Sent: Saturday, April 25, 2009 1:11 PM > > > To: Ali C. Begen (abegen); avt@ietf.org > > > Cc: Bill Ver Steeg (versteb) > > > Subject: RE: [AVT] New draft of "Rapid > > Acquisition of > > > Multicast RTPSessions (RAMS)" available > > > > > > Ali, > > > Can you please write three addresses > > from this strange SDP. > > > > > > 1. The address and port of multicast > > > > > > 2. The address and port of the RS where > > the RTCP FB should go to > > > > > > 3. The address and port on the RR where > > the unicast stream > > > should be sent to > > > > > > Roni > > > > > > -----Original Message----- > > > From: Ali C. Begen (abegen) > > [mailto:abegen@cisco.com] > > > Sent: Saturday, April 25, 2009 11:02 PM > > > To: Roni Even; avt@ietf.org > > > Cc: Bill Ver Steeg (versteb) > > > Subject: RE: [AVT] New draft of "Rapid > > Acquisition of > > > Multicast RTPSessions > > > (RAMS)" available > > > > > > > > > > > > Ali, > > > The example SDP is > > syntactically correct but it does not > > > > > > > > > say that the > > > > > > > > > rtp/rtcp mux will be used and > > it does not give the > > > information to where the > > > unicast stream will be sent > > when the RR sends a RAMS-R. > > > > > > > > > To my knowledge, the first line in the > > following SDP tells > > > the RRs on which > > > port they will receive the > > retransmission/burst packets. > > > > > > m=3Dvideo 41002 RTP/AVPF 99 > > > i=3DUnicast Retransmission Stream > > #2 (Ret. and Rapid > > > Acq. Support) > > > c=3DIN IP4 192.0.2.1 > > > a=3Drtpmap:99 rtx/90000 > > > a=3Drtcp:41003 > > > a=3Dfmtp:99 apt=3D98; rtx-time=3D5000 > > > a=3Dmid:4 > > > > > > There is a typo, you are right. That > > "a=3Drecvonly" line should > > > only exist in > > > the SDP sent to RRs. In the SDP sent to > > RS, we should rather have > > > "a=3Dsendonly". I will make this > > correction in the next version. > > > > > > The feedback target for the SSM session > > and the RTCP port for the > > > retransmission session are also defined > > in the SDP. > > > > > > Hope this clarifies. > > > > > > BR, > > > -acbegen > > > > > > > > > > > > I am not sure why the unicast > > stream m-line has a port > > > > > > > > > number with an > > > > > > > > > attribute of recvonly. What is > > the use case for that. The > > > only information > > > that the RR will need is the > > RTCP port on the RS to where to > > > send the RAMS-R > > > message. > > > Roni > > > -----Original Message----- > > > From: Ali C. Begen (abegen) > > [mailto:abegen@cisco.com] > > > Sent: Friday, April 24, 2009 10:37 PM > > > To: Roni Even; avt@ietf.org > > > Cc: Bill Ver Steeg (versteb) > > > Subject: RE: [AVT] New draft of > > "Rapid Acquisition of > > > Multicast RTPSessions > > > (RAMS)" available > > > > > > This is a part of an example > > SDP sent to RS and RR in a SAP > > > announcement, > > > for example. So, the SDP > > describes what both parties should > > > do (RR cannot > > > say that he wants to receive > > this multicast on its favorite > > > > > > > > > port). The > > > > > > > > > individual SDPs sent to RR or > > RS may include other portions > > > of descriptions > > > that will contain specific information. > > > > > > -acbegen > > > > > > > > > > > > -----Original Message----- > > > From: Roni Even > > [mailto:ron.even.tlv@gmail.com] > > > Sent: Friday, April 24, > > 2009 12:23 PM > > > To: Ali C. Begen > > (abegen); avt@ietf.org > > > Cc: Bill Ver Steeg (versteb) > > > Subject: RE: [AVT] New > > draft of "Rapid Acquisition of > > > Multicast RTPSessions > > (RAMS)" available > > > > > > Ali, > > > I think you get it > > wrong, this SDP is from the RS and not the > > > RR so the RS > > > cannot specify to which > > address it will send it can only > > > specify to which > > > address it can receive > > RTP stream. In this SDP the relevant > > > information is > > > that the request for > > retransmission will be sent by the RR to > > > port 41003 > > > Roni > > > > > > -----Original Message----- > > > From: Ali C. Begen > > (abegen) [mailto:abegen@cisco.com] > > > Sent: Friday, April 24, > > 2009 10:01 PM > > > To: Roni Even; avt@ietf.org > > > Cc: Bill Ver Steeg (versteb) > > > Subject: RE: [AVT] New > > draft of "Rapid Acquisition of > > > Multicast RTPSessions > > > (RAMS)" available > > > > > > Oh, I see. The burst > > goes to the port that we would > > > > > > > > > normally send the > > > > > > > > > retransmissions. For > > example, consider the SDP from the draft: > > > > > > m=3Dvideo 41000 > > RTP/AVPF 98 > > > i=3DPrimary > > Multicast Stream #2 > > > c=3DIN IP4 224.1.1.2/255 > > > > > a=3Dsource-filter: incl IN IP4 224.1.1.2 192.0.2.2 > > > a=3Drtpmap:98 MP2T/90000 > > > a=3Drtcp:41001 IN > > IP4 192.0.2.1 > > > a=3Drtcp-fb:98 nack > > > a=3Drtcp-fb:98 nack ssli > > > a=3Dssrc:123321 > > cname:iptv-ch32@rams.example.com > > > a=3Dmid:3 > > > m=3Dvideo 41002 > > RTP/AVPF 99 > > > i=3DUnicast > > Retransmission Stream #2 (Ret. and Rapid > > > Acq. Support) > > > c=3DIN IP4 192.0.2.1 > > > a=3Drecvonly > > > a=3Drtpmap:99 rtx/90000 > > > a=3Drtcp:41003 > > > a=3Dfmtp:99 > > apt=3D98; rtx-time=3D5000 > > > a=3Dmid:4 > > > > > > In this case, the burst > > will go to port 41002 on the RR. > > > > > > > > > The RAMS-I > > > > > > > > > message(s), which is an > > RTCP feedback message, will go to > > > > > > > > > port 41003. > > > > > > > > > HTH, > > > -acbegen > > > > > > > > > > > > -----Original > > Message----- > > > From: Roni Even > > [mailto:ron.even.tlv@gmail.com] > > > Sent: Friday, > > April 24, 2009 11:44 AM > > > To: Ali C. > > Begen (abegen); avt@ietf.org > > > Cc: Bill Ver > > Steeg (versteb) > > > Subject: RE: > > [AVT] New draft of "Rapid Acquisition of > > > Multicast > > RTPSessions (RAMS)" available > > > > > > Ali, > > > I will try to > > explain in simple way > > > > > > When the RS > > receives the RAMS-R it need to start sending an > > > RTP stream to > > > the RR. > > > In order to > > send a unicast packet, the RS needs to know a > > > transport address > > > on the RR to > > where the RTP stream will be sent. The current > > > draft does not > > > say how the RS > > knows this address. There is no SDP from RR to > > > RS like you > > > mention in your > > response. > > > This is why I > > say that the current draft does not specify a > > > solution that > > > can be > > implemented as a working solution > > > Roni > > > > > > -----Original > > Message----- > > > From: Ali C. > > Begen (abegen) [mailto:abegen@cisco.com] > > > Sent: Friday, > > April 24, 2009 7:38 PM > > > To: Roni Even; > > avt@ietf.org > > > Cc: Bill Ver > > Steeg (versteb) > > > Subject: RE: > > [AVT] New draft of "Rapid Acquisition of > > > Multicast RTPSessions > > > (RAMS)" available > > > > > > Hi Roni, > > > > > > > > > > > > > > -----Original Message----- > > > From: > > avt-bounces@ietf.org [mailto:avt- bounces@ietf.org] On > > > Behalf > > Of Roni Even > > > Sent: > > Friday, April 24, 2009 4:24 AM > > > To: avt@ietf.org > > > Cc: > > Bill Ver Steeg (versteb) > > > > > Subject: Re: [AVT] New draft of "Rapid Acquisition of > > > > > Multicast RTPSessions (RAMS)" available > > > > > > Hi, > > > > > > I think > > that the current draft does not give a > > > > > > > > > description of > > > > > > > > > a > > system that works since there is no text > > > > > > > > > explaining how the > > > > > > > > > What do you > > mean by "a system that works"? > > > > > > > > > > > > RS > > knows the unicast transport address on the RR to > > > > > > > > > where to > > > > > > > > > send the stream. > > > > > > > > > Once RS > > receives the request packet from an RR, RS knows its > > > address. Ports > > > are defined in > > the SDP. If you are asking about "NAT" > > > issues, > > > we have a > > > section for it, > > and we plan to complete it as we move > > > forward. It is not as > > > critical as the > > other parts for now. > > > > > > > > > > > > If you > > mandate the use of RTP/RTCP mux it should say so > > > > > otherwise the RAMS-R should have an optional parameter that > > > > > supplies this information and a flag for using RTP/RTCP mux. > > > > > > > > > IMO, we cannot > > mandate muxing as it is not required to make > > > RAMS work. If > > > muxing is > > supported, the SDP should reflect it. > > > > > > BR, > > > -acbegen > > > > > > > > > > > > Thanks > > > > > > Roni Even > > > > > > > > > > > > From: > > avt-bounces@ietf.org [mailto:avt- bounces@ietf.org] On > > > Behalf > > Of Bill Ver Steeg (versteb) > > > Sent: > > Thursday, April 16, 2009 7:39 PM > > > To: avt@ietf.org > > > > > Subject: [AVT] New draft of "Rapid Acquisition of Multicast > > > RTP > > Sessions (RAMS)" available > > > > > > > > > > > > There > > is a new draft of the "Rapid Acquisition of Multicast > > > RTP > > Sessions (RAMS)" draft available at > > > > > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-versteeg-avt-rapid-s > > > > > > > > > > > ynchronization-for-rtp-03.txt > > > <http://www.ietf.org/internet-> <http://www.ietf.org/internet-> > > > > > > > > > > > > > > drafts/draft-versteeg-avt-rapid-synchronization-for-rtp-03.txt> > > > > > > > > > > > > > > > We have > > incorporated the changes from the technical > > > > > > > > > breakout > > > > > > > > > session > > in San Francisco. The major changes in this version > > > of the > > draft include > > > > > > 1- > > Changing the document title to avoid confusion > > > > > > > > > with other > > > > > > > > > ongoing > > "synchronization" drafts > > > > > > 2- > > changing the message names to reflect the title change > > > > > > 3- > > clarification of the RTCP message semantics, including > > > changes > > to the "Request" and "Inform" messages > > > > > > 4- > > additional description/motivation for the > > > > > > > > > various message > > > > > > > > > flows > > has been added > > > > > > 5- > > RTP/RTCP muxing has been added > > > > > > > > > > > > > > > > > > We hope > > to make this a Working Group item, and will change > > > the > > name of the draft to avoid conflicts with other > > > > > "synchronization" drafts at that time. > > > > > > > > > > > > Bill VerSteeg > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Audio/Video Transport Working Group > > > avt@ietf.org > > > https://www.ietf.org/mailman/listinfo/avt > > > > > > > > > > > > >=20 >=20 > Panasonic R&D Center Germany GmbH > 63225 Langen, Hessen, Germany > Reg: AG Offenbach (Hessen) HRB 33974 > Managing Director: Thomas Micke >=20 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www.ietf.org/mailman/listinfo/avt From yekuiwang@huawei.com Sat May 23 09:06:45 2009 Return-Path: <yekuiwang@huawei.com> X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 053753A6A6F for <avt@core3.amsl.com>; Sat, 23 May 2009 09:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGHUD5IvSm48 for <avt@core3.amsl.com>; Sat, 23 May 2009 09:06:43 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 0CED23A684F for <avt@ietf.org>; Sat, 23 May 2009 09:06:43 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KK300MVHU5WA7@usaga02-in.huawei.com> for avt@ietf.org; Sat, 23 May 2009 09:08:21 -0700 (PDT) Received: from W90946 ([10.51.0.49]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KK300BNRU5S4J@usaga02-in.huawei.com> for avt@ietf.org; Sat, 23 May 2009 09:08:20 -0700 (PDT) Date: Sat, 23 May 2009 12:08:14 -0400 From: Ye-Kui Wang <yekuiwang@huawei.com> In-reply-to: <027101c9db1f$a9842a50$fc8c7ef0$%roni@huawei.com> To: 'Roni Even' <Even.roni@huawei.com>, 'Randell Jesup' <rjesup@wgate.com> Message-id: <02341470F0384C54B17D2411F9267BE7@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acna8UQGrgzYGcgMRLK6VKOJKU4GPAAA4SpwAAoiXVAAKLJ/MA== References: <4A15046C.5080600@rogers.com> <006701c9d9e9$51679500$f436bf00$%roni@huawei.com> <7779AD69A5E54F9F84E473BB4F4E1E71@china.huawei.com> <4A157ADA.8060900@rogers.com> <ybuljopyjto.fsf@jesup.eng.wgate.com> <3221EC0396044781B11D483B77E085A1@china.huawei.com> <ybuhbzdygly.fsf@jesup.eng.wgate.com> <939A5D7EEE0A410E867078A3117DD3CE@china.huawei.com> <ybuhbzdb1tr.fsf@jesup.eng.wgate.com> <0F4BC54357284559B31303B0D730F7E2@china.huawei.com> <027101c9db1f$a9842a50$fc8c7ef0$%roni@huawei.com> Cc: 'Tom Taylor' <tom.taylor@rogers.com>, 'IETF AVT WG' <avt@ietf.org> Subject: Re: [AVT] Consensus on profile-level-id in 3984bis X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group <avt.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/avt> List-Post: <mailto:avt@ietf.org> List-Help: <mailto:avt-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 23 May 2009 16:06:45 -0000 Roni, > I think I mentioned before that the offer can > offer a low level and add capabilities using the optional > parameters, this working point will be between two specified > levels from table A-1, higher than the one in the offer but > lower than the one above it. I think that in this case if the > answer will include the higher level this will still work, > and since the encoder is flexible it may take advantage of > the new information. Those max-* parameters may only be used to indicate receiver capabilities not anything else. That is, an offerer or answerer may add extra capabilities than the included level for receiving capabilities, but not for sending. BR, YK > -----Original Message----- > From: Roni Even [mailto:Even.roni@huawei.com] > Sent: Friday, May 22, 2009 4:55 PM > To: 'Ye-Kui Wang'; 'Randell Jesup' > Cc: 'Tom Taylor'; 'IETF AVT WG' > Subject: RE: [AVT] Consensus on profile-level-id in 3984bis > > YK, > I think you are right that we are now to the root of the > discussion. The levels in H.264 annex A specify some > compromise in order to allow mass production devices like set > top boxes use fixed architecture for example in order to > define the frame buffer size on the device and typically will > not negotiate the level (mostly streaming applications). On > the other side video conferencing systems have much more > flexibility and control over the encoder since they are part > of a system that considers also the display and network > connection when they offer a specific level (which may be > lower than the maximum that they can support). Having more > control on the encoder allows them to get requests from the > remote system to send pictures at specific resolutions and > aspect ratios. I think I mentioned before that the offer can > offer a low level and add capabilities using the optional > parameters, this working point will be between two specified > levels from table A-1, higher than the one in the offer but > lower than the one above it. I think that in this case if the > answer will include the higher level this will still work, > and since the encoder is flexible it may take advantage of > the new information. > > Roni > > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > Behalf Of Ye-Kui Wang > Sent: Friday, May 22, 2009 8:10 PM > To: 'Randell Jesup' > Cc: 'Tom Taylor'; 'IETF AVT WG' > Subject: Re: [AVT] Consensus on profile-level-id in 3984bis > > > I think the root of most of the disputes is, given a video > encoder, whether you can label it with a max level. In > theory, I think you are right that, given the computing > resource of the encoder, it is possible to compromise among > parameters. However, in practice, when you get an encoder > product (which is typically optimized or even fixed for > certain operating range), it would typically be labelled with > a profile at a level, and it should not be common that users > (of the encoder product) would try to compromise among > parameters and see whether it can produce a bitstream with a > higher level, and in many cases, the encoder product does not > provide enough space for you play around this. The level > labelled by the encoder manufacture is usually the max level. > There are of course also purely PC software based encoders > can be very flexible, and can be configured to be almost any > profile and level. But once it is configured to be at a > profile and a level and the encoder is initialized, then that > level should be used as the max level. > > BR, YK > > > -----Original Message----- > > From: Randell Jesup [mailto:rjesup@wgate.com] > > Sent: Friday, May 22, 2009 11:22 AM > > To: Ye-Kui Wang > > Cc: 'Tom Taylor'; 'IETF AVT WG' > > Subject: Re: [AVT] Consensus on profile-level-id in 3984bis > > > > Ye-Kui Wang <yekuiwang@huawei.com> writes: > > >> Ye-Kui Wang <yekuiwang@huawei.com> writes: > > >> >If the following are considered, then let the other > side know the > > >> >sending capability (as well as whether level upgrade is > allowed) > > >> >would be very useful. > > >> > > > >> >- One may want to request a specific mode, e.g. a spatial > > >> >resolution, from the sender, for example by using image > attribute > > >> >mmusic draft. > > >> > > >> Does adding a max-send-level actually help you there? > > > > > >Yes. > > > > > >> How does this interact with how you decide what your max sending > > >> level is? > > > > > >You don't decide your max sending level, your max sending > > level is your > > >max sending capability, a hard capability limit of you. > > > > Max capability for what/which? For all parameters simultaneously? > > Maximum bitrate at maximum framesize at maximum macroblocks/second, > > with maximum frame-to-frame motion, with maximum > > motion-estimation-search, etc? > > > > I'm not saying you can't choose a maximum, but it's very, > very soft - > > very subjective because encoding is much more variable (and > expensive) > > than decoding. It's (much) easier to estimate a worst-case for > > decode. > > > > >> As mentioned below, choosing a value for that (other than > > basing it > > >> on resolution alone, and that just might put a lower bound > > on it) is > > >> extremely subjective at best. > > > > > >Example: If one side lets the other side know its max sending > > >capability, then the other side would not even try to request a > > >specific capability that is impossible to be satisfied. > > Otherwise, the > > >other side may just send useless requests. > > > > > >> >- Video adaptation, in terms of bitrate, frame rate, > > and/or spatial > > >> >resolution etc, may happen during the session, and may be > > initiated > > >> >by either side. > > >> > > >> Again, how would this work in practice, and how would > > adding it here > > >> help? Adaptation within the negotiated limits can occur > now, so I > > >> don't see the advantage here. If you need to change the > > maximum limits (why? > > >> weren't they properly negotiated to start with?), then you can > > >> re-invite. I think we need a concrete example, in order > > to know if > > >> what you're proposing is sufficient - or if it works. I'm quite > > >> unclear on how you believe specifying a max send level will help > > >> anything, since your list is quite vague. > > >> > > > > > >Example > > > > > >The offerer does not tell the answerer its max sending capability, > > >which is level B. A negotiation is done, where the answer includes > > >level C (C>B), and the offerer starts to send at C (actually > > B, but the > > >answerer may not be sure). After a while, the answerer > > senses that the > > >connecting bandwidth is higher, and it wants to receive at > a higher > > >bitrate, which is still within the limit of level C, but above the > > >limit of B, and sends a meaningless adaption request using > re-invite. > > > > > >However, if the offerer does tell the answerer its max sending > > >capability, such meaningless adaption requests are avoided. > > I believe > > >there are more examples, but I hope this already helps. > > > > That's a plausible case - thanks. However, I think you > could have an > > unintended result if you did that. Lets say that the > offerer uses the > > "worst-case" method to decide on a max-send-level (per > above). That > > level may be well below the limits it could hit when it's not worst > > case - for example, it may be constrained on framesize or MBPS to > > level 3.0, but can handle the outgoing bandwidth of level 4.0, and > > level 5.0 when other parameters aren't worst-case. By > limiting to a > > max-send-level of 3.0, the receiver won't request use of extra > > bandwidth or 4.0 or 5.0. Note that even if you go and > duplicate all > > the max-* parameters as sprop-max-*, you still wouldn't be able to > > handle the "I can do this when other parameters are relaxed" case. > > > > I also already mentioned this problem below (repeated here): > > >> >> The question is "is it worth it"? Also, while this > may let you > > >> >> limit resources, you may also limit the options of the sender. > > >> >> For example, in the first case above, since A knows B > > can receive > > >> >> 5.0, A could send a higher frame size than 3.0 supports > > (perhaps > > >> >> at a lower framerate), even though A can't support > > sending "full" level 3.1. > > > > I think you can handle the adaptation issue as part of the > adaptation > > design, since there may be other reasons the offerer can't > raise the > > bandwidth (or whatever). > > > > >BR, YK > > > > > > > > >> >BR, YK > > >> > > > >> >> -----Original Message----- > > >> >> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] > > >> On Behalf Of > > >> >> Randell Jesup > > >> >> Sent: Thursday, May 21, 2009 10:04 PM > > >> >> To: Tom Taylor > > >> >> Cc: IETF AVT WG > > >> >> Subject: Re: [AVT] Consensus on profile-level-id in 3984bis > > >> >> > > >> >> Tom Taylor <tom.taylor@rogers.com> writes: > > >> >> >It appears that the optimum outcome is to be able to signal > > >> >> both send > > >> >> >and receive capability. The legacy approach loses > some of this > > >> >> >information, since profile-level-id contains the lesser > > >> of the two > > >> >> >values. In a legacy-new interworking situation it seems > > >> >> unlikely that > > >> >> >we can improve on this. > > >> >> > > >> >> Well, I'm not sure you can say that a legacy device > > >> definitively uses > > >> >> the lesser of send/receive in profile-level-id. Because > > >> of the way > > >> >> profile-level-id works, and how H.264 encodes streams, > > there is no > > >> >> problem with currently specifying a level above what you > > >> can "truly" > > >> >> support *sending*. I.e. you can say you can receive and > > >> send level > > >> >> 3.0 via profile-level-id, but nothing forces you to use > > the full > > >> >> limits of level 3.0 when sending. You can send a stream > > >> that could > > >> >> be encoded identically in level 2.0; you can even mark > > it as level > > >> >> 3.0 in the SPS/PPS NAL units. > > >> >> > > >> >> On the other side of the equation, it is the lesser - if > > >> you can only > > >> >> receive level 2.0 when all the limits in the received > > stream are > > >> >> maxed out, you can't use anything above level 2.0 in > > >> >> profile-level-id. (You can > > >> >> *extend* it (such as with max-fs), if you also agree to > > decode the > > >> >> extension as well.) > > >> >> > > >> >> Those are the *current* semantics of profile-level-id. > > A legacy > > >> >> device may (or may not) as mentioned over-state it's > ability to > > >> >> encode. > > >> >> > > >> >> You could use an parameter that specifies the max > sending level > > >> >> supported in an offer (there's no point in an answer I > > >> believe). I > > >> >> originally proposed this. However, on reflection, > there's very > > >> >> little if anything to gain from that that I can see. A > > receiver > > >> >> could respond to > > >> >> level-upgrade-allowed=1 (or > level-asymmetry-allowed=1) with the > > >> >> highest level it can receive. Now each side knows the > > >> highest level > > >> >> the other can receive, and can send up to that level. > The only > > >> >> downside I can possibly think of to not knowing the > > >> maximum sending > > >> >> ability is that a receiver could perhaps not allocate as many > > >> >> resources if it knew the offerer couldn't send above level N. > > >> >> Example: > > >> >> > > >> >> A: Can receive level 2.0 (small LCD perhaps), can > send level 3.0 > > >> >> B: Can receive level 5.0, can send level 3.0 (more > > common form of > > >> >> send/recv > > >> >> asymmetry) > > >> >> > > >> >> A offers to be with > > >> profile-level-id=420014;level-asymmetry-allowed=1 > > >> >> B answers with profile-level-id=420032 > > >> >> > > >> >> A will send at level 3.0 > > >> >> B will send at level 2.0 (and must allocate resources to > > >> potentially > > >> >> receive 5.0) > > >> >> > > >> >> If you had a maximum-send-level parameter: > > >> >> > > >> >> A offers to be with profile-level-id=420014;sprop-max-level=1E > > >> >> B answers with profile-level-id=42001E > > >> >> > > >> >> A will send at level 3.0 > > >> >> B will send at level 2.0 (and only has to allocate > > resources for > > >> >> level 3.0) > > >> >> > > >> >> > > >> >> The question is "is it worth it"? Also, while this > may let you > > >> >> limit resources, you may also limit the options of the sender. > > >> >> For example, in the first case above, since A knows B > > can receive > > >> >> 5.0, A could send a higher frame size than 3.0 supports > > (perhaps > > >> >> at a lower framerate), even though A can't support > > sending "full" level 3.1. > > >> >> > > >> >> I should also note that quantizing the maximum level > > you can send > > >> >> is VERY subjective/arbitrary, because of how the > > encoding works. > > >> >> See the discussion above about how you don't have to > > max out the > > >> >> level you're supposedly sending. > > >> >> > > >> >> So my suggestion is to use level-asymmetry-allowed. (See my > > >> >> previous post for how this differs from > > level-upgrade-allowed - it > > >> >> allows asymmetric levels on level downgrade as well, which is > > >> >> actually probably a more common case.) > > >> >> > > >> >> >That suggests that profile-level-id should retain > its current > > >> >> >semantics, and one or two new parameters (only one of > > >> which would be > > >> >> >present in the offer or answer) would indicate two things: > > >> >> >a) a value which is higher than the value given in > > >> profile-level-id; > > >> >> >b) whether that value is a send or receive capability. > > >> >> > > > >> >> >If it's just one parameter, it would have to be double > > >> valued e.g., > > >> >> >alternate-level-id="send,<value>". > > >> >> > > > >> >> >If it is two parameters, the appropriate parameter to > > >> include would > > >> >> >depend on which whether the capability being reported > > is send or > > >> >> >receive, e.g., send-level-id=<value> > > >> >> >or recv-level-id=<value > > >> >> >but never both in the same stream. > > >> >> > > > >> >> >Ye-Kui Wang wrote: > > >> >> >> Another interoperability issue relates to the semantics > > >> >> change of the > > >> >> >> level part of profile-level-id. Currently, the level part, > > >> >> when used > > >> >> >> capability exchange or session setup, gives the upper > > >> >> limit of both > > >> >> >> decoding capability and encoding capability, as seen > > from the > > >> >> >> following two paragraphs excerpted from the bis draft (the > > >> >> same in spirit in 3984): > > >> >> >> > > >> >> >> "The profile-level-id parameter indicates the default > > >> sub-profile, > > >> >> >> i.e. the subset of coding tools that may have been used to > > >> >> generate > > >> >> >> the stream or that the receiver supports, and the > > >> default level of > > >> >> >> the stream or the receiver supports." > > >> >> >> > > >> >> >> "If the profile-level-id parameter is used for capability > > >> >> exchange or > > >> >> >> session setup procedure, it indicates the subset of > > >> coding tools, > > >> >> >> which is equal to the default sub-profile, and the > > >> highest level, > > >> >> >> which is equal to the default level, that the codec > > >> supports. All > > >> >> >> levels lower than the default level are also supported by > > >> >> the codec. " > > >> >> >> > > >> >> >> When level upgrade is allowed, then this semantics must > > >> >> change, such > > >> >> >> that the level part basically indicates only the decoding > > >> >> capability. > > >> >> >> This change of course creates different understandings > > >> between the > > >> >> >> two sides whenever one is legacy and the other is new. > > >> >> >> > > >> >> >> We have at least the following options to go to > > allow for level > > >> >> >> upgrade (the semantics change above is anyway > > needed): - To add > > >> >> >> "level-upgrade-allowed". - To add "level-upgrade-allowed" > > >> >> and another > > >> >> >> parameter, say sending-capability-level, to indicate > > >> the sending > > >> >> >> capability expressed as a level value. - To go wildly, by > > >> >> making all > > >> >> >> paramters not starting with "sprop-" as receiving > > capabilities. > > >> >> >> Another group of parameters not starting with > > "sprop-" can be > > >> >> >> optionally used to indicate sending capabilities. When > > >> >> these sending > > >> >> >> capability parameters are not present, the sending > > >> >> capabilities are > > >> >> >> by default equal to the receiving capabilties. > > >> >> >> > > >> >> >> A decision needs to be made which one to take. > > >> >> >> > > >> >> >> In any case, I hope a proponent could provide relatively > > >> >> mature text, > > >> >> >> including changes to semantics, offer/answer rules > > (including > > >> >> >> parameter sets considerations in offer/answer), > > >> declarative usage, > > >> >> >> SDP examples, and discussion of backward > > compatibility issues. > > >> >> >> > > >> >> >> Note that all the changes will also affect the SVC payload > > >> >> draft, as > > >> >> >> they basically need to be appropriately integrated to the > > >> >> SVC payload draft. > > >> >> >> > > >> >> >> BR, YK > > >> >> >> > > >> >> >... > > >> >> >_______________________________________________ > > >> >> >Audio/Video Transport Working Group avt@ietf.org > > >> >> >https://www.ietf.org/mailman/listinfo/avt > > >> >> > > >> >> > > >> >> -- > > >> >> Randell Jesup, Worldgate (developers of the Ojo > > >> videophone), ex-Amiga > > >> >> OS team rjesup@wgate.com "The fetters imposed on liberty > > >> at home have > > >> >> ever been forged out of the weapons provided for > > defence against > > >> >> real, pretended, or imaginary dangers from abroad." > > >> >> - James Madison, 4th US president (1751-1836) > > >> >> > > >> >> _______________________________________________ > > >> >> Audio/Video Transport Working Group avt@ietf.org > > >> >> https://www.ietf.org/mailman/listinfo/avt > > >> >> > > >> > > >> > > >> -- > > >> Randell Jesup, Worldgate (developers of the Ojo > > videophone), ex-Amiga > > >> OS team rjesup@wgate.com "The fetters imposed on liberty > > at home have > > >> ever been forged out of the weapons provided for defence against > > >> real, pretended, or imaginary dangers from abroad." > > >> - James Madison, 4th US president (1751-1836) > > >> > > >> > > > > > > -- > > Randell Jesup, Worldgate (developers of the Ojo > videophone), ex-Amiga > > OS team rjesup@wgate.com "The fetters imposed on liberty at > home have > > ever been forged out of the weapons provided for defence > against real, > > pretended, or imaginary dangers from abroad." > > - James Madison, 4th US president (1751-1836) > > > > > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > > From Even.roni@huawei.com Sat May 23 15:36:27 2009 Return-Path: <Even.roni@huawei.com> X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 666713A6A8B for <avt@core3.amsl.com>; Sat, 23 May 2009 15:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.883 X-Spam-Level: X-Spam-Status: No, score=0.883 tagged_above=-999 required=5 tests=[AWL=-0.482, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xXDOvBYOf+my for <avt@core3.amsl.com>; Sat, 23 May 2009 15:36:26 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 8E01F3A6910 for <avt@ietf.org>; Sat, 23 May 2009 15:36:26 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KK400NZAC771S@szxga01-in.huawei.com> for avt@ietf.org; Sun, 24 May 2009 06:37:55 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KK400GWFC77YI@szxga01-in.huawei.com> for avt@ietf.org; Sun, 24 May 2009 06:37:55 +0800 (CST) Received: from windows8d787f9 (bzq-79-179-42-107.red.bezeqint.net [79.179.42.107]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KK400CLPC6V0T@szxml02-in.huawei.com>; Sun, 24 May 2009 06:37:55 +0800 (CST) Date: Sun, 24 May 2009 01:36:41 +0300 From: Roni Even <Even.roni@huawei.com> In-reply-to: <p0624080bc63cffcf77fe@[10.0.1.8]> To: 'David Singer' <singer@apple.com>, avt@ietf.org Message-id: <02c801c9dbf6$ff8d2e10$fea78a30$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcnbRZeiaSyjxm4qTyOZyzRQnwviNAArzydg References: <302f570905221154t7feb4162s6728f9dc2c736592@mail.gmail.com> <C63C617C.372F%luby@qualcomm.com> <31d1be720905221451t844a033ufe37b44884b56f83@mail.gmail.com> <302f570905221508q637770ebi89582187526d1594@mail.gmail.com> <p0624080bc63cffcf77fe@[10.0.1.8]> Subject: Re: [AVT] Comments on draft-pantos-http-live-streaming-00.txt ... X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group <avt.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/avt> List-Post: <mailto:avt@ietf.org> List-Help: <mailto:avt-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 23 May 2009 22:36:27 -0000 Hi, I find this draft interesting and also the MPEG workshop. I think that is will be good to describe first the general problem that need to be addressed before jumping to a solution and the MPEG work shop has more general scope in the topics to be considered. Industry experience of multimedia transport Delivery of media over IP networks in ptp/ptmp manner Download and random access of MP4 files MPEG TS Transport between heterogeneous network Delivery and sharing of User created contents Challenges of emerging multimedia transport environments: Peer-to-Peer (P2P) traffic for IPTV services Cross-layer designs to improve the Quality of Service/Experience (QoS/QoE) Context- and Content-Aware Networks Conversion between a stream and a randomly accessible file We can continue to discuss this in the AVT mailing list but I am trying to see what is the place for the work since it relates also to other working group. I hope that you are all aware on the p2p streaming discussion that took place in the last two IETF meetings as BAR BOFs. Regards Roni Even -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of David Singer Sent: Saturday, May 23, 2009 4:26 AM To: avt@ietf.org Subject: Re: [AVT] Comments on draft-pantos-http-live-streaming-00.txt ... Well, not really comments on the draft; more to thank Mike for pointing out that there is a 'question' in the industry, and that perhaps existing techniques ('pure' RTP or MPEG-2 Transport or existing file download) are not working so well. A few people at MPEG have noticed this as well, and are also asking the question. It's by no means clear what should be done, or where, or by whom, but they are stepping up to holding an open workshop. I don't get the sense from the organizers that there is any kind of 'position' being taken here (yet), not even on whether or where something should be done, let alone what. Have a look at this page and see whether some of you would like to write something (separately, jointly), or attend: <http://multimediacommunication.blogspot.com/2009/04/workshop-on-mmt-modern- media-transport.html> -- David Singer Multimedia Standards, Apple Inc. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www.ietf.org/mailman/listinfo/avt From gherlein@herlein.com Sat May 23 16:19:46 2009 Return-Path: <gherlein@herlein.com> X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 163763A696F for <avt@core3.amsl.com>; Sat, 23 May 2009 16:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.908 X-Spam-Level: X-Spam-Status: No, score=-0.908 tagged_above=-999 required=5 tests=[AWL=-0.421, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUQxVKj+uDeo for <avt@core3.amsl.com>; Sat, 23 May 2009 16:19:45 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.225]) by core3.amsl.com (Postfix) with ESMTP id 391C03A67E5 for <avt@ietf.org>; Sat, 23 May 2009 16:19:44 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id g37so730048rvb.49 for <avt@ietf.org>; Sat, 23 May 2009 16:21:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.11.11 with SMTP id o11mr1864943wfi.193.1243120883344; Sat, 23 May 2009 16:21:23 -0700 (PDT) In-Reply-To: <02c801c9dbf6$ff8d2e10$fea78a30$%roni@huawei.com> References: <302f570905221154t7feb4162s6728f9dc2c736592@mail.gmail.com> <C63C617C.372F%luby@qualcomm.com> <31d1be720905221451t844a033ufe37b44884b56f83@mail.gmail.com> <302f570905221508q637770ebi89582187526d1594@mail.gmail.com> <p0624080bc63cffcf77fe@10.0.1.8> <02c801c9dbf6$ff8d2e10$fea78a30$%roni@huawei.com> Date: Sat, 23 May 2009 16:21:23 -0700 Message-ID: <31d1be720905231621l2b986becw9c64cd1a08d90f0a@mail.gmail.com> From: Greg Herlein <gherlein@herlein.com> To: Roni Even <Even.roni@huawei.com> Content-Type: multipart/alternative; boundary=001636e0b96daa254f046a9ca2b3 Cc: David Singer <singer@apple.com>, avt@ietf.org Subject: Re: [AVT] Comments on draft-pantos-http-live-streaming-00.txt ... X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group <avt.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/avt> List-Post: <mailto:avt@ietf.org> List-Help: <mailto:avt-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 23 May 2009 23:19:46 -0000 --001636e0b96daa254f046a9ca2b3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit > > > > I hope that you are all aware on the p2p streaming discussion that took > > place in the last two IETF meetings as BAR BOFs. > Are there minutes of the p2p streaming meetings? -- Greg Herlein www.herlein.com --001636e0b96daa254f046a9ca2b3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"borde= r-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-le= ft: 1ex;"><br>> I hope that you are all aware on the p2p streaming discu= ssion that took<br> > place in the last two IETF meetings as BAR BOFs.<br> </blockquote><div><br>Are there minutes of the p2p streaming meetings?<br>= =A0 </div></div>-- <br>Greg Herlein<br><a href=3D"http://www.herlein.com">www.h= erlein.com</a><br> --001636e0b96daa254f046a9ca2b3-- From victor.pascual.avila@gmail.com Sun May 24 00:30:26 2009 Return-Path: <victor.pascual.avila@gmail.com> X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 611B63A6DD7 for <avt@core3.amsl.com>; Sun, 24 May 2009 00:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.258 X-Spam-Level: X-Spam-Status: No, score=-2.258 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oo7gL+rK3WKL for <avt@core3.amsl.com>; Sun, 24 May 2009 00:30:25 -0700 (PDT) Received: from mail-fx0-f168.google.com (mail-fx0-f168.google.com [209.85.220.168]) by core3.amsl.com (Postfix) with ESMTP id 1E24E3A6940 for <avt@ietf.org>; Sun, 24 May 2009 00:30:24 -0700 (PDT) Received: by fxm12 with SMTP id 12so670483fxm.37 for <avt@ietf.org>; Sun, 24 May 2009 00:32:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=9/rT33NfGtZmcoz0yZcQKriKc4p5lMvtFL0QGwxjEUs=; b=PJbIHE8eQCx+lunJBTJyrC7/aWk5Cotb1SGajsda/oNXThxN2GdXhKrd4fXkEzdEG9 uVMstGa0p3IjjsLm82AeiYvKpzpu31euepk8v1g+KFqhd9uwjmc2hsy6f98JxzUYYlEY qYiwppRkXLBrvrffVBnpkJJRkEkT1v/G+eE28= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=RlT4wZJ1og7c4USt+I2PHjwumPoJ3YLeRCyAfoIWjiD4yDMXtdQy/1A08k1dqbB5/a R19azu58yo/hBh0VkZhgxvlrof9LsmFAylODk0YBekUCumkDzcBs7K7yK3J0/brIG+Fj OSD/O+dY1IWPri6tY/Gcp/a9KQAmpdN2JbkWA= MIME-Version: 1.0 Received: by 10.204.115.135 with SMTP id i7mr5510783bkq.178.1243150321642; Sun, 24 May 2009 00:32:01 -0700 (PDT) In-Reply-To: <31d1be720905231621l2b986becw9c64cd1a08d90f0a@mail.gmail.com> References: <302f570905221154t7feb4162s6728f9dc2c736592@mail.gmail.com> <C63C617C.372F%luby@qualcomm.com> <31d1be720905221451t844a033ufe37b44884b56f83@mail.gmail.com> <302f570905221508q637770ebi89582187526d1594@mail.gmail.com> <p0624080bc63cffcf77fe@10.0.1.8> <02c801c9dbf6$ff8d2e10$fea78a30$%roni@huawei.com> <31d1be720905231621l2b986becw9c64cd1a08d90f0a@mail.gmail.com> Date: Sun, 24 May 2009 09:32:01 +0200 Message-ID: <618e24240905240032k7048df35ldde7cdd5f4c89b73@mail.gmail.com> From: =?UTF-8?Q?Victor_Pascual_=C3=81vila?= <victor.pascual.avila@gmail.com> To: Greg Herlein <gherlein@herlein.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: David Singer <singer@apple.com>, Roni Even <Even.roni@huawei.com>, avt@ietf.org Subject: Re: [AVT] Comments on draft-pantos-http-live-streaming-00.txt ... X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group <avt.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/avt> List-Post: <mailto:avt@ietf.org> List-Help: <mailto:avt-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 24 May 2009 07:30:26 -0000 On Sun, May 24, 2009 at 1:21 AM, Greg Herlein <gherlein@herlein.com> wrote: >> >> > I hope that you are all aware on the p2p streaming discussion that too= k >> > place in the last two IETF meetings as BAR BOFs. > > Are there minutes of the p2p streaming meetings? http://www.ietf.org/mail-archive/web/ppsp/current/msg00158.html http://www.ietf.org/mail-archive/web/ppsp/current/msg00157.html More info: http://labs.chinamobile.com/ppsp/ietf Cheers, --=20 Victor Pascual =C3=81vila From versteb@cisco.com Sun May 24 03:00:11 2009 Return-Path: <versteb@cisco.com> X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5851E3A705E for <avt@core3.amsl.com>; Sun, 24 May 2009 03:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.125 X-Spam-Level: X-Spam-Status: No, score=-4.125 tagged_above=-999 required=5 tests=[AWL=-2.385, BAYES_20=-0.74, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qD20sR3hdO1K for <avt@core3.amsl.com>; Sun, 24 May 2009 03:00:09 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id A0FBA3A6FDD for <avt@ietf.org>; Sun, 24 May 2009 03:00:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,239,1241395200"; d="scan'208";a="45073612" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 24 May 2009 10:01:48 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n4OA1m82019486; Sun, 24 May 2009 06:01:48 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n4OA1mbW013711; Sun, 24 May 2009 10:01:48 GMT Received: from xmb-rtp-21d.amer.cisco.com ([64.102.31.116]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 24 May 2009 06:01:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 24 May 2009 06:01:46 -0400 Message-ID: <81B9B88E2F9D574AA5328A85547CDE910142F016@xmb-rtp-21d.amer.cisco.com> In-Reply-To: <02a001c9dba0$a5559730$f000c590$%roni@huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available Thread-Index: AcnaYqqjHO1LimacStOS+9HZ8wJeMAADPRKQABOigeAADM4YEAArEjmQAC3tpCA= References: <81B9B88E2F9D574AA5328A85547CDE9101071D80@xmb-rtp-21d.amer.cisco.com> <49f1a1d6.190c660a.58fe.ffffa90e@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C80DA@xmb-sjc-215.amer.cisco.com> <49f208e8.05a0660a.5bd2.6764@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C81C9@xmb-sjc-215.amer.cisco.com> <49f211fc.07a5660a.3f7f.ffff8f4a@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8202@xmb-sjc-215.amer.cisco.com> <49f2efa2.1c215e0a.4454.ffffaf91@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8403@xmb-sjc-215.amer.cisco.com> <49f36ee2.0437560a.11df.1eef@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8405@xmb-sjc-215.amer.cisco.com> <49f387ca.0305560a.6657.4be7@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C840A@xmb-sjc-215.amer.cisco.com> <4A15D40E.80509@eu.panasonic.com> <04CAD96D4C5A3D48B1919248A8FE0D54095E153A@xmb-sjc-215.amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB011BF41B@lan-ex-02.panasonic.de> <04CAD96D4C5A3D48B1919248A8FE0D54095E18BB @xmb-sjc -.com> <02a001c9dba0$a5559730$f000c590$%roni@huawei.com> From: "Bill Ver Steeg (versteb)" <versteb@cisco.com> To: "Roni Even" <Even.roni@huawei.com>, "Ali C. Begen (abegen)" <abegen@cisco.com>, "Jose Rey" <Jose.Rey@eu.panasonic.com> X-OriginalArrivalTime: 24 May 2009 10:01:48.0212 (UTC) FILETIME=[A6E56740:01C9DC56] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=21402; t=1243159308; x=1244023308; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=versteb@cisco.com; z=From:=20=22Bill=20Ver=20Steeg=20(versteb)=22=20<versteb@ci sco.com> |Subject:=20RE=3A=20[AVT]=20New=20draft=20of=20=22Rapid=20A cquisition=20of=20Multicast=09RTPSessions=09(RAMS)=22=20avai lable |Sender:=20 |To:=20=22Roni=20Even=22=20<Even.roni@huawei.com>,=0A=20=20 =20=20=20=20=20=20=22Ali=20C.=20Begen=20(abegen)=22=20<abege n@cisco.com>,=0A=20=20=20=20=20=20=20=20=22Jose=20Rey=22=20< Jose.Rey@eu.panasonic.com>; bh=HmyEY0PNoTZtw/rY4W+wHhSFaZgKVAS9k5a6TZlBIW0=; b=ov2ao9PAKqsvsMKuYeTgDcMCWOiZkegse3E77Z+HugHAVT04F1gykHbPLs wwPUd4d8Kca7KsXHk/NyG6TIKhucZZ/S2ZeTvWhdZWnKYx3m0bltm3DG5+Am +F8hTJUTlW; Authentication-Results: rtp-dkim-1; header.From=versteb@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: Roni Even <ron.even.tlv@gmail.com>, avt@ietf.org Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group <avt.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/avt> List-Post: <mailto:avt@ietf.org> List-Help: <mailto:avt-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 24 May 2009 10:00:11 -0000 Roni- Regarding the RS being able to send data to the RR after receiving a = RAMS-R. There is a subtle point here, which you reference in your comment "need = to provide a reachable transport address". The RR sends the RAMS-R to = the feedback target UDP port number. In the presence of NAT, the only = communication path that is opened automatically is that single path. In = order to use the other port-pairs, holes must be poked in the NAT and = the correct NAT-ed ports must be signaled. As you know, there are many = ways to poke wholes in NAT, so we will not go into the details of how to = do that. This is an important point, and we will be sure to make it more clear in = the next draft. Bvs -----Original Message----- From: Roni Even [mailto:Even.roni@huawei.com]=20 Sent: Saturday, May 23, 2009 8:19 AM To: Ali C. Begen (abegen); 'Jose Rey' Cc: 'Roni Even'; avt@ietf.org; Bill Ver Steeg (versteb) Subject: RE: [AVT] New draft of "Rapid Acquisition of Multicast = RTPSessions (RAMS)" available Hi, I also have concerns about having the unicast Transport addresses for = the RR RTCP and RTP receive port. I think that we should first talk about the NAT/FW issue and than define = the requirements and solutions. My assumption is that the retransmission server has a publicly reachable = address while the receivers may sit behind NATs and will not have a = publicly reachable address. Note that the RAMS flow starts from the receiver by RAMS-R so a response = to the transport address from where the RAMS-R came should work (RTCP is = bi-directional in this case). On the other hand the unicast data flow is = to the receiver so the receiver will need to provide a reachable = transport address. Roni -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Ali C. Begen (abegen) Sent: Saturday, May 23, 2009 3:27 AM To: Jose Rey Cc: Roni Even; avt@ietf.org; Bill Ver Steeg (versteb) Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast = RTPSessions (RAMS)" available Hi Jose, Indeed, RAMS-R goes to the FT of the new primary session that RR is = interested in acquiring rapidly. Then the unicast session becomes alive = and RS sends RAMS-I message(s) to RR on the RTCP port for the unicast = session. After some time, RR sends the RAMS-T message to the RTCP port for the = unicast session since it is supposed to end the unicast session.=20 -acbegen > -----Original Message----- > From: Jose Rey [mailto:Jose.Rey@eu.panasonic.com] > Sent: Friday, May 22, 2009 7:09 AM > To: Ali C. Begen (abegen) > Cc: Roni Even; avt@ietf.org; Bill Ver Steeg (versteb) > Subject: RE: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" > available >=20 >=20 > Hi Ali, >=20 > > > > Hi Jose, > > > > We have separate RTCP ports for the SSM session and the unicast=20 > > session. Why is it a problem? >=20 > In line 19 you say you specify the dst port for RMS-I (41003), on RR.=20 > And you say that > would also be the port where the RR sends RMS-T, on RS. That is mixing = > the semantics of > a=3Drtcp for SSM (listening port at Feedback Target =3D mcast RTCP dst = > port) and those of RFC > 3605 (dst port). In other words, you are implicitly assuming that specifies symmetric > RTCP...no? >=20 > Another thing that was mentioned already: RMS-T is not sent to same=20 > port as RMS-R; is it > not the same RTCP session ? Or is this muxing desired? why? >=20 > JLR >=20 > > > > The slightly modified SDP for the next version is below: > > > 1> a=3Dgroup:FID 3 4 > 2> a=3Drtcp-unicast:rsi > 3> m=3Dvideo 41000 RTP/AVPF 98 > 4> i=3DPrimary Multicast Stream #2 > 5> c=3DIN IP4 233.252.0.2/255 > 6> a=3Dsource-filter: incl IN IP4 233.252.0.2 192.0.2.2 > 7> a=3Drecvonly > 8> a=3Drtpmap:98 MP2T/90000 > 9> a=3Drtcp:41001 IN IP4 192.0.2.1 > 10> a=3Drtcp-fb:98 nack > 11> a=3Drtcp-fb:98 nack ssli > 12> a=3Dssrc:123321 cname:iptv-ch32@rams.example.com > 13> a=3Dmid:3 > 14> m=3Dvideo 41002 RTP/AVPF 99 > 15> i=3DUnicast Retransmission Stream #2 (Ret. and Rapid > > Acq. Support) > 16> c=3DIN IP4 192.0.2.1 > 17> a=3Drecvonly > 18> a=3Drtpmap:99 rtx/90000 > 19> a=3Drtcp:41003 > 20> a=3Dfmtp:99 apt=3D98; rtx-time=3D5000 > 21> a=3Dmid:4 > > > > This is the SDP we send to RR. For RS, a=3Drecvonly will be = a=3Dsendonly. > > > > -acbegen > > > > > > > -----Original Message----- > > > From: Jos=E9 Rey [mailto:jose.rey@eu.panasonic.com] > > > Sent: Thursday, May 21, 2009 3:22 PM > > > To: Ali C. Begen (abegen) > > > Cc: Roni Even; avt@ietf.org; Bill Ver Steeg (versteb) > > > Subject: Re: [AVT] New draft of "Rapid Acquisition of > > Multicast RTPSessions (RAMS)" > > > available > > > > > > Hi all, > > > > > > sorry for jumping in.... > > > > > > I think one of the sources of confusion is that the > > attribute a=3Drtcp: > > > is used once for specifying the destination port and once for=20 > > > specifying a receiving port, and in the same SDP (!). The > > destination > > > port for RAMS-I packets sent by RS and the receiving port > > for RAMS-T. Which is also why different port numbers are used for=20 > > RAMS-T and -R packets. > > > > > > I think the use of a=3Drtcp: in SSM is the problem here. Or the = fact=20 > > > that we are mixing unicast and multicast, or both. > > > > > > Hope this helps, > > > > > > JLR > > > > > > > > > > > > > > > Ali C. Begen (abegen) wrote: > > > > > > > > > > > > > > > > > > -----Original Message----- > > > From: Roni Even [mailto:ron.even.tlv@gmail.com] > > > Sent: Saturday, April 25, 2009 2:58 PM > > > To: Ali C. Begen (abegen); avt@ietf.org > > > Cc: Bill Ver Steeg (versteb) > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of > > > Multicast RTPSessions (RAMS)" available > > > > > > Ali, > > > I looked at RFC 4570 and I assume that port > > 41001 is the port for the > > > unicast RTCP reports from the receivers and according to > > > > > > > > > > > > Yes, indeed. > > > > > > > > > > > > section 3.2.1 of > > > that RFC you also should have a RTCP-unicast > > specification. > > > This is for the > > > multicast receiver reports. > > > > > > > > > > > > Correct. We do have that line in our draft at the top > > right after the grouping lines: > > > > > > a=3Drtcp-unicast:rsi > > > > > > BR, > > > -acbegen > > > > > > > > > > > > Roni > > > > > > -----Original Message----- > > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > > Sent: Saturday, April 25, 2009 11:30 PM > > > To: Roni Even; avt@ietf.org > > > Cc: Bill Ver Steeg (versteb) > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of > > > Multicast RTPSessions > > > (RAMS)" available > > > > > > Here is the SDP. > > > > > > m=3Dvideo 41000 RTP/AVPF 98 > > > i=3DPrimary Multicast Stream #2 > > > c=3DIN IP4 224.1.1.2/255 > > > a=3Dsource-filter: incl IN IP4 224.1.1.2 192.0.2.2 > > > > > > Source (192.0.2.2) sends the rtp packets to the > > multicast > > > group (224.1.1.2) > > > with a dest port 41000. > > > > > > a=3Drtpmap:98 MP2T/90000 > > > a=3Drtcp:41001 IN IP4 192.0.2.1 > > > > > > The feedback target (RS) address for this SSM session is > > > 192.0.2.1 and its > > > port is 41001. This is the address/port where > > RR sends the RAMS-R, or > > > receiver reports for the SSM session. > > > > > > a=3Drtcp-fb:98 nack > > > a=3Drtcp-fb:98 nack ssli > > > a=3Dssrc:123321 cname:iptv-ch32@rams.example.com > > > a=3Dmid:3 > > > m=3Dvideo 41002 RTP/AVPF 99 > > > > > > The retransmission packets go to port 41002. > > This is the port > > > RRs listen to > > > for retransmission and RAMS. > > > > > > i=3DUnicast Retransmission Stream #2 > > (Ret. and Rapid > > > Acq. Support) > > > c=3DIN IP4 192.0.2.1 > > > > > > This is where the retransmission packets come > > from, same as > > > the feedback > > > target (in this example). > > > > > > a=3Drtpmap:99 rtx/90000 > > > a=3Drtcp:41003 > > > > > > This is where the RTCP packets for the > > retransmission session go. For > > > example, RAMS-I goes to this port on RRs. > > RAMS-T goes to this > > > port on RS. > > > > > > a=3Dfmtp:99 apt=3D98; rtx-time=3D5000 > > > a=3Dmid:4 > > > > > > > > > -acbegen > > > > > > > > > > > > > > > -----Original Message----- > > > From: Roni Even [mailto:ron.even.tlv@gmail.com] > > > Sent: Saturday, April 25, 2009 1:11 PM > > > To: Ali C. Begen (abegen); avt@ietf.org > > > Cc: Bill Ver Steeg (versteb) > > > Subject: RE: [AVT] New draft of "Rapid > > Acquisition of > > > Multicast RTPSessions (RAMS)" available > > > > > > Ali, > > > Can you please write three addresses > > from this strange SDP. > > > > > > 1. The address and port of multicast > > > > > > 2. The address and port of the RS where > > the RTCP FB should go to > > > > > > 3. The address and port on the RR where > > the unicast stream > > > should be sent to > > > > > > Roni > > > > > > -----Original Message----- > > > From: Ali C. Begen (abegen) > > [mailto:abegen@cisco.com] > > > Sent: Saturday, April 25, 2009 11:02 PM > > > To: Roni Even; avt@ietf.org > > > Cc: Bill Ver Steeg (versteb) > > > Subject: RE: [AVT] New draft of "Rapid > > Acquisition of > > > Multicast RTPSessions > > > (RAMS)" available > > > > > > > > > > > > Ali, > > > The example SDP is > > syntactically correct but it does not > > > > > > > > > say that the > > > > > > > > > rtp/rtcp mux will be used and > > it does not give the > > > information to where the > > > unicast stream will be sent > > when the RR sends a RAMS-R. > > > > > > > > > To my knowledge, the first line in the > > following SDP tells > > > the RRs on which > > > port they will receive the > > retransmission/burst packets. > > > > > > m=3Dvideo 41002 RTP/AVPF 99 > > > i=3DUnicast Retransmission Stream > > #2 (Ret. and Rapid > > > Acq. Support) > > > c=3DIN IP4 192.0.2.1 > > > a=3Drtpmap:99 rtx/90000 > > > a=3Drtcp:41003 > > > a=3Dfmtp:99 apt=3D98; rtx-time=3D5000 > > > a=3Dmid:4 > > > > > > There is a typo, you are right. That > > "a=3Drecvonly" line should > > > only exist in > > > the SDP sent to RRs. In the SDP sent to > > RS, we should rather have > > > "a=3Dsendonly". I will make this > > correction in the next version. > > > > > > The feedback target for the SSM session > > and the RTCP port for the > > > retransmission session are also defined > > in the SDP. > > > > > > Hope this clarifies. > > > > > > BR, > > > -acbegen > > > > > > > > > > > > I am not sure why the unicast > > stream m-line has a port > > > > > > > > > number with an > > > > > > > > > attribute of recvonly. What is > > the use case for that. The > > > only information > > > that the RR will need is the > > RTCP port on the RS to where to > > > send the RAMS-R > > > message. > > > Roni > > > -----Original Message----- > > > From: Ali C. Begen (abegen) > > [mailto:abegen@cisco.com] > > > Sent: Friday, April 24, 2009 10:37 PM > > > To: Roni Even; avt@ietf.org > > > Cc: Bill Ver Steeg (versteb) > > > Subject: RE: [AVT] New draft of > > "Rapid Acquisition of > > > Multicast RTPSessions > > > (RAMS)" available > > > > > > This is a part of an example > > SDP sent to RS and RR in a SAP > > > announcement, > > > for example. So, the SDP > > describes what both parties should > > > do (RR cannot > > > say that he wants to receive > > this multicast on its favorite > > > > > > > > > port). The > > > > > > > > > individual SDPs sent to RR or > > RS may include other portions > > > of descriptions > > > that will contain specific information. > > > > > > -acbegen > > > > > > > > > > > > -----Original Message----- > > > From: Roni Even > > [mailto:ron.even.tlv@gmail.com] > > > Sent: Friday, April 24, > > 2009 12:23 PM > > > To: Ali C. Begen > > (abegen); avt@ietf.org > > > Cc: Bill Ver Steeg (versteb) > > > Subject: RE: [AVT] New > > draft of "Rapid Acquisition of > > > Multicast RTPSessions > > (RAMS)" available > > > > > > Ali, > > > I think you get it > > wrong, this SDP is from the RS and not the > > > RR so the RS > > > cannot specify to which > > address it will send it can only > > > specify to which > > > address it can receive > > RTP stream. In this SDP the relevant > > > information is > > > that the request for > > retransmission will be sent by the RR to > > > port 41003 > > > Roni > > > > > > -----Original Message----- > > > From: Ali C. Begen > > (abegen) [mailto:abegen@cisco.com] > > > Sent: Friday, April 24, > > 2009 10:01 PM > > > To: Roni Even; avt@ietf.org > > > Cc: Bill Ver Steeg (versteb) > > > Subject: RE: [AVT] New > > draft of "Rapid Acquisition of > > > Multicast RTPSessions > > > (RAMS)" available > > > > > > Oh, I see. The burst > > goes to the port that we would > > > > > > > > > normally send the > > > > > > > > > retransmissions. For > > example, consider the SDP from the draft: > > > > > > m=3Dvideo 41000 > > RTP/AVPF 98 > > > i=3DPrimary > > Multicast Stream #2 > > > c=3DIN IP4 224.1.1.2/255 > > > > > a=3Dsource-filter: incl IN IP4 224.1.1.2 192.0.2.2 > > > a=3Drtpmap:98 MP2T/90000 > > > a=3Drtcp:41001 IN > > IP4 192.0.2.1 > > > a=3Drtcp-fb:98 nack > > > a=3Drtcp-fb:98 nack ssli > > > a=3Dssrc:123321 > > cname:iptv-ch32@rams.example.com > > > a=3Dmid:3 > > > m=3Dvideo 41002 > > RTP/AVPF 99 > > > i=3DUnicast > > Retransmission Stream #2 (Ret. and Rapid > > > Acq. Support) > > > c=3DIN IP4 192.0.2.1 > > > a=3Drecvonly > > > a=3Drtpmap:99 rtx/90000 > > > a=3Drtcp:41003 > > > a=3Dfmtp:99 > > apt=3D98; rtx-time=3D5000 > > > a=3Dmid:4 > > > > > > In this case, the burst > > will go to port 41002 on the RR. > > > > > > > > > The RAMS-I > > > > > > > > > message(s), which is an > > RTCP feedback message, will go to > > > > > > > > > port 41003. > > > > > > > > > HTH, > > > -acbegen > > > > > > > > > > > > -----Original > > Message----- > > > From: Roni Even > > [mailto:ron.even.tlv@gmail.com] > > > Sent: Friday, > > April 24, 2009 11:44 AM > > > To: Ali C. > > Begen (abegen); avt@ietf.org > > > Cc: Bill Ver > > Steeg (versteb) > > > Subject: RE: > > [AVT] New draft of "Rapid Acquisition of > > > Multicast > > RTPSessions (RAMS)" available > > > > > > Ali, > > > I will try to > > explain in simple way > > > > > > When the RS > > receives the RAMS-R it need to start sending an > > > RTP stream to > > > the RR. > > > In order to > > send a unicast packet, the RS needs to know a > > > transport address > > > on the RR to > > where the RTP stream will be sent. The current > > > draft does not > > > say how the RS > > knows this address. There is no SDP from RR to > > > RS like you > > > mention in your > > response. > > > This is why I > > say that the current draft does not specify a > > > solution that > > > can be > > implemented as a working solution > > > Roni > > > > > > -----Original > > Message----- > > > From: Ali C. > > Begen (abegen) [mailto:abegen@cisco.com] > > > Sent: Friday, > > April 24, 2009 7:38 PM > > > To: Roni Even; > > avt@ietf.org > > > Cc: Bill Ver > > Steeg (versteb) > > > Subject: RE: > > [AVT] New draft of "Rapid Acquisition of > > > Multicast RTPSessions > > > (RAMS)" available > > > > > > Hi Roni, > > > > > > > > > > > > > > -----Original Message----- > > > From: > > avt-bounces@ietf.org [mailto:avt- bounces@ietf.org] On > > > Behalf > > Of Roni Even > > > Sent: > > Friday, April 24, 2009 4:24 AM > > > To: avt@ietf.org > > > Cc: > > Bill Ver Steeg (versteb) > > > > > Subject: Re: [AVT] New draft of "Rapid Acquisition of > > > > > Multicast RTPSessions (RAMS)" available > > > > > > Hi, > > > > > > I think > > that the current draft does not give a > > > > > > > > > description of > > > > > > > > > a > > system that works since there is no text > > > > > > > > > explaining how the > > > > > > > > > What do you > > mean by "a system that works"? > > > > > > > > > > > > RS > > knows the unicast transport address on the RR to > > > > > > > > > where to > > > > > > > > > send the stream. > > > > > > > > > Once RS > > receives the request packet from an RR, RS knows its > > > address. Ports > > > are defined in > > the SDP. If you are asking about "NAT" > > > issues, > > > we have a > > > section for it, > > and we plan to complete it as we move > > > forward. It is not as > > > critical as the > > other parts for now. > > > > > > > > > > > > If you > > mandate the use of RTP/RTCP mux it should say so > > > > > otherwise the RAMS-R should have an optional parameter that > > > > > supplies this information and a flag for using RTP/RTCP mux. > > > > > > > > > IMO, we cannot > > mandate muxing as it is not required to make > > > RAMS work. If > > > muxing is > > supported, the SDP should reflect it. > > > > > > BR, > > > -acbegen > > > > > > > > > > > > Thanks > > > > > > Roni Even > > > > > > > > > > > > From: > > avt-bounces@ietf.org [mailto:avt- bounces@ietf.org] On > > > Behalf > > Of Bill Ver Steeg (versteb) > > > Sent: > > Thursday, April 16, 2009 7:39 PM > > > To: avt@ietf.org > > > > > Subject: [AVT] New draft of "Rapid Acquisition of Multicast > > > RTP > > Sessions (RAMS)" available > > > > > > > > > > > > There > > is a new draft of the "Rapid Acquisition of Multicast > > > RTP > > Sessions (RAMS)" draft available at > > > > > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-versteeg-avt-rapid-s > > > > > > > > > > > ynchronization-for-rtp-03.txt > > > <http://www.ietf.org/internet-> <http://www.ietf.org/internet-> > > > > > > > > > > > > > > drafts/draft-versteeg-avt-rapid-synchronization-for-rtp-03.txt> > > > > > > > > > > > > > > > We have > > incorporated the changes from the technical > > > > > > > > > breakout > > > > > > > > > session > > in San Francisco. The major changes in this version > > > of the > > draft include > > > > > > 1- > > Changing the document title to avoid confusion > > > > > > > > > with other > > > > > > > > > ongoing > > "synchronization" drafts > > > > > > 2- > > changing the message names to reflect the title change > > > > > > 3- > > clarification of the RTCP message semantics, including > > > changes > > to the "Request" and "Inform" messages > > > > > > 4- > > additional description/motivation for the > > > > > > > > > various message > > > > > > > > > flows > > has been added > > > > > > 5- > > RTP/RTCP muxing has been added > > > > > > > > > > > > > > > > > > We hope > > to make this a Working Group item, and will change > > > the > > name of the draft to avoid conflicts with other > > > > > "synchronization" drafts at that time. > > > > > > > > > > > > Bill VerSteeg > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Audio/Video Transport Working Group > > > avt@ietf.org > > > https://www.ietf.org/mailman/listinfo/avt > > > > > > > > > > > > >=20 >=20 > Panasonic R&D Center Germany GmbH > 63225 Langen, Hessen, Germany > Reg: AG Offenbach (Hessen) HRB 33974 > Managing Director: Thomas Micke >=20 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www.ietf.org/mailman/listinfo/avt From ron.even.tlv@gmail.com Sun May 24 05:26:27 2009 Return-Path: <ron.even.tlv@gmail.com> X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B9303A6B89 for <avt@core3.amsl.com>; Sun, 24 May 2009 05:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[AWL=-1.120, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VSnbIOFQ6VPR for <avt@core3.amsl.com>; Sun, 24 May 2009 05:26:20 -0700 (PDT) Received: from mail-fx0-f168.google.com (mail-fx0-f168.google.com [209.85.220.168]) by core3.amsl.com (Postfix) with ESMTP id B2ED13A6D3C for <avt@ietf.org>; Sun, 24 May 2009 05:26:19 -0700 (PDT) Received: by fxm12 with SMTP id 12so757568fxm.37 for <avt@ietf.org>; Sun, 24 May 2009 05:27:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=CCKD5ttz0AcV2smEo+RTehaadHl/UOFYHACaazkp+eI=; b=Ko0Y/oPp/Z2zhKvwiSH7FiswXVPfhEWN9hWZ2mzyU1Yh8LneegwqVuq5GjgvAQxSeP 9ogH6lGEPqoc+Y5o0efAcASjsqVftUUzhIvIyVcrtCQTtTHzcfiMgAxvPuFrbskYbAD2 dmeWswoZDipc9TWTsG4IBcc4iwZABwfI3SOuU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=WLsNUPm8lFYwd9N4ZZwAO6VhQQEKmmTyLkz5aJueBKajER5cz3LLybdasBAnQiN8IA DPIkwf6q6A8vr0VlhTp9V693cNp9SdFG6Rtk1RqNV8KSGsmIpUrm4/CI1h03E/pC7M9D 87FW257aAy8/d1SHme80WAoHhccrCxHP/it9Q= Received: by 10.103.222.1 with SMTP id z1mr3047041muq.44.1243168071811; Sun, 24 May 2009 05:27:51 -0700 (PDT) Received: from windows8d787f9 (bzq-79-179-42-107.red.bezeqint.net [79.179.42.107]) by mx.google.com with ESMTPS id 12sm9885872muq.23.2009.05.24.05.27.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 24 May 2009 05:27:50 -0700 (PDT) From: "Roni Even" <ron.even.tlv@gmail.com> To: "'Bill Ver Steeg \(versteb\)'" <versteb@cisco.com>, "'Roni Even'" <Even.roni@huawei.com>, "'Ali C. Begen \(abegen\)'" <abegen@cisco.com>, "'Jose Rey'" <Jose.Rey@eu.panasonic.com> References: <81B9B88E2F9D574AA5328A85547CDE9101071D80@xmb-rtp-21d.amer.cisco.com> <49f1a1d6.190c660a.58fe.ffffa90e@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C80DA@xmb-sjc-215.amer.cisco.com> <49f208e8.05a0660a.5bd2.6764@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C81C9@xmb-sjc-215.amer.cisco.com> <49f211fc.07a5660a.3f7f.ffff8f4a@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8202@xmb-sjc-215.amer.cisco.com> <49f2efa2.1c215e0a.4454.ffffaf91@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8403@xmb-sjc-215.amer.cisco.com> <49f36ee2.0437560a.11df.1eef@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8405@xmb-sjc-215.amer.cisco.com> <49f387ca.0305560a.6657.4be7@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C840A@xmb-sjc-215.amer.cisco.com> <4A15D40E.80509@eu.panasonic.com> <04CAD96D4C5A3D48B1919248A8FE0D54095E153A@xmb-sjc-215.amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB011BF41B@lan-ex-02.panasonic.de> <04CAD96D4C5A3D48B1919248A8FE0D54095E18BB@ xmb-sjc -.com> <02a00 1c9dba0$a5559730$f000c590$%roni@huawei.com> <81B9B88E2F9D574AA5328A85547CDE910142F016@xmb-rtp-21d.amer.cisco.com> In-Reply-To: <81B9B88E2F9D574AA5328A85547CDE910142F016@xmb-rtp-21d.amer.cisco.com> Date: Sun, 24 May 2009 15:26:48 +0300 Message-ID: <4a193d46.0c11660a.33cc.109d@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnaYqqjHO1LimacStOS+9HZ8wJeMAADPRKQABOigeAADM4YEAArEjmQAC3tpCAABUzVwA== Content-Language: en-us Cc: avt@ietf.org Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group <avt.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/avt> List-Post: <mailto:avt@ietf.org> List-Help: <mailto:avt-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 24 May 2009 12:26:27 -0000 Bill, My major point here is this is a reason for having an option port or transport address parameter in the RAMS-R allowing the RR to provide = such address. Roni -----Original Message----- From: Bill Ver Steeg (versteb) [mailto:versteb@cisco.com]=20 Sent: Sunday, May 24, 2009 1:02 PM To: Roni Even; Ali C. Begen (abegen); Jose Rey Cc: Roni Even; avt@ietf.org Subject: RE: [AVT] New draft of "Rapid Acquisition of Multicast = RTPSessions (RAMS)" available Roni- Regarding the RS being able to send data to the RR after receiving a = RAMS-R. There is a subtle point here, which you reference in your comment "need = to provide a reachable transport address". The RR sends the RAMS-R to the feedback target UDP port number. In the presence of NAT, the only communication path that is opened automatically is that single path. In order to use the other port-pairs, holes must be poked in the NAT and = the correct NAT-ed ports must be signaled. As you know, there are many ways = to poke wholes in NAT, so we will not go into the details of how to do = that. This is an important point, and we will be sure to make it more clear in = the next draft. Bvs -----Original Message----- From: Roni Even [mailto:Even.roni@huawei.com]=20 Sent: Saturday, May 23, 2009 8:19 AM To: Ali C. Begen (abegen); 'Jose Rey' Cc: 'Roni Even'; avt@ietf.org; Bill Ver Steeg (versteb) Subject: RE: [AVT] New draft of "Rapid Acquisition of Multicast = RTPSessions (RAMS)" available Hi, I also have concerns about having the unicast Transport addresses for = the RR RTCP and RTP receive port. I think that we should first talk about the NAT/FW issue and than define = the requirements and solutions. My assumption is that the retransmission server has a publicly reachable address while the receivers may sit behind NATs and will not have a = publicly reachable address. Note that the RAMS flow starts from the receiver by RAMS-R so a response = to the transport address from where the RAMS-R came should work (RTCP is bi-directional in this case). On the other hand the unicast data flow is = to the receiver so the receiver will need to provide a reachable transport address. Roni -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Ali C. Begen (abegen) Sent: Saturday, May 23, 2009 3:27 AM To: Jose Rey Cc: Roni Even; avt@ietf.org; Bill Ver Steeg (versteb) Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast = RTPSessions (RAMS)" available Hi Jose, Indeed, RAMS-R goes to the FT of the new primary session that RR is interested in acquiring rapidly. Then the unicast session becomes alive = and RS sends RAMS-I message(s) to RR on the RTCP port for the unicast = session. After some time, RR sends the RAMS-T message to the RTCP port for the unicast session since it is supposed to end the unicast session.=20 -acbegen > -----Original Message----- > From: Jose Rey [mailto:Jose.Rey@eu.panasonic.com] > Sent: Friday, May 22, 2009 7:09 AM > To: Ali C. Begen (abegen) > Cc: Roni Even; avt@ietf.org; Bill Ver Steeg (versteb) > Subject: RE: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" > available >=20 >=20 > Hi Ali, >=20 > > > > Hi Jose, > > > > We have separate RTCP ports for the SSM session and the unicast=20 > > session. Why is it a problem? >=20 > In line 19 you say you specify the dst port for RMS-I (41003), on RR.=20 > And you say that > would also be the port where the RR sends RMS-T, on RS. That is mixing = > the semantics of > a=3Drtcp for SSM (listening port at Feedback Target =3D mcast RTCP dst = > port) and those of RFC > 3605 (dst port). In other words, you are implicitly assuming that specifies symmetric > RTCP...no? >=20 > Another thing that was mentioned already: RMS-T is not sent to same=20 > port as RMS-R; is it > not the same RTCP session ? Or is this muxing desired? why? >=20 > JLR >=20 > > > > The slightly modified SDP for the next version is below: > > > 1> a=3Dgroup:FID 3 4 > 2> a=3Drtcp-unicast:rsi > 3> m=3Dvideo 41000 RTP/AVPF 98 > 4> i=3DPrimary Multicast Stream #2 > 5> c=3DIN IP4 233.252.0.2/255 > 6> a=3Dsource-filter: incl IN IP4 233.252.0.2 192.0.2.2 > 7> a=3Drecvonly > 8> a=3Drtpmap:98 MP2T/90000 > 9> a=3Drtcp:41001 IN IP4 192.0.2.1 > 10> a=3Drtcp-fb:98 nack > 11> a=3Drtcp-fb:98 nack ssli > 12> a=3Dssrc:123321 cname:iptv-ch32@rams.example.com > 13> a=3Dmid:3 > 14> m=3Dvideo 41002 RTP/AVPF 99 > 15> i=3DUnicast Retransmission Stream #2 (Ret. and Rapid > > Acq. Support) > 16> c=3DIN IP4 192.0.2.1 > 17> a=3Drecvonly > 18> a=3Drtpmap:99 rtx/90000 > 19> a=3Drtcp:41003 > 20> a=3Dfmtp:99 apt=3D98; rtx-time=3D5000 > 21> a=3Dmid:4 > > > > This is the SDP we send to RR. For RS, a=3Drecvonly will be = a=3Dsendonly. > > > > -acbegen > > > > > > > -----Original Message----- > > > From: Jos=E9 Rey [mailto:jose.rey@eu.panasonic.com] > > > Sent: Thursday, May 21, 2009 3:22 PM > > > To: Ali C. Begen (abegen) > > > Cc: Roni Even; avt@ietf.org; Bill Ver Steeg (versteb) > > > Subject: Re: [AVT] New draft of "Rapid Acquisition of > > Multicast RTPSessions (RAMS)" > > > available > > > > > > Hi all, > > > > > > sorry for jumping in.... > > > > > > I think one of the sources of confusion is that the > > attribute a=3Drtcp: > > > is used once for specifying the destination port and once for=20 > > > specifying a receiving port, and in the same SDP (!). The > > destination > > > port for RAMS-I packets sent by RS and the receiving port > > for RAMS-T. Which is also why different port numbers are used for=20 > > RAMS-T and -R packets. > > > > > > I think the use of a=3Drtcp: in SSM is the problem here. Or the = fact=20 > > > that we are mixing unicast and multicast, or both. > > > > > > Hope this helps, > > > > > > JLR > > > > > > > > > > > > > > > Ali C. Begen (abegen) wrote: > > > > > > > > > > > > > > > > > > -----Original Message----- > > > From: Roni Even [mailto:ron.even.tlv@gmail.com] > > > Sent: Saturday, April 25, 2009 2:58 PM > > > To: Ali C. Begen (abegen); avt@ietf.org > > > Cc: Bill Ver Steeg (versteb) > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of > > > Multicast RTPSessions (RAMS)" available > > > > > > Ali, > > > I looked at RFC 4570 and I assume that port > > 41001 is the port for the > > > unicast RTCP reports from the receivers and according to > > > > > > > > > > > > Yes, indeed. > > > > > > > > > > > > section 3.2.1 of > > > that RFC you also should have a RTCP-unicast > > specification. > > > This is for the > > > multicast receiver reports. > > > > > > > > > > > > Correct. We do have that line in our draft at the top > > right after the grouping lines: > > > > > > a=3Drtcp-unicast:rsi > > > > > > BR, > > > -acbegen > > > > > > > > > > > > Roni > > > > > > -----Original Message----- > > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > > Sent: Saturday, April 25, 2009 11:30 PM > > > To: Roni Even; avt@ietf.org > > > Cc: Bill Ver Steeg (versteb) > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of > > > Multicast RTPSessions > > > (RAMS)" available > > > > > > Here is the SDP. > > > > > > m=3Dvideo 41000 RTP/AVPF 98 > > > i=3DPrimary Multicast Stream #2 > > > c=3DIN IP4 224.1.1.2/255 > > > a=3Dsource-filter: incl IN IP4 224.1.1.2 192.0.2.2 > > > > > > Source (192.0.2.2) sends the rtp packets to the > > multicast > > > group (224.1.1.2) > > > with a dest port 41000. > > > > > > a=3Drtpmap:98 MP2T/90000 > > > a=3Drtcp:41001 IN IP4 192.0.2.1 > > > > > > The feedback target (RS) address for this SSM session is > > > 192.0.2.1 and its > > > port is 41001. This is the address/port where > > RR sends the RAMS-R, or > > > receiver reports for the SSM session. > > > > > > a=3Drtcp-fb:98 nack > > > a=3Drtcp-fb:98 nack ssli > > > a=3Dssrc:123321 cname:iptv-ch32@rams.example.com > > > a=3Dmid:3 > > > m=3Dvideo 41002 RTP/AVPF 99 > > > > > > The retransmission packets go to port 41002. > > This is the port > > > RRs listen to > > > for retransmission and RAMS. > > > > > > i=3DUnicast Retransmission Stream #2 > > (Ret. and Rapid > > > Acq. Support) > > > c=3DIN IP4 192.0.2.1 > > > > > > This is where the retransmission packets come > > from, same as > > > the feedback > > > target (in this example). > > > > > > a=3Drtpmap:99 rtx/90000 > > > a=3Drtcp:41003 > > > > > > This is where the RTCP packets for the > > retransmission session go. For > > > example, RAMS-I goes to this port on RRs. > > RAMS-T goes to this > > > port on RS. > > > > > > a=3Dfmtp:99 apt=3D98; rtx-time=3D5000 > > > a=3Dmid:4 > > > > > > > > > -acbegen > > > > > > > > > > > > > > > -----Original Message----- > > > From: Roni Even [mailto:ron.even.tlv@gmail.com] > > > Sent: Saturday, April 25, 2009 1:11 PM > > > To: Ali C. Begen (abegen); avt@ietf.org > > > Cc: Bill Ver Steeg (versteb) > > > Subject: RE: [AVT] New draft of "Rapid > > Acquisition of > > > Multicast RTPSessions (RAMS)" available > > > > > > Ali, > > > Can you please write three addresses > > from this strange SDP. > > > > > > 1. The address and port of multicast > > > > > > 2. The address and port of the RS where > > the RTCP FB should go to > > > > > > 3. The address and port on the RR where > > the unicast stream > > > should be sent to > > > > > > Roni > > > > > > -----Original Message----- > > > From: Ali C. Begen (abegen) > > [mailto:abegen@cisco.com] > > > Sent: Saturday, April 25, 2009 11:02 PM > > > To: Roni Even; avt@ietf.org > > > Cc: Bill Ver Steeg (versteb) > > > Subject: RE: [AVT] New draft of "Rapid > > Acquisition of > > > Multicast RTPSessions > > > (RAMS)" available > > > > > > > > > > > > Ali, > > > The example SDP is > > syntactically correct but it does not > > > > > > > > > say that the > > > > > > > > > rtp/rtcp mux will be used and > > it does not give the > > > information to where the > > > unicast stream will be sent > > when the RR sends a RAMS-R. > > > > > > > > > To my knowledge, the first line in the > > following SDP tells > > > the RRs on which > > > port they will receive the > > retransmission/burst packets. > > > > > > m=3Dvideo 41002 RTP/AVPF 99 > > > i=3DUnicast Retransmission Stream > > #2 (Ret. and Rapid > > > Acq. Support) > > > c=3DIN IP4 192.0.2.1 > > > a=3Drtpmap:99 rtx/90000 > > > a=3Drtcp:41003 > > > a=3Dfmtp:99 apt=3D98; rtx-time=3D5000 > > > a=3Dmid:4 > > > > > > There is a typo, you are right. That > > "a=3Drecvonly" line should > > > only exist in > > > the SDP sent to RRs. In the SDP sent to > > RS, we should rather have > > > "a=3Dsendonly". I will make this > > correction in the next version. > > > > > > The feedback target for the SSM session > > and the RTCP port for the > > > retransmission session are also defined > > in the SDP. > > > > > > Hope this clarifies. > > > > > > BR, > > > -acbegen > > > > > > > > > > > > I am not sure why the unicast > > stream m-line has a port > > > > > > > > > number with an > > > > > > > > > attribute of recvonly. What is > > the use case for that. The > > > only information > > > that the RR will need is the > > RTCP port on the RS to where to > > > send the RAMS-R > > > message. > > > Roni > > > -----Original Message----- > > > From: Ali C. Begen (abegen) > > [mailto:abegen@cisco.com] > > > Sent: Friday, April 24, 2009 10:37 PM > > > To: Roni Even; avt@ietf.org > > > Cc: Bill Ver Steeg (versteb) > > > Subject: RE: [AVT] New draft of > > "Rapid Acquisition of > > > Multicast RTPSessions > > > (RAMS)" available > > > > > > This is a part of an example > > SDP sent to RS and RR in a SAP > > > announcement, > > > for example. So, the SDP > > describes what both parties should > > > do (RR cannot > > > say that he wants to receive > > this multicast on its favorite > > > > > > > > > port). The > > > > > > > > > individual SDPs sent to RR or > > RS may include other portions > > > of descriptions > > > that will contain specific information. > > > > > > -acbegen > > > > > > > > > > > > -----Original Message----- > > > From: Roni Even > > [mailto:ron.even.tlv@gmail.com] > > > Sent: Friday, April 24, > > 2009 12:23 PM > > > To: Ali C. Begen > > (abegen); avt@ietf.org > > > Cc: Bill Ver Steeg (versteb) > > > Subject: RE: [AVT] New > > draft of "Rapid Acquisition of > > > Multicast RTPSessions > > (RAMS)" available > > > > > > Ali, > > > I think you get it > > wrong, this SDP is from the RS and not the > > > RR so the RS > > > cannot specify to which > > address it will send it can only > > > specify to which > > > address it can receive > > RTP stream. In this SDP the relevant > > > information is > > > that the request for > > retransmission will be sent by the RR to > > > port 41003 > > > Roni > > > > > > -----Original Message----- > > > From: Ali C. Begen > > (abegen) [mailto:abegen@cisco.com] > > > Sent: Friday, April 24, > > 2009 10:01 PM > > > To: Roni Even; avt@ietf.org > > > Cc: Bill Ver Steeg (versteb) > > > Subject: RE: [AVT] New > > draft of "Rapid Acquisition of > > > Multicast RTPSessions > > > (RAMS)" available > > > > > > Oh, I see. The burst > > goes to the port that we would > > > > > > > > > normally send the > > > > > > > > > retransmissions. For > > example, consider the SDP from the draft: > > > > > > m=3Dvideo 41000 > > RTP/AVPF 98 > > > i=3DPrimary > > Multicast Stream #2 > > > c=3DIN IP4 224.1.1.2/255 > > > > > a=3Dsource-filter: incl IN IP4 224.1.1.2 192.0.2.2 > > > a=3Drtpmap:98 MP2T/90000 > > > a=3Drtcp:41001 IN > > IP4 192.0.2.1 > > > a=3Drtcp-fb:98 nack > > > a=3Drtcp-fb:98 nack ssli > > > a=3Dssrc:123321 > > cname:iptv-ch32@rams.example.com > > > a=3Dmid:3 > > > m=3Dvideo 41002 > > RTP/AVPF 99 > > > i=3DUnicast > > Retransmission Stream #2 (Ret. and Rapid > > > Acq. Support) > > > c=3DIN IP4 192.0.2.1 > > > a=3Drecvonly > > > a=3Drtpmap:99 rtx/90000 > > > a=3Drtcp:41003 > > > a=3Dfmtp:99 > > apt=3D98; rtx-time=3D5000 > > > a=3Dmid:4 > > > > > > In this case, the burst > > will go to port 41002 on the RR. > > > > > > > > > The RAMS-I > > > > > > > > > message(s), which is an > > RTCP feedback message, will go to > > > > > > > > > port 41003. > > > > > > > > > HTH, > > > -acbegen > > > > > > > > > > > > -----Original > > Message----- > > > From: Roni Even > > [mailto:ron.even.tlv@gmail.com] > > > Sent: Friday, > > April 24, 2009 11:44 AM > > > To: Ali C. > > Begen (abegen); avt@ietf.org > > > Cc: Bill Ver > > Steeg (versteb) > > > Subject: RE: > > [AVT] New draft of "Rapid Acquisition of > > > Multicast > > RTPSessions (RAMS)" available > > > > > > Ali, > > > I will try to > > explain in simple way > > > > > > When the RS > > receives the RAMS-R it need to start sending an > > > RTP stream to > > > the RR. > > > In order to > > send a unicast packet, the RS needs to know a > > > transport address > > > on the RR to > > where the RTP stream will be sent. The current > > > draft does not > > > say how the RS > > knows this address. There is no SDP from RR to > > > RS like you > > > mention in your > > response. > > > This is why I > > say that the current draft does not specify a > > > solution that > > > can be > > implemented as a working solution > > > Roni > > > > > > -----Original > > Message----- > > > From: Ali C. > > Begen (abegen) [mailto:abegen@cisco.com] > > > Sent: Friday, > > April 24, 2009 7:38 PM > > > To: Roni Even; > > avt@ietf.org > > > Cc: Bill Ver > > Steeg (versteb) > > > Subject: RE: > > [AVT] New draft of "Rapid Acquisition of > > > Multicast RTPSessions > > > (RAMS)" available > > > > > > Hi Roni, > > > > > > > > > > > > > > -----Original Message----- > > > From: > > avt-bounces@ietf.org [mailto:avt- bounces@ietf.org] On > > > Behalf > > Of Roni Even > > > Sent: > > Friday, April 24, 2009 4:24 AM > > > To: avt@ietf.org > > > Cc: > > Bill Ver Steeg (versteb) > > > > > Subject: Re: [AVT] New draft of "Rapid Acquisition of > > > > > Multicast RTPSessions (RAMS)" available > > > > > > Hi, > > > > > > I think > > that the current draft does not give a > > > > > > > > > description of > > > > > > > > > a > > system that works since there is no text > > > > > > > > > explaining how the > > > > > > > > > What do you > > mean by "a system that works"? > > > > > > > > > > > > RS > > knows the unicast transport address on the RR to > > > > > > > > > where to > > > > > > > > > send the stream. > > > > > > > > > Once RS > > receives the request packet from an RR, RS knows its > > > address. Ports > > > are defined in > > the SDP. If you are asking about "NAT" > > > issues, > > > we have a > > > section for it, > > and we plan to complete it as we move > > > forward. It is not as > > > critical as the > > other parts for now. > > > > > > > > > > > > If you > > mandate the use of RTP/RTCP mux it should say so > > > > > otherwise the RAMS-R should have an optional parameter that > > > > > supplies this information and a flag for using RTP/RTCP mux. > > > > > > > > > IMO, we cannot > > mandate muxing as it is not required to make > > > RAMS work. If > > > muxing is > > supported, the SDP should reflect it. > > > > > > BR, > > > -acbegen > > > > > > > > > > > > Thanks > > > > > > Roni Even > > > > > > > > > > > > From: > > avt-bounces@ietf.org [mailto:avt- bounces@ietf.org] On > > > Behalf > > Of Bill Ver Steeg (versteb) > > > Sent: > > Thursday, April 16, 2009 7:39 PM > > > To: avt@ietf.org > > > > > Subject: [AVT] New draft of "Rapid Acquisition of Multicast > > > RTP > > Sessions (RAMS)" available > > > > > > > > > > > > There > > is a new draft of the "Rapid Acquisition of Multicast > > > RTP > > Sessions (RAMS)" draft available at > > > > > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-versteeg-avt-rapid-s > > > > > > > > > > > ynchronization-for-rtp-03.txt > > > <http://www.ietf.org/internet-> <http://www.ietf.org/internet-> > > > > > > > > > > > > > > drafts/draft-versteeg-avt-rapid-synchronization-for-rtp-03.txt> > > > > > > > > > > > > > > > We have > > incorporated the changes from the technical > > > > > > > > > breakout > > > > > > > > > session > > in San Francisco. The major changes in this version > > > of the > > draft include > > > > > > 1- > > Changing the document title to avoid confusion > > > > > > > > > with other > > > > > > > > > ongoing > > "synchronization" drafts > > > > > > 2- > > changing the message names to reflect the title change > > > > > > 3- > > clarification of the RTCP message semantics, including > > > changes > > to the "Request" and "Inform" messages > > > > > > 4- > > additional description/motivation for the > > > > > > > > > various message > > > > > > > > > flows > > has been added > > > > > > 5- > > RTP/RTCP muxing has been added > > > > > > > > > > > > > > > > > > We hope > > to make this a Working Group item, and will change > > > the > > name of the draft to avoid conflicts with other > > > > > "synchronization" drafts at that time. > > > > > > > > > > > > Bill VerSteeg > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Audio/Video Transport Working Group > > > avt@ietf.org > > > https://www.ietf.org/mailman/listinfo/avt > > > > > > > > > > > > >=20 >=20 > Panasonic R&D Center Germany GmbH > 63225 Langen, Hessen, Germany > Reg: AG Offenbach (Hessen) HRB 33974 > Managing Director: Thomas Micke >=20 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www.ietf.org/mailman/listinfo/avt From oran@cisco.com Sun May 24 06:58:35 2009 Return-Path: <oran@cisco.com> X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B40F3A6AEB for <avt@core3.amsl.com>; Sun, 24 May 2009 06:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.116 X-Spam-Level: X-Spam-Status: No, score=-5.116 tagged_above=-999 required=5 tests=[AWL=-1.517, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wr0cT1yFpFJZ for <avt@core3.amsl.com>; Sun, 24 May 2009 06:58:28 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 14BC63A69D5 for <avt@ietf.org>; Sun, 24 May 2009 06:58:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,240,1241395200"; d="scan'208";a="189673039" Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-1.cisco.com with ESMTP; 24 May 2009 14:00:08 +0000 Received: from stealth-10-32-245-158.cisco.com ([10.32.245.158]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id n4ODvl7Y007508; Sun, 24 May 2009 06:57:55 -0700 Received: from [127.0.0.1] by stealth-10-32-245-158.cisco.com (PGP Universal service); Sun, 24 May 2009 10:00:06 -0400 X-PGP-Universal: processed; by stealth-10-32-245-158.cisco.com on Sun, 24 May 2009 10:00:06 -0400 Message-Id: <D9D7FD6A-0DFE-4A4E-8215-C8B4F54462C9@cisco.com> From: David R Oran <oran@cisco.com> To: Roni Even <ron.even.tlv@gmail.com> In-Reply-To: <4a193d46.0c11660a.33cc.109d@mx.google.com> Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sun, 24 May 2009 09:59:56 -0400 References: <81B9B88E2F9D574AA5328A85547CDE9101071D80@xmb-rtp-21d.amer.cisco.com> <49f1a1d6.190c660a.58fe.ffffa90e@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C80DA@xmb-sjc-215.amer.cisco.com> <49f208e8.05a0660a.5bd2.6764@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C81C9@xmb-sjc-215.amer.cisco.com> <49f211fc.07a5660a.3f7f.ffff8f4a@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8202@xmb-sjc-215.amer.cisco.com> <49f2efa2.1c215e0a.4454.ffffaf91@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8403@xmb-sjc-215.amer.cisco.com> <49f36ee2.0437560a.11df.1eef@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8405@xmb-sjc-215.amer.cisco.com> <49f387ca.0305560a.6657.4be7@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C840A@xmb-sjc-215.amer.cisco.com> <4A15D40E.80509@eu.panasonic.com> <04CAD96D4C5A3D48B1919248A8FE0D54095E153A@xmb-sjc-215.amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB011BF41B@lan-ex-02.panasonic.de> <04CAD96D4C5A3D48B1919248A8FE0D54095E18BB@ xmb-sjc -.com> <02a00 1c9dba0$a5559730$f000c590$%roni@huawei.com> <81B9B88E2F9D574AA5328A85547CDE910142F016@xmb-rtp-21d.amer.cisco.com> <4a193d46.0c11660a.33cc.109d@mx.google.com> X-Mailer: Apple Mail (2.935.3) Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=23041; t=1243173476; x=1244037476; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:=20David=20R=20Oran=20<oran@cisco.com> |Subject:=20Re=3A=20[AVT]=20New=20draft=20of=20=22Rapid=20A cquisition=20of=20Multicast=09RTPSessions=09(RAMS)=22=20avai lable |Sender:=20 |To:=20Roni=20Even=20<ron.even.tlv@gmail.com>; bh=FvGS7GjhsWBOdi1RgKTtegj3TmrGJVuBW4QEJFKiRzk=; b=LlnkPFefd/mpePQcCdlYFqJyu2lpBR5jFLQY4nUtNdgCL1MjZQGChTt5Jm i6SZRhp9qXSR73I9rY4wLRgF22YWgVksSaVauutc5gucBLv9r2Gj9tvSlPfO kImCd7Ulpa; Authentication-Results: imail.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); Cc: 'Jose Rey' <Jose.Rey@eu.panasonic.com>, 'Roni Even' <Even.roni@huawei.com>, "'Bill Ver Steeg \(versteb\)'" <versteb@cisco.com>, avt@ietf.org Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group <avt.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/avt> List-Post: <mailto:avt@ietf.org> List-Help: <mailto:avt-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 24 May 2009 13:58:35 -0000 On May 24, 2009, at 8:26 AM, Roni Even wrote: > Bill, > My major point here is this is a reason for having an option port or > transport address parameter in the RAMS-R allowing the RR to provide =20= > such > address. Correct, in principle. I've already commented on the problematic =20 nature of sending complete transport addresses, so my strong =20 preference would be only to communicate port numbers (and possibly =20 SSRCs) However it's an interesting design point whether this situation is so =20= unique to RAMS that we solve it by putting the information in RAMS-R =20 messages, or whether it justifies a more general-purpose mechanism. An alternative design would be to define a separate RTCP packet type =20 to carry transport port information for "auxiliary" unicast RTP/RTCP =20 sessions. The situation we face with RAMS does in fact may arise in =20 other situations, both with and without NAT, where separate signaling =20= using offer/answer (as SIP would do) is either overkill, too much =20 overhead, or bad from a latency perspective. Just think unicast =20 retransmission for SSM by itself, without RAMS. In my view, it would be worth having a serious WG discussion of this =20 general subject before plunging ahead. If the sense is to in fact have =20= a separate mechanism, I have one sitting in my back pocket (and have =20 running open source code for). DaveO. > Roni > > -----Original Message----- > From: Bill Ver Steeg (versteb) [mailto:versteb@cisco.com] > Sent: Sunday, May 24, 2009 1:02 PM > To: Roni Even; Ali C. Begen (abegen); Jose Rey > Cc: Roni Even; avt@ietf.org > Subject: RE: [AVT] New draft of "Rapid Acquisition of Multicast =20 > RTPSessions > (RAMS)" available > > Roni- > Regarding the RS being able to send data to the RR after receiving a =20= > RAMS-R. > > There is a subtle point here, which you reference in your comment =20 > "need to > provide a reachable transport address". The RR sends the RAMS-R to the > feedback target UDP port number. In the presence of NAT, the only > communication path that is opened automatically is that single path. =20= > In > order to use the other port-pairs, holes must be poked in the NAT =20 > and the > correct NAT-ed ports must be signaled. As you know, there are many =20 > ways to > poke wholes in NAT, so we will not go into the details of how to do =20= > that. > > This is an important point, and we will be sure to make it more =20 > clear in the > next draft. > > Bvs > > > -----Original Message----- > From: Roni Even [mailto:Even.roni@huawei.com] > Sent: Saturday, May 23, 2009 8:19 AM > To: Ali C. Begen (abegen); 'Jose Rey' > Cc: 'Roni Even'; avt@ietf.org; Bill Ver Steeg (versteb) > Subject: RE: [AVT] New draft of "Rapid Acquisition of Multicast =20 > RTPSessions > (RAMS)" available > > Hi, > I also have concerns about having the unicast Transport addresses =20 > for the RR > RTCP and RTP receive port. > I think that we should first talk about the NAT/FW issue and than =20 > define the > requirements and solutions. > > My assumption is that the retransmission server has a publicly =20 > reachable > address while the receivers may sit behind NATs and will not have a =20= > publicly > reachable address. > Note that the RAMS flow starts from the receiver by RAMS-R so a =20 > response to > the transport address from where the RAMS-R came should work (RTCP is > bi-directional in this case). On the other hand the unicast data =20 > flow is to > the receiver so the receiver will need to provide a reachable =20 > transport > address. > > Roni > > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf =20 > Of Ali C. > Begen (abegen) > Sent: Saturday, May 23, 2009 3:27 AM > To: Jose Rey > Cc: Roni Even; avt@ietf.org; Bill Ver Steeg (versteb) > Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast =20 > RTPSessions > (RAMS)" available > > Hi Jose, > > Indeed, RAMS-R goes to the FT of the new primary session that RR is > interested in acquiring rapidly. Then the unicast session becomes =20 > alive and > RS sends RAMS-I message(s) to RR on the RTCP port for the unicast =20 > session. > After some time, RR sends the RAMS-T message to the RTCP port for the > unicast session since it is supposed to end the unicast session. > > -acbegen > >> -----Original Message----- >> From: Jose Rey [mailto:Jose.Rey@eu.panasonic.com] >> Sent: Friday, May 22, 2009 7:09 AM >> To: Ali C. Begen (abegen) >> Cc: Roni Even; avt@ietf.org; Bill Ver Steeg (versteb) >> Subject: RE: [AVT] New draft of "Rapid Acquisition of Multicast > RTPSessions (RAMS)" >> available >> >> >> Hi Ali, >> >>> >>> Hi Jose, >>> >>> We have separate RTCP ports for the SSM session and the unicast >>> session. Why is it a problem? >> >> In line 19 you say you specify the dst port for RMS-I (41003), on RR. >> And > you say that >> would also be the port where the RR sends RMS-T, on RS. That is =20 >> mixing >> the > semantics of >> a=3Drtcp for SSM (listening port at Feedback Target =3D mcast RTCP = dst >> port) > and those of RFC >> 3605 (dst port). In other words, you are implicitly assuming that > specifies symmetric >> RTCP...no? >> >> Another thing that was mentioned already: RMS-T is not sent to same >> port > as RMS-R; is it >> not the same RTCP session ? Or is this muxing desired? why? >> >> JLR >> >>> >>> The slightly modified SDP for the next version is below: >>> >> 1> a=3Dgroup:FID 3 4 >> 2> a=3Drtcp-unicast:rsi >> 3> m=3Dvideo 41000 RTP/AVPF 98 >> 4> i=3DPrimary Multicast Stream #2 >> 5> c=3DIN IP4 233.252.0.2/255 >> 6> a=3Dsource-filter: incl IN IP4 233.252.0.2 192.0.2.2 >> 7> a=3Drecvonly >> 8> a=3Drtpmap:98 MP2T/90000 >> 9> a=3Drtcp:41001 IN IP4 192.0.2.1 >> 10> a=3Drtcp-fb:98 nack >> 11> a=3Drtcp-fb:98 nack ssli >> 12> a=3Dssrc:123321 cname:iptv-ch32@rams.example.com >> 13> a=3Dmid:3 >> 14> m=3Dvideo 41002 RTP/AVPF 99 >> 15> i=3DUnicast Retransmission Stream #2 (Ret. and Rapid >>> Acq. Support) >> 16> c=3DIN IP4 192.0.2.1 >> 17> a=3Drecvonly >> 18> a=3Drtpmap:99 rtx/90000 >> 19> a=3Drtcp:41003 >> 20> a=3Dfmtp:99 apt=3D98; rtx-time=3D5000 >> 21> a=3Dmid:4 >>> >>> This is the SDP we send to RR. For RS, a=3Drecvonly will be =20 >>> a=3Dsendonly. >>> >>> -acbegen >>> >>> >>>> -----Original Message----- >>>> From: Jos=E9 Rey [mailto:jose.rey@eu.panasonic.com] >>>> Sent: Thursday, May 21, 2009 3:22 PM >>>> To: Ali C. Begen (abegen) >>>> Cc: Roni Even; avt@ietf.org; Bill Ver Steeg (versteb) >>>> Subject: Re: [AVT] New draft of "Rapid Acquisition of >>> Multicast RTPSessions (RAMS)" >>>> available >>>> >>>> Hi all, >>>> >>>> sorry for jumping in.... >>>> >>>> I think one of the sources of confusion is that the >>> attribute a=3Drtcp: >>>> is used once for specifying the destination port and once for >>>> specifying a receiving port, and in the same SDP (!). The >>> destination >>>> port for RAMS-I packets sent by RS and the receiving port >>> for RAMS-T. Which is also why different port numbers are used for >>> RAMS-T and -R packets. >>>> >>>> I think the use of a=3Drtcp: in SSM is the problem here. Or the = fact >>>> that we are mixing unicast and multicast, or both. >>>> >>>> Hope this helps, >>>> >>>> JLR >>>> >>>> >>>> >>>> >>>> Ali C. Begen (abegen) wrote: >>>> >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Roni Even [mailto:ron.even.tlv@gmail.com] >>>> Sent: Saturday, April 25, 2009 2:58 PM >>>> To: Ali C. Begen (abegen); avt@ietf.org >>>> Cc: Bill Ver Steeg (versteb) >>>> Subject: RE: [AVT] New draft of "Rapid Acquisition of >>>> Multicast RTPSessions (RAMS)" available >>>> >>>> Ali, >>>> I looked at RFC 4570 and I assume that port >>> 41001 is the port for the >>>> unicast RTCP reports from the receivers and according to >>>> >>>> >>>> >>>> Yes, indeed. >>>> >>>> >>>> >>>> section 3.2.1 of >>>> that RFC you also should have a RTCP-unicast >>> specification. >>>> This is for the >>>> multicast receiver reports. >>>> >>>> >>>> >>>> Correct. We do have that line in our draft at the top >>> right after the grouping lines: >>>> >>>> a=3Drtcp-unicast:rsi >>>> >>>> BR, >>>> -acbegen >>>> >>>> >>>> >>>> Roni >>>> >>>> -----Original Message----- >>>> From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] >>>> Sent: Saturday, April 25, 2009 11:30 PM >>>> To: Roni Even; avt@ietf.org >>>> Cc: Bill Ver Steeg (versteb) >>>> Subject: RE: [AVT] New draft of "Rapid Acquisition of >>>> Multicast RTPSessions >>>> (RAMS)" available >>>> >>>> Here is the SDP. >>>> >>>> m=3Dvideo 41000 RTP/AVPF 98 >>>> i=3DPrimary Multicast Stream #2 >>>> c=3DIN IP4 224.1.1.2/255 >>>> a=3Dsource-filter: incl IN IP4 224.1.1.2 = 192.0.2.2 >>>> >>>> Source (192.0.2.2) sends the rtp packets to the >>> multicast >>>> group (224.1.1.2) >>>> with a dest port 41000. >>>> >>>> a=3Drtpmap:98 MP2T/90000 >>>> a=3Drtcp:41001 IN IP4 192.0.2.1 >>>> >>>> The feedback target (RS) address for this SSM session is >>>> 192.0.2.1 and its >>>> port is 41001. This is the address/port where >>> RR sends the RAMS-R, or >>>> receiver reports for the SSM session. >>>> >>>> a=3Drtcp-fb:98 nack >>>> a=3Drtcp-fb:98 nack ssli >>>> a=3Dssrc:123321 cname:iptv-ch32@rams.example.com >>>> a=3Dmid:3 >>>> m=3Dvideo 41002 RTP/AVPF 99 >>>> >>>> The retransmission packets go to port 41002. >>> This is the port >>>> RRs listen to >>>> for retransmission and RAMS. >>>> >>>> i=3DUnicast Retransmission Stream #2 >>> (Ret. and Rapid >>>> Acq. Support) >>>> c=3DIN IP4 192.0.2.1 >>>> >>>> This is where the retransmission packets come >>> from, same as >>>> the feedback >>>> target (in this example). >>>> >>>> a=3Drtpmap:99 rtx/90000 >>>> a=3Drtcp:41003 >>>> >>>> This is where the RTCP packets for the >>> retransmission session go. For >>>> example, RAMS-I goes to this port on RRs. >>> RAMS-T goes to this >>>> port on RS. >>>> >>>> a=3Dfmtp:99 apt=3D98; rtx-time=3D5000 >>>> a=3Dmid:4 >>>> >>>> >>>> -acbegen >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Roni Even [mailto:ron.even.tlv@gmail.com] >>>> Sent: Saturday, April 25, 2009 1:11 PM >>>> To: Ali C. Begen (abegen); avt@ietf.org >>>> Cc: Bill Ver Steeg (versteb) >>>> Subject: RE: [AVT] New draft of "Rapid >>> Acquisition of >>>> Multicast RTPSessions (RAMS)" available >>>> >>>> Ali, >>>> Can you please write three addresses >>> from this strange SDP. >>>> >>>> 1. The address and port of multicast >>>> >>>> 2. The address and port of the RS where >>> the RTCP FB should go to >>>> >>>> 3. The address and port on the RR where >>> the unicast stream >>>> should be sent to >>>> >>>> Roni >>>> >>>> -----Original Message----- >>>> From: Ali C. Begen (abegen) >>> [mailto:abegen@cisco.com] >>>> Sent: Saturday, April 25, 2009 11:02 PM >>>> To: Roni Even; avt@ietf.org >>>> Cc: Bill Ver Steeg (versteb) >>>> Subject: RE: [AVT] New draft of "Rapid >>> Acquisition of >>>> Multicast RTPSessions >>>> (RAMS)" available >>>> >>>> >>>> >>>> Ali, >>>> The example SDP is >>> syntactically correct but it does not >>>> >>>> >>>> say that the >>>> >>>> >>>> rtp/rtcp mux will be used and >>> it does not give the >>>> information to where the >>>> unicast stream will be sent >>> when the RR sends a RAMS-R. >>>> >>>> >>>> To my knowledge, the first line in the >>> following SDP tells >>>> the RRs on which >>>> port they will receive the >>> retransmission/burst packets. >>>> >>>> m=3Dvideo 41002 RTP/AVPF 99 >>>> i=3DUnicast Retransmission Stream >>> #2 (Ret. and Rapid >>>> Acq. Support) >>>> c=3DIN IP4 192.0.2.1 >>>> a=3Drtpmap:99 rtx/90000 >>>> a=3Drtcp:41003 >>>> a=3Dfmtp:99 apt=3D98; rtx-time=3D5000 >>>> a=3Dmid:4 >>>> >>>> There is a typo, you are right. That >>> "a=3Drecvonly" line should >>>> only exist in >>>> the SDP sent to RRs. In the SDP sent to >>> RS, we should rather have >>>> "a=3Dsendonly". I will make this >>> correction in the next version. >>>> >>>> The feedback target for the SSM session >>> and the RTCP port for the >>>> retransmission session are also defined >>> in the SDP. >>>> >>>> Hope this clarifies. >>>> >>>> BR, >>>> -acbegen >>>> >>>> >>>> >>>> I am not sure why the unicast >>> stream m-line has a port >>>> >>>> >>>> number with an >>>> >>>> >>>> attribute of recvonly. What is >>> the use case for that. The >>>> only information >>>> that the RR will need is the >>> RTCP port on the RS to where to >>>> send the RAMS-R >>>> message. >>>> Roni >>>> -----Original Message----- >>>> From: Ali C. Begen (abegen) >>> [mailto:abegen@cisco.com] >>>> Sent: Friday, April 24, 2009 10:37 PM >>>> To: Roni Even; avt@ietf.org >>>> Cc: Bill Ver Steeg (versteb) >>>> Subject: RE: [AVT] New draft of >>> "Rapid Acquisition of >>>> Multicast RTPSessions >>>> (RAMS)" available >>>> >>>> This is a part of an example >>> SDP sent to RS and RR in a SAP >>>> announcement, >>>> for example. So, the SDP >>> describes what both parties should >>>> do (RR cannot >>>> say that he wants to receive >>> this multicast on its favorite >>>> >>>> >>>> port). The >>>> >>>> >>>> individual SDPs sent to RR or >>> RS may include other portions >>>> of descriptions >>>> that will contain specific information. >>>> >>>> -acbegen >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Roni Even >>> [mailto:ron.even.tlv@gmail.com] >>>> Sent: Friday, April 24, >>> 2009 12:23 PM >>>> To: Ali C. Begen >>> (abegen); avt@ietf.org >>>> Cc: Bill Ver Steeg (versteb) >>>> Subject: RE: [AVT] New >>> draft of "Rapid Acquisition of >>>> Multicast RTPSessions >>> (RAMS)" available >>>> >>>> Ali, >>>> I think you get it >>> wrong, this SDP is from the RS and not the >>>> RR so the RS >>>> cannot specify to which >>> address it will send it can only >>>> specify to which >>>> address it can receive >>> RTP stream. In this SDP the relevant >>>> information is >>>> that the request for >>> retransmission will be sent by the RR to >>>> port 41003 >>>> Roni >>>> >>>> -----Original Message----- >>>> From: Ali C. Begen >>> (abegen) [mailto:abegen@cisco.com] >>>> Sent: Friday, April 24, >>> 2009 10:01 PM >>>> To: Roni Even; avt@ietf.org >>>> Cc: Bill Ver Steeg (versteb) >>>> Subject: RE: [AVT] New >>> draft of "Rapid Acquisition of >>>> Multicast RTPSessions >>>> (RAMS)" available >>>> >>>> Oh, I see. The burst >>> goes to the port that we would >>>> >>>> >>>> normally send the >>>> >>>> >>>> retransmissions. For >>> example, consider the SDP from the draft: >>>> >>>> m=3Dvideo 41000 >>> RTP/AVPF 98 >>>> i=3DPrimary >>> Multicast Stream #2 >>>> c=3DIN IP4 224.1.1.2/255 >>>> >>> a=3Dsource-filter: incl IN IP4 224.1.1.2 192.0.2.2 >>>> a=3Drtpmap:98 MP2T/90000 >>>> a=3Drtcp:41001 IN >>> IP4 192.0.2.1 >>>> a=3Drtcp-fb:98 nack >>>> a=3Drtcp-fb:98 nack ssli >>>> a=3Dssrc:123321 >>> cname:iptv-ch32@rams.example.com >>>> a=3Dmid:3 >>>> m=3Dvideo 41002 >>> RTP/AVPF 99 >>>> i=3DUnicast >>> Retransmission Stream #2 (Ret. and Rapid >>>> Acq. Support) >>>> c=3DIN IP4 192.0.2.1 >>>> a=3Drecvonly >>>> a=3Drtpmap:99 rtx/90000 >>>> a=3Drtcp:41003 >>>> a=3Dfmtp:99 >>> apt=3D98; rtx-time=3D5000 >>>> a=3Dmid:4 >>>> >>>> In this case, the burst >>> will go to port 41002 on the RR. >>>> >>>> >>>> The RAMS-I >>>> >>>> >>>> message(s), which is an >>> RTCP feedback message, will go to >>>> >>>> >>>> port 41003. >>>> >>>> >>>> HTH, >>>> -acbegen >>>> >>>> >>>> >>>> -----Original >>> Message----- >>>> From: Roni Even >>> [mailto:ron.even.tlv@gmail.com] >>>> Sent: Friday, >>> April 24, 2009 11:44 AM >>>> To: Ali C. >>> Begen (abegen); avt@ietf.org >>>> Cc: Bill Ver >>> Steeg (versteb) >>>> Subject: RE: >>> [AVT] New draft of "Rapid Acquisition of >>>> Multicast >>> RTPSessions (RAMS)" available >>>> >>>> Ali, >>>> I will try to >>> explain in simple way >>>> >>>> When the RS >>> receives the RAMS-R it need to start sending an >>>> RTP stream to >>>> the RR. >>>> In order to >>> send a unicast packet, the RS needs to know a >>>> transport address >>>> on the RR to >>> where the RTP stream will be sent. The current >>>> draft does not >>>> say how the RS >>> knows this address. There is no SDP from RR to >>>> RS like you >>>> mention in your >>> response. >>>> This is why I >>> say that the current draft does not specify a >>>> solution that >>>> can be >>> implemented as a working solution >>>> Roni >>>> >>>> -----Original >>> Message----- >>>> From: Ali C. >>> Begen (abegen) [mailto:abegen@cisco.com] >>>> Sent: Friday, >>> April 24, 2009 7:38 PM >>>> To: Roni Even; >>> avt@ietf.org >>>> Cc: Bill Ver >>> Steeg (versteb) >>>> Subject: RE: >>> [AVT] New draft of "Rapid Acquisition of >>>> Multicast RTPSessions >>>> (RAMS)" available >>>> >>>> Hi Roni, >>>> >>>> >>>> >>>> >>> -----Original Message----- >>>> From: >>> avt-bounces@ietf.org [mailto:avt- bounces@ietf.org] On >>>> Behalf >>> Of Roni Even >>>> Sent: >>> Friday, April 24, 2009 4:24 AM >>>> To: avt@ietf.org >>>> Cc: >>> Bill Ver Steeg (versteb) >>>> >>> Subject: Re: [AVT] New draft of "Rapid Acquisition of >>>> >>> Multicast RTPSessions (RAMS)" available >>>> >>>> Hi, >>>> >>>> I think >>> that the current draft does not give a >>>> >>>> >>>> description of >>>> >>>> >>>> a >>> system that works since there is no text >>>> >>>> >>>> explaining how the >>>> >>>> >>>> What do you >>> mean by "a system that works"? >>>> >>>> >>>> >>>> RS >>> knows the unicast transport address on the RR to >>>> >>>> >>>> where to >>>> >>>> >>>> send the stream. >>>> >>>> >>>> Once RS >>> receives the request packet from an RR, RS knows its >>>> address. Ports >>>> are defined in >>> the SDP. If you are asking about "NAT" >>>> issues, >>>> we have a >>>> section for it, >>> and we plan to complete it as we move >>>> forward. It is not as >>>> critical as the >>> other parts for now. >>>> >>>> >>>> >>>> If you >>> mandate the use of RTP/RTCP mux it should say so >>>> >>> otherwise the RAMS-R should have an optional parameter that >>>> >>> supplies this information and a flag for using RTP/RTCP mux. >>>> >>>> >>>> IMO, we cannot >>> mandate muxing as it is not required to make >>>> RAMS work. If >>>> muxing is >>> supported, the SDP should reflect it. >>>> >>>> BR, >>>> -acbegen >>>> >>>> >>>> >>>> Thanks >>>> >>>> Roni Even >>>> >>>> >>>> >>>> From: >>> avt-bounces@ietf.org [mailto:avt- bounces@ietf.org] On >>>> Behalf >>> Of Bill Ver Steeg (versteb) >>>> Sent: >>> Thursday, April 16, 2009 7:39 PM >>>> To: avt@ietf.org >>>> >>> Subject: [AVT] New draft of "Rapid Acquisition of Multicast >>>> RTP >>> Sessions (RAMS)" available >>>> >>>> >>>> >>>> There >>> is a new draft of the "Rapid Acquisition of Multicast >>>> RTP >>> Sessions (RAMS)" draft available at >>>> >>>> >>>> >>>> >>> http://www.ietf.org/internet-drafts/draft-versteeg-avt-rapid-s >>>> >>>> >>>> >>> ynchronization-for-rtp-03.txt >>>> <http://www.ietf.org/internet-> <http://www.ietf.org/internet-> >>>> >>>> >>>> >>>> >>> drafts/draft-versteeg-avt-rapid-synchronization-for-rtp-03.txt> >>>> >>>> >>>> >>>> >>>> We have >>> incorporated the changes from the technical >>>> >>>> >>>> breakout >>>> >>>> >>>> session >>> in San Francisco. The major changes in this version >>>> of the >>> draft include >>>> >>>> 1- >>> Changing the document title to avoid confusion >>>> >>>> >>>> with other >>>> >>>> >>>> ongoing >>> "synchronization" drafts >>>> >>>> 2- >>> changing the message names to reflect the title change >>>> >>>> 3- >>> clarification of the RTCP message semantics, including >>>> changes >>> to the "Request" and "Inform" messages >>>> >>>> 4- >>> additional description/motivation for the >>>> >>>> >>>> various message >>>> >>>> >>>> flows >>> has been added >>>> >>>> 5- >>> RTP/RTCP muxing has been added >>>> >>>> >>>> >>>> >>>> >>>> We hope >>> to make this a Working Group item, and will change >>>> the >>> name of the draft to avoid conflicts with other >>>> >>> "synchronization" drafts at that time. >>>> >>>> >>>> >>>> Bill VerSteeg >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Audio/Video Transport Working Group >>>> avt@ietf.org >>>> https://www.ietf.org/mailman/listinfo/avt >>>> >>>> >>> >>> >>> >> >> >> Panasonic R&D Center Germany GmbH >> 63225 Langen, Hessen, Germany >> Reg: AG Offenbach (Hessen) HRB 33974 >> Managing Director: Thomas Micke >> > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From Even.roni@huawei.com Sun May 24 10:33:15 2009 Return-Path: <Even.roni@huawei.com> X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A3123A69ED for <avt@core3.amsl.com>; Sun, 24 May 2009 10:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.716 X-Spam-Level: X-Spam-Status: No, score=0.716 tagged_above=-999 required=5 tests=[AWL=-0.448, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6, SARE_RECV_BEZEQINT_B=0.763] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQeIy1R45BZw for <avt@core3.amsl.com>; Sun, 24 May 2009 10:33:13 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 397373A68B2 for <avt@ietf.org>; Sun, 24 May 2009 10:33:10 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KK5004FVSTZUL@szxga04-in.huawei.com> for avt@ietf.org; Mon, 25 May 2009 01:34:47 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KK5002QISTZJB@szxga04-in.huawei.com> for avt@ietf.org; Mon, 25 May 2009 01:34:47 +0800 (CST) Received: from windows8d787f9 (bzq-82-81-20-104.red.bezeqint.net [82.81.20.104]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KK5007WQSTHUB@szxml02-in.huawei.com>; Mon, 25 May 2009 01:34:47 +0800 (CST) Date: Sun, 24 May 2009 20:33:35 +0300 From: Roni Even <Even.roni@huawei.com> In-reply-to: <D9D7FD6A-0DFE-4A4E-8215-C8B4F54462C9@cisco.com> To: 'David R Oran' <oran@cisco.com>, 'Roni Even' <ron.even.tlv@gmail.com> Message-id: <000301c9dc95$ce1c2a80$6a547f80$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=ISO-8859-1 Content-language: en-us Content-transfer-encoding: quoted-printable Thread-index: Acncd/U2Bx7rvVnPQ6OM8st8S7h/7wAHZLRw iPlanet-SMTP-Warning: Lines longer than SMTP allows found and truncated. References: <81B9B88E2F9D574AA5328A85547CDE9101071D80@xmb-rtp-21d.amer.cisco.com> <49f1a1d6.190c660a.58fe.ffffa90e@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C80DA@xmb-sjc-215.amer.cisco.com> <49f208e8.05a0660a.5bd2.6764@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C81C9@xmb-sjc-215.amer.cisco.com> <49f211fc.07a5660a.3f7f.ffff8f4a@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8202@xmb-sjc-215.amer.cisco.com> <49f2efa2.1c215e0a.4454.ffffaf91@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8403@xmb-sjc-215.amer.cisco.com> <49f36ee2.0437560a.11df.1eef@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8405@xmb-sjc-215.amer.cisco.com> <49f387ca.0305560a.6657.4be7@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C840A@xmb-sjc-215.amer.cisco.com> <4A15D40E.80509@eu.panasonic.com> <04CAD96D4C5A3D48B1919248A8FE0D54095E153A@xmb-sjc-215.amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB011BF41B@lan-ex-02.panasonic.de> <81B9B88E2F9D574AA5328A85547CDE910142F016@xmb-rtp-.com> <4a193d46.0c11660a.33cc.109d@mx.google.com> <D9D7FD6A-0DFE-4A4E-8215-C8B4F54462C9@cisco.com> Cc: 'Jose Rey' <Jose.Rey@eu.panasonic.com>, avt@ietf.org, "'Bill Ver Steeg \(versteb\)'" <versteb@cisco.com> Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group <avt.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/avt> List-Post: <mailto:avt@ietf.org> List-Help: <mailto:avt-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 24 May 2009 17:33:15 -0000 Dave, I will start a separate thread on the issue. Just note that port may not = be enough, an example is if the RR is using a TURN relay Roni -----Original Message----- From: David R Oran [mailto:oran@cisco.com]=20 Sent: Sunday, May 24, 2009 5:00 PM To: Roni Even Cc: 'Bill Ver Steeg (versteb)'; 'Roni Even'; 'Ali C. Begen (abegen)'; = 'Jose Rey'; avt@ietf.org Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast = RTPSessions (RAMS)" available On May 24, 2009, at 8:26 AM, Roni Even wrote: > Bill, > My major point here is this is a reason for having an option port or > transport address parameter in the RAMS-R allowing the RR to provide =20 > such > address. Correct, in principle. I've already commented on the problematic =20 nature of sending complete transport addresses, so my strong =20 preference would be only to communicate port numbers (and possibly =20 SSRCs) However it's an interesting design point whether this situation is so =20 unique to RAMS that we solve it by putting the information in RAMS-R =20 messages, or whether it justifies a more general-purpose mechanism. An alternative design would be to define a separate RTCP packet type =20 to carry transport port information for "auxiliary" unicast RTP/RTCP =20 sessions. The situation we face with RAMS does in fact may arise in =20 other situations, both with and without NAT, where separate signaling =20 using offer/answer (as SIP would do) is either overkill, too much =20 overhead, or bad from a latency perspective. Just think unicast =20 retransmission for SSM by itself, without RAMS. In my view, it would be worth having a serious WG discussion of this =20 general subject before plunging ahead. If the sense is to in fact have =20 a separate mechanism, I have one sitting in my back pocket (and have =20 running open source code for). DaveO. > Roni > > -----Original Message----- > From: Bill Ver Steeg (versteb) [mailto:versteb@cisco.com] > Sent: Sunday, May 24, 2009 1:02 PM > To: Roni Even; Ali C. Begen (abegen); Jose Rey > Cc: Roni Even; avt@ietf.org > Subject: RE: [AVT] New draft of "Rapid Acquisition of Multicast =20 > RTPSessions > (RAMS)" available > > Roni- > Regarding the RS being able to send data to the RR after receiving a =20 > RAMS-R. > > There is a subtle point here, which you reference in your comment =20 > "need to > provide a reachable transport address". The RR sends the RAMS-R to the > feedback target UDP port number. In the presence of NAT, the only > communication path that is opened automatically is that single path. =20 > In > order to use the other port-pairs, holes must be poked in the NAT =20 > and the > correct NAT-ed ports must be signaled. As you know, there are many =20 > ways to > poke wholes in NAT, so we will not go into the details of how to do =20 > that. > > This is an important point, and we will be sure to make it more =20 > clear in the > next draft. > > Bvs > > > -----Original Message----- > From: Roni Even [mailto:Even.roni@huawei.com] > Sent: Saturday, May 23, 2009 8:19 AM > To: Ali C. Begen (abegen); 'Jose Rey' > Cc: 'Roni Even'; avt@ietf.org; Bill Ver Steeg (versteb) > Subject: RE: [AVT] New draft of "Rapid Acquisition of Multicast =20 > RTPSessions > (RAMS)" available > > Hi, > I also have concerns about having the unicast Transport addresses =20 > for the RR > RTCP and RTP receive port. > I think that we should first talk about the NAT/FW issue and than =20 > define the > requirements and solutions. > > My assumption is that the retransmission server has a publicly =20 > reachable > address while the receivers may sit behind NATs and will not have a =20 > publicly > reachable address. > Note that the RAMS flow starts from the receiver by RAMS-R so a =20 > response to > the transport address from where the RAMS-R came should work (RTCP is > bi-directional in this case). On the other hand the unicast data =20 > flow is to > the receiver so the receiver will need to provide a reachable =20 > transport > address. > > Roni > > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf =20 > Of Ali C. > Begen (abegen) > Sent: Saturday, May 23, 2009 3:27 AM > To: Jose Rey > Cc: Roni Even; avt@ietf.org; Bill Ver Steeg (versteb) > Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast =20 > RTPSessions > (RAMS)" available > > Hi Jose, > > Indeed, RAMS-R goes to the FT of the new primary session that RR is > interested in acquiring rapidly. Then the unicast session becomes =20 > alive and > RS sends RAMS-I message(s) to RR on the RTCP port for the unicast =20 > session. > After some time, RR sends the RAMS-T message to the RTCP port for the > unicast session since it is supposed to end the unicast session. > > -acbegen > >> -----Original Message----- >> From: Jose Rey [mailto:Jose.Rey@eu.panasonic.com] >> Sent: Friday, May 22, 2009 7:09 AM >> To: Ali C. Begen (abegen) >> Cc: Roni Even; avt@ietf.org; Bill Ver Steeg (versteb) >> Subject: RE: [AVT] New draft of "Rapid Acquisition of Multicast > RTPSessions (RAMS)" >> available >> >> >> Hi Ali, >> >>> >>> Hi Jose, >>> >>> We have separate RTCP ports for the SSM session and the unicast >>> session. Why is it a problem? >> >> In line 19 you say you specify the dst port for RMS-I (41003), on RR. >> And > you say that >> would also be the port where the RR sends RMS-T, on RS. That is =20 >> mixing >> the > semantics of >> a=3Drtcp for SSM (listening port at Feedback Target =3D mcast RTCP = dst >> port) > and those of RFC >> 3605 (dst port). In other words, you are implicitly assuming that > specifies symmetric >> RTCP...no? >> >> Another thing that was mentioned already: RMS-T is not sent to same >> port > as RMS-R; is it >> not the same RTCP session ? Or is this muxing desired? why? >> >> JLR >> >>> >>> The slightly modified SDP for the next version is below: >>> >> 1> a=3Dgroup:FID 3 4 >> 2> a=3Drtcp-unicast:rsi >> 3> m=3Dvideo 41000 RTP/AVPF 98 >> 4> i=3DPrimary Multicast Stream #2 >> 5> c=3DIN IP4 233.252.0.2/255 >> 6> a=3Dsource-filter: incl IN IP4 233.252.0.2 192.0.2.2 >> 7> a=3Drecvonly >> 8> a=3Drtpmap:98 MP2T/90000 >> 9> a=3Drtcp:41001 IN IP4 192.0.2.1 >> 10> a=3Drtcp-fb:98 nack >> 11> a=3Drtcp-fb:98 nack ssli >> 12> a=3Dssrc:123321 cname:iptv-ch32@rams.example.com >> 13> a=3Dmid:3 >> 14> m=3Dvideo 41002 RTP/AVPF 99 >> 15> i=3DUnicast Retransmission Stream #2 (Ret. and Rapid >>> Acq. Support) >> 16> c=3DIN IP4 192.0.2.1 >> 17> a=3Drecvonly >> 18> a=3Drtpmap:99 rtx/90000 >> 19> a=3Drtcp:41003 >> 20> a=3Dfmtp:99 apt=3D98; rtx-time=3D5000 >> 21> a=3Dmid:4 >>> >>> This is the SDP we send to RR. For RS, a=3Drecvonly will be =20 >>> a=3Dsendonly. >>> >>> -acbegen >>> >>> >>>> -----Original Message----- >>>> From: Jos=E9 Rey [mailto:jose.rey@eu.panasonic.com] >>>> Sent: Thursday, May 21, 2009 3:22 PM >>>> To: Ali C. Begen (abegen) >>>> Cc: Roni Even; avt@ietf.org; Bill Ver Steeg (versteb) >>>> Subject: Re: [AVT] New draft of "Rapid Acquisition of >>> Multicast RTPSessions (RAMS)" >>>> available >>>> >>>> Hi all, >>>> >>>> sorry for jumping in.... >>>> >>>> I think one of the sources of confusion is that the >>> attribute a=3Drtcp: >>>> is used once for specifying the destination port and once for >>>> specifying a receiving port, and in the same SDP (!). The >>> destination >>>> port for RAMS-I packets sent by RS and the receiving port >>> for RAMS-T. Which is also why different port numbers are used for >>> RAMS-T and -R packets. >>>> >>>> I think the use of a=3Drtcp: in SSM is the problem here. Or the = fact >>>> that we are mixing unicast and multicast, or both. >>>> >>>> Hope this helps, >>>> >>>> JLR >>>> >>>> >>>> >>>> >>>> Ali C. Begen (abegen) wrote: >>>> >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Roni Even [mailto:ron.even.tlv@gmail.com] >>>> Sent: Saturday, April 25, 2009 2:58 PM >>>> To: Ali C. Begen (abegen); avt@ietf.org >>>> Cc: Bill Ver Steeg (versteb) >>>> Subject: RE: [AVT] New draft of "Rapid Acquisition of >>>> Multicast RTPSessions (RAMS)" available >>>> >>>> Ali, >>>> I looked at RFC 4570 and I assume that port >>> 41001 is the port for the >>>> unicast RTCP reports from the receivers and according to >>>> >>>> >>>> >>>> Yes, indeed. >>>> >>>> >>>> >>>> section 3.2.1 of >>>> that RFC you also should have a RTCP-unicast >>> specification. >>>> This is for the >>>> multicast receiver reports. >>>> >>>> >>>> >>>> Correct. We do have that line in our draft at the top >>> right after the grouping lines: >>>> >>>> a=3Drtcp-unicast:rsi >>>> >>>> BR, >>>> -acbegen >>>> >>>> >>>> >>>> Roni >>>> >>>> -----Original Message----- >>>> From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] >>>> Sent: Saturday, April 25, 2009 11:30 PM >>>> To: Roni Even; avt@ietf.org >>>> Cc: Bill Ver Steeg (versteb) >>>> Subject: RE: [AVT] New draft of "Rapid Acquisition of >>>> Multicast RTPSessions >>>> (RAMS)" available >>>> >>>> Here is the SDP. >>>> >>>> m=3Dvideo 41000 RTP/AVPF 98 >>>> i=3DPrimary Multicast Stream #2 >>>> c=3DIN IP4 224.1.1.2/255 >>>> a=3Dsource-filter: incl IN IP4 224.1.1.2 192.0.2.2 >>>> >>>> Source (192.0.2.2) sends the rtp packets to the >>> multicast >>>> group (224.1.1.2) >>>> with a dest port 41000. >>>> >>>> a=3Drtpmap:98 MP2T/90000 >>>> a=3Drtcp:41001 IN IP4 192.0.2.1 >>>> >>>> The feedback target (RS) address for this SSM session is >>>> 192.0.2.1 and its >>>> port is 41001. This is the address/port where >>> RR sends the RAMS-R, or >>>> receiver reports for the SSM session. >>>> >>>> a=3Drtcp-fb:98 nack >>>> a=3Drtcp-fb:98 nack ssli >>>> a=3Dssrc:123321 cname:iptv-ch32@rams.example.com >>>> a=3Dmid:3 >>>> m=3Dvideo 41002 RTP/AVPF 99 >>>> >>>> The retransmission packets go to port 41002. >>> This is the port >>>> RRs listen to >>>> for retransmission and RAMS. >>>> >>>> i=3DUnicast Retransmission Stream #2 >>> (Ret. and Rapid >>>> Acq. Support) >>>> c=3DIN IP4 192.0.2.1 >>>> >>>> This is where the retransmission packets come >>> from, same as >>>> the feedback >>>> target (in this example). >>>> >>>> a=3Drtpmap:99 rtx/90000 >>>> a=3Drtcp:41003 >>>> >>>> This is where the RTCP packets for the >>> retransmission session go. For >>>> example, RAMS-I goes to this port on RRs. >>> RAMS-T goes to this >>>> port on RS. >>>> >>>> a=3Dfmtp:99 apt=3D98; rtx-time=3D5000 >>>> a=3Dmid:4 >>>> >>>> >>>> -acbegen >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Roni Even [mailto:ron.even.tlv@gmail.com] >>>> Sent: Saturday, April 25, 2009 1:11 PM >>>> To: Ali C. Begen (abegen); avt@ietf.org >>>> Cc: Bill Ver Steeg (versteb) >>>> Subject: RE: [AVT] New draft of "Rapid >>> Acquisition of >>>> Multicast RTPSessions (RAMS)" available >>>> >>>> Ali, >>>> Can you please write three addresses >>> from this strange SDP. >>>> >>>> 1. The address and port of multicast >>>> >>>> 2. The address and port of the RS where >>> the RTCP FB should go to >>>> >>>> 3. The address and port on the RR where >>> the unicast stream >>>> should be sent to >>>> >>>> Roni >>>> >>>> -----Original Message----- >>>> From: Ali C. Begen (abegen) >>> [mailto:abegen@cisco.com] >>>> Sent: Saturday, April 25, 2009 11:02 PM >>>> To: Roni Even; avt@ietf.org >>>> Cc: Bill Ver Steeg (versteb) >>>> Subject: RE: [AVT] New draft of "Rapid >>> Acquisition of >>>> Multicast RTPSessions >>>> (RAMS)" available >>>> >>>> >>>> >>>> Ali, >>>> The example SDP is >>> syntactically correct but it does not >>>> >>>> >>>> say that the >>>> >>>> >>>> rtp/rtcp mux will be used and >>> it does not give the >>>> information to where the >>>> unicast stream will be sent >>> when the RR sends a RAMS-R. >>>> >>>> >>>> To my knowledge, the first line in the >>> following SDP tells >>>> the RRs on which >>>> port they will receive the >>> retransmission/burst packets. >>>> >>>> m=3Dvideo 41002 RTP/AVPF 99 >>>> i=3DUnicast Retransmission Stream >>> #2 (Ret. and Rapid >>>> Acq. Support) >>>> c=3DIN IP4 192.0.2.1 >>>> a=3Drtpmap:99 rtx/90000 >>>> a=3Drtcp:41003 >>>> a=3Dfmtp:99 apt=3D98; rtx-time=3D5000 >>>> a=3Dmid:4 >>>> >>>> There is a typo, you are right. That >>> "a=3Drecvonly" line should >>>> only exist in >>>> the SDP sent to RRs. In the SDP sent to >>> RS, we should rather have >>>> "a=3Dsendonly". I will make this >>> correction in the next version. >>>> >>>> The feedback target for the SSM session >>> and the RTCP port for the >>>> retransmission session are also defined >>> in the SDP. >>>> >>>> Hope this clarifies. >>>> >>>> BR, >>>> -acbegen >>>> >>>> >>>> >>>> I am not sure why the unicast >>> stream m-line has a port >>>> >>>> >>>> number with an >>>> >>>> >>>> attribute of recvonly. What is >>> the use case for that. The >>>> only information >>>> that the RR will need is the >>> RTCP port on the RS to where to >>>> send the RAMS-R >>>> message. >>>> Roni >>>> -----Original Message----- >>>> From: Ali C. Begen (abegen) >>> [mailto:abegen@cisco.com] >>>> Sent: Friday, April 24, 2009 10:37 PM >>>> To: Roni Even; avt@ietf.org >>>> Cc: Bill Ver Steeg (versteb) >>>> Subject: RE: [AVT] New draft of >>> "Rapid Acquisition of >>>> Multicast RTPSessions >>>> (RAMS)" available >>>> >>>> This is a part of an example >>> SDP sent to RS and RR in a SAP >>>> announcement, >>>> for example. So, the SDP >>> describes what both parties should >>>> do (RR cannot >>>> say that he wants to receive >>> this multicast on its favorite >>>> >>>> >>>> port). The >>>> >>>> >>>> individual SDPs sent to RR or >>> RS may include other portions >>>> of descriptions >>>> that will contain specific information. >>>> >>>> -acbegen >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Roni Even >>> [mailto:ron.even.tlv@gmail.com] >>>> Sent: Friday, April 24, >>> 2009 12:23 PM >>>> To: Ali C. Begen >>> (abegen); avt@ietf.org >>>> Cc: Bill Ver Steeg (versteb) >>>> Subject: RE: [AVT] New >>> draft of "Rapid Acquisition of >>>> Multicast RTPSessions >>> (RAMS)" available >>>> >>>> Ali, >>>> I think you get it >>> wrong, this SDP is from the RS and not the >>>> RR so the RS >>>> cannot specify to which >>> address it will send it can only >>>> specify to which >>>> address it can receive >>> RTP stream. In this SDP the relevant >>>> information is >>>> that the request for >>> retransmission will be sent by the RR to >>>> port 41003 >>>> Roni >>>> >>>> -----Original Message----- >>>> From: Ali C. Begen >>> (abegen) [mailto:abegen@cisco.com] >>>> Sent: Friday, April 24, >>> 2009 10:01 PM >>>> To: Roni Even; avt@ietf.org >>>> Cc: Bill Ver Steeg (versteb) >>>> Subject: RE: [AVT] New >>> draft of "Rapid Acquisition of >>>> Multicast RTPSessions >>>> (RAMS)" available >>>> >>>> Oh, I see. The burst >>> goes to the port that we would >>>> >>>> >>>> normally send the >>>> >>>> >>>> retransmissions. For >>> example, consider the SDP from the draft: >>>> >>>> m=3Dvideo 41000 >>> RTP/AVPF 98 >>>> i=3DPrimary >>> Multicast Stream #2 >>>> c=3DIN IP4 224.1.1.2/255 >>>> >>> a=3Dsource-filter: incl IN IP4 224.1.1.2 192.0.2.2 >>>> a=3Drtpmap:98 MP2T/90000 >>>> a=3Drtcp:41001 IN >>> IP4 192.0.2.1 >>>> a=3Drtcp-fb:98 nack >>>> a=3Drtcp-fb:98 nack ssli >>>> a=3Dssrc:123321 >>> cname:iptv-ch32@rams.example.com >>>> a=3Dmid:3 >>>> m=3Dvideo 41002 >>> RTP/AVPF 99 >>>> i=3DUnicast >>> Retransmission Stream #2 (Ret. and Rapid >>>> Acq. Support) >>>> c=3DIN IP4 192.0.2.1 >>>> a=3Drecvonly >>>> a=3Drtpmap:99 rtx/90000 >>>> a=3Drtcp:41003 >>>> a=3Dfmtp:99 >>> apt=3D98; rtx-time=3D5000 >>>> a=3Dmid:4 >>>> >>>> In this case, the burst >>> will go to port 41002 on the RR. >>>> >>>> >>>> The RAMS-I >>>> >>>> >>>> message(s), which is an >>> RTCP feedback message, will go to >>>> >>>> >>>> port 41003. >>>> >>>> >>>> HTH, >>>> -acbegen >>>> >>>> >>>> >>>> -----Original >>> Message----- >>>> From: Roni Even >>> [mailto:ron.even.tlv@gmail.com] >>>> Sent: Friday, >>> April 24, 2009 11:44 AM >>>> To: Ali C. >>> Begen (abegen); avt@ietf.org >>>> Cc: Bill Ver >>> Steeg (versteb) >>>> Subject: RE: >>> [AVT] New draft of "Rapid Acquisition of >>>> Multicast >>> RTPSessions (RAMS)" available >>>> >>>> Ali, >>>> I will try to >>> explain in simple way >>>> >>>> When the RS >>> receives the RAMS-R it need to start sending an >>>> RTP stream to >>>> the RR. >>>> In order to >>> send a unicast packet, the RS needs to know a >>>> transport address >>>> on the RR to >>> where the RTP stream will be sent. The current >>>> draft does not >>>> say how the RS >>> knows this address. There is no SDP from RR to >>>> RS like you >>>> mention in your >>> response. >>>> This is why I >>> say that the current draft does not specify a >>>> solution that >>>> can be >>> implemented as a working solution >>>> Roni >>>> >>>> -----Original >>> Message----- >>>> From: Ali C. >>> Begen (abegen) [mailto:abegen@cisco.com] >>>> Sent: Friday, >>> April 24, 2009 7:38 PM >>>> To: Roni Even; >>> avt@ietf.org >>>> Cc: Bill Ver >>> Steeg (versteb) >>>> Subject: RE: >>> [AVT] New draft of "Rapid Acquisition of >>>> Multicast RTPSessions >>>> (RAMS)" available >>>> >>>> Hi Roni, >>>> >>>> >>>> >>>> >>> -----Original Message----- >>>> From: >>> avt-bounces@ietf.org [mailto:avt- bounces@ietf.org] On >>>> Behalf >>> Of Roni Even >>>> Sent: >>> Friday, April 24, 2009 4:24 AM >>>> To: avt@ietf.org >>>> Cc: >>> Bill Ver Steeg (versteb) >>>> >>> Subject: Re: [AVT] New draft of "Rapid Acquisition of >>>> >>> Multicast RTPSessions (RAMS)" available >>>> >>>> Hi, >>>> >>>> I think >>> that the current draft does not give a >>>> >>>> >>>> description of >>>> >>>> >>>> a >>> system that works since there is no text >>>> >>>> >>>> explaining how the >>>> >>>> >>>> What do you >>> mean by "a system that works"? >>>> >>>> >>>> >>>> RS >>> knows the unicast transport address on the RR to >>>> >>>> >>>> where to >>>> >>>> >>>> send the stream. >>>> >>>> >>>> Once RS >>> receives the request packet from an RR, RS knows its >>>> address. Ports >>>> are defined in >>> the SDP. If you are asking about "NAT" >>>> issues, >>>> we have a >>>> section for it, >>> and we plan to complete it as we move >>>> forward. It is not as >>>> critical as the >>> other parts for now. >>>> >>>> >>>> >>>> If you >>> mandate the use of RTP/RTCP mux it should say so >>>> >>> otherwise the RAMS-R should have an optional parameter that >>>> >>> supplies this information and a flag for using RTP/RTCP mux. >>>> >>>> >>>> IMO, we cannot >>> mandate muxing as it is not required to make >>>> RAMS work. If >>>> muxing is >>> supported, the SDP should reflect it. >>>> >>>> BR, >>>> -acbegen >>>> >>>> >>>> >>>> Thanks >>>> >>>> Roni Even >>>> >>>> >>>> >>>> From: >>> avt-bounces@ietf.org [mailto:avt- bounces@ietf.org] On >>>> Behalf >>> Of Bill Ver Steeg (versteb) >>>> Sent: >>> Thursday, April 16, 2009 7:39 PM >>>> To: avt@ietf.org >>>> >>> Subject: [AVT] New draft of "Rapid Acquisition of Multicast >>>> RTP >>> Sessions (RAMS)" available >>>> >>>> >>>> >>>> There >>> is a new draft of the "Rapid Acquisition of Multicast >>>> RTP >>> Sessions (RAMS)" draft available at >>>> >>>> >>>> >>>> >>> http://www.ietf.org/internet-drafts/draft-versteeg-avt-rapid-s >>>> >>>> >>>> >>> ynchronization-for-rtp-03.txt >>>> <http://www.ietf.org/internet-> <http://www.ietf.org/internet-> >>>> >>>> >>>> >>>> >>> drafts/draft-versteeg-avt-rapid-synchronization-for-rtp-03.txt> >>>> >>>> >>>> >>>> >>>> We have >>> incorporated the changes from the technical >>>> >>>> >>>> breakout >>>> >>>> >>>> session >>> in San Francisco. The major changes in this version >>>> of the >>> draft include >>>> >>>> 1- >>> Changing the document title to avoid confusion >>>> >>>> >>>> with other >>>> >>>> >>>> ongoing >>> "synchronization" drafts >>>> >>>> 2- >>> changing the message names to reflect the title change >>>> >>>> 3- >>> clarification of the RTCP message semantics, including >>>> changes >>> to the "Request" and "Inform" messages >>>> >>>> 4- >>> additional description/motivation for the >>>> >>>> >>>> various message >>>> >>>> >>>> flows >>> has been added >>>> >>>> 5- >>> RTP/RTCP muxing has been added >>>> >>>> >>>> >>>> >>>> >>>> We hope >>> to make this a Working Group item, and will change >>>> the >>> name of the draft to avoid conflicts with other >>>> >>> "synchronization" drafts at that time. >>>> >>>> >>>> >>>> Bill VerSteeg >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Audio/Video Transport Working Group >>>> avt@ietf.org >>>> https://www.ietf.org/mailman/listinfo/avt >>>> >>>> >>> >>> >>> >> >> >> Panasonic R&D Center Germany GmbH >> 63225 Langen, Hessen, Germany >> Reg: AG Offenbach (Hessen) HRB 33974 >> Managing Director: Thomas Micke >> > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From Even.roni@huawei.com Sun May 24 11:51:32 2009 Return-Path: <Even.roni@huawei.com> X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 544633A698A for <avt@core3.amsl.com>; Sun, 24 May 2009 11:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.27 X-Spam-Level: ** X-Spam-Status: No, score=2.27 tagged_above=-999 required=5 tests=[AWL=2.764, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cCU90yZ6ta90 for <avt@core3.amsl.com>; Sun, 24 May 2009 11:51:31 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 848CC3A6D67 for <avt@ietf.org>; Sun, 24 May 2009 11:51:30 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KK500FY2WGCOJ@szxga03-in.huawei.com> for avt@ietf.org; Mon, 25 May 2009 02:53:00 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KK500E9XWGCID@szxga03-in.huawei.com> for avt@ietf.org; Mon, 25 May 2009 02:53:00 +0800 (CST) Received: from windows8d787f9 (bzq-79-182-101-49.red.bezeqint.net [79.182.101.49]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KK5007SDWG0UB@szxml02-in.huawei.com>; Mon, 25 May 2009 02:53:00 +0800 (CST) Date: Sun, 24 May 2009 21:51:56 +0300 From: Roni Even <Even.roni@huawei.com> To: avt@ietf.org Message-id: <001701c9dca0$bd465130$37d2f390$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_51VrLTGO9fkyoCq5YyBMFg)" Content-language: en-us Thread-index: AcncoLYwVfWnqB14StiAMYm6TwYu6Q== Cc: "'Dave Oran \(oran\)'" <oran@cisco.com> Subject: [AVT] RTP unicast address for retransmssion of multicast sesssion or using RTCP to negotitaion of RTP adddresses X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group <avt.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/avt> List-Post: <mailto:avt@ietf.org> List-Help: <mailto:avt-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 24 May 2009 18:51:32 -0000 This is a multipart message in MIME format. --Boundary_(ID_51VrLTGO9fkyoCq5YyBMFg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, One of the issues discussed in Rapid Acquisition of Multicast RTPSessions (RAMS) has to do with the specific architecture where the media is sent to an announced multicast address where there is no offer answer negotiation between the sender and the receivers. In the proposed solution receivers may ask using RTCP for unicast retransmission of the RTP stream. The current draft has as part of the announcement a port number that the receiver should use to receive the unicast RTP stream. This port is specified by the retransmission server and not by the receiver and it assumes that the IP address will be the same as the one from where the RTCP message came from. The problem we encounter is that this retransmission stream is flowing from the retransmission server to the receiver who may be behind a FW/NAT. The simple case is if the RTP and RTCP streams are multiplexed on the RTCP port since in this case there is an RTCP message going from the receiver to the retransmission server which will open a pin hole in the NAT/FW enabling RTP to flow back to the receiver (Will need some keep alive mechanism) The case we are trying to discuss here is when we want to have a separate RTP channel (not multiplexed with RTCP). In this case we will need some mechanism to convey an address from the receiver to the retransmission server. We would like to ask if this should be part of RAMS or do we want a general RTCP message to covey such information. We would like to get some other scenarios not for RAMS that have similar requirements. Looking at previous work RFC 4588 when discussing retransmission for multicast channel is using a multicast group for the retransmission for small groups. It does not address the above problem. For the unicast case it is suing offer answer to negotiate addresses. The discussion in RFC 4588 as well as RFC 2887 do not address the same application requirement where each user that joins the multicast group wants to get a unicast stream with synchronization information and not a regular retransmission due to information loss. http://tools.ietf.org/html/draft-ietf-avt-rtcpssm-18 does not address retransmission but has as part of the RSI message from the distribution source a way to suggest a different feedback target transport address that overrides the one announced in the SDP. In RTSP the setup request from the receiver carries the transport initialization information enabling the receiver to specify a transport address for the stream. Thanks Roni Even --Boundary_(ID_51VrLTGO9fkyoCq5YyBMFg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT <html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv=Content-Type content="text/html; charset=us-ascii"> <meta name=Generator content="Microsoft Word 12 (filtered medium)"> <style> <!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} span.EmailStyle17 {mso-style-type:personal-compose; font-family:"Calibri","sans-serif"; color:windowtext;} .MsoChpDefault {mso-style-type:export-only;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.25in 1.0in 1.25in;} div.Section1 {page:Section1;} --> </style> <!--[if gte mso 9]><xml> <o:shapedefaults v:ext="edit" spidmax="1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext="edit"> <o:idmap v:ext="edit" data="1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=EN-US link=blue vlink=purple> <div class=Section1> <p class=MsoNormal>Hi,<o:p></o:p></p> <p class=MsoNormal><o:p> </o:p></p> <p class=MsoNormal><o:p> </o:p></p> <p class=MsoNormal>One of the issues discussed in Rapid Acquisition of Multicast RTPSessions (RAMS) has to do with the specific architecture where the media is sent to an announced multicast  address where there is no offer answer negotiation between the sender and the receivers.  In the proposed solution  receivers may ask using RTCP for unicast retransmission of the RTP stream. The current draft has as part of the announcement a port number that the receiver should use to receive the unicast RTP stream.  This port is specified by the retransmission server and not by the receiver and it assumes that the IP address will be the same as the one from where the RTCP message came from.<o:p></o:p></p> <p class=MsoNormal><o:p> </o:p></p> <p class=MsoNormal>The problem we encounter is that this retransmission stream is flowing from the retransmission server to the receiver who may be behind a FW/NAT. The simple case is if the RTP and RTCP streams are multiplexed on the RTCP port since in this case there is an RTCP message going from the receiver to the retransmission server which will open a pin hole in the NAT/FW enabling RTP to flow back to the receiver (Will need some keep alive mechanism)<o:p></o:p></p> <p class=MsoNormal>The case we are trying to discuss here is when we want to have a separate RTP channel (not multiplexed with RTCP). In this case we will need some mechanism to convey an address from the receiver to the retransmission server. <o:p></o:p></p> <p class=MsoNormal><o:p> </o:p></p> <p class=MsoNormal>We would like to ask if this should be part of RAMS or do we want a general RTCP message to covey such information.<o:p></o:p></p> <p class=MsoNormal>We would like to get some other scenarios not for RAMS that have similar requirements.<o:p></o:p></p> <p class=MsoNormal><o:p> </o:p></p> <p class=MsoNormal>Looking at previous work<o:p></o:p></p> <p class=MsoNormal><o:p> </o:p></p> <p class=MsoNormal>RFC 4588 when discussing retransmission for multicast channel is using a multicast group for the retransmission for small groups. It does not address the above problem. For the unicast case it is suing offer answer to negotiate addresses. The discussion in RFC 4588 as well as RFC 2887 do not address the same application requirement where each user that joins the multicast group wants to get a unicast stream with synchronization information and not a regular retransmission due to information loss.<o:p></o:p></p> <p class=MsoNormal><o:p> </o:p></p> <p class=MsoNormal><a href="http://tools.ietf.org/html/draft-ietf-avt-rtcpssm-18">http://tools.ietf.org/html/draft-ietf-avt-rtcpssm-18</a> does not address retransmission but has as part of the RSI message from the distribution source a way to suggest a different feedback target transport address that overrides the one announced in the SDP.<o:p></o:p></p> <p class=MsoNormal><o:p> </o:p></p> <p class=MsoNormal>In RTSP the setup request from the receiver carries the transport initialization information enabling the receiver to specify a transport address for the stream.<o:p></o:p></p> <p class=MsoNormal><o:p> </o:p></p> <p class=MsoNormal>Thanks<o:p></o:p></p> <p class=MsoNormal>Roni Even <o:p></o:p></p> <p class=MsoNormal><o:p> </o:p></p> <p class=MsoNormal><o:p> </o:p></p> <p class=MsoNormal><o:p> </o:p></p> </div> </body> </html> --Boundary_(ID_51VrLTGO9fkyoCq5YyBMFg)-- From gherlein@herlein.com Sun May 24 13:32:44 2009 Return-Path: <gherlein@herlein.com> X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B54DB3A6768 for <avt@core3.amsl.com>; Sun, 24 May 2009 13:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[AWL=-0.524, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oeSwiV1O7jZA for <avt@core3.amsl.com>; Sun, 24 May 2009 13:32:41 -0700 (PDT) Received: from mail-pz0-f112.google.com (mail-pz0-f112.google.com [209.85.222.112]) by core3.amsl.com (Postfix) with ESMTP id C791D3A6D99 for <avt@ietf.org>; Sun, 24 May 2009 13:32:41 -0700 (PDT) Received: by pzk10 with SMTP id 10so1770457pzk.29 for <avt@ietf.org>; Sun, 24 May 2009 13:34:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.52.7 with SMTP id z7mr2030602wfz.260.1243197260545; Sun, 24 May 2009 13:34:20 -0700 (PDT) In-Reply-To: <618e24240905240032k7048df35ldde7cdd5f4c89b73@mail.gmail.com> References: <302f570905221154t7feb4162s6728f9dc2c736592@mail.gmail.com> <C63C617C.372F%luby@qualcomm.com> <31d1be720905221451t844a033ufe37b44884b56f83@mail.gmail.com> <302f570905221508q637770ebi89582187526d1594@mail.gmail.com> <p0624080bc63cffcf77fe@10.0.1.8> <02c801c9dbf6$ff8d2e10$fea78a30$%roni@huawei.com> <31d1be720905231621l2b986becw9c64cd1a08d90f0a@mail.gmail.com> <618e24240905240032k7048df35ldde7cdd5f4c89b73@mail.gmail.com> Date: Sun, 24 May 2009 13:34:20 -0700 Message-ID: <31d1be720905241334s4c959ccs73880b4493b83c4d@mail.gmail.com> From: Greg Herlein <gherlein@herlein.com> To: =?ISO-8859-1?Q?Victor_Pascual_=C1vila?= <victor.pascual.avila@gmail.com> Content-Type: multipart/alternative; boundary=000e0cd2146c19c82c046aae6b1e Cc: David Singer <singer@apple.com>, Roni Even <Even.roni@huawei.com>, avt@ietf.org Subject: Re: [AVT] Comments on draft-pantos-http-live-streaming-00.txt ... X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group <avt.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/avt> List-Post: <mailto:avt@ietf.org> List-Help: <mailto:avt-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 24 May 2009 20:32:44 -0000 --000e0cd2146c19c82c046aae6b1e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks Victor. I found this too: http://labs.chinamobile.com/attachments/Yunfei-Zhangs-problem-statement-Sli= des.pdf That helps articulate the problem we are trying to solve. 2009/5/24 Victor Pascual =C1vila <victor.pascual.avila@gmail.com> > On Sun, May 24, 2009 at 1:21 AM, Greg Herlein <gherlein@herlein.com> > wrote: > >> > >> > I hope that you are all aware on the p2p streaming discussion that > took > >> > place in the last two IETF meetings as BAR BOFs. > > > > Are there minutes of the p2p streaming meetings? > > http://www.ietf.org/mail-archive/web/ppsp/current/msg00158.html > http://www.ietf.org/mail-archive/web/ppsp/current/msg00157.html > > More info: http://labs.chinamobile.com/ppsp/ietf > > Cheers, > -- > Victor Pascual =C1vila > --=20 Greg Herlein www.herlein.com --000e0cd2146c19c82c046aae6b1e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks Victor.=A0 I found this too:<br><a href=3D"http://labs.chinamobile.c= om/attachments/Yunfei-Zhangs-problem-statement-Slides.pdf">http://labs.chin= amobile.com/attachments/Yunfei-Zhangs-problem-statement-Slides.pdf</a><br><= br> That helps articulate the problem we are trying to solve.<br><span class=3D= "status-body"><span class=3D"entry-content"></span></span><br><br><div clas= s=3D"gmail_quote">2009/5/24 Victor Pascual =C1vila <span dir=3D"ltr"><<a= href=3D"mailto:victor.pascual.avila@gmail.com">victor.pascual.avila@gmail.= com</a>></span><br> <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class=3D"im"= >On Sun, May 24, 2009 at 1:21 AM, Greg Herlein <<a href=3D"mailto:gherle= in@herlein.com">gherlein@herlein.com</a>> wrote:<br> >><br> >> > I hope that you are all aware on the p2p streaming discussion= that took<br> >> > place in the last two IETF meetings as BAR BOFs.<br> ><br> > Are there minutes of the p2p streaming meetings?<br> <br> </div><a href=3D"http://www.ietf.org/mail-archive/web/ppsp/current/msg00158= .html" target=3D"_blank">http://www.ietf.org/mail-archive/web/ppsp/current/= msg00158.html</a><br> <a href=3D"http://www.ietf.org/mail-archive/web/ppsp/current/msg00157.html"= target=3D"_blank">http://www.ietf.org/mail-archive/web/ppsp/current/msg001= 57.html</a><br> <br> More info: <a href=3D"http://labs.chinamobile.com/ppsp/ietf" target=3D"_bla= nk">http://labs.chinamobile.com/ppsp/ietf</a><br> <br> Cheers,<br> --<br> <font color=3D"#888888">Victor Pascual =C1vila<br> </font></blockquote></div><br><br clear=3D"all"><br>-- <br>Greg Herlein<br>= <a href=3D"http://www.herlein.com">www.herlein.com</a><br> --000e0cd2146c19c82c046aae6b1e-- From abegen@cisco.com Sun May 24 23:29:30 2009 Return-Path: <abegen@cisco.com> X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D33543A6E45; Sun, 24 May 2009 23:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.39 X-Spam-Level: X-Spam-Status: No, score=-6.39 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDQRB6wanTxV; Sun, 24 May 2009 23:29:30 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id EE4CA3A6E53; Sun, 24 May 2009 23:29:29 -0700 (PDT) X-Files: draft-ietf-fecframe-1d2d-parity-scheme-01.URL : 106 X-IronPort-AV: E=Sophos;i="4.41,243,1241395200"; d="url'?scan'208";a="310169651" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 25 May 2009 06:31:11 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n4P6VAY0029277; Sun, 24 May 2009 23:31:10 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n4P6VAEI024700; Mon, 25 May 2009 06:31:10 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 24 May 2009 23:31:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C9DD02.648F38B7" Date: Sun, 24 May 2009 23:31:03 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54095E1974@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] I-D Action:draft-ietf-fecframe-1d2d-parity-scheme-01.txt Thread-Index: AcndALTE0vhLEce8TlyfMdInJpEN8QAAVY7A From: "Ali C. Begen (abegen)" <abegen@cisco.com> To: <fecframe@ietf.org> X-OriginalArrivalTime: 25 May 2009 06:31:10.0661 (UTC) FILETIME=[64BDE750:01C9DD02] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2889; t=1243233070; x=1244097070; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20<abegen@cisco. com> |Subject:=20FW=3A=20[Fecframe]=20I-D=20Action=3Adraft-ietf- fecframe-1d2d-parity-scheme-01.txt |Sender:=20; bh=N0Ho0xnHO2Q1MY+iFtLSNrVSPa+XkWoPOOI5bLoq3bo=; b=bvXuLgr8QpOrDScAyOGXFjt96YXv/clf2KbS+pro9dsgHB0CD0GXkgxZjk /xy4u7cTbanCrlOeGp+AFwagsp5XWpYLKOJHf+D+4g99gFU8JAllxFCK8zbb 72itUcFfHn; Authentication-Results: sj-dkim-4; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: avt@ietf.org Subject: [AVT] FW: [Fecframe] I-D Action:draft-ietf-fecframe-1d2d-parity-scheme-01.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group <avt.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/avt> List-Post: <mailto:avt@ietf.org> List-Help: <mailto:avt-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 25 May 2009 06:29:30 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9DD02.648F38B7 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I completed the missing sections and fixed a few editorial issues. This = version should be a complete one. Comments are welcome. http://www.ietf.org/internet-drafts/draft-ietf-fecframe-1d2d-parity-schem= e-01.txt -acbegen -----Original Message----- From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On = Behalf Of Internet-Drafts@ietf.org Sent: Sunday, May 24, 2009 11:15 PM To: i-d-announce@ietf.org Cc: fecframe@ietf.org Subject: [Fecframe] I-D = Action:draft-ietf-fecframe-1d2d-parity-scheme-01.txt A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the FEC Framework Working Group of the = IETF. Title : RTP Payload Format for Non-Interleaved and = Interleaved Parity FEC Author(s) : A. Begen Filename : draft-ietf-fecframe-1d2d-parity-scheme-01.txt Pages : 39 Date : 2009-05-24 This document defines new RTP payload formats for the Forward Error Correction (FEC) that is generated by the non-interleaved and interleaved parity codes from a source media encapsulated in RTP. These parity codes are systematic codes, where a number of repair symbols are generated from a set of source symbols and sent in a repair flow separate from the source flow that carries the source symbols. The non-interleaved and interleaved parity codes offer a good protection against random and bursty packet losses, respectively, at a cost of decent complexity. The RTP payload formats that are defined in this document address the scalability issues experienced with the earlier specifications including RFC 2733, RFC 5109 and SMPTE 2022-1, and offer several improvements. Due to these changes, the new payload formats are not backward compatible with the earlier specifications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fecframe-1d2d-parity-schem= e-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C9DD02.648F38B7 Content-Type: application/octet-stream; name="draft-ietf-fecframe-1d2d-parity-scheme-01.URL" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-fecframe-1d2d-parity-scheme-01.URL Content-Disposition: attachment; filename="draft-ietf-fecframe-1d2d-parity-scheme-01.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLWZlY2ZyYW1lLTFkMmQtcGFyaXR5LXNjaGVtZS0wMS50eHQNCg== ------_=_NextPart_001_01C9DD02.648F38B7-- From tom.taylor@rogers.com Mon May 25 04:29:52 2009 Return-Path: <tom.taylor@rogers.com> X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3DAE28C183 for <avt@core3.amsl.com>; Mon, 25 May 2009 04:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXGU5cYnSpx3 for <avt@core3.amsl.com>; Mon, 25 May 2009 04:29:52 -0700 (PDT) Received: from smtp121.rog.mail.re2.yahoo.com (smtp121.rog.mail.re2.yahoo.com [206.190.53.26]) by core3.amsl.com (Postfix) with SMTP id B649B28C169 for <avt@ietf.org>; Mon, 25 May 2009 04:29:51 -0700 (PDT) Received: (qmail 33931 invoked from network); 25 May 2009 11:31:30 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=FevA4Gv9LV0q6ylSTaZ5jvCtdt6d2AmVaDJK8k6BRfLpio6rZo+OuDAj0B79lhECU1W0C/rruTg/6IIue45O9ZtjepHWQjYrtKGAsAYo/vqp+HbGMCWrfH7c7sWxRVMvNnRiQ4vrWpC24x5LrIizko/v6B+0ylAkbSz1QVWKLUw= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@174.115.211.243 with plain) by smtp121.rog.mail.re2.yahoo.com with SMTP; 25 May 2009 11:31:30 -0000 X-YMail-OSG: 2Wji970VM1lyXj.lSaN42euL4wT5YQlCxqez6KAURqEU2OF4c0r5qnNw7dPm7WvlBw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A1A8192.2020807@rogers.com> Date: Mon, 25 May 2009 07:31:30 -0400 From: Tom Taylor <tom.taylor@rogers.com> User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Ali C. Begen (abegen)" <abegen@cisco.com> References: <04CAD96D4C5A3D48B1919248A8FE0D54095E1974@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D54095E1974@xmb-sjc-215.amer.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: avt@ietf.org Subject: Re: [AVT] FW: [Fecframe] I-D Action:draft-ietf-fecframe-1d2d-parity-scheme-01.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group <avt.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/avt> List-Post: <mailto:avt@ietf.org> List-Help: <mailto:avt-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 25 May 2009 11:29:52 -0000 I'm resending this to AVT because it bounced from a few addresses as a result of the MIME type the announcements use. Notice that I chopped that part off. Ali C. Begen (abegen) wrote: > I completed the missing sections and fixed a few editorial issues. This version should be a complete one. Comments are welcome. > > http://www.ietf.org/internet-drafts/draft-ietf-fecframe-1d2d-parity-scheme-01.txt > > -acbegen > > -----Original Message----- > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org > Sent: Sunday, May 24, 2009 11:15 PM > To: i-d-announce@ietf.org > Cc: fecframe@ietf.org > Subject: [Fecframe] I-D Action:draft-ietf-fecframe-1d2d-parity-scheme-01.txt > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the FEC Framework Working Group of the IETF. > > > Title : RTP Payload Format for Non-Interleaved and Interleaved Parity FEC > Author(s) : A. Begen > Filename : draft-ietf-fecframe-1d2d-parity-scheme-01.txt > Pages : 39 > Date : 2009-05-24 > > This document defines new RTP payload formats for the Forward Error > Correction (FEC) that is generated by the non-interleaved and > interleaved parity codes from a source media encapsulated in RTP. > These parity codes are systematic codes, where a number of repair > symbols are generated from a set of source symbols and sent in a > repair flow separate from the source flow that carries the source > symbols. The non-interleaved and interleaved parity codes offer a > good protection against random and bursty packet losses, > respectively, at a cost of decent complexity. The RTP payload > formats that are defined in this document address the scalability > issues experienced with the earlier specifications including RFC > 2733, RFC 5109 and SMPTE 2022-1, and offer several improvements. Due > to these changes, the new payload formats are not backward compatible > with the earlier specifications. > ... From stockhammer@nomor.de Mon May 25 07:31:52 2009 Return-Path: <stockhammer@nomor.de> X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 319983A679C; Mon, 25 May 2009 07:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.76 X-Spam-Level: X-Spam-Status: No, score=-0.76 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4W7TBiV09vy; Mon, 25 May 2009 07:31:51 -0700 (PDT) Received: from mo-p00-ob.rzone.de (mo-p00-ob.rzone.de [81.169.146.162]) by core3.amsl.com (Postfix) with ESMTP id 11F7C3A6978; Mon, 25 May 2009 07:31:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1243262011; l=1774; s=domk; d=nomor.de; h=References:Date:Subject:Mime-Version:Content-Transfer-Encoding: Content-Type:In-Reply-To:To:From:Cc:X-RZG-CLASS-ID:X-RZG-AUTH; bh=NzP106yf5g9WO0mPHLfjxEuotc4=; b=zBrq31O4BKHB8EUbJm2LCZYibR9m78706dok62H/ofRFD89+CXyviMr8zcoxT5Q861m 8mEAtwg3Mb+lbs50zWk1PMbHMtNmz+vB/iy0MJg+wePJ4reQQ3fgy8lAZN6NLMnLXdrwa fLjVJadAOREKDRCZj3wpc/3tqqh6T5tyLbY= X-RZG-AUTH: :P3gLdkugevKirJkjH/RoTtk5THWq6nlFgKpnuMPeiu18+1EZfOQVAS4z6gUSvLg= X-RZG-CLASS-ID: mo00 Received: from [192.168.0.165] (dialbs-213-023-252-114.static.arcor-ip.net [213.23.252.114]) by post.strato.de (fruni mo36) (RZmta 18.37) with ESMTP id x039d8l4PEN4Gm ; Mon, 25 May 2009 16:33:26 +0200 (MEST) Message-Id: <5AB53BB4-72A7-46E3-9A3E-E53E246D6A14@nomor.de> From: Thomas Stockhammer <stockhammer@nomor.de> To: David Singer <singer@apple.com> In-Reply-To: <p0624080bc63cffcf77fe@[10.0.1.8]> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 25 May 2009 16:33:26 +0200 References: <302f570905221154t7feb4162s6728f9dc2c736592@mail.gmail.com> <C63C617C.372F%luby@qualcomm.com> <31d1be720905221451t844a033ufe37b44884b56f83@mail.gmail.com> <302f570905221508q637770ebi89582187526d1594@mail.gmail.com> <p0624080bc63cffcf77fe@[10.0.1.8]> X-Mailer: Apple Mail (2.935.3) Cc: ppsp@ietf.org, avt@ietf.org Subject: Re: [AVT] Comments on draft-pantos-http-live-streaming-00.txt ... X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group <avt.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/avt> List-Post: <mailto:avt@ietf.org> List-Help: <mailto:avt-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 25 May 2009 14:31:52 -0000 Dave, all, DVB has started a similar effort in a study mission and a =20 questionnaire. Contributions of DVB and non DVB members are welcome. http://www.dvb.org/news_events/news/internet-tv-questionnaire/index.xml Best regards Thomas On May 23, 2009, at 3:26 AM, David Singer wrote: > Well, not really comments on the draft; more to thank Mike for =20 > pointing out that there is a 'question' in the industry, and that =20 > perhaps existing techniques ('pure' RTP or MPEG-2 Transport or =20 > existing file download) are not working so well. > > A few people at MPEG have noticed this as well, and are also asking =20= > the question. It's by no means clear what should be done, or where, =20= > or by whom, but they are stepping up to holding an open workshop. I =20= > don't get the sense from the organizers that there is any kind of =20 > 'position' being taken here (yet), not even on whether or where =20 > something should be done, let alone what. > > Have a look at this page and see whether some of you would like to =20 > write something (separately, jointly), or attend: > = <http://multimediacommunication.blogspot.com/2009/04/workshop-on-mmt-moder= n-media-transport.html=20 > > > --=20 > David Singer > Multimedia Standards, Apple Inc. > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt --- Dr. Thomas Stockhammer (CEO) || http://www.nomor.de || phone +49 89 =20 978980 02 || cell +49 172 5702667 Nomor Research GmbH - Sitz der Gesellschaft: M=FCnchen - =20 Registergericht: M=FCnchen, HRB 165856 =96 Umsatzsteuer-ID: DE238047637 = - =20 Gesch=E4ftsf=FChrer: Dr. Thomas Stockhammer, Dr. Ingo Viering. From oran@cisco.com Mon May 25 09:29:53 2009 Return-Path: <oran@cisco.com> X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D11A33A6EC3 for <avt@core3.amsl.com>; Mon, 25 May 2009 09:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGx1l4s4eGkD for <avt@core3.amsl.com>; Mon, 25 May 2009 09:29:51 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 901DB3A6DB9 for <avt@ietf.org>; Mon, 25 May 2009 09:29:51 -0700 (PDT) X-Files: PGP.sig : 195 X-IronPort-AV: E=Sophos;i="4.41,245,1241395200"; d="sig'?scan'208";a="168875649" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 25 May 2009 16:31:32 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n4PGVW3H016931; Mon, 25 May 2009 09:31:32 -0700 Received: from stealth-10-32-245-158.cisco.com (stealth-10-32-245-158.cisco.com [10.32.245.158]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n4PGVHXn011079; Mon, 25 May 2009 16:31:32 GMT Received: from [127.0.0.1] by stealth-10-32-245-158.cisco.com (PGP Universal service); Mon, 25 May 2009 12:31:32 -0400 X-PGP-Universal: processed; by stealth-10-32-245-158.cisco.com on Mon, 25 May 2009 12:31:32 -0400 Message-Id: <EA0C2943-88BE-42B2-A9FF-B09BE843C229@cisco.com> From: David R Oran <oran@cisco.com> To: Roni Even <Even.roni@huawei.com> In-Reply-To: <000301c9dc95$ce1c2a80$6a547f80$%roni@huawei.com> Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 25 May 2009 12:31:11 -0400 References: <81B9B88E2F9D574AA5328A85547CDE9101071D80@xmb-rtp-21d.amer.cisco.com> <49f1a1d6.190c660a.58fe.ffffa90e@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C80DA@xmb-sjc-215.amer.cisco.com> <49f208e8.05a0660a.5bd2.6764@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C81C9@xmb-sjc-215.amer.cisco.com> <49f211fc.07a5660a.3f7f.ffff8f4a@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8202@xmb-sjc-215.amer.cisco.com> <49f2efa2.1c215e0a.4454.ffffaf91@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8403@xmb-sjc-215.amer.cisco.com> <49f36ee2.0437560a.11df.1eef@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8405@xmb-sjc-215.amer.cisco.com> <49f387ca.0305560a.6657.4be7@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C840A@xmb-sjc-215.amer.cisco.com> <4A15D40E.80509@eu.panasonic.com> <04CAD96D4C5A3D48B1919248A8FE0D54095E153A@xmb-sjc-215.amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB011BF41B@lan-ex-02.panasonic.de> <81B9B88E2F9D574AA5328A85547CDE910142F016@ xmb-rtp-.com> <4a193d46.0c11660a.33cc.109d@mx.google.com> <D9D7FD6A-0DFE-4A4E-8215-C8B4F54462C9@cisco.com> <000301c9dc95$ce1c2a80$6a547f80$%roni@huawei.com> X-Mailer: Apple Mail (2.935.3) X-PGP-Encoding-Format: MIME X-PGP-Encoding-Version: 2.0.2 Content-Type: multipart/signed; boundary="PGP_Universal_99B3199C_E1D48CBA_0743BBF1_926669D2"; protocol="application/pgp-signature"; micalg="pgp-sha1" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=25331; t=1243269092; x=1244133092; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:=20David=20R=20Oran=20<oran@cisco.com> |Subject:=20Re=3A=20[AVT]=20New=20draft=20of=20=22Rapid=20A cquisition=20of=20Multicast=09RTPSessions=09(RAMS)=22=20avai lable |Sender:=20; bh=3ViI/8tqQMrFUqaPMgqALiZeJRNh3qCxCM8kJHsA6WY=; b=vB2WlqvDSUI9T5HjX5Pl/Os0FsAFuiWgj3p/kEZCqKf9TOUvrSJAtt2WKm 5xKdeZGjUaOx1ESErZbzL2dQsefylhoskywNHwFD14Otd5EUKMHjPlv0tTDy MhZs01LqTj; Authentication-Results: sj-dkim-2; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: 'Roni Even' <ron.even.tlv@gmail.com>, 'Jose Rey' <Jose.Rey@eu.panasonic.com>, avt@ietf.org, "'Bill Ver Steeg \(versteb\)'" <versteb@cisco.com> Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group <avt.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/avt> List-Post: <mailto:avt@ietf.org> List-Help: <mailto:avt-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 25 May 2009 16:29:53 -0000 --PGP_Universal_99B3199C_E1D48CBA_0743BBF1_926669D2 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable On May 24, 2009, at 1:33 PM, Roni Even wrote: > Dave, > I will start a separate thread on the issue. Just note that port may =20= > not be > enough, an example is if the RR is using a TURN relay Stopping reflection attacks here is more difficult - it requires STUN =20= cookies and the possibility of opening up state-based attacks on the =20 retransmission server. If that's the way the WG wants to go I'm ok =20 with that, but this is one area in which I might go to the IESG and =20 get some sense of whether we would run into a buzz-saw at the end =20 after investing a lot of design and consensus effort. > Roni > > -----Original Message----- > From: David R Oran [mailto:oran@cisco.com] > Sent: Sunday, May 24, 2009 5:00 PM > To: Roni Even > Cc: 'Bill Ver Steeg (versteb)'; 'Roni Even'; 'Ali C. Begen =20 > (abegen)'; 'Jose > Rey'; avt@ietf.org > Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast =20 > RTPSessions > (RAMS)" available > > > On May 24, 2009, at 8:26 AM, Roni Even wrote: > >> Bill, >> My major point here is this is a reason for having an option port or >> transport address parameter in the RAMS-R allowing the RR to provide >> such >> address. > Correct, in principle. I've already commented on the problematic > nature of sending complete transport addresses, so my strong > preference would be only to communicate port numbers (and possibly > SSRCs) > > However it's an interesting design point whether this situation is so > unique to RAMS that we solve it by putting the information in RAMS-R > messages, or whether it justifies a more general-purpose mechanism. > > An alternative design would be to define a separate RTCP packet type > to carry transport port information for "auxiliary" unicast RTP/RTCP > sessions. The situation we face with RAMS does in fact may arise in > other situations, both with and without NAT, where separate signaling > using offer/answer (as SIP would do) is either overkill, too much > overhead, or bad from a latency perspective. Just think unicast > retransmission for SSM by itself, without RAMS. > > In my view, it would be worth having a serious WG discussion of this > general subject before plunging ahead. If the sense is to in fact have > a separate mechanism, I have one sitting in my back pocket (and have > running open source code for). > > DaveO. > >> Roni >> >> -----Original Message----- >> From: Bill Ver Steeg (versteb) [mailto:versteb@cisco.com] >> Sent: Sunday, May 24, 2009 1:02 PM >> To: Roni Even; Ali C. Begen (abegen); Jose Rey >> Cc: Roni Even; avt@ietf.org >> Subject: RE: [AVT] New draft of "Rapid Acquisition of Multicast >> RTPSessions >> (RAMS)" available >> >> Roni- >> Regarding the RS being able to send data to the RR after receiving a >> RAMS-R. >> >> There is a subtle point here, which you reference in your comment >> "need to >> provide a reachable transport address". The RR sends the RAMS-R to =20= >> the >> feedback target UDP port number. In the presence of NAT, the only >> communication path that is opened automatically is that single path. >> In >> order to use the other port-pairs, holes must be poked in the NAT >> and the >> correct NAT-ed ports must be signaled. As you know, there are many >> ways to >> poke wholes in NAT, so we will not go into the details of how to do >> that. >> >> This is an important point, and we will be sure to make it more >> clear in the >> next draft. >> >> Bvs >> >> >> -----Original Message----- >> From: Roni Even [mailto:Even.roni@huawei.com] >> Sent: Saturday, May 23, 2009 8:19 AM >> To: Ali C. Begen (abegen); 'Jose Rey' >> Cc: 'Roni Even'; avt@ietf.org; Bill Ver Steeg (versteb) >> Subject: RE: [AVT] New draft of "Rapid Acquisition of Multicast >> RTPSessions >> (RAMS)" available >> >> Hi, >> I also have concerns about having the unicast Transport addresses >> for the RR >> RTCP and RTP receive port. >> I think that we should first talk about the NAT/FW issue and than >> define the >> requirements and solutions. >> >> My assumption is that the retransmission server has a publicly >> reachable >> address while the receivers may sit behind NATs and will not have a >> publicly >> reachable address. >> Note that the RAMS flow starts from the receiver by RAMS-R so a >> response to >> the transport address from where the RAMS-R came should work (RTCP is >> bi-directional in this case). On the other hand the unicast data >> flow is to >> the receiver so the receiver will need to provide a reachable >> transport >> address. >> >> Roni >> >> -----Original Message----- >> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf >> Of Ali C. >> Begen (abegen) >> Sent: Saturday, May 23, 2009 3:27 AM >> To: Jose Rey >> Cc: Roni Even; avt@ietf.org; Bill Ver Steeg (versteb) >> Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast >> RTPSessions >> (RAMS)" available >> >> Hi Jose, >> >> Indeed, RAMS-R goes to the FT of the new primary session that RR is >> interested in acquiring rapidly. Then the unicast session becomes >> alive and >> RS sends RAMS-I message(s) to RR on the RTCP port for the unicast >> session. >> After some time, RR sends the RAMS-T message to the RTCP port for the >> unicast session since it is supposed to end the unicast session. >> >> -acbegen >> >>> -----Original Message----- >>> From: Jose Rey [mailto:Jose.Rey@eu.panasonic.com] >>> Sent: Friday, May 22, 2009 7:09 AM >>> To: Ali C. Begen (abegen) >>> Cc: Roni Even; avt@ietf.org; Bill Ver Steeg (versteb) >>> Subject: RE: [AVT] New draft of "Rapid Acquisition of Multicast >> RTPSessions (RAMS)" >>> available >>> >>> >>> Hi Ali, >>> >>>> >>>> Hi Jose, >>>> >>>> We have separate RTCP ports for the SSM session and the unicast >>>> session. Why is it a problem? >>> >>> In line 19 you say you specify the dst port for RMS-I (41003), on =20= >>> RR. >>> And >> you say that >>> would also be the port where the RR sends RMS-T, on RS. That is >>> mixing >>> the >> semantics of >>> a=3Drtcp for SSM (listening port at Feedback Target =3D mcast RTCP = dst >>> port) >> and those of RFC >>> 3605 (dst port). In other words, you are implicitly assuming that >> specifies symmetric >>> RTCP...no? >>> >>> Another thing that was mentioned already: RMS-T is not sent to same >>> port >> as RMS-R; is it >>> not the same RTCP session ? Or is this muxing desired? why? >>> >>> JLR >>> >>>> >>>> The slightly modified SDP for the next version is below: >>>> >>> 1> a=3Dgroup:FID 3 4 >>> 2> a=3Drtcp-unicast:rsi >>> 3> m=3Dvideo 41000 RTP/AVPF 98 >>> 4> i=3DPrimary Multicast Stream #2 >>> 5> c=3DIN IP4 233.252.0.2/255 >>> 6> a=3Dsource-filter: incl IN IP4 233.252.0.2 192.0.2.2 >>> 7> a=3Drecvonly >>> 8> a=3Drtpmap:98 MP2T/90000 >>> 9> a=3Drtcp:41001 IN IP4 192.0.2.1 >>> 10> a=3Drtcp-fb:98 nack >>> 11> a=3Drtcp-fb:98 nack ssli >>> 12> a=3Dssrc:123321 cname:iptv-ch32@rams.example.com >>> 13> a=3Dmid:3 >>> 14> m=3Dvideo 41002 RTP/AVPF 99 >>> 15> i=3DUnicast Retransmission Stream #2 (Ret. and Rapid >>>> Acq. Support) >>> 16> c=3DIN IP4 192.0.2.1 >>> 17> a=3Drecvonly >>> 18> a=3Drtpmap:99 rtx/90000 >>> 19> a=3Drtcp:41003 >>> 20> a=3Dfmtp:99 apt=3D98; rtx-time=3D5000 >>> 21> a=3Dmid:4 >>>> >>>> This is the SDP we send to RR. For RS, a=3Drecvonly will be >>>> a=3Dsendonly. >>>> >>>> -acbegen >>>> >>>> >>>>> -----Original Message----- >>>>> From: Jos=E9 Rey [mailto:jose.rey@eu.panasonic.com] >>>>> Sent: Thursday, May 21, 2009 3:22 PM >>>>> To: Ali C. Begen (abegen) >>>>> Cc: Roni Even; avt@ietf.org; Bill Ver Steeg (versteb) >>>>> Subject: Re: [AVT] New draft of "Rapid Acquisition of >>>> Multicast RTPSessions (RAMS)" >>>>> available >>>>> >>>>> Hi all, >>>>> >>>>> sorry for jumping in.... >>>>> >>>>> I think one of the sources of confusion is that the >>>> attribute a=3Drtcp: >>>>> is used once for specifying the destination port and once for >>>>> specifying a receiving port, and in the same SDP (!). The >>>> destination >>>>> port for RAMS-I packets sent by RS and the receiving port >>>> for RAMS-T. Which is also why different port numbers are used for >>>> RAMS-T and -R packets. >>>>> >>>>> I think the use of a=3Drtcp: in SSM is the problem here. Or the = fact >>>>> that we are mixing unicast and multicast, or both. >>>>> >>>>> Hope this helps, >>>>> >>>>> JLR >>>>> >>>>> >>>>> >>>>> >>>>> Ali C. Begen (abegen) wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Roni Even [mailto:ron.even.tlv@gmail.com] >>>>> Sent: Saturday, April 25, 2009 2:58 PM >>>>> To: Ali C. Begen (abegen); avt@ietf.org >>>>> Cc: Bill Ver Steeg (versteb) >>>>> Subject: RE: [AVT] New draft of "Rapid Acquisition of >>>>> Multicast RTPSessions (RAMS)" available >>>>> >>>>> Ali, >>>>> I looked at RFC 4570 and I assume that port >>>> 41001 is the port for the >>>>> unicast RTCP reports from the receivers and according to >>>>> >>>>> >>>>> >>>>> Yes, indeed. >>>>> >>>>> >>>>> >>>>> section 3.2.1 of >>>>> that RFC you also should have a RTCP-unicast >>>> specification. >>>>> This is for the >>>>> multicast receiver reports. >>>>> >>>>> >>>>> >>>>> Correct. We do have that line in our draft at the top >>>> right after the grouping lines: >>>>> >>>>> a=3Drtcp-unicast:rsi >>>>> >>>>> BR, >>>>> -acbegen >>>>> >>>>> >>>>> >>>>> Roni >>>>> >>>>> -----Original Message----- >>>>> From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] >>>>> Sent: Saturday, April 25, 2009 11:30 PM >>>>> To: Roni Even; avt@ietf.org >>>>> Cc: Bill Ver Steeg (versteb) >>>>> Subject: RE: [AVT] New draft of "Rapid Acquisition of >>>>> Multicast RTPSessions >>>>> (RAMS)" available >>>>> >>>>> Here is the SDP. >>>>> >>>>> m=3Dvideo 41000 RTP/AVPF 98 >>>>> i=3DPrimary Multicast Stream #2 >>>>> c=3DIN IP4 224.1.1.2/255 >>>>> a=3Dsource-filter: incl IN IP4 224.1.1.2 = 192.0.2.2 >>>>> >>>>> Source (192.0.2.2) sends the rtp packets to the >>>> multicast >>>>> group (224.1.1.2) >>>>> with a dest port 41000. >>>>> >>>>> a=3Drtpmap:98 MP2T/90000 >>>>> a=3Drtcp:41001 IN IP4 192.0.2.1 >>>>> >>>>> The feedback target (RS) address for this SSM session is >>>>> 192.0.2.1 and its >>>>> port is 41001. This is the address/port where >>>> RR sends the RAMS-R, or >>>>> receiver reports for the SSM session. >>>>> >>>>> a=3Drtcp-fb:98 nack >>>>> a=3Drtcp-fb:98 nack ssli >>>>> a=3Dssrc:123321 cname:iptv-ch32@rams.example.com >>>>> a=3Dmid:3 >>>>> m=3Dvideo 41002 RTP/AVPF 99 >>>>> >>>>> The retransmission packets go to port 41002. >>>> This is the port >>>>> RRs listen to >>>>> for retransmission and RAMS. >>>>> >>>>> i=3DUnicast Retransmission Stream #2 >>>> (Ret. and Rapid >>>>> Acq. Support) >>>>> c=3DIN IP4 192.0.2.1 >>>>> >>>>> This is where the retransmission packets come >>>> from, same as >>>>> the feedback >>>>> target (in this example). >>>>> >>>>> a=3Drtpmap:99 rtx/90000 >>>>> a=3Drtcp:41003 >>>>> >>>>> This is where the RTCP packets for the >>>> retransmission session go. For >>>>> example, RAMS-I goes to this port on RRs. >>>> RAMS-T goes to this >>>>> port on RS. >>>>> >>>>> a=3Dfmtp:99 apt=3D98; rtx-time=3D5000 >>>>> a=3Dmid:4 >>>>> >>>>> >>>>> -acbegen >>>>> >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Roni Even [mailto:ron.even.tlv@gmail.com] >>>>> Sent: Saturday, April 25, 2009 1:11 PM >>>>> To: Ali C. Begen (abegen); avt@ietf.org >>>>> Cc: Bill Ver Steeg (versteb) >>>>> Subject: RE: [AVT] New draft of "Rapid >>>> Acquisition of >>>>> Multicast RTPSessions (RAMS)" available >>>>> >>>>> Ali, >>>>> Can you please write three addresses >>>> from this strange SDP. >>>>> >>>>> 1. The address and port of multicast >>>>> >>>>> 2. The address and port of the RS where >>>> the RTCP FB should go to >>>>> >>>>> 3. The address and port on the RR where >>>> the unicast stream >>>>> should be sent to >>>>> >>>>> Roni >>>>> >>>>> -----Original Message----- >>>>> From: Ali C. Begen (abegen) >>>> [mailto:abegen@cisco.com] >>>>> Sent: Saturday, April 25, 2009 11:02 PM >>>>> To: Roni Even; avt@ietf.org >>>>> Cc: Bill Ver Steeg (versteb) >>>>> Subject: RE: [AVT] New draft of "Rapid >>>> Acquisition of >>>>> Multicast RTPSessions >>>>> (RAMS)" available >>>>> >>>>> >>>>> >>>>> Ali, >>>>> The example SDP is >>>> syntactically correct but it does not >>>>> >>>>> >>>>> say that the >>>>> >>>>> >>>>> rtp/rtcp mux will be used and >>>> it does not give the >>>>> information to where the >>>>> unicast stream will be sent >>>> when the RR sends a RAMS-R. >>>>> >>>>> >>>>> To my knowledge, the first line in the >>>> following SDP tells >>>>> the RRs on which >>>>> port they will receive the >>>> retransmission/burst packets. >>>>> >>>>> m=3Dvideo 41002 RTP/AVPF 99 >>>>> i=3DUnicast Retransmission Stream >>>> #2 (Ret. and Rapid >>>>> Acq. Support) >>>>> c=3DIN IP4 192.0.2.1 >>>>> a=3Drtpmap:99 rtx/90000 >>>>> a=3Drtcp:41003 >>>>> a=3Dfmtp:99 apt=3D98; rtx-time=3D5000 >>>>> a=3Dmid:4 >>>>> >>>>> There is a typo, you are right. That >>>> "a=3Drecvonly" line should >>>>> only exist in >>>>> the SDP sent to RRs. In the SDP sent to >>>> RS, we should rather have >>>>> "a=3Dsendonly". I will make this >>>> correction in the next version. >>>>> >>>>> The feedback target for the SSM session >>>> and the RTCP port for the >>>>> retransmission session are also defined >>>> in the SDP. >>>>> >>>>> Hope this clarifies. >>>>> >>>>> BR, >>>>> -acbegen >>>>> >>>>> >>>>> >>>>> I am not sure why the unicast >>>> stream m-line has a port >>>>> >>>>> >>>>> number with an >>>>> >>>>> >>>>> attribute of recvonly. What is >>>> the use case for that. The >>>>> only information >>>>> that the RR will need is the >>>> RTCP port on the RS to where to >>>>> send the RAMS-R >>>>> message. >>>>> Roni >>>>> -----Original Message----- >>>>> From: Ali C. Begen (abegen) >>>> [mailto:abegen@cisco.com] >>>>> Sent: Friday, April 24, 2009 10:37 PM >>>>> To: Roni Even; avt@ietf.org >>>>> Cc: Bill Ver Steeg (versteb) >>>>> Subject: RE: [AVT] New draft of >>>> "Rapid Acquisition of >>>>> Multicast RTPSessions >>>>> (RAMS)" available >>>>> >>>>> This is a part of an example >>>> SDP sent to RS and RR in a SAP >>>>> announcement, >>>>> for example. So, the SDP >>>> describes what both parties should >>>>> do (RR cannot >>>>> say that he wants to receive >>>> this multicast on its favorite >>>>> >>>>> >>>>> port). The >>>>> >>>>> >>>>> individual SDPs sent to RR or >>>> RS may include other portions >>>>> of descriptions >>>>> that will contain specific information. >>>>> >>>>> -acbegen >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Roni Even >>>> [mailto:ron.even.tlv@gmail.com] >>>>> Sent: Friday, April 24, >>>> 2009 12:23 PM >>>>> To: Ali C. Begen >>>> (abegen); avt@ietf.org >>>>> Cc: Bill Ver Steeg (versteb) >>>>> Subject: RE: [AVT] New >>>> draft of "Rapid Acquisition of >>>>> Multicast RTPSessions >>>> (RAMS)" available >>>>> >>>>> Ali, >>>>> I think you get it >>>> wrong, this SDP is from the RS and not the >>>>> RR so the RS >>>>> cannot specify to which >>>> address it will send it can only >>>>> specify to which >>>>> address it can receive >>>> RTP stream. In this SDP the relevant >>>>> information is >>>>> that the request for >>>> retransmission will be sent by the RR to >>>>> port 41003 >>>>> Roni >>>>> >>>>> -----Original Message----- >>>>> From: Ali C. Begen >>>> (abegen) [mailto:abegen@cisco.com] >>>>> Sent: Friday, April 24, >>>> 2009 10:01 PM >>>>> To: Roni Even; avt@ietf.org >>>>> Cc: Bill Ver Steeg (versteb) >>>>> Subject: RE: [AVT] New >>>> draft of "Rapid Acquisition of >>>>> Multicast RTPSessions >>>>> (RAMS)" available >>>>> >>>>> Oh, I see. The burst >>>> goes to the port that we would >>>>> >>>>> >>>>> normally send the >>>>> >>>>> >>>>> retransmissions. For >>>> example, consider the SDP from the draft: >>>>> >>>>> m=3Dvideo 41000 >>>> RTP/AVPF 98 >>>>> i=3DPrimary >>>> Multicast Stream #2 >>>>> c=3DIN IP4 224.1.1.2/255 >>>>> >>>> a=3Dsource-filter: incl IN IP4 224.1.1.2 192.0.2.2 >>>>> a=3Drtpmap:98 MP2T/90000 >>>>> a=3Drtcp:41001 IN >>>> IP4 192.0.2.1 >>>>> a=3Drtcp-fb:98 nack >>>>> a=3Drtcp-fb:98 nack ssli >>>>> a=3Dssrc:123321 >>>> cname:iptv-ch32@rams.example.com >>>>> a=3Dmid:3 >>>>> m=3Dvideo 41002 >>>> RTP/AVPF 99 >>>>> i=3DUnicast >>>> Retransmission Stream #2 (Ret. and Rapid >>>>> Acq. Support) >>>>> c=3DIN IP4 192.0.2.1 >>>>> a=3Drecvonly >>>>> a=3Drtpmap:99 rtx/90000 >>>>> a=3Drtcp:41003 >>>>> a=3Dfmtp:99 >>>> apt=3D98; rtx-time=3D5000 >>>>> a=3Dmid:4 >>>>> >>>>> In this case, the burst >>>> will go to port 41002 on the RR. >>>>> >>>>> >>>>> The RAMS-I >>>>> >>>>> >>>>> message(s), which is an >>>> RTCP feedback message, will go to >>>>> >>>>> >>>>> port 41003. >>>>> >>>>> >>>>> HTH, >>>>> -acbegen >>>>> >>>>> >>>>> >>>>> -----Original >>>> Message----- >>>>> From: Roni Even >>>> [mailto:ron.even.tlv@gmail.com] >>>>> Sent: Friday, >>>> April 24, 2009 11:44 AM >>>>> To: Ali C. >>>> Begen (abegen); avt@ietf.org >>>>> Cc: Bill Ver >>>> Steeg (versteb) >>>>> Subject: RE: >>>> [AVT] New draft of "Rapid Acquisition of >>>>> Multicast >>>> RTPSessions (RAMS)" available >>>>> >>>>> Ali, >>>>> I will try to >>>> explain in simple way >>>>> >>>>> When the RS >>>> receives the RAMS-R it need to start sending an >>>>> RTP stream to >>>>> the RR. >>>>> In order to >>>> send a unicast packet, the RS needs to know a >>>>> transport address >>>>> on the RR to >>>> where the RTP stream will be sent. The current >>>>> draft does not >>>>> say how the RS >>>> knows this address. There is no SDP from RR to >>>>> RS like you >>>>> mention in your >>>> response. >>>>> This is why I >>>> say that the current draft does not specify a >>>>> solution that >>>>> can be >>>> implemented as a working solution >>>>> Roni >>>>> >>>>> -----Original >>>> Message----- >>>>> From: Ali C. >>>> Begen (abegen) [mailto:abegen@cisco.com] >>>>> Sent: Friday, >>>> April 24, 2009 7:38 PM >>>>> To: Roni Even; >>>> avt@ietf.org >>>>> Cc: Bill Ver >>>> Steeg (versteb) >>>>> Subject: RE: >>>> [AVT] New draft of "Rapid Acquisition of >>>>> Multicast RTPSessions >>>>> (RAMS)" available >>>>> >>>>> Hi Roni, >>>>> >>>>> >>>>> >>>>> >>>> -----Original Message----- >>>>> From: >>>> avt-bounces@ietf.org [mailto:avt- bounces@ietf.org] On >>>>> Behalf >>>> Of Roni Even >>>>> Sent: >>>> Friday, April 24, 2009 4:24 AM >>>>> To: avt@ietf.org >>>>> Cc: >>>> Bill Ver Steeg (versteb) >>>>> >>>> Subject: Re: [AVT] New draft of "Rapid Acquisition of >>>>> >>>> Multicast RTPSessions (RAMS)" available >>>>> >>>>> Hi, >>>>> >>>>> I think >>>> that the current draft does not give a >>>>> >>>>> >>>>> description of >>>>> >>>>> >>>>> a >>>> system that works since there is no text >>>>> >>>>> >>>>> explaining how the >>>>> >>>>> >>>>> What do you >>>> mean by "a system that works"? >>>>> >>>>> >>>>> >>>>> RS >>>> knows the unicast transport address on the RR to >>>>> >>>>> >>>>> where to >>>>> >>>>> >>>>> send the stream. >>>>> >>>>> >>>>> Once RS >>>> receives the request packet from an RR, RS knows its >>>>> address. Ports >>>>> are defined in >>>> the SDP. If you are asking about "NAT" >>>>> issues, >>>>> we have a >>>>> section for it, >>>> and we plan to complete it as we move >>>>> forward. It is not as >>>>> critical as the >>>> other parts for now. >>>>> >>>>> >>>>> >>>>> If you >>>> mandate the use of RTP/RTCP mux it should say so >>>>> >>>> otherwise the RAMS-R should have an optional parameter that >>>>> >>>> supplies this information and a flag for using RTP/RTCP mux. >>>>> >>>>> >>>>> IMO, we cannot >>>> mandate muxing as it is not required to make >>>>> RAMS work. If >>>>> muxing is >>>> supported, the SDP should reflect it. >>>>> >>>>> BR, >>>>> -acbegen >>>>> >>>>> >>>>> >>>>> Thanks >>>>> >>>>> Roni Even >>>>> >>>>> >>>>> >>>>> From: >>>> avt-bounces@ietf.org [mailto:avt- bounces@ietf.org] On >>>>> Behalf >>>> Of Bill Ver Steeg (versteb) >>>>> Sent: >>>> Thursday, April 16, 2009 7:39 PM >>>>> To: avt@ietf.org >>>>> >>>> Subject: [AVT] New draft of "Rapid Acquisition of Multicast >>>>> RTP >>>> Sessions (RAMS)" available >>>>> >>>>> >>>>> >>>>> There >>>> is a new draft of the "Rapid Acquisition of Multicast >>>>> RTP >>>> Sessions (RAMS)" draft available at >>>>> >>>>> >>>>> >>>>> >>>> http://www.ietf.org/internet-drafts/draft-versteeg-avt-rapid-s >>>>> >>>>> >>>>> >>>> ynchronization-for-rtp-03.txt >>>>> <http://www.ietf.org/internet-> <http://www.ietf.org/internet-> >>>>> >>>>> >>>>> >>>>> >>>> drafts/draft-versteeg-avt-rapid-synchronization-for-rtp-03.txt> >>>>> >>>>> >>>>> >>>>> >>>>> We have >>>> incorporated the changes from the technical >>>>> >>>>> >>>>> breakout >>>>> >>>>> >>>>> session >>>> in San Francisco. The major changes in this version >>>>> of the >>>> draft include >>>>> >>>>> 1- >>>> Changing the document title to avoid confusion >>>>> >>>>> >>>>> with other >>>>> >>>>> >>>>> ongoing >>>> "synchronization" drafts >>>>> >>>>> 2- >>>> changing the message names to reflect the title change >>>>> >>>>> 3- >>>> clarification of the RTCP message semantics, including >>>>> changes >>>> to the "Request" and "Inform" messages >>>>> >>>>> 4- >>>> additional description/motivation for the >>>>> >>>>> >>>>> various message >>>>> >>>>> >>>>> flows >>>> has been added >>>>> >>>>> 5- >>>> RTP/RTCP muxing has been added >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> We hope >>>> to make this a Working Group item, and will change >>>>> the >>>> name of the draft to avoid conflicts with other >>>>> >>>> "synchronization" drafts at that time. >>>>> >>>>> >>>>> >>>>> Bill VerSteeg >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Audio/Video Transport Working Group >>>>> avt@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/avt >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> Panasonic R&D Center Germany GmbH >>> 63225 Langen, Hessen, Germany >>> Reg: AG Offenbach (Hessen) HRB 33974 >>> Managing Director: Thomas Micke >>> >> >> _______________________________________________ >> Audio/Video Transport Working Group >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt >> >> _______________________________________________ >> Audio/Video Transport Working Group >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt > --PGP_Universal_99B3199C_E1D48CBA_0743BBF1_926669D2 Content-Type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig Content-Disposition: attachment; filename=PGP.sig -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.10.0 (Build 500) iQA/AwUBShrH3I1mhLZU3SrmEQJOAACdHrEfM4NgeugGGJjjc87nh2iDjnQAoKGx 8I/TOXPf2q+NOr9xx/qJz/F8 =yrYH -----END PGP SIGNATURE----- --PGP_Universal_99B3199C_E1D48CBA_0743BBF1_926669D2-- From gherlein@herlein.com Mon May 25 10:13:57 2009 Return-Path: <gherlein@herlein.com> X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4C793A6832; Mon, 25 May 2009 10:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.346 X-Spam-Level: X-Spam-Status: No, score=-0.346 tagged_above=-999 required=5 tests=[AWL=-0.784, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UeaswMRXk-r7; Mon, 25 May 2009 10:13:50 -0700 (PDT) Received: from mail-pz0-f180.google.com (mail-pz0-f180.google.com [209.85.222.180]) by core3.amsl.com (Postfix) with ESMTP id 9F4053A6A57; Mon, 25 May 2009 10:13:50 -0700 (PDT) Received: by pzk10 with SMTP id 10so2159155pzk.29 for <multiple recipients>; Mon, 25 May 2009 10:15:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.177.5 with SMTP id z5mr2335491wfe.32.1243271729691; Mon, 25 May 2009 10:15:29 -0700 (PDT) In-Reply-To: <5AB53BB4-72A7-46E3-9A3E-E53E246D6A14@nomor.de> References: <302f570905221154t7feb4162s6728f9dc2c736592@mail.gmail.com> <C63C617C.372F%luby@qualcomm.com> <31d1be720905221451t844a033ufe37b44884b56f83@mail.gmail.com> <302f570905221508q637770ebi89582187526d1594@mail.gmail.com> <p0624080bc63cffcf77fe@10.0.1.8> <5AB53BB4-72A7-46E3-9A3E-E53E246D6A14@nomor.de> Date: Mon, 25 May 2009 10:15:29 -0700 Message-ID: <31d1be720905251015r293c20e4x57038f4e2797b497@mail.gmail.com> From: Greg Herlein <gherlein@herlein.com> To: Thomas Stockhammer <stockhammer@nomor.de> Content-Type: multipart/alternative; boundary=000e0cd14eeecebe60046abfc1a5 Cc: ppsp@ietf.org, David Singer <singer@apple.com>, avt@ietf.org Subject: Re: [AVT] [ppsp] Comments on draft-pantos-http-live-streaming-00.txt ... X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group <avt.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/avt> List-Post: <mailto:avt@ietf.org> List-Help: <mailto:avt-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 25 May 2009 17:13:58 -0000 --000e0cd14eeecebe60046abfc1a5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit In a shameless plug for us all, I blogged about this subject, for what it's worth. http://www.herlein.com/index.php?entry=entry090525-092231 -- Greg Herlein www.herlein.com --000e0cd14eeecebe60046abfc1a5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit In a shameless plug for us all, I blogged about this subject, for what it's worth.<br><br><a href="http://www.herlein.com/index.php?entry=entry090525-092231">http://www.herlein.com/index.php?entry=entry090525-092231</a><br> <br><br>-- <br>Greg Herlein<br><a href="http://www.herlein.com">www.herlein.com</a><br> --000e0cd14eeecebe60046abfc1a5-- From marshall.eubanks@gmail.com Mon May 25 12:24:15 2009 Return-Path: <marshall.eubanks@gmail.com> X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50A473A6E97 for <avt@core3.amsl.com>; Mon, 25 May 2009 12:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JYT1uK0O1mG7 for <avt@core3.amsl.com>; Mon, 25 May 2009 12:24:14 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by core3.amsl.com (Postfix) with ESMTP id B22AD3A6B3A for <avt@ietf.org>; Mon, 25 May 2009 12:24:13 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 13so955427fge.18 for <avt@ietf.org>; Mon, 25 May 2009 12:25:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=jIzdH+nhlAXH+INQx1/4vPoHOVWGmSOigXU5yP5MBYk=; b=Aad30lhWzucuyddtpuc2m/+DcKHH87Zc4ZJftB2Lvy/p45HjQa5epeKD4v7z5RssX6 y07VG0vwN9BpAtkKjyo3P3wTnr+C4QDtZ847t9XFhMxw8R1PvrveT1kKmSPbh/rAntbz ew3TytklMTPUNHH34q9C6cA6LAsC1hX1fIEaA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=QH35aSzhirAnnw/GemNfKROJRq4ZL9dsZxeEmq6625gG/ueYpdZ6nTbSlo4QvExVS7 OHJYZfd7YDbJIR4QBe3+HVs5BmD5SHsyGp4MsFanvV1RhsHSvYTX6EJSygHlMwI/e2M+ 1FWMNLagE4Nrob3bYpXRFbW6/2rfGuS/uqsTw= MIME-Version: 1.0 Received: by 10.239.167.212 with SMTP id h20mr489174hbe.68.1243279551732; Mon, 25 May 2009 12:25:51 -0700 (PDT) In-Reply-To: <001701c9dca0$bd465130$37d2f390$%roni@huawei.com> References: <001701c9dca0$bd465130$37d2f390$%roni@huawei.com> Date: Mon, 25 May 2009 15:25:51 -0400 Message-ID: <dcad22d80905251225h64bd303cx9de2c1698b8eaa7d@mail.gmail.com> From: Marshall Eubanks <marshall.eubanks@gmail.com> To: Roni Even <Even.roni@huawei.com> Content-Type: multipart/alternative; boundary=001485f63160099b95046ac19462 Cc: "Dave Oran \(oran\)" <oran@cisco.com>, avt@ietf.org Subject: Re: [AVT] RTP unicast address for retransmssion of multicast sesssion or using RTCP to negotitaion of RTP adddresses X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group <avt.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/avt> List-Post: <mailto:avt@ietf.org> List-Help: <mailto:avt-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 25 May 2009 19:24:15 -0000 --001485f63160099b95046ac19462 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Sun, May 24, 2009 at 2:51 PM, Roni Even <Even.roni@huawei.com> wrote: > Hi, > > > > > > One of the issues discussed in Rapid Acquisition of Multicast RTPSessions > (RAMS) has to do with the specific architecture where the media is sent to > an announced multicast address where there is no offer answer negotiation > between the sender and the receivers. In the proposed solution receivers > may ask using RTCP for unicast retransmission of the RTP stream. The current > draft has as part of the announcement a port number that the receiver should > use to receive the unicast RTP stream. This port is specified by the > retransmission server and not by the receiver and it assumes that the IP > address will be the same as the one from where the RTCP message came from. > > > > The problem we encounter is that this retransmission stream is flowing from > the retransmission server to the receiver who may be behind a FW/NAT. The > simple case is if the RTP and RTCP streams are multiplexed on the RTCP port > since in this case there is an RTCP message going from the receiver to the > retransmission server which will open a pin hole in the NAT/FW enabling RTP > to flow back to the receiver (Will need some keep alive mechanism) > > The case we are trying to discuss here is when we want to have a separate > RTP channel (not multiplexed with RTCP). In this case we will need some > mechanism to convey an address from the receiver to the retransmission > server. > > > > We would like to ask if this should be part of RAMS or do we want a general > RTCP message to covey such information. > I would say that this should be a general RTCP message. This is a general technique now for getting through firewalls (rfc 5138). H.460 /18 and /19 use it, ICE uses it, it should be made general for RTP. Regards Marshall > We would like to get some other scenarios not for RAMS that have similar > requirements. > > > > Looking at previous work > > > > RFC 4588 when discussing retransmission for multicast channel is using a > multicast group for the retransmission for small groups. It does not address > the above problem. For the unicast case it is suing offer answer to > negotiate addresses. The discussion in RFC 4588 as well as RFC 2887 do not > address the same application requirement where each user that joins the > multicast group wants to get a unicast stream with synchronization > information and not a regular retransmission due to information loss. > > > > http://tools.ietf.org/html/draft-ietf-avt-rtcpssm-18 does not address > retransmission but has as part of the RSI message from the distribution > source a way to suggest a different feedback target transport address that > overrides the one announced in the SDP. > > > > In RTSP the setup request from the receiver carries the transport > initialization information enabling the receiver to specify a transport > address for the stream. > > > > Thanks > > Roni Even > > > > > > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > > --001485f63160099b95046ac19462 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <br><br><div class=3D"gmail_quote">On Sun, May 24, 2009 at 2:51 PM, Roni Ev= en <span dir=3D"ltr"><<a href=3D"mailto:Even.roni@huawei.com">Even.roni@= huawei.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div> <p>Hi,</p> <p>=A0</p> <p>=A0</p> <p>One of the issues discussed in Rapid Acquisition of Multicast RTPSessions (RAMS) has to do with the specific architecture where= the media is sent to an announced multicast=A0 address where there is no offer = answer negotiation between the sender and the receivers. =A0In the proposed solution =A0receivers may ask using RTCP for unicast retransmission of the RTP stream. The current draft has as part of the announcement a port number that the receiver should use to receive the unicast RTP stream. =A0This por= t is specified by the retransmission server and not by the receiver and it as= sumes that the IP address will be the same as the one from where the RTCP message came from.</p> <p>=A0</p> <p>The problem we encounter is that this retransmission stream is flowing from the retransmission server to the receiver who may be behind= a FW/NAT. The simple case is if the RTP and RTCP streams are multiplexed on t= he RTCP port since in this case there is an RTCP message going from the receiver to= the retransmission server which will open a pin hole in the NAT/FW enabling RTP= to flow back to the receiver (Will need some keep alive mechanism)</p> <p>The case we are trying to discuss here is when we want to have a separate RTP channel (not multiplexed with RTCP). In this case we wi= ll need some mechanism to convey an address from the receiver to the retransmi= ssion server. </p> <p>=A0</p> <p>We would like to ask if this should be part of RAMS or do we want a general RTCP message to covey such information.</p></div></div></blo= ckquote><div><br></div><div>I would say that this should be a general RTCP = message. This is a general technique now for getting through firewalls (rfc= 5138). H.460 /18 and /19 use it, ICE=A0uses it, it should be made general = for RTP.</div> <div><br></div><div>Regards</div><div>Marshall</div><div>=A0</div><blockquo= te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so= lid;padding-left:1ex;"><div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><= div><p></p> <p>We would like to get some other scenarios not for RAMS that have similar requirements.</p> <p>=A0</p> <p>Looking at previous work</p> <p>=A0</p> <p>RFC 4588 when discussing retransmission for multicast channel is using a multicast group for the retransmission for small groups.= It does not address the above problem. For the unicast case it is suing offer answer to negotiate addresses. The discussion in RFC 4588 as well as RFC 28= 87 do not address the same application requirement where each user that joins = the multicast group wants to get a unicast stream with synchronization informat= ion and not a regular retransmission due to information loss.</p> <p>=A0</p> <p><a href=3D"http://tools.ietf.org/html/draft-ietf-avt-rtcpssm-18" target= =3D"_blank">http://tools.ietf.org/html/draft-ietf-avt-rtcpssm-18</a> does not address retransmission but has as part of the RSI message from the distribution source a way to suggest a different feedback target transport = address that overrides the one announced in the SDP.</p> <p>=A0</p> <p>In RTSP the setup request from the receiver carries the transport initialization information enabling the receiver to specify a transport add= ress for the stream.</p> <p>=A0</p> <p>Thanks</p> <p>Roni Even </p> <p>=A0</p> <p>=A0</p> <p>=A0</p> </div> </div> <br>_______________________________________________<br> Audio/Video Transport Working Group<br> <a href=3D"mailto:avt@ietf.org">avt@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/avt" target=3D"_blank">htt= ps://www.ietf.org/mailman/listinfo/avt</a><br> <br></blockquote></div><br> --001485f63160099b95046ac19462-- From Even.roni@huawei.com Mon May 25 12:37:52 2009 Return-Path: <Even.roni@huawei.com> X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2EDF3A6856 for <avt@core3.amsl.com>; Mon, 25 May 2009 12:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.305 X-Spam-Level: * X-Spam-Status: No, score=1.305 tagged_above=-999 required=5 tests=[AWL=0.904, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94v9cZNFQZcA for <avt@core3.amsl.com>; Mon, 25 May 2009 12:37:50 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 331B03A67B1 for <avt@ietf.org>; Mon, 25 May 2009 12:37:50 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KK7007V7T9TZR@szxga03-in.huawei.com> for avt@ietf.org; Tue, 26 May 2009 03:39:29 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KK7007GGT9TNJ@szxga03-in.huawei.com> for avt@ietf.org; Tue, 26 May 2009 03:39:29 +0800 (CST) Received: from windows8d787f9 (bzq-79-182-101-49.red.bezeqint.net [79.182.101.49]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KK700MYBT9AHN@szxml02-in.huawei.com>; Tue, 26 May 2009 03:39:29 +0800 (CST) Date: Mon, 25 May 2009 22:38:24 +0300 From: Roni Even <Even.roni@huawei.com> In-reply-to: <EA0C2943-88BE-42B2-A9FF-B09BE843C229@cisco.com> To: 'David R Oran' <oran@cisco.com> Message-id: <00bd01c9dd70$68b4e110$3a1ea330$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=ISO-8859-1 Content-language: en-us Content-transfer-encoding: quoted-printable Thread-index: AcndVlDXDZoUVudhTUayhNdzpfbcUwAGb/6Q iPlanet-SMTP-Warning: Lines longer than SMTP allows found and truncated. References: <81B9B88E2F9D574AA5328A85547CDE9101071D80@xmb-rtp-21d.amer.cisco.com> <49f1a1d6.190c660a.58fe.ffffa90e@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C80DA@xmb-sjc-215.amer.cisco.com> <49f208e8.05a0660a.5bd2.6764@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C81C9@xmb-sjc-215.amer.cisco.com> <49f211fc.07a5660a.3f7f.ffff8f4a@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8202@xmb-sjc-215.amer.cisco.com> <49f2efa2.1c215e0a.4454.ffffaf91@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8403@xmb-sjc-215.amer.cisco.com> <49f36ee2.0437560a.11df.1eef@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8405@xmb-sjc-215.amer.cisco.com> <49f387ca.0305560a.6657.4be7@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C840A@xmb-sjc-215.amer.cisco.com> <4A15D40E.80509@eu.panasonic.com> <04CAD96D4C5A3D48B1919248A8FE0D54095E153A@xmb-sjc-215.amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB011BF41B@lan-ex-02.panasonic.de> <4a193d46.0c11660a.33cc.109d@mx.google.com> <"D9D7F 8215-C8B4F54462C9"@cisco.com> <000301c9dc95$ce1c2a80$6a547f80$%roni@huawei.com> <EA0C2943-88BE-42B2-A9FF-B09BE843C229@cisco.com> Cc: 'Roni Even' <ron.even.tlv@gmail.com>, 'Jose Rey' <Jose.Rey@eu.panasonic.com>, avt@ietf.org, "'Bill Ver Steeg \(versteb\)'" <versteb@cisco.com> Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group <avt.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/avt> List-Post: <mailto:avt@ietf.org> List-Help: <mailto:avt-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 25 May 2009 19:37:52 -0000 Dave, What I am trying to understand is what are the assumptions in this = solution. I will not object to any assumption as long as it is stated.=20 Roni Even As individual -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = David R Oran Sent: Monday, May 25, 2009 7:31 PM To: Roni Even Cc: 'Roni Even'; 'Jose Rey'; avt@ietf.org; 'Bill Ver Steeg (versteb)' Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast = RTPSessions (RAMS)" available On May 24, 2009, at 1:33 PM, Roni Even wrote: > Dave, > I will start a separate thread on the issue. Just note that port may=20 > not be enough, an example is if the RR is using a TURN relay Stopping reflection attacks here is more difficult - it requires STUN cookies and the possibility of opening up state-based attacks on the retransmission server. If that's the way the WG wants to go I'm ok with that, but this is one area in which I might go to the IESG and get some sense of whether we would run into a buzz-saw at the end after investing = a lot of design and consensus effort. > Roni > > -----Original Message----- > From: David R Oran [mailto:oran@cisco.com] > Sent: Sunday, May 24, 2009 5:00 PM > To: Roni Even > Cc: 'Bill Ver Steeg (versteb)'; 'Roni Even'; 'Ali C. Begen (abegen)';=20 > 'Jose Rey'; avt@ietf.org > Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast=20 > RTPSessions (RAMS)" available > > > On May 24, 2009, at 8:26 AM, Roni Even wrote: > >> Bill, >> My major point here is this is a reason for having an option port or=20 >> transport address parameter in the RAMS-R allowing the RR to provide=20 >> such address. > Correct, in principle. I've already commented on the problematic=20 > nature of sending complete transport addresses, so my strong=20 > preference would be only to communicate port numbers (and possibly > SSRCs) > > However it's an interesting design point whether this situation is so=20 > unique to RAMS that we solve it by putting the information in RAMS-R=20 > messages, or whether it justifies a more general-purpose mechanism. > > An alternative design would be to define a separate RTCP packet type=20 > to carry transport port information for "auxiliary" unicast RTP/RTCP=20 > sessions. The situation we face with RAMS does in fact may arise in=20 > other situations, both with and without NAT, where separate signaling=20 > using offer/answer (as SIP would do) is either overkill, too much=20 > overhead, or bad from a latency perspective. Just think unicast=20 > retransmission for SSM by itself, without RAMS. > > In my view, it would be worth having a serious WG discussion of this=20 > general subject before plunging ahead. If the sense is to in fact have = > a separate mechanism, I have one sitting in my back pocket (and have=20 > running open source code for). > > DaveO. > >> Roni >> >> -----Original Message----- >> From: Bill Ver Steeg (versteb) [mailto:versteb@cisco.com] >> Sent: Sunday, May 24, 2009 1:02 PM >> To: Roni Even; Ali C. Begen (abegen); Jose Rey >> Cc: Roni Even; avt@ietf.org >> Subject: RE: [AVT] New draft of "Rapid Acquisition of Multicast=20 >> RTPSessions (RAMS)" available >> >> Roni- >> Regarding the RS being able to send data to the RR after receiving a=20 >> RAMS-R. >> >> There is a subtle point here, which you reference in your comment=20 >> "need to provide a reachable transport address". The RR sends the=20 >> RAMS-R to the feedback target UDP port number. In the presence of=20 >> NAT, the only communication path that is opened automatically is that = >> single path. >> In >> order to use the other port-pairs, holes must be poked in the NAT and = >> the correct NAT-ed ports must be signaled. As you know, there are=20 >> many ways to poke wholes in NAT, so we will not go into the details=20 >> of how to do that. >> >> This is an important point, and we will be sure to make it more clear = >> in the next draft. >> >> Bvs >> >> >> -----Original Message----- >> From: Roni Even [mailto:Even.roni@huawei.com] >> Sent: Saturday, May 23, 2009 8:19 AM >> To: Ali C. Begen (abegen); 'Jose Rey' >> Cc: 'Roni Even'; avt@ietf.org; Bill Ver Steeg (versteb) >> Subject: RE: [AVT] New draft of "Rapid Acquisition of Multicast=20 >> RTPSessions (RAMS)" available >> >> Hi, >> I also have concerns about having the unicast Transport addresses for = >> the RR RTCP and RTP receive port. >> I think that we should first talk about the NAT/FW issue and than=20 >> define the requirements and solutions. >> >> My assumption is that the retransmission server has a publicly=20 >> reachable address while the receivers may sit behind NATs and will=20 >> not have a publicly reachable address. >> Note that the RAMS flow starts from the receiver by RAMS-R so a=20 >> response to the transport address from where the RAMS-R came should=20 >> work (RTCP is bi-directional in this case). On the other hand the=20 >> unicast data flow is to the receiver so the receiver will need to=20 >> provide a reachable transport address. >> >> Roni >> >> -----Original Message----- >> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = >> Ali C. >> Begen (abegen) >> Sent: Saturday, May 23, 2009 3:27 AM >> To: Jose Rey >> Cc: Roni Even; avt@ietf.org; Bill Ver Steeg (versteb) >> Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast=20 >> RTPSessions (RAMS)" available >> >> Hi Jose, >> >> Indeed, RAMS-R goes to the FT of the new primary session that RR is=20 >> interested in acquiring rapidly. Then the unicast session becomes=20 >> alive and RS sends RAMS-I message(s) to RR on the RTCP port for the=20 >> unicast session. >> After some time, RR sends the RAMS-T message to the RTCP port for the = >> unicast session since it is supposed to end the unicast session. >> >> -acbegen >> >>> -----Original Message----- >>> From: Jose Rey [mailto:Jose.Rey@eu.panasonic.com] >>> Sent: Friday, May 22, 2009 7:09 AM >>> To: Ali C. Begen (abegen) >>> Cc: Roni Even; avt@ietf.org; Bill Ver Steeg (versteb) >>> Subject: RE: [AVT] New draft of "Rapid Acquisition of Multicast >> RTPSessions (RAMS)" >>> available >>> >>> >>> Hi Ali, >>> >>>> >>>> Hi Jose, >>>> >>>> We have separate RTCP ports for the SSM session and the unicast=20 >>>> session. Why is it a problem? >>> >>> In line 19 you say you specify the dst port for RMS-I (41003), on=20 >>> RR. >>> And >> you say that >>> would also be the port where the RR sends RMS-T, on RS. That is=20 >>> mixing the >> semantics of >>> a=3Drtcp for SSM (listening port at Feedback Target =3D mcast RTCP = dst >>> port) >> and those of RFC >>> 3605 (dst port). In other words, you are implicitly assuming that >> specifies symmetric >>> RTCP...no? >>> >>> Another thing that was mentioned already: RMS-T is not sent to same = >>> port >> as RMS-R; is it >>> not the same RTCP session ? Or is this muxing desired? why? >>> >>> JLR >>> >>>> >>>> The slightly modified SDP for the next version is below: >>>> >>> 1> a=3Dgroup:FID 3 4 >>> 2> a=3Drtcp-unicast:rsi >>> 3> m=3Dvideo 41000 RTP/AVPF 98 >>> 4> i=3DPrimary Multicast Stream #2 >>> 5> c=3DIN IP4 233.252.0.2/255 >>> 6> a=3Dsource-filter: incl IN IP4 233.252.0.2 192.0.2.2 >>> 7> a=3Drecvonly >>> 8> a=3Drtpmap:98 MP2T/90000 >>> 9> a=3Drtcp:41001 IN IP4 192.0.2.1 >>> 10> a=3Drtcp-fb:98 nack >>> 11> a=3Drtcp-fb:98 nack ssli >>> 12> a=3Dssrc:123321 cname:iptv-ch32@rams.example.com >>> 13> a=3Dmid:3 >>> 14> m=3Dvideo 41002 RTP/AVPF 99 >>> 15> i=3DUnicast Retransmission Stream #2 (Ret. and Rapid >>>> Acq. Support) >>> 16> c=3DIN IP4 192.0.2.1 >>> 17> a=3Drecvonly >>> 18> a=3Drtpmap:99 rtx/90000 >>> 19> a=3Drtcp:41003 >>> 20> a=3Dfmtp:99 apt=3D98; rtx-time=3D5000 >>> 21> a=3Dmid:4 >>>> >>>> This is the SDP we send to RR. For RS, a=3Drecvonly will be=20 >>>> a=3Dsendonly. >>>> >>>> -acbegen >>>> >>>> >>>>> -----Original Message----- >>>>> From: Jos=E9 Rey [mailto:jose.rey@eu.panasonic.com] >>>>> Sent: Thursday, May 21, 2009 3:22 PM >>>>> To: Ali C. Begen (abegen) >>>>> Cc: Roni Even; avt@ietf.org; Bill Ver Steeg (versteb) >>>>> Subject: Re: [AVT] New draft of "Rapid Acquisition of >>>> Multicast RTPSessions (RAMS)" >>>>> available >>>>> >>>>> Hi all, >>>>> >>>>> sorry for jumping in.... >>>>> >>>>> I think one of the sources of confusion is that the >>>> attribute a=3Drtcp: >>>>> is used once for specifying the destination port and once for=20 >>>>> specifying a receiving port, and in the same SDP (!). The >>>> destination >>>>> port for RAMS-I packets sent by RS and the receiving port >>>> for RAMS-T. Which is also why different port numbers are used for=20 >>>> RAMS-T and -R packets. >>>>> >>>>> I think the use of a=3Drtcp: in SSM is the problem here. Or the = fact=20 >>>>> that we are mixing unicast and multicast, or both. >>>>> >>>>> Hope this helps, >>>>> >>>>> JLR >>>>> >>>>> >>>>> >>>>> >>>>> Ali C. Begen (abegen) wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Roni Even [mailto:ron.even.tlv@gmail.com] >>>>> Sent: Saturday, April 25, 2009 2:58 PM >>>>> To: Ali C. Begen (abegen); avt@ietf.org >>>>> Cc: Bill Ver Steeg (versteb) >>>>> Subject: RE: [AVT] New draft of "Rapid Acquisition of >>>>> Multicast RTPSessions (RAMS)" available >>>>> >>>>> Ali, >>>>> I looked at RFC 4570 and I assume that port >>>> 41001 is the port for the >>>>> unicast RTCP reports from the receivers and according to >>>>> >>>>> >>>>> >>>>> Yes, indeed. >>>>> >>>>> >>>>> >>>>> section 3.2.1 of >>>>> that RFC you also should have a RTCP-unicast >>>> specification. >>>>> This is for the >>>>> multicast receiver reports. >>>>> >>>>> >>>>> >>>>> Correct. We do have that line in our draft at the top >>>> right after the grouping lines: >>>>> >>>>> a=3Drtcp-unicast:rsi >>>>> >>>>> BR, >>>>> -acbegen >>>>> >>>>> >>>>> >>>>> Roni >>>>> >>>>> -----Original Message----- >>>>> From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] >>>>> Sent: Saturday, April 25, 2009 11:30 PM >>>>> To: Roni Even; avt@ietf.org >>>>> Cc: Bill Ver Steeg (versteb) >>>>> Subject: RE: [AVT] New draft of "Rapid Acquisition of >>>>> Multicast RTPSessions >>>>> (RAMS)" available >>>>> >>>>> Here is the SDP. >>>>> >>>>> m=3Dvideo 41000 RTP/AVPF 98 >>>>> i=3DPrimary Multicast Stream #2 >>>>> c=3DIN IP4 224.1.1.2/255 >>>>> a=3Dsource-filter: incl IN IP4 224.1.1.2 192.0.2.2 >>>>> >>>>> Source (192.0.2.2) sends the rtp packets to the >>>> multicast >>>>> group (224.1.1.2) >>>>> with a dest port 41000. >>>>> >>>>> a=3Drtpmap:98 MP2T/90000 >>>>> a=3Drtcp:41001 IN IP4 192.0.2.1 >>>>> >>>>> The feedback target (RS) address for this SSM session is >>>>> 192.0.2.1 and its >>>>> port is 41001. This is the address/port where >>>> RR sends the RAMS-R, or >>>>> receiver reports for the SSM session. >>>>> >>>>> a=3Drtcp-fb:98 nack >>>>> a=3Drtcp-fb:98 nack ssli >>>>> a=3Dssrc:123321 cname:iptv-ch32@rams.example.com >>>>> a=3Dmid:3 >>>>> m=3Dvideo 41002 RTP/AVPF 99 >>>>> >>>>> The retransmission packets go to port 41002. >>>> This is the port >>>>> RRs listen to >>>>> for retransmission and RAMS. >>>>> >>>>> i=3DUnicast Retransmission Stream #2 >>>> (Ret. and Rapid >>>>> Acq. Support) >>>>> c=3DIN IP4 192.0.2.1 >>>>> >>>>> This is where the retransmission packets come >>>> from, same as >>>>> the feedback >>>>> target (in this example). >>>>> >>>>> a=3Drtpmap:99 rtx/90000 >>>>> a=3Drtcp:41003 >>>>> >>>>> This is where the RTCP packets for the >>>> retransmission session go. For >>>>> example, RAMS-I goes to this port on RRs. >>>> RAMS-T goes to this >>>>> port on RS. >>>>> >>>>> a=3Dfmtp:99 apt=3D98; rtx-time=3D5000 >>>>> a=3Dmid:4 >>>>> >>>>> >>>>> -acbegen >>>>> >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Roni Even [mailto:ron.even.tlv@gmail.com] >>>>> Sent: Saturday, April 25, 2009 1:11 PM >>>>> To: Ali C. Begen (abegen); avt@ietf.org >>>>> Cc: Bill Ver Steeg (versteb) >>>>> Subject: RE: [AVT] New draft of "Rapid >>>> Acquisition of >>>>> Multicast RTPSessions (RAMS)" available >>>>> >>>>> Ali, >>>>> Can you please write three addresses >>>> from this strange SDP. >>>>> >>>>> 1. The address and port of multicast >>>>> >>>>> 2. The address and port of the RS where >>>> the RTCP FB should go to >>>>> >>>>> 3. The address and port on the RR where >>>> the unicast stream >>>>> should be sent to >>>>> >>>>> Roni >>>>> >>>>> -----Original Message----- >>>>> From: Ali C. Begen (abegen) >>>> [mailto:abegen@cisco.com] >>>>> Sent: Saturday, April 25, 2009 11:02 PM >>>>> To: Roni Even; avt@ietf.org >>>>> Cc: Bill Ver Steeg (versteb) >>>>> Subject: RE: [AVT] New draft of "Rapid >>>> Acquisition of >>>>> Multicast RTPSessions >>>>> (RAMS)" available >>>>> >>>>> >>>>> >>>>> Ali, >>>>> The example SDP is >>>> syntactically correct but it does not >>>>> >>>>> >>>>> say that the >>>>> >>>>> >>>>> rtp/rtcp mux will be used and >>>> it does not give the >>>>> information to where the >>>>> unicast stream will be sent >>>> when the RR sends a RAMS-R. >>>>> >>>>> >>>>> To my knowledge, the first line in the >>>> following SDP tells >>>>> the RRs on which >>>>> port they will receive the >>>> retransmission/burst packets. >>>>> >>>>> m=3Dvideo 41002 RTP/AVPF 99 >>>>> i=3DUnicast Retransmission Stream >>>> #2 (Ret. and Rapid >>>>> Acq. Support) >>>>> c=3DIN IP4 192.0.2.1 >>>>> a=3Drtpmap:99 rtx/90000 >>>>> a=3Drtcp:41003 >>>>> a=3Dfmtp:99 apt=3D98; rtx-time=3D5000 >>>>> a=3Dmid:4 >>>>> >>>>> There is a typo, you are right. That >>>> "a=3Drecvonly" line should >>>>> only exist in >>>>> the SDP sent to RRs. In the SDP sent to >>>> RS, we should rather have >>>>> "a=3Dsendonly". I will make this >>>> correction in the next version. >>>>> >>>>> The feedback target for the SSM session >>>> and the RTCP port for the >>>>> retransmission session are also defined >>>> in the SDP. >>>>> >>>>> Hope this clarifies. >>>>> >>>>> BR, >>>>> -acbegen >>>>> >>>>> >>>>> >>>>> I am not sure why the unicast >>>> stream m-line has a port >>>>> >>>>> >>>>> number with an >>>>> >>>>> >>>>> attribute of recvonly. What is >>>> the use case for that. The >>>>> only information >>>>> that the RR will need is the >>>> RTCP port on the RS to where to >>>>> send the RAMS-R >>>>> message. >>>>> Roni >>>>> -----Original Message----- >>>>> From: Ali C. Begen (abegen) >>>> [mailto:abegen@cisco.com] >>>>> Sent: Friday, April 24, 2009 10:37 PM >>>>> To: Roni Even; avt@ietf.org >>>>> Cc: Bill Ver Steeg (versteb) >>>>> Subject: RE: [AVT] New draft of >>>> "Rapid Acquisition of >>>>> Multicast RTPSessions >>>>> (RAMS)" available >>>>> >>>>> This is a part of an example >>>> SDP sent to RS and RR in a SAP >>>>> announcement, >>>>> for example. So, the SDP >>>> describes what both parties should >>>>> do (RR cannot >>>>> say that he wants to receive >>>> this multicast on its favorite >>>>> >>>>> >>>>> port). The >>>>> >>>>> >>>>> individual SDPs sent to RR or >>>> RS may include other portions >>>>> of descriptions >>>>> that will contain specific information. >>>>> >>>>> -acbegen >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Roni Even >>>> [mailto:ron.even.tlv@gmail.com] >>>>> Sent: Friday, April 24, >>>> 2009 12:23 PM >>>>> To: Ali C. Begen >>>> (abegen); avt@ietf.org >>>>> Cc: Bill Ver Steeg (versteb) >>>>> Subject: RE: [AVT] New >>>> draft of "Rapid Acquisition of >>>>> Multicast RTPSessions >>>> (RAMS)" available >>>>> >>>>> Ali, >>>>> I think you get it >>>> wrong, this SDP is from the RS and not the >>>>> RR so the RS >>>>> cannot specify to which >>>> address it will send it can only >>>>> specify to which >>>>> address it can receive >>>> RTP stream. In this SDP the relevant >>>>> information is >>>>> that the request for >>>> retransmission will be sent by the RR to >>>>> port 41003 >>>>> Roni >>>>> >>>>> -----Original Message----- >>>>> From: Ali C. Begen >>>> (abegen) [mailto:abegen@cisco.com] >>>>> Sent: Friday, April 24, >>>> 2009 10:01 PM >>>>> To: Roni Even; avt@ietf.org >>>>> Cc: Bill Ver Steeg (versteb) >>>>> Subject: RE: [AVT] New >>>> draft of "Rapid Acquisition of >>>>> Multicast RTPSessions >>>>> (RAMS)" available >>>>> >>>>> Oh, I see. The burst >>>> goes to the port that we would >>>>> >>>>> >>>>> normally send the >>>>> >>>>> >>>>> retransmissions. For >>>> example, consider the SDP from the draft: >>>>> >>>>> m=3Dvideo 41000 >>>> RTP/AVPF 98 >>>>> i=3DPrimary >>>> Multicast Stream #2 >>>>> c=3DIN IP4 224.1.1.2/255 >>>>> >>>> a=3Dsource-filter: incl IN IP4 224.1.1.2 192.0.2.2 >>>>> a=3Drtpmap:98 MP2T/90000 >>>>> a=3Drtcp:41001 IN >>>> IP4 192.0.2.1 >>>>> a=3Drtcp-fb:98 nack >>>>> a=3Drtcp-fb:98 nack ssli >>>>> a=3Dssrc:123321 >>>> cname:iptv-ch32@rams.example.com >>>>> a=3Dmid:3 >>>>> m=3Dvideo 41002 >>>> RTP/AVPF 99 >>>>> i=3DUnicast >>>> Retransmission Stream #2 (Ret. and Rapid >>>>> Acq. Support) >>>>> c=3DIN IP4 192.0.2.1 >>>>> a=3Drecvonly >>>>> a=3Drtpmap:99 rtx/90000 >>>>> a=3Drtcp:41003 >>>>> a=3Dfmtp:99 >>>> apt=3D98; rtx-time=3D5000 >>>>> a=3Dmid:4 >>>>> >>>>> In this case, the burst >>>> will go to port 41002 on the RR. >>>>> >>>>> >>>>> The RAMS-I >>>>> >>>>> >>>>> message(s), which is an >>>> RTCP feedback message, will go to >>>>> >>>>> >>>>> port 41003. >>>>> >>>>> >>>>> HTH, >>>>> -acbegen >>>>> >>>>> >>>>> >>>>> -----Original >>>> Message----- >>>>> From: Roni Even >>>> [mailto:ron.even.tlv@gmail.com] >>>>> Sent: Friday, >>>> April 24, 2009 11:44 AM >>>>> To: Ali C. >>>> Begen (abegen); avt@ietf.org >>>>> Cc: Bill Ver >>>> Steeg (versteb) >>>>> Subject: RE: >>>> [AVT] New draft of "Rapid Acquisition of >>>>> Multicast >>>> RTPSessions (RAMS)" available >>>>> >>>>> Ali, >>>>> I will try to >>>> explain in simple way >>>>> >>>>> When the RS >>>> receives the RAMS-R it need to start sending an >>>>> RTP stream to >>>>> the RR. >>>>> In order to >>>> send a unicast packet, the RS needs to know a >>>>> transport address >>>>> on the RR to >>>> where the RTP stream will be sent. The current >>>>> draft does not >>>>> say how the RS >>>> knows this address. There is no SDP from RR to >>>>> RS like you >>>>> mention in your >>>> response. >>>>> This is why I >>>> say that the current draft does not specify a >>>>> solution that >>>>> can be >>>> implemented as a working solution >>>>> Roni >>>>> >>>>> -----Original >>>> Message----- >>>>> From: Ali C. >>>> Begen (abegen) [mailto:abegen@cisco.com] >>>>> Sent: Friday, >>>> April 24, 2009 7:38 PM >>>>> To: Roni Even; >>>> avt@ietf.org >>>>> Cc: Bill Ver >>>> Steeg (versteb) >>>>> Subject: RE: >>>> [AVT] New draft of "Rapid Acquisition of >>>>> Multicast RTPSessions >>>>> (RAMS)" available >>>>> >>>>> Hi Roni, >>>>> >>>>> >>>>> >>>>> >>>> -----Original Message----- >>>>> From: >>>> avt-bounces@ietf.org [mailto:avt- bounces@ietf.org] On >>>>> Behalf >>>> Of Roni Even >>>>> Sent: >>>> Friday, April 24, 2009 4:24 AM >>>>> To: avt@ietf.org >>>>> Cc: >>>> Bill Ver Steeg (versteb) >>>>> >>>> Subject: Re: [AVT] New draft of "Rapid Acquisition of >>>>> >>>> Multicast RTPSessions (RAMS)" available >>>>> >>>>> Hi, >>>>> >>>>> I think >>>> that the current draft does not give a >>>>> >>>>> >>>>> description of >>>>> >>>>> >>>>> a >>>> system that works since there is no text >>>>> >>>>> >>>>> explaining how the >>>>> >>>>> >>>>> What do you >>>> mean by "a system that works"? >>>>> >>>>> >>>>> >>>>> RS >>>> knows the unicast transport address on the RR to >>>>> >>>>> >>>>> where to >>>>> >>>>> >>>>> send the stream. >>>>> >>>>> >>>>> Once RS >>>> receives the request packet from an RR, RS knows its >>>>> address. Ports >>>>> are defined in >>>> the SDP. If you are asking about "NAT" >>>>> issues, >>>>> we have a >>>>> section for it, >>>> and we plan to complete it as we move >>>>> forward. It is not as >>>>> critical as the >>>> other parts for now. >>>>> >>>>> >>>>> >>>>> If you >>>> mandate the use of RTP/RTCP mux it should say so >>>>> >>>> otherwise the RAMS-R should have an optional parameter that >>>>> >>>> supplies this information and a flag for using RTP/RTCP mux. >>>>> >>>>> >>>>> IMO, we cannot >>>> mandate muxing as it is not required to make >>>>> RAMS work. If >>>>> muxing is >>>> supported, the SDP should reflect it. >>>>> >>>>> BR, >>>>> -acbegen >>>>> >>>>> >>>>> >>>>> Thanks >>>>> >>>>> Roni Even >>>>> >>>>> >>>>> >>>>> From: >>>> avt-bounces@ietf.org [mailto:avt- bounces@ietf.org] On >>>>> Behalf >>>> Of Bill Ver Steeg (versteb) >>>>> Sent: >>>> Thursday, April 16, 2009 7:39 PM >>>>> To: avt@ietf.org >>>>> >>>> Subject: [AVT] New draft of "Rapid Acquisition of Multicast >>>>> RTP >>>> Sessions (RAMS)" available >>>>> >>>>> >>>>> >>>>> There >>>> is a new draft of the "Rapid Acquisition of Multicast >>>>> RTP >>>> Sessions (RAMS)" draft available at >>>>> >>>>> >>>>> >>>>> >>>> http://www.ietf.org/internet-drafts/draft-versteeg-avt-rapid-s >>>>> >>>>> >>>>> >>>> ynchronization-for-rtp-03.txt >>>>> <http://www.ietf.org/internet-> <http://www.ietf.org/internet-> >>>>> >>>>> >>>>> >>>>> >>>> drafts/draft-versteeg-avt-rapid-synchronization-for-rtp-03.txt> >>>>> >>>>> >>>>> >>>>> >>>>> We have >>>> incorporated the changes from the technical >>>>> >>>>> >>>>> breakout >>>>> >>>>> >>>>> session >>>> in San Francisco. The major changes in this version >>>>> of the >>>> draft include >>>>> >>>>> 1- >>>> Changing the document title to avoid confusion >>>>> >>>>> >>>>> with other >>>>> >>>>> >>>>> ongoing >>>> "synchronization" drafts >>>>> >>>>> 2- >>>> changing the message names to reflect the title change >>>>> >>>>> 3- >>>> clarification of the RTCP message semantics, including >>>>> changes >>>> to the "Request" and "Inform" messages >>>>> >>>>> 4- >>>> additional description/motivation for the >>>>> >>>>> >>>>> various message >>>>> >>>>> >>>>> flows >>>> has been added >>>>> >>>>> 5- >>>> RTP/RTCP muxing has been added >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> We hope >>>> to make this a Working Group item, and will change >>>>> the >>>> name of the draft to avoid conflicts with other >>>>> >>>> "synchronization" drafts at that time. >>>>> >>>>> >>>>> >>>>> Bill VerSteeg >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Audio/Video Transport Working Group >>>>> avt@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/avt >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> Panasonic R&D Center Germany GmbH >>> 63225 Langen, Hessen, Germany >>> Reg: AG Offenbach (Hessen) HRB 33974 Managing Director: Thomas Micke >>> >> >> _______________________________________________ >> Audio/Video Transport Working Group >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt >> >> _______________________________________________ >> Audio/Video Transport Working Group >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt > From csp@csperkins.org Mon May 25 14:06:37 2009 Return-Path: <csp@csperkins.org> X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79C763A6C58 for <avt@core3.amsl.com>; Mon, 25 May 2009 14:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.396 X-Spam-Level: X-Spam-Status: No, score=-3.396 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nEi3bMl53MOy for <avt@core3.amsl.com>; Mon, 25 May 2009 14:06:36 -0700 (PDT) Received: from lon1-msapost-1.mail.demon.net (lon1-msapost-1.mail.demon.net [195.173.77.180]) by core3.amsl.com (Postfix) with ESMTP id 009B93A6D83 for <avt@ietf.org>; Mon, 25 May 2009 14:06:35 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=Unknown-00-23-32-af-9b-aa.lan) by lon1-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1M8hP2-0005OY-XL; Mon, 25 May 2009 21:08:12 +0000 Message-Id: <658E8F78-CF7D-4405-9C73-ABE2837B4E62@csperkins.org> From: Colin Perkins <csp@csperkins.org> To: Marshall Eubanks <marshall.eubanks@gmail.com> In-Reply-To: <dcad22d80905251225h64bd303cx9de2c1698b8eaa7d@mail.gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-25-837994756 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 25 May 2009 22:08:03 +0100 References: <001701c9dca0$bd465130$37d2f390$%roni@huawei.com> <dcad22d80905251225h64bd303cx9de2c1698b8eaa7d@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) Cc: "Dave Oran \(oran\)" <oran@cisco.com>, avt@ietf.org, Roni Even <Even.roni@huawei.com> Subject: Re: [AVT] RTP unicast address for retransmssion of multicast sesssion or using RTCP to negotitaion of RTP adddresses X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group <avt.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/avt> List-Post: <mailto:avt@ietf.org> List-Help: <mailto:avt-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 25 May 2009 21:06:37 -0000 --Apple-Mail-25-837994756 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 25 May 2009, at 20:25, Marshall Eubanks wrote: > On Sun, May 24, 2009 at 2:51 PM, Roni Even <Even.roni@huawei.com> > wrote: > One of the issues discussed in Rapid Acquisition of Multicast > RTPSessions (RAMS) has to do with the specific architecture where > the media is sent to an announced multicast address where there is > no offer answer negotiation between the sender and the receivers. > In the proposed solution receivers may ask using RTCP for unicast > retransmission of the RTP stream. The current draft has as part of > the announcement a port number that the receiver should use to > receive the unicast RTP stream. This port is specified by the > retransmission server and not by the receiver and it assumes that > the IP address will be the same as the one from where the RTCP > message came from. > > > The problem we encounter is that this retransmission stream is > flowing from the retransmission server to the receiver who may be > behind a FW/NAT. The simple case is if the RTP and RTCP streams are > multiplexed on the RTCP port since in this case there is an RTCP > message going from the receiver to the retransmission server which > will open a pin hole in the NAT/FW enabling RTP to flow back to the > receiver (Will need some keep alive mechanism) > > The case we are trying to discuss here is when we want to have a > separate RTP channel (not multiplexed with RTCP). In this case we > will need some mechanism to convey an address from the receiver to > the retransmission server. > > > We would like to ask if this should be part of RAMS or do we want a > general RTCP message to covey such information. > > > I would say that this should be a general RTCP message. This is a > general technique now for getting through firewalls (rfc 5138). H. > 460 /18 and /19 use it, ICE uses it, it should be made general for > RTP. I agree that a general mechanism should be defined, rather than something that's narrowly focussed on the RAMS problem. It's not clear that RTCP is the right place for such an extension, though. RTCP has focussed on media level issues to date, leaving transport layer configuration to protocols like STUN. This seems like more of a STUN extension, than something that should be in RTCP. -- Colin Perkins http://csperkins.org/ --Apple-Mail-25-837994756 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable <html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; = -webkit-line-break: after-white-space; "><div><div>On 25 May 2009, at = 20:25, Marshall Eubanks wrote:</div><blockquote type=3D"cite"><div = class=3D"gmail_quote">On Sun, May 24, 2009 at 2:51 PM, Roni Even <span = dir=3D"ltr"><<a = href=3D"mailto:Even.roni@huawei.com">Even.roni@huawei.com</a>></span> = wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 = .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div lang=3D"EN-US" = link=3D"blue" vlink=3D"purple"> <div><p><span class=3D"Apple-style-span" = style=3D"-webkit-text-stroke-width: -1; ">One of the issues discussed in = Rapid Acquisition of Multicast RTPSessions (RAMS) has to do with the = specific architecture where the media is sent to an announced = multicast  address where there is no offer answer negotiation = between the sender and the receivers.  In the proposed solution =  receivers may ask using RTCP for unicast retransmission of the RTP = stream. The current draft has as part of the announcement a port number = that the receiver should use to receive the unicast RTP stream. =  This port is specified by the retransmission server and not by the = receiver and it assumes that the IP address will be the same as the one = from where the RTCP message came from.</span></p><div> <br = class=3D"webkit-block-placeholder"></div><p>The problem we encounter is = that this retransmission stream is flowing from the retransmission = server to the receiver who may be behind a FW/NAT. The simple case is if = the RTP and RTCP streams are multiplexed on the RTCP port since in this = case there is an RTCP message going from the receiver to the = retransmission server which will open a pin hole in the NAT/FW enabling = RTP to flow back to the receiver (Will need some keep alive = mechanism)</p><p>The case we are trying to discuss here is when we want = to have a separate RTP channel (not multiplexed with RTCP). In this case = we will need some mechanism to convey an address from the receiver to = the retransmission server. </p><div> <br = class=3D"webkit-block-placeholder"></div><p>We would like to ask if this = should be part of RAMS or do we want a general RTCP message to covey = such information.</p></div></div></blockquote><div><br></div><div>I = would say that this should be a general RTCP message. This is a general = technique now for getting through firewalls (rfc 5138). H.460 /18 and = /19 use it, ICE uses it, it should be made general for = RTP.</div></div></blockquote></div><br>I agree that a general mechanism = should be defined, rather than something that's narrowly focussed on the = RAMS problem. It's not clear that RTCP is the right place for such an = extension, though. RTCP has focussed on media level issues to date, = leaving transport layer configuration to protocols like STUN. This seems = like more of a STUN extension, than something that should be in = RTCP.<div apple-content-edited=3D"true"><span class=3D"Apple-style-span" = style=3D"border-collapse: separate; color: rgb(0, 0, 0); font-family: = Arial; font-size: 9px; font-style: normal; font-variant: normal; = font-weight: normal; letter-spacing: normal; line-height: normal; = orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; = white-space: normal; widows: 2; word-spacing: 0px; = -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: = 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = auto; -webkit-text-stroke-width: 0; "><div style=3D"word-wrap: = break-word; -webkit-nbsp-mode: space; -webkit-line-break: = after-white-space; "><span class=3D"Apple-style-span" = style=3D"border-collapse: separate; color: rgb(0, 0, 0); font-family: = 'Lucida Sans Typewriter'; font-size: 9px; font-style: normal; = font-variant: normal; font-weight: normal; letter-spacing: normal; = line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; = white-space: normal; widows: 2; word-spacing: 0px; = -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: = 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = auto; -webkit-text-stroke-width: 0px; "><span class=3D"Apple-style-span" = style=3D"border-collapse: separate; -webkit-border-horizontal-spacing: = 0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); = font-family: 'Lucida Sans Typewriter'; font-size: 9px; font-style: = normal; font-variant: normal; font-weight: normal; letter-spacing: = normal; line-height: normal; -webkit-text-decorations-in-effect: none; = text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; = orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span = class=3D"Apple-style-span" style=3D"border-collapse: separate; = -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: = 0px; color: rgb(0, 0, 0); font-family: 'Lucida Sans Typewriter'; = font-size: 9px; font-style: normal; font-variant: normal; font-weight: = normal; letter-spacing: normal; line-height: normal; = -webkit-text-decorations-in-effect: none; text-indent: 0px; = -webkit-text-size-adjust: auto; text-transform: none; orphans: 2; = white-space: normal; widows: 2; word-spacing: 0px; "><span = class=3D"Apple-style-span" style=3D"border-collapse: separate; = -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: = 0px; color: rgb(0, 0, 0); font-family: 'Lucida Sans Typewriter'; = font-size: 9px; font-style: normal; font-variant: normal; font-weight: = normal; letter-spacing: normal; line-height: normal; = -webkit-text-decorations-in-effect: none; text-indent: 0px; = -webkit-text-size-adjust: auto; text-transform: none; orphans: 2; = white-space: normal; widows: 2; word-spacing: 0px; "><div><br = class=3D"khtml-block-placeholder"></div><div>-- </div><div></div><div= >Colin Perkins</div><div><a = href=3D"http://csperkins.org/">http://csperkins.org/</a></div></span></spa= n></span><br class=3D"Apple-interchange-newline"></span><br = class=3D"Apple-interchange-newline"></div></span> = </div><br></body></html>= --Apple-Mail-25-837994756-- From Even.roni@huawei.com Tue May 26 00:37:19 2009 Return-Path: <Even.roni@huawei.com> X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F14713A68D6 for <avt@core3.amsl.com>; Tue, 26 May 2009 00:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.375 X-Spam-Level: X-Spam-Status: No, score=-0.375 tagged_above=-999 required=5 tests=[AWL=2.223, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILmoL-J-1ERV for <avt@core3.amsl.com>; Tue, 26 May 2009 00:37:19 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id E5C293A67BD for <avt@ietf.org>; Tue, 26 May 2009 00:37:18 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KK8003UFQGJW7@szxga03-in.huawei.com> for avt@ietf.org; Tue, 26 May 2009 15:36:19 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KK800EX7QGJHE@szxga03-in.huawei.com> for avt@ietf.org; Tue, 26 May 2009 15:36:19 +0800 (CST) Received: from windows8d787f9 (bzq-79-182-101-49.red.bezeqint.net [79.182.101.49]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KK800NC2QG50W@szxml02-in.huawei.com>; Tue, 26 May 2009 15:36:19 +0800 (CST) Date: Tue, 26 May 2009 10:35:10 +0300 From: Roni Even <Even.roni@huawei.com> To: avt@ietf.org Message-id: <004b01c9ddd4$88fe9240$9afbb6c0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_HnFmPBmXeJQ77IerVSd8bg)" Content-language: en-us Thread-index: Acnd1H8a/qlT+SluQeWBS2OzJQlWsQ== Cc: 'Tom Taylor' <tom.taylor@rogers.com> Subject: [AVT] WGLC on draft-ietf-avt-rtp-ipmr-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group <avt.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/avt> List-Post: <mailto:avt@ietf.org> List-Help: <mailto:avt-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 26 May 2009 07:37:20 -0000 This is a multipart message in MIME format. --Boundary_(ID_HnFmPBmXeJQ77IerVSd8bg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, I would like to start a WGLC on http://tools.ietf.org/html/draft-ietf-avt-rtp-ipmr-04 . This is the RTP Payload Format for IP-MR Speech Codec. There was some comments on the mailing list about this work and they were addressed in the 04 draft. We will start a 3 weeks working group last call. Please review the draft and send comments till June 16th Thanks Roni Even AVT co-chair --Boundary_(ID_HnFmPBmXeJQ77IerVSd8bg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT <html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"> <meta name=Generator content="Microsoft Word 12 (filtered medium)"> <style> <!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} span.EmailStyle17 {mso-style-type:personal-compose; font-family:"Calibri","sans-serif"; color:windowtext;} .MsoChpDefault {mso-style-type:export-only;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.25in 1.0in 1.25in;} div.Section1 {page:Section1;} --> </style> <!--[if gte mso 9]><xml> <o:shapedefaults v:ext="edit" spidmax="1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext="edit"> <o:idmap v:ext="edit" data="1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=EN-US link=blue vlink=purple> <div class=Section1> <p class=MsoNormal><o:p> </o:p></p> <p class=MsoNormal>Hi,<o:p></o:p></p> <p class=MsoNormal>I would like to start a WGLC on <a href="http://tools.ietf.org/html/draft-ietf-avt-rtp-ipmr-04">http://tools.ietf.org/html/draft-ietf-avt-rtp-ipmr-04</a> .<o:p></o:p></p> <p class=MsoNormal><o:p> </o:p></p> <p class=MsoNormal><span lang=EN>This is the RTP Payload Format for IP-MR Speech Codec</span>. <o:p></o:p></p> <p class=MsoNormal><o:p> </o:p></p> <p class=MsoNormal>There was some comments on the mailing list about this work and they were addressed in the 04 draft. <o:p></o:p></p> <p class=MsoNormal><o:p> </o:p></p> <p class=MsoNormal>We will start a 3 weeks working group last call.<o:p></o:p></p> <p class=MsoNormal>Please review the draft and send comments till June 16<sup>th</sup><o:p></o:p></p> <p class=MsoNormal><o:p> </o:p></p> <p class=MsoNormal>Thanks<o:p></o:p></p> <p class=MsoNormal>Roni Even<o:p></o:p></p> <p class=MsoNormal>AVT co-chair<o:p></o:p></p> <p class=MsoNormal><o:p> </o:p></p> </div> </body> </html> --Boundary_(ID_HnFmPBmXeJQ77IerVSd8bg)-- From oran@cisco.com Tue May 26 05:34:48 2009 Return-Path: <oran@cisco.com> X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A20628C24C for <avt@core3.amsl.com>; Tue, 26 May 2009 05:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.582 X-Spam-Level: X-Spam-Status: No, score=-6.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r88u5yMFXDk9 for <avt@core3.amsl.com>; Tue, 26 May 2009 05:34:47 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 4376C28C26C for <avt@ietf.org>; Tue, 26 May 2009 05:33:45 -0700 (PDT) X-Files: PGP.sig : 195 X-IronPort-AV: E=Sophos;i="4.41,251,1241395200"; d="sig'?scan'208";a="169043272" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 26 May 2009 12:35:27 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n4QCZRLH009826 for <avt@ietf.org>; Tue, 26 May 2009 05:35:27 -0700 Received: from stealth-10-32-245-158.cisco.com (stealth-10-32-245-158.cisco.com [10.32.245.158]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n4QCZ3u7028359 for <avt@ietf.org>; Tue, 26 May 2009 12:35:26 GMT Received: from [127.0.0.1] by stealth-10-32-245-158.cisco.com (PGP Universal service); Tue, 26 May 2009 08:35:26 -0400 X-PGP-Universal: processed; by stealth-10-32-245-158.cisco.com on Tue, 26 May 2009 08:35:26 -0400 Message-Id: <47FF3BB2-82FA-4601-920A-CE1DBB466994@cisco.com> From: David R Oran <oran@cisco.com> To: Colin Perkins <csp@csperkins.org> In-Reply-To: <658E8F78-CF7D-4405-9C73-ABE2837B4E62@csperkins.org> Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 26 May 2009 08:34:58 -0400 References: <001701c9dca0$bd465130$37d2f390$%roni@huawei.com> <dcad22d80905251225h64bd303cx9de2c1698b8eaa7d@mail.gmail.com> <658E8F78-CF7D-4405-9C73-ABE2837B4E62@csperkins.org> X-Mailer: Apple Mail (2.935.3) X-PGP-Encoding-Format: MIME X-PGP-Encoding-Version: 2.0.2 Content-Type: multipart/signed; boundary="PGP_Universal_5B2C5B79_69B4ED13_C23C9833_065F448D"; protocol="application/pgp-signature"; micalg="pgp-sha1" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4030; t=1243341327; x=1244205327; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:=20David=20R=20Oran=20<oran@cisco.com> |Subject:=20Re=3A=20[AVT]=20RTP=20unicast=20address=20for=2 0retransmssion=20of=20multicast=20sesssion=20or=20using=20RT CP=20to=20negotitaion=20of=20RTP=20adddresses |Sender:=20; bh=Fwl3zF3xB2Z9eX03dNDh1B/cRFpFudzBbillVMZwkwg=; b=jqkU/LlETK7wgJKEsHBBWJLM47VhcQbIrSK489CtHNZ7LwAXgJSxBFlFG4 SjXjFrZxpnyTF9ozeolLUIK3FQkCRYqgkZ1ZUE4qHJzJFnez5k/UhSfhOjOy e+FX8dahLY; Authentication-Results: sj-dkim-2; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: Roni Even <Even.roni@huawei.com>, Marshall Eubanks <marshall.eubanks@gmail.com>, avt@ietf.org Subject: Re: [AVT] RTP unicast address for retransmssion of multicast sesssion or using RTCP to negotitaion of RTP adddresses X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group <avt.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/avt> List-Post: <mailto:avt@ietf.org> List-Help: <mailto:avt-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 26 May 2009 12:34:48 -0000 --PGP_Universal_5B2C5B79_69B4ED13_C23C9833_065F448D Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On May 25, 2009, at 5:08 PM, Colin Perkins wrote: > On 25 May 2009, at 20:25, Marshall Eubanks wrote: >> On Sun, May 24, 2009 at 2:51 PM, Roni Even <Even.roni@huawei.com> >> wrote: >> One of the issues discussed in Rapid Acquisition of Multicast >> RTPSessions (RAMS) has to do with the specific architecture where >> the media is sent to an announced multicast address where there is >> no offer answer negotiation between the sender and the receivers. >> In the proposed solution receivers may ask using RTCP for unicast >> retransmission of the RTP stream. The current draft has as part of >> the announcement a port number that the receiver should use to >> receive the unicast RTP stream. This port is specified by the >> retransmission server and not by the receiver and it assumes that >> the IP address will be the same as the one from where the RTCP >> message came from. >> >> >> The problem we encounter is that this retransmission stream is >> flowing from the retransmission server to the receiver who may be >> behind a FW/NAT. The simple case is if the RTP and RTCP streams are >> multiplexed on the RTCP port since in this case there is an RTCP >> message going from the receiver to the retransmission server which >> will open a pin hole in the NAT/FW enabling RTP to flow back to the >> receiver (Will need some keep alive mechanism) >> >> The case we are trying to discuss here is when we want to have a >> separate RTP channel (not multiplexed with RTCP). In this case we >> will need some mechanism to convey an address from the receiver to >> the retransmission server. >> >> >> We would like to ask if this should be part of RAMS or do we want a >> general RTCP message to covey such information. >> >> >> I would say that this should be a general RTCP message. This is a >> general technique now for getting through firewalls (rfc 5138). H. >> 460 /18 and /19 use it, ICE uses it, it should be made general for >> RTP. > > I agree that a general mechanism should be defined, rather than > something that's narrowly focussed on the RAMS problem. It's not > clear that RTCP is the right place for such an extension, though. > RTCP has focussed on media level issues to date, leaving transport > layer configuration to protocols like STUN. This seems like more of > a STUN extension, than something that should be in RTCP. > Possibly. We considered just relying on STUN (you need something like it anyway to force open the ports), but there are two issues: 1. The need to keep state on the server side, which potentially opens up state-based attacks, if you want to open up the ports "in advance" and then use them later (for retransmission). 2. An extra round trip during the critical path for RAMS unless we can find a way to piggyback both STUN and RTCP on a single datagram. It might be "interesting" to see if there's a way to in fact piggyback STUN and RTCP in a single UDP packet. That leaves the questions around TURN that Roni raised for the case where both hosts are behind NATs. I'm somewhat at a loss to think of an efficient scheme for that case; given that TURN needs rendezvous state anyway and may need to be set up in advance, I'm afraid the extra round trip is unavoidable in that case and we might as well use ICE. DaveO. > -- > Colin Perkins > http://csperkins.org/ > > > --PGP_Universal_5B2C5B79_69B4ED13_C23C9833_065F448D Content-Type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig Content-Disposition: attachment; filename=PGP.sig -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.10.0 (Build 500) iQA/AwUBShviB41mhLZU3SrmEQIMuwCfShYm7zGmZMVb8eh25gmCweVc2DMAnjQs 6hDFIUBv6YWQlJdiKGFMMuRt =d2sv -----END PGP SIGNATURE----- --PGP_Universal_5B2C5B79_69B4ED13_C23C9833_065F448D-- From xavier.marjou@gmail.com Tue May 26 05:42:14 2009 Return-Path: <xavier.marjou@gmail.com> X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09C573A70C9 for <avt@core3.amsl.com>; Tue, 26 May 2009 05:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfdOtaYzQWPE for <avt@core3.amsl.com>; Tue, 26 May 2009 05:42:13 -0700 (PDT) Received: from mail-ew0-f176.google.com (mail-ew0-f176.google.com [209.85.219.176]) by core3.amsl.com (Postfix) with ESMTP id 0A8353A70C7 for <avt@ietf.org>; Tue, 26 May 2009 05:42:12 -0700 (PDT) Received: by ewy24 with SMTP id 24so3697736ewy.37 for <avt@ietf.org>; Tue, 26 May 2009 05:43:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=qpvC6at9Zmb4FDyc2ZKhE0wQHNxUgAMKSnPgTqt6tfA=; b=kd1IvTmWHYyjneKaDh1KwWPNjUxulM2dQgqCoSXrqkYoTV8+EWjpZ+R6DXLHoGDETk clcVO1Q5B+0AWpnGUeTtXY8m4sY6hrPOqVqi43kVH7pd3lZqFB78i5qd7gPhFLPCCqc/ fAq9OgPd3hSJt+WNOYFnv4Mfqc/v/C6zA9+Sg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=QBioL/SqZvjSwrUWfTJpVvKVKbhK11zcJpKhUXEt6HmPxF3NTe+K2h1x+BaTrdI7te gr3djhfFP+8CkGX5aHkjwy0Frk49wEkzBbBSIIxknU/NKbPTBmXjAWW1KxAbbFyr0Jxq 7XHkOp8IFaSEf9xekLxJ8Nmsch7A/zqb2zee8= MIME-Version: 1.0 Sender: xavier.marjou@gmail.com Received: by 10.216.26.77 with SMTP id b55mr3110153wea.101.1243341823663; Tue, 26 May 2009 05:43:43 -0700 (PDT) In-Reply-To: <001701c9dca0$bd465130$37d2f390$%roni@huawei.com> References: <001701c9dca0$bd465130$37d2f390$%roni@huawei.com> Date: Tue, 26 May 2009 14:43:43 +0200 X-Google-Sender-Auth: f07357d1493eab2a Message-ID: <458913680905260543h295c380ate312c7efe055534d@mail.gmail.com> From: Xavier Marjou <xavier.marjou@orange-ftgroup.com> To: Roni Even <Even.roni@huawei.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Dave Oran \(oran\)" <oran@cisco.com>, avt@ietf.org Subject: Re: [AVT] RTP unicast address for retransmssion of multicast sesssion or using RTCP to negotitaion of RTP adddresses X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group <avt.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/avt> List-Post: <mailto:avt@ietf.org> List-Help: <mailto:avt-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 26 May 2009 12:42:14 -0000 Hi, > The problem we encounter is that this retransmission stream is flowing from > the retransmission server to the receiver who may be behind a FW/NAT. The > simple case is if the RTP and RTCP streams are multiplexed on the RTCP port > since in this case there is an RTCP message going from the receiver to the > retransmission server which will open a pin hole in the NAT/FW enabling RTP > to flow back to the receiver (Will need some keep alive mechanism) > > The case we are trying to discuss here is when we want to have a separate > RTP channel (not multiplexed with RTCP). In this case we will need some > mechanism to convey an address from the receiver to the retransmission > server. My undertsanding is that this problem (RTP packets can not traverse a NAT from the public side to the private side) was tackled by the avt wg and solved by the draft-ietf-avt-rtp-and-rtcp-mux. Why this solution would now not be used for the rapid-acquisition draft? Is there anything missing in rtp-and-rtcp-mux? > > We would like to ask if this should be part of RAMS or do we want a general > RTCP message to covey such information. > > We would like to get some other scenarios not for RAMS that have similar > requirements. If there's addional work on "yet" another NAT traversal solution, I anticipate that we'll end up with additional bandwidth and delays with solutions like "symmetric+keepalive rtp", "tunnelling protocol", or "upnp", which will reduce the optimization expected from the rapid-acquisition draft. So my opinion is to keep it simple by mandating rtp-rtcp-mux only and avoid any new work related to NAT traversal for this draft. Cheers, Xavier From oran@cisco.com Tue May 26 05:57:33 2009 Return-Path: <oran@cisco.com> X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BD733A6B65 for <avt@core3.amsl.com>; Tue, 26 May 2009 05:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.582 X-Spam-Level: X-Spam-Status: No, score=-6.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Duq-4DUTSN5 for <avt@core3.amsl.com>; Tue, 26 May 2009 05:57:24 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 6F87E3A67D4 for <avt@ietf.org>; Tue, 26 May 2009 05:57:24 -0700 (PDT) X-Files: PGP.sig : 195 X-IronPort-AV: E=Sophos;i="4.41,251,1241395200"; d="sig'?scan'208";a="190183563" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 26 May 2009 12:57:15 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n4QCvFsd014646 for <avt@ietf.org>; Tue, 26 May 2009 05:57:15 -0700 Received: from stealth-10-32-245-158.cisco.com (stealth-10-32-245-158.cisco.com [10.32.245.158]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n4QCv5Wc003040 for <avt@ietf.org>; Tue, 26 May 2009 12:57:15 GMT Received: from [127.0.0.1] by stealth-10-32-245-158.cisco.com (PGP Universal service); Tue, 26 May 2009 08:57:15 -0400 X-PGP-Universal: processed; by stealth-10-32-245-158.cisco.com on Tue, 26 May 2009 08:57:15 -0400 Message-Id: <E13B83ED-3245-435E-AA4F-E9DBA0BCE741@cisco.com> From: David R Oran <oran@cisco.com> To: Xavier Marjou <xavier.marjou@orange-ftgroup.com> In-Reply-To: <458913680905260543h295c380ate312c7efe055534d@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 26 May 2009 08:57:00 -0400 References: <001701c9dca0$bd465130$37d2f390$%roni@huawei.com> <458913680905260543h295c380ate312c7efe055534d@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) X-PGP-Encoding-Format: MIME X-PGP-Encoding-Version: 2.0.2 Content-Type: multipart/signed; boundary="PGP_Universal_AA89FC3B_6635A36E_00851F1F_BB48810E"; protocol="application/pgp-signature"; micalg="pgp-sha1" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3353; t=1243342635; x=1244206635; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:=20David=20R=20Oran=20<oran@cisco.com> |Subject:=20Re=3A=20[AVT]=20RTP=20unicast=20address=20for=2 0retransmssion=20of=20multicast=20sesssion=20=20or=20using=2 0RTCP=20to=20negotitaion=20of=20RTP=20adddresses |Sender:=20; bh=uTyxZt5VdRe7yO9PDT6eIY1Jg6TW+VzZntjFpejSeXs=; b=OMVLfuQdgbMIJhfuJSnx0lR1J9dkINRtrpsBR5iwYc/dL/xZ8OjH7Ae6nk UcENnbled1a7s9SivYs5cRJ0GStmgW586HRkrr2C04Txp4lYTnLej1jCR3o4 2qEfEa+2Yj; Authentication-Results: sj-dkim-3; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: avt@ietf.org, Roni Even <Even.roni@huawei.com> Subject: Re: [AVT] RTP unicast address for retransmssion of multicast sesssion or using RTCP to negotitaion of RTP adddresses X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group <avt.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/avt> List-Post: <mailto:avt@ietf.org> List-Help: <mailto:avt-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 26 May 2009 12:57:33 -0000 --PGP_Universal_AA89FC3B_6635A36E_00851F1F_BB48810E Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On May 26, 2009, at 8:43 AM, Xavier Marjou wrote: > Hi, > >> The problem we encounter is that this retransmission stream is >> flowing from >> the retransmission server to the receiver who may be behind a FW/ >> NAT. The >> simple case is if the RTP and RTCP streams are multiplexed on the >> RTCP port >> since in this case there is an RTCP message going from the receiver >> to the >> retransmission server which will open a pin hole in the NAT/FW >> enabling RTP >> to flow back to the receiver (Will need some keep alive mechanism) >> >> The case we are trying to discuss here is when we want to have a >> separate >> RTP channel (not multiplexed with RTCP). In this case we will need >> some >> mechanism to convey an address from the receiver to the >> retransmission >> server. > > My undertsanding is that this problem (RTP packets can not traverse a > NAT from the public side to the private side) was tackled by the avt > wg and solved by the draft-ietf-avt-rtp-and-rtcp-mux. Why this > solution would now not be used for the rapid-acquisition draft? Is > there anything missing in rtp-and-rtcp-mux? > This reduces the problem from 2 ports to 1, but doesn't eliminate it. The core problem is that retransmission (and RAMS) are on a separate RTP session which does not exist until an action on a different session (the SSM session in the case of unicast repair of multicast sessions or RAMS) occurs. Since the initial packets of the retransmission session go through the NAT outside->inside, the server has no idea what the public port is to send the packets to unless it is told, either in advance, or as part of the NAK/RAMS operation. See my earlier message for some more thoughts on the subject. > >> >> We would like to ask if this should be part of RAMS or do we want a >> general >> RTCP message to covey such information. >> >> We would like to get some other scenarios not for RAMS that have >> similar >> requirements. > > If there's addional work on "yet" another NAT traversal solution, I > anticipate that we'll end up with additional bandwidth and delays with > solutions like "symmetric+keepalive rtp", "tunnelling protocol", or > "upnp", which will reduce the optimization expected from the > rapid-acquisition draft. > Right - this is why it's tricky. The stuff we (Cisco) have deployed today uses a non-standard RTCP method to communicate the pubic port for the unicast session. It works well, but it may be we can do better by putting our heads together. > So my opinion is to keep it simple by mandating rtp-rtcp-mux only and > avoid any new work related to NAT traversal for this draft. > Ah, if only that alone would solve the problem! > Cheers, > Xavier --PGP_Universal_AA89FC3B_6635A36E_00851F1F_BB48810E Content-Type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig Content-Disposition: attachment; filename=PGP.sig -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.10.0 (Build 500) iQA/AwUBShvnJI1mhLZU3SrmEQLe1ACg36kj+epDuuOwMETmhX8Blj6zkykAnRVH FBuD7+22TmlCI9/dZm5Eey9E =XHIV -----END PGP SIGNATURE----- --PGP_Universal_AA89FC3B_6635A36E_00851F1F_BB48810E-- From Even.roni@huawei.com Tue May 26 07:43:12 2009 Return-Path: <Even.roni@huawei.com> X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 196593A70A7 for <avt@core3.amsl.com>; Tue, 26 May 2009 07:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.306 X-Spam-Level: X-Spam-Status: No, score=0.306 tagged_above=-999 required=5 tests=[AWL=0.801, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K54oPHpV69vY for <avt@core3.amsl.com>; Tue, 26 May 2009 07:43:11 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 0A3B728C234 for <avt@ietf.org>; Tue, 26 May 2009 07:41:51 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KK900KFYA7SD1@szxga02-in.huawei.com> for avt@ietf.org; Tue, 26 May 2009 22:43:04 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KK900CYMA7SHJ@szxga02-in.huawei.com> for avt@ietf.org; Tue, 26 May 2009 22:43:04 +0800 (CST) Received: from windows8d787f9 (bzq-79-182-101-49.red.bezeqint.net [79.182.101.49]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KK900I2EA7FB8@szxml01-in.huawei.com>; Tue, 26 May 2009 22:43:04 +0800 (CST) Date: Tue, 26 May 2009 17:41:57 +0300 From: Roni Even <Even.roni@huawei.com> In-reply-to: <47FF3BB2-82FA-4601-920A-CE1DBB466994@cisco.com> To: 'David R Oran' <oran@cisco.com>, 'Colin Perkins' <csp@csperkins.org> Message-id: <008801c9de10$27420190$75c604b0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: Acnd/nMkmDrJRnCbReqSgWKToZGDDgAEXJ9Q References: <001701c9dca0$bd465130$37d2f390$%roni@huawei.com> <dcad22d80905251225h64bd303cx9de2c1698b8eaa7d@mail.gmail.com> <658E8F78-CF7D-4405-9C73-ABE2837B4E62@csperkins.org> <47FF3BB2-82FA-4601-920A-CE1DBB466994@cisco.com> Cc: avt@ietf.org, 'Marshall Eubanks' <marshall.eubanks@gmail.com> Subject: Re: [AVT] RTP unicast address for retransmssion of multicast sesssion or using RTCP to negotitaion of RTP adddresses X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group <avt.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/avt> List-Post: <mailto:avt@ietf.org> List-Help: <mailto:avt-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 26 May 2009 14:43:12 -0000 Dave, I think that we can ignore a TURN solution (or relay) since I assume that if the RTCP will work with no relay for RAMS then we will not need one for the RTP either, so port should be enough Roni -----Original Message----- From: David R Oran [mailto:oran@cisco.com] Sent: Tuesday, May 26, 2009 3:35 PM To: Colin Perkins Cc: Marshall Eubanks; Roni Even; avt@ietf.org Subject: Re: [AVT] RTP unicast address for retransmssion of multicast sesssion or using RTCP to negotitaion of RTP adddresses On May 25, 2009, at 5:08 PM, Colin Perkins wrote: > On 25 May 2009, at 20:25, Marshall Eubanks wrote: >> On Sun, May 24, 2009 at 2:51 PM, Roni Even <Even.roni@huawei.com> >> wrote: >> One of the issues discussed in Rapid Acquisition of Multicast >> RTPSessions (RAMS) has to do with the specific architecture where >> the media is sent to an announced multicast address where there is >> no offer answer negotiation between the sender and the receivers. >> In the proposed solution receivers may ask using RTCP for unicast >> retransmission of the RTP stream. The current draft has as part of >> the announcement a port number that the receiver should use to >> receive the unicast RTP stream. This port is specified by the >> retransmission server and not by the receiver and it assumes that >> the IP address will be the same as the one from where the RTCP >> message came from. >> >> >> The problem we encounter is that this retransmission stream is >> flowing from the retransmission server to the receiver who may be >> behind a FW/NAT. The simple case is if the RTP and RTCP streams are >> multiplexed on the RTCP port since in this case there is an RTCP >> message going from the receiver to the retransmission server which >> will open a pin hole in the NAT/FW enabling RTP to flow back to the >> receiver (Will need some keep alive mechanism) >> >> The case we are trying to discuss here is when we want to have a >> separate RTP channel (not multiplexed with RTCP). In this case we >> will need some mechanism to convey an address from the receiver to >> the retransmission server. >> >> >> We would like to ask if this should be part of RAMS or do we want a >> general RTCP message to covey such information. >> >> >> I would say that this should be a general RTCP message. This is a >> general technique now for getting through firewalls (rfc 5138). H. >> 460 /18 and /19 use it, ICE uses it, it should be made general for >> RTP. > > I agree that a general mechanism should be defined, rather than > something that's narrowly focussed on the RAMS problem. It's not > clear that RTCP is the right place for such an extension, though. > RTCP has focussed on media level issues to date, leaving transport > layer configuration to protocols like STUN. This seems like more of > a STUN extension, than something that should be in RTCP. > Possibly. We considered just relying on STUN (you need something like it anyway to force open the ports), but there are two issues: 1. The need to keep state on the server side, which potentially opens up state-based attacks, if you want to open up the ports "in advance" and then use them later (for retransmission). 2. An extra round trip during the critical path for RAMS unless we can find a way to piggyback both STUN and RTCP on a single datagram. It might be "interesting" to see if there's a way to in fact piggyback STUN and RTCP in a single UDP packet. That leaves the questions around TURN that Roni raised for the case where both hosts are behind NATs. I'm somewhat at a loss to think of an efficient scheme for that case; given that TURN needs rendezvous state anyway and may need to be set up in advance, I'm afraid the extra round trip is unavoidable in that case and we might as well use ICE. DaveO. > -- > Colin Perkins > http://csperkins.org/ > > > From singer@apple.com Tue May 26 10:01:51 2009 Return-Path: <singer@apple.com> X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B4553A6A62 for <avt@core3.amsl.com>; Tue, 26 May 2009 10:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.022 X-Spam-Level: X-Spam-Status: No, score=-104.022 tagged_above=-999 required=5 tests=[AWL=-1.212, BAYES_05=-1.11, MANGLED_TEXT=2.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVsXOwgiLuAL for <avt@core3.amsl.com>; Tue, 26 May 2009 10:01:50 -0700 (PDT) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 992103A68FF for <avt@ietf.org>; Tue, 26 May 2009 10:01:50 -0700 (PDT) Received: from relay16.apple.com (relay16.apple.com [17.128.113.55]) by mail-out3.apple.com (Postfix) with ESMTP id EAC9F62062EC for <avt@ietf.org>; Tue, 26 May 2009 10:03:14 -0700 (PDT) Received: from relay16.apple.com (unknown [127.0.0.1]) by relay16.apple.com (Symantec Brightmail Gateway) with ESMTP id D8AB55A0002; Tue, 26 May 2009 10:03:14 -0700 (PDT) X-AuditID: 11807137-a9570bb00000380b-28-4a1c20d26b80 Received: from [10.0.1.8] (singda.apple.com [17.202.35.52]) by relay16.apple.com (Apple SCV relay) with ESMTP id 7993D558003; Tue, 26 May 2009 10:03:14 -0700 (PDT) Mime-Version: 1.0 Message-Id: <p06240813c641cfd17a61@[10.0.1.8]> Date: Tue, 26 May 2009 10:02:36 -0700 To: avt@ietf.org From: David Singer <singer@apple.com> Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Brightmail-Tracker: AAAAAA== Cc: http-live-streaming-review@group.apple.com Subject: Re: [AVT] iPhone streaming Internet-Draft posted X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group <avt.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/avt> List-Post: <mailto:avt@ietf.org> List-Help: <mailto:avt-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 26 May 2009 17:01:51 -0000 Hi Alex thanks for the helpful comments... On May 20, 2009, at 8:50 AM, Alex Giladi wrote: >A few of questions regarding the RFC: > >3. >* Is there some sort of a standardized definition of M3U you are >referencing? There is a reference [M3U], which is a link to Wikipedia, >which, in turn, is a moving target. We're using that definition. We do not know of a better specification. It is an informal standard, which is why the Internet-Draft specifies it as well. >3.1.7. EXT-X-STREAM-INF > >* What are the requirements on the MPEG-2 TS/PES here? Is PMT >expected to be in each file, or do you convey the relevant information >separately? We recommend putting PAT/PMT at the start of each segment. >* Why do you need to specify the codecs separately, if they are >already conveyed in the stream? The codecs are specified so that a client can reject the stream without reading the media files. We want to allow providers to create a single playlist for clients with different capabilities. >4. >* E.g. in case of H.264, do you require SPS/PPS/SEI's in the >beginning of each file, or only in the beginning of time? If the >latter is correct, how do you start playing from an offset? We recommend SPS/PPS/SEI along with each IDR frame. We recommend at least 1 IDR frame in a segment. This allows clients to join the stream at any segment. >Otherwise, >why these parameters cannot change (e.g. switch from 30000/1001 to >24000/1001)? What is the definition of "consistent parameters" in this >case? Section 4 refers to consistent encoding parameters within a single variant stream, such as resolution and profile. Video frame rate is an exception since clients can handle a change without reinitializing the decoder. >6.1.3. Providing variant streams >* Does this mean that PTS values need to match in all variant >streams? What happens in case of different frame rates? All variant streams must share the same timeline, but video frames do not have to line up exactly. We're planning to revise the Internet-Draft to loosen the language somewhat: "Matching content in variant streams MUST have matching timestamps. This allows clients to synchronize the streams." (And thanks for your questions generally - they suggest a number of places we need to tweak the Internet-Draft.) -- David Singer Multimedia Standards, Apple Inc. From xavier.marjou@gmail.com Wed May 27 00:38:29 2009 Return-Path: <xavier.marjou@gmail.com> X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E13D03A6F2A for <avt@core3.amsl.com>; Wed, 27 May 2009 00:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUy45sQurU1S for <avt@core3.amsl.com>; Wed, 27 May 2009 00:38:24 -0700 (PDT) Received: from mail-ew0-f176.google.com (mail-ew0-f176.google.com [209.85.219.176]) by core3.amsl.com (Postfix) with ESMTP id 4AC223A6E5F for <avt@ietf.org>; Wed, 27 May 2009 00:38:24 -0700 (PDT) Received: by ewy24 with SMTP id 24so4305426ewy.37 for <avt@ietf.org>; Wed, 27 May 2009 00:40:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=KbPUftuYP6xigQFDf+BQVYm6bfQZzif72/vjBNFrXhM=; b=N6OJx/bvmdViq579DPXvYJT4Gqyfm6HJFjNmJod9qYzsOetgWnsQKhDYgH4C3OLNSo cw9+6pPvHOay+qf7L93C99/mTCVwvgsW5cWP/CYjlCq/gc4Vzg0ObbRc2+FAWgAKhL2q dnsUqOW5PivaskvDaNanV/wOUMqDKfWVDPr/g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=xW1mYnkdxIRZG6CSVysT8Pf2mIJS+sIJqpLUWOZ5gvCKHMkZGuLRal+8E/eC9NmTdL 0U9/Hz4yq69NnrvJK5rJtOYAD4o4IRUP9/WHSPMwho27ISP1tkijjm7hjEd0hQIU3e1j lB6uxkaVzKxHd2s3+bsy0BIGI/mo2fgvqcqO4= MIME-Version: 1.0 Received: by 10.216.70.130 with SMTP id p2mr3550130wed.190.1243410003474; Wed, 27 May 2009 00:40:03 -0700 (PDT) In-Reply-To: <E13B83ED-3245-435E-AA4F-E9DBA0BCE741@cisco.com> References: <001701c9dca0$bd465130$37d2f390$%roni@huawei.com> <458913680905260543h295c380ate312c7efe055534d@mail.gmail.com> <E13B83ED-3245-435E-AA4F-E9DBA0BCE741@cisco.com> Date: Wed, 27 May 2009 09:40:03 +0200 Message-ID: <458913680905270040h7e823077k974ed6cf639fefba@mail.gmail.com> From: Xavier Marjou <xavier.marjou@gmail.com> To: David R Oran <oran@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: avt@ietf.org, Roni Even <Even.roni@huawei.com> Subject: Re: [AVT] RTP unicast address for retransmssion of multicast sesssion or using RTCP to negotitaion of RTP adddresses X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group <avt.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/avt> List-Post: <mailto:avt@ietf.org> List-Help: <mailto:avt-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 27 May 2009 07:38:30 -0000 On Tue, May 26, 2009 at 2:57 PM, David R Oran <oran@cisco.com> wrote: > > On May 26, 2009, at 8:43 AM, Xavier Marjou wrote: > >> Hi, >> >>> The problem we encounter is that this retransmission stream is flowing >>> from >>> the retransmission server to the receiver who may be behind a FW/NAT. The >>> simple case is if the RTP and RTCP streams are multiplexed on the RTCP >>> port >>> since in this case there is an RTCP message going from the receiver to >>> the >>> retransmission server which will open a pin hole in the NAT/FW enabling >>> RTP >>> to flow back to the receiver (Will need some keep alive mechanism) >>> >>> The case we are trying to discuss here is when we want to have a separate >>> RTP channel (not multiplexed with RTCP). In this case we will need some >>> mechanism to convey an address from the receiver to the retransmission >>> server. >> >> My undertsanding is that this problem (RTP packets can not traverse a >> NAT from the public side to the private side) was tackled by the avt >> wg and solved by the draft-ietf-avt-rtp-and-rtcp-mux. Why this >> solution would now not be used for the rapid-acquisition draft? Is >> there anything missing in rtp-and-rtcp-mux? >> > This reduces the problem from 2 ports to 1, but doesn't eliminate it. The > core problem is that retransmission (and RAMS) are on a separate RTP session > which does not exist until an action on a different session (the SSM session > in the case of unicast repair of multicast sessions or RAMS) occurs. Since > the initial packets of the retransmission session go through the NAT > outside->inside, the server has no idea what the public port is to send the > packets to unless it is told, either in advance > I better understand now. However even with 2 sessions, rtp-rtcp-mux can still make it work; The RTP packets for retransmission should have associated RTCP packets as well. If rtp-rtcp-mux is used, a first RTCP packet can be sent from the RR to the RS, which will "naturally" open the NAT pin-hole for the retransmission packets RTP. From hishigh@gmail.com Wed May 27 04:14:29 2009 Return-Path: <hishigh@gmail.com> X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0516528C12C for <avt@core3.amsl.com>; Wed, 27 May 2009 04:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.656 X-Spam-Level: X-Spam-Status: No, score=-1.656 tagged_above=-999 required=5 tests=[AWL=0.942, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEDLn+DqClLQ for <avt@core3.amsl.com>; Wed, 27 May 2009 04:14:28 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by core3.amsl.com (Postfix) with ESMTP id 318413A703D for <avt@ietf.org>; Wed, 27 May 2009 04:14:28 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so4639015yxb.49 for <avt@ietf.org>; Wed, 27 May 2009 04:15:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=RxWsQ6FotA5pd1rhNSg59zDbg+MjUcjUoFUsjjVZUgc=; b=QpdHk+xxsp1lUUwXIp9weOxbRQqleiglOveAk91wIcwrV2S0T1cGp2fpT5fy4+JRYm 8eSOwyP09RIk/FDDwqWkRWYDU5vyhFAyhRt2focCgSpDNJthDaxwoNVeNtY//9CUA9oO nHd0a7RKTAiIxL3cM/ny1RUFT90qISNoUfwTA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Sini2zWgz4QCnxq/y8CaIQvksa/yv67pSiBrpnYXrqWPiVT4JjGnQuHtiNLplF81vt eGcbUYlzZlb01S2KD9u7rcp+yn1mxMjSGkj/JLVwTFbjIX0XH6udXSk79j4wAzHI7uiZ oqHJdid3KE/XUzLFrVpjBuIeRyv7hf0IyPCdQ= MIME-Version: 1.0 Received: by 10.151.98.17 with SMTP id a17mr18857053ybm.302.1243422618084; Wed, 27 May 2009 04:10:18 -0700 (PDT) Date: Wed, 27 May 2009 19:10:18 +0800 Message-ID: <8bd755250905270410t448cfb55w4f38815f67fed224@mail.gmail.com> From: yunfei zhang <hishigh@gmail.com> To: avt@ietf.org Content-Type: multipart/alternative; boundary=001517510b0e74e7ca046ae2e314 Subject: [AVT] problem statement of peer to peer streaming protocol(PPSP) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group <avt.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/avt> List-Post: <mailto:avt@ietf.org> List-Help: <mailto:avt-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 27 May 2009 11:14:29 -0000 --001517510b0e74e7ca046ae2e314 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,all, I have submitted problem statement draft of peer to peer streaming protocol(PPSP)to IETF website in the following link.(http://www.ietf.org/internet-drafts/draft-zhang-ppsp-problem-statement-03.txt) <http://www.ietf.org/internet-drafts/draft-zhang-ppsp-problem-statement-03.txt> which may related to AVT WG.Any comments and suggestions are highly welcome. The abstract is as follows: We propose to develop an open peer-to-peer (P2P) streaming protocol named PPSP. This document describes the problems related to PPSP and outlines considerations that have to be taken in account when arriving at equitable solutions. BR Yunfei --001517510b0e74e7ca046ae2e314 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable <div>Hi,all,</div> <div>    I have <font face=3D"Verdana" size=3D"2">submitted = problem statement draft of peer to peer streaming protocol(PPSP)to IETF web= site in the following link.(</font><a href=3D"http://www.ietf.org/internet-= drafts/draft-zhang-ppsp-problem-statement-03.txt"><font face=3D"Verdana" si= ze=3D"2">http://www.ietf.org/internet-drafts/draft-zhang-ppsp-problem-state= ment-03.txt) </font></a><font face=3D"Verdana" size=3D"2"> which may r= elated to AVT WG.Any comments and suggestions are highly welcome.</font>=20 <div><font face=3D"Verdana" size=3D"2">      = The abstract is as follows:</font></div> <div> <p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 12pt 21.6pt"><font face=3D"= Verdana"><font size=3D"2"><span lang=3D"EN-US">We propose to develop an ope= n peer-to-peer (</span><span lang=3D"EN-US" style=3D"FONT-FAMILY: =CB=CE=CC= =E5; mso-fareast-language: ZH-CN">P2P)</span><span lang=3D"EN-US"> streamin= g protocol named PPSP. This document describes the problems related to PPSP= and outlines considerations that have to be taken in account when arriving= at equitable solutions.</span></font></font></p> <p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 12pt 21.6pt"><font face=3D"= Verdana"><font size=3D"2"><span lang=3D"EN-US"></span></font></font> <= /p> <p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 12pt 21.6pt"><font face=3D"= Verdana"><font size=3D"2"><span lang=3D"EN-US">    &nbs= p;     BR</span></font></font></p> <p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 12pt 21.6pt"><font face=3D"= Verdana"><font size=3D"2"><span lang=3D"EN-US">    &nbs= p;         Yunfei</span></font></fo= nt></p></div></div> --001517510b0e74e7ca046ae2e314-- From Even.roni@huawei.com Wed May 27 10:32:22 2009 Return-Path: <Even.roni@huawei.com> X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F0463A69D5 for <avt@core3.amsl.com>; Wed, 27 May 2009 10:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.437 X-Spam-Level: X-Spam-Status: No, score=0.437 tagged_above=-999 required=5 tests=[AWL=-0.928, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXVXHdkw7UkJ for <avt@core3.amsl.com>; Wed, 27 May 2009 10:32:21 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 26DF53A6452 for <avt@ietf.org>; Wed, 27 May 2009 10:32:21 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KKB002P0C3LMV@szxga02-in.huawei.com> for avt@ietf.org; Thu, 28 May 2009 01:18:58 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KKB006FIC3LUL@szxga02-in.huawei.com> for avt@ietf.org; Thu, 28 May 2009 01:18:57 +0800 (CST) Received: from windows8d787f9 (bzq-79-176-123-93.red.bezeqint.net [79.176.123.93]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KKB007MVC3E04@szxml02-in.huawei.com> for avt@ietf.org; Thu, 28 May 2009 01:18:57 +0800 (CST) Date: Wed, 27 May 2009 20:18:00 +0300 From: Roni Even <Even.roni@huawei.com> To: avt@ietf.org Message-id: <013c01c9deef$1b9a8030$52cf8090$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_9lz+v7CCWbIS6PN0uzYL7Q)" Content-language: en-us Thread-index: Acne7xW3/Z+Bre4SQRiiCTiGbfVmng== Subject: [AVT] comments on draft-mcgrew-srtp-ekt-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group <avt.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/avt> List-Post: <mailto:avt@ietf.org> List-Help: <mailto:avt-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 27 May 2009 17:32:22 -0000 This is a multipart message in MIME format. --Boundary_(ID_9lz+v7CCWbIS6PN0uzYL7Q) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, I read the draft and think it would be very useful. I have some comments 1. RFC 5117 describes the different multi endpoints topologies. I suggest that this draft should reference it and maybe update RFC 5117 mostly with regards to section 5 (security consideration) of the topologies. Section 5 concludes that mixer or translators need to be part of the security context. Is there a case that EKT make it possible to reduce this requirement. The text in the important note in section 3.5.1 discourage using EKT for RTP transport translators. 2. Section 7 suggests using RTP transport if RTCP is not available. RTCP is not optional part of the protocol so I think this section should not be part of the draft. 3. Section 3.7 "Finally, subsequent offer/answer exchanges MUST NOT remap a given SPI value to a different EKT parameter set until 2^32 other mappings have been used within the SRTP session." SPI is 16 bit according to figure 1. Thanks Roni Even --Boundary_(ID_9lz+v7CCWbIS6PN0uzYL7Q) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT <html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv=Content-Type content="text/html; charset=us-ascii"> <meta name=Generator content="Microsoft Word 12 (filtered medium)"> <style> <!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Consolas; panose-1:2 11 6 9 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p.MsoPlainText, li.MsoPlainText, div.MsoPlainText {mso-style-priority:99; mso-style-link:"Plain Text Char"; margin:0in; margin-bottom:.0001pt; font-size:10.5pt; font-family:Consolas;} p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {mso-style-priority:34; margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:.5in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} span.EmailStyle17 {mso-style-type:personal-compose; font-family:"Calibri","sans-serif"; color:windowtext;} span.PlainTextChar {mso-style-name:"Plain Text Char"; mso-style-priority:99; mso-style-link:"Plain Text"; font-family:Consolas;} .MsoChpDefault {mso-style-type:export-only;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.25in 1.0in 1.25in;} div.Section1 {page:Section1;} /* List Definitions */ @list l0 {mso-list-id:504785115; mso-list-type:hybrid; mso-list-template-ids:-103093404 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;} @list l0:level1 {mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} @list l1 {mso-list-id:1970743413; mso-list-type:hybrid; mso-list-template-ids:-103093404 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;} @list l1:level1 {mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} ol {margin-bottom:0in;} ul {margin-bottom:0in;} --> </style> <!--[if gte mso 9]><xml> <o:shapedefaults v:ext="edit" spidmax="1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext="edit"> <o:idmap v:ext="edit" data="1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=EN-US link=blue vlink=purple> <div class=Section1> <p class=MsoNormal>Hi,<o:p></o:p></p> <p class=MsoNormal>I read the draft and think it would be very useful.<o:p></o:p></p> <p class=MsoNormal><o:p> </o:p></p> <p class=MsoNormal>I have some comments<o:p></o:p></p> <p class=MsoNormal><o:p> </o:p></p> <p class=MsoListParagraph style='text-indent:-.25in;mso-list:l1 level1 lfo1'><![if !supportLists]><span style='mso-list:Ignore'>1.<span style='font:7.0pt "Times New Roman"'>       </span></span><![endif]><span dir=LTR></span>RFC 5117 describes the different multi endpoints  topologies. I suggest that this draft  should reference it and maybe update RFC 5117 mostly with regards to  section 5 (security consideration) of the topologies. Section 5 concludes that mixer or translators need to be part of the security context. Is there a case that EKT make it possible to reduce this requirement. The text in the important note in section 3.5.1 discourage using EKT for RTP transport translators.<o:p></o:p></p> <p class=MsoListParagraph style='text-indent:-.25in;mso-list:l1 level1 lfo1'><![if !supportLists]><span style='mso-list:Ignore'>2.<span style='font:7.0pt "Times New Roman"'>       </span></span><![endif]><span dir=LTR></span>Section 7 suggests using RTP transport if RTCP is not available. RTCP is not optional part of the protocol so I think this section should not be part of the draft.<o:p></o:p></p> <p class=MsoListParagraph style='text-indent:-.25in;mso-list:l1 level1 lfo1'><![if !supportLists]><span style='mso-list:Ignore'>3.<span style='font:7.0pt "Times New Roman"'>       </span></span><![endif]><span dir=LTR></span>Section 3.7  "Finally, subsequent offer/answer exchanges MUST NOT remap a given SPI value to a different EKT parameter set until 2^32 other mappings have been used within the SRTP session."   SPI is 16 bit according to figure 1.<o:p></o:p></p> <p class=MsoNormal><o:p> </o:p></p> <p class=MsoNormal>Thanks<o:p></o:p></p> <p class=MsoNormal>Roni Even<o:p></o:p></p> </div> </body> </html> --Boundary_(ID_9lz+v7CCWbIS6PN0uzYL7Q)-- From yekuiwang@huawei.com Wed May 27 13:36:48 2009 Return-Path: <yekuiwang@huawei.com> X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00F533A689D for <avt@core3.amsl.com>; Wed, 27 May 2009 13:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.337 X-Spam-Level: X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJB6SXnXnusx for <avt@core3.amsl.com>; Wed, 27 May 2009 13:36:46 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id D57F83A6B46 for <avt@ietf.org>; Wed, 27 May 2009 13:36:45 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KKB008KALC3XY@usaga04-in.huawei.com> for avt@ietf.org; Wed, 27 May 2009 15:38:28 -0500 (CDT) Received: from W90946 ([10.193.125.102]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KKB008B0LBWV7@usaga04-in.huawei.com> for avt@ietf.org; Wed, 27 May 2009 15:38:27 -0500 (CDT) Date: Wed, 27 May 2009 16:38:20 -0400 From: Ye-Kui Wang <yekuiwang@huawei.com> In-reply-to: <02341470F0384C54B17D2411F9267BE7@china.huawei.com> To: 'IETF AVT WG' <avt@ietf.org> Message-id: <50292B8D4DC6498BAAB637D5DFDB2223@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acna8UQGrgzYGcgMRLK6VKOJKU4GPAAA4SpwAAoiXVAAKLJ/MADSmbwA References: <4A15046C.5080600@rogers.com> <006701c9d9e9$51679500$f436bf00$%roni@huawei.com> <7779AD69A5E54F9F84E473BB4F4E1E71@china.huawei.com> <4A157ADA.8060900@rogers.com> <ybuljopyjto.fsf@jesup.eng.wgate.com> <3221EC0396044781B11D483B77E085A1@china.huawei.com> <ybuhbzdygly.fsf@jesup.eng.wgate.com> <939A5D7EEE0A410E867078A3117DD3CE@china.huawei.com> <ybuhbzdb1tr.fsf@jesup.eng.wgate.com> <0F4BC54357284559B31303B0D730F7E2@china.huawei.com> <027101c9db1f$a9842a50$fc8c7ef0$%roni@huawei.com> <02341470F0384C54B17D2411F9267BE7@china.huawei.com> Subject: Re: [AVT] Consensus on profile-level-id in 3984bis X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group <avt.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/avt> List-Post: <mailto:avt@ietf.org> List-Help: <mailto:avt-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 27 May 2009 20:36:48 -0000 Can we conclude the consensus on this issue to be something similar as Tom suggested? BR, YK > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > Behalf Of Ye-Kui Wang > Sent: Saturday, May 23, 2009 12:08 PM > To: 'Roni Even'; 'Randell Jesup' > Cc: 'Tom Taylor'; 'IETF AVT WG' > Subject: Re: [AVT] Consensus on profile-level-id in 3984bis > > > Roni, > > > I think I mentioned before that the offer can offer a low level and > > add capabilities using the optional parameters, this working point > > will be between two specified levels from table A-1, higher > than the > > one in the offer but lower than the one above it. I think > that in this > > case if the answer will include the higher level this will > still work, > > and since the encoder is flexible it may take advantage of the new > > information. > > Those max-* parameters may only be used to indicate receiver > capabilities not anything else. That is, an offerer or > answerer may add extra capabilities than the included level > for receiving capabilities, but not for sending. > > BR, YK > > > -----Original Message----- > > From: Roni Even [mailto:Even.roni@huawei.com] > > Sent: Friday, May 22, 2009 4:55 PM > > To: 'Ye-Kui Wang'; 'Randell Jesup' > > Cc: 'Tom Taylor'; 'IETF AVT WG' > > Subject: RE: [AVT] Consensus on profile-level-id in 3984bis > > > > YK, > > I think you are right that we are now to the root of the > discussion. > > The levels in H.264 annex A specify some compromise in > order to allow > > mass production devices like set top boxes use fixed > architecture for > > example in order to define the frame buffer size on the device and > > typically will not negotiate the level (mostly streaming > > applications). On the other side video conferencing systems > have much > > more flexibility and control over the encoder since they > are part of a > > system that considers also the display and network connection when > > they offer a specific level (which may be lower than the > maximum that > > they can support). Having more control on the encoder > allows them to > > get requests from the remote system to send pictures at specific > > resolutions and aspect ratios. I think I mentioned before that the > > offer can offer a low level and add capabilities using the optional > > parameters, this working point will be between two specified levels > > from table A-1, higher than the one in the offer but lower than the > > one above it. I think that in this case if the answer will > include the > > higher level this will still work, and since the encoder is > flexible > > it may take advantage of the new information. > > > > Roni > > > > -----Original Message----- > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > Behalf Of > > Ye-Kui Wang > > Sent: Friday, May 22, 2009 8:10 PM > > To: 'Randell Jesup' > > Cc: 'Tom Taylor'; 'IETF AVT WG' > > Subject: Re: [AVT] Consensus on profile-level-id in 3984bis > > > > > > I think the root of most of the disputes is, given a video encoder, > > whether you can label it with a max level. In theory, I > think you are > > right that, given the computing resource of the encoder, it is > > possible to compromise among parameters. However, in practice, when > > you get an encoder product (which is typically optimized or > even fixed > > for certain operating range), it would typically be labelled with a > > profile at a level, and it should not be common that users (of the > > encoder product) would try to compromise among parameters and see > > whether it can produce a bitstream with a higher level, and in many > > cases, the encoder product does not provide enough space > for you play > > around this. The level labelled by the encoder manufacture > is usually > > the max level. > > There are of course also purely PC software based encoders > can be very > > flexible, and can be configured to be almost any profile and level. > > But once it is configured to be at a profile and a level and the > > encoder is initialized, then that level should be used as the max > > level. > > > > BR, YK > > > > > -----Original Message----- > > > From: Randell Jesup [mailto:rjesup@wgate.com] > > > Sent: Friday, May 22, 2009 11:22 AM > > > To: Ye-Kui Wang > > > Cc: 'Tom Taylor'; 'IETF AVT WG' > > > Subject: Re: [AVT] Consensus on profile-level-id in 3984bis > > > > > > Ye-Kui Wang <yekuiwang@huawei.com> writes: > > > >> Ye-Kui Wang <yekuiwang@huawei.com> writes: > > > >> >If the following are considered, then let the other > > side know the > > > >> >sending capability (as well as whether level upgrade is > > allowed) > > > >> >would be very useful. > > > >> > > > > >> >- One may want to request a specific mode, e.g. a spatial > > > >> >resolution, from the sender, for example by using image > > attribute > > > >> >mmusic draft. > > > >> > > > >> Does adding a max-send-level actually help you there? > > > > > > > >Yes. > > > > > > > >> How does this interact with how you decide what your > max sending > > > >> level is? > > > > > > > >You don't decide your max sending level, your max sending > > > level is your > > > >max sending capability, a hard capability limit of you. > > > > > > Max capability for what/which? For all parameters simultaneously? > > > Maximum bitrate at maximum framesize at maximum > macroblocks/second, > > > with maximum frame-to-frame motion, with maximum > > > motion-estimation-search, etc? > > > > > > I'm not saying you can't choose a maximum, but it's very, > > very soft - > > > very subjective because encoding is much more variable (and > > expensive) > > > than decoding. It's (much) easier to estimate a worst-case for > > > decode. > > > > > > >> As mentioned below, choosing a value for that (other than > > > basing it > > > >> on resolution alone, and that just might put a lower bound > > > on it) is > > > >> extremely subjective at best. > > > > > > > >Example: If one side lets the other side know its max sending > > > >capability, then the other side would not even try to request a > > > >specific capability that is impossible to be satisfied. > > > Otherwise, the > > > >other side may just send useless requests. > > > > > > > >> >- Video adaptation, in terms of bitrate, frame rate, > > > and/or spatial > > > >> >resolution etc, may happen during the session, and may be > > > initiated > > > >> >by either side. > > > >> > > > >> Again, how would this work in practice, and how would > > > adding it here > > > >> help? Adaptation within the negotiated limits can occur > > now, so I > > > >> don't see the advantage here. If you need to change the > > > maximum limits (why? > > > >> weren't they properly negotiated to start with?), then you can > > > >> re-invite. I think we need a concrete example, in order > > > to know if > > > >> what you're proposing is sufficient - or if it works. > I'm quite > > > >> unclear on how you believe specifying a max send level > will help > > > >> anything, since your list is quite vague. > > > >> > > > > > > > >Example > > > > > > > >The offerer does not tell the answerer its max sending > capability, > > > >which is level B. A negotiation is done, where the > answer includes > > > >level C (C>B), and the offerer starts to send at C (actually > > > B, but the > > > >answerer may not be sure). After a while, the answerer > > > senses that the > > > >connecting bandwidth is higher, and it wants to receive at > > a higher > > > >bitrate, which is still within the limit of level C, but > above the > > > >limit of B, and sends a meaningless adaption request using > > re-invite. > > > > > > > >However, if the offerer does tell the answerer its max sending > > > >capability, such meaningless adaption requests are avoided. > > > I believe > > > >there are more examples, but I hope this already helps. > > > > > > That's a plausible case - thanks. However, I think you > > could have an > > > unintended result if you did that. Lets say that the > > offerer uses the > > > "worst-case" method to decide on a max-send-level (per > > above). That > > > level may be well below the limits it could hit when it's > not worst > > > case - for example, it may be constrained on framesize or MBPS to > > > level 3.0, but can handle the outgoing bandwidth of level > 4.0, and > > > level 5.0 when other parameters aren't worst-case. By > > limiting to a > > > max-send-level of 3.0, the receiver won't request use of extra > > > bandwidth or 4.0 or 5.0. Note that even if you go and > > duplicate all > > > the max-* parameters as sprop-max-*, you still wouldn't > be able to > > > handle the "I can do this when other parameters are relaxed" case. > > > > > > I also already mentioned this problem below (repeated here): > > > >> >> The question is "is it worth it"? Also, while this > > may let you > > > >> >> limit resources, you may also limit the options of > the sender. > > > >> >> For example, in the first case above, since A knows B > > > can receive > > > >> >> 5.0, A could send a higher frame size than 3.0 supports > > > (perhaps > > > >> >> at a lower framerate), even though A can't support > > > sending "full" level 3.1. > > > > > > I think you can handle the adaptation issue as part of the > > adaptation > > > design, since there may be other reasons the offerer can't > > raise the > > > bandwidth (or whatever). > > > > > > >BR, YK > > > > > > > > > > > >> >BR, YK > > > >> > > > > >> >> -----Original Message----- > > > >> >> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] > > > >> On Behalf Of > > > >> >> Randell Jesup > > > >> >> Sent: Thursday, May 21, 2009 10:04 PM > > > >> >> To: Tom Taylor > > > >> >> Cc: IETF AVT WG > > > >> >> Subject: Re: [AVT] Consensus on profile-level-id in 3984bis > > > >> >> > > > >> >> Tom Taylor <tom.taylor@rogers.com> writes: > > > >> >> >It appears that the optimum outcome is to be able to signal > > > >> >> both send > > > >> >> >and receive capability. The legacy approach loses > > some of this > > > >> >> >information, since profile-level-id contains the lesser > > > >> of the two > > > >> >> >values. In a legacy-new interworking situation it seems > > > >> >> unlikely that > > > >> >> >we can improve on this. > > > >> >> > > > >> >> Well, I'm not sure you can say that a legacy device > > > >> definitively uses > > > >> >> the lesser of send/receive in profile-level-id. Because > > > >> of the way > > > >> >> profile-level-id works, and how H.264 encodes streams, > > > there is no > > > >> >> problem with currently specifying a level above what you > > > >> can "truly" > > > >> >> support *sending*. I.e. you can say you can receive and > > > >> send level > > > >> >> 3.0 via profile-level-id, but nothing forces you to use > > > the full > > > >> >> limits of level 3.0 when sending. You can send a stream > > > >> that could > > > >> >> be encoded identically in level 2.0; you can even mark > > > it as level > > > >> >> 3.0 in the SPS/PPS NAL units. > > > >> >> > > > >> >> On the other side of the equation, it is the lesser - if > > > >> you can only > > > >> >> receive level 2.0 when all the limits in the received > > > stream are > > > >> >> maxed out, you can't use anything above level 2.0 in > > > >> >> profile-level-id. (You can > > > >> >> *extend* it (such as with max-fs), if you also agree to > > > decode the > > > >> >> extension as well.) > > > >> >> > > > >> >> Those are the *current* semantics of profile-level-id. > > > A legacy > > > >> >> device may (or may not) as mentioned over-state it's > > ability to > > > >> >> encode. > > > >> >> > > > >> >> You could use an parameter that specifies the max > > sending level > > > >> >> supported in an offer (there's no point in an answer I > > > >> believe). I > > > >> >> originally proposed this. However, on reflection, > > there's very > > > >> >> little if anything to gain from that that I can see. A > > > receiver > > > >> >> could respond to > > > >> >> level-upgrade-allowed=1 (or > > level-asymmetry-allowed=1) with the > > > >> >> highest level it can receive. Now each side knows the > > > >> highest level > > > >> >> the other can receive, and can send up to that level. > > The only > > > >> >> downside I can possibly think of to not knowing the > > > >> maximum sending > > > >> >> ability is that a receiver could perhaps not > allocate as many > > > >> >> resources if it knew the offerer couldn't send > above level N. > > > >> >> Example: > > > >> >> > > > >> >> A: Can receive level 2.0 (small LCD perhaps), can > > send level 3.0 > > > >> >> B: Can receive level 5.0, can send level 3.0 (more > > > common form of > > > >> >> send/recv > > > >> >> asymmetry) > > > >> >> > > > >> >> A offers to be with > > > >> profile-level-id=420014;level-asymmetry-allowed=1 > > > >> >> B answers with profile-level-id=420032 > > > >> >> > > > >> >> A will send at level 3.0 > > > >> >> B will send at level 2.0 (and must allocate resources to > > > >> potentially > > > >> >> receive 5.0) > > > >> >> > > > >> >> If you had a maximum-send-level parameter: > > > >> >> > > > >> >> A offers to be with > profile-level-id=420014;sprop-max-level=1E > > > >> >> B answers with profile-level-id=42001E > > > >> >> > > > >> >> A will send at level 3.0 > > > >> >> B will send at level 2.0 (and only has to allocate > > > resources for > > > >> >> level 3.0) > > > >> >> > > > >> >> > > > >> >> The question is "is it worth it"? Also, while this > > may let you > > > >> >> limit resources, you may also limit the options of > the sender. > > > >> >> For example, in the first case above, since A knows B > > > can receive > > > >> >> 5.0, A could send a higher frame size than 3.0 supports > > > (perhaps > > > >> >> at a lower framerate), even though A can't support > > > sending "full" level 3.1. > > > >> >> > > > >> >> I should also note that quantizing the maximum level > > > you can send > > > >> >> is VERY subjective/arbitrary, because of how the > > > encoding works. > > > >> >> See the discussion above about how you don't have to > > > max out the > > > >> >> level you're supposedly sending. > > > >> >> > > > >> >> So my suggestion is to use level-asymmetry-allowed. > (See my > > > >> >> previous post for how this differs from > > > level-upgrade-allowed - it > > > >> >> allows asymmetric levels on level downgrade as > well, which is > > > >> >> actually probably a more common case.) > > > >> >> > > > >> >> >That suggests that profile-level-id should retain > > its current > > > >> >> >semantics, and one or two new parameters (only one of > > > >> which would be > > > >> >> >present in the offer or answer) would indicate two things: > > > >> >> >a) a value which is higher than the value given in > > > >> profile-level-id; > > > >> >> >b) whether that value is a send or receive capability. > > > >> >> > > > > >> >> >If it's just one parameter, it would have to be double > > > >> valued e.g., > > > >> >> >alternate-level-id="send,<value>". > > > >> >> > > > > >> >> >If it is two parameters, the appropriate parameter to > > > >> include would > > > >> >> >depend on which whether the capability being reported > > > is send or > > > >> >> >receive, e.g., send-level-id=<value> > > > >> >> >or recv-level-id=<value > > > >> >> >but never both in the same stream. > > > >> >> > > > > >> >> >Ye-Kui Wang wrote: > > > >> >> >> Another interoperability issue relates to the semantics > > > >> >> change of the > > > >> >> >> level part of profile-level-id. Currently, the > level part, > > > >> >> when used > > > >> >> >> capability exchange or session setup, gives the upper > > > >> >> limit of both > > > >> >> >> decoding capability and encoding capability, as seen > > > from the > > > >> >> >> following two paragraphs excerpted from the bis > draft (the > > > >> >> same in spirit in 3984): > > > >> >> >> > > > >> >> >> "The profile-level-id parameter indicates the default > > > >> sub-profile, > > > >> >> >> i.e. the subset of coding tools that may have > been used to > > > >> >> generate > > > >> >> >> the stream or that the receiver supports, and the > > > >> default level of > > > >> >> >> the stream or the receiver supports." > > > >> >> >> > > > >> >> >> "If the profile-level-id parameter is used for capability > > > >> >> exchange or > > > >> >> >> session setup procedure, it indicates the subset of > > > >> coding tools, > > > >> >> >> which is equal to the default sub-profile, and the > > > >> highest level, > > > >> >> >> which is equal to the default level, that the codec > > > >> supports. All > > > >> >> >> levels lower than the default level are also supported by > > > >> >> the codec. " > > > >> >> >> > > > >> >> >> When level upgrade is allowed, then this semantics must > > > >> >> change, such > > > >> >> >> that the level part basically indicates only the decoding > > > >> >> capability. > > > >> >> >> This change of course creates different understandings > > > >> between the > > > >> >> >> two sides whenever one is legacy and the other is new. > > > >> >> >> > > > >> >> >> We have at least the following options to go to > > > allow for level > > > >> >> >> upgrade (the semantics change above is anyway > > > needed): - To add > > > >> >> >> "level-upgrade-allowed". - To add "level-upgrade-allowed" > > > >> >> and another > > > >> >> >> parameter, say sending-capability-level, to indicate > > > >> the sending > > > >> >> >> capability expressed as a level value. - To go wildly, by > > > >> >> making all > > > >> >> >> paramters not starting with "sprop-" as receiving > > > capabilities. > > > >> >> >> Another group of parameters not starting with > > > "sprop-" can be > > > >> >> >> optionally used to indicate sending capabilities. When > > > >> >> these sending > > > >> >> >> capability parameters are not present, the sending > > > >> >> capabilities are > > > >> >> >> by default equal to the receiving capabilties. > > > >> >> >> > > > >> >> >> A decision needs to be made which one to take. > > > >> >> >> > > > >> >> >> In any case, I hope a proponent could provide relatively > > > >> >> mature text, > > > >> >> >> including changes to semantics, offer/answer rules > > > (including > > > >> >> >> parameter sets considerations in offer/answer), > > > >> declarative usage, > > > >> >> >> SDP examples, and discussion of backward > > > compatibility issues. > > > >> >> >> > > > >> >> >> Note that all the changes will also affect the > SVC payload > > > >> >> draft, as > > > >> >> >> they basically need to be appropriately integrated to the > > > >> >> SVC payload draft. > > > >> >> >> > > > >> >> >> BR, YK > > > >> >> >> > > > >> >> >... > > > >> >> >_______________________________________________ > > > >> >> >Audio/Video Transport Working Group avt@ietf.org > > > >> >> >https://www.ietf.org/mailman/listinfo/avt > > > >> >> > > > >> >> > > > >> >> -- > > > >> >> Randell Jesup, Worldgate (developers of the Ojo > > > >> videophone), ex-Amiga > > > >> >> OS team rjesup@wgate.com "The fetters imposed on liberty > > > >> at home have > > > >> >> ever been forged out of the weapons provided for > > > defence against > > > >> >> real, pretended, or imaginary dangers from abroad." > > > >> >> - James Madison, 4th US president (1751-1836) > > > >> >> > > > >> >> _______________________________________________ > > > >> >> Audio/Video Transport Working Group avt@ietf.org > > > >> >> https://www.ietf.org/mailman/listinfo/avt > > > >> >> > > > >> > > > >> > > > >> -- > > > >> Randell Jesup, Worldgate (developers of the Ojo > > > videophone), ex-Amiga > > > >> OS team rjesup@wgate.com "The fetters imposed on liberty > > > at home have > > > >> ever been forged out of the weapons provided for > defence against > > > >> real, pretended, or imaginary dangers from abroad." > > > >> - James Madison, 4th US president (1751-1836) > > > >> > > > >> > > > > > > > > > -- > > > Randell Jesup, Worldgate (developers of the Ojo > > videophone), ex-Amiga > > > OS team rjesup@wgate.com "The fetters imposed on liberty at > > home have > > > ever been forged out of the weapons provided for defence > > against real, > > > pretended, or imaginary dangers from abroad." > > > - James Madison, 4th US president (1751-1836) > > > > > > > > > > > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > > > > > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > From wwwrun@core3.amsl.com Wed May 27 15:31:33 2009 Return-Path: <wwwrun@core3.amsl.com> X-Original-To: avt@ietf.org Delivered-To: avt@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id D69273A6F81; Wed, 27 May 2009 15:31:33 -0700 (PDT) To: mcgrew@cisco.com,ekr@rtfm.com From: IETF Secretariat <ietf-ipr@ietf.org> Message-Id: <20090527223133.D69273A6F81@core3.amsl.com> Date: Wed, 27 May 2009 15:31:33 -0700 (PDT) Cc: fluffy@cisco.com, tom.taylor@rogers.com, avt@ietf.org, ipr-announce@ietf.org Subject: [AVT] Posting of IPR Disclosure related to Certicom's Statement about IPR related to RFC 4346, RFC 5246, RFC 5289, RFC 4492, RFC 2409, RFC 4306, RFC 4754, RFC 4753, RFC 4869, RFC 4253, RFC 2633, RFC 3278, RFC 4347, RFC 4366, RFC 4109, RFC 4252, RFC 3850, RFC 3851, RFC 5008, draft-ietf-tls-rfc43... X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group <avt.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/avt> List-Post: <mailto:avt@ietf.org> List-Help: <mailto:avt-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 27 May 2009 22:31:33 -0000 Dear David McGrew, Eric Rescorla: An IPR disclosure that pertains to your Internet-Draft entitled "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for Secure Real-time Transport Protocol (SRTP)" (draft-ietf-avt-dtls-srtp) was submitted to the IETF Secretariat on 2009-05-27 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1154/). The title of the IPR disclosure is "Certicom's Statement about IPR related to RFC 4346, RFC 5246, RFC 5289, RFC 4492, RFC 2409, RFC 4306, RFC 4754, RFC 4753, RFC 4869, RFC 4253, RFC 2633, RFC 3278, RFC 4347, RFC 4366, RFC 4109, RFC 4252, RFC 3850, RFC 3851, RFC 5008, draft-ietf-tls-rfc43...." The IETF Secretariat From timur.friedman@gmail.com Wed May 27 19:47:46 2009 Return-Path: <timur.friedman@gmail.com> X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B99DF3A6B71 for <avt@core3.amsl.com>; Wed, 27 May 2009 19:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[AWL=0.597, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NuL128iNRa3w for <avt@core3.amsl.com>; Wed, 27 May 2009 19:47:45 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.249]) by core3.amsl.com (Postfix) with ESMTP id 3BA9D3A6B4C for <avt@ietf.org>; Wed, 27 May 2009 19:47:45 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id c3so3659553ana.4 for <avt@ietf.org>; Wed, 27 May 2009 19:49:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type; bh=gyHQhiKktDvmtorPDgeJAVg8vNS2u/5te59M7wVmf0A=; b=QuTw44fBiJuhhfgJCamX/igRkVmNnDA3E02eD0Pyq9fsvVpEB6j37g1f2wbbgEFflb 1C0KRNRNRYaES3HPJfRujFCaISLg/DXgcYD3I8f1lLS98IPymuIT1K919d1N9yg/7Wex QpaqFBTtAmj8xNWRF+rSh1Jj90cy0dnv4fl1M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=VrWcuxQKLSaPDrHL4BuQZVip8phN1KDtWkna/ztH6MlFmUHDt6uOTOYCwG9r2QoEcl mk0pmBd+neKx75SVaQw1bGRDqd0Nwt1mhI5xEocD1i89L1xoeMK5XZEPrxHJEuI+dnsv rGs+rBAghyvqsKqj8wf8FXCw+3TyE9Y/b2a6g= MIME-Version: 1.0 Sender: timur.friedman@gmail.com Received: by 10.100.251.10 with SMTP id y10mr1363945anh.38.1243478964227; Wed, 27 May 2009 19:49:24 -0700 (PDT) In-Reply-To: <001601c9d7a4$3ce1d010$b6a57030$%roni@huawei.com> References: <5ef5d7280904222031te6b6570r2760491dafee65f@mail.gmail.com> <5ef5d7280904281216h68cda0c7p9039db4ffda7209f@mail.gmail.com> <5ef5d7280905041953v7cd824a2s19cdb325d33942a@mail.gmail.com> <5ef5d7280905151712w28c996d0v242b60144f5860f6@mail.gmail.com> <001601c9d7a4$3ce1d010$b6a57030$%roni@huawei.com> From: Timur Friedman <timur.friedman@upmc.fr> Date: Wed, 27 May 2009 19:49:04 -0700 X-Google-Sender-Auth: 3cae58fe6725a59e Message-ID: <5ef5d7280905271949r1d01d016ua1ed64ada44f3d82@mail.gmail.com> To: Roni Even <Even.roni@huawei.com> Content-Type: multipart/alternative; boundary=00163691fe65f2debc046af001b6 Cc: Nick Duffield <duffield@research.att.com>, Tom Taylor <tom.taylor@rogers.com>, "CACERES, RAMON \(ATTLABS\)" <ramon@research.att.com>, avt@ietf.org Subject: Re: [AVT] misleading RFC 3611 statement on RTCP packet stacking X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group <avt.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/avt> List-Post: <mailto:avt@ietf.org> List-Help: <mailto:avt-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 28 May 2009 02:47:46 -0000 --00163691fe65f2debc046af001b6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Roni, The original sentence in question is the first sentence in a paragraph, the overall purpose of which is to alert the reader to the potential impact of XR packets on the RTCP reporting interval. Basically, the paragraph is saying that the fact of RTCP packet stacking means that the addition of XR packets will tend to increase the average overall size of RTCP packets and thus increase the reporting interval. For this reason, Ramon, Nick and myself advocate an RFC Errata text that provides a reading of the first sentence that draws explicit attention to the fact of stacking to create compound packets. Our concern is that the word "supplement" by itself could be understood simply to mean that XR packets add to the existing set of packets, without any sense of increasing the size of a compound RTCP packet. However, taking your point that the text could be simplified, we would like to suggest the following: "XR packets supplement the existing RTCP packets to form compound RTCP packets according to RFC 3550 [9]." Timur On Mon, May 18, 2009 at 3:34 AM, Roni Even <Even.roni@huawei.com> wrote: > Hi, > > This sounds like a reasonable suggestion. You can do it this way or maybe > to make it simpler change > > > > "XR packets supplement the existing RTCP packets, and may be stacked with > other RTCP packets to form compound RTCP packets [9, Section 6]." > > > > to > > > > "XR packets supplement the existing RTCP packets according to RFC 3550[9] > > > > > > Roni Even > > > > > > > > On Tue, Apr 28, 2009 at 12:16 PM, Timur Friedman <timur.friedman@upmc.fr> > wrote: > > To follow up on our proposal to file an RFC Errata report, here, for > more direct comparison, is the RFC 3611 text immediately followed by > our suggestion for how it should be read: > > > > "XR packets supplement the existing RTCP packets, and may be stacked wi= th > > other RTCP packets to form compound RTCP packets [9, Section 6]." > > > =93XR packets supplement the existing RTCP packets, and stack with othe= r > RTCP > > packets to form compound RTCP packets, as described in Sec. 6 of RFC 35= 50 > > [9].=94 > > Timur > > > > On Wed, Apr 22, 2009 at 8:31 PM, Timur Friedman <timur.friedman@upmc.fr> > wrote: > > Some people are reading RFC 3611 as overriding RFC 3550 on RTCP packet > > stacking. > > > > This is what Sec. 1.1 of RFC 3611 says: > > > > "XR packets supplement the existing RTCP packets, and may be stacked wi= th > > other RTCP packets to form compound RTCP packets [9, Section 6]." > > > > Reference 9 is RFC 3550, which says: > > > > "all RTCP packets MUST be sent in a compound packet of at least two > > individual packets" > > > > That is, RFC 3550 says that RTCP packets MUST be stacked into a compoun= d > > packet, and some people are reading RFC 3611 as weakening that mandate = to > > say only that RTCP packets MAY be stacked into a compound packet (but > also > > MAY NOT, at least in the case of the XR packet). > > > > As one of the authors of RFC 3611, I can say that it was not my intenti= on > to > > override RFC 3550. Nor was it the intention of the two of my eight > > co-authors who I have discussed this with. Rather, the purpose of this > > sentence was to remind the reader that XR packets, like any RTCP packet= s, > > are designed to be stacked, and to helpfully point the reader to the RF= C > > 3550 section that deals with RTCP packet stacking for further details. > > > > To the best of my recollection, no discussion in AVT leading up to > approval > > of RFC 3611 indicates that any group participants at the time believed > that > > RFC 3611 would override RFC 3550 on RTCP packet stacking. > > > > Still, I understand how people are reading RFC 3611 in this way. It doe= s > say > > "may be stacked", and though "may" is not capitalized, it is nonetheles= s > an > > RFC 2119 keyword, meaning that the item is truly optional. > > > > Co-authors Nick Duffield, Ramon Caceres, and myself would like to open > > discussion on how to address this situation. We start by suggesting tha= t > we > > file an RFC Errata report, indicating that the sentence should read > instead: > > > > =93XR packets supplement the existing RTCP packets, and stack with othe= r > RTCP > > packets to form compound RTCP packets, as described in Sec. 6 of RFC 35= 50 > > [9].=94 > > > > By dropping the "may", we drop any hint that this RFC overrides the RFC > 3550 > > stacking mandate. And by adding "as described in Sec. 6 of RFC 3550" we > make > > clear the informational nature of this sentence. > > > > Timur Friedman > > > > > > > > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > > --00163691fe65f2debc046af001b6 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Roni,<br><br>The original sentence in question is the first sentence in a p= aragraph, the overall purpose of which is to alert the reader to the potent= ial impact of XR packets on the RTCP reporting interval.<br><br>Basically, = the paragraph is saying that the fact of RTCP packet stacking means that th= e addition of XR packets will tend to increase the average overall size of = RTCP packets and thus increase the reporting interval.<br> <br>For this reason, Ramon, Nick and myself advocate an RFC Errata text tha= t provides a reading of the first sentence that draws explicit attention to= the fact of stacking to create compound packets.<br><br>Our concern is tha= t the word "supplement" by itself could be understood simply to m= ean that XR packets add to the existing set of packets, without any sense o= f increasing the size of a compound RTCP packet.<br> <br>However, taking your point that the text could be simplified, we would = like to suggest the following:<br><br><div>"XR packets supplement the = existing RTCP packets=A0to form compound RTCP packets=A0according to RFC 35= 50 [9]."</div> <div><br></div>Timur<br><br><br><div class=3D"gmail_quote">On Mon, May 18, = 2009 at 3:34 AM, Roni Even <span dir=3D"ltr"><<a href=3D"mailto:Even.ron= i@huawei.com">Even.roni@huawei.com</a>></span> wrote:<br><blockquote cla= ss=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 204, 204); marg= in: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div link=3D"blue" vlink=3D"purple" lang=3D"EN-US"> <div><div class=3D"im"> <p>Hi,</p> <p>This sounds like a reasonable suggestion. You can do it this way or maybe to make it simpler change</p> <p>=A0</p> </div><p>"XR packets supplement the existing RTCP packets, and may be stacked with other RTCP packets to form compound RTCP packets [9= , Section 6]."</p> <p>=A0</p> <p>to</p><div class=3D"im"> <p>=A0</p> <p>"XR packets supplement the existing RTCP packets according to RFC 3550[9]</p> <p>=A0</p> <p>=A0</p> <p>Roni Even</p> <p><span style=3D"font-size: 11pt; color: rgb(31, 73, 125);">=A0</span></p> <p><span style=3D"font-size: 11pt; color: rgb(31, 73, 125);">=A0</span></p> </div><div> <div> <div> <p>=A0</p> <div> <p>On Tue, Apr 28, 2009 at 12:16 PM, Timur Friedman <<a href=3D"mailto:t= imur.friedman@upmc.fr" target=3D"_blank">timur.friedman@upmc.fr</a>> wrote:</p><div><div></div><div class=3D"h5"> <p>To follow up on our proposal to file an RFC Errata report, here, for<br> more direct comparison, is the RFC 3611 text immediately followed by<br> our suggestion for how it should be read:</p> <div> <p style=3D"margin-bottom: 12pt;"><br> > "XR packets supplement the existing RTCP packets, and may be stac= ked with<br> > other RTCP packets to form compound RTCP packets [9, Section 6]."= </p> </div> <div> <p style=3D"margin-bottom: 12pt;">> =93XR packets supplement the existing RTCP packets, and stack with other RTCP<br> > packets to form compound RTCP packets, as described in Sec. 6 of RFC 3= 550<br> > [9].=94</p> </div> <p><span style=3D"color: rgb(136, 136, 136);">Timur</span></p> <div> <div> <p><br> <br> On Wed, Apr 22, 2009 at 8:31 PM, Timur Friedman <<a href=3D"mailto:timur= .friedman@upmc.fr" target=3D"_blank">timur.friedman@upmc.fr</a>> wrote:<br> > Some people are reading RFC 3611 as overriding RFC 3550 on RTCP packet= <br> > stacking.<br> ><br> > This is what Sec. 1.1 of RFC 3611 says:<br> ><br> > "XR packets supplement the existing RTCP packets, and may be stac= ked with<br> > other RTCP packets to form compound RTCP packets [9, Section 6]."= <br> ><br> > Reference 9 is RFC 3550, which says:<br> ><br> > "all RTCP packets MUST be sent in a compound packet of at least t= wo<br> > individual packets"<br> ><br> > That is, RFC 3550 says that RTCP packets MUST be stacked into a compou= nd<br> > packet, and some people are reading RFC 3611 as weakening that mandate= to<br> > say only that RTCP packets MAY be stacked into a compound packet (but = also<br> > MAY NOT, at least in the case of the XR packet).<br> ><br> > As one of the authors of RFC 3611, I can say that it was not my intent= ion to<br> > override RFC 3550. Nor was it the intention of the two of my eight<br> > co-authors who I have discussed this with. Rather, the purpose of this= <br> > sentence was to remind the reader that XR packets, like any RTCP packe= ts,<br> > are designed to be stacked, and to helpfully point the reader to the R= FC<br> > 3550 section that deals with RTCP packet stacking for further details.= <br> ><br> > To the best of my recollection, no discussion in AVT leading up to approval<br> > of RFC 3611 indicates that any group participants at the time believed that<br> > RFC 3611 would override RFC 3550 on RTCP packet stacking.<br> ><br> > Still, I understand how people are reading RFC 3611 in this way. It do= es say<br> > "may be stacked", and though "may" is not capitali= zed, it is nonetheless an<br> > RFC 2119 keyword, meaning that the item is truly optional.<br> ><br> > Co-authors Nick Duffield, Ramon Caceres, and myself would like to open= <br> > discussion on how to address this situation. We start by suggesting th= at we<br> > file an RFC Errata report, indicating that the sentence should read instead:<br> ><br> > =93XR packets supplement the existing RTCP packets, and stack with oth= er RTCP<br> > packets to form compound RTCP packets, as described in Sec. 6 of RFC 3= 550<br> > [9].=94<br> ><br> > By dropping the "may", we drop any hint that this RFC overri= des the RFC 3550<br> > stacking mandate. And by adding "as described in Sec. 6 of RFC 3550" we make<br> > clear the informational nature of this sentence.<br> ><br> > Timur Friedman<br> ><br> ></p> </div> </div> </div></div></div> <p>=A0</p> </div> </div> </div> <p>=A0</p> </div> </div> <br>_______________________________________________<br> Audio/Video Transport Working Group<br> <a href=3D"mailto:avt@ietf.org">avt@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/avt" target=3D"_blank">htt= ps://www.ietf.org/mailman/listinfo/avt</a><br> <br></blockquote></div><br> --00163691fe65f2debc046af001b6-- From yekuiwang@huawei.com Thu May 28 07:35:27 2009 Return-Path: <yekuiwang@huawei.com> X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A946C3A6884 for <avt@core3.amsl.com>; Thu, 28 May 2009 07:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.342 X-Spam-Level: X-Spam-Status: No, score=-2.342 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1ijq0xih5jQ for <avt@core3.amsl.com>; Thu, 28 May 2009 07:35:20 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 5505E3A6DBD for <avt@ietf.org>; Thu, 28 May 2009 07:35:20 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KKC00AP5Z958F@usaga02-in.huawei.com> for avt@ietf.org; Thu, 28 May 2009 07:36:42 -0700 (PDT) Received: from W90946 ([10.193.125.102]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KKC00J9IZ8Z8U@usaga02-in.huawei.com> for avt@ietf.org; Thu, 28 May 2009 07:36:41 -0700 (PDT) Date: Thu, 28 May 2009 10:36:35 -0400 From: Ye-Kui Wang <yekuiwang@huawei.com> In-reply-to: To: 'IETF AVT WG' <avt@ietf.org> Message-id: <F31278A3961C4D1CB425DFF279D9FE9D@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acna8UQGrgzYGcgMRLK6VKOJKU4GPAAA4SpwAAoiXVAAKLJ/MADSmbwAACWstPA= References: <4A15046C.5080600@rogers.com> <006701c9d9e9$51679500$f436bf00$%roni@huawei.com> <7779AD69A5E54F9F84E473BB4F4E1E71@china.huawei.com> <4A157ADA.8060900@rogers.com> <ybuljopyjto.fsf@jesup.eng.wgate.com> <3221EC0396044781B11D483B77E085A1@china.huawei.com> <ybuhbzdygly.fsf@jesup.eng.wgate.com> <939A5D7EEE0A410E867078A3117DD3CE@china.huawei.com> <ybuhbzdb1tr.fsf@jesup.eng.wgate.com> <0F4BC54357284559B31303B0D730F7E2@china.huawei.com> <027101c9db1f$a9842a50$fc8c7ef0$%roni@huawei.com> <02341470F0384C54B17D2411F9267BE7@china.huawei.com> Cc: 'Tom Taylor' <tom.taylor@rogers.com>, 'Roni Even' <Even.roni@huawei.com> Subject: Re: [AVT] Consensus on profile-level-id in 3984bis X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group <avt.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/avt> List-Post: <mailto:avt@ietf.org> List-Help: <mailto:avt-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 28 May 2009 14:35:27 -0000 Chairs, Please guide how to proceed. We need to progress this work, which is dependent on by the SVC draft, which is needed by some other standards organizations like DVB and ATSC, though it seems that none of the proponents is going to provide detailed spec text. BR, YK > -----Original Message----- > From: Ye-Kui Wang [mailto:yekuiwang@huawei.com] > Sent: Wednesday, May 27, 2009 4:38 PM > To: 'IETF AVT WG' > Subject: RE: [AVT] Consensus on profile-level-id in 3984bis > > > Can we conclude the consensus on this issue to be something > similar as Tom suggested? > > BR, YK > > > > -----Original Message----- > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > Behalf Of > > Ye-Kui Wang > > Sent: Saturday, May 23, 2009 12:08 PM > > To: 'Roni Even'; 'Randell Jesup' > > Cc: 'Tom Taylor'; 'IETF AVT WG' > > Subject: Re: [AVT] Consensus on profile-level-id in 3984bis > > > > > > Roni, > > > > > I think I mentioned before that the offer can offer a low > level and > > > add capabilities using the optional parameters, this > working point > > > will be between two specified levels from table A-1, higher > > than the > > > one in the offer but lower than the one above it. I think > > that in this > > > case if the answer will include the higher level this will > > still work, > > > and since the encoder is flexible it may take advantage > of the new > > > information. > > > > Those max-* parameters may only be used to indicate receiver > > capabilities not anything else. That is, an offerer or answerer may > > add extra capabilities than the included level for receiving > > capabilities, but not for sending. > > > > BR, YK > > > > > -----Original Message----- > > > From: Roni Even [mailto:Even.roni@huawei.com] > > > Sent: Friday, May 22, 2009 4:55 PM > > > To: 'Ye-Kui Wang'; 'Randell Jesup' > > > Cc: 'Tom Taylor'; 'IETF AVT WG' > > > Subject: RE: [AVT] Consensus on profile-level-id in 3984bis > > > > > > YK, > > > I think you are right that we are now to the root of the > > discussion. > > > The levels in H.264 annex A specify some compromise in > > order to allow > > > mass production devices like set top boxes use fixed > > architecture for > > > example in order to define the frame buffer size on the > device and > > > typically will not negotiate the level (mostly streaming > > > applications). On the other side video conferencing systems > > have much > > > more flexibility and control over the encoder since they > > are part of a > > > system that considers also the display and network > connection when > > > they offer a specific level (which may be lower than the > > maximum that > > > they can support). Having more control on the encoder > > allows them to > > > get requests from the remote system to send pictures at specific > > > resolutions and aspect ratios. I think I mentioned before > that the > > > offer can offer a low level and add capabilities using > the optional > > > parameters, this working point will be between two > specified levels > > > from table A-1, higher than the one in the offer but > lower than the > > > one above it. I think that in this case if the answer will > > include the > > > higher level this will still work, and since the encoder is > > flexible > > > it may take advantage of the new information. > > > > > > Roni > > > > > > -----Original Message----- > > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > > Behalf Of > > > Ye-Kui Wang > > > Sent: Friday, May 22, 2009 8:10 PM > > > To: 'Randell Jesup' > > > Cc: 'Tom Taylor'; 'IETF AVT WG' > > > Subject: Re: [AVT] Consensus on profile-level-id in 3984bis > > > > > > > > > I think the root of most of the disputes is, given a > video encoder, > > > whether you can label it with a max level. In theory, I > > think you are > > > right that, given the computing resource of the encoder, it is > > > possible to compromise among parameters. However, in > practice, when > > > you get an encoder product (which is typically optimized or > > even fixed > > > for certain operating range), it would typically be > labelled with a > > > profile at a level, and it should not be common that > users (of the > > > encoder product) would try to compromise among parameters and see > > > whether it can produce a bitstream with a higher level, > and in many > > > cases, the encoder product does not provide enough space > > for you play > > > around this. The level labelled by the encoder manufacture > > is usually > > > the max level. > > > There are of course also purely PC software based encoders > > can be very > > > flexible, and can be configured to be almost any profile > and level. > > > But once it is configured to be at a profile and a level and the > > > encoder is initialized, then that level should be used as the max > > > level. > > > > > > BR, YK > > > > > > > -----Original Message----- > > > > From: Randell Jesup [mailto:rjesup@wgate.com] > > > > Sent: Friday, May 22, 2009 11:22 AM > > > > To: Ye-Kui Wang > > > > Cc: 'Tom Taylor'; 'IETF AVT WG' > > > > Subject: Re: [AVT] Consensus on profile-level-id in 3984bis > > > > > > > > Ye-Kui Wang <yekuiwang@huawei.com> writes: > > > > >> Ye-Kui Wang <yekuiwang@huawei.com> writes: > > > > >> >If the following are considered, then let the other > > > side know the > > > > >> >sending capability (as well as whether level upgrade is > > > allowed) > > > > >> >would be very useful. > > > > >> > > > > > >> >- One may want to request a specific mode, e.g. a spatial > > > > >> >resolution, from the sender, for example by using image > > > attribute > > > > >> >mmusic draft. > > > > >> > > > > >> Does adding a max-send-level actually help you there? > > > > > > > > > >Yes. > > > > > > > > > >> How does this interact with how you decide what your > > max sending > > > > >> level is? > > > > > > > > > >You don't decide your max sending level, your max sending > > > > level is your > > > > >max sending capability, a hard capability limit of you. > > > > > > > > Max capability for what/which? For all parameters > simultaneously? > > > > Maximum bitrate at maximum framesize at maximum > > macroblocks/second, > > > > with maximum frame-to-frame motion, with maximum > > > > motion-estimation-search, etc? > > > > > > > > I'm not saying you can't choose a maximum, but it's very, > > > very soft - > > > > very subjective because encoding is much more variable (and > > > expensive) > > > > than decoding. It's (much) easier to estimate a worst-case for > > > > decode. > > > > > > > > >> As mentioned below, choosing a value for that (other than > > > > basing it > > > > >> on resolution alone, and that just might put a lower bound > > > > on it) is > > > > >> extremely subjective at best. > > > > > > > > > >Example: If one side lets the other side know its max sending > > > > >capability, then the other side would not even try to > request a > > > > >specific capability that is impossible to be satisfied. > > > > Otherwise, the > > > > >other side may just send useless requests. > > > > > > > > > >> >- Video adaptation, in terms of bitrate, frame rate, > > > > and/or spatial > > > > >> >resolution etc, may happen during the session, and may be > > > > initiated > > > > >> >by either side. > > > > >> > > > > >> Again, how would this work in practice, and how would > > > > adding it here > > > > >> help? Adaptation within the negotiated limits can occur > > > now, so I > > > > >> don't see the advantage here. If you need to change the > > > > maximum limits (why? > > > > >> weren't they properly negotiated to start with?), > then you can > > > > >> re-invite. I think we need a concrete example, in order > > > > to know if > > > > >> what you're proposing is sufficient - or if it works. > > I'm quite > > > > >> unclear on how you believe specifying a max send level > > will help > > > > >> anything, since your list is quite vague. > > > > >> > > > > > > > > > >Example > > > > > > > > > >The offerer does not tell the answerer its max sending > > capability, > > > > >which is level B. A negotiation is done, where the > > answer includes > > > > >level C (C>B), and the offerer starts to send at C (actually > > > > B, but the > > > > >answerer may not be sure). After a while, the answerer > > > > senses that the > > > > >connecting bandwidth is higher, and it wants to receive at > > > a higher > > > > >bitrate, which is still within the limit of level C, but > > above the > > > > >limit of B, and sends a meaningless adaption request using > > > re-invite. > > > > > > > > > >However, if the offerer does tell the answerer its max sending > > > > >capability, such meaningless adaption requests are avoided. > > > > I believe > > > > >there are more examples, but I hope this already helps. > > > > > > > > That's a plausible case - thanks. However, I think you > > > could have an > > > > unintended result if you did that. Lets say that the > > > offerer uses the > > > > "worst-case" method to decide on a max-send-level (per > > > above). That > > > > level may be well below the limits it could hit when it's > > not worst > > > > case - for example, it may be constrained on framesize > or MBPS to > > > > level 3.0, but can handle the outgoing bandwidth of level > > 4.0, and > > > > level 5.0 when other parameters aren't worst-case. By > > > limiting to a > > > > max-send-level of 3.0, the receiver won't request use of extra > > > > bandwidth or 4.0 or 5.0. Note that even if you go and > > > duplicate all > > > > the max-* parameters as sprop-max-*, you still wouldn't > > be able to > > > > handle the "I can do this when other parameters are > relaxed" case. > > > > > > > > I also already mentioned this problem below (repeated here): > > > > >> >> The question is "is it worth it"? Also, while this > > > may let you > > > > >> >> limit resources, you may also limit the options of > > the sender. > > > > >> >> For example, in the first case above, since A knows B > > > > can receive > > > > >> >> 5.0, A could send a higher frame size than 3.0 supports > > > > (perhaps > > > > >> >> at a lower framerate), even though A can't support > > > > sending "full" level 3.1. > > > > > > > > I think you can handle the adaptation issue as part of the > > > adaptation > > > > design, since there may be other reasons the offerer can't > > > raise the > > > > bandwidth (or whatever). > > > > > > > > >BR, YK > > > > > > > > > > > > > > >> >BR, YK > > > > >> > > > > > >> >> -----Original Message----- > > > > >> >> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] > > > > >> On Behalf Of > > > > >> >> Randell Jesup > > > > >> >> Sent: Thursday, May 21, 2009 10:04 PM > > > > >> >> To: Tom Taylor > > > > >> >> Cc: IETF AVT WG > > > > >> >> Subject: Re: [AVT] Consensus on profile-level-id > in 3984bis > > > > >> >> > > > > >> >> Tom Taylor <tom.taylor@rogers.com> writes: > > > > >> >> >It appears that the optimum outcome is to be > able to signal > > > > >> >> both send > > > > >> >> >and receive capability. The legacy approach loses > > > some of this > > > > >> >> >information, since profile-level-id contains the lesser > > > > >> of the two > > > > >> >> >values. In a legacy-new interworking situation it seems > > > > >> >> unlikely that > > > > >> >> >we can improve on this. > > > > >> >> > > > > >> >> Well, I'm not sure you can say that a legacy device > > > > >> definitively uses > > > > >> >> the lesser of send/receive in profile-level-id. Because > > > > >> of the way > > > > >> >> profile-level-id works, and how H.264 encodes streams, > > > > there is no > > > > >> >> problem with currently specifying a level above what you > > > > >> can "truly" > > > > >> >> support *sending*. I.e. you can say you can receive and > > > > >> send level > > > > >> >> 3.0 via profile-level-id, but nothing forces you to use > > > > the full > > > > >> >> limits of level 3.0 when sending. You can send a stream > > > > >> that could > > > > >> >> be encoded identically in level 2.0; you can even mark > > > > it as level > > > > >> >> 3.0 in the SPS/PPS NAL units. > > > > >> >> > > > > >> >> On the other side of the equation, it is the lesser - if > > > > >> you can only > > > > >> >> receive level 2.0 when all the limits in the received > > > > stream are > > > > >> >> maxed out, you can't use anything above level 2.0 in > > > > >> >> profile-level-id. (You can > > > > >> >> *extend* it (such as with max-fs), if you also agree to > > > > decode the > > > > >> >> extension as well.) > > > > >> >> > > > > >> >> Those are the *current* semantics of profile-level-id. > > > > A legacy > > > > >> >> device may (or may not) as mentioned over-state it's > > > ability to > > > > >> >> encode. > > > > >> >> > > > > >> >> You could use an parameter that specifies the max > > > sending level > > > > >> >> supported in an offer (there's no point in an answer I > > > > >> believe). I > > > > >> >> originally proposed this. However, on reflection, > > > there's very > > > > >> >> little if anything to gain from that that I can see. A > > > > receiver > > > > >> >> could respond to > > > > >> >> level-upgrade-allowed=1 (or > > > level-asymmetry-allowed=1) with the > > > > >> >> highest level it can receive. Now each side knows the > > > > >> highest level > > > > >> >> the other can receive, and can send up to that level. > > > The only > > > > >> >> downside I can possibly think of to not knowing the > > > > >> maximum sending > > > > >> >> ability is that a receiver could perhaps not > > allocate as many > > > > >> >> resources if it knew the offerer couldn't send > > above level N. > > > > >> >> Example: > > > > >> >> > > > > >> >> A: Can receive level 2.0 (small LCD perhaps), can > > > send level 3.0 > > > > >> >> B: Can receive level 5.0, can send level 3.0 (more > > > > common form of > > > > >> >> send/recv > > > > >> >> asymmetry) > > > > >> >> > > > > >> >> A offers to be with > > > > >> profile-level-id=420014;level-asymmetry-allowed=1 > > > > >> >> B answers with profile-level-id=420032 > > > > >> >> > > > > >> >> A will send at level 3.0 > > > > >> >> B will send at level 2.0 (and must allocate resources to > > > > >> potentially > > > > >> >> receive 5.0) > > > > >> >> > > > > >> >> If you had a maximum-send-level parameter: > > > > >> >> > > > > >> >> A offers to be with > > profile-level-id=420014;sprop-max-level=1E > > > > >> >> B answers with profile-level-id=42001E > > > > >> >> > > > > >> >> A will send at level 3.0 > > > > >> >> B will send at level 2.0 (and only has to allocate > > > > resources for > > > > >> >> level 3.0) > > > > >> >> > > > > >> >> > > > > >> >> The question is "is it worth it"? Also, while this > > > may let you > > > > >> >> limit resources, you may also limit the options of > > the sender. > > > > >> >> For example, in the first case above, since A knows B > > > > can receive > > > > >> >> 5.0, A could send a higher frame size than 3.0 supports > > > > (perhaps > > > > >> >> at a lower framerate), even though A can't support > > > > sending "full" level 3.1. > > > > >> >> > > > > >> >> I should also note that quantizing the maximum level > > > > you can send > > > > >> >> is VERY subjective/arbitrary, because of how the > > > > encoding works. > > > > >> >> See the discussion above about how you don't have to > > > > max out the > > > > >> >> level you're supposedly sending. > > > > >> >> > > > > >> >> So my suggestion is to use level-asymmetry-allowed. > > (See my > > > > >> >> previous post for how this differs from > > > > level-upgrade-allowed - it > > > > >> >> allows asymmetric levels on level downgrade as > > well, which is > > > > >> >> actually probably a more common case.) > > > > >> >> > > > > >> >> >That suggests that profile-level-id should retain > > > its current > > > > >> >> >semantics, and one or two new parameters (only one of > > > > >> which would be > > > > >> >> >present in the offer or answer) would indicate > two things: > > > > >> >> >a) a value which is higher than the value given in > > > > >> profile-level-id; > > > > >> >> >b) whether that value is a send or receive capability. > > > > >> >> > > > > > >> >> >If it's just one parameter, it would have to be double > > > > >> valued e.g., > > > > >> >> >alternate-level-id="send,<value>". > > > > >> >> > > > > > >> >> >If it is two parameters, the appropriate parameter to > > > > >> include would > > > > >> >> >depend on which whether the capability being reported > > > > is send or > > > > >> >> >receive, e.g., send-level-id=<value> > > > > >> >> >or recv-level-id=<value > > > > >> >> >but never both in the same stream. > > > > >> >> > > > > > >> >> >Ye-Kui Wang wrote: > > > > >> >> >> Another interoperability issue relates to the semantics > > > > >> >> change of the > > > > >> >> >> level part of profile-level-id. Currently, the > > level part, > > > > >> >> when used > > > > >> >> >> capability exchange or session setup, gives the upper > > > > >> >> limit of both > > > > >> >> >> decoding capability and encoding capability, as seen > > > > from the > > > > >> >> >> following two paragraphs excerpted from the bis > > draft (the > > > > >> >> same in spirit in 3984): > > > > >> >> >> > > > > >> >> >> "The profile-level-id parameter indicates the default > > > > >> sub-profile, > > > > >> >> >> i.e. the subset of coding tools that may have > > been used to > > > > >> >> generate > > > > >> >> >> the stream or that the receiver supports, and the > > > > >> default level of > > > > >> >> >> the stream or the receiver supports." > > > > >> >> >> > > > > >> >> >> "If the profile-level-id parameter is used for > capability > > > > >> >> exchange or > > > > >> >> >> session setup procedure, it indicates the subset of > > > > >> coding tools, > > > > >> >> >> which is equal to the default sub-profile, and the > > > > >> highest level, > > > > >> >> >> which is equal to the default level, that the codec > > > > >> supports. All > > > > >> >> >> levels lower than the default level are also > supported by > > > > >> >> the codec. " > > > > >> >> >> > > > > >> >> >> When level upgrade is allowed, then this semantics must > > > > >> >> change, such > > > > >> >> >> that the level part basically indicates only > the decoding > > > > >> >> capability. > > > > >> >> >> This change of course creates different understandings > > > > >> between the > > > > >> >> >> two sides whenever one is legacy and the other is new. > > > > >> >> >> > > > > >> >> >> We have at least the following options to go to > > > > allow for level > > > > >> >> >> upgrade (the semantics change above is anyway > > > > needed): - To add > > > > >> >> >> "level-upgrade-allowed". - To add > "level-upgrade-allowed" > > > > >> >> and another > > > > >> >> >> parameter, say sending-capability-level, to indicate > > > > >> the sending > > > > >> >> >> capability expressed as a level value. - To go > wildly, by > > > > >> >> making all > > > > >> >> >> paramters not starting with "sprop-" as receiving > > > > capabilities. > > > > >> >> >> Another group of parameters not starting with > > > > "sprop-" can be > > > > >> >> >> optionally used to indicate sending capabilities. When > > > > >> >> these sending > > > > >> >> >> capability parameters are not present, the sending > > > > >> >> capabilities are > > > > >> >> >> by default equal to the receiving capabilties. > > > > >> >> >> > > > > >> >> >> A decision needs to be made which one to take. > > > > >> >> >> > > > > >> >> >> In any case, I hope a proponent could provide > relatively > > > > >> >> mature text, > > > > >> >> >> including changes to semantics, offer/answer rules > > > > (including > > > > >> >> >> parameter sets considerations in offer/answer), > > > > >> declarative usage, > > > > >> >> >> SDP examples, and discussion of backward > > > > compatibility issues. > > > > >> >> >> > > > > >> >> >> Note that all the changes will also affect the > > SVC payload > > > > >> >> draft, as > > > > >> >> >> they basically need to be appropriately > integrated to the > > > > >> >> SVC payload draft. > > > > >> >> >> > > > > >> >> >> BR, YK > > > > >> >> >> > > > > >> >> >... > > > > >> >> >_______________________________________________ > > > > >> >> >Audio/Video Transport Working Group avt@ietf.org > > > > >> >> >https://www.ietf.org/mailman/listinfo/avt > > > > >> >> > > > > >> >> > > > > >> >> -- > > > > >> >> Randell Jesup, Worldgate (developers of the Ojo > > > > >> videophone), ex-Amiga > > > > >> >> OS team rjesup@wgate.com "The fetters imposed on liberty > > > > >> at home have > > > > >> >> ever been forged out of the weapons provided for > > > > defence against > > > > >> >> real, pretended, or imaginary dangers from abroad." > > > > >> >> - James Madison, 4th US president (1751-1836) > > > > >> >> > > > > >> >> _______________________________________________ > > > > >> >> Audio/Video Transport Working Group avt@ietf.org > > > > >> >> https://www.ietf.org/mailman/listinfo/avt > > > > >> >> > > > > >> > > > > >> > > > > >> -- > > > > >> Randell Jesup, Worldgate (developers of the Ojo > > > > videophone), ex-Amiga > > > > >> OS team rjesup@wgate.com "The fetters imposed on liberty > > > > at home have > > > > >> ever been forged out of the weapons provided for > > defence against > > > > >> real, pretended, or imaginary dangers from abroad." > > > > >> - James Madison, 4th US president (1751-1836) > > > > >> > > > > >> > > > > > > > > > > > > -- > > > > Randell Jesup, Worldgate (developers of the Ojo > > > videophone), ex-Amiga > > > > OS team rjesup@wgate.com "The fetters imposed on liberty at > > > home have > > > > ever been forged out of the weapons provided for defence > > > against real, > > > > pretended, or imaginary dangers from abroad." > > > > - James Madison, 4th US president (1751-1836) > > > > > > > > > > > > > > > > > _______________________________________________ > > > Audio/Video Transport Working Group > > > avt@ietf.org > > > https://www.ietf.org/mailman/listinfo/avt > > > > > > > > > > > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > > From wwwrun@core3.amsl.com Thu May 28 11:06:44 2009 Return-Path: <wwwrun@core3.amsl.com> X-Original-To: avt@ietf.org Delivered-To: avt@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id D63DF3A6DF0; Thu, 28 May 2009 11:06:44 -0700 (PDT) X-idtracker: yes From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> Message-Id: <20090528180644.D63DF3A6DF0@core3.amsl.com> Date: Thu, 28 May 2009 11:06:44 -0700 (PDT) Cc: Internet Architecture Board <iab@iab.org>, avt mailing list <avt@ietf.org>, avt chair <avt-chairs@tools.ietf.org>, RFC Editor <rfc-editor@rfc-editor.org> Subject: [AVT] Protocol Action: 'RTP Payload Format for Adaptive TRansform Acoustic Coding (ATRAC) Family' to Proposed Standard X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group <avt.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/avt> List-Post: <mailto:avt@ietf.org> List-Help: <mailto:avt-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 28 May 2009 18:06:44 -0000 The IESG has approved the following document: - 'RTP Payload Format for Adaptive TRansform Acoustic Coding (ATRAC) Family ' <draft-ietf-avt-rtp-atrac-family-24.txt> as a Proposed Standard This document is the product of the Audio/Video Transport Working Group. The IESG contact persons are Cullen Jennings and Robert Sparks. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-atrac-family-24.txt Technical Summary This document describes an RTP payload format for efficient and flexible transporting of audio data encoded with the Adaptive TRansform Audio Coding (ATRAC) family of codecs. Recent enhancements to the ATRAC family of codecs support high quality audio coding with multiple channels. The RTP payload format as presented in this document also includes support for data fragmentation, elementary redundancy measures, and a variation on scalable streaming. Working Group Summary The first predecessor to this document appeared in late 2002. Since then the document has progressed steadily with strong guidance from the AVT Chairs. It was accepted as a Working Group item in August 2004. Working Group Last Call drew one comment on the media types list and a final Chair's review. All comments have been resolved. Document Quality The authors have implemented the content of the document. Media type review was requested for the three media types on 19/2/2008. Personnel Document Shepherd is Tom Taylor <tom.taylor@rogers.com>. Cullen Jennings is the responsible Area Director. From wwwrun@core3.amsl.com Thu May 28 11:10:13 2009 Return-Path: <wwwrun@core3.amsl.com> X-Original-To: avt@ietf.org Delivered-To: avt@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 886073A6DC7; Thu, 28 May 2009 11:10:13 -0700 (PDT) X-idtracker: yes From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> Message-Id: <20090528181013.886073A6DC7@core3.amsl.com> Date: Thu, 28 May 2009 11:10:13 -0700 (PDT) Cc: Internet Architecture Board <iab@iab.org>, avt mailing list <avt@ietf.org>, avt chair <avt-chairs@tools.ietf.org>, RFC Editor <rfc-editor@rfc-editor.org> Subject: [AVT] Protocol Action: 'RTP Payload Format for ITU-T Recommendation G.722.1' to Proposed Standard X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group <avt.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/avt> List-Post: <mailto:avt@ietf.org> List-Help: <mailto:avt-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 28 May 2009 18:10:13 -0000 The IESG has approved the following document: - 'RTP Payload Format for ITU-T Recommendation G.722.1 ' <draft-ietf-avt-rfc3047-bis-09.txt> as a Proposed Standard This document is the product of the Audio/Video Transport Working Group. The IESG contact persons are Cullen Jennings and Robert Sparks. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc3047-bis-09.txt Technical Summary International Telecommunication Union (ITU-T) Recommendation G.722.1 is a wide-band audio codec. This document describes the payload format for including G.722.1 generated bit streams within an RTP packet. The document also describes the syntax and semantics of the SDP parameters needed to support G.722.1 audio codec. Working Group Summary The G722.1 codec can change bit rate in mid-stream. Dealing with this successfully was an issue for discussion during WGLC. The resolution was to require each bit rate to have its own payload type. Document Quality Magnus Westerlund performed the initial review of the document. Aurelien Sollaud also provided careful reviews, particularly during WGLC. Personnel Tom Taylor is the Document Shepherd. RFC Editor Note In section 7 OLD The new draft obsoletes RFC3047 NEW This specification obsoletes RFC3047 From Even.roni@huawei.com Fri May 29 00:34:34 2009 Return-Path: <Even.roni@huawei.com> X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B92EF3A6E22 for <avt@core3.amsl.com>; Fri, 29 May 2009 00:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.148 X-Spam-Level: X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[AWL=0.451, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJvzEgX+tutO for <avt@core3.amsl.com>; Fri, 29 May 2009 00:34:33 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 3C0973A68C3 for <avt@ietf.org>; Fri, 29 May 2009 00:34:33 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KKE00KH4AGFA3@szxga04-in.huawei.com> for avt@ietf.org; Fri, 29 May 2009 15:36:15 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KKE0060VAGFWS@szxga04-in.huawei.com> for avt@ietf.org; Fri, 29 May 2009 15:36:15 +0800 (CST) Received: from windows8d787f9 (bzq-79-181-138-75.red.bezeqint.net [79.181.138.75]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KKE00M29AG4J3@szxml02-in.huawei.com> for avt@ietf.org; Fri, 29 May 2009 15:36:14 +0800 (CST) Date: Fri, 29 May 2009 10:35:18 +0300 From: Roni Even <Even.roni@huawei.com> To: avt@ietf.org Message-id: <021701c9e030$0a5deef0$1f19ccd0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_zXb6qIlBjkwGhPdIKOLr0Q)" Content-language: en-us Thread-index: AcngMAPzVFoLlUEtQjqFgqcok28Eyw== Subject: [AVT] [dispatch] Proposal to form Internet Wideband Audio Codec WG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group <avt.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/avt> List-Post: <mailto:avt@ietf.org> List-Help: <mailto:avt-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 29 May 2009 07:34:34 -0000 This is a multipart message in MIME format. --Boundary_(ID_zXb6qIlBjkwGhPdIKOLr0Q) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT FYI All, I would like to request agenda time inside the DISPATCH meeting to propose the formation of a new working group to define a Proposed Standard wideband audio codec. The text of the proposal is below. Comments, questions, and suggestions welcomed. Regards, Jason Internet Wideband Audio Codec (IWAC) Mailing Lists: TBD Chairs: TBD Area Directorate: Real Time Applications (RAI) Purpose: This new working group would be chartered with the purpose of collecting expertise within the IETF in order to review the design of audio codecs specifically for use with the Internet. Unlike other SDOs, these codecs would be optimized for use on the Internet, and as much as possible choose technology that does not require paying patent royalties. The Internet Low Bit Rate Codec (iLBC) work was done in AVT but it was felt that subsequent work should not be done in the AVT working group. This new working group will have as its primary purpose the standardization of a multi-purpose audio codec that can be used in various situations on the Internet. Some of the proposed Internet-specific requirements include: * scalable and adaptive bit rate; * various sampling rate profiles from narrow-band to super-wideband; * scalable complexity; * low latency; and * resilience to packet loss. There are a number of wide-band capable codecs defined by other SDOs. For instance, G.722 is seeing adoption in Enterprise applications since it is relatively simple and low-cost to deploy. However, it has a high, fixed bitrate and is not appropriate for mobile applications where spectrum efficiency is important or in consumer applications where available bandwidth is fluctuating or limited. G.722.2 (AMR-wideband) has been adopted by the 3GPP as a wideband standard for mobile applications. G.722.2 is relatively high cost due to patent royalties and is seeing minimal deployments outside of mobile handsets making it challenging to create wideband experiences on Internet-capable mobile devices when extending beyond the mobile network. In other cases, proprietary codecs are being adopted which further create islands with no interoperability unless widespread transcoding is performed. Transcoding leads to higher costs and lower quality. The goal of this working group is to define a single codec with multiple profiles which can be made available on a wide variety of Internet-capable devices including low-power, mobile devices as well as devices capable of utilizing high quality, high bitrate audio. Proposed Deliverables: 1) Requirements for wideband, Internet audio codec(s). 2) Algorithm description for wideband, Internet audio codec(s) as Proposed Standard. 3) Specification of payload format(s) for defined codecs as Proposed Standard _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --Boundary_(ID_zXb6qIlBjkwGhPdIKOLr0Q) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:x=3D"urn:schemas-microsoft-com:office:excel" = xmlns:p=3D"urn:schemas-microsoft-com:office:powerpoint" = xmlns:a=3D"urn:schemas-microsoft-com:office:access" = xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" = xmlns:s=3D"uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" = xmlns:rs=3D"urn:schemas-microsoft-com:rowset" xmlns:z=3D"#RowsetSchema" = xmlns:b=3D"urn:schemas-microsoft-com:office:publisher" = xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadsheet" = xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" = xmlns:odc=3D"urn:schemas-microsoft-com:office:odc" = xmlns:oa=3D"urn:schemas-microsoft-com:office:activation" = xmlns:html=3D"http://www.w3.org/TR/REC-html40" = xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" = xmlns:rtc=3D"http://microsoft.com/officenet/conferencing" = xmlns:D=3D"DAV:" xmlns:Repl=3D"http://schemas.microsoft.com/repl/" = xmlns:mt=3D"http://schemas.microsoft.com/sharepoint/soap/meetings/" = xmlns:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" = xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" = xmlns:ois=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" = xmlns:dir=3D"http://schemas.microsoft.com/sharepoint/soap/directory/" = xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#" = xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" = xmlns:udc=3D"http://schemas.microsoft.com/data/udc" = xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema" = xmlns:sub=3D"http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/"= xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" = xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" = xmlns:sps=3D"http://schemas.microsoft.com/sharepoint/soap/" = xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" = xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/soap" = xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" = xmlns:udcp2p=3D"http://schemas.microsoft.com/data/udc/parttopart" = xmlns:wf=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/" = xmlns:dsss=3D"http://schemas.microsoft.com/office/2006/digsig-setup" = xmlns:dssi=3D"http://schemas.microsoft.com/office/2006/digsig" = xmlns:mdssi=3D"http://schemas.openxmlformats.org/package/2006/digital-sig= nature" = xmlns:mver=3D"http://schemas.openxmlformats.org/markup-compatibility/2006= " xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" = xmlns:mrels=3D"http://schemas.openxmlformats.org/package/2006/relationshi= ps" xmlns:spwp=3D"http://microsoft.com/sharepoint/webpartpages" = xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/types"= = xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/messag= es" = xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/= " = xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortalServer/Pub= lishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" = xmlns:st=3D"" xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dus-ascii"> <meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)"> <style> <!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Consolas; panose-1:2 11 6 9 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p.MsoPlainText, li.MsoPlainText, div.MsoPlainText {mso-style-priority:99; mso-style-link:"Plain Text Char"; margin:0in; margin-bottom:.0001pt; font-size:10.5pt; font-family:Consolas;} span.EmailStyle17 {mso-style-type:personal-compose; font-family:"Calibri","sans-serif"; color:windowtext;} span.PlainTextChar {mso-style-name:"Plain Text Char"; mso-style-priority:99; mso-style-link:"Plain Text"; font-family:Consolas;} .MsoChpDefault {mso-style-type:export-only;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.25in 1.0in 1.25in;} div.Section1 {page:Section1;} --> </style> <!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3DEN-US link=3Dblue vlink=3Dpurple> <div class=3DSection1> <p class=3DMsoNormal>FYI<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoPlainText>All,<o:p></o:p></p> <p class=3DMsoPlainText><o:p> </o:p></p> <p class=3DMsoPlainText>I would like to request agenda time inside the = DISPATCH meeting to propose the formation of a new working group to define a = Proposed Standard wideband audio codec.<o:p></o:p></p> <p class=3DMsoPlainText><o:p> </o:p></p> <p class=3DMsoPlainText>The text of the proposal is below. Comments, = questions, and suggestions welcomed.<o:p></o:p></p> <p class=3DMsoPlainText><o:p> </o:p></p> <p class=3DMsoPlainText>Regards,<o:p></o:p></p> <p class=3DMsoPlainText>Jason<o:p></o:p></p> <p class=3DMsoPlainText><o:p> </o:p></p> <p class=3DMsoPlainText><o:p> </o:p></p> <p class=3DMsoPlainText>Internet Wideband Audio Codec = (IWAC)<o:p></o:p></p> <p class=3DMsoPlainText>Mailing Lists: TBD<o:p></o:p></p> <p class=3DMsoPlainText>Chairs: TBD<o:p></o:p></p> <p class=3DMsoPlainText>Area Directorate: Real Time Applications = (RAI)<o:p></o:p></p> <p class=3DMsoPlainText><o:p> </o:p></p> <p class=3DMsoPlainText>Purpose:<o:p></o:p></p> <p class=3DMsoPlainText><o:p> </o:p></p> <p class=3DMsoPlainText>This new working group would be chartered with = the purpose of collecting<o:p></o:p></p> <p class=3DMsoPlainText>expertise within the IETF in order to review the = design of audio codecs<o:p></o:p></p> <p class=3DMsoPlainText>specifically for use with the Internet. Unlike = other SDOs, these codecs<o:p></o:p></p> <p class=3DMsoPlainText>would be optimized for use on the Internet, and = as much as possible choose<o:p></o:p></p> <p class=3DMsoPlainText>technology that does not require paying patent = royalties.<o:p></o:p></p> <p class=3DMsoPlainText><o:p> </o:p></p> <p class=3DMsoPlainText>The Internet Low Bit Rate Codec (iLBC)  = work was done in AVT but it was felt<o:p></o:p></p> <p class=3DMsoPlainText>that subsequent work should not be done in the = AVT working group. This new<o:p></o:p></p> <p class=3DMsoPlainText>working group will have as its primary purpose = the standardization of a<o:p></o:p></p> <p class=3DMsoPlainText>multi-purpose audio codec that can be used in = various situations on the<o:p></o:p></p> <p class=3DMsoPlainText>Internet. Some of the proposed Internet-specific requirements include:<o:p></o:p></p> <p class=3DMsoPlainText>* scalable and adaptive bit rate;<o:p></o:p></p> <p class=3DMsoPlainText>* various sampling rate profiles from = narrow-band to super-wideband;<o:p></o:p></p> <p class=3DMsoPlainText>* scalable complexity;<o:p></o:p></p> <p class=3DMsoPlainText>* low latency; and <o:p></o:p></p> <p class=3DMsoPlainText>* resilience to packet loss.<o:p></o:p></p> <p class=3DMsoPlainText><o:p> </o:p></p> <p class=3DMsoPlainText>There are a number of wide-band capable codecs = defined by other SDOs. For<o:p></o:p></p> <p class=3DMsoPlainText>instance, G.722 is seeing adoption in Enterprise applications since it is<o:p></o:p></p> <p class=3DMsoPlainText>relatively simple and low-cost to deploy. = However, it has a high, fixed<o:p></o:p></p> <p class=3DMsoPlainText>bitrate and is not appropriate for mobile = applications where spectrum<o:p></o:p></p> <p class=3DMsoPlainText>efficiency is important or in consumer = applications where available<o:p></o:p></p> <p class=3DMsoPlainText>bandwidth is fluctuating or limited. G.722.2 (AMR-wideband) has been adopted<o:p></o:p></p> <p class=3DMsoPlainText>by the 3GPP as a wideband standard for mobile applications. G.722.2 is<o:p></o:p></p> <p class=3DMsoPlainText>relatively high cost due to patent royalties and = is seeing minimal<o:p></o:p></p> <p class=3DMsoPlainText>deployments outside of mobile handsets making it challenging to create<o:p></o:p></p> <p class=3DMsoPlainText>wideband experiences on Internet-capable mobile = devices when extending<o:p></o:p></p> <p class=3DMsoPlainText>beyond the mobile network. In other cases, = proprietary codecs are being<o:p></o:p></p> <p class=3DMsoPlainText>adopted which further create islands with no interoperability unless<o:p></o:p></p> <p class=3DMsoPlainText>widespread transcoding is performed. Transcoding = leads to higher costs and<o:p></o:p></p> <p class=3DMsoPlainText>lower quality. <o:p></o:p></p> <p class=3DMsoPlainText><o:p> </o:p></p> <p class=3DMsoPlainText>The goal of this working group is to define a = single codec with multiple<o:p></o:p></p> <p class=3DMsoPlainText>profiles which can be made available on a wide = variety of Internet-capable<o:p></o:p></p> <p class=3DMsoPlainText>devices including low-power, mobile devices as = well as devices capable of<o:p></o:p></p> <p class=3DMsoPlainText>utilizing high quality, high bitrate = audio.<o:p></o:p></p> <p class=3DMsoPlainText><o:p> </o:p></p> <p class=3DMsoPlainText>Proposed Deliverables:<o:p></o:p></p> <p class=3DMsoPlainText><o:p> </o:p></p> <p class=3DMsoPlainText>1) Requirements for wideband, Internet audio = codec(s).<o:p></o:p></p> <p class=3DMsoPlainText>2) Algorithm description for wideband, Internet = audio codec(s) as Proposed<o:p></o:p></p> <p class=3DMsoPlainText>Standard. <o:p></o:p></p> <p class=3DMsoPlainText>3) Specification of payload format(s) for = defined codecs as Proposed<o:p></o:p></p> <p class=3DMsoPlainText>Standard<o:p></o:p></p> <p class=3DMsoPlainText><o:p> </o:p></p> <p = class=3DMsoPlainText>_______________________________________________<o:p>= </o:p></p> <p class=3DMsoPlainText>dispatch mailing list<o:p></o:p></p> <p class=3DMsoPlainText><a = href=3D"mailto:dispatch@ietf.org">dispatch@ietf.org</a><o:p></o:p></p> <p class=3DMsoPlainText><a = href=3D"https://www.ietf.org/mailman/listinfo/dispatch">https://www.ietf.= org/mailman/listinfo/dispatch</a><o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> </div> </body> </html> --Boundary_(ID_zXb6qIlBjkwGhPdIKOLr0Q)-- From rjesup@wgate.com Fri May 29 06:24:58 2009 Return-Path: <rjesup@wgate.com> X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94D4C3A6EA1 for <avt@core3.amsl.com>; Fri, 29 May 2009 06:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.595 X-Spam-Level: X-Spam-Status: No, score=-1.595 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzTJrPitthc9 for <avt@core3.amsl.com>; Fri, 29 May 2009 06:24:57 -0700 (PDT) Received: from exchange1.wgate.com (pr-66-150-46-254.wgate.com [66.150.46.254]) by core3.amsl.com (Postfix) with ESMTP id B87E53A6A59 for <avt@ietf.org>; Fri, 29 May 2009 06:24:57 -0700 (PDT) Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 May 2009 08:31:36 -0400 To: Ye-Kui Wang <yekuiwang@huawei.com> References: <4A15046C.5080600@rogers.com> <006701c9d9e9$51679500$f436bf00$%roni@huawei.com> <7779AD69A5E54F9F84E473BB4F4E1E71@china.huawei.com> <4A157ADA.8060900@rogers.com> <ybuljopyjto.fsf@jesup.eng.wgate.com> <3221EC0396044781B11D483B77E085A1@china.huawei.com> <ybuhbzdygly.fsf@jesup.eng.wgate.com> <939A5D7EEE0A410E867078A3117DD3CE@china.huawei.com> <ybuhbzdb1tr.fsf@jesup.eng.wgate.com> <0F4BC54357284559B31303B0D730F7E2@china.huawei.com> <027101c9db1f$a9842a50$fc8c7ef0$%roni@huawei.com> <02341470F0384C54B17D2411F9267BE7@china.huawei.com> <F31278A3961C4D1CB425DFF279D9FE9D@china.huawei.com> From: Randell Jesup <rjesup@wgate.com> Date: Fri, 29 May 2009 08:32:04 -0400 In-Reply-To: <F31278A3961C4D1CB425DFF279D9FE9D@china.huawei.com> (Ye-Kui Wang's message of "Thu\, 28 May 2009 10\:36\:35 -0400") Message-ID: <ybu7i00hyyj.fsf@jesup.eng.wgate.com> User-Agent: Gnus/5.101 (Gnus v5.10.10) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 29 May 2009 12:31:36.0813 (UTC) FILETIME=[6895D1D0:01C9E059] Cc: 'IETF AVT WG' <avt@ietf.org>, 'Roni Even' <Even.roni@huawei.com>, 'Tom Taylor' <tom.taylor@rogers.com> Subject: Re: [AVT] Consensus on profile-level-id in 3984bis X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Randell Jesup <rjesup@wgate.com> List-Id: Audio/Video Transport Working Group <avt.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/avt> List-Post: <mailto:avt@ietf.org> List-Help: <mailto:avt-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 29 May 2009 13:24:58 -0000 Ye-Kui Wang <yekuiwang@huawei.com> writes: >Please guide how to proceed. We need to progress this work, which is >dependent on by the SVC draft, which is needed by some other standards >organizations like DVB and ATSC, though it seems that none of the proponents >is going to provide detailed spec text. I'm willing to take a shot at some text over the weekend, modulo time with my daughter. -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com "The fetters imposed on liberty at home have ever been forged out of the weapons provided for defence against real, pretended, or imaginary dangers from abroad." - James Madison, 4th US president (1751-1836) From john.lazzaro@gmail.com Fri May 29 09:37:17 2009 Return-Path: <john.lazzaro@gmail.com> X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0729C3A6BA5 for <avt@core3.amsl.com>; Fri, 29 May 2009 09:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d8Cf19wD4b17 for <avt@core3.amsl.com>; Fri, 29 May 2009 09:37:16 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.242]) by core3.amsl.com (Postfix) with ESMTP id 02E443A6A9A for <avt@ietf.org>; Fri, 29 May 2009 09:37:15 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id c3so4460405ana.4 for <avt@ietf.org>; Fri, 29 May 2009 09:38:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=Phnw3Mc/ILaFI3GVr1VxnVDW6cBjDWtAMBpJ4CtZmr8=; b=YQw4vp6QfoadC0dKMPMeHFyP1mvZYPmtt4Tyub0X58AaEtKXtZxt57WsWyjZfMYXLm vMK3Lpm9Ic4SRZ4xaK4tJNIPzF6ONaVkDjbc7SxCqfkPsXWPZdqOaVDzzzLMHPyfZ6+c ClORlA0faZPG51g68Gjl+dfYS9jbT7IFzZTiI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=FC7GtJsHWcTM2bn+RDBJPCv9VQTxK5f/o1SnMcjSUUvJYxlv/JKJtluyjb/3donHe0 zw8puVX+vdKsi1yhnvPe+mAw5ez0z4vsAnS47V5MbK35PBkgluV6fX4lCuUiKhQ/jQo8 zfjhNVNSGF4mbo6V78BWOdKsB0RBZ7+9TqF/U= MIME-Version: 1.0 Received: by 10.100.91.15 with SMTP id o15mr3991841anb.47.1243614686200; Fri, 29 May 2009 09:31:26 -0700 (PDT) In-Reply-To: <021701c9e030$0a5deef0$1f19ccd0$%roni@huawei.com> References: <021701c9e030$0a5deef0$1f19ccd0$%roni@huawei.com> Date: Fri, 29 May 2009 09:31:26 -0700 Message-ID: <302f570905290931lf084f46g3c2a6a298b326954@mail.gmail.com> From: John Lazzaro <john.lazzaro@gmail.com> To: avt@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [AVT] [dispatch] Proposal to form Internet Wideband Audio Codec WG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group <avt.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/avt> List-Post: <mailto:avt@ietf.org> List-Help: <mailto:avt-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 29 May 2009 16:37:17 -0000 Hi everyone, Brief comment below ... > Internet Wideband Audio Codec (IWAC) > > This new working group would be chartered with the purpose of collecting > expertise within the IETF in order to review the design of audio codecs > specifically for use with the Internet. A traditional response to this type of request is to note that the IETF really doesn't have much in the way of expertise in audio codec design. I don't see many of the regulars who present at the AES codec paper sessions posting here on AVT (ditto ICASSP paper sessions for voice codecs). It's a full-time job to keep up-to-date and contribute to that signal-processing lore. -- John Lazzaro http://www.cs.berkeley.edu/~lazzaro john [dot] lazzaro [at] gmail [dot] com From stephen.botzko@gmail.com Fri May 29 09:58:57 2009 Return-Path: <stephen.botzko@gmail.com> X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C40003A67EF for <avt@core3.amsl.com>; Fri, 29 May 2009 09:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6g8iYG0YJziE for <avt@core3.amsl.com>; Fri, 29 May 2009 09:58:56 -0700 (PDT) Received: from mail-fx0-f168.google.com (mail-fx0-f168.google.com [209.85.220.168]) by core3.amsl.com (Postfix) with ESMTP id 77DA03A68B5 for <avt@ietf.org>; Fri, 29 May 2009 09:58:56 -0700 (PDT) Received: by fxm12 with SMTP id 12so4520263fxm.37 for <avt@ietf.org>; Fri, 29 May 2009 10:00:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=wkb7PsTK11T84K2vtSIZxLiCKDdv47WSUpyHpm4oMoE=; b=wLhiViT6m+qDCg6BYqi0e7wZ8QVl7gxXEHqlee0i/ENnuvOKz4GHlG+JCStCHe8ng3 NXpBkZLH6CeF/muMBHf1Wui4psXIdihCcTpvea1cpZZ7Gt2TuUlK/3YBE2FqUjJfmKwX KsHGVPDAj+mfAhTC30jl17S9rVR863PifGeB8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=VtZceBgTy+Txr6p3dJDGveB8HNxUy4oidWLk9ye1wMYSe3RAbwDwfnu1gQs51HRksI kVOacWR45B9UDJfl/cx/p6Ym7ihli5qJ4WGLN9I5LBLACK0Jz2G7nelYgc8EwsNCGIIv 52cjnl6Vj2BQYN/GjBVi9nn7iThgykUgf1dSM= MIME-Version: 1.0 Received: by 10.223.116.77 with SMTP id l13mr2185242faq.106.1243616432801; Fri, 29 May 2009 10:00:32 -0700 (PDT) In-Reply-To: <302f570905290931lf084f46g3c2a6a298b326954@mail.gmail.com> References: <021701c9e030$0a5deef0$1f19ccd0$%roni@huawei.com> <302f570905290931lf084f46g3c2a6a298b326954@mail.gmail.com> Date: Fri, 29 May 2009 13:00:32 -0400 Message-ID: <6e9223710905291000v72e89443k34e5b528198e961@mail.gmail.com> From: stephen botzko <stephen.botzko@gmail.com> To: John Lazzaro <john.lazzaro@gmail.com> Content-Type: multipart/alternative; boundary=001636c5afb6b6ca8d046b1003da Cc: avt@ietf.org Subject: Re: [AVT] [dispatch] Proposal to form Internet Wideband Audio Codec WG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group <avt.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/avt> List-Post: <mailto:avt@ietf.org> List-Help: <mailto:avt-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 29 May 2009 16:58:57 -0000 --001636c5afb6b6ca8d046b1003da Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit In addition, rigorously testing the codec's quality is a specialized discipline in its own right. In other standards bodies the testing is frequently done by an independent working group (that just does testing). Stephen Botzko On Fri, May 29, 2009 at 12:31 PM, John Lazzaro <john.lazzaro@gmail.com>wrote: > Hi everyone, > > Brief comment below ... > > > Internet Wideband Audio Codec (IWAC) > > > > This new working group would be chartered with the purpose of collecting > > expertise within the IETF in order to review the design of audio codecs > > specifically for use with the Internet. > > A traditional response to this type of request is to note that the IETF > really doesn't have much in the way of expertise in audio codec design. > I don't see many of the regulars who present at the AES codec paper > sessions > posting here on AVT (ditto ICASSP paper sessions for voice codecs). It's > a full-time job to keep up-to-date and contribute to that > signal-processing lore. > > -- > John Lazzaro > http://www.cs.berkeley.edu/~lazzaro<http://www.cs.berkeley.edu/%7Elazzaro> > john [dot] lazzaro [at] gmail [dot] com > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > --001636c5afb6b6ca8d046b1003da Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In addition, rigorously testing the codec's quality is a specialized di= scipline in its own right.=A0 In other standards bodies the testing is freq= uently done by an independent working group (that just does testing).<br><b= r> Stephen Botzko<br><br><div class=3D"gmail_quote">On Fri, May 29, 2009 at 12= :31 PM, John Lazzaro <span dir=3D"ltr"><<a href=3D"mailto:john.lazzaro@g= mail.com">john.lazzaro@gmail.com</a>></span> wrote:<br><blockquote class= =3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 204, 204); margin= : 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Hi everyone,<br> <br> Brief comment below ...<br> <div class=3D"im"><br> > Internet Wideband Audio Codec (IWAC)<br> ><br> </div><div class=3D"im">> This new working group would be chartered with= the purpose of collecting<br> > expertise within the IETF in order to review the design of audio codec= s<br> > specifically for use with the Internet.<br> <br> </div>A traditional response to this type of request is to note that the IE= TF<br> really doesn't have much in the way of expertise in audio codec design.= <br> I don't see many of the regulars who present at the AES codec paper ses= sions<br> posting here on AVT (ditto ICASSP paper sessions for voice codecs). It'= s<br> a full-time job to keep up-to-date and contribute to that<br> signal-processing lore.<br> <font color=3D"#888888"><br> --<br> John Lazzaro<br> <a href=3D"http://www.cs.berkeley.edu/%7Elazzaro" target=3D"_blank">http://= www.cs.berkeley.edu/~lazzaro</a><br> john [dot] lazzaro [at] gmail [dot] com<br> _______________________________________________<br> Audio/Video Transport Working Group<br> <a href=3D"mailto:avt@ietf.org">avt@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/avt" target=3D"_blank">htt= ps://www.ietf.org/mailman/listinfo/avt</a><br> </font></blockquote></div><br> --001636c5afb6b6ca8d046b1003da-- From versteb@cisco.com Fri May 29 12:39:28 2009 Return-Path: <versteb@cisco.com> X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E3EC3A6FE7 for <avt@core3.amsl.com>; Fri, 29 May 2009 12:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.17 X-Spam-Level: X-Spam-Status: No, score=-6.17 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_00=-2.599, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fxf4zDnHQhFg for <avt@core3.amsl.com>; Fri, 29 May 2009 12:39:21 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id C86C93A6E90 for <avt@ietf.org>; Fri, 29 May 2009 12:37:47 -0700 (PDT) X-Files: rfcdiff.txt : 23415 X-IronPort-AV: E=Sophos;i="4.41,272,1241395200"; d="txt'?scan'208";a="45576038" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 29 May 2009 19:39:31 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n4TJdVNO020443 for <avt@ietf.org>; Fri, 29 May 2009 15:39:31 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n4TJdV2F004348 for <avt@ietf.org>; Fri, 29 May 2009 19:39:31 GMT Received: from xmb-rtp-21d.amer.cisco.com ([64.102.31.116]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 May 2009 15:39:31 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C9E095.2FC51AFD" Date: Fri, 29 May 2009 15:39:30 -0400 Message-ID: <81B9B88E2F9D574AA5328A85547CDE9101495636@xmb-rtp-21d.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540954DB8A@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions(RAMS) as a working group item Thread-Index: AcnS4FBFJRh0kTNdSKKujynDJmWrDwAJMQ/AAC+GL9AAAGUFAAAXW2jQAA+eDnAASHsCkALEQgYw References: <fa05fd7ad709f.d709ffa05fd7a@huawei.com> <81B9B88E2F9D574AA5328A85547CDE91013038E4@xmb-rtp-21d.amer.cisco.com> <81B9B88E2F9D574AA5328A85547CDE9101303DA5@xmb-rtp-21d.amer.cisco.com> <00dc01c9d3c5$7a323aa0$6e96afe0$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D54094C3DBF@xmb-sjc-215.amer.cisco.com> <000a01c9d461$813bdcb0$83b39610$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540954DB8A@xmb-sjc-215.amer.cisco.com> From: "Bill Ver Steeg (versteb)" <versteb@cisco.com> To: <avt@ietf.org> X-OriginalArrivalTime: 29 May 2009 19:39:31.0298 (UTC) FILETIME=[2FC55420:01C9E095] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=33158; t=1243625971; x=1244489971; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=versteb@cisco.com; z=From:=20=22Bill=20Ver=20Steeg=20(versteb)=22=20<versteb@ci sco.com> |Subject:=20RE=3A=20[AVT]=20Adopting=20Rapid=20Acquisition= 20of=20Multicast=20RTP=09Sessions(RAMS)=20as=20a=20working=2 0group=20item |Sender:=20 |To:=20<avt@ietf.org>; bh=uotSmSvb4cGCnD5wSUjOxzdR6Fx3H0S55SDnIyf84VU=; b=MQMViI7WaZ+9/mLqr0pFEWZ+K0Avl1k/1NXZm1gBv5TxzUjEywn/AIOHkO o5E1WJ809tTi1o3atAkN4Rn/hWkW160fVvOxBX5Qpx8ypx0V+Er/DO/IgSMU XJh9Oab6/k; Authentication-Results: rtp-dkim-2; header.From=versteb@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions(RAMS) as a working group item X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group <avt.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/avt> List-Post: <mailto:avt@ietf.org> List-Help: <mailto:avt-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 29 May 2009 19:39:28 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9E095.2FC51AFD Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Fellow AVT folks- We are continuing to solicit comments on the RAMS design points identified in Ali's email from May 15 (diff enclosed). We have received some valuable feedback. We hope to have a new draft mid next week, and will incorporate comments that we receive through Monday or Tuesday in that draft. Thanks in advance Bill VerSteeg -----Original Message----- From: Ali C. Begen (abegen)=20 Sent: Friday, May 15, 2009 1:32 PM To: Roni Even; Bill Ver Steeg (versteb); avt@ietf.org Subject: RE: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions(RAMS) as a working group item Hi Roni, All, Here is a diff for sections 7 and 13.=20 Comments are welcome. -acbegen ------_=_NextPart_001_01C9E095.2FC51AFD Content-Type: text/plain; name="rfcdiff.txt" Content-Transfer-Encoding: base64 Content-Description: rfcdiff.txt Content-Disposition: attachment; filename="rfcdiff.txt" U2VjdGlvbiA3LiwgcGFyYWdyYXBoIDE6DQpPTEQ6DQoNCiAgICBUaGlzIHNlY3Rpb24gZGVmaW5l cyB0aGUgZm9ybWF0cyBvZiB0aGUgUlRDUCB0cmFuc3BvcnQtbGF5ZXIgZmVlZGJhY2sNCiAgICBt ZXNzYWdlcyB0aGF0IGFyZSBleGNoYW5nZWQgYmV0d2VlbiB0aGUgUmV0cmFuc21pc3Npb24gU2Vy dmVyIChSUykNCiAgICBhbmQgUlRQIFJlY2VpdmVyIChSUikgZHVyaW5nIHJhcGlkIGFjcXVpc2l0 aW9uLiAgVGhlc2UgbWVzc2FnZXMgYXJlDQogICAgcGF5bG9hZC1pbmRlcGVuZGVudCBhbmQgTVVT VCBiZSB1c2VkIGJ5IGFsbCBSVFAtYmFzZWQgbXVsdGljYXN0DQogICAgYXBwbGljYXRpb25zIHRo YXQgc3VwcG9ydCByYXBpZCBhY3F1aXNpdGlvbiByZWdhcmRsZXNzIG9mIHRoZSBwYXlsb2FkDQog ICAgdGhleSBjYXJyeS4NCg0KTkVXOg0KDQogICAgVGhpcyBzZWN0aW9uIGRlZmluZXMgdGhlIGZv cm1hdHMgb2YgdGhlIFJUQ1AgdHJhbnNwb3J0LWxheWVyIGZlZWRiYWNrDQogICAgbWVzc2FnZXMg dGhhdCBhcmUgZXhjaGFuZ2VkIGJldHdlZW4gdGhlIFJldHJhbnNtaXNzaW9uIFNlcnZlciAoUlMp DQogICAgYW5kIFJUUCBSZWNlaXZlciAoUlIpIGR1cmluZyByYXBpZCBhY3F1aXNpdGlvbi4gIFRo ZXNlIG1lc3NhZ2VzIGFyZQ0KICAgIHJlZmVycmVkIHRvIGFzIHRoZSBSQU1TIE1lc3NhZ2VzLiAg VGhleSBhcmUgcGF5bG9hZC1pbmRlcGVuZGVudCBhbmQNCiAgICBNVVNUIGJlIHVzZWQgYnkgYWxs IFJUUC1iYXNlZCBtdWx0aWNhc3QgYXBwbGljYXRpb25zIHRoYXQgc3VwcG9ydA0KICAgIHJhcGlk IGFjcXVpc2l0aW9uIHJlZ2FyZGxlc3Mgb2YgdGhlIHBheWxvYWQgdGhleSBjYXJyeS4NCg0KDQpT ZWN0aW9uIDcuLCBwYXJhZ3JhcGggMjoNCk9MRDoNCg0KICAgIFNwZWNpZmljIHBheWxvYWQgZm9y bWF0cyBhcmUgbm90IGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCwgYnV0IGENCiAgICBmcmFtZXdv cmsgaXMgcHJlc2VudGVkIHRoYXQgYWxsb3dzIHBheWxvYWQtc3BlY2lmaWMgaW5mb3JtYXRpb24g dG8gYmUNCiAgICBpbmNsdWRlZCBpbiB0aGUgZXhjaGFuZ2UuDQoNCk5FVzoNCg0KICAgIFBheWxv YWQtc3BlY2lmaWMgZmVlZGJhY2sgbWVzc2FnZXMgYXJlIG5vdCBkZWZpbmVkIGluIHRoaXMgZG9j dW1lbnQsDQogICAgYnV0IGFuIGV4dGVuc2lvbiBtZWNoYW5pc20gaXMgcHJvdmlkZWQgd2hlcmUg ZnVydGhlciBvcHRpb25hbA0KICAgIHBheWxvYWQtaW5kZXBlbmRlbnQgYW5kIHBheWxvYWQtc3Bl Y2lmaWMgaW5mb3JtYXRpb24gY2FuIGJlIGluY2x1ZGVkDQogICAgaW4gdGhlIGV4Y2hhbmdlLg0K DQoNClNlY3Rpb24gNy4sIHBhcmFncmFwaCAzOg0KT0xEOg0KDQogICAgVGhlIGNvbW1vbiBwYWNr ZXQgZm9ybWF0IGZvciB0aGUgUlRDUCBmZWVkYmFjayBtZXNzYWdlcyBpcyBkZWZpbmVkIGluDQog ICAgU2VjdGlvbiA2LjEgb2YgW1JGQzQ1ODVdLiAgRWFjaCBmZWVkYmFjayBtZXNzYWdlIGhhcyBh IGZpeGVkLWxlbmd0aA0KICAgIGZpZWxkIGZvciB2ZXJzaW9uLCBwYWRkaW5nLCBmZWVkYmFjayBt ZXNzYWdlIHR5cGUgKEZNVCksIHBheWxvYWQgdHlwZQ0KICAgIChQVCksIGxlbmd0aCwgU1NSQyBv ZiBwYWNrZXQgc2VuZGVyLCBTU1JDIG9mIG1lZGlhIHNvdXJjZSBhcyB3ZWxsIGFzDQogICAgYSB2 YXJpYWJsZS1sZW5ndGggZmllbGQgZm9yIGZlZWRiYWNrIGNvbnRyb2wgaW5mb3JtYXRpb24gKEZD SSkuICBJbg0KICAgIHRoZSB0cmFuc3BvcnQtbGF5ZXIgZmVlZGJhY2sgbWVzc2FnZXMsIHRoZSBQ VCBmaWVsZCBpcyBzZXQgdG8gUlRQRkINCiAgICAoMjA1KS4NCg0KTkVXOg0KDQogICAgVGhlIGNv bW1vbiBwYWNrZXQgZm9ybWF0IGZvciB0aGUgUlRDUCBmZWVkYmFjayBtZXNzYWdlcyBpcyBkZWZp bmVkIGluDQogICAgU2VjdGlvbiA2LjEgb2YgW1JGQzQ1ODVdLiAgRWFjaCBmZWVkYmFjayBtZXNz YWdlIGhhcyBhIGZpeGVkLWxlbmd0aA0KICAgIGZpZWxkIGZvciB2ZXJzaW9uLCBwYWRkaW5nLCBm ZWVkYmFjayBtZXNzYWdlIHR5cGUgKEZNVCksIHBheWxvYWQgdHlwZQ0KICAgIChQVCksIGxlbmd0 aCwgU1NSQyBvZiBwYWNrZXQgc2VuZGVyLCBTU1JDIG9mIG1lZGlhIHNvdXJjZSBhcyB3ZWxsIGFz DQogICAgYSB2YXJpYWJsZS1sZW5ndGggZmllbGQgZm9yIGZlZWRiYWNrIGNvbnRyb2wgaW5mb3Jt YXRpb24gKEZDSSkuDQoNCg0KU2VjdGlvbiA3LiwgcGFyYWdyYXBoIDQ6DQpPTEQ6DQoNCiAgICBJ biB0aGUgZmVlZGJhY2sgbWVzc2FnZXMgZGVmaW5lZCBpbiB0aGlzIHNlY3Rpb24sIG9wdGlvbmFs IGV4dGVuc2lvbnMNCiAgICBhcmUgZW5jb2RlZCBieSB1c2luZyBUTFYgZWxlbWVudHMgYXMgZGVz Y3JpYmVkIGJlbG93IGFuZCBza2V0Y2hlZCBpbg0KICAgIEZpZ3VyZSA0Og0KDQpORVc6DQoNCiAg ICBJbiB0aGUgUkFNUyBtZXNzYWdlcywgdGhlIFBUIGZpZWxkIGlzIHNldCB0byBSVFBGQiAoMjA1 KSBhbmQgdGhlIEZNVA0KICAgIGZpZWxkIGlzIHNldCB0byBSQU1TICg2KS4gIEluZGl2aWR1YWwg UkFNUyBtZXNzYWdlcyBhcmUgaWRlbnRpZmllZCBieQ0KICAgIGEgc3ViLWZpZWxkIGNhbGxlZCBT dWIgRmVlZGJhY2sgTWVzc2FnZSBUeXBlIChTRk1UKS4NCiANCiA3LjEuICBFeHRlbnNpb25zDQog DQogICAgVG8gaW1wcm92ZSB0aGUgZnVuY3Rpb25hbGl0eSBvZiB0aGUgUkFNUyBtZXRob2QgaW4g Y2VydGFpbg0KICAgIGFwcGxpY2F0aW9ucywgaXQgbWF5IGJlIGRlc2lyYWJsZSB0byBkZWZpbmUg bmV3IGZpZWxkcyBpbiB0aGUgUkFNUw0KICAgIFJlcXVlc3QsIEluZm9ybWF0aW9uIGFuZCBUZXJt aW5hdGlvbiBtZXNzYWdlcy4gIFN1Y2ggZmllbGRzIE1VU1QgYmUNCiAgICBlbmNvZGVkIGFzIFRM ViBlbGVtZW50cyBhcyBkZXNjcmliZWQgYmVsb3cgYW5kIHNrZXRjaGVkIGluIEZpZ3VyZSA0Og0K DQoNClNlY3Rpb24gNy4sIHBhcmFncmFwaCA2Og0KT0xEOg0KDQogICAgbyAgTGVuZ3RoOiAgQSB0 d28tb2N0ZXQgZmllbGQgdGhhdCBpbmRpY2F0ZXMgdGhlIGxlbmd0aCBvZiB0aGUgVmFsdWUNCiAg ICAgICBmaWVsZCBpbiBvY3RldHMuDQoNCk5FVzoNCg0KICAgIG8gIExlbmd0aDogIEEgdHdvLW9j dGV0IGZpZWxkIHRoYXQgaW5kaWNhdGVzIHRoZSBsZW5ndGggb2YgdGhlIFRMVg0KICAgICAgIGVs ZW1lbnQgZXhjbHVkaW5nIHRoZSBUeXBlIGFuZCBMZW5ndGggZmllbGRzIGluIG9jdGV0cy4gIE5v dGUgdGhhdA0KICAgICAgIHRoaXMgbGVuZ3RoIGRvZXMgbm90IGluY2x1ZGUgYW55IHBhZGRpbmcg dGhhdCBpcyByZXF1aXJlZCBmb3INCiAgICAgICBhbGlnbm1lbnQuDQoNCg0KU2VjdGlvbiA3Liwg cGFyYWdyYXBoIDk6DQpPTEQ6DQoNCiAgICAgICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAg ICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzDQogICAgICAgMCAxIDIgMyA0IDUgNiA3 IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxDQogICAgICAr LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKw0KICAgICAgfCAgICAgVHlwZSAgICAgIHwgICAgICAgICAgICBMZW5ndGggICAgICAg ICAgICAgfCAgICAgVmFsdWUgICAgIHwNCiAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAgICB8ICAgICAgICAg ICAgICAgICAgICAgICAgICBWYWx1ZSBjb250ZC4gICAgICAgICAgICAgICAgICAgICAgICAgLw0K ICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSsNCg0KTkVXOg0KDQogICAgSW4gYW4gUkFNUyBtZXNzYWdlIGFueSB2ZW5k b3ItbmV1dHJhbCBvciBwcml2YXRlIGV4dGVuc2lvbiBNVVNUIGJlDQogICAgcGxhY2VkIGFmdGVy IHRoZSBtYW5kYXRvcnkgZmllbGRzIChpZiBhbnkpLiAgVGhlIHN1cHBvcnQgZm9yDQogICAgZXh0 ZW5zaW9ucyBpcyBPUFRJT05BTC4NCiANCiAgICAgICAwICAgICAgICAgICAgICAgICAgIDEgICAg ICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzDQogICAgICAgMCAxIDIgMyA0IDUg NiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxDQogICAg ICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKw0KICAgICAgfCAgICAgVHlwZSAgICAgIHwgICAgICAgICAgICBMZW5ndGggICAg ICAgICAgICAgfCAgICAgVmFsdWUgICAgIHwNCiAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAgICB8ICAgICAg ICAgICAgICAgICAgICAgICAgICBWYWx1ZSBjb250ZC4gICAgICAgICAgICAgICAgICAgICAgICAg Lw0KICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSsNCg0KDQpTZWN0aW9uIDcuLCBwYXJhZ3JhcGggMTA6DQpPTEQ6DQoN CiAgICAgICAgICAgICAgICAgICAgRmlndXJlIDQ6IFN0cnVjdHVyZSBvZiBhIFRMViBlbGVtZW50 DQogICAgRWRpdG9yJ3Mgbm90ZTogIFRoZSBvcHRpb25hbCBmaWVsZHMgaW4gdGhlIFJBTVMgbWVz c2FnZXMgKGRlZmluZWQNCiAgICBiZWxvdykgd2lsbCBiZSBjb252ZXJ0ZWQgdG8gVExWIGVsZW1l bnRzIGluIGEgbGF0ZXIgdmVyc2lvbiBvZiB0aGlzDQogICAgZG9jdW1lbnQuDQoNCk5FVzoNCg0K ICAgICAgICAgICAgICAgICAgICBGaWd1cmUgNDogU3RydWN0dXJlIG9mIGEgVExWIGVsZW1lbnQN Cg0KDQpTZWN0aW9uIDcuLCBwYXJhZ3JhcGggMTE6DQpPTEQ6DQoNCiA3LjEuICBSQU1TIFJlcXVl c3QNCg0KTkVXOg0KDQogNy4xLjEuICBWZW5kb3ItTmV1dHJhbCBFeHRlbnNpb25zDQoNCg0KU2Vj dGlvbiA3LiwgcGFyYWdyYXBoIDEyOg0KT0xEOg0KDQogICAgVGhlIFJBTVMgUmVxdWVzdCBtZXNz YWdlIGlzIGlkZW50aWZpZWQgYnkgUFQ9UlRQRkIgYW5kIEZNVD02Lg0KDQpORVc6DQoNCiAgICBJ ZiB0aGUgZ29hbCBpbiBkZWZpbmluZyBuZXcgVExWIGVsZW1lbnRzIGlzIHRvIGV4dGVuZCB0aGUN CiAgICBmdW5jdGlvbmFsaXR5IGluIGEgdmVuZG9yLW5ldXRyYWwgbWFubmVyLCB0aGV5IE1VU1Qg YmUgcmVnaXN0ZXJlZA0KICAgIHdpdGggSUFOQSB0aHJvdWdoIHRoZSBndWlkZWxpbmVzIHByb3Zp ZGVkIGluIFNlY3Rpb24gMTMuNC4NCiANCiAgICBUaGUgY3VycmVudCBkb2N1bWVudCBkZWZpbmVz IHNldmVyYWwgdmVuZG9yLW5ldXRyYWwgZXh0ZW5zaW9ucyBpbiB0aGUNCiAgICBmb2xsb3dpbmcg c2VjdGlvbnMuDQogDQogNy4xLjIuICBQcml2YXRlIEV4dGVuc2lvbnMNCiANCiAgICBJdCBpcyBk ZXNpcmFibGUgdG8gYWxsb3cgdmVuZG9ycyB0byB1c2UgcHJpdmF0ZSBleHRlbnNpb25zIGluIFRM Vg0KICAgIGZvcm1hdC4gIEZvciBpbnRlcm9wZXJhYmlsaXR5LCBzdWNoIGV4dGVuc2lvbnMgTVVT VCBOT1QgY29sbGlkZSB3aXRoDQogICAgZWFjaCBvdGhlci4NCiANCiAgICBBIGNlcnRhaW4gcmFu Z2Ugb2YgVExWIFR5cGVzIGlzIHJlc2VydmVkIGZvciBwcml2YXRlIGV4dGVuc2lvbnMNCiAgICAo UmVmZXIgdG8gU2VjdGlvbiAxMy40KS4gIElBTkEgbWFuYWdlbWVudCBmb3IgdGhlc2UgZXh0ZW5z aW9ucyBpcw0KICAgIHVubmVjZXNzYXJ5IGFuZCB0aGV5IGFyZSB0aGUgcmVzcG9uc2liaWxpdHkg b2YgaW5kaXZpZHVhbCB2ZW5kb3JzLg0KIA0KICAgIFRoZSBzdHJ1Y3R1cmUgdGhhdCBNVVNUIGJl IHVzZWQgZm9yIHRoZSBwcml2YXRlIGV4dGVuc2lvbnMgaXMNCiAgICBkZXBpY3RlZCBpbiBGaWd1 cmUgNS4gIEhlcmUsIHRoZSBlbnRlcnByaXNlIG51bWJlcnMgYXJlIHVzZWQgZnJvbQ0KICAgIGh0 dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvZW50ZXJwcmlzZS1udW1iZXJzLiAgVGhpcyB3 aWxsIGVuc3VyZQ0KICAgIHRoZSB1bmlxdWVuZXNzIG9mIHRoZSBwcml2YXRlIGV4dGVuc2lvbnMg YW5kIGF2b2lkIGFueSBjb2xsaXNpb24uDQogDQogICAgICAgMCAgICAgICAgICAgICAgICAgICAx ICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMw0KICAgICAgIDAgMSAyIDMg NCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0K ICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSsNCiAgICAgIHwgICAgICBUeXBlICAgICB8ICAgICAgICAgICAgTGVuZ3Ro ICAgICAgICAgICAgIHwgIEVudC4gTnVtYmVyICB8DQogICAgICArLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICAgfCAg ICAgICAgICAgICAgIEVudC4gTnVtYmVyIGNvbnRkLiAgICAgICAgICAgICAgfCAgICAgVmFsdWUg ICAgIHwNCiAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rDQogICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICBW YWx1ZSBjb250ZC4gICAgICAgICAgICAgICAgICAgICAgICAgLw0KICAgICAgKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAN CiAgICAgICAgICAgICAgICAgRmlndXJlIDU6IFN0cnVjdHVyZSBvZiBhIHByaXZhdGUgZXh0ZW5z aW9uDQogDQogNy4yLiAgUkFNUyBSZXF1ZXN0DQogDQogICAgVGhlIFJBTVMgUmVxdWVzdCBtZXNz YWdlIGlzIGlkZW50aWZpZWQgYnkgU0ZNVD0xLg0KDQoNClNlY3Rpb24gNy4sIHBhcmFncmFwaCAx NToNCk9MRDoNCg0KICAgIFRoZSBGQ0kgZmllbGQgaGFzIHRoZSBzdHJ1Y3R1cmUgZGVwaWN0ZWQg aW4gRmlndXJlIDUuDQoNCk5FVzoNCg0KICAgIFRoZSBGQ0kgZmllbGQgaGFzIHRoZSBzdHJ1Y3R1 cmUgZGVwaWN0ZWQgaW4gRmlndXJlIDYuDQoNCg0KU2VjdGlvbiA3LiwgcGFyYWdyYXBoIDE3Og0K T0xEOg0KDQogICAgICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIg ICAgICAgICAgICAgICAgICAgMw0KICAgICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0 IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KICAgICAgKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAg IHwgICAgICAgICAgICAgICBNaW4gUkFNUyBCdWZmZXIgRmlsbCBSZXF1aXJlbWVudCAgICAgICAg ICAgICAgICB8DQogICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICAgfCAgICAgICAgICAgICAgIE1heCBSQU1T IEJ1ZmZlciBGaWxsIFJlcXVpcmVtZW50ICAgICAgICAgICAgICAgIHwNCiAgICAgICstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r DQogICAgICB8ICAgICAgICAgICAgICAgICAgICAgICBNYXggUmVjZWl2ZSBCaXRyYXRlICAgICAg ICAgICAgICAgICAgICAgfA0KICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgIDogICAgICAgICAgICAgICAg ICAgIChUTFYtZW5jb2RlZCBFeHRlbnNpb25zKSAgICAgICAgICAgICAgICAgICA6DQogICAgICA6 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgOg0KICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSsNCg0KTkVXOg0KDQogICAgICAgMCAgICAgICAgICAgICAg ICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMw0KICAgICAgIDAg MSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5 IDAgMQ0KICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgIHwgICAgU0ZNVD0xICAgICB8ICAgICAgICAgIE9w dGlvbmFsIFRMVi1lbmNvZGVkIEZpZWxkcyAgICAgICAgICB8DQogICAgICArLSstKy0rLSstKy0r LSstKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAg ICAgOiAgICAgIE9wdGlvbmFsIFRMVi1lbmNvZGVkIEZpZWxkcyAoYW5kIFBhZGRpbmcsIGlmIG5l ZWRlZCkgICAgIDoNCiAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQoNCg0KU2VjdGlvbiA3LiwgcGFyYWdyYXBoIDE4 Og0KT0xEOg0KDQogICAgICAgICAgIEZpZ3VyZSA1OiBGQ0kgZmllbGQgc3ludGF4IGZvciB0aGUg UkFNUyBSZXF1ZXN0IG1lc3NhZ2UNCg0KTkVXOg0KDQogICAgICAgICAgIEZpZ3VyZSA2OiBGQ0kg ZmllbGQgc3ludGF4IGZvciB0aGUgUkFNUyBSZXF1ZXN0IG1lc3NhZ2UNCg0KDQpTZWN0aW9uIDcu LCBwYXJhZ3JhcGggMjI6DQpPTEQ6DQoNCiAgICBvICBNYXggUkFNUyBCdWZmZXIgRmlsbCBSZXF1 aXJlbWVudCAoMzIgYml0cyk6ICBPcHRpb25hbCBUTFYgZWxlbWVudA0KICAgICAgIHRoYXQgZGVu b3RlcyB0aGUgbWF4aW11bSBudW1iZXIgb2Ygb2N0ZXRzIG9mIGNvbnRlbnQgdGhlIFJUUA0KICAg ICAgIHJlY2VpdmVyIGNhbiBidWZmZXIgd2l0aG91dCBsb3NpbmcgdGhlIGJ1cnN0IGRhdGEgZHVl IHRvIGJ1ZmZlcg0KICAgICAgIG92ZXJmbG93Lg0KDQpORVc6DQoNCiAgICAgICBUeXBlOiAgVEJE DQogDQogICAgICAgTGVuZ3RoOiAgVEJEDQogICAgbyAgTWF4IFJBTVMgQnVmZmVyIEZpbGwgUmVx dWlyZW1lbnQgKDMyIGJpdHMpOiAgT3B0aW9uYWwgVExWIGVsZW1lbnQNCiAgICAgICB0aGF0IGRl bm90ZXMgdGhlIG1heGltdW0gbnVtYmVyIG9mIG9jdGV0cyBvZiBjb250ZW50IHRoZSBSVFANCiAg ICAgICByZWNlaXZlciBjYW4gYnVmZmVyIHdpdGhvdXQgbG9zaW5nIHRoZSBidXJzdCBkYXRhIGR1 ZSB0byBidWZmZXINCiAgICAgICBvdmVyZmxvdy4NCg0KDQpTZWN0aW9uIDcuLCBwYXJhZ3JhcGgg MjU6DQpPTEQ6DQoNCiAgICBvICBNYXggUmVjZWl2ZSBCaXRyYXRlICgzMiBiaXRzKTogIE9wdGlv bmFsIFRMViBlbGVtZW50IHRoYXQgZGVub3Rlcw0KICAgICAgIHRoZSBtYXhpbXVtIGJpdHJhdGUg KGluIGJpdHMgcGVyIHNlY29uZCkgdGhhdCB0aGUgUlRQIHJlY2VpdmVyIGNhbg0KICAgICAgIHBy b2Nlc3MgdGhlIHVuaWNhc3QgYnVyc3QuICBUaGlzIHJhdGUgc2hvdWxkIGluY2x1ZGUgd2hhdGV2 ZXINCiAgICAgICBrbm93bGVkZ2UgdGhlIHJlY2VpdmVyIGhhcyB0aGF0IHdvdWxkIHByb3ZpZGUg YW4gdXBwZXIgYm91bmQgb24NCiAgICAgICB0aGUgdW5pY2FzdCBidXJzdCBiaXRyYXRlLiAgVGhl IGxpbWl0cyBtYXkgaW5jbHVkZSBsb2NhbCByZWNlaXZlcg0KICAgICAgIGxpbWl0cyBhcyB3ZWxs IGFzIG5ldHdvcmsgbGltaXRzIHRoYXQgYXJlIGtub3duIHRvIHRoZSByZWNlaXZlci4NCg0KTkVX Og0KDQogICAgICAgVHlwZTogIFRCRA0KIA0KICAgICAgIExlbmd0aDogIFRCRA0KIA0KICAgIG8g IE1heCBSZWNlaXZlIEJpdHJhdGUgKDMyIGJpdHMpOiAgT3B0aW9uYWwgVExWIGVsZW1lbnQgdGhh dCBkZW5vdGVzDQogICAgICAgdGhlIG1heGltdW0gYml0cmF0ZSAoaW4gYml0cyBwZXIgc2Vjb25k KSB0aGF0IHRoZSBSVFAgcmVjZWl2ZXIgY2FuDQogICAgICAgcHJvY2VzcyB0aGUgdW5pY2FzdCBi dXJzdC4gIFRoaXMgcmF0ZSBzaG91bGQgaW5jbHVkZSB3aGF0ZXZlcg0KICAgICAgIGtub3dsZWRn ZSB0aGUgcmVjZWl2ZXIgaGFzIHRoYXQgd291bGQgcHJvdmlkZSBhbiB1cHBlciBib3VuZCBvbg0K ICAgICAgIHRoZSB1bmljYXN0IGJ1cnN0IGJpdHJhdGUuICBUaGUgbGltaXRzIG1heSBpbmNsdWRl IGxvY2FsIHJlY2VpdmVyDQogICAgICAgbGltaXRzIGFzIHdlbGwgYXMgbmV0d29yayBsaW1pdHMg dGhhdCBhcmUga25vd24gdG8gdGhlIHJlY2VpdmVyLg0KDQoNClNlY3Rpb24gNy4sIHBhcmFncmFw aCAyNzoNCk9MRDoNCg0KICAgIFRoZSBzZW1hbnRpY3Mgb2YgdGhlIFJBTVMtUiBmZWVkYmFjayBt ZXNzYWdlIGlzIGluZGVwZW5kZW50IG9mIHRoZQ0KICAgIHBheWxvYWQgdHlwZS4NCg0KTkVXOg0K DQogICAgICAgVHlwZTogIFRCRA0KIA0KICAgICAgIExlbmd0aDogIFRCRA0KIA0KICAgIFRoZSBz ZW1hbnRpY3Mgb2YgdGhlIFJBTVMtUiBmZWVkYmFjayBtZXNzYWdlIGlzIGluZGVwZW5kZW50IG9m IHRoZQ0KICAgIHBheWxvYWQgdHlwZS4NCg0KDQpTZWN0aW9uIDcuLCBwYXJhZ3JhcGggMjg6DQpP TEQ6DQoNCiA3LjIuICBSQU1TIEluZm9ybWF0aW9uDQoNCk5FVzoNCg0KIDcuMy4gIFJBTVMgSW5m b3JtYXRpb24NCg0KDQpTZWN0aW9uIDcuLCBwYXJhZ3JhcGggMjk6DQpPTEQ6DQoNCiAgICBUaGUg UkFNUyBJbmZvcm1hdGlvbiBtZXNzYWdlIGlzIGlkZW50aWZpZWQgYnkgUFQ9UlRQRkIgYW5kIEZN VD03Lg0KDQpORVc6DQoNCiAgICBUaGUgUkFNUyBJbmZvcm1hdGlvbiBtZXNzYWdlIGlzIGlkZW50 aWZpZWQgYnkgU0ZNVD0yLg0KDQoNClNlY3Rpb24gNy4sIHBhcmFncmFwaCAzMjoNCk9MRDoNCg0K ICAgIFRoZSBGQ0kgZmllbGQgaGFzIHRoZSBzdHJ1Y3R1cmUgZGVwaWN0ZWQgaW4gRmlndXJlIDYu DQoNCk5FVzoNCg0KICAgIFRoZSBGQ0kgZmllbGQgaGFzIHRoZSBzdHJ1Y3R1cmUgZGVwaWN0ZWQg aW4gRmlndXJlIDcuDQoNCg0KU2VjdGlvbiA3LiwgcGFyYWdyYXBoIDMzOg0KT0xEOg0KDQogICAg ICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAg ICAgICAgMw0KICAgICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAw IDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgIHwgICAgICBNU04g ICAgfFN8ICAgUmVzcG9uc2UgICAgfCAgICAgICAgICAgICBSc3ZkLiAgICAgICAgICAgICB8DQog ICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKw0KICAgICAgfCAgICAgICAgRXh0ZW5kZWQgUlRQIFNlcW51bSBvZiB0aGUg Rmlyc3QgQnVyc3QgUGFja2V0ICAgICAgICAgIHwNCiAgICAgICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAgICB8ICAg ICAgICAgICAgICAgICAgRWFybGllc3QgTXVsdGljYXN0IEpvaW4gVGltZSAgICAgICAgICAgICAg ICAgfA0KICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgQnVy c3QgRHVyYXRpb24gICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICArLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAg ICAgfCAgICAgICAgICAgICAgICAgICAgICAgTWF4IEJ1cnN0IEJpdHJhdGUgICAgICAgICAgICAg ICAgICAgICAgIHwNCiAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAgICA6ICAgICAgICAgICAgICAgICAgICAo VExWLWVuY29kZWQgRXh0ZW5zaW9ucykgICAgICAgICAgICAgICAgICAgOg0KICAgICAgOiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IDoNCiAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rDQoNCk5FVzoNCg0KICAgICAgIDAgICAgICAgICAgICAgICAgICAg MSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMNCiAgICAgICAwIDEgMiAz IDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEN CiAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rDQogICAgICB8ICAgIFNGTVQ9MiAgICAgfCAgICAgIE1TTiAgICB8U3wg ICBSZXNwb25zZSAgICB8ICAgICBSc3ZkLiAgICAgfA0KICAgICAgKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgIHwg ICAgICAgIEV4dGVuZGVkIFJUUCBTZXFudW0gb2YgdGhlIEZpcnN0IEJ1cnN0IFBhY2tldCAgICAg ICAgICB8DQogICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICAgOiAgICAgIE9wdGlvbmFsIFRMVi1lbmNvZGVk IEZpZWxkcyAoYW5kIFBhZGRpbmcsIGlmIG5lZWRlZCkgICAgIDoNCiAgICAgICstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQoN Cg0KU2VjdGlvbiA3LiwgcGFyYWdyYXBoIDM0Og0KT0xEOg0KDQogICAgICAgICBGaWd1cmUgNjog RkNJIGZpZWxkIHN5bnRheCBmb3IgdGhlIFJBTVMgSW5mb3JtYXRpb24gbWVzc2FnZQ0KDQpORVc6 DQoNCiAgICAgICAgIEZpZ3VyZSA3OiBGQ0kgZmllbGQgc3ludGF4IGZvciB0aGUgUkFNUyBJbmZv cm1hdGlvbiBtZXNzYWdlDQoNCg0KU2VjdGlvbiA3LiwgcGFyYWdyYXBoIDQxOg0KT0xEOg0KDQog ICAgICAgMS4gIFN1Y2Nlc3MNCiANCiAgICAgICAyLiAgQmFkX1JlcXVlc3QNCg0KTkVXOg0KDQog ICAgICAgMS4gIFN1Y2Nlc3MNCiAgICAgICAyLiAgQmFkX1JlcXVlc3QNCg0KDQpTZWN0aW9uIDcu LCBwYXJhZ3JhcGggNDU6DQpPTEQ6DQoNCiAgICBvICBSc3ZkICgxNiBiaXRzKTogIFJlc2VydmVk LiAgVGhpcyBmaWVsZCBTSEFMTCBiZSBzZXQgdG8gMC4NCg0KTkVXOg0KDQogICAgbyAgUnN2ZCAo OCBiaXRzKTogIFJlc2VydmVkLiAgVGhpcyBmaWVsZCBTSEFMTCBiZSBzZXQgdG8gMC4NCg0KDQpT ZWN0aW9uIDcuLCBwYXJhZ3JhcGggNTA6DQpPTEQ6DQoNCiAgICBvICBCdXJzdCBEdXJhdGlvbiAo MzIgYml0cyk6ICBPcHRpb25hbCBUTFYgZWxlbWVudCB0aGF0IGRlbm90ZXMgdGhlDQogICAgICAg ZHVyYXRpb24gb2YgdGhlIGJ1cnN0IHRoYXQgUlMgaXMgcGxhbm5pbmcgdG8gc2VuZCAoaW4gUlRQ IHRpY2tzKS4NCiAgICAgICBJbiB0aGUgYWJzZW5jZSBvZiBhZGRpdGlvbmFsIHN0aW11bHVzLCBS UyB3aWxsIHNlbmQgYSBidXJzdCBvZg0KICAgICAgIHRoaXMgZHVyYXRpb24uICBIb3dldmVyLCB0 aGUgYnVyc3QgZHVyYXRpb24gbWF5IGJlIG1vZGlmaWVkIGJ5DQogICAgICAgc3Vic2VxdWVudCBl dmVudHMsIGluY2x1ZGluZyBjaGFuZ2VzIGluIHRoZSBwcmltYXJ5IG11bHRpY2FzdA0KICAgICAg IHN0cmVhbSBhbmQgcmVjZXB0aW9uIG9mIFJBTVMtVCBtZXNzYWdlcy4NCg0KTkVXOg0KDQogICAg ICAgVHlwZTogIFRCRA0KIA0KICAgICAgIExlbmd0aDogIFRCRA0KIA0KICAgIG8gIEJ1cnN0IER1 cmF0aW9uICgzMiBiaXRzKTogIE9wdGlvbmFsIFRMViBlbGVtZW50IHRoYXQgZGVub3RlcyB0aGUN CiAgICAgICBkdXJhdGlvbiBvZiB0aGUgYnVyc3QgdGhhdCBSUyBpcyBwbGFubmluZyB0byBzZW5k IChpbiBSVFAgdGlja3MpLg0KICAgICAgIEluIHRoZSBhYnNlbmNlIG9mIGFkZGl0aW9uYWwgc3Rp bXVsdXMsIFJTIHdpbGwgc2VuZCBhIGJ1cnN0IG9mDQogICAgICAgdGhpcyBkdXJhdGlvbi4gIEhv d2V2ZXIsIHRoZSBidXJzdCBkdXJhdGlvbiBtYXkgYmUgbW9kaWZpZWQgYnkNCiAgICAgICBzdWJz ZXF1ZW50IGV2ZW50cywgaW5jbHVkaW5nIGNoYW5nZXMgaW4gdGhlIHByaW1hcnkgbXVsdGljYXN0 DQogICAgICAgc3RyZWFtIGFuZCByZWNlcHRpb24gb2YgUkFNUy1UIG1lc3NhZ2VzLg0KDQoNClNl Y3Rpb24gNy4sIHBhcmFncmFwaCA1MjoNCk9MRDoNCg0KICAgIG8gIE1heCBCdXJzdCBCaXRyYXRl ICgzMiBiaXRzKTogIE9wdGlvbmFsIFRMViBlbGVtZW50IHRoYXQgZGVub3Rlcw0KICAgICAgIHRo ZSBtYXhpbXVtIGJpdHJhdGUgKGluIGJpdHMgcGVyIHNlY29uZCkgdGhhdCB3aWxsIGJlIHVzZWQg YnkgUlMNCiAgICAgICBmb3IgdGhlIHVuaWNhc3QgYnVyc3QuDQoNCk5FVzoNCg0KICAgICAgIFR5 cGU6ICBUQkQNCiANCiAgICAgICBMZW5ndGg6ICBUQkQNCiANCiAgICBvICBNYXggQnVyc3QgQml0 cmF0ZSAoMzIgYml0cyk6ICBPcHRpb25hbCBUTFYgZWxlbWVudCB0aGF0IGRlbm90ZXMNCiAgICAg ICB0aGUgbWF4aW11bSBiaXRyYXRlIChpbiBiaXRzIHBlciBzZWNvbmQpIHRoYXQgd2lsbCBiZSB1 c2VkIGJ5IFJTDQogICAgICAgZm9yIHRoZSB1bmljYXN0IGJ1cnN0Lg0KDQoNClNlY3Rpb24gNy4s IHBhcmFncmFwaCA1MzoNCk9MRDoNCg0KICAgIFRoZSBzZW1hbnRpY3Mgb2YgdGhlIFJBTVMtSSBm ZWVkYmFjayBtZXNzYWdlIGlzIGluZGVwZW5kZW50IG9mIHRoZQ0KICAgIHBheWxvYWQgdHlwZS4N Cg0KTkVXOg0KDQogICAgICAgVHlwZTogIFRCRA0KIA0KICAgICAgIExlbmd0aDogIFRCRA0KIA0K ICAgIFRoZSBzZW1hbnRpY3Mgb2YgdGhlIFJBTVMtSSBmZWVkYmFjayBtZXNzYWdlIGlzIGluZGVw ZW5kZW50IG9mIHRoZQ0KICAgIHBheWxvYWQgdHlwZS4NCg0KDQpTZWN0aW9uIDcuLCBwYXJhZ3Jh cGggNTU6DQpPTEQ6DQoNCiA3LjMuICBSQU1TIFRlcm1pbmF0aW9uDQoNCk5FVzoNCg0KIDcuNC4g IFJBTVMgVGVybWluYXRpb24NCg0KDQpTZWN0aW9uIDcuLCBwYXJhZ3JhcGggNTY6DQpPTEQ6DQoN CiAgICBUaGUgUkFNUyBUZXJtaW5hdGlvbiBtZXNzYWdlIGlzIGlkZW50aWZpZWQgYnkgUFQ9UlRQ RkIgYW5kIEZNVD04Lg0KDQpORVc6DQoNCiAgICBUaGUgUkFNUyBUZXJtaW5hdGlvbiBtZXNzYWdl IGlzIGlkZW50aWZpZWQgYnkgU0ZNVD0zLg0KDQoNClNlY3Rpb24gNy4sIHBhcmFncmFwaCA2MToN Ck9MRDoNCg0KICAgIFRoZSBGQ0kgZmllbGQgaGFzIHRoZSBzdHJ1Y3R1cmUgZGVwaWN0ZWQgaW4g RmlndXJlIDcuDQoNCk5FVzoNCg0KICAgIFRoZSBGQ0kgZmllbGQgaGFzIHRoZSBzdHJ1Y3R1cmUg ZGVwaWN0ZWQgaW4gRmlndXJlIDguDQoNCg0KU2VjdGlvbiA3LiwgcGFyYWdyYXBoIDYyOg0KT0xE Og0KDQogICAgICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAg ICAgICAgICAgICAgICAgMw0KICAgICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUg NiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KICAgICAgKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgIHwg ICAgICAgICBFeHRlbmRlZCBSVFAgU2VxbnVtIG9mIEZpcnN0IE11bHRpY2FzdCBQYWNrZXQgICAg ICAgICB8DQogICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICAgOiAgICAgICAgICAgICAgICAgICAgKFRMVi1l bmNvZGVkIEV4dGVuc2lvbnMpICAgICAgICAgICAgICAgICAgIDoNCiAgICAgIDogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA6DQog ICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKw0KDQpORVc6DQoNCiAgICAgICAwICAgICAgICAgICAgICAgICAgIDEgICAg ICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzDQogICAgICAgMCAxIDIgMyA0IDUg NiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxDQogICAg ICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKw0KICAgICAgfCAgICBTRk1UPTMgICAgIHwgICAgICAgICAgT3B0aW9uYWwgVExW LWVuY29kZWQgRmllbGRzICAgICAgICAgIHwNCiAgICAgICstKy0rLSstKy0rLSstKy0rICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICA6ICAgICAg T3B0aW9uYWwgVExWLWVuY29kZWQgRmllbGRzIChhbmQgUGFkZGluZywgaWYgbmVlZGVkKSAgICAg Og0KICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSsNCg0KDQpTZWN0aW9uIDcuLCBwYXJhZ3JhcGggNjM6DQpPTEQ6DQoN CiAgICAgICAgIEZpZ3VyZSA3OiBGQ0kgZmllbGQgc3ludGF4IGZvciB0aGUgUkFNUyBUZXJtaW5h dGlvbiBtZXNzYWdlDQoNCk5FVzoNCg0KICAgICAgICAgRmlndXJlIDg6IEZDSSBmaWVsZCBzeW50 YXggZm9yIHRoZSBSQU1TIFRlcm1pbmF0aW9uIG1lc3NhZ2UNCg0KDQpTZWN0aW9uIDcuLCBwYXJh Z3JhcGggNjU6DQpPTEQ6DQoNCiAgICBUaGUgc2VtYW50aWNzIG9mIHRoZSBSQU1TLVQgZmVlZGJh Y2sgbWVzc2FnZSBpcyBpbmRlcGVuZGVudCBvZiB0aGUNCiAgICBwYXlsb2FkIHR5cGUuDQogDQog Ny40LiAgRXh0ZW5zaW9ucw0KIA0KICAgIFRvIGltcHJvdmUgdGhlIGZ1bmN0aW9uYWxpdHkgb2Yg dGhlIFJBTVMgbWV0aG9kIGluIGNlcnRhaW4NCiAgICBhcHBsaWNhdGlvbnMsIGl0IG1heSBiZSBk ZXNpcmFibGUgdG8gZGVmaW5lIG5ldyBmaWVsZHMgaW4gdGhlIFJBTVMNCiAgICBSZXF1ZXN0LCBJ bmZvcm1hdGlvbiBhbmQgVGVybWluYXRpb24gbWVzc2FnZXMuICBTdWNoIGZpZWxkcyBNVVNUIGJl DQogICAgZGVmaW5lZCBhcyBUTFYgZWxlbWVudHMuICBJZiB0aGUgZ29hbCBpbiBkZWZpbmluZyB0 aGVzZSBuZXcgZmllbGRzIGlzDQogICAgdG8gZXh0ZW5kIHRoZSBwcm90b2NvbCBpbiBhIHZlbmRv ci1uZXV0cmFsIG1hbm5lciwgdGhleSBNVVNUIGJlDQogICAgcmVnaXN0ZXJlZCB3aXRoIElBTkEg dGhyb3VnaCBhbiBJbmZvcm1hdGlvbmFsIG9yIGEgU3RhbmRhcmRzLXRyYWNrDQogICAgUkZDLiAg VGhlIHN1cHBvcnQgZm9yIHRoZXNlIG5ldyBmaWVsZHMgaXMgT1BUSU9OQUwuICBJbiBhbiBSQU1T DQogICAgbWVzc2FnZSwgYW55IGV4dGVuc2lvbiBNVVNUIGJlIHBsYWNlZCBhZnRlciBhbnkgZXhp c3RpbmcgbWFuZGF0b3J5DQogICAgZmllbGQgZm9yIHRoYXQgbWVzc2FnZS4NCiANCiAgICBFZGl0 b3IncyBub3RlOiAgV2Ugc2hvdWxkIHNwZWNpZnkgdGhlIHJlcXVpcmVtZW50cyBmb3IgcmVnaXN0 ZXJpbmcNCiAgICBuZXcgVExWIGVsZW1lbnRzLg0KIA0KICAgIEl0IGlzIGFsc28gZGVzaXJhYmxl IHRvIGFsbG93IHZlbmRvcnMgdG8gdXNlIHZlbmRvci1zcGVjaWZpYw0KICAgIGV4dGVuc2lvbnMg KGluIFRMViBmb3JtYXQpIGluIGFueSBvZiB0aGUgUkFNUyBtZXNzYWdlcy4gIEZvcg0KICAgIGlu dGVyb3BlcmFiaWxpdHksIHN1Y2ggZXh0ZW5zaW9ucyBNVVNUIE5PVCBjb2xsaWRlIHdpdGggZWFj aCBvdGhlci4NCiANCiAgICBFZGl0b3IncyBub3RlOiAgU29tZSBhcHByb2FjaGVzIGFyZSBjdXJy ZW50bHkgYmVpbmcgZXhhbWluZWQgZm9yDQogICAgdmVuZG9yLXNwZWNpZmljIGV4dGVuc2lvbnMu ICBBIHBvdGVudGlhbCBzb2x1dGlvbiBpcyBkZXBpY3RlZCBpbg0KICAgIEZpZ3VyZSA4LiAgSW4g dGhpcyBhcHByb2FjaCwgdGhlIGVudGVycHJpc2UgbnVtYmVycyBhcmUgdXNlZCBmcm9tDQogICAg aHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9lbnRlcnByaXNlLW51bWJlcnMuICBUaGlz IHdpbGwgZW5zdXJlDQogICAgdGhlIHVuaXF1ZW5lc3Mgb2YgdGhlIHZlbmRvci1zcGVjaWZpYyBl eHRlbnNpb25zLg0KDQpORVc6DQoNCiAgICAgICBUeXBlOiAgVEJEDQoNCg0KU2VjdGlvbiA3Liwg cGFyYWdyYXBoIDY2Og0KT0xEOg0KDQogICAgICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAg ICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMw0KICAgICAgIDAgMSAyIDMgNCA1IDYg NyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KICAgICAg Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSsNCiAgICAgIDogICAgICAgICAgTWFuZGF0b3J5IEZpZWxkcyBhcyBEZWZpbmVkIGlu IFRoaXMgRG9jdW1lbnQgICAgICAgICA6DQogICAgICA6ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOg0KICAgICAgKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsN CiAgICAgIHwgICBUeXBlID0gVEJEICB8ICAgICAgICAgICAgTGVuZ3RoICAgICAgICAgICAgIHwg IEVudC4gTnVtYmVyICB8DQogICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICAgfCAgICAgICAgICAgICAgIEVu dC4gTnVtYmVyIGNvbnRkLiAgICAgICAgICAgICAgfCAgICAgVmFsdWUgICAgIHwNCiAgICAgICst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rDQogICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICBWYWx1ZSBjb250ZC4gICAg ICAgICAgICAgICAgICAgICAgICAgLw0KICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCg0KTkVXOg0KDQogICAgICAg TGVuZ3RoOiAgVEJEDQoNCg0KU2VjdGlvbiA3LiwgcGFyYWdyYXBoIDY3Og0KT0xEOg0KDQogICAg ICAgICAgICAgRmlndXJlIDg6IFN0cnVjdHVyZSBvZiBhIHZlbmRvci1zcGVjaWZpYyBleHRlbnNp b24NCg0KTkVXOg0KDQogICAgVGhlIHNlbWFudGljcyBvZiB0aGUgUkFNUy1UIGZlZWRiYWNrIG1l c3NhZ2UgaXMgaW5kZXBlbmRlbnQgb2YgdGhlDQogICAgcGF5bG9hZCB0eXBlLg0KDQoNCg0KU2Vj dGlvbiAxMy4sIHBhcmFncmFwaCAxOg0KT0xEOg0KDQogICAgVGhpcyBkb2N1bWVudCByZWdpc3Rl cnMgYSBuZXcgU0RQIGF0dHJpYnV0ZSB2YWx1ZSBhbmQgc2V2ZXJhbCBuZXcNCiAgICBSVENQIHBh Y2tldHMuDQogDQogICAgVGhlIGZvbGxvd2luZyBjb250YWN0IGluZm9ybWF0aW9uIHNoYWxsIGJl IHVzZWQgZm9yIGFsbCByZWdpc3RyYXRpb25zDQogICAgaW4gdGhpcyBkb2N1bWVudDoNCg0KTkVX Og0KDQogICAgVGhlIGZvbGxvd2luZyBjb250YWN0IGluZm9ybWF0aW9uIHNoYWxsIGJlIHVzZWQg Zm9yIGFsbCByZWdpc3RyYXRpb25zDQogICAgaW4gdGhpcyBkb2N1bWVudDoNCg0KDQpTZWN0aW9u IDEzLjIuLCBwYXJhZ3JhcGggMToNCk9MRDoNCg0KICAgIFdpdGhpbiB0aGUgUlRQRkIgcmFuZ2Us IHRoZSBmb2xsb3dpbmcgdGhyZWUgZm9ybWF0IChGTVQpIHZhbHVlcyBhcmUNCiAgICByZWdpc3Rl cmVkOg0KDQpORVc6DQoNCiAgICBXaXRoaW4gdGhlIFJUUEZCIHJhbmdlLCB0aGUgZm9sbG93aW5n IGZvcm1hdCAoRk1UKSB2YWx1ZSBpcw0KICAgIHJlZ2lzdGVyZWQ6DQoNCg0KU2VjdGlvbiAxMy4y LiwgcGFyYWdyYXBoIDI6DQpPTEQ6DQoNCiAgICAgICAgIE5hbWU6ICAgICAgICAgICBSQU1TLVIN CiAgICAgICAgIExvbmcgbmFtZTogICAgICBSYXBpZCBBY3F1aXNpdGlvbiBvZiBNdWx0aWNhc3Qg U2Vzc2lvbnMgUmVxdWVzdA0KICAgICAgICAgVmFsdWU6ICAgICAgICAgIDYNCiAgICAgICAgIFJl ZmVyZW5jZTogICAgICBUaGlzIGRvY3VtZW50DQoNCk5FVzoNCg0KICAgICAgICAgTmFtZTogICAg ICAgICAgIFJBTVMNCiAgICAgICAgIExvbmcgbmFtZTogICAgICBSYXBpZCBBY3F1aXNpdGlvbiBv ZiBNdWx0aWNhc3QgU2Vzc2lvbnMNCiAgICAgICAgIFZhbHVlOiAgICAgICAgICA2DQogICAgICAg ICBSZWZlcmVuY2U6ICAgICAgVGhpcyBkb2N1bWVudA0KDQoNClNlY3Rpb24gMTMuMi4sIHBhcmFn cmFwaCAzOg0KT0xEOg0KDQogICAgICBOYW1lOiAgICAgICAgICAgUkFNUy1JDQogICAgICBMb25n IG5hbWU6ICAgICAgUmFwaWQgQWNxdWlzaXRpb24gb2YgTXVsdGljYXN0IFNlc3Npb25zIEluZm9y bWF0aW9uDQogICAgICBWYWx1ZTogICAgICAgICAgNw0KICAgICAgUmVmZXJlbmNlOiAgICAgIFRo aXMgZG9jdW1lbnQNCg0KTkVXOg0KDQogMTMuMy4gIFNGTVQgVmFsdWVzIGZvciBSQU1TIE1lc3Nh Z2VzIFJlZ2lzdHJ5DQoNCg0KU2VjdGlvbiAxMy4yLiwgcGFyYWdyYXBoIDQ6DQpPTEQ6DQoNCiAg ICAgIE5hbWU6ICAgICAgICAgICBSQU1TLVQNCiAgICAgIExvbmcgbmFtZTogICAgICBSYXBpZCBB Y3F1aXNpdGlvbiBvZiBNdWx0aWNhc3QgU2Vzc2lvbnMgVGVybWluYXRpb24NCiAgICAgIFZhbHVl OiAgICAgICAgICA4DQogICAgICBSZWZlcmVuY2U6ICAgICAgVGhpcyBkb2N1bWVudA0KDQpORVc6 DQoNCiAgICBUaGlzIGRvY3VtZW50IGNyZWF0ZXMgYSBuZXcgc3ViLXJlZ2lzdHJ5IGZvciB0aGUg c3ViLWZlZWRiYWNrIG1lc3NhZ2UNCiAgICB0eXBlIChTRk1UKSB2YWx1ZXMgdG8gYmUgdXNlZCB3 aXRoIHRoZSBGTVQgdmFsdWUgcmVnaXN0ZXJlZCBmb3IgUkFNUw0KICAgIG1lc3NhZ2VzLiAgVGhl IHJlZ2lzdHJ5IGlzIGNhbGxlZCB0aGUgU0ZNVCBWYWx1ZXMgZm9yIFJBTVMgTWVzc2FnZXMNCiAg ICBSZWdpc3RyeS4gIFRoaXMgcmVnaXN0cnkgaXMgdG8gYmUgbWFuYWdlZCBieSB0aGUgSUFOQSBh Y2NvcmRpbmcgdG8NCiAgICB0aGUgU3BlY2lmaWNhdGlvbiBSZXF1aXJlZCBwb2xpY3kgb2YgW1JG QzUyMjZdLg0KIA0KICAgIFRoZSBsZW5ndGggb2YgdGhlIFNGTVQgZmllbGQgaW4gdGhlIFJBTVMg bWVzc2FnZXMgaXMgYSBzaW5nbGUgb2N0ZXQsDQogICAgYWxsb3dpbmcgMjU2IHZhbHVlcy4gIFRo ZSByZWdpc3RyeSBpcyBpbml0aWFsaXplZCB3aXRoIHRoZSBmb2xsb3dpbmcNCiAgICBlbnRyaWVz Og0KIA0KICAgVmFsdWUgTmFtZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgUmVmZXJlbmNlDQogICAtLS0tLSAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSAtLS0tLS0tLS0tLS0tDQogICAxICAgICBSQU1TIFJlcXVl c3QgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUaGlzIGRvY3VtZW50DQog ICAyICAgICBSQU1TIEluZm9ybWF0aW9uICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBUaGlzIGRvY3VtZW50DQogICAzICAgICBSQU1TIFRlcm1pbmF0aW9uICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBUaGlzIGRvY3VtZW50DQogDQogICAgVGhlIFNGTVQgdmFsdWVz IDAgYW5kIDI1NSBhcmUgcmVzZXJ2ZWQgZm9yIGZ1dHVyZSB1c2UuDQogDQogICAgQW55IHJlZ2lz dHJhdGlvbiBmb3IgYW4gdW5hc3NpZ25lZCBTRk1UIHZhbHVlIE1VU1QgY29udGFpbiB0aGUNCiAg ICBmb2xsb3dpbmcgaW5mb3JtYXRpb246DQogDQogICAgbyAgQ29udGFjdCBpbmZvcm1hdGlvbiBv ZiB0aGUgb25lIGRvaW5nIHRoZSByZWdpc3RyYXRpb24sIGluY2x1ZGluZw0KICAgICAgIGF0IGxl YXN0IG5hbWUsIGFkZHJlc3MsIGFuZCBlbWFpbC4NCiANCiAgICBvICBBIGRldGFpbGVkIGRlc2Ny aXB0aW9uIG9mIHdoYXQgdGhlIG5ldyBTRk1UIHJlcHJlc2VudHMgYW5kIGhvdyBpdA0KICAgICAg IHNoYWxsIGJlIGludGVycHJldGVkLg0KIA0KICAgIE5vdGUgdGhhdCBuZXcgUkFNUyBmdW5jdGlv bmFsaXR5IHNob3VsZCBiZSBpbnRyb2R1Y2VkIGJ5IHVzaW5nIHRoZQ0KICAgIGV4dGVuc2lvbiBt ZWNoYW5pc20gd2l0aGluIHRoZSBleGlzdGluZyBSQU1TIG1lc3NhZ2UgdHlwZXMgbm90IGJ5DQog ICAgaW50cm9kdWNpbmcgbmV3IG1lc3NhZ2UgdHlwZXMgdW5sZXNzIGl0IGlzIGFic29sdXRlbHkg bmVjZXNzYXJ5Lg0KIA0KIDEzLjQuICBSQU1TIFRMViBTcGFjZSBSZWdpc3RyeQ0KIA0KICAgIFRo aXMgZG9jdW1lbnQgY3JlYXRlcyBhIG5ldyBJQU5BIFRMViBzcGFjZSByZWdpc3RyeSBmb3IgdGhl IFJBTVMNCiAgICBleHRlbnNpb25zLiAgVGhlIHJlZ2lzdHJ5IGlzIGNhbGxlZCB0aGUgUkFNUyBU TFYgU3BhY2UgUmVnaXN0cnkuDQogICAgVGhpcyByZWdpc3RyeSBpcyB0byBiZSBtYW5hZ2VkIGJ5 IHRoZSBJQU5BIGFjY29yZGluZyB0byB0aGUNCiAgICBTcGVjaWZpY2F0aW9uIFJlcXVpcmVkIHBv bGljeSBvZiBbUkZDNTIyNl0uDQogDQogICAgVGhlIGxlbmd0aCBvZiB0aGUgVHlwZSBmaWVsZCBp biB0aGUgVExWIGVsZW1lbnRzIGlzIGEgc2luZ2xlIG9jdGV0LA0KICAgIGFsbG93aW5nIDI1NiB2 YWx1ZXMuICBUaGUgcmVnaXN0cnkgaXMgaW5pdGlhbGl6ZWQgd2l0aCB0aGUgZm9sbG93aW5nDQog ICAgZW50cmllczoNCiANCiAgICBUeXBlIERlc2NyaXB0aW9uICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFJlZmVyZW5jZQ0KICAgIC0tLS0gLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gLS0tLS0tLS0tLS0tLQ0KICAgIFRCRCAg VEJEICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVGhpcyBk b2N1bWVudA0KICAgIC4uLiAgLi4uDQogDQogICAgVGhlIHJlZ2lzdHJ5IGVudHJpZXMgYXJlIFRC Qy4NCiANCiAgICBUaGUgVFlQRSB2YWx1ZXMgMCBhbmQgMjU1IGFyZSByZXNlcnZlZCBmb3IgZnV0 dXJlIHVzZS4gIFRoZSBUWVBFDQogICAgdmFsdWVzIGJldHdlZW4gKGFuZCBpbmNsdWRpbmcpIDEy OCBhbmQgMjU0IGFyZSByZXNlcnZlZCBmb3IgcHJpdmF0ZQ0KICAgIGV4dGVuc2lvbnMuDQogDQog ICAgQW55IHJlZ2lzdHJhdGlvbiBmb3IgYW4gdW5hc3NpZ25lZCBUWVBFIHZhbHVlIE1VU1QgY29u dGFpbiB0aGUNCiAgICBmb2xsb3dpbmcgaW5mb3JtYXRpb246DQogDQogICAgbyAgQ29udGFjdCBp bmZvcm1hdGlvbiBvZiB0aGUgb25lIGRvaW5nIHRoZSByZWdpc3RyYXRpb24sIGluY2x1ZGluZw0K ICAgICAgIGF0IGxlYXN0IG5hbWUsIGFkZHJlc3MsIGFuZCBlbWFpbC4NCiANCiAgICBvICBBIGRl dGFpbGVkIGRlc2NyaXB0aW9uIG9mIHdoYXQgdGhlIG5ldyBUTFYgZWxlbWVudCByZXByZXNlbnRz IGFuZA0KICAgICAgIGhvdyBpdCBzaGFsbCBiZSBpbnRlcnByZXRlZC4NCg0K ------_=_NextPart_001_01C9E095.2FC51AFD-- From jean-marc.valin@octasic.com Fri May 29 13:16:28 2009 Return-Path: <jean-marc.valin@octasic.com> X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9058A3A6DF8 for <avt@core3.amsl.com>; Fri, 29 May 2009 13:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=0.751, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0QxLqF3smJI for <avt@core3.amsl.com>; Fri, 29 May 2009 13:16:27 -0700 (PDT) Received: from MAILEXCH.octasic.com (mail.octasic.com [216.208.79.2]) by core3.amsl.com (Postfix) with ESMTP id 626B63A6EA5 for <avt@ietf.org>; Fri, 29 May 2009 13:16:21 -0700 (PDT) Received: from [142.138.24.19] ([142.138.24.19]) by MAILEXCH.octasic.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 May 2009 16:18:04 -0400 Message-ID: <4A204301.5010501@octasic.com> Date: Fri, 29 May 2009 16:18:09 -0400 From: Jean-Marc Valin <jean-marc.valin@octasic.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: John Lazzaro <john.lazzaro@gmail.com> References: <021701c9e030$0a5deef0$1f19ccd0$%roni@huawei.com> <302f570905290931lf084f46g3c2a6a298b326954@mail.gmail.com> In-Reply-To: <302f570905290931lf084f46g3c2a6a298b326954@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 May 2009 20:18:04.0941 (UTC) FILETIME=[92CF3BD0:01C9E09A] Cc: avt@ietf.org, Jason Fischl <jason.fischl@skype.net> Subject: Re: [AVT] [dispatch] Proposal to form Internet Wideband Audio Codec WG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group <avt.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/avt> List-Post: <mailto:avt@ietf.org> List-Help: <mailto:avt-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 29 May 2009 20:16:28 -0000 John Lazzaro wrote: > A traditional response to this type of request is to note that the IETF > really doesn't have much in the way of expertise in audio codec design. > I don't see many of the regulars who present at the AES codec paper sessions > posting here on AVT (ditto ICASSP paper sessions for voice codecs). It's > a full-time job to keep up-to-date and contribute to that > signal-processing lore. > Well, there's no reason that the IETF cannot build such an expertise in audio codecs. This is actually something in which I'd be interested in getting involved and I'm sure others at Xiph.Org would be interested as well. We have several people with audio codec expertise from working on Vorbis, Speex and (more recently) CELT. It turns out that the CELT codec currently under development at Xiph actually meets most of the requirements from the original proposal in being a very low delay codec with adaptive bit-rate and sampling rate (up to 48 kHz), scalable complexity, and good robustness to packet loss. We'd be willing to continue the development with the IETF. Even if not with CELT, it's still like to be involved in such a new WG. Cheers, Jean-Marc From Susanne.boll@informatik.uni-oldenburg.de Fri May 29 09:27:43 2009 Return-Path: <Susanne.boll@informatik.uni-oldenburg.de> X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B29B13A6906 for <avt@core3.amsl.com>; Fri, 29 May 2009 09:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.059 X-Spam-Level: * X-Spam-Status: No, score=1.059 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6eFsAFP5D2sV for <avt@core3.amsl.com>; Fri, 29 May 2009 09:27:42 -0700 (PDT) Received: from offis3.offis.uni-oldenburg.de (offis3.OFFIS.Uni-Oldenburg.DE [134.106.52.239]) by core3.amsl.com (Postfix) with ESMTP id 61D063A683B for <avt@ietf.org>; Fri, 29 May 2009 09:27:42 -0700 (PDT) Received: by offis3.offis.uni-oldenburg.de (Postfix, from userid 1003) id CB6D07FA1E; Fri, 29 May 2009 18:27:39 +0200 (CEST) X-Spam-hits: -1.8 X-Spam-DCC: debian: offis3 1169; Body=1 Fuz1=1 Fuz2=3 Received: from smtpsec.offis.uni-oldenburg.de (serv1.offis.uni-oldenburg.de [134.106.52.238]) by offis3.offis.uni-oldenburg.de (Postfix) with ESMTP id 267917FA1C; Fri, 29 May 2009 18:27:36 +0200 (CEST) Received: from wlan-offis36.offis.uni-oldenburg.de (wlan-offis36.offis.uni-oldenburg.de [134.106.59.36]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtpsec.offis.uni-oldenburg.de (Postfix) with ESMTPSA id 69BDA274E78; Fri, 29 May 2009 18:27:34 +0200 (CEST) Message-Id: <80296513-4A8C-4B64-BA6D-E37A6B468F8A@informatik.uni-oldenburg.de> From: Susanne Boll <Susanne.boll@informatik.uni-oldenburg.de> To: avt@ietf.org Content-Type: multipart/alternative; boundary=Apple-Mail-51--980718180 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 29 May 2009 18:27:34 +0200 X-Mailer: Apple Mail (2.935.3) X-Filtered-With: renattach 1.2.4 X-RenAttach-Info: mode=badlist action=rename count=0 X-Mailman-Approved-At: Sun, 31 May 2009 09:44:48 -0700 Subject: [AVT] ACM MM2009 Video Program Call for Video Submissions X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group <avt.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/avt> List-Post: <mailto:avt@ietf.org> List-Help: <mailto:avt-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 29 May 2009 16:27:43 -0000 --Apple-Mail-51--980718180 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit ACM MM2009 Video Program Call for Video Submissions ACM Multimedia seeks submissions of innovative research in the video format. The goal is to encourage communication of complex ideas in the video format so as to allow for better presentation of the idea. The scope of the research presented in similar to the general call, in that research ideas relevant all the four major technical tracks and the arts track - are of interest to the video program. * The videos can range in duration between 3 minutes to 8 minutes. * The minimum spatial resolution is 320*240 pixels per frame. * Videos should be submitted at a minimum of 15fps. * The videos should be in a standard archival format, such as .mov, .avi, .mpeg-1, and mpeg-2. * All submissions should be accompanied by a companion abstract, up to 3 pages in length, in the standard acm template. Important Dates: Submission Deadline: Extended to June 15, 2009 Notification of Acceptance: July 10, 2009 Contact If you have any questions regarding the video program please contact the video program co-chairs: Hari Sundaram (Arizona State University, USA) Jie Yang (Carnegie Mellon University, USA) - < hari sundaram | associate professor, cs + ame http://ame2.asu.edu/faculty/hs, o:480.965.2686 > --Apple-Mail-51--980718180 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable <html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; = -webkit-line-break: after-white-space; = "><div><br></div><div><br></div><div><div style=3D"margin-top: 0in; = margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: = 11pt; font-family: Calibri, sans-serif; ">ACM MM2009 Video Program Call = for Video Submissions<o:p></o:p></div><div style=3D"margin-top: 0in; = margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: = 11pt; font-family: Calibri, sans-serif; "><o:p> </o:p></div><div = style=3D"margin-top: 0in; margin-right: 0in; margin-left: 0in; = margin-bottom: 0.0001pt; font-size: 11pt; font-family: Calibri, = sans-serif; ">ACM Multimedia seeks submissions of innovative research in = the video format. The goal is to encourage communication of complex = ideas in the video format so as to allow for better presentation of the = idea. The scope of the research presented in similar to the general = call, in that research ideas relevant all the four major technical = tracks and the arts track - are of interest to the video = program.<o:p></o:p></div><div style=3D"margin-top: 0in; margin-right: = 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 11pt; = font-family: Calibri, sans-serif; "><o:p> </o:p></div><div = style=3D"margin-top: 0in; margin-right: 0in; margin-left: 0in; = margin-bottom: 0.0001pt; font-size: 11pt; font-family: Calibri, = sans-serif; ">* The videos can range in duration between 3 minutes to 8 = minutes.<o:p></o:p></div><div style=3D"margin-top: 0in; margin-right: = 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 11pt; = font-family: Calibri, sans-serif; ">* The minimum spatial resolution is = 320*240 pixels per frame.<o:p></o:p></div><div style=3D"margin-top: 0in; = margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: = 11pt; font-family: Calibri, sans-serif; ">* Videos should be submitted = at a minimum of 15fps.<o:p></o:p></div><div style=3D"margin-top: 0in; = margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: = 11pt; font-family: Calibri, sans-serif; ">* The videos should be in a = standard archival format, such as .mov, .avi, .mpeg-1, and = mpeg-2.<o:p></o:p></div><div style=3D"margin-top: 0in; margin-right: = 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 11pt; = font-family: Calibri, sans-serif; ">* All submissions should be = accompanied by a companion abstract, up to 3 pages in length, in the = standard acm template.<o:p></o:p></div><div style=3D"margin-top: 0in; = margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: = 11pt; font-family: Calibri, sans-serif; "><o:p> </o:p></div><div = style=3D"margin-top: 0in; margin-right: 0in; margin-left: 0in; = margin-bottom: 0.0001pt; font-size: 11pt; font-family: Calibri, = sans-serif; ">Important Dates:<o:p></o:p></div><div style=3D"margin-top: = 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; = font-size: 11pt; font-family: Calibri, sans-serif; = "><o:p> </o:p></div><div style=3D"margin-top: 0in; margin-right: = 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 11pt; = font-family: Calibri, sans-serif; ">Submission Deadline: Extended to = June 15, 2009<o:p></o:p></div><div style=3D"margin-top: 0in; = margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: = 11pt; font-family: Calibri, sans-serif; ">Notification of Acceptance: = July 10, 2009<o:p></o:p></div><div style=3D"margin-top: 0in; = margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: = 11pt; font-family: Calibri, sans-serif; "><o:p> </o:p></div><div = style=3D"margin-top: 0in; margin-right: 0in; margin-left: 0in; = margin-bottom: 0.0001pt; font-size: 11pt; font-family: Calibri, = sans-serif; ">Contact<o:p></o:p></div><div style=3D"margin-top: 0in; = margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: = 11pt; font-family: Calibri, sans-serif; ">If you have any questions = regarding the video program please contact the video program = co-chairs:<o:p></o:p></div><div style=3D"margin-top: 0in; margin-right: = 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 11pt; = font-family: Calibri, sans-serif; "><o:p> </o:p></div><div = style=3D"margin-top: 0in; margin-right: 0in; margin-left: 0in; = margin-bottom: 0.0001pt; font-size: 11pt; font-family: Calibri, = sans-serif; ">Hari Sundaram (Arizona State University, = USA)<o:p></o:p></div><div style=3D"margin-top: 0in; margin-right: 0in; = margin-left: 0in; margin-bottom: 0.0001pt; font-size: 11pt; font-family: = Calibri, sans-serif; ">Jie Yang (Carnegie Mellon University, = USA)<o:p></o:p></div><div style=3D"margin-top: 0in; margin-right: 0in; = margin-left: 0in; margin-bottom: 0.0001pt; font-size: 11pt; font-family: = Calibri, sans-serif; ">-<o:p></o:p></div><div style=3D"margin-top: 0in; = margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: = 11pt; font-family: Calibri, sans-serif; ">< hari sundaram | associate = professor,   cs + ame<o:p></o:p></div><div style=3D"margin-top: = 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; = font-size: 11pt; font-family: Calibri, sans-serif; "><a = href=3D"http://ame2.asu.edu/faculty/hs" style=3D"color: blue; = text-decoration: underline; "><span style=3D"color: blue; = ">http://ame2.asu.edu/faculty/hs</span></a>, o:480.965.2686 = ></div></div></body></html>= --Apple-Mail-51--980718180--