Subject: RE: [MMUSIC] reason for teardown

From: "Saurabh Srivastava" <[email-masked]>
Date: Fri, 4 Jul 2003 00:56:13 +0530

Hi,
    This is correct. My question is that I would like to have "some indication on why the client performed the TEARDOWN". It is more from the server perspective so that it can understand the nature of the request and then take appropriate action.
 
As far as the solutions are concerned for the problem, I have tried various things, but could not find a fool proof solution that would work in all conditions.
 
RTCP BYE as pointed out by Philippe is an indication from the server indicating that the session is over. And RR's keep indicating the reception quality from the client in the ideal scenario. But due to a possible delay in networks (specially wireless networks) there could be a scenario that the RR's do not reach the server in time and meanwhile the client times out (according to time-out settings on UA). In that case TEARDOWN arrives from client, and the server is unaware of the reason why it came.
 
RTCP BYE can be sent by the client to indicate that it is exiting from the session but there too the reason field is not mandatory (So left blank in most of the implementations :-)    ).
 
I believe, if the TEARDOWN contains this information also, then the server will perhaps be able to provide the support systems more information so that appropriate actions could be taken. More so because in most of the implementations RTSP would be implemented on TCP and RTP on UDP. And since this information becomes quite ciritical if end user's money is involved, RTSP would be a better channel to convey this information on account of a more reliable transport.
 
Regards,
waiting for comments,
 
Saurabh Srivastava

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 04 Jul 2003 16:32:21 +0200

Hi,

Comments inline

Saurabh Srivastava wrote:
> Hi,
>     This is correct. My question is that I would like to have "some 
> indication on why the client performed the TEARDOWN". It is more from 
> the server perspective so that it can understand the nature of the 
> request and then take appropriate action.
>  
> As far as the solutions are concerned for the problem, I have tried 
> various things, but could not find a fool proof solution that would work 
> in all conditions.
>  
> RTCP BYE as pointed out by Philippe is an indication from the server 
> indicating that the session is over. 

The RTCP BYE is sent when the RTP session is closed, this is normally 
done as a result of a RTSP TEARDOWN. RTCP BYE shall not be used to 
indicate the end of a media stream.

And RR's keep indicating the
> reception quality from the client in the ideal scenario. But due to a 
> possible delay in networks (specially wireless networks) there could be 
> a scenario that the RR's do not reach the server in time and meanwhile 
> the client times out (according to time-out settings on UA). In that 
> case TEARDOWN arrives from client, and the server is unaware of the 
> reason why it came.

In a streaming server -> client scenario the server will mostly be 
sending Sender reports, when not active sending media it will switch to 
RRs after a few reporting interval, normally 2. If any RTCP bandwidth is 
  assigned to the session, the limiting factor in a point to point case 
is the 5 second minimal rule. This means that RTCP packet will at most 
be sent from each end every 7.5 seconds. The default RTSP session 
time-out is 60 seconds, that means that it will be time for at least 8 
RTCP packet. This means that the probability to all be lost is very 
small. Therefore a server should not time out a client unnecessary. And 
when a server times out a client no TEARDOWN request is sent from the 
client or server. The server simply removes the session.

When it comes to client side time outs they must be reasonably set. They 
must allow for some transport problems. And a client would not time out 
a session while it receives media. And I don't see a reason for timing 
out the session very quickly even if no media is received. One must also 
give the user time to react to the end of the clip. Therefore I would 
not recommend such a timer to be shorter than 30 seconds.

>  
> RTCP BYE can be sent by the client to indicate that it is exiting from 
> the session but there too the reason field is not mandatory (So left 
> blank in most of the implementations :-)    ).

Yes, reasons field is seldom used. Also the RTCP bye is normally only 
sent once, therefore has high probability to become lost.

>  
> I believe, if the TEARDOWN contains this information also, then the 
> server will perhaps be able to provide the support systems more 
> information so that appropriate actions could be taken. More so because 
> in most of the implementations RTSP would be implemented on TCP and RTP 
> on UDP. And since this information becomes quite ciritical if end user's 
> money is involved, RTSP would be a better channel to convey this 
> information on account of a more reliable transport.
>  

When it comes to sending charging related information in protocols from 
the client I have a view that this is difficult. The most normal problem 
is how to avoid fraud. If a client can implement in the teardown a 
reason which will mean that the user doesn't have to pay, it will be 
exploited.

Could you please further elaborate on what the different cases you want 
to distinguish are? I have some trouble seeing how different TEARDOWN 
reasons will have impact.

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