Subject: [MMUSIC] RTSP: a comment on section 11.9 of draft-ietf-mmusic-rfc2326bis-13

From: Kylin Wei <[email-masked]>
Date: Fri, 28 Jul 2006 11:33:56 +0800

Hi:

I have a comment on section 11.9 of draft-ietf-mmusic-rfc2326bis-13.

Section 11.9 If the OPTIONAL Range header is included in a REDIRECT request,
it indicates when the redirection takes effect....When the indicated
redirect point is reached, a client MUST issue a TEARDOWN request and SHOULD
close the signaling connection after receiving a 2xx response. 
Even though a client sending a TEARDOWN request is helpful to state
handling, I think that it's insignificant and inefficient. The server had
reported this event to the client and had received the client's
acknowledgement. So the server should close signaling connection forwardly
without the client's request when the indicated redirect point is reached.
So does the client. This approach can increase efficiency and avoid that the
client may not send TEARDOWN request on time. Such as a malfeasant client
doesn't want to send a TEARDOWN request when the indicated redirect point is
reached.

I suggest that four paragraphs of section 11.9 should be changed to two
paragraphs as follow.

   If the OPTIONAL Range header is included in a REDIRECT request, it
   indicates when the redirection takes effect.  The range value MUST be
   an open ended single value, e.g. npt=59-, indicating the play out
   time when redirection SHALL occur.  Alternatively, a range with a
   time= parameter indicates the wall clock time by when the redirection
   MUST take place. When the time= parameter is present in the range,
   any range value MUST be ignored even though it MUST be syntactically
   correct. To allow a client to determine that redirect time without
   being time synchronized with the server, the server SHALL include a
   Date header in the request. When the indicated redirect point is
   reached, a server MUST terminate the session or transport connection
without sending any report to client. So does the client.        

   After a REDIRECT request has been processed, a client that wants to
   continue to send or receive media for the resource identified by the
   Request-URI will have to establish a new session with the designated
   host. If the URI given in the Location header is a valid resource
   URI, a client SHOULD issue a DESCRIBE request for the URI.

Kylin Wei 

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

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 28 Jul 2006 11:28:25 +0200

Hi Kylin,

I think it is important to consider the proxies in these cases and their 
states. As they are not necessarily on the media path they may not be 
fully aware of the media playout time and when the session will terminate.

I think I am supporting your idea on how to resolve this. However I 
think I would like to make an addition to it. To me the main purpose of 
the range header is to give the client some time to setup a new session 
and minimize the impact on the media playback by the change. Thus the 
most likely timespan a server would continue to server the media is in 
the order of seconds, like 5 to 10. Maybe we should clarify this and 
also separate out the functionalities provided with the range header. I 
think there is some semantic overload here.

A. So lets change the usage of the range header to indicate the media 
playback point at the time of the REDIRECT request was sent. Do not use 
"time" parameter at all.

B. Create a new header (Termination-Time) that indicates the amount of 
continued service the client will receive before the server removes all 
state after the REDIRECT request was sent. This would indicate the time 
in the DATE format. This header could also include the possibility to 
indicate "upon answer" and be used in the response to indicate that this 
is what the client desires.

C. Mandate the inclusion of the DATE header to indicate when the request 
was sent.

D. Adopt to always perform automatic termination of sessions after 
REDIRECT as Kylin proposes at the Termination-Time.

I think this will provide a better set of functionality that will be 
easier to implement, do work for proxies. It can also be made clear that 
the client should re-establish as soon as possible with the new server. 
It may use TEARDOWN to stop the media delivery prior to the 
Termination-Time to avoid the reception of two simultaneous media streams.

The removing of the overload of the "Range" header will allow the client 
to receive a clear indication on where the server currently thinks it is.

Please comment

Magnus

-- 

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]

---

From: Kylin Wei <[email-masked]>
Date: Sat, 29 Jul 2006 11:44:11 +0800

Hi Magnus:

> to receive a clear indication on where the server currently thinks it is.

I agree with your above opinions. They are useful. 
But I think there is likely to a problem existed on the case that a
malfeasant client refuses to respond to a REDIRECT request. Such as a server
use Termination-Time to indicate that serve will terminate this session
after 7 seconds. How long should a serve wait before terminating this
session if the client refuses to respond this request? It should wait at
least 10 seconds for a response referring to section 9.4 or it should wait 7
seconds referring to Termination-Time header field value? 

Thank you.

Kylin Wei 
> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Friday, July 28, 2006 5:28 PM
> To: Kylin Wei
> Cc: [email-masked]
> Subject: Re: [MMUSIC] RTSP: a comment on section 11.9
> ofdraft-ietf-mmusic-rfc2326bis-13
> 
> Hi Kylin,
> 
> > doesn't want to send a TEARDOWN request when the indicated redirect
point
> is