Subject: Re: [MMUSIC] RTSP: Server killing the session in ready state depiste keep-alives:

From: Magnus Westerlund <[email-masked]>
Date: Wed, 04 Mar 2009 14:38:48 +0100

Hi,

I have made an attempt to clarify this whole issue in the draft. Please
comment on the main changes here.

Cheers

Magnus

New section 2.5:

2.5.  Session Maintenance and Termination

   The session context that has been established is kept alive by having
   the client show liveness.  This is done in two main ways:

   o  Media transport protocol keep-alives.  RTCP is possible to use
      when using RTP.

   o  Any RTSP request referencing the session context.

   If the client fails to show liveness for more than the established
   session timeout value (normally 60 seconds) the server may terminate
   the context.  Other values may be selected by the server through the
   inclusion of the timeout parameter in the session header.

   The session context is normally terminated by the client by sending a
   TEARDOWN request to the server referencing the aggregated control
   URI.  An individual media resource can be removed from a session
   context by a TEARDOWN request referencing that particular media
   resource.  And if all media resources are removed from a session
   context the session context is also terminated.

   A client may keep the session alive indefinitely if allowed by the
   server, however it is recommend to release the session context when
   extended periods of time without media delivery activity has passed.
   It can re-establish the session context if required later.  One issue
   is that what is extended periods of time is dependent on the server
   and its usage.  Becuase of that it is recommended that the client
   terminate the session before 10*times the session timout value has
   passed.  A server may terminate the session after one session timeout
   period without any client activitity beyond keep-alive.  When a
   server terminates the session context it does that by sending a
   REDIRECT request indicating the reason why.

   A server can also request that the client tear down the session and
   re-establish it at an alternative server when needed for maintaince
   by using the REDIRECT method.  The Range and Redirect-Reason header
   is used to indicate when and why.  The Location header indicates
   where it should connect if there are an alternative server available.

-- Changes to the REDIRECT method description --

13.10.  REDIRECT

   The REDIRECT method is issued by a server to inform a client that the
   service provided will be terminated.  This happens for different
   reason.  One is that the server is being adminstrated such that it
   must stop providing server.  Thus the client is required to connect
   to another server location to access the resource indicated by the
   Request-URI.  The second reason is that the client has been inactive
   in an established RTSP session for such an extended period in time
   that the server like to recover the resources.

   The REDIRECT request SHALL contain a Redirect-Reson header
   (Section 16.39) to inform the client of the reason for the request.
   Additional parameters related to the reason may also be included.

