Re: [AVT] comments on section 10 ofdraft-ietf-avt-rapid-acquisition-for-rtp-01

["Ali C. Begen (abegen)" <abegen at cisco.com>]

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