Subject: RE: [MMUSIC] a=control in SDP

From: Thomas Zeng <[email-masked]>
Date: Wed, 11 Sep 2002 15:30:39 -0700

Magnus:

The extra slash does not hurt anything, does it?
Many people in 3GPP interop do use this approach (as suggested by Aaron).

Regards,
Thomas

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]]
Sent: Wednesday, September 11, 2002 12:21 AM
To: [email-masked]
Cc: IETF MMUSIC WG
Subject: Re: [MMUSIC] a=control in SDP

Hi Aaron,

Aaron wrote:

>I was under the impression that you could support this functionallity by 
>doing the following
>
>In the DESCRIBE response
>Content-Base: rtsp://example.com/donald.mp4/
>On session level:
>a=control:*   
>On media level
>a=control:trackID=2
>
>Is that not the case?
>
No, It would solve the problem at media level and that URL would resolve 
to "rtsp://example.com/donald.mp4/trackID=2" which is what I want. 
However the aggregated control URL on the session level would become 
"rtsp://example.com/donald.mp4/". And in this URL that extra slash is 
not desired.

Regards

Magnus

>
>Aaron
>
>On Tue, 10 Sep 2002, Magnus Westerlund wrote:
>
>>Hi,
>>
>>I have found a problem when using relative URLs in a=control: lines. One 
>>would like for on-demand stored files to not have to edit any of the 
>>control URLs when responding on a DESCRIBE request. This would be 
>>extremely good to have for container files like MP4 files. All media is 
>>part of the file and can be referenced within the file with just a track 
>>id. But as the relative URL scheme is defined in RFC 2396 which updates 
>>RFC 1808 referenced in the RTSP RFC, any relative URL must at least 
>>contain the filename of the container file. This results in that a SDP 
>>document delivered to a client may look like this.
>>
>>For a container file that has the URL: rtsp://example.com/donald.mp4
>>On session level:
>>a=control:*
>>On media level
>>a=control:donald.mp4/trackID=2
>>
>>Container files that stores SDPs would not like to have the filename of 
>>the file in there. Having the filename in the files creates problem when 
>>copying or renaming the file. A server may update the filename but this 
>>puts more load on the server when the goal of these container files it 
>>to put minimal load on the server and be media independent. Therefore it 
>>would be good if one could make SDP a=control lines like this:
>>
>>On session level:
>>a=control:*
>>On media level
>>a=control:*/trackID=2
>>
>>So does any see problems with extending the semantics of "*" in 
>>a=control URLs to allow the above media level usage?
>>
>>Then I have a second question. Is the use of "/" before "trackID=" the 
>>most appropriate way of referencing into a container file? Or would 
>>parameter or any other separator be better? At least "#" seems to be a 
>>bad choice as it refers to actions for the user agent (client).
>>
>>Regards
>>
>>Magnus Westerlund
>>
>>
>> From RFC 2326:
>>----------------------------------------
>>C.1.1 Control URL
>>
>>   The "a=control:" attribute is used to convey the control URL. This
>>   attribute is used both for the session and media descriptions. If
>>   used for individual media, it indicates the URL to be used for
>>   controlling that particular media stream. If found at the session
>>   level, the attribute indicates the URL for aggregate control.
>>
>>   Example:
>>     a=control:rtsp://example.com/foo
>>
>>   This attribute may contain either relative and absolute URLs,
>>   following the rules and conventions set out in RFC 1808 [25].
>>   Implementations should look for a base URL in the following order:
>>
>>   1.     The RTSP Content-Base field
>>   2.     The RTSP Content-Location field
>>   3.     The RTSP request URL
>>
>>   If this attribute contains only an asterisk (*), then the URL is
>>   treated as if it were an empty embedded URL, and thus inherits the
>>   entire base URL.
>>----------- end of quote -----------
>>
>>
>

-- 

Magnus Westerlund 

Multimedia Technologies, Ericsson Research ERA/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
_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 12 Sep 2002 09:02:44 +0200

Hi Thomas,

I think this can hurt someone. It is flawed in consistency.

The client does describe on a URL without a trailing slash. It gets a 
response that has a Content-Base URL that points to the URL with slash. 
Which results in that the aggregated control URL has trailing slash. If 
one would like to do a new describe using the aggregated control URL 
with a slash it does not work as intended. If the server would do a 
ANNOUNCE it would also be strange and inconsistent between the URLs. 
This may create worse problem when one tries to expand the protocol. If 
anyone would try to use the Content-Location header to indicate the 
base-url they would actually lie about where this SDP came from.

I think that my proposal using */ is more consistent. And consistency is 
one of the things that are important in the update of RTSP.

I guess that the 3GPP Interop your referring to is IMTC's PSS interop. I 
would be much more pleased of this group if they had the decency to 
report any found inconsistencies to MMUSIC. I would also like you to 
inform MMUSIC about your proposal to fix the bugs. I know that I is easy 
to get involved in details. But to make RTSP a useful protocol in the 
future a certain level of afterthought must be made when suggesting 
restrictions and resolutions.

Regards

Magnus

-- 

Magnus Westerlund