From avt-bounces@ietf.org Sun Apr 01 05:05:46 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HXvyi-0003A3-QE; Sun, 01 Apr 2007 05:04:00 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HXvw3-00016c-AM
	for avt@ietf.org; Sun, 01 Apr 2007 05:01:15 -0400
Received: from [211.189.53.2] (helo=kor1corpmail01.mediator.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXvjX-0003iq-C9
	for avt@ietf.org; Sun, 01 Apr 2007 04:48:21 -0400
MIME-Version: 1.0
Subject: RE: [AVT] Video streaming withour RTCP
Date: Sun, 1 Apr 2007 17:48:09 +0900
Message-ID: <FE6A9D3F2979884280CE0F5F5185517B1921FB@kor1corpmail01.mediator.com>
References: <E1HXGtE-0000EZ-R7@megatron.ietf.org>
	<006301c772dd$b6ab7fa0$0fa2ee0a@viola>
From: "Jaehwan Kim" <jaehwan@vidiator.com>
To: "Y. Matsui" <matsui.yoshinori@jp.panasonic.com>,
	<annasagaram.vamsi@aftek.com>, <avt@ietf.org>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2
Cc: 
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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-Type: multipart/mixed; boundary="===============0180081853=="
Errors-To: avt-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0180081853==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C7743A.790A137D"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C7743A.790A137D
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: quoted-printable

Hi,
Yes. However, I found many players and servers couldn't handle some =
strings like "client_port=3D3122;server=3D12100".
Therefore, your application is good to have RTP/RTCP port pairs in the =
SETUP process. If so, supporting both RTP/RTCP seems not much difficult. =

=20
As for sync, you can use RTP-Info and Range in RTSP. If it is live, =
although it is depends on the implementation of the peer, I receommend =
you support RTCP as well.
=20
Regards,
Jaehwan

________________________________

From: Y. Matsui [mailto:matsui.yoshinori@jp.panasonic.com]
Sent: 2007-03-31 (=C5=E4) =BF=C0=C0=FC 12:11
To: annasagaram.vamsi@aftek.com; avt@ietf.org
Subject: Re: [AVT] Video streaming withour RTCP



Hi,

RTSP is also available to synchronize audio and video in
streaming application, and it will be useful for control them
(play, pause, stop, etc.).

Best regards,

Yoshinori Matsui
Panasonic/Matsushita


----- Original Message -----
From: <annasagaram.vamsi@aftek.com>
Sent: Friday, March 30, 2007 10:11 PM
Subject: [AVT] Video streaming withour RTCP

> Hi,
>=20
>     Can video(with audio) streaming is possible with out RTCP?  RTCP
> packets are used for lip sync. I suppose!!  If it is so, then with out =
RTCP
> how can we achieve audio & video that is lip sync.??
>
> Thanks & Regards,
> Vamsi

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



------_=_NextPart_001_01C7743A.790A137D
Content-Type: text/html;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: quoted-printable

<HTML dir=3Dltr><HEAD><TITLE>Re: [AVT] Video streaming withour =
RTCP</TITLE>=0A=
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dunicode">=0A=
<META content=3D"MSHTML 6.00.2900.2180" name=3DGENERATOR></HEAD>=0A=
<BODY>=0A=
<DIV id=3DidOWAReplyText84253 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3D=B1=BC=B8=B2 color=3D#000000 =
size=3D2>Hi,</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3D=B1=BC=B8=B2 size=3D2>Yes. However, I found =
many players and servers&nbsp;couldn't handle&nbsp;some strings like =
"client_port=3D3122;server=3D12100".</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3D=B1=BC=B8=B2 =
size=3D2>Therefore,&nbsp;your&nbsp;application&nbsp;is good to have =
RTP/RTCP port pairs in the SETUP process. If&nbsp;so,&nbsp;supporting =
both RTP/RTCP seems not&nbsp;much difficult.&nbsp;</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3D=B1=BC=B8=B2 size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3D=B1=BC=B8=B2 size=3D2>As for sync, you can =
use RTP-Info and Range in RTSP. If it is live, although it is depends on =
the implementation of the peer, I receommend you&nbsp;support RTCP as =
well.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3D=B1=BC=B8=B2 size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3D=B1=BC=B8=B2 size=3D2>Regards,</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3D=B1=BC=B8=B2 =
size=3D2>Jaehwan</FONT></DIV></DIV>=0A=
<DIV dir=3Dltr><BR>=0A=
<HR tabIndex=3D-1>=0A=
<FONT face=3D=B1=BC=B8=B2 size=3D2><B>From:</B> Y. Matsui =
[mailto:matsui.yoshinori@jp.panasonic.com]<BR><B>Sent:</B> 2007-03-31 =
(=C5=E4) =BF=C0=C0=FC 12:11<BR><B>To:</B> annasagaram.vamsi@aftek.com; =
avt@ietf.org<BR><B>Subject:</B> Re: [AVT] Video streaming withour =
RTCP<BR></FONT><BR></DIV>=0A=
<DIV>=0A=
<P><FONT size=3D2>Hi,<BR><BR>RTSP is also available to synchronize audio =
and video in<BR>streaming application, and it will be useful for control =
them<BR>(play, pause, stop, etc.).<BR><BR>Best regards,<BR><BR>Yoshinori =
Matsui<BR>Panasonic/Matsushita<BR><BR><BR>----- Original Message =
-----<BR>From: &lt;annasagaram.vamsi@aftek.com&gt;<BR>Sent: Friday, =
March 30, 2007 10:11 PM<BR>Subject: [AVT] Video streaming withour =
RTCP<BR><BR>&gt; Hi,<BR>&gt;&nbsp;<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Can =
video(with audio) streaming is possible with out RTCP?&nbsp; =
RTCP<BR>&gt; packets are used for lip sync. I suppose!!&nbsp; If it is =
so, then with out RTCP<BR>&gt; how can we achieve audio &amp; video that =
is lip sync.??<BR>&gt;<BR>&gt; Thanks &amp; Regards,<BR>&gt; =
Vamsi<BR><BR>_______________________________________________<BR>Audio/Vid=
eo Transport Working Group<BR>avt@ietf.org<BR><A =
href=3D"https://www1.ietf.org/mailman/listinfo/avt">https://www1.ietf.org=
/mailman/listinfo/avt</A><BR></FONT></P></DIV></BODY></HTML>
------_=_NextPart_001_01C7743A.790A137D--


--===============0180081853==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0180081853==--




From avt-bounces@ietf.org Sun Apr 01 06:00:53 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HXwqi-0006rV-Ei; Sun, 01 Apr 2007 05:59:48 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HXwqh-0006qu-2m
	for avt@ietf.org; Sun, 01 Apr 2007 05:59:47 -0400
Received: from [67.15.60.3] (helo=mail.aftek.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXwqe-0004lu-4P
	for avt@ietf.org; Sun, 01 Apr 2007 05:59:47 -0400
Received: (qmail 10067 invoked by uid 510); 1 Apr 2007 05:13:53 -0500
Received: from 59.95.41.72 by plain.ev1servers.net (envelope-from
	<annasagaram.vamsi@aftek.com>,
	uid 508) with qmail-scanner-1.24-st-qms 
	(clamdscan: 0.75.1. perlscan: 1.25-st-qms.  
	Clear:RC:0(59.95.41.72):SA:0(-101.0/1.7):. 
	Processed in 2.341145 secs); 01 Apr 2007 10:13:53 -0000
X-Spam-Status: No, hits=-101.0 required=1.7
X-Antivirus-MYDOMAIN-Mail-From: annasagaram.vamsi@aftek.com via
	plain.ev1servers.net
X-Antivirus-MYDOMAIN: 1.24-st-qms (Clear:RC:0(59.95.41.72):SA:0(-101.0/1.7):.
	Processed in 2.341145 secs Process 10044)
Received: from unknown (HELO annasagaramv)
	(annasagaram.vamsi@aftek.com@59.95.41.72)
	by mail.aftek.com with SMTP; 1 Apr 2007 05:13:51 -0500
From: <annasagaram.vamsi@aftek.com>
To: "'Jaehwan Kim'" <jaehwan@vidiator.com>,
	"'Y. Matsui'" <matsui.yoshinori@jp.panasonic.com>, <avt@ietf.org>
Subject: RE: [AVT] Video streaming withour RTCP
Date: Sun, 1 Apr 2007 15:29:18 +0530
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Thread-Index: Acd0PImsAKjd8CY0Th+JwYSr0/efRAABu/Mg
In-Reply-To: <FE6A9D3F2979884280CE0F5F5185517B1921FB@kor1corpmail01.mediator.com>
X-Antivirus-MYDOMAIN-Message-ID: <1175422431105510044@plain.ev1servers.net>
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 9a9ddb14fac983e71b59f23b52a45b4e
Cc: 
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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-Type: multipart/mixed; boundary="===============1935716131=="
Errors-To: avt-bounces@ietf.org
Message-Id: <E1HXwqi-0006rV-Ei@megatron.ietf.org>

This is a multi-part message in MIME format.

--===============1935716131==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_000C_01C77472.8AA2D750"

This is a multi-part message in MIME format.

------=_NextPart_000_000C_01C77472.8AA2D750
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hi,=20

    Thanks for all these replies and suggestions.  I have developed RTP =
and RTCP but, due to some technical reasons I commented RTCP code as =
previously my application demanded only AUDIO.  And now I am about to =
implement even VIDEO.  For this I suppose it=E2=80=99s better to =
implement RTCP rather than going for other synchronization methods?? Can =
any one comment on this?  As per my understanding its better to use RTCP =
with RTP for synchronization of video and audio packets!!

=20

Thanks & regards,=20

Vamsi=20

=20

  _____ =20

From: Jaehwan Kim [mailto:jaehwan@vidiator.com]=20
Sent: Sunday, April 01, 2007 2:18 PM
To: Y. Matsui; annasagaram.vamsi@aftek.com; avt@ietf.org
Subject: RE: [AVT] Video streaming withour RTCP

=20

Hi,

Yes. However, I found many players and servers couldn't handle some =
strings like "client_port=3D3122;server=3D12100".

Therefore, your application is good to have RTP/RTCP port pairs in the =
SETUP process. If so, supporting both RTP/RTCP seems not much difficult. =


=20

As for sync, you can use RTP-Info and Range in RTSP. If it is live, =
although it is depends on the implementation of the peer, I receommend =
you support RTCP as well.

=20

Regards,

Jaehwan

=20

  _____ =20

From: Y. Matsui [mailto:matsui.yoshinori@jp.panasonic.com]
Sent: 2007-03-31 (=ED=86=A0) =EC=98=A4=EC=A0=84 12:11
To: annasagaram.vamsi@aftek.com; avt@ietf.org
Subject: Re: [AVT] Video streaming withour RTCP

Hi,

RTSP is also available to synchronize audio and video in
streaming application, and it will be useful for control them
(play, pause, stop, etc.).

Best regards,

Yoshinori Matsui
Panasonic/Matsushita


----- Original Message -----
From: <annasagaram.vamsi@aftek.com>
Sent: Friday, March 30, 2007 10:11 PM
Subject: [AVT] Video streaming withour RTCP

> Hi,
>=20
>     Can video(with audio) streaming is possible with out RTCP?  RTCP
> packets are used for lip sync. I suppose!!  If it is so, then with out =
RTCP
> how can we achieve audio & video that is lip sync.??
>
> Thanks & Regards,
> Vamsi

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


------=_NextPart_000_000C_01C77472.8AA2D750
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<title>Re: [AVT] Video streaming withour RTCP</title>
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Gulim;
	panose-1:2 11 6 0 0 1 1 1 1 1;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@Gulim";
	panose-1:0 0 0 0 0 0 0 0 0 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:Gulim;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:Gulim;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dblue>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Hi, <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>=C2=A0=C2=A0=C2=A0 Thanks for all =
these replies and
suggestions.=C2=A0 I have developed RTP and RTCP but, due to some =
technical reasons
I commented RTCP code as previously my application demanded only =
AUDIO.=C2=A0 And
now I am about to implement even VIDEO.=C2=A0 For this I suppose =
it=E2=80=99s better to
implement RTCP rather than going for other synchronization methods?? Can =
any
one comment on this?=C2=A0 As per my understanding its better to use =
RTCP with RTP
for synchronization of video and audio =
packets!!<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Thanks &amp; regards, =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Vamsi <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3DGulim><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> =
Jaehwan Kim
[mailto:jaehwan@vidiator.com] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Sunday, April 01, =
2007 2:18
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Y. Matsui;
annasagaram.vamsi@aftek.com; avt@ietf.org<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: [AVT] Video =
streaming
withour RTCP</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3DGulim><span =
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div id=3DidOWAReplyText84253>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3DGulim><span =
style=3D'font-size:
10.0pt;color:black'>Hi,</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DGulim><span =
style=3D'font-size:10.0pt'>Yes.
However, I found many players and servers</span></font><font size=3D2
face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt;font-family:"Times New =
Roman"'>&nbsp;</span></font><font
size=3D2><span style=3D'font-size:10.0pt'>couldn't =
handle</span></font><font
size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt;font-family:"Times New =
Roman"'>&nbsp;</span></font><font
size=3D2><span style=3D'font-size:10.0pt'>some strings like
&quot;client_port=3D3122;server=3D12100&quot;.</span></font><o:p></o:p></=
p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DGulim><span =
style=3D'font-size:10.0pt'>Therefore,</span></font><font
size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt;font-family:"Times New =
Roman"'>&nbsp;</span></font><font
size=3D2><span style=3D'font-size:10.0pt'>your</span></font><font =
size=3D2
face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt;font-family:"Times New =
Roman"'>&nbsp;</span></font><font
size=3D2><span style=3D'font-size:10.0pt'>application</span></font><font =
size=3D2
face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt;font-family:"Times New =
Roman"'>&nbsp;</span></font><font
size=3D2><span style=3D'font-size:10.0pt'>is good to have RTP/RTCP port =
pairs in
the SETUP process. If</span></font><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt;font-family:"Times New =
Roman"'>&nbsp;</span></font><font
size=3D2><span style=3D'font-size:10.0pt'>so,</span></font><font =
size=3D2
face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt;font-family:"Times New =
Roman"'>&nbsp;</span></font><font
size=3D2><span style=3D'font-size:10.0pt'>supporting both RTP/RTCP seems =
not</span></font><font
size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt;font-family:"Times New =
Roman"'>&nbsp;</span></font><font
size=3D2><span style=3D'font-size:10.0pt'>much =
difficult.</span></font><font
size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt;font-family:"Times New =
Roman"'>&nbsp;</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt;font-family:"Times New =
Roman"'>&nbsp;</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DGulim><span =
style=3D'font-size:10.0pt'>As
for sync, you can use RTP-Info and Range in RTSP. If it is live, =
although it is
depends on the implementation of the peer, I receommend =
you</span></font><font
size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt;font-family:"Times New =
Roman"'>&nbsp;</span></font><font
size=3D2><span style=3D'font-size:10.0pt'>support RTCP as =
well.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt;font-family:"Times New =
Roman"'>&nbsp;</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DGulim><span =
style=3D'font-size:10.0pt'>Regards,</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DGulim><span =
style=3D'font-size:10.0pt'>Jaehwan</span></font><o:p></o:p></p>

</div>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3DGulim><span =
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3DGulim><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1>

</span></font></div>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><b><font size=3D2 =
face=3DGulim><span
style=3D'font-size:10.0pt;font-weight:bold'>From:</span></font></b><font =
size=3D2><span
style=3D'font-size:10.0pt'> Y. Matsui =
[mailto:matsui.yoshinori@jp.panasonic.com]<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> 2007-03-31 (<span =
lang=3DKO>=ED=86=A0</span>)
<span lang=3DKO>=EC=98=A4=EC=A0=84</span> 12:11<br>
<b><span style=3D'font-weight:bold'>To:</span></b> =
annasagaram.vamsi@aftek.com;
avt@ietf.org<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Re: [AVT] Video =
streaming
withour RTCP</span></font><o:p></o:p></p>

</div>

<div>

<p><font size=3D2 face=3DGulim><span style=3D'font-size:10.0pt'>Hi,<br>
<br>
RTSP is also available to synchronize audio and video in<br>
streaming application, and it will be useful for control them<br>
(play, pause, stop, etc.).<br>
<br>
Best regards,<br>
<br>
Yoshinori Matsui<br>
Panasonic/Matsushita<br>
<br>
<br>
----- Original Message -----<br>
From: &lt;annasagaram.vamsi@aftek.com&gt;<br>
Sent: Friday, March 30, 2007 10:11 PM<br>
Subject: [AVT] Video streaming withour RTCP<br>
<br>
&gt; Hi,<br>
&gt;</span></font><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:
10.0pt;font-family:"Times New Roman"'>&nbsp;</span></font><font =
size=3D2><span
style=3D'font-size:10.0pt'><br>
&gt;</span></font><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:
10.0pt;font-family:"Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;</span></font><font
size=3D2><span style=3D'font-size:10.0pt'> Can video(with audio) =
streaming is
possible with out RTCP?</span></font><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt;font-family:"Times New =
Roman"'>&nbsp;</span></font><font
size=3D2><span style=3D'font-size:10.0pt'> RTCP<br>
&gt; packets are used for lip sync. I suppose!!</span></font><font =
size=3D2
face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt;font-family:"Times New =
Roman"'>&nbsp;</span></font><font
size=3D2><span style=3D'font-size:10.0pt'> If it is so, then with out =
RTCP<br>
&gt; how can we achieve audio &amp; video that is lip sync.??<br>
&gt;<br>
&gt; Thanks &amp; Regards,<br>
&gt; Vamsi<br>
<br>
_______________________________________________<br>
Audio/Video Transport Working Group<br>
avt@ietf.org<br>
<a =
href=3D"https://www1.ietf.org/mailman/listinfo/avt">https://www1.ietf.org=
/mailman/listinfo/avt</a></span></font><o:p></o:p></p>

</div>

</div>

</body>

</html>

------=_NextPart_000_000C_01C77472.8AA2D750--




--===============1935716131==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1935716131==--






From avt-bounces@ietf.org Sun Apr 01 08:30:33 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HXzBQ-0005Ky-Lw; Sun, 01 Apr 2007 08:29:20 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HXzBO-0005IB-Ov
	for avt@ietf.org; Sun, 01 Apr 2007 08:29:18 -0400
Received: from mr1.dcs.gla.ac.uk ([130.209.249.184])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXzBN-0003Ie-Fl
	for avt@ietf.org; Sun, 01 Apr 2007 08:29:18 -0400
Received: from csperkins-dsl.demon.co.uk ([62.49.4.249]:61471
	helo=[192.168.0.4])
	by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42)
	id 1HXzBM-0007nx-KL; Sun, 01 Apr 2007 13:29:16 +0100
In-Reply-To: <460CE89F.7060000@vil.ite.mee.com>
References: <46094749.1030806@vil.ite.mee.com>
	<ybuejnatwsk.fsf@jesup.eng.wgate.com>
	<1C1F3D15859526459B4DD0A7A9B2268B03488F9D@trebe101.NOE.Nokia.com>
	<460A45A5.4090908@vil.ite.mee.com>
	<1C1F3D15859526459B4DD0A7A9B2268B034B42FB@trebe101.NOE.Nokia.com>
	<460CE89F.7060000@vil.ite.mee.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <C37FC6DB-FAB7-4FF0-8FDA-C47113607E43@csperkins.org>
Content-Transfer-Encoding: 7bit
From: Colin Perkins <csp@csperkins.org>
Subject: Re: [AVT] AVC NALUs RTP packetisation
Date: Sun, 1 Apr 2007 13:29:13 +0100
To: Nikola Sprljan <nikola.sprljan@vil.ite.mee.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Cc: Ye-Kui.Wang@nokia.com, avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

On 30 Mar 2007, at 11:38, Nikola Sprljan wrote:
...
> I guess what I'd like to ask this time is - is SSRC multiplexing gone
> for good, or there's still a chance it could be reconsidered?

I hope it's gone for good, since it gave the (false) impression that  
one could reliably adapt RTP streams without being in the signalling/ 
security context, and without buffering packets.

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



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



From avt-bounces@ietf.org Sun Apr 01 10:55:36 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HY1Ra-0008As-9J; Sun, 01 Apr 2007 10:54:10 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HY1RY-0008Ak-0w
	for avt@ietf.org; Sun, 01 Apr 2007 10:54:08 -0400
Received: from ns.live555.com ([4.79.217.242])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HY1RV-0006GR-L8
	for avt@ietf.org; Sun, 01 Apr 2007 10:54:08 -0400
Received: from ns.live555.com (localhost.live555.com [127.0.0.1])
	by ns.live555.com (8.13.8/8.13.8) with ESMTP id l31EsQxK040458;
	Sun, 1 Apr 2007 07:54:26 -0700 (PDT)
	(envelope-from rsf@ns.live555.com)
Received: (from rsf@localhost)
	by ns.live555.com (8.13.8/8.13.8/Submit) id l31EsOit040425;
	Sun, 1 Apr 2007 07:54:24 -0700 (PDT) (envelope-from rsf)
Mime-Version: 1.0
Message-Id: <f06240802c2357566a067@[66.80.62.44]>
In-Reply-To: <FE6A9D3F2979884280CE0F5F5185517B1921FB@kor1corpmail01.mediator.com>
References: <E1HXGtE-0000EZ-R7@megatron.ietf.org>
	<006301c772dd$b6ab7fa0$0fa2ee0a@viola>
	<FE6A9D3F2979884280CE0F5F5185517B1921FB@kor1corpmail01.mediator.com>
Date: Sun, 1 Apr 2007 07:53:40 -0700
To: "Jaehwan Kim" <jaehwan@vidiator.com>
From: Ross Finlayson <finlayson@live555.com>
Subject: RE: [AVT] Video streaming withour RTCP
X-Spam-Score: 0.1 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Cc: "Y. Matsui" <matsui.yoshinori@jp.panasonic.com>, avt@ietf.org,
	annasagaram.vamsi@aftek.com
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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-Type: multipart/mixed; boundary="===============1944282480=="
Errors-To: avt-bounces@ietf.org

--===============1944282480==
Content-Type: multipart/alternative;
	boundary="============_-1036683268==_ma============"

--============_-1036683268==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

>As for sync, you can use RTP-Info and Range in RTSP.

No, this is appears to be a common misconception.  Although - when 
used in combination with the first RTCP "SR" report - the "RTP-Info" 
and "Range" headers can be used to generate an offset between 
presentation time and "NPT" (Normal Play Time), the "RTP-Info" and 
"Range" headers *alone* do not guarantee that you can get times (for 
audio and video) that remain synchronized *forever*.  For that, you 
need synchronized presentation times provided by RTCP.
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
--============_-1036683268==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>RE: [AVT] Video streaming withour
RTCP</title></head><body>
<blockquote type="cite" cite><font size="-1">As for sync, you can use
RTP-Info and Range in RTSP.</font></blockquote>
<div><br></div>
<div>No, this is appears to be a common misconception.&nbsp; Although
- when used in combination with the first RTCP &quot;SR&quot; report -
the &quot;RTP-Info&quot; and &quot;Range&quot; headers can be used to
generate an offset between presentation time and &quot;NPT&quot;
(Normal Play Time), the &quot;RTP-Info&quot; and &quot;Range&quot;
headers *alone* do not guarantee that you can get times (for audio and
video) that remain synchronized *forever*.&nbsp; For that, you need
synchronized presentation times provided by RTCP.</div>
<x-sigsep><pre>-- 
</pre></x-sigsep>
<div><br>
Ross Finlayson<br>
Live Networks, Inc.<br>
http://www.live555.com/</div>
</body>
</html>
--============_-1036683268==_ma============--


--===============1944282480==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1944282480==--




From avt-bounces@ietf.org Sun Apr 01 18:06:35 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HY8AK-0007gy-AY; Sun, 01 Apr 2007 18:04:48 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HY8AJ-0007gl-6V
	for avt@ietf.org; Sun, 01 Apr 2007 18:04:47 -0400
Received: from [211.189.53.2] (helo=kor1corpmail01.mediator.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HY8AH-0002Nb-6x
	for avt@ietf.org; Sun, 01 Apr 2007 18:04:47 -0400
MIME-Version: 1.0
Subject: RE: [AVT] Video streaming withour RTCP
Date: Mon, 2 Apr 2007 07:04:32 +0900
Message-ID: <FE6A9D3F2979884280CE0F5F5185517B480200@kor1corpmail01.mediator.com>
In-Reply-To: <f06240802c2357566a067@[66.80.62.44]>
References: <E1HXGtE-0000EZ-R7@megatron.ietf.org>
	<006301c772dd$b6ab7fa0$0fa2ee0a@viola>
	<FE6A9D3F2979884280CE0F5F5185517B1921FB@kor1corpmail01.mediator.com>
	<f06240802c2357566a067@[66.80.62.44]>
From: "Jaehwan Kim" <jaehwan@vidiator.com>
To: "Ross Finlayson" <finlayson@live555.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 40161b1d86420e0807d771943d981d25
Cc: "Y. Matsui" <matsui.yoshinori@jp.panasonic.com>, avt@ietf.org,
	annasagaram.vamsi@aftek.com
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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-Type: multipart/mixed; boundary="===============0707877896=="
Errors-To: avt-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0707877896==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C774A9.BB725F96"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C774A9.BB725F96
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

And could you explain more in detail?

I would appreciate if you give us an example.

=20

If there is a common misconception happening again and again, IMO, the
notion with enough examples should be into RTSP specification.

=20

Jaehwan

=20

=20

________________________________

From: Ross Finlayson [mailto:finlayson@live555.com]=20
Sent: Sunday, April 01, 2007 11:54 PM
To: Jaehwan Kim
Cc: Y. Matsui; annasagaram.vamsi@aftek.com; avt@ietf.org
Subject: RE: [AVT] Video streaming withour RTCP

=20

	As for sync, you can use RTP-Info and Range in RTSP.

=20

No, this is appears to be a common misconception.  Although - when used
in combination with the first RTCP "SR" report - the "RTP-Info" and
"Range" headers can be used to generate an offset between presentation
time and "NPT" (Normal Play Time), the "RTP-Info" and "Range" headers
*alone* do not guarantee that you can get times (for audio and video)
that remain synchronized *forever*.  For that, you need synchronized
presentation times provided by RTCP.

--=20


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/


------_=_NextPart_001_01C774A9.BB725F96
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<title>RE: [AVT] Video streaming withour RTCP</title>
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Batang;
	panose-1:2 3 6 0 0 1 1 1 1 1;}
@font-face
	{font-family:Gulim;
	panose-1:2 11 6 0 0 1 1 1 1 1;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Gulim;
	panose-1:2 11 6 0 0 1 1 1 1 1;}
@font-face
	{font-family:Batang;
	panose-1:2 3 6 0 0 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
pre
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:Gulim;
	color:navy;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:99.25pt 3.0cm 3.0cm 3.0cm;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DKO link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy =
face=3D&#44404;&#47548;><span
lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Gulim;color:navy'>Hi,<o:p></o:p></s=
pan></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy =
face=3D&#44404;&#47548;><span
lang=3DEN-US style=3D'font-size:10.0pt;font-family:Gulim;color:navy'>And =
could you explain
more in detail?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy =
face=3D&#44404;&#47548;><span
lang=3DEN-US style=3D'font-size:10.0pt;font-family:Gulim;color:navy'>I =
would
appreciate if you give us an example.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy =
face=3D&#44404;&#47548;><span
lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Gulim;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy =
face=3D&#44404;&#47548;><span
lang=3DEN-US style=3D'font-size:10.0pt;font-family:Gulim;color:navy'>If =
there is a
common misconception happening again and again, IMO, the notion with =
enough
examples should be into RTSP specification.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy =
face=3D&#44404;&#47548;><span
lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Gulim;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy =
face=3D&#44404;&#47548;><span
lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Gulim;color:navy'>Jaehwan<o:p></o:p=
></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy =
face=3D&#44404;&#47548;><span
lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Gulim;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy =
face=3D&#44404;&#47548;><span
lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Gulim;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span lang=3DEN-US style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</spa=
n></font></b><font
size=3D2 face=3DTahoma><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Tahoma'>
Ross Finlayson [mailto:finlayson@live555.com] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Sunday, April 01, =
2007 11:54
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Jaehwan Kim<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Y. Matsui;
annasagaram.vamsi@aftek.com; avt@ietf.org<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: [AVT] Video =
streaming
withour RTCP</span></font><span lang=3DEN-US><o:p></o:p></span></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DEN-US
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt'>

<p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>As for sync, you can use RTP-Info and Range =
in RTSP.</span></font><span
lang=3DEN-US><o:p></o:p></span></p>

</blockquote>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DEN-US
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DEN-US
style=3D'font-size:12.0pt'>No, this is appears to be a common
misconception.&nbsp; Although - when used in combination with the first =
RTCP
&quot;SR&quot; report - the &quot;RTP-Info&quot; and &quot;Range&quot; =
headers
can be used to generate an offset between presentation time and =
&quot;NPT&quot;
(Normal Play Time), the &quot;RTP-Info&quot; and &quot;Range&quot; =
headers
*alone* do not guarantee that you can get times (for audio and video) =
that
remain synchronized *forever*.&nbsp; For that, you need synchronized =
presentation
times provided by RTCP.<o:p></o:p></span></font></p>

</div>

<pre><font size=3D2 face=3D"Courier New"><span lang=3DEN-US =
style=3D'font-size:10.0pt'><x-sigsep>-- <o:p></o:p></span></font></pre>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DEN-US
style=3D'font-size:12.0pt'><br>
</x-sigsep>Ross Finlayson<br>
Live Networks, Inc.<br>
http://www.live555.com/<o:p></o:p></span></font></p>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C774A9.BB725F96--


--===============0707877896==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0707877896==--




From avt-bounces@ietf.org Mon Apr 02 02:35:57 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYG6m-0004Eb-Dl; Mon, 02 Apr 2007 02:33:40 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYG6l-0004CB-9J
	for avt@ietf.org; Mon, 02 Apr 2007 02:33:39 -0400
Received: from mailgate2.ebu.ch ([193.43.93.72])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYG6j-0002XP-OO
	for avt@ietf.org; Mon, 02 Apr 2007 02:33:39 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 2 Apr 2007 08:33:03 +0200
Message-ID: <B6472FAD86FE9C4A8F1870BA8C8910EBB37B77@gnvasmail1a.gva.ebu.ch>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Parameters lost for media type MPA in new RFC4856 ?
Thread-Index: Acd08MRc94oe8vG1Smq3bOajhh91Lw==
From: "Coinchon, Mathias" <coinchon@ebu.ch>
To: <avt@ietf.org>
X-OriginalArrivalTime: 02 Apr 2007 06:33:04.0027 (UTC)
	FILETIME=[C4742EB0:01C774F0]
X-Spam-Score: 0.4 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Subject: [AVT] Parameters lost for media type MPA in new RFC4856 ?
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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-Type: multipart/mixed; boundary="===============0529999266=="
Errors-To: avt-bounces@ietf.org

This is a multi-part message in MIME format.


--===============0529999266==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C774F0.C45CDFE4"

This is a multi-part message in MIME format.


------_=_NextPart_001_01C774F0.C45CDFE4
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=0D=0ADear RFC editors,=0D=0A=0D=0AI have one question regarding the new RF=
C4855 and RFC4856 that obsolete=0D=0ARFC3555:=0D=0A=0D=0A- Where are parame=
ters for MPA (mpeg audio) specified ? They were in RFC3555=0D=0A(4=2E1=2E17=
) but not anymore in RFC4856=2E=0D=0A=0D=0AAs I have understood from RFC485=
5/4856, parameters should now be specified=0D=0Ain payload format RFCs=2E=
=0D=0AHowever looking in RFC2250 for MPEG payload format (video and audio) =
I don't=0D=0Asee a specification of these parameters=2E=0D=0ALooking on IAN=
A pages, media type MPA still point on RFC3555=2E=0D=0A=0D=0ACould you plea=
se tell me where to point now for MPEG audio parameters ?=0D=0A=0D=0AWill t=
here be modifications of RFC2250 for MPEG payload format specifying=0D=0Apa=
rameters ? (and modification of RFC3550/3551 to point to RFC3855/56=0D=0Ain=
stead of RFC3555 ?)=0D=0A=0D=0AThis is an important issue as we rely and po=
int to RFCs for the signalling=0D=0Aof parameters (using SDP) for a standar=
d on Audio contribution over IP (EBU=0D=0Agroup N/ACIP)=2E=0D=0A=0D=0AThank=
 you=0D=0A=0D=0ARegards,=0D=0A=0D=0AMathias Coinchon=0D=0ASenior Engineer=
=0D=0ATechnical Department=0D=0A=0D=0AEuropean Broadcasting Union=0D=0AL'An=
cienne-Route 17A=0D=0A1218 Grand-Saconnex=0D=0ASwitzerland=0D=0A=0D=0ATel +=
41 22 717 27 16=0D=0AFax +41 22 747 47 16=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A----=
-------------------------------------=0D=0A********************************=
******************=0D=0AThis email and any files transmitted with it =0D=0A=
are confidential and intended solely for the =0D=0Ause of the individual or=
 entity to whom they=0D=0Aare addressed=2E =0D=0AIf you have received this =
email in error, =0D=0Aplease notify the system manager=2E=0D=0AThis footnot=
e also confirms that this email =0D=0Amessage has been swept by the mailgat=
eway=0D=0A**************************************************
------_=_NextPart_001_01C774F0.C45CDFE4
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3=2E2//EN">=0D=0A<HTML>=0D=0A<HEAD>=
=0D=0A<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Dus-=
ascii">=0D=0A<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version=
 6=2E0=2E6603=2E0">=0D=0A<TITLE>Parameters lost for media type MPA in new R=
FC4856 ?</TITLE>=0D=0A</HEAD>=0D=0A<BODY>=0D=0A<!-- Converted from text/rtf=
 format -->=0D=0A<BR>=0D=0A=0D=0A<P><FONT SIZE=3D2 FACE=3D"Arial">Dear RFC =
editors,</FONT>=0D=0A</P>=0D=0A=0D=0A<P><FONT SIZE=3D2 FACE=3D"Arial">I hav=
e one question regarding the new RFC4855 and RFC4856 that obsolete RFC3555:=
</FONT>=0D=0A</P>=0D=0A=0D=0A<P><FONT SIZE=3D2 FACE=3D"Arial">- Where are p=
arameters for MPA (mpeg audio) specified ? They were in RFC3555 (4=2E1=2E17=
) but not anymore in RFC4856=2E</FONT>=0D=0A</P>=0D=0A=0D=0A<P><FONT SIZE=
=3D2 FACE=3D"Arial">As I have understood from RFC4855/4856, parameters shou=
ld now be specified in payload format RFCs=2E</FONT>=0D=0A=0D=0A<BR><FONT S=
IZE=3D2 FACE=3D"Arial">However looking in RFC2250 for MPEG payload format (=
video and audio) I don't see a specification of these parameters=2E</FONT>=
=0D=0A=0D=0A<BR><FONT SIZE=3D2 FACE=3D"Arial">Looking on IANA pages, media =
type MPA still point on RFC3555=2E</FONT>=0D=0A</P>=0D=0A=0D=0A<P><FONT SIZ=
E=3D2 FACE=3D"Arial">Could you please tell me where to point now for MPEG a=
udio parameters ?</FONT>=0D=0A</P>=0D=0A=0D=0A<P><FONT SIZE=3D2 FACE=3D"Ari=
al">Will there be modifications of RFC2250 for MPEG payload format specifyi=
ng parameters ? (and modification of RFC3550/3551 to point to RFC3855/56 in=
stead of RFC3555 ?)</FONT></P>=0D=0A=0D=0A<P><FONT SIZE=3D2 FACE=3D"Arial">=
This is an important issue as we rely and point to RFCs for the signalling =
of parameters (using SDP) for a standard on Audio contribution over IP (EBU=
 group N/ACIP)=2E</FONT></P>=0D=0A=0D=0A<P><FONT SIZE=3D2 FACE=3D"Arial">Th=
ank you</FONT>=0D=0A</P>=0D=0A=0D=0A<P><FONT SIZE=3D2 FACE=3D"Arial">Regard=
s,</FONT>=0D=0A</P>=0D=0A=0D=0A<P><FONT SIZE=3D2 FACE=3D"Arial">Mathias Coi=
nchon</FONT>=0D=0A=0D=0A<BR><FONT SIZE=3D2 FACE=3D"Arial">Senior Engineer</=
FONT>=0D=0A=0D=0A<BR><FONT SIZE=3D2 FACE=3D"Arial">Technical Department</FO=
NT>=0D=0A</P>=0D=0A=0D=0A<P><FONT SIZE=3D2 FACE=3D"Arial">European Broadcas=
ting Union</FONT>=0D=0A=0D=0A<BR><FONT SIZE=3D2 FACE=3D"Arial">L'Ancienne-R=
oute 17A</FONT>=0D=0A=0D=0A<BR><FONT SIZE=3D2 FACE=3D"Arial">1218 Grand-Sac=
onnex</FONT>=0D=0A=0D=0A<BR><FONT SIZE=3D2 FACE=3D"Arial">Switzerland</FONT=
>=0D=0A</P>=0D=0A=0D=0A<P><FONT SIZE=3D2 FACE=3D"Arial">Tel +41 22 717 27 1=
6</FONT>=0D=0A=0D=0A<BR><FONT SIZE=3D2 FACE=3D"Arial">Fax +41 22 747 47 16<=
/FONT>=0D=0A</P>=0D=0A<BR>=0D=0A=0D=0A</BODY>=0D=0A</HTML>=0D=0A<HTML><BODY=
><P><hr size=3D1></P>=0D=0A<P><STRONG>=0D=0A*******************************=
*******************=0D=0AThis email and any files transmitted with it =0D=
=0Aare confidential and intended solely for the =0D=0Ause of the individual=
 or entity to whom they=0D=0Aare addressed=2E =0D=0AIf you have received th=
is email in error, =0D=0Aplease notify the system manager=2E=0D=0AThis foot=
note also confirms that this email =0D=0Amessage has been swept by the mail=
gateway=0D=0A**************************************************=0D=0A</STRO=
NG></P></BODY></HTML>
------_=_NextPart_001_01C774F0.C45CDFE4--



--===============0529999266==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0529999266==--





From avt-bounces@ietf.org Mon Apr 02 03:06:51 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYGc5-0001bZ-9k; Mon, 02 Apr 2007 03:06:01 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYGc3-0001bR-Fo
	for avt@ietf.org; Mon, 02 Apr 2007 03:05:59 -0400
Received: from mailgw3.ericsson.se ([193.180.251.60])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYGbx-0001IF-Sr
	for avt@ietf.org; Mon, 02 Apr 2007 03:05:59 -0400
Received: from mailgw3.ericsson.se (unknown [127.0.0.1])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
	43705207E1; Mon,  2 Apr 2007 09:05:49 +0200 (CEST)
X-AuditID: c1b4fb3c-ac51ebb0000073d5-4b-4610ab4dfc17 
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
	20BBB2054F; Mon,  2 Apr 2007 09:05:49 +0200 (CEST)
Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by
	esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 2 Apr 2007 09:05:48 +0200
Received: from [147.214.30.247] ([147.214.30.247]) by
	esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 2 Apr 2007 09:05:48 +0200
Message-ID: <4610AB4C.1080807@ericsson.com>
Date: Mon, 02 Apr 2007 09:05:48 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Jaehwan Kim <jaehwan@vidiator.com>
Subject: Re: [AVT] Video streaming withour RTCP
References: <E1HXGtE-0000EZ-R7@megatron.ietf.org>	<006301c772dd$b6ab7fa0$0fa2ee0a@viola>	<FE6A9D3F2979884280CE0F5F5185517B1921FB@kor1corpmail01.mediator.com>	<f06240802c2357566a067@[66.80.62.44]>
	<FE6A9D3F2979884280CE0F5F5185517B480200@kor1corpmail01.mediator.com>
In-Reply-To: <FE6A9D3F2979884280CE0F5F5185517B480200@kor1corpmail01.mediator.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 02 Apr 2007 07:05:48.0403 (UTC)
	FILETIME=[57502C30:01C774F5]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Cc: annasagaram.vamsi@aftek.com, Ross Finlayson <finlayson@live555.com>,
	"Y. Matsui" <matsui.yoshinori@jp.panasonic.com>, avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

Jaehwan Kim skrev:
> 
> 
> Hi,
> 
> And could you explain more in detail?
> 
> I would appreciate if you give us an example.
> 
>  
> 
> If there is a common misconception happening again and again, IMO, the 
> notion with enough examples should be into RTSP specification.

Okay, we will log a request to clarify that RTP-Info only provides for 
initial sync and that RTCP is needed for maintaining sync in the case of 
clock drift. But there is much more on timestamp handling in 
http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-14
than what is in RFC 2326.

I could also recommend looking at the How To write RTP payload formats 
that has some discussion on the RTCP synch mechanism or Colin Perkins 
book on RTP.
http://tools.ietf.org/html/draft-ietf-avt-rtp-howto-01

There is also need to have RTCP for synch in cases such as multiple 
sources (SSRCs) and live sessions. In addition RTCP is needed for its 
transport monitoring purpose. The sender can't do any type of adaptation 
or avoid causing long term congestion unless RTCP is used.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

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



From avt-bounces@ietf.org Mon Apr 02 03:36:28 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYH4U-0005lP-2Z; Mon, 02 Apr 2007 03:35:22 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYH4S-0005lK-NJ
	for avt@ietf.org; Mon, 02 Apr 2007 03:35:20 -0400
Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYH4R-0000lU-9r
	for avt@ietf.org; Mon, 02 Apr 2007 03:35:20 -0400
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211])
	by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id
	l327ZBDf029630; Mon, 2 Apr 2007 10:35:16 +0300
Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by
	esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 2 Apr 2007 10:35:06 +0300
