RE: [AVT] Draft AVT agenda

"Leon David (NRC/Dallas)" <David.Leon@nokia.com> Mon, 03 December 2001 23:54 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13620 for <avt-archive@odin.ietf.org>; Mon, 3 Dec 2001 18:54:31 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA15023 for avt-archive@odin.ietf.org; Mon, 3 Dec 2001 18:54:31 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA14983; Mon, 3 Dec 2001 18:53:55 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA14954 for <avt@optimus.ietf.org>; Mon, 3 Dec 2001 18:53:53 -0500 (EST)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13607 for <avt@ietf.org>; Mon, 3 Dec 2001 18:53:52 -0500 (EST)
Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fB3NspQ19391 for <avt@ietf.org>; Mon, 3 Dec 2001 17:54:51 -0600 (CST)
Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id <T579a3fdafbac12f257079@davir04nok.americas.nokia.com>; Mon, 3 Dec 2001 17:53:50 -0600
Received: from daebe008.NOE.Nokia.com ([172.18.242.238]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 3 Dec 2001 17:53:50 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
Subject: RE: [AVT] Draft AVT agenda
Date: Mon, 03 Dec 2001 17:53:50 -0600
Message-ID: <7CA3477F476D7F4FB82F02960B79CEBD16F9AE@daebe008.NOE.Nokia.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Thread-Topic: [AVT] Draft AVT agenda
Thread-Index: AcF7w+BpTlg5Tue1EdWBUQBQi2X+DwAkRZSA
From: "Leon David (NRC/Dallas)" <David.Leon@nokia.com>
To: 'ext Colin Perkins' <csp@isi.edu>, avt@ietf.org
X-OriginalArrivalTime: 03 Dec 2001 23:53:50.0685 (UTC) FILETIME=[C1B280D0:01C17C55]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id SAA14955
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
X-BeenThere: avt@ietf.org
Content-Transfer-Encoding: 8bit

Hello,

We are planning to present an updated draft on the RTP retransmission
framewrok.
http://search.ietf.org/internet-drafts/draft-leon-rtp-retransmission-01.
txt
 
We have modified the draft in order to address the comments received at
the WG meeting as follows:
 
*The retransmission packet payload format has been modified to better
use RTP semantics.
 
*Associating retransmission stream and SSRC:
Retransmissions are required to be sent to a different multicast group
from the original data. The original stream and the retransmission
stream should have the same SSRC
 
*Why not use the same SSRC and send to the same multicast group with a
different PT?
Original packets and retransmission packets would then have to share the
same SN space. We think this would have several drawbacks:
If packet loss has not been recovered, a receiver does not know if the
missing packets are retransmitted packets or new data. This has
drawbacks. For example, RTP conversational text (RFC 2793) uses missing
sequence numbers to indicate missing text location to the user. This
could not  be done reliably any longer.
A receiver should estimate the TS of a missing packet before requesting
its retransmission in order to determine if the packet if retransmitted
could be received before its playout time. Depending on whether the
missing packet contains first time sent data or retransmission data
(which the receiver would not know if these two types of packets were
found in the same stream) the TS may vary significantly and its
estimation may be wrong. 
Besides, RTCP jitter value would become meaningless.
  
*The same can be achieved with existing RLM and FEC techniques
The FEC payload format may be used as an alternative to the
retransmission format. However, we think it should be possible to use
retransmission without having to implement FEC. It therefore makes sense
to define a simple retransmission payload format.  Moreover we are not
only defining the payload format but also protocol rules to perform
retransmission. 

We are also planning to show performance evaluation results.
 

David.

> -----Original Message-----
> From: ext Colin Perkins [mailto:csp@isi.edu]
> Sent: Monday, December 03, 2001 12:29 AM
> To: avt@ietf.org
> Subject: [AVT] Draft AVT agenda
> 
> 
> Folks,
> 
> Enclosed is the draft agenda for the AVT working group 
> meeting at the Salt
> Lake City IETF. Please send comments and corrections to the 
> working group
> chairs, by Tuesday 4th December.
> 
> Those who have agenda time scheduled are requested to prepare 
> a summary of
> the issues they wish to discuss, and to send this to the 
> mailing list ahead
> of the meeting. This gives folks that won't be attending the 
> opportunity to 
> post their comments and concerns, and potentially even reach 
> some consensus, 
> before the meeting time is consumed. It also gives other 
> participants the 
> opportunity to consider the issue in more depth. Summary 
> messages should be 
> sent to the mailing list by Tuesday 4th December.
> 
> We also request that all presenters send us their slides 
> ahead of time. This 
> has multiple purposes:
> 
>   - It streamlines the presentation process by having the 
> presentations on 
>     a single laptop.
> 
>   - It avoids the delay that sometimes occurs in getting the 
> presentations
>     sent to us after the meeting, for inclusion in the minutes.
> 
>   - It allows us to preview the presentations to see if they 
> are following 
>     the guidelines for what should be covered during the meeting.
> 
> Those presenting new drafts: briefly describe the basic 
> problem and your
> proposed solution, discuss known issues, limitations and 
> problems, outline
> where you want input from the working group, and how you wish 
> us to proceed.
> When presenting work which has been previously discussed: 
> describe only the
> changes from the previous draft, highlight unresolved 
> problems, and propose
> future directions. Presenters are reminded of the 
> requirements for disclosure 
> of intellectual property relating to contributions, in 
> section 10 of RFC 2026. 
> 
> Agenda time is conditional on sending both a summary of open 
> issues and a
> copy of your slides ahead of the meeting.
> 
> We strongly encourage all participants to read all relevent 
> drafts before 
> the meeting, and to comment on the open issues raised on the 
> mailing list. 
> 
> Thanks for your assistance to try to conduct an effective meeting.
> 
> Colin & Steve
> 
> 
> 
> ==============================================================
> =================
> Audio/Video Transport WG (AVT)
> 
> Monday, December 10 at 1930-2200
> Wednesday, December 12 at 0900-1130
> ===================================
> 
> CHAIRS: Steve Casner <casner@acm.org>
>         Colin Perkins <csp@isi.edu>
> 
> AGENDA:
> 
> Session 1:
> 
> - Introduction and status (Casner/Perkins)			
> 	10
> 	Published or with RFC editor:
> 		RFC 3158
> 		draft-ietf-avt-dv-audio-04.txt
> 		draft-ietf-avt-dv-video-04.txt
> 	Under revision after IESG review:
> 		draft-ietf-avt-rtp-amr-10.txt
> 	Last call:
> 		draft-ietf-avt-crtp-enhance-03.txt
> 		draft-ietf-avt-tcrtp-04.txt
> 		draft-ietf-avt-uxp-01.txt
> 		draft-ietf-avt-ulp-02.txt 
> 		draft-ietf-avt-rtp-cn-04.txt
> 
> - RTP Payload formats for MPEG-4
> 	draft-ietf-avt-mpeg4-multiSL-02.txt 		
> (Gentric)	10
> 	draft-ietf-avt-mpeg4-simple-00.txt		(van 
> der Meer)	10
> 	draft-curet-avt-rtp-mpeg4-flexmux-01.txt 	(Roux)	
> 	10
> 
> - RTP payload format for GSM EFR speech			
> (Barany)	15
> 	draft-barany-avt-efr-00.txt
> 	draft-ietf-avt-profile-new-12.txt section 4.5.9
> 
> - RTP Payload Format for EVRC, SMV and Frame-Based Vocoders 
> (Li)	15
> 	draft-li-avt-vocoder-00.txt 
> 
> - RTP Payload Format for AC-3 Streams 			
> (Flaks)		15
> 	draft-flaks-avt-rtp-ac3-00.txt
> 
> - MWPP: A resilient MIDI RTP packetization 		
> (Lazzaro)	15
> 	draft-lazzaro-avt-mwpp-midi-nmp-00.txt
> 
> - RTP Payload Format for Distributed Speech Recognition	
> (Xie)		15
> 	draft-ietf-avt-dsr-00.txt
> 
> 
> 
> Session 2: 
> 
> - RTP payload format for JPEG 2000 video streams 	
> (Edwards)	15
> 	draft-edwards-avt-rtp-jpeg2000-00.txt
> 
> - Update to RTP specification and profile		
> (Casner)	15
> 	draft-ietf-avt-rtp-new-11.txt, .ps
> 	draft-ietf-avt-profile-new-12.txt, .ps
> 	draft-ietf-avt-rtp-mime-06.txt 
> 	draft-ietf-avt-rtcp-bw-05.txt
> 
> - Secure RTP profile					
> (Carrara)	15
> 	draft-ietf-avt-srtp-02.txt
> 
> - RTP extensions for classification and priority
> 	draft-carlberg-rtp-classifier-extension-00.txt	
> (Carlberg)	 5
> 	draft-polk-avt-rtpext-res-pri-00.txt		(Polk)	
> 	 5
> 	Discussion						
> 	10
> 
> - Extended RTP Profile for RTCP-based Feedback		
> (Ott)		15
> 	draft-ietf-avt-rtcp-feedback-01.txt
> 	draft-burmeister-avt-rtcp-feedback-sim-00.txt
> 
> - RTP retransmission
> 	draft-leon-retransmission-01.txt		(Leon)	
> 	15
> 	draft-ietf-avt-rtp-selret-03.txt
> 
> - RTCP Extension for SSM Sessions with Unicast feedback 
> (Chesterfield)	15
> 	draft-chesterfield-avt-rtcpssm-02.txt
> 
> - Extending RTCP for call quality metrics		
> (Massad)	 5
> 
> 
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> http://www1.ietf.org/mailman/listinfo/avt
> 

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