Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3550

RTP: A Transport Protocol for Real-Time Applications

Pages: 104
Internet Standard: 64
Errata
Obsoletes:  1889
Updated by:  5506576160516222702271607164808381088860
Part 2 of 4 – Pages 19 to 53
First   Prev   Next

Top   ToC   RFC3550 - Page 19   prevText

6. RTP Control Protocol -- RTCP

The RTP control protocol (RTCP) is based on the periodic transmission of control packets to all participants in the session, using the same distribution mechanism as the data packets. The underlying protocol MUST provide multiplexing of the data and control packets, for example using separate port numbers with UDP. RTCP performs four functions: 1. The primary function is to provide feedback on the quality of the data distribution. This is an integral part of the RTP's role as a transport protocol and is related to the flow and congestion control functions of other transport protocols (see Section 10 on the requirement for congestion control). The feedback may be directly useful for control of adaptive encodings [18,19], but experiments with IP multicasting have shown that it is also
Top   ToC   RFC3550 - Page 20
      critical to get feedback from the receivers to diagnose faults in
      the distribution.  Sending reception feedback reports to all
      participants allows one who is observing problems to evaluate
      whether those problems are local or global.  With a distribution
      mechanism like IP multicast, it is also possible for an entity
      such as a network service provider who is not otherwise involved
      in the session to receive the feedback information and act as a
      third-party monitor to diagnose network problems.  This feedback
      function is performed by the RTCP sender and receiver reports,
      described below in Section 6.4.

   2. RTCP carries a persistent transport-level identifier for an RTP
      source called the canonical name or CNAME, Section 6.5.1.  Since
      the SSRC identifier may change if a conflict is discovered or a
      program is restarted, receivers require the CNAME to keep track of
      each participant.  Receivers may also require the CNAME to
      associate multiple data streams from a given participant in a set
      of related RTP sessions, for example to synchronize audio and
      video.  Inter-media synchronization also requires the NTP and RTP
      timestamps included in RTCP packets by data senders.

   3. The first two functions require that all participants send RTCP
      packets, therefore the rate must be controlled in order for RTP to
      scale up to a large number of participants.  By having each
      participant send its control packets to all the others, each can
      independently observe the number of participants.  This number is
      used to calculate the rate at which the packets are sent, as
      explained in Section 6.2.

   4. A fourth, OPTIONAL function is to convey minimal session control
      information, for example participant identification to be
      displayed in the user interface.  This is most likely to be useful
      in "loosely controlled" sessions where participants enter and
      leave without membership control or parameter negotiation.  RTCP
      serves as a convenient channel to reach all the participants, but
      it is not necessarily expected to support all the control
      communication requirements of an application.  A higher-level
      session control protocol, which is beyond the scope of this
      document, may be needed.

   Functions 1-3 SHOULD be used in all environments, but particularly in
   the IP multicast environment.  RTP application designers SHOULD avoid
   mechanisms that can only work in unicast mode and will not scale to
   larger numbers.  Transmission of RTCP MAY be controlled separately
   for senders and receivers, as described in Section 6.2, for cases
   such as unidirectional links where feedback from receivers is not
   possible.
Top   ToC   RFC3550 - Page 21
   Non-normative note:  In the multicast routing approach
      called Source-Specific Multicast (SSM), there is only one sender
      per "channel" (a source address, group address pair), and
      receivers (except for the channel source) cannot use multicast to
      communicate directly with other channel members.  The
      recommendations here accommodate SSM only through Section 6.2's
      option of turning off receivers' RTCP entirely.  Future work will
      specify adaptation of RTCP for SSM so that feedback from receivers
      can be maintained.

6.1 RTCP Packet Format

This specification defines several RTCP packet types to carry a variety of control information: SR: Sender report, for transmission and reception statistics from participants that are active senders RR: Receiver report, for reception statistics from participants that are not active senders and in combination with SR for active senders reporting on more than 31 sources SDES: Source description items, including CNAME BYE: Indicates end of participation APP: Application-specific functions Each RTCP packet begins with a fixed part similar to that of RTP data packets, followed by structured elements that MAY be of variable length according to the packet type but MUST end on a 32-bit boundary. The alignment requirement and a length field in the fixed part of each packet are included to make RTCP packets "stackable". Multiple RTCP packets can be concatenated without any intervening separators to form a compound RTCP packet that is sent in a single packet of the lower layer protocol, for example UDP. There is no explicit count of individual RTCP packets in the compound packet since the lower layer protocols are expected to provide an overall length to determine the end of the compound packet. Each individual RTCP packet in the compound packet may be processed independently with no requirements upon the order or combination of packets. However, in order to perform the functions of the protocol, the following constraints are imposed:
Top   ToC   RFC3550 - Page 22
   o  Reception statistics (in SR or RR) should be sent as often as
      bandwidth constraints will allow to maximize the resolution of the
      statistics, therefore each periodically transmitted compound RTCP
      packet MUST include a report packet.

   o  New receivers need to receive the CNAME for a source as soon as
      possible to identify the source and to begin associating media for
      purposes such as lip-sync, so each compound RTCP packet MUST also
      include the SDES CNAME except when the compound RTCP packet is
      split for partial encryption as described in Section 9.1.

   o  The number of packet types that may appear first in the compound
      packet needs to be limited to increase the number of constant bits
      in the first word and the probability of successfully validating
      RTCP packets against misaddressed RTP data packets or other
      unrelated packets.

   Thus, all RTCP packets MUST be sent in a compound packet of at least
   two individual packets, with the following format:

   Encryption prefix:  If and only if the compound packet is to be
      encrypted according to the method in Section 9.1, it MUST be
      prefixed by a random 32-bit quantity redrawn for every compound
      packet transmitted.  If padding is required for the encryption, it
      MUST be added to the last packet of the compound packet.

   SR or RR:  The first RTCP packet in the compound packet MUST
      always be a report packet to facilitate header validation as
      described in Appendix A.2.  This is true even if no data has been
      sent or received, in which case an empty RR MUST be sent, and even
      if the only other RTCP packet in the compound packet is a BYE.

   Additional RRs:  If the number of sources for which reception
      statistics are being reported exceeds 31, the number that will fit
      into one SR or RR packet, then additional RR packets SHOULD follow
      the initial report packet.

   SDES:  An SDES packet containing a CNAME item MUST be included
      in each compound RTCP packet, except as noted in Section 9.1.
      Other source description items MAY optionally be included if
      required by a particular application, subject to bandwidth
      constraints (see Section 6.3.9).

   BYE or APP:  Other RTCP packet types, including those yet to be
      defined, MAY follow in any order, except that BYE SHOULD be the
      last packet sent with a given SSRC/CSRC.  Packet types MAY appear
      more than once.
