home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
drafts
/
draft_n_r
/
draft-rosenberg-itg-00.txt
< prev
next >
Wrap
Text File
|
1996-11-26
|
64KB
|
1,285 lines
Internet Engineering Task Force Audio-Visual Transport WG
INTERNET-DRAFT J. Rosenberg
Lucent, Bell Laboratories
H. Schulzrinne
Columbia University
November 26, 1996
Expires: May 26, 1997
Issues and Options for an Aggregation Service within RTP
draft-rosenberg-itg-00.txt
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
distribute working documents as Internet Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
To learn the current status of any Internet-Draft, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net
(Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
Coast), or ftp.isi.edu (US West Coast).
Distribution of this document is unlimited.
Abstract
This memorandum discusses the issues and options involved
in the design of a new transport protocol for multiplexed
voice within a single packet. The intended application is
the interconnection of devices which provide "trunking" or
long distance telephone service over the Internet. Such
devices have many voice connections simultaneously between
them. Multiplexing them into the same connection improves
on the efficiency, enables the use of low bitrate voice
codecs, and improves scalability. Options and issues
concerning timestamping, payload type identification,
length indication, and channel identification are
discussed. Several possible header formats are identified,
and their efficiencies are compared.
This document is a product of the Audio-Video Transport working
group within the Internet Engineering Task Force. Comments are
solicited and should be addressed to the working group's mailing
list at rem-conf@es.net and/or to the author(s).
J. Rosenberg, H. Schulzrinne Expires 5/26/97 Pg. 1
INTERNET-DRAFT Nov. 26, 1997
1. Introduction
With the tremendous changes in the telecommunications industry,
and the recent growth of the Internet, there is a new opportunity
for offering long distance telephony over the Internet. Such a
service can be offered by allowing users to dial a local access
number, connecting them to a device called an Internet Telephony
Gateway (ITG). This device prompts the user for a destination
telephone number, and then routes the call over the Internet to a
similar device at the local exchange of the destination. There,
the call is completed when the destination ITG dials the end user.
The scenario is depicted in Figure 1.
------- -------- ----------
| Phone | --------| NY ITG |---------------| Internet |
------- -------- | |
| |
| |
------- -------- | |
| Phone | --------| LA ITG |---------------| |
------- -------- ----------
Figure 1: Internet Telephony Gateway
In this application, the Internet is used only for the long
distance portion of the telephone call. Access to the service is
still via the traditional POTS. Current implementations of this
service are using H.323 to set up and tear down a new connection
each time a user establishes or terminates a call. However, H.323
is the wrong protocol for many reasons. First, it is far too
complex, providing for capabilities and features which cannot be
used because both endpoints are analog telephones. Secondly, a
significant increase in efficiency (in excess of 30%), can be
readily achieved if all of the voice calls between two ITG are
multiplexed into a single packet, instead of using a separate
connection (and thus separate packets) for each. Such multiplexing
reduces overhead by increasing the effective payload without a
corresponding penalty in packetization delay. In fact, as more
users are multiplexed, the payload from a particular user can be
reduced in size, or the bitrate reduced, without an efficiency
penalty. Furthermore, multiplexing improves scalability. As the
number of users increases, the number of packets which arrive at
the destination does not increase. This means that computations
which are per-packet (such as RTCP statistics collecting, jitter
accumulation, header processing, etc.) do not increase. The end
result is that multiplexing can simultaneously improve efficiency,
reduce delay, and improve scalability. There are some minor side
J. Rosenberg, H. Schulzrinne Expires 5/26/97 Pg. 2
INTERNET-DRAFT Nov. 26, 1997
benefits in addition to these major three. For example, in the
aggregated scenario, when a particular user enters a silence
period, and stops sending data, the flow of packets will not stop
unless all of the other users are already in silence (generally,
an unlikely event). This means that packets continually arrive,
and that delay estimates obtained from those packets can be
continuously generated. Algorithms for dynamically adapting the
playout buffer at the receiver are based on these delay estimates
[1], and can now be reworked to utilize the continuous stream of
delays, as opposed to relying on the delays received during
talkspurts only. The result is likely to be an improvement in both
end to end delay and loss performance.
In order to perform such multiplexing, a new Internet protocol is
required. This protocol must provide for the transport of multiple
real time streams within a single IP packet. Since the intended
application is real-time, the requirements for timing recovery,
sequencing, and payload identification are nearly identical to
normal single user voice. Since RTP was designed to meet these
requirements [2], it makes sense to build this new multiplexing
protocol on top of RTP. In fact, RTP allows for different profiles
to be defined for a particular application. The goal of this
document is to define a variety of options for that new profile,
and to compare them.
It is important to note that this application is similar in its
requirements to [3], which seeks to multiplex multiple encodings
for a particular user into the same IP packet.
2. Terminology
User: One of the individuals who has data within the IP packet.
Connection: The point to point RTP session between two ITG's.
Channel: A "virtual connection" which is established by allowing a
user to send data within a packet. There are many channels per
connection - this represents the multiplexing.
Channel Identifier: A number which identifies a channel.
Block: The section of the payload of a packet which contains data
for a particular user.
3. Requirements:
The transport protocol must provide, at a minimum, the following
functionality:
1. Delineation. Data from different users must be clearly
delineated.
2. Identification. The channel to which the data belongs must be
identified.
3. Variable lengths: The protocol should support variable length
blocks from a particular user. This allows for variable rate
codecs.
4. Low overhead: Since the protocol is designed for low rate
voice, it should have low overhead. This issue is extremely
important. New coders are emerging which can support near toll
quality at 8 kbps, and acceptable quality at rates even as low as
4 kbps. It is desirable to support such codecs, as they can reduce
J. Rosenberg, H. Schulzrinne Expires 5/26/97 Pg. 3
INTERNET-DRAFT Nov. 26, 1997
the cost of providing an ITG service. Furthermore, advances in
coding technology indicate that it is desirable to send very low
bitrate information (1 kbps or less) during silence periods, so
that background noise can be reproduced well (as opposed to
sending nothing). Support of such rates requires a protocol with
low overhead.
5. Marker: A general purpose marker bit should be available for
all users within the connection.
6. Payload Identification. The codec in use for each user should
be indicated somehow. It is a requirement to allow for the coding
type to change during the lifetime of a channel.
4. Issues
The following section identifies a number of issues which have an
impact on the design of the protocol. It also identifies a variety
of options for providing the specific services of the protocol.
4.1 How to bind telephone numbers to channel identifiers
There are four options for this problem. First, the telephone
number can be included in the per-user header. Second, the
telephone number can be signaled reliably by a companion TCP
connection before data begins. Thirdly, the phone number can be
sent periodically in RTCP in a soft-state fashion. Fourthly, the
information can be sent periodically over a reliable TCP based
control channel. The first approach avoids any synchronization
problems, but has high overhead. The second approach is a more
traditional approach, but relies on hard state at the destination
ITG. The third approach allows for a refresh of state, but causes
longer setup delays in the face of packet loss. The fourth
approach guarantees reliable delivery of signaling information,
but also generates refreshes to allow for recovery from end-system
failures.
The most reasonable approach seems to be the second - the use of
TCP (or any other reliable protocol) for sending signaling
information. This approach guarantees that the critical
information is received correctly, and in a timely manner. It
avoids bandwidth inefficient refresh as well.
4.2 Payload type identification
There are a number of ways to identify the coding of the payload.
The first is through static types, identified by bits in the
header (like RTP is now). The second approach dynamically adjusts
the coding type based on external messages which bind a coding
type to a channel identifier. Such external messages can be either
UDP or TCP based. A related issue is synchronization of these
changes. Either the timestamps or sequence numbers can be used.
One approach to performing the synchronization is as follows: The
source sends a message reliably to the receiver, indicating that
it will change codings at timestamp N, where N is some future
timestamp (or SN). The N should be chosen far enough into the
future to guarantee that the receiver will get the TCP message
before time N. The farther away N is, the more robust the system
becomes, but the source also loses its ability to adapt quickly.
There are also several options for simple in-band signaling
methods which can assist in error recovery. This is based on the
assumption that it is better for the receiver to know that the
J. Rosenberg, H. Schulzrinne Expires 5/26/97 Pg. 4
INTERNET-DRAFT Nov. 26, 1997
encoding has changed (even though it doesn't know to what), than
to know nothing. This avoids playing garbage out. A one or two bit
"coding sequence number" can be used in the header. Such a number
starts at zero. At the timestamp where the encoding changes, the
SN increments, and stays incremented until the next change. In
this fashion, we are guaranteed that the source will never play
out data using the wrong coding type. Probably just one or two
bits of this SN is necessary.
Yet another approach to changing payload types is via "pseudo-
dynamic" payloads. Before transmission of data commences, a
reliable exchange occurs which downloads a table of possible
encodings of the payload type, based on the capabilities of the
source. The table then remains active for the lifetime of the
connection. This technique can reduce the number of bits required
for the payload type, since a particular gateway is likely to
support just a few codecs. However, it is still a hard state
approach, but it would only fail in the face of end system
failure, not network failure.
Our conclusion is that it is desirable to have the PTI field in
the payload. This makes it possible to do more robust rate
control, which becomes a significant issue when multiple
connections are multiplexed together (and therefore the aggregate
bitrate increases). It also makes sense to signal a table of
encodings for the payload type at the beginning of the connection.
Any particular pair of ITG will generally only support a few
codecs. Therefore, dynamically setting the codings of the PTI bit
makes a more compact representation possible without restricting
the set of codecs which may be used.
4.3 Timestamps
Timing is a very complex issue for the multiplexing protocol. The
first question related to it is whether the protocol will support
mixing of media derived from separate clocks (i.e., voice and
video). Although doing this seems attractive, it is complex and in
opposition to the philosophy under which RTP was developed. RTP
explicitly states that separate media should be placed in separate
RTP streams. This allows for different QoS to be requested for
each media, and for clocks to be defined based on the media type.
Furthermore, this profile is geared towards the aggregation of
voice traffic generated from the POTS across the Internet. As a
result, the only source of data is from a single, 125us clock.
The next basic question is whether timestamps are needed
"globally", i.e., just one per packet independent of the number of
users, or "locally", whereby each user within a packet needs their
own timestamp. A separate question is the representation of these
timestamps in an efficient manner. When considering these
questions, the criteria to keep in mind are:
1. Can silence periods be recovered correctly
2. Can resynchronization occur in the face of packet loss
3. What is the impact on playout buffering and jitter
computation
The answer to this question depends on the desired capabilities of
J. Rosenberg, H. Schulzrinne Expires 5/26/97 Pg. 5
INTERNET-DRAFT Nov. 26, 1997
the protocol. In the most general case, it is possible to have
different frame sizes for each user (for example, 20ms, 10ms, and
15ms) within the same packet. These frames can be arbitrarily
aligned in time with respect to each other (i.e., the 20ms frame
starts 5.3 ms after the beginning of another user's 10 ms frame).
The user can send packets off at any point, containing data from
those users whose frames have been generated before the packet
departure time. A somewhat more restrictive capability is to allow
for different frame sizes and time alignments, but to require that
any packet contains all the same frame sizes, all aligned in time.
The most restrictive case is to require separate RTP sessions for
users with different frame sizes. This requires a channel to be
torn down and re-setup when it changes codec. The desire to
perform flow control on a channel-by-channel basis makes this
approach unacceptable, and it is not considered further.
4.3.1 General Case
First consider the general case. Packets can contain frames from
some or all of the users, and those frames are not the same length
nor time aligned in any way. An example of such a scenario is
depicted in Figure 2. In the figure, there are three sources, and
the ti correspond to the times of packet emissions. When packets
are lost, the variability in the amount and time alignment of data
in each packet makes it impossible to reconstruct how much time
had elapsed based solely on sequence numbers (such reconstruction
IS possible in the single user case). Furthermore, the amount of
time elapsed can easily vary from user to user, and therefore
local timestamps are needed.
The general case introduces further complications which have to do
with jitter and delay computation. Such computations are needed
for RTCP reporting and possibly for the estimation of network
delays, used in dynamic playout buffers. In the single user case,
the jitter is computed between each packet as:
D(i,j) = (Rj - Ri) - (Sj - Si)
Where the Ri correspond to the reception times at the receiver
measured in RTP time, and the Si are the RTP timestamps in the
data packets. The delay is computed as the difference between the
arrival time at the receiver and generation time, as indicated by
the RTP timestamp.
In the multiple user case, these definitions no longer make sense,
as there is no single RTP timestamp any longer. Each arriving
packet will have a single arriving time (Ri), but multiple sending
times (Si,j) for each block j in the ith packet. There are a
number of alternatives for delay and jitter computation in this
case: compute such information for all users, compute such
information for a single user, or generate a single delay and
jitter estimate, but have it be based on information from all
users. There are pros and cons to each approach.
First of all, it is possible for different blocks to experience
different delays (and jitters) even though they are within the
J. Rosenberg, H. Schulzrinne Expires 5/26/97 Pg. 6
INTERNET-DRAFT Nov. 26, 1997
same packet. This is because the general scenario allows for
significant variability, whereby blocks may either vary in size
from packet to packet and within a packet, or not be transmitted
immediately after their completion (the latter happens to source B
in Figure 2). Thus, it is arguable they it may be desirable to
perform adaptive playout buffering separately for each user, which
would require the storage and computation of delays for each user.
The second alternative is to compute the delays for a single user,
and use that information to size all of the other playout buffers.
This may be sub-optimal in terms of delay and loss, depending on
what fraction of the total delay and jitter are introduced by the
packetization itself. There is a second disadvantage to this
approach, however. When that particular user enters a silence
period, delay and jitter information is no longer being received,
and so estimates of network delay stop adapting. This implies that
delay estimates will be old for certain periods of time. An
alternative is to change the user from which delay and jitter
estimates are being collected.
The third alternative is to compute delay estimates based on some
measure derived from all of the users. There are several
reasonable approaches. For example, the delay estimate can be
computed as:
Delay = max{j, Ri - Si,j}
which would yield a conservative estimate of the delay for some
users. This approach requires storage of only a single set of
delay information, although computation still grows with the
number of users in a packet.
--------------------------------------------------
|| || || ||
-----------------------------------------------------
|| || || || || || ||
-----------------------------------------------------
|| || || || || ||
-----------------------------------------------------
t1 t2 t3 t4 t5 t6 t7 t8
Figure 2: Global Timestamp Problem
Sending local timestamps also requires extra bits in the block
headers. It is possible, however, to use offsets for the local
timestamps. A global timestamp can be used in the RTP header (the
field already exists), and each user has a modifier to indicate
position in time relative to that timestamp.
A related question is how big to make the offset field. This
offset is bounded by the difference in time between the earliest
and latest samples within a packet. Clearly, this itself is
bounded by the packetization delay at the source. For this
application, if we assume a 125us sample clock, and bound
packetization delays to 100ms, the offset field is bounded by 800
ticks, requiring 10 bits.
J. Rosenberg, H. Schulzrinne Expires 5/26/97 Pg. 7
INTERNET-DRAFT Nov. 26, 1997
4.3.2 More Restrictive Case
As a more restrictive case, we allow blocks to be present in a
packet if their frame sizes are identical and aligned in time.
Note that this does not imply identical codecs or identical block
sizes in terms of bytes; many voice codecs operate with a 20ms or
50ms frame size. This case would allow all frame sizes of the same
size and time alignment, independent of the codec, into a packet.
This simplifies the timing issue tremendously. Now, the scenario
is much more like the single user application. The sequence
numbers and the frame size completely determine the timing when at
least one user is active. But, when all users enter silence, a
global timestamp is needed to indicate the duration of the silence
period. The global timestamp is sufficient to reconstruct the
timing in the face of losses. Therefore, in this case, only a
global timestamp is required.
It is desirable to support a variety of different frame sizes
within such an aggregated connection, however. The way to do this
in this case is to simply mandate that different packets can
contain different frame sizes; the only restriction is within a
packet. This is not as simple as it may seem at first. Once this
is done, the relationship between sequence numbers and timing is
lost. Consider an example. There are two frame sizes, 10ms and
30ms. Packet N contains 10ms frames, as does packet N+1 and N+2,
however, N+3 contains 30ms frames. Thus, although the difference
in sequence number between the first and fourth is three, the
relative timing is not 10ms*3 or 30ms*3. Due to this fact, the
measurement of jitter is complicated (for the same reasons
described in Section 4.3.1), as it should not be done between two
packets with different frame sizes. It also makes recovery
techniques based on sequence number more complex. To resolve this
problem, we use a natural concept in RTP, which is the
synchronization source (SSRC). The approach is to have a separate
SSRC for each frame size in use. Then, sequence numbers are
interpreted for each SSRC separately. This resolves the problem
with the relationship between timing and sequence numbering. It
also makes jitter and delay computations simpler - they are now
done for each SSRC separately. Furthermore, multiple jitter (and
delay, loss, etc.) values are reported to the source, one for each
frame size. This is also desirable, since the different frame
sizes will cause different packetization delays and packet sizes,
which may cause those packets to see different delays and losses
in the network than other packets.
This case has both advantages and drawbacks when compared to the
general case. As an advantage, timing is greatly simplified, and
the approach falls much in line with the original intentions of
RTP. However, it causes losses in efficiency for systems with a
variety of different frame sizes in operation simultaneously. Such
a situation arises naturally when flow control is applied to each
source individually, as opposed to altering the rate and codec
type for all of the active sources.
J. Rosenberg, H. Schulzrinne Expires 5/26/97 Pg. 8
INTERNET-DRAFT Nov. 26, 1997
4.4 Channel ID
The question of channel identification may seem at first trivial -
simply use a 32 bit number, much like the SSRC, and be done with
it. However, 32 bits adds significant overhead. Reduction of the
number of bits for the channel ID becomes a complex issue. Unlike
the single user case, the connection may remain active for long
periods of time (days or months). The result is that channel ID's
will need to be reused during the lifetime of the connection. It
is critical to ensure that data from different channels is not
confused because of this. Large channel ID spacing helps to
resolve this issue (although it can not eliminate it), so an added
side effect of reducing the number of channel ID's possible is an
increase in the likelihood of such confusion.
The first question to be addressed is how many simultaneous users
can one expect to find in a single packet.
4.4.1 Number of Users
There are several ways to come up with some minimums and maximums.
Delay-bound
Clearly, as we add more users, the store and forward delays
increase since the packet size gets larger. Therefore, if we bound
the per-hop delay, and provide a lower bound on the codec bitrate
and packetization delay, an upper bound on the number of users can
be obtained. Consider a 2.4 kbps codec, with a 20ms frame size.
This is a reasonable minimum combination. Next, consider 50ms
store and forward delays. For a T1, this limits the number of
users within a packet to 965. For a T3, it is 30 times this, or
nearly 29,000. If silence suppression is used, the number of users
within a packet is roughly half the number of active users (on
average), thus requiring twice as many channel identifiers (1930
and 58,000). This bound doesn't seem to tight. Intuitively, even
965 seems too large.
Efficiency bound
The entire purpose of multiplexing is to improve upon efficiency.
Therefore, we should be able to support at least as many users as
is necessary to get good efficiency. Consider the typical case, a
16 kbps codec, with a 20ms packetization delay. This results in
320 bits of data per user. If we assume IP/UDP/RTP (20+8+12=40
bytes = 320 bits), plus an additional word (32 bits) of overhead
per user, the efficiency vs. N becomes:
E = (320N / ((320 + 32)N + 320))
This reaches an asymptote of 90%. It is desirable to be within a
few percent of this, say 88%. Solving for N, this requires 7 users
in a packet, so that we must support at least 14 active channels
(again, due to stat mux). The lower bound, therefore, on the
number of users is around 14.
J. Rosenberg, H. Schulzrinne Expires 5/26/97 Pg. 9
INTERNET-DRAFT Nov. 26, 1997
MTU Bound
In many cases, there is a maximum packet size. This is usually
around 1500 bytes. If we consider a very low bitrate codec, the
minimum block size from any particular user is 32 bits (otherwise,
overheads become very large, and we lose word alignment, so 32
bits is a good minimum). Dividing 1500 bytes by 4 bytes, we obtain
a maximum of 375 users. Multiplying by two, the number of active
channels needed is around 750.
Based on these bounds, we need to simultaneously support at least
10 users, and at most 750. This would imply that at least 8 to 10
bits of channel ID are required.
4.4.2 Channel ID Reuse Problem
It is important to guarantee that data from a particular channel
is never routed to a different channel; this would mean that a
user may hear pieces of conversations from different users, an
error we consider catastrophic. Such misrouting becomes possible
when a channel is torn down, and a new channel is set up soon
after using the same channel ID. Such a scenario is depicted in
Figure 3. Sometime after channel K is torn down, a new channel is
set up using the same channel ID, K. If the data packets (dotted
lines) are being delayed significantly, blocks from the old
channel K may still be present in the data stream after the new
channel K is established. These blocks will then be played out to
the new user of channel K. Protocol support is needed to
guarantee that this can never happen.
| Chnl K data here |
| .......> |
| |
| .......> |
| |
| |
| Teardown K |
| ---------------> |
| |
| Ack Teardown K |
| <--------------- |
| |
| Setup K |
| ---------------> |
| |
| Ack Setup K |
| <--------------- |
| Recv old Chnl K |
| .........> |
| .........> |
Source Destination
Figure 3: Channel ID Reuse Problem
The solution lies in an intelligent signaling protocol. The
protocol must support a two-way handshake for all control
messages. In addition, three simple rules must be obeyed at a
J. Rosenberg, H. Schulzrinne Expires 5/26/97 Pg. 10
INTERNET-DRAFT Nov. 26, 1997
source when setting up or tearing down connections:
1. When a source sends a teardown message, it stops sending data
in the UDP stream for that channel. Furthermore, in the signaling
message, it indicates the sequence number of the packet which
contained the last block for that channel, call this sequence
number K.
2. A source cannot re-use a channel identifier until it has
received an acknowledge from the destination that that particular
channel was successfully torn down.
3. A source cannot send begin to send data from a particular
channel in the UDP stream until it has received an acknowledge
from the destination that the setup is complete.
A few simple rules must also be used at the receiver:
1. When a receiver gets a teardown message, it checks the
highest SN received so far (call this sequence number M). If M >
K, the channel is torn down, and any further blocks containing
that channel ID are discarded. If M < K, blocks from that channel
are accepted until the received SN exceeds K. Once this happens,
the channel is torn down and no further blocks with that channel
ID are accepted.
2. When a setup message is received, the destination will begin
to accept blocks with the given channel identifier, but only if
the sequence numbers of the packets in which they ride is greater
than K.
The use of the sequence numbers allows the receiver to separate
the old channel K blocks from the new ones. This guarantees that
the destination will not misroute packets. An additional benefit
is that the end of speech will not be clipped if the last data
packets arrive after the teardown is received. This protocol is
quite simple to implement, although it requires a table at the
receiver of the values of K for each channel ID.
Alternate solutions to this reuse problem exist which can operate
when the above restrictions are relaxed. The simplest approach is
to have the source keep a linked list of free channel ID's. The
list is initialized to contain all channel ID's, in order. When a
new channel is required to be established, the channel ID is taken
from the top of the list. When a channel is torn down, its ID is
placed at the bottom of the list. This makes the time between
channel ID reuse as long as possible, and reduces the probability
of confusion. With this method, it is no longer necessary to
include sequence numbers in the tear down messages. Also, the
receiver does not need to maintain a table.
4.4.3 Channel ID Coding
This section discusses some of the options for coding the channel
ID field.
4.4.3.1 Fixed Length
J. Rosenberg, H. Schulzrinne Expires 5/26/97 Pg. 11
INTERNET-DRAFT Nov. 26, 1997
The fixed length approach is the most straightforward. A fixed
number of bits is assigned to the channel ID. Issues surrounding
the number of bits required have been discussed above.
4.4.3.2 Implicit + Present Mask
In reality, the channel ID's are very redundant. Both source and
destination know the set of active connections and their channel
identifiers from the signalling messages. Therefore, if the blocks
are placed in the packet in order of increasing channel ID, very
little information actually needs to be sent. In fact, without
silence suppression, channel activity and the presence of a block
in a packet are likely to be equivalent, in which case NO
information actually needs to be sent about channel ID's.
Unfortunately, there are some practical problems with this. First,
silence suppression is used. Secondly, even if it weren't, it is
possible for the voice codecs at the ITG not to have their framing
synchronized (as in the general case above), so that a packet may
not contain data from all users. Thirdly, the source and
destination do NOT have a consistent view of the state of the
system. There is a delay while signaling messages are in transit.
A few simple mechanisms can be used to overcome these
complexities. In the header of the packet, a mask is sent. Each
bit in the mask indicates whether data from a channel is present
in the packet or not. Mapping of channel ID's to bits is done by
sorting the channel ID's, and mapping the lowest number to the
first bit, next lowest to the second, etc. Therefore, if a channel
has no data for that packet, its bit is set to zero. Given that
the source and destination agree on how many connections are
active at all points in time, the number of bits required is known
to both sides.
The next step is to deal with the differences in state. An
additional field, called the "state-number", perhaps 5 bits, is
sent in the header of the packet. This field starts at zero. Lets
say at some point in time, its value is N. The source wishes to
tear down a channel. It sends the tear down message to the
destination, but continues to send data for that channel (or it
may choose to send nothing, but must set the appropriate bit in
the mask to zero). When the destination receives the message, it
replies with an acknowledge. When the acknowledge is received by
the source, the source considers the channel torn down, and no
longer sends data for it, nor considers it in computing the mask.
In the packet where this happens, the source also increments the
state-number field to N+1. The destination knows that the source
will do this, and will therefore consider the state changed for
all packets whose value of the field is N+1 or greater. When the
next signaling message takes effect, the field is further
increased. Even if packets are lost, the value of the state-number
field for any correctly received packet completely tells the
destination the state of the system as seen in that packet.
Furthermore, it is not necessary to wait for a particular setup or
teardown to be acknowledged before requesting another setup or
teardown.
J. Rosenberg, H. Schulzrinne Expires 5/26/97 Pg. 12
INTERNET-DRAFT Nov. 26, 1997
The number of bits for the state-number field should be set large
enough to represent the maximum number of state changes which can
have taken effect during a round trip time. As an alternative, an
additional exchange can occur. After the destination receives a
packet with state number greater than N, it destroys the state
related to N, and sends back, reliably, a "free-state N" message,
indicating to the destination that state N is now de-allocated,
and can be used again. Until such a message is received, the
source cannot reuse state N. This is essentially a window based
flow control, where the flow is equal to changes in state. With
this addition, the number of bits for the state number can be
safely reduced, and it is guaranteed that the destination will
never confuse the state, independent of the number of state-number
bits used. However, the use of too few state bits can cause call
blocking or delay the teardown of inactive channels.
This problem in state difference appears to be similar to the
channel ID reuse problem described in Section 4.4.2. However,
there is an important difference. In the channel ID reuse problem,
if the packet containing the last block of a user arrives before
the signaling message tearing down that connection, there is no
problem. The destination will generally play out silence until the
signaling message is received. Here, however, the destination must
know that blocks are no longer present in the data stream
independent of when the signaling messages arrive.
There are some drawbacks to this approach. They require the source
and destination to maintain state. Any error in processing at
either end, or a hardware failure, causes a complete loss of
synchronization. This "hard-state" nature of the protocol can be
relaxed by having the source send the complete state of the system
with each signaling message, along with the "state-number" field
for which this state takes effect. This guarantees that even in
the event of end-system failure, the system state will be
refreshed whenever a new connection is set up or torn down.
Furthermore, the state can be sent periodically to improve
performance.
4.5 Length Indicators
There are many ways to actually code the length indicators. The
first question, however, is the range of lengths which must be
coded.
4.5.1 Range of Length Indicators
Here, there is a clear tradeoff between flexibility and
J. Rosenberg, H. Schulzrinne Expires 5/26/97 Pg. 13
INTERNET-DRAFT Nov. 26, 1997
efficiency. A larger range can accommodate a variety of different
media (such as video) where lengths may be large. However, this
comes at the expense of a long length field, which may require
another word of header to hold. For voice, one would expect a
maximum bitrate to be 64 kbps, and around 50ms packetization
delay. This yields exactly 100 words of data. Therefore, an eight
bit field is probably sufficient for most voice applications.
4.5.2 PTI Based Lengths
In many applications, the amount of data present depends on the
voice codec in use. Frame based coders will generally send a frame
at a time. Since the codec type is indicated by the PTI field, it
may not always be necessary to send length information at all.
Even for non-frame based codecs, such as PCM, default data sizes
can be set in the standard (as in RFC 1890 [4]). An extension bit
can be used to indicate a non-standard length, so that when set, a
length field follows. This allows for efficient coding of the most
common cases, but allows for variable lengths with little
additional cost.
4.5.3 Variable Length w/ Indicator
In this approach, a variable length header is used. All of the
length indicators for all of the blocks are placed together in the
beginning of the packet. However, the first four bits of this
header field indicate the number of bits used for each length
field. What follows are the length fields themselves, each using
the number of bits indicated by the first four bits. This approach
scales well, using a small overhead when the block lengths are
small, and a larger overhead when they are larger. The drawback is
a variable length header field, plus additional complexity in the
parsing. An example of this technique is depicted in Figure 4. In
the first example, the four bit indicator field has a value of
three, so that the length fields are all three bits long. The four
lengths are then 2,6,3, and 8. In the second example, the 4 bit
indicator has a value of two, so that the length fields are all
two bits long. The four lengths are thus 3,2,1, and 3.
Example A: 0011 010 110 011 100
Example B: 0010 11 10 01 11
Figure 4: Variable Length w/ Indicator
4.5.4 Remaining Packet Length Based Lengths
UDP always informs RTP of how many bytes are in the payload. This
itself restricts the possible length of the first block, since its
length must be less than the total packet length minus the RTP
header. Furthermore, as each block is placed into the packet, the
possible set of lengths that it can have shrinks - it must always
be less than the remaining length in the packet. This approach,
therefore, codes each length field with log2 of the number of bits
J. Rosenberg, H. Schulzrinne Expires 5/26/97 Pg. 14
INTERNET-DRAFT Nov. 26, 1997
remaining in the packet. This approach works extremely well when
there is a long packet followed by several shorter ones, whereas
the previous approach performs poorly in this case. Furthermore,
it eliminates the length indicator present in the previous
approach. However, it is even more complex than the previous
technique. It can result in no savings under some conditions,
especially since the header fields must be rounded to 32 bits.
Consider an example. The total size of the packet is 31 words.
Inside of it are three blocks, the first whose length is 17, the
second 8, and the third, 6. We would code the length field with 5
bits. After this block is read, the remaining amount of data in
the packet is 14 words. Therefore, the next length field is coded
with 4 bits. After this block, the remaining amount of data in the
packet is 6 words, so the final length field is coded with three
bits. The total is therefore 5+4+3 = 12 bits. In the previous
approach (Section 4.5.3), the entire length field would have
required 4 bits for the indicator (whose value would be 5),
followed by 3 five bit fields, for a total of 19 bits.
One may question this example since the overhead of the length
fields itself is not taken into account when computing the
remaining length of the packet. While this can be incorporated, it
makes things even more complex, and it is not actually necessary.
All that is required is that the length fields are coded with
log2(M), where M is any bound on the remaining amount of data
which can be deterministically computed from past information. A
simple bound is the packet length minus the data seen thus far
(one can also subtract away any fixed length fields), precisely
the metric used in the example above.
4.5.5 Table Based Approach
Realistically, most systems will operate with codecs that generate
data in a fixed set of lengths (a frame size, for example). In
that case, the set of lengths which can appear in the packet are
usually very restricted. To take advantage of this fact, a table
can be transmitted to the receiver reliably before transmission
commences. This table can indicate the actual length of a block,
and its coding. The symbols transmitted in the data packets are
then used in this table to look up the actual lengths. This can
reduce the length field to 2 or 3 bits. These lengths then all
occur next to each other in the header. The technique now relies
on state at the receiver, and the parsing process is further
complicated by table lookups. In addition, the approach only works
if you know the set of lengths before the system begins operation.
If you allow the table to be dynamically modified during a
session, synchronization problems occur, and the system becomes
quite complex.
Further gains can be achieved through the use of Huffman codes
instead of fixed length codes This only makes sense when different
J. Rosenberg, H. Schulzrinne Expires 5/26/97 Pg. 15
INTERNET-DRAFT Nov. 26, 1997
codecs (and correspondingly different lengths) are used with
different frequencies. An example of such a situation is when the
codec changes to a higher rate because of music-on-hold; a rare
event in general.
4.6 Marker Bit
The marker bit has a general functionality, but is normally used
to indicate the beginning of a talkspurt. It seems like a good
idea to include this bit for each user.
4.7 Location of Per User Overhead
There will generally be overhead on a per-user basis (information
such as channel ID, length, etc.). This information can be located
in one of three places. First, it can all reside in front of the
block to which it is applicable. Second, it can all be pasted
together and reside up front in the header of the packet. The
third is a hybrid solution, where some of it resides up front
(such as channel ID), and some resides in front of the data. There
are various pros and cons to the different approaches. The hybrid
approach can be complex, since data is split into multiple places.
The case where all the header is up front has a few minor
advantages. First, it allows for a complete separation of the data
from the header. The implementation is likely to be a little less
complex, since extracting blocks does not require actually moving
through the payload.
5. Options
5.1 Option I: Mixer Based
This option is the most straightforward to implement, but has the
most overhead. The basic premise is to reuse the mixer concept
introduced in RTP. Each user is considered a contributing source,
and the gateway is considered a mixer. However, instead of mixing
the media, separate data from each user appear in the payload. The
32 bit CSRC identifies each user, acting as the channel ID. Data
from each user is organized into blocks. Each block has its own 32
bit header, which includes the length (12 bits) in units of 32 bit
words, Marker bit (1b), TimeStamp Offset (12b), and Payload Type
(7b). Furthermore, the payload type and marker bit are stricken
from the RTP header (since they only make sense for an individual
user), and the CC field expanded to fill the missing bytes. This
allows for a 12 bit CC field, or 4096 users in a packet. Thus,
the packet would look like:
Figure 5: Option I
J. Rosenberg, H. Schulzrinne Expires 5/26/97 Pg. 16
INTERNET-DRAFT Nov. 26, 1997
This approach allows for the most amount of generality in terms of
variable length coders and coders with different frame sizes (see
Section 4.3.1). The channel ID is longer than necessary, but using
the concept of a contributing source for the channel ID
necessitates the use of the additional bits. There are several
variations on option I, many of which have been mentioned above:
I.A: Put the CSRC with each 32 bit length+M+PT field, instead of
all of them being at the beginning. This has some pros and cons.
As an interesting artifact of this change, it is no longer
necessary to have a CC field. The length passed up by UDP is
sufficient to recover the point at where you stop checking for
additional blocks from users in the payload. In fact, the length
field in the last block is not strictly necessary either.
I.B: Do the opposite of I.A. Put the length+M+PT field up front
along with the CSRC fields, with the pattern being CSRC 1, length
1, CSRC 2, length 2, etc. Here again, the CC field is not strictly
necessary.
I.C: The CSRC field can be shrunk to 8 bits. This allows for
either 4 or two channel ID's to be coded in the space of one word,
whereas only one could in the current size of the field.
I.D: The CSRC field can be shrunk to 16 bits.
5.2 Option II: One word header
This option eliminates the large channel ID field present in the
previous option. In the RTP header, the CC bit is set to zero, the
marker bit has no meaning, and the payload type is TBD (possible
uses include an indication of the number of blocks in the packet).
The RTP timestamp corresponds to the generation of the first
sample, among all blocks, enclosed in this packet. A one word
header precedes each block of data. The number of blocks is known
by parsing them until the end of the RTP packet. The one word
field has a channel ID (8 bits), length (8 bits), Marker (1 bit),
timestamp offset (11 bits), and payload type (4 bits). Channel ID
number 255 is reserved, and causes the header to be expanded to
allow for greater length, payload type, and possibly channel ID
encodings. The specific format for this expanded header is for
further study. Given the compacted payload type space, it may be a
good idea to allow negotiation of the meaning for the payload type
at the beginning of the connection. It may be worthwhile to expand
the length field at the expense of the channel ID - this issue is
for further study.
The format of the packet is thus:
Figure 6: Option II
J. Rosenberg, H. Schulzrinne Expires 5/26/97 Pg. 17
INTERNET-DRAFT Nov. 26, 1997
5.3 Option III - Restricted Case
Option II has the advantage of being able to support multiple
frame sizes within a single packet. However, it comes at the
expense of a 32 bit header (which can be large for low bitrate
codecs), and at a reduced payload type field. This option has a 16
bit header, but does not support different frame sizes within a
packet. It therefore falls into the category described in Section
4.3.2. Of the 16 bit header, the first bit is an expand bit (to be
described shortly), and the second bit is the marker bit. The
following 6 bits indicate payload type, and the remaining 8 are
for channel ID. When the expand bit is set, an additional 16 bits
are present, which indicate the length of the block. When expand
is clear, the length is derived from the payload type. Since there
is no timestamp offset, all the blocks in the packet must be time
aligned and have the same frame lengths. Different sized frames
are supported by using a different SSRC for each frame length (see
Section 4.3.2). In the RTP header, the CC field is always zero.
The marker bits and payload type are undefined. The timestamp
indicates the time of generation of the first sample of each
block. SSRC is randomly chosen, but always different for each
frame size.
The block headers are all located at the beginning of the packet,
and follow each other. If the total length of the fields is not a
multiple of 32 bits, it is padded out to 32. The structure of the
header is such that fields never break across packet boundaries.
An example of such a packet is given in Figure 7. There are 7
blocks in this example. The first two have standard lengths based
on the PT field. The next one uses the expansion bit to indicate
the length. The fourth uses the PT field, the fifth the expansion
bit, and the last two use the PT field. The last 16 bits of the
header are padded out.
Figure 7: Option III
5.4 Option IV - Stacked RTP
This approach uses a duplicate of the RTP header as the per-block
header. It is therefore extremely inefficient (12 bytes per
block), but has several advantages: different media types can be
mixed, since the timestamps are no longer related, and little
processing is required if the sources being combined came from a
single user RTP source. It also works well when one of the users
is actually a mixer (for example, a conference bridge), since the
CSRC can be used. Its main advantage is the reduction in overhead
due to the IP and UDP headers. In addition to the standard RTP
header, an additional header is required for length indication.
This header has a number of 16 bit fields, each of which indicates
a length for its corresponding block (including the 12 byte RTP
header). The number of such 16 bit lengths fields is known by
continuing to look for additional length fields until the total
length of the packet passed up from UDP has been accounted for. If
an odd number of such length fields is required, then an
additional 16 bits of padding is inserted to make the length
J. Rosenberg, H. Schulzrinne Expires 5/26/97 Pg. 18
INTERNET-DRAFT Nov. 26, 1997
header a multiple of 32 bits.
The format of such a packet is given in Figure 8.
Figure 8: Option IV
5.5 Option V: Compacted
This option uses the Implicit + Mask approach outlined in Section
4.4.3.2 to code the channel ID. In all other respects it is
similar to Option III. Now, however, the per-block header can be
reduced to one byte: 1 bit of expansion, 1 bit of marker, and 6
bits of payload type. Furthermore, the length field (present when
the expansion bit is set) is reduced to 8 bits from 16 in Option
III. This reduction saves on space, but it also guarantees that
fields remain aligned on byte boundaries. The mask bits are
present in the beginning of the packet, and they are preceded by a
8 bit state-number. If the number of active channels is not a
multiple of 32, the mask field is padded out to a full word. This
approach is extremely efficient, but the channel identification
procedure is more complex and requires additional signaling
support.
A diagram of a typical packet for this option is given in Figure
9. The marker bits are indicated with lowercase m's. There are
four active channels, each of which is present in this packet (all
four mask bits would then be 1). The first block has a standard
length, but the second has its expansion bit set, so that an 8 bit
length field follows. The remaining two blocks have normal 8 bit
headers. The last 24 bits of the header are padded to a word
boundary.
Figure 9: Option V
6. Comparison of Options
In this section, the options are compared in terms of efficiency.
Issues relating to complexity, scalability, and generality have
already been discussed in previous sections. The analysis here
consists of two parts. The first is a table, indicating the
efficiency of each option for a variety of speech codecs. Several
tables are included for different numbers of users. The second
analysis consists of a series of graphs which consider the
efficiency vs. bitrate, assuming a fixed frame size and a certain
number of users. This analysis helps to indicate the range of
codecs which may be reasonably supported with each option.
6.1 Specific Codecs
In both Table 1 and Table 2, the efficiency vs. codec for all
three options is tabulated. For G.711, G.726, G.728 and G.722, the
frame size listed is a multiple of the actual frame size of the
codec, which is too small to be sent one at a time. The efficiency
is computed as the number of words of payload such a codec would
J. Rosenberg, H. Schulzrinne Expires 5/26/97 Pg. 19
INTERNET-DRAFT Nov. 26, 1997
occupy, times the number of users, divided by the total packet
size (i.e., it does not consider inefficiencies due to padding the
payload portion). Note that Option V is always superior in
efficiency. The efficiencies are generally 1 to 10 percent apart.
Table 1 considers the case where there are 10 users, and Table 2
considers the case where there are 24.
Codec Bitrate FrameSize Opti Optio Optio Optio Optio Optio Optio
(kbps) (ms) on n I.C n I.D n II n III n IV n V
I
G.711 64 20 93.0 94.56 94.12 95.24 96.39 90.50 96.84
2% % % % % % %
G.726, 32 20 86.9 89.69 88.89 90.91 93.02 82.64 93.88
6% % % % % % %
G.728, 16 18.75 76.9 81.30 80.00 83.33 86.96 70.42 88.47
2% % % % % % %
G.729 8 10 50.0 56.60 54.55 60.00 66.67 41.67 69.72
0% % % % % % %
G.723 5.3 30 62.5 68.49 66.67 71.43 76.92 54.35 79.33
0% % % % % % %
G.723 6.3 30 66.6 72.29 70.59 75.00 80.00 58.82 82.16
7% % % % % % %
ITU 4kbps 4 20 50.0 56.60 54.55 60.00 66.67 41.67 69.72
0% % % % % % %
G.722 64 15 90.9 92.88 92.31 93.75 95.24 87.72 95.84
1% % % % % % %
GSM Full 13 20 75.0 79.65 78.26 81.82 85.71 68.18 87.35
Rate 0% % % % % % %
TCH Half 5.6 20 57.1 63.49 61.54 66.67 72.73 48.78 75.43
Rate 4% % % % % % %
IS54 7.95 20 62.5 68.49 66.67 71.43 76.92 54.35 79.33
0% % % % % % %
IS96 8.5 20 66.6 72.29 70.59 75.00 80.00 58.82 82.16
7% % % % % % %
EVRC 8.5 20 66.6 72.29 70.59 75.00 80.00 58.82 82.16
7% % % % % % %
PDC Full 6.7 20 62.5 68.49 66.67 71.43 76.92 54.35 79.33
Rate 0% % % % % % %
PDC Half 3.45 40 62.5 68.49 66.67 71.43 76.92 54.35 79.33
Rate 0% % % % % % %
Table 1: 10 Users
J. Rosenberg, H. Schulzrinne Expires 5/26/97 Pg. 20
INTERNET-DRAFT Nov. 26, 1997
Codec Bitrat FrameSize Optio Optio Optio Optio Optio Optio Optio
e (ms) n I n I.C n I.D n II n III n IV n V
(kbps)
G.711 64 20 94.30 96.00 95.43 96.58 97.76 91.34 98.26
% % % % % % %
G.726 32 20 89.22 92.31 91.25 93.39 95.62 84.06 96.57
% % % % % % %
G.728 16 18.75 80.54 85.71 83.92 87.59 91.60 72.51 93.37
% % % % % % %
G.729 8 10 55.38 64.29 61.02 67.92 76.60 44.17 80.87
% % % % % % %
G.723 5.3 30 67.42 75.00 72.29 77.92 84.51 56.87 87.57
% % % % % % %
G.723 6.3 30 71.29 78.26 75.79 80.90 86.75 61.28 89.42
% % % % % % %
ITU 4kbps 4 20 55.38 64.29 61.02 67.92 76.60 44.17 80.87
% % % % % % %
G.722 64 15 92.54 94.74 93.99 95.49 97.04 88.78 97.69
% % % % % % %
GSM Full 13 20 78.83 84.38 82.44 86.40 90.76 70.36 92.69
Rate % % % % % % %
TCH Half 5.6 20 62.34 70.59 67.61 73.85 81.36 51.34 84.93
Rate % % % % % % %
IS54 7.95 20 67.42 75.00 72.29 77.92 84.51 56.87 87.57
% % % % % % %
IS96 8.5 20 71.29 78.26 75.79 80.90 86.75 61.28 89.42
% % % % % % %
EVRC 8.5 20 71.29 78.26 75.79 80.90 86.75 61.28 89.42
% % % % % % %
PDC Full 6.7 20 67.42 75.00 72.29 77.92 84.51 56.87 87.57
Rate % % % % % % %
PDC Half 3.45 40 67.42 75.00 72.29 77.92 84.51 56.87 87.57
Rate % % % % % % %
Table 2: 24 Users
6.2 Efficiency vs. Bitrate
The following figure considers the efficiency of the protocol vs.
bitrate. For this case, the frame size is fixed at 20ms, and the
number of users at 24. As the bitrate varies, the block size
varies, and therefore the efficiency does as well. The efficiency
here is computed in a slightly different manner than the graph
above. Here, the efficiency is the bitrate times the frame size
(without padding to 32 bits), divided by the same quantity plus
the packet and block overhead. This avoids the otherwise sawtooth
behavior of the graph, which makes it very difficult to read.
The graph is very illustrative. The ordering of the efficiencies
is no surprise; option V is always superior. However, the
difference between the options is interesting. Despite the
difference in overhead by a factor of two, Option V and Option III
are very close in efficiencies over a wide range of bitrates. This
is due to the fact that it requires a lot of users at low bitrates
to overcome the IP/UDP/RTP header overhead, and at higher
bitrates, the payload sizes are large enough to make the
difference in block headers inconsequential.
J. Rosenberg, H. Schulzrinne Expires 5/26/97 Pg. 21
INTERNET-DRAFT Nov. 26, 1997
7. References
_______________________________
[1] R. Ramjee, J. Kurose, D. Towsley, H. Schulzrinne, "Adaptive
Playout Mechanisms for Packetized Audio Applications in Wide Area
Networks", Proceedings of IEEE Infocom, 1994
[2] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, "RTP: A
Transport Protocol for Real-Time Applications", Audio Visual
Working Group Request for Comments RFC 1889, IETF, January 1996
[3] M. Handley, V. Hardman, I. Kouvelas, C. Perkins, J. Bolot, A.
Vega-Garcia, S. Fosse-Parisis, "Payload Format Issues for
Redundant Encodings in RTP", Work In Progress
[4] H. Schulzrinne, "RTP Profile for Audio and Video Conferences
with Minimal Control", Audio Visual Working Group Request for
Comments RFC 1890, IETF, January 1996
