Internet Engineering Task Force AVT Working Group Internet Draft B. Subbiah, S. Sengodan draft-ietf-avt-mux-rtp-00.txt Nokia Research Center. Aug 21, 1998 Expires: Feb 21, 1999 User Multiplexing in RTP payload between IP Telephony Gateways STATUS OF THIS MEMO This document is an Internet-Draft. Internet-Drafts are working docu- ments of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute work- ing 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 mate- rial 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). Distribution of this document is unlimited. ABSTRACT This draft proposes a method to multiplex a number of low bit rate audio streams (upto 256) into a single RTP/UDP/IP connection between IP telephony gateways. Audio samples from different users are assem- bled into an RTP payload thus reducing the overhead of RTP/UDP/IP headers. To identify users sharing a single RTP/UDP/IP connection, a 2 byte MINI-Header is proposed. A channel negotiation procedure to assign and release channels on a single UDP connection between gateways is described. 1 Introduction IP telephony gateways provide an interface between the existing circuit switched telephone networks (such as PSTN and GSM) and the packet switched IP data networks. In a traditional IP telephony application, telephone calls between PSTN/GSM users interconnected by a pair of IP telephony gateways are carried by separate RTP/UDP/IP connections. Codecs at the IP telephony gateway which compress incoming PSTN/GSM speech samples generate packets with sizes ranging from 5 to 20 bytes per speech sample. For example, G.723.1 (the most popular IP telephony codec and the IMTC VoIP Forum's mandatory low bit-rate codec), generates a 20 byte speech packet at 30 ms intervals B. Subbiah, S. Sengodan [Page 1]
Internet Draft Aug 15, 1998 [4]. Many codecs used in cellular environments generate packets of size less than 10 bytes per speech sample. Small size packets are subject to a large overhead when transferred using the Real time Transport Protocol (RTP). The RTP/UDP/IP overhead is 40 bytes (12+8+20) for a single speech packet. For example, a 10 byte packet transferred via RTP/UDP/IP has an overhead of 80%. In addition, for each call request a single UDP/IP connection (a pair of UDP ports) is established between the gateways. This not only limits the number of audio streams between the gateways to the number of available UDP port pairs, but also requires a large state (memory) to be maintained at the telephony gateways, thereby making these gateways less scaleable. Another disadvantage of the traditional RTP/UDP/IP method in a gateway scenario is the possibility of congestion at intermediate routers in the IP network. In the RTP/UDP/IP method, each individual speech packet is transmitted as a single IP packet, which results in large number of small sized IP packets between gateways. This is a potential situation for congestion at intermediate IP routers. Congestion in IP networks results in packet loss and UDP does not have any re-transmission mechanism to recover lost packets. Also, real time applications such as speech are intolerant to delay caused by re-transmission. In this draft, we propose a mechanism that enables several streams (upto 256) to share a single RTP/UDP/IP connection between IP telephony gateways thereby reducing the overhead, lowering the possibility for congestion at IP routers, and making such gateways more scaleable. This method is suitable for IP telephony gateways that interconnect PSTN/GSM users through IP networks. In a cellular environment, it can also be used in cellular trunking, links that interconnect Base Station (BS), Base Station controller (BSC), and Mobile Switching Center (MSC) of a Radio Access Network (RAN). Individual user packets multiplexed in an RTP payload are identified using a 2 byte MINI-header. The channel association between gateways for a single user can be carried out by one of the three mechanisms described later in this draft. 2 User multiplexing in RTP payload It has been observed that, at any given time there are multiple active users between IP telephony gateway pairs that interconnect PSTN/PBX/GSM clouds. This is also true in the case of cellular trunking between a Base Transmission System (BTS) and BSC/MSC. At present, IP telephony gateways establish and maintain a separate RTP/UDP/IP connection for each call request. In the above scenarios, a large number of connections originate and terminate between two gateways interconnected by an IP network. This is an ideal situation for multiplexing a group of users in a single RTP/UDP/IP connection. The mechanism for user mux in RTP that is proposed in this draft decreases the overhead by multiplexing two or more (up to 256) low bit rate connections (compressed speech) in a single RTP/UDP/IP connection. To enable such multiplexing, a 2 byte header called B. Subbiah, S. Sengodan [Page 2]
Internet Draft Aug 15, 1998 MINI-Header is prepended to each mini packet before it is assembled with other mini packets into an RTP payload. To identify a single user among the number of users sharing the same RTP connection, each user is assigned a unique Channel Identifier (CID) which is negot- iated during connection setup. The CID negotiation procedure is carried out by a control signaling which may be based on one of the three methods(CNP, SIP and H.225) described in section 3. 2.1 MINI-Header The format of a MINI-Header is shown in Figure 1: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CID | LI |T|R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Format of a MINI-Header The length of the MINI-Header is 2 bytes, which includes a Channel Identifier(CID), Length Indicator (LI), Transition bit (T) and a Reserved bit (R). The purpose of each field is described below: - Channel IDentification (CID): This 8 bit field allows a maximum of 256 users to share a single RTP/UDP/IP connection. When the total number of users exceeds 256, a new RTP/UDP/IP connection is established. - Length Indicator (LI): This 6 bit field allows a maximum payload size of 64 bytes. - Transition bit (T): The transition bit is used to facilitate dynamic re-negotiation of mini-packet processing. Notification of such changes occurs by toggling the bit. - Reserved bit (R): The use of this bit is being explored at this moment. It has been observed that an 8 bit CID is sufficient for multiplexing since there are enough speech samples at any instance. Most of the codecs generate packets less than 40 bytes per speech sample that can be easily accommodated with a 6 bit LI field. While the presence of a Sequence Number (SN) field and a Marker (M) field in the mini-header could be useful at the receiving gateway, we believe that the presence of these fields is not critical. The SN field in the RTP header can guarantee the order of packet (RTP packet) arrival at the receiver. If the packet multiplexing order at the transmitter is maintained then there is no need for SN in the MINI-Header from the standpoint of in-sequence arrival of packets within a single RTP/UDP/IP connection. Moreover, a Header Error Control (HEC) field to protect from transmission errors has been left out because UDP checksum could be used for the same purpose. B. Subbiah, S. Sengodan [Page 3]
Internet Draft Aug 15, 1998 2.2 RTP Payload Format A speech sample (voice packet) received from a user is converted to a mini packet by adding the 2 byte MINI-Header. The CID selection and channel negotiation procedures are carried out before the packet is assembled. These procedures are described in section 3. The assembly of mini packets into a single RTP payload with RTP/UDP/IP header is shown in Figure 2. The mini packets follow the RTP header and each mini packet is delineated by the 2 byte MINI-Header. This arrangement of a MINI-header followed by payload allows variable sized packets (<= 64 bytes) to be assembled without the knowledge of the payload itself. Moreover, this scheme requires a very simple de-multiplexing algorithm at the receiver. The RTP payload received by the remote gateway is de-assembled to recover the individual mini packets until the payload becomes empty. The packets are then delivered to the respective users based on the channel association carried out during the call setup phase. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+ | + + + + + + + + + | | IP + UDP + RTP + MH1 + VP1 + MH2 + VP2 + ~ + MHn + VPn | | (20) + (8) + (12) + (2) + + (2) + + + (2) + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+ *MH - Mini Header, VP - Voice Packet Figure 2. RTP payload format with user multiplexing 2.3 Packet assembly timer While assembling mini packets into an RTP payload, there is a need to control the waiting time (delay) between the placement of the first packet in the RTP payload and the transmission of the complete IP packet to the remote gateway. Without a timer, packets placed at the beginning will be subjected to a large delay. This problem occurs when there is a large interval between successive packet arrivals at the multiplexing end. To solve this problem, we propose a timer called TIMER_MUX to control the maximum delay a mini packet may be subjected to during the RTP payload assembly. The TIMER_MUX is initialized when the first packet is placed in the RTP payload and upon the timer expiry the RTP/UDP/IP packet is transmitted. There are instances when the RTP/UDP/IP packet needs to be transmitted without the expiry of TIMER_MUX. The higher the TIMER_MUX value the better the bandwidth efficiency. However, a higher TIMER_MUX value means additional delay for voice packets. 2.4 Packet Size The assembly process of mini-packets into an RTP payload should not only consider the TIMER_MUX value but should also take into account the size of the resulting IP datagram. The size of the resulting IP datagram should not exceed the maximum transmission unit (MTU) of the B. Subbiah, S. Sengodan [Page 4]
Internet Draft Aug 15, 1998 IP network. Hence, when the IP network is the public Internet, the size of the IP datagram should not exceed 1500 bytes. It has been determined that an IP datagram of size less than 1500 bytes usually goes through the Internet unfragmented. 2.5 UDP connection Implementation details of sharing a pair of UDP ports among different users and reusing the same port numbers for persistent UDP sessions are beyond the scope of this document. 3 Control signaling for user multiplexing The user plane and control plane between gateways is shown in Figure 3. The control plane signaling is needed because peer Mux controllers are required to negotiate a channel for an incoming call request on an existing or on a new UDP connection. The control signaling is transferred using a common persistent connection, which may be either connection oriented (TCP) or connectionless (UDP). The user plane association (CID allocation on a UDP connection) is made after a successful connection setup. In this draft, we describe three different approaches to establish and clear a CID association. The user plane data is carried over RTP/UDP/IP layers in a manner similar to the audio and video transport over IP networks. The description of the signalling and control operation is not meant to be comprehensive. +++++++++++++++++++ +++++++++++++++++++ + Mux Controller + + Mux controller + +++++++++++++++++++ +++++++++++++++++++ | | | | | | U-plane U-plane | |C-plane C-plane | +++++++ +++++++ | | + RTP + + RTP + | +++++++++++++++++++ +++++++++++++++++++ + TCP | UDP + + UDP | TCP + +++++++++++++++++++ +++++++++++++++++++ + IP ++++> IP NET <++++++ IP + +++++++++++++++++++ +++++++++++++++++++ Figure 3. Control plane and user plane in a user multiplexing scenario B. Subbiah, S. Sengodan [Page 5]
Internet Draft Aug 15, 1998 3.1 CID selection Irrespective of the choice of the signaling mechanism between the MUX controllers, the CID selection procedure at each of the MUX controllers MUST be done as follows: 1) Arrival of a new call from a PSTN/GSM user triggers a CID assignment sequence at the MUX controller of the local gateway. After establishing which remote gateway can handle the call, the local MUX controller checks for the existence of an RTP/UDP/IP connection to the remote MUX controller. If there exists a UDP connection with free CIDs, then a CID is chosen and reserved for that call. If there is no UDP connection between the gateways or if all the existing connections are full (i.e., no free CID), then a new RTP/UDP/IP connection is established. Once the CID selection is done, a notification message that consists of CID, calling user ID, called user ID, local and remote UDP port numbers is transmitted. Such transmission may occur either in the initial notification message (during call setup) or in the notification message for capability exchange that occurs after call setup. 2) Upon receiving the message containing the CID, the MUX control- ler at the remote gateway checks its CID table associated with the UDP connection. The status of CIDs is maintained in a CID table, which is associated with each UDP connection between any two gateways. If the CID indicated in the notification message has not already been assigned, then the remote MUX controller makes an entry in its CID table assigning the CID to a call between the pair of UDP ports as indicated in the notification message. If the UDP port at the remote gateway is not already open, then the MUX controller opens the UDP port. Table 1 shows a sample CID table used at a gateway for a single UDP conne- ction. ------------------------------------------------------------ | CID |CID status | Local UID |Remote UID | ------------------------------------------------------------ | 5 | Assigned | 6172300000 |9127363736 | | | | | | | 10 | Reserved | 6175464636 |8263737474 | | | | | | | 20 | Idle | | | | | | | | | 200 | Idle | | | ------------------------------------------------------------ Table 1. CID table for a single UDP connection 3.2 CID collision During the CID negotiation procedures, there is a possibility that the same CID is selected by both ends for their own call requests. Both gateways transmit channel request messages with the same CID without the knowledge of the other gateway. After receiving the request, both sides are unable to allocate the CID since it has been B. Subbiah, S. Sengodan [Page 6]
Internet Draft Aug 15, 1998 reserved for their local call request. This problem is otherwise known as CID glare. We propose to use a method that is fair to both ends in CID assignment procedures. In this method, one side is assigned to allocate CIDs from the top of the CID table and the opposite side from bottom. However, CID collision occurs when a single CID is available at both ends. Even in such a case, fairness can be achieved by an assignment based on the even and odd value of CID. The arbitration of which side starts from top can be resolved using IP address of the gateways. For example, the gateway with the higher IP address starts from the top and the other gateway starts from the bottom. 3.3 Channel Negotiation Procedures (CNP) CNP is a new control signaling specifically proposed for the user multiplexing application between IP telephony gateways that interconnect PSTN/GSM clouds. The function of CNP is to negotiate a CID for a call through a set of messages similar to standard signal- ing protocols. Since CNP is targeted for a specific application, we do not anticipate the need for complex signaling procedures similar to H.225/H.245 [5,6]. However, H.225/H.245 could be adapted to suit the requirements of the user multiplexing in RTP method. CNP consists of a set of messages that include assign, assign_confirm, release, release_confirm and reject. An additional message "messages_transfer" is also proposed in case there is a need to transmit control messages of a particular user (call control messages) during the active session of a call. A detailed study on the format of the CNP messages and their parameters will be reported later. The following is the sequence of events that occur in a channel negotiation phase: - Assign: Upon arrival of a new call from a PSTN/GSM user, a CID is assigned based on the procedure described in the previous sect- ion. An "assign" message is then transmitted to the remote gate- way containing the local UDP port number, remote UDP port number, CID number, calling and called user, and an UUI field to carry any call control signaling (PSTN and SS7). - Assign_confirm or reject: The remote peer recovers the informat- ion within the "assign" message and does local processing as described in the previous section. If the call can be accepted then the local Mux controller updates its local CID table and replies with an "assign_confirm" message. If the remote gateway experiences a problem in allocating the connection, say due to CID collision, then it transmits a "reject" message. Upon recei- ving the "assign_confirm" message, the local Mux controller confirms the CID assignment by updating the CID table and noti- fying the local user. B. Subbiah, S. Sengodan [Page 7]
Internet Draft Aug 15, 1998 +++++++ +++++++ + + Assign + + + + ----------------> + + + GW1 + Assign_confirm + GW2 + + + <------------------ + + + + + + +++++++ +++++++ Figure 4: CNP Confirm sequence +++++++ +++++++ + + Assign + + + + ----------------> + + + GW1 + Reject + GW2 + + + <------------------ + + + + + + +++++++ +++++++ Figure 5: CNP Reject sequence 3.4 Use of H.225/H.245 for channel negotiation +++++++++ +++++++++++ +++++++++ + +------ H.225 ------+ + ++++++++ + + + +------ H.245 ------+ + + + + PSTN +++++ + + + +++++++ PSTN + +++++++++ + IP GW +--- IP NETWORK ---+ IP GW + ++++++++ + + + + + +-- UDP channel 1 --+ + +++++++++ + +-- UDP channel n --+ + +++++++++ + + ++++ +++++++++ ++++++++++++++++ + + GSM + + GSM + +++++++++ +++++++++ Figure 6: H.225/H.245 in an IP telephony gateway ITU-T has standardized H.225[5] and H.245[6] as the call signaling protocol and call control protocol respectively to be used within the ITU-T standard H.323[7]. H.225 and H.245 may be used for signaling and control purposes between the gateways. When this is the case, persistent H.225 and H.245 connections exist between a pair of gateways. All voice connections between the two gateways should use the same H.225 and H.245 connection for call signaling and call control purposes. B. Subbiah, S. Sengodan [Page 8]
Internet Draft Aug 15, 1998 When a new call arrives at a gateway from the circuit switched side (PSTN/GSM), a SETUP message is transmitted from the initiating gateway to the terminating gateway on the persistent TCP call-signa- ling channel (H.225 channel). The User-User-Information-Element (UUIE) of the SETUP message includes the parameters that are needed for connection setup as indicated in the H.225 document [9]. For the purpose of user multiplexing between gateways, the setting of the UUIE fields in the SETUP message MUST be as follows: - h245Address: This field is set to the TSAP address of the call control TCP channel (H.245 channel) at the initiating gateway that will be used for call control purposes of this voice stream. Initiating gateways should use the same call control channel for all voice streams. However, the initiating gateway may wish to open a new call control channel when the number of voice streams using the same control channel exceeds a certain threshold value. When the initiating gateway wishes to use a new call control channel, the TSAP address of the new H.245 channel is included in this field. If the remote gateway responds with a CONNECT message upon receiving the SETUP message, the UUIE fields within the CONNECT message MUST be set as follows: - h245Address: This field is set to the TSAP address of the call control TCP channel (H.245 channel) at the responding gateway that will be used for call control purposes of this voice stream. Remote gateways should use the same call control channel for all voice streams when an initiating gateway has used the same existing call control channel. If a remote gateway wishes to use a new call control channel when the initiating gateway has indicated the use of an existing call control channel in the SETUP message, then the remote gateway must send a FACILITY and a RELEASE message. However, if an initiating gateway has indic- ated the use of a new call control channel, then the remote gateway must use a new call control channel. The TSAP address of the new call control TCP channel at the remote gateway is included in this field. Upon receiving the CONNECT message from the remote gateway, the call control phase (H.245) begins. The capability exchange messages determine the choice of codecs and the security parameters if any to be used between the gateways. In addition, the capability exchange also indicates the capability for performing multiplexing. In the openLogicalChannel (and openLogicalChannelAck) message, in addition to indicating the TSAP address, the CID is also indicated. B. Subbiah, S. Sengodan [Page 9]
Internet Draft Aug 15, 1998 +++++++ +++++++ + + SETUP + + + + ----------------> + + + GW1 + CONNECT + GW2 + + + <------------------ + + + + CapabilitySet + + + + ------------------> + + + + CapabilitySetAck + + + + <------------------ + + + + OLC + + + + ------------------> + + + + OLCAck + + + + <------------------ + + +++++++ +++++++ Figure 7: H.225/H.245 exchange sequence +++++++ +++++++ + + SETUP + + + + ----------------> + + + GW1 + FACILITY + GW2 + + + <------------------ + + + + RELEASE + + + + <------------------ + + +++++++ +++++++ Figure 8: H.225 Facility/Reject sequence B. Subbiah, S. Sengodan [Page 10]
Internet Draft Aug 15, 1998 3.5 Use of SIP for channel negotiation +++++++++++ +++++++++++++++++ + + --- persistent SIP channel -- + + + + + + + + + + + IP GW1 + + IP GW2 + + + + + + + --- audio UDP channel 1 --- + + + + --- audio UDP channel n --- + + +++++++++++ +++++++++++++++++ Figure 9. SIP in IP telephony gateways Session Initiation Protocol (SIP) can be used as the control signaling protocol between the two gateways [11]. In this case, the gateway that receives a call from the circuit switched side is the SIP client, while the remote gateway is the SIP server. The series of messages that are exchanged are described below. These messages are exchanged on the persistent signaling connection existing between the two gateways. Such a persistent connection may either be TCP or UDP. As with the case of H.225, the description here is not meant to be exhaustive but is merely for illustration. Issues such as locating the remote gateway by the use of proxy or redirect servers, among other things, are not discussed here. When a new call comes into the initiating gateway from the circuit switched side, an INVITE message is sent from the calling gateway (SIP client) to the called gateway (SIP server). The fields of the INVITE message are set as follows: - Request-URI: This field contains sip:phonenumber@remotegateway. For instance, if the number being called is +1-781-359-5112 and the remote gateway that can handle this call is gw1-boston.research.nokia.com, then the Request-URI has a value sip:+1-781-359-5112@gw1-boston.research.nokia.com. - Session Description: The session description includes the capability of the initiating gateway with regard to supported codecs, supported security parameters etc. Also included in the session description is the Channel Identifier (CID), the source UDP port and the destination UDP port. Upon receiving the INVITE message, the remote gateway returns the following messages in the sequence indicated: - TRYING: This message indicates to the calling gateway that the remote gateway has received the INVITE message successfully and that the remote gateway is trying to establish contact with the user. This is also an indication to the initiating gateway not to retransmit the INVITE message. - RINGING: This message indicates that the user has been contacted and that his phone is ringing. - SUCCESS: This message indicates that the user has answered his phone. The SUCCESS message is sent by the remote gateway only if the CID value indicated in the INVITE message is acceptable to the remote gateway. Upon receiving the SUCCESS message, the initiating gateway returns an ACK message back to the remote gateway. This is illust- rated in Figure 10. If the CID indicated in the INVITE message is not a valid one, the remote gateway returns an ERROR/FAILURE message back to the initia- ting gateway as indicated in Figure 11. B. Subbiah, S. Sengodan [Page 11]
Internet Draft Aug 15, 1998 +++++++ +++++++ + + INVITE + + + + ----------------> + + + GW1 + TRYING + GW2 + + + <------------------ + + + + RINGING + + + + <------------------ + + + + SUCCESS + + + + <------------------ + + + + ACK + + + + ----------------> + + +++++++ +++++++ Figure 10: SIP Confirm sequence +++++++ +++++++ + + INVITE + + + + ----------------> + + + GW1 + ERROR/FAILURE + GW2 + + + <------------------ + + +++++++ +++++++ Figure 11: SIP Reject sequence 4 Transmission errors and packet loss Protocols such as ATM, IP and AAL2 specify a Header Error Correction (HEC) to detect errors in the headers, whereas UDP offers both header and payload protection. The UDP checksum field in the UDP header is calculated for the entire UDP packet including the header and payload bytes. The MINI-header used for user multiplexing is 2 byte long and does not have any HEC field. The reason is that the mini packets are encapsulated within a UDP payload thus protected by the UDP checksum. The presence of the RTP sequence number in the RTP header facilitates to identify packet losses at the RTP level. Since each RTP packet contains a number of mini packets, packet loss at individual level becomes difficult. However, it is our understanding that the SN for individual mini packet is not necessary. 5 Application scenarios Some of the most obvious scenarios, in which the proposed method is beneficial, are shown in Figure 12. Traditional telephony system such as PSTN interconnected by IP telephony gateways is an ideal scenario where user mux method improves the bandwidth efficiency in the IP B. Subbiah, S. Sengodan [Page 12]
Internet Draft Aug 15, 1998 network. This method can also be used in the Radio Access Network (RAN) of a cellular network. In cellular trunking, mux controller is a part of the BS and BSC/MSC connected by IP networks. User aggregation can be applied between BTS and BSC as well as between BSC and MSC. ++++++++++ ++++++++ + + + + + PSTN + + PSTN + ++++++++++ + ++++++++ + + +++++++++++ +++++++++ + + + + + + + + + IP GW ++++++ IP NETWORK ++++ IP GW + + + + + + + + + + +++++++++++ + + + + +++++++ + + +++++++++++ +++++++++ +++++ + + GSM + + GSM + +++++++++++ +++++++ Figure 12. Application scenario of User mux in RTP 6 Security Considerations There are no security considerations beyond those addressed in RTP itself. The multiplexing protocol can make use of whatever encryption and authentication schemes are present in RTP, SIP, H.323 or other relevant protocols. For instance, the multiplexed media stream could be secured by securing the UDP ports using IPSEC. The signaling and control channels could be secured either by the use of IPSEC or TLS. Application level security as specified in SIP and H.235 may also be incorporated. 7 Comparison of User mux in RTP and traditional RTP/UDP/IP The important reason for multiplexing small size packets into a single RTP payload is that the RTP/UDP/IP overhead for each packet can be reduced. For example, the RTP/UDP/IP overhead is 66.7% in case of 20 byte G.723.1 packet and 80% for a 10 byte G.729 packet. Considering that IP telephony gateways transfer 100s of user at any given time, the total bandwidth requirement including the overhead is very high. The bandwidth requirement for a traditional scheme (RTP/UDP/IP) is compared to user mux in RTP and the results are shown in Table 2. The results indicate that the bandwidth requirement to transport same number of users through user mux is very low compared to the traditional IP telephony (RTP/UDP/IP) method. B. Subbiah, S. Sengodan [Page 13]
Internet Draft Aug 15, 1998 --------------------------------------------------------------------- # users No Mux User Mux No Mux UserMux (G.723.1) (G.723.1) (G.729) (G.729) --------------------------------------------------------------------- 10 159 68.9 400 128 30 477 185.5 1200 320 50 795 302.1 2000 512 70 1113 418.7 2800 704 90 1431 535.3 3600 896 110 1749 651.9 4400 1088 130 2067 768.5 5200 1280 150 2385 885.1 6000 1472 170 2703 1001.7 6800 1664 190 3021 1118.3 7600 1856 210 3339 1234.9 8400 2048 230 3657 1351.5 9200 2240 250 3975 1468.1 10000 2432 ---------------------------------------------------------------------- Table 2. Bandwidth requirements in Kbps for user mux and IP methods A comparison of percentage overhead for two different speech codecs is shown in Table 3. The overhead due to RTP/UDP/IP is constant for both codecs. User mux in RTP method is able to multiplex small packets into a single RTP/UDP/IP payload thus reducing the overhead to minimum. The overhead comparison on both codecs proves that user mux in RTP is very efficient in reducing the overhead. ------------------------------------------------------------------- #Users Mux(G.729) IP (G.729) Mux(G.723.1) IP (G.723.1) ------------------------------------------------------------------- 10 37.5 80 23.07692308 66.7 30 25 80 14.28571429 66.7 50 21.875 80 12.28070175 66.7 70 20.45454545 80 11.39240506 66.7 90 19.64285714 80 10.89108911 66.7 110 19.11764706 80 10.56910569 66.7 130 18.75 80 10.34482759 66.7 150 18.47826087 80 10.17964072 66.7 170 18.26923077 80 10.05291005 66.7 190 18.10344828 80 9.952606635 66.7 210 17.96875 80 9.871244635 66.7 230 17.85714286 80 9.803921569 66.7 250 17.76315789 80 9.747292419 66.7 ------------------------------------------------------------------ Table 3. Comparison of % overhead due to IP and user mux in RTP 8 Advantages of user multiplexing in RTP The first advantage of using the proposed method between IP telephony B. Subbiah, S. Sengodan [Page 14]
Internet Draft Aug 15, 1998 gateways is the bandwidth efficiency. The second advantage of sharing a single RTP/UDP/IP is that the number of UDP connections is reduced between gateways. For example, in the proposed user multiplexing method a single UDP connection can be shared by a maximum of 256 users. The third advantage is that the less chances for traffic congestion at intermediate IP routers, because the proposed method reduces the number of IP packets by multiplexing mini packets in a single RTP payload. Despite the multiplexing effect, user multiplex- ing in RTP does not cause any problems in the IP network since RTP payload (mini packets) is transparent to the intermediate IP routers. The user mux method requires minimal effort on standardization and could be implemented as an add-on module to the existing telephony gateways. 9 Comparison of three different proposals We have found two other proposals [9,10] submitted as IETF drafts to the AVT group. We have compared our proposal with others in terms of known performance metrics. Table 4 summarizes the results of the comparison. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + + Nokia + Lucent + Hitachi+ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + + + + + +Reducing overhead + Very good + Very good + ok + + + + + + +Bandwidth efficiency+ Very good + Very good + ok + + + + + + +Additional header + yes + yes + Not known+ + + (2 bytes/pkt) + (2 bytes/pkt)+ + + + + + + +Assembly and + Simple + Hard + Simple + +de-assembly + + + + + + + + + +Max # of users + + + + +for multiplexing + 256 + 256 + Not known+ + + + + + +Mini packet size + Variable + Variable + Variable + + + (0 ~64) +(req. known + + + + + profiles) + + + + + + + +Channel association + Required + Required + Required+ +(signaling) + + + + + + + + + +Padding mux + Not required + Required + Not req + +header + + + + + + + + + +Multiplex timer + Proposed + Not proposed + Not prop + + + + + + +Dynamic capability + Possible + Not possible + Not poss + + exchange + + + + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Table 4. Comparison of different approaches on user multiplexing in RTP payload B. Subbiah, S. Sengodan [Page 15]
Internet Draft Aug 15, 1998 10 Conclusion A new method to multiplex speech samples from a number of users in a RTP payload is proposed. It is shown that this method reduces the overhead for small packets, improves the bandwidth efficiency, lowers the chances for congestion at intermediate IP routers and enhances the scalability of the gateways. A new control signaling procedure to negotiate a channel between peer gateways is also proposed. The advantages of this method justify the need for such a mechanism between gateways that interconnect PSTN and GSM users. 11 Full Copyright Statement Copyright (C) The Internet Society (1998). 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 Soci- ety 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 fol- lowed, 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 MER- CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 12 Authors' Addresses Barani Subbiah, Senthil Sengodan Nokia Research Center 3 Burlington Woods Dr., Ste. 260 Burlington, MA - 01803, USA baranitharan.subbiah@research.nokia.com senthil.sengodan@research.nokia.com B. Subbiah, S. Sengodan [Page 16]
Internet Draft Aug 15, 1998 13 Bibliography [1] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, RTP: a transport protocol for real-time applications, Request for Comments(Proposed Standard) 1889, Internet Engineering Task Force, Jan. 1996. [2] International Telecommunication Union, Coding of speech at 8 kbit/s using conjugate-structure algebraic-code-excited linear- prediction, Recommendation G.729, Telecommunication Standardi- zation Sector of ITU, Geneva, Switzerland, Mar. 1996. [3] H. Schulzrinne, RTP profile for audio and video conferences with minimal control, Request for Comments (Proposed Standard) 1890, Internet Engineering Task Force, Jan. 1996. [4] ITU-T Recommendation G.723.1 (1995) "Dual Rate Speech Coder For Multimedia Communications Transmitting At 5.3 And 6.3 kbit/s" [5] ITU-T Recommendation H.225.0 (1998): " Media Stream Packetization and Synchronization for Visual Telephone Systems on Non-Guarant- eed Quality of Service LANs ". [6] ITU-T Recommendation H.245 (1998): "Control of communications between Visual Telephone Systems and Terminal Equipment". ITU-T Recommendation H.246 (1998) "Interworking of H.series multimedia terminals" [7] ITU-T Recommendation H.323 (May, 1996): Visual Telephone Systems and Equipment for Local Area Networks Which Provide a Non-Guara- nteed Quality of Service. [8] ITU-T Recommendation H.323 (January, 1998): Packet Based Multi- media Communications Systems [9] J. Rosenberg and H. Schulzrinne: An RTP payload format for user multiplexing, IETF draft, work in progress, May 1998. [10] K. Tanigawa, T. Hoshi and K. Tsukada: A RTP simple multiplexing transfer method for Internet telephony gateway, IETF draft, work in progress, June 1988 [11] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg: SIP: Session Initiation Protocol, IETF draft, work in progress, July 1998. B. Subbiah, S. Sengodan [Page 17]
