We discussed this in one of our conference calls a year or two ago. I
think we agreed on option 2. That is why the Internet-Draft mentions
option 2 now. But apparently the I-D doesn't say anything about how the
failure cases should be handled.
Considering the failure cases, I think there are three steps, or phases,
in option 2:
2A) The client may try to change the transport parameters during Play
state. But the server may not support it, in which case the server will
respond with error 455.
2B) If a client tried step A and it failed, it may send a PAUSE command
to bring the session into Ready state, then try sending a SETUP request
again. But the server may not support it, in which case the server will
respond with error 455.
2C) If the client step B and it failed, it may send a non-aggregate
TEARDOWN command to de-select the stream whose transport parameters the
client want to change. Then the client can send a SETUP request to
select the stream once again, but using different transport parameters.
All servers must support this. Then the client sends a PLAY command to
continue streaming from where it left off.
I think step 2C would never fail. Otherwise, there could be a step 2D,
where the client sends an aggregate TEARDOWN to destroy the entire RTSP
session, and then creates a new RTSP session with different transport
parameters.
So, if I understand the issue correctly, we decided on option 2, but the
Internet-Draft only explicitly mentions step "2A". What the client
should do on failure is only implied. If necessary, we could add a
paragraph, or two, describing steps "2B" and "2C".
Anders
-----Original Message-----
From: mmusic-bounces at ietf.org [mailto:mmusic-bounces at ietf.org] On Behalf
Of Sean Sheedy
Sent: Thursday, July 14, 2005 3:16 PM
To: Magnus Westerlund
Cc: mmusic (E-mail)
Subject: Re: [MMUSIC] RTSP: Changing of transport parameters using SETUP
On Thu, 2005-07-14 at 13:46 +0200, Magnus Westerlund wrote:
The spec does currently allows the usage of SETUP to change transport
parameters both in ready and play mode. If a server doesn't support
the
functionality it is supposed to respond using 455 (Method not allowed
in
this state). However this generates an issue. If a client gets back a
455 when the server is play state, then it can't determine if the
server
supports this operation in ready mode or not.
Possible solutions:
1. Require the support of changing of transport parameters in ready
state from all servers.
I don't like this. In some environments (such as cable TV), changing
transport parameters after the initial SETUP isn't feasible.
2. Recommend that clients checks also in ready state?
I think this is the best choice.
3. If supporting this functionality it shall be supported in both
ready
and play mode.
4. Forbid it in play mode
Is anyone using re-SETUP during play mode for bandwidth throttling? If
so, we don't want to forbid it.
5. Ignore the issue
Sean