From exim@www1.ietf.org  Wed Oct  1 04:11:33 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02371
	for <avt-archive@odin.ietf.org>; Wed, 1 Oct 2003 04:11:33 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4c4j-00089r-Oh
	for avt-archive@odin.ietf.org; Wed, 01 Oct 2003 04:11:10 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h918B9aX031353
	for avt-archive@odin.ietf.org; Wed, 1 Oct 2003 04:11:09 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4c4c-000898-NW; Wed, 01 Oct 2003 04:11:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4c3w-000889-HJ
	for avt@optimus.ietf.org; Wed, 01 Oct 2003 04:10:20 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02352
	for <avt@ietf.org>; Wed, 1 Oct 2003 04:10:13 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4c3t-0003lM-00
	for avt@ietf.org; Wed, 01 Oct 2003 04:10:17 -0400
Received: from [220.117.193.11] (helo=mail.nextreaming.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4c3t-0003kn-00
	for avt@ietf.org; Wed, 01 Oct 2003 04:10:17 -0400
Content-Class: urn:content-classes:message
Subject: [AVT] RTPtimescale override in dynamic payload type
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Date: Wed, 1 Oct 2003 17:09:45 +0900
Message-ID: <F286138BFB1A724ABDD9F0A27978ED1C394CF3@lapis.nextreaming.com>
Thread-Topic: [AVT] RTPtimescale override in dynamic payload type
Thread-Index: AcOH82XBoTXh/f1oRdSICLy6w5Nncg==
From: "Jae-Hwan Kim" <kjh1905m@nextreaming.com>
To: <avt@ietf.org>
Content-Transfer-Encoding: quoted-printable
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable

Dear experts,

Is the following discussion true? i.e. Can we override RTP timescale if
we use dynamic payload type?

For example, despite of no static payload type, RTP payload document
about H.263 only allows 90000 timescale.
In many interoperability tests, other values except 90000 have not been
allowed. But I should have checked out the exact definition of 'dynamic
payload type'. I would appriciate you for a straight solution on this.

In addition, can we use dynamic payload type about a media defined as
static. For example, RFC 3551 newly defines QCELP has static payload
type value,12, but dynamic value has been used before. e.g. 96. For the
backward compatibility, can we use the old payload type instead of new
payload type? It seems to have been discussed before but I could not
find it exactly.

Thanks in advance,

-Jae-Hwan


------------<snip>------------------------------------------------------
------
To: <avt@ietf.org>, "Ross Finlayson" <finlayson@live.com>=20
Subject: Re: [AVT] Can the 'rtpmap' timestamp frequency override static
payload type's default frequency?=20
From: "M. Reha Civanlar" <civanlar@research.att.com>=20
Date: Wed, 9 Jan 2002 17:20:26 -0500=20
Cc: <wmay@cisco.com>=20
List-Id: Audio/Video Transport Working Group <avt.ietf.org>=20
Organization: AT&T Labs - Research=20
References: <4.3.1.1.20020108195131.00c8be90@localhost>=20
Reply-To: "M. Reha Civanlar" <civanlar@research.att.com>=20
Sender: avt-admin@ietf.org=20

------------------------------------------------------------------------
--------

Yes, it would have been "more legal" (if there is such a thing :-) if it
had
used a dynamic payload type for this purpose. As decided in the London
meeting, I am supposed to update RFC 2250 to explicitly state that "any
clock rate can be specified out-of-band using a dynamic payload type
with
the payload formats defined in RFC 2250." Then, it will be "really
legal."

------------------------------------------------------------------------
----
------
M. Reha Civanlar
Division Manager
Speech & Image Processing Services Research Lab
AT&T Labs - Research
200 Laurel Ave. South, A5 4D04
Middletown, NJ 07748
+1 732 420 9170    Fax: +1 732 368 9456
civanlar@research.att.com
http://www.research.att.com/info/mrc


----- Original Message -----
From: "Ross Finlayson" <finlayson@live.com>
To: <avt@ietf.org>
Cc: <wmay@cisco.com>
Sent: Tuesday, January 08, 2002 11:00 PM
Subject: [AVT] Can the 'rtpmap' timestamp frequency override static
payload
type's default frequency?


> Today I saw the following lines in a session's SDP description:
> m=3Daudio 0 RTP/AVP 14
> a=3Drtpmap:14 MPA/22050
>
> I.e., the session was using the standard MPEG audio payload format (as
> defined in RFC2250), but with a RTP timestamp frequency of 22050
instead
of
> 90000.
>
> My question: Is this legal?  Section 4.5.13 of
> <draft-ietf-avt-profile-new-12.txt> states
> 4.5.13 MPA
> ...
> The RTP timestamp clock rate is always 90000,
> independent of the sampling rate.
> which suggests that it's not legal to use a RTP timestamp frequency
other
> than 90000 for MPA (and MPV, although
<draft-ietf-avt-profile-new-12.txt>
> is less explicit in this case).
>
> If the above SDP is not legal, would it have been any more legal if it
had
said
> m=3Daudio 0 RTP/AVP 96
> a=3Drtpmap:96 MPA/22050
> i.e., using a dynamic payload type instead of the static payload type
(14)
> for MPA?
>
> Ross.
>
>
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> http://www1.ietf.org/mailman/listinfo/avt
>


_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
http://www1.ietf.org/mailman/listinfo/avt


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



From exim@www1.ietf.org  Wed Oct  1 07:57:31 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09108
	for <avt-archive@odin.ietf.org>; Wed, 1 Oct 2003 07:57:31 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4fbQ-0002qW-Oc
	for avt-archive@odin.ietf.org; Wed, 01 Oct 2003 07:57:09 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h91Bv8QT010936
	for avt-archive@odin.ietf.org; Wed, 1 Oct 2003 07:57:08 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4fbI-0002po-Pv; Wed, 01 Oct 2003 07:57:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4faq-0002pV-J2
	for avt@optimus.ietf.org; Wed, 01 Oct 2003 07:56:36 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09088
	for <avt@ietf.org>; Wed, 1 Oct 2003 07:56:24 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4fap-000660-00
	for avt@ietf.org; Wed, 01 Oct 2003 07:56:31 -0400
Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4fap-00065x-00
	for avt@ietf.org; Wed, 01 Oct 2003 07:56:31 -0400
Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121])
	by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h91BuQlN007730;
	Wed, 1 Oct 2003 13:56:27 +0200 (MEST)
Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55)
	id T6YNAV5Z; Wed, 1 Oct 2003 13:57:20 +0200
Message-ID: <3F7AC0E8.9030903@ericsson.com>
Date: Wed, 01 Oct 2003 13:56:24 +0200
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jae-Hwan Kim <kjh1905m@nextreaming.com>
CC: avt@ietf.org
Subject: Re: [AVT] RTPtimescale override in dynamic payload type
References: <F286138BFB1A724ABDD9F0A27978ED1C394CF3@lapis.nextreaming.com>
In-Reply-To: <F286138BFB1A724ABDD9F0A27978ED1C394CF3@lapis.nextreaming.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hi,

See below:

Jae-Hwan Kim wrote:

> Dear experts,
> 
> Is the following discussion true? i.e. Can we override RTP timescale if
> we use dynamic payload type?
> 
> For example, despite of no static payload type, RTP payload document
> about H.263 only allows 90000 timescale.
> In many interoperability tests, other values except 90000 have not been
> allowed. But I should have checked out the exact definition of 'dynamic
> payload type'. I would appriciate you for a straight solution on this.
> 

The clock rate for the RTP timestamp is dependent on the payload format. 
  I agree with your assesment that H.263 does not allow any other clock 
rate then 90 kHz. In cases the payload format does not allow other rates 
the rate can't be redefined.

> In addition, can we use dynamic payload type about a media defined as
> static. For example, RFC 3551 newly defines QCELP has static payload
> type value,12, but dynamic value has been used before. e.g. 96. For the
> backward compatibility, can we use the old payload type instead of new
> payload type? It seems to have been discussed before but I could not
> find it exactly.

There is a section about this in RFC 3551:
   "This profile reserves payload type numbers in the range 96-127
    exclusively for dynamic assignment.  Applications SHOULD first use
    values in this range for dynamic payload types.  Those applications
    which need to define more than 32 dynamic payload types MAY bind
    codes below 96, in which case it is RECOMMENDED that unassigned
    payload type numbers be used first.  However, the statically assigned
    payload types are default bindings and MAY be dynamically bound to
    new encodings if needed.  Redefining payload types below 96 may cause
    incorrect operation if an attempt is made to join a session without
    obtaining session description information that defines the dynamic
    payload types."

So I don't see a problem of using SDP to define a that QCELP will use a 
dynamically assigned number in the range 96-127. I don't understand what 
you mean with old payload type. If dynamic payload types where used 
before the actually used number are only valid for that RTP session.


Best 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 exim@www1.ietf.org  Wed Oct  1 09:24:31 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11682
	for <avt-archive@odin.ietf.org>; Wed, 1 Oct 2003 09:24:31 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4gxa-00084u-Bz
	for avt-archive@odin.ietf.org; Wed, 01 Oct 2003 09:24:07 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h91DO6p3031051
	for avt-archive@odin.ietf.org; Wed, 1 Oct 2003 09:24:06 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4gxV-00084Q-Jp; Wed, 01 Oct 2003 09:24:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4SjI-00010P-EP
	for avt@optimus.ietf.org; Tue, 30 Sep 2003 18:12:25 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18616
	for <avt@ietf.org>; Tue, 30 Sep 2003 18:12:14 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4SjF-00061H-00
	for avt@ietf.org; Tue, 30 Sep 2003 18:12:21 -0400
Received: from almso2.att.com ([192.128.166.71] helo=almso2.proxy.att.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4SjE-000614-00
	for avt@ietf.org; Tue, 30 Sep 2003 18:12:20 -0400
Received: from attrh5i.attrh.att.com ([135.38.62.12])
	by almso2.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id h8UM9DwS005211
	for <avt@ietf.org>; Tue, 30 Sep 2003 18:11:50 -0400
Received: from KCCLUST06EVS1.ugd.att.com (135.38.164.89) by attrh5i.attrh.att.com (6.5.032)
        id 3F307C6C00F64C37; Tue, 30 Sep 2003 18:11:34 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 30 Sep 2003 17:11:50 -0500
Message-ID: <9473683187ADC049A855ED2DA739ABCA0201EE9D@KCCLUST06EVS1.ugd.att.com>
Thread-Topic: [AVT] I-D ACTION:draft-ash-e2e-voip-hdr-comp-rqmts-01.txt
Thread-Index: AcOHinolNpLyunfATWyKD/3J60KfDwAELO3w
From: "Ash, Gerald R (Jerry), ALABS" <gash@att.com>
To: <avt@ietf.org>
Cc: "Ash, Gerald R (Jerry), ALABS" <gash@att.com>,
        "GOODE, B (Bur), ALABS" <bgoode@att.com>,
        "Hand, James C, ALABS" <jameshand@att.com>,
        "Jim Hand" <hand17@earthlink.net>, "raymond zhang" <zhangr@info.net>,
        "George Swallow" <swallow@cisco.com>
Content-Transfer-Encoding: quoted-printable
Subject: [AVT] RE: I-D ACTION:draft-ash-e2e-voip-hdr-comp-rqmts-01.txt
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable

All,

Please review the updated 01 version of the 'Requirements for VoIP =
Header Compression over Multiple-Hop Paths' =
http://www.ietf.org/internet-drafts/draft-ash-e2e-voip-hdr-comp-rqmts-01.=
txt. =20

The update is in response to the AVT proposed charter items, where these =
milestones have been tentatively added to the charter:

Nov 2003 Initial draft requirements for ECRTP over MPLS; discuss with =
MPLS WG
Mar 2004 Finish requirements for ECRTP over MPLS; re-charter for =
subsequent work

These are the main changes/updates from the 00 version:

1. Changed the terminology of 'end-to-end VoIP header compression' to =
'VoIP header compression from compressor to decompressor over =
multiple-hop paths'.  The 'end-to-end' terminology caused some confusion =
at IETF-57.
2. Expanded the introduction to be more descriptive of the problem and =
background.
3. Added Section 2 on 'scenarios'.
4. Added 'goals' to Section 3, and made the requirements more specific =
(e.g., added tentative performance requirements for delay, jitter and =
packet loss).
5. Put a brief summary of 'proposed solutions' in Appendix A (for =
convenience of the reader).

Please let us know your comments and suggestions.

Thanks,
Jerry Ash

-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
Sent: Tuesday, September 30, 2003 3:38 PM
Cc: avt@ietf.org
Subject: [AVT] I-D ACTION:draft-ash-e2e-voip-hdr-comp-rqmts-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts =
directories.

	Title		: Requirements for VoIP Header Compression over=20
                          Multiple-Hop Paths
	Author(s)	: J. Ash et al.=20
	Filename	: draft-ash-e2e-voip-hdr-comp-rqmts-01.txt
	Pages		: 0
	Date		: 2003-9-30
=09
VoIP typically uses the encapsulation voice/RTP/UDP/IP/.  When MPLS=20
labels are added, this becomes voice/RTP/UDP/IP/MPLS-labels.  For an=20
MPLS VPN, the packet header is at least 48 bytes, while the voice=20
payload is often no more than 30 bytes.  VoIP header compression can=20
significantly reduce the VoIP overhead through various compression=20
mechanisms.  This is important on access links where bandwidth is=20
scarce, and can be important on backbone facilities, especially where=20
costs are high (e.g., some global cross-sections).  Providing VoIP=20
header compression over multiple hop paths avoids multiple=20
compression/decompression cycles at each router, and thereby increases=20
the processing scalability of the maximum number of simultaneous VoIP=20
flows which use header compression at each router.  This draft gives a=20
problem statement, example scenarios, goals, and requirements for VoIP=20
header compression from compressor to decompressor over multiple-hop=20
paths, possibly over MPLS.  It also discusses work items and issues for=20
consideration, and highlights various solution alternatives that have=20
been proposed.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ash-e2e-voip-hdr-comp-rqmts-01.=
txt

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



From exim@www1.ietf.org  Wed Oct  1 09:39:33 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12160
	for <avt-archive@odin.ietf.org>; Wed, 1 Oct 2003 09:39:33 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4hC7-0000qH-As
	for avt-archive@odin.ietf.org; Wed, 01 Oct 2003 09:39:10 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h91Dd7Ok003238
	for avt-archive@odin.ietf.org; Wed, 1 Oct 2003 09:39:07 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4hC1-0000mc-Be; Wed, 01 Oct 2003 09:39:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4hBq-0000mH-Rz
	for avt@optimus.ietf.org; Wed, 01 Oct 2003 09:38:50 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12098
	for <avt@ietf.org>; Wed, 1 Oct 2003 09:38:43 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4hBo-00076u-00
	for avt@ietf.org; Wed, 01 Oct 2003 09:38:48 -0400
Received: from [220.117.193.11] (helo=mail.nextreaming.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4hBo-00076M-00
	for avt@ietf.org; Wed, 01 Oct 2003 09:38:48 -0400
Content-Class: urn:content-classes:message
Subject: RE: [AVT] RTPtimescale override in dynamic payload type
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 1 Oct 2003 22:38:22 +0900
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Message-ID: <F286138BFB1A724ABDD9F0A27978ED1C394D44@lapis.nextreaming.com>
Thread-Topic: [AVT] RTPtimescale override in dynamic payload type
Thread-Index: AcOIExE+tyjDcp6hSx2GYyZjRS765AACqTOg
From: "Jae-Hwan Kim" <kjh1905m@nextreaming.com>
To: "Magnus Westerlund" <magnus.westerlund@ericsson.com>
Cc: <avt@ietf.org>
Content-Transfer-Encoding: quoted-printable
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable


Hi! Magnus,

Thanks a lot for your fast response but I am still in a mist.
I found a message from AVT mail archive. Please read the below first.

------------------------------------------------------------------------
> Today I saw the following lines in a session's SDP description:=20
> m=3Daudio 0 RTP/AVP 14 a=3Drtpmap:14 MPA/22050
>
> I.e., the session was using the standard MPEG audio payload format (as

> defined in RFC2250), but with a RTP timestamp frequency of 22050
instead
of
> 90000.
>
> My question: Is this legal?  Section 4.5.13 of=20
> <draft-ietf-avt-profile-new-12.txt> states 4.5.13 MPA
> ...
> The RTP timestamp clock rate is always 90000,
> independent of the sampling rate.
> which suggests that it's not legal to use a RTP timestamp frequency
other
> than 90000 for MPA (and MPV, although
<draft-ietf-avt-profile-new-12.txt>
> is less explicit in this case).
>
> If the above SDP is not legal, would it have been any more legal if it
had
said
> m=3Daudio 0 RTP/AVP 96
> a=3Drtpmap:96 MPA/22050
> i.e., using a dynamic payload type instead of the static payload type
(14)
> for MPA?

Yes, it would have been "more legal" (if there is such a thing :-) if it
had used a dynamic payload type for this purpose. As decided in the
London meeting, I am supposed to update RFC 2250 to explicitly state
that "any clock rate can be specified out-of-band using a dynamic
payload type with the payload formats defined in RFC 2250." Then, it
will be "really legal."
------------------------------------------------------------------------
Because I could not find any other threads about this discussion, I
would like to ask you whether above answer is correct or not. It sounds
like, "we can override RTP timescale if we use dynamic payload type
although the payload format allows only a specific timescale". It is
somewhat reasonable but it seems to be different from many other's
knowledge on it. Is it right? If I'm wrong, could you interpret it more
clearly?=20

Best Regards,
Jae-Hwan


-----Original Message-----
From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20
Sent: Wednesday, October 01, 2003 8:56 PM
To: Jae-Hwan Kim
Cc: avt@ietf.org
Subject: Re: [AVT] RTPtimescale override in dynamic payload type


Hi,

See below:

Jae-Hwan Kim wrote:

> Dear experts,
>=20
> Is the following discussion true? i.e. Can we override RTP timescale=20
> if we use dynamic payload type?
>=20
> For example, despite of no static payload type, RTP payload document=20
> about H.263 only allows 90000 timescale. In many interoperability=20
> tests, other values except 90000 have not been allowed. But I should=20
> have checked out the exact definition of 'dynamic payload type'. I=20
> would appriciate you for a straight solution on this.
>=20

The clock rate for the RTP timestamp is dependent on the payload format.

  I agree with your assesment that H.263 does not allow any other clock=20
rate then 90 kHz. In cases the payload format does not allow other rates

the rate can't be redefined.

> In addition, can we use dynamic payload type about a media defined as=20
> static. For example, RFC 3551 newly defines QCELP has static payload=20
> type value,12, but dynamic value has been used before. e.g. 96. For=20
> the backward compatibility, can we use the old payload type instead of

> new payload type? It seems to have been discussed before but I could=20
> not find it exactly.

There is a section about this in RFC 3551:
   "This profile reserves payload type numbers in the range 96-127
    exclusively for dynamic assignment.  Applications SHOULD first use
    values in this range for dynamic payload types.  Those applications
    which need to define more than 32 dynamic payload types MAY bind
    codes below 96, in which case it is RECOMMENDED that unassigned
    payload type numbers be used first.  However, the statically
assigned
    payload types are default bindings and MAY be dynamically bound to
    new encodings if needed.  Redefining payload types below 96 may
cause
    incorrect operation if an attempt is made to join a session without
    obtaining session description information that defines the dynamic
    payload types."

So I don't see a problem of using SDP to define a that QCELP will use a=20
dynamically assigned number in the range 96-127. I don't understand what

you mean with old payload type. If dynamic payload types where used=20
before the actually used number are only valid for that RTP session.


Best 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 exim@www1.ietf.org  Wed Oct  1 11:54:31 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20607
	for <avt-archive@odin.ietf.org>; Wed, 1 Oct 2003 11:54:31 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4jIl-0001C0-ST
	for avt-archive@odin.ietf.org; Wed, 01 Oct 2003 11:54:08 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h91Fs7Hr004580
	for avt-archive@odin.ietf.org; Wed, 1 Oct 2003 11:54:07 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4jIf-0001BF-Ll; Wed, 01 Oct 2003 11:54:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4jIP-0001Ak-9i
	for avt@optimus.ietf.org; Wed, 01 Oct 2003 11:53:45 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20586
	for <avt@ietf.org>; Wed, 1 Oct 2003 11:53:37 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4jIN-0001ID-00
	for avt@ietf.org; Wed, 01 Oct 2003 11:53:43 -0400
Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4jIN-0001IA-00
	for avt@ietf.org; Wed, 01 Oct 2003 11:53:43 -0400
Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121])
	by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h91FrflN024655;
	Wed, 1 Oct 2003 17:53:42 +0200 (MEST)
Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55)
	id T6YNDJ0T; Wed, 1 Oct 2003 17:54:36 +0200
Message-ID: <3F7AF882.10909@ericsson.com>
Date: Wed, 01 Oct 2003 17:53:38 +0200
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jae-Hwan Kim <kjh1905m@nextreaming.com>
CC: avt@ietf.org
Subject: Re: [AVT] RTPtimescale override in dynamic payload type
References: <F286138BFB1A724ABDD9F0A27978ED1C394D44@lapis.nextreaming.com>
In-Reply-To: <F286138BFB1A724ABDD9F0A27978ED1C394D44@lapis.nextreaming.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hi Kim,

I think my response was correct in regards to the discussion you cited. 
The discussion seem to be in the context of RFC 2250 and especially the 
audio layers in MPEG-1. If one looks at the following updated MIME type 
registration from RFC 3555 one can clearly see that using any RTP 
timestamp rate other than 90000 is not allowed:

"4.1.17. Registration of MIME media type audio/MPA

    MIME media type name: audio

    MIME subtype name: MPA (MPEG audio)

    Required parameters: None

    Optional parameters:
         layer: which layer of MPEG audio encoding; permissible values
         are 1, 2, 3.

         samplerate: the rate at which audio is sampled.  MPEG-1 audio
         supports sampling rates of 32, 44.1, and 48 kHz; MPEG-2
         supports sampling rates of 16, 22.05 and 24 kHz.  This parameter
         is separate from the RTP timestamp clock rate which is always
         90000 Hz for MPA."

The answer to the question "Are one allow to break the timestamp rate 
rules due to the fact that one is using a dynamically assigned payload 
type instead of a static?" is in general NO. The rules for the payload 
format applies. There might be cases where the payload format allows 
many rates but the static payload is set a certain one. In that case 
there will be a difference. I have not looked into if there are any such 
format that has been assigned a static payload type.

In regards to the update of the RFC 2250 I can understand that one would 
in consider to allow an updated MIME type using dynamic assignment to 
use other rates then 90000. I think the only consideration is how if 
necessary one switches between the rates.

Best Regards

Magnus




Jae-Hwan Kim wrote:

> Hi! Magnus,
> 
> Thanks a lot for your fast response but I am still in a mist.
> I found a message from AVT mail archive. Please read the below first.
> 
> ------------------------------------------------------------------------
> 
>>Today I saw the following lines in a session's SDP description: 
>>m=audio 0 RTP/AVP 14 a=rtpmap:14 MPA/22050
>>
>>I.e., the session was using the standard MPEG audio payload format (as
> 
> 
>>defined in RFC2250), but with a RTP timestamp frequency of 22050
> 
> instead
> of
> 
>>90000.
>>
>>My question: Is this legal?  Section 4.5.13 of 
>><draft-ietf-avt-profile-new-12.txt> states 4.5.13 MPA
>>...
>>The RTP timestamp clock rate is always 90000,
>>independent of the sampling rate.
>>which suggests that it's not legal to use a RTP timestamp frequency
> 
> other
> 
>>than 90000 for MPA (and MPV, although
> 
> <draft-ietf-avt-profile-new-12.txt>
> 
>>is less explicit in this case).
>>
>>If the above SDP is not legal, would it have been any more legal if it
> 
> had
> said
> 
>>m=audio 0 RTP/AVP 96
>>a=rtpmap:96 MPA/22050
>>i.e., using a dynamic payload type instead of the static payload type
> 
> (14)
> 
>>for MPA?
> 
> 
> Yes, it would have been "more legal" (if there is such a thing :-) if it
> had used a dynamic payload type for this purpose. As decided in the
> London meeting, I am supposed to update RFC 2250 to explicitly state
> that "any clock rate can be specified out-of-band using a dynamic
> payload type with the payload formats defined in RFC 2250." Then, it
> will be "really legal."
> ------------------------------------------------------------------------
> Because I could not find any other threads about this discussion, I
> would like to ask you whether above answer is correct or not. It sounds
> like, "we can override RTP timescale if we use dynamic payload type
> although the payload format allows only a specific timescale". It is
> somewhat reasonable but it seems to be different from many other's
> knowledge on it. Is it right? If I'm wrong, could you interpret it more
> clearly? 
> 
> Best Regards,
> Jae-Hwan
> 
> 
> -----Original Message-----
> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] 
> Sent: Wednesday, October 01, 2003 8:56 PM
> To: Jae-Hwan Kim
> Cc: avt@ietf.org
> Subject: Re: [AVT] RTPtimescale override in dynamic payload type
> 
> 
> Hi,
> 
> See below:
> 
> Jae-Hwan Kim wrote:
> 
> 
>>Dear experts,
>>
>>Is the following discussion true? i.e. Can we override RTP timescale 
>>if we use dynamic payload type?
>>
>>For example, despite of no static payload type, RTP payload document 
>>about H.263 only allows 90000 timescale. In many interoperability 
>>tests, other values except 90000 have not been allowed. But I should 
>>have checked out the exact definition of 'dynamic payload type'. I 
>>would appriciate you for a straight solution on this.
>>
> 
> 
> The clock rate for the RTP timestamp is dependent on the payload format.
> 
>   I agree with your assesment that H.263 does not allow any other clock 
> rate then 90 kHz. In cases the payload format does not allow other rates
> 
> the rate can't be redefined.
> 
> 
>>In addition, can we use dynamic payload type about a media defined as 
>>static. For example, RFC 3551 newly defines QCELP has static payload 
>>type value,12, but dynamic value has been used before. e.g. 96. For 
>>the backward compatibility, can we use the old payload type instead of
> 
> 
>>new payload type? It seems to have been discussed before but I could 
>>not find it exactly.
> 
> 
> There is a section about this in RFC 3551:
>    "This profile reserves payload type numbers in the range 96-127
>     exclusively for dynamic assignment.  Applications SHOULD first use
>     values in this range for dynamic payload types.  Those applications
>     which need to define more than 32 dynamic payload types MAY bind
>     codes below 96, in which case it is RECOMMENDED that unassigned
>     payload type numbers be used first.  However, the statically
> assigned
>     payload types are default bindings and MAY be dynamically bound to
>     new encodings if needed.  Redefining payload types below 96 may
> cause
>     incorrect operation if an attempt is made to join a session without
>     obtaining session description information that defines the dynamic
>     payload types."
> 
> So I don't see a problem of using SDP to define a that QCELP will use a 
> dynamically assigned number in the range 96-127. I don't understand what
> 
> you mean with old payload type. If dynamic payload types where used 
> before the actually used number are only valid for that RTP session.
> 
> 
> Best 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

-- 

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 exim@www1.ietf.org  Wed Oct  1 12:29:27 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22345
	for <avt-archive@odin.ietf.org>; Wed, 1 Oct 2003 12:29:26 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4jqZ-00047P-Lu
	for avt-archive@odin.ietf.org; Wed, 01 Oct 2003 12:29:04 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h91GT3PZ015805
	for avt-archive@odin.ietf.org; Wed, 1 Oct 2003 12:29:03 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4jqX-00046N-37; Wed, 01 Oct 2003 12:29:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4jpr-00044r-Lb
	for avt@optimus.ietf.org; Wed, 01 Oct 2003 12:28:19 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22286
	for <avt@ietf.org>; Wed, 1 Oct 2003 12:28:11 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4jpq-0001oK-00
	for avt@ietf.org; Wed, 01 Oct 2003 12:28:18 -0400
Received: from ims.ku.edu.tr ([193.140.63.3] helo=ku.edu.tr)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4jpp-0001oF-00
	for avt@ietf.org; Wed, 01 Oct 2003 12:28:17 -0400
Received: from FENER.KU.EDU.TR not authenticated [193.140.62.55]
	by ku.edu.tr with Novell NIMS $Revision:   2.88.1.1  $ on Novell NetWare;
	Wed, 01 Oct 2003 19:36:53 +0300
Received: from mail-MTA by FENER.KU.EDU.TR
	with Novell_GroupWise; Wed, 01 Oct 2003 19:27:53 +0200
Message-Id: <sf7b2ab9.095@FENER.KU.EDU.TR>
X-Mailer: Novell GroupWise Internet Agent 6.5.0 
Date: Wed, 01 Oct 2003 18:28:15 +0200
From: "REHA CIVANLAR" <rcivanlar@ku.edu.tr>
To: <avt@ietf.org>
Subject: Re: [AVT] RTPtimescale override in dynamic payload type
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hi Magnus,

>>> Magnus Westerlund <magnus.westerlund@ericsson.com> 01.10.2003
18:53:38 >>>
...
>In regards to the update of the RFC 2250 I can understand that one
would 
>in consider to allow an updated MIME type using dynamic assignment to

>use other rates then 90000. I think the only consideration is how if 
>necessary one switches between the rates.
...

In this case, switching between the rates should not be any different
than switching between payload types. I assumed that the rate specified
at the beginning of a session (through out-of-band means) stays the same
unless the payload type is changed during the session. If needed, this
may be stated explicitly.

Best regards.

M. Reha Civanlar
Computer Engineering Department
Koc University
Istanbul, Turkey




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



From exim@www1.ietf.org  Wed Oct  1 12:46:28 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22929
	for <avt-archive@odin.ietf.org>; Wed, 1 Oct 2003 12:46:28 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4k73-00054T-2z
	for avt-archive@odin.ietf.org; Wed, 01 Oct 2003 12:46:06 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h91Gk5H1019487
	for avt-archive@odin.ietf.org; Wed, 1 Oct 2003 12:46:05 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4k6y-00053k-Nv; Wed, 01 Oct 2003 12:46:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4k6d-00053G-Fi
	for avt@optimus.ietf.org; Wed, 01 Oct 2003 12:45:39 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22857
	for <avt@ietf.org>; Wed, 1 Oct 2003 12:45:31 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4k6b-0001yf-00
	for avt@ietf.org; Wed, 01 Oct 2003 12:45:37 -0400
Received: from david.siemens.de ([192.35.17.14])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4k6a-0001yV-00
	for avt@ietf.org; Wed, 01 Oct 2003 12:45:37 -0400
Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14])
	by david.siemens.de (8.11.7/8.11.7) with ESMTP id h91GjZB07825
	for <avt@ietf.org>; Wed, 1 Oct 2003 18:45:35 +0200 (MEST)
Received: from demchh202e.mchh.siemens.de (mchh2g1e.mchh.siemens.de [139.21.200.101])
	by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id h91GjZ610796
	for <avt@ietf.org>; Wed, 1 Oct 2003 18:45:35 +0200 (MEST)
x-mimeole: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: base64
Date: Wed, 1 Oct 2003 18:44:33 +0200
Message-ID: <7C222247E93DB64FA0078E8A4426435C286A9F@mchh2g1e.mchh.siemens.de>
Thread-Topic: questions/comments on the CLEARMODE draft
Thread-Index: AcN9EKtOyZEUDr+8TJ+sM6/lH7NX/wAA6hCPAoxYEuAAO6dpIA==
From: "Kreuter Ruediger" <Ruediger.Kreuter@siemens.com>
To: =?utf-8?Q?GARCIN_S=C3=A9bastien_FTRD/DAC/ISS?= <sebastien.garcin@rd.francetelecom.com>,
        <avt@ietf.org>
Cc: "Tom Taylor" <taylor@nortelnetworks.com>, <joachim.lueken@siemens.com>
Content-Transfer-Encoding: base64
Subject: [AVT] AW: questions/comments on the CLEARMODE draft
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: base64

SGkgU2ViYXN0aWVuLA0KIA0KcmVzdHJpY3RpbmcgQ2xlYXJtb2RlIHRvICJzb21lIiBhcHBsaWNh
dGlvbnMNCm9yIGV4cGxpY2l0bHkgZXhjbHVkZSAic29tZSIgYXBwbGljYXRpb25zDQpzb3VuZHMg
dmVyeSBjb21wbGljYXRlZCB0byBtZS4NCklmIHdlIHN0YXJ0IHRvIGRvIHRoaXMsIHdoaWNoIGFw
cGxpY2F0aW9ucyBzaG91bGQgYmUgDQpleGNsdWRlZC9pbmNsdWRlZCBhbmQgd2hpY2ggbm90ID8g
SG93IGRvIHdlIGhhbmRsZQ0KZnV0dXJlIHVwY29taW5nIGFwcGxpY2F0aW9ucyBub3QgdGhvdWdo
dCBhYm91dCB0b2RheSA/DQogDQpJdCB3b3VsZCBsaWtlIHRvIGtlZXAgdGhpcyBkcmFmdCAoaS5l
LiB0aGlzIHBzZXVkbyBjb2RlYykNCmFzIHNpbXBsZSBhcyBwb3NzaWJsZS4gVGhpcyB3aWxsIGFs
bG93IHNpbXBsZSBpbXBsZW1lbnRhdGlvbiwNCmFuZCBpcywgQlRXLCBpbiBsaW5lIHdpdGggZXhp
c3RpbmcgaW1wbGVtZW50YXRpb25zIGluIHRoZSBmaWVsZC4NCiANClNlZSBhbHNvIHNvbWUgY29t
bWVudHMgYmVsb3cuDQogDQpCZXN0IHJlZ2FyZHMsDQpSdWVkaWdlcg0KDQoJLS0tLS1VcnNwcsO8
bmdsaWNoZSBOYWNocmljaHQtLS0tLSANCglWb246IEdBUkNJTiBTw6liYXN0aWVuIEZUUkQvREFD
L0lTUyBbbWFpbHRvOnNlYmFzdGllbi5nYXJjaW5AcmQuZnJhbmNldGVsZWNvbS5jb21dIA0KCUdl
c2VuZGV0OiBEaSAzMC4wOS4yMDAzIDEzOjUwIA0KCUFuOiBLcmV1dGVyIFJ1ZWRpZ2VyIA0KCUNj
OiBUb20gVGF5bG9yIA0KCUJldHJlZmY6IFJFOiBxdWVzdGlvbnMvY29tbWVudHMgb24gdGhlIENM
RUFSTU9ERSBkcmFmdA0KCQ0KCQ0KDQoNCglIaSBydWVkaWdlciwNCgkNCglBcyB5b3UgbWF5IGhh
dmUgc2VlbiBpbiB5b3VyIG1haWxib3gsIEkgaGF2ZSBxdWVzdGlvbmVkIHRoZSBhdXRob3JzIG9m
IHRoZSBuZXctU0RQIGRyYWZ0IGFib3V0IHRoZSAiZGF0YSIgYW5kICJhdWRpbyIgaXNzdWUuDQoJ
DQoJVGhlIG91dGNvbWUgb2YgdGhpcyBkaXNjdXNzaW9uIHdhcyB0aGF0ICJkYXRhIiBzaG91bGQg
cmF0aGVyIGJlIHVzZWQgaW4gbm9uLVJUUCBzY2VuYXJpbyBhbmQgZml0cyBpbiBmaW5lIHdpdGgg
cHVyZSBkYXRhIGNvbm5leGlvbnMgYnV0IG5vdCBmb3IgSVNETiA3a2h6IHZvaWNlIGFwcGxpY2F0
aW9ucy4NCgkNCglPbiB0aGUgY29udHJhcnksIHRoZSB1c2Ugb2YgbT1hdWRpby4uLiBtYXkgbm90
IGJlIGFwcHJvcHJpYXRlIGZvciBwdXJlIGRhdGEgY29ubmV4aW9ucyBzaW5jZSBSVFAgdHJhbnNw
b3J0IGlzIG5vdCBuZWVkZWQuDQoNCgkNCg0KCT4gImlzIG5vdCBuZWVkZWQiID8/PyBXZWxsLCBo
b3cgZG8geW91IHJlcGxhY2UgdGhlIHNlY3VyaXR5IGZlYXR1cmVzLCB3aGljaCBjb21lIGluaGVy
ZW50bHkgd2l0aCBSVFAgPyBJbiBhIFRETSByZXBsYWNlbWVudCBzY2VuYXJpbyBJIHJlYWxseSB3
b3VsZG4ndCBsaWtlIHRvIG1pc3MgdGhlbS4NCg0KCT4gMm5kIGNvbW1lbnQ6IFNvbWUgcGVvcGxl
IHRoaW5rIGFib3V0IHVzYWdlIG9mIENsZWFybW9kZSBmb3IgbG93IGJpdHJhdGUgdmlkZW8gZGF0
YS4gU28sIGlmIHdlIGZvbGxvdyB5b3VyIGFyZ3VtZW50YXRpb24sIHdlIHdvdWxkIG5lZWQgYSBD
bGVhcm1vZGUgZm9yICJhdWRpbyIsIG9uZSBmb3IgImRhdGEiLCBvbmUgZm9yICJ2aWRlbyIsIG9u
ZSBmb3IgLi4uICAgIFlvdSB3aWxsIG5vdCBmaW5kICJvbmUiIE1JTUUgdHlwZSB0aGF0IGZpdHMg
Zm9yIGFsbCBzY2VuYXJpb3MuDQoNCgkNCgkNCglJdCB3b3VsZCBiZSBwb3NzaWJsZSB0byB1c2Ug
YSBzcGVjaWZpYyBtYXBwaW5nIGRlcGVuZGluZyBvbiB0aGUgSVNETiBCZWFyZXIgQ2FwYWJpbGl0
eSBpbmZvcm1hdGlvbiBlbGVtZW50IHJlY2VpdmVkIGF0IHRoZSBWb0lQIE1HQy4NCgkNCgllLmcN
CgkNCglCQyAwMTAwMCAidW5yZXN0cmljdGVkIGRpZ2l0YWwgaW5mbyIgLS0tPiBtPWRhdGEgVURQ
Li4uDQoNCgk+IElmIFNHMTEgd2FudHMgdG8gc3RheSB3aXRoICJkYXRhIiBmb3IgdXNlIG92ZXIg
VURQLCBJIHdvdWxkIHN1Z2dlc3QgYSBzZXBlcmF0ZSBJQU5BIHJlZ2lzdHJhdGlvbiBmb3IgdGhp
cyBNSU1FIFR5cGUgLyBNSU1FIFN1YnR5cGUgY29tYmluYXRpb24uIFdpdGggYSBTRzExIFN0YW5k
YXJkIHlvdSB3b3VsZG4ndCBldmVuIG5lZWQgYW4gUkZDLCBiZWNhdXNlIHlvdSBhbHJlYWR5IGhh
dmUgYSBzdGFuZGFyZCB0byBwb2ludCB0by4NCg0KCT4gWW91IHNob3VsZCBhbHNvIHNjcmVlbiB0
aGUgYXJndW1lbnRhdGlvbiBmb3IgdGhlID5pbnRyb2R1Y3Rpb248IG9mICJhdWRpby9ULjM4Ii4g
VGhpcyB3aWxsIG1ha2UgY2FsbCBzZXR1cCBjb2RlYyBuZWdvdGlhdGlvbiBpbiBhIFZvSVAgZW52
aXJvbm1lbnQgbXVjaCBzaW1wbGVyLiBJIGRvbid0IHNlZSB3aHkgd2Ugc2hvdWxkIGZvbGxvdyBh
IGNvbnRyYXJ5IGFwcHJvYWNoIHdpdGggQ2xlYXJtb2RlLg0KDQoJDQoJDQoJQkMgMTAwMDEgInVu
cmVzdHJpY3RlZCBkaWdpdGFsIGluZm8gd2l0aCB0b25lcy9hbmQgYW5ub3VuY2VtZW50cyAtLS0+
bT1hdWRpbyAxMjM0NSBSVFAvQVZQIDk3DQoJICAgICAgICAgICAgICAgICAgICAgICAgICAgYT1y
dHBtYXA6OTcgQ0xFQVJNT0RFLzgwMDANCgkgICAgICAgICAgICAgICAgICAgICAgICAgICBhPXB0
aW1lOjEwDQoNCgkNCg0KCT4gVGhlcmUgaXMgbm8gdG9uZSBkZXRlY3Rpb24gd2l0aCAiQ2xlYXJt
b2RlIiBpbiB0aGUgY3VycmVudGx5IGV4aXN0aW5nIERTUCBjb2RlLCBvZiBWb0lQIGdhdGV3YXlz
LiBJZiB0b25lIGRldGVjdGlvbiBpcyBuZWVkZWQsIHRoZW4gRy43MjIgbXVzdCBiZSB1c2VkIGZv
ciBJU0ROIDdrSHogdm9pY2UuDQoNCgkNCgkNCglBbm90aGVyIHBvc3NpYmlsaXR5IHdvdWxkIGJl
IHRvIHJlc3RyaWN0IHRoZSB1c2Ugb2YgY2xlYXJtb2RlIHRvICJJU0ROIDcga2h6IGF1ZGlvIg0K
DQoJPiBBcyBkZXNjcmliZWQgYWJvdmUsIHRoaXMgZG9lc24ndCBtYWtlIHNlbnNlLg0KDQoJDQoJ
DQoJQW55IHRob3VnaHRzIGFib3V0IHRoaXM/DQoJDQoJDQoJDQoJUmVnYXJkcywNCglTw6liYXN0
aWVuDQoJDQoJR2FyY2luIFPDqWJhc3RpZW4NCglGcmFuY2UgVMOpbMOpY29tIFImRA0KCSszMyAo
MCkxIDQ1IDI5IDY0IDk2DQoJDQoJDQoNCg==

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



From exim@www1.ietf.org  Wed Oct  1 16:55:36 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04253
	for <avt-archive@odin.ietf.org>; Wed, 1 Oct 2003 16:55:36 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4o07-0002iH-DG
	for avt-archive@odin.ietf.org; Wed, 01 Oct 2003 16:55:13 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h91KtBNW010386
	for avt-archive@odin.ietf.org; Wed, 1 Oct 2003 16:55:11 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4nzy-0002gx-Ox; Wed, 01 Oct 2003 16:55:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4nzW-0002gR-Dq
	for avt@optimus.ietf.org; Wed, 01 Oct 2003 16:54:37 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04203
	for <avt@ietf.org>; Wed, 1 Oct 2003 16:54:26 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4nzU-0005GA-00
	for avt@ietf.org; Wed, 01 Oct 2003 16:54:32 -0400
Received: from dundee.dcs.gla.ac.uk ([130.209.242.163])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4nzT-0005Fx-00
	for avt@ietf.org; Wed, 01 Oct 2003 16:54:31 -0400
Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:61060 helo=csperkins.org)
	by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.04)
	id 1A4nyw-0000QM-00; Wed, 01 Oct 2003 21:53:58 +0100
Date: Wed, 1 Oct 2003 21:53:54 +0100
Subject: Re: [AVT] AW: questions/comments on the CLEARMODE draft
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: =?ISO-8859-1?Q?GARCIN_S=E9bastien_FTRD/DAC/ISS?= <sebastien.garcin@rd.francetelecom.com>,
        <avt@ietf.org>, "Tom Taylor" <taylor@nortelnetworks.com>,
        <joachim.lueken@siemens.com>
To: "Kreuter Ruediger" <Ruediger.Kreuter@siemens.com>
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <7C222247E93DB64FA0078E8A4426435C286A9F@mchh2g1e.mchh.siemens.de>
Message-Id: <5EB720B8-F451-11D7-8CEB-000A957FC5F2@csperkins.org>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
Content-Transfer-Encoding: 7bit
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

On Wednesday, Oct 1, 2003, at 17:44 Europe/London, Kreuter Ruediger 
wrote:
> restricting Clearmode to "some" applications
> or explicitly exclude "some" applications
> sounds very complicated to me.
> If we start to do this, which applications should be
> excluded/included and which not ? How do we handle
> future upcoming applications not thought about today ?
>
> It would like to keep this draft (i.e. this pseudo codec)
> as simple as possible. This will allow simple implementation,
> and is, BTW, in line with existing implementations in the field.

I would agree with this. The clearmode draft solves a clearly specified 
and well delineated problem, and I would not like to see its scope 
creep without very good reason. Emulation of other data circuits is 
best left to other payload formats or protocols (e.g. those under 
discussion in the PWE3 working group, or perhaps in the ITU).

-- 
Colin Perkins
http://csperkins.org/


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



From exim@www1.ietf.org  Thu Oct  2 10:48:36 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22743
	for <avt-archive@odin.ietf.org>; Thu, 2 Oct 2003 10:48:36 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A54ka-0003Dm-5b
	for avt-archive@odin.ietf.org; Thu, 02 Oct 2003 10:48:16 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h92EmGer012378
	for avt-archive@odin.ietf.org; Thu, 2 Oct 2003 10:48:16 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A54kL-0003AO-3w; Thu, 02 Oct 2003 10:48:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A54jR-00038j-Vt
	for avt@optimus.ietf.org; Thu, 02 Oct 2003 10:47:06 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22643
	for <avt@ietf.org>; Thu, 2 Oct 2003 10:46:55 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A54jP-0001RB-00
	for avt@ietf.org; Thu, 02 Oct 2003 10:47:03 -0400
Received: from thoth.sbs.de ([192.35.17.2])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A54jO-0001R8-00
	for avt@ietf.org; Thu, 02 Oct 2003 10:47:02 -0400
Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11])
	by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id h92El1j04529
	for <avt@ietf.org>; Thu, 2 Oct 2003 16:47:01 +0200 (MEST)
Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85])
	by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id h92El0i01383
	for <avt@ietf.org>; Thu, 2 Oct 2003 16:47:00 +0200 (MEST)
Received: from mchh246e.mchh.siemens.de (mchh246e.mchh.siemens.de [139.21.200.56])
	by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id QAA10125
	for <avt@ietf.org>; Thu, 2 Oct 2003 16:47:00 +0200 (MET DST)
Received: by mchh246e.mchh.siemens.de with Internet Mail Service (5.5.2656.59)
	id <SWM8NRTB>; Thu, 2 Oct 2003 16:46:12 +0200
Message-ID: <EF8E39AA846CD411BB9C00508B951F5106D774BF@mchh267e.mchh.siemens.de>
From: Belling Thomas <thomas.belling@siemens.com>
To: "'avt@ietf.org'" <avt@ietf.org>
Subject: [AVT] Usage of RFC 3556 to turn of RTCP?
Date: Thu, 2 Oct 2003 16:45:53 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable

Dear all,


Is it possible to turn off RTCP with the help of RFC 3556?

(I am aware that RFC 3550 recommends the usage of RTCP. However, =
turning off RTCP may possibly be beneficial for a conversational =
point-to-point voice communication over limited bandwidth with low =
delay requirements. Here, large RTCP packages may delay the =
transmission of RTP packages too much and result in audible =
distortions.)


RFC 3556 seems to be designed with other applications in mind
(e.g., streaming services - one sender, many only-listeners).
Only the suppression of receiver reports is mentioned as an =
application:
"  Using two parameters allows RTCP reception reports to be turned
   off entirely for a particular session by setting the RTCP bandwidth
   for non-data-senders to zero while keeping the RTCP bandwidth for
   data senders non-zero so that sender reports can still be sent for
   inter-media synchronization.  Turning off RTCP reception reports is
   not recommended because they are needed for the functions listed in
   the RTP specification, particularly reception quality feedback and
   congestion control.  However, doing so may be appropriate for =
systems
   operating on unidirectional links or for sessions that do not =
require
   feedback on the quality of reception or liveness of receivers and
   that have other means to avoid congestion."
The possibility of turning off RTCP bandwidth for data-senders is not=20
explicitly considered.

Nevertheless, I do not find anything in RFC 3556 that forbids setting =
both bandwidth modifiers to zero:
"
b:RR:0
b:RS:0
"

The only explicit explanation about this parameter combination in RFC =
3556 I find is
"If RS and RR are both zero, it would be unwise to attempt calculation =
of the fraction RS/(RS+RR)."

However, RFC 3556 also states:
"  The bandwidth allocation specified by the RS and RR modifiers =
applies
   to the total bandwidth consumed by all RTCP packet types, including
   SR, RR, SDES, BYE, APP and any new types defined in the future."

I derive that no bandwidth is granted for RTCP, if RS and RR are both =
zero.

Do you agree that the setting of both RS and RR to zero is allowed?

Do you agree that the implied semantics are: "RTCP is not used"   ??


Thanks for your help, Thomas Belling



----------------------------------
Dr. Thomas Belling
Siemens AG          =20
Sankt-Martinsstr. 76=20
D-81542 M=FCnchen Germany
ICM N PG SP ST N1
MCH M 34 307
Tel     +49 89 636 75207
Fax     +49 89 636 75577
Mobile  +49 172 2974678
Email   Thomas.Belling@siemens.com




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



From exim@www1.ietf.org  Thu Oct  2 10:50:26 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23121
	for <avt-archive@odin.ietf.org>; Thu, 2 Oct 2003 10:50:26 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A54mM-0003YM-J8
	for avt-archive@odin.ietf.org; Thu, 02 Oct 2003 10:50:06 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h92Eo6bl013571
	for avt-archive@odin.ietf.org; Thu, 2 Oct 2003 10:50:06 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A54mJ-0003VS-Cm; Thu, 02 Oct 2003 10:50:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A54m8-0003U5-2r
	for avt@optimus.ietf.org; Thu, 02 Oct 2003 10:49:52 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22882;
	Thu, 2 Oct 2003 10:49:41 -0400 (EDT)
Message-Id: <200310021449.KAA22882@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: avt@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Thu, 02 Oct 2003 10:49:40 -0400
Subject: [AVT] I-D ACTION:draft-ietf-avt-uxp-06.txt
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Audio/Video Transport Working Group of the IETF.

	Title		: An RTP Payload Format for Erasure-Resilient 
                          Transmission of Progressive Multimedia Streams
	Author(s)	: G. Liebl et al.
	Filename	: draft-ietf-avt-uxp-06.txt
	Pages		: 25
	Date		: 2003-10-2
	
This document specifies an efficient way to ensure erasure-
resilient transmission of progressively encoded multimedia 
sources via RTP using Reed-Solomon (RS) codes together with 
interleaving. The level of erasure protection can be explicitly 
adapted to the importance of the respective parts in the source 
stream, thus allowing a graceful degradation of application 
quality with increasing packet loss rate on the network. Hence, 
this type of unequal erasure protection (UXP) schemes is intended 
to cope with the rapidly varying channel conditions on wireless 
access links to the Internet backbone. Furthermore, protection of 
non-progressive multimedia streams is ensured, since equal 
erasure protection (EXP) represents a subset of generic UXP. By 
applying interleaving and RS codes a  payload format is defined, 
which can be easily integrated into the existing framework for 
RTP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-uxp-06.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-avt-uxp-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-avt-uxp-06.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-10-2105701.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-avt-uxp-06.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-avt-uxp-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-10-2105701.I-D@ietf.org>

--OtherAccess--

--NextPart--



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



From exim@www1.ietf.org  Thu Oct  2 10:59:25 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23789
	for <avt-archive@odin.ietf.org>; Thu, 2 Oct 2003 10:59:24 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A54v3-0004VV-6V
	for avt-archive@odin.ietf.org; Thu, 02 Oct 2003 10:59:05 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h92Ex5Gh017292
	for avt-archive@odin.ietf.org; Thu, 2 Oct 2003 10:59:05 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A54v0-0004UC-8j; Thu, 02 Oct 2003 10:59:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A54uk-0004Tq-6Z
	for avt@optimus.ietf.org; Thu, 02 Oct 2003 10:58:46 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23772
	for <avt@ietf.org>; Thu, 2 Oct 2003 10:58:35 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A54uh-0001co-00
	for avt@ietf.org; Thu, 02 Oct 2003 10:58:43 -0400
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A54uf-0001cT-00
	for avt@ietf.org; Thu, 02 Oct 2003 10:58:41 -0400
Received: from cisco.com (171.71.177.238)
  by sj-iport-3.cisco.com with ESMTP; 02 Oct 2003 08:03:47 -0700
Received: from [10.32.254.182] (stealth-10-32-254-182.cisco.com [10.32.254.182])
	by sj-core-5.cisco.com (8.12.9/8.12.6) with SMTP id h92Ew8Xg012937;
	Thu, 2 Oct 2003 07:58:09 -0700 (PDT)
Date: Thu, 02 Oct 2003 10:58:03 -0400
From: "David R. Oran" <oran@cisco.com>
To: Belling Thomas <thomas.belling@siemens.com>,
        "'avt@ietf.org'" <avt@ietf.org>
Subject: Re: [AVT] Usage of RFC 3556 to turn of RTCP?
Message-ID: <269322140.1065092283@[10.32.254.182]>
In-Reply-To: <EF8E39AA846CD411BB9C00508B951F5106D774BF@mchh267e.mchh.siemens.de>
References:  <EF8E39AA846CD411BB9C00508B951F5106D774BF@mchh267e.mchh.siemens.
 de>
X-Mailer: Mulberry/3.1.0b8 (Win32)
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="==========0C8F05A4799F4DC18991=========="
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>

--==========0C8F05A4799F4DC18991==========
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

My 2 centi-Euros below:
Dave.

--On Thursday, October 02, 2003 4:45 PM +0200 Belling Thomas=20
<thomas.belling@siemens.com> wrote:

> Dear all,
>
>
> Is it possible to turn off RTCP with the help of RFC 3556?
>
> (I am aware that RFC 3550 recommends the usage of RTCP. However, turning
> off RTCP may possibly be beneficial for a conversational point-to-point
> voice communication over limited bandwidth with low delay requirements.
> Here, large RTCP packages may delay the transmission of RTP packages too
> much and result in audible distortions.)
>
Huh? You're kidding right? Send RTP with DSCP=3DEF and RTCP with DSCP=3DBE.
If an occasional RTCP BE packet can introduce enough delay to matter, I=20
sure hope you don't allow even a single TLS startup exchange to go over the =

link while you're talking!

>
> RFC 3556 seems to be designed with other applications in mind
> (e.g., streaming services - one sender, many only-listeners).
> Only the suppression of receiver reports is mentioned as an application:
> "  Using two parameters allows RTCP reception reports to be turned
>    off entirely for a particular session by setting the RTCP bandwidth
>    for non-data-senders to zero while keeping the RTCP bandwidth for
>    data senders non-zero so that sender reports can still be sent for
>    inter-media synchronization.  Turning off RTCP reception reports is
>    not recommended because they are needed for the functions listed in
>    the RTP specification, particularly reception quality feedback and
>    congestion control.  However, doing so may be appropriate for systems
>    operating on unidirectional links or for sessions that do not require
>    feedback on the quality of reception or liveness of receivers and
>    that have other means to avoid congestion."
> The possibility of turning off RTCP bandwidth for data-senders is not
> explicitly considered.
>
> Nevertheless, I do not find anything in RFC 3556 that forbids setting
> both bandwidth modifiers to zero: "
> b:RR:0
> b:RS:0
> "
>
I believe that is correct. Caveat emptor.

> The only explicit explanation about this parameter combination in RFC
> 3556 I find is "If RS and RR are both zero, it would be unwise to attempt
> calculation of the fraction RS/(RS+RR)."
>
> However, RFC 3556 also states:
> "  The bandwidth allocation specified by the RS and RR modifiers applies
>    to the total bandwidth consumed by all RTCP packet types, including
>    SR, RR, SDES, BYE, APP and any new types defined in the future."
>
> I derive that no bandwidth is granted for RTCP, if RS and RR are both
> zero.
>
> Do you agree that the setting of both RS and RR to zero is allowed?
>
> Do you agree that the implied semantics are: "RTCP is not used"   ??
>
Note that these SDP parameters will be carried in an SDP offer-answer=20
exchange, so I believe that *both* ends need to agree that this is OK. This =

means that while on a given call you can negotiate RTCP transmission=20
essentially off, you can't use this as a sleazeball way to avoid=20
implementing it and using it when one side or the other wants to.

Note also that setting this bandwidth to zero has the potential to break=20
SRTP, which relies on RTCP for crypto resynchronization under cwertain=20
failure conditions.

All in all, I would encourage you to reconsider the assumptions which lead=20
you to think turning off RTCP is a good idea.


>
> Thanks for your help, Thomas Belling
>
>
>
> ----------------------------------
> Dr. Thomas Belling
> Siemens AG
> Sankt-Martinsstr. 76
> D-81542 M=FCnchen Germany
> ICM N PG SP ST N1
> MCH M 34 307
> Tel     +49 89 636 75207
> Fax     +49 89 636 75577
> Mobile  +49 172 2974678
> Email   Thomas.Belling@siemens.com
>
>
>
>
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www1.ietf.org/mailman/listinfo/avt



------------------------
David R. Oran
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720
Office: +1 978 264 2048
VoIP: +1 408 571 4576
Email: oran@cisco.com
--==========0C8F05A4799F4DC18991==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: Mulberry PGP Plugin v3.0
Comment: processed by Mulberry PGP Plugin

iQA/AwUBP3w8/I1mhLZU3SrmEQIzgwCg29CH1vBLlr0FuaZzJi2Bcs0Z4GMAoIbQ
1Jln9ErL/f4PCn3i/MlmZJR3
=r5IK
-----END PGP SIGNATURE-----

--==========0C8F05A4799F4DC18991==========--


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



From exim@www1.ietf.org  Thu Oct  2 11:30:29 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26740
	for <avt-archive@odin.ietf.org>; Thu, 2 Oct 2003 11:30:29 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A55P6-0006a9-HX
	for avt-archive@odin.ietf.org; Thu, 02 Oct 2003 11:30:08 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h92FU8l2025295
	for avt-archive@odin.ietf.org; Thu, 2 Oct 2003 11:30:08 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A55P0-0006Zf-Uz; Thu, 02 Oct 2003 11:30:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A55OL-0006Y2-N0
	for avt@optimus.ietf.org; Thu, 02 Oct 2003 11:29:21 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26668
	for <avt@ietf.org>; Thu, 2 Oct 2003 11:29:12 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A55OK-0002M0-00
	for avt@ietf.org; Thu, 02 Oct 2003 11:29:20 -0400
Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A55OJ-0002Ls-00
	for avt@ietf.org; Thu, 02 Oct 2003 11:29:19 -0400
Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121])
	by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h92FTFlN000866;
	Thu, 2 Oct 2003 17:29:15 +0200 (MEST)
Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55)
	id T6YN3LWR; Thu, 2 Oct 2003 17:30:12 +0200
Message-ID: <3F7C444B.8080909@ericsson.com>
Date: Thu, 02 Oct 2003 17:29:15 +0200
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Belling Thomas <thomas.belling@siemens.com>
CC: "'avt@ietf.org'" <avt@ietf.org>
Subject: Re: [AVT] Usage of RFC 3556 to turn of RTCP?
References: <EF8E39AA846CD411BB9C00508B951F5106D774BF@mchh267e.mchh.siemens.de>
In-Reply-To: <EF8E39AA846CD411BB9C00508B951F5106D774BF@mchh267e.mchh.siemens.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable

Hi Thomas,

Yes, setting both RTCP bandwidths to 0 will turn of RTCP.

However this is strongly recommened not to do for a number of reasons:

- Loss of receiver feedback giving congestion control information.
- Loss of synchronization information between multiple media streams,=20
either different SSRC or between RTP sessions live audio and video.
- Loss of liveness information of the other end-point.
- Loss of information to bind different SSRC in different sessions to=20
come from the same entity.
- Loss of possibility to use RTCP based extensions.
- Loss of possibility to use RTP payload formats requiring use of RTCP,=20
for example the MIDI and its recover journal.

For more text on this see, section 6 of RFC 3550.


AVT Chair hat off:

I assume this is in relation to the proposal for conversational IMS=20
based service's optimized radio bearer in 3GPP. I strongly recommend=20
against removing RTCP of the following reasons that I think apply in=20
this use case.

1. Loss of synchronization if combined with another media, like audio=20
and video.
2. Loss of liveness information from the other party.
3. If the conversational IMS system becomes used over networks which are =

best effort and not using reserved resources the RTCP will be needed for =

congestion control.

That is my view on this issue.

Best Regards

Magnus


Belling Thomas wrote:

> Dear all,
>=20
>=20
> Is it possible to turn off RTCP with the help of RFC 3556?
>=20
> (I am aware that RFC 3550 recommends the usage of RTCP. However, turnin=
g off RTCP may possibly be beneficial for a conversational point-to-point=
 voice communication over limited bandwidth with low delay requirements. =
Here, large RTCP packages may delay the transmission of RTP packages too =
much and result in audible distortions.)
>=20
>=20
> RFC 3556 seems to be designed with other applications in mind
> (e.g., streaming services - one sender, many only-listeners).
> Only the suppression of receiver reports is mentioned as an application=
:
> "  Using two parameters allows RTCP reception reports to be turned
>    off entirely for a particular session by setting the RTCP bandwidth
>    for non-data-senders to zero while keeping the RTCP bandwidth for
>    data senders non-zero so that sender reports can still be sent for
>    inter-media synchronization.  Turning off RTCP reception reports is
>    not recommended because they are needed for the functions listed in
>    the RTP specification, particularly reception quality feedback and
>    congestion control.  However, doing so may be appropriate for system=
s
>    operating on unidirectional links or for sessions that do not requir=
e
>    feedback on the quality of reception or liveness of receivers and
>    that have other means to avoid congestion."
> The possibility of turning off RTCP bandwidth for data-senders is not=20
> explicitly considered.
>=20
> Nevertheless, I do not find anything in RFC 3556 that forbids setting b=
oth bandwidth modifiers to zero:
> "
> b:RR:0
> b:RS:0
> "
>=20
> The only explicit explanation about this parameter combination in RFC 3=
556 I find is
> "If RS and RR are both zero, it would be unwise to attempt calculation =
of the fraction RS/(RS+RR)."
>=20
> However, RFC 3556 also states:
> "  The bandwidth allocation specified by the RS and RR modifiers applie=
s
>    to the total bandwidth consumed by all RTCP packet types, including
>    SR, RR, SDES, BYE, APP and any new types defined in the future."
>=20
> I derive that no bandwidth is granted for RTCP, if RS and RR are both z=
ero.
>=20
> Do you agree that the setting of both RS and RR to zero is allowed?
>=20
> Do you agree that the implied semantics are: "RTCP is not used"   ??
>=20
>=20
> Thanks for your help, Thomas Belling
>=20
>=20
>=20
> ----------------------------------
> Dr. Thomas Belling
> Siemens AG          =20
> Sankt-Martinsstr. 76=20
> D-81542 M=FCnchen Germany
> ICM N PG SP ST N1
> MCH M 34 307
> Tel     +49 89 636 75207
> Fax     +49 89 636 75577
> Mobile  +49 172 2974678
> Email   Thomas.Belling@siemens.com
>=20
>=20
>=20
>=20
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www1.ietf.org/mailman/listinfo/avt
>=20

--=20

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 exim@www1.ietf.org  Fri Oct  3 21:50:29 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07318
	for <avt-archive@odin.ietf.org>; Fri, 3 Oct 2003 21:50:29 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A5bYe-0007MI-Cj
	for avt-archive@odin.ietf.org; Fri, 03 Oct 2003 21:50:08 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h941o8IT028262
	for avt-archive@odin.ietf.org; Fri, 3 Oct 2003 21:50:08 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A5bYY-0007LA-HK; Fri, 03 Oct 2003 21:50:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A5bXo-0007KR-9N
	for avt@optimus.ietf.org; Fri, 03 Oct 2003 21:49:16 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07257
	for <avt@ietf.org>; Fri, 3 Oct 2003 21:49:06 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A5bXl-0001pk-00
	for avt@ietf.org; Fri, 03 Oct 2003 21:49:13 -0400
Received: from mail19b.dulles19-verio.com ([198.170.241.3])
	by ietf-mx with smtp (Exim 4.12)
	id 1A5bXk-0001pe-00
	for avt@ietf.org; Fri, 03 Oct 2003 21:49:12 -0400
Received: from www.i2telecom.com (161.58.97.193)
	by mail19b.dulles19-verio.com (RS ver 1.0.87vs) with SMTP id 3-078736563
	for <avt@ietf.org>; Fri,  3 Oct 2003 18:36:03 -0400 (EDT)
Message-ID: <06e101c389ff$199d9790$6f01a8c0@albab>
From: "Awais Ali" <aali@i2telecom.com>
To: <avt@ietf.org>
Date: Fri, 3 Oct 2003 15:38:42 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_06DE_01C389C4.6CD37AA0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Loop-Detect: 1
Subject: [AVT] sending Flash event using rfc2833
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_06DE_01C389C4.6CD37AA0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

When the flash event is detected it has already ended. Does this mean =
that when sending Flash the first packet sent will have the "end" bit =
set.?

Ali Awais
------=_NextPart_000_06DE_01C389C4.6CD37AA0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>When the flash event is detected it has =
already=20
ended. Does this mean that when sending Flash the first packet sent will =
have=20
the "end" bit set.?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Ali Awais</FONT></DIV></BODY></HTML>

------=_NextPart_000_06DE_01C389C4.6CD37AA0--


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



From exim@www1.ietf.org  Mon Oct  6 17:02:32 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22405
	for <avt-archive@odin.ietf.org>; Mon, 6 Oct 2003 17:02:32 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A6cUe-0000zY-4f
	for avt-archive@odin.ietf.org; Mon, 06 Oct 2003 17:02:12 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h96L2CKS003808
	for avt-archive@odin.ietf.org; Mon, 6 Oct 2003 17:02:12 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A6cUT-0000x2-Gz; Mon, 06 Oct 2003 17:02:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A6cTi-0000vB-Cv
	for avt@optimus.ietf.org; Mon, 06 Oct 2003 17:01:14 -0400
Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22234
	for <avt@odin.ietf.org>; Mon, 6 Oct 2003 17:01:04 -0400 (EDT)
Received: from apache by asgard.ietf.org with local (Exim 4.14)
	id 1A6cRn-00066h-J2; Mon, 06 Oct 2003 16:59:15 -0400
X-test-idtracker: no
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce:;
Cc: Internet Architecture Board <iab@iab.org>,
        RFC Editor <rfc-editor@rfc-editor.org>, <avt@ietf.org>
Message-Id: <E1A6cRn-00066h-J2@asgard.ietf.org>
Date: Mon, 06 Oct 2003 16:59:15 -0400
Subject: [AVT] Protocol Action: 'RTP Payload Format for Transport of
 MPEG-4 Elementary Streams' to Proposed Standard
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>

The IESG has approved following document:

- 'RTP Payload Format for Transport of MPEG-4 Elementary Streams '
   <draft-ietf-avt-mpeg4-simple-08.txt> as a Proposed Standard

This document is the product of the Audio/Video Transport Working Group. 

The IESG contact persons are Allison Mankin and Jon Peterson.

Technical Summary

The MPEG-4 standard specifies compression of audio-visual data into
for example an audio or video elementary stream. In the MPEG-4
standard, these streams take the form of audio-visual objects that may
be arranged into an audio-visual scene by means of a scene
description. Each MPEG-4 elementary stream consists of a sequence of
Access Units; examples of an Access Unit (AU) are an audio frame and a
video picture.

This specification defines a general and configurable payload
structure to transport non-multiplexed MPEG-4 elementary streams, in
particular MPEG-4 audio (including speech) streams, MPEG-4 video
streams and also MPEG-4 systems streams, such as BIFS (BInary Format
for Scenes), OCI (Object Content Information), OD (Object Descriptor)
and IPMP (Intellectual Property Management and Protection) streams.
The RTP payload defined in this document is simple to implement and
reasonably efficient. It allows for optional interleaving of Access
Units (such as audio frames) to increase error resiliency in packet
loss.

This payload format is largely compatible with the video part
of RFC 3016, the RTP Payload Format for MPEG-4 Audio/Visual Streams, and
extends that format to effectively support other classes of media and also
MPEG-4 Systems streams.

The specification registers the MIME sub-types audio/mpeg4-generic,
video/mpeg4-generic and application/mpeg4-generic.

MPEG-4 Systems supports stream types including commands that are
executed on the terminal like OD commands, BIFS commands, etc. and
programmatic content like MPEG-J (Java(TM) Byte Code) and
CMAScript. The Security Considerations discuss risks associated with
these capabilities and ways to mitigate these risks.

Working Group Summary

This was a strenuous effort by the AVT Working group.
This payload format has been under development since the 39th IETF meeting
in Munich, August 1997. It is the result of collaboration between AVT, the
MPEG committee and the Internet Streaming Media Alliance. When the
consensus designs were achieved, there was a thorough Last Call review and
strong support for advancement.

Protocol Quality

The specification was reviewed for the IESG by Allison Mankin.


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



From exim@www1.ietf.org  Tue Oct  7 07:28:42 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27230
	for <avt-archive@odin.ietf.org>; Tue, 7 Oct 2003 07:28:42 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A6q0p-0003Tr-22
	for avt-archive@odin.ietf.org; Tue, 07 Oct 2003 07:28:19 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h97BSJTK013377
	for avt-archive@odin.ietf.org; Tue, 7 Oct 2003 07:28:19 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A6q0X-0003T3-E5; Tue, 07 Oct 2003 07:28:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A6q03-0003SX-OP
	for avt@optimus.ietf.org; Tue, 07 Oct 2003 07:27:31 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27207
	for <avt@ietf.org>; Tue, 7 Oct 2003 07:27:23 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A6q03-0004Be-00
	for avt@ietf.org; Tue, 07 Oct 2003 07:27:31 -0400
Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A6q02-0004Bb-00
	for avt@ietf.org; Tue, 07 Oct 2003 07:27:30 -0400
Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125])
	by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h97BRRN1022173;
	Tue, 7 Oct 2003 13:27:27 +0200 (MEST)
Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55)
	id T6YTWVGT; Tue, 7 Oct 2003 13:30:27 +0200
Message-ID: <3F82A31C.6010903@ericsson.com>
Date: Tue, 07 Oct 2003 13:27:24 +0200
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: IETF AVT WG <avt@ietf.org>
CC: Colin Perkins <csp@csperkins.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [AVT] IETF 58 Deadlines - draft submission and AVT agenda - Reminder
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hi,

Please remember the following deadlines for draft submission and AVT WG 
meeting agenda requests.

-------------------------------------------------
The Draft submission deadlines are the following:

October 20th: Cutoff for Initial Submissions (new documents)

All initial submissions(-00) must be submitted by Monday, October 20th,
at 09:00 ET.  Initial submissions received after this time will NOT be
made available in the Internet-Drafts directory, and will have to be
resubmitted.

Please note that if your initial submission is intended for the AVT WG
we recommend a naming strategy of
draft-<author>-avt-<short subject>-00.txt

October 27th: FINAL Internet-Draft Cutoff

All revised Internet-Draft submissions must be submitted by Monday,
October 27th, 2003 at 09:00 ET.  Internet-Drafts received after this
time will NOT be announced NOR made available in the Internet-Drafts
Directories.

------------------------------------------------
The deadline to request AVT WG agenda time is:

October 27th: AVT agenda time request Cutoff

Any one desiring to have a presentation and discussion during the AVT
working group's slots in Minneapolis MUST request time on the agenda. A
submission of a draft is not sufficient for receiving agenda time. Send
the request before the 27th October, 2003 at 24.00 GMT to BOTH chairs.
In the request include the following information:

A. Presentation Title:

B. Name of presenter:

C. Draft Reference(s):

D. Requested amount of time in minutes:



Best Regards

Magnus Westerlund & Colin Perkins




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



From exim@www1.ietf.org  Tue Oct  7 13:15:28 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12195
	for <avt-archive@odin.ietf.org>; Tue, 7 Oct 2003 13:15:28 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A6vQS-0004EB-QL
	for avt-archive@odin.ietf.org; Tue, 07 Oct 2003 13:15:08 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h97HF8dL016228
	for avt-archive@odin.ietf.org; Tue, 7 Oct 2003 13:15:08 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A6vQM-0004Cz-Qz; Tue, 07 Oct 2003 13:15:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A6vPe-0004CD-Uq
	for avt@optimus.ietf.org; Tue, 07 Oct 2003 13:14:18 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12143
	for <avt@ietf.org>; Tue, 7 Oct 2003 13:14:08 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A6vPc-0000xb-00
	for avt@ietf.org; Tue, 07 Oct 2003 13:14:16 -0400
Received: from dundee.dcs.gla.ac.uk ([130.209.242.163])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A6vPc-0000x0-00
	for avt@ietf.org; Tue, 07 Oct 2003 13:14:16 -0400
Received: from bisa ([130.209.247.104]:54011 helo=csperkins.org)
	by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.04)
	id 1A6vP3-000263-00; Tue, 07 Oct 2003 18:13:41 +0100
Date: Tue, 7 Oct 2003 18:13:39 +0100
Subject: Re: [AVT] Working group last call: draft-ietf-avt-rtp-clearmode-02.txt
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: IETF AVT WG <avt@ietf.org>, Ruediger.Kreuter@siemens.com
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <3F68535B.6000302@ericsson.com>
Message-Id: <980A896C-F8E9-11D7-A082-000A957FC5F2@csperkins.org>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
Content-Transfer-Encoding: 7bit
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

On Wednesday, Sep 17, 2003, at 13:28 Europe/London, Magnus Westerlund 
wrote:
> This is to announce a working group last call on "RTP payload format 
> for a 64 kbit/s transparent call" 
> (draft-ietf-avt-rtp-clearmode-02.txt).
> Please send any final comments on this draft to the mailing list by 
> 1st of October 2003. If no substantive technical issues are raised, we 
> intend to submit this draft for publication as a proposed standard > RFC.
>
> Note that this draft will not be advanced until we receive at least one
> valid review from someone not directly involved with production of the
> draft (i.e., not an author or contributor).

This working group last call period has finished, and a number of 
comments were received. If I correctly read the list discussion, there 
was no agreement to make technical changes to the draft,  but there 
were several points raised that require clarification, and minor 
editorial changes.

I'd like the author to submit a revised draft to address these 
concerns. Once this is done, I would be grateful if anyone who 
commented could review the revised version to ensure that their comment 
was implemented, before we request publication of the draft.

-- 
Colin Perkins
http://csperkins.org/


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



From exim@www1.ietf.org  Tue Oct  7 17:15:43 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22818
	for <avt-archive@odin.ietf.org>; Tue, 7 Oct 2003 17:15:43 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A6zAv-0008Pi-Qt
	for avt-archive@odin.ietf.org; Tue, 07 Oct 2003 17:15:23 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h97LFLvt032299
	for avt-archive@odin.ietf.org; Tue, 7 Oct 2003 17:15:21 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A6zAc-0008O6-JZ; Tue, 07 Oct 2003 17:15:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A6yty-0007B3-KN
	for avt@optimus.ietf.org; Tue, 07 Oct 2003 16:57:51 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22081
	for <avt@ietf.org>; Tue, 7 Oct 2003 16:57:40 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A6ytw-0003hP-00
	for avt@ietf.org; Tue, 07 Oct 2003 16:57:48 -0400
Received: from dundee.dcs.gla.ac.uk ([130.209.242.163])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A6ytv-0003gZ-00
	for avt@ietf.org; Tue, 07 Oct 2003 16:57:48 -0400
Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:60843 helo=csperkins.org)
	by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.04)
	id 1A6ytP-0002hB-00; Tue, 07 Oct 2003 21:57:15 +0100
Date: Tue, 7 Oct 2003 21:57:10 +0100
Subject: Re: [AVT] RE: I-D ACTION:draft-ash-e2e-voip-hdr-comp-rqmts-01.txt
Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: <avt@ietf.org>, "GOODE, B (Bur), ALABS" <bgoode@att.com>,
        "Hand, James C, ALABS" <jameshand@att.com>,
        "Jim Hand" <hand17@earthlink.net>, "raymond zhang" <zhangr@info.net>,
        "George Swallow" <swallow@cisco.com>
To: "Ash, Gerald R (Jerry), ALABS" <gash@att.com>
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0201EE9D@KCCLUST06EVS1.ugd.att.com>
Message-Id: <D18B5F52-F908-11D7-A082-000A957FC5F2@csperkins.org>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
Content-Transfer-Encoding: 7bit
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Jerry, all,

On Tuesday, Sep 30, 2003, at 23:11 Europe/London, Ash, Gerald R  
(Jerry), ALABS wrote:
> Please review the updated 01 version of the 'Requirements for VoIP  
> Header Compression over Multiple-Hop Paths'  
> http://www.ietf.org/internet-drafts/draft-ash-e2e-voip-hdr-comp-rqmts- 
> 01.txt.
...
> Please let us know your comments and suggestions.

I think this gives a reasonable overview of the problem space. I'd be  
interested, though, to see more discussion of the limiting factor when  
supporting many hop-by-hop CRTP flows: is the primary bottleneck  
processing power in the router, or the amount of per-flow state that  
has to be maintained? Multi-hop header compression will reduce the  
computation, but it's not clear that it will help with the state  
overhead.

-- 
Colin Perkins
http://csperkins.org/


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



From exim@www1.ietf.org  Wed Oct  8 07:16:37 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09715
	for <avt-archive@odin.ietf.org>; Wed, 8 Oct 2003 07:16:37 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7CIg-0006f2-0G
	for avt-archive@odin.ietf.org; Wed, 08 Oct 2003 07:16:15 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h98BGDkC025600
	for avt-archive@odin.ietf.org; Wed, 8 Oct 2003 07:16:13 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7CIT-0006e4-Ha; Wed, 08 Oct 2003 07:16:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7CI8-0006dl-3t
	for avt@optimus.ietf.org; Wed, 08 Oct 2003 07:15:40 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09685
	for <avt@ietf.org>; Wed, 8 Oct 2003 07:15:32 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7CI7-0003VI-00
	for avt@ietf.org; Wed, 08 Oct 2003 07:15:39 -0400
Received: from almso2.att.com ([192.128.166.71] helo=almso2.proxy.att.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7CI7-0003V4-00
	for avt@ietf.org; Wed, 08 Oct 2003 07:15:39 -0400
Received: from attrh5i.attrh.att.com ([135.38.62.12])
	by almso2.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id h98BDcxv002383
	for <avt@ietf.org>; Wed, 8 Oct 2003 07:15:08 -0400
Received: from KCCLUST06EVS1.ugd.att.com (135.38.164.88) by attrh5i.attrh.att.com (6.5.032)
        id 3F307C6C0111B18B; Wed, 8 Oct 2003 07:14:51 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [AVT] RE: I-D ACTION:draft-ash-e2e-voip-hdr-comp-rqmts-01.txt
Date: Wed, 8 Oct 2003 06:15:07 -0500
Message-ID: <9473683187ADC049A855ED2DA739ABCA0201EEAA@KCCLUST06EVS1.ugd.att.com>
Thread-Topic: [AVT] RE: I-D ACTION:draft-ash-e2e-voip-hdr-comp-rqmts-01.txt
Thread-Index: AcONFZ6MBeiIUX41QIuYxRjLAO/h0AAdeAEg
From: "Ash, Gerald R (Jerry)" <gash@att.com>
To: "Colin Perkins" <csp@csperkins.org>
Cc: "Ash, Gerald R (Jerry)" <gash@att.com>, <avt@ietf.org>,
        "GOODE, B (Bur)" <bgoode@att.com>, "Hand, James C" <jameshand@att.com>,
        "raymond zhang" <zhangr@info.net>,
        "George Swallow" <swallow@cisco.com>
Content-Transfer-Encoding: quoted-printable
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable

Jerry> Please review the updated 01 version of the 'Requirements=20
Jerry> for VoIP Header Compression over Multiple-Hop Paths' =20
Jerry> =
http://www.ietf.org/internet-drafts/draft-ash-e2e-voip-hdr-comp-rqmts-01.=
txt.
Jerry> Please let us know your comments and suggestions.

Colin> I think this gives a reasonable overview of the problem=20
Colin> space.=20

Thanks.

Colin> I'd be interested, though, to see more discussion of=20
Colin> the limiting factor when supporting many hop-by-hop=20
Colin> CRTP flows: is the primary bottleneck processing power=20
Colin> in the router, or the amount of per-flow state that =20
Colin> has to be maintained? Multi-hop header compression will=20
Colin> reduce the computation, but it's not clear that it will=20
Colin> help with the state overhead.

IMO this is a scalability question for vendors to answer as far as how =
many multi-hop header compression (MHHC) VoIP flows can be maintained in =
the router versus when real-time runs out versus other limitations.  I =
would expect the answer to be vendor dependent depending on their =
hardware/software implementation.

Right now the CRTP limitation is processor power (~100 --> a few hundred =
CRTP flows or so).  MHHC will increase the number of compressed flows a =
router can handle so maybe some other limiting factor will take over =
instead of processor power.  Obviously there will still be some limiting =
factor, be it processor power, flow-state limitations, or whatever.

It would be good to hear some comments from vendors on this.

Thanks,
Jerry

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



From exim@www1.ietf.org  Wed Oct  8 11:27:30 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22246
	for <avt-archive@odin.ietf.org>; Wed, 8 Oct 2003 11:27:30 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7GDV-0004BZ-2o
	for avt-archive@odin.ietf.org; Wed, 08 Oct 2003 11:27:09 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h98FR9Gf016088
	for avt-archive@odin.ietf.org; Wed, 8 Oct 2003 11:27:09 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7GDN-0004AW-I2; Wed, 08 Oct 2003 11:27:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7GCt-00041M-VQ
	for avt@optimus.ietf.org; Wed, 08 Oct 2003 11:26:31 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22180;
	Wed, 8 Oct 2003 11:26:19 -0400 (EDT)
Message-Id: <200310081526.LAA22180@ietf.org>
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce: ;
Cc: Colin Perkins <csp@csperkins.org>,
        Magnus Westerlund <magnus.westerlund@ericsson.com>, avt@ietf.org
Date: Wed, 08 Oct 2003 11:26:19 -0400
Subject: [AVT] WG Action: RECHARTER: Audio/Video Transport (avt)
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>

The charter of the Audio/Video Transport (avt) working group in 
Transport Area of the IETF has been updated.  For additional information, 
please contact the Area Directors or the working group Chairs.

Audio/Video Transport (avt)
---------------------------

Current Status: Active Working Group

Chair(s):
Colin Perkins <csp@csperkins.org>
Magnus Westerlund <magnus.westerlund@ericsson.com>

Transport Area Director(s):
Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>

Transport Area Advisor:
Allison Mankin <mankin@psg.com>

Mailing Lists:
General Discussion: avt@ietf.org
To Subscribe: avt-request@ietf.org
Archive: www.ietf.org/mail-archive/working-groups/avt/current/maillist.html

The Audio/Video Transport Working Group was formed to specify a
protocol for real-time transmission of audio and video over unicast
and multicast UDP/IP. This is the Real-time Transport Protocol, RTP,
together with its associated profiles and payload formats. The 
current aims of the working group are:     

 - to advance the main RTP specification and RTP Profile 
   for Audio and Video Conferences with Minimal Control 
   for publication as full Internet Standards

 - to review and revise existing payload formats to advance those
   which are useful to Draft Standard, and to declare others
   as Historic. Milestones will be established as a champion for 
   each payload format is identified.

 - to develop payload formats for new media codecs, and to
   document best-current practices in payload format design. 
   The group continues to be precluded from work on codecs 
   themselves because of overlap with the other standards 
   bodies, and because the IETF does not have the ability 
   to effectively review new codecs. An exception was made 
   for the freeware iLBC codec on a highly experimental basis, 
   but acceptance of new codec work is unexpected and subject 
   to rechartering.

 - to complete the forward error correction work in the ULP and
   UXP payload formats

 - to extend RTP to work with Source-Specific Multicast sessions
   with unicast feedback

 - to provide a framing mechanism for RTP over TCP and TLS

 - to review the applicability of Compressed RTP operation on
   MPLS networks, developing extensions as necessary

 - to develop a new RTP profile as the combination of the SRTP
   profile and the Extended RTP Profile for RTCP-based Feedback
   (RTP/SAVPF)

The group will also coordinate with the DCCP working group to
ensure that RTP can be efficiently transported over DCCP.

The longer term goals of the working group are to advance the 
SRTP Profile, the Extended RTP Profile for RTCP-based Feedback,
the Compressed RTP framework, and the RTP MIB to Draft Standard. 

The group has no plans to develop new RTP profiles beyond those
listed above, but will consider rechartering to produce profile
level extensions if appropriate.            

Milestones:

Oct 2003  Review DCCP including prototypes and API; feedback to DCCP WG
Nov 2003  Initial draft requirements for ECRTP over MPLS; discuss with MPLS WG
Dec 2003  Submit UXP Payload Format for Proposed Standard              
Dec 2003  Submit ULP Payload Format for Proposed Standard 
Dec 2003  Submit RTCP/SSM draft for Proposed Standard
Dec 2003  Submit iLBC codec specification for Experimental
Dec 2003  Submit iLBC payload format for Proposed Standard
Jan 2004  Advance RTP specification and A/V profile to Full Standard
Mar 2004  Submit Framing of RTP for TCP and TLS for Proposed Standard
Mar 2004  Identify payload formats to classify as Historic
Mar 2004  Finish requirements for ECRTP over MPLS; 
	  recharter for subsequent work
Jul 2004  Submit RTP/SAVPF profile for Proposed Standard
Jul 2004  Begin update of SRTP profile for Draft Standard RFC
Jul 2004  Begin update of RTP/AVPF profile for Draft Standard RFC
Aug 2004  Consider update of RTP MIB
Nov 2004  Collect SRTP implementation reports
Nov 2004  Collect RTP/AVPF implementation reports
Mar 2005  Submit SRTP for Draft Standard
Mar 2005  Submit RTP/AVPF for Draft Standard





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



From exim@www1.ietf.org  Wed Oct  8 12:35:26 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26601
	for <avt-archive@odin.ietf.org>; Wed, 8 Oct 2003 12:35:26 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7HHF-0000xF-IO
	for avt-archive@odin.ietf.org; Wed, 08 Oct 2003 12:35:06 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h98GZ5AJ003663
	for avt-archive@odin.ietf.org; Wed, 8 Oct 2003 12:35:05 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7HHD-0000wi-DY; Wed, 08 Oct 2003 12:35:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7HGz-0000vY-Ln
	for avt@optimus.ietf.org; Wed, 08 Oct 2003 12:34:49 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26568
	for <avt@ietf.org>; Wed, 8 Oct 2003 12:34:39 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7HGx-0000pN-00
	for avt@ietf.org; Wed, 08 Oct 2003 12:34:47 -0400
Received: from dundee.dcs.gla.ac.uk ([130.209.242.163])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7HGx-0000op-00
	for avt@ietf.org; Wed, 08 Oct 2003 12:34:47 -0400
Received: from bisa ([130.209.247.104]:57818 helo=csperkins.org)
	by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.04)
	id 1A7HGQ-0007gl-00; Wed, 08 Oct 2003 17:34:15 +0100
Date: Wed, 8 Oct 2003 17:34:09 +0100
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: avt@ietf.org, Magnus Westerlund <magnus.westerlund@ericsson.com>
To: Mark Baugher <mark@mbaugher.com>
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <6.0.0.22.2.20031008085425.035fcd48@agora.rdrop.com>
Message-Id: <3DD2B775-F9AD-11D7-A082-000A957FC5F2@csperkins.org>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
Content-Transfer-Encoding: 7bit
Subject: [AVT] Re: WG Action: RECHARTER: Audio/Video Transport (avt)
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Mark,

I fully agree with your assessment. You'll note that the new charter 
says that we will "consider" updating the MIB; the issues you mention 
are those we should work through in the next year or so, to make a 
decision on how to proceed and if there is sufficient community to do 
the work.

The first stage is probably to identify a volunteer to look into these 
issues...

Colin



On Wednesday, Oct 8, 2003, at 17:04 Europe/London, Mark Baugher wrote:

> I see that we want to advance the RTP MIB to draft standard.  At 
> minimum, I think we will want to consider updating the RTP MIB for 
> SRTP.  This is also an opportunity to review 
> ftp://ftp.rfc-editor.org/in-notes/rfc2959.txt and try to ascertain 
> if/how the RTP MIB is used in products or tools.  This MIB was 
> reference by the ITU for H.323 management and there were a number of 
> technical issues in trying to balance multicast uses with 
> pairwise/unicast uses of the RTP MIB.
>
> I think we will need to find a constituency who have products that use 
> the RTP MIB, or need to, and who will drive the effort just as the ITU 
> folks drove the original MIB effort.  To my knowledge, many of the 
> individuals who led this effort are now doing other things and I don't 
> know of any product implementations of the RTP MIB (is videoserver 
> corp even around anymore, it looks like a web commerce site?).
>
> Although we only need two interoperable implementations for draft 
> status, this could be complex since interoperability is bifurcated 
> between pairwise/unicast and multicast types of applications.
>
> Mark
>
> At 08:26 AM 10/8/2003, The IESG wrote:
>> The charter of the Audio/Video Transport (avt) working group in
>> Transport Area of the IETF has been updated.  For additional 
>> information,
>> please contact the Area Directors or the working group Chairs.
>>
>> Audio/Video Transport (avt)
>> ---------------------------
>>
>> Current Status: Active Working Group
>>
>> Chair(s):
>> Colin Perkins <csp@csperkins.org>
>> Magnus Westerlund <magnus.westerlund@ericsson.com>
>>
>> Transport Area Director(s):
>> Allison Mankin <mankin@psg.com>
>> Jon Peterson <jon.peterson@neustar.biz>
>>
>> Transport Area Advisor:
>> Allison Mankin <mankin@psg.com>
>>
>> Mailing Lists:
>> General Discussion: avt@ietf.org
>> To Subscribe: avt-request@ietf.org
>> Archive: 
>> www.ietf.org/mail-archive/working-groups/avt/current/maillist.html
>>
>> The Audio/Video Transport Working Group was formed to specify a
>> protocol for real-time transmission of audio and video over unicast
>> and multicast UDP/IP. This is the Real-time Transport Protocol, RTP,
>> together with its associated profiles and payload formats. The
>> current aims of the working group are:
>>
>>  - to advance the main RTP specification and RTP Profile
>>    for Audio and Video Conferences with Minimal Control
>>    for publication as full Internet Standards
>>
>>  - to review and revise existing payload formats to advance those
>>    which are useful to Draft Standard, and to declare others
>>    as Historic. Milestones will be established as a champion for
>>    each payload format is identified.
>>
>>  - to develop payload formats for new media codecs, and to
>>    document best-current practices in payload format design.
>>    The group continues to be precluded from work on codecs
>>    themselves because of overlap with the other standards
>>    bodies, and because the IETF does not have the ability
>>    to effectively review new codecs. An exception was made
>>    for the freeware iLBC codec on a highly experimental basis,
>>    but acceptance of new codec work is unexpected and subject
>>    to rechartering.
>>
>>  - to complete the forward error correction work in the ULP and
>>    UXP payload formats
>>
>>  - to extend RTP to work with Source-Specific Multicast sessions
>>    with unicast feedback
>>
>>  - to provide a framing mechanism for RTP over TCP and TLS
>>
>>  - to review the applicability of Compressed RTP operation on
>>    MPLS networks, developing extensions as necessary
>>
>>  - to develop a new RTP profile as the combination of the SRTP
>>    profile and the Extended RTP Profile for RTCP-based Feedback
>>    (RTP/SAVPF)
>>
>> The group will also coordinate with the DCCP working group to
>> ensure that RTP can be efficiently transported over DCCP.
>>
>> The longer term goals of the working group are to advance the
>> SRTP Profile, the Extended RTP Profile for RTCP-based Feedback,
>> the Compressed RTP framework, and the RTP MIB to Draft Standard.
>>
>> The group has no plans to develop new RTP profiles beyond those
>> listed above, but will consider rechartering to produce profile
>> level extensions if appropriate.
>>
>> Milestones:
>>
>> Oct 2003  Review DCCP including prototypes and API; feedback to DCCP 
>> WG
>> Nov 2003  Initial draft requirements for ECRTP over MPLS; discuss 
>> with MPLS WG
>> Dec 2003  Submit UXP Payload Format for Proposed Standard
>> Dec 2003  Submit ULP Payload Format for Proposed Standard
>> Dec 2003  Submit RTCP/SSM draft for Proposed Standard
>> Dec 2003  Submit iLBC codec specification for Experimental
>> Dec 2003  Submit iLBC payload format for Proposed Standard
>> Jan 2004  Advance RTP specification and A/V profile to Full Standard
>> Mar 2004  Submit Framing of RTP for TCP and TLS for Proposed Standard
>> Mar 2004  Identify payload formats to classify as Historic
>> Mar 2004  Finish requirements for ECRTP over MPLS;
>>           recharter for subsequent work
>> Jul 2004  Submit RTP/SAVPF profile for Proposed Standard
>> Jul 2004  Begin update of SRTP profile for Draft Standard RFC
>> Jul 2004  Begin update of RTP/AVPF profile for Draft Standard RFC
>> Aug 2004  Consider update of RTP MIB
>> Nov 2004  Collect SRTP implementation reports
>> Nov 2004  Collect RTP/AVPF implementation reports
>> Mar 2005  Submit SRTP for Draft Standard
>> Mar 2005  Submit RTP/AVPF for Draft Standard
>
>
-- 
Colin Perkins
http://csperkins.org/


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



From exim@www1.ietf.org  Wed Oct  8 14:39:26 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02027
	for <avt-archive@odin.ietf.org>; Wed, 8 Oct 2003 14:39:26 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7JDF-0000zK-Dw
	for avt-archive@odin.ietf.org; Wed, 08 Oct 2003 14:39:05 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h98Id5uL003788
	for avt-archive@odin.ietf.org; Wed, 8 Oct 2003 14:39:05 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7JDA-0000y1-UU; Wed, 08 Oct 2003 14:39:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7IBy-00055a-KH
	for avt@optimus.ietf.org; Wed, 08 Oct 2003 13:33:42 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28619
	for <avt@ietf.org>; Wed, 8 Oct 2003 13:33:33 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7IBw-0001a6-00
	for avt@ietf.org; Wed, 08 Oct 2003 13:33:40 -0400
Received: from sa.infonet.com ([192.157.130.21])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7IBv-0001a3-00
	for avt@ietf.org; Wed, 08 Oct 2003 13:33:40 -0400
Received: from delta.info.net (delta.info.net [192.237.125.34])
	by sa.infonet.com  with ESMTP id h98HXXdU018469;
	Wed, 8 Oct 2003 17:33:33 GMT
Received: from zhangr2.info.net (sfjl114.us.info.net [204.79.139.114])
	by delta.info.net  with ESMTP id RAA27223;
	Wed, 8 Oct 2003 17:33:32 GMT
Message-Id: <5.2.0.9.2.20031008102628.00ae8610@delta.info.net>
X-Sender: zhangr@delta.info.net
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Wed, 08 Oct 2003 10:31:01 -0700
To: "Ash, Gerald R (Jerry)" <gash@att.com>,
        "Colin Perkins" <csp@csperkins.org>
From: raymond zhang <zhangr@info.net>
Subject: RE: [AVT] RE: I-D
  ACTION:draft-ash-e2e-voip-hdr-comp-rqmts-01.txt
Cc: "Ash, Gerald R (Jerry)" <gash@att.com>, <avt@ietf.org>,
        "GOODE, B (Bur)" <bgoode@att.com>, "Hand, James C" <jameshand@att.com>,
        "George Swallow" <swallow@cisco.com>
In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0201EEAA@KCCLUST06EVS1.ugd
 .att.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>

At 06:15 AM 10/8/2003 -0500, Ash, Gerald R (Jerry) wrote:
>Jerry> Please review the updated 01 version of the 'Requirements
>Jerry> for VoIP Header Compression over Multiple-Hop Paths'
>Jerry> 
>http://www.ietf.org/internet-drafts/draft-ash-e2e-voip-hdr-comp-rqmts-01.txt.
>Jerry> Please let us know your comments and suggestions.
>
>Colin> I think this gives a reasonable overview of the problem
>Colin> space.
>
>Thanks.
>
>Colin> I'd be interested, though, to see more discussion of
>Colin> the limiting factor when supporting many hop-by-hop
>Colin> CRTP flows: is the primary bottleneck processing power
>Colin> in the router, or the amount of per-flow state that
>Colin> has to be maintained? Multi-hop header compression will
>Colin> reduce the computation, but it's not clear that it will
>Colin> help with the state overhead.
>
>IMO this is a scalability question for vendors to answer as far as how 
>many multi-hop header compression (MHHC) VoIP flows can be maintained in 
>the router versus when real-time runs out versus other limitations.  I 
>would expect the answer to be vendor dependent depending on their 
>hardware/software implementation.
>
>Right now the CRTP limitation is processor power (~100 --> a few hundred 
>CRTP flows or so).  MHHC will increase the number of compressed flows a 
>router can handle so maybe some other limiting factor will take over 
>instead of processor power.  Obviously there will still be some limiting 
>factor, be it processor power, flow-state limitations, or whatever.
>
>It would be good to hear some comments from vendors on this.

Further on Jerry's response, there maybe two aspects of this: number of HC 
flows on the gw (CE) and the number crtp flow states which is in our 
current thinking is at the PE edge router only and the MPLS Core (P core) 
will not maintain nor know anything about them...

Regards,
Raymond

>Thanks,
>Jerry



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



From exim@www1.ietf.org  Wed Oct  8 14:39:26 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02026
	for <avt-archive@odin.ietf.org>; Wed, 8 Oct 2003 14:39:25 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7JDF-0000zL-EE
	for avt-archive@odin.ietf.org; Wed, 08 Oct 2003 14:39:05 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h98Id5b1003789
	for avt-archive@odin.ietf.org; Wed, 8 Oct 2003 14:39:05 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7JDA-0000xt-9r; Wed, 08 Oct 2003 14:39:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7Goq-00070Q-7d
	for avt@optimus.ietf.org; Wed, 08 Oct 2003 12:05:44 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25067
	for <avt@ietf.org>; Wed, 8 Oct 2003 12:05:34 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7Goo-0000JX-00
	for avt@ietf.org; Wed, 08 Oct 2003 12:05:42 -0400
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7Gon-0000JC-00
	for avt@ietf.org; Wed, 08 Oct 2003 12:05:41 -0400
Received: from mbaugher.com (171.71.177.238)
  by sj-iport-2.cisco.com with ESMTP; 08 Oct 2003 09:06:06 -0700
Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15])
	by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h98G58Xg019698;
	Wed, 8 Oct 2003 09:05:09 -0700 (PDT)
Received: from cscoamera13263.mbaugher.com (rtp-vpn2-608.cisco.com [10.82.242.96])
	by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AIV20627;
	Wed, 8 Oct 2003 09:05:07 -0700 (PDT)
Message-Id: <6.0.0.22.2.20031008085425.035fcd48@agora.rdrop.com>
X-Sender: mbaugher@agora.rdrop.com
X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22
Date: Wed, 08 Oct 2003 09:04:19 -0700
To: avt@ietf.org
From: Mark Baugher <mark@mbaugher.com>
Cc: Colin Perkins <csp@csperkins.org>,
        Magnus Westerlund <magnus.westerlund@ericsson.com>
In-Reply-To: <200310081526.LAA22180@ietf.org>
References: <200310081526.LAA22180@ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [AVT] Re: WG Action: RECHARTER: Audio/Video Transport (avt)
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>

I see that we want to advance the RTP MIB to draft standard.  At minimum, I 
think we will want to consider updating the RTP MIB for SRTP.  This is also 
an opportunity to review ftp://ftp.rfc-editor.org/in-notes/rfc2959.txt and 
try to ascertain if/how the RTP MIB is used in products or tools.  This MIB 
was reference by the ITU for H.323 management and there were a number of 
technical issues in trying to balance multicast uses with pairwise/unicast 
uses of the RTP MIB.

I think we will need to find a constituency who have products that use the 
RTP MIB, or need to, and who will drive the effort just as the ITU folks 
drove the original MIB effort.  To my knowledge, many of the individuals 
who led this effort are now doing other things and I don't know of any 
product implementations of the RTP MIB (is videoserver corp even around 
anymore, it looks like a web commerce site?).

Although we only need two interoperable implementations for draft status, 
this could be complex since interoperability is bifurcated between 
pairwise/unicast and multicast types of applications.

Mark

At 08:26 AM 10/8/2003, The IESG wrote:
>The charter of the Audio/Video Transport (avt) working group in
>Transport Area of the IETF has been updated.  For additional information,
>please contact the Area Directors or the working group Chairs.
>
>Audio/Video Transport (avt)
>---------------------------
>
>Current Status: Active Working Group
>
>Chair(s):
>Colin Perkins <csp@csperkins.org>
>Magnus Westerlund <magnus.westerlund@ericsson.com>
>
>Transport Area Director(s):
>Allison Mankin <mankin@psg.com>
>Jon Peterson <jon.peterson@neustar.biz>
>
>Transport Area Advisor:
>Allison Mankin <mankin@psg.com>
>
>Mailing Lists:
>General Discussion: avt@ietf.org
>To Subscribe: avt-request@ietf.org
>Archive: www.ietf.org/mail-archive/working-groups/avt/current/maillist.html
>
>The Audio/Video Transport Working Group was formed to specify a
>protocol for real-time transmission of audio and video over unicast
>and multicast UDP/IP. This is the Real-time Transport Protocol, RTP,
>together with its associated profiles and payload formats. The
>current aims of the working group are:
>
>  - to advance the main RTP specification and RTP Profile
>    for Audio and Video Conferences with Minimal Control
>    for publication as full Internet Standards
>
>  - to review and revise existing payload formats to advance those
>    which are useful to Draft Standard, and to declare others
>    as Historic. Milestones will be established as a champion for
>    each payload format is identified.
>
>  - to develop payload formats for new media codecs, and to
>    document best-current practices in payload format design.
>    The group continues to be precluded from work on codecs
>    themselves because of overlap with the other standards
>    bodies, and because the IETF does not have the ability
>    to effectively review new codecs. An exception was made
>    for the freeware iLBC codec on a highly experimental basis,
>    but acceptance of new codec work is unexpected and subject
>    to rechartering.
>
>  - to complete the forward error correction work in the ULP and
>    UXP payload formats
>
>  - to extend RTP to work with Source-Specific Multicast sessions
>    with unicast feedback
>
>  - to provide a framing mechanism for RTP over TCP and TLS
>
>  - to review the applicability of Compressed RTP operation on
>    MPLS networks, developing extensions as necessary
>
>  - to develop a new RTP profile as the combination of the SRTP
>    profile and the Extended RTP Profile for RTCP-based Feedback
>    (RTP/SAVPF)
>
>The group will also coordinate with the DCCP working group to
>ensure that RTP can be efficiently transported over DCCP.
>
>The longer term goals of the working group are to advance the
>SRTP Profile, the Extended RTP Profile for RTCP-based Feedback,
>the Compressed RTP framework, and the RTP MIB to Draft Standard.
>
>The group has no plans to develop new RTP profiles beyond those
>listed above, but will consider rechartering to produce profile
>level extensions if appropriate.
>
>Milestones:
>
>Oct 2003  Review DCCP including prototypes and API; feedback to DCCP WG
>Nov 2003  Initial draft requirements for ECRTP over MPLS; discuss with MPLS WG
>Dec 2003  Submit UXP Payload Format for Proposed Standard
>Dec 2003  Submit ULP Payload Format for Proposed Standard
>Dec 2003  Submit RTCP/SSM draft for Proposed Standard
>Dec 2003  Submit iLBC codec specification for Experimental
>Dec 2003  Submit iLBC payload format for Proposed Standard
>Jan 2004  Advance RTP specification and A/V profile to Full Standard
>Mar 2004  Submit Framing of RTP for TCP and TLS for Proposed Standard
>Mar 2004  Identify payload formats to classify as Historic
>Mar 2004  Finish requirements for ECRTP over MPLS;
>           recharter for subsequent work
>Jul 2004  Submit RTP/SAVPF profile for Proposed Standard
>Jul 2004  Begin update of SRTP profile for Draft Standard RFC
>Jul 2004  Begin update of RTP/AVPF profile for Draft Standard RFC
>Aug 2004  Consider update of RTP MIB
>Nov 2004  Collect SRTP implementation reports
>Nov 2004  Collect RTP/AVPF implementation reports
>Mar 2005  Submit SRTP for Draft Standard
>Mar 2005  Submit RTP/AVPF for Draft Standard


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



From exim@www1.ietf.org  Wed Oct  8 14:53:27 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02644
	for <avt-archive@odin.ietf.org>; Wed, 8 Oct 2003 14:53:27 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7JQp-0001tA-AI
	for avt-archive@odin.ietf.org; Wed, 08 Oct 2003 14:53:07 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h98Ir7Bg007231
	for avt-archive@odin.ietf.org; Wed, 8 Oct 2003 14:53:07 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7JQk-0001qU-0Q; Wed, 08 Oct 2003 14:53:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7JQc-0001px-M2
	for avt@optimus.ietf.org; Wed, 08 Oct 2003 14:52:54 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02598
	for <avt@ietf.org>; Wed, 8 Oct 2003 14:52:44 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7JQZ-0002ls-00
	for avt@ietf.org; Wed, 08 Oct 2003 14:52:51 -0400
Received: from telchemy.com ([66.155.69.251])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7JQO-0002kz-00
	for avt@ietf.org; Wed, 08 Oct 2003 14:52:40 -0400
Received: from TELWS104 [64.238.103.215] by telchemy.com with ESMTP
  (SMTPD32-7.14) id AC7460401F4; Wed, 08 Oct 2003 14:50:28 -0400
Reply-To: <alan@telchemy.com>
From: "Alan Clark" <alan@telchemy.com>
To: <avt@ietf.org>
Date: Wed, 8 Oct 2003 14:49:51 -0400
Message-ID: <00b201c38dcc$f53e4710$6801a8c0@telchemy.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <3DD2B775-F9AD-11D7-A082-000A957FC5F2@csperkins.org>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Content-Transfer-Encoding: 7bit
Subject: [AVT] MIB based on RTCP XR VoIP metrics
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit


We've been developing a MIB based on the RTCP XR VoIP metrics, to support
VoIP management.  One example of the use of this would be to allow a Gateway
to collect IP phone generated metrics reported through RTCP XR in addition
to retaining locally generated call quality data.

Is anyone interested in this work?

Regards

Alan Clark
Telchemy


-----Original Message-----
From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Colin
Perkins
Sent: Wednesday, October 08, 2003 12:34 PM
To: Mark Baugher
Cc: avt@ietf.org; Magnus Westerlund
Subject: [AVT] Re: WG Action: RECHARTER: Audio/Video Transport (avt)


Mark,

I fully agree with your assessment. You'll note that the new charter
says that we will "consider" updating the MIB; the issues you mention
are those we should work through in the next year or so, to make a
decision on how to proceed and if there is sufficient community to do
the work.

The first stage is probably to identify a volunteer to look into these
issues...

Colin



On Wednesday, Oct 8, 2003, at 17:04 Europe/London, Mark Baugher wrote:

> I see that we want to advance the RTP MIB to draft standard.  At
> minimum, I think we will want to consider updating the RTP MIB for
> SRTP.  This is also an opportunity to review
> ftp://ftp.rfc-editor.org/in-notes/rfc2959.txt and try to ascertain
> if/how the RTP MIB is used in products or tools.  This MIB was
> reference by the ITU for H.323 management and there were a number of
> technical issues in trying to balance multicast uses with
> pairwise/unicast uses of the RTP MIB.
>
> I think we will need to find a constituency who have products that use
> the RTP MIB, or need to, and who will drive the effort just as the ITU
> folks drove the original MIB effort.  To my knowledge, many of the
> individuals who led this effort are now doing other things and I don't
> know of any product implementations of the RTP MIB (is videoserver
> corp even around anymore, it looks like a web commerce site?).
>
> Although we only need two interoperable implementations for draft
> status, this could be complex since interoperability is bifurcated
> between pairwise/unicast and multicast types of applications.
>
> Mark
>
> At 08:26 AM 10/8/2003, The IESG wrote:
>> The charter of the Audio/Video Transport (avt) working group in
>> Transport Area of the IETF has been updated.  For additional
>> information,
>> please contact the Area Directors or the working group Chairs.
>>
>> Audio/Video Transport (avt)
>> ---------------------------
>>
>> Current Status: Active Working Group
>>
>> Chair(s):
>> Colin Perkins <csp@csperkins.org>
>> Magnus Westerlund <magnus.westerlund@ericsson.com>
>>
>> Transport Area Director(s):
>> Allison Mankin <mankin@psg.com>
>> Jon Peterson <jon.peterson@neustar.biz>
>>
>> Transport Area Advisor:
>> Allison Mankin <mankin@psg.com>
>>
>> Mailing Lists:
>> General Discussion: avt@ietf.org
>> To Subscribe: avt-request@ietf.org
>> Archive:
>> www.ietf.org/mail-archive/working-groups/avt/current/maillist.html
>>
>> The Audio/Video Transport Working Group was formed to specify a
>> protocol for real-time transmission of audio and video over unicast
>> and multicast UDP/IP. This is the Real-time Transport Protocol, RTP,
>> together with its associated profiles and payload formats. The
>> current aims of the working group are:
>>
>>  - to advance the main RTP specification and RTP Profile
>>    for Audio and Video Conferences with Minimal Control
>>    for publication as full Internet Standards
>>
>>  - to review and revise existing payload formats to advance those
>>    which are useful to Draft Standard, and to declare others
>>    as Historic. Milestones will be established as a champion for
>>    each payload format is identified.
>>
>>  - to develop payload formats for new media codecs, and to
>>    document best-current practices in payload format design.
>>    The group continues to be precluded from work on codecs
>>    themselves because of overlap with the other standards
>>    bodies, and because the IETF does not have the ability
>>    to effectively review new codecs. An exception was made
>>    for the freeware iLBC codec on a highly experimental basis,
>>    but acceptance of new codec work is unexpected and subject
>>    to rechartering.
>>
>>  - to complete the forward error correction work in the ULP and
>>    UXP payload formats
>>
>>  - to extend RTP to work with Source-Specific Multicast sessions
>>    with unicast feedback
>>
>>  - to provide a framing mechanism for RTP over TCP and TLS
>>
>>  - to review the applicability of Compressed RTP operation on
>>    MPLS networks, developing extensions as necessary
>>
>>  - to develop a new RTP profile as the combination of the SRTP
>>    profile and the Extended RTP Profile for RTCP-based Feedback
>>    (RTP/SAVPF)
>>
>> The group will also coordinate with the DCCP working group to
>> ensure that RTP can be efficiently transported over DCCP.
>>
>> The longer term goals of the working group are to advance the
>> SRTP Profile, the Extended RTP Profile for RTCP-based Feedback,
>> the Compressed RTP framework, and the RTP MIB to Draft Standard.
>>
>> The group has no plans to develop new RTP profiles beyond those
>> listed above, but will consider rechartering to produce profile
>> level extensions if appropriate.
>>
>> Milestones:
>>
>> Oct 2003  Review DCCP including prototypes and API; feedback to DCCP
>> WG
>> Nov 2003  Initial draft requirements for ECRTP over MPLS; discuss
>> with MPLS WG
>> Dec 2003  Submit UXP Payload Format for Proposed Standard
>> Dec 2003  Submit ULP Payload Format for Proposed Standard
>> Dec 2003  Submit RTCP/SSM draft for Proposed Standard
>> Dec 2003  Submit iLBC codec specification for Experimental
>> Dec 2003  Submit iLBC payload format for Proposed Standard
>> Jan 2004  Advance RTP specification and A/V profile to Full Standard
>> Mar 2004  Submit Framing of RTP for TCP and TLS for Proposed Standard
>> Mar 2004  Identify payload formats to classify as Historic
>> Mar 2004  Finish requirements for ECRTP over MPLS;
>>           recharter for subsequent work
>> Jul 2004  Submit RTP/SAVPF profile for Proposed Standard
>> Jul 2004  Begin update of SRTP profile for Draft Standard RFC
>> Jul 2004  Begin update of RTP/AVPF profile for Draft Standard RFC
>> Aug 2004  Consider update of RTP MIB
>> Nov 2004  Collect SRTP implementation reports
>> Nov 2004  Collect RTP/AVPF implementation reports
>> Mar 2005  Submit SRTP for Draft Standard
>> Mar 2005  Submit RTP/AVPF for Draft Standard
>
>
--
Colin Perkins
http://csperkins.org/


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


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



From exim@www1.ietf.org  Wed Oct  8 16:49:28 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08605
	for <avt-archive@odin.ietf.org>; Wed, 8 Oct 2003 16:49:28 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7LF5-0000qP-Pw
	for avt-archive@odin.ietf.org; Wed, 08 Oct 2003 16:49:07 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h98Kn7HY003239
	for avt-archive@odin.ietf.org; Wed, 8 Oct 2003 16:49:07 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7LEz-0000op-O2; Wed, 08 Oct 2003 16:49:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7LEQ-0000nW-8I
	for avt@optimus.ietf.org; Wed, 08 Oct 2003 16:48:26 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08542
	for <avt@ietf.org>; Wed, 8 Oct 2003 16:48:16 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7LEO-0004Dv-00
	for avt@ietf.org; Wed, 08 Oct 2003 16:48:24 -0400
Received: from dundee.dcs.gla.ac.uk ([130.209.242.163])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7LEN-0004Cg-00
	for avt@ietf.org; Wed, 08 Oct 2003 16:48:23 -0400
Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:63624 helo=csperkins.org)
	by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.04)
	id 1A7LDq-0008UE-00; Wed, 08 Oct 2003 21:47:50 +0100
Date: Wed, 8 Oct 2003 21:47:43 +0100
Subject: Re: [AVT] RE: I-D ACTION:draft-ash-e2e-voip-hdr-comp-rqmts-01.txt
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: "Ash, Gerald R (Jerry)" <gash@att.com>, <avt@ietf.org>,
        "GOODE, B (Bur)" <bgoode@att.com>, "Hand, James C" <jameshand@att.com>,
        "George Swallow" <swallow@cisco.com>
To: raymond zhang <zhangr@info.net>
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <5.2.0.9.2.20031008102628.00ae8610@delta.info.net>
Message-Id: <AA52A548-F9D0-11D7-AB1B-000A957FC5F2@csperkins.org>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
Content-Transfer-Encoding: 7bit
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

On Wednesday, Oct 8, 2003, at 18:31 Europe/London, raymond zhang wrote:
> At 06:15 AM 10/8/2003 -0500, Ash, Gerald R (Jerry) wrote:
...
>> Colin> I'd be interested, though, to see more discussion of
>> Colin> the limiting factor when supporting many hop-by-hop
>> Colin> CRTP flows: is the primary bottleneck processing power
>> Colin> in the router, or the amount of per-flow state that
>> Colin> has to be maintained? Multi-hop header compression will
>> Colin> reduce the computation, but it's not clear that it will
>> Colin> help with the state overhead.
>>
>> IMO this is a scalability question for vendors to answer as far as 
>> how many multi-hop header compression (MHHC) VoIP flows can be 
>> maintained in the router versus when real-time runs out versus other 
>> limitations.  I would expect the answer to be vendor dependent 
>> depending on their hardware/software implementation.
>>
>> Right now the CRTP limitation is processor power (~100 --> a few 
>> hundred CRTP flows or so).  MHHC will increase the number of 
>> compressed flows a router can handle so maybe some other limiting 
>> factor will take over instead of processor power.  Obviously there 
>> will still be some limiting factor, be it processor power, flow-state 
>> limitations, or whatever.
>>
>> It would be good to hear some comments from vendors on this.
>
> Further on Jerry's response, there maybe two aspects of this: number 
> of HC flows on the gw (CE) and the number crtp flow states which is in 
> our current thinking is at the PE edge router only and the MPLS Core 
> (P core) will not maintain nor know anything about them...

The core will need to maintain some state for MPLS, no? How large is 
that compared to the CRTP state?

-- 
Colin Perkins
http://csperkins.org/


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



From exim@www1.ietf.org  Wed Oct  8 19:48:31 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15347
	for <avt-archive@odin.ietf.org>; Wed, 8 Oct 2003 19:48:31 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7O2L-0002GD-FC
	for avt-archive@odin.ietf.org; Wed, 08 Oct 2003 19:48:09 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h98Nm9Xg008685
	for avt-archive@odin.ietf.org; Wed, 8 Oct 2003 19:48:09 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7O2D-0002FD-IX; Wed, 08 Oct 2003 19:48:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7O1k-0002Dl-WE
	for avt@optimus.ietf.org; Wed, 08 Oct 2003 19:47:33 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15219
	for <avt@ietf.org>; Wed, 8 Oct 2003 19:47:24 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7O1j-00061Z-00
	for avt@ietf.org; Wed, 08 Oct 2003 19:47:31 -0400
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7O1i-00061D-00
	for avt@ietf.org; Wed, 08 Oct 2003 19:47:30 -0400
Received: from cscoamera13263.cisco.com (rtp-vpn1-339.cisco.com [10.82.225.83])
	by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h98Nkv5h010340;
	Wed, 8 Oct 2003 19:46:58 -0400 (EDT)
Message-Id: <6.0.0.22.2.20031008163752.037a2ff8@mira-sjc5-6.cisco.com>
X-Sender: mbaugher@mira-sjc5-6.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22
Date: Wed, 08 Oct 2003 16:39:46 -0700
To: <alan@telchemy.com>
From: Mark Baugher <mbaugher@cisco.com>
Subject: Re: [AVT] MIB based on RTCP XR VoIP metrics
Cc: <avt@ietf.org>
In-Reply-To: <00b201c38dcc$f53e4710$6801a8c0@telchemy.com>
References: <3DD2B775-F9AD-11D7-A082-000A957FC5F2@csperkins.org>
 <00b201c38dcc$f53e4710$6801a8c0@telchemy.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>

Alan,
   I would expect you to put this added functionality into the RTP MIB and 
not create a MIB for a particular feature of the protocol.  Am I missing 
something here?  A great deal of the RTP MIB RFC 2959 is there for VoIP 
management by way of a group that was doing management for H.323 - the RTP 
MIB was just one piece of their management standard.

Mark
At 11:49 AM 10/8/2003, Alan Clark wrote:

>We've been developing a MIB based on the RTCP XR VoIP metrics, to support
>VoIP management.  One example of the use of this would be to allow a Gateway
>to collect IP phone generated metrics reported through RTCP XR in addition
>to retaining locally generated call quality data.
>
>Is anyone interested in this work?
>
>Regards
>
>Alan Clark
>Telchemy
>
>
>-----Original Message-----
>From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Colin
>Perkins
>Sent: Wednesday, October 08, 2003 12:34 PM
>To: Mark Baugher
>Cc: avt@ietf.org; Magnus Westerlund
>Subject: [AVT] Re: WG Action: RECHARTER: Audio/Video Transport (avt)
>
>
>Mark,
>
>I fully agree with your assessment. You'll note that the new charter
>says that we will "consider" updating the MIB; the issues you mention
>are those we should work through in the next year or so, to make a
>decision on how to proceed and if there is sufficient community to do
>the work.
>
>The first stage is probably to identify a volunteer to look into these
>issues...
>
>Colin
>
>
>
>On Wednesday, Oct 8, 2003, at 17:04 Europe/London, Mark Baugher wrote:
>
> > I see that we want to advance the RTP MIB to draft standard.  At
> > minimum, I think we will want to consider updating the RTP MIB for
> > SRTP.  This is also an opportunity to review
> > ftp://ftp.rfc-editor.org/in-notes/rfc2959.txt and try to ascertain
> > if/how the RTP MIB is used in products or tools.  This MIB was
> > reference by the ITU for H.323 management and there were a number of
> > technical issues in trying to balance multicast uses with
> > pairwise/unicast uses of the RTP MIB.
> >
> > I think we will need to find a constituency who have products that use
> > the RTP MIB, or need to, and who will drive the effort just as the ITU
> > folks drove the original MIB effort.  To my knowledge, many of the
> > individuals who led this effort are now doing other things and I don't
> > know of any product implementations of the RTP MIB (is videoserver
> > corp even around anymore, it looks like a web commerce site?).
> >
> > Although we only need two interoperable implementations for draft
> > status, this could be complex since interoperability is bifurcated
> > between pairwise/unicast and multicast types of applications.
> >
> > Mark
> >
> > At 08:26 AM 10/8/2003, The IESG wrote:
> >> The charter of the Audio/Video Transport (avt) working group in
> >> Transport Area of the IETF has been updated.  For additional
> >> information,
> >> please contact the Area Directors or the working group Chairs.
> >>
> >> Audio/Video Transport (avt)
> >> ---------------------------
> >>
> >> Current Status: Active Working Group
> >>
> >> Chair(s):
> >> Colin Perkins <csp@csperkins.org>
> >> Magnus Westerlund <magnus.westerlund@ericsson.com>
> >>
> >> Transport Area Director(s):
> >> Allison Mankin <mankin@psg.com>
> >> Jon Peterson <jon.peterson@neustar.biz>
> >>
> >> Transport Area Advisor:
> >> Allison Mankin <mankin@psg.com>
> >>
> >> Mailing Lists:
> >> General Discussion: avt@ietf.org
> >> To Subscribe: avt-request@ietf.org
> >> Archive:
> >> www.ietf.org/mail-archive/working-groups/avt/current/maillist.html
> >>
> >> The Audio/Video Transport Working Group was formed to specify a
> >> protocol for real-time transmission of audio and video over unicast
> >> and multicast UDP/IP. This is the Real-time Transport Protocol, RTP,
> >> together with its associated profiles and payload formats. The
> >> current aims of the working group are:
> >>
> >>  - to advance the main RTP specification and RTP Profile
> >>    for Audio and Video Conferences with Minimal Control
> >>    for publication as full Internet Standards
> >>
> >>  - to review and revise existing payload formats to advance those
> >>    which are useful to Draft Standard, and to declare others
> >>    as Historic. Milestones will be established as a champion for
> >>    each payload format is identified.
> >>
> >>  - to develop payload formats for new media codecs, and to
> >>    document best-current practices in payload format design.
> >>    The group continues to be precluded from work on codecs
> >>    themselves because of overlap with the other standards
> >>    bodies, and because the IETF does not have the ability
> >>    to effectively review new codecs. An exception was made
> >>    for the freeware iLBC codec on a highly experimental basis,
> >>    but acceptance of new codec work is unexpected and subject
> >>    to rechartering.
> >>
> >>  - to complete the forward error correction work in the ULP and
> >>    UXP payload formats
> >>
> >>  - to extend RTP to work with Source-Specific Multicast sessions
> >>    with unicast feedback
> >>
> >>  - to provide a framing mechanism for RTP over TCP and TLS
> >>
> >>  - to review the applicability of Compressed RTP operation on
> >>    MPLS networks, developing extensions as necessary
> >>
> >>  - to develop a new RTP profile as the combination of the SRTP
> >>    profile and the Extended RTP Profile for RTCP-based Feedback
> >>    (RTP/SAVPF)
> >>
> >> The group will also coordinate with the DCCP working group to
> >> ensure that RTP can be efficiently transported over DCCP.
> >>
> >> The longer term goals of the working group are to advance the
> >> SRTP Profile, the Extended RTP Profile for RTCP-based Feedback,
> >> the Compressed RTP framework, and the RTP MIB to Draft Standard.
> >>
> >> The group has no plans to develop new RTP profiles beyond those
> >> listed above, but will consider rechartering to produce profile
> >> level extensions if appropriate.
> >>
> >> Milestones:
> >>
> >> Oct 2003  Review DCCP including prototypes and API; feedback to DCCP
> >> WG
> >> Nov 2003  Initial draft requirements for ECRTP over MPLS; discuss
> >> with MPLS WG
> >> Dec 2003  Submit UXP Payload Format for Proposed Standard
> >> Dec 2003  Submit ULP Payload Format for Proposed Standard
> >> Dec 2003  Submit RTCP/SSM draft for Proposed Standard
> >> Dec 2003  Submit iLBC codec specification for Experimental
> >> Dec 2003  Submit iLBC payload format for Proposed Standard
> >> Jan 2004  Advance RTP specification and A/V profile to Full Standard
> >> Mar 2004  Submit Framing of RTP for TCP and TLS for Proposed Standard
> >> Mar 2004  Identify payload formats to classify as Historic
> >> Mar 2004  Finish requirements for ECRTP over MPLS;
> >>           recharter for subsequent work
> >> Jul 2004  Submit RTP/SAVPF profile for Proposed Standard
> >> Jul 2004  Begin update of SRTP profile for Draft Standard RFC
> >> Jul 2004  Begin update of RTP/AVPF profile for Draft Standard RFC
> >> Aug 2004  Consider update of RTP MIB
> >> Nov 2004  Collect SRTP implementation reports
> >> Nov 2004  Collect RTP/AVPF implementation reports
> >> Mar 2005  Submit SRTP for Draft Standard
> >> Mar 2005  Submit RTP/AVPF for Draft Standard
> >
> >
>--
>Colin Perkins
>http://csperkins.org/
>
>
>_______________________________________________
>Audio/Video Transport Working Group
>avt@ietf.org
>https://www1.ietf.org/mailman/listinfo/avt
>
>
>_______________________________________________
>Audio/Video Transport Working Group
>avt@ietf.org
>https://www1.ietf.org/mailman/listinfo/avt



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



From exim@www1.ietf.org  Thu Oct  9 11:22:33 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24358
	for <avt-archive@odin.ietf.org>; Thu, 9 Oct 2003 11:22:33 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7ccE-0001dc-TT
	for avt-archive@odin.ietf.org; Thu, 09 Oct 2003 11:22:11 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h99FMACB006292
	for avt-archive@odin.ietf.org; Thu, 9 Oct 2003 11:22:10 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7cc5-0001cS-LQ; Thu, 09 Oct 2003 11:22:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7cbE-0001b8-Ky
	for avt@optimus.ietf.org; Thu, 09 Oct 2003 11:21:08 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24268
	for <avt@ietf.org>; Thu, 9 Oct 2003 11:21:00 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7cbD-0007bF-00
	for avt@ietf.org; Thu, 09 Oct 2003 11:21:07 -0400
Received: from telchemy.com ([66.155.69.251])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7cbC-0007b6-00
	for avt@ietf.org; Thu, 09 Oct 2003 11:21:07 -0400
Received: from TELWS104 [64.238.103.215] by telchemy.com with ESMTP
  (SMTPD32-7.14) id AC4823600A2; Thu, 09 Oct 2003 11:18:32 -0400
Reply-To: <alan@telchemy.com>
From: "Alan Clark" <alan@telchemy.com>
To: "'Mark Baugher'" <mbaugher@cisco.com>
Cc: <avt@ietf.org>
Subject: RE: [AVT] MIB based on RTCP XR VoIP metrics
Date: Thu, 9 Oct 2003 11:17:54 -0400
Message-ID: <00ad01c38e78$838b4cb0$6801a8c0@telchemy.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <6.0.0.22.2.20031008163752.037a2ff8@mira-sjc5-6.cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Content-Transfer-Encoding: 7bit
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Mark

We could certainly look at incorporating the RTCP XR VoIP metrics into the
RTP MIB.  From a quick look, this would involve the addition of an XR VoIP
Metrics group in a similar vein to the SR and RR groups.
It would be helpful to know how widely implemented the RTP MIB is.  In
developing draft versions of the RTCP XR based MIB we've incorporated some
ideas that are structurally different to the RTP MIB and hence a version 2
MIB maybe a little different to the current RFC.

Regards

Alan


-----Original Message-----
From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Mark
Baugher
Sent: Wednesday, October 08, 2003 7:40 PM
To: alan@telchemy.com
Cc: avt@ietf.org
Subject: Re: [AVT] MIB based on RTCP XR VoIP metrics


Alan,
   I would expect you to put this added functionality into the RTP MIB and
not create a MIB for a particular feature of the protocol.  Am I missing
something here?  A great deal of the RTP MIB RFC 2959 is there for VoIP
management by way of a group that was doing management for H.323 - the RTP
MIB was just one piece of their management standard.

Mark
At 11:49 AM 10/8/2003, Alan Clark wrote:

>We've been developing a MIB based on the RTCP XR VoIP metrics, to support
>VoIP management.  One example of the use of this would be to allow a
Gateway
>to collect IP phone generated metrics reported through RTCP XR in addition
>to retaining locally generated call quality data.
>
>Is anyone interested in this work?
>
>Regards
>
>Alan Clark
>Telchemy
>
>
>-----Original Message-----
>From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Colin
>Perkins
>Sent: Wednesday, October 08, 2003 12:34 PM
>To: Mark Baugher
>Cc: avt@ietf.org; Magnus Westerlund
>Subject: [AVT] Re: WG Action: RECHARTER: Audio/Video Transport (avt)
>
>
>Mark,
>
>I fully agree with your assessment. You'll note that the new charter
>says that we will "consider" updating the MIB; the issues you mention
>are those we should work through in the next year or so, to make a
>decision on how to proceed and if there is sufficient community to do
>the work.
>
>The first stage is probably to identify a volunteer to look into these
>issues...
>
>Colin
>
>
>
>On Wednesday, Oct 8, 2003, at 17:04 Europe/London, Mark Baugher wrote:
>
> > I see that we want to advance the RTP MIB to draft standard.  At
> > minimum, I think we will want to consider updating the RTP MIB for
> > SRTP.  This is also an opportunity to review
> > ftp://ftp.rfc-editor.org/in-notes/rfc2959.txt and try to ascertain
> > if/how the RTP MIB is used in products or tools.  This MIB was
> > reference by the ITU for H.323 management and there were a number of
> > technical issues in trying to balance multicast uses with
> > pairwise/unicast uses of the RTP MIB.
> >
> > I think we will need to find a constituency who have products that use
> > the RTP MIB, or need to, and who will drive the effort just as the ITU
> > folks drove the original MIB effort.  To my knowledge, many of the
> > individuals who led this effort are now doing other things and I don't
> > know of any product implementations of the RTP MIB (is videoserver
> > corp even around anymore, it looks like a web commerce site?).
> >
> > Although we only need two interoperable implementations for draft
> > status, this could be complex since interoperability is bifurcated
> > between pairwise/unicast and multicast types of applications.
> >
> > Mark
> >
> > At 08:26 AM 10/8/2003, The IESG wrote:
> >> The charter of the Audio/Video Transport (avt) working group in
> >> Transport Area of the IETF has been updated.  For additional
> >> information,
> >> please contact the Area Directors or the working group Chairs.
> >>
> >> Audio/Video Transport (avt)
> >> ---------------------------
> >>
> >> Current Status: Active Working Group
> >>
> >> Chair(s):
> >> Colin Perkins <csp@csperkins.org>
> >> Magnus Westerlund <magnus.westerlund@ericsson.com>
> >>
> >> Transport Area Director(s):
> >> Allison Mankin <mankin@psg.com>
> >> Jon Peterson <jon.peterson@neustar.biz>
> >>
> >> Transport Area Advisor:
> >> Allison Mankin <mankin@psg.com>
> >>
> >> Mailing Lists:
> >> General Discussion: avt@ietf.org
> >> To Subscribe: avt-request@ietf.org
> >> Archive:
> >> www.ietf.org/mail-archive/working-groups/avt/current/maillist.html
> >>
> >> The Audio/Video Transport Working Group was formed to specify a
> >> protocol for real-time transmission of audio and video over unicast
> >> and multicast UDP/IP. This is the Real-time Transport Protocol, RTP,
> >> together with its associated profiles and payload formats. The
> >> current aims of the working group are:
> >>
> >>  - to advance the main RTP specification and RTP Profile
> >>    for Audio and Video Conferences with Minimal Control
> >>    for publication as full Internet Standards
> >>
> >>  - to review and revise existing payload formats to advance those
> >>    which are useful to Draft Standard, and to declare others
> >>    as Historic. Milestones will be established as a champion for
> >>    each payload format is identified.
> >>
> >>  - to develop payload formats for new media codecs, and to
> >>    document best-current practices in payload format design.
> >>    The group continues to be precluded from work on codecs
> >>    themselves because of overlap with the other standards
> >>    bodies, and because the IETF does not have the ability
> >>    to effectively review new codecs. An exception was made
> >>    for the freeware iLBC codec on a highly experimental basis,
> >>    but acceptance of new codec work is unexpected and subject
> >>    to rechartering.
> >>
> >>  - to complete the forward error correction work in the ULP and
> >>    UXP payload formats
> >>
> >>  - to extend RTP to work with Source-Specific Multicast sessions
> >>    with unicast feedback
> >>
> >>  - to provide a framing mechanism for RTP over TCP and TLS
> >>
> >>  - to review the applicability of Compressed RTP operation on
> >>    MPLS networks, developing extensions as necessary
> >>
> >>  - to develop a new RTP profile as the combination of the SRTP
> >>    profile and the Extended RTP Profile for RTCP-based Feedback
> >>    (RTP/SAVPF)
> >>
> >> The group will also coordinate with the DCCP working group to
> >> ensure that RTP can be efficiently transported over DCCP.
> >>
> >> The longer term goals of the working group are to advance the
> >> SRTP Profile, the Extended RTP Profile for RTCP-based Feedback,
> >> the Compressed RTP framework, and the RTP MIB to Draft Standard.
> >>
> >> The group has no plans to develop new RTP profiles beyond those
> >> listed above, but will consider rechartering to produce profile
> >> level extensions if appropriate.
> >>
> >> Milestones:
> >>
> >> Oct 2003  Review DCCP including prototypes and API; feedback to DCCP
> >> WG
> >> Nov 2003  Initial draft requirements for ECRTP over MPLS; discuss
> >> with MPLS WG
> >> Dec 2003  Submit UXP Payload Format for Proposed Standard
> >> Dec 2003  Submit ULP Payload Format for Proposed Standard
> >> Dec 2003  Submit RTCP/SSM draft for Proposed Standard
> >> Dec 2003  Submit iLBC codec specification for Experimental
> >> Dec 2003  Submit iLBC payload format for Proposed Standard
> >> Jan 2004  Advance RTP specification and A/V profile to Full Standard
> >> Mar 2004  Submit Framing of RTP for TCP and TLS for Proposed Standard
> >> Mar 2004  Identify payload formats to classify as Historic
> >> Mar 2004  Finish requirements for ECRTP over MPLS;
> >>           recharter for subsequent work
> >> Jul 2004  Submit RTP/SAVPF profile for Proposed Standard
> >> Jul 2004  Begin update of SRTP profile for Draft Standard RFC
> >> Jul 2004  Begin update of RTP/AVPF profile for Draft Standard RFC
> >> Aug 2004  Consider update of RTP MIB
> >> Nov 2004  Collect SRTP implementation reports
> >> Nov 2004  Collect RTP/AVPF implementation reports
> >> Mar 2005  Submit SRTP for Draft Standard
> >> Mar 2005  Submit RTP/AVPF for Draft Standard
> >
> >
>--
>Colin Perkins
>http://csperkins.org/
>
>
>_______________________________________________
>Audio/Video Transport Working Group
>avt@ietf.org
>https://www1.ietf.org/mailman/listinfo/avt
>
>
>_______________________________________________
>Audio/Video Transport Working Group
>avt@ietf.org
>https://www1.ietf.org/mailman/listinfo/avt



_______________________________________________
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 exim@www1.ietf.org  Thu Oct  9 11:40:29 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24851
	for <avt-archive@odin.ietf.org>; Thu, 9 Oct 2003 11:40:29 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7ctb-0002q3-G2
	for avt-archive@odin.ietf.org; Thu, 09 Oct 2003 11:40:07 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h99Fe7UL010846
	for avt-archive@odin.ietf.org; Thu, 9 Oct 2003 11:40:07 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7ctW-0002nw-Ll; Thu, 09 Oct 2003 11:40:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7csa-0002jz-2i
	for avt@optimus.ietf.org; Thu, 09 Oct 2003 11:39:04 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24832
	for <avt@ietf.org>; Thu, 9 Oct 2003 11:38:55 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7csZ-000019-00
	for avt@ietf.org; Thu, 09 Oct 2003 11:39:03 -0400
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7csY-00000q-00
	for avt@ietf.org; Thu, 09 Oct 2003 11:39:02 -0400
Received: from cisco.com (64.102.124.13)
  by sj-iport-2.cisco.com with ESMTP; 09 Oct 2003 08:39:30 -0700
Received: from cscoamera13263.cisco.com (rtp-vpn2-503.cisco.com [10.82.241.247])
	by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h99FcS5h018660;
	Thu, 9 Oct 2003 11:38:28 -0400 (EDT)
Message-Id: <6.0.0.22.2.20031009082430.038237f0@mira-sjc5-6.cisco.com>
X-Sender: mbaugher@mira-sjc5-6.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22
Date: Thu, 09 Oct 2003 08:33:44 -0700
To: <alan@telchemy.com>
From: Mark Baugher <mbaugher@cisco.com>
Subject: Anybody use the RTP MIB? (was RE: [AVT] MIB based on RTCP XR
  VoIP metrics
Cc: <avt@ietf.org>
In-Reply-To: <00ad01c38e78$838b4cb0$6801a8c0@telchemy.com>
References: <6.0.0.22.2.20031008163752.037a2ff8@mira-sjc5-6.cisco.com>
 <00ad01c38e78$838b4cb0$6801a8c0@telchemy.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>

Alan,

At 08:17 AM 10/9/2003, Alan Clark wrote:
>Mark
>
>We could certainly look at incorporating the RTCP XR VoIP metrics into the
>RTP MIB.  From a quick look, this would involve the addition of an XR VoIP
>Metrics group in a similar vein to the SR and RR groups.

I'd be happy to review this for you.  I would suggest that you take the 
RFC, change it, put your name on it in place of the others, and resubmit it.

>It would be helpful to know how widely implemented the RTP MIB is.

That's hard to say.  We can ask this group to look into their products and 
see if it's there.  I doubt if it's widely used though it is an IETF and an 
ITU-referenced standard.

>In
>developing draft versions of the RTCP XR based MIB we've incorporated some
>ideas that are structurally different to the RTP MIB and hence a version 2
>MIB maybe a little different to the current RFC.

I think so too.

Mark


>Regards
>
>Alan
>
>
>-----Original Message-----
>From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Mark
>Baugher
>Sent: Wednesday, October 08, 2003 7:40 PM
>To: alan@telchemy.com
>Cc: avt@ietf.org
>Subject: Re: [AVT] MIB based on RTCP XR VoIP metrics
>
>
>Alan,
>    I would expect you to put this added functionality into the RTP MIB and
>not create a MIB for a particular feature of the protocol.  Am I missing
>something here?  A great deal of the RTP MIB RFC 2959 is there for VoIP
>management by way of a group that was doing management for H.323 - the RTP
>MIB was just one piece of their management standard.
>
>Mark
>At 11:49 AM 10/8/2003, Alan Clark wrote:
>
> >We've been developing a MIB based on the RTCP XR VoIP metrics, to support
> >VoIP management.  One example of the use of this would be to allow a
>Gateway
> >to collect IP phone generated metrics reported through RTCP XR in addition
> >to retaining locally generated call quality data.
> >
> >Is anyone interested in this work?
> >
> >Regards
> >
> >Alan Clark
> >Telchemy
> >
> >
> >-----Original Message-----
> >From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Colin
> >Perkins
> >Sent: Wednesday, October 08, 2003 12:34 PM
> >To: Mark Baugher
> >Cc: avt@ietf.org; Magnus Westerlund
> >Subject: [AVT] Re: WG Action: RECHARTER: Audio/Video Transport (avt)
> >
> >
> >Mark,
> >
> >I fully agree with your assessment. You'll note that the new charter
> >says that we will "consider" updating the MIB; the issues you mention
> >are those we should work through in the next year or so, to make a
> >decision on how to proceed and if there is sufficient community to do
> >the work.
> >
> >The first stage is probably to identify a volunteer to look into these
> >issues...
> >
> >Colin
> >
> >
> >
> >On Wednesday, Oct 8, 2003, at 17:04 Europe/London, Mark Baugher wrote:
> >
> > > I see that we want to advance the RTP MIB to draft standard.  At
> > > minimum, I think we will want to consider updating the RTP MIB for
> > > SRTP.  This is also an opportunity to review
> > > ftp://ftp.rfc-editor.org/in-notes/rfc2959.txt and try to ascertain
> > > if/how the RTP MIB is used in products or tools.  This MIB was
> > > reference by the ITU for H.323 management and there were a number of
> > > technical issues in trying to balance multicast uses with
> > > pairwise/unicast uses of the RTP MIB.
> > >
> > > I think we will need to find a constituency who have products that use
> > > the RTP MIB, or need to, and who will drive the effort just as the ITU
> > > folks drove the original MIB effort.  To my knowledge, many of the
> > > individuals who led this effort are now doing other things and I don't
> > > know of any product implementations of the RTP MIB (is videoserver
> > > corp even around anymore, it looks like a web commerce site?).
> > >
> > > Although we only need two interoperable implementations for draft
> > > status, this could be complex since interoperability is bifurcated
> > > between pairwise/unicast and multicast types of applications.
> > >
> > > Mark
> > >
> > > At 08:26 AM 10/8/2003, The IESG wrote:
> > >> The charter of the Audio/Video Transport (avt) working group in
> > >> Transport Area of the IETF has been updated.  For additional
> > >> information,
> > >> please contact the Area Directors or the working group Chairs.
> > >>
> > >> Audio/Video Transport (avt)
> > >> ---------------------------
> > >>
> > >> Current Status: Active Working Group
> > >>
> > >> Chair(s):
> > >> Colin Perkins <csp@csperkins.org>
> > >> Magnus Westerlund <magnus.westerlund@ericsson.com>
> > >>
> > >> Transport Area Director(s):
> > >> Allison Mankin <mankin@psg.com>
> > >> Jon Peterson <jon.peterson@neustar.biz>
> > >>
> > >> Transport Area Advisor:
> > >> Allison Mankin <mankin@psg.com>
> > >>
> > >> Mailing Lists:
> > >> General Discussion: avt@ietf.org
> > >> To Subscribe: avt-request@ietf.org
> > >> Archive:
> > >> www.ietf.org/mail-archive/working-groups/avt/current/maillist.html
> > >>
> > >> The Audio/Video Transport Working Group was formed to specify a
> > >> protocol for real-time transmission of audio and video over unicast
> > >> and multicast UDP/IP. This is the Real-time Transport Protocol, RTP,
> > >> together with its associated profiles and payload formats. The
> > >> current aims of the working group are:
> > >>
> > >>  - to advance the main RTP specification and RTP Profile
> > >>    for Audio and Video Conferences with Minimal Control
> > >>    for publication as full Internet Standards
> > >>
> > >>  - to review and revise existing payload formats to advance those
> > >>    which are useful to Draft Standard, and to declare others
> > >>    as Historic. Milestones will be established as a champion for
> > >>    each payload format is identified.
> > >>
> > >>  - to develop payload formats for new media codecs, and to
> > >>    document best-current practices in payload format design.
> > >>    The group continues to be precluded from work on codecs
> > >>    themselves because of overlap with the other standards
> > >>    bodies, and because the IETF does not have the ability
> > >>    to effectively review new codecs. An exception was made
> > >>    for the freeware iLBC codec on a highly experimental basis,
> > >>    but acceptance of new codec work is unexpected and subject
> > >>    to rechartering.
> > >>
> > >>  - to complete the forward error correction work in the ULP and
> > >>    UXP payload formats
> > >>
> > >>  - to extend RTP to work with Source-Specific Multicast sessions
> > >>    with unicast feedback
> > >>
> > >>  - to provide a framing mechanism for RTP over TCP and TLS
> > >>
> > >>  - to review the applicability of Compressed RTP operation on
> > >>    MPLS networks, developing extensions as necessary
> > >>
> > >>  - to develop a new RTP profile as the combination of the SRTP
> > >>    profile and the Extended RTP Profile for RTCP-based Feedback
> > >>    (RTP/SAVPF)
> > >>
> > >> The group will also coordinate with the DCCP working group to
> > >> ensure that RTP can be efficiently transported over DCCP.
> > >>
> > >> The longer term goals of the working group are to advance the
> > >> SRTP Profile, the Extended RTP Profile for RTCP-based Feedback,
> > >> the Compressed RTP framework, and the RTP MIB to Draft Standard.
> > >>
> > >> The group has no plans to develop new RTP profiles beyond those
> > >> listed above, but will consider rechartering to produce profile
> > >> level extensions if appropriate.
> > >>
> > >> Milestones:
> > >>
> > >> Oct 2003  Review DCCP including prototypes and API; feedback to DCCP
> > >> WG
> > >> Nov 2003  Initial draft requirements for ECRTP over MPLS; discuss
> > >> with MPLS WG
> > >> Dec 2003  Submit UXP Payload Format for Proposed Standard
> > >> Dec 2003  Submit ULP Payload Format for Proposed Standard
> > >> Dec 2003  Submit RTCP/SSM draft for Proposed Standard
> > >> Dec 2003  Submit iLBC codec specification for Experimental
> > >> Dec 2003  Submit iLBC payload format for Proposed Standard
> > >> Jan 2004  Advance RTP specification and A/V profile to Full Standard
> > >> Mar 2004  Submit Framing of RTP for TCP and TLS for Proposed Standard
> > >> Mar 2004  Identify payload formats to classify as Historic
> > >> Mar 2004  Finish requirements for ECRTP over MPLS;
> > >>           recharter for subsequent work
> > >> Jul 2004  Submit RTP/SAVPF profile for Proposed Standard
> > >> Jul 2004  Begin update of SRTP profile for Draft Standard RFC
> > >> Jul 2004  Begin update of RTP/AVPF profile for Draft Standard RFC
> > >> Aug 2004  Consider update of RTP MIB
> > >> Nov 2004  Collect SRTP implementation reports
> > >> Nov 2004  Collect RTP/AVPF implementation reports
> > >> Mar 2005  Submit SRTP for Draft Standard
> > >> Mar 2005  Submit RTP/AVPF for Draft Standard
> > >
> > >
> >--
> >Colin Perkins
> >http://csperkins.org/
> >
> >
> >_______________________________________________
> >Audio/Video Transport Working Group
> >avt@ietf.org
> >https://www1.ietf.org/mailman/listinfo/avt
> >
> >
> >_______________________________________________
> >Audio/Video Transport Working Group
> >avt@ietf.org
> >https://www1.ietf.org/mailman/listinfo/avt
>
>
>
>_______________________________________________
>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 exim@www1.ietf.org  Fri Oct 10 14:50:38 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12057
	for <avt-archive@odin.ietf.org>; Fri, 10 Oct 2003 14:50:38 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A82LA-0001ny-SE
	for avt-archive@odin.ietf.org; Fri, 10 Oct 2003 14:50:17 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AIoGA2006934
	for avt-archive@odin.ietf.org; Fri, 10 Oct 2003 14:50:16 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A82Kw-0001kj-8n; Fri, 10 Oct 2003 14:50:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A82KL-0001k7-NW
	for avt@optimus.ietf.org; Fri, 10 Oct 2003 14:49:25 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11949
	for <avt@ietf.org>; Fri, 10 Oct 2003 14:49:16 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A82KI-0007a4-00
	for avt@ietf.org; Fri, 10 Oct 2003 14:49:22 -0400
Received: from nan-smtp-02.noos.net ([212.198.2.71] helo=smtp.noos.fr)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A82KI-0007ZP-00
	for avt@ietf.org; Fri, 10 Oct 2003 14:49:22 -0400
Received: (qmail 3892198 invoked by uid 0); 10 Oct 2003 18:42:58 -0000
Received: (qmail 3158711 invoked by uid 0); 8 Oct 2003 15:46:08 -0000
Received: from unknown (HELO asgard.ietf.org) ([132.151.6.40])
          (envelope-sender <owner-ietf-announce@ietf.org>)
          by 212.198.2.71 (qmail-ldap-1.03) with SMTP
          for <ocheron@noos.fr>; 8 Oct 2003 15:46:08 -0000
Received: from majordomo by asgard.ietf.org with local (Exim 4.14)
	id 1A7GE2-0008SX-OE
	for ietf-announce-list@asgard.ietf.org; Wed, 08 Oct 2003 11:27:42 -0400
Received: from ietf.org ([10.27.2.28])
	by asgard.ietf.org with esmtp (Exim 4.14)
	id 1A7GCr-0008LP-JD
	for all-ietf@asgard.ietf.org; Wed, 08 Oct 2003 11:26:29 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22180;
	Wed, 8 Oct 2003 11:26:19 -0400 (EDT)
Message-Id: <200310081526.LAA22180@ietf.org>
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce: ;
Cc: Colin Perkins <csp@csperkins.org>,
        Magnus Westerlund <magnus.westerlund@ericsson.com>, avt@ietf.org
Date: Wed, 08 Oct 2003 11:26:19 -0400
Precedence: bulk
Subject: [AVT] WG Action: RECHARTER: Audio/Video Transport (avt)
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>

The charter of the Audio/Video Transport (avt) working group in 
Transport Area of the IETF has been updated.  For additional information, 
please contact the Area Directors or the working group Chairs.

Audio/Video Transport (avt)
---------------------------

Current Status: Active Working Group

Chair(s):
Colin Perkins <csp@csperkins.org>
Magnus Westerlund <magnus.westerlund@ericsson.com>

Transport Area Director(s):
Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>

Transport Area Advisor:
Allison Mankin <mankin@psg.com>

Mailing Lists:
General Discussion: avt@ietf.org
To Subscribe: avt-request@ietf.org
Archive: www.ietf.org/mail-archive/working-groups/avt/current/maillist.html

The Audio/Video Transport Working Group was formed to specify a
protocol for real-time transmission of audio and video over unicast
and multicast UDP/IP. This is the Real-time Transport Protocol, RTP,
together with its associated profiles and payload formats. The 
current aims of the working group are:     

 - to advance the main RTP specification and RTP Profile 
   for Audio and Video Conferences with Minimal Control 
   for publication as full Internet Standards

 - to review and revise existing payload formats to advance those
   which are useful to Draft Standard, and to declare others
   as Historic. Milestones will be established as a champion for 
   each payload format is identified.

 - to develop payload formats for new media codecs, and to
   document best-current practices in payload format design. 
   The group continues to be precluded from work on codecs 
   themselves because of overlap with the other standards 
   bodies, and because the IETF does not have the ability 
   to effectively review new codecs. An exception was made 
   for the freeware iLBC codec on a highly experimental basis, 
   but acceptance of new codec work is unexpected and subject 
   to rechartering.

 - to complete the forward error correction work in the ULP and
   UXP payload formats

 - to extend RTP to work with Source-Specific Multicast sessions
   with unicast feedback

 - to provide a framing mechanism for RTP over TCP and TLS

 - to review the applicability of Compressed RTP operation on
   MPLS networks, developing extensions as necessary

 - to develop a new RTP profile as the combination of the SRTP
   profile and the Extended RTP Profile for RTCP-based Feedback
   (RTP/SAVPF)

The group will also coordinate with the DCCP working group to
ensure that RTP can be efficiently transported over DCCP.

The longer term goals of the working group are to advance the 
SRTP Profile, the Extended RTP Profile for RTCP-based Feedback,
the Compressed RTP framework, and the RTP MIB to Draft Standard. 

The group has no plans to develop new RTP profiles beyond those
listed above, but will consider rechartering to produce profile
level extensions if appropriate.            

Milestones:

Oct 2003  Review DCCP including prototypes and API; feedback to DCCP WG
Nov 2003  Initial draft requirements for ECRTP over MPLS; discuss with MPLS WG
Dec 2003  Submit UXP Payload Format for Proposed Standard              
Dec 2003  Submit ULP Payload Format for Proposed Standard 
Dec 2003  Submit RTCP/SSM draft for Proposed Standard
Dec 2003  Submit iLBC codec specification for Experimental
Dec 2003  Submit iLBC payload format for Proposed Standard
Jan 2004  Advance RTP specification and A/V profile to Full Standard
Mar 2004  Submit Framing of RTP for TCP and TLS for Proposed Standard
Mar 2004  Identify payload formats to classify as Historic
Mar 2004  Finish requirements for ECRTP over MPLS; 
	  recharter for subsequent work
Jul 2004  Submit RTP/SAVPF profile for Proposed Standard
Jul 2004  Begin update of SRTP profile for Draft Standard RFC
Jul 2004  Begin update of RTP/AVPF profile for Draft Standard RFC
Aug 2004  Consider update of RTP MIB
Nov 2004  Collect SRTP implementation reports
Nov 2004  Collect RTP/AVPF implementation reports
Mar 2005  Submit SRTP for Draft Standard
Mar 2005  Submit RTP/AVPF for Draft Standard






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



From exim@www1.ietf.org  Fri Oct 10 15:27:28 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15054
	for <avt-archive@odin.ietf.org>; Fri, 10 Oct 2003 15:27:28 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A82un-0004BN-Om
	for avt-archive@odin.ietf.org; Fri, 10 Oct 2003 15:27:05 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AJR582016039
	for avt-archive@odin.ietf.org; Fri, 10 Oct 2003 15:27:05 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A82uj-0004AA-KX; Fri, 10 Oct 2003 15:27:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A82uC-00049b-KO
	for avt@optimus.ietf.org; Fri, 10 Oct 2003 15:26:28 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15013
	for <avt@ietf.org>; Fri, 10 Oct 2003 15:26:20 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A82uB-0000Mz-00
	for avt@ietf.org; Fri, 10 Oct 2003 15:26:27 -0400
Received: from mail.on2.com ([66.162.65.131] helo=on2.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A82uA-0000Mo-00
	for avt@ietf.org; Fri, 10 Oct 2003 15:26:26 -0400
Received: Received on2.com
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.0.6249.0
Date: Fri, 10 Oct 2003 15:24:59 -0400
Message-ID: <AFD33B1DBD906847B460CE449A9EC53B54988B@exchange.alb.on2.com>
Thread-Topic: specifying the multicast interface
Thread-Index: AcOPZDJAmE/cv7cXS0GVyeFvAKx5JA==
From: "Matthew Heaney" <mheaney@on2.com>
To: <avt@ietf.org>
X-MailScanner: Found to be clean
Content-Transfer-Encoding: quoted-printable
Subject: [AVT] specifying the multicast interface
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable

When creating a multicast session, it is possible to specify the
outgoing interface using the IP_MULTICAST_IF socket option.  Does RFC
3550 (or 1889) prescribe a mechanism for specifying the interface?

Analogously, the IP_ADD_MEMBERSHIP socket option allows the receiver to
specify the multicast interface explicitly (via the imr_interface data
member of the ip_mreq struct).  Is there a mechanism (via the SDP
DESCRIBE, I guess) for indicating the multicast interface?

Thanks,
Matt


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



From exim@www1.ietf.org  Mon Oct 13 20:58:34 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07828
	for <avt-archive@odin.ietf.org>; Mon, 13 Oct 2003 20:58:33 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A9DVs-0002Yy-Ng
	for avt-archive@odin.ietf.org; Mon, 13 Oct 2003 20:58:12 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9E0wCOC009809
	for avt-archive@odin.ietf.org; Mon, 13 Oct 2003 20:58:12 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A9DVh-0002XW-CD; Mon, 13 Oct 2003 20:58:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A9DVJ-0002Ul-Sq
	for avt@optimus.ietf.org; Mon, 13 Oct 2003 20:57:37 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07757
	for <avt@ietf.org>; Mon, 13 Oct 2003 20:57:28 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A9DVH-0003tW-00
	for avt@ietf.org; Mon, 13 Oct 2003 20:57:35 -0400
Received: from opus.cs.columbia.edu ([128.59.20.100])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A9DVG-0003tT-00
	for avt@ietf.org; Mon, 13 Oct 2003 20:57:34 -0400
Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143])
	(authenticated bits=0)
	by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id h9E0vWAL007903
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT)
	for <avt@ietf.org>; Mon, 13 Oct 2003 20:57:33 -0400 (EDT)
Message-ID: <3F8B49FC.1090907@cs.columbia.edu>
Date: Mon, 13 Oct 2003 20:57:32 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030924 Thunderbird/0.3
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "'avt@ietf.org'" <avt@ietf.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [AVT] Test (reference) file for silence suppression
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Is anybody aware of a reference or test audio file that could be used to 
compare difference silence suppressors, representing reasonably typical 
phonecall background noise?

Thanks.


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



From exim@www1.ietf.org  Tue Oct 14 11:06:28 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13853
	for <avt-archive@odin.ietf.org>; Tue, 14 Oct 2003 11:06:28 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A9QkS-0004Gb-Q4
	for avt-archive@odin.ietf.org; Tue, 14 Oct 2003 11:06:08 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9EF68M5016400
	for avt-archive@odin.ietf.org; Tue, 14 Oct 2003 11:06:08 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A9QkL-0004E7-Am; Tue, 14 Oct 2003 11:06:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A9Qjr-0004Cp-Uq
	for avt@optimus.ietf.org; Tue, 14 Oct 2003 11:05:31 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13806
	for <avt@ietf.org>; Tue, 14 Oct 2003 11:05:20 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A9Qjp-0003sd-00
	for avt@ietf.org; Tue, 14 Oct 2003 11:05:29 -0400
Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A9Qjo-0003sa-00
	for avt@ietf.org; Tue, 14 Oct 2003 11:05:28 -0400
Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121])
	by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9EF5R42014189
	for <avt@ietf.org>; Tue, 14 Oct 2003 17:05:27 +0200 (MEST)
Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55)
	id 43DTBZNP; Tue, 14 Oct 2003 17:05:47 +0200
Message-ID: <3F8C10B4.7070308@ericsson.com>
Date: Tue, 14 Oct 2003 17:05:24 +0200
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: IETF AVT WG <avt@ietf.org>
Subject: [AVT] IETF 58 Deadlines - draft submission and AVT agenda - Reminder
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hi,

I hope you remember the deadlines for draft submission and AVT WG 
meeting agenda requests.

-------------------------------------------------
The Draft submission deadlines are the following:

October 20th: Cutoff for Initial Submissions (new documents)

All initial submissions(-00) must be submitted by Monday, October 20th,
at 09:00 ET.  Initial submissions received after this time will NOT be
made available in the Internet-Drafts directory, and will have to be
resubmitted.

Please note that if your initial submission is intended for the AVT WG
we recommend a naming strategy of
draft-<author>-avt-<short subject>-00.txt

October 27th: FINAL Internet-Draft Cutoff

All revised Internet-Draft submissions must be submitted by Monday,
October 27th, 2003 at 09:00 ET.  Internet-Drafts received after this
time will NOT be announced NOR made available in the Internet-Drafts
Directories.

------------------------------------------------
The deadline to request AVT WG agenda time is:

October 27th: AVT agenda time request Cutoff

Any one desiring to have a presentation and discussion during the AVT
working group's slots in Minneapolis MUST request time on the agenda. A
submission of a draft is not sufficient for receiving agenda time. Send
the request before the 27th October, 2003 at 24.00 GMT to BOTH chairs.
In the request include the following information:

A. Presentation Title:

B. Name of presenter:

C. Draft Reference(s):

D. Requested amount of time in minutes:



Best Regards

Magnus Westerlund & Colin Perkins



_______________________________________________
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 exim@www1.ietf.org  Tue Oct 14 15:37:36 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26503
	for <avt-archive@odin.ietf.org>; Tue, 14 Oct 2003 15:37:36 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A9Uyo-00040U-KQ
	for avt-archive@odin.ietf.org; Tue, 14 Oct 2003 15:37:14 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9EJbE8J015359
	for avt-archive@odin.ietf.org; Tue, 14 Oct 2003 15:37:14 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A9Uyc-0003wQ-7c; Tue, 14 Oct 2003 15:37:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A9Uxd-0003R2-5p
	for avt@optimus.ietf.org; Tue, 14 Oct 2003 15:36:01 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26339;
	Tue, 14 Oct 2003 15:35:51 -0400 (EDT)
Message-Id: <200310141935.PAA26339@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: avt@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Tue, 14 Oct 2003 15:35:51 -0400
Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-clearmode-03.txt
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Audio/Video Transport Working Group of the IETF.

	Title		: RTP payload format for a 64 kbit/s transparent call
	Author(s)	: R. Kreuter
	Filename	: draft-ietf-avt-rtp-clearmode-03.txt
	Pages		: 7
	Date		: 2003-10-14
	
This document describes how to carry 64 kbit/s data streams 
transparently in RTP packets, using a pseudo-codec called 
'Clearmode'.  It also serves as registration for a related MIME type 
called 'audio/clearmode'. 
'Clearmode' is a basic feature of VoIP media gateways.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-clearmode-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-avt-rtp-clearmode-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-clearmode-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:	<2003-10-14150632.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-avt-rtp-clearmode-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-avt-rtp-clearmode-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-10-14150632.I-D@ietf.org>

--OtherAccess--

--NextPart--



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



From exim@www1.ietf.org  Tue Oct 14 17:16:35 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02873
	for <avt-archive@odin.ietf.org>; Tue, 14 Oct 2003 17:16:35 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A9WWc-0002om-Qp
	for avt-archive@odin.ietf.org; Tue, 14 Oct 2003 17:16:15 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9ELGEqL010788
	for avt-archive@odin.ietf.org; Tue, 14 Oct 2003 17:16:14 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A9WWP-0002nK-Um; Tue, 14 Oct 2003 17:16:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A9WVe-0002Z5-6S
	for avt@optimus.ietf.org; Tue, 14 Oct 2003 17:15:14 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02832
	for <avt@ietf.org>; Tue, 14 Oct 2003 17:15:03 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A9WVb-0001HK-00
	for avt@ietf.org; Tue, 14 Oct 2003 17:15:11 -0400
Received: from igloo.df.lth.se ([194.47.250.47] ident=daemon)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A9WVa-0001HF-00
	for avt@ietf.org; Tue, 14 Oct 2003 17:15:11 -0400
Received: from localhost (triad@localhost)
	by igloo.df.lth.se (8.11.7p1+Sun/8.9.3) with ESMTP id h9ELF7K02727
	for <avt@ietf.org>; Tue, 14 Oct 2003 23:15:07 +0200 (MEST)
Date: Tue, 14 Oct 2003 23:15:06 +0200 (MEST)
From: Linus Walleij <triad@df.lth.se>
To: avt@ietf.org
Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-rtp-clearmode-03.txt
In-Reply-To: <200310141935.PAA26339@ietf.org>
Message-ID: <Pine.GSO.4.44.0310142311310.29873-100000@igloo.df.lth.se>
X-Justice: You know what you doing.
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>

One minor:

   This document also serves as the MIME type registration according RFC
                                                                    ^
                                                                    to
Apart from that it's ready to roll, IMHO.

Linus


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



From exim@www1.ietf.org  Wed Oct 15 02:13:45 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29351
	for <avt-archive@odin.ietf.org>; Wed, 15 Oct 2003 02:13:45 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A9euQ-0001TF-Uw
	for avt-archive@odin.ietf.org; Wed, 15 Oct 2003 02:13:23 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9F6DMaQ005653
	for avt-archive@odin.ietf.org; Wed, 15 Oct 2003 02:13:22 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A9eu5-0001QX-6Q; Wed, 15 Oct 2003 02:13:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A9eu1-0001QC-8D
	for avt@optimus.ietf.org; Wed, 15 Oct 2003 02:12:57 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28529
	for <avt@ietf.org>; Wed, 15 Oct 2003 02:12:48 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A9etx-00075m-00
	for avt@ietf.org; Wed, 15 Oct 2003 02:12:53 -0400
Received: from malazgirt.ege.edu.tr ([155.223.251.1] helo=gatekeeper.ege.edu.tr)
	by ietf-mx with smtp (Exim 4.12)
	id 1A9etw-00075E-00
	for avt@ietf.org; Wed, 15 Oct 2003 02:12:53 -0400
Received: from kantarci (bilmuh24106.bilgmuh.ege.edu.tr [155.223.24.106]) 	by bornova.ege.edu.tr (8.11.3/8.11.3) with ESMTP id h9F6Ad005685 	for <avt@ietf.org>; Wed, 15 Oct 2003 09:10:39 +0300 (EET DST)
From: "Aylin Kantarci" <kantarci@bornova.ege.edu.tr>
To: <avt@ietf.org>
Date: Wed, 15 Oct 2003 09:12:08 +0300
Message-ID: <000a01c392e3$44354880$6a18df9b@compeng.ege.edu.tr>
MIME-Version: 1.0
Content-Type: multipart/alternative; 	boundary="----=_NextPart_000_000B_01C392FC.69828080"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2616
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Subject: [AVT] Instant messaging
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_000B_01C392FC.69828080
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

 
Hello
 
I am looking for documantation on Instant messaging. I will be glad if
you recommend a few links.
 
Aylin


------=_NextPart_000_000B_01C392FC.69828080
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR></HEAD>
<BODY style=3D"COLOR: #000000; FONT-FAMILY: "><LABEL id=3DHbSession=20
SessionId=3D"47321022"></LABEL>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D936471006-15102003>Hello</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D936471006-15102003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D936471006-15102003>I am =
looking for=20
documantation on Instant messaging. I will be glad if you recommend a =
few=20
links.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D936471006-15102003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D936471006-15102003>Aylin</SPAN></FONT></DIV>
<P></P></BODY></HTML>

------=_NextPart_000_000B_01C392FC.69828080--



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



From exim@www1.ietf.org  Wed Oct 15 03:19:27 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18297
	for <avt-archive@odin.ietf.org>; Wed, 15 Oct 2003 03:19:27 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A9fw0-0007s4-G0
	for avt-archive@odin.ietf.org; Wed, 15 Oct 2003 03:19:04 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9F7J4nb030192
	for avt-archive@odin.ietf.org; Wed, 15 Oct 2003 03:19:04 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A9fvy-0007qi-2n; Wed, 15 Oct 2003 03:19:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A9fvp-0007qM-NT
	for avt@optimus.ietf.org; Wed, 15 Oct 2003 03:18:53 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18225
	for <avt@ietf.org>; Wed, 15 Oct 2003 03:18:46 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A9fvn-0000Nl-00
	for avt@ietf.org; Wed, 15 Oct 2003 03:18:51 -0400
Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A9fvm-0000Ng-00
	for avt@ietf.org; Wed, 15 Oct 2003 03:18:50 -0400
Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118])
	by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9F7ImSs015420;
	Wed, 15 Oct 2003 09:18:48 +0200 (MEST)
Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55)
	id 43DNF6ZV; Wed, 15 Oct 2003 09:22:39 +0200
Message-ID: <3F8CF4D3.6000506@ericsson.com>
Date: Wed, 15 Oct 2003 09:18:43 +0200
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Aylin Kantarci <kantarci@bornova.ege.edu.tr>
CC: avt@ietf.org
Subject: Re: [AVT] Instant messaging
References: <000a01c392e3$44354880$6a18df9b@compeng.ege.edu.tr>
In-Reply-To: <000a01c392e3$44354880$6a18df9b@compeng.ege.edu.tr>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hi Aylin,

I think what you look for is the SIMPLE WG.
http://www.ietf.org/html.charters/simple-charter.html

To my knowledge we haven't had any discussion concerning instant 
messaging in this WG, and the charter for AVT 
(http://www.ietf.org/html.charters/avt-charter.html) does not hint 
toward that. So I would recommend that you in the future spend some more 
time checking if a question is appropriate in a forum before voicing it.

To find the appropriate WG within IETF the best way is to look through 
the WG list and check their charters.

Best Regards

Magnus


Aylin Kantarci wrote:

> Hello
>  
> I am looking for documantation on Instant messaging. I will be glad if 
> you recommend a few links.
>  
> Aylin
> 

-- 

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 exim@www1.ietf.org  Wed Oct 15 05:57:34 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22769
	for <avt-archive@odin.ietf.org>; Wed, 15 Oct 2003 05:57:34 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A9iP3-0001S5-MZ
	for avt-archive@odin.ietf.org; Wed, 15 Oct 2003 05:57:13 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9F9vDWg005538
	for avt-archive@odin.ietf.org; Wed, 15 Oct 2003 05:57:13 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A9iOs-0001Mu-HF; Wed, 15 Oct 2003 05:57:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A9iOe-0001Ld-WD
	for avt@optimus.ietf.org; Wed, 15 Oct 2003 05:56:49 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22647;
	Wed, 15 Oct 2003 05:56:38 -0400 (EDT)
From: Rod.Walsh@nokia.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A9iOa-000264-00; Wed, 15 Oct 2003 05:56:44 -0400
Received: from mgw-x1.nokia.com ([131.228.20.21])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A9iOZ-00025w-00; Wed, 15 Oct 2003 05:56:43 -0400
Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33])
	by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9F9ugd08787;
	Wed, 15 Oct 2003 12:56:42 +0300 (EET DST)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T654c3a8bf2ac158f21081@esvir01nok.ntc.nokia.com>;
 Wed, 15 Oct 2003 12:56:42 +0300
Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Wed, 15 Oct 2003 12:56:41 +0300
Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe014.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Wed, 15 Oct 2003 12:56:39 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 15 Oct 2003 12:56:38 +0300
Message-ID: <2BF0AD29BC31FE46B788773211440431038165E6@trebe003.europe.nokia.com>
Thread-Topic: Multicast Session/Service/etc discovery & announcement
Thread-Index: AcOS9gsoVA8cELvBTy+SKp1fLS1jzg==
To: <magma@ietf.org>, <msec@securemulticast.org>, <rmt@ietf.org>,
        <avt@ietf.org>, <ip-dvb@erg.abdn.ac.uk>
Cc: <mmusic@ietf.org>
X-OriginalArrivalTime: 15 Oct 2003 09:56:39.0866 (UTC) FILETIME=[A11B89A0:01C39302]
Content-Transfer-Encoding: quoted-printable
Subject: [AVT] Multicast Session/Service/etc discovery & announcement
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable

Does our current effort to summarize multicast service discovery =
requirements in MMUSIC meet your needs?

Internet Media Guide requirements: =
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-img-req-00.txt

Clearly, exchanging/announcing session/etc parameters effects joining =
(SSM and ASM), involves security risks and enable multicast content =
services - like streaming media and file delivery. So any comments, =
criticisms, ideas and beers are welcome. (Speaking of service =
announcements, does Minneapolis offer the same excellent range of Ales =
as San Francisco?)

Cheers,
Rod.

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



From exim@www1.ietf.org  Wed Oct 15 13:32:41 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11986
	for <avt-archive@odin.ietf.org>; Wed, 15 Oct 2003 13:32:41 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A9pVS-0006Cu-Bt
	for avt-archive@odin.ietf.org; Wed, 15 Oct 2003 13:32:19 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9FHWILZ023858
	for avt-archive@odin.ietf.org; Wed, 15 Oct 2003 13:32:18 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A9pVB-0006C3-AY; Wed, 15 Oct 2003 13:32:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A9pUb-00068b-Oq
	for avt@optimus.ietf.org; Wed, 15 Oct 2003 13:31:25 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11960
	for <avt@ietf.org>; Wed, 15 Oct 2003 13:31:15 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A9pUZ-0000Yc-00
	for avt@ietf.org; Wed, 15 Oct 2003 13:31:23 -0400
Received: from sa.infonet.com ([192.157.130.21])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A9pUY-0000YZ-00
	for avt@ietf.org; Wed, 15 Oct 2003 13:31:23 -0400
Received: from delta.info.net (delta.info.net [192.237.125.34])
	by sa.infonet.com  with ESMTP id h9FHUhLV008754;
	Wed, 15 Oct 2003 17:30:43 GMT
Received: from zhangr2.info.net (sfjl114.us.info.net [204.79.139.114])
	by delta.info.net  with ESMTP id RAA27317;
	Wed, 15 Oct 2003 17:30:42 GMT
Message-Id: <5.2.0.9.2.20031015102933.02b98eb0@delta.info.net>
X-Sender: zhangr@delta.info.net
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Wed, 15 Oct 2003 10:30:36 -0700
To: Colin Perkins <csp@csperkins.org>
From: raymond zhang <zhangr@info.net>
Subject: Re: [AVT] RE: I-D
  ACTION:draft-ash-e2e-voip-hdr-comp-rqmts-01.txt
Cc: "Ash, Gerald R (Jerry)" <gash@att.com>, <avt@ietf.org>,
        "GOODE, B (Bur)" <bgoode@att.com>, "Hand, James C" <jameshand@att.com>,
        "George Swallow" <swallow@cisco.com>
In-Reply-To: <AA52A548-F9D0-11D7-AB1B-000A957FC5F2@csperkins.org>
References: <5.2.0.9.2.20031008102628.00ae8610@delta.info.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>

Hi Colin,

Sorry for the delayed response...

At 09:47 PM 10/8/2003 +0100, Colin Perkins wrote:
>On Wednesday, Oct 8, 2003, at 18:31 Europe/London, raymond zhang wrote:
>>At 06:15 AM 10/8/2003 -0500, Ash, Gerald R (Jerry) wrote:
>...
>>>Colin> I'd be interested, though, to see more discussion of
>>>Colin> the limiting factor when supporting many hop-by-hop
>>>Colin> CRTP flows: is the primary bottleneck processing power
>>>Colin> in the router, or the amount of per-flow state that
>>>Colin> has to be maintained? Multi-hop header compression will
>>>Colin> reduce the computation, but it's not clear that it will
>>>Colin> help with the state overhead.
>>>
>>>IMO this is a scalability question for vendors to answer as far as how 
>>>many multi-hop header compression (MHHC) VoIP flows can be maintained in 
>>>the router versus when real-time runs out versus other limitations.  I 
>>>would expect the answer to be vendor dependent depending on their 
>>>hardware/software implementation.
>>>
>>>Right now the CRTP limitation is processor power (~100 --> a few hundred 
>>>CRTP flows or so).  MHHC will increase the number of compressed flows a 
>>>router can handle so maybe some other limiting factor will take over 
>>>instead of processor power.  Obviously there will still be some limiting 
>>>factor, be it processor power, flow-state limitations, or whatever.
>>>
>>>It would be good to hear some comments from vendors on this.
>>
>>Further on Jerry's response, there maybe two aspects of this: number of 
>>HC flows on the gw (CE) and the number crtp flow states which is in our 
>>current thinking is at the PE edge router only and the MPLS Core (P core) 
>>will not maintain nor know anything about them...
>
>The core will need to maintain some state for MPLS, no? How large is that 
>compared to the CRTP state?

Yes..  Much less though since the P routers in a MPLS core would only need 
to maintain label states for reaching PE routers in the network.

Cheers,
Raymond

>--
>Colin Perkins
>http://csperkins.org/
>



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



From exim@www1.ietf.org  Fri Oct 17 07:28:37 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28031
	for <avt-archive@odin.ietf.org>; Fri, 17 Oct 2003 07:28:37 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AASmF-0006oM-4W
	for avt-archive@odin.ietf.org; Fri, 17 Oct 2003 07:28:15 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HBSFa1026139
	for avt-archive@odin.ietf.org; Fri, 17 Oct 2003 07:28:15 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AASm1-0006mi-Po; Fri, 17 Oct 2003 07:28:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AASl9-0006bF-Lz
	for avt@optimus.ietf.org; Fri, 17 Oct 2003 07:27:07 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27960
	for <avt@ietf.org>; Fri, 17 Oct 2003 07:26:59 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AASl8-0002MU-00
	for avt@ietf.org; Fri, 17 Oct 2003 07:27:06 -0400
Received: from dundee.dcs.gla.ac.uk ([130.209.242.163])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AASl8-0002MM-00
	for avt@ietf.org; Fri, 17 Oct 2003 07:27:06 -0400
Received: from bisa ([130.209.247.104]:54802 helo=csperkins.org)
	by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.04)
	id 1AASkd-0007HI-00
	for avt@ietf.org; Fri, 17 Oct 2003 12:26:35 +0100
Date: Fri, 17 Oct 2003 12:26:29 +0100
Mime-Version: 1.0 (Apple Message framework v552)
Content-Type: text/plain; charset=US-ASCII; format=flowed
From: Colin Perkins <csp@csperkins.org>
To: avt@ietf.org
Content-Transfer-Encoding: 7bit
Message-Id: <C0B84FE2-0094-11D8-BFBE-000A957FC5F2@csperkins.org>
X-Mailer: Apple Mail (2.552)
Content-Transfer-Encoding: 7bit
Subject: [AVT] Reminder: I-D submission deadline
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

The deadline for submission of -00 internet-drafts is 9am US EDT (GMT 
-04:00) on Monday. Individual submissions intended for eventual working 
group discussion should be named 
draft-<authorname>-avt-<shortsubject>-00.txt. Initial working group 
drafts, which have previously been approved by the chairs, may use the 
draft-ietf-avt- prefix.

The deadline for all other internet-draft submissions is Monday 27th 
October.

Any one desiring to have a presentation and discussion during the AVT 
working group's slots in Minneapolis MUST request time on the agenda. A 
submission of a draft is not sufficient for receiving agenda time. Send 
the request before the 27th October, 2003 at 24.00 GMT to BOTH chairs. 
In the request include the following information:

A. Presentation Title:

B. Name of presenter:

C. Draft Reference(s):

D. Requested amount of time in minutes:


-- 
Colin Perkins
http://csperkins.org/


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



From exim@www1.ietf.org  Fri Oct 17 07:33:23 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28193
	for <avt-archive@odin.ietf.org>; Fri, 17 Oct 2003 07:33:23 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AASqr-0007F9-LD
	for avt-archive@odin.ietf.org; Fri, 17 Oct 2003 07:33:01 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HBX1qe027818
	for avt-archive@odin.ietf.org; Fri, 17 Oct 2003 07:33:01 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AASqr-0007E8-4d; Fri, 17 Oct 2003 07:33:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AASq7-0007DF-UC
	for avt@optimus.ietf.org; Fri, 17 Oct 2003 07:32:15 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28171
	for <avt@ietf.org>; Fri, 17 Oct 2003 07:32:07 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AASq7-0002Qa-00
	for avt@ietf.org; Fri, 17 Oct 2003 07:32:15 -0400
Received: from dundee.dcs.gla.ac.uk ([130.209.242.163])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AASq6-0002QJ-00
	for avt@ietf.org; Fri, 17 Oct 2003 07:32:14 -0400
Received: from bisa ([130.209.247.104]:54805 helo=csperkins.org)
	by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.04)
	id 1AASpc-0007Ig-00
	for avt@ietf.org; Fri, 17 Oct 2003 12:31:44 +0100
Date: Fri, 17 Oct 2003 12:31:38 +0100
Mime-Version: 1.0 (Apple Message framework v552)
Content-Type: text/plain; charset=US-ASCII; format=flowed
From: Colin Perkins <csp@csperkins.org>
To: avt@ietf.org
Content-Transfer-Encoding: 7bit
Message-Id: <78C09B99-0095-11D8-BFBE-000A957FC5F2@csperkins.org>
X-Mailer: Apple Mail (2.552)
Content-Transfer-Encoding: 7bit
Subject: [AVT] Document editor's training
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

The following training session might be of interest to group members:

> We will also be presenting a new editor's training session in
> Minneapolis, as follows:
>
>     Sunday, November 10, 2003
>     =========================
>     1330-1500  Editor's Training -- Conrad C
>
>     Training for current or aspiring IETF document
>     editors.  Covers the roles and responsibilities
>     of a document editor, and includes advice on
>     producing a high-quality IETF specification.
>
> Please feel free to forward this information to your document
> editors and suggest that they attend.

-- 
Colin Perkins
http://csperkins.org/


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



From exim@www1.ietf.org  Fri Oct 17 12:50:33 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09949
	for <avt-archive@odin.ietf.org>; Fri, 17 Oct 2003 12:50:33 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AAXnp-0006J3-OY
	for avt-archive@odin.ietf.org; Fri, 17 Oct 2003 12:50:13 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HGoDxV024198
	for avt-archive@odin.ietf.org; Fri, 17 Oct 2003 12:50:13 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AAXnf-0006Hg-3E; Fri, 17 Oct 2003 12:50:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AAXmw-0006GV-Dh
	for avt@optimus.ietf.org; Fri, 17 Oct 2003 12:49:18 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09876
	for <avt@ietf.org>; Fri, 17 Oct 2003 12:49:07 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AAXmu-0005UI-00
	for avt@ietf.org; Fri, 17 Oct 2003 12:49:16 -0400
Received: from ondar.cablelabs.com ([192.160.73.61])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AAXmg-0005Td-00
	for avt@ietf.org; Fri, 17 Oct 2003 12:49:02 -0400
Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20])
	by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id h9HGmG10012289
	for <avt@ietf.org>; Fri, 17 Oct 2003 10:48:17 -0600 (MDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 17 Oct 2003 10:48:16 -0600
Message-ID: <AEE1FD45F580334296FDA24A1167FFA5028481@srvxchg.cablelabs.com>
Thread-Topic: Any thoughts on documenting RTP/RTCP port usage?
Thread-Index: AcOUonPcd5VXtyD4SNWwPHF+iO6gYAAKjcLg
From: "Jean-Francois Mule" <jf.mule@cablelabs.com>
To: <avt@ietf.org>
X-Approved: ondar
Content-Transfer-Encoding: quoted-printable
Subject: [AVT] Any thoughts on documenting RTP/RTCP port usage?
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable

I'm curious to know whether there has been some discussion on =
documenting the RTP/RTCP port use in the real world today. Many =
applications use RTP&RTCP and random UDP ports outside the IANA =
registry. Some RTP entries exist in the IANA registry today (see below), =
but most commonly used RTP applications don't have an entry.

Some operators may want to be able to establish strict firewall rules on =
UDP traffic. This is where some kind of registry for RTP traffic could =
help, especially since there are some streaming applications that =
consistently use the same not-that-well-known ports.

Any thoughts on this? Has an RTP port registry been considered? Is this =
a bad idea?
Thanks in advance,
Jean-Fran=E7ois=20
---
paging-port     3771/tdp   RTP Paging Port
paging-port     3771/udp   RTP Paging Port
#                          Patrick Ferriter =
<Patrick.Ferriter@zultys.com> June 2003

espeech-rtp     8417/tcp    eSpeech RTP Protocol
espeech-rtp     8417/udp    eSpeech RTP Protocol
#                           Scott Tarone <starone@proactivethought.com> =
April 2003


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



From exim@www1.ietf.org  Sat Oct 18 14:22:36 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04502
	for <avt-archive@odin.ietf.org>; Sat, 18 Oct 2003 14:22:36 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AAviS-00019T-AF
	for avt-archive@odin.ietf.org; Sat, 18 Oct 2003 14:22:16 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9IIMGBK004384
	for avt-archive@odin.ietf.org; Sat, 18 Oct 2003 14:22:16 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AAviD-00010w-1o; Sat, 18 Oct 2003 14:22:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AAvhd-0000lw-HY
	for avt@optimus.ietf.org; Sat, 18 Oct 2003 14:21:27 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04474
	for <avt@ietf.org>; Sat, 18 Oct 2003 14:21:15 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AAvha-00049r-00
	for avt@ietf.org; Sat, 18 Oct 2003 14:21:22 -0400
Received: from rrcs-midsouth-24-199-215-41.biz.rr.com
	([24.199.215.41] helo=paris.packetizer.org ident=system)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AAvha-00049M-00
	for avt@ietf.org; Sat, 18 Oct 2003 14:21:22 -0400
Received: from PAULEJW2K1 (geneva.packetizer.org [192.168.1.2])
	by paris.packetizer.org (8.12.5/8.12.5) with SMTP id h9IHL4BQ014240;
	Sat, 18 Oct 2003 13:21:05 -0400
Message-ID: <006601c395a4$71fb5de0$e1cc6a9c@cisco.com>
From: "Paul E. Jones" <paulej@packetizer.com>
To: "Colin Perkins" <csp@csperkins.org>
Cc: <avt@ietf.org>
References: <2BA438E0-F336-11D7-8BFC-000A957FC5F2@csperkins.org>
Subject: Re: [AVT] Fw: I-D ACTION:draft-jones-avt-audio-t38-01.txt
Date: Sat, 18 Oct 2003 14:19:59 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Content-Transfer-Encoding: 7bit
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Colin,

Thanks.  I've revised my local copy and you'll see this request reflected in
the next I-D.

Do we have general agreement to allow this to move forward as a working
group item for publication as an RFC.  As I mentioned, we have a goal set
for referencing this work in documents produced in the January 2004 meeting
of ITU-T SG16.

Paul

----- Original Message ----- 
From: "Colin Perkins" <csp@csperkins.org>
To: "Paul E. Jones" <paulej@packetizer.com>
Cc: <avt@ietf.org>
Sent: Tuesday, September 30, 2003 7:06 AM
Subject: Re: [AVT] Fw: I-D ACTION:draft-jones-avt-audio-t38-01.txt


> Paul,
>
> On Monday, Sep 22, 2003, at 21:38 Europe/London, Paul E. Jones wrote:
> > I just submitted a revised document on the transport of T.38 via RTP.
> > Please review and comment on this document.  This document is a
> > dependency
> > on an amendment to T.38 that is currently being considered within ITU
> > for
> > approval in January 2004.
>
> I have one minor suggestion, which is to add the text "One new MIME
> type and associated RTP payload format is to be registered, as
> described below" at the beginning of Section 4 (to ensure that the IANA
> enters this into the table of RTP payload formats). Otherwise it looks
> very reasonable.
>
> -- 
> Colin Perkins
> http://csperkins.org/
>


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



From exim@www1.ietf.org  Sat Oct 18 14:55:23 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05675
	for <avt-archive@odin.ietf.org>; Sat, 18 Oct 2003 14:55:23 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AAwEC-0001R5-6X
	for avt-archive@odin.ietf.org; Sat, 18 Oct 2003 14:55:04 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9IIt4X2005513
	for avt-archive@odin.ietf.org; Sat, 18 Oct 2003 14:55:04 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AAwEA-0001QN-Mp; Sat, 18 Oct 2003 14:55:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AAwDs-0001Nu-QA
	for avt@optimus.ietf.org; Sat, 18 Oct 2003 14:54:44 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05649
	for <avt@ietf.org>; Sat, 18 Oct 2003 14:54:33 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AAwDp-0004gx-00
	for avt@ietf.org; Sat, 18 Oct 2003 14:54:41 -0400
Received: from rrcs-midsouth-24-199-215-41.biz.rr.com
	([24.199.215.41] helo=paris.packetizer.org ident=system)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AAwDp-0004gu-00
	for avt@ietf.org; Sat, 18 Oct 2003 14:54:41 -0400
Received: from PAULEJW2K1 (geneva.packetizer.org [192.168.1.2])
	by paris.packetizer.org (8.12.5/8.12.5) with SMTP id h9IHsdBQ014467;
	Sat, 18 Oct 2003 13:54:40 -0400
Message-ID: <006c01c395a9$22c1e550$e1cc6a9c@cisco.com>
From: "Paul E. Jones" <paulej@packetizer.com>
To: "Colin Perkins" <csp@csperkins.org>
Cc: <avt@ietf.org>
References: <4B52E71D-F33F-11D7-8BFC-000A957FC5F2@csperkins.org>
Subject: Re: [AVT] Submitted draft-hellstrom-avt-rfc2793bis-01.txt
Date: Sat, 18 Oct 2003 14:53:34 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Content-Transfer-Encoding: 7bit
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Colin,

> The T140block counter is presumably used to determine if a T.140 packet
> has been lost when a single RTP session switches between text and
> speech (so, for example, one can tell if a lost packet is the last
> packet of speech or the first packet of text). The rationale is not
> clearly explained in Section 3.2.

The text in that section states, "This counter may be utilized to detect
lost characters."  Is there alternative text that you'd like to see here?

> There seem to be cases where the T140block counter can fail to detect a
> lost packet. For example, consider the scenario where the last packet
> of text and first packet of speech are lost, during the transition. In
> this case the RTP sequence number will tell you that two packets were
> lost, but there doesn't seem to be a way to tell if they were text or
> speech. Is this an issue?

No, this should not be an issue.  In fact, this is precisely why the
T140block counter is proposed to be added at the start of the payload.  This
way, the receiving end can detect whether a text packet is lost or not.  We
have a requirement from the deaf community to include a back tick (`)
character whenever one or more characters are lost.  We were told that it
does not matter how many characters were lost (i.e., they do not want a
string of back tick characters) or whether audio was lost: they just need an
indicator to know that some textual information was lost.

> Section 3.5 would benefit from more discussion of the difference
> between a single RTP session that can switch between speech and text
> (which has no special synchronisation requirements), and multiple
> simultaneous RTP sessions, some text and some other media types, which
> need to be synchronised. There is a fundamental difference between the
> audio/t140 format - which treats text as a low-rate audio codec - and
> the text/140 format which treats text as a separate media, and this is
> not well brought out in the draft.

This should be done solely based on the RTP timestamps, I believe.  I will
add some text accordingly that will appear in the next draft.

> In Section 3.8, it is important to clarify that each packet will have a
> unique timestamp, but that this is not sufficient to identify packets
> because text packets have no fixed time duration. The current text
> could be interpreted to imply that packets have non-unique timestamps.

I do not follow you completely here.  How is is that one could assume that
the timestamps may be replicated?  Can you point to specific text that
exists or is missing?  (Hard to point to the latter, but perhaps you could
propose some.)

> I would recommend that the "text/red" MIME type registration be split
> into a separate draft, since logically separate from transport of T.140.

I can certainly do that.  If we put nothing more into this other draft, then
it would be a very short document.  Is there particular content that you'd
also like to see go along with this registration, other than appropriate
references to the work in RFC 2198?

Paul


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



From exim@www1.ietf.org  Sat Oct 18 15:46:28 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07801
	for <avt-archive@odin.ietf.org>; Sat, 18 Oct 2003 15:46:28 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AAx1b-00065b-Mc
	for avt-archive@odin.ietf.org; Sat, 18 Oct 2003 15:46:08 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9IJk71x023403
	for avt-archive@odin.ietf.org; Sat, 18 Oct 2003 15:46:07 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AAx1V-00064F-QA; Sat, 18 Oct 2003 15:46:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AAx0s-0005qA-Mx
	for avt@optimus.ietf.org; Sat, 18 Oct 2003 15:45:23 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07751
	for <avt@ietf.org>; Sat, 18 Oct 2003 15:45:13 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AAx0r-0005U8-00
	for avt@ietf.org; Sat, 18 Oct 2003 15:45:21 -0400
Received: from rrcs-midsouth-24-199-215-41.biz.rr.com
	([24.199.215.41] helo=paris.packetizer.org ident=system)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AAx0q-0005U3-00
	for avt@ietf.org; Sat, 18 Oct 2003 15:45:20 -0400
Received: from PAULEJW2K1 (geneva.packetizer.org [192.168.1.2])
	by paris.packetizer.org (8.12.5/8.12.5) with SMTP id h9IIjDBQ014669;
	Sat, 18 Oct 2003 14:45:14 -0400
Message-ID: <00a301c395b0$332855d0$e1cc6a9c@cisco.com>
From: "Paul E. Jones" <paulej@packetizer.com>
To: "Magnus Westerlund" <magnus.westerlund@ericsson.com>,
        "IETF AVT WG" <avt@ietf.org>,
        "Gunnar Hellstrom" <gunnar.hellstrom@omnitor.se>
References: <3F744C80.3040109@ericsson.com>
Date: Sat, 18 Oct 2003 15:44:08 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Content-Transfer-Encoding: 7bit
Subject: [AVT] Re: Comments on draft-hellstrom-avt-rfc2793bis-01.txt
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Magnus,

> 1. I think the draft introduction should be much clearer about that this
> draft updates and extends RFC 2793. I think the reason for the update
> should be made much more evident. The reasons are also very important so
> that the requirements can be understood.

OK.. I'll add some text here for the next draft.  How does this sound:
``This document updates and extends RFC 2793.  The text is intended to try
to clarify any ambiguities in RFC 2793, improve on the specific
implementation requirements learned through development experience, and to
introduce a means of transporting text interleaved with voice within the
same RTP session.''

> Based on the chair author discussion my understanding of the purpose is
> to enable the extraction of T.140 in a Voice gateway and distribute it
> correctly over an IP network. That means that there are certain
> considerations regarding the how to multiplex voice and text or possible
> another media.

Colin pointed out the same.  I've modified section 3.5 to try to address
this.  Please look for changes in the next draft.

> There where also expressed an requirement to be backwards compatible
> towards the format in RFC 2793.
>
> The authors has in this version tried to meet the requirements by
> specifying basically a new format with the MIME type audio/t140 which
> has its own text block sequence number allowing the RTP sequence number
> space to be non continuos in regards to the text transport. However
> there has not been any big consideration on what this may do on the
> audio codec sharing the SSRC with the text transport.

There are syncronization issues, as mentioned.  For example, when the
ingress side transmits text at 300bps and the egress side can only produce
text at 45.45bps, we have a problem.  I've tried to address this in my
working copy.

> This scenario also needs to be made much clearer if that is what should
> be used.
>
> There exist alternatives to this solution that I think may not be
> sufficiently worked through.
> - RTP session multiplexing
> - SSRC multiplexing
>
> I would encourage some discussion on this topic.

We actually did have some discussion on this, though I can't recall if it
was on the list or not.  Esentially, the word "multiplexing" seems to be a
bad word.  Every form of multiplexing proposed... and we had several... was
generally rejected for one reason or another.  I actually did have text that
proposed the use of two SSRCs, but has long since been removed.

So far, the only acceptable solution has been to interleave audio and text
in the transmitted stream.  This is what we've tried to capture in this
draft.

> 2. Section 3.5: I think this section should much clearer about the
> potential usage of RTCP for inter media synchronization.

What would you suggest?  There is an explicit reference to that section of
RFC 3550.  Would you like to remove the reference and state it quite
explicitly here?  (Sometimes, referring to the text that describes the
mechanism is better than try to re-explain the same. That was the approach
taken here.)

> 3. Section 4.2: I think one should consider the application of targeted
> FEC when one uses RTCP for explicit packet loss notification with NACKs.

Please explain what you have in mind here.  We didn't mention FEC in the
draft at all, as the use of FEC is something "one level higher" than this
draft.

> 4. Section 4.4, last paragraph: "Redundancy for the last T140block
> SHOULD NOT be implemented by repeatedly transmitting the same packet
> (with the same sequence number) because this will cause the packet loss
> count, as reported in RTCP, to decrement." I would like to see this
> being even stronger.

You want a MUST NOT?  I have no objection to that, if that's what you want.

> 5. Section 5: I don't think "flow control" is the appropriate words
> here. At least in my ears flow control is something dynamic instead of a
> simple session duration limitation on maximum character rate.

You might be right.  It's certainly static.  How about "SDP Attribute for
Character Transmission Rate" with appropriate changes to the text within?

> 6. Section 7: Please provide a pointer to RFC 3550 security
> consideration. Secondly I think that authentication should actually be
> even more important then confidentiality through encryption.

Done.

> 7. There is need for a RFC-editors consideration section pointing out
> that there are some places where the RFC number needs to be inserted.
> The common practice is to use RFC XXXX, YYYY, etc. To give mappings
> between future number and the draft(s).

Done.

> 8. Section 8.1, 8.2: Change controller: I don't see a need for having
> any C/O for the IETF AVT WG. If something needs to be addressed this is
> probably in the hands of the chair currently sitting then.

Removed as requested.

> 9. Section 8.3: I understand the need for registering the MIME type for
> RED also for text. However the introduction and abstract should motivate
> why this is necessary.

It has been requested that we move this to a separate I-D.  We'll remove it
from here and then put that motivation in the separate I-D.

> 10. End of draft: Missing IPR statement.

Added.

> 11. If you are giving copyright of your individual submission to the
> IETF through the large statement, I think you can include the short
> statement on the first page.

What do you mean, exactly?  This was taken from RFC 2198, I believe,
unchanged.  Can you point me to an example with something that is an
alternative to this?

Paul


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



From exim@www1.ietf.org  Sun Oct 19 07:50:32 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06116
	for <avt-archive@odin.ietf.org>; Sun, 19 Oct 2003 07:50:32 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABC4Y-0005sO-Fz
	for avt-archive@odin.ietf.org; Sun, 19 Oct 2003 07:50:11 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9JBoAuN022587
	for avt-archive@odin.ietf.org; Sun, 19 Oct 2003 07:50:10 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABC4P-0005pH-47; Sun, 19 Oct 2003 07:50:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABC3r-0005jj-HU
	for avt@optimus.ietf.org; Sun, 19 Oct 2003 07:49:27 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06084
	for <avt@ietf.org>; Sun, 19 Oct 2003 07:49:18 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABC3n-0004ir-00
	for avt@ietf.org; Sun, 19 Oct 2003 07:49:23 -0400
Received: from smtp3.vsnl.net ([203.200.235.233])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABC3n-0004ii-00
	for avt@ietf.org; Sun, 19 Oct 2003 07:49:23 -0400
Received: from happy ([172.16.28.233])
 by smtp3.vsnl.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14
 2003)) with SMTP id <0HN0009N664TTN@smtp3.vsnl.net> for avt@ietf.org; Sun,
 19 Oct 2003 17:18:45 +0530 (IST)
Received: from ([219.65.46.227])
 by smtp3.vsnl.net	(InterScan E-Mail VirusWall Unix); Sun,
 19 Oct 2003 17:18:45 +0530 (IST)
Date: Sun, 19 Oct 2003 17:15:48 +0530
From: Deepak Kotian <dkotian3@vsnl.net>
To: avt@ietf.org
Reply-to: Deepak Kotian <dkotian3@vsnl.net>
Message-id: <003301c39636$c5522040$e32e41db@vsnl.net>
Organization: pcs
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
Content-type: multipart/alternative;
 boundary="Boundary_(ID_KPZolCWjI/P0HU8Z5/X7zw)"
X-Priority: 3
X-MSMail-priority: Normal
Subject: [AVT] ipv6 multicast problem on Linux kernel 2.4.18-3 while doing a sendto
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

--Boundary_(ID_KPZolCWjI/P0HU8Z5/X7zw)
Content-type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7BIT

Hi,    

We  are currently facing a problem when
we try mutlicast IP FF12::224.5.6.7 on Linux.
The function inet_pton() returns > 0, that means the IP is OK, but
when we do a sendto(), it gives an error, EADDRINVAL.

The kernel used is 2.4.18-3 and ipv6 is enable. 
Can one please let me know, how to make this multicast IPV6
sendto() functionality work properly. 

I think, this is not the right forum, but if some has worked on it,
can one please share his experience on it.
Or does anyone know the right forum for this query.

         
Thanks and Regards
Deepak


--Boundary_(ID_KPZolCWjI/P0HU8Z5/X7zw)
Content-type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 5.50.4522.1801" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>Hi,&nbsp;&nbsp;&nbsp; </FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>We&nbsp; are currently facing a problem 
when</FONT></DIV>
<DIV><FONT face=Arial size=2>we try mutlicast IP FF12::224.5.6.7 on 
Linux.</FONT></DIV>
<DIV><FONT face=Arial size=2>The&nbsp;function inet_pton() returns &gt; 0, that 
means the IP is OK, but</FONT></DIV>
<DIV><FONT face=Arial size=2>when we do a sendto(), it gives an error, 
EADDRINVAL.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>The kernel used is 2.4.18-3 and ipv6 is enable. 
</FONT></DIV>
<DIV><FONT face=Arial size=2>Can one please let me know, how to make this 
multicast IPV6</FONT></DIV>
<DIV><FONT face=Arial size=2>sendto() functionality work properly. </FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>I think, this is not the right forum, but if some 
has worked on it,</FONT></DIV>
<DIV><FONT face=Arial size=2>can one please share his experience on 
it.</FONT></DIV>
<DIV><FONT face=Arial size=2>Or does anyone know the right forum for this 
query.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial 
size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT><FONT 
face=Arial size=2></FONT></DIV>
<DIV><FONT face=Arial size=2>Thanks and Regards</FONT></DIV>
<DIV><FONT face=Arial size=2>Deepak</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV></BODY></HTML>

--Boundary_(ID_KPZolCWjI/P0HU8Z5/X7zw)--

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



From exim@www1.ietf.org  Mon Oct 20 03:50:40 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16463
	for <avt-archive@odin.ietf.org>; Mon, 20 Oct 2003 03:50:40 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABUny-00085H-Tf
	for avt-archive@odin.ietf.org; Mon, 20 Oct 2003 03:50:19 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9K7oIgp031076
	for avt-archive@odin.ietf.org; Mon, 20 Oct 2003 03:50:18 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABUni-00081s-8V; Mon, 20 Oct 2003 03:50:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABUmu-0007pP-0g
	for avt@optimus.ietf.org; Mon, 20 Oct 2003 03:49:12 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16404
	for <avt@ietf.org>; Mon, 20 Oct 2003 03:49:03 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABUmr-0005Jc-00
	for avt@ietf.org; Mon, 20 Oct 2003 03:49:09 -0400
Received: from eagle.ericsson.se ([193.180.251.53])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABUmq-0005JY-00
	for avt@ietf.org; Mon, 20 Oct 2003 03:49:08 -0400
Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120])
	by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9K7n0oq021820;
	Mon, 20 Oct 2003 09:49:05 +0200
Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55)
	id 45JRT85D; Mon, 20 Oct 2003 09:49:49 +0200
Message-ID: <3F939364.6070106@ericsson.com>
Date: Mon, 20 Oct 2003 09:48:52 +0200
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jean-Francois Mule <jf.mule@cablelabs.com>
CC: avt@ietf.org
Subject: Re: [AVT] Any thoughts on documenting RTP/RTCP port usage?
References: <AEE1FD45F580334296FDA24A1167FFA5028481@srvxchg.cablelabs.com>
In-Reply-To: <AEE1FD45F580334296FDA24A1167FFA5028481@srvxchg.cablelabs.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable

Hi Jean-Francois,

I can't recall any such debate during the almost 4 years that I have=20
been active in the AVT. However I do understand the reason for not=20
having that debate. As RTP is currently used in SIP and RTSP, MBONE,=20
i.e. per session dynamic assignment of ports, there has been little=20
reason. Thus any RTP application usually needs at least a range to be use=
d.

I know that certain ranges declared for example in the Real Networks=20
player has become almost defacto standard within the streaming=20
community. However this is for one certain application. I don't know if=20
the SIP clients out there uses any special range.

I think that the definition of port ranges will only restrict the=20
applications and does not provide any real security. For example by=20
defining a port range for a certain application it will force any new=20
application into the same ranges, otherwise there will be FW traversal=20
problems. From a security stand point the FW can't accept any IP/UDP/RTP =

traffic simply because it is within the range, it will need to check=20
this against the application level requests for traffic. If the FW=20
anyway are doing the checking or clients are using a MIDCOM protocol the =

FW can open any ports and there are no need for ranges.

Due to the above reasons I think it is a bad idea. I guess that others=20
have their own view on this.

Cheers

Magnus

Jean-Francois Mule wrote:

> I'm curious to know whether there has been some discussion on documenti=
ng the RTP/RTCP port use in the real world today. Many applications use R=
TP&RTCP and random UDP ports outside the IANA registry. Some RTP entries =
exist in the IANA registry today (see below), but most commonly used RTP =
applications don't have an entry.
>=20
> Some operators may want to be able to establish strict firewall rules o=
n UDP traffic. This is where some kind of registry for RTP traffic could =
help, especially since there are some streaming applications that consist=
ently use the same not-that-well-known ports.
>=20
> Any thoughts on this? Has an RTP port registry been considered? Is this=
 a bad idea?
> Thanks in advance,
> Jean-Fran=E7ois=20
> ---
> paging-port     3771/tdp   RTP Paging Port
> paging-port     3771/udp   RTP Paging Port
> #                          Patrick Ferriter <Patrick.Ferriter@zultys.co=
m> June 2003
>=20
> espeech-rtp     8417/tcp    eSpeech RTP Protocol
> espeech-rtp     8417/udp    eSpeech RTP Protocol
> #                           Scott Tarone <starone@proactivethought.com>=
 April 2003
>=20
>=20
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www1.ietf.org/mailman/listinfo/avt
>=20

--=20

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 exim@www1.ietf.org  Mon Oct 20 12:15:32 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02306
	for <avt-archive@odin.ietf.org>; Mon, 20 Oct 2003 12:15:32 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABcga-0003Dx-0G
	for avt-archive@odin.ietf.org; Mon, 20 Oct 2003 12:15:12 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KGFB3Y012389
	for avt-archive@odin.ietf.org; Mon, 20 Oct 2003 12:15:11 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABcgR-00039c-Pp; Mon, 20 Oct 2003 12:15:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABcg1-00034X-OH
	for avt@optimus.ietf.org; Mon, 20 Oct 2003 12:14:37 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02241;
	Mon, 20 Oct 2003 12:14:27 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABcg0-0001t3-00; Mon, 20 Oct 2003 12:14:36 -0400
Received: from smtp3.vsnl.net ([203.200.235.233])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABcfz-0001sp-00; Mon, 20 Oct 2003 12:14:36 -0400
Received: from happy ([172.16.28.233])
 by smtp3.vsnl.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14
 2003)) with SMTP id <0HN200AK7D2Y2D@smtp3.vsnl.net>; Mon,
 20 Oct 2003 21:43:50 +0530 (IST)
Received: from ([219.65.46.127])
 by smtp3.vsnl.net	(InterScan E-Mail VirusWall Unix); Mon,
 20 Oct 2003 21:43:50 +0530 (IST)
Date: Mon, 20 Oct 2003 21:42:42 +0530
From: Deepak Kotian <dkotian3@vsnl.net>
To: avt@ietf.org, IETF MMUSIC WG <mmusic@ietf.org>
Reply-to: Deepak Kotian <dkotian3@vsnl.net>
Message-id: <001601c39724$fe228d80$7f2e41db@vsnl.net>
Organization: pcs
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
Content-type: multipart/alternative;
 boundary="Boundary_(ID_FKut3SW8i0b9+1uwDNuT9Q)"
X-Priority: 3
X-MSMail-priority: Normal
Subject: [AVT] Re: ipv6 multicast problem on Linux kernel 2.4.18-3 while doing a
 sendto
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

--Boundary_(ID_FKut3SW8i0b9+1uwDNuT9Q)
Content-type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7BIT

Hi,

Also an additional information.
F001:0:0:0:0:0:0:43 MULTICast address works
fine with sendto, but FF12::224.5.6.7 does not
work.
Also, the errno is 99 , the errno menitioned in the 
earlier mail was not OK.

Any inputs from anyone on this now.

Thanks and Regards
Deepak

  ----- Original Message ----- 
  From: Deepak Kotian 
  To: avt@ietf.org 
  Sent: Sunday, October 19, 2003 5:15 PM
  Subject: ipv6 multicast problem on Linux kernel 2.4.18-3 while doing a sendto 


  Hi,    

  We  are currently facing a problem when
  we try mutlicast IP FF12::224.5.6.7 on Linux.
  The function inet_pton() returns > 0, that means the IP is OK, but
  when we do a sendto(), it gives an error, EADDRINVAL.

  The kernel used is 2.4.18-3 and ipv6 is enable. 
  Can one please let me know, how to make this multicast IPV6
  sendto() functionality work properly. 

  I think, this is not the right forum, but if some has worked on it,
  can one please share his experience on it.
  Or does anyone know the right forum for this query.

           
  Thanks and Regards
  Deepak


--Boundary_(ID_FKut3SW8i0b9+1uwDNuT9Q)
Content-type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 5.50.4522.1801" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>Hi,</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>Also an additional information.</FONT></DIV>
<DIV><FONT face=Arial size=2>F001:0:0:0:0:0:0:43 MULTICast address 
works</FONT></DIV>
<DIV><FONT face=Arial size=2>fine with sendto, but FF12::224.5.6.7 does 
not</FONT></DIV>
<DIV><FONT face=Arial size=2>work.</FONT></DIV>
<DIV><FONT face=Arial size=2>Also, the errno is 99 , the errno menitioned in the 
</FONT></DIV>
<DIV><FONT face=Arial size=2>earlier mail was not OK.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>Any inputs from anyone on this now.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>Thanks and Regards</FONT></DIV>
<DIV><FONT face=Arial size=2>Deepak</FONT></DIV>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV 
  style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B> 
  <A title=dkotian3@vsnl.net href="mailto:dkotian3@vsnl.net">Deepak Kotian</A> 
  </DIV>
  <DIV style="FONT: 10pt arial"><B>To:</B> <A title=avt@ietf.org 
  href="mailto:avt@ietf.org">avt@ietf.org</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>Sent:</B> Sunday, October 19, 2003 5:15 
  PM</DIV>
  <DIV style="FONT: 10pt arial"><B>Subject:</B> ipv6 multicast problem on Linux 
  kernel 2.4.18-3 while doing a sendto </DIV>
  <DIV><BR></DIV>
  <DIV><FONT face=Arial size=2>Hi,&nbsp;&nbsp;&nbsp; </FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>We&nbsp; are currently facing a problem 
  when</FONT></DIV>
  <DIV><FONT face=Arial size=2>we try mutlicast IP FF12::224.5.6.7 on 
  Linux.</FONT></DIV>
  <DIV><FONT face=Arial size=2>The&nbsp;function inet_pton() returns &gt; 0, 
  that means the IP is OK, but</FONT></DIV>
  <DIV><FONT face=Arial size=2>when we do a sendto(), it gives an error, 
  EADDRINVAL.</FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>The kernel used is 2.4.18-3 and ipv6 is enable. 
  </FONT></DIV>
  <DIV><FONT face=Arial size=2>Can one please let me know, how to make this 
  multicast IPV6</FONT></DIV>
  <DIV><FONT face=Arial size=2>sendto() functionality work properly. 
  </FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>I think, this is not the right forum, but if some 
  has worked on it,</FONT></DIV>
  <DIV><FONT face=Arial size=2>can one please share his experience on 
  it.</FONT></DIV>
  <DIV><FONT face=Arial size=2>Or does anyone know the right forum for this 
  query.</FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial 
  size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT><FONT 
  face=Arial size=2></FONT></DIV>
  <DIV><FONT face=Arial size=2>Thanks and Regards</FONT></DIV>
  <DIV><FONT face=Arial size=2>Deepak</FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML>

--Boundary_(ID_FKut3SW8i0b9+1uwDNuT9Q)--

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



From exim@www1.ietf.org  Mon Oct 20 15:40:34 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20430
	for <avt-archive@odin.ietf.org>; Mon, 20 Oct 2003 15:40:34 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABfsy-0008P8-KN
	for avt-archive@odin.ietf.org; Mon, 20 Oct 2003 15:40:12 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KJeBkw032261
	for avt-archive@odin.ietf.org; Mon, 20 Oct 2003 15:40:11 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABfsp-0008KO-9n; Mon, 20 Oct 2003 15:40:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABfsa-0008HF-OI
	for avt@optimus.ietf.org; Mon, 20 Oct 2003 15:39: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 PAA20075;
	Mon, 20 Oct 2003 15:39:39 -0400 (EDT)
Message-Id: <200310201939.PAA20075@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: avt@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Mon, 20 Oct 2003 15:39:38 -0400
Subject: [AVT] I-D ACTION:draft-ietf-avt-dsr-es202050-01.txt
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Audio/Video Transport Working Group of the IETF.

	Title		: RTP Payload Format for European Telecommunications 
			  Standards Institute (ETSI) European Standard ES 202 
			  050 Distributed  Speech Recognition Encoding
	Author(s)	: Q. Xie, D. Pearce
	Filename	: draft-ietf-avt-dsr-es202050-01.txt
	Pages		: 11
	Date		: 2003-10-20
	
This document specifies an RTP payload format for encapsulating ETSI
Standard ES 202 050 advanced front-end signal processing feature
streams for distributed speech recognition (DSR) systems.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-dsr-es202050-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-avt-dsr-es202050-01.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-dsr-es202050-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-10-20144402.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-avt-dsr-es202050-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-avt-dsr-es202050-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-10-20144402.I-D@ietf.org>

--OtherAccess--

--NextPart--



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



From exim@www1.ietf.org  Mon Oct 20 17:16:30 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05754
	for <avt-archive@odin.ietf.org>; Mon, 20 Oct 2003 17:16:30 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABhNq-0007OD-BN
	for avt-archive@odin.ietf.org; Mon, 20 Oct 2003 17:16:10 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KLGAWd028362
	for avt-archive@odin.ietf.org; Mon, 20 Oct 2003 17:16:10 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABhNi-0007LJ-5a; Mon, 20 Oct 2003 17:16:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABhNE-0007Ft-5r
	for avt@optimus.ietf.org; Mon, 20 Oct 2003 17:15:32 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05714
	for <avt@ietf.org>; Mon, 20 Oct 2003 17:15:21 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABhNB-0000lb-00
	for avt@ietf.org; Mon, 20 Oct 2003 17:15:29 -0400
Received: from ribbit.cs.berkeley.edu ([128.32.112.203])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABhNB-0000lY-00
	for avt@ietf.org; Mon, 20 Oct 2003 17:15:29 -0400
Received: from ribbit.CS.Berkeley.EDU (localhost [127.0.0.1])
	by ribbit.CS.Berkeley.EDU (3.14/2.71/) with ESMTP id h9KLFTTA024738
	for <avt@ietf.org>; Mon, 20 Oct 2003 14:15:29 -0700 (PDT)
Received: (from lazzaro@localhost)
	by ribbit.CS.Berkeley.EDU (3.14/3.14/Submit) id h9KLFSR2024737
	for avt@ietf.org; Mon, 20 Oct 2003 14:15:28 -0700 (PDT)
Date: Mon, 20 Oct 2003 14:15:28 -0700 (PDT)
From: John Lazzaro <lazzaro@CS.Berkeley.EDU>
Message-Id: <200310202115.h9KLFSR2024737@ribbit.CS.Berkeley.EDU>
To: avt@ietf.org
Subject: [AVT] RTP MIDI status report
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>


Hi everyone,

	Sent off the updated versions of the RTP MIDI payload 
format document (draft-ietf-avt-rtp-midi-format-00.txt) and
implementation guide (draft-ietf-avt-rtp-midi-guidelines-00.txt)
to internet-drafts@ietf.org yesterday.  Pick up copies here:

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

	As you may recall, the plan I posted pre-Vienna called
for a complete implementation of the payload format in sfront,
with protocol bugfixes rolled into the -00.txt documents to 
produce candidate Last Call drafts.

	We're about 70% of the way to that goal -- all of
the I-D main body, practically all of Appendix A, and much
of Appendix C has been implemented in sfront and tested, and
the -00.txt I-Ds reflect protocol bugfixes from that effort.
See the draft-ietf-avt-rtp-midi-format-00.txt Change Log for
details.

	The new goal is to complete sfront coding and send off
the -01.txt Last Call candidates to internet-drafts@ietf.org
before UCB shuts down for the holidays, and do the actual -02.txt
Last Call submission before the UCB spring semester starts. 

-------------------------------------------------------------------------
John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
lazzaro [at] cs [dot] berkeley [dot] edu     www.cs.berkeley.edu/~lazzaro
-------------------------------------------------------------------------

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



From exim@www1.ietf.org  Mon Oct 20 23:33:32 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20733
	for <avt-archive@odin.ietf.org>; Mon, 20 Oct 2003 23:33:32 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABnGh-0002rW-Dt
	for avt-archive@odin.ietf.org; Mon, 20 Oct 2003 23:33:11 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9L3XB98010961
	for avt-archive@odin.ietf.org; Mon, 20 Oct 2003 23:33:11 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABnGX-0002lv-AS; Mon, 20 Oct 2003 23:33:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABnFt-0002cF-8v
	for avt@optimus.ietf.org; Mon, 20 Oct 2003 23:32:21 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20711
	for <avt@ietf.org>; Mon, 20 Oct 2003 23:32:11 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABnFr-0006IW-00
	for avt@ietf.org; Mon, 20 Oct 2003 23:32:19 -0400
Received: from ribbit.cs.berkeley.edu ([128.32.112.203])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABnFq-0006IS-00
	for avt@ietf.org; Mon, 20 Oct 2003 23:32:18 -0400
Received: from ribbit.CS.Berkeley.EDU (localhost [127.0.0.1])
	by ribbit.CS.Berkeley.EDU (3.14/2.71/) with ESMTP id h9L3WHTA026163
	for <avt@ietf.org>; Mon, 20 Oct 2003 20:32:17 -0700 (PDT)
Received: (from lazzaro@localhost)
	by ribbit.CS.Berkeley.EDU (3.14/3.14/Submit) id h9L3WHBM026162
	for avt@ietf.org; Mon, 20 Oct 2003 20:32:17 -0700 (PDT)
Date: Mon, 20 Oct 2003 20:32:17 -0700 (PDT)
From: John Lazzaro <lazzaro@CS.Berkeley.EDU>
Message-Id: <200310210332.h9L3WHBM026162@ribbit.CS.Berkeley.EDU>
To: avt@ietf.org
Subject: [AVT] TCP framing update
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>


Hi everyone,

	Just submitted an updated version of the TCP framing
I-D (draft-lazzaro-avt-rtp-framing-contrans-02.txt) to
internet-drafts@ietf.org, you can pick it up at:

http://www.cs.berkeley.edu/~lazzaro/sa/pubs/txt/current-contrans.txt

	Only the name and date have been updated -- the memo had been
awaiting re-chartering, and was about to expire.  The re-chartering
text of interest is:

> - to provide a framing mechanism for RTP over TCP and TLS

	The draft-lazzaro-avt-rtp-framing-contrans-02.txt draft is
driven from two requirements, which were culled from earlier
discussions on avt@ietf.org, and from the discussion in San
Francisco in the spring:

  -1-  Compatibility with the TCP framing format in earlier
       versions of the RTP RFCs.

  -2-  Compatibility with draft-ietf-mmusic-sdp-comedia-05.txt

	It would be good to get feedback on whether the document falls
short on either requirement.

	My take on the San Francisco discussions is that there is a
need for a protocol that meets these requirements, to support existing
codebases.  Based on that assessment, I'd like to request WG Item
status for draft-lazzaro-avt-rtp-framing-contrans-02.txt.

	However, there was also sentiment in San Francisco that a
non-backward-compatible format, that supported multiplexing of
multiple RTP/RTCP pairs on a single socket with framing markers, would
be a complementary protocol to the legacy protocol.  So, making
draft-lazzaro-avt-rtp-framing-contrans-02.txt a WG Item wouldn't
preclude such a complementary protocol effort, I would think, if
someone (else, I'm overbooked) wanted to take on its design.

-------------------------------------------------------------------------
John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
lazzaro [at] cs [dot] berkeley [dot] edu     www.cs.berkeley.edu/~lazzaro
-------------------------------------------------------------------------

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



From exim@www1.ietf.org  Mon Oct 20 23:55:27 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21195
	for <avt-archive@odin.ietf.org>; Mon, 20 Oct 2003 23:55:27 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABnbu-0001uY-TV
	for avt-archive@odin.ietf.org; Mon, 20 Oct 2003 23:55:07 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9L3t6de007343
	for avt-archive@odin.ietf.org; Mon, 20 Oct 2003 23:55:06 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABnbs-0001sr-1Z; Mon, 20 Oct 2003 23:55:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABnbX-0001n8-6h
	for avt@optimus.ietf.org; Mon, 20 Oct 2003 23:54:43 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21145
	for <avt@ietf.org>; Mon, 20 Oct 2003 23:54:33 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABnbU-0006S1-00
	for avt@ietf.org; Mon, 20 Oct 2003 23:54:40 -0400
Received: from hyervision.com ([66.159.193.111] helo=server.hyervision.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABnbT-0006Rw-00
	for avt@ietf.org; Mon, 20 Oct 2003 23:54:39 -0400
Received: from WIND (hyervision.com [66.159.193.111])
	by server.hyervision.com (8.12.9/8.12.6) with ESMTP id h9L3h4RC004523
	for <avt@ietf.org>; Mon, 20 Oct 2003 20:43:04 -0700 (PDT)
From: "Adam Li" <adamli@icsl.ucla.edu>
To: <avt@ietf.org>
Date: Mon, 20 Oct 2003 20:53:43 -0700
Organization: UCLA
Message-ID: <000101c39786$ef032b40$6c7ba8c0@divxnetworks.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2616
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Content-Transfer-Encoding: quoted-printable
Subject: [AVT] FEC draft
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable

Hi folks,

We would like to discuss the following changes to the FEC draft with
you, and would like to hear your comments.

As decided in previous meetings and discussions, we are in the process
of updating and incorporating the ULP FEC draft with the generic FEC. At
the same time, taking this chance, we would also like to modify a few
issues with RFC 2733. In RFC 2733, the M, P, X, and CC bits in the RTP
header of the FEC packets are calculated from the parity operation, thus
those fields do not confirm to their normal definition as in RFC 1889.

The proposed change to fix this issue is to move the parity data of the
M, P, X, and CC bits into the FEC header part of the FEC packet from the
RTP header, so the corresponding fields in the RTP header can retain
their original meaning.

One of the potential solutions is as below. (E =3D extension, R =3D
reserved)

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |      SN base                  |        length recovery        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |M| PT recovery |P|X|  CC   |E|R|             mask              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                          TS recovery                          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

With the addition of M, P, X, and CC bits in the FEC header, one extra
octet is taken. This reduces the mask from 24 to 16 bits. This might
still be enough, as the typical interleaving is something like 10
packets. =20

One other potential solution is pretty much as above, but keeping the
mask at 24 bits as it is in RFC 2733. However, by doing that, the FEC
header above will not align on a 32 bit boundary, which might be a good
property to keep.

So the question we would like to hear your comment is: Shall we (a)
reduce the mask to 16-bit, or (b) keep the mask at 24-bit, and break the
32-bit alignment?

Your help is very much appreciated.

Adam




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



From exim@www1.ietf.org  Tue Oct 21 07:55:39 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14464
	for <avt-archive@odin.ietf.org>; Tue, 21 Oct 2003 07:55:39 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABv6b-00044A-5X
	for avt-archive@odin.ietf.org; Tue, 21 Oct 2003 07:55:18 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LBtH7X015626
	for avt-archive@odin.ietf.org; Tue, 21 Oct 2003 07:55:17 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABv6L-00040P-Ps; Tue, 21 Oct 2003 07:55:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABv61-0003sV-5S
	for avt@optimus.ietf.org; Tue, 21 Oct 2003 07:54:41 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14444
	for <avt@ietf.org>; Tue, 21 Oct 2003 07:54:31 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABv60-0002gj-00
	for avt@ietf.org; Tue, 21 Oct 2003 07:54:40 -0400
Received: from mail.pel.panasonic.de ([194.162.191.12])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABv5z-0002ga-00
	for avt@ietf.org; Tue, 21 Oct 2003 07:54:40 -0400
Received: from mcomreyj ([10.10.100.5]) by mail.pel.panasonic.de with Microsoft SMTPSVC(5.0.2195.6713);
	 Tue, 21 Oct 2003 13:54:32 +0200
Reply-To: <rey@panasonic.de>
From: =?US-ASCII?Q?Jose_Rey?= <rey@panasonic.de>
To: <avt@ietf.org>
Cc: "'Colin Perkins'" <csp@csperkins.org>,
        "'Magnus Westerlund'" <magnus.westerlund@ericsson.com>
Subject: RE: [AVT] Retransmission draft
Date: Tue, 21 Oct 2003 13:54:29 +0200
Message-ID: <010901c397ca$16ebb580$05640a0a@panasonic.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200
Importance: Normal
In-Reply-To: <3F6F0BFF.8020609@ericsson.com>
X-OriginalArrivalTime: 21 Oct 2003 11:54:32.0325 (UTC) FILETIME=[1719A350:01C397CA]
Content-Transfer-Encoding: 7bit
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit



hi all,

please be informed that the IPR statement regarding the
draft-ietf-avt-rtp-retransmission-09.txt is now available at the IETF IPR
webpage. We are sorry for the delay. We cannot explain why it has taken so
long for the IETF IPR people to publish it. As a matter of fact the
statement was first sent already on July 24th, however not published until a
recent second submission.

In previous emails we have been asked to explain our patent application and
we
informed AVT that the patent application itself specifies a transport method
using the RTP protocol where two sequence numbers are used: one to specifiy
the transmission order (=RTP SN) and the other one defining the reprodution
order, which in the draft corresponds with the OSN (original sequence
number). We also stated that it is not possible to implement the protocol
without infringing on the patent.
So far we have not received any more questions on the patent, but are happy
to provide them in case needed.

On the issue of how to proceed with this RTP retransmission draft some
opinions have been provided by Magnus Westerlund, Lars-Erik Jonsson and
John Lazzaro. John Lazzaro (08.09.03) has suggested to publish it as
Informational if the patent rights are held while Magnus and
Lars-Erik have suggested to proceed with the document as a Proposed
Standard (as we understand from the emails on from 22.09.03 and 09.09.03).

Taking all the above into account and considering that
independent of the patent situation this work is intended to be included in
the next release of 3GPP, we would like to ask the group to proceed with the
draft on standards track.

cheers,

Jose





> -----Original Message-----
> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]
> Sent: Monday, September 22, 2003 4:50 PM
> To: Colin Perkins
> Cc: Jose Rey; avt@ietf.org
> Subject: Re: [AVT] Retransmission draft
>
>
> Hi,
>
> This mail is my personal comments, not as an WG chair!
>
> Colin Perkins wrote:
>
> > On Wednesday, Sep 3, 2003, at 09:15 Europe/London, Jose Rey wrote:
> > ...
> >
> >> Exactly, it is not possible to implement the
> >> payload format without infringing on the IPR.
> >
> >
> > A question to the working group: since it's not possible to
> implement
> > draft-ietf-avt-rtp-retransmission-09.txt without infringing
> a patent,
> > does it make sense for this to be published as a Proposed Standard?
> >
> > Given that there are FEC solutions that do not appear to be
> encumbered,
> > should we consider the retransmission draft for an Informational RFC
> > instead?
> >
>
> I think that it still makes sense to publish this a Proposed
> Standard.
> My arguments are:
>
> - First I think that it is important to make the solution of
> retransmission available in a standardized way. By publishing it as
> proposed standard the normative text is in force. The
> solution then is
> possible to implement in an interoperable way.
>
> - As the solution are not a core technology, however something that
> allows for more bandwidth optimized error recovery, it can be used by
> applications where one can license the rights for the benefit.
>
> - The method is commonly used and if as indicated there is no
> way around
> the patent, and it is valid then having a proposed standard
> for it and
> using it, or not having a proposed standard and still using it, the
> proposed standard way will have less problem.
>
>
> These are my arguments why it should be published as a proposed
> standard. However I would hope that Jose can provide some
> more details
> about the patent so that everyone can judge it validity. Also
> the patent
> statement is still not available on the IETF page.
>
> If Matsushita would provide a more specified statement making this
> license free or at least some better statement I also think
> there would
> be less problem to go ahead.
>
>
> Best 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 exim@www1.ietf.org  Tue Oct 21 12:59:38 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26425
	for <avt-archive@odin.ietf.org>; Tue, 21 Oct 2003 12:59:38 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABzqq-0001td-2i
	for avt-archive@odin.ietf.org; Tue, 21 Oct 2003 12:59:20 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LGxJGo007246
	for avt-archive@odin.ietf.org; Tue, 21 Oct 2003 12:59:19 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABzqX-0001lO-Ko; Tue, 21 Oct 2003 12:59:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABzpi-0001Oa-LY
	for avt@optimus.ietf.org; Tue, 21 Oct 2003 12:58:10 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26385
	for <avt@ietf.org>; Tue, 21 Oct 2003 12:57:58 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABzpg-000617-00
	for avt@ietf.org; Tue, 21 Oct 2003 12:58:08 -0400
Received: from dundee.dcs.gla.ac.uk ([130.209.242.163])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABzpg-00060V-00
	for avt@ietf.org; Tue, 21 Oct 2003 12:58:08 -0400
Received: from bisa ([130.209.247.104]:55866 helo=csperkins.org)
	by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.04)
	id 1ABzpA-0004ix-00; Tue, 21 Oct 2003 17:57:37 +0100
Date: Tue, 21 Oct 2003 17:57:32 +0100
Subject: Re: [AVT] Retransmission draft
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: <avt@ietf.org>, "'Magnus Westerlund'" <magnus.westerlund@ericsson.com>
To: <rey@panasonic.de>
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <010901c397ca$16ebb580$05640a0a@panasonic.de>
Message-Id: <A9950C3F-03E7-11D8-BDC0-000A957FC5F2@csperkins.org>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
Content-Transfer-Encoding: 7bit
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

On Tuesday, Oct 21, 2003, at 12:54 Europe/London, Jose Rey wrote:
...
> In previous emails we have been asked to explain our patent 
> application and
> we
> informed AVT that the patent application itself specifies a transport 
> method
> using the RTP protocol where two sequence numbers are used: one to 
> specifiy
> the transmission order (=RTP SN) and the other one defining the 
> reprodution
> order, which in the draft corresponds with the OSN (original sequence
> number). We also stated that it is not possible to implement the 
> protocol
> without infringing on the patent.
> So far we have not received any more questions on the patent, but are 
> happy
> to provide them in case needed.
>
> On the issue of how to proceed with this RTP retransmission draft some
> opinions have been provided by Magnus Westerlund, Lars-Erik Jonsson and
> John Lazzaro. John Lazzaro (08.09.03) has suggested to publish it as
> Informational if the patent rights are held while Magnus and
> Lars-Erik have suggested to proceed with the document as a Proposed
> Standard (as we understand from the emails on from 22.09.03 and 
> 09.09.03).
>
> Taking all the above into account and considering that
> independent of the patent situation this work is intended to be 
> included in
> the next release of 3GPP, we would like to ask the group to proceed 
> with the
> draft on standards track.
>
> cheers,
> Jose

[takes working group chair hat off]

3GPP is only one forum which uses IETF standards, and one where dealing 
with IPR issues is commonplace. Having patented standards is more of an 
issue for open source developers, who are often excluded by the 
licensing terms. Would Matsushita be willing to clarify if the 
"reasonable, nondiscriminatory" terms allow open source implementations 
to use the retransmission format (this will probably require a 
Royalty-Free license)?

[puts working group chair hat on again]

-- 
Colin Perkins
http://csperkins.org/


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



From exim@www1.ietf.org  Tue Oct 21 14:28:27 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29365
	for <avt-archive@odin.ietf.org>; Tue, 21 Oct 2003 14:28:27 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AC1Em-0001DF-87
	for avt-archive@odin.ietf.org; Tue, 21 Oct 2003 14:28:08 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LIS8F0004617
	for avt-archive@odin.ietf.org; Tue, 21 Oct 2003 14:28:08 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AC1Ee-0001A8-TP; Tue, 21 Oct 2003 14:28:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AC1EK-00015O-J4
	for avt@optimus.ietf.org; Tue, 21 Oct 2003 14:27:40 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29293
	for <avt@ietf.org>; Tue, 21 Oct 2003 14:27:29 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AC1EH-0007C9-00
	for avt@ietf.org; Tue, 21 Oct 2003 14:27:37 -0400
Received: from ribbit.cs.berkeley.edu ([128.32.112.203])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AC1EH-0007C6-00
	for avt@ietf.org; Tue, 21 Oct 2003 14:27:37 -0400
Received: from ribbit.CS.Berkeley.EDU (localhost [127.0.0.1])
	by ribbit.CS.Berkeley.EDU (3.14/2.71/) with ESMTP id h9LIRYTA028869
	for <avt@ietf.org>; Tue, 21 Oct 2003 11:27:34 -0700 (PDT)
Received: (from lazzaro@localhost)
	by ribbit.CS.Berkeley.EDU (3.14/3.14/Submit) id h9LIRYbt028868
	for avt@ietf.org; Tue, 21 Oct 2003 11:27:34 -0700 (PDT)
Date: Tue, 21 Oct 2003 11:27:34 -0700 (PDT)
From: John Lazzaro <lazzaro@CS.Berkeley.EDU>
Message-Id: <200310211827.h9LIRYbt028868@ribbit.CS.Berkeley.EDU>
To: avt@ietf.org
Subject: [AVT] Re: Retransmission draft
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>


> Colin Perkins writes:
>
> 3GPP is only one forum which uses IETF standards, and one where
> dealing with IPR issues is commonplace. Having patented standards is
> more of an issue for open source developers, who are often excluded by
> the licensing terms.

Yes, the musical-instrument world also has a history of license-free
standards.  Even industry titans like Yamaha and Gibson have found it
tough sledding to get broad acceptance of musical instrument standards
that are patent-encumbered.  So, we would probably exclude an encumbered
retransmission RFC from any framework documents for RTP MIDI sessions.

-------------------------------------------------------------------------
John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
lazzaro [at] cs [dot] berkeley [dot] edu     www.cs.berkeley.edu/~lazzaro
-------------------------------------------------------------------------

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



From exim@www1.ietf.org  Tue Oct 21 15:58:33 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04194
	for <avt-archive@odin.ietf.org>; Tue, 21 Oct 2003 15:58:32 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AC2dx-0008DB-5l
	for avt-archive@odin.ietf.org; Tue, 21 Oct 2003 15:58:13 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LJwDEN031515
	for avt-archive@odin.ietf.org; Tue, 21 Oct 2003 15:58:13 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AC2dl-00086j-TF; Tue, 21 Oct 2003 15:58:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AC2cx-0007pc-15
	for avt@optimus.ietf.org; Tue, 21 Oct 2003 15:57:11 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03921;
	Tue, 21 Oct 2003 15:57:00 -0400 (EDT)
Message-Id: <200310211957.PAA03921@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: avt@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Tue, 21 Oct 2003 15:56:59 -0400
Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-midi-guidelines-00.txt
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Audio/Video Transport Working Group of the IETF.

	Title		: An Implementation Guide for RTP MIDI
	Author(s)	: J. Lazzaro, et.al.
	Filename	: draft-ietf-avt-rtp-midi-guidelines-00.txt
	Pages		: 34
	Date		: 2003-10-21
	
This memo offers non-normative implementation guidance for the RTP
MIDI payload format.  The memo presents its advice in the context
of a network musical performance application.  In this application
two musicians, located in different physical locations, interact
over a network to perform as they would if located in the same
room.  Underlying the performances are RTP MIDI sessions over
unicast UDP.  Algorithms for sending and receiving recovery
journals (the resiliency structure for the payload format) are
described in detail.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-midi-guidelines-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-avt-rtp-midi-guidelines-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-avt-rtp-midi-guidelines-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-10-21153125.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-avt-rtp-midi-guidelines-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-avt-rtp-midi-guidelines-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-10-21153125.I-D@ietf.org>

--OtherAccess--

--NextPart--



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



From exim@www1.ietf.org  Tue Oct 21 15:58:34 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04223
	for <avt-archive@odin.ietf.org>; Tue, 21 Oct 2003 15:58:34 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AC2dx-0008DA-5K
	for avt-archive@odin.ietf.org; Tue, 21 Oct 2003 15:58:13 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LJwDHK031517
	for avt-archive@odin.ietf.org; Tue, 21 Oct 2003 15:58:13 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AC2dm-00086u-FS; Tue, 21 Oct 2003 15:58:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AC2d4-0007rE-41
	for avt@optimus.ietf.org; Tue, 21 Oct 2003 15:57:18 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03938;
	Tue, 21 Oct 2003 15:57:07 -0400 (EDT)
Message-Id: <200310211957.PAA03938@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: avt@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Tue, 21 Oct 2003 15:57:06 -0400
Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-midi-format-00.txt
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Audio/Video Transport Working Group of the IETF.

	Title		: RTP Payload Format for MIDI
	Author(s)	: J. Lazzaro, et. al.
	Filename	: draft-ietf-avt-rtp-midi-format-00.txt
	Pages		: 112
	Date		: 2003-10-21
	
This memo describes an RTP payload format for the MIDI command
language.  The format encodes all commands that may legally appear
on a MIDI 1.0 DIN cable.  The format is suitable for interactive
applications (such as the remote operation of musical instruments)
and content-delivery applications (such as file streaming).  The
format may be used over unicast and multicast UDP as well as TCP,
and defines tools for graceful recovery from packet loss.  Stream
behavior, including the MIDI rendering method, may be customized
during session setup.  The format also serves as a mode for the
mpeg4-generic format, to support the MPEG 4 Audio Object Types for
General MIDI, Downloadable Sounds Level 2, and Structured Audio.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-midi-format-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-avt-rtp-midi-format-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-avt-rtp-midi-format-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-10-21153213.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-avt-rtp-midi-format-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-avt-rtp-midi-format-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-10-21153213.I-D@ietf.org>

--OtherAccess--

--NextPart--



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



From exim@www1.ietf.org  Tue Oct 21 16:23:24 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05855
	for <avt-archive@odin.ietf.org>; Tue, 21 Oct 2003 16:23:24 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AC321-0006vG-Bw
	for avt-archive@odin.ietf.org; Tue, 21 Oct 2003 16:23:05 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LKN5SV026604
	for avt-archive@odin.ietf.org; Tue, 21 Oct 2003 16:23:05 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AC31x-0006t4-EK; Tue, 21 Oct 2003 16:23:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AC31e-0006py-98
	for avt@optimus.ietf.org; Tue, 21 Oct 2003 16:22:42 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05835;
	Tue, 21 Oct 2003 16:22:30 -0400 (EDT)
Message-Id: <200310212022.QAA05835@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: avt@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Tue, 21 Oct 2003 16:22:30 -0400
Subject: [AVT] I-D ACTION:draft-ietf-avt-profile-savpf-00.txt
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Audio/Video Transport Working Group of the IETF.

	Title		: Extended Secure RTP Profile for RTCP-based Feedback (RTP/SAVPF)
	Author(s)	: J. Ott, E. Carrara
	Filename	: draft-ietf-avt-profile-savpf-00.txt
	Pages		: 15
	Date		: 2003-10-20
	
An RTP profile (SAVP) is defined for secure real-time 
communications, and another profile (AVPF) is specified to provide 
timely feedback from the receivers to a sender.  This memo defines 
the combination of both profiles to enable secure RTP 
communications with feedback.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-profile-savpf-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-avt-profile-savpf-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-avt-profile-savpf-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-10-21163613.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-avt-profile-savpf-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-avt-profile-savpf-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-10-21163613.I-D@ietf.org>

--OtherAccess--

--NextPart--



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



From exim@www1.ietf.org  Tue Oct 21 16:36:26 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06477
	for <avt-archive@odin.ietf.org>; Tue, 21 Oct 2003 16:36:26 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AC3Ed-0001Vq-2i
	for avt-archive@odin.ietf.org; Tue, 21 Oct 2003 16:36:07 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LKa7X9005797
	for avt-archive@odin.ietf.org; Tue, 21 Oct 2003 16:36:07 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AC3EZ-0001TJ-6Q; Tue, 21 Oct 2003 16:36:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AC3ES-0001Rh-3H
	for avt@optimus.ietf.org; Tue, 21 Oct 2003 16:35:56 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06422;
	Tue, 21 Oct 2003 16:35:44 -0400 (EDT)
Message-Id: <200310212035.QAA06422@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: avt@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Tue, 21 Oct 2003 16:35:44 -0400
Subject: [AVT] I-D ACTION:draft-clark-avt-rtpmibv2-00.txt
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Proposed Real-Time Transport Protocol
			  Management Information Base Version 2
	Author(s)	: A. Clark
	Filename	: draft-clark-avt-rtpmibv2-00.txt
	Pages		: 36
	Date		: 2003-10-20
	
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it defines objects for managing Real-Time Transport
Protocol (RTP) (RFC3550).  The Version 2 MIB provides extensions to
support the RTP Control Protocol Reporting Extensions (RTCP XR) for
Voice over IP management.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-clark-avt-rtpmibv2-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-clark-avt-rtpmibv2-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-clark-avt-rtpmibv2-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-10-21163918.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-clark-avt-rtpmibv2-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-clark-avt-rtpmibv2-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-10-21163918.I-D@ietf.org>

--OtherAccess--

--NextPart--



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



From exim@www1.ietf.org  Wed Oct 22 08:32:36 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05730
	for <avt-archive@odin.ietf.org>; Wed, 22 Oct 2003 08:32:36 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACI9v-0002jW-7e
	for avt-archive@odin.ietf.org; Wed, 22 Oct 2003 08:32:16 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MCWFJX010502
	for avt-archive@odin.ietf.org; Wed, 22 Oct 2003 08:32:15 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACI9i-0002eG-38; Wed, 22 Oct 2003 08:32:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACI96-0002Wn-1H
	for avt@optimus.ietf.org; Wed, 22 Oct 2003 08:31:25 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05667
	for <avt@ietf.org>; Wed, 22 Oct 2003 08:31:13 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACI94-0004Rh-00
	for avt@ietf.org; Wed, 22 Oct 2003 08:31:22 -0400
Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACI93-0004RK-00
	for avt@ietf.org; Wed, 22 Oct 2003 08:31:21 -0400
Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118])
	by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9MCVFI2015164;
	Wed, 22 Oct 2003 14:31:15 +0200 (MEST)
Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55)
	id 43DPJ40B; Wed, 22 Oct 2003 14:31:15 +0200
Message-ID: <3F967890.2030800@ericsson.com>
Date: Wed, 22 Oct 2003 14:31:12 +0200
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Adam Li <adamli@icsl.ucla.edu>
CC: avt@ietf.org
Subject: Re: [AVT] FEC draft
References: <000101c39786$ef032b40$6c7ba8c0@divxnetworks.com>
In-Reply-To: <000101c39786$ef032b40$6c7ba8c0@divxnetworks.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hi Adam,

[chair hat of]

I have actually thought this over and have a counter proposal that I 
think is rather nice. First I would like to rearrange the header in the 
following way:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      SN base                  |        length recovery        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|L|P|X|  CC   |M| PT recovery |             mask              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          TS recovery                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

That way the 16 bits of fields matches the first 16 bits of the RTP 
header. The sending part can simply XOR the headers of the packet as is 
and mask out the version bits.

Secondly I would actually take the reserved bit and change it into a 
"Long mask" indicator. When the L bit is set the header would then 
actually look like this:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      SN base                  |        length recovery        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|L|P|X|  CC   |M| PT recovery |             mask              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         mask continued                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          TS recovery                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

That way one can allow for a 48 bit mask while still keeping the number 
of options low and keep the 32 bit alignment.

What does you think about it?

Cheers

Magnus


Adam Li wrote:

> Hi folks,
> 
> We would like to discuss the following changes to the FEC draft with
> you, and would like to hear your comments.
> 
> As decided in previous meetings and discussions, we are in the process
> of updating and incorporating the ULP FEC draft with the generic FEC. At
> the same time, taking this chance, we would also like to modify a few
> issues with RFC 2733. In RFC 2733, the M, P, X, and CC bits in the RTP
> header of the FEC packets are calculated from the parity operation, thus
> those fields do not confirm to their normal definition as in RFC 1889.
> 
> The proposed change to fix this issue is to move the parity data of the
> M, P, X, and CC bits into the FEC header part of the FEC packet from the
> RTP header, so the corresponding fields in the RTP header can retain
> their original meaning.
> 
> One of the potential solutions is as below. (E = extension, R =
> reserved)
> 
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |      SN base                  |        length recovery        |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |M| PT recovery |P|X|  CC   |E|R|             mask              |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |                          TS recovery                          |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> With the addition of M, P, X, and CC bits in the FEC header, one extra
> octet is taken. This reduces the mask from 24 to 16 bits. This might
> still be enough, as the typical interleaving is something like 10
> packets.  
> 
> One other potential solution is pretty much as above, but keeping the
> mask at 24 bits as it is in RFC 2733. However, by doing that, the FEC
> header above will not align on a 32 bit boundary, which might be a good
> property to keep.
> 
> So the question we would like to hear your comment is: Shall we (a)
> reduce the mask to 16-bit, or (b) keep the mask at 24-bit, and break the
> 32-bit alignment?
> 
> Your help is very much appreciated.
> 
> Adam
> 
> 
> 
> 
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www1.ietf.org/mailman/listinfo/avt
> 

-- 

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 exim@www1.ietf.org  Wed Oct 22 18:49:31 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03117
	for <avt-archive@odin.ietf.org>; Wed, 22 Oct 2003 18:49:31 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACRn0-0004qi-4L
	for avt-archive@odin.ietf.org; Wed, 22 Oct 2003 18:49:14 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MMnEkT018631
	for avt-archive@odin.ietf.org; Wed, 22 Oct 2003 18:49:14 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACRmm-0004oE-S7; Wed, 22 Oct 2003 18:49:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACRmZ-0004k8-3b
	for avt@optimus.ietf.org; Wed, 22 Oct 2003 18:48:47 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03079;
	Wed, 22 Oct 2003 18:48:33 -0400 (EDT)
Message-Id: <200310222248.SAA03079@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: avt@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Wed, 22 Oct 2003 18:48:33 -0400
Subject: [AVT] I-D ACTION:draft-lazzaro-avt-rtp-framing-contrans-02.txt
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Framing RTP and RTCP Packets over Connection-Oriented 
			  Transport
	Author(s)	: J. Lazzaro
	Filename	: draft-lazzaro-avt-rtp-framing-contrans-02.txt
	Pages		: 8
	Date		: 2003-10-22
	
This memo defines a method for framing Real Time Protocol (RTP) and
Real Time Control Protocol (RTCP) packets onto connection-oriented
transport (such as TCP and TLS).  The memo also defines how to
specify the framing method in a session description.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-lazzaro-avt-rtp-framing-contrans-02.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-lazzaro-avt-rtp-framing-contrans-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-lazzaro-avt-rtp-framing-contrans-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-10-22182904.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-lazzaro-avt-rtp-framing-contrans-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-lazzaro-avt-rtp-framing-contrans-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-10-22182904.I-D@ietf.org>

--OtherAccess--

--NextPart--



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



From exim@www1.ietf.org  Wed Oct 22 19:05:24 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04075
	for <avt-archive@odin.ietf.org>; Wed, 22 Oct 2003 19:05:24 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACS2N-0008WE-BG
	for avt-archive@odin.ietf.org; Wed, 22 Oct 2003 19:05:07 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MN57l2032723
	for avt-archive@odin.ietf.org; Wed, 22 Oct 2003 19:05:07 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACS2I-0008UI-Nj; Wed, 22 Oct 2003 19:05:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACS24-0008Sk-FR
	for avt@optimus.ietf.org; Wed, 22 Oct 2003 19:04: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 TAA04051;
	Wed, 22 Oct 2003 19:04:35 -0400 (EDT)
Message-Id: <200310222304.TAA04051@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: avt@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Wed, 22 Oct 2003 19:04:34 -0400
Subject: [AVT] I-D ACTION:draft-tseng-avt-rtcp-streaming-extens-00.txt
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: RTCP Streaming Extended Reports
	Author(s)	: A. Tseng, et. al.
	Filename	: draft-tseng-avt-rtcp-streaming-extens-00.txt
	Pages		: 14
	Date		: 2003-10-22
	
This document defines a new streaming report block for the Extended 
Report (XR) packet type for the RTP Control Protocol (RTCP) [1].  
XR packets are an extension to the reception report blocks of RTCP 
sender report (SR) or Receiver Report (RR) packets. In [1] seven report 
blocks are defined to receive various information that helps the sender 
to monitor the network and assess quality of VoIP delivery. In this 
document we define a new report block for the XR packet, namely the 
streaming report block, to receive statistics about the quality of an 
audio and/or video streaming session.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-tseng-avt-rtcp-streaming-extens-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-tseng-avt-rtcp-streaming-extens-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-tseng-avt-rtcp-streaming-extens-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-10-22183521.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-tseng-avt-rtcp-streaming-extens-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-tseng-avt-rtcp-streaming-extens-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-10-22183521.I-D@ietf.org>

--OtherAccess--

--NextPart--



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



From exim@www1.ietf.org  Wed Oct 22 20:54:28 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11553
	for <avt-archive@odin.ietf.org>; Wed, 22 Oct 2003 20:54:28 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACTjs-0005XQ-FC
	for avt-archive@odin.ietf.org; Wed, 22 Oct 2003 20:54:08 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9N0s8B5021287
	for avt-archive@odin.ietf.org; Wed, 22 Oct 2003 20:54:08 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACTjk-0005VG-Qb; Wed, 22 Oct 2003 20:54:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACTjG-0005Rm-1d
	for avt@optimus.ietf.org; Wed, 22 Oct 2003 20:53:30 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11530
	for <avt@ietf.org>; Wed, 22 Oct 2003 20:53:19 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACTjD-0006C9-00
	for avt@ietf.org; Wed, 22 Oct 2003 20:53:27 -0400
Received: from mail-relay.divxnetworks.com ([64.132.39.167])
	by ietf-mx with smtp (Exim 4.12)
	id 1ACTjC-0006Bj-00
	for avt@ietf.org; Wed, 22 Oct 2003 20:53:26 -0400
Received: (qmail 10076 invoked from network); 23 Oct 2003 00:52:54 -0000
Received: from unknown (HELO divxnetworks.com) (192.168.0.31)
  by mail-relay.divxnetworks.com with SMTP; 23 Oct 2003 00:52:54 -0000
Received: from WIND ([192.168.0.36]) by divxnetworks.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Wed, 22 Oct 2003 17:51:48 -0700
From: "Adam Li" <adamli@icsl.ucla.edu>
To: "'Magnus Westerlund'" <magnus.westerlund@ericsson.com>
Cc: <avt@ietf.org>
Subject: RE: [AVT] FEC draft
Date: Wed, 22 Oct 2003 17:51:48 -0700
Organization: UCLA
Message-ID: <007001c398ff$d6ae1080$2400a8c0@divxnetworks.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2616
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <3F967890.2030800@ericsson.com>
Importance: Normal
X-OriginalArrivalTime: 23 Oct 2003 00:51:48.0462 (UTC) FILETIME=[D6D128E0:01C398FF]
Content-Transfer-Encoding: 7bit
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hi Magnus,

That's a very nice and elegant idea. I like it better than the one in my
previous email. I will work on rewriting the draft in this way.

Thanks a lot.

Adam

> -----Original Message-----
> From: avt-admin@ietf.org [mailto:avt-admin@ietf.org] On Behalf Of
Magnus
> Westerlund
> Sent: Wednesday, October 22, 2003 5:31 AM
> To: Adam Li
> Cc: avt@ietf.org
> Subject: Re: [AVT] FEC draft
> 
> Hi Adam,
> 
> [chair hat of]
> 
> I have actually thought this over and have a counter proposal that I
> think is rather nice. First I would like to rearrange the header in
the
> following way:
> 
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |      SN base                  |        length recovery        |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |E|L|P|X|  CC   |M| PT recovery |             mask              |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |                          TS recovery                          |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> That way the 16 bits of fields matches the first 16 bits of the RTP
> header. The sending part can simply XOR the headers of the packet as
is
> and mask out the version bits.
> 
> Secondly I would actually take the reserved bit and change it into a
> "Long mask" indicator. When the L bit is set the header would then
> actually look like this:
> 
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |      SN base                  |        length recovery        |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |E|L|P|X|  CC   |M| PT recovery |             mask              |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |                         mask continued                        |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |                          TS recovery                          |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> That way one can allow for a 48 bit mask while still keeping the
number
> of options low and keep the 32 bit alignment.
> 
> What does you think about it?
> 
> Cheers
> 
> Magnus
> 
> 
> Adam Li wrote:
> 
> > Hi folks,
> >
> > We would like to discuss the following changes to the FEC draft with
> > you, and would like to hear your comments.
> >
> > As decided in previous meetings and discussions, we are in the
process
> > of updating and incorporating the ULP FEC draft with the generic
FEC. At
> > the same time, taking this chance, we would also like to modify a
few
> > issues with RFC 2733. In RFC 2733, the M, P, X, and CC bits in the
RTP
> > header of the FEC packets are calculated from the parity operation,
thus
> > those fields do not confirm to their normal definition as in RFC
1889.
> >
> > The proposed change to fix this issue is to move the parity data of
the
> > M, P, X, and CC bits into the FEC header part of the FEC packet from
the
> > RTP header, so the corresponding fields in the RTP header can retain
> > their original meaning.
> >
> > One of the potential solutions is as below. (E = extension, R =
> > reserved)
> >
> >   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >   |      SN base                  |        length recovery        |
> >   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >   |M| PT recovery |P|X|  CC   |E|R|             mask              |
> >   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >   |                          TS recovery                          |
> >   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> > With the addition of M, P, X, and CC bits in the FEC header, one
extra
> > octet is taken. This reduces the mask from 24 to 16 bits. This might
> > still be enough, as the typical interleaving is something like 10
> > packets.
> >
> > One other potential solution is pretty much as above, but keeping
the
> > mask at 24 bits as it is in RFC 2733. However, by doing that, the
FEC
> > header above will not align on a 32 bit boundary, which might be a
good
> > property to keep.
> >
> > So the question we would like to hear your comment is: Shall we (a)
> > reduce the mask to 16-bit, or (b) keep the mask at 24-bit, and break
the
> > 32-bit alignment?
> >
> > Your help is very much appreciated.
> >
> > Adam
> >
> >
> >
> >
> > _______________________________________________
> > Audio/Video Transport Working Group
> > avt@ietf.org
> > https://www1.ietf.org/mailman/listinfo/avt
> >
> 
> --
> 
> 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 exim@www1.ietf.org  Thu Oct 23 04:14:09 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07899
	for <avt-archive@odin.ietf.org>; Thu, 23 Oct 2003 04:14:09 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACabM-0007wQ-AY
	for avt-archive@odin.ietf.org; Thu, 23 Oct 2003 04:13:49 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9N8Dmfn030525
	for avt-archive@odin.ietf.org; Thu, 23 Oct 2003 04:13:48 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACaab-0007k0-Au; Thu, 23 Oct 2003 04:13:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACRkz-0004Nf-6a
	for avt@optimus.ietf.org; Wed, 22 Oct 2003 18:47:09 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02979
	for <avt@ietf.org>; Wed, 22 Oct 2003 18:46:56 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACRkv-0003iN-00
	for avt@ietf.org; Wed, 22 Oct 2003 18:47:05 -0400
Received: from ip72.usw4.rb1.bel.nwlink.com ([209.20.232.72] helo=bels002.mediator.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACRkt-0003hj-00
	for avt@ietf.org; Wed, 22 Oct 2003 18:47:04 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_001_01C398EE.57038B58"
Date: Wed, 22 Oct 2003 15:46:32 -0700
Message-ID: <787ED0EC136B854DB341E7662D666CD65410F3@bels002.mediator.com>
X-MS-Has-Attach: yes
Thread-Topic: FW: draft-tseng-avt-rtcp-streaming-extns-00.txt
Thread-Index: AcOW3t64rKbo8tEbQ/qayfJzR2/mJQAC35PuAABQThgAgFxjEA==
From: "Gamze Seckin" <gamze@vidiator.com>
To: <avt@ietf.org>
Cc: "Alan Tseng" <alan@vidiator.com>
Subject: [AVT] draft-tseng-avt-rtcp-streaming-extns-00.txt
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C398EE.57038B58
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_002_01C398EE.57038B58"


------_=_NextPart_002_01C398EE.57038B58
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: base64

IA0KIERlYXIgQVZUIG1lbWJlcnMsDQogDQpBdHRhY2hlZCBpcyBvdXIgZHJhZnQgY2FsbGVkICJS
VENQIFN0cmVhbWluZyBFeHRlbmRlZCBSZXBvcnRzKGRyYWZ0LXRzZW5nLWF2dC1ydGNwLXN0cmVh
bWluZy1leHRucy0wMC50eHQpIiB3aGljaCB3ZSBzdWJtaXR0ZWQgb24gTW9uZGF5IHRvIGlldGYt
ZHJhZnRzIGRpcmVjdG9yeS4gIA0KVGhlIGZvcm1hdCBpcyBhIGJpdCBtZXNzZWQgdXAgYnV0IHdl
IGFyZSBsb29raW5nIGZvcndhcmQgdG8geW91ciBjb21tZW50cy4NCiANCiB0aGFua3MgYW5kIGJl
c3QgcmVnYXJkcywgDQogZyANCiANCiANCkdhbXplIFNlY2tpbiwgUGguRC4NCkRpcmVjdG9yIG9m
IFJlc2VhcmNoDQpWaWRpYXRvciBUZWNobm9sb2d5IChVUykgSW5jLg0KIDxodHRwOi8vd3d3LnZp
ZGlhdG9yLmNvbS8+IHd3dy52aWRpYXRvci5jb20gDQo0MTEgMTA4dGggQXZlbnVlIE5FLiBTdWl0
ZSA2ODgsDQpCZWxsZXZ1ZSwgV0EgOTgwMDQgVVNBLg0KVGVsZXBob25lOiAxLjQyNS42ODguODgx
MXgyMTA4DQpFbWFpbDogIDxtYWlsdG86Z2FtemVAdmlkaWF0b3IuY29tPiBnYW16ZUB2aWRpYXRv
ci5jb20gDQogDQpUaGlzIGUtbWFpbCBtZXNzYWdlIChpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnQp
IGlzIGludGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJzb25hbCB1c2Ugb2YgdGhlIHJlY2lwaWVudChz
KSBuYW1lZCBhYm92ZS4gVGhpcyBtZXNzYWdlIGlzIGNvbmZpZGVudGlhbCBhbmQgbWF5IGJlIGxl
Z2FsbHkgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCB5
b3UgbWF5IG5vdCByZXZpZXcsIGNvcHkgb3IgZGlzdHJpYnV0ZSB0aGlzIG1lc3NhZ2UuIElmIHlv
dSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlm
eSB1cyBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwgbWVzc2Fn
ZS4gQW55IHZpZXdzIG9yIG9waW5pb25zIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRo
b3NlIG9mIHRoZSBhdXRob3Igb25seS4gRnVydGhlcm1vcmUsIHRoaXMgbWVzc2FnZSBpbmNsdWRp
bmcgYW55IGF0dGFjaG1lbnQgZG9lcyBub3QgY3JlYXRlIGFueSBsZWdhbGx5IGJpbmRpbmcgcmln
aHRzIG9yIG9ibGlnYXRpb25zIHdoYXRzb2V2ZXIsIHdoaWNoIG1heSBvbmx5IGJlIGNyZWF0ZWQg
YnkgdGhlIGV4Y2hhbmdlIG9mIGhhcmQgY29weSBkb2N1bWVudHMgc2lnbmVkIGJ5IGEgZHVseSBh
dXRob3JpemVkIHJlcHJlc2VudGF0aXZlIG9mIFZpZGlhdG9yIFRlY2hub2xvZ3kgKFVTKSBJbmMu
DQo=

------_=_NextPart_002_01C398EE.57038B58
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U
RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPFRJVExFPlJlOiBGVzogZHJhZnQtdHNl
bmctYXZ0LXJ0Y3Atc3RyZWFtaW5nLWV4dG5zLTAwLnR4dDwvVElUTEU+DQoNCjxNRVRBIGNvbnRl
bnQ9Ik1TSFRNTCA2LjAwLjI3MjYuMjUwMCIgbmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJPRFkg
ZGlyPWx0cj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElW
Pg0KPERJViBjbGFzcz1PdXRsb29rTWVzc2FnZUhlYWRlciBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQ
QU4gDQpjbGFzcz02MTkyMzM3MjItMjIxMDIwMDM+PEZPTlQgc2l6ZT0yPiZuYnNwO0RlYXIgQVZU
IA0KbWVtYmVycyw8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJViBjbGFzcz1PdXRsb29rTWVzc2Fn
ZUhlYWRlciBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gDQpjbGFzcz02MTkyMzM3MjItMjIxMDIw
MDM+PEZPTlQgc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWIGNsYXNzPU91
dGxvb2tNZXNzYWdlSGVhZGVyIGRpcj1sdHIgYWxpZ249bGVmdD48Rk9OVCBzaXplPTI+PFNQQU4g
DQpjbGFzcz02MTkyMzM3MjItMjIxMDIwMDM+QXR0YWNoZWQgaXMgb3VyIGRyYWZ0IGNhbGxlZCAi
PC9TUEFOPjxGT05UIA0KZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48U1BBTiANCnN0eWxlPSJGT05U
LVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnIj48Rk9OVCANCmZhY2U9IlRp
bWVzIE5ldyBSb21hbiI+UlRDUCBTdHJlYW1pbmcgRXh0ZW5kZWQgDQpSZXBvcnRzKGRyYWZ0LXRz
ZW5nLWF2dC1ydGNwLXN0cmVhbWluZy1leHRucy0wMC50eHQ8U1BBTiANCmNsYXNzPTYxOTIzMzcy
Mi0yMjEwMjAwMz4pPC9TUEFOPjwvRk9OVD48U1BBTiBjbGFzcz02MTkyMzM3MjItMjIxMDIwMDM+
PEZPTlQgDQpmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiI8L0ZPTlQ+IDxGT05UIGZhY2U9IlRpbWVz
IE5ldyBSb21hbiI+d2hpY2ggd2Ugc3VibWl0dGVkIA0Kb24gTW9uZGF5IHRvIGlldGYtZHJhZnRz
IGRpcmVjdG9yeTwvRk9OVD48L1NQQU4+PC9TUEFOPi48U1BBTiANCmNsYXNzPTYxOTIzMzcyMi0y
MjEwMjAwMz4mbmJzcDsmbmJzcDs8L1NQQU4+PC9GT05UPjwvRk9OVD48L0RJVj4NCjxESVYgY2xh
c3M9T3V0bG9va01lc3NhZ2VIZWFkZXIgZGlyPWx0ciBhbGlnbj1sZWZ0PjxGT05UIHNpemU9Mj48
Rk9OVCANCmZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PFNQQU4gY2xhc3M9NjE5MjMzNzIyLTIyMTAy
MDAzPlRoZSBmb3JtYXQgaXMgYSBiaXQgbWVzc2VkIA0KdXAgYnV0IHdlIGFyZSBsb29raW5nIGZv
cndhcmQgdG8geW91ciBjb21tZW50cy48L1NQQU4+PC9GT05UPjwvRk9OVD48L0RJVj4NCjxESVYg
Y2xhc3M9T3V0bG9va01lc3NhZ2VIZWFkZXIgZGlyPWx0ciBhbGlnbj1sZWZ0PjxGT05UPjxGT05U
IA0KZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48U1BBTiBjbGFzcz02MTkyMzM3MjItMjIxMDIwMDM+
PC9TUEFOPjwvRk9OVD48L0ZPTlQ+PEZPTlQgDQpzaXplPTI+PFNQQU4gY2xhc3M9NjE5MjMzNzIy
LTIyMTAyMDAzPjwvU1BBTj48L0ZPTlQ+PEZPTlQgc2l6ZT0yPjxTUEFOIA0KY2xhc3M9NjE5MjMz
NzIyLTIyMTAyMDAzPjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWIGNsYXNzPU91dGxv
b2tNZXNzYWdlSGVhZGVyIGRpcj1sdHIgYWxpZ249bGVmdD48Rk9OVCBzaXplPTI+PFNQQU4gDQpj
bGFzcz02MTkyMzM3MjItMjIxMDIwMDM+Jm5ic3A7PC9TUEFOPnRoYW5rcyBhbmQgYmVzdCByZWdh
cmRzLDxTUEFOIA0KY2xhc3M9NjE5MjMzNzIyLTIyMTAyMDAzPjxGT05UIGZhY2U9QXJpYWw+Jm5i
c3A7PC9GT05UPjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQo8RElWIGNsYXNzPU91dGxvb2tNZXNzYWdl
SGVhZGVyIGRpcj1sdHIgYWxpZ249bGVmdD48Rk9OVCBzaXplPTI+PFNQQU4gDQpjbGFzcz02MTky
MzM3MjItMjIxMDIwMDM+Jm5ic3A7PC9TUEFOPmc8U1BBTiBjbGFzcz02MTkyMzM3MjItMjIxMDIw
MDM+PEZPTlQgDQpmYWNlPUFyaWFsPiZuYnNwOzwvRk9OVD48L1NQQU4+PC9GT05UPjwvRElWPg0K
PERJViBjbGFzcz1PdXRsb29rTWVzc2FnZUhlYWRlciBkaXI9bHRyIGFsaWduPWxlZnQ+PEZPTlQg
c2l6ZT0yPjxTUEFOIA0KY2xhc3M9NjE5MjMzNzIyLTIyMTAyMDAzPiZuYnNwOzwvU1BBTj48L0ZP
TlQ+PC9ESVY+DQo8RElWIGNsYXNzPU91dGxvb2tNZXNzYWdlSGVhZGVyIGRpcj1sdHIgYWxpZ249
bGVmdD48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiANCmNsYXNzPTYxOTIzMzcyMi0yMjEw
MjAwMz48L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJViBkaXI9bHRyPg0KPERJVj48Rk9O
VCBzaXplPTI+R2FtemUgU2Vja2luLCBQaC5ELjxCUj5EaXJlY3RvciBvZiBSZXNlYXJjaDxCUj5W
aWRpYXRvciANClRlY2hub2xvZ3kgKFVTKSBJbmMuPEJSPjxTUEFOIGNsYXNzPTYxOTIzMzcyMi0y
MjEwMjAwMz48QSANCmhyZWY9Imh0dHA6Ly93d3cudmlkaWF0b3IuY29tLyI+PEZPTlQgDQpjb2xv
cj0jMDAwMDAwPnd3dy52aWRpYXRvci5jb208L0ZPTlQ+PC9BPiZuYnNwOzwvU1BBTj48QlI+NDEx
IDEwOHRoIEF2ZW51ZSBORS4gDQpTdWl0ZSA2ODgsPEJSPkJlbGxldnVlLCBXQSA5ODAwNCBVU0Eu
PEJSPlRlbGVwaG9uZTogDQoxLjQyNS42ODguODgxMXgyMTA4PEJSPkVtYWlsOiA8L0ZPTlQ+PEEg
aHJlZj0ibWFpbHRvOmdhbXplQHZpZGlhdG9yLmNvbSI+PEZPTlQgDQpzaXplPTI+Z2FtemVAdmlk
aWF0b3IuY29tPC9GT05UPjwvQT48U1BBTiBjbGFzcz02MTkyMzM3MjItMjIxMDIwMDM+PEZPTlQg
DQpzaXplPTI+Jm5ic3A7PC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjxT
UEFOIGNsYXNzPTYxOTIzMzcyMi0yMjEwMjAwMz4mbmJzcDs8L1NQQU4+PEJSPlRoaXMgZS1tYWls
IA0KbWVzc2FnZSAoaW5jbHVkaW5nIGFueSBhdHRhY2htZW50KSBpcyBpbnRlbmRlZCBvbmx5IGZv
ciB0aGUgcGVyc29uYWwgdXNlIG9mIHRoZSANCnJlY2lwaWVudChzKSBuYW1lZCBhYm92ZS4gVGhp
cyBtZXNzYWdlIGlzIGNvbmZpZGVudGlhbCBhbmQgbWF5IGJlIGxlZ2FsbHkgDQpwcml2aWxlZ2Vk
LiBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBtYXkgbm90IHJldmll
dywgY29weSBvciANCmRpc3RyaWJ1dGUgdGhpcyBtZXNzYWdlLiBJZiB5b3UgaGF2ZSByZWNlaXZl
ZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIA0KcGxlYXNlIG5vdGlmeSB1cyBpbW1lZGlh
dGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwgbWVzc2FnZS4gQW55IA0Kdmll
d3Mgb3Igb3BpbmlvbnMgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhl
IGF1dGhvciBvbmx5LiANCkZ1cnRoZXJtb3JlLCB0aGlzIG1lc3NhZ2UgaW5jbHVkaW5nIGFueSBh
dHRhY2htZW50IGRvZXMgbm90IGNyZWF0ZSBhbnkgbGVnYWxseSANCmJpbmRpbmcgcmlnaHRzIG9y
IG9ibGlnYXRpb25zIHdoYXRzb2V2ZXIsIHdoaWNoIG1heSBvbmx5IGJlIGNyZWF0ZWQgYnkgdGhl
IA0KZXhjaGFuZ2Ugb2YgaGFyZCBjb3B5IGRvY3VtZW50cyBzaWduZWQgYnkgYSBkdWx5IGF1dGhv
cml6ZWQgcmVwcmVzZW50YXRpdmUgb2YgDQpWaWRpYXRvciBUZWNobm9sb2d5IChVUykgSW5jLjwv
Rk9OVD48L0RJVj48L0RJVj48L0JPRFk+PC9IVE1MPg0K

------_=_NextPart_002_01C398EE.57038B58--

------_=_NextPart_001_01C398EE.57038B58
Content-Type: text/plain;
	name="draft-tseng-avt-rtcp-streaming-extns-00.txt"
Content-Transfer-Encoding: base64
Content-Description: draft-tseng-avt-rtcp-streaming-extns-00.txt
Content-Disposition: attachment;
	filename="draft-tseng-avt-rtcp-streaming-extns-00.txt"
Content-Transfer-Encoding: base64
Content-Transfer-Encoding: base64

SU5URVJORVQtRFJBRlQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAx
OSBPY3RvYmVyIDIwMDMNCkludGVybmV0IEVuZ2luZWVyaW5nIFRhc2sgRm9yY2UgICAgICAgICAg
ICAgICAgICBFeHBpcmVzOiAxOSBBcHJpbCAyMDA0DQpBdWRpby9WaWRlbyBUcmFuc3BvcnQgV29y
a2luZyBHcm91cA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBbGFuIFRzZW5nDQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
R2FtemUgU2Vja2luDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IFZpZGlhdG9yIFRlY2hub2xvZ3kgVVMgSW5jLg0KICAgICANCgkJCQkJCSAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KICAgICAgICAgICAgICAgICAg
ICAgIFJUQ1AgU3RyZWFtaW5nIEV4dGVuZGVkIFJlcG9ydHMNCiAgICAgICAgICAgICAgICBkcmFm
dC10c2VuZy1hdnQtcnRjcC1zdHJlYW1pbmctZXh0ZW5zLTAwLnR4dA0KDQoNClN0YXR1cyBvZiB0
aGlzIE1lbW8NCg0KICAgVGhpcyBkb2N1bWVudCBpcyBhbiBJbnRlcm5ldC1EcmFmdCBhbmQgaXMg
c3ViamVjdCB0byBhbGwgcHJvdmlzaW9ucw0KICAgb2YgU2VjdGlvbiAxMCBvZiBSRkMyMDI2Lg0K
DQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5l
dCBFbmdpbmVlcmluZw0KICAgVGFzayBGb3JjZSAoSUVURiksIGl0cyBhcmVhcywgYW5kIGl0cyB3
b3JraW5nIGdyb3Vwcy4gIE5vdGUgdGhhdA0KICAgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3Ry
aWJ1dGUgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtDQogICBEcmFmdHMuDQoNCiAgIElu
dGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Yg
c2l4IG1vbnRocw0KICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVk
IGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkNCiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRl
IHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlDQogICBtYXRlcmlhbCBvciB0byBj
aXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iDQoNCiAgIFRoZSBsaXN0
IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAgaHR0cDov
L3d3dy5pZXRmLm9yZy8xaWQtYWJzdHJhY3RzLmh0bWwNCg0KICAgVGhlIGxpc3Qgb2YgSW50ZXJu
ZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAgaHR0cDov
L3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbA0KDQpBYnN0cmFjdA0KVGhpcyBkb2N1bWVudCBkZWZp
bmVzIGEgbmV3IHN0cmVhbWluZyByZXBvcnQgYmxvY2sgZm9yIHRoZSBFeHRlbmRlZCANClJlcG9y
dCAoWFIpIHBhY2tldCB0eXBlIGZvciB0aGUgUlRQIENvbnRyb2wgUHJvdG9jb2wgKFJUQ1ApIFsx
XS4gIA0KWFIgcGFja2V0cyBhcmUgYW4gZXh0ZW5zaW9uIHRvIHRoZSByZWNlcHRpb24gcmVwb3J0
IGJsb2NrcyBvZiBSVENQIA0Kc2VuZGVyIHJlcG9ydCAoU1IpIG9yIFJlY2VpdmVyIFJlcG9ydCAo
UlIpIHBhY2tldHMuIEluIFsxXSBzZXZlbiByZXBvcnQgDQpibG9ja3MgYXJlIGRlZmluZWQgdG8g
cmVjZWl2ZSB2YXJpb3VzIGluZm9ybWF0aW9uIHRoYXQgaGVscHMgdGhlIHNlbmRlciANCnRvIG1v
bml0b3IgdGhlIG5ldHdvcmsgYW5kIGFzc2VzcyBxdWFsaXR5IG9mIFZvSVAgZGVsaXZlcnkuIElu
IHRoaXMgDQpkb2N1bWVudCB3ZSBkZWZpbmUgYSBuZXcgcmVwb3J0IGJsb2NrIGZvciB0aGUgWFIg
cGFja2V0LCBuYW1lbHkgdGhlIA0Kc3RyZWFtaW5nIHJlcG9ydCBibG9jaywgdG8gcmVjZWl2ZSBz
dGF0aXN0aWNzIGFib3V0IHRoZSBxdWFsaXR5IG9mIGFuIA0KYXVkaW8gYW5kL29yIHZpZGVvIHN0
cmVhbWluZyBzZXNzaW9uLg0KDQpUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJF
UVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsDQoiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAi
UkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4gdGhpcw0KZG9jdW1lbnQgYXJl
IHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBbUkZDMjExOV0uDQoNCg0KDQoNCg0K
DQpUc2VuZywgU2Vja2luICAgICAgICAgICBFeHBpcmVzIEFwcmlsIDE5LCAyMDA0ICAgICAgICAg
ICAgICAgIFtQYWdlIDFdDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgIFJUQ1AgU3RyZWFtaW5n
IFhSICAgICAgICAgICAgICAgT2N0b2JlciAyMDAzDQoNCg0KDQpUYWJsZSBvZiBDb250ZW50cw0K
DQogICAxLiAgICAgSW50cm9kdWN0aW9uIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLjINCiAgIDIuICAgICBHZW5lcmljIERlZmluaXRpb25zLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMg0KICAgMy4gICAgIFN0cmVhbWluZyBRdWFsaXR5
IE1ldHJpYyBEZWZpbml0aW9ucy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4zDQogICAgICAgICAgMy4x
IFJlcG9ydGluZyBQZXJpb2QuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjQN
CiAgICAgICAgICAzLjIgR29vZCBGcmFtZS4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uNA0KICAgICAgICAgIDMuMyBDb3JydXB0aW9uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi40DQogICAgICAgICAgICAgIDMuMy4xIFZpZGVvIENv
cnJ1cHRpb25zLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjYNCiAgICAgICAgICAgICAg
My4zLjIgQXVkaW8gQ29ycnVwdGlvbnMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNg0K
ICAgICAgICAgIDMuNCBSZWJ1ZmZlcmluZy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi43DQogICAgICAgICAgMy41IFBlciBtZWRpYSByZXBvcnRpbmcuLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjggCQ0KICAgNC4gICAgIFN0cmVhbWluZyBSZXBvcnQg
QmxvY2sgZm9yIFhSIFBhY2tldHMuLi4uLi4uLi4uLi4uLi4uLi4uLi44DQogICA1LiAgICAgU3Ry
ZWFtaW5nIFJlcG9ydCBCbG9jayBJbnRlcnZhbC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTIN
CiAgIDYuICAgICBUaGUgU0RQIGF0dHJpYnV0ZS4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4xMiANCiAgIDcuICAgICBJQU5BIENvbnNpZGVyYXRpb25zIC4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMw0KICAgOC4gICAgIFNlY3VyaXR5IENvbnNpZGVy
YXRpb25zIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjEzDQogICA5LiAgICAgSW50
ZWxsZWN0dWFsIFByb3BlcnR5IC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTMN
CiAgIDEwLiAgICBBY2tub3dsZWRnbWVudHMgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4xMyANCiAgIDExLiAgICBBdXRob3JzJyBBZGRyZXNzZXMgLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xNCANCiAgIDEyLiAgICBSZWZlcmVuY2VzIC4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xNCANCiAgIDEzLiAgICBG
dWxsIENvcHlyaWdodCBTdGF0ZW1lbnQgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4x
NCANCg0KDQoxLiBJbnRyb2R1Y3Rpb24NCg0KVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgbmV3IHN0
cmVhbWluZyByZXBvcnQgYmxvY2sgZm9yIHRoZSBFeHRlbmRlZCANClJlcG9ydCAoWFIpIHBhY2tl
dCB0eXBlIGZvciB0aGUgUlRQIENvbnRyb2wgUHJvdG9jb2wgKFJUQ1ApIFsxXS4NClhSIHBhY2tl
dHMgYXJlIGFuIGV4dGVuc2lvbiB0byB0aGUgcmVjZXB0aW9uIHJlcG9ydCBibG9ja3Mgb2YgUlRD
UCANCnNlbmRlciByZXBvcnQgKFNSKSBvciBSZWNlaXZlciBSZXBvcnQgKFJSKSBwYWNrZXRzLiBJ
biBbMV0gc2V2ZW4gcmVwb3J0IA0KYmxvY2tzIGFyZSBkZWZpbmVkIHRvIHJlY2VpdmUgdmFyaW91
cyBpbmZvcm1hdGlvbiB0aGF0IGhlbHBzIHRvIG1vbml0b3INCnRoZSBuZXR3b3JrIGFuZCBhc3Nl
c3MgcXVhbGl0eSBvZiBWb0lQIGRlbGl2ZXJ5LiBJbiB0aGlzIGRvY3VtZW50IHdlIA0KZGVmaW5l
IGEgbmV3IHJlcG9ydCBibG9jayBmb3IgdGhlIFhSIHBhY2tldCwgbmFtZWx5IHRoZSBzdHJlYW1p
bmcgDQpyZXBvcnQgYmxvY2ssIHRvIHJlY2VpdmUgc3RhdGlzdGljcyBhYm91dCB0aGUgcXVhbGl0
eSBvZiBhbiBhdWRpbyANCmFuZC9vciB2aWRlbyBzdHJlYW1pbmcgc2Vzc2lvbi4gQXMgYWxsIHRo
ZSBvdGhlciByZXBvcnQgYmxvY2tzIA0KZGVmaW5lZCBpbiBbMV0sIHRoZSBzdHJlYW1pbmcgcmVw
b3J0IGJsb2NrcyBhcmUgYXBwbGljYWJsZSB0byANCm9uZS10by1vbmUgb3Igb25lLXRvLW1hbnkg
YXBwbGljYXRpb25zIHRoYXQgZ2VuZXJhdGUgDQpSVENQIFNSIG9yIFJSIHJlcG9ydHMuDQoNCiAN
CjIuIEdlbmVyaWMgRGVmaW5pdGlvbnMNCg0KQVZQIChBdWRpbyBhbmQgVmlkZW8gUHJvZmlsZSkg
bW9kdWxlOiBBbiBhYnN0cmFjdCBtb2R1bGUgcmVzcG9uc2libGUgDQpmb3IgcHJlc2VudGluZyBk
YXRhIHRvIGFuIGluZGl2aWR1YWwgZGVjb2RlciBmb3IgZGVjb2RpbmcgKEZpZ3VyZSAxKS4gIA0K
Rm9yIHB1cnBvc2VzIG9mIHRoZSBYUiByZXBvcnQsIHRoZSBBVlAgbW9kdWxlIGlzIHJlc3BvbnNp
YmxlIGZvciANCnBhcnNpbmcgQVZQIHN5bnRheCBhbmQgYWxsIGxvd2VyIGxheWVycyBpbmNsdWRp
bmcgUlRQLCBVRFAsIGV0Yy4NCg0KDQoNCg0KDQoNClRzZW5nLCBTZWNraW4gICAgICAgRXhwaXJl
cyBBcHJpbCAxOSwgMjAwNCAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMl0NCkludGVybmV0LURy
YWZ0ICAgICAgICAgICBSVENQIFN0cmVhbWluZyBYUiAgICAgICAgICAgICAgICBPY3RvYmVyIDIw
MDMNCg0KDQoNCkRlY29kZXIgbW9kdWxlOiBBbiBhYnN0cmFjdCBtb2R1bGUgcmVzcG9uc2libGUg
Zm9yIGRlY29kaW5nIGFuIGlucHV0IA0KcmF3IGJpdHN0cmVhbSwgYW5kIG91dHB1dHRpbmcgdGlt
ZXN0YW1wZWQgbXVsdGltZWRpYSBkYXRhIHN1Y2ggYXMgDQp2aWRlbyBmcmFtZXMgb3IgUENNIGF1
ZGlvLg0KDQpQbGF5ZXIgYXBwbGljYXRpb246IEFuIGFic3RyYWN0IGVudGl0eSB0aGF0IGVuY29t
cGFzc2VzIG9uZSBvciBtb3JlIEFWUCANCm1vZHVsZXMsIGRlY29kZXIgbW9kdWxlcywgYW5kIFhS
IHJlcG9ydCBtb2R1bGVzLCBhbmQgaXMgcmVzcG9uc2libGUgZm9yIA0KY29tcG9zaW5nLCByZW5k
ZXJpbmcsIGFuZCBzeW5jaHJvbml6aW5nIGEgbXVsdGltZWRpYSBwcmVzZW50YXRpb24uIA0KRm9y
IHRoZSBwdXJwb3NlcyBvZiB0aGUgWFIgcmVwb3J0LCB0aGUgcGxheWVyIGFwcGxpY2F0aW9uIGlz
IA0KcmVzcG9uc2libGUgZm9yIGNvbmZpZ3VyaW5nIHRoZSBYUiBtb2R1bGUgd2l0aCB0aW1pbmcg
aW5mb3JtYXRpb24sIA0KYW5kIHJlcG9ydGluZy4NCg0KWFIgUmVwb3J0IG1vZHVsZTogQW4gYWJz
dHJhY3QgbW9kdWxlIHJlc3BvbnNpYmxlIGZvciBjb2xsZWN0aW5nIGRhdGEgDQpmcm9tIHRoZSBB
VlAgbW9kdWxlLCB0aGUgZGVjb2RlciBtb2R1bGUsIGFuZCBwbGF5ZXIgYXBwbGljYXRpb24sIGFu
ZCANCmNvbXBpbGluZyB0aGVtIGludG8gYW4gWFIgUmVwb3J0Lg0KDQpYUiBSZXBvcnQ6IEFuIFJU
Q1AgZXh0ZW5zaW9uIGJsb2NrIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudC4NCg0KKy0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCnwgICAgICAgICAg
ICAgICAgIFBsYXllciBhcHBsaWNhdGlvbiAgICAgICAgICAgICAgICB8DQorLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgICBeICAgICAgICAg
ICAgIHwgICAgICAgICAgICAgXiAgICAgICAgICAgICB8DQogICAgIHwgICAgICAgICAgICAgfCAg
ICAgICAgICAgICB8ICAgICAgICAgICAgIHwNCiAgICAgfCAgICAgICAgICAgICB2ICAgICAgICAg
ICAgIHwgICAgICAgICAgICAgdg0KKy0tLS0tLS0tLSsgICArLS0tLS0tLS0tKyAgICstLS0tLS0t
LS0rICAgKy0tLS0tLS0tLSsNCnwgRGVjb2RlciB8LS0+fCAgICAgICAgIHwgICB8IERlY29kZXIg
fC0tPnwgICAgICAgICB8DQorLS0tLS0tLS0tKyAgIHwgICAgICAgICB8ICAgKy0tLS0tLS0tLSsg
ICB8ICAgICAgICAgfCAgIA0KICAgICBeICAgICAgICB8ICAgWFIgICAgfCAgICAgICAgXiAgICAg
ICAgfCAgIFhSICAgIHwNCiAgICAgfCAgICAgICAgfCAgUmVwb3J0IHwgICAgICAgIHwgICAgICAg
IHwgIFJlcG9ydCB8ICAgDQogICAgIHwgICAgICAgIHwgIEJsb2NrICB8ICAgICAgICB8ICAgICAg
ICB8ICBCbG9jayAgfA0KKy0tLS0tLS0tLSsgICB8ICAgICAgICAgfCAgICstLS0tLS0tLS0rICAg
fCAgICAgICAgIHwgICANCnwgICBBVlAgICB8LS0+fCAgICAgICAgIHwgICB8ICAgQVZQICAgfC0t
PnwgICAgICAgICB8ICAgDQorLS0tLS0tLS0tKyAgICstLS0tLS0tLS0rICAgKy0tLS0tLS0tLSsg
ICArLS0tLS0tLS0tKyAgIA0KICAgICBeICAgICAgICAgICAgIHwgICAgICAgICAgICAgXiAgICAg
ICAgICAgICB8DQogICAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAg
IHwNCiAgICAgfCAgICAgICAgICAgICB2ICAgICAgICAgICAgIHwgICAgICAgICAgICAgdg0KKy0t
LS0tLS0tLSsgICArLS0tLS0tLS0tKyAgICstLS0tLS0tLS0rICAgKy0tLS0tLS0tLSsgICANCnwg
ICBSVFAgICB8ICAgfCAgUlRDUCAgIHwgICB8ICAgUlRQICAgfCAgIHwgIFJUQ1AgICB8ICAgDQor
LS0tLS0tLS0tKyAgICstLS0tLS0tLS0rICAgKy0tLS0tLS0tLSsgICArLS0tLS0tLS0tKyAgIA0K
DQpGaWd1cmUgMTogSWxsdXN0cmF0aW9uIG9mIGRhdGEgZmxvd3MgaW4gYSBzYW1wbGUgc3RyZWFt
aW5nIG11bHRpbWVkaWEgDQpwbGF5YmFjayBhcHBsaWNhdGlvbi4NCg0KMy4gU3RyZWFtaW5nIFF1
YWxpdHkgTWV0cmljIERlZmluaXRpb25zDQoNCkFzIGRlZmluZWQgaW4gWzJdIHRoZXJlIGFyZSBz
ZXZlcmFsIG1ldHJpY3MgdGhhdCBjYW4gaGVscCBkZXRlcm1pbmluZyANCnRoZSBxdWFsaXR5IG9m
IGV4cGVyaWVuY2UgaW4gYSBzdHJlYW1pbmcgc2Vzc2lvbi4gRXhhbXBsZXMgb2YgcG9vciANCnF1
YWxpdHkgb2YgZXhwZXJpZW5jZSBjb3VsZCBpbmNsdWRlOg0KDQoNCg0KDQoNClRzZW5nLCBTZWNr
aW4gICAgICAgRXhwaXJlcyBBcHJpbCAxOSwgMjAwNCAgICAgICAgICAgICAgICAgICAgW1BhZ2Ug
M10NCkludGVybmV0LURyYWZ0ICAgICAgICAgICBSVENQIFN0cmVhbWluZyBYUiAgICAgICAgICAg
ICAgICBPY3RvYmVyIDIwMDMNCg0KDQoNCiAgbyAgICBtYWNyb2Jsb2NrIGNvcnJ1cHRpb24gZm9y
IHZpZGVvDQogIG8gICAgYnVyc3RzIG9mIGdhcmJsZWQsIHN0YXRpY3MsIG9yIHNpbGVudCBhdWRp
bw0KICBvICAgIHJlYnVmZmVyaW5nIHBlcmlvZHMgaW4gd2hpY2ggYSB2aWRlbyBwcmVzZW50YXRp
b24gJ2ZyZWV6ZXMnLg0KDQpCYXNlZCBvbiBbMl0gdGhlIGJhc2ljIHN0cmVhbWluZyBxdWFsaXR5
IG1ldHJpY3MgZGVmaW5pdGlvbnMgYXJlIA0KYXMgZm9sbG93czoNCg0KMy4xIFJlcG9ydGluZyBw
ZXJpb2QNCg0KVGhlIHJlcG9ydGluZyBwZXJpb2QgaXMgdGhlIHBlcmlvZCBvdmVyIHdoaWNoIGEg
c2V0IG9mIG1ldHJpY3MgaXMgDQpjYWxjdWxhdGVkLiBBbGwgdGltZXN0YW1wcyByZXBvcnRlZCBi
eSB0aGUgWFIgcGFja2V0IFNIQUxMIGJlIFJUUCANCnRpbWVzdGFtcHMuIEFsbCBkdXJhdGlvbnMg
U0hBTEwgYmUgaW4gdW5pdHMgb2YgdGhlIFJUUCB0aW1lYmFzZS4gDQoNCkl0IGlzIHBvc3NpYmxl
IHRoYXQgdGhlIGRlY29kZXIgYW5kIG5ldHdvcmsgbGF5ZXJzIHVzZSBkaWZmZXJlbnQgDQp0aW1l
bGluZXMgKGUuZy4sIHRoZSBkZWNvZGVyIHJlcG9ydHMgTVBFRy00IHRpbWVzdGFtcHMgYW5kIHRo
ZSANCkFWUCBsYXllciByZXBvcnRzIFJUUCB0aW1lc3RhbXBzKS4gSWYgdGhlIGRlY29kZXIgZG9l
cyBub3QgcmVwb3J0IA0KY29ycnVwdGlvbiBwZXJpb2RzIGluIFJUUCB0aW1lc3RhbXBzLCB0aGUg
YXBwbGljYXRpb24gaXMgcmVzcG9uc2libGUgDQpmb3IgY29uZmlndXJpbmcgdGhlIFhSIHJlcG9y
dCBibG9jayB0byB1c2UgY29ycmVjdCB0aW1pbmcgYW5kIA0Kc3luY2hyb25pemF0aW9uIGluZm9y
bWF0aW9uLiBBIGxpc3Qgb2YgcG9zc2libGUgbWV0aG9kcyBmb2xsb3dzOyANCnRoaXMgbGlzdCBp
cyBieSBubyBtZWFucyBleGhhdXN0aXZlLg0KDQotIElmIHRoZSBkZWNvZGVyIHNwZWNpZmllcyBj
b3JydXB0aW9uIGludGVydmFscyBhcyBOUFQgdGltZXMsIA0KdGhlIGFwcGxpY2F0aW9uIG1heSBw
cm92aWRlIE5QVCB0byBSVFAgbWFwcGluZywgb2J0YWluZWQgZnJvbSANClJUU1AgUnRwLUluZm8g
aGVhZGVyLg0KDQotIElmIHRoZSBkZWNvZGVyIHNwZWNpZmllcyBjb3JydXB0aW9uIGludGVydmFs
cyBhcyBSVFAgdGltZXMsIA0KdGhlIGFwcGxpY2F0aW9uIGRvZXMgbm90IG5lZWQgdG8gcHJvdmlk
ZSBhbnkgYWRkaXRpb25hbCBpbmZvcm1hdGlvbi4NCg0KMy4yIEdvb2QgZnJhbWUNCg0KSWRlYWxs
eSBhIGdvb2QgZnJhbWUgaXMgYSBkZWNvZGVkIHZpZGVvIG9yIGF1ZGlvIGZyYW1lIHJlY2VpdmVk
IA0KYnkgdGhlIGNsaWVudCB0aGF0IG1hdGNoZXMgdGhlIGZyYW1lIHNlbnQgYnkgdGhlIHNlcnZl
ci4gIA0KSG93ZXZlciwgc2luY2UgdGhlIGNsaWVudCBjYW4gbm90IGNvbXBhcmUgdGhlc2UgZGly
ZWN0bHksIA0KYSBnb29kIGZyYW1lIGlzIGRlZmluZWQgYXMgYSBkZWNvZGVkIHZpZGVvIG9yIGF1
ZGlvIGZyYW1lIA0KZm9yIHdoaWNoIG5vIGNvcnJ1cHRpb24gaXMgZGV0ZWN0ZWQuDQoNCjMuMy4g
Q29ycnVwdGlvbg0KDQpBIG1lZGlhIChhdWRpby9zcGVlY2gvdmlkZW8pIGNvcnJ1cHRpb24gcGVy
aW9kIGlzIGRlZmluZWQgYXMgcGVyaW9kIA0Kd2hlcmUgdGhlIG1lZGlhIChhdWRpby9zcGVlY2gv
dmlkZW8pIGhhcyBmcmVlemVzL2dhcHMgb3IgcXVhbGl0eSANCmRlZ3JhZGF0aW9ucy4gQ29ycnVw
dGlvbiBwZXJpb2QgaW4gdGltZSBpcyBkZWZpbmVkIGZyb20gc3RhcnQgb2YgdGhlIA0KZmlyc3Qg
Y29ycnVwdGVkIG1lZGlhIChhdWRpby9zcGVlY2gvdmlkZW8pIGRlY29kZWQgZnJhbWUgdG8gdGhl
IHN0YXJ0IA0Kb2YgZmlyc3Qgc3Vic2VxdWVudCBkZWNvZGVkIGdvb2QgZnJhbWUgb3IgdGhlIGVu
ZCBvZiByZXBvcnRpbmcgcGVyaW9kIA0KKHdoaWNoZXZlciBpcyBzb29uZXIpIG5vdCBpbmNsdWRp
bmcgdGhlIGJ1ZmZlcmluZyBmcmVlemVzL2dhcHMgYW5kIA0KcGF1c2UgZnJlZXplcy9nYXBzLiAN
Cg0KDQoNCg0KDQoNClRzZW5nLCBTZWNraW4gICAgICAgRXhwaXJlcyBBcHJpbCAxOSwgMjAwNCAg
ICAgICAgICAgICAgICAgICAgW1BhZ2UgNF0NCg0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgIFJU
Q1AgU3RyZWFtaW5nIFhSICAgICAgICAgICAgICAgIE9jdG9iZXIgMjAwMw0KDQoNCg0KSW4gdGhl
IGV4YW1wbGUgaW4gRmlndXJlIDIsIGEgYmxvY2sgb2YgY29udGlndW91cyBYJ3MgYW5kIFkncyBy
ZXByZXNlbnQgDQphIHNpbmdsZSBjb3JydXB0aW9uIHBlcmlvZC4gIFRoZSBYJ3MgcmVwcmVzZW50
IGNvcnJ1cHRpb24gZHVlIHRvIGEgDQpsb3N0IG9yIGNvcnJ1cHRlZCBwYWNrZXRzLiAgVGhlIFkn
cyByZXByZXNlbnQgY29ycnVwdGlvbiBkdWUgdG8gDQpkZXBlbmRlbmNpZXMgb24gY29ycnVwdGVk
IFgncyAoZS5nLiwgdmlkZW8gUC1mcmFtZXMpLg0KDQogICAgICAgICArLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVmlkZW8gICAgfCAgICAg
ICAgICAgICAgICAgICAgICB8WFhZWVlZWVlZWXwgICAgICAgICAgICAgICANCiAgICAgICAgICst
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQog
ICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLQ0KQXVkaW8gICAgfCAgICAgIHxYfCAgICAgfFh8ICAgfFhYWHwNCiAgICAgICAgICst
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIA0K
ICAgICAgICAgfA0KUGxheWJhY2sgfC0tLS0tLS0tLXwtLS0tLS0tLS18LS0tLS0tLS0tfC0tLS0t
LS0tLXwtLS0tLS0tLS18LS0tLS0+IHQNClRpbWUgKHMpIDAgICAgICAgICAxICAgICAgICAgMiAg
ICAgICAgIDMgICAgICAgICA0ICAgICAgICAgNQ0KDQogICAgICAgICBGaWd1cmUgMi4gRXhhbXBs
ZSBBViBwcmVzZW50YXRpb24gd2l0aCBjb3JydXB0ZWQgcGxheWJhY2sNCg0KDQpBcyBtZW50aW9u
ZWQgaW4gWzJdIGVycm9ycyB0aGF0IGNhdXNlIGNvcnJ1cHRpb24gY2FuIGJlIGRldGVjdGVkIGlu
IA0KdHdvIHBsYWNlczoNCg0KLSBhdCB0aGUgQVZQIG1vZHVsZTogUGFja2V0IGRyb3AgYW5kIHBh
Y2tldCBlcnJvcnMgY2FuIHNvbWV0aW1lcyBiZSANCmRldGVjdGVkIGJ5IGluY29ycmVjdCBvciBt
aXNzaW5nIHNlcXVlbmNlIG51bWJlciBvciBjaGVja3N1bS4gDQpUaGUgQVZQIG1vZHVsZSByZWNv
cmRzIHRoZSBSVFAgdGltZXN0YW1wIG9mIHRoZSBSVFAgcGFja2V0IA0KY29udGFpbmluZyBhbiBl
cnJvciwgYW5kIG1hcmtzIHRoZSBkdXJhdGlvbiBvZiB0aGUgUlRQIHBhY2tldCANCmFzIGEgY29y
cnVwdGlvbi4gRHVyYXRpb24gb2YgYW4gUlRQIHBhY2tldCB2YXJpZXMgYWNjb3JkaW5nIHRvIA0K
Y29kZWMgYW5kIEFWUCBwcm9maWxlLg0KDQotIGF0IHRoZSBkZWNvZGVyIG1vZHVsZTogVGhlIGRl
Y29kZXIgY2FuIHNvbWV0aW1lcyBkZXRlY3QgYml0c3RyZWFtIA0KZXJyb3JzIHRoYXQgcmVzdWx0
IGluIGlsbGVnYWwgc3ludGF4IGZvciBydW4gbGVuZ3RoIGVuY29kaW5nLCANCkh1ZmZtYW4gdGFi
bGVzLCBSVkxDLCBldGMuIFRoZSBkZWNvZGVyIG1heSBvciBtYXkgbm90IGJlIGF3YXJlIA0Kb2Yg
UlRQIHRpbWVzdGFtcHMsIHRoZWlyIHJlbGF0aW9uc2hpcCB3aXRoIHRoZSANCm5vcm1hbCBwbGF5
IHRpbWUgKE5QVCksIG9yIHN5bmNocm9uaXphdGlvbiB3aXRoIG90aGVyIG1lZGlhIGRlY29kZXJz
Lg0KDQpJbiBzb21lIGNhc2VzLCB0aGUgZXJyb3JzIGRldGVjdGVkIGF0IHRoZSBuZXR3b3JrIGxl
dmVsIHdpbGwgbm90IGJlIA0KZGV0ZWN0ZWQgYXQgdGhlIGRlY29kZXIgbGV2ZWw7IGluIG90aGVy
IGNhc2VzIGVycm9ycyBkZXRlY3RlZCBhdCB0aGUgDQpkZWNvZGVyIGxldmVsIHdpbGwgbm90IGJl
IGRldGVjdGVkIGF0IHRoZSBuZXR3b3JrIGxldmVsLiAgSW4gZWl0aGVyIGNhc2UsIA0KdGhlIGxl
dmVsIHRoYXQgZGV0ZWN0cyB0aGUgZXJyb3Igd2lsbCBtYXJrIHRoZSB0aW1lbGluZSBmb3IgdGhh
dCBtZWRpYSANCnN0cmVhbSBhcyBjb3JydXB0ZWQuIEluIG90aGVyIGNhc2VzLCBhbiBlcnJvciBt
YXkgYmUgZGV0ZWN0ZWQgYnkgDQpib3RoIHRoZSBuZXR3b3JrIGFuZCBkZWNvZGVyIGxldmVscy4g
IEluIHN1Y2ggY2FzZSwgdG8gYmUgY29uc2VydmF0aXZlLCANCnRoZSB1bmlvbiBvZiB0aGUgY29y
cnVwdGlvbiBwZXJpb2RzIHdpbGwgYmUgbWFya2VkIG9uIHRoZSB0aW1lbGluZS4NCg0KVGhlIGZv
bGxvd2luZyBlcnJvcnMgY2FuIGJlIGRldGVjdGVkIGJ5IHRoZSBBVlAgbW9kdWxlIGFuZCByZXBv
cnRlZCANCmFzIGEgY29ycnVwdGlvbjoNCi0gcGFja2V0IGNvcnJ1cHRlZCAoZS5nLiwgY2hlY2tz
dW0gZmFpbGVkKQ0KLSBwYWNrZXQgZHJvcHBlZCAoZS5nLiwgc2VxdWVuY2UgbnVtYmVyIG1pc3Np
bmcpDQotIGZyYW1lIGluY29tcGxldGUgKGUuZy4sIHNlcXVlbmNlIG51bWJlciBtaXNzaW5nLCBS
VFAgbWFya2VyIGJpdCB1bnNldCkNCg0KDQoNCg0KVHNlbmcsIFNlY2tpbiAgICAgICBFeHBpcmVz
IEFwcmlsIDE5LCAyMDA0ICAgICAgICAgICAgICAgICAgICBbUGFnZSA1XQ0KDQpJbnRlcm5ldC1E
cmFmdCAgICAgICAgICAgUlRDUCBTdHJlYW1pbmcgWFIgICAgICAgICAgICAgICAgT2N0b2JlciAy
MDAzDQoNCg0KDQozLjMuMSBWaWRlbyBDb3JydXB0aW9ucw0KDQpUaGUgYXRvbWljIHVuaXQgb3Zl
ciB3aGljaCBhIGNvcnJ1cHRpb24gbWF5IGJlIGRldGVjdGVkIGF0IHRoZSBkZWNvZGVyIA0KbGV2
ZWwgaXMgYSB2aWRlbyBmcmFtZS4NCg0KVGhlIGJlZ2lubmluZyBvZiBjb3JydXB0aW9uIGlzIGRl
ZmluZWQgYXMgdGhlIHRpbWVzdGFtcCBvZiB0aGUgdmlkZW8gZnJhbWUgDQppbiB3aGljaCB0aGUg
ZXJyb3IgaXMgZGV0ZWN0ZWQuIEluIGdlbmVyYWwsIHRoZSBlbmQgb2YgY29ycnVwdGlvbiBpcyAN
CmRlZmluZWQgYXMgdGhlIHRpbWVzdGFtcCBvZiB0aGUgZmlyc3Qgc3Vic2VxdWVudCB2aWRlbyBm
cmFtZSB0aGF0IGlzIA0KZGVjb2RlZCBjb21wbGV0ZWx5IGFuZCBzdWNjZXNzZnVsbHkuIFRoZSBk
ZXRhaWxzIGFyZSBzcGVjaWZpYyB0byB0aGUgY29kZWMuDQoNCkZvciBNUEVHLTQsIEguMjYzLCBh
bmQgYWxsIG90aGVyIG1hY3JvYmxvY2sgYmFzZWQgY29kZWNzIHVubGVzcyANCm90aGVyd2lzZSBk
ZWZpbmVkOiBhIGNvbXBsZXRlbHkgYW5kIHN1Y2Nlc3NmdWxseSBkZWNvZGVkIEktZnJhbWUgYWx3
YXlzIA0KbWFya3MgdGhlIGVuZCBvZiBhIGNvcnJ1cHRpb24uICBJbiBhZGRpdGlvbiwgdGhlIGVu
ZCBvZiBhIGNvcnJ1cHRpb24gaXMgYWxzbyANCm1hcmtlZCBieSBhIHZpZGVvIGZyYW1lIGZvciB3
aGljaCBhbGwgY29ycnVwdGVkIGFyZWFzIG9mIHRoZSB2aWRlbyBmcmFtZSANCmFyZSBrbm93biB0
byBoYXZlIGJlZW4gcmVwbGFjZWQgYnkgc3VjY2Vzc2Z1bGx5IGFuZCBjb21wbGV0ZWx5IGRlY29k
ZWQgDQpJLW1hY3JvYmxvY2tzLg0KDQpXaGVuZXZlciBhIGNvcnJ1cHRpb24gZG9lcyBub3QgZW5k
IGJlZm9yZSB0aGUgZW5kIG9mIGFuIFhSIHJlcG9ydGluZyBwZXJpb2QsDQogdGhlIFhSIHJlcG9y
dCBibG9jayBTSEFMTCByZXBvcnQgdGhlIGVuZCBvZiBjb3JydXB0aW9uIGFzIHRoZSBlbmQgdGlt
ZSANCm9mIHRoZSBYUiByZXBvcnRpbmcgcGVyaW9kLiAgVGhlIGJlZ2lubmluZyBvZiB0aGUgbmV4
dCBYUiByZXBvcnQgYmxvY2sgDQpTSEFMTCBtYXJrIHRoZSBiZWdpbm5pbmcgb2YgYSBuZXcgY29y
cnVwdGlvbiBkdXJhdGlvbi4NCg0KV2hlbmV2ZXIgYSBjb3JydXB0aW9uIGRvZXMgbm90IGVuZCBi
ZWZvcmUgdGhlIGVuZCBvZiBwbGF5YmFjaywgdGhlIA0KWFIgcmVwb3J0IGJsb2NrIFNIQUxMIHJl
cG9ydCB0aGUgZW5kIG9mIGNvcnJ1cHRpb24gYXMgdGhlIGVuZCB0aW1lIG9mIA0KcGxheWJhY2su
DQoNCg0KUG90ZW50aWFsIHJlcG9ydGluZyBlcnJvcnM6DQoNCkl0IGlzIHBvc3NpYmxlIHRoYXQg
dGhlIHZpZGVvIGRlY29kZXIgY29tcGxldGVseSBkZWNvZGVzIGEgZnJhbWUgd2l0aCANCmEgYml0
IGVycm9yLiAgVGhpcyByZXN1bHRzIGluIGEgZmFsc2UgbmVnYXRpdmUsIGluIHdoaWNoIHRoZSB1
c2VyIA0KYWN0dWFsbHkgcGVyY2VpdmVzIGNvcnJ1cHRlZCB2aWRlbywgYnV0IHRoZSBhcHBsaWNh
dGlvbiByZXBvcnRzIHRoZSANCmVuZCBvZiBhIGNvcnJ1cHRpb24gcGVyaW9kLCBvciBubyBjb3Jy
dXB0aW9uIGF0IGFsbC4gIFRoaXMgcHJvYmxlbSBtYXkgDQpiZSBwcmV2ZW50ZWQgaWYgdGhlIGJp
dCBlcnJvciBpcyBkZXRlY3RlZCBhdCB0aGUgQVZQIG1vZHVsZS4NCg0KSXQgaXMgYWxzbyBwb3Nz
aWJsZSB0aGF0IGEgYml0IGVycm9yIHdpbGwgcmVzdWx0IGluIGEgZGVmZXJyZWQgZXJyb3IsIA0K
aW4gd2hpY2ggYW4gYWN0dWFsIGVycm9yIGNhdXNlcyBkZWNvZGluZyB0byBmYWlsIGluIHRoZSBj
dXJyZW50IGZyYW1lLCANCmJ1dCB0aGUgZGVjb2RlciBkb2VzIG5vdCBkZXRlY3QgaXQgdW50aWwg
dGhlIHN1YnNlcXVlbnQgZnJhbWUuIEluIHRoaXMgDQpjYXNlLCB0aGUgZGVjb2RlciByZXBvcnRz
IHRoZSBiZWdpbm5pbmcgb2YgY29ycnVwdGlvbiBwZXJpb2QgdG8gYmUgDQpsYXRlciB0aGFuIHRo
ZSB1c2VyIGFjdHVhbGx5IHBlcmNlaXZlcy4gT25jZSBhZ2FpbiwgZGV0ZWN0aW5nIHRoZSBlcnJv
ciANCmF0IHRoZSBBVlAgbW9kdWxlIHJlZHVjZXMgdGhlIGNoYW5jZXMgb2YgYSBmYWxzZSBuZWdh
dGl2ZSByZXBvcnQuDQoNCjIuMy4yIEF1ZGlvIENvcnJ1cHRpb25zDQoNClRoZSBhdG9taWMgdW5p
dCBvdmVyIHdoaWNoIGFuIGF1ZGlvIGNvcnJ1cHRpb24gY2FuIGJlIGRldGVjdGVkIGF0IHRoZSAN
CmRlY29kZXIgbGV2ZWwgaXMgYW4gYXVkaW8gZnJhbWUuIEZvciB0aGUgY2FzZSBvZiBQQ00gYXVk
aW8sIGFuIGF1ZGlvIA0KZnJhbWUgaXMgZGVmaW5lZCBhcyBhIHNpbmdsZSBzYW1wbGUuIA0KDQpU
c2VuZywgU2Vja2luICAgICAgIEV4cGlyZXMgQXByaWwgMTksIDIwMDQgICAgICAgICAgICAgICAg
ICAgIFtQYWdlIDZdDQoNCkludGVybmV0LURyYWZ0ICAgICAgICAgICBSVENQIFN0cmVhbWluZyBY
UiAgICAgICAgICAgICAgICBPY3RvYmVyIDIwMDMNCg0KDQoNCk9wdGlvbmFsbHksIGFueSBhdWRp
byBjb2RlYyBtYXkgaW5zdGVhZCByZXBvcnQgYXVkaW8gY29ycnVwdGlvbiBwZXJpb2RzIA0Kd2l0
aCBhIHJlc29sdXRpb24gb2Ygb25lIHNhbXBsZS4gTm90ZSBob3dldmVyLCB0aGF0IHRoZSBYUiBi
bG9jayANCnJlcG9ydHMgUlRQIHRpbWVzdGFtcHMgaW4gdGhlIFJUUCB0aW1lYmFzZTsgdGhlcmVm
b3JlLCB0aGUgYWN0dWFsIFhSIA0KcmVwb3J0cyBtYXkgYmUgbGltaXRlZCBpbiB0aW1lIHJlc29s
dXRpb24uDQoNClRoZSBiZWdpbm5pbmcgb2YgY29ycnVwdGlvbiBpcyBkZWZpbmVkIGFzIHRoZSB0
aW1lc3RhbXAgb2YgdGhlIGF1ZGlvIA0KZnJhbWUgaW4gd2hpY2ggdGhlIGVycm9yIGlzIGRldGVj
dGVkLiBJbiBnZW5lcmFsLCB0aGUgZW5kIG9mIGNvcnJ1cHRpb24gDQppcyBkZWZpbmVkIGFzIHRo
ZSB0aW1lc3RhbXAgb2YgdGhlIGZpcnN0IHN1YnNlcXVlbnQgYXVkaW8gZnJhbWUgdGhhdCANCmlz
IGRlY29kZWQgY29tcGxldGVseSBhbmQgc3VjY2Vzc2Z1bGx5LiBUaGUgZGV0YWlscyBhcmUgc3Bl
Y2lmaWMgdG8gDQp0aGUgY29kZWMuDQoNCkZvciBBQUMsIE1QMywgRVZSQywgQU1SLCBBTVItV0Ig
YW5kIG90aGVyIGZyYW1lLWJhc2VkIHN1YmJhbmQgYXVkaW8gDQpjb21wcmVzc2lvbiBvciB2b2lj
ZS1jb2RlYyB1bmxlc3Mgb3RoZXJ3aXNlIGRlZmluZWQ6IGFueSBhdWRpbyBmcmFtZSANCnRoYXQg
Y2FuIG5vdCBiZSBzdWNjZXNzZnVsbHkgZGVjb2RlZCBkdWUgdG8gZGVwZW5kZW5jaWVzIG9uIG90
aGVyIA0KYXVkaW8gZnJhbWVzIHRoYXQgaGF2ZSBiZWVuIGNvcnJ1cHRlZCwgKGUuZy4sIGZyYW1l
cyB1c2luZyANCkFBQyBMVFAgdG9vbCwgb3IgTVAzIGZyYW1lcyB3aXRoIGJhY2sgcG9pbnRlcnMp
IGFyZSBjb25zaWRlcmVkIGluIGVycm9yLg0KDQpXaGVuZXZlciBhIGNvcnJ1cHRpb24gZG9lcyBu
b3QgZW5kIGJlZm9yZSB0aGUgZW5kIG9mIGFuIFhSIHJlcG9ydGluZyANCnBlcmlvZCwgdGhlIFhS
IHJlcG9ydCBibG9jayBTSEFMTCByZXBvcnQgdGhlIGVuZCBvZiBjb3JydXB0aW9uIGFzIHRoZSAN
CmVuZCB0aW1lIG9mIHRoZSBYUiByZXBvcnRpbmcgcGVyaW9kLiAgVGhlIGJlZ2lubmluZyBvZiB0
aGUgbmV4dCBYUiANCnJlcG9ydCBibG9jayBTSEFMTCBtYXJrIHRoZSBiZWdpbm5pbmcgb2YgYSBu
ZXcgY29ycnVwdGlvbiBkdXJhdGlvbi4NCg0KV2hlbmV2ZXIgYSBjb3JydXB0aW9uIGRvZXMgbm90
IGVuZCBiZWZvcmUgdGhlIGVuZCBvZiBwbGF5YmFjaywgDQp0aGUgWFIgcmVwb3J0IGJsb2NrIFNI
QUxMIHJlcG9ydCB0aGUgZW5kIG9mIGNvcnJ1cHRpb24gYXMgdGhlIGVuZCANCnRpbWUgb2YgcGxh
eWJhY2suDQoNClBvdGVudGlhbCByZXBvcnRpbmcgZXJyb3JzOg0KDQpJdCBpcyBwb3NzaWJsZSB0
aGF0IHRoZSBhdWRpbyBkZWNvZGVyIGNvbXBsZXRlbHkgZGVjb2RlcyBhIGZyYW1lIHdpdGggDQph
IGJpdCBlcnJvci4gIFRoaXMgcmVzdWx0cyBpbiBhIGZhbHNlIG5lZ2F0aXZlLCBpbiB3aGljaCB0
aGUgdXNlciANCmFjdHVhbGx5IHBlcmNlaXZlcyBjb3JydXB0ZWQgYXVkaW8sIGJ1dCB0aGUgcGxh
eWVyIHJlcG9ydHMgdGhlIGVuZCANCm9mIGEgY29ycnVwdGlvbiBwZXJpb2QsIG9yIG5vIGNvcnJ1
cHRpb24gYXQgYWxsLiAgVGhpcyBwcm9ibGVtIG1heSANCmJlIGFsbGV2aWF0ZWQgaWYgdGhlIGJp
dCBlcnJvciBpcyBkZXRlY3RlZCBhdCB0aGUgQVZQIG1vZHVsZS4NCg0KDQpJdCBpcyBhbHNvIHBv
c3NpYmxlIHRoYXQgYSBiaXQgZXJyb3Igd2lsbCByZXN1bHQgaW4gYSBkZWZlcnJlZCBlcnJvciAN
CmluIHdoaWNoIGFuIGFjdHVhbCBlcnJvciBjYXVzZXMgZGVjb2RpbmcgdG8gZmFpbCBpbiB0aGUg
Y3VycmVudCBmcmFtZSwNCmJ1dCB0aGUgZGVjb2RlciBkb2VzIG5vdCBkZXRlY3QgaXQgdW50aWwg
dGhlIHN1YnNlcXVlbnQgZnJhbWUuIA0KSW4gdGhpcyBjYXNlLCB0aGUgZGVjb2RlciByZXBvcnRz
IHRoZSBiZWdpbm5pbmcgb2YgY29ycnVwdGlvbiBwZXJpb2QgDQp0byBiZSBsYXRlciB0aGFuIHRo
ZSB1c2VyIGFjdHVhbGx5IHBlcmNlaXZlcy4gT25jZSBhZ2FpbiwgZGV0ZWN0aW5nIA0KdGhlIGVy
cm9yIGF0IHRoZSBBVlAgbW9kdWxlIHJlZHVjZXMgdGhlIGNoYW5jZXMgb2YgYSBmYWxzZSBuZWdh
dGl2ZSANCnJlcG9ydC4NCg0KMy40IFJlLWJ1ZmZlcmluZw0KDQpSZS1idWZmZXJpbmcgaXMgZGVm
aW5lZCBhcyBhbnkgc3RhbGwgaW4gcGxheSB0aW1lIGR1ZSB0byBhbnkgaW52b2x1bnRhcnkNCmV2
ZW50IGF0IHRoZSBjbGllbnQgc2lkZS4NCg0KDQoNCg0KVHNlbmcsIFNlY2tpbiAgICAgICBFeHBp
cmVzIEFwcmlsIDE5LCAyMDA0ICAgICAgICAgICAgICAgICAgICBbUGFnZSA3XQ0KDQpJbnRlcm5l
dC1EcmFmdCAgICAgICAgICAgUlRDUCBTdHJlYW1pbmcgWFIgICAgICAgICAgICAgICAgT2N0b2Jl
ciAyMDAzDQoNCkEgc3RyZWFtaW5nIG11bHRpbWVkaWEgcGxheWVyIGFwcGxpY2F0aW9uIHR5cGlj
YWxseSBiZWdpbnMgcGxheWJhY2sgDQpvbmx5IGFmdGVyIGFjY3VtdWxhdGluZyBhIGJ1ZmZlciBv
ZiBkYXRhIGZyb20gd2hpY2ggdG8gYmVnaW4gcGxheWJhY2suICANCklmIHRoaXMgYnVmZmVyIHVu
ZGVyZmxvd3MgKGUuZy4sIGR1ZSB0byBuZXR3b3JrIGNvbmdlc3Rpb24pIHRoZSBwbGF5ZXIgDQph
cHBsaWNhdGlvbiB0eXBpY2FsbHkgcGF1c2VzIHBsYXliYWNrIHVudGlsIHRoZSBidWZmZXIgY2Fu
IGJlDQpzdWZmaWNpZW50bHkgcmVmaWxsZWQgdG8gcmVzdW1lIHBsYXliYWNrLg0KDQpTdWNoIGFu
IGludGVycnVwdGlvbiBpbiBwbGF5YmFjayBuZWdhdGl2ZWx5IGFmZmVjdHMgdXNlciBleHBlcmll
bmNlIA0KYW5kIFNIQUxMIGJlIHJlcG9ydGVkIGluIHRoZSBYUiBwYWNrZXQuDQotIEJ1ZmZlciB1
bmRlcmZsb3c6IGRlY29kZXIgY29uc3VtZXMgZGF0YSBhdCBhIGZhc3RlciByYXRlIHRoYW4gDQpi
dWZmZXIgaXMgZmlsbGVkLg0KDQpDZXJ0YWluIGludGVycnVwdGlvbnMgaW4gcGxheWJhY2sgYXJl
IHNwZWNpZmljYWxseSBleGNsdWRlZCBmcm9tIA0KcmVwb3J0aW5nLg0KLSBVc2VyIGludGVudGlv
bmFsbHkgcGF1c2VzIHBsYXliYWNrLg0KDQpJbiBhZGRpdGlvbiwgd2hlbmV2ZXIgYSByZWJ1ZmZl
cmluZyBwZXJpb2QgZG9lcyBub3QgZW5kIGJlZm9yZSB0aGUgDQplbmQgb2YgYW4gWFIgcmVwb3J0
aW5nIHBlcmlvZCwgdGhlIFhSIHJlcG9ydCBibG9jayBTSEFMTCByZXBvcnQgdGhlIA0KZW5kIG9m
IHJlYnVmZmVyaW5nIHBlcmlvZCBhcyB0aGUgZW5kIHRpbWUgb2YgdGhlIFhSIHJlcG9ydGluZyBw
ZXJpb2QuDQpUaGUgYmVnaW5uaW5nIG9mIHRoZSBuZXh0IFhSIHJlcG9ydCBibG9jayBTSEFMTCBt
YXJrIHRoZSBiZWdpbm5pbmcgb2YgYSANCm5ldyByZWJ1ZmZlcmluZyBwZXJpb2QuDQoNCldoZW5l
dmVyIGEgcmVidWZmZXJpbmcgZG9lcyBub3QgZW5kIGJlZm9yZSB0aGUgZW5kIG9mIHBsYXliYWNr
LCB0aGUgWFIgDQpyZXBvcnQgYmxvY2sgU0hBTEwgcmVwb3J0IHRoZSBlbmQgb2YgY29ycnVwdGlv
biBhcyB0aGUgZW5kIHRpbWUgDQpvZiBwbGF5YmFjay4NCg0KMy41IFBlciBtZWRpYSByZXBvcnRp
bmcNCg0KRWFjaCBvZiB0aGVzZSBtZXRyaWNzIGlzIHJlY29yZGVkIG9uIGluZGVwZW5kZW50IHRp
bWVsaW5lcyBmb3IgZWFjaCANCmluZGl2aWR1YWwgbWVkaWEuICANCg0KNC4gU3RyZWFtaW5nIFJl
cG9ydCBCbG9jayBmb3IgWFIgUGFja2V0cw0KDQpBbiBSVENQIFhSIHBhY2tldCBoZWFkZXIgaXMg
ZGVmaW5lZCBhcyBpbiBbMV0sIGFzIGZvbGxvd3M6DQogICAgMCAgICAgICAgICAgICAgICAgICAx
ICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMw0KICAgIDAgMSAyIDMgNCA1
IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KICAg
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSsNCiAgIHxWPTJ8UHxyZXNlcnZlZCB8ICAgUFQ9WFI9MjA3ICAgfCAgICAgICAgICAg
ICBsZW5ndGggICAgICAgICAgICB8DQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgfCAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIFNTUkMgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rDQogICB8ICAgICAgICAgICAgICAgICAgICAgICAgIHJlcG9ydCBibG9ja3MgICAgICAgICAg
ICAgICAgICAgICAgICAgfA0KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgIEZpZ3VyZSAzLiBSVENQIFhSIGhlYWRl
ciBbMV0NCg0KDQogIHZlcnNpb24gKFYpOiAyIGJpdHMNCiAgICAgICAgSWRlbnRpZmllcyB0aGUg
dmVyc2lvbiBvZiBSVFAuICBUaGlzIHNwZWNpZmljYXRpb24gYXBwbGllcyB0bw0KICAgICAgICBS
VFAgdmVyc2lvbiB0d28uDQoNCg0KDQoNCg0KDQpUc2VuZywgU2Vja2luICAgICAgIEV4cGlyZXMg
QXByaWwgMTksIDIwMDQgICAgICAgICAgICAgICAgICAgIFtQYWdlIDhdDQpJbnRlcm5ldC1EcmFm
dCAgICAgICAgICAgUlRDUCBTdHJlYW1pbmcgWFIgICAgICAgICAgICAgICAgT2N0b2JlciAyMDAz
DQoNCg0KICAgcGFkZGluZyAoUCk6IDEgYml0DQogICAgICAgIElmIHRoZSBwYWRkaW5nIGJpdCBp
cyBzZXQsIHRoaXMgWFIgcGFja2V0IGNvbnRhaW5zIHNvbWUNCiAgICAgICAgYWRkaXRpb25hbCBw
YWRkaW5nIG9jdGV0cyBhdCB0aGUgZW5kLg0KDQogICByZXNlcnZlZDogNSBiaXRzDQogICAgICAg
IFRoaXMgZmllbGQgaXMgcmVzZXJ2ZWQgZm9yIGZ1dHVyZSBkZWZpbml0aW9uLiBJbiB0aGUgYWJz
ZW5jZSANCiAgICAgICAgb2Ygc3VjaCBkZWZpbml0aW9uLCB0aGUgYml0cyBpbiB0aGlzIGZpZWxk
IE1VU1QgYmUgc2V0IHRvDQogICAgICAgIHplcm8gYW5kIE1VU1QgYmUgaWdub3JlZCBieSB0aGUg
cmVjZWl2ZXIuDQoNCiAgIHBhY2tldCB0eXBlIChQVCk6IDggYml0cw0KICAgICAgICBDb250YWlu
cyB0aGUgY29uc3RhbnQgMjA3IHRvIGlkZW50aWZ5IHRoaXMgYXMgYW4gUlRDUCANCiAgICAgICAg
WFIgcGFja2V0Lg0KDQogICBsZW5ndGg6IDE2IGJpdHMNCiAgICAgICAgQXMgZGVmaW5lZCBpbiBT
ZWN0aW9uIDMgaW4gWzFdLg0KDQogICBTU1JDOiAzMiBiaXRzDQogICAgICAgIFRoZSBzeW5jaHJv
bml6YXRpb24gc291cmNlIGlkZW50aWZpZXIgZm9yIHRoZSBvcmlnaW5hdG9yIG9mIA0KICAgICAg
ICB0aGlzIFhSIHBhY2tldC4NCg0KICAgcmVwb3J0IGJsb2NrczogdmFyaWFibGUgbGVuZ3RoLg0K
ICAgICAgICBaZXJvIG9yIG1vcmUgZXh0ZW5kZWQgcmVwb3J0IGJsb2Nrcy4gIEluIGtlZXBpbmcg
d2l0aCB0aGUNCiAgICAgICAgZXh0ZW5kZWQgcmVwb3J0IGJsb2NrIGZyYW1ld29yayBkZWZpbmVk
IGluIFsxXSwgZWFjaCBibG9jayANCiAgICAgICAgTVVTVCBjb25zaXN0IG9mIG9uZSBvciBtb3Jl
IDMyLWJpdCB3b3Jkcy4NCiAgICANClRoZSBzdHJlYW1pbmcgcmVwb3J0IGJsb2NrIGlzIGRlZmlu
ZWQgYXMgZm9sbG93czoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN
Cg0KDQoNCg0KDQoNClRzZW5nLCBTZWNraW4gICAgICAgRXhwaXJlcyBBcHJpbCAxOSwgMjAwNCAg
ICAgICAgICAgICAgICAgICAgW1BhZ2UgOV0NCkludGVybmV0LURyYWZ0ICAgICAgICAgICBSVENQ
IFN0cmVhbWluZyBYUiAgICAgICAgICAgICAgICBPY3RvYmVyIDIwMDMNCg0KDQoNCiAgICAwICAg
ICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAz
DQogICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1
IDYgNyA4IDkgMCAxDQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgfCAgICAgQlQ9OCAgICAgIHxDfER8TnxSfCBy
c3ZkLiB8ICAgICAgIGJsb2NrIGxlbmd0aCAgICAgICAgICAgIHwNCiAgICstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICB8
ICAgCQkgICAgICAgIFN0YXJ0aW5nIFBUUyAgKHB0c19zdGFydCkgICAgICAgICAgICAgICAgfA0K
ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSsNCiAgIHwgICAJCSAgICAgICAgICBFbmRpbmcgUFRTICAocHRzX3N0b3ApICAg
ICAgICAgICAgICAgICB8DQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgfCAgIAkgICBudW1fY29yICAgICAgICAg
ICAgIHwgICAgICAgICAgIG51bV9yZWJ1ZiAgICAgICAgICAgfA0KICAgKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgIHwg
ICAJICAgICAgICAgICAgICAgICAgbWluX2R1cl9jb3IgICAgICAgICAgICAgICAgICAgICAgICAg
IHwNCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rDQogICB8ICAgCSAgICAgICAgICAgICAgICAgIG1heF9kdXJfY29yICAg
ICAgICAgICAgICAgICAgICAgICAgICB8DQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgfCAgIAkgICAgICAgICAg
ICAgICAgICBhdmdfZHVyX2NvciAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSsNCiAgIHwgICAJICAgICAgICAgICAgICAgICAgc3RkX2R1cl9jb3IgICAgICAgICAgICAgICAg
ICAgICAgICAgIHwNCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICB8ICAgCSAgICAgICAgICAgICAgICAgbWF4X2R1
cl9yZWJ1ZiAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICArLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgfCAgIAkg
ICAgICAgICAgICAgICAgIG1pbl9kdXJfcmVidWYgICAgICAgICAgICAgICAgICAgICAgICAgfA0K
ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSsNCiAgIHwgICAJICAgICAgICAgICAgICAgICBhdmdfZHVyX3JlYnVmICAgICAg
ICAgICAgICAgICAgICAgICAgIHwNCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICB8ICAgCSAgICAgICAgICAgICAg
ICAgc3RkX2R1cl9yZWJ1ZiAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICArLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0K
ICAgIEZpZ3VyZSA0LiBzdHJlYW1pbmcgcmVwb3J0IGJsb2NrDQoNCiAgIFRoZSBibG9jayBpcyBl
bmNvZGVkIGFzIHR3ZWx2ZSAzMi1iaXQgd29yZHM6DQoNCiAgIGJsb2NrIHR5cGUgKEJUKTogOCBi
aXRzDQogICAgICAgIEEgc3RyZWFtaW5nIG1ldHJpY3MgcmVwb3J0IGJsb2NrIGlzIGlkZW50aWZp
ZWQgYnkgdGhlIGNvbnN0YW50IDguDQoNCiAgIE51bWJlciBvZiBDb3JydXB0aW9ucyBGbGFnIChD
KTogMSBiaXQNCg0KICAgRHVyYXRpb24gb2YgQ29ycnVwdGlvbnMgRmxhZyAoRCk6IDEgYml0DQoN
CiAgIE51bWJlciBvZiB0aW1lcyBQbGF5ZXIgUmUtYnVmZmVyZWQgRmxhZyAoTik6IDEgYml0DQoN
CiAgIER1cmF0aW9uIG9mIFBsYXllciBSZS1idWZmZXJpbmcgRmxhZyAoUik6IDEgYml0DQoNCiAg
IHJlc2VydmVkOiA0IGJpdHMNCiAgICAgICAgVGhpcyBmaWVsZCBpcyByZXNlcnZlZCBmb3IgZnV0
dXJlIGRlZmluaXRpb24uICBJbiB0aGUgYWJzZW5jZSANCiAgICAgICAgb2Ygc3VjaCBkZWZpbml0
aW9uLCB0aGUgYml0cyBpbiB0aGlzIGZpZWxkIE1VU1QgYmUgc2V0IHRvIHplcm8NCiAgICAgICAg
YW5kIE1VU1QgYmUgaWdub3JlZCBieSB0aGUgcmVjZWl2ZXIuDQoNCg0KDQoNClRzZW5nLCBTZWNr
aW4gICAgICBFeHBpcmVzIEFwcmlsIDE5LCAyMDA0ICAgICAgICAgICAgICAgICAgICBbUGFnZSAx
MF0NCg0KDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgUlRDUCBTdHJlYW1pbmcgWFIgICAgICAg
ICAgICAgICAgT2N0b2JlciAyMDAzDQoNCg0KDQogICBibG9jayBsZW5ndGg6IDE2IGJpdHMNCiAg
ICAgICAgQXMgZGVmaW5lZCBpbiBTZWN0aW9uIDMgaW4gWzFdLg0KDQogICBwdHNfc3RhcnQ6IDMy
IGJpdA0KICAgICAgIFRoZSBSVFAgdGltZXN0YW1wIHRoYXQgbWFya3MgdGhlIGJlZ2lubmluZyBv
ZiB0aGUgZHVyYXRpb24NCiAgICAgICBiZWluZyByZXBvcnRlZC4NCg0KICAgcHRzX3N0b3A6IDMy
IGJpdA0KICAgICAgIFRoZSBSVFAgdGltZXN0YW1wIHRoYXQgbWFya3MgdGhlIGJlZ2lubmluZyBv
ZiB0aGUgZHVyYXRpb24gDQogICAgICAgYmVpbmcgcmVwb3J0ZWQuDQoNCiAgIG51bV9jb3I6IDE2
IGJpdHMNCiAgICAgICBUaGUgbnVtYmVyIG9mIGNvcnJ1cHRpb24gcGVyaW9kcyBpbiB0aGlzIHJl
cG9ydGluZyBwZXJpb2QuDQoNCiAgIG51bV9yZWJ1ZjogMTYgYml0cw0KICAgICAgIFRoZSBudW1i
ZXIgb2YgcmVidWZmZXJpbmcgcGVyaW9kcyBpbiB0aGlzIHJlcG9ydGluZyBwZXJpb2QuDQoNCiAg
IG1pbl9kdXJfY29yOiAzMiBiaXRzDQogICAgICAgVGhlIG1pbmltdW0gZHVyYXRpb24gb2YgYSBj
b3JydXB0aW9uIHBlcmlvZCBkdXJpbmcgdGhpcyANCiAgICAgICByZXBvcnRpbmcgcGVyaW9kLiBV
bml0cyBhcmUgaW4gdGltZWJhc2Ugb2YgdGhlIFJUUCB0aW1lc3RhbXAuDQoNCiAgIG1heF9kdXJf
Y29yOiAzMiBiaXRzDQogICAgICAgVGhlIG1heGltdW0gZHVyYXRpb24gb2YgYSBjb3JydXB0aW9u
IHBlcmlvZCBkdXJpbmcgdGhpcyANCiAgICAgIHJlcG9ydGluZyBwZXJpb2QuIFVuaXRzIGFyZSBp
biB0aW1lYmFzZSBvZiB0aGUgUlRQIHRpbWVzdGFtcC4NCg0KICAgYXZnX2R1cl9jb3I6IDMyIGJp
dHMNCiAgICAgICBUaGUgYXZlcmFnZSBkdXJhdGlvbiBvZiBhIGNvcnJ1cHRpb24gcGVyaW9kIGR1
cmluZyB0aGlzIA0KICAgICAgIHJlcG9ydGluZyBwZXJpb2QuIFVuaXRzIGFyZSBpbiB0aW1lYmFz
ZSBvZiB0aGUgUlRQIHRpbWVzdGFtcC4NCg0KICAgc3RkX2R1cl9jb3I6IDMyIGJpdHMNCiAgICAg
ICBUaGUgc3RhbmRhcmQgZGV2aWF0aW9uIG9mIHRoZSBkdXJhdGlvbiBvZiBhIGNvcnJ1cHRpb24g
cGVyaW9kDQogICAgICAgZHVyaW5nIHRoaXMgcmVwb3J0aW5nIHBlcmlvZC4gIFVuaXRzIGFyZSBp
biB0aGUgc3F1YXJlIG9mIHRoZQ0KICAgICAgIHRpbWViYXNlIG9mIHRoZSBSVFAgdGltZXN0YW1w
LiBUaGlzIHZhbHVlIGlzIGEgc2luZ2xlDQogICAgICAgcHJlY2lzaW9uIGZsb2F0aW5nIHBvaW50
IG51bWJlciwgYWNjb3JkaW5nIHRvIHRoZSBJRUVFIDc1NA0KICAgICAgIHN0YW5kYXJkIChGaWd1
cmUgNSkuDQoNCiAgICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAg
ICAgICAgICAgICAgICAgICAzDQogICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2
IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxDQogICArLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgfFN8ICAgZXhw
b25lbnQgICAgfCAgICAgICAgICAgICAgbWFudGlzc2EgICAgICAgICAgICAgICAgICAgICAgIHwN
CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rDQogICBGaWd1cmUgNS4gRmxvYXRpbmctcG9pbnQgZm9ybWF0IGZvciBzdGFu
ZGFyZCBkZXZpYXRpb24uIA0KDQogICBTOiAxIGJpdA0KICAgICAgU2lnbiBiaXQgKDA9cG9zaXRp
dmUsIDE9bmVnYXRpdmUpLiAgTm90ZTogZm9yIHN0YW5kYXJkIGRldmlhdGlvbiANCiAgICAgIHRo
aXMgaXMgYWx3YXlzIHBvc2l0aXZlLg0KDQoNCg0KDQoNCg0KVHNlbmcsIFNlY2tpbiAgICAgIEV4
cGlyZXMgQXByaWwgMTksIDIwMDQgICAgICAgICAgICAgICAgICAgIFtQYWdlIDExXQ0KSW50ZXJu
ZXQtRHJhZnQgICAgICAgICAgIFJUQ1AgU3RyZWFtaW5nIFhSICAgICAgICAgICAgICAgIE9jdG9i
ZXIgMjAwMw0KDQoNCiAgIA0KICAgRXhwb25lbnQ6IDggYml0cw0KICAgICAgRXhwb25lbnQsIHdp
dGggYmlhcyBvZiAxMjcuDQoNCiAgIE1hbnRpc3NhOiAyMyBiaXRzDQogICAgICAgTWFudGlzc2Eu
DQoNCiAgIG1pbl9kdXJfcmVidWY6IDMyIGJpdHMNCiAgICAgIFRoZSBtaW5pbXVtIGR1cmF0aW9u
IG9mIGEgcmVidWZmZXJpbmcgcGVyaW9kIGR1cmluZyB0aGlzIA0KICAgICAgcmVwb3J0aW5nIHBl
cmlvZC4gVW5pdHMgYXJlIGluIHRpbWViYXNlIG9mIHRoZSBSVFAgdGltZXN0YW1wLg0KDQoNCg0K
ICAgbWF4X2R1cl9yZWJ1ZjogMzIgYml0cw0KICAgICAgIFRoZSBtYXhpbXVtIGR1cmF0aW9uIG9m
IGEgcmVidWZmZXJpbmcgcGVyaW9kIGR1cmluZyB0aGlzIA0KICAgICAgIHJlcG9ydGluZyBwZXJp
b2QuIFVuaXRzIGFyZSBpbiB0aW1lYmFzZSBvZiB0aGUgUlRQIHRpbWVzdGFtcC4NCg0KICAgYXZn
X2R1cl9yZWJ1ZjogMzIgYml0cw0KICAgICAgVGhlIGF2ZXJhZ2UgZHVyYXRpb24gb2YgYSByZWJ1
ZmZlcmluZyBwZXJpb2QgZHVyaW5nIHRoaXMgDQogICAgICByZXBvcnRpbmcgcGVyaW9kLiBVbml0
cyBhcmUgaW4gdGltZWJhc2Ugb2YgdGhlIFJUUCB0aW1lc3RhbXAuDQoNCiAgIHN0ZF9kdXJfcmVi
dWY6IDMyIGJpdHMNCiAgICAgIFRoZSBzdGFuZGFyZCBkZXZpYXRpb24gb2YgdGhlIGR1cmF0aW9u
IG9mIGEgcmVidWZmZXJpbmcgcGVyaW9kIA0KICAgICAgZHVyaW5nIHRoaXMgcmVwb3J0aW5nIHBl
cmlvZC4gIFVuaXRzIGFyZSBpbiB0aGUgc3F1YXJlIG9mIHRoZSANCiAgICAgIHRpbWViYXNlIG9m
IHRoZSBSVFAgdGltZXN0YW1wLiBUaGlzIHZhbHVlIGlzIGEgc2luZ2xlIHByZWNpc2lvbg0KICAg
ICAgZmxvYXRpbmcgcG9pbnQgbnVtYmVyLCBhY2NvcmRpbmcgdG8gdGhlIA0KICAgICAgSUVFRSA3
NTQgc3RhbmRhcmQgKEZpZ3VyZSA1KS4NCg0KNS4gU3RyZWFtaW5nIFJlcG9ydCBCbG9jayBJbnRl
cnZhbA0KDQpYUiByZXBvcnQgYmxvY2tzIG5lZWQgbm90IHRvIGJlIHNlbnQgaW4gZWFjaCBSVENQ
IHBhY2tldC4gIA0KVGhlcmVmb3JlLCB0aGUgaW50ZXJ2YWwgYmV0d2VlbiBzZXF1ZW50aWFsIFhS
IHJlcG9ydCBibG9ja3MgbWF5IGV4Y2VlZCANCnRoZSBpbnRlcnZhbCBiZXR3ZWVuIHNlcXVlbnRp
YWwgUlRDUCBwYWNrZXRzLiBJdCBpcyB0aGUgcmVjZWl2ZXJzIA0KcmVzcG9uc2liaWxpdHkgdG8g
dXNlIHRoZSBzdGF0aXN0aWNzIGZvciB0aGUgc3BlY2lmaWVkIGludGVydmFsIA0KaW4gdGhlIHJl
cG9ydCBibG9ja3MuDQoNCjYuIFRoZSBTRFAgYXR0cmlidXRlDQoNClRoZSB1c2FnZSBvZiBTRFAg
aXMgYXMgc3BlY2lmaWVkIGluIHNlY3Rpb24gNSBpbiBbMV0uIA0KQW4gcnRjcC14ci1hdHJpYiBp
cyBkZWZpbmVkIGZvciBzdHJlYW1pbmcgbWV0cmljcyBhcyBmb2xsb3dzOg0KDQpydGNwLXhyLWF0
dHJpYiA9ICJhPSIgInJ0Y3AteHIiICI6IiBbeHItZm9ybWF0ICooU1AgeHItZm9ybWF0KV0gQ1JM
Rg0KeHItZm9ybWF0ID0gc3RyZWFtaW5nLW1ldHJpY3MNCnN0cmVhbWluZy1tZXRyaWNzICAgPSAi
c3RyZWFtaW5nLW1ldHJpY3MiDQoNCg0KDQoNCg0KDQoNCg0KDQpUc2VuZywgU2Vja2luICAgICAg
RXhwaXJlcyBBcHJpbCAxOSwgMjAwNCAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMTJdDQpJbnRl
cm5ldC1EcmFmdCAgICAgICAgICAgUlRDUCBTdHJlYW1pbmcgWFIgICAgICAgICAgICAgICAgT2N0
b2JlciAyMDAzDQoNCg0KDQo3LiBJQU5BIENvbnNpZGVyYXRpb25zDQoNCiAgIEEgcmVxdWVzdCB3
aWxsIGJlIG1hZGUgdG8gSUFOQSB0byByZWdpc3RlciB0aGUgZm9sbG93aW5nIGJsb2NrIHR5cGU6
DQogICANCiAgIEJUICBuYW1lDQogICAtLSAgLS0tLQ0KICAgOCAgU3RyZWFtaW5nIFJlcG9ydCBC
bG9jawkNCg0KOC4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMNCg0KQWxsIHNlY3VyaXR5IGNvbnNp
ZGVyYXRpb25zIGFkZHJlc3NlZCBpbiBbMV0gYXJlIHZhbGlkIGZvciB0aGlzIA0KZG9jdW1lbnQg
YW5kIG5vIG5ldyBzb2x1dGlvbnMgYXJlIHByb3Bvc2VkIHRvIGFkZHJlc3MgdGhvc2UNCmNvbnNp
ZGVyYXRpb25zLiAgDQoNCjkuIEludGVsbGVjdHVhbCBQcm9wZXJ0eQ0KICANClRoZSBJRVRGIHRh
a2VzIG5vIHBvc2l0aW9uIHJlZ2FyZGluZyB0aGUgdmFsaWRpdHkgb3Igc2NvcGUgb2YgYW55DQpp
bnRlbGxlY3R1YWwgcHJvcGVydHkgb3Igb3RoZXIgcmlnaHRzIHRoYXQgbWlnaHQgYmUgY2xhaW1l
ZCB0bw0KcGVydGFpbiB0byB0aGUgaW1wbGVtZW50YXRpb24gb3IgdXNlIG9mIHRoZSB0ZWNobm9s
b2d5IGRlc2NyaWJlZCBpbg0KdGhpcyBkb2N1bWVudCBvciB0aGUgZXh0ZW50IHRvIHdoaWNoIGFu
eSBsaWNlbnNlIHVuZGVyIHN1Y2ggcmlnaHRzDQptaWdodCBvciBtaWdodCBub3QgYmUgYXZhaWxh
YmxlOyBuZWl0aGVyIGRvZXMgaXQgcmVwcmVzZW50IHRoYXQgaXQNCmhhcyBtYWRlIGFueSBlZmZv
cnQgdG8gaWRlbnRpZnkgYW55IHN1Y2ggcmlnaHRzLiBJbmZvcm1hdGlvbiBvbiB0aGUNCg0KDQoN
CklFVEYncyBwcm9jZWR1cmVzIHdpdGggcmVzcGVjdCB0byByaWdodHMgaW4gc3RhbmRhcmRzLXRy
YWNrIGFuZA0Kc3RhbmRhcmRzLXJlbGF0ZWQgZG9jdW1lbnRhdGlvbiBjYW4gYmUgZm91bmQgaW4g
QkNQLTExLiANCkNvcGllcyBvZiBjbGFpbXMgb2YgcmlnaHRzIG1hZGUgYXZhaWxhYmxlIGZvciBw
dWJsaWNhdGlvbiBhbmQgYW55IA0KYXNzdXJhbmNlcyBvZiBsaWNlbnNlcyB0byBiZSBtYWRlIGF2
YWlsYWJsZSwgb3IgdGhlIHJlc3VsdCBvZiBhbiANCmF0dGVtcHQgbWFkZSB0byBvYnRhaW4gYSBn
ZW5lcmFsIGxpY2Vuc2Ugb3IgcGVybWlzc2lvbiBmb3IgdGhlIHVzZQ0Kb2Ygc3VjaCBwcm9wcmll
dGFyeSByaWdodHMgYnkgaW1wbGVtZW50ZXJzIG9yIHVzZXJzIG9mIHRoaXMgDQpzcGVjaWZpY2F0
aW9uIGNhbiBiZSBvYnRhaW5lZCBmcm9tIHRoZSBJRVRGIFNlY3JldGFyaWF0Lg0KDQpUaGUgSUVU
RiBpbnZpdGVzIGFueSBpbnRlcmVzdGVkIHBhcnR5IHRvIGJyaW5nIHRvIGl0cyBhdHRlbnRpb24g
YW55DQpjb3B5cmlnaHRzLCBwYXRlbnRzIG9yIHBhdGVudCBhcHBsaWNhdGlvbnMsIG9yIG90aGVy
IHByb3ByaWV0YXJ5DQpyaWdodHMgd2hpY2ggbWF5IGNvdmVyIHRlY2hub2xvZ3kgdGhhdCBtYXkg
YmUgcmVxdWlyZWQgdG8gcHJhY3RpY2UNCnRoaXMgc3RhbmRhcmQuIFBsZWFzZSBhZGRyZXNzIHRo
ZSBpbmZvcm1hdGlvbiB0byB0aGUgSUVURiBFeGVjdXRpdmUNCkRpcmVjdG9yLg0KDQoxMC4gQWNr
bm93bGVkZ21lbnRzDQoNClRoZSBBdXRob3JzIHRoYW5rIEpheWFuayBCaGFsb2QsIFlhbmRhIE1h
LCBSYWFnaHUgTmFnYXJhaiwgYW5kIA0KTGFsaXQgU2FybmEgZnJvbSBWaWRpYXRvciBUZWNobm9s
b2d5IFVzIEluYy4gYW5kIFJvbGFuZCBCYW5rcyANCmZyb20gMyBVSyBmb3IgdGhlaXIgdmFsdWFi
bGUgaW5wdXQuIA0KDQpGdW5kaW5nIGZvciB0aGUgUkZDIEVkaXRvciBmdW5jdGlvbiBpcyBjdXJy
ZW50bHkgcHJvdmlkZWQgYnkgDQp0aGUgSW50ZXJuZXQgU29jaWV0eS4NCg0KDQoNCg0KDQpUc2Vu
ZywgU2Vja2luICAgICAgRXhwaXJlcyBBcHJpbCAxOSwgMjAwNCAgICAgICAgICAgICAgICAgICAg
W1BhZ2UgMTNdDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgUlRDUCBTdHJlYW1pbmcgWFIgICAg
ICAgICAgICAgICAgT2N0b2JlciAyMDAzDQoNCg0KDQoxMS4gQXV0aG9ycycgQWRkcmVzc2VzDQoN
CkFsYW4gVHNlbmcsIGFsYW5AdmlkaWF0b3IuY29tDQo4ODggVmlsbGEgU3QuIFN1aXRlIDUwMA0K
TW91bnRhaW4gVmlldywgQ0EgOTQwNDEgVVNBDQoNCkdhbXplIFNlY2tpbiwgZ2FtemVAdmlkaWF0
b3IuY29tDQo0MTEgMTA4dGggQXZlIE5FLCBTdWl0ZSA2ODgNClJlZG1vbmQsIFdBIDk4MDA0IFVT
QQ0KDQoxMi4gUmVmZXJlbmNlcw0KDQpbMV0gUlRQIENvbnRyb2wgUHJvdG9jb2wgRXh0ZW5kZWQg
UmVwb3J0cyAoUlRDUCBYUiksIFByb3Bvc2VkIA0KU3RhbmRhcmQsIEZyaWVkbWFuLCBDYWNhcmVz
LCBDbGFyaywgTWF5IDIwMDMsIA0KZHJhZnQtaWV0Zi1hdnQtcnRjcC1yZXBvcnQtZXh0bnMtMDYu
dHh0DQoNClsyXSAzR1BQIFNBNCBURE9DIFM0LTAzMDY4MiBEcmFmdCBSZWwtNiBRdWFsaXR5IE1l
dHJpY3MgUGVybWFuZW50IA0KRG9jdW1lbnQgdjAuMDYNCg0KMTMuIEZ1bGwgQ29weXJpZ2h0IFN0
YXRlbWVudA0KDQpDb3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDAzKS4gQWxs
IFJpZ2h0cyBSZXNlcnZlZC4NCg0KVGhpcyBkb2N1bWVudCBhbmQgdHJhbnNsYXRpb25zIG9mIGl0
IG1heSBiZSBjb3BpZWQgYW5kIGZ1cm5pc2hlZCB0bw0Kb3RoZXJzLCBhbmQgZGVyaXZhdGl2ZSB3
b3JrcyB0aGF0IGNvbW1lbnQgb24gb3Igb3RoZXJ3aXNlIGV4cGxhaW4gaXQNCm9yIGFzc2lzdCBp
biBpdHMgaW1wbGVtZW50YXRpb24gbWF5IGJlIHByZXBhcmVkLCBjb3BpZWQsIHB1Ymxpc2hlZA0K
YW5kIGRpc3RyaWJ1dGVkLCBpbiB3aG9sZSBvciBpbiBwYXJ0LCB3aXRob3V0IHJlc3RyaWN0aW9u
IG9mIGFueQ0Ka2luZCwgcHJvdmlkZWQgdGhhdCB0aGUgYWJvdmUgY29weXJpZ2h0IG5vdGljZSBh
bmQgdGhpcyBwYXJhZ3JhcGggYXJlDQppbmNsdWRlZCBvbiBhbGwgc3VjaCBjb3BpZXMgYW5kIGRl
cml2YXRpdmUgd29ya3MuICBIb3dldmVyLCB0aGlzDQpkb2N1bWVudCBpdHNlbGYgbWF5IG5vdCBi
ZSBtb2RpZmllZCBpbiBhbnkgd2F5LCBzdWNoIGFzIGJ5IHJlbW92aW5nDQoNCnRoZSBjb3B5cmln
aHQgbm90aWNlIG9yIHJlZmVyZW5jZXMgdG8gdGhlIEludGVybmV0IFNvY2lldHkgb3Igb3RoZXIN
CkludGVybmV0IG9yZ2FuaXphdGlvbnMsIGV4Y2VwdCBhcyBuZWVkZWQgZm9yIHRoZSBwdXJwb3Nl
IG9mDQpkZXZlbG9waW5nIEludGVybmV0IHN0YW5kYXJkcyBpbiB3aGljaCBjYXNlIHRoZSBwcm9j
ZWR1cmVzIGZvcg0KY29weXJpZ2h0cyBkZWZpbmVkIGluIHRoZSBJbnRlcm5ldCBTdGFuZGFyZHMg
cHJvY2VzcyBtdXN0IGJlDQpmb2xsb3dlZCwgb3IgYXMgcmVxdWlyZWQgdG8gdHJhbnNsYXRlIGl0
IGludG8gbGFuZ3VhZ2VzIG90aGVyIHRoYW4NCkVuZ2xpc2guDQoNClRoZSBsaW1pdGVkIHBlcm1p
c3Npb25zIGdyYW50ZWQgYWJvdmUgYXJlIHBlcnBldHVhbCBhbmQgd2lsbCBub3QgYmUNCnJldm9r
ZWQgYnkgdGhlIEludGVybmV0IFNvY2lldHkgb3IgaXRzIHN1Y2Nlc3NvcnMgb3IgYXNzaWducy4N
Cg0KVGhpcyBkb2N1bWVudCBhbmQgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gaXMg
cHJvdmlkZWQgb24gYW4NCiJBUyBJUyIgYmFzaXMgYW5kIFRIRSBJTlRFUk5FVCBTT0NJRVRZIEFO
RCBUSEUgSU5URVJORVQgRU5HSU5FRVJJTkcNClRBU0sgRk9SQ0UgRElTQ0xBSU1TIEFMTCBXQVJS
QU5USUVTLCBFWFBSRVNTIE9SIElNUExJRUQsIElOQ0xVRElORw0KQlVUIE5PVCBMSU1JVEVEIFRP
IEFOWSBXQVJSQU5UWSBUSEFUIFRIRSBVU0UgT0YgVEhFIElORk9STUFUSU9ODQpIRVJFSU4gV0lM
TCBOT1QgSU5GUklOR0UgQU5ZIFJJR0hUUyBPUiBBTlkgSU1QTElFRCBXQVJSQU5USUVTIE9GDQpN
RVJDSEFOVEFCSUxJVFkgT1IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuDQoNCg0K
DQoNCg0KVHNlbmcsIFNlY2tpbiAgICAgIEV4cGlyZXMgQXByaWwgMTksIDIwMDQgICAgICAgICAg
ICAgICAgICAgIFtQYWdlIDE0XQ0K

------_=_NextPart_001_01C398EE.57038B58--

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



From exim@www1.ietf.org  Thu Oct 23 06:15:36 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11641
	for <avt-archive@odin.ietf.org>; Thu, 23 Oct 2003 06:15:36 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACcUl-0004Y9-U7
	for avt-archive@odin.ietf.org; Thu, 23 Oct 2003 06:15:17 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NAF7TR017445
	for avt-archive@odin.ietf.org; Thu, 23 Oct 2003 06:15:07 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACcUg-0004Sv-4e; Thu, 23 Oct 2003 06:15:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACcTp-00041Y-GL
	for avt@optimus.ietf.org; Thu, 23 Oct 2003 06:14:09 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11548
	for <avt@ietf.org>; Thu, 23 Oct 2003 06:13:56 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACcTk-0004ov-00
	for avt@ietf.org; Thu, 23 Oct 2003 06:14:04 -0400
Received: from ipvpn069002.netvigator.com ([203.198.202.2] helo=mail.astri.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACcTi-0004ob-00
	for avt@ietf.org; Thu, 23 Oct 2003 06:14:03 -0400
Received: from TrevorNg (entry1 [172.16.1.1])
	(authenticated bits=0)
	by mail.astri.org (8.12.8/8.12.8) with ESMTP id h9NATl7C029269
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <avt@ietf.org>; Thu, 23 Oct 2003 18:29:49 +0800
Message-ID: <003a01c3994e$1d369100$4203050a@astri.org>
From: "Trevor NG" <trevor@astri.org>
To: <avt@ietf.org>
Date: Thu, 23 Oct 2003 18:12:05 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0037_01C39991.2A1CBD20"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Subject: [AVT] draft-ietf-avt-mpeg4-simple-08.txt : AU-header bit pattern
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0037_01C39991.2A1CBD20
Content-Type: text/plain;
	charset="big5"
Content-Transfer-Encoding: quoted-printable

Dear experts,

Referring to P12-13 of draft-ietf-avt-mpeg4-simple-08.txt, how many bits =
are allocated for each fields in the AU-header? I can't find any =
definition of the field length within section 3.2. Can anybody guide me =
to the correct section?

Thanks and regards,
Trevor

------=_NextPart_000_0037_01C39991.2A1CBD20
Content-Type: text/html;
	charset="big5"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dbig5">
<META content=3D"MSHTML 6.00.2800.1264" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3D"Courier New" size=3D2>Dear experts,</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>Referring to P12-13 of=20
draft-ietf-avt-mpeg4-simple-08.txt, how many bits are allocated for each =
fields=20
in the AU-header? I can't find any definition of the field length within =
section=20
3.2. Can anybody guide me to the correct section?</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>Thanks and =
regards,</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>Trevor</FONT></DIV>
<DIV><FONT face=3D"Courier New" =
size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0037_01C39991.2A1CBD20--


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



From exim@www1.ietf.org  Thu Oct 23 09:12:27 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17227
	for <avt-archive@odin.ietf.org>; Thu, 23 Oct 2003 09:12:27 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACfG3-000697-0x
	for avt-archive@odin.ietf.org; Thu, 23 Oct 2003 09:12:07 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NDC6rT023619
	for avt-archive@odin.ietf.org; Thu, 23 Oct 2003 09:12:06 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACfFy-00066X-0Y; Thu, 23 Oct 2003 09:12:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACfFZ-000621-Pc
	for avt@optimus.ietf.org; Thu, 23 Oct 2003 09:11:37 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17187;
	Thu, 23 Oct 2003 09:11:27 -0400 (EDT)
Message-Id: <200310231311.JAA17187@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: avt@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Thu, 23 Oct 2003 09:11:26 -0400
Subject: [AVT] I-D ACTION:draft-xie-avt-xdsr-es202211-00.txt
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: RTP Payload Format for European Telecommunications 
			  Standards  Institute (ETSI) European Standard ES 202 
			  211 Extended  Distributed Speech Recognition Encoding
			  (XFE)
	Author(s)	: Q. Xie, et. al.
	Filename	: draft-xie-avt-xdsr-es202211-00.txt
	Pages		: 12
	Date		: 2003-10-22
	
This document specifies an RTP payload format for encapsulating ETSI
Standard ES 202 211 extended advanced front-end signal processing
feature streams for distributed speech recognition (DSR) systems.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-xie-avt-xdsr-es202211-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-xie-avt-xdsr-es202211-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-xie-avt-xdsr-es202211-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-10-22183543.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-xie-avt-xdsr-es202211-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-xie-avt-xdsr-es202211-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-10-22183543.I-D@ietf.org>

--OtherAccess--

--NextPart--



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



From exim@www1.ietf.org  Thu Oct 23 09:13:22 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17308
	for <avt-archive@odin.ietf.org>; Thu, 23 Oct 2003 09:13:22 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACfGw-0006Up-12
	for avt-archive@odin.ietf.org; Thu, 23 Oct 2003 09:13:02 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NDD18E024924
	for avt-archive@odin.ietf.org; Thu, 23 Oct 2003 09:13:01 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACfGv-0006Rd-9d; Thu, 23 Oct 2003 09:13:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACfGd-0006Na-Gu
	for avt@optimus.ietf.org; Thu, 23 Oct 2003 09:12:43 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17256;
	Thu, 23 Oct 2003 09:12:32 -0400 (EDT)
Message-Id: <200310231312.JAA17256@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: avt@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Thu, 23 Oct 2003 09:12:32 -0400
Subject: [AVT] I-D ACTION:draft-xie-avt-xadsr-es202212-00.txt
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: RTP Payload Format for European Telecommunications 
			  Standards Institute (ETSI) European Standard ES 202 
			  212 Extended Advanced Distributed Speech Recognition 
			  Encoding (XAFE)
	Author(s)	: Q. Xie, et. al.
	Filename	: draft-xie-avt-xadsr-es202212-00.txt
	Pages		: 12
	Date		: 2003-10-22
	
This document specifies an RTP payload format for encapsulating ETSI
Standard ES 202 212 extended advanced front-end (XAFE) signal
processing feature streams for distributed speech recognition (DSR)
systems.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-xie-avt-xadsr-es202212-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-xie-avt-xadsr-es202212-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-xie-avt-xadsr-es202212-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-10-22183600.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-xie-avt-xadsr-es202212-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-xie-avt-xadsr-es202212-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-10-22183600.I-D@ietf.org>

--OtherAccess--

--NextPart--



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



From exim@www1.ietf.org  Thu Oct 23 10:59:26 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27587
	for <avt-archive@odin.ietf.org>; Thu, 23 Oct 2003 10:59:26 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACgvc-0000Rh-7I
	for avt-archive@odin.ietf.org; Thu, 23 Oct 2003 10:59:08 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NEx8R8001665
	for avt-archive@odin.ietf.org; Thu, 23 Oct 2003 10:59:08 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACgvV-0000Nw-IY; Thu, 23 Oct 2003 10:59:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACguW-0000AM-A1
	for avt@optimus.ietf.org; Thu, 23 Oct 2003 10:58:00 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27501
	for <avt@ietf.org>; Thu, 23 Oct 2003 10:57:48 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACguT-0001nu-00
	for avt@ietf.org; Thu, 23 Oct 2003 10:57:57 -0400
Received: from eagle.ericsson.se ([193.180.251.53])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACguT-0001nr-00
	for avt@ietf.org; Thu, 23 Oct 2003 10:57:57 -0400
Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121])
	by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9NEvqoq005858
	for <avt@ietf.org>; Thu, 23 Oct 2003 16:57:56 +0200
Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55)
	id 43DWSQX0; Thu, 23 Oct 2003 16:58:39 +0200
Message-ID: <3F97EC6A.90108@ericsson.com>
Date: Thu, 23 Oct 2003 16:57:46 +0200
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: avt@ietf.org
Subject: [AVT] Reminder: I-D submission deadline
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

The deadline for initial submissions is passed, any further submission 
will have to wait until the 58th IETF meeting has ended.

The deadline for all other internet-draft submissions is Monday 27th
October at 9.00 ET.

Any one desiring to have a presentation and discussion during the AVT
working group's slots in Minneapolis MUST request time on the agenda. A
submission of a draft is not sufficient for receiving agenda time. Send
the request before the 27th October, 2003 at 24.00 GMT to BOTH chairs.
In the request include the following information:

A. Presentation Title:

B. Name of presenter:

C. Draft Reference(s):

D. Requested amount of time in minutes:


Magnus & Colin


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



From exim@www1.ietf.org  Thu Oct 23 11:14:24 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28315
	for <avt-archive@odin.ietf.org>; Thu, 23 Oct 2003 11:14:24 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AChA2-0003wk-Gx
	for avt-archive@odin.ietf.org; Thu, 23 Oct 2003 11:14:04 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NFE2ko015136
	for avt-archive@odin.ietf.org; Thu, 23 Oct 2003 11:14:02 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AChA1-0003vf-BZ; Thu, 23 Oct 2003 11:14:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACh9W-0003kW-KZ
	for avt@optimus.ietf.org; Thu, 23 Oct 2003 11:13:30 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28229
	for <avt@ietf.org>; Thu, 23 Oct 2003 11:13:20 -0400 (EDT)
From: philippe.gentric@philips.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACh9V-00023h-00
	for avt@ietf.org; Thu, 23 Oct 2003 11:13:29 -0400
Received: from gw-nl4.philips.com ([212.153.190.6])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACh9U-00023Z-00
	for avt@ietf.org; Thu, 23 Oct 2003 11:13:28 -0400
Received: from smtpscan-nl3.philips.com (smtpscan-nl3.philips.com [130.139.36.23])
	by gw-nl4.philips.com (Postfix) with ESMTP
	id 4F6015ACF6; Thu, 23 Oct 2003 17:13:27 +0200 (MET DST)
Received: from smtpscan-nl3.philips.com (localhost [127.0.0.1])
	by localhost.philips.com (Postfix) with ESMTP
	id C800219C48; Thu, 23 Oct 2003 17:13:26 +0200 (MEST)
Received: from smtprelay-nl2.philips.com (smtprelay-eur2.philips.com [130.139.36.35])
	by smtpscan-nl3.philips.com (Postfix) with ESMTP
	id 6B25E19C46; Thu, 23 Oct 2003 17:13:26 +0200 (MEST)
Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) 
	by smtprelay-nl2.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id RAA14358; Thu, 23 Oct 2003 17:13:25 +0200 (MEST)
Subject: Re: [AVT] draft-ietf-avt-mpeg4-simple-08.txt : AU-header bit pattern
To: "Trevor NG" <trevor@astri.org>
Cc: avt@ietf.org
X-Mailer: Lotus Notes Release 5.0.9a  January 7, 2002
Message-ID: <OF419C35FB.8432110E-ONC1256DC8.00528C9A-C1256DC8.0053626E@diamond.philips.com>
Date: Thu, 23 Oct 2003 17:11:08 +0200
X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.11  |July 24, 2002) at
 23/10/2003 17:14:56
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>

Dear Trevor,

AU_header is a configurable header.

Each field xxxx has a size in bits indicated by a specific configuration parameter,
transmitted as a MIME parameter that has the name xxxxLength.

E.g.       if you look at page 30:

sizeLength:
      The number of bits on which the AU-size field is encoded in the  AU-header.

etc ...


regards,


Philippe Gentric
Software Architect
Philips MP4Net
philippe.gentric@philips.com
http://www.platform4.philips.com


                                                                                                                                       
                                                                                                                                       
                                                   To:   <avt@ietf.org>                                                                
                                                   cc:   (bcc: Philippe Gentric/MP4-SUR/CE/PHILIPS)                                    
                                                   Subject:    [AVT] draft-ietf-avt-mpeg4-simple-08.txt : AU-header bit pattern        
                                                                                                                                       
               "Trevor NG"                         Classification:                                                                     
               <trevor@astri.org>                                                                                                      
                                                                                                                                       
               Sent by:                                                                                                                
               avt-admin@ietf.org                                                                                                      
                                                                                                                                       
               23/10/2003 12:12                                                                                                        
                                                                                                                                       
                                                                                                                                       




Dear experts,

Referring to P12-13 of draft-ietf-avt-mpeg4-simple-08.txt, how many bits are allocated for each fields in the AU-header? I can't find any definition of the field length within section 3.2. Can anybody guide me to the correct section?

Thanks and regards,
Trevor






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



From exim@www1.ietf.org  Thu Oct 23 16:38:33 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17849
	for <avt-archive@odin.ietf.org>; Thu, 23 Oct 2003 16:38:33 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACmDl-0002Ge-Il
	for avt-archive@odin.ietf.org; Thu, 23 Oct 2003 16:38:13 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NKcDxr008712
	for avt-archive@odin.ietf.org; Thu, 23 Oct 2003 16:38:13 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACmDa-0002AQ-9W; Thu, 23 Oct 2003 16:38:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACmDO-00022j-HR
	for avt@optimus.ietf.org; Thu, 23 Oct 2003 16:37:50 -0400
Received: from cc26-01.idc1.level3.com (machine77.Level3.com [209.244.4.106])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17826
	for <avt@ietf.org>; Thu, 23 Oct 2003 16:37:39 -0400 (EDT)
Received: from cc26-01.idc1.level3.com (localhost [127.0.0.1])
	by localhost (Postfix) with ESMTP
	id 345BF8B147; Thu, 23 Oct 2003 20:32:12 +0000 (GMT)
Received: from idc1exc0001.corp.global.level3.com (idc1exc0001.corp.global.level3.com [10.1.7.194])
	by cc26-01.idc1.level3.com (Postfix) with SMTP
	id 7106A8AD1A; Thu, 23 Oct 2003 20:32:11 +0000 (GMT)
Received: from idc1exc0004.corp.global.level3.com ([10.1.8.20]) by idc1exc0001.corp.global.level3.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Thu, 23 Oct 2003 14:32:11 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.0.6470.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [AVT] FEC draft
Date: Thu, 23 Oct 2003 14:32:10 -0600
Message-ID: <C681A23EB05EB249BF9E7B0DB40B91AA114771@idc1exc0004.corp.global.level3.com>
Thread-Topic: [AVT] FEC draft
Thread-Index: AcOZYX/4sTZWsFtbR5CVm+RjlH0jIgAK3gaA
From: "White, Craig (Level 3)" <Craig.White@Level3.com>
To: "Magnus Westerlund" <magnus.westerlund@ericsson.com>
Cc: <avt@ietf.org>
X-OriginalArrivalTime: 23 Oct 2003 20:32:11.0076 (UTC) FILETIME=[BC627040:01C399A4]
Content-Transfer-Encoding: quoted-printable
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable

Hi!

As a long time lurker (don't know if anyone remembers the sonet draft I =
proposed eons ago), I just wanted to say to the whole of the group. Not =
that there is anything special about this particular email (other than =
I'm interested in FEC) but this e-mail just prompted me to write this =
note, and I'd like to let you know that:=20

YOU GUYS ROCK!!!!=20

I have no technical content to add, just a word of encouragement! As you =
may or may not know, I've been working out of the PWE3 group and only =
wish we were beginning to work on issues like these, rather than what's =
going on over there (not saying that the work PWE3 is doing is not =
worthwhile...)

Carry on!
-craig

-----Original Message-----
From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Magnus
Westerlund
Sent: Thursday, October 23, 2003 6:27 AM
To: Adam Li; IETF AVT WG
Subject: Re: [AVT] FEC draft


Hi Adam,

Why not, it should simplify the processing somewhat. However I think=20
this should be discussed openly, so I CC the AVT list in this reply. So=20
if someone else has any comments about this, please respond.

Cheers

Magnus

Adam Li wrote:

> Hi Magnus,
>=20
> I shuffle the fields around a little bit more (since we have them =
moved
> already). What do you think about the following format along the line
> you proposed? It have a even closer resemblance of the RTP header.
>=20
>  0                   1                   2                   3
>  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |E|L|P|X|  CC   |M| PT recovery |            SN base            |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |                          TS recovery                          |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |        length recovery        |             mask              |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |              mask cont. (present only when L =3D 1)             |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>=20
> Do you think this looks alright? Thanks a lot.
>=20
> Adam
>=20
>=20
>=20
>>-----Original Message-----
>>From: avt-admin@ietf.org [mailto:avt-admin@ietf.org] On Behalf Of
>>Magnus Westerlund
>>Sent: Wednesday, October 22, 2003 5:31 AM
>>To: Adam Li
>>Cc: avt@ietf.org
>>Subject: Re: [AVT] FEC draft
>>
>>Hi Adam,
>>
>>[chair hat of]
>>
>>I have actually thought this over and have a counter proposal that I
>>think is rather nice. First I would like to rearrange the header in
>>the
>>following way:
>>
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>|      SN base                  |        length recovery        |
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>|E|L|P|X|  CC   |M| PT recovery |             mask              |
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>|                          TS recovery                          |
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>That way the 16 bits of fields matches the first 16 bits of the RTP
>>header. The sending part can simply XOR the headers of the packet as
>>is
>>and mask out the version bits.
>>
>>Secondly I would actually take the reserved bit and change it into a
>>"Long mask" indicator. When the L bit is set the header would then
>>actually look like this:
>>
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>|      SN base                  |        length recovery        |
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>|E|L|P|X|  CC   |M| PT recovery |             mask              |
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>|                         mask continued                        |
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>|                          TS recovery                          |
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>That way one can allow for a 48 bit mask while still keeping the
>>number
>>of options low and keep the 32 bit alignment.
>>
>>What does you think about it?
>>
>>Cheers
>>
>>Magnus
>>
>>
--=20

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 exim@www1.ietf.org  Thu Oct 23 23:46:30 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01590
	for <avt-archive@odin.ietf.org>; Thu, 23 Oct 2003 23:46:29 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACstu-0000gr-5t
	for avt-archive@odin.ietf.org; Thu, 23 Oct 2003 23:46:10 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9O3kAkN002564
	for avt-archive@odin.ietf.org; Thu, 23 Oct 2003 23:46:10 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACstm-0000eH-4E; Thu, 23 Oct 2003 23:46:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACstT-0000XE-Ex
	for avt@optimus.ietf.org; Thu, 23 Oct 2003 23:45:43 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01548
	for <avt@ietf.org>; Thu, 23 Oct 2003 23:45:32 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACstR-0004l4-00
	for avt@ietf.org; Thu, 23 Oct 2003 23:45:41 -0400
Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com)
	by ietf-mx with smtp (Exim 4.12)
	id 1ACstQ-0004k7-01
	for avt@ietf.org; Thu, 23 Oct 2003 23:45:40 -0400
Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap 
	 id 21761; Thu, 23 Oct 2003 23:53:13 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 23 Oct 2003 23:45:09 -0400
Message-ID: <4A3384433CE2AB46A63468CB207E209D4F6868@zoe.office.snowshore.com>
Thread-Topic: draft-basso-avt-videoconreq-00: What really is used?
Thread-Index: AcOZzw4pIRyYAKjySVGY4+Om1+6ZeQ==
From: "Eric Burger" <eburger@snowshore.com>
To: <avt@ietf.org>
Content-Transfer-Encoding: quoted-printable
Subject: [AVT] draft-basso-avt-videoconreq-00: What really is used?
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable

Looking through the codec commands, I am struck by a nagging question: =
How much of this do people really use?

VideoFastUpdatePicture clearly gets used.  However, does anyone really =
USE the quality trade-off commands (e.g., RateRequest, =
Temporal/Spatial)?  I understand the use cases, I just wonder if it gets =
used.

Likewise, does anyone EVER use VideoFastUpdateGOB?  Again, I understand =
the use case, but in reality, most decoders, when they sense a messed up =
picture, will issue a VideoFastUpdatePicture request.


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



From exim@www1.ietf.org  Fri Oct 24 00:33:39 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01589
	for <avt-archive@odin.ietf.org>; Thu, 23 Oct 2003 23:46:29 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACstu-0000gq-5T
	for avt-archive@odin.ietf.org; Thu, 23 Oct 2003 23:46:10 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9O3k9fp002565
	for avt-archive@odin.ietf.org; Thu, 23 Oct 2003 23:46:10 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACstl-0000e5-85; Thu, 23 Oct 2003 23:46:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACstS-0000Wa-Rk
	for avt@optimus.ietf.org; Thu, 23 Oct 2003 23:45:42 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01545
	for <avt@ietf.org>; Thu, 23 Oct 2003 23:45:31 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACstQ-0004kz-00
	for avt@ietf.org; Thu, 23 Oct 2003 23:45:40 -0400
Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com)
	by ietf-mx with smtp (Exim 4.12)
	id 1ACstQ-0004k7-00
	for avt@ietf.org; Thu, 23 Oct 2003 23:45:40 -0400
Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap 
	 id 21761; Thu, 23 Oct 2003 23:53:12 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 23 Oct 2003 23:45:08 -0400
Message-ID: <4A3384433CE2AB46A63468CB207E209D4F6867@zoe.office.snowshore.com>
Thread-Topic: draft-basso-avt-videoconreq-00: H.245 and Section 7.8
Thread-Index: AcOZzl8H0LFHlI99RPSdm3A6+TjMfA==
From: "Eric Burger" <eburger@snowshore.com>
To: <avt@ietf.org>
Content-Transfer-Encoding: quoted-printable
Subject: [AVT] draft-basso-avt-videoconreq-00: H.245 and Section 7.8
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable

I am concerned about the potential direction the requirement stated in =
section 7.8 may bring us.  Here is the text:

  7.8 Interoperability with other protocols=20
   =20
      The codec control transport protocol MUST allow inter-operability=20
      with the most commonly deployed IP-based video communication=20
      protocols, such as H.323, H.324 and H.324M.


What does this mean.  On one level, it sounds straightforward.  If I =
have a video system, and you have a video system, then we should be able =
to communicate.  In fact, given a lexicon, how could one NOT create =
mappings between different grammars for that lexicon?  In that sense, =
this is a non-requirement and should be removed.

However, at another level, and taken in conjunction with the statement =
of section 6.3 (protocol duplication), it is hideous.  Direct =
interoperability means that we should take the common signaling =
denominator for these three protocols, namely H.245.

H.245 sound innocent enough, as it is independent of H.323 and H.324.  =
However, when one looks closer, we find a lot of overlap between H.245 =
and SDP and (please look at the protocol) SIP.

I would offer that if H.245, or something like H.245, is what is being =
thought of for this requirement, then there is no reason for this draft. =
 Use H.323/H.324/H.324m/H.320 and Be Happy.

If there is any requirement that should be in the document, it is an =
emphasis on Section 6.2.  I would offer that the call control and =
content negotiation capabilities of H.245 "break" SIP and SDP (or =
conversely, would not interoperate in the ITU direction).  Since this is =
the IETF, I really only care about not breaking IETF protocols.  You can =
break the broken protocols to your hearts content :-)



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



From exim@www1.ietf.org  Fri Oct 24 05:55:42 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23175
	for <avt-archive@odin.ietf.org>; Fri, 24 Oct 2003 05:55:42 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACyfB-0008AG-RS
	for avt-archive@odin.ietf.org; Fri, 24 Oct 2003 05:55:24 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9O9tL0B031375
	for avt-archive@odin.ietf.org; Fri, 24 Oct 2003 05:55:21 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACyev-000835-5K; Fri, 24 Oct 2003 05:55:05 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACyef-0007zy-8u
	for avt@optimus.ietf.org; Fri, 24 Oct 2003 05:54:49 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23095
	for <avt@ietf.org>; Fri, 24 Oct 2003 05:54:37 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACyeb-0000d9-00
	for avt@ietf.org; Fri, 24 Oct 2003 05:54:45 -0400
Received: from mail.pel.panasonic.de ([194.162.191.12])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACyea-0000d6-00
	for avt@ietf.org; Fri, 24 Oct 2003 05:54:44 -0400
Received: from mcomreyj ([10.10.100.5]) by mail.pel.panasonic.de with Microsoft SMTPSVC(5.0.2195.6713);
	 Fri, 24 Oct 2003 11:54:36 +0200
Reply-To: <rey@panasonic.de>
From: =?utf-8?Q?Jos=C3=A9_Rey?= <rey@panasonic.de>
To: "'Magnus Westerlund'" <magnus.westerlund@ericsson.com>
Cc: "'IETF AVT WG'" <avt@ietf.org>, "'Dave Singer'" <singer@apple.com>,
        "Jan van der Meer \(E-mail\)" <jan.vandermeer@philips.com>,
        "Yoshinori Matsui \(E-mail\)" <matsui.yoshinori@jp.panasonic.com>
Date: Fri, 24 Oct 2003 11:54:34 +0200
Message-ID: <004f01c39a14$d4ff9950$05640a0a@panasonic.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200
Importance: Normal
In-Reply-To: <3F7428E3.7020905@ericsson.com>
X-OriginalArrivalTime: 24 Oct 2003 09:54:36.0036 (UTC) FILETIME=[D5045440:01C39A14]
Content-Transfer-Encoding: quoted-printable
Subject: [AVT] RE: Comments on draft-rey-avt-rtp-3gpp-timed-text-01.txt
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable

Hi Magnus,all


First of all, thanks to you and Per for the comments.  Please see =
inline:

> -----Original Message-----
> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]
> Sent: Friday, September 26, 2003 1:54 PM
> To: Jose Rey; IETF AVT WG
> Cc: Dave Singer
> Subject: Comments on draft-rey-avt-rtp-3gpp-timed-text-01.txt
>=20
>=20
> Hi Jose,
>=20
> Here is a number of comment on your draft from me and my=20
> colleague Per=20
> Fr=C3=B6jdh. I think there are a couple of fundamental design issues =
here=20
> Most however is details.
>=20
>=20
> 1. A General comment is about the language which is rather fuzzy and=20
> unprecise. I would strongly recommend a much greater level of use of=20
> normative language to describe how things work.
>=20
> 2. In the abstract there is a sentence saying: "3GPP timed text is=20
> time-lined decorated text media format based on the ISO=20
> (International=20
> Standardisation Organisation) Base Media File Format."
>=20
> In my opinion the text format is not BASED ON ISO, it is=20
> rather defined=20
> within the framework for ISO files.

OK

>=20
> 3. Abstract, " As of today, 3GPP timed text contents can be=20
> downloaded=20
> via HTTP and synchronised with audio/video contents." I think=20
> one should=20
> consider the formulation. The 3GPP timed text content can be=20
> download as=20
>   a 3GP file using HTTP.
>=20
OK

> 4. Section 2, second paragraph, first sentence: "3GPP timed text is a=20
> 3GP file format for time-lined decorated text specified in=20
> Annex D.8.a=20
> of [1]." Again 3GPP timed text is a format with defined=20
> storage in a 3GP=20
> file according to Annex D.8.a
>=20
OK

> 5. How do you plan to handle the Release 6 update and definitions?
>=20
Could you be more specific in your question?

> 6. Section 2, last paragraph, stray ".".
>=20
> 7. Section 4. Marker bit definition. Needs normative MUST.=20
> Some note on=20
> multi sample packets.

OK.
>=20
> 8. Section 4. Timestamp definition: In the case of multiple=20
> samples in a=20
> packet, I think that the timestamp SHALL be set for the=20
> earliest, rather=20
> than first sample. Otherwise the duration rule will have problem. I=20
> think one should also point out that all samples have unique=20
> timestamps=20
> that is why one can use the TS as a identifier of which packet the=20
> fragments belong to.
>=20

This is described in the text as you say above, as no negative SDUR =
values are defined.  It seems this needs further clarification...

> 9. Section 4. Payload type definition. "Payload Type (PT):=20
> the payload=20
> type is set dynamically and sent by out-of-band means. " I think the=20
> sentence is slightly wrongly formulated. The payload type is=20
> dynamically=20
> assigned per RTP session and the assignment is done by out-of-bands=20
> mechanisms, for example SDP.

This is a mistake. It should read: "Payload Type (PT): the payload type =
is set dynamically by out-of-band means. "

>=20
> 10. Section 4. Sequence number handling. I think there are need to=20
> consider sequence number in the case of FU packets to get the right=20
> assembly order. In general I think there is a lack of definition or=20
> explanation of how a receiver determines what is the first and last=20
> packet of fragment.

Right, this is not specified. I think the best solution here is to add =
(reuse) a new (the fragment) header field carrying some type of fragment =
numbering for those having the same TS. This is much easier. =20

>=20
> 11. Section 4. Page 5, Last partial sentence: "This payload format is=20
> used to convey both fragmented and non-fragmented text=20
> samples." In the=20
> case for more normative language the sentence should be probably be=20
> reformulated as "This payload format MAY be used to convey both=20
> fragmented and non-fragmented text samples."

OK.

>=20
> 12. Figure 1, 2, 3, 4. I think there is not clear how a=20
> receiver will be=20
> able to distinguish between the cases.=20

This is the same observation as in item 10 above.

> The only one that has an=20
> explanation at all is the case with FHDR first. How a=20
> receiver detects=20
> the presence or not of a SPLDESC I have no idea.=20

The presence of SPLDESC is signalled using SDP. The SPLDESC is always at =
least one byte long =3D the entry count byte.  A value of zero is =
allowed for the entry count field.

As for the presence of the rest: FHDR is indicated in SDP and for THDR =
in the FHDR itself (T=3D1)

> When I have this=20
> complains I would also like to point out that using the=20
> payload types is=20
> not a good solution, at least not as the current parameter mapping is=20
> done. When one has fragments one in fact duplicates all the=20
> track header=20
> information and sample descriptions sent in the SDP. As the fmtp line=20
> can become rather big for this format I don't see this as an=20
> acceptable=20
> solution.

Correct. To avoid this, is it not possible to associate the sample =
descriptions and just write the contents in one line? I think this =
should be possible through some new SDP attribute and defining the =
behaviour of the receiver. This way the PT-multiplexing still works =
fine.

>=20
> 13. Section 4.1, page 8:
> "  The composition of the THDR depends on whether the text sample is
>     fragmented or not.  In particular:
>=20
>     - SLEN MUST NOT be present if the RTP packet contains a=20
> text sample
>     fragment.  If the RTP packet carries one or several non-fragmented
>     samples SLEN MUST be present for every text sample, as in=20
> Figure 1."
>=20
> Why should one not have a SLEN field for a fragment?

The motivation for SLEN is for packets containing several whole text =
samples, to allow the receiver to jump from one sample to another, as a =
kind of indexing. In the case the RTP packet only contains one text =
sample, SLEN is theoretically not needed; however we thought making an =
exception here would make it all too confusing.=20

> In my opinion=20
> knowing the total length of the fragmented sample allows one=20
> to allocate=20
> the correct buffer for that sample.
>=20
I think this is an implementation issue.  In general packet sizes are =
not included in RTP and buffering works anyway. I don't see why the =
sizes should be used in this particular case to reserve buffer in =
advance, specially given the low bitrates.

> 14. Section 4.2.2 I am not convinced that the fragmentation=20
> rules allow=20
> for all cases to have the sample reconstructed. For example is seems=20
> that multiple fragments of boxes will not be guaranteed to be=20
> reconstructed in the correct order unless some other information is=20
> provided.

I think you mean the same as in 10 and 12 with the reassembly.=20

>=20
> In general I would like to have a discussion of the need for the=20
> advanced fragmentation formats that is defined. Could not a simple=20
> fragmentation requiring all parts be sufficient. Are really=20
> there enough=20
> advantage of using the fragments when some are missing=20
> enough. Will it=20
> also not in some cases result in something that is more confusing the=20
> not presenting it at all would.
>=20
> If one keeps this advance fragmentation then it is really need for a=20
> introduction part that talks about why and how this works.
>=20
> 15. Section 4.2 There is need for having guidelines on how to=20
> fragment.=20
> I think there are some fragmentation points that are advantageous.

We developed the fragmentation headers because 3GPP timed text allows in =
principle for bigger packets (until 2048 bytes) and didn't want to leave =
that out. We also didn't assume the use of FEC, for simplicity.

We realize that the FHDR increments the complexity of the draft. If =
fragmentation happens seldom, we agree it is convenient to reduce the =
complexity of the headers, i.e. to a mere counter of the fragments. =
Therefore we would agree to simplify them if no one else has an =
application/use case for that. Does anyone feel the advanced =
fragmentation headers as they are in the draft now are needed?

>=20
> 16. Section 4.2.5, The use of this MSF field requires that the=20
> fragmentation of a "krok" is done at a boundaries of the=20
> highligth-offset entry.

I think this is the same we mean in the text. Each entry starts with a =
field "highlight-end-time" which is I guess what you call =
highlight-offset.

>=20
> 17. Section 4.2.6: Last sentence in section: "Fragmentation=20
> MUST be done=20
> between the URL and the altLength fields." I guess this is=20
> conditionally=20
> if fragmentation is done.

Of course, we'll add some wording.
>=20
> 18. Section 4.3: "   - All SIDX values present in the SPLDESC=20
> field of=20
> an RTP packet MUST be present in at least one of the text=20
> samples in the=20
> payload." I interpret this rule saying that within a RTP packet which=20
> carries the Sample descriptions the sample description must=20
> be included=20
> in the sample part.=20

This is not what is meant; descriptions are only present once. What we =
meant to be present in both SPLDESC and text samples is the SIDX value =
to be able to pair them. This has two reasons: 1) in principle, SPLDESC =
was thought for live streaming and 2) feedback might not always be =
available, so that the sender doesn't know the received descriptions. =
But it might be used for other things, as you point out. So we can =
abolish the restriction and make a note saying that the sender shall =
provide the means for the receiver to have all descriptions available =
for the received text samples whether there's feedback or not: using =
retransmissions, include the descriptions again or protect them with FEC =
appropriately.



> However I don't see a reason for this. All sample=20
> descriptions MUST be cached and can at any time be used.=20
> Therefore I see=20
> some advantage of allowing sample description only packets=20
> for example.=20
>   They can be given high protection with FEC. They can be=20
> given highest=20
> priority for retransmission. They can be sent in advance and=20
> verified as=20
> arrived if explicit packet loss vectors are used. So what is=20
> the reason.
>=20
I like the idea of using sample-description-only packets. A bit of the =
initial entry count field could be used to indicate there are any =
(SIDX,SPLATTR) pairs following or is just a sample-description-only =
packet.

> 19. Section 4.3.1: The SPLATTR field. I don't see why the fields are=20
> conditionally on the bit field to be present. In the sample=20
> description=20
> in the 3GP file all fields must always be present. Therefore I see a=20
> great simplification by removing the whole first 16 bits=20
> which contains=20
> flags if fields are present or not. Also if the fields would be=20
> conditionally present default values or derivation rules must be=20
> defined. As the number of sample descriptions are limited I=20
> don't see a=20
> reason for making this field minimal in bandwidth, I think=20
> simplicity is=20
> an advantage here.

Yes, this is more simple. We'll take that in the next draft.


>=20
> 20. Section 5.1: Why is not FEC with RFC 2733 mentioned?
>=20
is an option...can be included in next revision.

> 21. section 6, second paragraph, last sentence: "Such a rule would=20
> translate in practice into the following actions: " I think=20
> "would" is=20
> rather "can".

OK

> I also think one should be clearer that if one have a=20
> congestion control system being fair, then one may use as=20
> much bandwidth=20
> as the system allows for if deemed necessary. So in these cases the=20
> sender can use retransmission or FEC at a higher bit-rate=20
> then before.=20
> So the SHOULD NOT (next paragraph) is conditional if one knows that=20
> there is available bandwidth.
>=20
OK

> 22. Section 8.1: Fragment variable: The values allow to be given are=20
> they "one" and "zero" or "1" or "0"?=20
>=20
"fragment=3D0" and "fragment=3D1" are possible values.

> Also I don't like this=20
> variable as=20
> it results in duplication of a rather long "a=3Dfmtp" line.

what do you propose instead?

> 23. Section 8.1: brand: How does one handle the Release 6 brands that=20
> are several and the usage of brand compatible list?
>=20

We'll work that out.

> 24. Section 8.1: Version: pointing at the SDP section in the MIME=20
> registration is not acceptable as the MIME registration may=20
> be separated=20
> into another database.
>=20
OK

> 25. Section 8.1: spldesc-inband: I think there are interesting cases=20
> where one would like to initially define some sample=20
> descriptions which=20
> is carried out-of-band, e.g. in SDP, and where one later may=20
> want to add=20
> more. I think there should be a "both" value for this parameter. Also=20
> the acceptable value should be clearly defined.

Agree,  how about :

"spldesc=3Din"
"spldesc=3Dout"
"spldesc=3Dboth"

as possible values for in-band, out-of-band and both in- and out-of-band =
tx of sample descriptions?

>=20
> 26. Section 8.1 width and height parameters: What is the unit=20
> of these=20
> parameter?
Pixels, will be indicated.


>=20
> 27. Section 8.1 Interoperability consideration: I think there=20
> are some=20
> to mention. As this format will support 3GPP timed text from=20
> different=20
> 3GPP releases and some extension may be done in the future=20
> this should=20
> be discussed.

OK. Basically it is expected that 3GP files, also including timed text, =
will be extended while still keeping backwards compatibility, so old =
terminals can ignore attributes they don't understand.=20

>=20
> 28. Section 9, The encoding of the sample descriptions: You=20
> mention that=20
> they are compressed why base64 only provides expansion to allow for 8=20
> bit binary in a set of characters acceptable for text=20
> protocol. Base 64=20
> has an expansion factor that 4 8-bit bytes becomes 5 base64 8=20
> bit chars.

could you reword your question? I am not sure I understand what you =
mean. Base64 encoding was proposed in the last meeting in Vienna for =
h264 to reduce overhead in the transport of parameter sets instead of =
the usual base16 encoding which has an expansion factor of two.

>=20
> 29. Section 10.1  The "a=3Dcontrol" header in SDP should point to the=20
> track of a 3GP file, e.g.=20
> "a=3Dcontrol:rtsp://server/example.3gp/trackID=3D2".
> The meaning of "...example.3gp/text" is not defined.

OK, seems we forgot that.

>=20
> 30. Section 10.2 Example figures 1 and 2: I think there is something=20
> really wrong with the first figure: First it has SLEN which=20
> is SHALL NOT=20
> have. Secondly the FHDR header is not first. A receiver would=20
> not have=20
> any possibilities to decode these payloads as I see it.

Indeed. Cut&paste error.
>=20
> 31. section 11: The payload format shall be registering one=20
> MIME type,=20
> nothing more. There is no special action for IANA regarding the=20
> mentioned parameters.
>=20
>=20
OK


> 32. Section 13: Reference list comments
> - There is an updated version of reference 1 (V5.5.0).
>=20
> - Reference 2 should point to "14496-12 | 15444-12".
>=20
> - In my eyes reference 7, 8, 11 are normative.
>=20

OK

> 33. Appendix B. I don't see how an informative Annex can have=20
> normative=20
> language. This is nothing this specification can determine. Any=20
> requirements are already part of the 3GPP specs.

Yes, after re-reading the text I think references to the payload format =
itself should be removed and so reduce the scope to the merely =
informative.
=20
thanks again,=20

Jos=C3=A9

>=20
>=20
> Cheers
>=20
>=20
> Magnus Westerlund
>=20
> 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
>=20
>=20


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



From exim@www1.ietf.org  Fri Oct 24 09:04:34 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28863
	for <avt-archive@odin.ietf.org>; Fri, 24 Oct 2003 09:04:33 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AD1bw-0003EQ-GO
	for avt-archive@odin.ietf.org; Fri, 24 Oct 2003 09:04:14 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OD4CYS012416
	for avt-archive@odin.ietf.org; Fri, 24 Oct 2003 09:04:12 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AD1bm-0003BB-2E; Fri, 24 Oct 2003 09:04:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AD1bM-000398-KY
	for avt@optimus.ietf.org; Fri, 24 Oct 2003 09:03:37 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28851
	for <avt@ietf.org>; Fri, 24 Oct 2003 09:03:25 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AD1bL-00030I-00
	for avt@ietf.org; Fri, 24 Oct 2003 09:03:35 -0400
Received: from mail.pel.panasonic.de ([194.162.191.12])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AD1bK-00030E-00
	for avt@ietf.org; Fri, 24 Oct 2003 09:03:34 -0400
Received: from mcomreyj ([10.10.100.5]) by mail.pel.panasonic.de with Microsoft SMTPSVC(5.0.2195.6713);
	 Fri, 24 Oct 2003 15:03:29 +0200
Reply-To: <rey@panasonic.de>
From: =?utf-8?Q?Jos=C3=A9_Rey?= <rey@panasonic.de>
To: "'Magnus Westerlund'" <magnus.westerlund@ericsson.com>
Cc: "'IETF AVT WG'" <avt@ietf.org>, "'Dave Singer'" <singer@apple.com>,
        "Jan van der Meer \(E-mail\)" <jan.vandermeer@philips.com>,
        "Yoshinori Matsui \(E-mail\)" <matsui.yoshinori@jp.panasonic.com>
Date: Fri, 24 Oct 2003 15:03:26 +0200
Message-ID: <005201c39a2f$38102b30$05640a0a@panasonic.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200
Importance: Normal
In-Reply-To: <3F9904B4.7050103@ericsson.com>
X-OriginalArrivalTime: 24 Oct 2003 13:03:29.0169 (UTC) FILETIME=[38173010:01C39A2F]
Content-Transfer-Encoding: quoted-printable
Subject: [AVT] RE: Comments on draft-rey-avt-rtp-3gpp-timed-text-01.txt
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable

Hi,

please see inline.

> -----Original Message-----
> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]
> Sent: Friday, October 24, 2003 12:54 PM
> To: Rey Jose
> Cc: 'IETF AVT WG'; 'Dave Singer'; Jan van der Meer (E-mail); Yoshinori
> Matsui (E-mail)
> Subject: Re: Comments on draft-rey-avt-rtp-3gpp-timed-text-01.txt
>=20
>=20
> Hi Jos=C3=A9,
>=20
> See comments and clarifications below. I hope that you will=20
> be able to=20
> speed up the process for this, if you want to meet the deadlines you=20
> have targeted.
>=20
> Jos=C3=A9 Rey wrote:
>=20
> >=20
> >>8. Section 4. Timestamp definition: In the case of multiple=20
> >>samples in a=20
> >>packet, I think that the timestamp SHALL be set for the=20
> >>earliest, rather=20
> >>than first sample. Otherwise the duration rule will have problem. I=20
> >>think one should also point out that all samples have unique=20
> >>timestamps=20
> >>that is why one can use the TS as a identifier of which packet the=20
> >>fragments belong to.
> >>
> >=20
> >=20
> > This is described in the text as you say above, as no=20
> negative SDUR values are defined.  It seems this needs=20
> further clarification...
> >=20
> Yes, I think so.
>=20
> >=20
> >>10. Section 4. Sequence number handling. I think there are need to=20
> >>consider sequence number in the case of FU packets to get the right=20
> >>assembly order. In general I think there is a lack of definition or=20
> >>explanation of how a receiver determines what is the first and last=20
> >>packet of fragment.
> >=20
> >=20
> > Right, this is not specified. I think the best solution=20
> here is to add (reuse) a new (the fragment) header field=20
> carrying some type of fragment numbering for those having the=20
> same TS. This is much easier. =20
> >=20
>=20
> Yes that will of course work. However it also gives one more=20
> insecurity,=20
> as you will not know when you should have received all fragments. The=20
> potential problem as I see it if not all fragments are required to be=20
> sent in RTP sequence number order is that the receiver having=20
> lost some=20
> packets from the start can't determine if the lost packets contained=20
> fragments or not. However there might be some other advantage=20
> of doing=20
> as you propose it.
>=20
> >=20
> >>12. Figure 1, 2, 3, 4. I think there is not clear how a=20
> >>receiver will be=20
> >>able to distinguish between the cases.=20
> >=20
> >=20
> > This is the same observation as in item 10 above.
> >=20
> >=20
> >>The only one that has an=20
> >>explanation at all is the case with FHDR first. How a=20
> >>receiver detects=20
> >>the presence or not of a SPLDESC I have no idea.=20
> >=20
> >=20
> > The presence of SPLDESC is signalled using SDP. The SPLDESC=20
> is always at least one byte long =3D the entry count byte.  A=20
> value of zero is allowed for the entry count field.
> >=20
> > As for the presence of the rest: FHDR is indicated in SDP=20
> and for THDR in the FHDR itself (T=3D1)
> >=20
>=20
> So you are saying that you will have a different payload type for=20
> payloads with SPLDESC compared to the ones without.=20

No. This is a remainder from the initial purpose for SPLDESC: live =
streaming. In live streaming there is no need to use the  4 PTs =
simultaneously.=20

After all, with all these complications and changes/additions of =
fucntionality it seems reasonable to include the flags for this and the =
fragmentation headers in the fixed header bytes.

> Then you=20
> will have a=20
> different payload for presence of the FHDR or not. That makes it=20
> necessary to have four payload types to allow for all four=20
> combinations.
>=20
> I think you should strongly reconsider the usage of payload type=20
> multiplexing for this functionality. Problems I see with payload type=20
> multiplexing:
>=20
> - The eventual exhaustion of the payload format space. If the payload=20
> formats starts using multiple payload formats for normal cases the=20
> choice of using PT in the RTP retransmission format is probably a bad=20
> one, as it doubles the number of used payload formats.
> - The need for having MIME parameter declaration for each and=20
> everyone=20
> of the payload format configurations.
>=20
> Due to this and the mitigating factor that this payload format is not=20
> extremely high packet rate to begin with, the inclusion of 1 byte per=20
> header will not cause a massive increase in overhead.
>=20
> I would propose that you actually spend a byte for indicating the=20
> necessary header types, allowing for the use of a single=20
> payload format=20
> in the normal cases.
>=20

OK, the SDP fix is not a good idea. Some bits for flags in the fixed =
header seem necessary.

> >=20
> >>When I have this=20
> >>complains I would also like to point out that using the=20
> >>payload types is=20
> >>not a good solution, at least not as the current parameter=20
> mapping is=20
> >>done. When one has fragments one in fact duplicates all the=20
> >>track header=20
> >>information and sample descriptions sent in the SDP. As the=20
> fmtp line=20
> >>can become rather big for this format I don't see this as an=20
> >>acceptable=20
> >>solution.
> >=20
> >=20
> > Correct. To avoid this, is it not possible to associate the=20
> sample descriptions and just write the contents in one line?=20
> I think this should be possible through some new SDP=20
> attribute and defining the behaviour of the receiver. This=20
> way the PT-multiplexing still works fine.
> >=20
>=20
> As I point out above I don't think the usage PT multiplexing is the=20
> correct choice for this format. I would also like to avoid having to=20
> create a copy operation for the fmtp fields in SDP. We don't=20
> need more=20
> functionality in SDP, we need a better session description format.
>=20

Yes. It doesn't seem to be appropriate, the comments above apply.

> >=20
> >>13. Section 4.1, page 8:
> >>"  The composition of the THDR depends on whether the text sample is
> >>    fragmented or not.  In particular:
> >>
> >>    - SLEN MUST NOT be present if the RTP packet contains a=20
> >>text sample
> >>    fragment.  If the RTP packet carries one or several=20
> non-fragmented
> >>    samples SLEN MUST be present for every text sample, as in=20
> >>Figure 1."
> >>
> >>Why should one not have a SLEN field for a fragment?
> >=20
> >=20
> > The motivation for SLEN is for packets containing several=20
> whole text samples, to allow the receiver to jump from one=20
> sample to another, as a kind of indexing. In the case the RTP=20
> packet only contains one text sample, SLEN is theoretically=20
> not needed; however we thought making an exception here would=20
> make it all too confusing.=20
> >=20
>=20
> Yes, I agree with your comments are bad, but you haven't answered why=20
> there is a need for having a SLEN exception for the fragmented case.
> >=20

see below

> >>In my opinion=20
> >>knowing the total length of the fragmented sample allows one=20
> >>to allocate=20
> >>the correct buffer for that sample.
> >>
> >=20
> > I think this is an implementation issue.  In general packet=20
> sizes are not included in RTP and buffering works anyway. I=20
> don't see why the sizes should be used in this particular=20
> case to reserve buffer in advance, specially given the low bitrates.
> >=20
>=20
> Yes, I would agree that if would not be needed in the normal=20
> case, but=20
> we are in fact talking about fragmented samples that has no=20
> given size=20
> limit. They could in fact be as large as 100kbytes.=20
> Depending on the=20
> unlimited sample size
> I think it would be good to allow a receiver to=20
> determine how big this sample is before trying to assemble=20
> it. That it=20
> also helps the implementations in some cases to do this=20
> efficiently is=20
> just a bonus.


If it is needed, the upper limit is given by SLEN, <=3D64Kbytes =
(16bits). Anyway, the headers have to be re-arranged. We shall then take =
your comments into account.=20

>=20
> >=20
> >>14. Section 4.2.2 I am not convinced that the fragmentation=20
> >>rules allow=20
> >>for all cases to have the sample reconstructed. For example=20
> is seems=20
> >>that multiple fragments of boxes will not be guaranteed to be=20
> >>reconstructed in the correct order unless some other information is=20
> >>provided.
> >=20
> >=20
> > I think you mean the same as in 10 and 12 with the reassembly.=20
>=20
> Yes, at least I think so. There has been a while since I wrote these=20
> comments.
>=20
> >=20
> >=20
> >>In general I would like to have a discussion of the need for the=20
> >>advanced fragmentation formats that is defined. Could not a simple=20
> >>fragmentation requiring all parts be sufficient. Are really=20
> >>there enough=20
> >>advantage of using the fragments when some are missing=20
> >>enough. Will it=20
> >>also not in some cases result in something that is more=20
> confusing the=20
> >>not presenting it at all would.
> >>
> >>If one keeps this advance fragmentation then it is really=20
> need for a=20
> >>introduction part that talks about why and how this works.
> >>
> >>15. Section 4.2 There is need for having guidelines on how to=20
> >>fragment.=20
> >>I think there are some fragmentation points that are advantageous.
> >=20
> >=20
> > We developed the fragmentation headers because 3GPP timed=20
> text allows in principle for bigger packets (until 2048=20
> bytes) and didn't want to leave that out. We also didn't=20
> assume the use of FEC, for simplicity.
> >=20
> > We realize that the FHDR increments the complexity of the=20
> draft. If fragmentation happens seldom, we agree it is=20
> convenient to reduce the complexity of the headers, i.e. to a=20
> mere counter of the fragments. Therefore we would agree to=20
> simplify them if no one else has an application/use case for=20
> that. Does anyone feel the advanced fragmentation headers as=20
> they are in the draft now are needed?
> >=20
>=20
> I don't now about the answer to your question.
>=20
> >>18. Section 4.3: "   - All SIDX values present in the SPLDESC=20
> >>field of=20
> >>an RTP packet MUST be present in at least one of the text=20
> >>samples in the=20
> >>payload." I interpret this rule saying that within a RTP=20
> packet which=20
> >>carries the Sample descriptions the sample description must=20
> >>be included=20
> >>in the sample part.=20
> >=20
> >=20
> > This is not what is meant; descriptions are only present=20
> once. What we meant to be present in both SPLDESC and text=20
> samples is the SIDX value to be able to pair them. This has=20
> two reasons: 1) in principle, SPLDESC was thought for live=20
> streaming and 2) feedback might not always be available, so=20
> that the sender doesn't know the received descriptions. But=20
> it might be used for other things, as you point out. So we=20
> can abolish the restriction and make a note saying that the=20
> sender shall provide the means for the receiver to have all=20
> descriptions available for the received text samples whether=20
> there's feedback or not: using retransmissions, include the=20
> descriptions again or protect them with FEC appropriately.
> >=20
>=20
> I think that sounds more reasonable.
>=20
> >=20
> >=20
> >=20
> >>However I don't see a reason for this. All sample=20
> >>descriptions MUST be cached and can at any time be used.=20
> >>Therefore I see=20
> >>some advantage of allowing sample description only packets=20
> >>for example.=20
> >>  They can be given high protection with FEC. They can be=20
> >>given highest=20
> >>priority for retransmission. They can be sent in advance and=20
> >>verified as=20
> >>arrived if explicit packet loss vectors are used. So what is=20
> >>the reason.
> >>
> >=20
> > I like the idea of using sample-description-only packets. A=20
> bit of the initial entry count field could be used to=20
> indicate there are any (SIDX,SPLATTR) pairs following or is=20
> just a sample-description-only packet.
> >=20
>=20
> Good, I hope it can be implemented without a lot of complexity.
>=20
> >=20
> >=20
> >>20. Section 5.1: Why is not FEC with RFC 2733 mentioned?
> >>
> >=20
> > is an option...can be included in next revision.
>=20
> I think this is one of the formats that may really need to=20
> use FEC for=20
> at least any SPDLDESCRs, this is especially for multicast=20
> distribution=20
> cases, but also for unicast.
>=20
> >>22. Section 8.1: Fragment variable: The values allow to be=20
> given are=20
> >>they "one" and "zero" or "1" or "0"?=20
> >>
> >=20
> > "fragment=3D0" and "fragment=3D1" are possible values.
>=20
> Then please clarify that.
>=20
> >=20
> >=20
> >>Also I don't like this=20
> >>variable as=20
> >>it results in duplication of a rather long "a=3Dfmtp" line.
> >=20
> >=20
> > what do you propose instead?
>=20
> As I have written previous I would suggest that you drop the whole PT=20
> multiplexing for presence or not of FHDR, etc.
>=20

Yes, the SDP fix seems too complex, thanks.
> >=20
> >>25. Section 8.1: spldesc-inband: I think there are=20
> interesting cases=20
> >>where one would like to initially define some sample=20
> >>descriptions which=20
> >>is carried out-of-band, e.g. in SDP, and where one later may=20
> >>want to add=20
> >>more. I think there should be a "both" value for this=20
> parameter. Also=20
> >>the acceptable value should be clearly defined.
> >=20
> >=20
> > Agree,  how about :
> >=20
> > "spldesc=3Din"
> > "spldesc=3Dout"
> > "spldesc=3Dboth"
> >=20
> > as possible values for in-band, out-of-band and both in-=20
> and out-of-band tx of sample descriptions?
>=20
> Looks good
>=20
> >=20
> >>28. Section 9, The encoding of the sample descriptions: You=20
> >>mention that=20
> >>they are compressed why base64 only provides expansion to=20
> allow for 8=20
> >>bit binary in a set of characters acceptable for text=20
> >>protocol. Base 64=20
> >>has an expansion factor that 4 8-bit bytes becomes 5 base64 8=20
> >>bit chars.
> >=20
> >=20
> > could you reword your question? I am not sure I understand=20
> what you mean. Base64 encoding was proposed in the last=20
> meeting in Vienna for h264 to reduce overhead in the=20
> transport of parameter sets instead of the usual base16=20
> encoding which has an expansion factor of two.
> >=20
>=20
> YEs, this is nit picking. If you compare the binary save sample=20
> description, that will have a size of X. Then the BASE64=20
> encoded will no=20
> t be compressed but rather expanded in regards to the binary.=20
> OF course=20
> it is better than BASE16, but that what not what I was seeing as the=20
> base line.
>=20
>=20

cheers,


Jos=C3=A9


> Cheers
>=20
> Magnus Westerlund
>=20
> 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
>=20
>=20


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



From exim@www1.ietf.org  Fri Oct 24 09:23:22 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29480
	for <avt-archive@odin.ietf.org>; Fri, 24 Oct 2003 09:23:22 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AD1u9-000878-NQ
	for avt-archive@odin.ietf.org; Fri, 24 Oct 2003 09:23:02 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9ODN1uO031158
	for avt-archive@odin.ietf.org; Fri, 24 Oct 2003 09:23:01 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AD1u8-00086L-SM; Fri, 24 Oct 2003 09:23:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACzVl-0002BR-In
	for avt@optimus.ietf.org; Fri, 24 Oct 2003 06:49:41 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24862
	for <avt@ietf.org>; Fri, 24 Oct 2003 06:49:28 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACzVh-0001Mj-00
	for avt@ietf.org; Fri, 24 Oct 2003 06:49:37 -0400
Received: from pmesmtp02.wcom.com ([199.249.20.2])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACzVg-0001MD-00
	for avt@ietf.org; Fri, 24 Oct 2003 06:49:36 -0400
Received: from dgismtp05.wcomnet.com ([166.38.58.88])
 by firewall.wcom.com (Iplanet MTA 5.2)
 with ESMTP id <0HN900HKWCGJID@firewall.wcom.com> for avt@ietf.org; Fri,
 24 Oct 2003 10:43:31 +0000 (GMT)
Received: from dgismtp05.wcomnet.com by dgismtp05.wcomnet.com
 (iPlanet Messaging Server 5.1 HotFix 0.7 (built May  7 2002))
 with SMTP id <0HN900001CGJL6@dgismtp05.wcomnet.com>; Fri,
 24 Oct 2003 10:43:31 +0000 (GMT)
Received: from hsinnreich2 ([166.50.122.3])
 by dgismtp05.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7
 2002)) with ESMTP id <0HN90002CCGH36@dgismtp05.wcomnet.com>; Fri,
 24 Oct 2003 10:43:31 +0000 (GMT)
Date: Fri, 24 Oct 2003 05:43:30 -0500
From: Henry Sinnreich <Henry.Sinnreich@mci.com>
In-reply-to: <4A3384433CE2AB46A63468CB207E209D4F6867@zoe.office.snowshore.com>
To: "'Eric Burger'" <eburger@snowshore.com>, avt@ietf.org
Message-id: <0HN90002FCGI36@dgismtp05.wcomnet.com>
Organization: WorldCom, Inc.
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Mailer: Microsoft Office Outlook, Build 11.0.5329
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
Thread-index: AcOZzl8H0LFHlI99RPSdm3A6+TjMfAATJtOg
Content-Transfer-Encoding: 7bit
Subject: [AVT] RE: draft-basso-avt-videoconreq-00: H.245 and Section 7.8
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

I agree that the requirement is pure non-sense.

      The codec control transport protocol MUST allow inter-operability 
      with the most commonly deployed IP-based video communication 
      protocols, such as H.323, H.324 and H.324M.

There are gateways between IETF SIP based systems and legacy
implementations.

Thanks, Henry

Henry Sinnreich

MCI
400 International Parkway
Richardson, Texas 75081
USA

Have you disconnected the PBX?

-----Original Message-----
From: Eric Burger [mailto:eburger@snowshore.com] 
Sent: Thursday, October 23, 2003 10:45 PM
To: avt@ietf.org
Subject: draft-basso-avt-videoconreq-00: H.245 and Section 7.8

I am concerned about the potential direction the requirement stated in
section 7.8 may bring us.  Here is the text:

  7.8 Interoperability with other protocols 
    
      The codec control transport protocol MUST allow inter-operability 
      with the most commonly deployed IP-based video communication 
      protocols, such as H.323, H.324 and H.324M.


What does this mean.  On one level, it sounds straightforward.  If I have a
video system, and you have a video system, then we should be able to
communicate.  In fact, given a lexicon, how could one NOT create mappings
between different grammars for that lexicon?  In that sense, this is a
non-requirement and should be removed.

However, at another level, and taken in conjunction with the statement of
section 6.3 (protocol duplication), it is hideous.  Direct interoperability
means that we should take the common signaling denominator for these three
protocols, namely H.245.

H.245 sound innocent enough, as it is independent of H.323 and H.324.
However, when one looks closer, we find a lot of overlap between H.245 and
SDP and (please look at the protocol) SIP.

I would offer that if H.245, or something like H.245, is what is being
thought of for this requirement, then there is no reason for this draft.
Use H.323/H.324/H.324m/H.320 and Be Happy.

If there is any requirement that should be in the document, it is an
emphasis on Section 6.2.  I would offer that the call control and content
negotiation capabilities of H.245 "break" SIP and SDP (or conversely, would
not interoperate in the ITU direction).  Since this is the IETF, I really
only care about not breaking IETF protocols.  You can break the broken
protocols to your hearts content :-)



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



From exim@www1.ietf.org  Fri Oct 24 10:51:39 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05402
	for <avt-archive@odin.ietf.org>; Fri, 24 Oct 2003 10:51:39 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AD3Hc-0002an-Ly
	for avt-archive@odin.ietf.org; Fri, 24 Oct 2003 10:51:20 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OEpKFl009921
	for avt-archive@odin.ietf.org; Fri, 24 Oct 2003 10:51:20 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AD3HK-0002Vs-Nc; Fri, 24 Oct 2003 10:51:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AD3GT-0002RH-Sb
	for avt@optimus.ietf.org; Fri, 24 Oct 2003 10:50:09 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05139
	for <avt@ietf.org>; Fri, 24 Oct 2003 10:49:57 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AD3GR-0004KN-00
	for avt@ietf.org; Fri, 24 Oct 2003 10:50:07 -0400
Received: from cs.columbia.edu ([128.59.16.20])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AD3GQ-0004KK-00
	for avt@ietf.org; Fri, 24 Oct 2003 10:50:06 -0400
Received: from razor.cs.columbia.edu (IDENT:root@razor.cs.columbia.edu [128.59.16.8])
	by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id h9OEo0LZ029041
	for <avt@ietf.org>; Fri, 24 Oct 2003 10:50:00 -0400 (EDT)
Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1])
	by razor.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h9OEntv03426
	for <avt@ietf.org>; Fri, 24 Oct 2003 10:50:00 -0400
Message-ID: <3F993C15.8020300@cs.columbia.edu>
Date: Fri, 24 Oct 2003 10:49:57 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030916
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: avt@ietf.org
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [AVT] FEC (RFC 2733) implementations?
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Are there any publically available audio applications that support RFC 
2733 (or follow-on ID's)? We want to test interoperability with our own 
implementation.

Thanks.


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



From exim@www1.ietf.org  Fri Oct 24 14:21:34 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21426
	for <avt-archive@odin.ietf.org>; Fri, 24 Oct 2003 14:21:34 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AD6Yk-00006q-Fj
	for avt-archive@odin.ietf.org; Fri, 24 Oct 2003 14:21:14 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OILDlx000384
	for avt-archive@odin.ietf.org; Fri, 24 Oct 2003 14:21:13 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AD6YZ-0008Uh-D3; Fri, 24 Oct 2003 14:21:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AD6Xr-0008G2-Fc
	for avt@optimus.ietf.org; Fri, 24 Oct 2003 14:20:19 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21346
	for <avt@ietf.org>; Fri, 24 Oct 2003 14:20:08 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AD6Xo-00027F-00
	for avt@ietf.org; Fri, 24 Oct 2003 14:20:16 -0400
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AD6Xo-00024i-00
	for avt@ietf.org; Fri, 24 Oct 2003 14:20:16 -0400
Received: from cisco.com (171.68.223.138)
  by sj-iport-5.cisco.com with ESMTP; 24 Oct 2003 11:22:23 -0700
Received: from nismail-w2k02.cisco.com (sjc-vpn1-134.cisco.com [10.21.96.134])
	by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h9OIJhbe012575
	for <avt@ietf.org>; Fri, 24 Oct 2003 11:19:43 -0700 (PDT)
Message-Id: <4.3.2.7.2.20031024110944.00b3c568@VTG-UM-E2K1>
X-Sender: nismail@VTG-UM-E2K1
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 24 Oct 2003 11:19:41 -0700
To: <avt@ietf.org>
From: Nermeen Ismail <nismail@cisco.com>
Subject: Re: [AVT] draft-basso-avt-videoconreq-00: H.245 and Section 7.8
In-Reply-To: <4A3384433CE2AB46A63468CB207E209D4F6867@zoe.office.snowshor
 e.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>


>I am concerned about the potential direction the requirement stated in 
>section 7.8 may bring us.  Here is the text:
>
>   7.8 Interoperability with other protocols
>
>       The codec control transport protocol MUST allow inter-operability
>       with the most commonly deployed IP-based video communication
>       protocols, such as H.323, H.324 and H.324M.
>

It needs rewording. The intent was that to make sure that if we are to use 
one of the existing IETF protocols to carry these commands that
there can be a way to inter-operate with the H.323 systems (i.e. build 
gateways) without breaking other usages of
that specific IETF protocol.

nermeen









>What does this mean.  On one level, it sounds straightforward.  If I have 
>a video system, and you have a video system, then we should be able to 
>communicate.  In fact, given a lexicon, how could one NOT create mappings 
>between different grammars for that lexicon?  In that sense, this is a 
>non-requirement and should be removed.
>
>However, at another level, and taken in conjunction with the statement of 
>section 6.3 (protocol duplication), it is hideous.  Direct 
>interoperability means that we should take the common signaling 
>denominator for these three protocols, namely H.245.
>
>H.245 sound innocent enough, as it is independent of H.323 and 
>H.324.  However, when one looks closer, we find a lot of overlap between 
>H.245 and SDP and (please look at the protocol) SIP.
>
>I would offer that if H.245, or something like H.245, is what is being 
>thought of for this requirement, then there is no reason for this 
>draft.  Use H.323/H.324/H.324m/H.320 and Be Happy.
>
>If there is any requirement that should be in the document, it is an 
>emphasis on Section 6.2.  I would offer that the call control and content 
>negotiation capabilities of H.245 "break" SIP and SDP (or conversely, 
>would not interoperate in the ITU direction).  Since this is the IETF, I 
>really only care about not breaking IETF protocols.  You can break the 
>broken protocols to your hearts content :-)
>
>
>
>_______________________________________________
>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 exim@www1.ietf.org  Fri Oct 24 14:37:24 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22106
	for <avt-archive@odin.ietf.org>; Fri, 24 Oct 2003 14:37:23 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AD6o4-0004fy-Lz
	for avt-archive@odin.ietf.org; Fri, 24 Oct 2003 14:37:04 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OIb41u017953
	for avt-archive@odin.ietf.org; Fri, 24 Oct 2003 14:37:04 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AD6o1-0004cT-E9; Fri, 24 Oct 2003 14:37:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AD6nO-0004Oa-CJ
	for avt@optimus.ietf.org; Fri, 24 Oct 2003 14:36:22 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22080
	for <avt@ietf.org>; Fri, 24 Oct 2003 14:36:11 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AD6nL-0002KF-00
	for avt@ietf.org; Fri, 24 Oct 2003 14:36:19 -0400
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AD6nL-0002Jw-00
	for avt@ietf.org; Fri, 24 Oct 2003 14:36:19 -0400
Received: from cisco.com (171.68.223.138)
  by sj-iport-5.cisco.com with ESMTP; 24 Oct 2003 11:38:27 -0700
Received: from nismail-w2k02.cisco.com (sjc-vpn1-134.cisco.com [10.21.96.134])
	by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h9OIZlbe023307
	for <avt@ietf.org>; Fri, 24 Oct 2003 11:35:47 -0700 (PDT)
Message-Id: <4.3.2.7.2.20031024112624.00b54c38@VTG-UM-E2K1>
X-Sender: nismail@VTG-UM-E2K1
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 24 Oct 2003 11:35:45 -0700
To: <avt@ietf.org>
From: Nermeen Ismail <nismail@cisco.com>
Subject: Re: [AVT] draft-basso-avt-videoconreq-00: What really is used?
In-Reply-To: <4A3384433CE2AB46A63468CB207E209D4F6868@zoe.office.snowshor
 e.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>

The most commonly used commands are the videoFastUpdate, the pictureFreeze 
and the rateRequest. Not clear if really RateRequest
makes sense or not cause you can just re-negotiate the bitrate using the 
signaling path.

Temporal-Spatial tradeoff and VideoFastUpdateGoB are not commonly used. The 
requirement for including them came more from
people designing videophones for the cellular market.

nermeen




>Looking through the codec commands, I am struck by a nagging question: How 
>much of this do people really use?
>
>VideoFastUpdatePicture clearly gets used.  However, does anyone really USE 
>the quality trade-off commands (e.g., RateRequest, Temporal/Spatial)?  I 
>understand the use cases, I just wonder if it gets used.
>
>Likewise, does anyone EVER use VideoFastUpdateGOB?  Again, I understand 
>the use case, but in reality, most decoders, when they sense a messed up 
>picture, will issue a VideoFastUpdatePicture request.
>
>
>_______________________________________________
>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 exim@www1.ietf.org  Fri Oct 24 19:29:29 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05446
	for <avt-archive@odin.ietf.org>; Fri, 24 Oct 2003 19:29:29 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ADBMk-0000Mp-Be
	for avt-archive@odin.ietf.org; Fri, 24 Oct 2003 19:29:10 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9ONTAjR001408
	for avt-archive@odin.ietf.org; Fri, 24 Oct 2003 19:29:10 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ADBMa-0000KA-VX; Fri, 24 Oct 2003 19:29:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ADBMJ-0000G8-7D
	for avt@optimus.ietf.org; Fri, 24 Oct 2003 19:28:43 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05430
	for <avt@ietf.org>; Fri, 24 Oct 2003 19:28:31 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ADBMH-000673-00
	for avt@ietf.org; Fri, 24 Oct 2003 19:28:41 -0400
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ADBMH-00066b-00
	for avt@ietf.org; Fri, 24 Oct 2003 19:28:41 -0400
Received: from SCOTTF-W2K5.cisco.com (dhcp-128-107-141-144.cisco.com [128.107.141.144])
	by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h9ONS9ev016638
	for <avt@ietf.org>; Fri, 24 Oct 2003 16:28:09 -0700 (PDT)
Message-Id: <4.3.1.2.20031024160826.02004ee8@VTG-UM-E2K1>
X-Sender: nismail@VTG-UM-E2K1
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Fri, 24 Oct 2003 16:28:49 -0700
To: <avt@ietf.org>
From: Nermeen Ismail <nismail@cisco.com>
Subject: Re: [AVT] draft-basso-avt-videoconreq-00: H.245 and Section 7.8
In-Reply-To: <4A3384433CE2AB46A63468CB207E209D4F6867@zoe.office.snowshor
 e.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>





>I am concerned about the potential direction the requirement stated in 
>section 7.8 may bring us.  Here is the text:
>
>   7.8 Interoperability with other protocols
>
>       The codec control transport protocol MUST allow inter-operability
>       with the most commonly deployed IP-based video communication
>       protocols, such as H.323, H.324 and H.324M.
>
>
>What does this mean.  On one level, it sounds straightforward.  If I have 
>a video system, and you have a video system, then we should be able to 
>communicate.  In fact, given a lexicon, how could one NOT create mappings 
>between different grammars for that lexicon?  In that sense, this is a 
>non-requirement and should be removed.
>
>However, at another level, and taken in conjunction with the statement of 
>section 6.3 (protocol duplication), it is hideous.  Direct 
>interoperability means that we should take the common signaling 
>denominator for these three protocols, namely H.245.
>
>H.245 sound innocent enough, as it is independent of H.323 and 
>H.324.  However, when one looks closer, we find a lot of overlap between 
>H.245 and SDP and (please look at the protocol) SIP.
>
>I would offer that if H.245, or something like H.245, is what is being 
>thought of for this requirement, then there is no reason for this 
>draft.  Use H.323/H.324/H.324m/H.320 and Be Happy.

Would rewording the statement from:
"
The codec control mechanism SHOULD NOT duplicate the functionality
       of existing protocols."

to :
"
The codec control mechanism SHOULD NOT duplicate the functionality
       of existing IETF protocols."

calrify the text?.

6.3 intent is to say that if thre is already an IETF protocol that can be 
used for the transport of these commands then we should do that
rather than come up with a new different protocol. Putting it bluntly if 
RTCP is not going to be used as the transport mechanism then
there should be good reasons for that.


I think so far the options are:
- Use RTCP with the AVP feedback extensions and create new payload-specific 
FB messages for things that are missing such as pictureFreeze etc.
- Use a different protocol (TBD) to carry these 
contrl/feedback/notification messages and use SDP to initiate it. It would 
take such a sad sad
   person to suggest H.245 to be that protocol :-).

It is time for a draft that looks at which one is a better go and makes a 
concrete proposal.

nermeen









>If there is any requirement that should be in the document, it is an 
>emphasis on Section 6.2.  I would offer that the call control and content 
>negotiation capabilities of H.245 "break" SIP and SDP (or conversely, 
>would not interoperate in the ITU direction).  Since this is the IETF, I 
>really only care about not breaking IETF protocols.  You can break the 
>broken protocols to your hearts content :-)
>
>
>
>_______________________________________________
>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 exim@www1.ietf.org  Fri Oct 24 19:51:01 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05991
	for <avt-archive@odin.ietf.org>; Fri, 24 Oct 2003 19:51:01 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ADBhX-0002kU-Gn
	for avt-archive@odin.ietf.org; Fri, 24 Oct 2003 19:50:40 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9ONodgQ010523
	for avt-archive@odin.ietf.org; Fri, 24 Oct 2003 19:50:39 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ADBgw-0002dr-S8; Fri, 24 Oct 2003 19:50:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ADBfw-0002YM-QL
	for avt@optimus.ietf.org; Fri, 24 Oct 2003 19:49:01 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05914
	for <avt@ietf.org>; Fri, 24 Oct 2003 19:48:51 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ADBfu-0006Ka-00
	for avt@ietf.org; Fri, 24 Oct 2003 19:48:58 -0400
Received: from mail-out3.apple.com ([17.254.13.22])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ADBfu-0006KH-00
	for avt@ietf.org; Fri, 24 Oct 2003 19:48:58 -0400
Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225])
	by mail-out3.apple.com (8.12.10/8.12.9) with ESMTP id h9ONmSrY013466
	for <avt@ietf.org>; Fri, 24 Oct 2003 16:48:28 -0700 (PDT)
Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T657b677a02118064e13f0@mailgate1.apple.com>;
 Fri, 24 Oct 2003 16:47:55 -0700
Received: from [17.202.35.52] (singda.apple.com [17.202.35.52])
	by scv1.apple.com (8.12.9/8.12.9) with ESMTP id h9ONlwwx018566;
	Fri, 24 Oct 2003 16:47:58 -0700 (PDT)
Mime-Version: 1.0
X-Sender: singer@mail.apple.com (Unverified)
Message-Id: <p0600208dbbbf696a87eb@[17.202.35.52]>
Date: Fri, 24 Oct 2003 16:46:48 -0700
To: gen-sys@advent.ee.columbia.edu, avt@ietf.org,
        3GPP_TSG_SA_WG4@LIST.ETSI.ORG
From: Dave Singer <singer@apple.com>
Cc: "Glenn A. Adams" <glenn@xfsi.com>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Subject: [AVT] Soliciting Feedback on Timed Text (TT) Authoring Format 1.0 Use
 Cases  and Requirements
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>

Friends in MPEG-4 systems, IETF AVT, and 3GPP SA4.

The timed text working group at W3C is working, as you know, on an 
authoring format for Timed Text.  There is a public document on which 
your comments are solicited, as we reach this mile-stone in the work. 
I forward the formal request from the chairman, below.

* * * * * * * * * * * * * *


The Timed Text Working Group invites your working group(s) to comment 
on the 2nd public draft of "Timed Text (TT) Authoring Format 1.0 Use 
Cases and Requirements" [1]. We expect to accept and process comments 
that we receive on or before Dec 1, after which time the Timed Text 
Working Group intends to publish this document (possibly with changes 
to address comments) as a "Working Group Note".

Please send comments to the public reflector <public-tt@w3.org>, 
which is archived at [2].

Regards,
Glenn Adams, Chair TT WG

[1] http://www.w3.org/TR/2003/WD-tt-af-1-0-req-20030915/
[2] http://lists.w3.org/Archives/Public/public-tt/
-- 
David Singer
Apple Computer/QuickTime

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



From exim@www1.ietf.org  Sun Oct 26 13:12:35 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23512
	for <avt-archive@odin.ietf.org>; Sun, 26 Oct 2003 13:12:35 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ADpNA-0000nD-N1
	for avt-archive@odin.ietf.org; Sun, 26 Oct 2003 13:12:16 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9QICGBI003042
	for avt-archive@odin.ietf.org; Sun, 26 Oct 2003 13:12:16 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ADpMv-0000mL-2N; Sun, 26 Oct 2003 13:12:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ADpM6-0000jM-2S
	for avt@optimus.ietf.org; Sun, 26 Oct 2003 13:11:10 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23473
	for <avt@ietf.org>; Sun, 26 Oct 2003 13:10:58 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ADpM4-00078m-00
	for avt@ietf.org; Sun, 26 Oct 2003 13:11:08 -0500
Received: from [202.97.224.98] (helo=mail.hl.cn)
	by ietf-mx with smtp (Exim 4.12)
	id 1ADpM3-00078j-00
	for avt@ietf.org; Sun, 26 Oct 2003 13:11:07 -0500
Received: from mail.hl.cn([127.0.0.1]) by mail.hl.cn(AIMC 2.9.5.6)
	with SMTP id jm23f9c2bc0; Mon, 27 Oct 2003 01:59:52 +0800
Received: from asgard.ietf.org([132.151.6.40]) by mail.hl.cn(AIMC 2.9.5.6)
	with SMTP id jm83f975915; Thr, 23 Oct 2003 07:59:01 +0800
Received: from majordomo by asgard.ietf.org with local (Exim 4.14)
	id 1ACSXd-00040Q-PM
	for ietf-announce-list@asgard.ietf.org; Wed, 22 Oct 2003 19:37:25 -0400
Received: from ietf.org ([10.27.2.28])
	by asgard.ietf.org with esmtp (Exim 4.14)
	id 1ACRmX-0003rW-Ab
	for all-ietf@asgard.ietf.org; Wed, 22 Oct 2003 18:48:45 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03079;
	Wed, 22 Oct 2003 18:48:33 -0400 (EDT)
Message-Id: <200310222248.SAA03079@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: avt@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Wed, 22 Oct 2003 18:48:33 -0400
Precedence: bulk
X-AIMC-AUTH: (null)
X-AIMC-MAILFROM: owner-ietf-announce@ietf.org
X-AIMC-AUTH: (null)
X-AIMC-MAILFROM: Internet-Drafts@ietf.org
Subject: [AVT] I-D ACTION:draft-lazzaro-avt-rtp-framing-contrans-02.txt
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Framing RTP and RTCP Packets over Connection-Oriented 
			  Transport
	Author(s)	: J. Lazzaro
	Filename	: draft-lazzaro-avt-rtp-framing-contrans-02.txt
	Pages		: 8
	Date		: 2003-10-22
	
This memo defines a method for framing Real Time Protocol (RTP) and
Real Time Control Protocol (RTCP) packets onto connection-oriented
transport (such as TCP and TLS).  The memo also defines how to
specify the framing method in a session description.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-lazzaro-avt-rtp-framing-contrans-02.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-lazzaro-avt-rtp-framing-contrans-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-lazzaro-avt-rtp-framing-contrans-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-10-22182904.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-lazzaro-avt-rtp-framing-contrans-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-lazzaro-avt-rtp-framing-contrans-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-10-22182904.I-D@ietf.org>

--OtherAccess--

--NextPart--




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



From exim@www1.ietf.org  Sun Oct 26 17:24:26 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00492
	for <avt-archive@odin.ietf.org>; Sun, 26 Oct 2003 17:24:26 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ADtIu-0001IE-BS
	for avt-archive@odin.ietf.org; Sun, 26 Oct 2003 17:24:08 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9QMO8Nn004968
	for avt-archive@odin.ietf.org; Sun, 26 Oct 2003 17:24:08 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ADtIm-0001H7-IC; Sun, 26 Oct 2003 17:24:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ADtI8-00019a-GY
	for avt@optimus.ietf.org; Sun, 26 Oct 2003 17:23:20 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00164
	for <avt@ietf.org>; Sun, 26 Oct 2003 17:23:07 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ADtI6-0001S5-00
	for avt@ietf.org; Sun, 26 Oct 2003 17:23:18 -0500
Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com)
	by ietf-mx with smtp (Exim 4.12)
	id 1ADtI5-0001Rl-00
	for avt@ietf.org; Sun, 26 Oct 2003 17:23:17 -0500
Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap 
	 id 11706; Sun, 26 Oct 2003 17:30:39 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [AVT] draft-basso-avt-videoconreq-00: H.245 and Section 7.8
Date: Sun, 26 Oct 2003 17:22:47 -0500
Message-ID: <4A3384433CE2AB46A63468CB207E209D4F6881@zoe.office.snowshore.com>
Thread-Topic: [AVT] draft-basso-avt-videoconreq-00: H.245 and Section 7.8
Thread-Index: AcOahq9EpkVtbkxMTvGbng5Tp5cwQABbRYhQ
From: "Eric Burger" <eburger@snowshore.com>
To: "Nermeen Ismail" <nismail@cisco.com>, <avt@ietf.org>
Content-Transfer-Encoding: quoted-printable
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable

Comments in-line.

> -----Original Message----- From: Nermeen Ismail =
[mailto:nismail@cisco.com]
> Sent: Fri, October 24, 2003 7:29 PM
> Would rewording the statement from:
> "
> The codec control mechanism SHOULD NOT duplicate the functionality
>        of existing protocols."
>=20
> to :
> "
> The codec control mechanism SHOULD NOT duplicate the functionality
>        of existing IETF protocols."
>=20
> calrify the text?.

Sounds good.

> 6.3 intent is to say that if thre is already an IETF protocol=20
> that can be=20
> used for the transport of these commands then we should do that
> rather than come up with a new different protocol. Putting it=20
> bluntly if=20
> RTCP is not going to be used as the transport mechanism then
> there should be good reasons for that.
>=20
>=20
> I think so far the options are:
> - Use RTCP with the AVP feedback extensions and create new=20
> payload-specific=20
> FB messages for things that are missing such as pictureFreeze etc.
> - Use a different protocol (TBD) to carry these=20
> contrl/feedback/notification messages and use SDP to initiate=20
> it. It would=20
> take such a sad sad
>    person to suggest H.245 to be that protocol :-).
>=20
> It is time for a draft that looks at which one is a better go=20
> and makes a=20
> concrete proposal.
>=20
> nermeen

I don't see it as an "either/or" choice.  Rather, both work.

RTCP makes sense for FastVideoUpdate.  The connection (RTCP) already =
exists in the right direction, it is media related, and the RTCP =
connection is often connected to the codec.

That said, another option, like a TCP control m=3D line, has LOTS of =
advantages.  It is reliable, works for implementations that don't =
connect RTCP to the encoder or decoder (depending on direction), and =
fits in to the "IETF Framework."  As an example, check out the use of =
the m=3D line in speechsc.

This mechanism makes sense for the forward-direction commands, like =
FreezeFrame.


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



From exim@www1.ietf.org  Mon Oct 27 03:42:36 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01370
	for <avt-archive@odin.ietf.org>; Mon, 27 Oct 2003 03:42:36 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AE2x4-0007A7-3J
	for avt-archive@odin.ietf.org; Mon, 27 Oct 2003 03:42:14 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9R8gDDS027527
	for avt-archive@odin.ietf.org; Mon, 27 Oct 2003 03:42:13 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AE2ws-00079A-8U; Mon, 27 Oct 2003 03:42:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AE2vy-00070Y-6d
	for avt@optimus.ietf.org; Mon, 27 Oct 2003 03:41:06 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01347
	for <avt@ietf.org>; Mon, 27 Oct 2003 03:40:55 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AE2vv-00015u-00
	for avt@ietf.org; Mon, 27 Oct 2003 03:41:03 -0500
Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AE2vu-00015r-00
	for avt@ietf.org; Mon, 27 Oct 2003 03:41:02 -0500
Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118])
	by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9R8f2Ss014667
	for <avt@ietf.org>; Mon, 27 Oct 2003 09:41:02 +0100 (MET)
Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55)
	id VWW651B7; Mon, 27 Oct 2003 09:41:02 +0100
Message-ID: <3F9CDA10.2030705@ericsson.com>
Date: Mon, 27 Oct 2003 09:40:48 +0100
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: IETF AVT WG <avt@ietf.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [AVT] [Fwd: [dccp] DCCP, TFRC, and VoIP issue summary]
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hi AVT members,

If you where not a member of either DCCP or MMUSIC you might have missed 
the big discussion after the Vienna IETF. However here is what 
conclusions Eddie makes from the discussion. As many of the topics 
should concern you on this list I forward it. Please review it as it 
will probably have impact on how well things will work in the future.

If you have comments please discuss this on one list AVT or DCCP. Cross 
posting multiple lists are not a good idea at all.

Cheers

Magnus

-------- Original Message --------
Subject: [dccp] DCCP, TFRC, and VoIP issue summary
Date: Fri, 24 Oct 2003 23:13:22 -0700
From: Eddie Kohler <kohler@icir.org>
To: dccp@ietf.org
CC: mmusic@ietf.org

Hi all,

Several months ago, we had a pretty lively discussion on these lists about
why TFRC and/or DCCP might be inappropriate for VoIP and other apps. I
wanted to summarize again the problems that people have brought up, and
where we stand on solutions. Comments welcome.

A. Complexity

    The existing DCCP specification is simply too complex for resource-
    constrained implementations, which might be common for voice.

    * This complexity seems important and not onerous for host stacks. We
    hope that CCID 3-Thin shows it's possible to simplify DCCP's
    requirements for resource-constrained implementations without radical
    surgery on the base protocol.

B. Slow-start

    TCP-friendly congestion control algorithms must slow-start up to their
    sustained rate. Voice apps might like to start with their full bandwidth
    right away. Plus, the initial TFRC rate seems very slow (1 packet per
    RTT).

    * We have updated the CCID 3 draft to allow initial TFRC rates of up to
    4 packets per RTT (or 4380 payload bytes per RTT), in line with recent
    TCP practice (RFC 3390). For a This supports a 40ms _initial_
    packetization interval for any RTT up to 160ms: not bad at all.  And we
    might consider allowing a larger initial window when packet payloads are
    small; this would require a bit of research on whether many small
    packets is actually equivalent to few large packets in terms of
    congestion.

C. Rate slows down during idle periods

    The TFRC allowed sending rate will drop down to something very small
    (2-4 packets/RTT) when the sender is idle. This may cause problems
    particualrly with VoIP conversations, which are naturally idle-one-way
    then idle-the-other-way. The rampup from the small rate to the fair rate
    may take several to many RTTs, ouch.

    * The solution for slow start applies here. Beyond that, we recommend
    sending probe packets if any slowdown during an idle period is
    unacceptable; you don't get to reserve bandwidth in the best-effort
    internet. These probe packets could easily consist of required
    acknowledgements.

D. Rate will not increase during app-limited period

    If the application is sending at rate R, the allowed rate will not
    increase much beyond R (say, more than 2R) until the app "probes" by
    transmitting at a faster rate. The reason: DCCP determines the allowable
    maximum rate by monitoring packet drops. Thus, DCCP "can not tell the
    application when to increase its rate unless the application 'probes'
    the network first by ... increasing its rate."  (Phillipe Gentric)

    * A related issue, and again, we can't do much better in the current
    internet than having the application send probe packets: you don't get
    to reserve bandwidth you aren't using. Nevertheless, there shouldn't be
    much problem with the sender abruptly doubling its sending rate in this
    situation, assuming TFRC's observed loss event rate is low enough to
    allow it.

E. Congestion control means variable rate

    Must an application with discrete sending rates send at a rate strictly
    bounded by TFRC's allowed rate? Could we allow some flexibility, so that
    it could send at, say, any rate <= 1.8*TFRC_allowed_rate?

    * There probably wouldn't be any problem with this, but it should be
    explored in a separate document. Does anyone want to write up a draft
    about CCID 3 adapted for a sender with discrete sending rates?

F. Rate changes/oscillations

    There are application costs, possibly significant ones, associated with
    changing rates. Current codecs switch rates poorly; actual devices tend
    to swap in a new codec. Also, for audio at least, people find the
    glitches caused by frequent rate changes distracting. Thus, if the
    application has to change its rate frequently, because of CC, that's a
    problem.

    * A solution to issue D would apply here. Furthermore, we should not
    solve this problem generically; different applications will want
    different behavior. For example, Tom Phelan described a procedure where
    bandwidth is probed at the beginning of the connection, then a codec
    starts at a lower rate than the probe rate; if congestion causes the
    rate to drop below this, the connection terminates.

G. Multiple streams

    An application that had both audio and video to send might use 2 DCCP
    connections. Could the application choose how its bandwidth is allocated
    among those connections?  (Phillipe Gentric)

    * We haven't made progress on this. It's at least somewhat problematic
    since the end nodes can't necessarily assume that the two connections
    take the same path, with the same quality of service on all parts of the
    path.

Here are some non-issues: things people have brought up that I think the
DCCP spec already handles well.

H. Low delay

    It's very important to minimize packetization overhead and effects of
    the send buffer.

    * An API issue, and DCCP was designed with this in mind.

I. Control over the send buffer

    What happens when packets need to be dropped (because TFRC demands a
    lower rate than the application wants)? Some would like packets to be
    dropped by the TFRC stack, either by dropping the first packet, or the
    last packet, or the lowest-priority packet; others would like the
    application to be in direct control.

    * This is an API issue, and DCCP seems flexible enough to handle any of
    those APIs, or others.

J. Pushing against the maximum rate (streaming media)

    TFRC always pushes against its maximum rate until a loss, which will
    force a decrease in the allowable rate. This induces periodic
    distortion. Can we minimize this by providing TFRC with a maximum rate,
    beyond which it will not push? (Damon Lanphear)

    * Absolutely---TFRC will not send more data than the application
    provides.

Eddie

_______________________________________________
dccp IETF mailing list: dccp@ietf.org
list info:  https://www1.ietf.org/mailman/listinfo/dccp
wg charter: http://www.ietf.org/html.charters/dccp-charter.html


-- 

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 exim@www1.ietf.org  Mon Oct 27 03:45:23 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01438
	for <avt-archive@odin.ietf.org>; Mon, 27 Oct 2003 03:45:23 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AE2zn-0007Y5-U3
	for avt-archive@odin.ietf.org; Mon, 27 Oct 2003 03:45:03 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9R8j3hu028917
	for avt-archive@odin.ietf.org; Mon, 27 Oct 2003 03:45:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AE2zm-0007W7-8k; Mon, 27 Oct 2003 03:45:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AE2yz-0007Ri-TZ
	for avt@optimus.ietf.org; Mon, 27 Oct 2003 03:44:13 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01403
	for <avt@ietf.org>; Mon, 27 Oct 2003 03:44:02 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AE2yx-000178-00
	for avt@ietf.org; Mon, 27 Oct 2003 03:44:11 -0500
Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AE2yw-000175-00
	for avt@ietf.org; Mon, 27 Oct 2003 03:44:10 -0500
Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121])
	by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9R8i7I2028809
	for <avt@ietf.org>; Mon, 27 Oct 2003 09:44:11 +0100 (MET)
Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55)
	id VWWHB1QG; Mon, 27 Oct 2003 09:44:08 +0100
Message-ID: <3F9CDAC9.3030600@ericsson.com>
Date: Mon, 27 Oct 2003 09:43:53 +0100
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: IETF AVT WG <avt@ietf.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [AVT] Submission deadlines
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hi,

According to my clock it is 5 hours until the 9 AM ET draft submission 
deadline has passed. There are 15 hours until the AVT WG agenda request 
must been have sent to us chairs. So if you haven't already submitted 
things, please do this.

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 exim@www1.ietf.org  Mon Oct 27 03:53:24 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01636
	for <avt-archive@odin.ietf.org>; Mon, 27 Oct 2003 03:53:24 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AE37Y-0008F5-R5
	for avt-archive@odin.ietf.org; Mon, 27 Oct 2003 03:53:05 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9R8r4Km031639
	for avt-archive@odin.ietf.org; Mon, 27 Oct 2003 03:53:04 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AE37W-0008Dl-CB; Mon, 27 Oct 2003 03:53:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AE37O-0008CT-Mx
	for avt@optimus.ietf.org; Mon, 27 Oct 2003 03:52:54 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01621
	for <avt@ietf.org>; Mon, 27 Oct 2003 03:52:43 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AE37L-0001DN-00
	for avt@ietf.org; Mon, 27 Oct 2003 03:52:51 -0500
Received: from ns4.sony.co.jp ([137.153.0.44])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AE37L-0001DK-00
	for avt@ietf.org; Mon, 27 Oct 2003 03:52:51 -0500
Received: from mail7.sony.co.jp (mail7.sony.co.jp [43.0.1.209])
Received: from mail7.sony.co.jp (localhost [127.0.0.1])
	by mail7.sony.co.jp (R8/Sony) with ESMTP id h9R8qo922745
	for <avt@ietf.org>; Mon, 27 Oct 2003 17:52:50 +0900 (JST)
Received: from localhost.localdomain ([43.13.117.111])
	by mail7.sony.co.jp (R8/Sony) with ESMTP id h9R8qow22733
	for <avt@ietf.org>; Mon, 27 Oct 2003 17:52:50 +0900 (JST)
Received: from avfpi.av.crl.sony.co.jp (avfpi.av.crl.sony.co.jp [43.13.117.96] (may be forged))
	by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h9R8qnGn013283
	for <avt@ietf.org>; Mon, 27 Oct 2003 17:52:49 +0900
Message-Id: <5.1.1.8.2.20031027140655.053f5d68@localhost>
X-Sender: hatanaka/43.13.117.111@localhost
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1-J
Date: Mon, 27 Oct 2003 17:52:47 +0900
To: avt@ietf.org
From: Mitsuyuki Hatanaka <hatanaka@av.crl.sony.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [AVT] draft-hatanaka-avt-rtp-atracx-03.txt
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hi all,
 
We have submitted our revised internet draft as "draft-hatanaka-avt-rtp-atracx-03.txt".
You will be able to get it from the on-line Internet-Drafts directories.

We added some descriptions regarding on MIME parameters and consideration on 
error robustness in section 9. and 10.

Best Regards,
Mitsuyuki Hatanaka


---------------------------------------
 Mitsuyuki Hatanaka
 IMNC Audio Codec Dev Dept.1
 Sony Corporation
 E-mail: hatanaka@av.crl.sony.co.jp
---------------------------------------


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



From exim@www1.ietf.org  Mon Oct 27 04:37:22 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03533
	for <avt-archive@odin.ietf.org>; Mon, 27 Oct 2003 04:37:22 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AE3o7-0003xd-ON
	for avt-archive@odin.ietf.org; Mon, 27 Oct 2003 04:37:03 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9R9b3Lo015171
	for avt-archive@odin.ietf.org; Mon, 27 Oct 2003 04:37:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AE3o5-0003vt-MX; Mon, 27 Oct 2003 04:37:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AE3nH-0003sf-JX
	for avt@optimus.ietf.org; Mon, 27 Oct 2003 04:36:11 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03516
	for <avt@ietf.org>; Mon, 27 Oct 2003 04:35:59 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AE3nE-0001ua-00
	for avt@ietf.org; Mon, 27 Oct 2003 04:36:08 -0500
Received: from dundee.dcs.gla.ac.uk ([130.209.242.163])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AE3nE-0001uH-00
	for avt@ietf.org; Mon, 27 Oct 2003 04:36:08 -0500
Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:61720 helo=csperkins.org)
	by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.04)
	id 1AE3ml-000151-00; Mon, 27 Oct 2003 09:35:39 +0000
Date: Mon, 27 Oct 2003 09:34:37 +0000
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>
To: avt@ietf.org
From: Colin Perkins <csp@csperkins.org>
Content-Transfer-Encoding: 7bit
Message-Id: <C8360BB8-0860-11D8-8B4D-000A957FC5F2@csperkins.org>
X-Mailer: Apple Mail (2.552)
Content-Transfer-Encoding: 7bit
Subject: [AVT] Email addresses for your chairs
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Folks,

Over the past few months, Magnus has replaced Steve as AVT co-chair, 
and I have changed affiliation. Please note that our contact details 
are as follows:

	Colin Perkins
	University of Glasgow
	Email: csp@csperkins.org

	Magnus Westerlund
	Ericsson Research
	Email: magnus.westerlund@ericsson.com

Colin


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



From exim@www1.ietf.org  Mon Oct 27 05:53:24 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05974
	for <avt-archive@odin.ietf.org>; Mon, 27 Oct 2003 05:53:24 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AE4zi-0002xN-SF
	for avt-archive@odin.ietf.org; Mon, 27 Oct 2003 05:53:06 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RAr6pD011346
	for avt-archive@odin.ietf.org; Mon, 27 Oct 2003 05:53:06 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AE4zd-0002tm-CV; Mon, 27 Oct 2003 05:53:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AE4yx-0002qW-N0
	for avt@optimus.ietf.org; Mon, 27 Oct 2003 05:52:19 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05899;
	Mon, 27 Oct 2003 05:52:06 -0500 (EST)
From: Rod.Walsh@nokia.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AE4yt-0002jS-00; Mon, 27 Oct 2003 05:52:15 -0500
Received: from mgw-x1.nokia.com ([131.228.20.21])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AE4yt-0002jO-00; Mon, 27 Oct 2003 05:52:15 -0500
Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])
	by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9RAqFI18901;
	Mon, 27 Oct 2003 12:52:15 +0200 (EET)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T658a028314ac158f257ce@esvir05nok.ntc.nokia.com>;
 Mon, 27 Oct 2003 12:51:57 +0200
Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747);
	 Mon, 27 Oct 2003 12:51:57 +0200
Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe013.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747);
	 Mon, 27 Oct 2003 12:51:56 +0200
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
Date: Mon, 27 Oct 2003 12:51:53 +0200
Message-ID: <F0D879F44A9F8D498E1C07736E7BED6001C30843@trebe003.europe.nokia.com>
Thread-Topic: [AVT] AVT Charter update
Thread-Index: AcNxVxTqZ8KLcjOBQ5KJUz7nS+NoXwAudvqA
To: <magnus.westerlund@ericsson.com>, <finlayson@live.com>
Cc: <avt@ietf.org>, <rmt@ietf.org>, <mmusic@ietf.org>
X-OriginalArrivalTime: 27 Oct 2003 10:51:56.0933 (UTC) FILETIME=[5730CB50:01C39C78]
Content-Transfer-Encoding: quoted-printable
Subject: [AVT] time-lined static media with FLUTE & IMG
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable

Hi Magnus, Ross (and everyone)

1=BD-2 years back there was a draft on time-lined static media =
(draft-westerlund-avt-rtp-static-media-01) - basically to send files, =
text (etc) with timed presentation along with AV media streams. Since =
the basic requirements haven't gone away, but RMT has made progress on =
usable protocols, what do you think about using FLUTE =
(draft-ietf-rmt-flute-02) for the same job? With a quick comparison I =
think it should be pretty straight forward, although you may have some =
preferences (or extensions to the FLUTE-FDT) if you already have a =
working RTP-payload'ed implementation.

Ross mentioned sending ID-3 tags in-band with audio streams. Any ideas =
you have on doing this with FLUTE (ID3) and RTP (music) could be pretty =
useful for the Internet Media Guide (IMG) work in MMUSIC - how to move =
around (and announce) metadata for 'foo' multicast and unicast sessions.

Cheers, Rod.

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



From exim@www1.ietf.org  Mon Oct 27 15:28:36 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07403
	for <avt-archive@odin.ietf.org>; Mon, 27 Oct 2003 15:28:36 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEDyL-0005fq-6z
	for avt-archive@odin.ietf.org; Mon, 27 Oct 2003 15:28:17 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RKSHEK021758
	for avt-archive@odin.ietf.org; Mon, 27 Oct 2003 15:28:17 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEDy6-0005W2-Iw; Mon, 27 Oct 2003 15:28:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEDxc-0005T5-Nu
	for avt@optimus.ietf.org; Mon, 27 Oct 2003 15:27:32 -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07182;
	Mon, 27 Oct 2003 15:27:21 -0500 (EST)
Message-Id: <200310272027.PAA07182@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: avt@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Mon, 27 Oct 2003 15:27:20 -0500
Subject: [AVT] I-D ACTION:draft-ietf-avt-uncomp-video-04.txt
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Audio/Video Transport Working Group of the IETF.

	Title		: RTP Payload Format for Uncompressed Video
	Author(s)	: L. Gharai, C. Perkins
	Filename	: draft-ietf-avt-uncomp-video-04.txt
	Pages		: 18
	Date		: 2003-10-27
	
This memo specifies a packetization scheme for encapsulating
uncompressed video into a payload format for the Real-time
Transport Protocol, RTP. It supports a range of standard- and
high-definition video formats, including common television
formats such as ITU BT.601, and standards from the Society of
Motion Picture and Television Engineers (SMPTE), such as SMPTE
274M and SMPTE 296M. The format is designed to be applicable
and extensible to new video formats as they are developed.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-uncomp-video-04.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-avt-uncomp-video-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-avt-uncomp-video-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-10-27153635.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-avt-uncomp-video-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-avt-uncomp-video-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-10-27153635.I-D@ietf.org>

--OtherAccess--

--NextPart--



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



From exim@www1.ietf.org  Mon Oct 27 15:28:36 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07402
	for <avt-archive@odin.ietf.org>; Mon, 27 Oct 2003 15:28:36 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEDyL-0005fD-4s
	for avt-archive@odin.ietf.org; Mon, 27 Oct 2003 15:28:17 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RKSHM3021761
	for avt-archive@odin.ietf.org; Mon, 27 Oct 2003 15:28:17 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEDy5-0005Ve-D6; Mon, 27 Oct 2003 15:28:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEDxU-0005R4-2d
	for avt@optimus.ietf.org; Mon, 27 Oct 2003 15:27:24 -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07147;
	Mon, 27 Oct 2003 15:27:12 -0500 (EST)
Message-Id: <200310272027.PAA07147@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: avt@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Mon, 27 Oct 2003 15:27:12 -0500
Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-h264-03.txt
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Audio/Video Transport Working Group of the IETF.

	Title		: RTP payload Format for JVT Video
	Author(s)	: S. Wenger
	Filename	: draft-ietf-avt-rtp-h264-03.txt
	Pages		: 70
	Date		: 2003-10-27
	
This memo describes an RTP Payload format for the ITU-T 
Recommendation H.264 video codec.  This codec was designed as a 
joint project of the Video Coding Experts Group (VCEG) of ITU-T and
the Moving Picture Experts Group (MPEG) of ISO/IEC.  Recommendation 
H.264 was approved by ITU-T on May 2003, and the approved draft 
specification is available for public review.  ISO/IEC 
International Standard 14496-10 will be technically identical to 
ITU-T Recommendation H.264.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-h264-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-avt-rtp-h264-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-h264-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:	<2003-10-27153619.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-avt-rtp-h264-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-avt-rtp-h264-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-10-27153619.I-D@ietf.org>

--OtherAccess--

--NextPart--



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



From exim@www1.ietf.org  Mon Oct 27 23:19:33 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07056
	for <avt-archive@odin.ietf.org>; Mon, 27 Oct 2003 23:19:33 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AELK6-0004HD-An
	for avt-archive@odin.ietf.org; Mon, 27 Oct 2003 23:19:14 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9S4JElE016434
	for avt-archive@odin.ietf.org; Mon, 27 Oct 2003 23:19:14 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AELJt-0004FP-MD; Mon, 27 Oct 2003 23:19:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AELJ6-0004Dj-AD
	for avt@optimus.ietf.org; Mon, 27 Oct 2003 23:18:12 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07023;
	Mon, 27 Oct 2003 23:18:00 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AELJ4-0005Oz-00; Mon, 27 Oct 2003 23:18:10 -0500
Received: from ns2.packetvideo.com ([63.214.191.68])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AELJ3-0005Ot-00; Mon, 27 Oct 2003 23:18:09 -0500
Received: from misty.packetvideo.com (pv-fw [63.214.191.66])
	by ns2.packetvideo.com (8.12.10/8.12.10) with ESMTP id h9S4HYio019695;
	Mon, 27 Oct 2003 20:17:34 -0800 (PST)
Received: by misty.packetvideo.com with Internet Mail Service (5.5.2657.72)
	id <VP5Z1HRL>; Mon, 27 Oct 2003 20:17:34 -0800
Message-ID: <72263E8E8622D611975C0002B32C19D805A17BF6@misty.packetvideo.com>
From: Thomas Zeng <zeng@PacketVideo.COM>
To: "'Matthew Heaney'" <mheaney@on2.com>,
        Magnus Westerlund
	 <magnus.westerlund@ericsson.com>,
        Tom Marshall <tmarshall@real.com>,
        Greg Sherwood <sherwood@PacketVideo.COM>, mmusic@ietf.org
Cc: "'avt@ietf.org'" <avt@ietf.org>
Date: Mon, 27 Oct 2003 20:17:32 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C39D0A.68A03730"
Subject: [AVT] FW: draft-zeng-mmusic-rtsp-end-of-stream-01.txt
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C39D0A.68A03730
Content-Type: text/plain;
	charset="iso-8859-1"

Dear AVT and MMUSIC members:

Last night, I submitted revision 01 of the strawman End-Of-Stream proposal,
which is the action assigned to me during IETF-57.
See forwarded email.

In this revision, I added "Appendix A" to describe a new RTCP packet for
singalling EOS: the RTCP EOS packet.
My intention is to  present both RTSP EOS and RTCP EOS, and open to the
group to debate whether one or both of them (or none
of them) should be standardized.

Note that in my view defining a special RTP packet is inferior to new RTCP
EOS packet, because RTCP is more suitable for control purposes.
Therefor I didn't present an RTP based EOS solution. The final decision is
up to the group.

As always, your comments are highly appreciated.

Given the differing opinions on EOS signalling, I'd like to request a 15
minutes time slot during MMUSIC session on Nov.14 to
present these alternatives to the group. I will send a separate email to
MMUSIC chairs shortly.

Another note:
   In Appendix A, the sequence number of the ending RTP packet is given for
each SSRC/CSRC in the new RTCP EOS packet. 
It appears to be enough and I don't see a need to also put RTP time of the
ending RTP timestamp in the RTCP EOS packet.

AVT mailing list is CC'ed since if we opt for a new RTCP EOS packet, AVT
would be the WG to get approval.

Thanks,
- thomas


>  -----Original Message-----
> From: 	Thomas Zeng  
> Sent:	Sunday, October 26, 2003 10:34 PM
> To:	'internet-drafts@ietf.org'
> Subject:	draft-zeng-mmusic-rtsp-end-of-stream-01.txt
> 
>  <<draft-zeng-mmusic-rtsp-end-of-stream-01.txt>> 

------_=_NextPart_000_01C39D0A.68A03730
Content-Type: text/plain;
	name="draft-zeng-mmusic-rtsp-end-of-stream-01.txt"
Content-Disposition: attachment;
	filename="draft-zeng-mmusic-rtsp-end-of-stream-01.txt"
Content-Transfer-Encoding: quoted-printable

=0A=
MMUSIC                                                     Thomas M. =
Zeng=0A=
                                                         P. Greg =
Sherwood=0A=
Internet-Draft                                                =
PacketVideo=0A=
Expires: April 29, 2004                                     Oct  26, =
2003=0A=
=0A=
=0A=
              Signalling End Of Stream in Real Time Streaming=0A=
                draft-zeng-mmusic-end-of-stream-01.txt=0A=
=0A=
Status of this Memo=0A=
=0A=
   This document is an Internet-Draft and is in full conformance =
with=0A=
   all provisions of Section 10 of RFC2026.=0A=
=0A=
   Internet-Drafts are working documents of the Internet Engineering=0A=
   Task Force (IETF), its areas, and its working groups. Note that =
other=0A=
   groups may also distribute working documents as Internet-Drafts.=0A=
=0A=
   Internet-Drafts are draft documents valid for a maximum of six =
months=0A=
   and may be updated, replaced, or obsoleted by other documents at =
any=0A=
   time. It is inappropriate to use Internet-Drafts as reference=0A=
   material or to cite them other than as "work in progress."=0A=
=0A=
   The list of current Internet-Drafts can be accessed at http://=0A=
   www.ietf.org/ietf/1id-abstracts.txt.=0A=
=0A=
   The list of Internet-Draft Shadow Directories can be accessed at=0A=
   http://www.ietf.org/shadow.html.=0A=
=0A=
   This Internet-Draft will expire on Apr. 29, 2004.=0A=
=0A=
Copyright Notice=0A=
=0A=
   Copyright (C) The Internet Society (2003). All Rights Reserved.=0A=
=0A=
Abstract=0A=
=0A=
   This document describes a new RTSP method called END_OF_STREAM, =
which =0A=
   extends the core RTSP protocol to enable one RTSP protocol entity to =
=0A=
   signal other entity(s) =0A=
   that it has no more media data to send. This request could be issued =
=0A=
   either with a =0A=
   non-aggregate or aggregate control URI, the latter implies that all =
=0A=
   media streams =0A=
   in the aggregate session have run out of media data.=0A=
=0A=
   The receiver of this RTSP request is expected to reply with 200 OK =
=0A=
   response.=0A=
=0A=
   Since END_OF_STREAM represents an extension to the core RTSP =
protocol, =0A=
   a feature tag,=0A=
   "method.eos", is defined to facilitate capability negotiation using =
=0A=
   RTSP extension =0A=
   mechanism [RTSP_NEW].=0A=
=0A=
=0A=
1. Motivation=0A=
=0A=
   In the core RTSP protocol [RTSP_NEW], an RTSP client relies on =
the=0A=
   media transport mechanism  to signal end of stream.=0A=
=0A=
   When the media transport mechanism happens to be RTP over UDP, this =
=0A=
   is carried out by RTCP BYE packet [RTP_NEW]. In practice, there are =
=0A=
   some drawbacks with this approach:=0A=
     =0A=
     1. When the server sends an RTCP BYE packet with its SSRC, the =0A=
        server is giving up=0A=
        the SSRC (see section 8.2 in [RTP_NEW]). The server would be =
=0A=
        required to =0A=
        switch to a new SSRC on a subsequent PLAY of the same media =0A=
        stream.=0A=
        Since server's SSRC is only communicated in the Transport =
header =0A=
        of SETUP =0A=
        response, the server would not have an opportunity to send a =
new=0A=
        value to =0A=
        the player, and the client would have to discover the SSRC from =
=0A=
        the incoming RTP packets. =0A=
=0A=
     2. RTCP BYE packet method does not offer a simple, gurranteed =0A=
        method of delievering=0A=
        an end-of-stream announcement.=0A=
=0A=
     3. RTCP BYE packet method does not offer the option to have a =
single=0A=
        aggregate=0A=
        end-of-stream announcemnt for all media streams in the RTSP =0A=
        session.=0A=
=0A=
     4. Section 6.3.7 of RFC3550 stipulates that an RTP sender cannot =
=0A=
        send RTCP BYE =0A=
        before leaving the RTP session if it has not already sent at =
=0A=
        least one RTP or RTCP packet. This is a problem under =0A=
        error conditions. Consider the case =0A=
        where an RTP session has just started (i.e., RTSP PLAY has =0A=
        been =0A=
        successfully acknowledged with an RTSP 200 OK response), and =
the =0A=
        sender attempts to =0A=
        retrieve media frames from its media source. The media source =
=0A=
        fails to provide any media frame due to its internal error such =
=0A=
        as file corruption. The sender should inform its receiver(s) =
=0A=
        but it cannot send BYE packets.=0A=
=0A=
   The motivation to solve the above issues is particularly high for =
=0A=
   unicast streaming applications that use RTSP over TCP in the control =
=0A=
   plane, and RTP over UDP in the media transport. =0A=
=0A=
   There is also the desire to have an EOS (End Of Stream) =0A=
   signalling mechanism =0A=
   for non-RTP delivery. One such delivery is MPEG2 transport streams =
=0A=
   used in the cable TV environment. In non-IP delivery environments, =
=0A=
   the transport typically remains allocated even if no media is being =
=0A=
   delivered.  This=0A=
   means that a client cannot watch for the server to close the=0A=
   transport to signal the end of stream. Meanwhile,  watching for the =
=0A=
   incoming media to stop is unreliable.  Short=0A=
   timeouts can trigger a false end of media detection if the=0A=
   media flow is temporarily delayed.  Long timeouts introduce=0A=
   unacceptable latencies.  Clients are unable to distinguish=0A=
   between a normal end of stream and an error condition that=0A=
   resulted in the media delivery stopping.=0A=
=0A=
   We note that using TEARDOWN from server to client is not =0A=
   appropriate because:=0A=
     1. TEARDOWN is currently not allowed from server to =0A=
        client [RTSP_NEW];=0A=
     2. Even if TEARDOWN is made available in server to client =0A=
        direction, =0A=
        the definition of TEARDOWN requires that, if the request =0A=
        URI is =0A=
        aggregate, that the session must be de-allocated by the =0A=
        server. =0A=
        There are RTSP applications that use SET_PARAMETER from =0A=
        client to=0A=
        server as the means to report session QoS statistics, but if=0A=
        server uses TEARDOWN on aggregate URL to signal end of stream, =
=0A=
        the client can no longer use SET_PARAMETER with a =0A=
        session header. =0A=
     3. In general, RTSP, being a client-server protocol,=0A=
        should let client, not server to control session state. But =0A=
        TEARDOWN=0A=
        on aggregate URL will change session from PLAYING state =0A=
        to INIT state.=0A=
=0A=
   We note that using PAUSE from server to client is not appropriate =
=0A=
   either, because PAUSE will change the state of the RTSP session.=0A=
=0A=
   We note also that using ANNOUNCE from server to client is not =0A=
   suitable, for two reasons:=0A=
      1. ANNOUNCE from server to client is used in RFC2326 to update =
=0A=
         session description. =0A=
         Extending it to indicate end-of-stream event is awkward.=0A=
      2. ANNOUNCE is not in the core RTSP protocol [RTSP_NEW].=0A=
=0A=
   There has been proposals to extend RTP or RTCP protocol to =
introduce=0A=
   in-band signalling of end-of-stream events. Appendex A explains=0A=
   one such proposal. We note that in practice both approaches =0A=
   (using an RTSP method or a special RTP/RTCP packet to signal=0A=
    end-of-stream) have shown up in propriatery implemtations. =0A=
   Therefore it is our view that allowing both approaches =0A=
   is a reasonable compromise until a concensus is reached.   =0A=
=0A=
   The next section describes our solution.=0A=
=0A=
3. Solution Using END_OF_STREAM method=0A=
=0A=
   We introduce a new RTSP method to signal end of stream in =
applications=0A=
   where an persistent RTSP connection is maintained between server =0A=
   and client.=0A=
   The new method is an RTSP "extension-method" [RTSP_NEW]. It is =
called=0A=
   END_OF_STREAM, and is a request from media sender=0A=
   to receiver. In the case of RTSP client playing media streams sent =
by =0A=
   RTSP server,=0A=
   the END_OF_STREAM is sent from server to client. In the use case =
where =0A=
   RTSP server is=0A=
   recording media sent by RTSP client, the END_OF_STREAM requet could =
=0A=
   be sent from an=0A=
   RTSP client to server.  =0A=
=0A=
   As any other RTSP request method, END_OF_STREAM must be acknowledged =
=0A=
   with a response.=0A=
   =0A=
   3.1 The Definition of END_OF_STREAM=0A=
      =0A=
   The END_OF_STREAM request for a URI signals the fact that no more =
=0A=
   RTP packets will be=0A=
   sent. Here is an example:=0A=
=0A=
     S->C: END_OF_STREAM rtsp://foo.com/bar.avi RTSP/1.0=0A=
           CSeq: 10=0A=
           Session: 12345678=0A=
	   Range: npt=3D0-200=0A=
           RTP-Info: =
url=3D//foo.com/bar.avi/streamid=3D0;seq=3D45102,=0A=
             url=3Drtsp://foo.com/bar.avi/streamid=3D1;seq=3D30211    =
=0A=
	   Reason: End of range reached=0A=
=0A=
     C->S: RTSP/1.0 200 OK  =0A=
           CSeq: 10=0A=
           Session: 12345678=0A=
    =0A=
   An END_OF_STREAM request MUST include "CSeq", "Range" and "Session" =
=0A=
   headers.=0A=
   It SHOULD include "RTP-Info" header.=0A=
   The RTP-Info in server's END_OF_STREAM request=0A=
   is used to indicate the sequence number of =0A=
   the ending RTP packet for each media stream.=0A=
   =0A=
   An END_OF_STREAM requet MAY include a new "Reason" header, =0A=
   defined as a =0A=
   string, whose purpose is to allow the server to explain why stream =
=0A=
   has ended, and whose ABNF definition is given below:=0A=
    =0A=
          Reason     =3D  "Reason" ":"   Reason-Phrase CRLF=0A=
=0A=
   where:=0A=
       -- "Reason-Phrase" is a parameter defined in section 7.1.1 of =
=0A=
          [RTSP_NEW].=0A=
=0A=
   =0A=
   Note that the server is free to use any text as "Reason-Phrase". In =
=0A=
   certain applications, the client=0A=
   may  display the text, in its entirety, to end user to improve =
user=0A=
   friendliness.=0A=
      =0A=
   END_OF_STREAM does not remove session ID, nor does it change the =0A=
   state of the RTSP session.=0A=
=0A=
   END_OF_STREAM may be applied to either aggregate or non-aggregate =
URI.=0A=
   =0A=
   END_OF_STREAM does not apply if the RTSP session is not in =
PLAYING=0A=
   state. If a client receives END_OF_STREAM while it is not in PLAYING =
=0A=
   state, it must reply with a 455 response: Method Not Valid in This =
=0A=
   State.=0A=
=0A=
   We note that client can piggy back QoS statistics as a entity body =
in=0A=
   its 200 OK response to the END_OF_STREAM request from the server.   =
=0A=
=0A=
   3.2 Limitations=0A=
   =0A=
   END_OF_STREAM method is applicable only if the server has the =
means=0A=
   to contact the client when it reaches the end of a media stream.=0A=
   This may not be possible if the RTSP connection between server =
and=0A=
   client is not persistent. When it is time to send END_OF_STREAM =
but=0A=
   the server does not have connection to the client, the server =
will=0A=
   simply skip END_OF_STREAM. That is to say, the server will not =0A=
   queue up the END_OF_STREAM message.=0A=
   =0A=
=0A=
4. Feature tag=0A=
  =0A=
   The END_OF_STREAM feature is represented by a feature tag (see =0A=
   [RTSP_NEW]=0A=
   for how to use feature tags in capability negotiations).=0A=
=0A=
   The feature tag is:=0A=
=0A=
          method.eos=0A=
=0A=
   which means that the END_OF_STREAM method is fully supported. By =0A=
   fully we mean either at non-aggregate or aggregate level.=0A=
=0A=
5. Use Case=0A=
=0A=
   In this example, the server sends END_OF_STREAM request to client =
for=0A=
   one live media stream, because upstream source terminates the =
stream=0A=
   after 200 seconds. The fact that the stream has played for 200 =
seconds=0A=
   is communicated by the Range header in the END_OF_STREAM request.=0A=
=0A=
     C->S: PLAY rtsp://foo.com/bar.avi/streamid=3D0 RTSP/1.0=0A=
	   Supported: method.eos=0A=
           CSeq: 10=0A=
           Session: 12345678=0A=
	   Range: 0-200=0A=
=0A=
     S->C: RTSP/1.0 200 OK=0A=
	   Supported: method.eos=0A=
           CSeq: 10=0A=
           Session: 12345678=0A=
           RTP-Info: url=3D//foo.com/bar.avi/streamid=3D0;seq=3D0; =
rtptime=3D0 =0A=
=0A=
     S->C: END_OF_STREAM rtsp://foo.com/bar.avi/streamid=3D0 =
RTSP/1.0=0A=
           CSeq: 123=0A=
           Session: 12345678=0A=
	   Range: npt=3D0-200; bytes=3D0-200000=0A=
           RTP-Info: url=3D//foo.com/bar.avi/streamid=3D0;seq=3D45102 =
=0A=
	   Reason: End of range reached=0A=
=0A=
     C->S: RTSP/1.0 200 OK  =0A=
           CSeq: 123=0A=
           Session: 12345678=0A=
  =0A=
   In the END_OF_STREAM request, the client will learn that the server =
has =0A=
   completed the stream as requested (as indicated by the "End of range =
=0A=
   reached" Reason).=0A=
=0A=
   From the two RTP-Info headers, one in PLAY response, one in =0A=
   END_OF_STREAM requst, the client can derive the total number=0A=
   of RTP packets that the server has sent. From the npt field in the =
=0A=
   Range header, the client knows the presentation time that this =
stream =0A=
   has covered, from the server's point of view, while the byte-range =
field =0A=
   can optional inform the =0A=
   client how much media data, in bytes, that the server has sent. =0A=
 =0A=
5. Security Considerations=0A=
 =0A=
   Because there is only one new TEXT header, "Reason", added by our =
=0A=
   new RTSP method,=0A=
   the security considerations outlined in [RTSP_NEW] apply here as =
well.=0A=
     =0A=
6. IANA Considerations=0A=
=0A=
   A new method name, and its associated feature tag need to be =
registered =0A=
   with IANA.=0A=
    =0A=
     -- Method name: END_OF_STREAM=0A=
     =0A=
     -- feature tag: method.eos=0A=
=0A=
=0A=
=0C=0A=
=0A=
Appendix A: Signalling End-Of-Streaming With RTCP EOD Packet=0A=
=0A=
In this appendix, a new RTCP packet type is defined to signal=0A=
end-of-stream event. =0A=
=0A=
A new RTCP packet type is prefered over profile specific extensions=0A=
(see section 6.4.1 of  [RTP-NEW])=0A=
because this feature is profile independent.=0A=
=0A=
1. EOS: End-Of-Stream RTCP Packet=0A=
=0A=
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 =
1=0A=
      =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=
      |V=3D2|P|    SC   |   PT=3DEOS=3D205  |             length        =
    |=0A=
      =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=
      |                           SSRC/CSRC                           =
|=0A=
      =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=
      |        extended RTP sequence number                           | =
=0A=
      =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=
      :                              ...                              =
:=0A=
      =
+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D=
+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=0A=
(opt) |     length    |               reason for EOS                =
...=0A=
      =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=
=0A=
  The EOS packet indicates that one or more sources have exhausted =
its=0A=
  media data and will not send any new RTP packet, yet the source is =
=0A=
  not about to leave the session.=0A=
=0A=
  packet type (PT):  8 bits=0A=
     Contains the constant 205 to idnentify this as an RTCP EOS =
packet.=0A=
 =0A=
  source count (SC): 5 bits=0A=
     The number of SSRC/CSRC identifiers included in this EOS =
packet.=0A=
     A count value of zero is valid, but useless. For each one of =0A=
     them, an extended RTP sequence number is included. See below.=0A=
=0A=
  extended RTP sequence number: 32 bit=0A=
    The extended sequence number of the ending RTP packet from the =0A=
    source.=0A=
    The low 16 bits contain the sequence number of the ending RTP=0A=
    data packet from source SSRC_n, and the most significant 16=0A=
    bits extend that sequence number with the corresponding count of=0A=
    sequence number cycles. The RTP receiver needs to track the=0A=
    extended sequence number to properly generate RTCP=0A=
    RR packets, hence it can easily determine which RTP packet is =
the=0A=
    ending RTP packet.=0A=
=0A=
2. Rules of sending RTCP EOS packet=0A=
=0A=
  RTCP EOS packet should be sent if the source runs out of media =
data,=0A=
  but is NOT about to leave the session. It may, for instance, wait=0A=
  for the receiver to send anther RTSP PLAY request (if RTSP is the=0A=
  session contorl protocol in use) and then re-use the SSRC to send=0A=
  RTP packets.=0A=
=0A=
  If an EOS packet is received by a mixer, the mixer SHOULD forward=0A=
  the EOS packet with its SSRC/CSRC identifier(s) unchanged.=0A=
=0A=
  Optionally,  the EOS packet MAY include an 8-bit octet count =0A=
  followed by that many=0A=
  octets of text indicating the reason for ending, e.g., "End of file" =
=0A=
  or "Upstream EOS received".  The string has the same=0A=
  encoding as that described for SDES.  If the string fills the =
packet=0A=
  to the next 32-bit boundary, the string is not null terminated.  =
If=0A=
  not, the EOS packet MUST be padded with null octets to the next =
32-=0A=
  bit boundary.  This padding is separate from that indicated by the =
P=0A=
  bit in the RTCP header.=0A=
  =0A=
  When RTP is carried over un-reliable transport (e.g., UDP), an RTP =
=0A=
  source may repeatedly send RTCP EOS packets until it is assured =
that=0A=
  the receiver(s) have got the event notification -- e.g., it has=0A=
  received another RTSP PLAY request from the RTP receiver.  =0A=
=0A=
^L=0A=
Normative References=0A=
=0A=
   [RTSP_NEW] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., =
=0A=
         "Real Time Streaming Protocol", =0A=
         draft-ietf-mmusic-rfc2326bis-04.txt=0A=
=0A=
   [RTP_NEW] RFC3550 "Real-time Transport Protocol", July 2003=0A=
=0A=
=0A=
Full Copyright Statement=0A=
=0A=
   Copyright (C) The Internet Society (2003). All Rights Reserved.=0A=
=0A=
   This document and translations of it may be copied and furnished =
to=0A=
   others, and derivative works that comment on or otherwise explain =
it=0A=
   or assist in its implementation may be prepared, copied, =
published=0A=
   and distributed, in whole or in part, without restriction of any=0A=
   kind, provided that the above copyright notice and this paragraph =
are=0A=
   included on all such copies and derivative works. However, this=0A=
   document itself may not be modified in any way, such as by =
removing=0A=
   the copyright notice or references to the Internet Society or =
other=0A=
   Internet organizations, except as needed for the purpose of=0A=
   developing Internet standards in which case the procedures for=0A=
   copyrights defined in the Internet Standards process must be=0A=
   followed, or as required to translate it into languages other =
than=0A=
   English.=0A=
=0A=
   The limited permissions granted above are perpetual and will not =
be=0A=
   revoked by the Internet Society or its successors or assignees.=0A=
=0A=
   This document and the information contained herein is provided on =
an=0A=
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET =
ENGINEERING=0A=
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, =
INCLUDING=0A=
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF=0A=
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=0A=
=0A=
=0A=
Acknowledgement=0A=
=0A=
   Thanks to Sean Sheedy for suggesting the inclusion of "Range" =
header=0A=
   and for contributing some text in the motivations section.=0A=
=0A=
   Funding for the RFC Editor function is currently provided by the=0A=
   Internet Society.=0A=
=0A=
Author Addresses=0A=
=0A=
   Thomas Zeng=0A=
   PacketVideo Corp.=0A=
   10350 Science Center Dr., Suite 210=0A=
   San Diego, CA 92127=0A=
   email: zeng@pv.com=0A=
=0A=
   P. Greg Sherwood=0A=
   PacketVideo Corp.=0A=
   10350 Science Center Dr., Suite 210=0A=
   San Diego, CA 92127=0A=
   email: sherwood@pv.com
------_=_NextPart_000_01C39D0A.68A03730--

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



From exim@www1.ietf.org  Tue Oct 28 04:14:41 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11045
	for <avt-archive@odin.ietf.org>; Tue, 28 Oct 2003 04:14:41 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEPvi-0001Qe-J4
	for avt-archive@odin.ietf.org; Tue, 28 Oct 2003 04:14:22 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9S9EMNb005487
	for avt-archive@odin.ietf.org; Tue, 28 Oct 2003 04:14:22 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEPvQ-0001Js-L4; Tue, 28 Oct 2003 04:14:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEPv6-0001IF-DO
	for avt@optimus.ietf.org; Tue, 28 Oct 2003 04:13:44 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11002;
	Tue, 28 Oct 2003 04:13:32 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AEPv3-0005zz-00; Tue, 28 Oct 2003 04:13:41 -0500
Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AEPv2-0005zl-00; Tue, 28 Oct 2003 04:13:40 -0500
Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120])
	by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9S9D3I2026095;
	Tue, 28 Oct 2003 10:13:03 +0100 (MET)
Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55)
	id VXCB1VR4; Tue, 28 Oct 2003 10:13:07 +0100
Message-ID: <3F9E330E.60006@ericsson.com>
Date: Tue, 28 Oct 2003 10:12:46 +0100
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
Reply-To: IETF MMUSIC WG <mmusic@ietf.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: mmusic@ietf.org
CC: "'avt@ietf.org'" <avt@ietf.org>
References: <72263E8E8622D611975C0002B32C19D805A17BF6@misty.packetvideo.com>
In-Reply-To: <72263E8E8622D611975C0002B32C19D805A17BF6@misty.packetvideo.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [AVT] Re: FW: draft-zeng-mmusic-rtsp-end-of-stream-01.txt
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hi,

If you have comments on this, lets discuss this on the MMUSIC list. So 
no future cross postings.

Cheers

Magnus

Thomas Zeng wrote:

> Dear AVT and MMUSIC members:
> 
> Last night, I submitted revision 01 of the strawman End-Of-Stream proposal,
> which is the action assigned to me during IETF-57.
> See forwarded email.
> 
> In this revision, I added "Appendix A" to describe a new RTCP packet for
> singalling EOS: the RTCP EOS packet.
> My intention is to  present both RTSP EOS and RTCP EOS, and open to the
> group to debate whether one or both of them (or none
> of them) should be standardized.
> 
> Note that in my view defining a special RTP packet is inferior to new RTCP
> EOS packet, because RTCP is more suitable for control purposes.
> Therefor I didn't present an RTP based EOS solution. The final decision is
> up to the group.
> 
> As always, your comments are highly appreciated.
> 
> Given the differing opinions on EOS signalling, I'd like to request a 15
> minutes time slot during MMUSIC session on Nov.14 to
> present these alternatives to the group. I will send a separate email to
> MMUSIC chairs shortly.
> 
> Another note:
>    In Appendix A, the sequence number of the ending RTP packet is given for
> each SSRC/CSRC in the new RTCP EOS packet. 
> It appears to be enough and I don't see a need to also put RTP time of the
> ending RTP timestamp in the RTCP EOS packet.
> 
> AVT mailing list is CC'ed since if we opt for a new RTCP EOS packet, AVT
> would be the WG to get approval.
> 
> Thanks,
> - thomas
> 
> 
> 
>> -----Original Message-----
>>From: 	Thomas Zeng  
>>Sent:	Sunday, October 26, 2003 10:34 PM
>>To:	'internet-drafts@ietf.org'
>>Subject:	draft-zeng-mmusic-rtsp-end-of-stream-01.txt
>>
>> <<draft-zeng-mmusic-rtsp-end-of-stream-01.txt>> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> 
> MMUSIC                                                     Thomas M. Zeng
>                                                          P. Greg Sherwood
> Internet-Draft                                                PacketVideo
> Expires: April 29, 2004                                     Oct  26, 2003
> 
> 
>               Signalling End Of Stream in Real Time Streaming
>                 draft-zeng-mmusic-end-of-stream-01.txt
> 
> Status of this Memo
> 
>    This document is an Internet-Draft and is in full conformance with
>    all provisions of Section 10 of RFC2026.
> 
>    Internet-Drafts are working documents of the Internet Engineering
>    Task Force (IETF), its areas, and its working groups. Note that other
>    groups may also distribute working documents as Internet-Drafts.
> 
>    Internet-Drafts are draft documents valid for a maximum of six months
>    and may be updated, replaced, or obsoleted by other documents at any
>    time. It is inappropriate to use Internet-Drafts as reference
>    material or to cite them other than as "work in progress."
> 
>    The list of current Internet-Drafts can be accessed at http://
>    www.ietf.org/ietf/1id-abstracts.txt.
> 
>    The list of Internet-Draft Shadow Directories can be accessed at
>    http://www.ietf.org/shadow.html.
> 
>    This Internet-Draft will expire on Apr. 29, 2004.
> 
> Copyright Notice
> 
>    Copyright (C) The Internet Society (2003). All Rights Reserved.
> 
> Abstract
> 
>    This document describes a new RTSP method called END_OF_STREAM, which 
>    extends the core RTSP protocol to enable one RTSP protocol entity to 
>    signal other entity(s) 
>    that it has no more media data to send. This request could be issued 
>    either with a 
>    non-aggregate or aggregate control URI, the latter implies that all 
>    media streams 
>    in the aggregate session have run out of media data.
> 
>    The receiver of this RTSP request is expected to reply with 200 OK 
>    response.
> 
>    Since END_OF_STREAM represents an extension to the core RTSP protocol, 
>    a feature tag,
>    "method.eos", is defined to facilitate capability negotiation using 
>    RTSP extension 
>    mechanism [RTSP_NEW].
> 
> 
> 1. Motivation
> 
>    In the core RTSP protocol [RTSP_NEW], an RTSP client relies on the
>    media transport mechanism  to signal end of stream.
> 
>    When the media transport mechanism happens to be RTP over UDP, this 
>    is carried out by RTCP BYE packet [RTP_NEW]. In practice, there are 
>    some drawbacks with this approach:
>      
>      1. When the server sends an RTCP BYE packet with its SSRC, the 
>         server is giving up
>         the SSRC (see section 8.2 in [RTP_NEW]). The server would be 
>         required to 
>         switch to a new SSRC on a subsequent PLAY of the same media 
>         stream.
>         Since server's SSRC is only communicated in the Transport header 
>         of SETUP 
>         response, the server would not have an opportunity to send a new
>         value to 
>         the player, and the client would have to discover the SSRC from 
>         the incoming RTP packets. 
> 
>      2. RTCP BYE packet method does not offer a simple, gurranteed 
>         method of delievering
>         an end-of-stream announcement.
> 
>      3. RTCP BYE packet method does not offer the option to have a single
>         aggregate
>         end-of-stream announcemnt for all media streams in the RTSP 
>         session.
> 
>      4. Section 6.3.7 of RFC3550 stipulates that an RTP sender cannot 
>         send RTCP BYE 
>         before leaving the RTP session if it has not already sent at 
>         least one RTP or RTCP packet. This is a problem under 
>         error conditions. Consider the case 
>         where an RTP session has just started (i.e., RTSP PLAY has 
>         been 
>         successfully acknowledged with an RTSP 200 OK response), and the 
>         sender attempts to 
>         retrieve media frames from its media source. The media source 
>         fails to provide any media frame due to its internal error such 
>         as file corruption. The sender should inform its receiver(s) 
>         but it cannot send BYE packets.
> 
>    The motivation to solve the above issues is particularly high for 
>    unicast streaming applications that use RTSP over TCP in the control 
>    plane, and RTP over UDP in the media transport. 
> 
>    There is also the desire to have an EOS (End Of Stream) 
>    signalling mechanism 
>    for non-RTP delivery. One such delivery is MPEG2 transport streams 
>    used in the cable TV environment. In non-IP delivery environments, 
>    the transport typically remains allocated even if no media is being 
>    delivered.  This
>    means that a client cannot watch for the server to close the
>    transport to signal the end of stream. Meanwhile,  watching for the 
>    incoming media to stop is unreliable.  Short
>    timeouts can trigger a false end of media detection if the
>    media flow is temporarily delayed.  Long timeouts introduce
>    unacceptable latencies.  Clients are unable to distinguish
>    between a normal end of stream and an error condition that
>    resulted in the media delivery stopping.
> 
>    We note that using TEARDOWN from server to client is not 
>    appropriate because:
>      1. TEARDOWN is currently not allowed from server to 
>         client [RTSP_NEW];
>      2. Even if TEARDOWN is made available in server to client 
>         direction, 
>         the definition of TEARDOWN requires that, if the request 
>         URI is 
>         aggregate, that the session must be de-allocated by the 
>         server. 
>         There are RTSP applications that use SET_PARAMETER from 
>         client to
>         server as the means to report session QoS statistics, but if
>         server uses TEARDOWN on aggregate URL to signal end of stream, 
>         the client can no longer use SET_PARAMETER with a 
>         session header. 
>      3. In general, RTSP, being a client-server protocol,
>         should let client, not server to control session state. But 
>         TEARDOWN
>         on aggregate URL will change session from PLAYING state 
>         to INIT state.
> 
>    We note that using PAUSE from server to client is not appropriate 
>    either, because PAUSE will change the state of the RTSP session.
> 
>    We note also that using ANNOUNCE from server to client is not 
>    suitable, for two reasons:
>       1. ANNOUNCE from server to client is used in RFC2326 to update 
>          session description. 
>          Extending it to indicate end-of-stream event is awkward.
>       2. ANNOUNCE is not in the core RTSP protocol [RTSP_NEW].
> 
>    There has been proposals to extend RTP or RTCP protocol to introduce
>    in-band signalling of end-of-stream events. Appendex A explains
>    one such proposal. We note that in practice both approaches 
>    (using an RTSP method or a special RTP/RTCP packet to signal
>     end-of-stream) have shown up in propriatery implemtations. 
>    Therefore it is our view that allowing both approaches 
>    is a reasonable compromise until a concensus is reached.   
> 
>    The next section describes our solution.
> 
> 3. Solution Using END_OF_STREAM method
> 
>    We introduce a new RTSP method to signal end of stream in applications
>    where an persistent RTSP connection is maintained between server 
>    and client.
>    The new method is an RTSP "extension-method" [RTSP_NEW]. It is called
>    END_OF_STREAM, and is a request from media sender
>    to receiver. In the case of RTSP client playing media streams sent by 
>    RTSP server,
>    the END_OF_STREAM is sent from server to client. In the use case where 
>    RTSP server is
>    recording media sent by RTSP client, the END_OF_STREAM requet could 
>    be sent from an
>    RTSP client to server.  
> 
>    As any other RTSP request method, END_OF_STREAM must be acknowledged 
>    with a response.
>    
>    3.1 The Definition of END_OF_STREAM
>       
>    The END_OF_STREAM request for a URI signals the fact that no more 
>    RTP packets will be
>    sent. Here is an example:
> 
>      S->C: END_OF_STREAM rtsp://foo.com/bar.avi RTSP/1.0
>            CSeq: 10
>            Session: 12345678
> 	   Range: npt=0-200
>            RTP-Info: url=//foo.com/bar.avi/streamid=0;seq=45102,
>              url=rtsp://foo.com/bar.avi/streamid=1;seq=30211    
> 	   Reason: End of range reached
> 
>      C->S: RTSP/1.0 200 OK  
>            CSeq: 10
>            Session: 12345678
>     
>    An END_OF_STREAM request MUST include "CSeq", "Range" and "Session" 
>    headers.
>    It SHOULD include "RTP-Info" header.
>    The RTP-Info in server's END_OF_STREAM request
>    is used to indicate the sequence number of 
>    the ending RTP packet for each media stream.
>    
>    An END_OF_STREAM requet MAY include a new "Reason" header, 
>    defined as a 
>    string, whose purpose is to allow the server to explain why stream 
>    has ended, and whose ABNF definition is given below:
>     
>           Reason     =  "Reason" ":"   Reason-Phrase CRLF
> 
>    where:
>        -- "Reason-Phrase" is a parameter defined in section 7.1.1 of 
>           [RTSP_NEW].
> 
>    
>    Note that the server is free to use any text as "Reason-Phrase". In 
>    certain applications, the client
>    may  display the text, in its entirety, to end user to improve user
>    friendliness.
>       
>    END_OF_STREAM does not remove session ID, nor does it change the 
>    state of the RTSP session.
> 
>    END_OF_STREAM may be applied to either aggregate or non-aggregate URI.
>    
>    END_OF_STREAM does not apply if the RTSP session is not in PLAYING
>    state. If a client receives END_OF_STREAM while it is not in PLAYING 
>    state, it must reply with a 455 response: Method Not Valid in This 
>    State.
> 
>    We note that client can piggy back QoS statistics as a entity body in
>    its 200 OK response to the END_OF_STREAM request from the server.   
> 
>    3.2 Limitations
>    
>    END_OF_STREAM method is applicable only if the server has the means
>    to contact the client when it reaches the end of a media stream.
>    This may not be possible if the RTSP connection between server and
>    client is not persistent. When it is time to send END_OF_STREAM but
>    the server does not have connection to the client, the server will
>    simply skip END_OF_STREAM. That is to say, the server will not 
>    queue up the END_OF_STREAM message.
>    
> 
> 4. Feature tag
>   
>    The END_OF_STREAM feature is represented by a feature tag (see 
>    [RTSP_NEW]
>    for how to use feature tags in capability negotiations).
> 
>    The feature tag is:
> 
>           method.eos
> 
>    which means that the END_OF_STREAM method is fully supported. By 
>    fully we mean either at non-aggregate or aggregate level.
> 
> 5. Use Case
> 
>    In this example, the server sends END_OF_STREAM request to client for
>    one live media stream, because upstream source terminates the stream
>    after 200 seconds. The fact that the stream has played for 200 seconds
>    is communicated by the Range header in the END_OF_STREAM request.
> 
>      C->S: PLAY rtsp://foo.com/bar.avi/streamid=0 RTSP/1.0
> 	   Supported: method.eos
>            CSeq: 10
>            Session: 12345678
> 	   Range: 0-200
> 
>      S->C: RTSP/1.0 200 OK
> 	   Supported: method.eos
>            CSeq: 10
>            Session: 12345678
>            RTP-Info: url=//foo.com/bar.avi/streamid=0;seq=0; rtptime=0 
> 
>      S->C: END_OF_STREAM rtsp://foo.com/bar.avi/streamid=0 RTSP/1.0
>            CSeq: 123
>            Session: 12345678
> 	   Range: npt=0-200; bytes=0-200000
>            RTP-Info: url=//foo.com/bar.avi/streamid=0;seq=45102 
> 	   Reason: End of range reached
> 
>      C->S: RTSP/1.0 200 OK  
>            CSeq: 123
>            Session: 12345678
>   
>    In the END_OF_STREAM request, the client will learn that the server has 
>    completed the stream as requested (as indicated by the "End of range 
>    reached" Reason).
> 
>    From the two RTP-Info headers, one in PLAY response, one in 
>    END_OF_STREAM requst, the client can derive the total number
>    of RTP packets that the server has sent. From the npt field in the 
>    Range header, the client knows the presentation time that this stream 
>    has covered, from the server's point of view, while the byte-range field 
>    can optional inform the 
>    client how much media data, in bytes, that the server has sent. 
>  
> 5. Security Considerations
>  
>    Because there is only one new TEXT header, "Reason", added by our 
>    new RTSP method,
>    the security considerations outlined in [RTSP_NEW] apply here as well.
>      
> 6. IANA Considerations
> 
>    A new method name, and its associated feature tag need to be registered 
>    with IANA.
>     
>      -- Method name: END_OF_STREAM
>      
>      -- feature tag: method.eos
> 
> 
> 
> 
> Appendix A: Signalling End-Of-Streaming With RTCP EOD Packet
> 
> In this appendix, a new RTCP packet type is defined to signal
> end-of-stream event. 
> 
> A new RTCP packet type is prefered over profile specific extensions
> (see section 6.4.1 of  [RTP-NEW])
> because this feature is profile independent.
> 
> 1. EOS: End-Of-Stream RTCP Packet
> 
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |V=2|P|    SC   |   PT=EOS=205  |             length            |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                           SSRC/CSRC                           |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |        extended RTP sequence number                           | 
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       :                              ...                              :
>       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
> (opt) |     length    |               reason for EOS                ...
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>   The EOS packet indicates that one or more sources have exhausted its
>   media data and will not send any new RTP packet, yet the source is 
>   not about to leave the session.
> 
>   packet type (PT):  8 bits
>      Contains the constant 205 to idnentify this as an RTCP EOS packet.
>  
>   source count (SC): 5 bits
>      The number of SSRC/CSRC identifiers included in this EOS packet.
>      A count value of zero is valid, but useless. For each one of 
>      them, an extended RTP sequence number is included. See below.
> 
>   extended RTP sequence number: 32 bit
>     The extended sequence number of the ending RTP packet from the 
>     source.
>     The low 16 bits contain the sequence number of the ending RTP
>     data packet from source SSRC_n, and the most significant 16
>     bits extend that sequence number with the corresponding count of
>     sequence number cycles. The RTP receiver needs to track the
>     extended sequence number to properly generate RTCP
>     RR packets, hence it can easily determine which RTP packet is the
>     ending RTP packet.
> 
> 2. Rules of sending RTCP EOS packet
> 
>   RTCP EOS packet should be sent if the source runs out of media data,
>   but is NOT about to leave the session. It may, for instance, wait
>   for the receiver to send anther RTSP PLAY request (if RTSP is the
>   session contorl protocol in use) and then re-use the SSRC to send
>   RTP packets.
> 
>   If an EOS packet is received by a mixer, the mixer SHOULD forward
>   the EOS packet with its SSRC/CSRC identifier(s) unchanged.
> 
>   Optionally,  the EOS packet MAY include an 8-bit octet count 
>   followed by that many
>   octets of text indicating the reason for ending, e.g., "End of file" 
>   or "Upstream EOS received".  The string has the same
>   encoding as that described for SDES.  If the string fills the packet
>   to the next 32-bit boundary, the string is not null terminated.  If
>   not, the EOS packet MUST be padded with null octets to the next 32-
>   bit boundary.  This padding is separate from that indicated by the P
>   bit in the RTCP header.
>   
>   When RTP is carried over un-reliable transport (e.g., UDP), an RTP 
>   source may repeatedly send RTCP EOS packets until it is assured that
>   the receiver(s) have got the event notification -- e.g., it has
>   received another RTSP PLAY request from the RTP receiver.  
> 
> ^L
> Normative References
> 
>    [RTSP_NEW] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., 
>          "Real Time Streaming Protocol", 
>          draft-ietf-mmusic-rfc2326bis-04.txt
> 
>    [RTP_NEW] RFC3550 "Real-time Transport Protocol", July 2003
> 
> 
> Full Copyright Statement
> 
>    Copyright (C) The Internet Society (2003). All Rights Reserved.
> 
>    This document and translations of it may be copied and furnished to
>    others, and derivative works that comment on or otherwise explain it
>    or assist in its implementation may be prepared, copied, published
>    and distributed, in whole or in part, without restriction of any
>    kind, provided that the above copyright notice and this paragraph are
>    included on all such copies and derivative works. However, this
>    document itself may not be modified in any way, such as by removing
>    the copyright notice or references to the Internet Society or other
>    Internet organizations, except as needed for the purpose of
>    developing Internet standards in which case the procedures for
>    copyrights defined in the Internet Standards process must be
>    followed, or as required to translate it into languages other than
>    English.
> 
>    The limited permissions granted above are perpetual and will not be
>    revoked by the Internet Society or its successors or assignees.
> 
>    This document and the information contained herein is provided on an
>    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
>    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
>    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
> 
> 
> 
> 
> 
>    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
>    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
> 
> 
> Acknowledgement
> 
>    Thanks to Sean Sheedy for suggesting the inclusion of "Range" header
>    and for contributing some text in the motivations section.
> 
>    Funding for the RFC Editor function is currently provided by the
>    Internet Society.
> 
> Author Addresses
> 
>    Thomas Zeng
>    PacketVideo Corp.
>    10350 Science Center Dr., Suite 210
>    San Diego, CA 92127
>    email: zeng@pv.com
> 
>    P. Greg Sherwood
>    PacketVideo Corp.
>    10350 Science Center Dr., Suite 210
>    San Diego, CA 92127
>    email: sherwood@pv.com

-- 

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 exim@www1.ietf.org  Tue Oct 28 08:13:32 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19170
	for <avt-archive@odin.ietf.org>; Tue, 28 Oct 2003 08:13:32 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AETem-0000mV-8C
	for avt-archive@odin.ietf.org; Tue, 28 Oct 2003 08:13:12 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SDD8LW002959
	for avt-archive@odin.ietf.org; Tue, 28 Oct 2003 08:13:08 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AETef-0000kG-7i; Tue, 28 Oct 2003 08:13:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AETe9-0000dg-T6
	for avt@optimus.ietf.org; Tue, 28 Oct 2003 08:12:32 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19119
	for <avt@ietf.org>; Tue, 28 Oct 2003 08:12:19 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AETe8-0002TD-00
	for avt@ietf.org; Tue, 28 Oct 2003 08:12:28 -0500
Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AETe7-0002TA-00
	for avt@ietf.org; Tue, 28 Oct 2003 08:12:28 -0500
Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125])
	by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9SDCPI2023416;
	Tue, 28 Oct 2003 14:12:25 +0100 (MET)
Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55)
	id VXBRWDV8; Tue, 28 Oct 2003 14:12:25 +0100
Message-ID: <3F9E6B28.6090307@ericsson.com>
Date: Tue, 28 Oct 2003 14:12:08 +0100
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: IETF AVT WG <avt@ietf.org>, Qiaobing Xie <Qiaobing.Xie@Motorola.com>
CC: Colin Perkins <csp@csperkins.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [AVT] Comments on DSR drafts
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hi Qiaobing,

I have looked at your three dsr drafts:
  draft-ietf-avt-dsr-es202050-01.txt
  draft-xie-avt-xdsr-es202211-00.txt
  draft-xie-avt-xadsr-es202212-00.txt

1. My first comment is that these three draft could easily be folded 
into a single draft. To my understanding they have a lot in common. The 
only real difference is the actual internal frame format and that 050 
have shorter frames then 211 and 212. Then there is the need define 
individual MIME types for each. However this seems to be about all. 
Having a single draft will reduce the workload on IESG and RFC editor 
slightly. It will also make it less RFC to keep track of.

2. You should make a reference to maxptime rather then define it 
yourself. Either RFC 3267 or make it dependent on SDP-new.

3. I think the security consideration is a bit thin. Are you really 
certain that the format does not result in any special considerations?

4. You might want to clarify in mapping MIME to SDP that even if no rate 
is given the default value must be given here.

5. What use is the NULL frame? It is defined in all drafts but not 
declared how they should be used.


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 exim@www1.ietf.org  Tue Oct 28 14:12:30 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17471
	for <avt-archive@odin.ietf.org>; Tue, 28 Oct 2003 14:12:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEZGF-0003un-HV
	for avt-archive@odin.ietf.org; Tue, 28 Oct 2003 14:12:12 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SJCB9Y015045
	for avt-archive@odin.ietf.org; Tue, 28 Oct 2003 14:12:11 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEZG4-0003tG-R4; Tue, 28 Oct 2003 14:12:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEZFH-0003or-DF
	for avt@optimus.ietf.org; Tue, 28 Oct 2003 14:11:11 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17363
	for <avt@ietf.org>; Tue, 28 Oct 2003 14:10:59 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AEZFE-0004iI-00
	for avt@ietf.org; Tue, 28 Oct 2003 14:11:08 -0500
Received: from mail2.fw-bc.sony.com ([160.33.98.69])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AEZFD-0004hw-00
	for avt@ietf.org; Tue, 28 Oct 2003 14:11:08 -0500
Received: from mail3.sjc.in.sel.sony.com (mail3.sjc.in.sel.sony.com [43.134.1.211])
	by mail2.fw-bc.sony.com (8.8.8/8.8.8) with ESMTP id TAA25419;
	Tue, 28 Oct 2003 19:10:33 GMT
Received: by mail3.sjc.in.sel.sony.com id SAA07751; Tue, 28 Oct 2003 18:53:18 GMT
Received: by us-sj-xims-2.am.sony.com with Internet Mail Service (5.5.2657.72)
	id <VDKSX4HL>; Tue, 28 Oct 2003 10:53:18 -0800
Message-ID: <0DE752C748D0D211A6BE0090272B960B0784886D@us-sj-xmsg-2.am.sony.com>
From: "Edwards, Eric" <Eric.Edwards@am.sony.com>
To: "'csp@csperkins.org'" <csp@csperkins.org>,
        "'magnus.westerlund@ericsson.com'" <magnus.westerlund@ericsson.com>,
        "'avt@ietf.org'" <avt@ietf.org>
Date: Tue, 28 Oct 2003 10:53:16 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C39D84.BF702EB0"
Subject: [AVT] draft-ietf-avt-rtp-jpeg2000-04.txt
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C39D84.BF702EB0
Content-Type: text/plain;
	charset="iso-8859-1"

Dear AVT Chairs and All,

We have uploaded the latest draft of our jp2/rtp proposal.

Additions - 

Please see Sections 4.1 and 4.2.  We have added an indication for interlace
support.  Please review timestamp field in 4.1, and the tp field in 4.2.

Also, we have updated the document per comments forwarded in July by the
chairs.

We would like to move this document to Last Call.  Please forward any
comments that still may need to be addressed.  If the AVT group is
comfortable with this latest draft we would like to go to Last Call.

Best regards,

Eric

 <<draft-ietf-avt-rtp-jpeg2000-04.zip>> 



------_=_NextPart_000_01C39D84.BF702EB0
Content-Type: application/octet-stream;
	name="draft-ietf-avt-rtp-jpeg2000-04.zip"
Content-Disposition: attachment;
	filename="draft-ietf-avt-rtp-jpeg2000-04.zip"
Content-Transfer-Encoding: base64

UEsDBBQAAAAIALu9Wi+bZPrBkTsAADbJAAAiAAAAZHJhZnQtaWV0Zi1hdnQtcnRwLWpwZWcyMDAw
LTA0LnR4dN19a3PbSJLgZ3Wc/0OFI3ZbiiFpUZJf2vPFsiW6zR7rMRI93b0djguQBEWMQYADgJbU
5/vvl896AKAku9V3e8uJ3bZIICsrKyvflTU6HQ8vTofj7vHF4O3YfM1nWCRTM5xdR8WsfPLdrIjm
VTeJq3k3+lx1i2rV/ccqvtrb3d3t7h70qpuqHcplVOXlIjFv11W8XEZPvmt/7N7PaT5Z3xKkcb5M
qm8HNEzKaLIucjOqok/r4tsBXebZrTnKi1VeRFWSZ98M6Gxa5ZO4MHsvOwbouf/1gIY3q6SIy0Mz
WBVJavZeEKCDJ9/h/8JHL8bn5jy6TfNoZt7mxTKqzDwvzE/nwx/xnV3z92QW5+ayKuJoWeL7l1VU
rUuTz021SEpzEi9zBTvGL2b5dL2Ms8rAv6PMjLIqLrK46h4jx8A3M/whyUy5nvwjnlamyk2Upgxg
VeSfkxKIR/Av4Wf4t+nv4l8Xb4/2dvde9HSwEDCMVcTmOi8+JdmVxUHQjO3DZphdJVkcF/CU4ByV
n3Dm09hsj4bjtzsdkzC0qOwwuvCnAr4q8vWq7AH7VTEAjioGksMYhfxoltEtzKjMzSwpqyKZAKe3
IBaVrdO4c3q06TwYn6M0mdF6RTDqTbJcL3HCZXLDMJZ5Vi1KmgQiNYnNejWLqnjWMUW8SqMp/gve
zidlnsbwvZnc8lz4fQ9bXLlbUyXLuAc7hZcwWsF6AYdFSIvcrMu4jjWDiUoYbh4XcQZEBg4D6gN9
cGB4a5oQJeOlEBGImuEbT5FkMIhljCvg6LL31PFabFIgME54ui4K5Lg6zaYACiYdTafwKsxOl2tR
VavDZ8+ur697KMF6eXH1DP/xrJ/MutEEVi2awlKAEGsbrT7K5SKa5dfmGLYc7Nwiib9u4JJe7y2q
ZUqLP5Dx2zfVLC6nwFMwRmRWsm/nbt/Cm1kJEqhCZsNNzDBoJ3+mnVzyTobVwkdw+29fxFHaxaU1
Y33dnBd5lU/zdKd3NxhkSxwfJ4k4TYHlkmydg4QoY6IFUMxKEwZTVkmammQZXcWwlWh+talc4wMg
FYCsgTT6XjiqnEZpNEnSpLol7i5AG5RVBsRGlprEvBuS3wErlDSEq93xwLZpMiUZzdvtyXfjaJLG
iOkRoE8Mr9Tv9wx9YNGLfLZmgdR78AdopnD6BAcG+AwDkIj7UDJ+JEePdYU3wBE1sCf41AX02xik
MuyQe3Az5oDh7Asclf3HcZlcPXxmFs5BDY7okPsh8MeDw/RBhpwnN0CYRRzNQB6sS2CTe+F5cPYs
HMVJIM0fgJoxzxnOc5kXw5l+iqvk9+jhi2/MS4XD8zrNs24CvJWmyRWu8jKf3T8rhPNK4fC8RnUY
D8XnNcN5IfO6pB0ETH8cp8nnuOB9dF4kIMBgU82TOJ21gAZdjDtDzMCOAY0apQLy4Z/fznFN+x+f
fPffnnw3apikD7Itm1aSTpAJbqeyhP2Ooq6i6TanVJ9g38IhSMfxPFqnFWigGryvgINLB5u96M7i
OVgfMwfsXqQ8OMwAl3EGzPx9aQYsix7KAP09hbNPcC7iaYwL7yDdD6TnwXnZEETLCGSZ7LVpvlzF
Wbl5x5j+vsLpe/NCRY86834Cy8eDsxfM6yshmb4IkFcyr7MV4h6lVoq845k9FM5r3WgxWCe41CD5
SxDVxcOkiOmLIOrvMqDR4HTwlTDwY/ovLBwi9MnoZAhEukLb9GsEmgeHCH15jIKxiJZgNxb3qR33
MX0RjH3RrCzQwHJaI63BnowLINZFcrWoDLoacbtSdHD2FA7Ld1h7cHuA+WbJjekiO+TLJfIWSjcw
q5JpoCRNXwRsXzTihVqq5QN3Fn8cHNGIg3W1yIvyezOYzdByvVc188f0RVD3RQO9XYMpdJSvbov7
SBLC2dtl0wbI7Nsu7VZluYqnyRyttdAQK2vOINl+YoKJAZh/JqM9NndZkWBjjs/FlGRIifoG4CFe
nj0bDY/Ero5k28FEsxkoGbB4P8cpsAU7Oll8U3VB+8W+k+0ZlAaWLp/BpgfqjQD/SVQmU/ulqeLp
IsvT/OoWXRg1pmcMBsTXb/2Pv734aJ0wYPDK7KsT6bAvHXIo0MELzmkr2ScYCIJ4l1/DBIqOwtI3
8iy9JajzJI3VNgFf0WR5hd/z22TPL5MSfWLfzrcmLcAJHFyY9lv0AxZKYPRj8wydWpxxFqNMjEDd
g53MqPDiodnV4v4zjMDk71nb2KPHeoXrjb4veIkrmHIxX6dmrkYpesrkKuDk5GGP6oiB+nAE1NIX
1+Plx99efTz0Qxe5eQebQdQMbi6kTjyfJ9MEVvqWfUgCdJ1UC5OiX/A5KUHCPPluy5g0h79j4nnw
MW7RuQWuKmBbBQCJw9hD2MrNwKAqSfERYBsiBU8rn89RAE5yHAkgsyUFk4xRydsBCQkPvMK9INcl
XGjaU1meAKw4+5wUeUZeOKytvHQu7jAKu+BN8N9XYD2n6HquQdzdmu3L0wux9shf2iGMyGmKwetf
I9/2FO4FfJ8v/SmyC0vPO4Xac1KEd0WXuCBKr9CqWSyR0ybg/M2BuPHNKo3I6JnANr7umbcJ7E0x
aspFfo1e4yTNp5/MLImuQKEEHqPbuqBoFvlMHLZHMkH3/hQT9Ks/f+ni5y/f+PYXc3E2Ml/+n4wN
n28dGD5/b32VMWK07vxzE9pfjo86tNV6QBukz88RqBDgE/nTf1SEZHQt6sO8efM/zBfaUygPu1/g
7/qff1tHmbqD8MUGJGCTiYH+pfXP4NF2In4NJf7QQthPKwx/oG/Fw59wjQB30cPJgf/+5s0XcxxV
kTyDfw9I2oBrPqU/j3LVARX+ruviSTOEfVbMKPxrBxb5wn9OEvarU/jqjxOjXSKwBDw0P9SlXmhk
kOTDUKxCGUbTBWCb5qz48gwnisoeLQgQuZZNKawECv6a+Z7fnjrqoCZB0d0KpVxPumW0XKUK5XME
imwt5kSK1hhGD9ekOkFRAfVZi4KKAIs3+T3PKvpiXoAqWYCihn/F/1zDdMDAZCjb14uE5gKPJlmJ
oT6afLmIihXYJfBtWu6gjYLfUhjwoSDmKZsaUdnbMcbfqjg5UMpCILUdyfbwSEMmA9gkMRIbaTGB
iQm9hJ7+89aQnSVoJVEEHUH+0x+4rOIVmA+/x0Qk/Bl0LwYVaNHW2RRj8mIvDuZgyAWvd4iDWUcG
AVcisKBrLUawL6ZJNnUTweFwbXHRz+2PCCYyaP+BMRmvIvEF0XISuuArhG99dFqoJdAbdpX/rjAw
yVGhCWxXGHWI/sfqVjdasAw+td1AOC6DiOwWJ57iPUFUxp0KpkUW95RojaXM5wIEeMOfxQLWEcyR
ODMMjdg8QmsETHSEy+KiA99xPIPBYEJrhs+DUZvRTCp9dUUhQmETiYEsIsuV8r66qECsLI4JElrh
ahXSBBgSw/VwxkkyFMoyIbH5SV4TpA6AS6NbsEUD88ya0ojOPF8XwMW3FCYXw5FzcojFLKYAPiNj
zXNczkMkuLMXO8ifaEx2wNYvE/7Kl0rIaoydyB7Oh+QoejnmjX4CIIJ4aKwep1/G1mnwZoHZJvWY
cswrwPJFlF1M/LA8/OakJ+00WJrEuRlrjDARPcgV5G1Y2UymesPoQq0LSkaJJLKMhO+IWNY5AUkz
mpGISXAxb5D1PGcQvRg3m2DFI+8pp6eAmBnmDNcpOr2UBrFMVKA3WQotdc9ZI5m+7RjwDNdluxwS
McM5vHxdYTyJt/QUnOwGMZhD2U3GWTJFlBq4ldErmMGC4ZqnIHZjTvYZpzm8OTJx5rkmGIW+SiAM
ud6bIfG5+1N8i7nVWWmenny4HD/t8H/N6Rn9+2L4tw+ji+Ex/vvy3eD9e/uPR3Mh9v8UF0Lwv3x3
9uH9sfuXm9fR2cnJ8PSYp3Yy+PUp56qfnp2PR2eng/dPLdeHy0kCnFJkmI0ogAsrTt3ZWAi+g7n2
vkaiftvjxdnz4zdh1qkZEfjGLCGDkRiLnyWk1QZsPyNDgRxw6NogQzPRKFt0jVwEagHLCUCB35L8
8UIoXkIQxexd0Q+SomRm0LZkvxRUVGnjEyN/46PvjcJriYUNgATwBMp/1mXk5U/TqMQIFb2DlgtD
wS2PighUa4skjDgqiHG9SMI2XVahcwzIcnZ+FmMQFNY8vRVqWMluumqIwFbNYW1IVdGgVpJYpUBl
CzFoll5zlUmnpPFNglkMfIPDDlVMiNMyF3nas5jz++U64byHZKxRYeuzYnFksOgksvRrkDCISBZX
WBcg8seLfLQgh6tPBSUg4LCGI7/OfF8gLgoYHgiSpIlUJhSfQLQKbFIdyCneK2A94aIxJfZ7teSp
J+F12EaOniJGGBLJEaPQ3m8EVzvhpqy8HQDbZspqt8aMGEuaaPAw+hRnakl4iQPLq10MJGnBDS6G
GB8Yr/Jdl7Mwxtgxz//FfxT5DaPseSZsxRbeFHjPmoL4wRqUMkdjbhnTGySK9nb/BW2HZU4qBIhX
wm6s2uniaFPyvDBuKXZQxzijfBVkbEVJ4kLWwSDq6FkkBRtjIA+sLSIigwQLLCgwLI3qQLjtsY75
ZU434UBdMTXRtiVGAwiZN3wtrjdiFP0UGmAGxK1o5T1G7zhTAD8ctQBWx8gqyDq249BhGUynoBgx
ZnmLhmx5C9p/SRU3mpvzwNBOJFertDVTNWSUTD3HPQNLaJx2OV1gCDVkcbeMc/BzOLYPhmPPZ69W
MGXOkNDI0zniBFcu9KmCDT9qzJI2o+Amsjw4V9OK8q3eS+qiFZIpdEC4JmYDymKPAQqULtcgN+UZ
HAh+yJWuiHGLcMXpiVDWkOxX8ygQavgB1GcJW0A4F3yOy1VYHi1Xa6rvIRRwtXgmtsAFP+AZVTga
K48DJ6u4QIO/7G8ot3jECOvBn2IeYYqD9J3b/ywJG/NJSpGOzjWv2RmroEqkYziuUHuvzUrvqVLm
YbXKBCsnJONBfmYEFkJE7qJk2aakXOpoBFYGFftZ2R8pLs7KOCFdRSbC9snOISGxdN/JDm5Qg2xj
4OAytiwLuPQ1iQS2SOWRFMFEghgZFmxjUp3edVLGmFRSMKJ4DGarf17EocwKXX4g53KdVskqJQwV
Qsl5kZIXcsL5qjKuVPURcg4x0nts7XD4oAbHy+Hx+la34N5sn4+FWiv/a7SQbzOwBiWUVaI+J1Tt
/GANH+Iv9Uia+aC92IzRUcA8AgsHw11gxgHVpou8jCl7I+PMUe7BaPiviQ2GwOQAryilzW9Tq3Hv
qtcBSl6ed8zl6Bz367S3Y60RVLZVtFwdWk6t9CupxF1nCWu517vm07vfexw3ANJaHrEv0DKDvRxH
hdIdV+GKfAtilysQqRmvjLKCran20r8k0hP14eNCilGRsPlsJvVHYqTq66DPQIivcvbfYxqHnqN9
VgnSDlt1G0CnV0mUKpjPUbqOlYUCWhSc/qKYxCdwLjM0GSl9hX4rmOcVsF+pcDDnmE2LWyoUIfvF
zBI0QYC5O4xewoOU+Rrri4HKcToHVgHrB9S1whEgHRP5ESCuI56z71/k66sFEJc2FUh20tZRRaAk
I4aFbxuL3nyXmfd3W2VcS67fM5O0YLkuisyuaX76Ld/ttXy3b2H04fd9c2CemxfmpXllXn/Ndwzl
L90/+D8G8+WXL8MvJ+/eflku/mcy+zLm3IQt2QpyFRQ0z9ZLVFL6+fK42KCLghGvGfy7WoWZEn/v
zVFWNj+Ph82T77Yoc7F3aB7KRMyaOP4v5hCWbpJYVsTP8KYCQ5Ty1iDu52l0pa4i/u0pK9ZS1yRM
PMWJH+LVXIu1GjgRr7KIVgUf2gAWRt0OsGrONHHZZcniILhA4SZcyppSB+mp5xteOTgNdaLkGrbS
LyM32iPeSN731CeSjso/SLW4l5/65aiBw/S0Hc3nvT0eYeiAyDi7bgCQbGGlaw00RQkezbx8/qcl
8NU74KUHtYvyHaPWfEyhxmheaN9bzMoeaIgbnE6EqG3fntsvIH/AskMPTOoO38I7O8AEewgh8M7x
US6kgA0iQza8N1oFyXSIaeggqFWFRSeVNeBqQOKbpKxKtcY8w9vBIV3HdZxENWI/tNOSouTECjOj
21rErKTEvfnYV3mjiW/sgMAr/Y4Mhq6SfOkg0LkYObwz943HwpqONfIk2TRdz2IPi+04IVpeL3I8
GlDYtYpnO52NM2WEwv2Bc8YiPOEHCld3vJnj+DLY/vab3Um/v2Nyzyvdoy93d3QuX7kojthATHvQ
AZmGS+tRWmBlDin0LcpfB0nsr/iAkthCzQlK6pgkyEpKHh76+fIoGBiQ5l+AlTfsAQwqgNm9GQMA
0Pf1Lqq0+RqDzBhKvkdSMYA+YlCxiyJcE2CzjeEay5Q7DrueAkAMIuE+/00N1NQZuo4B/mPT6N5o
m6bwR1cBQGxtGSMM1z/0GI7s79KJOvygYWol7nQRY+gM36DsE7gHSy1U9KfBTlTk7ze0mcXT3FyP
3qrdXsL2CiVZSzDOqmMyDUEa7zelsf8Wht/R4+dxaeIuGM55CWSuNnMkmKjGnY11zQQDhRIhfhi1
L8M5SIBy5Qq1GyHlcCD8y4FYZ9MFElkLIMSTci6UxYJdp545oS/od29V1hTHnBaUHgQvt4/uUcHn
CYHLs/i6Rm1vFi6w18NI9FT4wI2Dw18B6EqV7Uu2RmBQT52DJchRN6rOrHDngCDom+gKBu7h+Qzk
TbW/WhDZwDXNAMA4kOyYta5pJjZkh1aXOR1nv9slFZO16kdJBYI1+ntc5C45ZLbHVErMI2c0FDPe
XGwHa0BujXkg8KSx9iS0HHyfxk5D4JFi2iIrYdBQgAz0Wo2HNjjwskCSmtMx5qA4K3mdm2lUMjJS
ZnIXKjDxrbOMC5+Q06NSYs/AAV4MCwTozKu2DlyTRzFBXzy6Cbrl7QUyHIgLcIIUyGeqYzicqqlj
PporVMLdu9VOukk8jfCMbuaXSeBjXdIjKMjI2cc1chZR07bo6cKJQUOUTyTkaSN7LYDJBYJXRQ9X
+RUzXZKFa0Zz5hr/VAvXo9lnPKif4vugFPBBXlSslKC52mEa8DpUV8/WE75uMUvj7KqiWG+V51zT
JMO5VJIOptji8jTmSBYYYuJPIlg5IybqlgSDUzmryqFGlIG8VBTNY1NSS6y8lcTibV1GfEYXncQ6
hyxRn9jEFB6lLoAwBVX8J0Q9kMEJpoRsnBu5yJNLwewMz47XDZTohCq5E8qfczm8znasyeSOCYQL
h39RaFDFkxVXNp5yaF7R2hlfiyJ32SdUoqmwwpknSzxDwLmUWuFkw6+ps7L4bqjTblcc8qVSLz5T
oMM6MEkQh9bwnFQehhmj5o+hPk4pZaNlhS6z7+9WkNMvGmaFp1TY16vvcRZ93i5Aoz67QibD0n7c
KlYyj62aQTHu7C50VIk7bDlYBquyFbIQ6m+y0LiIStHqoQ6zgF3gAXz9rVZf2nvVUmFltjFo3u7n
+nrV8gLQIiiisoHlEnOisObbsuEcnK6fDkR72gagd1i07XKo3IIKs4cCuIdZ8UiycTHmr8E2ygtw
vNDsBSrAMkm+cJaUK6zMQzOtm1AzBdrgcugKiyBnIIbIkMWXFzEd9RJ+c3Pz1QIh2q8hijkDGzzn
HIILrmtAlzIIPR4J35bRHDZ3jYujLKJ0zq/LzhMIthatSgp/0oQei8OI31N+6IQYexSLux7idIiH
ZTe87MX9Xd0D0lsSxikdr6LaWEpP2Owxvx6lfMosZhLuNUnoDXAfDQHAfh2ACkZBEfFogcHIMKAO
/ZpJPWjAMHOs8+E0F5j4oMLQwIqLOKAjmf90/gjpj/T819ok8HtNyZzZZWjwLhMMCahMwNOyC8Pv
OfSq62QKAn+Wryep1lSG3MCLr9u4Hq6GbX5g9/mjWGMvH90aqwkgdjk03SlyDmc6ua1inVd9C3le
BJ5gEAktSkK3HACvG1leKQKuntRfq9IyaVRcqdOD41GBa3pL0m5Lqgq+L422huHzAfACJ/y2T8Yf
OJQlVWAyxpLWjxbbix9Q5LBEt41C26TmxCusrypb5PA6TdaRBClkq0v0vJ/oaNonJBUrDmo8YTO2
NfEe6IJFnK5YHVo1QyoPnc0yXmL4YSMgtmRzGzIotSsC7/OZ9kYAlce1IWHieivMWctMmUPshCRu
ydzBU6TU6pat1cOX5l6EUaPBWqW7ymEUwArlhEURANSQbGJYy6krfLQHGFUMl5ATQUQnObtLg2Bt
lg/AT2c+EQteF1pmiOZvIGqQuM97ptFBQ7fUoCRTBmUjH4nZ72yohyYiUS3PGuu0lLQSivG00yS+
SjIyyVRnmMuzI6mM4KpqKTWT8w3bzj23jsSc4uD8bzzVgQTY6Wgy2gwtQNz5aok4fOLMityAZen0
DgGlYrySU+6R5yjxJMQUQlVGy1L6cxnr0IgNjBT8eGwnamNizhzcjrxS23+s9rq8hjtBJRadX2o/
Y0dxLSNxRfwgYfmPCy2gi3x+YFykSIan9kVGaADnjwNOa8p/+PE0mXsZExuX9+CNp2XbgCMV5Q+H
OZtkjn+ASKQMJbaCa2Ra0Mdv6gsoU6Zv3LDj3c74fJf/oDgNhnjsm7vhFO8hGn7TRgR/jsf6TX2O
wp+xsiMhcC8pTcCd3ueLx2M6t0ZA4U7g96zSPSvQTuy+Evub2M9S7yswFxDo/wg1mscH730bPkPe
Vm37imL+sgfEwghrWluH0VJX0nX8AEvbQ2onQmLVq5Jtk79sBj2ShfbqT0nZjq/zMNNMpzhtJzYb
avcVjLO2DmWf13PXS3aCyfoJvrRS00ZBk5KrPtmIV1Q22x5G4+yS+kOoHKgiJxm1MsfeCQIh4h3o
oxRArYLQ1zYWLdTwCR7mZMNCI2ZuNCnOqrnoejaE3QoiZRAq0MxGXDrF1yQ/K6ehy3mHARiVeUAv
gcAdBugZL4S7oq4wqSsaBk/S4eXFRPVUKkoDqZ/dzNIISPChg2iocEfn1kjSY3o42xxPNSABsLmF
RHjY9mYw1gAHi5rPeaoNbeoWtDXPOLxXwJA+9UotUgVM6DAfm9gaWQMDDFfPGooJp6UYghyRCIvF
I7dmjJPUiZOVC/g4K1mnQmNr4FSdao7qYB7qKqO2enJgxFWLU6aSYXhz9pwZ7ITW1gXN7mA06Ylr
KOSC50rtniW+50XWwCUePUmycm0DtUfnH4SSFGOjTViUd2zA8hZW+cbIQUHLM44O3rPAf57R5Fqg
aIiX95NlRFXOmwePMDjHMFx4jePRbUcbEMmN+8jXcc1KJUtfP9YpeOpKbTqIaCjSSyXEDIQxBKYc
YE0LnRK3GbBw/yd+WQG+KlpJldN9uWUtf0MywH9kql/a0bQbQnTuF1H4QpOwZq75+fJHMPyvOq/G
B7tK/ded8hOpbjw4NEPH2K0GQcjoLkbk6UcrKSUtVhMn3m4hxcDvtw7mR9udBJD0sCcjSNcyHDIO
gkJvLT7seqNK2GqzcuR4QiO406bCe23S8BfCtqXMjZAJjp9iTWCmfjiZQ3KMgp6kfIEkjB/FBH39
p5igQoO5r3PlH3WThvKFzoQhAtCftiyvtnRq88m6A12lCsAmU2IqavKGYDg2PGABSpEhNhQd1Zlt
k1rDAo1pnk3jVSUaOdwDGFBEpua39VA+rtlgw5PaCTOytW+eBmIwXmCn0xInoY4DUatWfosBCE/N
cW+OO7QxKlx+tYktmWRoSmiA23sPMIAfr+Kq4mzrrRJgFt9QWsKVhWpKgrsH2HBSRiNutKIZgbo9
0PP8Djrlina8CBFnTUhiMJ9vhtmWJhdrkuyIldTANec9I9O0xQoAQTUz2i/BM+KlPPxrzYLG3xt0
STjFxt8bdAlxo/00/v5WDJULQZ08Rxp5CqVJEdqh6hYEqrdt2RT4pZ6j7bQ+Ju3e0djf3+tSej1K
qUAAbXrhlBkfMqR4/ozbR0wr7Sgi6XpO2wUVNU7RWGemBYUOVaXYs7UyQmntU+qkIogEgSmUM1EV
Y4pu1gbYeYHzjXLIT4yoT0aVJBwO4Pedm9LjQ9sRNp5pei8+cO/0rfccDat9J+iQKr7oEpemXE+n
QE+bhm7DWiuzrfZWqdbcZAxEdtojbLLw87AtRkj/IWPtW0y1b7G5/z+YT+Pzjbb2f/KpenLxxcPk
or8d/7j5J33Hdx+/Ys+07Wk2tF70HtRsXanTap9gsKPAqEd4In2yTlKRHFQAwRC4dqco/XoeEIQz
DDopIjZpyJ0JtLyFAQR9NczmZqNccsQnrLhPC9cvMJTwBD6tppQAU0Vy2KUU0ChXEdUWuzZTDCfB
Xq0lhhvhRz5SD4oluMRB88HcCUZRspLawyThQLdgS0jhmc2YUtFuZLbICUdRUYIoHdKU3l1UaFei
dutw1Z0FVKH6wbs6PmO36Z53VowUExZDc10FnwuV54KGJREtv6YSOAYncl+WVIKlEiMjzaEVgwxd
yjQEvIsDwZPOaLalatIkzbaIERiYwecaFn7bnmGn6CTZ2PqN7f4VfOuIyr0D5WQKuXzuKe1aJxUF
3NwKkOJYX0WNwXykqSAR4dj2W00PW3qi4Q9PLY/j+iPwp/6q5NoSUmKZAXl4Ua64XRcV2VMXtegG
L1hiKjAUb/71STM76Rx1Jaj5Ctdp1osd/cxyWOpIK2IrR2SLYJSOD157cpS2P/fh8CsUvd1s08RW
Lqh8CXvIcdUiUsbzKRRhW4OPv9dqKMl8FBpXweGnuA5gNwBRehcuIO32nj+30qASjLxnYJyfY+P1
s24Ah20rDZ8ZjjyACQzdPqz5SrONf9SP3NSczx2GwsfbQRx91btkX7OJqOvnTuVZZ4x2dMsRs9rU
bIwXL75ov/TCKl6ZaGMztC7IXHtsuN1gl4B5TVIVjZsxaFBNXNjafizsdJ306i8d4uq1X7SB67/2
bs9oB0BF4/BlNkWPpHMHZlaQZvFVXiXkZ0zi6jqW6lghutZ7uKoiOYaPZzmLzDES92GAtQcrHywW
kAphL4YdTVmgN+bn8KSBhCjd8BCJ6xuv5Th+xyAjQ8G2Jx9sGmkSiGqCuiAf9L4t7zU+FqOZKdur
AFnIkkKRccTrhsRTSjGVWFEqiUrah2qF2M24cWWRxXgm4KFVa9Lmvlx26UYNFpbhuhIF1q03q3hH
kMLi5w3zQhOLWoJ6XGHlo39gNW5FS1L09anqzoS9uekiGV/Qbip+8hpnEi80drBDVZhria2j+DgN
/onpQ/qqpkS5Fko1TKWrL+nMNKqwPBSUmvaefxT7+/Ev/mG8R9lGVuv4KtZqLBeEZACOOMDe1G5Y
NV4nMEakwsl7PLFdTqjCywY5tJEMvsTD9nvcvYisb4oLsC72JSzJAne2g8xmCTVMKH/fC85oc3Wn
HiB5A7pyx0rqAkW4dlaRR/iUH9Whw7MUTGyZuchIiwVdabhICAuyCE/LnPrQXp6d1yqzzPYgy+Ib
M+i96klvjt/6H3eUNzeUYm7xTtm766okf7O073sV8YBjHNNJBn6ASjhBRHGUs6ZD1ErQdVv7ZvVG
3W73XF3DlzteLBoXm/3cjhLg/cXRuexbb5+TN7IvPXxJru6rGLR+Ca/jXTOXghc7bYwDMZhtEQQS
IaK6T+BOOp+aVYCyORBr1TOOvF0SyBeCqxPT2W5tWWT6h+b9m93OBfyfOXoDJlLHnL+RALn32J4+
1u/u3fngPj7YhwfpiTsePMAH99of5BkMkLhsjtqFYbGuZO5OonITZX3txoX3QaTN/5x7xCBCvG9S
Y2vr3KOFPNVCDO+5fXyuj8+1TNF77gCf29vw3N2ksK7MN1Jiq40ER5YENM1WAvjPhNMikPIz/bIB
CJa1MQHtc815j3O/uKrdItC8V/uvDMcdA8j8EnY2IMWmt9aCjRyIUbBXv8vNrkqLqmKLG9UMtXUk
b9CGl5smBYIRM3w0d3H6uvaXOHUj9izi0fNEag6XQ6z0E2/1npMuRWWbjZNLYcFwjlmayFuitlSw
9xqClOQkIG8NYDsgg7ljVGvJ47fufeqsLunRRzF0Hv96Gby976J+c58XT/i6QF0Yo2Mg3xKoC2J0
DOYrA3XNGJ1om4cH6jbE6FRKPThQJ5GvqJgukiqmIwdqLeScRlbDwB0SduHUuR84Ay5dRpoU9glh
/bcp9h6unlGStWjSqt6kVA5iyelMu5MnOfWZnMYFRfIcn+cmn9BXYiTKRLxGpNwlmmJfWSCugLu0
h2gQCwpOi7reHMgEFfdY3uZNTacoKtnhlTut4Ttd8AxrH2pxCt/gpR++QGMxw1YJ/lCTTaV30JKJ
YnENxIV0DqND1/Z2sqPzD8i4ZOvJivJsgLcX6hKQ70itsbsev0toteNOWtNzfoEHG0jiFDRWZoUD
Ib0meoYY24YtMRXrFifIdGKQCVz3rgXhRfrEmrPHAWW68it3c6bJUB1rh8/nbAOtxVgsPyWrVRx0
CPAsQ7k6zYMj2WXq8UwD6ukgSw4FzP4NnmK8dR1A7bx+rvvkTq2sM79AKMcza/HNKp7S5eWyoRwv
hueKG0fHtTbBz6oiDi/9jvab2sW0++f+0xg60F6+tn+6a7nSs1d3SGZG/ntHPYo9b0aTsZCsLAs7
uLSfEBa2qfGJKxe21kPr62oH+h03a/U5Hr6N/tOu/yWmFfRYmD2u29jGNvoScIwytGdgGO2Fo0D9
hZCmuwKKu2eX3K65pCL4YOZJeHnFSHII2Kwh92+go5Ca9qHgPucMhztdZyKLbYcdurycmyrAwNSZ
Rm9DkkuF1OkXVckHc4dew1B/zah5gfJCEFqec3pU+7TixGdFjjvZE0zu1j5v285tJ96GeA7g816S
lvNyXlGrfWtfC3NGKcx3FlzUYw3LBqkCxcIdfYIjy/UmeyKsqWxd6iu1c42uSNy2A9t4xa+qk+gd
w7jj/XDOrk9uYA0zFNS5NKG8ZUXdwAJI2ibxoT4kku4Oi4FenhmVZT7l6CSxMXEU61CYRP+wT+EN
+PvW5cg2Es3RK75jth6XhlRjDb9xEZkol7ZbURl91tBRSMggbewj+1lQ1LPC9DQdaPbkFDAktebS
JkqPZr3/OTe7BFwRTMzeLeKxlHyzrHfVamXITst3IbXcaoTEFoOygRI5WioRI5aotuLXrbqfprLB
SkH6mmscLXMJ9zMUUSQLbeRGkEyzIVjk/Mp2Y/Rk8KvRpjhLu5fw2yImy8uNabMOqsWcqu+xUdBv
XkbeMtuld21rFZh+ruwrWras3TpL9ZCT3iVV2+jOQbExhZbNKB5Cc//qJuXW7/6tY/7pUhurvRz9
h/yww9XatsakFtYtzfbR2XHHHJ0dScr74sfTjvnb0TH+vyOuaT0/O9oJm4k4TXqOIdK+keCw3PqE
cEZzjxz+VLyb2rgRnZ8XFZmvDeLEsLDLUGPH2j7SSLpbV21u5z/kWpL0g5i790h8g6V9sjAvGT/+
hRAA/lsXGTXDkV5znlXvYNnuZnpuR2OSvoVLIVvpdd7U18TxWoToLvkgfvd2blnX+ew+etfrvsRW
4jpwcw9YKljkqDxJnQ+aU2BLg0CZVhgRwp+s6dfIsIR71wfhVoF1CJJ8pWZs25ok1NrInGnXNzk5
W7MUr9XJs7hbXOtqi/Yaxc07YqMVXspQa2MIuYYRbQVynknWKbWnHvB3FXYMxNk6PHCD6rVuPL7j
V+MZ5IGo8I9oqnD3abXNlf70jbht3Ph+ogY4cgs21oltljlsdbbjSzwigQPv7xr6wqvdURHpWat3
mqgegX1aWRL9NWPv4o42yLQPJDIBY/lpcBFp3r3g1xtI7hUO270s9VOYcO003iGPwOuxUT8P84ZK
OAQOvqwq16sxDtjKuzweE5H6mOwIHM1eidA+1pPvXvXMmXYq1zsD3olSZjiDbGNfdUpKSssiUqcS
Q/ICWLIltMBLrgIlXvhF+sPx7mhALjHmrMcZ7u/sXgfRCz11BhNcZqDP4w1UwI727tANYz1m6vvx
r8PxpIOl6yaa1tSJd9z6TmL37uQFDi4HgrTQgIDzOOyxVAk1AZbOSJBTpTqZthslHnihxL6F8J/o
Pgn8f0A9vA3G4O0SAcbSg9L71Euvv/UGh3YwX7a2tngp3eaUpHAPP7W3/oT7I16aw3p0RXfmJh6j
ZqDJFBN9gqxj/TOm7CHArXcMlJ80YFbetcupPq2n72DDyt3ui32ypW0j8Khkm7pjruM07bKalIi2
plRskdoWqC7pGo4GALdR0kikK/SS8cyLg25/76VNrW5J+YJrXJH50vV7DrXTYAmXTYE5ibVB2Nxp
xUkGe2EZR9OquFSz4xqILsBJW93aq4iocdZVAk8WsXeABU8K4tV/ZqAVLadcGDJYVwsOtW6PBqeD
nZ5bmNYrP/Rm3eBCBOmZXGuq1qfwIaenHYAHXfWx4aF/88BUC3e7R21gVpBb1m4JL28Q19sO4YQs
drtUdLc24UmCkO4+TJZg4GAoBzMMooSoU+omMax0FJGxuU9o2KOODGB+JZ838Za+bA7Etgs5stTq
mF86CoH8lJ1e6H0T8zgA2k3NCz1qyqw++nWDxg6MR2yvfLmh2vrCcq972JV7Tbx45F93qeTxfUM/
us4ARQZqOQNZJ0lpZaRn06BIKNeTf4CjoDn+UgcO7tksMU80XZf2EmPf+/Hhlr/tf5Q9gGHqRE+N
Yxknd1rh8x4axkS2ETAkN/lS2OkiiT+zyezupeqZH7x+wVI8zkX+dkIkY7ygeEgRBI2CJ6aGY90q
78J/Ot4QDKRhuUs+0TtSwL0PiWJFzL4LTRGEmpiufhku1gxj3xdJhz6aCfb4V8aIuWxWecVrBVyU
wX+6+byLmiOhnvWYB9D7OigLjdTQYHOpK0HJM7dAILSniyz551pZgux6bBSwzhLaZLoJcVUYCLf1
jGSjaadjoCjfX8bWGTAkMfAqAvmd5lfYGoRfR7yuCnvDKrG3FKhR/SOyPw6Rxjde6BC1CvEZA6l8
8cCKEaO5iAw507a6OUh/4eTD29Him0XCXQRug5SkR4EEy/+9mMrf8ksg6wITqBhPZPJL6qBDQkAR
K9XLl/6nDMLLmiLmIJXWFE/Trr12QTmCYPCIK2tWmwOZVtyHaBLTjLg4gA/TziWPBDO0Lf5jG26I
ynK9tCSMXCDf88TBjqm68RymXllkqH9AzNdNBqFSBGQp0/ZmUgqWTB4qkbRWSigJGA7pLyHYfbTy
f6YLoZVCUgUPuMYrrgQI0qXn3nuUc2Ohas8Lu9fQQjDjo3O+KC+aFnnpxdClBSoxubr3NyvsgphN
XUzBe9BdvNrRm1xZqpL5BYsYXdnVoRIi2GgdvPeqpMaUeUY+VlTmfDEXHdCGjUWReVd1ieFfu8ZW
L/AUrCBP8EgD6wSLlU2rw+Yu0XMSqem1+GL50bg+exlj/DQpl7RO0Sxa0QoJFn6tEK3Tdl4/7iNV
qaD37L3raJSKQdIoxZKyrZ2OtEiICrysRS2ByJcNAiK2dziK5NObmzzmMevMrj2XQ1ibaCBhdxQU
o3NbtshnM9whimlSgOFd0mmq0sMj0GFOUnHaOLwxeMVWSY7XC7l+YMpe3MtCyo24bkH+gNU8ZTbr
Er1MtMb9X2mTfB7c08goXMF+AI1nzRZKB1iIcn5QSpppw3nBWoQzpXAXE7I2nFxGKVPG6RA9OZRV
P1USHCJZFWttkWk9SMFEwVl2jF13G/GFUO6qKzT68eTc/Pb6I8mvJPP4BzZXJdlrOV2jjMJXKwcc
BCyToi5j/aSoRFpgFks+kZqB6x1r/V3wmMBhaZqK8EvfnIxOhuaCHKHQiBz73ptYi6VkrNjAZJGZ
UbYUk1kuYYtAZceRVa3WBVvTNGThDUlil/ZLzVtmGO50CEgz2CWxFHu7O4IRINmKfBMtonRoFIT3
DGxq7wHFyprNroWDiuhD1L+x54Cru9L+wFAz6qF1rE0X8bMhHiDyzrsDCNwj2udI66gME00Xb4/M
L/B5PFvx8e924SlftvsLh8DJ5EzQ8r/GLRLMCV8lT5zs4kmStoC4l6aoYVzyJah0AZ3h+3FcfEkN
KOyGFuHB15CnCdpitB6/9T9KRaCagw4OniJarioRaHQmmVw+KRFpx9NO+Bx7y5cLFHe+z3RoRpdn
z0bDI7DoDw4OuuB8K61ctZBfcsnSYa2XDrqNcWhbafPIFMjOKDy8BEk31WNpFqrrm+LlVkOWP4nA
ohb1uV3u8I9ef6LU83ibv59EU7S9ywU/OcbNeQS0sk9a2sBeg+X4V4MnelLsqULHlCvyq8DYl77i
EnMJsHXLMywAVdku8PXWEGEd0tc9+frfYT1goNse0MRnREoA0K1uh+bo7OTk7JSO8RCVKDD07Ihz
+2KHpHGxaeSHDUziec9cHmNPcVcWp7I5bgg9WthnujdxhXF5cf0jikMDqaTVmOopZM1LsUGOvVsM
z+2F2zD6jvnt4CPFA+U2ZLt2OdfBEAakBMTzf7p885SvVsAjU4C/RsQJw174uq1BCiBEb0DOAN4N
OEOE4+Q2E5eO+/jyfac2CCiN6ScxrdpHUNCvd0lLeXTWhqRR0JuGZ13E1DbKkxWIJoodrV7wbpDe
Wr7hvXfwuv9y99keCvZng7+fm9ev4EfF5/D1Kzu/Z4SNMANdrIlNzGLyuXCRQDRidSwdc70EHGLO
jDkWGQ3Hb00VfSI/E5vrs20NqjcqbKEdXYhEMZfC3fQuJ0geRbU8/kUV+HLiE2OlxLBl1gVSRSIJ
9iDwNI2SJW0FhrGSYmVx/muiH03a0nb6p/AExg9uXVmqYmKCSLeWWJPYI10g4QSwoUFIgyiU+yu8
2hxBlzHN6x1sP4O0QDfr38D4ErMbYwdJ5ThQdzR3sMV8/TKa8TW+4gcDHtLL+JaDDFiYz+PalKyr
n5GYFnLQ9171qPgeBeWOCaZgrjIFHY4Z8kwXTBnsMpXNvO+KOCX7UEkV+b4eNbiwJP3h6LyLTA/q
YCW9/Gn56F9KLpqiUgc1gKwrKlKx/skyxdMZJXiu7Ayhk8froKmMEJB4OLKMMFc8Z0ubwip4esEd
Ooj0Eje7wBYVLH9nEauRYWEqoj8yLjjpFdbPyqR8HzfXSmjmRS9gEVgISkHGJnb3RtD6MQQwxLBA
rAADvdeQEQl4PRV1Z7yljVVwmAcPetLZign3W87p5APSIHPhUHwHxMYto49N2iqqoKKgCe0A/7BH
x25RoU+TALxb0L+Suki383g7s+elDdeE80G+AcNVHLBCAgnTYZAlpds4rc2AW91jdd79sgWQGsMb
MForPFt0nGCRTF40KeYO0ecVm+WwMu0ySaYlwscyOEthcupyLjH1Cshry1u/PoeBeD0U3uZy2Yc/
MbSXqevBAk+tkJ4D+7KyW0mRsUKAFM1ezwkCIAFYlljycGO6WCkFhiKbQudCbGuSDFqK/JFpdB1Q
LaLfjQXiaXzDt7y4M0OuEBA9fGdye7cI2Rb3K+m5KcIlkXQegoH9G2MrHGqX4HDxoARL6V2rxb4C
EafQeYo9LbfWUDkL7CvwuhmCjbCRWTHDozs5HflxA3PlkwswipD0VxfIHegdb48r6Si/JY2tbP6J
78pBzwjF45K3ZLwhn9Nrm6+QDFhCghwgA/DqyoYTNKUAIZ3bSX6PvcTnsCiA8S7iMkmZDidURlnL
01mRF9PjhXucqy5tqWy4YA6E8+eEgwqPExMuSLJtNTCsSni59+1JCs3ylt7QeAVuusJjUmIG6NkV
4q5Izy7wgnM/FJwCx16woF0AuZ4ow8vhuIP/GQ8uxt4VNUSxC7CCTpyF+ev55LwAHZfmdNxwGtdJ
xw9M3QPudB4iy9cB45HQJahPvk5KX/ezK+THIoy6/kYgizVsRDn85FH9FpTAsscVNy5zZhdJT+hH
3m3CNIYHghD2u31hQSOISHfWitUrtWgA8mIFKyfSFQRa7Y+YE3v8OzkY1XOvT8mZNNnyl9Kxdo6C
ruSQqpN619EtGSPcKwEJO6fjee6IBH60SVpuNyPbpnrdmXdO2vklPa/PDH6oOwqsJ7K87QcG/IG9
vng1uZuKq0hGy4UiuQ6I35closY49shgo2ULBvit1E1SjTpw7qNsp5J/dlvSrKwwqaI896qobQiY
5sa1vV65ONfsgpSsUuucG3vegq6wYGhlfCcetN1upZSSmtuRw4SN6LiIQmZWguKS5j18Pna94vSi
XoMRYdqECEBxWqoR3dIIkZ4PT6nRF60m3t7VqYlHbWCCbdfReaQAcImhX2lGrZuWzDZCDORQSiuP
wtKrGdzyYXEoOUhXEYW2k17cszPwLwEBAEpDgi75pbK3I+bEfg/0g7Ro4qa+p9a2cD8oE2BwTaNd
P42P+s8uj/Zed+oBMPPUd1U8+7DbtoRyLaaYIyTUwJjhCn28Gaio/fi040FZg7YBKHuWgX/b+2gu
e+aHIpplmNZ9+lfgCmr2RtsENR0HaGk7j7S1ncSW2UPfeo+2Qvm0g15O/4DieXv9Pkz0BA9jm/7r
1y/dgPsfzTvsrLlYp7/DXsrAbgIEjqKSxr/ombew7Fg09onPJfy9Z36KpvmkzDO8o/Xpxfj80AzM
GIUEdj9y8Z05KW+QMmO8nd6PIT4lnODt/qtXgNZPUbZGCx0Qe+EQO/hoQJO9I7vktjG0eXp5DAO3
BJgArKLA45i9fZSoA/AEUhzjFY3hW6EtnPK8hVOe/fxjHwbGtaelp0UembckSo/AZMDIujlGUQ9I
/J0TNKbf2wU8FlW1Onz27Pr6uoeCv5cXV8/YkXw2n86E83qr2VxWCQBQSsMi9GIzQic5carjyRAj
i5Ky3cMx2u+BFyAYkU7qO4RePoBCheNL6TBQ5HMUORgqFvq86O0DNqQgkbdVviNz3YHi9VU/67/a
3UeSWZRefQSfKr7KzSUY91H3qFj/3jFj0DzR7B9mOCmiBWg14Lc8TsGj+AQGNZEbbAsMqW29j4qy
FI1ztABnNo3yEv5VgA2br8BKzUuZnBfmZwHwaBbE41+psCXiB+mNhyfQO3ZBEyD9iGKy0x4FQs9H
w+9Lc/CcUsAZWWxbyziuSMZ7exgfPk6ukgoYbUQi8NxVqf3yy2g0wgX8nKe9g37/Ofjtq97BwYvu
wXOQRyr2PO5+DSsXky5H8QNUfofifqihfZZ+o3NzoplNeBJQvxwfm+c4EG7zfr+/Bziur9Cf6b9+
9ZrA9w96EkMvv8eUA9VQ2X1ei9njV5d5hoVvBQizyMUhTigk683xWG60FANNWjyYsVMXR5i3paT/
YIkCVFyO/X1gnf+IMiwgugCnDTjwGATZT3tHB4IA6L+f8hIE8dHAvH7e35fvzxfggR2av/TNwe4r
+OG5eXHwYo9/exvdBL88f7knbz0wC3EZYZ4kMW/XoKOW0bPTfLK+pW/GOUiR6NkwKaPJugClU0Wf
YEfdRawX3Zfd/efmr/AeQMiiq+g6Mpf6r+6ntVhr+afb3PQP+l3ghb75aXA+OA2n+qpv9g1Ioldm
f/f1C3+q7hegwV4w1f9V4lyS7vxL1q0I+S8J4/y//720MweJIjbEc9BxeD30kYaZmuFu99P20Q6H
abSQ9zKfwqa8Ndu433aA1/D2EI7JXEi9sxcU8AO55L2j2kydZ57YANQUA5MchJivi4wydwwF7XPc
xHKdFSrnz6zHyDYyUvK45GhxZkNiWKXLELCbLQYWE4oGY3O9kmQv3WcROudajij3iHUELzFiVjan
SJhgyj2ZrKm3RJLxVWY4QkInV6sOeRD5WlQRhgGBK1WaoMeCrfg76s3NjC2A4qN1Ng5IYTHtrOcF
QQosuFst5F4cLL6NuZgIPXh0oKcc7Q3JxmDYrvQq6sKou1fmIXHzJYhVzZjbQNM1NjPRpjR08GuZ
f9ZcSB1/Q+EKa70GkcI6e9nUg/0FlGGUSZt0VDp0ls+17GE4GhVerWGLcpjEiyRZWFYd8LJhhJSO
Tll8vBA9gnQR2bDQ198XCtIDULradI4VIaMQB9p4K1FBNgXVlLsrZdIou1pTGyOmBDkKw+wKOTCI
u6Wg5SnAbKPjpQHGoCoa6fFTUIXtKqZYakSV/NxsgqFQAPhzjj299B7BlgXB7SJNKPKi1K10FTR9
bmz4RSOKKsFXTAYm1ALK8r8Lgpung0swt56aSVQmzMDjd0OjZgJeIjwajn81g9Pj4AcRjKc/jk6H
w4vR6Y9mPLj8q3l7dnE0NMejy6P3g9HJpRm8f29+HlxcDE7Ho+Flxwx/Ob8YXl6aswthx5Pz96Ph
MdgKp0fvPxwjnB8+8AHZ96OT0XgIo57B4L8qlF8Bi8GYUMHc55mkCRg1GP1kMB6dnZp3w4vh6NT8
PILxERj8hkgOCdTF6Md3Y8SB/hIUHsvQ2nv8ywvwZUdEmLM5GV4cvYM/Bz+M3o+AJjCVt6PxKVL2
LU7LnA8uxqOjD+8HF+b8w8X52eVQwp//t/73KKSUPrT3/+//AFBLAQIUABQAAAAIALu9Wi+bZPrB
kTsAADbJAAAiAAAAAAAAAAEAIAC2gQAAAABkcmFmdC1pZXRmLWF2dC1ydHAtanBlZzIwMDAtMDQu
dHh0UEsFBgAAAAABAAEAUAAAANE7AAAAAA==

------_=_NextPart_000_01C39D84.BF702EB0--

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



From exim@www1.ietf.org  Tue Oct 28 15:23:29 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22488
	for <avt-archive@odin.ietf.org>; Tue, 28 Oct 2003 15:23:29 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEaMv-0005IU-UD
	for avt-archive@odin.ietf.org; Tue, 28 Oct 2003 15:23:09 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SKN9xo020308
	for avt-archive@odin.ietf.org; Tue, 28 Oct 2003 15:23:09 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEaMn-0005FW-1P; Tue, 28 Oct 2003 15:23:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEaMj-0005FG-A8
	for avt@optimus.ietf.org; Tue, 28 Oct 2003 15:22:57 -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22374;
	Tue, 28 Oct 2003 15:22:45 -0500 (EST)
Message-Id: <200310282022.PAA22374@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: avt@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Tue, 28 Oct 2003 15:22:44 -0500
Subject: [AVT] I-D ACTION:draft-ietf-avt-ulp-08.txt
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Audio/Video Transport Working Group of the IETF.

	Title		: An RTP Payload Format for Generic FEC with Uneven Level Protection
	Author(s)	: A. Li
	Filename	: draft-ietf-avt-ulp-08.txt
	Pages		: 33
	Date		: 2003-10-28
	
This document specifies a payload format for generic Forward
   Error Correction (FEC) for media data encapsulated in RTP. It is
   based on the exclusive-or (parity) operation, and it is a
   generalized algorithms that includes Uneven Level Protection
   (ULP). The payload format described in this draft allows end
   systems to apply protection using arbitrary protection lengths
   and levels, in addition to using arbitrary protection group
   sizes. It enables complete recovery or partial recovery of the
   critical payload and RTP header fields depending on the packet
   loss situation. This scheme is completely backward compatible
   with non-FEC capable hosts. Those receivers that do not know
   about FEC can simply ignore the protection data. This draft will
   obsolete RFC 2733 and RFC 3009.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-ulp-08.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-avt-ulp-08.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-avt-ulp-08.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-10-28145509.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-avt-ulp-08.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-avt-ulp-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-10-28145509.I-D@ietf.org>

--OtherAccess--

--NextPart--



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



From exim@www1.ietf.org  Tue Oct 28 15:24:26 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22597
	for <avt-archive@odin.ietf.org>; Tue, 28 Oct 2003 15:24:26 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEaNq-0005hv-F2
	for avt-archive@odin.ietf.org; Tue, 28 Oct 2003 15:24:06 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SKO5JV021541
	for avt-archive@odin.ietf.org; Tue, 28 Oct 2003 15:24:05 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEaNn-0005U6-1S; Tue, 28 Oct 2003 15:24:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEaNS-0005RO-9T
	for avt@optimus.ietf.org; Tue, 28 Oct 2003 15:23:42 -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22510;
	Tue, 28 Oct 2003 15:23:31 -0500 (EST)
Message-Id: <200310282023.PAA22510@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: avt@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Tue, 28 Oct 2003 15:23:30 -0500
Subject: [AVT] I-D ACTION:draft-ietf-avt-ilbc-codec-03.txt
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Audio/Video Transport Working Group of the IETF.

	Title		: Internet Low Bit Rate Codec
	Author(s)	: S. Andersen
	Filename	: draft-ietf-avt-ilbc-codec-03.txt
	Pages		: 175
	Date		: 2003-10-28
	
This document specifies a speech codec suitable for robust voice 
communication over IP. The codec is developed by Global IP Sound 
(GIPS). It is designed for narrow band speech and results in a payload 
bit rate of 13.33 kbit/s for 30 ms frames and 15.20 kbit/s for 20 ms 
frames. The codec enables graceful speech quality degradation in the 
case of lost frames, which occurs in connection with lost or delayed IP 
packets.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-ilbc-codec-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-avt-ilbc-codec-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-ilbc-codec-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:	<2003-10-28145602.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-avt-ilbc-codec-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-avt-ilbc-codec-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-10-28145602.I-D@ietf.org>

--OtherAccess--

--NextPart--



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



From exim@www1.ietf.org  Tue Oct 28 15:25:23 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22718
	for <avt-archive@odin.ietf.org>; Tue, 28 Oct 2003 15:25:23 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEaOk-0005p8-Qr
	for avt-archive@odin.ietf.org; Tue, 28 Oct 2003 15:25:02 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SKP10x022259
	for avt-archive@odin.ietf.org; Tue, 28 Oct 2003 15:25:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEaOj-0005mt-Ea; Tue, 28 Oct 2003 15:25:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEaNm-0005Tr-Be
	for avt@optimus.ietf.org; Tue, 28 Oct 2003 15:24:02 -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22543;
	Tue, 28 Oct 2003 15:23:49 -0500 (EST)
Message-Id: <200310282023.PAA22543@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: avt@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Tue, 28 Oct 2003 15:23:49 -0500
Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-ilbc-03.txt
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Audio/Video Transport Working Group of the IETF.

	Title		: RTP Payload Format for iLBC Speech
	Author(s)	: A. Duric, S. Andersen
	Filename	: draft-ietf-avt-rtp-ilbc-03.txt
	Pages		: 12
	Date		: 2003-10-28
	
This document describes the RTP payload format for the internet Low 
Bit Rate Coder (iLBC) Speech [1] developed by Global IP Sound 
(GIPS). Also, within the document there are included necessary 
details for the use of iLBC with MIME and SDP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-ilbc-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-avt-rtp-ilbc-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-ilbc-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:	<2003-10-28145909.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-avt-rtp-ilbc-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-avt-rtp-ilbc-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-10-28145909.I-D@ietf.org>

--OtherAccess--

--NextPart--



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



From exim@www1.ietf.org  Tue Oct 28 15:25:26 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22735
	for <avt-archive@odin.ietf.org>; Tue, 28 Oct 2003 15:25:26 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEaOo-000611-Q4
	for avt-archive@odin.ietf.org; Tue, 28 Oct 2003 15:25:06 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SKP4UL022847
	for avt-archive@odin.ietf.org; Tue, 28 Oct 2003 15:25:04 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEaOk-0005pa-Vo; Tue, 28 Oct 2003 15:25:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEaNs-0005iQ-Fg
	for avt@optimus.ietf.org; Tue, 28 Oct 2003 15:24:08 -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22558;
	Tue, 28 Oct 2003 15:23:57 -0500 (EST)
Message-Id: <200310282023.PAA22558@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: avt@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Tue, 28 Oct 2003 15:23:56 -0500
Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-jpeg2000-04.txt
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Audio/Video Transport Working Group of the IETF.

	Title		: RTP Payload Format for JPEG 2000 Video Streams
	Author(s)	: E. Edwards
	Filename	: draft-ietf-avt-rtp-jpeg2000-04.txt
	Pages		: 21
	Date		: 2003-10-28
	
This document describes a payload format for transporting JPEG
2000 video streams using RTP (Real-time Transport Protocol). JPEG
2000 video streams are formed as a continuous series of JPEG 2000
still images. This payload format will allow for scalability and
robustness of JPEG 2000's potential to be maximized in streaming
applications.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-jpeg2000-04.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-avt-rtp-jpeg2000-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-avt-rtp-jpeg2000-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-10-28150106.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-avt-rtp-jpeg2000-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-avt-rtp-jpeg2000-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-10-28150106.I-D@ietf.org>

--OtherAccess--

--NextPart--



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



From exim@www1.ietf.org  Tue Oct 28 16:09:27 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22596
	for <avt-archive@odin.ietf.org>; Tue, 28 Oct 2003 15:24:26 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEaNq-0005gb-9b
	for avt-archive@odin.ietf.org; Tue, 28 Oct 2003 15:24:06 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SKO52t021543
	for avt-archive@odin.ietf.org; Tue, 28 Oct 2003 15:24:05 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEaNn-0005Uk-TK; Tue, 28 Oct 2003 15:24:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEaNb-0005Rn-E3
	for avt@optimus.ietf.org; Tue, 28 Oct 2003 15:23:51 -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22526;
	Tue, 28 Oct 2003 15:23:40 -0500 (EST)
Message-Id: <200310282023.PAA22526@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: avt@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Tue, 28 Oct 2003 15:23:39 -0500
Subject: [AVT] I-D ACTION:draft-ietf-avt-rtcpssm-05.txt
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Audio/Video Transport Working Group of the IETF.

	Title		: RTCP Extensions for Single-Source Multicast Sessions with Unicase Feedback
	Author(s)	: J. Chesterfield
	Filename	: draft-ietf-avt-rtcpssm-05.txt
	Pages		: 39
	Date		: 2003-10-28
	
This document specifies a modification to the Real-time Transport 
Control Protocol (RTCP) to use unicast feedback. The proposed 
extension is useful for single source multicast sessions such as 
Source Specific Multicast (SSM) communication where the traditional 
model of many-to-many group communication is either not possible or 
not preferred. In addition, it can be applied to any group that 
might benefit from a sender controlled summarised reporting 
mechanism.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcpssm-05.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-avt-rtcpssm-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-avt-rtcpssm-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-10-28145630.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-avt-rtcpssm-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-avt-rtcpssm-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-10-28145630.I-D@ietf.org>

--OtherAccess--

--NextPart--



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



From exim@www1.ietf.org  Tue Oct 28 17:55:31 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04292
	for <avt-archive@odin.ietf.org>; Tue, 28 Oct 2003 17:55:31 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEck5-00033R-GM
	for avt-archive@odin.ietf.org; Tue, 28 Oct 2003 17:55:14 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SMtDNC011737
	for avt-archive@odin.ietf.org; Tue, 28 Oct 2003 17:55:13 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEcju-0002vl-MA; Tue, 28 Oct 2003 17:55:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEcje-0002u0-S5
	for avt@optimus.ietf.org; Tue, 28 Oct 2003 17:54:46 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04260
	for <avt@ietf.org>; Tue, 28 Oct 2003 17:54:34 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AEcjc-00022q-00
	for avt@ietf.org; Tue, 28 Oct 2003 17:54:44 -0500
Received: from dundee.dcs.gla.ac.uk ([130.209.242.163])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AEcjb-00021q-00
	for avt@ietf.org; Tue, 28 Oct 2003 17:54:43 -0500
Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:62582 helo=csperkins.org)
	by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.04)
	id 1AEcj5-0002f1-00; Tue, 28 Oct 2003 22:54:12 +0000
Date: Tue, 28 Oct 2003 22:54:07 +0000
Content-Type: multipart/mixed; boundary=Apple-Mail-2-1027617691
Mime-Version: 1.0 (Apple Message framework v552)
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>
To: avt@ietf.org, Eddie Kohler <kohler@icir.org>
From: Colin Perkins <csp@csperkins.org>
Message-Id: <A2BA263A-0999-11D8-8015-000A957FC5F2@csperkins.org>
X-Mailer: Apple Mail (2.552)
Subject: [AVT] Draft agenda for Minneapolis
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>


--Apple-Mail-2-1027617691
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

Folks,

Attached is the draft agenda for the AVT meeting in Minneapolis. Please 
send any comments or corrections to the chairs.

Those who have agenda time scheduled are requested to prepare a summary 
of the issues they wish to discuss, and to send this to the mailing 
list ahead of the meeting. This gives those who won't be attending the 
opportunity to post their comments and concerns, and potentially even 
reach some consensus, before the meeting time is consumed. It also 
gives other participants the opportunity to consider the issue in more 
depth. Summary messages SHOULD be sent to the mailing list by Monday 
3rd November.

We also request that all presenters send us their slides ahead of time, 
preferably in PDF format. This has multiple purposes:

   - It streamlines the presentation process by having the presentations 
on
     a single laptop.

   - It avoids the delay that sometimes occurs in getting the 
presentations
     sent to us after the meeting, for inclusion in the minutes.

   - It allows us to preview the presentations to see if they are 
following
     the guidelines for what should be covered during the meeting.

Presentations SHOULD be submitted before 12 noon EST (GMT -05:00) on 
Friday 7th November. Agenda time is conditional on sending both a 
summary of open issues and a copy of your slides ahead of the meeting, 
and 5 minutes ahead doesn't count!

Those presenting new drafts: briefly describe the basic problem and 
your proposed solution, discuss known issues, limitations and problems, 
outline where you want input from the working group, and how you wish 
us to proceed.  When presenting work which has been previously 
discussed: describe only the changes from the previous draft, highlight 
unresolved problems, and propose future directions. Presenters are 
reminded of the requirements for disclosure of intellectual property 
relating to contributions, in section 10 of RFC 2026.

We strongly encourage all participants to read all relevent drafts 
before the meeting, and to comment on the open issues raised on the 
mailing list.

Thanks for your assistance to try to conduct an effective meeting.

Colin & Magnus


--Apple-Mail-2-1027617691
Content-Disposition: attachment;
	filename=agenda.txt
Content-Type: text/plain;
	x-unix-mode=0644;
	name="agenda.txt"
Content-Transfer-Encoding: 7bit

Audio/Video Transport Working Group

CHAIRS: Colin Perkins     <csp@csperkins.org>
	Magnus Westerlund <magnus.westerlund@ericsson.com>


Monday, 10th October 2003 at 09:00-11:30
=====================================

Introduction, and Status Update				(Chairs)	5
	draft-ietf-avt-crtp-enhance-07.txt		=> RFC 3545
	draft-ietf-avt-rtp-new-12.txt			=> RFC 3550
	draft-ietf-avt-profile-new-13.txt		=> RFC 3551
	draft-ietf-avt-rtp-mime-06.txt			=> RFC 3555
	draft-ietf-avt-rtcp-bw-05.txt			=> RFC 3556
	draft-ietf-avt-dsr-05.txt			=> RFC 3557
	draft-ietf-avt-evrc-smv-03.txt			=> RFC 3558
	draft-ietf-avt-rtp-retransmission-09.txt	[AD Evaluation]
	draft-ietf-avt-rtcp-feedback-07.txt		[AD Evaluation]
	draft-burmeister-avt-rtcp-feedback-sim-02.txt	[AD Evaluation]
	draft-ietf-avt-tcrtp-07.txt			[AD Evaluation]
	draft-ietf-srtp-09.txt 				[IESG review]
	draft-ietf-avt-mpeg4-simple-08.txt		[RFC Editor]
	draft-ietf-avt-rtcp-report-extns-06.txt		[RFC Editor]
	draft-ietf-avt-uxp-06.txt
	draft-ietf-avt-rfc2833bis-03.txt	
	draft-ietf-avt-rtp-clearmode-03.txt
	draft-ietf-avt-mpeg1and2-mod-00.txt
	draft-sparks-avt-2833-interop-00.txt
	draft-kerr-avt-vorbis-rtp-02.txt
	draft-herlein-speex-rtp-profile-01 
	draft-jones-avt-audio-t38-01.txt
	draft-ramalho-rgl-rtpformat-02.txt
	draft-chen-rtp-bv-01.txt	

Updates on behalf of author				(Chairs)	15
	draft-ietf-avt-ulp-08.txt
	draft-ietf-avt-rtp-jpeg2000-04.txt
	draft-ietf-avt-midi-rtp-00.txt
	draft-ietf-avt-midi-guidelines-00.txt
	draft-lazzaro-avt-rtp-framing-contrans-02.txt

RTP payload format for AMR-WB+ audio codec		(Lakaniemi)	15
	draft-sjoberg-avt-rtp-amrwbplus-00.txt
	
Highlights of VMR-WB RTP Payload and Storage Format 	(Ahmadi)	15 
	draft-ahmadi-avt-rtp-vmr-wb-00.txt

RTP payload formats for ETSI DSR front ends		(Xie)		15
	draft-ietf-avt-dsr-es202050-01.txt
	draft-xie-avt-xdsr-es202211-00.txt
	draft-xie-avt-xadsr-es202212-00.txt

RTP payload format for ATRAC-X				(Hatanaka)	15
	draft-hatanaka-avt-rtp-atracx-03.txt

Internet Low Bit Rate Codec & its RTP payload format	(Duric)		15
	draft-ietf-avt-rtp-ilbc-02.txt
	draft-ietf-avt-ilbc-codec-03.txt
	
RTP Payload for Text Conversation			(Hellstrom)	15	
	draft-hellstrom-avt-rfc2793bis-02.txt

Way forward for the RTP payload format for Timed Text	(Rey)		15
	draft-rey-avt-3gpp-timed-text-01.txt

RTP Payload Format for Uncompressed Video 		(Gharai)	10
	draft-ietf-avt-uncomp-video-04.txt

RTP payload Format for H.264 Video			(Wenger)	15
	draft-ietf-avt-rtp-h264-03.txt


Wednesday, 12th October 2003 at 09:00-11:30
===========================================

RTCP Extensions for SSM with Unicast Feedback		(Ott)		15
	draft-ietf-avt-rtcpssm-04.txt

Extended Secure RTP Profile for RTCP-based Feedback 	(Ott)		15
	draft-ietf-avt-profile-savpf-00.txt

RTCP Streaming Extended Reports				(Tseng)		15
	draft-tseng-avt-rtcp-streaming-extens-00.txt

Proposed additions to RTP MIB				(Clark)		15
	 draft-clark-avt-rtpmibv2-00.txt
	 
Datagram Congestion Control Protocol (DCCP) and RTP	(Kohler)	30
	draft-ietf-dccp-spec-05.txt
	draft-ietf-dccp-ccid2-04.txt
	draft-ietf-dccp-ccid3-04.txt
	draft-ietf-dccp-ccid3-thin-00.txt	 

RTP Header Compression over Multi-Hop Paths		(Ash)		30
	draft-ash-e2e-voip-hdr-comp-rqmts-01.txt

SDP parameters for supporting H.263 and H.261 options	(Roni)		30
	draft-even-avt-h263-h261-options-00.txt
	draft-nismail-mmusic-sdp-video-00.txt
	draft-basso-avt-videoconreq-00.txt


--Apple-Mail-2-1027617691--


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



From exim@www1.ietf.org  Wed Oct 29 11:18:33 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16889
	for <avt-archive@odin.ietf.org>; Wed, 29 Oct 2003 11:18:33 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEt1Q-00037I-Uf
	for avt-archive@odin.ietf.org; Wed, 29 Oct 2003 11:18:13 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9TGICWP011976
	for avt-archive@odin.ietf.org; Wed, 29 Oct 2003 11:18:12 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEt1F-00034P-9I; Wed, 29 Oct 2003 11:18:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEt0X-00030K-Vf
	for avt@optimus.ietf.org; Wed, 29 Oct 2003 11:17:19 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16774
	for <avt@ietf.org>; Wed, 29 Oct 2003 11:17:07 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AEt0X-00048M-00
	for avt@ietf.org; Wed, 29 Oct 2003 11:17:17 -0500
Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AEt0V-00048F-00
	for avt@ietf.org; Wed, 29 Oct 2003 11:17:16 -0500
Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125])
	by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9TGHDI2006778;
	Wed, 29 Oct 2003 17:17:14 +0100 (MET)
Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id V6M19RTS; Wed, 29 Oct 2003 17:17:13 +0100
Message-ID: <3F9FE7F6.6000906@ericsson.com>
Date: Wed, 29 Oct 2003 17:16:54 +0100
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Alan Tseng <alan@vidiator.com>, Gamze Seckin <gamze@vidiator.com>
CC: IETF AVT WG <avt@ietf.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [AVT] Comments on draft-tseng-rtcp-streaming-extns-00.txt
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hi,

Here is my comments on your draft:

1. First I think the draft isn't very clear on why any metrics are 
needed. In the 3GPP document it only states: "The objective of the 
streaming service quality metrics is to offer to the service providers 
means to evaluate the end user experience.". This doesn't make it very 
clear what the real needs are. I think further developing of this is 
needed.

2. Regarding the corruption statistics. For media that uses codec that 
have prediction any error normally remains for a rather long time. 
However it is very difficult to determine when the effects has been 
removed. Therefore this measurement is hard to derive on the receiver 
side. Combined with the definition it only provides a good, possibly bad 
indication. Also looking at the reasons for corruption, the only real 
reason is lost or late packets. A good feeling for the quality can be 
determined by the server simply by employing packet loss vector 
reporting and knowing when the buffer is empty.

3. The rebuffering measurements makes more sense. However there are at 
least one client that does not really perform rebuffering, namely 
quicktime. Instead is assumes that if the transmitted bit-rate is 
acceptable any short term effects will go away and the client will later 
  have a buffer fullness given by the initial buffering delay. The 
interesting thing about this measurement is that in 3GPP they already 
have a way of letting the server measure when rebuffering takes place, 
namely the OBSN reporting specified in TS 26.234 REL 6 (only preliminary 
versions available).

4. As state privately before this drafts need to be checked against the 
ID nits: http://www.ietf.org/ID-nits.html

5. Section 1. The introduction is basically the same as the 
introduction. I would recommend you to write a better more informative 
introduction.

6. Section 1. Last sentence: "As all the other report blocks
defined in [1], the streaming report blocks are applicable to
one-to-one or one-to-many applications that generate
RTCP SR or RR reports." This sentence is not really correct. The use of 
the RTCP XR reports is possible in any application sending RTCP.

7. Section 2, You talk about AVP, but this extension is not dependent on 
any special profile and seems to be compatible with any of the four 
available or under development profiles that exist.

8. Section 2, Figure 1. This figure shows this report formats potential 
need to have reporting from all layers on the receiving side. This might 
be a problem for certain application architectures. I am not saying that 
it can't be used, its only that some applications may have difficulties 
to include your reports.

9. Section 3.1, first paragraph: "All timestamps reported by the XR 
packet SHALL be RTP timestamps. All durations SHALL be in units of the 
RTP timebase." This definition is not clear, because in applications 
allowing for switching between payload types the rate can change. I 
think that the intention of using the RTP timestamp value for indication 
over what interval which the report covers is a good one. However some 
more consideration over formulation must be done.

10. Section 3.3, PAge 5, first bullet after figure 2:
"- at the AVP module: Packet drop and packet errors can sometimes be
detected by incorrect or missing sequence number or checksum. " Do you 
really need to consider bit-errors, the only allowed possibility for 
bit-errors in RTP is if partial checksums are used. Bit-errors surviving 
to the transport layer is the meaning to be caught by the UDP, etc., 
checksum.

11. Section 6. The streaming metrics should probably have a value to 
combine with the parameter to indicate how often the report block should 
be included. This seem to be a block that is not needed very often.

12. Section 8. The security section does not look sufficient. I guess 
that the consideration for this is rather similar to the VoIP block. 
However I think there should be made some effort to indicate the main 
security concerns also in this document.

13. Section 12. The references need to be divided into Normative and 
Informative ones.

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 exim@www1.ietf.org  Thu Oct 30 04:43:32 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15287
	for <avt-archive@odin.ietf.org>; Thu, 30 Oct 2003 04:43:32 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AF9Kh-0005ix-Jd
	for avt-archive@odin.ietf.org; Thu, 30 Oct 2003 04:43:13 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9U9hB2P021953
	for avt-archive@odin.ietf.org; Thu, 30 Oct 2003 04:43:11 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AF9KX-0005bp-2J; Thu, 30 Oct 2003 04:43:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AF9Jc-0005UI-Lm
	for avt@optimus.ietf.org; Thu, 30 Oct 2003 04:42:04 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15248
	for <avt@ietf.org>; Thu, 30 Oct 2003 04:41:53 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AF9JZ-0000Lv-00
	for avt@ietf.org; Thu, 30 Oct 2003 04:42:01 -0500
Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AF9JZ-0000Lr-00
	for avt@ietf.org; Thu, 30 Oct 2003 04:42:01 -0500
Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120])
	by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9U9fuI2016312;
	Thu, 30 Oct 2003 10:42:00 +0100 (MET)
Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id V637MJMR; Thu, 30 Oct 2003 10:41:59 +0100
Message-ID: <3FA0DCCE.1060305@ericsson.com>
Date: Thu, 30 Oct 2003 10:41:34 +0100
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Takeshi Yoshimura <yoshimura@spg.yrp.nttdocomo.co.jp>
CC: Rod.Walsh@nokia.com, finlayson@live.com, avt@ietf.org
References: <F0D879F44A9F8D498E1C07736E7BED6001C30843@trebe003.europe.nokia.com> <20031030181018.04F3.YOSHIMURA@spg.yrp.nttdocomo.co.jp>
In-Reply-To: <20031030181018.04F3.YOSHIMURA@spg.yrp.nttdocomo.co.jp>
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [AVT] Re: [MMUSIC] time-lined static media with FLUTE & IMG
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hi,

The static media draft is dead. I have no plans of updating it as I
currently don't think it is the right approach to the problem. The usage
of RTP actually seems rather unnecessary. Most of the functionality in
RTP is not at all needed and other things where missing. Here I find the
FLUTE solution more addressing the problems around binary object
transport for multicast. However I don't know its performance for
unicast, however for any unicast session HTTP is probably usable if one
can schedule the GET command appropriately and to know when to stop
requesting because it is to late.

The FLUTE solution are still missing many vital parts to my
understanding. The first is how to achieve the synchronization. One
could for example use SMIL however this requires one to have resolved
how one performs the referencing to downloaded binary objects. To my
understanding a defined cache utilizing FLUTEs source URI declaration
could be a possibility. There also seem to be shortcoming that no real
effort has been made into defining how the session declaration should be
made.

The usage of RFC 2733 or ULP does not seem to provide the necessary FEC
performance to be used in multicast delivery, at least not for objects
larger than a few packets. However this is not my expertise area, but I
assume there are good reasons why more advanced algorithms like
reed-solomon or tornado codes seem to be used in the area.

I don't think this problem space has any straightforward solutions. It
is hard problems, requiring well thought through solutions. There is
definitely need to do more work in the area.

My personal feeling in regards to MBMS is that the work is to hurried to
be able to produce a good solution.

As a conclusion to the original question, I would say that the
application of FLUTE for time-lined static media delivery as combination
to multicasted continuos media like audio and video requires further
investigation.

Cheers

Magnus

Takeshi Yoshimura wrote:

> Hi Rod and Magnus,
> 
> I'm also considering a reliable and time-lined static media delivery,
> because it is discussed in 3GPP as one of the services over 3G MBMS
> (Multimedia Broadcast/Multicast Service).
> 
> You seem to extend FLUTE for this purpose, but I think combining generic
> RTP format (Magnus's draft) and RTP-FEC format (e.g, RFC2733,
> draft-ietf-avt-ulp, draft-ietf-avt-uxp) is more straightforward way.
> What do you think of this approach?
> 
> Regarding this issue, what's the current status of
> draft-westerlund-avt-rtp-static-media-01?  Is there any technical
> problem with this?
> 
> Best regards,
> Takeshi
> 
> 
>>Hi Magnus, Ross (and everyone)
>>
>>1ス-2 years back there was a draft on time-lined static media (draft-westerlund-avt-rtp-static-media-01) - basically to send files, text (etc) with timed presentation along with AV media streams. Since the basic requirements haven't gone away, but RMT has made progress on usable protocols, what do you think about using FLUTE (draft-ietf-rmt-flute-02) for the same job? With a quick comparison I think it should be pretty straight forward, although you may have some preferences (or extensions to the FLUTE-FDT) if you already have a working RTP-payload'ed implementation.
>>
>>Ross mentioned sending ID-3 tags in-band with audio streams. Any ideas you have on doing this with FLUTE (ID3) and RTP (music) could be pretty useful for the Internet Media Guide (IMG) work in MMUSIC - how to move around (and announce) metadata for 'foo' multicast and unicast sessions.
>>
>>Cheers, Rod.

-- 

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 exim@www1.ietf.org  Thu Oct 30 04:52:22 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15503
	for <avt-archive@odin.ietf.org>; Thu, 30 Oct 2003 04:52:22 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AF9TG-0006VX-Qs
	for avt-archive@odin.ietf.org; Thu, 30 Oct 2003 04:52:02 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9U9q2Ev025012
	for avt-archive@odin.ietf.org; Thu, 30 Oct 2003 04:52:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AF9TF-0006Ul-Ob; Thu, 30 Oct 2003 04:52:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AF8r1-0002w3-SS
	for avt@optimus.ietf.org; Thu, 30 Oct 2003 04:12:32 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14623
	for <avt@ietf.org>; Thu, 30 Oct 2003 04:12:21 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AF8qz-00001u-00
	for avt@ietf.org; Thu, 30 Oct 2003 04:12:29 -0500
Received: from mail0.yrp.nttdocomo.co.jp ([202.245.184.18] ident=root)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AF8qy-00001r-00
	for avt@ietf.org; Thu, 30 Oct 2003 04:12:28 -0500
Received: from spg.yrp.nttdocomo.co.jp (spg.yrp.nttdocomo.co.jp [172.21.48.130])
	by mail0.yrp.nttdocomo.co.jp (8.12.10/YRPHUB0-8820020412) with ESMTP id h9U9CI8w022273;
	Thu, 30 Oct 2003 18:12:18 +0900 (JST)
Received: from [172.21.51.150] (yoshi-nec.mml-ad.yrp.nttdocomo.co.jp [172.21.51.150])
	by spg.yrp.nttdocomo.co.jp (8.12.6/8.12.6) with ESMTP id h9U9CGoV091859;
	Thu, 30 Oct 2003 18:12:16 +0900 (JST)
Date: Thu, 30 Oct 2003 18:12:17 +0900
From: Takeshi Yoshimura <yoshimura@spg.yrp.nttdocomo.co.jp>
To: Rod.Walsh@nokia.com
Cc: <magnus.westerlund@ericsson.com>, <finlayson@live.com>, <avt@ietf.org>
In-Reply-To: <F0D879F44A9F8D498E1C07736E7BED6001C30843@trebe003.europe.nokia.com>
References: <F0D879F44A9F8D498E1C07736E7BED6001C30843@trebe003.europe.nokia.com>
Message-Id: <20031030181018.04F3.YOSHIMURA@spg.yrp.nttdocomo.co.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.05.04
Content-Transfer-Encoding: 7bit
Subject: [AVT] Re: [MMUSIC] time-lined static media with FLUTE & IMG
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hi Rod and Magnus,

I'm also considering a reliable and time-lined static media delivery,
because it is discussed in 3GPP as one of the services over 3G MBMS
(Multimedia Broadcast/Multicast Service).

You seem to extend FLUTE for this purpose, but I think combining generic
RTP format (Magnus's draft) and RTP-FEC format (e.g, RFC2733,
draft-ietf-avt-ulp, draft-ietf-avt-uxp) is more straightforward way.
What do you think of this approach?

Regarding this issue, what's the current status of
draft-westerlund-avt-rtp-static-media-01?  Is there any technical
problem with this?

Best regards,
Takeshi

> Hi Magnus, Ross (and everyone)
> 
> 1ス-2 years back there was a draft on time-lined static media (draft-westerlund-avt-rtp-static-media-01) - basically to send files, text (etc) with timed presentation along with AV media streams. Since the basic requirements haven't gone away, but RMT has made progress on usable protocols, what do you think about using FLUTE (draft-ietf-rmt-flute-02) for the same job? With a quick comparison I think it should be pretty straight forward, although you may have some preferences (or extensions to the FLUTE-FDT) if you already have a working RTP-payload'ed implementation.
> 
> Ross mentioned sending ID-3 tags in-band with audio streams. Any ideas you have on doing this with FLUTE (ID3) and RTP (music) could be pretty useful for the Internet Media Guide (IMG) work in MMUSIC - how to move around (and announce) metadata for 'foo' multicast and unicast sessions.
> 
> Cheers, Rod.


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



From exim@www1.ietf.org  Thu Oct 30 05:18:29 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16030
	for <avt-archive@odin.ietf.org>; Thu, 30 Oct 2003 05:18:28 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AF9sX-0000V6-0j
	for avt-archive@odin.ietf.org; Thu, 30 Oct 2003 05:18:09 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9UAI8TU001866
	for avt-archive@odin.ietf.org; Thu, 30 Oct 2003 05:18:08 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AF9sR-0000Ss-4A; Thu, 30 Oct 2003 05:18:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AF9s6-0000N1-Bc
	for avt@optimus.ietf.org; Thu, 30 Oct 2003 05:17:42 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16019
	for <avt@ietf.org>; Thu, 30 Oct 2003 05:17:29 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AF9s1-0000l9-00
	for avt@ietf.org; Thu, 30 Oct 2003 05:17:37 -0500
Received: from dundee.dcs.gla.ac.uk ([130.209.242.163])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AF9s1-0000l0-00
	for avt@ietf.org; Thu, 30 Oct 2003 05:17:37 -0500
Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:61249 helo=csperkins.org)
	by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.04)
	id 1AF9qp-0001Ai-00; Thu, 30 Oct 2003 10:16:23 +0000
Date: Thu, 30 Oct 2003 10:16:20 +0000
Subject: Re: [AVT] Re: [MMUSIC] time-lined static media with FLUTE & IMG
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: Rod.Walsh@nokia.com, <magnus.westerlund@ericsson.com>,
        <finlayson@live.com>, <avt@ietf.org>
To: Takeshi Yoshimura <yoshimura@spg.yrp.nttdocomo.co.jp>
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <20031030181018.04F3.YOSHIMURA@spg.yrp.nttdocomo.co.jp>
Message-Id: <1B1B3AC2-0AC2-11D8-9E64-000A957FC5F2@csperkins.org>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
Content-Transfer-Encoding: 7bit
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

On Thursday, Oct 30, 2003, at 09:12 Europe/London, Takeshi Yoshimura 
wrote:
> I'm also considering a reliable and time-lined static media delivery,
> because it is discussed in 3GPP as one of the services over 3G MBMS
> (Multimedia Broadcast/Multicast Service).
>
> You seem to extend FLUTE for this purpose, but I think combining 
> generic
> RTP format (Magnus's draft) and RTP-FEC format (e.g, RFC2733,
> draft-ietf-avt-ulp, draft-ietf-avt-uxp) is more straightforward way.
> What do you think of this approach?
>
> Regarding this issue, what's the current status of
> draft-westerlund-avt-rtp-static-media-01?  Is there any technical
> problem with this?

There was some discussion of this idea in the past - see the minutes of 
AVT at the 51st (London) IETF for example.

-- 
Colin Perkins
http://csperkins.org/


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



From exim@www1.ietf.org  Thu Oct 30 10:54:25 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27989
	for <avt-archive@odin.ietf.org>; Thu, 30 Oct 2003 10:54:25 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AFF7e-0004MP-Dv
	for avt-archive@odin.ietf.org; Thu, 30 Oct 2003 10:54:06 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9UFs6lD016716
	for avt-archive@odin.ietf.org; Thu, 30 Oct 2003 10:54:06 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AFF7Z-0004KZ-Jr; Thu, 30 Oct 2003 10:54:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AFF7J-0004JZ-0E
	for avt@optimus.ietf.org; Thu, 30 Oct 2003 10:53:45 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27983
	for <avt@ietf.org>; Thu, 30 Oct 2003 10:53:33 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AFF7G-0005Mh-00
	for avt@ietf.org; Thu, 30 Oct 2003 10:53:42 -0500
Received: from m5tmail.m5t.com ([66.129.134.18])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AFF7F-0005Lg-00
	for avt@ietf.org; Thu, 30 Oct 2003 10:53:42 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 30 Oct 2003 10:51:12 -0500
Message-ID: <AB5AF73EAF23304EA1B932174137CED7032284@m5tmail.m5t.com>
Thread-Topic: SRTP session keys generation using AES-CM
Thread-Index: AcOe/aUO+eWmCO3KRraFlQVO7YXTYg==
From: "Sylvain Latulippe" <slatulippe@m5t.com>
To: <avt@ietf.org>
Content-Transfer-Encoding: quoted-printable
Subject: [AVT] SRTP session keys generation using AES-CM
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable


Hi,

I am confused regarding AES-CM initialization for PRF (IV vs AES-CM =
input).

According to draft-ietf-avt-srtp-09.txt (B.3 Key Derivation Test =
Vectors), Cipher key generation uses AES-CM input (x*2^16) which is the =
same value as IV?

Do I init AES-CM IV and than use the same value for encryption input?

Thanks,

Sylvain Latulippe,
M5T Inc.


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



From exim@www1.ietf.org  Fri Oct 31 05:12:12 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19979
	for <avt-archive@odin.ietf.org>; Fri, 31 Oct 2003 05:12:12 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AFWG2-0007Ub-Ug
	for avt-archive@odin.ietf.org; Fri, 31 Oct 2003 05:11:55 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9VABsIp028795
	for avt-archive@odin.ietf.org; Fri, 31 Oct 2003 05:11:54 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AFWEQ-0007LJ-Hq; Fri, 31 Oct 2003 05:10:14 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AFWDl-0007Fx-9Z
	for avt@optimus.ietf.org; Fri, 31 Oct 2003 05:09:33 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19950
	for <avt@ietf.org>; Fri, 31 Oct 2003 05:09:20 -0500 (EST)
From: juha-pekka.luoma@nokia.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AFWDh-00052l-00
	for avt@ietf.org; Fri, 31 Oct 2003 05:09:29 -0500
Received: from mgw-x1.nokia.com ([131.228.20.21])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AFWDh-00052i-00
	for avt@ietf.org; Fri, 31 Oct 2003 05:09:29 -0500
Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33])
	by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9VA9TY16824
	for <avt@ietf.org>; Fri, 31 Oct 2003 12:09:29 +0200 (EET)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T659e750e9cac158f21b70@esvir01nok.ntc.nokia.com>;
 Fri, 31 Oct 2003 12:09:28 +0200
Received: from esebe015.NOE.Nokia.com ([172.21.138.54]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747);
	 Fri, 31 Oct 2003 12:09:29 +0200
Received: from trebe004.NOE.Nokia.com ([172.22.232.177]) by esebe015.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747);
	 Fri, 31 Oct 2003 12:09:23 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
Date: Fri, 31 Oct 2003 12:09:22 +0200
Message-ID: <481D6FFB3BD60E4CB590F39C59098400024F77E4@trebe004.europe.nokia.com>
Thread-Topic: [MMUSIC] time-lined static media with FLUTE & IMG
Thread-Index: AcOeykdaUni+QEZXREmWOoO4Xh7TWAAEQBHwAC6M7uA=
To: <Magnus.Westerlund@ericsson.com>
Cc: <avt@ietf.org>
X-OriginalArrivalTime: 31 Oct 2003 10:09:23.0690 (UTC) FILETIME=[0EFDD4A0:01C39F97]
Content-Transfer-Encoding: 7bit
Subject: [AVT] RE: [MMUSIC] time-lined static media with FLUTE & IMG
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hi Magnus,

It was good to learn of your views on Flute! We have been thinking on similar lines about the possible use SMIL for synchronizing Flute transfers with media streams. The use of SDP for describing the sessions of the FLUTE protocol has been in the plans. We have also been preliminarily considering the use of both SMIL and SDP for our work on Internet Media Guides in MMUSIC.

Looking forward to seeing you in Minneapolis!

-Pekka

-------------------
Juha-Pekka Luoma
Nokia Research Center
Tampere, Finland
-------------------

> -----Original Message-----
> From: ext Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]
> Sent: Thursday, October 30, 2003 11:42 AM
> To: Takeshi Yoshimura
> Cc: Walsh Rod (NRC/Tampere); finlayson@live.com; avt@ietf.org
> Subject: Re: [MMUSIC] time-lined static media with FLUTE & IMG
> 
> 
> Hi,
> 
> The static media draft is dead. I have no plans of updating it as I
> currently don't think it is the right approach to the 
> problem. The usage
> of RTP actually seems rather unnecessary. Most of the functionality in
> RTP is not at all needed and other things where missing. Here 
> I find the
> FLUTE solution more addressing the problems around binary object
> transport for multicast. However I don't know its performance for
> unicast, however for any unicast session HTTP is probably 
> usable if one
> can schedule the GET command appropriately and to know when to stop
> requesting because it is to late.
> 
> The FLUTE solution are still missing many vital parts to my
> understanding. The first is how to achieve the synchronization. One
> could for example use SMIL however this requires one to have resolved
> how one performs the referencing to downloaded binary objects. To my
> understanding a defined cache utilizing FLUTEs source URI declaration
> could be a possibility. There also seem to be shortcoming that no real
> effort has been made into defining how the session 
> declaration should be
> made.
> 
> The usage of RFC 2733 or ULP does not seem to provide the 
> necessary FEC
> performance to be used in multicast delivery, at least not for objects
> larger than a few packets. However this is not my expertise 
> area, but I
> assume there are good reasons why more advanced algorithms like
> reed-solomon or tornado codes seem to be used in the area.
> 
> I don't think this problem space has any straightforward solutions. It
> is hard problems, requiring well thought through solutions. There is
> definitely need to do more work in the area.
> 
> My personal feeling in regards to MBMS is that the work is to 
> hurried to
> be able to produce a good solution.
> 
> As a conclusion to the original question, I would say that the
> application of FLUTE for time-lined static media delivery as 
> combination
> to multicasted continuos media like audio and video requires further
> investigation.
> 
> Cheers
> 
> Magnus
> 
> Takeshi Yoshimura wrote:
> 
> > Hi Rod and Magnus,
> > 
> > I'm also considering a reliable and time-lined static media 
> delivery,
> > because it is discussed in 3GPP as one of the services over 3G MBMS
> > (Multimedia Broadcast/Multicast Service).
> > 
> > You seem to extend FLUTE for this purpose, but I think 
> combining generic
> > RTP format (Magnus's draft) and RTP-FEC format (e.g, RFC2733,
> > draft-ietf-avt-ulp, draft-ietf-avt-uxp) is more straightforward way.
> > What do you think of this approach?
> > 
> > Regarding this issue, what's the current status of
> > draft-westerlund-avt-rtp-static-media-01?  Is there any technical
> > problem with this?
> > 
> > Best regards,
> > Takeshi
> > 
> > 
> >>Hi Magnus, Ross (and everyone)
> >>
> >>1ス-2 years back there was a draft on time-lined static 
> media (draft-westerlund-avt-rtp-static-media-01) - basically 
> to send files, text (etc) with timed presentation along with 
> AV media streams. Since the basic requirements haven't gone 
> away, but RMT has made progress on usable protocols, what do 
> you think about using FLUTE (draft-ietf-rmt-flute-02) for the 
> same job? With a quick comparison I think it should be pretty 
> straight forward, although you may have some preferences (or 
> extensions to the FLUTE-FDT) if you already have a working 
> RTP-payload'ed implementation.
> >>
> >>Ross mentioned sending ID-3 tags in-band with audio 
> streams. Any ideas you have on doing this with FLUTE (ID3) 
> and RTP (music) could be pretty useful for the Internet Media 
> Guide (IMG) work in MMUSIC - how to move around (and 
> announce) metadata for 'foo' multicast and unicast sessions.
> >>
> >>Cheers, Rod.
> 
> -- 
> 
> 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 exim@www1.ietf.org  Fri Oct 31 05:42:27 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20657
	for <avt-archive@odin.ietf.org>; Fri, 31 Oct 2003 05:42:27 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AFWjK-0002S9-Lv
	for avt-archive@odin.ietf.org; Fri, 31 Oct 2003 05:42:10 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9VAgAXP009385
	for avt-archive@odin.ietf.org; Fri, 31 Oct 2003 05:42:10 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AFWiE-0002In-9x; Fri, 31 Oct 2003 05:41:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AFWha-0002FZ-Ki
	for avt@optimus.ietf.org; Fri, 31 Oct 2003 05:40:22 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20624
	for <avt@ietf.org>; Fri, 31 Oct 2003 05:40:09 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AFWhX-0005OV-00
	for avt@ietf.org; Fri, 31 Oct 2003 05:40:19 -0500
Received: from manatick.foretec.com ([4.17.168.5] helo=manatick)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AFWhW-0005OS-00
	for avt@ietf.org; Fri, 31 Oct 2003 05:40:18 -0500
Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49])
	by manatick with esmtp (Exim 4.24)
	id 1AFWhW-0003Tp-AZ
	for avt@ietf.org; Fri, 31 Oct 2003 05:40:18 -0500
Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120])
	by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9VAdtI2008732;
	Fri, 31 Oct 2003 11:39:55 +0100 (MET)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72)
	id <V637W3RX>; Fri, 31 Oct 2003 11:40:02 +0100
Message-ID: <1F55F6582266314A85A55F6241509B67078E5562@Esealnt863.al.sw.ericsson.se>
From: "Karl Norrman (KI/EAB)" <karl.norrman@ericsson.com>
To: "'Sylvain Latulippe'" <slatulippe@m5t.com>
Cc: avt@ietf.org
Subject: RE: [AVT] SRTP session keys generation using AES-CM
Date: Fri, 31 Oct 2003 11:36:58 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>

Hello,

 >-----Original Message-----
 >From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf 
 >Of Sylvain
 >Latulippe
 >Sent: den 30 oktober 2003 16:51
 >To: avt@ietf.org
 >Subject: [AVT] SRTP session keys generation using AES-CM
 >
 >
 >
 >Hi,
 >
 >I am confused regarding AES-CM initialization for PRF (IV vs 
 >AES-CM input).
 >
 >According to draft-ietf-avt-srtp-09.txt (B.3 Key Derivation 
 >Test Vectors), Cipher key generation uses AES-CM input 
 >(x*2^16) which is the same value as IV?
 
Yes, the cipher key is generated by the PRF, which takes x
as input. That PRF input is then used to compute x*2^{16},
which is then used as IV for AES-CM.

Note that the IV is the first block that is encrypted  by AES.
The output of of that encryption is the first block of the output of the PRF.

 >
 >Do I init AES-CM IV and than use the same value for encryption input?

I'm not sure what you mean by "encryption input". The IV is the only input
to AES in the PRF, i.e., the IV is the cleartext input to AES and the encrypted
IV is the first part of the PRF output.

Regards,
Karl

 >
 >Thanks,
 >
 >Sylvain Latulippe,
 >M5T Inc.
 >
 >
 >_______________________________________________
 >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 exim@www1.ietf.org  Fri Oct 31 11:03:44 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04999
	for <avt-archive@odin.ietf.org>; Fri, 31 Oct 2003 11:03:44 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AFbk5-0007Qq-Ho
	for avt-archive@odin.ietf.org; Fri, 31 Oct 2003 11:03:27 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9VG3HJu028562
	for avt-archive@odin.ietf.org; Fri, 31 Oct 2003 11:03:17 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AFbir-0007J1-1R; Fri, 31 Oct 2003 11:02:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AFbig-0007Ho-Qd
	for avt@optimus.ietf.org; Fri, 31 Oct 2003 11:01:52 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04969
	for <avt@ietf.org>; Fri, 31 Oct 2003 11:01:36 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AFbie-0002H5-00
	for avt@ietf.org; Fri, 31 Oct 2003 11:01:48 -0500
Received: from manatick.foretec.com ([4.17.168.5] helo=manatick)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AFbid-0002H2-00
	for avt@ietf.org; Fri, 31 Oct 2003 11:01:47 -0500
Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47])
	by manatick with esmtp (Exim 4.24)
	id 1AFbid-0001rF-FE
	for avt@ietf.org; Fri, 31 Oct 2003 11:01:47 -0500
Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125])
	by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9VG1USs029573;
	Fri, 31 Oct 2003 17:01:31 +0100 (MET)
Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id V6MGAYR3; Fri, 31 Oct 2003 17:01:30 +0100
Message-ID: <3FA2875A.3090603@ericsson.com>
Date: Fri, 31 Oct 2003 17:01:30 +0100
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Adam Li <adamli@icsl.ucla.edu>, IETF AVT WG <avt@ietf.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [AVT] Comments on draft-ietf-avt-ulp-08.txt
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hi Adam,

I have a number of comments on the ULP draft. I hope that most can 
easily be incorporated in the next update so that we can have a version 
possibly ready for working group last call.

1. The short copyright notice on first page is missing. It is required 
for a WG document.

2. The section numbering and corresponding text is strangely displaced 
and not on the same line.

3. Section 1, second paragraph: "(2) flexible enough to support a wide 
variety of FEC mechanisms," What is meant with this?

4. I think the different protection levels needs more explanation. I 
think a new section about this should be added before section 6. It 
needs to explain how the different levels relate. And how one achieves 
better protection for the lower layers.

5. In section 6 there is some unclearities on how one determines what is 
the SSRC that should be used in the recovery operation. For example in 
the case of SSRC multiplexing it is definitely not clear. Also in cases 
with RFC 2198 or session multiplexing it needs to be clarified.

6. You haven't updated the references to RFC 1889 to RFC 3550 yet, 
please do.

7. Section 6.3: "The sequence number has the standard definition: it 
MUST be one higher than the sequence number in the previously 
transmitted FEC packet." I don't think this definition is correct. I 
think you should rely on using it as defined in the RFC 3550. There are 
certain use cases it will be increased with more than one between FEC 
packets, for example in RFC 2198.

8. Section 6.3: What about the usage of the marker bit. It might be 
simplest to simple declare it as being set to 0.

9. Section 6.4: The Mask field. I think it might be advantage of 
reversing the order of the MASK field. That way the first 16 bit are 
always representing 1 to 16 higher than base, instead of for L=0 mean 
1..16 and for L=1 mean 33..48.

10. Section 6.5 "It indicates the protection length provided by the
    ULP FEC for Level 0 (i.e., the payload length after the header)." 
This is not correct as in cases where the SSRC, or RTP header extension 
are in use the payload does not start 96 bits from the packet beginning.

11. Section 6.5, bullet list after figure 4:
  " The setting of mask field when the extended mode FEC is used shall
    follow the following rules:

       a. A media packet can only be protected at each protection level
          once.

       b. For a media packet to be protected at level p, it must also
          be protect at level p-1.

       c. If an ULP FEC packet contains protection at level p, it must
          also contain protection at level p-1."

I don't think these rules are very clear. For example (a), does it mean 
that it can only be done once in each packet or that in any FEC packet 
for level 0 the same packet may only be protected by one FEC packet? I 
don't see reasons for this limitation. The text should also use 
normative wording.

12. Section 7.2.2: The first paragraph: Do you mean associated when you 
use corresponding? I also think the text can be improved regarding clarity.

13. Section 8. There is missing text about the problem when a packet can 
only be partially recovered. Some application may be able to use those 
packets other not. There should be some text talking about the problem. 
Also how one knows that it has happened should be pointed out. What I 
understand the recovery lengths if they does not match the recovered 
packet length field.

14. Section 8.1, bullet 14.
	 "Take the next 16 bits of the recovery bit string. Whatever
           unsigned integer this represents (assuming network-order),
           take that many bytes from the recovery bit string and append
           them to the new packet. This represents the CSRC list,
           extension, payload, and padding."

How does one know how much is padding? Are you meaning RTP padding here? 
Please clarify.

15. Section 8.2.1, "a string of number of bytes of the protection length 
0 is copied to the new packet." I guess there is a missing "for level" 
before the "0".

16. Section 8.2.2: Bullet 2. Why is the padding pattern not fully 
defined to be 0 for example. This is obviously something prevent 
interoperability between implementations.

17. Section 8.2.2: Shouldn't there be a step copying the data to the 
recovered packet so far. There is also missing text requiring the 
operation to be performed first at the lower levels before doing it at 
level N.

18. Section 9, Figure 6. The SSRC value is not obvious to be 2, that is 
depending on the use case. Secondly the SN number is not clear. Unless 
one explains that this is in a separate RTP session it is not logical.

19. Section 9, figure 16, in relation to rules on, in this example the 
media packets with SN 11 and 12 are protected in another FEC packet but 
not in this. IF I interpret the rules quoted in bug 11 then this is not 
allowed.

20. Section 10. I think one should be more explicit about the need to 
define how encryption is performed in relation to the encryption operation.

21. Section 10. I think one should also explicit mention the problems 
with integrity of FEC packets. Changing some bits in the FEC payload has 
hugh impact on calculation and the correct recovery of packets. Changing 
the length recovery field can result in the recovery of too long 
packets. Also the computionatial complexity can be effect up to at least 
one magnitude.

22. Section 11. The usage of different use cases are not clear here. 
Both the PT multiplexing and the SSRC multiplexing cases should be 
discussed.

23. Section 12.1 What happens with the rate if one switches payload type 
to another that has different RTP timestamp rates?

24. Section 12.1 Author Change controller: This should be written as you 
and the AVT WG.

25. Section 15. The references needs to be split into Normative and 
Informative ones.

26. Please go through the ID nits properly.

27. Abstract: In the last sentence you use the word draft. I think you 
should replace it with specification. I also think the introduction 
should explain why it obsolete the RFCs mentioned.


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 exim@www1.ietf.org  Fri Oct 31 12:32:04 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09547
	for <avt-archive@odin.ietf.org>; Fri, 31 Oct 2003 12:32:04 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AFd7j-0001GD-3A
	for avt-archive@odin.ietf.org; Fri, 31 Oct 2003 12:31:47 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9VHVlv8004843
	for avt-archive@odin.ietf.org; Fri, 31 Oct 2003 12:31:47 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AFd70-00016Z-L9; Fri, 31 Oct 2003 12:31:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AFd6l-000146-Jn
	for avt@optimus.ietf.org; Fri, 31 Oct 2003 12:30:47 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09496
	for <avt@ietf.org>; Fri, 31 Oct 2003 12:30:34 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AFd6j-0003o6-00
	for avt@ietf.org; Fri, 31 Oct 2003 12:30:45 -0500
Received: from ftpbox.mot.com ([129.188.136.101])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AFd6j-0003nz-00
	for avt@ietf.org; Fri, 31 Oct 2003 12:30:45 -0500
Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231])
	by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h9VHUgAe013487;
	Fri, 31 Oct 2003 10:30:43 -0700 (MST)
Received: from motorola.com (d1421-0a1070d5.cig.mot.com [10.16.112.213])
	by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id h9VHTmQe013823;
	Fri, 31 Oct 2003 11:29:48 -0600
Message-ID: <3FA29C84.8A6D7C@motorola.com>
Date: Fri, 31 Oct 2003 11:31:48 -0600
From: Qiaobing Xie <Qiaobing.Xie@motorola.com>
X-Mailer: Mozilla 4.8 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
CC: IETF AVT WG <avt@ietf.org>, Colin Perkins <csp@csperkins.org>
References: <3F9E6B28.6090307@ericsson.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [AVT] Re: Comments on DSR drafts
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hi, Magnus,

Thank you very much for the feedback. Please see my comments/answers
in-line.

Magnus Westerlund wrote:
> 
> Hi Qiaobing,
> 
> I have looked at your three dsr drafts:
>   draft-ietf-avt-dsr-es202050-01.txt
>   draft-xie-avt-xdsr-es202211-00.txt
>   draft-xie-avt-xadsr-es202212-00.txt
> 
> 1. My first comment is that these three draft could easily be folded
> into a single draft. To my understanding they have a lot in common. The
> only real difference is the actual internal frame format and that 050
> have shorter frames then 211 and 212. Then there is the need define
> individual MIME types for each. However this seems to be about all.
> Having a single draft will reduce the workload on IESG and RFC editor
> slightly. It will also make it less RFC to keep track of.

I talked with Steve C. about this a year ago. At that time, the
front-ends were at very different maturity levels in ETSI. So we agreed
to create separate draft for each front-end. Now things have progressed
and my understanding is that all three front-ends above are finalized in
ETSI. So, I think to combine them may be a good thing to do.

We can either merge 050 and 212 into one draft (since they are more
logically related) and leave 211 stand-alone, or fold all three into one
draft. I will double-check with my ETSI colleagues about this and if
there is no other issues, will release merged version after this IETF
meeting.

> 2. You should make a reference to maxptime rather then define it
> yourself. Either RFC 3267 or make it dependent on SDP-new.

will do.

> 
> 3. I think the security consideration is a bit thin. Are you really
> certain that the format does not result in any special considerations?

Besides defining their specific frame bit-format, these payload
definitions do not add anything else to the standard RTP functions (they
may be one of the most straightforward RTP payloads). I really do not
see any special security issues introduced. I'd appreciate for any input
on this.

> 
> 4. You might want to clarify in mapping MIME to SDP that even if no rate
> is given the default value must be given here.

ok

> 
> 5. What use is the NULL frame? It is defined in all drafts but not
> declared how they should be used.

It is used to signal the end of a transmission segment, per definition
in ETSI specs (it is also discussed in RFC3557). Will make it clearer in
the new drafts.

regards,
-Qiaobing

> 
> 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 exim@www1.ietf.org  Fri Oct 31 14:09:57 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13942
	for <avt-archive@odin.ietf.org>; Fri, 31 Oct 2003 14:09:57 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AFeeR-0005Dy-TT
	for avt-archive@odin.ietf.org; Fri, 31 Oct 2003 14:09:40 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9VJ9deG020076
	for avt-archive@odin.ietf.org; Fri, 31 Oct 2003 14:09:39 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AFedo-000559-BM; Fri, 31 Oct 2003 14:09:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AFedW-000535-Mt
	for avt@optimus.ietf.org; Fri, 31 Oct 2003 14:08:42 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13866
	for <avt@ietf.org>; Fri, 31 Oct 2003 14:08:29 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AFedU-0005QF-00
	for avt@ietf.org; Fri, 31 Oct 2003 14:08:40 -0500
Received: from ip72.usw4.rb1.bel.nwlink.com ([209.20.232.72] helo=bels002.mediator.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AFedT-0005Pw-00
	for avt@ietf.org; Fri, 31 Oct 2003 14:08:39 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 31 Oct 2003 11:08:08 -0800
Message-ID: <787ED0EC136B854DB341E7662D666CD6540E86@bels002.mediator.com>
Thread-Topic: Comments on draft-tseng-rtcp-streaming-extns-00.txt
Thread-Index: AcOeOCAZztdgQZ7JSbyWZW3X3Dc/xwBpqOjA
From: "Gamze Seckin" <gamze@vidiator.com>
To: "Magnus Westerlund" <magnus.westerlund@ericsson.com>,
        "Alan Tseng" <alan@vidiator.com>
Cc: "IETF AVT WG" <avt@ietf.org>
Content-Transfer-Encoding: quoted-printable
Subject: [AVT] RE: Comments on draft-tseng-rtcp-streaming-extns-00.txt
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable


Hi Magnus,=20
thanks for the comments.
See my response inline.

best regards
gamze
-----Original Message-----
From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]
Sent: Wednesday, October 29, 2003 8:17 AM
To: Alan Tseng; Gamze Seckin
Cc: IETF AVT WG
Subject: Comments on draft-tseng-rtcp-streaming-extns-00.txt


Hi,

Here is my comments on your draft:

1. First I think the draft isn't very clear on why any metrics are=20
needed. In the 3GPP document it only states: "The objective of the=20
streaming service quality metrics is to offer to the service providers=20
means to evaluate the end user experience.". This doesn't make it very=20
clear what the real needs are. I think further developing of this is=20
needed.

[g]you are right, the draft does not talk about that clearly. We should =
add that.

2. Regarding the corruption statistics. For media that uses codec that=20
have prediction any error normally remains for a rather long time.=20
However it is very difficult to determine when the effects has been=20
removed. Therefore this measurement is hard to derive on the receiver=20
side. Combined with the definition it only provides a good, possibly bad =

indication. Also looking at the reasons for corruption, the only real=20
reason is lost or late packets. A good feeling for the quality can be=20
determined by the server simply by employing packet loss vector=20
reporting and knowing when the buffer is empty.

[g]packet loss is definitely a way of estimating corruption, but this =
gives an algorithm in the decoder (or pre-decoder)a chance to provide =
better statistics.

3. The rebuffering measurements makes more sense. However there are at=20
least one client that does not really perform rebuffering, namely=20
quicktime. Instead is assumes that if the transmitted bit-rate is=20
acceptable any short term effects will go away and the client will later =

  have a buffer fullness given by the initial buffering delay. The=20
interesting thing about this measurement is that in 3GPP they already=20
have a way of letting the server measure when rebuffering takes place,=20
namely the OBSN reporting specified in TS 26.234 REL 6 (only preliminary =

versions available).

[g] yes, and I believe those statistics are useful, however they are =
tight with rate adaptation (only turned on when rate-adaptation is =
enabled) and tightly coupled with other rtsp messages.

4. As state privately before this drafts need to be checked against the=20
ID nits: http://www.ietf.org/ID-nits.html

[g] yes, we should definitely do that thanks.

5. Section 1. The introduction is basically the same as the=20
introduction. I would recommend you to write a better more informative=20
introduction.

[g] agreed.

6. Section 1. Last sentence: "As all the other report blocks
defined in [1], the streaming report blocks are applicable to
one-to-one or one-to-many applications that generate
RTCP SR or RR reports." This sentence is not really correct. The use of=20
the RTCP XR reports is possible in any application sending RTCP.

[g] himm,i am confused i thought that the first sentence covers =
everything - what is left out?=20
So [1] needs to be updated too?

7. Section 2, You talk about AVP, but this extension is not dependent on =

any special profile and seems to be compatible with any of the four=20
available or under development profiles that exist.

[g] agreed.

8. Section 2, Figure 1. This figure shows this report formats potential=20
need to have reporting from all layers on the receiving side. This might =

be a problem for certain application architectures. I am not saying that =

it can't be used, its only that some applications may have difficulties=20
to include your reports.

[g] we believe the statistics reported should be extensible also should =
be allowed to be ignored.=20
So if an end side cannot support it should put simply a zero - what do =
you think?

9. Section 3.1, first paragraph: "All timestamps reported by the XR=20
packet SHALL be RTP timestamps. All durations SHALL be in units of the=20
RTP timebase." This definition is not clear, because in applications=20
allowing for switching between payload types the rate can change. I=20
think that the intention of using the RTP timestamp value for indication =

over what interval which the report covers is a good one. However some=20
more consideration over formulation must be done.

[g] valid point - I guess we need to think more about the corner cases.

10. Section 3.3, PAge 5, first bullet after figure 2:
"- at the AVP module: Packet drop and packet errors can sometimes be
detected by incorrect or missing sequence number or checksum. " Do you=20
really need to consider bit-errors, the only allowed possibility for=20
bit-errors in RTP is if partial checksums are used. Bit-errors surviving =

to the transport layer is the meaning to be caught by the UDP, etc.,=20
checksum.

[g] there could be cases where bit errors are propagated (e.g. udp =
lite).

11. Section 6. The streaming metrics should probably have a value to=20
combine with the parameter to indicate how often the report block should =

be included. This seem to be a block that is not needed very often.

[g] valid point, note taken.

12. Section 8. The security section does not look sufficient. I guess=20
that the consideration for this is rather similar to the VoIP block.=20
However I think there should be made some effort to indicate the main=20
security concerns also in this document.

[g] agreed.

13. Section 12. The references need to be divided into Normative and=20
Informative ones.

[g] agreed.

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 exim@www1.ietf.org  Fri Oct 31 16:01:58 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20185
	for <avt-archive@odin.ietf.org>; Fri, 31 Oct 2003 16:01:58 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AFgOq-0006yW-Rq
	for avt-archive@odin.ietf.org; Fri, 31 Oct 2003 16:01:40 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9VL1eDT026768
	for avt-archive@odin.ietf.org; Fri, 31 Oct 2003 16:01:40 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AFgOC-0006rT-W5; Fri, 31 Oct 2003 16:01:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AFgNk-0006pt-PH
	for avt@optimus.ietf.org; Fri, 31 Oct 2003 16:00:32 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20140
	for <avt@ietf.org>; Fri, 31 Oct 2003 16:00:20 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AFgNj-0007Gf-00
	for avt@ietf.org; Fri, 31 Oct 2003 16:00:31 -0500
Received: from rrcs-midsouth-24-199-215-41.biz.rr.com
	([24.199.215.41] helo=paris.packetizer.org ident=system)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AFgNi-0007Gc-00
	for avt@ietf.org; Fri, 31 Oct 2003 16:00:30 -0500
Received: from berlin (berlin.packetizer.org [192.168.1.4])
	by paris.packetizer.org (8.12.5/8.12.5) with SMTP id h9VL0UBQ006088
	for <avt@ietf.org>; Fri, 31 Oct 2003 16:00:30 -0500
Message-ID: <00cd01c39ff2$04b63d60$0401a8c0@berlin>
From: "Paul E. Jones" <paulej@packetizer.com>
To: <avt@ietf.org>
Date: Fri, 31 Oct 2003 16:00:30 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Content-Transfer-Encoding: 7bit
Subject: [AVT] Moving draft-jones-avt-audio-t38-01.txt forward
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Folks,

I would like to seek agreement from the AVT group to move the document
audio/t38 document forward.  As I have mentioned previously, the ITU would
like to incorporate this in T.38 in an amendment to be approved in January
2004.

The motivation for transporting T.38 via RTP is probably obvious to most.
In fact, I recall several saying that that is the way it should have been
done from the outset.  Most certainly, this will prove to be a good step in
leveraging SRTP for fax to address security needs.

The document is relatively short, just seeking the MIME registration.  The
technical details will be specified in the ITU-T Recommendation T.38.

Can I get agreement to make this an official working group item?  Can we try
to get this approved by the January 2004 ITU-T SG16 meeting?

Thanks,
Paul


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



From exim@www1.ietf.org  Fri Oct 31 16:26:57 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20913
	for <avt-archive@odin.ietf.org>; Fri, 31 Oct 2003 16:26:57 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AFgn1-0000ds-ES
	for avt-archive@odin.ietf.org; Fri, 31 Oct 2003 16:26:39 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9VLQdtr002424
	for avt-archive@odin.ietf.org; Fri, 31 Oct 2003 16:26:39 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AFgmP-0000Wv-AY; Fri, 31 Oct 2003 16:26:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AFgll-0000Sb-GZ
	for avt@optimus.ietf.org; Fri, 31 Oct 2003 16:25:21 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20866
	for <avt@ietf.org>; Fri, 31 Oct 2003 16:25:08 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AFglj-0007WW-00
	for avt@ietf.org; Fri, 31 Oct 2003 16:25:19 -0500
Received: from rrcs-midsouth-24-199-215-41.biz.rr.com
	([24.199.215.41] helo=paris.packetizer.org ident=system)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AFglj-0007WN-00
	for avt@ietf.org; Fri, 31 Oct 2003 16:25:19 -0500
Received: from berlin (berlin.packetizer.org [192.168.1.4])
	by paris.packetizer.org (8.12.5/8.12.5) with SMTP id h9VLPIBQ006242;
	Fri, 31 Oct 2003 16:25:18 -0500
Message-ID: <00eb01c39ff5$7c25c5c0$0401a8c0@berlin>
From: "Paul E. Jones" <paulej@packetizer.com>
To: <avt@ietf.org>
Cc: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= <gunnar.hellstrom@omnitor.se>
Date: Fri, 31 Oct 2003 16:25:19 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Content-Transfer-Encoding: 7bit
Subject: [AVT] Moving draft-hellstrom-avt-rfc2793bis-02.txt forward
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

AVT,

As you know, the ITU-T is working to produce a new Recommendation dubbed
V.ToIP, which they hope to approve in January 2004.  As part of that effort,
revisions have been made to RFC 2793.  The current draft has captured (as
far as I know) all of the comments, except one: there is a request to move
the text/red MIME registration out of this draft and into a separate
document.  We do want to do that, but we just didn't have time before the
IETF meeting document submission deadline.  However, we'll tackle that in
the coming weeks.

What I'd like to do now is seek approval from the group to make this
document an active work AVT work item.  The document does not differ
substantially from the previously published RFC 2793, though it offer a
means of interleaving audio and text over a single RTP session.  This is
there primarily to allow to PSTN gateways to transmit text and audio
received on a DS0 across an IP network for reproduction back onto the PSTN
on the other side.  The previous text required the use of a separate RTP
session for text, as the text and audio were truly sourced independently.

At any rate, I think Mr. Hellstrom might be attending the IETF meeting,
though I will not be able to attend.  Regardless, I'd like to see this work
move forward with a goal of approving this before the January meeting of
ITU-T SG16.  I'm not so positive that the ITU will actually be able to close
on the V.ToIP work by January and I'll have a much better feeling about this
after the next interim meeting in December.  I can report the results of
that meeting to the group, if desired, as it will impact the urgency of this
work.

For now, I'd like it to be treated with some urgency.  At the very least,
let's make this a working group item and perhaps have some discussion at the
next meeting.

Thanks!
Paul


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