[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] comments on section10ofdraft-ietf-avt-rapid-acquisition-for-rtp-01
Thanks I read your earlier message before, my point is that if you assume all entities are one, and assume muxing, you can assume the source port the RR use to send the RAMS-R is the same it wishes to receive the burst and control answers.
I.e. - I disagree with your conclusion below
<quote>
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.
</quote>
Zeev
-----Original Message-----
From: Ali C. Begen (abegen) [mailto:abegen at cisco.com]
Sent: Thursday, June 18, 2009 3:07 PM
To: Zeev Vax; Roni Even; Bill Ver Steeg (versteb); VAN CAENEGEM Tom; avt at ietf.org
Subject: RE: [AVT] comments on section10ofdraft-ietf-avt-rapid-acquisition-for-rtp-01
I will copy/paste from my earlier email:
<quote>
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.
</quote>
So, even if muxing is enabled by RR meaning that it can receive RTP and RTCP on the same port, we still need to signal that single port somehow. One way of doing it is PubPorts message (which is by itself an RTCP message and can be appended to the RTCP packet that carries RAMS-R message). And frankly speaking, signaling two ports (RTP + RTCP) is not any more difficult than signaling a single (muxed) port. Thus, IMO we should not be mandating muxing.
-acbegen
> -----Original Message-----
> From: Zeev Vax [mailto:zeevvax at microsoft.com]
> Sent: Thursday, June 18, 2009 2:58 PM
> To: Ali C. Begen (abegen); Roni Even; Bill Ver Steeg (versteb); VAN CAENEGEM Tom;
> avt at ietf.org
> Subject: RE: [AVT] comments on section10ofdraft-ietf-avt-rapid-acquisition-for-rtp-01
>
> If we assume all entities are one, why would you need to signal the retransmission port
> separately ?
>
> Zeev
>
> -----Original Message-----
> From: Ali C. Begen (abegen) [mailto:abegen at cisco.com]
> Sent: Thursday, June 18, 2009 2:46 PM
> To: Zeev Vax; Roni Even; Bill Ver Steeg (versteb); VAN CAENEGEM Tom; avt at ietf.org
> Subject: RE: [AVT] comments on section10ofdraft-ietf-avt-rapid-acquisition-for-rtp-01
>
> Zeev,
>
> I agree that mandating both is not a good idea. But, you should note that muxing does not
> solve our issues. So, mandating it will not be the cure for everything. See my email from
> Tuesday.
>
> -acbegen
>
> > -----Original Message-----
> > From: Zeev Vax [mailto:zeevvax at microsoft.com]
> > Sent: Thursday, June 18, 2009 2:27 PM
> > To: Roni Even; Bill Ver Steeg (versteb); Ali C. Begen (abegen); 'VAN CAENEGEM Tom';
> > avt at ietf.org
> > Subject: RE: [AVT] comments on section10ofdraft-ietf-avt-rapid-acquisition-for-rtp-01
> >
> > Roni,
> >
> > As I said I support mandating the multiplexing, but not the multiple ports. If there are
> > no other opinions, we can add that to draft.
> >
> > Zeev
> >
> > -----Original Message-----
> > From: Roni Even [mailto:Even.roni at huawei.com]
> > Sent: Thursday, June 18, 2009 2:50 AM
> > To: Zeev Vax; 'Bill Ver Steeg (versteb)'; 'Ali C. Begen (abegen)'; 'VAN CAENEGEM Tom';
> > avt at ietf.org
> > Subject: RE: [AVT] comments on section10ofdraft-ietf-avt-rapid-acquisition-for-rtp-01
> >
> > Zeev,
> > This is a question I had in the past. I think that it merits a separate
> > thread in order to get a consensus on the issue. Mandating RTP/RTCP
> > multiplexing for the unicast burst make it simpler and faster to start.
> >
> > Note the two ports may still be used for the retransmission case.
> >
> > Roni
> >
> >
> >
> > > -----Original Message-----
> > > From: Zeev Vax [mailto:zeevvax at microsoft.com]
> > > Sent: Wednesday, June 17, 2009 7:45 PM
> > > To: Bill Ver Steeg (versteb); Ali C. Begen (abegen); VAN CAENEGEM Tom;
> > > Roni Even; avt at ietf.org
> > > Subject: 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
> >
>