Subject: [MMUSIC] I-D ACTION:draft-srikantan-mmusic-rtsp-streaming-relay-00.txt

From: [email-masked]
Date: Thu, 04 Dec 2003 15:37:52 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Streaming Relays
	Author(s)	: G. Srikantan
	Filename	: draft-srikantan-mmusic-rtsp-streaming-relay-00.txt
	Pages		: 0
	Date		: 2003-12-4
	
Delivery of streaming media to a large number of clients distributed
across several geographic and network boundaries presents several
challenges in terms of scalability and stream quality. This document
describes N-tier relays to address scalability and quality issues in
the delivery of stored and live content. This document addresses
issues in stream synchronization, content announcement/expiry,
reliability of transport, failover/recovery, administration, and
security issues. This document propose a set of primitives to enable
implementation of Push and Pull mechanisms for N-tier relays. We also
provide usage scenarios where each approach is most useful. The Pull
and Push  mechanisms are complementary and provide valuable building
blocks in N-tier relays. This document introduces a few new RTSP
methods and headers.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-srikantan-mmusic-rtsp-streaming-relay-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-srikantan-mmusic-rtsp-streaming-relay-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-srikantan-mmusic-rtsp-streaming-relay-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Colin Perkins <[email-masked]>
Date: Thu, 11 Dec 2003 22:50:42 +0000

Geetha, all,

> http://www.ietf.org/internet-drafts/draft-srikantan-mmusic-rtsp-streaming-relay-00.txt

Nice survey of the mechanisms and possible solutions.  Would you envisage
all these approaches being useful for different scenarios, or would it be
appropriate to choose a subset which could be written up as a BCP - perhaps
along with some standard RTSP extensions?

-- 
Colin Perkins
http://csperkins.org/

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Geetha Srikantan <[email-masked]>
Date: Fri, 12 Dec 2003 08:14:56 -0800

hi Colin,

Thanks for reviewing the document.

More inline..

> along with some standard RTSP extensions?

We see these approaches as being useful individually and in combination,
depending on the scenario. The RTSP methods and headers needed are
as summarized below. It would be great to get these into the core RTSP
spec, if not, then as an RTSP extension.

Methods for content availability notification and server capability
detection in both Push and Pull mechanisms:

	ANNOUNCE for multicast Push
	ANNOUNCE_RELAY for unicast Pull 
	ANNOUNCE_RECEIVE for unicast Push

Methods for Push mechanism:
	SETUP with mode=receive
	RECEIVE

Headers to be used with ANNOUNCE* methods for both Push and Pull
mechanisms:
	Content-Lifetime: <start-date>-<end-date>
	Content-Revoke: <start-date>
	Alternate-Source: <url>
	Recovery: <Retry connection or not>; <retry duration>;
		  <retry rate>

I'm not sure what BCP is..would you elaborate?

thanks
geetha

-- 
Geetha Srikantan <[email-masked]>

---

From: Colin Perkins <[email-masked]>
Date: Fri, 12 Dec 2003 18:11:26 +0000

Hi,

> On Thu, 2003-12-11 at 14:50, Colin Perkins wrote:
...
> > Nice survey of the mechanisms and possible solutions.  Would you
> > envisage all these approaches being useful for different scenarios, or
> > would it be appropriate to choose a subset which could be written up as
> > a BCP - perhaps along with some standard RTSP extensions?
> 

Do we need all of these?  It would ease interoperability if we could define
a single approach that worked for all scenarios, and this may even be worth
doing if the result is a little less optimal. 

> I'm not sure what BCP is..would you elaborate?

A "Best Current Practice" RFC, as a way of describing how other existing
components can be combined to solve a particular class of problem. 

-- 
Colin Perkins
http://csperkins.org/