Received: from trebe101.NOE.Nokia.com ([172.22.124.61]) by
	esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 2 Apr 2007 10:35:06 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [AVT] AVC NALUs RTP packetisation
Date: Mon, 2 Apr 2007 10:35:05 +0300
Message-ID: <1C1F3D15859526459B4DD0A7A9B2268B034DD891@trebe101.NOE.Nokia.com>
In-Reply-To: <C37FC6DB-FAB7-4FF0-8FDA-C47113607E43@csperkins.org>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [AVT] AVC NALUs RTP packetisation
Thread-Index: Acd0WZbvdcCfYcjlTBCH5x+Nk0VlgQAnrcrA
References: <46094749.1030806@vil.ite.mee.com>
	<ybuejnatwsk.fsf@jesup.eng.wgate.com>
	<1C1F3D15859526459B4DD0A7A9B2268B03488F9D@trebe101.NOE.Nokia.com>
	<460A45A5.4090908@vil.ite.mee.com>
	<1C1F3D15859526459B4DD0A7A9B2268B034B42FB@trebe101.NOE.Nokia.com>
	<460CE89F.7060000@vil.ite.mee.com>
	<C37FC6DB-FAB7-4FF0-8FDA-C47113607E43@csperkins.org>
From: <Ye-Kui.Wang@nokia.com>
To: <csp@csperkins.org>, <nikola.sprljan@vil.ite.mee.com>
X-OriginalArrivalTime: 02 Apr 2007 07:35:06.0355 (UTC)
	FILETIME=[6F225C30:01C774F9]
X-eXpurgate-Category: 1/0
X-eXpurgate-ID: 149371::070402103516-6F4DBBB0-0CB8AF33/0-0/0-1
X-Nokia-AV: Clean
X-Spam-Score: 0.2 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Cc: avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

Confirmed that the SSRC multiplexing stuff has gone for good. The
original intention for that was to save number of fireware pinholes
and/or to enable stream adaptation when SRTP is in use. But it was later
found that there are no good use case.=20

BR, YK=20

>-----Original Message-----
>From: ext Colin Perkins [mailto:csp@csperkins.org]=20
>Sent: Sunday, April 01, 2007 3:29 PM
>To: Nikola Sprljan
>Cc: Wang Ye-Kui (Nokia-NRC/Tampere); avt@ietf.org
>Subject: Re: [AVT] AVC NALUs RTP packetisation
>
>On 30 Mar 2007, at 11:38, Nikola Sprljan wrote:
>...
>> I guess what I'd like to ask this time is - is SSRC=20
>multiplexing gone=20
>> for good, or there's still a chance it could be reconsidered?
>
>I hope it's gone for good, since it gave the (false)=20
>impression that one could reliably adapt RTP streams without=20
>being in the signalling/ security context, and without=20
>buffering packets.
>
>--
>Colin Perkins
>http://csperkins.org/
>
>
>

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



From avt-bounces@ietf.org Mon Apr 02 06:12:14 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYJVJ-0001pu-Q8; Mon, 02 Apr 2007 06:11:13 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYJVI-0001pm-Ax
	for avt@ietf.org; Mon, 02 Apr 2007 06:11:12 -0400
Received: from [211.189.53.2] (helo=kor1corpmail01.mediator.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYJVG-0004MJ-Ej
	for avt@ietf.org; Mon, 02 Apr 2007 06:11:12 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: [AVT] Why RTCP is needed for synch after long time in aggregated A/V
	RTSP session?
Date: Mon, 2 Apr 2007 19:10:57 +0900
Message-ID: <FE6A9D3F2979884280CE0F5F5185517B48023E@kor1corpmail01.mediator.com>
In-Reply-To: <4610AB4C.1080807@ericsson.com>
References: <E1HXGtE-0000EZ-R7@megatron.ietf.org>	<006301c772dd$b6ab7fa0$0fa2ee0a@viola>	<FE6A9D3F2979884280CE0F5F5185517B1921FB@kor1corpmail01.mediator.com>	<f06240802c2357566a067@[66.80.62.44]><FE6A9D3F2979884280CE0F5F5185517B480200@kor1corpmail01.mediator.com>
	<4610AB4C.1080807@ericsson.com>
From: "Jaehwan Kim" <jaehwan@vidiator.com>
To: "Magnus Westerlund" <magnus.westerlund@ericsson.com>,
	"Ross Finlayson" <finlayson@live555.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Cc: annasagaram.vamsi@aftek.com, avt@ietf.org,
	"Y. Matsui" <matsui.yoshinori@jp.panasonic.com>
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

Dear Magnus,
Yes, we need. And thanks to this group, people could learn many things
about RTP timestamp as described in the Appendix B of rfc2326bis. Now I
found most major players have been changed to follow it; it was not in
the past.

As for the subject, I would appreciate if we add more text about "why"
in future; I found one sentence from rfc2326bis-04 but failed to find
why.
(page92)

I felt that Ross knows some empirical knowledge. So, I asked him.
Ross, do you mind if you share your experience with us?=20

>From my 2 cents, if the given RTSP session is VOD, although the given
session is enough long, the additional work, checking RTCP would not be
necessary to our client codes.

I think Ross mentioned the live RTSP session, in which we need to take
into account more. I would like to learn :->

And inline:

Magnus wrote:
>Okay, we will log a request to clarify that RTP-Info only provides for=20
>initial sync and that RTCP is needed for maintaining sync in the case
of=20
>clock drift. But there is much more on timestamp handling in=20
>http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-14
>than what is in RFC 2326.
>I could also recommend looking at the How To write RTP payload formats=20
>that has some discussion on the RTCP synch mechanism or Colin Perkins=20
>book on RTP.
>http://tools.ietf.org/html/draft-ietf-avt-rtp-howto-01
Very nice references. Of course, Colin's is bible.

>There is also need to have RTCP for synch in cases such as multiple=20
>sources (SSRCs) and live sessions. In addition RTCP is needed for its=20
>transport monitoring purpose. The sender can't do any type of
adaptation=20
>or avoid causing long term congestion unless RTCP is used.
Sometimes, non-functional requirement like simplicity and modifiability
is more important than additional features. IMHO, thereby allowing an
applications using just RTP without RTCP would be meaningful. At least,
it looks like optional in rfc2326.

Cheers,
Jaehwan


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



From avt-bounces@ietf.org Mon Apr 02 07:09:13 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYKOH-0008BV-3x; Mon, 02 Apr 2007 07:08:01 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYKOF-0008BE-QX
	for avt@ietf.org; Mon, 02 Apr 2007 07:07:59 -0400
Received: from an-out-0708.google.com ([209.85.132.241])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYKOE-00074C-IC
	for avt@ietf.org; Mon, 02 Apr 2007 07:07:59 -0400
Received: by an-out-0708.google.com with SMTP id d30so1250742and
	for <avt@ietf.org>; Mon, 02 Apr 2007 04:07:58 -0700 (PDT)
Received: by 10.100.225.13 with SMTP id x13mr3362276ang.1175512078343;
	Mon, 02 Apr 2007 04:07:58 -0700 (PDT)
Received: by 10.100.126.19 with HTTP; Mon, 2 Apr 2007 04:07:58 -0700 (PDT)
Message-ID: <31d1be720704020407j1c28deck28568be5aae13e58@mail.gmail.com>
Date: Mon, 2 Apr 2007 04:07:58 -0700
From: "Greg Herlein" <gherlein@herlein.com>
To: "Magnus Westerlund" <magnus.westerlund@ericsson.com>
Subject: Re: [AVT] Video streaming withour RTCP
In-Reply-To: <4610AB4C.1080807@ericsson.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <E1HXGtE-0000EZ-R7@megatron.ietf.org>
	<006301c772dd$b6ab7fa0$0fa2ee0a@viola>
	<FE6A9D3F2979884280CE0F5F5185517B1921FB@kor1corpmail01.mediator.com>
	<f06240802c2357566a067@66.80.62.44>
	<FE6A9D3F2979884280CE0F5F5185517B480200@kor1corpmail01.mediator.com>
	<4610AB4C.1080807@ericsson.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
Cc: Jaehwan Kim <jaehwan@vidiator.com>, Ross Finlayson <finlayson@live555.com>,
	annasagaram.vamsi@aftek.com, avt@ietf.org,
	"Y. Matsui" <matsui.yoshinori@jp.panasonic.com>
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

If we are going to add some language, I'd like to make sure we make a
clear point that RTCP provides the only standard way to get
*visibility* into the playback behavior (ie, packet loss rate etc) at
the end points.  Even if you don't plan to actively *use* that data
for stream control, it's very important to have that data for some
applications - and RTCP provides the standard way to get it.  I have
to explain this constantly to folks - more specific language about
"Why RTCP?" would be a good thing.

Greg

On 4/2/07, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
> Jaehwan Kim skrev:
> >
> >
> > Hi,
> >
> > And could you explain more in detail?
> >
> > I would appreciate if you give us an example.
> >
> >
> >
> > If there is a common misconception happening again and again, IMO, the
> > notion with enough examples should be into RTSP specification.
>
> Okay, we will log a request to clarify that RTP-Info only provides for
> initial sync and that RTCP is needed for maintaining sync in the case of
> clock drift. But there is much more on timestamp handling in
> http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-14
> than what is in RFC 2326.
>
> I could also recommend looking at the How To write RTP payload formats
> that has some discussion on the RTCP synch mechanism or Colin Perkins
> book on RTP.
> http://tools.ietf.org/html/draft-ietf-avt-rtp-howto-01
>
> There is also need to have RTCP for synch in cases such as multiple
> sources (SSRCs) and live sessions. In addition RTCP is needed for its
> transport monitoring purpose. The sender can't do any type of adaptation
> or avoid causing long term congestion unless RTCP is used.
>
> Cheers
>
> Magnus Westerlund
>
> IETF Transport Area Director & TSVWG Chair
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM/M
> ----------------------------------------------------------------------
> Ericsson AB                | Phone +46 8 4048287
> Torshamsgatan 23           | Fax   +46 8 7575550
> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www1.ietf.org/mailman/listinfo/avt
>

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



From avt-bounces@ietf.org Mon Apr 02 15:22:25 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYS5C-0007Is-29; Mon, 02 Apr 2007 15:20:50 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYS5A-0007Ig-KU
	for avt@ietf.org; Mon, 02 Apr 2007 15:20:48 -0400
Received: from dns.packetdesign.com ([65.192.41.10]
	helo=mailman.packetdesign.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYS57-00043G-7w
	for avt@ietf.org; Mon, 02 Apr 2007 15:20:48 -0400
Received: from dhcp-1-81.packetdesign.com (dhcp-1-81.packetdesign.com
	[192.168.1.81])
	by mailman.packetdesign.com (8.13.1/8.13.1) with ESMTP id
	l32JKREq008106; Mon, 2 Apr 2007 12:20:28 -0700
Date: Mon, 2 Apr 2007 12:21:30 -0700 (PDT)
From: Stephen Casner <casner@acm.org>
To: "Coinchon, Mathias" <coinchon@ebu.ch>
Subject: Re: [AVT] Parameters lost for media type MPA in new RFC4856 ?
In-Reply-To: <B6472FAD86FE9C4A8F1870BA8C8910EBB37B77@gnvasmail1a.gva.ebu.ch>
Message-ID: <20070402121602.F89535@hsa>
References: <B6472FAD86FE9C4A8F1870BA8C8910EBB37B77@gnvasmail1a.gva.ebu.ch>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Cc: avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

On Mon, 2 Apr 2007, Coinchon, Mathias wrote:

> I have one question regarding the new RFC4855 and RFC4856 that obsolete
> RFC3555:
>
> - Where are parameters for MPA (mpeg audio) specified ? They were in RFC3555
> (4.1.17) but not anymore in RFC4856.
>
> As I have understood from RFC4855/4856, parameters should now be specified
> in payload format RFCs.
> However looking in RFC2250 for MPEG payload format (video and audio) I don't
> see a specification of these parameters.
> Looking on IANA pages, media type MPA still point on RFC3555.
>
> Could you please tell me where to point now for MPEG audio parameters ?

Section 1.1, IANA Considerations, in RFC4856 says:

    Some media type registrations contained in RFC 3555 are omitted
    from this document; the existing registrations for those types
    continue to be valid until updated by other RFCs.

That is why on the IANA pages, media type MPA still lists RFC3555 as
the reference.

> Will there be modifications of RFC2250 for MPEG payload format specifying
> parameters ? (and modification of RFC3550/3551 to point to RFC3855/56
> instead of RFC3555 ?)

There was some work done on updating RFC2250 by one of the authors,
but that has not come to fruition.  In any case, I would expect any
changes to be backwards compatible with the parameter specifications
in RFC3555.

                                                         -- Steve

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



From avt-bounces@ietf.org Tue Apr 03 03:43:34 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYdec-0006PT-Od; Tue, 03 Apr 2007 03:42:10 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYdea-0006PC-Od
	for avt@ietf.org; Tue, 03 Apr 2007 03:42:08 -0400
Received: from ihemail1.lucent.com ([135.245.0.33])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYdeV-0001xl-Bs
	for avt@ietf.org; Tue, 03 Apr 2007 03:42:08 -0400
Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2])
	by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l337fgQ8022123
	for <avt@ietf.org>; Tue, 3 Apr 2007 02:42:01 -0500 (CDT)
Received: from inexp02.in.lucent.com ([135.254.223.66]) by
	ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 3 Apr 2007 02:42:00 -0500
Received: from INEXC1U02.in.lucent.com ([135.254.223.25]) by
	inexp02.in.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 3 Apr 2007 13:11:54 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 3 Apr 2007 13:11:54 +0530
Message-ID: <BF2A009791C9E644A1E6344619C5698A1ABED7@INEXC1U02.in.lucent.com>
In-Reply-To: <20070402121602.F89535@hsa>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Confusion regarding RTP 
Thread-Index: Acd1XKnmz8/3t3H8QSCt9riNlZJTIAAZfNsQ
References: <B6472FAD86FE9C4A8F1870BA8C8910EBB37B77@gnvasmail1a.gva.ebu.ch>
	<20070402121602.F89535@hsa>
From: "Bhattacharya, Abhijit \(Abhijit\)" <abhattacharya@alcatel-lucent.com>
To: <avt@ietf.org>
X-OriginalArrivalTime: 03 Apr 2007 07:41:54.0938 (UTC)
	FILETIME=[8D14EDA0:01C775C3]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Subject: [AVT] Confusion regarding RTP 
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org


Hi,

I have a confusion regarding RTP header. Let us suppose the following
considerations

Version =3D 2
Padding =3D 0
Extension =3D 0
CC =3D 0
PT =3D 0
Seq. No. =3D 0A9E

Now what should be the packet look like=20

0000 80 00 0A 9E ....
0010 ................

  OR=20

0000 02 00 9E 0A ....
0010 ................

I am confused regarding this.=20

Thanks and regards,
Abhijit


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



From avt-bounces@ietf.org Tue Apr 03 04:51:44 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYein-0008TC-NS; Tue, 03 Apr 2007 04:50:33 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYeim-0008St-Kt
	for avt@ietf.org; Tue, 03 Apr 2007 04:50:32 -0400
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYeig-0000cO-VM
	for avt@ietf.org; Tue, 03 Apr 2007 04:50:32 -0400
Received: from mailgw4.ericsson.se (unknown [127.0.0.1])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	70A22215C6; Tue,  3 Apr 2007 10:50:24 +0200 (CEST)
X-AuditID: c1b4fb3e-b01efbb0000061ca-d4-461215503937 
Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	5E7D321580; Tue,  3 Apr 2007 10:50:24 +0200 (CEST)
Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by
	esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 3 Apr 2007 10:50:21 +0200
Received: from [147.214.30.247] ([147.214.30.247]) by
	esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 3 Apr 2007 10:50:20 +0200
Message-ID: <4612154C.3090205@ericsson.com>
Date: Tue, 03 Apr 2007 10:50:20 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: "Bhattacharya, Abhijit \(Abhijit\)" <abhattacharya@alcatel-lucent.com>
Subject: Re: [AVT] Confusion regarding RTP
References: <B6472FAD86FE9C4A8F1870BA8C8910EBB37B77@gnvasmail1a.gva.ebu.ch>	<20070402121602.F89535@hsa>
	<BF2A009791C9E644A1E6344619C5698A1ABED7@INEXC1U02.in.lucent.com>
In-Reply-To: <BF2A009791C9E644A1E6344619C5698A1ABED7@INEXC1U02.in.lucent.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 03 Apr 2007 08:50:20.0873 (UTC)
	FILETIME=[1C68E390:01C775CD]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Cc: avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

Bhattacharya, Abhijit (Abhijit) skrev:
> Hi,
> 
> I have a confusion regarding RTP header. Let us suppose the following
> considerations
> 
> Version = 2
> Padding = 0
> Extension = 0
> CC = 0
> PT = 0
> Seq. No. = 0A9E
> 
> Now what should be the packet look like 
> 
> 0000 80 00 0A 9E ....
> 0010 ................
> 
>   OR 
> 
> 0000 02 00 9E 0A ....
> 0010 ................
> 
> I am confused regarding this. 
> 
> Thanks and regards,
> Abhijit
> 
> 

It is network byte order, which means the most significant bits and 
bytes first.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

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



From avt-bounces@ietf.org Tue Apr 03 04:57:54 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYep2-0004H6-Ts; Tue, 03 Apr 2007 04:57:00 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYep1-0004FF-Ge
	for avt@ietf.org; Tue, 03 Apr 2007 04:56:59 -0400
Received: from ihemail2.lucent.com ([135.245.0.35])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYeoy-00049W-Vi
	for avt@ietf.org; Tue, 03 Apr 2007 04:56:59 -0400
Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2])
	by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id l338usdq012337;
	Tue, 3 Apr 2007 03:56:54 -0500 (CDT)
Received: from inexp01.in.lucent.com ([135.254.223.65]) by
	ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 3 Apr 2007 03:56:54 -0500
Received: from INEXC1U02.in.lucent.com ([135.254.223.25]) by
	inexp01.in.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 3 Apr 2007 14:26:50 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [AVT] Confusion regarding RTP
Date: Tue, 3 Apr 2007 14:26:50 +0530
Message-ID: <BF2A009791C9E644A1E6344619C5698A1ABEFB@INEXC1U02.in.lucent.com>
In-Reply-To: <4612154C.3090205@ericsson.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [AVT] Confusion regarding RTP
Thread-Index: Acd1zWw8bpzHe6poTf293ofqVPtRSgAADzBQ
References: <B6472FAD86FE9C4A8F1870BA8C8910EBB37B77@gnvasmail1a.gva.ebu.ch>	<20070402121602.F89535@hsa>
	<BF2A009791C9E644A1E6344619C5698A1ABED7@INEXC1U02.in.lucent.com>
	<4612154C.3090205@ericsson.com>
From: "Bhattacharya, Abhijit \(Abhijit\)" <abhattacharya@alcatel-lucent.com>
To: "Magnus Westerlund" <magnus.westerlund@ericsson.com>
X-OriginalArrivalTime: 03 Apr 2007 08:56:50.0402 (UTC)
	FILETIME=[04964C20:01C775CE]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a
Cc: avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

Hi Magnus,

Thanks for the information. Actually, the rtp_hdt_t structure in RFC
3550 resulted in the confusion. Here version field is the 1st element in
the structure. So it becomes the LSB. Anyways, now its clear to me.

Thanks and regards,
Abhijit=20

-----Original Message-----
From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20
Sent: Tuesday, April 03, 2007 2:20 PM
To: Bhattacharya, Abhijit (Abhijit)
Cc: avt@ietf.org
Subject: Re: [AVT] Confusion regarding RTP

Bhattacharya, Abhijit (Abhijit) skrev:
> Hi,
>=20
> I have a confusion regarding RTP header. Let us suppose the following=20
> considerations
>=20
> Version =3D 2
> Padding =3D 0
> Extension =3D 0
> CC =3D 0
> PT =3D 0
> Seq. No. =3D 0A9E
>=20
> Now what should be the packet look like
>=20
> 0000 80 00 0A 9E ....
> 0010 ................
>=20
>   OR
>=20
> 0000 02 00 9E 0A ....
> 0010 ................
>=20
> I am confused regarding this.=20
>=20
> Thanks and regards,
> Abhijit
>=20
>=20

It is network byte order, which means the most significant bits and
bytes first.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

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



From avt-bounces@ietf.org Tue Apr 03 05:05:07 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYewD-0000qI-EW; Tue, 03 Apr 2007 05:04:25 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYewB-0000cj-Tf
	for avt@ietf.org; Tue, 03 Apr 2007 05:04:23 -0400
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HYew6-0000qE-7x
	for avt@ietf.org; Tue, 03 Apr 2007 05:04:23 -0400
Received: from mailgw4.ericsson.se (unknown [127.0.0.1])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	8053B2159D; Tue,  3 Apr 2007 11:04:15 +0200 (CEST)
X-AuditID: c1b4fb3e-af9eebb0000061ca-97-4612188fa346 
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	6CE61213B2; Tue,  3 Apr 2007 11:04:15 +0200 (CEST)
Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by
	esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 3 Apr 2007 11:04:14 +0200
Received: from [147.214.30.247] ([147.214.30.247]) by
	esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 3 Apr 2007 11:04:15 +0200
Message-ID: <4612188E.90507@ericsson.com>
Date: Tue, 03 Apr 2007 11:04:14 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: "Bhattacharya, Abhijit \(Abhijit\)" <abhattacharya@alcatel-lucent.com>
Subject: Re: [AVT] Confusion regarding RTP
References: <B6472FAD86FE9C4A8F1870BA8C8910EBB37B77@gnvasmail1a.gva.ebu.ch>	<20070402121602.F89535@hsa>
	<BF2A009791C9E644A1E6344619C5698A1ABED7@INEXC1U02.in.lucent.com>
	<4612154C.3090205@ericsson.com>
	<BF2A009791C9E644A1E6344619C5698A1ABEFB@INEXC1U02.in.lucent.com>
In-Reply-To: <BF2A009791C9E644A1E6344619C5698A1ABEFB@INEXC1U02.in.lucent.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 03 Apr 2007 09:04:15.0019 (UTC)
	FILETIME=[0D9977B0:01C775CF]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Cc: avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

Bhattacharya, Abhijit (Abhijit) skrev:
> Hi Magnus,
> 
> Thanks for the information. Actually, the rtp_hdt_t structure in RFC
> 3550 resulted in the confusion. Here version field is the 1st element in
> the structure. So it becomes the LSB. Anyways, now its clear to me.
> 

Your comment make me think you are misunderstanding how bit fields in C 
are defined? If one looks at the rtp_hdt_t:

    typedef struct {
        unsigned int version:2;   /* protocol version */
        unsigned int p:1;         /* padding flag */
        unsigned int x:1;         /* header extension flag */
        unsigned int cc:4;        /* CSRC count */
        unsigned int m:1;         /* marker bit */
        unsigned int pt:7;        /* payload type */
        unsigned int seq:16;      /* sequence number */
        u_int32 ts;               /* timestamp */
        u_int32 ssrc;             /* synchronization source */
        u_int32 csrc[1];          /* optional CSRC list */
    } rtp_hdr_t;

I can't understand why you think version is the LSB. Starting in the 
most significant 2 bits in the first byte write version. The next bit is 
p, then x, then 4 bits of CC in MSB to LSB. In the next byte there is 
first the marker bit (bit 9) and then 7 PT bits. Then you have the more 
significant first byte of the sequence number, followed by the less 
significant byte.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

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



From avt-bounces@ietf.org Tue Apr 03 06:11:06 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYfxy-0001hB-QB; Tue, 03 Apr 2007 06:10:18 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYfxy-0001fw-8X
	for avt@ietf.org; Tue, 03 Apr 2007 06:10:18 -0400
Received: from smtp3.wanadoo.co.uk ([193.252.22.156] helo=smtp3.freeserve.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYfxt-00032i-Nz
	for avt@ietf.org; Tue, 03 Apr 2007 06:10:18 -0400
Received: from me-wanadoo.net (localhost [127.0.0.1])
	by mwinf3201.me.freeserve.com (SMTP Server) with ESMTP id 0B7362400085; 
	Tue,  3 Apr 2007 12:10:11 +0200 (CEST)
Received: from Codalogic (user-54433ea2.lns5-c7.dsl.pol.co.uk [84.67.62.162])
	by mwinf3201.me.freeserve.com (SMTP Server) with SMTP id
	A14FF2400082; Tue,  3 Apr 2007 12:10:10 +0200 (CEST)
X-ME-UUID: 20070403101010660.A14FF2400082@mwinf3201.me.freeserve.com
Message-ID: <009901c775d8$4049c2b0$2400a8c0@Codalogic>
From: "Pete Cordell" <pete@tech-know-ware.com>
To: "Magnus Westerlund" <magnus.westerlund@ericsson.com>,
	"Bhattacharya, Abhijit (Abhijit)" <abhattacharya@alcatel-lucent.com>
References: <B6472FAD86FE9C4A8F1870BA8C8910EBB37B77@gnvasmail1a.gva.ebu.ch>	<20070402121602.F89535@hsa><BF2A009791C9E644A1E6344619C5698A1ABED7@INEXC1U02.in.lucent.com><4612154C.3090205@ericsson.com><BF2A009791C9E644A1E6344619C5698A1ABEFB@INEXC1U02.in.lucent.com>
	<4612188E.90507@ericsson.com>
Subject: Re: [AVT] Confusion regarding RTP
Date: Tue, 3 Apr 2007 11:10:02 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
	reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-Spam-Score: 0.1 (/)
X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede
Cc: avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

It seems you've forgotten that C (and C++) reserves the right to pack these 
up how it feels.  Try:

    #include <stdio.h>

    typedef unsigned int u_int32;

    typedef struct {
        unsigned int version:2;   /* protocol version */
        unsigned int p:1;         /* padding flag */
        unsigned int x:1;         /* header extension flag */
        unsigned int cc:4;        /* CSRC count */
        unsigned int m:1;         /* marker bit */
        unsigned int pt:7;        /* payload type */
        unsigned int seq:16;      /* sequence number */
        u_int32 ts;               /* timestamp */
        u_int32 ssrc;             /* synchronization source */
        u_int32 csrc[1];          /* optional CSRC list */
    } rtp_hdr_t;

    typedef union {
        rtp_hdr_t rtp;
        unsigned int uint;
    } thingy;

    int main()
    {
        thingy my_thing;

        my_thing.uint = 0;
        my_thing.rtp.version = 3;
        printf( "Version: %x\n", my_thing.uint );

        my_thing.uint = 0;
        my_thing.rtp.seq = 0xffff;
        printf( "Seq: %x\n", my_thing.uint );

        return 0;
    }


I get:

Version: 3
seq: ffff0000

on both Visual Studio x86 and Cygwin GCC (x86).

Hence this is not likely to be portable.

HTH,

Pete.
--
=============================================
Pete Cordell
Tech-Know-Ware Ltd
for XML to C++ data binding visit
http://www.tech-know-ware.com/lmx/
http://www.codalogic.com/lmx/
=============================================

----- Original Message ----- 
From: "Magnus Westerlund" <magnus.westerlund@ericsson.com>
To: "Bhattacharya, Abhijit (Abhijit)" <abhattacharya@alcatel-lucent.com>
Cc: <avt@ietf.org>
Sent: Tuesday, April 03, 2007 10:04 AM
Subject: Re: [AVT] Confusion regarding RTP


> Bhattacharya, Abhijit (Abhijit) skrev:
>> Hi Magnus,
>>
>> Thanks for the information. Actually, the rtp_hdt_t structure in RFC
>> 3550 resulted in the confusion. Here version field is the 1st element in
>> the structure. So it becomes the LSB. Anyways, now its clear to me.
>>
>
> Your comment make me think you are misunderstanding how bit fields in C 
> are defined? If one looks at the rtp_hdt_t:
>
>    typedef struct {
>        unsigned int version:2;   /* protocol version */
>        unsigned int p:1;         /* padding flag */
>        unsigned int x:1;         /* header extension flag */
>        unsigned int cc:4;        /* CSRC count */
>        unsigned int m:1;         /* marker bit */
>        unsigned int pt:7;        /* payload type */
>        unsigned int seq:16;      /* sequence number */
>        u_int32 ts;               /* timestamp */
>        u_int32 ssrc;             /* synchronization source */
>        u_int32 csrc[1];          /* optional CSRC list */
>    } rtp_hdr_t;
>
> I can't understand why you think version is the LSB. Starting in the most 
> significant 2 bits in the first byte write version. The next bit is p, 
> then x, then 4 bits of CC in MSB to LSB. In the next byte there is first 
> the marker bit (bit 9) and then 7 PT bits. Then you have the more 
> significant first byte of the sequence number, followed by the less 
> significant byte.
>
> Cheers
>
> Magnus Westerlund
>
> IETF Transport Area Director & TSVWG Chair
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM/M
> ----------------------------------------------------------------------
> Ericsson AB                | Phone +46 8 4048287
> Torshamsgatan 23           | Fax   +46 8 7575550
> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www1.ietf.org/mailman/listinfo/avt
> 



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



From avt-bounces@ietf.org Tue Apr 03 06:26:55 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYgCy-00049J-Cf; Tue, 03 Apr 2007 06:25:48 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYgCx-00046h-7z
	for avt@ietf.org; Tue, 03 Apr 2007 06:25:47 -0400
Received: from mee06.mee.com ([194.130.244.68])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYgCv-0005fh-QE
	for avt@ietf.org; Tue, 03 Apr 2007 06:25:47 -0400
Received: from meemgw02 ([10.226.1.24] helo=meemgw02.mee.com)
	by mee06.mee.com with esmtp (Exim 4.43) id 1HYgCh-0002ba-3z
	for avt@ietf.org; Tue, 03 Apr 2007 11:25:31 +0100
Received: from meetvd02 (meetvd02.diamondlink.com [10.226.1.23])
	by meemgw02.mee.com (8.11.6/8.11.6) with SMTP id l33APU247066
	for <avt@ietf.org>; Tue, 3 Apr 2007 11:25:30 +0100 (BST)
Received: From einstein.vil.ite.mee.com ([10.226.210.23]) by meetvd02
	(WebShield SMTP v4.5 MR1a P0803.345); 
	id 1175595050125; Tue, 3 Apr 2007 11:10:50 +0100
Received: from [10.226.210.105]
	by einstein.vil.ite.mee.com with esmtp (Exim 4.62)
	(envelope-from <nikola.sprljan@vil.ite.mee.com>)
	id 1HYgCZ-0002a5-DR; Tue, 03 Apr 2007 11:25:24 +0100
Message-ID: <46122B93.4050507@vil.ite.mee.com>
Date: Tue, 03 Apr 2007 11:25:23 +0100
From: Nikola Sprljan <nikola.sprljan@vil.ite.mee.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Subject: Re: [AVT] Confusion regarding RTP
References: <B6472FAD86FE9C4A8F1870BA8C8910EBB37B77@gnvasmail1a.gva.ebu.ch>	<20070402121602.F89535@hsa>	<BF2A009791C9E644A1E6344619C5698A1ABED7@INEXC1U02.in.lucent.com>	<4612154C.3090205@ericsson.com>	<BF2A009791C9E644A1E6344619C5698A1ABEFB@INEXC1U02.in.lucent.com>
	<4612188E.90507@ericsson.com>
In-Reply-To: <4612188E.90507@ericsson.com>
X-Enigmail-Version: 0.94.2.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: -5.4 (-----)
X-Spam-Report: VI-Lab's spam scanner has examined this email on server
	"einstein.vil.ite.mee.com". The results of the scan are shown below.
	If you have any questions, see the administrator of that system.
	Is Spam? No  (-5.4 points, 3.5 required)
	pts rule name              description
	---- ----------------------
	--------------------------------------------------
	-1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP
	-3.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1%
	[score: 0.0000]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Cc: avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

Magnus Westerlund wrote:
> Bhattacharya, Abhijit (Abhijit) skrev:
>> Hi Magnus,
>>
>> Thanks for the information. Actually, the rtp_hdt_t structure in RFC
>> 3550 resulted in the confusion. Here version field is the 1st element in
>> the structure. So it becomes the LSB. Anyways, now its clear to me.
>>
> 
> Your comment make me think you are misunderstanding how bit fields in C
> are defined? If one looks at the rtp_hdt_t:
> 
>    typedef struct {
>        unsigned int version:2;   /* protocol version */
>        unsigned int p:1;         /* padding flag */
>        unsigned int x:1;         /* header extension flag */
>        unsigned int cc:4;        /* CSRC count */
>        unsigned int m:1;         /* marker bit */
>        unsigned int pt:7;        /* payload type */
>        unsigned int seq:16;      /* sequence number */
>        u_int32 ts;               /* timestamp */
>        u_int32 ssrc;             /* synchronization source */
>        u_int32 csrc[1];          /* optional CSRC list */
>    } rtp_hdr_t;
> 
> I can't understand why you think version is the LSB. Starting in the
> most significant 2 bits in the first byte write version. The next bit is
> p, then x, then 4 bits of CC in MSB to LSB. In the next byte there is
> first the marker bit (bit 9) and then 7 PT bits. Then you have the more
> significant first byte of the sequence number, followed by the less
> significant byte.

It think the problem that Abhijit is encountering is a common one with C
bit-fields - the order of bits will depend on endianess of processor
this is compiled on. Since x86 processors use the little-endian format,
you'll have to manually reverse the order of fields for each byte in the
structure. You'll also have to do conversions from/to network byte order
(which is big-endian) by using ntohl and htonl (and other) functions.

Also, for data to be aligned properly, for some versions of the MS
compiler you have to specify correct packing when in a default Debug mode:
#pragma pack(1)
, otherwise casting pointers to/from structures including rtp_hdr_t
struct would not work.

Kind regards,

Nikola Sprljan

-- 
*Dr. Nikola Sprljan*
/Research Engineer/
*MITSUBISHI ELECTRIC INFORMATION TECHNOLOGY CENTRE EUROPE B.V*
*VISUAL INFORMATION LABORATORY*
20, Frederick Sanger Road
The Surrey Research Park
Guildford, Surrey GU2 7YD
/UK Registered Branch BR 003158/
*DDI Telephone: +44 1483 885538*
Tel: +44 1483 885800   Fax: +44 1483 579107

CONFIDENTIALITY NOTICE:
This message contains information which is confidential and/or privileged
and is intended for the named addressee(s) only. If you are not the
intended recipient, you must not copy, distribute, disclose, otherwise
use the information or take any action in reliance on it. If you have
received this message in error, please notify sender immediately and
destroy any copies whether in physical or electronic record.

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



From avt-bounces@ietf.org Tue Apr 03 06:37:36 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYgNa-0004CX-CX; Tue, 03 Apr 2007 06:36:46 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYgNY-0004BW-HK
	for avt@ietf.org; Tue, 03 Apr 2007 06:36:44 -0400
Received: from mee06.mee.com ([194.130.244.68])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYgNX-0008PQ-9I
	for avt@ietf.org; Tue, 03 Apr 2007 06:36:44 -0400
Received: from meemgw02 ([10.226.1.24] helo=meemgw02.mee.com)
	by mee06.mee.com with esmtp (Exim 4.43) id 1HYgNW-00034i-Tn
	for avt@ietf.org; Tue, 03 Apr 2007 11:36:42 +0100
Received: from meetvd02 (meetvd02.diamondlink.com [10.226.1.23])
	by meemgw02.mee.com (8.11.6/8.11.6) with SMTP id l33Aag248567
	for <avt@ietf.org>; Tue, 3 Apr 2007 11:36:42 +0100 (BST)
Received: From einstein.vil.ite.mee.com ([10.226.210.23]) by meetvd02
	(WebShield SMTP v4.5 MR1a P0803.345); 
	id 1175595722609; Tue, 3 Apr 2007 11:22:02 +0100
Received: from [10.226.210.105]
	by einstein.vil.ite.mee.com with esmtp (Exim 4.62)
	(envelope-from <nikola.sprljan@vil.ite.mee.com>) id 1HYgNP-0002gp-VQ
	for avt@ietf.org; Tue, 03 Apr 2007 11:36:37 +0100
Message-ID: <46122E33.1000700@vil.ite.mee.com>
Date: Tue, 03 Apr 2007 11:36:35 +0100
From: Nikola Sprljan <nikola.sprljan@vil.ite.mee.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: avt@ietf.org
Subject: Re: [AVT] Confusion regarding RTP
References: <B6472FAD86FE9C4A8F1870BA8C8910EBB37B77@gnvasmail1a.gva.ebu.ch>	<20070402121602.F89535@hsa>	<BF2A009791C9E644A1E6344619C5698A1ABED7@INEXC1U02.in.lucent.com>	<4612154C.3090205@ericsson.com>	<BF2A009791C9E644A1E6344619C5698A1ABEFB@INEXC1U02.in.lucent.com>	<4612188E.90507@ericsson.com>
	<46122B93.4050507@vil.ite.mee.com>
In-Reply-To: <46122B93.4050507@vil.ite.mee.com>
X-Enigmail-Version: 0.94.2.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: -5.4 (-----)
X-Spam-Report: VI-Lab's spam scanner has examined this email on server
	"einstein.vil.ite.mee.com". The results of the scan are shown below.
	If you have any questions, see the administrator of that system.
	Is Spam? No  (-5.4 points, 3.5 required)
	pts rule name              description
	---- ----------------------
	--------------------------------------------------
	-1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP
	-3.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1%
	[score: 0.0000]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

Please disregard the confidentiality notice in my previous mail, it was
inserted by mistake.

Nikola

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



From avt-bounces@ietf.org Tue Apr 03 06:46:17 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYgVg-0004G6-IN; Tue, 03 Apr 2007 06:45:08 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYgVf-0004Fm-6B
	for avt@ietf.org; Tue, 03 Apr 2007 06:45:07 -0400
Received: from mr1.dcs.gla.ac.uk ([130.209.249.184])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HYgVd-00042a-IH
	for avt@ietf.org; Tue, 03 Apr 2007 06:45:07 -0400
Received: from vpn13.dcs.gla.ac.uk ([130.209.254.13]:53964)
	by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42)
	id 1HYgVR-0007aA-Ez; Tue, 03 Apr 2007 11:44:53 +0100
