From avt-bounces@ietf.org Mon May 02 05:28:34 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1DSXEA-00045r-F5; Mon, 02 May 2005 05:28:34 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1DSWdJ-0003Jl-2W
for avt@megatron.ietf.org; Mon, 02 May 2005 04:50:30 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15006
for ; Mon, 2 May 2005 04:50:27 -0400 (EDT)
Received: from gate.eu.panasonic.com ([194.173.20.12]
helo=hhe500-02.hbg.de.pan.eu)
by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DSWqw-0004nI-0z
for avt@ietf.org; Mon, 02 May 2005 05:04:35 -0400
Received: from eundadmi01.pan.eu(10.100.96.64) by hhe500-02.hbg.de.pan.eu via
smtp id 49f5_1fe6ce4e_baf1_11d9_9602_003048253456;
Mon, 02 May 2005 12:01:21 +0200 (CEST)
Received: from VPN-MRelay-01.PEL.Panasonic.de ([10.100.176.55])
by eundadmi01.pan.eu (Lotus Domino Release 6.5.2)
with ESMTP id 2005050210500056-196 ; Mon, 2 May 2005 10:50:00 +0200
Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PEL.Panasonic.de;
Mon, 2 May 2005 10:51:09 +0200
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: RE: [AVT] Update (-09) of Timed Tex draft (WAS:
RE:Commentsondraft-ietf-avt-rtp-3gpp-timed-text-08.txt)
Date: Mon, 2 May 2005 10:49:17 +0200
Message-ID: <9D277E44D6EF0942B928C6F0DE99BB31B9722F@lan-ex-01.panasonic.de>
Thread-Topic: [AVT] Update (-09) of Timed Tex draft (WAS:
RE:Commentsondraft-ietf-avt-rtp-3gpp-timed-text-08.txt)
Thread-Index: AcVOe+z6Clhq6xvIQVWwYWn1QfhJ9QAcsaLQ
From: "Jose Rey"
To: "Colin Perkins" , "Jose Rey"
Content-Transfer-Encoding: quoted-printable
Content-class: urn:content-classes:message
Content-Type: text/plain;
charset="iso-8859-1"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Mon, 02 May 2005 05:08:27 -0400
Cc: Jan vanderMeer ,
Magnus Westerlund , avt@ietf.org,
Dave Singer
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: ,
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org
Colin,
[cut agreed]
>=20
> > Note that sending a sample description together with every=20
> text sample=20
> > (or set of samples) may result in a situation where the same sample=20
> > description is present in the receiver buffer many times, but with=20
> > different timestamp values. This is a desing choice to=20
> ensure correct=20
> > reception of sample descriptions and may cause moderate overhead.
>=20
> I'm not sure this part's appropriate, since it assumes a=20
> particular receiver buffer implementation strategy.
>=20
I am assuming that only the basic functionality is implemented: opening =
RTP packets, reading out units, giving them a TS as the rules describe =
and storing them in the receiver buffer in TS order. I intended to be =
as general as possible. The last sentence may lead to misunderstanding. =
Instead of that one, maybe describing an easy way to avoid this =
situation is more helpful: =20
"Note that sending a sample description together with every text sample =
(or set of samples) may result in a situation where the same sample =
description is present in the receiver buffer many times, but with =
different timestamp values. This can be avoided by maintaining a list =
of currently stored sample descriptions (i.e., their SIDX values) and =
checking this before writing in the buffer."
Jos=E9
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt
From avt-bounces@ietf.org Mon May 02 05:28:38 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1DSXEE-00048B-A2; Mon, 02 May 2005 05:28:38 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1DSWsk-0005nN-9R
for avt@megatron.ietf.org; Mon, 02 May 2005 05:06:26 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15728
for ; Mon, 2 May 2005 05:06:24 -0400 (EDT)
Received: from mr1.dcs.gla.ac.uk ([130.209.249.184])
by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSX6N-00051k-MT
for avt@ietf.org; Mon, 02 May 2005 05:20:33 -0400
Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:61717
helo=[192.168.0.2])
by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42)
id 1DSWsY-0004bZ-O5; Mon, 02 May 2005 10:06:14 +0100
In-Reply-To: <9D277E44D6EF0942B928C6F0DE99BB31B9722F@lan-ex-01.panasonic.de>
References: <9D277E44D6EF0942B928C6F0DE99BB31B9722F@lan-ex-01.panasonic.de>
Mime-Version: 1.0 (Apple Message framework v622)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <9cddd7b84f011eee4fa8faefa3ce9edb@csperkins.org>
Content-Transfer-Encoding: 7bit
From: Colin Perkins
Subject: Re: [AVT] Update (-09) of Timed Tex draft (WAS:
RE:Commentsondraft-ietf-avt-rtp-3gpp-timed-text-08.txt)
Date: Mon, 2 May 2005 10:06:10 +0100
To: "Jose Rey"
X-Mailer: Apple Mail (2.622)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Content-Transfer-Encoding: 7bit
Cc: Jan vanderMeer ,
Magnus Westerlund ,
Jose Rey , avt@ietf.org,
Dave Singer
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: ,
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org
Jose,
On 2 May 2005, at 09:49, Jose Rey wrote:
...
>>> Note that sending a sample description together with every text
>>> sample
>>> (or set of samples) may result in a situation where the same sample
>>> description is present in the receiver buffer many times, but with
>>> different timestamp values. This is a desing choice to ensure
>>> correct
>>> reception of sample descriptions and may cause moderate overhead.
>>
>> I'm not sure this part's appropriate, since it assumes a
>> particular receiver buffer implementation strategy.
>
> I am assuming that only the basic functionality is implemented:
> opening RTP packets, reading out units, giving them a TS as the rules
> describe and storing them in the receiver buffer in TS order. I
> intended to be as general as possible. The last sentence may lead to
> misunderstanding. Instead of that one, maybe describing an easy way
> to avoid this situation is more helpful:
>
> "Note that sending a sample description together with every text
> sample (or set of samples) may result in a situation where the same
> sample description is present in the receiver buffer many times, but
> with different timestamp values. This can be avoided by maintaining a
> list of currently stored sample descriptions (i.e., their SIDX values)
> and checking this before writing in the buffer."
This still has the same problem: it talks about implementation
strategies for the receiver buffer. From the point of the payload
format, we don't care how many copies of the data are maintained in the
buffer, or how you remove duplicates.
Colin
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt
From avt-bounces@ietf.org Mon May 02 06:15:43 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1DSXxn-0002UM-5X; Mon, 02 May 2005 06:15:43 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1DSXxk-0002U8-Qt
for avt@megatron.ietf.org; Mon, 02 May 2005 06:15:41 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23545
for ; Mon, 2 May 2005 06:15:38 -0400 (EDT)
Received: from mr1.dcs.gla.ac.uk ([130.209.249.184])
by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSYBP-0006qn-58
for avt@ietf.org; Mon, 02 May 2005 06:29:48 -0400
Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:62934
helo=[192.168.0.2])
by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42)
id 1DSXxS-0002RI-Rm; Mon, 02 May 2005 11:15:23 +0100
In-Reply-To: <9D277E44D6EF0942B928C6F0DE99BB31B96AE5@lan-ex-01.panasonic.de>
References: <9D277E44D6EF0942B928C6F0DE99BB31B96AE5@lan-ex-01.panasonic.de>
Mime-Version: 1.0 (Apple Message framework v622)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Message-Id:
Content-Transfer-Encoding: quoted-printable
From: Colin Perkins
Subject: Re: [AVT] IESG comments on draft-ietf-avr-rtp-retransmission-11.txt:
congestion control and retransmission request issuing concerns
Date: Mon, 2 May 2005 11:15:18 +0100
To: Jose Rey , TSV ADs
X-Mailer: Apple Mail (2.622)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 24d000849df6f171c5ec1cca2ea21b82
Content-Transfer-Encoding: quoted-printable
Cc: "W. Mark Townsley" ,
Magnus Westerlund ,
IETF AVT WG , david.leon@nokia.com
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: ,
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org
Jon: We'd like to move forward with this: could you please review the=20
changes to see if they address your concerns?
Jose: could you please prepare a list of changes to the draft, giving=20
old and new text? This would make it easier to see what has changed.
Colin
On 20 Apr 2005, at 16:10, Jose Rey wrote:
> (first of all, I apologize for the delay)
>
> Hi,
>
> This email has two parts as per subject. The only unanswered comment=20=
> is one on the reference implementation from Mark. David may have=20
> something to say there but since he's travelling now he hasn't found=20=
> the time yet.
>
> Wrt the CC comments,
>
> Jon says:
> =09
> "In the first place, we do not make a practice of passing Proposed=20
> Standard congestion control systems which lack sufficient=20
> implementation experience. It is more common for such mechanisms to=20
> spend considerable time as Experimental RFCs before we consider them=20=
> for PS. Is there any reason why this document is not going to=20
> Experimental now?"
>
> =3D=3D>??, RTX is not a congestion control system, the send rate is=20=
> determined by a CC mechanism only. If there are reasons for=20
> experimental then not here, no?
>
> "The sorts of statements made in Section 7 seem to provide just cause=20=
> for caution. The entire section is scoped to a SHOULD, and offers no=20=
> guidance as to when or why this SHOULD might not apply. The same=20
> applies to the other SHOULDs sprinkled through the ensuing paragraphs=20=
> - if the authors envision a condition like the following:
>
> If the packet loss rate exceeds an
> acceptable level, it SHOULD be concluded that congestion is not
> kept under control and retransmission SHOULD NOT then be used.
>
> ... i.e., in which implementations merely SHOULD NOT ignore evidence=20=
> of increasing packet loss due to the use of this mechanism, then this=20=
> specification would be the right place to raise counterexamples;=20
> otherwise these normative statements ought to be MUSTs."
>
> =3D=3D>A justification for the SHOULD would be, for example, when the=20=
> stream is paused to let the buffer fill up again as packets are=20
> re-sent. RTX explicitly allows retransmissions to be sent during RTSP=20=
> PAUSE. Another example could be application-specific messages (as per=20=
> AVPF) that could trigger repetition of a particular packet or frame. =20=
> In this line, another similar example: when the server estimates a=20
> particular requested frame is more important than the rest and sends=20=
> it in times of congestion ( kind of "receive better this than=20
> nothing"). These could be added as examples right behind the text=20
> above.
>
> "The second paragraph of Section 7 seems to allude to the congestion=20=
> control guidance in Section 2 of RFC3551, and the remainder of the=20
> section uses this guidance as a yardstick. However, this document=20
> offers no concrete advice to implementers on how an application might=20=
> determine if packet loss is within acceptable limits as those=20
> guidelines suggest."
> [Also Mark had similar comments: that little guidance here is a=20
> problem when implementing]
>
> =3D=3D>Hhmmm..maybe "acceptable packet loss level" is not the right=20
> wording. The "acceptable packet loss level" is an application thing=20=
> that cannot be specified here. Such assertions are based on=20
> subjective or objective evaluations of application performance.
>
> The whole point is that RTX should not be used when the application is=20=
> experiencing or recovering from congestion (except as above). Now,=20
> deciding when congestion is "over" is a difficult task that cannot be=20=
> specified here. Therefore I would change the text above to:
>
> "If the congestion is not
> kept under control, then retransmission SHOULD NOT then be used."
>
> "What I am afraid of in a few cases here is that if someone is handed=20=
> this document code from without a reference implementation to go by,=20=
> some of the lack of details in these sections would end up in: (1)=20
> several questions posted to a list asking for help, (2) a lot of=20
> guesses made, or (3) an unusable number of configuration commands to=20=
> tweak each and every possible parameter."
>
> =3D=3D>This is a different issue but related to the above: the=20
> client/server has limited means to set certain parameters that may=20
> help in defining when / how to use RTX. There is just one parameter=20=
> defined on this regard and that would be the server buffer time,=20
> "rtx". If this is not enough, so would it make sense to introduce any=20=
> of the following additional information as follows in the SDP (or=20
> elsewhere)?
>
> I.e. parameter(s) that:
>
> 1) Allow server to tell the receiver *implicitly* how to use NACKs as=20=
> a collection of parameters, understood as guidance values: a) minimum=20=
> / maximum number of retransmissions per packet; b) what timer value to=20=
> use for the retransmission requests; c) etc...or,
> 2) Allow the server to do the same explicitly: bitrate share that=20
> should be allocated to the retransmission stream, number of packets=20
> that should be reported in each RR.
>
> Comments:
> - In all options, the server always decides what is actually=20
> retransmitted;
> - In 2) the server has to do most calculations while in in 1) this is=20=
> done by the client.
>
> *Question* : does it make sense to add this to the SDP of this=20
> document? I am not sure if these should be present here or let for=20
> experimentation first.
>
> -----------
>
> Wrt to the other comments on "retransmission requests" from Mark:
>
> "6.3 Retransmission requests
>
>> The receiver should not send a retransmission request as soon as
>> it detects a missing sequence number but should add some extra
>> delay to compensate for packet reordering. This extra delay may,
>> for example, be based on past observations of the experienced
>> packet reordering.
>
> If packet reordering is determined to be extremely rare (e.g.,=20
> essentially never - perhaps due to the underlying datalink preventing=20=
> misordering) then the optimum delay here could in fact be zero except=20=
> in the rarest of cases. I'm afraid that an implementor might take this=20=
> too literally and always include some minimum delay, inhibiting=20
> performance for no good reason. Perhaps it should be pointed out that=20=
> "some delay" may in fact be zero in some cases."
> Also, the best "possible reorder delay" algorithm may not actually be=20=
> time based, but packet based. e.g., if n number of packets are=20
> received after a gap is detected, then assume that the packet was=20
> truly lost rather than out of order (something, incidentally, which=20
> may be far easier to code on some platforms as a very short fixed FIFO=20=
> packet buffer rather than via a timer-based mechanism)."
>
>
> =3D=3D>Thanks, this is a very helpful comment. Here is some work out =
some=20
> text on this based taking *much* from your comments.
>
> "It should be noted, in environments where packet reordering is rare=20=
> or does not take place, e.g., if the underlying datalink layer affords=20=
> ordered delivery, the delay may be extremely low or even take the=20
> value zero. In such cases, an appropriate "reorder delay" algorithm=20=
> may not actually be timer-based, but packet-based. E.g., if n number=20=
> of packets are received after a gap is detected, then it should be=20
> assumed that the packet was truly lost rather than out of order. This=20=
> may turn out to be far easier to code on some platforms as a very=20
> short fixed FIFO packet buffer as opposed to the timer-based=20
> mechanism."
>
> "> To increase the robustness to the loss of a NACK or of a
>> retransmission packet, a receiver may send a new NACK for the same
>> packet. This is referred to as multiple retransmissions. Before
>> sending a new NACK for a missing packet, the receiver should rely
>> on a timer to be reasonably sure that the previous retransmission
>> attempt has failed in order to avoid unnecessary retransmissions.
>
> Simply stating "should rely on a timer" doesn't really give the=20
> implementor much to go on as to what interval the timer should be set=20=
> to. Earlier in this section, calculation of an RTT was referenced.=20
> Perhaps this RTT should be used as part of the algorithm for when one=20=
> might send a multiple retransmission NACK request? =46rom this text=20
> alone, it isn't obvious what to base this timer on, what the default=20=
> value might be, whether it should be adaptive, etc."
>
> =3D=3D>Yes, the timer should be based in the observed RTT. For a =
start, I=20
> would leave it static, since experience is needed to find a meaningful=20=
> description/value of an adaptive mechanism. BTW, just to check, with=20=
> "part of the algorithm for when to send multiple retransmissions", I=20=
> guess you mean some adaptive algorithm that adjusts the timer for each=20=
> subsequent request?
>
> "Page 13, Section 7, Congestion control.
>
>> In addition, the sender MAY selectively retransmit only the
>> packets that it deems important and ignore NACK messages for other
>> packets in order to limit the bitrate.
>
> I think this could end up creating a situation where one side asks for=20=
> a packet repeatedly (multiple retransmission NACKs), and the other=20
> side ignores the request repeatedly (not sending due to selective=20
> retransmission)? Is this considered a reasonable and expected behavior=20=
> of the protocol?"
>
> =3D=3D>Yes, but this is not dangerous. Typically (at leat this is done =
in=20
> 3GPP) the client will report over a fixed number of packets or, in=20
> other words, carry fixed number of RTCP NACK reports (adjusted to the=20=
> RTCP packet size). Although this client-requesting-server-ignoring=20
> can happen a couple of times it doesn't add any danger or overhead=20
> since the NACK window simply "moves on"
>
> Looking forward to your comments,
>
> Jos=E9
>
>> -----Original Message-----
>> From: Colin Perkins [mailto:csp@csperkins.org]
>> Sent: Friday, April 01, 2005 2:57 PM
>> To: Jose Rey; Viktor.Varsa@nokia.com; Akihiro Miyazaki; Rolf
>> Hakenberg; david.leon@nokia.com
>> Cc: Magnus Westerlund; Allison Mankin
>> Subject: IESG comments on draft-ietf-avr-rtp-retransmission-11.txt
>>
>> Folks,
>>
>> The IESG has reviewed
>> draft-ietf-avt-rtp-retransmission-11.txt and has a number of
>> significant comments which can be found in the I-D tracker:
>>
>> https://datatracker.ietf.org/public/pidtracker.cgi?
>> command=3Dprint_ballot&ballot_id=3D973&filename=3Ddraft-ietf-avt-rtp-
>> retransmission
>>
>> To move forwards, you should review the comments to either
>> propose changes to the draft to address the IESG's concerns
>> or to explain why those concerns are not valid. It has been
>> suggested that one possible route forwards might be to move
>> to draft forward as an experimental RFC, documenting the
>> concerns about congestion control and security, but even that
>> approach would require adding text to document the issues.
>>
>> Opinions?
>>
>> Colin
>>
>>
>>
>
>
> _______________________________________________
> 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 Mon May 02 06:17:46 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1DSXzm-0002hD-Bt; Mon, 02 May 2005 06:17:46 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1DSXzk-0002h5-BN
for avt@megatron.ietf.org; Mon, 02 May 2005 06:17:44 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23677
for ; Mon, 2 May 2005 06:17:42 -0400 (EDT)
Received: from mr1.dcs.gla.ac.uk ([130.209.249.184])
by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSYDO-0006tD-Tj
for avt@ietf.org; Mon, 02 May 2005 06:31:51 -0400
Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:62960
helo=[192.168.0.2])
by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42)
id 1DSXzX-0002Ut-HM; Mon, 02 May 2005 11:17:31 +0100
In-Reply-To: <9D277E44D6EF0942B928C6F0DE99BB31B97000@lan-ex-01.panasonic.de>
References: <9D277E44D6EF0942B928C6F0DE99BB31B97000@lan-ex-01.panasonic.de>
Mime-Version: 1.0 (Apple Message framework v622)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Message-Id: <57fc6dbee4e67dba7ad1eec4f9db2f00@csperkins.org>
Content-Transfer-Encoding: quoted-printable
From: Colin Perkins
Subject: Re: [AVT] Re: IESG comments on
draft-ietf-avt-rtp-retransmission-11.txt: security concerns
Date: Mon, 2 May 2005 11:17:27 +0100
To: "Jose Rey"
X-Mailer: Apple Mail (2.622)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f
Content-Transfer-Encoding: quoted-printable
Cc: david.leon@nokia.com, Russ Housley ,
IETF AVT WG , Allison Mankin
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: ,
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org
Russ,
Does this address your concerns?
Colin
On 27 Apr 2005, at 14:28, Jose Rey wrote:
> Hi Russ,
>
> Sorry for the delay. Here is the proposed text, hopefully satisfying=20=
> your requests:
>
> --
> 12. Security considerations
>
> RTP packets using the payload format defined in this specification are=20=
> subject to the general security considerations discussed in RTP,=20
> Section 9.
>
> In common streaming scenarios message authentication, data integrity,=20=
> replay protection and confidentiality are desired. The absence of=20
> authentication may enable man-in-the-middle and replay attacks, which=20=
> can be very harmful for RTP retransmission. For example: tampered RTCP=20=
> packets may trigger inappropriate retransmissions that effectively=20
> reduce the actual bitrate share allocated to the original data stream,=20=
> tampered RTP retransmission packets could cause the client's decoder=20=
> to crash, tampered retransmission requests may invalidate the SSRC=20
> association mechanism described in Section 5 of this document. On the=20=
> other hand, replayed packets could lead to false re-ordering and RTT=20=
> measurements (required for the retransmission request strategy) and=20
> may cause the receiver buffer to overflow. Further, in order to ensure=20=
> confidentiality of the data, the original payload data needs to be=20
> encrypted. There is actually no need to encrypt the 2-byte=20
> retransmission payload header since it does not provide any hints=20
> about the data content.
>
> Furthermore, it is RECOMMENDED that the cryptography mechanisms used=20=
> for this payload format provide protection against known plaintext=20
> attacks. RTP recommends that the initial RTP timestamp SHOULD be=20
> random to secure the stream against known plaintext attacks. This=20
> payload format does not follow this recommendation as the initial=20
> timestamp will be the media timestamp of the first retransmitted=20
> packet. However, since the initial timestamp of the original stream is=20=
> itself random, if the original stream is encrypted, the first=20
> retransmitted packet timestamp would also be random to an attacker.=20
> Therefore, confidentiality would not be compromised.
>
> If cryptography is used to provide security services on the original=20=
> stream, then the same services, with equivalent cryptographic=20
> strength, MUST be provided on the retransmission stream. The use of=20=
> the same key for the retransmitted stream and the original stream may=20=
> lead to security problems, e. g., two-time pads. Refer to Section 9.1=20=
> of the Secure Real-Time Transport Protocol (SRTP)[12] for a discussion=20=
> the implications of two-time pads and how to avoid them.
>
> However, at the time of writing this document, the current SRTP=20
> specification cannot afford all the security services mentioned. There=20=
> are, at least, two reasons for this: 1) the ocurrence of two-time pads=20=
> and 2) the fact that this payload format typically works under the=20
> RTP/AVPF profile while SRTP only supports RTP/AVP. An adapted variant=20=
> of SRTP shall solve these shortcomings in the future.
>
> Congestion control considerations with the use of retransmission are=20=
> dealt with in Section 7 of this document.
>
> -- =20
>
> Looking forward to your comments,
>
> Jos=E9
>
>> -----Original Message-----
>> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On
>> Behalf Of Russ Housley
>> Sent: Thursday, April 07, 2005 11:07 PM
>> To: Jose.Rey@eu.panasonic.com
>> Cc: david.leon@nokia.com; csp@csperkins.org; avt@ietf.org
>> Subject: [AVT] Re: IESG comments on
>> draft-ietf-avt-rtp-retransmission-11.txt: security concerns
>>
>> Sorry for the delay in responding. I have been out of the
>> office too much.
>>
>>> I'll start with the security comments. Russ says:
>>>
>>> The introduction says:
>>>
>>> [snip] (no problems with these...)
>>>
>>> The first paragraph of the security considerations says:
>>>>
>>>> If cryptography is used to provide security services on the
>>>> original stream, then the same services, with equivalent
>>>> cryptographic strength, MUST be provided on the retransmission
>>>> stream. Old keys will likely need to be cached so that when the
>>>> keys change for the original stream, the old key is
>> used until it
>>>> is determined that the key has changed on the retransmission
>>>> packets as well.
>>>>
>>>> The use of the same key for the retransmitted stream and the
>>>> original stream may lead to security problems, e.g.
>> two-time pads.
>>>> This sharing has to be evaluated towards the chosen security
>>>> protocol and security algorithms.
>>>>
>>> I like the first sentence of the first paragraph very
>> much. However,
>>> the second sentence implies that the same keying material might be
>>> used to encrypt the retransmission, even though it is
>> being sent on a
>>> separate stream. The second paragraph points to the
>> possible security
>>> flaw if this is done. Since a SRTP-variant is the
>> security protocol
>>> that would be used in this context and SRTP is almost
>> always used with
>>> counter mode, the result could be a loss of
>> confidentiality. If the
>>> same keying material is used, then a mechanism is needed to ensure
>>> that the counter value will be different. SRTP seems to
>> be prepared
>>> to support this situation, but not without some guidance.
>> RFC 3711
>>> says:
>>>>
>>>> In addition, there can be cases (see Sections 8 and 9.1) where
>>>> several SRTP streams within a given RTP session,
>> identified by their
>>>> synchronization source (SSRCs, which is part of the RTP header),
>>>> share most of the crypto context parameters (including possibly
>>>> master and session keys). In such cases, just as in the normal
>>>> SRTP/SRTCP parameter sharing above, separate replay
>> lists and packet
>>>> counters for each stream (SSRC) MUST still be maintained.
>>>
>>>
>>> I am not sure what is the action that should result from
>> this comment.
>>> Let me explain myself: the two-time pads issue was discussed in the
>>> past with the SRTP authors. The last sentence in the second
>> paragraph
>>> " This sharing..." is trying to say that if two-time pads
>> are not dealt
>>> with in the security protocol used, then there is a security
>> problem.
>>> As Russ (and the doc) says it is a variant of SRTP, SAVPF,
>> that will
>>> be used to secure the original and rtx streams.
>>>
>>> Therefore it would be in this SRTP variant that shall define
>> what to do
>>> with potential two-time pads cases and not in the draft, hence what
>>> else could be said here? Since SAVPF draft has expired, I
>> understand
>>> that the security issue is not solved. Is this what has to be
>>> documented or make these two last facts even more explicit?
>>
>> I think we need to start with a more basic discussion of
>> security services. Which ones are desired? And, what are the
>> consequences if they are not provided. At a minimum, data
>> integrity, authentication, replay protection, and
>> confidentiality should be discussed.
>>
>> Next, the section should point out that a SRTP variant is a
>> likely way to provide the needed services. State that SRTP
>> as it stands is not acceptable because of the two-time pad
>> issue. Give a reference to the two-time pad discussion in
>> the SRTP specification.
>>
>> This would be a good place to include the sentence that I
>> liked so much:
>>> If cryptography is used to provide security services on the
>>> original stream, then the same services, with equivalent
>>> cryptographic strength, MUST be provided on the retransmission
>>> stream.
>>
>> I would omit the discussion of "old keys." Leave the
>> solution to the designers of the SRTP variant.
>>
>> I have no problem with the following two paragraphs from your
>> -11 document coming next; it seems like good context for the
>> SRTP variant designers:
>>> Furthermore, it is RECOMMENDED that the cryptography mechanisms
>>> used for this payload format provide protection against known
>>> plaintext attacks. RTP recommends that the initial RTP timestamp
>>> SHOULD be random to secure the stream against known plaintext
>>> attacks. This payload format does not follow this recommendation
>>> as the initial timestamp will be the media timestamp of the first
>>> retransmitted packet. However, since the initial
>> timestamp of the
>>> original stream is itself random, if the original stream is
>>> encrypted, the first retransmitted packet timestamp would also be
>>> random to an attacker. Therefore, confidentiality would not be
>>> compromised.
>>>
>>> Congestion control considerations with the use of retransmission
>>> are dealt with in Section 7 of this document.
>>
>> Does this raise any concerns?
>>
>> Russ
>>
>>
>> _______________________________________________
>> Audio/Video Transport Working Group
>> avt@ietf.org
>> https://www1.ietf.org/mailman/listinfo/avt
>>
>>
>
>
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www1.ietf.org/mailman/listinfo/avt
>
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt
From avt-bounces@ietf.org Mon May 02 07:48:56 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1DSZQ0-0005iW-BP; Mon, 02 May 2005 07:48:56 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1DSE5N-0006qY-BW
for avt@megatron.ietf.org; Sun, 01 May 2005 09:02:13 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20183
for ; Sun, 1 May 2005 09:02:09 -0400 (EDT)
Received: from woodstock.binhost.com ([144.202.243.4])
by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DSEIo-0008OD-SH
for avt@ietf.org; Sun, 01 May 2005 09:16:09 -0400
Received: (qmail 18611 invoked by uid 0); 1 May 2005 13:02:06 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (156.106.205.71)
by woodstock.binhost.com with SMTP; 1 May 2005 13:02:06 -0000
Message-Id: <6.2.0.14.2.20050501085945.05904560@mail.binhost.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14
Date: Sun, 01 May 2005 09:02:04 -0400
To: "Jose Rey"
From: Russ Housley
Subject: RE: [AVT] Re: IESG comments on
draft-ietf-avt-rtp-retransmission-11.txt: security concerns
In-Reply-To: <9D277E44D6EF0942B928C6F0DE99BB31B97000@lan-ex-01.panasonic .de>
References: <9D277E44D6EF0942B928C6F0DE99BB31B97000@lan-ex-01.panasonic.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id JAA20183
X-Mailman-Approved-At: Sun, 01 May 2005 11:31:25 -0400
Cc: david.leon@nokia.com, csp@csperkins.org, 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: ,
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org
Works for me, but I suggest an editorial change (for clarity).
OLD:
However, at the time of writing this document, the current SRTP=20
specification cannot afford all the security services mentioned.
NEW:
At the time of writing this document, SRTP does not provide all the=20
security services mentioned.
Russ
At 09:28 AM 4/27/2005, Jose Rey wrote:
>Hi Russ,
>
>Sorry for the delay. Here is the proposed text, hopefully satisfying yo=
ur=20
>requests:
>
>--
>12. Security considerations
>
>RTP packets using the payload format defined in this specification are=20
>subject to the general security considerations discussed in RTP, Section=
9.
>
>In common streaming scenarios message authentication, data integrity,=20
>replay protection and confidentiality are desired. The absence of=20
>authentication may enable man-in-the-middle and replay attacks, which ca=
n=20
>be very harmful for RTP retransmission. For example: tampered RTCP packe=
ts=20
>may trigger inappropriate retransmissions that effectively reduce the=20
>actual bitrate share allocated to the original data stream, tampered RTP=
=20
>retransmission packets could cause the client's decoder to crash, tamper=
ed=20
>retransmission requests may invalidate the SSRC association mechanism=20
>described in Section 5 of this document. On the other hand, replayed=20
>packets could lead to false re-ordering and RTT measurements (required f=
or=20
>the retransmission request strategy) and may cause the receiver buffer t=
o=20
>overflow. Further, in order to ensure confidentiality of the data, the=20
>original payload data needs to be encrypted. There is actually no need t=
o=20
>encrypt the 2-byte retransmission payload header since it does not provi=
de=20
>any hints about the data content.
>
>Furthermore, it is RECOMMENDED that the cryptography mechanisms used for=
=20
>this payload format provide protection against known plaintext attacks.=20
>RTP recommends that the initial RTP timestamp SHOULD be random to secure=
=20
>the stream against known plaintext attacks. This payload format does not=
=20
>follow this recommendation as the initial timestamp will be the media=20
>timestamp of the first retransmitted packet. However, since the initial=20
>timestamp of the original stream is itself random, if the original strea=
m=20
>is encrypted, the first retransmitted packet timestamp would also be=20
>random to an attacker. Therefore, confidentiality would not be compromis=
ed.
>
>If cryptography is used to provide security services on the original=20
>stream, then the same services, with equivalent cryptographic strength,=20
>MUST be provided on the retransmission stream. The use of the same key=20
>for the retransmitted stream and the original stream may lead to securit=
y=20
>problems, e. g., two-time pads. Refer to Section 9.1 of the Secure=20
>Real-Time Transport Protocol (SRTP)[12] for a discussion the implication=
s=20
>of two-time pads and how to avoid them.
>
>However, at the time of writing this document, the current SRTP=20
>specification cannot afford all the security services mentioned. There=20
>are, at least, two reasons for this: 1) the ocurrence of two-time pads a=
nd=20
>2) the fact that this payload format typically works under the RTP/AVPF=20
>profile while SRTP only supports RTP/AVP. An adapted variant of SRTP=20
>shall solve these shortcomings in the future.
>
>Congestion control considerations with the use of retransmission are dea=
lt=20
>with in Section 7 of this document.
>
>--
>
>Looking forward to your comments,
>
>Jos=E9
>
> > -----Original Message-----
> > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On
> > Behalf Of Russ Housley
> > Sent: Thursday, April 07, 2005 11:07 PM
> > To: Jose.Rey@eu.panasonic.com
> > Cc: david.leon@nokia.com; csp@csperkins.org; avt@ietf.org
> > Subject: [AVT] Re: IESG comments on
> > draft-ietf-avt-rtp-retransmission-11.txt: security concerns
> >
> > Sorry for the delay in responding. I have been out of the
> > office too much.
> >
> > >I'll start with the security comments. Russ says:
> > >
> > > The introduction says:
> > >
> > > [snip] (no problems with these...)
> > >
> > > The first paragraph of the security considerations says:
> > > >
> > > > If cryptography is used to provide security services on the
> > > > original stream, then the same services, with equivalent
> > > > cryptographic strength, MUST be provided on the retransmission
> > > > stream. Old keys will likely need to be cached so that when th=
e
> > > > keys change for the original stream, the old key is
> > used until it
> > > > is determined that the key has changed on the retransmission
> > > > packets as well.
> > > >
> > > > The use of the same key for the retransmitted stream and the
> > > > original stream may lead to security problems, e.g.
> > two-time pads.
> > > > This sharing has to be evaluated towards the chosen security
> > > > protocol and security algorithms.
> > > >
> > > I like the first sentence of the first paragraph very
> > much. However,
> > > the second sentence implies that the same keying material might b=
e
> > > used to encrypt the retransmission, even though it is
> > being sent on a
> > > separate stream. The second paragraph points to the
> > possible security
> > > flaw if this is done. Since a SRTP-variant is the
> > security protocol
> > > that would be used in this context and SRTP is almost
> > always used with
> > > counter mode, the result could be a loss of
> > confidentiality. If the
> > > same keying material is used, then a mechanism is needed to ensur=
e
> > > that the counter value will be different. SRTP seems to
> > be prepared
> > > to support this situation, but not without some guidance.
> > RFC 3711
> > > says:
> > > >
> > > > In addition, there can be cases (see Sections 8 and 9.1) where
> > > > several SRTP streams within a given RTP session,
> > identified by their
> > > > synchronization source (SSRCs, which is part of the RTP header)=
,
> > > > share most of the crypto context parameters (including possibly
> > > > master and session keys). In such cases, just as in the normal
> > > > SRTP/SRTCP parameter sharing above, separate replay
> > lists and packet
> > > > counters for each stream (SSRC) MUST still be maintained.
> > >
> > >
> > >I am not sure what is the action that should result from
> > this comment.
> > >Let me explain myself: the two-time pads issue was discussed in the
> > >past with the SRTP authors. The last sentence in the second
> > paragraph
> > >" This sharing..." is trying to say that if two-time pads
> > are not dealt
> > >with in the security protocol used, then there is a security
> > problem.
> > >As Russ (and the doc) says it is a variant of SRTP, SAVPF,
> > that will
> > >be used to secure the original and rtx streams.
> > >
> > >Therefore it would be in this SRTP variant that shall define
> > what to do
> > >with potential two-time pads cases and not in the draft, hence what
> > >else could be said here? Since SAVPF draft has expired, I
> > understand
> > >that the security issue is not solved. Is this what has to be
> > >documented or make these two last facts even more explicit?
> >
> > I think we need to start with a more basic discussion of
> > security services. Which ones are desired? And, what are the
> > consequences if they are not provided. At a minimum, data
> > integrity, authentication, replay protection, and
> > confidentiality should be discussed.
> >
> > Next, the section should point out that a SRTP variant is a
> > likely way to provide the needed services. State that SRTP
> > as it stands is not acceptable because of the two-time pad
> > issue. Give a reference to the two-time pad discussion in
> > the SRTP specification.
> >
> > This would be a good place to include the sentence that I
> > liked so much:
> > > If cryptography is used to provide security services on the
> > > original stream, then the same services, with equivalent
> > > cryptographic strength, MUST be provided on the retransmission
> > > stream.
> >
> > I would omit the discussion of "old keys." Leave the
> > solution to the designers of the SRTP variant.
> >
> > I have no problem with the following two paragraphs from your
> > -11 document coming next; it seems like good context for the
> > SRTP variant designers:
> > > Furthermore, it is RECOMMENDED that the cryptography mechanisms
> > > used for this payload format provide protection against known
> > > plaintext attacks. RTP recommends that the initial RTP timestam=
p
> > > SHOULD be random to secure the stream against known plaintext
> > > attacks. This payload format does not follow this recommendatio=
n
> > > as the initial timestamp will be the media timestamp of the firs=
t
> > > retransmitted packet. However, since the initial
> > timestamp of the
> > > original stream is itself random, if the original stream is
> > > encrypted, the first retransmitted packet timestamp would also b=
e
> > > random to an attacker. Therefore, confidentiality would not be
> > > compromised.
> > >
> > > Congestion control considerations with the use of retransmission
> > > are dealt with in Section 7 of this document.
> >
> > Does this raise any concerns?
> >
> > Russ
> >
> >
> > _______________________________________________
> > 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 Mon May 02 07:49:03 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1DSZQ7-0006EN-CQ; Mon, 02 May 2005 07:49:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1DSIZe-0004YT-1Y
for avt@megatron.ietf.org; Sun, 01 May 2005 13:49:46 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04978
for ; Sun, 1 May 2005 13:49:42 -0400 (EDT)
Received: from mr1.dcs.gla.ac.uk ([130.209.249.184])
by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSIn9-0008Jj-6a
for avt@ietf.org; Sun, 01 May 2005 14:03:44 -0400
Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:61493
helo=[192.168.0.2])
by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42)
id 1DSIZP-0006ia-NI; Sun, 01 May 2005 18:49:31 +0100
In-Reply-To: <9D277E44D6EF0942B928C6F0DE99BB31A5AF93@lan-ex-01.panasonic.de>
References: <9D277E44D6EF0942B928C6F0DE99BB31A5AF93@lan-ex-01.panasonic.de>
Mime-Version: 1.0 (Apple Message framework v622)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <5279b420cec4e78a922971c6551debe6@csperkins.org>
Content-Transfer-Encoding: quoted-printable
From: Colin Perkins
Subject: Re: [AVT] Update (-09) of Timed Tex draft (WAS: RE: Comments
ondraft-ietf-avt-rtp-3gpp-timed-text-08.txt)
Date: Sun, 1 May 2005 18:49:18 +0100
To: "Jose Rey"
X-Mailer: Apple Mail (2.622)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Content-Transfer-Encoding: quoted-printable
Cc: Magnus Westerlund ,
IETF 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: ,
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org
Jose,
On 13 Apr 2005, at 14:30, Jose Rey wrote:
...
>>> Right now, for TYPE 5 units applies:
>>>
>>> o In general, TYPE 5 units MUST receive their
>> timestamp from
>>> the first non-TYPE 5 unit following them in
>> the payload.
>>> o However, if:
>>>
>>>
>>> Rey & Matsui
>> [Page 31]
>>> =0C> Internet Draft Payload Format for 3GPP Timed Text March =
29,=20
>>> 2005
>>>
>>> o the payload only contains (one or several) TYPE 5
>>> units or,
>>> o if one or several TYPE 5 units follow a sample of
>>> unknown duration (see Section 4.1.2, SDUR
>>> definition),
>>>
>>> then (all) TYPE 5 units MUST use the RTP timestamp.
>>>
>>> Is this what you refer as too much complexity?
>>
>> Yes. Why not simply state that TYPE 5 units receive a
>> timestamp indicating when they become available for use?
>>
>
> This last sentence is included. The other issue is where to place=20
> them, i.e., currently they are placed as they are read from file. To=20=
> simplify one could say that they are all placed (regardless to which=20=
> unit in the payload they apply) at the beginning of the payload before=20=
> all other units and receive the RTP TS?
Sure, why not? As Dave said later, provided the sample descriptions=20
have a suitable timestamp for (a) their position in the stream and (b)=20=
before the timestamp of the first AU that uses them, everything will=20
work. The other rules seem to be unnecessary complexity.
Colin
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt
From avt-bounces@ietf.org Mon May 02 07:49:04 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1DSZQ8-0006FD-1V; Mon, 02 May 2005 07:49:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1DSJDu-0008Tk-M3
for avt@megatron.ietf.org; Sun, 01 May 2005 14:31:22 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06964
for ; Sun, 1 May 2005 14:31:19 -0400 (EDT)
Received: from mr1.dcs.gla.ac.uk ([130.209.249.184])
by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSJRR-0000Ui-5G
for avt@ietf.org; Sun, 01 May 2005 14:45:21 -0400
Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:61647
helo=[192.168.0.2])
by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42)
id 1DSJDk-000244-Of; Sun, 01 May 2005 19:31:12 +0100
In-Reply-To: <9D277E44D6EF0942B928C6F0DE99BB31B96B77@lan-ex-01.panasonic.de>
References: <9D277E44D6EF0942B928C6F0DE99BB31B96B77@lan-ex-01.panasonic.de>
Mime-Version: 1.0 (Apple Message framework v622)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <9dcc745baa7d9190cce3ef942caccaf2@csperkins.org>
Content-Transfer-Encoding: 7bit
From: Colin Perkins
Subject: Re: [AVT] Update (-09) of Timed Tex draft (WAS:
RE:Commentsondraft-ietf-avt-rtp-3gpp-timed-text-08.txt)
Date: Sun, 1 May 2005 19:31:01 +0100
To: "Jose Rey"
X-Mailer: Apple Mail (2.622)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1
Content-Transfer-Encoding: 7bit
Cc: Jan vanderMeer ,
Magnus Westerlund , avt@ietf.org,
Dave Singer
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: ,
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org
Jose,
On 21 Apr 2005, at 10:45, Jose Rey wrote:
...
>>> On this regard, this discussion in the intro of section 4 was moved
>>> to
>>> 4.5, where the following was added:
>>>
>>> Regarding sample descriptions in aggregate payloads: since TYPE
>>> 5
>>> units may potentially apply to several units in the stream, a
>>> sender shall ensure that a copy of the sample description is
>>> received before the affected text sample is due. Therefore, a
>>> copy of the sample description SHOULD be placed in the payload
>>> before the text sample it applies to. Of course, if several
>>> text
>>> samples in a payload use the same sample description, once per
>>> payload is enough. A sender MAY choose to omit the sample
>>> description if it knows by some other means, such as payload
>>> specific feedback messages [21], that the sample description has
>>> arrived at the receiver or if it employs additional transport
>>> resiliency measures (Section 5), for example.
>>
>> I would suggest changing this to:
>>
>> Correct reception of TYPE 5 units is important since their contents
>> may be referenced by several other units in the stream. Accordingly,
>> they MUST be given at timestamp not later than that given to those
>> other units. It may be desirable to resend the sample descriptions
>> periodically, or to use other transport resiliency mechanisms.
>>
>> since the text in the draft implies that a copy of the sample
>> description is sent in every packet, rather than allowing it
>> to be sent once and referenced by later packets.
>>
>
> Since it is the codec that shall buffer the SDs, then it is possible
> in some cases to 'skip' putting SDs in every single payload and be (or
> just relatively) confident that the units will be correctly displayed:
> for cases such as reliable channels or when the server knows the SD
> was received by other means; hence, I thought of a SHOULD and not a
> MUST. Would this text be fine?
>
> --
> Correct reception of TYPE 5 units is important since their contents
> may be referenced by several other units in the stream. Sample
> descriptions MUST be placed in the aggregate payload before the
> occurrence of any non-TYPE 5 units and MUST receive the RTP timestamp
> of that packet.
This is fine.
> Additionally, it is RECOMMENDED to include a copy of the sample
> description if referencing text samples are present. This is because
> the decoder is, in general, not able of using the text sample if the
> sample description is missing. Of course, if several text samples in
> a payload use the same sample description, once per payload is enough.
> Nevertheless, a sender MAY choose to omit the sample description if it
> knows by some other means, such as payload specific feedback messages
> [21], that the sample description has arrived at the receiver or if it
> employs additional transport resiliency measures (Section 5), for
> example.
These are okay, but not particularly clearly written. I suggest
rewording them as:
Receivers are unable to use text samples until their corresponding
sample description is received. Accordingly, a sender should send
multiple copies of a sample description to ensure reliability (see
section 5). Receivers can use payload specific feedback messages
[21] to tell a sender that they have received a particular sample
description.
> Note that sending a sample description together with every text sample
> (or set of samples) may result in a situation where the same sample
> description is present in the receiver buffer many times, but with
> different timestamp values. This is a desing choice to ensure correct
> reception of sample descriptions and may cause moderate overhead.
I'm not sure this part's appropriate, since it assumes a particular
receiver buffer implementation strategy.
Colin
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt
From avt-bounces@ietf.org Mon May 02 08:36:31 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1DSaA3-0004Rk-4k; Mon, 02 May 2005 08:36:31 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1DSaA0-0004RZ-Qo
for avt@megatron.ietf.org; Mon, 02 May 2005 08:36:28 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10494
for ; Mon, 2 May 2005 08:36:24 -0400 (EDT)
Received: from mr1.dcs.gla.ac.uk ([130.209.249.184])
by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSaNd-0002YL-Cr
for avt@ietf.org; Mon, 02 May 2005 08:50:34 -0400
Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:63168
helo=[192.168.0.2])
by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42)
id 1DSa9m-000768-44; Mon, 02 May 2005 13:36:14 +0100
In-Reply-To: <57fc6dbee4e67dba7ad1eec4f9db2f00@csperkins.org>
References: <9D277E44D6EF0942B928C6F0DE99BB31B97000@lan-ex-01.panasonic.de>
<57fc6dbee4e67dba7ad1eec4f9db2f00@csperkins.org>
Mime-Version: 1.0 (Apple Message framework v622)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Message-Id: <71a9e2e47c73af2615c038fff8669b54@csperkins.org>
Content-Transfer-Encoding: quoted-printable
From: Colin Perkins
Subject: Re: [AVT] Re: IESG comments on
draft-ietf-avt-rtp-retransmission-11.txt: security concerns
Date: Mon, 2 May 2005 13:36:01 +0100
To: Russ Housley
X-Mailer: Apple Mail (2.622)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 65bc4909d78e8b10349def623cf7a1d1
Content-Transfer-Encoding: quoted-printable
Cc: david.leon@nokia.com, Jose Rey ,
IETF AVT WG , Allison Mankin
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: ,
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org
Sorry - didn't see your answer since the list was down.
Colin
On 2 May 2005, at 11:17, Colin Perkins wrote:
> Russ,
>
> Does this address your concerns?
> Colin
>
>
> On 27 Apr 2005, at 14:28, Jose Rey wrote:
>
>> Hi Russ,
>>
>> Sorry for the delay. Here is the proposed text, hopefully satisfying=20=
>> your requests:
>>
>> --
>> 12. Security considerations
>>
>> RTP packets using the payload format defined in this specification=20
>> are subject to the general security considerations discussed in RTP,=20=
>> Section 9.
>>
>> In common streaming scenarios message authentication, data integrity,=20=
>> replay protection and confidentiality are desired. The absence of=20
>> authentication may enable man-in-the-middle and replay attacks, which=20=
>> can be very harmful for RTP retransmission. For example: tampered=20
>> RTCP packets may trigger inappropriate retransmissions that=20
>> effectively reduce the actual bitrate share allocated to the original=20=
>> data stream, tampered RTP retransmission packets could cause the=20
>> client's decoder to crash, tampered retransmission requests may=20
>> invalidate the SSRC association mechanism described in Section 5 of=20=
>> this document. On the other hand, replayed packets could lead to=20
>> false re-ordering and RTT measurements (required for the=20
>> retransmission request strategy) and may cause the receiver buffer to=20=
>> overflow. Further, in order to ensure confidentiality of the data,=20
>> the original payload data needs to be encrypted. There is actually no=20=
>> need to encrypt the 2-byte retransmission payload header since it=20
>> does not provide any hints about the data content.
>>
>> Furthermore, it is RECOMMENDED that the cryptography mechanisms used=20=
>> for this payload format provide protection against known plaintext=20
>> attacks. RTP recommends that the initial RTP timestamp SHOULD be=20
>> random to secure the stream against known plaintext attacks. This=20
>> payload format does not follow this recommendation as the initial=20
>> timestamp will be the media timestamp of the first retransmitted=20
>> packet. However, since the initial timestamp of the original stream=20=
>> is itself random, if the original stream is encrypted, the first=20
>> retransmitted packet timestamp would also be random to an attacker.=20=
>> Therefore, confidentiality would not be compromised.
>>
>> If cryptography is used to provide security services on the original=20=
>> stream, then the same services, with equivalent cryptographic=20
>> strength, MUST be provided on the retransmission stream. The use of=20=
>> the same key for the retransmitted stream and the original stream may=20=
>> lead to security problems, e. g., two-time pads. Refer to Section=20
>> 9.1 of the Secure Real-Time Transport Protocol (SRTP)[12] for a=20
>> discussion the implications of two-time pads and how to avoid them.
>>
>> However, at the time of writing this document, the current SRTP=20
>> specification cannot afford all the security services mentioned.=20
>> There are, at least, two reasons for this: 1) the ocurrence of=20
>> two-time pads and 2) the fact that this payload format typically=20
>> works under the RTP/AVPF profile while SRTP only supports RTP/AVP. =20=
>> An adapted variant of SRTP shall solve these shortcomings in the=20
>> future.
>>
>> Congestion control considerations with the use of retransmission are=20=
>> dealt with in Section 7 of this document.
>>
>> -- =20
>> Looking forward to your comments,
>>
>> Jos=E9
>>
>>> -----Original Message-----
>>> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On
>>> Behalf Of Russ Housley
>>> Sent: Thursday, April 07, 2005 11:07 PM
>>> To: Jose.Rey@eu.panasonic.com
>>> Cc: david.leon@nokia.com; csp@csperkins.org; avt@ietf.org
>>> Subject: [AVT] Re: IESG comments on
>>> draft-ietf-avt-rtp-retransmission-11.txt: security concerns
>>>
>>> Sorry for the delay in responding. I have been out of the
>>> office too much.
>>>
>>>> I'll start with the security comments. Russ says:
>>>>
>>>> The introduction says:
>>>>
>>>> [snip] (no problems with these...)
>>>>
>>>> The first paragraph of the security considerations says:
>>>>>
>>>>> If cryptography is used to provide security services on the
>>>>> original stream, then the same services, with equivalent
>>>>> cryptographic strength, MUST be provided on the retransmission
>>>>> stream. Old keys will likely need to be cached so that when the
>>>>> keys change for the original stream, the old key is
>>> used until it
>>>>> is determined that the key has changed on the retransmission
>>>>> packets as well.
>>>>>
>>>>> The use of the same key for the retransmitted stream and the
>>>>> original stream may lead to security problems, e.g.
>>> two-time pads.
>>>>> This sharing has to be evaluated towards the chosen security
>>>>> protocol and security algorithms.
>>>>>
>>>> I like the first sentence of the first paragraph very
>>> much. However,
>>>> the second sentence implies that the same keying material might =
be
>>>> used to encrypt the retransmission, even though it is
>>> being sent on a
>>>> separate stream. The second paragraph points to the
>>> possible security
>>>> flaw if this is done. Since a SRTP-variant is the
>>> security protocol
>>>> that would be used in this context and SRTP is almost
>>> always used with
>>>> counter mode, the result could be a loss of
>>> confidentiality. If the
>>>> same keying material is used, then a mechanism is needed to =
ensure
>>>> that the counter value will be different. SRTP seems to
>>> be prepared
>>>> to support this situation, but not without some guidance.
>>> RFC 3711
>>>> says:
>>>>>
>>>>> In addition, there can be cases (see Sections 8 and 9.1) where
>>>>> several SRTP streams within a given RTP session,
>>> identified by their
>>>>> synchronization source (SSRCs, which is part of the RTP header),
>>>>> share most of the crypto context parameters (including possibly
>>>>> master and session keys). In such cases, just as in the normal
>>>>> SRTP/SRTCP parameter sharing above, separate replay
>>> lists and packet
>>>>> counters for each stream (SSRC) MUST still be maintained.
>>>>
>>>>
>>>> I am not sure what is the action that should result from
>>> this comment.
>>>> Let me explain myself: the two-time pads issue was discussed in the
>>>> past with the SRTP authors. The last sentence in the second
>>> paragraph
>>>> " This sharing..." is trying to say that if two-time pads
>>> are not dealt
>>>> with in the security protocol used, then there is a security
>>> problem.
>>>> As Russ (and the doc) says it is a variant of SRTP, SAVPF,
>>> that will
>>>> be used to secure the original and rtx streams.
>>>>
>>>> Therefore it would be in this SRTP variant that shall define
>>> what to do
>>>> with potential two-time pads cases and not in the draft, hence what
>>>> else could be said here? Since SAVPF draft has expired, I
>>> understand
>>>> that the security issue is not solved. Is this what has to be
>>>> documented or make these two last facts even more explicit?
>>>
>>> I think we need to start with a more basic discussion of
>>> security services. Which ones are desired? And, what are the
>>> consequences if they are not provided. At a minimum, data
>>> integrity, authentication, replay protection, and
>>> confidentiality should be discussed.
>>>
>>> Next, the section should point out that a SRTP variant is a
>>> likely way to provide the needed services. State that SRTP
>>> as it stands is not acceptable because of the two-time pad
>>> issue. Give a reference to the two-time pad discussion in
>>> the SRTP specification.
>>>
>>> This would be a good place to include the sentence that I
>>> liked so much:
>>>> If cryptography is used to provide security services on the
>>>> original stream, then the same services, with equivalent
>>>> cryptographic strength, MUST be provided on the retransmission
>>>> stream.
>>>
>>> I would omit the discussion of "old keys." Leave the
>>> solution to the designers of the SRTP variant.
>>>
>>> I have no problem with the following two paragraphs from your
>>> -11 document coming next; it seems like good context for the
>>> SRTP variant designers:
>>>> Furthermore, it is RECOMMENDED that the cryptography mechanisms
>>>> used for this payload format provide protection against known
>>>> plaintext attacks. RTP recommends that the initial RTP timestamp
>>>> SHOULD be random to secure the stream against known plaintext
>>>> attacks. This payload format does not follow this recommendation
>>>> as the initial timestamp will be the media timestamp of the first
>>>> retransmitted packet. However, since the initial
>>> timestamp of the
>>>> original stream is itself random, if the original stream is
>>>> encrypted, the first retransmitted packet timestamp would also be
>>>> random to an attacker. Therefore, confidentiality would not be
>>>> compromised.
>>>>
>>>> Congestion control considerations with the use of retransmission
>>>> are dealt with in Section 7 of this document.
>>>
>>> Does this raise any concerns?
>>>
>>> Russ
>>>
>>>
>>> _______________________________________________
>>> Audio/Video Transport Working Group
>>> avt@ietf.org
>>> https://www1.ietf.org/mailman/listinfo/avt
>>>
>>>
>>
>>
>> _______________________________________________
>> Audio/Video Transport Working Group
>> avt@ietf.org
>> https://www1.ietf.org/mailman/listinfo/avt
>>
>
>
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www1.ietf.org/mailman/listinfo/avt
>
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt
From avt-bounces@ietf.org Mon May 02 13:34:54 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1DSeon-000767-Vg; Mon, 02 May 2005 13:34:53 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1DSeok-0006rb-Nm
for avt@megatron.ietf.org; Mon, 02 May 2005 13:34:52 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07231
for ; Mon, 2 May 2005 13:34:47 -0400 (EDT)
Received: from mail-out4.apple.com ([17.254.13.23])
by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSf2S-0000Br-EC
for avt@ietf.org; Mon, 02 May 2005 13:49:01 -0400
Received: from mailgate2.apple.com (a17-128-100-204.apple.com [17.128.100.204])
by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id j42HYdbG010799
for ; Mon, 2 May 2005 10:34:39 -0700 (PDT)
Received: from relay3.apple.com (relay3.apple.com) by mailgate2.apple.com
(Content Technologies SMTPRS 4.3.17) with ESMTP id
;
Mon, 2 May 2005 10:34:40 -0700
Received: from [17.202.35.52] (singda.apple.com [17.202.35.52])
by relay3.apple.com (8.12.11/8.12.11) with ESMTP id j42HYc9Q003186;
Mon, 2 May 2005 10:34:39 -0700 (PDT)
Mime-Version: 1.0
Message-Id:
In-Reply-To: <9D277E44D6EF0942B928C6F0DE99BB31B9722F@lan-ex-01.panasonic.de>
References: <9D277E44D6EF0942B928C6F0DE99BB31B9722F@lan-ex-01.panasonic.de>
Date: Mon, 2 May 2005 10:32:27 -0700
To: Jose Rey , Colin Perkins ,
Jose Rey
From: Dave Singer
Subject: RE: [AVT] Update (-09) of Timed Tex draft (WAS:
RE:Commentsondraft-ietf-avt-rtp-3gpp-timed-text-08.txt)
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Cc: Jan vanderMeer ,
Magnus Westerlund , 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: ,
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org
At 10:49 AM +0200 5/2/05, Jose Rey wrote:
>Colin,
>
>[cut agreed]
>>
>> > Note that sending a sample description together with every
>> text sample
>> > (or set of samples) may result in a situation where the same sample
>> > description is present in the receiver buffer many times, but with
>> > different timestamp values. This is a desing choice to
>> ensure correct
>> > reception of sample descriptions and may cause moderate overhead.
>>
>> I'm not sure this part's appropriate, since it assumes a
>> particular receiver buffer implementation strategy.
>>
>
>I am assuming that only the basic functionality is implemented:
>opening RTP packets, reading out units, giving them a TS as the
>rules describe and storing them in the receiver buffer in TS order.
>I intended to be as general as possible. The last sentence may lead
>to misunderstanding. Instead of that one, maybe describing an easy
>way to avoid this situation is more helpful:
>
>"Note that sending a sample description together with every text
>sample (or set of samples) may result in a situation where the same
>sample description is present in the receiver buffer many times, but
>with different timestamp values. This can be avoided by maintaining
>a list of currently stored sample descriptions (i.e., their SIDX
>values) and checking this before writing in the buffer."
>
I'm with Colin; leave it out. It assumes a dumb client, and if
engineers can't work out how to optimize this, they deserve the
overhead!
--
David Singer
Apple Computer/QuickTime
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt
From avt-bounces@ietf.org Mon May 02 20:08:10 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1DSkxO-0007e1-0a; Mon, 02 May 2005 20:08:10 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1DSkxM-0007dw-Jt
for avt@megatron.ietf.org; Mon, 02 May 2005 20:08:08 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03046
for ; Mon, 2 May 2005 20:08:07 -0400 (EDT)
Received: from mail2.dolby.com ([204.156.147.24] helo=dolby.com)
by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSlB8-0006Md-Mw
for avt@ietf.org; Mon, 02 May 2005 20:22:23 -0400
Received: from ([172.16.33.28])
by silver.dolby.com with ESMTP id 4028811.2956791;
Mon, 02 May 2005 17:07:34 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 2 May 2005 17:07:34 -0700
Message-ID: <5FCCC03CAF7C5C4C8E2F995E3D72E13304D96C63@platinum.dolby.net>
Thread-Topic: ptime and frame-based audio payload formats
Thread-Index: AcVPdBtVS6fc9pB1RK2FBkx5vOSG9g==
From: "Link, Brian"
To:
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
Subject: [AVT] ptime and frame-based audio payload formats
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="===============1810756391=="
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org
This is a multi-part message in MIME format.
--===============1810756391==
content-class: urn:content-classes:message
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C54F74.1B2AF59F"
This is a multi-part message in MIME format.
------_=_NextPart_001_01C54F74.1B2AF59F
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Colleagues,=0D=0A=0D=0AA question has come up inside the Digital Living Net=
work Alliance (DLNA)=0D=0Aabout the preferred way to define an RTP payload =
format for audio that=0D=0Auses a frame-based representation=2E The questio=
n applies to the AC-3 I-D,=0D=0Abut hopefully there is a general answer rea=
dily available=2E=0D=0A=0D=0AShould the optional MIME parameter "ptime" des=
cribe the duration of one=0D=0Aaudio frame in an RTP packet (regardless of =
the number of frames in the=0D=0Apacket) or should it describe the duration=
of an entire RTP packet (even=0D=0Athough the number of frames, and thus t=
he duration, may vary from packet=0D=0Ato packet)?=0D=0A=0D=0AThanks for yo=
ur help,=0D=0ABrian=0D=0A=0D=0A---=0D=0ABrian Link=0D=0ADolby Laboratories,=
100 Potrero Ave=2E, San Francisco, CA 94103=0D=0Aphone: 415-558-0324 fax:=
415-863-1373=0D=0Aemail: bdl@dolby=2Ecom alt email: link@ieee=2Eorg=0D=
=0A =0D=0A=0D=0A=0D=0A=0D=0A=0D=0A-----------------------------------------=
=0D=0AThis message (including any attachments) may contain confidential=0D=
=0Ainformation intended for a specific individual and purpose=2E If you ar=
e not=0D=0Athe intended recipient, delete this message=2E If you are not t=
he intended=0D=0Arecipient, disclosing, copying, distributing, or taking an=
y action based on=0D=0Athis message is strictly prohibited=2E=0D=0A
------_=_NextPart_001_01C54F74.1B2AF59F
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
=0D=0A=0D=0A=
=0D=0A=0D=0A=0D=0A=0D=0A=0D=0Aptime and frame-bas=
ed audio payload formats=0D=0A=0D=0A=0D=0A=0D=0A=0D=0ACol=
leagues,=0D=0A
=0D=0A=0D=0AA que=
stion has come up inside the Digital Living Network Alliance (DLNA) about t=
he preferred way to define an RTP payload format for audio that uses a fram=
e-based representation=2E The question applies to the AC-3 I-D, but hopeful=
ly there is a general answer readily available=2E
=0D=0A=0D=0A=
Should the optional MIME parameter "ptim=
e" describe the duration of one audio frame in an RTP packet (regardle=
ss of the number of frames in the packet) or should it describe the duratio=
n of an entire RTP packet (even though the number of frames, and thus the d=
uration, may vary from packet to packet)?
=0D=0A=0D=0AThanks for your help,=0D=0A=0D=0A
Brian=0D=0A
=0D=0A=0D=0A---=0D=0A=0D=0A
Brian =
Link=0D=0A=0D=0A
Dolby Laboratories=
, 100 Potrero Ave=2E, San Francisco, CA 94103=0D=0A=0D=0A
phone: 415-558-0324 fax: 415-863-1373=0D=0A=0D=0A
email: bdl@dolby=2Ecom alt email: link@ieee=2Eorg=
=0D=0A=0D=0A
=0D=0A
=0D=0A=
=0D=0A=0D=0A=0D=0A=0D=0A
=0D=0A=
=0D=0AThis message (including any attachments) may contain confidential=0D=
=0Ainformation intended for a specific individual and purpose=2E If you ar=
e not=0D=0Athe intended recipient, delete this message=2E If you are not t=
he intended=0D=0Arecipient, disclosing, copying, distributing, or taking an=
y action based on=0D=0Athis message is strictly prohibited=2E=0D=0A
=0D=0A=0D=0A=0D=0A
------_=_NextPart_001_01C54F74.1B2AF59F--
--===============1810756391==
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
--===============1810756391==--
From avt-bounces@ietf.org Tue May 03 03:31:33 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1DSrsT-0004gl-1g; Tue, 03 May 2005 03:31:33 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1DSrsQ-0004fT-F7
for avt@megatron.ietf.org; Tue, 03 May 2005 03:31:30 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08218
for ; Tue, 3 May 2005 03:31:28 -0400 (EDT)
Received: from albatross.ericsson.se ([193.180.251.49])
by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSs6D-0000UO-GH
for avt@ietf.org; Tue, 03 May 2005 03:45:49 -0400
Received: from esealmw127.eemea.ericsson.se ([153.88.254.122])
by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id
j437Uti4020007; Tue, 3 May 2005 09:31:23 +0200 (MEST)
Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by
esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211);
Tue, 3 May 2005 09:31:18 +0200
Received: from [147.214.34.108] ([147.214.34.108]) by
esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211);
Tue, 3 May 2005 09:31:18 +0200
Message-ID: <427728C6.9030406@ericsson.com>
Date: Tue, 03 May 2005 09:31:18 +0200
From: Magnus Westerlund
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Link, Brian"
Subject: Re: [AVT] ptime and frame-based audio payload formats
References: <5FCCC03CAF7C5C4C8E2F995E3D72E13304D96C63@platinum.dolby.net>
In-Reply-To: <5FCCC03CAF7C5C4C8E2F995E3D72E13304D96C63@platinum.dolby.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 03 May 2005 07:31:18.0629 (UTC)
FILETIME=[18A6E150:01C54FB2]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Content-Transfer-Encoding: 7bit
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: ,
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org
Hi Brian
Link, Brian wrote:
> Colleagues,
>
> A question has come up inside the Digital Living Network Alliance (DLNA)
> about the preferred way to define an RTP payload format for audio that
> uses a frame-based representation. The question applies to the AC-3 I-D,
> but hopefully there is a general answer readily available.
>
> Should the optional MIME parameter "ptime" describe the duration of one
> audio frame in an RTP packet (regardless of the number of frames in the
> packet) or should it describe the duration of an entire RTP packet (even
> though the number of frames, and thus the duration, may vary from packet
> to packet)?
>
ptime is on packet basis. If you review the definition in RFC 2327:
a=ptime:
This gives the length of time in milliseconds represented by the
media in a packet. This is probably only meaningful for audio
data. It should not be necessary to know ptime to decode RTP or
vat audio, and it is intended as a recommendation for the
encoding/packetisation of audio. It is a media attribute, and is
not dependent on charset.
It is clearly spelled out in the first sentence.
Cheers
Magnus Westerlund
Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
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 Tue May 03 03:36:26 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1DSrxB-0006Hi-VS; Tue, 03 May 2005 03:36:26 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1DSZ99-0006P3-3m
for avt@megatron.ietf.org; Mon, 02 May 2005 07:31:31 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04006
for ; Mon, 2 May 2005 07:31:30 -0400 (EDT)
Received: from gate.eu.panasonic.com ([194.173.20.12]
helo=hhe500-02.hbg.de.pan.eu)
by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DSZMn-0000gu-JM
for avt@ietf.org; Mon, 02 May 2005 07:45:39 -0400
Received: from eundadmi01.pan.eu(10.100.96.64) by hhe500-02.hbg.de.pan.eu via
smtp id 4a2e_a0fa4df6_bb07_11d9_912d_003048253456;
Mon, 02 May 2005 14:42:26 +0200 (CEST)
Received: from VPN-MRelay-01.PEL.Panasonic.de ([10.100.176.55])
by eundadmi01.pan.eu (Lotus Domino Release 6.5.2)
with ESMTP id 2005050213310583-5862 ; Mon, 2 May 2005 13:31:05 +0200
Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PEL.Panasonic.de;
Mon, 2 May 2005 13:32:17 +0200
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: RE: [AVT] Update (-09) of Timed Tex draft
(WAS:RE:Commentsondraft-ietf-avt-rtp-3gpp-timed-text-08.txt)
Date: Mon, 2 May 2005 13:30:22 +0200
Message-ID: <9D277E44D6EF0942B928C6F0DE99BB31B9725A@lan-ex-01.panasonic.de>
Thread-Topic: [AVT] Update (-09) of Timed Tex draft
(WAS:RE:Commentsondraft-ietf-avt-rtp-3gpp-timed-text-08.txt)
Thread-Index: AcVPAtkSBGfnhQmDS724MwXSqfbtrwAAM9Vw
From: "Jose Rey"
To: "Colin Perkins"
Content-Transfer-Encoding: quoted-printable
Content-class: urn:content-classes:message
Content-Type: text/plain;
charset="iso-8859-1"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Tue, 03 May 2005 03:36:22 -0400
Cc: Jan vanderMeer ,
Magnus Westerlund , avt@ietf.org,
Dave Singer
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: ,
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org
=20
Colin,
[]
> >> I'm not sure this part's appropriate, since it assumes a=20
> particular=20
> >> receiver buffer implementation strategy.
> >
> > I am assuming that only the basic functionality is implemented:=20
> > opening RTP packets, reading out units, giving them a TS as=20
> the rules=20
> > describe and storing them in the receiver buffer in TS order. I=20
> > intended to be as general as possible. The last sentence=20
> may lead to=20
> > misunderstanding. Instead of that one, maybe describing an=20
> easy way=20
> > to avoid this situation is more helpful:
> >
> > "Note that sending a sample description together with every text=20
> > sample (or set of samples) may result in a situation where the same=20
> > sample description is present in the receiver buffer many=20
> times, but=20
> > with different timestamp values. This can be avoided by=20
> maintaining a=20
> > list of currently stored sample descriptions (i.e., their=20
> SIDX values)=20
> > and checking this before writing in the buffer."
>=20
> This still has the same problem: it talks about=20
> implementation strategies for the receiver buffer. From the=20
> point of the payload format, we don't care how many copies of=20
> the data are maintained in the buffer, or how you remove duplicates.
Then I'll delete it. The note was meant to be merely informative but it =
is giving too much trouble.
Jos=E9
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt
From avt-bounces@ietf.org Fri May 06 10:41:10 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1DU40s-0008Bn-8I; Fri, 06 May 2005 10:41:10 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1DU40q-0008Bi-3B
for avt@megatron.ietf.org; Fri, 06 May 2005 10:41:08 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21569
for ; Fri, 6 May 2005 10:41:05 -0400 (EDT)
From: varadaraj.yatirajula@wipro.com
Received: from wip-ec-wd.wipro.com ([203.101.113.39])
by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DU4FI-0000ZI-Po
for avt@ietf.org; Fri, 06 May 2005 10:56:08 -0400
Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1])
by localhost (Postfix) with ESMTP id D34F62055F
for ; Fri, 6 May 2005 20:02:28 +0530 (IST)
Received: from blr-ec-bh02.wipro.com (unknown [10.201.50.92])
by wip-ec-wd.wipro.com (Postfix) with ESMTP id 825C42055A
for ; Fri, 6 May 2005 20:02:28 +0530 (IST)
Received: from BLR-EC-MBX04.wipro.com ([10.201.50.165]) by
blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.211);
Fri, 6 May 2005 20:10:44 +0530
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.7226.0
Date: Fri, 6 May 2005 20:10:56 +0530
Message-ID:
Thread-Topic: Question about replay list
Thread-Index: AcVPAtkSBGfnhQmDS724MwXSqfbtrwAAM9VwANFU7pA=
To:
X-OriginalArrivalTime: 06 May 2005 14:40:44.0534 (UTC)
FILETIME=[95913960:01C55249]
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed
Content-Transfer-Encoding: quoted-printable
Subject: [AVT] Question about replay list
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: ,
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org
I have a question about the replay list (RFC 3711) that is maintained
for replay protection.
Consider that a session is receiving packets from different sources
(each with at unique SSRC), does the replay list have to be maintained
for
each stream of RTP packets (with the same SSRC value)?
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt
From avt-bounces@ietf.org Fri May 06 10:59:44 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1DU4Iq-0002NW-Ei; Fri, 06 May 2005 10:59:44 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1DU4Ip-0002Mj-0f
for avt@megatron.ietf.org; Fri, 06 May 2005 10:59:43 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23347
for ; Fri, 6 May 2005 10:59:40 -0400 (EDT)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
id 1DU4XI-0001li-8b for avt@ietf.org; Fri, 06 May 2005 11:14:43 -0400
Received: from sj-core-1.cisco.com (171.71.177.237)
by sj-iport-2.cisco.com with ESMTP; 06 May 2005 07:59:31 -0700
Received: from imail.cisco.com (imail.cisco.com [128.107.200.91])
by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j46ExRER023168;
Fri, 6 May 2005 07:59:27 -0700 (PDT)
Received: from [192.168.0.11] (sjc-vpn1-431.cisco.com [10.21.97.175])
by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j46EnU4V004184;
Fri, 6 May 2005 07:49:30 -0700
In-Reply-To:
References:
Mime-Version: 1.0 (Apple Message framework v622)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id:
Content-Transfer-Encoding: 7bit
From: Mark Baugher
Subject: Re: [AVT] Question about replay list
Date: Fri, 6 May 2005 07:59:24 -0700
To: varadaraj.yatirajula@wipro.com
X-Mailer: Apple Mail (2.622)
IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs";
t:"1115390970.995534"; x:"432200"; a:"rsa-sha1"; b:"nofws:532";
e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p"
"XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC"
"50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc=";
s:"RUN3ZOPcu3oBeof0G2UH/z/8mTeMEp1IhCo2lKlow8OQh840YyDtKkBwlKVADHU3dlunP1Ro"
"cYunKp/+DHraI+XBdNuvwKuwBa2HGfFyHsHXaeY5OHpRurJ4CDQgsvy4JYUDQ1ZC+vpTCWrXY0c"
"2pB9DgFkdhUSx1b5Eq49lMWo=";
c:"From: Mark Baugher ";
c:"Subject: Re: [AVT] Question about replay list";
c:"Date: Fri, 6 May 2005 07:59:24 -0700"
IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com";
c:"message from imail.cisco.com verified; "
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Content-Transfer-Encoding: 7bit
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: ,
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org
On May 6, 2005, at 7:40 AM, varadaraj.yatirajula@wipro.com wrote:
> I have a question about the replay list (RFC 3711) that is maintained
> for replay protection.
>
> Consider that a session is receiving packets from different sources
> (each with at unique SSRC), does the replay list have to be maintained
> for
> each stream of RTP packets (with the same SSRC value)?
Yes. See 3.2.1 of RFC 3711. There is a replay list per crypto context
- and a crypto context per stream.
Mark
>
> _______________________________________________
> 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 Fri May 06 20:21:18 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1DUD4I-0006Aq-BI; Fri, 06 May 2005 20:21:18 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1DUD4G-0006Ai-4o; Fri, 06 May 2005 20:21:16 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25425;
Fri, 6 May 2005 20:21:14 -0400 (EDT)
Received: from boreas.isi.edu ([128.9.160.161])
by ietf-mx.ietf.org with esmtp (Exim 4.33)
id 1DUDIq-0003JK-Vg; Fri, 06 May 2005 20:36:21 -0400
Received: from ISI.EDU (adma.isi.edu [128.9.160.239])
by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j470KV626967;
Fri, 6 May 2005 17:20:31 -0700 (PDT)
Message-Id: <200505070020.j470KV626967@boreas.isi.edu>
To: ietf-announce@ietf.org
From: rfc-editor@rfc-editor.org
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 06 May 2005 17:20:31 -0700
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: rfc-ed@isi.edu
X-Spam-Score: -13.5 (-------------)
X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4
Cc: avt@ietf.org, rfc-editor@rfc-editor.org
Subject: [AVT] RFC 4060 on RTP Payload Formats for European
Telecommunications Standards Institute (ETSI) European
Standard ES 202 050, ES 202 211,
and ES 202 212 Distributed Speech Recognition Encoding
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: ,
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 4060
Title: RTP Payload Formats for European
Telecommunications Standards Institute (ETSI)
European Standard ES 202 050, ES 202 211, and
ES 202 212 Distributed Speech Recognition Encoding
Author(s): Q. Xie, D. Pearce
Status: Standards Track
Date: May 2005
Mailbox: qxie1@email.mot.com, bdp003@motorola.com
Pages: 19
Characters: 39654
Updates/Obsoletes/SeeAlso: None
I-D Tag: draft-ietf-avt-rtp-dsr-codecs-03.txt
URL: ftp://ftp.rfc-editor.org/in-notes/rfc4060.txt
This document specifies RTP payload formats for encapsulating European
Telecommunications Standards Institute (ETSI) European Standard ES 202
050 DSR Advanced Front-end (AFE), ES 202 211 DSR Extended
Front-end (XFE), and ES 202 212 DSR Extended Advanced Front-end
(XAFE) signal processing feature streams for distributed speech
recognition (DSR) systems.
This document is a product of the Audio/Video Transport Working Group
of the IETF.
This is now a Proposed Standard Protocol.
This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions
for improvements. Please refer to the current edition of the
"Internet Official Protocol Standards" (STD 1) for the
standardization state and status of this protocol. Distribution
of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST@IETF.ORG. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info@RFC-EDITOR.ORG
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
server="RFC-INFO@RFC-EDITOR.ORG"
Content-Type: text/plain
Content-ID: <050506171853.RFC@RFC-EDITOR.ORG>
RETRIEVE: rfc
DOC-ID: rfc4060
--OtherAccess
Content-Type: Message/External-body; name="rfc4060.txt"; site="ftp.isi.edu";
access-type="anon-ftp"; directory="in-notes"
Content-Type: text/plain
Content-ID: <050506171853.RFC@RFC-EDITOR.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 May 09 09:04:34 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1DV7w1-0001HS-Tv; Mon, 09 May 2005 09:04:33 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1DUJKT-00072u-0K; Sat, 07 May 2005 03:02:25 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14581;
Sat, 7 May 2005 03:02:23 -0400 (EDT)
Received: from pat.uio.no ([129.240.130.16] ident=7411)
by ietf-mx.ietf.org with esmtp (Exim 4.33)
id 1DUJZ5-0001i1-4M; Sat, 07 May 2005 03:17:33 -0400
Received: from mail-mx1.uio.no ([129.240.10.29])
by pat.uio.no with esmtp (Exim 4.43)
id 1DUJKJ-0003y5-PY; Sat, 07 May 2005 09:02:15 +0200
Received: from kaksi.ifi.uio.no ([129.240.65.193])
by mail-mx1.uio.no with esmtp (Exim 4.43)
id 1DUJKB-0000Bd-Jj; Sat, 07 May 2005 09:02:07 +0200
Received: from griff by kaksi.ifi.uio.no with local (Exim 4.44)
id 1DUJKA-0005Y3-Pr; Sat, 07 May 2005 09:02:06 +0200
To: avt@ietf.org, diffserv@ietf.org, gsmp@ietf.org, manet@ietf.org,
mmusic@ietf.org, rmonmib@ietf.org, seamoby@ietf.org, sip@ietf.org,
sming@ops.ietf.org
Message-Id:
From: Carsten Griwodz
Date: Sat, 07 May 2005 09:02:06 +0200
X-UiO-Spam-info: not spam, SpamAssassin (score=-6.565, required 12,
autolearn=disabled, ALL_TRUSTED -2.82, AWL -0.24, SORTED_RECIPS 1.50,
UIO_MAIL_IS_INTERNAL -5.00)
X-Spam-Score: 4.3 (++++)
X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027
X-Mailman-Approved-At: Mon, 09 May 2005 09:04:32 -0400
Cc:
Subject: [AVT] CFP: Multimedia Computing and Networking (MMCN 2006)
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: ,
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org
Dear mailing list member,
we would like to inform you about the upcoming deadline of the
MMCN 2006. We apologize if you receive multiple copies of this CfP.
==========================================================================
Call for Papers and Announcement
SPIE/ACM MMCN 2006
Multimedia Computing and Networking 2006
Part of the IS&T/SPIE International Symposium on Electronic Imaging
In cooperation with: ACM SIG Multimedia
15-18 January 2006
San Jose Marriott and San Jose Convention Center
San Jose, CA, USA
The objective of this conference is to bring together researchers and
practitioners contributing to all facets of multimedia computing and
networking. We especially encourage full and original papers on emerging
technologies such as residential broadband networks and digital appliances,
multimedia and QoS support for 3G and ad hoc networks, multimedia in P2P
environments, sensor networks and grids, power-aware computing and
communications, mobile and fixed wireless multimedia networks and content
distribution networks. We will specially feature industrial design
experiences and showcase tools for next-generation multimedia systems and
applications. Presenters will be encouraged to make multimedia
presentations and demonstrate their solutions in person.
Papers are solicited in all areas of multimedia, including, but not
limited to:
Multimedia Networking
. home, mobile and broadband networks
. QoS control and scheduling
. push technologies, content distribution and other emerging access
technologies
. Internet data streaming, delivery and wide-area caching
. sensor networks for multimedia
. grid use for multimedia
Measurement and Modeling
. performance measurement of multimedia systems
. statistical modeling of server traffic and server software
. multimedia system simulations and benchmark comparisons
Multimedia Computing
. multimedia OS services
. power-aware systems
. video-on-demand services
. peer-to-peer media systems
. development tools
Case Studies and Applications
. entertainment and networked games
. distributed virtual reality
. multimedia authoring
Authors are invited to submit both research and industrial papers on
original, unpublished work describing current research and novel ideas in
the area of multimedia computing and networking. Papers whose contributions
are supported by experimental evaluations are strongly encouraged. Paper
submissions should not exceed 15 single-spaced, single column pages
including figures, tables, and references, using a typeface no smaller than
10 points. The full paper and a 500-word text abstract must be electronical-
ly submitted by the submission deadline. For details about the submission
process go to the conference website at http://www.ifi.uio.no/mmcn2006.
| |
|Full Paper for Review Due: 24 June 2005 |
|Final Manuscript Due: 24 October 2005 |
|200-word Final Summary Due: 14 November 2005 |
|Proceedings of this conference will be published and |
|available at the meeting. |
Conference Chairs:
Surendar Chandra, Univ. of Notre Dame
Carsten Griwodz, Univ. of Oslo
Publicity Co-Chairs:
Wei Tsang Ooi, National Univ. of Singapore (Singapore)
Andreas Mauthe, Lancaster Univ. (UK)
Michael Zink, Univ. of Massachusetts/Amherst (USA)
Program Committee:
Tarek Abdelzaher, Univ. of Virginia (USA)
Sarita Adve, Univ. of Illinois/Urbana-Champaign (USA)
Scott A. Brandt, Univ. of California/Santa Cruz (USA)
Pascal Frossard, Swiss Federal Institute of Tech. (Switzerland)
Pål Halvorsen, Univ. of Oslo (Norway)
David H. Du, Univ. of Minnesota (USA)
Wu-chi Feng, Portland State Univ. (USA)
Baochun Li, University of Toronto (Canada)
Ian Marsh, Swedish Computer Science Institute (Sweden)
Andreas Mauthe, Lancaster Univ. (UK)
Ketan Mayer-Patel, Univ. of North Carolina/Chapel Hill (USA)
Klara Nahrstedt, Univ. of Illinois/Urbana-Champaign (USA)
Wei Tsang Ooi, National Univ. of Singapore (Singapore)
Ragunathan Rajkumar, Carnegie Mellon Univ. (USA)
Tajana Simunic-Rosing, Univ. of Californica/San Diego
Karsten Schwan, Georgia Institute of Technology (USA)
Ralf Steinmetz, Darmstadt Univ. of Tech. (Germany)
Nalini Venkatasubramanian, Univ. of California/Irvine (USA)
Lars Wolf, Tech. Univ. Braunschweig (Germany)
Dongyan Xu, Purdue Univ. (USA)
Wanghong Yuan, DoCoMo Coomunications Lab. (USA
Roger Zimmermann, Univ. of Southern California (USA)
Michael Zink, Univ. of Massachusetts/Amherst (USA)
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt
From avt-bounces@ietf.org Wed May 11 06:06:50 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1DVo77-0003nb-US; Wed, 11 May 2005 06:06:49 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1DVo76-0003nW-5v
for avt@megatron.ietf.org; Wed, 11 May 2005 06:06:48 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18587
for ; Wed, 11 May 2005 06:06:45 -0400 (EDT)
Received: from gate.eu.panasonic.com ([194.173.20.12]
helo=hhe500-02.hbg.de.pan.eu)
by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DVoMY-00053P-FG
for avt@ietf.org; Wed, 11 May 2005 06:22:49 -0400
Received: from eundadmi01.pan.eu(10.100.96.64) by hhe500-02.hbg.de.pan.eu via
smtp id 3658_4d681436_c20d_11d9_823e_003048253456;
Wed, 11 May 2005 13:10:41 +0200 (CEST)
Received: from VPN-MRelay-01.PEL.Panasonic.de ([10.100.176.55])
by eundadmi01.pan.eu (Lotus Domino Release 6.5.2)
with ESMTP id 2005051111584394-31518 ;
Wed, 11 May 2005 11:58:43 +0200
Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PEL.Panasonic.de;
Wed, 11 May 2005 11:59:56 +0200
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: RE: [AVT] IESG comments on draft-ietf-avr-rtp-retransmission-11.txt:
congestion control and retransmission request issuing concerns
Date: Wed, 11 May 2005 11:57:52 +0200
Message-ID: <9D277E44D6EF0942B928C6F0DE99BB31B976E1@lan-ex-01.panasonic.de>
Thread-Topic: [AVT] IESG comments on draft-ietf-avr-rtp-retransmission-11.txt:
congestion control and retransmission request issuing concerns
Thread-Index: AcVPAEYmZl453TvQRQeVp1tjTGrApwHBlUAg
To: "Colin Perkins" , "TSV ADs"
From: "Jose Rey"
Content-Transfer-Encoding: quoted-printable
Content-class: urn:content-classes:message
Content-Type: text/plain;
charset="iso-8859-1"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f0b5a4216bfa030ed8a6f68d1833f8ae
Content-Transfer-Encoding: quoted-printable
Cc: "W. Mark Townsley" ,
Magnus Westerlund ,
IETF AVT WG , david.leon@nokia.com
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: ,
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org
Colin, Jon,
> Jose: could you please prepare a list of changes to the=20
> draft, giving old and new text? This would make it easier to=20
> see what has changed.
Here is the text I proposed in the last emails in the requested format. =
Not all comments are addressed with these new text pieces as I still =
await guidance from Jon and Mark.
Thanks,
Jos=E9
> >
> > "The sorts of statements made in Section 7 seem to provide=20
> just cause=20
> > for caution. The entire section is scoped to a SHOULD, and=20
> offers no=20
> > guidance as to when or why this SHOULD might not apply. The same=20
> > applies to the other SHOULDs sprinkled through the ensuing=20
> paragraphs
> > - if the authors envision a condition like the following:
> >
> > If the packet loss rate exceeds an
> > acceptable level, it SHOULD be concluded that congestion is not
> > kept under control and retransmission SHOULD NOT then be used.
> >
> > "The second paragraph of Section 7 seems to allude to the=20
> congestion=20
> > control guidance in Section 2 of RFC3551, and the remainder of the=20
> > section uses this guidance as a yardstick. However, this document=20
> > offers no concrete advice to implementers on how an=20
> application might=20
> > determine if packet loss is within acceptable limits as those=20
> > guidelines suggest."
> > [Also Mark had similar comments: that little guidance here is a=20
> > problem when implementing]
> >
> > =3D=3D>Hhmmm..maybe "acceptable packet loss level" is not the right=20
> > wording. The "acceptable packet loss level" is an=20
> application thing=20
> > that cannot be specified here. Such assertions are based on=20
> > subjective or objective evaluations of application performance.
> >
> > The whole point is that RTX should not be used when the=20
> application is=20
> > experiencing or recovering from congestion (except as above). Now,=20
> > deciding when congestion is "over" is a difficult task that=20
> cannot be=20
> > specified here. Therefore I would change the text above to:
> >
> > "If the congestion is not
> > kept under control, then retransmission SHOULD NOT then be used."
OLD:
These congestion control mechanisms should keep the packet loss=20
rate within acceptable parameters. Packet loss is considered=20
acceptable if a TCP flow across the same network path and=20
experiencing the same network conditions would achieve, on a=20
reasonable timescale, an average throughput, that is not less than=20
the one the RTP flow achieves. If the packet loss rate exceeds an=20
acceptable level, it SHOULD be concluded that congestion is not=20
kept under control and retransmission SHOULD NOT then be used. It=20
may further be necessary to adapt the transmission rate (or the=20
number of layers subscribed for a layered multicast session), or=20
to arrange for the receiver to leave the session. =20
NEW:
These congestion control mechanisms should keep the packet loss=20
rate within acceptable parameters. In the context of congestion =
control, packet loss is considered=20
acceptable if a TCP flow across the same network path and=20
experiencing the same network conditions would achieve, on a=20
reasonable timescale, an average throughput, that is not less than=20
the one the RTP flow achieves. If congestion is not
kept under control, then retransmission SHOULD NOT be used. =20
Retransmissions MAY still be sent in some cases, e.g.,=20
in wireless links where packet losses are not caused by congestion, =
or if the=20
server (or the client that makes the retransmission request) =
estimates that a particular
packet or frame is important to continue play out, or if an RTSP =
PAUSE has been=20
issued to allow the buffer to fill up (RTSP PAUSE does not affect
the sending of retransmissions.) =20
Finally, it may further be necessary to adapt the transmission rate =
(or the=20
number of layers subscribed for a layered multicast session), or=20
to arrange for the receiver to leave the session. =20
[]
> >
> > Wrt to the other comments on "retransmission requests" from Mark:
> >
> > "6.3 Retransmission requests
> >
> >> The receiver should not send a retransmission request as soon as
> >> it detects a missing sequence number but should add some extra
> >> delay to compensate for packet reordering. This extra=20
> delay may,
> >> for example, be based on past observations of the experienced
> >> packet reordering.
> >
> > If packet reordering is determined to be extremely rare (e.g.,=20
> > essentially never - perhaps due to the underlying datalink=20
> preventing
> > misordering) then the optimum delay here could in fact be=20
> zero except=20
> > in the rarest of cases. I'm afraid that an implementor=20
> might take this=20
> > too literally and always include some minimum delay, inhibiting=20
> > performance for no good reason. Perhaps it should be=20
> pointed out that=20
> > "some delay" may in fact be zero in some cases."
> > Also, the best "possible reorder delay" algorithm may not=20
> actually be=20
> > time based, but packet based. e.g., if n number of packets are=20
> > received after a gap is detected, then assume that the packet was=20
> > truly lost rather than out of order (something, incidentally, which=20
> > may be far easier to code on some platforms as a very short=20
> fixed FIFO=20
> > packet buffer rather than via a timer-based mechanism)."
> >
> >
> > =3D=3D>Thanks, this is a very helpful comment. Here is some=20
> work out some=20
> > text on this based taking *much* from your comments.
> >
> > "It should be noted, in environments where packet=20
> reordering is rare=20
> > or does not take place, e.g., if the underlying datalink=20
> layer affords=20
> > ordered delivery, the delay may be extremely low or even take the=20
> > value zero. In such cases, an appropriate "reorder delay"=20
> algorithm=20
> > may not actually be timer-based, but packet-based. E.g.,=20
> if n number=20
> > of packets are received after a gap is detected, then it should be=20
> > assumed that the packet was truly lost rather than out of=20
> order. This=20
> > may turn out to be far easier to code on some platforms as a very=20
> > short fixed FIFO packet buffer as opposed to the timer-based=20
> > mechanism."
> >
OLD:
The receiver should not send a retransmission request as soon as=20
it detects a missing sequence number but should add some extra=20
delay to compensate for packet reordering. This extra delay may,=20
for example, be based on past observations of the experienced=20
packet reordering.
NEW:
The receiver should not send a retransmission request as soon as=20
it detects a missing sequence number but should add some extra=20
delay to compensate for packet reordering. This extra delay may,=20
for example, be based on past observations of the experienced=20
packet reordering. It should be noted that, in environments where
packet reordering is rare or does not take place, e. g., if the=20
underlying datalink layer affords ordered delivery, the delay may=20
be extremely low or even take the value zero. In such cases, an=20
appropriate "reorder delay" algorithm may not actually be=20
timer-based, but packet-based. E. g., if n number of packets are
received after a gap is detected, then it should be assumed=20
that the packet was truly lost rather than out of order. This may=20
turn out to be far easier to code on some platforms as a very=20
short fixed FIFO packet buffer as opposed to the timer-based =
mechanism.
(I shamelessly lent much of the new text from Mark :)
> > "> To increase the robustness to the loss of a NACK or of a
> >> retransmission packet, a receiver may send a new NACK=20
> for the same
> >> packet. This is referred to as multiple=20
> retransmissions. Before
> >> sending a new NACK for a missing packet, the receiver=20
> should rely
> >> on a timer to be reasonably sure that the previous=20
> retransmission
> >> attempt has failed in order to avoid unnecessary=20
> retransmissions.
> >
> > Simply stating "should rely on a timer" doesn't really give the=20
> > implementor much to go on as to what interval the timer=20
> should be set=20
> > to. Earlier in this section, calculation of an RTT was referenced.
> > Perhaps this RTT should be used as part of the algorithm=20
> for when one=20
> > might send a multiple retransmission NACK request? From this text=20
> > alone, it isn't obvious what to base this timer on, what=20
> the default=20
> > value might be, whether it should be adaptive, etc."
> >
> > =3D=3D>Yes, the timer should be based in the observed RTT. For=20
> a start, I=20
> > would leave it static, since experience is needed to find a=20
> meaningful=20
> > description/value of an adaptive mechanism. BTW, just to=20
> check, with=20
> > "part of the algorithm for when to send multiple=20
> retransmissions", I=20
> > guess you mean some adaptive algorithm that adjusts the=20
> timer for each=20
> > subsequent request?
> >
OLD:
To increase the robustness to the loss of a NACK or of a=20
retransmission packet, a receiver may send a new NACK for the same=20
packet. This is referred to as multiple retransmissions. Before=20
sending a new NACK for a missing packet, the receiver should rely=20
on a timer to be reasonably sure that the previous retransmission=20
attempt has failed in to avoid unnecessary retransmissions.=20
NEW:
To increase the robustness to the loss of a NACK or of a=20
retransmission packet, a receiver may send a new NACK for the same=20
packet. This is referred to as multiple retransmissions. Before=20
sending a new NACK for a missing packet, the receiver should rely=20
on a timer to be reasonably sure that the previous retransmission=20
attempt has failed and so avoid unnecessary retransmissions. =20
The timer value shall be based on the observed round-trip time. =
Both, a static
or an adaptive value MAY be used. =20
An adaptive timer could be one that changes its value with=20
every new request for the same packet. This document=20
does not provide any guidelines as to how this adaptive value should
be calculated because no experiments have been done to find this out.
[]
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt
From avt-bounces@ietf.org Wed May 11 09:37:13 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1DVrOj-0003Jv-GQ; Wed, 11 May 2005 09:37:13 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1DVrOh-0003Jn-IP; Wed, 11 May 2005 09:37:11 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03839;
Wed, 11 May 2005 09:37:09 -0400 (EDT)
Received: from penguin.ericsson.se ([193.180.251.47])
by ietf-mx.ietf.org with esmtp (Exim 4.33)
id 1DVreD-0007YT-SK; Wed, 11 May 2005 09:53:14 -0400
Received: from esealmw126.eemea.ericsson.se ([153.88.254.123])
by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id
j4BDZVmR022657; Wed, 11 May 2005 15:37:05 +0200 (MEST)
Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by
esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211);
Wed, 11 May 2005 15:37:01 +0200
Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by
esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211);
Wed, 11 May 2005 15:37:00 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 11 May 2005 15:37:00 +0200
Message-ID: <026F8EEDAD2C4342A993203088C1FC051C288B@esealmw109.eemea.ericsson.se>
Thread-Topic: I-D ACTION:draft-ash-avt-hc-over-mpls-protocol-00.txt
Thread-Index: AcVGsK+ZB2HmnyVzRdmKlM478mx93gAB+qAAAAFCAXAAACNPsAAABc3AA9m5cPA=
From: "Lars-Erik Jonsson \(LU/EAB\)"
To: "Ash, Gerald R \(Jerry\), ALABS" , ,
X-OriginalArrivalTime: 11 May 2005 13:37:00.0813 (UTC)
FILETIME=[828473D0:01C5562E]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e
Content-Transfer-Encoding: quoted-printable
Cc:
Subject: [AVT] RE: [rohc] RE: I-D
ACTION:draft-ash-avt-hc-over-mpls-protocol-00.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: ,
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org
Jerry and others,
First of all, I must say you've done a great job with this update. The
technical solution is starting to get in shape, and so also the draft
itself. I just have a few issues that I believe should be given some
additional attention, and I'll start with the least technical one:
* References
=20
- There is one incorrect reference to RFC 3409, which I think has
not much to do with this document. The correct document to refer
to is RFC 3241, "Robust Header Compression (ROHC) over PPP".
- There is one invalid reference [IPCP], I guess it should be [RFC1332]
- As it is currently written, I believe [RFC3544] and [RFC3241]
would be normative for this document. I believe some other
references, e.g. some MPLS references, would also be normative.
- There are many informative references, go through them and make
sure they all are actually bringing any value as informative to
this document (I am not sure about the MPLS references). It might
also make sense to group them based on content (HD vs MPLS, etc),
that would make it easier for the reader.
* Separation of functionality
As previously discussed, I believe it would be useful to more
clearly separate negotiation/setup/signalling from encapsulation. As
it now stands, I am not sure I understand what purpose the separation
of chapter 2 and chapter 3 serves. Chapter 2 is about both setup and
encapsulation, while chapter 3 is about setup only.
* Requirements fulfilment
In chapter 1, it is said that the outlined solution fulfils the
requirements of [MPLS-HC-REQ]. I am not sure this listing is really
needed, neither do I think it is fully correct.
a) is true, that is a design decision for this document
b) is also true, ok, it is the whole purpose of the document
c) is not really achieved by this document, but depends on the
header compression scheme used, and especially on how that
scheme is implemented. This document can not guarantee anything
in this regard, but it provides what it can to make this possible.
What this document do indeed provide, is the mechanism to avoid
multiple compression/decompression cycles, but that is b) above.
d) "signal context identification", I do not know what is meant
with that, neither do I know what standard protocols are referred
to, is it the MPLS PW mechanisms that are meant, and/or the
HC-over-PPP specifications (for the latter, see also below).
e) this is implementation dependent on HC-protocol level, and it
is out of control of this specification, which is dependent on
the HC scheme implementation(s). Or do PW provide means for=20
in-order delivery?
Overall, I do not see the point of listing these things here. I
think it is sufficient to say that the solution(s) outlined in
this document have been designed and chosen to address the
goals and requirements of [MPLS-HC-REQ].
* "Flow Setup", end of chapter 2 introduction
- Is this really only about "setup"? It does not look so to me.
- I believe this can be generalized so that it is HC-scheme
independent, should not be hard to do.
- It is not clear whether 2) is mandatory or not, i.e. is it
mandatory to have a bidirectional connection?
* "Flow setup", last bullet, "Free up CID when flow terminates"
- How can one ever know that a flow has terminated? For UDP-based
"flows", there is no such thing. Also, why should one free
CIDs, I agree CIDs should be re-usable, but if memory is
allocated for a certain number of CIDs, that memory should
last as long as the HC instance(s) is(are) alive. It is the
compressor that may choose to re-use a CID. This has been
thoroughly discussed in the ROHC WG, captured in chapter 7
of .
* Link layer packet type field
The requirement that link layers must provide packet type
identification for HC packets does not apply to ROHC. Therefore
I believe it is an improper design to require the extra
multiplexing byte (Pkt Typ field) for all schemes. There is
a negotiation of HC scheme done for the "channel", so why not
say that for schemes that can not identify their own packet
types, the extra byte is needed, as described. Or actually
negotiate whether to have this byte, independent of HC scheme
(although some require it).
* I think it makes sense to re-use the principles of RFC 3544 and
RFC 3241, but I also think this document will actually have to
define more specifically how the negotiation is done (with
similar principles as in 3544 and 3241). Both RFC 3544 and RFC
3241 are written as plug-ins to the PPP control protocol IPCP,
so just referring to them here where there is no PPP or IPCP
does not convince me about the completeness of the solution.=20
Rgds,
/L-E
> -----Original Message-----
> From: rohc-bounces@ietf.org [mailto:rohc-bounces@ietf.org]On Behalf Of
> Ash, Gerald R (Jerry), ALABS
> Sent: den 22 april 2005 00:06
> To: rohc@ietf.org
> Cc: Ash, Gerald R (Jerry), ALABS
> Subject: [rohc] RE: I-D
> ACTION:draft-ash-avt-hc-over-mpls-protocol-00.txt
>=20
>=20
> Hi All,
>=20
> Please review and comment on the (significantly) updated=20
> draft "Protocol
> Extensions for Header Compression over MPLS"
> (http://www.ietf.org/internet-drafts/draft-ash-avt-hc-over-mpl
> s-protocol
> -00.txt).
>=20
> Here is a brief background and overview/explanation of the updates:
>=20
> Work on requirements for header compression over MPLS
> (http://www.ietf.org/internet-drafts/draft-ietf-avt-hc-mpls-re
> qs-03.txt)
> is complete, and work on protocol extensions for header=20
> compression over
> MPLS is underway (previous draft at
> http://ietf.org/internet-drafts/draft-ash-avt-ecrtp-over-mpls-
> protocol-0
> 2.txt). Chartering of the protocol work in the AVT working group has
> been submitted for approval with the following milestone:
>=20
> Dec 05: Submit any extensions for RTP HC on MPLS networks for Proposed
> Standard
>=20
> There has been considerable discussion on the previous protocol
> extensions draft
> (http://ietf.org/internet-drafts/draft-ash-avt-ecrtp-over-mpls
> -protocol-
> 02.txt) in the last couple of months. I presented the update on the
> header compression over MPLS protocol extensions work at the=20
> AVT meeting
> at IETF-62; slides and minutes are available at
> https://datatracker.ietf.org/public/proceeding_interim.cgi?mee
> ting_num=3D6
> 2 (look under AVT for minutes and slides). The recent discussion and
> issues regarding the basic approach are summarized in the slides.
>=20
> Header compression experts in the AVT and ROHC working groups wish to
> re-use, and extend, the existing layer 2 approaches for assignment of
> context identification (CID) and header compression parameter
> negotiation. In a multipoint-to-point MPLS environment, one approach
> would be to have the various header compressors assign CIDs as they do
> now, with the possible need to resolve CID conflicts/collisions at the
> header decompressor. Some comments were made that current header
> compression methods do not have to resolve CID collisions, however the
> synchronization source (SSRC) assigned in RTP could need
> collision/conflict resolution.
>=20
> A second approach, suggested by Andy Malis and Loa Andersson,=20
> is to use
> pseudowires and/or targeted LDP to create 'point-to-point' sessions
> between header compressor and header decompressor, thereby=20
> avoiding any
> issue of CID collision. The disadvantage of this approach is that it
> requires an additional 4-byte label to be carried with each packet. =20
>=20
> The updated draft based on the second approach is available at
> http://www.ietf.org/internet-drafts/draft-ash-avt-hc-over-mpls
> -protocol-
> 00.txt.
>=20
> Once again, please review and comment on the updated draft.
>=20
> Thanks,
> Jerry
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt
From avt-bounces@ietf.org Thu May 12 09:51:51 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1DWE6R-00008T-Ny; Thu, 12 May 2005 09:51:51 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1DWE6M-00006o-Iq; Thu, 12 May 2005 09:51:46 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24516;
Thu, 12 May 2005 09:51:44 -0400 (EDT)
Received: from [132.151.6.50] (helo=newodin.ietf.org)
by ietf-mx.ietf.org with esmtp (Exim 4.33)
id 1DWEM6-000239-Bn; Thu, 12 May 2005 10:08:02 -0400
Received: from apache by newodin.ietf.org with local (Exim 4.43)
id 1DWE6J-0004AS-47; Thu, 12 May 2005 09:51:43 -0400
X-test-idtracker: no
From: The IESG
To: IETF-Announce
Message-Id:
Date: Thu, 12 May 2005 09:51:43 -0400
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Cc: avt chair , avt chair ,
Internet Architecture Board , avt mailing list ,
RFC Editor
Subject: [AVT] Document Action: 'Requirements for Header Compression over
MPLS' 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: ,
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org
The IESG has approved the following document:
- 'Requirements for Header Compression over MPLS '
as an Informational RFC
This document is the product of the Audio/Video Transport Working Group.
It was reviewed as well by the Multiprotocol Label Switching Working Group.
The IESG contact persons are Allison Mankin and Jon Peterson.
RFC Editor Note:
OLD:
These MPLS
signaling protocol extensions need coordination with other working
groups (e.g., MPLS).
NEW:
The specific MPLS signaling protocol extensions to support these
approved requirements need to be developed as a well-coordinated
separate document in the MPLS working group.
The IETF needs to support a coordinated process for the two solution
documents, though they are in separate areas.
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt
From avt-bounces@ietf.org Thu May 12 14:17:04 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1DWIF6-0006cf-Mj; Thu, 12 May 2005 14:17:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1DWIF5-0006ca-0y
for avt@megatron.ietf.org; Thu, 12 May 2005 14:17:03 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17597
for ; Thu, 12 May 2005 14:17:01 -0400 (EDT)
Received: from gateway0.eecs.berkeley.edu ([169.229.60.93])
by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWIUq-0000AZ-QT
for avt@ietf.org; Thu, 12 May 2005 14:33:21 -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.13.4/8.13.3) with ESMTP id
j4CIH0SO029712
(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT)
for ; Thu, 12 May 2005 11:17:01 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v622)
Content-Transfer-Encoding: 7bit
Message-Id: <0e101a978781fadadc66adf49b44a36b@eecs.berkeley.edu>
Content-Type: text/plain; charset=US-ASCII; format=flowed
To: avt@ietf.org
From: lazzaro
Date: Thu, 12 May 2005 11:16:50 -0700
X-Mailer: Apple Mail (2.622)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac
Content-Transfer-Encoding: 7bit
Subject: [AVT] RE: RTP MIDI I-D updates ...
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: ,
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org
On Sun, 24 Apr 2005 21:40:18 -0700 John Lazzaro wrote:
> Just sent off RTP MIDI I-D updates
> to internet-drafts, you can download them
> now from the Berkeley mirror site:
>
> http://www.cs.berkeley.edu/~lazzaro/sa/pubs/txt/current-rtp-midi.txt
> http://www.cs.berkeley.edu/~lazzaro/sa/pubs/txt/current-guide.txt
>
> Until May 15th, I'll be busy wrapping up
> the course I'm teaching this semester [...]
Teaching responsibilities ended a few days early.
So, if anyone has comments they've been holding
back sending to the list, now is a good time to send.
A good first step might be to classify which of the
responses for the 43 issues are considered resolved
and which ones are contentious. I could then release
a document with a more manageable change log, that
listed the still-open issues. This could also let me slip
in some errata that implementors have passed along
in the past few weeks ...
Also, one note from my earlier posting:
> C.6.2 is interesting because I did my best
> to push RTSP as hard as I could to handle the
> full range of stage and studio products. In the process,
> I basically had to bend RTSP until it (almost) broke,
> and I still didn't quite get all the semantics I need
> to get the functionality pro audio folks will expect.
> See C.6.2 for details; for those short on time, read the
> preamble, then skip to the examples in C.6.2.3.
>
> There are many paths possible on this issue.
> Ideally, there's a way to keep the stage and studio
> material in the RTP MIDI I-Ds, use RTSP as is, and
> fully solve the problem. But maybe that's not possible.
> If so, we'll have to think outside the box.
I'm starting to believe that the right thing to do is to
accept that the IETF has mature session management
protocols and frameworks that are a good match to the
VoIP-like Network Musical Performance application
for RTP MIDI (namely, SIP) and for content-streaming
RTP MIDI work (namely, RTSP).
But, getting a good fit for the "stage and studio" applications
from an IETF session management protocol (RTSP, as I
tried to do in C.6.2, or SIP, which I have sketched out
informally in the past) is going to take real work that
is more appropriately done somewhere else than AVT.
So, it may be wise to limit the scope of the I-Ds to cover
the two mature applications, and limit references to
"stage and studio" to the introduction, where we would
note that the protocol was designed to be useful in
those domains, but that the I-D focuses on applications
for which the upper layers of the IETF stack is ready to go.
I think this particularly makes sense because many
stage and studio devices (particularly video devices)
won't be using MIDI at all, but yet will face the same
issues that the examples in C.6.2 do.
One could imagine reworking C.6.2 to be less MIDI specific,
and spinning it off into an MMUSIC document ... or, one could
imagine leaving session management for stage and studio to
a standards organization that specializes in the pro world,
rather than leaving it in the IETF ...
---
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 Mon May 16 09:33:16 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1DXfie-0001JE-1Q; Mon, 16 May 2005 09:33:16 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1DXfid-0001J9-3N
for avt@megatron.ietf.org; Mon, 16 May 2005 09:33:15 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11303
for ; Mon, 16 May 2005 09:33:13 -0400 (EDT)
Received: from mr1.dcs.gla.ac.uk ([130.209.249.184])
by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXfzA-0003zo-AL
for avt@ietf.org; Mon, 16 May 2005 09:50:21 -0400
Received: from alor.dcs.gla.ac.uk ([130.209.247.84]:53379)
by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42)
id 1DXfiN-0007MC-Qi; Mon, 16 May 2005 14:32:59 +0100
In-Reply-To: <200505091952.PAA25698@ietf.org>
References: <200505091952.PAA25698@ietf.org>
Mime-Version: 1.0 (Apple Message framework v622)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <6077bebac7bfc6f9950d040c3a953828@csperkins.org>
Content-Transfer-Encoding: 7bit
From: Colin Perkins
Date: Mon, 16 May 2005 14:32:59 +0100
To: Dan Wing
X-Mailer: Apple Mail (2.622)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336
Content-Transfer-Encoding: 7bit
Cc: IETF AVT WG
Subject: [AVT] Re: I-D ACTION:draft-wing-avt-rtp-noop-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: ,
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org
On 9 May 2005, at 20:52, Internet-Drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
> Title : A No-op payload format for the Realtime Transport Protocol
> Author(s) : F. Andreasen, et al.
> Filename : draft-wing-avt-rtp-noop-02.txt
> Pages : 12
> Date : 2005-5-9
>
> This document defines an no-op payload format for the Real-time
> Transport Protocol (RTP), and a mechanism to request an immediate
> RTCP report. This can be used to verify RTP connectivity and to
> keep
> Network Address Translator (NAT) bindings and Firewall pinholes
> open.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-wing-avt-rtp-noop-02.txt
I have a few comments on this draft:
Would it be possible to rename "Request Immediate RTCP" to "Request
Early RTCP" throughout? This would clarify that the RTP/AVPF timing
rules MUST be followed, and that applications cannot send the feedback
immediately. This would also reduce concerns about congestion control.
Similarly, it would help if bullet point 1 in section 2.6 stated
clearly that "If the RTP/AVPF profile is not used the receiver MUST NOT
send immediate feedback".
Can you please change the title to use "RTP" rather than "Realtime
Transport Protocol" for consistency with other drafts, and to make it
easier to search for RTP-related RFCs. We have permission from the RFC
Editor and IESG to use the acronym in draft titles.
The definition of RFC 2119 key words should be placed at the end of the
introduction, rather than being a separate section before the table of
contents.
Section 2.6 (second paragraph) has a typo ("Se""nd Immediate RTCP
Report").
Section 3 has incorrectly formatted SDP examples (the "s=" lines).
Colin
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt
From avt-bounces@ietf.org Mon May 16 12:39:46 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1DXid8-0006ri-8B; Mon, 16 May 2005 12:39:46 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1DXid6-0006o3-O3
for avt@megatron.ietf.org; Mon, 16 May 2005 12:39:44 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07414
for ; Mon, 16 May 2005 12:39:41 -0400 (EDT)
Received: from gateway0.eecs.berkeley.edu ([169.229.60.93])
by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXitf-0002Ch-Fp
for avt@ietf.org; Mon, 16 May 2005 12:56:52 -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.13.4/8.13.3) with ESMTP id
j4GGdfn4011677
(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT)
for ; Mon, 16 May 2005 09:39:41 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v728)
In-Reply-To: <20050516161058.AEBF68C64S@mxtreme0.EECS.Berkeley.EDU>
References: <20050516161058.AEBF68C64S@mxtreme0.EECS.Berkeley.EDU>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id:
Content-Transfer-Encoding: 7bit
From: lazzaro
Date: Mon, 16 May 2005 09:39:40 -0700
To: avt@ietf.org
X-Mailer: Apple Mail (2.728)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Content-Transfer-Encoding: 7bit
Subject: [AVT] Maybe www.apps.ietf.org needs an SDP validator
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: ,
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org
On May 16, 2005, at 9:10 AM, Colin Perkins wrote:
>
> Section 3 has incorrectly formatted SDP examples (the "s=" lines).
>
> Colin
Maybe we should consider writing an SDP syntax validator
as a web service for www.apps.ietf.org, in the spirit of the
ABNF validator ... it would seem that enough WGs
produce I-Ds that include session description examples
that its worth the effort to making this checking automatic
instead of manual ...
---
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 Tue May 17 10:45:07 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1DY3Ji-0002IM-HR; Tue, 17 May 2005 10:45:06 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1DY3Jg-0002I3-Iw
for avt@megatron.ietf.org; Tue, 17 May 2005 10:45:04 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02281
for ; Tue, 17 May 2005 10:45:01 -0400 (EDT)
Received: from eagle.ericsson.se ([193.180.251.53])
by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY3aP-000348-RG
for avt@ietf.org; Tue, 17 May 2005 11:02:24 -0400
Received: from esealmw127.eemea.ericsson.se ([153.88.254.122])
by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id
j4HEikOG014595 for ; Tue, 17 May 2005 16:44:56 +0200
Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by
esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211);
Tue, 17 May 2005 16:44:55 +0200
Received: from [147.214.34.108] ([147.214.34.108]) by
esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211);
Tue, 17 May 2005 16:44:55 +0200
Message-ID: <428A0366.7010806@ericsson.com>
Date: Tue, 17 May 2005 16:44:54 +0200
From: Magnus Westerlund
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: IETF AVT WG
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 17 May 2005 14:44:55.0050 (UTC)
FILETIME=[FD6E2EA0:01C55AEE]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
Content-Transfer-Encoding: 7bit
Subject: [AVT] First bug in the RTP payload format for H.264 (RFC 3984)
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: ,
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org
Hi,
We authors have received a question that identifies an contradiction in
section 8.2.2:
One paragraph states:
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.
Two other states:
o Parameters used for declaring receiver capabilities are in general
downgradable; i.e., they express the upper limit for a sender's
possible behavior. Thus a sender MAY select to set its encoder
using only lower/lesser or equal values of these parameters.
"sprop-parameter-sets" MUST NOT be used in a sender's declaration
of its capabilities, as the limits of the values that are carried
inside the parameter sets are implicit with the profile and level
used.
o Parameters declaring a configuration point are not downgradable,
with the exception of the level part of the "profile-level-id"
parameter. This expresses values a receiver expects to be used
and must be used verbatim on the sender side.
As can be seen there is an inconsistency in the description in respect
to the level part of "profile-level-id" value included in any offer. The
two different interpretations that can be done are:
1. The answerer may change the level part of the profile-level-id value
in the answer.
2. Exactly the same profile-level-id string MUST be used in the answer.
However the media sender may use a lower level.
These two alternative interpretations could lead to a interoperability
issue, this needs to be clarified.
So the functional difference is that for alternative 1, the answerer can
accept a media type even if it only support a lower level than the
offerer, as long as the profile and restrictions match. However I don't
think that this work due to the fact that the offer assumes that a
certain level is supported. That assumption is used to when determining
the parameter-sets that the offerer intends to use when sending to the
answerer. So if the answerer is allowed to change level, new parameter
sets are needed to be sent to the answerer. Thus requiring a second
updated offer/answer exchange. So this can be used but require further
clarifications in text and indicating these requirements.
Alternative 2 also has the advantage that it will not cause any failures
even if either part has made the interpretation and gone for alternative 1.
So alternative 1 provides better functionality but at the cost of added
complexity and reduced interoperability. Using alternative 2 would be
safe from interoperability stand point.
So what do people say about this? I have no clear preference.
Cheers
Magnus Westerlund
Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
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 Tue May 17 12:26:12 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1DY4tY-0001aO-DX; Tue, 17 May 2005 12:26:12 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1DY4tW-0001aE-9L
for avt@megatron.ietf.org; Tue, 17 May 2005 12:26:10 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12031
for ; Tue, 17 May 2005 12:26:07 -0400 (EDT)
Received: from sj-iport-1-in.cisco.com ([171.71.176.70]
helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
id 1DY5AI-0000D8-Ni for avt@ietf.org; Tue, 17 May 2005 12:43:31 -0400
Received: from sj-core-1.cisco.com (171.71.177.237)
by sj-iport-1.cisco.com with ESMTP; 17 May 2005 09:24:06 -0700
X-IronPort-AV: i="3.93,114,1115017200";
d="scan'208"; a="636831898:sNHT2844754850"
Received: from edison.cisco.com (edison.cisco.com [171.71.180.109])
by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4HGO0ER010936;
Tue, 17 May 2005 09:24:00 -0700 (PDT)
Received: from dwingwxp ([10.32.240.195] (may be forged)) by edison.cisco.com
(8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA05911;
Tue, 17 May 2005 09:24:02 -0700 (PDT)
Message-Id: <200505171624.JAA05911@edison.cisco.com>
From: "Dan Wing"
To: "'Colin Perkins'"
Date: Tue, 17 May 2005 09:24:16 -0700
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Thread-Index: AcVaHBSIWeTtUomaTqmtipsXMeVAOQA38Avg
In-Reply-To: <6077bebac7bfc6f9950d040c3a953828@csperkins.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Content-Transfer-Encoding: 7bit
Cc: Flemming Andreasen , "'David R. Oran'" ,
'IETF AVT WG'
Subject: [AVT] RE: I-D ACTION:draft-wing-avt-rtp-noop-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: ,
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org
Colin,
Thanks for your comments. They have all been incorporated into -03 which
will appear in the Internet-Drafts archives shortly. The same file is
available immediately at:
http://scm.sipfoundry.org/rep/ietf-drafts/dwing/draft-wing-avt-rtp-noop.txt
http://scm.sipfoundry.org/rep/ietf-drafts/dwing/draft-wing-avt-rtp-noop.html
-d
> -----Original Message-----
> From: Colin Perkins [mailto:csp@csperkins.org]
> Sent: Monday, May 16, 2005 6:33 AM
> To: Dan Wing
> Cc: IETF AVT WG
> Subject: Re: I-D ACTION:draft-wing-avt-rtp-noop-02.txt
>
> On 9 May 2005, at 20:52, Internet-Drafts@ietf.org wrote:
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> >
> > Title : A No-op payload format for the
> Realtime Transport Protocol
> > Author(s) : F. Andreasen, et al.
> > Filename : draft-wing-avt-rtp-noop-02.txt
> > Pages : 12
> > Date : 2005-5-9
> >
> > This document defines an no-op payload format for the Real-time
> > Transport Protocol (RTP), and a mechanism to request an immediate
> > RTCP report. This can be used to verify RTP connectivity and to
> > keep
> > Network Address Translator (NAT) bindings and Firewall pinholes
> > open.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-wing-avt-rtp-noop-02.txt
>
> I have a few comments on this draft:
>
> Would it be possible to rename "Request Immediate RTCP" to "Request
> Early RTCP" throughout? This would clarify that the RTP/AVPF timing
> rules MUST be followed, and that applications cannot send the
> feedback
> immediately. This would also reduce concerns about congestion control.
>
> Similarly, it would help if bullet point 1 in section 2.6 stated
> clearly that "If the RTP/AVPF profile is not used the
> receiver MUST NOT
> send immediate feedback".
>
> Can you please change the title to use "RTP" rather than "Realtime
> Transport Protocol" for consistency with other drafts, and to make it
> easier to search for RTP-related RFCs. We have permission
> from the RFC
> Editor and IESG to use the acronym in draft titles.
>
> The definition of RFC 2119 key words should be placed at the
> end of the
> introduction, rather than being a separate section before the
> table of
> contents.
>
> Section 2.6 (second paragraph) has a typo ("Se""nd Immediate RTCP
> Report").
>
> Section 3 has incorrectly formatted SDP examples (the "s=" lines).
>
> Colin
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt
From avt-bounces@ietf.org Tue May 17 12:52:50 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1DY5JK-0008M7-5P; Tue, 17 May 2005 12:52:50 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1DY5JI-0008Lw-D5
for avt@megatron.ietf.org; Tue, 17 May 2005 12:52:48 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14759
for ; Tue, 17 May 2005 12:52:45 -0400 (EDT)
Received: from gate.eu.panasonic.com ([194.173.20.12]
helo=hhe500-02.hbg.de.pan.eu)
by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DY5a5-0001in-1J
for avt@ietf.org; Tue, 17 May 2005 13:10:09 -0400
Received: from eundadmi01.pan.eu(10.100.96.64) by hhe500-02.hbg.de.pan.eu via
smtp id 481c_ab8d94ae_c6e6_11d9_94a4_003048253456;
Tue, 17 May 2005 17:16:48 +0200 (CEST)
Received: from VPN-MRelay-01.PEL.Panasonic.de ([10.100.176.55])
by eundadmi01.pan.eu (Lotus Domino Release 6.5.2)
with ESMTP id 2005051716042300-91888 ;
Tue, 17 May 2005 16:04:23 +0200
Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PEL.Panasonic.de;
Tue, 17 May 2005 16:05:39 +0200
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Date: Tue, 17 May 2005 16:03:41 +0200
Message-ID: <9D277E44D6EF0942B928C6F0DE99BB31C84294@lan-ex-01.panasonic.de>
Thread-Topic: Update -14 of Timed Text draft
Thread-Index: AcVa6GmSgFFsdqojSn+AmWw8/OW41Q==
To: "IETF AVT WG"
From: "Jose Rey"
Content-Transfer-Encoding: quoted-printable
Content-class: urn:content-classes:message
Content-Type: text/plain;
charset="iso-8859-1"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Content-Transfer-Encoding: quoted-printable
Cc: Jan vanderMeer ,
Magnus Westerlund ,
"Y. Matsui" ,
Colin Perkins , Dave Singer
Subject: [AVT] Update -14 of Timed Text draft
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: ,
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org
Hi,
A new update has been sent to the ID manager. Unfortunately I cannot =
provide a link to a local copy, so you can retrieve it in a couple of =
days when it makes its way through the ID queue. =20
Shortly, changes comprise:
- updated boilerplate (minor correction)
- section "4.1.6 TYPE 5 Header" Removed that clients MAY display a text =
sample without a sample description, as this will never be the case =
given the new rules for placing sample descriptions.=20
- new section "4.2 Buffering of Sample Descriptions". The dynamic SIDX =
algo was included as a subsection here. It was also emphasized that the =
payload format requires codecs using this payload format (and specially =
TYPE 5 units) to implement the specified algorithm.=20
- Section "4.6 Aggregate Payloads" (moved from 4.5) : emphasizes that =
the proposed aggregates' configurations are ordered, simplified =
timestamping rules as per ML discusssion with Colin, changed figures and =
examples (4.7) accordingly.
Looking forward to WGLC,
Jos=E9
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt
From avt-bounces@ietf.org Tue May 17 15:43:52 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1DY7yq-0006zI-2K; Tue, 17 May 2005 15:43:52 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1DY7ym-0006y7-Fy; Tue, 17 May 2005 15:43:48 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01444;
Tue, 17 May 2005 15:43:46 -0400 (EDT)
Message-Id: <200505171943.PAA01444@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Date: Tue, 17 May 2005 15:43:45 -0400
Cc: avt@ietf.org
Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-ac3-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: ,
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Audio/Video Transport Working Group of the IETF.
Title : RTP Payload Format for AC-3 Audio
Author(s) : J. Flaks, et al.
Filename : draft-ietf-avt-rtp-ac3-03.txt
Pages : 10
Date : 2005-5-17
This document describes an RTP payload format for transporting AC-3
encoded audio data. AC-3 is a high quality, multichannel audio coding
system used in US HDTV, DVD, cable and satellite television and other
media. The RTP payload format as presented in this document includes
support for data fragmentation.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-ac3-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-ac3-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-ac3-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: <2005-5-17154030.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-avt-rtp-ac3-03.txt
--OtherAccess
Content-Type: Message/External-body; name="draft-ietf-avt-rtp-ac3-03.txt";
site="ftp.ietf.org"; access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <2005-5-17154030.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 May 17 15:44:21 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1DY7zJ-000728-H1; Tue, 17 May 2005 15:44:21 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1DY7zF-00071T-GN; Tue, 17 May 2005 15:44:17 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01474;
Tue, 17 May 2005 15:44:15 -0400 (EDT)
Message-Id: <200505171944.PAA01474@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Date: Tue, 17 May 2005 15:44:14 -0400
Cc: avt@ietf.org
Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-atrac-family-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: ,
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Audio/Video Transport Working Group of the IETF.
Title : RTP Payload Format for ATRAC Family
Author(s) : M. Romaine, et al.
Filename : draft-ietf-avt-rtp-atrac-family-03.txt
Pages : 22
Date : 2005-5-17
This document describes an RTP payload format for efficient and
flexible transporting of audio data encoded with the Adaptive
TRansform Audio Codec (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, auxiliary
data, and elementary redundancy measures.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-atrac-family-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-atrac-family-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-atrac-family-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: <2005-5-17154046.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-avt-rtp-atrac-family-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-avt-rtp-atrac-family-03.txt";
site="ftp.ietf.org"; access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <2005-5-17154046.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 May 17 16:45:17 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1DY8wH-0004dt-Dh; Tue, 17 May 2005 16:45:17 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1DY8wE-0004dU-Cc
for avt@megatron.ietf.org; Tue, 17 May 2005 16:45:14 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17793
for ; Tue, 17 May 2005 16:45:11 -0400 (EDT)
Received: from mail2.dolby.com ([204.156.147.24] helo=dolby.com)
by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY9D1-0001Nj-K9
for avt@ietf.org; Tue, 17 May 2005 17:02:37 -0400
Received: from ([172.16.33.28])
by silver.dolby.com with ESMTP id 5202052.134978;
Tue, 17 May 2005 13:44:35 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Subject: RE: [AVT] I-D ACTION:draft-ietf-avt-rtp-ac3-03.txt
Date: Tue, 17 May 2005 13:44:35 -0700
Message-ID: <5FCCC03CAF7C5C4C8E2F995E3D72E13304D96C94@platinum.dolby.net>
Thread-Topic: [AVT] I-D ACTION:draft-ietf-avt-rtp-ac3-03.txt
Thread-Index: AcVbHQnKf0Pf9IXhS521RPi+d/kgFAAA8oCg
From: "Link, Brian"
To:
Content-Type: text/plain;
charset="us-ascii"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Content-Transfer-Encoding: quoted-printable
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: ,
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org
Greetings,=0D=0A=0D=0AAs quoted below, there is a new revision of the I-D d=
efining the RTP=0D=0Apayload format for AC-3=2E The major change for this v=
ersion is the=0D=0Aremoval of the capability to carry SMPTE time stamps in =
a payload=0D=0Aspecific header=2E (I have also updated the IP boilerplate=
=2E)=0D=0A=0D=0AI believe this addresses all comments I have received about=
this I-D=2E If=0D=0Athere are any further comments, I'll be glad to addres=
s them=2E=0D=0A=0D=0ARegards,=0D=0ABrian=0D=0A=0D=0A---=0D=0ABrian Link=0D=
=0ADolby Laboratories, 100 Potrero Ave=2E, San Francisco, CA 94103=0D=0Apho=
ne: 415-558-0324 fax: 415-863-1373=0D=0Aemail: bdl@dolby=2Ecom alt email=
: link@ieee=2Eorg=0D=0A =0D=0A =0D=0A=0D=0A> -----Original Message-----=0D=
=0A> From: avt-bounces@ietf=2Eorg [mailto:avt-bounces@ietf=2Eorg] On =0D=0A=
> Behalf Of Internet-Drafts@ietf=2Eorg=0D=0A> Sent: Tuesday, May 17, 2005 1=
2:44 PM=0D=0A> To: i-d-announce@ietf=2Eorg=0D=0A> Cc: avt@ietf=2Eorg=0D=0A>=
Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-ac3-03=2Etxt=0D=0A> =0D=0A> A=
New Internet-Draft is available from the on-line =0D=0A> Internet-Drafts d=
irectories=2E=0D=0A> This draft is a work item of the Audio/Video Transport=
=0D=0A> Working Group of the IETF=2E=0D=0A> =0D=0A> Title : RTP Payload =
Format for AC-3 Audio=0D=0A> Author(s) : J=2E Flaks, et al=2E=0D=0A> File=
name : draft-ietf-avt-rtp-ac3-03=2Etxt=0D=0A> Pages : 10=0D=0A> Date : =
2005-5-17=0D=0A> =0D=0A> This document describes an RTP payload format for=
=0D=0A> transporting AC-3 encoded audio data=2E AC-3 is a high =0D=0A> qu=
ality, multichannel audio coding system used in US HDTV, =0D=0A> DVD, cable=
and satellite television and other media=2E The RTP =0D=0A> payload forma=
t as presented in this document includes support =0D=0A> for data fragmenta=
tion=2E=0D=0A> =0D=0A> A URL for this Internet-Draft is:=0D=0A> http://www=
=2Eietf=2Eorg/internet-drafts/draft-ietf-avt-rtp-ac3-03=2Etxt=0D=0A> =0D=0A=
> To remove yourself from the I-D Announcement list, send a =0D=0A> message=
to i-d-announce-request@ietf=2Eorg with the word =0D=0A> unsubscribe in th=
e body of the message=2E =0D=0A> You can also visit https://www1=2Eietf=2E=
org/mailman/listinfo/I-D-announce=0D=0A> to change your subscription settin=
gs=2E=0D=0A> =0D=0A> =0D=0A> Internet-Drafts are also available by anonymou=
s FTP=2E Login =0D=0A> with the username "anonymous" and a password of your=
e-mail =0D=0A> address=2E After logging in, type "cd internet-drafts" and =
then=0D=0A> "get draft-ietf-avt-rtp-ac3-03=2Etxt"=2E=0D=0A> =0D=0A> A list=
of Internet-Drafts directories can be found in =0D=0A> http://www=2Eietf=
=2Eorg/shadow=2Ehtml or =0D=0A> ftp://ftp=2Eietf=2Eorg/ietf/1shadow-sites=
=2Etxt=0D=0A> =0D=0A> =0D=0A> Internet-Drafts can also be obtained by e-mai=
l=2E=0D=0A> =0D=0A> Send a message to:=0D=0A> mailserv@ietf=2Eorg=2E=0D=0A=
> In the body type:=0D=0A> "FILE /internet-drafts/draft-ietf-avt-rtp-ac3-0=
3=2Etxt"=2E=0D=0A> =0D=0A> NOTE: The mail server at ietf=2Eorg can return =
the document in=0D=0A> MIME-encoded form by using the "mpack" utility=2E =
To use this=0D=0A> feature, insert the command "ENCODING mime" before the =
"FILE"=0D=0A> command=2E To decode the response(s), you will need "munpac=
k" or=0D=0A> a MIME-compliant mail reader=2E Different MIME-compliant =0D=
=0A> mail readers=0D=0A> exhibit different behavior, especially when deali=
ng with=0D=0A> "multipart" MIME messages (i=2Ee=2E documents which have be=
en split=0D=0A> up into multiple messages), so check your local documentat=
ion on=0D=0A> how to manipulate these messages=2E=0D=0A> =0D=0A> =0D=
=0A> Below is the data which will enable a MIME compliant mail reader=0D=0A=
> implementation to automatically retrieve the ASCII version of the=0D=0A> =
Internet-Draft=2E=0D=0A> =0D=0A=0D=0A--------------------------------------=
---=0D=0AThis message (including any attachments) may contain confidential=
=0D=0Ainformation intended for a specific individual and purpose=2E If you=
are not=0D=0Athe intended recipient, delete this message=2E If you are no=
t the intended=0D=0Arecipient, disclosing, copying, distributing, or taking=
any action based on=0D=0Athis message is strictly prohibited=2E=0D=0A
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt
From avt-bounces@ietf.org Tue May 17 17:01:10 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1DY9Ba-0004LM-1C; Tue, 17 May 2005 17:01:06 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1DY9BY-0004Kf-3X; Tue, 17 May 2005 17:01:04 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19608;
Tue, 17 May 2005 17:01:00 -0400 (EDT)
Received: from mail124.messagelabs.com ([85.158.136.19])
by ietf-mx.ietf.org with smtp (Exim 4.33)
id 1DY9SJ-0002SR-N6; Tue, 17 May 2005 17:18:26 -0400
X-VirusChecked: Checked
X-Env-Sender: gash@att.com
X-Msg-Ref: server-6.tower-124.messagelabs.com!1116363649!1956266!1
X-StarScan-Version: 5.4.15; banners=-,-,-
X-Originating-IP: [192.128.166.71]
Received: (qmail 23167 invoked from network); 17 May 2005 21:00:50 -0000
Received: from almso2.att.com (HELO almso2.proxy.att.com) (192.128.166.71)
by server-6.tower-124.messagelabs.com with SMTP;
17 May 2005 21:00:50 -0000
Received: from attrh5i.attrh.att.com ([135.38.62.12])
by almso2.proxy.att.com (AT&T IPNS/MLO-6.0) with ESMTP id
j4HKvcMl021366; Tue, 17 May 2005 17:00:49 -0400
Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by
attrh5i.attrh.att.com (7.2.052)
id 4287737400069A8A; Tue, 17 May 2005 17:00:49 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 17 May 2005 16:00:49 -0500
Message-ID: <9473683187ADC049A855ED2DA739ABCA09FA8DC5@KCCLUST06EVS1.ugd.att.com>
Thread-Topic: I-D ACTION:draft-ash-avt-hc-over-mpls-protocol-00.txt
Thread-Index: AcVGsK+ZB2HmnyVzRdmKlM478mx93gAB+qAAAAFCAXAAACNPsAAABc3AA9m5cPABOE/twA==
From: "Ash, Gerald R \(Jerry\), ALABS"
To: "Lars-Erik Jonsson \(LU/EAB\)" ,
,
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407
Content-Transfer-Encoding: quoted-printable
Cc: "Ash, Gerald R \(Jerry\), ALABS"
Subject: [AVT] RE: I-D ACTION:draft-ash-avt-hc-over-mpls-protocol-00.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: ,
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org
Hi Lars-Erik,
We really appreciate your thorough reviews and helpful suggestions.
> First of all, I must say you've done a great job with this update. The
> technical solution is starting to get in shape, and so also the draft
> itself. I just have a few issues that I believe should be given some
> additional attention, and I'll start with the least technical one:
>=20
> * References
> =20
> - There is one incorrect reference to RFC 3409, which I think has
> not much to do with this document. The correct document to refer
> to is RFC 3241, "Robust Header Compression (ROHC) over PPP".
>=20
> - There is one invalid reference [IPCP], I guess it should be
> [RFC1332]
>=20
> - As it is currently written, I believe [RFC3544] and [RFC3241]
> would be normative for this document. I believe some other
> references, e.g. some MPLS references, would also be normative.
>=20
> - There are many informative references, go through them and make
> sure they all are actually bringing any value as informative to
> this document (I am not sure about the MPLS references). It might
> also make sense to group them based on content (HD vs MPLS, etc),
> that would make it easier for the reader.
Agree to all the above suggestions.
=20
> * Separation of functionality
>=20
> As previously discussed, I believe it would be useful to more
> clearly separate negotiation/setup/signaling from encapsulation. As
> it now stands, I am not sure I understand what purpose the=20
> separation of chapter 2 and chapter 3 serves. Chapter 2 is about
> both setup and encapsulation, while chapter 3 is about setup only.
OK, perhaps we could map current Sections 2 and 3 into the following
sub-sections:
Section 2.1: link layer encapsulation type field (current Section 2.2)
Section 2.2: PW and HC scheme negotiation/setup/signaling (current
Sections 2.1 and 3)
Section 3: procedures summary (from "In Figure 1 ..." in current Section
2)
If you have another suggested organization, please let us know.
> * Requirements fulfillment
>=20
> In chapter 1, it is said that the outlined solution fulfils the
> requirements of [MPLS-HC-REQ]. I am not sure this listing is really
> needed, neither do I think it is fully correct.
>=20
> a) is true, that is a design decision for this document
> b) is also true, ok, it is the whole purpose of the document
> c) is not really achieved by this document, but depends on the
> header compression scheme used, and especially on how that
> scheme is implemented. This document can not guarantee anything
> in this regard, but it provides what it can to make this=20
> possible. What this document do indeed provide, is the
> mechanism to avoid multiple compression/decompression cycles,
> but that is b) above.
> d) "signal context identification", I do not know what is meant
> with that, neither do I know what standard protocols are referred
> to, is it the MPLS PW mechanisms that are meant, and/or the
> HC-over-PPP specifications (for the latter, see also below).
We can make it more clear that we meant to use existing CRTP, ECRTP or
ROHC procedures
to signal these natively. The nice thing about the approach is that it
achieves functional separation from the PW signaling.
> e) this is implementation dependent on HC-protocol level, and it
> is out of control of this specification, which is dependent on
> the HC scheme implementation(s). Or do PW provide means for=20
> in-order delivery?
Agreed that it is HC scheme dependent, however, PW does provide a means
for in-order delivery.
> Overall, I do not see the point of listing these things here. I
> think it is sufficient to say that the solution(s) outlined in
> this document have been designed and chosen to address the
> goals and requirements of [MPLS-HC-REQ].
We agree with your suggestion to replace the material with a statement
like the one above.
=20
> * "Flow Setup", end of chapter 2 introduction
>=20
> - Is this really only about "setup"? It does not look so to me.
>=20
> - I believe this can be generalized so that it is HC-scheme
> independent, should not be hard to do.
Agreed, we'll re-word to make it HC-scheme independent.
=20
> - It is not clear whether 2) is mandatory or not, i.e. is it
> mandatory to have a bidirectional connection?
We think it is mandatory to have a bidirectional connection for
CRTP/ECRTP/ROHC with feedback channel, and also for voice signaling and
flow control (RTCP).
=20
> * "Flow setup", last bullet, "Free up CID when flow terminates"
>=20
> - How can one ever know that a flow has terminated? For UDP-based
> "flows", there is no such thing. Also, why should one free
> CIDs, I agree CIDs should be re-usable, but if memory is
> allocated for a certain number of CIDs, that memory should
> last as long as the HC instance(s) is(are) alive. It is the
> compressor that may choose to re-use a CID. This has been
> thoroughly discussed in the ROHC WG, captured in chapter 7
> of .
Agreed. has a nice discussion on CID
re-use, which we'll reference.
> * Link layer packet type field
>=20
> The requirement that link layers must provide packet type
> identification for HC packets does not apply to ROHC. Therefore
> I believe it is an improper design to require the extra
> multiplexing byte (Pkt Typ field) for all schemes. There is
> a negotiation of HC scheme done for the "channel", so why not
> say that for schemes that can not identify their own packet
> types, the extra byte is needed, as described. Or actually
> negotiate whether to have this byte, independent of HC scheme
> (although some require it).
Dynamic negotiation of the multiplexing byte may require a bit more work
and complexity than is desirable. Since the gateways need to be
configured for each HC type anyway, we could follow this suggestion by
saying that the extra byte will be needed for those HC schemes that can
not identify their own packet type. That is, an extra byte will be
added by default once a certain HC type is configured.
=20
> * I think it makes sense to re-use the principles of RFC 3544 and
> RFC 3241, but I also think this document will actually have to
> define more specifically how the negotiation is done (with
> similar principles as in 3544 and 3241). Both RFC 3544 and RFC
> 3241 are written as plug-ins to the PPP control protocol IPCP,
> so just referring to them here where there is no PPP or IPCP
> does not convince me about the completeness of the solution.
Are you suggesting that we provide a more detailed specification to
extend the use of IPCP or similar scheme for HC parameter negotiation
over MPLS?
> Rgds,
> /L-E
Thanks again,
Regards,
Jerry
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt
From avt-bounces@ietf.org Wed May 18 01:44:31 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1DYHM7-0007ea-5U; Wed, 18 May 2005 01:44:31 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1DYHM4-0007eS-S6
for avt@megatron.ietf.org; Wed, 18 May 2005 01:44:29 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29851
for ; Wed, 18 May 2005 01:44:26 -0400 (EDT)
Received: from ns8.sony.co.jp ([137.153.0.33])
by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYHcw-0004uE-SR
for avt@ietf.org; Wed, 18 May 2005 02:01:55 -0400
Received: from mail21.sony.co.jp (mail21.sony.co.jp [43.0.1.221])
Received: from mail21.sony.co.jp (localhost [127.0.0.1])
by mail21.sony.co.jp (R8/Sony) with ESMTP id j4I5iIPS015084
for ; Wed, 18 May 2005 14:44:18 +0900 (JST)
Received: from jptkyxim01.jp.sony.com (jptkyxim01.jp.sony.com [43.15.17.87])
by mail21.sony.co.jp (R8/Sony) with ESMTP id j4I5iINd015081
for ; Wed, 18 May 2005 14:44:18 +0900 (JST)
Received: from jptkyxwa05.jp.sony.com ([43.15.31.5]) by jptkyxim01.jp.sony.com
with Microsoft SMTPSVC(5.0.2195.6881);
Wed, 18 May 2005 14:44:18 +0900
Received: from [43.13.117.153] ([43.13.117.153]) by jptkyxwa05.jp.sony.com
with Microsoft SMTPSVC(5.0.2195.6881);
Wed, 18 May 2005 14:44:18 +0900
Mime-Version: 1.0 (Apple Message framework v721)
References: <200505171944.PAA01474@ietf.org>
Content-Type: text/plain; charset=UTF-8; delsp=yes; format=flowed
Message-Id: <612FD92E-3ED5-4518-8C32-5B08C8F3E58D@jp.sony.com>
Content-Transfer-Encoding: quoted-printable
From: Matthew Romaine
Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-rtp-atrac-family-03.txt
Date: Wed, 18 May 2005 14:42:57 +0900
To: avt@ietf.org
X-Mailer: Apple Mail (2.721)
X-OriginalArrivalTime: 18 May 2005 05:44:18.0125 (UTC)
FILETIME=[A1EDF7D0:01C55B6C]
X-Spam-Score: 2.2 (++)
X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f
Content-Transfer-Encoding: quoted-printable
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: ,
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org
Hi all,
As noted below, there is a new revision of the ID outlining a payload =20=
for ATRAC content. Key changes include clarifying the SDP parameters =20=
and Offer/Answer exchange. An auxiliary data section has also been =20
added.
Would appreciate any comments from the community. We have most of =20
the draft implemented, so whatever else needs to happen before last =20
call I'm ready to address.
Cheers,
Matt
Begin forwarded message:
> From: Internet-Drafts@ietf.org
> Date: 2005=E5=B9=B45=E6=9C=8818=E6=97=A5 4:44:14:JST
> To: i-d-announce@ietf.org
> Cc: avt@ietf.org
> Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-atrac-family-03.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts =20
> directories.
> This draft is a work item of the Audio/Video Transport Working =20
> Group of the IETF.
>
> Title : RTP Payload Format for ATRAC Family
> Author(s) : M. Romaine, et al.
> Filename : draft-ietf-avt-rtp-atrac-family-03.txt
> Pages : 22
> Date : 2005-5-17
>
> This document describes an RTP payload format for efficient and
> flexible transporting of audio data encoded with the Adaptive
> TRansform Audio Codec (ATRAC) family of codecs. Recent =20
> enhancements
> to the ATRAC family of codecs support high quality audio coding =20
> with
> multiple channels. The RTP payload format as presented in this
> document also includes support for data fragmentation, auxiliary
> data, and elementary redundancy measures.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-atrac-=20
> family-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 =20=
> 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 =20=
> 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-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-atrac-family-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 =20
> 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.
> Content-Type: text/plain
> Content-ID: <2005-5-17154046.I-D@ietf.org>
>
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www1.ietf.org/mailman/listinfo/avt
-------------------------------------------
Tel: +81-3-5448-6065
Fax: +81-3-5448-5617
ITCNC PCD Audio Codec Dev Dept.1
Sony Corporation, Japan
-------------------------------------------
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt
From avt-bounces@ietf.org Wed May 18 10:29:44 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1DYPYO-0004OO-5G; Wed, 18 May 2005 10:29:44 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1DYPYM-0004OJ-DJ
for avt@megatron.ietf.org; Wed, 18 May 2005 10:29:42 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25855
for ; Wed, 18 May 2005 10:29:40 -0400 (EDT)
Received: from fw.polycom.co.il ([212.179.41.2]
helo=isrexch01.israel.polycom.com)
by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYPpJ-0001Ug-Ab
for avt@ietf.org; Wed, 18 May 2005 10:47:14 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
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] First bug in the RTP payload format for H.264 (RFC 3984)
Date: Wed, 18 May 2005 17:30:28 +0300
Message-ID: <144ED8561CE90C41A3E5908EDECE315C01AE2CE0@IsrExch01.israel.polycom.com>
Thread-Topic: [AVT] First bug in the RTP payload format for H.264 (RFC 3984)
Thread-Index: AcVa76MSGrewD1u8SzKu2/O923HWCgAxitMw
From: "Even, Roni"
To: "Magnus Westerlund" ,
"IETF AVT WG"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0
Content-Transfer-Encoding: quoted-printable
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: ,
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org
Magnus,
I asked in Polycom the feedback is:
Alternative 1 seems like the best choice. The Offer/Answer is really
just a caps exchange and we are telling the remote side in the answer
what we can accept.
>From RFC 3264:
8.3.4 Changing Attributes
Any other attributes in a media description MAY be updated in an
offer or answer. Generally, an agent MUST send media (if the
directionality of the stream allows) using the new parameters once the
SDP with the change is received.
Alternative 2 does not sound good as it says the answer must have the
exact same profile-level-id. If we do not support receiving that
profile-level-id then it would appear we would either have to remove
H.264 from the media line, or reject that media line and answer with a
new one.
Roni Even
-----Original Message-----
From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of
Magnus Westerlund
Sent: Tuesday, May 17, 2005 5:45 PM
To: IETF AVT WG
Subject: [AVT] First bug in the RTP payload format for H.264 (RFC 3984)
Hi,
We authors have received a question that identifies an contradiction in=20
section 8.2.2:
One paragraph states:
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.
Two other states:
o Parameters used for declaring receiver capabilities are in
general
downgradable; i.e., they express the upper limit for a sender's
possible behavior. Thus a sender MAY select to set its encoder
using only lower/lesser or equal values of these parameters.
"sprop-parameter-sets" MUST NOT be used in a sender's declaration
of its capabilities, as the limits of the values that are carried
inside the parameter sets are implicit with the profile and level
used.
o Parameters declaring a configuration point are not downgradable,
with the exception of the level part of the "profile-level-id"
parameter. This expresses values a receiver expects to be used
and must be used verbatim on the sender side.
As can be seen there is an inconsistency in the description in respect=20
to the level part of "profile-level-id" value included in any offer. The
two different interpretations that can be done are:
1. The answerer may change the level part of the profile-level-id value=20
in the answer.
2. Exactly the same profile-level-id string MUST be used in the answer.=20
However the media sender may use a lower level.
These two alternative interpretations could lead to a interoperability=20
issue, this needs to be clarified.
So the functional difference is that for alternative 1, the answerer can
accept a media type even if it only support a lower level than the=20
offerer, as long as the profile and restrictions match. However I don't=20
think that this work due to the fact that the offer assumes that a=20
certain level is supported. That assumption is used to when determining=20
the parameter-sets that the offerer intends to use when sending to the=20
answerer. So if the answerer is allowed to change level, new parameter=20
sets are needed to be sent to the answerer. Thus requiring a second=20
updated offer/answer exchange. So this can be used but require further=20
clarifications in text and indicating these requirements.
Alternative 2 also has the advantage that it will not cause any failures
even if either part has made the interpretation and gone for alternative
1.
So alternative 1 provides better functionality but at the cost of added=20
complexity and reduced interoperability. Using alternative 2 would be=20
safe from interoperability stand point.
So what do people say about this? I have no clear preference.
Cheers
Magnus Westerlund
Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
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
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt
From avt-bounces@ietf.org Wed May 18 11:00:52 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1DYQ2V-0006op-VU; Wed, 18 May 2005 11:00:51 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1DYQ2U-0006lu-4N
for avt@megatron.ietf.org; Wed, 18 May 2005 11:00:50 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29105
for ; Wed, 18 May 2005 11:00:47 -0400 (EDT)
Received: from albatross.ericsson.se ([193.180.251.49])
by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYQJQ-0003JM-B9
for avt@ietf.org; Wed, 18 May 2005 11:18:22 -0400
Received: from esealmw126.eemea.ericsson.se ([153.88.254.123])
by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id
j4IF00jk016597
for ; Wed, 18 May 2005 17:00:46 +0200 (MEST)
Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by
esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211);
Wed, 18 May 2005 17:00:42 +0200
Received: from [147.214.34.108] ([147.214.34.108]) by
esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211);
Wed, 18 May 2005 17:00:41 +0200
Message-ID: <428B5899.4080403@ericsson.com>
Date: Wed, 18 May 2005 17:00:41 +0200
From: Magnus Westerlund
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: IETF AVT WG
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 18 May 2005 15:00:41.0967 (UTC)
FILETIME=[5C3FFFF0:01C55BBA]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Content-Transfer-Encoding: 7bit
Subject: [AVT] Working Group Last Call:
draft-ietf-avt-rtp-3gpp-timed-text-14.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: ,
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org
This is to announce a working group last call on the RTP Payload Format
for 3GPP Timed Text. Please send any final comments on this draft to the
mailing list by 1st June 2005. If no substantive technical comments are
received by that time, we intend to request the IESG to consider this
for publication as a proposed standard RFC.
Regards
Magnus Westerlund
Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
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 May 18 11:11:42 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1DYQD0-00020m-Eq; Wed, 18 May 2005 11:11:42 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1DYQCw-00020W-GJ
for avt@megatron.ietf.org; Wed, 18 May 2005 11:11:40 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29940
for ; Wed, 18 May 2005 11:11:36 -0400 (EDT)
Received: from albatross.ericsson.se ([193.180.251.49])
by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYQTl-0003qJ-1u
for avt@ietf.org; Wed, 18 May 2005 11:29:11 -0400
Received: from esealmw128.eemea.ericsson.se ([153.88.254.121])
by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id
j4IFAffo018919
for ; Wed, 18 May 2005 17:10:41 +0200 (MEST)
Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by
esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211);
Wed, 18 May 2005 17:10:39 +0200
Received: from [147.214.34.108] ([147.214.34.108]) by
esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211);
Wed, 18 May 2005 17:10:39 +0200
Message-ID: <428B5AEF.2030905@ericsson.com>
Date: Wed, 18 May 2005 17:10:39 +0200
From: Magnus Westerlund
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: IETF AVT WG
Subject: Re: [AVT] Working Group Last Call:
draft-ietf-avt-rtp-3gpp-timed-text-14.txt
References: <428B5899.4080403@ericsson.com>
In-Reply-To: <428B5899.4080403@ericsson.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 18 May 2005 15:10:39.0665 (UTC)
FILETIME=[C0817A10:01C55BBB]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Content-Transfer-Encoding: 7bit
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group