[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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