Subject: [MMUSIC] Minutes from RTSP telecon 22 of january

From: Thomas Zeng <[email-masked]>
Date: Mon, 27 Jan 2003 11:14:02 -0800

Attendees of RTSP telecon 22 of january, 2003

Andrea Basso
Tom Marshall
Jorg Ott 
Magnus Westerlund
Adlers Klemets
Thomas Zeng

Agenda Bashing:
 Magnus: Please everyone take a look at A proposal for RTP interleaved in
TCP: draft-lazzaro-avt-rtp-framing-contrans-00.txt. It is available from the
IETF repository at:
http://www.ietf.org/internet-drafts/draft-lazzaro-avt-rtp-framing-contrans-0
0.txt

Meeting notes:
- Follow up on last telecon
  * 304 and REDIRECT "*" text proposal.
  (Tom's proposal -- see corresponding email sent by Tom Marshall on Jan 21
entiled [MMUSIC] Proposed update to draft-02.

  Mag(nus): The paragraph on redirect out to proxy and clients is back
wards?
  Tom:      I don't understand...
  Mag:      I mean the order of control channel teardown...
  Tom:      Why order is important? why a particular order?
  Mag:      Perhaps my misunderstanding ? 
  Tom:      Proxy can answer requests on behalf of the clients, therefore
order (of answering vs taking done the RTSP                           
            session) is no longer important.
	  
  Resolution:  add a session that proxy should answer redirect request to
the server on behalf of its down stream clients

- 3rr codes:
  Thomas: What is 3rr useful for?
  Mag:    If a client closed TCP after setup,  then connect again to send
play request but Server wanted to REDIRECT, then 
	    Server would use 3rr responses.   

  Mag:    I have more ecommments: have you (Tom) considered header
usability?  eg. Location header for 3rr responses ...
          Should update table 4 and 5 such that Location header should be
allowed for all methods.

  (Action item: Tom to add wording to allow 3rr for other method responses).

  Thomas:  I'd like to bring up the proposal from Magnus (or Mag in short)
to use REDIRECT as a way to say "TEARDOWN" from 
           S->C.

  Tom: I don't like using REDIECT to replace TEARDOWN from S->C. I prefer
END_OF_STREAM in this case to close a session.

  Jorg:  I agree with Tom. Compared to TEARDOWN from S->C, REDIRECT means
something else.

  Mag:   We can say REDIRECT with empty Location header to mean redirecting
to cyber space.

  Jorg:  It still is not convincing.

  Tom:   A "*" location maybe?

  Mag:   Perhaps END_OF_STREAM (or END_OF_SESSION) is more appropriate?  

  Adrea: what about backwards compability? in that regard REDIRECT is better
(than END_OF_STREAM/SESSION)...

  Mag: I don't know whether it belongs to RTSP (i.e., RTCP BYE is better to
signal end of live session)... 

  Tom: I ahve an idea. Suppose server live feed goes away, then server
redirect its clients to itself. Then client   
  reconnect;
  Magnus: Yah,  you can actually redirect to info page

  Resolution: use redirect to tell the clients to teardown and reconnect to
the same server. Then tell the clients that
  service is not available via perhaps a info page. That way we have good
backwards compatibility and no 
  need for TEARDOWN S->C nor END_OF_STREAM.

  Mag: Let's go on to extension mechanism

- Extension mechanism
  Mag: basic idea is to use feature tags and require/Proxy-requre headers
        as well as the Support/Unsupported header from SIP. End points will
list all feature tags 
        it supports in a request and the other side includes all its tags in
its response

  Andrea:  it's not clear who will be the master (e.g., 324-M one guy takes
the role of the master)
  Mag;     it's up to the requester 

  Andrea: in the case of streaming you are right it is the client to decide

  Mag:     it applies to two way as well

  Andrea: what about two way? a capability exchange must have a master

  Mag :   but we are talking about server capabilit not media capabilty

  Jorg:   Clarifying 324M ...   Feature tags are independent of master slave
       Feature tags only indicate what's available , independent of
hieraarchical relationships (master / slave).

   Andrea: for streaming scenario it is clear to me.

   Mag:  This is basically the idea if you require a feature put in Require
