[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Attachment: PGP.sig
Description: PGP signature