title: RTP/RTSP start up latency: Would this method help to reduce it, and if yes, why we don't have it
body: <p>This is probably not the best forum for such a specialized question, but at the moment I don't know of a better one (open to suggestions/recommendations).</p>
  
  <p>I work on a video product which for the last 10+ years has been using proprietary communications protocol (DCOM-based) to send the video across the network.  A while ago we recognized the need to standardize and currently are almost at a point of ripping out all that DCOM baggage and replacing it with a fully compliant RTP/RTSP client/server framework.</p>
  
  <p>One thing we noticed during testing over the last few months is that when we switch the client to use RTP/RTSP, there's a noticeable increase in start-up latency. The problem is that it's not us but RTSP.</p>
  
  <p>BEFORE (DCOM): we would send one DCOM command and before that command even returned back to the client, the server would already be sending video. -- total latency 1 RTT</p>
  
  <p>NOW (RTSP): This is the sequence of commands, each one being a separate network request: DESCRIBE, SETUP, SETUP, PLAY (assuming the session has audio and video) -- total of 4 RTTs.</p>
  
  <p>Works as designed - unfortunately it feels like a step backwards because prior user experience was actually better.</p>
  
  <p>Can this be improved? If you stay with the standard, short answer is, NO.  However, my team fully controls our entire RTP/RTSP stack and I've been thinking we could introduce a new RTSP command (without touching any of existing commands so we are still fully inter-operable) as a solution: DESCRIBE_SETUP_PLAY.</p>
  
  <p>We could send this one command, pass in types of streams interested in (typically, there's only one video and 0..1 audio). Response would include the full SDP text, as well as all the port information and just like before, server would start streaming instantly without waiting for anything else from the client.</p>
  
  <p>Would this work? any downside that I may not be seeing? I'm curious why this wasn't considered (or was dropped) from official spec, since latency even in local intranet is definitely noticeable.</p>