[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,
See inline
Roni
-----Original Message-----
From: Ali C. Begen (abegen) [mailto:abegen at cisco.com]
Sent: Saturday, April 25, 2009 11:30 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
Here is the SDP.
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
Source (192.0.2.2) sends the rtp packets to the multicast group (224.1.1.2)
with a dest port 41000.
a=rtpmap:98 MP2T/90000
a=rtcp:41001 IN IP4 192.0.2.1
The feedback target (RS) address for this SSM session is 192.0.2.1 and its
port is 41001. This is the address/port where RR sends the RAMS-R, or
receiver reports for the SSM session.
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
The retransmission packets go to port 41002. This is the port RRs listen to
for retransmission and RAMS.
Roni E: This implies that the multicast source defines the port that all
clients MUST use to receive the unicast information from the Burst source.
i=Unicast Retransmission Stream #2 (Ret. and Rapid Acq. Support)
c=IN IP4 192.0.2.1
This is where the retransmission packets come from, same as the feedback
target (in this example).
Roni E: If this is the address of the feedback target it belongs to the
above m-line (m=video 41002 RTP/AVPF 99) that according to you gives the
port on the RR and not on the RS. The problem is that according to SDP the
combination of the c= and port on the m-line provides the transport address
to where a stream will be sent so according to SDP this m-line specify an
address and port on the Feedback Target and not on the RR and only to this
address RTP payload type 99 will be sent. I am positive that this is not
what you want.
a=rtpmap:99 rtx/90000
a=rtcp:41003
This is where the RTCP packets for the retransmission session go. For
example, RAMS-I goes to this port on RRs. RAMS-T goes to this port on RS.
Roni E: So now you assume that the RR must use the same port as the FT for
this communication. I could not find any place that one m-line gives the
address for both sides. This RTCP port is on 192.0.2.1 so it will be used
for RAMS-R but not for RAMS-I.
a=fmtp:99 apt=98; rtx-time=5000
a=mid:4
-acbegen
> -----Original Message-----
> From: Roni Even [mailto:ron.even.tlv at gmail.com]
> Sent: Saturday, April 25, 2009 1:11 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,
> 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
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>