[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] comments on section 10ofdraft-ietf-avt-rapid-acquisition-for-rtp-01
The proposed text looks good to me. We should probably put the burst and retransmission sources in the same block in Figure 2 as well.
-acbegen
> -----Original Message-----
> From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of VAN CAENEGEM Tom
> Sent: Wednesday, June 17, 2009 5:23 AM
> To: Roni Even; avt at ietf.org
> Subject: Re: [AVT] comments on section 10ofdraft-ietf-avt-rapid-acquisition-for-rtp-01
>
>
> Hi Roni,
>
> Perhaps the start of section 6.2 can be rewritten as follows:
>
>
> <START>
>
> 6.2. Message Flows
>
> Figure 2 shows the main entities involved in rapid acquisition:
>
> o Multicast Source
>
> o Feedback Target (FT)
>
> o Burst/ Retransmission Source
>
> o RTP Receiver (RR)
>
> (fig 2)
>
>
> The feedback target (FT) is the entity as defined in [rtcpssm draft], to
> which the RR sends its RTCP FB messages, indicating packet loss in the
> ssm primary stream by means of a NACK or indicating the RR's desire to
> have rapid acquisition of the ssm primary stream (by means of an RTCP FB
> message as defined in this document). While the burst/retransmission
> source is responsible for responding on these messages and, in the case
> of rapid acquisition, further RTCP interaction with the RR during this
> acquisition process, it is assumed in the remainder of the document that
> these two logical entities (FT and burst/retransmission source) are
> combined in a single physical entity and share state. In the remainder
> of the text, the term retransmission server is used whenever
> appropriate, to refer to the combined functionality of the FT and
> retransmission/burst source. However, it must be noted that only the FT
> is involved in the primary ssm RTP session, whereas the
> burst/retransmission source transmits unicast RTP burst and RTP
> retransmissions packets (both formatted as RTP retransmission packets
> [RFC4585]) in a single separate unicast RTP retransmission session to
> each RR.
>
> Note also that the same method (with the identical message flows) would
> also apply in a scenario where rapid acquisition is performed by a
> feedback target co-located with the media source.
>
> (...)
>
> <END>
>
> Tom: As we mandate the retransmission source and burst source to be in
> the same session, I think it is no longer required to split-up among
> these two logical entities. I invite other people, including the
> co-authors to comment on this new text proposal.
>
> With respect to your comments on the RTP/RTCP port muxing support
> indication by the RR inside the RAMS-R message. That would be needed,
> but is not sufficient as, if only declarative SDP is used, and we want
> to have the possibility that the RTP/RTCP packets in the retransmission
> session can be received by the RR on the same port the RR issues the
> RTCP RAMS-R, we need also a way by which the RR can signal this too. We
> provided a possible solution in the draft, but I understood that you
> think such a solution should be proposed in a separate draft proposal?
> But I guess that would also apply then to the signaling of support for
> RTP/RTCP port muxing by the RR?
>
> Tom
>
> -----Original Message-----
> From: Roni Even [mailto:Even.roni at huawei.com]
> Sent: woensdag 17 juni 2009 13:24
> To: VAN CAENEGEM Tom; avt at ietf.org
> Subject: RE: [AVT] comments on section 10
> ofdraft-ietf-avt-rapid-acquisition-for-rtp-01
>
> Tom,
> I understand the RAMS-R and RAMS-T, the text is not clear enough in
> section
> 6.2
>
> It still leaves open the issue of the addresses for the RR in the case
> of declarative SDP when there is no answer SDP from the RR.
>
> About RTP/RTCP multiplexing, the declarative SDP can show that the RS
> supports it and I still think that some information about the addressing
> (like support for RTP/RTCP mux) should be supplied in the RAMS-R for the
> declarative case.
>
> Roni
>
> > -----Original Message-----
> > From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of
> > VAN CAENEGEM Tom
> > Sent: Wednesday, June 17, 2009 11:17 AM
> > To: avt at ietf.org
> > Subject: Re: [AVT] comments on section 10 of draft-ietf-avt-rapid-
> > acquisition-for-rtp-01
> >
> > Hi Roni,
> >
> > I think your understanding was indeed different from the general
> >assumptions in this draft. Previously we agreed to only consider the
> >case where there is only one physical entity involved (called the
> >Retransmission Server in the draft), which allows us to NOT consider
> >and discuss cases where for instance the feedback target (which is
> >defined in the rtcpssm draft/RFC) is not in the same box as the
> >retransmission source or burst source, the entities sourcing
> >retransmision/burst packets. In that case we then would also need to
> >describe how these separate entities communicate.
> > The fact that these different entities are now in the same box does
> >not necessarily mean that all interactions and data exchange with the
> >RRs is part of the same RTP session, which is in this case the SSM
> >RTP session.
> > As Ali explained, the NACK and RAMS-R RTCP FB messages are directed to
>
> >the FB target, where we do not defer from the rtcpssm draft. The RTP
> >retransmission/burst packets that are sent as a response to the NACK
> >and the RAMS-R can be either session multiplexed with respect to the
> >original SSM RTP session or SSRC muxed (same session), following RFC
> >4588.
> >As the retransmission packets in this case are addressing the RR in
> >unicast, we obviously have a dedicated RTP session for the
> >retransmission/burst packets. We had some internal discussion on
> >whether considering the use case of having a separate session between
> >RS and RR for RTP retransmission packets triggered by an RTCP FB NACK
> >and a separate session for RTP burst packets triggered by an RTCP
> >RAMS-R made sense, but we ended up agreeing that allowing a single
> >session was the easiest way out, without imposing serious limitations
> >to the general architecture.
> >
> > This means that the ports used by the (single) RTP
> > retransmission/burst session are in principle decoupled from the
> > primary SSM session. Hence if an RR wants to receive the
> > burst/retransmission packets and associated RTCP messages on the same
> > port the RR sent out the RTCP RAMS-R/ NACK FB messages, this should
> > either be signaled by the RR, OR such port usage scheme is considered
> > the "default" case -which also means the RR supports RTP/RTCP port
> > muxing for the retransmission/burst session-, and then the RR needs to
>
> > signal the ports for receiving the RTP and RTCP packets in the
> > retransmission session when it requires dedicated ports.
> >
> > The RAMS-I (RS-> RR) and RAMS-T (RR-> RS) messages are only relevant
> > to a specific RR requesting the RTP burst stream and the RS, and carry
>
> > information/signaling related to the retransmission/burst session and
> > have nothing to do with the SSM session. Hence the FB target as
> > logical entity is not involved here.
> >
> > I hope this clarifies rather than it contributes to your confusion.
> > But we may need to rephrase the part you quoted, as your
> > interpretation was different from its intended meaning. We also tried
> > to be more explicit in which session which RAMS or other RTCP (e.g.
> > Bye) messages needed to be exchanged compared to a previous version of
>
> > the draft, but we are open of course to any other suggestions from
> > your side if this is not clear enough in your opinion.
> >
> > Tom
> >
> >
> >
> >
> >
> >
> > " A Retransmission Source may equally act as a Burst Source. The
> > Retransmission Source may also incorporate the Feedback Target
> > ([I-D.ietf-avt-rtcpssm] permits the feedback target to be a
> > retransmission server, since it is a logical function to which RRs
> > send their unicast feedback), and we will use the term
> > Retransmission
> > Server (RS) in the remainder of the document to refer to a single
> > physical entity comprising these three entities that share state.
> > Note that the same method (with the identical message flows) would
> > also apply in a scenario where rapid acquisition is performed by a
> > feedback target co-located with the media source."
> >
> > I assumed that we are only dealing with the case that the RS is a
> > single entity and not three different entities with different
> > addresses
> >
> > I also thought that this was agreed in previous discussions
> >
> > If my understanding is not correct I will review the draft since the
> > current text is not explicit enough to specify which part is doing
> > each message. I saw that RAMS-R is going to feedback target but RAMS-T
>
> > is going to RS which is not specifying a specific address according to
>
> > you.
> >
> > Roni
> >
> > -----Original Message-----
> > From: Ali C. Begen (abegen) [mailto:abegen at cisco.com]
> > Sent: Tuesday, June 16, 2009 10:00 PM
> > To: Roni Even; avt at ietf.org
> > Subject: RE: [AVT] comments on section 10
> > ofdraft-ietf-avt-rapid-acquisition-for-rtp-01
> >
> > Remember that the RAMS-R (RR->RS) message is NOT on the retransmission
> > (unicast) session, it's on the primary session since it is sent to the
>
> > feedback target of the primary SSM session. Thus, the source port RR
> > uses to send RAMS-R "cannot" be assumed to be the destination port it
> > wishes to receive the unicast burst on.
> >
> > If you agree with this statement, it is clear why we need port
> > signaling.
> > Muxing will not help much here. It will just reduce the number of
> > signaled ports from 2 to 1.
> >
> > -acbegen
> >
> >
> > > -----Original Message-----
> > > From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf
> > > Of Roni
> > Even
> > > Sent: Tuesday, June 16, 2009 10:08 AM
> > > To: avt at ietf.org
> > > Subject: [AVT] comments on section 10
> > ofdraft-ietf-avt-rapid-acquisition-for-rtp-01
> > >
> > > Hi,
> > >
> > > I looked at section 10 and have some comments
> > >
> > >
> > >
> > > 1. If RTP/RTCP multiplexing is used, there is no need for any
> > specific operation
> > > from the RR side. The RR sends the RAMS-R message to the RS from the
>
> > > port
> > it wants to
> > > receive the RAMS-I and RTP payload. The RS just sends the
> > > information to
> > the port from
> > > which it received the RAMS-R and not to the one in the SDP
> > >
> > > 2. In the case where there is no RTP/RTCP multiplexing, the
> > RAMS-R
> > RTCP message will
> > > go to the RS and the RAMS-I will go to the port on the RR from where
>
> > > the
> > RAMS-R was
> > > received. For the RTP, the RR does not know if it has a NAT on the
> > way
> >
> > > to
> > the RS and
> > > should try to get a routable address (using STUN for example) and
> > providing the port to
> > > the RS ( we still need to agree on how to do it)
> > >
> > > 3. If the above two points are correct than the RR receive
> port
> > in
> > the SDP is not
> > > really useful
> > >
> > >
> > >
> > > Roni Even
> >
> >
> > _______________________________________________
> > Audio/Video Transport Working Group
> > avt at ietf.org
> > https://www.ietf.org/mailman/listinfo/avt
>
> _______________________________________________
> Audio/Video Transport Working Group
> avt at ietf.org
> https://www.ietf.org/mailman/listinfo/avt