Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #51 - 11 msgs

From: [email-masked]
Date: Wed, 30 Oct 2002 01:56:02 -0800

This is an automatic digest of bugs submitted and changed on the RTSP bug tracker.  To see a list of bugs, visit:

http://sf.net/projects/rtspspec

When replying, please make your Subject line more specific than "Re: Rtspspec-bugs digest"

Today's Topics:

   1. [ rtspspec-Bugs-630920 ] RTP-Info does not support multiple SSRC ([email-masked])
   2. [ rtspspec-Bugs-453258 ] Inconsistency with range in Pause ([email-masked])
   3. [ rtspspec-Bugs-464462 ] Content-Length header wrong in examples ([email-masked])
   4. [ rtspspec-Bugs-477400 ] Play without range while playing ([email-masked])
   5. [ rtspspec-Bugs-477404 ] Errors in table in chapter 12 ([email-masked])
   6. [ rtspspec-Bugs-477407 ] Transport BNF, ; and unclearities ([email-masked])
   7. [ rtspspec-Bugs-477413 ] Transport BNF: mode ([email-masked])
   8. [ rtspspec-Bugs-477416 ] BNF error section 3.6 NPT ([email-masked])
   9. [ rtspspec-Bugs-477421 ] When to send response ([email-masked])
  10. [ rtspspec-Bugs-477424 ] How to queue timed plays? ([email-masked])
  11. [ rtspspec-Bugs-477427 ] Transport model requirements ([email-masked])

--__--__--

Message: 1
To: [email-masked]
From: [email-masked]
Date: Tue, 29 Oct 2002 23:44:50 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-630920 ] RTP-Info does not support multiple SSRC

Bugs item #630920, was opened at 2002-10-30 08:44
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=630920&group_id=23194

Category: General
Group: Fix for DS - Need WG Input
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Rob Lanphier (robla)
Summary: RTP-Info does not support multiple SSRC

Initial Comment:
The RTP-Info header can't be used to synchronize
multiple RTP flows using different SSRC as a single
media stream. As each SSRC has its own RTP sequence and
timestamp space to allow synchronization it needs to be
possible to give these values for each SSRC in the
media stream. 

This bug has connection with bug# 625352.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=630920&group_id=23194

--__--__--

Message: 2
To: [email-masked]
From: [email-masked]
Date: Wed, 30 Oct 2002 01:00:22 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-453258 ] Inconsistency with range in Pause

Bugs item #453258, was opened at 2001-08-20 11:22
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=453258&group_id=23194

Category: None
Group: Fix for DS - Typo/Thinko
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Rob Lanphier (robla)
Summary: Inconsistency with range in Pause

Initial Comment:
Page 36, Pause method

Second paragraph states that any pause method 
containing a pause point not present in any pending 
play should be returned with error 457 Invalid range. 

Last paragraph on page contains an example with a 
pause with an illegal pause point. Plays for 10-15 and 
20-29. Then a pause for 16 is requested and it is 
stated it should stop after play segement 10-15 and 
remove the 20-29 play request. Should this pause 
request not result in a 457 error?   

----------------------------------------------------------------------

>Comment By: Magnus Westerlund (magwes)
Date: 2002-10-30 10:00

Message:
Logged In: YES 
user_id=302620

Fixed and checked in CVS.

----------------------------------------------------------------------

Comment By: Rob Lanphier (robla)
Date: 2002-01-25 01:28

Message:
Logged In: YES 
user_id=3796

I'll edit this one after we resolve #508211

----------------------------------------------------------------------

Comment By: Rob Lanphier (robla)
Date: 2001-12-13 18:01

Message:
Logged In: YES 
user_id=3796

Agreed.  This is an error in the spec that just needs to be fixed.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=453258&group_id=23194

--__--__--

Message: 3
To: [email-masked]
From: [email-masked]
Date: Wed, 30 Oct 2002 01:02:07 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-464462 ] Content-Length header wrong in examples

Bugs item #464462, was opened at 2001-09-24 18:09
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=464462&group_id=23194

Category: General
Group: Fix for DS - Typo/Thinko
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Rob Lanphier (robla)
Summary: Content-Length header wrong in examples

Initial Comment:
In most of the examples the Content-Length header is not the right value for the actual content of the header.

like the one below,which I copied from RTSP 14.5, this number doeas not match: In this case here they write "44", but if you count (together with CRLF, or even just LF) 103 chars + 8 for CRLF or 4 for just LF.