13.10.1.  Server Administration

   The intention here is to allow an server administrator to do a
   controlled shutdown of the RTSP server.  That requires sufficient
   time to inform all entities having associated state with the server
   and for them too perform a controlled migration from this server to a
   fallback one if available.

   A REDIRECT request with a Session header has end-to-end (i.e. server
   to client) scope and applies only to the given session.  Any
   intervening proxies SHOULD NOT disconnect the control channel while
   there are other remaining end-to-end sessions.  The OPTIONAL Location
   header, if included in such a request, MUST contain a complete
   absolute URI pointing to the resource to which the client SHOULD
   reconnect.  Specifically, the Location MUST NOT contain just the host
   and port.  A client may receive a REDIRECT request with a Session
   header, if and only if, an end-to-end session has been established.

   A client may receive a REDIRECT request without a Session header at
   any time when it has communication or a connection established with a
   server.  The scope of such a request is limited to the next-hop (i.e.
   the RTSP agent in direct communication with the server) and applies,
   as well, to the control connection between the next-hop RTSP agent
   and the server.  A REDIRECT request without a Session header
   indicates that all sessions and pending requests being managed via
   the control connection MUST be redirected.  The OPTIONAL Location
   header, if included in such a request, SHOULD contain an absolute URI
   with only the host address and the OPTIONAL port number of the server
   to which the RTSP agent SHOULD reconnect.  Any intervening proxies
   SHOULD do all of the following in the order listed:

   1.  respond to the REDIRECT request

   2.  disconnect the control channel from the requesting server

   3.  connect to the server at the given host address

   4.  pass the REDIRECT request to each applicable client (typically
       those clients with an active session or an unanswered request)

      Note: The proxy is responsible for accepting REDIRECT responses
      from its clients; these responses MUST NOT be passed on to either
      the original server or the redirected server.

   The lack of a Location header in any REDIRECT request is indicative
   of the server no longer being able to fulfill the current request and
   having no alternatives for the client to continue with its normal
   operation.  It is akin to a server initiated TEARDOWN that applies
   both to sessions as well as the general connection associated with
   that client.  The server MAY include the user-msg parameter to
   provide information about the server and for example when maintence
   is expected to have completed.

   When no Range header nor the Redirect-Reason "time" parameter are
   included in a REDIRECT request, the client SHOULD perform the
   redirection immediately and return a response to the server.  The
   server can consider the session as terminated and can free any
   associated state after it receives the successful (2xx) response.
   The server MAY close the signalling connection upon receiving the
   response and the client SHOULD close the signalling connection after
   sending the 2xx response.  The exception to this is when the client
   has several sessions on the server being managed by the given
   signalling connection.  In this case, the client SHOULD close the
   connection when it has received and responded to REDIRECT requests
   for all the sessions managed by the signalling connection.

   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 MUST occur.  Alternatively, the Redirect-Reason
   header MAY include the "time" parameter to indicate the wall clock
   time by when the redirection MUST have take place.  To allow a client
   to determine that redirect time without being time synchronized with
   the server, the server MUST include a Date header in the request.
   When the indicated redirect point is reached, a client MUST issue a
   TEARDOWN request and SHOULD close the signalling connection after
   receiving a 2xx response.  The normal connection considerations apply
   for the server.

      The differentiation of REDIRECT requests with and without range
      header is to allow for clear and explicit state handling.  As the
      state in the server needs to be kept until the point of
      redirection, the handling becomes more clear if the client is
      required to TEARDOWN the session at the redirect point.

   If the REDIRECT request times out following the rules in Section 10.4
   the server MAY terminate the session or transport connection that
   would be redirected by the request.  This is a safeguard against
   misbehaving clients that refuses to respond to a REDIRECT request.
   That should not provide any benefit.

   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.

      Note: The media resource indicated by the Location header can be
      identical, slightly different or totally different.  This is the
      reason why a new DESCRIBE request SHOULD be issued.

   If the Location header contains only a host address, the client MAY
   assume that the media on the new server is identical to the media on
   the old server, i.e. all media configuration information from the old
   session is still valid except for the host address.  However the
   usage of conditional SETUP using MTag identifiers are RECOMMENDED to
   verify the assumption.

   This example request redirects traffic for this session to the new
   server at the given absolute time:

     S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/2.0
           CSeq: 732
           Location: rtsp://s2.example.com:8001
           Redirect-Reason: Server-Admin ;time=19960213T143205Z
           Session: uZ3ci0K+Ld-M
           Date: Thu, 13 Feb 1996 14:30:43 GMT

     C->S: RTSP/2.0 200 OK
           CSeq: 732
           User-Agent: PhonyClient/1.2

13.10.2.  Session Timeout

   When a RTSP client has maintained a RTSP session that otherwise is
   inactive for an extended period of time the server may reclaim the
   resources.  That is done by issuing a REDIRECT request with the
   Redirect-Reason set to "Session-Timeout".  This MAY be done when the
   client has been inactive in the RTSP session for more than one
   Session Timeout period (Section 16.49).  However, the server is
   RECOMMENDED to not perform this operation until an extended period of
   inactivitiy has passed.  The time period is considered extended when
   it is 10 times the Session Timeout period.  Consideration of the
   application of the server and its content should be performed when
   configuring what is considered as extended periods of time.

   The REDIRECT request shall contain the Redirect-Reason
   (Section 16.39) andSession (Section 16.49) header.  The request only
   applies on the session identified in the Session header.

   The server can consider the session as terminated and can free any
   associated state after it receives the successful (2xx) response.
   The client SHOULD close the signalling connection after sending the
   2xx response.  The server MAY close the signalling connection upon
   receiving the response.  The exception to this is when the client has
   several sessions on the server being managed by the given signalling
   connection.  In this case, the client SHOULD close the connection
   when it has received and responded to REDIRECT requests for all the
   sessions managed by the signalling connection.

   The client may establish a new RTSP session on the same server upon
   user activity requesting RTSP operations.

