Subject: Re: [MMUSIC] Aggregate Control URI

From: Magnus Westerlund <[email-masked]>
Date: Thu, 03 Jul 2003 15:17:38 +0200

Hi,

A few words in relation to this. When I filed the bug I was thinking of 
such a case that you try to aggregate two different media that the 
server did not offer as an aggregated session. However during 
discussions I have come to the conclusion that it will be difficult to 
use. However the aggregated control URI resolution may have more usage 
when it comes to session that are supposed to be used where the 
aggregated control URL is missing. I do think it is good to have stated 
a direction on how this is resolved in cased when information is missing 
but the server allows it.

Note that a server can always refuse to perform aggregation of a media 
with another, by responding to a SETUP request trying to aggregate with 
a "459 Aggregate operation not allowed" error code. In that case the 
client will have to perform synchronization, etc. locally using two 
non-aggregated sessions.

"If an Aggregate control URI is not specified in the session 
description, a client MUST create an URI for aggregate control of the 
session."

I don't think this formulation is good. The reason a session description 
does not give a aggregated control URI is that it does not desire the 
media to be aggregated. I would reformulate the sentence into:

If an Aggregate control URI is not specified in the session description, 
it is probably a indication that non-aggregated control SHOULD be used. 
However a client MAY try to SETUP the session in aggregated control. If 
the server refuse to aggregate the specified media, the server SHALL use 
the 459 error code. If the server allows the aggregation, then the 
client MUST create an URI for aggregate control of the session. This URI 
MUST contain the servers host address ...

As a conclusion, I don't see a problem with this resolution, although it 
is not what we had discussed. So I can understand any comments to this. 
What do you think of the updated text?

Best Regards

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

---

From: Aravind Narasimhan <[email-masked]>
Date: Thu, 10 Jul 2003 17:33:36 -0400

Comments line:

Magnus Westerlund wrote:

> Hi,
>
> A few words in relation to this. When I filed the bug I was thinking 
> of such a case that you try to aggregate two different media that the 
> aggregated control URL is missing. I do think it is good to have 
> stated a direction on how this is resolved in cased when information 
> is missing but the server allows it.
>
> with another, by responding to a SETUP request trying to aggregate 
> with a "459 Aggregate operation not allowed" error code. In that case 
> the client will have to perform synchronization, etc. locally using 
> two non-aggregated sessions.
>
> I don't think this formulation is good. The reason a session 
> description does not give a aggregated control URI is that it does not 
> desire the media to be aggregated. I would reformulate the sentence into:
>
> If an Aggregate control URI is not specified in the session 
> description, it is probably a indication that non-aggregated control 
> SHOULD be used. However a client MAY try to SETUP the session in 
> aggregated control. If the server refuse to aggregate the specified 
> media, the server SHALL use the 459 error code. If the server allows 
> the aggregation, then the client MUST create an URI for aggregate 
> control of the session. This URI MUST contain the servers host address ...
>
> As a conclusion, I don't see a problem with this resolution, although 
> it is not what we had discussed. So I can understand any comments to 
> this. What do you think of the updated text? 

I think this works.  My only comment is that I think we need clarify the 
definition of exactly what aggregate control means.  The spec. is till 
unclear about this in many places.  I think it is important to make sure 
that we re-check the use of the phrases "aggregate control" and 
"non-aggregate control" within the spec.  Specifically aggregate control 
should be anything that happens within a session, whether a session has 
0, 1 or more media.  "Non-aggregate control" should be anything that 
happens between multiple sessions, regardless of how many media 
resources each session has.  What we need to clearly state is that RTSP 
only deals with specifying aggregate control of media through a RTSP 
session, and not with other problem of non-aggregate control of multiple 
sessions.

Do people agree with this interpretation?

Thanks

Aravind

---

From: Bill May <[email-masked]>
Date: Thu, 10 Jul 2003 14:52:07 -0700

Aravind Narasimhan wrote:
 >  Specifically aggregate control

No, not really.  Aggregate control to me has meant a method of controlling all
streams in a session simultaneously.  This can happen only if there is an
a=control statement before any media.

Non aggregate control has meant individual control of streams within a session.
These use the a=control statement required by the media.

I guess I do not understand where multiple sessions come in.

Can you enlighten me as to where I'm wrong ?

Bill May
Cisco Systems

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 11 Jul 2003 09:12:10 +0200

Hi Aravind and Bill,

My view on aggregated control has been that this is a media session 
which has at least 2 media. That forces a server to run these under 
aggregated control according to the new spec. Non-aggregated control is 
when a session has only 1 media. However I agree that this is not a 
watertight definition as a client could potentially use the aggregated 
control URL to control a session with only a single media. However there 
is some clear differences in behaviour between a session with 1 media 
and another with 2 media.

I do agree that we need to resolve this and use it consistently through 
the draft. What we need to express in the draft, I believe is the 
differences between a 1 media session and a 2 or more media session. 
Then we can of course better explain that using multiple 1 media 
sessions allow the client maximal control of how to handle the media. 
Then we must also clarify how the aggregated and non-aggregated control 
URI fit.

Best Regards

Magnus

Bill May wrote:

