Subject: [AVT] comments on section 10 of draft-ietf-avt-rapid-acquisition-for-rtp-01

From: Roni Even <[email-masked]>
Date: Tue, 16 Jun 2009 20:07:39 +0300

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

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 16 Jun 2009 11:59:37 -0700

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: [email-masked] [mailto:[email-masked]] On Behalf Of Roni Even
> Sent: Tuesday, June 16, 2009 10:08 AM
> To: [email-masked]
> Subject: [AVT] comments on section 10 ofdraft-ietf-avt-rapid-acquisition-for-rtp-01
> 
> Hi,
> 
> 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

---

From: Roni Even <[email-masked]>
Date: Tue, 16 Jun 2009 23:45:35 +0300

Ali,
>From figure 2 and the text that follows

" 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:[email-masked]] 
Sent: Tuesday, June 16, 2009 10:00 PM
To: Roni Even; [email-masked]
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

> Subject: [AVT] comments on section 10
ofdraft-ietf-avt-rapid-acquisition-for-rtp-01
> 2.       In the case where there is no RTP/RTCP multiplexing, the RAMS-R
RTCP message will

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 16 Jun 2009 14:12:44 -0700

Inline.

> From: Roni Even [mailto:[email-masked]]
> Sent: Tuesday, June 16, 2009 1:46 PM
> To: Ali C. Begen (abegen); [email-masked]
> Subject: RE: [AVT] comments on section 10 ofdraft-ietf-avt-rapid-acquisition-for-rtp-01
> 
> Ali,

You are correct. There is a single retransmission server that does all the work. Other types of scenarios may be considered in the future.
 
> I also thought that this was agreed in previous discussions

Yup.

> is not specifying a specific address according to you.

Right, RAMS-T goes to RS as well but it goes to the RTCP port of the unicast session not the FT of the primary session (since it is to terminate the unicast burst). What I am trying to say below is different, though, which is that we cannot make an assumption on the port RR wants to use in the unicast session (e.g., to receive the burst) based on the port it used for the primary session.

-acbegen

---

From: Roni Even <[email-masked]>
Date: Wed, 17 Jun 2009 12:59:35 +0300

Ali,
Thanks, I understand the RAMS-R and RAMS-T port usage and the logic behind
it.
As for the RAMS-I section 6.2 says

" Note that RS learns the IP address information for RR from the
       RAMS-R message it received.  (This description glosses over the
       NAT details.  Refer to Section 10 for a discussion of NAT-related
       issues.)"

So according to the above if using RTP/RTCP multiplexing, the RTP unicast
stream is sent to the address from which the RAMS-R has arrived. 
Roni

-----Original Message-----
From: Ali C. Begen (abegen) [mailto:[email-masked]] 
Sent: Wednesday, June 17, 2009 12:13 AM
To: Roni Even; [email-masked]
Subject: RE: [AVT] comments on section 10

Inline.

> entity and not three different entities with different addresses

You are correct. There is a single retransmission server that does all the
work. Other types of scenarios may be considered in the future.

Yup.

> is not specifying a specific address according to you.

Right, RAMS-T goes to RS as well but it goes to the RTCP port of the unicast
session not the FT of the primary session (since it is to terminate the
unicast burst). What I am trying to say below is different, though, which is
that we cannot make an assumption on the port RR wants to use in the unicast
session (e.g., to receive the burst) based on the port it used for the
primary session.

-acbegen

> > From: [email-masked] [mailto:[email-masked]] On Behalf Of
Roni
> Even
> > from the RR side. The RR sends the RAMS-R message to the RS from the
port
> it wants to
> > received. For the RTP, the RR does not know if it has a NAT on the way
to
> the RS and

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 17 Jun 2009 07:12:27 -0700

> Sent: Wednesday, June 17, 2009 3:00 AM

Yes. Whether there is a NAT or not (or whether muxing is used or not), the RAMS-R will always indicate RR's public IP address and RS sends its packets to that IP address. But, this part does not say anything regarding the ports. The ports to be used depend on whether there is a NAT or not and the signaling in the RAMS-R/pubports/etc.

-acbegen