--- New Header ---
16.39.  Redirect-Reason

   The Redirect-Reason request header allows the server when sending a
   REDIRECT request to provide a reason for the redirection and
   additional information about the redirect.  This specification
   identifies two reasons for Redirections and may be extended in the
   future:

   Server-Admin:  The server needs to be shutdown for some adminstrative
      reason.

   Session-Timeout:  A client's session is kept alive for extended
      periods of time and the server has determined that it needs to
      reclaim the resources assoicated with this session.

   The Server may provide additional parameters containing information
   around the redirect.  This specification defines the following ones.

   time:  Provides a wall clock time when the server will stop provide
      any service.

   user-msg:  An UTF-8 text string with a message from the server to the
      user.  This message SHOULD be displayed to the user.

--- ABNF syntax for new header ---

  Redirect-Reason      =  "Redirect-Reason" HCOLON RR-info
  RR-Info              =  RR-Reason *(SEMI RR-Parameter)
  RR-Reason            =  "Session-Timeout" / "Server-Admin" / token
  RR-Parameter         =  RR-time / RR-user-msg / generic-param
  RR-time              =  "time" EQUAL utc-time
  RR-user-msg          =  "user-msg" EQUAL quoted-string

--- Remove the "time" paramteter from Range ---

--- New IANA registry for Redirect-Reason ---

22.10.  Redirect-Reason Header

   The Redirect-Reason header (Section 16.39) has two registries for
   extensions.

22.10.1.  Redirect Reasons

   Registrations are done under the policy of Expert Review.  The
   registered value needs to follow syntax, i.e. be a token.  The
   specification needs to provide definition of what the procedures that
   is to be followed when a client receives this redirect reason.  This
   specification registeres two values:

   o  Session-Timeout

   o  Server-Admin

22.10.2.  Redirect-Reason Header Parameters

   Registrations are done under the policy of Specification Required.
   The registrations must define a syntax for the parameter that also
   follows the allowed by the RTSP 2.0 specification.  A contact person
   is also required.  This specification registers:

   o  time

   o  user-msg

-- 

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Wed, 4 Mar 2009 16:10:15 +0200

> comment on the main changes here.

When it comes to keep-alives, it must be explicitly stated whether:

 - The client MUST use both RTCP and RTSP,
   the server MUST support at least one of the two.

 - The client and the server MUST support RTCP for RTP streams,
   other transports must specify their mandatory keep-alive method.

 - The server MUST support both RTCP and RTSP for keep-alive,
   the client MUST use at least of the two at its discretion.

 - The server MUST instruct the client which one to use.

In RTSP/1.0, different interpretations have led to clients that only implement 
one method, and servers that only implement another method. That causes 
uninteroperable combinations.

I believe the proposed 2.5 section is still not sufficiently explicit. I don't 
care too much which path is taken, but I think one path needs to be taken.

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 04 Mar 2009 15:19:35 +0100

> care too much which path is taken, but I think one path needs to be taken.

That was not part of the update as this already is covered in the
following ways:

C.1.6.2.  RTSP Session keep-alive

   RTCP traffic from the RTSP client to the RTSP server MUST function as
   keep-alive.  Which requires an RTSP server supporting RTP to use the
   received RTCP packets as indications that the client desires the
   related RTSP session to be kept alive.

