Default IP address: First browse to this website and pick up your camera manufacturer and navigate to your camera model. Open Network. The Real Time Streaming Protocol RTSP is a network control protocol designed for use in entertainment and communications systems to control streaming media servers.
The protocol is used for establishing and controlling media sessions between end points. Refer to Sec. Notes: 1. Where is my RTSP port?
Since the number of parameters and the frequency of commands is low, processing efficiency is not a concern. Text-based protocols, if done carefully, also allow easy implementation of research prototypes in scripting languages such as Tcl, Visual Basic and Perl. This is also the encoding used for RTCP. ISO translates directly into Unicode with a high-order octet of zero. ISO characters with the most-significant bit set are represented as x 10xxxxxx.
Requests contain methods, the object the method is operating upon and parameters to further describe the method. Methods are idempotent, unless otherwise noted. Methods are also designed to require little or no state maintenance at the media server. Any response message which MUST NOT include a message body such as the 1xx, , and responses is always terminated by the first empty line after the header fields, regardless of the entity-header fields present in the message. If a Content-Length header field section If this header field is not present, a value of zero is assumed.
By the server closing the connection. Closing the connection cannot be used to indicate the end of a request body, since that would leave no possibility for the server to send back a response.
Given the moderate length of presentation descriptions returned, the server should always be able to determine its length, even if it is generated dynamically, making the chunked transfer encoding unnecessary.
Even though Content-Length must be present if there is any entity body, the rules ensure reasonable behavior even if the length is not given explicitly.
The valid response codes and the methods they can be used with are defined in Table 1. After receiving and interpreting a request message, the recipient responds with an RTSP response message. These codes are fully defined in Section The Reason-Phrase is intended to give a short textual description of the Status-Code.
The Status-Code is intended for use by automata and the Reason-Phrase is intended for the human user. The client is not required to examine or display the Reason- Phrase. The last two digits do not have any categorization role. The reason phrases listed here are only recommended - they may be replaced by local equivalents without affecting the protocol.
RTSP applications are not required to understand the meaning of all registered status codes, though such understanding is obviously desirable. However, applications MUST understand the class of any status code, as indicated by the first digit, and treat any unrecognized response as being equivalent to the x00 status code of that class, with the exception that an unrecognized response MUST NOT be cached. For example, if an unrecognized status code of is received by the client, it can safely assume that there was something wrong with its request and treat the response as if it had received a status code.
In such cases, user agents SHOULD present to the user the entity returned with the response, since that entity is likely to include human- readable information which will explain the unusual status. These header fields give information about the server and about further access to the resource identified by the Request-URI. However, new or experimental header fields MAY be given the semantics of response- header fields if all parties in the communication recognize them to be response-header fields.
Unrecognized header fields are treated as entity-header fields. An entity consists of entity-header fields and an entity-body, although some responses will only include the entity-headers. In this section, both sender and recipient refer to either the client or the server, depending on who sends and who receives the entity. For the scheme "rtsp", a persistent connection is assumed, while the scheme "rtspu" calls for RTSP requests to be sent without setting up a connection.
However, this is only supported for persistent connections, as the media server otherwise has no reliable way of reaching the client. Also, this is the only way that requests from media server to client are likely to traverse firewalls.
A server MUST send its responses to those requests in the same order that the requests were received. If there is no acknowledgement, the sender may resend the same message after a timeout of one round-trip time RTT.
If both the underlying reliable transport such as TCP and the RTSP application retransmit requests, it is possible that each packet loss results in two retransmissions. The receiver cannot typically take advantage of the application-layer retransmission since the Schulzrinne, et. Standards Track [Page 28] RFC Real Time Streaming Protocol April transport stack will not deliver the application-layer retransmission before the first attempt has reached the receiver.
If the packet loss is caused by congestion, multiple retransmissions at different layers will exacerbate the congestion. The Timestamp header Section Each request carries a sequence number in the CSeq header Section If a request is repeated because of lack of acknowledgement, the request MUST carry the original sequence number i. Otherwise, an RTSP packet is terminated with an empty line immediately following the last message header. The method is case-sensitive. New methods may be defined in the future.
Methods are summarized in Table 2. It does not influence server state. It may use the Accept header to specify the description formats that the client understands. The server responds with a description of the requested resource. Clear ground rules need to be established so that clients have an unambiguous means of knowing when to request media initialization information via DESCRIBE, and when not to.
If a new media stream is added to a presentation e. For the benefit of any intervening firewalls, a client must indicate the transport parameters even if it has no influence over these parameters, for example, where the server advertises a fixed multicast address. Since SETUP includes all transport initialization information, firewalls and other intermediate network devices which need this information are spared the more arduous task of parsing the DESCRIBE response, which has been reserved for media initialization.
The Transport header specifies the transport parameters acceptable to the client for data transmission; the response will contain the transport parameters selected by the server. The PLAY request positions the normal play time to the beginning of the range specified and delivers stream data until the end of the range is reached.
This allows precise editing. For example, regardless of how closely spaced the two PLAY requests in the example below arrive, the server will first play seconds 10 through 15, then, immediately following, seconds 20 to 25, and finally seconds 30 through the end. It starts playing a stream from the beginning unless the stream has been paused. If a stream is playing, such a PLAY request causes no further action and can be used by the client to test server liveness.
This parameter specifies a time in UTC at which the playback should start. If the message is received after the specified time, playback is started immediately. The time parameter may be used to aid in synchronization of streams obtained from different sources. For a on-demand stream, the server replies with the actual range that will be played back. This may differ from the requested range if alignment of the requested range to valid frame boundaries is required for the media source.
If no range is specified in the request, the current position is returned in the reply. The unit of the range in the reply is the same as that in the request. After playing the desired range, the presentation is automatically paused, as if a PAUSE request had been issued. The following example plays the whole presentation starting at SMPTE time code until the end of the clip. The playback is to start at on 23 Jan If the request URL names a stream, only playback and recording of that stream is halted.
For example, for audio, this is equivalent to muting. If the request URL names a presentation or group of streams, delivery of all currently active streams within the presentation or group is halted. After resuming playback or recording, synchronization of the tracks MUST be maintained. Any server resources are kept, though servers MAY close the session and free resources after being paused for the duration specified with the timeout parameter of the Session header in the SETUP message.
We refer to this point as the "pause point". The header must contain exactly one value rather than a time range. The normal play time for the stream is set to the pause point. The pause request becomes effective the first time the server is encountering the time point specified in any of the currently pending PLAY requests.
If a media unit such as an audio or video frame starts presentation at exactly the pause point, it is not played or recorded. If the Range header is missing, stream delivery is interrupted immediately on receipt of the message and the pause point is set to the current normal play time.
However, the pause point in the media stream MUST be maintained. For example, if the server has play requests for ranges 10 to 15 and 20 to 29 pending and then receives a pause request for NPT 21, it would start playing the second range and stop at NPT If the pause request is for NPT 12 and the server is playing at NPT 13 serving the first play request, the server stops immediately.
If the pause request is for NPT 16, the server stops after completing the first Schulzrinne, et. If the server has already sent data beyond the time specified in the Range header, a PLAY would still resume at that point in time, as it is assumed that the client has discarded data after that point. Unless all transport parameters are defined by the session description, a SETUP request has to be issued before the session can be played again.
The content of the reply and response is left to the implementation. This method is intentionally loosely defined with the intention that the reply content and response content will be defined after further experimentation.
If the request contains several parameters, the server MUST only act on the request if all of the parameters can be set successfully. The parameters are split in a fine-grained fashion so that there can be more meaningful error indications. However, it may make sense to allow the setting of several parameters if an atomic setting is desirable.
Imagine device control where the client does not want the camera to pan unless it can also tilt to the right angle at the same time. It contains the mandatory header Location, which indicates that the client should issue requests for that URL.
It may contain the parameter Range, which indicates when the redirection takes effect. The timestamp reflects start and end time UTC.
If no time range is given, use the start or end time provided in the presentation description. If the session has already started, commence recording immediately. A media server supporting recording of live presentations MUST support the clock range format; the smpte format does not make sense. This interleaving should generally be avoided unless necessary since it complicates client and server operation and imposes additional overhead.
Stream data such as RTP packets is encapsulated by an ASCII dollar sign 24 hexadecimal , followed by a one-byte channel identifier, followed by the length of the encapsulated binary data as a binary, two-byte integer in network byte order. The stream data follows immediately afterwards, without a CRLF, but including the upper-layer protocol headers.
The channel identifier is defined in the Transport header with the interleaved parameter Section This is done by specifying two channels in the interleaved parameter of the Transport header Section RTCP is needed for synchronization when two or more streams are interleaved in such a fashion. Status codes that have the same meaning are not repeated here. See Table 1 for a listing of which status codes may be returned by which requests. If possible, the server should use the Range header to indicate what time period it may still be able to record.
Since other processes on the server may be consuming storage space simultaneously, a client should take this only as an estimate. Within RTSP, redirection may be used for load balancing or redirecting stream requests to a server topologically closer to the client.
Mechanisms to determine topological proximity are beyond the scope of this specification. The response MUST include an Allow header containing a list of valid methods for the requested resource.
This status code is also to be used if a request attempts to use a method not indicated during SETUP, e. This may, for example, be the result of a resource reservation failure. The method may be applied on a stream URL. The method may be applied on the presentation URL. This error will most likely be the result of a client attempt to place an invalid Destination parameter in the Transport field.
The Unsupported header should be returned stating the option for which there is no support. Table 3 summarizes the header fields used by RTSP. Type "g" designates general request headers to be found in both requests and responses, type "R" designates request headers, type "r" designates response headers, and type "e" designates entity header fields. Fields marked with "req. Note that not all fields marked "req. The "req. The last column lists the method for which this header field is meaningful; the designation "entity" refers to all methods that return a message body.
The "level" parameter for presentation descriptions is properly defined as part of the MIME type registration, not here. Get the Gio. TlsCertificate used for negotiating TLS auth.
TlsCertificate of auth. Get the GTlsDatabase used for verifying client certificate. TlsDatabase used for verifying client certificate. TlsDatabase of auth. Parse the contents of the file at path and enable the privileges listed in token for the users it describes.
True if the file was successfully parsed, False otherwise. The default token will be used for unauthenticated users. Set the default GstRtspServer. RTSPToken to token in auth. The Gio. When set to another value than Gio.
NONE , accept-certificate signal will be emitted and must be handled. Set the TLS certificate for the auth. Client connections will only be accepted when TLS is negotiated. Sets the certificate database that is used to verify peer certificates. If set to null the default , then peer certificate validation will always set the Gio.
If set to None the default , then peer certificate validation will always set the Gio. Indoor vs Outdoor? Don't even know what PTZ means? What is RTSP? RTSP Uses? C Streaming to a service Some services allow you to send an RTSP stream to an internet server, allowing that stream to then be broadcasted publicly the internet.
It can be omitted. It starts from 1. Channels start at 0.
0コメント