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

From: Martin Stiemerling <[email-masked]>
Date: Tue, 19 Oct 2010 15:07:10 +0000

Hi Magnus,

Your comment makes good sense. It would be good to have a short text capturing the below example as when the Content-Location header can be used and also to clarify the difference to the MTag. 

This wasn't clear to me and I guess implementers may also have a hard time to see the difference. 

  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 

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Monday, September 27, 2010 4:01 PM
> To: Tom Taylor
> Cc: Martin Stiemerling; mmusic
> Subject: Re: [MMUSIC] Content-Location in RTSP 2.0
> 
> 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]
> ----------------------------------------------------------------------

---

From: Tom Taylor <[email-masked]>
Date: Thu, 21 Oct 2010 10:09:07 -0400

Agreed with that resolution. I have snipped all of the earlier 
conversation except one point that had eluded me: how the application 
uses the URI provided by Content-Location. I had missed the ability to 
send it in the a=control line. I'm only repeating that point to verify 
that this is correct.

On 19/10/2010 11:07 AM, Martin Stiemerling wrote:
> Hi Magnus,
>
> Your comment makes good sense. It would be good to have a short text
> capturing the below example as when the Content-Location header can
> be used and also to clarify the difference to the MTag.
>
> Limited | Registered Office: NEC House, 1 Victoria Road, London W3
> 6BL | Registered in England 2832014
>
>
>> -----Original Message----- From: Magnus Westerlund
>> [mailto:[email-masked]] Sent: Monday, September 27,
>> 2010 4:01 PM To: Tom Taylor Cc: Martin Stiemerling; mmusic Subject:
>> Re: [MMUSIC] Content-Location in RTSP 2.0
>>
[snip]
>>
>> 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.
>>
[snip]
>> Tom Taylor skrev [snip]
[snip]

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 22 Oct 2010 10:52:51 +0200

> send it in the a=control line. I'm only repeating that point to verify 

Yes, it can either be used as the base-uri for relative URIs. It can
also be used in DESCRIBE requests to check if there is a newer version
of the file available, i.e. verify that the cache is up to date.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 22 Oct 2010 16:30:58 +0200

Hi,

> a Content-Location if you want to query something around that specific

The sentence: "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."

That is in error as there is a written limitation for MTags in Section
4.8 that says:
A message body tag MUST be unique across all versions of all message
   bodies associated with a particular resource.

I have written some extra text for the Content-Location header section
so it now reads:

16.17.  Content-Location

   The Content-Location header field MAY be used to supply the resource
   location for the message body enclosed in the message when that body
   is accessible from a location separate from the requested resource's
   URI.  A server SHOULD provide a Content-Location for the variant
   corresponding to the response message body; especially in the case
   where a resource has multiple variants associated with it, and those
   entities actually have separate locations by which they might be
   individually accessed, the server SHOULD provide a Content-Location
   for the particular variant which is returned.

   The Content-Location value is not a replacement for the original
   requested URI; it is only a statement of the location of the resource
   corresponding to this particular variant at the time of the request.
   Future requests MAY specify the Content-Location URI as the request
   URI if the desire is to identify the source of that particular
   variant.  This is useful if the RTSP agent desires verify if the
   resource variant is current through a conditional request.

   A cache cannot assume that an message body with a Content-Location
   different from the URI used to retrieve it can be used to respond to
   later requests on that Content-Location URI.  However, the Content-
   Location can be used to differentiate between multiple variants
   retrieved from a single requested resource.

   If the Content-Location is a relative URI, the relative URI is
   interpreted relative to the Request-URI.

   Note, that Content-Location can be used in some cases to derive the
   base-URI for relative URI present in session description formats.
   This needs to be taken into account when Content-Location is used.
   The easiest way to avoid needing to consider that issue is to include
   the Content-Base whenever the Content-Location is included.

   Note also, when using Media Tags in conjunction with Content-Location
   it is important that the different versions have different MTags,
   even if provided under different Content-Location URIs.  This as they
   have still been provided under the same request URI.

   Note also, as in most cases as the URI used in the DESCRIBE and the
   SETUP requests are different the URI provided in a DESCRIBE Content-
   Location response can't directly be used in a SETUP request.  Instead
   the extra step of resolving URIs combined with the media descriptions
   indication, like with SDP's a=control attribute.

Comments appreciated.

-- 

Magnus Westerlund