From avt-bounces@ietf.org Sun Apr 01 05:05:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 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: References: <006301c772dd$b6ab7fa0$0fa2ee0a@viola> From: "Jaehwan Kim" To: "Y. Matsui" , , 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 List-Unsubscribe: , List-Post: List-Help: List-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: 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 Re: [AVT] Video streaming withour = RTCP=0A= =0A= =0A= =0A=
=0A=
Hi,
=0A=
Yes. However, I found = many players and servers couldn't handle some strings like = "client_port=3D3122;server=3D12100".
=0A=
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. 
=0A=
 
=0A=
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.
=0A=
 
=0A=
Regards,
=0A=
Jaehwan
=0A=

=0A=
=0A= 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

=0A=
=0A=

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,
> 
>     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/Vid= eo Transport Working Group
avt@ietf.org
https://www1.ietf.org= /mailman/listinfo/avt

------_=_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: 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 , 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: To: "'Jaehwan Kim'" , "'Y. Matsui'" , 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: 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1935716131==" Errors-To: avt-bounces@ietf.org Message-Id: 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: 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 Re: [AVT] Video streaming withour RTCP

Hi,

=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!!

 

Thanks & regards, =

Vamsi

 

From: = Jaehwan Kim [mailto:jaehwan@vidiator.com]
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

 

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. 

 

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.

 

Regards,

Jaehwan

 

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,
> 
>     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-- --===============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: 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> <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: Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [AVT] AVC NALUs RTP packetisation Date: Sun, 1 Apr 2007 13:29:13 +0100 To: Nikola Sprljan 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 List-Unsubscribe: , List-Post: List-Help: List-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: 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: In-Reply-To: References: <006301c772dd$b6ab7fa0$0fa2ee0a@viola> Date: Sun, 1 Apr 2007 07:53:40 -0700 To: "Jaehwan Kim" From: Ross Finlayson Subject: RE: [AVT] Video streaming withour RTCP X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: "Y. Matsui" , 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 List-Unsubscribe: , List-Post: List-Help: List-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" RE: [AVT] Video streaming withour RTCP
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============-- --===============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: 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: In-Reply-To: References: <006301c772dd$b6ab7fa0$0fa2ee0a@viola> From: "Jaehwan Kim" To: "Ross Finlayson" X-Spam-Score: 0.0 (/) X-Scan-Signature: 40161b1d86420e0807d771943d981d25 Cc: "Y. Matsui" , 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 List-Unsubscribe: , List-Post: List-Help: List-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 RE: [AVT] Video streaming withour RTCP

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.

 =

Jaehwan

 =

 =

From: Ross Finlayson [mailto:finlayson@live555.com]
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

 

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/

------_=_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: 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: 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" To: 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 List-Unsubscribe: , List-Post: List-Help: List-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 =0D=0A=0D=0A= =0D=0A=0D=0A=0D=0AParameters lost for media type MPA in new R= FC4856 ?=0D=0A=0D=0A=0D=0A=0D=0A
=0D=0A=0D=0A

Dear RFC = editors,=0D=0A

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

I hav= e one question regarding the new RFC4855 and RFC4856 that obsolete RFC3555:= =0D=0A

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

- Where are p= arameters for MPA (mpeg audio) specified ? They were in RFC3555 (4=2E1=2E17= ) but not anymore in RFC4856=2E=0D=0A

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

As I have understood from RFC4855/4856, parameters shou= ld now be specified in payload format RFCs=2E=0D=0A=0D=0A
However looking in RFC2250 for MPEG payload format (= video and audio) I don't see a specification of these parameters=2E= =0D=0A=0D=0A
Looking on IANA pages, media = type MPA still point on RFC3555=2E=0D=0A

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

Could you please tell me where to point now for MPEG a= udio parameters ?=0D=0A

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

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 ?)

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

= 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

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

Th= ank you=0D=0A

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

Regard= s,=0D=0A

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

Mathias Coi= nchon=0D=0A=0D=0A
Senior Engineer=0D=0A=0D=0A
Technical Department=0D=0A

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

European Broadcas= ting Union=0D=0A=0D=0A
L'Ancienne-R= oute 17A=0D=0A=0D=0A
1218 Grand-Sac= onnex=0D=0A=0D=0A
Switzerland=0D=0A

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

Tel +41 22 717 27 1= 6=0D=0A=0D=0A
Fax +41 22 747 47 16<= /FONT>=0D=0A

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

