Subject: RTSP session length bug

From: Eric Fleischman <[email-masked]>
Date: Thu, 5 Jun 1997 11:06:15 -0700

(oops. I originally sent this one to AVT rather than MMUSIC. Sorry for
the mistaken double posting)

> There is a bug in RTSP in that a session identifier is defined as
> being
> one or more octets long (see below) and is encouraged to be a very
> large
> random value in the Security section (section 15). I would therefore
> interpret this as encouraging a 4 or 8 octet session id length.
> 
> However, Section 9.11 (which deals with embedded binary data) states
> that a session identier should be solely one byte long. No mention is
> made as to how to map between session ids of multiple bytes to session
> ids of one byte. However, I think that such mapping would be
> problematic: one should consistently use the same session-identifier
> value to refer to the same session.
> 
> Therefore, I suggest that Section 9.11 be ammended to state that a one
> byte length value (giving the length of the session ID) preceeds the
> session identifier in the encapsulation approach: $ session-ID-length
> session-ID binary-data-length binary-data.
> 
> --------------------------------
> Session ID length: Section 11.26 of RTSP states that the session
> identifier has the same syntax as the conference identifier. Section
> 3.3
> states that the syntax of the conference identifier is 1*OCTET. RFC
> 2068
> section 2.1 (whose syntax is used by RTSP) states that the meaning of
> the Augmented BNF description of 1*element is "one or more instances"
> of
> element. Therefore, the session identifier must be one or more octets
> long (e.g., a 4 or an 8 byte long session identifier is legal). 
> 
> 
>

---

From: Rob Lanphier <[email-masked]>
Date: Thu, 05 Jun 1997 17:50:30 -0700

At 02:41 PM 6/5/97 -0400, Henning Schulzrinne (BL) wrote:
>A choice needs to be made if in-band TCP data (a hopefully rare
>occurrence) should be allowed only when one TCP connection represents
>one RTSP session at a time. If so, the in-band data session ID is
>unnecessary; if not, it needs to be of variable and unbounded length
>(basically, a string) and be the same as the session identifier carried
>as "Session:". Comments?

Since the rtp/tcp wasn't fully speced out, I can see why there's confusion
here.  I was presuming the interaction would go something like the following:

C->S   SETUP rtsp://foo.com/bar.file RTSP/1.0 2
       Transport: rtp/tcp;mplex=0

S->C   RTSP/1.0 200 2 OK
       Date: 05 Jun 1997 18:57:18 GMT
       Transport: rtp/tcp;mplex=0
       Session: 12345

C->S   PLAY rtsp://foo.com/bar.file RTSP/1.0 3
       Session: 12345

S->C   RTSP/1.0 200 3 OK
       Session: 12345
       Date: 05 Jun 1997 18:59:15 GMT
       
S->C   $\000{2 byte length}{"length" bytes data, w/RTP header}
S->C   $\000{2 byte length}{"length" bytes data, w/RTP header}
S->C   $\000{2 byte length}{"length" bytes data, w/RTP header}
S->C   $\000{2 byte length}{"length" bytes data, w/RTP header}

C->S   SETUP rtsp://foo.com/blech.file RTSP/1.0 4
       Transport: rtp/tcp;mplex=1

S->C   RTSP/1.0 200 4 OK
       Date: 05 Jun 1997 18:57:18 GMT
       Transport: rtp/tcp;mplex=1
       Session: 67890

C->S   PLAY rtsp://foo.com/blech.file RTSP/1.0 5
       Session: 67890

S->C   RTSP/1.0 200 5 OK
       Session: 67890
       Date: 05 Jun 1997 18:59:15 GMT
       
S->C   $\001{2 byte length}{"length" bytes data, w/RTP header}
S->C   $\000{2 byte length}{"length" bytes data, w/RTP header}
S->C   $\001{2 byte length}{"length" bytes data, w/RTP header}
S->C   $\000{2 byte length}{"length" bytes data, w/RTP header}
S->C   $\001{2 byte length}{"length" bytes data, w/RTP header}
.....

This would allow 256 streams over a single TCP connection.  Not perfect,
but in the case where you have more than 256 sessions, one could argue that
a second TCP connection is no great hardship.

There are Huffman-esque tricks that I think we can do, but I would prefer
not to bother specing them (and hence adding one more complience hoop) and
instead negotiate those via PEP if folks find it necessary (hey, a great
use for PEP!)

Rob

---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: [email-masked]
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/firewall.html
For more information on RTSP:               http://www.real.com/prognet/rt