NetBorder Session Controller Manual 2.1 Last update: 2015/01/09 Sangoma Technologies

Transcription

1 NetBorder Session Controller Manual 2.1 Last update: 2015/01/09 Sangoma Technologies

2 Table of Contents Overview... 3 Form Factor... 5 Unique Features... 9 Virtual Machine Ready Easy to use WebGUI SBC Features Signaling and Media Theory of Operation SIP and SBC Sessions SBC Use Case Overview SBC Scenario Overview Usage Scenarios SIP Trunking Carrier SIP Trunking Enterprise IP-PBX SIP Trunking Microsoft Lync Hosted PBX and Remote Users SBC Remote Office User Interface WebUI Interface Console Interface RESTful Interface Product Information U Carrier Front Pannel U Carrier Rear Pannel U Carrier Front Pannel U Carrier Rear Pannel U Enterprise Front Pannel U Enterprise Rear Pannel Shipping Contents Factory Configuration First Boot & Initial Setup Power Connection Initial WebGUI Connection Change Default Password Console SSH Configuration SBC License... 76

3 Software SBC Software SBC Installation SBC Quick Config Overview Network Configuration Singaling Interfaces Media Interfaces IP Troubleshooting SBC General Configuration SIP Domain Configuration SIP Profile Configuration Media Profile Configuration SIP Trunk (Gateway) Configuration Call Routing Configuration WebGUI: Basic Call Routing Advanced XML Call Routing Advanced XML Syntax SIP Header Manipulation WebGUI: Basic Header Manipulation SBC Advanced Configuration SBC Upper Registration SBC Security SBC Threat Protection SIP Firewall IP Firewall SBC Intrusion Detection SIP Rate Limiting Applying Configuration SBC Operation SBC Contol Panel SBC Dashboard Overview SBC Session Status SBC Troubleshooting Options SBC Backup SBC Restore SBC Upgrade SBC Monitoring SBC Notifications SBC Troubleshooting SBC PCAP Tracing

4 Factory Reset and Reboot Professional Services Support Information Appendix Frequently Asked Questions

5 Overview The Sangoma SBC (also referred to as NSC, NetBorder Session Controller or Vega esbc ) is a family of advanced and flexible Session Border Controllers that allow you to interconnect different SIP networks securely to perform SIP trunking and general SIP call routing with its advanced GUI or XML-based routing engine. Overview Subtopic Form Factor Unique Features Virtual Machine Ready Ease to use WebGUI SBC Features Signaling and Media Markets Sangoma SBC were designed to address three market segments Carrier Enterprise Virtualization (NFV) Last update: 2015/01/09 00:09:25 Page 3 of 188

6 Feature Overview Virtual Machine ready Easy to use Web Interface Advanced XML Routing Engine Dynamic Load Balancing and Call Routing Hybrid decoupled design (Hardware-Assisted RTP even when running on a virtual machine) SIP Intrusion Prevention SIP Registration Scan Attack Detection SIP Request Rate Limiting SIP Friendly Load Limitation SIP Registration Pass-thru SIP Header Normalization SIP Malformed Packet Protection Topology Hiding Intelligent media anchoring/release DDoS / DoS Attack Protection RTCP Statistics Reports Call Access Control (Limits call rate and total calls per user or IP) Call Security with TLS / SRTP Advanced NAT Traversal Capabilities Least Cost Routing Full RTP Transcoding (G.711, G.722, G.729, G.726, G.723.1, ilbc, AMR, G.722.1) T.38 Fax Relay IP Firewall RADIUS CDR and Authentication HTTP XML-based CDR ENUM Routing VLAN QoS (ToS or DSCP) Multiple flexible form factors Scalable from 25 to 4000 sessions/calls (field upgradable) Last update: 2015/01/09 00:09:25 Page 4 of 188

7 Form Factor Netborder Carrier SBC: 1U Redundant Power Supply AC RAID SSD 1U Rack-mount and 2U Rack-mount Telco standard size 20 Calls Per Second (CPS) 75 Capacity 4000 sessions (4000 calls) Last update: 2015/01/09 00:09:25 Page 5 of 188

8 Netborder Carrier SBC: 2U Redundant Power Supply AC & DC RAID SSD 1U Rack-mount and 2U Rack-mount Telco standard size 20 Calls Per Second (CPS) 75 Capacity 4000 sessions (4000 calls) Last update: 2015/01/09 00:09:25 Page 6 of 188

9 Vega Enterprise SBC: 1U 1U Enterprise Appliance 1U Rack-mount Small footprint Calls per second (CPS) 10 Capacity 250 sessions (250 calls) Last update: 2015/01/09 00:09:25 Page 7 of 188

10 Vega VM Enterprise SBC Virtual Machine (software only, no hardware) Vega VM Enterprise Hybrid SBC Virtual Machine with hardware-assisted RTP Last update: 2015/01/09 00:09:25 Page 8 of 188

11 Unique Features Sangoma SBC provides unique end to end solutions for both Carriers and Large Enterprise to SMB and end customers. Flexible Deployment Options Support for SIP Trunking and Access (Remote User) on single platform. Common code base across all SBC platforms. Common deployment and management end to end: CPE to Carrier/Provider Simplified Licensing Single license provides all SBC features. There are no hidden costs, or per feature pricing. All premium features under single license Transcoding Security SRTP Unlimited Registrations Signaling and Media Tracing Sangoma SBCs support native SIP Signalling and RTP Media PCAP tracing on the appliance. This feature is a must in any kind of SBC debugging, and provides very quick troubleshooting turnaround times. Without native media tracing feature. RTP/Media capture is only possible via Ethernet Switch mirror tapping. In large network deployments such tapping/tracing requests must be made to IT departments. Which delay s troubleshooting and ultimately customer resolution response. Last update: 2015/01/09 00:09:25 Page 9 of 188

12 Scalable Transcoding Included Transcoding comes standard on Carrier SBC Enterprise SBC VM Hybrid Enterprise SBC Furthermore trans-coding is supported on all sessions. ** 2000 session SBC will support 2000 trans-coded sessions of G729. Carrier and Enterprise features on one platform SIP Trunking and Peering Access: Remote User / Upper Registration Sangoma SBC support both SIP Trunking and Access functionality simultaneously on single system. Flexible Deployment Options Carrier 1U and 2U Appliance Enterprise 1U Appliance Virtualized SBC (Software Only) SDN/NFV deployments Amazon AMI Images Supports all Virtualization platforms Hyper-V VMware Xen and XenServer (Citrix) VirtualBox KVM VM Hybrid SBC VM SBC (Software) + Hardware: Ethernet Media/RTP Device Last update: 2015/01/09 00:09:25 Page 10 of 188

13 Softswitch Features Advanced Dialplan Call Routing GUI XML Centralized Database Routing via HTTP/S Load balancing and Forking Internal database support for CDR MongoDB CDR support Carrier Hardware Appliance Redundant Power Supply AC & DC RAID SSD 1U Rack-mount Telco standard size 20 Calls Per Second (CPS) 75 Capacity 4000 sessions (4000 calls) Enterprise Hardware Appliance 1U Rack-mount Small footprint Calls per second (CPS) 10 Capacity 250 sessions (250 calls) Virtual Machine (Software Only) Software Only Refer to VM Below Virtual Machine + D150 External Hardware Network Device. All benefits of VM with Hardware RTP and Media processing Refer to VM Hybrid Below Last update: 2015/01/09 00:09:25 Page 11 of 188

14 Virtual Machine Ready Description Ability to run SBC is software only mode. Ability to run inside a Virtual Machine. Lower Price Customers that have existing VM infrastructure do not have to go through the expense of yet another box. Another box requires power,space, cables and offers another point of failure. Redundancy VM infrastructure provides unmatched flexibility, redundancy and durability. VMWare ESX infrastructure can run a single VM on multiple HW platforms allowing carrier grade Flexibility hardware redundancy. VM instance can be moved, copied and backed up. VM offers upgrades with minimal down time by allowing IT to build and test new VM before shutting down the one in production. Limitations SBC running in VM as a software only solution will have limited capacity. Limited capacity is primarily due to RTP media flowing the the VM. Software Trascoding will further reduce the capacity. Licensing is based on USB Key. VM Hybrid Ability to run SBC is software mode. Ability to run inside a Virtual Machine. Offloading Media RTP onto a D150 External Network Device Best of both worlds: VM + Dedicated Cost effective external network device. Last update: 2015/01/09 00:09:25 Page 12 of 188

15 VM Model is preserved The D150 External Network Device maintains the VM architecture. The D150 is External and communicates via Ethernet. One does not have to open the VM server and install any non-standard hardware. SBC licensing is based on the D150 hardware device, this allows VM to be moved from one hardware platform to another. Scale Ability to scale while running in VM mode. RTP and Media processing is offloaded onto a D150 External Network Device Full Transcoding any to any supported. Ability to add more D150 External Network Devices in order to scale higher. Sangoma Exclusive No other vendor supports such solution Limitations Even though RTP is offloaded on the D150 Network Device, the VM will be limited in processing large number of calls per second. Due to variable performance metrics of VM, all installations must be stress tested before going into production Last update: 2015/01/09 00:09:25 Page 13 of 188

16 Easy to use WebGUI Sangoma SBC uses a modern WebGUI for configuration, operation, troubleshooting and management. Other vendors use complex CLI and text based interfaces Documentation built in Along with a standard user manual, Sangoma SBC documentation is embedded in the GUI. Each GUI field has a help button to display the function and feature of the field. Dashboard Stats View SBC Traffic and capacity on single page. View call statistics (CDR) and error statistics (RTCP) from the GUI Ability to search and identify bad quality calls and pre-empt the customer call Monitoring and Notifications notifications on all SBC metrics Error messages Voice Quality System Thresholds Capacity Thresholds RESTful API Sangoma SBC s provide RESTful Web API for automatic easy provisioning. A third party SoftSwitch or application can easily view SBC configuration via Web API s. VI in the Browser For advanced users, Sangoma WebGUI offers vi editor in browser for rapid routing rule editing and development. Last update: 2015/01/09 00:09:25 Page 14 of 188

17 SBC Features Simple Licensing Sangoma has very intuitive licensing model. Product is licensed based on number of sessions. A session is considered a single leg of the call. Thus two sessions are needed to complete a full duplex call. Example: 4000 session SBC can provide (4000 call capacity) Simple and Predictable Aside from sessions licensing there are NO Per feature licensing Per user licensing Per codec licensing All features, codecs are included in the license. Sangoma only counts INVITE as a session. This allows a network planner a predictable SBC capacity in every situation. Other vendors use draconian licensing schemes Example: Phone Registration counts as a sessions when the call is made In this case SBC capacity is reduced further due to licensing model. Media Anchoring and Complex Calls Proxy based PBXs require Sangoma SBC when connected to a SIP trunk. PBX need an SBCs in order to perform complex call functions such as blind transfers and call forking. PBX Isolation Sangoma SBC is able to isolate the enterprise PBX from the ITSP and provide riche media functions. Without the Sangoma SBC acting as the demarcation point between the PBX and ITSP, unwanted SIP messages such as REFER would reach the ITSP. In such cases ITSP would simply reject such messages causing call failures. In other cases ITSP has strict rules as to which call flows are supported and allowed. Last update: 2015/01/09 00:09:25 Page 15 of 188

18 SIP-X and ezuce Sangoma full interoperates with SIP-X based PBXs and facilitates secure demarcation point. While offering media anchoring support to the PBX. Advanced XML Routing and Database Support Sangoma SBC s have SoftSwitch style routing plans. Users can configure unlimited number of dial plans/routing rules per sip profile. All routing plans can be applied live without system interruption. The rules can be very simple or very complex. They support complex syntax for advanced logic and customization. Database Support Complex routing rules, DIDs, and ACL lists are usually stored in internal or external Databases. Sangoma SBC support external database access via HTTP requests. On each routing table entry an HTTP request to an external DB can used to fetch routing information. Sangoma SBC support internal database via mysql for routing plans, ACL lists and etc. On each routing table entry an HTTP request to an internal DB can be used to fetch routing information. HTTP access allows user to map any DB info into the Sangoma SBC routing logic. Per Message Routing and Header Manipulation Routing rules are executed for each SIP message. Actions can be taken based on any SIP message that flows through the SBC. SIP Headers can be modified using regular expressions for each SIP message. Advanced Networking Most large networks require complex networking support. Sangoma SBC supports: VLAN, DiffServ, QOS, Firewall, etc. Last update: 2015/01/09 00:09:25 Page 16 of 188

19 Load Balancing and Least Cost Routing Sangoma SBC offers carrier features to the Enterprise SBC. Load Balancing allows Sangoma SBC to distribute call load to number of ITSP providers. In case of ITSP failure, the call load can be re-routed to other ITSPs. Least Cost Routing tables can be used to route calls based on route costs. Takes advantage of favorable rates. Media Server and Trasncoding Sangoma SBCs offer rich media services along with full featured: Transcoding. VQE Features Echo Cancellation, Noise Reduction, AGC, etc Codecs G729, G722, AMR, etc Fax (FoIP) T.38 Pass-Through T.38 Relay (roadmap) T.38 SRTP (roadmap) Some codes such as AMR-WB will reduce session capacity in certain scenarios. Configurable Load Limit Messages What separates the Sangoma SBC from others is that when this threshold is reached the SBC will reply with a SIP 503 Service Unavailable message which tells the originator to try an alternate destination. In other SIP appliances once the CPU threshold reaches a certain point the traffic is disrupted by means of calls dropping, loss of RTP (if media is flowing through), or registrations becoming corrupted. Configurable Load Limit Message Sangoma SBC allows one to configure the load limit message: 501, 403 etc Last update: 2015/01/09 00:09:25 Page 17 of 188

20 This allows greater flexibility and customization to custom network needs. Last update: 2015/01/09 00:09:25 Page 18 of 188

21 Signaling and Media SIP RFC SIP V2 / RFC 3261 RFC 3261 Session Initiate Protocol RFC 2976 SIP INFO Method RFC 3515 Refer Method RFC 2327 Session Description Protocol RFC 3581 An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing RFC 3892 Referred-By Mechanism RFC 3891 Replaces Header RFC 3551: RTP/AVP RFC 3515: REFER RFC 2617: HTTP Digest Authentication SDP Bypass SBC exports all SS7 parameters via SIP custom X headers. Call Routing Configurable and extendable XML-based dial plan and routing rules XML Dialplan can be used to create complex routing scenarios between SIP and TDM. Call routing based on any call parameter present in a SIP message. Ability to use external applications to build complex routing logic* Media Processing & Transcoding Wide range of codecs supported for any to any codec negotiation. G.711 G G.726 ilbc G.729AB GSM G.722 AMR G Last update: 2015/01/09 00:09:25 Page 19 of 188

22 Echo Cancellation & VQE Telco grade hardware based echo canceling and Voice processing G with 128ms tail Noise cancellation DTMF Removal DTMF Detection FAX Detection Automatic Gain Control DTMF Detection and Generation Sangoma SBC gateway supports multiple DTMF internetworking scenarios. RFC 2833 Tone Relay In-band SIP INFO Hardware and software DTMF detection and generation Management and Configuration Sangoma SBC configuration, operation and troubleshooting are designed to be flexible. Web GUI On the fly configuration without service interruption. Command line interface via ssh and usb to serial Call detail records in XML format Detailed logs with user configurable file size and auto rotation Monitoring SNMP v1, 2, 3 RTCP Accounting Radius Last update: 2015/01/09 00:09:25 Page 20 of 188

23 Last update: 2015/01/09 00:09:25 Page 21 of 188

24 Theory of Operation What is an SBC SBC stands for Session Border Controller Simplified Explanation SIP Firewall SIP Security Device Session Real time interactive communications Voice, Video, multimedia SIP or H323 Signaling Border IP to IP network border SIP trunks to service providers Remote worker access Internal Enterprise / External Enteprise Control Security & SLA assurance Revenue & cost optimization Compliance Last update: 2015/01/09 00:09:25 Page 22 of 188

25 Why use an SBC SBC are installed at the edge of VoIP Networks to facilitate end to end VoIP transmission without compromising network security Essential for Several reasons: New security issues introduced with SIP protocol Fix Interoperability issues Implementation of UC/Collaboration features SBC are typically implemented as Back to Back User Agents (B2BUA) All SIP and Media (voice) traffic transit through SBCs B2BUA Explained A back to back user agent (B2BUA) is a logical network element in the Session Initiation Protocol (SIP) applications It operates between two endpoints in a communication session and divides the communication channel into two different call legs It mediates SIP signalling between both ends of the call B2BUAs are often implemented within media gateways Last update: 2015/01/09 00:09:25 Page 23 of 188

26 Last update: 2015/01/09 00:09:25 Page 24 of 188

27 What are User Agents? Theory Subtopics SIP and SBC Sessions SBC Use Case Overview SBC Scenario Overview Last update: 2015/01/09 00:09:25 Page 25 of 188

28 SIP and SBC Sessions SIP Session 1 Call = 1 session when call is direct SBC Session SBC is a back to back user agent. A single SBC call will crate 2 SIP sessions. For licensing purposes Sangoma uses SBC Sessions to describe the session capacity. Thus License of 500 sessions is equivalent to 500 SBC Sessions which translates to 500 end to end calls. Thus: 1 Session is equal to 1 Call. Last update: 2015/01/09 00:09:25 Page 26 of 188

29 Sangoma SBC License sessions refer to INVITE messages only. Registrations and other SIP messages are not counted as part of license capacity. This makes the licensing and scaling of Sangoma SBC s really simple and intuitive. Last update: 2015/01/09 00:09:25 Page 27 of 188

30 SBC Use Case Overview Sangoma SBC acts as the interface between 2 SIP networks to: Solve firewall and NAT issues Normalize and fix SIP messaging Register with SIP trunking provider Hide Network Topology Secure SIP and Voice (TLS, SRTP) Codec Conversion (Transcoding) Why SBC Real Time IP Communications are Complex Sessions initiated from inside or outside firewalls NAT QOS is needed to provide voice quality over internet Interoperability problem between vendors Security and Fraud State full session security Media security and encryption Session Limits: call per second, max calls per user Intrusion detection and prevention Standard Firewalls are not enough Unlike firewalls SBC maintains session state SBC opens pinholes for ports associated with session Firewall will close and reopen different port numbers breaking the session. Last update: 2015/01/09 00:09:25 Page 28 of 188

31 SBC inspects, controls and manipulates all network layers: 2 to 7 Firewall only works on layer: 2 to 4 (IP/TCP) Enterprise Security Threats Denial of Services Call/registration overlaod Malformed messages (fuzzing) Configuration errors Mis-configured devices Operator and applicatoin errors Theft of service / Fraud Unauthorized users Unauthorized media types BYOD Smartphones running unauthorized apps Viruses and Malware attacking your VoIP network Firewall is not enough Traditional firewalls cannot: Prevent SIP-specific overload / SIP DOS Open/Close RTP media ports in sync with SIP signaling Track session state and provide uninterrupted service Perform internetworking or security on encrypted sessions Solve multi-vendor SIP interoperability Topology Hiding SBC do all of the above. Last update: 2015/01/09 00:09:25 Page 29 of 188

32 SBC Scenario Overview SBC Use Case Overview Connect remote workers securely to a VoIP infrastructure Connect Branch Offices together securely without needing VPNs Smoothly integrate legacy VoIP systems into a unified infrastructure Evolve VoIP infrastructures while preserving investment and avoiding forklift upgrades Integrate VoIP disaster recovery solutions Ensure compliance in VoIP networks Ensure PSTN equivalency is achieved quickly and smooth when migrating to a SIP trunking architecture Protect VoIP assets from the security threats posed by a migration to SIP trunking Advanced security features reduce risk for SIP trunk deployment Improved business continuity with high availability voice services Simplified approach to expansion of call capacity Reduce overheads with lowered call costs and simplified integration with SIP providers SBC for IP PBX to SIP Trunks Known demarcation point Reduces interop issues/resource with core Transcoding if required Last update: 2015/01/09 00:09:25 Page 30 of 188

33 Multi ITSP Support for IP-PBX All advantages of SBC for SIP trunks Least Cost Routing Load balancing Lync Interworking with IP-PBX All advantages of SBC for SIP trunks Least Cost Routing Load Balancing Last update: 2015/01/09 00:09:25 Page 31 of 188

34 SBC For IP-PBX to SIP Trunks Known demarcation point Reduces interop issues/resource with core Transcoding if required Protects Hosted PBX from DDOS and attacks Registration Storms Identity Theft Last update: 2015/01/09 00:09:25 Page 32 of 188

35 Usage Scenarios SIP Trunking Carrier SIP Trunking Enterprise IP-PBX SIP Trunking Microsoft Lync Hosted PBX and Remote Users SBC Remote Office Last update: 2015/01/09 00:09:25 Page 33 of 188

36 SIP Trunking Carrier Carriers offering SIP trunking services must provide a secure environment that their customers can trust, especially when these services are delivered over the internet. Carriers also aim to reduce or eliminate interoperability difficulties between their equipment and that of their clients. The security of a VoIP network can be breached at either the service provider s side or on the customer s side. The carrier must not only protect their network, they must also protect their customers network from being compromised through weaknesses on the carrier side network. The best way for an enterprise to control access to their network and protect it is to install an Enterprise Session Border Controller (esbc). This is also best practice to solve network traversal challenges presented by corporate firewalls, transcoding requirements, and fix SIP interoperability issues. However, if the client-side network does not have an SBC installed, the carrier-side SBC can manage most of these problems. Last update: 2015/01/09 00:09:25 Page 34 of 188

37 The carrier-side SBC also enables SIP phones at remote locations, such as a home office, to interoperate with a SIP trunk, where the SIP phone is typically behind a natted firewall. The SBC on the carrier-side may also be required to perform transcoding and SIP compatibility operations if these functions are not available on the client side. Transcoding is required when different voice encoding schemes are used at end-points on either side of the call. The endpoints should negotiate for the best codec available to all devices on the call, but in some cases, end-points may not share a common codec. Transcoding corrects this problem by offering a codec bridge between incompatible devices. SIP is a very flexible standard and there are many flavors of this protocol. While different implementations may conform to the SIP standard in general, it is possible that a mixture of devices from different manufacturers may not interoperate correctly. The carrier-side SBC ensures that this problem is corrected between client-side SIP devices, and end-points connected through the Internet Telephone Service Provider (ITSP). Figure 1 illustrates how the Internet Telephone Service Provider (ITSP) is protected by a Sangoma carrierclass NetBorder session border controller, while each client is protected by an esbc. Carrier-class and enterprise SBCs differ only in the capacity that they can handle. The Sangoma NetBorder carrier-class SBCs scale up to 4,000 calls, whereas the Vega enterprise-class SBCs come in a range of capacities from 25 calls to 250 calls. Last update: 2015/01/09 00:09:25 Page 35 of 188

38 SIP Trunking Enterprise IP-PBX Local and long distance dialing charges are greatly reduced by using Voice over Internet Protocol (VoIP) delivered via SIP trunks, rather than legacy Public Switched Telephone Network (PSTN) via TDM trunks. SIP trunks also allow for much greater flexibility. For example, in addition to just voice, Unified Communications (UC) can be delivered, including presence, video conferencing, file sharing and screen sharing. However, using VoIP over a public medium such as the internet does open both the Internet Telephone Service Provider (ITSP) network and the corporate network to vulnerabilities that must be properly addressed. Just as the firewall protects the data network, an SBC is required to protect both the data and voice network when VoIP is integrated into the system. Last update: 2015/01/09 00:09:25 Page 36 of 188

39 The example shown in Figure 1 illustrates a legacy PBX on the corporate premises which has been converted to use SIP trunks rather than TDM trunks. In this example, the SIP trunks are provided by the ITSP and delivered over the internet. A Vega gateway converts between SIP and the TDM interface used by the PBX. An SBC guards against toll fraud and navigates across the firewall. It also protects the corporate network. The ITSP protects its network with a carrier class Session Border Controller (SBC) that is designed to handle the high call volumes that the carrier will experience and provide the High Availability (HA) features required for carrier operations. The corporate network is protected by a Vega esbc (enterprise SBC) which is sized to handle moderate call volumes. Both SBCs provide the same functionality, including prevention of toll fraud, denial of service and eavesdropping. They enable VoIP traffic to navigate firewalls and ensure interoperability between different SIP implementations. Last update: 2015/01/09 00:09:25 Page 37 of 188

40 SIP Trunking Microsoft Lync In the past few years, SIP Trunking has become one of the hottest topics in IP Communications. At the same time, Microsoft Lync has been driving a frenetic level of activity in the Unified Communications Space. With the release of Lync 2013, these two topics have converged, as Lync 2013 now has native support for SIP Trunks. However, because this connectivity is limited to Microsoft Certified SIP Trunks, those who wish to use them are denied many of the advantages of downward price pressure, improved connectivity options and the flexibility that general SIP Trunks offer. Sangoma SBCs solve this issue by allowing Lync to reliably and securely connect to standard SIP Trunks, delivering maximum flexibility and security to those wanting to connect to the PSTN through any SIP trunking provider. Last update: 2015/01/09 00:09:25 Page 38 of 188

41 Hosted PBX and Remote Users The proliferation of VoIP technology has enabled a range of new services that were previously not costeffective or even practical using the legacy Public Switched Telephone Network (PSTN). This use case describes a hosted PBX service, but could just as easily apply to other services such as hosted Interactive Voice Response (IVR) servers or hosted contact centers. The VoIP service provider supplies SIP trunks and cost-effective virtual PBX services using a large, robust and redundant platform. The corporate client gets all the advantages of a PBX without the need to install, maintain or manage the PBX system. A common way to supply these services is across the internet, which delivers a universal and inexpensive access method, although the medium itself is insecure. It is essential that this off-site service be delivered securely. Just as the firewall provides security to the data network, the SBC provides security to the VoIP network and individual VoIP calls. The SBC protects against toll fraud and other vulnerabilities which VoIP can introduce. The SBC in the VoIP service provider s network and the esbc in the corporation s network provide needed security and privacy for the connection. If privacy of the voice channel is important, encryption can be applied to voice traffic. Sangoma implements encryption using their transcoding engine. Transcoding may be required if disparate equipment are unable to negotiate a common codec. Transcoding also allows for adjustments to the trade-off between bandwidth consumption and quality across the network. Interoperability issues may appear between equipment used by the corporate customer and the VoIP service provider. The SBC on the service provider s side corrects these compatibility issues by normalizing SIP messages. Last update: 2015/01/09 00:09:25 Page 39 of 188

42 VoIP routing issues can develop when Network Address Translation (NAT) is used by the corporate network. If the SIP messages use an IP address local to the corporate network, replies to the SIP message cannot be routed properly. This is corrected by the carrier SBC which changes the IP address of the SIP message to match the IP address of the packet in which it was delivered. Sangoma has a wide range of SBCs to suit both the corporate network and the higher capacity VoIP service provider s network. They are available as a hardware appliance or as software suitable for a purely virtual environment. Last update: 2015/01/09 00:09:25 Page 40 of 188

43 SBC Remote Office The cost of maintaining dedicated telephone connections between branch offices and headquarters can be significant. Each branch office needs a dedicated multiline voice connection to the main office, typically T1 or T3. A connection between each branch office may also be required. If all branches need to be interconnected, an ever increasing number of connections are required. For example, a single branch office (two locations) requires one connection, two branch offices require three connections, and nine branch offices (10 locations) require 45 connections. A centrally located IP-PBX cluster can manage all voic and another telephone functions for headquarters and for all branch offices. Connectivity between each branch office and the central IP-PBX is achieved through the internet. A limited number of local PSTN connections can be retained for business continuity in the event of a failed internet connection. The challenge to extending the VoIP system across the internet between branches and headquarters is ensuring security for the network and privacy for conversations. One way to achieve these security functions is by protecting intraoffice communications with a VPN. However, this requires one VPN account per trunk, which requires powerful VPN servers when large numbers of locations are involved. VPN connections add overhead to the internet connection which consumes bandwidth. Upgrades and additional configuration to routers, firewalls, and other network components may be required to obtain a fully functional and efficient Last update: 2015/01/09 00:09:25 Page 41 of 188

44 VoIP system. VPNs can be tedious to setup for a VoIP system, and may require special configuration for each user. An alternative to using VPNs to secure the VoIP system between offices is to deploy SBCs to interconnect VoIP LANs across the internet. SBCs are installed at the edge of each LAN and work transparently, with no need to configure individuals equipment. This requires less powerful servers and much less configuration and management compared to VPNs. The SBC protects the network from security threats, and can offer voice encryption, increasing the level of voice privacy. Firewalls and Network Address Translation (NAT) impede the flow of VoIP traffic between the corporate network and SIP trunks. An SBC is the best way to solve these network transversal challenges because it allows VoIP traffic to pass between the corporate LAN and the internet without exposing the corporate network through the opening of ports in the firewall. Although SIP is a standard, the many ways in which it can be implemented can lead to incompatibilities between SIP devices such as phone handsets from a variety of vendors, the IP-PBX, and the SIP trunk provider. The SBC normalizes SIP, transparently translating each variety of SIP into the appropriate format for each device. Using an SBC to manage intraoffice voice connections offers a robust solution with lower equipment costs, and with less disruption to the network and to users, than using a VPN to accomplish the same thing. For a typical small-to medium-sized business installation, the Sangoma esbc has ample capacity to handle the call load. For large call volumes, the Sangoma carrier-class NetBorder SBC may be suitable. In cases where SIP trunks are installed for outside telephone connections, each office location can connect directly to the PSTN using of VoIP gateway such as the Sangoma Vega series. Last update: 2015/01/09 00:09:25 Page 42 of 188

45 User Interface Sangoma SBC provides the user with three interfaces WebGUI Web GUI is preferred for almost all operations Configuration Operations Statistics Reports Console via ssh or usb-serial For power users familiar with Linux operating system ssh usb-serial console provides advanced and flexible interface for troubleshooting and automation. RESTful API Used for tight product integration with other platforms. Business automation Auto configuration Monitoring Management More Info WebUI Interface Console Interface Last update: 2015/01/09 00:09:25 Page 43 of 188

46 RESTful Interface Last update: 2015/01/09 00:09:25 Page 44 of 188

47 WebUI Interface Sangoma SBC WebGUI is composed of the following sections Overview Configuration System Reports Help The WebGUI has a tool tip for each configuration option. Just scroll the mouse over the tool tip where available, to get more information. Last update: 2015/01/09 00:09:25 Page 45 of 188

48 Overview The Overview section is used to obtain SBC status information as well as to star, stop, restart the SBC Services. Dashboard Section System Status Control Panel Description Provides global SBC status information such as CPU, Memory and Services status. It also provides detailed per service information and error events Used to start, stop,restart SBC services Last update: 2015/01/09 00:09:25 Page 46 of 188

49 Signaling This section displays detailed SBC Signaling resources related information. Section SIP Profile Status SIP Trunk Status SIP Session Status Description Detailed status and configuration of each SIP Profile created Detailed status and configuration of each SIP Trunk created Detailed overview of currently active SBC sessions Media This section displays detailed SBC Media resources related information. Section Description Media Interface Status Lists all hardware media interfaces supported by the SBC. For each interface it will also display number of sessions currently active, and session history Security The security section provides the Blocked IP information for each security services. Section Description SIP Firewall Status Last update: 2015/01/09 00:09:25 Page 47 of 188

50 Configuration Configuration section is used to configure the SBC features. Last update: 2015/01/09 00:09:25 Page 48 of 188

51 System System section is used to configure system/appliance related functions. Including notifications, audit points, backup and restore. Last update: 2015/01/09 00:09:25 Page 49 of 188

52 Reports Provides detailed logs and time based traffic information. Help Provides help and upgrade information Last update: 2015/01/09 00:09:25 Page 50 of 188

53 Console Interface Console Structure Console access via ssh Console access via usb-serial Shell Commands via WebUI Command Execution Gateway CLI Commands via WebUI Command Execution Operating system is Linux based. Therefore Linux expertise is mandatory. Working in shell is very powerful and flexible, but also dangerous A system can be corrupted, formatted, erased if user makes a mistake. Connect via SSH Use default SSH clients on any desktop Windows putty Linux native ssh On login prompt Username: root Password: < your custom password > Connect via USB Serial usb to serial cable One must use usb to serial cable + null modem cable If Laptop does not have a serial port then use two usb to serial cables plus null modem cable per diagram below. Connect to any usb port on SBC appliance All SBC appliances have usb port on rear panel 2U SBC appliances have usb port in front panel as well. Configure Terminal Client on Laptop Last update: 2015/01/09 00:09:25 Page 51 of 188

54 Windows HyperTerminal Linux mincomm Serial Settings , N, 8, 1 vt100 Press enter a few times until a login prompt appears. Login via: username: root, password: Bash Shell Once successfully logged into the system, either via ssh or usb serial, user will be offered a bash prompt. SBC system is based on Linux The initial console after login will be a bash shell System Commands System commands are based on Linux operating systems. Listed here are some most useful debugging commands. tcpdump Provides network capture to a pcap file Can be analyzed using wireshark on Desktop or Laptop. ethtool Provides detail network interface information, like Ethernet link status. Run: ethtool for all the options Eg: ethtool eth0 show Ethernet status Ifconfig Network interface statistics tool Shows error counters on Ethernet and TDM interfaces. Notice the error and overrun counters on wanpipe w1g1 interfaces. nsc_cli Provides SBC CLI Refer to the appendix for all System Commands Last update: 2015/01/09 00:09:25 Page 52 of 188

55 SBC CLI nsc_cli First log into the System Console (bash) Once on bash prompt run nsc_cli The SBC gateway must be running and started in Control Panel. Command Description status show channels log [debug, error, crit] Shows SBC Status List all active calls Set log level to debug loglevel critical Last update: 2015/01/09 00:09:25 Page 53 of 188

56 RESTful Interface Sangoma s SBC can be fully configured using a RESTful API. You can also use the API to auto-provision SIP trunks, users, etc; in an automated way from your own systems or scripts. RESTful Documentation The API documentation is auto-generated and it can be found here: RESTful Sample Code Examples of the API usage in PHP can be downloaded here. rest-api-samples.tar.gz Last update: 2015/01/09 00:09:25 Page 54 of 188

57 Product Information Sangoma SBC Appliance Fully integrated Industrial grade telco appliance running a customized OS, Sangoma SBC Application and Media interfaces configured and installed by Sangoma. Sangoma SBC Appliance provides a full-featured, carrier-class SBC deployment while leveraging the flexibility and cost effectiveness of standard computing platforms Hadware Specifications Carrier Hardware Specification Industrial grade telecom appliance Size: 1U and 2U 19 Rack mount Min Capacity: 250 Sessions/Calls (1U) Max Capacity: 4000 Sessions/Calls (1U/2U) Power: AC, DC, Redundant AC/DC Enterprise Hardware Specification Industrial grade telecom appliance Size: 1U and 2U 19 Rack mount Min Capacity: 25 Sessions/Calls (1U) Max Capacity: 250 Sessions/Calls (1U) Power: AC Only AC Power Supply (Redundant) 110V/220V 110V/220V DC Power Supply (Redundant) The Input Current for -48VDC, is 12.0A (RMS). With Inrush Current of 20.0A MAX. Depth: 20 Depth: 8 Weight: 36lb Weight: 20lb 2 Gigabit Network Interfaces 2 Gigabit Network Interfaces 1 or 2 High Density DSP Interfaces 1 DSP Interface Last update: 2015/01/09 00:09:25 Page 55 of 188

58 SBC Appliance Info 1U Carrier Front Pannel 1U Carrier Rear Pannel 2U Carrier Front Pannel 2U Carrier Rear Pannel 1U Enterprise Front Pannel 1U Enterprise Rear Pannel Last update: 2015/01/09 00:09:25 Page 56 of 188

59 1U Carrier Front Pannel NetBorder Carrier SBC Front Panel Reset/Power button is used for: Factory Reset Press 1 time per second until system beeps and reboots (approx.: 10sec). A beep will sound to indicate that system has completed factory reset before system reboots. Soft Reboot Press 1 time every 3 seconds until system reboots. (approx.: 6sec) There will be no beep on reboot. Power on/off Hold for 10 seconds Nothing will happen if pressed once To avoid accidental restart. Caution: From SBC SW release 5.0 Refer to Factory Reset section. USB Ports can be used for Serial Console Refer to Serial Console section. Last update: 2015/01/09 00:09:25 Page 57 of 188

60 RAID1 SSD The RAID1 is NOT Hot Plug SBC appliances use industrial grade SSD One must power down the machine in order to change SSD/HDD Contact Sangoma Support for part replacement. Last update: 2015/01/09 00:09:25 Page 58 of 188

61 1U Carrier Rear Pannel Last update: 2015/01/09 00:09:25 Page 59 of 188

62 2U Carrier Front Pannel Fan Filter USB Used for Serial CLI Refer to the Serial CLI Section Power LED HDD Activity LED Front Panel Reset/Power button is used for: Factory Reset Press 1 time per second until system beeps and reboots (approx.: 10sec). A beep will sound to indicate that system has completed factory reset before system reboots. Soft Reboot Press 1 time every 3 seconds until system reboots. (approx.: 6sec) There will be no beep on reboot. Power on/off Hold for 10 seconds Nothing will happen if pressed once To avoid accidental restart. Refer to Factory Reset section. RAID1 SSD The RAID1 is NOT Hot Plug Last update: 2015/01/09 00:09:25 Page 60 of 188

63 SBC appliances use industrial grade SSD One must power down the machine in order to change SSD/HDD Contact Sangoma Support for part replacement. Last update: 2015/01/09 00:09:25 Page 61 of 188

64 2U Carrier Rear Pannel Fan Internal Power supply Default AC, non-redundant Option: DC or AC Redundant Power Button Used to turn off the machine Not used for Factory Reset. Unused 2x Gig Ethernet Port Not used at this time. Should NOT be plugged into the LAN. Primary Eth Interface (eth0): Gig Ethernet Port This adapter must be plugged into the LAN SIP Signaling and RTP Media will flow through this device. WebUI identifies this device as eth0 Secondary Eth Interface (eth1): Gig Ethernet Port This adapter is optional It can be used for Monitoring and Statistics WebUI identifies this device as eth1 USB Ports Used for Serial Console Can be used re-flash the appliance Future use: active/standby redundancy* Last update: 2015/01/09 00:09:25 Page 62 of 188

65 T1/E1 Interfaces SBC does not support T1/E1 interfaces Redundant DC Version Last update: 2015/01/09 00:09:25 Page 63 of 188

66 1U Enterprise Front Pannel Last update: 2015/01/09 00:09:25 Page 64 of 188

67 1U Enterprise Rear Pannel Last update: 2015/01/09 00:09:25 Page 65 of 188

68 Shipping Contents The first three tasks for installing and operating the Sangoma SBC are Unpack Inspect Power up. Carefully inspect the Sangoma SBC Appliance for any damage that might have occurred in shipment. If damage is suspected, file a claim immediately with the carrier, keep the original packaging for damage verification and/or returning the unit, and contact Sangoma Customer Service. What is included in the box Sangoma SBC Appliance Appliance can be 1U or 2U depending on model ordered Power Cable AC cable in case of AC PSU (black cable) DC cable in case of DC PSU (RED & Black cable) Mounting Brackets Rack mount rails Quickstart user guide Factory Configuration Factory Configuration Last update: 2015/01/09 00:09:25 Page 66 of 188

69 Factory Configuration By default the SBC appliance gets shipped with following configuration. Static IP / Static IP Port eth0 (Primary Ethernet Interface Port) Refer to Product Information for port location on the rear pannel. WebUI URL Username: root Password: sangoma Last update: 2015/01/09 00:09:25 Page 67 of 188

70 First Boot & Initial Setup Initial Setup Unpack the SBC shipping box Connect the SBC appliance to a power source Connect the SBC appliance to LAN Connect to SBC appliance via Laptop Browser Provision the Appliance Change Password Change Hostname & IP Date Time Initial Provision Done Next step is to configure the SBC. Please refer to usage scenarios First Boot Subtopic Power Connection Initial WebGUI Connection Change Default Password Console SSH Configuration SBC License Last update: 2015/01/09 00:09:25 Page 68 of 188

71 Power Connection Power Connection Sangoma SBC comes with three types of power supplies AC PSU AC Single PSU (Default) AC Dual-Redundant PSU DC PSU DC Dual-Redundant PSU (Only) AC PSU Connection Standard 110V or 220V, 50-60Hz connection. Optional Dual-Redundant AC 110V or 220V, 50-60Hz connection. Optional Dual-Redundant DC -48V Last update: 2015/01/09 00:09:25 Page 69 of 188

72 2U DC Redundant PSU Connection Connecting cables to a power supply depends on the remote power source. Power Source Type Black Wire Red Wire If power source -48V -48V 0V (Ground) If power source +48V 0V (Ground) +48V The PSU has voltage reverse protection. If the red and black wires are connected the wrong way, the system will not power up. But there will be no damage to the PSU or the system. VOLTAGE DC -36V to -72V INPUT CURRENT INRUSH CURRENT DC OUTPUT 12.0A (RMS). FOR -48 VDC 20A (Max) 400W (Max) Last update: 2015/01/09 00:09:25 Page 70 of 188

73 Initial WebGUI Connection SBC factory settings are not very useful, as the Primary Ethernet port:eth0 is set to a static IP address. Proceed to connect to the SBC Appliance via Laptop s web browser. Connect the Primary Signaling Port: eth0 to a LAN Switch Connect Laptop to LAN Switch Configure Laptop to IP address: /24 Using Laptop web browser go to URL: or Login via Username: root, Password: sangoma Last update: 2015/01/09 00:09:25 Page 71 of 188

74 Ethernet network connections for 1U and 2U Carrier appliances are the same. SBC WebGUI Login Screen Default Credentials Username: root Password: sangoma Make sure to change the default password right away. Change Password Section Last update: 2015/01/09 00:09:25 Page 72 of 188

75 SBC WebGUI Initial Status On the very first login, the WebGUI will provide you an overview of Sangoma SBC configuration status. The top of the WebGUI screen contains Information dialogs that are used to provide important messages to the user. At a quick glance we can see that the SBC is Not started And that Configuration is not complete Below the Information Dialogs, the Configuration Checklist indicates what are the minimum configuration steps necessary to get the SBC running. Last update: 2015/01/09 00:09:25 Page 73 of 188

76 Change Default Password After successful Login, please proceed to change the default password. Sangoma SBC appliance comes with default user name and password: root/sangoma For security reasons please change the password after first login. Password can only be changed from Secure HTTP connection Log into Sangoma SBC using ip > Navigate to System -> Users Change password for *root user Last update: 2015/01/09 00:09:25 Page 74 of 188

77 Console SSH Configuration By default SBC systems come with SSH enabled. To configure ssh service Select Services from side/top System Menu Enable or disable Secure Shell service Last update: 2015/01/09 00:09:25 Page 75 of 188

78 SBC License Sangoma SBC Appliances By default Sangoma SBC appliances comes with a valid SBC license as per product SKU number. This section can be skipped unless upgrading capacity with a new License file. Sangoma SBC VM & VM Hybrid License VM and VM Hybrid SBC software is shipped with no License. Sangoma Sales will send you an appropriate SBC License file based on product SKU number. License will have to be updated as per instructions below. For more detailed information refer to: SBC Licensing and Installation Last update: 2015/01/09 00:09:25 Page 76 of 188

79 License Update License installation and update is done from the menu System -> License. Even if the license is already installed, you can upload a new license or verify your current license details there. If you want to install the license for the first time or update to a new license, click Choose File and upload the.tar.gz license file provided by Sangoma. Then click Upload. After uploading the license you will see the details of the uploaded license. In this example, the license has a limit of 500 sessions. Different vendors have a different concept of what a session is. In Sangoma SBC things are much simpler. One session is one call. Sangoma s NetBorder Session Controller do not require extra licensing for registered peers (SIP REGISTER message), SIP trunks or any other SIP entity. In case of upgrades, of expansions please contact Sangoma Sales. To update SBC license Select License from side/top Configuration Menu Obtain SBC License from Sangoma Support Upload the License into the SBC Gateway via the Upload Button Last update: 2015/01/09 00:09:25 Page 77 of 188

80 The License page offers the detailed license overview. License Variables Name Product License Max-Sessions HD-Serial Description Customer Name Customer Product Name NA Maximum number of SIP sessions System s Hard Drive serial. License code checks the HDD serial and confirmes if Serial is correct. Last update: 2015/01/09 00:09:25 Page 78 of 188

81 Software SBC Sangoma software SBC is distributed as self contained installable ISO. It can be installed on any hardware platform or a Virtual Machine. Virtualization Sangoma supports all virtualization platforms Vmware XenServer VirtualBox Hyper-V Requirements Minimum VM Requirements are 1 GIG memory 1 CPU Bridged Network Device Virtualization Licensing In order to simplify software licensing, Sangoma SBC s license binds to VM ethernet mac address. This allows the VM to be deployed in VM HA mode without the need for internet access or complicated licensing servers. Last update: 2015/01/09 00:09:25 Page 79 of 188

82 Software SBC Installation Instructions on how to get started with Sangoma VM SBC Download The Wiki download page contains the latest Sangoma SBC ISO. It is recommended that customers download the latest Sangoma SBC ISO. Only use the older versions if you are already in production and need to remain on the old version. Please download the latest Sangoma ISO on to your system. Sangoma SBC VM License Sangoma Sales will provide you with a: License Key You will use this key the generate SBC License File and upload it to the Sangoma SBC GUI. If you do not have the Sangoma SBC License Key please contact Sangoma Sales. SBC VM Installation Download Sangoma SBC ISO Install Sangoma ISO on VM of choice Follow the ISO installation instructions. Next Step is to Log into the Sangoma SBC GUI Default WebGUI Login < ip of VM box > User: root Pass: < specify password you used on install > Last update: 2015/01/09 00:09:25 Page 80 of 188

83 License File Generation Once you have logged into the Sangoma SBC GUI. One of the first steps is to install the correct license. In order to generate the Sangoma SBC license file, you need the License Key. Refer to License Key section above. Step by Step Instructions Navigate to Sangoma SBC License Generation Page Specify above license key Specify the MAC address of the Sangoma SBC VM eth0 device. To determine your VM eth0 mac address: Navigate to Sangoma SBC GUI Login Click on Help -> About The About page contain System Information table. This table will contain the MAC address of your eth0 device. Once you have filled out the MAC address and the Key Click generate license Download License to your computer. Apply Sangoma SBC License Navigate to Sangoma SBC GUI Login Click on System -> License Click on Upload Select downloaded license file At this point your will be ready to use the SBC. Last update: 2015/01/09 00:09:25 Page 81 of 188

84 SBC Quick Config Overview Before diving into detailed step by step configuration, this page will outline all mandatory configuration steps in order to properly configure your Sangoma SBC. General Change default password Confirm SBC has correct license installed Network Planning Draw out a network diagram Identify IP networking scenario for SBC Is SBC straddling two networks Is SBC behind a router Identify SIP signaling ip addresses Is SBC going to have private or public IP address Identify RTP media ip address Last update: 2015/01/09 00:09:25 Page 82 of 188

85 How many media ip addresses can you have? Is RTP media ip address going to be same or different than SIP signaling ip address Identify SBC scenario type Carrier or Network Core Providing SIP Trunks to customers Hosted PBX provider Enterprise IP PBX that requires remote user support IP PBX that requires SIP Trunking support IP PBX that requries both remote user and SIP trunking. SIP Signaling Configuration How many SIP profiles do you need? RTP Media Configuration What codecs are going to be used? Which Media profiles will be attached to SIP Profiles Security Considerations Any special security considerations? Is authentication enabled on the PBX behind the SBC? Network Configuration Regardless of the type of SBC deployment you choose, you first must configure the signaling interfaces and media interface network information. SBC Signaling Interface Configuration SBC Media Interfaces SBC Configuration Options SBC Configuration depends on the above Network Planning Scenario. SIP Trunking Access (Remote User or Upper Registration) Combined All Sangoma SBC s support both SIP Trunking and Access simultaneously. Last update: 2015/01/09 00:09:25 Page 83 of 188

86 SBC General Configuration Configure SIP Domain In order to handle SIP registrations from the remote users, the SBC requires domain (SIP realm) configuration. In a typical scenario with registrations involved you will have at least one domain. A SIP Domain is bound to a SIP profile. SIP Domain can be bound to one or many SIP Profiles Configure SIP Profile SBC has minimum of two SIP Profiles. External and Internal. SIP profile listens on a specific port (eg: 5060) and accepts incoming SIP traffic. Depending on the SBC scenario: External SIP Profile interfaces to the ITSP or SIP trunk provider Internal SIP Profile interfaces to the local PBX or IP end points Sangoma SBC does not have a limit on how many SIP Profiles can be created Configure Media Profile Media profiles are used to define RTP parameters and are bound to one or more SIP Profiles Depending on use case: User can create one Media profile per SIP profile User can create one Media profile for many SIP Profiles. SIP profile uses the Media profile information to negotiate SDP information Codecs & P-times Local RTP ports Sangoma SBC runs Media RTP in custom Sangoma HW DSP. This allows Sangoma SBC to scale to thousands of RTP sessions without quality or capacity degradation. Configure Call Routing Profile A call routing profile is used to route SIP signaling from one SIP Profile to another. A call routing profile is bound to a SIP profile. Call routing profile can be bound to one or many SIP Profiles Last update: 2015/01/09 00:09:25 Page 84 of 188

87 Once SIP call receives a SIP INVITE it evokes the call routing profile to determine how to route a call. Sangoma SBC support GUI call routing configuration as well as Advanced XML call routing configuration. Configure Header Manipulation Profile Used to resolve SIP protocol variances between different vendors Or to hide SIP topology by removing VIA headers SBC Security Configuration Set SIP Signaling threshold limits to prevent DDOS attacks Invite and Registration storms Set Intrusion Detection and Prevention To prevent known attach patterns Set IP Firewall To allow certain IP address range, depending on network scenarios Apply Configuration The changes made in the Configuration section of the WebUI are only stored one the scratch disk. User MUST proceed to Apply page in the Management Section to save new configuration There are two ways to apply configuration. Most of the pages across the system will notify you as soon as you make changes that require to be applied. \ You can click there on Apply Configuration. Alternatively one can navigate to Configuration -> Management -> Apply Last update: 2015/01/09 00:09:25 Page 85 of 188

88 Network Configuration Network settings are configured from the menu Configuration -> IP Settings This menu has 2 type of interfaces: Signaling Interfaces Media Interfaces Signaling Interface Signaling interfaces are used to carry SIP Signalling traffic. Primary Signaling Interface (eth0) Secondary Signaling Interface (eth1) You must understand the IP data network scenario you are trying to setup. Scenario SBC straddle two networks SBC behind a firewall Network Config eth0 should have external IP address eth1 should have a local IP address eth0 should have local IP addreess eth1 will not be used Last update: 2015/01/09 00:09:25 Page 86 of 188

89 Media Interfaces Media Interfaces are used to carry RTP traffic. The Media/RTP IP addresses can be the same as SIP IP address. Media interfaces are special DSP s (Digital Signal Processor) which are accessible through any Ethernet network any of the signaling interfaces is attached to. These media interfaces are sometimes embedded within a Sangoma PCI card (ie D500, D100 devices) and sometimes are completely stand-alone processors that are just attached to the same network (D150). Sangoma SBC support two Media modes: Hidden and Exposed The recommended mode to use is Hidden Hidden mode provides a single Media/RTP address to remove network. Exposed mode Exposes DSP Media IP address to remote network. Exposed mode is more efficient but uses more IP addresses. Network Configuration Subtopics Singaling Interfaces Media Interfaces IP Troubleshooting Last update: 2015/01/09 00:09:25 Page 87 of 188

90 Singaling Interfaces Signaling Interface Overview A signaling interface deals with any type of SIP signaling which goes in and out of the SBC. The signaling interfaces on the SBC are the physical ethernet adapters. There is a special adapter called the sngdsp0 interface. The sngdsp0 interface allows the SBC to access its media interfaces. Must not be given an IP which is routable within the network. Signaling Interface Configuration You must start by configuring all the signaling interfaces you are planning use. You can click Edit for each network interface you want to configure. Last update: 2015/01/09 00:09:25 Page 88 of 188

91 Note: From the network configuration interface you can also set the hostname, default gateway and the DNS servers. If you use DHCP for any of the interfaces you won t be able to specify a default gateway or DNS servers. You can also add VLAN interfaces or interface aliases (Virtual IP) by clicking in the proper Add button at the bottom of the network configuration page. In the above example, interfaces named sngdsp0 and sngdsp1 are Sangoma Ethernet interfaces that give access to Sangoma s media interfaces (DSPs). Unless you are configuring a server for software transcoding mode or you have D150 media interfaces, then you need to configure those network interfaces and you must assign an IP to them. Last update: 2015/01/09 00:09:25 Page 89 of 188

92 Media Interfaces Media Interface Overview A media interface deals with all forms of media which goes in and out of the SBC. The media interfaces deal with all transcoding functions Example conversion from G.729 to G.722. The media interfaces deal with all other functions related to media (RTP/SRTP). Media interfaces are the actual DSPs that perform RTP streaming, trans-coding etc. These media interfaces are also network devices and therefore require IP configuration (IP addr, Netmask, Gateway etc). For the case of any appliance using a D100 (media interface without an external Ethernet port) the IP address assigned can be any IP because the interface will remain hidden within the appliance and the RTP packets end up using the IP of the signaling network interfaces. Media Interface Configuration The first step to configure media interfaces is select the media mode in which NSC will operate. There are three media interface IP modes: Hidden The DSP Media interface IP addresses will be hidden from the network Default and Recommended Uses a single IP address for all Media/RTP Exposed The DSP Media interface IP addresses will be exposed to the network Uses multiple IP addresses for Media/RTP but more CPU efficient Disabled Software mode. No DSP interfaces Used in VM environments Last update: 2015/01/09 00:09:25 Page 90 of 188

93 By default the hidden mode will be chosen when you go to Configuration -> IP Settings -> Media Interfaces. You must click Modify to change it and/or to perform the initial media interface discovery. Hidden Mode The Hidden mode is simpler to operate. In this mode all the media interfaces are hidden within the system and all the IP traffic generated by the media interfaces is routed/forwarded through the NSC host operating system and NATed. This mode is simpler because you don t have to worry about multiple IP addresses for your media interfaces. The media interfaces will still need an IP, but there is no possible conflict with your network as those interfaces will be hidden within NSC. You just have to choose a network that does not conflict with your real networks (ie, /24). The disadvantage of this mode is that all RTP is relayed thru the NSC host and therefore has an impact in the CPU load. Hidden mode works fine for call loads of up to 1,500 calls (3,000 call legs/sessions). If you require higher density you need to use Exposed. Note that appliances using D100 cards have no other option but to use Hidden mode because the D100 card has no external Ethernet port. In practice this is not a problem because D100 users do not reach the high call loads at which Hidden mode is limited. Last update: 2015/01/09 00:09:25 Page 91 of 188

94 Exposed Mode The Exposed mode requires more careful configuration as the media interfaces will be exposed to your network (whatever network you plug the Ethernet cable to), so you must choose the IP network information carefully to avoid conflicts with other network equipment. The clear advantage of this mode is that RTP does not go through the host operating system, instead the media interfaces send the RTP directly to the external Ethernet port to its destination. No interrupt or system load at all in the host operating system for any RTP stream. The first time you modify the media interfaces configuration you must go through a discovery procedure to find all media interfaces. Unless you are using a D150 device (stand-alone media interface) you should only select the network devices named sngdsp[n] for discovery (see Detect Media Interfaces field). If you are using a D150 (or several) you must select the ethernet interface the D150 device is attached to (they should share the same broadcast domain). Last update: 2015/01/09 00:09:25 Page 92 of 188

95 If you select the Exposed IP mode, the web ui will allow you to configure the IP settings for the media interfaces it finds. In Hidden mode you are only asked to provide a starting UDP port range for the RTP streams. You can leave the default if you don t require a particular port range. Once you click Save, the web ui will perform the device discovery procedure which will take a few seconds. The discovery procedure will send Ethernet broadcast messages to auto-discover Sangoma media interfaces attached to the same network(s) of the selected Ethernet interfaces. Once done, you will receive a report of the hardware found. In the example above, there is 2 network interfaces (sngdsp0 and sngdsp1) which correspond to one D500 card each. The first network interface (sngdsp0) has 4 media interfaces (also referred to as media modules ). The network interface sngdsp1 has attached 5 media interfaces. Each media interface was assigned a network configuration based on the discovery page input. You can manually edit each media module network configuration by clicking Edit. Last update: 2015/01/09 00:09:25 Page 93 of 188

96 Disabled Mode Software SBC installations will not have any hardware DSP resources. In this scenario one must set the Media Interface mode to Disable. In this mode RTP Media will be handled in software. Limitations of Software SBCs are Limited Transcoding capability Sangoma SBC currently only support free software voice codecs, such as ilbc, GSM, G726 G729, AMR and other royalty codecs are not supported in software. Limited Transcoding capacity The transcoding capacity depends on VM or Host resources. It is possible to transcode hundreds of calls using a VM with significant resources Limited Session capacity Session capacity depends on VM or Host resources Last update: 2015/01/09 00:09:25 Page 94 of 188

97 IP Troubleshooting In most installs, the network cards and IP settings will work straight out of the box. However, getting the network up the first time can be an exercise in frustration in some circumstances. Issues include; Network card compatibility Invalid networks settings (username, password, default gateway) Cable/DSL modems that cache network card hardware information Last update: 2015/01/09 00:09:25 Page 95 of 188

98 SBC General Configuration Sangoma SBC SIP and Media Configuration consists of following modules SIP Domain Configuration SIP Profile Configuration Media Profile Configuration SIP Trunk (Gateway) Configuration Call Routing Configuration SIP Header Manipulation Last update: 2015/01/09 00:09:25 Page 96 of 188

99 SIP Domain Configuration SIP Domain Overview Domains are also known as Realms within SIP networks. A domain, or a SIP realm, is a component within SIP which is used to authenticate users within the SIP registration process. Domain profiles are used to define the way users will authenticate with the SBC. Local authentication is used when users will register with the SBC. Upper registration is used when users will register to a softswitch or a IP-PBX through a SBC. This enables topology hiding so that no one outside of the corporate network knows about the equipment sitting behind the SBC. Domains are not strictly needed. If you are not using SIP registrations or are using IP authentication, you will not require a domain profile. SIP Domain Configuration Add a SIP domain by going to Configuration -> Signaling -> Domains All you need to provide to add a domain is the domain name, which should be a FQDN string (ie mycompany.com). Last update: 2015/01/09 00:09:25 Page 97 of 188

100 The system will then prompt you to select whether you want to enable Forward Registration / Authentication. If you want NSC to handle authentication of SIP requests (ie REGISTER, INVITE) using the local user database, you must choose Disable. If you plan to forward authentication to a third-party server (ie a registrar server or PBX) you must select Enable and provide the information of the third-party server that will handle authentication of those SIP requests. If you wish to create SIP accounts (users) you can click the Add button in the domain edit page. You can create as many domains as you want. Later you can Bind a domain to one or more SIP profiles. See the SIP profile configuration for details. Last update: 2015/01/09 00:09:25 Page 98 of 188

101 Note that the directory of users for that domain will only be valid when using a SIP profile that is bound to that domain. Last update: 2015/01/09 00:09:25 Page 99 of 188

102 SIP Profile Configuration SIP Profile Overview A SIP Profile is an account built on the SBC which contains a set of SIP attributes that are associated to the SBC itself. The SIP profile is used as a configuration for how the external endpoints may connect to the SBC. You bind an IP address, port, and other SIP related features to a SIP profile. You also bind call routes, domain profiles, media profiles, and SIP trunks to SIP profiles. A SIP profile contains SIP UA configuration. Sangoma SBC can be configured to behave as multiple UA each with a different configuration (and therefore a different set of IP:port pair each). SIP Profile describes information that is local to the SBC Information needed for remote user agents to connect to Sangoma SBC. Local listening port Local authentication user information Local transport info: TCP,UDP etc.. SIP Profile Configuration You can create SIP profiles by going to Configuration -> Signaling -> SIP Profiles. For the SIP profile name, use a descriptive name (no spaces) such as internal, internal-network, external-users etc. Last update: 2015/01/09 00:09:25 Page 100 of 188

103 Remember a SIP profile is a SIP UA that will be used to communicate with other SIP UA (ie SIP phones) or Servers (ITSP, SIP Proxies etc) Once you click Create, you will get a configuration page for the new SIP profile that allows you to specify: all the details about your new SIP profile including the IP information to be used, TLS/SRTP settings, etc. Pay special attention to the following fields: SIP Profile Field IP Address Transport Port Authenticate Calls Routing Plan: Description This is the IP address where NSC will listen for calls Most implementations will want to leave the default UDP+TCP, this means SIP packets will be accepted in both UDP and TCP protocols. Most of the time you will want to leave the default 5060 port. This means any SIP calls (INVITE requests) will be accepted and not challenged. You have to choose the routing plan you created before () Security Note: If you Disable Authenticate Calls in the SBC, take care that the remote SIP UA, eg: IP IPBX has authetication enabled. Security Note: if you are exposing a SIP Profile to the public internet, you may want to change its Port to something different than default 5060, in order to reduce attach exposure. Many malicious tools scan for for 5060 to find SIP systems connected to the internet. Even though Sangoma SBC comes with several protection mechanisms to detect scans, you will be better off on the internet by using a different port. Last update: 2015/01/09 00:09:25 Page 101 of 188

104 The contextual help on each field will give you information about what each field in the SIP profile does. When done configuring the SIP profile click Save. You can now proceed to optionally bind one or more domains to this SIP profile. When you bind a domain to a SIP profile you are attaching all the user directory of each domain bound for this SIP profile to be able to accept registrations and/or perform authentication of SIP INVITE messages based on the user/password information stored in the domain user directory (or performed via authentication forwarded according to the domain configuration). Note that in order to perform SIP authentication you have to set the Authenticate Calls parameter to Enable. To bind a domain to a SIP profile simply click Bind in the SIP profile modification page: Last update: 2015/01/09 00:09:25 Page 102 of 188

105 Then choose the domains you which to bind. Finally click Bind. You will see now the domain listed in the SIP profile page. Last update: 2015/01/09 00:09:25 Page 103 of 188

106 Media Profile Configuration A media profile is a list of attributes which define what audio codecs are used on a per call basis. It also describes how DTMF (Dual Tone Multiple Frequency) will be handled within the SIP profile Media profiles are bound to one or more SIP Profiles Depending on use case: User can create one Media profile per SIP profile User can create one Media profile for many SIP Profiles. SIP profile uses the Media profile information to negotiate SDP information Codecs & P-times Local RTP ports Audio Codec An audio codec is a program implemented as an algorithm that compresses and decompresses digital audio data. 5 codecs can be configured per media profile. 10 different codecs to choose from with multiple variations of each codec. Last update: 2015/01/09 00:09:25 Page 104 of 188

107 Codecs available: G.711 PCMU G.711 PCMA G.729 AMR ilbc GSM G.722 G G.723 G.726 Last update: 2015/01/09 00:09:25 Page 105 of 188

108 SIP Trunk (Gateway) Configuration SIP Trunks are used to connect Sangoma SBC to a remote SIP Providers/User Agents. Trunks can be used to communicate with SIP carriers or with IP-PBXs. It is the description of how the SBC will communicate with that endpoint. Example: IP address, port, etc. SIP Trunks usually contain Remote Domain Information Remote authentication credentials Remote Registration information SIP Trunks are bound to SIP Profiles. A single SIP Profile can be connected to multiple SIP Trunks For per option information please use the tool tips provided in the GUI. Last update: 2015/01/09 00:09:25 Page 106 of 188

109 Last update: 2015/01/09 00:09:25 Page 107 of 188

110 Call Routing Configuration This section will provide introduction to Sangoma SBC Call Routing Call Routing Configuration Options Sangoma SBC provide three interfaces call routing interfaces WebGUI Call Routing Default configuration method Advanced XML file call routing One or more XML configuration files can be used to store call routing information Designed for advanced users. Remote Database Call routing For each call SBC requests routing information from centralized database. What is call routing Call routing is the process used to route telephone calls across a telephony network. The process is the same whether calls are made between two phones the same locality, or across two different continents. Three concepts to call routing Condition The outcome this routing rule is addressing. The condition statement is used to determine how the call will be dealt if the rule turns out to be true or false. Example: Action to be performed if true What action will be performed if the condition is found to be true. Example: bridge to a different SIP trunk. Action to be performed if false What action will be performed if the condition is found to be false. Example: send the originator a 503 service unavailable message. Last update: 2015/01/09 00:09:25 Page 108 of 188

111 Call flow through Sangoma SBC Call routing profile is bound to a Sangoma SBC Profile An incoming call is processed by a Sangoma SBC Profile SBC Profile evokes a Call routing profile Call routing profile determines an action to take based on incoming call Bridge to another SIP Profile, SIP Trunk Hangup Transfer Routing rules are created in order to direct calls received from one interface, and bridge it out to the next interface. SIP profiles or SIP trunks are used to bridge calls. Routing rules can be as simple as bridging between trunks, or as complicated as choosing from a different carrier due to costs of routing. Last update: 2015/01/09 00:09:25 Page 109 of 188

112 Call Routing Subtopics WebGUI: Basic Call Routing Advanced XML Call Routing Advanced XML Syntax Last update: 2015/01/09 00:09:25 Page 110 of 188

113 WebGUI: Basic Call Routing WebGUI call routing (also referred to as Basic call routing), uses the graphic user interface of the SBC to allow users to create routing rules. It is modeled so that anyone would be able to create almost any type of scenario without the need to learn XML. Each basic dialplan can have multiple rules associated with it. Each rule deals with a specific condition which needs to be met. You can program the rule to continue to the next rule if it passes or fails. WebGUI Call Routing Section Navigate to Configuration -> Call Routing Basic Call Routing Default This section deals with default parameters for that particular dialplan. Rules This section deals with the specific rules which will be processed within the dialplan. Each rule is described based on the selections chosen within the rule configuration. Last update: 2015/01/09 00:09:25 Page 111 of 188

114 Call Routing Default Parameters The default parameters identify the description of the dialplan, and what the default SIP response code will be in an event of a failure. Description Description of what the dialplan will accomplish. Trace Call Whether the dialplan/call routing profile will include a trace within the SBC logging. Default Response Default SIP response code which will be sent in the event that the dialplan cannot process the call which is handed to it. Last update: 2015/01/09 00:09:25 Page 112 of 188

115 Call Routing Rule Creation Navigate to Configuration -> Call Routing section and select Add Rule Condition section Can set up to 5 condition which the rule will validate against. The rank is the priority of that rule within the dialplan. The stop policy determines whether the dialplan should stop processing if the rule matches, or whether it should continue to the next rule. Actions to perform if condition matches section Can set up up to 5 actions to perform if the conditions set are matched. Can be different actions Example: bridge to another trunk and log the transfer within the SBC logs. Actions to perfom if condition doesn t match section Can set up to 5 actions to perform if the condition does not match. Can be different actions Last update: 2015/01/09 00:09:25 Page 113 of 188

116 Example: hangup the call with a specific SIP response code and log the call within the SBC logs. Last update: 2015/01/09 00:09:25 Page 114 of 188

117 Advanced XML Call Routing For advanced users, there is a way to build dialplans using the advanced call routing engine. Advanced call routing is based on XML. There is no need to build multiple rules. All rules are added into a single XML file. Rules are separated by the different conditions. There are different editors built into the advanced dialplan that a user may choose from: Standard text editor Vim editor Emacs editor Last update: 2015/01/09 00:09:25 Page 115 of 188

118 Advanced XML Syntax There are several elements used to build an XML dialplan. In general, the dialplan groups logically similar functions and calling activities into a context. Within a context are extensions, each with condition rules and associated actions to perform when the condition rules match. The following is a sample dialplan to illustrate these concepts. We have left out the XML wrapper to help make the basic concepts more clear: <context name="example"> <extension name="500"> <condition field="destination_number" expression="^500$"> <action application="bridge" data="user/500"/> </ condition> </ extension> <extension name="501"> <condition field="destination_number" expression="^501$"> <action application="bridge" data="user/501"/> <action application="answer"/> <action application="sleep" data="1000"/> <action application="bridge" data="loopback/app=voic default ${domain_name} ${dialed_extension}"/> </ condition> </ extension> </ context > Each rule is processed in order until you reach the action tag which tells SBC what action to perform. You are not limited to only one condition or action tag for a given extension. In our above example, a call to extension 501 rings the extensions. If the user does not answer, the second action answers the call, and following actions delay for 1000 milliseconds (which is 1 second) and connect the call to the voic system. Last update: 2015/01/09 00:09:25 Page 116 of 188

119 Context Contexts are a logical grouping of extensions. You may have multiple extensions contained within a single context. The context tag has a required parameter of name. There is one reserved name, any, which matches any context. The name is used by incoming call handlers (like the [Sofia] SIP driver) to select the dialplan that runs when it needs to route a call. There is often more than one context in a dialplan. A fully qualified context definition is shown below. Typically you ll not need all the trimmings, but they are shown here for completeness. <?xml version="1.0"?> <document type="freeswitch/xml"> <section name="dialplan" description="regex/xml Dialplan"> <!-- the default context is a safe start --> <context name="default"> <!-- one or more extension tags --> </context> <!-- more optional contexts --> </section> </document> Last update: 2015/01/09 00:09:25 Page 117 of 188

120 Extensions Extensions are destinations for a call. This is the meat of SBC routing dialed numbers. They are given a name and contain a group of conditions, that if met, will execute certain actions. A name parameter is required: It must be a unique name assigned to an extension for identification and later use. For example: <extension name="your extension name here"> <condition(s)... <action(s).../> </condition> </extension> Typically when an extension is matched in your dialplan, the corresponding actions are performed and dialplan processing stops. An optional continue parameter allows your dialplan to continue running. <extension name="500" continue="true"> Last update: 2015/01/09 00:09:25 Page 118 of 188

121 Conditions Dialplan conditions are typically used to match a destination number to an extension. They have, however, much more power than may appear on the surface. SBC has a set of built-in variables used for testing. In this example, the built-in variable destination_number is compared against the regular expression ^500$. This comparison is true if is set to 500. <extension name="500"> <condition field="destination_number" expression="^500$"> <action application="bridge" data="user/500"/> </condition> </extension> Each condition is parsed with the Perl Compatible Regular Expression library. (go here for PCRE syntax information). If a regular expression contains any terms wrapped in parentheses, and the expression matches, the variables $1,$2..$N will be set to the matching contents within the parenthesis, and may be used in subsequent action tags within this extension s block. For example, this simple expression matches a four digit extension number, and captures the last two digits into $1. <condition field="destination_number" expression="^\d\d(\d\d)$"> <action application="bridge" data="sofia/internal/[email protected]"/> </condition> A destination number of 3425 would set $1 to 25 and then bridge the call to the phone at [email protected] Last update: 2015/01/09 00:09:25 Page 119 of 188

122 Multiple Conditions (Logical AND) You can emulate the logical AND operation available in many programming languages using multiple conditions. When you place more than one condition in an extension, all conditions must match before the actions will be executed. For example, this block will only execute the actions if the destination number is 500 AND it is Sunday. <condition field="destination_number" expression="^500$"/> <condition wday="1"> action(s)... </condition> </condition> Keep in mind that you must observe correct XML syntax when using this structure. Be sure to close all conditions except the last one with />. The last condition contains the final actions to be run, and is closed on the line after the last action. By default, if any condition is false, SBC will move on to the anti-actions or the next extension without even evaluating any more conditions. Last update: 2015/01/09 00:09:25 Page 120 of 188

123 Multiple Conditions (Logical OR, XOR) It is possible to emulate the logical OR operation available in many programming languages, using multiple conditions. In this situation, if one of the conditions matches, the actions are executed. For example, this block executes its actions if the destination number is 501 OR the destination number is 502. <condition field="destination_number" expression="^ $"> action(s)... </condition> This method works well if your OR condition is for the same field. However, if you need to use two or more different fields then use the new regex syntax <extension name="regex OR example 1" continue="true"> <condition regex="any"> <!-- If either of these is true then the subsequent actions are added to execute list --> <regex field="caller_id_name" expression="some User"/> <regex field="caller_id_number" expression="^1001$"/> <action application="log" data="info At least one of the conditions matched!"/> <!-- If *none* of the regexes is true then the anti-actions are added to the execute list --> <anti-action application="log" data="warning None of the conditions matched!"/> </condition> </extension> Using this method it becomes easier to match the caller s name OR caller ID number and execute actions whether either is true. Last update: 2015/01/09 00:09:25 Page 121 of 188

124 A slightly more advanced use of this method is demonstrated here: <extension name="regex OR example 2" continue="true"> <condition regex="any" break="never"> <regex field="caller_id_name" expression="^michael\s*s?\s*collins"/> <regex field="caller_id_number" expression="^ $"/> <action application="set" data="calling_user=mercutioviz" inline="true"/> <anti-action application="set" data="calling_user=loser" inline="true"/> </condition> <condition> <action application="answer"/> <action application="sleep" data="500"/> <action application="playback" data="ivr/ivr-welcome_to_freeswitch.wav"/> <action application="sleep" data="500"/> </condition> <condition field="${calling_user}" expression="^loser$"> <action application="playback" data="ivr/ivr-dude_you_suck.wav"/> <anti-action application="playback" data="ivr/ivr-dude_you_rock.wav"/> </condition> </extension> <extension name="regex XOR example 3" continue="true"> <condition regex="xor"> <!-- If only one of these is true then the subsequent actions are added to execute list --> <regex field="caller_id_name" expression="some User"/> <regex field="caller_id_number" expression="^1001$"/> <action application="log" data="info Only one of the conditions matched!"/> <!-- If *none* of the regexes is true then the anti-actions are added to the execute list --> <anti-action application="log" data="warning None of the conditions matched!"/> </condition> </extension> Basically, for this new syntax you can have a condition to have a regex attr instead of field and expression etc. When there is a regex attr, that means you plan to have one or more tags that are similar to the condition tag itself that it has field and expression in it. The value of the regex attr is either all or any or xor indicating if all expressions must match or just any expression or only one must match(xor). If it s set to any it will stop testing the regex tags as soon as it finds one match, if it is set to all, it will stop as soon as it finds one failure. From there it will behave like a normal condition tag either executing the actions or anti-actions and breaking based on the break attr. Last update: 2015/01/09 00:09:25 Page 122 of 188

125 The basic difference here is once there is a regex attr, the tags parsed for all or any take the place of the single field and condition Also, if any captures are done in the expression attrs of a tag, only the data from the newest capture encountered will be considered in the $n expansion or FIELD_DATA creation. In addition, you can set DP_REGEX_MATCH_1.. DP_REGEX_MATCH_N to preserve captures into arrays. <extension name="inbound_external"> <condition regex="any"> <regex field="${sip_from_host}" expression="domaina"/> <regex field="${sip_from_uri}" expression=" @domainb"/> <regex field="${sip_from_uri}" expression="user@domainc"/> <regex field="caller_id_name" expression="^(john Smith)$"/> <regex field="caller_id_number" expression="^( ) ( ) ( )$"/> <action application="set" data="domain_name=domainz"/> <action application="transfer" data="${destination_number} XML domainz"/> </condition> </extension> This is another example to show that all regex conditions must be true, then the action will get executed; otherwise, the anti-action will. This is the same logic as follows: IF (cond1 AND cond2 AND cond3) THEN do actions ELSE do other actions ENDIF Last update: 2015/01/09 00:09:25 Page 123 of 188

126 Basically, the <condition regex="all"> tells the parser, Hey, execute the <action> s only if all regexes PASS, otherwise execute any <anti-action> s. <condition regex="all"> <regex field="${sip_gateway}" expression="^${default_provider}$"/> <regex field="${emergency_call}" expression="^true$"/> <regex field="${db(select/emergency/autoanswer)}" expression="^1$"/> <!-- the following actions get executed if all regexes PASS --> <action application="set" data="call_timeout=60"/> <action application="set" data="effective_caller_id_name=${regex(${caller_id_name} ^Emerg(_.*)$ Auto%1)}"/> <action application="set" data="autoanswered=true"/> <action application="bridge" data="user/1000@${domain_name},sofia/gateway/ 1006_7217/${mobile_number}"/> <!-- the following anti-actions are executed if any of the regexes FAIL --> <anti-action application="set" data="effective_caller_id_name=${regex(${caller_id_name} ^Emerg(_.*)$ NotAuto%1)}"/> <anti-action application="set" data="call_timeout=30"/> <anti-action application="set" data="autoanswered=false"/> <anti-action application="bridge" data="user/1000@${domain_name},sofia/ gateway/1006_7217/${mobile_number}"/> </condition> Last update: 2015/01/09 00:09:25 Page 124 of 188

127 Complex Condition/Action Rules Here is a more complex example, performing time-based routing for a support organization. The user dials extension The actual support extension is 1105 and is staffed every day from 8am to 10pm, except Friday, when it is staffed between 8am and 1pm. At all other times, calls to 1100 are sent to the support after-hours mailbox. <extension name="time-of-day-tod"> <!--if this is false, FreeSWITCH skips to the next *extension*.--> <condition field="destination_number" expression="^1100$" break="on-false"/> <!--Don't bother evaluating the next condition set if this is true.--> <condition wday="6" hour="8-12" break="on-true"> <!--Fri, 8am-12:59pm--> <action application="transfer" data="1105 XML default"/> </condition> <condition wday="1-5" hour="8-21" break="on-true"> <!--Sunday-Thursday, 8am-9:59pm--> <action application="transfer" data="1105 XML default"/> </condition> <condition> <!--this is a catch all, sending the call to voic at all other times. --> <action application="voic " data="default $domain 1105"/> </condition> </extension> In this example, we use the break=never parameter to cause the first condition to fall-through to the next condition no matter if the first condition is true or false. This is useful to set certain flags as part of extension processing. This example sets the variable begins_with_one if the destination number begins with 1. <extension name="break-demo"> <!-- because break=never is set, even when the destination does not begin with 1, we skip the action and keep going --> <condition field="destination_number" expression="^1(\d+)$" break="never"> <action application="set" data="begins_with_one=true"/> </condition> <condition field="destination_number" expression="^(\d+)$">...other actions that may query begins_with_one... </condition> </extension> Last update: 2015/01/09 00:09:25 Page 125 of 188

128 Variables Condition statements can match against channel variables, or against an array of built in variables. Built-In Variables The following variables, called caller profile fields, can be accessed from condition statements directly: Dialplan Variable context rdnis destination_number dialplan caller_id_name caller_id_number ani aniii uuid source chan_name network_addr Description Why can we use the context as a field? Give us examples of usages please. Redirected Number, the directory number to which the call was last presented. Called Number, the number this call is trying to reach (within a given context) Name of the dialplan module that are used, the name is provided by each dialplan module. Example: XML Name of the caller (provided by the User Agent that has called us). Directory Number of the party who called (caller) can be masked (hidden) Automatic Number Identification, the number of the calling party (caller) cannot be masked The type of device placing the call ANI2 Unique identifier of the current call? (looks like a GUID) Name of the FreeSWITCH module that received the call (e.g. PortAudio) Name of the current channel (Example: PortAudio/1234). IP address of the signaling source for a VoIP call. year Calendar year, yday Day of year, mon Month, 1-12 (Jan = 1, etc.) mday Day of month, 1-31 week Week of year, 1-53 mweek Week of month, 1-6 wday Day of week, 1-7 (Sun = 1, Mon = 2, etc.) or sun, mon, tue, etc. hour Hour, 0-23 minute Minute (of the hour), 0-59 Last update: 2015/01/09 00:09:25 Page 126 of 188

129 minute-of-day Minute of the day, (1-1440) (midnight = 1, 1am = 60, noon = 720, etc.) time-of-day Time range formatted: hh:mm[:ss]-hh:mm[:ss] (seconds optional) Example: 08:00-17:00 date-time Date/time range formatted: YYYY-MM-DD hh:mm[:ss]~yyyy-mm-dd hh:mm[:ss] (seconds optional, note tilde between dates) Example: :00:01~ :59:59 Last update: 2015/01/09 00:09:25 Page 127 of 188

130 SIP Header Manipulation Header manipulation is used when specific components within SIP messages need to be modified. The reason for header manipulation are: To resolve SIP protocol variances between different vendors To hide SIP topology by removing VIA headers Header Manipulation Actions You can modify non-essential headers in SIP messages using header and parameter profiles. The following information summarizes the supported actions: Pass the header unchanged (whitelist functionality). Conditionally pass the header unchanged. Remove the header (blacklist functionality). Conditionally remove the header. Replace the name of the header. The replacement name cannot be that of a vital header. Conditionally replace the header content (appearing after the : ). Add a new instance of a header to a message regardless of whether or not the header already exists. Add the first instance of the header to the message, if a header with this name does not already exist. Header manipulation is generally performed prior to routing of calls, however, can be modified after routing as well. Header Manipulation Operation Ingress When the SIP profile has header manipulation for ingress configured, SIP headers get modified, then the call is sent to the routing engine. Egress When the SIP profile has header manipulation for egress configured, SIP header get modified as the call leaves the SIP profile. Last update: 2015/01/09 00:09:25 Page 128 of 188

131 Header Manipulation Configuration Options Similarly to call routing, there are two ways of configuring header manipulation rules: WebGUI/Basic Header Manipulation Advanced XML Header Manipulation SIP Header Manipulation Subtopics WebGUI: Basic Header Manipulation Last update: 2015/01/09 00:09:25 Page 129 of 188

132 WebGUI: Basic Header Manipulation WebGUI header manipulation, (also referred to as Basic header manipulation) allows a user not familiar with XML to build rules required to manipulate SIP information on inbound or outbound calls. Navigate to Configuration -> Header Manipulation Basic Header Manipulation Default This section deals with default parameters for that particular dialplan. Rules This section deals with the specific rules which will be processed within the dialplan. Each rule is described based on the selections chosen within the rule configuration. Last update: 2015/01/09 00:09:25 Page 130 of 188

133 Rules Condition section Can set up to 5 condition which the rule will validate against. The rank is the priority of that rule within the manipulation. The stop policy determines whether the manipulation should stop processing if the rule matches, or whether it should continue to the next rule. Actions to perform if condition matches section Can set up up to 5 actions to perform if the conditions set are matched. Can be different actions Example: Modify the Request-URI header within the SIP invite. Actions to perfom if condition doesn t match section Can set up to 5 actions to perform if the condition does not match. Can be different actions Example: Log the failure within the SBC logs. Last update: 2015/01/09 00:09:25 Page 131 of 188

134 SBC Advanced Configuration SBC Upper Registration Last update: 2015/01/09 00:09:25 Page 132 of 188

135 SBC Upper Registration Overview Upper Registration (also named as Through Registration or Forward Registration ) is a feature Sangoma SBC provides to help remote users, outside of the Enterprise or Carrier networks, to access Enterprise PBX, Hosted PBX or Carrier Soft-switch in a secure and reliable way. Sangoma SBC stands on the edge of local network and transparently passes registration coming from public network to an Enterprise PBX or Carrier Soft-switch. As a result, users are able to use their existing SIP account to register from outside of local network via Sangoma SBC. There is no need to have separate access credentials for those users accessing services from public networks. Users registered with upper registration feature can then make and receive calls, just like using an internal phone extension. Configuration Steps The following outline the steps required to configure Sangoma SBC for Upper Registration. A more detailed use case configuration example can be found in the section Use Case Configuration Example. Create a SIP Profile for the PBX A dedicated SIP Profile must be created for the Enterprise PBX, this SIP Profile is reserved to be used by the designated PBX. Note that if there are more than one PBX, each PBX must have its own SIP Profile created in the SBC. Create a Domain Create a Domain using the same domain name in the PBX. The domain configuration consists the location of the Registrar. When SBC receives a Registration request that matches the domain name, it forwards to the PBX. Create Domain binding Bind the Domain to the SIP Profile that handles traffic from outside the Enterprise network. Create Call Routing Specific call routing for registered users. Last update: 2015/01/09 00:09:25 Page 133 of 188

136 Use Case Configuration Example In this section, we use a typical use case to show you how to configure upper registration feature on Sangoma SBC. Enterprise PBX/Carrier Soft Switch: IP address SBC Internal IP address SBC External IP address We need to add: Two Call Routing Profiles Inbound_Dialplan and Outbound_Dialplan Last update: 2015/01/09 00:09:25 Page 134 of 188

137 Two SIP Profiles Internal_Sip_Profile and External_Sip_Profile Two Domains Upper registration domain Call Routing Profile: Inbound_Dialplan <extension name="local_extension_inbound"> <condition field="destination_number" expression="^(10[01][0-9]).*$"> <action application="export" data="dialed_extension=$1"/> <action application="bridge" data="sip/ </condition> </extension> Call Route Profile: Outbound_Dialplan <extension name="local_extension_outbound"> <condition field="destination_number" <action application="export" data="dialed_extension=$1"/> <action application="bridge" </condition> </extension> SIP Profile Internal_Sip_Profile Navigate to Configuration -> Signalling -> SIP Profiles : add a new sip profile Internal_Sip_Profile ; Make the following changes from default configuration: SIP IP Address : choose the NIC you want to use for SIP listening: in this case it is ; Set Authenticate Calls to Disabled Set Always Use Full Identification to Enabled Set Routing Plan to Outbound_Dialplan Last update: 2015/01/09 00:09:25 Page 135 of 188

138 Security Warning: With Authenticate Calls set to Disable, make sure that your PBX/Soft Switch is set to authenticate incoming calls. SIP Profile External_Sip_Profile For sip profile External_Sip_Profile, it is similar to Internal_Sip_Profile. Navigate to Configuration -> Signalling -> SIP Profiles, add a new sip profile External_Sip_Profile ; Last update: 2015/01/09 00:09:25 Page 136 of 188

139 Make the following changes from default configuration: SIP IP Address : choose the NIC you want to use for SIP listening: in this case it is ; Set Authenticate Calls to Disabled Set Always Use Full Identification to Enabled Set Routing Plan to Inbound_Dialplan Upper Registration Domain Navigate to Configuration -> Signalling -> Domains, add a new domain ; Enable Forward Registration The following screen shot first states: For any registration to domain , Sangoma SBC will use sip profile Internal_Sip_Profile to forward it to IP , port 5060 with transport UDP. Last update: 2015/01/09 00:09:25 Page 137 of 188

140 Bind Domain to external sip profile Go to Configuration -> Signalling -> SIP Profiles, choose to modify sip profile External_Sip_Profile ; Click the Bind button, and then check the checkbox beside domain ; Click Bind button in the message box. Last update: 2015/01/09 00:09:25 Page 138 of 188

141 SBC Security Security Overview Sangoma SBC Security consists of five parts SBC Threat Protection SIP Firewall IP Firewall SBC Intrusion Detection SIP Rate Limiting Sangoma SBC performs security operations at each network layer Ethernet TCP/IP SIP/RTP Sangoma SBC uses kernel level firewall to block intruders. This allows the SBC to scale even when it s under full DOS attack SIP Security Per SIP message, per realm message rate limit Trunk rate limits Overall system limits Firewall State full firewall rules Intrusion Detection/Prevention Known threat patterns such as scanners and sip attack software Various attach patterns and scenarios Option to add additional patterns Notification Last update: 2015/01/09 00:09:25 Page 139 of 188

142 notifications of threat events Last update: 2015/01/09 00:09:25 Page 140 of 188

143 SBC Threat Protection UDP Threats UDP Short Header UDP Flood UDP spoofed boradcast eecho (Fraggle Attack) UDP attack on diag ports (Pepsi Attack) RTP Threats RTP rogue packets (after-call) RTP flooding during call RTP flooding attack RTP spoofing SIP Threats SDP malformed contents (Protos Test) SIP malformed packet SIP request message flood attack SIP response message flood attack SIP Invite spoof SIP Register spoof SIP Register flood attack SIP request spoof SIP response spoof SIP end-call attack IP Threat Unknown Protocol ARP Flood (Poink Attack) IP Stream Option IP Spoofing IP Source Route Option, Strict IP Source Route Option, Loose IP Short Header Last update: 2015/01/09 00:09:25 Page 141 of 188

144 IP Malformed Packet IP bad Option IP address Session Limit Fragments too many Fragments, Large Offset Fragments Storm Fragments Same Offset Fragments Reassembly w/different offsets (tear drop) Fragments Reassembly w/different offsets and padding (new tear attack) Fragments Reassembly w/different offsets and oversize (Bonk/Boink attack) Fragments Reassembly off by one IP header (Nestea attack) Fragments flood initial fragment only (Rose Attack) Fragments Deny ICMP Threat ICMP Source quench ICMP mask request ICMP large packet (>1472) ICMP oversized packet (>65536) ping of death/ssping attack) ICMP info request ICMP incompatible fragment (jolt attack) ICMP flood ICMP broadcast with spoofed source (Smurf/Pong attack) ICMP error packets flood (Trash attack) ICMP spoofed unreachable (Click attack) ICMP spoofed unreachable flood (smack/bloop/puke attack) TCP Threat TCP Packets without flag TCP packets, oversized TCP FIN bit with no ACK bit TCP packet with URG/OOB flag (nuke attack) TCP SYN fragments reassembly with overlap (syndrop attack) SYN fragment SYN attack w/ip spoofing (land attack) SYN attack (syn flood) SYN and FIN bits set Scan attack TCP port Last update: 2015/01/09 00:09:25 Page 142 of 188

145 SIP Firewall The SIP firewall can assist you in detecting failed SIP connections to the SBC. The general concept is the SIP firewall is made up of rules that will either LOG or BLOCK the offender exceeding the failed attempts. These rules can be targeted towards every IP and User Agent, or only certain User Agents or IPs. As well these rules can be associated with all SIP profiles or certain SIP profiles. SIP Firewall configuration works in conjunction with SIP Security Monitor Service Refer to SBC Operation SIP Firewall Configuration To start the configuration go to Configuration->Security->SIP Firewall then click Add to add rule in the SIP Security Monitor Rules section. Specify the name for the new rule, then click Add. Last update: 2015/01/09 00:09:25 Page 143 of 188

146 The rule below will look for any single source IP exceeding 20 failed attempts over 10 minutes. If a certain IP exceeds this then it will be blocked. The Action Parameter is set to 0 so this will block the host forever, if you would like the host to be blocked for 15 minutes set the Action Parameter to 15. If you want to keep all blocked users in your own 3rd party firewall you can let the SBC block the IPs then check the status of the blocked users as shown below. Or you can write to the log file and have a utility which checks the NSC logs for these entries and act on this. The log file is /var/log/sipsecmon.log on the unit or in the WebUI go to Reports->System->NSC Logs then click on SIP Security Monitor. Last update: 2015/01/09 00:09:25 Page 144 of 188

147 SIP Firewall Logging To configure the log level click edit under the SIP Security Monitor Configuration. On the next page the log level can be set to Information or Debug, once set click save to exit. To apply the changes click Configuration Modified then click Apply & Reload. Last update: 2015/01/09 00:09:25 Page 145 of 188

148 Last update: 2015/01/09 00:09:25 Page 146 of 188

149 SIP Firewall Status To get the status of blocked IPs on the SBC go to Overview->Security->SIP Firewall Status and the list of blocked IPs will be there. Last update: 2015/01/09 00:09:25 Page 147 of 188

150 IP Firewall The purpose of the IP Firewall is to block all services on the SBC except the ones in the list of allowed services. This helps secure the unit as only the defined services will be allowed. IP Firewall Configuration Navigate to WebGUI Configuration->Security->IP Firewall to start the configuration. To add UDP SIP on port 5060 select SIP from the Standard Services drop down menu, then click Add. Next you will see SIP listed in the allowed services list. Last update: 2015/01/09 00:09:25 Page 148 of 188

151 IP Firewall Service Control Panel Enable the firewall by going to Overview->Control Panel then click Start next to the IP Firewall. Last update: 2015/01/09 00:09:25 Page 149 of 188

152 SBC Intrusion Detection The intrusion detection system on the SBC is has been pre-configured with a set of known attacks. T hese attacks are grouped depending on what core service the attack is designed for. By default only the VoIP group is enabled. SBC Intrusion Detection Configuration Navigate via WebGUI to Configuration->Security->Intrusion Detection then you will see a list of all known attacks and their groups. Enable the attacks you would like then click Update. SBC Intrusion Detection Service Once configured go to Overview->Control Panel and start the Intrusion Detection service. Last update: 2015/01/09 00:09:25 Page 150 of 188

153 SIP Rate Limiting The purpose of rate limiting is to prevent an host from sending too many SIP requests. This can help prevent a DOS type attack where an IP sends many SIP requests in all at once. If the limit is reached the host will be blocked in the kernel for the length of the period. SIP Rate Limiting Configuration Navigate via WebGUI to Configuration->Signalling->SIP Profiles then select the SIP profile you wish to configure the rule on. Once in the profile click Add under the SIP Limits Rules section. Last update: 2015/01/09 00:09:25 Page 151 of 188

154 Select the SIP method you would like to limit and the host you would like to limit. The keyword ANY will apply the limit rule to all IPs. Next select how many of these methods can be received during the period you specify. In the example below 10 OPTIONS can be received in a 60 second period. If this limit is exceeded all traffic from the host will be blocked for the period of 60 seconds. Once the rule is added it will appear as shown below in the table. Last update: 2015/01/09 00:09:25 Page 152 of 188

155 SIP Rate Limiting Configuration Apply After SIP Rate Limiting rules configuration is done, the Configuration Modified notification will turn red, indicating that configuration must be applied. To apply the rule click on Configuration Modified to review configuration changes. The proceed to apply the rule click Apply & Restart or Apply & Reload. Refer to Apply Configuration Section Last update: 2015/01/09 00:09:25 Page 153 of 188

156 Applying Configuration The changes made in the Configuration section of the WebUI are only stored one the scratch disk. User MUST proceed to Apply page in the Management Section to save new configuration There are two ways to apply configuration. Most of the pages across the system will notify you as soon as you make changes that require to be applied. \ You can click there on Apply Configuration. Alternatively one can navigate to Configuration -> Management -> Apply It is not necessary to apply the configuration changes immediately every time you make them. You can go around the web interface making all the changes you need and then only apply them at the end when you re ready to test them or deploy them. Most of the configuration changes require a service restart, however, certain modules such as Call Routing Domain Users allow you to apply the configuration changes without restarting the NetBorder Session Controller service. Configuration / Apply Options The Apply section will inform the user what changes were made on the SBC. It will also inform the user how the SBC will be affected when the configuration is applied. Configuration task can be split into two categories Re-loadable Configuration Restart Configuration Last update: 2015/01/09 00:09:25 Page 154 of 188

157 Re-loadable Configuration Any changes in Reload Configuration section will not affect active calls on Apply You will see a button such as Apply Call Routing, which then applies the call routing changes without requiring a restart of the service and the changes will be taken by the running service instead immediately. Restart Configuration Any changes in Restart Configuration section WILL bring down all sessions on the SBC. Because SBC will have to be restarted for configuration to take effect. You will see a button requesting a Restart in order to fully apply configuration. Last update: 2015/01/09 00:09:25 Page 155 of 188

158 SBC Operation Sangoma SBC Services are split into three sections Application Service Main SBC Application Security Services Security services associated with Main SBC application Media Services Media services that work in conjunction with Main SBC application One can control each service via SBC Control Panel Sangoma SBC Service Descriptions Service Section Description NetBorder Session Controller IP Firewall Intrusion Detection Intrusion Prevention Secure Shell SIP Security Monitor Media Firewall Application Services Security Service Security Service Security Service Security Service Security Service Security Service Main SBC application service. Main SIP and Proxy application. IP Firewall configuration. Used to create ip firewall rules such as block ports IP Firewall is automatically used by other security services as part of overall SBC security Rules based intrusion detection. When the rules match known attack pattern, the event is passed to the Intrusion Prevention service Processes Intrusion Detection Events and applies Firewall rules on incoming ip addresses or ports such as block SSH console login Attaches to the Main SBC application and monitors SIP signalling events. Once an event is detected it takes action. Such as overload detection of SIP INVITES, Registration or Mangled packets and employs the firewall to take action such as block Attaches to the Main SBC application and monitors RTP media events. It opens and closes local RTP ports based on SDP information Last update: 2015/01/09 00:09:25 Page 156 of 188

159 RTCP Monitor Media Service Attaches to the Main SBC application and monitors RTCP media control events. It logs the RTCP statistics and triggers media quality events to the user SBC Operation Subtopics SBC Contol Panel SBC Dashboard Overview SBC Session Status SBC Troubleshooting Options SBC Backup SBC Restore SBC Upgrade SBC Monitoring SBC Notifications Last update: 2015/01/09 00:09:25 Page 157 of 188

160 SBC Contol Panel You can start all services from the control panel at Overview -> Dashboard -> Control Panel. Simply click on the Start button for the service NetBorder Session Controller. Because the NetBorder Session Controller service is the main application service, other services will automatically be started with it, depending on how the service is configured. Last update: 2015/01/09 00:09:25 Page 158 of 188

161 SBC Dashboard Overview Once services are started, you can use the Dashboard menus to monitor the status of all your services. The most important menu is the Control Panel, which you have already used to start/stop services. By default, the secure shell service (ssh) is the only one started at boot. However, any services that you turn on will be automatically started on next boot as well, if you stop any service, it will also be taken out of the boot sequence. To check the status of your SIP profiles, go to Overview -> Dashboard -> SIP Status You can then click on View to see more details of your profiles, including status of SIP trunks and SIP registrations. Last update: 2015/01/09 00:09:25 Page 159 of 188

162 Last update: 2015/01/09 00:09:25 Page 160 of 188

163 SBC Session Status To check active sessions (and active calls) and its details, go to Overview -> Dashboard -> Session Status Last update: 2015/01/09 00:09:25 Page 161 of 188

164 SBC Troubleshooting Options All services in NSC report logging at different levels. You can consult the application logs at Reports -> System -> NSC Logs. The most important service logs are the logs for the NetBorder Session Controller service, which have their own tab (See below). There you can find relevant information, including SIP messages received and sent from the system. When debugging problems it may be necessary to enable debugging logs for NSC. You can find the core logging level available at Configuration -> Core. For production systems the recommended level is Notice, but when performing troubleshooting you should set this to Debug. Last update: 2015/01/09 00:09:25 Page 162 of 188

165 Last update: 2015/01/09 00:09:25 Page 163 of 188

166 SBC Backup Navigate Configuration -> Management -> Backup-Restore then click Backup. The backup will now be completed and ready for download. Last update: 2015/01/09 00:09:25 Page 164 of 188

167 It is best to download and save a copy to ensure you have a good backup. If you do not download a backup will be saved still on the SBC. Last update: 2015/01/09 00:09:25 Page 165 of 188

168 SBC Restore Navigate Configuration -> Management -> Backup-Restore then click Restore. Last update: 2015/01/09 00:09:25 Page 166 of 188

169 SBC Upgrade First Create a Backup Refer to SBC Backup You must backup your configuration before upgrade process or you will Lose current config. Download Update from Sangoma Download the most recent upgrade package from the NSC Download page Go to Help -> Update, then click Upload. Last update: 2015/01/09 00:09:25 Page 167 of 188

170 Upload Update Click Choose File, then browse for the package you downloaded in step #1. Then click Upload to begin the update. The system will load the package. Last update: 2015/01/09 00:09:25 Page 168 of 188

171 Install Update Once loaded click Install to perform the upgrade. Then on the next screen click Ok to confirm the update. Restart After the upgrade is done, you will be prompted to Restart the system. Click Restart to restart the SBC. This step will reboot the server. Last update: 2015/01/09 00:09:25 Page 169 of 188

172 Verify Upgrade Once the system comes back online, after the reboot. Verify the version of NSC by navigating to Help -> About Last update: 2015/01/09 00:09:25 Page 170 of 188

173 Upgrade Cleanup Once the upgrade is completed it is recommend to delete the upgrade package file from the system. Go to Help -> System -> Update then click Delete on the applied package. Last update: 2015/01/09 00:09:25 Page 171 of 188

174 SBC Monitoring On can monitor Sangoma SBCs using standard monitoring technologies such as SNMP Monit Sangoma EMS (Roadmap) Last update: 2015/01/09 00:09:25 Page 172 of 188

175 SBC Notifications Sangoma SBC natively supports error and event reporting functionality. Using the WebGUI Notification page, user can setup reporting based on Threshold based events Error events Capacity events Audio quality events Events are delivered via SNMP (Trap) (Roadmap feature) Last update: 2015/01/09 00:09:25 Page 173 of 188

176 SBC Troubleshooting SBC PCAP Tracing Last update: 2015/01/09 00:09:25 Page 174 of 188

177 SBC PCAP Tracing Sangoma SBC s have native network capture functionality. Network Capture stores data in in PCAP file format, and is able to capture ALL network data. PCAP files are stored on Sangoma SBC file system. (SSD) More importantly Sangoma SBC can PCAP capture both Signaling (SIP) and Media (RTP) data. Last update: 2015/01/09 00:09:25 Page 175 of 188

178 Factory Reset and Reboot Front Panel Reset/Power button is used for: Factory Reset Press 1 time per second until system beeps and reboots (approx.: 10sec). A beep will sound to indicate that system has completed factory reset before system reboots. Soft Reboot Press 1 time every 3 seconds until system reboots. (approx.: 6sec) Last update: 2015/01/09 00:09:25 Page 176 of 188

179 There will be no beep on reboot. Power on/off Hold for 10 seconds Nothing will happen if pressed once To avoid accidental restart. Caution: From SBC SW release 5.0 Refer to Factory Reset section. Factory Reset Factory reset will only reset the root password and the default IP address. After the factory reset IP: user: root Password: sangoma Last update: 2015/01/09 00:09:25 Page 177 of 188

180 Professional Services Sangoma Engineers are here to support your success. Whether you need technical support and software maintenance, training, consultation and installation services, Sangoma can help you. Please contact your Sales representative for more information. Support Information Last update: 2015/01/09 00:09:25 Page 178 of 188

181 Support Information When troubleshooting SBC there are certain pieces of information from the system that will be critical. The list of information we need is as follows: The logs and configuration folders for NSC. Make a test call which demonstrates the issue you are having in order to populate the logs with debug information. Create a staging folder: mkdir nsc_support Copy the configuration folder into the staging directory: cp -r /usr/local/nsc/conf nsc_support/ Copy the logs to the staging directory: cp /usr/local/nsc/log/*log* nsc_support Provide a list of the installed packages: rpm -qa > nsc_support/packages.txt Zip the staging folder: tar -zxvf nsc_support.tgz nsc_support A packet capture from a test call which demonstrates the issue you are having. Note: If you are having an audio issue, you should configure the device for Hidden Mode before doing a packet capture. From the Web interface, click Reports -> Network Capture Click the capture button Make a test call exhibiting the issue you are having When finished, click the stop button, then the Download button and save the pcap file. A network diagram of the path of the call through your network (not strictly required but can greatly aid in troubleshooting in most cases) It is preferable to have some form of document describing the network environment SBC is deployed in including any relevant NAT or firewall devices and anything that is involved in the call flow. This can be an image or a sketch of some kind. When finished, attach nsc_support.tgz, the pcap you obtained in step 2, and any network diagram you may have from step 3 in a response to your support ticket. Hidden Mode If you are using the transcoding features of SBC, you should configure the system in Hidden Mode before doing a packet capture. This ensures that audio packets flow through NSC and will appear in the capture. Using the device in Exposed Mode will result in media flowing direct between the endpoints and the transcoding modules. If you are using a D100 card for transcoding, this step is not necessary as it is only possible to use the D100 in Hidden Mode. If you are using a D150, it is NOT possible to enable Hidden Mode. You can try disabling the media interfaces if you are not using licensed codecs like G729. Last update: 2015/01/09 00:09:25 Page 179 of 188

182 To configure hidden mode: In the Web interface, under Configuration, click Media Interfaces. Under Media Server Configuration, if your system is not already in Hidden Mode, click Modify. Check the box that says sngdsp0 and click detect. You should now be in Hidden mode. In the case of the D150: In the Web interface, under Configuration, click Media Interfaces. Under Media Server Configuration, click Modify. For the option Enable/Disable Media Interfaces select Disable then click Detect at the bottom. Last update: 2015/01/09 00:09:25 Page 180 of 188

183 Appendix Frequently Asked Questions Last update: 2015/01/09 00:09:25 Page 181 of 188

184 Frequently Asked Questions What is the SBC capacity? Sangoma provides two different tiers for its SBC. The Vega Session Controller and the NetBorder Session Controller. Both are based in the same software base, but Vega SBC is tailored to small densities (ie enterprise), from concurrent calls. The NetBorder SBC it is aimed to big enterprises or ITSP/carriers, it goes all the way to 4,000 concurrent calls with hardware-assisted RTP/transcoding. In the near future we will at least double this capacity with more powerful DSPs and memory size. The CPS (calls per second) measurement depends on many factors, including the hardware where you run it. Sangoma s SBC can run in standard Sangoma hardware appliances, custom hardware or even virtual machines. The carrier-level SBC appliance from Sangoma has been tested with 75 CPS with hardware transcoding involved. What can it transcode? Sangoma s NetBorder/Vega SBC does virtually all major codecs used in the industry, from narrow band (PCMU, G.729) to wide band codecs (ie G.722 and Siren/G from Polycom) The following is a list of supported codecs: G.711 (PCMU/PCMA), G.729, ilbc, G.722, G.722.1, GSM, G.723.1, G.726, AMR The SBC is also capable of translating a variety of protocols, such as encrypted SIP TLS/SRTP traffic into non-encrypted UDP/TCP SIP traffic. Where does it transcode? Sangoma s NetBorder/Vega SBC is extremely flexible regarding transcoding. You can decide to do transcoding in hardware or software. You can also opt for bypassing media processing and allow the RTP flow directly between endpoints (this increases SBC overall capacity to handle more sessions easily). When doing hardware transcoding there is the option to do it built-in in the appliance DSPs, or with external DSPs (connected thru an ethernet network). Last update: 2015/01/09 00:09:25 Page 182 of 188

185 How does it ensure QoS (Quality of Service)? There is several built-in mechanisms to protect QoS. You can specify CPU threshold limits to protect the quality of existing calls. Whenever the specified threshold is exceeded (ie, 80% CPU usage) the SBC will start refusing to accept new calls using a configurable SIP response code (ie 503 Service Unavailable), your equipment upstream can defer traffic to another SBC or gateway whenever it receives such code. It is also possible to specify the ToS/DiffServ octet of SIP and RTP traffic to enforce QoS policies in the routing devices. What kind of call routing does it do? All the call routing is based on an XML scripting language, you can basically match SIP requests based on any field in the SIP packet (including source IP, SDP properties, codecs, headers etc) and route it to a defined SIP trunk/gateway or using the SBC built-in ENUM or LCR modules. You can also decide to reject the call or challenge the request yourself (this can also be done automatically by the SBC based on Call Admission Control rules). How does it handle attacks? There is multiple security mechanisms. The SBC comes with an IDS/IPS system (Intrusion Detection/ Intrusion Prevention) system to block suspicious traffic. The definition of suspicious comes from a set of security rules/signatures of well-known VoIP attacks (there is rule sets for other protocols available as well, such as icmp, http). You can also specify rules for failed SIP authentication requests (REGISTER or INVITE). If a given IP is sending you multiple failed authentication requests, it is either a misconfigured device or someone trying to perform a dictionary attack or scanning your network for valid users. NetBorder SBC can detect this patterns and block the offender immediately. You can also detect malformed packets/traffic (someone trying sending garbage to see if it can crash your PBX or softw-switch), and the SBC can automatically block the offending IP address at the operating system level, where is extremely efficient to discard further packets from the offender. Last update: 2015/01/09 00:09:25 Page 183 of 188

186 How does it ensure reliability? The SBC is capable of detecting SIP devices (ie gateways, proxies, soft-switches) that are down and reroute the traffic to alternate routes. This can be configured to be done automatically. Does it provide ENUM support? Yes, we support ENUM-based routing Does it provide DTMF translation? Yes we can translate from RFC2833 to inband How well does it play with others? We ve done interoperability test with a number of PBX, phones and gateways. Some of them include: PBX / SoftSwitches: - Microsoft Lync - OpenUC / sipxecs - Metaswitch - Asterisk - FreeSWITCH Phones: - Bria - AAstra - Polycom - Grandstream ITSPs (SIP carriers): - Appia Communications - BroadVox - CallCentric - SoTel - Vitality - VoIP MS Last update: 2015/01/09 00:09:25 Page 184 of 188

187 The list will keep growing in the coming weeks. If you do not see your vendor included in the list, we ll make it work for you. Our SBC is extremely flexible and we re confident that with the right configuration we can interop with any vendor. Is there any limits for SIP trunks? The number of SIP trunks you can create is only limited by the amount of memory (RAM) and hard-drive space available. In realistic situations you won t hit the limit ever, we ve tested with 200 SIP trunks without problems (or even start to scratch any limit). Licensing is done only based on active calls, not on any other SIP dialog or request. Is there any limits for Virtual IPs? The number of Virtual IPs is unlimited. How is SIP header manipulation done? All header manipulation is done at the same time the routing is done in the XML script. Special variables define the meaning of different headers and parameters within those headers. This is an example of the INVITE URI modification in a SIP Refer request: Basically you match headers (ie ${sip_refer_to} is the variable where Refer-To header is populated by our SBC) when match against a desired regular expression, and then replace either that same header or other headers by using the export or set application. How can the RTP DTMF payload type be changed (ie from 96 to 101)? You just set a variable during call routing before sending out the outgoing INVITE. If a SIP trunk is configured to use RFC2833 for DTMF but the remote end sends inband, can the SBC detect the tones? Yes, the SBC can convert inband tones to RFC2833 Can your SBC can handle SIP and media/rtp on separate physical Ethernet lines/port. Simple answer is Yes. Last update: 2015/01/09 00:09:25 Page 185 of 188

188 Sangoma Carrier and Enterprise SBC perform RTP in hardware. We can have two RTP operation modes in our SBC: Exposed or Hidden Exposed mode Exposes RTP hardware IP addresses. RTP hardware communicates directly to remote agents via separate Ethernet port. Hidden mode Hides RTP hardware IP address Single IP and Ethernet port is used for both Media and Signaling Sangoma SBC also support VLAN s for both Signaling and Media/RTP. Last update: 2015/01/09 00:09:25 Page 186 of 188

189 What is the difference between calls and sessions? This terminology may vary across vendors and even sometimes even within the same vendor some people may mistaken one for another. Be sure to clarify the meaning when comparing telecom equipment. At Sangoma the terms call and session depend on the context. In our sales organization and to facilitate comparing our pricing to other SBCs, the term session and call are equivalent. This means that when talking to sales about your licensing needs, a session is a call with bi-directional audio and/or video. In technical terms (when going through the WebUI or talking to tech support or Sangoma engineers) Sangoma SBC s use the term session to refer to a call leg. Your typical call in a Sangoma SBC will require 2 sessions (in technical terms). An inbound session and an outbound session. As a rule of thumb you can say a given call is composed of 2 sessions, however, in some circumstances, for example call forking, sometimes Sangoma SBC may actually have 3 or more sessions at the same time for the same call (one inbound session created multiple outbound sessions), until one of them receives early media or is answered and then the call session count is reduced to 2 (the inbound and only one outbound, the other outbound sessions are cancelled once one of the outbound sessions is confirmed). If you acquire from our Sales organization an SBC with support for 250 sessions, you re getting an SBC with support for 250 sessions or calls (session and call is the same in this context). However, when you navigate through the WebUI (for example in the Sessions page) you will see 2 sessions per call (inbound/outbound legs) but you will be able to see up to 500 of these (twice as much as you have licensed). How Does Call Forking work with the SBC? With SIP Forking you receive one call, and the SBC as a result, forks into multiple calls (2 or more). Once one of the forked calls answers the first one in answering gets bridged, the other ones get cancelled. Last update: 2015/01/09 00:09:25 Page 187 of 188

190 How to return multiple values from curl? The response from curl is always stored in the variable $ {curl_response_data}, but you can return multiple values simply separate the values by commas, or any other character you want. If you separated the values by commas the HTTP response would be: value-1, value-2, value-3 After you execute the curl application you have to transfer to a new extension. The transfer is necessary to make the variable $ {curl_response_data} available to be evaluated in a new condition. In the example below the exec_curl extension is simply just running the curl app. The second extension parse_curl_response is cutting individual values separated by commas from the string. <extension name="exec_curl"> <condition> <action application="curl" data=" roting.php?number=${destination_number}&callerid=${caller_id_number}"/> <action application="set" inline="true" data="auto_hunt=true"/> <action application="transfer" data="parse_curl_response"/> </condition> </extension> <extension name="parse_curl_response"> <condition field="${curl_response_data}" expression="^(\w+),?(\w+)?,?(\w+)?$"> <action application="log" data="crit value #1: $1"/> <action application="log" data="crit value #2: $2"/> <action application="log" data="crit value #3: $3"/> </condition> </extension> Now can see the values are stored in the variables $ 1, $ 2, $ 3 and you can use them as you like in your dial plan. Note as well how you cannot use the ampersand character in a curl request unless you escape it (because it s XML) using HTML entities (&) Last update: 2015/01/09 00:09:25 Page 188 of 188