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 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). Abstract 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 streams. 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 streams. 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 field? 7. Conclusion A voice streams multiplexing format for IP Telephony Gateways was proposed. This format is very simple, and the implementation is very easy. 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