10.5.  Showing Liveness

   The mechanisms for showing liveness of the client is, any RTSP
   request with a Session header, if RTP & RTCP is used an RTCP message,
   or through any other used media protocol capable of indicating
   liveness of the RTSP client.  It is RECOMMENDED that a client does
   not wait to the last second of the timeout before trying to send a
   liveness message.  The RTSP message may be lost or when using
   reliable protocols, such as TCP, the message may take some time to
   arrive safely at the receiver.  To show liveness between RTSP request
   issued to accomplish other things, the following mechanisms can be
   used, in descending order of preference:

   RTCP: If RTP is used for media transport RTCP SHOULD be used.  If
         RTCP is used to report transport statistics, it MUST also work
         as keep alive.  The server can determine the client by used
         network address and port together with the fact that the client
         is reporting on the servers SSRC(s).  A downside of using RTCP
         is that it only gives statistical guarantees to reach the
         server.  However that probability is so low that it can be
         ignored in most cases.  For example, a session with 60 seconds
         timeout and enough bitrate assigned to RTCP messages to send a
         message from client to server on average every 5 seconds.  That
         client have for a network with 5 % packet loss, the probability
         to fail showing liveness sign in that session within the
         timeout interval of 2.4*E-16.  In sessions with shorter timeout
         times, or much higher packet loss, or small RTCP bandwidths
         SHOULD also use any of the mechanisms below.

   SET_PARAMETER:  When using SET_PARAMETER for keep alive, no body
         SHOULD be included.  This method is the RECOMMENDED RTSP method
         to use in request only intended to perform keep-alive.

   OPTIONS:  This method is also usable, but it causes the server to
         perform more unnecessary processing and result in bigger
         responses than necessary for the task.  The reason is that the
         server needs to determine the capabilities associated with the
         media resource to correctly populate the Public and Allow
         headers.

   The timeout parameter MAY be included in a SETUP response, and MUST
   NOT be included in requests.  The server uses it to indicate to the
   client how long the server is prepared to wait between RTSP commands
   or other signs of life before closing the session due to lack of
   activity (see below and Appendix B).  The timeout is measured in
   seconds, with a default of 60 seconds.  The length of the session
   timeout MUST NOT be changed in a established session.

I should add a reference in Section 2.5 to 10.5 about how to show liveness.

Cheers

Magnus Westerlund

---

From: "Jaehwan Kim" <[email-masked]>
Date: Thu, 5 Mar 2009 16:31:58 +0900

Hi Magnus,
10.5 looks good. In addition, I would like to add the following 
sentence or similar text.

"In RTSP PLAY state using persistence connection, when the 
client is suddenly detached from the network, there is no 
way for the server to know it until the given TCP session is 
expired. It is because there is no chance of notification for 
the connection close in TCP protocol. Because TCP timeout is 
rather very long, an application requiring high throughput such
as RTP and RTSP streaming service needs to know disconnection 
state earlier. To check client's disconnection in this case, 
server could send a keep-alive RTSP requests such as SET_PARAMETER 
or OPTIONS periodically. If the message is not delivered, server 
could stop sending RTP packets"

We know already many clients and servers support this mechanism 
in 3GPP world.

Regards,
Jaehwan

Senior Development Manager / Xenon Platform Architect
Vidiator® - Mobilizing Interactive Media(tm)

7th Fl. AnnJay BLDG 718-2 
YeokSam-Dong, KangNam-Gu, 135-920, Seoul
 
d: +82.70.7012.2540
f:  +82.2.569.5348
m:+82.10.6225.0619
e:  [email-masked]
w: www.vidiator.com

The message represents the personal views and opinion of the individual sender and under no circumstances represents those of HWL or its Group Companies. The shareholders, directors and management of HWL and any of its Group Companies accept no responsibility and accordingly shall have no liability to any party whatsoever with respect to the contents of this message. 
This message (including any attachments) is intended only for the use of the addressee(s) named above. It may contain information that is PRIVILEGED and CONFIDENTIAL and should not be read, copied or otherwise used by any other person. 
If you are not the intended recipient, you are hereby notified that any use, retention, disclosure, copying, printing, forwarding or dissemination of this communication is strictly prohibited. If you have received this communication in error, please erase all copies of the message and its attachments and notify us immediately.

---

From: "Jaehwan Kim" <[email-masked]>
Date: Thu, 5 Mar 2009 16:51:52 +0900

Hi Magnus,

>2.5.  Session Maintenance and Termination
(snip)
>When a
Is it possible? 
Session is terminated, then no session. Then, how to know whether the
given REDIRECT request from server is related to the terminated session?
Or should server keep the session ID until it receives REDIRECT
response(2xx)? In ordinary case, session ID is disappeared at TEARDOWN
response time.