M-C: 
RTSP/1.0 200 1 OK 
Content-type: application/sdp 
Content-Length: 44 

v=0 
o=- 2890844526 2890842807 IN IP4 192.16.24.202 
s=RTSP Session i=See above t=0 0
m=audio 0 RTP/AVP 0 

C-M: 
SETUP rtsp://server.example.com/demo/548/sound RTSP/1.0 CSeq: 2 
Transport: RTP/AVP;multicast;destination=225.219.201
..............................

----------------------------------------------------------------------

>Comment By: Magnus Westerlund (magwes)
Date: 2002-10-30 10:02

Message:
Logged In: YES 
user_id=302620

These must be fixed in all examples as soon as the updates
becomes more stable. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=464462&group_id=23194

--__--__--

Message: 4
To: [email-masked]
From: [email-masked]
Date: Wed, 30 Oct 2002 01:25:49 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-477400 ] Play without range while playing

Bugs item #477400, was opened at 2001-11-02 08:15
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=477400&group_id=23194

Category: General
Group: Fixed in CVS/Need WG Approval
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Rob Lanphier (robla)
Summary: Play without range while playing

Initial Comment:
A PLAY request without a Range header is legal. It starts playing a
stream from the beginning unless the stream has been paused. If a
stream has been paused via PAUSE, stream delivery resumes at the
pause point. If a stream is playing, such a PLAY request causes no
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
further action and can be used by the client to test server liveness.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

In a response to play without range while playing, what shall the server
do with RTP-Info? The RTP-Info is required according to table in the
beginning of chapter 12, but my opinion is that it lacks meaning in this
case.

----------------------------------------------------------------------

>Comment By: Magnus Westerlund (magwes)
Date: 2002-10-30 10:25

Message:
Logged In: YES 
user_id=302620

Further the use of PLAY for keep-alive is decapitaited. A
455 response will be received when used.

----------------------------------------------------------------------

Comment By: Rob Lanphier (robla)
Date: 2002-05-24 20:01

Message:
Logged In: YES 
user_id=3796

Added PING method:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/rtspspec/methods.tex.diff?r1=1.3&r2=1.4

----------------------------------------------------------------------

Comment By: Rob Lanphier (robla)
Date: 2001-12-13 18:49

Message:
Logged In: YES 
user_id=3796

We should deprecate this use of PLAY, and add a PING method (so that we can explicitly ensure there are 
no side effects)  The nice thing about PING is that we can define it as bidirectional.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=477400&group_id=23194

--__--__--

Message: 5
To: [email-masked]
From: [email-masked]
Date: Wed, 30 Oct 2002 01:28:16 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-477404 ] Errors in table in chapter 12

Bugs item #477404, was opened at 2001-11-02 08:22
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=477404&group_id=23194

Category: None
Group: Fix for DS - Large task
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Magnus Westerlund (magwes)
Summary: Errors in table in chapter 12

Initial Comment:
 Table with RTSP headers page 45, contains the following errors?:
  - A session header is not required when using describe.
  - Proxy Authenticate is missing all values on what it is.
  - The transport header is specifed as required in 12.0 table, but
    the text in 12.39 says it MAY be included in requests and responses.

----------------------------------------------------------------------

>Comment By: Magnus Westerlund (magwes)
Date: 2002-10-30 10:28

Message:
Logged In: YES 
user_id=302620

The table has been split to fit the pages. 

As this has been present in the draft past at least one
publication and no comments has been received that this was
a wrong move this issue is closed. Further errors in the
table needs to be logged as new bugs.

----------------------------------------------------------------------

Comment By: Magnus Westerlund (magwes)
Date: 2002-09-18 17:24

Message:
Logged In: YES 
user_id=302620

The table needs to formated so it fits the pages.

----------------------------------------------------------------------

Comment By: Magnus Westerlund (magwes)
Date: 2002-06-07 16:29

Message:
Logged In: YES 
user_id=302620

The table is update using the same structure as the new SIP
draft. This is available in CVS. There are still some
uncertainties in the table. So please review the table and
give comments.

----------------------------------------------------------------------

Comment By: Magnus Westerlund (magwes)
Date: 2002-02-06 14:20

Message:
Logged In: YES 
user_id=302620

The table is also missing the location header. 

----------------------------------------------------------------------

