Subject: [MMUSIC] Signaling End of media Stream in RTSP

From: "Desineni, Harikishan" <[email-masked]>
Date: Thu, 12 Apr 2007 19:56:23 -0700

I heard that this topic was discussed long time ago. 
 
I strongly felt the need for such a feature when doing VOD streaming of
clips with unequal track durations. I am curious to know if the
END_OF_STREAM<Track id, Seq No, TS> has been proposed on the control
path (RTSP). Another choice is RTCP BYE in the media path may not work
if RTCP BYE is dropped over unreliable UDP. 
 
Using END_OF_STREAM (in S->C direction), it is also important to know
the <last Seq no, Timestamp> to detect how much track duration is left
for a given media stream. This would avoid depending on the wrong range
header information in the SDP (many servers screw up range header values
in SDP).
 
Would like to know if there was any standards work performed since the
time this discussion started in the past and what was the outcome?

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

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 13 Apr 2007 11:05:26 +0200

There is the now expired WG draft on this:

http://tools.ietf.org/html/draft-ietf-mmusic-rtsp-announce-01

/Magnus

Desineni, Harikishan skrev:
>  I strongly felt the need for such a feature when doing VOD streaming of clips with unequal track durations. I am curious to know if the END_OF_STREAM<Track id, Seq No, TS> has been proposed on the control path (RTSP). Another choice is RTCP BYE in the media path may not work if RTCP BYE is dropped over unreliable UDP.    
> 
>      
> 
>  Using END_OF_STREAM (in S->C direction), it is also important to know the <last Seq no, Timestamp> to detect how much track duration is left for a given media stream. This would avoid depending on the wrong range header information in the SDP (many servers screw up range header values in SDP).   
> 
>      
> 
>  Would like to know if there was any standards work performed since the time this discussion started in the past and what was the outcome?   
> 
>  
> 
> 
> ------------------------------------------------------------------------
> 

-- 

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 13 Apr 2007 11:12:12 +0200

(As individual contributor)

I forgot to comment a thing about the email.

Desineni, Harikishan skrev:
>  I strongly felt the need for such a feature when doing 
> VOD streaming of clips with unequal track durations. I am 
> curious to know if the END_OF_STREAM<Track id, Seq No, TS>
> has been proposed on the control path (RTSP). Another 
 > choice is RTCP BYE in the media path may not work if
 > RTCP BYE is dropped over unreliable UDP.

RTCP BYE is definitely the wrong tool for this. The semantics for RTCP 
BYE means that a receiver should mark the SSRC as leaving the session. 
This would mean that if the client request another play on the same 
stream the server should use a new SSRC. Thus resulting in the loss of 
all synchronization information between streams. Needing to re-establish 
this. If the server doesn't chose a new SSRC (more likely) then a client 
can interpret this as being late packet for a source having left. It may 
also screw around with the SSRC collision rules.

Cheers

Magnus Westerlund

---

From: "Desineni, Harikishan" <[email-masked]>
Date: Fri, 13 Apr 2007 16:25:06 -0700

Magnus,

I agree that RTCP BYE is not the correct tool to solve this problem. The
solution proposed in the draft appears to be in correct direction. Any
reason why the draft did not progress? Was it purely due to author's
lack of interest to move it forward or any other technical reasons? 

Does RTSP 2.0 provide any support to solve this problem?

Thanks,
Hari

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Friday, April 13, 2007 2:12 AM
> To: Desineni, Harikishan
> Cc: [email-masked]
> Subject: Re: [MMUSIC] Signaling End of media Stream in RTSP
>

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 16 Apr 2007 10:14:49 +0200

> lack of interest to move it forward or any other technical reasons?

To my knowledge this is part of the lack of interest in RTSP 
standardization work. Which I think come around for two reasons. 1) our 
failure to conclude RTSP 2.0 and 2) the fact that a number of active 
people changed positions and moved into other work areas.

> Does RTSP 2.0 provide any support to solve this problem?

No, I at least was expecting that the WG draft would provide that 
solution for RTSP 2.0. All MMUSIC WG's RTSP extensions has been based on 
RTSP 2.0 due to the problem of not having a spec that one could really 
trust for RTSP 1.0.

Cheers

Magnus Westerlund