Standards Track A. Rao Netscap - RFC Editor

More documents

Recommendations

Info

RFC 2326 Real Time Streaming Protocol April 1998C->S: RTSP/1.0 200 OKCSeq: 431Content-Length: 46Content-Type: text/parameterspackets_received: 10jitter: 0.3838The "text/parameters" section is only an example type forparameter. This method is intentionally loosely defined with theintention that the reply content and response content will bedefined after further experimentation.10.9 SET_PARAMETERThis method requests to set the value of a parameter for apresentation or stream specified by the URI.A request SHOULD only contain a single parameter to allow the clientto determine why a particular request failed. If the request containsseveral parameters, the server MUST only act on the request if all ofthe parameters can be set successfully. A server MUST allow aparameter to be set repeatedly to the same value, but it MAY disallowchanging parameter values.Note: transport parameters for the media stream MUST only be set withthe SETUP command.Restricting setting transport parameters to SETUP is for thebenefit of firewalls.The parameters are split in a fine-grained fashion so that therecan be more meaningful error indications. However, it may makesense to allow the setting of several parameters if an atomicsetting is desirable. Imagine device control where the client doesnot want the camera to pan unless it can also tilt to the rightangle at the same time.Example:C->S: SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0CSeq: 421Content-length: 20Content-type: text/parametersbarparam: barstuffS->C: RTSP/1.0 451 Invalid ParameterSchulzrinne, et. al. Standards Track [Page 38]
RFC 2326 Real Time Streaming Protocol April 1998CSeq: 421Content-length: 10Content-type: text/parametersbarparamThe "text/parameters" section is only an example type forparameter. This method is intentionally loosely defined with theintention that the reply content and response content will bedefined after further experimentation.10.10 REDIRECTA redirect request informs the client that it must connect to anotherserver location. It contains the mandatory header Location, whichindicates that the client should issue requests for that URL. It maycontain the parameter Range, which indicates when the redirectiontakes effect. If the client wants to continue to send or receivemedia for this URI, the client MUST issue a TEARDOWN request for thecurrent session and a SETUP for the new session at the designatedhost.This example request redirects traffic for this URI to the new serverat the given play time:S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/1.0CSeq: 732Location: rtsp://bigserver.com:8001Range: clock=19960213T143205Z-10.11 RECORDThis method initiates recording a range of media data according tothe presentation description. The timestamp reflects start and endtime (UTC). If no time range is given, use the start or end timeprovided in the presentation description. If the session has alreadystarted, commence recording immediately.The server decides whether to store the recorded data under therequest-URI or another URI. If the server does not use the request-URI, the response SHOULD be 201 (Created) and contain an entity whichdescribes the status of the request and refers to the new resource,and a Location header.A media server supporting recording of live presentations MUSTsupport the clock range format; the smpte format does not make sense.Schulzrinne, et. al. Standards Track [Page 39]
Page 2 and 3: RFC 2326 Real Time Streaming Protoc
Page 7: RFC 2326 Real Time Streaming Protoc
Page 88 and 89:
RFC 2326 Real Time Streaming Protoc
Page 90 and 91:
Page 92:
show all

Standards Track A. Rao Netscap - RFC Editor

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?