header. If server does not have the capability
     it responds with error (code 551) with an Unsupported header containing
the feature tags in question that are not           	supported. 
	The feature tag representing the updated specification with basic 
	playback functionality is necessary due to the few non-backwards 
	compatibility issues we have. To be able to use the following
mechanism 
	in RTSP both end-points need to support "play.basic":

		-- IPv6 addresses in source and destination parameters in
transport header
		-- Use of "RTCP_client_port" and "rtcp_server_port"
transport header parameters.

     This mechanism makes it possible to evolve the RTSP standards 
     (e.g. possible future IPV6 or RTCP back channel (?) extensions).

  Thomas : Makes sense since SIP had a success with it.

  Mag: We have the options method which is a perfrect place to include
Supported header.

  * Feature tags
    - play.basic    
	Mag: The tag, play.basic signals the min implementation of the new
spec. 
         There are also play.speed and play.scale tags.

      Thomas:  let's require Range in PLAY response in play.basic (i.e. min
implementation) if there is no objection.

      Mag: the draft alreadys requires Range header in all Play responses
for on-demand media.

      Thomas: Let's do the same with Live.

      Resolution: Let's propose to require Range in Play responses (for
live, use range "now- ") to the mailing list.

	Magnus:  A comment, for live streams if possible it is better to
give a real 
		clock if possible. I think UTC times can be useful also in
live streams.

    - registration

    Jorg: There is a big issue with registration, which should be
centralized by IETF to reg all feature tags.
         For event packages may not necessaryly be regi by IETF.
         We have seen too many attmpts to abuse it.
         Keep strict control here is to ensure people don't do strange
things. For RTSP we want same security
         so RTSP don't open up too many doors.

         We should probably start with strict registration, but we are aware
of propriatary tags in the existing servers.
         SIP says don't mess up existing registered feature tags if you have
propriatary features.

         Ensure we don't get collisions in the registration process. Should
have an open documentation for that. It's up to
         group to decide whether we have allowance to experimentations,
since people don't want to wait until it's all 		   finished.
What are people's thoughts whether to make it very strict or very open?

   Mag:  Judging by 3gpp experience, 3 months turn around is too long. I'd
rather see it faily open registration

   Jorg: Just not say anything about how to use feature tags? not a good
idea.

   Mag:  first come first serve is an option.

   Conclustion: More thougts are required. Please look at the existing
registration route in the drafts as well as the 7 
   tags. Identify potential parties who will likely send requests to
register tags (e.g. 3gpp and ISMA).

   Jorg: My goal is to avoid too many profiles of RTSP -- we have had enough
incompabilites b/w SIP in general and
        3gpp SIP. Neither side should be relying on anything.

   Mag: I have been talking to 3gpp. RTSP so far hasn't suffered much in
terms of "profiling RTSP".
   Jorg: there is going to be a meeting b/w 3gpp and IETF next week. I'll
speak to Allison on this issue.
         
   (Action item: Jorg to post a feedback after next week's meeting.)

  * Require header
  * Proxy-require header
    - Shall it really require server to support these? See SIP, RFC
      3261 which uses Proxy-Require only for proxies.   

    Tom: all Proxy headers are hop by hop in HTTP 1.1

    Magus: it makes sense to align with SIP than HTTP at this moment. 

    Magnus: can you see Proxy only feature tags?
            e.g. cache feature tags for RTSP that are only for proxies?
            Current servers are not to honor Proxy-require headers.

    Jorg: if you want tag be supported by both proxy and servers then use
both Require and Proxy-Require.

    Mag: Do you Tom support Proxy-require?

    Tom: yes, but there is no specific tags.
         in previous server, Proxy-require not honored by servers. It's
changed in recent release.

    Conclusion: Propose to MMUSIC that Proxy-require should not be honored
by servers, only by Proxys. Likewise,  Require 
	is only for servers, not Proxy.     This would be aligning with SIP.

    Mag: Tom's and my servers both honor Proxy-require headers. So there is
backwards compatibility issue, but minor engouh.

- Next meeting

Magnus: when?

        also think about editorship.

       Let's say two weeks.

Thomas : any objectisn to two weeks?

        Two weeks it is.

---------------------------------
Best Regards

Magnus Westerlund 

Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

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