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

From: [email-masked]
Date: Tue, 09 Sep 2003 08:26:02 -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-755472 ] Restricted use of Range header time parameter (SourceForge.net)
   2. [ rtspspec-Bugs-755472 ] Restricted use of Range header time parameter (SourceForge.net)
   3. [ rtspspec-Bugs-739845 ] "a=range" is missing IANA registration and clear rules (SourceForge.net)
   4. [ rtspspec-Bugs-803064 ] Teardown text needs rewrite (SourceForge.net)
   5. [ rtspspec-Bugs-742328 ] How to handle PLAY request when at the end of a media clip (SourceForge.net)
   6. [ rtspspec-Bugs-678107 ] Change of Proxy-Require header (SourceForge.net)
   7. [ rtspspec-Bugs-707252 ] Update the RTSP URI schemes (SourceForge.net)
   8. [ rtspspec-Bugs-518997 ] Mixing aggregate and non-aggregate (SourceForge.net)
   9. [ rtspspec-Bugs-507884 ] Should sequnce numbers be consecutive (SourceForge.net)
  10. [ rtspspec-Bugs-771638 ] a=range in SDP to indicate live media (SourceForge.net)
  11. [ rtspspec-Bugs-477427 ] Transport model requirements (SourceForge.net)

--__--__--

Message: 1
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Tue, 09 Sep 2003 04:07:22 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-755472 ] Restricted use of Range header time parameter

Bugs item #755472, was opened at 2003-06-16 20:37
Message generated for change (Comment added) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=755472&group_id=23194

Category: None
Group: Fix - Discussed/Resolved
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Magnus Westerlund (magwes)
Summary: Restricted use of Range header time parameter

Initial Comment:
The Range header's time parameter has been deprecated

from use in PLAY and PAUSE method. The only method

still using the time parameter is REDIRECT. 

The decision to stop using time= for PAUSE and PLAY was

discussed at the 56th IETF and at the April 16th telecon. 

Reasons is that they create hard synchronization

problems and possilbe failure modes that does not give

the client any error codes. There was also no need seen

for the functionality. 

The change has been edited in and will be published

from version 4 of the draft. 

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

>Comment By: Magnus Westerlund (magwes)
Date: 2003-09-09 13:07

Message:
Logged In: YES 
user_id=302620

As discussed in MMUSIC the following definition will be added:

If the "a=range" attribute contains an open ended range

(fmt=start-) this media or session is of unknown duration

and SHALL be considered as non seekable unless this property

is overriden. 

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

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

--__--__--

Message: 2
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Tue, 09 Sep 2003 04:16:11 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-755472 ] Restricted use of Range header time parameter

Bugs item #755472, was opened at 2003-06-16 20:37
Message generated for change (Comment added) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=755472&group_id=23194

Category: None
Group: Fix - Discussed/Resolved
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Magnus Westerlund (magwes)
Summary: Restricted use of Range header time parameter

Initial Comment:
The Range header's time parameter has been deprecated

from use in PLAY and PAUSE method. The only method

still using the time parameter is REDIRECT. 

The decision to stop using time= for PAUSE and PLAY was

discussed at the 56th IETF and at the April 16th telecon. 

Reasons is that they create hard synchronization

problems and possilbe failure modes that does not give

the client any error codes. There was also no need seen

for the functionality. 

The change has been edited in and will be published

from version 4 of the draft. 

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

>Comment By: Magnus Westerlund (magwes)
Date: 2003-09-09 13:16

Message:
Logged In: YES 
user_id=302620

Sorry, text went on wrong item. Please disregard.

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

Comment By: Magnus Westerlund (magwes)
Date: 2003-09-09 13:07

Message:
Logged In: YES 
user_id=302620

As discussed in MMUSIC the following definition will be added:

If the "a=range" attribute contains an open ended range

(fmt=start-) this media or session is of unknown duration

and SHALL be considered as non seekable unless this property

is overriden. 

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

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

--__--__--

Message: 3
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Tue, 09 Sep 2003 04:16:54 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-739845 ] "a=range" is missing IANA registration and clear rules

Bugs item #739845, was opened at 2003-05-19 14:13
Message generated for change (Comment added) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=739845&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: Magnus Westerlund (magwes)
Summary: "a=range" is missing IANA registration and clear rules

Initial Comment:
The "a=range" SDP attribute in appendix C.1.5 of the

specification has some issues.

1. The parameter is not registered with IANA. Write

IANA registration request.

2. The parameter is not clearly defined in regards to

ABNF. Write ABNF definition for attribute don't forget

extension for new format types.

3. Is multiple range specifications allowed?

4. Write normative language on usage regarding session

and media level. 

5. Is multiple instances for the different formats allowed?

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

>Comment By: Magnus Westerlund (magwes)
Date: 2003-09-09 13:16

Message:
Logged In: YES 
user_id=302620

As discussed in MMUSIC the following definition will be added:

If the "a=range" attribute contains an open ended

range

(fmt=start-) this media or session is of unknown duration

and SHALL be considered as non seekable unless this property

is overriden. 

This has been edited in and will appear in the 05 draft version.

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

Comment By: Magnus Westerlund (magwes)
Date: 2003-06-05 12:45

Message:
Logged In: YES 
user_id=302620

Changes are now editied in. See IANA.tex and SDP.tex

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

Comment By: Magnus Westerlund (magwes)
Date: 2003-06-05 11:31

Message:
Logged In: YES 
user_id=302620

Has been discussed at telecon

1. Write IANA registration

2. Write ABNF 

3. No

4. Yes, will be included.

5. No

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

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

--__--__--

Message: 4
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Tue, 09 Sep 2003 04:20:40 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-803064 ] Teardown text needs rewrite

Bugs item #803064, was opened at 2003-09-09 13:20
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=803064&group_id=23194

Category: None
Group: Fix for DS - Typo/Thinko
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Teardown text needs rewrite

Initial Comment:
The text for the teardown section needs a serious

rewrite. The current text is not very clear on several

matters in regards to aggregated and non-aggregated

teardown.

Should probably await resolution of bug 795295.

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

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

--__--__--

Message: 5
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Tue, 09 Sep 2003 04:38:08 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-742328 ] How to handle PLAY request when at the end of a media clip

Bugs item #742328, was opened at 2003-05-23 15:44
Message generated for change (Comment added) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=742328&group_id=23194

Category: None
Group: Fix - Discussed/Resolved
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Magnus Westerlund (magwes)
Summary: How to handle PLAY request when at the end of a media clip

Initial Comment:
This is a problem that has surfaced in interoperability

test. It shouldn't surface in a correct implemented

client talking to a correct server. However how should

the server handle it if still happens.

The scenario is:

The server is playing a stored media clip to the

client. The client has a certain amount of buffer

space. The client hits PAUSE. However when the PAUSE

request reaches the server the server has played all

media for the clip. The server respond to the PAUSE

request with a Range header containing the pause point.

The problem arise when the client likes to resume the

playout of  the media to the end. The client has all

the rest of the media already in its buffer and this

should be totally local operation.

There are three reasons I see why the client may not

know that this is a local operation:

1. The client has not been informed about the duration

of the media. Therefore it can use the pause point in

the response to determine that the server is at the end

of the media clip.

2. The server has not included the pause point in the

PAUSE response, may happen for RFC 2326 servers. This

is a MUST in the new specification.

3. The client does not check the duration against the

given pause point. This the client SHOULD do to prevent

this from happening.

Any of the three above would result in that the client

sends a PLAY request to resume playing (no range

header) at the pause point. However the server is

already at the of the media clip. So the big question

is how the server handles this PLAY request?

I can see two ways of resolving it and would like some

input on which is the recommended one.

A. The server sends a 200 OK on the request to

continue. The RTP-Info is for the next packet which

will not be sent as result of this PLAY request. The

Range header response indicate that the server will

play from the given end of the clip to the end of the

clip. Then no RTP packets are sent.

B. The server sends a 457 (Invalid Range) including in

the response the range header for the pause point.

In my opinion the best alternative is B. This clearly

indicate to the client that no media will be delivered.

Also it is in line with the semantics that a PLAY

request is only performed when the range is within the

media clip.

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

>Comment By: Magnus Westerlund (magwes)
Date: 2003-09-09 13:38

Message:
Logged In: YES 
user_id=302620

The resolution B has been added to the text in the PLAY

method. Will become available from draft version 05. 

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

Comment By: Magnus Westerlund (magwes)
Date: 2003-06-13 16:08

Message:
Logged In: YES 
user_id=302620

At the telecon 28th of May 2003 it was the conclusion to use

resoultion b. Needs to be written up. 

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

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

--__--__--

Message: 6
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Tue, 09 Sep 2003 04:54:14 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-678107 ] Change of Proxy-Require header

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

Category: General
>Group: Resolved - Added to text
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Magnus Westerlund (magwes)
Summary: Change of Proxy-Require header

Initial Comment:
Current text: Says that proxy-require applies to both

proxy and server.

New Proposal: The feature tags in a "Proxy-require"

header will only apply to the proxies, and not the

server. For feature that the server must support the

"Require" header shall be used. If required feature

support from both proxy and server both "Proxy-Require"

and "Require" must be used.

Pro:

- Align with SIP's usage of header

- Makes it possible to create features tags for proxy

only functionality. Otherwise all servers will be

mandated to also know about proxy only features.

Cons: 

- Backwards compatibility. (Actually this does not

matter much as: A old server implementing the old way

would also not work with any new feature tags for

proxies. So it will block operation independent of

changed semantics or not.)

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

>Comment By: Magnus Westerlund (magwes)
Date: 2003-09-09 13:54

Message:
Logged In: YES 
user_id=302620

The necessary text changes have been written in and will

become available in version 05 of the draft. 

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

Comment By: Magnus Westerlund (magwes)
Date: 2003-07-10 11:42

Message:
Logged In: YES 
user_id=302620

Whas resolved at the telecon january 22 2003. 

Resolution: Proxy-require shall only apply to proxies not

servers. 

Needs to be changed in the specification. Should also

clarify that a feature tag can be of type, proxy, server or

both. 

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

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

--__--__--

Message: 7
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Tue, 09 Sep 2003 04:57:53 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-707252 ] Update the RTSP URI schemes

Bugs item #707252, was opened at 2003-03-21 01:45
Message generated for change (Settings changed) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=707252&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: Magnus Westerlund (magwes)
Summary: Update the RTSP URI schemes

Initial Comment:
The current RTSP schemes has been updated to allow 

for literall IPv6. However the URI scheme should also be 

updated to cover IRI (Internationalized Resource 

Identifiers). I (Magnus W) will try to get more information 

on this from the people having created the IRI. Hopefully 

this is little or no work.

For people to read up on URI scheme considerations 

and other things should look at:

RFC 2717 and 2718. I hade so far not had time to dig up 

any references to the IRI work. 

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

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

--__--__--

Message: 8
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Tue, 09 Sep 2003 06:47:01 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-518997 ] Mixing aggregate and non-aggregate

Bugs item #518997, was opened at 2002-02-18 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=518997&group_id=23194

Category: General
Group: Fixed in CVS/Need WG Approval
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Rob Lanphier (robla)
Assigned to: Magnus Westerlund (magwes)
Summary: Mixing aggregate and non-aggregate

Initial Comment:
This is a tracking issue for the email here:

http://www1.ietf.org/mail-archive/working-groups/mmusic/current/msg00115.html

 * Point a) RESOLVED

 * First point b) RESOLVED

 * Second point b) MUTE and UNMUTE

   * RESOLVED: separate draft

   * ACTION ITEM: Call for authors on MUTE proposed. AN

is tentatively signed up

 * Point C) (same as http://rtsp.org/bug477400)

   * RESOLVED: PING writeup will be done as part of

next RTSP draft...continue discussion on mailing list

   * RESOLVED: deprecate PLAY w/o range as ping method

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

>Comment By: Magnus Westerlund (magwes)
Date: 2003-09-09 15:47

Message:
Logged In: YES 
user_id=302620

No comments has been received on this since it was written up. 

Closing bug. 

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

Comment By: Magnus Westerlund (magwes)
Date: 2002-10-30 18:52

Message:
Logged In: YES 
user_id=302620

The MUTE proposal has been written but is currenlty out of

circulation. However these issues has been resolved. The

changes necessary has been written up. If accepted this

issue can be closed. 

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

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

--__--__--

Message: 9
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Tue, 09 Sep 2003 08:04:07 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-507884 ] Should sequnce numbers be consecutive

Bugs item #507884, was opened at 2002-01-24 09:31
Message generated for change (Comment added) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=507884&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: Magnus Westerlund (magwes)
Summary: Should sequnce numbers be consecutive

Initial Comment:
To make it possible to detect losses of request when transported over UDP, the sequnce number 

should be consecutive. In that way the server will know that it should not process a request until 

the missing ones before is received. 

Are there any issues with such a solution? 

Does the first sequence number needs to be specified so losses of the first message(s) is known?

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

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

Message:
Logged In: YES 
user_id=302620

The text has been updated, with explict text about sequence

number may start at any value, but is recommended to start

at 0. 

The connection chapter has also be restructered. 

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

Comment By: Magnus Westerlund (magwes)
Date: 2002-10-30 17:53

Message:
Logged In: YES 
user_id=302620

The specification is updated to require increments with one

for each new message. However the initial value is still

free to pick. 

The effect of losing the first packet is that request can be

performed in another order than intended. However if you

loose a not state changing event (Options, DESCRIBE) it will

not really matter. The first setup can't be pipelined unless

it is done with another SETUP request for two non-aggregate

session. A client is not allowed to issue a PLAY until the

SETUP request response is back. 

So I don't see how it can matter.  

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

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

--__--__--

Message: 10
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Tue, 09 Sep 2003 08:15:44 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-771638 ] a=range in SDP to indicate live media

Bugs item #771638, was opened at 2003-07-15 16:46
Message generated for change (Comment added) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=771638&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: Magnus Westerlund (magwes)
Summary: a=range in SDP to indicate live media

Initial Comment:
Today there is some confusion on how a client should

know that media is live. To be able to indicate this in

SDP the following is proposed:

Use a=range with any timeformet but in open ended style

will indicate that the media is live, e.g.

a=range:npt=0- or a=range:npt=now-. This makes it

possible to use also for sessions using SMTPE or UTC

times. 

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

>Comment By: Magnus Westerlund (magwes)
Date: 2003-09-09 17:15

Message:
Logged In: YES 
user_id=302620

This has been added into the SDP appendix. Awaiting review.

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

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

--__--__--

Message: 11
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Tue, 09 Sep 2003 08:18:36 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-477427 ] Transport model requirements

Bugs item #477427, was opened at 2001-11-02 08:49
Message generated for change (Comment added) made by magwes
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: Closed
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
>Assigned to: Magnus Westerlund (magwes)
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: 2003-09-09 17:18

Message:
Logged In: YES 
user_id=302620

This has been resolved. 

TCP MUST be supported. Non persistent TCP MUST be supported.

No comments on that part for a while, closing this. 

The RTSP over UDP is removed. If needed in the future it

will need a seperate document. 

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

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