CURRENT_MEETING_REPORT_
Reported by Steve Casner/USC-ISI
Minutes of the Audio/Video Transport Working Group (AVT)
Overview
The meeting began with a brief report on the status of the Real-time
Transport Protocol (RTP). The draft RTP specification was submitted with
a request for IESG Last Call just before the previous IETF meeting in
November. The review by the Transport Area Directorate called for
several changes so that RTP would more closely follow the principles of
Application Level Framing (ALF) and Integrated Layer Processing (ILP)
proposed by David Clark and David Tennenhouse in their SIGCOMM 1990
paper. In two discussions between Steve Casner, Ron Frederick and Van
Jacobson, in which the vat and nv programs were taken as design
examples, the following list of proposed changes was constructed:
o Carry the control and data traffic on separate ports
o Move the application-level multiplexing of the channel ID to an
encapsulation, for the cases where it is needed
o Minimize the use of options
o Make the definition of some fields application-specific (in
particular, the timestamp clock rate and sync marker)
o Use global rather than local IDs, to be able to detect loops
o Specify more precisely how reception reports should be provided
These changes were described in more detail by Steve Casner in a long
message sent to the rem-conf@es.net mailing list on 21 March 1994. The
first 90 minutes of the first session, and the beginning of the second
session, were occupied by a presentation of these changes. The sections
below interleave the main points from the presentation of proposed
changes with issues from the discussion that followed. The working
group generally agreed with the changes, although some remaining details
were identified. A summary appears at the end of these minutes.
Our task is now to complete the design to address these details, update
the specification and get consensus from the working group via e-mail.
Steve Casner will take responsibility for sending out a more complete
draft of the proposed changes to start the discussion. Everyone is
encouraged to participate. Please send e-mail if there were issues not
addressed, to the rem-conf list or to Steve. The goal is to submit the
draft for Last Call after review at the July IETF meeting in Toronto.
After reviewing the RTP submission in November, the directorate
recommended that the protocol be given Experimental status rather than
Proposed Standard. However, John Wroclawski said that this was only a
strategy for dealing with the differences of opinion about the protocol,
and that with the proposed changes he believes the directorate would not
have a preference. John and others expressed personal preferences for
Proposed Standard status as the goal, once the details of the changes
are completed and integrated into the specification. No objections were
voiced.
At the end of the second session, there were two additional
presentations. Julio Escobar gave a report on the use of RTP to support
the Synchronization Protocol developed at BBN. The only requirement not
satisfied by RTP was the need to communicate the calculated
synchronization delays among the destination processors; this could be
added to the control packet as application-specific data.
Don Hoffman gave a brief description of the two Internet-Drafts just
released on encoding profiles for Cell-B and MPEG/MPEG-2. Cell-B was
developed by Sun but is freely available. MPEG-2 is in development as
an ISO/IEC standard. In the MPEG profile, two formats are proposed, one
for interoperation with other transport mechanisms using the MPEG-2
Systems environment, and a second, simpler format intended for native
Internet-style applications. Comments on the drafts were solicited.
The drafts are:
o ``RTP Encapsulation of Cell-B Video Encoding''
(draft-speer-cellb-rtp-encap-00.txt)
o ``RTP Encapsulation of MPEG1/MPEG2''
(draft-hoffman-rtp-mpeg-encap-00.txt)
These encoding profiles will be finalized after the RTP changes are
resolved, and reviewed at the Toronto IETF meeting.
There has also been further work on the JPEG encapsulation since the
November meeting. It is now proposed that a small header be included at
the start of the data area in each packet. This would be a more compact
representation of some of the information in a JFIF header. With this
header, decoding restarts would be possible, allowing partial frames to
be decoded. Those who are interested in more details should send e-mail
to Bill Fenner.
Proposed Changes to RTP
The sections below interleave the main points from the presentation of
proposed changes with issues from the discussion that followed.
However, much of the presentation of advantages and disadvantages has
been omitted here; those who did not read the message describing the
changes are advised to fetch it from ftp.isi.edu, in
/mbone/avt/rtpv2-proposal.txt. In the same directory is
rtpv2-presentation.ps which contains the slides from this meeting.
1. Control and Data on Separate Ports
This change removes RTCP functions from RTP data packets and puts them
into a separate packet stream on another port to streamline data
processing and to allow monitoring programs to receive the control
information without having to sort through the data.
No issues regarding this point were brought up in the discussion.
However, in e-mail, Jarmo Molsa expressed the concern that using
separate ports would require an additional socket on many systems, and
that on some systems the number of sockets is limited.
2. Remove Channel ID, Put Multiplexing into Encapsulations as Needed
There has been quite a bit of debate about the channel ID in the past,
but none during this meeting. Most applications that may have used
multiple channel IDs could use multiple destination ports instead.
3. Replace Data Options with a Bit Field
With the RTCP operations separated into another packet stream on a
different port, there are only a few optional fields to be selected in
data packets. That allows the optional fields to be indicated by bits
in the fixed header. If the bits are also grouped together, it is
possible to interpret them as a ``packet format,'' which is a single
demultiplexing point for processing as a set of fixed formats if
appropriate. The packet format method might not be used in software
implementations, except perhaps for a fast-path when all options are
off; however, for hardware, the bit-field approach would be much simpler
than the option structure as defined in the current RTP specification.
The RTP options would be replaced as follows:
o CSRC (content source) -- A bit field of 5 or 6 bits in the fixed
header to count the number of content source identifiers to follow,
for packets produced by a bridge (mixer). Zero indicates that the
packet did not come from a bridge. This count takes the place of
the length field in the current CSRC option.
o SSRC (synchronization source) -- It was decided that the SSRC
identifier should always be included (see the discussion of global
identifiers below), so this option becomes part of the fixed
header.
o BOS (beginning of sync unit) -- Eliminated as an option.
o APP (application-specific) -- Application-specific functions could
be defined in profiles as extensions to the RTP header, but there
is no provision for one implementation of an application to define
its own optional information in a way that other implementations
can simply ignore.
o SDST (sync destination, or reverse-path option) -- Reverse path
packets would be eliminated because translators would not keep a
table of source transport address to SSRC identifier mappings, and
the SSRC/SDST would not be visible in encrypted packets.
o ENC (encryption) -- When encryption is used, the whole RTP unit is
encrypted (all of the RTP header and data). The receiver depends
upon header validity checks (version, format, sequence number, and
timestamp having reasonable values) to discard packets that should
have been decrypted (or decrypted with a different key). There is
no provision for an explicit initialization vector; instead, zero
would be used with random initial values for the sequence number
and timestamp to deter a known plain-text attack. The key and
encryption algorithm would be specified by out-of-band information;
key switching can be done by decrypting just the header with the
old key first, and if the validity checks fail, then trying again
with the new key.
o MIC (authentication) -- An authenticated packet would be indicated
by a bit in the header which would indicate the presence of an
authentication field later in the header. With the global
identifier scheme, the SSRC could be authenticated to have been set
by one of the sources (but could still be false). The
authentication method (covered by ENC, keyed, symmetrically
encrypted, or asymmetrically encrypted), algorithm and key (if any)
would be known from out-of-band information. As with encryption,
key changes could be accomplished by trying with old and new keys
in succession. Alternatively, a key descriptor could be included
at the start of the authentication field. To allow some receivers
to ignore the authentication without knowing the out-of-band
information, a length field would be needed at the start of the
authentication field.
Some details for the encryption and authentication methods have not been
fully specified. Encryption requires an indication of how much padding
was added to the end of the data to round up the length to a multiple of
the encryption block size. Christian Huitema also suggested that the
authentication digest be appended as a trailer rather than a header
encapsulation to allow for hardware processing or to allow a single loop
through the data for decryption, authentication, and decompression, per
the ILP design principle. It may be possible to use one bit in the
header to indicate whether there is any trailer present, and then to
structure the trailer to indicate padding and authentication digest. In
e-mail, Mark Wahl brought up the desire to include a full NTP timestamp
and sender description (e.g., distinguished name) within the
authentication to minimize replay and support non-repudiation. These
details are to be designed and presented later.
The other fields in the first 32 bits of the RTP header are the version
number, format, sync marker, and sequence number. It is proposed that
the version number be bumped to 2 if these proposed changes are adopted.
The format field would remain unchanged. The sync marker definition
would change (see below), but would remain one bit. The sequence number
should stay at 16 bits for arithmetic convenience, but could be trimmed
if necessary. So, the resulting header bit count would be:
6 for CSRC count
1 for encryption/authentication trailer
2 for version
6 for format
1 for sync marker
16 for sequence number
---
32
Jon Crowcroft said that the UCL monitoring software uses sequence
numbers to measure loss and reordering, so reducing the sequence number
space to 8 bits would cause a problem for their sampling mechanism (over
a long view, not looking at all packets). Van Jacobson commented that
misordering by more than the sequence number space can still be
corrected using the timestamp. The purpose of the sequence number is to
detect gaps.
Jon also requested that space be made for one additional bit to indicate
the congestion probe options used in Ian Wakeman's congestion control
scheme. Several others expressed concern in off-line comments that
there should be some mechanism for adding functions or options to the
data packets. This is an issue that needs further discussion.
4. Media-specific Timestamps
To eliminate the requirement for RTP applications to know the time of
day and some possible, but rare, off-by-one errors in timestamp tick
rate conversion, it is proposed that the rate at which the clock ticks,
instead of always being 65536 Hz, would become a parameter of the
format. For some formats, such as the variable frame rate video we are
now using, it may make sense to retain the 65536 Hz rate, while for most
audio formats, the clock rate would be set to be the same as the
sampling rate, as is done for the timestamp in vat.
It is also proposed to remove the requirement for senders to make
timestamp adjustments. For example, the timestamps would just follow
the input device's sample counter. For senders that do know the time of
day, control packets would carry both an RTP timestamp (sample clock)
and the corresponding full 64-bit NTP timestamp to establish the
relationship.
Bill Fink noted that with the previous definition of the RTP timestamp
as the middle 32 bits of an NTP timestamp, it would be simple for a
recorder to replay an RTP stream with the original timing or to
synchronize the playback of two RTP streams without any knowledge of the
encodings. He asked if recorders would now have to be media-specific.
There are several possibilities. A recorder can replay packets with the
same timing as they were received simply by recording its own local
timestamps along with the packets. However, that requires extra space,
and does not remove the jitter induced on the path from the source to
the recorder. The recorder can reconstruct the source's timing in
several ways: 1) from the media timestamps and the nominal rate if it
is known, 2) by calculating the nominal rate based on the difference
between times in a pair of control packets relating media timestamps to
real time, or 3) by calculating the nominal rate based on the arrival
rate when the packets are received.
5. Application-specific Sync Marker Bit
In the current RTP specification, the sync bit is defined to mark the
last packet of a synchronization unit. The proposed change is to allow
the meaning of the sync marker bit to be defined by an application
profile. The application profile could further specify that the bit is
defined by each of the encoding profiles to be used under that
application profile.
In e-mail, Henning Schulzrinne suggested that two sync marker bits be
defined in the fixed header, one for start and one for end of
synchronization unit, since both events are interesting, as opposed to
making the one bit variable and requiring the application to define what
it means. However, the general sentiment in the meeting was in favor of
one flexible bit as proposed because there may be more than these two
meanings, e.g., in video there may be a difference between sync unit and
frame. The recommendation was to remove the word ``sync'' from the
description of the bit, making it an application-specific marker to be
defined as seen fit in the application profile.
6. Global Source Identifiers
RTP currently uses locally unique source 16-bit identifiers to keep
track of distinct sources when packets flow through translators and
bridges and lose their original transport addresses. The identifiers
are locally assigned by the translators and bridges and are remapped by
successive translators or bridges. The proposed change is based on the
scheme used by vat and wb in which sources assign 32-bit identifiers
that are globally unique within a particular medium in a particular
session. No remapping is required; loops can be detected.
The way the proposed scheme would be specified is that the identifiers
are 32-bit opaque numbers, and that there may be a variety of means to
assign them, including choosing them randomly. Since there may be
collisions in a distributed allocation mechanism, there is a collision
resolution protocol, but the allocation mechanism should be such that
the collision resolution protocol is typically exercised less than 1% of
the time. Two mechanisms are proposed:
o When a participant first joins a conference, the identifiers of the
other participants are likely to be heard before the new
participant transmits, so there is a chance to choose another
random number if there is a conflict.
o If a new site begins using an identifier in conflict with an
existing one, then any site in the session can send a message
challenging the new participant (since the owner of the identifier
might not be in the session at that moment). Randomized delays
would be used to prevent an implosion of responses. This challenge
mechanism would need to be specified in the protocol.
6.1 Use of IPv4 Addresses
The topic receiving the most discussion during the meeting was Van
Jacobson's proposal that in the current Internet multicast environment,
one way to assign unique identifiers is to use the IPv4 address of the
host if there is only one source per host. Van argued that this is
almost always the case because sessions tend to be associated with a
particular set of hardware resources, for example, the mike and speaker
associated with a particular workstation. Even if multiple X terminals
that have audio hardware operate off a single workstation, the X
terminal also has an IP address which can be used.
For those cases where there are additional sources on one host, a
identifier would be chosen at random from the ``class F'' IP address
space (26 bits) so as not to conflict with assigned addresses.
Christian Huitema pointed out that we could use the IP multicast class D
space (28 bits) since a multicast address should never be a source
address. However, a bit of additional analysis done since the meeting
by Sally Floyd in response to a question from Steve Casner shows that it
may be better just to choose the random numbers from the 32-bit space
anyway. For a session with 2000 participants, the probability of
collision is lower in the separate 26-bit space only if the number of
random allocations is less than 60, and in that case the probability of
collision is less than 0.00005 either way.
Using the IPv4 address for most identifiers has two advantages:
o The identifier field could be omitted and a single bit could be
used in the RTP header to denote that the identifier was implicit
in the common case where the identifier is the same as the source
address of the packet (a significant reduction for audio).
o Given that IP addresses are (generally) unique, this reduces the
probability of identifier collisions by requiring fewer random
allocations (compared to allocating all identifiers randomly).
Since RTP may also be used over protocols other than IP, Jon Crowcroft
suggested that the specification allow the use of unique addresses from
any address space, for example, the bottom 32 bits of an IEEE 802
address. Unfortunately, this idea runs into trouble when we consider
interoperation among multiple networks with different address spaces.
Ron Frederick and Abel Weinrib pointed out that two spaces may have
allocation patterns such that the rate of collision is much higher than
would be the result of allocating all identifiers randomly. For
example, consider a session involving multiple enterprises connected
through firewalls and each using the small portion of the IPv4 space
allocated to private networks as described in RFC 1597. Even when the
session size is small, some individuals who communicate frequently might
always collide (because the addresses are fixed).
Therefore, only one address space can be allowed to us use non-random
assignment unless the spaces can be arranged to be non-overlapping, and
that seems impractical. It seems technically bad to give the
optimization to IPv4 if we expect this protocol to live for a while, not
to mention the political concern that anything that says ``IPv4
address'' in it is probably short-sighted.
Ron also disagreed with Van's contention that the presence of multiple
sources on one host would necessarily be infrequent. For example, one
might run multiple copies of nv for multiple cameras or for a camera and
an X screen capture source. Many applications would require the extra
mechanism to support figuring out if the IPv4 address could be used or
if a random identifier must be allocated.
The conclusion was that the specification should not suggest the use of
IPv4 addresses or any other fixed mapping of an address space to the
32-bit identifier space. Instead, applications should always allocate
identifiers randomly in the full 32-bit space. A combination of the
address and time might be used to seed the random number generator.
Given that the synchronization source (SSRC) identifier is to be chosen
randomly, that identifier must always be included explicitly in the RTP
header. While many of us hate to see the header length increased from 8
to 12 bytes, there was a consensus that this was the right decision
because it simplifies several other aspects of the protocol: it means
we don't need a flag bit to indicate inclusion of the SSRC field, it
allows translators to forward encrypted and/or authenticated packets
without any special handling, and it eliminates any dependence upon the
packet source address (e.g., IP address).
6.2 Permanence of Identifiers
One of the advantages that may have been cited for using the IPv4
address as the identifier is its permanence. When an application using
random identifiers is killed and restarted in the same session, a person
may be identified as a new source unless the application stored the
previously allocated identifier somewhere. However, it is also wrong to
assume that the IPv4 address would serve as a persistent identifier for
a participant. Van Jacobson pointed out that there may be multiple
people using one machine serially in one session, and they should be
identified uniquely; John Wroclawski noted that the IP address may
change between application invocations due to mobile computing and
dynamically assigned addresses. The specification must state that it is
mandatory for an application that cares about reuse to provide a way to
save the identifier itself, independent of what scheme was used to
select the identifier in the first place.
Ron Frederick said that even if IPv4 addresses were used as identifiers,
some other source might allocate the same number randomly or through
some other means. Therefore, applications must always be prepared to go
through the collision resolution protocol. Abel Weinrib took the point
further, saying that assumptions of permanence are dangerous. If an
application saves an identifier and tries to reuse it sometime later,
another source may have begun using that identifier in the meantime so
the reuse would be seen as a collision and the first application would
be stuck.
For applications that require long-term permanence, or for which
information ownership has serious consequences, a higher-level
participant name, such as may be carried in the RTP control packet or a
higher-level control protocol, should be the point of ownership and the
RTP source identifiers should be considered transient. Bill Fink noted
that the use of these identifiers is very dependent upon how the control
protocol works and how the session and directory information is
maintained.
6.3 Scaling Limit for Random Identifier Allocation
The primary disadvantage of random identifier allocation is the
possibility that two sources will choose the same number; this is the
same as the ``birthday problem.'' Steve Casner presented two graphs of
probability of collision based on analysis and bits of Mathematica
supplied by Sally Floyd. For identifiers picked uniformly from a 32-bit
space, the probability of there being at least one collision is 0.0001
for 1K identifiers chosen or 0.01 (1%) for 10K identifiers chosen.
Considering that not all the identifiers in a session are chosen at
once, it is useful to consider that the probability of collision is much
smaller for adding one participant to a session in which the identifiers
are already known not to conflict.
So, for most applications, the maximum session size for which the random
allocation scheme performs acceptably would be somewhere in the range
1K-10K. This is not a new constraint since it matches the limit on
session size already imposed by the rate backoff limit for the sender
identification and reception report packets. However, it is important
to insure that the collision resolution protocol scales (or fails
gracefully) when the expected limit is exceeded.
Some sessions, such as IETF meetings and space shuttle missions, are
already near 1K in the cumulative list of participants, though the
maximum number of simultaneous participants is around 200-300. We are
likely to reach the limit within the expected life of the protocol. To
go beyond that will require some additional mechanism such as
aggregation and hierarchy. Van Jacobson suggested that in a large,
private broadcast system, one might assign customer identifiers as
people sign up, and use those as globally unique identifiers. Or, in
truly unidirectional systems, the receivers may not require unique
identifiers because they cannot emit any packets.
John Wroclawski believes there is a clear architectural understanding of
how to make this scale to much larger systems, and there is some
engineering work that's beginning to get underway. This may well be an
appropriate future direction for this protocol and this working group,
but we don't know the general solution yet. Perhaps the specification
should include an applicability statement for the random identifier
scheme as defined, along with some hints about the architectural ideas
and work in progress, to encourage experimentation.
7. Control Packet Format/Reception Reports
With control and data being carried on separate ports, the functions of
the RTCP options would be moved into the control packets. The primary
functions are:
o Providing information about the sender, e.g., name.
o Providing reception reports for all sources received since the last
report, or round robin through the list for as many as will fit;
reports should contain absolute information rather than deltas so
it does not matter if a report is missed.
o Relating the sender's media timestamp to real time for intermedia
synchronization, also marking the time of the reception reports so
rates can be calculated from differences in packet and byte counts.
The format of control packets has not been as well defined as the other
items in the proposed collection of changes. The header format for the
control packets need not be exactly the same as for the data packets,
but it may be useful to keep them similar. SSRC, CSRC, encryption and
authentication are required for control packets as well as data packets,
and the mechanisms should be the same. The general guideline for the
construction of the control packet is to put more common information
first so that application-independent monitors can process all the
common information without having to know anything about the format of
the application- or media-dependent information. The length of any
application-dependent section would be implicit in the profile that
defines the application. However, for those applications that may
include media-dependent information, an identifier and possibly a length
field for the particular media format would be required.
7.1 Mandatory Reception Reports
In previous AVT meetings, it has been suggested that RTCP might be
removed from the RTP specification entirely. However, Van Jacobson
argues that in order for RTP to be used on a large scale in the
Internet, we must provide mechanisms for network service providers as
well as users to evaluate the distribution quality. The multicast data
itself is the test traffic, and the reception reports are the monitoring
mechanism. This mechanism needs to be considered a fundamental part of
RTP covering all applications; its use should not be considered
optional. The RTP specification and application profiles should be
written such that any application using RTP will work in multicast mode,
with unicast as a special case. In an IP multicast environment,
reception reports must be sent by all receivers, including those that
never send any data. The rate at which the reports are generated is
scaled back as the number of participants increases so that the
aggregate control traffic does not exceed the bandwidth of one data
stream. The control packets would be sent too slowly to be useful
beyond a session size somewhere in the 1K-10K range.
This brought up the question of using RTP in truly unidirectional
systems in which it is presumed that successful transmission is assured
by some means and in which it may not be possible for receivers to send
a report. In such a system, reception reports would not be required.
The specification will need some applicability statements for those
pieces that may not be architecturally relevant as we move into new
applications. A profile may specify how to use RTP in a unidirectional
environment.
7.2 Requirement for NTP Time in Control Packet
Frank Kastenholz expressed concern about the requirement for an NTP
timestamp in the control packet. This needs to be clarified: systems
that do not know what time it is should not be required to put an
absolute time into that field. However, if the calculation of the data
rate and packet rate from the counts in the reception report depends
upon the time field, then there may be a requirement for a time value
that increments at close to real time even if it is not related to the
time of day. An audio application might be able to keep track of time
by referencing the sample counter, but what about applications with
aperiodic data?
7.3 Congestion Control
Jon Crowcroft and Christian Huitema would like to enable receivers to
more quickly report that they are experiencing loss. Jon sought support
for Ian Wakeman's congestion control scheme which selects receivers to
report more frequently than the rate backoff of reception reports would
allow in a large session. Christian wanted the reception report to
include an explicit measurement of packet loss by the receiver so that
when loss is observed in small sessions the sender can be advised to
adapt. Van Jacobson claims that transients are not a concern, and that
one cannot robustly make a better diagnosis than the proposed reception
report mechanism allows without making the report size much larger. He
offered to provide convincing arguments off-line. We are awaiting
results of those discussions.
7.4 Reports for Multiple-priority Streams
John Wroclawski asked whether the reception reports would provide an
accurate estimate of overall loss rate for multi-priority schemes and
layered encodings. One may only care about the highest priority
packets, or one may want more information than the general reception
report provides. Additional information could be added in the
media-dependent section of the report, but this might not solve the
problem for generic monitoring tools. Van Jacobson said that the
different priority data streams should be sent on different multicast
addresses so the loss rates can be reported separately. However,
monitors would still need to know that the loss rate on lower priority
streams is expected to be higher. This question needs more thought.
7.5 Additional Control Functions
The sender description and reception report information correspond to
the RTCP SDES and QOS options. In addition, if the functions of the
FMT, BYE and APP options are to be retained, they need to be
incorporated into the control packet structure in some way. These
functions could be specified by different packet types in the control
packet header, plus another type for the mandatory sender
description/reception report. Greg Minshall suggested that there be
some mechanism for tagging along additional information on the report
packets that must be sent periodically anyway. One way would be to
allow multiple control packets to be aggregated into one lower-layer
packet.
o FMT (format description) -- Allows format codes, which go in the
6-bit field in the data packet header, to be defined dynamically in
addition to the small set that are predefined. FMT is not intended
for redefinition of codes to allow switching among more than 32
formats in one session; applications needing to do that should
define a format whose data field begins with a further
specification of the format. FMT may be seldom used since a
higher-layer session protocol, such as a session directory, would
normally be used to select the formats for a session and define any
format codes not already predefined.
o BYE (goodbye) -- Indicates that a source is terminating its
participation in a session. Since no source description or
reception report information is required, this could be a separate
(trivial) control packet format. Greg Minshall suggested that we
might want the BYE packet to include the reason for leaving.
o APP (application-specific controls) -- Application-specific
sections of the sender information and reception reports in the
control packet already provide a means to carry periodic
information defined by an application profile. However, multiple
implementations of a single application profile may interoperate
but still need to communicate information that may be ignored by
other implementations. Each profile could define on its own a
mechanism to include implementation-dependent information, but it
seems better to have a common mechanism. Implementation-specific
data could be added at end of the reception reports after the
media-dependent data. To avoid conflicts among multiple
implementations each of which wanted to include its own
information, some implementation identification such as the ASCII
name in the existing APP option is required. A separate APP packet
type would use the same implementation identification mechanism for
transporting signals that are not periodic and have nothing to do
with the sender information.
Charley Kline asked whether we should simply require that applications
use some more sophisticated session control protocol if they need to
communicate any control information beyond what's in the sender
description and reception reports. For many applications, it is likely
to be more convenient to use the RTCP path. The basic question is,
should we make a provision for RTP to operate in the absence of any
higher-layer mechanism for some applications?
Summary of Agreements and Open Issues
The following items were agreed during the meeting:
o Global identifiers would always be 32-bit random numbers; the IPv4
address should not be used.
o The sync source (SSRC) identifier would always be included in a new
field added to the fixed RTP header.
o Encryption should cover the whole packet; zero would be used for
the initialization vector, with random initial values for timestamp
and sequence number.
o The above agreements imply elimination of reverse-path packets.
o The word ``sync'' would be dropped from the name of the marker bit;
its meaning would be defined by the application profile.
o The plan is to seek Proposed Standard status for the protocol.
The following open issues were identified during the discussion:
o Need to define how to indicate the length of padding required for
encryption and the format of a trailer for authentication.
o Should an optional congestion probe field be defined?
o Should there be a means to add options to a data packet?
o The control packet format needs to be defined in detail.
o Specify how timestamps are used on systems that don't know time.
o Should a receiver-calculated loss measure be in reception reports?
o What is the effect of multi-priority streams on loss monitoring?
o Should the FMT and APP options be included? (Should RTP be usable
without a higher-layer session protocol?)
o An applicability statement for RTP needs to be defined.
Attendees
Brian Adamson adamson@itd.nrl.navy.mil
Kannan Alagappan kannan@sejour.lkg.dec.com
Richard Bantel rb@mtsol.att.com
Lou Berger lberger@bbn.com
Steven Berson berson@isi.edu
Jim Binkley jrb@cs.pdx.edu
David Borman dab@cray.com
Carsten Bormann cabo@informatik.uni-bremen.de
Robert Braden braden@isi.edu
Michael Bradley bradley@mdd.comm.mot.com
Michael Bringmann michael@rd.qms.com
Theodore Brunner ted.brunner@tek.com
John Carlson johnc@cac.washington.edu
Stephen Casner casner@isi.edu
Andrew Cherenson arc@sgi.com
Eric Chin-Li-Sun ericc@tera.com
Richard Cogger R.Cogger@cornell.edu
Eric Crawley kaufman@scrc.symbolics.com
Jon Crowcroft jon@cs.ucl.ac.uk
Roger Cyganer cygander@telebit.comm
Sandip Dasgupta sandip@cup.hp.com
Luca Delgrossi luca@ibmpa.awdpa.ibm.com
Chuck deSostoa chuckd@cup.hp.com
Julio Escobar jescobar@bbn.com
William Fenner fenner@cmf.nrl.navy.mil
Antonio Fernandez afa@bellcore.com
William Fink bill@wizard.gsfc.nasa.gov
Sally Floyd floyd@ee.lbl.gov
Ron Frederick frederick@parc.xerox.com
Thane Frivold frivold@erg.sri.com
Mark Handley mhandley@cs.ucl.ac.uk
Don Hoffman hoffman@eng.sun.com
Christian Huitema Christian.Huitema@sophia.inria.fr
Geoff Huston g.huston@aarnet.edu.au
Phil Irey pirey@relay.nswc.navy.mil
Steven Jackowski stevej@syzygycomm.com
Van Jacobson van@ee.lbl.gov
Kyungran Kang krkang@cosmos.kaist.ac.kr
Frank Kastenholz kasten@ftp.com
Alan Katz katz@adonis.com
Andrew Knutsen andrewk@sco.com
Robert Kummerfeld bob@cs.su.oz.au
Paul Leach paulle@microsoft.com
Arthur Lin yalin@srv.pacbell.com
Chris Maeda cmaeda@cs.washington.edu
Allison Mankin mankin@cmf.nrl.navy.mil
David Marlow dmarlow@relay.nswc.navy.mil
Ken Masica masic@es.net
Yosi Mass yosi@ubique.co.il
Greg Minshall minshall@wc.novell.com
Steve Minzer minzer@bellcore.com
Dennis Morris morrisd@cc.ims.disa.mil
Luc Nguyen luc@bss.com
Richard Paine painer@ct.si.cs.boeing.com
Joseph Pang pang@bodega.stanford.edu
Mark Prior mrp@itd.adelaide.edu.au
J. Mark Pullen mpullen@cs.gmu.edu
Robert Reschly reschly@brl.mil
William Robertson rob@agate.berkeley.edu
Francois Robitaille francois.robitaille@crim.ca
Martina-Angela Sasse a.sasse@cs.ucl.ac.uk
Eve Schooler schooler@isi.edu
Dallas Scott scott@fluky.mitre.org
Katsuhiro Sebayashi sebayasi@tnlab.ntt.jp
Ming-Jye Sheu msheu@vnet.ibm.com
Michael Sorsen c02420MS@wuvmd.wustl.edu
Michael Speer michael.speer@sun.com
Michael St. Johns stjohns@arpa.mil
Rodney Thayer rodney@world.std.com
Dave Thompson davet@ncsa.uiuc.edu
Kevin Thompson kev@gateway.mitre.org
Akihiro Tominaga tomy@sfc.wide.ad.jp
Jerry Toporek jt@mentat.com
Jost Weinmiller jost@prz.tu-berlin.de
Abel Weinrib abel@bellcore.com
Linda Winkler lwinkler@anl.gov
Dan Wood dwood@bbn.com
John Wroclawski jtw@lcs.mit.edu
Shinichi Yoshida yoshida@sumitomo.com
Charles Young Charles.E.Young@att.com