Subject: [MMUSIC] Relative control attributes in SDP

From: Tom Marshall <[email-masked]>
Date: Thu, 17 Oct 2002 10:07:58 -0700

I have a question regarding the proper handling of the Content-Base header
in an SDP for an RTSP presentation that is fetched via HTTP.

RFC2326 specifies the format of the "control" attribute in SDP.  It provides
for a completely relative syntax with the base url being provided in the
Content-Base and Content-Location headers.  RFC2068 (section 14.11) also has
an explanation of how these headers are to be used, which matches up nicely
with RTSP.

Suppose an SDP is downloaded via HTTP.  This could be downloaded by a
browser on behalf of a media player, for example.  The SDP has no absolute
urls and the HTTP response has a Content-Base header that provides the base
url.  How should the control attributes be handled after the SDP has been
downloaded?  Should the HTTP client use the Content-Base header and modify
the control attribute, or should the SDP be left as-is?

Example:

GET /video.sdp HTTP/1.0
Host: media.example.com

HTTP/1.0 200 OK
Content-Base: rtsp://media.example.com/video.sdp/
...

v=0
...
m=audio
a=control:trackID=0
...
m=video
a=control:trackID=1

If the SDP is passed around unmodified, there is no absolute url and it's
pretty useless to the media player.  However, if the Content-Base header is
used, the media player will see this, and it will be happy:

v=0
...
m=audio    
a=control:rtsp://media.example.com/video.sdp/trackID=0
...
m=video
a=control:rtsp://media.example.com/video.sdp/trackID=1

-- 
The intelligence of any discussion diminishes with the square of the
number of participants.
        -- Adam Walinsky

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 18 Oct 2002 09:35:42 +0200

Hi Tom,

In my opinion all SDPs received with other means than a RTSP DESCRIBE 
should have absolute control URLs. Then one avoids all these problems. 
But In your case the HTTP client has to change the SDP and create 
absolute URLs from the relative and the Content-base/Content-Location 
header. But one has to be aware that Content-Base header does not exist 
in the draft standard version of HTTP 1.1 (RFC 2616) and that is the 
header with the best semantics.

Content-Location does not only work as base URL for the entity (SDP). It 
also has the role of pointing out the location if available elsewhere. 
This should be true in most cases that the SDP can be received by an 
RTSP DESCRIBE from the Content-Location URL. But it is possible to have 
media structures that does not correspond to that and then 
Content-Location can't be used.

I don't find it reasonable that the HTTP client has to be able to parse 
SDP and update it based on the Content-Location/Content-Base header.

So it is simplest to serve SDP's for HTTP download with absolute control 
URLs.

Regards

Magnus

-- 

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: Rob Lanphier <[email-masked]>
Date: Fri, 18 Oct 2002 11:53:38 -0700 (Pacific Daylight Time)

> SDP and update it based on the Content-Location/Content-Base header.

I disagree.  It's not necessary for the actually HTTP implementation to be
that closely bound to the SDP parser.

This is a standard relative URL issue, and it's handled by HTML and SMIL
quite nicely.  I'll use SMIL as an example because it better illustrates
my point.  In many SMIL use cases, the web server hands a SMIL file to a
web browser, which lobs the file to a media player based on the MIME-type.
The media player is still capable of resolving relative URLs, because
modern browsers allow for passing the content base as a command line
parameter to a properly configured client.

So, it's not as though the HTTP client needs to actually parse SDP.  It
just needs to hand the right content base to the SDP client.

Rob

---

From: Tom Marshall <[email-masked]>
Date: Fri, 18 Oct 2002 18:17:33 -0700

> just needs to hand the right content base to the SDP client.

I imagine a practical implementation would be a system where the browser
passes the content-base and other information as metadata along with the
document.  Unfortunately, I thought about that after I sent the email.

-- 
Nothing will dispel enthusiasm like a small admission fee.
        -- Kim Hubbard

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 21 Oct 2002 09:19:45 +0200

Hi Rob,

Yes, I see that this probably works fine when you want to use the HTTP 
downloaded SDP directly. But what if you do "save to file". And later 
desires to play the session described in the file. Then it is missing 
its base-URL and the relative URLs does not work. So in that case when 
saving you would have to create the absolute URLs. This seems stupid and 
I see few reasons why the HTTP server could not be given an SDP with 
absolute URLs. I think my recommendation to use absolute URLs when 
possible is still very valid.

Regards

Magnus

-- 

Magnus Westerlund