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