Subject: [AVT] I-D Action:draft-ietf-avt-forward-shifted-red-02.txt

From: [email-masked]
Date: Tue, 7 Oct 2008 13:30:02 -0700 (PDT)

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           : Forward-shifted RTP Redundancy Payload Support
	Author(s)       : Q. Xie
	Filename        : draft-ietf-avt-forward-shifted-red-02.txt
	Pages           : 13
	Date            : 2008-10-07

This document defines a simple enhancement to RFC 2198 to support RTP
sessions with forward-shifted redundant encodings, i.e., redundant
data sent before the corresponding primary data.  Forward-shifted
redundancy can be used to conceal losses of a large number of
consecutive media frames (e.g., consecutive loss of seconds or even
tens of seconds of media).

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: Qiaobing Xie <[email-masked]>
Date: Thu, 09 Oct 2008 14:05:05 -0500

Dear chairs,

I wonder if we can consider initiating WG last call on this I-D? It's 
been stable for a while and I only received minor comments on -01 
version (comments received are either responded on the list or 
incorporated in -02).

Your guidance will be appreciated.

regards,
-Qiaobing

[email-masked] wrote:
> ------------------------------------------------------------------------
>

---

From: Qiaobing Xie <[email-masked]>
Date: Thu, 09 Oct 2008 14:27:27 -0500

(re-sent with corrected cc-list)

Dear chairs,

regards,
-Qiaobing

---

From: "Mundra, Satish" <[email-masked]>
Date: Thu, 16 Oct 2008 13:20:32 -0500

Hi Qiaobing,

I have one minor comment on the forwardshift parameter defined on page 5.  I think the "forwardshift" value needs to be greater
than the "timestamp offset in the additional header" otherwise the redundant data will not be forward-shifted. A simpler alternative
would be to require that "timestamp offset in the additional header" MUST be set to '0' when forwardshift is used as assumed in
examples in appendix.

BR,

Satish Mundra

---

From: Qiaobing Xie <[email-masked]>
Date: Thu, 16 Oct 2008 19:39:29 -0500

Satish,

I totally agree with you that it would not make much sense if a session is setting both "forwardshift" and "timestamp offset in additional header" to some non-zero values. But if someone really wants to do that for whatever reason, the spec can still handle it correctly. Of cause the spirit for doing forward-shifting may be lost, as you pointed out below. But I think a "MUST" is a bit too strong here.

How about we add something like: 

"In a forward-shifted session, the timestamp offset in the additional header SHOULD be set to '0'".

regards,
-Qiaobing

---

From: "Mundra, Satish" <[email-masked]>
Date: Fri, 17 Oct 2008 10:31:54 -0500

Hi Qiaobing,

Yes, I think SHOULD is preferable. 
Another question is on redundancy levels. Should one be allowed to specify more than 
one value for forwardshift parameter respectively for secondary (tertiary etc..) AS streams ?
I think loss concealment can be further improved under certain loss scenarios as one can increase 
the number of opportunities to repair the stream if desired. 

BR,

Satish Mundra

> -----Original Message-----
> From: Qiaobing Xie [mailto:[email-masked]] 
> Sent: Thursday, October 16, 2008 8:39 PM
> To: Mundra, Satish
> Cc: [email-masked]
> Subject: Re: [AVT] Comment on 
> draft-ietf-avt-forward-shifted-red-02.txt
> 
> Satish,
> 
> I totally agree with you that it would not make much sense if 
> a session is setting both "forwardshift" and "timestamp 
> offset in additional header" to some non-zero values. But if 
> someone really wants to do that for whatever reason, the spec 
> can still handle it correctly. Of cause the spirit for doing 
> forward-shifting may be lost, as you pointed out below. But I 
> think a "MUST" is a bit too strong here.
> 
> > I have one minor comment on the forwardshift parameter 
> defined on page 
> > 5.  I think the "forwardshift" value needs to be greater than the 
> > "timestamp offset in the additional header" otherwise the redundant 
> > data will not be forward-shifted. A simpler alternative 
> would be to require that "timestamp offset in the additional 
> header" MUST be set to '0' when forwardshift is used as 
> assumed in examples in appendix.
> >
> > BR,
> >
> > Satish Mundra
> >

---

From: Qiaobing Xie <[email-masked]>
Date: Sat, 18 Oct 2008 15:24:53 -0500

Hello, Satish

I certainly see the usefulness of supporting more than one level of 
forward-shifted redundancy but don't see it as important. My preference 
is to keep the mechanism simple. However, if you have any suggestion on 
adding this capability without introducing too much signaling complexity 
to the design, I'd certainly welcome it.

regards,
-Qiaobing

---

From: "Mundra, Satish" <[email-masked]>
Date: Mon, 20 Oct 2008 09:03:54 -0500

We could specify the multiple forward shift base values for higher levels 
with "-" or "/" as separator. 

m=audio 12345 RTP/AVP 121 0 5
a=rtpmap:121 fwdred/8000/1
a=fmtp:121 0/5/5/5 forwardshift=20000-40800-56000
or 
a=fmtp:121 0/5/5/5 forwardshift="20000/40800/56000"

BR,

Satish Mundra

> Sent: Saturday, October 18, 2008 4:25 PM
> To: Mundra, Satish
> Cc: [email-masked]
> I certainly see the usefulness of supporting more than one 
> level of forward-shifted redundancy but don't see it as 
> important. My preference is to keep the mechanism simple. 
> However, if you have any suggestion on adding this capability 
> without introducing too much signaling complexity to the 
> design, I'd certainly welcome it.
> 
> regards,
> -Qiaobing
>  
> Mundra, Satish wrote:
> > Hi Qiaobing,
> >
> > Another question is on redundancy levels. Should one be allowed to 
> > specify more than one value for forwardshift parameter 
> respectively for secondary (tertiary etc..) AS streams ?
> > I think loss concealment can be further improved under certain loss 
> > scenarios as one can increase the number of opportunities 
> to repair the stream if desired.
> >
> > BR,
> >
> > Satish Mundra
> >
> >  
> >
> >   
> >> I totally agree with you that it would not make much sense if a 
> >> session is setting both "forwardshift" and "timestamp offset in 
> >> additional header" to some non-zero values. But if someone really 
> >> wants to do that for whatever reason, the spec can still handle it 
> >> correctly. Of cause the spirit for doing forward-shifting may be 
> >> lost, as you pointed out below. But I think a "MUST" is a bit too 
> >> strong here.
> >>
> >> "In a forward-shifted session, the timestamp offset in the 
> additional 
> >> header SHOULD be set to '0'".
> >>
> >> regards,
> >> -Qiaobing
> >>
> >> Mundra, Satish wrote:
> >>     
> >>> Hi Qiaobing,
> >>>
> >>>
> >> would be to require that "timestamp offset in the 
> additional header" 
> >> MUST be set to '0' when forwardshift is used as assumed in 
> examples 
> >> in appendix.
> >>     
> >>> BR,
> >>>
> >>> Satish Mundra
> >>>