Top   ToC   RFC3550 - Page 23
   An individual RTP participant SHOULD send only one compound RTCP
   packet per report interval in order for the RTCP bandwidth per
   participant to be estimated correctly (see Section 6.2), except when
   the compound RTCP packet is split for partial encryption as described
   in Section 9.1.  If there are too many sources to fit all the
   necessary RR packets into one compound RTCP packet without exceeding
   the maximum transmission unit (MTU) of the network path, then only
   the subset that will fit into one MTU SHOULD be included in each
   interval.  The subsets SHOULD be selected round-robin across multiple
   intervals so that all sources are reported.

   It is RECOMMENDED that translators and mixers combine individual RTCP
   packets from the multiple sources they are forwarding into one
   compound packet whenever feasible in order to amortize the packet
   overhead (see Section 7).  An example RTCP compound packet as might
   be produced by a mixer is shown in Fig. 1.  If the overall length of
   a compound packet would exceed the MTU of the network path, it SHOULD
   be segmented into multiple shorter compound packets to be transmitted
   in separate packets of the underlying protocol.  This does not impair
   the RTCP bandwidth estimation because each compound packet represents
   at least one distinct participant.  Note that each of the compound
   packets MUST begin with an SR or RR packet.

   An implementation SHOULD ignore incoming RTCP packets with types
   unknown to it.  Additional RTCP packet types may be registered with
   the Internet Assigned Numbers Authority (IANA) as described in
   Section 15.

   if encrypted: random 32-bit integer
   |
   |[--------- packet --------][---------- packet ----------][-packet-]
   |
   |                receiver            chunk        chunk
   V                reports           item  item   item  item
   --------------------------------------------------------------------
   R[SR #sendinfo #site1#site2][SDES #CNAME PHONE #CNAME LOC][BYE##why]
   --------------------------------------------------------------------
   |                                                                  |
   |<-----------------------  compound packet ----------------------->|
   |<--------------------------  UDP packet ------------------------->|

   #: SSRC/CSRC identifier

              Figure 1: Example of an RTCP compound packet
Top   ToC   RFC3550 - Page 24

6.2 RTCP Transmission Interval

RTP is designed to allow an application to scale automatically over session sizes ranging from a few participants to thousands. For example, 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. Therefore, the rate must be scaled down by dynamically calculating the interval between RTCP packet transmissions. For each session, it is assumed that the data traffic is subject to an aggregate limit called the "session bandwidth" to be divided among the participants. This bandwidth might be reserved and the limit enforced by the network. If there is no reservation, there may be other constraints, depending on the environment, that establish the "reasonable" maximum for the session to use, and that would be the session bandwidth. The session bandwidth may be chosen based on some cost or a priori knowledge of the available network bandwidth for the session. It is somewhat independent of the media encoding, but the encoding choice may be limited by the session bandwidth. Often, the session bandwidth is the sum of the nominal bandwidths of the senders expected to be concurrently active. For teleconference audio, this number would typically be one sender's bandwidth. For layered encodings, each layer is a separate RTP session with its own session bandwidth parameter. The session bandwidth parameter is expected to be supplied by a session management application when it invokes a media application, but media applications MAY set a default based on the single-sender data bandwidth for the encoding selected for the session. The application MAY also enforce bandwidth limits based on multicast scope rules or other criteria. All participants MUST use the same value for the session bandwidth so that the same RTCP interval will be calculated. Bandwidth calculations for control and data traffic include lower- layer transport and network protocols (e.g., UDP and IP) since that is what the resource reservation system would need to know. The application can also be expected to know which of these protocols are in use. Link level headers are not included in the calculation since the packet will be encapsulated with different link level headers as it travels.
Top   ToC   RFC3550 - Page 25
   The control traffic should be limited to a small and known fraction
   of the session bandwidth: small so that the primary function of the
   transport protocol to carry data is not impaired; known so that the
   control traffic can be included in the bandwidth specification given
   to a resource reservation protocol, and so that each participant can
   independently calculate its share.  The control traffic bandwidth is
   in addition to the session bandwidth for the data traffic.  It is
   RECOMMENDED that the fraction of the session bandwidth added for RTCP
   be fixed at 5%.  It is also RECOMMENDED that 1/4 of the RTCP
   bandwidth be dedicated to participants that are sending data so that
   in sessions with a large number of receivers but a small number of
   senders, newly joining participants will more quickly receive the
   CNAME for the sending sites.  When the proportion of senders is
   greater than 1/4 of the participants, the senders get their
   proportion of the full RTCP bandwidth.  While the values of these and
   other constants in the interval calculation are not critical, all
   participants in the session MUST use the same values so the same
   interval will be calculated.  Therefore, these constants SHOULD be
   fixed for a particular profile.

   A profile MAY specify that the control traffic bandwidth may be a
   separate parameter of the session rather than a strict percentage of
   the session bandwidth.  Using a separate parameter allows rate-
   adaptive applications to set an RTCP bandwidth consistent with a
   "typical" data bandwidth that is lower than the maximum bandwidth
   specified by the session bandwidth parameter.

   The profile MAY further specify that the control traffic bandwidth
   may be divided into two separate session parameters for those
   participants which are active data senders and those which are not;
   let us call the parameters S and R.  Following the recommendation
   that 1/4 of the RTCP bandwidth be dedicated to data senders, the
   RECOMMENDED default values for these two parameters would be 1.25%
   and 3.75%, respectively.  When the proportion of senders is greater
   than S/(S+R) of the participants, the senders get their proportion of
   the sum of these parameters.  Using two parameters allows RTCP
   reception reports to be turned off entirely for a particular session
   by setting the RTCP bandwidth for non-data-senders to zero while
   keeping the RTCP bandwidth for data senders non-zero so that sender
   reports can still be sent for inter-media synchronization.  Turning
   off RTCP reception reports is NOT RECOMMENDED because they are needed
   for the functions listed at the beginning of Section 6, particularly
   reception quality feedback and congestion control.  However, doing so
   may be appropriate for systems operating on unidirectional links or
   for sessions that don't require feedback on the quality of reception
   or liveness of receivers and that have other means to avoid
   congestion.
Top   ToC   RFC3550 - Page 26
   The calculated interval between transmissions of compound RTCP
   packets SHOULD also have a lower bound to avoid having bursts of
   packets exceed the allowed bandwidth when the number of participants
   is small and the traffic isn't smoothed according to the law of large
   numbers.  It also keeps the report interval from becoming too small
   during transient outages like a network partition such that
   adaptation is delayed when the partition heals.  At application
   startup, a delay SHOULD be imposed before the first compound RTCP
   packet is sent to allow time for RTCP packets to be received from
   other participants so the report interval will converge to the
   correct value more quickly.  This delay MAY be set to half the
   minimum interval to allow quicker notification that the new
   participant is present.  The RECOMMENDED value for a fixed minimum
   interval is 5 seconds.

   An implementation MAY scale the minimum RTCP interval to a smaller
   value inversely proportional to the session bandwidth parameter with
   the following limitations:

   o  For multicast sessions, only active data senders MAY use the
      reduced minimum value to calculate the interval for transmission
      of compound RTCP packets.

   o  For unicast sessions, the reduced value MAY be used by
      participants that are not active data senders as well, and the
      delay before sending the initial compound RTCP packet MAY be zero.

   o  For all sessions, the fixed minimum SHOULD be used when
      calculating the participant timeout interval (see Section 6.3.5)
      so that implementations which do not use the reduced value for
      transmitting RTCP packets are not timed out by other participants
      prematurely.

   o  The RECOMMENDED value for the reduced minimum in seconds is 360
      divided by the session bandwidth in kilobits/second.  This minimum
      is smaller than 5 seconds for bandwidths greater than 72 kb/s.

   The algorithm described in Section 6.3 and Appendix A.7 was designed
   to meet the goals outlined in this section.  It calculates the
   interval between sending compound RTCP packets to divide the allowed
   control traffic bandwidth among the participants.  This allows an
   application to provide fast response for small sessions where, for
   example, identification of all participants is important, yet
   automatically adapt to large sessions.  The algorithm incorporates
   the following characteristics:
Top   ToC   RFC3550 - Page 27
   o  The calculated interval between RTCP packets scales linearly with
      the number of members in the group.  It is this linear factor
      which allows for a constant amount of control traffic when summed
      across all members.

   o  The interval between RTCP packets is varied randomly over the
      range [0.5,1.5] times the calculated interval to avoid unintended
      synchronization of all participants [20].  The first RTCP packet
      sent after joining a session is also delayed by a random variation
      of half the minimum RTCP interval.

   o  A dynamic estimate of the average compound RTCP packet size is
      calculated, including all those packets received and sent, to
      automatically adapt to changes in the amount of control
      information carried.

   o  Since the calculated interval is dependent on the number of
      observed group members, there may be undesirable startup effects
      when a new user joins an existing session, or many users
      simultaneously join a new session.  These new users will initially
      have incorrect estimates of the group membership, and thus their
      RTCP transmission interval will be too short.  This problem can be
      significant if many users join the session simultaneously.  To
      deal with this, an algorithm called "timer reconsideration" is
      employed.  This algorithm implements a simple back-off mechanism
      which causes users to hold back RTCP packet transmission if the
      group sizes are increasing.

   o  When users leave a session, either with a BYE or by timeout, the
      group membership decreases, and thus the calculated interval
      should decrease.  A "reverse reconsideration" algorithm is used to
      allow members to more quickly reduce their intervals in response
      to group membership decreases.

   o  BYE packets are given different treatment than other RTCP packets.
      When a user leaves a group, and wishes to send a BYE packet, it
      may do so before its next scheduled RTCP packet.  However,
      transmission of BYEs follows a back-off algorithm which avoids
      floods of BYE packets should a large number of members
      simultaneously leave the session.

   This algorithm may be used for sessions in which all participants are
   allowed to send.  In that case, the session bandwidth parameter is
   the product of the individual sender's bandwidth times the number of
   participants, and the RTCP bandwidth is 5% of that.

   Details of the algorithm's operation are given in the sections that
   follow.  Appendix A.7 gives an example implementation.
Top   ToC   RFC3550 - Page 28

6.2.1 Maintaining the Number of Session Members

Calculation of the RTCP packet interval depends upon an estimate of the number of sites participating in the session. New sites are added to the count when they are heard, and an entry for each SHOULD be created in a table indexed by the SSRC or CSRC identifier (see Section 8.2) to keep track of them. New entries MAY be considered not valid until multiple packets carrying the new SSRC have been received (see Appendix A.1), or until an SDES RTCP packet containing a CNAME for that SSRC has been received. Entries MAY be deleted from the table when an RTCP BYE packet with the corresponding SSRC identifier is received, except that some straggler data packets might arrive after the BYE and cause the entry to be recreated. Instead, the entry SHOULD be marked as having received a BYE and then deleted after an appropriate delay. A participant MAY mark another site inactive, or delete it if not yet valid, if no RTP or RTCP packet has been received for a small number of RTCP report intervals (5 is RECOMMENDED). This provides some robustness against packet loss. All sites must have the same value for this multiplier and must calculate roughly the same value for the RTCP report interval in order for this timeout to work properly. Therefore, this multiplier SHOULD be fixed for a particular profile. For sessions with a very large number of participants, it may be impractical to maintain a table to store the SSRC identifier and state information for all of them. An implementation MAY use SSRC sampling, as described in [21], to reduce the storage requirements. An implementation MAY use any other algorithm with similar performance. A key requirement is that any algorithm considered SHOULD NOT substantially underestimate the group size, although it MAY overestimate.

6.3 RTCP Packet Send and Receive Rules

The rules for how to send, and what to do when receiving an RTCP packet are outlined here. An implementation that allows operation in a multicast environment or a multipoint unicast environment MUST meet the requirements in Section 6.2. Such an implementation MAY use the algorithm defined in this section to meet those requirements, or MAY use some other algorithm so long as it provides equivalent or better performance. An implementation which is constrained to two-party unicast operation SHOULD still use randomization of the RTCP transmission interval to avoid unintended synchronization of multiple instances operating in the same environment, but MAY omit the "timer reconsideration" and "reverse reconsideration" algorithms in Sections 6.3.3, 6.3.6 and 6.3.7.
Top   ToC   RFC3550 - Page 29
   To execute these rules, a session participant must maintain several
   pieces of state:

   tp: the last time an RTCP packet was transmitted;

   tc: the current time;

   tn: the next scheduled transmission time of an RTCP packet;

   pmembers: the estimated number of session members at the time tn
      was last recomputed;

   members: the most current estimate for the number of session
      members;

   senders: the most current estimate for the number of senders in
      the session;

   rtcp_bw: The target RTCP bandwidth, i.e., the total bandwidth
      that will be used for RTCP packets by all members of this session,
      in octets per second.  This will be a specified fraction of the
      "session bandwidth" parameter supplied to the application at
      startup.

   we_sent: Flag that is true if the application has sent data
      since the 2nd previous RTCP report was transmitted.

   avg_rtcp_size: The average compound RTCP packet size, in octets,
      over all RTCP packets sent and received by this participant.  The
      size includes lower-layer transport and network protocol headers
      (e.g., UDP and IP) as explained in Section 6.2.

   initial: Flag that is true if the application has not yet sent
      an RTCP packet.

   Many of these rules make use of the "calculated interval" between
   packet transmissions.  This interval is described in the following
   section.

6.3.1 Computing the RTCP Transmission Interval

To maintain scalability, the average interval between packets from a session participant should scale with the group size. This interval is called the calculated interval. It is obtained by combining a number of the pieces of state described above. The calculated interval T is then determined as follows:
Top   ToC   RFC3550 - Page 30
   1. If the number of senders is less than or equal to 25% of the
      membership (members), the interval depends on whether the
      participant is a sender or not (based on the value of we_sent).
      If the participant is a sender (we_sent true), the constant C is
      set to the average RTCP packet size (avg_rtcp_size) divided by 25%
      of the RTCP bandwidth (rtcp_bw), and the constant n is set to the
      number of senders.  If we_sent is not true, the constant C is set
      to the average RTCP packet size divided by 75% of the RTCP
      bandwidth.  The constant n is set to the number of receivers
      (members - senders).  If the number of senders is greater than
      25%, senders and receivers are treated together.  The constant C
      is set to the average RTCP packet size divided by the total RTCP
      bandwidth and n is set to the total number of members.  As stated
      in Section 6.2, an RTP profile MAY specify that the RTCP bandwidth
      may be explicitly defined by two separate parameters (call them S
      and R) for those participants which are senders and those which
      are not.  In that case, the 25% fraction becomes S/(S+R) and the
      75% fraction becomes R/(S+R).  Note that if R is zero, the
      percentage of senders is never greater than S/(S+R), and the
      implementation must avoid division by zero.

   2. If the participant has not yet sent an RTCP packet (the variable
      initial is true), the constant Tmin is set to 2.5 seconds, else it
      is set to 5 seconds.

   3. The deterministic calculated interval Td is set to max(Tmin, n*C).

   4. The calculated interval T is set to a number uniformly distributed
      between 0.5 and 1.5 times the deterministic calculated interval.

   5. The resulting value of T is divided by e-3/2=1.21828 to compensate
      for the fact that the timer reconsideration algorithm converges to
      a value of the RTCP bandwidth below the intended average.

   This procedure results in an interval which is random, but which, on
   average, gives at least 25% of the RTCP bandwidth to senders and the
   rest to receivers.  If the senders constitute more than one quarter
   of the membership, this procedure splits the bandwidth equally among
   all participants, on average.

6.3.2 Initialization

Upon joining the session, the participant initializes tp to 0, tc to 0, senders to 0, pmembers to 1, members to 1, we_sent to false, rtcp_bw to the specified fraction of the session bandwidth, initial to true, and avg_rtcp_size to the probable size of the first RTCP packet that the application will later construct. The calculated interval T is then computed, and the first packet is scheduled for
Top   ToC   RFC3550 - Page 31
   time tn = T.  This means that a transmission timer is set which
   expires at time T.  Note that an application MAY use any desired
   approach for implementing this timer.

   The participant adds its own SSRC to the member table.

6.3.3 Receiving an RTP or Non-BYE RTCP Packet

When an RTP or RTCP packet is received from a participant whose SSRC is not in the member table, the SSRC is added to the table, and the value for members is updated once the participant has been validated as described in Section 6.2.1. The same processing occurs for each CSRC in a validated RTP packet. When an RTP packet is received from a participant whose SSRC is not in the sender table, the SSRC is added to the table, and the value for senders is updated. For each compound RTCP packet received, the value of avg_rtcp_size is updated: avg_rtcp_size = (1/16) * packet_size + (15/16) * avg_rtcp_size where packet_size is the size of the RTCP packet just received.

6.3.4 Receiving an RTCP BYE Packet

Except as described in Section 6.3.7 for the case when an RTCP BYE is to be transmitted, if the received packet is an RTCP BYE packet, the SSRC is checked against the member table. If present, the entry is removed from the table, and the value for members is updated. The SSRC is then checked against the sender table. If present, the entry is removed from the table, and the value for senders is updated. Furthermore, to make the transmission rate of RTCP packets more adaptive to changes in group membership, the following "reverse reconsideration" algorithm SHOULD be executed when a BYE packet is received that reduces members to a value less than pmembers: o The value for tn is updated according to the following formula: tn = tc + (members/pmembers) * (tn - tc) o The value for tp is updated according the following formula: tp = tc - (members/pmembers) * (tc - tp).
Top   ToC   RFC3550 - Page 32
   o  The next RTCP packet is rescheduled for transmission at time tn,
      which is now earlier.

   o  The value of pmembers is set equal to members.

   This algorithm does not prevent the group size estimate from
   incorrectly dropping to zero for a short time due to premature
   timeouts when most participants of a large session leave at once but
   some remain.  The algorithm does make the estimate return to the
   correct value more rapidly.  This situation is unusual enough and the
   consequences are sufficiently harmless that this problem is deemed
   only a secondary concern.

6.3.5 Timing Out an SSRC

At occasional intervals, the participant MUST check to see if any of the other participants time out. To do this, the participant computes the deterministic (without the randomization factor) calculated interval Td for a receiver, that is, with we_sent false. Any other session member who has not sent an RTP or RTCP packet since time tc - MTd (M is the timeout multiplier, and defaults to 5) is timed out. This means that its SSRC is removed from the member list, and members is updated. A similar check is performed on the sender list. Any member on the sender list who has not sent an RTP packet since time tc - 2T (within the last two RTCP report intervals) is removed from the sender list, and senders is updated. If any members time out, the reverse reconsideration algorithm described in Section 6.3.4 SHOULD be performed. The participant MUST perform this check at least once per RTCP transmission interval.

6.3.6 Expiration of Transmission Timer

When the packet transmission timer expires, the participant performs the following operations: o The transmission interval T is computed as described in Section 6.3.1, including the randomization factor. o If tp + T is less than or equal to tc, an RTCP packet is transmitted. tp is set to tc, then another value for T is calculated as in the previous step and tn is set to tc + T. The transmission timer is set to expire again at time tn. If tp + T is greater than tc, tn is set to tp + T. No RTCP packet is transmitted. The transmission timer is set to expire at time tn.
Top   ToC   RFC3550 - Page 33
   o  pmembers is set to members.

   If an RTCP packet is transmitted, the value of initial is set to
   FALSE.  Furthermore, the value of avg_rtcp_size is updated:

      avg_rtcp_size = (1/16) * packet_size + (15/16) * avg_rtcp_size

   where packet_size is the size of the RTCP packet just transmitted.

6.3.7 Transmitting a BYE Packet

When a participant wishes to leave a session, a BYE packet is transmitted to inform the other participants of the event. In order to avoid a flood of BYE packets when many participants leave the system, a participant MUST execute the following algorithm if the number of members is more than 50 when the participant chooses to leave. This algorithm usurps the normal role of the members variable to count BYE packets instead: o When the participant decides to leave the system, tp is reset to tc, the current time, members and pmembers are initialized to 1, initial is set to 1, we_sent is set to false, senders is set to 0, and avg_rtcp_size is set to the size of the compound BYE packet. The calculated interval T is computed. The BYE packet is then scheduled for time tn = tc + T. o Every time a BYE packet from another participant is received, members is incremented by 1 regardless of whether that participant exists in the member table or not, and when SSRC sampling is in use, regardless of whether or not the BYE SSRC would be included in the sample. members is NOT incremented when other RTCP packets or RTP packets are received, but only for BYE packets. Similarly, avg_rtcp_size is updated only for received BYE packets. senders is NOT updated when RTP packets arrive; it remains 0. o Transmission of the BYE packet then follows the rules for transmitting a regular RTCP packet, as above. This allows BYE packets to be sent right away, yet controls their total bandwidth usage. In the worst case, this could cause RTCP control packets to use twice the bandwidth as normal (10%) -- 5% for non-BYE RTCP packets and 5% for BYE. A participant that does not want to wait for the above mechanism to allow transmission of a BYE packet MAY leave the group without sending a BYE at all. That participant will eventually be timed out by the other group members.
Top   ToC   RFC3550 - Page 34
   If the group size estimate members is less than 50 when the
   participant decides to leave, the participant MAY send a BYE packet
   immediately.  Alternatively, the participant MAY choose to execute
   the above BYE backoff algorithm.

   In either case, a participant which never sent an RTP or RTCP packet
   MUST NOT send a BYE packet when they leave the group.

6.3.8 Updating we_sent

The variable we_sent contains true if the participant has sent an RTP packet recently, false otherwise. This determination is made by using the same mechanisms as for managing the set of other participants listed in the senders table. If the participant sends an RTP packet when we_sent is false, it adds itself to the sender table and sets we_sent to true. The reverse reconsideration algorithm described in Section 6.3.4 SHOULD be performed to possibly reduce the delay before sending an SR packet. Every time another RTP packet is sent, the time of transmission of that packet is maintained in the table. The normal sender timeout algorithm is then applied to the participant -- if an RTP packet has not been transmitted since time tc - 2T, the participant removes itself from the sender table, decrements the sender count, and sets we_sent to false.

6.3.9 Allocation of Source Description Bandwidth

This specification defines several source description (SDES) items in addition to the mandatory CNAME item, such as NAME (personal name) and EMAIL (email address). It also provides a means to define new application-specific RTCP packet types. Applications should exercise caution in allocating control bandwidth to this additional information because it will slow down the rate at which reception reports and CNAME are sent, thus impairing the performance of the protocol. It is RECOMMENDED that no more than 20% of the RTCP bandwidth allocated to a single participant be used to carry the additional information. Furthermore, it is not intended that all SDES items will be included in every application. Those that are included SHOULD be assigned a fraction of the bandwidth according to their utility. Rather than estimate these fractions dynamically, it is recommended that the percentages be translated statically into report interval counts based on the typical length of an item. For example, an application may be designed to send only CNAME, NAME and EMAIL and not any others. NAME might be given much higher priority than EMAIL because the NAME would be displayed continuously in the application's user interface, whereas EMAIL would be displayed only when requested. At every RTCP interval, an RR packet and an SDES packet with the CNAME item would be sent. For a small session
Top   ToC   RFC3550 - Page 35
   operating at the minimum interval, that would be every 5 seconds on
   the average.  Every third interval (15 seconds), one extra item would
   be included in the SDES packet.  Seven out of eight times this would
   be the NAME item, and every eighth time (2 minutes) it would be the
   EMAIL item.

   When multiple applications operate in concert using cross-application
   binding through a common CNAME for each participant, for example in a
   multimedia conference composed of an RTP session for each medium, the
   additional SDES information MAY be sent in only one RTP session.  The
   other sessions would carry only the CNAME item.  In particular, this
   approach should be applied to the multiple sessions of a layered
   encoding scheme (see Section 2.4).

6.4 Sender and Receiver Reports

RTP receivers provide reception quality feedback using RTCP report packets which may take one of two forms depending upon whether or not the receiver is also a sender. The only difference between the sender report (SR) and receiver report (RR) forms, besides the packet type code, is that the sender report includes a 20-byte sender information section for use by active senders. The SR is issued if a site has sent any data packets during the interval since issuing the last report or the previous one, otherwise the RR is issued. Both the SR and RR forms include zero or more reception report blocks, one for each of the synchronization sources from which this receiver has received RTP data packets since the last report. Reports are not issued for contributing sources listed in the CSRC list. Each reception report block provides statistics about the data received from the particular source indicated in that block. Since a maximum of 31 reception report blocks will fit in an SR or RR packet, additional RR packets SHOULD be stacked after the initial SR or RR packet as needed to contain the reception reports for all sources heard during the interval since the last report. If there are too many sources to fit all the necessary RR packets into one compound RTCP packet without exceeding the MTU of the network path, then only the subset that will fit into one MTU SHOULD be included in each interval. The subsets SHOULD be selected round-robin across multiple intervals so that all sources are reported. The next sections define the formats of the two reports, how they may be extended in a profile-specific manner if an application requires additional feedback information, and how the reports may be used. Details of reception reporting by translators and mixers is given in Section 7.
Top   ToC   RFC3550 - Page 36

6.4.1 SR: Sender Report RTCP Packet

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ header |V=2|P| RC | PT=SR=200 | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of sender | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ sender | NTP timestamp, most significant word | info +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NTP timestamp, least significant word | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sender's packet count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sender's octet count | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ report | SSRC_1 (SSRC of first source) | block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | fraction lost | cumulative number of packets lost | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | extended highest sequence number received | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | interarrival jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | last SR (LSR) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | delay since last SR (DLSR) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ report | SSRC_2 (SSRC of second source) | block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 : ... : +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | profile-specific extensions | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The sender report packet consists of three sections, possibly followed by a fourth profile-specific extension section if defined. The first section, the header, is 8 octets long. The fields have the following meaning: version (V): 2 bits Identifies the version of RTP, which is the same in RTCP packets as in RTP data packets. The version defined by this specification is two (2).
Top   ToC   RFC3550 - Page 37
   padding (P): 1 bit
      If the padding bit is set, this individual RTCP packet contains
      some additional padding octets at the end which are not part of
      the control information but are included in the length field.  The
      last octet of the padding is a count of how many padding octets
      should be ignored, including itself (it will be a multiple of
      four).  Padding may be needed by some encryption algorithms with
      fixed block sizes.  In a compound RTCP packet, padding is only
      required on one individual packet because the compound packet is
      encrypted as a whole for the method in Section 9.1.  Thus, padding
      MUST only be added to the last individual packet, and if padding
      is added to that packet, the padding bit MUST be set only on that
      packet.  This convention aids the header validity checks described
      in Appendix A.2 and allows detection of packets from some early
      implementations that incorrectly set the padding bit on the first
      individual packet and add padding to the last individual packet.

   reception report count (RC): 5 bits
      The number of reception report blocks contained in this packet.  A
      value of zero is valid.

   packet type (PT): 8 bits
      Contains the constant 200 to identify this as an RTCP SR packet.

   length: 16 bits
      The length of this RTCP packet in 32-bit words minus one,
      including the header and any padding.  (The offset of one makes
      zero a valid length and avoids a possible infinite loop in
      scanning a compound RTCP packet, while counting 32-bit words
      avoids a validity check for a multiple of 4.)

   SSRC: 32 bits
      The synchronization source identifier for the originator of this
      SR packet.

   The second section, the sender information, is 20 octets long and is
   present in every sender report packet.  It summarizes the data
   transmissions from this sender.  The fields have the following
   meaning:

   NTP timestamp: 64 bits
      Indicates the wallclock time (see Section 4) when this report was
      sent so that it may be used in combination with timestamps
      returned in reception reports from other receivers to measure
      round-trip propagation to those receivers.  Receivers should
      expect that the measurement accuracy of the timestamp may be
      limited to far less than the resolution of the NTP timestamp.  The
      measurement uncertainty of the timestamp is not indicated as it
Top   ToC   RFC3550 - Page 38
      may not be known.  On a system that has no notion of wallclock
      time but does have some system-specific clock such as "system
      uptime", a sender MAY use that clock as a reference to calculate
      relative NTP timestamps.  It is important to choose a commonly
      used clock so that if separate implementations are used to produce
      the individual streams of a multimedia session, all
      implementations will use the same clock.  Until the year 2036,
      relative and absolute timestamps will differ in the high bit so
      (invalid) comparisons will show a large difference; by then one
      hopes relative timestamps will no longer be needed.  A sender that
      has no notion of wallclock or elapsed time MAY set the NTP
      timestamp to zero.

   RTP timestamp: 32 bits
      Corresponds to the same time as the NTP timestamp (above), but in
      the same units and with the same random offset as the RTP
      timestamps in data packets.  This correspondence may be used for
      intra- and inter-media synchronization for sources whose NTP
      timestamps are synchronized, and may be used by media-independent
      receivers to estimate the nominal RTP clock frequency.  Note that
      in most cases this timestamp will not be equal to the RTP
      timestamp in any adjacent data packet.  Rather, it MUST be
      calculated from the corresponding NTP timestamp using the
      relationship between the RTP timestamp counter and real time as
      maintained by periodically checking the wallclock time at a
      sampling instant.

   sender's packet count: 32 bits
      The total number of RTP data packets transmitted by the sender
      since starting transmission up until the time this SR packet was
      generated.  The count SHOULD be reset if the sender changes its
      SSRC identifier.

   sender's octet count: 32 bits
      The total number of payload octets (i.e., not including header or
      padding) transmitted in RTP data packets by the sender since
      starting transmission up until the time this SR packet was
      generated.  The count SHOULD be reset if the sender changes its
      SSRC identifier.  This field can be used to estimate the average
      payload data rate.

   The third section contains zero or more reception report blocks
   depending on the number of other sources heard by this sender since
   the last report.  Each reception report block conveys statistics on
   the reception of RTP packets from a single synchronization source.
   Receivers SHOULD NOT carry over statistics when a source changes its
   SSRC identifier due to a collision.  These statistics are:
Top   ToC   RFC3550 - Page 39
   SSRC_n (source identifier): 32 bits
      The SSRC identifier of the source to which the information in this
      reception report block pertains.

   fraction lost: 8 bits
      The fraction of RTP data packets from source SSRC_n lost since the
      previous SR or RR packet was sent, expressed as a fixed point
      number with the binary point at the left edge of the field.  (That
      is equivalent to taking the integer part after multiplying the
      loss fraction by 256.)  This fraction is defined to be the number
      of packets lost divided by the number of packets expected, as
      defined in the next paragraph.  An implementation is shown in
      Appendix A.3.  If the loss is negative due to duplicates, the
      fraction lost is set to zero.  Note that a receiver cannot tell
      whether any packets were lost after the last one received, and
      that there will be no reception report block issued for a source
      if all packets from that source sent during the last reporting
      interval have been lost.

   cumulative number of packets lost: 24 bits
      The total number of RTP data packets from source SSRC_n that have
      been lost since the beginning of reception.  This number is
      defined to be the number of packets expected less the number of
      packets actually received, where the number of packets received
      includes any which are late or duplicates.  Thus, packets that
      arrive late are not counted as lost, and the loss may be negative
      if there are duplicates.  The number of packets expected is
      defined to be the extended last sequence number received, as
      defined next, less the initial sequence number received.  This may
      be calculated as shown in Appendix A.3.

   extended highest sequence number received: 32 bits
      The low 16 bits contain the highest sequence number received in an
      RTP data packet from source SSRC_n, and the most significant 16
      bits extend that sequence number with the corresponding count of
      sequence number cycles, which may be maintained according to the
      algorithm in Appendix A.1.  Note that different receivers within
      the same session will generate different extensions to the
      sequence number if their start times differ significantly.

   interarrival jitter: 32 bits
      An estimate of the statistical variance of the RTP data packet
      interarrival time, measured in timestamp units and expressed as an
      unsigned integer.  The interarrival jitter J is defined to be the
      mean deviation (smoothed absolute value) of the difference D in
      packet spacing at the receiver compared to the sender for a pair
      of packets.  As shown in the equation below, this is equivalent to
      the difference in the "relative transit time" for the two packets;
Top   ToC   RFC3550 - Page 40
      the relative transit time is the difference between a packet's RTP
      timestamp and the receiver's clock at the time of arrival,
      measured in the same units.

      If Si is the RTP timestamp from packet i, and Ri is the time of
      arrival in RTP timestamp units for packet i, then for two packets
      i and j, D may be expressed as

         D(i,j) = (Rj - Ri) - (Sj - Si) = (Rj - Sj) - (Ri - Si)

      The interarrival jitter SHOULD be calculated continuously as each
      data packet i is received from source SSRC_n, using this
      difference D for that packet and the previous packet i-1 in order
      of arrival (not necessarily in sequence), according to the formula

         J(i) = J(i-1) + (|D(i-1,i)| - J(i-1))/16

      Whenever a reception report is issued, the current value of J is
      sampled.

      The jitter calculation MUST conform to the formula specified here
      in order to allow profile-independent monitors to make valid
      interpretations of reports coming from different implementations.
      This algorithm is the optimal first-order estimator and the gain
      parameter 1/16 gives a good noise reduction ratio while
      maintaining a reasonable rate of convergence [22].  A sample
      implementation is shown in Appendix A.8.  See Section 6.4.4 for a
      discussion of the effects of varying packet duration and delay
      before transmission.

   last SR timestamp (LSR): 32 bits
      The middle 32 bits out of 64 in the NTP timestamp (as explained in
      Section 4) received as part of the most recent RTCP sender report
      (SR) packet from source SSRC_n.  If no SR has been received yet,
      the field is set to zero.

   delay since last SR (DLSR): 32 bits
      The delay, expressed in units of 1/65536 seconds, between
      receiving the last SR packet from source SSRC_n and sending this
      reception report block.  If no SR packet has been received yet
      from SSRC_n, the DLSR field is set to zero.

      Let SSRC_r denote the receiver issuing this receiver report.
      Source SSRC_n can compute the round-trip propagation delay to
      SSRC_r by recording the time A when this reception report block is
      received.  It calculates the total round-trip time A-LSR using the
      last SR timestamp (LSR) field, and then subtracting this field to
      leave the round-trip propagation delay as (A - LSR - DLSR).  This
Top   ToC   RFC3550 - Page 41
      is illustrated in Fig. 2.  Times are shown in both a hexadecimal
      representation of the 32-bit fields and the equivalent floating-
      point decimal representation.  Colons indicate a 32-bit field
      divided into a 16-bit integer part and 16-bit fraction part.

      This may be used as an approximate measure of distance to cluster
      receivers, although some links have very asymmetric delays.

   [10 Nov 1995 11:33:25.125 UTC]       [10 Nov 1995 11:33:36.5 UTC]
   n                 SR(n)              A=b710:8000 (46864.500 s)
   ---------------------------------------------------------------->
                      v                 ^
   ntp_sec =0xb44db705 v               ^ dlsr=0x0005:4000 (    5.250s)
   ntp_frac=0x20000000  v             ^  lsr =0xb705:2000 (46853.125s)
     (3024992005.125 s)  v           ^
   r                      v         ^ RR(n)
   ---------------------------------------------------------------->
                          |<-DLSR->|
                           (5.250 s)

   A     0xb710:8000 (46864.500 s)
   DLSR -0x0005:4000 (    5.250 s)
   LSR  -0xb705:2000 (46853.125 s)
   -------------------------------
   delay 0x0006:2000 (    6.125 s)

           Figure 2: Example for round-trip time computation
Top   ToC   RFC3550 - Page 42

6.4.2 RR: Receiver Report RTCP Packet

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ header |V=2|P| RC | PT=RR=201 | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of packet sender | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ report | SSRC_1 (SSRC of first source) | block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | fraction lost | cumulative number of packets lost | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | extended highest sequence number received | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | interarrival jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | last SR (LSR) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | delay since last SR (DLSR) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ report | SSRC_2 (SSRC of second source) | block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 : ... : +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | profile-specific extensions | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format of the receiver report (RR) packet is the same as that of the SR packet except that the packet type field contains the constant 201 and the five words of sender information are omitted (these are the NTP and RTP timestamps and sender's packet and octet counts). The remaining fields have the same meaning as for the SR packet. An empty RR packet (RC = 0) MUST be put at the head of a compound RTCP packet when there is no data transmission or reception to report.

6.4.3 Extending the Sender and Receiver Reports

A profile SHOULD define profile-specific extensions to the sender report and receiver report if there is additional information that needs to be reported regularly about the sender or receivers. This method SHOULD be used in preference to defining another RTCP packet type because it requires less overhead: o fewer octets in the packet (no RTCP header or SSRC field);
Top   ToC   RFC3550 - Page 43
   o  simpler and faster parsing because applications running under that
      profile would be programmed to always expect the extension fields
      in the directly accessible location after the reception reports.

   The extension is a fourth section in the sender- or receiver-report
   packet which comes at the end after the reception report blocks, if
   any.  If additional sender information is required, then for sender
   reports it would be included first in the extension section, but for
   receiver reports it would not be present.  If information about
   receivers is to be included, that data SHOULD be structured as an
   array of blocks parallel to the existing array of reception report
   blocks; that is, the number of blocks would be indicated by the RC
   field.

6.4.4 Analyzing Sender and Receiver Reports

It is expected that reception quality feedback will be useful not only for the sender but also for other receivers and third-party monitors. The sender may modify its transmissions based on the feedback; receivers can determine whether problems are local, regional or global; network managers may use profile-independent monitors that receive only the RTCP packets and not the corresponding RTP data packets to evaluate the performance of their networks for multicast distribution. Cumulative counts are used in both the sender information and receiver report blocks so that differences may be calculated between any two reports to make measurements over both short and long time periods, and to provide resilience against the loss of a report. The difference between the last two reports received can be used to estimate the recent quality of the distribution. The NTP timestamp is included so that rates may be calculated from these differences over the interval between two reports. Since that timestamp is independent of the clock rate for the data encoding, it is possible to implement encoding- and profile-independent quality monitors. An example calculation is the packet loss rate over the interval between two reception reports. The difference in the cumulative number of packets lost gives the number lost during that interval. The difference in the extended last sequence numbers received gives the number of packets expected during the interval. The ratio of these two is the packet loss fraction over the interval. This ratio should equal the fraction lost field if the two reports are consecutive, but otherwise it may not. The loss rate per second can be obtained by dividing the loss fraction by the difference in NTP timestamps, expressed in seconds. The number of packets received is the number of packets expected minus the number lost. The number of
Top   ToC   RFC3550 - Page 44
   packets expected may also be used to judge the statistical validity
   of any loss estimates.  For example, 1 out of 5 packets lost has a
   lower significance than 200 out of 1000.

   From the sender information, a third-party monitor can calculate the
   average payload data rate and the average packet rate over an
   interval without receiving the data.  Taking the ratio of the two
   gives the average payload size.  If it can be assumed that packet
   loss is independent of packet size, then the number of packets
   received by a particular receiver times the average payload size (or
   the corresponding packet size) gives the apparent throughput
   available to that receiver.

   In addition to the cumulative counts which allow long-term packet
   loss measurements using differences between reports, the fraction
   lost field provides a short-term measurement from a single report.
   This becomes more important as the size of a session scales up enough
   that reception state information might not be kept for all receivers
   or the interval between reports becomes long enough that only one
   report might have been received from a particular receiver.

   The interarrival jitter field provides a second short-term measure of
   network congestion.  Packet loss tracks persistent congestion while
   the jitter measure tracks transient congestion.  The jitter measure
   may indicate congestion before it leads to packet loss.  The
   interarrival jitter field is only a snapshot of the jitter at the
   time of a report and is not intended to be taken quantitatively.
   Rather, it is intended for comparison across a number of reports from
   one receiver over time or from multiple receivers, e.g., within a
   single network, at the same time.  To allow comparison across
   receivers, it is important the the jitter be calculated according to
   the same formula by all receivers.

   Because the jitter calculation is based on the RTP timestamp which
   represents the instant when the first data in the packet was sampled,
   any variation in the delay between that sampling instant and the time
   the packet is transmitted will affect the resulting jitter that is
   calculated.  Such a variation in delay would occur for audio packets
   of varying duration.  It will also occur for video encodings because
   the timestamp is the same for all the packets of one frame but those
   packets are not all transmitted at the same time.  The variation in
   delay until transmission does reduce the accuracy of the jitter
   calculation as a measure of the behavior of the network by itself,
   but it is appropriate to include considering that the receiver buffer
   must accommodate it.  When the jitter calculation is used as a
   comparative measure, the (constant) component due to variation in
   delay until transmission subtracts out so that a change in the
Top   ToC   RFC3550 - Page 45
   network jitter component can then be observed unless it is relatively
   small.  If the change is small, then it is likely to be
   inconsequential.

6.5 SDES: Source Description RTCP Packet

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ header |V=2|P| SC | PT=SDES=202 | length | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ chunk | SSRC/CSRC_1 | 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SDES items | | ... | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ chunk | SSRC/CSRC_2 | 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SDES items | | ... | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ The SDES packet is a three-level structure composed of a header and zero or more chunks, each of which is composed of items describing the source identified in that chunk. The items are described individually in subsequent sections. version (V), padding (P), length: As described for the SR packet (see Section 6.4.1). packet type (PT): 8 bits Contains the constant 202 to identify this as an RTCP SDES packet. source count (SC): 5 bits The number of SSRC/CSRC chunks contained in this SDES packet. A value of zero is valid but useless. Each chunk consists of an SSRC/CSRC identifier followed by a list of zero or more items, which carry information about the SSRC/CSRC. Each chunk starts on a 32-bit boundary. Each item consists of an 8- bit type field, an 8-bit octet count describing the length of the text (thus, not including this two-octet header), and the text itself. Note that the text can be no longer than 255 octets, but this is consistent with the need to limit RTCP bandwidth consumption.
Top   ToC   RFC3550 - Page 46
   The text is encoded according to the UTF-8 encoding specified in RFC
   2279 [5].  US-ASCII is a subset of this encoding and requires no
   additional encoding.  The presence of multi-octet encodings is
   indicated by setting the most significant bit of a character to a
   value of one.

   Items are contiguous, i.e., items are not individually padded to a
   32-bit boundary.  Text is not null terminated because some multi-
   octet encodings include null octets.  The list of items in each chunk
   MUST be terminated by one or more null octets, the first of which is
   interpreted as an item type of zero to denote the end of the list.
   No length octet follows the null item type octet, but additional null
   octets MUST be included if needed to pad until the next 32-bit
   boundary.  Note that this padding is separate from that indicated by
   the P bit in the RTCP header.  A chunk with zero items (four null
   octets) is valid but useless.

   End systems send one SDES packet containing their own source
   identifier (the same as the SSRC in the fixed RTP header).  A mixer
   sends one SDES packet containing a chunk for each contributing source
   from which it is receiving SDES information, or multiple complete
   SDES packets in the format above if there are more than 31 such
   sources (see Section 7).

   The SDES items currently defined are described in the next sections.
   Only the CNAME item is mandatory.  Some items shown here may be
   useful only for particular profiles, but the item types are all
   assigned from one common space to promote shared use and to simplify
   profile-independent applications.  Additional items may be defined in
   a profile by registering the type numbers with IANA as described in
   Section 15.

6.5.1 CNAME: Canonical End-Point Identifier SDES Item

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CNAME=1 | length | user and domain name ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The CNAME identifier has the following properties: o Because the randomly allocated SSRC identifier may change if a conflict is discovered or if a program is restarted, the CNAME item MUST be included to provide the binding from the SSRC identifier to an identifier for the source (sender or receiver) that remains constant.
Top   ToC   RFC3550 - Page 47
   o  Like the SSRC identifier, the CNAME identifier SHOULD also be
      unique among all participants within one RTP session.

   o  To provide a binding across multiple media tools used by one
      participant in a set of related RTP sessions, the CNAME SHOULD be
      fixed for that participant.

   o  To facilitate third-party monitoring, the CNAME SHOULD be suitable
      for either a program or a person to locate the source.

   Therefore, the CNAME SHOULD be derived algorithmically and not
   entered manually, when possible.  To meet these requirements, the
   following format SHOULD be used unless a profile specifies an
   alternate syntax or semantics.  The CNAME item SHOULD have the format
   "user@host", or "host" if a user name is not available as on single-
   user systems.  For both formats, "host" is either the fully qualified
   domain name of the host from which the real-time data originates,
   formatted according to the rules specified in RFC 1034 [6], RFC 1035
   [7] and Section 2.1 of RFC 1123 [8]; or the standard ASCII
   representation of the host's numeric address on the interface used
   for the RTP communication.  For example, the standard ASCII
   representation of an IP Version 4 address is "dotted decimal", also
   known as dotted quad, and for IP Version 6, addresses are textually
   represented as groups of hexadecimal digits separated by colons (with
   variations as detailed in RFC 3513 [23]).  Other address types are
   expected to have ASCII representations that are mutually unique.  The
   fully qualified domain name is more convenient for a human observer
   and may avoid the need to send a NAME item in addition, but it may be
   difficult or impossible to obtain reliably in some operating
   environments.  Applications that may be run in such environments
   SHOULD use the ASCII representation of the address instead.

   Examples are "doe@sleepy.example.com", "doe@192.0.2.89" or
   "doe@2201:056D::112E:144A:1E24" for a multi-user system.  On a system
   with no user name, examples would be "sleepy.example.com",
   "192.0.2.89" or "2201:056D::112E:144A:1E24".

   The user name SHOULD be in a form that a program such as "finger" or
   "talk" could use, i.e., it typically is the login name rather than
   the personal name.  The host name is not necessarily identical to the
   one in the participant's electronic mail address.

   This syntax will not provide unique identifiers for each source if an
   application permits a user to generate multiple sources from one
   host.  Such an application would have to rely on the SSRC to further
   identify the source, or the profile for that application would have
   to specify additional syntax for the CNAME identifier.
Top   ToC   RFC3550 - Page 48
   If each application creates its CNAME independently, the resulting
   CNAMEs may not be identical as would be required to provide a binding
   across multiple media tools belonging to one participant in a set of
   related RTP sessions.  If cross-media binding is required, it may be
   necessary for the CNAME of each tool to be externally configured with
   the same value by a coordination tool.

   Application writers should be aware that private network address
   assignments such as the Net-10 assignment proposed in RFC 1918 [24]
   may create network addresses that are not globally unique.  This
   would lead to non-unique CNAMEs if hosts with private addresses and
   no direct IP connectivity to the public Internet have their RTP
   packets forwarded to the public Internet through an RTP-level
   translator.  (See also RFC 1627 [25].)  To handle this case,
   applications MAY provide a means to configure a unique CNAME, but the
   burden is on the translator to translate CNAMEs from private
   addresses to public addresses if necessary to keep private addresses
   from being exposed.

6.5.2 NAME: User Name SDES Item

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NAME=2 | length | common name of source ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This is the real name used to describe the source, e.g., "John Doe, Bit Recycler". It may be in any form desired by the user. For applications such as conferencing, this form of name may be the most desirable for display in participant lists, and therefore might be sent most frequently of those items other than CNAME. Profiles MAY establish such priorities. The NAME value is expected to remain constant at least for the duration of a session. It SHOULD NOT be relied upon to be unique among all participants in the session.

6.5.3 EMAIL: Electronic Mail Address SDES Item

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EMAIL=3 | length | email address of source ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The email address is formatted according to RFC 2822 [9], for example, "John.Doe@example.com". The EMAIL value is expected to remain constant for the duration of a session.
Top   ToC   RFC3550 - Page 49

6.5.4 PHONE: Phone Number SDES Item

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PHONE=4 | length | phone number of source ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The phone number SHOULD be formatted with the plus sign replacing the international access code. For example, "+1 908 555 1212" for a number in the United States.

6.5.5 LOC: Geographic User Location SDES Item

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LOC=5 | length | geographic location of site ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Depending on the application, different degrees of detail are appropriate for this item. For conference applications, a string like "Murray Hill, New Jersey" may be sufficient, while, for an active badge system, strings like "Room 2A244, AT&T BL MH" might be appropriate. The degree of detail is left to the implementation and/or user, but format and content MAY be prescribed by a profile. The LOC value is expected to remain constant for the duration of a session, except for mobile hosts.

6.5.6 TOOL: Application or Tool Name SDES Item

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TOOL=6 | length |name/version of source appl. ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A string giving the name and possibly version of the application generating the stream, e.g., "videotool 1.2". This information may be useful for debugging purposes and is similar to the Mailer or Mail-System-Version SMTP headers. The TOOL value is expected to remain constant for the duration of the session.
Top   ToC   RFC3550 - Page 50

6.5.7 NOTE: Notice/Status SDES Item

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NOTE=7 | length | note about the source ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The following semantics are suggested for this item, but these or other semantics MAY be explicitly defined by a profile. The NOTE item is intended for transient messages describing the current state of the source, e.g., "on the phone, can't talk". Or, during a seminar, this item might be used to convey the title of the talk. It should be used only to carry exceptional information and SHOULD NOT be included routinely by all participants because this would slow down the rate at which reception reports and CNAME are sent, thus impairing the performance of the protocol. In particular, it SHOULD NOT be included as an item in a user's configuration file nor automatically generated as in a quote-of-the-day. Since the NOTE item may be important to display while it is active, the rate at which other non-CNAME items such as NAME are transmitted might be reduced so that the NOTE item can take that part of the RTCP bandwidth. When the transient message becomes inactive, the NOTE item SHOULD continue to be transmitted a few times at the same repetition rate but with a string of length zero to signal the receivers. However, receivers SHOULD also consider the NOTE item inactive if it is not received for a small multiple of the repetition rate, or perhaps 20-30 RTCP intervals.

6.5.8 PRIV: Private Extensions SDES Item

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PRIV=8 | length | prefix length |prefix string... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | value string ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This item is used to define experimental or application-specific SDES extensions. The item contains a prefix consisting of a length-string pair, followed by the value string filling the remainder of the item and carrying the desired information. The prefix length field is 8 bits long. The prefix string is a name chosen by the person defining the PRIV item to be unique with respect to other PRIV items this application might receive. The application creator might choose to use the application name plus an additional subtype identification if
Top   ToC   RFC3550 - Page 51
   needed.  Alternatively, it is RECOMMENDED that others choose a name
   based on the entity they represent, then coordinate the use of the
   name within that entity.

   Note that the prefix consumes some space within the item's total
   length of 255 octets, so the prefix should be kept as short as
   possible.  This facility and the constrained RTCP bandwidth SHOULD
   NOT be overloaded; it is not intended to satisfy all the control
   communication requirements of all applications.

   SDES PRIV prefixes will not be registered by IANA.  If some form of
   the PRIV item proves to be of general utility, it SHOULD instead be
   assigned a regular SDES item type registered with IANA so that no
   prefix is required.  This simplifies use and increases transmission
   efficiency.

6.6 BYE: Goodbye RTCP Packet

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P| SC | PT=BYE=203 | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC/CSRC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ (opt) | length | reason for leaving ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The BYE packet indicates that one or more sources are no longer active. version (V), padding (P), length: As described for the SR packet (see Section 6.4.1). packet type (PT): 8 bits Contains the constant 203 to identify this as an RTCP BYE packet. source count (SC): 5 bits The number of SSRC/CSRC identifiers included in this BYE packet. A count value of zero is valid, but useless. The rules for when a BYE packet should be sent are specified in Sections 6.3.7 and 8.2.
Top   ToC   RFC3550 - Page 52
   If a BYE packet is received by a mixer, the mixer SHOULD forward the
   BYE packet with the SSRC/CSRC identifier(s) unchanged.  If a mixer
   shuts down, it SHOULD send a BYE packet listing all contributing
   sources it handles, as well as its own SSRC identifier.  Optionally,
   the BYE packet MAY include an 8-bit octet count followed by that many
   octets of text indicating the reason for leaving, e.g., "camera
   malfunction" or "RTP loop detected".  The string has the same
   encoding as that described for SDES.  If the string fills the packet
   to the next 32-bit boundary, the string is not null terminated.  If
   not, the BYE packet MUST be padded with null octets to the next 32-
   bit boundary.  This padding is separate from that indicated by the P
   bit in the RTCP header.

6.7 APP: Application-Defined RTCP Packet

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P| subtype | PT=APP=204 | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC/CSRC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | name (ASCII) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | application-dependent data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The APP packet is intended for experimental use as new applications and new features are developed, without requiring packet type value registration. APP packets with unrecognized names SHOULD be ignored. After testing and if wider use is justified, it is RECOMMENDED that each APP packet be redefined without the subtype and name fields and registered with IANA using an RTCP packet type. version (V), padding (P), length: As described for the SR packet (see Section 6.4.1). subtype: 5 bits May be used as a subtype to allow a set of APP packets to be defined under one unique name, or for any application-dependent data. packet type (PT): 8 bits Contains the constant 204 to identify this as an RTCP APP packet.
Top   ToC   RFC3550 - Page 53
   name: 4 octets
      A name chosen by the person defining the set of APP packets to be
      unique with respect to other APP packets this application might
      receive.  The application creator might choose to use the
      application name, and then coordinate the allocation of subtype
      values to others who want to define new packet types for the
      application.  Alternatively, it is RECOMMENDED that others choose
      a name based on the entity they represent, then coordinate the use
      of the name within that entity.  The name is interpreted as a
      sequence of four ASCII characters, with uppercase and lowercase
      characters treated as distinct.

   application-dependent data: variable length
      Application-dependent data may or may not appear in an APP packet.
      It is interpreted by the application and not RTP itself.  It MUST
      be a multiple of 32 bits long.



(page 53 continued on part 3)

Next Section