Comment By: David W. Walker (davidwwalker)
Date: 2002-01-28 23:41

Message:
Logged In: YES 
user_id=437905

RESOLUTION:  

The latest SIP draft has an equivalent table. It has been  
recommended that we evaluate this SIP table and unless 
someone objects and justifies the need to make a change 
let's adopt the SIP draft specification version. 

----------------------------------------------------------------------

Comment By: Rob Lanphier (robla)
Date: 2002-01-23 04:47

Message:
Logged In: YES 
user_id=3796

Here's a discrepency between the initial CVS checkin and RFC 2326
  12  Header Field Definitions (Table 3):
   Change from:
   Content-Type         r      req.      entity
   To:
   Content-Type        e    req.   SET_PARAMETER, ANNOUNCE

----------------------------------------------------------------------

Comment By: Rob Lanphier (robla)
Date: 2001-12-13 18:53

Message:
Logged In: YES 
user_id=3796

These are all good examples of what's wrong with this table.  We need to do an audit of the table, and we 
may restructure this table for clarity.  Suggestions for a new table format would be appreciated.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=477404&group_id=23194

--__--__--

Message: 6
To: [email-masked]
From: [email-masked]
Date: Wed, 30 Oct 2002 01:33:28 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-477407 ] Transport BNF, ; and unclearities

Bugs item #477407, was opened at 2001-11-02 08:26
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=477407&group_id=23194

Category: None
Group: Fixed in CVS/Need WG Approval
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Transport BNF, ; and unclearities

Initial Comment:
Page 61, Transport BNF: Should not multicast/unicast be proceeded by a ";"? Is multiple entries of 
the same type allowed? Are there any requirement on having multicast/unicast first?

----------------------------------------------------------------------

>Comment By: Magnus Westerlund (magwes)
Date: 2002-10-30 10:33

Message:
Logged In: YES 
user_id=302620

Fixed, checked in and published in 01 version. No comments.
Issue closed

----------------------------------------------------------------------

Comment By: Rob Lanphier (robla)
Date: 2002-02-22 01:44

Message:
Logged In: YES 
user_id=3796

Language inserted:
"A transport-spec transport option may only contain one of
any given parameter within it.  Parameters may be given in
any order.  Additionally, it may only contain the unicast or
multicast transport parameter."

Example has been fleshed out as follows:

"Below is a usage example, showing a client advertising the
capability to handle multicast or unicast, preferring
multicast.  Since this is a unicast-only stream, the server
responds with the proper transport parameters for unicast.

  C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.0
        CSeq: 302
        Transport: RTP/AVP;multicast;mode="PLAY",
           RTP/AVP;unicast;client_port=3456-3457;mode="PLAY"

  S->C: RTSP/1.0 200 OK
        CSeq: 302
        Date: 23 Jan 1997 15:35:06 GMT
        Session: 47112344
        Transport: RTP/AVP;unicast;client_port=3456-3457;
            server_port=6256-6257;mode="PLAY"

----------------------------------------------------------------------

Comment By: David W. Walker (davidwwalker)
Date: 2002-01-29 01:46

Message:
Logged In: YES 
user_id=437905

RESOLUTION:

BNF will require semicolon, no mandated ordering, and 
example will be added.

Question was raised if multiple entries of the same type 
should be allowed?  This question was referred to a new 
issue.

Question was raied if interleave parameters should require 
paramters?  This question was referred to a new issue.

----------------------------------------------------------------------

Comment By: Henning Schulzrinne (hgschulz)
Date: 2002-01-09 18:59

Message:
Logged In: YES 
user_id=115926

BNF will be fixed to have semicolon. Ordering doesn't
matter. Say before header section that parameter order
doesn't matter. Also state that parameters can't be
replicated (;port=1;port=2) within the same header instance.

----------------------------------------------------------------------

Comment By: Rob Lanphier (robla)
Date: 2001-12-14 04:34

Message:
Logged In: YES 
user_id=3796

Agreed it needs fix.  We'll need to sort out the right BNF for this, in such a way that it doesn't break
backwards compatibility

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=477407&group_id=23194

--__--__--

Message: 7
To: [email-masked]
From: [email-masked]
Date: Wed, 30 Oct 2002 01:37:12 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-477413 ] Transport BNF: mode

Bugs item #477413, was opened at 2001-11-02 08:32
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=477413&group_id=23194

Category: None
Group: Fixed in CVS/Need WG Approval
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Transport BNF: mode

