Architecture and Design of an enhanced H.323 VoIP Gateway

Size: px

Start display at page:

Download "Architecture and Design of an enhanced H.323 VoIP Gateway"

Linda Riley
6 years ago
Views:

1 Architecture and Design of an enhanced H.323 VoIP Gateway T. Dagiuklas and P. Galiotos Development Programmes Department INTRACOM S.A. Markopoulo Avenue Athens GREECE Abstract- This paper presents the architecture and design of an enhanced VoIP gateway, which is based on the H.323 protocol. The key characteristics of this gateway include: scalability separating signaling from media transformation and use of protocols such as MGCP/MEGACO for the communication between signaling part and media gateway; lightweight by using SCTP transport protocol to convey H.323 and MGCP/MEGACO signaling and QoS support through the control of the voice encoding of the VoIP connections. This control is accomplished by estimating the network load and enforces the voice connections to modify the encoding scheme according to the estimated network load. Indexing Terms: IP Telephony, VoIP, H.323 I. INTRODUCTION It is anticipated that the volume of data traffic will exceed that of voice in the near future due to the Internet explosion. This explosion will have a great impact in the operation of both telecommunication operators and Internet Service Providers. Large parts of the today s voice dominated networks will be replaced by IP-based data networks where a number of existing (e.g. voice, Internet access) and future services (e.g. multimedia) will be provided to the end-user. However, this transition towards a data type of networks will be smoothly rather revolutionary [1], [2]. During the past years both the traditional circuitswitched networks and the emerging IP data networks, deployed throughout the world, have been considered as two separate worlds [1], [2]. These worlds have started to converge by examining the possibility of offering voice services over the Internet (VoIP). VoIP offers not only advanced voice services but it provides means of connectivity to the existing voice networks. The first generation of VoIP gateways has been based on proprietary solutions that lack scalability features and they suffer from interoperability problems [1], [2]. This paper presents the architecture and the design of an enhanced next generation gateway using H.323 protocol suite. The key features of the enhancements include scalability, lightweight and QoS support. The scalability is accomplished by separating media transformation (MG- Media Gateway) from signaling (MGC-Media Gateway Controller) and employ protocols such as MGCP/MEGACO for the communication between MGC and the MG. Lightweight has been carried out by using SCTP protocol to convey signaling information. Besides, SCTP offers a great improvement in call-setup duration and reduces the delay between the exchange of all signaling messages (referring especially to the Q.931, H.245 and also the MGCP protocol. Finally, QoS of the VoIP connections is handled at the application layer. The MGC runs a QoS management entity, which estimates the network load. When the network traffic reaches a threshold, some users will be forced to switch to a lower quality codec, without interrupting their calls. The paper is organized as follows: Section 2 describes the architecture of the enhanced VoIP Gateway; Section 3 presents the MGC Architecture, use of SCTP with H.323 and MGCP signaling and detailed analysis of the QoS Management Module; Section 4 presents the architecture of the MG and conclusions are given on section 5. II. ENHANCED H.323 VOIP GATEWAY ARCHITECTURE The main characteristics of the proposed decomposed VoIP Gateway are the following: 1. H.323 and VoIP: H.323 is a protocol suite used to deploy VoIP networks and offer valued-added services to the end-users. H.323 is a suite of standards that have been adopted by ÿ U for real-time multimedia communication, in LANs and the Internet [11]. The standard covers both singlepoint and multipoint communications. More specifically, þ.323 defines the following protocol suite for multimedia communications [11]: H.245 for control, H for connection establishment, H.332 for large conferences, H.450.x which refers to all the additional services offered by H.323. Additionally, þ.323 can be used with Internet Protocols such as TCP, UDP, RTP, RTCP and RSVP. Furthermore, Q.931 is used for call signaling. This can be accomplished by implementing Q.931 over TCP. The main reasons of adopting the H.323 technology [3] to implement the VoIP gateway, are the following: H.323 has been deployed and tested successfully in wide area networks, large private VoIP networks, and the Internet H.323 was an early adopter of such IETF protocols as RTP, which proved its ability to carry real-time audio and video over IP networks that span the globe

2 Although H.323 is a richly feature protocol suite, it introduces large overhead and it does not scale well over large networks. However, H.323 evolution introduced new features such as Security, Fast Connect, Supplementary services and Scalability features 2. Scalability: In this architecture, the media transformation functions are separated from the gateway control function. The gateways are responsible for the media transformation. All the signalling information is handled from dedicated devices, which are called Call Agents or Media Gateways Controller. Such an architecture is illustrated in the following figure 1. The communication between MG and MGC is carried out using one of the protocols that have been proposed for decomposed architectures (e.g. MGCP, MEGACO/H.248) [9]. This also necessitates the interworking between the MGCP/MEGACO and H.323. H.323 Signalling Control Protocol MGCP/MEGACO H.323 Media MGC MG MG MG Figure 1: VoIP Decomposed Architecture 3. Lightweight: In H.323, TCP is employed as to carry out signalling messages. Although TCP is a reliable protocol, it introduces large overheads, which deteriorate signalling performance. Besides, it is strictly oriented to sequencing delivery and continuous retransmissions, which are not always needed in the way TCP implements them. For this purpose, IETF SigTran WG [7] has standardized a new protocol (SCTP-Scream Control Transport Protocol) for the transmission of signalling information in IP-based networks. In the proposed VoIP gateway, SCTP is used to transmit H.323 signalling (H.225-Q.931 and H.245 messages). 4. Use of QoS mechanisms to improve the voice quality: A QoS Management entity runs on the MGC. This entity estimates the network load under the zone of the VoIP gateway as well as the R-factor proposed by the ITU-T [5]. It extracts useful information (packet count, octet count, interarrival jitter, packet loss, NTP timstamp) from the RTCP packets and monitors the present situation of the Network and of each separately. Once the network load reaches at a certain level, the voice connections are instructed to employ a higher voice compression scheme, leading to the reduction of the generated bits. Figure 2 illustrates the architecture of the enhanced VoIP Gateway. MGC/Call Agent MGCP-H323 Interworking H.225 H.225 H.245 RAS Q.931 UDP SCTP IP QoS Management RTCP MGCP Server CPU Internet Call Handler MG DSPs Multiple Voice Codecs (G.711, G.723, G.726) µp8260 Scheduler C-RTP MGCP MGCP-Q.931 Client Interworking UDP SCTP E1 PSTN Figure 2: Enhanced H.323 VoIP Gateway Architecture III. MGC ARCHITECTURE The MGC is responsible for all the related signalling functionalities and comprises of the following elements: 1. SCTP Engine: It is a new transport protocol used to carry out H.225 and H.245 signalling as well as MGCP commands 2. H.225 (RAS) using the UDP transport 3. Use of the MGCP protocol for the communication between the MGC and the MG 4. QoS Management module: This module estimates the network load under the zone of the Gateway. Once the estimated network load reaches the threshold, the gateway instructs the active voice connections to employ a higher compression scheme (e.g. switch from G.711 to G.727) 5. Interworking Module: A software module capable of providing H.323 to MGCP interworking services. It receives the MGCP commands with the parameters and translates them to H.323 messages with the essential primitives and vica versa. A. SCTP SCTP is an RFC protocol, standardized by IETF in order to transport PSTN signaling over IP-based networks [6]. SCTP is a reliable transport protocol and it runs over connectionless packet-based network like IP. It provides acknowledged, error-free but also non-duplicated transfer of user data, supports data fragmentation and sequenced delivery of user messages within multiple streams. It also gives the capability of building optionally, multiple user messages into a single SCTP packet. Stream in SCTP [7] is defined as a sequence of user messages that are to be delivered to the upper layer, while in TCP the stream is made off a sequence of bytes. The sequence in SCTP is guaranteed by assigning a stream sequence number to each message. The receiver can then receive several streams in parallel and sequentially, in case

3 one of them blocks waiting for the next sequenced message. SCTP has a chunk bundling function, to request bundling of more than one user messages into a single SCTP packet [7]. This function may operate even if the user has not requested it, during times of congestion. SCTP provides a Verification Tag field and a 32-bit checksum field in its header. The first one is chosen by each endpoint during the association startup and provides protection against masquerade attack and stale SCTP packets from a previous association. The bit-checksum field provides protection against data corruption in the network. B. SCTP Sockets The use of SCTP necessitates the introduction of new sockets that will implement the well-known Berkley Socket functions like: socket, bind, setsockopt, recvmsg, sendmsg and close [7]. So when for example, one calls the socket function, the essential parameters are: PF_INET, remain the same since we still to an Internet Protocol (IP) family of addresses SOCK_SEQPACKET, since we do not use the TCP streaming socket anymore, but a sequence of packets (chunks) for the SCTP IPPROTO_SCTP, that defines the protocol (SCTP) which will implement the communication on the channel Note that we adopt the PF_INET parameter as the parameter that should be firstly passed in the socket command and characterizes the Protocol Family. In this way, the protocol used (TCP, UDP, SCTP) can be distinguished by the way the data is transmitted e.g. SOCK_SEQPACKET for STCP and SOCK_DGRAM for UDP. However we keep using the AF_INET parameter when we want to characterize the Address Family e.g. to give a value to the sin_family element of the sockaddr_in structure. C. H.323 and SCTP In the original H.323 implementation, TCP was used as the transport layer for the signaling part of H.323, specifically for the Q.931 and H.245 protocols. However, TCP has several limitations [4]. For example, it offers very strict order of transmission for delivery of data. This is not always essential or is partially requested. In those cases, using TCP can cause unnecessary delays with a great amount of acknowledges, retransmissions and duplicated packets. Besides the stream oriented nature of TCP can cause some kind of inconvenience when trying to mark the message s boundaries or when dealing with the transfer time. Moreover to that, TCP is quite vulnerable to denial of service attacks, and its sockets are not capable of providing highly available data transfer capability using multi-homed hosts. In contrast with TCP, SCTP offers reliable transfer of user messages between peer SCTP users. SCTP is connection oriented in nature. The SCTP endpoint provides the other endpoint (during the association startup) with a list of transport addresses e.g. multiple IP addresses in combination with an SCTP port, where the endpoint originates and accepts data. Note that, the association in SCTP bears the same meaning with the connection in TCP. During the association, a cookie mechanism is employed, to provide protection against security attacks. SCTP also differs from TCP, in that it does not allow a half open-state, where although the one side is closed, the other continues to send data. In SCTP, when the endpoint shuts down, the other one (in a peer-topeer connection) will stop accepting new data. D. Use of MGCP In the proposed architecture, particular emphasis has been given to the use of MGCP due to the fact that it is more stable and mature than MEGACO. The MGCP Server at the MGC receives the capabilities, which have been defined during the association of the IP Terminal and the VoIP Gateway (H.245 negotiations). MGCP is mainly used for the control of telephony gateways from external call control elements [9]. MGCP currently uses UDP transport to convey MGCP commands. The advantages of SCTP use when carrying signaling make it also appropriate for carrying the MGCP signals in the VoIP System. The scope is again the better performance in parallel with the reliability and the avoidance of retransmission and duplicated packets. In the proposed architecture, the following MGCP Commands are mostly used for the communication between MG and MGC: ƒ MGCP Create : Once the H.245 has been completed, the MGCP must be triggered to inform the MGC about the creation of a new voice channel. The following primitives must be included as a parameters: 1. Call ID: This parameter must be provided by H.225- Q EndPoint ID: This identifier for the connection endpoint in the MG where the command is executed. 3. Local Options which provide the following information to the MG: Encoding Method (e.g. G.711, G.727, G.723), Packetization Period, Use of Silence Supression, Use of echo cancellation 4. Mode: It indicates the mode of operation for this side of the connection. Supported modes include send, receive, etc 5. Remote: It contains elements that are provided by the H.245 engine (session description). MGCP Modify : This command is triggered by the QoS Management module to send a command towards the MG in order to instruct the DSPs at the MG to generate less bits by employing a higher compressed voice encoding scheme (e.g. switch from G.711 to G.727). This command contains the following primitives 1. Call ID: Same as in the MGCP Create 2. EndPoint ID: Same as in the MGCP Create 3. ID: This ID must be provided by the MGCP client, after the initialisation of the connection. Its scope is to uniquely identify the connection, within the context of an end-point. 4. Local Options, Mode, Remote, etc.

4 ƒ MGCP Delete : As its name implies, this command is used to terminate a connection and inform the MG to release the appropriate resources at the DSP. This command contains the following primitives: 1. Call ID: Same as in the MGCP Create 2. EndPoint ID: Same as in the MGCP Create 3. ID: Same as in the MGCP Create Each of the above commands forces the Endpoint to send back a response that may carry several response parameters similar to those that were sent with the commands. These parameters are very useful to the Server and the Client as they provide all the necessary details about the ongoing connection. To give just an example such parameters are the followings: ResponseAck, CallID, ObservedEvents etc. There is a set of 26 parameters. Their use in each command can be mandatory, optional or forbidden. The differences depend on whether they are sent in a command or a response. The handling of our connections depends on the information carried by these parameters. Figure 3 illustrates the complete protocol stack for the MGC. H.225.0/RAS UDP H.225.0/Q.931 Call Signalling IP H.245 Media Control SCTP Figure 3: Protocol Stack in the MGC MGCP E. QoS Management The QoS Management Module is a software entity, specially designed to control the quality of each voice connections. This quality can also be predefined in a possible scenario where the users have prepaid for a certain quality during their use of the VoIP System. The QoS module resides in the Application Layer of the protocol stack at the MGC. Its functionality is to grab the RTCP packets, extract the essential values from some fields and attach the carried values to certain formulas in order to estimate the end-to-end delay, the jittering, packet loss, in order to predict congestion network levels. The RTCP packet fields used by the QoS Management module are the following: NTP Timestamp, RTP Timestamp, Packet loss, Interarrival jitter, Sender s Packet Count, Octet Count. Note that the packets are distinguished into two categories, the Sender and the Receiver Report packets, according to whether the source has sent RTP packets or has just received. The QoS Management module firstly calculates the R-factor and then the Network Load using the Network Load Estimation (NLE) [12]. Based on the following table, it takes the appropriate decisions that can either use a higher compression scheme to operate in a very congested network or to upgrade the quality of the connection by adopting a codec that provides higher quality. The following table presents all the well-defined categories: Service Category Best High Medium Low Poor TABLE I R-factors for the corresponding VoIP Service Categories Encoding Scheme G.711 (64Kbps) G.727 (40Kbps) G.727 (32Kbps) G.727 (16Kbps) G.728 (8Kbps) Network Load 70% 80% 90% 100% R-factor 90 < R < < R < < R < < R < < R < 60 In the same time, the QoS Management module determines the expected VoIP QoS for each connection separately. The calculations are based on the ITU-T s E-Model [4]. The R factor ranges from 0 to 100, depends on the echo, the background noise, the signal loss, the codec impairments and is calculated from the following formula: R=100-Is-Id-Ief+A where Is is the signal-to-noise impairments associated with typical SCN paths, Id is the impairment associated with the delay of the path and Ief is an equipment impairment factor associated with losses within the gateway and A is the expectation factor covering those intangible quantities that are difficult to quantify. For the sake of simplicity, according to the ITU-T G.107 recommendation, this equation can be simplified as follows [3]: R = d (d-177.3)*H(d-177.3)-Ie The proposed algorithm for the QoS Management Module is shown in the following figure. Note that d is the one-way delay time and H is either 0, when the value in parentheses is evaluated negative, or 1 for a non-negative value [2]., <(7 9$/,' GURSRXW DIWHU PLQ & VHTXHQFH QXPEHU QXPEHU RI VHTXHQWLDO SNWV 0,1B6(48(17,$/! QXPEHU RI VHTXHQWLDO SNWV 0$;B6(48(17,$/ 9$/,' 0$;B' VHTXHQFH QXPEHU DQG 0$;B0,625'(5 VHT V!PD[BVHT 127 9$/,' FOHDU DOO '$7$ V!F\FOHV QXPEHU FXPXODWLYH RI SNWV ORVW 57&3 665& VHHQ EHIRUH G 173/65'/65 G 0$;B'HOD\+236 'B)DFWRU G +G +G 5$7( / 5 GG+G 5B)DFWRU 5 /BSNWVBORVW FXPXODWLYH RI SNWV ORVW QRZ SUHY /BIUFWBORVW IUDFWLRQ ORVW QRZ SUHY -LWWHU! MD N /BSNWVBORVW /B)DFWRU /BIUFWBORVW N/BSNWVBORVW 'B)DFWRU 5B)DFWRU /B)DFWRU!!!! UDWH N /BSNWVBORVW Figure 4: QoS Management Module Function To give just an example, once the network load drops at low level and the R-factor has fallen below the ordinary levels, the voice connections employ a higher quality voice-

5 encoding scheme to compensate for quality distortion during the congested periods. IV. MEDIA GATEWAY ARCHITECTURE The MG implements the media transformation of the voice connection. The MG comprises of an Ethernet/VoIP Board embedded architecture and contains the following functionalities: 1. A scheduler mechanism, which runs in the microcontroller and is responsible for the management of the DSP resources. The scheduler handles the allocation and de-allocation of the DSP resources during the request of call activation and de-activation respectively. 2. MGCP Client that receives commands from the MGC and responds accordingly. 3. Use of SCTP as a transport protocol for the MGCP 4. RTP/C-RTP packetisation schemes A. Scheduler Schedule s operation is quite simple as it co-operates with the QoS Management Entity. It instructs each DSP about the codec that will be used and the connection that it will serve. Moreover to that, it is able to monitor each DSP s payload every moment so that not to demand extra processing power from an already overloaded DSP. In general, the Scheduler will carry out the following tasks: Co-operate with the QoS Management, Communication with the DSPs, Allocate the appropriate resources for each new connection, Re-allocate the DSP resources by modifying the connection characteristics B. MGCP Client In response to each MGCP command, the MGCP replies using the return codes with all the essential parameters [9], e.g: ƒ Return Code for the Create Command (CRCX): The only mandatory parameter is the Local Descriptor (with the code LC), which is an SDP session descritpor containing the IP address and the port number where the endpoint is expecting to receive data and also the format of that data. ƒ Return Code for the Delete Command (DLCX): It includes several statistical parameters such as: average latency, average jitter, number of packets sent, number of packets received, number of lost packets. ƒ Return Code for the Modify Command (MDCX): This response to Modify consists of only one optional parameter, which is the local connection descriptor that has already been presented. for the communication between MGC and MG. Lightweight is accomplished through the use of the SCTP to carry all the signalling information (H.225/Q.931, H.245 and MGCP). In this way the bandwidth spent in retransmissions or duplicated packets is also minimized. The QoS support of the voice connections is controlled by an entity, which estimates the network load. When the network load reaches a certain threshold, the MGC instructs the MG to modify the encoding parameters of the voice connections by switching to higher compressed voice-encoding scheme. ACKNOWLEDGMENT This work has been conducted under the NETGATE IST project (IST ). The European Commission is gratefully acknowledged for partly funding the NETGATE project by the IST Programme. REFERENCES [1] IEEE Network Magazine, Special Issue on Internet Telephony, May [2] IEEE Communications Magazine, Special Issue on Internet Telephony, April [3] R. Cole and J.H. Rosenbluth, Voice over IP performance monitoring, ACM Computer Communications Review, Vol. 31, April 2001 [4] H. Liu and P. Mouchtaris, VoIP Signaling: H.323 and Beyond, IEEE Communications Magazine, October [5] ITU-T Recommendation G.107, The E-Model, a computation model for use in transmission planning, December [6] ITU-T Recommendation P.861, Objective quality measurement of telephone-band speech codecs, August [7] IETF RFC 2960, Stream Control Transmission Protocol, October 2000 [8] ITU-T Recommendation H.225.0, Call Signaling protocols and media stream packetization for packetbased multimedia communication systems, September [9] IETF RFC 2705, Media Gateway Control Protocol (MGCP), Version 1.0, October 1999 [10] IETF RFC 2508, Compressing IP/UDP/RTP Headers for Low-Speed Serial Links, February 1999 [11] Daniel Collins, Carrier Grade Voice Over IP, McGraw-Hill Professional Telecom [12] P. Galiotos, T. Dagiuklas, QoS Management for an Enhanced VoIP Platform using R-factor and Network Load Estimation Functionality, has been submitted for presentation at HSNMC 02, January 2002 V. CONCLUSIONS This paper presents the architecture of an enhanced H.323 VoIP gateway. The key enhancements of the gateway include scalability, lightweight and QoS support. Scalability is achieved by separating media transformation from the signaling and use protocols such as MGCP and MEGACO

Stream Control Transmission Protocol (SCTP)

Stream Control Transmission Protocol (SCTP) Definition Stream control transmission protocol (SCTP) is an end-to-end, connectionoriented protocol that transports data in independent sequenced streams. SCTP