|
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 |