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

From: [email-masked]
Date: Thu, 21 Nov 2002 14:41:27 +0100

Hi all,

I know there has recently been lots of posts about urls. Unfortunately I
haven't had time to go thru the archive, so I'd like to apologize if my
questions were already asked...

We've recently had an unconclusioned discussion on the IMTC mailing list
about the aggregate control url to be used in a PLAY: in the context we had
to use the Content-Base as the aggregate control url. It looked like
"rtsp://server/xx/yy/" (the "/" at the end is the key). When PLAYing, our
UA sends the aggregate url without modification ("rtsp://server/xx/yy/")
but the server expects "rtsp://server/xx/yy" (the last "/" stripped away).

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.

So (finally), my question is how should we interpret RTSP urls being
"opaque" to a client ??
My interpretation is that a client/UA must not manipulate the URL, like
adding or zapping "/", stripping away query or fragment components. The
only allowed manipulations are (as far as I know):
  - resolution, because it is clear where, when & how it can take place
- subsitution in the network address part (e.g. default port...)
- transport protocol to use for the RTSP channel, based on the scheme

Do you have other interpretations, is this one OK ??  Does RFC 2326::14.3
example needs clarification ??

Thanks for your feedback,

Olivier

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

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 21 Nov 2002 17:15:36 +0100

Hi Olivier,

I will try to give you some answers.

>but the server expects "rtsp://server/xx/yy" (the last "/" stripped away).

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

>"rtsp://foo.com/test.wav/" and no SDP session level "a=control" information
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".

As a general note most of the example in RFC 2326 are in fact in error. 
They are missing headers they should contain, URLs are wrong, etc.

>example needs clarification ??
Yes, I agree with your summary.

All examples in the RTSP draft will be revised as soon as we have 
resolved the major part of the open issues. However so far no effort has 
been performed in the draft-ietf-mmusic-rfc2326bis-02.txt to correct the 
examples.

Best Regards

Magnus