In-Reply-To: <46122B93.4050507@vil.ite.mee.com>
References: <B6472FAD86FE9C4A8F1870BA8C8910EBB37B77@gnvasmail1a.gva.ebu.ch>	<20070402121602.F89535@hsa>	<BF2A009791C9E644A1E6344619C5698A1ABED7@INEXC1U02.in.lucent.com>	<4612154C.3090205@ericsson.com>	<BF2A009791C9E644A1E6344619C5698A1ABEFB@INEXC1U02.in.lucent.com>
	<4612188E.90507@ericsson.com> <46122B93.4050507@vil.ite.mee.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <F5056FFC-AFA2-4F5A-B23D-4E49237CEA33@csperkins.org>
Content-Transfer-Encoding: 7bit
From: Colin Perkins <csp@csperkins.org>
Subject: Re: [AVT] Confusion regarding RTP
Date: Tue, 3 Apr 2007 11:44:47 +0100
To: Nikola Sprljan <nikola.sprljan@vil.ite.mee.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>, avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

Note the comment at the start of appendix A of RFC 3550:

    The following definitions are used for all examples; for clarity and
    brevity, the structure definitions are only valid for 32-bit big-
    endian (most significant octet first) architectures.  Bit fields are
    assumed to be packed tightly in big-endian bit order, with no
    additional padding.  Modifications would be required to construct a
    portable implementation.


Colin



On 3 Apr 2007, at 11:25, Nikola Sprljan wrote:

> Magnus Westerlund wrote:
>> Bhattacharya, Abhijit (Abhijit) skrev:
>>> Hi Magnus,
>>>
>>> Thanks for the information. Actually, the rtp_hdt_t structure in RFC
>>> 3550 resulted in the confusion. Here version field is the 1st  
>>> element in
>>> the structure. So it becomes the LSB. Anyways, now its clear to me.
>>>
>>
>> Your comment make me think you are misunderstanding how bit fields  
>> in C
>> are defined? If one looks at the rtp_hdt_t:
>>
>>    typedef struct {
>>        unsigned int version:2;   /* protocol version */
>>        unsigned int p:1;         /* padding flag */
>>        unsigned int x:1;         /* header extension flag */
>>        unsigned int cc:4;        /* CSRC count */
>>        unsigned int m:1;         /* marker bit */
>>        unsigned int pt:7;        /* payload type */
>>        unsigned int seq:16;      /* sequence number */
>>        u_int32 ts;               /* timestamp */
>>        u_int32 ssrc;             /* synchronization source */
>>        u_int32 csrc[1];          /* optional CSRC list */
>>    } rtp_hdr_t;
>>
>> I can't understand why you think version is the LSB. Starting in the
>> most significant 2 bits in the first byte write version. The next  
>> bit is
>> p, then x, then 4 bits of CC in MSB to LSB. In the next byte there is
>> first the marker bit (bit 9) and then 7 PT bits. Then you have the  
>> more
>> significant first byte of the sequence number, followed by the less
>> significant byte.
>
> It think the problem that Abhijit is encountering is a common one  
> with C
> bit-fields - the order of bits will depend on endianess of processor
> this is compiled on. Since x86 processors use the little-endian  
> format,
> you'll have to manually reverse the order of fields for each byte  
> in the
> structure. You'll also have to do conversions from/to network byte  
> order
> (which is big-endian) by using ntohl and htonl (and other) functions.
>
> Also, for data to be aligned properly, for some versions of the MS
> compiler you have to specify correct packing when in a default  
> Debug mode:
> #pragma pack(1)
> , otherwise casting pointers to/from structures including rtp_hdr_t
> struct would not work.
>
> Kind regards,
>
> Nikola Sprljan
>
> -- 
> *Dr. Nikola Sprljan*
> /Research Engineer/
> *MITSUBISHI ELECTRIC INFORMATION TECHNOLOGY CENTRE EUROPE B.V*
> *VISUAL INFORMATION LABORATORY*
> 20, Frederick Sanger Road
> The Surrey Research Park
> Guildford, Surrey GU2 7YD
> /UK Registered Branch BR 003158/
> *DDI Telephone: +44 1483 885538*
> Tel: +44 1483 885800   Fax: +44 1483 579107
>
> CONFIDENTIALITY NOTICE:
> This message contains information which is confidential and/or  
> privileged
> and is intended for the named addressee(s) only. If you are not the
> intended recipient, you must not copy, distribute, disclose, otherwise
> use the information or take any action in reliance on it. If you have
> received this message in error, please notify sender immediately and
> destroy any copies whether in physical or electronic record.
>
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www1.ietf.org/mailman/listinfo/avt



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



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



From avt-bounces@ietf.org Tue Apr 03 06:54:02 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYgda-0007vF-GS; Tue, 03 Apr 2007 06:53:18 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYgdZ-0007ra-Au
	for avt@ietf.org; Tue, 03 Apr 2007 06:53:17 -0400
Received: from ihemail1.lucent.com ([135.245.0.33])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HYgdT-0004pz-IO
	for avt@ietf.org; Tue, 03 Apr 2007 06:53:12 -0400
Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1])
	by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l33AqrI3011894;
	Tue, 3 Apr 2007 05:53:02 -0500 (CDT)
Received: from inexp02.in.lucent.com ([135.254.223.66]) by
	ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 3 Apr 2007 05:52:35 -0500
Received: from INEXC1U02.in.lucent.com ([135.254.223.25]) by
	inexp02.in.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 3 Apr 2007 16:22:14 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [AVT] Confusion regarding RTP
Date: Tue, 3 Apr 2007 16:22:13 +0530
Message-ID: <BF2A009791C9E644A1E6344619C5698A1ABF60@INEXC1U02.in.lucent.com>
In-Reply-To: <46122B93.4050507@vil.ite.mee.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [AVT] Confusion regarding RTP
Thread-Index: Acd12ngYRwiKyU3hTlixzb3BXwSN0gAApHCw
References: <B6472FAD86FE9C4A8F1870BA8C8910EBB37B77@gnvasmail1a.gva.ebu.ch>	<20070402121602.F89535@hsa>	<BF2A009791C9E644A1E6344619C5698A1ABED7@INEXC1U02.in.lucent.com>	<4612154C.3090205@ericsson.com>	<BF2A009791C9E644A1E6344619C5698A1ABEFB@INEXC1U02.in.lucent.com>
	<4612188E.90507@ericsson.com> <46122B93.4050507@vil.ite.mee.com>
From: "Bhattacharya, Abhijit \(Abhijit\)" <abhattacharya@alcatel-lucent.com>
To: "Nikola Sprljan" <nikola.sprljan@vil.ite.mee.com>,
	"Magnus Westerlund" <magnus.westerlund@ericsson.com>,
	"Pete Cordell" <pete@tech-know-ware.com>
X-OriginalArrivalTime: 03 Apr 2007 10:52:14.0193 (UTC)
	FILETIME=[237CF610:01C775DE]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290
Cc: avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

Hi all,

Thanks for your inputs. Actually I just now attempted in both Solaris
and Linux the same code as the following=20

#include<stdio.h>
#include<math.h>
#include <stdlib.h>
#include <string.h>
#include <netinet/in.h>
typedef struct headers {
       unsigned int version:2;   /* protocol version */
       unsigned int p:1;         /* padding flag */
       unsigned int x:1;         /* header extension flag */
       unsigned int cc:4;        /* CSRC count */
        }HDR;
   typedef struct {
       HDR       u;
       unsigned int ts;               /* timestamp */
       unsigned int ssrc;             /* synchronization source */
       unsigned int csrc[1];          /* optional CSRC list */
   } rtp_hdr_t;


main()
{
        char a[1];
        rtp_hdr_t rtp_hdr;
        rtp_hdr.u.version =3D 1;
        rtp_hdr.u.p =3D 0;
        rtp_hdr.u.x =3D 0;
        rtp_hdr.u.cc =3D 0;
        memcpy((void *)a, (void *)(&rtp_hdr.u), 1);
        printf("\n THE value is %x !! \n", a[0]);
}


In Linux the answer is :-

THE value is 1

And in Solaris the answer is :-

THE value is 40 !!

Initially I was using Linux and since htons does not work within "a
byte", I was confused. So the 1st element is considered MSB in Solaris
and LSB in Linux.

Thanks and regards,
Abhijit


=20

-----Original Message-----
From: Nikola Sprljan [mailto:nikola.sprljan@vil.ite.mee.com]=20
Sent: Tuesday, April 03, 2007 3:55 PM
To: Magnus Westerlund
Cc: Bhattacharya, Abhijit (Abhijit); avt@ietf.org
Subject: Re: [AVT] Confusion regarding RTP

Magnus Westerlund wrote:
> Bhattacharya, Abhijit (Abhijit) skrev:
>> Hi Magnus,
>>
>> Thanks for the information. Actually, the rtp_hdt_t structure in RFC=20
>> 3550 resulted in the confusion. Here version field is the 1st element

>> in the structure. So it becomes the LSB. Anyways, now its clear to
me.
>>
>=20
> Your comment make me think you are misunderstanding how bit fields in=20
> C are defined? If one looks at the rtp_hdt_t:
>=20
>    typedef struct {
>        unsigned int version:2;   /* protocol version */
>        unsigned int p:1;         /* padding flag */
>        unsigned int x:1;         /* header extension flag */
>        unsigned int cc:4;        /* CSRC count */
>        unsigned int m:1;         /* marker bit */
>        unsigned int pt:7;        /* payload type */
>        unsigned int seq:16;      /* sequence number */
>        u_int32 ts;               /* timestamp */
>        u_int32 ssrc;             /* synchronization source */
>        u_int32 csrc[1];          /* optional CSRC list */
>    } rtp_hdr_t;
>=20
> I can't understand why you think version is the LSB. Starting in the=20
> most significant 2 bits in the first byte write version. The next bit=20
> is p, then x, then 4 bits of CC in MSB to LSB. In the next byte there=20
> is first the marker bit (bit 9) and then 7 PT bits. Then you have the=20
> more significant first byte of the sequence number, followed by the=20
> less significant byte.

It think the problem that Abhijit is encountering is a common one with C
bit-fields - the order of bits will depend on endianess of processor
this is compiled on. Since x86 processors use the little-endian format,
you'll have to manually reverse the order of fields for each byte in the
structure. You'll also have to do conversions from/to network byte order
(which is big-endian) by using ntohl and htonl (and other) functions.

Also, for data to be aligned properly, for some versions of the MS
compiler you have to specify correct packing when in a default Debug
mode:
#pragma pack(1)
, otherwise casting pointers to/from structures including rtp_hdr_t
struct would not work.

Kind regards,

Nikola Sprljan

--
*Dr. Nikola Sprljan*
/Research Engineer/
*MITSUBISHI ELECTRIC INFORMATION TECHNOLOGY CENTRE EUROPE B.V* *VISUAL
INFORMATION LABORATORY* 20, Frederick Sanger Road The Surrey Research
Park Guildford, Surrey GU2 7YD /UK Registered Branch BR 003158/ *DDI
Telephone: +44 1483 885538*
Tel: +44 1483 885800   Fax: +44 1483 579107

CONFIDENTIALITY NOTICE:
This message contains information which is confidential and/or
privileged and is intended for the named addressee(s) only. If you are
not the intended recipient, you must not copy, distribute, disclose,
otherwise use the information or take any action in reliance on it. If
you have received this message in error, please notify sender
immediately and destroy any copies whether in physical or electronic
record.

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



From avt-bounces@ietf.org Tue Apr 03 07:15:42 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYgyB-00018j-Ls; Tue, 03 Apr 2007 07:14:35 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYgyA-00014c-59
	for avt@ietf.org; Tue, 03 Apr 2007 07:14:34 -0400
Received: from mee06.mee.com ([194.130.244.68])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYgy8-0003xW-Kd
	for avt@ietf.org; Tue, 03 Apr 2007 07:14:34 -0400
Received: from meemgw02 ([10.226.1.24] helo=meemgw02.mee.com)
	by mee06.mee.com with esmtp (Exim 4.43) id 1HYgy8-0004ju-19
	for avt@ietf.org; Tue, 03 Apr 2007 12:14:32 +0100
Received: from meetvd02 (meetvd02.diamondlink.com [10.226.1.23])
	by meemgw02.mee.com (8.11.6/8.11.6) with SMTP id l33BEV253051
	for <avt@ietf.org>; Tue, 3 Apr 2007 12:14:31 +0100 (BST)
Received: From einstein.vil.ite.mee.com ([10.226.210.23]) by meetvd02
	(WebShield SMTP v4.5 MR1a P0803.345); 
	id 1175597990890; Tue, 3 Apr 2007 11:59:50 +0100
Received: from [10.226.210.105]
	by einstein.vil.ite.mee.com with esmtp (Exim 4.62)
	(envelope-from <nikola.sprljan@vil.ite.mee.com>)
	id 1HYgy0-00030V-6O; Tue, 03 Apr 2007 12:14:25 +0100
Message-ID: <46123710.1070805@vil.ite.mee.com>
Date: Tue, 03 Apr 2007 12:14:24 +0100
From: Nikola Sprljan <nikola.sprljan@vil.ite.mee.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: "Bhattacharya, Abhijit \(Abhijit\)" <abhattacharya@alcatel-lucent.com>
Subject: Re: [AVT] Confusion regarding RTP
References: <B6472FAD86FE9C4A8F1870BA8C8910EBB37B77@gnvasmail1a.gva.ebu.ch>	<20070402121602.F89535@hsa>	<BF2A009791C9E644A1E6344619C5698A1ABED7@INEXC1U02.in.lucent.com>	<4612154C.3090205@ericsson.com>	<BF2A009791C9E644A1E6344619C5698A1ABEFB@INEXC1U02.in.lucent.com>
	<4612188E.90507@ericsson.com> <46122B93.4050507@vil.ite.mee.com>
	<BF2A009791C9E644A1E6344619C5698A1ABF60@INEXC1U02.in.lucent.com>
In-Reply-To: <BF2A009791C9E644A1E6344619C5698A1ABF60@INEXC1U02.in.lucent.com>
X-Enigmail-Version: 0.94.2.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: -5.4 (-----)
X-Spam-Report: VI-Lab's spam scanner has examined this email on server
	"einstein.vil.ite.mee.com". The results of the scan are shown below.
	If you have any questions, see the administrator of that system.
	Is Spam? No  (-5.4 points, 3.5 required)
	pts rule name              description
	---- ----------------------
	--------------------------------------------------
	-1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP
	-3.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1%
	[score: 0.0000]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87
Cc: avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

Bhattacharya, Abhijit (Abhijit) wrote:
> Hi all,
> 
> Thanks for your inputs. Actually I just now attempted in both Solaris
> and Linux the same code as the following 
...
> 
> In Linux the answer is :-
> 
> THE value is 1
> 
> And in Solaris the answer is :-
> 
> THE value is 40 !!
> 
> Initially I was using Linux and since htons does not work within "a
> byte", I was confused. So the 1st element is considered MSB in Solaris
> and LSB in Linux.

My guess is that you are running Solaris on a SPARC architecure
(big-endian), while your Linux is on a x86 based machine
(little-endian). Remember, it's the processor that counts here, not the
OS. Also, some new SPARCs have switchable endianness.

And I forgot to mention: my initial assumption was that you were
compiling this on a x86 or some other little-endian processor, due to
observations you made in your second e-mail.

Cheers,

Nikola


> -----Original Message-----
> From: Nikola Sprljan [mailto:nikola.sprljan@vil.ite.mee.com] 
> Sent: Tuesday, April 03, 2007 3:55 PM
> To: Magnus Westerlund
> Cc: Bhattacharya, Abhijit (Abhijit); avt@ietf.org
> Subject: Re: [AVT] Confusion regarding RTP
> 
> Magnus Westerlund wrote:
>> Bhattacharya, Abhijit (Abhijit) skrev:
>>> Hi Magnus,
>>>
>>> Thanks for the information. Actually, the rtp_hdt_t structure in RFC 
>>> 3550 resulted in the confusion. Here version field is the 1st element
> 
>>> in the structure. So it becomes the LSB. Anyways, now its clear to
> me.
>> Your comment make me think you are misunderstanding how bit fields in 
>> C are defined? If one looks at the rtp_hdt_t:
>>
>>    typedef struct {
>>        unsigned int version:2;   /* protocol version */
>>        unsigned int p:1;         /* padding flag */
>>        unsigned int x:1;         /* header extension flag */
>>        unsigned int cc:4;        /* CSRC count */
>>        unsigned int m:1;         /* marker bit */
>>        unsigned int pt:7;        /* payload type */
>>        unsigned int seq:16;      /* sequence number */
>>        u_int32 ts;               /* timestamp */
>>        u_int32 ssrc;             /* synchronization source */
>>        u_int32 csrc[1];          /* optional CSRC list */
>>    } rtp_hdr_t;
>>
>> I can't understand why you think version is the LSB. Starting in the 
>> most significant 2 bits in the first byte write version. The next bit 
>> is p, then x, then 4 bits of CC in MSB to LSB. In the next byte there 
>> is first the marker bit (bit 9) and then 7 PT bits. Then you have the 
>> more significant first byte of the sequence number, followed by the 
>> less significant byte.
> 
> It think the problem that Abhijit is encountering is a common one with C
> bit-fields - the order of bits will depend on endianess of processor
> this is compiled on. Since x86 processors use the little-endian format,
> you'll have to manually reverse the order of fields for each byte in the
> structure. You'll also have to do conversions from/to network byte order
> (which is big-endian) by using ntohl and htonl (and other) functions.
> 
> Also, for data to be aligned properly, for some versions of the MS
> compiler you have to specify correct packing when in a default Debug
> mode:
> #pragma pack(1)
> , otherwise casting pointers to/from structures including rtp_hdr_t
> struct would not work.
> 
> Kind regards,
> 
> Nikola Sprljan
> 
> --
> *Dr. Nikola Sprljan*
> /Research Engineer/
> *MITSUBISHI ELECTRIC INFORMATION TECHNOLOGY CENTRE EUROPE B.V* *VISUAL
> INFORMATION LABORATORY* 20, Frederick Sanger Road The Surrey Research
> Park Guildford, Surrey GU2 7YD /UK Registered Branch BR 003158/ *DDI
> Telephone: +44 1483 885538*
> Tel: +44 1483 885800   Fax: +44 1483 579107


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



From avt-bounces@ietf.org Tue Apr 03 07:24:42 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYh71-0008V0-Fq; Tue, 03 Apr 2007 07:23:43 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYh70-0008Ue-5n
	for avt@ietf.org; Tue, 03 Apr 2007 07:23:42 -0400
Received: from ihemail4.lucent.com ([135.245.0.39])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYh6y-0006CD-Ko
	for avt@ietf.org; Tue, 03 Apr 2007 07:23:42 -0400
Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1])
	by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l33BNZun006746;
	Tue, 3 Apr 2007 06:23:39 -0500 (CDT)
Received: from inexp01.in.lucent.com ([135.254.223.65]) by
	ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 3 Apr 2007 06:23:21 -0500
Received: from INEXC1U02.in.lucent.com ([135.254.223.25]) by
	inexp01.in.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 3 Apr 2007 16:53:14 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [AVT] Confusion regarding RTP
Date: Tue, 3 Apr 2007 16:53:13 +0530
Message-ID: <BF2A009791C9E644A1E6344619C5698A1ABF74@INEXC1U02.in.lucent.com>
In-Reply-To: <46123710.1070805@vil.ite.mee.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [AVT] Confusion regarding RTP
Thread-Index: Acd14XgvcoA82ml/QnaXAqGXu0xJDQAANErQ
References: <B6472FAD86FE9C4A8F1870BA8C8910EBB37B77@gnvasmail1a.gva.ebu.ch>	<20070402121602.F89535@hsa>	<BF2A009791C9E644A1E6344619C5698A1ABED7@INEXC1U02.in.lucent.com>	<4612154C.3090205@ericsson.com>	<BF2A009791C9E644A1E6344619C5698A1ABEFB@INEXC1U02.in.lucent.com>
	<4612188E.90507@ericsson.com> <46122B93.4050507@vil.ite.mee.com>
	<BF2A009791C9E644A1E6344619C5698A1ABF60@INEXC1U02.in.lucent.com>
	<46123710.1070805@vil.ite.mee.com>
From: "Bhattacharya, Abhijit \(Abhijit\)" <abhattacharya@alcatel-lucent.com>
To: "Nikola Sprljan" <nikola.sprljan@vil.ite.mee.com>
X-OriginalArrivalTime: 03 Apr 2007 11:23:14.0767 (UTC)
	FILETIME=[787A05F0:01C775E2]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243
Cc: avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

Hi Nikola,

"My guess is that you are running Solaris on a SPARC architecure
(big-endian), while your Linux is on a x86 based machine
(little-endian). Remember, it's the processor that counts here, not the
OS. Also, some new SPARCs have switchable endianness."

Yes your guess is absolutely right.

Thanks and regards,
Abhijit

-----Original Message-----
From: Nikola Sprljan [mailto:nikola.sprljan@vil.ite.mee.com]=20
Sent: Tuesday, April 03, 2007 4:44 PM
To: Bhattacharya, Abhijit (Abhijit)
Cc: avt@ietf.org
Subject: Re: [AVT] Confusion regarding RTP

Bhattacharya, Abhijit (Abhijit) wrote:
> Hi all,
>=20
> Thanks for your inputs. Actually I just now attempted in both Solaris=20
> and Linux the same code as the following
...
>=20
> In Linux the answer is :-
>=20
> THE value is 1
>=20
> And in Solaris the answer is :-
>=20
> THE value is 40 !!
>=20
> Initially I was using Linux and since htons does not work within "a=20
> byte", I was confused. So the 1st element is considered MSB in Solaris

> and LSB in Linux.

My guess is that you are running Solaris on a SPARC architecure
(big-endian), while your Linux is on a x86 based machine
(little-endian). Remember, it's the processor that counts here, not the
OS. Also, some new SPARCs have switchable endianness.

And I forgot to mention: my initial assumption was that you were
compiling this on a x86 or some other little-endian processor, due to
observations you made in your second e-mail.

Cheers,

Nikola


> -----Original Message-----
> From: Nikola Sprljan [mailto:nikola.sprljan@vil.ite.mee.com]
> Sent: Tuesday, April 03, 2007 3:55 PM
> To: Magnus Westerlund
> Cc: Bhattacharya, Abhijit (Abhijit); avt@ietf.org
> Subject: Re: [AVT] Confusion regarding RTP
>=20
> Magnus Westerlund wrote:
>> Bhattacharya, Abhijit (Abhijit) skrev:
>>> Hi Magnus,
>>>
>>> Thanks for the information. Actually, the rtp_hdt_t structure in RFC

>>> 3550 resulted in the confusion. Here version field is the 1st=20
>>> element
>=20
>>> in the structure. So it becomes the LSB. Anyways, now its clear to
> me.
>> Your comment make me think you are misunderstanding how bit fields in

>> C are defined? If one looks at the rtp_hdt_t:
>>
>>    typedef struct {
>>        unsigned int version:2;   /* protocol version */
>>        unsigned int p:1;         /* padding flag */
>>        unsigned int x:1;         /* header extension flag */
>>        unsigned int cc:4;        /* CSRC count */
>>        unsigned int m:1;         /* marker bit */
>>        unsigned int pt:7;        /* payload type */
>>        unsigned int seq:16;      /* sequence number */
>>        u_int32 ts;               /* timestamp */
>>        u_int32 ssrc;             /* synchronization source */
>>        u_int32 csrc[1];          /* optional CSRC list */
>>    } rtp_hdr_t;
>>
>> I can't understand why you think version is the LSB. Starting in the=20
>> most significant 2 bits in the first byte write version. The next bit

>> is p, then x, then 4 bits of CC in MSB to LSB. In the next byte there

>> is first the marker bit (bit 9) and then 7 PT bits. Then you have the

>> more significant first byte of the sequence number, followed by the=20
>> less significant byte.
>=20
> It think the problem that Abhijit is encountering is a common one with

> C bit-fields - the order of bits will depend on endianess of processor

> this is compiled on. Since x86 processors use the little-endian=20
> format, you'll have to manually reverse the order of fields for each=20
> byte in the structure. You'll also have to do conversions from/to=20
> network byte order (which is big-endian) by using ntohl and htonl (and
other) functions.
>=20
> Also, for data to be aligned properly, for some versions of the MS=20
> compiler you have to specify correct packing when in a default Debug
> mode:
> #pragma pack(1)
> , otherwise casting pointers to/from structures including rtp_hdr_t=20
> struct would not work.
>=20
> Kind regards,
>=20
> Nikola Sprljan
>=20
> --
> *Dr. Nikola Sprljan*
> /Research Engineer/
> *MITSUBISHI ELECTRIC INFORMATION TECHNOLOGY CENTRE EUROPE B.V* *VISUAL

> INFORMATION LABORATORY* 20, Frederick Sanger Road The Surrey Research=20
> Park Guildford, Surrey GU2 7YD /UK Registered Branch BR 003158/ *DDI
> Telephone: +44 1483 885538*
> Tel: +44 1483 885800   Fax: +44 1483 579107


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



From avt-bounces@ietf.org Tue Apr 03 11:16:36 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYkjB-000689-DA; Tue, 03 Apr 2007 11:15:21 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYkj9-00067g-O9
	for avt@ietf.org; Tue, 03 Apr 2007 11:15:19 -0400
Received: from ihemail1.lucent.com ([135.245.0.33])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYkfn-0002VS-F0
	for avt@ietf.org; Tue, 03 Apr 2007 11:12:21 -0400
Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1])
	by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l33FBSTU011083;
	Tue, 3 Apr 2007 10:11:50 -0500 (CDT)
Received: from inexp02.in.lucent.com ([135.254.223.66]) by
	ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 3 Apr 2007 10:11:37 -0500
Received: from INEXC1U02.in.lucent.com ([135.254.223.25]) by
	inexp02.in.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 3 Apr 2007 20:41:32 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [AVT] Confusion regarding RTP
Date: Tue, 3 Apr 2007 20:41:31 +0530
Message-ID: <BF2A009791C9E644A1E6344619C5698A1ABFD8@INEXC1U02.in.lucent.com>
In-Reply-To: <46123710.1070805@vil.ite.mee.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [AVT] Confusion regarding RTP
Thread-Index: Acd14XgvcoA82ml/QnaXAqGXu0xJDQAHoDew
References: <B6472FAD86FE9C4A8F1870BA8C8910EBB37B77@gnvasmail1a.gva.ebu.ch>	<20070402121602.F89535@hsa>	<BF2A009791C9E644A1E6344619C5698A1ABED7@INEXC1U02.in.lucent.com>	<4612154C.3090205@ericsson.com>	<BF2A009791C9E644A1E6344619C5698A1ABEFB@INEXC1U02.in.lucent.com>
	<4612188E.90507@ericsson.com> <46122B93.4050507@vil.ite.mee.com>
	<BF2A009791C9E644A1E6344619C5698A1ABF60@INEXC1U02.in.lucent.com>
	<46123710.1070805@vil.ite.mee.com>
From: "Bhattacharya, Abhijit \(Abhijit\)" <abhattacharya@alcatel-lucent.com>
To: "Nikola Sprljan" <nikola.sprljan@vil.ite.mee.com>
X-OriginalArrivalTime: 03 Apr 2007 15:11:32.0278 (UTC)
	FILETIME=[5CD45560:01C77602]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c
Cc: avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

Hi all,

Sorry troubling you all again.=20

Suppose I wish to send EVRC rate 1/2 packets (ptime 120, maxptime 120,
hence no variation in rates and no interleaving) what will be the value
of "Mode (mmm)" field in RTP payload header. Will it be 4 (since all
packets are 1/2) or 0 ?


I feel that since Rate 1 packets are not being transmitted so the
fraction of Rate 1 packets being Rate 2 does not arise. So this field
can be ignored. Is my thinking right?

Thanks and regards,
Abhijit

-----Original Message-----
From: Nikola Sprljan [mailto:nikola.sprljan@vil.ite.mee.com]=20
Sent: Tuesday, April 03, 2007 4:44 PM
To: Bhattacharya, Abhijit (Abhijit)
Cc: avt@ietf.org
Subject: Re: [AVT] Confusion regarding RTP

Bhattacharya, Abhijit (Abhijit) wrote:
> Hi all,
>=20
> Thanks for your inputs. Actually I just now attempted in both Solaris=20
> and Linux the same code as the following
...
>=20
> In Linux the answer is :-
>=20
> THE value is 1
>=20
> And in Solaris the answer is :-
>=20
> THE value is 40 !!
>=20
> Initially I was using Linux and since htons does not work within "a=20
> byte", I was confused. So the 1st element is considered MSB in Solaris

> and LSB in Linux.

My guess is that you are running Solaris on a SPARC architecure
(big-endian), while your Linux is on a x86 based machine
(little-endian). Remember, it's the processor that counts here, not the
OS. Also, some new SPARCs have switchable endianness.

And I forgot to mention: my initial assumption was that you were
compiling this on a x86 or some other little-endian processor, due to
observations you made in your second e-mail.

Cheers,

Nikola


> -----Original Message-----
> From: Nikola Sprljan [mailto:nikola.sprljan@vil.ite.mee.com]
> Sent: Tuesday, April 03, 2007 3:55 PM
> To: Magnus Westerlund
> Cc: Bhattacharya, Abhijit (Abhijit); avt@ietf.org
> Subject: Re: [AVT] Confusion regarding RTP
>=20
> Magnus Westerlund wrote:
>> Bhattacharya, Abhijit (Abhijit) skrev:
>>> Hi Magnus,
>>>
>>> Thanks for the information. Actually, the rtp_hdt_t structure in RFC

>>> 3550 resulted in the confusion. Here version field is the 1st=20
>>> element
>=20
>>> in the structure. So it becomes the LSB. Anyways, now its clear to
> me.
>> Your comment make me think you are misunderstanding how bit fields in

>> C are defined? If one looks at the rtp_hdt_t:
>>
>>    typedef struct {
>>        unsigned int version:2;   /* protocol version */
>>        unsigned int p:1;         /* padding flag */
>>        unsigned int x:1;         /* header extension flag */
>>        unsigned int cc:4;        /* CSRC count */
>>        unsigned int m:1;         /* marker bit */
>>        unsigned int pt:7;        /* payload type */
>>        unsigned int seq:16;      /* sequence number */
>>        u_int32 ts;               /* timestamp */
>>        u_int32 ssrc;             /* synchronization source */
>>        u_int32 csrc[1];          /* optional CSRC list */
>>    } rtp_hdr_t;
>>
>> I can't understand why you think version is the LSB. Starting in the=20
>> most significant 2 bits in the first byte write version. The next bit