=0D=0A

=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

------_=_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: 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 User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Jaehwan Kim Subject: Re: [AVT] Video streaming withour RTCP References: <006301c772dd$b6ab7fa0$0fa2ee0a@viola> In-Reply-To: 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 , "Y. Matsui" , avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org 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: 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: 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> <1C1F3D15859526459B4DD0A7A9B2268B03488F9D@trebe101.NOE.Nokia.com> <460A45A5.4090908@vil.ite.mee.com> <1C1F3D15859526459B4DD0A7A9B2268B034B42FB@trebe101.NOE.Nokia.com> <460CE89F.7060000@vil.ite.mee.com> From: To: , 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 List-Unsubscribe: , List-Post: List-Help: List-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: 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: In-Reply-To: <4610AB4C.1080807@ericsson.com> References: <006301c772dd$b6ab7fa0$0fa2ee0a@viola> <4610AB4C.1080807@ericsson.com> From: "Jaehwan Kim" To: "Magnus Westerlund" , "Ross Finlayson" X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: annasagaram.vamsi@aftek.com, avt@ietf.org, "Y. Matsui" X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Dear 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: 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 ; 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" To: "Magnus Westerlund" 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: <006301c772dd$b6ab7fa0$0fa2ee0a@viola> <4610AB4C.1080807@ericsson.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: Jaehwan Kim , Ross Finlayson , annasagaram.vamsi@aftek.com, avt@ietf.org, "Y. Matsui" X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org 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 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: 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 To: "Coinchon, Mathias" Subject: Re: [AVT] Parameters lost for media type MPA in new RFC4856 ? In-Reply-To: Message-ID: <20070402121602.F89535@hsa> References: 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 List-Unsubscribe: , List-Post: List-Help: List-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: 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 ; 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: In-Reply-To: <20070402121602.F89535@hsa> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Confusion regarding RTP Thread-Index: Acd1XKnmz8/3t3H8QSCt9riNlZJTIAAZfNsQ References: <20070402121602.F89535@hsa> From: "Bhattacharya, Abhijit \(Abhijit\)" To: 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 List-Unsubscribe: , List-Post: List-Help: List-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: 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 User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Bhattacharya, Abhijit \(Abhijit\)" Subject: Re: [AVT] Confusion regarding RTP References: <20070402121602.F89535@hsa> In-Reply-To: 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 List-Unsubscribe: , List-Post: List-Help: List-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: 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: 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: <20070402121602.F89535@hsa> <4612154C.3090205@ericsson.com> From: "Bhattacharya, Abhijit \(Abhijit\)" To: "Magnus Westerlund" 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 List-Unsubscribe: , List-Post: List-Help: List-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: 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 User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Bhattacharya, Abhijit \(Abhijit\)" Subject: Re: [AVT] Confusion regarding RTP References: <20070402121602.F89535@hsa> <4612154C.3090205@ericsson.com> In-Reply-To: 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 List-Unsubscribe: , List-Post: List-Help: List-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: 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" To: "Magnus Westerlund" , "Bhattacharya, Abhijit (Abhijit)" References: <20070402121602.F89535@hsa><4612154C.3090205@ericsson.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 List-Unsubscribe: , List-Post: List-Help: List-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 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" To: "Bhattacharya, Abhijit (Abhijit)" Cc: 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: 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 ; 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 ) 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 User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Magnus Westerlund Subject: Re: [AVT] Confusion regarding RTP References: <20070402121602.F89535@hsa> <4612154C.3090205@ericsson.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 List-Unsubscribe: , List-Post: List-Help: List-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: 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 ; 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 ) 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 User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: avt@ietf.org Subject: Re: [AVT] Confusion regarding RTP References: <20070402121602.F89535@hsa> <4612154C.3090205@ericsson.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 List-Unsubscribe: , List-Post: List-Help: List-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: 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: <20070402121602.F89535@hsa> <4612154C.3090205@ericsson.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: Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [AVT] Confusion regarding RTP Date: Tue, 3 Apr 2007 11:44:47 +0100 To: Nikola Sprljan X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: Magnus Westerlund , avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , 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: 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: 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: <20070402121602.F89535@hsa> <4612154C.3090205@ericsson.com> <4612188E.90507@ericsson.com> <46122B93.4050507@vil.ite.mee.com> From: "Bhattacharya, Abhijit \(Abhijit\)" To: "Nikola Sprljan" , "Magnus Westerlund" , "Pete Cordell" 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 List-Unsubscribe: , List-Post: List-Help: List-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 #include #include #include #include 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: 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 ; 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 ) 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 User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Bhattacharya, Abhijit \(Abhijit\)" Subject: Re: [AVT] Confusion regarding RTP References: <20070402121602.F89535@hsa> <4612154C.3090205@ericsson.com> <4612188E.90507@ericsson.com> <46122B93.4050507@vil.ite.mee.com> In-Reply-To: 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 List-Unsubscribe: , List-Post: List-Help: List-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: 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: 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: <20070402121602.F89535@hsa> <4612154C.3090205@ericsson.com> <4612188E.90507@ericsson.com> <46122B93.4050507@vil.ite.mee.com> <46123710.1070805@vil.ite.mee.com> From: "Bhattacharya, Abhijit \(Abhijit\)" To: "Nikola Sprljan" 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 List-Unsubscribe: , List-Post: List-Help: List-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: 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: 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: <20070402121602.F89535@hsa> <4612154C.3090205@ericsson.com> <4612188E.90507@ericsson.com> <46122B93.4050507@vil.ite.mee.com> <46123710.1070805@vil.ite.mee.com> From: "Bhattacharya, Abhijit \(Abhijit\)" To: "Nikola Sprljan" 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 List-Unsubscribe: , List-Post: List-Help: List-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: 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: 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: <20070402121602.F89535@hsa> <4612154C.3090205@ericsson.com> <4612188E.90507@ericsson.com> <46122B93.4050507@vil.ite.mee.com><46123710.1070805@vil.ite.mee.com> From: "Desineni, Harikishan" To: "Bhattacharya, Abhijit \(Abhijit\)" 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 List-Unsubscribe: , List-Post: List-Help: List-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: 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" To: 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 List-Unsubscribe: , List-Post: List-Help: List-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: 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 ; 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" 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 List-Unsubscribe: , List-Post: List-Help: List-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: 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" Subject: Re: [AVT] default packetization interval for pcmu, pcma and iLBC References: <4e5a3720704050642p5f76ba0ek95e97063a47f52c6@mail.gmail.com> From: Randell Jesup 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: 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 List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org "Murat Artun" 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: 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: 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : 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: 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: 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP payload format for EVRC-WB codec and 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: 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: 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : A 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: 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: 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload Format for 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: 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: 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: 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : 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: 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: 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload Format for Vorbis Encoded Audio Author(s) : L. Barbato Filename : draft-ietf-avt-rtp-vorbis-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: 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: 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: 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload Format for 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: 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" To: , "Tom-PT Taylor" 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 List-Unsubscribe: , List-Post: List-Help: List-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

