[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] comments on section10ofdraft-ietf-avt-rapid-acquisition-for-rtp-01
The text proposal looks fine to me.
I don't think we should mandate support both, this would cause extra work in implementation of a solution, and I can't see any benefit. Giving that this is UDP traffic port muxing is a subset of separate ports, so we can mandate port muxing, and make optional the separate ports.
Zeev
-----Original Message-----
From: Bill Ver Steeg (versteb) [mailto:versteb at cisco.com]
Sent: Wednesday, June 17, 2009 8:40 AM
To: Ali C. Begen (abegen); VAN CAENEGEM Tom; Roni Even; avt at ietf.org; Zeev Vax
Subject: RE: [AVT] comments on section10ofdraft-ietf-avt-rapid-acquisition-for-rtp-01
Tom-
These words looks good to me as well, with the following clarification.
We do need to consider how we handle RTP/RTCP port muxing throughout the
document, and make the wording consistent wherever we reference the
ports in use. I am in favor of allowing (but not mandating) the RR to
signal RTP/RTCP port muxing. This would require the RS to support both
methods. This is just my opinion, and we need to come to consensus on
this matter.
Bill VerSteeg
-----Original Message-----
From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of
Ali C. Begen (abegen)
Sent: Wednesday, June 17, 2009 10:15 AM
To: VAN CAENEGEM Tom; Roni Even; avt at ietf.org
Subject: Re: [AVT] comments on
section10ofdraft-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
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt