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

From: "Jae-Hwan Kim" <[email-masked]>
Date: Fri, 5 Sep 2003 19:14:11 +0900

Hi Magnus,

RFC just says that a player may deduce the duration of the session from 't=' or 'r='.
-----------(snip)--------------

C.1.5 Range of presentation

   The "a=range" attribute defines the total time range of the stored
   session. (The length of live sessions can be deduced from the "t" and
   "r" parameters.) Unless the presentation contains media streams of
   different durations, the range attribute is a session-level
   attribute. The unit is specified first, followed by the value range.
   The units and their values are as defined in Section 3.5, 3.6 and
   3.7.
-----------(snip)--------------

I understand a=range is not madatory field in IETF document. An example
in RTSP shows no a=range SDP is also possible. In 3GPP, however, 
the specification made it mandatory. Therefore we need to be forced 
to use this field here at first if you want to look upon it as an indication 
of live session.

Why do you need to define a new way for live indication?
Although there is no live indication method, the server can respond
appropriately for the PAUSE or PLAY with range. 
If defining new SDP attribute is not easy, I think your try will meet 
the same obstacle.

In my previous e-mail, the 24 hours was no more than an example. 
A server using closed range even in case of live session is possible.
I have no idea why the server uses it if that server is not mine. 
Perhaps a player only can understand the closed range so that
the server might be implmented closed range only for this player.
Because there has been no rule restricting the use of closed range for live session,
we can not blame the player understanding only closed range and 
the server providing always only closed range at this moment. 
(the original purpose of a=range is just for duration information).
Even if the player may have no relationship to me, if it is in our boundary, 
it is not easy for me to just overlook it. IMO, for a new rule, 
we need to think of its backward compatibility.

Basically I think your approach is good. It is true that we use open range 
in general when the live session is used. I know only one implementation 
not following this general usage(and RTSP example). 
I agree that using open range is the very easy and convenient way for us 
because any new SDP attribute is not required. 

Finally, If open a=range is used as mandatory, the player (I mentioned) 
must be fixed even if it is not easy. Proveded that this usage is just informative, 
however, the player don't need to be fixed and it can distinguish 
the session type from the original way. The server using closed range 
is allowed in natural. On the other hand, many other new *good* players 
can use the both ways. The open a=range will probably be 
a good guidance for live session.

Sincerely Yours,
Jae-Hwan

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]] 
Sent: Wednesday, September 03, 2003 8:30 PM
To: Jae-Hwan Kim
Cc: Amir Wolf; IETF MMUSIC WG
Subject: Re: [MMUSIC] RTSP: The use of the SDP attribute "a=range:"

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

Jae-Hwan Kim wrote:

> 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)ߣȜ

-- 

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]

&��"rf��)��+-�k��Ȟ��+�m����5��_��?�������+-�w��i��'

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 05 Sep 2003 13:04:28 +0200

Hi Kim,

I think we are basically in agreement. I don't intend to have the use of 
open range as mandatory for a live session. However I like to have an 
clearly understandable definition of any open ended range given. So that 
when a server gives this, a client will understand what it means. Then 
if the session is not the most common case further information will be 
required to override the basic property given by the open ended range.

I think we have considered backwards compatibility fairly well. I know 
that such a definition at this stage of time can't be guaranteed to work 
in 100% of the clients. However this is mostly due to that there has 
been non clear definition of how to interpret the a=range attribute.

I think that the backwards compatibility is good due to:

- It is a common interpretation.

- It is not required to be present. Once can signal a closed interval 
also for a live session. However the effects of this unless other 
attributes are used will be that it will appear seekable and client will 
probably treat it as on-demand content.

- It follows what most consider to be obvious possible usage of the 
"a=range" attribute.

- If one does not understand the non-seekability definition of an open 
range one will still be able to use this stream, unless one requires 
closed ranges. If the client tries to seek the server can indicate in 
the response that it is not possible.

I am also trying to have a common understanding of this between 3GPP and 
IETF. This definition will provide this. It is also based on a 
interpretation made by people prior to the 3GPP PSS work.

So I will go forward with writing an update to section C.1.5 for the 
RTSP specification.

Thanks

Magnus

-- 

Magnus Westerlund