Subject: [MMUSIC] Relative URLs in RTP-Info field

From: Aaron Colwell <[email-masked]>
Date: Thu, 20 Feb 2003 09:54:27 -0800 (PST)

Hi,

In some inter-op testing that I've done, I've discovered an ambiguous
situation related to SDP initiated playback and relative URLs in the PLAY
response.

Say I have the following SDP
v=0
a=control:rtsp://foo.com/blah.3gp
m=audio 0 RTP/AVP 96
a=control:rtsp://foo.com/blah.3gp/trackID=1
a=rtpmap:96 MP4A-LATM/44100
a=range:npt=0-37
m=video 0 RTP/AVP 97
a=control:rtsp://foo.com/blah.3gp/trackID=2
a=rtpmap:97 MP4V-ES/90000

The RTSP chat sequence looks something like
OPTIONS rtsp://foo.com
SETUP rtsp://foo.com/blah.3gp/trackID=1
SETUP response
SETUP rtsp://foo.com/blah.3gp/trackID=2
SETUP response
PLAY rtsp://foo.com/blah.3gp
PLAY response
 RTP-Info: url=trackID=1;seq=0;rtptime=0,url=trackID=2;seq=2234;rtptime=93875

Notice that the URLs in the RTP-Info field are relative. In this case, I
don't have a base URL to apply the relative URLs to. This is because I did
not issue a DESCRIBE and therefore did not get a Content-Base or
Content-Location field from a DESCRIBE response.

What is the proper thing to do in this case? Since I don't have a base URL
to apply the relative URLs to, I can't figure out which SETUP URL the
RTP-Info is referring to. In this particular example I would be able to
figure it out by applying the relative URLs to each SETUP URL and then see
if the resulting URL matches the original URL. That solution won't work
for all cases though. Here is an example of where that won't work.

You have an SDP that looks like..
v=0
a=control:rtsp://foo.com/movie
m=audio 0 RTP/AVP 96
a=control:rtsp://foo.com/audio.3gp/trackID=1
a=rtpmap:96 MP4A-LATM/44100
a=range:npt=0-37
m=video 0 RTP/AVP 97
a=control:rtsp://foo.com/video.3gp/trackID=1
a=rtpmap:97 MP4V-ES/90000

The RTSP chat for this situation would look like
OPTIONS rtsp://foo.com
SETUP rtsp://foo.com/audio.3gp/trackID=1
SETUP response
SETUP rtsp://foo.com/video.3gp/trackID=1
SETUP response
PLAY rtsp://foo.com/movie
PLAY response
 RTP-Info: url=trackID=1;seq=0;rtptime=0,url=trackID=1;seq=234;rtptime=23487

In this case I have no way to figure out what info is associated with
which stream.

I think part of the problem here is that the server is assuming that the
client knows what the base URL is. In the case of an SDP initiated
playback, I don't have one. To my knowledge there is no way that the
server can detect whether I have a base URL or not. I suppose it could
check to see if I issued a DESCRIBE or not, but that seems a little messy
to me.

I propose that the RTP-Info field should contain the SETUP URLs exactly
the way that they were given to the server in the SETUP. This allows the
client an easy way to figure out what URLs are associated with which
streams. Relative URLs should not be allowed since it is ambiguous as to
what they are relative to.

I'm open to any questions or comments.

Aaron

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

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 21 Feb 2003 11:27:28 +0100

Hi Aaron,

I will try to provide answers to your questions.

>Content-Location field from a DESCRIBE response.

The relative URLs are having the base URL of the Request URL. It might 
not be very clear about how to derive the base URL for the RTP-info 
header. It is something we need to clarify in the updated RTSP spec. 
However the base URL rules that are defined for SDP base URL says that 
the request URL should be used if not Content-Base or Content-Location 
is defined in the response. So in the above case they are actually 
erroneous. The RTP info header should have the following look:

 RTP-Info: url=blah.3gp/trackID=1;seq=0;rtptime=0,url=blah.3gp/trackID=2;seq=2234;rtptime=93875

