#26 Provide Transport capabilites in 461 response

[Magnus Westerlund]

Christian Haas raised on the MMUSIC list that we should consider to providing server transport capabilities when sending 461 error response. He suggested that Transport header could be used for this.

My reflection on this is two fold:

1. That how to express capabilities is different than providing configuration

2. That such capabilities are probably desirable to retrieve in other forms.

[Martin Stiemerling]

For 1; how to express:
Adding a Transport header to the 461 response with only the first part set:
Transport = "Transport" HCOLON transport-spec
*(COMMA transport-spec)
transport-spec = transport-id *tr-parameter
transport-id = trans-id-rtp / other-trans

E.g. Transport: RTP/AVP, RTP/AVP/TCP

For 2; out of scope of RTSP.

[juliusfriedman]

I would settle for the same transport header which would otherwise be received in such a case as a successful response e.g. also include the next available channels.

I also think when a client attempts to select a channel with the interleaved option if the channel is in use rather then returning an error the request should be informational and the correct channel should be indicated by the server to save another trip.

An error should only occur if the specific transport is specifically not supported.

At such a point as this post suggests the correct transport type should be indicated.