#5 Reuse of existing transports
In some environments, such as commercial ATM or QAM
deployments, transport properties do not change from
presentation to presentation, and setting up sessions
is expensive, in terms of both server loading and
client perceived latency. The Web browsing model of
creating a transport for each presentation works well
in many Internet delivery environments. In a non-IP
delivery environment with dedicated media delivery
bandwidth, however, using a single transport for
several sequential presentations provides a better end
user experience.
Reusing an existing transport for different
presentations requires a mechanism to change the
presentation URI, and URI wildcarding to allow clients
to control playout in cases when the currently active
presentation on the server is not known precisely.
Changing Presentation URI
To play a different presentation on an existing
transport, the client may specify a different
presentation URI on a PLAY method request than was used
in the initial SETUP request. If a PLAY is requested
with a different presentation URI than that most
recently used in the session, the presentation
specified by the new URI will be played over the
existing session's transport.
For a PLAY request with a new presentation URI to
succeed, sufficient bandwidth must already be available
in the existing transport. This can be reserved with
an extension transport parameter on the initial SETUP
of the session ("bandwidth", described in a separate
item), or can be allocated with a new SETUP request.
Changing a presentation URI is only allowed if the
server supports aggregate control of both the current
presentation and the new presentation. If this is not
the case, the server must respond with error 459,
"Aggregate Operation Not Allowed".
If the new URI requested by a client is not a
presentation URI, the server must respond with error
460, "Only Aggregate Operation Allowed".
Wildcard Presentation URI
If a client uses queued PLAY requests with different
URI's, it may not be able to determine which
presentation is active at any particular time. To
handle this case, an asterisk (*) for the URI matches
whatever presentation URI, if any, is currently
active. Such a wild card asterisk is legal only for
the following methods:
PLAY
PAUSE
TEARDOWN
GET_PARAMETER
SET_PARAMETER
Wildcard URI's may not be used with SETUP requests. If
a client uses a wildcard URI in a SETUP request, the
server must respond with an error 404, "Not Found".
URI Response Header
In a response to a request containing a wildcard URI,
the server must include a URI header its response to
indicate the actual presentation URI affected by the
request. The syntax of the URI response header is:
URI-Response = "URI" ":" absolute_URI
This is implementation specific. The client would have to issue a setup anyway how that setup is handled is already defined. If a client switched from udp to tcp you cant reuse that transport. The session and such assests are already reusable.