Subject: RE: [MMUSIC] Need clarification about RTSP url opaque to client

From: "Anders Klemets" <[email-masked]>
Date: Mon, 25 Nov 2002 19:19:20 -0800

Magnus,

I don't fully agree with your reply to Olivier...

> >When we discussed this,  I mentionned a RTSP url is opaque to the
client
> >(3.2 in RFC 2326) so the client must not modify anything, and
therefore
> >send the content base exactly as it is. Yet I found an example (14.3
in RFC
> >2326) where the PLAY in aggregate control sends the following URL:
> >rtsp://foo.com/test.wav, although the Content-Base is
>"rtsp://foo.com/test.wav/" and no SDP session level "a=control"
information
> >is defined.
> >
> There is an error in this section. This media is not offered under 
> aggregated control. That you detect from the lack of session level 
> control attribute in the SDP. As it is going to be controlled with 
> non-aggregated control the media URL is going to be used in the PLAY 
> request. So the PLAY request shall contain the following URL: 
> "rtsp://foo.com/test.wav/streamid=0".

I don't believe that this interpretation of RFC 2326 is entirely
correct.  The example in section 14.3 in RFC 2326 is really meant to
illustrate how RTSP works in the case of aggregate control.  The text at
the bottom of page 68 makes this quite clear:

   "Note the different URL in the SETUP command, and then the switch
back
    to the aggregate URL in the PLAY command. This makes complete sense
    when there are multiple streams with aggregate control,"

The problem with the example is that the "a=control:*" attribute at the
session-level is missing.

> If the server offers media description that results in that the client

> resolves the session level control URL to one with a trailing slash
the 
> server must accept that URL. So the server shall not expect or require

> the "rtsp://server/xx/yy" but rather "rtsp://server/xx/yy/".

The purpose of the Content-Base header is to provide a "base" URL.  The
idea is that one may take this "base" URL and merge it with a "relative"
URL.  There are special rules for how this merge should happen.  The
rules are described in RFC 1808.  In order to follow these rules, one
must parse the URL.  It is not possible to treat the Content-Base URL as
an opaque URL.

For example, RFC 1808 says that if the base URL does NOT end with a
slash character, then the last "segment" of the base URL must be
stripped off before the relative URL can be concatenated with the base
URL.  In other words, it is necessary to parse to base URL.

I don't think it is correct to directly use the URL from the
Content-Base header in an RTSP request.  It is only a "base" URL, so it
is not guaranteed to be a completely valid URL.  

The tricky issue seems to be how to create a valid RTSP URL when the
base URL has a trailing slash and the relative URL is an empty string.
Since the client needs to be able to parse the base URL, it does not
seem unreasonable that the client should make sure that the resulting
RTSP URL does not have a trailing slash.  Of course, a tolerant server
should accept the URL even if it contains the extra trailing slash.

Anders

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 26 Nov 2002 13:08:11 +0100

Hi Anders,

See comments below:

>session-level is missing.
Okay, I agree with your interpretation of the intent of the chapter and 
what is its errors are. Sorry, I seem to have not read the entire chapter.

>should accept the URL even if it contains the extra trailing slash.
Yes, you are correct that a relative URL needs to be resolved. However I 
don't think the last case you meantion is tricky at all. The rules are 
defined for this case.

In the case of a=control:* the following from Appendix C, RFC 2326 applies:
"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."
That a empty relative URL inherits the whole base URL is also written in 
RFC 1808, see chapter 4, step 2 a. So the entire base URL is used and 
can in this case be treated without any parsing. Therefore I am of the 
opinion that the aggregated control URL for these examples shall have a 
trailing slash.

Please note that the updated RTSP specification will use the rules in 
RFC 2396 instead of RFC 1808 in regards to resolving URLs. Therefore 
some clarification on this issue is needed. In RFC 2396 the empty 
relative URL means the same document. However by clearly formulating 
rules for "a=control:*" this should not be a problem.

Regards

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]