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

["Roni Even" <ron.even.tlv at gmail.com>]

Ali,
I will try to explain in simple way

When the RS receives the RAMS-R it need to start sending an RTP stream to
the RR. 
In order to send a unicast packet, the RS needs to know a transport address
on the RR to where the RTP stream will be sent. The current draft does not
say how the RS knows this address. There is no SDP from RR to RS like you
mention in your response.
This is why I say that the current draft does not specify a solution that
can be implemented as a working solution
Roni

-----Original Message-----
From: Ali C. Begen (abegen) [mailto:abegen at cisco.com] 
Sent: Friday, April 24, 2009 7:38 PM
To: Roni Even; avt at ietf.org
Cc: Bill Ver Steeg (versteb)
Subject: RE: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions
(RAMS)" available

Hi Roni, 

> -----Original Message-----
> From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On 
> Behalf Of Roni Even
> Sent: Friday, April 24, 2009 4:24 AM
> To: avt at ietf.org
> Cc: Bill Ver Steeg (versteb)
> Subject: Re: [AVT] New draft of "Rapid Acquisition of 
> Multicast RTPSessions (RAMS)" available
> 
> Hi,
> 
> I think that the current draft does not give a description of 
> a system that works since there is no text explaining how the 

What do you mean by "a system that works"? 

> RS knows the unicast transport address on the RR to where to 
> send the stream. 

Once RS receives the request packet from an RR, RS knows its address. Ports
are defined in the SDP. If you are asking about "NAT" issues, we have a
section for it, and we plan to complete it as we move forward. It is not as
critical as the other parts for now.
 
> If you mandate the use of RTP/RTCP mux it should say so 
> otherwise the RAMS-R should have an optional parameter that 
> supplies this information and a flag for using RTP/RTCP mux.

IMO, we cannot mandate muxing as it is not required to make RAMS work. If
muxing is supported, the SDP should reflect it.

BR,
-acbegen
 
> Thanks
> 
> Roni Even
> 
>  
> 
> From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On 
> Behalf Of Bill Ver Steeg (versteb)
> Sent: Thursday, April 16, 2009 7:39 PM
> 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
> 
>  
> 
>  
> 
>