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

From: Thomas Zeng <[email-masked]>
Date: Wed, 12 Nov 2003 13:05:26 -0800

Thanks for the comments. Two  important corrections, see inline.

> -----Original Message-----
> From: Aravind Narasimhan [mailto:[email-masked]]
> Sent: Wednesday, November 12, 2003 12:50 PM
> To: [email-masked]
> Subject: [MMUSIC] RTSP offline meeting Notes - 11/11
> 
> 
>   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.  
What I said was:   You don't need the whole SDP here, just an updated Range
plus Reason 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,
If a client is neither behind NAT/FW, nor dual-hosted, it should not have to
pay additional price (in terms of delay, at least).
> 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
> 

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