Subject: Re: [MMUSIC] Content-Location in RTSP 2.0

From: Magnus Westerlund <[email-masked]>
Date: Mon, 27 Sep 2010 16:00:39 +0200

Hi,

We are trying to close the issues that remain on RTSP 2.0 so that the
chairs can do a publication request unless we require another WGLC.
However, lets discuss Content-Location.

The main purpose for Content-Location is cases where there is multiple
versions, like for different device types or different session
description formats. SDP is pretty dominating, but in case you have
other formats, there is quite likely that you do the following:

DESCRIBE rtsp://a.example.org/foo/movie
Accept: application/sdp-ng;application/sdp

200 OK
Content-Location: rtsp://a.example.org/foo/movie-sdp-ng

[SDP-NG description of content]

So it is primarily not for different versions in time or so. It is more
for results based on functionality, capability or negotiation between
server and client where it is reasonable to have multiple version for
the same basic content. Maybe different receiver devices would be a
better example, like a HD Topset box compared to a mobile device.

So from a description caching perspective there is some usage of
Content-Location. But, if you want to ensure that you have a current
version in cache, MTag is clearly the way to go. However, as MTag is
defined in RTSP the MTag value for an SDP and SDP-NG description of the
same content could easily use the same MTAG. Thus requiring the need of
a Content-Location if you want to query something around that specific
resource.

Also Content-Location does not provide any linking between the DESCRIBE
and the SETUP. That has to be done by the included a=control URI or
similar to ensure that the client request the right version of media
streams. MTag is also specified to have a cross request persistence
making it usable to ensure that the media setup is the one actually
described.

Based on that it I think there is functionality in Content-Location that
isn't replaceable by MTag. However, it does only affect the small class
of agents that care about handling particular device configurations for
a content.

So my question are there need for further clarifications? And does
anyone thing that the functionality should be removed, or definitely
wants it?

Cheers

Magnus

Tom Taylor skrev 2010-06-30 14:23:
> I can see the possibility of using Content-Location to check on the currency of 
> an SDP cache. That doesn't require retrieving content through the URI, just 
> making comparisons with it.
> 
> We should probably make MTags the only way to check on currency of cached resources.
> 
> Martin Stiemerling wrote:
>> Hi Tom,
>>
> ...
> 
>>>
>>> It makes no sense to point to the original location of an RTSP entity 
>>> (i.e., the presentation description, the SDP) because there is no way one
>>> can use that pointer (URI) in a subsequent request.
>>>
> ...
> 
>>
>> One usage not described above is for cache handling of SDPs (Section 18.2)
>> and related checking if a resource has been modified (Section 15.3.4).
>>
>> The checking if a resource has been modified (Section 15.3.4) can be done
>> without the Content-Location header by using MTags.
>>
>> However, the cache handling in Section 18.2 might require this, as the
>> Content-Location header can be used to determine whether the SDP requested is
>> still up-to-date or not. However, the caching part may be under specified, as
>> it inherits a lot from HTTP, but not all parts.
>>
>> I also have to admit that the Content-Location header might be indeed to much
>> legacy inherited of HTTP.
>>
>> Martin
>>
>>
>> [email-masked]
>>
>> NEC Laboratories Europe - Network Research Division NEC Europe Limited |
>> Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in
>> England 2832014 _______________________________________________ mmusic
>> mailing list [email-masked] https://www.ietf.org/mailman/listinfo/mmusic
>>
>>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
> 

-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------