>> is p, then x, then 4 bits of CC in MSB to LSB. In the next byte there

>> is first the marker bit (bit 9) and then 7 PT bits. Then you have the

>> more significant first byte of the sequence number, followed by the=20
>> less significant byte.
>=20
> It think the problem that Abhijit is encountering is a common one with

> C bit-fields - the order of bits will depend on endianess of processor

> this is compiled on. Since x86 processors use the little-endian=20
> format, you'll have to manually reverse the order of fields for each=20
> byte in the structure. You'll also have to do conversions from/to=20
> network byte order (which is big-endian) by using ntohl and htonl (and
other) functions.
>=20
> Also, for data to be aligned properly, for some versions of the MS=20
> compiler you have to specify correct packing when in a default Debug
> mode:
> #pragma pack(1)
> , otherwise casting pointers to/from structures including rtp_hdr_t=20
> struct would not work.
>=20
> Kind regards,
>=20
> Nikola Sprljan
>=20
> --
> *Dr. Nikola Sprljan*
> /Research Engineer/
> *MITSUBISHI ELECTRIC INFORMATION TECHNOLOGY CENTRE EUROPE B.V* *VISUAL

> INFORMATION LABORATORY* 20, Frederick Sanger Road The Surrey Research=20
> Park Guildford, Surrey GU2 7YD /UK Registered Branch BR 003158/ *DDI
> Telephone: +44 1483 885538*
> Tel: +44 1483 885800   Fax: +44 1483 579107


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



From avt-bounces@ietf.org Tue Apr 03 14:15:22 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYnWK-0007Ps-25; Tue, 03 Apr 2007 14:14:16 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYnWI-0007PA-OP
	for avt@ietf.org; Tue, 03 Apr 2007 14:14:14 -0400
Received: from ithilien.qualcomm.com ([129.46.51.59])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYnW7-0000qq-Sm
	for avt@ietf.org; Tue, 03 Apr 2007 14:14:14 -0400
Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150])
	by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	l33IDxah020974
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 3 Apr 2007 11:13:59 -0700
Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com
	[172.30.36.175])
	by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id
	l33IDw2W014766; Tue, 3 Apr 2007 11:13:59 -0700
Received: from NAEX01.qualcomm.com ([129.46.51.60]) by
	sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 3 Apr 2007 11:13:58 -0700
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Question on EVRC fixed rate operation - was [AVT] Confusion
	regarding RTP
Date: Tue, 3 Apr 2007 11:13:55 -0700
Message-ID: <2CA3E1B6CEC064449CAA7D0FAB46079B02AF262A@NAEX01.na.qualcomm.com>
In-Reply-To: <BF2A009791C9E644A1E6344619C5698A1ABFD8@INEXC1U02.in.lucent.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Question on EVRC fixed rate operation - was [AVT] Confusion
	regarding RTP
Thread-Index: Acd14XgvcoA82ml/QnaXAqGXu0xJDQAHoDewAAa6MSA=
References: <B6472FAD86FE9C4A8F1870BA8C8910EBB37B77@gnvasmail1a.gva.ebu.ch>	<20070402121602.F89535@hsa>	<BF2A009791C9E644A1E6344619C5698A1ABED7@INEXC1U02.in.lucent.com>	<4612154C.3090205@ericsson.com>	<BF2A009791C9E644A1E6344619C5698A1ABEFB@INEXC1U02.in.lucent.com><4612188E.90507@ericsson.com>
	<46122B93.4050507@vil.ite.mee.com><BF2A009791C9E644A1E6344619C5698A1ABF60@INEXC1U02.in.lucent.com><46123710.1070805@vil.ite.mee.com>
	<BF2A009791C9E644A1E6344619C5698A1ABFD8@INEXC1U02.in.lucent.com>
From: "Desineni, Harikishan" <hdesinen@qualcomm.com>
To: "Bhattacharya, Abhijit \(Abhijit\)" <abhattacharya@alcatel-lucent.com>
X-OriginalArrivalTime: 03 Apr 2007 18:13:58.0462 (UTC)
	FILETIME=[D94375E0:01C7761B]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5
Cc: avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

"Compact bundle format" is probably the correct payload format for what
you are trying to do. The corresponding MIME type is EVRC1. See section
4, RFC 4788 for more details.

-Hari

> -----Original Message-----
> From: Bhattacharya, Abhijit (Abhijit) [mailto:abhattacharya@alcatel-
> lucent.com]
> Sent: Tuesday, April 03, 2007 8:12 AM
> To: Nikola Sprljan
> Cc: avt@ietf.org
> Subject: RE: [AVT] Confusion regarding RTP
>=20
> Hi all,
>=20
> Sorry troubling you all again.
>=20
> Suppose I wish to send EVRC rate 1/2 packets (ptime 120, maxptime 120,
> hence no variation in rates and no interleaving) what will be the
value
> of "Mode (mmm)" field in RTP payload header. Will it be 4 (since all
> packets are 1/2) or 0 ?
>=20
>=20
> I feel that since Rate 1 packets are not being transmitted so the
> fraction of Rate 1 packets being Rate 2 does not arise. So this field
> can be ignored. Is my thinking right?
>=20
> Thanks and regards,
> Abhijit
>=20
> -----Original Message-----
> From: Nikola Sprljan [mailto:nikola.sprljan@vil.ite.mee.com]
> Sent: Tuesday, April 03, 2007 4:44 PM
> To: Bhattacharya, Abhijit (Abhijit)
> Cc: avt@ietf.org
> Subject: Re: [AVT] Confusion regarding RTP
>=20
> Bhattacharya, Abhijit (Abhijit) wrote:
> > Hi all,
> >
> > Thanks for your inputs. Actually I just now attempted in both
Solaris
> > and Linux the same code as the following
> ...
> >
> > In Linux the answer is :-
> >
> > THE value is 1
> >
> > And in Solaris the answer is :-
> >
> > THE value is 40 !!
> >
> > Initially I was using Linux and since htons does not work within "a
> > byte", I was confused. So the 1st element is considered MSB in
Solaris
>=20
> > and LSB in Linux.
>=20
> My guess is that you are running Solaris on a SPARC architecure
> (big-endian), while your Linux is on a x86 based machine
> (little-endian). Remember, it's the processor that counts here, not
the
> OS. Also, some new SPARCs have switchable endianness.
>=20
> And I forgot to mention: my initial assumption was that you were
> compiling this on a x86 or some other little-endian processor, due to
> observations you made in your second e-mail.
>=20
> Cheers,
>=20
> Nikola
>=20
>=20
> > -----Original Message-----
> > From: Nikola Sprljan [mailto:nikola.sprljan@vil.ite.mee.com]
> > Sent: Tuesday, April 03, 2007 3:55 PM
> > To: Magnus Westerlund
> > Cc: Bhattacharya, Abhijit (Abhijit); avt@ietf.org
> > Subject: Re: [AVT] Confusion regarding RTP
> >
> > Magnus Westerlund wrote:
> >> Bhattacharya, Abhijit (Abhijit) skrev:
> >>> Hi Magnus,
> >>>
> >>> Thanks for the information. Actually, the rtp_hdt_t structure in
RFC
>=20
> >>> 3550 resulted in the confusion. Here version field is the 1st
> >>> element
> >
> >>> in the structure. So it becomes the LSB. Anyways, now its clear to
> > me.
> >> Your comment make me think you are misunderstanding how bit fields
in
>=20
> >> C are defined? If one looks at the rtp_hdt_t:
> >>
> >>    typedef struct {
> >>        unsigned int version:2;   /* protocol version */
> >>        unsigned int p:1;         /* padding flag */
> >>        unsigned int x:1;         /* header extension flag */
> >>        unsigned int cc:4;        /* CSRC count */
> >>        unsigned int m:1;         /* marker bit */
> >>        unsigned int pt:7;        /* payload type */
> >>        unsigned int seq:16;      /* sequence number */
> >>        u_int32 ts;               /* timestamp */
> >>        u_int32 ssrc;             /* synchronization source */
> >>        u_int32 csrc[1];          /* optional CSRC list */
> >>    } rtp_hdr_t;
> >>
> >> I can't understand why you think version is the LSB. Starting in
the
> >> most significant 2 bits in the first byte write version. The next
bit
>=20
> >> is p, then x, then 4 bits of CC in MSB to LSB. In the next byte
there
>=20
> >> is first the marker bit (bit 9) and then 7 PT bits. Then you have
the
>=20
> >> more significant first byte of the sequence number, followed by the
> >> less significant byte.
> >
> > It think the problem that Abhijit is encountering is a common one
with
>=20
> > C bit-fields - the order of bits will depend on endianess of
processor
>=20
> > this is compiled on. Since x86 processors use the little-endian
> > format, you'll have to manually reverse the order of fields for each
> > byte in the structure. You'll also have to do conversions from/to
> > network byte order (which is big-endian) by using ntohl and htonl
(and
> other) functions.
> >
> > Also, for data to be aligned properly, for some versions of the MS
> > compiler you have to specify correct packing when in a default Debug
> > mode:
> > #pragma pack(1)
> > , otherwise casting pointers to/from structures including rtp_hdr_t
> > struct would not work.
> >
> > Kind regards,
> >
> > Nikola Sprljan
> >
> > --
> > *Dr. Nikola Sprljan*
> > /Research Engineer/
> > *MITSUBISHI ELECTRIC INFORMATION TECHNOLOGY CENTRE EUROPE B.V*
*VISUAL
>=20
> > INFORMATION LABORATORY* 20, Frederick Sanger Road The Surrey
Research
> > Park Guildford, Surrey GU2 7YD /UK Registered Branch BR 003158/ *DDI
> > Telephone: +44 1483 885538*
> > Tel: +44 1483 885800   Fax: +44 1483 579107
>=20
>=20
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www1.ietf.org/mailman/listinfo/avt

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



From avt-bounces@ietf.org Wed Apr 04 15:04:20 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZAki-0000kk-OA; Wed, 04 Apr 2007 15:02:40 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZAkh-0000if-2z
	for avt@ietf.org; Wed, 04 Apr 2007 15:02:39 -0400
Received: from fw.polycom.co.il ([212.179.41.2]
	helo=isrexch01.israel.polycom.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZAkf-0000p0-Nf
	for avt@ietf.org; Wed, 04 Apr 2007 15:02:39 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 4 Apr 2007 22:02:54 +0300
Message-ID: <144ED8561CE90C41A3E5908EDECE315C0472EB0C@IsrExch01.israel.polycom.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: New revisions for existing drafts
Thread-Index: Acd269nUF9W3R9/pTo6MrU7m9HgpPA==
From: "Even, Roni" <roni.even@polycom.co.il>
To: <avt@ietf.org>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014
Subject: [AVT] New revisions for existing drafts
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

H,
Since we are now in a process of updating drafts that were not active =
for some time please verify that they are OK using the idnits tool =
http://tools.ietf.org/tools/idnits/

Look at the copyright notice and any other errors you may encounter

Thanks
Roni Even

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



From avt-bounces@ietf.org Thu Apr 05 09:44:11 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZSEj-00005x-2m; Thu, 05 Apr 2007 09:42:49 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZSEh-00005p-Au
	for avt@ietf.org; Thu, 05 Apr 2007 09:42:47 -0400
Received: from ug-out-1314.google.com ([66.249.92.172])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZSEg-00011T-0q
	for avt@ietf.org; Thu, 05 Apr 2007 09:42:47 -0400
Received: by ug-out-1314.google.com with SMTP id 72so935211ugd
	for <avt@ietf.org>; Thu, 05 Apr 2007 06:42:45 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta;
	h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
	b=IqmrURoXRH7J6ygj43rZuk4nuAsS8s/B5hBDwoqix/IiQUYdh864qqdF/StWCtRHibj7fH1UVcugsJ9VgzB2yIuEOrkyMnpD2s3t/1iBSjZ9PML02X6sifzG9PTFP2M0eHO1Qc9tL0g8GBs9vNoP3a9QvS4QJyxrFlgftCRqyi8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
	b=CcOlsr0TWwRHrQfDEsZI1yrF1LnWax2Kjx02xKPj/Tuic2K2d2r8yUz+ECNGYk/77GSJLAccEDJitLk8YTN40Nf1VdwDxXBWJcUwOe7B9nqHHVpXwJ5nKUiC2rxItXsTjR0mn9YNmFAWT0crNzqw6CwJW1N1xC5zkRYT3udxqFg=
Received: by 10.78.201.2 with SMTP id y2mr295957huf.1175780564781;
	Thu, 05 Apr 2007 06:42:44 -0700 (PDT)
Received: by 10.78.165.14 with HTTP; Thu, 5 Apr 2007 06:42:44 -0700 (PDT)
Message-ID: <4e5a3720704050642p5f76ba0ek95e97063a47f52c6@mail.gmail.com>
Date: Thu, 5 Apr 2007 16:42:44 +0300
From: "Murat Artun" <artunmurat@gmail.com>
To: avt@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Subject: [AVT] default packetization interval for pcmu, pcma and iLBC
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

Hello,

I want to ask this for confirmation purposes.

As I read from RFC 3551 pg 10 default packetization interval of 20 ms.
So I understand that for PCMU and PCMA  frames should defaulted to be
20 ms (160 samples). Of course this is valid for other codec types
specified to be static in RF 3551.

However, as it was discussed in the below thread in avt default
packetization interval is 30 ms for iLBC:

http://www1.ietf.org/mail-archive/web/avt/current/msg05212.html

So, can we say that for an VoIP application to be standard it should
follow these packetization interval specifications?

-- 
M u r at  A r t u n, MSc.
   Software Engineer

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



From avt-bounces@ietf.org Thu Apr 05 10:16:58 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZSl1-0004no-AA; Thu, 05 Apr 2007 10:16:11 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZSl0-0004nj-Iz
	for avt@ietf.org; Thu, 05 Apr 2007 10:16:10 -0400
Received: from pr-66-150-46-254.wgate.com ([66.150.46.254]
	helo=exchange1.wgate.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HZSkz-0005uV-9p for avt@ietf.org; Thu, 05 Apr 2007 10:16:10 -0400
Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with
	Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Apr 2007 10:16:04 -0400
To: "Murat Artun" <artunmurat@gmail.com>
Subject: Re: [AVT] default packetization interval for pcmu, pcma and iLBC
References: <4e5a3720704050642p5f76ba0ek95e97063a47f52c6@mail.gmail.com>
From: Randell Jesup <rjesup@wgate.com>
Date: Thu, 05 Apr 2007 10:16:04 -0400
In-Reply-To: <4e5a3720704050642p5f76ba0ek95e97063a47f52c6@mail.gmail.com>
	(Murat Artun's message of "Thu, 5 Apr 2007 16:42:44 +0300")
Message-ID: <ybuzm5mdhzv.fsf@jesup.eng.wgate.com>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-OriginalArrivalTime: 05 Apr 2007 14:16:04.0858 (UTC)
	FILETIME=[F25BD5A0:01C7778C]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Cc: avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Randell Jesup <rjesup@wgate.com>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

"Murat Artun" <artunmurat@gmail.com> writes:
>I want to ask this for confirmation purposes.
>
>As I read from RFC 3551 pg 10 default packetization interval of 20 ms.
>So I understand that for PCMU and PCMA  frames should defaulted to be
>20 ms (160 samples). Of course this is valid for other codec types
>specified to be static in RF 3551.

I think you've over-stated what RFC 3551 says:

   The following recommendations are default operating parameters.
   Applications SHOULD be prepared to handle other values.  The ranges
   given are meant to give guidance to application writers, allowing a
   set of applications conforming to these guidelines to interoperate
   without additional negotiation.  These guidelines are not intended to
   restrict operating parameters for applications that can negotiate a
   set of interoperable parameters, e.g., through a conference control
   protocol.

   For packetized audio, the default packetization interval SHOULD have
   a duration of 20 ms or one frame, whichever is longer, unless
   otherwise noted in Table 1 (column "ms/packet").  The packetization
   interval determines the minimum end-to-end delay; longer packets
   introduce less header overhead but higher delay and make packet loss
   more noticeable.  For non-interactive applications such as lectures
   or for links with severe bandwidth constraints, a higher
   packetization delay MAY be used.  A receiver SHOULD accept packets
   representing between 0 and 200 ms of audio data.  (For framed audio
   encodings, a receiver SHOULD accept packets with a number of frames
   equal to 200 ms divided by the frame duration, rounded up.)  This
   restriction allows reasonable buffer sizing for the receiver.

>However, as it was discussed in the below thread in avt default
>packetization interval is 30 ms for iLBC:
>
>http://www1.ietf.org/mail-archive/web/avt/current/msg05212.html

Sure, because the RTP packetization RFC for iLBC says that unless you
specify (and agree) otherwise via a=fmtp, the frame interval for iLBC is 30
(note: NOT the packetization interval - you can have (almost) any integer
number of frames in a packet - see above.)  Also note that since iLBC can
have (and defaults to) a frame length of 30ms, it falls into the "20ms or
one frame, whichever is longer" case.

>So, can we say that for an VoIP application to be standard it should
>follow these packetization interval specifications?

See above.  Those are recommendations, and at strongest a "SHOULD".

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
rjesup@wgate.com
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)


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



From avt-bounces@ietf.org Thu Apr 05 15:51:15 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZXyS-0002eN-75; Thu, 05 Apr 2007 15:50:24 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZXyM-0002d4-Iv; Thu, 05 Apr 2007 15:50:18 -0400
Received: from ns0.neustar.com ([156.154.16.158])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HZXyD-0004dR-8C; Thu, 05 Apr 2007 15:50:18 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 6B902328F3;
	Thu,  5 Apr 2007 19:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1HZXy6-00045t-AX; Thu, 05 Apr 2007 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1HZXy6-00045t-AX@stiedprstage1.ietf.org>
Date: Thu, 05 Apr 2007 15:50:02 -0400
X-Spam-Score: -2.5 (--)
X-Scan-Signature: f66b12316365a3fe519e75911daf28a8
Cc: avt@ietf.org
Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-jpeg2000-beam-05.txt 
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

--NextPart

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

	Title		: Payload Format for JPEG 2000 Video: Extensions for Scalability and Main Header Recovery
	Author(s)	: A. Leung, et al.
	Filename	: draft-ietf-avt-rtp-jpeg2000-beam-05.txt
	Pages		: 33
	Date		: 2007-4-5
	
This memo describes extended uses for payload header in RFC document:
   "RTP Payload Format for JPEG 2000 Video Streams."  For better support
   of JPEG 2000 features such as scalability and includes a main header
   recovery method.

   This memo MUST be accompanied with a complete implementation of "RTP
   Payload Format for JPEG 2000 Video Streams."  That document is a
   complete description of the payload header and signaling, this
   document only describes additional processing for the payload header.
   There is an additional media type and SDP marker signaling for
   implementations of this document.

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

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

Content-Type: text/plain
Content-ID: <2007-4-5134428.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-avt-rtp-jpeg2000-beam-05.txt

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

Content-Type: text/plain
Content-ID: <2007-4-5134428.I-D@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--NextPart--




From avt-bounces@ietf.org Thu Apr 05 15:51:16 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZXyu-0003NA-86; Thu, 05 Apr 2007 15:50:52 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZXyd-0002jy-9v; Thu, 05 Apr 2007 15:50:35 -0400
Received: from ns3.neustar.com ([156.154.24.138])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1HZXya-0002qK-Tq; Thu, 05 Apr 2007 15:50:35 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 73BED17666;
	Thu,  5 Apr 2007 19:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1HZXy6-00045e-6w; Thu, 05 Apr 2007 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1HZXy6-00045e-6w@stiedprstage1.ietf.org>
Date: Thu, 05 Apr 2007 15:50:02 -0400
X-Spam-Score: -2.5 (--)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
Cc: avt@ietf.org
Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-evrc-wb-01.txt 
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

--NextPart

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

	Title		: RTP payload format for EVRC-WB codec and MIME updates for EVRC-B codec
	Author(s)	: H. Desineni, Q. Xie
	Filename	: draft-ietf-avt-rtp-evrc-wb-01.txt
	Pages		: 38
	Date		: 2007-4-5
	
This document specifies real-time transport protocol (RTP) payload
   formats to be used for the EVRC wideband codec (EVRC-WB) and updates
   the MIME registrations for EVRC-B codec.  Several media type
   registrations are included for EVRC-WB RTP payload formats.  In
   addition, a file format is specified for transport of EVRC-WB speech
   data in storage mode applications such as e-mail.

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

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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

ENCODING mime
FILE /internet-drafts/draft-ietf-avt-rtp-evrc-wb-01.txt

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

Content-Type: text/plain
Content-ID: <2007-4-5133650.I-D@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--NextPart--





From avt-bounces@ietf.org Thu Apr 05 15:51:20 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZXyL-0002cl-Jq; Thu, 05 Apr 2007 15:50:17 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZXyI-0002cJ-S7; Thu, 05 Apr 2007 15:50:14 -0400
Received: from ns0.neustar.com ([156.154.16.158])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HZXyA-0004dG-8K; Thu, 05 Apr 2007 15:50:14 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 29FFD328DC;
	Thu,  5 Apr 2007 19:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1HZXy6-00045J-29; Thu, 05 Apr 2007 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1HZXy6-00045J-29@stiedprstage1.ietf.org>
Date: Thu, 05 Apr 2007 15:50:02 -0400
X-Spam-Score: -2.5 (--)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Cc: avt@ietf.org
Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-no-op-01.txt 
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

--NextPart

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

	Title		: A No-Op Payload Format for RTP
	Author(s)	: F. Andreasen, et al.
	Filename	: draft-ietf-avt-rtp-no-op-01.txt
	Pages		: 13
	Date		: 2007-4-5
	
This document defines an no-op payload format for the Real-time
   Transport Protocol (RTP).  This packet is not played out by
   receivers.  It can be useful as a way to keep Network Address
   Translator (NAT) bindings and Firewall pinholes open.  Other uses are
   discussed in the document.

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

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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

ENCODING mime
FILE /internet-drafts/draft-ietf-avt-rtp-no-op-01.txt

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

Content-Type: text/plain
Content-ID: <2007-4-5130152.I-D@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--NextPart--




From avt-bounces@ietf.org Thu Apr 05 15:51:32 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZXz9-0003hS-Ko; Thu, 05 Apr 2007 15:51:07 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZXz8-0003h9-8R; Thu, 05 Apr 2007 15:51:06 -0400
Received: from ns3.neustar.com ([156.154.24.138])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1HZXz6-00037i-Uf; Thu, 05 Apr 2007 15:51:06 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 885AA17667;
	Thu,  5 Apr 2007 19:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1HZXy6-00045n-8w; Thu, 05 Apr 2007 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1HZXy6-00045n-8w@stiedprstage1.ietf.org>
Date: Thu, 05 Apr 2007 15:50:02 -0400
X-Spam-Score: -2.5 (--)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
Cc: avt@ietf.org
Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-jpeg2000-13.txt 
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

--NextPart

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

	Title		: RTP Payload Format for JPEG 2000 Video Streams
	Author(s)	: S. Futemma, et al.
	Filename	: draft-ietf-avt-rtp-jpeg2000-13.txt
	Pages		: 34
	Date		: 2007-4-5
	
This memo describes an RTP payload format for the ISO/IEC
   International Standard 15444-1 | ITU-T Rec. T.800, otherwise better
   known as: JPEG 2000.  JPEG 2000 features are considered in the design
   of this payload format.  JPEG 2000 is a truly scalable compression
   technology allowing applications to encode once and decode many
   different ways.  JPEG 2000 video stream is formed by extending from a
   single image to a series of JPEG 2000 images.

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

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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

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

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

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

Content-Type: text/plain
Content-ID: <2007-4-5134220.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-avt-rtp-jpeg2000-13.txt

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

Content-Type: text/plain
Content-ID: <2007-4-5134220.I-D@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--NextPart--




From avt-bounces@ietf.org Mon Apr 09 15:41:44 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HaziJ-0006zl-1j; Mon, 09 Apr 2007 15:39:43 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HaziG-0006zG-I1; Mon, 09 Apr 2007 15:39:40 -0400
Received: from [202.99.23.227] (helo=people.com.cn)
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1Hazi7-0003vL-Td; Mon, 09 Apr 2007 15:39:40 -0400
Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8)
	with SMTP id jmc461b0767; Tue, 10 Apr 2007 03:50:11 +0800
Received: from megatron.ietf.org([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8)
	with SMTP id jmdb4615bd51; Fri, 06 Apr 2007 09:49:27 +0800
Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC
	2.9.5.8) with SMTP id AISP action; Fri, 06 Apr 2007 09:49:27 +0800
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZXyT-0002ez-NW; Thu, 05 Apr 2007 15:50:25 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZXyM-0002d4-Iv; Thu, 05 Apr 2007 15:50:18 -0400
Received: from ns0.neustar.com ([156.154.16.158])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HZXyD-0004dR-8C; Thu, 05 Apr 2007 15:50:18 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 6B902328F3;
	Thu,  5 Apr 2007 19:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1HZXy6-00045t-AX; Thu, 05 Apr 2007 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1HZXy6-00045t-AX@stiedprstage1.ietf.org>
Date: Thu, 05 Apr 2007 15:50:02 -0400
X-Spam-Score: -2.5 (--)
X-Scan-Signature: f66b12316365a3fe519e75911daf28a8
X-BeenThere: i-d-announce@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Archive: <http://www1.ietf.org/pipermail/i-d-announce>
X-AIMC-AUTH: (null)
X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org
X-AIMC-AUTH: (null)
X-AIMC-MAILFROM: Internet-Drafts@ietf.org
X-Spam-Score: 2.2 (++)
X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4
Cc: avt@ietf.org
Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-jpeg2000-beam-05.txt 
X-BeenThere: avt@ietf.org
Reply-To: internet-drafts@ietf.org
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

--NextPart

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

	Title		: Payload Format for JPEG 2000 Video: Extensions for Scalability and Main Header Recovery
	Author(s)	: A. Leung, et al.
	Filename	: draft-ietf-avt-rtp-jpeg2000-beam-05.txt
	Pages		: 33
	Date		: 2007-4-5
	
This memo describes extended uses for payload header in RFC document:
   "RTP Payload Format for JPEG 2000 Video Streams."  For better support
   of JPEG 2000 features such as scalability and includes a main header
   recovery method.

   This memo MUST be accompanied with a complete implementation of "RTP
   Payload Format for JPEG 2000 Video Streams."  That document is a
   complete description of the payload header and signaling, this
   document only describes additional processing for the payload header.
   There is an additional media type and SDP marker signaling for
   implementations of this document.

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

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

Content-Type: text/plain
Content-ID: <2007-4-5134428.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-avt-rtp-jpeg2000-beam-05.txt

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

Content-Type: text/plain
Content-ID: <2007-4-5134428.I-D@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--NextPart--





From avt-bounces@ietf.org Mon Apr 09 15:51:24 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hazsq-0004hJ-Hj; Mon, 09 Apr 2007 15:50:36 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hazsn-0004f4-Dr; Mon, 09 Apr 2007 15:50:33 -0400
Received: from ns3.neustar.com ([156.154.24.138])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1Hazsm-0000aB-RX; Mon, 09 Apr 2007 15:50:33 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id A2E771760D;
	Mon,  9 Apr 2007 19:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1HazsI-0005bs-DH; Mon, 09 Apr 2007 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1HazsI-0005bs-DH@stiedprstage1.ietf.org>
Date: Mon, 09 Apr 2007 15:50:02 -0400
X-Spam-Score: -2.5 (--)
X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30
Cc: avt@ietf.org
Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-vorbis-02.txt 
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

--NextPart

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

	Title		: RTP Payload Format for Vorbis Encoded Audio
	Author(s)	: L. Barbato
	Filename	: draft-ietf-avt-rtp-vorbis-02.txt
	Pages		: 25
	Date		: 2007-4-9
	
This document describes an RTP payload format for transporting Vorbis
   encoded audio.  It details the RTP encapsulation mechanism for raw
   Vorbis data and details the delivery mechanisms for the decoder
   probability model, referred to as a codebook and other setup
   information.

   Also included within this memo are media type registrations, and the
   details necessary for the use of Vorbis with the Session Description
   Protocol (SDP).

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

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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

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

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

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

Content-Type: text/plain
Content-ID: <2007-4-9103731.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-avt-rtp-vorbis-02.txt

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

Content-Type: text/plain
Content-ID: <2007-4-9103731.I-D@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--NextPart--





From avt-bounces@ietf.org Mon Apr 09 17:11:30 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hb18A-0003q8-GZ; Mon, 09 Apr 2007 17:10:30 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hb188-0003o5-Ur; Mon, 09 Apr 2007 17:10:29 -0400
Received: from [202.99.23.227] (helo=people.com.cn)
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1Hb185-0000wc-85; Mon, 09 Apr 2007 17:10:28 -0400
Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8)
	with SMTP id jm17461b00f3; Tue, 10 Apr 2007 05:21:08 +0800
Received: from megatron.ietf.org([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8)
	with SMTP id jm1d461612da; Fri, 06 Apr 2007 11:11:22 +0800
Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC
	2.9.5.8) with SMTP id AISP action; Fri, 06 Apr 2007 11:11:22 +0800
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZXzB-0003hs-9K; Thu, 05 Apr 2007 15:51:09 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZXz8-0003h9-8R; Thu, 05 Apr 2007 15:51:06 -0400
Received: from ns3.neustar.com ([156.154.24.138])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1HZXz6-00037i-Uf; Thu, 05 Apr 2007 15:51:06 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 885AA17667;
	Thu,  5 Apr 2007 19:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1HZXy6-00045n-8w; Thu, 05 Apr 2007 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1HZXy6-00045n-8w@stiedprstage1.ietf.org>
Date: Thu, 05 Apr 2007 15:50:02 -0400
X-Spam-Score: -2.5 (--)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
X-BeenThere: i-d-announce@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Archive: <http://www1.ietf.org/pipermail/i-d-announce>
X-AIMC-AUTH: (null)
X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org
X-AIMC-AUTH: (null)
X-AIMC-MAILFROM: Internet-Drafts@ietf.org
X-Spam-Score: 2.2 (++)
X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8
Cc: avt@ietf.org
Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-jpeg2000-13.txt 
X-BeenThere: avt@ietf.org
Reply-To: internet-drafts@ietf.org
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

--NextPart

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

	Title		: RTP Payload Format for JPEG 2000 Video Streams
	Author(s)	: S. Futemma, et al.
	Filename	: draft-ietf-avt-rtp-jpeg2000-13.txt
	Pages		: 34
	Date		: 2007-4-5
	
This memo describes an RTP payload format for the ISO/IEC
   International Standard 15444-1 | ITU-T Rec. T.800, otherwise better
   known as: JPEG 2000.  JPEG 2000 features are considered in the design
   of this payload format.  JPEG 2000 is a truly scalable compression
   technology allowing applications to encode once and decode many
   different ways.  JPEG 2000 video stream is formed by extending from a
   single image to a series of JPEG 2000 images.

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

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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

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

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

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

Content-Type: text/plain
Content-ID: <2007-4-5134220.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-avt-rtp-jpeg2000-13.txt

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

Content-Type: text/plain
Content-ID: <2007-4-5134220.I-D@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--NextPart--





From avt-bounces@ietf.org Tue Apr 10 08:33:21 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HbFVi-0003QC-Lg; Tue, 10 Apr 2007 08:31:46 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HbFVh-0003OB-9p
	for avt@ietf.org; Tue, 10 Apr 2007 08:31:45 -0400
