Subject: [MMUSIC] a=control in SDP

From: Magnus Westerlund <[email-masked]>
Date: Tue, 10 Sep 2002 12:22:41 +0200

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

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 11 Sep 2002 09:21:27 +0200

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,
>>

-- 

Magnus Westerlund

---

From: Aaron <[email-masked]>
Date: Tue, 10 Sep 2002 09:24:40 -0700 (PDT)

In the DESCRIBE response

Is that not the case?

Aaron