Subject: RE: [MMUSIC] [ rtspspec-Bugs-810678 ] How to indicate end of medi a stream

From: Thomas Zeng <[email-masked]>
Date: Fri, 24 Oct 2003 13:39:54 -0700

my comments embedded.

-----Original Message-----
From: Tom Marshall [mailto:[email-masked]]
Sent: Friday, October 24, 2003 12:55 PM
To: Matthew Heaney
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: Re: [MMUSIC] [ rtspspec-Bugs-810678 ] How to indicate end of
media stream

> > Discussion: Need to signal that a stream/media has
> > ended exist mostly in unbound sessions. Proposal
> > brought up to indicate this is RTCP BYE when the sender
> > stops sending and has waited some time it can remove
> > the SSRC of that source and send the BYE to indicate
> > this. Another proposal was to send this information in
> > RTSP methods. One could use sever to client TEARDOWN to 
> > indicate this session really are over, nothing more can be 
> > done. PAUSE can be sent when the media has been served but 
> > the client may rewind do other operations. The TEARDOWN idea 
> > was not liked as certain applications require session data to 
> > be sent from client to server using SET_PARAMETER. A new 
> > method should be evaluated. There might also exist 
> > significant synchronization problems in this.
> > 
> > Resolution: Propose a RTSP extension with a new method.
> > Thomas Zeng to write strawman proposal for evaluation
> > to mailing list.
> 
> 
> We do this already in TrueCast using a special RTP header extension
> word.
> 
> The RTSP spec says that when the play request has completed, you're
> supposed to automatically transition to the paused state, per RFC 2326
> 10.5 (p. 35).  However, this doesn't really work, because it's
> impossible for a client to know which frame corresponds to the endpoint
> of the Range header of the PLAY response.
> 
> In other words, if the client sees a delay in the receipt of a frame, it
> can't know whether this is because of a server issue, a network issue,
> or just that there are no more frames coming.
> 
> So what we do instead is to send a special end-of-stream RTP packet,
> containing a single header extension word, once we've sent all the
> frames in the range specified in the original PLAY request.  We remain
> in the PLAY state, and continue to send the special packet every 100ms,
> until the client either explicitly issues a PAUSE request, or sends a
> TEARDOWN.

[tz] Just curious: why not send BYE every 100 ms instead of a special
packet? Is it because
     RTCP channel may not be allocated?

We also have an end-of-stream packet for our RDT transport.  I'm not sure
what we do with RTP but I can check if you're interested.

It seems logical to me that this be communicated over the transport channel,
not the control channel.  A simple RTP extension like you mention would make
a great proposal.  Obviously not everyone here shares that view though...
[tz] A special RTP packet would work, provided re-transmission mechanism is 
     in place for RTP over UDP. It is also required for each track. For an 
     RTSP session with many tracks, it is not elegant not being able to 
     signal end-of-stream for the aggregate session.

     Also if the transport is not RTP, what do we do?  I don't think 
     RTSP is tied to using RTP as transport, for example REAL uses RDT as 
     transport.  
     So if RTSP does not provide end-of-stream signalling, every potential
     transport would have to reinvent the wheel.

     Therefore I still think that although both RTSP end-of-stream
signalling and special
     RTP extension can solve the problem, RTSP end-of-stream is more
succinct and more
     "re-usable".  The drawback, of course, is that RTSP end-of-stream
requires persistent
     RTSP connection.
-- 
Research is what I'm doing when I don't know what I'm doing.
        -- Wernher von Braun

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

---

From: Tom Marshall <[email-masked]>
Date: Fri, 24 Oct 2003 14:03:05 -0700

>      RTCP channel may not be allocated?

My understanding is that if you send BYE, the RTP session is closed.  The
player should be allowed to continue using the session with another PLAY
request.

>      signal end-of-stream for the aggregate session.

Why is this not elegant?  It keeps transport signalling in the transport and
control signalling in the control channel.  I think mixing them is less
elegant.

In my experience, the tracks don't always end at exactly the same time
anyway (though they are usually well within one second of each other).

>      transport would have to reinvent the wheel.

That should be the least of the transport inventors' worries.  It just
slipped by in RTP because RTP was invented primarily for multicast live and
predates RTSP by a couple of years.

>      "re-usable".  The drawback, of course, is that RTSP end-of-stream

I thought the current spec was steering us away from persistent connections? 
Requiring a persistent connection to properly receive an end-of-stream
notification seems to be a step backward.

-- 
To use violence is to already be defeated.
        -- Chinese proverb