>> should be anything that happens within a session, whether a session 
>> has 0, 1 or more media.  "Non-aggregate control" should be anything 
>> that happens between multiple sessions, regardless of how many media 
>> resources each session has.  What we need to clearly state is that 
>> RTSP only deals with specifying aggregate control of media through a 
>> RTSP session, and not with other problem of non-aggregate control of 
>> multiple sessions.
>>

-- 

Magnus Westerlund

---

From: Aravind Narasimhan <[email-masked]>
Date: Fri, 11 Jul 2003 10:40:35 -0400

Hi Bill,

comments inline:

> a=control statement before any media.

The a=control attribute at the session level of an SDP description 
indicates that URL that should be used for aggregate control of the 
presentation that is being described.  While this is what the client 
should use for aggregate control of the presentation, this is not a 
normative requirement from the RTSP spec.  For one thing RTSP and SDP 
are not tied together.  You could potentially use a different standard 
for describing a session.  Secondly, as Tom and Magnus have mentioned, a 
user may try to aggregate multiple streams in one RTSP session, where 
there isnt a unified presentaiton description, or where someone has 
ignored to put a session level aggregate control URL in the SDP.  Now 
the server has the right to say that it cannot aggregate the given media 
URLs in a session, but it does not make sense for the server to allow 
two or more streams to be part of a session where each stream within the 
session is going ot be controlled separately in a non-aggregate fashion.

In the RTSP concalls of late, there was a general trend towards a 
consensus that within a RTSP session, all streams should be "aggregately 
controlled."  In other words, once part of a session, an individual 
media stream will be tied to the timeline of the session and will be 
controlled in conjunction with the rest of the streams in the session.  
So control methods such as PAUSE, PLAY would apply collectively to all 
streams within the session.  The upshot of this is that you cannot just 
PLAY or PAUSE a single media stream within a session. 

> I guess I do not understand where multiple sessions come in.

To achieve the notion of "non-aggregate control", or may be the more 
appropriate term is "independent control" the consensus was that the 
onus should be on the client to set up multiple RTSP sessions, each with 
one or more media streams and manage them in a non-aggregate fashion.  
To try to clearly specify the mechanisms of "non-aggregate" control of 
individual media streams within a single session would probably cloud 
and confuse the spec unnecessarily, since the functionality is easily 
achievable by having multiple RTSP sessions that are controlled 
independently.  If this becomes a very serious requirement, someone can 
write an extension to RTSP that describes how two independent RTSP 
sessions can be controlled in a coordinated, yet non-aggregate fashion.

> Can you enlighten me as to where I'm wrong ?

Now there is an effort underway to establish the MUTE/UNMUTE methods to 
temporarily "silence/unsilence" individual streams within a RTSP session 
as a extension to RTSP.  In this case, however, the streams would still 
be tied to the timeline of the RTSP Session, where PLAY and PAUSE on the 
session would supercede the MUTE/UNMUTE methods.

But I can see where my definitions for aggregate control and 
non-aggregate control could be a bit ambiguous, since obviously, there 
are methods such as SETUP and TEARDOWN, and even MUTE and UNMUTE that 
can work on individual media streams within a session.  I'll see if I 
can clean it up to take these methods into account.  We may just have to 
come up with more appropriate terminology.

Aravind

---

From: Bill May <[email-masked]>
Date: Fri, 11 Jul 2003 10:17:20 -0700

Aravind Narasimhan wrote:
>  Secondly, as Tom and Magnus have mentioned, a 
> URLs in a session, 

I will agree with this; however, it does not make sense for the client
to create it's own aggregate URLS where the server does not specify one
(given the SDP case).

 > but it does not make sense for the server to allow

I'm sorry, but I do not understand.

I can see a scenario where you might want to stop the video, but still maintain
the audio.  In this case, you have 2 or more streams running, and the client
wishes to stop 1 of them.  This is a perfectly legal scenario.

Another would be a fast forward application, where you pause 1 or more streams
while changing speeds on another.

Can you please expand on why it doesn't make sense to allow streams to
be controlled seperately ?  I've done most of my work on the player side with
the idea that the streams could be seperate, so most likely I'm missing
something.

> PLAY or PAUSE a single media stream within a session.

Why ?  To me, aggregate (or control of the entire session) control and
non-aggregate control (or control based on each stream) can be used
at the same time, and should be allowed.

Perhaps I do not understand the argument why control over streams
in a session is so difficult.  Can you point me to some information about
this ?

The only thing I could see is that you might want to discourage changes
to the overall timeline, ie:one stream going back 10 seconds from the
rest of the presentation.

But it would seem to me that would be an easy thing to prevent.

> one or more media streams and manage them in a non-aggregate fashion.  

That seems non-intuitive to me -keeping twice as much information as
needed.

> sessions can be controlled in a coordinated, yet non-aggregate fashion.

I guess I'm not understanding why this would be difficult.  The only
limitation would be that the timeline must be consistent across all
streams.  Otherwise, control the streams to your heart's content.

I apologize for being so dense.

> session would supercede the MUTE/UNMUTE methods.

I'm not sure that this buys you anything, if all a MUTE is is a PAUSE to
an individual streams.  It does sound like over-complicating (adding more
states and breaking backward compatibility) to avoid a couple of sentences.

> come up with more appropriate terminology.

Most likely that is why I do not understand.

Bill