[Search] [txt|ps|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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