[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

To: "Roni Even" <ron.even.tlv at gmail.com>, <avt at ietf.org>
Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available
From: "Ali C. Begen (abegen)" <abegen at cisco.com>
Date: Sat, 25 Apr 2009 15:26:44 -0700
Authentication-results: sj-dkim-4; header.From=abegen at cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; );
Cc: "Bill Ver Steeg \(versteb\)" <versteb at cisco.com>
Delivered-to: avt at core3.amsl.com
Dkim-signature: v=1; a=rsa-sha256; q=dns/txt; l=13599; t=1240698409; x=1241562409; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen at cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20<abegen at cisco. com> |Subject:=20RE=3A=20[AVT]=20New=20draft=20of=20=22Rapid=20A cquisition=20of=20Multicast=20RTPSessions=09(RAMS)=22=20avai lable |Sender:=20; bh=pmoE51/NuPub791EjoX4KLGjZIUtG4S0ByXSZSumgCM=; b=tUcev15dsLYL3OYR3yB2n8z9zNRrtt/pP6GbtQUO1YQdITvpW7rZusWo8o dQf+yWbQr5ZwyxglzZ9kqzym0bWbJJzBmXp3E+P0MVkfkkPbHI6jLqkEs3da 3rtVP7ebEB;
In-reply-to: <49f387ca.0305560a.6657.4be7 at mx.google.com>
List-archive: <http://www.ietf.org/mail-archive/web/avt>
List-help: <mailto:avt-request@ietf.org?subject=help>
List-id: Audio/Video Transport Working Group <avt.ietf.org>
List-post: <mailto:avt@ietf.org>
List-subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
List-unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
References: <81B9B88E2F9D574AA5328A85547CDE9101071D80 at xmb-rtp-21d.amer.cisco.com> <49f1a1d6.190c660a.58fe.ffffa90e at mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C80DA at xmb-sjc-215.amer.cisco.com> <49f208e8.05a0660a.5bd2.6764 at mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C81C9 at xmb-sjc-215.amer.cisco.com> <49f211fc.07a5660a.3f7f.ffff8f4a at mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8202 at xmb-sjc-215.amer.cisco.com> <49f2efa2.1c215e0a.4454.ffffaf91 at mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8403 at xmb-sjc-215.amer.cisco.com> <49f36ee2.0437560a.11df.1eef at mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8405 at xmb-sjc-215.amer.cisco.com> <49f387ca.0305560a.6657.4be7 at mx.google.com>
Thread-index: Acm+sdXPh1GGTWXYSFG97HplRMX73QGHOeBQAAroqxAABGe0AAAAUgbQAAEZLVAAAGk5sAAgqbUwABJxCtAAAIRzIAAAQcKgAANiJ+AAAQT/QA==
Thread-topic: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available

 

> -----Original Message-----
> From: Roni Even [mailto:ron.even.tlv at gmail.com] 
> Sent: Saturday, April 25, 2009 2:58 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 looked at RFC 4570 and I assume that port 41001 is the port for the
> unicast RTCP reports from the receivers and according to

Yes, indeed.
 
> section 3.2.1 of
> that RFC you also should have a RTCP-unicast specification. 
> This is for the
> multicast receiver reports.

Correct. We do have that line in our draft at the top right after the grouping lines:

	a=rtcp-unicast:rsi

BR,
-acbegen
 
> 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.
> 
>         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).
> 
>         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.
> 
>         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
> > > > > > 
> > > > > >  
> > > > > > 
> > > > > >  
> > > > > > 
> > > > > > 
> > > > > 
> > > > > 
> > > > 
> > > > 
> > > 
> > > 
> > 
> > 
> 
>

Follow-Ups:
- Re: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available
  - From: José Rey

References:
- [AVT] New draft of "Rapid Acquisition of Multicast RTP Sessions (RAMS)" available
  - From: Bill Ver Steeg (versteb)
- Re: [AVT] New draft of "Rapid Acquisition of Multicast RTP Sessions (RAMS)" available
  - From: Roni Even
- Re: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available
  - From: Ali C. Begen (abegen)
- Re: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available
  - From: Roni Even
- Re: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available
  - From: Ali C. Begen (abegen)
- Re: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available
  - From: Roni Even
- Re: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available
  - From: Ali C. Begen (abegen)
- Re: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available
  - From: Roni Even
- Re: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available
  - From: Ali C. Begen (abegen)
- Re: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available
  - From: Roni Even
- Re: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available
  - From: Ali C. Begen (abegen)
- Re: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available
  - From: Roni Even

Prev by Date: Re: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available
Next by Date: Re: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available
Previous by thread: Re: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available
Next by thread: Re: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available
Index(es):
- Date
- Thread