Subject: RE: [MMUSIC] RTSP: The use of the SDP attribute "a=range:"

From: "Jae-Hwan Kim" <[email-masked]>
Date: Wed, 3 Sep 2003 15:44:48 +0900

Due to some reasons, a server can not use open range. Not all server must use open range in case of live. A special live server just allows 24 hours play. Generally, indicating the target is live streaming server is WAP/Web server. Morever, I know a commercial player can not understand(even can not play) SDP session level open range. Of course I believe this implementation is wrong. If we can, however, I think defining new SDP attribute for live indication would be better.

-Jae-Hwan

-----Original Message-----
From: Amir Wolf [mailto:[email-masked]] 
Sent: Friday, August 22, 2003 6:24 AM
To: Magnus Westerlund; IETF MMUSIC WG
Subject: RE: [MMUSIC] RTSP: The use of the SDP attribute "a=range:"

Hi Magnus,
In the PSS AG we have been testing live as part of our interoperability tests. The vendors that supplied the live feeds (servers) used an open range as an identifier for the link being a live link. It appears that all the clients got the message and treated this session as live. 

	-----Original Message----- 
	From: Magnus Westerlund [mailto:[email-masked]] 
	Sent: ה 21/08/2003 17:47 
	To: IETF MMUSIC WG 
	Cc: 
	Subject: [MMUSIC] RTSP: The use of the SDP attribute "a=range:"

	Hi,
	
	During the 57th IETF meeting we discussed the meaning of open intervals
	for the SDP attribute a=range, e.g. "a=range:npt=0-". My memory and
	notes indicates that the conclusions made was:
	
	1. An open range indicates a media with unknown duration.
	
	2. There seem to be need for more attributes expressing things like:
	seekability.
	
	The start of the discussion on this topic was the usability of an open
	range to indicate that media is live and not seekable. There where
	comments that even though a session is live it might be seekable, at
	least into the past, i.e. behind "now". This is can be accomplished by
	on the fly recording servers. However there is a lack of possibility to
	express this capability.
	
	There are currently implementations that interpret an open range as not
	being seekable, for example the quicktime 6.3 player. So to rehash the
	question in this forum:
	
	Would it be acceptable to define an open interval range attribute as
	being live and non seekable unless other attributes give further
	properties, like seekable?
	
	If you own a commercial implementation of a RTSP client, could you
	please inform how it would react to an open range?
	
	Looking forward to your comments.
	
	Cheers
	
	Magnus Westerlund
	
	Multimedia Technologies, Ericsson Research EAB/TVA/A
	----------------------------------------------------------------------
	Ericsson AB                | Phone +46 8 4048287
	Torshamsgatan 23           | Fax   +46 8 7575550
	S-164 80 Stockholm, Sweden | mailto: [email-masked]

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

kɚXXi'"zm?0'~ffX)ߣȜ
	��Ȝ����x%��f��"r'�~����i����
bz���j)fj��b��?�k��

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 03 Sep 2003 13:29:52 +0200

Hi Kim,

I don't see why the argument you specify would not allow a server to use 
open ended range to specify the live content. If the server will only 
keep a live session for 24 hours the SDP should contain "t=" attribute 
that specify this.

Any client that does not allow open ranges in the SDP attribute 
"a=range" has not trying to be very reasonable in the interpretation of 
the attribute. I know that there are no ABNF specification for the 
attribute in RFC 2326. However if one compare it with the RTSP header 
Range, such an interpretation seems to be very limited. So I definitely 
agree with you that such implementation should be corrected. In the RTSP 
update we are going for an ABNF of the "a=range" attribute that looks 
like this.

    This attribute is defined in ABNF [14] as:

    a-range-def = "a" "=" "range" ":" ranges-specifier CRLF 

This definition will allow the presence of any range format that are 
specified, but not multiple ranges or formats that is allowed by the 
Range header's ABNF.

The reason I have proposed this is that there are a clear and present 
need for having something simple for the basic case of non-seekable and 
unknown duration. Therefore I proposed to document a behaviour that are 
very common in several implementations.

If one have use cases which can't be mapped into a this simple use case 
where one has a media of undetermined length with no seekability, then 
we do need a new way of signalling this. However as this attribute can 
be used to override the basic case I don't see a problem with the basic 
definition.

So anyone having need for more property attributes, like seekable, 
non-seekable, partially seekable in some intervals, seekable to all 
times from start to current position, for media stream should start work 
to define this here in MMUSIC.

Best Regards

Magnus

-- 

Magnus Westerlund