Subject: [MMUSIC] Minutes from 28 May Telecon on RTSP

From: Aravind Narasimhan <[email-masked]>
Date: Mon, 02 Jun 2003 12:33:55 -0400

May 28th Teleconference Meeting Minutes:

Agenda:
-------

1. Opening of meeting.
2. Since last meeting (14th of May).
    a. Bug 533691 &  513880
        - Waiting for updated text after resolution of issues.
    b. http://rtsp.org/bug556295 - Thomas to write text.
    c. Multiple SSRC in RTSP.
        - Aravind to write updated text.
    d. Other?
3. New Things
    a. http://rtsp.org/507882 - RTP timestamp and pause
    b. http://rtsp.org/739845 - "a=range" is missing IANA registration 
and clear rules
    c. http://rtsp.org/742328 - How to handle PLAY request when at the 
end of a media clip
    d. http://rtsp.org/742348 - Usage of implicit REDIRECT.
4. Administrative
    a. Phase 2 of the work. Getting text into shape.
5. Any other Issues
6. Next meeting - Proposal: 11th of June?
7. End meeting

Attendees:
----------
Magnus Westerlund
Geetha Srikantan
Aravind Narasimhan
Philippe Gentric
Yves Ramanzin
Rob Lanphier
Sean Sheedy
Thomas Zeng
Anders Klemets

Old Issues:
-----------

Multiple SSRC Issue:
--------------------
Magnus:  Why change the RTCP section of the Session Header?
Aravind: It was just to have method to indicate how the SSRC can be 
located.  Magnus:  Hard to have mandatory recommendation where SSRC 
should go in RR.
Thomas:  Hint for server implementation
Aravind: Implementations should look through all SSRCs in the RR.
Thomas:  If there are other SSRCs, how does the server resolve it.
Magnus:  What you need to resolve is the server has to know the client 
SSRC.
Thomas:  Client_ssrc is not mandatory, right?
Magnus:  It is added in the bis02
Thomas:  Difficutly in resolving where the RR is coming from it
Aravind: What is the main question?  RTP session is just address pair
Thomas:  If there is no NAT, what is the source/destination?
Magnus:  Client address should be in the destination address field.
Aravind: Maybe we should not mandate where the SSRC should be in
Thomas:  Agreed
Magnus:  Agreed

Resolution:  Remove the text added to indicate where SSRC should go into 
the RTCP RR. Aravind will write up.

Bug 556295 - Client Issues PAUSE while server in READY state
------------------------------------------------------------
Thomas:  While server is in ready state, badly behaving client sets 
pause point to future time, what is the proper response?  Pause request 
without the range header, server sends 200 Ok.  If client does send the 
range header in the PAUSE request, what should be returned?
Rob:     Why not just return response with Range header of where the 
server paused?
Thomas:  If the client sends Range header for future time and server 
sends 200 OK while setting the range header, is that a wrong message to 
the client?  What if the client doesn't check the range response header?
Rob:     Contend that the Range header needs to be checked by client.
Magnus:  If this is a big issue, we not allow client to do PAUSE in READY.
Sean:    The client should be check range header in READY state.  It is 
really a corner case for client to send range in future.
Thomas:  Ok with that
Magnus:  Queueing pause in not in the spec?
Thomas:  Confusion if client doesn't check range header.
Aravind: All pause response must have a range header?  If the client 
requests a PAUSE in the future in the READY state, the server will 
respond 200K with the current pause point in the range header.

Resolution:  Ok to do PAUSE in ready state. Whether range header is 
included in the PAUSE request or not, the server will return 200 Ok.  
The range response header will be set to the current pause point (not to 
any other time requested in the PAUSE request).  Thomas will write up.

Bug 533691 & 513880
-------------------
Magnus:  Status?
Aravind: Just sent it out a couple of minutes ago.  Everyone should 
please review and send comments.  Essentially says that Range intervals 
always go from the first number to the second number.  For negative 
scale, ranges can be decreasing. Range is still half open.  Exception at 
0, where if 0 is the second point, it is closed.

New Things:
-----------

Bug 507882 - RTP timestamp and the effect of PAUSE.
---------------------------------------------------
Magnus:  Old bug.  But resolution is reached on email.  There will be a 
gap in the RTP timestamps space during the pause, that reflects realtime.
Magnus:  Need to add warning that some old servers may not behave this 
way with the gap in RTP timestamp.  Good example in Appendix B is 
needed.  Yves:    What is the outcome?  Where will it be clarified?
Magnus:  Will be in the next RTSP update
Aravind: Someone going to write this up?  I'll take it.

Resolution:  Aravind will write up the upshot of the mail and 
teleconference discussions as clarifications to the spec.

Bug 739845 - "a=range" is missing IANA registration and clear rules.
--------------------------------------------------------------------
Magnus:  No IANA registration for it.  Just need to write it up. ABNF 
should also include extension for new format types.
Magnus:  Multiple a=range allow?  May cause major incompatibilities?
Thomas:  Anyone tried to use it?
Magnus:  Probably not?
Thomas:  Should be disallowed?
Aravind: Specified anywhere?
Magnus:  That is the questions
Aravind: Will probably cause incompatibilities.
Magnus:  Need normative language on how ranges should be specified.
Magnus:  How about allowing multiple range specifications, NPT, SMPTE?
Rob:     Doubt any current implementations allow it, but that may not be 
the right way to approach it.
Thomas:  Different clients may prefer different specifications such as 
NPT, SMPTE, Clock
Magnus:  Clock not most common
Thomas:  SOme clients may not have the capability to understand certain 
formats.  Felxibility helps.
Magnus:  How do you specify?  Each person should consider how your own 
client deals with it? 
Resolution:
Needs more detailed write up and discussion on MMUSIC.  Magnus will 
write more detail about this to MMUSIC.

Bug 742328 - How to handle PLAY requests at end of a media clip
--------------------------------------------------------------
Magnus:  This came up with interop tests
Geetha:  The server can use wallclock time and use the range headers 
from the play request.
Magnus:  Play request may not have range header in the case of resuming 
from pause
Geetha:  Aren't all PLAY and PAUSE requests mandated to have range headers?
Aravind: Only responses are mandated to have range headers.
Magnus:  Use option B from bug report.  Send a 457 Invalid Range. 
Resolution:  The server sends a 457 (Invalid Range) including in the 
response the range header for the pause point. Magnus will write it up.

Bug 742348 - Usage of implicit REDIREDCT
----------------------------------------
Phillippe:  The first server may not be able to serve the stream but may 
be able to send the SDP.  Want to save SDP.  This issue came up in IMTC, 
3GPP interop.  Philippe:   Proposal, to send OK DESCRIBE response with 
URL for redirection.  Counter proposal to use the full URL in the 
REDIRECT response.
Thomas:     2326 tells that describe response should not use this.  
Philipple:  Why?
Thomas:     To prevent loops
Yves:       If you use it in the describe response, the client will send 
some SETUP request. What kind of loop will you have?
Rob:        Which bug are we talking about?
Yves:       Section 10.2 says discouraging use of redirect in DESCRIBE 
response.
Yves:       We try to minimize RTT.  We want to redirect.  Load 
balancing is a place that this is used.
Rob:        It's not about looping.  Its about making sure that the 
description and the serving was coupled.  If there are whole bunch of 
URLS in the response, makes the clients complex.  Yves:       Basically, 
are you saying that it is not recommended to have two different 
machines, one doing describe and one doing the streaming.
Rob:        Yes, the machine serving up the media should have a means of 
describing it.  Didn't want to get into the problmem of having URL in 
the response, and which points you to another server, when you have to 
do another describe to make sure it matches up.  There should be one 
normative source to do the description and one way of doing it.
Rob:        Concern is that we are adding another feature.  Need to test 
interoperability.
Yves:       You can do it with HTTP,  Get the SDP from using HTTP and 
then use the URLs in the SDP to do RTSP.  It is better to use RTSP 
response  to keep the mechanisms alinged.  Also not preferred to have 
URLs in SDP.
Rob:        Big concern is having yet another way to the same thing.
Magnus:     Load balancing doesnt seem like a good reason.  Aren't you 
hiding the multiple server with DNS level hiding.  Yves:       Can use 
Redirect to load balanceing.
Rob:        Done already
Yves:       But extra RTT.  The proposed soltuion will remove RTT.
Mangnus:    Maybe can use DNS load balancing to reduce RTT.
Yves:       Sometimes it takes more intimate knowledge about client. 
Addtional streaming service info in DESCRIBE can be useful.
Rob:        RTSP interoperabilty sucks.  If we solve that we can add 
some more features.
Yves:       The main problem is that the specification is not clear 
about error messages and some of these features.  What is the way foward?
Rob:        Please write up some text
Yves:       What is the process for discussing this more?
Magnus:     Write a proposal and discuss on MMUSIC.
Thomas:     This is starting to become more clear.  Can see advantanges 
of having the RTT reduced.
Rob:        An interesting thing that shouldn't be forced on every client.
Magnus:     Feature tag may be a way to go.
Thomas:     The feature tag may help also avoid DOS attacks.
Rob:        The problem is that the Onus is still on the client to use 
the feature tag and try the fall back, especially if the proxies and 
servers do not support the fall back.
Magnus:  Philippe:   A new client will be able to save 1 RTT.  An old 
client will get complete explict redirection.
Rob:        Clients and servers have to support base line capabiliy and 
this will be an optional optimization on top of that.
Philippe:   Baseline is explicit redirection.
Magnus:     Optimization in current spec or separate document?
Philippe:   Explict redirection is 3XX.  No information.  Then behavior 
is close to HTTP.
Philippe:   Optimization:  2XX with information. And feature tag.
Magnus:     SDP Content Location or Content Base?
Philippe:   Let's discuss this more on the mmusic
Magnus:     Separate document to do optimization
Philippe:   Will do separate document to do feature tag and optmization.
Magnus:     Also, Philippe, please clarify the information in current 
draft.  Not allowed to use Content-Base, Content-Location.  Should not 
use Session description to point to other places.  Minimum 
implementation of the client should only need to deal with content from 
the same server.

Resolution:  Philippe and Yves will write up a proposal for an optional 
feature of RTSP to allow redirection on the DESCRIBE response.  2XX will 
be used for the redirection.  It will be proposed as a separate document.
The base line will be specified in RTSP.  Will be 3XX without any 
information if stream or SDP cannot be served. Explicit redirection will 
be the baseline mode of operations.  Philippe and Yves will write up a 
clarification to the the current spec indicating the baseline and 
disallowing the use of Content-Location and Content-Base in the base 
line RTSP.

Other Issues:
-------------
Magnus:   Need to clean up the spec.  Don't have that much time in hand.
Aravind:  I can help.
Magnus:   Let's take it offline.
Aravind:  July 13-18th is the IETF
Magnus:   Submissions by 30th June
Magnus:   Tentative 16th of June for meeting

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