Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #93 - 9 msgs

From: [email-masked]
Date: Mon, 22 Sep 2003 01:49:16 -0700

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-464462 ] Content-Length header wrong in examples (SourceForge.net)
   2. [ rtspspec-Bugs-493054 ] IPv6 issues (SourceForge.net)
   3. [ rtspspec-Bugs-477403 ] Missing session header in response (SourceForge.net)
   4. [ rtspspec-Bugs-494526 ] The use of message-body in methods (SourceForge.net)
   5. [ rtspspec-Bugs-494533 ] The use of the word require in the RFC. (SourceForge.net)
   6. [ rtspspec-Bugs-494957 ] 457 Invalid range for aggregate (SourceForge.net)
   7. [ rtspspec-Bugs-507347 ] Removal of destination redirection (SourceForge.net)
   8. [ rtspspec-Bugs-507882 ] RTP timestamps when playing after pause (SourceForge.net)
   9. [ rtspspec-Bugs-513787 ] Allow capability negotiations (SourceForge.net)

--__--__--

Message: 1
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Mon, 22 Sep 2003 01:41:11 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-464462 ] Content-Length header wrong in examples

Bugs item #464462, was opened at 2001-09-24 18:09
Message generated for change (Settings changed) made by magwes
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: Nobody/Anonymous (nobody)
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: 2
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Mon, 22 Sep 2003 01:42:04 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-493054 ] IPv6 issues

Bugs item #493054, was opened at 2001-12-13 23:49
Message generated for change (Settings changed) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=493054&group_id=23194

Category: General
Group: Fix for DS - Need WG Input
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Magnus Westerlund (magwes)
Summary: IPv6 issues

Initial Comment:
Need a second audit of IPv6 stuff.

Here's an initial survey of IPv6 readiness by Philip J. Nesser II ([email-masked])

http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-ipv4survey-01.txt

Section 3.2 RTSP URL defines:

   The "rtsp" and "rtspu" schemes are used to refer to network resources

   via the RTSP protocol. This section defines the scheme-specific

   syntax and semantics for RTSP URLs.

   rtsp_URL  =   ( "rtsp:" | "rtspu:" )

                 "//" host [ ":" port ] [ abs_path ]

   host      =   <A legal Internet host domain name of IP address

                 (in dotted decimal form), as defined by Section 2.1

                 of RFC 1123 \cite{rfc1123}>

   port      =   *DIGIT

Althought later in that section the following text is added:

   The use of IP addresses in URLs SHOULD be avoided whenever possible

   (see RFC 1924 [19]).

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

Comment By: Rob Lanphier (robla)
Date: 2002-12-26 23:42

Message:
Logged In: YES 
user_id=3796

Discussed at 2002-Dec-11 telecon

http://rtsp.org/2002/telecon/minutes11Dec.html#section2.2.3

RESOLUTION: accepted that IPv6 should be added to spec

Colin: feature tag should be taken up as separate issue

Magnus: people should look at spec for feature tag

ACTION ITEM (all): read spec for how feature tag works

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

Comment By: Magnus Westerlund (magwes)
Date: 2002-10-30 12:50

Message:
Logged In: YES 
user_id=302620

An IPv6 explanation chapter started in the connetion

chapter. May need more text. 

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

Comment By: Magnus Westerlund (magwes)
Date: 2002-10-30 12:31

Message:
Logged In: YES 
user_id=302620

The specification has been updated so that URL's can handle

IPv6 in them. A note of caution that this will cause

interoperability problems has also been added. 

Propose that a chapter is written on IPv4/IPv6

Interoperability to better explain the issues. Demand that

implementers of option-tag "play.basic" supports IPv6 so

that this can be checked before trying.

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

Comment By: Jonathan Sergent (sergent)
Date: 2002-01-15 18:27

Message:
Logged In: YES 
user_id=79184

We have implemented IPv6 in our RTSP server.  The above

issue--strings in URLs--is not particularly relevant to us

since we do not attempt to parse the host and port

information in our server (we just treat it as a string),

and we do not have an RTSP client.

The issue that is not mentioned above that is much more

significant is the Transport header's handling of

addresses.  The grammar does not allow IPv6 addresses.

We will deliver RTP over IPv6 if it can be negotiated

