external/srs
1
0
Fork 0
mirror of https://github.com/ossrs/srs.git synced 2025-03-09 15:49:59 +00:00
Code Issues Releases Wiki Activity

Refine typo in protocol.

Browse source
This commit is contained in:
winlin 2019-04-23 08:06:50 +08:00
parent 35fe05d62c
commit 8bc77387ff
7 changed files with 1328 additions and 2117 deletions
Download patch file Download diff file Expand all files Collapse all files

660
trunk/src/protocol/srs_rtsp_stack.hpp
View file

@ -38,7 +38,7 @@ class SrsSimpleStream;
class SrsAudioFrame;
class ISrsProtocolReadWriter;
// rtsp specification
// From rtsp specification
// CR = <US-ASCII CR, carriage return (13)>
#define SRS_RTSP_CR SRS_CONSTS_CR // 0x0D
// LF = <US-ASCII LF, linefeed (10)>
@ -78,38 +78,28 @@ class ISrsProtocolReadWriter;
// RTSP-Version
#define SRS_RTSP_VERSION "RTSP/1.0"
/**
* the rtsp sdp parse state.
*/
// The rtsp sdp parse state.
enum SrsRtspSdpState
{
/**
* other sdp properties.
*/
// Other sdp properties.
SrsRtspSdpStateOthers,
/**
* parse sdp audio state.
*/
// Parse sdp audio state.
SrsRtspSdpStateAudio,
/**
* parse sdp video state.
*/
// Parse sdp video state.
SrsRtspSdpStateVideo,
};
/**
* 10 Method Definitions, @see rfc2326-1998-rtsp.pdf, page 57
* The method token indicates the method to be performed on the resource
* identified by the Request-URI. The method is case-sensitive. New
* methods may be defined in the future. Method names may not start with
* a $ character (decimal 24) and must be a token. Methods are
* summarized in Table 2.
* Notes on Table 2: PAUSE is recommended, but not required in that a
* fully functional server can be built that does not support this
* method, for example, for live feeds. If a server does not support a
* particular method, it MUST return "501 Not Implemented" and a client
* SHOULD not try this method again for this server.
*/
// 10 Method Definitions, @see rfc2326-1998-rtsp.pdf, page 57
// The method token indicates the method to be performed on the resource
// identified by the Request-URI. The method is case-sensitive. New
// methods may be defined in the future. Method names may not start with
// a $ character (decimal 24) and must be a token. Methods are
// summarized in Table 2.
// Notes on Table 2: PAUSE is recommended, but not required in that a
// fully functional server can be built that does not support this
// method, for example, for live feeds. If a server does not support a
// particular method, it MUST return "501 Not Implemented" and a client
// SHOULD not try this method again for this server.
enum SrsRtspMethod
{
SrsRtspMethodDescribe = 0x0001,
@ -125,237 +115,187 @@ enum SrsRtspMethod
SrsRtspMethodTeardown = 0x0400,
};
/**
* the state of rtsp token.
*/
// The state of rtsp token.
enum SrsRtspTokenState
{
/**
* parse token failed, default state.
*/
// Parse token failed, default state.
SrsRtspTokenStateError = 100,
/**
* when SP follow the token.
*/
// When SP follow the token.
SrsRtspTokenStateNormal = 101,
/**
* when CRLF follow the token.
*/
// When CRLF follow the token.
SrsRtspTokenStateEOF = 102,
};
/**
* the rtp packet.
* 5. RTP Data Transfer Protocol, @see rfc3550-2003-rtp.pdf, page 12
*/
// The rtp packet.
// 5. RTP Data Transfer Protocol, @see rfc3550-2003-rtp.pdf, page 12
class SrsRtpPacket
{
public:
/**
* version (V): 2 bits
* This field identifies the version of RTP. The version defined by this specification is two (2).
* (The value 1 is used by the first draft version of RTP and the value 0 is used by the protocol
* initially implemented in the \vat" audio tool.)
*/
// The version (V): 2 bits
// This field identifies the version of RTP. The version defined by this specification is two (2).
// (The value 1 is used by the first draft version of RTP and the value 0 is used by the protocol
// initially implemented in the \vat" audio tool.)
int8_t version; //2bits
/**
* padding (P): 1 bit
* If the padding bit is set, the packet contains one or more additional padding octets at the
* end which are not part of the payload. The last octet of the padding contains a count of
* how many padding octets should be ignored, including itself. Padding may be needed by
* some encryption algorithms with fixed block sizes or for carrying several RTP packets in a
* lower-layer protocol data unit.
*/
// The padding (P): 1 bit
// If the padding bit is set, the packet contains one or more additional padding octets at the
// end which are not part of the payload. The last octet of the padding contains a count of
// how many padding octets should be ignored, including itself. Padding may be needed by
// some encryption algorithms with fixed block sizes or for carrying several RTP packets in a
// lower-layer protocol data unit.
int8_t padding; //1bit
/**
* extension (X): 1 bit
* If the extension bit is set, the fixed header must be followed by exactly one header extension,
* with a format defined in Section 5.3.1.
*/
// The extension (X): 1 bit
// If the extension bit is set, the fixed header must be followed by exactly one header extension,
// with a format defined in Section 5.3.1.
int8_t extension; //1bit
/**
* CSRC count (CC): 4 bits
* The CSRC count contains the number of CSRC identifiers that follow the fixed header.
*/
// The CSRC count (CC): 4 bits
// The CSRC count contains the number of CSRC identifiers that follow the fixed header.
int8_t csrc_count; //4bits
/**
* marker (M): 1 bit
* The interpretation of the marker is defined by a profile. It is intended to allow significant
* events such as frame boundaries to be marked in the packet stream. A profile may define
* additional marker bits or specify that there is no marker bit by changing the number of bits
* in the payload type field (see Section 5.3).
*/
// The marker (M): 1 bit
// The interpretation of the marker is defined by a profile. It is intended to allow significant
// events such as frame boundaries to be marked in the packet stream. A profile may define
// additional marker bits or specify that there is no marker bit by changing the number of bits
// in the payload type field (see Section 5.3).
int8_t marker; //1bit
/**
* payload type (PT): 7 bits
* This field identifies the format of the RTP payload and determines its interpretation by the
* application. A profile may specify a default static mapping of payload type codes to payload
* formats. Additional payload type codes may be defined dynamically through non-RTP means
* (see Section 3). A set of default mappings for audio and video is specified in the companion
* RFC 3551 [1]. An RTP source may change the payload type during a session, but this field
* should not be used for multiplexing separate media streams (see Section 5.2).
* A receiver must ignore packets with payload types that it does not understand.
*/
// The payload type (PT): 7 bits
// This field identifies the format of the RTP payload and determines its interpretation by the
// application. A profile may specify a default static mapping of payload type codes to payload
// formats. Additional payload type codes may be defined dynamically through non-RTP means
// (see Section 3). A set of default mappings for audio and video is specified in the companion
// RFC 3551 [1]. An RTP source may change the payload type during a session, but this field
// should not be used for multiplexing separate media streams (see Section 5.2).
// A receiver must ignore packets with payload types that it does not understand.
int8_t payload_type; //7bits
/**
* sequence number: 16 bits
* The sequence number increments by one for each RTP data packet sent, and may be used
* by the receiver to detect packet loss and to restore packet sequence. The initial value of the
* sequence number should be random (unpredictable) to make known-plaintext attacks on
* encryption more dicult, even if the source itself does not encrypt according to the method
* in Section 9.1, because the packets may flow through a translator that does. Techniques for
* choosing unpredictable numbers are discussed in [17].
*/
// The sequence number: 16 bits
// The sequence number increments by one for each RTP data packet sent, and may be used
// by the receiver to detect packet loss and to restore packet sequence. The initial value of the
// sequence number should be random (unpredictable) to make known-plaintext attacks on
// encryption more dicult, even if the source itself does not encrypt according to the method
// in Section 9.1, because the packets may flow through a translator that does. Techniques for
// choosing unpredictable numbers are discussed in [17].
uint16_t sequence_number; //16bits
/**
* timestamp: 32 bits
* The timestamp reflects the sampling instant of the first octet in the RTP data packet. The
* sampling instant must be derived from a clock that increments monotonically and linearly
* in time to allow synchronization and jitter calculations (see Section 6.4.1). The resolution
* of the clock must be sucient for the desired synchronization accuracy and for measuring
* packet arrival jitter (one tick per video frame is typically not sucient). The clock frequency
* is dependent on the format of data carried as payload and is specified statically in the profile
* or payload format specification that defines the format, or may be specified dynamically for
* payload formats defined through non-RTP means. If RTP packets are generated periodically,
* the nominal sampling instant as determined from the sampling clock is to be used, not a
* reading of the system clock. As an example, for fixed-rate audio the timestamp clock would
* likely increment by one for each sampling period. If an audio application reads blocks covering
* 160 sampling periods from the input device, the timestamp would be increased by 160 for
* each such block, regardless of whether the block is transmitted in a packet or dropped as
* silent.
*
* The initial value of the timestamp should be random, as for the sequence number. Several
* consecutive RTP packets will have equal timestamps if they are (logically) generated at once,
* e.g., belong to the same video frame. Consecutive RTP packets may contain timestamps that
* are not monotonic if the data is not transmitted in the order it was sampled, as in the case
* of MPEG interpolated video frames. (The sequence numbers of the packets as transmitted
* will still be monotonic.)
*
* RTP timestamps from different media streams may advance at different rates and usually
* have independent, random offsets. Therefore, although these timestamps are sucient to
* reconstruct the timing of a single stream, directly comparing RTP timestamps from different
* media is not effective for synchronization. Instead, for each medium the RTP timestamp
* is related to the sampling instant by pairing it with a timestamp from a reference clock
* (wallclock) that represents the time when the data corresponding to the RTP timestamp was
* sampled. The reference clock is shared by all media to be synchronized. The timestamp
* pairs are not transmitted in every data packet, but at a lower rate in RTCP SR packets as
* described in Section 6.4.
*
* The sampling instant is chosen as the point of reference for the RTP timestamp because it is
* known to the transmitting endpoint and has a common definition for all media, independent
* of encoding delays or other processing. The purpose is to allow synchronized presentation of
* all media sampled at the same time.
*
* Applications transmitting stored data rather than data sampled in real time typically use a
* virtual presentation timeline derived from wallclock time to determine when the next frame
* or other unit of each medium in the stored data should be presented. In this case, the RTP
* timestamp would reflect the presentation time for each unit. That is, the RTP timestamp for
* each unit would be related to the wallclock time at which the unit becomes current on the
* virtual presentation timeline. Actual presentation occurs some time later as determined by
* the receiver.
*
* An example describing live audio narration of prerecorded video illustrates the significance
* of choosing the sampling instant as the reference point. In this scenario, the video would
* be presented locally for the narrator to view and would be simultaneously transmitted using
* RTP. The sampling instant" of a video frame transmitted in RTP would be established by
* referencing its timestamp to the wallclock time when that video frame was presented to the
* narrator. The sampling instant for the audio RTP packets containing the narrator's speech
* would be established by referencing the same wallclock time when the audio was sampled.
* The audio and video may even be transmitted by different hosts if the reference clocks on
* the two hosts are synchronized by some means such as NTP. A receiver can then synchronize
* presentation of the audio and video packets by relating their RTP timestamps using the
* timestamp pairs in RTCP SR packets.
*/
// The timestamp: 32 bits
// The timestamp reflects the sampling instant of the first octet in the RTP data packet. The
// sampling instant must be derived from a clock that increments monotonically and linearly
// in time to allow synchronization and jitter calculations (see Section 6.4.1). The resolution
// of the clock must be sucient for the desired synchronization accuracy and for measuring
// packet arrival jitter (one tick per video frame is typically not sucient). The clock frequency
// is dependent on the format of data carried as payload and is specified statically in the profile
// or payload format specification that defines the format, or may be specified dynamically for
// payload formats defined through non-RTP means. If RTP packets are generated periodically,
// The nominal sampling instant as determined from the sampling clock is to be used, not a
// reading of the system clock. As an example, for fixed-rate audio the timestamp clock would
// likely increment by one for each sampling period. If an audio application reads blocks covering
// 160 sampling periods from the input device, the timestamp would be increased by 160 for
// each such block, regardless of whether the block is transmitted in a packet or dropped as
// silent.
//
// The initial value of the timestamp should be random, as for the sequence number. Several
// consecutive RTP packets will have equal timestamps if they are (logically) generated at once,
// e.g., belong to the same video frame. Consecutive RTP packets may contain timestamps that
// are not monotonic if the data is not transmitted in the order it was sampled, as in the case
// of MPEG interpolated video frames. (The sequence numbers of the packets as transmitted
// will still be monotonic.)
//
// RTP timestamps from different media streams may advance at different rates and usually
// have independent, random offsets. Therefore, although these timestamps are sucient to
// reconstruct the timing of a single stream, directly comparing RTP timestamps from different
// media is not effective for synchronization. Instead, for each medium the RTP timestamp
// is related to the sampling instant by pairing it with a timestamp from a reference clock
// (wallclock) that represents the time when the data corresponding to the RTP timestamp was
// sampled. The reference clock is shared by all media to be synchronized. The timestamp
// pairs are not transmitted in every data packet, but at a lower rate in RTCP SR packets as
// described in Section 6.4.
//
// The sampling instant is chosen as the point of reference for the RTP timestamp because it is
// known to the transmitting endpoint and has a common definition for all media, independent
// of encoding delays or other processing. The purpose is to allow synchronized presentation of
// all media sampled at the same time.
//
// Applications transmitting stored data rather than data sampled in real time typically use a
// virtual presentation timeline derived from wallclock time to determine when the next frame
// or other unit of each medium in the stored data should be presented. In this case, the RTP
// timestamp would reflect the presentation time for each unit. That is, the RTP timestamp for
// each unit would be related to the wallclock time at which the unit becomes current on the
// virtual presentation timeline. Actual presentation occurs some time later as determined by
// The receiver.
//
// An example describing live audio narration of prerecorded video illustrates the significance
// of choosing the sampling instant as the reference point. In this scenario, the video would
// be presented locally for the narrator to view and would be simultaneously transmitted using
// RTP. The sampling instant" of a video frame transmitted in RTP would be established by
// referencing its timestamp to the wallclock time when that video frame was presented to the
// narrator. The sampling instant for the audio RTP packets containing the narrator's speech
// would be established by referencing the same wallclock time when the audio was sampled.
// The audio and video may even be transmitted by different hosts if the reference clocks on
// The two hosts are synchronized by some means such as NTP. A receiver can then synchronize
// presentation of the audio and video packets by relating their RTP timestamps using the
// timestamp pairs in RTCP SR packets.
uint32_t timestamp; //32bits
/**
* SSRC: 32 bits
* The SSRC field identifies the synchronization source. This identifier should be chosen
* randomly, with the intent that no two synchronization sources within the same RTP session
* will have the same SSRC identifier. An example algorithm for generating a random identifier
* is presented in Appendix A.6. Although the probability of multiple sources choosing the same
* identifier is low, all RTP implementations must be prepared to detect and resolve collisions.
* Section 8 describes the probability of collision along with a mechanism for resolving collisions
* and detecting RTP-level forwarding loops based on the uniqueness of the SSRC identifier. If
* a source changes its source transport address, it must also choose a new SSRC identifier to
* avoid being interpreted as a looped source (see Section 8.2).
*/
// The SSRC: 32 bits
// The SSRC field identifies the synchronization source. This identifier should be chosen
// randomly, with the intent that no two synchronization sources within the same RTP session
// will have the same SSRC identifier. An example algorithm for generating a random identifier
// is presented in Appendix A.6. Although the probability of multiple sources choosing the same
// identifier is low, all RTP implementations must be prepared to detect and resolve collisions.
// Section 8 describes the probability of collision along with a mechanism for resolving collisions
// and detecting RTP-level forwarding loops based on the uniqueness of the SSRC identifier. If
// a source changes its source transport address, it must also choose a new SSRC identifier to
// avoid being interpreted as a looped source (see Section 8.2).
uint32_t ssrc; //32bits
// the payload.
// The payload.
SrsSimpleStream* payload;
// whether transport in chunked payload.
// Whether transport in chunked payload.
bool chunked;
// whether message is completed.
// Whether message is completed.
// normal message always completed.
// while chunked completed when the last chunk arriaved.
bool completed;
/**
* the audio samples, one rtp packets may contains multiple audio samples.
*/
// The audio samples, one rtp packets may contains multiple audio samples.
SrsAudioFrame* audio;
public:
SrsRtpPacket();
virtual ~SrsRtpPacket();
public:
/**
* copy the header from src.
*/
// copy the header from src.
virtual void copy(SrsRtpPacket* src);
/**
* reap the src to this packet, reap the payload.
*/
// reap the src to this packet, reap the payload.
virtual void reap(SrsRtpPacket* src);
/**
* decode rtp packet from stream.
*/
// decode rtp packet from stream.
virtual srs_error_t decode(SrsBuffer* stream);
private:
virtual srs_error_t decode_97(SrsBuffer* stream);
virtual srs_error_t decode_96(SrsBuffer* stream);
};
/**
* the sdp in announce, @see rfc2326-1998-rtsp.pdf, page 159
* Appendix C: Use of SDP for RTSP Session Descriptions
* The Session Description Protocol (SDP, RFC 2327 [6]) may be used to
* describe streams or presentations in RTSP.
*/
// The sdp in announce, @see rfc2326-1998-rtsp.pdf, page 159
// Appendix C: Use of SDP for RTSP Session Descriptions
// The Session Description Protocol (SDP, RFC 2327 [6]) may be used to
// describe streams or presentations in RTSP.
class SrsRtspSdp
{
private:
SrsRtspSdpState state;
public:
/**
* the version of sdp.
*/
// The version of sdp.
std::string version;
/**
* the owner/creator of sdp.
*/
// The owner/creator of sdp.
std::string owner_username;
std::string owner_session_id;
std::string owner_session_version;
std::string owner_network_type;
std::string owner_address_type;
std::string owner_address;
/**
* the session name of sdp.
*/
// The session name of sdp.
std::string session_name;
/**
* the connection info of sdp.
*/
// The connection info of sdp.
std::string connection_network_type;
std::string connection_address_type;
std::string connection_address;
/**
* the tool attribute of sdp.
*/
// The tool attribute of sdp.
std::string tool;
/**
* the video attribute of sdp.
*/
// The video attribute of sdp.
std::string video_port;
std::string video_protocol;
std::string video_transport_format;
@ -363,13 +303,11 @@ public:
std::string video_codec;
std::string video_sample_rate;
std::string video_stream_id;
// fmtp
// The fmtp
std::string video_packetization_mode;
std::string video_sps; // sequence header: sps.
std::string video_pps; // sequence header: pps.
/**
* the audio attribute of sdp.
*/
// The audio attribute of sdp.
std::string audio_port;
std::string audio_protocol;
std::string audio_transport_format;
@ -378,7 +316,7 @@ public:
std::string audio_sample_rate;
std::string audio_channel;
std::string audio_stream_id;
// fmtp
// The fmtp
std::string audio_profile_level_id;
std::string audio_mode;
std::string audio_size_length;
@ -389,34 +327,24 @@ public:
SrsRtspSdp();
virtual ~SrsRtspSdp();
public:
/**
* parse a line of token for sdp.
*/
// Parse a line of token for sdp.
virtual srs_error_t parse(std::string token);
private:
/**
* generally, the fmtp is the sequence header for video or audio.
*/
// generally, the fmtp is the sequence header for video or audio.
virtual srs_error_t parse_fmtp_attribute(std::string attr);
/**
* generally, the control is the stream info for video or audio.
*/
// generally, the control is the stream info for video or audio.
virtual srs_error_t parse_control_attribute(std::string attr);
/**
* decode the string by base64.
*/
// decode the string by base64.
virtual std::string base64_decode(std::string value);
};
/**
* the rtsp transport.
* 12.39 Transport, @see rfc2326-1998-rtsp.pdf, page 115
* This request header indicates which transport protocol is to be used
* and configures its parameters such as destination address,
* compression, multicast time-to-live and destination port for a single
* stream. It sets those values not already determined by a presentation
* description.
*/
// The rtsp transport.
// 12.39 Transport, @see rfc2326-1998-rtsp.pdf, page 115
// This request header indicates which transport protocol is to be used
// and configures its parameters such as destination address,
// compression, multicast time-to-live and destination port for a single
// stream. It sets those values not already determined by a presentation
// description.
class SrsRtspTransport
{
public:
@ -431,7 +359,7 @@ public:
// Clients that are capable of handling both unicast and
// multicast transmission MUST indicate such capability by
// including two full transport-specs with separate parameters
// for each.
// For each.
std::string cast_type;
// The mode parameter indicates the methods to be supported for
// this session. Valid values are PLAY and RECORD. If not
@ -449,79 +377,59 @@ public:
SrsRtspTransport();
virtual ~SrsRtspTransport();
public:
/**
* parse a line of token for transport.
*/
// Parse a line of token for transport.
virtual srs_error_t parse(std::string attr);
};
/**
* the rtsp request message.
* 6 Request, @see rfc2326-1998-rtsp.pdf, page 39
* A request message from a client to a server or vice versa includes,
* within the first line of that message, the method to be applied to
* the resource, the identifier of the resource, and the protocol
* version in use.
* Request = Request-Line ; Section 6.1
* *( general-header ; Section 5
* | request-header ; Section 6.2
* | entity-header ) ; Section 8.1
* CRLF
* [ message-body ] ; Section 4.3
*/
// The rtsp request message.
// 6 Request, @see rfc2326-1998-rtsp.pdf, page 39
// A request message from a client to a server or vice versa includes,
// within the first line of that message, the method to be applied to
// The resource, the identifier of the resource, and the protocol
// version in use.
// Request = Request-Line ; Section 6.1
// // ( general-header ; Section 5
// | request-header ; Section 6.2
// | entity-header ) ; Section 8.1
// CRLF
// [ message-body ] ; Section 4.3
class SrsRtspRequest
{
public:
/**
* 6.1 Request Line
* Request-Line = Method SP Request-URI SP RTSP-Version CRLF
*/
// 6.1 Request Line
// Request-Line = Method SP Request-URI SP RTSP-Version CRLF
std::string method;
std::string uri;
std::string version;
/**
* 12.17 CSeq
* The CSeq field specifies the sequence number for an RTSP requestresponse
* pair. This field MUST be present in all requests and
* responses. For every RTSP request containing the given sequence
* number, there will be a corresponding response having the same
* number. Any retransmitted request must contain the same sequence
* number as the original (i.e. the sequence number is not incremented
* for retransmissions of the same request).
*/
// 12.17 CSeq
// The CSeq field specifies the sequence number for an RTSP requestresponse
// pair. This field MUST be present in all requests and
// responses. For every RTSP request containing the given sequence
// number, there will be a corresponding response having the same
// number. Any retransmitted request must contain the same sequence
// number as the original (i.e. the sequence number is not incremented
// For retransmissions of the same request).
long seq;
/**
* 12.16 Content-Type, @see rfc2326-1998-rtsp.pdf, page 99
* See [H14.18]. Note that the content types suitable for RTSP are
* likely to be restricted in practice to presentation descriptions and
* parameter-value types.
*/
// 12.16 Content-Type, @see rfc2326-1998-rtsp.pdf, page 99
// See [H14.18]. Note that the content types suitable for RTSP are
// likely to be restricted in practice to presentation descriptions and
// parameter-value types.
std::string content_type;
/**
* 12.14 Content-Length, @see rfc2326-1998-rtsp.pdf, page 99
* This field contains the length of the content of the method (i.e.
* after the double CRLF following the last header). Unlike HTTP, it
* MUST be included in all messages that carry content beyond the header
* portion of the message. If it is missing, a default value of zero is
* assumed. It is interpreted according to [H14.14].
*/
// 12.14 Content-Length, @see rfc2326-1998-rtsp.pdf, page 99
// This field contains the length of the content of the method (i.e.
// after the double CRLF following the last header). Unlike HTTP, it
// MUST be included in all messages that carry content beyond the header
// portion of the message. If it is missing, a default value of zero is
// assumed. It is interpreted according to [H14.14].
long content_length;
/**
* the session id.
*/
// The session id.
std::string session;
/**
* the sdp in announce, NULL for no sdp.
*/
// The sdp in announce, NULL for no sdp.
SrsRtspSdp* sdp;
/**
* the transport in setup, NULL for no transport.
*/
// The transport in setup, NULL for no transport.
SrsRtspTransport* transport;
/**
* for setup message, parse the stream id from uri.
*/
// For setup message, parse the stream id from uri.
int stream_id;
public:
SrsRtspRequest();
@ -533,79 +441,63 @@ public:
virtual bool is_record();
};
/**
* the rtsp response message.
* 7 Response, @see rfc2326-1998-rtsp.pdf, page 43
* [H6] applies except that HTTP-Version is replaced by RTSP-Version.
* Also, RTSP defines additional status codes and does not define some
* HTTP codes. 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.
* Response = Status-Line ; Section 7.1
* *( general-header ; Section 5
* | response-header ; Section 7.1.2
* | entity-header ) ; Section 8.1
* CRLF
* [ message-body ] ; Section 4.3
*/
// The rtsp response message.
// 7 Response, @see rfc2326-1998-rtsp.pdf, page 43
// [H6] applies except that HTTP-Version is replaced by RTSP-Version.
// Also, RTSP defines additional status codes and does not define some
// HTTP codes. 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.
// Response = Status-Line ; Section 7.1
// // ( general-header ; Section 5
// | response-header ; Section 7.1.2
// | entity-header ) ; Section 8.1
// CRLF
// [ message-body ] ; Section 4.3
class SrsRtspResponse
{
public:
/**
* 7.1 Status-Line
* The first line of a Response message is the Status-Line, consisting
* of the protocol version followed by a numeric status code, and the
* textual phrase associated with the status code, with each element
* separated by SP characters. No CR or LF is allowed except in the
* final CRLF sequence.
* Status-Line = RTSP-Version SP Status-Code SP Reason-Phrase CRLF
*/
// 7.1 Status-Line
// The first line of a Response message is the Status-Line, consisting
// of the protocol version followed by a numeric status code, and the
// textual phrase associated with the status code, with each element
// separated by SP characters. No CR or LF is allowed except in the
// final CRLF sequence.
// Status-Line = RTSP-Version SP Status-Code SP Reason-Phrase CRLF
// @see about the version of rtsp, see SRS_RTSP_VERSION
// @see about the status of rtsp, see SRS_CONSTS_RTSP_OK
int status;
/**
* 12.17 CSeq, @see rfc2326-1998-rtsp.pdf, page 99
* The CSeq field specifies the sequence number for an RTSP requestresponse
* pair. This field MUST be present in all requests and
* responses. For every RTSP request containing the given sequence
* number, there will be a corresponding response having the same
* number. Any retransmitted request must contain the same sequence
* number as the original (i.e. the sequence number is not incremented
* for retransmissions of the same request).
*/
// 12.17 CSeq, @see rfc2326-1998-rtsp.pdf, page 99
// The CSeq field specifies the sequence number for an RTSP requestresponse
// pair. This field MUST be present in all requests and
// responses. For every RTSP request containing the given sequence
// number, there will be a corresponding response having the same
// number. Any retransmitted request must contain the same sequence
// number as the original (i.e. the sequence number is not incremented
// For retransmissions of the same request).
long seq;
/**
* the session id.
*/
// The session id.
std::string session;
public:
SrsRtspResponse(int cseq);
virtual ~SrsRtspResponse();
public:
/**
* encode message to string.
*/
// Encode message to string.
virtual srs_error_t encode(std::stringstream& ss);
protected:
/**
* sub classes override this to encode the headers.
*/
// Sub classes override this to encode the headers.
virtual srs_error_t encode_header(std::stringstream& ss);
};
/**
* 10.1 OPTIONS, @see rfc2326-1998-rtsp.pdf, page 59
* The behavior is equivalent to that described in [H9.2]. An OPTIONS
* request may be issued at any time, e.g., if the client is about to
* try a nonstandard request. It does not influence server state.
*/
// 10.1 OPTIONS, @see rfc2326-1998-rtsp.pdf, page 59
// The behavior is equivalent to that described in [H9.2]. An OPTIONS
// request may be issued at any time, e.g., if the client is about to
// try a nonstandard request. It does not influence server state.
class SrsRtspOptionsResponse : public SrsRtspResponse
{
public:
/**
* join of SrsRtspMethod
*/
// Join of SrsRtspMethod
SrsRtspMethod methods;
public:
SrsRtspOptionsResponse(int cseq);
@ -614,28 +506,26 @@ protected:
virtual srs_error_t encode_header(std::stringstream& ss);
};
/**
* 10.4 SETUP, @see rfc2326-1998-rtsp.pdf, page 65
* The SETUP request for a URI specifies the transport mechanism to be
* used for the streamed media. A client can issue a SETUP request for a
* stream that is already playing to change transport parameters, which
* a server MAY allow. If it does not allow this, it MUST respond with
* error "455 Method Not Valid In This State". 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.
*/
// 10.4 SETUP, @see rfc2326-1998-rtsp.pdf, page 65
// The SETUP request for a URI specifies the transport mechanism to be
// used for the streamed media. A client can issue a SETUP request for a
// stream that is already playing to change transport parameters, which
// a server MAY allow. If it does not allow this, it MUST respond with
// error "455 Method Not Valid In This State". 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.
class SrsRtspSetupResponse : public SrsRtspResponse
{
public:
// the client specified port.
// The client specified port.
int client_port_min;
int client_port_max;
// client will use the port in:
// The client will use the port in:
// [local_port_min, local_port_max)
int local_port_min;
int local_port_max;
// session.
// The session.
std::string session;
public:
SrsRtspSetupResponse(int cseq);
@ -644,65 +534,45 @@ protected:
virtual srs_error_t encode_header(std::stringstream& ss);
};
/**
* the rtsp protocol stack to parse the rtsp packets.
*/
// The rtsp protocol stack to parse the rtsp packets.
class SrsRtspStack
{
private:
/**
* cached bytes buffer.
*/
// The cached bytes buffer.
SrsSimpleStream* buf;
/**
* underlayer socket object, send/recv bytes.
*/
// The underlayer socket object, send/recv bytes.
ISrsProtocolReadWriter* skt;
public:
SrsRtspStack(ISrsProtocolReadWriter* s);
virtual ~SrsRtspStack();
public:
/**
* recv rtsp message from underlayer io.
* @param preq the output rtsp request message, which user must free it.
* @return an int error code.
* ERROR_RTSP_REQUEST_HEADER_EOF indicates request header EOF.
*/
// Recv rtsp message from underlayer io.
// @param preq the output rtsp request message, which user must free it.
// @return an int error code.
// ERROR_RTSP_REQUEST_HEADER_EOF indicates request header EOF.
virtual srs_error_t recv_message(SrsRtspRequest** preq);
/**
* send rtsp message over underlayer io.
* @param res the rtsp response message, which user should never free it.
* @return an int error code.
*/
// Send rtsp message over underlayer io.
// @param res the rtsp response message, which user should never free it.
// @return an int error code.
virtual srs_error_t send_message(SrsRtspResponse* res);
private:
/**
* recv the rtsp message.
*/
// Recv the rtsp message.
virtual srs_error_t do_recv_message(SrsRtspRequest* req);
/**
* read a normal token from io, error when token state is not normal.
*/
// Read a normal token from io, error when token state is not normal.
virtual srs_error_t recv_token_normal(std::string& token);
/**
* read a normal token from io, error when token state is not eof.
*/
// Read a normal token from io, error when token state is not eof.
virtual srs_error_t recv_token_eof(std::string& token);
/**
* read the token util got eof, for example, to read the response status Reason-Phrase
* @param pconsumed, output the token parsed length. NULL to ignore.
*/
// Read the token util got eof, for example, to read the response status Reason-Phrase
// @param pconsumed, output the token parsed length. NULL to ignore.
virtual srs_error_t recv_token_util_eof(std::string& token, int* pconsumed = NULL);
/**
* read a token from io, split by SP, endswith CRLF:
* token1 SP token2 SP ... tokenN CRLF
* @param token, output the read token.
* @param state, output the token parse state.
* @param normal_ch, the char to indicates the normal token.
* the SP use to indicates the normal token, @see SRS_RTSP_SP
* the 0x00 use to ignore normal token flag. @see recv_token_util_eof
* @param pconsumed, output the token parsed length. NULL to ignore.
*/
// Read a token from io, split by SP, endswith CRLF:
// token1 SP token2 SP ... tokenN CRLF
// @param token, output the read token.
// @param state, output the token parse state.
// @param normal_ch, the char to indicates the normal token.
// the SP use to indicates the normal token, @see SRS_RTSP_SP
// the 0x00 use to ignore normal token flag. @see recv_token_util_eof
// @param pconsumed, output the token parsed length. NULL to ignore.
virtual srs_error_t recv_token(std::string& token, SrsRtspTokenState& state, char normal_ch = SRS_RTSP_SP, int* pconsumed = NULL);
};