DOCSLIB.ORG

Gnugk (Gnu Gatekeeper)

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read 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 1720 (TCP/UDP) für eingehende Verbindungen: – Keine Rufbarkeit von außerhalb der eigenen Institution – Funktioniert nicht, wenn beide Gesprächspartner diese Lösung wählen Umzug der VC-Geräte in ein internes geschütztes Netz: – Keine Erreichbarkeit von außerhalb der eigenen Institution Kommerzielle Lösung: – Z.B. Einrichtung eines Firewall-Traversals Sebastian Liebscher 5 Abwehr von SPAM-Anrufen GNUGK (GNU GATEKEEPER) Sebastian Liebscher 6 Kurzvorstellung GnuGK Sebastian Liebscher 7 Kurzvorstellung GnuGK Freie Software Läuft unter Linux, Windows, MacOS X, Solaris, FreeBSD, OpenBSD, NetBSD Unterstützt H.323 v8, H.323 Annex O, IPv4, IPv6, dual stack Bietet zahlreiche Methoden für: – Authentifizierung von Endgeräten – Authentifizierung von Anrufen Anbindung an Datenbanken möglich: – ODBC, MySQL, MariaDB, PostgreSQL, SQLite, Firebird Unterstützt flexibles Routing von Anrufen, Umschreibung von Rufnummern Einbettbar in weltweite GDS-Struktur Nutzbar als H.323-Proxy Unterstützt NAT-Traversal Graphisches Nutzerinterface verfügbar Sebastian Liebscher 7 Neuerungen in der Version 3.8 (3.9) Allgemeine Neuerungen beim GnuGK in der Version 3.8: – Kommerzielles Add-On: Neues Webinterface (unter PHP) für Konfiguration und Überwachung des GnuGK – CatchAll-Regel ersetzt nun Ziel-Alias entsprechend – Möglichkeit der Ausfilterung ganzer „Fähigkeitsklassen“ (z.B. H.239) – Schalter „[Gatekeeper::Main] MinH323Version=“ – Behebung von diversen Problemen und Abstürzen Neuerungen aufgrund der Spam-Anrufe: – Verbesserte Nutzung und Erzeugung von Zufallszahlen – Schalter „[RasSrv::ARQFeatures] CheckSenderIP=“ – Neues Authentifizierungs-Modul: LuaAuth – Verbesserungen bei anderen Authentifizierungs-Modulen: • FileIPAuth, AliasAuth, PrefixAuth, SQLAuth Sebastian Liebscher 8 Neuerungen in der Version 3.8 (3.9) - II Wichtige Neuerungen beim GnuGK in der Version 3.9: – Neues Authentifizierungs-Modul: GeoIPAuth: • Überprüfung anhand der Landeszugehörigkeit • Liste der Zuordnung von IP-Adressen zu Ländern nötig – Verbesserung Status-Port: • Möglichkeit zur Speicherung der letzten n Ereignisse • Nachträgliche Abrufbarkeit gegeben • Alternative zu Log-Datei Sebastian Liebscher 9 Sinnvolle Anpassungen in der Konfiguration Alte Konfiguration - Auszug: Neue Konfiguration - Auszug: [Gatekeeper::Main] [Gatekeeper::Main] Fourtytwo=42 Name=00493514632 Name=00493514632 TimeToLive=300 TimeToLive=300 Home=141.30.xxx.yyy Home=141.30.xxx.yyy NetworkInterfaces=141.30.xxx.yyy/32 NetworkInterfaces=141.30.xxx.yyy/32 StatusPort=7000 StatusPort=7000 UseBroadcastListener=0 UseBroadcastListener=0 [RasSrv::LRQFeatures] [RasSrv::LRQFeatures] CiscoGKCompatible=1 IncludeDestinationInfoInLCF=0 ForwardHopCount=10 AcceptNonNeighborLCF=1 AcceptNonNeighborLCF=1 Sebastian Liebscher 10 Sinnvolle Anpassungen in der Konfiguration - II Alte Konfiguration - Auszug: Neue Konfiguration - Auszug: [RasSrv::Neighbors] [RasSrv::Neighbors] m=141.30.xxx.zzz:1719;00493514631 GK1=GnuGk / CiscoGk / ClarentGk / Glonetgk [Neighbor::GK1] GatekeeperIdentifier=GK1 Host=141.30.xxx.zzz:1719 SendPrefixes=00493514631 AcceptPrefixes=* ForwardHopCount=10 ForwardLRQ=always [RasSrv::ARQFeatures] CheckSenderIP=1 Sebastian Liebscher 11 Abwehr von SPAM-Anrufen ABWEHR DER SPAM-ANRUFE Sebastian Liebscher 12 Detailbetrachtung der Spam-Anrufe Verbindungsversuche über H.323 (Port 1720) Kontaktierung per IP, nicht über GDS H.323-Name: vornehmlich „cisco“ Standort beliebig Auszug eines typischen Logeintrags eines Spam-Anrufs (Teil 1): callType = pointToPoint destinationInfo = 1 entries { [0]=dialedDigits „9010441227806181“ } destCallSignalAddress = ipAddress { ip = 4 octets { 8d 1e 43 f7 ..C. } port = 1720 } Sebastian Liebscher 13 Detailbetrachtung der Spam-Anrufe - II Verbindungsversuche über H.323 (Port 1720) Kontaktierung per IP, nicht über GDS H.323-Name: vornehmlich „cisco“ Standort beliebig Auszug eines typischen Logeintrags eines Spam-Anrufs (Teil 2): srcInfo = 1 entries { [0]=h323_ID 5 characters { 0063 0069 0073 0063 006f cisco } } srcCallSignalAddress = ipAddress { ip = 4 octets { d0 46 38 3c .F8< } port = 43164 } Sebastian Liebscher 14 Mechanismen zur Abwehr Für Kontrolle der Anrufe am Gatekeeper Routed Mode erforderlich: – Standardmäßig nur RAS – Nachrichten (H.225) über Gatekeeper – 3 Abstufungen beim Routed Mode möglich: • 1. Stufe: Zusätzlich Rufsignalisierung (Q.931) über Gatekeeper • 2. Stufe: Zusätzlich Parameteraushandlung (H.245) über Gatekeeper • 3. Stufe: Alle Pakete über Gatekeeper (Proxy) – 1. Stufe für Kontrolle der Anrufe ausreichend Nötige Konfigurationsänderung beim GnuGK: [RoutedMode] GKRouted=1 H245Routed=0 CallSignalPort=1720 AcceptUnregisteredCalls=1 Sebastian Liebscher 15 Mechanismen zur Abwehr - II Ablauf eines typischen Rufes im Routed Mode (1. Stufe): 1. Schritt Ruf auf Port 1720 (Q.931: CS: setup, CS: status) Rückantwort: CS: callProceeding Sebastian Liebscher 16 Mechanismen zur Abwehr - II Ablauf eines typischen Rufes im Routed Mode (1. Stufe): 1. Schritt Ruf auf Port 1720 (Q.931: CS: setup, CS: status) Rückantwort: CS: callProceeding Port 1719: RAS: admissionRequest Rückantwort: RAS: admissionReject RAS: admissionReject: – Ablehnungsgrund: routeCallToGatekeeper Sebastian Liebscher 16 Mechanismen zur Abwehr - II Ablauf eines typischen Rufes im Routed Mode (1. Stufe): 1. Schritt Ruf auf Port 1720 (Q.931: CS: setup, CS: status) Rückantwort: CS: callProceeding Weitere Rückantwort: CS: facility, CS: releaseComplete Port 1719: RAS: admissionRequest Rückantwort: RAS: admissionReject RAS: admissionReject: – Ablehnungsgrund: routeCallToGatekeeper CS: facility: – Enthält IP-Adresse und Port des Gatekeepers des Ziel-Geräts (Eintrag: alternativeAddress: ipAddress) – Enthält Grund für Umleitung: routeCallToGatekeeper Sebastian Liebscher 16 Mechanismen zur Abwehr - III Ablauf eines typischen Rufes im Routed Mode (1. Stufe): 2. Schritt (Kurzform) Port 1719: RAS: admissionRequest Rückantwort: RAS: admissionConfirm Ruf auf Port 1720 (Q.931) über Gatekeeper an Ziel-Gerät Rückantworten (Q.931): ebenfalls über Gatekeeper Sebastian Liebscher 17 Mechanismen zur Abwehr - III Ablauf eines typischen Rufes im Routed Mode (1. Stufe): 2. Schritt (Kurzform) Aufbau des Rufes (H.245, RTP / RTCP) Port 1719: RAS: admissionRequest Rückantwort: RAS: admissionConfirm Ruf auf Port 1720 (Q.931) über Gatekeeper an Ziel-Gerät Rückantworten (Q.931): ebenfalls über Gatekeeper Sebastian Liebscher 17 Mechanismen zur Abwehr - III Ablauf eines typischen Rufes im Routed Mode (1. Stufe): 2. Schritt (Kurzform) Aufbau des Rufes (H.245, RTP / RTCP) Feststellung: Spam-Anrufe werden schon Port 1719: RAS: admissionRequest geblockt ! Rückantwort: RAS: admissionConfirm Grund: 2. Verbindung über Gatekeeper wird nicht initiiert Ruf auf Port 1720 (Q.931) über Gatekeeper an Ziel-Gerät Rückantworten (Q.931): ebenfalls über Gatekeeper Sebastian Liebscher 17 Praktische Erfahrungen Routed Mode: – Spam-Anrufe werden zuverlässig geblockt – Rufe per IP und GDS weiterhin möglich (Rufrichtung egal) – Einzelne Probleme mit Gegenstellen, die ebenfalls die 2. Verbindung über den Gatekeeper nicht initiieren: • Problem tritt nur mit Gegenstellen auf, die nicht rufbar sind (Firewall / NAT / Internet-Proxy etc.) und per IP rufen • Nachstellung des Problems im VCC bisher nicht gelungen • Wechsel der Konfiguration bzw. des Gatekeepers nötig, um Verbindung aufbauen zu können AcceptUnregisteredCalls=0: – Nur Annahme von Rufen von registrierten Endgeräten und über bekannte Gatekeeper (Nachbar-GK), also auch kein URI-Dialing möglich – Rufe von nicht registrierten Endgeräten können trotzdem über bekannte Gatekeeper (mit AcceptUnregisteredCalls=1) eintreffen Sebastian Liebscher 18 Ausblick auf evtl. zukünftig auftretende Probleme URI-Dialing in der Form „h323:[email protected]“ kommt am Endgerät (141.30.67.247) an: – 2. Verbindung über Gatekeeper wird aufgebaut – Logeinträge decken sich mit Logeinträgen der Spam-Anrufe Spam-Anrufe könnten auch Gatekeeper erreichen (Initiierung 2. Verbindung) Daher evtl. weitere Abwehrmechanismen
Load more

Recommended publications
  • 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
    [Show full text]
  • 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 – 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]