>13.10.1.  Server Administration
(snip)
>too perform a controlled migration
looks typo. too-> to

(snip)
>   A REDIRECT request with a Session header(snip) 
>A client may receive a REDIRECT request with a Session
Is it the same proxy case which is described below?
And session header in REDIRECT means that client could start with 
PLAY method using that session header for the new connection, right?

(snip)
> The scope of such a request is limited to the next-hop (i.e.
>   and the server.
I don't understand this part.

(snip)
>A REDIRECT request without a Session header
More clarification is needed for the case of relative URI.
Although we might be able to use the same host and port as request URI
but with different contents name, absolute URI looks clearer.
Maybe we could use MUST than SHOULD.

>   to which the RTSP agent SHOULD reconnect. 

(snip)
>       those clients with an active session or an unanswered request)
So, even in case of many proxies in the network, anyway REDIRECT 
situation should be informed to the player at the end, right?

BTW, it is not clear proxy should send Location header and Session
header.
I guess both must be included in this case, right?

(snip)
>   The lack of a Location header in any REDIRECT request(snip)
Now we have 'PLAY_NOTIFY' with End-Of-Stream reason.
Do we still need to maintain this section? 
Or it looks better off with making Location mandatory and using 
PLAY_NOTIFY method in case of 'a server initiated TEARDOWN'.

(snip)
>If the URI given in the Location header is a valid resource

>  reason why a new DESCRIBE request SHOULD be issued.
OK. But I see "SHOULD"
I guess sending PLAY after making new connection if there is Session 
Header would be possible. Especially when the media resource and network
setup for RTP is exactly same as before. Of course, if we want to use
different transport information, player could update it through
SETUP. Sometimes, the original session was made from SDP Initiation
(Player downloads SDP from HTTP server in this case.)

>   If the Location header contains only a host address,(snip)
The example below has Session header. Then, it is contract to the above
clause, starting with " A REDIRECT request with a Session header...".
It says, "the Location SHALL contain a complete absolute URI 
and SHALL NOT contain just the host and port"

And I guess Server header field is strongly recommended when server
makes request. Even at client side, it might connect to various servers
due to redirection even within one RTSP session. Then, it is very good
information
for debugging purpose.

(snip)
>   (Section 16.39) and Session (Section 16.49) header.  The request
only
>   applies on the session identified in the Session header.
Please clarify this clause. We have no session header case above.

Regards,
Jaehwan

Senior Development Manager / Xenon Platform Architect
Vidiator(r) - Mobilizing Interactive Media(tm)

d: +82.70.7012.2540
f:  +82.2.569.5348
m:+82.10.6225.0619
e:  [email-masked]
w: www.vidiator.com

The message represents the personal views and opinion of the individual
sender and under no circumstances represents those of HWL or its Group
Companies. The shareholders, directors and management of HWL and any of
its Group Companies accept no responsibility and accordingly shall have
no liability to any party whatsoever with respect to the contents of
this message. 
This message (including any attachments) is intended only for the use of
the addressee(s) named above. It may contain information that is
PRIVILEGED and CONFIDENTIAL and should not be read, copied or otherwise
used by any other person. 
If you are not the intended recipient, you are hereby notified that any
use, retention, disclosure, copying, printing, forwarding or
dissemination of this communication is strictly prohibited. If you have
received this communication in error, please erase all copies of the
message and its attachments and notify us immediately.

---

From: "Jaehwan Kim" <[email-masked]>
Date: Thu, 5 Mar 2009 17:05:53 +0900

Maybe I should have changed the subject.
Or I don't understand the point. Correct me if I am wrong.

The below was about "how to detect client's unintended dead".

>From a server and operator point of view, sending RTP packets
looks waste of resource in this case and the subscriber might 
claim that the bill is too much in case of real time billing.
Therefore, there is a need to detect client's dead in timely 
manner.

Regards,
Jaehwan

-----Original Message-----
From: Rémi Denis-Courmont [mailto:[email-masked]] 
Sent: Thursday, March 05, 2009 4:52 PM
To: Jaehwan Kim
Cc: Magnus Westerlund; [email-masked]
Subject: Re: [MMUSIC] RTSP: Server killing the session in ready state depiste keep-alives: Showing Liveness

> could stop sending RTP packets"

Currently, the specification allow for clients to disconnect or change the
RTSP control connection, so I do not see how this could work.

I do know that some servers do that though (and it is somewhat
understandable).

-- 
Rémi Denis-Courmont

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Thu, 5 Mar 2009 11:01:27 +0200

> The below was about "how to detect client's unintended dead".

Yeah, and the point is that your proposed solution is incompatible with 
permissions that the current (and the RTSP/1.0) specification grants to 
clients.

I am not going to argue for or against a change. I am just pointing out that 
this requires a major change to the current RTSP specification.

> Therefore, there is a need to detect client's dead in timely

There is one, and only one, way to timely detect that a client is dead. It's 
link-layer state (which would need to be propagated from the base station to 
the RTSP server, yikes). TCP timeout is several minutes, which is nowhere near 
timely.

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 05 Mar 2009 13:45:21 +0100

> the RTSP server, yikes). TCP timeout is several minutes, which is nowhere near 

If you ensure that the clients send RTCP in a timely fashion, no less
than every 5-10 seconds then you will detect client failure quickly. In
fact to have good bit-rate adaptation for your data transmission you
need to configure RTCP to send more frequently, at least every few round
trip time. I know that PSS has all these features since release 6. Also
the RTSP session will timeout before the TCP timeout.

I don't think the text you suggest is the general message the RTSP
specification should carry. I would say use data transport layer
feedback to detect client failures, as you anyway should do it to be
congestion safe.

Cheers

Magnus Westerlund

---

From: Joe Pallas <[email-masked]>
Date: Thu, 5 Mar 2009 09:33:51 -0800

> PLAY_NOTIFY method in case of 'a server initiated TEARDOWN'.

I think it is very odd to use REDIRECT when there is no place to  
redirect to.

Although PLAY_NOTIFY is appropriate for indicating changes in the  
stream state, I don't necessarily think it makes sense for changes to  
the session state.

Why can't we just say that the server is allowed to send TEARDOWN to  
the client if it is terminating the session and there is no  
redirection available.

joe

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 05 Mar 2009 18:49:51 +0100

Joe Pallas skrev:
> Although PLAY_NOTIFY is appropriate for indicating changes in the stream
> state, I don't necessarily think it makes sense for changes to the
> session state.
> 
> Why can't we just say that the server is allowed to send TEARDOWN to the
> client if it is terminating the session and there is no redirection
> available.
> 

Yes, I agree wit that and it would clearer from a method semantics point
of view.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 06 Mar 2009 15:57:28 +0100

> client if it is terminating the session and there is no redirection

I thought some more when trying to implement this. I think there is an
important difference here. When the server terminates the session in
that instant using TEARDOWN seems correct. Thus the killing of inactive
sessions are done using TEARDOWN. However, when a server informs the
clients that it will stop providing service at some future point using
REDIRECT seems to be the right choice. Even if the server can't provide
an alternative.

Also is there anyone having a usage for Redirect with Range: npt=-90.45
? I have some questions mark what it means to fail to reach that point.
Thus I would like to remove that and only have: Wall clock time in
future or immediate REDIRECT.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 06 Mar 2009 16:44:50 +0100

Hi,

And here is new spec text for your review.

   Section 10.5 discusses the methods for showing liveness in more
   depth.  If the client fails to show liveness for more than the
   established session timeout value (normally 60 seconds) the server
   may terminate the context.  Other values may be selected by the
   server through the inclusion of the timeout parameter in the session
   header.

Schulzrinne, et al.     Expires September 7, 2009              [Page 19]

Internet-Draft   Real Time Streaming Protocol 2.0 (RTSP)      March 2009

   passed.  A server may terminate the session after one session timeout
   period without any client activitity beyond keep-alive.  When a
   server terminates the session context it does that by sending a
   TEARDOWN request indicating the reason why.

   A server can also request that the client tear down the session and
   re-establish it at an alternative server when needed for maintaince
   by using the REDIRECT method.  The Terminate-Reason header is used to
   indicate when and why.  The Location header indicates where it should
   connect if there are an alternative server available.  When the
   deadline expires the server simply stop providing service.  So to
   achieve a clean closure the client will need to initiate session
   termination prior to the deadline.  In case the server has no other
   server to redirect and likes to close the session for maintance it
   shall use the TEARDOWN method with a Terminate-Reason header.

13.7.  TEARDOWN

13.7.1.  Client to Server

   The TEARDOWN client to server request stops the stream delivery for
   the given URI, freeing the resources associated with it.  A TEARDOWN
   request MAY be performed on either an aggregated or a media control
   URI.  However some restrictions apply depending on the current state.
   The TEARDOWN request MUST contain a Session header indicating what
   session the request applies to.

   A TEARDOWN using the aggregated control URI or the media URI in a
   session under non-aggregated control (single media session) MAY be
   done in any state (Ready, and Play).  A successful request MUST
   result in that media delivery is immediately halted and the session
   state is destroyed.  This MUST be indicated through the lack of a
   Session header in the response.

   A TEARDOWN using a media URI in an aggregated session MAY only be
   done in Ready state.  Such a request only removes the indicated media
   stream and associated resources from the session.  This may result in
   that a session returns to non-aggregated control, due to that it only
   contains a single media after the requests completion.  A session
   that will exist after the processing of the TEARDOWN request MUST in
   the response to that TEARDOWN request contain a Session header.  Thus
   the presence of the Session header indicates to the receiver of the

Schulzrinne, et al.     Expires September 7, 2009              [Page 83]

Internet-Draft   Real Time Streaming Protocol 2.0 (RTSP)      March 2009

   response if the session is still existing or has been removed.

   Example:

     C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/2.0
           CSeq: 892
           Session: 12345678
           User-Agent: PhonyClient/1.2

     S->C: RTSP/2.0 200 OK
           CSeq: 892
           Server: PhonyServer 1.0

13.7.2.  Server to Client

   The server can send TEARDOWN requests in the server to client
   direction to indicate that the server has been forced to terminate
   the ongoing session.  This may happen for several reasons such as,
   server maintenace without available backup, or session have been
   inactive for extended periods of time.  The reason is provided in the
   Terminate-Reason header (Section 16.50).

   Terminate-Reason set to "Session-Timeout".  This MAY be done when the
   Session Timeout period (Section 16.48).  However, the server is

   In case the server needs to stop provide service to the established
   sessions and their is no server to point at in a REDIRECT request
   TEARDOWN shall be used to terminate the session.  This method can
   also be used when non-recoverable internal errors have happened and
   the server has no other option then to terminate the sessions.

   The TEARDOWN request is normally done on the session aggregate
   control URI and MUST include the following headers; Session and
   Terminate-Reason headers.  The request only applies to the session
   identified in the Session header.  The server may include a message
   to the client's user with the "user-msg" parameter.

   The TEARDOWN request may alternatively be done on the wildcard URI *
   and without any session header.  The scope of such a request is

Schulzrinne, et al.     Expires September 7, 2009              [Page 84]

Internet-Draft   Real Time Streaming Protocol 2.0 (RTSP)      March 2009

   limited to the next-hop (i.e. the RTSP agent in direct communication
   with the server) and applies, as well, to the control connection
   between the next-hop RTSP agent and the server.  This request
   indicates that all sessions and pending requests being managed via
   the control connection are terminated.  Any intervening proxies
   SHOULD do all of the following in the order listed:

   1.  respond to the TEARDOWN request

   3.  pass the TEARDOWN request to each applicable client (typically
       those clients with an active session or an unanswered request)

      Note: The proxy is responsible for accepting TEARDOWN responses
      from its clients; these responses MUST NOT be passed on to either
      the original server or the redirected server.

