Subject: [MMUSIC] reason for teardown

From: "Saurabh Srivastava" <[email-masked]>
Date: Thu, 3 Jul 2003 20:05:31 +0530

Hi Folks,
      This is a requirement that would enable the streaming server to know that why a session is being closed from client and in turn, allow it to give guaranteed delivery service in pay-per-view scenarios.
 
TEARDOWN, which indiactes the end of the session can be sent from a client due to:-
1. The RTP channel indicating that the clip is over.
2. The user initiating the request to end the session.
3. Network problem due to which the client gets time-out.
 
What is the solution for this problem?
Should it be a header in the TEARDOWN request?
Or it should be inferred from data level protocol like RTP?
 
Regards,
Saurabh Srivastava
Pricipal Member Engineering
July Systems.

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 03 Jul 2003 17:14:38 +0200

Hi,

Do I understand you correctly that you would like to have some 
indication on why the client performed the TEARDOWN? If not can you 
please be more clear about what you desire.

I would also like to to point out certain things in your mail.

Saurabh Srivastava wrote:
> Hi Folks,
>       This is a requirement that would enable the streaming server to 
> know that why a session is being closed from client and in turn, allow 
> it to give guaranteed delivery service in pay-per-view scenarios.
>  

There is no explicit indication on that a clip is over. In streaming 
this is normally resolved at the client when it notices that the 
full-range has been played out. The client may also detect that delivery 
has stopped of RTP packets. To verify that this is not due to transport 
errors the client should look at the RTCP SR. However this method does 
not guarantee that a clip is really over, and not simply a part where no 
packets are delivered. For Live content this is basically very difficult 
unless other means indicate that the session has expired.

On possibility in RTSP to notify clients that the session is really over 
is to redirect the client to such a message. Introducing the message in 
the session for live content is also useful, at least for the user.

Normally the client will issue a TEARDOWN in this case when the user 
does not rewind the session or otherwise inactive for some period of 
time. In other words, the end of the clip does not automatically lead to 
a TEARDOWN request.

> 2. The user initiating the request to end the session.

Which is the case you receive a TEARDOWN.

> 3. Network problem due to which the client gets time-out.

In this case there will be no TEARDOWN request. The server side simply 
times out the session.

Best Regards

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]

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