Internet Engineering Task Force AVT WG Internet Draft Alexander Tulai draft-tulai-avt-dynamic-nx64-00.txt Mitel Corp. October 21, 1999 Expires: April 21, 1999 Dynamic Nx64 STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. ABSTRACT This document describes DyN64, an RTP payload format for dynamic multiplexing 64 Kbps voice streams. This document is a product of the Audio/Video Transport (AVT) working group of the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at rem-conf@es.net and/or the author. 1 Introduction When multiple RTP voice streams originate and end in the same gateway, previous RTP multiplexing methods (see [GeRM] and [TCRTP]) have shown very good packet overhead reduction. This methods could add significant complexity to both the sender and the receiver implementations [TCRTP] and, even in the best case, still require a Alexander Tulai [Page 1] Internet Draft Dynamic Nx64 October 21, 1999 few bytes of overhead per RTP stream. When multiple identically encoded sample-based RTP streams are to be transported between a pair of gateways, like in IP telephony, the individuality of each RTP stream (defined by the the fields in the RTP header) could be sacrificed and the bandwidth gains could be used to lower the packetization delay of each individual stream. The issue of transporting Nx64 streams has been addressed in the context of ATM networks as reflected in the ATM forum document [DBCES], whereby a mechanism for identifying the active channels is added to the Nx64K mechanisnm for transporting fractional DS1/E1 trunks described in [CESIS]. Next generation of gateway equipment will have to bridge Circuit Switched Networks to both ATM and IP networks (see ITU-T,Q21/SG15) and trying to match ATM network capabilities with IP network capabilities, comes as a natural concern. The Digital Circuit Multiplexing Equipment (DCME) manufacturers are also interested in transporting Nx64 streams and this interest is reflected in the study items proposed for the new ITU-T period by Q6/SG15 working group (e.g. "evaluation/development of schemes for nx64 kbit/s unrestricted services"). The method proposed in this internet draft for dynamically transporting Nx64 Kb/s streams in the IP network domain could be used as well for transporting Nx32 Kb/s streams (32 Kb/s ADPCM) or, generally speaking, any N identically encoded sample-based voice streams. 2 Terminology o Activity bits: A group of two bits assigned to a channel o Connection: The point to point RTP session between two MGs. o Channel: A virtual connection which is established by allowing a user to send data within a packet. There are many channels per connection - this represents the Nx64. o DyN64 header: A collection of 4M activity bits that are placed at the beginning of the payload, immediately following the RTP header. The first byte in the DyN64 header is the most significant and the last one is the least significant. The end of the DyN64 header is marked by the bits '11'. Alexander Tulai [Page 2] Internet Draft Dynamic Nx64 October 21, 1999 3 Specification Because all the RTP streams will share a destination IP address, UDP port as well as the SSRC number, the channel to which the data belongs will be identified by the position of the data in the payload and by the activity bits in the DyN64 header. A dynamic payload type (PT) will be allocated for the dynamic Nx64 RTP payload. If multiple 64 Kb/s and 32 Kb/s sample-based streams are to be established between two gateways, then different PTs will have to be allocated for the Nx64 and Nx32 payload types, and so on. All the sample-based streams are assumed to be coded with the same codec and they equally share the payload. Interleaving the samples of the packetized channels allows for a simpler implementation compared to blocking the samples per channel. The DyN64 header is a group of 4M pairs of activity bits. Each pair of activity bits is allocated to a virtual channel. The coding of the activity bits is as follows: 00: inactive channel 01: active channel 10: silence supressed channel 11: end of DyN64 header With a maximum limit for M set to 8, an IP packet could carry up to 31 individual channels (31x64). The DyN64 can have a variable size from 1 (M=1, 3x64 Kb/s streams) to 8 bytes (M=8, 31x64 Kb/s streams). The most significant bytes of the DyN64 header that are null do not have to be tramsitted. When the DyN64 header is one byte long, up to three channels could be carried in the RTP payload. In general, when the DyN64 header (the end of which is marked by the bits '11') is M bytes long, the maximum number of channels carried in the payload is 4M-1. When silence supression is employed on a certain channel, the activity bits will be set to '10' and only one byte will be transmitted on the position corresponding to sample 0. That byte will carry the noise level that is usually carried through a CN packet (see [RTPP]) By including the noise level in every packet, for as long as silence is detected, better noise shaping will be achieved at a very low cost of 1 byte per packet. In addition to that, the loss of a packet will not affect the comfort noise generation process at the receiver end. The number of samples per channel carried in a packet is calculated Alexander Tulai [Page 3] Internet Draft Dynamic Nx64 October 21, 1999 as follows: number of samples per active channel = (length of the payload - the size of the DyN64 header - number of silence channels) / number of active channels 4 Examples Assuming that out-of-band signalling has been used to establish a dynamic Nx64 connection with channel 0 active, the payload of such a packet would look like. 7 6 5 4 3 2 1 0 +--+--+--+--+--+--+--+--+ | 0 0 | 0 0 | 0 1 | 1 1 | +--+--+--+--+--+--+--+--+ | ch0_s0 | ------------------------- | ch0_s1 | ------------------------- ................ Assuming that channel 1 becomes active the payload will look like 7 6 5 4 3 2 1 0 +--+--+--+--+--+--+--+--+ | 0 0 | 0 1 | 0 1 | 1 1 | +--+--+--+--+--+--+--+--+ | ch1_s0 | ------------------------- | ch0_s0 | ------------------------- | ch1_s1 | ------------------------- | ch0_s1 | ------------------------- ................ If channel 0 will be silence supressed the payload will look like 7 6 5 4 3 2 1 0 +--+--+--+--+--+--+--+--+ | 0 0 | 0 1 | 1 0 | 1 1 | +--+--+--+--+--+--+--+--+ | ch1_s0 | ------------------------- |0 | chan.0 noise level | ------------------------- | ch1_s1 | ------------------------- Alexander Tulai [Page 4] Internet Draft Dynamic Nx64 October 21, 1999 | ch1_s2 | ------------------------- ................ If two more channels become active the payload will look like 7 6 5 4 3 2 1 0 +--+--+--+--+--+--+--+--+ | 0 0 | 0 0 | 0 0 | 0 1 | +--+--+--+--+--+--+--+--+ | 0 1 | 0 1 | 1 0 | 1 1 | +--+--+--+--+--+--+--+--+ | ch3_s0 | ------------------------- | ch2_s0 | ------------------------- | ch1_s0 | ------------------------- |0 | chan.0 noise level | ------------------------- | ch3_s1 | ------------------------- | ch2_s1 | ------------------------- | ch1_s1 | ------------------------- | ch3_s2 | ------------------------- ................ If channels 2 and 1 become inactive and channel 0 is not silence supressed anymore, the payload will look like. 7 6 5 4 3 2 1 0 +--+--+--+--+--+--+--+--+ | 0 0 | 0 0 | 0 0 | 0 1 | +--+--+--+--+--+--+--+--+ | 0 0 | 0 0 | 0 1 | 1 1 | +--+--+--+--+--+--+--+--+ | ch3_s0 | ------------------------- | ch0_s0 | ------------------------- | ch3_s1 | ------------------------- | ch0_s1 | ------------------------- ................ From these examples it becomes clear that when a channel with a high Alexander Tulai [Page 5] Internet Draft Dynamic Nx64 October 21, 1999 number stays active while most of the channels with a lower number are inactive, the size of the DyN64 header becomes significant when compared to the size of the payload. This is one good reason why N (in Nx64) should not be very high. 5 RTP header sharing All the Nx64 streams will share the same RTP header. The implications of that is studied in this section. 5.1 CSRC count If the CC field is non zero, the CSRC list that follows will have to be globally relevant to all RTP streams and not to one stream in particular. An example of such a case would be an audio conference where all the participants use G.711 coders. The only incentive for using the DyN64 in such a case would be the support for silence supression. 5.2 Marker bit (M) The marker bit is not used by the Dynamic Nx64 payload format. 5.3 Sequence number The initial value of the sequence number is randomly chosen. When a call is setup and a new channel becomes active, the instant value of the sequence number will consequently be a random value for that particular call, in line with [RTP]. 5.4 Timestamp The timestamp reflects the sampling instant of the first octet in the RTP payload. Because a new channel becomes active at a random point in time, the first packet that contains a new active channel might require insertion of "silence" samples at the beginning to compensate for the difference between the time of the timestamp and the time when the channel has in fact become active. 5.5 Miscellaneous fields The sharing of the rest of the RTP header fields between multiplexed streams coded with an identical coder poses no problems. 6 RTCP statistics Per stream RTCP statistics are required on the termination of the connection (channel moving to inactive state) as explained in [MGCP], Alexander Tulai [Page 6] Internet Draft Dynamic Nx64 October 21, 1999 and will be required by the new ITU-T standard H.248. It is clear that the life of IP packet stream using DyN64 is equal or longer than the life of any of the RTP stream it carries. However, some of the statistics have relevance for each individual stream (for example the bytes or packets sent, packets lost etc.). For those statistics that are relevant to each individual connection, the corresponding counters must be reset when a new stream becomes active. However, before they are cleared, the value of those counters should be used to update the value of individual counters of the older streams. Those statistics that have global significance, like packet jitter, should be left untouched because long term measurements are more relevant than the short term ones. The method of clearing the statistics counters is already used, for example, when the SSRC changes. 7. Copyright Copyright (C) The Internet Society 1999. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 8 Addresses of Authors Alexander Tulai Mitel Corporation, 350 Legget Drive, Kanata, Ontario, K2K-2W7, Canada Alexander Tulai [Page 7] Internet Draft Dynamic Nx64 October 21, 1999 Email: alexander_tulai@mitel.com 9. References [TCRTP] T. Koren, P. Ruddy, B. Thompson, A. Tweedly, D. Wing, "Tunneled multiplexed Compressed RTP", draft-wing-avt-tcrtp-00, June 1999. [GERM] M. Handley, "GeRM: Generic RTP Multiplexing", draft-ietf-avt- germ-00, Nov. 1998 [CESIS] The ATM Forum, "Circuit Emulation Service Interoperability Specification", Version 2.0, aft-vtoa-0078.000, January 1997 [DBCES] The ATM Forum, "Specifications of Dynamic Bandwidth Utilization - in 64 kbps Time Slot Trunking over ATM - using CES", af-vtoa-0085.000, July 1997 [RTPP] H. Schulzrinne, S. Canser, "RTP Profile for Audio and Video Conferences with Minimal Control", draft-ietf-avt-profile-new-06, June 1999 [CRTP] S. Casner, V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC2508, February 1999. [RTP] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC1889, January 1996. [MGCP] Mauricio Arango, Andrew Dugan, Isaac Elliott, Christian Huitema, Scott Pickett, "Media Gateway Control Protocol" draft- huitema-megaco-mgcp-v0r1-05.txt, Expires: April 21, 1999 Internet Draft Dynamic Nx64 October 21, 1999