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

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

Oh, I see. The burst goes to the port that we would normally send the retransmissions. For example, consider the SDP from the draft:

        m=video 41000 RTP/AVPF 98
        i=Primary Multicast Stream #2
        c=IN IP4 224.1.1.2/255
        a=source-filter: incl IN IP4 224.1.1.2 192.0.2.2
        a=rtpmap:98 MP2T/90000
        a=rtcp:41001 IN IP4 192.0.2.1
        a=rtcp-fb:98 nack
        a=rtcp-fb:98 nack ssli
        a=ssrc:123321 cname:iptv-ch32 at rams.example.com
        a=mid:3
        m=video 41002 RTP/AVPF 99
        i=Unicast Retransmission Stream #2 (Ret. and Rapid Acq. Support)
        c=IN IP4 192.0.2.1
        a=recvonly
        a=rtpmap:99 rtx/90000
        a=rtcp:41003
        a=fmtp:99 apt=98; rtx-time=5000
        a=mid:4

In this case, the burst will go to port 41002 on the RR. The RAMS-I message(s), which is an RTCP feedback message, will go to port 41003.

HTH,
-acbegen

> -----Original Message-----
> From: Roni Even [mailto:ron.even.tlv at gmail.com] 
> Sent: Friday, April 24, 2009 11:44 AM
> To: Ali C. Begen (abegen); avt at ietf.org
> Cc: Bill Ver Steeg (versteb)
> Subject: RE: [AVT] New draft of "Rapid Acquisition of 
> Multicast RTPSessions (RAMS)" available
> 
> 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
> > 
> >  
> > 
> >  
> > 
> > 
> 
>