DOCSLIB.ORG

IP Telephony Cookbook

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read 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) . 45 2.2.5.1 RTP Header . 46 2.2.5.2 RTCP packet types and format . 47 3 IP Telephony Scenarios 49 3.1 Introduction . 49 3.2 Scenario 1: Long-distance least cost routing . 49 3.2.1 Least Cost Routing - An implementation example . 50 3.3 Scenario 2: Alternatives to legacy PBX systems . 50 3.3.1 Scenario 2a: IP-Phones without a PBX system . 51 3.3.2 Scenario 2b: Integration of VoIP with legacy PBX systems . 52 3.3.3 Scenario 2c: Full replacement of legacy PBX systems . 53 3.3.3.1 Intelligent vs. simple terminals . 53 3.3.3.2 Signalling . 54 3.3.3.3 Inter-department trunking . 54 3.3.3.4 Legacy functionality . 54 3.3.3.5 Wireless VoIP . 55 3.3.3.6 Issues . 55 3.4 Scenario 3: Integration of VoIP and Videoconferencing . 55 3 CONTENTS 3.4.1 Integrating Voice and Videoconferencing over IP - an example . 56 4 Setting up basic services 59 4.1 General concepts . 59 4.1.1 Architecture . 59 4.1.1.1 PSTN gateways / PBX migration . 60 4.1.1.2 Trunking . 62 4.1.2 Robustness . 63 4.1.3 Management issues . 65 4.1.3.1 Multiple account databases . 65 4.1.3.2 Decentralization . 66 4.2 Dialplans . 66 4.3 Authentication . 67 4.3.1 Authentication in H.323 . 67 4.3.1.1 Areas of application . 67 4.3.1.2 User Authentication . 67 4.3.1.3 Integrity . 68 4.3.1.4 Confidentiality . 68 4.3.1.5 Security profiles . 68 4.3.1.6 H.235 and the real world . 69 4.3.2 Authentication in SIP . 69 4.3.2.1 Overview of Digest Authentication . 69 4.3.2.2 Digest Authentication and SIP . 70 4.3.2.3 Basic Scenarios . 71 4.4 Examples . 73 4.4.1 Example 1: Simple, use IP telephony like legacy telephony . 73 4.4.2 Example 2: Complex, full featured . 73 4.5 Setting up H.323 services . 75 4.5.1 Using a Cisco Multimedia Conference Manager (MCM gatekeeper) . 75 4.5.1.1 Installation . 75 4.5.1.2 Configuration . 76 4.5.1.3 Operation . 77 4.5.1.4 Endpoint authentication . 78 4.5.1.5 Advanced features . 78 4.5.2 Using a Radvision Enhanced Communication Server (ECS gatekeeper) . 78 4.5.2.1 Installation . 79 4.5.2.2 Configuration . 79 4.5.2.3 Operation . 81 4.5.2.4 Endpoint authentication . 81 4.5.2.5 Advanced features . 81 4.5.3 Using an OpenH323 Gatekeeper - GNU Gatekeeper . 82 4.5.3.1 Installation . 82 4.5.3.2 Configuration . 84 4.5.3.3 Operation . 85 4.5.3.4 Endpoint authentication . 85 4.5.3.5 Advanced features . 86 4.6 Setting up SIP services . 86 4.6.1 Operation of SIP Servers . 86 4.6.1.1 Recommended Operational Practices . 86.
Load more

Recommended publications
  • RFC 2168 Resolution of Uris Using the DNS June 1997
    Network Working Group R. Daniel Request for Comments: 2168 Los Alamos National Laboratory Category: Experimental M. Mealling Network Solutions, Inc. June 1997 Resolution of Uniform Resource Identifiers using the Domain Name System Status of this Memo =================== This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. Abstract: ========= Uniform Resource Locators (URLs) are the foundation of the World Wide Web, and are a vital Internet technology. However, they have proven to be brittle in practice. The basic problem is that URLs typically identify a particular path to a file on a particular host. There is no graceful way of changing the path or host once the URL has been assigned. Neither is there a graceful way of replicating the resource located by the URL to achieve better network utilization and/or fault tolerance. Uniform Resource Names (URNs) have been hypothesized as a adjunct to URLs that would overcome such problems. URNs and URLs are both instances of a broader class of identifiers known as Uniform Resource Identifiers (URIs). The requirements document for URN resolution systems[15] defines the concept of a "resolver discovery service". This document describes the first, experimental, RDS. It is implemented by a new DNS Resource Record, NAPTR (Naming Authority PoinTeR), that provides rules for mapping parts of URIs to domain names. By changing the mapping rules, we can change the host that is contacted to resolve a URI. This will allow a more graceful handling of URLs over long time periods, and forms the foundation for a new proposal for Uniform Resource Names.
    [Show full text]
  • VOIP – Voice Over IP Overview
    VOIP – Voice over IP Overview Introduction Voice over IP (VOIP), otherwise known as IP telephony, is the delivery of voice information over Internet Protocol (IP) packet switched networks. This means sending voice information in digital form in discrete packets rather than in the traditional circuit-committed protocols of the public switched telephone network (PSTN). A major advantage of VOIP is that it can avoid the tolls charged by ordinary telephone service by utilising fixed charge IP network services such as broadband. Recent development with SIP (see below) technology and hardware supporting this standard has resulted in the production of a number of commercially marketed SIP handsets, both wired and wireless networks, removing the need for a PC or laptop running a software handset, or “softphone”, to connect to VOIP services. A subscription to a local server from a SIP handset or softphone provides you with all the normal telephony features including voice and fax, as well as text and even video services. SIP (Session initiation protocol) is an Internet standard specified by the Internet Engineering Task Force (IETF) in RFC 2543. SIP is used to initiate, manage, and terminate interactive sessions between one or more users on the Internet. SIP, which borrows heavily from HTTP and the e-mail protocol SMTP, provides scalability, extensibility, flexibility, and capabilities for creation of new services. SIP is increasingly used for Internet telephony signalling, in gateways, PC phones, softswitches, and softphones, but it is not limited to Internet telephony and can be used to initiate and manage any type of session, including video, interactive games, and text chat.
    [Show full text]
  • Integration of Voice Over IP Services Over Ipv6 Networks
    View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by UCL Discovery Kirstein, P; Lambrinos, L; (2007) Integrating Voice over IP Services in IPv4 and IPv6 Networks. In: Proceedings of the International Multi-Conference on Computing in the Global Information Technology. IEEE ARTICLE Integrating Voice over IP services in IPv4 and IPv6 networks Lambros Lambrinos Dept.of Communication and Internet studies Cyprus University of Technology Limassol 3603, Cyprus [email protected] Peter Kirstein Department of Computer Science University College London (UCL) Gower Street, London, WC1E 6BT, UK [email protected] Abstract The transition from the current IPv4 network addressing model to the next generation IPv6 network addressing model has always been deemed as a lengthy process. As the deployment of IPv6 infrastructures evolves, interaction with the existing IPv4 networks is unavoidable. This interaction may occur at the network level (simple data pass-through) or at the application level (between IPv6 and IPv4 endpoints). In this paper we concentrate on application level interoperability and select an increasingly popular application: Voice Over IP (VoIP). The use of VoIP technologies is becoming more widespread as end-users and network providers recognise the potential benefits that the usage of the application provides. It is important to provide an environment where IPv4 and IPv6 networks and applications / devices can interoperate in the context of VoIP. This environment is based on an architecture that integrates all the components together (whether they support IPv4 or IPv6 or both) thereby providing ubiquitous access to IP telephony services based on the SIP signaling protocol.
    [Show 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
    [Show full text]
  • A Survey of Open Source Products for Building a SIP Communication Platform
    Hindawi Publishing Corporation Advances in Multimedia Volume 2011, Article ID 372591, 21 pages doi:10.1155/2011/372591 Research Article A Survey of Open Source Products for Building a SIP Communication Platform Pavel Segec and Tatiana Kovacikova Department of InfoCom Networks, University of Zilina, Univerzitna 8215/1, 010 26 Zilina, Slovakia Correspondence should be addressed to Tatiana Kovacikova, [email protected] Received 29 July 2011; Revised 31 October 2011; Accepted 15 November 2011 Academic Editor: T. Turletti Copyright © 2011 P. Segec and T. Kovacikova. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. The Session Initiation Protocol (SIP) is a multimedia signalling protocol that has evolved into a widely adopted communication standard. The integration of SIP into existing IP networks has fostered IP networks becoming a convergence platform for both real- time and non-real-time multimedia communications. This converged platform integrates data, voice, video, presence, messaging, and conference services into a single network that offers new communication experiences for users. The open source community has contributed to SIP adoption through the development of open source software for both SIP clients and servers. In this paper, we provide a survey on open SIP systems that can be built using publically available software. We identify SIP features for service deve- lopment and programming, services and applications of a SIP-converged platform, and the most important technologies support- ing SIP functionalities. We propose an advanced converged IP communication platform that uses SIP for service delivery.
    [Show full text]
  • DNS/ENUM Guidelines for Service Providers & GRX/IPX
    GSM Association Non Confidential Official Document IR.67 IR.67 - DNS/ENUM Guidelines for Service Providers & GRX/IPX Providers 6.0 1 December 2011 This is a non-binding permanent reference document of the GSM Association. Security Classification – NON-CONFIDENTIAL GSMA Material Copyright Notice Copyright © 2011 GSM Association Antitrust Notice The information contain herein is in full compliance with the GSM Association’s antitrust compliance policy. V6.0 Page 1 of 78 GSM Association Non Confidential Official Document IR.67 Table of Contents IR.67 - DNS/ENUM Guidelines for Service Providers & GRX/IPX Providers .......... 1 6.0 ............................................................................................................................... 1 1 December 2011 ....................................................................................................... 1 1 Introduction ...................................................................................................... 5 1.1 Overview ..................................................................................................... 5 1.2 Scope .......................................................................................................... 5 1.3 Definition of Acronyms and Abbreviations ................................................... 5 1.4 Definition of Terms ...................................................................................... 6 1.5 Document Cross-References ...................................................................... 7 2 DNS
    [Show full text]
  • Technical Realization of Communication Networks
    TECHNISCHE UNIVERSITAT ••• WIEN • • • institute of Vienna University of Technology • e • telecommunications Lecture Notes Technical Realization of Communication Networks Course Number: 388.031 Part : Networking o. Univ. Prof. Dr. Hannen R. van As Institute of Telecommunications Vienna University of Technology 2011 2 CONTENTS 1.5.14 Adrnii;sion control 59 l.5.15 Flow control .... 60 1.5.16 Congestion control 61 1.6 Mobility 62 1. 7 Security . .. 63 Contents 2 Source and transmission coding 65 2.1 Introduction . 66 2.2 Source coding . 67 2.3 Linc coding aJJd modulation . 68 2.3.1 Binary coding . 69 1 Networking 1 2.3.2 I3lock <.'Oding .... 70 1.1 Network architecture . 2 2.3.3 Convolution coding . 71 1.1.1 Network planes . .. 2 2.4 Modulation . 72 1.1.2 Wired and wireless media 3 2.4.l OFDM ....... 73 1.1.3 Transmission . 3 2.4.2 CMSK .. .. ... 74 1.1.4 Switching . 9 2.5 System-related coding and tra.nsrnh;sion 75 1.1.5 Signaling and control . 13 2.5.1 PCM .......... .... 76 1.1.6 Network intelligence 14 1.1.7 Network management 14 3 Tuansmission 77 1.1.8 Service transport . 14 3.1 Introduction . 78 1.1.9 Communication and content services 14 3.2 Transmission media . 82 1.1.10 Technological layering 14 3.2.l CoaxiaJ cable 82 1.1.11 Geographical areas 15 3.2.2 Copper twisted pair 82 1.2 Protocol Architecture 19 3.2.3 Fiber . 83 1.3 Network protocols 23 3.2.4 Free-space optic link 83 1.4 Network availability 27 3.2.5 Frequency spcctmrn 83 1.5 Network control .
    [Show full text]
  • March 22, 2006 Marlene H. Dortch Federal Communications Commission Office of the Secretary 445 12Th Street, SW Washington, DC 2
    1875 K Street, NW Washington, DC 20006 Tel: 202 303 1000 Fax: 202 303 2000 March 22, 2006 Marlene H. Dortch Federal Communications Commission Office of the Secretary 445 12th Street, SW Washington, DC 20554 Re: In re Telecommunications Relay Services and Speech-to-Speech Services for Individuals with Hearing and Speech Disabilities; Petition for Declaratory Ruling on Video Relay Service Interoperability, CG Docket No. 03-123 Dear Ms. Dortch: On March 20, 2006, representatives of Snap Telecommunications, Inc. (“Snap”), Aequus Technologies Corp. (“Aequus”), and WorldGate Communications, Inc. (“WorldGate”) met with Tom Chandler, Chief, Disability Rights Office; Jay Keithley, Deputy Bureau Chief, Consumer & Governmental Affairs Bureau; Greg Hlibok, Disability Rights Office; and Sharon Diskin, Office of the General Counsel. Also attending the meeting were David Dinin, President, Aequus; Daryl Crouse, President and Founder, Snap; Randy Gort, General Counsel, WorldGate; Richard Westerfer, Chief Operating Officer and Senior Vice-President, WorldGate; and the undersigned. During the meeting, the parties supported the petition in the above-captioned proceeding and opposed restrictive marketing practices, IP blocking, or other techniques by a VRS provider designed to prevent a hearing-impaired individual from placing a VRS call to a different VRS provider. However, the parties also cautioned the Commission to avoid the adoption of requirements in this proceeding that could have the inadvertent effect of impeding the ability of new or existing VRS providers from introducing VRS equipment and services implementing the newer and more robust open standard called Session Initiation Protocol (“SIP”). The parties described the benefits of SIP in providing functionally equivalent service for the hearing-impaired community, the fact that SIP is increasingly being embraced as the standard of choice in the video phone and VoIP arenas, and that SIP is the focus of significant efforts by various industry players to establish E-911 solutions for VoIP and VRS.
    [Show full text]
  • Dns Applications and Resource Records
    10 DNS APPLICATIONS AND RESOURCE RECORDS 10.1 INTRODUCTION DNS inherently lends itself well to “translating” a given piece of information into another related piece of information. This resolution process is the very reason for DNS’s invention, and it has been extended beyond resolving hostnames into IP addresses and vice versa to support a broad variety of applications. Virtually any service or application that requires translation of one form of information into another can leverage DNS. Each resource record configured in DNS enables this lookup function, returning a resolution answer for a given query. The DNS server parses the query from the Question section of the DNS message,* seeking a match within the corresponding domain’s zone file for the query’s QNAME, QCLASS, and QTYPE. Each resource record has a Name (aka Owner) field, Class (Internet class is assumed if not specified), and Type field. The RData field contains the corresponding answer to the query. The resource record type defines the type and format of the question (owner/name field) and corresponding answer (RData field). In some instances, multiple resource records may match the queried name, type, and class. In such cases, all matching records, called a Resource Record Set (RRSet), are returned in the Answer section of the response message. * Refer to Figure 9.12. IP Address Management: Principles and Practice, by Timothy Rooney Copyright Ó 2011 the Institute of Electrical and Electronics Engineers, Inc. 10.1 INTRODUCTION 177 Most, but not all, new applications require new resource record types to enable definition of application-specific information, and these new resource record types are standardized via the IETF RFC process.
    [Show full text]
  • ENUM Guidelines for Service Providers and IPX Providers
    GSM Association Non-confidential Official Document NG.105 - ENUM Guidelines for Service Providers and IPX Providers ENUM Guidelines for Service Providers and IPX Providers Version 1.1 28 May 2018 This is a Non-binding Permanent Reference Document of the GSMA Security Classification: Non-confidential Access to and distribution of this document is restricted to the persons permitted by the security classification. This document is confidential to the Association and is subject to copyright protection. This document is to be used only for the purposes for which it has been supplied and information contained in it must not be disclosed or in any other way made available, in whole or in part, to persons other than those permitted under the security classification without the prior written approval of the Association. Copyright Notice (Test) Copyright © 2018 GSM Association Disclaimer The GSM Association (“Association”) makes no representation, warranty or undertaking (express or implied) with respect to and does not accept any responsibility for, and hereby disclaims liability for the accuracy or completeness or timeliness of the information contained in this document. The information contained in this document may be subject to change without prior notice. Antitrust Notice The information contain herein is in full compliance with the GSM Association’s antitrust compliance policy. V1.1 Page 1 of 55 GSM Association Non-confidential Official Document NG.105 - ENUM Guidelines for Service Providers and IPX Providers Table of Contents 1 Introduction
    [Show full text]
  • Integration of Voice Over IP Services Over Ipv6 Networks
    Kirstein, P; Lambrinos, L; (2007) Integrating Voice over IP Services in IPv4 and IPv6 Networks. In: Proceedings of the International Multi-Conference on Computing in the Global Information Technology. IEEE ARTICLE Integrating Voice over IP services in IPv4 and IPv6 networks Lambros Lambrinos Dept.of Communication and Internet studies Cyprus University of Technology Limassol 3603, Cyprus [email protected] Peter Kirstein Department of Computer Science University College London (UCL) Gower Street, London, WC1E 6BT, UK [email protected] Abstract The transition from the current IPv4 network addressing model to the next generation IPv6 network addressing model has always been deemed as a lengthy process. As the deployment of IPv6 infrastructures evolves, interaction with the existing IPv4 networks is unavoidable. This interaction may occur at the network level (simple data pass-through) or at the application level (between IPv6 and IPv4 endpoints). In this paper we concentrate on application level interoperability and select an increasingly popular application: Voice Over IP (VoIP). The use of VoIP technologies is becoming more widespread as end-users and network providers recognise the potential benefits that the usage of the application provides. It is important to provide an environment where IPv4 and IPv6 networks and applications / devices can interoperate in the context of VoIP. This environment is based on an architecture that integrates all the components together (whether they support IPv4 or IPv6 or both) thereby providing ubiquitous access to IP telephony services based on the SIP signaling protocol. We present our experiences from realising the proposed architecture. 1. Introduction The IPv6 network addressing protocol is considered the flagship protocol in the next- generation internet.
    [Show full text]
  • Vitalqip® DNS/DHCP & IP Management Software ENUM
    VitalQIP® DNS/DHCP & IP Management Software ENUM Manager Release 1.2 User’s Guide 190-409-067R7.1 Issue 1 August 2007 Alcatel-Lucent - Proprietary This document contains proprietary information of Alcatel-Lucent and is not to be disclosed or used except in accordance with applicable agreements. Copyright © 2007 Alcatel-Lucent. Unpublished and not for publication. All rights reserved. Copyright © 2007 Alcatel-Lucent. All Rights Reserved. This material is protected by the copyright laws of the United States and other countries. It may not be reproduced, distributed, or altered in any fashion by any entity (either internal or external to Alcatel-Lucent), except in accordance with applicable agreements, contracts, or licensing, without the express written consent of Alcatel-Lucent and the business management owner of the material. This material is protected by the copyright and trade secret laws of the United States and other countries. It may not be reproduced, distributed, or altered in any fashion by any entity (either internal or external to Alcatel-Lucent), except in accordance with applicable agreements, contracts, or licensing, without the express written consent of Alcatel-Lucent and the business management owner of the material. Trademarks All trademarks and service marks specified herein are owned by their respective companies. Licenses Apache This product includes software developed by the Apache Software Foundation (http:// www.apache.org/). Alcatel-Lucent - Proprietary See notice on first page. Contents About this document 1 ENUM
    [Show full text]