if (rspn >= end) {
rsp = rspn;
break;
}
member_sdes(s, rsp->type, rsp->data, rsp->length);
}
sd = (rtcp_sdes_t *)
((u_int32 *)sd + (((char *)rsp - (char *)sd) >> 2)+1);
}
if (count >= 0) {
/* invalid packet format */
}
}
A.6 Generating a Random 32-bit Identifier
The following subroutine generates a random 32-bit identifier using
the MD5 routines published in RFC1321 [23]. The system routines may
not be present on all operating systems, but they should serve as
hints as to what kinds of information may be used. Other system calls
that may be appropriate include
o getdomainname() ,
o getwd() , or
o getrusage()
"Live" video or audio samples are also a good source of random
numbers, but care must be taken to avoid using a turned-off
microphone or blinded camera as a source [7].
Use of this or similar routine is suggested to generate the initial
seed for the random number generator producing the RTCP period (as
shown in Appendix A.7), to generate the initial values for the
sequence number and timestamp, and to generate SSRC values. Since
this routine is likely to be CPU-intensive, its direct use to
generate RTCP periods is inappropriate because predictability is not
an issue. Note that this routine produces the same result on repeated
calls until the value of the system clock changes unless different
values are supplied for the type argument.
/*
* Generate a random 32-bit quantity.
*/
#include <sys/types.h> /* u_long */
#include <sys/time.h> /* gettimeofday() */
#include <unistd.h> /* get..() */
#include <stdio.h> /* printf() */
#include <time.h> /* clock() */
#include <sys/utsname.h> /* uname() */
#include "global.h" /* from RFC1321 */
#include "md5.h" /* from RFC1321 */
#define MD_CTX MD5_CTX
#define MDInit MD5Init
#define MDUpdate MD5Update
#define MDFinal MD5Final
static u_long md_32(char *string, int length)
{
MD_CTX context;
union {
char c[16];
u_long x[4];
} digest;
u_long r;
int i;
MDInit (&context);
MDUpdate (&context, string, length);
MDFinal ((unsigned char *)&digest, &context);
r = 0;
for (i = 0; i < 3; i++) {
r ^= digest.x[i];
}
return r;
} /* md_32 */
/*
* Return random unsigned 32-bit quantity. Use 'type' argument if you
* need to generate several different values in close succession.
*/
u_int32 random32(int type)
{
struct {
int type;
struct timeval tv;
clock_t cpu;
pid_t pid;
u_long hid;
uid_t uid;
gid_t gid;
struct utsname name;
} s;
gettimeofday(&s.tv, 0);
uname(&s.name);
s.type = type;
s.cpu = clock();
s.pid = getpid();
s.hid = gethostid();
s.uid = getuid();
s.gid = getgid();
return md_32((char *)&s, sizeof(s));
} /* random32 */
A.7 Computing the RTCP Transmission Interval
The following function returns the time between transmissions of RTCP
packets, measured in seconds. It should be called after sending one
compound RTCP packet to calculate the delay until the next should be
sent. This function should also be called to calculate the delay
before sending the first RTCP packet upon startup rather than send
the packet immediately. This avoids any burst of RTCP packets if an
application is started at many sites simultaneously, for example as a
result of a session announcement.
The parameters have the following meaning:
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 should be 5% of the "session bandwidth"
parameter supplied to the application at startup.
senders: Number of active senders since sending last report, known
from construction of receiver reports for this RTCP packet.
Includes ourselves, if we also sent during this interval.
members: The estimated number of session members, including
ourselves. Incremented as we discover new session members from
the receipt of RTP or RTCP packets, and decremented as session
members leave (via RTCP BYE) or their state is timed out (30
minutes is recommended). On the first call, this parameter
should have the value 1.
we_sent: Flag that is true if we have sent data during the last two
RTCP intervals. If the flag is true, the compound RTCP packet
just sent contained an SR packet.
packet_size: The size of the compound RTCP packet just sent, in
octets, including the network encapsulation (e.g., 28 octets for
UDP over IP).
avg_rtcp_size: Pointer to estimator for compound RTCP packet size;
initialized and updated by this function for the packet just
sent, and also updated by an identical line of code in the RTCP
receive routine for every RTCP packet received from other
participants in the session.
initial: Flag that is true for the first call upon startup to
calculate the time until the first report should be sent.
#include <math.h>
double rtcp_interval(int members,
int senders,
double rtcp_bw,
int we_sent,
int packet_size,
int *avg_rtcp_size,
int initial)
{
/*
* Minimum time between RTCP packets from this site (in seconds).
* This time prevents the reports from `clumping' when sessions
* are small and the law of large numbers isn't helping to smooth
* out the traffic. It also keeps the report interval from
* becoming ridiculously small during transient outages like a
* network partition.
*/
double const RTCP_MIN_TIME = 5.;
/*
* Fraction of the RTCP bandwidth to be shared among active
* senders. (This fraction was chosen so that in a typical
* session with one or two active senders, the computed report
* time would be roughly equal to the minimum report time so that
* we don't unnecessarily slow down receiver reports.) The
* receiver fraction must be 1 - the sender fraction.
*/
double const RTCP_SENDER_BW_FRACTION = 0.25;
double const RTCP_RCVR_BW_FRACTION = (1-RTCP_SENDER_BW_FRACTION);
/*
* Gain (smoothing constant) for the low-pass filter that
* estimates the average RTCP packet size (see Cadzow reference).
*/
double const RTCP_SIZE_GAIN = (1./16.);
double t; /* interval */
double rtcp_min_time = RTCP_MIN_TIME;
int n; /* no. of members for computation */
/*
* Very first call at application start-up uses half the min
* delay for quicker notification while still allowing some time
* before reporting for randomization and to learn about other
* sources so the report interval will converge to the correct
* interval more quickly. The average RTCP size is initialized
* to 128 octets which is conservative (it assumes everyone else
* is generating SRs instead of RRs: 20 IP + 8 UDP + 52 SR + 48
* SDES CNAME).
*/
if (initial) {
rtcp_min_time /= 2;
*avg_rtcp_size = 128;
}
/*
* If there were active senders, give them at least a minimum
* share of the RTCP bandwidth. Otherwise all participants share
* the RTCP bandwidth equally.
*/
n = members;
if (senders > 0 && senders < members * RTCP_SENDER_BW_FRACTION) {
if (we_sent) {
rtcp_bw *= RTCP_SENDER_BW_FRACTION;
n = senders;
} else {
rtcp_bw *= RTCP_RCVR_BW_FRACTION;
n -= senders;
}
}
/*
* Update the average size estimate by the size of the report
* packet we just sent.
*/
*avg_rtcp_size += (packet_size - *avg_rtcp_size)*RTCP_SIZE_GAIN;
/*
* The effective number of sites times the average packet size is
* the total number of octets sent when each site sends a report.
* Dividing this by the effective bandwidth gives the time
* interval over which those packets must be sent in order to
* meet the bandwidth target, with a minimum enforced. In that
* time interval we send one report so this time is also our
* average time between reports.
*/
t = (*avg_rtcp_size) * n / rtcp_bw;
if (t < rtcp_min_time) t = rtcp_min_time;
/*
* To avoid traffic bursts from unintended synchronization with
* other sites, we then pick our actual next report interval as a
* random number uniformly distributed between 0.5*t and 1.5*t.
*/
return t * (drand48() + 0.5);
}
A.8 Estimating the Interarrival Jitter
The code fragments below implement the algorithm given in Section
6.3.1 for calculating an estimate of the statistical variance of the
RTP data interarrival time to be inserted in the interarrival jitter
field of reception reports. The inputs are r->ts , the timestamp from
the incoming packet, and arrival , the current time in the same
units. Here s points to state for the source; s->transit holds the
relative transit time for the previous packet, and s->jitter holds
the estimated jitter. The jitter field of the reception report is
measured in timestamp units and expressed as an unsigned integer, but
the jitter estimate is kept in a floating point. As each data packet
arrives, the jitter estimate is updated:
int transit = arrival - r->ts;
int d = transit - s->transit;
s->transit = transit;
if (d < 0) d = -d;
s->jitter += (1./16.) * ((double)d - s->jitter);
When a reception report block (to which rr points) is generated for
this member, the current jitter estimate is returned:
rr->jitter = (u_int32) s->jitter;
Alternatively, the jitter estimate can be kept as an integer, but
scaled to reduce round-off error. The calculation is the same except
for the last line:
s->jitter += d - ((s->jitter + 8) >> 4);
In this case, the estimate is sampled for the reception report as:
rr->jitter = s->jitter >> 4;
B. Security Considerations
RTP suffers from the same security liabilities as the underlying
protocols. For example, an impostor can fake source or destination
network addresses, or change the header or payload. Within RTCP, the
CNAME and NAME information may be used to impersonate another
participant. In addition, RTP may be sent via IP multicast, which
provides no direct means for a sender to know all the receivers of
the data sent and therefore no measure of privacy. Rightly or not,
users may be more sensitive to privacy concerns with audio and video
communication than they have been with more traditional forms of
network communication [24]. Therefore, the use of security mechanisms
with RTP is important. These mechanisms are discussed in Section 9.
RTP-level translators or mixers may be used to allow RTP traffic to
reach hosts behind firewalls. Appropriate firewall security
principles and practices, which are beyond the scope of this
document, should be followed in the design and installation of these
devices and in the admission of RTP applications for use behind the
firewall.
C. Authors' Addresses
Henning Schulzrinne
GMD Fokus
Hardenbergplatz 2
D-10623 Berlin
Germany
EMail: schulzrinne@fokus.gmd.de
Stephen L. Casner
Precept Software, Inc.
21580 Stevens Creek Boulevard, Suite 207
Cupertino, CA 95014
United States
EMail: casner@precept.com
Ron Frederick
Xerox Palo Alto Research Center
3333 Coyote Hill Road
Palo Alto, CA 94304
United States
EMail: frederic@parc.xerox.com
Van Jacobson
MS 46a-1121
Lawrence Berkeley National Laboratory
Berkeley, CA 94720
United States
EMail: van@ee.lbl.gov
Acknowledgments
This memorandum is based on discussions within the IETF Audio/Video
Transport working group chaired by Stephen Casner. The current
protocol has its origins in the Network Voice Protocol and the Packet
Video Protocol (Danny Cohen and Randy Cole) and the protocol
implemented by the vat application (Van Jacobson and Steve McCanne).
Christian Huitema provided ideas for the random identifier generator.
D. Bibliography
[1] D. D. Clark and D. L. Tennenhouse, "Architectural considerations
for a new generation of protocols," in SIGCOMM Symposium on
Communications Architectures and Protocols , (Philadelphia,
Pennsylvania), pp. 200--208, IEEE, Sept. 1990. Computer
Communications Review, Vol. 20(4), Sept. 1990.
[2] H. Schulzrinne, "Issues in designing a transport protocol for
audio and video conferences and other multiparticipant real-time
applications", Work in Progress.
[3] D. E. Comer, Internetworking with TCP/IP , vol. 1. Englewood
Cliffs, New Jersey: Prentice Hall, 1991.
[4] Postel, J., "Internet Protocol", STD 5, RFC791, USC/Information
Sciences Institute, September 1981.
[5] Mills, D., "Network Time Protocol Version 3", RFC1305, UDEL,
March 1992.
[6] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC1700,
USC/Information Sciences Institute, October 1994.
[7] Eastlake, D., Crocker, S., and J. Schiller, "Randomness
Recommendations for Security", RFC1750, DEC, Cybercash, MIT,
December 1994.
[8] J.-C. Bolot, T. Turletti, and I. Wakeman, "Scalable feedback
control for multicast video distribution in the internet," in
SIGCOMM Symposium on Communications Architectures and Protocols ,
(London, England), pp. 58--67, ACM, Aug. 1994.
[9] I. Busse, B. Deffner, and H. Schulzrinne, "Dynamic QoS control of
multimedia applications based on RTP," Computer Communications ,
Jan. 1996.
[10] S. Floyd and V. Jacobson, "The synchronization of periodic
routing messages," in SIGCOMM Symposium on Communications
Architectures and Protocols (D. P. Sidhu, ed.), (San Francisco,
California), pp. 33--44, ACM, Sept. 1993. also in [25].
[11] J. A. Cadzow, Foundations of digital signal processing and data
analysis New York, New York: Macmillan, 1987.
[12] International Standards Organization, "ISO/IEC DIS 10646-1:1993
information technology -- universal multiple-octet coded
character set (UCS) -- part I: Architecture and basic
multilingual plane," 1993.
[13] The Unicode Consortium, The Unicode Standard New York, New York:
Addison-Wesley, 1991.
[14] Mockapetris, P., "Domain Names - Concepts and Facilities", STD
13, RFC1034, USC/Information Sciences Institute, November 1987.
[15] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC1035, USC/Information Sciences
Institute, November 1987.
[16] Braden, R., "Requirements for Internet Hosts - Application and
Support", STD 3, RFC1123, Internet Engineering Task Force,
October 1989.
[17] Rekhter, Y., Moskowitz, R., Karrenberg, D., and G. de Groot,
"Address Allocation for Private Internets", RFC1597, T.J. Watson
Research Center, IBM Corp., Chrysler Corp., RIPE NCC, March 1994.
[18] Lear, E., Fair, E., Crocker, D., and T. Kessler, "Network 10
Considered Harmful (Some Practices Shouldn't be Codified)", RFC
1627, Silicon Graphics, Inc., Apple Computer, Inc., Silicon
Graphics, Inc., July 1994.
[19] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC822, UDEL, August 1982.
[20] W. Feller, An Introduction to Probability Theory and its
Applications, Volume 1 , vol. 1. New York, New York: John Wiley
and Sons, third ed., 1968.
[21] Balenson, D., "Privacy Enhancement for Internet Electronic Mail:
Part III: Algorithms, Modes, and Identifiers", RFC1423, TIS, IAB
IRTF PSRG, IETF PEM WG, February 1993.
[22] V. L. Voydock and S. T. Kent, "Security mechanisms in high-level
network protocols," ACM Computing Surveys , vol. 15, pp. 135--
171, June 1983.
[23] Rivest, R., "The MD5 Message-Digest Algorithm", RFC1321, MIT
Laboratory for Computer Science and RSA Data Security, Inc.,
April 1992.
[24] S. Stubblebine, "Security services for multimedia conferencing,"
in 16th National Computer Security Conference , (Baltimore,
Maryland), pp. 391--395, Sept. 1993.
[25] S. Floyd and V. Jacobson, "The synchronization of periodic
routing messages," IEEE/ACM Transactions on Networking , vol. 2,
pp. 122-136, April 1994.