|
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] Sent: Friday, April 24, 2009 7:24 AM To: avt at ietf.org Cc: Bill Ver Steeg (versteb) Subject: RE: [AVT] New draft of "Rapid Acquisition of Multicast RTP Sessions (RAMS)" available 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 |