|
Roni-
These are reasonable approaches, which I need to consider
in detail. I have (mostly) been thinking about NAT-friendly solutions, which
leads me back to muxing. I need to consider the ramifications of NAT on the
methods that signal IP addresses and port numbers as part of the run-time for
acceleration. The intent is to make acquisition faster, and additional
complexity at session instantiation should be avoided
(IMHO).
More to come, once I get my head around the various
options.
bvs
From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of Roni Even Sent: Friday, April 24, 2009 3:19 PM To: Bill Ver Steeg (versteb); avt at ietf.org Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available Bill, Since
I have two hats here then as a WG chair, my intention is to ask the list to
start this topic as a WG item Taking
my WG chair off, my expectation is that a WG document will describe a solution
that can be implemented while the current text does not specify how to make it
work. I do not care if you write that RTP/RTCP mux MUST be used by the RS and
supported by the RR and update the SDP in the example to specify that this is
case. My
personal preference is to have the RS indicate in the SDP that it wants to use
multiplexing and to add a flag to RAMS-R that will indicate if RTP/RTCP mux is
supported by RR and can be used. Only if the RR cannot support the multiplexing
it should indicate it using the flag and add to the RAMS-R the transport address
to be used (Note that it can be v4 or v6). SDP
cannot be used since there is no SDP from RR to RS. Roni
Even From: Bill Ver Steeg
(versteb) [mailto:versteb at cisco.com] Roni- Yes, the
document needs updating in this respect. We have two broad options which need to
be described in detail. The
method that I have been assuming does use muxing. The RS sends the unicast
burst back to the UDP port number on the RR that sent the RAMS-R. This allows
transparent operation through NAT. There is a single UDP port, and the
transaction is initiated by the "client", so it is NAT
friendly. There
are quite a few ways we could handle the case in which muxing is not used. We
could add a parameter to the RAMS-R, use another RTCP packet in the same
compound packet, define the port numbers as a relationship to the opened port
(not attractive), or define something in the SDP (also not attractive). I
personally like the "RAMS-R optional field" approach, but I think this should be
a topic that we consider in detail once we have a WG item. bvs From: Roni Even
[mailto:ron.even.tlv at gmail.com] Hi, I
think that the current draft does not give a description of a system that works
since there is no text explaining how the RS knows the unicast transport address
on the RR to where to send the stream. If
you mandate the use of RTP/RTCP mux it should say so otherwise the RAMS-R should
have an optional parameter that supplies this information and a flag for using
RTP/RTCP mux. Thanks Roni
Even From:
avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of Bill Ver
Steeg (versteb) There is a new draft
of the "Rapid Acquisition of Multicast RTP Sessions (RAMS)" draft available at
http://www.ietf.org/internet-drafts/draft-versteeg-avt-rapid-synchronization-for-rtp-03.txt We
have incorporated the changes from the technical breakout session in San
Francisco. The major changes in this version of the draft include
1- Changing the
document title to avoid confusion with other ongoing "synchronization"
drafts 2- changing the
message names to reflect the title change 3- clarification of
the RTCP message semantics, including changes to the "Request" and
"Inform" messages 4- additional
description/motivation for the various message flows has been
added 5- RTP/RTCP muxing
has been added We hope to make this
a Working Group item, and will change the name of the draft to avoid conflicts
with other "synchronization" drafts at that time. Bill
VerSteeg |