Subject: [MMUSIC] RTSP: Media Properties and aggregated sessions

From: Magnus Westerlund <[email-masked]>
Date: Mon, 03 Nov 2008 13:31:27 +0100

Hi,

I have received some private feedback from people active in 3GPP. They
wonder about if there is any point at all in having this be per media
instead of rather per session. I have spent some time thinking about
this and this is my arguments.

A RTSP session either contains a single media or is an aggregated
session with two or more media. In the first case the control of the
session equals control of the media. In the aggregated case the control
is done on all the media together, thus only the common properties are
what can be addressed. In case the the media in a aggregated session
have different properties there is still a need for the server to
determine what the resulting set of properties becomes for the
aggregate. If the media's properties aren't possible to combine, then
the aggregation should anyway be turned down.

Based on this reasoning there is a simple but necessary clarification
needed for the applicability of the media-properties header. I suggest
that the 2 first pargraphs in Section 16.29 (Media-Properties) is
modified to the following:

This general header is used in SETUP response or PLAY_NOTIFY requests to
indicate the media's properties that currently are applicable to the
RTSP session. PLAY_NOTIFY MAY be used to modify these properties at any
point. However, the client MUST have received the update prior to any
action related to the new media properties take affect. For aggregated
sessions the Media-Properties header will be returned in each SETUP
response and the one that applies is the response to the last request.

The media properties expressed by this header is the one applicable to
all media in the RTSP session. So for aggregated sessions the header
expressed the combined media-properties. As a result aggregation of
media MAY result in a change of the media properties, and thus the
content of the Media-Properties header contained in subsequent SETUP
responses.

The header contains a list of property values that are applicable to the
currently setup media or aggregate of media as indicated by the RTSP URI
in the request. No ordering are enforced within the header. Property
values should be grouped into a single group that handles a particular
orthogonal property. Values or groups that express multiple properties
SHOULD NOT be used. The list of properties that can be expressed MAY be
extended at any time. Unknown property values SHALL be ignored.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Färögatan 6                | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 28 Nov 2008 16:45:31 +0100

Jaehwan Kim skrev:

> I don't understand the last sentence starting with "the one that..".
> Does it mean "only the last response shall be considered for 
> aggregated session, as a combined property"?

Yes, I mean the only the last one is the one that applies on the whole
session from this point forward. Reworded last sentence to:

For aggregated sessions the Media-Properties header will be returned in
each SETUP response. The header received in the latest response is the
one that applies on the whole session from this point until any future
update.

Better?

> 
>> The header contains a list of property values that are applicable to 
>> the currently setup media or aggregate of media as indicated by the 
>> RTSP URI in the request. No ordering are enforced within the header.
>> Property values should be grouped into a single group that handles 
>> a particular orthogonal property. Values or groups that express 
>> multiple properties SHOULD NOT be used. The list of properties that 
>> can be expressed MAY be extended at any time. Unknown property values 
>> SHALL be ignored.
> (snip)
> 
> Connotation is clear here. 
> But I would like to see the actual example if any. 
> I found it only from page 61, page 76 and some 3gpp contributions.
> It would be nice if we have an aggregated case for this.

The examples hasn't been properly updated. It is requires in all SETUP
responses so it needs to be added in a number of cases and I think that
will make it clearer. I am working on this.

> 
> BTW, IMO, the following description after the above looks redundant 
> because we have description in section 1.5.  Media Properties, don't we?
> 
> Regards,
> Jaehwan
> p.s. maybe the following would be the example of aggregated case.
> C->S: SETUP rtsp://example.com/foo/bar/baz.3gp/TrackID=101 RTSP/2.0
>            CSeq: 302
>            Transport: RTP/AVP;unicast;dest_addr="192.0.2.53:4588"/
> 		"192.0.2.53:4589"
> 	   Accept-Ranges: NPT, UTC
>            User-Agent: PhonyClient/1.2
> 
>      S->C: RTSP/2.0 200 OK
>            CSeq: 302
>            Date: Thu, 23 Jan 1997 15:35:06 GMT
>            Server: PhonyServer 1.1
>            Session: 47112344;timeout=30
>            Transport: RTP/AVP;unicast;dest_addr="192.0.2.53:4588"/
>                       "192.0.2.53:4589"; src_addr="192.0.2.241:6256"/
>                       "192.0.2.241:6257"; ssrc=2A3F93ED
>            Accept-Ranges: NPT
>            Media-Properties: Random-Access=3.2, Time-Progressing,
>                              Time-Duration=3600.0
> 	   Media-Range: npt=0-2893.23
> 
> C->S: SETUP rtsp://example.com/foo/bar/baz.3gp/TrackID=201 RTSP/2.0
>            CSeq: 303
> 	   Session: 47112344
> 	   Transport: RTP/AVP;unicast;dest_addr="192.0.2.53:4590"/
> 		"192.0.2.53:4591"
>            Accept-Ranges: NPT, UTC
>            User-Agent: PhonyClient/1.2
> 
>      S->C: RTSP/2.0 200 OK
>            CSeq: 303
>            Date: Thu, 23 Jan 1997 15:35:07 GMT
>            Server: PhonyServer 1.1
>            Session: 47112344;timeout=30
>            Transport: RTP/AVP;unicast;dest_addr="192.0.2.53:4590"/
>                       "192.0.2.53:4591"; src_addr="192.0.2.241:6258"/
>                       "192.0.2.241:6259"; ssrc=1A3093E0
>            Accept-Ranges: NPT
>            Media-Properties: Random-Access=0.2, Time-Progressing,
>                              Time-Duration=3600.0
> 	   Media-Range: npt=0-2893.23
> 

This is a bad example I think. If the two SETUPs switched place then the
Random-Access values would make more sense. Going from a Maximum of 0.2
seconds to 3.2 s makes sense as you add media.

> C->S: SETUP rtsp://example.com/foo/bar/baz.3gp/TrackID=301 RTSP/2.0
>            CSeq: 304
> 	   Session: 47112344
> 	   Transport: RTP/AVP;unicast;dest_addr="192.0.2.53:4592"/
> 		"192.0.2.53:4593"
>            Accept-Ranges: NPT, UTC
>            User-Agent: PhonyClient/1.2
> 
>      S->C: RTSP/2.0 200 OK
>            CSeq: 304
>            Date: Thu, 23 Jan 1997 15:35:07 GMT
>            Server: PhonyServer 1.1
>            Session: 47112344;timeout=30
>            Transport: RTP/AVP;unicast;dest_addr="192.0.2.53:4592"/
>                       "192.0.2.53:4593"; src_addr="192.0.2.241:6260"/
>                       "192.0.2.241:6261"; ssrc=2F003788
>            Accept-Ranges: NPT
>            Media-Properties: Begining-Only, Time-Progressing,
>                              Time-Duration=3600.0
> 	   Media-Range: npt=0-2893.23
> 
> So, I guess the aggregated session will allow Random Access only at
> beginning from this example. Correct?
> 

Yes, this would then be restricted to Begining-Only. But Begining-Only
is also very a bit strange for a Time-Progressing media, especially one
with Time-Duration, i.e. moving window.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
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]
----------------------------------------------------------------------
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic