Subject: [MMUSIC] RTSP offline meeting Notes - 11/11

From: Aravind Narasimhan <[email-masked]>
Date: Wed, 12 Nov 2003 14:49:46 -0600

The meeting followed the agenda that Magnus sent out on 11/10

Attendees:

Thomas Zeng,
Henning Schulzerine
Geetha Srikantan
Victor Varsa
Sean Sheedy
Adrea Basso
Magnus Westerlund
Colin Perkins
Aravind Narasimhan

Issues:

2A. RTP Timestamps under pause clarification. 
- Aravind to write up text  - Not Done.  Hopefully by the end of week.

2B. PLAY request at the end of a media clip
- Awaiting review

2C. Implicit Redirect
- Philippe/Aravind to write up text?

2D. Aggregate URL deriving
- Awaiting review. 
- HS:  Is there motivation for deriving the URL?  It should be opaque?  
I can't use for something else?
- TZ:  It might conflict with an actual URL?
- HS:  Seems like a recipie for strange cases.
- TZ:  SDP from two different sources that you want to mix.
- HS:  The server should give you the URL.  If the SDP doesn't have an 
aggregate URL than the media can't be played in aggregate fashion.
- HS:  Concerned about specifying generating URL.  How do you know what 
you are getting?  What if it is not there?
- TZ:  Have SETUP two separate streams.  Need to control together. 
Session ID should be enough, but URL is needed for PLAY request.
- AN:  URL is used for proxies and accounting.
- CP:  State explicitly what needs to be done.
- HS:  Server needs to accept the need to do it.
- CP:  Imposing rules on URL is hard.  Nontraditional URIs.  What do you do.
- HS:  Toss this feature and verbiage from the spec. because it is hard 
to specify.
- MW:  Leave it as open issue.  See if Tom has issue.  But will remove 
from spec if no objections.
Conclusion:  Hard feature to specify.  We should not try to do it 
because we will do a poor job of it.  Will remove from spec if no 
objections.

2E:  A=range in SDP indicates live media
- HS:  An undefined range means there is no defined a range forward or back.
- GS:  How about RTP-Info.  Does it go away?
- MW:  You need RTP-Info
- AN:  Server does not know NPT.  Can't generate it in many cases.
- HS:  How do you do Tivo like model?
- HS:  From whereever you started recording to now.
- CP:  It's not quite that simple.  You can play past the pause point 
because the Tivo is still recording.
- HS:  Dont' want to break the spec.  Don't want to label things. 
Because you may have part live and part not live.
- MW:  Two aspects.  We need something new, but we can't break range.
- HS:  If range abs time doesnt support this model.
- HS:  If you use UTC, then you know if you are asking for a time 
tomorrow then it is live.
- CP:  How about clock skew.
- HS:  If we can do time till now, it works with the Tivo Case.
- TZ:  If you say UTC -, then the slider size is going to be hard to 
determine.
- HS:  a user interface issue.
Conclusion: 
  + In the SDP range if there is an open range, then it is live. We need 
to check the Tivo case is supported
  + Need Live media defintion: media with out a defined end point during 
playback.
  + SDP is referencing RTSP for range format.  Need to register with IANA.

2.F  REDIRECT with Connetion close:
- MW:  Normally connection is closed by the client.  The server may 
close the connection after 200k is recieved.
- TZ:  a bit rude bit its fine.
Conclusion:  Server MAY drop the connection after it has recieved 200 OK 
response on a REDIRECT.