without passing addresses through the Transport header (i.e.

no multicast, and source and destination are the same as the

RTSP endpoints).  If we can decide on the format for this,

we will be able to implement it and try it out.

I think that some rules need to be set out w.r.t. the use of

mapped addresses and such in the header.  And should IPv6

potentially be negotiated as a different protocol in the

header?  (i.e. Transport:

RTP/AVP/UDP6;unicast;foo,RTP/AVP/UDP;unicast;bar to indicate

a preference for V6 over V4)

Also, it should probably be clarified that c=IN IP4 0.0.0.0

in SDP is just a flag value and does not indicate the

preference or the availability of V4, only that the

parameters will be negotiated at SETUP time.

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

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

--__--__--

Message: 3
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Mon, 22 Sep 2003 01:43:21 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-477403 ] Missing session header in response

Bugs item #477403, was opened at 2001-11-02 08:20
Message generated for change (Settings changed) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=477403&group_id=23194

Category: None
Group: Fix for DS - Need WG Input
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
>Assigned to: Magnus Westerlund (magwes)
Summary: Missing session header in response

Initial Comment:
Page 38 first example: Example missing session header in response.

Should not the client respond with what session id the respond relates to, as the

request contained one.

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

Comment By: Magnus Westerlund (magwes)
Date: 2003-09-04 09:03

Message:
Logged In: YES 
user_id=302620

There has been some text changes on this section in the 04

draft. I don't think the changed text actually covers the

case completly in regards to the old text. It is also a

tighter definition. 

The new definition does not allow one to create session

without a session id as RFC2326 does. This functionality to

use some other method, like dynamic URLs, seems unspecified.

Therefore I propsoe that it is dissallowed.

Secondly the comments about when one MUST send the session

identifier:

- Robla is correct that the text does not require a server

in the response to include a session header. 

- In response to kjh1905m's comment, this MUST relates to

the client. IF you read carful it says that the client MUST

use the session identifier, if defined by the server, in any

request that is in relation to the created session. 

Actions:

- Question: Is there any need to not require the server to

generate a session ID? The use of any other method to bind

sessions is not specified. In my opinion any client being

faced with this would not understand it, and if it had the

intention of doing aggregate control, it will not know how. 

- The text in the 04 draft version should propably be

improved. I think that mentioning cases where the session

header must or must not be included in the response will

improve understanding. An example of this is the TEARDOWN,

where the presence of a session id header indicates that the

session still exist. I would also guess that having at as

default behavior to return the session ID in responses is

beneficial, but not required or something a client or proxy

cna depend on.

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

Comment By: Jaehwan, Kim (kjh1905m)
Date: 2003-09-04 07:42

Message:
Logged In: YES 
user_id=365760

Then, what is the meaning of 'MUST'?

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

12.37 Session

   This request and response header field identifies an RTSP 

session

   started by the media server in a SETUP response and 

concluded by

   TEARDOWN on the presentation URL. The session identifier 

is chosen by

   the media server (see Section 3.4). Once a client receives 

a Session

   identifier, it MUST return it for any request related to that

   session.  A server does not have to set up a session 

identifier if it

   has other means of identifying a session, such as 

dynamically

   generated URLs.

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

Comment By: Rob Lanphier (robla)
Date: 2002-01-29 00:23

Message:
Logged In: YES 
user_id=3796

I don't think this is a mistake.  The server isn't required to send back a session identifier if the client sends 

one.  It's only required to generate one if the client *doesn't* specify one....and only then in the SETUP 

message.

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

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

Message:
Logged In: YES 
user_id=3796

Whoops...will fix.

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

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

--__--__--

Message: 4
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Mon, 22 Sep 2003 01:43:41 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-494526 ] The use of message-body in methods

Bugs item #494526, was opened at 2001-12-18 10:43
Message generated for change (Settings changed) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=494526&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: Nobody/Anonymous (nobody)
Summary: The use of message-body in methods

Initial Comment:
The current specification does only allow use of message-body in methods DESCRIBE and 

GET_PARAMETER according to text below.

Chapter 12 secodn paragraph:

   "                      ...   The last column lists the method for which

   this header field is meaningful; the designation "entity" refers to

   all methods that return a message body. Within this specification,

   DESCRIBE and GET_PARAMETER fall into this class."

