Re: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions(RAMS) as a working group item

[Roni Even <Even.roni at huawei.com>]

Ali,

"This is tricky. Remember that the RAMS request message goes to the Feedback
Target of the primary multicast session but the burst comes from the
retransmission server. They could be the same entity or different ones. Any
solution should consider this in its design."

From the draft

" Editor's note:  As stated above, FT, Burst Source and Retransmission
   Source are logical entities.  For efficiency and simplicity, they MAY
   be implemented by a single physical Retransmission Server (RS).  In a
   number of places throughout this document we assume (and explicitly
   state so) that all three are implemented by the same physical entity
   and therefore share the same IP address and the port number.  The
   authors look to the AVT community for recommendations on whether this
   is sufficient or the mechanism has to explicitly address other
   topologies where FT, Burst Source and Retransmission Source are not
   co-located."

My understanding is that having a single physical entity is the assumption
of this work and any other architecture is for further study.

BTW: figure 2 has feedback target as part of the retransmission server, I
think that you meant retransmission source for the burst. 

Roni

-----Original Message-----
From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of Ali C.
Begen (abegen)
Sent: Thursday, May 14, 2009 2:46 AM
To: Roni Even; Bill Ver Steeg (versteb); avt at ietf.org
Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP
Sessions(RAMS) as a working group item

Roni,

There are a few other important issues that we need WG input on:

- The scenarios where there are multiple SSRC-multiplexed RTP streams in a
single RTP session. Will RAMS apply to individual streams or the whole
session? Similarly, what happens when the same multicast session carries
multiple RTP sessions (same multicast address but different ports). Clearly,
such cases will exist. We have a draft text that discusses different
scenarios and what needs to be done in each such cases. But before we move
forward, we would like to hear WG input. Managing multiple bursts
simultaneously requires some details.

- The security section needs to be completed as well as the NAT section.

Some comments inline.

> I have some others issues to add to this list
> 
> 1. I suggest to add to the RAMS request an optional parameter that will
> allow the receiver to request that the unicast stream will be sent to the
a
> port specified in this parameter instead of the port offered in the
> announcement.

This is tricky. Remember that the RAMS request message goes to the Feedback
Target of the primary multicast session but the burst comes from the
retransmission server. They could be the same entity or different ones. Any
solution should consider this in its design.
 
> 2. The issue of RTP/RTCP multiplexing should be discussed, is it mandatory
> to use it.

It is not mandatory. Even if we made it mandatory, it would not help us with
the issue you describe above. Muxing only simplifies NAT traversal.
 
> 3. The issue of FW/NAT traversal for the unicast stream should also be
> discussed.

Indeed. The NAT section is TBC.

-acbegen
 
> 
> Thanks
> Roni Even
> 
> -----Original Message-----
> From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of Bill
> Ver Steeg (versteb)
> Sent: Wednesday, May 13, 2009 3:08 PM
> To: avt at ietf.org
> Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP
> Sessions(RAMS) as a working group item
> 
> 
> 
> We submitted version -00 of "draft-ietf-avt-rapid-acquisition-for-rtp".
> This is basically a name change from
> "draft-versteeg-avt-rapid-synchronization-for-rtp-03" to avoid confusion
> with other pending "synchronization" drafts.
> 
> There were some issues remaining from -03 version that have already been
> identified on the list and technical breakout session. We are planning
> to address these issues in the next version of the draft.
> 
> We hope to address the following areas in the next revision of the
> draft:
> 
> - Section 7 - Define a method for vendor-specific and generic extensions
> to RAMS, lay out the intent to use FMT==6 for all messages and to have
> an (extensible) enumeration of the RAMS sub-FMTs
> - Section 8 - Elaborate SDP to describe the various use cases for RAMS
> - Section 13 - Define a single registry (FMT==6) for all RAMS
> transactions, and then define Sub-FMT Values for RAMS Messages. Also
> define an extensible RAMS TLV space registry
> 
> - We need to make some typographical corrections, mostly changing from
> RMS to RAMS.
> - We need to formalize the TLV definitions and extensions (both vendor
> and private extensions)
> - We need to register FMT=6 with IANA for RAMS and use sub-FMT values to
> identify various RAMS messages
> - We need to clarify the SDP section based on the earlier discussion.
> The SDP example is still declarative and we are looking forward to
> include more examples as we move forward.
> - The IANA concerns section needs to be updated to reflect how to extend
> the RAMS protocol.
> - The unicast/multicast addresses need to be fixed according to the
> idnits tool.
> 
> Are there other issues that we need to address in the next revision of
> the draft? The authors would like to address these high priority issues
> in the next few days, so timely feedback would be appreciated.
> 
> 
> Bill VerSteeg
> _______________________________________________
> 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