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

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

Hi,


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.

2. The issue of RTP/RTCP multiplexing should be discussed, is it mandatory
to use it.

3. The issue of FW/NAT traversal for the unicast stream should also be
discussed.


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