This seems to be a typo as also SET_PARAMETER examples has message-body. Also a table 

clarifying which headers that are allowed to have message-body would be good. 

What is needed to be discussed in the WG is a possiblilty to allow message-body also for the 

SETUP method. Allowing this would make it possible to do media and encoding selection with RTSP. 

Today there exist no way for a server to express different alternatives in a SDP for a media, 

primarily regarding media encoding. A selection of media variants may perhaps already be possible 

through the use of different URLs.  

A walk-through example would look like this: Client does describe and receives a SDP. This SDP 

tells the client that the audio media is available AMR and can be packetized both with or without 

interleaving. Client selects the interleaving case and removes the payload type without interleaving 

 from the SDP. This modified SDP is then sent in the SETUP request to the server. The server looks 

at the received SDP and uses the media information concerning the URL in the setup and use it to 

configure the payload packetizer. 

In the above example a number of alternatives could also be given in the SDP. The ones 

not supported by the client is removed. They can also be prioritized. Then the server is allowed to 

select and also to switch encoding during the session. This makes it for example possible to adapt 

to network conditions.  

This will of course require a more complete overview what the consequences will be of such a 

change. 

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

Comment By: Magnus Westerlund (magwes)
Date: 2002-10-30 12:58

Message:
Logged In: YES 
user_id=302620

The method table in the beginning of the header chapter now

contains a column which tells how body can be used. Also all

error messages may include a body. 

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

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

--__--__--

Message: 5
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Mon, 22 Sep 2003 01:43:53 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-494533 ] The use of the word require in the RFC.

Bugs item #494533, was opened at 2001-12-18 11:16
Message generated for change (Settings changed) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=494533&group_id=23194

Category: General
Group: Fix for DS - Large task
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
>Assigned to: Nobody/Anonymous (nobody)
Summary: The use of the word require in the RFC.

Initial Comment:
The RFC contains different usage of the word require. Sometimes it means that a implementation 

must interpret and understand a header or method. Othertimes the a certain header must be sent 

togheter with a method. 

One fix is to create a better table for the headers that clarifies the two different cases. Another is 

looking over the methods and use cases and clearly write when they must be included. 

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

Comment By: Rob Lanphier (robla)
Date: 2001-12-19 02:29

Message:
Logged In: YES 
user_id=3796

We need to rework that table to clarify the difference between the two.

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

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

--__--__--

Message: 6
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Mon, 22 Sep 2003 01:44:41 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-494957 ] 457 Invalid range for aggregate

Bugs item #494957, was opened at 2001-12-19 10:50
Message generated for change (Settings changed) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=494957&group_id=23194

Category: General
Group: Fixed in CVS/Need WG Approval
Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Magnus Westerlund (magwes)
>Assigned to: Magnus Westerlund (magwes)
Summary: 457 Invalid range for aggregate

Initial Comment:
When shall 457 be used in the case of aggregated control?

In a single media session its unambigous to when a range is valid or not. But in the aggregated 

case the range given in a play can be valid for one media and invalid for another. Which of the two 

following interpretetations should be used?

1. A aggregate range is invalid only if all media see it as invalid.

2. A aggregate range is invalid in any media see it as invalid.

I would argue for reasons of simplicity and clearnes that case 2 is the better.  

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

Comment By: Magnus Westerlund (magwes)
Date: 2002-10-30 13:08

Message:
Logged In: YES 
user_id=302620

This has been clarified in the specification so that a given

range in a PLAY request must be inside the bounds of at

least one of the medias part of the aggregate. Otherwise a

457 response shall be given. The same rules apply for PAUSE.

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

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

--__--__--

Message: 7
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Mon, 22 Sep 2003 01:45:08 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-507347 ] Removal of destination redirection

Bugs item #507347, was opened at 2002-01-23 05:39
Message generated for change (Settings changed) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=507347&group_id=23194

Category: General
Group: Fixed in CVS/Need WG Approval
Status: Open
Resolution: None
Priority: 5
Submitted By: Rob Lanphier (robla)
>Assigned to: Nobody/Anonymous (nobody)
Summary: Removal of destination redirection

Initial Comment:
Discrepency between RFC 2326 and initial checkin:

