[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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