From avt-bounces@ietf.org Wed Aug 01 05:39:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGAel-0000QG-8E; Wed, 01 Aug 2007 05:38:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGAao-0002C8-Mb for avt@ietf.org; Wed, 01 Aug 2007 05:34:10 -0400 Received: from mail5.audiocodes.com ([212.25.125.21] helo=imss.audiocodes.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGAal-0007UU-B7 for avt@ietf.org; Wed, 01 Aug 2007 05:34:10 -0400 Received: from aclcas.corp.audiocodes.com ([10.1.0.13]) by imss with InterScan Messaging Security Suite; Wed, 01 Aug 2007 11:44:02 +0200 Received: from aclmailbox.corp.audiocodes.com ([10.1.1.48]) by aclcas.corp.audiocodes.com ([10.1.0.13]) with mapi; Wed, 1 Aug 2007 12:34:19 +0300 From: Amit Yedidia To: "avt@ietf.org" Date: Wed, 1 Aug 2007 12:34:17 +0300 Thread-Topic: Text Overlay (over Video) questions Thread-Index: AcfUHyFWICEcEovqQGq89bOmncmq2A== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Subject: [AVT] Text Overlay (over Video) questions X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1553371538==" Errors-To: avt-bounces@ietf.org --===============1553371538== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_C7507220AA34614FB456FA5EA7D8AE2E0BEB84A9A3aclmailboxcor_" --_000_C7507220AA34614FB456FA5EA7D8AE2E0BEB84A9A3aclmailboxcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, Does anyone have experience with text overlay on video.? I have few question regard to this issue: 1. What font file format to use (bitmap fonts, true type)? 2. How to acquire new font type? Or just define a default set for the syst= em. 3. If using bitmap fonts - how to mange with scaling of the font? Thanks. Amit Yedidia --_000_C7507220AA34614FB456FA5EA7D8AE2E0BEB84A9A3aclmailboxcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

Does anyone have experience with text overlay on video.?=

I have few question regard to this issue:

1. What font file format to use (bitmap fonts, true type= )?

2. How to acquire new font type? Or just define a defaul= t set for the  system.

3. If using bitmap fonts – how to mange with scali= ng of the font?

 

Thanks.

Amit Yedidia

 

 

 

 

=  

 

--_000_C7507220AA34614FB456FA5EA7D8AE2E0BEB84A9A3aclmailboxcor_-- --===============1553371538== 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://www1.ietf.org/mailman/listinfo/avt --===============1553371538==-- From avt-bounces@ietf.org Wed Aug 01 05:46:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGAm5-0007PT-9p; Wed, 01 Aug 2007 05:45:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGAm3-0007PE-Fc for avt@ietf.org; Wed, 01 Aug 2007 05:45:47 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGAm2-0000JU-Lp for avt@ietf.org; Wed, 01 Aug 2007 05:45:47 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Aug 2007 11:45:36 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [AVT] Draft minutes from Chicago meeting Date: Wed, 1 Aug 2007 11:43:43 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] Draft minutes from Chicago meeting Thread-Index: AcfSgU6QF9qn+AveQKK3IqdJpF3HlABnsxlg References: From: "SOLLAUD Aurelien RD-TECH-LAN" To: "Colin Perkins" , "AVT WG" X-OriginalArrivalTime: 01 Aug 2007 09:45:36.0200 (UTC) FILETIME=[B611A480:01C7D420] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Roni Even , Tom Taylor X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org >=20 > RTP Keep Alive >=20 > draft-ietf-avt-app-rtp-keepalive-00 [...]=20 > Jonathan Lennox noted=20 > that there are > often codec specific keep alive mechanisms, in addition=20 > to comfort noise. I don't think "often" is correct. An example was given (H.264 kind of "null" NAL unit if I remember correctly) but it is not true for the majority of codecs. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Wed Aug 01 06:26:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGBOt-0001Wx-Rg; Wed, 01 Aug 2007 06:25:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGBOt-0001WX-1N for avt@ietf.org; Wed, 01 Aug 2007 06:25:55 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGBOr-0000f1-Fu for avt@ietf.org; Wed, 01 Aug 2007 06:25:55 -0400 Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]:49622) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1IGBOq-0000GM-S8; Wed, 01 Aug 2007 11:25:52 +0100 In-Reply-To: <46AF2A0A.8070407@ericsson.com> References: <0MKp8S-1IBfib2mC2-0005q2@mrelay.perfora.net> <0MKpCa-1IDqsy0MRm-0006V5@mrelay.perfora.net> <46A8F01A.8040809@ericsson.com> <0MKp8S-1IFKak0Stn-0005t6@mrelay.perfora.net> <46AF2A0A.8070407@ericsson.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4E6D480D-2328-40AE-B5EB-34DE32939E9C@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [AVT] draft-ietf-avt-hdrext-12 Date: Wed, 1 Aug 2007 11:25:51 +0100 To: Magnus Westerlund X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: Dave Singer , AVT WG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Hi, [Not as chair] I don't especially care if we end up with one draft or two. That will depend on how similar the proposals are, in terms of header fields, and how the namespace is managed. I do think, however, that we need to document both versions (since both are in use), and we need to include a strong recommendation on which SHOULD be used for new implementations, and which is for backwards compatibility with pre-standards use and SHOULD NOT be used. Colin On 31 Jul 2007, at 13:24, Magnus Westerlund wrote: > Hi, > > IETF standards track documents are strong recommendations on how to > solve a problem. In many case that doesn't rule out the existence > of other solutions. However, it may hurt interoperability and/or > complicate implementations. There is no protocol police that goes > ut and stop usage that doesn't follow IETF. In addition the header > extension mechanism in RTP is free to use by anyone. So 8+8 is > definitely conformant to RFC 3550. One has only to be aware of the > limitations they result in. But the desirable future is that anyone > in the future that needs this functionality will use RFC XXX (what > ever the number will be for draft-ietf-avt-hdrext). > > As I see it the best we can do for the future is to select one > solution and go forward. And hope that most future users out there > uses that single solution. That is in my view the best way and will > maximize interoperability in the future. I can also hope that some > that uses their own extension mechanism will move to the IETF > defined one. > >> Which is why I think I would like to document them in one document, > > with 4+4 support required and 8+8 documented and mentioned and > > support for it optional. > > I hope that it is clearer why I propose to select only a single one > and stick with that. I don't want to have two of them in the > document because that will result in that everyone will have to > implement both. IETF has become worse and worse at selecting a > single solution and sticking with it. I asked the question about > deployement, because as I see it there are some difference in the > technical tradeoff but if you had a large deployement that would > still be compatible with the tag value mechanism in the current WG > document then I think it would have been reasonable to switch to > the 8+8 tradeoff. However, as you aren't forthcomming with that > information there is no data to for determinging that 8+8 would be > a more reasonable choice then 4+4. I am also worried about the ID > numberspace and control over that. > > I am worried about the 8+8 ID namespace that may make it difficult > to adopt. draft-ietf-avt-hdrext contains a larger namespace that is > mapped onto the ID values. This as 16 values would never last. But > the same is also true for 256 values. Thus the same rule could be > applied. However, that requires that IETF gets full control of at > least a substantial block of the field values. There must be full > agreement between the original definers and IETF that control is > transfered. In addition it must be known which values are used and > already handed out. The only alternative for a 8+8 solutio would be > to go with another header extension identifier. > > Because of that I would propose that we go forward with a document > that only provides the 4+4 solution. > > Dave Singer skrev: >> If that is a problem, how about we add a sentence to the 4+4 spec. >> saying "A variant of this design, using 8-bit length and tag >> fields, also exists, using a different value for the field that >> takes the value 0xBEDE here."? > > There might be value in pointing out that there exist similar but > not IETF defined solutions for the header extension field. However, > I wonder if it would confuse more then any benefit it gives. But my > attempt is the following: > > "At least one similar solution is known to exist for solving the > first drawback. That solution uses different field lengths, but > also another 16-bit identifier value, thus no risk of misstake > between them exist. The resolution of the second drawback and > slightly differnt tradebacks resulted in the solution present in > this document." > > The above is written based on that the solution you documents did > not try to resolve the namespace issues to provide an basically > unlimited number of header extensions. > > I might have not given the impression before that there is benefit > in document the 8+8 solutions that are in use. I think it would be > best that it is documented in an informational RFC. However, I > would like to see good wording in there that this is a > documentation of something that is used, but that it is prefered to > use draft-ietf-avt-hdrext. > > Cheers > > Magnus Westerlund > > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM/M > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt -- Colin Perkins http://csperkins.org/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Wed Aug 01 06:44:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGBfp-00055q-Ar; Wed, 01 Aug 2007 06:43:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGBfo-000557-GD for avt@ietf.org; Wed, 01 Aug 2007 06:43:24 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGBfo-0002DE-2e for avt@ietf.org; Wed, 01 Aug 2007 06:43:24 -0400 Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]:49677) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1IGBfn-00042t-0K; Wed, 01 Aug 2007 11:43:23 +0100 In-Reply-To: References: <2CD7768D-70A2-4149-9FD4-80096D8BD564@csperkins.org> <7B03E158-CA2B-416F-AA9B-0A8BF69AF765@csperkins.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-tfrc-profile-09.txt Date: Wed, 1 Aug 2007 11:43:21 +0100 To: Randell Jesup X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Ladan Gharai , AVT WG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org On 26 Jul 2007, at 05:26, Randell Jesup wrote: > Colin Perkins writes: >> This is why I'm suggesting you use the RTP timestamp rate: it >> avoids all >> these issues with multiple clocks. > > But can't the RTP timestamp rate change in mid-stream? Sure, but you have to deal with that whether or not you implement TFRC. Thinking about this issue some more, though, it might be better to use units of 1/65536 seconds, to match the LSR and DLSR fields in RTCP RR packets? -- Colin Perkins http://csperkins.org/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Wed Aug 01 07:09:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGC3n-0002To-8J; Wed, 01 Aug 2007 07:08:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGC3k-0002Re-Ud for avt@ietf.org; Wed, 01 Aug 2007 07:08:08 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGC3j-0001tk-KC for avt@ietf.org; Wed, 01 Aug 2007 07:08:08 -0400 Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]:49747) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1IGC3i-0007da-TH; Wed, 01 Aug 2007 12:08:06 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <72F8B0F3-99B7-4245-9956-91E6480D18B2@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-rtp-and-rtcp-mux-06.txt Date: Wed, 1 Aug 2007 12:08:05 +0100 To: Randell Jesup X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: AVT WG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org On 26 Jul 2007, at 19:54, Randell Jesup wrote: > Internet-Drafts@ietf.org writes: >> Title : Multiplexing RTP Data and Control Packets on a Single Port >> Filename : draft-ietf-avt-rtp-and-rtcp-mux-06.txt > >> Note: since all RTCP packets MUST be sent as compound packets >> beginning with an SR or an RR packet ([1] Section 6.1), one >> might >> wonder why RTP payload types other than 72 and 73 are prohibited >> when multiplexing RTP and RTCP. This is done to ensure >> robustness >> against broken nodes which send non-compliant RTCP packets, >> which >> might otherwise be confused with multiplexed RTP packets. > > This should mention that relaxing that restriction is under > consideration, > (I forget the exact draft name) and that by including the PT > restrictions > in this draft we avoid a potential conflict with the other draft > (i.e. it > may not be only "broken nodes"). I also would remove the word > "broken", > it's misleading. They are non-compliant with 3261 (until that > draft is > approved). I'll submit a -07, changing this to: Note: since all RTCP packets MUST be sent as compound packets beginning with an SR or an RR packet ([1] Section 6.1), one might wonder why RTP payload types other than 72 and 73 are prohibited when multiplexing RTP and RTCP. This is done to ensure robustness against nodes which send non-compound RTCP packets, which might otherwise be confused with multiplexed RTP packets. At the time of this writing, there is a proposal to allow non-compound RTCP packets in some circumstances [17], so this robustness may become more important in future. and adding the appropriate reference. >> When the Session Description Protocol (SDP) [8] is used to >> negotiate >> RTP sessions following the offer/answer model [9], the "a=rtcp-mux" >> attribute (see Section 8) indicates the desire to multiplex RTP and >> RTCP onto a single port. > > We should also discuss interaction with offering both "a=rtcp-mux" and > "a=rtcp ". I can see an endpoint wanting (or needing) to > include > both. The answer selects between rtcp-mux and "normal" rtcp handling > (including a=rtcp, though there's no direct way to know if the > answerer > supports it). This is discussed in section 5.1.1 of the draft. Please suggest text if the current wording is not sufficient. Thanks, -- Colin Perkins http://csperkins.org/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Wed Aug 01 07:36:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGCUD-00031u-5o; Wed, 01 Aug 2007 07:35:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGCU9-00031p-UW for avt@ietf.org; Wed, 01 Aug 2007 07:35:25 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGCU9-0002Wt-JU for avt@ietf.org; Wed, 01 Aug 2007 07:35:25 -0400 Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]:49853) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1IGCU9-0003F9-8V for avt@ietf.org; Wed, 01 Aug 2007 12:35:25 +0100 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <9AF2A1B3-91CD-4A89-A455-2501CE41A72C@csperkins.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: AVT WG From: Colin Perkins Date: Wed, 1 Aug 2007 12:35:23 +0100 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [AVT] Progressing the RTP no-op payload format X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org The No-Op Payload Format for RTP (draft-ietf-avt-rtp-no-op-04.txt) is technically complete. There has been, however, some discussion on IPR relating to the draft: see http://www1.ietf.org/ietf/IPR/cisco-ipr- draft-ietf-avt-rtp-no-op-04.txt and http://www1.ietf.org/mail-archive/ web/avt/current/msg08380.html and followups. My understanding is that some claims on the patent application are sufficiently broad that it will be difficult to develop a no-op format which is not covered, should the patent be awarded. Given this, and the IPR statement linked above, I'd like to ask the working group two questions, so we can decide how to proceed with the draft: 1) Do you believe an RTP no-op payload format is useful to standardise, given the other keep alive mechanisms that now exist? 2) Do you believe the working group should proceed with this particular draft? Response to the list preferred, but private responses accepted and I'll summarise. Thanks, Colin (as chair) _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Wed Aug 01 08:41:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGDUh-00019D-WE; Wed, 01 Aug 2007 08:40:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGDUh-00018x-5p; Wed, 01 Aug 2007 08:40:03 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGDUg-0004HB-KQ; Wed, 01 Aug 2007 08:40:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 8766A26E90; Wed, 1 Aug 2007 12:40:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IGDUg-000823-Ez; Wed, 01 Aug 2007 08:40:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 01 Aug 2007 08:40:02 -0400 X-Spam-Score: -1.4 (-) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: avt@ietf.org Subject: [AVT] I-D Action:draft-ietf-avt-avpf-ccm-09.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , 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 : Author(s) : S. Wenger, et al. Filename : draft-ietf-avt-avpf-ccm-09.txt Pages : 68 Date : 2007-08-01 This document specifies a few extensions to the messages defined in the Audio-Visual Profile with Feedback (AVPF). They are helpful primarily in conversational multimedia scenarios where centralized multipoint functionalities are in use. However, some are also usable in smaller multicast environments and point-to-point calls. The extensions discussed are messages related to the ITU-T H.271 Video Back Channel, Full Intra Request, Temporary Maximum Media Stream Bit Rate and Temporal Spatial Trade-off. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-avpf-ccm-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-avpf-ccm-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-avpf-ccm-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-08-01083522.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-avpf-ccm-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-avpf-ccm-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-08-01083522.I-D\@ietf.org> --OtherAccess-- --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://www1.ietf.org/mailman/listinfo/avt --NextPart-- From avt-bounces@ietf.org Wed Aug 01 08:41:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGDUk-0001Ds-4H; Wed, 01 Aug 2007 08:40:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGDUh-000195-DS; Wed, 01 Aug 2007 08:40:03 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGDUh-0005DO-0u; Wed, 01 Aug 2007 08:40:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id B7FD2175F7; Wed, 1 Aug 2007 12:40:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IGDUg-000820-Ac; Wed, 01 Aug 2007 08:40:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 01 Aug 2007 08:40:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: avt@ietf.org Subject: [AVT] I-D Action:draft-ietf-avt-topologies-06.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , 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 : RTP Topologies Author(s) : M. Westerlund, S. Wenger Filename : draft-ietf-avt-topologies-06.txt Pages : 22 Date : 2007-08-01 This document discusses multi-endpoint topologies used in RTP-based environments. In particular, centralized topologies commonly employed in the video conferencing industry are mapped to the RTP terminology. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-topologies-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-topologies-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-topologies-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-08-01083439.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-topologies-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-topologies-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-08-01083439.I-D\@ietf.org> --OtherAccess-- --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://www1.ietf.org/mailman/listinfo/avt --NextPart-- From avt-bounces@ietf.org Wed Aug 01 08:46:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGDZf-0005tv-8l; Wed, 01 Aug 2007 08:45:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGDZc-0005lZ-5I for avt@ietf.org; Wed, 01 Aug 2007 08:45:09 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGDZb-0005U0-NL for avt@ietf.org; Wed, 01 Aug 2007 08:45:08 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 21CAA2126E for ; Wed, 1 Aug 2007 14:45:07 +0200 (CEST) X-AuditID: c1b4fb3e-b2038bb0000007e1-f1-46b08053ce06 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0A7BF20209 for ; Wed, 1 Aug 2007 14:45:07 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Aug 2007 14:45:06 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Aug 2007 14:45:06 +0200 Message-ID: <46B08052.4050902@ericsson.com> Date: Wed, 01 Aug 2007 14:45:06 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: avt@ietf.org Subject: Re: [AVT] I-D Action:draft-ietf-avt-topologies-06.txt References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Aug 2007 12:45:06.0461 (UTC) FILETIME=[C9A50CD0:01C7D439] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Hi, This version address comments from Keith Lantz. As with CCM this have now passed a second WG last call and I expect that chairs will request publication soon. Cheers Magnus Internet-Drafts@ietf.org skrev: > 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 Topologies > Author(s) : M. Westerlund, S. Wenger > Filename : draft-ietf-avt-topologies-06.txt > Pages : 22 > Date : 2007-08-01 > > This document discusses multi-endpoint topologies used in RTP-based > environments. In particular, centralized topologies commonly > employed in the video conferencing industry are mapped to the RTP > terminology. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-avt-topologies-06.txt > -- Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Wed Aug 01 08:47:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGDb1-0006Za-NK; Wed, 01 Aug 2007 08:46:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGDb0-0006Yl-04 for avt@ietf.org; Wed, 01 Aug 2007 08:46:34 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGDaz-0004aD-EZ for avt@ietf.org; Wed, 01 Aug 2007 08:46:33 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D6640212F1 for ; Wed, 1 Aug 2007 14:46:32 +0200 (CEST) X-AuditID: c1b4fb3e-af833bb0000007e1-76-46b080a84244 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B9CB6211F7 for ; Wed, 1 Aug 2007 14:46:32 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Aug 2007 14:46:32 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Aug 2007 14:46:32 +0200 Message-ID: <46B080A8.9000007@ericsson.com> Date: Wed, 01 Aug 2007 14:46:32 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: avt@ietf.org Subject: Re: [AVT] I-D Action:draft-ietf-avt-avpf-ccm-09.txt References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Aug 2007 12:46:32.0194 (UTC) FILETIME=[FCBEDE20:01C7D439] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Hi, This version addresses the last set of comments received during the second WG last call. This should mean that this document together with RTP Topologies is ready for publication request. Cheers Magnus Internet-Drafts@ietf.org skrev: > 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 : > Author(s) : S. Wenger, et al. > Filename : draft-ietf-avt-avpf-ccm-09.txt > Pages : 68 > Date : 2007-08-01 > > This document specifies a few extensions to the messages defined in > the Audio-Visual Profile with Feedback (AVPF). They are helpful > primarily in conversational multimedia scenarios where centralized > multipoint functionalities are in use. However, some are also > usable in smaller multicast environments and point-to-point calls. > The extensions discussed are messages related to the ITU-T H.271 > Video Back Channel, Full Intra Request, Temporary Maximum Media > Stream Bit Rate and Temporal Spatial Trade-off. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-avt-avpf-ccm-09.txt > -- Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Wed Aug 01 22:38:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGQZb-0005iS-Qb; Wed, 01 Aug 2007 22:37:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGQZa-0005iG-Cu for avt@ietf.org; Wed, 01 Aug 2007 22:37:58 -0400 Received: from pr-66-150-46-254.wgate.com ([66.150.46.254] helo=exchange1.wgate.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGQZa-0001WX-2B for avt@ietf.org; Wed, 01 Aug 2007 22:37:58 -0400 Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Aug 2007 22:37:57 -0400 To: Colin Perkins Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-tfrc-profile-09.txt References: <2CD7768D-70A2-4149-9FD4-80096D8BD564@csperkins.org> <7B03E158-CA2B-416F-AA9B-0A8BF69AF765@csperkins.org> From: Randell Jesup Date: Wed, 01 Aug 2007 22:37:56 -0400 In-Reply-To: (Colin Perkins's message of "Wed, 1 Aug 2007 11:43:21 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 02 Aug 2007 02:37:57.0639 (UTC) FILETIME=[22C9B170:01C7D4AE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Ladan Gharai , AVT WG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randell Jesup List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Colin Perkins writes: >On 26 Jul 2007, at 05:26, Randell Jesup wrote: >> Colin Perkins writes: >>> This is why I'm suggesting you use the RTP timestamp rate: it avoids >>> all these issues with multiple clocks. >> >> But can't the RTP timestamp rate change in mid-stream? > >Sure, but you have to deal with that whether or not you implement TFRC. Yeah, but I think it would throw a major additional wrench into TFRC calculations - and no one would test it (nor test packet loss at the transition point), and you'd have problems in practice. >Thinking about this issue some more, though, it might be better to use >units of 1/65536 seconds, to match the LSR and DLSR fields in RTCP RR >packets? Sure, that might make sense - depending on how many bits you have to play with, and the range of times you need to deal with. -- 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://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Wed Aug 01 22:53:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGQoq-0005gr-EL; Wed, 01 Aug 2007 22:53:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGQoo-0005gl-Sa for avt@ietf.org; Wed, 01 Aug 2007 22:53:42 -0400 Received: from pr-66-150-46-254.wgate.com ([66.150.46.254] helo=exchange1.wgate.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGQon-0000Jr-Jc for avt@ietf.org; Wed, 01 Aug 2007 22:53:42 -0400 Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Aug 2007 22:53:41 -0400 To: Colin Perkins Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-rtp-and-rtcp-mux-06.txt References: <72F8B0F3-99B7-4245-9956-91E6480D18B2@csperkins.org> From: Randell Jesup Date: Wed, 01 Aug 2007 22:53:40 -0400 In-Reply-To: <72F8B0F3-99B7-4245-9956-91E6480D18B2@csperkins.org> (Colin Perkins's message of "Wed, 1 Aug 2007 12:08:05 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 02 Aug 2007 02:53:41.0327 (UTC) FILETIME=[55450DF0:01C7D4B0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: AVT WG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randell Jesup List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Colin Perkins writes: >On 26 Jul 2007, at 19:54, Randell Jesup wrote: >> Internet-Drafts@ietf.org writes: >>> Title : Multiplexing RTP Data and Control Packets on a Single Port >>> Filename : draft-ietf-avt-rtp-and-rtcp-mux-06.txt >I'll submit a -07, changing this to: > > Note: since all RTCP packets MUST be sent as compound packets > beginning with an SR or an RR packet ([1] Section 6.1), one might > wonder why RTP payload types other than 72 and 73 are prohibited > when multiplexing RTP and RTCP. This is done to ensure robustness > against nodes which send non-compound RTCP packets, which might > otherwise be confused with multiplexed RTP packets. At the time > of this writing, there is a proposal to allow non-compound RTCP > packets in some circumstances [17], so this robustness may become > more important in future. > >and adding the appropriate reference. Looks good. >> We should also discuss interaction with offering both "a=rtcp-mux" and >> "a=rtcp ". I can see an endpoint wanting (or needing) to include >> both. The answer selects between rtcp-mux and "normal" rtcp handling >> (including a=rtcp, though there's no direct way to know if the answerer >> supports it). > >This is discussed in section 5.1.1 of the draft. Please suggest text if >the current wording is not sufficient. Aha, sorry, missed that. The wording seems good. -- 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://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Fri Aug 03 11:45:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGzKK-00025C-Uo; Fri, 03 Aug 2007 11:44:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGzKJ-000256-3C for avt@ietf.org; Fri, 03 Aug 2007 11:44:31 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGzKI-0006cy-N8 for avt@ietf.org; Fri, 03 Aug 2007 11:44:31 -0400 Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]:55868) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1IGzKE-0000iu-WF; Fri, 03 Aug 2007 16:44:27 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <17F9A7A3-28B2-4119-AC40-D3DA152A4416@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-rtp-speex-03.txt Date: Fri, 3 Aug 2007 16:44:26 +0100 To: Greg Herlein , jean-marc.valin@usherbrooke.ca, "Alfred E. Heggestad" , Aymeric Moizard X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: AVT WG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org On 24 Jul 2007, at 18:15, Internet-Drafts@ietf.org wrote: > 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-03.txt > Pages : 23 > Date : 2007-7-24 > > 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). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-speex-03.txt Thanks for the update - this version addresses my concerns with the previous draft. Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Fri Aug 03 12:42:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IH0DJ-0008K1-Lv; Fri, 03 Aug 2007 12:41:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IH0DH-0008FT-Dn for avt@ietf.org; Fri, 03 Aug 2007 12:41:19 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IH0DH-0008JD-1z for avt@ietf.org; Fri, 03 Aug 2007 12:41:19 -0400 Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]:55994) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1IH0CL-0003WX-40 for avt@ietf.org; Fri, 03 Aug 2007 17:40:21 +0100 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <8F3BAAAB-D96C-465C-A350-2A8FD367A44A@csperkins.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: AVT WG From: Colin Perkins Date: Fri, 3 Aug 2007 17:40:20 +0100 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [AVT] Working group last call: JPEG-2000 payload format X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Folks, There was considerable discussion on the list in June about allowing non-90kHz clock rates for the JPEG-2000 payload format. A new version of the draft is now available, making the agreed change: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-jpeg2000-16.txt http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-jpeg2000- beam-07.txt If you commented previously, please review to confirm the changes made reflect the consensus. If there are no additional comments by 20th August, we will request the IESG consider these drafts for publication. -- Colin Perkins http://csperkins.org/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Mon Aug 06 17:16:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1II9ut-0004pk-Ad; Mon, 06 Aug 2007 17:15:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1II9uo-0004on-H5; Mon, 06 Aug 2007 17:15:02 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1II9uo-0005FZ-4b; Mon, 06 Aug 2007 17:15:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id D4536175D1; Mon, 6 Aug 2007 21:15:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1II9un-00050l-EV; Mon, 06 Aug 2007 17:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 06 Aug 2007 17:15:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-and-rtcp-mux-07.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , 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 : Multiplexing RTP Data and Control Packets on a Single Port Author(s) : C. Perkins, M. Westerlund Filename : draft-ietf-avt-rtp-and-rtcp-mux-07.txt Pages : 15 Date : 2007-8-6 This memo discusses issues that arise when multiplexing RTP data packets and RTP control protocol (RTCP) packets on a single UDP port. It updates RFC 3550 to describe when such multiplexing is, and is not, appropriate, and explains how the Session Description Protocol (SDP) can be used to signal multiplexed sessions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-and-rtcp-mux-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-and-rtcp-mux-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-and-rtcp-mux-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-8-6161407.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-and-rtcp-mux-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-and-rtcp-mux-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-8-6161407.I-D@ietf.org> --OtherAccess-- --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://www1.ietf.org/mailman/listinfo/avt --NextPart-- From avt-bounces@ietf.org Tue Aug 07 10:15:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIPqU-000283-9p; Tue, 07 Aug 2007 10:15:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIPqP-00025m-Tj; Tue, 07 Aug 2007 10:15:33 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIPqP-0007bi-3v; Tue, 07 Aug 2007 10:15:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id C54A5175C7; Tue, 7 Aug 2007 14:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IIPpu-0003x2-B6; Tue, 07 Aug 2007 10:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 07 Aug 2007 10:15:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-ulp-23.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , 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 : RTP Payload Format for Generic Forward Error Correction Author(s) : A. Li Filename : draft-ietf-avt-ulp-23.txt Pages : 43 Date : 2007-8-7 This document specifies a payload format for generic Forward Error Correction (FEC) for media data encapsulated in RTP. It is based on the exclusive-or (parity) operation. The payload format described in this draft allows end systems to apply protection using various protection lengths and levels, in addition to using various protection group sizes to adapt to different media and channel characteristic. It enables complete recovery of the protected packets or partial recovery of the critical parts of the payload depending on the packet loss situation. This scheme is completely compatible with non-FEC capable hosts, so the receivers in a multicast group that do not implement FEC can still work by simply ignoring the protection data. This specification obsoletes RFC 2733 and RFC 3009. The FEC specified in this document is not backward compatible with RFC 2733 and RFC 3009. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-ulp-23.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-ulp-23.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-ulp-23.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-8-7091001.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-ulp-23.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-ulp-23.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-8-7091001.I-D@ietf.org> --OtherAccess-- --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://www1.ietf.org/mailman/listinfo/avt --NextPart-- From avt-bounces@ietf.org Tue Aug 07 10:15:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIPqj-0002fG-BY; Tue, 07 Aug 2007 10:15:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIPqQ-00026v-1X; Tue, 07 Aug 2007 10:15:34 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIPqP-0007bl-AK; Tue, 07 Aug 2007 10:15:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id E5A3E175C9; Tue, 7 Aug 2007 14:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IIPpu-0003xO-Fs; Tue, 07 Aug 2007 10:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 07 Aug 2007 10:15:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-evrc-wb-03.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , 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 : RTP payload format for EVRC-WB codec and media subtype updates for EVRC-B codec Author(s) : H. Desineni, Q. Xie Filename : draft-ietf-avt-rtp-evrc-wb-03.txt Pages : 37 Date : 2007-8-7 This document specifies real-time transport protocol (RTP) payload formats to be used for the EVRC wideband codec (EVRC-WB) and updates the media type registrations for EVRC-B codec. Several media type registrations are included for EVRC-WB RTP payload formats. In addition, a file format is specified for transport of EVRC-WB speech data in storage mode applications such as e-mail. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-evrc-wb-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-evrc-wb-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-evrc-wb-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-8-7092350.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-evrc-wb-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-evrc-wb-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-8-7092350.I-D@ietf.org> --OtherAccess-- --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://www1.ietf.org/mailman/listinfo/avt --NextPart-- From avt-bounces@ietf.org Tue Aug 07 11:12:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIQjO-0001vK-0D; Tue, 07 Aug 2007 11:12:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIQjL-0001tT-Ma; Tue, 07 Aug 2007 11:12:19 -0400 Received: from nj300815-nj-outbound.net.avaya.com ([198.152.12.100] helo=nj300815-nj-outbound.avaya.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIQjL-0003PQ-2t; Tue, 07 Aug 2007 11:12:19 -0400 Received: from 12.140.64.135.in-addr.arpa (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by nj300815-nj-outbound.avaya.com with ESMTP; 07 Aug 2007 11:12:18 -0400 X-IronPort-AV: i="4.19,229,1183348800"; d="scan'208"; a="46576584:sNHT8708070" 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, 7 Aug 2007 17:12:17 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call: draft-hunt-avt-rtcpxnq (BT's eXtended Network Quality RTP Control Protocol Extended Reports (RTCP XR XNQ)) to Informational RFC Thread-Index: AcfDGqGUaT6SLkmJQcGL4/tIJusyewV6O69Q References: From: "Romascanu, Dan (Dan)" To: X-Spam-Score: 0.4 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: AVT WG Subject: [AVT] RE: Last Call: draft-hunt-avt-rtcpxnq (BT's eXtended Network Quality RTP Control Protocol Extended Reports (RTCP XR XNQ)) to Informational RFC X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org 1. 'This document has been produced to describe the report block in sufficient detail to register the block type with IANA, rather than with the intention of standardising the report block for use outside BT's network.'=20 Is this a recommendation not to use this report block outside a private network? Is the scope of the document limited to providing a specification in order to fill in the Specification Required policy for requesting an RTCP XR block type as per 3611 - if this is the case it should be made clear.=20 2.=20 'The metric vrange is the difference between the shortest and longest network packet delays seen over the duration of the connection to date. The metric vrange is a positive quantity or (unusually) zero. The metric vmaxdiff is found as follows. For each RTCP measurement cycle, find the difference between the shortest and longest network packet delays within that measurement cycle. These differences are all positive quantities or (unusually) zero. Take the set of these differences and find the maximum, which is vmaxdiff. The metric vmaxdiff is also a positive quantity or (unusually) zero.'=20 In order for the metrics to be expressed as positive numbers, should not the differences be defined as between the longest and the shortest network packet delays, and not the other way?=20 3. IANA considerations - I think that the Internet Draft should ask IANA to allocate the first free Block Type number and recommend that this number be 8, but cannot guarantee that 8 was not allocated until the time the RFC is approved.=20 Dan =20 =20 > -----Original Message----- > From: The IESG [mailto:iesg-secretary@ietf.org]=20 > Sent: Tuesday, July 10, 2007 8:45 PM > To: IETF-Announce > Subject: Last Call: draft-hunt-avt-rtcpxnq (BT's eXtended=20 > Network Quality RTP Control Protocol Extended Reports (RTCP=20 > XR XNQ)) to Informational RFC=20 >=20 > The IESG has received a request from an individual submitter=20 > to consider the following document: >=20 > - 'BT's eXtended Network Quality RTP Control Protocol=20 > Extended Reports=20 > (RTCP XR XNQ) ' > as an Informational RFC >=20 > The IESG plans to make a decision in the next few weeks, and=20 > solicits final comments on this action. Please send=20 > substantive comments to the ietf@ietf.org mailing lists by=20 > 2007-08-07. Exceptionally, comments may be sent to=20 > iesg@ietf.org instead. In either case, please retain the=20 > beginning of the Subject line to allow automated sorting. >=20 > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-hunt-avt-rtcpxnq-00.txt >=20 >=20 > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dvie > w_id&dTag=3D15988&rfc_flag=3D0 >=20 >=20 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce >=20 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Wed Aug 08 18:42:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIuCE-0006wu-Td; Wed, 08 Aug 2007 18:40:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIuCD-0006wk-IV for avt@ietf.org; Wed, 08 Aug 2007 18:40:05 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIuCC-0004QM-42 for avt@ietf.org; Wed, 08 Aug 2007 18:40:05 -0400 Received: from csperkins-dsl.demon.co.uk ([62.49.4.249]:63585 helo=[192.168.0.4]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1IIuCB-0007eB-93 for avt@ietf.org; Wed, 08 Aug 2007 23:40:03 +0100 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <68147E97-4D45-40F7-B5C3-0F12195CB753@csperkins.org> References: <68147E97-4D45-40F7-B5C3-0F12195CB753@csperkins.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5573722E-57C2-4088-8C53-DDFEE940DB13@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [AVT] Non-compound RTCP as work item? Date: Wed, 8 Aug 2007 23:39:59 +0100 To: AVT WG X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org On 31 Jul 2007, at 15:17, Colin Perkins wrote: > The consensus of the meeting in Chicago was to take the draft on > non-compound RTCP (draft-johansson-avt-rtcp-avpf-non- > compound-02.txt) as an AVT work item. This would involve adding the > following text to the charter: > > - to specify how the RFC 3550 requirement on RTCP senders to always > send compound packets can be relaxed to allow for non-compound > packets. The specification need to define under which criteria > non-compound RTCP packets may be sent while maintaining the > functionality that motivated the usage of compound RTCP packets > and keep the bandwidth within specified limits. > > with a milestone of: > > - Sep 2008 Submit Non-Compound usage specification for Proposed > Standard > > Since not all working group members attended the Chicago meeting, > this note is to solicit input on this proposal from the wider > group. Please comment on this to the mailing list by 7th August 2007. There were no objections, therefore we will send this to the IESG for approval as an AVT working group draft. -- Colin Perkins http://csperkins.org/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Aug 09 10:28:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ8xd-0003JB-OX; Thu, 09 Aug 2007 10:26:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ8xc-0003F8-OL for avt@ietf.org; Thu, 09 Aug 2007 10:26:00 -0400 Received: from gwa2.webcontrolcenter.com ([63.134.207.7]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJ8xc-0004e6-Dh for avt@ietf.org; Thu, 09 Aug 2007 10:26:00 -0400 Received: from maila14.webcontrolcenter.com (unverified [216.119.106.130]) by gwa2.webcontrolcenter.com (SurgeMail 3.8i3) with ESMTP id 23508390-1777422 for ; Thu, 09 Aug 2007 07:30:19 -0700 Received: from [72.71.255.136] by maila14.webcontrolcenter.com via HTTP; Thu, 9 Aug 2007 07:25:22 -0700 MIME-Version: 1.0 Date: Thu, 9 Aug 2007 07:25:22 -0700 From: "Cesar Trobianni" To: CC: Message-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [AVT] FECC X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ctrobianni@ecotronics.com List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1699708025==" Errors-To: avt-bounces@ietf.org This is a multi-part message in MIME format. --===============1699708025== Content-Type: multipart/alternative; boundary=----_SmarterMail_NextPart_5168677714515621 This is a multi-part message in MIME format. ------_SmarterMail_NextPart_5168677714515621 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =0D=0A=0D=0AAll,=0D=0A=0D=0AI have a question regarding the standardization= of the camera=0D=0Acontrol for video conferencing and video surveillance u= sing the SDP/RTP/RTCP=0D=0Acombo. Is there anything out there? As far as I = can tell I am only aware of the=0D=0AH.281 over H.224 over RTP by means of = RFC4573 SDP signaling.=0D=0A=0D=0AWe are currently upgrading our proprietar= y protocol to=0D=0Asupport additional capabilities and came into discussion= the already existent standards.=0D=0A=0D=0AFeedback greatly appreciated, T= hank you.=0D=0A=0D=0A ------_SmarterMail_NextPart_5168677714515621 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =0D=0A=0D=0A

All,

=0D=0A=0D=0A=0D=0A=0D=0A

I have a question regarding the standardization of the camer= a=0D=0Acontrol for video conferencing and video surveillance using the SDP/= RTP/RTCP=0D=0Acombo. Is there anything out there? As far as I can tell I am= only aware of the=0D=0AH.281 over H.224 over RTP by means of RFC4573 SDP s= ignaling.

=0D=0A=0D=0A

We are currently upgrading = our proprietary protocol to=0D=0Asupport additional capabilities and came i= nto discussion the already existent standards.=0D=0A

=0D=0A=0D=0A=0D=0A= =0D=0A

Feedback greatly appreciated, Thank= you.

=0D=0A=0D=0A ------_SmarterMail_NextPart_5168677714515621-- --===============1699708025== 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://www1.ietf.org/mailman/listinfo/avt --===============1699708025==-- From avt-bounces@ietf.org Thu Aug 09 10:34:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ94Y-0001uY-LC; Thu, 09 Aug 2007 10:33:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ94X-0001uS-Jk for avt@ietf.org; Thu, 09 Aug 2007 10:33:09 -0400 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJ94W-0004pN-SN for avt@ietf.org; Thu, 09 Aug 2007 10:33:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [AVT] FECC Date: Thu, 9 Aug 2007 17:34:19 +0300 Message-ID: <144ED8561CE90C41A3E5908EDECE315C04D4468D@IsrExch01.israel.polycom.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] FECC Thread-Index: AcfakX9Niko2tGmNSJuvwVGP7vJfdQAAGwxw From: "Even, Roni" To: , X-Spam-Score: 1.8 (+) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 Cc: X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0320459061==" Errors-To: avt-bounces@ietf.org This is a multi-part message in MIME format. --===============0320459061== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7DA92.5DD7516D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7DA92.5DD7516D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, This is currently the only FECC defined and supported by Video = conferencing systems. The way to carry the h.224 frame with H.281 in RTP is in H.323 annex Q. Roni Even =20 =20 ________________________________ From: Cesar Trobianni [mailto:ctrobianni@ecotronics.com]=20 Sent: Thursday, August 09, 2007 5:25 PM To: avt@ietf.org Subject: [AVT] FECC =20 All, I have a question regarding the standardization of the camera control = for video conferencing and video surveillance using the SDP/RTP/RTCP = combo. Is there anything out there? As far as I can tell I am only aware = of the H.281 over H.224 over RTP by means of RFC4573 SDP signaling. We are currently upgrading our proprietary protocol to support = additional capabilities and came into discussion the already existent = standards.=20 Feedback greatly appreciated, Thank you. ------_=_NextPart_001_01C7DA92.5DD7516D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

This is currently the only FECC = defined and supported by Video conferencing = systems.

The way to carry the h.224 frame = with H.281 in RTP is in H.323 annex Q.

Roni Even

 

 

From: Cesar = Trobianni [mailto:ctrobianni@ecotronics.com]
Sent: Thursday, August = 09, 2007 5:25 PM
To: avt@ietf.org
Subject: [AVT] = FECC

 

All,

I = have a question regarding the standardization of the camera control for video = conferencing and video surveillance using the SDP/RTP/RTCP combo. Is there anything out = there? As far as I can tell I am only aware of the H.281 over H.224 over RTP by = means of RFC4573 SDP signaling.

We = are currently upgrading our proprietary protocol to support additional capabilities = and came into discussion the already existent standards. =

Feedback greatly appreciated, Thank you.

------_=_NextPart_001_01C7DA92.5DD7516D-- --===============0320459061== 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://www1.ietf.org/mailman/listinfo/avt --===============0320459061==-- From avt-bounces@ietf.org Thu Aug 09 16:19:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJESO-0003im-Ts; Thu, 09 Aug 2007 16:18:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJESL-0003iY-8z for avt@ietf.org; Thu, 09 Aug 2007 16:18:06 -0400 Received: from cyber.robotics.net ([209.150.98.82] helo=barney.robotics.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJESL-000732-19 for avt@ietf.org; Thu, 09 Aug 2007 16:18:05 -0400 Received: from barney.robotics.net (barney.robotics.net [209.150.98.82]) by barney.robotics.net (8.12.10/8.12.10) with ESMTP id l79KI6FX028389; Thu, 9 Aug 2007 16:18:06 -0400 Date: Thu, 9 Aug 2007 16:18:06 -0400 (EDT) From: Nathan Allen Stratton To: Cesar Trobianni Subject: Re: [AVT] FECC In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org On Thu, 9 Aug 2007, Cesar Trobianni wrote: > All, > > I have a question regarding the standardization of the camera > control for video conferencing and video surveillance using the SDP/RTP/RTCP > combo. Is there anything out there? As far as I can tell I am only aware of the > H.281 over H.224 over RTP by means of RFC4573 SDP signaling. > > We are currently upgrading our proprietary protocol to > support additional capabilities and came into discussion the already existent standards. I have been looking for the same sort of thing for our IPTV platform, people are trying to push me to RTSP, but our network is 100% SIP/SDP/RTP! ><> Nathan Stratton CTO, Voila IP Communications nathan at robotics.net nathan at voilaip.com http://www.robotics.net http://www.voilaip.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Aug 09 19:30:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJHQx-0005DU-Ld; Thu, 09 Aug 2007 19:28:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJHQu-0005DN-KO for avt@ietf.org; Thu, 09 Aug 2007 19:28:48 -0400 Received: from gwa2.webcontrolcenter.com ([63.134.207.7]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJHQt-0003eI-P6 for avt@ietf.org; Thu, 09 Aug 2007 19:28:48 -0400 Received: from maila14.webcontrolcenter.com (unverified [216.119.106.130]) by gwa2.webcontrolcenter.com (SurgeMail 3.8i3) with ESMTP id 23656033-1777422 for multiple; Thu, 09 Aug 2007 16:33:10 -0700 Received: from [72.71.255.136] by maila14.webcontrolcenter.com via HTTP; Thu, 9 Aug 2007 16:27:56 -0700 MIME-Version: 1.0 Date: Thu, 9 Aug 2007 16:27:56 -0700 Subject: RE: [AVT] FECC From: "Cesar Trobianni" To: , Message-ID: <95c09a2735ef48faa9247c3873663e16@maila14.webcontrolcenter.com> X-Spam-Score: 1.8 (+) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ctrobianni@ecotronics.com List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0602759946==" Errors-To: avt-bounces@ietf.org This is a multi-part message in MIME format. --===============0602759946== Content-Type: multipart/alternative; boundary=----_SmarterMail_NextPart_2751528426276461 This is a multi-part message in MIME format. ------_SmarterMail_NextPart_2751528426276461 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Thanks, that's what I thought. That basically means there is no additional = camera control functionality that is standardized (other than that one defi= ned by H.281), is that correct? (regardless of the transport) =0D=0A=0D=0A-= ---------------------------------------=0D=0AFrom: "Even, Roni" =0D=0ASent: Thursday, August 09, 2007 10:51 AM=0D=0ATo: ctrob= ianni@ecotronics.com>, Th= at basically means there is no additional camera control functionality that= is standardized (other than that one defined by H.281), is that correct? (= regardless of the transport)=

From: "Even, Roni" <ron= i.even@polycom.co.il>
Sent: Thursday, August 09, 200= 7 10:51 AM
To: ctrobianni@ecotronics.com>, <avt@i= etf.org
Subject: RE: [AVT] FECC

=0D= =0A=0D=0A=0D=0A=0D=0A=0D=0A=0D= =0A
=0D=0A=0D=0A

Hi,

=0D=0A=0D=0A

This is currently the only FE= CC defined=0D=0Aand supported by Video conferencing systems.<= /p>=0D=0A=0D=0A

The way to carry the h.224 frame with=0D=0AH.281 in RTP is in H.323 annex = Q.

=0D=0A=0D=0A

Roni = Even

=0D=0A=0D=0A

 

=0D=0A=0D=0A

 

=0D=0A=0D=0A=0D=0A=0D=0A
=0D=0A=0D=0A=
=0D= =0A=0D=0A
=0D= =0A=0D=0A
=0D=0A=0D=0A

From: Cesar = Trobianni=0D=0A[mailto:ctrobianni@ecotronics.com]
=0D=0ASent: Thursday, August 09, 2007= =0D=0A5:25 PM
=0D=0ATo: avt@ietf.org
=0D=0ASubject: [AVT] FECC

=0D=0A=0D=0A
=0D= =0A=0D=0A

<= span style=3D"font-size: 12pt;"> 

=0D=0A=0D=0A

All,

=0D=0A=0D=0A

I have a question=0D=0Aregarding the standardization = of the camera control for video conferencing and=0D=0Avideo surveillance us= ing the SDP/RTP/RTCP combo. Is there anything out there?=0D=0AAs far as I c= an tell I am only aware of the H.281 over H.224 over RTP by means=0D=0Aof R= FC4573 SDP signaling.

=0D=0A=0D=0A

We are currently=0D=0Aupgrading our proprietary protocol to suppo= rt additional capabilities and came=0D=0Ainto discussion the already existe= nt standards.

=0D=0A=0D=0A

Feedback greatly=0D=0Aappreciated, Thank you.=

=0D=0A=0D=0A
=0D=0A=0D=0A
------_SmarterMail_NextPart_2751528426276461-- --===============0602759946== 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://www1.ietf.org/mailman/listinfo/avt --===============0602759946==-- From avt-bounces@ietf.org Thu Aug 09 19:39:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJHZM-0005GH-CO; Thu, 09 Aug 2007 19:37:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJHZI-0005F0-VC for avt@ietf.org; Thu, 09 Aug 2007 19:37:29 -0400 Received: from gwa2.webcontrolcenter.com ([63.134.207.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJHZI-0000On-Ce for avt@ietf.org; Thu, 09 Aug 2007 19:37:28 -0400 Received: from maila14.webcontrolcenter.com (unverified [216.119.106.130]) by gwa2.webcontrolcenter.com (SurgeMail 3.8i3) with ESMTP id 23657715-1777422 for multiple; Thu, 09 Aug 2007 16:41:51 -0700 Received: from [72.71.255.136] by maila14.webcontrolcenter.com via HTTP; Thu, 9 Aug 2007 16:36:38 -0700 MIME-Version: 1.0 Date: Thu, 9 Aug 2007 16:36:38 -0700 Subject: Re: [AVT] FECC From: "Cesar Trobianni" To: Message-ID: <86c617bf595d405d841fd5a13a6bab24@maila14.webcontrolcenter.com> X-Spam-Score: -1.0 (-) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ctrobianni@ecotronics.com List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0157761241==" Errors-To: avt-bounces@ietf.org This is a multi-part message in MIME format. --===============0157761241== Content-Type: multipart/alternative; boundary=----_SmarterMail_NextPart_3865804623156850 This is a multi-part message in MIME format. ------_SmarterMail_NextPart_3865804623156850 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable >I have been looking for the same sort of thing for our IPTV platform,=0D= =0A>people are trying to push me to RTSP, but our network is 100% SIP/SDP/R= TP!=0D=0A=0D=0AAre you talking about sending the camera control cmds over S= IP ? (i.e. on a SIP INFO)=0D=0A=0D=0AOur implementation (primary based on S= IP) uses RTCP (APP packet=0D=0Atype) to send camera control information ma= pping all the=0D=0Afunctionality of H.281 and extending it. This is mostly = for video=0D=0Asurveillance. This is pretty independent of the signaling an= d applies to any signaling that supports SDP=0D=0A ------_SmarterMail_NextPart_3865804623156850 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable >I have been looking for the same sort of thing for our IPTV platform,>people are trying to push me to RTSP, but our network is 100% SIP/SDP= /RTP!
=0D=0A
Are you talking about sending the camera control cmds ov= er SIP ? (i.e. on a SIP INFO)
=0D=0A
=0D=0AOur implementation (primar= y based on SIP) uses RTCP (APP packet=0D=0Atype) to send camera control inf= ormation  mapping all the=0D=0Afunctionality of H.281 and extending it= . This is mostly for video=0D=0Asurveillance. This is pretty independent of= the signaling and applies to any signaling that supports SDP
------_SmarterMail_NextPart_3865804623156850-- --===============0157761241== 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://www1.ietf.org/mailman/listinfo/avt --===============0157761241==-- From avt-bounces@ietf.org Thu Aug 09 22:49:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJKWo-0005Ne-2l; Thu, 09 Aug 2007 22:47:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJKWn-0005Jq-9W for avt@ietf.org; Thu, 09 Aug 2007 22:47:05 -0400 Received: from cyber.robotics.net ([209.150.98.82] helo=barney.robotics.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJKWn-0001Ho-1f for avt@ietf.org; Thu, 09 Aug 2007 22:47:05 -0400 Received: from barney.robotics.net (barney.robotics.net [209.150.98.82]) by barney.robotics.net (8.12.10/8.12.10) with ESMTP id l7A2l5FX032254; Thu, 9 Aug 2007 22:47:05 -0400 Date: Thu, 9 Aug 2007 22:47:05 -0400 (EDT) From: Nathan Allen Stratton To: Cesar Trobianni Subject: Re: [AVT] FECC In-Reply-To: <86c617bf595d405d841fd5a13a6bab24@maila14.webcontrolcenter.com> Message-ID: References: <86c617bf595d405d841fd5a13a6bab24@maila14.webcontrolcenter.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org On Thu, 9 Aug 2007, Cesar Trobianni wrote: > >I have been looking for the same sort of thing for our IPTV platform, > >people are trying to push me to RTSP, but our network is 100% SIP/SDP/RTP! > > Are you talking about sending the camera control cmds over SIP ? (i.e. on a SIP INFO) > > Our implementation (primary based on SIP) uses RTCP (APP packet > type) to send camera control information mapping all the > functionality of H.281 and extending it. This is mostly for video > surveillance. This is pretty independent of the signaling and applies to any signaling that supports SDP In my case I am talking about trick play functionality, stuff like stop, play ff, rew wind, chan up down, etc. ><> Nathan Stratton CTO, Voila IP Communications nathan at robotics.net nathan at voilaip.com http://www.robotics.net http://www.voilaip.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Fri Aug 10 00:50:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJMQQ-00040O-Ew; Fri, 10 Aug 2007 00:48:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJMQO-0003pl-Lj for avt@ietf.org; Fri, 10 Aug 2007 00:48:36 -0400 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJMQM-0004Z2-Sv for avt@ietf.org; Fri, 10 Aug 2007 00:48:36 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [AVT] FECC Date: Fri, 10 Aug 2007 07:49:44 +0300 Message-ID: <144ED8561CE90C41A3E5908EDECE315C04D4472D@IsrExch01.israel.polycom.com> In-Reply-To: <95c09a2735ef48faa9247c3873663e16@maila14.webcontrolcenter.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] FECC Thread-Index: Acfa3TYZch7cjyfBTsClNxXccCOtPAALHoPw From: "Even, Roni" To: , X-Spam-Score: 1.8 (+) X-Scan-Signature: e3ebaaff3b3539efaf29ef65eea2aded Cc: X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1481060808==" Errors-To: avt-bounces@ietf.org This is a multi-part message in MIME format. --===============1481060808== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7DB09.E05D747F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7DB09.E05D747F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, There was some device control in ITU based on T.120, I think it is H.283 = but it is not implemented by shipping products as far as I know. H.281 is widely deployed and interoperates in H.320, H.323 and now in = SIP video conferencing Roni =20 ________________________________ From: Cesar Trobianni [mailto:ctrobianni@ecotronics.com]=20 Sent: Friday, August 10, 2007 2:28 AM To: Even, Roni; avt@ietf.org Subject: RE: [AVT] FECC =20 Thanks, that's what I thought. That basically means there is no = additional camera control functionality that is standardized (other than = that one defined by H.281), is that correct? (regardless of the = transport) ________________________________ From: "Even, Roni" Sent: Thursday, August 09, 2007 10:51 AM To: ctrobianni@ecotronics.com>, =20 Hi, This is currently the only FECC defined and supported by Video = conferencing systems. The way to carry the h.224 frame with H.281 in RTP is in H.323 annex Q. Roni Even =20 =20 ________________________________ From: Cesar Trobianni [mailto:ctrobianni@ecotronics.com]=20 Sent: Thursday, August 09, 2007 5:25 PM To: avt@ietf.org Subject: [AVT] FECC =20 All, I have a question regarding the standardization of the camera control = for video conferencing and video surveillance using the SDP/RTP/RTCP = combo. Is there anything out there? As far as I can tell I am only aware = of the H.281 over H.224 over RTP by means of RFC4573 SDP signaling. We are currently upgrading our proprietary protocol to support = additional capabilities and came into discussion the already existent = standards.=20 Feedback greatly appreciated, Thank you. =20 ------_=_NextPart_001_01C7DB09.E05D747F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

There was some device control in = ITU based on T.120, I think it is H.283 but it is not implemented by shipping = products as far as I know.

H.281 is widely deployed and = interoperates in H.320, H.323 and now in SIP video = conferencing

Roni

 

From: Cesar = Trobianni [mailto:ctrobianni@ecotronics.com]
Sent: Friday, August 10, = 2007 2:28 AM
To: Even, Roni; = avt@ietf.org
Subject: RE: [AVT] = FECC

 

Thanks, that's = what I thought. That basically means there is no additional camera control functionality that is standardized (other than that one defined by = H.281), is that correct? (regardless of the transport)

From: = "Even, Roni" <roni.even@polycom.co.il>
Sent: Thursday, August 09, 2007 10:51 AM
To: ctrobianni@ecotronics.com>, <avt@ietf.org
Subject: RE: [AVT] FECC

Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0cm; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman";} a:link, span.MsoHyperlink {color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {color:purple; text-decoration:underline;} span.EmailStyle17 {mso-style-type:personal-reply; = font-family:Arial; color:navy;} @page Section1 {size:612.0pt 792.0pt; margin:72.0pt 90.0pt 72.0pt = 90.0pt;} = div.Section1 {page:Section1;} -->

Hi,

This is currently the only FECC defined and supported by = Video conferencing systems.

The way to carry the h.224 frame with H.281 in RTP is in = H.323 annex Q.

Roni = Even

 

 

<= font size=3D2 face=3DTahoma>From: Cesar Trobianni [mailto:ctrobianni@ecotronics.com]
Sent: Thursday, August 09, 2007 5:25 PM
To: avt@ietf.org
Subject: [AVT] FECC

 

All,

I = have a question regarding the standardization of the camera control for video = conferencing and video surveillance using the SDP/RTP/RTCP combo. Is there anything out = there? As far as I can tell I am only aware of the H.281 over H.224 over RTP by = means of RFC4573 SDP signaling.

We = are currently upgrading our proprietary protocol to support additional capabilities = and came into discussion the already existent standards. =

Feedback greatly appreciated, Thank you.

 

------_=_NextPart_001_01C7DB09.E05D747F-- --===============1481060808== 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://www1.ietf.org/mailman/listinfo/avt --===============1481060808==-- From avt-bounces@ietf.org Mon Aug 13 12:38:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKct4-0002w3-Pf; Mon, 13 Aug 2007 12:35:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKct4-0002vv-7l for avt@ietf.org; Mon, 13 Aug 2007 12:35:26 -0400 Received: from [212.25.125.1] (helo=aclmsg.corp.audiocodes.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKct3-0003y3-9x for avt@ietf.org; Mon, 13 Aug 2007 12:35:25 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 13 Aug 2007 19:35:20 +0300 Message-ID: <79B4F738DDD4EF4F85A4641A0FE5EFD602CA8E0E@aclmsg.corp.audiocodes.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 3984 offer/answer Question Thread-Index: Acfdx/Bx9nsXkGGeQTis3udxE7u6cA== From: "Yuval Nissan" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Subject: [AVT] RFC 3984 offer/answer Question X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1764811034==" Errors-To: avt-bounces@ietf.org This is a multi-part message in MIME format. --===============1764811034== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7DDC7.F0931DD6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7DDC7.F0931DD6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I would like to clarify the following scenario: =20 A and B use the same H.264 profile and packetization mode (this assumption is only for simplicity).=20 A supports up to level 3.0, and B supports only level 1.0. A doesn't know the level supported by B, and it wants to start the negotiation as offerer. =20 My understanding is that A needs to send in the SDP new attribute for each level from 1.0 to 3.0 in order to ensure interoperability. Is this correct? =20 Regards, Yuval =20 =20 =20 =20 ------_=_NextPart_001_01C7DDC7.F0931DD6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I would like to clarify the following = scenario:

 

A and B use the same H.264 profile and packetization = mode (this assumption is only for simplicity).

A supports up to level 3.0, and B supports only level = 1.0.

A doesn’t know the level supported by B, and it = wants to start the negotiation as offerer.

 

My understanding is that A needs to send in the SDP = new attribute for each level from 1.0 to 3.0 in order to ensure interoperability. Is = this correct?

 

Regards,

Yuval

 

 

 

 

------_=_NextPart_001_01C7DDC7.F0931DD6-- --===============1764811034== 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://www1.ietf.org/mailman/listinfo/avt --===============1764811034==-- From avt-bounces@ietf.org Tue Aug 14 03:05:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKqPp-0007Db-Ji; Tue, 14 Aug 2007 03:02:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKqPo-000766-9v for avt@ietf.org; Tue, 14 Aug 2007 03:02:08 -0400 Received: from nf-out-0910.google.com ([64.233.182.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKqPm-0006a7-EI for avt@ietf.org; Tue, 14 Aug 2007 03:02:08 -0400 Received: by nf-out-0910.google.com with SMTP id c10so647984nfd for ; Tue, 14 Aug 2007 00:02:05 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ot4Y9+dionwZLZq865ynfUYd+eh1GzxqTBvxuBnVVeBQl3g36ZW9aCsYPs2lHp/O0R6Iqe8CyQxn8Ku8FA3LWpiXy13xjWHNyB5QOoKB/hwmlf18QoWanioR3WKVxClrJq1n2Vaxh4whjyD73DUQQ7glwC94cS1n068bpJvB750= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Q3fu8i4y5r2RyfHY/j7whZjOdqDKgp2OY9tb7LEzBTF2lbWsFj2cWlCjIkNnlMziRY7hC5F324ra6lPMYK0nId+wTIyQ2oBEF+hLlOk3xj1yRsm4U6oygKkmP6+uuLsHVyhaWQD+uffp4drDfMkPf48MVFDHsQ2EZahIEgp2t3Q= Received: by 10.78.56.19 with SMTP id e19mr2478702hua.1187074925074; Tue, 14 Aug 2007 00:02:05 -0700 (PDT) Received: by 10.78.140.19 with HTTP; Tue, 14 Aug 2007 00:02:05 -0700 (PDT) Message-ID: <4e5a3720708140002m59db750n9a1cdd066a84d44f@mail.gmail.com> Date: Tue, 14 Aug 2007 10:02:05 +0300 From: "Murat Artun" To: "Yuval Nissan" Subject: Re: [AVT] RFC 3984 offer/answer Question In-Reply-To: <79B4F738DDD4EF4F85A4641A0FE5EFD602CA8E0E@aclmsg.corp.audiocodes.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <79B4F738DDD4EF4F85A4641A0FE5EFD602CA8E0E@aclmsg.corp.audiocodes.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Hello, inline... On 8/13/07, Yuval Nissan wrote: > > > > > Hi, > > > > I would like to clarify the following scenario: > > > > A and B use the same H.264 profile and packetization mode (this assumption > is only for simplicity). > > A supports up to level 3.0, and B supports only level 1.0. > > A doesn't know the level supported by B, and it wants to start the > negotiation as offerer. > > > > My understanding is that A needs to send in the SDP new attribute for each > level from 1.0 to 3.0 in order to ensure interoperability. Is this correct? > This does not seem to comply with the offer/answer procedure. Do you mean a new connection establishment attempt to take place after the first that you defined above is somehow rejected or fails with a reject in the SIP level? > > > Regards, > > Yuval > > > > > > > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > > -- M u r at A r t u n, MSc. Design Engineer "be conservative in what you do, be liberal in what you accept from others" _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Tue Aug 14 07:39:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKuhd-0004Oo-V5; Tue, 14 Aug 2007 07:36:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKuhc-0004Oi-SD for avt@ietf.org; Tue, 14 Aug 2007 07:36:48 -0400 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKuhb-00063N-92 for avt@ietf.org; Tue, 14 Aug 2007 07:36:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [AVT] RFC 3984 offer/answer Question Date: Tue, 14 Aug 2007 14:38:00 +0300 Message-ID: <144ED8561CE90C41A3E5908EDECE315C04D44AB4@IsrExch01.israel.polycom.com> In-Reply-To: <79B4F738DDD4EF4F85A4641A0FE5EFD602CA8E0E@aclmsg.corp.audiocodes.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] RFC 3984 offer/answer Question Thread-Index: Acfdx/Bx9nsXkGGeQTis3udxE7u6cAAnzKlg From: "Even, Roni" To: "Yuval Nissan" , X-Spam-Score: 0.0 (/) X-Scan-Signature: f60fbf3dbcaca652b6d10036f0630412 Cc: X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1709091577==" Errors-To: avt-bounces@ietf.org This is a multi-part message in MIME format. --===============1709091577== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7DE67.88C0C847" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7DE67.88C0C847 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Yuval, The level is the highest level supported so level 3 means that you also support level 1. This is specified in RFC 3984. B can offer level 3. Roni Even =20 ________________________________ From: Yuval Nissan [mailto:Yuval.Nissan@audiocodes.com]=20 Sent: Monday, August 13, 2007 7:35 PM To: avt@ietf.org Subject: [AVT] RFC 3984 offer/answer Question =20 Hi, =20 I would like to clarify the following scenario: =20 A and B use the same H.264 profile and packetization mode (this assumption is only for simplicity).=20 A supports up to level 3.0, and B supports only level 1.0. A doesn't know the level supported by B, and it wants to start the negotiation as offerer. =20 My understanding is that A needs to send in the SDP new attribute for each level from 1.0 to 3.0 in order to ensure interoperability. Is this correct? =20 Regards, Yuval =20 =20 =20 =20 ------_=_NextPart_001_01C7DE67.88C0C847 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Yuval,

The level is the highest level = supported so level 3 means that you also support level 1. This is specified in RFC = 3984.

B can offer level = 3.

Roni = Even

 

From: Yuval = Nissan [mailto:Yuval.Nissan@audiocodes.com]
Sent: Monday, August 13, = 2007 7:35 PM
To: avt@ietf.org
Subject: [AVT] RFC 3984 offer/answer Question

 

Hi,

 

I would like to clarify the following = scenario:

 

A and B use the same H.264 profile and packetization = mode (this assumption is only for simplicity).

A supports up to level 3.0, and B supports only level = 1.0.

A doesn’t know the level supported by B, and it = wants to start the negotiation as offerer.

 

My understanding is that A needs to send in the SDP = new attribute for each level from 1.0 to 3.0 in order to ensure = interoperability. Is this correct?

 

Regards,

Yuval

 

 

 

 

------_=_NextPart_001_01C7DE67.88C0C847-- --===============1709091577== 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://www1.ietf.org/mailman/listinfo/avt --===============1709091577==-- From avt-bounces@ietf.org Tue Aug 14 12:20:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKz5X-0001mO-06; Tue, 14 Aug 2007 12:17:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKz5V-0001mE-Ls for avt@ietf.org; Tue, 14 Aug 2007 12:17:45 -0400 Received: from gwa2.webcontrolcenter.com ([63.134.207.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKz5U-0007ZZ-13 for avt@ietf.org; Tue, 14 Aug 2007 12:17:45 -0400 Received: from maila14.webcontrolcenter.com (unverified [216.119.106.130]) by gwa2.webcontrolcenter.com (SurgeMail 3.8i3) with ESMTP id 24543715-1777422 for multiple; Tue, 14 Aug 2007 09:22:53 -0700 Received: from [71.168.69.72] by maila14.webcontrolcenter.com via HTTP; Tue, 14 Aug 2007 09:17:08 -0700 MIME-Version: 1.0 Date: Tue, 14 Aug 2007 09:17:08 -0700 Subject: RE: [AVT] RFC 3984 offer/answer Question From: "Cesar Trobianni" To: ,, Message-ID: X-Spam-Score: -1.0 (-) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ctrobianni@ecotronics.com List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0671308619==" Errors-To: avt-bounces@ietf.org This is a multi-part message in MIME format. --===============0671308619== Content-Type: multipart/alternative; boundary=----_SmarterMail_NextPart_5035512522303548 This is a multi-part message in MIME format. ------_SmarterMail_NextPart_5035512522303548 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable >The level is the highest level supported=0D=0Aso level 3 means that you al= so support level 1. This is specified in RFC 3984. =0D=0A=0D=0A>B can offer= level 3. =0D=0A But still a separate profile-level-id ftmp line per level = should be acceptable (as worst-case scenario), right? =0D=0A=0D=0A---------= -------------------------------=0D=0AFrom: "Even, Roni" =0D=0ASent: Tuesday, August 14, 2007 7:38 AM=0D=0ATo: "Yuval Nissan" = , =0D=0ASubject: RE: [AVT] RFC 3= 984 offer/answer Question =0D=0A=0D=0AYuval, =0D=0A=0D=0AThe level is the h= ighest level supported=0D=0Aso level 3 means that you also support level 1.= This is specified in RFC 3984. =0D=0A=0D=0AB can offer level 3. =0D=0A=0D= =0ARoni Even =0D=0A=0D=0A =0D=0A=0D=0A------------------------------------= ----=0D=0A=0D=0AFrom: Yuval Nissan=0D=0A[mailto:Yuval.Nissan@audiocodes.co= m] =0D=0A=0D=0ASent: Monday, August 13, 2007 7:35=0D=0APM=0D=0A=0D=0ATo: av= t@ietf.org=0D=0A=0D=0ASubject: [AVT] RFC 3984=0D=0Aoffer/answer Question = =0D=0A=0D=0A =0D=0A=0D=0AHi, =0D=0A=0D=0A =0D=0A=0D=0AI would like to cla= rify the following scenario: =0D=0A=0D=0A =0D=0A=0D=0AA and B use the same= H.264 profile and packetization mode=0D=0A(this assumption is only for sim= plicity). =0D=0A=0D=0AA supports up to level 3.0, and B supports only leve= l 1.0. =0D=0A=0D=0AA doesn't know the level supported by B, and it wants=0D= =0Ato start the negotiation as offerer. =0D=0A=0D=0A =0D=0A=0D=0AMy unders= tanding is that A needs to send in the SDP new=0D=0Aattribute for each leve= l from 1.0 to 3.0 in order to ensure interoperability. Is=0D=0Athis correct= ? =0D=0A=0D=0A =0D=0A=0D=0ARegards, =0D=0A=0D=0AYuval =0D=0A=0D=0A =0D=0A= =0D=0A =0D=0A=0D=0A =0D=0A=0D=0A =0D=0A=0D=0A ------_SmarterMail_NextPart_5035512522303548 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

>The level = is the highest level supported=0D=0Aso level 3 means that you also support = level 1. This is specified in RFC 3984.

=0D=0A=0D=0A

>B can offer leve= l 3.


But still a separate profile-level-id ftmp line per level = should be acceptable (as worst-case scenario), right?

=
From: "Even, Roni" <roni.ev= en@polycom.co.il>
Sent: Tuesday, August 14, 2007 7:3= 8 AM
To: "Yuval Nissan" <Yuval.Nissan@audiocodes.com= >, <avt@ietf.org>
Subject: RE: [AVT] RFC 3984 = offer/answer Question

= =0D=0A=0D=0A=0D=0A=0D=0A=0D=0A= =0D=0A
=0D=0A=0D=0A

Yuval,

=0D=0A=0D=0A

The level is the highest = level supported=0D=0Aso level 3 means that you also support level 1. This i= s specified in RFC 3984.

=0D=0A=0D=0A

B can offer level 3.<= /p>=0D=0A=0D=0A

Roni Even

=0D=0A=0D=0A

 

=0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D= =0A
=0D=0A=0D= =0A
=0D=0A=0D=0A

From: Yuval Nissan= =0D=0A[mailto:Yuval.Nissan@audiocodes.com]
=0D=0ASent: Monday, August 13, 2007 7:35=0D= =0APM
=0D=0ATo: avt@ietf.org
=0D=0ASubject= : [AVT] RFC 3984=0D=0Aoffer/answer Question=0D=0A=0D=0A

=0D=0A=0D=0A

 =

=0D=0A=0D=0A

Hi,

=0D= =0A=0D=0A

 

=0D=0A=0D= =0A

I would like to clarify the following s= cenario:

=0D=0A=0D=0A

&nbs= p;

=0D=0A=0D=0A

A and B us= e the same H.264 profile and packetization mode=0D=0A(this assumption is on= ly for simplicity).

=0D=0A=0D=0A

A supports up to level 3.0, and B supports only level 1.0.

=0D=0A=0D=0A

A doesn't know the le= vel supported by B, and it wants=0D=0Ato start the negotiation as offerer.<= /span>

=0D=0A=0D=0A

 =

=0D=0A=0D=0A

My understanding is= that A needs to send in the SDP new=0D=0Aattribute for each level from 1.0= to 3.0 in order to ensure interoperability. Is=0D=0Athis correct?<= /font>

=0D=0A=0D=0A

 =

=0D=0A=0D=0A

Regards,

= =0D=0A=0D=0A

Yuval

=0D=0A= =0D=0A

 

=0D=0A=0D=0A=

 

=0D=0A=0D=0A

 

=0D=0A=0D=0A

 

=0D=0A=0D=0A
=0D=0A=0D=0A=

------_SmarterMail_NextPart_5035512522303548-- --===============0671308619== 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://www1.ietf.org/mailman/listinfo/avt --===============0671308619==-- From avt-bounces@ietf.org Tue Aug 14 12:25:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKzAt-0003kl-M1; Tue, 14 Aug 2007 12:23:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKzAs-0003kY-0j for avt@ietf.org; Tue, 14 Aug 2007 12:23:18 -0400 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKzAq-0007ol-7U for avt@ietf.org; Tue, 14 Aug 2007 12:23:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [AVT] RFC 3984 offer/answer Question Date: Tue, 14 Aug 2007 19:24:25 +0300 Message-ID: <144ED8561CE90C41A3E5908EDECE315C04D44B5F@IsrExch01.israel.polycom.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] RFC 3984 offer/answer Question Thread-Index: AcfejvTgfwIEz+1bRCCIQqdB+4E25AAAHjpA From: "Even, Roni" To: , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d9aaf4f837d0910b987cb9188300fdd Cc: X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1838617780==" Errors-To: avt-bounces@ietf.org This is a multi-part message in MIME format. --===============1838617780== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7DE8F.96182F4D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7DE8F.96182F4D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable No,=20 It is not needed since it does not give more options to B.=20 If A wants later to limit the level to 1 it can do a re-invite. Roni Even =20 ________________________________ From: Cesar Trobianni [mailto:ctrobianni@ecotronics.com]=20 Sent: Tuesday, August 14, 2007 7:17 PM To: Even, Roni; Yuval.Nissan@audiocodes.com; avt@ietf.org Subject: RE: [AVT] RFC 3984 offer/answer Question =20 >The level is the highest level supported so level 3 means that you also = support level 1. This is specified in RFC 3984. >B can offer level 3. =20 But still a separate profile-level-id ftmp line per level should be = acceptable (as worst-case scenario), right? =20 ________________________________ From: "Even, Roni" Sent: Tuesday, August 14, 2007 7:38 AM To: "Yuval Nissan" , Subject: RE: [AVT] RFC 3984 offer/answer Question Yuval, The level is the highest level supported so level 3 means that you also = support level 1. This is specified in RFC 3984. B can offer level 3. Roni Even =20 ________________________________ From: Yuval Nissan [mailto:Yuval.Nissan@audiocodes.com]=20 Sent: Monday, August 13, 2007 7:35 PM To: avt@ietf.org Subject: [AVT] RFC 3984 offer/answer Question =20 Hi, =20 I would like to clarify the following scenario: =20 A and B use the same H.264 profile and packetization mode (this = assumption is only for simplicity).=20 A supports up to level 3.0, and B supports only level 1.0. A doesn't know the level supported by B, and it wants to start the = negotiation as offerer. =20 My understanding is that A needs to send in the SDP new attribute for = each level from 1.0 to 3.0 in order to ensure interoperability. Is this = correct? =20 Regards, Yuval =20 =20 =20 =20 =20 ------_=_NextPart_001_01C7DE8F.96182F4D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

No,

It is not needed since it does not = give more options to B.

If A wants later to limit the level = to 1 it can do a re-invite.

Roni Even

 

From: Cesar = Trobianni [mailto:ctrobianni@ecotronics.com]
Sent: Tuesday, August 14, = 2007 7:17 PM
To: Even, Roni; Yuval.Nissan@audiocodes.com; avt@ietf.org
Subject: RE: [AVT] RFC = 3984 offer/answer Question

 

>The level is the highest level supported so level 3 = means that you also support level 1. This is specified in RFC = 3984.

>B can offer level 3.

 

But still a separate profile-level-id ftmp line per level = should be acceptable (as worst-case scenario), right?

 

From: "Even, Roni" <roni.even@polycom.co.il>
Sent: Tuesday, August 14, 2007 7:38 AM
To: "Yuval Nissan" <Yuval.Nissan@audiocodes.com>, <avt@ietf.org>
Subject: RE: [AVT] RFC 3984 offer/answer Question

Yuval,

The level is the highest level = supported so level 3 means that you also support level 1. This is specified in RFC = 3984.

B can offer level = 3.

Roni Even

 

From: Yuval = Nissan [mailto:Yuval.Nissan@audiocodes.com]
Sent: Monday, August 13, 2007 7:35 PM
To: avt@ietf.org
Subject: [AVT] RFC 3984 offer/answer Question

 

Hi,

 

I would like to clarify the following = scenario:

 

A and B use the same H.264 profile and packetization = mode (this assumption is only for simplicity).

A supports up to level 3.0, and B supports only level = 1.0.

A doesn't know the level supported by B, and it wants = to start the negotiation as offerer.

 

My understanding is that A needs to send in the SDP = new attribute for each level from 1.0 to 3.0 = in order to ensure interoperability. Is this = correct?

 

Regards,

Yuval

 

 

 

 

 

------_=_NextPart_001_01C7DE8F.96182F4D-- --===============1838617780== 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://www1.ietf.org/mailman/listinfo/avt --===============1838617780==-- From avt-bounces@ietf.org Tue Aug 14 12:27:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKzCl-0007nw-Tz; Tue, 14 Aug 2007 12:25:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKzCk-0007Pd-BR for avt@ietf.org; Tue, 14 Aug 2007 12:25:14 -0400 Received: from pr-66-150-46-254.wgate.com ([66.150.46.254] helo=exchange1.wgate.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKzCj-0002lh-SS for avt@ietf.org; Tue, 14 Aug 2007 12:25:14 -0400 Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 12:25:11 -0400 To: ctrobianni@ecotronics.com Subject: Re: [AVT] RFC 3984 offer/answer Question References: From: Randell Jesup Date: Tue, 14 Aug 2007 12:25:10 -0400 In-Reply-To: (Cesar Trobianni's message of "Tue, 14 Aug 2007 09:17:08 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 14 Aug 2007 16:25:11.0934 (UTC) FILETIME=[B01711E0:01C7DE8F] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Yuval.Nissan@audiocodes.com, roni.even@polycom.co.il, avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randell Jesup List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org "Cesar Trobianni" writes: >>The level is the highest level supported so level 3 means that you also >>support level 1. This is specified in RFC 3984. >> >>B can offer level 3. > >But still a separate profile-level-id ftmp line per level should be >acceptable (as worst-case scenario), right? You can only have one fmtp line per payload value. You can define multiple payloads with different fmtp's for a media stream, however. Responses (payloads and their fmtp's) are matched up against the offer using a combination of profile-level-id, packetization-mode, and (if used) the sprop interleave (if I remember correctly - that last one only applies to packetization-mode 2). Assuming anyone implements all of that totally correctly... :-/ -- 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://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Wed Aug 15 02:21:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILCDT-0007Gx-Pr; Wed, 15 Aug 2007 02:18:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILCDS-0007Gq-8W for avt@ietf.org; Wed, 15 Aug 2007 02:18:50 -0400 Received: from [212.25.125.1] (helo=aclmsg.corp.audiocodes.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILCDQ-000314-Ow for avt@ietf.org; Wed, 15 Aug 2007 02:18:50 -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 Subject: RE: [AVT] RFC 3984 offer/answer Question Date: Wed, 15 Aug 2007 09:18:46 +0300 Message-ID: <79B4F738DDD4EF4F85A4641A0FE5EFD602CA8E15@aclmsg.corp.audiocodes.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] RFC 3984 offer/answer Question Thread-Index: Acfej7YmxCpWniS1TKWZaYd/UAeFdgActPVQ From: "Yuval Nissan" To: "Randell Jesup" , X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: roni.even@polycom.co.il, avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org I now understand that the following scenario is legal: Offerer support up to level 3. Offerer -> Answerer SDP message: m=3Dvideo 49170 RTP/AVP 98 a=3Drtpmap:98 H264/90000 a=3Dfmtp:98 profile-level-id=3D42A01E; packetization-mode=3D0; =20 Answerer support level 1 only. Answerer -> Offerer SDP message: m=3Dvideo 49170 RTP/AVP 98 a=3Drtpmap:97 H264/90000 a=3Dfmtp:97 profile-level-id=3D42A00A; packetization-mode=3D0; =20 The offerer understands that the session should be in level 1. Thanks for your feedback, Yuval -----Original Message----- From: Randell Jesup [mailto:rjesup@wgate.com]=20 Sent: Tuesday, August 14, 2007 19:25 To: ctrobianni@ecotronics.com Cc: Yuval Nissan; roni.even@polycom.co.il; avt@ietf.org Subject: Re: [AVT] RFC 3984 offer/answer Question "Cesar Trobianni" writes: >>The level is the highest level supported so level 3 means that you also >>support level 1. This is specified in RFC 3984. >> >>B can offer level 3. > >But still a separate profile-level-id ftmp line per level should be >acceptable (as worst-case scenario), right? You can only have one fmtp line per payload value. You can define multiple payloads with different fmtp's for a media stream, however. Responses (payloads and their fmtp's) are matched up against the offer using a combination of profile-level-id, packetization-mode, and (if used) the sprop interleave (if I remember correctly - that last one only applies to packetization-mode 2). Assuming anyone implements all of that totally correctly... :-/ --=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) _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Wed Aug 15 02:52:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILChg-0004s8-VQ; Wed, 15 Aug 2007 02:50:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILChf-0004rt-Hl for avt@ietf.org; Wed, 15 Aug 2007 02:50:03 -0400 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILChd-0003g7-GA for avt@ietf.org; Wed, 15 Aug 2007 02:50:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [AVT] RFC 3984 offer/answer Question Date: Wed, 15 Aug 2007 09:51:10 +0300 Message-ID: <144ED8561CE90C41A3E5908EDECE315C04D44C16@IsrExch01.israel.polycom.com> In-Reply-To: <79B4F738DDD4EF4F85A4641A0FE5EFD602CA8E15@aclmsg.corp.audiocodes.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] RFC 3984 offer/answer Question Thread-Index: Acfej7YmxCpWniS1TKWZaYd/UAeFdgActPVQAAFzbiA= From: "Even, Roni" To: "Yuval Nissan" , "Randell Jesup" , X-Spam-Score: 0.0 (/) X-Scan-Signature: c25c25eef92c03b403abac6c7c688517 Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0001096709==" Errors-To: avt-bounces@ietf.org This is a multi-part message in MIME format. --===============0001096709== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7DF08.E46AC495" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7DF08.E46AC495 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Yuval, =20 > m=3Dvideo 49170 RTP/AVP 98 > a=3Drtpmap:97 H264/90000 > a=3Dfmtp:97 profile-level-id=3D42A00A; packetization-mode=3D0; =20 You just have a problem with the payload type 98=20 =20 > m=3Dvideo 49170 RTP/AVP 98 > a=3Drtpmap:98 H264/90000 > a=3Dfmtp:98 profile-level-id=3D42A00A; packetization-mode=3D0; =20 =20 > -----Original Message----- > From: Yuval Nissan [mailto:Yuval.Nissan@audiocodes.com] > Sent: Wednesday, August 15, 2007 9:19 AM > To: Randell Jesup; ctrobianni@ecotronics.com > Cc: Even, Roni; avt@ietf.org > Subject: RE: [AVT] RFC 3984 offer/answer Question >=20 > I now understand that the following scenario is legal: >=20 > Offerer support up to level 3. > Offerer -> Answerer SDP message: >=20 > m=3Dvideo 49170 RTP/AVP 98 > a=3Drtpmap:98 H264/90000 > a=3Dfmtp:98 profile-level-id=3D42A01E; packetization-mode=3D0; >=20 > Answerer support level 1 only. > Answerer -> Offerer SDP message: >=20 > m=3Dvideo 49170 RTP/AVP 98 > a=3Drtpmap:97 H264/90000 > a=3Dfmtp:97 profile-level-id=3D42A00A; packetization-mode=3D0; >=20 > The offerer understands that the session should be in level 1. >=20 > Thanks for your feedback, > Yuval >=20 >=20 > -----Original Message----- > From: Randell Jesup [mailto:rjesup@wgate.com] > Sent: Tuesday, August 14, 2007 19:25 > To: ctrobianni@ecotronics.com > Cc: Yuval Nissan; roni.even@polycom.co.il; avt@ietf.org > Subject: Re: [AVT] RFC 3984 offer/answer Question >=20 > "Cesar Trobianni" writes: > >>The level is the highest level supported so level 3 means that you > also > >>support level 1. This is specified in RFC 3984. > >> > >>B can offer level 3. > > > >But still a separate profile-level-id ftmp line per level should be > >acceptable (as worst-case scenario), right? >=20 > You can only have one fmtp line per payload value. >=20 > You can define multiple payloads with different fmtp's for a media > stream, > however. Responses (payloads and their fmtp's) are matched up against > the > offer using a combination of profile-level-id, packetization-mode, and > (if > used) the sprop interleave (if I remember correctly - that last one only > applies to packetization-mode 2). >=20 > Assuming anyone implements all of that totally correctly... :-/ >=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 >=20 > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt ------_=_NextPart_001_01C7DF08.E46AC495 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Yuval,

 

>      m=3Dvideo = 49170 RTP/AVP 98

>      a=3Drtpmap:97 = H264/90000

>      a=3Dfmtp:97 = profile-level-id=3D42A00A; packetization-mode=3D0;

 

You just have a problem with the payload type 98 =

 

>      m=3Dvideo 49170 RTP/AVP = 98

>      a=3Drtpmap:98 = H264/90000

>      a=3Dfmtp:98 = profile-level-id=3D42A00A; packetization-mode=3D0;

 

 

> -----Original Message-----

> From: Yuval Nissan = [mailto:Yuval.Nissan@audiocodes.com]

> Sent: Wednesday, August 15, 2007 9:19 AM

> To: Randell Jesup; = ctrobianni@ecotronics.com

> Cc: Even, Roni; avt@ietf.org

> Subject: RE: [AVT] RFC 3984 offer/answer = Question

>

> I now understand that the following scenario is = legal:

>

> Offerer support up to level 3.

> Offerer -> Answerer SDP message:

>

>       m=3Dvideo 49170 RTP/AVP = 98

>       a=3Drtpmap:98 = H264/90000

>       a=3Dfmtp:98 profile-level-id=3D42A01E; packetization-mode=3D0;

>

> Answerer support level 1 only.

> Answerer -> Offerer SDP message:

>

>      m=3Dvideo 49170 RTP/AVP = 98

>      a=3Drtpmap:97 = H264/90000

>      a=3Dfmtp:97 = profile-level-id=3D42A00A; packetization-mode=3D0;

>

> The offerer understands that the session should be in level = 1.

>

> Thanks for your feedback,

> Yuval

>

>

> -----Original Message-----

> From: Randell Jesup = [mailto:rjesup@wgate.com]

> Sent: Tuesday, August 14, 2007 19:25

> To: ctrobianni@ecotronics.com

> Cc: Yuval Nissan; roni.even@polycom.co.il; = avt@ietf.org

> Subject: Re: [AVT] RFC 3984 offer/answer = Question

>

> "Cesar Trobianni" = <ctrobianni@ecotronics.com> writes:

> >>The level is the highest level supported so level 3 = means that you

> also

> >>support level 1. This is specified in RFC = 3984.

> >>

> >>B can offer level 3.

> >

> >But still a separate profile-level-id ftmp line per = level should be

> >acceptable (as worst-case scenario), = right?

>

> You can only have one fmtp line per payload = value.

>

> You can define multiple payloads with different fmtp's for = a media

> stream,

> however.  Responses (payloads and their fmtp's) are = matched up against

> the

> offer using a combination of profile-level-id, = packetization-mode, and

> (if

> used) the sprop interleave (if I remember correctly - that = last one only

> applies to packetization-mode 2).

>

> Assuming anyone implements all of that totally correctly... = :-/

>

> --

> 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://www1.ietf.org/mailman/listinfo/avt

------_=_NextPart_001_01C7DF08.E46AC495-- --===============0001096709== 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://www1.ietf.org/mailman/listinfo/avt --===============0001096709==-- From avt-bounces@ietf.org Wed Aug 15 07:42:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILHEt-0003pz-WC; Wed, 15 Aug 2007 07:40:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILHEq-0003jP-7H for avt@ietf.org; Wed, 15 Aug 2007 07:40:36 -0400 Received: from pr-66-150-46-254.wgate.com ([66.150.46.254] helo=exchange1.wgate.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILHEp-0008Il-Ku for avt@ietf.org; Wed, 15 Aug 2007 07:40:36 -0400 Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Aug 2007 07:40:35 -0400 To: "Even, Roni" Subject: Re: [AVT] RFC 3984 offer/answer Question References: <144ED8561CE90C41A3E5908EDECE315C04D44C16@IsrExch01.israel.polycom.com> From: Randell Jesup Date: Wed, 15 Aug 2007 07:40:33 -0400 In-Reply-To: <144ED8561CE90C41A3E5908EDECE315C04D44C16@IsrExch01.israel.polycom.com> (Roni Even's message of "Wed, 15 Aug 2007 09:51:10 +0300") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 15 Aug 2007 11:40:35.0151 (UTC) FILETIME=[17F285F0:01C7DF31] X-Spam-Score: 0.0 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Cc: Yuval Nissan , avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randell Jesup List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org "Even, Roni" writes: >> m=video 49170 RTP/AVP 98 >> a=rtpmap:97 H264/90000 >> a=fmtp:97 profile-level-id=42A00A; packetization-mode=0; > >You just have a problem with the payload type 98 >> m=video 49170 RTP/AVP 98 >> a=rtpmap:98 H264/90000 >> a=fmtp:98 profile-level-id=42A00A; packetization-mode=0; Roni - I think that's invalid for offer/answer, per 8.2.2. If the offerer wants to support only level 1.0 (in this case, 42a00a), it *has* to offer it as a separate payload type in the offer. The answer cannot add it as the same payload type, and you're not supposed to add media formats (payloads) in an answer. 8.2.2. Usage with the SDP Offer/Answer Model When H.264 is offered over RTP using SDP in an Offer/Answer model [7] for negotiation for unicast usage, the following limitations and rules apply: o The parameters identifying a media format configuration for H.264 are "profile-level-id", "packetization-mode", and, if required by "packetization-mode", "sprop-deint-buf-req". These three parameters MUST be used symmetrically; i.e., the answerer MUST either maintain all configuration parameters or remove the media format (payload type) completely, if one or more of the parameter values are not supported. Informative note: The requirement for symmetric use applies only for the above three parameters and not for the other stream properties and capability parameters. > > > > > >> -----Original Message----- > >> From: Yuval Nissan [mailto:Yuval.Nissan@audiocodes.com] > >> Sent: Wednesday, August 15, 2007 9:19 AM > >> To: Randell Jesup; ctrobianni@ecotronics.com > >> Cc: Even, Roni; avt@ietf.org > >> Subject: RE: [AVT] RFC 3984 offer/answer Question > >> > >> I now understand that the following scenario is legal: > >> > >> Offerer support up to level 3. > >> Offerer -> Answerer SDP message: > >> > >> m=video 49170 RTP/AVP 98 > >> a=rtpmap:98 H264/90000 > >> a=fmtp:98 profile-level-id=42A01E; packetization-mode=0; > >> > >> Answerer support level 1 only. > >> Answerer -> Offerer SDP message: > >> > >> m=video 49170 RTP/AVP 98 > >> a=rtpmap:97 H264/90000 > >> a=fmtp:97 profile-level-id=42A00A; packetization-mode=0; > >> > >> The offerer understands that the session should be in level 1. > >> > >> Thanks for your feedback, > >> Yuval > >> > >> > >> -----Original Message----- > >> From: Randell Jesup [mailto:rjesup@wgate.com] > >> Sent: Tuesday, August 14, 2007 19:25 > >> To: ctrobianni@ecotronics.com > >> Cc: Yuval Nissan; roni.even@polycom.co.il; avt@ietf.org > >> Subject: Re: [AVT] RFC 3984 offer/answer Question > >> > >> "Cesar Trobianni" writes: > >> >>The level is the highest level supported so level 3 means that you > >> also > >> >>support level 1. This is specified in RFC 3984. > >> >> > >> >>B can offer level 3. > >> > > >> >But still a separate profile-level-id ftmp line per level should be > >> >acceptable (as worst-case scenario), right? > >> > >> You can only have one fmtp line per payload value. > >> > >> You can define multiple payloads with different fmtp's for a media > >> stream, > >> however. Responses (payloads and their fmtp's) are matched up against > >> the > >> offer using a combination of profile-level-id, packetization-mode, and > >> (if > >> used) the sprop interleave (if I remember correctly - that last one >only > >> applies to packetization-mode 2). > >> > >> Assuming anyone implements all of that totally correctly... :-/ > >> > >> -- > >> 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://www1.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://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Wed Aug 15 08:17:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILHmk-0005lN-TO; Wed, 15 Aug 2007 08:15:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILHmj-0005lH-EG for avt@ietf.org; Wed, 15 Aug 2007 08:15:37 -0400 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILHmf-00033j-Tn for avt@ietf.org; Wed, 15 Aug 2007 08:15:37 -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 Subject: RE: [AVT] RFC 3984 offer/answer Question Date: Wed, 15 Aug 2007 15:16:49 +0300 Message-ID: <144ED8561CE90C41A3E5908EDECE315C04D44CA1@IsrExch01.israel.polycom.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] RFC 3984 offer/answer Question Thread-Index: AcffMUOQOcPhbBVKS+WNduG6apqeswABCQ0Q From: "Even, Roni" To: "Randell Jesup" X-Spam-Score: 0.0 (/) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 Cc: stewe@stewe.org, Yuval Nissan , avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Randell, "If the offerer wants to support only level 1.0" - this is not the case here. The offerer can support level 3. The answerer can support only level 1 which is implied by the offer. The parameter value is supported. This is why the answerer maintains the configuration parameters.=20 Roni !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! A consensus means that everyone agrees to say collectively what no one believes individually !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=20 > -----Original Message----- > From: Randell Jesup [mailto:rjesup@wgate.com] > Sent: Wednesday, August 15, 2007 2:41 PM > To: Even, Roni > Cc: Yuval Nissan; ctrobianni@ecotronics.com; avt@ietf.org > Subject: Re: [AVT] RFC 3984 offer/answer Question >=20 > "Even, Roni" writes: > >> m=3Dvideo 49170 RTP/AVP 98 > >> a=3Drtpmap:97 H264/90000 > >> a=3Dfmtp:97 profile-level-id=3D42A00A; packetization-mode=3D0; > > > >You just have a problem with the payload type 98 >=20 > >> m=3Dvideo 49170 RTP/AVP 98 > >> a=3Drtpmap:98 H264/90000 > >> a=3Dfmtp:98 profile-level-id=3D42A00A; packetization-mode=3D0; >=20 > Roni - >=20 > I think that's invalid for offer/answer, per 8.2.2. If the offerer wants > to support only level 1.0 (in this case, 42a00a), it *has* to offer it > as a separate payload type in the offer. The answer cannot add it as > the same payload type, and you're not supposed to add media formats > (payloads) in an answer. >=20 >=20 > 8.2.2. Usage with the SDP Offer/Answer Model >=20 > When H.264 is offered over RTP using SDP in an Offer/Answer model [7] > for negotiation for unicast usage, the following limitations and > rules apply: >=20 > o The parameters identifying a media format configuration for H.264 > are "profile-level-id", "packetization-mode", and, if required by > "packetization-mode", "sprop-deint-buf-req". These three > parameters MUST be used symmetrically; i.e., the answerer MUST > either maintain all configuration parameters or remove the media > format (payload type) completely, if one or more of the parameter > values are not supported. >=20 > Informative note: The requirement for symmetric use applies > only for the above three parameters and not for the other > stream properties and capability parameters. >=20 > > > > > > > > > > > >> -----Original Message----- > > > >> From: Yuval Nissan [mailto:Yuval.Nissan@audiocodes.com] > > > >> Sent: Wednesday, August 15, 2007 9:19 AM > > > >> To: Randell Jesup; ctrobianni@ecotronics.com > > > >> Cc: Even, Roni; avt@ietf.org > > > >> Subject: RE: [AVT] RFC 3984 offer/answer Question > > > >> > > > >> I now understand that the following scenario is legal: > > > >> > > > >> Offerer support up to level 3. > > > >> Offerer -> Answerer SDP message: > > > >> > > > >> m=3Dvideo 49170 RTP/AVP 98 > > > >> a=3Drtpmap:98 H264/90000 > > > >> a=3Dfmtp:98 profile-level-id=3D42A01E; = packetization-mode=3D0; > > > >> > > > >> Answerer support level 1 only. > > > >> Answerer -> Offerer SDP message: > > > >> > > > >> m=3Dvideo 49170 RTP/AVP 98 > > > >> a=3Drtpmap:97 H264/90000 > > > >> a=3Dfmtp:97 profile-level-id=3D42A00A; packetization-mode=3D0; > > > >> > > > >> The offerer understands that the session should be in level 1. > > > >> > > > >> Thanks for your feedback, > > > >> Yuval > > > >> > > > >> > > > >> -----Original Message----- > > > >> From: Randell Jesup [mailto:rjesup@wgate.com] > > > >> Sent: Tuesday, August 14, 2007 19:25 > > > >> To: ctrobianni@ecotronics.com > > > >> Cc: Yuval Nissan; roni.even@polycom.co.il; avt@ietf.org > > > >> Subject: Re: [AVT] RFC 3984 offer/answer Question > > > >> > > > >> "Cesar Trobianni" writes: > > > >> >>The level is the highest level supported so level 3 means that you > > > >> also > > > >> >>support level 1. This is specified in RFC 3984. > > > >> >> > > > >> >>B can offer level 3. > > > >> > > > > >> >But still a separate profile-level-id ftmp line per level should be > > > >> >acceptable (as worst-case scenario), right? > > > >> > > > >> You can only have one fmtp line per payload value. > > > >> > > > >> You can define multiple payloads with different fmtp's for a media > > > >> stream, > > > >> however. Responses (payloads and their fmtp's) are matched up against > > > >> the > > > >> offer using a combination of profile-level-id, packetization-mode, and > > > >> (if > > > >> used) the sprop interleave (if I remember correctly - that last one > >only > > > >> applies to packetization-mode 2). > > > >> > > > >> Assuming anyone implements all of that totally correctly... :-/ > > > >> > > > >> -- > > > >> 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://www1.ietf.org/mailman/listinfo/avt >=20 >=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) _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Wed Aug 15 14:00:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILN8J-0005dy-7f; Wed, 15 Aug 2007 13:58:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILN8H-0005YN-DD for avt@ietf.org; Wed, 15 Aug 2007 13:58:13 -0400 Received: from pr-66-150-46-254.wgate.com ([66.150.46.254] helo=exchange1.wgate.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILN8G-0002eV-UC for avt@ietf.org; Wed, 15 Aug 2007 13:58:13 -0400 Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Aug 2007 13:58:12 -0400 To: "Even, Roni" Subject: Re: [AVT] RFC 3984 offer/answer Question References: <144ED8561CE90C41A3E5908EDECE315C04D44CA1@IsrExch01.israel.polycom.com> From: Randell Jesup Date: Wed, 15 Aug 2007 13:58:11 -0400 In-Reply-To: <144ED8561CE90C41A3E5908EDECE315C04D44CA1@IsrExch01.israel.polycom.com> (Roni Even's message of "Wed, 15 Aug 2007 15:16:49 +0300") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 15 Aug 2007 17:58:12.0462 (UTC) FILETIME=[D8C1D0E0:01C7DF65] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: stewe@stewe.org, Yuval Nissan , avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randell Jesup List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org "Even, Roni" writes: >"If the offerer wants to support only level 1.0" - this is not the case >here. The offerer can support level 3. The answerer can support only >level 1 which is implied by the offer. The parameter value is supported. >This is why the answerer maintains the configuration parameters. My apologies if I wrote too quickly - I was on the way to pick up my mother-in-law at the hospital (after 10 weeks). I should have said "if the offerer wants to also support level 1.0". It should have been clear from the context, but I mis-stated it. The offerer supports Level 3.0, and in the original question, only includes a single payload and FMTP at 3.0. According to 8.2.2 (below), you MUST use profile-level-id symmetrically (along with packetization-mode and maybe sprop-deint-buf-req). The answer MUST not change any of them, or it must remove the payload if it cannot support them. So, when offered level 3, an answerer who supports level 1 MUST remove the level 3 payload. Accordingly (and per the much longer full section 8 of the RFC and RFC 3264, I think if you want to support levels 1-N you must offer levels 1-N as separate payloads (N payloads). If you want to support packetization-modes 0 and 1 as well, you'll need 2*N payloads. I wish I'd been looking at this before it was approved, though given general offer-answer semantics it's not too surprising they chose this way. >> I think that's invalid for offer/answer, per 8.2.2. If the offerer >> wants to support only level 1.0 (in this case, 42a00a), it *has* to >> offer it as a separate payload type in the offer. The answer cannot add >> it as the same payload type, and you're not supposed to add media >> formats (payloads) in an answer. >> >> >> 8.2.2. Usage with the SDP Offer/Answer Model >> >> When H.264 is offered over RTP using SDP in an Offer/Answer model [7] >> for negotiation for unicast usage, the following limitations and >> rules apply: >> >> o The parameters identifying a media format configuration for H.264 >> are "profile-level-id", "packetization-mode", and, if required by >> "packetization-mode", "sprop-deint-buf-req". These three >> parameters MUST be used symmetrically; i.e., the answerer MUST >> either maintain all configuration parameters or remove the media >> format (payload type) completely, if one or more of the parameter >> values are not supported. >> >> Informative note: The requirement for symmetric use applies >> only for the above three parameters and not for the other >> stream properties and capability parameters. -- 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://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Aug 16 02:36:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILYwJ-0008Mt-6l; Thu, 16 Aug 2007 02:34:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILYwH-0008Mo-8Z for avt@ietf.org; Thu, 16 Aug 2007 02:34:37 -0400 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILYwF-0004Cp-T6 for avt@ietf.org; Thu, 16 Aug 2007 02:34:36 -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 Subject: RE: [AVT] RFC 3984 offer/answer Question Date: Thu, 16 Aug 2007 09:35:47 +0300 Message-ID: <144ED8561CE90C41A3E5908EDECE315C04D44DAF@IsrExch01.israel.polycom.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] RFC 3984 offer/answer Question Thread-Index: AcffZgg6V6bEBmwkRBSE4RgUduNp0gAZOXig From: "Even, Roni" To: "Randell Jesup" X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: stewe@stewe.org, Yuval Nissan , avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Randell, I can see your point but I would like to see other opinions maybe from the authors of the text. My view is that most current implementation of offer / answer for unicast has the same approach. (this is based on interoperability tests between vendors of video conferencing systems) The problem here is that the profile-level-id parameter includes three different parameters. I still think that on the level part of the parameter the comparison should be based on the highest common. I do not believe that the intention here was to fix a specific mode. Since the level parameter is an upper bound and lower levels are included (except for level 1b) it does not make sense to offer a separate media type for each level (there are 15 levels defined), for example if the offerer support level 3 it will need to specify 3,2.2, 2.1, 2, 1.3, 1.2, 1.1 and 1 using 8 media type.=20 I do not think that this was the intention in offer/answer. Offer/answer should not be used to fix a specific level. To make it more complicated, by using the other optional parameters like max-mbps, max-fs the meaning of the level according to table A.1 in H.264 is changed and the current maximum values supported are based on the sum of the values from table A.1 and the optional parameters.=20 BTW: I do not think that having the same level in the offer and answer will make the communication symmetric, the encoder on each side can send any frame size at any macro blocks per second rate that falls within the specified level (this means frame size and frame rate would not be the same on each direction).=20 If you want to have a specific picture size or frame rate (e.g. CIF at 30 fps) then you will need a different signaling for requesting specific mode. I mentioned in Chicago that we are working in H.323 on such extensions (requesting a specific mode (picture size and frame rate)) and we will have a similar draft for SDP based systems. Roni Even =20 =20 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! A consensus means that everyone agrees to say collectively what no one believes individually !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=20 > -----Original Message----- > From: Randell Jesup [mailto:rjesup@wgate.com] > Sent: Wednesday, August 15, 2007 8:58 PM > To: Even, Roni > Cc: Yuval Nissan; ctrobianni@ecotronics.com; avt@ietf.org; stewe@stewe.org > Subject: Re: [AVT] RFC 3984 offer/answer Question >=20 > "Even, Roni" writes: > >"If the offerer wants to support only level 1.0" - this is not the case > >here. The offerer can support level 3. The answerer can support only > >level 1 which is implied by the offer. The parameter value is supported. > >This is why the answerer maintains the configuration parameters. >=20 > My apologies if I wrote too quickly - I was on the way to pick up my > mother-in-law at the hospital (after 10 weeks). I should have said > "if the offerer wants to also support level 1.0". It should have > been clear from the context, but I mis-stated it. >=20 >=20 > The offerer supports Level 3.0, and in the original question, only > includes > a single payload and FMTP at 3.0. According to 8.2.2 (below), you MUST > use > profile-level-id symmetrically (along with packetization-mode and maybe > sprop-deint-buf-req). The answer MUST not change any of them, or it must > remove the payload if it cannot support them. So, when offered level 3, > an > answerer who supports level 1 MUST remove the level 3 payload. >=20 > Accordingly (and per the much longer full section 8 of the RFC and RFC > 3264, I think if you want to support levels 1-N you must offer levels 1-N > as separate payloads (N payloads). If you want to support > packetization-modes 0 and 1 as well, you'll need 2*N payloads. >=20 > I wish I'd been looking at this before it was approved, though given > general offer-answer semantics it's not too surprising they chose this > way. >=20 > >> I think that's invalid for offer/answer, per 8.2.2. If the offerer > >> wants to support only level 1.0 (in this case, 42a00a), it *has* to > >> offer it as a separate payload type in the offer. The answer cannot > add > >> it as the same payload type, and you're not supposed to add media > >> formats (payloads) in an answer. > >> > >> > >> 8.2.2. Usage with the SDP Offer/Answer Model > >> > >> When H.264 is offered over RTP using SDP in an Offer/Answer model > [7] > >> for negotiation for unicast usage, the following limitations and > >> rules apply: > >> > >> o The parameters identifying a media format configuration for H.264 > >> are "profile-level-id", "packetization-mode", and, if required by > >> "packetization-mode", "sprop-deint-buf-req". These three > >> parameters MUST be used symmetrically; i.e., the answerer MUST > >> either maintain all configuration parameters or remove the media > >> format (payload type) completely, if one or more of the parameter > >> values are not supported. > >> > >> Informative note: The requirement for symmetric use applies > >> only for the above three parameters and not for the other > >> stream properties and capability parameters. > -- > 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://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Aug 16 03:03:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILZMr-0002ap-Ez; Thu, 16 Aug 2007 03:02:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILZMq-0002ak-8Q for avt@ietf.org; Thu, 16 Aug 2007 03:02:04 -0400 Received: from [212.25.125.1] (helo=aclmsg.corp.audiocodes.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILZMo-0004Yj-GK for avt@ietf.org; Thu, 16 Aug 2007 03:02:04 -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 Subject: RE: [AVT] RFC 3984 offer/answer Question Date: Thu, 16 Aug 2007 10:01:57 +0300 Message-ID: <79B4F738DDD4EF4F85A4641A0FE5EFD602CA8E22@aclmsg.corp.audiocodes.com> In-Reply-To: <144ED8561CE90C41A3E5908EDECE315C04D44DAF@IsrExch01.israel.polycom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] RFC 3984 offer/answer Question Thread-Index: AcffZgg6V6bEBmwkRBSE4RgUduNp0gAZOXigAAFiXZA= From: "Yuval Nissan" To: "Even, Roni" , "Randell Jesup" X-Spam-Score: 0.1 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Cc: stewe@stewe.org, Ilan Avner , avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Roni, Regarding the communication symmetric - if we understand it the way which you propose (which I think is the practical one): Offerer support up to level 3. Offerer -> Answerer SDP message: m=3Dvideo 49170 RTP/AVP 98 a=3Drtpmap:98 H264/90000 a=3Dfmtp:98 profile-level-id=3D42A01E; packetization-mode=3D0; =20 Answerer support level 1 only. Answerer -> Offerer SDP message: m=3Dvideo 49170 RTP/AVP 98 a=3Drtpmap:98 H264/90000 a=3Dfmtp:98 profile-level-id=3D42A00A; packetization-mode=3D0; =20 There can be 2 possibilities: 1. The offerer must transmit in level 1.0. Still the answerer can transmit up to level 3.0 if he wants.=20 2. Both of them must use level 1. Which one is correct? =20 Yuval =20 -----Original Message----- From: Even, Roni [mailto:roni.even@polycom.co.il]=20 Sent: Thursday, August 16, 2007 09:36 To: Randell Jesup Cc: Yuval Nissan; ctrobianni@ecotronics.com; avt@ietf.org; stewe@stewe.org Subject: RE: [AVT] RFC 3984 offer/answer Question Randell, I can see your point but I would like to see other opinions maybe from the authors of the text. My view is that most current implementation of offer / answer for unicast has the same approach. (this is based on interoperability tests between vendors of video conferencing systems) The problem here is that the profile-level-id parameter includes three different parameters. I still think that on the level part of the parameter the comparison should be based on the highest common. I do not believe that the intention here was to fix a specific mode. Since the level parameter is an upper bound and lower levels are included (except for level 1b) it does not make sense to offer a separate media type for each level (there are 15 levels defined), for example if the offerer support level 3 it will need to specify 3,2.2, 2.1, 2, 1.3, 1.2, 1.1 and 1 using 8 media type.=20 I do not think that this was the intention in offer/answer. Offer/answer should not be used to fix a specific level. To make it more complicated, by using the other optional parameters like max-mbps, max-fs the meaning of the level according to table A.1 in H.264 is changed and the current maximum values supported are based on the sum of the values from table A.1 and the optional parameters.=20 BTW: I do not think that having the same level in the offer and answer will make the communication symmetric, the encoder on each side can send any frame size at any macro blocks per second rate that falls within the specified level (this means frame size and frame rate would not be the same on each direction).=20 If you want to have a specific picture size or frame rate (e.g. CIF at 30 fps) then you will need a different signaling for requesting specific mode. I mentioned in Chicago that we are working in H.323 on such extensions (requesting a specific mode (picture size and frame rate)) and we will have a similar draft for SDP based systems. Roni Even =20 =20 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! A consensus means that everyone agrees to say collectively what no one believes individually !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=20 > -----Original Message----- > From: Randell Jesup [mailto:rjesup@wgate.com] > Sent: Wednesday, August 15, 2007 8:58 PM > To: Even, Roni > Cc: Yuval Nissan; ctrobianni@ecotronics.com; avt@ietf.org; stewe@stewe.org > Subject: Re: [AVT] RFC 3984 offer/answer Question >=20 > "Even, Roni" writes: > >"If the offerer wants to support only level 1.0" - this is not the case > >here. The offerer can support level 3. The answerer can support only > >level 1 which is implied by the offer. The parameter value is supported. > >This is why the answerer maintains the configuration parameters. >=20 > My apologies if I wrote too quickly - I was on the way to pick up my > mother-in-law at the hospital (after 10 weeks). I should have said > "if the offerer wants to also support level 1.0". It should have > been clear from the context, but I mis-stated it. >=20 >=20 > The offerer supports Level 3.0, and in the original question, only > includes > a single payload and FMTP at 3.0. According to 8.2.2 (below), you MUST > use > profile-level-id symmetrically (along with packetization-mode and maybe > sprop-deint-buf-req). The answer MUST not change any of them, or it must > remove the payload if it cannot support them. So, when offered level 3, > an > answerer who supports level 1 MUST remove the level 3 payload. >=20 > Accordingly (and per the much longer full section 8 of the RFC and RFC > 3264, I think if you want to support levels 1-N you must offer levels 1-N > as separate payloads (N payloads). If you want to support > packetization-modes 0 and 1 as well, you'll need 2*N payloads. >=20 > I wish I'd been looking at this before it was approved, though given > general offer-answer semantics it's not too surprising they chose this > way. >=20 > >> I think that's invalid for offer/answer, per 8.2.2. If the offerer > >> wants to support only level 1.0 (in this case, 42a00a), it *has* to > >> offer it as a separate payload type in the offer. The answer cannot > add > >> it as the same payload type, and you're not supposed to add media > >> formats (payloads) in an answer. > >> > >> > >> 8.2.2. Usage with the SDP Offer/Answer Model > >> > >> When H.264 is offered over RTP using SDP in an Offer/Answer model > [7] > >> for negotiation for unicast usage, the following limitations and > >> rules apply: > >> > >> o The parameters identifying a media format configuration for H.264 > >> are "profile-level-id", "packetization-mode", and, if required by > >> "packetization-mode", "sprop-deint-buf-req". These three > >> parameters MUST be used symmetrically; i.e., the answerer MUST > >> either maintain all configuration parameters or remove the media > >> format (payload type) completely, if one or more of the parameter > >> values are not supported. > >> > >> Informative note: The requirement for symmetric use applies > >> only for the above three parameters and not for the other > >> stream properties and capability parameters. > -- > 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://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Aug 16 03:12:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILZVS-0000sU-Fm; Thu, 16 Aug 2007 03:10:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILZVR-0000sP-22 for avt@ietf.org; Thu, 16 Aug 2007 03:10:57 -0400 Received: from [203.187.132.25] (helo=tapal.aricent.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILZVO-00050y-QB for avt@ietf.org; Thu, 16 Aug 2007 03:10:56 -0400 Received: from tapal.aricent.com (localhost [127.0.0.1]) by tapal.aricent.com (8.13.8/8.13.8) with ESMTP id l7G74uXL003488 for ; Thu, 16 Aug 2007 12:34:56 +0530 Received: from pragati.bgh.aricent.com (pragati.bgh.aricent.com [10.203.193.22])by tapal.aricent.com (8.13.8/8.13.8) with ESMTP id l7G74tG1003485for ; Thu, 16 Aug 2007 12:34:55 +0530 To: avt@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: ManojKumar.Soni@aricent.com Date: Thu, 16 Aug 2007 12:35:26 +0530 X-MIMETrack: Serialize by Router on Pragati/BLR/HSS(Release 6.5.5|November 30, 2005) at08/16/2007 12:34:08 PM,Serialize complete at 08/16/2007 12:34:08 PM X-imss-version: 2.047 X-imss-result: Passed X-imss-scanInfo: M:B L:N SM:2 X-imss-tmaseResult: TT:1 TS:-11.0618 TC:1F TRN:31 TV:3.6.1039(15362.002) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:2 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 2.9 (++) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Subject: [AVT] Regarding G726 SDP files X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1977231725==" Errors-To: avt-bounces@ietf.org This is a multipart message in MIME format. --===============1977231725== Content-Type: multipart/alternative; boundary="=_alternative 0027D34765257339_=" This is a multipart message in MIME format. --=_alternative 0027D34765257339_= Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: base64 SGksDQpJIG5lZWQgYSBmYXZvdXIgZnJvbSB1IGd1eXMuDQpDb3VsZCB5b3UgcGxlYXNlIGxldCBt ZSBrbm93IGZyb20gd2hlcmUgSSBjYW4gZ2V0IHNhbXBsZSBzZHAgZmlsZXMgZm9yIA0KRzcyNiBz cGVlY2ggY29kZWM/IA0KDQpUaGFua3MgaW4gQWR2YW5jZS4NClJlZ2FyZHMNCk1hbm9qDQoNCg0K DQoNCg0KDQoqKioqKioqKioqKioqKioqKioqKioqKiAgQXJpY2VudC1Qcml2YXRlICAgKioqKioq KioqKioqKioqKioqKioqKioNCiJESVNDTEFJTUVSOiBUaGlzIG1lc3NhZ2UgaXMgcHJvcHJpZXRh cnkgdG8gQXJpY2VudCBhbmQgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIAp0aGUg aW5kaXZpZHVhbCB0byB3aG9tIGl0IGlzIGFkZHJlc3NlZC4gSXQgbWF5IGNvbnRhaW4gcHJpdmls ZWdlZCBvciBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gYW5kIHNob3VsZCBub3QgYmUgCmNpcmN1 bGF0ZWQgb3IgdXNlZCBmb3IgYW55IHB1cnBvc2Ugb3RoZXIgdGhhbiBmb3Igd2hhdCBpdCBpcyBp bnRlbmRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtZXNzYWdlIGluIGVycm9yLCAKcGxl YXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBpbW1lZGlhdGVseS4gSWYgeW91IGFyZSBub3QgdGhl IGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBub3RpZmllZCB0aGF0IHlvdSBhcmUgc3RyaWN0 bHkKcHJvaGliaXRlZCBmcm9tIHVzaW5nLCBjb3B5aW5nLCBhbHRlcmluZywgb3IgZGlzY2xvc2lu ZyB0aGUgY29udGVudHMgb2YgdGhpcyBtZXNzYWdlLiBBcmljZW50IGFjY2VwdHMgbm8gcmVzcG9u c2liaWxpdHkgZm9yIApsb3NzIG9yIGRhbWFnZSBhcmlzaW5nIGZyb20gdGhlIHVzZSBvZiB0aGUg aW5mb3JtYXRpb24gdHJhbnNtaXR0ZWQgYnkgdGhpcyBlbWFpbCBpbmNsdWRpbmcgZGFtYWdlIGZy b20gdmlydXMuIgo= --=_alternative 0027D34765257339_= Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLDwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SSBuZWVkIGEgZmF2b3VyIGZyb20gdSBndXlzLjwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Q291bGQgeW91IHBsZWFz ZSBsZXQgbWUga25vdyBmcm9tIHdoZXJlDQpJIGNhbiBnZXQgc2FtcGxlIHNkcCBmaWxlcyBmb3Ig RzcyNiBzcGVlY2ggY29kZWM/IDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+VGhhbmtzIGluIEFkdmFuY2UuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj5SZWdhcmRzPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj5NYW5vajwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPGJyPg0KPGJyPg0KKioqKioqKioqKioqKioqKioq KioqKiogJm5ic3A7QXJpY2VudC1Qcml2YXRlICZuYnNwOyAqKioqKioqKioqKioqKioqKioqKioq KjwvZm9udD4NCjx0YWJsZT48dHI+PHRkIGJnY29sb3I9I2ZmZmZmZj48Zm9udCBjb2xvcj0jMDAw MDAwPjxwcmU+IkRJU0NMQUlNRVI6IFRoaXMgbWVzc2FnZSBpcyBwcm9wcmlldGFyeSB0byBBcmlj ZW50IGFuZCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgCnRoZSBpbmRpdmlkdWFs IHRvIHdob20gaXQgaXMgYWRkcmVzc2VkLiBJdCBtYXkgY29udGFpbiBwcml2aWxlZ2VkIG9yIGNv bmZpZGVudGlhbCBpbmZvcm1hdGlvbiBhbmQgc2hvdWxkIG5vdCBiZSAKY2lyY3VsYXRlZCBvciB1 c2VkIGZvciBhbnkgcHVycG9zZSBvdGhlciB0aGFuIGZvciB3aGF0IGl0IGlzIGludGVuZGVkLiBJ ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1lc3NhZ2UgaW4gZXJyb3IsIApwbGVhc2Ugbm90aWZ5 IHRoZSBvcmlnaW5hdG9yIGltbWVkaWF0ZWx5LiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQg cmVjaXBpZW50LCB5b3UgYXJlIG5vdGlmaWVkIHRoYXQgeW91IGFyZSBzdHJpY3RseQpwcm9oaWJp dGVkIGZyb20gdXNpbmcsIGNvcHlpbmcsIGFsdGVyaW5nLCBvciBkaXNjbG9zaW5nIHRoZSBjb250 ZW50cyBvZiB0aGlzIG1lc3NhZ2UuIEFyaWNlbnQgYWNjZXB0cyBubyByZXNwb25zaWJpbGl0eSBm b3IgCmxvc3Mgb3IgZGFtYWdlIGFyaXNpbmcgZnJvbSB0aGUgdXNlIG9mIHRoZSBpbmZvcm1hdGlv biB0cmFuc21pdHRlZCBieSB0aGlzIGVtYWlsIGluY2x1ZGluZyBkYW1hZ2UgZnJvbSB2aXJ1cy4i CjwvcHJlPjwvZm9udD48L3RkPjwvdHI+PC90YWJsZT4= --=_alternative 0027D34765257339_=-- --===============1977231725== 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://www1.ietf.org/mailman/listinfo/avt --===============1977231725==-- From avt-bounces@ietf.org Thu Aug 16 09:23:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILfI7-0007Ee-12; Thu, 16 Aug 2007 09:21:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILfI6-0007EZ-7o for avt@ietf.org; Thu, 16 Aug 2007 09:21:34 -0400 Received: from pr-66-150-46-254.wgate.com ([66.150.46.254] helo=exchange1.wgate.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILfI5-0006ca-14 for avt@ietf.org; Thu, 16 Aug 2007 09:21:34 -0400 Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Aug 2007 09:21:32 -0400 To: "Yuval Nissan" Subject: Re: [AVT] RFC 3984 offer/answer Question References: <79B4F738DDD4EF4F85A4641A0FE5EFD602CA8E22@aclmsg.corp.audiocodes.com> From: Randell Jesup Date: Thu, 16 Aug 2007 09:21:30 -0400 In-Reply-To: <79B4F738DDD4EF4F85A4641A0FE5EFD602CA8E22@aclmsg.corp.audiocodes.com> (Yuval Nissan's message of "Thu, 16 Aug 2007 10:01:57 +0300") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 16 Aug 2007 13:21:32.0525 (UTC) FILETIME=[5CD631D0:01C7E008] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: stewe@stewe.org, "Even, Roni" , Ilan Avner , avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randell Jesup List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org "Yuval Nissan" writes: >Regarding the communication symmetric - if we understand it the way >which you propose (which I think is the practical one): > >Offerer support up to level 3. >Offerer -> Answerer SDP message: > > m=video 49170 RTP/AVP 98 > a=rtpmap:98 H264/90000 > a=fmtp:98 profile-level-id=42A01E; packetization-mode=0; > >Answerer support level 1 only. >Answerer -> Offerer SDP message: > > m=video 49170 RTP/AVP 98 > a=rtpmap:98 H264/90000 > a=fmtp:98 profile-level-id=42A00A; packetization-mode=0; > >There can be 2 possibilities: > >1. The offerer must transmit in level 1.0. Still the answerer can >transmit up to level 3.0 if he wants. > >2. Both of them must use level 1. > >Which one is correct? Correct? Neither, I'm afraid. Given the RFC, if someone sends a response that doesn't comply with the RFC (i.e. a level 1.0 response to level 3.0 offer), there's no way to know how the offerer will deal with that response. They could: a) go asymmetric, and send 1.0 and receive any 1.0 -> 3.0 stream b) require symmetric, and send and receive 1.0 only c) Not understand the response and consider it in error, and either reINVITE (perhaps to 1.0, or to another codec, or even 3.0 again) or send a BYE. d) Not understand the response and send 3.0 anyways (since the payload value was accepted, and the RFC doesn't allow for changing the level of a payload). e) Process the response as a new, added payload (since it doesn't match on the triple of level, packetization, deint-buf) even though numerically it's the same. Given offer-answer semantics, this would mean the answer did not provide a payload that was offered, and while each side should continue to accept what they sent, the offerer should not send. This is probably the most canonically-correct way to handle the response per the RFCs (3984 and 3264). You don't know which of these they will do, especially if the implementation was developed in a closed system without direct interoperation tests (against systems that may not comply with the RFC and so force them to do something other than option e, or whatever possible mis-reading of the RFC they had). Now, Roni may be correct that some of the conferencing people have assumed that you don't have to match profile-level-id (which is incorrect per the RFC, but if they all test against each other may work in practice). If there is a big hole in the RFC that has caused everyone to make some non-compliant assumption (like option 'a' above), then it should be made into a new RFC (3984bis). They may find that the authors had a reason for not allowing it, or perhaps there's a better solution to their problem. So neither is 'correct'. One of those (or one of a-e) may be compatible with many or even most H.264+SIP+SDP devices -- but I doubt that either choice will avoid compatibility problems with all such devices. Unfortunately. -- 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://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Aug 16 09:58:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILfqU-00007P-Hv; Thu, 16 Aug 2007 09:57:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILfqT-00007J-OO for avt@ietf.org; Thu, 16 Aug 2007 09:57:05 -0400 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILfqR-0007NG-RR for avt@ietf.org; Thu, 16 Aug 2007 09:57:05 -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_01C7E00D.7DB7A08B" Subject: RE: [AVT] RFC 3984 offer/answer Question Date: Thu, 16 Aug 2007 16:58:17 +0300 Message-ID: <144ED8561CE90C41A3E5908EDECE315C04D44EBE@IsrExch01.israel.polycom.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] RFC 3984 offer/answer Question Thread-Index: AcfgCI2/U2VplQlnT1mjPhyVS6bzjAAAFFbg From: "Even, Roni" To: "Randell Jesup" , "Yuval Nissan" X-Spam-Score: 0.0 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b Cc: stewe@stewe.org, Ilan Avner , avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C7E00D.7DB7A08B Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Randell, I went back to the mailing list and found the attached email. It is in line with my thought that the level can be downgraded Roni > -----Original Message----- > From: Randell Jesup [mailto:rjesup@wgate.com] > Sent: Thursday, August 16, 2007 4:22 PM > To: Yuval Nissan > Cc: Even, Roni; ctrobianni@ecotronics.com; avt@ietf.org; stewe@stewe.org; > Ilan Avner > Subject: Re: [AVT] RFC 3984 offer/answer Question >=20 > "Yuval Nissan" writes: > >Regarding the communication symmetric - if we understand it the way > >which you propose (which I think is the practical one): > > > >Offerer support up to level 3. > >Offerer -> Answerer SDP message: > > > > m=3Dvideo 49170 RTP/AVP 98 > > a=3Drtpmap:98 H264/90000 > > a=3Dfmtp:98 profile-level-id=3D42A01E; packetization-mode=3D0; > > > >Answerer support level 1 only. > >Answerer -> Offerer SDP message: > > > > m=3Dvideo 49170 RTP/AVP 98 > > a=3Drtpmap:98 H264/90000 > > a=3Dfmtp:98 profile-level-id=3D42A00A; packetization-mode=3D0; > > > >There can be 2 possibilities: > > > >1. The offerer must transmit in level 1.0. Still the answerer can > >transmit up to level 3.0 if he wants. > > > >2. Both of them must use level 1. > > > >Which one is correct? >=20 > Correct? Neither, I'm afraid. >=20 > Given the RFC, if someone sends a response that doesn't comply with the > RFC (i.e. a level 1.0 response to level 3.0 offer), there's no way to know > how the offerer will deal with that response. >=20 > They could: > a) go asymmetric, and send 1.0 and receive any 1.0 -> 3.0 stream > b) require symmetric, and send and receive 1.0 only > c) Not understand the response and consider it in error, and either > reINVITE (perhaps to 1.0, or to another codec, or even 3.0 again) or > send a BYE. > d) Not understand the response and send 3.0 anyways (since the payload > value was accepted, and the RFC doesn't allow for changing the level of > a payload). > e) Process the response as a new, added payload (since it doesn't match > on the triple of level, packetization, deint-buf) even though > numerically it's the same. Given offer-answer semantics, this would > mean the answer did not provide a payload that was offered, and while > each side should continue to accept what they sent, the offerer > should not send. This is probably the most canonically-correct way to > handle the response per the RFCs (3984 and 3264). >=20 > You don't know which of these they will do, especially if the > implementation was developed in a closed system without direct > interoperation tests (against systems that may not comply with the RFC and > so force them to do something other than option e, or whatever possible > mis-reading of the RFC they had). >=20 > Now, Roni may be correct that some of the conferencing people have assumed > that you don't have to match profile-level-id (which is incorrect per the > RFC, but if they all test against each other may work in practice). If > there is a big hole in the RFC that has caused everyone to make some > non-compliant assumption (like option 'a' above), then it should be > made into a new RFC (3984bis). They may find that the authors had a > reason > for not allowing it, or perhaps there's a better solution to their > problem. >=20 > So neither is 'correct'. One of those (or one of a-e) may be compatible > with many or even most H.264+SIP+SDP devices -- but I doubt that either > choice will avoid compatibility problems with all such devices. > Unfortunately. >=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) ------_=_NextPart_001_01C7E00D.7DB7A08B Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from mailrelay.polycom.co.il ([212.179.41.34]) by isrexch01.israel.polycom.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Oct 2005 15:04:04 +0200 Received: from localhost.polycom.co.il (localhost.localdomain [127.0.0.1]) by mailrelay.polycom.co.il (8.12.11/8.12.11) with ESMTP id j9CCvF61018502 for ; Wed, 12 Oct 2005 14:57:16 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by mailrelay.polycom.co.il (Postfix) with ESMTP id 08E9015C002 for ; Wed, 12 Oct 2005 14:57:13 +0200 (IST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPgC8-0002cA-67; Wed, 12 Oct 2005 08:58:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPgC5-0002c1-Ou for avt@megatron.ietf.org; Wed, 12 Oct 2005 08:58:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19389 for ; Wed, 12 Oct 2005 08:58:51 -0400 (EDT) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPgMK-0001N8-3o for avt@ietf.org; Wed, 12 Oct 2005 09:09:33 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 13BBDD4D; Wed, 12 Oct 2005 14:58:45 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Oct 2005 14:58:06 +0200 Received: from [147.214.34.64] ([147.214.34.64]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Oct 2005 14:58:05 +0200 Content-class: urn:content-classes:message Subject: [AVT] Clarification on Offer Answer usage of H.264 payload format (RFC 3984) Date: Wed, 12 Oct 2005 15:58:05 +0300 Message-ID: <434D085D.6090606@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] Clarification on Offer Answer usage of H.264 payload format (RFC 3984) Thread-Index: AcXPLWxTcOpGVkhgTiq7posDzC9jHg== List-Help: List-Subscribe: , List-Unsubscribe: , From: "Magnus Westerlund" Sender: To: "IETF AVT WG" Cc: , "Stephan Wenger (Nokia)" , "Dave Singer" SGksDQoNCldlIGF1dGhvcnMgd2FzIG1hZGUgYXdhcmUgb2YgYW4gaXNzdWUgaW4gdGhlIE9mZmVy L0Fuc3dlciB1c2FnZSBmb3IgdGhlIA0KSC4yNjQgUlRQIHBheWxvYWQgZm9ybWF0IGJ5IFRhbmcg WW9uZ2xpYW5nLg0KDQpUaGUgaXNzdWUgaXMgdGhhdCBzZWN0aW9uIDguMi4yIHNheXM6DQoNCiAg ICBvICBUaGUgcGFyYW1ldGVycyBpZGVudGlmeWluZyBhIG1lZGlhIGZvcm1hdCBjb25maWd1cmF0 aW9uIGZvciBILjI2NA0KICAgICAgIGFyZSAicHJvZmlsZS1sZXZlbC1pZCIsICJwYWNrZXRpemF0 aW9uLW1vZGUiLCBhbmQsIGlmIHJlcXVpcmVkIGJ5DQogICAgICAgInBhY2tldGl6YXRpb24tbW9k ZSIsICJzcHJvcC1kZWludC1idWYtcmVxIi4gIFRoZXNlIHRocmVlDQogICAgICAgcGFyYW1ldGVy cyBNVVNUIGJlIHVzZWQgc3ltbWV0cmljYWxseTsgaS5lLiwgdGhlIGFuc3dlcmVyIE1VU1QNCiAg ICAgICBlaXRoZXIgbWFpbnRhaW4gYWxsIGNvbmZpZ3VyYXRpb24gcGFyYW1ldGVycyBvciByZW1v dmUgdGhlIG1lZGlhDQogICAgICAgZm9ybWF0IChwYXlsb2FkIHR5cGUpIGNvbXBsZXRlbHksIGlm IG9uZSBvciBtb3JlIG9mIHRoZSBwYXJhbWV0ZXINCiAgICAgICB2YWx1ZXMgYXJlIG5vdCBzdXBw b3J0ZWQuDQoNCkFuZCBsYXRlcg0KDQoiICBvICBQYXJhbWV0ZXJzIGRlY2xhcmluZyBhIGNvbmZp Z3VyYXRpb24gcG9pbnQgYXJlIG5vdCBkb3duZ3JhZGFibGUsDQogICAgICAgd2l0aCB0aGUgZXhj ZXB0aW9uIG9mIHRoZSBsZXZlbCBwYXJ0IG9mIHRoZSAicHJvZmlsZS1sZXZlbC1pZCINCiAgICAg ICBwYXJhbWV0ZXIuIg0KDQpUaGF0IGlzIGNvbnRyYWRpY3RpbmcgZm9yIHRoZSAicHJvZmlsZS1s ZXZlbC1pZCIgcGFyYW1ldGVyLiBUaGUgDQppbnRlbnRpb24gb2YgdGhlIGF1dGhvcnMgd2FzIHRo YXQgdGhlIHByb2ZpbGUgcGFydCAocHJvZmlsZV9pZGMgYW5kIA0KcHJvZmlsZV9pb3ApIHdvdWxk IGJlIGZpeGVkIGJ1dCB0aGUgbGV2ZWwgKGxldmVsX2lkYykgY2FuIGJlIGRvd25ncmFkZWQuIA0K VGhhdCB3YXkgeW91IGFzIGFuIHJlY2VpdmVyIHN0YXRlIHRoZSBwcm9maWxlcyBhbmQgaGlnaGVz dCBsZXZlbCBmb3IgDQp0aGF0IHByb2ZpbGUgeW91IGFyZSB3aWxsaW5nIHRvIGFjY2VwdC4gVGhl IGFuc3dlcmVyIGNhbiB0aGVuIHJlc3BvbmQgDQp3aXRoIHRoZSBzYW1lIHByb2ZpbGUgYnV0IHdp dGggYSBwb3NzaWJseSBsb3dlciBsZXZlbC4NCg0KU28gZm9yIGNsYXJpZmljYXRpb246IEFuIGFu c3dlcmVyIE1VU1Qgb25seSBtYWludGFpbiB0aGUgcHJvZmlsZV9pZGMgYW5kIA0KcHJvZmlsZV9p b3AgYnl0ZXMgb2YgdGhlIHByb2ZpbGUtbGV2ZWwtaWQgdmFsdWUgYW5kIE1BWSBkb3duZ3JhZGUg dGhlIA0KbGV2ZWwgcGFydC4NCg0KUGxlYXNlIG5vdGU6IFRoaXMgbWF5IHJlcXVpcmUgdGhlIG9m ZmVyaW5nIHBhcnR5IHRvIG1ha2UgYSBuZXcgb2ZmZXIgdG8gDQpwcm92aWRlIGl0cyAic3Byb3Ai IHBhcmFtZXRlcnMgY29ycmVjdGx5IGR1ZSB0byB0aGUgcmVkdWN0aW9uIGluIGxldmVsLg0KDQpI b3dldmVyIHdpdGhvdXQgdGhpcyBjbGFyaWZpY2F0aW9uIHRoZSBvbmx5IHdheSBvZiBnZXR0aW5n IGEgc3VjY2Vzc2Z1bCANCm9mZmVyL2Fuc3dlciBmb3IgSC4yNjQgd2hlbiBub3QgZnVsbHkgYXdh cmUgb2YgdGhlIGNvdW50ZXItcGFydHMgDQpjYXBhYmlsaXRpZXMgd291bGQgYmUgdG8gd3JpdGUg b25lIHBheWxvYWQgdHlwZSBmb3IgZWFjaCBwcm9maWxlLWxldmVsIA0KY29tYmluYXRpb24gdGhh dCBvbmUgY291bGQgZG93bmdyYWRlIHRvLg0KDQpBbnkgY29tbWVudHMgb24gdGhpcyBjbGFyaWZp Y2F0aW9uPw0KDQpDaGVlcnMNCg0KTWFnbnVzIFdlc3Rlcmx1bmQNCg0KTXVsdGltZWRpYSBUZWNo bm9sb2dpZXMsIEVyaWNzc29uIFJlc2VhcmNoIEVBQi9UVkEvQQ0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KRXJp Y3Nzb24gQUIgICAgICAgICAgICAgICAgfCBQaG9uZSArNDYgOCA0MDQ4Mjg3DQpUb3JzaGFtc2dh dGFuIDIzICAgICAgICAgICB8IEZheCAgICs0NiA4IDc1NzU1NTANClMtMTY0IDgwIFN0b2NraG9s bSwgU3dlZGVuIHwgbWFpbHRvOiBtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20NCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkF1ZGlvL1ZpZGVv IFRyYW5zcG9ydCBXb3JraW5nIEdyb3VwDQphdnRAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3MS5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2F2dA0K ------_=_NextPart_001_01C7E00D.7DB7A08B 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://www1.ietf.org/mailman/listinfo/avt ------_=_NextPart_001_01C7E00D.7DB7A08B-- From avt-bounces@ietf.org Thu Aug 16 10:11:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILg2H-0000Im-Tq; Thu, 16 Aug 2007 10:09:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILg2F-0000Id-Vm for avt@ietf.org; Thu, 16 Aug 2007 10:09:16 -0400 Received: from pr-66-150-46-254.wgate.com ([66.150.46.254] helo=exchange1.wgate.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILg2E-0008Ix-TF for avt@ietf.org; Thu, 16 Aug 2007 10:09:15 -0400 Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Aug 2007 10:09:14 -0400 To: "Even, Roni" Subject: Re: [AVT] RFC 3984 offer/answer Question References: <144ED8561CE90C41A3E5908EDECE315C04D44DAF@IsrExch01.israel.polycom.com> From: Randell Jesup Date: Thu, 16 Aug 2007 10:09:12 -0400 In-Reply-To: <144ED8561CE90C41A3E5908EDECE315C04D44DAF@IsrExch01.israel.polycom.com> (Roni Even's message of "Thu, 16 Aug 2007 09:35:47 +0300") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 16 Aug 2007 14:09:14.0431 (UTC) FILETIME=[06AA64F0:01C7E00F] X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: stewe@stewe.org, Yuval Nissan , avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randell Jesup List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org "Even, Roni" writes: >Randell, >I can see your point but I would like to see other opinions maybe from >the authors of the text. Absolutely. >My view is that most current implementation of offer / answer for >unicast has the same approach. (this is based on interoperability tests >between vendors of video conferencing systems) I suspect that all the implementations you've tested (conferencing systems) have tested against each other, and they've ended up (perhaps without even realizing it) at a non-compliant implementation. Or perhaps one or more realized the RFC meant the SDP processing would be a royal pain, and so decided to purposely implement something similar but not RFC compliant. >The problem here is that the profile-level-id parameter includes three >different parameters. >I still think that on the level part of the parameter the comparison >should be based on the highest common. I do not believe that the >intention here was to fix a specific mode. Perhaps it wasn't, but that is the result of the text (or more to the point, fix a 1<->1 relationship of payload value to level). You can support a lot of levels, but the RFC says you have to be able to distinguish them by payload value. It ends up wordy in the SDP (VERY wordy), but it would work. (It would make support for 3984 above a low level pretty much impossible on UDP SIP, for example, but it's not the only thing that can do this - see Magnus's 10K SDP example.) >Since the level parameter is an upper bound and lower levels are >included (except for level 1b) it does not make sense to offer a >separate media type for each level (there are 15 levels defined), for >example if the offerer support level 3 it will need to specify 3,2.2, >2.1, 2, 1.3, 1.2, 1.1 and 1 using 8 media type. Lower levels are included, but from the registration for profile-level-id in 8.1: 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. (that is declaritive SDP) and for negotiation: 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. The profile-iop byte indicates whether the codec has additional limitations whereby only the common subset of the algorithmic features and limitations of the profiles signaled with the profile-iop byte and of the profile indicated by profile_idc is supported by the codec. For example, if a codec supports only the common subset of the coding tools of the Baseline profile and the Main profile at level 2.1 and below, the profile-level-id becomes 42E015, in which 42 stands for the Baseline profile, E0 indicates that only the common subset for all profiles is supported, and 15 indicates level 2.1. Informative note: Capability exchange and session setup procedures should provide means to list the capabilities for each supported codec profile separately. For example, the one-of-N codec selection procedure of the SDP Offer/Answer model can be used (section 10.2 of [7]). 10.2 of RFC 3264 is the "offer inactive with many payloads, get inactive response, reINVITE active with a single payload, get active response". That (and the "list the capabilities for each supported codec profile separately") makes me think that this requirement to have N (or 2*N or in theory even more) payloads is intentional, not just poor wording. >I do not think that this was the intention in offer/answer. Offer/answer >should not be used to fix a specific level. See above; I'm not sure you're right here. I agree that (unless there's something I'm missing about why they did this) I'd really like to be able to have an asymmetric response, but there's no standard (see my options a-e in my response to Yuval). >To make it more complicated, by using the other optional parameters like >max-mbps, max-fs the meaning of the level according to table A.1 in >H.264 is changed and the current maximum values supported are based on >the sum of the values from table A.1 and the optional parameters. Right, though the offer-answer section says that those do not have to match in the offer and answer. >BTW: I do not think that having the same level in the offer and answer >will make the communication symmetric, the encoder on each side can send >any frame size at any macro blocks per second rate that falls within the >specified level (this means frame size and frame rate would not be the >same on each direction). You're correct it doesn't select actual frame size (in x, y) or frame rate. (within the limits of the level). However, the assumption of the writers *may* have been that agreeing on a level was important due to some algorithmic differences or resource-reservation issues - for example, an offerer who does a lot of streams might not want to have to reserve enough processing power, buffers, etc to decode level 3 if the answerer only supports level 1 - but if you let the answerer respond at level 1 to a level 3 offer, the offerer doesn't know if they'll receive level 1 or 3. (That's totally a guess and likely wrong, but it's an example of why they might have made the decision.) >If you want to have a specific picture size or frame rate (e.g. CIF at >30 fps) then you will need a different signaling for requesting specific >mode. I mentioned in Chicago that we are working in H.323 on such >extensions (requesting a specific mode (picture size and frame rate)) >and we will have a similar draft for SDP based systems. Which will be useful when it's available. Our device in reality only supports fixed resolutions. It can support others, but it has to scale them to fit on the display, so it's better to avoid that, and scaling isn't free (horsepower-wise, or artifact-wise). We may need a 3984-bis, or an explanation why all the conferencing people are doing it wrong or have mis-read the RFC (it's dense reading - witness this discussion. And some people read it and say "that's silly, they must have meant to do it this way..." since they don't know why the rfc reads the way it does - me included.) -- 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://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Aug 16 10:21:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILgCG-000858-LC; Thu, 16 Aug 2007 10:19:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILgCF-00084z-4Q for avt@ietf.org; Thu, 16 Aug 2007 10:19:35 -0400 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILgCD-0007wn-EG for avt@ietf.org; Thu, 16 Aug 2007 10:19:35 -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 Subject: RE: [AVT] RFC 3984 offer/answer Question Date: Thu, 16 Aug 2007 17:20:49 +0300 Message-ID: <144ED8561CE90C41A3E5908EDECE315C04D44ED3@IsrExch01.israel.polycom.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] RFC 3984 offer/answer Question Thread-Index: AcfgDzQK5kwpgBLSTXO1oiKFBkxR6wAAESMA From: "Even, Roni" To: "Randell Jesup" X-Spam-Score: 0.0 (/) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 Cc: stewe@stewe.org, Yuval Nissan , avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Randell The text in RFC 3984 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. Explains that you can downgrade the level parameter Roni !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! A consensus means that everyone agrees to say collectively what no one believes individually !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=20 > -----Original Message----- > From: Randell Jesup [mailto:rjesup@wgate.com] > Sent: Thursday, August 16, 2007 5:09 PM > To: Even, Roni > Cc: Yuval Nissan; ctrobianni@ecotronics.com; avt@ietf.org; stewe@stewe.org > Subject: Re: [AVT] RFC 3984 offer/answer Question >=20 > "Even, Roni" writes: > >Randell, > >I can see your point but I would like to see other opinions maybe from > >the authors of the text. >=20 > Absolutely. >=20 > >My view is that most current implementation of offer / answer for > >unicast has the same approach. (this is based on interoperability tests > >between vendors of video conferencing systems) >=20 > I suspect that all the implementations you've tested (conferencing > systems) > have tested against each other, and they've ended up (perhaps without even > realizing it) at a non-compliant implementation. Or perhaps one or more > realized the RFC meant the SDP processing would be a royal pain, and so > decided to purposely implement something similar but not RFC compliant. >=20 > >The problem here is that the profile-level-id parameter includes three > >different parameters. > >I still think that on the level part of the parameter the comparison > >should be based on the highest common. I do not believe that the > >intention here was to fix a specific mode. >=20 > Perhaps it wasn't, but that is the result of the text (or more to the > point, fix a 1<->1 relationship of payload value to level). You can > support a lot of levels, but the RFC says you have to be able to > distinguish them by payload value. It ends up wordy in the SDP (VERY > wordy), but it would work. (It would make support for 3984 above a low > level pretty much impossible on UDP SIP, for example, but it's not the > only > thing that can do this - see Magnus's 10K SDP example.) >=20 > >Since the level parameter is an upper bound and lower levels are > >included (except for level 1b) it does not make sense to offer a > >separate media type for each level (there are 15 levels defined), for > >example if the offerer support level 3 it will need to specify 3,2.2, > >2.1, 2, 1.3, 1.2, 1.1 and 1 using 8 media type. >=20 > Lower levels are included, but from the registration for profile-level-id > in 8.1: >=20 > 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. >=20 > (that is declaritive SDP) and for negotiation: >=20 > 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. The > profile-iop byte indicates whether the codec > has additional limitations whereby only the > common subset of the algorithmic features and > limitations of the profiles signaled with the > profile-iop byte and of the profile indicated > by profile_idc is supported by the codec. For > example, if a codec supports only the common > subset of the coding tools of the Baseline > profile and the Main profile at level 2.1 and > below, the profile-level-id becomes 42E015, in > which 42 stands for the Baseline profile, E0 > indicates that only the common subset for all > profiles is supported, and 15 indicates level > 2.1. >=20 > Informative note: Capability exchange and > session setup procedures should provide > means to list the capabilities for each > supported codec profile separately. For > example, the one-of-N codec selection > procedure of the SDP Offer/Answer model can > be used (section 10.2 of [7]). >=20 > 10.2 of RFC 3264 is the "offer inactive with many payloads, get inactive > response, reINVITE active with a single payload, get active response". >=20 > That (and the "list the capabilities for each supported codec profile > separately") makes me think that this requirement to have N (or 2*N or > in theory even more) payloads is intentional, not just poor wording. >=20 > >I do not think that this was the intention in offer/answer. Offer/answer > >should not be used to fix a specific level. >=20 > See above; I'm not sure you're right here. I agree that (unless there's > something I'm missing about why they did this) I'd really like to be > able to have an asymmetric response, but there's no standard (see my > options a-e in my response to Yuval). >=20 > >To make it more complicated, by using the other optional parameters like > >max-mbps, max-fs the meaning of the level according to table A.1 in > >H.264 is changed and the current maximum values supported are based on > >the sum of the values from table A.1 and the optional parameters. >=20 > Right, though the offer-answer section says that those do not have to > match in the offer and answer. >=20 > >BTW: I do not think that having the same level in the offer and answer > >will make the communication symmetric, the encoder on each side can send > >any frame size at any macro blocks per second rate that falls within the > >specified level (this means frame size and frame rate would not be the > >same on each direction). >=20 > You're correct it doesn't select actual frame size (in x, y) or frame > rate. > (within the limits of the level). However, the assumption of the writers > *may* have been that agreeing on a level was important due to some > algorithmic differences or resource-reservation issues - for example, an > offerer who does a lot of streams might not want to have to reserve enough > processing power, buffers, etc to decode level 3 if the answerer only > supports level 1 - but if you let the answerer respond at level 1 to a > level 3 offer, the offerer doesn't know if they'll receive level 1 or 3. > (That's totally a guess and likely wrong, but it's an example of why they > might have made the decision.) >=20 > >If you want to have a specific picture size or frame rate (e.g. CIF at > >30 fps) then you will need a different signaling for requesting specific > >mode. I mentioned in Chicago that we are working in H.323 on such > >extensions (requesting a specific mode (picture size and frame rate)) > >and we will have a similar draft for SDP based systems. >=20 > Which will be useful when it's available. Our device in reality only > supports fixed resolutions. It can support others, but it has to scale > them to fit on the display, so it's better to avoid that, and scaling > isn't > free (horsepower-wise, or artifact-wise). >=20 > We may need a 3984-bis, or an explanation why all the conferencing people > are doing it wrong or have mis-read the RFC (it's dense reading - witness > this discussion. And some people read it and say "that's silly, they must > have meant to do it this way..." since they don't know why the rfc reads > the way it does - me included.) >=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) _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Aug 16 10:22:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILgDm-0000Wb-UA; Thu, 16 Aug 2007 10:21:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILgDk-0000SZ-UI for avt@ietf.org; Thu, 16 Aug 2007 10:21:08 -0400 Received: from pr-66-150-46-254.wgate.com ([66.150.46.254] helo=exchange1.wgate.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILgDj-000805-Pp for avt@ietf.org; Thu, 16 Aug 2007 10:21:08 -0400 Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Aug 2007 10:21:07 -0400 To: "Even, Roni" Subject: Re: [AVT] RFC 3984 offer/answer Question References: <144ED8561CE90C41A3E5908EDECE315C04D44EBE@IsrExch01.israel.polycom.com> From: Randell Jesup Date: Thu, 16 Aug 2007 10:21:05 -0400 In-Reply-To: <144ED8561CE90C41A3E5908EDECE315C04D44EBE@IsrExch01.israel.polycom.com> (Roni Even's message of "Thu, 16 Aug 2007 16:58:17 +0300") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 16 Aug 2007 14:21:07.0556 (UTC) FILETIME=[AFB8A240:01C7E010] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: stewe@stewe.org, Yuval Nissan , Ilan Avner , avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randell Jesup List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org "Even, Roni" writes: >I went back to the mailing list and found the attached email. >It is in line with my thought that the level can be downgraded Darn! :-) I knew this whole conversation sounded familiar. I remember (now) seeing that, and in fact I've kept the article "ticked" in Gnus so it doesn't disappear on me. There really should be an rfc 3984bis (or at least an informational RFC; I don't know how this is supposed to work); everyone who comes to read it without searching the mail-archives will make the same set of mistakes and mis-readings. Magnus? Magnus wrote: >We authors was made aware of an issue in the Offer/Answer usage for the >H.264 RTP payload format by Tang Yongliang. > >The issue is that section 8.2.2 says: > > o The parameters identifying a media format configuration for H.264 > are "profile-level-id", "packetization-mode", and, if required by > "packetization-mode", "sprop-deint-buf-req". These three > parameters MUST be used symmetrically; i.e., the answerer MUST > either maintain all configuration parameters or remove the media > format (payload type) completely, if one or more of the parameter > values are not supported. > >And later > >" o Parameters declaring a configuration point are not downgradable, > with the exception of the level part of the "profile-level-id" > parameter." > >That is contradicting for the "profile-level-id" parameter. The >intention of the authors was that the profile part (profile_idc and >profile_iop) would be fixed but the level (level_idc) can be downgraded. >That way you as an receiver state the profiles and highest level for >that profile you are willing to accept. The answerer can then respond >with the same profile but with a possibly lower level. > >So for clarification: An answerer MUST only maintain the profile_idc and >profile_iop bytes of the profile-level-id value and MAY downgrade the >level part. > >Please note: This may require the offering party to make a new offer to >provide its "sprop" parameters correctly due to the reduction in level. > >However without this clarification the only way of getting a successful >offer/answer for H.264 when not fully aware of the counter-parts >capabilities would be to write one payload type for each profile-level >combination that one could downgrade to. -- 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://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Aug 16 11:45:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILhVp-0004sq-5i; Thu, 16 Aug 2007 11:43:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILhVo-0004sl-BP for avt@ietf.org; Thu, 16 Aug 2007 11:43:52 -0400 Received: from stewe.org ([85.214.23.117] helo=h665227.serverkompetenz.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILhVm-0002Bv-O8 for avt@ietf.org; Thu, 16 Aug 2007 11:43:52 -0400 Received: (qmail 4899 invoked by uid 60000); 16 Aug 2007 15:40:46 -0000 Received: from 75.60.27.134 by h665227 (envelope-from , uid 60004) with qmail-scanner-1.24st visas (spamassassin: 2.64. Clear:RC:0(75.60.27.134):SA:0(0.0/20.0):. Processed in 0.525949 secs); 16 Aug 2007 15:40:46 -0000 X-Spam-Status: No, hits=0.0 required=20.0 X-Envelope-From: stewe@stewe.org Received: from adsl-75-60-27-134.dsl.pltn13.sbcglobal.net (HELO ?192.168.1.102?) (stewe@stewe.org@75.60.27.134) by stewe.org with SMTP; 16 Aug 2007 15:40:46 -0000 In-Reply-To: References: <144ED8561CE90C41A3E5908EDECE315C04D44EBE@IsrExch01.israel.polycom.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Stephan Wenger Subject: Re: [AVT] RFC 3984 offer/answer Question Date: Thu, 16 Aug 2007 08:43:43 -0700 To: Randell Jesup X-Mailer: Apple Mail (2.752.3) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on h665227.serverkompetenz.net X-Spam-Level: X-Qmail-Scanner-MOVED-X-Spam-Status: No, hits=0.0 required=20.0 tests=none autolearn=no version=2.64 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: Yuval Nissan , "Even, Roni" , Ilan Avner , avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org 3984 bis is on our list for a while now. It has almost become a ritual between (at least) Magnus and me: a the end of an AVT session, we talk and say "we really should get started on 384 bis". Seriously, this is not the only known ambiguity in the spec. Somewhere, I even have a list of the others :-). I'll devote cycles once the ccm spec is out (hint hint). Stephan On Aug 16, 2007, at 7:21 AM, Randell Jesup wrote: > "Even, Roni" writes: >> I went back to the mailing list and found the attached email. >> It is in line with my thought that the level can be downgraded > > Darn! :-) I knew this whole conversation sounded familiar. I > remember > (now) seeing that, and in fact I've kept the article "ticked" in Gnus > so it doesn't disappear on me. > > There really should be an rfc 3984bis (or at least an informational > RFC; I > don't know how this is supposed to work); everyone who comes to > read it > without searching the mail-archives will make the same set of > mistakes and > mis-readings. > > Magnus? > > Magnus wrote: >> We authors was made aware of an issue in the Offer/Answer usage >> for the >> H.264 RTP payload format by Tang Yongliang. >> >> The issue is that section 8.2.2 says: >> >> o The parameters identifying a media format configuration for >> H.264 >> are "profile-level-id", "packetization-mode", and, if >> required by >> "packetization-mode", "sprop-deint-buf-req". These three >> parameters MUST be used symmetrically; i.e., the answerer MUST >> either maintain all configuration parameters or remove the >> media >> format (payload type) completely, if one or more of the >> parameter >> values are not supported. >> >> And later >> >> " o Parameters declaring a configuration point are not >> downgradable, >> with the exception of the level part of the "profile-level-id" >> parameter." >> >> That is contradicting for the "profile-level-id" parameter. The >> intention of the authors was that the profile part (profile_idc and >> profile_iop) would be fixed but the level (level_idc) can be >> downgraded. >> That way you as an receiver state the profiles and highest level for >> that profile you are willing to accept. The answerer can then respond >> with the same profile but with a possibly lower level. >> >> So for clarification: An answerer MUST only maintain the >> profile_idc and >> profile_iop bytes of the profile-level-id value and MAY downgrade the >> level part. >> >> Please note: This may require the offering party to make a new >> offer to >> provide its "sprop" parameters correctly due to the reduction in >> level. >> >> However without this clarification the only way of getting a >> successful >> offer/answer for H.264 when not fully aware of the counter-parts >> capabilities would be to write one payload type for each profile- >> level >> combination that one could downgrade to. > > -- > 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://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Aug 16 13:22:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILj1N-0002b3-0G; Thu, 16 Aug 2007 13:20:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILj1L-0002Ut-6M; Thu, 16 Aug 2007 13:20:31 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILj1K-0006Ty-V2; Thu, 16 Aug 2007 13:20:31 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 988FA175A5; Thu, 16 Aug 2007 17:20:00 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1ILj0q-0002b5-3Q; Thu, 16 Aug 2007 13:20:00 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Thu, 16 Aug 2007 13:20:00 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: avt@ietf.org Subject: [AVT] Last Call: draft-ietf-avt-profile-savpf (Extended Secure RTP Profile for RTCP-based Feedback (RTP/SAVPF)) to Proposed Standard X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf@ietf.org List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org The IESG has received a request from the Audio/Video Transport WG (avt) to consider the following document: - 'Extended Secure RTP Profile for RTCP-based Feedback (RTP/SAVPF) ' 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 2007-08-30. 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-profile-savpf-11.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=11002&rfc_flag=0 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Fri Aug 17 03:20:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILw6O-00020k-LY; Fri, 17 Aug 2007 03:18:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILw6N-00020f-ID for avt@ietf.org; Fri, 17 Aug 2007 03:18:35 -0400 Received: from co300216-co-outbound.net.avaya.com ([198.152.13.100] helo=co300216-co-outbound.avaya.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILw6N-0006LM-8D for avt@ietf.org; Fri, 17 Aug 2007 03:18:35 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-outbound.avaya.com with ESMTP; 17 Aug 2007 03:18:34 -0400 X-IronPort-AV: i="4.19,274,1183348800"; d="scan'208"; a="54334166:sNHT9042042" 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, 17 Aug 2007 09:17:56 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question about rtcp-xr-mib Thread-Index: AcfgOPElgT37HOdCQIyRhmML7FvmGgAZZwqA From: "Romascanu, Dan (Dan)" To: "AVT WG" X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: roberterayjr@gmail.com Subject: [AVT] FW: Question about rtcp-xr-mib X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org The AVT Working Group chairs and the editors of the document should be able to provide an answer to Bob's question.=20 Dan =20 -----Original Message----- From: Bob Ray [mailto:roberterayjr@gmail.com]=20 Sent: Thursday, August 16, 2007 10:09 PM To: Romascanu, Dan (Dan) Subject: Question about rtcp-xr-mib Hi. I've searched the mail archives and the rfc editor queue but I cannot find out the status of the draft RTCP-XR_MIB (in the AVT working group). Will it be advanced is it going to fade away? I ask because I am currently tasked with implementing it... (or something very much like it soon). Regards, Bob Ray _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Fri Aug 17 10:43:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM31L-0008Cz-MR; Fri, 17 Aug 2007 10:41:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM31K-0008Ch-CE for avt@ietf.org; Fri, 17 Aug 2007 10:41:50 -0400 Received: from smtpd4.aruba.it ([62.149.128.209] helo=smtp3.aruba.it) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IM31F-0005pL-JW for avt@ietf.org; Fri, 17 Aug 2007 10:41:50 -0400 Received: (qmail 2146 invoked by uid 89); 17 Aug 2007 14:41:33 -0000 Received: by simscan 1.1.0 ppid: 2134, pid: 2140, t: 0.4057s scanners: clamav: 0.88.4/m:40/d:1722 Received: from unknown (HELO bsoft007) (daniele@bsoft.info@151.71.184.243) by smtp3.aruba.it with SMTP; 17 Aug 2007 14:41:33 -0000 Message-ID: <009001c7e0dc$b114dd30$11010a0a@bsoft007> From: "daniele renzi \(bsoft\)" To: Date: Fri, 17 Aug 2007 16:41:26 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Rating: smtp3.aruba.it 1.6.2 0/1000/N X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Subject: [AVT] RTP streaming and adaptation to AVC of an SVC temporal scalable bitstream - Packet loss X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1341894534==" Errors-To: avt-bounces@ietf.org This is a multi-part message in MIME format. --===============1341894534== Content-Type: multipart/alternative; boundary="----=_NextPart_000_008D_01C7E0ED.7402CCC0" This is a multi-part message in MIME format. ------=_NextPart_000_008D_01C7E0ED.7402CCC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, I'd like to clarify the following scenario (the reference documents are = draft-ietf-avt-rtp-svc-02.txt and RFC-3984). We're implementing a system including: a) an SVC encoder + RTP streamer module (non-interleaved mode), b) an SVCtoAVC adapter, taking the RTP stream from the network, adapting = its SVC payload to AVC, streaming (RTP) the resulting AVC stream, c) an RTP receiver + AVC decoder. The SVC encoder implements just temporal scalability: it produces/sends = AVC-compliant NALUs and before any of them a prefix NALU to carry = scalability information. The different (temporal) layers are transported in a single RTP session. Let's suppose that the SVCtoAVC adapter has to forward just the base = layer by dropping the enhancement layers and the prefix NALUs and making = just some minor adaptation in the Sequence Parameter Set. Now the question: how can we handle a packet loss in the path between = the SVC encoder and the SVCtoAVC adapter, considering the single RTP = session? The problem is that the SVCtoAVC adapter is not able to know which layer = the lost packet belongs to; it can just detect a generic packet loss, = which could affect either the base layer or an enhancement layer, then = the SVCtoAVC adapter doesn't know whether this loss has to be signaled = to the receiver, i.e. whether it must insert a sequence number gap in = the outcoming RTP stream... If we used different RTP sessions the hardle would be cleared, as the = sequence number would be increased separately for any layer. Anyway, = we'd need to keep the single RTP session mode (if allowed, of course). Any suggestion would be very appreciated. Thanks in advance. Best regards, Daniele Renzi bSoft -- www.bsoft.info +39-0733-57707 (tel/fax) ------=_NextPart_000_008D_01C7E0ED.7402CCC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear=20 all,
 
I'd like to clarify the = following scenario=20 (the reference documents are draft-ietf-avt-rtp-svc-02.txt and = RFC-3984).
 
We're implementing a system=20 including:
a) an SVC encoder + RTP = streamer module=20 (non-interleaved mode),
b) an SVCtoAVC adapter, taking = the RTP=20 stream from the network, adapting its SVC payload to AVC, streaming = (RTP)=20 the resulting AVC stream,
c) an RTP receiver + AVC=20 decoder.
 
The SVC encoder implements just = temporal=20 scalability: it produces/sends AVC-compliant NALUs and before any = of them a=20 prefix NALU to carry scalability information.
The different (temporal) layers = are=20 transported in a single RTP session.
 
Let's suppose that the SVCtoAVC = adapter has=20 to forward just the base layer by dropping the enhancement layers = and the=20 prefix NALUs and making just some minor adaptation in the Sequence = Parameter=20 Set.
 
Now the question: how can = we handle a=20 packet loss in the path between the SVC encoder and the SVCtoAVC = adapter,=20 considering the single RTP session?
The problem is that the = SVCtoAVC adapter=20 is not able to know which layer the lost packet belongs to; it can = just=20 detect a generic packet loss, which could affect either the base layer = or an=20 enhancement layer, then the SVCtoAVC adapter doesn't know whether = this loss=20 has to be signaled to the receiver, i.e. whether it must = insert a=20 sequence number gap in the outcoming RTP stream...
 
If we used different RTP = sessions the=20 hardle would be cleared, as the sequence number would be increased=20 separately for any layer. Anyway, we'd need to keep the single RTP = session mode=20 (if allowed, of course).
 
Any suggestion would be very=20 appreciated.
 
Thanks in advance.
 
Best regards,
 
 
Daniele Renzi
bSoft -- = www.bsoft.info
+39-0733-57707  (tel/fax)
------=_NextPart_000_008D_01C7E0ED.7402CCC0-- --===============1341894534== 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://www1.ietf.org/mailman/listinfo/avt --===============1341894534==-- From avt-bounces@ietf.org Fri Aug 17 17:00:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM8tg-0000Gv-EM; Fri, 17 Aug 2007 16:58:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM8te-0000DI-CF for avt@ietf.org; Fri, 17 Aug 2007 16:58:18 -0400 Received: from gwa2.webcontrolcenter.com ([63.134.207.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IM8tc-0001k7-Ee for avt@ietf.org; Fri, 17 Aug 2007 16:58:18 -0400 Received: from maila14.webcontrolcenter.com (unverified [216.119.106.130]) by gwa2.webcontrolcenter.com (SurgeMail 3.8i3) with ESMTP id 25440003-1777422 for ; Fri, 17 Aug 2007 14:03:57 -0700 Received: from [72.71.251.41] by maila14.webcontrolcenter.com via HTTP; Fri, 17 Aug 2007 13:58:12 -0700 MIME-Version: 1.0 Date: Fri, 17 Aug 2007 13:58:12 -0700 From: "Cesar Trobianni" To: CC: Message-ID: <27dd78ee4c104edc9d85393e189485b5@maila14.webcontrolcenter.com> X-Spam-Score: -1.0 (-) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Subject: [AVT] RFC3016 packetization question X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ctrobianni@ecotronics.com List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1735560386==" Errors-To: avt-bounces@ietf.org This is a multi-part message in MIME format. --===============1735560386== Content-Type: multipart/alternative; boundary=----_SmarterMail_NextPart_0652842783774384 This is a multi-part message in MIME format. ------_SmarterMail_NextPart_0652842783774384 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable All,=0D=0A=0D=0AI don't have very clear how to behave in this case. If I ha= ve a very big MPEG4 VOP (bigger than the MTU), do I =0D=0A=0D=0A1. Put it i= n a single RTP (marker =3D=3D true)=0D=0A2. Put it in multiple RTPs using R= FC2190/RFC2429 (short header mode)?=0D=0A=0D=0AThank you=0D=0A=0D=0A-------= ---------------------------------=0D=0AFrom: Stephan Wenger =0D=0ASent: Thursday, August 16, 2007 11:44 AM=0D=0ATo: Randell Jesup =0D=0ASubject: Re: [AVT] RFC 3984 offer/answer Question =0D= =0A=0D=0A3984 bis is on our list for a while now. It has almost become a = =0D=0Aritual between (at least) Magnus and me: a the end of an AVT session,= =0D=0Awe talk and say "we really should get started on 384 bis".=0D=0ASer= iously, this is not the only known ambiguity in the spec. =0D=0ASomewhere= , I even have a list of the others :-). I'll devote cycles =0D=0Aonce the= ccm spec is out (hint hint).=0D=0AStephan=0D=0A=0D=0AOn Aug 16, 2007, at 7= :21 AM, Randell Jesup wrote:=0D=0A=0D=0A> "Even, Roni" writes:=0D=0A>> I w= ent back to the mailing list and found the attached email.=0D=0A>> It is in= line with my thought that the level can be downgraded=0D=0A>=0D=0A> Darn! = :-) I knew this whole conversation sounded familiar. I =0D=0A> remember= =0D=0A> (now) seeing that, and in fact I've kept the article "ticked" in Gn= us=0D=0A> so it doesn't disappear on me.=0D=0A>=0D=0A> There really should = be an rfc 3984bis (or at least an informational =0D=0A> RFC; I=0D=0A> don'= t know how this is supposed to work); everyone who comes to =0D=0A> read i= t=0D=0A> without searching the mail-archives will make the same set of =0D= =0A> mistakes and=0D=0A> mis-readings.=0D=0A>=0D=0A> Magnus?=0D=0A>=0D=0A> = Magnus wrote:=0D=0A>> We authors was made aware of an issue in the Offer/An= swer usage =0D=0A>> for the=0D=0A>> H.264 RTP payload format by Tang Yongl= iang.=0D=0A>>=0D=0A>> The issue is that section 8.2.2 says:=0D=0A>>=0D=0A>>= o The parameters identifying a media format configuration for =0D=0A>= > H.264=0D=0A>> are "profile-level-id", "packetization-mode", and, if= =0D=0A>> required by=0D=0A>> "packetization-mode", "sprop-deint-buf= -req". These three=0D=0A>> parameters MUST be used symmetrically; i.= e., the answerer MUST=0D=0A>> either maintain all configuration param= eters or remove the =0D=0A>> media=0D=0A>> format (payload type) com= pletely, if one or more of the =0D=0A>> parameter=0D=0A>> values are= not supported.=0D=0A>>=0D=0A>> And later=0D=0A>>=0D=0A>> " o Parameters = declaring a configuration point are not =0D=0A>> downgradable,=0D=0A>> = with the exception of the level part of the "profile-level-id"=0D=0A>> = parameter."=0D=0A>>=0D=0A>> That is contradicting for the "profile-lev= el-id" parameter. The=0D=0A>> intention of the authors was that the profile= part (profile_idc and=0D=0A>> profile_iop) would be fixed but the level (l= evel_idc) can be =0D=0A>> downgraded.=0D=0A>> That way you as an receiver = state the profiles and highest level for=0D=0A>> that profile you are willi= ng to accept. The answerer can then respond=0D=0A>> with the same profile b= ut with a possibly lower level.=0D=0A>>=0D=0A>> So for clarification: An an= swerer MUST only maintain the =0D=0A>> profile_idc and=0D=0A>> profile_iop= bytes of the profile-level-id value and MAY downgrade the=0D=0A>> level pa= rt.=0D=0A>>=0D=0A>> Please note: This may require the offering party to mak= e a new =0D=0A>> offer to=0D=0A>> provide its "sprop" parameters correctly= due to the reduction in =0D=0A>> level.=0D=0A>>=0D=0A>> However without t= his clarification the only way of getting a =0D=0A>> successful=0D=0A>> of= fer/answer for H.264 when not fully aware of the counter-parts=0D=0A>> capa= bilities would be to write one payload type for each profile- =0D=0A>> leve= l=0D=0A>> combination that one could downgrade to.=0D=0A>=0D=0A> -- =0D=0A>= Randell Jesup, Worldgate (developers of the Ojo videophone), ex- =0D=0A> A= miga OS team=0D=0A> rjesup@wgate.com=0D=0A> "The fetters imposed on liberty= at home have ever been forged out =0D=0A> of the weapons=0D=0A> provided = for defence against real, pretended, or imaginary dangers =0D=0A> from abr= oad."=0D=0A> - James Madison, 4th US president (1751-1836)=0D=0A>=0D=0A>= =0D=0A> _______________________________________________=0D=0A> Audio/Video = Transport Working Group=0D=0A> avt@ietf.org=0D=0A> https://www1.ietf.org/ma= ilman/listinfo/avt=0D=0A=0D=0A_____________________________________________= __=0D=0AAudio/Video Transport Working Group=0D=0Aavt@ietf.org=0D=0Ahttps://= www1.ietf.org/mailman/listinfo/avt=0D=0A=0D=0A ------_SmarterMail_NextPart_0652842783774384 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable All,

I don't have very clear how to behave in this case. If I have a= very big MPEG4 VOP (bigger than the MTU), do I

1. Put it in a sing= le RTP (marker =3D=3D true)
2. Put it in multiple RTPs using RFC2190/RFC= 2429 (short header mode)?

Thank you

<= strong>From: Stephan Wenger <stewe@stewe.org>
Sen= t: Thursday, August 16, 2007 11:44 AM
To: Rand= ell Jesup <rjesup@wgate.com>
Subject: Re: [AVT] R= FC 3984 offer/answer Question

3984 bis is on our list for a w= hile now. It has almost become a
ritual between (at least) Magnus and= me: a the end of an AVT session,
we talk and say "we really should ge= t started on 384 bis".
Seriously, this is not the only known ambiguity i= n the spec.
Somewhere, I even have a list of the others :-). I'll de= vote cycles
once the ccm spec is out (hint hint).
Stephan

On Aug 16, 2007, at 7:21 AM, Randell Jesup wrote:

> "Even, Roni= " writes:
>> I went back to the mailing = list and found the attached email.
>> It is in line with my though= t that the level can be downgraded
>
> Darn! :-) I knew this w= hole conversation sounded familiar. I
> remember
> (now) see= ing that, and in fact I've kept the article "ticked" in Gnus
> so it = doesn't disappear on me.
>
> There really should be an rfc 3984= bis (or at least an informational
> RFC; I
> don't know how t= his is supposed to work); everyone who comes to
> read it
> w= ithout searching the mail-archives will make the same set of
> mist= akes and
> mis-readings.
>
> Magnus?
>
> Magn= us wrote:
>> We authors was made aware of an issue in the Offer/An= swer usage
>> for the
>> H.264 RTP payload format by Ta= ng Yongliang.
>>
>> The issue is that section 8.2.2 says:=
>>
>> o The parameters identifying a media format co= nfiguration for
>> H.264
>> are "profile-level-id= ", "packetization-mode", and, if
>> required by
>> = "packetization-mode", "sprop-deint-buf-req". These three
>> = parameters MUST be used symmetrically; i.e., the answerer MUST
>&g= t; either maintain all configuration parameters or remove the
&g= t;> media
>> format (payload type) completely, if one or = more of the
>> parameter
>> values are not suppor= ted.
>>
>> And later
>>
>> " o Parame= ters declaring a configuration point are not
>> downgradable,>> with the exception of the level part of the "profile-level-= id"
>> parameter."
>>
>> That is contradic= ting for the "profile-level-id" parameter. The
>> intention of the= authors was that the profile part (profile_idc and
>> profile_iop= ) would be fixed but the level (level_idc) can be
>> downgraded.=
>> That way you as an receiver state the profiles and highest lev= el for
>> that profile you are willing to accept. The answerer can= then respond
>> with the same profile but with a possibly lower l= evel.
>>
>> So for clarification: An answerer MUST only m= aintain the
>> profile_idc and
>> profile_iop bytes of = the profile-level-id value and MAY downgrade the
>> level part.>>
>> Please note: This may require the offering party to m= ake a new
>> offer to
>> provide its "sprop" parameters= correctly due to the reduction in
>> level.
>>
>= > However without this clarification the only way of getting a
>= > successful
>> offer/answer for H.264 when not fully aware of = the counter-parts
>> capabilities would be to write one payload ty= pe for each profile-
>> level
>> combination that one co= uld downgrade to.
>
> --
> Randell Jesup, Worldgate (dev= elopers of the Ojo videophone), ex-
> Amiga OS team
> rjesup@w= gate.com
> "The fetters imposed on liberty at home have ever been for= ged 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 Gr= oup
> avt@ietf.org
> https://www1.ietf.org/mailman/listinfo/avt=


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

 ------_SmarterMail_NextPart_0652842783774384-- --===============1735560386== 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://www1.ietf.org/mailman/listinfo/avt --===============1735560386==-- From avt-bounces@ietf.org Sat Aug 18 07:34:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMMXW-0003gW-Pa; Sat, 18 Aug 2007 07:32:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMMXS-0003ft-IY for avt@ietf.org; Sat, 18 Aug 2007 07:32:18 -0400 Received: from mail.hhi.fraunhofer.de ([193.174.67.45]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IMMXR-00077p-Gs for avt@ietf.org; Sat, 18 Aug 2007 07:32:18 -0400 Received: by mail.hhi.fraunhofer.de (Postfix, from userid 65534) id 308A11D88F79; Sat, 18 Aug 2007 13:32:08 +0200 (CEST) Received: from ipam040160 (unknown [85.183.158.206]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.hhi.fraunhofer.de (Postfix) with ESMTP id AAD521D88F46; Sat, 18 Aug 2007 13:32:04 +0200 (CEST) From: "Thomas Schierl" To: "'daniele renzi (bsoft)'" , References: <009001c7e0dc$b114dd30$11010a0a@bsoft007> In-Reply-To: <009001c7e0dc$b114dd30$11010a0a@bsoft007> Subject: RE: [AVT] RTP streaming and adaptation to AVC of an SVC temporalscalable bitstream - Packet loss Date: Sat, 18 Aug 2007 13:32:02 +0200 Message-ID: <014301c7e18b$67187bb0$35497310$@fhg.de> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acfg3OFC4u3Xasl2QIuLS5BsHvm+YgArjpDA Content-Language: de X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on mail.hhi.fraunhofer.de X-Spam-Level: X-Spam-Status: No, hits=-102.6 required=5.0 tests=AWL,BAYES_00,HTML_50_60, HTML_MESSAGE,SUBJ_HAS_SPACES,USER_IN_WHITELIST autolearn=no version=2.64 X-alterMIME: Yes X-Spam-Score: 0.0 (/) X-Scan-Signature: 426dd6ea860196690cb99367d860d19e Cc: X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2071597121==" Errors-To: avt-bounces@ietf.org Dies ist eine mehrteilige Nachricht im MIME-Format. --===============2071597121== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0144_01C7E19C.2AA14BB0" Content-Language: de Dies ist eine mehrteilige Nachricht im MIME-Format. ------=_NextPart_000_0144_01C7E19C.2AA14BB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear Daniele, Beside session multiplexing, you may use TL0PICIDX of the PACSI NAL unit for loss detection assuming that your base layer represents Temporal Level "0". Thomas From: daniele renzi (bsoft) [mailto:daniele@bsoft.info] Sent: Friday, August 17, 2007 4:41 PM To: avt@ietf.org Subject: [AVT] RTP streaming and adaptation to AVC of an SVC temporalscalable bitstream - Packet loss Dear all, I'd like to clarify the following scenario (the reference documents are draft-ietf-avt-rtp-svc-02.txt and RFC-3984). We're implementing a system including: a) an SVC encoder + RTP streamer module (non-interleaved mode), b) an SVCtoAVC adapter, taking the RTP stream from the network, adapting its SVC payload to AVC, streaming (RTP) the resulting AVC stream, c) an RTP receiver + AVC decoder. The SVC encoder implements just temporal scalability: it produces/sends AVC-compliant NALUs and before any of them a prefix NALU to carry scalability information. The different (temporal) layers are transported in a single RTP session. Let's suppose that the SVCtoAVC adapter has to forward just the base layer by dropping the enhancement layers and the prefix NALUs and making just some minor adaptation in the Sequence Parameter Set. Now the question: how can we handle a packet loss in the path between the SVC encoder and the SVCtoAVC adapter, considering the single RTP session? The problem is that the SVCtoAVC adapter is not able to know which layer the lost packet belongs to; it can just detect a generic packet loss, which could affect either the base layer or an enhancement layer, then the SVCtoAVC adapter doesn't know whether this loss has to be signaled to the receiver, i.e. whether it must insert a sequence number gap in the outcoming RTP stream... If we used different RTP sessions the hardle would be cleared, as the sequence number would be increased separately for any layer. Anyway, we'd need to keep the single RTP session mode (if allowed, of course). Any suggestion would be very appreciated. Thanks in advance. Best regards, Daniele Renzi bSoft -- www.bsoft.info +39-0733-57707 (tel/fax) ---- Visit us at IFA 2007 / Berlin, 31 August - 5 September 2007 / Hall 5.3 Booth 17 http://www.hhi.fraunhofer.de/german/gf/events/index.html IBC 2007 / Amsterdam, 7 - 11 September 2007 / Booth 8.381 http://ip.hhi.de/ibc2007.html eslw 2007 / Berlin, 14 - 15 September 2007 / Fraunhofer Institute for Telecommunications, Heinrich-Hertz-Institut http://eslw2007.hhi.de/index.htm ECOC 2007 / Berlin, Exhibition 17 - 19 September 2007 / Booth 13007 - 13008 http://www.hhi.fraunhofer.de/german/gf/events/index.html ------=_NextPart_000_0144_01C7E19C.2AA14BB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Daniele,

 

Beside session multiplexing, you may use TL0PICIDX of the = PACSI NAL unit for loss detection assuming that your base layer represents = Temporal Level “0”.

 

Thomas

 

 

From:= daniele = renzi (bsoft) [mailto:daniele@bsoft.info]
Sent: Friday, August 17, 2007 4:41 PM
To: avt@ietf.org
Subject: [AVT] RTP streaming and adaptation to AVC of an SVC temporalscalable bitstream - Packet loss

 

Dear all,

 

I'd like to clarify the following scenario (the reference documents are draft-ietf-avt-rtp-svc-02.txt and RFC-3984).

 

We're implementing a system including:

a) an SVC encoder + RTP streamer module (non-interleaved = mode),

b) an SVCtoAVC adapter, taking the RTP stream from the network, adapting = its SVC payload to AVC, streaming (RTP) the resulting AVC = stream,

c) an RTP receiver + AVC decoder.

 

The SVC encoder implements just temporal scalability: it produces/sends AVC-compliant NALUs and before any of them a prefix = NALU to carry scalability information.

The different (temporal) layers are transported in a single RTP = session.

 

Let's suppose that the SVCtoAVC adapter has to forward just the base = layer by dropping the enhancement layers and the prefix NALUs and making just = some minor adaptation in the Sequence Parameter Set.

 

Now the question: how can we handle a packet loss in the path between = the SVC encoder and the SVCtoAVC adapter, considering the single RTP = session?

The problem is that the SVCtoAVC adapter is not able to know which = layer the lost packet belongs to; it can just detect a generic packet loss, which = could affect either the base layer or an enhancement layer, then the SVCtoAVC = adapter doesn't know whether this loss has to be signaled to the receiver, i.e. whether it must insert a sequence number gap in the = outcoming RTP stream...

 

If we used different RTP sessions the hardle would be cleared, as the sequence number would be increased separately for any layer. = Anyway, we'd need to keep the single RTP session mode (if allowed, of = course).

 

Any suggestion would be very appreciated.

 

Thanks in advance.

 

Best regards,

 

 

Daniele Renzi
bSoft -- www.bsoft.info
+39-0733-57707  (tel/fax)



----
Visit us at

IFA 2007 / Berlin, 31 August - 5 September 2007 / Hall 5.3 Booth 17
http://www.hhi.fraunhofer.de/german/gf/events/index.html

IBC 2007 / Amsterdam, 7 - 11 September 2007 / Booth 8.381
http://ip.hhi.de/ibc2007.html

eslw 2007 / Berlin, 14 - 15 September 2007 / Fraunhofer Institute for Telecommunications, Heinrich-Hertz-Institut
http://eslw2007.hhi.de/index.htm

ECOC 2007 / Berlin, Exhibition 17 - 19 September 2007 / Booth 13007 - 13008
http://www.hhi.fraunhofer.de/german/gf/events/index.html


------=_NextPart_000_0144_01C7E19C.2AA14BB0-- --===============2071597121== 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://www1.ietf.org/mailman/listinfo/avt --===============2071597121==-- From avt-bounces@ietf.org Sat Aug 18 13:38:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMSDi-0001N1-QY; Sat, 18 Aug 2007 13:36:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMSDh-0001Mw-Ir for avt@ietf.org; Sat, 18 Aug 2007 13:36:17 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IMSDf-0004NJ-SV for avt@ietf.org; Sat, 18 Aug 2007 13:36:17 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7IHa5PF003526; Sat, 18 Aug 2007 20:36:10 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 18 Aug 2007 20:36:04 +0300 Received: from trebe101.NOE.Nokia.com ([172.22.124.61]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 18 Aug 2007 20:36:04 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [AVT] RTP streaming and adaptation to AVC of an SVC temporalscalable bitstream - Packet loss Date: Sat, 18 Aug 2007 20:36:01 +0300 Message-ID: <1C1F3D15859526459B4DD0A7A9B2268B03BE988B@trebe101.NOE.Nokia.com> In-Reply-To: <009001c7e0dc$b114dd30$11010a0a@bsoft007> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] RTP streaming and adaptation to AVC of an SVC temporalscalable bitstream - Packet loss Thread-Index: Acfg3ODPj7tuRTpZSsyg9BvDryGaHgAMTy4A References: <009001c7e0dc$b114dd30$11010a0a@bsoft007> From: To: , X-OriginalArrivalTime: 18 Aug 2007 17:36:04.0462 (UTC) FILETIME=[407258E0:01C7E1BE] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Cc: X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1671049208==" Errors-To: avt-bounces@ietf.org This is a multi-part message in MIME format. --===============1671049208== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7E1BE.3F71549D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7E1BE.3F71549D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Daniele, =20 In your example the SVCtoAVC adapter is an RTP mixer, which terminates the RTP session between the sender and itself and restarts another RTP session between itself and the receiver. Therefore the RTP sequence number needs to be updated for the base layer packets anyway.=20 =20 BR, YK ________________________________ From: ext daniele renzi (bsoft) [mailto:daniele@bsoft.info]=20 Sent: Friday, August 17, 2007 5:41 PM To: avt@ietf.org Subject: [AVT] RTP streaming and adaptation to AVC of an SVC temporalscalable bitstream - Packet loss =09 =09 Dear all, =20 I'd like to clarify the following scenario (the reference documents are draft-ietf-avt-rtp-svc-02.txt and RFC-3984). =20 We're implementing a system including: a) an SVC encoder + RTP streamer module (non-interleaved mode), b) an SVCtoAVC adapter, taking the RTP stream from the network, adapting its SVC payload to AVC, streaming (RTP) the resulting AVC stream, c) an RTP receiver + AVC decoder. =20 The SVC encoder implements just temporal scalability: it produces/sends AVC-compliant NALUs and before any of them a prefix NALU to carry scalability information. The different (temporal) layers are transported in a single RTP session. =20 Let's suppose that the SVCtoAVC adapter has to forward just the base layer by dropping the enhancement layers and the prefix NALUs and making just some minor adaptation in the Sequence Parameter Set. =20 Now the question: how can we handle a packet loss in the path between the SVC encoder and the SVCtoAVC adapter, considering the single RTP session? The problem is that the SVCtoAVC adapter is not able to know which layer the lost packet belongs to; it can just detect a generic packet loss, which could affect either the base layer or an enhancement layer, then the SVCtoAVC adapter doesn't know whether this loss has to be signaled to the receiver, i.e. whether it must insert a sequence number gap in the outcoming RTP stream... =20 If we used different RTP sessions the hardle would be cleared, as the sequence number would be increased separately for any layer. Anyway, we'd need to keep the single RTP session mode (if allowed, of course). =20 Any suggestion would be very appreciated. =20 Thanks in advance. =20 Best regards, =20 =20 Daniele Renzi bSoft -- www.bsoft.info =20 +39-0733-57707 (tel/fax) ------_=_NextPart_001_01C7E1BE.3F71549D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Daniele,
 
In your example the SVCtoAVC adapter is an RTP = mixer, which=20 terminates the RTP session between the sender and itself and restarts = another=20 RTP session between itself and the receiver. Therefore the RTP sequence = number=20 needs to be updated for the base layer packets anyway. =
 
BR, YK

From: ext daniele renzi (bsoft)=20 [mailto:daniele@bsoft.info]
Sent: Friday, August 17, 2007 = 5:41=20 PM
To: avt@ietf.org
Subject: [AVT] RTP streaming = and=20 adaptation to AVC of an SVC temporalscalable bitstream - Packet=20 loss

Dear all,
 
I'd like to clarify the = following=20 scenario (the reference documents are=20 draft-ietf-avt-rtp-svc-02.txt and RFC-3984).
 
We're implementing a system=20 including:
a) an SVC encoder + RTP = streamer module=20 (non-interleaved mode),
b) an SVCtoAVC adapter, = taking the RTP=20 stream from the network, adapting its SVC payload to AVC, = streaming (RTP)=20 the resulting AVC stream,
c) an RTP receiver + AVC=20 decoder.
 
The SVC encoder implements = just temporal=20 scalability: it produces/sends AVC-compliant NALUs and before any = of them=20 a prefix NALU to carry scalability information.
The different (temporal) = layers are=20 transported in a single RTP session.
 
Let's suppose that the = SVCtoAVC adapter=20 has to forward just the base layer by dropping the enhancement = layers and=20 the prefix NALUs and making just some minor adaptation in the Sequence = Parameter Set.
 
Now the question: how can = we handle=20 a packet loss in the path between the SVC encoder and the SVCtoAVC = adapter,=20 considering the single RTP session?
The problem is that the = SVCtoAVC adapter=20 is not able to know which layer the lost packet belongs to; it = can just=20 detect a generic packet loss, which could affect either the base layer = or an=20 enhancement layer, then the SVCtoAVC adapter doesn't know whether = this=20 loss has to be signaled to the receiver, i.e. whether = it must insert=20 a sequence number gap in the outcoming RTP stream...
 
If we used different RTP = sessions=20 the hardle would be cleared, as the sequence number would = be increased=20 separately for any layer. Anyway, we'd need to keep the single RTP = session=20 mode (if allowed, of course).
 
Any suggestion would be very=20 appreciated.
 
Thanks in = advance.
 
Best regards,
 
 
Daniele Renzi
bSoft -- = www.bsoft.info
+39-0733-57707  = (tel/fax)
------_=_NextPart_001_01C7E1BE.3F71549D-- --===============1671049208== 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://www1.ietf.org/mailman/listinfo/avt --===============1671049208==-- From avt-bounces@ietf.org Sat Aug 18 14:08:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMSh8-0007FY-3Q; Sat, 18 Aug 2007 14:06:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMSh6-0007FS-LD for avt@ietf.org; Sat, 18 Aug 2007 14:06:40 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IMSh6-0002a5-8H for avt@ietf.org; Sat, 18 Aug 2007 14:06:40 -0400 Received: from csperkins-dsl.demon.co.uk ([62.49.4.249]:61515 helo=[192.168.0.4]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1IMSgz-0003Mk-ND; Sat, 18 Aug 2007 19:06:33 +0100 In-Reply-To: <1C1F3D15859526459B4DD0A7A9B2268B03BE988B@trebe101.NOE.Nokia.com> References: <009001c7e0dc$b114dd30$11010a0a@bsoft007> <1C1F3D15859526459B4DD0A7A9B2268B03BE988B@trebe101.NOE.Nokia.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <78541B84-1BC4-4586-9B2D-A8E8A7707416@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [AVT] RTP streaming and adaptation to AVC of an SVC temporalscalable bitstream - Packet loss Date: Sat, 18 Aug 2007 19:06:31 +0100 To: X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org On 18 Aug 2007, at 18:36, wrote: > In your example the SVCtoAVC adapter is an RTP mixer, which > terminates the RTP session between the sender and itself and > restarts another RTP session between itself and the receiver. > Therefore the RTP sequence number needs to be updated for the base > layer packets anyway. If the SVCtoAVC adapter is a transcoder from an SVC stream to an AVC stream, it will be an RTP translator, not an RTP mixer. Neither an RTP translator or a RTP mixer terminate the RTP session. RFC 3550 and draft-ietf-avt-topologies-06.txt discuss this in more detail. -- Colin Perkins http://csperkins.org/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Sat Aug 18 18:01:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMWKa-0000mK-6O; Sat, 18 Aug 2007 17:59:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMWKZ-0000mD-0d for avt@ietf.org; Sat, 18 Aug 2007 17:59:39 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IMWKY-0000tp-E8 for avt@ietf.org; Sat, 18 Aug 2007 17:59:38 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7ILxJMd001367; Sun, 19 Aug 2007 00:59:28 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 19 Aug 2007 00:58:48 +0300 Received: from trebe101.NOE.Nokia.com ([172.22.124.61]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 19 Aug 2007 00:58:48 +0300 Content-class: urn:content-classes:message Subject: RE: [AVT] RTP streaming and adaptation to AVC of an SVC temporalscalable bitstream - Packet loss MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 19 Aug 2007 00:58:46 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Message-ID: <1C1F3D15859526459B4DD0A7A9B2268B03BE988D@trebe101.NOE.Nokia.com> In-Reply-To: <78541B84-1BC4-4586-9B2D-A8E8A7707416@csperkins.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] RTP streaming and adaptation to AVC of an SVC temporalscalable bitstream - Packet loss Thread-Index: AcfhwpAgOTvCIo7CQnaNxXxJvXRGhQAHZb3Q References: <009001c7e0dc$b114dd30$11010a0a@bsoft007> <1C1F3D15859526459B4DD0A7A9B2268B03BE988B@trebe101.NOE.Nokia.com> <78541B84-1BC4-4586-9B2D-A8E8A7707416@csperkins.org> From: To: X-OriginalArrivalTime: 18 Aug 2007 21:58:48.0605 (UTC) FILETIME=[F49BACD0:01C7E1E2] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Hi Colin,=20 Thanks for your clarification. But according to the following sentence copied from Daniele's email,=20 "... then the SVCtoAVC adapter doesn't know whether this loss has to be signaled to the receiver, i.e. whether it must insert a sequence number gap in the outcoming RTP stream...",=20 the SVCtoAVC adapter uses a different RTP sequence number value space for the outcoming RTP steam than the incoming RTP stream. Is this what a translator can do? It is not clear how the SVCtoAVC adapter handles the CC, SSRC and CSRC fields and RTCP traffic, though.=20 BR, YK >-----Original Message----- >From: ext Colin Perkins [mailto:csp@csperkins.org]=20 >Sent: Saturday, August 18, 2007 9:07 PM >To: Wang Ye-Kui (Nokia-NRC/Tampere) >Cc: daniele@bsoft.info; avt@ietf.org >Subject: Re: [AVT] RTP streaming and adaptation to AVC of an=20 >SVC temporalscalable bitstream - Packet loss > >On 18 Aug 2007, at 18:36, wrote: >> In your example the SVCtoAVC adapter is an RTP mixer, which=20 >terminates=20 >> the RTP session between the sender and itself and restarts=20 >another RTP=20 >> session between itself and the receiver. >> Therefore the RTP sequence number needs to be updated for the base=20 >> layer packets anyway. > >If the SVCtoAVC adapter is a transcoder from an SVC stream to=20 >an AVC stream, it will be an RTP translator, not an RTP mixer.=20 >Neither an RTP translator or a RTP mixer terminate the RTP=20 >session. RFC 3550 and draft-ietf-avt-topologies-06.txt discuss=20 >this in more detail. > >-- >Colin Perkins >http://csperkins.org/ > > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Sun Aug 19 01:37:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMdRQ-00051S-CC; Sun, 19 Aug 2007 01:35:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMdRN-0004ld-6C for avt@ietf.org; Sun, 19 Aug 2007 01:35:09 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IMdRL-0004rE-JU for avt@ietf.org; Sun, 19 Aug 2007 01:35:09 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7J5Z0S8027563; Sun, 19 Aug 2007 08:35:01 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 19 Aug 2007 08:34:59 +0300 Received: from trebe101.NOE.Nokia.com ([172.22.124.61]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 19 Aug 2007 08:34:59 +0300 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AVT] RTP streaming and adaptation to AVC of an SVC temporalscalable bitstream - Packet loss x-mimeole: Produced By Microsoft Exchange V6.5 Date: Sun, 19 Aug 2007 08:34:57 +0300 Message-ID: <1C1F3D15859526459B4DD0A7A9B2268B03BE988E@trebe101.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] RTP streaming and adaptation to AVC of an SVC temporalscalable bitstream - Packet loss Thread-Index: AcfhwpAgOTvCIo7CQnaNxXxJvXRGhQAHZb3QABB3MzA= References: <009001c7e0dc$b114dd30$11010a0a@bsoft007> <1C1F3D15859526459B4DD0A7A9B2268B03BE988B@trebe101.NOE.Nokia.com> <78541B84-1BC4-4586-9B2D-A8E8A7707416@csperkins.org> From: To: X-OriginalArrivalTime: 19 Aug 2007 05:34:59.0612 (UTC) FILETIME=[AEFFE5C0:01C7E222] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org =20 OK, forget about my na=EFve question, because I found the following = sentence in RFC 3550, "If multiple data packets are re-encoded into one, = or vice versa, a translator MUST assign new sequence numbers to the = outgoing packets."=20 BR, YK=20 >-----Original Message----- >From: Wang Ye-Kui (Nokia-NRC/Tampere)=20 >Sent: Sunday, August 19, 2007 12:59 AM >To: 'ext Colin Perkins' >Cc: daniele@bsoft.info; avt@ietf.org >Subject: RE: [AVT] RTP streaming and adaptation to AVC of an=20 >SVC temporalscalable bitstream - Packet loss > > >Hi Colin,=20 > >Thanks for your clarification. But according to the following=20 >sentence copied from Daniele's email,=20 > >"... then the SVCtoAVC adapter doesn't know whether this loss=20 >has to be signaled to the receiver, i.e. whether it must=20 >insert a sequence number gap in the outcoming RTP stream...",=20 > >the SVCtoAVC adapter uses a different RTP sequence number=20 >value space for the outcoming RTP steam than the incoming RTP=20 >stream. Is this what a translator can do? It is not clear how=20 >the SVCtoAVC adapter handles the CC, SSRC and CSRC fields and=20 >RTCP traffic, though.=20 > >BR, YK > >>-----Original Message----- >>From: ext Colin Perkins [mailto:csp@csperkins.org] >>Sent: Saturday, August 18, 2007 9:07 PM >>To: Wang Ye-Kui (Nokia-NRC/Tampere) >>Cc: daniele@bsoft.info; avt@ietf.org >>Subject: Re: [AVT] RTP streaming and adaptation to AVC of an SVC=20 >>temporalscalable bitstream - Packet loss >> >>On 18 Aug 2007, at 18:36, wrote: >>> In your example the SVCtoAVC adapter is an RTP mixer, which >>terminates >>> the RTP session between the sender and itself and restarts >>another RTP >>> session between itself and the receiver. >>> Therefore the RTP sequence number needs to be updated for the base=20 >>> layer packets anyway. >> >>If the SVCtoAVC adapter is a transcoder from an SVC stream to an AVC=20 >>stream, it will be an RTP translator, not an RTP mixer. >>Neither an RTP translator or a RTP mixer terminate the RTP=20 >session. RFC=20 >>3550 and draft-ietf-avt-topologies-06.txt discuss this in more detail. >> >>-- >>Colin Perkins >>http://csperkins.org/ >> >> >> _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Sun Aug 19 08:55:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMkHq-0006gn-6z; Sun, 19 Aug 2007 08:53:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMkHo-0006gh-Uf for avt@ietf.org; Sun, 19 Aug 2007 08:53:44 -0400 Received: from submit01.sysedata.no ([195.159.29.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IMkHn-0001x4-GB for avt@ietf.org; Sun, 19 Aug 2007 08:53:44 -0400 Received: from [84.215.127.238] (helo=[10.0.0.4]) by submit01.sysedata.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.62) (envelope-from ) id 1IMkHd-0003ZV-Pq; Sun, 19 Aug 2007 14:53:33 +0200 Message-ID: <46C83D4D.3070409@db.org> Date: Sun, 19 Aug 2007 14:53:33 +0200 From: "Alfred E. Heggestad" User-Agent: Icedove 1.5.0.12 (X11/20070606) MIME-Version: 1.0 To: Colin Perkins Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-rtp-speex-03.txt References: <17F9A7A3-28B2-4119-AC40-D3DA152A4416@csperkins.org> In-Reply-To: <17F9A7A3-28B2-4119-AC40-D3DA152A4416@csperkins.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: AVT WG , jean-marc.valin@usherbrooke.ca X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Colin Perkins wrote: > On 24 Jul 2007, at 18:15, Internet-Drafts@ietf.org wrote: >> 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-03.txt >> Pages : 23 >> Date : 2007-7-24 >> >> 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). >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-speex-03.txt > > Thanks for the update - this version addresses my concerns with the > previous draft. > thanks for the review. I did not get any more comments since -03 was published (2007-07-24). Unless there more comments I guess the document is ready for publication? Should we go to the next step and call for a WGLC ? /alfred > Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Sun Aug 19 13:57:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMozn-0005Jg-EH; Sun, 19 Aug 2007 13:55:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMozl-0005Ja-OG for avt@ietf.org; Sun, 19 Aug 2007 13:55:25 -0400 Received: from smtpd4.aruba.it ([62.149.128.209] helo=smtp6.aruba.it) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IMozi-0002he-84 for avt@ietf.org; Sun, 19 Aug 2007 13:55:25 -0400 Received: (qmail 23534 invoked by uid 89); 19 Aug 2007 17:55:18 -0000 Received: by simscan 1.1.0 ppid: 23508, pid: 23518, t: 0.1913s scanners: clamav: 0.90.3/m:43/d:3378 Received: from unknown (HELO bsoft007) (daniele@bsoft.info@87.13.174.76) by smtp6.aruba.it with SMTP; 19 Aug 2007 17:55:18 -0000 Message-ID: <002201c7e28a$168c34c0$0301a8c0@bsoft007> From: "daniele renzi \(bsoft\)" To: , , "Thomas Schierl" References: <009001c7e0dc$b114dd30$11010a0a@bsoft007> <1C1F3D15859526459B4DD0A7A9B2268B03BE988B@trebe101.NOE.Nokia.com> <78541B84-1BC4-4586-9B2D-A8E8A7707416@csperkins.org> <1C1F3D15859526459B4DD0A7A9B2268B03BE988E@trebe101.NOE.Nokia.com> Subject: Re: [AVT] RTP streaming and adaptation to AVC of an SVC temporal scalable bitstream - Packet loss Date: Sun, 19 Aug 2007 19:55:10 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Rating: smtp6.aruba.it 1.6.2 0/1000/N X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Dear Ye-Kui, Colin, Thomas, all, many thanks for your clarifications. Anyway, I'd like to define precisely the scenario. Indeed, as Ye-Kui specified, the SVCtoAVC adapter assign new sequence numbers to the outgoing stream. Here is the problem: if a packet is lost in the incoming stream, it would be good if the adapter reported this anyway to the receiver, even though the packet loss was in a different RTP *segment* (I'm not sure if that can be defined as a *session*...), as in any case there has been a loss between the sender and the receiver that should be handled by the receiver itself. But the adapter cannot say whether this loss affected the base layer or an enhancement layer, as the prefix NALU could have been lost and with it the scalability information (temporal_id). Then it could assert that the sequence number gap in the incoming stream is due to a loss in the enhancement layer (then do nothing) even when this isn't true, or viceversa. We're trying to get a solution (maybe different than forcing the insertion of a sequence number gap in the outgoing stream) to make the receiver able to handle a loss in both the RTP *segments*. I'll try to evaluate the Thomas' proposal and have a better look to RFC-3550 and draft-ietf-avt-topologies-06.txt. Thanks again. Best regards, Daniele Daniele Renzi bSoft -- www.bsoft.info +39-0733-57707 (tel/fax) ----- Original Message ----- From: To: Cc: ; Sent: Sunday, August 19, 2007 7:34 AM Subject: RE: [AVT] RTP streaming and adaptation to AVC of an SVC temporalscalable bitstream - Packet loss OK, forget about my naïve question, because I found the following sentence in RFC 3550, "If multiple data packets are re-encoded into one, or vice versa, a translator MUST assign new sequence numbers to the outgoing packets." BR, YK >-----Original Message----- >From: Wang Ye-Kui (Nokia-NRC/Tampere) >Sent: Sunday, August 19, 2007 12:59 AM >To: 'ext Colin Perkins' >Cc: daniele@bsoft.info; avt@ietf.org >Subject: RE: [AVT] RTP streaming and adaptation to AVC of an >SVC temporalscalable bitstream - Packet loss > > >Hi Colin, > >Thanks for your clarification. But according to the following >sentence copied from Daniele's email, > >"... then the SVCtoAVC adapter doesn't know whether this loss >has to be signaled to the receiver, i.e. whether it must >insert a sequence number gap in the outcoming RTP stream...", > >the SVCtoAVC adapter uses a different RTP sequence number >value space for the outcoming RTP steam than the incoming RTP >stream. Is this what a translator can do? It is not clear how >the SVCtoAVC adapter handles the CC, SSRC and CSRC fields and >RTCP traffic, though. > >BR, YK > >>-----Original Message----- >>From: ext Colin Perkins [mailto:csp@csperkins.org] >>Sent: Saturday, August 18, 2007 9:07 PM >>To: Wang Ye-Kui (Nokia-NRC/Tampere) >>Cc: daniele@bsoft.info; avt@ietf.org >>Subject: Re: [AVT] RTP streaming and adaptation to AVC of an SVC >>temporalscalable bitstream - Packet loss >> >>On 18 Aug 2007, at 18:36, wrote: >>> In your example the SVCtoAVC adapter is an RTP mixer, which >>terminates >>> the RTP session between the sender and itself and restarts >>another RTP >>> session between itself and the receiver. >>> Therefore the RTP sequence number needs to be updated for the base >>> layer packets anyway. >> >>If the SVCtoAVC adapter is a transcoder from an SVC stream to an AVC >>stream, it will be an RTP translator, not an RTP mixer. >>Neither an RTP translator or a RTP mixer terminate the RTP >session. RFC >>3550 and draft-ietf-avt-topologies-06.txt discuss this in more detail. >> >>-- >>Colin Perkins >>http://csperkins.org/ >> >> >> -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.484 / Virus Database: 269.12.0/961 - Release Date: 19/08/2007 07:27 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Sun Aug 19 17:18:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMs8U-0003y3-O8; Sun, 19 Aug 2007 17:16:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMs8T-0003xy-Mk for avt@ietf.org; Sun, 19 Aug 2007 17:16:37 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IMs8S-0007i3-RV for avt@ietf.org; Sun, 19 Aug 2007 17:16:37 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7JLGRRF001360; Mon, 20 Aug 2007 00:16:28 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Aug 2007 00:16:27 +0300 Received: from trebe101.NOE.Nokia.com ([172.22.124.61]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Aug 2007 00:16:27 +0300 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AVT] RTP streaming and adaptation to AVC of an SVC temporal scalable bitstream - Packet loss x-mimeole: Produced By Microsoft Exchange V6.5 Date: Mon, 20 Aug 2007 00:16:26 +0300 Message-ID: <1C1F3D15859526459B4DD0A7A9B2268B03BE98BC@trebe101.NOE.Nokia.com> In-Reply-To: <002201c7e28a$168c34c0$0301a8c0@bsoft007> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] RTP streaming and adaptation to AVC of an SVC temporal scalable bitstream - Packet loss Thread-Index: AcfiiiCLyJw37nAuToyDl8nlq0gmDwAGfgzg References: <009001c7e0dc$b114dd30$11010a0a@bsoft007> <1C1F3D15859526459B4DD0A7A9B2268B03BE988B@trebe101.NOE.Nokia.com> <78541B84-1BC4-4586-9B2D-A8E8A7707416@csperkins.org> <1C1F3D15859526459B4DD0A7A9B2268B03BE988E@trebe101.NOE.Nokia.com> <002201c7e28a$168c34c0$0301a8c0@bsoft007> From: To: , , X-OriginalArrivalTime: 19 Aug 2007 21:16:27.0319 (UTC) FILETIME=[344BF470:01C7E2A6] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Yet another solution is to use AVC itself instead of SVC (you can also = use RFC 3984 instead of the SVC RTP payload draft), as you need only = temporal scalability. This requires the use of sub-sequence information = SEI messages. The sub_seq_layer_num indicates the temporal layer. You = set each sub-sequence layer (i.e. temporal layer) as one sub-sequence, = then the sub_seq_frame_num indicates the frame number of each reference = frame inside a temporal layer.=20 In the prefix NAL unit plus PACSI with TL0PicIndex solution, the adapter = needs to parse prefix NAL units, and the outcoming stream can only be of = temporal_id equal to 0 (i.e. the lowest temporal layer). In the = sub-seqence informtion SEI message based solution, the adapter needs to = parse sub-sequence information SEI messages, and the outcoming stream = can be of any lower temporal layers.=20 BR, YK >-----Original Message----- >From: ext daniele renzi (bsoft) [mailto:daniele@bsoft.info]=20 >Sent: Sunday, August 19, 2007 8:55 PM >To: Wang Ye-Kui (Nokia-NRC/Tampere); csp@csperkins.org; Thomas Schierl >Cc: avt@ietf.org >Subject: Re: [AVT] RTP streaming and adaptation to AVC of an=20 >SVC temporal scalable bitstream - Packet loss > >Dear Ye-Kui, Colin, Thomas, all, > >many thanks for your clarifications. > >Anyway, I'd like to define precisely the scenario. >Indeed, as Ye-Kui specified, the SVCtoAVC adapter assign new=20 >sequence numbers to the outgoing stream. >Here is the problem: if a packet is lost in the incoming=20 >stream, it would be good if the adapter reported this anyway=20 >to the receiver, even though the packet loss was in a=20 >different RTP *segment* (I'm not sure if that can be defined=20 >as a *session*...), as in any case there has been a loss=20 >between the sender and the receiver that should be handled by=20 >the receiver itself. >But the adapter cannot say whether this loss affected the base=20 >layer or an enhancement layer, as the prefix NALU could have=20 >been lost and with it the scalability information=20 >(temporal_id). Then it could assert that the sequence number=20 >gap in the incoming stream is due to a loss in the enhancement=20 >layer (then do nothing) even when this isn't true, or viceversa. > >We're trying to get a solution (maybe different than forcing=20 >the insertion of a sequence number gap in the outgoing stream)=20 >to make the receiver able to handle a loss in both the RTP *segments*. > >I'll try to evaluate the Thomas' proposal and have a better=20 >look to RFC-3550 and draft-ietf-avt-topologies-06.txt. > >Thanks again. > >Best regards, > >Daniele > > >Daniele Renzi >bSoft -- www.bsoft.info >+39-0733-57707 (tel/fax) > >----- Original Message ----- >From: >To: >Cc: ; >Sent: Sunday, August 19, 2007 7:34 AM >Subject: RE: [AVT] RTP streaming and adaptation to AVC of an=20 >SVC temporalscalable bitstream - Packet loss > > > >OK, forget about my na=EFve question, because I found the=20 >following sentence >in RFC 3550, "If multiple data packets are re-encoded into one, or vice >versa, a translator MUST assign new sequence numbers to the outgoing >packets." > >BR, YK > >>-----Original Message----- >>From: Wang Ye-Kui (Nokia-NRC/Tampere) >>Sent: Sunday, August 19, 2007 12:59 AM >>To: 'ext Colin Perkins' >>Cc: daniele@bsoft.info; avt@ietf.org >>Subject: RE: [AVT] RTP streaming and adaptation to AVC of an >>SVC temporalscalable bitstream - Packet loss >> >> >>Hi Colin, >> >>Thanks for your clarification. But according to the following >>sentence copied from Daniele's email, >> >>"... then the SVCtoAVC adapter doesn't know whether this loss >>has to be signaled to the receiver, i.e. whether it must >>insert a sequence number gap in the outcoming RTP stream...", >> >>the SVCtoAVC adapter uses a different RTP sequence number >>value space for the outcoming RTP steam than the incoming RTP >>stream. Is this what a translator can do? It is not clear how >>the SVCtoAVC adapter handles the CC, SSRC and CSRC fields and >>RTCP traffic, though. >> >>BR, YK >> >>>-----Original Message----- >>>From: ext Colin Perkins [mailto:csp@csperkins.org] >>>Sent: Saturday, August 18, 2007 9:07 PM >>>To: Wang Ye-Kui (Nokia-NRC/Tampere) >>>Cc: daniele@bsoft.info; avt@ietf.org >>>Subject: Re: [AVT] RTP streaming and adaptation to AVC of an SVC >>>temporalscalable bitstream - Packet loss >>> >>>On 18 Aug 2007, at 18:36, wrote: >>>> In your example the SVCtoAVC adapter is an RTP mixer, which >>>terminates >>>> the RTP session between the sender and itself and restarts >>>another RTP >>>> session between itself and the receiver. >>>> Therefore the RTP sequence number needs to be updated for the base >>>> layer packets anyway. >>> >>>If the SVCtoAVC adapter is a transcoder from an SVC stream to an AVC >>>stream, it will be an RTP translator, not an RTP mixer. >>>Neither an RTP translator or a RTP mixer terminate the RTP >>session. RFC >>>3550 and draft-ietf-avt-topologies-06.txt discuss this in=20 >more detail. >>> >>>-- >>>Colin Perkins >>>http://csperkins.org/ >>> >>> >>> > > > >--=20 >No virus found in this incoming message. >Checked by AVG Free Edition. >Version: 7.5.484 / Virus Database: 269.12.0/961 - Release=20 >Date: 19/08/2007 >07:27 > > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Sun Aug 19 17:24:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMsE6-00070y-Te; Sun, 19 Aug 2007 17:22:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMsE4-00070d-R6 for avt@ietf.org; Sun, 19 Aug 2007 17:22:24 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IMsE3-0006uG-6d for avt@ietf.org; Sun, 19 Aug 2007 17:22:24 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7JLMCk8028242; Mon, 20 Aug 2007 00:22:15 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Aug 2007 00:22:13 +0300 Received: from trebe101.NOE.Nokia.com ([172.22.124.61]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Aug 2007 00:22:13 +0300 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AVT] RTP streaming and adaptation to AVC of an SVC temporal scalable bitstream - Packet loss x-mimeole: Produced By Microsoft Exchange V6.5 Date: Mon, 20 Aug 2007 00:22:10 +0300 Message-ID: <1C1F3D15859526459B4DD0A7A9B2268B03BE98BD@trebe101.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] RTP streaming and adaptation to AVC of an SVC temporal scalable bitstream - Packet loss Thread-Index: AcfiiiCLyJw37nAuToyDl8nlq0gmDwAGfgzgAACjMhA= References: <009001c7e0dc$b114dd30$11010a0a@bsoft007> <1C1F3D15859526459B4DD0A7A9B2268B03BE988B@trebe101.NOE.Nokia.com> <78541B84-1BC4-4586-9B2D-A8E8A7707416@csperkins.org> <1C1F3D15859526459B4DD0A7A9B2268B03BE988E@trebe101.NOE.Nokia.com> <002201c7e28a$168c34c0$0301a8c0@bsoft007> From: To: , , X-OriginalArrivalTime: 19 Aug 2007 21:22:13.0377 (UTC) FILETIME=[02903710:01C7E2A7] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org =20 To be more precise, the adapter may only parse PACSI NAL units in the = SVC based solution, as temporal_id is also included in PACSI NAL units.=20 BR, YK >-----Original Message----- >From: Wang Ye-Kui (Nokia-NRC/Tampere)=20 >Sent: Monday, August 20, 2007 12:16 AM >To: 'ext daniele renzi (bsoft)'; csp@csperkins.org; Thomas Schierl >Cc: avt@ietf.org >Subject: RE: [AVT] RTP streaming and adaptation to AVC of an=20 >SVC temporal scalable bitstream - Packet loss > > >Yet another solution is to use AVC itself instead of SVC (you=20 >can also use RFC 3984 instead of the SVC RTP payload draft),=20 >as you need only temporal scalability. This requires the use=20 >of sub-sequence information SEI messages. The=20 >sub_seq_layer_num indicates the temporal layer. You set each=20 >sub-sequence layer (i.e. temporal layer) as one sub-sequence,=20 >then the sub_seq_frame_num indicates the frame number of each=20 >reference frame inside a temporal layer.=20 > >In the prefix NAL unit plus PACSI with TL0PicIndex solution,=20 >the adapter needs to parse prefix NAL units, and the outcoming=20 >stream can only be of temporal_id equal to 0 (i.e. the lowest=20 >temporal layer). In the sub-seqence informtion SEI message=20 >based solution, the adapter needs to parse sub-sequence=20 >information SEI messages, and the outcoming stream can be of=20 >any lower temporal layers.=20 > >BR, YK > >>-----Original Message----- >>From: ext daniele renzi (bsoft) [mailto:daniele@bsoft.info] >>Sent: Sunday, August 19, 2007 8:55 PM >>To: Wang Ye-Kui (Nokia-NRC/Tampere); csp@csperkins.org; Thomas Schierl >>Cc: avt@ietf.org >>Subject: Re: [AVT] RTP streaming and adaptation to AVC of an SVC=20 >>temporal scalable bitstream - Packet loss >> >>Dear Ye-Kui, Colin, Thomas, all, >> >>many thanks for your clarifications. >> >>Anyway, I'd like to define precisely the scenario. >>Indeed, as Ye-Kui specified, the SVCtoAVC adapter assign new sequence=20 >>numbers to the outgoing stream. >>Here is the problem: if a packet is lost in the incoming stream, it=20 >>would be good if the adapter reported this anyway to the=20 >receiver, even=20 >>though the packet loss was in a different RTP *segment* (I'm not sure=20 >>if that can be defined as a *session*...), as in any case there has=20 >>been a loss between the sender and the receiver that should=20 >be handled=20 >>by the receiver itself. >>But the adapter cannot say whether this loss affected the=20 >base layer or=20 >>an enhancement layer, as the prefix NALU could have been lost=20 >and with=20 >>it the scalability information (temporal_id). Then it could=20 >assert that=20 >>the sequence number gap in the incoming stream is due to a=20 >loss in the=20 >>enhancement layer (then do nothing) even when this isn't true, or=20 >>viceversa. >> >>We're trying to get a solution (maybe different than forcing the=20 >>insertion of a sequence number gap in the outgoing stream) to=20 >make the=20 >>receiver able to handle a loss in both the RTP *segments*. >> >>I'll try to evaluate the Thomas' proposal and have a better look to=20 >>RFC-3550 and draft-ietf-avt-topologies-06.txt. >> >>Thanks again. >> >>Best regards, >> >>Daniele >> >> >>Daniele Renzi >>bSoft -- www.bsoft.info >>+39-0733-57707 (tel/fax) >> >>----- Original Message ----- >>From: >>To: >>Cc: ; >>Sent: Sunday, August 19, 2007 7:34 AM >>Subject: RE: [AVT] RTP streaming and adaptation to AVC of an SVC=20 >>temporalscalable bitstream - Packet loss >> >> >> >>OK, forget about my na=EFve question, because I found the following=20 >>sentence in RFC 3550, "If multiple data packets are re-encoded into=20 >>one, or vice versa, a translator MUST assign new sequence numbers to=20 >>the outgoing packets." >> >>BR, YK >> >>>-----Original Message----- >>>From: Wang Ye-Kui (Nokia-NRC/Tampere) >>>Sent: Sunday, August 19, 2007 12:59 AM >>>To: 'ext Colin Perkins' >>>Cc: daniele@bsoft.info; avt@ietf.org >>>Subject: RE: [AVT] RTP streaming and adaptation to AVC of an SVC=20 >>>temporalscalable bitstream - Packet loss >>> >>> >>>Hi Colin, >>> >>>Thanks for your clarification. But according to the=20 >following sentence=20 >>>copied from Daniele's email, >>> >>>"... then the SVCtoAVC adapter doesn't know whether this loss has to=20 >>>be signaled to the receiver, i.e. whether it must insert a sequence=20 >>>number gap in the outcoming RTP stream...", >>> >>>the SVCtoAVC adapter uses a different RTP sequence number=20 >value space=20 >>>for the outcoming RTP steam than the incoming RTP stream. Is=20 >this what=20 >>>a translator can do? It is not clear how the SVCtoAVC=20 >adapter handles=20 >>>the CC, SSRC and CSRC fields and RTCP traffic, though. >>> >>>BR, YK >>> >>>>-----Original Message----- >>>>From: ext Colin Perkins [mailto:csp@csperkins.org] >>>>Sent: Saturday, August 18, 2007 9:07 PM >>>>To: Wang Ye-Kui (Nokia-NRC/Tampere) >>>>Cc: daniele@bsoft.info; avt@ietf.org >>>>Subject: Re: [AVT] RTP streaming and adaptation to AVC of an SVC=20 >>>>temporalscalable bitstream - Packet loss >>>> >>>>On 18 Aug 2007, at 18:36, wrote: >>>>> In your example the SVCtoAVC adapter is an RTP mixer, which >>>>terminates >>>>> the RTP session between the sender and itself and restarts >>>>another RTP >>>>> session between itself and the receiver. >>>>> Therefore the RTP sequence number needs to be updated for=20 >the base=20 >>>>> layer packets anyway. >>>> >>>>If the SVCtoAVC adapter is a transcoder from an SVC stream=20 >to an AVC=20 >>>>stream, it will be an RTP translator, not an RTP mixer. >>>>Neither an RTP translator or a RTP mixer terminate the RTP >>>session. RFC >>>>3550 and draft-ietf-avt-topologies-06.txt discuss this in >>more detail. >>>> >>>>-- >>>>Colin Perkins >>>>http://csperkins.org/ >>>> >>>> >>>> >> >> >> >>-- >>No virus found in this incoming message. >>Checked by AVG Free Edition. >>Version: 7.5.484 / Virus Database: 269.12.0/961 - Release >>Date: 19/08/2007 >>07:27 >> >> >> _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Mon Aug 20 06:14:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN4F2-0002iF-9t; Mon, 20 Aug 2007 06:12:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN4F0-0002i0-Ni for avt@ietf.org; Mon, 20 Aug 2007 06:12:10 -0400 Received: from smtpd4.aruba.it ([62.149.128.209] helo=smtp6.aruba.it) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IN4Ey-0007wL-Bt for avt@ietf.org; Mon, 20 Aug 2007 06:12:10 -0400 Received: (qmail 19878 invoked by uid 89); 20 Aug 2007 10:12:05 -0000 Received: by simscan 1.1.0 ppid: 19843, pid: 19859, t: 0.8302s scanners: clamav: 0.90.3/m:43/d:3378 Received: from unknown (HELO bsoft007) (daniele@bsoft.info@151.71.165.253) by smtp6.aruba.it with SMTP; 20 Aug 2007 10:12:04 -0000 Message-ID: <005701c7e312$89ea2b10$11010a0a@bsoft007> From: "daniele renzi \(bsoft\)" To: , , References: <009001c7e0dc$b114dd30$11010a0a@bsoft007> <1C1F3D15859526459B4DD0A7A9B2268B03BE988B@trebe101.NOE.Nokia.com> <78541B84-1BC4-4586-9B2D-A8E8A7707416@csperkins.org> <1C1F3D15859526459B4DD0A7A9B2268B03BE988E@trebe101.NOE.Nokia.com> <002201c7e28a$168c34c0$0301a8c0@bsoft007> <1C1F3D15859526459B4DD0A7A9B2268B03BE98BC@trebe101.NOE.Nokia.com> Subject: Re: [AVT] RTP streaming and adaptation to AVC of an SVC temporal scalable bitstream - Packet loss Date: Mon, 20 Aug 2007 12:11:55 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Rating: smtp6.aruba.it 1.6.2 0/1000/N X-Spam-Score: 0.0 (/) X-Scan-Signature: af2aae76ea468dc53420d9ba52ca6045 Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1786506666==" Errors-To: avt-bounces@ietf.org This is a multi-part message in MIME format. --===============1786506666== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0054_01C7E323.4CC025D0" This is a multi-part message in MIME format. ------=_NextPart_000_0054_01C7E323.4CC025D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Ye-Kui, thanks for your help. Just one (two) more question(s). In the SEI message based solution, how is a packet loss handled? Isn't it the same as in the prefix NALUs based solution, that is by the = RTP sequence number? It seems that the problem would persist if for example the SEI message = gets lost, but I could be wrong. >From RFC-3984 and RFC-3550 I suppose that the sequence number wouldn't = be anyway specific for the single sub-sequence (temporal layer). So far I can't see any other solution than multiplexing different RTP = sessions for different temporal layers (or sub-sequences), unless a = layer-specific sequence number was present in the RTP payload when using = a single RTP session. Thanks. Best regards, Daniele Daniele Renzi bSoft -- www.bsoft.info +39-0733-57707 (tel/fax) ----- Original Message -----=20 From: To: ; ; Cc: Sent: Sunday, August 19, 2007 11:16 PM Subject: RE: [AVT] RTP streaming and adaptation to AVC of an SVC = temporal scalable bitstream - Packet loss Yet another solution is to use AVC itself instead of SVC (you can also = use RFC 3984 instead of the SVC RTP payload draft), as you need only = temporal scalability. This requires the use of sub-sequence information = SEI messages. The sub_seq_layer_num indicates the temporal layer. You = set each sub-sequence layer (i.e. temporal layer) as one sub-sequence, = then the sub_seq_frame_num indicates the frame number of each reference = frame inside a temporal layer.=20 In the prefix NAL unit plus PACSI with TL0PicIndex solution, the adapter = needs to parse prefix NAL units, and the outcoming stream can only be of = temporal_id equal to 0 (i.e. the lowest temporal layer). In the = sub-seqence informtion SEI message based solution, the adapter needs to = parse sub-sequence information SEI messages, and the outcoming stream = can be of any lower temporal layers.=20 BR, YK >-----Original Message----- >From: ext daniele renzi (bsoft) [mailto:daniele@bsoft.info]=20 >Sent: Sunday, August 19, 2007 8:55 PM >To: Wang Ye-Kui (Nokia-NRC/Tampere); csp@csperkins.org; Thomas Schierl >Cc: avt@ietf.org >Subject: Re: [AVT] RTP streaming and adaptation to AVC of an=20 >SVC temporal scalable bitstream - Packet loss > >Dear Ye-Kui, Colin, Thomas, all, > >many thanks for your clarifications. > >Anyway, I'd like to define precisely the scenario. >Indeed, as Ye-Kui specified, the SVCtoAVC adapter assign new=20 >sequence numbers to the outgoing stream. >Here is the problem: if a packet is lost in the incoming=20 >stream, it would be good if the adapter reported this anyway=20 >to the receiver, even though the packet loss was in a=20 >different RTP *segment* (I'm not sure if that can be defined=20 >as a *session*...), as in any case there has been a loss=20 >between the sender and the receiver that should be handled by=20 >the receiver itself. >But the adapter cannot say whether this loss affected the base=20 >layer or an enhancement layer, as the prefix NALU could have=20 >been lost and with it the scalability information=20 >(temporal_id). Then it could assert that the sequence number=20 >gap in the incoming stream is due to a loss in the enhancement=20 >layer (then do nothing) even when this isn't true, or viceversa. > >We're trying to get a solution (maybe different than forcing=20 >the insertion of a sequence number gap in the outgoing stream)=20 >to make the receiver able to handle a loss in both the RTP *segments*. > >I'll try to evaluate the Thomas' proposal and have a better=20 >look to RFC-3550 and draft-ietf-avt-topologies-06.txt. > >Thanks again. > >Best regards, > >Daniele > > >Daniele Renzi >bSoft -- www.bsoft.info >+39-0733-57707 (tel/fax) > >----- Original Message ----- >From: >To: >Cc: ; >Sent: Sunday, August 19, 2007 7:34 AM >Subject: RE: [AVT] RTP streaming and adaptation to AVC of an=20 >SVC temporalscalable bitstream - Packet loss > > > >OK, forget about my na=EFve question, because I found the=20 >following sentence >in RFC 3550, "If multiple data packets are re-encoded into one, or vice >versa, a translator MUST assign new sequence numbers to the outgoing >packets." > >BR, YK > >>-----Original Message----- >>From: Wang Ye-Kui (Nokia-NRC/Tampere) >>Sent: Sunday, August 19, 2007 12:59 AM >>To: 'ext Colin Perkins' >>Cc: daniele@bsoft.info; avt@ietf.org >>Subject: RE: [AVT] RTP streaming and adaptation to AVC of an >>SVC temporalscalable bitstream - Packet loss >> >> >>Hi Colin, >> >>Thanks for your clarification. But according to the following >>sentence copied from Daniele's email, >> >>"... then the SVCtoAVC adapter doesn't know whether this loss >>has to be signaled to the receiver, i.e. whether it must >>insert a sequence number gap in the outcoming RTP stream...", >> >>the SVCtoAVC adapter uses a different RTP sequence number >>value space for the outcoming RTP steam than the incoming RTP >>stream. Is this what a translator can do? It is not clear how >>the SVCtoAVC adapter handles the CC, SSRC and CSRC fields and >>RTCP traffic, though. >> >>BR, YK >> >>>-----Original Message----- >>>From: ext Colin Perkins [mailto:csp@csperkins.org] >>>Sent: Saturday, August 18, 2007 9:07 PM >>>To: Wang Ye-Kui (Nokia-NRC/Tampere) >>>Cc: daniele@bsoft.info; avt@ietf.org >>>Subject: Re: [AVT] RTP streaming and adaptation to AVC of an SVC >>>temporalscalable bitstream - Packet loss >>> >>>On 18 Aug 2007, at 18:36, wrote: >>>> In your example the SVCtoAVC adapter is an RTP mixer, which >>>terminates >>>> the RTP session between the sender and itself and restarts >>>another RTP >>>> session between itself and the receiver. >>>> Therefore the RTP sequence number needs to be updated for the base >>>> layer packets anyway. >>> >>>If the SVCtoAVC adapter is a transcoder from an SVC stream to an AVC >>>stream, it will be an RTP translator, not an RTP mixer. >>>Neither an RTP translator or a RTP mixer terminate the RTP >>session. RFC >>>3550 and draft-ietf-avt-topologies-06.txt discuss this in=20 >more detail. >>> >>>-- >>>Colin Perkins >>>http://csperkins.org/ >>> >>> >>> > > > >--=20 >No virus found in this incoming message. >Checked by AVG Free Edition. >Version: 7.5.484 / Virus Database: 269.12.0/961 - Release=20 >Date: 19/08/2007 >07:27 > > > --=20 No virus found in this incoming message. Checked by AVG Free Edition.=20 Version: 7.5.484 / Virus Database: 269.12.0/961 - Release Date: = 19/08/2007 07:27 ------=_NextPart_000_0054_01C7E323.4CC025D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear Ye-Kui,
 
thanks for your = help.
 
Just one (two) more=20 question(s).
In the SEI message based = solution, how is a=20 packet loss handled?
Isn't it the same as in the = prefix NALUs=20 based solution, that is by the RTP sequence number?
It seems that the problem would = persist if=20 for example the SEI message gets lost, but I could be = wrong.
 
From RFC-3984 and RFC-3550 I = suppose that=20 the sequence number wouldn't be anyway specific for the single = sub-sequence=20 (temporal layer).
 
So far I can't see any other = solution than=20 multiplexing different RTP sessions for different temporal layers (or=20 sub-sequences), unless a layer-specific sequence number was present in = the RTP=20 payload when using a single RTP session.
 
Thanks.
 
Best regards,
 
Daniele
 
Daniele Renzi
bSoft -- = www.bsoft.info
+39-0733-57707  (tel/fax)
 
----- Original Message ----- =
From: <Ye-Kui.Wang@nokia.com>
To: <daniele@bsoft.info>;=20 <csp@csperkins.org>;=20 <schierl@hhi.fhg.de>
Cc: <avt@ietf.org>
Sent: Sunday, August 19, 2007 = 11:16=20 PM
Subject: RE: [AVT] RTP = streaming and=20 adaptation to AVC of an SVC temporal scalable bitstream - Packet=20 loss


Yet another solution is to use AVC itself = instead of=20 SVC (you can also use RFC 3984 instead of the SVC RTP payload draft), as = you=20 need only temporal scalability. This requires the use of sub-sequence=20 information SEI messages. The sub_seq_layer_num indicates the temporal = layer.=20 You set each sub-sequence layer (i.e. temporal layer) as one = sub-sequence, then=20 the sub_seq_frame_num indicates the frame number of each reference frame = inside=20 a temporal layer.

In the prefix NAL unit plus PACSI with = TL0PicIndex=20 solution, the adapter needs to parse prefix NAL units, and the outcoming = stream=20 can only be of temporal_id equal to 0 (i.e. the lowest temporal layer). = In the=20 sub-seqence informtion SEI message based solution, the adapter needs to = parse=20 sub-sequence information SEI messages, and the outcoming stream can be = of any=20 lower temporal layers.

BR, YK

>-----Original=20 Message-----
>From: ext daniele renzi (bsoft) = [mailto:daniele@bsoft.info]=20
>Sent: Sunday, August 19, 2007 8:55 PM
>To: Wang Ye-Kui=20 (Nokia-NRC/Tampere); csp@csperkins.org; Thomas Schierl
>Cc: avt@ietf.org
>Subject: Re: [AVT] RTP streaming and adaptation to AVC of = an=20
>SVC temporal scalable bitstream - Packet = loss
>
>Dear=20 Ye-Kui, Colin, Thomas, all,
>
>many thanks for your=20 clarifications.
>
>Anyway, I'd like to define precisely the=20 scenario.
>Indeed, as Ye-Kui specified, the SVCtoAVC adapter = assign new=20
>sequence numbers to the outgoing stream.
>Here is the = problem: if=20 a packet is lost in the incoming
>stream, it would be good if the = adapter=20 reported this anyway
>to the receiver, even though the packet = loss was in=20 a
>different RTP *segment* (I'm not sure if that can be defined=20
>as a *session*...), as in any case there has been a loss =
>between=20 the sender and the receiver that should be handled by
>the = receiver=20 itself.
>But the adapter cannot say whether this loss affected the = base=20
>layer or an enhancement layer, as the prefix NALU could have=20
>been lost and with it the scalability information =
>(temporal_id).=20 Then it could assert that the sequence number
>gap in the = incoming stream=20 is due to a loss in the enhancement
>layer (then do nothing) even = when=20 this isn't true, or viceversa.
>
>We're trying to get a = solution=20 (maybe different than forcing
>the insertion of a sequence number = gap in=20 the outgoing stream)
>to make the receiver able to handle a loss = in both=20 the RTP *segments*.
>
>I'll try to evaluate the Thomas' = proposal and=20 have a better
>look to RFC-3550 and=20 draft-ietf-avt-topologies-06.txt.
>
>Thanks=20 again.
>
>Best=20 regards,
>
>Daniele
>
>
>Daniele=20 Renzi
>bSoft -- www.bsoft.info
>+39-0733-57707  (tel/fax)
>
>----- = Original Message=20 -----
>From: <Ye-Kui.Wang@nokia.com>
>To: <csp@csperkins.org>
>Cc: <daniele@bsoft.info>; <avt@ietf.org>
>Sent:=20 Sunday, August 19, 2007 7:34 AM
>Subject: RE: [AVT] RTP streaming = and=20 adaptation to AVC of an
>SVC temporalscalable bitstream - Packet=20 loss
>
>
>
>OK, forget about my na=EFve = question, because=20 I found the
>following sentence
>in RFC 3550, "If multiple = data=20 packets are re-encoded into one, or vice
>versa, a translator MUST = assign=20 new sequence numbers to the outgoing
>packets."
>
>BR, = YK
>
>>-----Original Message-----
>>From: Wang = Ye-Kui=20 (Nokia-NRC/Tampere)
>>Sent: Sunday, August 19, 2007 12:59=20 AM
>>To: 'ext Colin Perkins'
>>Cc: daniele@bsoft.info; avt@ietf.org
>>Subject: RE: [AVT] RTP streaming and adaptation to AVC = of=20 an
>>SVC temporalscalable bitstream - Packet=20 loss
>>
>>
>>Hi = Colin,
>>
>>Thanks=20 for your clarification. But according to the = following
>>sentence=20 copied from Daniele's email,
>>
>>"... then the = SVCtoAVC=20 adapter doesn't know whether this loss
>>has to be signaled to = the=20 receiver, i.e. whether it must
>>insert a sequence number gap = in the=20 outcoming RTP stream...",
>>
>>the SVCtoAVC adapter = uses a=20 different RTP sequence number
>>value space for the outcoming = RTP steam=20 than the incoming RTP
>>stream. Is this what a translator can = do? It is=20 not clear how
>>the SVCtoAVC adapter handles the CC, SSRC and = CSRC=20 fields and
>>RTCP traffic, though.
>>
>>BR,=20 YK
>>
>>>-----Original = Message-----
>>>From:=20 ext Colin Perkins [mailto:csp@csperkins.org]
>>>Sent: = Saturday,=20 August 18, 2007 9:07 PM
>>>To: Wang Ye-Kui=20 (Nokia-NRC/Tampere)
>>>Cc: daniele@bsoft.info; avt@ietf.org
>>>Subject: Re: [AVT] RTP streaming and adaptation to = AVC of an=20 SVC
>>>temporalscalable bitstream - Packet=20 loss
>>>
>>>On 18 Aug 2007, at 18:36, = <Ye-Kui.Wang@nokia.com>=20 wrote:
>>>> In your example the SVCtoAVC adapter is an = RTP mixer,=20 which
>>>terminates
>>>> the RTP session = between the=20 sender and itself and restarts
>>>another = RTP
>>>>=20 session between itself and the receiver.
>>>> Therefore = the RTP=20 sequence number needs to be updated for the base
>>>> = layer=20 packets anyway.
>>>
>>>If the SVCtoAVC adapter = is a=20 transcoder from an SVC stream to an AVC
>>>stream, it will = be an RTP=20 translator, not an RTP mixer.
>>>Neither an RTP translator = or a RTP=20 mixer terminate the RTP
>>session. RFC
>>>3550 and=20 draft-ietf-avt-topologies-06.txt discuss this in
>more=20 detail.
>>>
>>>--
>>>Colin=20 Perkins
>>>http://csperkins.org/
>>>
>>&= gt;
>>>
>
>
>
>--=20
>No virus found in this incoming message.
>Checked by AVG = Free=20 Edition.
>Version: 7.5.484 / Virus Database: 269.12.0/961 - = Release=20
>Date: = 19/08/2007
>07:27
>
>
>



--=20
No virus found in this incoming message.
Checked by AVG Free = Edition.=20
Version: 7.5.484 / Virus Database: 269.12.0/961 - Release Date: = 19/08/2007=20 07:27

 ------=_NextPart_000_0054_01C7E323.4CC025D0-- --===============1786506666== 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://www1.ietf.org/mailman/listinfo/avt --===============1786506666==-- From avt-bounces@ietf.org Mon Aug 20 09:41:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN7U1-0003mI-Km; Mon, 20 Aug 2007 09:39:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN7Tz-0003mC-OJ for avt@ietf.org; Mon, 20 Aug 2007 09:39:51 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IN7Ty-0007qm-Hl for avt@ietf.org; Mon, 20 Aug 2007 09:39:51 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7KDdMRv014321; Mon, 20 Aug 2007 16:39:44 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Aug 2007 16:39:30 +0300 Received: from trebe101.NOE.Nokia.com ([172.22.124.61]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Aug 2007 16:39:29 +0300 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 Subject: RE: [AVT] RTP streaming and adaptation to AVC of an SVC temporal scalable bitstream - Packet loss Date: Mon, 20 Aug 2007 16:39:27 +0300 Message-ID: <1C1F3D15859526459B4DD0A7A9B2268B03C1AE56@trebe101.NOE.Nokia.com> In-Reply-To: <005701c7e312$89ea2b10$11010a0a@bsoft007> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] RTP streaming and adaptation to AVC of an SVC temporal scalable bitstream - Packet loss Thread-Index: AcfjEpSBcvWnKI/lSomvIVpqSPLDPwAHOK2g References: <009001c7e0dc$b114dd30$11010a0a@bsoft007> <1C1F3D15859526459B4DD0A7A9B2268B03BE988B@trebe101.NOE.Nokia.com> <78541B84-1BC4-4586-9B2D-A8E8A7707416@csperkins.org> <1C1F3D15859526459B4DD0A7A9B2268B03BE988E@trebe101.NOE.Nokia.com> <002201c7e28a$168c34c0$0301a8c0@bsoft007> <1C1F3D15859526459B4DD0A7A9B2268B03BE98BC@trebe101.NOE.Nokia.com> <005701c7e312$89ea2b10$11010a0a@bsoft007> From: To: , , X-OriginalArrivalTime: 20 Aug 2007 13:39:29.0865 (UTC) FILETIME=[88A23B90:01C7E32F] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ed68cc91cc637fea89623888898579ba Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Dear Daniele, =20 So you were assuming that the adapter does not parse anything else than = RTP payload header as specified in the payload format. Then how could it = find out which packet contains prefix NAL unit to be discarded?=20 To do the adaption, parsing more than RTP payload header is needed = anyway. In that case, parsing of a certain SEI message does not impose = much burden in addition. In the sub-sequence information SEI message = based solution, the adapter parses an sub-sequence information SEI = message to detect whether an earlier packet containing a slice to be = included in the outcoming stream was lost, then knows how to set the RTP = sequence number of the current outgoing packet.=20 =20 BR, YK=20 ________________________________ From: ext daniele renzi (bsoft) [mailto:daniele@bsoft.info]=20 Sent: Monday, August 20, 2007 1:12 PM To: Wang Ye-Kui (Nokia-NRC/Tampere); csp@csperkins.org; = schierl@hhi.fhg.de Cc: avt@ietf.org Subject: Re: [AVT] RTP streaming and adaptation to AVC of an SVC = temporal scalable bitstream - Packet loss =09 =09 Dear Ye-Kui, =20 thanks for your help. =20 Just one (two) more question(s). In the SEI message based solution, how is a packet loss handled? Isn't it the same as in the prefix NALUs based solution, that is by the = RTP sequence number? It seems that the problem would persist if for example the SEI message = gets lost, but I could be wrong. =20 From RFC-3984 and RFC-3550 I suppose that the sequence number wouldn't = be anyway specific for the single sub-sequence (temporal layer). =20 So far I can't see any other solution than multiplexing different RTP = sessions for different temporal layers (or sub-sequences), unless a = layer-specific sequence number was present in the RTP payload when using = a single RTP session. =20 Thanks. =20 Best regards, =20 Daniele =20 Daniele Renzi bSoft -- www.bsoft.info =20 +39-0733-57707 (tel/fax) =20 ----- Original Message -----=20 From: > To: >; = >; > Cc: > Sent: Sunday, August 19, 2007 11:16 PM Subject: RE: [AVT] RTP streaming and adaptation to AVC of an SVC = temporal scalable bitstream - Packet loss =09 =09 Yet another solution is to use AVC itself instead of SVC (you can also = use RFC 3984 instead of the SVC RTP payload draft), as you need only = temporal scalability. This requires the use of sub-sequence information = SEI messages. The sub_seq_layer_num indicates the temporal layer. You = set each sub-sequence layer (i.e. temporal layer) as one sub-sequence, = then the sub_seq_frame_num indicates the frame number of each reference = frame inside a temporal layer.=20 =09 In the prefix NAL unit plus PACSI with TL0PicIndex solution, the = adapter needs to parse prefix NAL units, and the outcoming stream can = only be of temporal_id equal to 0 (i.e. the lowest temporal layer). In = the sub-seqence informtion SEI message based solution, the adapter needs = to parse sub-sequence information SEI messages, and the outcoming stream = can be of any lower temporal layers.=20 =09 BR, YK =09 >-----Original Message----- >From: ext daniele renzi (bsoft) [mailto:daniele@bsoft.info]=20 >Sent: Sunday, August 19, 2007 8:55 PM >To: Wang Ye-Kui (Nokia-NRC/Tampere); csp@csperkins.org = ; Thomas Schierl >Cc: avt@ietf.org =20 >Subject: Re: [AVT] RTP streaming and adaptation to AVC of an=20 >SVC temporal scalable bitstream - Packet loss > >Dear Ye-Kui, Colin, Thomas, all, > >many thanks for your clarifications. > >Anyway, I'd like to define precisely the scenario. >Indeed, as Ye-Kui specified, the SVCtoAVC adapter assign new=20 >sequence numbers to the outgoing stream. >Here is the problem: if a packet is lost in the incoming=20 >stream, it would be good if the adapter reported this anyway=20 >to the receiver, even though the packet loss was in a=20 >different RTP *segment* (I'm not sure if that can be defined=20 >as a *session*...), as in any case there has been a loss=20 >between the sender and the receiver that should be handled by=20 >the receiver itself. >But the adapter cannot say whether this loss affected the base=20 >layer or an enhancement layer, as the prefix NALU could have=20 >been lost and with it the scalability information=20 >(temporal_id). Then it could assert that the sequence number=20 >gap in the incoming stream is due to a loss in the enhancement=20 >layer (then do nothing) even when this isn't true, or viceversa. > >We're trying to get a solution (maybe different than forcing=20 >the insertion of a sequence number gap in the outgoing stream)=20 >to make the receiver able to handle a loss in both the RTP *segments*. > >I'll try to evaluate the Thomas' proposal and have a better=20 >look to RFC-3550 and draft-ietf-avt-topologies-06.txt. > >Thanks again. > >Best regards, > >Daniele > > >Daniele Renzi >bSoft -- www.bsoft.info =20 >+39-0733-57707 (tel/fax) > >----- Original Message ----- >From: > >To: > >Cc: >; > >Sent: Sunday, August 19, 2007 7:34 AM >Subject: RE: [AVT] RTP streaming and adaptation to AVC of an=20 >SVC temporalscalable bitstream - Packet loss > > > >OK, forget about my na=EFve question, because I found the=20 >following sentence >in RFC 3550, "If multiple data packets are re-encoded into one, or = vice >versa, a translator MUST assign new sequence numbers to the outgoing >packets." > >BR, YK > >>-----Original Message----- >>From: Wang Ye-Kui (Nokia-NRC/Tampere) >>Sent: Sunday, August 19, 2007 12:59 AM >>To: 'ext Colin Perkins' >>Cc: daniele@bsoft.info ; avt@ietf.org = =20 >>Subject: RE: [AVT] RTP streaming and adaptation to AVC of an >>SVC temporalscalable bitstream - Packet loss >> >> >>Hi Colin, >> >>Thanks for your clarification. But according to the following >>sentence copied from Daniele's email, >> >>"... then the SVCtoAVC adapter doesn't know whether this loss >>has to be signaled to the receiver, i.e. whether it must >>insert a sequence number gap in the outcoming RTP stream...", >> >>the SVCtoAVC adapter uses a different RTP sequence number >>value space for the outcoming RTP steam than the incoming RTP >>stream. Is this what a translator can do? It is not clear how >>the SVCtoAVC adapter handles the CC, SSRC and CSRC fields and >>RTCP traffic, though. >> >>BR, YK >> >>>-----Original Message----- >>>From: ext Colin Perkins [mailto:csp@csperkins.org] >>>Sent: Saturday, August 18, 2007 9:07 PM >>>To: Wang Ye-Kui (Nokia-NRC/Tampere) >>>Cc: daniele@bsoft.info ; avt@ietf.org = =20 >>>Subject: Re: [AVT] RTP streaming and adaptation to AVC of an SVC >>>temporalscalable bitstream - Packet loss >>> >>>On 18 Aug 2007, at 18:36, > wrote: >>>> In your example the SVCtoAVC adapter is an RTP mixer, which >>>terminates >>>> the RTP session between the sender and itself and restarts >>>another RTP >>>> session between itself and the receiver. >>>> Therefore the RTP sequence number needs to be updated for the base >>>> layer packets anyway. >>> >>>If the SVCtoAVC adapter is a transcoder from an SVC stream to an AVC >>>stream, it will be an RTP translator, not an RTP mixer. >>>Neither an RTP translator or a RTP mixer terminate the RTP >>session. RFC >>>3550 and draft-ietf-avt-topologies-06.txt discuss this in=20 >more detail. >>> >>>-- >>>Colin Perkins >>>http://csperkins.org/ >>> >>> >>> > > > >--=20 >No virus found in this incoming message. >Checked by AVG Free Edition. >Version: 7.5.484 / Virus Database: 269.12.0/961 - Release=20 >Date: 19/08/2007 >07:27 > > > =09 =09 =09 --=20 No virus found in this incoming message. Checked by AVG Free Edition.=20 Version: 7.5.484 / Virus Database: 269.12.0/961 - Release Date: = 19/08/2007 07:27 =09 =09 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Mon Aug 20 14:58:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INCQr-0005T1-DC; Mon, 20 Aug 2007 14:56:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INCQq-0005Sw-T1 for avt@ietf.org; Mon, 20 Aug 2007 14:56:56 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INCQp-00068c-G8 for avt@ietf.org; Mon, 20 Aug 2007 14:56:56 -0400 Received: from postgrad1.arts.gla.ac.uk ([130.209.98.104]:61094 helo=[192.168.3.119]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1INCQo-0000Wr-SG for avt@ietf.org; Mon, 20 Aug 2007 19:56:54 +0100 Mime-Version: 1.0 (Apple Message framework v752.2) References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0F0C28CC-ADAD-417E-B457-BF6D619F6E22@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Date: Mon, 20 Aug 2007 19:56:54 +0100 To: AVT WG X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [AVT] Take draft-seokung-avt-seed-srtp-00.txt as a work item? X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: 6 August 2007 18:15:02 BDT > Subject: I-D ACTION:draft-seokung-avt-seed-srtp-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : The SEED Cipher Algorithm and Its Use with the Secure > Real-time Transport Protocol (SRTP) > Author(s) : S. Yoon, et al. > Filename : draft-seokung-avt-seed-srtp-00.txt > Pages : 6 > Date : 2007-8-6 > > This document describes the use of SEED block cipher algorithm > in the > Secure Real-time Transport Protocol [3] for confidentiality to the > RTP traffic and to the control traffic for RTP, the Real-time > Transport Control Protocol (RTCP). > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-seokung-avt-seed-srtp-00.txt This draft was briefly discussed at the recent AVT meeting in Chicago. It appears to fit within our charter "to maintain and enhance the SRTP Profile, with review and input from the Security Area". Accordingly, as we discussed in Chicago, the chairs propose to accept this draft as an AVT work item. Please send any comments, objections, or statements in favour to the mailing list by 3rd September 2007. If there are no objections, we will ask the authors to submit the next version as an AVT working group draft. -- Colin Perkins http://csperkins.org/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Mon Aug 20 16:00:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INDOt-0002kj-9j; Mon, 20 Aug 2007 15:58:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INDOr-0002ke-Up for avt@ietf.org; Mon, 20 Aug 2007 15:58:57 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INDOp-0007zJ-U7 for avt@ietf.org; Mon, 20 Aug 2007 15:58:57 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7KJwQXr002004; Mon, 20 Aug 2007 22:58:37 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Aug 2007 22:58:36 +0300 Received: from trebe101.NOE.Nokia.com ([172.22.124.61]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Aug 2007 22:58:36 +0300 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 Subject: RE: [AVT] RTP streaming and adaptation to AVC of an SVC temporal scalable bitstream - Packet loss Date: Mon, 20 Aug 2007 22:58:34 +0300 Message-ID: <1C1F3D15859526459B4DD0A7A9B2268B03C1AED7@trebe101.NOE.Nokia.com> In-Reply-To: <00b901c7e341$7e85dd30$11010a0a@bsoft007> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] RTP streaming and adaptation to AVC of an SVC temporal scalable bitstream - Packet loss Thread-Index: AcfjQYiIyH18AwadShuGMB4k16vaeAAHqOLg References: <009001c7e0dc$b114dd30$11010a0a@bsoft007> <1C1F3D15859526459B4DD0A7A9B2268B03BE988B@trebe101.NOE.Nokia.com> <78541B84-1BC4-4586-9B2D-A8E8A7707416@csperkins.org> <1C1F3D15859526459B4DD0A7A9B2268B03BE988E@trebe101.NOE.Nokia.com> <002201c7e28a$168c34c0$0301a8c0@bsoft007> <1C1F3D15859526459B4DD0A7A9B2268B03BE98BC@trebe101.NOE.Nokia.com> <005701c7e312$89ea2b10$11010a0a@bsoft007> <1C1F3D15859526459B4DD0A7A9B2268B03C1AE52@trebe101.NOE.Nokia.com> <00b901c7e341$7e85dd30$11010a0a@bsoft007> From: To: X-OriginalArrivalTime: 20 Aug 2007 19:58:36.0035 (UTC) FILETIME=[7E685530:01C7E364] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 79bb66f827e54e9d5c5c7f1f9d645608 Cc: avt@ietf.org, csp@csperkins.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Daniele, My understanding is that the NAL unit header of a NAL unit contained in = a single NAL unit packet is considered as the payload header. However, = for an aggregation packet, the "NAL unit header" of the aggregation = packet itself is considered as the payload header, but not the NAL unit = headers of individual NAL units contained in the aggregation packet. = Otherwise we have to understand that the payload header is interleaved = with payload data.=20 The SEI message based solution can be used together with normal RTP = sequence number to detect loss of a part of a picture. So is true also = for the PACSI + TL0PicIdx solution mentioned by Thomas.=20 =20 However, you are right that a temporal_id specific RTP sequence number = would be smoother as parsing of sub-sequence information SEI message is = not required. But to me the complexity reduction is not much. = Furthermore, having such layer specific RTP sequence numbers would make = the payload structure pretty ugly, because general SVC use cases with = other scalability dimensions, each combination of temporal_id (3 bits), = dependency_id (3 bits) and quality_id (5 bits) then needs to have their = specific RTP sequence numbers. The total number is up to 8x8x32.=20 =20 BR, YK ________________________________ From: ext daniele renzi (bsoft) [mailto:daniele@bsoft.info]=20 Sent: Monday, August 20, 2007 6:48 PM To: Wang Ye-Kui (Nokia-NRC/Tampere) Cc: avt@ietf.org; csp@csperkins.org; schierl@hhi.fhg.de Subject: Re: [AVT] RTP streaming and adaptation to AVC of an SVC = temporal scalable bitstream - Packet loss =09 =09 Dear Ye Kui, =20 sorry for not being clear. =20 Currently the adapter parses the NALU header to get all the information = it needs, e.g. temporal_id. =20 When I mentioned the RTP payload header I meant also the NALU header, = as, according to RFC-3984:=20 "All NAL units consist of a single NAL unit type octet, which also = co-serves as the payload header of this RTP payload format". =20 Concerning the packet loss handling in the SEI message based solution, = if I understood correctly the sub_seq_frame_num is used to detect a = reference picture loss in the sub-sequence. However, this way to detect a loss looks to me inefficient (for our = scenario) in the case where a packet carrying a slice which is just a = sub-part of a picture gest lost, as it is based on sub_seq_frame_num gap = detection and sub_seq_frame_num is the same for any slice in the same = picture. =20 For our purposes this solution could be equivalent to simply delimiting = an access unit by the marker_bit and inferring that a lost packet = belongs to a layer by simply assuming that any packet in that access = unit had the same temporal_id, which we can get either from prefix NALU = Units or SEI message. Maybe the SEI message based solution could look more useful than the = one based on prefix NALUs if we consider the SEI message as a better = delimiter of an access unit and consequently of a temporal layer. =20 I still think that a parameter simulating the RTP sequence number = inside the NALU header information and specific for any temporal layer = would have been the smoother solution to keep the single RTP session = mode. =20 Please correct me if my understanding is somewhere wrong. =20 Sorry for being a little long-winded with my emails... =20 Thanks a lot =20 BR, =20 Daniele =20 =20 Daniele Renzi bSoft -- www.bsoft.info =20 +39-0733-57707 (tel/fax) ----- Original Message -----=20 From: Ye-Kui.Wang@nokia.com=20 To: daniele@bsoft.info ; csp@csperkins.org ; schierl@hhi.fhg.de=20 Cc: avt@ietf.org=20 Sent: Monday, August 20, 2007 3:35 PM Subject: RE: [AVT] RTP streaming and adaptation to AVC of an SVC = temporal scalable bitstream - Packet loss Dear Daniele, =20 So you were assuming that the adapter does not parse anything else = than RTP payload header as specified in the payload format. Then how = could it find out which packet contains prefix NAL unit to be discarded? = To do the adaption, parsing more than RTP payload header is needed = anyway. In that case, parsing of a certain SEI message does not impose = much burden in addition. In the sub-sequence information SEI message = based solution, the adapter parses an sub-sequence information SEI = message to detect whether an earlier packet containing a slice to be = included in the outcoming stream was lost, then knows how to set the RTP = sequence number of the current outgoing packet.=20 =20 BR, YK ________________________________ From: ext daniele renzi (bsoft) [mailto:daniele@bsoft.info]=20 Sent: Monday, August 20, 2007 1:12 PM To: Wang Ye-Kui (Nokia-NRC/Tampere); csp@csperkins.org; = schierl@hhi.fhg.de Cc: avt@ietf.org Subject: Re: [AVT] RTP streaming and adaptation to AVC of an SVC = temporal scalable bitstream - Packet loss =09 =09 Dear Ye-Kui, =20 thanks for your help. =20 Just one (two) more question(s). In the SEI message based solution, how is a packet loss handled? Isn't it the same as in the prefix NALUs based solution, that is by = the RTP sequence number? It seems that the problem would persist if for example the SEI = message gets lost, but I could be wrong. =20 From RFC-3984 and RFC-3550 I suppose that the sequence number = wouldn't be anyway specific for the single sub-sequence (temporal = layer). =20 So far I can't see any other solution than multiplexing different RTP = sessions for different temporal layers (or sub-sequences), unless a = layer-specific sequence number was present in the RTP payload when using = a single RTP session. =20 Thanks. =20 Best regards, =20 Daniele =20 Daniele Renzi bSoft -- www.bsoft.info =20 +39-0733-57707 (tel/fax) =20 ----- Original Message -----=20 From: > To: >; = >; > Cc: > Sent: Sunday, August 19, 2007 11:16 PM Subject: RE: [AVT] RTP streaming and adaptation to AVC of an SVC = temporal scalable bitstream - Packet loss =09 =09 Yet another solution is to use AVC itself instead of SVC (you can = also use RFC 3984 instead of the SVC RTP payload draft), as you need = only temporal scalability. This requires the use of sub-sequence = information SEI messages. The sub_seq_layer_num indicates the temporal = layer. You set each sub-sequence layer (i.e. temporal layer) as one = sub-sequence, then the sub_seq_frame_num indicates the frame number of = each reference frame inside a temporal layer.=20 =09 In the prefix NAL unit plus PACSI with TL0PicIndex solution, the = adapter needs to parse prefix NAL units, and the outcoming stream can = only be of temporal_id equal to 0 (i.e. the lowest temporal layer). In = the sub-seqence informtion SEI message based solution, the adapter needs = to parse sub-sequence information SEI messages, and the outcoming stream = can be of any lower temporal layers.=20 =09 BR, YK =09 >-----Original Message----- >From: ext daniele renzi (bsoft) [mailto:daniele@bsoft.info]=20 >Sent: Sunday, August 19, 2007 8:55 PM >To: Wang Ye-Kui (Nokia-NRC/Tampere); csp@csperkins.org = ; Thomas Schierl >Cc: avt@ietf.org =20 >Subject: Re: [AVT] RTP streaming and adaptation to AVC of an=20 >SVC temporal scalable bitstream - Packet loss > >Dear Ye-Kui, Colin, Thomas, all, > >many thanks for your clarifications. > >Anyway, I'd like to define precisely the scenario. >Indeed, as Ye-Kui specified, the SVCtoAVC adapter assign new=20 >sequence numbers to the outgoing stream. >Here is the problem: if a packet is lost in the incoming=20 >stream, it would be good if the adapter reported this anyway=20 >to the receiver, even though the packet loss was in a=20 >different RTP *segment* (I'm not sure if that can be defined=20 >as a *session*...), as in any case there has been a loss=20 >between the sender and the receiver that should be handled by=20 >the receiver itself. >But the adapter cannot say whether this loss affected the base=20 >layer or an enhancement layer, as the prefix NALU could have=20 >been lost and with it the scalability information=20 >(temporal_id). Then it could assert that the sequence number=20 >gap in the incoming stream is due to a loss in the enhancement=20 >layer (then do nothing) even when this isn't true, or viceversa. > >We're trying to get a solution (maybe different than forcing=20 >the insertion of a sequence number gap in the outgoing stream)=20 >to make the receiver able to handle a loss in both the RTP = *segments*. > >I'll try to evaluate the Thomas' proposal and have a better=20 >look to RFC-3550 and draft-ietf-avt-topologies-06.txt. > >Thanks again. > >Best regards, > >Daniele > > >Daniele Renzi >bSoft -- www.bsoft.info =20 >+39-0733-57707 (tel/fax) > >----- Original Message ----- >From: > >To: > >Cc: >; > >Sent: Sunday, August 19, 2007 7:34 AM >Subject: RE: [AVT] RTP streaming and adaptation to AVC of an=20 >SVC temporalscalable bitstream - Packet loss > > > >OK, forget about my na=EFve question, because I found the=20 >following sentence >in RFC 3550, "If multiple data packets are re-encoded into one, or = vice >versa, a translator MUST assign new sequence numbers to the outgoing >packets." > >BR, YK > >>-----Original Message----- >>From: Wang Ye-Kui (Nokia-NRC/Tampere) >>Sent: Sunday, August 19, 2007 12:59 AM >>To: 'ext Colin Perkins' >>Cc: daniele@bsoft.info ; avt@ietf.org = =20 >>Subject: RE: [AVT] RTP streaming and adaptation to AVC of an >>SVC temporalscalable bitstream - Packet loss >> >> >>Hi Colin, >> >>Thanks for your clarification. But according to the following >>sentence copied from Daniele's email, >> >>"... then the SVCtoAVC adapter doesn't know whether this loss >>has to be signaled to the receiver, i.e. whether it must >>insert a sequence number gap in the outcoming RTP stream...", >> >>the SVCtoAVC adapter uses a different RTP sequence number >>value space for the outcoming RTP steam than the incoming RTP >>stream. Is this what a translator can do? It is not clear how >>the SVCtoAVC adapter handles the CC, SSRC and CSRC fields and >>RTCP traffic, though. >> >>BR, YK >> >>>-----Original Message----- >>>From: ext Colin Perkins [mailto:csp@csperkins.org] >>>Sent: Saturday, August 18, 2007 9:07 PM >>>To: Wang Ye-Kui (Nokia-NRC/Tampere) >>>Cc: daniele@bsoft.info ; avt@ietf.org = =20 >>>Subject: Re: [AVT] RTP streaming and adaptation to AVC of an SVC >>>temporalscalable bitstream - Packet loss >>> >>>On 18 Aug 2007, at 18:36, > wrote: >>>> In your example the SVCtoAVC adapter is an RTP mixer, which >>>terminates >>>> the RTP session between the sender and itself and restarts >>>another RTP >>>> session between itself and the receiver. >>>> Therefore the RTP sequence number needs to be updated for the = base >>>> layer packets anyway. >>> >>>If the SVCtoAVC adapter is a transcoder from an SVC stream to an = AVC >>>stream, it will be an RTP translator, not an RTP mixer. >>>Neither an RTP translator or a RTP mixer terminate the RTP >>session. RFC >>>3550 and draft-ietf-avt-topologies-06.txt discuss this in=20 >more detail. >>> >>>-- >>>Colin Perkins >>>http://csperkins.org/ >>> >>> >>> > > > >--=20 >No virus found in this incoming message. >Checked by AVG Free Edition. >Version: 7.5.484 / Virus Database: 269.12.0/961 - Release=20 >Date: 19/08/2007 >07:27 > > > =09 =09 =09 --=20 No virus found in this incoming message. Checked by AVG Free Edition.=20 Version: 7.5.484 / Virus Database: 269.12.0/961 - Release Date: = 19/08/2007 07:27 =09 =09 ________________________________ No virus found in this incoming message. Checked by AVG Free Edition.=20 Version: 7.5.484 / Virus Database: 269.12.0/961 - Release Date: = 19/08/2007 07:27 =09 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Mon Aug 20 18:52:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ING4S-0005xw-8v; Mon, 20 Aug 2007 18:50:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ING4R-0005s1-6G for avt@ietf.org; Mon, 20 Aug 2007 18:50:03 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ING4Q-0007sQ-PZ for avt@ietf.org; Mon, 20 Aug 2007 18:50:03 -0400 Received: from csperkins-dsl.demon.co.uk ([62.49.4.249]:60795 helo=[192.168.0.4]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1ING4P-00033r-QT for avt@ietf.org; Mon, 20 Aug 2007 23:50:01 +0100 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <9AF2A1B3-91CD-4A89-A455-2501CE41A72C@csperkins.org> References: <9AF2A1B3-91CD-4A89-A455-2501CE41A72C@csperkins.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <92986A11-DA21-45EF-B58B-329B778DB3FD@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [AVT] Progressing the RTP no-op payload format Date: Mon, 20 Aug 2007 23:50:00 +0100 To: AVT WG X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org On 1 Aug 2007, at 12:35, Colin Perkins wrote: > The No-Op Payload Format for RTP (draft-ietf-avt-rtp-no-op-04.txt) > is technically complete. There has been, however, some discussion > on IPR relating to the draft: see http://www1.ietf.org/ietf/IPR/ > cisco-ipr-draft-ietf-avt-rtp-no-op-04.txt and http://www1.ietf.org/ > mail-archive/web/avt/current/msg08380.html and followups. > > My understanding is that some claims on the patent application are > sufficiently broad that it will be difficult to develop a no-op > format which is not covered, should the patent be awarded. Given > this, and the IPR statement linked above, I'd like to ask the > working group two questions, so we can decide how to proceed with > the draft: > > 1) Do you believe an RTP no-op payload format is useful to > standardise, given the other keep alive mechanisms that now exist? > > 2) Do you believe the working group should proceed with this > particular draft? > > Response to the list preferred, but private responses accepted and > I'll summarise. No response - is everybody on vacation, or is there no interest in pursuing this draft? -- Colin Perkins http://csperkins.org/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Tue Aug 21 02:32:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INNG7-00085x-9K; Tue, 21 Aug 2007 02:30:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INNG5-00081V-Sy for avt@ietf.org; Tue, 21 Aug 2007 02:30:33 -0400 Received: from chnmail1.satyam.com ([125.17.27.13]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INNG4-0000zf-Q1 for avt@ietf.org; Tue, 21 Aug 2007 02:30:33 -0400 Received: from csc.satyam.com ([172.18.88.13]) by chnmail1.satyam.com (8.13.4/8.13.4) with ESMTP id l7L6QKOM001557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 21 Aug 2007 11:56:20 +0530 Received: from disclaimerchn2.corp.satyam.ad (cscmsg003.satyam.com [172.18.89.212]) by csc.satyam.com (8.13.1/8.13.1) with ESMTP id l7L6OvgE009514 for ; Tue, 21 Aug 2007 11:54:57 +0530 Received: from bhrmsg001.corp.satyam.ad ([172.19.97.210]) by disclaimerchn2.corp.satyam.ad with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Aug 2007 12:00:29 +0530 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2929 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 21 Aug 2007 12:00:26 +0530 Message-ID: <39B37AADF671EC45838BBBF23816AAF9D4E1CA@bhrmsg001.corp.satyam.ad> X-MS-Has-Attach: X-MS-TNEF-Correlator: Importance: normal Priority: normal Thread-Topic: capturing rtcp packets Thread-Index: AcfjvMKAMDxUKkLoReOAm+HefXRZCg== From: "Naresh_Hanumanthakari" To: X-OriginalArrivalTime: 21 Aug 2007 06:30:29.0360 (UTC) FILETIME=[C4829F00:01C7E3BC] X-Virus-Scanned: ClamAV version 0.88.6, clamav-milter version 0.88.6 on csc X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Subject: [AVT] capturing rtcp packets X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2100868845==" Errors-To: avt-bounces@ietf.org This is a multi-part message in MIME format. --===============2100868845== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7E3BC.C28EB41C" Content-Transfer-Encoding: 7bit This is a multi-part message in MIME format. ------_=_NextPart_001_01C7E3BC.C28EB41C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hello there, I am new to rtp/rtcp protcol usage. As part of my = requirement I need to capture RTP and RTCP packets. For that i am using some RTP packet generating = tools and captured=20 the RTP packets successfully. But i am facing some problem regarding the = RTCP packets. I am unable to generate the RTCP packets. I have few doubts -> are there any RTCP packet generating tools? -> RTCP packets are genereted automatically upon generating/receiving = the RTP packets? please suggest me any tools for RTCP packet generation or suggest me how = to generate capture the RTCP packets. thanks in advance Regards Naresh DISCLAIMER: This email (including any attachments) is intended for the sole use of = the intended recipient/s and may contain material that is CONFIDENTIAL = AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or = copying or distribution or forwarding of any or all of the contents in = this message is STRICTLY PROHIBITED. If you are not the intended = recipient, please contact the sender by email and delete all copies; = your cooperation in this regard is appreciated. ------_=_NextPart_001_01C7E3BC.C28EB41C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable capturing rtcp packets

hello there,
            I am = new to rtp/rtcp protcol usage. As part of my requirement I need to = capture
RTP and RTCP packets. For that i am using some RTP packet generating = tools and captured
the RTP packets successfully. But i am facing some problem regarding the = RTCP packets.
I am unable to generate the RTCP packets. I have few doubts
-> are there any RTCP packet generating tools?
-> RTCP packets are genereted automatically upon generating/receiving = the RTP packets?

please suggest me any tools for RTCP packet generation or suggest me how = to generate
capture the RTCP packets.
thanks in advance

Regards
Naresh

DISCLAIMER:
This email (including any attachments) is = intended for the sole use of the intended recipient/s and may contain = material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any = review or reliance by others or copying or distribution or forwarding of = any or all of the contents in this message is STRICTLY PROHIBITED. If = you are not the intended recipient, please contact the sender by email = and delete all copies; your cooperation in this regard is = appreciated.. ------_=_NextPart_001_01C7E3BC.C28EB41C-- --===============2100868845== 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://www1.ietf.org/mailman/listinfo/avt --===============2100868845==-- From avt-bounces@ietf.org Tue Aug 21 02:35:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INNJK-0002OS-P5; Tue, 21 Aug 2007 02:33:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INNJJ-0002ON-R3 for avt@ietf.org; Tue, 21 Aug 2007 02:33:53 -0400 Received: from nf-out-0910.google.com ([64.233.182.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INNJI-0005MQ-7e for avt@ietf.org; Tue, 21 Aug 2007 02:33:53 -0400 Received: by nf-out-0910.google.com with SMTP id c10so817097nfd for ; Mon, 20 Aug 2007 23:33:51 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=aSiW5yqFtgMGoQ0VxuPMUc/PpiA1enPrO/aZPojRP3PZtzwa7jWWwS9jxSAetpUrPqyl0ESmqfbn/IYIWViLtvoFGoKc460/L7BLDJSISkiyzq2gY7T4eP9VHzbL9YJ7aVo4TE6oN4RRhp4lI8sFpVBRQ7qSVKldyGp+/Hz3M94= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=E/kBaKlx4kCu3nqP8YnmUqqcZOYt8a6h4FdaXTk3SdiQnJBcug1qKf9slYaeCbiLfC2ubsZBIqB62wt0U+iI3wIQqZ/U/gdt8Eoox48ndlyLImizqXE0GtfR3RxEu+ksZImGyeOI6ZEl9Du5v5VxSRHhEaYEAWxKcqoLvEzc15s= Received: by 10.78.37.7 with SMTP id k7mr2540249huk.1187678031348; Mon, 20 Aug 2007 23:33:51 -0700 (PDT) Received: by 10.78.140.19 with HTTP; Mon, 20 Aug 2007 23:33:51 -0700 (PDT) Message-ID: <4e5a3720708202333p26f5f0c8q706491dc9d15a0bc@mail.gmail.com> Date: Tue, 21 Aug 2007 09:33:51 +0300 From: "Murat Artun" To: Naresh_Hanumanthakari Subject: Re: [AVT] capturing rtcp packets In-Reply-To: <39B37AADF671EC45838BBBF23816AAF9D4E1CA@bhrmsg001.corp.satyam.ad> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <39B37AADF671EC45838BBBF23816AAF9D4E1CA@bhrmsg001.corp.satyam.ad> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org It is worth first checking the documentation of your tool for RTCP support. On 8/21/07, Naresh_Hanumanthakari wrote: > > > > > hello there, > I am new to rtp/rtcp protcol usage. As part of my requirement I > need to capture > RTP and RTCP packets. For that i am using some RTP packet generating tools > and captured > the RTP packets successfully. But i am facing some problem regarding the > RTCP packets. > I am unable to generate the RTCP packets. I have few doubts > -> are there any RTCP packet generating tools? > -> RTCP packets are genereted automatically upon generating/receiving the > RTP packets? > > please suggest me any tools for RTCP packet generation or suggest me how to > generate > capture the RTCP packets. > thanks in advance > > Regards > Naresh > > > > DISCLAIMER: > This email (including any attachments) is intended for the sole use of the > intended recipient/s and may contain material that is CONFIDENTIAL AND > PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or > distribution or forwarding of any or all of the contents in this message is > STRICTLY PROHIBITED. If you are not the intended recipient, please contact > the sender by email and delete all copies; your cooperation in this regard > is appreciated.. > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > > -- M u r at A r t u n, MSc. Design Engineer "be conservative in what you do, be liberal in what you accept from others" _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Tue Aug 21 03:46:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INOQH-0001sK-5D; Tue, 21 Aug 2007 03:45:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INOQF-0001sD-CH for avt@ietf.org; Tue, 21 Aug 2007 03:45:07 -0400 Received: from smtpd4.aruba.it ([62.149.128.209] helo=smtp4.aruba.it) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1INOQB-0007Cw-7A for avt@ietf.org; Tue, 21 Aug 2007 03:45:07 -0400 Received: (qmail 10387 invoked by uid 89); 21 Aug 2007 07:44:54 -0000 Received: by simscan 1.1.0 ppid: 10366, pid: 10379, t: 0.5854s scanners: clamav: 0.88.4/m:40/d:1722 Received: from unknown (HELO bsoft007) (daniele@bsoft.info@151.71.165.253) by smtp4.aruba.it with SMTP; 21 Aug 2007 07:44:53 -0000 Message-ID: <000901c7e3c7$23e31470$11010a0a@bsoft007> From: "daniele renzi \(bsoft\)" To: Subject: Re: [AVT] RTP streaming and adaptation to AVC of an SVC temporal scalable bitstream - Packet loss Date: Tue, 21 Aug 2007 09:44:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Rating: smtp4.aruba.it 1.6.2 0/1000/N X-Spam-Score: 0.0 (/) X-Scan-Signature: 4166dd0e0c668adc975c3d3e0f1bce3b X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Dear Ye Kui, I agree with you that having layer specific sequence numbers would make the payload structure pretty ugly, even though I think also that for spatial and quality scalability the RTP session multiplexing (different RTP sessions for different layers) would be more sensible than for temporal scalability, as one of the biggest benefit to have a single RTP session for a temporal scalable bistream using prefix NAL Units is to make an AVC decoder able to decode even the original SVC stream (with all the layers) by simply discarding the prefix NAL Units. This would save from having specific RTP sequence numbers for spatial and quality scalability and combinations of them. Anyway, as you suggested, using the SEI message based solution in addition to the RTP sequence number seems a very good solution, as well as thinking about removing in our scenario the single RTP session requirement. I'll try to estimate which is the best solution for us. Thanks a lot for your help. Best regards, Daniele Daniele Renzi bSoft -- www.bsoft.info +39-0733-57707 (tel/fax) > ----- Original Message ----- > From: > To: > Cc: ; ; > Sent: Monday, August 20, 2007 9:58 PM > Subject: RE: [AVT] RTP streaming and adaptation to AVC of an SVC temporal > scalable bitstream - Packet loss > > > Daniele, > > My understanding is that the NAL unit header of a NAL unit contained in a > single NAL unit packet is considered as the payload header. However, for > an aggregation packet, the "NAL unit header" of the aggregation packet > itself is considered as the payload header, but not the NAL unit headers > of individual NAL units contained in the aggregation packet. Otherwise we > have to understand that the payload header is interleaved with payload > data. > > The SEI message based solution can be used together with normal RTP > sequence number to detect loss of a part of a picture. So is true also for > the PACSI + TL0PicIdx solution mentioned by Thomas. > > However, you are right that a temporal_id specific RTP sequence number > would be smoother as parsing of sub-sequence information SEI message is > not required. But to me the complexity reduction is not much. Furthermore, > having such layer specific RTP sequence numbers would make the payload > structure pretty ugly, because general SVC use cases with other > scalability dimensions, each combination of temporal_id (3 bits), > dependency_id (3 bits) and quality_id (5 bits) then needs to have their > specific RTP sequence numbers. The total number is up to 8x8x32. > > BR, YK > > ________________________________ > > From: ext daniele renzi (bsoft) [mailto:daniele@bsoft.info] > Sent: Monday, August 20, 2007 6:48 PM > To: Wang Ye-Kui (Nokia-NRC/Tampere) > Cc: avt@ietf.org; csp@csperkins.org; schierl@hhi.fhg.de > Subject: Re: [AVT] RTP streaming and adaptation to AVC of an SVC temporal > scalable bitstream - Packet loss > > > Dear Ye Kui, > > sorry for not being clear. > > Currently the adapter parses the NALU header to get all the information it > needs, e.g. temporal_id. > > When I mentioned the RTP payload header I meant also the NALU header, as, > according to RFC-3984: > "All NAL units consist of a single NAL unit type octet, which also > co-serves as the payload header of this RTP payload format". > > Concerning the packet loss handling in the SEI message based solution, if > I understood correctly the sub_seq_frame_num is used to detect a reference > picture loss in the sub-sequence. > However, this way to detect a loss looks to me inefficient (for our > scenario) in the case where a packet carrying a slice which is just a > sub-part of a picture gest lost, as it is based on sub_seq_frame_num gap > detection and sub_seq_frame_num is the same for any slice in the same > picture. > > For our purposes this solution could be equivalent to simply delimiting an > access unit by the marker_bit and inferring that a lost packet belongs to > a layer by simply assuming that any packet in that access unit had the > same temporal_id, which we can get either from prefix NALU Units or SEI > message. > Maybe the SEI message based solution could look more useful than the one > based on prefix NALUs if we consider the SEI message as a better delimiter > of an access unit and consequently of a temporal layer. > > I still think that a parameter simulating the RTP sequence number inside > the NALU header information and specific for any temporal layer would have > been the smoother solution to keep the single RTP session mode. > > Please correct me if my understanding is somewhere wrong. > > Sorry for being a little long-winded with my emails... > > Thanks a lot > > BR, > > Daniele > > > Daniele Renzi > bSoft -- www.bsoft.info > +39-0733-57707 (tel/fax) > > ----- Original Message ----- > From: Ye-Kui.Wang@nokia.com > To: daniele@bsoft.info ; csp@csperkins.org ; schierl@hhi.fhg.de > Cc: avt@ietf.org > Sent: Monday, August 20, 2007 3:35 PM > Subject: RE: [AVT] RTP streaming and adaptation to AVC of an SVC temporal > scalable bitstream - Packet loss > > Dear Daniele, > > So you were assuming that the adapter does not parse anything else than > RTP payload header as specified in the payload format. Then how could it > find out which packet contains prefix NAL unit to be discarded? To do the > adaption, parsing more than RTP payload header is needed anyway. In that > case, parsing of a certain SEI message does not impose much burden in > addition. In the sub-sequence information SEI message based solution, the > adapter parses an sub-sequence information SEI message to detect whether > an earlier packet containing a slice to be included in the outcoming > stream was lost, then knows how to set the RTP sequence number of the > current outgoing packet. > > BR, YK > > > ________________________________ > > From: ext daniele renzi (bsoft) [mailto:daniele@bsoft.info] > Sent: Monday, August 20, 2007 1:12 PM > To: Wang Ye-Kui (Nokia-NRC/Tampere); csp@csperkins.org; schierl@hhi.fhg.de > Cc: avt@ietf.org > Subject: Re: [AVT] RTP streaming and adaptation to AVC of an SVC temporal > scalable bitstream - Packet loss > > > Dear Ye-Kui, > > thanks for your help. > > Just one (two) more question(s). > In the SEI message based solution, how is a packet loss handled? > Isn't it the same as in the prefix NALUs based solution, that is by the > RTP sequence number? > It seems that the problem would persist if for example the SEI message > gets lost, but I could be wrong. > > From RFC-3984 and RFC-3550 I suppose that the sequence number wouldn't be > anyway specific for the single sub-sequence (temporal layer). > > So far I can't see any other solution than multiplexing different RTP > sessions for different temporal layers (or sub-sequences), unless a > layer-specific sequence number was present in the RTP payload when using a > single RTP session. > > Thanks. > > Best regards, > > Daniele > > Daniele Renzi > bSoft -- www.bsoft.info > +39-0733-57707 (tel/fax) > > ----- Original Message ----- > From: > > To: >; >; > > Cc: > > Sent: Sunday, August 19, 2007 11:16 PM > Subject: RE: [AVT] RTP streaming and adaptation to AVC of an SVC temporal > scalable bitstream - Packet loss > > > > Yet another solution is to use AVC itself instead of SVC (you can also use > RFC 3984 instead of the SVC RTP payload draft), as you need only temporal > scalability. This requires the use of sub-sequence information SEI > messages. The sub_seq_layer_num indicates the temporal layer. You set each > sub-sequence layer (i.e. temporal layer) as one sub-sequence, then the > sub_seq_frame_num indicates the frame number of each reference frame > inside a temporal layer. > > In the prefix NAL unit plus PACSI with TL0PicIndex solution, the adapter > needs to parse prefix NAL units, and the outcoming stream can only be of > temporal_id equal to 0 (i.e. the lowest temporal layer). In the > sub-seqence informtion SEI message based solution, the adapter needs to > parse sub-sequence information SEI messages, and the outcoming stream can > be of any lower temporal layers. > > BR, YK > >>-----Original Message----- >>From: ext daniele renzi (bsoft) [mailto:daniele@bsoft.info] >>Sent: Sunday, August 19, 2007 8:55 PM >>To: Wang Ye-Kui (Nokia-NRC/Tampere); csp@csperkins.org >> ; Thomas Schierl >>Cc: avt@ietf.org >>Subject: Re: [AVT] RTP streaming and adaptation to AVC of an >>SVC temporal scalable bitstream - Packet loss >> >>Dear Ye-Kui, Colin, Thomas, all, >> >>many thanks for your clarifications. >> >>Anyway, I'd like to define precisely the scenario. >>Indeed, as Ye-Kui specified, the SVCtoAVC adapter assign new >>sequence numbers to the outgoing stream. >>Here is the problem: if a packet is lost in the incoming >>stream, it would be good if the adapter reported this anyway >>to the receiver, even though the packet loss was in a >>different RTP *segment* (I'm not sure if that can be defined >>as a *session*...), as in any case there has been a loss >>between the sender and the receiver that should be handled by >>the receiver itself. >>But the adapter cannot say whether this loss affected the base >>layer or an enhancement layer, as the prefix NALU could have >>been lost and with it the scalability information >>(temporal_id). Then it could assert that the sequence number >>gap in the incoming stream is due to a loss in the enhancement >>layer (then do nothing) even when this isn't true, or viceversa. >> >>We're trying to get a solution (maybe different than forcing >>the insertion of a sequence number gap in the outgoing stream) >>to make the receiver able to handle a loss in both the RTP *segments*. >> >>I'll try to evaluate the Thomas' proposal and have a better >>look to RFC-3550 and draft-ietf-avt-topologies-06.txt. >> >>Thanks again. >> >>Best regards, >> >>Daniele >> >> >>Daniele Renzi >>bSoft -- www.bsoft.info >>+39-0733-57707 (tel/fax) >> >>----- Original Message ----- >>From: > >>To: > >>Cc: >; > > >>Sent: Sunday, August 19, 2007 7:34 AM >>Subject: RE: [AVT] RTP streaming and adaptation to AVC of an >>SVC temporalscalable bitstream - Packet loss >> >> >> >>OK, forget about my naïve question, because I found the >>following sentence >>in RFC 3550, "If multiple data packets are re-encoded into one, or vice >>versa, a translator MUST assign new sequence numbers to the outgoing >>packets." >> >>BR, YK >> >>>-----Original Message----- >>>From: Wang Ye-Kui (Nokia-NRC/Tampere) >>>Sent: Sunday, August 19, 2007 12:59 AM >>>To: 'ext Colin Perkins' >>>Cc: daniele@bsoft.info ; avt@ietf.org >>> >>>Subject: RE: [AVT] RTP streaming and adaptation to AVC of an >>>SVC temporalscalable bitstream - Packet loss >>> >>> >>>Hi Colin, >>> >>>Thanks for your clarification. But according to the following >>>sentence copied from Daniele's email, >>> >>>"... then the SVCtoAVC adapter doesn't know whether this loss >>>has to be signaled to the receiver, i.e. whether it must >>>insert a sequence number gap in the outcoming RTP stream...", >>> >>>the SVCtoAVC adapter uses a different RTP sequence number >>>value space for the outcoming RTP steam than the incoming RTP >>>stream. Is this what a translator can do? It is not clear how >>>the SVCtoAVC adapter handles the CC, SSRC and CSRC fields and >>>RTCP traffic, though. >>> >>>BR, YK >>> >>>>-----Original Message----- >>>>From: ext Colin Perkins [mailto:csp@csperkins.org] >>>>Sent: Saturday, August 18, 2007 9:07 PM >>>>To: Wang Ye-Kui (Nokia-NRC/Tampere) >>>>Cc: daniele@bsoft.info ; avt@ietf.org >>>> >>>>Subject: Re: [AVT] RTP streaming and adaptation to AVC of an SVC >>>>temporalscalable bitstream - Packet loss >>>> >>>>On 18 Aug 2007, at 18:36, >>> > wrote: >>>>> In your example the SVCtoAVC adapter is an RTP mixer, which >>>>terminates >>>>> the RTP session between the sender and itself and restarts >>>>another RTP >>>>> session between itself and the receiver. >>>>> Therefore the RTP sequence number needs to be updated for the base >>>>> layer packets anyway. >>>> >>>>If the SVCtoAVC adapter is a transcoder from an SVC stream to an AVC >>>>stream, it will be an RTP translator, not an RTP mixer. >>>>Neither an RTP translator or a RTP mixer terminate the RTP >>>session. RFC >>>>3550 and draft-ietf-avt-topologies-06.txt discuss this in >>more detail. >>>> >>>>-- >>>>Colin Perkins >>>>http://csperkins.org/ >>>> >>>> >>>> >> >> >> >>-- >>No virus found in this incoming message. >>Checked by AVG Free Edition. >>Version: 7.5.484 / Virus Database: 269.12.0/961 - Release >>Date: 19/08/2007 >>07:27 >> >> >> > > > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.484 / Virus Database: 269.12.0/961 - Release Date: 19/08/2007 > 07:27 > > > > ________________________________ > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.484 / Virus Database: 269.12.0/961 - Release Date: 19/08/2007 > 07:27 > > > > > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.484 / Virus Database: 269.12.1/963 - Release Date: 20/08/2007 > 17:44 > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Tue Aug 21 06:40:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INR89-0004Sl-4K; Tue, 21 Aug 2007 06:38:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INR88-0004SD-Fs for avt@ietf.org; Tue, 21 Aug 2007 06:38:36 -0400 Received: from cluster-f.mailcontrol.com ([85.119.2.190]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INR85-0000yr-Sl for avt@ietf.org; Tue, 21 Aug 2007 06:38:34 -0400 Received: from rly30f.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly30f.srv.mailcontrol.com (MailControl) with ESMTP id l7LAcOhH014636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 21 Aug 2007 11:38:24 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly30f.srv.mailcontrol.com (MailControl) id l7LAbxME011856 for avt@ietf.org; Tue, 21 Aug 2007 11:37:59 +0100 Received: from exsmtp01.nasstar-t1.net (exsmtp01.nasstar-t1.net [89.28.233.12]) by rly30f-eth0.srv.mailcontrol.com (envelope-sender attila.sipos@vegastream.com) (MIMEDefang) with ESMTP id l7LAbj88010441; Tue, 21 Aug 2007 11:37:59 +0100 (BST) Received: from ExBE03.nasstar-t1.net ([10.2.10.102]) by exsmtp01.nasstar-t1.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Aug 2007 11:36:53 +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" Subject: RE: [AVT] Progressing the RTP no-op payload format Date: Tue, 21 Aug 2007 11:34:28 +0100 Message-ID: <165288C2C3E29449AFDE022DD10CC471071285E4@ExBE03.nasstar-t1.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] Progressing the RTP no-op payload format Thread-Index: AcfjfJVlxbH2YkSGQ4CUdjjRN5NQZAAYYkaQ From: "Attila Sipos" To: "Colin Perkins" , "AVT WG" X-OriginalArrivalTime: 21 Aug 2007 10:36:53.0176 (UTC) FILETIME=[3059EB80:01C7E3DF] X-Scanned-By: MailControl A-07-08-00 (www.mailcontrol.com) on 10.70.1.140 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Looks like a useful draft to me. I think maybe the draft doesn't sound exciting and so people won't express strong opinions one way or another. Perosnally, I wouldn't like to see this draft disappear. Regards, Attila -----Original Message----- From: Colin Perkins [mailto:csp@csperkins.org]=20 Sent: 20 August 2007 23:50 To: AVT WG Subject: Re: [AVT] Progressing the RTP no-op payload format On 1 Aug 2007, at 12:35, Colin Perkins wrote: > The No-Op Payload Format for RTP (draft-ietf-avt-rtp-no-op-04.txt) is=20 > technically complete. There has been, however, some discussion on IPR=20 > relating to the draft: see http://www1.ietf.org/ietf/IPR/=20 > cisco-ipr-draft-ietf-avt-rtp-no-op-04.txt and http://www1.ietf.org/=20 > mail-archive/web/avt/current/msg08380.html and followups. > > My understanding is that some claims on the patent application are=20 > sufficiently broad that it will be difficult to develop a no-op format > which is not covered, should the patent be awarded. Given this, and=20 > the IPR statement linked above, I'd like to ask the working group two=20 > questions, so we can decide how to proceed with the draft: > > 1) Do you believe an RTP no-op payload format is useful to=20 > standardise, given the other keep alive mechanisms that now exist? > > 2) Do you believe the working group should proceed with this=20 > particular draft? > > Response to the list preferred, but private responses accepted and=20 > I'll summarise. No response - is everybody on vacation, or is there no interest in pursuing this draft? -- Colin Perkins http://csperkins.org/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Tue Aug 21 06:41:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INR9X-0004lw-Pm; Tue, 21 Aug 2007 06:40:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INR9O-0004lJ-K5 for avt@ietf.org; Tue, 21 Aug 2007 06:39:59 -0400 Received: from cluster-f.mailcontrol.com ([85.119.2.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INR9N-0004fE-26 for avt@ietf.org; Tue, 21 Aug 2007 06:39:54 -0400 Received: from rly19f.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly19f.srv.mailcontrol.com (MailControl) with ESMTP id l7LAdYb6009225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 21 Aug 2007 11:39:37 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly19f.srv.mailcontrol.com (MailControl) id l7LAdIra008187 for avt@ietf.org; Tue, 21 Aug 2007 11:39:18 +0100 Received: from exsmtp01.nasstar-t1.net (exsmtp01.nasstar-t1.net [89.28.233.12]) by rly19f-eth0.srv.mailcontrol.com (envelope-sender attila.sipos@vegastream.com) (MIMEDefang) with ESMTP id l7LAZwAv026357; Tue, 21 Aug 2007 11:39:18 +0100 (BST) Received: from ExBE03.nasstar-t1.net ([10.2.10.102]) by exsmtp01.nasstar-t1.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Aug 2007 11:39:34 +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" Subject: RE: [AVT] Progressing the RTP no-op payload format Date: Tue, 21 Aug 2007 11:39:11 +0100 Message-ID: <165288C2C3E29449AFDE022DD10CC47107128611@ExBE03.nasstar-t1.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] Progressing the RTP no-op payload format Thread-Index: AcfjfJVlxbH2YkSGQ4CUdjjRN5NQZAAYYkaQAAA/CMA= From: "Attila Sipos" To: "Colin Perkins" , "AVT WG" X-OriginalArrivalTime: 21 Aug 2007 10:39:34.0117 (UTC) FILETIME=[90479150:01C7E3DF] X-Scanned-By: MailControl A-07-08-00 (www.mailcontrol.com) on 10.70.1.129 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org > 1) Do you believe an RTP no-op payload format is useful to=20 > standardise, given the other keep alive mechanisms that now exist? By the way, what other standard keepalive mechanisms exist? Any of them RFC'ed yet? So far I have found this: http://www.ietf.org/internet-drafts/draft-ietf-avt-app-rtp-keepalive-00. txt (and another very similar one (by the same author) Regards, Attila =20 -----Original Message----- From: Attila Sipos=20 Sent: 21 August 2007 11:34 To: 'Colin Perkins'; AVT WG Subject: RE: [AVT] Progressing the RTP no-op payload format Looks like a useful draft to me. I think maybe the draft doesn't sound exciting and so people won't express strong opinions one way or another. Perosnally, I wouldn't like to see this draft disappear. Regards, Attila -----Original Message----- From: Colin Perkins [mailto:csp@csperkins.org] Sent: 20 August 2007 23:50 To: AVT WG Subject: Re: [AVT] Progressing the RTP no-op payload format On 1 Aug 2007, at 12:35, Colin Perkins wrote: > The No-Op Payload Format for RTP (draft-ietf-avt-rtp-no-op-04.txt) is=20 > technically complete. There has been, however, some discussion on IPR=20 > relating to the draft: see http://www1.ietf.org/ietf/IPR/=20 > cisco-ipr-draft-ietf-avt-rtp-no-op-04.txt and http://www1.ietf.org/=20 > mail-archive/web/avt/current/msg08380.html and followups. > > My understanding is that some claims on the patent application are=20 > sufficiently broad that it will be difficult to develop a no-op format > which is not covered, should the patent be awarded. Given this, and=20 > the IPR statement linked above, I'd like to ask the working group two=20 > questions, so we can decide how to proceed with the draft: > > 1) Do you believe an RTP no-op payload format is useful to=20 > standardise, given the other keep alive mechanisms that now exist? > > 2) Do you believe the working group should proceed with this=20 > particular draft? > > Response to the list preferred, but private responses accepted and=20 > I'll summarise. No response - is everybody on vacation, or is there no interest in pursuing this draft? -- Colin Perkins http://csperkins.org/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Tue Aug 21 07:13:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INReX-0003FG-D0; Tue, 21 Aug 2007 07:12:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INReV-0003F4-8E for avt@ietf.org; Tue, 21 Aug 2007 07:12:03 -0400 Received: from smtpd4.aruba.it ([62.149.128.209] helo=smtp4.aruba.it) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1INReO-0005Kd-JM for avt@ietf.org; Tue, 21 Aug 2007 07:12:03 -0400 Received: (qmail 5184 invoked by uid 89); 21 Aug 2007 11:11:54 -0000 Received: by simscan 1.1.0 ppid: 5133, pid: 5159, t: 0.7768s scanners: clamav: 0.88.4/m:40/d:1722 Received: from unknown (HELO bsoft007) (daniele@bsoft.info@151.71.165.253) by smtp4.aruba.it with SMTP; 21 Aug 2007 11:11:53 -0000 Message-ID: <008201c7e3e4$0e2dce00$11010a0a@bsoft007> From: "daniele renzi \(bsoft\)" To: Subject: Re: [AVT] RTP streaming and adaptation to AVC of an SVC temporal scalable bitstream - Packet loss Date: Tue, 21 Aug 2007 13:11:42 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Rating: smtp4.aruba.it 1.6.2 0/1000/N X-Spam-Score: 0.0 (/) X-Scan-Signature: efc5d1db3729b4b7031f1bb5f5a30ae3 Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Dear Ye Kui, I've been doing a little more thinking about the solution of having layer specific sequence numbers and I got the following conclusions (please correct me if something is wrong): - each combination of temporal_id (3 bits), dependency_id (3 bits) and quality_id (5 bits) completely identify a scalable layer; - the streamer should keep a separate sequence number variable for any of these layers (combination of temporal_id, dependency_id and quality_id); - separate sequence number variables don't mean different fields in the RTP payload header (NALU header), as any NALU belongs to a specific layer and not to other layers (1:1 mapping between NALU and layer); - so, we'd have just one additional field in the NALU header (16 bit, like sequence number in RTP); this field could be added just to the prefix NALUs syntax to save some bandwidth; this wouldn't make the RTP payload structure that ugly, at least in my opinion...; - I agree that having a prefix NALU for any slice NALU would definitely increase the bandwidth occupation and that for temporal scalability the SEI message based solution could be better; however, this would mean that in any SVC streaming scenario the single RTP session mode must be used in conjunction with the sub-sequence SEI message to prevent packet loss problems when dropping higher layers; - if everything above is correct, I suppose that without this additional layer-specific sequence number field, in any case the smoother way to handle packet losses is transporting different layers of a SVC bitstream in different RTP sessions. Thanks BR, Daniele Daniele Renzi bSoft -- www.bsoft.info +39-0733-57707 (tel/fax) ----- Original Message ----- From: "daniele renzi (bsoft)" To: Sent: Tuesday, August 21, 2007 9:43 AM Subject: Re: [AVT] RTP streaming and adaptation to AVC of an SVC temporal scalable bitstream - Packet loss > Dear Ye Kui, > > I agree with you that having layer specific sequence numbers would make > the payload structure pretty ugly, even though I think also that for > spatial and quality scalability the RTP session multiplexing (different > RTP sessions for different layers) would be more sensible than for > temporal scalability, as one of the biggest benefit to have a single RTP > session for a temporal scalable bistream using prefix NAL Units is to make > an AVC decoder able to decode even the original SVC stream (with all the > layers) by simply discarding the prefix NAL Units. > This would save from having specific RTP sequence numbers for spatial and > quality scalability and combinations of them. > > Anyway, as you suggested, using the SEI message based solution in addition > to the RTP sequence number seems a very good solution, as well as thinking > about removing in our scenario the single RTP session requirement. > > I'll try to estimate which is the best solution for us. > > Thanks a lot for your help. > > Best regards, > > Daniele > > Daniele Renzi > bSoft -- www.bsoft.info > +39-0733-57707 (tel/fax) > > ----- Original Message ----- > From: > To: > Cc: ; ; > Sent: Monday, August 20, 2007 9:58 PM > Subject: RE: [AVT] RTP streaming and adaptation to AVC of an SVC temporal > scalable bitstream - Packet loss > > > Daniele, > > My understanding is that the NAL unit header of a NAL unit contained in a > single NAL unit packet is considered as the payload header. However, for > an aggregation packet, the "NAL unit header" of the aggregation packet > itself is considered as the payload header, but not the NAL unit headers > of individual NAL units contained in the aggregation packet. Otherwise we > have to understand that the payload header is interleaved with payload > data. > > The SEI message based solution can be used together with normal RTP > sequence number to detect loss of a part of a picture. So is true also for > the PACSI + TL0PicIdx solution mentioned by Thomas. > > However, you are right that a temporal_id specific RTP sequence number > would be smoother as parsing of sub-sequence information SEI message is > not required. But to me the complexity reduction is not much. Furthermore, > having such layer specific RTP sequence numbers would make the payload > structure pretty ugly, because general SVC use cases with other > scalability dimensions, each combination of temporal_id (3 bits), > dependency_id (3 bits) and quality_id (5 bits) then needs to have their > specific RTP sequence numbers. The total number is up to 8x8x32. > > BR, YK > > ________________________________ > > From: ext daniele renzi (bsoft) [mailto:daniele@bsoft.info] > Sent: Monday, August 20, 2007 6:48 PM > To: Wang Ye-Kui (Nokia-NRC/Tampere) > Cc: avt@ietf.org; csp@csperkins.org; schierl@hhi.fhg.de > Subject: Re: [AVT] RTP streaming and adaptation to AVC of an SVC temporal > scalable bitstream - Packet loss > > > Dear Ye Kui, > > sorry for not being clear. > > Currently the adapter parses the NALU header to get all the information it > needs, e.g. temporal_id. > > When I mentioned the RTP payload header I meant also the NALU header, as, > according to RFC-3984: > "All NAL units consist of a single NAL unit type octet, which also > co-serves as the payload header of this RTP payload format". > > Concerning the packet loss handling in the SEI message based solution, if > I understood correctly the sub_seq_frame_num is used to detect a reference > picture loss in the sub-sequence. > However, this way to detect a loss looks to me inefficient (for our > scenario) in the case where a packet carrying a slice which is just a > sub-part of a picture gest lost, as it is based on sub_seq_frame_num gap > detection and sub_seq_frame_num is the same for any slice in the same > picture. > > For our purposes this solution could be equivalent to simply delimiting an > access unit by the marker_bit and inferring that a lost packet belongs to > a layer by simply assuming that any packet in that access unit had the > same temporal_id, which we can get either from prefix NALU Units or SEI > message. > Maybe the SEI message based solution could look more useful than the one > based on prefix NALUs if we consider the SEI message as a better delimiter > of an access unit and consequently of a temporal layer. > > I still think that a parameter simulating the RTP sequence number inside > the NALU header information and specific for any temporal layer would have > been the smoother solution to keep the single RTP session mode. > > Please correct me if my understanding is somewhere wrong. > > Sorry for being a little long-winded with my emails... > > Thanks a lot > > BR, > > Daniele > > > Daniele Renzi > bSoft -- www.bsoft.info > +39-0733-57707 (tel/fax) > > ----- Original Message ----- > From: Ye-Kui.Wang@nokia.com > To: daniele@bsoft.info ; csp@csperkins.org ; schierl@hhi.fhg.de > Cc: avt@ietf.org > Sent: Monday, August 20, 2007 3:35 PM > Subject: RE: [AVT] RTP streaming and adaptation to AVC of an SVC temporal > scalable bitstream - Packet loss > > Dear Daniele, > > So you were assuming that the adapter does not parse anything else than > RTP payload header as specified in the payload format. Then how could it > find out which packet contains prefix NAL unit to be discarded? To do the > adaption, parsing more than RTP payload header is needed anyway. In that > case, parsing of a certain SEI message does not impose much burden in > addition. In the sub-sequence information SEI message based solution, the > adapter parses an sub-sequence information SEI message to detect whether > an earlier packet containing a slice to be included in the outcoming > stream was lost, then knows how to set the RTP sequence number of the > current outgoing packet. > > BR, YK > > > ________________________________ > > From: ext daniele renzi (bsoft) [mailto:daniele@bsoft.info] > Sent: Monday, August 20, 2007 1:12 PM > To: Wang Ye-Kui (Nokia-NRC/Tampere); csp@csperkins.org; schierl@hhi.fhg.de > Cc: avt@ietf.org > Subject: Re: [AVT] RTP streaming and adaptation to AVC of an SVC temporal > scalable bitstream - Packet loss > > > Dear Ye-Kui, > > thanks for your help. > > Just one (two) more question(s). > In the SEI message based solution, how is a packet loss handled? > Isn't it the same as in the prefix NALUs based solution, that is by the > RTP sequence number? > It seems that the problem would persist if for example the SEI message > gets lost, but I could be wrong. > > From RFC-3984 and RFC-3550 I suppose that the sequence number wouldn't be > anyway specific for the single sub-sequence (temporal layer). > > So far I can't see any other solution than multiplexing different RTP > sessions for different temporal layers (or sub-sequences), unless a > layer-specific sequence number was present in the RTP payload when using a > single RTP session. > > Thanks. > > Best regards, > > Daniele > > Daniele Renzi > bSoft -- www.bsoft.info > +39-0733-57707 (tel/fax) > > ----- Original Message ----- > From: > > To: >; >; > > Cc: > > Sent: Sunday, August 19, 2007 11:16 PM > Subject: RE: [AVT] RTP streaming and adaptation to AVC of an SVC temporal > scalable bitstream - Packet loss > > > > Yet another solution is to use AVC itself instead of SVC (you can also use > RFC 3984 instead of the SVC RTP payload draft), as you need only temporal > scalability. This requires the use of sub-sequence information SEI > messages. The sub_seq_layer_num indicates the temporal layer. You set each > sub-sequence layer (i.e. temporal layer) as one sub-sequence, then the > sub_seq_frame_num indicates the frame number of each reference frame > inside a temporal layer. > > In the prefix NAL unit plus PACSI with TL0PicIndex solution, the adapter > needs to parse prefix NAL units, and the outcoming stream can only be of > temporal_id equal to 0 (i.e. the lowest temporal layer). In the > sub-seqence informtion SEI message based solution, the adapter needs to > parse sub-sequence information SEI messages, and the outcoming stream can > be of any lower temporal layers. > > BR, YK > >>-----Original Message----- >>From: ext daniele renzi (bsoft) [mailto:daniele@bsoft.info] >>Sent: Sunday, August 19, 2007 8:55 PM >>To: Wang Ye-Kui (Nokia-NRC/Tampere); csp@csperkins.org >> ; Thomas Schierl >>Cc: avt@ietf.org >>Subject: Re: [AVT] RTP streaming and adaptation to AVC of an >>SVC temporal scalable bitstream - Packet loss >> >>Dear Ye-Kui, Colin, Thomas, all, >> >>many thanks for your clarifications. >> >>Anyway, I'd like to define precisely the scenario. >>Indeed, as Ye-Kui specified, the SVCtoAVC adapter assign new >>sequence numbers to the outgoing stream. >>Here is the problem: if a packet is lost in the incoming >>stream, it would be good if the adapter reported this anyway >>to the receiver, even though the packet loss was in a >>different RTP *segment* (I'm not sure if that can be defined >>as a *session*...), as in any case there has been a loss >>between the sender and the receiver that should be handled by >>the receiver itself. >>But the adapter cannot say whether this loss affected the base >>layer or an enhancement layer, as the prefix NALU could have >>been lost and with it the scalability information >>(temporal_id). Then it could assert that the sequence number >>gap in the incoming stream is due to a loss in the enhancement >>layer (then do nothing) even when this isn't true, or viceversa. >> >>We're trying to get a solution (maybe different than forcing >>the insertion of a sequence number gap in the outgoing stream) >>to make the receiver able to handle a loss in both the RTP *segments*. >> >>I'll try to evaluate the Thomas' proposal and have a better >>look to RFC-3550 and draft-ietf-avt-topologies-06.txt. >> >>Thanks again. >> >>Best regards, >> >>Daniele >> >> >>Daniele Renzi >>bSoft -- www.bsoft.info >>+39-0733-57707 (tel/fax) >> >>----- Original Message ----- >>From: > >>To: > >>Cc: >; > > >>Sent: Sunday, August 19, 2007 7:34 AM >>Subject: RE: [AVT] RTP streaming and adaptation to AVC of an >>SVC temporalscalable bitstream - Packet loss >> >> >> >>OK, forget about my naïve question, because I found the >>following sentence >>in RFC 3550, "If multiple data packets are re-encoded into one, or vice >>versa, a translator MUST assign new sequence numbers to the outgoing >>packets." >> >>BR, YK >> >>>-----Original Message----- >>>From: Wang Ye-Kui (Nokia-NRC/Tampere) >>>Sent: Sunday, August 19, 2007 12:59 AM >>>To: 'ext Colin Perkins' >>>Cc: daniele@bsoft.info ; avt@ietf.org >>> >>>Subject: RE: [AVT] RTP streaming and adaptation to AVC of an >>>SVC temporalscalable bitstream - Packet loss >>> >>> >>>Hi Colin, >>> >>>Thanks for your clarification. But according to the following >>>sentence copied from Daniele's email, >>> >>>"... then the SVCtoAVC adapter doesn't know whether this loss >>>has to be signaled to the receiver, i.e. whether it must >>>insert a sequence number gap in the outcoming RTP stream...", >>> >>>the SVCtoAVC adapter uses a different RTP sequence number >>>value space for the outcoming RTP steam than the incoming RTP >>>stream. Is this what a translator can do? It is not clear how >>>the SVCtoAVC adapter handles the CC, SSRC and CSRC fields and >>>RTCP traffic, though. >>> >>>BR, YK >>> >>>>-----Original Message----- >>>>From: ext Colin Perkins [mailto:csp@csperkins.org] >>>>Sent: Saturday, August 18, 2007 9:07 PM >>>>To: Wang Ye-Kui (Nokia-NRC/Tampere) >>>>Cc: daniele@bsoft.info ; avt@ietf.org >>>> >>>>Subject: Re: [AVT] RTP streaming and adaptation to AVC of an SVC >>>>temporalscalable bitstream - Packet loss >>>> >>>>On 18 Aug 2007, at 18:36, >>> > wrote: >>>>> In your example the SVCtoAVC adapter is an RTP mixer, which >>>>terminates >>>>> the RTP session between the sender and itself and restarts >>>>another RTP >>>>> session between itself and the receiver. >>>>> Therefore the RTP sequence number needs to be updated for the base >>>>> layer packets anyway. >>>> >>>>If the SVCtoAVC adapter is a transcoder from an SVC stream to an AVC >>>>stream, it will be an RTP translator, not an RTP mixer. >>>>Neither an RTP translator or a RTP mixer terminate the RTP >>>session. RFC >>>>3550 and draft-ietf-avt-topologies-06.txt discuss this in >>more detail. >>>> >>>>-- >>>>Colin Perkins >>>>http://csperkins.org/ >>>> >>>> >>>> >> >> >> >>-- >>No virus found in this incoming message. >>Checked by AVG Free Edition. >>Version: 7.5.484 / Virus Database: 269.12.0/961 - Release >>Date: 19/08/2007 >>07:27 >> >> >> > > > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.484 / Virus Database: 269.12.0/961 - Release Date: 19/08/2007 > 07:27 > > > > ________________________________ > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.484 / Virus Database: 269.12.0/961 - Release Date: 19/08/2007 > 07:27 > > > > > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.484 / Virus Database: 269.12.1/963 - Release Date: 20/08/2007 > 17:44 > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Tue Aug 21 07:38:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INS2g-00086S-6s; Tue, 21 Aug 2007 07:37:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INS2f-000866-5N for avt@ietf.org; Tue, 21 Aug 2007 07:37:01 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INS2e-0002KO-EK for avt@ietf.org; Tue, 21 Aug 2007 07:37:01 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7LBaRVn032528; Tue, 21 Aug 2007 14:36:49 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Aug 2007 14:36:35 +0300 Received: from trebe101.NOE.Nokia.com ([172.22.124.61]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Aug 2007 14:36:35 +0300 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 Subject: RE: [AVT] RTP streaming and adaptation to AVC of an SVC temporal scalable bitstream - Packet loss Date: Tue, 21 Aug 2007 14:36:33 +0300 Message-ID: <1C1F3D15859526459B4DD0A7A9B2268B03C1B455@trebe101.NOE.Nokia.com> In-Reply-To: <008201c7e3e4$0e2dce00$11010a0a@bsoft007> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] RTP streaming and adaptation to AVC of an SVC temporal scalable bitstream - Packet loss Thread-Index: Acfj5BeD/yzU3aClSWeKdSTFP6u51wAAKXCA References: <008201c7e3e4$0e2dce00$11010a0a@bsoft007> From: To: X-OriginalArrivalTime: 21 Aug 2007 11:36:35.0294 (UTC) FILETIME=[8775BFE0:01C7E3E7] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Hi Daniele, See inline, please.=20 BR, YK=20 >-----Original Message----- >From: ext daniele renzi (bsoft) [mailto:daniele@bsoft.info]=20 >Sent: Tuesday, August 21, 2007 2:12 PM >To: Wang Ye-Kui (Nokia-NRC/Tampere) >Cc: avt@ietf.org >Subject: Re: [AVT] RTP streaming and adaptation to AVC of an=20 >SVC temporal scalable bitstream - Packet loss > >Dear Ye Kui, > >I've been doing a little more thinking about the solution of=20 >having layer specific sequence numbers and I got the following=20 >conclusions (please correct me if something is wrong): >- each combination of temporal_id (3 bits), dependency_id (3=20 >bits) and quality_id (5 bits) completely identify a scalable layer; An error from myself: quality_id is of 4 bits, not 5 bits.=20 Otherwise yes if a scalable layer is defined as a combintion of the three variables DTQ. In some exotic cases, a scalable layer may also be a subset of NAL units of a combinaiton of DTQ, e.g. when region-of-interest (ROI) scalability is in use.=20 >- the streamer should keep a separate sequence number variable=20 >for any of these layers (combination of temporal_id,=20 >dependency_id and quality_id); >- separate sequence number variables don't mean different=20 >fields in the RTP payload header (NALU header), as any NALU=20 >belongs to a specific layer and not to other layers (1:1=20 >mapping between NALU and layer); >- so, we'd have just one additional field in the NALU header=20 >(16 bit, like sequence number in RTP); this field could be=20 >added just to the prefix NALUs syntax to save some bandwidth;=20 >this wouldn't make the RTP payload structure that ugly, at=20 >least in my opinion...; This is true if you never encapsulate NALUs with different values of DTQ in the same packet. But the thing gets complicated when considering aggregation packets, and more when considering interleaved packetization mode. But you are right that probably nobody would ever encapsulate NAL units from the maximum possible number of layers into one packet, therefore the number of layer specific sequence numbers would never reach the maximum, 8x8x16. But anyway, then a loop of layers is needed, and an ID of layer is needed in addition to each sequence number.=20 >- I agree that having a prefix NALU for any slice NALU would=20 >definitely increase the bandwidth occupation and that for=20 >temporal scalability the SEI message based solution could be=20 >better; however, this would mean that in any SVC streaming=20 >scenario the single RTP session mode must be used in=20 >conjunction with the sub-sequence SEI message to prevent=20 >packet loss problems when dropping higher layers; Prefix NAL unit can only be associated with NALUs with dependency_id and quality_id both equal to 0.=20 >- if everything above is correct, I suppose that without this=20 >additional layer-specific sequence number field, in any case=20 >the smoother way to handle packet losses is transporting=20 >different layers of a SVC bitstream in different RTP sessions. > The conclusion is correct to me. Yet another solution with single RTP session, without sub-sequence info SEI message, without PACSI or prefix NAL unit, is to let the adapter parse the slice header. Then together with normal RTP sequence number the adapter should be able to detect any loss of any layer. BR, YK >Thanks > >BR, > >Daniele > >Daniele Renzi >bSoft -- www.bsoft.info >+39-0733-57707 (tel/fax) > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Tue Aug 21 08:34:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INSu5-0004WS-3X; Tue, 21 Aug 2007 08:32:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INSu3-0004WD-Ig for avt@ietf.org; Tue, 21 Aug 2007 08:32:11 -0400 Received: from smtpd4.aruba.it ([62.149.128.209] helo=smtp5.aruba.it) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1INSu2-0003mK-M3 for avt@ietf.org; Tue, 21 Aug 2007 08:32:11 -0400 Received: (qmail 7755 invoked by uid 89); 21 Aug 2007 12:32:06 -0000 Received: by simscan 1.1.0 ppid: 7734, pid: 7745, t: 0.2498s scanners: clamav: 0.88.4/m:40/d:1722 Received: from unknown (HELO bsoft007) (daniele@bsoft.info@151.71.165.253) by smtp5.aruba.it with SMTP; 21 Aug 2007 12:32:06 -0000 Message-ID: <009601c7e3ef$42c38ff0$11010a0a@bsoft007> From: "daniele renzi \(bsoft\)" To: References: <008201c7e3e4$0e2dce00$11010a0a@bsoft007> <1C1F3D15859526459B4DD0A7A9B2268B03C1B455@trebe101.NOE.Nokia.com> Subject: Re: [AVT] RTP streaming and adaptation to AVC of an SVC temporal scalable bitstream - Packet loss Date: Tue, 21 Aug 2007 14:31:55 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Rating: smtp5.aruba.it 1.6.2 0/1000/N X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Dear Ye Kui, please see inline. BR, Daniele Daniele Renzi bSoft -- www.bsoft.info +39-0733-57707 (tel/fax) ----- Original Message ----- From: To: Cc: Sent: Tuesday, August 21, 2007 1:36 PM Subject: RE: [AVT] RTP streaming and adaptation to AVC of an SVC temporal scalable bitstream - Packet loss Hi Daniele, See inline, please. BR, YK >-----Original Message----- >From: ext daniele renzi (bsoft) [mailto:daniele@bsoft.info] >Sent: Tuesday, August 21, 2007 2:12 PM >To: Wang Ye-Kui (Nokia-NRC/Tampere) >Cc: avt@ietf.org >Subject: Re: [AVT] RTP streaming and adaptation to AVC of an >SVC temporal scalable bitstream - Packet loss > >Dear Ye Kui, > >I've been doing a little more thinking about the solution of >having layer specific sequence numbers and I got the following >conclusions (please correct me if something is wrong): >- each combination of temporal_id (3 bits), dependency_id (3 >bits) and quality_id (5 bits) completely identify a scalable layer; An error from myself: quality_id is of 4 bits, not 5 bits. Otherwise yes if a scalable layer is defined as a combintion of the three variables DTQ. In some exotic cases, a scalable layer may also be a subset of NAL units of a combinaiton of DTQ, e.g. when region-of-interest (ROI) scalability is in use. [DR] Ok. Error from myself as well...:) >- the streamer should keep a separate sequence number variable >for any of these layers (combination of temporal_id, >dependency_id and quality_id); >- separate sequence number variables don't mean different >fields in the RTP payload header (NALU header), as any NALU >belongs to a specific layer and not to other layers (1:1 >mapping between NALU and layer); >- so, we'd have just one additional field in the NALU header >(16 bit, like sequence number in RTP); this field could be >added just to the prefix NALUs syntax to save some bandwidth; >this wouldn't make the RTP payload structure that ugly, at >least in my opinion...; This is true if you never encapsulate NALUs with different values of DTQ in the same packet. [DR] That's why such layer-specific sequence number parameter should be added to any NALU, not to any packet . This way if you loose a packet you can track the loss of NALUs for any layer. But the thing gets complicated when considering aggregation packets, and more when considering interleaved packetization mode. But you are right that probably nobody would ever encapsulate NAL units from the maximum possible number of layers into one packet, therefore the number of layer specific sequence numbers would never reach the maximum, 8x8x16. But anyway, then a loop of layers is needed, and an ID of layer is needed in addition to each sequence number. [DR] The layer ID could be simply inferred by combining the DTQ values, then not added as a field in the payload header. Isn't that correct? Anyway, you are right that things could get complicated, but in any case this would be just a computational problem for the streamer (keeping multiple variables for the various sequence numbers, looping over layers, etc.) and not a big burden for the RTP payload (16 bits per NALU), unless one encapsulate several NALUs in the same packet. A 1-bit flag could be even used to signal that such 16-bits field is present or not. >- I agree that having a prefix NALU for any slice NALU would >definitely increase the bandwidth occupation and that for >temporal scalability the SEI message based solution could be >better; however, this would mean that in any SVC streaming >scenario the single RTP session mode must be used in >conjunction with the sub-sequence SEI message to prevent >packet loss problems when dropping higher layers; Prefix NAL unit can only be associated with NALUs with dependency_id and quality_id both equal to 0. [DR] You are right. >- if everything above is correct, I suppose that without this >additional layer-specific sequence number field, in any case >the smoother way to handle packet losses is transporting >different layers of a SVC bitstream in different RTP sessions. > The conclusion is correct to me. Yet another solution with single RTP session, without sub-sequence info SEI message, without PACSI or prefix NAL unit, is to let the adapter parse the slice header. Then together with normal RTP sequence number the adapter should be able to detect any loss of any layer. [DR] I agree with you, even though I still can't see how the adapter could deduce a loss by simply parsing the slice header and do not decoding the rest of the stream, e.g. estimating the number of decoded macroblocks and comparing it to the total number of MBs per picture or to first_mb_in_slice. BR, YK >Thanks > >BR, > >Daniele > >Daniele Renzi >bSoft -- www.bsoft.info >+39-0733-57707 (tel/fax) > -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.484 / Virus Database: 269.12.1/963 - Release Date: 20/08/2007 17:44 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Tue Aug 21 09:12:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INTUv-0001by-NU; Tue, 21 Aug 2007 09:10:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INTUu-0001bj-Qd for avt@ietf.org; Tue, 21 Aug 2007 09:10:16 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INTUu-00055C-4b for avt@ietf.org; Tue, 21 Aug 2007 09:10:16 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7LDA4xK021648; Tue, 21 Aug 2007 16:10:10 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Aug 2007 16:09:51 +0300 Received: from trebe101.NOE.Nokia.com ([172.22.124.61]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Aug 2007 16:09:51 +0300 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 Subject: RE: [AVT] RTP streaming and adaptation to AVC of an SVC temporal scalable bitstream - Packet loss Date: Tue, 21 Aug 2007 16:09:49 +0300 Message-ID: <1C1F3D15859526459B4DD0A7A9B2268B03C1B598@trebe101.NOE.Nokia.com> In-Reply-To: <009601c7e3ef$42c38ff0$11010a0a@bsoft007> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] RTP streaming and adaptation to AVC of an SVC temporal scalable bitstream - Packet loss Thread-Index: Acfj71dRB9PX8JnmQ3K9LGD3dBjq3gAAgtdA References: <008201c7e3e4$0e2dce00$11010a0a@bsoft007> <1C1F3D15859526459B4DD0A7A9B2268B03C1B455@trebe101.NOE.Nokia.com> <009601c7e3ef$42c38ff0$11010a0a@bsoft007> From: To: X-OriginalArrivalTime: 21 Aug 2007 13:09:51.0054 (UTC) FILETIME=[8ECAF6E0:01C7E3F4] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org See also inline. I removed overhead text to make reading easier.=20 The issue is now pretty clear. The question is whether to change the payload structures to associate a 16-bit layer specific RTP sequence number to each NAL unit, or rely on existing solutions.=20 Personally I think we should not make the change to the SVC RTP payload draft as the change is needed to all types of packets. So Daniele you would like to have this? Does anyone else there has an opinion?=20 BR, YK =20 >>- the streamer should keep a separate sequence number=20 >variable for any=20 >>of these layers (combination of temporal_id, dependency_id and=20 >>quality_id); >>- separate sequence number variables don't mean different=20 >fields in the=20 >>RTP payload header (NALU header), as any NALU belongs to a specific=20 >>layer and not to other layers (1:1 mapping between NALU and layer); >>- so, we'd have just one additional field in the NALU header >>(16 bit, like sequence number in RTP); this field could be added just=20 >>to the prefix NALUs syntax to save some bandwidth; this wouldn't make=20 >>the RTP payload structure that ugly, at least in my opinion...; > >This is true if you never encapsulate NALUs with different=20 >values of DTQ in the same packet. > >[DR] That's why such layer-specific sequence number parameter=20 >should be added to any NALU, not to any packet . >This way if you loose a packet you can track the loss of NALUs=20 >for any layer. Right. My misunderstanding that you meant to any packet. =20 > >But the thing gets complicated when considering aggregation=20 >packets, and more when considering interleaved packetization=20 >mode. But you are right that probably nobody would ever=20 >encapsulate NAL units from the maximum possible number of=20 >layers into one packet, therefore the number of layer specific=20 >sequence numbers would never reach the maximum, 8x8x16. But=20 >anyway, then a loop of layers is needed, and an ID of layer is=20 >needed in addition to each sequence number. > >[DR] The layer ID could be simply inferred by combining the=20 >DTQ values, then not added as a field in the payload header.=20 >Isn't that correct? Yes, that's right.=20 >[DR] I agree with you, even though I still can't see how the=20 >adapter could deduce a loss by simply parsing the slice header=20 >and do not decoding the rest of the stream, e.g. estimating=20 >the number of decoded macroblocks and comparing it to the=20 >total number of MBs per picture or to first_mb_in_slice. After parsing slice header you then know the value of frame_num and picture order count values. Then together with RTP sequence number should be able to detect loss of pictures and slices. This is simply as the two solutions mentioned earlier.=20 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Tue Aug 21 09:27:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INTk7-0000H1-Sf; Tue, 21 Aug 2007 09:25:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INTk5-0000Fu-Vr for avt@ietf.org; Tue, 21 Aug 2007 09:25:58 -0400 Received: from smtpd4.aruba.it ([62.149.128.209] helo=smtp5.aruba.it) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1INTk5-0005eQ-7V for avt@ietf.org; Tue, 21 Aug 2007 09:25:57 -0400 Received: (qmail 21231 invoked by uid 89); 21 Aug 2007 13:25:54 -0000 Received: by simscan 1.1.0 ppid: 21196, pid: 21218, t: 0.3900s scanners: clamav: 0.88.4/m:40/d:1722 Received: from unknown (HELO bsoft007) (daniele@bsoft.info@151.71.165.253) by smtp5.aruba.it with SMTP; 21 Aug 2007 13:25:54 -0000 Message-ID: <00b301c7e3f6$c73fb6d0$11010a0a@bsoft007> From: "daniele renzi \(bsoft\)" To: References: <008201c7e3e4$0e2dce00$11010a0a@bsoft007> <1C1F3D15859526459B4DD0A7A9B2268B03C1B455@trebe101.NOE.Nokia.com> <009601c7e3ef$42c38ff0$11010a0a@bsoft007> <1C1F3D15859526459B4DD0A7A9B2268B03C1B598@trebe101.NOE.Nokia.com> Subject: Re: [AVT] RTP streaming and adaptation to AVC of an SVC temporal scalable bitstream - Packet loss Date: Tue, 21 Aug 2007 15:25:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Rating: smtp5.aruba.it 1.6.2 0/1000/N X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Dear Ye Kui, all, just to highlight that my purpose was just to highlight a possible critical scenario considering the already existing solutions and emphasize what in my (negligible... :) ) opinion was the best solution. I'm aware that making changes to the SVC RTP payload draft (and perhaps to the SVC video coding spec...) isn't maybe the best step to perform at this stage and that we could simply rely on already existing solutions. Anyway, any further opinion would be very appreciated. Thanks, BR Daniele Daniele Renzi bSoft -- www.bsoft.info +39-0733-57707 (tel/fax) ----- Original Message ----- From: To: Cc: Sent: Tuesday, August 21, 2007 3:09 PM Subject: RE: [AVT] RTP streaming and adaptation to AVC of an SVC temporal scalable bitstream - Packet loss See also inline. I removed overhead text to make reading easier. The issue is now pretty clear. The question is whether to change the payload structures to associate a 16-bit layer specific RTP sequence number to each NAL unit, or rely on existing solutions. Personally I think we should not make the change to the SVC RTP payload draft as the change is needed to all types of packets. So Daniele you would like to have this? Does anyone else there has an opinion? BR, YK >>- the streamer should keep a separate sequence number >variable for any >>of these layers (combination of temporal_id, dependency_id and >>quality_id); >>- separate sequence number variables don't mean different >fields in the >>RTP payload header (NALU header), as any NALU belongs to a specific >>layer and not to other layers (1:1 mapping between NALU and layer); >>- so, we'd have just one additional field in the NALU header >>(16 bit, like sequence number in RTP); this field could be added just >>to the prefix NALUs syntax to save some bandwidth; this wouldn't make >>the RTP payload structure that ugly, at least in my opinion...; > >This is true if you never encapsulate NALUs with different >values of DTQ in the same packet. > >[DR] That's why such layer-specific sequence number parameter >should be added to any NALU, not to any packet . >This way if you loose a packet you can track the loss of NALUs >for any layer. Right. My misunderstanding that you meant to any packet. > >But the thing gets complicated when considering aggregation >packets, and more when considering interleaved packetization >mode. But you are right that probably nobody would ever >encapsulate NAL units from the maximum possible number of >layers into one packet, therefore the number of layer specific >sequence numbers would never reach the maximum, 8x8x16. But >anyway, then a loop of layers is needed, and an ID of layer is >needed in addition to each sequence number. > >[DR] The layer ID could be simply inferred by combining the >DTQ values, then not added as a field in the payload header. >Isn't that correct? Yes, that's right. >[DR] I agree with you, even though I still can't see how the >adapter could deduce a loss by simply parsing the slice header >and do not decoding the rest of the stream, e.g. estimating >the number of decoded macroblocks and comparing it to the >total number of MBs per picture or to first_mb_in_slice. After parsing slice header you then know the value of frame_num and picture order count values. Then together with RTP sequence number should be able to detect loss of pictures and slices. This is simply as the two solutions mentioned earlier. -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.484 / Virus Database: 269.12.1/963 - Release Date: 20/08/2007 17:44 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Tue Aug 21 09:51:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INU7B-0002Ra-Of; Tue, 21 Aug 2007 09:49:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INU7A-0002RU-2X for avt@ietf.org; Tue, 21 Aug 2007 09:49:48 -0400 Received: from mail.hhi.fraunhofer.de ([193.174.67.45]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INU79-0006Gh-6F for avt@ietf.org; Tue, 21 Aug 2007 09:49:47 -0400 Received: by mail.hhi.fraunhofer.de (Postfix, from userid 65534) id F04181D88FBF; Tue, 21 Aug 2007 15:49:45 +0200 (CEST) Received: from [172.19.40.140] (unknown [172.19.40.140]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.hhi.fraunhofer.de (Postfix) with ESMTP id BC26E1D88FB6; Tue, 21 Aug 2007 15:49:44 +0200 (CEST) In-Reply-To: <00b301c7e3f6$c73fb6d0$11010a0a@bsoft007> References: <008201c7e3e4$0e2dce00$11010a0a@bsoft007><1C1F3D15859526459B4DD0 A7A9B2268B03C1B455@trebe101.NOE.Nokia.com><009601c7e3ef$42c38ff0$11010a0a@b soft007><1C1F3D15859526459B4DD0A7A9B2268B03C1B598@trebe101.NOE.Nokia.com> <00b301c7e3f6$c73fb6d0$11010a0a@bsoft007> Mime-Version: 1.0 (Apple Message framework v752.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5115C7A2-E934-40F0-8DD4-A8E47D1BA329@hhi.de> Content-Transfer-Encoding: 7bit From: Thomas Wiegand Subject: Re: [AVT] RTP streaming and adaptation to AVC of an SVC temporalscalable bitstream - Packet loss Date: Tue, 21 Aug 2007 15:50:00 +0200 To: daniele renzi (bsoft) X-Mailer: Apple Mail (2.752.3) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on mail.hhi.fraunhofer.de X-Spam-Level: X-Spam-Status: No, hits=-104.1 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=2.64 X-alterMIME: Yes X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: Ye-Kui.Wang@nokia.com, avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Daniele the SVC video spec is already finalized (AAP in ITU / ballot in ISO) and currently being processed towards publication. Wrt the RTP payload, please also consider the possibility to have a temporal scalable transmission in multiple RTP sessions, where one session contains the temporal base layer and the other session contains a copy signaling of the base layer (can be done in SVC with a few bytes) and the temporal enhancement layer. The two RTP session can be potentially merged into a single RFC 3984 session. Such a construction allows you to detect any loss on the RTP layer (sequence number) and the video layer (frame_num) (somewhat redundant provisions) Best Regards, Thomas --- Dr.-Ing. Thomas Wiegand Head, Image Communication Group Image Processing Department Fraunhofer Inst. for Telecommunications - HHI Einsteinufer 37, D-10587 Berlin, Germany Phone: +49 30 31002 617, Mobile: +49 172 381 3814 http: iphome.hhi.de/wiegand --- On Aug 21, 2007, at 3:25 PM, daniele renzi (bsoft) wrote: > Dear Ye Kui, all, > > just to highlight that my purpose was just to highlight a possible > critical scenario considering the already existing solutions and > emphasize what in my (negligible... :) ) opinion was the best > solution. > I'm aware that making changes to the SVC RTP payload draft (and > perhaps to the SVC video coding spec...) isn't maybe the best step > to perform at this stage and that we could simply rely on already > existing solutions. > > Anyway, any further opinion would be very appreciated. > > Thanks, > > BR > > Daniele > > Daniele Renzi > bSoft -- www.bsoft.info > +39-0733-57707 (tel/fax) > > ----- Original Message ----- From: > To: > Cc: > Sent: Tuesday, August 21, 2007 3:09 PM > Subject: RE: [AVT] RTP streaming and adaptation to AVC of an SVC > temporal scalable bitstream - Packet loss > > > > See also inline. I removed overhead text to make reading easier. > > The issue is now pretty clear. The question is whether to change the > payload structures to associate a 16-bit layer specific RTP sequence > number to each NAL unit, or rely on existing solutions. > > Personally I think we should not make the change to the SVC RTP > payload > draft as the change is needed to all types of packets. So Daniele you > would like to have this? > > Does anyone else there has an opinion? > > BR, YK > >>> - the streamer should keep a separate sequence number >> variable for any >>> of these layers (combination of temporal_id, dependency_id and >>> quality_id); >>> - separate sequence number variables don't mean different >> fields in the >>> RTP payload header (NALU header), as any NALU belongs to a specific >>> layer and not to other layers (1:1 mapping between NALU and layer); >>> - so, we'd have just one additional field in the NALU header >>> (16 bit, like sequence number in RTP); this field could be added >>> just >>> to the prefix NALUs syntax to save some bandwidth; this wouldn't >>> make >>> the RTP payload structure that ugly, at least in my opinion...; >> >> This is true if you never encapsulate NALUs with different >> values of DTQ in the same packet. >> >> [DR] That's why such layer-specific sequence number parameter >> should be added to any NALU, not to any packet . >> This way if you loose a packet you can track the loss of NALUs >> for any layer. > > Right. My misunderstanding that you meant to any packet. > >> >> But the thing gets complicated when considering aggregation >> packets, and more when considering interleaved packetization >> mode. But you are right that probably nobody would ever >> encapsulate NAL units from the maximum possible number of >> layers into one packet, therefore the number of layer specific >> sequence numbers would never reach the maximum, 8x8x16. But >> anyway, then a loop of layers is needed, and an ID of layer is >> needed in addition to each sequence number. >> >> [DR] The layer ID could be simply inferred by combining the >> DTQ values, then not added as a field in the payload header. >> Isn't that correct? > > Yes, that's right. > >> [DR] I agree with you, even though I still can't see how the >> adapter could deduce a loss by simply parsing the slice header >> and do not decoding the rest of the stream, e.g. estimating >> the number of decoded macroblocks and comparing it to the >> total number of MBs per picture or to first_mb_in_slice. > > After parsing slice header you then know the value of frame_num and > picture order count values. Then together with RTP sequence number > should be able to detect loss of pictures and slices. This is > simply as > the two solutions mentioned earlier. > > > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.484 / Virus Database: 269.12.1/963 - Release Date: > 20/08/2007 17:44 > > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > ---- Visit us at IFA 2007 / Berlin, 31 August - 5 September 2007 / Hall 5.3 Booth 17 http://www.hhi.fraunhofer.de/german/gf/events/index.html IBC 2007 / Amsterdam, 7 - 11 September 2007 / Booth 8.381 http://ip.hhi.de/ibc2007.html eslw 2007 / Berlin, 14 - 15 September 2007 / Fraunhofer Institute for Telecommunications, Heinrich-Hertz-Institut http://eslw2007.hhi.de/index.htm ECOC 2007 / Berlin, Exhibition 17 - 19 September 2007 / Booth 13007 - 13008 http://www.hhi.fraunhofer.de/german/gf/events/index.html _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Tue Aug 21 10:52:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INV3i-0006nC-RI; Tue, 21 Aug 2007 10:50:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INV3h-0006lP-Ck for avt@ietf.org; Tue, 21 Aug 2007 10:50:17 -0400 Received: from smtpd4.aruba.it ([62.149.128.209] helo=smtp4.aruba.it) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1INV3d-0004Ny-GJ for avt@ietf.org; Tue, 21 Aug 2007 10:50:17 -0400 Received: (qmail 14545 invoked by uid 89); 21 Aug 2007 14:50:10 -0000 Received: by simscan 1.1.0 ppid: 14526, pid: 14535, t: 0.3094s scanners: clamav: 0.88.4/m:40/d:1722 Received: from unknown (HELO bsoft007) (daniele@bsoft.info@151.71.165.253) by smtp4.aruba.it with SMTP; 21 Aug 2007 14:50:09 -0000 Message-ID: <00cb01c7e402$8caa0a50$11010a0a@bsoft007> From: "daniele renzi \(bsoft\)" To: "Thomas Wiegand" References: <008201c7e3e4$0e2dce00$11010a0a@bsoft007><1C1F3D15859526459B4DD0 A7A9B2268B03C1B455@trebe101.NOE.Nokia.com><009601c7e3ef$42c38ff0$11010a0a@b soft007><1C1F3D15859526459B4DD0A7A9B2268B03C1B598@trebe101.NOE.Nokia.com> <00b301c7e3f6$c73fb6d0$11010a0a@bsoft007> <5115C7A2-E934-40F0-8DD4-A8E47D1BA329@hhi.de> Subject: Re: [AVT] RTP streaming and adaptation to AVC of an SVC temporalscalable bitstream - Packet loss Date: Tue, 21 Aug 2007 16:49:59 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Rating: smtp4.aruba.it 1.6.2 0/1000/N X-Spam-Score: 0.0 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Thomas, thanks a lot for your suggestion, it looks pretty good for our case. Indeed I knew the SVC video spec is already finalized, that's the main reason why in my last email I emphasized my agreement on the fact that at this stage making changes is not the best solution... My idea was just a way for reasoning about a critical scenario. Thanks again. BR, Daniele Daniele Renzi bSoft -- www.bsoft.info +39-0733-57707 (tel/fax) ----- Original Message ----- From: "Thomas Wiegand" To: "daniele renzi (bsoft)" Cc: ; Sent: Tuesday, August 21, 2007 3:50 PM Subject: Re: [AVT] RTP streaming and adaptation to AVC of an SVC temporalscalable bitstream - Packet loss > Daniele > > the SVC video spec is already finalized (AAP in ITU / ballot in ISO) and > currently being processed towards publication. > > Wrt the RTP payload, please also consider the possibility to have a > temporal scalable transmission in multiple RTP sessions, where one > session contains the temporal base layer and the other session contains a > copy signaling of the base layer (can be done in SVC with a few bytes) > and the temporal enhancement layer. > > The two RTP session can be potentially merged into a single RFC 3984 > session. > > Such a construction allows you to detect any loss on the RTP layer > (sequence number) and the video layer (frame_num) (somewhat redundant > provisions) > > Best Regards, > Thomas > > --- > Dr.-Ing. Thomas Wiegand > Head, Image Communication Group > Image Processing Department > Fraunhofer Inst. for Telecommunications - HHI > Einsteinufer 37, D-10587 Berlin, Germany > Phone: +49 30 31002 617, > Mobile: +49 172 381 3814 > http: iphome.hhi.de/wiegand > --- > > > On Aug 21, 2007, at 3:25 PM, daniele renzi (bsoft) wrote: > >> Dear Ye Kui, all, >> >> just to highlight that my purpose was just to highlight a possible >> critical scenario considering the already existing solutions and >> emphasize what in my (negligible... :) ) opinion was the best solution. >> I'm aware that making changes to the SVC RTP payload draft (and perhaps >> to the SVC video coding spec...) isn't maybe the best step to perform at >> this stage and that we could simply rely on already existing solutions. >> >> Anyway, any further opinion would be very appreciated. >> >> Thanks, >> >> BR >> >> Daniele >> >> Daniele Renzi >> bSoft -- www.bsoft.info >> +39-0733-57707 (tel/fax) >> >> ----- Original Message ----- From: >> To: >> Cc: >> Sent: Tuesday, August 21, 2007 3:09 PM >> Subject: RE: [AVT] RTP streaming and adaptation to AVC of an SVC >> temporal scalable bitstream - Packet loss >> >> >> >> See also inline. I removed overhead text to make reading easier. >> >> The issue is now pretty clear. The question is whether to change the >> payload structures to associate a 16-bit layer specific RTP sequence >> number to each NAL unit, or rely on existing solutions. >> >> Personally I think we should not make the change to the SVC RTP payload >> draft as the change is needed to all types of packets. So Daniele you >> would like to have this? >> >> Does anyone else there has an opinion? >> >> BR, YK >> >>>> - the streamer should keep a separate sequence number >>> variable for any >>>> of these layers (combination of temporal_id, dependency_id and >>>> quality_id); >>>> - separate sequence number variables don't mean different >>> fields in the >>>> RTP payload header (NALU header), as any NALU belongs to a specific >>>> layer and not to other layers (1:1 mapping between NALU and layer); >>>> - so, we'd have just one additional field in the NALU header >>>> (16 bit, like sequence number in RTP); this field could be added just >>>> to the prefix NALUs syntax to save some bandwidth; this wouldn't make >>>> the RTP payload structure that ugly, at least in my opinion...; >>> >>> This is true if you never encapsulate NALUs with different >>> values of DTQ in the same packet. >>> >>> [DR] That's why such layer-specific sequence number parameter >>> should be added to any NALU, not to any packet . >>> This way if you loose a packet you can track the loss of NALUs >>> for any layer. >> >> Right. My misunderstanding that you meant to any packet. >> >>> >>> But the thing gets complicated when considering aggregation >>> packets, and more when considering interleaved packetization >>> mode. But you are right that probably nobody would ever >>> encapsulate NAL units from the maximum possible number of >>> layers into one packet, therefore the number of layer specific >>> sequence numbers would never reach the maximum, 8x8x16. But >>> anyway, then a loop of layers is needed, and an ID of layer is >>> needed in addition to each sequence number. >>> >>> [DR] The layer ID could be simply inferred by combining the >>> DTQ values, then not added as a field in the payload header. >>> Isn't that correct? >> >> Yes, that's right. >> >>> [DR] I agree with you, even though I still can't see how the >>> adapter could deduce a loss by simply parsing the slice header >>> and do not decoding the rest of the stream, e.g. estimating >>> the number of decoded macroblocks and comparing it to the >>> total number of MBs per picture or to first_mb_in_slice. >> >> After parsing slice header you then know the value of frame_num and >> picture order count values. Then together with RTP sequence number >> should be able to detect loss of pictures and slices. This is simply as >> the two solutions mentioned earlier. >> >> >> >> -- >> No virus found in this incoming message. >> Checked by AVG Free Edition. >> Version: 7.5.484 / Virus Database: 269.12.1/963 - Release Date: >> 20/08/2007 17:44 >> >> >> >> _______________________________________________ >> Audio/Video Transport Working Group >> avt@ietf.org >> https://www1.ietf.org/mailman/listinfo/avt >> > > ---- > Visit us at > > IFA 2007 / Berlin, 31 August - 5 September 2007 / Hall 5.3 Booth 17 > http://www.hhi.fraunhofer.de/german/gf/events/index.html > > IBC 2007 / Amsterdam, 7 - 11 September 2007 / Booth 8.381 > http://ip.hhi.de/ibc2007.html > > eslw 2007 / Berlin, 14 - 15 September 2007 / Fraunhofer Institute for > Telecommunications, Heinrich-Hertz-Institut > http://eslw2007.hhi.de/index.htm > > ECOC 2007 / Berlin, Exhibition 17 - 19 September 2007 / Booth 13007 - > 13008 > http://www.hhi.fraunhofer.de/german/gf/events/index.html > > > > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. Version: 7.5.484 / Virus Database: > 269.12.1/963 - Release Date: 20/08/2007 17:44 > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Tue Aug 21 11:50:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INVyS-0007Wx-N8; Tue, 21 Aug 2007 11:48:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INVyS-0007Wn-5x for avt@ietf.org; Tue, 21 Aug 2007 11:48:56 -0400 Received: from maild.telecomitalia.it ([156.54.233.30]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INVyR-0002u1-Lt for avt@ietf.org; Tue, 21 Aug 2007 11:48:56 -0400 Received: from ptpxch009ba020.idc.cww.telecomitalia.it ([156.54.240.52]) by maild.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Aug 2007 17:48:54 +0200 Received: from PTPEVS108BA020.idc.cww.telecomitalia.it ([156.54.241.228]) by ptpxch009ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Aug 2007 17:48:54 +0200 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2929 Content-Class: urn:content-classes:message MIME-Version: 1.0 Importance: normal Priority: normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Aug 2007 17:48:54 +0200 Message-ID: In-Reply-To: <00b301c7e3f6$c73fb6d0$11010a0a@bsoft007> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] RTP streaming and adaptation to AVC of an SVC temporalscalable bitstream - Packet loss thread-index: Acfj9tzsPPk+ClGESr2Z8QAZVXMgeQAECqhA From: "Franceschini Guido" To: X-OriginalArrivalTime: 21 Aug 2007 15:48:54.0176 (UTC) FILETIME=[C6EFD200:01C7E40A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Paltro Pier Carlo Subject: [AVT] Interop issue with H263-1998 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Dear all, I have an issue with the definition of the H263-1998 media type. In the RFC 2429, no optional parameters are defined, implying that any = valid H263+ stream could be streamed. In the RFC 4629, that obsoletes 2429, various optional parameters are = specified, which allow specifying the (decoder) support to the various = annexes. What confuses me is the following statement in RFC 4629, concerning = H263-1998 Interoperability considerations: These are receiver options; current implementations will not send any optional parameters in their SDP. They will ignore the optional parameters and will *** encode the H.263 stream without = any *** of the annexes. Most decoders support at least QCIF and CIF fixed resolutions, and they are expected to be available almost in every H.263-based video application. Indeed my understanding would be quite different, and I would have = written instead: These are receiver options; current implementations will not send any optional parameters in their SDP. They will ignore the optional parameters and will *** encode the H.263+ stream with = possibly all *** of the annexes. Most decoders support at least QCIF and CIF fixed resolutions, and they are expected to be available almost in every H.263-based video application. Any clarification would be welcomed Best regards Guido Franceschini -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons = above and may contain confidential information. If you have received the = message in error, be informed that any use of the content hereof is = prohibited. Please return it immediately to the sender and delete the = message. Should you have any questions, please contact us by replying to = webmaster@telecomitalia.it. Thank you www.telecomitalia.it -------------------------------------------------------------------- =20 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Wed Aug 22 18:17:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INyUG-0001I3-Do; Wed, 22 Aug 2007 18:15:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INyU9-000197-Nl; Wed, 22 Aug 2007 18:15:33 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INyU9-0002zT-Al; Wed, 22 Aug 2007 18:15:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id EAA1A175F4; Wed, 22 Aug 2007 22:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1INyTe-0007Pm-CI; Wed, 22 Aug 2007 18:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 22 Aug 2007 18:15:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-atrac-family-10.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , 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 : RTP Payload Format for Adaptive TRansform Acoustic Coding (ATRAC) Family Author(s) : J. Matsumoto, M. Hatanaka Filename : draft-ietf-avt-rtp-atrac-family-10.txt Pages : 29 Date : 2007-8-22 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-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-atrac-family-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-atrac-family-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-8-22171123.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-atrac-family-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-atrac-family-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-8-22171123.I-D@ietf.org> --OtherAccess-- --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://www1.ietf.org/mailman/listinfo/avt --NextPart-- From avt-bounces@ietf.org Thu Aug 23 07:29:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOAr3-0003AX-AF; Thu, 23 Aug 2007 07:28:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOAr2-0003AR-4D for avt@ietf.org; Thu, 23 Aug 2007 07:28:00 -0400 Received: from ns6.sony.co.jp ([137.153.0.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOAr0-0003PK-7M for avt@ietf.org; Thu, 23 Aug 2007 07:28:00 -0400 Received: from mail3.sony.co.jp ([43.0.1.203]) Received: from mail3.sony.co.jp (localhost [127.0.0.1]) by mail3.sony.co.jp (R8/Sony) with ESMTP id l7NBRoJ1011039 for ; Thu, 23 Aug 2007 20:27:50 +0900 (JST) Received: from jptkyxim02.jp.sony.com (jptkyxim02.jp.sony.com [43.15.17.88]) by mail3.sony.co.jp (R8/Sony) with ESMTP id l7NBRnqF011035 for ; Thu, 23 Aug 2007 20:27:49 +0900 (JST) Received: from jptkyxwa01.jp.sony.com ([43.15.31.1]) by jptkyxim02.jp.sony.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 23 Aug 2007 20:27:51 +0900 Received: from avhta.av.crl.sony.co.jp ([43.4.150.188]) by jptkyxwa01.jp.sony.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 23 Aug 2007 20:27:50 +0900 Message-Id: <5.1.1.9.2.20070823104914.00d2c170@pop.jp.sony.com> X-Sender: jp\jp05992@pop.jp.sony.com X-Mailer: QUALCOMM Windows Eudora Version 5.1-Jr4 Date: Thu, 23 Aug 2007 11:00:07 +0900 To: avt@ietf.org From: Mitsuyuki Hatanaka Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-rtp-atrac-family-10.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Aug 2007 11:27:50.0909 (UTC) FILETIME=[A3BA72D0:01C7E578] X-Spam-Score: 1.9 (+) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Dear AVT member, We have submitted our revised internet draft as "draft-ietf-avt-rtp-atracx-family-10.txt". You will be able to get it from the on-line Internet-Drafts directories. The revised points are as follows. (1) The description of decoder control was added in section 4.5.2, in response to the case that the number of base and enhancement layer incoming packet is not identical at the presentation time in scalable multi-session streaming. (2) The explanation of "Marker" was modified in Section 5.2. (3) The description of "Timestamp" for ATRAC Advanced Lossless was added in section 5.2. (4) The description of "Subtype name" was deleted correspinding to the elimination of vendor tree registration for ATRAC3, ATRAC-X and ATRAC Advanced Lossless in Section 7.1, 7.2 and 7.3 respectively. (5) The description of "rate" for ATRAC3 was added in Section 7.1. (6) The description of "Security Consideration" was modified from Section 7.1 through Section 7.3. (7) Referenced standard information was modified in Section 9. Best regards, Mitsuyuki Hatanaka _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Aug 23 07:30:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOAs9-00043D-Do; Thu, 23 Aug 2007 07:29:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOAs8-000438-Db for avt@ietf.org; Thu, 23 Aug 2007 07:29:08 -0400 Received: from wa-out-1112.google.com ([209.85.146.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOAs7-0003QY-5z for avt@ietf.org; Thu, 23 Aug 2007 07:29:08 -0400 Received: by wa-out-1112.google.com with SMTP id m16so548929waf for ; Thu, 23 Aug 2007 04:29:06 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=XV7asjeJbCDy7rjkKZD60dclcw/FKOXr93pBLv6HU75iLHcYWpH8hihb8rAgyA97ZtKu5vfEE+UPJqS+/QB8Zt4EvPWhi802enmG46F9vSnA9Kik0GyH/VTCChCJ6CK/5jPHumeH2oLD6DSzHtew7+ArXWsNPDUE49wkNZwgP5U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=nKEhBzmyJm/voIrYT9Kp++yHt8jUIxNHBoJjKQSl+trZtNxadRZ5pdw4sXs+OasI6fgnHyB4ZL40JzCSqomC5KBjAov7empkiNZ+t4nzHgWgvYtqjAwNmIZ1nPTkP2lGsQ/tAxoKra+bhIKq3Ouwg3kiUO+5c4o81ozOp7FBA/Q= Received: by 10.114.144.1 with SMTP id r1mr1963691wad.1187868545613; Thu, 23 Aug 2007 04:29:05 -0700 (PDT) Received: by 10.115.92.8 with HTTP; Thu, 23 Aug 2007 04:29:05 -0700 (PDT) Message-ID: <7e4b541c0708230429q21bb215ey59252cbcc6489888@mail.gmail.com> Date: Thu, 23 Aug 2007 13:29:05 +0200 From: "Tom Kristensen" <2mkristensen@gmail.com> To: "Randell Jesup" Subject: Re: [AVT] RFC 3984 offer/answer Question In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <144ED8561CE90C41A3E5908EDECE315C04D44EBE@IsrExch01.israel.polycom.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: stewe@stewe.org, Yuval Nissan , "Even, Roni" , Ilan Avner , avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org On 16/08/07, Randell Jesup wrote: > "Even, Roni" writes: > >I went back to the mailing list and found the attached email. > >It is in line with my thought that the level can be downgraded > > Darn! :-) I knew this whole conversation sounded familiar. I remember > (now) seeing that, and in fact I've kept the article "ticked" in Gnus > so it doesn't disappear on me. > > There really should be an rfc 3984bis (or at least an informational RFC; I > don't know how this is supposed to work); everyone who comes to read it > without searching the mail-archives will make the same set of mistakes and > mis-readings. Agree! However, reading the RFC3984 carefully reveals the "hidden statement" on level part being downgradable. -- Tom -- # TANDBERG R&D ## http://www.tandberg.com ### http://folk.uio.no/tomkri/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Aug 23 11:08:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOEGT-0007iG-Av; Thu, 23 Aug 2007 11:06:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOEGR-0007iA-UG for avt@ietf.org; Thu, 23 Aug 2007 11:06:27 -0400 Received: from an-out-0708.google.com ([209.85.132.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOEGR-0008Bw-MU for avt@ietf.org; Thu, 23 Aug 2007 11:06:27 -0400 Received: by an-out-0708.google.com with SMTP id c17so56605anc for ; Thu, 23 Aug 2007 08:06:27 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=AClGKsO0geovs0LYGXB+ysc2lDJCNKKzmqqDkkE5fZl5FReh6g9YxYrUBqcV64/aNCMYLR6XmQii691W7Pd/Ey7fODkNRnrRXQk8MA62+RWCI9ifXNiftwLll7Qn8BguCk3IbEW8eLVuSjO2qQ5v/NbSF8+MB2Rq3Y/es3UFihM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=Cig94Mo30YSr50OqYsLTgWgOaxDyzjnzXSWQR8bH9yuBvah1gnkpNZXnQpR3zTzU1o7bDUqpcW7yycYitluOQVHx0/Q+ChFz/0Trsyro63JZTrciXk8b6VqAD59R8iD+s1Pi0de1rQS63KK3T3n3B1eGPwuScrlF7jrj7bs427U= Received: by 10.90.68.15 with SMTP id q15mr3578753aga.1187881587027; Thu, 23 Aug 2007 08:06:27 -0700 (PDT) Received: by 10.100.140.2 with HTTP; Thu, 23 Aug 2007 08:06:26 -0700 (PDT) Message-ID: Date: Thu, 23 Aug 2007 11:06:27 -0400 From: Ram To: avt@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [AVT] MPEG4 with short video header X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0305189313==" Errors-To: avt-bounces@ietf.org --===============0305189313== Content-Type: multipart/alternative; boundary="----=_Part_4706_28567261.1187881587000" ------=_Part_4706_28567261.1187881587000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi there, I am trying to find out how an endpoint signals that it's using MPEG4 with short video header. The reason I am asking is that in the RTP depack side I need to know if MPEG4 with short video header is used so that I can use the appropriate depacketization routine corresponding to RFC2429/RFC2190. Thanks for the help, R.. ------=_Part_4706_28567261.1187881587000 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

Hi there,
 
I am trying to find out how an endpoint signals that it's using MPEG4 with short video header. The reason  I am asking is that in the RTP depack side I need to know if MPEG4 with short video
header is used so that I can use the appropriate depacketization routine corresponding to RFC2429/RFC2190.
 
Thanks for the help,
 
R..
 
------=_Part_4706_28567261.1187881587000-- --===============0305189313== 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://www1.ietf.org/mailman/listinfo/avt --===============0305189313==-- From avt-bounces@ietf.org Thu Aug 23 17:17:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOK1m-00020Y-7h; Thu, 23 Aug 2007 17:15:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOK1d-0001qm-6W; Thu, 23 Aug 2007 17:15:33 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IOK1c-00044a-Pl; Thu, 23 Aug 2007 17:15:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 67C6D175CA; Thu, 23 Aug 2007 21:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IOK17-0002C7-SR; Thu, 23 Aug 2007 17:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 23 Aug 2007 17:15:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-vorbis-07.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , 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 : RTP Payload Format for Vorbis Encoded Audio Author(s) : L. Barbato Filename : draft-ietf-avt-rtp-vorbis-07.txt Pages : 25 Date : 2007-8-23 This document describes an RTP payload format for transporting Vorbis encoded audio. It details the RTP encapsulation mechanism for raw Vorbis data and details the delivery mechanisms for the decoder probability model, referred to as a codebook and other setup information. Also included within this memo are media type registrations, and the details necessary for the use of Vorbis with the Session Description Protocol (SDP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-vorbis-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-vorbis-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-vorbis-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-8-23162317.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-vorbis-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-vorbis-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-8-23162317.I-D@ietf.org> --OtherAccess-- --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://www1.ietf.org/mailman/listinfo/avt --NextPart-- From avt-bounces@ietf.org Mon Aug 27 18:23:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPmxv-00063R-GJ; Mon, 27 Aug 2007 18:21:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPmxu-00063J-Bo; Mon, 27 Aug 2007 18:21:46 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPmxt-0007lZ-7z; Mon, 27 Aug 2007 18:21:46 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 2723332883; Mon, 27 Aug 2007 22:21:15 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IPmxP-00009w-1u; Mon, 27 Aug 2007 18:21:15 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 27 Aug 2007 18:21:15 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Internet Architecture Board , avt mailing list , avt chair , RFC Editor Subject: [AVT] Protocol Action: 'Multiplexing RTP Data and Control Packets on a Single Port' to Proposed Standard X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org The IESG has approved the following document: - 'Multiplexing RTP Data and Control Packets on a Single Port ' as a Proposed Standard This document is the product of the Audio/Video Transport Working Group. The IESG contact persons are Cullen Jennings and Jon Peterson. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-and-rtcp-mux-07.txt Technical Summary This memo discusses issues that arise when multiplexing RTP data packets and RTP control protocol (RTCP) packets on a single UDP port. It updates RFC 3550 to describe when such multiplexing is, and is not, appropriate, and explains how the Session Description Protocol (SDP) can be used to signal multiplexed sessions. Working Group Summary This document represents a solid consensus of the AVT Working Group, with informal concurrence of the MMUSIC and BEHAVE Working Groups. Following the initial proposal, the major issue subsequently considered and resolved was how to negotiate the multiplexing capability and achieve fail-safe behavior. The decision was to provide a new SDP attribute to signal the multiplexing capability explicitly. There was also some discussion of how to signal bandwidth requirements. The outcome was a decision to include allowance for RTCP traffic in the b=AS: value. Document Quality The document has attracted considerable interest because it makes NAT traversal easier. Jonathan Rosenberg, author of the ICE document, reviewed the proposal in terms of its interaction with ICE and provided related text. Randell Jesup deserves special mention for his careful reviews of successive versions of the document and persistence in analysis of the associated signaling issues. Personnel Document Shepherd was Tom Taylor. Responsible Area Director was Cullen Jennings. Note to RFC Editor Please change this document so that it also updates RFC 3551. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Tue Aug 28 15:17:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ6Wy-0006mp-KU; Tue, 28 Aug 2007 15:15:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ6Wl-0006ih-8v; Tue, 28 Aug 2007 15:15:03 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQ6Wk-0005Fs-4I; Tue, 28 Aug 2007 15:15:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 0A45232898; Tue, 28 Aug 2007 19:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IQ6Wj-0006ve-TN; Tue, 28 Aug 2007 15:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 28 Aug 2007 15:15:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-rfc4695-bis-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , 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 : RTP Payload Format for MIDI Author(s) : J. Lazzaro, J. Wawrzynek Filename : draft-ietf-avt-rfc4695-bis-02.txt Pages : 183 Date : 2007-8-28 This memo describes a Real-time Transport Protocol (RTP) payload format for the MIDI (Musical Instrument Digital Interface) command language. The format encodes all commands that may legally appear on a MIDI 1.0 DIN cable. The format is suitable for interactive applications (such as network musical performance) and content- delivery applications (such as file streaming). The format may be used over unicast and multicast UDP and TCP, and it defines tools for graceful recovery from packet loss. Stream behavior, including the MIDI rendering method, may be customized during session setup. The format also serves as a mode for the mpeg4-generic format, to support the MPEG 4 Audio Object Types for General MIDI, Downloadable Sounds Level 2, and Structured Audio. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc4695-bis-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rfc4695-bis-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rfc4695-bis-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-8-28142357.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rfc4695-bis-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rfc4695-bis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-8-28142357.I-D@ietf.org> --OtherAccess-- --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://www1.ietf.org/mailman/listinfo/avt --NextPart-- From avt-bounces@ietf.org Tue Aug 28 16:17:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ7St-0005en-GX; Tue, 28 Aug 2007 16:15:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ7Sp-0005dO-5O; Tue, 28 Aug 2007 16:15:03 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQ7So-0008FZ-0h; Tue, 28 Aug 2007 16:15:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id F337932899; Tue, 28 Aug 2007 20:15:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IQ7Sn-0006vo-Sp; Tue, 28 Aug 2007 16:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 28 Aug 2007 16:15:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-toffset-06.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , 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 : Transmission Time offsets in RTP streams Author(s) : H. Desineni, D. Singer Filename : draft-ietf-avt-rtp-toffset-06.txt Pages : 16 Date : 2007-8-28 This document describes a method to inform RTP clients when RTP packets are transmitted at a time other than their 'nominal' transmission time. It also provides a mechanism to provide improved inter-arrival jitter reports from the clients, that take into account the reported transmission times. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-toffset-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-toffset-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-toffset-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-8-28150113.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-toffset-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-toffset-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-8-28150113.I-D@ietf.org> --OtherAccess-- --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://www1.ietf.org/mailman/listinfo/avt --NextPart-- From avt-bounces@ietf.org Tue Aug 28 16:17:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ7T6-00062F-C9; Tue, 28 Aug 2007 16:15:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ7Sp-0005dm-Im; Tue, 28 Aug 2007 16:15:03 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQ7Sp-0006ue-45; Tue, 28 Aug 2007 16:15:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 94C0F1759D; Tue, 28 Aug 2007 20:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IQ7Sn-0006vu-UQ; Tue, 28 Aug 2007 16:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 28 Aug 2007 16:15:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-hdrext-13.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , 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 : A general mechanism for RTP Header Extensions Author(s) : H. Desineni, D. Singer Filename : draft-ietf-avt-rtp-hdrext-13.txt Pages : 24 Date : 2007-8-28 This document provides a general mechanism to use the header- extension feature of RTP (the Real Time Transport Protocol). It provides the option to use a small number of small extensions in each RTP packet, where the universe of possible extensions is large and registration is de-centralized. The actual extensions in use in a session are signaled in the setup information for that session. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-hdrext-13.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-hdrext-13.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-hdrext-13.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-8-28150218.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-hdrext-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-hdrext-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-8-28150218.I-D@ietf.org> --OtherAccess-- --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://www1.ietf.org/mailman/listinfo/avt --NextPart-- From avt-bounces@ietf.org Tue Aug 28 16:17:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ7T0-0005of-TL; Tue, 28 Aug 2007 16:15:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ7Sp-0005do-Iy; Tue, 28 Aug 2007 16:15:03 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQ7So-0008Fa-6i; Tue, 28 Aug 2007 16:15:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 158F826E71; Tue, 28 Aug 2007 20:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IQ7Sn-0006w0-Vq; Tue, 28 Aug 2007 16:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 28 Aug 2007 16:15:01 -0400 X-Spam-Score: -1.4 (-) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-smpte-rtp-11.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , 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 : Associating Time-codes with RTP streams Author(s) : D. Singer Filename : draft-ietf-avt-smpte-rtp-11.txt Pages : 21 Date : 2007-8-28 This document describes a mechanism for associating time-codes, as defined by the Society of Motion Picture and Television Engineers (SMPTE), with media streams, in a way that is independent of the RTP payload format of the media stream itself. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-smpte-rtp-11.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-smpte-rtp-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-smpte-rtp-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-8-28150314.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-smpte-rtp-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-smpte-rtp-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-8-28150314.I-D@ietf.org> --OtherAccess-- --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://www1.ietf.org/mailman/listinfo/avt --NextPart-- From avt-bounces@ietf.org Tue Aug 28 16:26:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ7b9-0005vm-Ks; Tue, 28 Aug 2007 16:23:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ7b8-0005vT-Pq for avt@ietf.org; Tue, 28 Aug 2007 16:23:38 -0400 Received: from mail-out4.apple.com ([17.254.13.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQ7b7-0000lM-Bp for avt@ietf.org; Tue, 28 Aug 2007 16:23:38 -0400 Received: from relay12.apple.com (relay12.apple.com [17.128.113.53]) by mail-out4.apple.com (Postfix) with ESMTP id CCA98100C4D4 for ; Tue, 28 Aug 2007 13:23:36 -0700 (PDT) Received: from relay12.apple.com (unknown [127.0.0.1]) by relay12.apple.com (Symantec Mail Security) with ESMTP id B332828342 for ; Tue, 28 Aug 2007 13:23:36 -0700 (PDT) X-AuditID: 11807135-a61c6bb000000f40-3f-46d484489d49 Received: from [17.202.35.52] (singda.apple.com [17.202.35.52]) by relay12.apple.com (Symantec Mail Security) with ESMTP id 681552828E for ; Tue, 28 Aug 2007 13:23:36 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 28 Aug 2007 13:22:59 -0700 To: avt@ietf.org From: Dave Singer Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-rtp-hdrext-13.txt, and smpte and toffset drafs Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -4.0 (----) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org These three new versions should deal with the final concerns and so on, raised by this WG, the ADs, and other experts. details of the changes are below, after each draft At 16:15 -0400 28/08/07, Internet-Drafts@ietf.org wrote: >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 : A general mechanism for RTP Header Extensions > Author(s) : H. Desineni, D. Singer > Filename : draft-ietf-avt-rtp-hdrext-13.txt > Pages : 24 > Date : 2007-8-28 > >This document provides a general mechanism to use the header- > extension feature of RTP (the Real Time Transport Protocol). It > provides the option to use a small number of small extensions in each > RTP packet, where the universe of possible extensions is large and > registration is de-centralized. The actual extensions in use in a > session are signaled in the setup information for that session. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-hdrext-13.txt > Now permits the same extension, differently parameterized, to be used more than once per stream (needed for some SMPTE TC cases) Even more clear that the extension cannot affect the decodability of the packet stream Restricts IANA registered extensions to those using IETF URNs, and restricts IETF URNs toextensions documented in RFCs A paragraph on the impact of header compression was inserted (thanks to Colin). ABNF fixed as per Magnus (I went with his byte-string alternative choice) >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 : Associating Time-codes with RTP streams > Author(s) : D. Singer > Filename : draft-ietf-avt-smpte-rtp-11.txt > Pages : 21 > Date : 2007-8-28 > >This document describes a mechanism for associating time-codes, as > defined by the Society of Motion Picture and Television Engineers > (SMPTE), with media streams, in a way that is independent of the RTP > payload format of the media stream itself. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-avt-smpte-rtp-11.txt > There was a minor improvement in wording in one place >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 : Transmission Time offsets in RTP streams > Author(s) : H. Desineni, D. Singer > Filename : draft-ietf-avt-rtp-toffset-06.txt > Pages : 16 > Date : 2007-8-28 > >This document describes a method to inform RTP clients when RTP > packets are transmitted at a time other than their 'nominal' > transmission time. It also provides a mechanism to provide improved > inter-arrival jitter reports from the clients, that take into account > the reported transmission times. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-toffset-06.txt > Re-uploaded with only the date and version changed, as it was about to expire. -- David Singer Apple/QuickTime _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Tue Aug 28 17:00:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ889-0007uZ-2x; Tue, 28 Aug 2007 16:57:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ887-0007pW-Oi for avt@ietf.org; Tue, 28 Aug 2007 16:57:43 -0400 Received: from mail-out3.apple.com ([17.254.13.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQ886-0001p8-9M for avt@ietf.org; Tue, 28 Aug 2007 16:57:43 -0400 Received: from relay12.apple.com (relay12.apple.com [17.128.113.53]) by mail-out3.apple.com (Postfix) with ESMTP id 3434FFAC122 for ; Tue, 28 Aug 2007 13:57:39 -0700 (PDT) Received: from relay12.apple.com (unknown [127.0.0.1]) by relay12.apple.com (Symantec Mail Security) with ESMTP id 1C5EE281C7 for ; Tue, 28 Aug 2007 13:57:39 -0700 (PDT) X-AuditID: 11807135-a99cdbb000000f40-18-46d48c428b15 Received: from [17.202.35.52] (singda.apple.com [17.202.35.52]) by relay12.apple.com (Symantec Mail Security) with ESMTP id C3626280E6 for ; Tue, 28 Aug 2007 13:57:38 -0700 (PDT) Mime-Version: 1.0 Message-Id: Date: Tue, 28 Aug 2007 13:55:54 -0700 To: avt@ietf.org From: Dave Singer Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-rtp-hdrext-13.txt, and smpte and toffset drafs Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -4.0 (----) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org [oops, one line was missing in the previous summary, sorry; please ignore that and read this email!] These three new versions should deal with the final concerns and so on, raised by this WG, the ADs, and other experts. details of the changes are below, after each draft At 16:15 -0400 28/08/07, Internet-Drafts@ietf.org wrote: >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 : A general mechanism for RTP Header Extensions > Author(s) : H. Desineni, D. Singer > Filename : draft-ietf-avt-rtp-hdrext-13.txt > Pages : 24 > Date : 2007-8-28 > >This document provides a general mechanism to use the header- > extension feature of RTP (the Real Time Transport Protocol). It > provides the option to use a small number of small extensions in each > RTP packet, where the universe of possible extensions is large and > registration is de-centralized. The actual extensions in use in a > session are signaled in the setup information for that session. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-hdrext-13.txt > Now permits the same extension, differently parameterized, to be used more than once per stream (needed for some SMPTE TC cases) Even more clear that the extension cannot affect the decodability of the packet stream Restricts IANA registered extensions to those using IETF URNs, and restricts IETF URNs toextensions documented in RFCs A paragraph on the impact of header compression was inserted (thanks to Colin). Variant two-byte header optional form added. ABNF fixed as per Magnus (I went with his byte-string alternative choice) >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 : Associating Time-codes with RTP streams > Author(s) : D. Singer > Filename : draft-ietf-avt-smpte-rtp-11.txt > Pages : 21 > Date : 2007-8-28 > >This document describes a mechanism for associating time-codes, as > defined by the Society of Motion Picture and Television Engineers > (SMPTE), with media streams, in a way that is independent of the RTP > payload format of the media stream itself. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-avt-smpte-rtp-11.txt > There was a minor improvement in wording in one place >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 : Transmission Time offsets in RTP streams > Author(s) : H. Desineni, D. Singer > Filename : draft-ietf-avt-rtp-toffset-06.txt > Pages : 16 > Date : 2007-8-28 > >This document describes a method to inform RTP clients when RTP > packets are transmitted at a time other than their 'nominal' > transmission time. It also provides a mechanism to provide improved > inter-arrival jitter reports from the clients, that take into account > the reported transmission times. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-toffset-06.txt > Re-uploaded with only the date and version changed, as it was about to expire. -- David Singer Apple/QuickTime _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Tue Aug 28 17:33:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ8ec-0005Fa-T9; Tue, 28 Aug 2007 17:31:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ8eb-0005Dv-Ce for avt@ietf.org; Tue, 28 Aug 2007 17:31:17 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQ8ea-0001Bg-St for avt@ietf.org; Tue, 28 Aug 2007 17:31:17 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 28 Aug 2007 14:31:16 -0700 X-IronPort-AV: i="4.19,318,1183359600"; d="scan'208"; a="208204942:sNHT46671975" 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 l7SLVGgl016585; Tue, 28 Aug 2007 14:31:16 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-1.cisco.com (8.12.10/8.12.6) with SMTP id l7SLV6l8024569; Tue, 28 Aug 2007 21:31:15 GMT References: Mime-Version: 1.0 (Apple Message framework v752.3) Impp: xmpp:cullenfluffyjennings@jabber.org Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Tue, 28 Aug 2007 14:29:43 -0700 To: avt@ietf.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2521; t=1188336676; x=1189200676; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Help=20with=20DVM=20and=20AV3=20entries=20in=20wave-avi=20reg istry |Sender:=20; bh=KZqZn0MkhoP99y/kA6dkzSPtB+3dTgUY+JJgaRDGPUY=; b=bolYLjGJtdlh28YraowDumJk/qz/Qhj+D6h7WUX1O3tlxTUavshLkyz3ET31u6291T9k2A9D 9+QCqv40zGMPJ5IoxJlCXMpTCoTV8gV12wDaP0rrcP/HR/9m4LAT/Sb8; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: shawn@vrfarchive.com Subject: [AVT] Help with DVM and AV3 entries in wave-avi registry X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Hi All, Shawn pointed out there could be a problem here. Can anyone provide definitive references for these or pointers on how to solve it? Thanks, Cullen The registry is at http://www.iana.org/assignments/wave-avi-codec- registry Begin forwarded message: > From: "Michelle Cotton via RT" > Date: August 28, 2007 10:38:41 AM PDT > Cc: jon.peterson@neustar.biz, fluffy@cisco.com > Subject: [IANA #97962] Codec registry inaccuracies > Reply-To: iana-matrix@icann.org > > Jon and Cullen, > > Thomas Narten suggested maybe this is a RAI area item, so I'm > checking with you both to see if you can > assist. > > We received the below inquiry about 2 registrations being incorrect > in the following registry: > http://www.iana.org/wave-avi-codec-registry > > Specifically: Dolby AC3 SPDIF 0x0092 > DVM 0x2000 > > See specifics below in his message. > > I don't believe we have made any updates to this registry since > I've been here accept for format edits > (not content). > > Any ideas on how this should be corrected? > These are all documented in RFC 2361. > http://www.rfc-editor.org/rfc/rfc2361.txt > > Any input you have would be great, even if it is pointing us to > someone else :) > > Thanks, > > Michelle > IANA > > > On Mon Aug 13 18:16:20 2007, shawn@vrfarchive.com wrote: >>> Can you provide the URL for which registry you are referring to? >> >> Sure thing: >> >> http://www.iana.org/assignments/wave-avi-codec-registry >> >> It seems that AC3 and DVM are mixed up. Or at least, I know a Format >> Tag of 0x2000 means AC3 for sure. >> >> I found this because of an AVI that wouldn't play sound. It's tag was >> 0x2000 and I looked it up in the registry (which identifies it as >> DVM). I searched for the namespace type (audio/ >> vnd.wave;codec=2000) >> and found this: >> >> http://forum.doom9.org/archive/index.php/t-34712.html >> >> [quote] >> For instance, Tag2000 is AC3, yet in the RFC, AC3 is listed as Tag92. >> It is the only listing for AC3 in the RFC : >> [snip] >> Furthermore, tag2000 is in the list, but is listed as DVM. What in >> the >> world is DVM? >> [/quote] >> >> I'd like to provide an automatic codec download service, and I >> planned >> on using RFC 2361 as a reference. I can easily swap these two, but >> I'm wondering if there are other entries that need fixing. >> -SHAWN- >> >> > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Tue Aug 28 18:37:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ9ed-00025I-Hc; Tue, 28 Aug 2007 18:35:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ9ec-00025D-RN for avt@ietf.org; Tue, 28 Aug 2007 18:35:22 -0400 Received: from gateway0.eecs.berkeley.edu ([169.229.60.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQ9eb-0003kN-A8 for avt@ietf.org; Tue, 28 Aug 2007 18:35:22 -0400 Received: from [128.32.34.73] (dhcp-34-73.CS.Berkeley.EDU [128.32.34.73]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.1/8.13.5) with ESMTP id l7SMZJog008245 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 28 Aug 2007 15:35:20 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: lazzaro Date: Tue, 28 Aug 2007 15:35:17 -0700 To: avt@ietf.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: lazzaro Subject: [AVT] Re: I-D ACTION:draft-ietf-avt-rfc4695-bis-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Hello everyone, rfc4695-bis-01.txt was about to expire, and so I released rfc4695-bis-02.txt today. No changes except for the name update. The plan is to keep this I-D alive for a few more 6-month cycles, while we wait to see if there are more errata discovered by implementors ... --- John Lazzaro http://www.cs.berkeley.edu/~lazzaro lazzaro [at] cs [dot] berkeley [dot] edu --- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Wed Aug 29 02:58:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQHTV-0005mG-Lj; Wed, 29 Aug 2007 02:56:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQHTQ-0005kI-5A for avt@ietf.org; Wed, 29 Aug 2007 02:56:20 -0400 Received: from pcsmail.patni.com ([203.189.177.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQHTO-0006yv-1g for avt@ietf.org; Wed, 29 Aug 2007 02:56:19 -0400 Received: from EXCHSPZ01.patni.com ([192.168.153.41]) by pcsmail.patni.com (8.13.4/8.13.4) with ESMTP id l7T6pTmw014131 for ; Wed, 29 Aug 2007 12:21:34 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 29 Aug 2007 12:28:39 +0530 Message-ID: <556AA45B0A282049B352EA5300311522F1DA61@EXCHSPZ01.patni.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Regarding 'broadcasters sharing the same port' Thread-Index: AcfqCgdMBDUPq095SoSH9OnAUaa7wg== From: "Padgaonkar, Leena" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Subject: [AVT] Regarding 'broadcasters sharing the same port' X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0161474965==" Errors-To: avt-bounces@ietf.org This is a multi-part message in MIME format. --===============0161474965== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7EA0A.09187426" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7EA0A.09187426 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hello !! We are announcing SDP from broadcaster to specific port on Darwin Streaming Server . With the help of this announced SDP, client is able to receive the Media.=20 =20 My query is "Can two broadcasters use the same port on the Darwin Streaming Server to stream the media data ?" =20 =20 =20 =20 Regards Leena ------_=_NextPart_001_01C7EA0A.09187426 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hello !!

  We are announcing SDP from broadcaster to = specific port on Darwin Streaming Server . With the help = of

this announced SDP, client is able to receive the = Media.

 

My query is “Can two broadcasters use the same = port on the Darwin Streaming Server to stream the media data = ?”

 

 

 

 

Regards

Leena

------_=_NextPart_001_01C7EA0A.09187426-- --===============0161474965== 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://www1.ietf.org/mailman/listinfo/avt --===============0161474965==-- From avt-bounces@ietf.org Wed Aug 29 05:43:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQK3G-0006Hl-N8; Wed, 29 Aug 2007 05:41:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQK3F-0006Hd-In for avt@ietf.org; Wed, 29 Aug 2007 05:41:29 -0400 Received: from mu-out-0910.google.com ([209.85.134.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQK3E-0001fe-AA for avt@ietf.org; Wed, 29 Aug 2007 05:41:29 -0400 Received: by mu-out-0910.google.com with SMTP id w8so160724mue for ; Wed, 29 Aug 2007 02:41:27 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=e91JmCI4EDd4sCW4YeD8PlQzlIzsWvEiyFQ+xcUHS84kFlSztyWrrt6CvAaNib8h7PZOSrUdw+K6TlGhBl+kwHvLXtZ63BN9o1duRby8qN8kwed6lzWlCtgwjeYZGI4llIgv88DFcCBd6LwR6jBWPxmUxdDH+o7StO/OuDhFHNk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jq9Q8SVGga3m6xwr8qnN4hdSBSnvfioIMOH0+eSiZcv/nSvBGhsVXz3jq8qoyEyNoZqF1/Ocgu8Qba+fybZISb7dGItA2G32/X6k6F34He9tSRg64uV0LZmB50Vfu3FBNJvb04B2T3ZtCRQKeiIF1ZwuuFiBHVjuIhJCAM077i0= Received: by 10.82.165.13 with SMTP id n13mr975358bue.1188380487036; Wed, 29 Aug 2007 02:41:27 -0700 (PDT) Received: by 10.82.157.1 with HTTP; Wed, 29 Aug 2007 02:41:27 -0700 (PDT) Message-ID: Date: Wed, 29 Aug 2007 05:41:27 -0400 From: "Marshall Eubanks" To: "Padgaonkar, Leena" Subject: Re: [AVT] Regarding 'broadcasters sharing the same port' In-Reply-To: <556AA45B0A282049B352EA5300311522F1DA61@EXCHSPZ01.patni.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <556AA45B0A282049B352EA5300311522F1DA61@EXCHSPZ01.patni.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Hello; This is a protocol development list, and such questions are inappropriate here. You should ask this on the Apple Streaming Server users lists - see http://lists.apple.com/mailman/listinfo/streaming-server-users http://lists.apple.com/mailman/listinfo http://lists.apple.com/ for more detail. I am on the streaming-server-users list and it is very active. Regards Marshall On 8/29/07, Padgaonkar, Leena wrote: > > > > > Hello !! > > > > We are announcing SDP from broadcaster to specific port on Darwin > Streaming Server . With the help of > > this announced SDP, client is able to receive the Media. > > > > My query is "Can two broadcasters use the same port on the Darwin Streaming > Server to stream the media data ?" > > > > > > > > > > Regards > > Leena > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Wed Aug 29 16:17:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQTwk-0000AI-Nq; Wed, 29 Aug 2007 16:15:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQTwN-0008R6-Dm; Wed, 29 Aug 2007 16:15:03 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQTwN-0000HF-0Q; Wed, 29 Aug 2007 16:15:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id BA3782AC75; Wed, 29 Aug 2007 20:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IQTwM-0004Cv-ET; Wed, 29 Aug 2007 16:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 29 Aug 2007 16:15:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-rfc3119bis-05.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , 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 : A More Loss-Tolerant RTP Payload Format for MP3 Audio Author(s) : R. Finlayson Filename : draft-ietf-avt-rfc3119bis-05.txt Pages : 0 Date : 2007-8-29 This document describes a RTP (Real-Time Protocol) payload format for transporting MPEG (Moving Picture Experts Group) 1 or 2, layer III audio (commonly known as "MP3"). This format is an alternative to that described in RFC 2250, and performs better if there is packet loss. (This document updates (and obsoletes) RFC 3119, correcting typographical errors in the "SDP usage" section and pseudo-code appendices.) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc3119bis-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rfc3119bis-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rfc3119bis-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-8-29153346.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rfc3119bis-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rfc3119bis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-8-29153346.I-D@ietf.org> --OtherAccess-- --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://www1.ietf.org/mailman/listinfo/avt --NextPart-- From avt-bounces@ietf.org Fri Aug 31 10:46:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IR7jK-0008CA-4t; Fri, 31 Aug 2007 10:44:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IR7jJ-0008C5-GU for avt@ietf.org; Fri, 31 Aug 2007 10:44:13 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IR7jI-0007sa-9V for avt@ietf.org; Fri, 31 Aug 2007 10:44:13 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A9A05548189; Fri, 31 Aug 2007 16:44:11 +0200 (CEST) X-AuditID: c1b4fb3c-af67dbb0000007e1-f5-46d8293b7b44 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8B37620B19; Fri, 31 Aug 2007 16:44:11 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 31 Aug 2007 16:44:11 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 31 Aug 2007 16:44:10 +0200 Message-ID: <46D82939.8000300@ericsson.com> Date: Fri, 31 Aug 2007 16:44:09 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Stephan Wenger , Ye-Kui Wang , Thomas Schierl , IETF AVT WG X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Aug 2007 14:44:10.0729 (UTC) FILETIME=[645A5590:01C7EBDD] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: Subject: [AVT] Comments on draft-ietf-avt-rtp-svc-02 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Hi, Here are some comments on the document. 1. Section 1, last sentence. I think you need to clarify the following. - That it uses its own identity rather then extending on the identity of H.264. - That the deprecation only affects usage under SVC and not the normal H.264 payload format. I would change the word deprecates, removes to indicate that it doesn't change any existing only removes a not needed functionality. 2. Section 3.2: I think this text is a bit unclear. It can to easily be interpreted as that once an parameter set has been used it can't be changed. But I assume that this hasn't been changed and that you can change the active set and have the sets changed during the session by overwriting them. I think you should tell when the sets can be changed, rather also to make it clear. Because that do create some extra complexity. 3. Section 3.3, R and RR bits. Is this MUST in both send and receive. And what do you do if you find an violation. To be extendable a clear receiver policy needs to be defined, chose between discard NAL or Ignore bit. 4. Section 5.1.2: " RTP packet stream: A sequence of RTP packets with increasing sequence numbers, identical PT and SSRC, carried in one RTP session. Within the scope of this memo, one RTP packet stream is utilized to transport an integer number of SVC Layers." I don't agree that the PT needs to be identical. However, for your purposes I assume that it is great simpification not having to think about people using multiple PTs configured for carrying SVC NAL units for the same video sequence. I think you are introducing a limitation that doesn't need to exist, but has little practical value. 5. Section 6.2: "Please see section 5.1 of [RFC3984]. The following applies in addition." I think you should reomve the second sentence. 6. Section 6.4, I think you need to extend a bit on what is meant with protecting in this section. I understand it that it might be any RTP or network transport mechanism that affect the probability of delivery of the packet, including network QoS, FEC, RTP retransmissions, even scheduling behavior if one has knowledge about a local link with such properties. 7. Section 6.5, Is single nalu mode allowed for the base layer? As that is following 3984, it is not clear. 8. Section 6.6: [Ed.Note(YkW): I think we need more thinking on the value of the parameters. For example, requiring the parameters be the same for all the RTP streams and clients might be overkill for receivers of only lower layers.] [Edt. Note (StW): In RFC3984, the aforementioned codepoints are optional. It appears that for SVC, when used in conjunction with session mux, they are mandatory. I don't know how to express this in the MIME registration; we'll cross that bridge once we are getting to it.]" Assuming that you have multiple layers in multiple RTP sessions. As I see it the only good way of getting the buffer handling to work will be max-don-diff. That needs to be the same for all layers. However deint-buf-req can increase and be the sum of all layers included and which there are dependencies from this session. That way one can have an increasing buffer requirement depending on the number of RTP sessions being received in a multi-layer structure. 9. Section 6.9, why is the F bit redefined here? It seems much better to leave this bit alone to not complicate processing by having specific processing for it for this NALU type. Isn't the reasonable usage the same as for the aggregation NALU types in RFC 3984? 10. Section 6.9, definition of A bit is not understandable. To much new concepts introduced in the section. I would recommend that the concepts are explained in the introductionary part, rather then here in the specification part. "Layer Picture" also needs to be explained. 11. Section 6.9, what is "temporal scalable layer switching point"? 12. Section 6.9, are the definition, like "The P bit MUST be set to 1 if all the layer pictures containing the target NAL units (as defined above) are redundant pictures." meant to apply only to NALUs within this packet but also to NALUs in any other packet? 13. Section 6.9, there is little concreate motivation why PASCI NALU and the additional signalling flags are needed. Making an observation it seems that the PASCI has only limited appliability. First of all the level of aggregation within in a single RTP packet will not be that high that digging out the NALU headers will be a significant problem. Can we really expect that more than a few VCL NALUs to be present in the same packet. In some cases some SEI and parameters set NALUs may also appear but that will not be that common that it will be a significant issue. It is after all read and jump operations based on the NALU field length. Thus making the jumping around operation on a per NALU become the following: 1. Read NALU type, 2. read NALU length field (dependent on NALU type) 3. perform 1 at current + NALU size + C. Are there any great benefit from grouping the SEI NALUs in this NALU type? To me it seems that they could just as well be placed in the normal position. And if this information is so important please clarify which SEI messages that should be included here. Also the additional signalling information, I am missing how hard (if at all possible to derive) is to get from the NALUs itself. Is this additional information that doesn't exist otherwise in the bit-stream. Also how useful is it? My big question is: Is the PASCI motivated, despite being optional to utilize, it complicates the specification and implementations to smaller or bigger degree. 14. Section 9. I don't think SVC should change anything with the media type for AVC. Use it as is, for the base layer. Some explanation on how it relates to the SVC layers are of course necessary. 15. Section 9.1: sprop-interleaving-depth: Will usage of interleaving be allowed in combination with layering? They are after all to certain degree orthogonal usage. You can after all have interleaving-depth 0 and still use layering with DONs. I think there need to be a separation on the buffering required for inserting the layers and for interleaving. I would propose that this is thought over and possibly new parameters are defined to better indicate properties of the layered stream when it comes to buffering. 16. Section 9.1, sprop-scalabilit-info: Please include referense to Base64. 17. Section 9.1, sprop-leyer-ids: Why is it needed to base64 encode the DID,QID and TID numbers? Aren't there a point of keeping these human readable? 18. Section 9.2.2: Here is some work. I think we need to rework the offer/answer of 3984 with the additional complexity of the layering. 19. Section 9.2.3: This also needs clarification. 20, Section 10, I think you will need to elaborate on why there are no extra security issues due to the layering. 21. Section 13.3, Mentioning FGS when it is not yet supported by SVC. Is that not going a bit to far? I think MGS is good enough for motivating in this use case. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Fri Aug 31 10:58:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IR7vR-0003VP-MD; Fri, 31 Aug 2007 10:56:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IR7vQ-0003VJ-T0 for avt@ietf.org; Fri, 31 Aug 2007 10:56:44 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IR7vP-0008MT-Ha for avt@ietf.org; Fri, 31 Aug 2007 10:56:44 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 05AA1207AE; Fri, 31 Aug 2007 16:56:43 +0200 (CEST) X-AuditID: c1b4fb3c-af67dbb0000007e1-5b-46d82c2ab7b3 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E421F205EE; Fri, 31 Aug 2007 16:56:42 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 31 Aug 2007 16:56:42 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 31 Aug 2007 16:56:42 +0200 Message-ID: <46D82C2A.9000402@ericsson.com> Date: Fri, 31 Aug 2007 16:56:42 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Colin Perkins Subject: Re: [AVT] Working group last call: JPEG-2000 payload format References: <8F3BAAAB-D96C-465C-A350-2A8FD367A44A@csperkins.org> In-Reply-To: <8F3BAAAB-D96C-465C-A350-2A8FD367A44A@csperkins.org> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Aug 2007 14:56:42.0380 (UTC) FILETIME=[245F2CC0:01C7EBDF] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: AVT WG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Colin Perkins skrev: > Folks, > > There was considerable discussion on the list in June about allowing > non-90kHz clock rates for the JPEG-2000 payload format. A new version of > the draft is now available, making the agreed change: > > http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-jpeg2000-16.txt > http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-jpeg2000-beam-07.txt > > If you commented previously, please review to confirm the changes made > reflect the consensus. If there are no additional comments by 20th > August, we will request the IESG consider these drafts for publication. > Even if late, I think it looks okay. I am missing some recommendations on not using timestamp rate below 1000. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Fri Aug 31 11:03:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IR80E-0006tq-93; Fri, 31 Aug 2007 11:01:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IR80D-0006pq-04 for avt@ietf.org; Fri, 31 Aug 2007 11:01:41 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IR80C-0008Pf-Gu for avt@ietf.org; Fri, 31 Aug 2007 11:01:40 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 52ED12096B; Fri, 31 Aug 2007 17:00:41 +0200 (CEST) X-AuditID: c1b4fb3c-ae67bbb0000007e1-31-46d82d1917d9 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 38BE920510; Fri, 31 Aug 2007 17:00:41 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 31 Aug 2007 17:00:40 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 31 Aug 2007 17:00:40 +0200 Message-ID: <46D82D18.3060902@ericsson.com> Date: Fri, 31 Aug 2007 17:00:40 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Attila Sipos Subject: Re: [AVT] Progressing the RTP no-op payload format References: <165288C2C3E29449AFDE022DD10CC47107128611@ExBE03.nasstar-t1.net> In-Reply-To: <165288C2C3E29449AFDE022DD10CC47107128611@ExBE03.nasstar-t1.net> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Aug 2007 15:00:40.0673 (UTC) FILETIME=[B267CD10:01C7EBDF] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Colin Perkins , AVT WG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Attila Sipos skrev: >> 1) Do you believe an RTP no-op payload format is useful to >> standardise, given the other keep alive mechanisms that now exist? > > By the way, what other standard keepalive mechanisms exist? > Any of them RFC'ed yet? > > So far I have found this: > http://www.ietf.org/internet-drafts/draft-ietf-avt-app-rtp-keepalive-00. > txt > > (and another very similar one (by the same author) > > Regards, > > Attila > Well, that depends on the application context. But if using ICE then the STUN connectivity checks are used for keep-alive. The document above is a listing of possible solutions. But it lacks recommendation for or against. Most of them should not be used, due to bad side effects. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt