Subject: [MMUSIC] RTSP discussion and status

From: Magnus Westerlund <[email-masked]>
Date: Mon, 01 Mar 2004 01:42:59 +0100

Hi,

Below is an proposal for an agenda for a off-line discussion of RTSP. If 
you are at the IETF meeting and interested in participating in a 
discussion please send me a mail. My three proposals for meeting time if 
enough interest exist are:
Tuesday 15.30-17.00
Wednesday 13.00-15.00
Thursday 9.00-11.00

Please indicate possibility to participate for all of the times.

Below the agenda there is a message indicating my view of the status of 
all the Bugs currently open in the sourceforge bug tracker.

Cheers

Magnus

-----

Agenda RTSP discussion IETF 59

1. Opening of meeting and Administrative

2. RTSP Core

2.1 Core specification bugs under development.

a. http://rtsp.org/bug507882 - RTP timestamp and pause
    - Examples edited into 06

b. http://rtsp.org/bug742348 - Usage of implicit REDIRECT.
    - Around will write up text.

c. http://rtsp.org/bug640272 - Default way of deriving aggregate URL
    - The text has been removed, it is now unspecified

d. http://rtsp.org/bug771638 - a=range in SDP to indicate live media
    - Check if live is written, and try to remove, in benefit for
      Unbounded session. This has been resolved by defining live as being
      unbound. See definition chapter of 06 version.

    - Check if the syntax does not create great clashes with the TiVo
      use case.  However it is unlikely that the full semantics necessary
      can be expressed with current attributes. Has not been done.

e. http://rtsp.org/bug531189 - How does REDIRECT method work
    - Has been edited in.

f. http://rtsp.org/bug770522 - Request to response time is not limited.
    - The text has been updated and added into the spec, see section 9.5

g. http://rtsp.org/bug804219 - How to handle sync in re-SETUP
    - Text in the SETUP method description seems strict enough.

h. http://rtsp.org/bug806404 - Re-SETUP of transport parameters
    - It seems initial and ready state changes are equal, and the play
      state being more restricted.
    - Point out that in the general case the changes can result in that a
      new RTP session is created.
    - Another consideration is for connection oriented media, can a
      switch over be performed relatively seamless.
    - It seems that not requiring a PAUSE, SETUP, PLAY sequence makes
      sense, thus motivating the continuation of this work.
    - However the proposals and text needs more thought.
    - Geetha will provide new text.

i. http://rtsp.org/bug810666 - Removal of SETUP in play state
   - Magnus will edit in that it is unspecified. [DONE]

j. http://rtsp.org/bug811815 - Use of c= in SDP to know possible address
                                classes
   - Needs to look into backwards compatibility issues.
   - This issue is connected to issue (r), to allow a server to announce
     dual address realm support.
   - It needs a proposal text for evaluation.

k. http://rtsp.org/bug795314 - Caching of OPTIONS request
   - It seems that the Caching chapter is enough. I don't see a reason
     for allowing caching of OPTIONS

l. http://rtsp.org/bug850256 - When must RTP-Info be included?

   - Usage of RTP-Info can be a SHOULD, however if the server does not
     provide it, the client will be required to do synchronization by
     RTCP. Servers are strongly recommend if able to include RTP-Info
     with timestamp information.
     [Edited in]

m. http://rtsp.org/bug850265 - Removed features are unspecified, not
forbidden
   - Needs to be edited in. [DONE]

n. http://rtsp.org/bug840304 - CSEQ is direction dependent in numberspaces.
   - Nothing done, needs to be edited in. [Done]

o. http://rtsp.org/bug850267 - Should all ABNF syntax be gathered in one
chapter?
   - Nothing done, needs to be edited in. [Done]

p. http://rtsp.org/bug829528 - Usage of Grouping of media lines with
                                RTSP.
   - For further study and discussion.

q. http://rtsp.org/bug853175 - Dest_addr needs indicator for using RTSP
                                IP
   - The dest_addr allow for empty host specifier, thus if one does not
     want to specify the address, only port one have an empty host part.
     This has been clarified in the text.

r. http://rtsp.org/bug853178 - Security risk with changing transport
                                parameters
   - For further study and discussion.

s. http://rtsp.org/bug853184 - How to learn servers multicast
                                capabilities
   - For further study and discussion.

t. http://rtsp.org/bug889699 - Change requirement level on auth for 
media destination

2.2 Tracking of items not require actions currently.

  http://rtsp.org/bug464462 - Content-Length header wrong in examples
  http://rtsp.org/bug810681 - The updated specification version number

3. RTSP Specification Extensions

3.1 Streaming Relays.

3.2 End of Media

3.3 RTSP and NAT issues

4. Next meeting

- Will be in mid January

5. Meeting closed.

Current Sourceforge bugs and their status
==========================================
Nr   Class
---------------------------------------------------
10   Stable Resolution exist, proposed to be closed
17   Resolution Exist, needs further review
7    Needs write-up of Resolution
4    Needs Discussion
2    Has dependencies forcing delay

Stable Resolution exist, proposed to be closed
----------------------------------------------

  493054 IPv6 issues * 2001-12-13 23:49 magwes nobody
    - Awaiting review before being closed.

  493265 Pause - Play behaviour clarification * 2001-12-14 12:55 magwes 
magwes
    - I think it has been clarified, intend to close if not comments are 
given.

  494526 The use of message-body in methods * 2001-12-18 10:43 nobody 
magwes
    - The bug part is resolve, the feature request has its own feature 
request
      in that tracker. Recommend that we close bug.

  506412 RTSP Teardown functionality * 2002-01-21 13:41 magwes magwes
    - Is now clarified, please review. Propose to close.

  513880 How to use Range when Scale is negative * 2002-02-06 19:48 