Initial Comment:
Transport ABNF, mode line, The "=" lacks " around it. There are also unclearities if you could 
actually have mode=""PLAY","RECORD"" ?

----------------------------------------------------------------------

>Comment By: Magnus Westerlund (magwes)
Date: 2002-10-30 10:37

Message:
Logged In: YES 
user_id=302620

The BNF problems has been resolved. Checked in and published
in the 01 version. So far no comments, closing issue

----------------------------------------------------------------------

Comment By: Rob Lanphier (robla)
Date: 2002-02-22 02:40

Message:
Logged In: YES 
user_id=3796

New BNF:
parameter          = ";" ( "unicast" | "multicast" )
                ...
                   | ";" "mode" "=" mode-spec
mode-spec          =  <"> 1#mode <"> | mode
mode               =  "PLAY" | "RECORD" | token

----------------------------------------------------------------------

Comment By: Rob Lanphier (robla)
Date: 2002-01-30 03:06

Message:
Logged In: YES 
user_id=3796

RESOLVED (Jan 9 telecon: http://rtsp.org/2002/telecon/jan09.html

Rework BNF, fixing multiple problems not limited to allow outside
quotes, but not inside quotes. Quotes are optional 

----------------------------------------------------------------------

Comment By: Rob Lanphier (robla)
Date: 2001-12-14 04:45

Message:
Logged In: YES 
user_id=3796

First issue is a thinko, and just needs to be fixed.  The BNF is pretty sloppy the way that it is, and needs to 
be fixed

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=477413&group_id=23194

--__--__--

Message: 8
To: [email-masked]
From: [email-masked]
Date: Wed, 30 Oct 2002 01:39:30 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-477416 ] BNF error section 3.6 NPT

Bugs item #477416, was opened at 2001-11-02 08:37
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=477416&group_id=23194

Category: None
Group: Fixed in CVS/Need WG Approval
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: BNF error section 3.6 NPT

Initial Comment:
BNF definition:npt-range, sec 3.6 lacks "npt=" in the begining of the definition. Compare with 
smpte-range or utc-range. 

----------------------------------------------------------------------

>Comment By: Magnus Westerlund (magwes)
Date: 2002-10-30 10:39

Message:
Logged In: YES 
user_id=302620

Resolved, fix written up and checked in, pubished in 01
version. No comments, closing issue.

----------------------------------------------------------------------

Comment By: Rob Lanphier (robla)
Date: 2002-02-22 03:06

Message:
Logged In: YES 
user_id=3796

Fixed in CVS:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/rtspspec/parameters.tex.diff?r1=1.4&r2=1.5

----------------------------------------------------------------------

Comment By: David W. Walker (davidwwalker)
Date: 2002-01-29 01:49

Message:
Logged In: YES 
user_id=437905

RESOLUTION:

Require npt=, but have backwards-compatibility note in 
specificaton.

----------------------------------------------------------------------

Comment By: Rob Lanphier (robla)
Date: 2001-12-14 04:53

Message:
Logged In: YES 
user_id=3796

Hmmm...do implementors predominantly implement from the BNF, or from the numerous examples?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=477416&group_id=23194

--__--__--

Message: 9
To: [email-masked]
From: [email-masked]
Date: Wed, 30 Oct 2002 01:42:46 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-477421 ] When to send response

Bugs item #477421, was opened at 2001-11-02 08:43
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=477421&group_id=23194

Category: None
Group: Fixed in CVS/Need WG Approval
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: When to send response

Initial Comment:
Server can't respond to a bad request if no sequence number is present in the request. Resulting in 
that the client does not know that the server has received it and has issues. Please clarify when a 
server is allowed to send response to bad request.

----------------------------------------------------------------------

>Comment By: Magnus Westerlund (magwes)
Date: 2002-10-30 10:42

Message:
Logged In: YES 
user_id=302620

The issue seem to be resolved. The below update has been
published in the 01 version. Closing issue.

----------------------------------------------------------------------

Comment By: Rob Lanphier (robla)
Date: 2002-02-22 04:00

Message:
Logged In: YES 
user_id=3796

Added the following section as a new 11.3.1

11.3.1  400 Bad Request

The request could not be understood by the server due to
malformed syntax. The client SHOULD NOT repeat the request
without modifications [H10.4.1]. If the request does not
have a CSeq header, the server MUST not include a CSeq in
the response.

