[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available
Ali,
Can you please write three addresses from this strange SDP.
1. The address and port of multicast
2. The address and port of the RS where the RTCP FB should go to
3. The address and port on the RR where the unicast stream should be sent to
Roni
-----Original Message-----
From: Ali C. Begen (abegen) [mailto:abegen at cisco.com]
Sent: Saturday, April 25, 2009 11:02 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
> Ali,
> The example SDP is syntactically correct but it does not say that the
> rtp/rtcp mux will be used and it does not give the
> information to where the
> unicast stream will be sent when the RR sends a RAMS-R.
To my knowledge, the first line in the following SDP tells the RRs on which
port they will receive the retransmission/burst packets.
m=video 41002 RTP/AVPF 99
i=Unicast Retransmission Stream #2 (Ret. and Rapid Acq. Support)
c=IN IP4 192.0.2.1
a=rtpmap:99 rtx/90000
a=rtcp:41003
a=fmtp:99 apt=98; rtx-time=5000
a=mid:4
There is a typo, you are right. That "a=recvonly" line should only exist in
the SDP sent to RRs. In the SDP sent to RS, we should rather have
"a=sendonly". I will make this correction in the next version.
The feedback target for the SSM session and the RTCP port for the
retransmission session are also defined in the SDP.
Hope this clarifies.
BR,
-acbegen
>
> I am not sure why the unicast stream m-line has a port number with an
> attribute of recvonly. What is the use case for that. The
> only information
> that the RR will need is the RTCP port on the RS to where to
> send the RAMS-R
> message.
> Roni
> -----Original Message-----
> From: Ali C. Begen (abegen) [mailto:abegen at cisco.com]
> Sent: Friday, April 24, 2009 10:37 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
>
> This is a part of an example SDP sent to RS and RR in a SAP
> announcement,
> for example. So, the SDP describes what both parties should
> do (RR cannot
> say that he wants to receive this multicast on its favorite port). The
> individual SDPs sent to RR or RS may include other portions
> of descriptions
> that will contain specific information.
>
> -acbegen
>
> > -----Original Message-----
> > From: Roni Even [mailto:ron.even.tlv at gmail.com]
> > Sent: Friday, April 24, 2009 12:23 PM
> > 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 think you get it wrong, this SDP is from the RS and not the
> > RR so the RS
> > cannot specify to which address it will send it can only
> > specify to which
> > address it can receive RTP stream. In this SDP the relevant
> > information is
> > that the request for retransmission will be sent by the RR to
> > port 41003
> > Roni
> >
> > -----Original Message-----
> > From: Ali C. Begen (abegen) [mailto:abegen at cisco.com]
> > Sent: Friday, April 24, 2009 10:01 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
> >
> > 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
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>