arvy_n klemets
    - This has been resolved, and been available since last revision. 
Close bug.

  533691 Clarify Range Where t0 <= t1 * 2002-03-22 18:36 arvy_n zengtm
    - Is clarified in text, propose to close bug

  556061 When can REDIRECT be received? * 2002-05-14 20:33 magwes robla
    - Has been made clear, review and then close.

  640265 Extension of Transport header * 2002-11-18 21:07 magwes magwes
    - The possibility to extend Transport header is clarified. Needs review

  640272 Default way of deriving aggregate URL * 2002-11-18 21:19 magwes 
magwes
    - Has been resolved as being undefined. Clarified in text.

  663715 Requirement levels for Transport:SSRC needs clarification * 
2003-01-07 15:31 arvy_n magwes
    - This is now clarified. Review and close

Resolution Exist, needs further review
--------------------------------------

  494533 The use of the word require in the RFC. * 2001-12-18 11:16 
magwes magwes
    - There has been some editing done in relation of this. However 
further review
      of the usage of RFC 2119 normative language is recommended.

  500868 Require: option-tag values unclear * 2002-01-08 17:09 magwes 
seansh
    - The IANA registry is proposed, some values has been defined. 
Further review
      solicited. If no comments forth coming, propose to close this bug.

  507882 RTP timestamps when playing after pause * 2002-01-24 09:30 
arvy_n magwes
    - This has been added to Appendix B. Please review.

  531189 How does REDIRECT method work * 2002-03-18 05:14 magwes magwes
    - Is edited in, needs review. Possible issue with connection handling.
      Current text resolves this. Acceptable?

  538997 Need to flesh out 1.5 (Extending RTSP) * 2002-04-04 01:26 
magwes robla
    - IANA section is in good shape. Please review 1.5 if it is enough.

  631957 Use of # and ? in RTSP URLs * 2002-11-01 09:49 magwes magwes
    - The URI part is clarified to allow both. However the actual usage 
is not
      defined.

  633779 SET_PARAMETER responses * 2002-11-05 13:19 magwes magwes
    - Text for SET_PARAMETER has been updated. Needs review.

  672160 Describe a interleaved RTSP channel for client RR reports  * 
2003-01-22 01:28 magwes zengtm
    - The bi-directional nature of channels has been clarified. Needs 
review.

  770522 Request to response time is not limited. * 2003-07-13 16:00 
magwes magwes
    - Text proposal in spec. Needs review.

  803064 Teardown text needs rewrite * 2003-09-09 13:20 magwes magwes
    - Has been updated, needs review.

  804219 How to handle sync in re-SETUP * 2003-09-11 09:20 magwes magwes
    - Has been clarified. Needs review

  831553 Error in rfc2326bis-04 example 15.4 * 2003-10-28 06:20 magwes 
zengtm
    - Has been fixed. Resolution needs review. More than a single 
solution possible.

  840304 CSEQ is direction dependent in numberspaces. * 2003-11-11 22:54 
magwes magwes
    - Has been clarified, needs review.

  850256 When must RTP-Info be included? * 2003-11-27 15:06 magwes magwes
    - The level has been lowered to SHOULD, strengthen motivation.

  850265 Removed features are unspecified, not forbidden * 2003-11-27 
15:25 magwes magwes
    - Definition written in and applied in most cases. Needs review.

  850267 Gather all ABNF in syntax chapter * 2003-11-27 15:38 magwes magwes
    - Performed, needs review.

  853175 Dest_addr needs indicator for using RTSP IP * 2003-12-03 11:00 
magwes magwes
    - Proposal to solve using empty host in dest_addr.

Needs write-up of Resolution
----------------------------

  506684 Allow Rtp-Info header in more contexts * 2002-01-21 23:46 
magwes klemets
    - The usage has been extended to SETUP. Missing RTP-Info in header 
table.

  631148 Better Info on usage of Proxies * 2002-10-30 18:23 nobody magwes
    - Needs to be written up.

  640298 Use cases for RTSP * 2002-11-18 21:55 nobody magwes
    - A skeleton chapter is created, needs to be edited in.

  742348 Usage of implicit REDIRECT.  * 2003-05-23 16:21 arvy_n magwes
    - Needs text.

Needs Discussion
----------------

  792973 Clarify changing of transport parameters * 2003-08-22 09:21 
nobody magwes
    - Needs text proposal for further discussion.

  806404 Re-SETUP of transport parameters * 2003-09-15 10:52 nobody magwes
    - Needs discussion, see also 792973.

  811815 Use of c= in SDP to know possible address classes * 2003-09-24 
16:59 nobody magwes
    - Needs discussion

  829528 SDP appendix and RFC 3388 * 2003-10-24 13:38 nobody magwes
    - Needs discussion

  853178 Security risk with changing transport parameters * 2003-12-03 
11:07 nobody magwes
    - Open for further discussion

  853184 How to learn servers multicast capabilities * 2003-12-03 11:16 
nobody magwes
    - Needs discussion

  889699 Change requirement level on auth for media destination 
2004-02-03 14:14 nobody magwes
    - Needs discussion

Has dependencies forcing delay
-----------------------------

  464462 Content-Length header wrong in examples * 2001-09-24 18:09 
nobody nobody
    - Editorial, needs to be checked after the examples themselves has 
been reviewed.

  810681 The updated specification version number * 2003-09-22 17:59 
nobody magwes
    - Open, however author target is for 1.0. Will need discussion when 
edits are in.

-- 

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]

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

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