Subject: [AVT] WGLC on Rapid Synchronisation of RTP Flows

From: Roni Even <[email-masked]>
Date: Sun, 06 Dec 2009 16:05:12 +0200

Hi,

The AVT chairs  would like to start a WGLC on
http://tools.ietf.org/html/draft-ietf-avt-rapid-rtp-sync-07 

This draft outlines how RTP sessions are synchronized, and discusses how
rapidly such synchronization can occur

We will start a 2 weeks working group last call.

Please review the draft and send comments till December 21st .

Thanks

Roni Even

AVT co-chair

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 21 Dec 2009 10:38:52 -0800

I have a few comments on this draft:

Page 9, section 2.1.4: 

   ...which also don't suffer from the implosion problem).  SSM receivers
   using unicast feedback would not be allowed to send immediate RTCP.

This sentence requires revision. The scope of "RTCP" needs to be specified here. E.g., in RAMS, the receivers send an RTCP feedback right away.

Page 10, section 2.2: I would advise adding an informative reference to the RAMS draft in bullet #3.

Page 11:

   When using SSM sessions with unicast feedback, is possible that the
   feedback target and media source are not co-located.  If a feedback
   target receives an RTCP-SR-REQ feedback message in such a case, the
   request should be forwarded to the media source.  The mechanism to be
   used for forwarding such requests is not defined here.

More relevant to the RAMS draft rather than this one. In RAMS, we are planning to recommend the use of header extension approach to allow rapid synchronization. This will allow the receivers to establish synchronization faster during the burst phase as well as after they join the SSM session. However, if the feedback target receives an RTCP-SR-REQ, should it indeed forward that request to the media source?

I realize that you used "should" in your text and have not defined any mechanism to forward such requests. In RAMS, I believe it will be a wise decision to disallow such forwarding from the feedback target to the source.

Any comments?

Cheers, acbegen.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Roni Even
> Sent: Sunday, December 06, 2009 9:05 AM
> To: [email-masked]
> Subject: [AVT] WGLC on Rapid Synchronisation of RTP Flows
> 
> Hi,
> 
> The AVT chairs  would like to start a WGLC on http://tools.ietf.org/html/draft-ietf-avt-
> rapid-rtp-sync-07
> 
> 
> 
> This draft outlines how RTP sessions are synchronized, and discusses how rapidly such
> synchronization can occur
>

---

From: Colin Perkins <[email-masked]>
Date: Tue, 22 Dec 2009 16:59:54 +0000

Hi Ali,

On 21 Dec 2009, at 18:38, Ali C. Begen (abegen) wrote:
> This sentence requires revision. The scope of "RTCP" needs to be  
> specified here. E.g., in RAMS, the receivers send an RTCP feedback  
> right away.

If I understand correctly, RAMS uses AVPF with the SSM unicast  
feedback extensions. That doesn't appear to allow immediate feedback  
on joining a session, so I believe the text in the rapid-rtp-sync  
draft is correct.

> to the RAMS draft in bullet #3.

Will do.

> More relevant to the RAMS draft rather than this one. In RAMS, we  
> are planning to recommend the use of header extension approach to  
> allow rapid synchronization. This will allow the receivers to  
> establish synchronization faster during the burst phase as well as  
> after they join the SSM session. However, if the feedback target  
> receives an RTCP-SR-REQ, should it indeed forward that request to  
> the media source?
>
> I realize that you used "should" in your text and have not defined  
> any mechanism to forward such requests. In RAMS, I believe it will  
> be a wise decision to disallow such forwarding from the feedback  
> target to the source.
>
> Any comments?

There seems little point forwarding it in this scenario, since the  
media source would likely ignore the request anyway.  I'll add a few  
words suggesting that a media source can legitimately ignore RTCP-SR- 
REQ packets received in cases where its regularly scheduled  
transmission of synchronisation metadata can be expected to allow the  
receiver to regain synchronisation shortly.

Cheers,
Colin

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 22 Dec 2009 09:06:49 -0800

> From: Colin Perkins [mailto:[email-masked]]
> Sent: Tuesday, December 22, 2009 12:00 PM
> To: Ali C. Begen (abegen)
> Cc: [email-masked]
> Subject: Re: [AVT] WGLC on Rapid Synchronisation of RTP Flows
> 
> Hi Ali,
> 

Actually, you are right. However, since in RAMS we send the feedback before we actually join the session, I suppose the rule does not apply. In other words, we don't apply any timing rules on the first RAMS Request message. Yet, I guess your current text may stay as it is.

The rest looks good.

Thanks, acbegen.

---

From: Colin Perkins <[email-masked]>
Date: Tue, 22 Dec 2009 17:18:01 +0000

On 22 Dec 2009, at 17:06, Ali C. Begen (abegen) wrote:
> Actually, you are right. However, since in RAMS we send the feedback  
> before we actually join the session, I suppose the rule does not  
> apply. In other words, we don't apply any timing rules on the first  
> RAMS Request message. Yet, I guess your current text may stay as it  
> is.

The issue of implosion of requests is something the RAMS draft needs  
to consider. The prohibition of immediate requests at the start of the  
session was added to the AVPF draft for good reasons, and if the RAMS  
draft is proposing to ignore it, then it'll need to justify that  
decision.

> The rest looks good.

Thanks - I'll submit an update containing these changes.

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