‹header›
‹date/time›
Click to edit Master text styles
Second level
Third level
Fourth level
Fifth level
‹footer›
‹#›
Version: The version field identifies the version of RTP, which is currently version 2
Padding (P): Some protocols or algorithms require a packet to be a specific size. The
padding field is a variable field that fills space to make the header the proper size.
CSRC count: The CSRC field contains the number of CSRC identifiers that follow the
fixed header.
Marker: The marker field is used in specific applications to identify groups of RTP packets.
Payload type: This field identifies what type of information is in the payload portion
of the RTP packet and is used by applications to determine how to handle the packet.
Sequence number: The sequence number keeps a count of RTP packets by Real-Time Transport Protocol
incrementing the field by one for each packet that is sent, and is used to detect
packet loss and to maintain the sequence of the packets that are received.
Timestamp: The timestamp field records the time when the RTP packet was
created and is derived from a clock that increments monotonically and linearly
in time to allow synchronization and jitter calculations.
Synchronization source (SSRC): The SSRC field contains a randomly
generated 32-bit number to identify individual RTP sessions for the purpose of
separating individual RTP sessions and synchronizing the data transmission
across multiple end-points.
Contributing source (CSRC): The CSRC field is another layer of
identification for sessions that have the same SSRC number, but the data in the
stream needs to be differentiated further. For example, in a conference call, all
the RTP packets in the session would contain the same SSRC identifier but the
CSRC could be used to identify each caller who is speaking.
QoS monitoring and congestion control
Provides feedback to an application about the quality of data distribution
Sender can adjust its transmission based on the receiver report feedback
Receivers can know whether a congestion is local, regional or global
Source identification
RTCP SDES (source description) packets contain textual information called canonical names as globally unique identifiers of the session participants
It may include user's name, telephone number, email address and other information
Session size estimation and scaling
All participants send periodic RTCP packets
Transmission rate of RTCP packets must be reduced as the number of participants increases
RFC 1889 limits RTCP traffic to less than 5% of session bandwidth, divided between sender reports (25%) and receiver reports (75%)
Session control
Optional function to convey minimal session control information, for example, participant identification to be displayed in the user interface
Synchronizing high and low bandwidth users:
Consider the case where participants in one area are connected through a low-speed link to the majority of the conference participants who enjoy high-speed network access. Instead of forcing everyone to use a lower-bandwidth, reduced-quality audio encoding, an RTP-level relay called a mixer may be placed near the low-bandwidth area. This mixer resynchronizes incoming audio packets to reconstruct the constant 20 ms spacing generated by the sender, mixes these reconstructed audio streams into a single stream, translates the audio encoding to a lower-bandwidth one and forwards the lower- bandwidth packet stream across the low-speed link.
BANDWIDTH ISSUES
RTP is designed to allow an application to scale automatically over session sizes ranging from a few participants to thousands. In an audio conference the data traffic is inherently self- limiting because only one or two people will speak at a time, so with  multicast distribution the data rate on any given link remains relatively constant independent of the number of participants. However, the control traffic is not self-limiting. If the reception  reports from each participant were sent at a constant rate, the control traffic would grow linearly with the number of participants.
To maintain scalability, the average interval between packets from a session participant should scale with the group size. The control traffic should be limited to a small and known fraction of the session bandwidth:
a) Small so that the primary function of the   transport protocol to carry data is not impaired;
b) Known so that each participant can  independently calculate its share.
It is suggested that the fraction of the session bandwidth allocated to RTCP be fixed at 5%.
MIXER BASICS
1) Receives streams of RTP data packets from one or more sources,  possibly changes the data format, combines the streams in some manner and then forwards the combined stream.
2) All data packets forwarded by a  mixer will be marked with the mixer's own SSRC identifier. In order to preserve the identity of the original sources contributing to the mixed packet.
TRANSLATORS
1) Forwards RTP packets with their SSRC identifier intact.
2) May change the encoding of the data and thus the RTP data payload type.
RTPCreate():
The first of the first of these is RTPCreate(), which establishes a context. A context is an identifier used by the library to determine which RTP session a function call is to be associated with. An application can run many sessions at the same time, each created with a separate call to RTPCreate, resulting in a different context for each.
RTPSessionSetBandwidth():
RTCP packets are sent at a rate that depends on the session bandwidth. This is a global parameter for the RTP session. The application should set this value before calling RTPOpenConnection() in order to ensure proper RTCP transmission rates. If it is not set, the default rate of 120 kbps.
RTPMemberInfoSetSDES():
One RTCP packet type, SDES, contains information about each user. This includes the name, email, and CNAME for the user. It is the responsibility of the application to set these fields. In particular, the CNAME field MUST be set prior to calling RTPOpenConnection. All of the other SDES fields are optional.
RTPSend():
The RTPSend() function is used to tell the library to send an RTP packet. It requires the user to pass a pointer to a buffer, a length, a value for the marker field in the RTP header, an increment for the timestamp, and the context. The library will take the buffer, add the RTP header, perform any required operations, and send the packet. The library will automatically send RTCP packets. The initial timestamp and sequence number are chosen randomly.
RTPReceive():
In order to know if a packet is available for reading, a process can block, it can poll, or use any other kind of mechanism. The library does not dictate this policy, it is up to the user to determine when data is available for reading.
Steps involved in receiving a packet:
1. The functions RTPSessionGetRTPSocket() and RTPSessionGetRTCPSocket() are used. They take as input the context and a pointer to a socket. When they return, the socket has been filled in. The user application may then check for the presence on an RTP packet on these sockets in any fashion.
2. When a packet is present on either socket, the application calls the function RTPReceive(). This function takes the context, the socket on which data is present, a pointer to a buffer, and a pointer to a length value. The length value should be initialized to the amount of room in the buffer. The library will read and process the RTP or RTCP packet. For RTCP, it will perform all statistics collection and parsing. Generally, there will be no further action required from the user. For an RTP packet, the library will also update some statistics and variables. The buffer will be filled in with the entire RTP/RTCP packet, including the header.
3. Once RTPReceive() is complete, the user may want to access data in the packet if it is an RTP packet. However, the packet in the original buffer used in the RTPReceive still contains the header. To gain access to the header fields, and the payload, the function RTPGetRTPPacket() is provided. This function accepts the buffer as an input, and returns a pointer to an RTP packet structure. This pointer is of type rtp_packet, and contains fields for the various RTP headers, and a pointer to the payload. The user application can then access these fields for whatever purposes it likes.
RTPCloseConnection():
When the function RTPCloseConnection() is called, it closes all active receive sockets, sends a BYE packet, and then closes all send sockets. It does not delete internal storage or statistics that have been collected, however. RTPCloseConnection() accepts a reason string. This string is sent in the BYE packet. If set to NULL, the library will not include any reason in the BYE.
RTPDestroy():
It destroys all internal information about the session. It takes the context as its sole argument, and frees all memory associated with the context.
GET SESSION INFORMATION
RTPMemberInfoGetStatus()
The function retrieves the member and sender status for a particular user.
RTPMemberInfoGetRTPAddr()
The function returns the address and port a user is sending RTP packets from. If the user is a contributor, the address is that of the mixer sending the packets.
RTPMemberInfoGetPktCnt()
This function returns the packet count reported in the last sender report from the given user. This function should only be called for users who are CONFIRMED senders. Operation on non-confirmed senders is undefined.
RTPMemberInfoGetUserInfo()
This function retrieves the user info field for a particular member. This field is never used by the library. It is provided as a convenience to application developers, allowing them to use the library's member management structures to store application specific information.
RTPSessionGetBandwidth()
This function writes the value of the session bandwidth and RTCP fraction into the given variables.
RTPFindMember()
This function is used to obtain a handle to a person by searching based on a specific criteria, such as email, phone, cname, etc. It is useful mostly for finding users based on CNAME for correlation across multiple sessions. Member lists can be generically obtained by using the RTPSessionGetMemberList() function.
ADVANCED FUNCTIONS
RTPSplitCompoundRTCP()
The function “int RTPSplitCompoundRTCP (char *rtcppacket, char *indpkts[], long len)” takes the raw RTCP packet received on the socket, and splits it into the individual RTCP packets (this is because an RTCP data packet can contain many RTCP packets inside of it).
RTPGetRTCPPacket()
The function “rtcp_packet RTPGetRTCPPacket (char *rtcppacket)” takes a pointer to an individual RTCP packet character string that composes the RTCP packet. It returns a pointer to an rtcp_packet. This is a structure which contains the various common header fields (version, type, count, etc.) and the parts specific to the particular RTCP packet.