Received: from fw.polycom.co.il ([212.179.41.2]
	helo=isrexch01.israel.polycom.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbFVd-0002tf-70
	for avt@ietf.org; Tue, 10 Apr 2007 08:31:45 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [AVT] Working group last call
	fordraft-ietf-avt-rfc2833biscas-03.txt
Date: Tue, 10 Apr 2007 15:31:54 +0300
Message-ID: <144ED8561CE90C41A3E5908EDECE315C0472ED86@IsrExch01.israel.polycom.com>
In-Reply-To: <144ED8561CE90C41A3E5908EDECE315C04696792@IsrExch01.israel.polycom.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [AVT] Working group last call
	fordraft-ietf-avt-rfc2833biscas-03.txt
Thread-Index: AcdqUTX2qXmWQvitTw+UlZpbaWuvFARGavGA
From: "Even, Roni" <roni.even@polycom.co.il>
To: <avt@ietf.org>,
	"Tom-PT Taylor" <taylor@nortel.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 00134749b78ab2213964fc53d03de937
Cc: 
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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-Type: multipart/mixed; boundary="===============0612075401=="
Errors-To: avt-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0612075401==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C77B6C.39A50EAD"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C77B6C.39A50EAD
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Tom,

I finally finished reading the document.

In general it looks ready to me.

=20

1. I have some comments on the IANA consideration - section 5.

=20

I looked at =
http://www.iana.org/assignments/audio-telephone-event-registry

I suggest that you update the event code allocation since you now used =
144-159 and 206-211 from the general reserved and not the ones reserved =
for this draft.

Also add a note to IANA to use the RFC number of this specification as =
the relevant document.

=20

2. Section 2.7 discuss metering pulse event but does not refer to any =
document where it is specified.

=20

=20

Some typos:

=20

1.    section 2.3.2 fgrequencies - frequencies

2.     section 3 desribed - described

=20

=20

Roni Even

=20

=20

=20

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

> From: Even, Roni [mailto:roni.even@polycom.co.il]

> Sent: Monday, March 19, 2007 8:06 PM

> To: avt@ietf.org

> Subject: [AVT] Working group last call =
fordraft-ietf-avt-rfc2833biscas-

> 03.txt

>=20

> Hi,

>=20

> Announcing work group last call for =
draft-ietf-avt-rfc2833biscas-03.txt,

> Definition of Events For Channel-Oriented Telephony Signaling.

>=20

> The last call period will be three weeks expiring on Saturday, April =
7.

>=20

> Roni Even will be the PROTO Shepherd for this document

>=20

>=20

>=20

>=20

>=20

>=20

> _______________________________________________

> Audio/Video Transport Working Group

> avt@ietf.org

> https://www1.ietf.org/mailman/listinfo/avt


------_=_NextPart_001_01C77B6C.39A50EAD
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PersonName"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 77.95pt 72.0pt 77.95pt;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:45569188;
	mso-list-type:hybrid;
	mso-list-template-ids:887381812 67698703 67698713 67698715 67698703 =
67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
	{mso-level-tab-stop:36.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Tom,<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>I finally finished reading the =
document.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>In general it looks ready to me.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>1. I have some comments on the IANA consideration &#8211; =
section 5.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>I looked at <a
href=3D"http://www.iana.org/assignments/audio-telephone-event-registry">h=
ttp://www.iana.org/assignments/audio-telephone-event-registry</a><o:p></o=
:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>I suggest that you update the event code allocation since you =
now used 144-159
and 206-211 from the general reserved and not the ones reserved for this =
draft.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Also add a note to IANA to use the RFC number of this =
specification as
the relevant document.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>2. Section 2.7 discuss metering pulse event but does not refer =
to any
document where it is specified.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Some typos:<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText =
style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-list:
l0 level1 lfo1'><![if !supportLists]><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'><span style=3D'mso-list:Ignore'>1.<font =
size=3D1
face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><span dir=3DLTR><span =
lang=3DFR>section
2.3.2 fgrequencies &#8211; </span>frequencies<o:p></o:p></span></p>

<p class=3DMsoPlainText =
style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-list:
l0 level1 lfo1'><![if !supportLists]><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'><span style=3D'mso-list:Ignore'>2.<font =
size=3D1
face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><span dir=3DLTR>=A0<span =
lang=3DFR>section
3 desribed &#8211; </span>described<o:p></o:p></span></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DFR
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DFR
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Roni Even<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DFR
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DFR
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DFR
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; </span></font>-----Original Message-----</p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; </span></font>From: Even, Roni =
[mailto:roni.even@polycom.co.il]</p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; </span></font>Sent: Monday, March 19, 2007 8:06 PM</p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; </span></font>To: avt@ietf.org</p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; </span></font>Subject: [AVT] Working group last call
fordraft-ietf-avt-rfc2833biscas-</p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; </span></font>03.txt</p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; </span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; Hi,</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; </span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; Announcing work group last call for
draft-ietf-avt-rfc2833biscas-03.txt,</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; Definition of Events For Channel-Oriented Telephony =
Signaling.</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; </span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; The last call period will be three weeks expiring on =
Saturday,
April 7.</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; </span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; <st1:PersonName ProductID=3D"Roni Even" w:st=3D"on">Roni =
Even</st1:PersonName>
will be the PROTO Shepherd for this document</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; </span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; </span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; </span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; </span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; </span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; </span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; =
_______________________________________________</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; Audio/Video Transport Working Group</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; avt@ietf.org</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; =
https://www1.ietf.org/mailman/listinfo/avt</span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C77B6C.39A50EAD--


--===============0612075401==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0612075401==--




From avt-bounces@ietf.org Tue Apr 10 09:11:26 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HbG7O-0005rv-7R; Tue, 10 Apr 2007 09:10:42 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HbG7M-0005rL-Ly
	for avt@ietf.org; Tue, 10 Apr 2007 09:10:40 -0400
Received: from mr1.dcs.gla.ac.uk ([130.209.249.184])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbG7L-0005p6-CX
	for avt@ietf.org; Tue, 10 Apr 2007 09:10:40 -0400
Received: from vpn5.dcs.gla.ac.uk ([130.209.254.5]:56978)
	by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42)
	id 1HbG7K-0007Pt-TC for avt@ietf.org; Tue, 10 Apr 2007 14:10:38 +0100
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Transfer-Encoding: 7bit
Message-Id: <DA8D773D-710C-4D6A-BA3C-46C1150E36EE@csperkins.org>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: IETF AVT WG <avt@ietf.org>
From: Colin Perkins <csp@csperkins.org>
Date: Tue, 10 Apr 2007 14:10:31 +0100
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08e48e05374109708c00c6208b534009
Subject: [AVT] IPR statement on draft-ietf-avt-rtp-svc-01.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

The secretariat informs us that an IPR disclosure has been submitted  
pertaining to the SVC payload format draft: https:// 
datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=832

This joins the previous IPR disclosure on this draft from Nokia:  
https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=736

Colin (as chair)

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



From avt-bounces@ietf.org Tue Apr 10 14:22:24 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HbKxp-00006L-IM; Tue, 10 Apr 2007 14:21:09 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HbKxn-00005z-2p; Tue, 10 Apr 2007 14:21:07 -0400
Received: from nit.isi.edu ([128.9.160.116])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HbKxl-0007Ee-Mu; Tue, 10 Apr 2007 14:21:07 -0400
Received: from nit.isi.edu (loopback [127.0.0.1])
	by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id l3AIL2fc023095; 
	Tue, 10 Apr 2007 11:21:02 -0700
Received: (from apache@localhost)
	by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id l3AIL2cw023094;
	Tue, 10 Apr 2007 11:21:02 -0700
Date: Tue, 10 Apr 2007 11:21:02 -0700
Message-Id: <200704101821.l3AIL2cw023094@nit.isi.edu>
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
From: rfc-editor@rfc-editor.org
X-Spam-Score: -14.8 (--------------)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976
Cc: avt@ietf.org, rfc-editor@rfc-editor.org
Subject: [AVT] RFC 4867 on RTP Payload Format and File Storage Format for
	the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate
	Wideband (AMR-WB) Audio Codecs
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org


A new Request for Comments is now available in online RFC libraries.

        
        RFC 4867

        Title:      RTP Payload Format and File 
                    Storage Format for the Adaptive Multi-Rate 
                    (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) 
                    Audio Codecs 
        Author:     J. Sjoberg, M. Westerlund,
                    A. Lakaniemi, Q. Xie
        Status:     Standards Track
        Date:       April 2007
        Mailbox:    Johan.Sjoberg@ericsson.com, 
                    Magnus.Westerlund@ericsson.com, 
                    ari.lakaniemi@nokia.com, Qiaobing.Xie@motorola.com
        Pages:      59
        Characters: 139584
        Obsoletes:  RFC3267
        See-Also:   

        I-D Tag:    draft-ietf-avt-rtp-amr-bis-06.txt

        URL:        http://www.rfc-editor.org/rfc/rfc4867.txt

This document specifies a Real-time Transport Protocol (RTP) payload
format to be used for Adaptive Multi-Rate (AMR) and Adaptive
Multi-Rate Wideband (AMR-WB) encoded speech signals.  The payload
format is designed to be able to interoperate with existing AMR and
AMR-WB transport formats on non-IP networks.  In addition, a file
format is specified for transport of AMR and AMR-WB speech data in
storage mode applications such as email.  Two separate media type
registrations are included, one for AMR and one for AMR-WB,
specifying use of both the RTP payload format and the storage
format.  This document obsoletes RFC 3267.  [STANDARDS TRACK]

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

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and 
suggestions for improvements.Please refer to the current edition of the 
Internet Official Protocol Standards (STD 1) for the standardization 
state and status of this protocol.  Distribution of this memo is 
unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST@IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body 

help: ways_to_get_rfcs. For example:

        To: rfc-info@RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
RFC-EDITOR@RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


The RFC Editor Team
USC/Information Sciences Institute

...



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



From avt-bounces@ietf.org Thu Apr 12 17:50:35 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hc7BZ-0007c0-WA; Thu, 12 Apr 2007 17:50:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc7BY-0007Zx-83
	for avt@ietf.org; Thu, 12 Apr 2007 17:50:32 -0400
Received: from hu-out-0506.google.com ([72.14.214.232])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc7BV-0007DS-TG
	for avt@ietf.org; Thu, 12 Apr 2007 17:50:32 -0400
Received: by hu-out-0506.google.com with SMTP id 21so340432hug
	for <avt@ietf.org>; Thu, 12 Apr 2007 14:50:29 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta;
	h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type;
	b=eZbRlbsx7XNc6ecXxCMAIh07jd0jFWASOe5wBcNEsLBAkxzNpavS+hQ5zk3rjrFnHHvbcnulxm+D30DBMUNEK2ayY8AjGP9uONpnhZLJFBuMhQlqOpj2OuLGUw/bcMLnwQghnnID/+fRujVPu6Yyo3K7CV87PAXofj+hnPOuy0c=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:to:subject:mime-version:content-type;
	b=IdccMByVxy7fAWnd7tURYDru98awDWCrFCh0ZiNwhIUeJNFA9iqLMQNbURuQQ15qe3iTLKDB0ZsZ+r7f0V3m2JEKyX/gssyfu3fV2gGyMYBnZF0PL4EEj5rSvu2wlDN4VH0VxZxac54oH3Qsu/y6Nyvnoyg9neF7r39uf9T4bmc=
Received: by 10.78.123.4 with SMTP id v4mr528268huc.1176414628811;
	Thu, 12 Apr 2007 14:50:28 -0700 (PDT)
Received: by 10.78.43.3 with HTTP; Thu, 12 Apr 2007 14:50:28 -0700 (PDT)
Message-ID: <38c19b540704121450k611cfa11ic3ff20deee967849@mail.gmail.com>
Date: Thu, 12 Apr 2007 14:50:28 -0700
From: "Greg Shepherd" <gjshep@gmail.com>
To: fecframe@ietf.org, rmt@ietf.org, mmusic@ietf.org, avt@ietf.org
MIME-Version: 1.0
X-Spam-Score: 0.1 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Cc: 
Subject: [AVT] Request For FEC Schemes
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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-Type: multipart/mixed; boundary="===============0414466272=="
Errors-To: avt-bounces@ietf.org

--===============0414466272==
Content-Type: multipart/alternative; 
	boundary="----=_Part_30859_12924349.1176414628761"

------=_Part_30859_12924349.1176414628761
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Greetings,

>From the 68th IETF meeting in Prague, the FECFrame working group came away
with some action items which we need to get to in order stay on track with
our milestones:

1) Streaming Content Delivery Protocol
       Define specific protocol elements for signalling the use of FEC
       SDP, in particular, requires coordination with mmusic, avt and rmt -
thus the current distribution.
       Call for volunteers to participate as the part of a Design Team.


2) Call for FEC Schemes:

     Like the RMT FEC Building Block, we should define the requirements that
FECFRAME FEC Schemes should meet;
          Data elements that must be defined
          Procedures that must be defined
          Format for FEC Scheme specifications

If you're interested enough to be on this list, and/or interested enough to
attend the WG meetings, then you must be interested enough to see this
through to functional result - please step-up.

Thanks,
Greg

------=_Part_30859_12924349.1176414628761
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Greetings,<br><br>From the 68th IETF meeting in Prague, the FECFrame working group came away with some action items which we need to get to in order stay on track with our milestones:<br><br>1) Streaming Content Delivery Protocol
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Define specific protocol elements for signalling the use of FEC<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SDP, in particular, requires coordination with mmusic, avt and rmt - thus the current distribution.<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <span style="font-weight: bold;">
Call for volunteers to participate as the part of a Design Team.</span><br style="font-weight: bold;"><br><br>2) Call for FEC Schemes:<br><br>&nbsp;&nbsp;&nbsp;&nbsp; Like the RMT FEC Building Block, we should define the requirements that FECFRAME FEC Schemes should meet;
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Data elements that must be defined<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Procedures that must be defined<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Format for FEC Scheme specifications<br><br>If you&#39;re interested enough to be on this list, and/or interested enough to attend the WG meetings, then you must be interested enough to see this through to functional result - please step-up.
<br><br>Thanks,<br>Greg<br><br>

------=_Part_30859_12924349.1176414628761--


--===============0414466272==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0414466272==--




From avt-bounces@ietf.org Fri Apr 13 03:03:32 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HcFoc-0006Wg-JG; Fri, 13 Apr 2007 03:03:26 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HcFob-0006WR-IS
	for avt@ietf.org; Fri, 13 Apr 2007 03:03:25 -0400
Received: from lon-del-04.spheriq.net ([195.46.50.101])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcFoa-0003ZL-27
	for avt@ietf.org; Fri, 13 Apr 2007 03:03:25 -0400
Received: from lon-out-03.spheriq.net ([195.46.50.131])
	by lon-del-04.spheriq.net with ESMTP id l3D73JuZ016175
	for <avt@ietf.org>; Fri, 13 Apr 2007 07:03:19 GMT
Received: from lon-cus-01.spheriq.net (lon-cus-01.spheriq.net [195.46.50.37])
	by lon-out-03.spheriq.net with ESMTP id l3D73IAJ020051
	for <avt@ietf.org>; Fri, 13 Apr 2007 07:03:18 GMT
Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35])
	by lon-cus-01.spheriq.net with ESMTP id l3D73Fm5004338
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK);
	Fri, 13 Apr 2007 07:03:16 GMT
Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9])
	by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP
	id 750BADB19; Fri, 13 Apr 2007 07:03:14 +0000 (GMT)
Received: from mail4.agr.st.com (mail4.agr.st.com [164.130.4.70])
	by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id BAAC14726D;
	Fri, 13 Apr 2007 07:03:13 +0000 (GMT)
Received: from [10.50.13.10] (agr2261.agr.st.com [10.50.13.10])
	by mail4.agr.st.com (MOS 3.7.5a-GA)
	with ESMTP id BEG96178 (AUTH "andrea vitali");
	Fri, 13 Apr 2007 09:03:12 +0200 (CEST)
Message-ID: <461F2B30.80905@st.com>
Date: Fri, 13 Apr 2007 09:03:12 +0200
From: Andrea Lorenzo VITALI <andrea.vitali@st.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Greg Shepherd <gjshep@gmail.com>
Subject: Re: [AVT] Request For FEC Schemes
References: <38c19b540704121450k611cfa11ic3ff20deee967849@mail.gmail.com>
In-Reply-To: <38c19b540704121450k611cfa11ic3ff20deee967849@mail.gmail.com>
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-O-Spoofed: Not Scanned
X-O-General-Status: No
X-O-Spam1-Status: Not Scanned
X-O-Spam2-Status: Not Scanned
X-O-URL-Status: Not Scanned
X-O-Virus1-Status: No
X-O-Virus2-Status: Not Scanned
X-O-Virus3-Status: No
X-O-Virus4-Status: No
X-O-Virus5-Status: Not Scanned
X-O-Image-Status: Not Scanned
X-O-Attach-Status: Not Scanned
X-SpheriQ-Ver: 4.2.04
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Cc: avt@ietf.org, mmusic@ietf.org, fecframe@ietf.org, rmt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org


I am interested. Please let me know the next step.

  Andrea Vitali (STMicroelectronics)


> 1) Streaming Content Delivery Protocol
>        Define specific protocol elements for signalling the use of FEC
>        SDP, in particular, requires coordination with mmusic, avt and
> rmt - thus the current distribution.
>        Call for volunteers to participate as the part of a Design Team.
> 
> 
> 2) Call for FEC Schemes:
> 
>      Like the RMT FEC Building Block, we should define the requirements
> that FECFRAME FEC Schemes should meet;
>           Data elements that must be defined
>           Procedures that must be defined
>           Format for FEC Scheme specifications
> 
> If you're interested enough to be on this list, and/or interested enough
> to attend the WG meetings, then you must be interested enough to see
> this through to functional result - please step-up.
> 
> Thanks,
> Greg
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www1.ietf.org/mailman/listinfo/avt

-- 
 ______________________________________________________________

  Andrea VITALI                            andrea.vitali@st.com

  tel (+39) 039 603 7244             mobile (+39) 347 93 08 433
  fax (+39) 039 603 6129

  STMicroelectronics
  Centro Direzionale COLLEONI - Palazzo "DIALETTICA"
  20041 Agrate Brianza (MI) ITALY
 ______________________________________________________________

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



From avt-bounces@ietf.org Fri Apr 13 05:22:40 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HcHzJ-00086c-OM; Fri, 13 Apr 2007 05:22:37 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HcHzH-00086U-Lb
	for avt@ietf.org; Fri, 13 Apr 2007 05:22:35 -0400
Received: from p-mail2.rd.francetelecom.com ([195.101.245.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcHzG-0002WZ-9f
	for avt@ietf.org; Fri, 13 Apr 2007 05:22:35 -0400
Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by
	ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 13 Apr 2007 11:22:27 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 13 Apr 2007 11:22:26 +0200
Message-ID: <DD8B8FEBBFAF9E488F63FF0F1A69EDD10361F603@ftrdmel1.rd.francetelecom.fr>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: question on draft-ietf-avt-rfc3047-bis-03
Thread-Index: Acd9rUCQavpXFlGLQamyZAusitGSCg==
From: "SOLLAUD Aurelien RD-TECH-LAN" <aurelien.sollaud@orange-ftgroup.com>
To: <patrick.luthi@tandberg.no>,
	<roni.even@polycom.co.il>
X-OriginalArrivalTime: 13 Apr 2007 09:22:27.0880 (UTC)
	FILETIME=[41205280:01C77DAD]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Cc: avt@ietf.org
Subject: [AVT] question on draft-ietf-avt-rfc3047-bis-03
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

Hi

I have a question on draft-ietf-avt-rfc3047-bis-03.

Quoting section 3.1:

      Marker (M) bit: The M bit is set to one to indicate that the RTP
      packet payload contains at least one complete frame

It is not what we are used to for audio formats.
In addition the Figure 1 says there is "one or more frames" in eache
packet, that would imply that the M bit is always set to 1 (there is
always at least one complete frame).

Can you clarify the M bit definition and motivation ?
Is it a bug ?

Thanks
Aurelien

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



From avt-bounces@ietf.org Fri Apr 13 12:37:08 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HcOli-0002SB-Hp; Fri, 13 Apr 2007 12:37:02 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HcOlh-0002S4-4Z
	for avt@ietf.org; Fri, 13 Apr 2007 12:37:01 -0400
Received: from mr1.dcs.gla.ac.uk ([130.209.249.184])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcOlf-0005iT-P3
	for avt@ietf.org; Fri, 13 Apr 2007 12:37:01 -0400
Received: from vpn2.dcs.gla.ac.uk ([130.209.254.2]:49672)
	by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42)
	id 1HcOlf-0000At-4F; Fri, 13 Apr 2007 17:36:59 +0100
In-Reply-To: <E1HZXy6-00045J-29@stiedprstage1.ietf.org>
References: <E1HZXy6-00045J-29@stiedprstage1.ietf.org>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <3C92DFB3-BACA-4957-9BC1-DC841817E43C@csperkins.org>
Content-Transfer-Encoding: 7bit
From: Colin Perkins <csp@csperkins.org>
Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-rtp-no-op-01.txt 
Date: Fri, 13 Apr 2007 17:36:44 +0100
To: Flemming Andreasen <fandreas@cisco.com>, David R Oran <oran@cisco.com>,
	Dan Wing <dwing@cisco.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Cc: IETF AVT WG <avt@ietf.org>
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

On 5 Apr 2007, at 20:50, Internet-Drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Audio/Video Transport Working  
> Group of the IETF.
>
> 	Title		: A No-Op Payload Format for RTP
> 	Author(s)	: F. Andreasen, et al.
> 	Filename	: draft-ietf-avt-rtp-no-op-01.txt
> 	Pages		: 13
> 	Date		: 2007-4-5
> 	
> This document defines an no-op payload format for the Real-time
>    Transport Protocol (RTP).  This packet is not played out by
>    receivers.  It can be useful as a way to keep Network Address
>    Translator (NAT) bindings and Firewall pinholes open.  Other  
> uses are
>    discussed in the document.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-no-op-01.txt

This revision looks good, except that it still uses the old MIME  
registration template, rather than following (and referencing) RFC  
4855. If you can update it to correct this, and possibly also add an  
informative reference to the RTP and RTCP multiplexing draft as an  
alternative keep alive mechanism, then I think this would be ready  
for working group last call.

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



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



From avt-bounces@ietf.org Fri Apr 13 13:58:01 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HcQ22-0004mb-Cn; Fri, 13 Apr 2007 13:57:58 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HcQ20-0004iK-Py
	for avt@ietf.org; Fri, 13 Apr 2007 13:57:56 -0400
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcQ20-0008D4-GZ
	for avt@ietf.org; Fri, 13 Apr 2007 13:57:56 -0400
Received: from sj-dkim-6.cisco.com ([171.68.10.81])
	by sj-iport-5.cisco.com with ESMTP; 13 Apr 2007 10:57:56 -0700
X-IronPort-AV: i="4.14,408,1170662400"; 
	d="scan'208"; a="411272629:sNHT46414156"
Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137])
	by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l3DHvtkU025329; 
	Fri, 13 Apr 2007 10:57:55 -0700
Received: from dwingwxp ([10.32.240.196])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l3DHvsA8003640;
	Fri, 13 Apr 2007 17:57:54 GMT
From: "Dan Wing" <dwing@cisco.com>
To: "'Colin Perkins'" <csp@csperkins.org>,
	"'Flemming Andreasen'" <fandreas@cisco.com>,
	"'David R Oran'" <oran@cisco.com>
Subject: RE: [AVT] I-D ACTION:draft-ietf-avt-rtp-no-op-01.txt 
Date: Fri, 13 Apr 2007 10:57:53 -0700
Message-ID: <014701c77df5$4308faf0$c4f0200a@amer.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <3C92DFB3-BACA-4957-9BC1-DC841817E43C@csperkins.org>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Thread-Index: Acd96fhN/UJ+ZaHvTxGroOmE8LrL1QACEhag
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1069; t=1176487075;
	x=1177351075; c=relaxed/simple; s=sjdkim6002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=dwing@cisco.com;
	z=From:=20=22Dan=20Wing=22=20<dwing@cisco.com>
	|Subject:=20RE=3A=20[AVT]=20I-D=20ACTION=3Adraft-ietf-avt-rtp-no-op-01.tx
	t=20 |Sender:=20;
	bh=XrESZLfD6P7dzbheEe7VqaH/MMSQk2u5QlTOXfJlHck=;
	b=U3x2+/b2nqVgXW/jegBUDyz1BXREB4QNNKws8WOYyrl54XZAXUP7F2mh6zuLggu0WUcUUR7Z
	lOVhik39Ruxgip/Ugt1zTLItrMrx1PxWP5zDFlaNl+Cw/QQqWniDGT+n;
Authentication-Results: sj-dkim-6; header.From=dwing@cisco.com; dkim=pass (s
	ig from cisco.com/sjdkim6002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Cc: 'MARJOU Xavier RD-MAPS-LAN' <xavier.marjou@orange-ftgroup.com>,
	'IETF AVT WG' <avt@ietf.org>
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-no-op-01.txt
> 
> This revision looks good, except that it still uses the old MIME  
> registration template, rather than following (and referencing) RFC  
> 4855.

Sorry about that, I wasn't aware of the new MIME registration RFC.  I have
corrected that and will submit -02.

> If you can update it to correct this, and possibly also add an  
> informative reference to the RTP and RTCP multiplexing draft as an  
> alternative keep alive mechanism, then I think this would be ready  
> for working group last call.

I added this to the end of the introduction:

      Multiplexing RTP and RTCP over the same port 
      <xref target="I-D.ietf-avt-rtp-and-rtcp-mux"></xref> provides a
      separate keepalive mechanism which uses the periodic RTCP 
      transmission to keep middleboxes aware of the flow.

draft-marjou-behave-app-rtp-keepalive-01 compares the various keepalive
techniques; perhaps that might be a useful AVT WG document?

-d

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



From avt-bounces@ietf.org Mon Apr 16 03:52:10 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdM0E-0006y0-R4; Mon, 16 Apr 2007 03:51:58 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HdM0D-0006xM-6r
	for avt@ietf.org; Mon, 16 Apr 2007 03:51:57 -0400
Received: from mr1.dcs.gla.ac.uk ([130.209.249.184])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdM0C-0002Xt-Pq
	for avt@ietf.org; Mon, 16 Apr 2007 03:51:57 -0400
Received: from csperkins-dsl.demon.co.uk ([62.49.4.249]:61750
	helo=[192.168.0.3])
	by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42)
	id 1HdM0A-00012h-BD; Mon, 16 Apr 2007 08:51:54 +0100
In-Reply-To: <E1HZXy6-00045t-AX@stiedprstage1.ietf.org>
References: <E1HZXy6-00045t-AX@stiedprstage1.ietf.org>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <F34A77B0-58F8-4549-9DC5-713A286EBD10@csperkins.org>
Content-Transfer-Encoding: 7bit
From: Colin Perkins <csp@csperkins.org>
Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-rtp-jpeg2000-beam-05.txt 
Date: Sun, 15 Apr 2007 19:39:53 +0100
To: Andrew Leung <andrew@ualberta.net>,
	Satoshi Futemma <satosi-f@sm.sony.co.jp>,
	ITAKURA Eisaburo <itakura@sm.sony.co.jp>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Cc: IETF AVT WG <avt@ietf.org>
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

On 5 Apr 2007, at 20:50, Internet-Drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Audio/Video Transport Working  
> Group of the IETF.
>
> 	Title		: Payload Format for JPEG 2000 Video: Extensions for  
> Scalability and Main Header Recovery
> 	Author(s)	: A. Leung, et al.
> 	Filename	: draft-ietf-avt-rtp-jpeg2000-beam-05.txt
> 	Pages		: 33
> 	Date		: 2007-4-5
> 	
> This memo describes extended uses for payload header in RFC document:
>    "RTP Payload Format for JPEG 2000 Video Streams."  For better  
> support
>    of JPEG 2000 features such as scalability and includes a main  
> header
>    recovery method.
>
>    This memo MUST be accompanied with a complete implementation of  
> "RTP
>    Payload Format for JPEG 2000 Video Streams."  That document is a
>    complete description of the payload header and signaling, this
>    document only describes additional processing for the payload  
> header.
>    There is an additional media type and SDP marker signaling for
>    implementations of this document.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-jpeg2000- 
> beam-05.txt

As with the main JPEG-2000 payload format, I think this is generally  
in good shape. I noticed two minor issues:

1) the abstract should not use RFC 2119 terminology ("MUST" -> "must")

2) the examples in section 8.1 are incorrect: they have multiple  
"a=fmtp:" lines for a single payload type, but should have a single  
long "a=fmtp:" line.

In addition, the automated checker finds some problems with the  
references which need to be corrected: http://tools.ietf.org/wg/avt/ 
draft-ietf-avt-rtp-jpeg2000-beam/draft-ietf-avt-rtp-jpeg2000- 
beam-05.nits.txt

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



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



From avt-bounces@ietf.org Mon Apr 16 03:52:10 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdM0B-0006u2-20; Mon, 16 Apr 2007 03:51:55 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HdM09-0006lF-9W
	for avt@ietf.org; Mon, 16 Apr 2007 03:51:53 -0400
Received: from mr1.dcs.gla.ac.uk ([130.209.249.184])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdM07-0002Xi-Hz
	for avt@ietf.org; Mon, 16 Apr 2007 03:51:52 -0400
Received: from csperkins-dsl.demon.co.uk ([62.49.4.249]:61750
	helo=[192.168.0.3])
	by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42)
	id 1HdM06-00012h-C4; Mon, 16 Apr 2007 08:51:50 +0100
In-Reply-To: <014701c77df5$4308faf0$c4f0200a@amer.cisco.com>
References: <014701c77df5$4308faf0$c4f0200a@amer.cisco.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <6E11DE78-E2B0-403C-888F-CA3098577122@csperkins.org>
Content-Transfer-Encoding: 7bit
From: Colin Perkins <csp@csperkins.org>
Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-rtp-no-op-01.txt 
Date: Sun, 15 Apr 2007 10:44:31 +0100
To: Dan Wing <dwing@cisco.com>,
 Cullen Jennings <fluffy@cisco.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Cc: Flemming Andreasen <fandreas@cisco.com>,
	MARJOU Xavier RD-MAPS-LAN <xavier.marjou@orange-ftgroup.com>,
	David R Oran <oran@cisco.com>, IETF AVT WG <avt@ietf.org>
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

On 13 Apr 2007, at 18:57, Dan Wing wrote:
>>> A URL for this Internet-Draft is:
>>> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-no-op-01.txt
>>
>> This revision looks good, except that it still uses the old MIME
>> registration template, rather than following (and referencing) RFC
>> 4855.
>
> Sorry about that, I wasn't aware of the new MIME registration RFC.   
> I have corrected that and will submit -02.
>
>> If you can update it to correct this, and possibly also add an
>> informative reference to the RTP and RTCP multiplexing draft as an
>> alternative keep alive mechanism, then I think this would be ready
>> for working group last call.
>
> I added this to the end of the introduction:
>
>       Multiplexing RTP and RTCP over the same port
>       <xref target="I-D.ietf-avt-rtp-and-rtcp-mux"></xref> provides a
>       separate keepalive mechanism which uses the periodic RTCP
>       transmission to keep middleboxes aware of the flow.
>
> draft-marjou-behave-app-rtp-keepalive-01 compares the various  
> keepalive
> techniques; perhaps that might be a useful AVT WG document?

Yes, I think so. If Cullen's okay with it, it would probably make  
sense to move this draft to AVT.

Colin

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

From avt-bounces@ietf.org Mon Apr 16 03:52:10 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdM0E-0006xZ-EF; Mon, 16 Apr 2007 03:51:58 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HdM0D-0006xH-69
	for avt@ietf.org; Mon, 16 Apr 2007 03:51:57 -0400
Received: from mr1.dcs.gla.ac.uk ([130.209.249.184])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdM0C-0002Xu-Pr
	for avt@ietf.org; Mon, 16 Apr 2007 03:51:57 -0400
Received: from csperkins-dsl.demon.co.uk ([62.49.4.249]:61750
	helo=[192.168.0.3])
	by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42)
	id 1HdM09-00012h-2P; Mon, 16 Apr 2007 08:51:53 +0100
In-Reply-To: <E1HZXy6-00045n-8w@stiedprstage1.ietf.org>
References: <E1HZXy6-00045n-8w@stiedprstage1.ietf.org>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <C840717A-B472-426F-97DA-79698168DB80@csperkins.org>
Content-Transfer-Encoding: 7bit
From: Colin Perkins <csp@csperkins.org>
Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-rtp-jpeg2000-13.txt 
Date: Sun, 15 Apr 2007 17:52:07 +0100
To: Satoshi Futemma <satosi-f@sm.sony.co.jp>,
	Andrew Leung <andrew@ualberta.net>,
	ITAKURA Eisaburo <itakura@sm.sony.co.jp>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Cc: IETF AVT WG <avt@ietf.org>
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

On 5 Apr 2007, at 20:50, Internet-Drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Audio/Video Transport Working  
> Group of the IETF.
>
> 	Title		: RTP Payload Format for JPEG 2000 Video Streams
> 	Author(s)	: S. Futemma, et al.
> 	Filename	: draft-ietf-avt-rtp-jpeg2000-13.txt
> 	Pages		: 34
> 	Date		: 2007-4-5
> 	
> This memo describes an RTP payload format for the ISO/IEC
>    International Standard 15444-1 | ITU-T Rec. T.800, otherwise better
>    known as: JPEG 2000.  JPEG 2000 features are considered in the  
> design
>    of this payload format.  JPEG 2000 is a truly scalable compression
>    technology allowing applications to encode once and decode many
>    different ways.  JPEG 2000 video stream is formed by extending  
> from a
>    single image to a series of JPEG 2000 images.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-jpeg2000-13.txt

Thanks for updating this draft. The text looks generally okay, and  
ready for working group last call, except that there are a number of  
problems with the references, found by the automated checker: http:// 
tools.ietf.org/wg/avt/draft-ietf-avt-rtp-jpeg2000/draft-ietf-avt-rtp- 
jpeg2000-13.nits.txt

Please can you revise the draft to correct these problems?

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



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





From avt-bounces@ietf.org Mon Apr 16 03:52:10 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdM09-0006l7-B8; Mon, 16 Apr 2007 03:51:53 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HdM07-0006g3-Nv
	for avt@ietf.org; Mon, 16 Apr 2007 03:51:51 -0400
Received: from mr1.dcs.gla.ac.uk ([130.209.249.184])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdM06-0002X7-8Y
	for avt@ietf.org; Mon, 16 Apr 2007 03:51:51 -0400
Received: from csperkins-dsl.demon.co.uk ([62.49.4.249]:61750
	helo=[192.168.0.3])
	by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42)
	id 1HdM04-00012h-2h; Mon, 16 Apr 2007 08:51:48 +0100
In-Reply-To: <E1HazsI-0005bs-DH@stiedprstage1.ietf.org>
References: <E1HazsI-0005bs-DH@stiedprstage1.ietf.org>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <F1913120-2D69-4BE0-8155-F5133C87126C@csperkins.org>
Content-Transfer-Encoding: 7bit
From: Colin Perkins <csp@csperkins.org>
Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-rtp-vorbis-02.txt 
Date: Sun, 15 Apr 2007 10:04:36 +0100
To: Luca Barbato <lu_zero@gentoo.org>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8
Cc: IETF AVT WG <avt@ietf.org>
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

Luca, all,

On 9 Apr 2007, at 20:50, Internet-Drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Audio/Video Transport Working  
> Group of the IETF.
>
> 	Title		: RTP Payload Format for Vorbis Encoded Audio
> 	Author(s)	: L. Barbato
> 	Filename	: draft-ietf-avt-rtp-vorbis-02.txt
> 	Pages		: 25
> 	Date		: 2007-4-9
> 	
> This document describes an RTP payload format for transporting Vorbis
>    encoded audio.  It details the RTP encapsulation mechanism for raw
>    Vorbis data and details the delivery mechanisms for the decoder
>    probability model, referred to as a codebook and other setup
>    information.
>
>    Also included within this memo are media type registrations, and  
> the
>    details necessary for the use of Vorbis with the Session  
> Description
>    Protocol (SDP).
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-vorbis-02.txt

Thanks for updating this draft. I think this version is in pretty  
good shape, although there are a number of minor issues that should  
be resolved before it can be published as an RFC.

First of all, there are a number of 'nits' found by the automated  
checker: http://tools.ietf.org/wg/avt/draft-ietf-avt-rtp-vorbis/draft- 
ietf-avt-rtp-vorbis-02.nits.txt

The media type registrations use an old MIME registration template  
(or a variation on it), and should be updated to match the new  
template. Please follow the instructions in, and reference, RFC 4855,  
and ensure the change controller is listed as "IETF AVT Working Group  
delegated from the IESG", rather than just the working group.

Both media type registrations should be included in the IANA  
Considerations section (or, at least, referenced from it).

For the "delivery-method" media type parameter, is the  
"specific_name" part of the out_band method needed, or can it be  
inferred from the configuration URI? It would ease registration if it  
can be inferred.

The offer/answer considerations section should specify if the  
parameters are declarative or negotiated. Section 3.3.2 of draft-ietf- 
avt-rtp-howto-01.txt has some guidance on this.

These are all relatively minor issues, which should be possible to  
fix relatively quickly.

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



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



From avt-bounces@ietf.org Mon Apr 16 03:52:10 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdM0B-0006u2-20; Mon, 16 Apr 2007 03:51:55 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HdM09-0006lF-9W
	for avt@ietf.org; Mon, 16 Apr 2007 03:51:53 -0400
Received: from mr1.dcs.gla.ac.uk ([130.209.249.184])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdM07-0002Xi-Hz
	for avt@ietf.org; Mon, 16 Apr 2007 03:51:52 -0400
Received: from csperkins-dsl.demon.co.uk ([62.49.4.249]:61750
	helo=[192.168.0.3])
	by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42)
	id 1HdM06-00012h-C4; Mon, 16 Apr 2007 08:51:50 +0100
In-Reply-To: <014701c77df5$4308faf0$c4f0200a@amer.cisco.com>
References: <014701c77df5$4308faf0$c4f0200a@amer.cisco.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <6E11DE78-E2B0-403C-888F-CA3098577122@csperkins.org>
Content-Transfer-Encoding: 7bit
From: Colin Perkins <csp@csperkins.org>
Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-rtp-no-op-01.txt 
Date: Sun, 15 Apr 2007 10:44:31 +0100
To: Dan Wing <dwing@cisco.com>,
 Cullen Jennings <fluffy@cisco.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Cc: Flemming Andreasen <fandreas@cisco.com>,
	MARJOU Xavier RD-MAPS-LAN <xavier.marjou@orange-ftgroup.com>,
	David R Oran <oran@cisco.com>, IETF AVT WG <avt@ietf.org>
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

On 13 Apr 2007, at 18:57, Dan Wing wrote:
>>> A URL for this Internet-Draft is:
>>> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-no-op-01.txt
>>
>> This revision looks good, except that it still uses the old MIME
>> registration template, rather than following (and referencing) RFC
>> 4855.
>
> Sorry about that, I wasn't aware of the new MIME registration RFC.   
> I have corrected that and will submit -02.
>
>> If you can update it to correct this, and possibly also add an
>> informative reference to the RTP and RTCP multiplexing draft as an
>> alternative keep alive mechanism, then I think this would be ready
>> for working group last call.
>
> I added this to the end of the introduction:
>
>       Multiplexing RTP and RTCP over the same port
>       <xref target="I-D.ietf-avt-rtp-and-rtcp-mux"></xref> provides a
>       separate keepalive mechanism which uses the periodic RTCP
>       transmission to keep middleboxes aware of the flow.
>
> draft-marjou-behave-app-rtp-keepalive-01 compares the various  
> keepalive
> techniques; perhaps that might be a useful AVT WG document?

Yes, I think so. If Cullen's okay with it, it would probably make  
sense to move this draft to AVT.

Colin

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

From avt-bounces@ietf.org Mon Apr 16 03:52:10 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdM0E-0006xZ-EF; Mon, 16 Apr 2007 03:51:58 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HdM0D-0006xH-69
	for avt@ietf.org; Mon, 16 Apr 2007 03:51:57 -0400
Received: from mr1.dcs.gla.ac.uk ([130.209.249.184])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdM0C-0002Xu-Pr
	for avt@ietf.org; Mon, 16 Apr 2007 03:51:57 -0400
Received: from csperkins-dsl.demon.co.uk ([62.49.4.249]:61750
	helo=[192.168.0.3])
	by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42)
	id 1HdM09-00012h-2P; Mon, 16 Apr 2007 08:51:53 +0100
In-Reply-To: <E1HZXy6-00045n-8w@stiedprstage1.ietf.org>
References: <E1HZXy6-00045n-8w@stiedprstage1.ietf.org>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <C840717A-B472-426F-97DA-79698168DB80@csperkins.org>
Content-Transfer-Encoding: 7bit
From: Colin Perkins <csp@csperkins.org>
Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-rtp-jpeg2000-13.txt 
Date: Sun, 15 Apr 2007 17:52:07 +0100
To: Satoshi Futemma <satosi-f@sm.sony.co.jp>,
	Andrew Leung <andrew@ualberta.net>,
	ITAKURA Eisaburo <itakura@sm.sony.co.jp>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Cc: IETF AVT WG <avt@ietf.org>
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

On 5 Apr 2007, at 20:50, Internet-Drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Audio/Video Transport Working  
> Group of the IETF.
>
> 	Title		: RTP Payload Format for JPEG 2000 Video Streams
> 	Author(s)	: S. Futemma, et al.
> 	Filename	: draft-ietf-avt-rtp-jpeg2000-13.txt
> 	Pages		: 34
> 	Date		: 2007-4-5
> 	
> This memo describes an RTP payload format for the ISO/IEC
>    International Standard 15444-1 | ITU-T Rec. T.800, otherwise better
>    known as: JPEG 2000.  JPEG 2000 features are considered in the  
> design
>    of this payload format.  JPEG 2000 is a truly scalable compression
>    technology allowing applications to encode once and decode many
>    different ways.  JPEG 2000 video stream is formed by extending  
> from a
>    single image to a series of JPEG 2000 images.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-jpeg2000-13.txt

