Subject: [MMUSIC] Aggregate Control URI

From: Aravind Narasimhan <[email-masked]>
Date: Sun, 29 Jun 2003 19:52:02 -0400

Hey Folks,

More spec clarifications:  This time with regards to the definition and 
specification of Aggregate control URI.

Section 1.4
Old Wording:
Aggregate control URI: The URI that represents the whole aggregate. 
Normally specified in the session description.

Proposed New Wording:
Aggregate control URI: The URI used in a RTSP request to refer to and 
control an aggregated session. It normally, but not always, corresponds 
to the presentation URI specified in the session description. See 
Section 11.3 for more information.

Also added the following to Section 11.3, SETUP Method:

An Aggregate control URI MUST be used to control an aggregated session. 
This URI MUST be different from the stream control URIs of the 
individual media streams included in the aggregate. The Aggregate 
control URI SHOULD be specified by the session description since there 
is no general rule for deriving it from the various stream control URIs 
in the session. If an Aggregate control URI is not specified in the 
session description, a client MUST create an URI for aggregate control 
of the session. This URI MUST contain the servers host address and MUST 
contain the port, if applicable. Once an URI is used to refer to an 
aggregation for a given session, that URI MUST be used to refer to that 
aggregation for the duration of the session. If the contents of the 
aggregation change, then a different aggregate control URI SHOULD be used.

While the session ID has enough information for aggregate control of a 
session, the Aggregate control URI is still important for some methods 
such as SET PARAMETER where the control URI enables the resource in 
question to be easily identified. The Aggregate control URI is also 
useful for proxies, enabling them to route the request to the 
appropriate server, and for logging, where it is useful to note the 
actual resource that a request was
operating on. Finally, presence of the Aggregate control URI allows for 
backwards compatibility with RFC 2326 [21].

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

---

From: Aaron Colwell <[email-masked]>
Date: Mon, 30 Jun 2003 09:55:02 -0700 (PDT)

Comments inline

> aggregation change, then a different aggregate control URI SHOULD be used.

I'm a little confused about why the client MUST create a aggregate control
URI if one does not exist in the content description. I thought the
presence of the session level control URI was what signalled whether
aggregate control was supported by the server for this piece of content.
If this field is not present, I thought the client was to assume that
aggregate control was not supported and just control the stream
seperately. Is this not the case? It seems to me that the server is the
one that know whether it supports aggregate control and should be the one
that dictates what the aggregate control URL should be. I don't think that
the server should have to deal with something that the client just made up
on its own.

Aaron

---

From: Tom Marshall <[email-masked]>
Date: Mon, 30 Jun 2003 10:41:55 -0700

> the server should have to deal with something that the client just made up

Suppose a client wishes to play audio from one file and video from another
with an aggregated session.  There is no real aggregate control url to use. 
The server should be watching for each of the stream urls to determine
whether non-aggregate control is in use.  In a separate conversation, it was
agreed that the Session header is to take precedence over the url in the
request in case they don't match.  Therefore, in the absence of an obvious
aggregate control url, a reasonable fallback is rtsp://host:port/.  It will
work through proxies and it will not conflict with the stream urls.

This is admittedly a corner case.  I am not aware of any real world
scenarios where it would happen.  Magnus filed the bug [1] so he may have a
real world scenario in mind.  It is obviously preferable to use an aggregate
url but we should probably define behavior in case it is not present.

[1] http://rtsp.org/bug640272

-- 
Harrison's Postulate:
        For every action, there is an equal and opposite criticism.

---

From: Aaron Colwell <[email-masked]>
Date: Mon, 30 Jun 2003 11:06:26 -0700 (PDT)

Makes sense to me. I guess I hadn't thought of that case.

Aaron