Subject: [MMUSIC] [ rtspspec-Bugs-810678 ] How to indicate end of media stream

From: "Matthew Heaney" <[email-masked]>
Date: Fri, 24 Oct 2003 15:36:29 -0400

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: Thursday, October 23, 2003 11:22 PM
> 
> Issue:  Possible methods for signalling end of
> stream/media (not session) in RTP.
> 
> 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.

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

---

From: Tom Marshall <[email-masked]>
Date: Fri, 24 Oct 2003 12:55:21 -0700

> until the client either explicitly issues a PAUSE request, or sends a

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...

-- 
Research is what I'm doing when I don't know what I'm doing.
        -- Wernher von Braun

---

From: Aaron Colwell <[email-masked]>
Date: Fri, 24 Oct 2003 13:44:42 -0700 (PDT)

The RealServer sends it's own end of stream APP packet over the RTCP 
channel. This packet contains the sequence number and timestamp of the 
last packet in the stream. The sequence number allows the client to know 
when it has received the last packet of the stream. This can help it 
avoid shutting down the stream early if the EOS packet happens to arrive 
before the last packet in the stream. This is not a common case, but it 
could happen.

I think the RealServer only sends five or less of the end of stream 
packets. I like the idea of periodically sending them until a PAUSE or 
TEARDOWN occurs. That seems like a better way to insure the client gets 
the packet.

Should this EOS packet be on the RTP or RTCP channel? Currently the 
RealServer uses the RTCP channel because it had a mechanism to allow 
extensions that would be ignored by clients that don't understand the 
packet. I don't think there a mechanism for putting this type of packet on 
the RTP channel.

Aaron

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 27 Oct 2003 10:45:40 +0100

Hi,

You having this discussion on a friday evening (my time) makes it kind 
of hard of give comments into the discussion :-). So I guess it falls on 
my lot to summarize and give comments on what I see as important 
considerations.

There are several possible solutions that all have advantages and 
drawbacks.

1. Using RTCP BYE
- bye sending a RTCP bye the server will signal that it is leaving the 
session with the indicated SSRC(s). As this is probably not the intended 
effect in many cases RTCP bye is not semantically correct.
- Killing the SSRC prevents the continues reporting of RTCP sender 
reports allowing a client not supporting the end of stream mechanism to 
detect that it is lost.
- The intention of RTCP BYE is to work as hint to help keeping the 
accurate group size, therefore it is not very robust. RTCP bye are only 
sent once and any receiver not getting it will time-out the source instead.

Personal comment: I am not in favour of using this mechanism.

2. Using an RTCP extension, APP or other
- By including SSRC and RTP sequence number of the last packet to be 
sent the server the RTCP packet can be sent both earlier and later than 
the transmission of the last RTP packet.
- Requires the usage of RTCP, which in my opinion in most cases is good. 
I know there might be use cases where RTCP may not be possible to use 
even from server to client(s).
- RTCP is not robust, message will be need to be repeated. Due to RTCP 
bandwidth limitation this might result in that it takes some time to get 
the message across.

3. Using the RTSP signalling channel with an END_OF_STREAM method.
- Sent in the RTSP signalling channel, so if TCP is used it is robust. 
Will get the message over as soon as TCP can transmit it. However due to 
packet losses this time is not bound, it might still arrive late.
- Is not RTP specific, through the usage of other transport protocols 
equivalent to RTP-Info they could inform what the last packet that 
belongs to the request is.
- Due to the use of RTSP signalling channel it may go through one or 
more proxies. Thus taking longer time than the media path.
- If the client drops the signalling connection it will not be possible 
to get over.
- One message will cover all streams in the same RTSP session.

4. Use a RTP extension.
This solution can either be implemented through a new RTP payload format 
including the necessary information, or through some RTP header extension.
- Will go in the media channel as media rather than signalling.
- Can't be sent in advance for certain media requiring continuos RTP 
sequence numbers if it requires its own packets.
- Is not robust will require that one either uses some type of ACKs and 
adaptive transmission of them or do a repetition accomplishing high 
enough delivery probability.
- The use of header extension would prevent other header extensions.
- The use of a payload format would either require its own RTP packet or 
  use of RFC 2198.

General comments:

- Please note that any end of stream indication will not be 100% 
reliable and guaranteed to arrive in time before the last packet arrives.

- Regarding messages from server to client. The client are not required 
to keep the TCP connection open, however it is strongly recommended. My 
intention with the current text around connections is that the protocol 
shall survive the loss of the signalling channel. That this allows for 
clients to close the TCP connection has to be accepted.

- Regarding the requirement about state transition as an indication. 
This is not suitable in all use cases. I think this mechanism if located 
in RTP/RTCP then it should work also for multicast. Thus one needs to 
look into the separate use cases.

I think we should further explore the pro and cons of proposal 2 to 4. 
Thus trying to decide what the desired solution is. There are probably 
further considerations that I have not yet thought of.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]