----------------------------------------------------------------------

Comment By: David W. Walker (davidwwalker)
Date: 2002-02-13 02:10

Message:
Logged In: YES 
user_id=437905

RESOLVED: The Server is allowed to send an immediate 
response with no sequence number. As a general rule the 
server should NOT set sequence numbers. 

----------------------------------------------------------------------

Comment By: Rob Lanphier (robla)
Date: 2001-12-13 19:01

Message:
Logged In: YES 
user_id=3796

This one is going to be up to the server.  It can send "Connection: close" if the state machine is too 
messed up (though see #492546 for another discussion).  We can't overspecify this, though.

Please suggest text to insert in the specification.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=477421&group_id=23194

--__--__--

Message: 10
To: [email-masked]
From: [email-masked]
Date: Wed, 30 Oct 2002 01:46:45 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-477424 ] How to queue timed plays?

Bugs item #477424, was opened at 2001-11-02 08:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=477424&group_id=23194

Category: None
>Group: Fixed in CVS/Need WG Approval
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: How to queue timed plays?

Initial Comment:
When you queue items that has a activation time, does that override the order of the events that 
are queued? Play(1) has time A, Play(2) has time B, time A are after time B. 
Assumption on how it work: 
First Play(2) activated at time B, then at time B Play(1) tries to start, if already playing, it 
is queued as a normal untimed event.

----------------------------------------------------------------------

>Comment By: Magnus Westerlund (magwes)
Date: 2002-10-30 10:46

Message:
Logged In: YES 
user_id=302620

A Queued play is removed, a timed play being activated while
the session is in playing state will result in failure of
type 455. This has been written up and checked in CVS. See
new text for the PLAY method. 

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/rtspspec/methods.tex?rev=1.12&content-type=text/vnd.viewcvs-markup

Resolution needs review on spec text. 

----------------------------------------------------------------------

Comment By: David W. Walker (davidwwalker)
Date: 2002-02-13 02:44

Message:
Logged In: YES 
user_id=437905

RESOLVED: Propose elimination of queued play to list. 
Separate email necessary. 

RESOLVED: postpone 477424 until queue play is resolved.

ACTION ITEM (RL): submit proposal to eliminate queued play.
ACTION ITEM (MW): continuous sequence number filing.

----------------------------------------------------------------------

Comment By: Rob Lanphier (robla)
Date: 2001-12-13 19:04

Message:
Logged In: YES 
user_id=3796

Interpretation is correct.  Do you (or anyone in the working group) have a proposal for text to drop into the 
spec?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=477424&group_id=23194

--__--__--

Message: 11
To: [email-masked]
From: [email-masked]
Date: Wed, 30 Oct 2002 01:55:08 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-477427 ] Transport model requirements

Bugs item #477427, was opened at 2001-11-02 08:49
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=477427&group_id=23194

Category: None
>Group: Fixed in CVS/Need WG Approval
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Transport model requirements

Initial Comment:
Which connection models are required. Is non persitent TCP connections a MUST support, or only 
RECOMMENDED?

----------------------------------------------------------------------

>Comment By: Magnus Westerlund (magwes)
Date: 2002-10-30 10:55

Message:
Logged In: YES 
user_id=302620

The text in section 1.1 has been rewritten to, "There is no
necessity for a notion of an RTSP connection;"

New text written in chapter 9. Connections. This resolves it
around  TCP connections. However the connection less usage
(rtspu) needs further text.

----------------------------------------------------------------------

Comment By: Rob Lanphier (robla)
Date: 2002-04-04 02:03

Message:
Logged In: YES 
user_id=3796

Current section 1.1 has text which is counter to our
resolution:  "There is no notion of an RTSP connection...."

----------------------------------------------------------------------

Comment By: Rob Lanphier (robla)
Date: 2002-03-18 05:06

Message:
Logged In: YES 
user_id=3796

Discussed in RTSP telecon Jan 23
(http://rtsp.org/2002/telecon/minutes23Jan.html#line90)

  RESOLVED: define header and response for non-persistent
connections. Default is connection-oriented, and
connectionless MAY be implemented. Look into "supported" header.

----------------------------------------------------------------------

Comment By: Rob Lanphier (robla)
Date: 2001-12-13 19:07

Message:
Logged In: YES 
user_id=3796

Good question.  This is related to #492546

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=477427&group_id=23194

End of Rtspspec-bugs Digest

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