[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available
Bill,
My major point here is this is a reason for having an option port or
transport address parameter in the RAMS-R allowing the RR to provide such
address.
Roni
-----Original Message-----
From: Bill Ver Steeg (versteb) [mailto:versteb at cisco.com]
Sent: Sunday, May 24, 2009 1:02 PM
To: Roni Even; Ali C. Begen (abegen); Jose Rey
Cc: Roni Even; avt at ietf.org
Subject: RE: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions
(RAMS)" available
Roni-
Regarding the RS being able to send data to the RR after receiving a RAMS-R.
There is a subtle point here, which you reference in your comment "need to
provide a reachable transport address". The RR sends the RAMS-R to the
feedback target UDP port number. In the presence of NAT, the only
communication path that is opened automatically is that single path. In
order to use the other port-pairs, holes must be poked in the NAT and the
correct NAT-ed ports must be signaled. As you know, there are many ways to
poke wholes in NAT, so we will not go into the details of how to do that.
This is an important point, and we will be sure to make it more clear in the
next draft.
Bvs
-----Original Message-----
From: Roni Even [mailto:Even.roni at huawei.com]
Sent: Saturday, May 23, 2009 8:19 AM
To: Ali C. Begen (abegen); 'Jose Rey'
Cc: 'Roni Even'; avt at ietf.org; Bill Ver Steeg (versteb)
Subject: RE: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions
(RAMS)" available
Hi,
I also have concerns about having the unicast Transport addresses for the RR
RTCP and RTP receive port.
I think that we should first talk about the NAT/FW issue and than define the
requirements and solutions.
My assumption is that the retransmission server has a publicly reachable
address while the receivers may sit behind NATs and will not have a publicly
reachable address.
Note that the RAMS flow starts from the receiver by RAMS-R so a response to
the transport address from where the RAMS-R came should work (RTCP is
bi-directional in this case). On the other hand the unicast data flow is to
the receiver so the receiver will need to provide a reachable transport
address.
Roni
-----Original Message-----
From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of Ali C.
Begen (abegen)
Sent: Saturday, May 23, 2009 3:27 AM
To: Jose Rey
Cc: Roni Even; avt at ietf.org; Bill Ver Steeg (versteb)
Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions
(RAMS)" available
Hi Jose,
Indeed, RAMS-R goes to the FT of the new primary session that RR is
interested in acquiring rapidly. Then the unicast session becomes alive and
RS sends RAMS-I message(s) to RR on the RTCP port for the unicast session.
After some time, RR sends the RAMS-T message to the RTCP port for the
unicast session since it is supposed to end the unicast session.
-acbegen
> -----Original Message-----
> From: Jose Rey [mailto:Jose.Rey at eu.panasonic.com]
> Sent: Friday, May 22, 2009 7:09 AM
> To: Ali C. Begen (abegen)
> Cc: Roni Even; avt at ietf.org; Bill Ver Steeg (versteb)
> Subject: RE: [AVT] New draft of "Rapid Acquisition of Multicast
RTPSessions (RAMS)"
> available
>
>
> Hi Ali,
>
> >
> > Hi Jose,
> >
> > We have separate RTCP ports for the SSM session and the unicast
> > session. Why is it a problem?
>
> In line 19 you say you specify the dst port for RMS-I (41003), on RR.
> And
you say that
> would also be the port where the RR sends RMS-T, on RS. That is mixing
> the
semantics of
> a=rtcp for SSM (listening port at Feedback Target = mcast RTCP dst
> port)
and those of RFC
> 3605 (dst port). In other words, you are implicitly assuming that
specifies symmetric
> RTCP...no?
>
> Another thing that was mentioned already: RMS-T is not sent to same
> port
as RMS-R; is it
> not the same RTCP session ? Or is this muxing desired? why?
>
> JLR
>
> >
> > The slightly modified SDP for the next version is below:
> >
> 1> a=group:FID 3 4
> 2> a=rtcp-unicast:rsi
> 3> m=video 41000 RTP/AVPF 98
> 4> i=Primary Multicast Stream #2
> 5> c=IN IP4 233.252.0.2/255
> 6> a=source-filter: incl IN IP4 233.252.0.2 192.0.2.2
> 7> a=recvonly
> 8> a=rtpmap:98 MP2T/90000
> 9> a=rtcp:41001 IN IP4 192.0.2.1
> 10> a=rtcp-fb:98 nack
> 11> a=rtcp-fb:98 nack ssli
> 12> a=ssrc:123321 cname:iptv-ch32 at rams.example.com
> 13> a=mid:3
> 14> m=video 41002 RTP/AVPF 99
> 15> i=Unicast Retransmission Stream #2 (Ret. and Rapid
> > Acq. Support)
> 16> c=IN IP4 192.0.2.1
> 17> a=recvonly
> 18> a=rtpmap:99 rtx/90000
> 19> a=rtcp:41003
> 20> a=fmtp:99 apt=98; rtx-time=5000
> 21> a=mid:4
> >
> > This is the SDP we send to RR. For RS, a=recvonly will be a=sendonly.
> >
> > -acbegen
> >
> >
> > > -----Original Message-----
> > > From: José Rey [mailto:jose.rey at eu.panasonic.com]
> > > Sent: Thursday, May 21, 2009 3:22 PM
> > > To: Ali C. Begen (abegen)
> > > Cc: Roni Even; avt at ietf.org; Bill Ver Steeg (versteb)
> > > Subject: Re: [AVT] New draft of "Rapid Acquisition of
> > Multicast RTPSessions (RAMS)"
> > > available
> > >
> > > Hi all,
> > >
> > > sorry for jumping in....
> > >
> > > I think one of the sources of confusion is that the
> > attribute a=rtcp:
> > > is used once for specifying the destination port and once for
> > > specifying a receiving port, and in the same SDP (!). The
> > destination
> > > port for RAMS-I packets sent by RS and the receiving port
> > for RAMS-T. Which is also why different port numbers are used for
> > RAMS-T and -R packets.
> > >
> > > I think the use of a=rtcp: in SSM is the problem here. Or the fact
> > > that we are mixing unicast and multicast, or both.
> > >
> > > Hope this helps,
> > >
> > > JLR
> > >
> > >
> > >
> > >
> > > Ali C. Begen (abegen) wrote:
> > >
> > >
> > >
> > >
> > >
> > > -----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-> <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
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Audio/Video Transport Working Group
> > > avt at ietf.org
> > > https://www.ietf.org/mailman/listinfo/avt
> > >
> > >
> >
> >
> >
>
>
> Panasonic R&D Center Germany GmbH
> 63225 Langen, Hessen, Germany
> Reg: AG Offenbach (Hessen) HRB 33974
> Managing Director: Thomas Micke
>
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt