DOCSLIB.ORG

Session Border Controllers

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Session Border Controllers SESSION BORDER CONTROLLERS ENABLING THE VOIP REVOLUTION February 2005 Jon Hardwick Data Connection Ltd [email protected] Data Connection Limited 100 Church Street Enfield, EN2 6BQ, UK Tel: +44 20 8366 1177 http://www.dataconnection.com/ Copyright © 2005 Data Connection Limited. All Rights Reserved. TABLE OF CONTENTS 1. INTRODUCTION AND OVERVIEW .............................................................. 1 1.1 Document Roadmap........................................................................... 1 2. INTRODUCING SBCS .................................................................................. 2 2.1 Internal structure of an SBC ............................................................... 2 2.2 The Demilitarized Zone ...................................................................... 3 2.2.1 Single-box SBC deployments.................................................. 3 2.2.2 Dual-box SBC deployments .................................................... 5 2.3 Applicable network scenarios for SBCs.............................................. 6 2.3.1 UNI scenario............................................................................ 7 2.3.2 NNI scenario............................................................................ 8 2.3.3 VPN scenario .......................................................................... 9 2.3.4 Solving internal topology issues ............................................ 11 2.3.5 Centralized codec transcoding .............................................. 12 3. SBC FUNCTION OVERVIEW ..................................................................... 13 3.1 DMZ processing ............................................................................... 13 3.2 Firewall and NAT traversal ............................................................... 13 3.3 Call Admission Control (CAC) and DoS protection ........................... 14 3.4 Quality of Service (QoS)................................................................... 15 3.5 Media bridging.................................................................................. 15 3.5.1 Voice over IP media bridging................................................. 16 3.5.2 Fax over IP media bridging.................................................... 16 3.5.3 Modem over IP media bridging.............................................. 17 3.6 Fault Tolerance ................................................................................ 17 3.7 Policy-based call routing................................................................... 18 3.7.1 Crankback and re-initiation of call setups .............................. 18 3.8 Signaling protocol interworking......................................................... 18 3.9 Call billing......................................................................................... 19 3.10 Comparison of single-box and dual-box model................................. 19 3.10.1 Single-box SBCs ................................................................... 19 3.10.2 Dual-box SBCs...................................................................... 20 3.11 Configuration models........................................................................ 21 3.12 Feature matrix .................................................................................. 21 4. DMZ PROCESSING.................................................................................... 24 4.1 Devices in the DMZ .......................................................................... 24 4.1.1 The firewall............................................................................ 25 4.1.2 The NAT................................................................................ 26 4.2 How VoIP signaling packets traverse the DMZ................................. 27 4.3 How VoIP media packets traverse the DMZ ..................................... 28 4.4 Other DMZ processing ..................................................................... 29 4.4.1 Topology hiding..................................................................... 29 4.4.2 Bad protocol detection........................................................... 29 Copyright © 2005 Data Connection Limited. All Rights Reserved. 5. FIREWALL AND NAT TRAVERSAL .......................................................... 30 5.1 The VoIP firewall/NAT traversal problem.......................................... 30 5.2 SBC pinhole solution ........................................................................ 31 5.2.1 The signaling pinhole ............................................................ 32 5.2.2 Keeping the signaling pinhole open....................................... 33 5.2.3 The media pinhole................................................................. 34 5.2.4 Example SIP flow .................................................................. 35 6. CALL ADMISSION CONTROL ................................................................... 38 6.1 DoS and DDoS attack prevention..................................................... 38 6.1.1 Summary of limiting options .................................................. 40 6.2 Reacting to network congestion........................................................ 41 6.3 Policing SLAs ................................................................................... 42 6.4 Preventing theft of service and bandwidth ........................................ 42 6.5 Emergency services calls ................................................................. 43 7. CONCLUSION ............................................................................................ 44 8. ABOUT DATA CONNECTION.................................................................... 45 9. GLOSSARY ................................................................................................ 46 10. REFERENCES ............................................................................................ 50 10.1 Media ............................................................................................... 50 10.2 Signaling........................................................................................... 51 Copyright © 2005 Data Connection Limited. All Rights Reserved. 1. INTRODUCTION AND OVERVIEW Session Border Controllers (SBCs) have become an important element of modern Voice over IP (VoIP) networks, as service providers look to protect the integrity of their networks and business models while offering diverse services to their customers. Most people would agree that an SBC is a kind of firewall for Voice over IP traffic. However, as soon as you start to look beyond this initial consensus, there is considerable disagreement as to what an SBC actually is, and what function it should offer! This is partly because SBC vendors are pushing out to cover a wide variety of niches in order to compete for market share, and partly due to the genuine range of scenarios where service providers are looking for solutions. This white paper starts by looking at the deployment scenarios where SBCs have a role today. It then goes on to examine the breadth of technology and functionality that different companies claim should be delivered by an SBC, assessing which functions are most important for each type of deployment. Finally, it looks in more detail at the key elements common to most SBC products. 1.1 Document Roadmap This white paper is structured as follows. • Chapter 2, Introducing SBCs, takes a high-level look at the role of SBCs within a network, and explains where they are most likely to be deployed. • Chapter 3, SBC function overview, gives more detail of the types of function offered by SBCs. • Chapters 4 to 6 then discuss the key features of SBCs in depth. • Chapter 4, DMZ processing, explains SBCs’ firewall and Network Address Translation (NAT) function. • Chapter 5, Firewall and NAT traversal, describes how SBCs can be used to direct VoIP packets behind firewalls in adjacent networks. • Chapter 6, Call Admission Control, lists the types of call processing performed by SBCs. • Chapter 7, Conclusion, provides a summary of the analysis. • Chapter 8, About Data Connection, contains information about the author of this paper, Data Connection, and Data Connection’s range of portable software (including DC-SBC). • Chapter 9, Glossary, contains a glossary of some of the important terms used in this paper. • Chapter 10, References, provides details of references made in this paper. Copyright © 2005 Data Connection Limited. All Rights Reserved. Page 1 http://www.dataconnection.com/ 2. INTRODUCING SBCS An SBC is a VoIP session-aware device that controls call admission to a network at the border of that network. Optionally (depending on the device), it can also perform a host of call-control functions to ease the load on the call agents within the network. This chapter provides a general introduction to SBCs. • Section 2.1, Internal structure of an SBC, describes the two distinct components that make up an SBC. • Section 2.2, The Demilitarized Zone, describes the part of the network in which SBCs are mostly (though not always) used. • Section 2.3, Applicable network scenarios for SBCs, describes the five main network scenarios where SBCs are deployed. 2.1 Internal structure of an SBC An SBC device breaks down into two logically distinct pieces. • The Signaling SBC function (SBC-SIG) controls access of VoIP signaling messages to the core of the network, and manipulates the contents of these messages. It does this by acting
Load more

Recommended publications
  • Introduction to Voip – Voice Over Internet Protocol
    Introduction to VoIP – Voice Over Internet Protocol 818 West Diamond Avenue - Third Floor, Gaithersburg, MD 20878 Phone: (301) 670-4784 Fax: (301) 670-9187 Email: [email protected] Website: http://www.gl.com 1 What is VoIP? • Voice over Internet Protocol is a general term for a family of transmission technologies for delivery of voice communications over IP networks such as the Internet or other packet- switched networks • Other terms frequently encountered and synonymous with VoIP are IP telephony, Internet telephony, voice over broadband (VoBB), broadband telephony, and broadband phone • Voice over IP systems carry telephony signals as digital audio, typically reduced in data rate using speech data compression technologies, encapsulated in a data-packet stream over IP 2 Advantages of VoIP Differences from PSTN Network • Ability to transmit more than one call over the same broadband connection • Conference calling, IVR, call forwarding, automatic redial and caller ID are free • Bandwidth efficiency and Low cost • Location Independence - Only an internet connection is needed to get a connection to a VoIP provider • Integration with other services available over the Internet, including video conversation, message or data file exchange in parallel with the conversation, audio conferencing, managing address books, and passing information about whether others, e.g., friends or colleagues, are available to interested parties • Supports voice, data and video • Secure calls using standardized protocols (such as Secure Real-time Transport Protocol)
    [Show full text]
  • N2N: a Layer Two Peer-To-Peer VPN
    N2N: A Layer Two Peer-to-Peer VPN Luca Deri1, Richard Andrews2 ntop.org, Pisa, Italy1 Symstream Technologies, Melbourne, Australia2 {deri, andrews}@ntop.org Abstract. The Internet was originally designed as a flat data network delivering a multitude of protocols and services between equal peers. Currently, after an explosive growth fostered by enormous and heterogeneous economic interests, it has become a constrained network severely enforcing client-server communication where addressing plans, packet routing, security policies and users’ reachability are almost entirely managed and limited by access providers. From the user’s perspective, the Internet is not an open transport system, but rather a telephony-like communication medium for content consumption. This paper describes the design and implementation of a new type of peer-to- peer virtual private network that can allow users to overcome some of these limitations. N2N users can create and manage their own secure and geographically distributed overlay network without the need for central administration, typical of most virtual private network systems. Keywords: Virtual private network, peer-to-peer, network overlay. 1. Motivation and Scope of Work Irony pervades many pages of history, and computing history is no exception. Once personal computing had won the market battle against mainframe-based computing, the commercial evolution of the Internet in the nineties stepped the computing world back to a substantially rigid client-server scheme. While it is true that the today’s Internet serves as a good transport system for supplying a plethora of data interchange services, virtually all of them are delivered by a client-server model, whether they are centralised or distributed, pay-per-use or virtually free [1].
    [Show full text]
  • NAT Traversal About
    NAT Traversal About Some difficulties have been encountered with devices that have poor NAT support. FreeSWITCH goes to great lengths to repair broken NAT support in phones and gateway devices. In order to aid FreeSWITCH in traversing NAT please see the External profile page. Some routers offer an Application Layer Gateway feature which can prevent FreeSWITCH NAT traversal from working. See the ALG page for more information, including how to disable it. Using STUN to aid in NAT Traversal STUN is a method to allow an end host (i.e. phone) to discover its public IP address if it is located behind a NAT . Using this method requires a STUN server on the public internet and a client on the phone. The phone's STUN client queries the STUN server for it's own public IP and transmits the information it has received in it's connection information in the SIP packets it sends to the SIP server. Enable and configure STUN settings on your phone in order correctly to report your phone's contact information to FreeSWITCH when registering. Unfortunately, not all phones have a properly working STUN client. STUN servers This site contains a list of public STUN servers: https://gist.github.com/zziuni/3741933 stun.freeswitch.org is never guaranteed to be up and running so use it in production at your own risk. There are several open source projects to run your own STUN server, e.g. STUNTMAN Using FreeSWITCH built-in methods to aid in NAT Traversal nat-options-ping This parameter causes FreeSWITCH to regularly (every 20 - 40s) send an OPTIONS packet to NATed registered endpoints in order to keep the port on the clients firewall open.
    [Show full text]
  • Ipv6 DMZ Web Service Technology Design Guide
    IPv6 DMZ Web Service Technology Design Guide August 2014 Series Table of Contents Preface ........................................................................................................................................1 CVD Navigator .............................................................................................................................2 Use Cases .................................................................................................................................. 2 Scope ......................................................................................................................................... 2 Proficiency .................................................................................................................................. 2 Introduction .................................................................................................................................3 Technology Use Cases ............................................................................................................... 3 Use Case: Enable Native IPv6 Access for Network Traffic Between the Internet and a Web Server DMZ Network.............................................................................................................. 3 Use Case: Enable IPv6 Access for Network Traffic Between the Internet and an IPv4-only Web Server DMZ Network ..................................................................................................... 3 Design Overview ........................................................................................................................
    [Show full text]
  • Diffserv -- the Scalable End-To-End Qos Model
    WHITE PAPER DIFFSERV—THE SCALABLE END-TO-END QUALITY OF SERVICE MODEL Last Updated: August 2005 The Internet is changing every aspect of our lives—business, entertainment, education, and more. Businesses use the Internet and Web-related technologies to establish Intranets and Extranets that help streamline business processes and develop new business models. Behind all this success is the underlying fabric of the Internet: the Internet Protocol (IP). IP was designed to provide best-effort service for delivery of data packets and to run across virtually any network transmission media and system platform. The increasing popularity of IP has shifted the paradigm from “IP over everything,” to “everything over IP.” In order to manage the multitude of applications such as streaming video, Voice over IP (VoIP), e-commerce, Enterprise Resource Planning (ERP), and others, a network requires Quality of Service (QoS) in addition to best-effort service. Different applications have varying needs for delay, delay variation (jitter), bandwidth, packet loss, and availability. These parameters form the basis of QoS. The IP network should be designed to provide the requisite QoS to applications. For example, VoIP requires very low jitter, a one-way delay in the order of 150 milliseconds and guaranteed bandwidth in the range of 8Kbps -> 64Kbps, dependent on the codec used. In another example, a file transfer application, based on ftp, does not suffer from jitter, while packet loss will be highly detrimental to the throughput. To facilitate true end-to-end QoS on an IP-network, the Internet Engineering Task Force (IETF) has defined two models: Integrated Services (IntServ) and Differentiated Services (DiffServ).
    [Show full text]
  • NAT and NAT Traversal Lecturer: Andreas Müller [email protected]
    NAT and NAT Traversal lecturer: Andreas Müller [email protected] NetworkIN2097 - MasterSecurity, Course WS 2008/09, Computer Chapter Networks, 9 WS 2009/2010 39 NAT: Network Address Translation Problem: shortage of IPv4 addresses . more and more devices . only 32bit address field Idea: local network uses just one IP address as far as outside world is concerned: . range of addresses not needed from ISP: just one IP address for all devices . can change addresses of devices in local network without notifying outside world . can change ISP without changing addresses of devices in local network . devices inside local net not explicitly addressable, visible by outside world (a security plus). NetworkIN2097 - MasterSecurity, Course WS 2008/09, Computer Chapter Networks, 9 WS 2009/2010 40 NAT: Network Address (and Port) Translation rest of local network Internet (e.g., home network) 10.0.0/24 10.0.0.1 10.0.0.4 10.0.0.2 138.76.29.7 10.0.0.3 All datagrams leaving local Datagrams with source or network have same single source destination in this network NAT IP address: 138.76.29.7, have 10.0.0/24 address for different source port numbers source, destination (as usual) NetworkIN2097 - MasterSecurity, Course WS 2008/09, Computer Chapter Networks, 9 WS 2009/2010 41 NAT: Network Address Translation Implementation: NAT router must: . outgoing datagrams: replace (source IP address, port #) of every outgoing datagram to (NAT IP address, new port #) . remote clients/servers will respond using (NAT IP address, new port #) as destination addr. remember (in NAT translation table) every (source IP address, port #) to (NAT IP address, new port #) translation pair -> we have to maintain a state in the NAT .
    [Show full text]
  • Iptables with Shorewall!
    Iptables with shorewall! Table of Contents 1. Install swarmlab-sec (Home PC) . 1 2. shorewall . 1 2.1. Installation . 2 3. Basic Two-Interface Firewall. 2 4. Shorewall Concepts . 3 4.1. zones — Shorewall zone declaration file . 3 4.2. interfaces — Shorewall interfaces file. 4 4.3. policy — Shorewall policy file . 4 4.4. rules — Shorewall rules file . 4 4.5. Compile then Execute . 4 5. Three-Interface Firewall. 5 5.1. zones . 6 5.2. interfaces . 6 5.3. policy . 7 5.4. rules . 7 5.5. masq - Shorewall Masquerade/SNAT definition file . 7 5.6. snat — Shorewall SNAT/Masquerade definition file . 8 5.7. Compile and Execute . 8 1. Install swarmlab-sec (Home PC) HowTo: See http://docs.swarmlab.io/lab/sec/sec.adoc.html NOTE Assuming you’re already logged in 2. shorewall Shorewall is an open source firewall tool for Linux that builds upon the Netfilter (iptables/ipchains) system built into the Linux kernel, making it easier to manage more complex configuration schemes by providing a higher level of abstraction for describing rules using text files. More: wikipedia 1 NOTE Our docker instances have only one nic to add more nic’s: create netowrk frist docker network create --driver=bridge --subnet=192.168.0.0/16 net1 docker network create --driver=bridge --subnet=192.168.0.0/16 net2 docker network create --driver=bridge --subnet=192.168.0.0/16 net3 then connect network to container connect network created to container docker network connect net1 master docker network connect net1 worker1 docker network connect net2 master docker network connect net2 worker2 now let’s look at the following image 2.1.
    [Show full text]
  • Autoqos for Voice Over IP (Voip)
    WHITE PAPER AUTOQoS FOR VOICE OVER IP Last Updated: September 2008 Customer networks exist to service application requirements and end users efficiently. The tremendous growth of the Internet and corporate intranets, the wide variety of new bandwidth-hungry applications, and convergence of data, voice, and video traffic over consolidated IP infrastructures has had a major impact on the ability of networks to provide predictable, measurable, and guaranteed services to these applications. Achieving the required Quality of Service (QoS) through the proper management of network delays, bandwidth requirements, and packet loss parameters, while maintaining simplicity, scalability, and manageability of the network is the fundamental solution to running an infrastructure that serves business applications end-to-end. Cisco IOS ® Software offers a portfolio of QoS features that enable customer networks to address voice, video, and data application requirements, and are extensively deployed by numerous Enterprises and Service Provider networks today. Cisco AutoQoS dramatically simplifies QoS deployment by automating Cisco IOS QoS features for voice traffic in a consistent manner and leveraging the advanced functionality and intelligence of Cisco IOS Software. Figure 1 illustrates how Cisco AutoQoS provides the user a simple, intelligent Command Line Interface (CLI) for enabling campus LAN and WAN QoS for Voice over IP (VoIP) on Cisco switches and routers. The network administrator does not need to possess extensive knowledge of the underlying network
    [Show full text]
  • AES67-101: the Basics of AES67
    AES67-101: The Basics of AES67 Anthony P. Kuzub IP Audio Product Manager [email protected] www.Ward-Beck.Systems TorontoAES.org Vice-Chair Ward-Beck.Systems - Audio Domains PREAMPS.audio FILTERING.audio PATCHING.audio MUTING.audio DB25.audio VUMETERS.audio PANELS.audio MATRIXING.audio BUSSING.audio XLR.audio SUMMING.audio AMPLIFY.audio CONSOLES.audio GROUNDING.audio The least you SHOULD know about networking: The physical datalink networks transported sessions presented by the application TX RX DATA 7 - Application DATA PATCHING.audio AES67.audio MATRIXING.audio 2110-30.AES67.audio 6 - Presentation BUSSING.audio 5 - Session 4 - Transport ROUTING.audio IGMP.audio 3 - Network SWITCHING.audio CLOCKING.audio 2 - Data Link MULTICASTING.audio 1 - Physical RJ45.audio The Road to Incompatibility… Dante RAVENNA QLAN Livewire Control & Monitoring Proprietary HTTP, Ember+ TCP, HTTP HTTP, Proprietary Proprietary Proprietary Discovery Bonjour Proprietary Connection Proprietary RTSP, SIP, IGMP Proprietary Proprietary, HTTP, IGMP Management Session Description Proprietary SDP Proprietary Channel # Transport Proprietary, IPv4 RTP, IPv4 RTP, IPv4 RTP, IPv4 Quality of Service DiffServ DiffServ DiffServ DiffServ/802.1pq Encoding & Streaming L16-32, ≤4 ch/flow L16-32, ≤64 cha/str 32B-FP, ≤16 ch/str L24, st, surr Synchronization PTP1588-2002 PTP1588-2008 PTP1588-2008 Proprietary Media Clock 44.1kHz, 192kHz 44.1kHz – 384kHz 48kHz 48kHz AES67-2013 Standard for audio applications of networks: High-performance streaming audio-over-IP interoperability References
    [Show full text]
  • 5G and Net Neutrality
    University of Pennsylvania Carey Law School Penn Law: Legal Scholarship Repository Faculty Scholarship at Penn Law 2019 5G and Net Neutrality Christopher S. Yoo University of Pennsylvania Carey Law School Jesse Lambert University of Pennsylvania Law School Follow this and additional works at: https://scholarship.law.upenn.edu/faculty_scholarship Part of the Administrative Law Commons, Communication Technology and New Media Commons, European Law Commons, Internet Law Commons, Law and Economics Commons, Science and Technology Law Commons, and the Transnational Law Commons Repository Citation Yoo, Christopher S. and Lambert, Jesse, "5G and Net Neutrality" (2019). Faculty Scholarship at Penn Law. 2089. https://scholarship.law.upenn.edu/faculty_scholarship/2089 This Article is brought to you for free and open access by Penn Law: Legal Scholarship Repository. It has been accepted for inclusion in Faculty Scholarship at Penn Law by an authorized administrator of Penn Law: Legal Scholarship Repository. For more information, please contact [email protected]. 5G and Net Neutrality Christopher S. Yoo† and Jesse Lambert‡ Abstract Industry observers have raised the possibility that European network neutrality regulations may obstruct the deployment of 5G. To assess those claims, this Chapter describes the key technologies likely to be incorporated into 5G, including millimeter wave band radios, massive multiple input/multiple output (MIMO), ultra-densification, multiple radio access technologies (multi-RAT), and support for device-to-device (D2D) and machine-to-machine (M2M) connectivity. It then reviews the business models likely to be associated with 5G, including network management through biasing and blanking, an emphasis on business-to- business (B2B) communications, and network function virtualization/network slicing.
    [Show full text]
  • Net Neutral Quality of Service Differentiation in Flow-Aware Networks
    AGH University of Science and Technology Faculty of Electrical Engineering, Automatics, Computer Science and Electronics Ph.D. Thesis Robert Wójcik Net Neutral Quality of Service Differentiation in Flow-Aware Networks Supervisor: Prof. dr hab. in˙z.Andrzej Jajszczyk AGH University of Science and Technology Faculty of Electrical Engineering, Automatics, Computer Science and Electronics Department of Telecommunications Al. Mickiewicza 30, 30-059 Kraków, Poland tel. +48 12 634 55 82 fax. +48 12 634 23 72 www.agh.edu.pl www.eaie.agh.edu.pl www.kt.agh.edu.pl To my loving wife, Izabela Acknowledgements Many people have helped my throughout the course of my work on this dissertation over the past four years. I would like to express my gratitude to all of them and to a few in particular. First of all, I would like to thank my supervisor, Professor Andrzej Jajszczyk, for his invaluable comments, advice and constant support during my whole research. I am sure that without his patience, broad vision and motivation, completing this dissertation would not have been possible. I have been fortunate to meet James Roberts, the founder of the original con- cept of Flow-Aware Networking, and discuss several issues with. Our joint work on the project concerning FAN architecture was a milestone in my vision of the future Internet and strongly contributed to my understanding of the ideas and problems related to admission control, scheduling and network design. Much of my experience has been formed through the collaboration with Jerzy Domżał, my friend and collegue. His insight and remarks concerning various issues have contributed significantly to the improvement of my results.
    [Show full text]
  • Peer-To-Peer NAT-Traversal for Ipsec
    Peer-to-Peer NAT-Traversal for IPsec y Anonymized peer registration y Endpoint discovery and relaying y Peer-initiated hole punching y IKEv2 Internet draft in preparation [email protected] [email protected] IKEv2 Mediation IKEv2 Mediation Server Mediation Connection Connection NAT Router NAT Router 1.2.3.4:1025 5.6.7.8:3001 IKEv2 Mediated Connection 10.1.0.10:4500 10.2.0.10:4500 Direct IPsec Tunnel using NAT-Traversal Peer Alice Peer Bob www.strongswan.org The double NAT case - where punching holes counts! ● You are selling automation systems all over the world. In order to save on travel expenses you want to remotely diagnose and update your deployed systems via the Internet. But security counts – thus IPsec is a must! Unfortunately both you and your customer are behind NAT routers so that no direct VPN connection is possible. You are helplessly blocked! ● You own an apartment at home, in the mountains or even abroad. You want to remotely control the heating or your sophisticated intrusion detection system via ADSL or Cable access. But since you and your apartment are separated by two NAT routers your are helplessly blocked. How it works! ● Two peers want to set up a direct IPsec tunnel using the established NAT traversal mechanism of encapsulating ESP packets in UDP datagrams. Unfortunately they cannot achieve this by themselves because neither host is seen from the Internet under the standard IKE NAT-T port 4500. Therefore both peers need to set up a mediation connection with an IKEv2 mediation server. In order to prevent unsolicited connection attempts by foreign peers, the mediation connections use randomized pseudonyms as IKE peer identities.
    [Show full text]