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 | +----------------------------+--------------------------------+