12.39 Transport:  In CVS, the following phrase has been removed from the specifation:

"A server SHOULD not allow a client to direct media streams to an address that differs from the 

address commands are coming from."  

I don't necessarily oppose this because there are totally legitimate reasons for sending to a 

different address, but we should probably come up with alternate wording that makes it clear.

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

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

--__--__--

Message: 8
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Mon, 22 Sep 2003 01:48:22 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-507882 ] RTP timestamps when playing after pause

Bugs item #507882, was opened at 2002-01-24 09:30
Message generated for change (Comment added) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=507882&group_id=23194

Category: General
>Group: Resolved - Need write up
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
>Assigned to: Magnus Westerlund (magwes)
Summary: RTP timestamps when playing after pause

Initial Comment:
What happends to the RTP timestamp when you issue a play after being paused for some time?

The following was my interpretation of the proposal for a solution. The

RTP timestamp is equal to display time. So it you do pause, wait five

seconds and then press play the timestamp will be 5 seconds later for

the first packet when resuming.

This behavior works fine when the play contains a range, for queued play

following after each other, but not for resuming play. The reason is the

delay between a user on the client side pressing pause and until the

client stops receiving data packets. If the client then does resume

play, i.e. play without range, the server will continue after the last

packet sent. In this case the client needs to show first the packet

arriving directly after pressing pause (which according to the used

model is past time), and then correctly synchronize the new packet which

has a significant offset in timestamp corresponding to the period of

pause the server has seen. The solution to this is to not use resume

play and instead say play from the point where user pressed pause.

On the other side I don't believe any other model will not have worse

problems.

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

>Comment By: Magnus Westerlund (magwes)
Date: 2003-09-22 10:48

Message:
Logged In: YES 
user_id=302620

A Clear example of RTP Timestamp and synchronization will be

added in appendix B - RTP transport.

The discussion in MMUSIC has made it clear that a continous

time model is needed to make RTCP work correctly. It has to

be accpeted that for on-demand media this will result in

slightly more code for the clients and servers. However all

pices to makes things work is already present. 

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

Comment By: Magnus Westerlund (magwes)
Date: 2003-05-23 16:05

Message:
Logged In: YES 
user_id=302620

This has been further discussed in the MMUSIC mailing list. 

A important point is that RTP and RTCP to function as

intended in this environment must have a timestamp space

that increase continously with real time. 

A client handling the RTSP range header and RTP-Info can

always synchronize the data correctly independtly of which

case the server sent out. 

Using a continous RTP Timestamp space allows the same

timestamp model for both on-demand and live media.

The proposed resolution is to clrafiy in the RTP appendix of

the specification that a RTP timestamp space continous in

regards to real-time SHALL be used. Further write a warning

that this has been missunderstood and clients is RECOMMENDED

to handle both cases. 

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

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

--__--__--

Message: 9
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Mon, 22 Sep 2003 01:48:41 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-513787 ] Allow capability negotiations

Bugs item #513787, was opened at 2002-02-06 16:32
Message generated for change (Settings changed) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=513787&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: Nobody/Anonymous (nobody)
Summary: Allow capability negotiations

Initial Comment:
Today RTSP lacks the possibility to do any kind of capability/parameter negotiation or at least 

choices regarding media parameters. 

I would like to see possibilities for this in the future. My initial idea is to make a offer/answer model. 

This will require expanding the SETUP request to carry a message body. A message exchange could 

work like this.

1. C->S: Describe

2. S->C: Response with media description, SDP or in the future SDP-NG. This description contains 

multiple alternatives or in the case SDP-NG a complete description of the choices regarding media 

that the client can do.

3. Client selects its desired configuration.

4. C->S: Setup with message body with choosen configuration in SDP/SDP-NG.

5. S->C: Server either accepts or refuses the setup with the given configuration. Refusing should 

happend very rarely as server should not offer anything it can provide.

Such solution should try to keep the difference between media parameters and transport 

parameters. Transport parameters should be keept in the transport header to simplify processing in 

proxies and firewalls. Conclusion: only media related parameters should be negotiated with the 

offer/answer mechanism. 

To my knowledge the changes required for this is to allow a message body in SETUP requests. Also 

rules how and to what it may be used must be specified.

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

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

End of Rtspspec-bugs Digest

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