Thanks for updating this draft. The text looks generally okay, and  
ready for working group last call, except that there are a number of  
problems with the references, found by the automated checker: http:// 
tools.ietf.org/wg/avt/draft-ietf-avt-rtp-jpeg2000/draft-ietf-avt-rtp- 
jpeg2000-13.nits.txt

Please can you revise the draft to correct these problems?

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



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





From avt-bounces@ietf.org Mon Apr 16 03:52:10 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdM09-0006l7-B8; Mon, 16 Apr 2007 03:51:53 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HdM07-0006g3-Nv
	for avt@ietf.org; Mon, 16 Apr 2007 03:51:51 -0400
Received: from mr1.dcs.gla.ac.uk ([130.209.249.184])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdM06-0002X7-8Y
	for avt@ietf.org; Mon, 16 Apr 2007 03:51:51 -0400
Received: from csperkins-dsl.demon.co.uk ([62.49.4.249]:61750
	helo=[192.168.0.3])
	by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42)
	id 1HdM04-00012h-2h; Mon, 16 Apr 2007 08:51:48 +0100
In-Reply-To: <E1HazsI-0005bs-DH@stiedprstage1.ietf.org>
References: <E1HazsI-0005bs-DH@stiedprstage1.ietf.org>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <F1913120-2D69-4BE0-8155-F5133C87126C@csperkins.org>
Content-Transfer-Encoding: 7bit
From: Colin Perkins <csp@csperkins.org>
Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-rtp-vorbis-02.txt 
Date: Sun, 15 Apr 2007 10:04:36 +0100
To: Luca Barbato <lu_zero@gentoo.org>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8
Cc: IETF AVT WG <avt@ietf.org>
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

Luca, all,

On 9 Apr 2007, at 20:50, Internet-Drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Audio/Video Transport Working  
> Group of the IETF.
>
> 	Title		: RTP Payload Format for Vorbis Encoded Audio
> 	Author(s)	: L. Barbato
> 	Filename	: draft-ietf-avt-rtp-vorbis-02.txt
> 	Pages		: 25
> 	Date		: 2007-4-9
> 	
> This document describes an RTP payload format for transporting Vorbis
>    encoded audio.  It details the RTP encapsulation mechanism for raw
>    Vorbis data and details the delivery mechanisms for the decoder
>    probability model, referred to as a codebook and other setup
>    information.
>
>    Also included within this memo are media type registrations, and  
> the
>    details necessary for the use of Vorbis with the Session  
> Description
>    Protocol (SDP).
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-vorbis-02.txt

Thanks for updating this draft. I think this version is in pretty  
good shape, although there are a number of minor issues that should  
be resolved before it can be published as an RFC.

First of all, there are a number of 'nits' found by the automated  
checker: http://tools.ietf.org/wg/avt/draft-ietf-avt-rtp-vorbis/draft- 
ietf-avt-rtp-vorbis-02.nits.txt

The media type registrations use an old MIME registration template  
(or a variation on it), and should be updated to match the new  
template. Please follow the instructions in, and reference, RFC 4855,  
and ensure the change controller is listed as "IETF AVT Working Group  
delegated from the IESG", rather than just the working group.

Both media type registrations should be included in the IANA  
Considerations section (or, at least, referenced from it).

For the "delivery-method" media type parameter, is the  
"specific_name" part of the out_band method needed, or can it be  
inferred from the configuration URI? It would ease registration if it  
can be inferred.

The offer/answer considerations section should specify if the  
parameters are declarative or negotiated. Section 3.3.2 of draft-ietf- 
avt-rtp-howto-01.txt has some guidance on this.

These are all relatively minor issues, which should be possible to  
fix relatively quickly.

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



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



From avt-bounces@ietf.org Mon Apr 16 03:52:10 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdM0B-0006u2-20; Mon, 16 Apr 2007 03:51:55 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HdM09-0006lF-9W
	for avt@ietf.org; Mon, 16 Apr 2007 03:51:53 -0400
Received: from mr1.dcs.gla.ac.uk ([130.209.249.184])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdM07-0002Xi-Hz
	for avt@ietf.org; Mon, 16 Apr 2007 03:51:52 -0400
Received: from csperkins-dsl.demon.co.uk ([62.49.4.249]:61750
	helo=[192.168.0.3])
	by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42)
	id 1HdM06-00012h-C4; Mon, 16 Apr 2007 08:51:50 +0100
In-Reply-To: <014701c77df5$4308faf0$c4f0200a@amer.cisco.com>
References: <014701c77df5$4308faf0$c4f0200a@amer.cisco.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <6E11DE78-E2B0-403C-888F-CA3098577122@csperkins.org>
Content-Transfer-Encoding: 7bit
From: Colin Perkins <csp@csperkins.org>
Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-rtp-no-op-01.txt 
Date: Sun, 15 Apr 2007 10:44:31 +0100
To: Dan Wing <dwing@cisco.com>,
 Cullen Jennings <fluffy@cisco.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Cc: Flemming Andreasen <fandreas@cisco.com>,
	MARJOU Xavier RD-MAPS-LAN <xavier.marjou@orange-ftgroup.com>,
	David R Oran <oran@cisco.com>, IETF AVT WG <avt@ietf.org>
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

On 13 Apr 2007, at 18:57, Dan Wing wrote:
>>> A URL for this Internet-Draft is:
>>> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-no-op-01.txt
>>
>> This revision looks good, except that it still uses the old MIME
>> registration template, rather than following (and referencing) RFC
>> 4855.
>
> Sorry about that, I wasn't aware of the new MIME registration RFC.   
> I have corrected that and will submit -02.
>
>> If you can update it to correct this, and possibly also add an
>> informative reference to the RTP and RTCP multiplexing draft as an
>> alternative keep alive mechanism, then I think this would be ready
>> for working group last call.
>
> I added this to the end of the introduction:
>
>       Multiplexing RTP and RTCP over the same port
>       <xref target="I-D.ietf-avt-rtp-and-rtcp-mux"></xref> provides a
>       separate keepalive mechanism which uses the periodic RTCP
>       transmission to keep middleboxes aware of the flow.
>
> draft-marjou-behave-app-rtp-keepalive-01 compares the various  
> keepalive
> techniques; perhaps that might be a useful AVT WG document?

Yes, I think so. If Cullen's okay with it, it would probably make  
sense to move this draft to AVT.

Colin

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

From avt-bounces@ietf.org Mon Apr 16 03:52:10 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdM0E-0006xZ-EF; Mon, 16 Apr 2007 03:51:58 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HdM0D-0006xH-69
	for avt@ietf.org; Mon, 16 Apr 2007 03:51:57 -0400
Received: from mr1.dcs.gla.ac.uk ([130.209.249.184])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdM0C-0002Xu-Pr
	for avt@ietf.org; Mon, 16 Apr 2007 03:51:57 -0400
Received: from csperkins-dsl.demon.co.uk ([62.49.4.249]:61750
	helo=[192.168.0.3])
	by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42)
	id 1HdM09-00012h-2P; Mon, 16 Apr 2007 08:51:53 +0100
In-Reply-To: <E1HZXy6-00045n-8w@stiedprstage1.ietf.org>
References: <E1HZXy6-00045n-8w@stiedprstage1.ietf.org>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <C840717A-B472-426F-97DA-79698168DB80@csperkins.org>
Content-Transfer-Encoding: 7bit
From: Colin Perkins <csp@csperkins.org>
Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-rtp-jpeg2000-13.txt 
Date: Sun, 15 Apr 2007 17:52:07 +0100
To: Satoshi Futemma <satosi-f@sm.sony.co.jp>,
	Andrew Leung <andrew@ualberta.net>,
	ITAKURA Eisaburo <itakura@sm.sony.co.jp>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Cc: IETF AVT WG <avt@ietf.org>
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

On 5 Apr 2007, at 20:50, Internet-Drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Audio/Video Transport Working  
> Group of the IETF.
>
> 	Title		: RTP Payload Format for JPEG 2000 Video Streams
> 	Author(s)	: S. Futemma, et al.
> 	Filename	: draft-ietf-avt-rtp-jpeg2000-13.txt
> 	Pages		: 34
> 	Date		: 2007-4-5
> 	
> This memo describes an RTP payload format for the ISO/IEC
>    International Standard 15444-1 | ITU-T Rec. T.800, otherwise better
>    known as: JPEG 2000.  JPEG 2000 features are considered in the  
> design
>    of this payload format.  JPEG 2000 is a truly scalable compression
>    technology allowing applications to encode once and decode many
>    different ways.  JPEG 2000 video stream is formed by extending  
> from a
>    single image to a series of JPEG 2000 images.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-jpeg2000-13.txt

Thanks for updating this draft. The text looks generally okay, and  
ready for working group last call, except that there are a number of  
problems with the references, found by the automated checker: http:// 
tools.ietf.org/wg/avt/draft-ietf-avt-rtp-jpeg2000/draft-ietf-avt-rtp- 
jpeg2000-13.nits.txt

Please can you revise the draft to correct these problems?

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



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





From avt-bounces@ietf.org Mon Apr 16 03:52:10 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdM09-0006l7-B8; Mon, 16 Apr 2007 03:51:53 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HdM07-0006g3-Nv
	for avt@ietf.org; Mon, 16 Apr 2007 03:51:51 -0400
Received: from mr1.dcs.gla.ac.uk ([130.209.249.184])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdM06-0002X7-8Y
	for avt@ietf.org; Mon, 16 Apr 2007 03:51:51 -0400
Received: from csperkins-dsl.demon.co.uk ([62.49.4.249]:61750
	helo=[192.168.0.3])
	by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42)
	id 1HdM04-00012h-2h; Mon, 16 Apr 2007 08:51:48 +0100
In-Reply-To: <E1HazsI-0005bs-DH@stiedprstage1.ietf.org>
References: <E1HazsI-0005bs-DH@stiedprstage1.ietf.org>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <F1913120-2D69-4BE0-8155-F5133C87126C@csperkins.org>
Content-Transfer-Encoding: 7bit
From: Colin Perkins <csp@csperkins.org>
Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-rtp-vorbis-02.txt 
Date: Sun, 15 Apr 2007 10:04:36 +0100
To: Luca Barbato <lu_zero@gentoo.org>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8
Cc: IETF AVT WG <avt@ietf.org>
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

Luca, all,

On 9 Apr 2007, at 20:50, Internet-Drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Audio/Video Transport Working  
> Group of the IETF.
>
> 	Title		: RTP Payload Format for Vorbis Encoded Audio
> 	Author(s)	: L. Barbato
> 	Filename	: draft-ietf-avt-rtp-vorbis-02.txt
> 	Pages		: 25
> 	Date		: 2007-4-9
> 	
> This document describes an RTP payload format for transporting Vorbis
>    encoded audio.  It details the RTP encapsulation mechanism for raw
>    Vorbis data and details the delivery mechanisms for the decoder
>    probability model, referred to as a codebook and other setup
>    information.
>
>    Also included within this memo are media type registrations, and  
> the
>    details necessary for the use of Vorbis with the Session  
> Description
>    Protocol (SDP).
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-vorbis-02.txt

Thanks for updating this draft. I think this version is in pretty  
good shape, although there are a number of minor issues that should  
be resolved before it can be published as an RFC.

First of all, there are a number of 'nits' found by the automated  
checker: http://tools.ietf.org/wg/avt/draft-ietf-avt-rtp-vorbis/draft- 
ietf-avt-rtp-vorbis-02.nits.txt

The media type registrations use an old MIME registration template  
(or a variation on it), and should be updated to match the new  
template. Please follow the instructions in, and reference, RFC 4855,  
and ensure the change controller is listed as "IETF AVT Working Group  
delegated from the IESG", rather than just the working group.

Both media type registrations should be included in the IANA  
Considerations section (or, at least, referenced from it).

For the "delivery-method" media type parameter, is the  
"specific_name" part of the out_band method needed, or can it be  
inferred from the configuration URI? It would ease registration if it  
can be inferred.

The offer/answer considerations section should specify if the  
parameters are declarative or negotiated. Section 3.3.2 of draft-ietf- 
avt-rtp-howto-01.txt has some guidance on this.

These are all relatively minor issues, which should be possible to  
fix relatively quickly.

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



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



From avt-bounces@ietf.org Mon Apr 16 08:09:25 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdQ1J-0000r9-8S; Mon, 16 Apr 2007 08:09:21 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HdQ1I-0000r1-1k
	for avt@ietf.org; Mon, 16 Apr 2007 08:09:20 -0400
Received: from an-out-0708.google.com ([209.85.132.245])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdQ1G-0004Y5-8U
	for avt@ietf.org; Mon, 16 Apr 2007 08:09:20 -0400
Received: by an-out-0708.google.com with SMTP id d30so1844048and
	for <avt@ietf.org>; Mon, 16 Apr 2007 05:09:17 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta;
	h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
	b=gtfCXwv2trWYfQravlk6+SATKETaxU0itau+43Cc5AVKBiMB398SnSQO6nchieHts798hDs7rfJguaP/3vFj+ZIa7M/8euBb7/3Sq6vBGGoU1+oyU1whBfPSeSSXIvJg23GnrocVshD55qY3fExCoj573R5jq8z1XQKaa8nfEic=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
	b=ZBfptCpJTbfS3KzgPDW4i74Ufyd8TsuKbVba761P1xZK0s8WfmSYrD2Cr5OS85io/ZdPiO5xEf4QtJhCrkOD6KwT/5OyfNH3g/y3AuRkGzzz4kXC5qNwPXUTrUuHdFcmrbcxBqpz+QqQcoq+gpPD1QO6+396ci5HXcIgynQNz6A=
Received: by 10.100.94.3 with SMTP id r3mr1595733anb.1176725357273;
	Mon, 16 Apr 2007 05:09:17 -0700 (PDT)
Received: by 10.100.189.14 with HTTP; Mon, 16 Apr 2007 05:09:17 -0700 (PDT)
Message-ID: <458913680704160509x7b35dd45q57a2485c8da78e8c@mail.gmail.com>
Date: Mon, 16 Apr 2007 14:09:17 +0200
From: "Xavier Marjou" <xavier.marjou@orange-ftgroup.com>
To: "Dan Wing" <dwing@cisco.com>, "Colin Perkins" <csp@csperkins.org>
Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-rtp-no-op-01.txt
In-Reply-To: <6E11DE78-E2B0-403C-888F-CA3098577122@csperkins.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <014701c77df5$4308faf0$c4f0200a@amer.cisco.com>
	<6E11DE78-E2B0-403C-888F-CA3098577122@csperkins.org>
X-Google-Sender-Auth: 6ca4ba51cda0b96a
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Cc: Cullen Jennings <fluffy@cisco.com>, Flemming Andreasen <fandreas@cisco.com>,
	David R Oran <oran@cisco.com>, IETF AVT WG <avt@ietf.org>
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

> > draft-marjou-behave-app-rtp-keepalive-01 compares the various
> > keepalive
> > techniques; perhaps that might be a useful AVT WG document?
>
> Yes, I think so. If Cullen's okay with it, it would probably make
> sense to move this draft to AVT.

Just some few words about this "rtp keepalive" draft. Based on the
feedback I got so far, there is really no consensus on the keepalive
technique to be used. I would thus propose to remove the Section on
"recommended solution" and limit the scope of the draft to the list of
different techniques.

Xavier

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



