Subject: [MMUSIC] rtsp describe and containers

From: Markus Buchhorn <[email-masked]>
Date: Wed, 11 Jan 2006 12:29:03 +1100

Hi all

First off, Happy New Year to all! [who celebrate the Julian calendar] 

I have a quick couple of questions about the rtsp (v1) spec, and the v2 rfc2326bis draft as well. 

The ability to control 'container' files doesn't appear to be described consistently. The example in 11.2 (2326bis; 10.2 in rfc2326) for DESCRIBE has an SDP showing multiple media (m=) streams, but no control information per stream. Yet the examples in 17.1/17.2 (2326bis; 14.1/14.2 in rfc2326) have individual control information per m= line. Is there a mechanism for handling container'ed materials that uses the SDP description as the DESCRIBE examples show, or should the example SDP in 10.2/11.2 be like the examples in 14.1-2/17.1-2? :-) 

Also, there is the use of a 'streamid' in several rfc2326 examples, and both 'streamid' and 'trackid' are used in rfc2326bis. streamid is never explained in either document, and it appears that trackid takes on its role in 2326bis? Trackid doesn't have any introduction in the latter, is only covered briefly in C.1.1 under URI handling, and is very late in the document :-) A sentence or two specifically on it up earlier could be helpful to implementors...

I presume 'trackid' (to replace 'streamid'?) is a new standard for rtsp-v2 clients as well then? In which case should streamid go away from 2326bis/rtsp-v2?

Thanks for any advice/comments! We're trying to code up a small rtsp (v1 for now) server and the various clients ain't totally happy :-) Seems like too many differing examples to choose from just caused us some confusion.

Cheers,
	Markus

Markus Buchhorn, ANU Internet Futures             |Ph: +61 2 61258810
[email-masked]                        |Fx: +61 2 61259805
The Australian National University, Canberra 0200 |Mob: 0417 281429

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

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 11 Jan 2006 11:58:40 +0100

Hi Markus,

> The ability to control 'container' files doesn't appear to be described consistently. The example in 11.2 (2326bis; 10.2 in rfc2326) for DESCRIBE has an SDP showing multiple media (m=) streams, but…

The example in 11.2 is not a container file example, it is an multicast 
example.

> Also, there is the use of a 'streamid' in several rfc2326 examples, and both 'streamid' and 'trackid' are used in rfc2326bis. streamid is never explained in either document, and it appears that tra…

The issue here is that there are no standard for this. These are merely 
examples. If you look in section 3.2:

"The syntax of any URI query string is unspecified and responder
    (usually the server) specific. As it is from the requestor an opaque
    string, it needs to be handled as such."

Thus, RTSP does not at all specify any URI structure for container 
files. If a container file think it necessary to have a common structure 
then it should define that.

> I presume 'trackid' (to replace 'streamid'?) is a new standard for rtsp-v2 clients as well then? In which case should streamid go away from 2326bis/rtsp-v2?

This is an example. We probably should clarify this.

> Thanks for any advice/comments! We're trying to code up a small rtsp (v1 for now) server and the various clients ain't totally happy :-) Seems like too many differing examples to choose from just c…

The issue is that RTSPv1 isn't possible to get fully interoperable from 
the specification. One needs to know the common core that people 
support. And I think a lot of commercial servers uses If User-Agent = 
"client X" then ...

Please remember also to implement from the specification text, not the 
examples.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]