>for all cases though. Here is an example of where that won't work.

As said before the relative URLs uses the Request URL as base, i.e. the 
PLAY request for the RTP-Info header. Please also note that normal URL 
handling rules apply, e.g. the last path segment at the end of the URL 
is removed.

>In this case I have no way to figure out what info is associated with

Yes, you have. By using the PLAY request's URL as base the RTP-Info URLs 
would be:

RTP-Info: url=audio.3gp/trackID=1;seq=0;rtptime=0, url=video.3gp/trackID=1;seq=234;rtptime=23487

>check to see if I issued a DESCRIBE or not, but that seems a little messy

There must always be clear what is the base-URL. For RTSP request you 
can't use base-urls that are remembered each request - response pair 
must be self contained in this regard.

>what they are relative to.

For RTP-Info you either use relative URLs to the request URL or use 
absolute ones. Unless anyone argues against it I will add the following 
sentence to the RTP-Info URL description to clarify this: "Any relative 
URL SHALL use the request URL as base URL."

Best 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]

---

From: Tom Marshall <[email-masked]>
Date: Fri, 21 Feb 2003 09:07:06 -0800

> RTP-Info: url=audio.3gp/trackID=1;seq=0;rtptime=0, 
> url=video.3gp/trackID=1;seq=234;rtptime=23487

You are making an assumption about the ordering here -- that the first url=
corresponds to the first SETUP.  Is that required?

-- 
Most people are too busy to have time for anything important.

---

From: Aaron Colwell <[email-masked]>
Date: Fri, 21 Feb 2003 09:43:13 -0800 (PST)

Thank you for the clarification. I was somewhat expecting that answer, but
I just wanted to make sure.

One other thing that I'd like to have clarified is that if absolute URLs
are returned that they match what was sent in the SETUP request for that
stream. I've run into a case where a server will return me an IP address
in the hostname part of the URL instead of the hostname that I specified.
It is things like this that make matching SETUP URLs with RTP-Info
information not very easy. I'd like to not have to use heuristic methods
for dealing with these types of situations. Perhaps the clarification for
RTP-Info URLs should be something like

"Any relative URL SHALL use the request URL as base URL. The resulting
 URL must match the URL used to SETUP that stream. If an absolute URL is
 specified, it MUST match the URL used to SETUP that stream."

I'm sure this could be worded a little better and put into proper
RFC-speak.

Thanks,
Aaron

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 21 Feb 2003 19:22:13 +0100

Hi Aaron,

>I'm sure this could be worded a little better and put into proper
Yes, this sounds reasonable. The sever should really reference the media 
resource that it has setup, not something else. However I have not have 
time to look up what RFC 2396 says about matching a URI.

Cheers

Magnus Westerlund

---

From: Tom Marshall <[email-masked]>
Date: Fri, 21 Feb 2003 12:01:21 -0800

> url=video.3gp/trackID=1;seq=234;rtptime=23487

Based on the RTSP spec and a few private emails, I think the correct answer
here is that the server is in error (is this what you meant to say, Magnus?)
When the client combines the relative urls in RTP-Info with the absolute url
in the request using the rules in RFC1808, the result is this for both
streams:

  rtsp://foo.com/movie + trackID=1 -> rtsp://foo.com/trackID=1

If the server wished to use relative urls in the RTP-Info header, the proper
response would be one of the following:

A completely relative response would be this:

Note that if the stream urls were in a different path from the aggregate
url, the response would contain one or more ../ sequences.

An absolute path without any host would also work:

  RTP-Info: url=/audio.3gp/trackID=1;seq=0;rtptime=0,
            url=/video.3gp/trackID=1;seq=234;rtptime=23487

-- 
Innovate, v.:
        To annoy people.

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 21 Feb 2003 21:08:04 +0100

>here is that the server is in error (is this what you meant to say,
Yes, you are correct.

Cheers 

Magnus Westerlund