[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available
Dave,
What I am trying to understand is what are the assumptions in this solution.
I will not object to any assumption as long as it is stated.
Roni Even
As individual
-----Original Message-----
From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of David
R Oran
Sent: Monday, May 25, 2009 7:31 PM
To: Roni Even
Cc: 'Roni Even'; 'Jose Rey'; avt at ietf.org; 'Bill Ver Steeg (versteb)'
Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions
(RAMS)" available
On May 24, 2009, at 1:33 PM, Roni Even wrote:
> Dave,
> I will start a separate thread on the issue. Just note that port may
> not be enough, an example is if the RR is using a TURN relay
Stopping reflection attacks here is more difficult - it requires STUN
cookies and the possibility of opening up state-based attacks on the
retransmission server. If that's the way the WG wants to go I'm ok with
that, but this is one area in which I might go to the IESG and get some
sense of whether we would run into a buzz-saw at the end after investing a
lot of design and consensus effort.
> Roni
>
> -----Original Message-----
> From: David R Oran [mailto:oran at cisco.com]
> Sent: Sunday, May 24, 2009 5:00 PM
> To: Roni Even
> Cc: 'Bill Ver Steeg (versteb)'; 'Roni Even'; 'Ali C. Begen (abegen)';
> 'Jose Rey'; avt at ietf.org
> Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast
> RTPSessions (RAMS)" available
>
>
> On May 24, 2009, at 8:26 AM, Roni Even wrote:
>
>> Bill,
>> My major point here is this is a reason for having an option port or
>> transport address parameter in the RAMS-R allowing the RR to provide
>> such address.
> Correct, in principle. I've already commented on the problematic
> nature of sending complete transport addresses, so my strong
> preference would be only to communicate port numbers (and possibly
> SSRCs)
>
> However it's an interesting design point whether this situation is so
> unique to RAMS that we solve it by putting the information in RAMS-R
> messages, or whether it justifies a more general-purpose mechanism.
>
> An alternative design would be to define a separate RTCP packet type
> to carry transport port information for "auxiliary" unicast RTP/RTCP
> sessions. The situation we face with RAMS does in fact may arise in
> other situations, both with and without NAT, where separate signaling
> using offer/answer (as SIP would do) is either overkill, too much
> overhead, or bad from a latency perspective. Just think unicast
> retransmission for SSM by itself, without RAMS.
>
> In my view, it would be worth having a serious WG discussion of this
> general subject before plunging ahead. If the sense is to in fact have
> a separate mechanism, I have one sitting in my back pocket (and have
> running open source code for).
>
> DaveO.
>
>> Roni
>>
>> -----Original Message-----
>> From: Bill Ver Steeg (versteb) [mailto:versteb at cisco.com]
>> Sent: Sunday, May 24, 2009 1:02 PM
>> To: Roni Even; Ali C. Begen (abegen); Jose Rey
>> Cc: Roni Even; avt at ietf.org
>> Subject: RE: [AVT] New draft of "Rapid Acquisition of Multicast
>> RTPSessions (RAMS)" available
>>
>> Roni-
>> Regarding the RS being able to send data to the RR after receiving a
>> RAMS-R.
>>
>> There is a subtle point here, which you reference in your comment
>> "need to provide a reachable transport address". The RR sends the
>> RAMS-R to the feedback target UDP port number. In the presence of
>> NAT, the only communication path that is opened automatically is that
>> single path.
>> In
>> order to use the other port-pairs, holes must be poked in the NAT and
>> the correct NAT-ed ports must be signaled. As you know, there are
>> many ways to poke wholes in NAT, so we will not go into the details
>> of how to do that.
>>
>> This is an important point, and we will be sure to make it more clear
>> in the next draft.
>>
>> Bvs
>>
>>
>> -----Original Message-----
>> From: Roni Even [mailto:Even.roni at huawei.com]
>> Sent: Saturday, May 23, 2009 8:19 AM
>> To: Ali C. Begen (abegen); 'Jose Rey'
>> Cc: 'Roni Even'; avt at ietf.org; Bill Ver Steeg (versteb)
>> Subject: RE: [AVT] New draft of "Rapid Acquisition of Multicast
>> RTPSessions (RAMS)" available
>>
>> Hi,
>> I also have concerns about having the unicast Transport addresses for
>> the RR RTCP and RTP receive port.
>> I think that we should first talk about the NAT/FW issue and than
>> define the requirements and solutions.
>>
>> My assumption is that the retransmission server has a publicly
>> reachable address while the receivers may sit behind NATs and will
>> not have a publicly reachable address.
>> Note that the RAMS flow starts from the receiver by RAMS-R so a
>> response to the transport address from where the RAMS-R came should
>> work (RTCP is bi-directional in this case). On the other hand the
>> unicast data flow is to the receiver so the receiver will need to
>> provide a reachable transport address.
>>
>> Roni
>>
>> -----Original Message-----
>> From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of
>> Ali C.
>> Begen (abegen)
>> Sent: Saturday, May 23, 2009 3:27 AM
>> To: Jose Rey
>> Cc: Roni Even; avt at ietf.org; Bill Ver Steeg (versteb)
>> Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast
>> RTPSessions (RAMS)" available
>>
>> Hi Jose,
>>
>> Indeed, RAMS-R goes to the FT of the new primary session that RR is
>> interested in acquiring rapidly. Then the unicast session becomes
>> alive and RS sends RAMS-I message(s) to RR on the RTCP port for the
>> unicast session.
>> After some time, RR sends the RAMS-T message to the RTCP port for the
>> unicast session since it is supposed to end the unicast session.
>>
>> -acbegen
>>
>>> -----Original Message-----
>>> From: Jose Rey [mailto:Jose.Rey at eu.panasonic.com]
>>> Sent: Friday, May 22, 2009 7:09 AM
>>> To: Ali C. Begen (abegen)
>>> Cc: Roni Even; avt at ietf.org; Bill Ver Steeg (versteb)
>>> Subject: RE: [AVT] New draft of "Rapid Acquisition of Multicast
>> RTPSessions (RAMS)"
>>> available
>>>
>>>
>>> Hi Ali,
>>>
>>>>
>>>> Hi Jose,
>>>>
>>>> We have separate RTCP ports for the SSM session and the unicast
>>>> session. Why is it a problem?
>>>
>>> In line 19 you say you specify the dst port for RMS-I (41003), on
>>> RR.
>>> And
>> you say that
>>> would also be the port where the RR sends RMS-T, on RS. That is
>>> mixing the
>> semantics of
>>> a=rtcp for SSM (listening port at Feedback Target = mcast RTCP dst
>>> port)
>> and those of RFC
>>> 3605 (dst port). In other words, you are implicitly assuming that
>> specifies symmetric
>>> RTCP...no?
>>>
>>> Another thing that was mentioned already: RMS-T is not sent to same
>>> port
>> as RMS-R; is it
>>> not the same RTCP session ? Or is this muxing desired? why?
>>>
>>> JLR
>>>
>>>>
>>>> The slightly modified SDP for the next version is below:
>>>>
>>> 1> a=group:FID 3 4
>>> 2> a=rtcp-unicast:rsi
>>> 3> m=video 41000 RTP/AVPF 98
>>> 4> i=Primary Multicast Stream #2
>>> 5> c=IN IP4 233.252.0.2/255
>>> 6> a=source-filter: incl IN IP4 233.252.0.2 192.0.2.2
>>> 7> a=recvonly
>>> 8> a=rtpmap:98 MP2T/90000
>>> 9> a=rtcp:41001 IN IP4 192.0.2.1
>>> 10> a=rtcp-fb:98 nack
>>> 11> a=rtcp-fb:98 nack ssli
>>> 12> a=ssrc:123321 cname:iptv-ch32 at rams.example.com
>>> 13> a=mid:3
>>> 14> m=video 41002 RTP/AVPF 99
>>> 15> i=Unicast Retransmission Stream #2 (Ret. and Rapid
>>>> Acq. Support)
>>> 16> c=IN IP4 192.0.2.1
>>> 17> a=recvonly
>>> 18> a=rtpmap:99 rtx/90000
>>> 19> a=rtcp:41003
>>> 20> a=fmtp:99 apt=98; rtx-time=5000
>>> 21> a=mid:4
>>>>
>>>> This is the SDP we send to RR. For RS, a=recvonly will be
>>>> a=sendonly.
>>>>
>>>> -acbegen
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: José Rey [mailto:jose.rey at eu.panasonic.com]
>>>>> Sent: Thursday, May 21, 2009 3:22 PM
>>>>> To: Ali C. Begen (abegen)
>>>>> Cc: Roni Even; avt at ietf.org; Bill Ver Steeg (versteb)
>>>>> Subject: Re: [AVT] New draft of "Rapid Acquisition of
>>>> Multicast RTPSessions (RAMS)"
>>>>> available
>>>>>
>>>>> Hi all,
>>>>>
>>>>> sorry for jumping in....
>>>>>
>>>>> I think one of the sources of confusion is that the
>>>> attribute a=rtcp:
>>>>> is used once for specifying the destination port and once for
>>>>> specifying a receiving port, and in the same SDP (!). The
>>>> destination
>>>>> port for RAMS-I packets sent by RS and the receiving port
>>>> for RAMS-T. Which is also why different port numbers are used for
>>>> RAMS-T and -R packets.
>>>>>
>>>>> I think the use of a=rtcp: in SSM is the problem here. Or the fact
>>>>> that we are mixing unicast and multicast, or both.
>>>>>
>>>>> Hope this helps,
>>>>>
>>>>> JLR
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Ali C. Begen (abegen) wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Roni Even [mailto:ron.even.tlv at gmail.com]
>>>>> Sent: Saturday, April 25, 2009 2:58 PM
>>>>> To: Ali C. Begen (abegen); avt at ietf.org
>>>>> Cc: Bill Ver Steeg (versteb)
>>>>> Subject: RE: [AVT] New draft of "Rapid Acquisition of
>>>>> Multicast RTPSessions (RAMS)" available
>>>>>
>>>>> Ali,
>>>>> I looked at RFC 4570 and I assume that port
>>>> 41001 is the port for the
>>>>> unicast RTCP reports from the receivers and according to
>>>>>
>>>>>
>>>>>
>>>>> Yes, indeed.
>>>>>
>>>>>
>>>>>
>>>>> section 3.2.1 of
>>>>> that RFC you also should have a RTCP-unicast
>>>> specification.
>>>>> This is for the
>>>>> multicast receiver reports.
>>>>>
>>>>>
>>>>>
>>>>> Correct. We do have that line in our draft at the top
>>>> right after the grouping lines:
>>>>>
>>>>> a=rtcp-unicast:rsi
>>>>>
>>>>> BR,
>>>>> -acbegen
>>>>>
>>>>>
>>>>>
>>>>> Roni
>>>>>
>>>>> -----Original Message-----
>>>>> From: Ali C. Begen (abegen) [mailto:abegen at cisco.com]
>>>>> Sent: Saturday, April 25, 2009 11:30 PM
>>>>> To: Roni Even; avt at ietf.org
>>>>> Cc: Bill Ver Steeg (versteb)
>>>>> Subject: RE: [AVT] New draft of "Rapid Acquisition of
>>>>> Multicast RTPSessions
>>>>> (RAMS)" available
>>>>>
>>>>> Here is the SDP.
>>>>>
>>>>> m=video 41000 RTP/AVPF 98
>>>>> i=Primary Multicast Stream #2
>>>>> c=IN IP4 224.1.1.2/255
>>>>> a=source-filter: incl IN IP4 224.1.1.2 192.0.2.2
>>>>>
>>>>> Source (192.0.2.2) sends the rtp packets to the
>>>> multicast
>>>>> group (224.1.1.2)
>>>>> with a dest port 41000.
>>>>>
>>>>> a=rtpmap:98 MP2T/90000
>>>>> a=rtcp:41001 IN IP4 192.0.2.1
>>>>>
>>>>> The feedback target (RS) address for this SSM session is
>>>>> 192.0.2.1 and its
>>>>> port is 41001. This is the address/port where
>>>> RR sends the RAMS-R, or
>>>>> receiver reports for the SSM session.
>>>>>
>>>>> a=rtcp-fb:98 nack
>>>>> a=rtcp-fb:98 nack ssli
>>>>> a=ssrc:123321 cname:iptv-ch32 at rams.example.com
>>>>> a=mid:3
>>>>> m=video 41002 RTP/AVPF 99
>>>>>
>>>>> The retransmission packets go to port 41002.
>>>> This is the port
>>>>> RRs listen to
>>>>> for retransmission and RAMS.
>>>>>
>>>>> i=Unicast Retransmission Stream #2
>>>> (Ret. and Rapid
>>>>> Acq. Support)
>>>>> c=IN IP4 192.0.2.1
>>>>>
>>>>> This is where the retransmission packets come
>>>> from, same as
>>>>> the feedback
>>>>> target (in this example).
>>>>>
>>>>> a=rtpmap:99 rtx/90000
>>>>> a=rtcp:41003
>>>>>
>>>>> This is where the RTCP packets for the
>>>> retransmission session go. For
>>>>> example, RAMS-I goes to this port on RRs.
>>>> RAMS-T goes to this
>>>>> port on RS.
>>>>>
>>>>> a=fmtp:99 apt=98; rtx-time=5000
>>>>> a=mid:4
>>>>>
>>>>>
>>>>> -acbegen
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Roni Even [mailto:ron.even.tlv at gmail.com]
>>>>> Sent: Saturday, April 25, 2009 1:11 PM
>>>>> To: Ali C. Begen (abegen); avt at ietf.org
>>>>> Cc: Bill Ver Steeg (versteb)
>>>>> Subject: RE: [AVT] New draft of "Rapid
>>>> Acquisition of
>>>>> Multicast RTPSessions (RAMS)" available
>>>>>
>>>>> Ali,
>>>>> Can you please write three addresses
>>>> from this strange SDP.
>>>>>
>>>>> 1. The address and port of multicast
>>>>>
>>>>> 2. The address and port of the RS where
>>>> the RTCP FB should go to
>>>>>
>>>>> 3. The address and port on the RR where
>>>> the unicast stream
>>>>> should be sent to
>>>>>
>>>>> Roni
>>>>>
>>>>> -----Original Message-----
>>>>> From: Ali C. Begen (abegen)
>>>> [mailto:abegen at cisco.com]
>>>>> Sent: Saturday, April 25, 2009 11:02 PM
>>>>> To: Roni Even; avt at ietf.org
>>>>> Cc: Bill Ver Steeg (versteb)
>>>>> Subject: RE: [AVT] New draft of "Rapid
>>>> Acquisition of
>>>>> Multicast RTPSessions
>>>>> (RAMS)" available
>>>>>
>>>>>
>>>>>
>>>>> Ali,
>>>>> The example SDP is
>>>> syntactically correct but it does not
>>>>>
>>>>>
>>>>> say that the
>>>>>
>>>>>
>>>>> rtp/rtcp mux will be used and
>>>> it does not give the
>>>>> information to where the
>>>>> unicast stream will be sent
>>>> when the RR sends a RAMS-R.
>>>>>
>>>>>
>>>>> To my knowledge, the first line in the
>>>> following SDP tells
>>>>> the RRs on which
>>>>> port they will receive the
>>>> retransmission/burst packets.
>>>>>
>>>>> m=video 41002 RTP/AVPF 99
>>>>> i=Unicast Retransmission Stream
>>>> #2 (Ret. and Rapid
>>>>> Acq. Support)
>>>>> c=IN IP4 192.0.2.1
>>>>> a=rtpmap:99 rtx/90000
>>>>> a=rtcp:41003
>>>>> a=fmtp:99 apt=98; rtx-time=5000
>>>>> a=mid:4
>>>>>
>>>>> There is a typo, you are right. That
>>>> "a=recvonly" line should
>>>>> only exist in
>>>>> the SDP sent to RRs. In the SDP sent to
>>>> RS, we should rather have
>>>>> "a=sendonly". I will make this
>>>> correction in the next version.
>>>>>
>>>>> The feedback target for the SSM session
>>>> and the RTCP port for the
>>>>> retransmission session are also defined
>>>> in the SDP.
>>>>>
>>>>> Hope this clarifies.
>>>>>
>>>>> BR,
>>>>> -acbegen
>>>>>
>>>>>
>>>>>
>>>>> I am not sure why the unicast
>>>> stream m-line has a port
>>>>>
>>>>>
>>>>> number with an
>>>>>
>>>>>
>>>>> attribute of recvonly. What is
>>>> the use case for that. The
>>>>> only information
>>>>> that the RR will need is the
>>>> RTCP port on the RS to where to
>>>>> send the RAMS-R
>>>>> message.
>>>>> Roni
>>>>> -----Original Message-----
>>>>> From: Ali C. Begen (abegen)
>>>> [mailto:abegen at cisco.com]
>>>>> Sent: Friday, April 24, 2009 10:37 PM
>>>>> To: Roni Even; avt at ietf.org
>>>>> Cc: Bill Ver Steeg (versteb)
>>>>> Subject: RE: [AVT] New draft of
>>>> "Rapid Acquisition of
>>>>> Multicast RTPSessions
>>>>> (RAMS)" available
>>>>>
>>>>> This is a part of an example
>>>> SDP sent to RS and RR in a SAP
>>>>> announcement,
>>>>> for example. So, the SDP
>>>> describes what both parties should
>>>>> do (RR cannot
>>>>> say that he wants to receive
>>>> this multicast on its favorite
>>>>>
>>>>>
>>>>> port). The
>>>>>
>>>>>
>>>>> individual SDPs sent to RR or
>>>> RS may include other portions
>>>>> of descriptions
>>>>> that will contain specific information.
>>>>>
>>>>> -acbegen
>>>>>
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Roni Even
>>>> [mailto:ron.even.tlv at gmail.com]
>>>>> Sent: Friday, April 24,
>>>> 2009 12:23 PM
>>>>> To: Ali C. Begen
>>>> (abegen); avt at ietf.org
>>>>> Cc: Bill Ver Steeg (versteb)
>>>>> Subject: RE: [AVT] New
>>>> draft of "Rapid Acquisition of
>>>>> Multicast RTPSessions
>>>> (RAMS)" available
>>>>>
>>>>> Ali,
>>>>> I think you get it
>>>> wrong, this SDP is from the RS and not the
>>>>> RR so the RS
>>>>> cannot specify to which
>>>> address it will send it can only
>>>>> specify to which
>>>>> address it can receive
>>>> RTP stream. In this SDP the relevant
>>>>> information is
>>>>> that the request for
>>>> retransmission will be sent by the RR to
>>>>> port 41003
>>>>> Roni
>>>>>
>>>>> -----Original Message-----
>>>>> From: Ali C. Begen
>>>> (abegen) [mailto:abegen at cisco.com]
>>>>> Sent: Friday, April 24,
>>>> 2009 10:01 PM
>>>>> To: Roni Even; avt at ietf.org
>>>>> Cc: Bill Ver Steeg (versteb)
>>>>> Subject: RE: [AVT] New
>>>> draft of "Rapid Acquisition of
>>>>> Multicast RTPSessions
>>>>> (RAMS)" available
>>>>>
>>>>> Oh, I see. The burst
>>>> goes to the port that we would
>>>>>
>>>>>
>>>>> normally send the
>>>>>
>>>>>
>>>>> retransmissions. For
>>>> example, consider the SDP from the draft:
>>>>>
>>>>> m=video 41000
>>>> RTP/AVPF 98
>>>>> i=Primary
>>>> Multicast Stream #2
>>>>> c=IN IP4 224.1.1.2/255
>>>>>
>>>> a=source-filter: incl IN IP4 224.1.1.2 192.0.2.2
>>>>> a=rtpmap:98 MP2T/90000
>>>>> a=rtcp:41001 IN
>>>> IP4 192.0.2.1
>>>>> a=rtcp-fb:98 nack
>>>>> a=rtcp-fb:98 nack ssli
>>>>> a=ssrc:123321
>>>> cname:iptv-ch32 at rams.example.com
>>>>> a=mid:3
>>>>> m=video 41002
>>>> RTP/AVPF 99
>>>>> i=Unicast
>>>> Retransmission Stream #2 (Ret. and Rapid
>>>>> Acq. Support)
>>>>> c=IN IP4 192.0.2.1
>>>>> a=recvonly
>>>>> a=rtpmap:99 rtx/90000
>>>>> a=rtcp:41003
>>>>> a=fmtp:99
>>>> apt=98; rtx-time=5000
>>>>> a=mid:4
>>>>>
>>>>> In this case, the burst
>>>> will go to port 41002 on the RR.
>>>>>
>>>>>
>>>>> The RAMS-I
>>>>>
>>>>>
>>>>> message(s), which is an
>>>> RTCP feedback message, will go to
>>>>>
>>>>>
>>>>> port 41003.
>>>>>
>>>>>
>>>>> HTH,
>>>>> -acbegen
>>>>>
>>>>>
>>>>>
>>>>> -----Original
>>>> Message-----
>>>>> From: Roni Even
>>>> [mailto:ron.even.tlv at gmail.com]
>>>>> Sent: Friday,
>>>> April 24, 2009 11:44 AM
>>>>> To: Ali C.
>>>> Begen (abegen); avt at ietf.org
>>>>> Cc: Bill Ver
>>>> Steeg (versteb)
>>>>> Subject: RE:
>>>> [AVT] New draft of "Rapid Acquisition of
>>>>> Multicast
>>>> RTPSessions (RAMS)" available
>>>>>
>>>>> Ali,
>>>>> I will try to
>>>> explain in simple way
>>>>>
>>>>> When the RS
>>>> receives the RAMS-R it need to start sending an
>>>>> RTP stream to
>>>>> the RR.
>>>>> In order to
>>>> send a unicast packet, the RS needs to know a
>>>>> transport address
>>>>> on the RR to
>>>> where the RTP stream will be sent. The current
>>>>> draft does not
>>>>> say how the RS
>>>> knows this address. There is no SDP from RR to
>>>>> RS like you
>>>>> mention in your
>>>> response.
>>>>> This is why I
>>>> say that the current draft does not specify a
>>>>> solution that
>>>>> can be
>>>> implemented as a working solution
>>>>> Roni
>>>>>
>>>>> -----Original
>>>> Message-----
>>>>> From: Ali C.
>>>> Begen (abegen) [mailto:abegen at cisco.com]
>>>>> Sent: Friday,
>>>> April 24, 2009 7:38 PM
>>>>> To: Roni Even;
>>>> avt at ietf.org
>>>>> Cc: Bill Ver
>>>> Steeg (versteb)
>>>>> Subject: RE:
>>>> [AVT] New draft of "Rapid Acquisition of
>>>>> Multicast RTPSessions
>>>>> (RAMS)" available
>>>>>
>>>>> Hi Roni,
>>>>>
>>>>>
>>>>>
>>>>>
>>>> -----Original Message-----
>>>>> From:
>>>> avt-bounces at ietf.org [mailto:avt- bounces at ietf.org] On
>>>>> Behalf
>>>> Of Roni Even
>>>>> Sent:
>>>> Friday, April 24, 2009 4:24 AM
>>>>> To: avt at ietf.org
>>>>> Cc:
>>>> Bill Ver Steeg (versteb)
>>>>>
>>>> Subject: Re: [AVT] New draft of "Rapid Acquisition of
>>>>>
>>>> Multicast RTPSessions (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
>>>>>
>>>>>
>>>>> What do you
>>>> mean by "a system that works"?
>>>>>
>>>>>
>>>>>
>>>>> RS
>>>> knows the unicast transport address on the RR to
>>>>>
>>>>>
>>>>> where to
>>>>>
>>>>>
>>>>> send the stream.
>>>>>
>>>>>
>>>>> Once RS
>>>> receives the request packet from an RR, RS knows its
>>>>> address. Ports
>>>>> are defined in
>>>> the SDP. If you are asking about "NAT"
>>>>> issues,
>>>>> we have a
>>>>> section for it,
>>>> and we plan to complete it as we move
>>>>> forward. It is not as
>>>>> critical as the
>>>> other parts for now.
>>>>>
>>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>>
>>>>> IMO, we cannot
>>>> mandate muxing as it is not required to make
>>>>> RAMS work. If
>>>>> muxing is
>>>> supported, the SDP should reflect it.
>>>>>
>>>>> BR,
>>>>> -acbegen
>>>>>
>>>>>
>>>>>
>>>>> Thanks
>>>>>
>>>>> Roni Even
>>>>>
>>>>>
>>>>>
>>>>> From:
>>>> avt-bounces at ietf.org [mailto:avt- bounces at ietf.org] On
>>>>> Behalf
>>>> Of Bill Ver Steeg (versteb)
>>>>> Sent:
>>>> Thursday, April 16, 2009 7:39 PM
>>>>> To: avt at ietf.org
>>>>>
>>>> Subject: [AVT] New draft of "Rapid Acquisition of Multicast
>>>>> RTP
>>>> Sessions (RAMS)" available
>>>>>
>>>>>
>>>>>
>>>>> 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-s
>>>>>
>>>>>
>>>>>
>>>> ynchronization-for-rtp-03.txt
>>>>> <http://www.ietf.org/internet-> <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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Audio/Video Transport Working Group
>>>>> avt at ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/avt
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> Panasonic R&D Center Germany GmbH
>>> 63225 Langen, Hessen, Germany
>>> Reg: AG Offenbach (Hessen) HRB 33974 Managing Director: Thomas Micke
>>>
>>
>> _______________________________________________
>> 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
>