DOCSLIB.ORG

Installation and Configuration of H.323 Gatekeeper Best Practice Document

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Installation and Configuration of H.323 Gatekeeper Best Practice Document Installation and configuration of H.323 Gatekeeper Best Practice Document Produced by the AMRES/RCUB-led Multimedia – VoIP working group Author: Ognjen Milosavljevic (RCUB) April 2016 © AMRES, 2016 © GÉANT, 2016. All rights reserved. Document No: GN4-1-NA3-T2-AMRES-BDP-116 Version / date: V1.2 / 20-04-2016 Original language : Serbian Original title: “Instalacija i konfiguracija H.323 Gatekeeper-a” Original version / date: Version 1 / 8. December 2014 Contact: [email protected] AMRES/RCUB is responsible for the contents of this document. The document was developed by the AMRES Multimedia – VoIP (AMRES BPD 116 topic) working group. Parts of the report may be freely copied, unaltered, provided that the original source is acknowledged and copyright preserved. The research leading to these results has received funding from the European Union’s Horizon 2020 research and innovation programme under Grant Agreement No. 691567 (GN4-1). Table of Contents 1 Executive Summary 1 2 A Description of the H323 Technology 2 2.1 H.323 2 2.2 H.323 Gatekeeper 4 2.3 Global Dialling Scheme (GDS) 7 3 A Description of the Solution 9 3.1 The National Gatekeeper 9 3.2 The NREN Gatekeeper 10 3.3 The Institutional Gatekeeper 11 4 Installing the GNU Gatekeeper 12 5 Configuring the Gatekeeper 13 5.1.1 The National Gatekeeper 13 5.1.2 The NREN Gatekeeper 16 5.1.3 The Institutional Gatekeeper 19 5.2 Configuring the iptables Tool 20 Appendix A GNU-GK installation script 21 References 27 Glossary 28 Deliverable Best Practice Document: Installation and configuration of H.323 i Gatekeeper Contents Table of Figures Figure 2.1: Logical elements in the H.323 environment (the figure taken from [1]) 2 Figure 2.2: Routing the call signalling through the gatekeeper 6 Figure 2.3: Calling a terminal from another zone 6 Figure 2.4: Hierarchy in the GDS network 8 Figure 3.1: Structural scheme of the design 9 Best Practice Document: Installation and configuration of H.323 ii Gatekeeper 1 Executive Summary This paper describes the theoretical basis of the H.323 protocol with the aim of presenting a solution for the software implementation and integration of H.323 Gatekeeper into the existing infrastructure of the Academic Network of Serbia (AMRES). A gatekeeper is the central controlling device in the H.323 environment and includes functions such as admission control, translation of H.323 addresses to IP addresses, bandwidth control, zone management, call control and additional services during the call. The gatekeeper can also serve as a proxy server, i.e. the entire traffic between the endpoints (terminals) participating in the communication can be routed through the gatekeeper for security or quality control purposes. Summary (in Serbian) U ovom radu je opisana teorijska osnova H.323 protokola, sa ciljem predstavljanja rešenja za implementaciju i integraciju H.323 gatekeeper-a u postojeću infrastrukturu Akademske mreže Srbije (AMRES). Prikazana je izabrana softverska implementacija rešenja za gatekeeper. Best Practice Document: Installation and configuration of H.323 1 Gatekeeper 2 A Description of the H323 Technology This section describes the technologies that are necessary for understanding the configuration of the gatekeeper. A short overview of the H.323 protocol is presented, with a special emphasis on the H.323. gatekeeper. The description also includes the hierarchy of the GDS (Global Dialling Scheme) and information on GDS numbering. 2.1 H.323 H.323 is a recommendation of the ITU-T (ITU Telecommunication Standardisation Sector), the body that defines protocols for audio-visual communication in IP-based networks. H.323 defines several logical elements shown Figure 2.1, and their roles are explained below: Figure 2.1: Logical elements in the H.323 environment (the figure taken from [1]) • H.323 Gatekeeper is the central controlling device in the H.323 environment, which includes a set of functionalities such as admission control, translation of H.323 addresses to IP Best Practice Document: Installation and configuration of H.323 2 Gatekeeper A Description of the H323 Technology addresses, bandwidth control, zone management, call control, additional services during the call, etc. Besides this, the gatekeeper can also act as a proxy server, i.e. the entire traffic between the endpoints (terminals) participating in the communication can be routed through the gatekeeper for security or quality control purposes. • H.323 Terminal is an H.323-compatible user device accessing the H.323 network in order to establish a video conference call. This can be achieved by way of software, i.e. as a program installed on a certain computer, or by way of hardware, in the form of a separate device (e.g. an H.323 video conference device). The terminals have their respective identifications in the form of a username and password and/or number, whereby they are uniquely identified on the H.323 network. • H.323 MCU (Multipoint Control Unit) is a combination of an MC (Multipoint Controller) and an MP (Multipoint Processor) within one device and it is used for establishing conference calls involving more than two clients. • MC (Multipoint Controller) is a device that connects the signalling channels of two or more H.323 terminals in a star-shaped fashion. The MC performs the negotiation process about the audio-visual capabilities of the H.323 terminals in order to maintain the best possible communication. Also, the MC controls resource consumption during a multicast video conference. Besides the MCU, an MC can be used as part of any H.323 device (terminal, gateway, gatekeeper), and it can be implemented as a separate device. • MP (Multipoint Processor) serves for receiving and processing audio-visual data from individual endpoints, and for sending the data to other endpoints. The MP performs the conversion between different codecs and bandwidths. • H.323 Gateway is a device that connects the H.323 environment with other protocols and/or networks, such as ISDN, PSTN, ATM and other telephone networks. The following three control protocols are used for the communication between the components within the H.323 environment: • H.225.0 RAS (Registration, Admission and Status) - this control protocol is used for communication between the endpoints and the gatekeeper, and for communication between different gatekeepers. The endpoints rely on RAS for registering with the gatekeeper, for requesting permission to use the system resources, to send requests for the IP address translation of another endpoint etc. The gatekeeper uses RAS for maintaining the list of registered endpoints and for gathering the resource information at the end of the call. RAS provides a user authentication and call authorisation mechanism. • H.225.0 Call Signalling - this channel serves for establishing calls and for messages such as ringing, successfully established or failed connections, and for additional services during the call. These messages are derived from the Q.931 signalling (IDSN call signalling), but the procedure is simplified and only a subset of the messages is used. The signalling can be performed directly between the endpoints as well as through one or more gatekeepers. • H.245 Conference Control - this channel is used for controlling the audio-visual format. It enables two or more participants in the conference to agree on a multimedia format that will be understood by all the participants. This concerns the compression, decompression and auto-configuration of multimedia content between the users. The control of the audio-visual format can be performed directly between the endpoints (terminal-terminal, terminal-MCU), as well as through one or more gatekeepers. Best Practice Document: Installation and configuration of H.323 3 Gatekeeper A Description of the H323 Technology The audio-visual content is directly exchanged between the endpoints and the following two protocols are used for that purpose: RTP (Real Time Protocol) and RTCP (Real Time Control Protocol). An RTP session is established for each multimedia content separately. The session contains an IP address and a pair of ports, the one port for the RTP, and the other port for the RTCP. According to the specification under Reference [2], the RTP port should be an even number, while a larger odd number should be used for the RTCP. Available UDP ports (1024-65565) are usually used for that. The RTP uses the UDP protocol to establish a number of connections between two points. The RTP header contains the ordinal number of the packet, the time of its creation, the source that generated the packet, etc. The RTCP contains the information on data quality, the number of listeners, the identification of listeners and senders, etc. Moreover, the SRTP (Secure RTP) can be used for additional data security. There are several types of H.323 addresses, i.e. several ways in which endpoints can be identified in the H.323 environment. They include E.164 numbers, H.323 URLs having the h323:[email protected] structure, various symbolic names, and IP addresses. 2.2 H.323 Gatekeeper As noted above, the gatekeeper is the central control and management device in the H.323 environment. According to the ITU-T H.323 recommendations, the gatekeeper should enable the following: • Address translation. • Admission control. • Bandwidth control. • Zone management. • Call control signalling. • Call authorisation. • Bandwidth control • Call management. The most common way of setting up the client device for a gatekeeper is through a static configuration of the IP address, which is the default manner referred to in this paper. Another way of configuration involves sending multicast messages to the 224.0.1.41 address in order to find the gatekeeper. Signalling messages can be sent directly between the endpoints or through the gatekeeper. In the first case, the gatekeeper cannot monitor the course of the call because the signalling, or part thereof, does not go through it, while in the second case the gatekeeper can control the entire course of the call, or parts thereof, depending on the signalling messages that pass through it.
Load more