From avt-bounces@ietf.org Mon Apr 16 15:11:57 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdWcA-00080b-U9; Mon, 16 Apr 2007 15:11:50 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdWc9-00080V-E6; Mon, 16 Apr 2007 15:11:49 -0400
Received: from zrtps0kp.nortel.com ([47.140.192.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HdWc8-0000dY-UB; Mon, 16 Apr 2007 15:11:49 -0400
Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com
	[47.129.230.89])
	by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l3GJBhm22852; Mon, 16 Apr 2007 19:11:43 GMT
Received: from [47.130.20.158] ([47.130.20.158] RDNS failed) by
	zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 16 Apr 2007 15:11:43 -0400
Message-ID: <4623CA3E.3050402@nortel.com>
Date: Mon, 16 Apr 2007 15:10:54 -0400
From: "Tom-PT Taylor" <taylor@nortel.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Cullen Jennings <fluffy@cisco.com>
Content-Type: multipart/mixed; boundary="------------060101030302050309020306"
X-OriginalArrivalTime: 16 Apr 2007 19:11:43.0346 (UTC)
	FILETIME=[11DD8D20:01C7805B]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172
Cc: Dave Singer <singer@apple.com>, Roni Even <roni.even@polycom.co.il>,
	iesg-secretary@ietf.org, IETF AVT WG <avt@ietf.org>,
	Colin Perkins <csp@csperkins.org>
Subject: [AVT] Request for publication of draft-ietf-avt-smtpe-rtp-10.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

This is a multi-part message in MIME format.
--------------060101030302050309020306
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

This is a request for publication of draft-ietf-avt-smtpe-rtp-10.txt as a 
Standards Track document. The PROTO writeup is attached.

Tom Taylor

--------------060101030302050309020306
Content-Type: text/plain;
 name="SMPTE PROTO writeup.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="SMPTE PROTO writeup.txt"

As required by RFC-to-be draft-ietf-proto-wgchair-doc-shepherding, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated February 1, 2007. 

This is the PROTO writeup for draft-ietf-avt-smtpe-rtp-10.txt.

(1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication?

	Tom Taylor <taylor@nortel.com> is the Document Shepherd. 
	I have personally reviewed this version of the document and consider it 	ready for forwarding.

(1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? 

	This draft grew out of a discussion of the transport of SMPTE time codes
      in January, 2005.
      Initial draft, draft-singer-smpte-rtp-00.txt (2005-2-15), used RTCP
      transport only. Concern that discontinuities could cause SMPTE markings 
      carried in RTCP to get out of synch with the RTP timestamps. Conclusion
      was that SMPTE information should also be carried in the RTP stream.

      Further discussion of requirements in Feb-March 2005. Concluded that
      a flexible header mechanism would be desirable. At the same time, the
      work was put out to SMPTE TV Systems Technology Committee for review. 

      draft-singer-smpte-rtp-01.txt issued 2005-6-1 along with 
      draft-singer-rtp-hdrext-00.txt, describing a general header extension
      mechanism (currently with the AD).

      Agreed at the Paris meeting (IETF 63) and confirmed on the list that
      these should be Working Group documents.

      draft-ietf-avt-smpte-rtp-00.txt published 2005-8-16
         Comments by Colin Perkins.
      draft-ietf-avt-smpte-rtp-01.txt published 2006-2-9
         One of two open issues resolved through discussion with
         members of the SMPTE, who reviewed the work.
         Author's proposal for the other one agreed on list.
      draft-ietf-avt-smpte-rtp-02.txt 2006-6-7
      draft-ietf-avt-smpte-rtp-03.txt 2006-6-15
         Colin Perkins comments, mainly editorial, 2006-6-23.
      draft-ietf-avt-smpte-rtp-04.txt 2006-8-16
      draft-ietf-avt-smpte-rtp-05.txt 2006-10-19
      draft-ietf-avt-smpte-rtp-06.txt 2006-12-6
      draft-ietf-avt-smpte-rtp-07.txt 2006-12-15
         This last reflects nits review of related hdrext draft.

      WGLC announced 2006-12-18, to close 2007-1-14.  No comments received. 
      Reviews requested 2007-1-8 from members of the AVT review team). 
      Ladan Gharai responded 2007-02-07.
      draft-ietf-avt-smpte-rtp-08.txt 2007-02-14 in response to these
      comments.
      draft-ietf-avt-smpte-rtp-09.txt 2007-02-23
      draft-ietf-avt-smpte-rtp-10.txt 2007-02-26
         Nit fixes.

(1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? 

	No.

(1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. 

	All OK.

(1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? 

	Many of the WG's active members have addressed it. On that basis, 
	consensus appears to be strong.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) 

	No.

(1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? 

	The document passes idnits. The following nits exist:
	- extra 's' in esssentially' in the second paragraph of page 6
      - the reference to hdrext needs to be up-versioned to -12
	- in accordance with the IANA Considerations section of 
	draft-ietf-avt-rtp-hdrext-12.txt, the document must indicate that it 
	updates draft-ietf-avt-rtp-hdrext-12.txt

(1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. 

	All OK.

(1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? 

	All OK except the third nit identified under (1.g).

(1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? 

	Not applicable.

(1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: 

Technical Summary

   This document describes a method to inform RTP clients when RTP
   packets are transmitted at a time other than their 'nominal'
   transmission time.  It also provides a mechanism to provide improved
   inter-arrival jitter reports from the clients, that take into account
   the reported transmission times. 

Working Group Summary

   This RTP header extension was first defined within draft-ietf-avt-rtp-hdrext
   as an initial application of the RTP header extension mechanism that draft
   defines. As a result of WG discussion in July, 2006, it was moved to a 
   separate draft. Additional discussion resulted in further changes up through 
   Working Group Last Call. There is a strong Working Group consensus in favour 
   of the present document. 

Document Quality 

   Solicited review comments from Qiaobing Xie and Ron Frederick provided a 
   final polish to the document. 

Personnel 

   Tom Taylor is the Document Shepherd for this document? 

   Cullen Jennings is the Responsible Area Director? 
   No IANA expert is needed. 
--------------060101030302050309020306
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--------------060101030302050309020306--




From avt-bounces@ietf.org Tue Apr 17 11:47:22 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hdpti-0001mx-M6; Tue, 17 Apr 2007 11:47:14 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdptg-0001gP-RR
	for avt@ietf.org; Tue, 17 Apr 2007 11:47:12 -0400
Received: from eracle.polito.it ([130.192.3.44] helo=polito.it)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdprG-0002fp-3Y
	for avt@ietf.org; Tue, 17 Apr 2007 11:44:45 -0400
X-ExtScanner: Niversoft's FindAttachments (free)
Received: from [130.192.86.166] (HELO [192.168.99.135])
	by eracle.polito.it (CommuniGate Pro SMTP 5.1.8)
	with ESMTPS id 6142949; Tue, 17 Apr 2007 17:44:40 +0200
Message-ID: <4624EBBB.9080908@gentoo.org>
Date: Tue, 17 Apr 2007 17:46:03 +0200
From: Luca Barbato <lu_zero@gentoo.org>
User-Agent: Thunderbird 1.5.0.10 (X11/20070314)
MIME-Version: 1.0
To: Colin Perkins <csp@csperkins.org>,  avt@ietf.org
Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-rtp-vorbis-02.txt
References: <E1HazsI-0005bs-DH@stiedprstage1.ietf.org>
	<F1913120-2D69-4BE0-8155-F5133C87126C@csperkins.org>
In-Reply-To: <F1913120-2D69-4BE0-8155-F5133C87126C@csperkins.org>
X-Enigmail-Version: 0.94.3.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Cc: 
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

Colin Perkins wrote:
> First of all, there are a number of 'nits' found by the automated
> checker:
> http://tools.ietf.org/wg/avt/draft-ietf-avt-rtp-vorbis/draft-ietf-avt-rtp-vorbis-02.nits.txt
> 

Ok, I'm having problems in putting intended status in xml2rfc in the
correct way, beside that all nits should be fixed in svn

> 
> The media type registrations use an old MIME registration template (or a
> variation on it), and should be updated to match the new template.
> Please follow the instructions in, and reference, RFC 4855, and ensure
> the change controller is listed as "IETF AVT Working Group delegated
> from the IESG", rather than just the working group.

Ack, is there an xml2rfc template around I could pillage?

> 
> Both media type registrations should be included in the IANA
> Considerations section (or, at least, referenced from it).

I moved the packed header registration to the IANA consideration section

> 
> For the "delivery-method" media type parameter, is the "specific_name"
> part of the out_band method needed, or can it be inferred from the
> configuration URI? It would ease registration if it can be inferred.

I think it's ok, I'll drop the specifc_name item in the next commit.

> 
> The offer/answer considerations section should specify if the parameters
> are declarative or negotiated. Section 3.3.2 of
> draft-ietf-avt-rtp-howto-01.txt has some guidance on this.

ok

> 
> These are all relatively minor issues, which should be possible to fix
> relatively quickly.

I'll submit another revision during this week once I'll reshape the IANA
section to be compliant.

Thank you for the comments

lu

-- 

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero


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



From avt-bounces@ietf.org Tue Apr 17 15:50:06 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hdtgi-0001eq-45; Tue, 17 Apr 2007 15:50:04 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hdtgg-0001eT-Gk; Tue, 17 Apr 2007 15:50:02 -0400
Received: from ns0.neustar.com ([156.154.16.158])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Hdtgg-0001gG-8w; Tue, 17 Apr 2007 15:50:02 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 3E4813297C;
	Tue, 17 Apr 2007 19:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1Hdtgg-0001L2-4h; Tue, 17 Apr 2007 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1Hdtgg-0001L2-4h@stiedprstage1.ietf.org>
Date: Tue, 17 Apr 2007 15:50:02 -0400
X-Spam-Score: -2.5 (--)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Cc: avt@ietf.org
Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-no-op-02.txt 
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

--NextPart

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

	Title		: A No-Op Payload Format for RTP
	Author(s)	: F. Andreasen, et al.
	Filename	: draft-ietf-avt-rtp-no-op-02.txt
	Pages		: 12
	Date		: 2007-4-17
	
This document defines an no-op payload format for the Real-time
   Transport Protocol (RTP).  This packet is not played out by
   receivers.  It can be useful as a way to keep Network Address
   Translator (NAT) bindings and Firewall pinholes open.  Other uses are
   discussed in the document.

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

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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

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

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

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

Content-Type: text/plain
Content-ID: <2007-4-17115849.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-avt-rtp-no-op-02.txt

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

Content-Type: text/plain
Content-ID: <2007-4-17115849.I-D@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--NextPart--




From avt-bounces@ietf.org Wed Apr 18 15:50:38 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeGAk-00086j-Jf; Wed, 18 Apr 2007 15:50:34 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeGAj-000865-3g; Wed, 18 Apr 2007 15:50:33 -0400
Received: from ns3.neustar.com ([156.154.24.138])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1HeGAi-0003mQ-NK; Wed, 18 Apr 2007 15:50:32 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id A270D1761E;
	Wed, 18 Apr 2007 19:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1HeGAE-0002ED-Dm; Wed, 18 Apr 2007 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1HeGAE-0002ED-Dm@stiedprstage1.ietf.org>
Date: Wed, 18 Apr 2007 15:50:02 -0400
X-Spam-Score: -2.5 (--)
X-Scan-Signature: f66b12316365a3fe519e75911daf28a8
Cc: avt@ietf.org
Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-jpeg2000-beam-06.txt 
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

--NextPart

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

	Title		: Payload Format for JPEG 2000 Video: Extensions for Scalability and Main Header Recovery
	Author(s)	: A. Leung, et al.
	Filename	: draft-ietf-avt-rtp-jpeg2000-beam-06.txt
	Pages		: 33
	Date		: 2007-4-18
	
This memo describes extended uses for payload header in RFC document:
   "RTP Payload Format for JPEG 2000 Video Streams."  For better support
   of JPEG 2000 features such as scalability and includes a main header
   recovery method.

   This memo must be accompanied with a complete implementation of "RTP
   Payload Format for JPEG 2000 Video Streams."  That document is a
   complete description of the payload header and signaling, this
   document only describes additional processing for the payload header.
   There is an additional media type and SDP marker signaling for
   implementations of this document.

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

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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

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

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

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

Content-Type: text/plain
Content-ID: <2007-4-18115109.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-avt-rtp-jpeg2000-beam-06.txt

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

Content-Type: text/plain
Content-ID: <2007-4-18115109.I-D@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--NextPart--




From avt-bounces@ietf.org Wed Apr 18 16:21:38 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeGek-0001BB-CI; Wed, 18 Apr 2007 16:21:35 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeGeb-0000gU-0C; Wed, 18 Apr 2007 16:21:25 -0400
Received: from ns0.neustar.com ([156.154.16.158])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HeGeZ-0001KN-KF; Wed, 18 Apr 2007 16:21:24 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 7D064329D6;
	Wed, 18 Apr 2007 19:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1HeGAE-0002EA-D8; Wed, 18 Apr 2007 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1HeGAE-0002EA-D8@stiedprstage1.ietf.org>
Date: Wed, 18 Apr 2007 15:50:02 -0400
X-Spam-Score: -2.5 (--)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
Cc: avt@ietf.org
Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-jpeg2000-14.txt 
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

--NextPart

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

	Title		: RTP Payload Format for JPEG 2000 Video Streams
	Author(s)	: S. Futemma, et al.
	Filename	: draft-ietf-avt-rtp-jpeg2000-14.txt
	Pages		: 34
	Date		: 2007-4-18
	
This memo describes an RTP payload format for the ISO/IEC
   International Standard 15444-1 | ITU-T Rec. T.800, otherwise better
   known as: JPEG 2000.  JPEG 2000 features are considered in the design
   of this payload format.  JPEG 2000 is a truly scalable compression
   technology allowing applications to encode once and decode many
   different ways.  JPEG 2000 video stream is formed by extending from a
   single image to a series of JPEG 2000 images.

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

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

Content-Type: text/plain
Content-ID: <2007-4-18114940.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-avt-rtp-jpeg2000-14.txt

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

Content-Type: text/plain
Content-ID: <2007-4-18114940.I-D@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--NextPart--




From avt-bounces@ietf.org Wed Apr 18 16:22:36 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeGfh-0003Rt-BX; Wed, 18 Apr 2007 16:22:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HeGfQ-0002gc-HX
	for avt@ietf.org; Wed, 18 Apr 2007 16:22:16 -0400
Received: from mr1.dcs.gla.ac.uk ([130.209.249.184])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeGfO-0001Zo-5D
	for avt@ietf.org; Wed, 18 Apr 2007 16:22:16 -0400
Received: from csperkins-dsl.demon.co.uk ([62.49.4.249]:63159
	helo=[192.168.0.3])
	by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42)
	id 1HeGfN-0006Ns-Ih; Wed, 18 Apr 2007 21:22:13 +0100
In-Reply-To: <4624EBBB.9080908@gentoo.org>
References: <E1HazsI-0005bs-DH@stiedprstage1.ietf.org>
	<F1913120-2D69-4BE0-8155-F5133C87126C@csperkins.org>
	<4624EBBB.9080908@gentoo.org>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <60CD3029-0CBC-4579-B0B4-DAAD93BAABB7@csperkins.org>
Content-Transfer-Encoding: 7bit
From: Colin Perkins <csp@csperkins.org>
Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-rtp-vorbis-02.txt
Date: Wed, 18 Apr 2007 21:22:07 +0100
To: Luca Barbato <lu_zero@gentoo.org>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Cc: avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

On 17 Apr 2007, at 16:46, Luca Barbato wrote:
> Colin Perkins wrote:
>> First of all, there are a number of 'nits' found by the automated
>> checker:
>> http://tools.ietf.org/wg/avt/draft-ietf-avt-rtp-vorbis/draft-ietf- 
>> avt-rtp-vorbis-02.nits.txt
>>
>
> Ok, I'm having problems in putting intended status in xml2rfc in the
> correct way, beside that all nits should be fixed in svn
>
>>
>> The media type registrations use an old MIME registration template  
>> (or a
>> variation on it), and should be updated to match the new template.
>> Please follow the instructions in, and reference, RFC 4855, and  
>> ensure
>> the change controller is listed as "IETF AVT Working Group delegated
>> from the IESG", rather than just the working group.
>
> Ack, is there an xml2rfc template around I could pillage?

Not of the XML, but just copy the text from a recent RTP payload  
format RFC.

Thanks,
Colin

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



From avt-bounces@ietf.org Wed Apr 18 18:50:08 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeIyT-0000F5-6Y; Wed, 18 Apr 2007 18:50:05 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeIyQ-0000EX-Qx; Wed, 18 Apr 2007 18:50:02 -0400
Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HeIyQ-0006VF-G1; Wed, 18 Apr 2007 18:50:02 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 604CA26E86;
	Wed, 18 Apr 2007 22:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1HeIyQ-00038R-95; Wed, 18 Apr 2007 18:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1HeIyQ-00038R-95@stiedprstage1.ietf.org>
Date: Wed, 18 Apr 2007 18:50:02 -0400
X-Spam-Score: -2.5 (--)
X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30
Cc: avt@ietf.org
Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-vorbis-03.txt 
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

--NextPart

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

	Title		: RTP Payload Format for Vorbis Encoded Audio
	Author(s)	: L. Barbato
	Filename	: draft-ietf-avt-rtp-vorbis-03.txt
	Pages		: 25
	Date		: 2007-4-18
	
This document describes an RTP payload format for transporting Vorbis
   encoded audio.  It details the RTP encapsulation mechanism for raw
   Vorbis data and details the delivery mechanisms for the decoder
   probability model, referred to as a codebook and other setup
   information.

   Also included within this memo are media type registrations, and the
   details necessary for the use of Vorbis with the Session Description
   Protocol (SDP).

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

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

Content-Type: text/plain
Content-ID: <2007-4-18155302.I-D@ietf.org>

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

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

Content-Type: text/plain
Content-ID: <2007-4-18155302.I-D@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--NextPart--





From avt-bounces@ietf.org Fri Apr 20 13:44:39 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hex9x-0005vv-0F; Fri, 20 Apr 2007 13:44:37 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hex9u-0005vf-F1
	for avt@ietf.org; Fri, 20 Apr 2007 13:44:35 -0400
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hex9t-0006Uv-62
	for avt@ietf.org; Fri, 20 Apr 2007 13:44:34 -0400
Received: from sj-dkim-7.cisco.com ([171.68.10.88])
	by sj-iport-5.cisco.com with ESMTP; 20 Apr 2007 10:44:32 -0700
X-IronPort-AV: i="4.14,433,1170662400"; 
	d="scan'208"; a="413906892:sNHT45943288"
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138])
	by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l3KHiWwN003543; 
	Fri, 20 Apr 2007 10:44:32 -0700
Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with SMTP id l3KHiRwo015062;
	Fri, 20 Apr 2007 17:44:27 GMT
In-Reply-To: <6E11DE78-E2B0-403C-888F-CA3098577122@csperkins.org>
References: <014701c77df5$4308faf0$c4f0200a@amer.cisco.com>
	<6E11DE78-E2B0-403C-888F-CA3098577122@csperkins.org>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <633FB36D-2FBC-451D-A4FB-26D911D2F789@cisco.com>
Content-Transfer-Encoding: 7bit
From: Cullen Jennings <fluffy@cisco.com>
Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-rtp-no-op-01.txt 
Date: Fri, 20 Apr 2007 10:43:53 -0700
To: Colin Perkins <csp@csperkins.org>
X-Mailer: Apple Mail (2.752.3)
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=364; t=1177091072;
	x=1177955072; c=relaxed/simple; s=sjdkim7002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=fluffy@cisco.com;
	z=From:=20Cullen=20Jennings=20<fluffy@cisco.com>
	|Subject:=20Re=3A=20[AVT]=20I-D=20ACTION=3Adraft-ietf-avt-rtp-no-op-01.tx
	t=20 |Sender:=20;
	bh=5G2cLqn5b/4B2j1I33lOz8pmINEhIX2Y2vg9J3iSa4Q=;
	b=O5ADVIAmpYlPmY3svZHIE8b5fj9r1nFIP5KWpGZTfAAWXXa97sD42HQyRocxEbFUnTpO6TL6
	VZplktHAt4EdzONiAEcyzMISvDWxTfptX89AYEA/twwHkaPLjPMk0JrT;
Authentication-Results: sj-dkim-7; header.From=fluffy@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim7002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89
Cc: "Flemming Andreasen \(fandreas\)" <fandreas@cisco.com>,
	MARJOU Xavier RD-MAPS-LAN <xavier.marjou@orange-ftgroup.com>,
	"Dave Oran \(oran\)" <oran@cisco.com>, IETF AVT WG <avt@ietf.org>,
	"Dan Wing \(dwing\)" <dwing@cisco.com>
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org


On Apr 15, 2007, at 2:44 AM, Colin Perkins wrote:

> > draft-marjou-behave-app-rtp-keepalive-01 compares the various
> > keepalive
> > techniques; perhaps that might be a useful AVT WG document?
>
> Yes, I think so. If Cullen's okay with it, it would probably make
> sense to move this draft to AVT.

I'm fine with moving the discution of this to AVT.

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



From avt-bounces@ietf.org Sun Apr 22 23:16:14 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hfp27-0007fl-Pv; Sun, 22 Apr 2007 23:16:07 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfouw-0007t4-5N
	for avt@ietf.org; Sun, 22 Apr 2007 23:08:42 -0400
Received: from zcars04e.nortel.com ([47.129.242.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hfouv-0002HW-9N
	for avt@ietf.org; Sun, 22 Apr 2007 23:08:42 -0400
Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com
	[47.129.230.89])
	by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	l3N378f22752; Mon, 23 Apr 2007 03:07:09 GMT
Received: from [47.130.25.177] ([47.130.25.177] RDNS failed) by
	zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Sun, 22 Apr 2007 23:07:46 -0400
Message-ID: <462C22D1.90503@nortel.com>
Date: Sun, 22 Apr 2007 23:06:57 -0400
From: "Tom-PT Taylor" <taylor@nortel.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: avt@ietf.org, Rebecca.Bunch@neustar.biz
Content-Type: text/plain; charset=windows-1252; format=flowed
X-OriginalArrivalTime: 23 Apr 2007 03:07:46.0812 (UTC)
	FILETIME=[917F13C0:01C78554]
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by zcars04e.nortel.com id
	l3N378f22752
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f31e050dc7ce62aeed70903f7da21012
X-Mailman-Approved-At: Sun, 22 Apr 2007 23:16:06 -0400
Cc: 
Subject: [AVT] AVT minutes
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

AVT meeting notes - Prague
- note takers Alan Clark, Stephan Wenger


Monday, 19 March 2007 at 13:00-15:00 (Roma/Vienna/Madrid)
--------------------------------------------------------
13:00   Introduction and Status Update                      (Chairs, 15)
1:15 tape

Tom Taylor (TT): Notes (Alan Clark, Stephan Wenger), scribe (no one on ja=
bber)
TT: Agenda (no comments)
TT; IPR policy review
TT: Document status, 4733, 3734, 4855, 4856, 4788, 4629, 4628, 4695, 4696=
 all=20
published
TT; with RFC editor: hc-over-mpls, amr-bis payload
TT; IESG: savpf, hdrext, toffset, ulp, smpte very soon as well
TT; WGLC: rfc3047bis, rtp-and-rtcp-mux, rfc2833biscas (three weeks on tho=
se)

1:20 tape
Ingemar Johanssom (IJ) non-compound RTCP
IJ presentation of slides (pretty verbatim)
arguments for
- shorter serialization time (long RTCP packets leads to more jitter)
- can send more frequent feedback
- more robust on links with mtu size limits
3gpp example
- header compression PDCP layer, fragmentation in RLC layer
- under bad channel conditions block sizes smaller and hence more risk of=
=20
segmentation
Gave simulation example
- showed that compound RTCP degrades faster than RTP
Using non-compound RTCP
- middle boxes may discard
- old RTCP receivers may discard
- PT of RTCP may vary from 200/201
Leads to new requirements
- compound RTCP should be maintained
- non-compound should be allowed in early/intermediate AVPF framework
- need verification that non-compound RTCP is received (otherwise would n=
ot know=20
if network and far end accepts)

Joerg Ott (Jo): We had this before during AVPF design.  This is link laye=
r=20
optimization stuff, why should the rest of the Internet care? Benefit for=
=20
congestion control profile (TFRC) to be checked, cross-check in conjuncti=
on with=20
Ladan's draft on Wednesday suggested.
IJ: lower layer optimization main target, 3GPP issue voip
Stephan Wenger (SW): if you fix a 3GPP problem, fix it in 3GPP
Roni Even: its more than 3GPP issue,
JO: if there's a bigger picture, then we should discuss a bigger picture =
not=20
this locatliced solution
RE: This does not only address 3GPP, do we want to have it in AVPF only, =
or also=20
in other profiles?  Draft says AVPF only.  Agree with Jo.
Magnus Westerlund (MW): applicable to a number of use cases.  AVPF is the=
 key=20
profile
Jo: Remind AVPF has been forced to remove any form of positive ACK, as it=
 is=20
Congestion Control, which was 3 years ago non P.C.
SW: bring just one use case and I'm more comfortable with it
MW: TFRC is this one use case
SW: let's take this up again in TFRC context
Carsten Bormann (cabo): RTCP compression draft-bormann-something
Jo: even over 3GPP links, you send some stuff that is not compressed by s=
aid draft
Colin Perkins (CP)as chair: general interest, probably useful, extended=20
requirement discussion needed, details over next couple of meeting, if th=
ere's a=20
general use case, we continue with this.

1:40 tape
Thomas Schierl (TS), sdp mmusic layer codec
TS presentation of slides, removal of SSRC mux
CP: use cases (1) and (2) (on SSRC mux) are not useful use cases, decisio=
n to=20
remove SSRC mux OK

1:45
Stephan Wenger (SW): svc payload
SW: presentation of slides
Reviewed changes from ID to WG-00 draft
- aligned with JVT joint draft 8
- removed SSRC mux, now doing session mux
- IPR declaration related to PACSI header
SSRC discussion
- happy to remove SSRC multiplexing
Open issues
- continue on packetization/ de-packetization rules
- alignment with SVC spec
- think about usage of layer codec in SDP offer/answer
- same story for declarative session description
- capability - two choices, 1- try do in this draft , 2- leave to a revis=
ion

SW: capability negotiation in this draft?
RE: good idea to work with media capability negotiation group, they look =
for=20
more complex applications.
SW: concern re timing
RE: regular offer answer in draft only, capability negation support in se=
cond draft
SW: yes, let's do that
RE: timing?
SW: WGLC in Chicago
Thomas Wiegand: media spec frozen 95% in April, 100% in July
RE: RFC number out quickly for non-IETF citations
CSP: WGLC to RFC: at least 3 months

1:57 tape
Tom Kristensen (TK) H.264 extensions
13:50   H.264 Payload extensions for RDCO and Static Macroblocks(Kristens=
en , 15)
         draft-kristensen-avt-rtp-h264-extension-00.txt

Static macroblocks
- some macroblocks don't change (static), frees processing time for non-s=
tatic=20
blocks
- parameter related to number of static macroblocks
Reduced complexity decoding operation (H.241 Annex B for H.264 Baseline)
- can reduce decoder complexity by 30% and encoder by 15%
- propose new MIME (Tom - Media) type
- as RCDO is distinct from H.264 profiles and not compatible with H.264 b=
aselines
TT: media sub-type instead of MIME subtype
CP:  too many subtypes is not a good thing, as it hinders interop
SW: Background: contention in ITU-T, non-compatible change to H.264, spec=
ified=20
in a spec where it should not belong.  New subtype is not only useful but=
=20
required, support both proposals, two different drafts suggested, as MB=20
processing is useful outside H.264
RE: two separate topics, re static MBs, H.241 low complexity codec.  Stat=
ic=20
MBs:how to define a mechanism that allows us to extend parameter space wi=
thout=20
re-issuing RFCs.
SW: WRT. H.241 extension, idea to include codepoints in a container;
RE: not what I want to do
SW: ok with me then
TK:Max MBs also useful for SVC draft
Thomas Wiegand: clarification of low complexity: RCDO bitstreams can be=20
decoding, it just looks horrible. Practically, different subtype is neede=
d.  SVC=20
people are looking at static MBs; likely we will see similar vision of de=
coding=20
processing power as in H.241
SW: should be done codec independently, perhaps there's even more stuff t=
hat=20
could go into that draft
CP: there is no such thing as a generalized parameter mechanism
SW: Informational RFC how to write a payload format for video codecs
CP: feel free to write it
MW: send it to me for the "how to write a payload draft" draft
TK: So to summarie: one draft? No, two draft
Thomas Wiegand: making things too generic is dangerous, no need to promot=
e 10=20
year old codecs
CP: if there's a need for a mechanism applying to more than one codec, th=
en more=20
than one codec payload spec needs to be updated: have not sensed any enth=
usiasm=20
in doing that
RE: in fact, we try to freeze H.261/H.263 payloads by moving up standard'=
s track
TK: split the drafts
RE: RCDO: separate draft, as no interop of the two profiles.  Static MB: =
have a=20
new draft, these are new parameters added to H.264 payload, to be folded =
in later
TT: media type registrations have to be referred to media-types list in t=
ime
RE: draft is not formally OK yet.

2:13 tape
14:05   Issues with TMMBR                                   (Westerlund, =
20)
         draft-ietf-avt-avpf-ccm-04.txt

Issues
- session maximum bit rate is not well defined
- what is bit rate -  media encoding, payload, stream..... sender/ receiv=
er
- is a single value sufficient?  use a token bucket? - easier to keep a s=
ingle value
- proposal to calculate a smoothed reception rate (over a second or more)
- sender should not be too bursty

RE: Do you want to discuss traffic shaping?
MW: no.  Perhaps one paragraph only; assumption: sender is well-behaved.
RE: bandwidth definition broken not only in CCM, but also everywhere else=
 (i.e. SDP)

- varying overhead due to protocol stack - may be different for sender an=
d receiver
- discussed on mailing list

RE: 3890 is about MtU size

- proposed to use average bits/sec plus average overhead
- showed chart comparing three different link speed/ overhead scenarios
- need to consider range of scenarios/ topologies but think these are cov=
ered
- described method of selecting lowest bandwidth and highest but rate, co=
mpute=20
highest packet rate possible

TT:  Is this basically a linear programming problem?  Known solutions.  B=
ut this=20
is not quite such a problem
MW: there are also other factors that do not permit straightforward linea=
r=20
optimization, i.e. congestion control
RE:  don't always know beforehand the packet rate, need to make assumptio=
ns
MW: yes, but that shouldn't be a problem in practice (example: video).
MW: it's the media sender's implementation problem to find the right pack=
et=20
rate, overhead, packet size

- may be cases where there is a hard time but many decoders have some for=
m of=20
bit bucket or rate limiting
- TMMBN contains info on limitations produced by media sender's usage of =
algorithm

Guido Franciscini (GF): minimized state-keeping is an implementation issu=
e,=20
media server may have a database of info
MW: algorithm has properties beyond resource saving...
RE: Confused remark re several session
GF: no, that's not his thing.  Suggest media server keeps data base on al=
l=20
received TMMBR requests,
MW: this may be an option, but it has impacts on how you update things, l=
arger=20
RTCP traffic
GF: when media sender raises value, you may congest receivers.
MW: yes, but you need to use congestion control anyway.
MW: no database,
MW: if there's something really broken, speak up now.  Otherwise we'll go=
 to new=20
last call
CP: Having seen presentation, this makes sense.  But cannot derive this f=
rom the=20
draft.  Clean up language
SW: Within a week

14:25   Bandwidth Metrics for bottleneck characterization(Franceschini, 1=
5)
         draft-franceschini-avt-bwmetrics-00.txt
2:40 tape

Verbally declared IPR related to draft, draft at present informational, n=
o=20
direct relation and no IPR on Magnus idea
CP: need to submit formal IPR disclosure
- TIDC - transport independent downlink capacity
- method for calculating mean packet overhead
- jointly consider multiple media streams (RTP session)
- advocates use of RTCP to manage the link capacity allocation
- recommends session level TIDC

CP: seem to assume that there is only audio and video; this is the IETF, =
you=20
have to consider all traffic types (including TCP traffic)
GF: trying to manage what can be controlled, other traffic types may not =
be=20
controllable
SW: don't think link optimization should be discussed in AVT
CP: should take work to WG that works on QoS
GF: this is the same concept as TMMBR?
CP: No it's not, this is link partitioning, which is against congestion c=
ontrol=20
principles
GF: Example of partitioning again
CP: you can't do this
GF: TMMBR is used to partition link
CP No
GF: instead of having one TMMBR for audio and one TMMBR for video, let's =
have=20
one for both
TT: choose payload type to combine them
Crowd: NO
CP: TMMBR is link capacity.
MW: TMMBR specific to one source, one media.   does not say whether it is=
 used=20
for audio and video separately or together, context of RTP session
RE: use case of TMMBR for media codec type changes
SW: Is in RTCP RR, and pertains to one media sender in one RTP session, n=
ot to=20
the link.
SW: If you wish to fine-tune operation points between multiple codecs, se=
nd=20
TMMBR on all sessions you have,
SW: in multicast or layered codec scenario this draft would not work
SW: is this an algo description how to generate multiple TMMBR messages o=
n=20
optimizing link: write it up as informational
RE: over time, list
GF: OK
CP: interested people should meet offline, hash out meaning of TMMBR.
MW: after TSV Area tomorrow afternoon
CP: send it to the list

14:40   Source-specific SDP attribute                       (Lennox, 20)
         draft-lennox-mmusic-sdp-source-attributes-00
3:00 tape

Source specific attributes
- SDP can't signal things related to multiple sources in an RTP session
- describe/ differentiate between multiple SSRCs from the same participan=
t in=20
the same RTP session
- e.g. multiple cameras, FEC, based vs enhanced, layered codecs... Issue

CP: isn't this done by CNAME?
Jonathan Lennox (JL): No
CP: you want to say what the sessions per SSRC are about?
JL: Yes

- SDP Media Stream describes RTP Session
- suggest using Media Source term Implications for RTP
- SSRC changes
- must not reuse signalled SSRC
- but still could have problem due to race conditions
Proposed approach
- give signaled SSRC precedence
- signaled SSRC's should not collide but if they do then use normal algor=
ithm to=20
resolve
- signal updated SSRC
Backward compatibility problems
- many endpoints can't hand RTP sessions with multiple sources or may not=
 have=20
decoding resources
- could cause anarchic behavior in badly designed endpoints

Dave Oran: can this ever happen on a non-broken endpoints, and if an endp=
oint is=20
broken this won't fix it
JL: Yes, can happen
(some discussion, no conclusion)
Henning Schulzrinne (HS): complexity issue.  Also seems fairly close to X=
CON -=20
suggests discussion should be broader and potentially relate to multiple =
parameters
JL: talk is fine, but we don't want to map everything into XCON
Henning Schulzrinne (HS): have architecture discussion, decide where thin=
gs=20
belong beyond this one single parameter
Ken Toney:  talking about the same SSRC with different source/ destinatio=
n?
JL: semantics are as in RTP session, SSRC generated by single endpoint, o=
ne entity
CP: relationship to SDES items?  Could also signal language etc in SDES
JL: probably went overboard with the details of his SDP-based description=
s
CP: need to decide and create guideline: do we convey it in SDP or in SDE=
S
- reviewed architectural issues
- AVT review - any architectural issues overlooked?  SDES issue

Close of session 3:18 on tape
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Wednesday, 21 March 2007 at 15:10-16:10 (Grand Ballroom)
--------------------------------------------------------
15:10   RTCP HR                                              (Clark, 15)
         draft-ietf-avt-rtcphr-00.txt
3:32:30 on tape ietf68-ch5-wed-noon

Issues and concerns
- removal of topology-related material
- general cleanup following comments
- suggestion to negotiate sub-blocks in SDP

Aligning w/ SG 16 reqts for use in H.248
- aiming to finish mid-2007
Topology stuff: not so easy to remove everything. Have to provide guidanc=
e on=20
how to calculate metrics and what to propagate when there are devices lik=
e=20
bridges in the path.

Colin: describe how to calculate metrics when the device does and when it=
 does=20
not terminate the RTP session. Alan: agreed.

- Colin suggestion: refer to topology draft as much as possible.  Too lat=
e to=20
move anything else into it.

No comments received on the actual metrics. Some people have already impl=
emented=20
the current draft.

Hence just have to address the sub-block negotiation =96 whether to use t=
he SDP to=20
allow end points to negotiate which parts of the report to receive. Autho=
rs=20
willing to do it if it is desirable.
Roni Even: what is the requirement for the application to negotiate which=
 parts=20
to receive? Alan: not sure. A major service provider requested the capabi=
lity.=20
Alan can probe to find out what the issue is.
** Use case requested.


15:25   RTCP XR video Metrics                                (Clark, 15)
         draft-ietf-avt-rtcpxr-video-00.txt
Tape: 3:42:00

Metrics for video over IP is an active area of study. Rather than compete=
 with=20
other work in progress, authors want to take advantage of it. Draft conce=
ntrates=20
on RTP transport. Also covers Forward Error Correction (FEC) related stat=
istics.=20
Also bear in mind the requirement in mobile to keep packet sizes small.


Roni: the draft seems to show audio and video in same block. This is corr=
ect=20
only for MPEG transport streams. There are no guidelines for other cases.=
 Should=20
Al Morton =96- reduced vs no reference -- should wait until that question=
 is=20
resolved, to see if there is any value in carrying references at all.

Dave Oran: this is a matter of whether you have an elementary or transpor=
t=20
stream =96 mark each block with the type of content measured rather than =
using an=20
arbitrary metric to combine them.
Alan: the intention is to match an MPEG programme stream when that is inv=
olved.

Colin =96 try keep structures as general and transport-independent as pos=
sible.
Preserve the commonality of the statistics captured while using different=
 block=20
types to report on different content types.
Alan: currently these are metrics relating to MPEG using RTP transport. C=
ould=20
try to create common framework.
Colin: No shortage of RTCP report types -- have used only 6 of 256. Sugge=
sts=20
using that level rather than one report type with a bunch of sub-blocks =3D=
 yet=20
another layer of multiplexing. Suggests a set of drafts each defining a r=
eport=20
type. All get bundled into a common RTCP report. Alan: Could end up with =
6-8=20
drafts. Colin: so? Each draft should address one problem.

Accommodating FEC: pre- and post loss rates, burst density/length, loss p=
eriods.
Dave Oran: people want to derive from the metric how close to the edge th=
ey are.=20
Can these metrics give that? Alan: yes. Burst metrics very useful for thi=
s purpose.
Mark Watson: number of lost packets within an FEC block is the item of in=
terest.=20
Saw in graph that the burst legth is time based, but something based on F=
EC=20
block size (=3Dtime) would be most useful. The metrics in the draft are a=
n=20
improvement, but metrics based on the time scale of FEC block would be mo=
st=20
useful. Alan: instrument FEC coder? Mark: metrics are used to decide whet=
her to=20
use FEC and which FEC coder to use. Dave: may be sending FEC streams sepa=
rately=20
from the main media stream. Can't just use the source stream to tell what=
 is=20
going on -- have to consider in some cases the losses in the FEC streams =
(though=20
this is a second-order effect).

QoE metrics =96 being defined elsewhere. They tend to involve IPR.
Cullen Jennings: are we defining metrics? As AD he would not expect we ha=
ve=20
expertise to do so. Alan: not defining them, just implementing what other=
s have=20
been defined.
Kaynam Hedayat: Problem =96 draft refers to metrics for which a standard =
does not=20
exist. Concentrate on metrics that are standards. Otherwise we will run i=
nto the=20
problem that audio shows, where it is hard to correlate results from diff=
erent=20
networks.  Also avoid metrics that are relevant to audio but not to video.
Dave =96 report inputs to metrics, then receiver can apply =96 much bette=
r=20
architecture. Kaynam: agreed. Dave reiterates, Colin agrees.
Alan: disagrees w/ Keynam's point re RFC 3611 -- millions of end points=20
reporting successfully. Endpoint can do real-time correlation, other enti=
ties=20
cannot =96 lose info when averaging.

Some metrics are place holders for work in progress, are being replaced a=
s MOS=20
metrics become available ifrom other bodies.

15:40   RTCP XR IPTV Metrics                               (Hedayat, 15)
         draft-venna-avt-rtcpxr-iptv-00.txt

Tape 4:10:00

Purpose is to define raw metrics that serve as basis for others to calcul=
ate=20
derived values. Also aiming usage at operations rather than algorithm ref=
inement.

- take advantage of IPPM metrics
- "yard-stick" measurements for the industry
- based on experience from tier 1 & 2 ntwks
- TS-level

main block: packet-level
program sub-block =96 per program
elementary stream sub-block

Looking for feedback. Especially interested in IPTV application.

Mark Watson =96 have to support everyday operation =96 constantly changin=
g network=20
characteristics and FEC algorithms have to change with them.
Alan =96 draft deals with MPEG transport streams and not RTP. Is this in =
scope for=20
AVT?
Kaynam -- there is RTP-related- define raw metrics
Colin =96 focus of this group is RTP-based media. Kaynam assures that MPE=
G=20
transport over RTP is involved here
Alan =96 look into tunneling protocol over RTCP transport
Colin =96 be very careful to keep in step with IPPM -- Transport AD conce=
rn.
Alan =96 IPPM found some stuff out of scope =96 suggestion that we may ne=
ed a BOF to=20
consider application performance in general
Colin =96 ADs aware of issue -- something may happen in the near future.

15:55   RTP with TCP Friendly Rate Control                  (Gharai, 15)
         draft-ietf-avt-tfrc-profile-07.txt
Tape 4:18:00

How to support required transfer of control information between a TRFC se=
nder=20
and receiver in RTP/RTCP. Would like feedback on whether the protocol and=
=20
language of the draft are correct.

Draft modified, now uses two new header extensions rather than a profile.=
 One is=20
for the round-trip time, the other for the send timestamp. It is not nece=
ssary=20
to send the round-trip time every time, so making it a separate header ex=
tension=20
saves a few bytes on the average. Some concern whether the send timesatmp=
 field=20
is long enough. Colin: suggests making the send timestamp relative to the=
 RTP=20
timestamp, to save bits.
Alternative breakout would be to use one extension for send timestamps on=
ly, the=20
other for combined send timestamp plus round-trip time.
Plus RTCP feedback to send back the receiver feedback.
[Some discussion of what feedback message type number to use.]

Some concern over data volume. RTCP packet comes to 100 bytes, but TRFC w=
ants=20
feedback once per round-trip time.

Jonathan Lennox: assumes that RR always has a report block =96 not sure t=
hat this=20
is required. Magnus says RFC doesn't say anything about it. Jonathan: lea=
ve them=20
out of early RTCP, include only in the regular RTCP reports. Colin: can o=
verflow=20
if too many. Jonathan: what if one is too many?

Another point: Feedback is on an SSRC basis, which seems right, but TRFC =
would=20
presumably span the whole session. If there is more than one RTP source w=
ith the=20
same IP, have to report on all of them. Example: multiple cameras. Unicas=
t at=20
the transport layer, but multiple SSRCs.  Magnus: Really have to look bel=
ow the=20
RTP/RTCP layer. Colin: may have to say this works only for two participan=
ts=20
(i.e. one SSRC per end point. Some nasty interactions possible, have to b=
e=20
considered.

May need more than 5% for RTCP feedback in some cases, will have to be=20
signalled. JonL: need to know RTT before signalling!

Need specific AVPF settings for transmission intervals. Magnus: the setti=
ngs=20
affect only the regular RTCP reports, not the early feedback. Connclusion=
: don't=20
have to discuss this point.

Moreover, do not toggle allow_early. Magnus: the toggling guards against=20
excessive bandwidth consumption by early feedback packets. Colin: implies=
 you=20
have to set your RTCP bandwidth high enough that this wasn't a problem. S=
tephan=20
Wenger: hasn't read the draft, expects he would have one - discuss on lis=
t in=20
the coming week.

For SDP signalling (rtcp_fb attribute): need a payload type value. What w=
ould=20
that be? Magnus: use "*".


TMMBR report (draft-ietf-avt-avpf-ccm-04.txt reprise)
Tape 4:35:10
Stephan Wenger reported.

Plan to clean up and then have a language pass over the next week. Key po=
int is=20
to make clear that TMMBR pertains to a single media stream, not a link. A=
lso=20
will give example of usage that is different from link capacity restricti=
on.
Will make clear that algorithm is not mandated provided that the algorith=
m used=20
gets the same results.
Further point: in the congestion control section, must bring out the poin=
t that=20
congestion control may require a rate lower than that called for in TMMBR.
When the media sender concludes that bandwidth can increase, it must wait=
 two=20
round-trips to see if another participant has a tighter restriction.
Overhead is defined more clearly.
Roni had a couple of additional points, since he was unable to find the m=
eeting,=20
but these have been addressed.

Comment: Jonathan L: might have to wait more than two round-trip time. Ha=
ve also=20
to wait until the receiver can send another feedback message -- may just =
have=20
sent one. Magnus: sender may have difficulty knowing receiver's timings, =
but=20
point is valid. Colin also agrees. Stephan: make informed guess based on =
the=20
size of the multicast group. Will float ideas on list.

16:10   End

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



From avt-bounces@ietf.org Mon Apr 23 17:09:56 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hg5nG-0005sm-KR; Mon, 23 Apr 2007 17:09:54 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg5nD-0005qK-0Z
	for avt@ietf.org; Mon, 23 Apr 2007 17:09:51 -0400
Received: from mr1.dcs.gla.ac.uk ([130.209.249.184])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg5nB-0004No-M7
	for avt@ietf.org; Mon, 23 Apr 2007 17:09:50 -0400
Received: from csperkins-dsl.demon.co.uk ([62.49.4.249]:61598
	helo=[192.168.0.3])
	by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42)
	id 1Hg5n7-0003r5-Hb; Mon, 23 Apr 2007 22:09:45 +0100
In-Reply-To: <E1HeGAE-0002EA-D8@stiedprstage1.ietf.org>
References: <E1HeGAE-0002EA-D8@stiedprstage1.ietf.org>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <238EEBD6-7234-463B-9137-556E2CA98FE6@csperkins.org>
Content-Transfer-Encoding: 7bit
From: Colin Perkins <csp@csperkins.org>
Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-rtp-jpeg2000-14.txt 
Date: Mon, 23 Apr 2007 22:09:40 +0100
To: Satoshi Futemma <satosi-f@sm.sony.co.jp>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Cc: IETF AVT WG <avt@ietf.org>
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

On 18 Apr 2007, at 20:50, Internet-Drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Audio/Video Transport Working  
> Group of the IETF.
>
> 	Title		: RTP Payload Format for JPEG 2000 Video Streams
> 	Author(s)	: S. Futemma, et al.
> 	Filename	: draft-ietf-avt-rtp-jpeg2000-14.txt
> 	Pages		: 34
> 	Date		: 2007-4-18
> 	
> This memo describes an RTP payload format for the ISO/IEC
>    International Standard 15444-1 | ITU-T Rec. T.800, otherwise better
>    known as: JPEG 2000.  JPEG 2000 features are considered in the  
> design
>    of this payload format.  JPEG 2000 is a truly scalable compression
>    technology allowing applications to encode once and decode many
>    different ways.  JPEG 2000 video stream is formed by extending  
> from a
>    single image to a series of JPEG 2000 images.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-jpeg2000-14.txt

I spotted one remaining nit with this draft: in section 8.2, a  
semicolon is incorrectly added at the end of the "a=rtpmap:98  
jpeg2000/90000;" line. Can you please do a revision to correct this?

Thanks,
Colin

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



From avt-bounces@ietf.org Mon Apr 23 17:26:37 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hg63P-0006sz-5g; Mon, 23 Apr 2007 17:26:35 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg63N-0006su-6E
	for avt@ietf.org; Mon, 23 Apr 2007 17:26:33 -0400
Received: from mr1.dcs.gla.ac.uk ([130.209.249.184])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg63L-0008KL-Tc
	for avt@ietf.org; Mon, 23 Apr 2007 17:26:33 -0400
Received: from csperkins-dsl.demon.co.uk ([62.49.4.249]:61613
	helo=[192.168.0.3])
	by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42)
	id 1Hg63G-0005km-GU; Mon, 23 Apr 2007 22:26:26 +0100
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <A254526E-F7D5-49BF-AE4C-D221025866CD@csperkins.org>
Content-Transfer-Encoding: 7bit
From: Colin Perkins <csp@csperkins.org>
Date: Mon, 23 Apr 2007 22:26:20 +0100
To: IETF AVT WG <avt@ietf.org>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Cc: Roni Even <roni.even@polycom.co.il>, Tom-PT Taylor <taylor@nortel.com>
Subject: [AVT] draft-hiwasaki-avt-rtp-uemclip-02.txt as a work item
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

Folks,

We are considering adopting the RTP Payload Format for UEMCLIP Speech  
Codec
(draft-hiwasaki-avt-rtp-uemclip-02.txt) as an AVT working group  
draft. This fits within the AVT charter, which allows us to work on  
RTP payload formats.

If there are objections to accepting this draft, please comment to  
the list before 7 May 2007.

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



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



From avt-bounces@ietf.org Mon Apr 23 19:05:30 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hg7b4-00081s-0s; Mon, 23 Apr 2007 19:05:26 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg7b2-00081k-H8
	for avt@ietf.org; Mon, 23 Apr 2007 19:05:24 -0400
Received: from fw.polycom.co.il ([212.179.41.2]
	helo=isrexch01.israel.polycom.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg7b1-00021U-5x
	for avt@ietf.org; Mon, 23 Apr 2007 19:05:24 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 24 Apr 2007 02:05:53 +0300
Message-ID: <144ED8561CE90C41A3E5908EDECE315C047C25F7@IsrExch01.israel.polycom.com>
In-Reply-To: <A254526E-F7D5-49BF-AE4C-D221025866CD@csperkins.org>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-hiwasaki-avt-rtp-uemclip-02.txt as a work item
Thread-Index: AceF7qS9CSYqP75KRYaCWI4bxpwi1QADP4Rg
From: "Even, Roni" <roni.even@polycom.co.il>
To: "Colin Perkins" <csp@csperkins.org>,
	"IETF AVT WG" <avt@ietf.org>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Cc: Tom-PT Taylor <taylor@nortel.com>
Subject: [AVT] RE: draft-hiwasaki-avt-rtp-uemclip-02.txt as a work item
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

Hi,
I have no objection for adopting it as a work item but I would like to
get clarification if the intention is for payload specification for an
NTT codec or for the G.711 wideband extension work currently at the ITU
SG16 Question 10

Thanks
Roni Even

> -----Original Message-----
> From: Colin Perkins [mailto:csp@csperkins.org]
> Sent: Tuesday, April 24, 2007 12:26 AM
> To: IETF AVT WG
> Cc: Tom-PT Taylor; Even, Roni
> Subject: draft-hiwasaki-avt-rtp-uemclip-02.txt as a work item
>=20
> Folks,
>=20
> We are considering adopting the RTP Payload Format for UEMCLIP Speech
> Codec
> (draft-hiwasaki-avt-rtp-uemclip-02.txt) as an AVT working group
> draft. This fits within the AVT charter, which allows us to work on
> RTP payload formats.
>=20
> If there are objections to accepting this draft, please comment to
> the list before 7 May 2007.
>=20
> --
> Colin Perkins
> http://csperkins.org/
>=20


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



From avt-bounces@ietf.org Mon Apr 23 22:09:05 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HgASc-00034q-E1; Mon, 23 Apr 2007 22:08:54 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HgASb-00034c-25
	for avt@ietf.org; Mon, 23 Apr 2007 22:08:53 -0400
Received: from ns5.sony.co.jp ([137.153.0.45])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgASZ-0005n7-2v
	for avt@ietf.org; Mon, 23 Apr 2007 22:08:53 -0400
Received: from mail38.sony.co.jp ([43.0.1.238])
Received: from mail38.sony.co.jp (localhost [127.0.0.1])
	by mail38.sony.co.jp (R8/Sony) with ESMTP id l3O28mLw009576;
	Tue, 24 Apr 2007 11:08:48 +0900 (JST)
Received: from bourbon.sm.sony.co.jp ([43.11.4.16])
	by mail38.sony.co.jp (R8/Sony) with ESMTP id l3O28mW5009571;
	Tue, 24 Apr 2007 11:08:48 +0900 (JST)
Received: from [43.11.4.168] ([43.11.4.168])
	by bourbon.sm.sony.co.jp (8.13.6/8.13.6) with ESMTP id l3O2R0IO010612; 
	Tue, 24 Apr 2007 11:27:00 +0900
Message-ID: <462D6695.3010009@sm.sony.co.jp>
Date: Tue, 24 Apr 2007 11:08:21 +0900
From: Satoshi Futemma <satosi-f@sm.sony.co.jp>
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: Colin Perkins <csp@csperkins.org>
Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-rtp-jpeg2000-14.txt
References: <E1HeGAE-0002EA-D8@stiedprstage1.ietf.org>
	<238EEBD6-7234-463B-9137-556E2CA98FE6@csperkins.org>
In-Reply-To: <238EEBD6-7234-463B-9137-556E2CA98FE6@csperkins.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Cc: IETF AVT WG <avt@ietf.org>
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

Dear Colin,

Thank you for the reviewing.

All right, I will correct it soon.
Could I post a new version with so tiny change ?

Best regards,

Futemma

Colin Perkins wrote:
> On 18 Apr 2007, at 20:50, Internet-Drafts@ietf.org wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the Audio/Video Transport Working Group 
>> of the IETF.
>>
>>     Title        : RTP Payload Format for JPEG 2000 Video Streams
>>     Author(s)    : S. Futemma, et al.
>>     Filename    : draft-ietf-avt-rtp-jpeg2000-14.txt
>>     Pages        : 34
>>     Date        : 2007-4-18
>>     
>> This memo describes an RTP payload format for the ISO/IEC
>>    International Standard 15444-1 | ITU-T Rec. T.800, otherwise better
>>    known as: JPEG 2000.  JPEG 2000 features are considered in the design
>>    of this payload format.  JPEG 2000 is a truly scalable compression
>>    technology allowing applications to encode once and decode many
>>    different ways.  JPEG 2000 video stream is formed by extending from a
>>    single image to a series of JPEG 2000 images.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-jpeg2000-14.txt
> 
> I spotted one remaining nit with this draft: in section 8.2, a semicolon 
> is incorrectly added at the end of the "a=rtpmap:98 jpeg2000/90000;" 
> line. Can you please do a revision to correct this?
> 
> Thanks,
> Colin
> 
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www1.ietf.org/mailman/listinfo/avt
> 
> 

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



From avt-bounces@ietf.org Tue Apr 24 03:23:53 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HgFNN-0003Fj-DY; Tue, 24 Apr 2007 03:23:49 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HgFNM-0003Fe-0d
	for avt@ietf.org; Tue, 24 Apr 2007 03:23:48 -0400
Received: from mr1.dcs.gla.ac.uk ([130.209.249.184])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgFNK-0000zD-On
	for avt@ietf.org; Tue, 24 Apr 2007 03:23:47 -0400
Received: from csperkins-dsl.demon.co.uk ([62.49.4.249]:62047
	helo=[192.168.0.3])
	by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42)
	id 1HgFNB-0007mZ-5y; Tue, 24 Apr 2007 08:23:37 +0100
In-Reply-To: <462D6695.3010009@sm.sony.co.jp>
References: <E1HeGAE-0002EA-D8@stiedprstage1.ietf.org>
	<238EEBD6-7234-463B-9137-556E2CA98FE6@csperkins.org>
	<462D6695.3010009@sm.sony.co.jp>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <8974732E-EBB9-4440-A97E-1E1FD52FD201@csperkins.org>
Content-Transfer-Encoding: 7bit
From: Colin Perkins <csp@csperkins.org>
Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-rtp-jpeg2000-14.txt
Date: Tue, 24 Apr 2007 08:23:30 +0100
To: Satoshi Futemma <satosi-f@sm.sony.co.jp>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08e48e05374109708c00c6208b534009
Cc: IETF AVT WG <avt@ietf.org>
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

On 24 Apr 2007, at 03:08, Satoshi Futemma wrote:
> All right, I will correct it soon.
> Could I post a new version with so tiny change ?

Yes.

Thanks,
Colin

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



From avt-bounces@ietf.org Tue Apr 24 15:50:33 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HgR1X-0007pb-6g; Tue, 24 Apr 2007 15:50:03 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HgR1W-0007pL-Mx; Tue, 24 Apr 2007 15:50:02 -0400
Received: from ns0.neustar.com ([156.154.16.158])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HgR1W-0004OL-EQ; Tue, 24 Apr 2007 15:50:02 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 6840032936;
	Tue, 24 Apr 2007 19:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1HgR1W-00017Q-AW; Tue, 24 Apr 2007 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1HgR1W-00017Q-AW@stiedprstage1.ietf.org>
Date: Tue, 24 Apr 2007 15:50:02 -0400
X-Spam-Score: -2.5 (--)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
Cc: avt@ietf.org
Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-jpeg2000-15.txt 
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

--NextPart

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

	Title		: RTP Payload Format for JPEG 2000 Video Streams
	Author(s)	: S. Futemma, et al.
	Filename	: draft-ietf-avt-rtp-jpeg2000-15.txt
	Pages		: 34
	Date		: 2007-4-24
	
This memo describes an RTP payload format for the ISO/IEC
   International Standard 15444-1 | ITU-T Rec. T.800, otherwise better
   known as: JPEG 2000.  JPEG 2000 features are considered in the design
   of this payload format.  JPEG 2000 is a truly scalable compression
   technology allowing applications to encode once and decode many
   different ways.  JPEG 2000 video stream is formed by extending from a
   single image to a series of JPEG 2000 images.

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

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

Content-Type: text/plain
Content-ID: <2007-4-24100713.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-avt-rtp-jpeg2000-15.txt

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

Content-Type: text/plain
Content-ID: <2007-4-24100713.I-D@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--NextPart--




From avt-bounces@ietf.org Wed Apr 25 03:09:33 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hgbcz-0004WZ-DC; Wed, 25 Apr 2007 03:09:25 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgbcy-0004WR-8v
	for avt@ietf.org; Wed, 25 Apr 2007 03:09:24 -0400
Received: from fw.polycom.co.il ([212.179.41.2]
	helo=isrexch01.israel.polycom.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgbcw-0001tn-TB
	for avt@ietf.org; Wed, 25 Apr 2007 03:09:24 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [AVT] Working group last call
	fordraft-ietf-avt-rfc2833biscas-03.txt
Date: Wed, 25 Apr 2007 10:09:48 +0300
Message-ID: <144ED8561CE90C41A3E5908EDECE315C047C26BA@IsrExch01.israel.polycom.com>
In-Reply-To: <144ED8561CE90C41A3E5908EDECE315C04696792@IsrExch01.israel.polycom.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [AVT] Working group last call
	fordraft-ietf-avt-rfc2833biscas-03.txt
Thread-Index: AcdqUTX2qXmWQvitTw+UlZpbaWuvFActzDGw
From: "Even, Roni" <roni.even@polycom.co.il>
To: "Even, Roni" <roni.even@polycom.co.il>,
	<avt@ietf.org>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Cc: 
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

Hi,
A bit late but we have concluded the WGLC, there were comments from the =
reviewers, thanks to Steve Norreys
The author will submit a revised version and we will move the document =
to publication.

Roni Even

> -----Original Message-----
> From: Even, Roni [mailto:roni.even@polycom.co.il]
> Sent: Monday, March 19, 2007 8:06 PM
> To: avt@ietf.org
> Subject: [AVT] Working group last call =
fordraft-ietf-avt-rfc2833biscas-
> 03.txt
>=20
> Hi,
>=20
> Announcing work group last call for =
draft-ietf-avt-rfc2833biscas-03.txt,
> Definition of Events For Channel-Oriented Telephony Signaling.
>=20
> The last call period will be three weeks expiring on Saturday, April =
7.
>=20
> Roni Even will be the PROTO Shepherd for this document
>=20
>=20
>=20
>=20
>=20
>=20
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www1.ietf.org/mailman/listinfo/avt

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



From avt-bounces@ietf.org Wed Apr 25 03:39:28 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hgc60-0006R3-MW; Wed, 25 Apr 2007 03:39:24 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgc5z-0006Qq-Cu
	for avt@ietf.org; Wed, 25 Apr 2007 03:39:23 -0400
Received: from tama55.ecl.ntt.co.jp ([129.60.39.103])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgc5x-0008WI-OK
	for avt@ietf.org; Wed, 25 Apr 2007 03:39:23 -0400
Received: from sfs2.rdh.ecl.ntt.co.jp (IDENT:mirapoint@sfs2.rdh.ecl.ntt.co.jp
	[129.60.39.117])
	by tama55.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l3P7Zq39024263;
	Wed, 25 Apr 2007 16:39:17 +0900 (JST)
Received: from mfs34.rdh.ecl.ntt.co.jp (mfs34.rdh.ecl.ntt.co.jp
	[129.60.39.114]) by sfs2.rdh.ecl.ntt.co.jp (MOS 3.8.3-GA)
	with ESMTP id AIH77192; Wed, 25 Apr 2007 16:39:16 +0900 (JST)
Received: from mfs34.rdh.ecl.ntt.co.jp (localhost [127.0.0.1])
	by mfs34.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 4AD3820AE2A;
	Wed, 25 Apr 2007 16:39:16 +0900 (JST)
Received: from nttmail3.ecl.ntt.co.jp (nttmail3.ecl.ntt.co.jp [129.60.39.100])
	by mfs34.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id F1A0820AE2C;
	Wed, 25 Apr 2007 16:39:15 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp
	[129.60.5.69])
	by nttmail3.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l3P7dExD013742; 
	Wed, 25 Apr 2007 16:39:15 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1])
	by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id
	l3P7dES9006636; Wed, 25 Apr 2007 16:39:14 +0900 (JST)
Received: from imi.m.ecl.ntt.co.jp (imi0.m.ecl.ntt.co.jp [129.60.5.147])by 
	eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l3P7dEPf006633;
	Wed, 25 Apr 2007 16:39:14 +0900 (JST)
Received: from sp-abarth.splab.ecl.ntt.co.jp.lab.ntt.co.jp 
	(sp-abarth.splab.ecl.ntt.co.jp [129.60.2.79])by imi.m.ecl.ntt.co.jp 
	(8.13.8/8.13.8) with ESMTP id l3P7d8Zo000136; Wed, 25 Apr 2007 16:39:09 
	+0900 (JST)
Date: Wed, 25 Apr 2007 16:36:01 +0900
Message-ID: <m3d51s7voe.wl%hiwasaki.yusuke@lab.ntt.co.jp>
From: yusuke hiwasaki <hiwasaki.yusuke@lab.ntt.co.jp>
To: "Even, Roni" <roni.even@polycom.co.il>
Subject: Re: [AVT] RE: draft-hiwasaki-avt-rtp-uemclip-02.txt as a work item
In-Reply-To: <144ED8561CE90C41A3E5908EDECE315C047C25F7@IsrExch01.israel.poly
	com.com>
References: <A254526E-F7D5-49BF-AE4C-D221025866CD@csperkins.org><144ED8561CE
	90C41A3E5908EDECE315C047C25F7@IsrExch01.israel.polycom.com>
User-Agent: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 
	(SAKAKI)
Organization: NTT Cyber Space Laboratories
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain;
	charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Cc: hiwasaki.yusuke@lab.ntt.co.jp, Tom-PT Taylor <taylor@nortel.com>,
	Colin Perkins <csp@csperkins.org>, IETF AVT WG <avt@ietf.org>
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

Dear Roni and all,

Thank you for raising the question. This document is intended as a
payload specification for an NTT codec, not the G.711 wideband
extension.

Regards,
yusuke
============
Yusuke Hiwasaki, NTT Cyber Space Labs.
hiwasaki.yusuke@lab.ntt.co.jp
Tel: +81-422-59-4815 (Fax: +81-422-60-7811)

At Tue, 24 Apr 2007 02:05:53 +0300,
Even, Roni wrote:
> 
> Hi,
> I have no objection for adopting it as a work item but I would like to
> get clarification if the intention is for payload specification for an
> NTT codec or for the G.711 wideband extension work currently at the ITU
> SG16 Question 10
> 
> Thanks
> Roni Even
> 
> > -----Original Message-----
> > From: Colin Perkins [mailto:csp@csperkins.org]
> > Sent: Tuesday, April 24, 2007 12:26 AM
> > To: IETF AVT WG
> > Cc: Tom-PT Taylor; Even, Roni
> > Subject: draft-hiwasaki-avt-rtp-uemclip-02.txt as a work item
> > 
> > Folks,
> > 
> > We are considering adopting the RTP Payload Format for UEMCLIP Speech
> > Codec
> > (draft-hiwasaki-avt-rtp-uemclip-02.txt) as an AVT working group
> > draft. This fits within the AVT charter, which allows us to work on
> > RTP payload formats.
> > 
> > If there are objections to accepting this draft, please comment to
> > the list before 7 May 2007.
> > 
> > --
> > Colin Perkins
> > http://csperkins.org/
> > 
> 
> 
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www1.ietf.org/mailman/listinfo/avt
> 

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



From avt-bounces@ietf.org Thu Apr 26 09:39:16 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hh4Bh-0002Ea-KZ; Thu, 26 Apr 2007 09:39:09 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh4Bf-0002EU-Ln
	for avt@ietf.org; Thu, 26 Apr 2007 09:39:07 -0400
Received: from web42102.mail.mud.yahoo.com ([209.191.86.235])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hh4Be-0006Wq-4F
	for avt@ietf.org; Thu, 26 Apr 2007 09:39:07 -0400
Received: (qmail 5359 invoked by uid 60001); 26 Apr 2007 13:39:05 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID;
	b=CUdUs1jOP/kutVFKLtLt4Mj6bMW5hTW4fBxIemMH28DKN9sdnkKNVh6pbFRvLsZOQoLfrHqgujR6lu4Gr2N0/mMZQTvPFUILy+FgFl8oar4ZKksbd+yrDTEACcaal0OkvTECjHPH5yv1PAbjHsJjl18h22t8wk++/n+R1C/y4p0=;
X-YMail-OSG: bBNn8eoVM1mEPnSFSFU85juCTQqUl.3nF_3z5on2FtPysuEnwTBNEjv5mDm6wfYdLwOMT0YlyqxalrhKWjvq683DFaLq3Ab755_qxDpb3fVex3ZPJthtUktrwonPrg--
Received: from [202.84.165.223] by web42102.mail.mud.yahoo.com via HTTP;
	Thu, 26 Apr 2007 06:39:05 PDT
Date: Thu, 26 Apr 2007 06:39:05 -0700 (PDT)
From: sona chalam <sona_kk@yahoo.com>
To: avt@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Message-ID: <451317.4686.qm@web42102.mail.mud.yahoo.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
Subject: [AVT] H264 interleaving method
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

Hello

I am trying to implement interleaved packetization
mode for a packet switched streaming(PSS) client.

I have gone through the RFC but not very clear about
when to start deinterleaving(arranging the received
NALs in decoding order).



Method 1 Sprop-interleaving-depth

As per my understanding  I can  start deinterleaving
once i receive N number of VCL NAL units.

So i will be accumualting NALs in my bufer and have a
count on the number of VCL NALs. Once I have N VCL NAL
units i will perform the logic of deinterleaving.

Please guide me whether my understanding of
Sprop-interleaving-depth is correct or not.

If it is correct how  ot handle packet loss cases. 

Example 
If Sprop-interleaving-depth is 30 and 
 I have received 20 VCL NALs and I miss few packets. 
Then i receive few more VCL NALs can i add it to the
same buffer  and wait till reaches 30 ?

Hoe to handle this?.

Basically I need to know on what basis i can start
deinterleaving?

Waiting for your reply.



















__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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



From avt-bounces@ietf.org Thu Apr 26 12:36:22 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hh6x9-0001rU-MA; Thu, 26 Apr 2007 12:36:19 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh6x8-0001rP-Cy
	for avt@ietf.org; Thu, 26 Apr 2007 12:36:18 -0400
Received: from mailgw3.ericsson.se ([193.180.251.60])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh6x6-0002qw-Ij
	for avt@ietf.org; Thu, 26 Apr 2007 12:36:18 -0400
Received: from mailgw3.ericsson.se (unknown [127.0.0.1])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
	05CE720C39; Thu, 26 Apr 2007 18:36:16 +0200 (CEST)
X-AuditID: c1b4fb3c-a84eabb0000073d5-3d-4630d4ff29e0 
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
	E86C320B59; Thu, 26 Apr 2007 18:36:15 +0200 (CEST)
Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by
	esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 26 Apr 2007 18:36:15 +0200
Received: from [147.214.30.247] ([147.214.30.247]) by
	esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 26 Apr 2007 18:36:15 +0200
Message-ID: <4630D4FF.1010606@ericsson.com>
Date: Thu, 26 Apr 2007 18:36:15 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: sona chalam <sona_kk@yahoo.com>
Subject: Re: [AVT] H264 interleaving method
References: <451317.4686.qm@web42102.mail.mud.yahoo.com>
In-Reply-To: <451317.4686.qm@web42102.mail.mud.yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 26 Apr 2007 16:36:15.0445 (UTC)
	FILETIME=[02225050:01C78821]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
Cc: avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

sona chalam skrev:
> Hello
> 
> I am trying to implement interleaved packetization
> mode for a packet switched streaming(PSS) client.
> 
> I have gone through the RFC but not very clear about
> when to start deinterleaving(arranging the received
> NALs in decoding order).
> 
> 
> 
> Method 1 Sprop-interleaving-depth
> 
> As per my understanding  I can  start deinterleaving
> once i receive N number of VCL NAL units.
> 
> So i will be accumualting NALs in my bufer and have a
> count on the number of VCL NALs. Once I have N VCL NAL
> units i will perform the logic of deinterleaving.
> 
> Please guide me whether my understanding of
> Sprop-interleaving-depth is correct or not.
> 
> If it is correct how  ot handle packet loss cases. 
> 
> Example 
> If Sprop-interleaving-depth is 30 and 
>  I have received 20 VCL NALs and I miss few packets. 
> Then i receive few more VCL NALs can i add it to the
> same buffer  and wait till reaches 30 ?
> 
> Hoe to handle this?.
> 
> Basically I need to know on what basis i can start
> deinterleaving?
> 
> Waiting for your reply.
> 

First, we expect that you have deinterleave the packets on the fly when 
they arrive and put the NALU into the buffer. The issue is when to 
remove them from the buffer. Sprop-interleaving-depth provides an upper 
limit in regards to how many NALUs you need to buffer. However the 
sprop-max-don-diff can help a great deal. When the DON values for NALUS 
in the buffer has larger diff from the lowest to the highest is larger 
than the max-don-diff value then they are moved to the decoder. That way 
the packet loss will be handled as the next packet arrives and also if 
the sender likes to reduce its depth during the session he can do that 
by making the DON values sparse.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

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



From avt-bounces@ietf.org Fri Apr 27 03:06:26 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HhKX9-0004np-8D; Fri, 27 Apr 2007 03:06:23 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HhKX8-0004gs-1P
	for avt@ietf.org; Fri, 27 Apr 2007 03:06:22 -0400
Received: from web42103.mail.mud.yahoo.com ([209.191.86.236])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HhKX7-0000BF-Ln
	for avt@ietf.org; Fri, 27 Apr 2007 03:06:22 -0400
Received: (qmail 4330 invoked by uid 60001); 27 Apr 2007 07:06:21 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID;
	b=5BR5kWrXv8X9F7n+/GCqv06VJyon2Z1z4KzJyxeY3MsCWz42V2eukjWJVkB4O5K17QbwW9sYdkhk/3UM+SAkuFdJIdYYhzT9mqI65CgUbq7sRxwGGsEMfz9AIv8NepoRMBWGtHPHxNDWASXjpcQMeN+FsN4p05mnrUmASXWt8NE=;
X-YMail-OSG: bM6RH2cVM1m0O.tMTd8rT6pHPBq4Cjtj4mk4wSAtq0fKY8Yj5BFypVv.e5Y26QduznLMaT2SXbXGJzMfk4pDMZ_fkBpTOIqAcMvUgiYW9me1Afj1dzo-
Received: from [202.84.165.223] by web42103.mail.mud.yahoo.com via HTTP;
	Fri, 27 Apr 2007 00:06:20 PDT
Date: Fri, 27 Apr 2007 00:06:20 -0700 (PDT)
From: sona chalam <sona_kk@yahoo.com>
Subject: Re: [AVT] H264 interleaving method
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
In-Reply-To: <4630D4FF.1010606@ericsson.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Message-ID: <67007.3363.qm@web42103.mail.mud.yahoo.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985
Cc: a22339@motorola.com, avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

Hi Magnus 

Thanks for your reply.Can you clarify a bit more also

Still I have few queries.

sprop-max-don-diff method

I have issues here. since the sprop-max-don-diff is a
optional parameters it is not gauranteed that I will
get this sprop-don-diff value always.

Secondly If i arrange the NAL units in Absodn order
will it same as decoding order? Till DON value reaches
65536 both DON and AbsDon will be same ?

But how to handle when the  DON value reaching 65535. 

So in that case my Absdon  can become negative.

As per the formula given in the RFC 

If DON(m)<DON(n)  and n-m >32768

AbdDon(n)=Absdon(m) -(Don(m)+65536-Don(n)). 

How to handle this?.

I thought of rearranging the NAL  by ascending order
of DON  and i can send it to the decoder once it
reaches sprop-deinterleaving-depth is reached.

And also  i can over come the DON (roll over after
65526 if  i use 32 bit value for that.So that i can
simply arrange the DON in ascending order into my
buffer

And also in H264 interleaving is done between Staps or
Mtaps and with in an STAP or MTAP the NALs will be in
same order. 

Your inoput and suggestion is required.














--- Magnus Westerlund <magnus.westerlund@ericsson.com>
wrote:

> sona chalam skrev:
> > Hello
> > 
> > I am trying to implement interleaved packetization
> > mode for a packet switched streaming(PSS) client.
> > 
> > I have gone through the RFC but not very clear
> about
> > when to start deinterleaving(arranging the
> received
> > NALs in decoding order).
> > 
> > 
> > 
> > Method 1 Sprop-interleaving-depth
> > 
> > As per my understanding  I can  start
> deinterleaving
> > once i receive N number of VCL NAL units.
> > 
> > So i will be accumualting NALs in my bufer and
> have a
> > count on the number of VCL NALs. Once I have N VCL
> NAL
> > units i will perform the logic of deinterleaving.
> > 
> > Please guide me whether my understanding of
> > Sprop-interleaving-depth is correct or not.
> > 
> > If it is correct how  ot handle packet loss cases.
> 
> > 
> > Example 
> > If Sprop-interleaving-depth is 30 and 
> >  I have received 20 VCL NALs and I miss few
> packets. 
> > Then i receive few more VCL NALs can i add it to
> the
> > same buffer  and wait till reaches 30 ?
> > 
> > Hoe to handle this?.
> > 
> > Basically I need to know on what basis i can start
> > deinterleaving?
> > 
> > Waiting for your reply.
> > 
> 
> First, we expect that you have deinterleave the
> packets on the fly when 
> they arrive and put the NALU into the buffer. The
> issue is when to 
> remove them from the buffer.
> Sprop-interleaving-depth provides an upper 
> limit in regards to how many NALUs you need to
> buffer. However the 
> sprop-max-don-diff can help a great deal. When the
> DON values for NALUS 
> in the buffer has larger diff from the lowest to the
> highest is larger 
> than the max-don-diff value then they are moved to
> the decoder. That way 
> the packet loss will be handled as the next packet
> arrives and also if 
> the sender likes to reduce its depth during the
> session he can do that 
> by making the DON values sparse.
> 
> Cheers
> 
> Magnus Westerlund
> 
> IETF Transport Area Director & TSVWG Chair
>
----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM/M
>
----------------------------------------------------------------------
> Ericsson AB                | Phone +46 8 4048287
> Torshamsgatan 23           | Fax   +46 8 7575550
> S-164 80 Stockholm, Sweden | mailto:
> magnus.westerlund@ericsson.com
>
----------------------------------------------------------------------
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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



From avt-bounces@ietf.org Fri Apr 27 04:59:17 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HhMIO-0007cO-2K; Fri, 27 Apr 2007 04:59:16 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HhMIM-0007Yp-J9
	for avt@ietf.org; Fri, 27 Apr 2007 04:59:14 -0400
Received: from web42108.mail.mud.yahoo.com ([209.191.86.241])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HhMIL-0005k3-6A
	for avt@ietf.org; Fri, 27 Apr 2007 04:59:14 -0400
Received: (qmail 78536 invoked by uid 60001); 27 Apr 2007 08:59:12 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID;
	b=MkMjBNZ+Q+Z4VpvI4eoLllWuDalkYLx4BSYPDaWw34jP/SJkHx/NaGIdwdFsb9qScPVLQuNlg63Sa1sDohAyVKYOhHktB63Ks/FsOhn/j5n6ak/oZ+cUzBXi53Mr+W6IzkjLAbJxIEJh3fv5nTgyiXBFdlUm0Pj4WXt8zU9Dg/M=;
X-YMail-OSG: HGyulL8VM1nrSa_ZgpDgDOPD6o1IMouEJJT4Bi3e6ljsg0Ich7O_ymDyla3DoM6A7FnLF9LpyHp9sfZkAwPqMqxrZpoyOthC70g1bjoDktvAB3c-
Received: from [202.84.165.223] by web42108.mail.mud.yahoo.com via HTTP;
	Fri, 27 Apr 2007 01:59:12 PDT
Date: Fri, 27 Apr 2007 01:59:12 -0700 (PDT)
From: sona chalam <sona_kk@yahoo.com>
Subject: Re: [AVT] H264 interleaving method
To: sona chalam <sona_kk@yahoo.com>,
	Magnus Westerlund <magnus.westerlund@ericsson.com>
In-Reply-To: <67007.3363.qm@web42103.mail.mud.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Message-ID: <555260.72592.qm@web42108.mail.mud.yahoo.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee
Cc: a22339@motorola.com, avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org



Hi Mganus

In my previous mail i was refering some doubts in
AbsDon. 

I think i did a mistake while calculating AbsDon.
It never becomes negative. It won't wrap around like
DON.

So in that case I can always send the NALs in AbsDon
order
once my AbsDon-diff(m,n) is greates than
sprop-max-don-diff or Number of VCL NAL units greater
sprop-interleaving-depth.

So while calcualting sprop-deinterleaving-depth do i
ignore NON VCL NAL units?.

So please clarify my doubts?

1.For streaming session will the spop-max-don-diff
should always be present?

2.If I arrange the NALs in AbsDon order is it same as
decoding order?

3. Do I need to exclude the Non VCL NAL units while
counting the sprop-deinterleaving-depth?


Thanks Regards
K.Sonachalam.



 .
--- sona chalam <sona_kk@yahoo.com> wrote:

> Hi Magnus 
> 
> Thanks for your reply.Can you clarify a bit more
> also
> 
> Still I have few queries.
> 
> sprop-max-don-diff method
> 
> I have issues here. since the sprop-max-don-diff is
> a
> optional parameters it is not gauranteed that I will
> get this sprop-don-diff value always.
> 
> Secondly If i arrange the NAL units in Absodn order
> will it same as decoding order? Till DON value
> reaches
> 65536 both DON and AbsDon will be same ?
> 
> But how to handle when the  DON value reaching
> 65535. 
> 
> So in that case my Absdon  can become negative.
> 
> As per the formula given in the RFC 
> 
> If DON(m)<DON(n)  and n-m >32768
> 
> AbdDon(n)=Absdon(m) -(Don(m)+65536-Don(n)). 
> 
> How to handle this?.
> 
> I thought of rearranging the NAL  by ascending order
> of DON  and i can send it to the decoder once it
> reaches sprop-deinterleaving-depth is reached.
> 
> And also  i can over come the DON (roll over after
> 65526 if  i use 32 bit value for that.So that i can
> simply arrange the DON in ascending order into my
> buffer
> 
> And also in H264 interleaving is done between Staps
> or
> Mtaps and with in an STAP or MTAP the NALs will be
> in
> same order. 
> 
> Your inoput and suggestion is required.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> --- Magnus Westerlund
> <magnus.westerlund@ericsson.com>
> wrote:
> 
> > sona chalam skrev:
> > > Hello
> > > 
> > > I am trying to implement interleaved
> packetization
> > > mode for a packet switched streaming(PSS)
> client.
> > > 
> > > I have gone through the RFC but not very clear
> > about
> > > when to start deinterleaving(arranging the
> > received
> > > NALs in decoding order).
> > > 
> > > 
> > > 
> > > Method 1 Sprop-interleaving-depth
> > > 
> > > As per my understanding  I can  start
> > deinterleaving
> > > once i receive N number of VCL NAL units.
> > > 
> > > So i will be accumualting NALs in my bufer and
> > have a
> > > count on the number of VCL NALs. Once I have N
> VCL
> > NAL
> > > units i will perform the logic of
> deinterleaving.
> > > 
> > > Please guide me whether my understanding of
> > > Sprop-interleaving-depth is correct or not.
> > > 
> > > If it is correct how  ot handle packet loss
> cases.
> > 
> > > 
> > > Example 
> > > If Sprop-interleaving-depth is 30 and 
> > >  I have received 20 VCL NALs and I miss few
> > packets. 
> > > Then i receive few more VCL NALs can i add it to
> > the
> > > same buffer  and wait till reaches 30 ?
> > > 
> > > Hoe to handle this?.
> > > 
> > > Basically I need to know on what basis i can
> start
> > > deinterleaving?
> > > 
> > > Waiting for your reply.
> > > 
> > 
> > First, we expect that you have deinterleave the
> > packets on the fly when 
> > they arrive and put the NALU into the buffer. The
> > issue is when to 
> > remove them from the buffer.
> > Sprop-interleaving-depth provides an upper 
> > limit in regards to how many NALUs you need to
> > buffer. However the 
> > sprop-max-don-diff can help a great deal. When the
> > DON values for NALUS 
> > in the buffer has larger diff from the lowest to
> the
> > highest is larger 
> > than the max-don-diff value then they are moved to
> > the decoder. That way 
> > the packet loss will be handled as the next packet
> > arrives and also if 
> > the sender likes to reduce its depth during the
> > session he can do that 
> > by making the DON values sparse.
> > 
> > Cheers
> > 
> > Magnus Westerlund
> > 
> > IETF Transport Area Director & TSVWG Chair
> >
>
----------------------------------------------------------------------
> > Multimedia Technologies, Ericsson Research
> EAB/TVM/M
> >
>
----------------------------------------------------------------------
> > Ericsson AB                | Phone +46 8 4048287
> > Torshamsgatan 23           | Fax   +46 8 7575550
> > S-164 80 Stockholm, Sweden | mailto:
> > magnus.westerlund@ericsson.com
> >
>
----------------------------------------------------------------------
> > 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam
> protection around 
> http://mail.yahoo.com 
> 
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www1.ietf.org/mailman/listinfo/avt
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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



From avt-bounces@ietf.org Fri Apr 27 08:28:23 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HhPYV-0007dP-QM; Fri, 27 Apr 2007 08:28:07 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HhPYU-0007d0-G0
	for avt@ietf.org; Fri, 27 Apr 2007 08:28:06 -0400
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhPYJ-0005fd-PW
	for avt@ietf.org; Fri, 27 Apr 2007 08:27:57 -0400
Received: from mailgw4.ericsson.se (unknown [127.0.0.1])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	393852189B; Fri, 27 Apr 2007 14:27:55 +0200 (CEST)
X-AuditID: c1b4fb3e-af1edbb0000061ca-33-4631ec4b5177 
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	221352188C; Fri, 27 Apr 2007 14:27:55 +0200 (CEST)
Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by
	esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 27 Apr 2007 14:27:54 +0200
Received: from [147.214.30.247] ([147.214.30.247]) by
	esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 27 Apr 2007 14:27:54 +0200
Message-ID: <4631EC4A.70408@ericsson.com>
Date: Fri, 27 Apr 2007 14:27:54 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: sona chalam <sona_kk@yahoo.com>
Subject: Re: [AVT] H264 interleaving method
References: <555260.72592.qm@web42108.mail.mud.yahoo.com>
In-Reply-To: <555260.72592.qm@web42108.mail.mud.yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 27 Apr 2007 12:27:54.0504 (UTC)
	FILETIME=[7AE4E880:01C788C7]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Cc: a22339@motorola.com, avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

sona chalam skrev:
> 
> Hi Mganus
> 
> In my previous mail i was refering some doubts in
> AbsDon. 
> 
> I think i did a mistake while calculating AbsDon.
> It never becomes negative. It won't wrap around like
> DON.
> 
> So in that case I can always send the NALs in AbsDon
> order
> once my AbsDon-diff(m,n) is greates than
> sprop-max-don-diff or Number of VCL NAL units greater
> sprop-interleaving-depth.
> 
> So while calcualting sprop-deinterleaving-depth do i
> ignore NON VCL NAL units?.
> 
> So please clarify my doubts?
> 
> 1.For streaming session will the spop-max-don-diff
> should always be present?

No, guarantees. As you say this is optional.

> 
> 2.If I arrange the NALs in AbsDon order is it same as
> decoding order?

decoding order is decoding order. The DON values are simply a wrapped 
representation of this.

> 
> 3. Do I need to exclude the Non VCL NAL units while
> counting the sprop-deinterleaving-depth?
> 

Good question, I can't remember. Does the RFC says something on this?

cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

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



From avt-bounces@ietf.org Sun Apr 29 06:38:58 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hi6nm-0003xv-9z; Sun, 29 Apr 2007 06:38:46 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hi6nk-0003xo-R1
	for avt@ietf.org; Sun, 29 Apr 2007 06:38:44 -0400
Received: from fw.polycom.co.il ([212.179.41.2]
	helo=isrexch01.israel.polycom.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hi6nj-0005na-7H
	for avt@ietf.org; Sun, 29 Apr 2007 06:38:44 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Sun, 29 Apr 2007 13:39:10 +0300
Message-ID: <144ED8561CE90C41A3E5908EDECE315C0484EB4F@IsrExch01.israel.polycom.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: working group last call on draft-ietf-avt-rtp-evrc-wb-01
Thread-Index: AceKSp8ezo3UZRdsTjCuF1qB22PLOw==
From: "Even, Roni" <roni.even@polycom.co.il>
To: <avt@ietf.org>
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407
Cc: Colin Perkins <csp@csperkins.org>, Tom-PT Taylor <taylor@nortel.com>
Subject: [AVT] working group last call on draft-ietf-avt-rtp-evrc-wb-01
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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-Type: multipart/mixed; boundary="===============0527218181=="
Errors-To: avt-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0527218181==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C78A4A.8DA20D60"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C78A4A.8DA20D60
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

=20

Hi,

=20

Announcing work group last call for draft-ietf-avt-rtp-evrc-wb-01.txt =
<http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-evrc-wb-01.txt> =
,

RTP payload format for EVRC-WB codec and MIME updates for EVRC-B codec

=20

The last call period will be two weeks expiring on Saturday, May 12.

=20

Roni Even will be the PROTO Shepherd for this document

=20

=20

=20


------_=_NextPart_001_01C78A4A.8DA20D60
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PersonName"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 77.95pt 72.0pt 77.95pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Hi,<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Announcing work group last call for <a
href=3D"http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-evrc-wb-01=
.txt">draft-ietf-avt-rtp-evrc-wb-01.txt</a>,<o:p></o:p></span></font></p>=


<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>RTP payload format for EVRC-WB codec and MIME updates for EVRC-B =
codec<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>The last call period will be two weeks expiring on Saturday, May =
12.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><st1:PersonName ProductID=3D"Roni Even" =
w:st=3D"on"><font
 size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>Roni =
Even</span></font></st1:PersonName>
will be the PROTO Shepherd for this document<o:p></o:p></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C78A4A.8DA20D60--


--===============0527218181==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0527218181==--




From avt-bounces@ietf.org Mon Apr 30 15:51:00 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hibtc-0005lC-J1; Mon, 30 Apr 2007 15:50:52 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HibtK-00058X-3W; Mon, 30 Apr 2007 15:50:34 -0400
Received: from ns4.neustar.com ([156.154.24.139])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1HibtI-00032y-OB; Mon, 30 Apr 2007 15:50:34 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id A78C22AC79;
	Mon, 30 Apr 2007 19:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1Hibso-0001lA-Em; Mon, 30 Apr 2007 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1Hibso-0001lA-Em@stiedprstage1.ietf.org>
Date: Mon, 30 Apr 2007 15:50:02 -0400
X-Spam-Score: -2.5 (--)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Cc: avt@ietf.org
Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-no-op-03.txt 
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

--NextPart

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

	Title		: A No-Op Payload Format for RTP
	Author(s)	: F. Andreasen, et al.
	Filename	: draft-ietf-avt-rtp-no-op-03.txt
	Pages		: 12
	Date		: 2007-4-30
	
This document defines an no-op payload format for the Real-time
   Transport Protocol (RTP).  This packet is not played out by
   receivers.  It can be useful as a way to keep Network Address
   Translator (NAT) bindings and Firewall pinholes open.  Other uses are
   discussed in the document.

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

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

Content-Type: text/plain
Content-ID: <2007-4-30144757.I-D@ietf.org>

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

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

Content-Type: text/plain
Content-ID: <2007-4-30144757.I-D@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--NextPart--




From avt-bounces@ietf.org Mon Apr 30 18:38:30 2007
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HieVk-0001bp-6b; Mon, 30 Apr 2007 18:38:24 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HieVi-0001bk-H7
	for avt@ietf.org; Mon, 30 Apr 2007 18:38:22 -0400
Received: from mr1.dcs.gla.ac.uk ([130.209.249.184])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HieVh-00008J-0e
	for avt@ietf.org; Mon, 30 Apr 2007 18:38:22 -0400
Received: from csperkins-dsl.demon.co.uk ([62.49.4.249]:61725
	helo=[192.168.0.3])
	by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42)
	id 1HieVg-0006HU-5a; Mon, 30 Apr 2007 23:38:20 +0100
In-Reply-To: <E1HeIyQ-00038R-95@stiedprstage1.ietf.org>
References: <E1HeIyQ-00038R-95@stiedprstage1.ietf.org>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <C257C52A-BDF1-49C3-AA4D-4489EDD1ABF7@csperkins.org>
Content-Transfer-Encoding: 7bit
From: Colin Perkins <csp@csperkins.org>
Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-rtp-vorbis-03.txt 
Date: Mon, 30 Apr 2007 23:38:00 +0100
To: Luca Barbato <lu_zero@gentoo.org>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027
Cc: IETF AVT WG <avt@ietf.org>
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Errors-To: avt-bounces@ietf.org

Hi Luca,

On 18 Apr 2007, at 23:50, Internet-Drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Audio/Video Transport Working  
> Group of the IETF.
>
> 	Title		: RTP Payload Format for Vorbis Encoded Audio
> 	Author(s)	: L. Barbato
> 	Filename	: draft-ietf-avt-rtp-vorbis-03.txt
> 	Pages		: 25
> 	Date		: 2007-4-18
> 	
> This document describes an RTP payload format for transporting Vorbis
>    encoded audio.  It details the RTP encapsulation mechanism for raw
>    Vorbis data and details the delivery mechanisms for the decoder
>    probability model, referred to as a codebook and other setup
>    information.
>
>    Also included within this memo are media type registrations, and  
> the
>    details necessary for the use of Vorbis with the Session  
> Description
>    Protocol (SDP).
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-vorbis-03.txt

I just reviewed this draft in detail, with the aim of getting it  
ready for publication, and found a some more issues:

Section 2.1 (timestamp): "...conveyed out-of-band as a SDP  
parameter." -> "...conveyed out-of-band (e.g. as an SDP parameter)."

Section 2.2 (last paragraph): I suggest clarifying that "The payload  
MUST be either a single fragment of a Vorbis packet, or one or more  
complete Vorbis packets". This is described in section 5, but it  
doesn't hurt to be explicit here.

Section 2.3 (2nd paragraph): I assume Vorbis decoders will parse the  
bit stream  to determine if padding has been added, so there's no  
need to explicitly signal how much padding is present? Also, does the  
value of the padding bits matter? A few words of clarification would  
be useful.

Section 2.4: I think it would be clearer if figures 4 and 5 were  
combined into a single figure, as done for the later examples. Also,  
the figure makes it look like the complete packet is 32 bit aligned:  
to avoid confusion, including the length of the vorbis data packets,  
and showing that the resulting RTP packet is not a multiple of 32  
bits would be good.

Section 3 (1st paragraph): expand the acronym "VQ" on first use.

Section 3 (3rd paragraph): "SDP delivery is used" -> "SDP delivery is  
typically used" since other options are possible.

Section 3 (4th paragraph): "The delivery vectors in use are specified  
by..." -> "...can be specified by..." since, again, something other  
than SDP might be used to configure this in future.

Section 3 (4th paragraph): Delete the last word in the paragraph  
("section"), it's redundant.

Section 3.1.1 (1st paragraph): Do the identification and setup  
headers end on byte boundaries, or is there a need to include  
padding? If padding is needed, is it added between the two headers,  
or after both? (i.e. does the setup header always start on a byte  
boundary?)

Section 3.1.1 (1st paragraph): might be clearer if normative language  
is used: "The packet configuration packet MUST include the  
identification header, followed by the setup header. It MUST NOT  
include the comment header." or similar?

Section 3.2.1: clarify that the initial 32 bit count field is in  
network byte order. Also, would it be useful for debugging and  
validity checks for the format to start with a magic number?

Section 5.1: rather than using "xxxxx" for the timestamp, suggest  
picking a hex value as an example.

Section 6: clarify that the delivery-method and configuration  
parameters may be included multiple times; and that configuration  
parameters follow the associated delivery-method parameter.

Section 7: "MIME" -> "Media Type" throughout, since this isn't email.

Section 7: "a=fmpt" -> "a=fmtp" (typo, occurs twice)

Section 7 (last paragraph): "in the c attribute" -> "in the c=  
line" (it isn't an attribute in SDP).

Section 7.1.1: typo "lenght"

Section 10: are there any security considerations due to the need to  
fetch code books? At the least, it should mention that codebooks are  
(potentially) fetched from Internet sites, which can leak information  
on when a certain stream is played, and so is a potential privacy  
risk. Not sure if there's anything else to mention?

With these changes, I think the draft will be in a suitable shape for  
publication. If you have nothing more to do to the draft, we can  
consider starting the media type review and working group last call,  
once a revision to address these comments is available.

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



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