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

["Ali C. Begen (abegen)" <abegen at cisco.com>]

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