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

From: [email-masked]
Date: Thu, 12 Sep 2002 11:17:34 +0300

Hi Magnus, all,

> In the case of downloaded SDP files or fetching SDP by HTTP, the URLs 
> must be absolute ones.
> 

Yes, exactly. I believe this is not stated in SDP or RTSP RFC or any other place, right? I hope everyone will obey this and if possible I would also like to see this text written in the RFC as a clarification. 

This also means that if a client would like to store an SDP description of an RTSP session for further usage, it has to update the SDP description to include absolute URLs.

> However as I wrote to Thomas Zeng, I would like to see a more 
> consistent 
> solution than using a extra slash. My proposal is to use * as 
> a copy the 
> base URL for this type of  relative URLs. So that track level 
> references 
> looks like "*/trackID=2". I would like to get some feedback 
> about this.

I think we have to consider the possible impact of such a change on current implementations and products which are already on the market. This approach does not have backward compatiblity with the existing RTSP/SDP implementations, right? This also means that the Content-Base can not contain structures like Thomas indicated, "Content-Base: rtsp://example.com/donald.mp4/", nor the control attribute having "a=control:trackID=2"?

BR
Emre

> -----Original Message-----
> From: ext Magnus Westerlund [mailto:[email-masked]]
> Sent: 12. September 2002 10:10
> To: Aksu Emre (NMP/Tampere)
> Cc: [email-masked]
> Subject: Re: [MMUSIC] a=control in SDP
> 
> 
> Hi Emre,
> 
> In the case of downloaded SDP files or fetching SDP by HTTP, the URLs 
> must be absolute ones.
> 
> However as I wrote to Thomas Zeng, I would like to see a more 
> consistent 
> solution than using a extra slash. My proposal is to use * as 
> a copy the 
> base URL for this type of  relative URLs. So that track level 
> references 
> looks like "*/trackID=2". I would like to get some feedback 
> about this.
> 
> Regards
> 
> Magnus
> 
> [email-masked] wrote:
> 
> >Hi all,
> >
> >>>In the DESCRIBE response
> >>>Content-Base: rtsp://example.com/donald.mp4/
> >>>On session level:
> >>>a=control:*   
> >>>On media level
> >>>a=control:trackID=2
> >>>
> >
> >Please be aware that stand alone SDP files or HTTP 
> downloaded SDP files are also possible ways of starting a 
> session, according to the use cases of 3GPP  PSS spec 
> (TS.26.234). So, you may not always be able to have a 
> Content-Base field accompanying your SDP description. The 
> solution must be defined/found inside the SDP syntax, not by 
> the help of any RTSP header I think. 
> >
> >I'd really like to see a solution to this issue, since it 
> also caused different interpretations during the 3GPP interop. tests.
> >
> >Best Regards,
> >Emre
> >
> >
> >Emre Baris Aksu
> >Senior Design Engineer
> >
> >Nokia Mobile Phones
> >Tampere / Finland
> >e-mail : [email-masked]
> >Mobile : +358 40 743 1972
> >Fax    : +358 7180 70504
> >
> >
> >
> >>-----Original Message-----
> >>From: ext Thomas Zeng [mailto:[email-masked]]
> >>Sent: 12. September 2002 1:31
> >>To: 'Magnus Westerlund'; [email-masked]
> >>Cc: IETF MMUSIC WG
> >>Subject: RE: [MMUSIC] a=control in SDP
> >>
> >>
> >>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
> >>
> >
> 
> -- 
> 
> 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: Thu, 12 Sep 2002 10:52:26 +0200

Emre,

>Yes, exactly. I believe this is not stated in SDP or RTSP RFC or any other place, right? I hope everyone will obey this and if possible I would also like to see this text written in the RFC as a cla…
Yes, a note may be appropriate for the RTSP specification. I will put it 
on my to do list.

>This also means that if a client would like to store an SDP description of an RTSP session for further usage, it has to update the SDP description to include absolute URLs.
Yes, or have some way of storing the base URL to the location. Here 
again, storing a base-URL that has a trailing slash can create problems. 
If one want's to check if the SDP is valid by doing a describe with the 
base URL it will fail.

>I think we have to consider the possible impact of such a change on current implementations and products which are already on the market. This approach does not have backward compatiblity with the e…
Yes, I am aware of that my proposal has some backwards compatibility 
issues. However as I see it these issues are with something that does 
not work properly. So the question is should we further paint our selves 
into the corner or should we try to jump over the wet paint before it 
becomes totally impossible.

Yes, if you are using "a=control:*/trackID=2" you can't have trailing 
slashes in the Content-Base URL.

Regards

Magnus

-- 

Magnus Westerlund

---

From: Gayathri Ramakrishnan <[email-masked]>
Date: Thu, 12 Sep 2002 15:03:49 +0530

Hi Magnua,

<snipped>
> slashes in the Content-Base URL.

If we need to indicate the relative uri,then  using "*/" is a good idea.
But, when we don't specify any relative filename (as say for eg:
a=control:trackID=4), can't we  mandate that in the RFC saying
that it is equivalent to an relative url of "*/".  Futher more, if we
are going to introduce the extra slash, we might need to make sure
that the "Content-Base" doesn't have the trailing slash, as u had
pointed out.

Thanks,
Gayathri

--
We pause, to soar higher
http://cdn.hcltech.com

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 12 Sep 2002 12:45:38 +0200

Hi Gayathri,

See comments below.

>that the "Content-Base" doesn't have the trailing slash, as u had
Yes, It seems to be a way forward that can solve the basic problem of 
referring within a file. A question, is "trackID" the only special word 
needed? OR do we also need to allow for any variation with upper and 
lower cases, and perhaps "_" between track and ID? I would hope that we 
can settle for a single word.

Best Regards

Magnus

-- 

Magnus Westerlund