Re: [AVT] New draft of "Rapid Acquisition of Multicast RTP Sessions (RAMS)" available

[Zou ZiXuan <tendyntu at huawei.com>]

Hi, Ali,
	Thanks for your explanation. 

> -----Original Message-----
> From: Ali C. Begen (abegen) [mailto:abegen at cisco.com]
> Sent: Friday, April 24, 2009 11:13 PM
> To: Zou ZiXuan; Bill Ver Steeg (versteb); avt at ietf.org
> Subject: RE: [AVT] New draft of "Rapid Acquisition of Multicast RTP
Sessions
> (RAMS)" available
> 
> Hi Zou,
> 
> This is a very good question. Let me take a stab here.
> 
> Per RFC 3550, each SSRC space has its own clock rate and seq
numbering.
> We include the SSRC in the RAMS request messages.
> 
> There are different flavors of your scneario. Lets assume that we have
two
> RTP streams (audio and video).
> 
> 
> Case 1: Different RTP sessions are transmitted over different mcast
groups.
> 
> Here, we run a different independent RAMS session for each RTP stream
> that we want to rapidly acquire (they can run in parallel). Here one
needs to
> pay attention to how to use the shared bandwidth among different
bursts,
> though.
> 
> Case 2: Different RTP sessions are transmitted over the same mcast
group
> (with different dest ports).
> 
> Again, we run a different independent RAMS for each RTP stream
(different
> request for each, etc). But, one should keep in mind that the join
times for the
> all RAMS sessions need to be common as there is only one multicast.
> 
> Case 3: One RTP session (same mcast group, same dest port) carrying
both
> audio and video (this is SSRC multiplexing).
> 
> Similar to case 2, join time needs to be coordinated among different
RAMS
> sessions running for each RTP stream. Since we signal SSRC in the
request
> message and we have independent RAMS sessions, using different clock
> rates is not an issue.
> 
> Case 4: One RTP session, one SSRC with payload type multiplexing. This
is
> not recommended for many reasons. On top of that, different payloads
with
> different clock rates cannot be multiplexed in this fashion. So, I
don't think this
> will apply to our problem.
> 
> HTH,
> -acbegen
> 
> 
> > -----Original Message-----
> > From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On
> > Behalf Of Zou ZiXuan
> > Sent: Friday, April 24, 2009 3:03 AM
> > To: Bill Ver Steeg (versteb); avt at ietf.org
> > Subject: Re: [AVT] New draft of "Rapid Acquisition of
> > Multicast RTP Sessions (RAMS)" available
> >
> > Hi,
> >
> >          The burst duration (8 octets) in RAMS-I message is
> > in a single RTP ticks. And I note that from draft-01 on, the
> > solution is payload-independent (is my understanding
> > correct?). So, for non-MEPG2-TS payload, for example,
> > H.264-NAL where audio and video content are encapsulated
> > separately in two RTP streams with different ticks, does the
> > duration indicated by this single ticks still work? Which
> > stream does this tick belong to?
> >
> >
> >
> > From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On
> > Behalf Of Bill Ver Steeg (versteb)
> > Sent: Friday, April 17, 2009 12:39 AM
> > To: avt at ietf.org
> > Subject: [AVT] New draft of "Rapid Acquisition of Multicast
> > RTP Sessions (RAMS)" available
> >
> >
> >
> > There is a new draft of the "Rapid Acquisition of Multicast
> > RTP Sessions (RAMS)" draft available at
> > http://www.ietf.org/internet-drafts/draft-versteeg-avt-rapid-s
> ynchronization-for-rtp-03.txt <http://www.ietf.org/internet->
> drafts/draft-versteeg-avt-rapid-synchronization-for-rtp-03.txt>
> >
> >
> >
> > We have incorporated the changes from the technical breakout
> > session in San Francisco. The major changes in this version
> > of the draft include
> >
> > 1- Changing the document title to avoid confusion with other
> > ongoing "synchronization" drafts
> >
> > 2- changing the message names to reflect the title change
> >
> > 3- clarification of the RTCP message semantics, including
> > changes to the "Request" and "Inform" messages
> >
> > 4- additional description/motivation for the various message
> > flows has been added
> >
> > 5- RTP/RTCP muxing has been added
> >
> >
> >
> >
> >
> > We hope to make this a Working Group item, and will change
> > the name of the draft to avoid conflicts with other
> > "synchronization" drafts at that time.
> >
> >
> >
> > Bill VerSteeg
> >
> >
> >
> >
> >
> >