draft-ietf-avt-rtptest-00.txt   draft-ietf-avt-rtptest-01.txt 
INTERNET-DRAFT 25 June 1999 INTERNET-DRAFT 16 August 1999
Colin Perkins Colin Perkins
University College London University College London
Jonathan Rosenberg
Bell Laboratories
Henning Schulzrinne
Columbia University
RTP Testing Strategies RTP Testing Strategies
draft-ietf-avt-rtptest-00.txt draft-ietf-avt-rtptest-01.txt
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with
provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering
Force (IETF), its areas, and its working groups. Note that other groups Task Force (IETF), its areas, and its working groups. Note that
may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and Internet-Drafts are draft documents valid for a maximum of six months
may be updated, replaced, or obsoleted by other documents at any time. It and may be updated, replaced, or obsoleted by other documents at
is inappropriate to use Internet-Drafts as reference material or to cite any time. It is inappropriate to use Internet-Drafts as reference
them other than as work in progress. material or to cite them other than as work in progress.
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Distribution of this document is unlimited. Distribution of this document is unlimited.
Comments are solicited and should be addressed to the author and/or the Comments are solicited and should be addressed to the author and/or the
skipping to change at page 2, line 34 skipping to change at page 2, line 39
delay or discard packets in some of the tests. The test instrument delay or discard packets in some of the tests. The test instrument
is invisible to the RTP implementations - it merely simulates poor is invisible to the RTP implementations - it merely simulates poor
network conditions. network conditions.
The test instrument is also capable of logging packet contents for The test instrument is also capable of logging packet contents for
inspection of their correctness. inspection of their correctness.
A typical test setup might comprise three machines on a single Ethernet A typical test setup might comprise three machines on a single Ethernet
segment. Two of these machines run the RTP implementations, the segment. Two of these machines run the RTP implementations, the
third runs the test instrument. The test instrument is an application third runs the test instrument. The test instrument is an application
level UDP packet forwarder. Both RTP implementations are instructed level packet forwarder. Both RTP implementations are instructed to
to send unicast RTP/UDP packets to the test instrument, which forwards send unicast RTP packets to the test instrument, which forwards packets
packets between them. between them.
2.1 Media transport 2.1 Media transport
The aim of these tests is to show that basic media flows can be The aim of these tests is to show that basic media flows can be
exchanged between the two RTP implementations. The initial test is exchanged between the two RTP implementations. The initial test is
for the first RTP implementation to transmit and the second to receive. for the first RTP implementation to transmit and the second to receive.
If this succeeds, the process is reversed, with the second implementation If this succeeds, the process is reversed, with the second implementation
sending and the first receiving. sending and the first receiving.
The receiving application should be able to handle the following The receiving application should be able to handle the following
edge cases, in addition to normal operation: edge cases, in addition to normal operation:
o Verify reception of packets which contain padding. o Verify reception of packets which contain padding.
o Verify reception of packets which have the marker bit set
o Verify correct operation during sequence number wrap-around. o Verify correct operation during sequence number wrap-around.
o Verify correct operation during timestamp wrap-around. o Verify correct operation during timestamp wrap-around.
o Verify that the implementation correctly differentiates packets
according to the payload type field.
o Verify that the implementation ignores packets with unsupported o Verify that the implementation ignores packets with unsupported
payload types payload types
o Verify that the implementation can playout packets containing
a CSRC list and non-zero CC field (see section 4).
The sending application should be verified to correctly handle the The sending application should be verified to correctly handle the
following edge cases: following edge cases:
o If padding is used, verify that the padding length indicator o If padding is used, verify that the padding length indicator
(last octet of the packet) is correctly set and that the length (last octet of the packet) is correctly set and that the length
of the data section of the packet corresponds to that of this of the data section of the packet corresponds to that of this
particular payload plus the padding. particular payload plus the padding.
o Verify correct handling of the M bit, as defined by the profile. o Verify correct handling of the M bit, as defined by the profile.
skipping to change at page 3, line 35 skipping to change at page 3, line 49
o Verify correct operation during sequence number wrap-around. o Verify correct operation during sequence number wrap-around.
o Verify that the initial value of the timestamp is randomly selected. o Verify that the initial value of the timestamp is randomly selected.
o Verify correct increment of timestamp (dependent on the payload o Verify correct increment of timestamp (dependent on the payload
format). format).
o Verify correct operation during timestamp wrap-around. o Verify correct operation during timestamp wrap-around.
o Verify correct choice of payload type according to the chosen
payload format, profile and any session level control protocol.
2.2 RTP Header Extension 2.2 RTP Header Extension
An RTP implementation which does not use an extended header should An RTP implementation which does not use an extended header should
be able to process packets containing an extension header by ignoring be able to process packets containing an extension header by ignoring
the extension. the extension.
If an implementation makes use of the header extension, it should If an implementation makes use of the header extension, it should
be verified that the profile specific field and the length field be verified that the profile specific field and the length field
of the extension are set correctly, and that the length of the packet of the extension are set correctly, and that the length of the packet
is consistent. is consistent.
skipping to change at page 4, line 43 skipping to change at page 5, line 13
be verified: be verified:
o that the SSRC in the report block is consistent with that in o that the SSRC in the report block is consistent with that in
the data packets being received the data packets being received
o that the fraction lost is zero o that the fraction lost is zero
o that the cumulative number of packets lost is zero o that the cumulative number of packets lost is zero
o that the extended highest sequence number received is consistent o that the extended highest sequence number received is consistent
with the data packets being received with the data packets being received (provided the round trip
time between test instrument and receiver is smaller than the
packet inter-arrival time, this can be directly checked by the
test instrument).
o that the interarrival jitter is small (a precise value cannot o that the interarrival jitter is small (a precise value cannot
be given, since it depends on the test instrument, but very be given, since it depends on the test instrument and network
little jitter should be present in this scenario). conditions, but very little jitter should be present in this
scenario).
o that the last sender report timestamp is consistent with that o that the last sender report timestamp is consistent with that
in the SR packets in the SR packets (ie: each RR passing through the test instrument
should contain the middle 32 bits from the 64 bit NTP timestamp
of the last SR packet which passed through the test instrument
in the opposite direction).
o that the delay since last SR field is sensible (an estimate o that the delay since last SR field is sensible (an estimate
may be made by timing the passage of an SR and corresponding may be made by timing the passage of an SR and corresponding
RR through the test instrument) RR through the test instrument, this should closely agree with
the DLSR field)
The next test is to show behaviour in the presence of packet loss. The next test is to show behaviour in the presence of packet loss.
The first implementation is made to transmit data packets, which The first implementation is made to transmit data packets, which
are received by the second implementation. This time, however, the are received by the second implementation. This time, however, the
test instrument is made to randomly drop a small fraction (1% is test instrument is made to randomly drop a small fraction (1% is
suggested) of the data packets. The second implementation should suggested) of the data packets. The second implementation should
be able to receive the data packets and process them in a normal be able to receive the data packets and process them in a normal
manner (with, of course, some quality degradation). The RR packets manner (with, of course, some quality degradation). The RR packets
should show a loss fraction corresponding to the drop rate of the should show a loss fraction corresponding to the drop rate of the
test instrument and should show an increasing cumulative number of test instrument and should show an increasing cumulative number of
skipping to change at page 5, line 21 skipping to change at page 5, line 50
manner (with, of course, some quality degradation). The RR packets manner (with, of course, some quality degradation). The RR packets
should show a loss fraction corresponding to the drop rate of the should show a loss fraction corresponding to the drop rate of the
test instrument and should show an increasing cumulative number of test instrument and should show an increasing cumulative number of
packets lost. packets lost.
The loss rate in the test instrument is then returned to zero and The loss rate in the test instrument is then returned to zero and
it is made to delay each packet by some random amount (the exact it is made to delay each packet by some random amount (the exact
amount depends on the media type, but a small fraction of the average amount depends on the media type, but a small fraction of the average
interarrival time is reasonable). The effect of this should be to interarrival time is reasonable). The effect of this should be to
increase the reported interarrival jitter in the RR packets. increase the reported interarrival jitter in the RR packets.
If these tests succeed, the process should be repeated with the second If these tests succeed, the process should be repeated with the second
implementation transmitting and the first receiving. implementation transmitting and the first receiving.
2.4 RTCP source description packets 2.4 RTCP source description packets
Both implementations should be run, but neither is required to transmit Both implementations should be run, but neither is required to transmit
data packets. The RTCP packets should be observed and it should data packets. The RTCP packets should be observed and it should
be verified that each compound packet contains an SDES packet and be verified that each compound packet contains an SDES packet, that
that that packet contains a CNAME item. that packet contains a CNAME item and that the CNAME is chosen according
to the rules in the RTP specification and profile.
If an application supports additional SDES items then it should be If an application supports additional SDES items then it should be
verified that they are sent in addition to the CNAME with some SDES verified that they are sent in addition to the CNAME with some SDES
packets (the exact rate at which these additional items are included packets (the exact rate at which these additional items are included
is dependent on the application and profile). is dependent on the application and profile).
It should be verified that an implementation can correctly receive NAME, It should be verified that an implementation can correctly receive
EMAIL, PHONE, LOC, NOTE, TOOL and PRIV items, even if it does not send NAME, EMAIL, PHONE, LOC, NOTE, TOOL and PRIV items, even if it does
them. This is because it may reasonably be expected to interwork with not send them. This is because it may reasonably be expected to
other implementations which support those items. Receiving and ignoring interwork with other implementations which support those items. Receiving
such packets is valid behaviour. and ignoring such packets is valid behaviour.
It should be verified that an implementation correctly sets the length It should be verified that an implementation correctly sets the length
fields in the SDES items it sends, and that the source count and packet fields in the SDES items it sends, and that the source count and
length fields are correct. packet length fields are correct.
It should be verified that an implementation correctly receives SDES It should be verified that an implementation correctly receives SDES
items which do not terminate in a zero byte. items which do not terminate in a zero byte.
2.5 RTCP transmission interval 2.5 RTCP BYE packets
See draft-ietf-avt-rtcptest-01.txt
2.6 RTCP BYE packets
Both implementations should be run, but neither is required to transmit Both implementations should be run, but neither is required to transmit
data packets. The first implementation is then quit and it should data packets. The first implementation is then quit and it should
be verified that an RTCP BYE packet is sent. If should be verified be verified that an RTCP BYE packet is sent. If should be verified
that the second implementation reacts to this BYE packet and notes that the second implementation reacts to this BYE packet and notes
that the first implementation has left the conference. that the first implementation has left the conference.
If the test succeeds, the implementations should be restarted and If the test succeeds, the implementations should be restarted and
the process repeated with the second implementation leaving the conference. the process repeated with the second implementation leaving the conference.
It should be verified that implementations handle BYE packets containing It should be verified that implementations handle BYE packets containing
the optional reason for leaving. the optional reason for leaving.
2.7 RTCP application defined packets 2.6 RTCP application defined packets
Tests for the correct response to application defined packets are Tests for the correct response to application defined packets are
difficult to specify, since the response is clearly implementation difficult to specify, since the response is clearly implementation
dependent. It should be verified that an implementation ignores APP dependent. It should be verified that an implementation ignores APP
packets where the 4 octet name field is unrecognised. Implementations packets where the 4 octet name field is unrecognised. Implementations
which use APP packets should verify that they behave as expected. which use APP packets should verify that they behave as expected.
2.7 RTCP transmission interval
The basic architecture for performing the tests is shown in figure 2.
+--------------+
| test |
| instrument |
+-----+--------+
|
------+-----------+------------- LAN
|
+-------+--------+
| RTP |
| implementation |
+----------------+
Figure 2: Testing architecture for RTCP
The test instrument is connected on the same LAN as the RTP implementation
being tested. It is assumed that the test instrument is preconfigured
with the addresses and ports used by the RTP implementation, and
is also aware of the RTCP bandwidth and sender/receiver fractions.
The tests can be conducted using either multicast or unicast.
The test instrument must be capable of sending arbitrarily crafted
RTP and RTCP packets to the RTP implementation. The instrument should
also be capable of receiving packets sent by the RTP implementation,
parsing them, and computing metrics based on those packets.
It is furthermore assumed that a number of basic controls over the
RTP implementation exist. These controls are:
o the ability to force the implementation to send or not send
RTP packets at any desired point in time;
o the ability to force the application to terminate its involvement
in the RTP session, and for this termination to be known immediately
to the test instrument;
o the ability to set the session bandwidth and RTCP sender and
receiver fractions;
The second of these is required only for the test of BYE reconsideration,
and is the only aspect of these tests not easily implementable by
pure automation. It will generally require manual intervention to
terminate the session from the RTP implementation and to convey this
to the test instrument through some non-RTP means.
2.7.1 Basic Behavior
The first test is to verify basic correctness of the implementation
of the RTCP transmission rules. This basic behavior consists of:
o periodic transmission of RTCP packets;
o randomization of the interval for RTCP packet transmission;
o correct implementation of the randomization interval computations,
with unconditional reconsideration.
These features are tested in the following manner. The RTP implementation
acts as a session receiver, and never sends any RTP packets. The
implementation is configured with a large session bandwidth, say 1
Mb/s. This will cause the implementation to use the minimal interval
of 5s rather than the small interval based on the session bandwidth
and membership size. The implementation will generate RTCP packets
at this minimal interval, on average. The test instrument generates
no packets, but receives the RTCP packets generated by the implementation.
When an RTCP packet is received, the time is noted by the test instrument.
The difference in time between each pair of subsequent packets (called
the interval) is computed. These intervals are stored, so that statistics
based on these intervals can be computed. It is recommended that
this observation process operate for at least 20 minutes.
An implementation passes this test if the intervals have the following
properties:
o the minimum interval is never less than 2 seconds or more than
2.5 seconds;
o the maximum interval is never more than 7 seconds or less than
5.5 seconds;
o the average interval is between 4.5 and 5.5 seconds;
o the number of intervals between x and x+500ms is less than the
number of intervals between x+500ms and x+1s, for any x.
In particular, an implementation fails if the packets are sent with
a constant interval.
2.7.2 Step join backoff
The main purpose of the reconsideration algorithm is to avoid a flood
of packets that might occur when a large number of users simultaneously
join an RTP session. Reconsideration therefore exhibits a backoff
behavior in sending of RTCP packets when group sizes increase. This
aspect of the algorithm can be tested in the following manner.
The implementation begins operation. The test instrument waits for
the arrival of the first RTCP packet. When it arrives, the test
instrument notes the time and then immediately sends 100 RTCP RR
packets to the implementation, each with a different SSRC and SDES
CNAME. The test instrument should ensure that each RTCP packet is
of the same length. The instrument should then wait until the next
RTCP packet is received from the implementation, and the time of
such reception is noted.
Without reconsideration, the next RTCP packet will arrive within a
short period of time. With reconsideration, transmission of this
packet will be delayed. The earliest it can arrive depends on the
RTCP session bandwidth, receiver fraction, and average RTCP packet
size. The RTP implementation should be using the exponential averaging
algorithm defined in the specification to compute the average RTCP
packet size. Since this is dominated by the received packets (the
implementation has only sent one itself), the average will be roughly
equal to the length of the RTCP packets sent by the test instrument.
Therefore, the minimum amount of time between the first and second
RTCP packets from the implementation is:
T > 101 * S / ( B * Fr * (e-1.5) * 2 )
Where S is the size of the RTCP packets sent by the test instrument,
B is the RTCP bandwidth (normally five percent of the session bandwidth),
Fr is the fraction of RTCP bandwidth allocated to receivers (normally
75 percent), and e is the natural exponent. Without reconsideration,
this minimum interval Te would be much smaller:
Te > MAX( [ S / ( B * Fr * (e-1.5) * 2 ) ] , [ 2.5 / (e-1.5) ] )
B should be chosen sufficiently small so that T is around 60 seconds.
Reasonable choices for these parameters are B = 950 bits per second,
and S = 1024 bits. An implementation passes this test if the interval
between packets is not less than T above, and not more than 3 times T.
The test may be repeated for the case when the RTP implementation
is a sender. This is accomplished by having the implementation send
RTP packets at least once a second. In this case, the interval between
the first and second RTCP packets should be no less than:
T > S / ( B * Fs * (e-1.5) * 2 )
Where Fs is the fraction of RTCP bandwidth allocated to senders,
usually 25%. Note that this value of T is significantly smaller
than the interval for receivers.
2.7.3 Steady State Behavior
In addition to the basic behavior in section 2.7.1, an implementation
should correctly implement a number of other, slightly more advanced
features:
o scale the RTCP interval with the group size;
o correctly divide bandwidth between senders and receivers;
o correctly compute the RTCP interval when the user is a sender
The following tests are meant to test these features.
The implementation begins operation as a receiver. The test instrument
waits for the first RTCP packet from the implementation. When it
arrives, the test instrument notes the time, and immediately sends
50 RTCP RR packets and 50 RTCP SR packets to the implementation,
each with a different SSRC and SDES CNAME. The test instrument then
sends 50 RTP packets, using the 50 SSRC from the RTCP SR packets.
The test instrument should ensure that each RTCP packet is of the
same length. The instrument should then wait until the next RTCP
packet is received from the implementation, and the time of such
reception is noted. The difference between the reception of the
RTCP packet and the reception of the previous is computed and stored.
In addition, after every RTCP packet reception, the 100 RTCP and
50 RTP packets are retransmitted by the test instrument. This ensures
that the sender and member status of the 100 users does not time
out. The test instrument should collect the interval measurements
figures for at least 100 RTCP packets.
With 50 senders, the implementation should not try to divide the
RTCP bandwidth between senders and receivers, but rather group all
users together and divide the RTCP bandwidth equally. The test is
deemed successful if the average RTCP interval is within 5% of:
T = 101* S/B
Where S is the size of the RTCP packets sent by the test instrument,
and B is the RTCP bandwidth. B should be chosen sufficiently small
so that the value of T is on the order of tens of seconds or more.
Reasonable values are S=1024 bits and B=3.4 kb/s.
The previous test is repeated. However, the test instrument sends
10 RTP packets instead of 50, and 10 RTCP SR and 90 RTCP RR instead
of 50 of each. In addition, the implementation is made to send at
least one RTP packet between transmission of every one of its own
RTCP packets.
In this case, the average RTCP interval should be within 5% of:
T = 11 * S / (B * Fs)
Where S is the size of the RTCP packets sent by the test instrument,
B is the RTCP bandwidth, and Fs is the fraction of RTCP banwidth
allocated for senders (normally 25%). The values for B and S should
be chosen small enough so that T is on the order of tens of seconds.
Reasonable choices are S=1024 bits and B=1.5 kb/s.
2.7.4 Reverse Reconsideration
The reverse reconsideration algorithm is effectively the opposite
of the normal reconsideration algorithm. It causes the RTCP interval
to be reduced more rapidly in response to decreases in the group
membership. This is advantageous in that it keeps the RTCP information
as fresh as possible, and helps avoids some premature timeout problems.
In the first test, the implementation joins the session as a receiver.
As soon as it sends its first RTCP packet, the test instrument sends
100 RTCP RR packets, each of the same length S, and a different SDES
CNAME and SSRC in each. It then waits for the implementation to
send another RTCP packet. Once it does, the test instrument sends
100 BYE packets, each one containing a different SSRC, but matching
an SSRC from one of the initial RTCP packets. Each BYE should also
be the same size as the RTCP packets sent by the test instrument.
This is easily accomplished by using a BYE reason to pad out the
length. The time of the next RTCP packet from the implementation
is then noted. The delay T between this (the third RTCP packet)
and the previous should be no more than:
T < 3 * S / (B * Fr * (e-1.5) * 2)
Where S is the size of the RTCP and BYE packets sent by the test
instrument, B is the RTCP bandwidth, Fr is the fraction of the RTCP
bandwidth allocated to receivers, and e is the natural exponent.
B should be chosen such that T is on the order of tens of seconds.
A reasonable choice is S=1024 bits and B=168 bits per second.
This test demonstrates basic correctness of implementation. An
implementation without reverse reconsideration will not send its next
RTCP packet for nearly 100 times as long as the above amount.
In the second test, the implementation joins the session as a receiver.
As soon as it sends its first RTCP packet, the test instrument sends
100 RTCP RR packets, each of the same length S, followed by 100 BYE
packets, also of length S. Each RTCP packet carries a different SDES
CNAME and SSRC, and is matched with precisely one BYE packet with
the same SSRC. This will cause the implementation to see a rapid
increase and then rapid drop in group membership.
The test is deemed succesful if the next RTCP packet shows up T seconds
after the first, and T is within:
2.5 / (e-1.5) < T < 7.5 / (e-1.5)
This tests correctness of the maintenance of the pmembers variable.
An incorrect implementation might try to execute reverse reconsideration
every time a BYE is received, as opposed to only when the group membership
drops below pmembers. If an implementation did this, it would end
up sending an RTCP packet immediately after receiving the stream
of BYE's. For this test to work, B must be chosen to be a large
value, around 1Mb/s.
2.7.5 BYE Reconsideration
The BYE reconsideration algorithm works in much the same fashion
as regular reconsideration, except applied to BYE packets. When a
user leaves the group, instead of sending a BYE immediately, it may
delay transmission of its BYE packet if others are sending BYE's.
The test for correctness of this algorithm is as follows. The RTP
implementation joins the group as a receiver. The test instrument
waits for the first RTCP packet. When the test instrument receives
this packet, the test instrument immediately sends 100 RTCP RR packets,
each of the same length S, and each containing a different SSRC and
SDES CNAME. Once the test instrument receives the next RTCP packet
from the implementation, the RTP implementation is made to leave
the RTP session, and this information is conveyed to the test instrument
through some non-RTP means. The test instrument then sends 100 BYE
packets, each with a different SSRC, and each matching an SSRC from
a previously transmitted RTCP packet. Each of these BYE packets
is also of size S. Immediately following the BYE packets, the test
instrument sends 100 RTCP RR packets, using the same SSRC/CNAMEs
as the original 100 RTCP packets.
The test is deemed successful if the implementation either never
sends a BYE, or if it does, the BYE is not received by the test
instrument earlier than T seconds after the implementation left the
session, where T is:
T = 100 * S / ( 2 * (e-1.5) * B * Fr)
S is the size of the RTCP and BYE packets, e is the natural exponent,
B is the RTCP bandwidth, and Fr is the RTCP bandwidth fraction for
receivers. S and B should be chosen so that T is on the order of
50 seconds. A reasonable choice is S=1024 bits and B=1.1 kb/s.
The transmission of the RTCP packets is meant to verify that the
implementation is ignoring non-BYE RTCP packets once it decides to
leave the group.
2.7.6 Timing out members
Active RTP participants are supposed to send periodic RTCP packets.
When a participant leaves the session, they may send a BYE, however
this is not required. Furthermore, BYE reconsideration may cause
a BYE to never be sent. As a result, participants must time out
other participants who have not sent an RTCP packet in a long time.
According to the specification, participants who have not sent an
RTCP packet in the last 5 intervals are timed out. This test verifies
that these timeouts are being performed correctly.
The RTP implementation joins a session as a receiver. The test instrument
waits for the first RTCP packet from the implementation. Once it
arrives, the test instrument sends 100 RTCP RR packets, each with
a different SDES and SSRC, and notes the time. This will cause the
implementation to believe that there are now 101 group participants,
causing it to increase its RTCP interval. The test instrument continues
to monitor the RTCP packets from the implementation. As each RTCP
packet is received, the time of its reception is noted, and the interval
between RTCP packets is stored. The 100 participants spoofed by
the test instrument should eventually time out at the RTP implementation.
This should cause the RTCP interval to be reduced to its minimum.
The test is deemed successful if the interval between RTCP packets
after the first is no less than:
Ti > 101 * S / ( 2 * (e-1.5) * B * Fr)
and this minimum interval is sustained no later than Td seconds after
the transmission of the 100 RR's, where Td is:
Td = 7 * 101 * S / ( B * Fr )
and the interval between RTCP packets after this point is no less
than:
Tf > 2.5 / (e-1.5)
For this test to work, B and S must be chosen so Ti is on the order
of minutes. Recommended values are S = 1024 bits and B = 1.9 kbps.
2.7.7 Rapid SR's
The minimum interval for RTCP packets can be reduced for large session
bandwdiths. The reduction applies to senders only. The recommended
algorithm for computing this minimum interval is 360 divided by the
RTP session bandwidth, in kbps. For bandwidths larger than 72 kbps,
this interval is less than 5 seconds.
This test verifies the ability of an implementation to use a lower
RTCP minimum interval when it is a sender in a high bandwidth session.
The test can only be run on implementations that support this reduction,
since it is optional.
The RTP implementation is configured to join the session as a sender.
The session is configured to use 360 kbps. If the recommended algorithm
for computing the reduced minimum interval is used, the result is
a 1 second interval. If the RTP implementation uses a different
algorithm, the session bandwidth should be set in such a way to cause
the reduced minimum interval to be 1 second.
Once joining the session, the RTP implementation should begin to
send both RTP and RTCP packets. The interval between RTCP packets
is measured and stored until 100 intervals have been collected.
The test is deemed successful if the smallest interval is no less
than 1/2 a second, and the largest interval is no more than 1.5 seconds.
The average should be close to 1 second.
3 RTP translators 3 RTP translators
RTP translators should be tested in the same manner as end systems, RTP translators should be tested in the same manner as end systems,
with the addition of the tests described in this section. with the addition of the tests described in this section.
The architecture for testing RTP translators is shown in figure 2.
The architecture for testing RTP translators is shown in figure 3.
+-----------------+ +-----------------+
+-------+ RTP Translator +-----+ +-------+ RTP Translator +-----+
| +-----------------+ | | +-----------------+ |
| | | |
+--------+-------+ +-------+--------+ +--------+-------+ +-------+--------+
| First RTP | | Second RTP | | First RTP | | Second RTP |
| implementation | | implementation | | implementation | | implementation |
+----------------+ +----------------+ +----------------+ +----------------+
Figure 2: Testing architecture for translators Figure 3: Testing architecture for translators
The first RTP implementation is instructed to send data to the translator, The first RTP implementation is instructed to send data to the translator,
which forwards the packets to the other RTP implementation, after which forwards the packets to the other RTP implementation, after
translating then as desired. It should be verified that the second translating then as desired. It should be verified that the second
implementation can playout the translated packets. implementation can playout the translated packets.
It should be verified that the RTP packets sent to the second implementation It should be verified that the RTP packets sent to the second implementation
have the same SSRC as those sent by the first implementation. The have the same SSRC as those sent by the first implementation. The
CC should be zero and CSRC fields should not be present in the translated CC should be zero and CSRC fields should not be present in the translated
packets. The other RTP header fields may be rewritten by the translator, packets. The other RTP header fields may be rewritten by the translator,
depending on the translation being performed. depending on the translation being performed, for example
o the payload type should change if the translator changes the
encoding of the data
o the timestamp may change if, for example, the encoding, packetisation
interval or framerate is changed
o the sequence number may change if the translator merges or splits
packets
o padding may be added or removed, in particular if the translator
is adding or removing encryption
o the marker bit may be rewritten
If the translator modifies the contents of the data packets it should If the translator modifies the contents of the data packets it should
be verified that the corresponding change is made to the RTCP packets, be verified that the corresponding change is made to the RTCP packets,
and that both receivers can correctly process the modified RTCP packets. and that both receivers can correctly process the modified RTCP packets.
In particular In particular
o the SSRC is unchanged by the translator
o if the translator changes the data encoding it should also change o if the translator changes the data encoding it should also change
the octet count field in the SR packets the octet count field in the SR packets
o if the translator combines multiple data packets into one it o if the translator combines multiple data packets into one it
should also change the packet count field in SR packets should also change the packet count field in SR packets
o if the translator combines multiple data packets into one it
should also change the packet loss and extended highest sequence
number fields of RR packets flowing back from the receiver
o if the translator changes the sampling frequency of the data o if the translator changes the sampling frequency of the data
packets it should also change the RTP timestamp field in the packets it should also change the RTP timestamp field in the
SR packets SR packets
o if the translator combines multiple data packets into one it
should also change the packet loss and extended highest sequence
number fields of RR packets flowing back from the receiver (it
is legal for the translator to strip the report blocks and send
empty SR/RR packets, but this should only be done if the transformation
of the data is such that the reception reports cannot sensibly
be translated)
o the translator should forward SDES CNAME packets o the translator should forward SDES CNAME packets
o the translator may forward other SDES packets o the translator may forward other SDES packets
o the translator should forward BYE packets unchanged o the translator should forward BYE packets unchanged
o the translator should forward APP packets unchanged o the translator should forward APP packets unchanged
When the translator exits it should be verified to send a BYE packet When the translator exits it should be verified to send a BYE packet
to each receiver. That BYE packet should contain the SSRC of the to each receiver containing the SSRC of the other receiver. The
translator and may contain the SSRC of the other receiver. The receivers receivers should be verified to correctly process this BYE packet
should be verified to correctly process this BYE packet (this is (this is different to the BYE test in section 2.5 since multiple
different to the BYE test in section 2.6 since multiple SSRCs may SSRCs may be included in each BYE if the translator also sends its
be included in each BYE). own RTCP information).
4 RTP mixers 4 RTP mixers
RTP mixers should be tested in the same manner as end systems, with RTP mixers should be tested in the same manner as end systems, with
the addition of the tests described in this section. the addition of the tests described in this section.
The architecture for testing RTP mixers is shown in figure 3. The architecture for testing RTP mixers is shown in figure 4.
The first and second RTP implementations are instructed to send data
packets to the RTP mixer. The mixer combines those packets and sends
them to the third RTP implementation.
It should be verified that the third RTP implementation can playout
the mixed packets. It should also be verified that
+----------------+ +----------------+
| Second RTP | | Second RTP |
| implementation | | implementation |
+--------+-------+ +--------+-------+
| |
| +-----------+ | +-----------+
+-------+ RTP Mixer +-----+ +-------+ RTP Mixer +-----+
| +-----------+ | | +-----------+ |
| | | |
+--------+-------+ +-------+--------+ +--------+-------+ +-------+--------+
| First RTP | | Third RTP | | First RTP | | Third RTP |
| implementation | | implementation | | implementation | | implementation |
+----------------+ +----------------+ +----------------+ +----------------+
Figure 3: Testing architecture for mixers Figure 4: Testing architecture for mixers
The first and second RTP implementations are instructed to send data
packets to the RTP mixer. The mixer combines those packets and sends
them to the third RTP implementation. The mixer should also process
RTCP packets from the other implementations, and should generate its
own RTCP reports.
It should be verified that the third RTP implementation can playout
the mixed packets. It should also be verified that
o the CC field in the RTP packets received by the third implementation o the CC field in the RTP packets received by the third implementation
is set to 2 is set to 2
o the RTP packets received by the third implementation contain o the RTP packets received by the third implementation contain
2 CSRCs corresponding to the first and second RTP implementations 2 CSRCs corresponding to the first and second RTP implementations
o the RTP packets received by the third implementation contain o the RTP packets received by the third implementation contain
an SSRC corresponding to that of the mixer an SSRC corresponding to that of the mixer
It should next be verified that the mixer generates SR and RR packets It should next be verified that the mixer generates SR and RR packets
for each cloud. The mixer should generate RR packets in the direction for each cloud. The mixer should generate RR packets in the direction
of the first and second implementations, and SR packets in the direction of the first and second implementations, and SR packets in the direction
of the third implementation. of the third implementation.
It should be verified that the SR packets sent to the third implmentation It should be verified that the SR packets sent to the third implementation
do not reference the first or second implementations, and vice versa. do not reference the first or second implementations, and vice versa.
It should be verified that SDES CNAME information is forwarded across It should be verified that SDES CNAME information is forwarded across
the mixer. Other SDES fields may optionally be forwarded. the mixer. Other SDES fields may optionally be forwarded.
Finally, one of the implementations should be quit, and it should Finally, one of the implementations should be quit, and it should
be verified that the other implementations see the BYE packet. This be verified that the other implementations see the BYE packet. This
implementation should then be restarted and the mixer should be quit. implementation should then be restarted and the mixer should be quit.
It should be verified that the implementations see both the mixer It should be verified that the implementations see both the mixer
and the implementations on the other side of the mixer quit (illustrating and the implementations on the other side of the mixer quit (illustrating
response to BYE packets containing multiple sources). response to BYE packets containing multiple sources).
5 SSRC collision detection 5 SSRC collision detection
See draft-ietf-avt-rtcptest-01.txt RTP has a provision for SSRC collisions. These collisions occur
6 Loop detection when two different session participants choose the same SSRC. In
this case, both participants are supposed to send a BYE, leave the
session, and rejoin with a different SSRC, but the same CNAME. The
purpose of this test is to verify that this function is present in
the implementation.
To be completed. The test is straightforward. The RTP implementation is made to join
the multicast group as a receiver. A test instrument waits for the
first RTCP packet. Once it arrives, the test instrument notes the
CNAME and SSRC from the RTCP packet. The test instrument then generates
an RTCP receiver report. This receiver report contains an SDES chunk
with an SSRC matching that of the RTP implementation, but with a
different CNAME. At this point, the implementation should send a
BYE RTCP packet (containing an SDES chunk with the old SSRC and CNAME),
and then rejoin, causing it to send a receiver report containing
an SDES chunk, but with a new SSRC and the same CNAME.
7 Encrypted RTP The test is deemed succesful if the RTP implementation sends the
RTCP BYE and RTCP RR as described above within one minute of receiving
the colliding RR from the test instrument.
To be completed. 6 SSRC Randomization
8 Author's Address According to the RTP specification, SSRC's are supposed to be chosen
randomly and uniformly over a 32 bit space. This randomization is
beneficial for several reasons:
o It reduces the probability of collisions in large groups.
o It simplifies the process of group sampling [3] which depends
on the uniform distribution of SSRC's across the 32 bit space.
Unfortunately, verifying that a random number has 32 bits of uniform
randomness requires a large number of samples. The procedure below
gives only a rough validation to the randomness used for generating
the SSRC.
The test runs as follows. The RTP implementation joins the group
as a receiver. The test instrument waits for the first RTCP packet.
It notes the SSRC in this RTCP packet. The test is repeated 2500
times, resulting in a collection of 2500 SSRC.
The are then placed into 25 bins. An SSRC with value X is placed
into bin FLOOR(X/(2**32 / 25)). The idea is to break the 32 bit
space into 25 regions, and compute the number of SSRC in each region.
Ideally, there should be 40 SSRC in each bin. Of course, the actual
number in each bin is a random variable whose expectation is 40.
With 2500 SSRC, the coefficient of variation of the number of SSRC
in a bin is 0.1, which means the number should be between 36 and
44. The test is thus deemed successful if each bin has no less than
30 and no more than 50 SSRC.
Running this test may require substantial amounts of time, particularly
if there is no automated way to have the implementation join the
session. In such a case, the test can be run fewer times. With
26 tests, half of the SSRC should be less than 2**31, and the other
half higher. The cofficient of variation in this case is 0.2, so
the test is successful if there are more than 8 SSRC less than 2**31,
and less than 26.
In general, if the SSRC is collected N times, and there are B bins,
the coefficient of variation of the number of SSRC in each bin is
given by:
coeff = SQRT( (B-1)/N )
7 Authors' Address
Colin Perkins Colin Perkins
Department of Computer Science Department of Computer Science
University College London University College London
Gower Street Gower Street
London WC1E 6BT London WC1E 6BT
United Kingdom
Email: c.perkins@cs.ucl.ac.uk Email: c.perkins@cs.ucl.ac.uk
9 References Jonathan Rosenberg
Lucent Technologies, Bell Laboratories
101 Crawfords Corner Rd.
Holmdel, NJ 07733
Email: jdrosen@bell-labs.com
Henning Schulzrinne
Columbia University
M/S 0401
1214 Amsterdam Ave.
New York, NY 10027-7003
Email: schulzrinne@cs.columbia.edu
8 References
[1] S. Bradner, ``The Internet Standards Process -- Revision 3'', [1] S. Bradner, ``The Internet Standards Process -- Revision 3'',
RFC2026, Internet Engineering Task Force, October 1996. RFC2026, Internet Engineering Task Force, October 1996.
[2] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, ``RTP: [2] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, ``RTP:
A Transport Protocol to Real-Time Applications'', RFC1889, Internet A Transport Protocol to Real-Time Applications'', RFC1889, Internet
Engineering Task Force, January 1996. Engineering Task Force, January 1996.
[3] J. Rosenberg and H. Schulzrinne, ``Sampling of the Group Membership
in RTP'', draft-ietf-avt-rtpsample-05.txt, July 1999.
 End of changes. 44 change blocks. 
67 lines changed or deleted 545 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/