idnits 2.17.1 draft-tanigawa-rtp-multiplex-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 266 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 16, 1998) is 9446 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1889 (ref. '1') (Obsoleted by RFC 3550) ** Obsolete normative reference: RFC 1890 (ref. '2') (Obsoleted by RFC 3551) Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT Keiko Tanigawa 2 draft-tanigawa-rtp-multiplex-00.txt Tohru Hoshi 3 Koji Tsukada 5 Hitachi, Ltd. 6 June 16, 1998 7 Expires: December 16, 1998 9 An RTP Simple Multiplexing Transfer Method 10 for Internet Telephony Gateway 12 STATUS OF THIS MEMO 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as ``work in progress''. 24 To learn the current status of any Internet-Draft, please check the 25 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 26 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 27 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 28 ftp.isi.edu (US West Coast). 30 Abstract 32 This document discusses the RTP multiplexing format which is designed 33 to reduce the IP-UDP header overhead of the RTP streams with a 34 decreased number of packets in end-to-end transport functions. By 35 augmenting the RTP format and defining a format for multiplexing 36 streams, the overhead for duplicated IP/UDP headers is reduced. 38 1. Introduction 40 Since real-time transport protocol, which transmits and receives 41 multi-media data, such as audio and video over IP networks was defined 42 as RFC 1889[1] and RFC1890[2], the conformance between 43 conference/conversation multi-media communication applications has 44 become guaranteed. Prior to that time, it was difficult or impossible 45 because of individual formats. As RTP is integrated into the H.323 46 protocol stack which was standardized by the ITU-T, Internet Telephony 47 Gateways and gateways that enable communication between RTP supported 48 Internet Telephony client software and telephones, or between two 49 telephones, is increasing. 51 One problem concerning the voice packet is that IP/UDP/RTP header is 52 larger than the voice data itself when being sent on IP networks. 53 Various high compression methods have been developed for digitizing 54 voice data. For example, with the G.723.1 (5.3kbps) the frame size 55 becomes 20B (30ms), half the size of the 40B header, IPv4 (20B) + UDP 56 (8B) + RTP fixed header (12B) = 40B. The IPv6 header is even larger 57 and the overhead occupied in the RTP voice packet places an even 58 greater burden on the network. 60 In case of Internet Telephony Gateways, where more than one RTP stream 61 occurs between gateways, the bandwidth that the header occupies must 62 be taken into consideration. Also, the traffic load on the router 63 increases due to the flow of many short packets of under a hundred 64 bytes. This causes the delay, jitter and the packet loss, which 65 contributes to the overall degradation of the quality that real-time 66 communication demands. 68 This document defines the RTP multiplexing method for Internet 69 Telephony Gateways communicating between two telephones, where more 70 than one RTP stream occurs between gateways. 72 Also defined is the RTP stream multiplexing format which is the 73 extended RTP format. 75 2. Multiplexing RTP Voice Streams 77 There are two types of Internet Telephony Gateways presently being 78 developed; (1) Internet Telephony client-to-telephone, and (2) 79 telephone-to-telephone. This document focuses on the latter type, the 80 unicast type telephone-to-telephone gateway. 82 RTP explained in RFC 1889 is a protocol for transmitting real-time 83 multi-media data over multicast or unicast networks. Basically there 84 is a separate session for each stream. For example in the transfer of 85 video data, an audio stream and a video stream attaches a separate 86 session and the identification code for each can be set individually. 88 Like Internet Telephony Gateways, when more than one RTP stream occurs 89 between gateways, each RTP data stream shares the same IP address and 90 the IP address size (20B) does not differ from the size of the voice 91 data. When 8 voice streams (coding format G.723.1) are being 92 transferred between Internet Telephony Gateways, each RTP voice stream 93 bandwidth is: 95 20 (IP) + 8 (UDP) + 12 (RTP-Fixed Header) + 20 (G.723.1) = 60B 96 60 * 33 (packets/sec) * 8 = 15.8 (kbps) 98 The bandwidth utilized by the above 8 RTP voice streams: 100 15.8 (kbps) * 8 = 126.7 (kbps) 102 The percentage occupied by the shared IP address data within the 8 103 streams is: 105 20 (B) * 33 (packet/sec) * 8 (streams) * 8 (bits) = 42.2 (kbps). 107 This is equal to a little less than the bandwidth of 3 RTP voice 108 streams. 110 The above characteristics make it possible to eliminate redundant data 111 and reduce the necessary bandwidth through multiplexing streams into 112 one IP packet when there is more than one sharing the same 113 destination, or that is, having the same IP address at one gateways. 114 In addition traffic load of the router is lessened because the number 115 of packets is reduce to one-eighth of the original amount. At the 116 same time, it is possible to set the ID, UDP port for each stream 117 according to the RTP, and RTCP sender reports and receiver reports are 118 transmitted for each stream. 120 3. Simple Voice Stream Multiplexing Packet Format 122 The format for each stream is that standard RTP format described in 123 [1]. The multiplex stream is formed only by linking a series of RTP 124 streams. 126 0 2 3 4 7 8 15 31 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 | RTP Data 1 | 129 | ............. | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 | RTP Data 2 | 132 | ............. | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | ............. | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | RTP Data n | 137 | ............. | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 Figure 1. Multiplexing Format 142 Tanking into consideration the integration of, and borrowing from, 143 existing RTP standards, this method is preferable. 145 If the GWs negotiate for multiplexing at the call control, the 146 decision as to whether or not the stream data shall continue more in 147 the packet can be made by considering the size of the receiving packet 148 and each stream's payload-type. There are some advantages, for 149 example, there is no redundant data added for multiplexing and it is 150 easy to implement. 152 Figure 2 indicates the type of CODEC and the effect of multiplexing 153 when using bandwidth for multiplexing 8 streams. (The bandwidth when 154 sending 8 streams separately = 100% ) 156 +---------+---------+---------+---------+---------+ 157 | CODEC | G.711 | G.723.1 | G.729 | GSM | 158 +---------+---------+---------+---------+---------+ 159 | Rate(%) | 96.9 | 68.75 | 66.4 | 73.1 | 160 +---------+---------+---------+---------+---------+ 162 Figure 2 164 4. Port assignment for Multiplexing 166 The UDP port that transports the RTP data is set separately for each 167 RTP session. Unlike transmitting video data, in the Internet 168 Telephony Gateways one transmission does not include multi-media 169 sessions such as video and voice (data). Each RTP session is separate 170 and not related, which makes it impossible to have a fixed setting in 171 one of the related sessions. Indicated below is the method for 172 determining the UDP port on which the multiplex stream is transported 173 when multiplexing RTP voice streams. Basically one of the RTP 174 sessions having the same gateway destination is used and a multiplex 175 packet is created and transferred. 177 o The sending and receiving buffer of each RTP session is reserved, 178 and a multiplex packet is created and transmitted at a set timing. 179 For example voice transmissions are set at a default value of 20ms 180 intervals (except G.723.1). 182 o When data is transmitted in a RTP session at RTP timing, after 183 checking whether or not the transmitted data of another session has 184 the same terminal destination IP address, the message is distributed 185 to the transmission destination. 187 o In cases when there are already other sessions with the same 188 transmit terminal destination, the RTP data is queued in the transmit 189 buffer of one of the RTP sessions. 191 o When there is already some RTP data queued in the transmit buffer of 192 a session, the new data is linked in the same transmit buffer. 194 o When the data of each session has been distributed, transmission 195 processing begins. When there is some RTP data linked, the data is put 196 into an IP packet. 198 For example when 5 RTP voice streams(1-5) are transferred between 199 Internet Telephony Gateways, multiplex packets are sent using one of 200 the UDP ports designated for the streams(1-5). Each time a 201 stream(1-5) is transmitted, it is possible to change the UDP port that 202 is used. Actual implementation is beyond the scope of this document. 204 5. Negotiation 206 GWs must determine, during the call control, whether the destination 207 GW and/or H.323 terminal has a multiplexing function. Additionally, 208 when multiple streams are multiplexed into one RTP packet, GWs can not 209 distinguish between streams by the receiving port number. Therefore, 210 GWs need to communicate that stream identifications with one another. 211 The ID value is set SSRC which is defined in RTP to prevent having to 212 manage multiple IDs. Negotiation and such topics are also beyond the 213 scope of this document. 215 6. Open Issues 217 There are some issues; 219 (1) How the negotiation for multiplexing and communication of stream's 220 ID (SSRC) are processed in H.323? 222 (2) How about the multimedia streams whose lengths are variable? 223 Shall each RTP stream's RTP fixed header be extended having a length 224 field? 226 7. Conclusion 228 A voice streams multiplexing format for IP Telephony Gateways was 229 proposed. This format is very simple, and the implementation is very 230 easy. 232 8. References 234 [1] H. Schulzrinne, et. al., "RTP : A Transport Protocol for Real-Time 235 Applications", IETF RFC 1889, January 1996. 237 [2] H. Schulzrinne, et. al., "RTP Profile for Audio and Video 238 Conference with Minimal Control", IETF RFC 1890, January 1996. 240 9. Author's Addresses 242 Keiko Tanigawa 243 Systems Development Laboratory 244 Hitachi, Ltd. 245 292 Yoshida-cho, Totsuka-ku, Yokohama, 244-0817, JAPAN 246 Phone: +81-45-881-1241 247 Fax: +81-45-860-1675 248 Email: takahara@sdl.hitachi.co.jp 250 Tohru Hoshi 251 Email: hoshi@sdl.hitachi.co.jp 253 Koji Tsukada 254 EMail: ktsukada@sdl.hitachi.co.jp