Recommended publications
  • IP Telephony Cookbook
    IP Telephony Cookbook Dr. Margit Brandl, Dimitris Daskopoulos, Erik Dobbelsteijn, Dr. Rosario Giuseppe Garroppo, Jan Janak, Jiri Kuthan, Saverio Niccolini, Dr. Jorg¨ Ott, Stefan Prelle, Dr. Sven Ubik, Egon Verharen March 9, 2004 Contents 1 Introduction 11 1.1 Goal . 11 1.2 Reasons for writing this document . 11 1.3 Contents . 11 1.4 How to read this document . 12 1.5 Techno-economic aspect of moving from classic telephony to VoIP . 12 2 Technology Background 15 2.1 Components . 15 2.1.1 Terminal . 15 2.1.2 Server . 15 2.1.3 Gateway . 15 2.1.4 Conference Bridge . 16 2.1.5 Addressing . 16 2.2 Protocols . 16 2.2.1 H.323 . 16 2.2.1.1 Scope . 17 2.2.1.2 Signaling protocols . 18 2.2.1.3 Gatekeeper Discovery and Registration . 20 2.2.1.4 Signaling models . 21 2.2.1.5 Communication Phases . 24 2.2.1.6 Locating zone external targets . 28 2.2.1.7 Sample Call Scenario . 29 2.2.1.8 Additional (Call) Services . 29 2.2.1.9 H.235 Security . 30 2.2.1.10 Protocol Profiles . 31 2.2.2 SIP . 31 2.2.2.1 Purpose of SIP . 31 2.2.2.2 SIP Network Elements . 32 2.2.2.3 SIP Messages . 34 2.2.2.4 SIP Transactions . 38 2.2.2.5 SIP Dialogs . 38 2.2.2.6 Typical SIP Scenarios . 40 2.2.3 Media Gateway Control Protocols . 43 2.2.4 Proprietary Signaling Protocols . 45 2.2.5 Real Time Protocol (RTP) and Real Time Control Protocol (RTCP) .
    [Show full text]
  • Universidad Católica Andrés Bello Facultad De Ingeniería Escuela De
    Análisis y diseño de un sistema de telefonía IP basado en software libre a través de softswitch con priorización de voz Caso empresa SERVIMECA, C.A. Universidad Católica Andrés Bello Facultad de Ingeniería Escuela de Ingeniería de Telecomunicaciones Análisis y diseño de un sistema de telefonía IP basado en software libre a través de softswitch con priorización de voz Caso empresa SERVIMECA, C.A. UNIVERSIDAD CATÓLICA ANDRÉS BELLO Como parte de los requisitos para optar al título de INGENIERO EN TELECOMUNICACIONES EFECTUADO POR: Daniel Prado TUTOR Ing. Wilfredo Torres Caracas, 13 de Febrero de 2012 Página I Análisis y diseño de un sistema de telefonía IP basado en software libre a través de softswitch con priorización de voz Caso empresa SERVIMECA, C.A. Universidad Católica Andrés Bello Facultad de Ingeniería Escuela de Ingeniería de Telecomunicaciones Análisis y diseño de un sistema de telefonía IP basado en software libre a través de softswitch con priorización de voz Caso empresa SERVIMECA, C.A. EFECTUADO POR: Daniel Prado TUTOR Ing. Wilfredo Torres Caracas, 13 de Febrero de 2012 Página II Análisis y diseño de un sistema de telefonía IP basado en software libre a través de softswitch con priorización de voz Caso empresa SERVIMECA, C.A. ANÁLISIS Y DISEÑO DE UN SISTEMA DE TELEFONÍA IP BASADO EN SOFTWARE LIBRE A TRAVÉS DE SOFTSWITCH CON PRIORIZACIÓN DE VOZ CASO EMPRESA SERVIMECA, C.A. Prado, Daniel [email protected] El presente trabajo busca dar solución a la actual situación de SERVIMECA, C.A la cual factura grandes cantidades de dinero en llamadas, a través de una plataforma de telefonía IP cuyo objetivo principal es “Diseñar un Sistema de Telefonía IP basado en software libre para la interconexión de usuarios en las sedes de SERVIMECA C.A, optimizando el tráfico de voz con mecanismos de Calidad de Servicio” permitiendo reducir los costos manteniendo una calidad equivalente al sistema anterior y añadiendo nuevas características, lo que lo convierte en una excelente oportunidad de negocio bajo una buena administración.
    [Show full text]
  • User's Manual
    User’s Manual Table of Contents TABLE OF CONTENTS 222 PREFACES 444 0.10.10.1 AAABOUT TTTHIS MMMANUAL 4 0.20.20.2 CCCOPYRIGHT DDDECLARATIONS 4 0.30.30.3 TTTRADEMARKS 4 0.40.40.4 SSSAFETY IIINSTRUCTIONS 4 0.50.50.5 WWWARRANTY 4 INTRODUCE 555 1.11.11.1 OOOVERVIEW 5 1.21.21.2 AAACRONYMS TTTABLE 5 1.31.31.3 IIINTRODUCTION 6 1.41.41.4 FFFRONT PPPANEL LED IIINDICATORS &&& RRREAR PPPANELS 7 1.4.1 VVVOOOIPIPIP GGGATEWAY OOOUTLOOK 777 1.4.2 FFFRONT PPPANEL LED AND CCCONTAINER DDDESCRIPESCRIPTIONSTIONS 777 1.4.3 RRREAR PPPANEL DDDESCRIPTIONS ERROR ! BOOKMARK NOT DEFINED . 1.51.51.5 FFFEATURES AND SSSPECIFICATIONS 13 1.5.1 VVVOOOIPIPIP GGGATEWAY FFFEATURES 131313 1.5.1.5.2222 VVVOOOIPIPIP GGGATEWAY SSSPECIFICATION 141414 INSTALLATION AND SETUP 151515 2.12.12.1 PPPACKAGE CCCONTENT 15 2.1.1 S200/S400 SSSERIES GGGATEWAY 161616 2.1.2 S800 SSSERIES GGGATEWAY 171717 2.1.3 SB800/S1600/S2400 SSSERIES HHHIGH DDDENSITY GGGATEWAY 181818 2.22.22.2 IIINSTALLATION 18 2.32.32.3 SSSETUP 19 2.3.1 FFFACTORY DDDEFAULT SETTING 191919 2.3.2 CCCONSOLE 202020 2.3.3 TTTELNET 212121 2.3.4 WWWEB UUUSER IIINTERFACE 242424 WIZARD FOR QUICK SETUP 272727 2 3.13.13.1 WAN PPPORT TTTYPE SSSETUP 27 3.23.23.2 CCCONFIGURING NAT OR BBBRIDGE SETTING ::: 29 3.33.33.3 VVVOOOIPIPIP CCCALL PPPROTOCOL SSSETUP 30 GATEWAY SETTING 323232 4.14.14.1 NNNETWORK CCCONFIGURATION 34 4.1.1 WAN PPPORT TTTYPE SSSETETETUPET UPUPUP 343434 4.1.2 CCCONFIGURING LAN IPIPIP AAADDRESS AND DHCP SSSERVER 363636 4.1.3 VVVIRTUAL SSSERVER SSSETUP 373737 4.1.4 DDDYNAMIC DNS 373737 4.1.5 NNNETWORK MMMANAGEMENT 383838 4.24.24.2 VVVOOOIPIPIP SSSETUP 39 4.2.1 H.323 SSSETUP 393939 4.2.2 SIPSIPSIP SSSETUP 474747 4.2.3 DDDIRECT CALL (P(P(P EER TO PPPEER ))) SETUP 535353 4.2.4 OOOTHER VVVOOOIPIPIP SSSETTING 565656 4.4.4.34.
    [Show full text]
  • Lifesize UVC™ Release Notes
    LifeSize® UVC™ Release Notes Product Version Update LifeSize UVC Platform 1.2.6 LifeSize UVC ClearSea 4.0.4 LifeSize UVC Multipoint 1.6.2 LifeSize UVC Video Center 2.2.5 LifeSize UVC Manager 1.2.1 LifeSize UVC Transit 4.1.4 LifeSize UVC Access 1.5.5 Each LifeSize UVC application includes a separate deployment guide available from lifesize.com/support. For information about UVC server capacity and planning your UVC deployment, refer to the datasheet or online capacity planner at lifesize.com. April 15, 2014 LifeSize UVC Release Notes 2 Section 1: LifeSize UVC Platform Version 1.2.6 To update UVC Platform virtual machine on Microsoft Hyper-V, you must log in to UVC Platform and update the software to each available release, rebooting after each upgrade. If you are performing a first time installation, you must first install version 1.1.1 according to the instructions for new installations, and then upgrade to the latest version following the instructions for upgrading software. Refer to the UVC Platform Installation and Deployment Guide for specific instructions. New Features and Resolved Issues • Time zones correctly display and persist and no longer change to CST after reboots or refreshes. (PLT-1310, LSGK-553) • Server errors preventing changes to the IP address no longer occur. (PLT-1334) • You can now change the default gateway and IP address from the System Settings page. (PLT-1308) • The capacity planner now includes UVC Video Center HD SIP transcodes. Performance numbers for Virtual Machines are calculated using E5-2650 processors with Hyper-Threading enabled.
    [Show full text]
  • Networking Studies Selected Technical Reports
    Networking Studies Selected Technical Reports Networking Studies Selected Technical Reports All CESNET technical reports are available at http://www.cesnet.cz/doc/techzpravy/ Ladislav Lhotka, Pavel Satrapa Networking Studies Selected Technical Reports CESNET, z. s. p. o., 2007 Editors: Ladislav Lhotka [email protected] Pavel Satrapa [email protected] CESNET, z. s. p. o. Zikova 4 160 00 Praha 6 Czech Republic CATALOGUING-IN-PUBLICATION – NATIONAL LIBRARY OF THE CZECH REP. KATALOGIZACE V KNIZE – NÁRODNÍ KNIHOVNA ČESKÉ REPUBLIKY Networking Studies : Selected Technical Reports. -- [1st ed.]. -- Prague : CESNET, 2007. -- viii, 178 p. ISBN 978-80-239-9285-4 621.39 * (437.3) - telecommunication networks -- Czech Republic - papers - telekomunikační sítě -- Česko - sborníky 621.382 - Communication engineering [19] 621.39 - Sdělovací technika [19] ISBN 978-80-239-9285-4 All rights are reserved, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, storage on microfilms or in any other way, and storage in data bases. Duplication of this publication or parts thereof is permitted only under the provisions of the Czech Copyright Law, in its current version, and permissions for use must always be obtained from CESNET. Violations are liable for prosecution under the Czech Copyright Law. c CESNET, z. s. p. o., 2007 Printed by PB tisk, s. r. o., Příbram, Czech Republic Number of copies: 300 Cover design: Pavel Satrapa Typeset from XML sources in Computer Modern fonts by L. Lhotka using XSLT and TEX. Not for sale. Preface CESNET, the Czech national research and education network, was founded as a legal entity in 1996 and is an association of all government-founded universities in the Czech Republic and the Czech Academy of Sciences.
    [Show full text]
  • IP Telephony Cookbook Deliverable 2
    IP Telephony Cookbook Deliverable 2 Saverio Niccolini, University of Pisa Dr. Rosario Giuseppe Garroppo, University of Pisa Dr. Jörg Ott, Universität Bremen TZI Stefan Prelle, Universität Bremen TZI Jiri Kuthan, FhG Fokus Jan Janak, FhG Fokus Dr. Sven Ubik, CESNET Dr. Margit Brandl, Karl-Franzens-Uni Graz Dimitris Daskopoulos, GRNET Egon Verharen, SURFnet Erik Dobbelsteijn, SURFnet IP Telephony Cookbook: Deliverable 2 by Saverio Niccolini, Dr. Rosario Giuseppe Garroppo, Dr. Jörg Ott, Stefan Prelle, Jiri Kuthan, Jan Janak, Dr. Sven Ubik, Dr. Margit Brandl, Dimitris Daskopoulos, Egon Verharen, and Erik Dobbelsteijn Table of Contents 1. Introduction ....................................................................................................................... 1 1.1. Goal ...................................................................................................................... 1 1.2. Reasons for writing this document ............................................................................... 1 1.3. Contents ................................................................................................................. 1 1.4. How to read this document ......................................................................................... 1 1.5. Techno-economic aspect of moving from classic telephony to VoIP ................................... 2 2. Technology Background ...................................................................................................... 5 2.1. Components ...........................................................................................................
    [Show full text]
  • Archivos De Configuración Del Servidor
    ESCUELA POLITÉCNICA NACIONAL FACULTAD DE INGENIERÍA ELÉCTRICA Y ELECTRÓNICA REDISEÑO DE RED MULTISERVICIOS PARA EL COLEGIO “FERNANDO DAQUILEMA” DE LA CIUDAD DE RIOBAMBA PROYECTO PREVIO A LA OBTENCIÓN DEL TÍTULO DE INGENIERO EN ELECTRÓNICA Y REDES DE INFORMACIÓN JARAMILLO PINOS EDUARDO SEBASTIÁN [email protected] DIRECTOR: Ing. Mónica Vinueza [email protected] Quito, Agosto 2013 i DECLARACIÓN Yo, Eduardo Sebastián Jaramillo Pinos, declaro bajo juramento que el trabajo aquí descrito es de mi autoría; que no ha sido previamente presentado para ningún grado o calificación profesional; y, que he consultado las referencias bibliográficas que se incluyen en este documento. A través de la presente declaración cedo mis derechos de propiedad intelectual correspondientes a este trabajo, a la Escuela Politécnica Nacional, según lo establecido por la Ley de Propiedad Intelectual, por su Reglamento y por la normatividad institucional vigente. Eduardo Jaramillo P. ii CERTIFICACIÓN Certifico que el presente trabajo fue desarrollado por Eduardo Sebastián Jaramillo Pinos, bajo mi supervisión. Ing. Mónica Vinueza DIRECTORA DE PROYECTO iii DEDICATORIA Dedico el presente trabajo a mis Padres quienes me han apoyado en todo momento de mi vida y que me han inculcado los valores éticos y morales que me permitieron dar este gran paso en mi vida profesional. A mis hermanas María Fernanda e Ibeth que siempre han estado pendientes de mí, alentándome para que sea alguien mejor. Eduardo iv CONTENIDO CAPÍTULO I FUNDAMENTOS TEÓRICOS 1.1 REDES DE INFORMACIÓN .................................................... 1 1.1.1 MODELO DE REFERENCIA OSI ........................................................... 1 1.1.2 MODELO DE REFERENCIA TCP/IP ..................................................... 1 1.1.2.1 Capa Aplicación ...................................................................................
    [Show full text]
  • Gnugk (Gnu Gatekeeper)
    Kompetenzzentrum für Videokonferenzdienste (VCC) Abwehr von SPAM-Anrufen bei VC- Geräten mit dem GNUGK V3.8 Zellescher Weg 12 Willers-Bau A217 Tel. +49 351 - 463 - 35653 Sebastian Liebscher ([email protected]) Inhalt Spam-Anrufe über H.323 – Problemdarstellung – Alternative Abwehrstrategien ohne GnuGK GnuGK (GNU Gatekeeper) – Kurzvorstellung GnuGK – Neuerungen in der Version 3.8 (3.9) – Sinnvolle Anpassungen in der Konfiguration Abwehr der Spam-Anrufe – Detailbetrachtung der Spam-Anrufe – Mechanismen zur Abwehr – Praktische Erfahrungen – Ausblick auf evtl. zukünftig auftretende Probleme Zusammenfassung Sebastian Liebscher 2 Abwehr von SPAM-Anrufen SPAM-ANRUFE ÜBER H.323 Sebastian Liebscher 3 Problemdarstellung Verbindungsversuche über H.323 (Port 1720) Kontaktierung per IP, nicht über GDS H.323-Name: vornehmlich „cisco“ Standort beliebig Evtl. Registrierung GDS-Verbund (World-GK, Country-GK etc.) Evtl. Anbindung Automatisierte H.323-Netzscans (von speziellem Tool auf Cloud-Servern) Ziel: Suche von Gateways in das ISDN- / Telefonnetz Absicht: Telefonnutzung auf fremde Kosten bzw. Verkauf der Zugangsdaten Vergleich: SIP-Angriffe auf SIP-Server (z.B. VoIP) Sebastian Liebscher 4 Alternative Abwehrstrategien ohne GnuGK Blacklist von bekannten Spam-IP-Adressen: – Nicht alle Spam-IP-Adressen bekannt – Ständige Aktualisierung der Liste nötig Erstellung von Positivlisten für IP-Adressen von zulässigen VC-Geräten: – Nur möglich wenn alle potenziellen Anrufer bekannt sind – Im wissenschaftlichen Umfeld impraktikabel Sperren von Port
    [Show full text]
  • Gnugk – the GNU Gatekeeper Opensource Telephony Summit 2006
    GnuGk – The GNU Gatekeeper OpenSource Telephony Summit 2006 Jan Willamowius 2006-05-02 http://www.gnugk.org Project Overview (1) started in 1999, GPL licence all regular H.323 gatekeeper features – address translation (alias to IP) – access control, call authorization, accounting – call routing – etc. support for Linux, Solaris, FreeBSD, MacOS X and Windows http://www.gnugk.org 2006-05-02 Project Overview (2) authorization and accounting with various backend systems – plain text file – SQL – Radius – via TCP/IP gatekeeper clustering and failover support – child-parent gatekeepers – neighbor gatekeepers (interzone communication) – alternate gatekeepers – retry failed calls on another route http://www.gnugk.org 2006-05-02 Project Overview (3) E.164 number rewritting NAT traversal - both outgoing and incoming calls support for various versions of H.323 protocol (V1 endpoints, some V4 features) H.235 security (authentication) CTI functions: – inbound call routing (“virtual queues”) – call transfer configuration changeable at runtime monitor and admin interface via TCP Graphical User Interface in Java for monitoring http://www.gnugk.org 2006-05-02 Operational Modes direct signalling mode gatekeeper routed signalling mode full proxy mode (signalling + RTP media) http://www.gnugk.org 2006-05-02 Direct Signalling Mode Gatekeeper only RAS channel between endpoints and the gatekeeper signalling directly RAS RAS between endpoints very good scalability signalling lack of precise call control RTP media Endpoint A Endpoint B http://www.gnugk.org
    [Show full text]
  • A Worldwide Survey of Encryption Products
    A Worldwide Survey of Encryption Products Bruce Schneier Kathleen Seidel Saranya Vijayakumar Berkman Center for Internet Independent Researcher Harvard College and Society [email protected] [email protected] Harvard University [email protected] February 11, 2016 Version 1.0 Introduction Data security is a worldwide problem, and there is a wide world of encryption solutions available to help solve this problem. Most of these products are developed and sold by for-profit entities, although some are created as free open-source projects. They are available, either for sale or free download, all over the world. In 1999, a group of researchers from George Washington University attempted to survey the worldwide market for encryption products [HB+99]. The impetus for their survey was the ongoing debate about US encryption export controls. By collecting information about 805 hardware and software encryption products from 35 countries outside the US, the researchers showed that restricting the export of encryption products did nothing to reduce their availability around the world, while at the same time putting US companies at a competitive disadvantage in the information security market. Seventeen years later, we have tried to replicate this survey. Findings We collected information on as many encryption products as we could find anywhere in the world. This is a summary of our findings: We have identified 865 hardware or software products incorporating encryption from 55 different countries. This includes 546 encryption products from outside the US, representing two-thirds of the total. Table 1 summarizes the number of products from each country. The most common non-US country for encryption products is Germany, with 112 products.
    [Show full text]
  • An Automated Tool for Generating and Evaluating the Quality of Voip Calls
    ACME: An Automated Tool for Generating and Evaluating the Quality of VoIP Calls Leandro C.G. Lustosa, André A.D.P. Souza, Paulo H. de A. Rodrigues, and Douglas G. Quinellato Laboratório de Voz Sobre IP – Núcleo de Computação Eletrônica Universidade Federal do Rio de Janeiro (NCE/UFRJ)* Caixa Postal 2324 – 20001-970 – Rio de Janeiro – RJ – Brasil [email protected], {andreabrantes,aguiar}@nce.ufrj.br, [email protected] Abstract. ACME, an automated tool for generating and evaluating the quality of VoIP calls, is presented. ACME examines the availability of bandwidth and processing capacity to determine the largest number of simultaneous calls that a node can operate in a given topology, besides supporting pre-programmed schedule of VoIP experiments. Demos of ACME usage as a capacity estimation tool and as an instrument for monitoring of an IP telephony production service show its effectiveness and versatility. Keywords: monitoring tool, VoIP call generation, capacity determination. 1 Introduction ACME (Automatic Call Measurement Environment) is a tool capable of performing two basic activities: generation of VoIP calls and measurement of the quality of the generated calls. The tool uses the potential of these two activities to build an auto- mated environment supporting two classes of experiments. The first class, called stress experiment, is primarily used for determining the ability (in number of simulta- neous calls) that a medium (wired or wireless) or VoIP system (service or set of serv- ers) can support without compromising voice quality below a previously established level. The second class, called periodic experiment, is used to check the change in call quality over time, even allowing VoIP service availability monitoring.
    [Show full text]
  • Voip Voice Gateway - All Series
    Signamax Connectivity Systems VoIP Voice Gateway - All Series (embedded Gatekeeper / Sip Proxy Server) SIP and H.323 User’s Manual Version 2.3(Firmware 2.7.8) 1 Table of Contents TABLE OF CONTENTS 222 PREFACES 444 0.1 A BOUT THIS MANUAL 4 0.2 C OPYRIGHT DECLARATIONS 4 0.3 T RADEMARKS 4 0.4 S AFETY INSTRUCTIONS 4 0.5 W ARRANTY 4 INTRODUCE 555 1.1 O VERVIEW 5 1.2 A CRONYMS TABLE 5 1.3 I NTRODUCTION 6 1.4 F RONT PANEL LED I NDICATORS & R EAR PANELS 7 1.4.1 G ATEWAY & S IP PROXY SERVER & G ATEKEEPER OUTLOOK 7 1.4.2 F RONT PANEL LED AND CONTAINER DESCRIPTIONS 7 1.4.3 R EAR PANEL DESCRIPTIONS 10 1.5 F EATURES AND SPECIFICATIONS 13 1.5.1 G ATEWAY FEATURES 13 1.5.2 G ATEKEEPER FEATURES 14 1.5.3 S IP PROXY FEATURES 14 1.5.4 G ATEWAY & G ATEKEEPER & S IP PROXY SERVER SPECIFICATIONS 14 INSTALLATION AND SETSETUPUPUPUP 161616 2.1 PACKAGE CONTENT 16 2.1.1 2 PORT /4 PORT GATEWAY & EMBEDDED GATEKEEPER / S IP PROXY SERVER 17 2.1.2 8 PORT SERIES GATEWAY & EMBEDDED GATEKEEPER / S IP PROXY SERVER 17 2.1.3 MODULAR SERIES HIGH DENSITY GATEWAY 18 2.2 I NSTALLATION 18 2.3 S ETUP 19 2.3.1 F ACTORY DEFAULT SETTING 19 2.3.2 C ONSOLE 20 2.3.3 T ELNET 21 2.3.4 W EB USER INTERFACE 24 WIZARD FOR QUICK SETSETUPUPUPUP 272727 2 3.1 WAN P ORT TYPE SETUP 27 3.2 C ONFIGURING NAT OR BRIDGE SETTING : 29 3.3 V OIP C ALL PROTOCOL SETUP 30 GATEWAY SETTING 323232 4.1 N ETWORK CONFIGURATION 34 4.1.1 WAN P ORT TYPE SETUP 34 4.1.2 C ONFIGURING LAN IP A DDRESS AND DHCP S ERVER 36 4.1.3 V IRTUAL SERVER SETUP 37 4.1.4 D YNAMIC DNS 37 4.1.5 N ETWORK MANAGEMENT 38 4.2 V OIP S ETUP 39
    [Show full text]