2G.  End of Stream
- TZ:  Need a persistant connection
- MW:  Is there a usecase in SIP for End of playout notification?
- HS:  There Is media level, application level and , session level
- HS:  It is hard to dectect the last packet stream.  Technically hard.
- HS:  What is the use case for needing end of stream in the RTP/RTCP?  
End of segment/ End of stream is it a more generic problem?
- TZ:  This is more like an event.
- HS:  DTMF-AD  was trying to signal time synchornized notification.  
Not universally popular.
- TZ:  Not event registration frame work.  Is something like SIP event 
framework overkill?
- AN:  The client in RTSP doesnt know the media has ended if you play 
Range -
- TZ:  Also for live.
- AN:  but the live server doesnt know when the range ends
- HS:  How about send an announce with the new SDP that stream's end 
range has changed?
- HS:  How about BYE
- TZ:  Don't wnat to do BYE because it gets rid of the SSRC and you want 
to keep RTCP reporting.
- TZ:  Also want to report error
- HS:  Make that generic.  Is the consumer a machine or is it for human 
user?
- AN:  Once persistence is established you can add all kinds of server 
reporting features.
- SS:  Almost always it will be a machine that will consume the error 
information.
- TZ:  A more generic framework for header that can be in end of stream 
and in Announce.
- HS:  Use Announce to send the SDP with the new range header
- TZ:  You dont need the whole range header.  You alredy have have SDP.
- HS:  You have a trade of with efficiently and future supoprt.  Try to 
overly optimize is not a good idea.
- AN:  No reason why RTCP can't say end of stream as a separate thing.
- HS:  Yes.  But keep it separarte and have AVT work on it.
- MW:  Use ANNOUNCE.  to do this.  Revivie Sean's old spec.
Conclusion:  Keep the end of stream messages in the control channel 
rather than the data chanel. TZ will take ownership.
- Keep the idea of server trying to start a coneection with client as a 
separate issue.

2H.  How long to wait for response?
- SS:  5 Seconds?
- HS:  10 times longer than SIP.
- SS:  This is RTSP over TCP.  UDP is lot longer
- HS:  100 is a indication that it will succeed.  You want to send it 
early rather than later.  So 5 seconds may be too long.
- TS:  The first 100 response is easy.  Do we need to send it periodically.
- HS:  There is a reasons to send useful feedback, but do we need to 
send more than that.
- HS:  Should not be mandated
- AN:  Server MAY / SHOULD send 100, but client MUST deal with it.
- CP:  If the server knows its going to take appreciable amount of time, 
send 100 immediately (less than 2 seconds).
- TZ:  Sean's proposal is reasonable.
- CP:  If the server should send in a "couple" of seconds.
- CP:  It's hard to place a time limit.
- TZ:  Implementor's guide.
- HS:  Not a good idea because it's hard to do, and may contradict the spec.
- TZ:  Provide some motivation example.
Conclusion:  Sean's writeup seems reasonable.  Change the timelimit to 2 
seconds and make sure that wording is there to indicate server should do 
this immediately if it know it's going to take a long time.  Need 
motivation example.

2I.  Version number of new spec
- MW: will try to make it 1.0
- HS: Protocols don't generally get a second chance
- HS: If you want to go with a new protocol version than get some better 
features.
- TZ: There are servers out there that wont interop.
- CP: Document where the potential interop problems will be.
- AN: We will be hard pressed to keep the current version number.  But 
let's see after the change spec is done.
 
2J.  Teardown * and Ready-nm
- Removed from spec. Awaiting WG review

2K.  How to handle sync in re-SETUP
- Awaiting review from the WG.
- Need to look at the level of mandate for RTP-Info in live case.

2L.  Re-Setup of Transport parameters
- GS:  Not to unicast -> multicast. 
- HS:  May want to switch from multicast to unicast. . .
- MW:  Take to list.

2M.  Removal of SETUP in play state
- Removed from spec.
- CP:  Keep it unspecified rather then saying that it cannot be done.  
That breaks being able to do that in the future.
- AN:  Explicitly state that it is unspecified instead of cant be done.
Conclusion:  Remove but state that it is unspecified and a new draft 
needs to be writted to make it work.

2N.  Use of c= in SDP to know possible address classes
- CP: It is reasonable to connet to the server with one protocol and use 
a different protocol for the media.
- TZ: Is it reasonable to have two, (one for IPv4, and one for IPv6).
- CP: You can specify alternatives.
- MW: 3338+gonzolo. Use the alt group thing.

Conclusion:
Should look at address classes in the SDP to figure what protocol to use 
(need to add SDP section of RTSP)
Look at c= line syntax.  Multiple c lines can be use in media field?  
SIP resolution was that multiple c lines should not be used to express 
multiple connection address.

2O.  How should proxies cache?  OPTIONS. 
Conclusion:
Caching dropped.  make it explicitly unspecified in the spec.

3A.  ABNF should be moved to end. 
- HS:  Difficult problem with SIP spec is that the when the semantic  
description is given, it should reference ABNF name.
- CP:  IETF has tools as well has henning.

3B.  . . .

4.  How to do RTSP over NAT?

NAT Requirements? 
Priorities:
 1. Server is deployed in open network.
 2. Server behind firewall next.
 3. If a client is not dual hosted, it should not have to deal with 
additional protocols.
 4. Must have defense against DOS
 5. Security.
 6. MUST deal with symmetric nat.
 7. ALG.  The firewall traversal should not interfere with ALGs. 
 8. Advise to ALG writers not to screw it up.  

Aravind

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

---

From: Tom Marshall <[email-masked]>
Date: Wed, 12 Nov 2003 13:40:30 -0800

> because we will do a poor job of it.  Will remove from spec if no 

I don't have any objection either way here.  It would be nice if we could
provide a recommendation to make this work but if not, it's not a big deal. 
There is no real-world use case as far as I can tell.  My theoretical use
case (playing audio from one file and video from another) is not supported
by our server.  If a use case pops up, the implementor can deal with it.

> - Keep the idea of server trying to start a coneection with client as a 

If we take an END_OF_STREAM proposal, I think it should be an extension
signalled by a feature tag.  I believe this is a deficiency in the RTP
transport and we should bring the issue up in AVT.  We have heard from
someone that has implemented a transport level stream end notification so we
know that it's both possible and deployed.  We also know that END_OF_STREAM
has issues with connectionless control that a transport solution does not.

> this immediately if it know it's going to take a long time.  Need 

Please see my message from a few minutes ago.  I don't think RTT
measurements are meaningful.  In addition to being unaware of the physical
layer and TCP retransmission delays, this proposal makes it clear that
servers have real and occasionally significant processing delays.  This
makes any RTT measurement extremely unreliable.  I think that we should drop
the RTT measurements and focus on the actual issue, which is total delay
seen by the client.

I have implementation concerns with using 100 responses on the server side. 
As an example, our server is highly asynchronous.  It does nonblocking reads
and writes on all I/O, including files.  Further, complex datatypes (such as
mpeg4) require quite a few read/seek operations to formulate an SDP for the
DESCRIBE response.  Now suppose the server is busy.  Really busy.  It's
taking, say, 100ms or so to process all of its events each time through its
main event loop.  The server doesn't know how long it is going to take to
formulate the SDP because it doesn't know exactly how many reads it will
take.  And to make matters worse, sending 100 responses both generates more
network traffic and more event traffic (you need to set a timer so that you
know when the response is taking too long).  It may even make the difference
between handling the requests and failing.  Is sending one or more 100
responses really the best thing to do in this situation?

-- 
Most people are too busy to have time for anything important.

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 12 Nov 2003 23:11:28 +0100

Hi,

some comments, removing any sections without comments:

Aravind Narasimhan wrote:

> Conclusion:  + In the SDP range if there is an open range, then it is 
> live. We need to check the Tivo case is supported
>  + Need Live media defintion: media with out a defined end point 
> during playback.

I think that we had a conclusion to write a informative note about TIVO 
scenario signalling using large future values. The question is how this 
relates to the range limitations and what happens when a client asks for 
a futuer point. As I can see it the server can answer with what it 
actually will play out.

> - HS:  What is the use case for needing end of stream in the 
> RTP/RTCP?  End of segment/ End of stream is it a more generic problem?
> - TZ:  Don't wnat to do BYE because it gets rid of the SSRC and you 
> want to keep RTCP reporting.
> - HS:  Make that generic.  Is the consumer a machine or is it for 
> human user?
> - TZ:  A more generic framework for header that can be in end of 
> stream and in Announce.
> - HS:  You have a trade of with efficiently and future supoprt.  Try 
> to overly optimize is not a good idea.
> - Keep the idea of server trying to start a coneection with client as 
> a separate issue.
>
> - CP:  If the server knows its going to take appreciable amount of 
> time, send 100 immediately (less than 2 seconds).
> Conclusion:  Sean's writeup seems reasonable.  Change the timelimit to 
> 2 seconds and make sure that wording is there to indicate server 
> should do this immediately if it know it's going to take a long time.  
> Need motivation example.

I think we ad more discussion in the direction that we don't need exact 
rules for clients on how long they should wait, rather clarify why the 
client should wait sufficently long.

> - HS: If you want to go with a new protocol version than get some 
> better features.

I think the hennings important comments, that a solution if one creates 
non-interoperable changes to document them and explain how to support 
them, but clearly show that they are deprecated and can be removed at a 
later stage when old implementation has been upgraded.

> 3B.  . . . 

This will be included due to 2N.

Cheers

Magnus