Subject: Re: negotiating client capabilities within RTSP

From: Rob Lanphier <[email-masked]>
Date: Wed, 28 Mar 2001 18:02:35 -0800

Hi Greg,

I've cc'd the MMUSIC list, since that's the more appropriate forum.

The type of negotiation that you are suggesting is something that would 
need to be handled by extension to RTSP.  There's currently no way, other 
than the "Require" header, for the client to announce its capability set to 
the server, and there isn't yet a standardized set of Require extensions.

Mind you, you probably don't want to use the Require header anyway.  That 
would force an extra round trip from the server if the feature isn't 
supported, and you don't get the benefit of learning what the server *does* 
have to offer, since it's required to return a "feature not supported" 
response.  It's harmless to let the server return a DESCRIBE response, and 
then decide whether or not to proceed to SETUP the streams or not.

The best thing you could do is add a header which lists the media types in 
the DESCRIBE request:

DESCRIBE rtsp://example.org/foo.rm RTSP/1.0
Accept-RTP-Payload:  audio/AMR/8000, audio/AMR-WB/16000
...

....which would then possibly restrict the server to the listed codecs.  If 
the server ignored this header, the client could still determine whether or 
not its capable of playing back the media based on what is returned in the 
SDP in the DESCRIBE response.

You may want to model this after the "Accept" header usage described in RFC 
2295 (http://www.ietf.org/rfc/rfc2295.txt), but that may be more complex 
than you want.

This hasn't been a problem in our system, since the client usually has 
*far* more capabilities than the server has options for returning the content.

Hope this helps.

Rob

At 05:23 PM 3/27/01 -0800, Greg Sherwood wrote:

>I have some questions regarding the implementation of simple capability
>negotiation within RTSP.  Many of the proposed payload formats have optional
>parameters communicated through MIME attributes.  What is the preferred
>method
>of communicating the client capabilities?
>
>In a streaming application, there is no problem with the server listing
>several
>options in the DESCRIBE response using SDP and the syntax defined in the SDP
>simcap
>draft.  The client can then select the desired set of parameters through the
>SETUP
>request (i.e., only does a SETUP on the stream with the desired parameters).
>However,
>this method is only reasonable if the number of options is small.  In other
>cases, the
>client needs to inform the server of its capabilities so they can find a
>mutually agreeable
>set of parameters.  The client typically has the most severe resource
>limitations (especially
>for wireless handsets), so it's probably the case that the server can
>accommodate whatever the
>client can handle if it is informed about the constraints.
>
>It seems like the "Require" field might be a method for the client to inform
>the server about
>capabilities.  What is the preferred syntax if we use the Require field?  Do
>we just use SDP lines?
>Can we include multiple Require fields in a single request?  I get the
>impression that a single
>Require per request is preferred to simplify a possible negative
>acknowledgement from the server.
>However, the delay may become excessive if many requests have to be made to
>get through the capability
>negotiation.  Also if the client sends a range of acceptable values for a
>given parameter, how does the
>server indicate the selected value? Is it possible to send an entity body in
>the SETUP request which
>contains the clients capabilities encoded in SDP?
>
>Sorry for all the questions, but there are many ways to make it work and I
>want to follow the intentions
>of RTSP document. Any advice would be appreciated.
>
>- Greg Sherwood