One document matched: draft-tanigawa-rtp-multiplex-01.txt
Differences from draft-tanigawa-rtp-multiplex-00.txt
INTERNET DRAFT Keiko Tanigawa
draft-tanigawa-rtp-multiplex-01.txt Tohru Hoshi
Koji Tsukada
Hitachi, Ltd.
November 18, 1998
Expires: May 18, 1999
Simple RTP Multiplexing Transfer Methods for VoIP
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 made obsolete 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), ftp.isi.edu (US East Coast),
or ftp.isi.edu (US West Coast).
Abstract
This document proposes a simple voice stream multiplexing method which is
designed to reduce the IP-UDP header overhead of RTP (real-time transport
protocol) streams and to decrease the number of packets in the end-to-end
transport functions. The proposed multiplexing method is to concatenate
RTP packets destined for the same Internet Telephony Gateway (IP-GW) into
a single UDP packet. The benefits of this method are that no new
additional headers are required and the current well-defined H.323 and
RTP standards can be used.
Furthermore, this method is a general RTP packet multiplexing method that
is applicable not only to an IP-GW but also to other multiplexing
applications, as well as trunking VoIP streams application with insertion
and deletion of RTP streams on the way.
1. Introduction
Header overhead is a key issue in Internet protocol (IP) telephony.
That is, RTP, UDP and IP headers (a total of 40 bytes) are attached to
voice information. High-compression low-bit-rate codec systems are now
being used for voice digitization and compressed data is being reduced
in size. For example, G.723.1 compresses voice data to 5.3 kbps. Voice
data is packetized every 30 ms and the size of the payload is 20 bytes.
That is, only one-third of all the data is payload and the other
two-thirds is overhead, so the current transfer method for VoIP is still
very inefficient. Table 1 shows the relationship between codec types,
coding speeds, header sizes, and payloads.
Table 1 Coding speeds, payload sizes, header overhead, and number of packets
+---------------------------------------------------------------------------+
| Codec | G.711 | G.723.1 | G.726-32 | G.729 | GSM |
-----------------------------------------------------------------------------
| Coding speed (kbps) | 64 |5.3 / 6.3| 32 | 8 | 13.2 |
-----------------------------------------------------------------------------
| Framing interval (ms) | 20* | 30 | 20* | 10 | 20 |
-----------------------------------------------------------------------------
| Header (IP+UDP+RTP) | 40 | 40 | 40 | 40 | 40 |
-----------------------------------------------------------------------------
| Payload (Bytes) | 160 | 20 / 24 | 80 | 20** | 33 |
-----------------------------------------------------------------------------
| Header Overhead( % ) | 20 | 67 / 63 | 33 | 67 | 52 |
-----------------------------------------------------------------------------
|Packets in a stream/sec | 50* | 33 | 50* | 50* | 50 |
+---------------------------------------------------------------------------+
*: packetizing interval is assumed to be 20 ms.
**: 2 frames
Regarding IP-GWs, multiple voice streams are connected between a pair of GWs.
This characteristic can be used to decrease the header overhead and reduce
the number of packets flowing into the Internet. That is, when a number of
VoIP streams exist between two IP-GWs these voice packets can be multiplexed.
This mechanism greatly improves channel efficiency.
But at present, there is still no standard available for multiplexing voice
streams between IP-GWs, even though IP telephony protocols such as H.323[1]
or RTP[2] are standardized.
2. Proposed voice stream multiplexing method
2.1 Overview
The objective of this proposal is to provide a simple and flexible
multiplexing solution between IP-GWs. The basic idea of the proposed
multiplexing method is to concatenate RTP voice packets, and encapsulate them
in a UDP packet. Negotiation about whether a call is multiplexed or
non-multiplexed between IP-GWs is done by call control sequence. There is
no special UDP port assigned for multiplexing. The multiplexing mechanism
is placed between the RTP and UDP layers, and is not in the RTP layer itself.
Figure 1 shows the layers for multiplexing.
+----------------------------+
| RTP |
+---------------+ |
+-------------+ | |
| MUX | | |
+-------------+ +------------+
+----------------------------+
| UDP |
+----------------------------+
+----------------------------+
| IP |
+----------------------------+
Figure 1 Multiplexing layer
2.2 Multiplexing packet format
The packet format of multiplexing is shown in Figure 2. A multiplexed voice
packet is composed by concatenating RTP encapsulated voice packets and IP
and UDP headers. There is no additional header for multiplexing. Each RTP
encapsulated voice packet format is defined in RFC1889.
+-------------------------------------------------------------+
| IP |
| |
+-------------------------------------------------------------+
| UDP |
+-------------------------------------------------------------+
| RTP header - stream 1 |
+-------------------------------------------------------------+
| Payload - stream 1 |
| |
+-------------------------------------------------------------+
| RTP header - stream 2 |
+-------------------------------------------------------------+
| Payload - stream 2 |
| |
+-------------------------------------------------------------+
| |
| ................... |
+-------------------------------------------------------------+
| RTP header - stream n |
+-------------------------------------------------------------+
| Payload - stream n |
| |
+-------------------------------------------------------------+
Figure 2 Multiplexing format
RFC1889 defines the default packetizing interval to be 20 ms for frame-type
codecs with a framing interval of 20 ms or less. When the framing interval
exceeds 20 ms, the packetizing interval shall be the framing interval. For
example, in G.723.1, the framing interval is 30 ms, so 30 ms shall be the
packetizing interval. For G.729 codecs, the framing interval is 10 ms, so
an RTP packet has two frames. For non-frame-type codecs, such as G.711 or
G.726, the packetizing interval is 20 ms according to this rule. Table 2
shows the framing interval and packetizing interval of codecs.
Table 2 Framing interval and Packetizing interval (RFC1889)
+--------------------------------------------------------------------------+
| CODEC | G.711 | G.723.1 |G.726-32| G.729 | GSM |
+--------------------------------------------------------------------------+
| Framing interval (ms) | ---- | 30 | ---- | 10 | 20 |
+--------------------------------------------------------------------------+
| Packetizing interval(ms) | 20 | 30 | 20 | 20 | 20 |
+--------------------------------------------------------------------------+
Figure 3 shows the multiplexing voice stream mechanism. In this example,
three voice streams to the IP-GW composed of RTP packets are multiplexed.
Each stream is sampled at a multiplexing interval, and sampled RTP packets
are concatenated into a multiplexed packet, which is sent to the destination
IP-GW by adding UDP and IP headers. The length of the packet varies
depending depend on the numbers of RTP packets concatenated and the order of
the RTP packets in each multiplexed packet is flexible.
| | | | |
| | | | |
+--|---+--|---+--|---+--|---+ |
RTP voice stream #1 | 1-4 | 1-3 | 1-2 | 1-1 | |
----+--|---+--|---+--|---+--|---+--|---->
| | | | |
| | +---|--+---|--+ |
RTP voice stream #2 | | | 2-2 | 2-1 | |
------|------|--+---|--+---|--+---|---->
| | | | |
+----|-+----|-+----|-+----|-+----|-+
RTP voice stream #3 | 3-5| | 3-4| | 3-3| | 3-2| | 3-1| |
-+----|-+----|-+----|-+----|-+----|-+-->
|<====>|<====>|<====>|<====>|
Multiplexing interval
|
|
V
+---+---+----+ +---+---+---+----+ +---+---+---+----+ +---+----+
|3-4|1-3| H | |3-3|2-2|1-2| H | |3-2|2-1|1-1| H | |3-1| H |
-+---+---+----+--+---+---+---+----+--+---+---+---+----+--+---+----+->
Figure 3 Multiplexed voice stream configuration
2.3 Port assignment
No special UDP port for multiplexing is assigned. The multiplexed stream
uses one of the UDP ports already assigned to non-multiplexed voice
streams to the same destination IP-GW. The port is dynamically assigned
on a packet-by-packet basis. Figure 4 shows an example.
In an RTP multiplexing module, when a multiplexing period comes, the source
IP-GW has three packets which should be sent. Stream-1 whose UDP port
number is 5000 has packet 1-1 destined for GW-10, stream-2 whose UDP port
number is 5020 has packet 2-1 for GW-10, and stream-3 whose UDP port number
is 5040 has packet 3-1 for GW-20. At first, packet 1-1 is queued in the
queue for stream-1. Next, packet 2-1, which belongs to stream-2, is selected.
In this case, packet 2-1 is queued in the queue for stream-1(Queue-1) because
packet 1-1, whose destination is the same as stream-2, already exists.
Then, packet 3-1 is queued into Queue-3. In Queue-1, because there are two
packets, they are multiplexed into one IP packet and this multiplexed packet
is sent to GW-10. Queue-2 does no processing because there are no packets.
In Queue-3, packet 3-1 is packetized into one IP packet and the packet is
sent to GW-20.
RTP Multiplexing UDP/IP
+---------------------------------+ +-----------------------+
| Queue for stream-1( Queue-1 ) | | UDP # 5000,To GW-10 |
To GW-10 | -------+-------------------+--- | |+---------------------+|
UDP # 5000 | | 2-1 | 1-1 | | || 2-1 | 1-1 |UDP||
+----+ ===========> +---------+---------+ | |+--------+--------| / ||
|1-1 | | |==> |data |RTP|data |RTP| | ||data|RTP|data|RTP|IP ||
+----+ | -||----+-------------------+--- | |+---------------------+|
| || | | |
| || Queue-2 | | |
To GW-10 | -||---------------------------- | | |
UDP # 5020 | || | | |
+----+ | || | | |
|2-1 |==========| | | |
+----+ | ------------------------------- | | |
| | | |
| Queue-3 | | UDP # 5040,To GW-20 |
To GW-20 | -----------------+---------+--- | | +------------+ |
UDP # 5040 | | 3-1 | | | | 3-1 |UDP| |
+----+ | +---------+ | | +--------| / | |
|3-1 |======================> |data |RTP| | | |data|RTP|IP | |
+----+ | -----------------+---------+--- | | +------------+ |
| | | |
+---------------------------------+ +-----------------------+
Figure 4 Port assignment
2.4 Stream identification
UDP port numbers used for a multiplexed stream cannot identify the RTP stream
any more because of the dynamic assignment to the stream. The SSRC parameter
of the RTP header is used for the stream identification.
2.5 Negotiation in call control
Negotiation in the H.323 call set-up phase is required in order to determine
whether or not the IP-GW has a voice stream multiplexing function and to
exchange the stream identification.
The H.245 call control sequence should
be modified for the negotiation. Two options are considered below.
2.5.1 Option 1: Add new parameters in H.245 sequence
One option is to add new parameters in the H.245 call set-up sequence by
modifying the "Capability Exchange" and "Logical Channel Open". Figure 6(a)
shows this sequence. The multiplex capability parameter is added to the
H.245 Term Cap exchange sequence and an exchange of SSRC values for stream
identification is added to the H.245 Open Audio Logical Channel sequence.
(1) Capability exchange
After the TCP channel for H.245 is opened, the IP-GWs exchange information
about their capabilities with each other. In this step, the
ipgwMultiplexCapability (BOOLEAN) part is newly added to the h2250Capability
structure of the MultiplexCapability structure of the TerminalCapabilitySet
message in the H.245 structure. (Refer to Figure 5(a) H.245 Term Cap messages.)
(2) Logical channel setting
In the logical channel setting sequence, mediaID (a four-byte integer)
parameter is added to the items of H2250LogicalChannelParameter in the
OpenLogicalChannel message structure. The mediaID represents a stream
identification using the SSRC value of RTP. (Refer to Figure 5(b) H.245 open
audio logical channel message.)
2.5.2 Option 2: Use user data command
The other option is to use the "NonStandardMessage" in the H.245 structure.
After the capability exchange in the H.245 sequence, a "NonStandardMessage"
is used to exchange multiplexing mode negotiation and SSRC values for stream
identifier. Figure 5(b) shows this sequence.
NonStandardMessage Format
+---------------------------------------------------------+
| nonStandardIdentifire | size | SSRC |
+---------------------------------------------------------+
nonStandardIdentifier: refer to H.245
size (8 bits): Data size after "size" field.
0 shows that this cannot be multiplexed.
Values other than 0 (= 4) show multiplexing is possible.
SSRC (32 bits): Stream identifier. Use the value set in the RTP.
H.323 Terminal #2 H.323 GK H.323 Terminal #1
(IP-GW) (IP-GW)
| | H.225: Admission |
| | <-------------------------------->|
| | |
| Q.931 SetUp |
|<-----------------------------------------------------------------|
| H.225: Admission | |
|<---------------------------->| |
| | |
| Q.931 Connect |
|----------------------------------------------------------------->|
| Open TCP Channel for H.245 |
|<-----------------------------------------------------------------|
| H.245 TermCap |
|<================================================================>|
| H.245 open audio logical channel |
|<================================================================>|
| Full Duplex Audio Send in both directions |
|<---------------------------------------------------------------->|
| |
| |
(1) H.245 TermCap:
Add an new parameter, "Multiplexing Capability", to the message's
structure.
(2) H.245 open audio logical channel:
Add an new parameter, "streamID (= SSRC)", to the message's
structure.
Figure 5(a) Add new parameters to H.323 call
H.323 Terminal #2 H.323 GK H.323 Terminal #1
(IP-GW) (IP-GW)
| | H.225: Admission |
| | <-------------------------------->|
| | |
| Q.931 SetUp |
|<-----------------------------------------------------------------|
| H.225: Admission | |
|<---------------------------->| |
| | |
| Q.931 Connect |
|----------------------------------------------------------------->|
| Open TCP Channel for H.245 |
|<-----------------------------------------------------------------|
| H.245 TermCap |
|<---------------------------------------------------------------->|
| H.245 open audio logical channel |
|<---------------------------------------------------------------->|
| H.245 Nonstandard data (Multiplex Cap) |
|<================================================================>|
| |
| Full Duplex Audio Send in both directions |
|<---------------------------------------------------------------->|
| |
| |
Figure 5(b) Use user data command (option 2)
2.6 Summary of proposed voice stream multiplexing
The requirements and specifications of the proposed voice stream
multiplexing are summarized in Table 3.
Table 3 Summary of proposal
+------------------------------------------------------------------------+
| Kind of multiplexing | Multiplex RTP packet |
|------------------------------------+-----------------------------------|
| Number of users in multiplexing | No limitations |
| | (restricted by increased delay |
| | fragmentation in router) |
|------------------------------------+-----------------------------------|
| Negotiation of multiplex mode | Exchange in H.245 |
|------------------------------------+-----------------------------------|
| Voice stream identification | Use SSRC value of RTP in RFC 1889 |
|------------------------------------+-----------------------------------|
| Number of RTP packets in mux-packet| Variable |
|------------------------------------+-----------------------------------|
| Order of RTP packets in mux-packet | Flexible |
|------------------------------------+-----------------------------------|
| UDP port for multiplexed stream | Use one of UDP ports of the same |
| | route |
| | Special UDP port not required |
|------------------------------------+-----------------------------------|
| Additional capabilities | Extendable to generic multiplexing|
| | method for RTP streams other than |
| | IP-GW |
+------------------------------------------------------------------------+
3. Conclusion
A voice stream multiplexing method is proposed. This multiplexing method
is to concatenate RTP packets from the voice streams to the same IP-GW at
a multiplexing period into a single UDP packet. The benefits of this
method are that no additional header is required and it is usable with
current, well-defined, H.323 and RTP standards with minimum changes.
4. References
[1] ITU-T Recommendation H.323: "Packet-based multimedia communications
systems"
[2] IETF RFC1889: "RTP: A Transport Protocol for Real-Time Applications",
H. Schulzrinne et al., January 1996
[3] ITU-T Recommendation Q.931: "Digital Subscriber Signalling System No.1
(Dss 1)-ISDN User-Network Interface Layer 3 Specification for Basic Call
Control"
[4] ITU-T Recommendation H.245: "Control of Communications Between Visual
Telephone Systems and Terminal Equipment"
5. Authors' 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
Appendix: Evaluation and discussion
1. Average number of users in multiplexing
The numbers of packets generated by IP-GW is decreased by multiplexing.
In a pair of IP-GWs with a single link, all the voice streams can be
multiplexed in a single multiplexed channel. In this case, the packet
reduction rate is extremely large and results in one by number of users
in a multiplexed channel. However, in an IP telephony system with a
number of IP-GWs, the packet reduction rate is smaller than in the above
case.
The average numbers of users in multiplexing is discussed in a
typical case. A simplified traffic model is used assuming that there are
N IP-GWs in an IP telephony system and each IP-GW has the same number of
voice streams as other IP-GWs, and that traffic between every pair of
IP-GWs is the same. The average number of users in a multiplexed channel
is shown in Table 4. The number of users in a multiplexed channel between
any particular IP-GWs is 10-20 in a system with fewer than IP-GWs.
However, if the number of IP-GWs exceed 50, the average number of users in
the channel is dramatically decreased.
Therefore, multiplexing is effective when there are some tens or less of
IP-GWs in a system. The more IP-GWs there are, the lower the multiplicity
and the less effective multiplexing is.
Table 4 Average number of users in a multiplexed channel
+---------------------------------------------------+
| N (nodes) | 5 | 10 | 20 | 40 | 50 |
+----------------+------+------+------+------+------+
|number of links | 10 | 45 | 190 | 780 | 1225 |
+===================================================+
| calls / node | 40 |
+----------------+----------------------------------+
| Total calls | 100 | 200 | 400 | 800 | 1000 |
+----------------+------+------+------+------+------+
| ave. mux # | 10 | 4.4 | 2.1 | 1.0 | 0.8 |
+===================================================+
| calls / node | 100 |
+----------------+----------------------------------+
| Total calls | 250 | 500 | 1000 | 2000 | 2500 |
+----------------+------+------+------+------+------+
| ave. mux # | 25 | 11.1 | 5.2 | 2.6 | 2 |
+---------------------------------------------------+
2. Packet reduction
The numbers of packets generated by IP-GW is decreased by multiplexing.
3. Header overhead reduction
Table 5 shows header overhead reduction in terms of the number of users in
multiplexing. When there are 8 users in a multiplexed channel, the
required bandwidth is reduced from 126 kbps to 75 kbps. This value is 40%
of the bandwidth usage.
Table 5 Overhead reduction expressed by required bandwidth
+--------------------------------------------------+
| # of connections | 1 | 2 | 4 | 8 |
+---------+--------+-------+-------+-------+-------+
|Bandwidth|Non-Mux | 15.8 | 31.6 | 63.3 | 126.7 |
|(kbps) +--------+-------+-------+-------+-------+
| | Mux | 15.8 | 24.3 | 41.2 | 75.0 |
+--------------------------------------------------+
4. Additional delay
Additional delays occurs in multiplexing. There are multiplexing
processing delay in IP-GW and store-and-forward delay in the router.
4.1 Multiplexing processing delay
Multiplexing processing delay is caused by the multiplexing interval
timing newly introduced for multiplexing RTP voice streams. Table 6 shows
examples of multiplexing delay. This delay depends on the value of the
multiplexing interval timing, which will be decided by the implementer of
an IP-GW. If the chosen multiplexing interval timing is small, the
additional delay becomes small but the number of users in a multiplexed
channel also becomes small. There is a trade-off between them.
Table 6 Multiplexing delay
+--------------------------------------------------------------------+
| CODEC | Framing |Packetizing|Multiplexing|Multiplexing|#of users|
| | interval | Interval | Interval | Delay |in Mux |
+---------+----------+-----------+------------+------------+---------+
| G.723.1 | 30 ms | 30 ms | 10 ms | 0 - 10 ms | n |
| | | +------------+------------+---------+
| | | | 20 | 0 - 20 | 2n |
+---------+----------+-----------+------------+------------+---------+
| G.729 | 10 | 20 | 10 | 0 - 10 | n |
| | | +------------+------------+---------+
| | | | 20 | 0 - 20 | 2n |
| | | +------------+------------+---------+
| | | | 30 | 0 - 30 | 3n |
+--------------------------------------------------------------------+
4.2 Store-and-forward delay
There is a store-and-forward delay in a router. When the packet length
becomes longer, a larger delay occurs. Table 7 shows the store-and-forward
delay in terms of line transmission speed connected to
a router.
Table 7 Store and forward delay
+-------------------------------------------------------------+
| Line speed (kbps) | 128 | 384 | 768 | 1544 |
+============================+=======+========================+
| Delay | Non-multiplexing | 3.75 | 1.25 | 0.625 | 0.318 |
| (ms) |--------------------+-------+-------+-------+--------+
| | 3 streams-mux | 7.75 | 2.58 | 1.29 | 0.647 |
| |--------------------+-------+-------+-------+--------+
| | 8 streams-mux | 17.75 | 5.91 | 2.95 | 1.479 |
+----------------------------+--------------------------------+
| PAFTECH AB 2003-2026 | 2026-04-23 19:53:01 |