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

Versions: 00 01                                                         
INTERNET DRAFT                                            Keiko Tanigawa
draft-tanigawa-rtp-multiplex-00.txt                          Tohru Hoshi
                                                            Koji Tsukada

                                                           Hitachi, Ltd.
June 16, 1998
Expires: December 16, 1998

              An RTP Simple Multiplexing Transfer Method
                    for Internet Telephony Gateway


   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).


This document discusses the RTP multiplexing format which is designed
to reduce the IP-UDP header overhead of the RTP streams with a
decreased number of packets in end-to-end transport functions.  By
augmenting the RTP format and defining a format for multiplexing
streams, the overhead for duplicated IP/UDP headers is reduced.

1. Introduction

Since real-time transport protocol, which transmits and receives
multi-media data, such as audio and video over IP networks was defined
as RFC 1889[1] and RFC1890[2], the conformance between
conference/conversation multi-media communication applications has
become guaranteed.  Prior to that time, it was difficult or impossible
because of individual formats.  As RTP is integrated into the H.323
protocol stack which was standardized by the ITU-T, Internet Telephony
Gateways and gateways that enable communication between RTP supported
Internet Telephony client software and telephones, or between two
telephones, is increasing.

One problem concerning the voice packet is that IP/UDP/RTP header is
larger than the voice data itself when being sent on IP networks.
Various high compression methods have been developed for digitizing
voice data.  For example, with the G.723.1 (5.3kbps) the frame size
becomes 20B (30ms), half the size of the 40B header, IPv4 (20B) + UDP
(8B) + RTP fixed header (12B) = 40B.  The IPv6 header is even larger
and the overhead occupied in the RTP voice packet places an even
greater burden on the network.

In case of Internet Telephony Gateways, where more than one RTP stream
occurs between gateways, the bandwidth that the header occupies must
be taken into consideration.  Also, the traffic load on the router
increases due to the flow of many short packets of under a hundred
bytes.  This causes the delay, jitter and the packet loss, which
contributes to the overall degradation of the quality that real-time
communication demands.

This document defines the RTP multiplexing method for Internet
Telephony Gateways communicating between two telephones, where more
than one RTP stream occurs between gateways.

Also defined is the RTP stream multiplexing format which is the
extended RTP format.

2. Multiplexing RTP Voice Streams

There are two types of Internet Telephony Gateways presently being
developed; (1) Internet Telephony client-to-telephone, and (2)
telephone-to-telephone.  This document focuses on the latter type, the
unicast type telephone-to-telephone gateway.

RTP explained in RFC 1889 is a protocol for transmitting real-time
multi-media data over multicast or unicast networks.  Basically there
is a separate session for each stream.  For example in the transfer of
video data, an audio stream and a video stream attaches a separate
session and the identification code for each can be set individually.

Like Internet Telephony Gateways, when more than one RTP stream occurs
between gateways, each RTP data stream shares the same IP address and
the IP address size (20B) does not differ from the size of the voice
data.  When 8 voice streams (coding format G.723.1) are being
transferred between Internet Telephony Gateways, each RTP voice stream
bandwidth is:

20 (IP) + 8 (UDP) + 12 (RTP-Fixed Header) + 20 (G.723.1) = 60B
60 * 33 (packets/sec) * 8 = 15.8 (kbps)

The bandwidth utilized by the above 8 RTP voice streams:

15.8 (kbps) * 8 = 126.7 (kbps)

The percentage occupied by the shared IP address data within the 8
streams is:

20 (B) * 33 (packet/sec) * 8 (streams) * 8 (bits) = 42.2 (kbps).

This is equal to a little less than the bandwidth of 3 RTP voice

The above characteristics make it possible to eliminate redundant data
and reduce the necessary bandwidth through multiplexing streams into
one IP packet when there is more than one sharing the same
destination, or that is, having the same IP address at one gateways.
In addition traffic load of the router is lessened because the number
of packets is reduce to one-eighth of the original amount.  At the
same time, it is possible to set the ID, UDP port for each stream
according to the RTP, and RTCP sender reports and receiver reports are
transmitted for each stream.

3. Simple Voice Stream Multiplexing Packet Format

The format for each stream is that standard RTP format described in
[1]. The multiplex stream is formed only by linking a series of RTP

0   2 3 4     7 8            15                              31
|                           RTP Data 1                        |
|                          .............                      |
|                           RTP Data 2                        |
|                          .............                      |
|                          .............                      |
|                           RTP Data n                        |
|                          .............                      |

                 Figure 1. Multiplexing Format

Tanking into consideration the integration of, and borrowing from,
existing RTP standards, this method is preferable.

If the GWs negotiate for multiplexing at the call control, the
decision as to whether or not the stream data shall continue more in
the packet can be made by considering the size of the receiving packet
and each stream's payload-type.  There are some advantages, for
example, there is no redundant data added for multiplexing and it is
easy to implement.

Figure 2 indicates the type of CODEC and the effect of multiplexing
when using bandwidth for multiplexing 8 streams. (The bandwidth when
sending 8 streams separately = 100% )

|  CODEC  |  G.711  | G.723.1 |  G.729  |   GSM   |
| Rate(%) |   96.9  |  68.75  |   66.4  |   73.1  |

                     Figure 2

4. Port assignment for Multiplexing

The UDP port that transports the RTP data is set separately for each
RTP session.  Unlike transmitting video data, in the Internet
Telephony Gateways one transmission does not include multi-media
sessions such as video and voice (data).  Each RTP session is separate
and not related, which makes it impossible to have a fixed setting in
one of the related sessions.  Indicated below is the method for
determining the UDP port on which the multiplex stream is transported
when multiplexing RTP voice streams.  Basically one of the RTP
sessions having the same gateway destination is used and a multiplex
packet is created and transferred.

o The sending and receiving buffer of each RTP session is reserved,
and a multiplex packet is created and transmitted at a set timing.
For example voice transmissions are set at a default value of 20ms
intervals (except G.723.1).

o When data is transmitted in a RTP session at RTP timing, after
checking whether or not the transmitted data of another session has
the same terminal destination IP address, the message is distributed
to the transmission destination.

o In cases when there are already other sessions with the same
transmit terminal destination, the RTP data is queued in the transmit
buffer of one of the RTP sessions.

o When there is already some RTP data queued in the transmit buffer of
a session, the new data is linked in the same transmit buffer.

o When the data of each session has been distributed, transmission
processing begins. When there is some RTP data linked, the data is put
into an IP packet.

For example when 5 RTP voice streams(1-5) are transferred between
Internet Telephony Gateways, multiplex packets are sent using one of
the UDP ports designated for the streams(1-5).  Each time a
stream(1-5) is transmitted, it is possible to change the UDP port that
is used.  Actual implementation is beyond the scope of this document.

5. Negotiation

GWs must determine, during the call control, whether the destination
GW and/or H.323 terminal has a multiplexing function. Additionally,
when multiple streams are multiplexed into one RTP packet, GWs can not
distinguish between streams by the receiving port number. Therefore,
GWs need to communicate that stream identifications with one another.
The ID value is set SSRC which is defined in RTP to prevent having to
manage multiple IDs.  Negotiation and such topics are also beyond the
scope of this document.

6. Open Issues

There are some issues;

(1) How the negotiation for multiplexing and communication of stream's
ID (SSRC) are processed in H.323?

(2) How about the multimedia streams whose lengths are variable?
Shall each RTP stream's RTP fixed header be extended having a length

7. Conclusion

A voice streams multiplexing format for IP Telephony Gateways was
proposed.  This format is very simple, and the implementation is very

8. References

[1] H. Schulzrinne, et. al., "RTP : A Transport Protocol for Real-Time
Applications", IETF RFC 1889, January 1996.

[2] H. Schulzrinne, et. al., "RTP Profile for Audio and Video
Conference with Minimal Control", IETF RFC 1890, January 1996.

9.  Author's Addresses

    Keiko Tanigawa
    Systems Development Laboratory
    Hitachi, Ltd.
    292 Yoshida-cho, Totsuka-ku, Yokohama, 244-0817, JAPAN
    Phone: +81-45-881-1241
    Fax: +81-45-860-1675
    Email: takahara@sdl.hitachi.co.jp

    Tohru Hoshi
    Email: hoshi@sdl.hitachi.co.jp

    Koji Tsukada
    EMail: ktsukada@sdl.hitachi.co.jp