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

From: [email-masked]
Date: Thu, 12 Sep 2002 14:06:07 +0300

Hi Magnus, Gayathi, all,

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

I think there is no restriction stating that "trackID" is the only control identifier. In fact, for my understanding, any kind of text can be present there (as long as it is complient with the <token> definition made in SDP RFC), as long as the server can differentiate between different media component choices. 
So, for example,
"a=control:thisistheaudiotrack" is as valid as "a=control:trackID=2". Because the meaning of the control text is transparent to the client. Client only uses it to differentiate between choices and does not try to interpret the meaning of it.

Can you find any RFC or document where the "trackID" is defined as a control attribute? I think it is only used in the RTSP RFC as an example purpose.

BR
Emre

> -----Original Message-----
> From: ext Magnus Westerlund [mailto:[email-masked]]
> Sent: 12. September 2002 13:46
> To: Gayathri Ramakrishnan
> Cc: [email-masked]
> Subject: Re: [MMUSIC] a=control in SDP
> 
> 
> Hi Gayathri,
> 
> See comments below.
> 
> Gayathri Ramakrishnan wrote:
> 
> >Hi Magnua,
> >
> ><snipped>
> >
> >>>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"?
> >>>
> >>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.
> >>
> >
> >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.
> >
> 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
> 
> >
> >Thanks,
> >Gayathri
> >
> >--
> >We pause, to soar higher
> >http://cdn.hcltech.com
> >
> >
> >
> >>Regards
> >>
> >>Magnus
> >>
> >>>>-----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]
> >>>>
> >>>>
> >>>>
> >>>>
> >>--
> >>
> >>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
> >>
> >
> 
> -- 
> 
> 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 13:47:43 +0200

Emre,

>Can you find any RFC or document where the "trackID" is defined as a control attribute? I think it is only used in the RTSP RFC as an example purpose.
You are correct that any sequence in accordance with <token> can be 
used. However this is an implementation issue. What does the content 
creation tools out in the world write into the SDPs. Also what does the 
servers out there understand so it can open its hint track readers. Does 
all understand trackID? Or are there some other string that has been 
commonly used? I hope that it can be enough with "trackID".

Best Regards

Magnus Westerlund

---

From: Gayathri Ramakrishnan <[email-masked]>
Date: Thu, 12 Sep 2002 17:43:39 +0530

Hi ,

Inline ..

> commonly used? I hope that it can be enough with "trackID".

Lets just add the token "trackId" for the time being. When anyother such
token comes up, we can append the information to the syntax....Like say

trackID | token 1 | token 2 etc....

Thanks,
Gayathri

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

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 13 Sep 2002 08:58:28 +0200

Hi Aaron,

Aaron wrote:

>Hi all,
>
>I think it would be a mistake to latch onto the trackID as a keyword. I 
>know of at least family of servers that do not always use that string 
>for control fields, the RealServer. I think the current semantics of treating 
>the control field as a relative URL is the best solution because it 
>provides a well defined way to construct the control URLs without 
>expecting anything about the contents or format of the string. I do agree 
>with Magnus' concern that the Content-Base method that I mentioned is not 
>the best way to handle the problem he raised. It is just how I've seen 
>the situation handled in practice. 
>
Yes, I was rather certain that there would be more words than "trackID" 
in use out there. So having a lot of special cases is not good as you 
point out.

>
>I think we should use a slightly modified or more general form of Magnus' 
>proposal. Basically make it '*/<relative URL>'. This allows you to have 
>the same flexibility that we have now, but it also addresses Magnus' 
>concern. What does this form indicate? If the media level control 
>URL starts with '*/' it means that you will add a '/' to the base URL, if 
>it doesn't already end with one, and then apply the relative URL that 
>follows the '*/' sequence. When I say "base URL' I am talking about 
>whatever URL you would have applied the relative URL to in the first 
>place.
>
Yes, my intention was that "*/" would be a general case that worked with 
any URL string. My original thoughts was basically to make "*" a 
reserved word in a=control URLs that means replace me with the base url. 
One basic restriction could that it is only allowed in the beginning of 
the string.

>
>I think adding this behaviour to existing implementations would be trivial
>and adoption of this would require minimal effort. Using this form
>still creates compatibility problems for the client though. Adding logic 
>to handle both interpretations could be tricky. I don't know of any 
>servers that currently put '*/' in their media level control fields so it 
>may not be worth the effort to support backwards compatability in that 
>situation.
>
If I have understood you correctly, you are in favor of  having the 
following rules in regards to a=control URLs.
1. All rules in RFC 2396 applies.
2. A "*" in the beginning of a relative URL means that this "*" shall be 
replaced by the complete base URL.
3. If  the concatenation of the base URL and the relative URL results in 
that two slashes are next to each other at the point of concatenation, 
remove one.

Rule 2 allows for having only * at session level, and to have */trackID 
constructs at media level. This works fine with server and clients that 
are in accordance with rule 1 and 2. Old servers that do the 
Content-Base URL with an extra slash will be handled by rule 3.

I don't understand how this would be very tricky to implement. It would 
still have the problem that old clients would not understand new media 
with media level urls with *<somthing more>. But as PC based clients are 
rather often updated it is a minor problem. However it is important that 
this gets into PSS clients as they will probably have a much longer life 
span. 

I like this, having a simple extra rule that only helps backwards 
compatibility seems fine with me. This I see is much better than 
creating other reserved words.

Regards

Magnus Westerlund

---

From: Aaron <[email-masked]>
Date: Thu, 12 Sep 2002 09:27:09 -0700 (PDT)

Hi all,

Aaron