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

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

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