13.10.  REDIRECT

   The REDIRECT method is issued by a server to inform a client that the
   service provided will be terminated and where a corresponding service
   can provided instead.  This happens for different reasons.  One is
   that the server is being adminstrated such that it must stop
   providing service.  Thus the client is required to connect to another
   server location to access the resource indicated by the Request-URI.

   The REDIRECT request SHALL contain a Terminate-Reason header
   (Section 16.50) to inform the client of the reason for the request.
   Additional parameters related to the reason may also be included.
   The intention here is to allow an server administrator to do a
   controlled shutdown of the RTSP server.  That requires sufficient
   time to inform all entities having associated state with the server

Schulzrinne, et al.     Expires September 7, 2009              [Page 87]

Internet-Draft   Real Time Streaming Protocol 2.0 (RTSP)      March 2009

   and for them to perform a controlled migration from this server to a
   fallback server.

   A REDIRECT request with a Session header has end-to-end (i.e. server
   to client) scope and applies only to the given session.  Any
   intervening proxies SHOULD NOT disconnect the control channel while
   there are other remaining end-to-end sessions.  The REQUIRED Location
   header MUST contain a complete absolute URI pointing to the resource
   to which the client SHOULD reconnect.  Specifically, the Location
   MUST NOT contain just the host and port.  A client may receive a
   REDIRECT request with a Session header, if and only if, an end-to-end
   session has been established.

   A client may receive a REDIRECT request without a Session header at
   any time when it has communication or a connection established with a
   server.  The scope of such a request is limited to the next-hop (i.e.
   the RTSP agent in direct communication with the server) and applies
   to all sessions controlled, as well as the control connection between
   the next-hop RTSP agent and the server.  A REDIRECT request without a
   Session header indicates that all sessions and pending requests being
   managed via the control connection MUST be redirected.  The REQUIRED
   Location header, if included in such a request, SHOULD contain an
   absolute URI with only the host address and the OPTIONAL port number
   of the server to which the RTSP agent SHOULD reconnect.  Any
   intervening proxies SHOULD do all of the following in the order
   listed:

   When the server lacks any alternative server and needs to terminate a
   session or all sessions the TEARDOWN request SHALL be used instead.

   When no Terminate-Reason "time" parameter are included in a REDIRECT
   request, the client SHALL perform the redirection immediately and
   return a response to the server.  The server shall consider the
   session as terminated and can free any associated state after it
   receives the successful (2xx) response.  The server MAY close the

Schulzrinne, et al.     Expires September 7, 2009              [Page 88]

Internet-Draft   Real Time Streaming Protocol 2.0 (RTSP)      March 2009

   signalling connection upon receiving the response and the client
   SHOULD close the signalling connection after sending the 2xx
   response.  The exception to this is when the client has several
   sessions on the server being managed by the given signalling
   connection.  In this case, the client SHOULD close the connection
   when it has received and responded to REDIRECT requests for all the
   sessions managed by the signalling connection.

   The Terminate-Reason header "time" parameter MAY be used to indicate
   the wall clock time by when the redirection MUST have take place.  To
   allow a client to determine that redirect time without being time
   synchronized with the server, the server MUST include a Date header
   in the request.  The client should have before the redirection time-
   line terminated the session and close the control connection.  The
   server MAY simple cease to provide service when the deadline time has
   been reached, or it may issue TEARDOWN requests to the remaining
   sessions.

Schulzrinne, et al.     Expires September 7, 2009              [Page 89]

Internet-Draft   Real Time Streaming Protocol 2.0 (RTSP)      March 2009

     S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/2.0
           CSeq: 732
           Location: rtsp://s2.example.com:8001
           Terminate-Reason: Server-Admin ;time=19960213T143205Z
           Session: uZ3ci0K+Ld-M
           Date: Thu, 13 Feb 1996 14:30:43 GMT

     C->S: RTSP/2.0 200 OK
           CSeq: 732

16.50.  Terminate-Reason

   The Terminate-Reason request header allows the server when sending a
   REDIRECT or TERMINATE request to provide a reason for the session
   termination and any additional information.  This specification
   identifies three reasons for Redirections and may be extended in the
   future:

   Internal-Error  An internal error that is impossible to recover from
      has occured forcing the server to terminate the session.

-- 

Magnus Westerlund