Tom,

I finally finished reading the = document.

In general it looks ready to me.

 

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

 

I looked at h= ttp://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.

 

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

 

 

Some typos:

 

1.    section 2.3.2 fgrequencies – frequencies

2.    =A0section 3 desribed – described

 

 

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

>

> Hi,

>

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

> Definition of Events For Channel-Oriented Telephony = Signaling.

>

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

>

> Roni = Even will be the PROTO Shepherd for this document

>

>

>

>

>

>

> = _______________________________________________

> Audio/Video Transport Working Group

> avt@ietf.org

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

------_=_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: 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: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: IETF AVT WG From: Colin Perkins 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 List-Unsubscribe: , List-Post: List-Help: List-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: 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 List-Unsubscribe: , List-Post: List-Help: List-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: 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 ; 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" 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 List-Unsubscribe: , List-Post: List-Help: List-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,

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-- --===============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: 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 ; 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 ; 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 User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Greg Shepherd 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 List-Unsubscribe: , List-Post: List-Help: List-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: 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: 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" To: , 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 List-Unsubscribe: , List-Post: List-Help: List-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: 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: References: 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 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 , David R Oran , Dan Wing X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: IETF AVT WG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , 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: 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" To: "'Colin Perkins'" , "'Flemming Andreasen'" , "'David R Oran'" 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 |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' , 'IETF AVT WG' X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , 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 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: 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: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Colin Perkins 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 , Satoshi Futemma , ITAKURA Eisaburo X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: IETF AVT WG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , 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: 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 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 , Cullen Jennings X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Flemming Andreasen , MARJOU Xavier RD-MAPS-LAN , David R Oran , IETF AVT WG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , 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 > 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: 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: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Colin Perkins 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 , Andrew Leung , ITAKURA Eisaburo X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: IETF AVT WG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , 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: 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: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Colin Perkins 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 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: IETF AVT WG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , 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: 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 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 , Cullen Jennings X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Flemming Andreasen , MARJOU Xavier RD-MAPS-LAN , David R Oran , IETF AVT WG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , 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 > 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: 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: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Colin Perkins 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 , Andrew Leung , ITAKURA Eisaburo X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: IETF AVT WG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , 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: 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: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Colin Perkins 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 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: IETF AVT WG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , 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: 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 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 , Cullen Jennings X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Flemming Andreasen , MARJOU Xavier RD-MAPS-LAN , David R Oran , IETF AVT WG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , 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 > 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: 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: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Colin Perkins 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 , Andrew Leung , ITAKURA Eisaburo X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: IETF AVT WG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , 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: 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: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Colin Perkins 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 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: IETF AVT WG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , 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: 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 ; 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" To: "Dan Wing" , "Colin Perkins" 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 , Flemming Andreasen , David R Oran , IETF AVT WG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , 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: 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" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Cullen Jennings 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 , Roni Even , iesg-secretary@ietf.org, IETF AVT WG , Colin Perkins 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 List-Unsubscribe: , List-Post: List-Help: List-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 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: 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 User-Agent: Thunderbird 1.5.0.10 (X11/20070314) MIME-Version: 1.0 To: Colin Perkins , avt@ietf.org Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-rtp-vorbis-02.txt References: In-Reply-To: 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 List-Unsubscribe: , List-Post: List-Help: List-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: 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: 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : A 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: 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: 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : 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: 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: 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload Format for 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: 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: <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 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 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 List-Unsubscribe: , List-Post: List-Help: List-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: 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: 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload Format for Vorbis Encoded Audio Author(s) : L. Barbato Filename : draft-ietf-avt-rtp-vorbis-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: 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 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 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 |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\)" , MARJOU Xavier RD-MAPS-LAN , "Dave Oran \(oran\)" , IETF AVT WG , "Dan Wing \(dwing\)" X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org On 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: 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" 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 List-Unsubscribe: , List-Post: List-Help: List-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: 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: References: 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 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 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: IETF AVT WG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , 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: 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: Content-Transfer-Encoding: 7bit From: Colin Perkins Date: Mon, 23 Apr 2007 22:26:20 +0100 To: IETF AVT WG X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Roni Even , Tom-PT Taylor 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 List-Unsubscribe: , List-Post: List-Help: List-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: 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: 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" To: "Colin Perkins" , "IETF AVT WG" X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Tom-PT Taylor 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 List-Unsubscribe: , List-Post: List-Help: List-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: 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 User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Colin Perkins Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-rtp-jpeg2000-14.txt References: <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 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Dear 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: 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: <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 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 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: IETF AVT WG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , 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: 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: 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload Format for 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: 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" To: "Even, Roni" , 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 List-Unsubscribe: , List-Post: List-Help: List-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: 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: From: yusuke hiwasaki To: "Even, Roni" 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: <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 , Colin Perkins , IETF AVT WG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , 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: 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 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 List-Unsubscribe: , List-Post: List-Help: List-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: 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 User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: sona chalam 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 List-Unsubscribe: , List-Post: List-Help: List-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: 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 Subject: Re: [AVT] H264 interleaving method To: Magnus Westerlund 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 List-Unsubscribe: , List-Post: List-Help: List-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)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 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: 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 Subject: Re: [AVT] H264 interleaving method To: sona chalam , Magnus Westerlund 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 List-Unsubscribe: , List-Post: List-Help: List-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 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)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 > > 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: 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 User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: sona chalam 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 List-Unsubscribe: , List-Post: List-Help: List-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: 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" To: X-Spam-Score: 0.2 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Cc: Colin Perkins , Tom-PT Taylor 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 List-Unsubscribe: , List-Post: List-Help: List-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 = = , 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

 

Hi,

 

Announcing work group last call for draft-ietf-avt-rtp-evrc-wb-01.txt,

=

RTP payload format for EVRC-WB codec and MIME updates for EVRC-B = codec

 

The last call period will be two weeks expiring on Saturday, May = 12.

 

Roni = Even will be the PROTO Shepherd for this document

 

 

 

------_=_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: 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: 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : A 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: 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: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Colin Perkins 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 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: IETF AVT WG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , 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