SIP Network Server Network Deployment for VoIP Services

Size: px

Start display at page:

Download "SIP Network Server Network Deployment for VoIP Services"

Christina Jennifer Spencer
6 years ago
Views:

1 Knowledge Management SIP Network Server Network Deployment for VoIP Services

2 Copyright Information 2005 Flextronics Software Systems Ltd. All rights reserved. No part of this document may be reproduced or transmitted in any form or by any means, electronic or otherwise, including photocopying, reprinting or recording, for any purpose, without the express written permission of Flextronics Software Systems Ltd. Disclaimer Information in this document is subject to change without notice and should not be construed as a commitment on the part of Flextronics Software Systems. Flextronics Software Systems does not assume any responsibility or make any warranty against errors that may appear in this document and disclaims any implied warranty of merchantability or fitness for a particular purpose. Trademarks All other company, brand, product or service names mentioned herein are the trademarks or registered trademarks of their respective owners. Flextronics Software Systems Ltd. Plot 31, Electronic City, Sector 18, Gurgaon Haryana (INDIA) Tel: / Fax: / info@flextronicssoftware.com Visit us at: 2

3 SIP Network Server e r CONTENTS 1. Introduction Deployment in ITSP environment Deployment models Starter configuration Advanced configuration Service deployment scenarios IP Centrex features for corporate customers VoIP services for residential and SoHo customers Features SIP functions Transaction-stateful Proxy Registrar/Location server Transport protocols Routing Security Management Debugging Accounting Value proposition Centrex Centrex features Services Call forwarding features Call screening Hunt groups Load balancing Redundancy feature Route based congestion control Emergency calls Caller identification and privacy features Configuration and management Carrier-class performance Appendix A info.flextronicssoftware.com

4 In troduction t o 1. Introduction This document describes the various network deployment scenarios of the SIP Network Server from Flextronics Software Systems (FSS). It also outlines the various value-added services that are enabled through the deployment approach adopted by FSS. FSS' SIP Network Server is a carrier-grade, high performance, feature rich offering that serves as a core infrastructure router by providing the transaction-stateful proxy, registrar and location server, and presence server functionality. Targeted at ITSPs and Telcos, the SIP Network Server offers several advanced features - such as SIP Centrex (Hosted PBX) and Per-User Call Processing Language - that are of tremendous value to service providers, assisting them in product deployment and in providing value-added services to their subscribers. The SIP Network Server is a true carrier-class deployment, designed to ensure maximum scalability (SIP load balancing, multi-threaded architecture), outstanding performance throughput, reliability (virtual IP hot standby redundancy), manageability (SNMP & HTTP support), flexibility (extensive configuration parameters), interoperability (RFC 3261 compliant, interop tested with most SIP solutions for various vendors at SIP IT events) and congestion control. The SIP Network Server can support as many as 500,000 subscribers, making it one of most scalable and cost effective solutions for providing SIP services in access and core networks. It is deployed in some of the largest SIP-based basic telephony and Centrex networks in the world. 5 info.flextronicssoftware.com

as well as for both Access and core networks. 2.1 Deployment Models The FSS SIP Network server is a highly scalable entity and supports multiple deployment models.

5 Deployment e in ITSP Environment n n 2. Deployment in ITSP Environment In this chapter we explain the various network deployment models and service deployment scenarios for the FSS SIP Network Server for various types of clients/services as well as for both Access and core networks. 2.1 Deployment Models The FSS SIP Network server is a highly scalable entity and supports multiple deployment models. It can cater to the requirements of newer ITSPs with small subscriber bases, as well as large telcos with hundreds of thousands of subscribers. The service provider can select a deployment model based on his current needs and can subsequently scale the network up to a higher configuration as the subscriber base and network usage increases. This allows the service provider the luxury of scaling up his small initial investment based on incremental returns Starter Configuration This is the basic configuration, in which the whole system runs on just two server platforms. This is the minimum hardware requirement for using the SIP Network Server in the virtual IP redundancy mode. Figure 2-2: Advanced network deployment configuration for SIP Network Server This deployment model is ideal for large ITSPs/Telcos, who cater to a vast number of subscribers. This model provides maximum scalability and gives service providers the flexibility to deploy the solution according to their network needs. For instance, if a service provider is hosting a number of services on the application server, he can choose to deploy a number of application servers with services/subscribers distributed among them. Alternatively, if the core infrastructure proxy services are being used heavily in the network, if can increase the number of proxies in the farm and distribute the load among them. 2.2 Service Deployment Scenarios The following two service deployment scenarios have been identified and are explained in the sections below:. IP Centrex for corporate customers. VoIP services for residential/soho customers Figure 2-1: Basic network deployment configuration for SIP Network Server This deployment model does not require a large initial investment, yet is capable of meeting the needs of small and medium ITSPs catering to around 60,000 subscribers (on Intel Rack mount servers running dual 2.4 GHz xeon processors) Advanced Configuration In this configuration, different components of the SIP Network Server run on different hosts IP Centrex Features for Corporate Customers Centrex is a set of specialized features primarily for voice services, where the equipment providing the call control and service logic functions is owned and operated by the service provider and hence is located on the service provider's premises. FSS proposes the following implementation for corporate customers: A numbering plan can be defined and extensions can be assigned to all the users. For example, if a large corporate has offices in New York, London and Mumbai, three different extension ranges can be defined and assigned to the three offices. Extensions can be assigned to employees in the New York office, extensions to the Mumbai office and extensions to the London office. Employees will be able to call one another by dialing only the desired extension, irrespective of their location. 6

It is also possible to assign specific privileges to different users in an organization. For instance, a company might want to give long distance dialing privileges only to managers.

Employees need to dial only the extension number to reach each other. The SIP Network Server also allows the ITSP to tie up with several carriers to terminate PSTN calls.

6 It is also possible to assign specific privileges to different users in an organization. For instance, a company might want to give long distance dialing privileges only to managers. The figure below illustrates a sample Centrex configuration for a hypothetical corporate body. The corporate has two branch offices and the extension ranges for both branches are defined. Employees need to dial only the extension number to reach each other. The SIP Network Server also allows the ITSP to tie up with several carriers to terminate PSTN calls. Based on the destination number pattern, the call can be routed to the appropriate destination gateway. Therefore, if the service provider gets lower rates for calls to a specific country, say, India via a particular carrier, it is possible for him to route all calls to India using that carrier, while calls made to other destinations are terminated via the default carrier. Figure 2-4: Network diagram for providing SIP services to residential/soho users Figure 2-3: Sample Centrex configuration for corporate customers VoIP Services for Residential and SoHo Customers A majority of residential and SoHo customers use VoIP networks to make low rate international calls. These customers usually connect to the Internet through a dial-up connection provided by an ISP (PC users), or connect to an ITSP network through an IP phone or a 2/4 port FXS gateway with a public IP address. Figure 2-4 depicts the SIP Network Server deployment for providing VoIP services to residential and SoHo customers. As shown in the figure, the customer connects to the Internet via a dial-up connection provided by an ISP, or through the IP phone or FXS gateway. The ITSP's VoIP service center has a portal where users can register for VoIP services. (The administrator may also register users for VoIP services). Each user is provided with a unique username and password. The user configures the username and password on a SIP device (softphone/ip Phone/gateway etc.), after which the SIP device registers the user with the SIP Network Server. The SIP Network Server validates the user's identity and allows him to make calls. 7 info.flextronicssoftware.com

7 Features e 3. Features The SIP Network Server supports the following features: 3.1 SIP Functions Transaction-stateful Proxy The core infrastructure server component of the SIP Network Server provides the transaction-stateful proxy functionality. In this mode, the Network Server provides LDAP based lookup components as well as a DNS-SRV based address resolution mechanism for routing purposes. The SIP Network Server supports Record-routing procedures to ensure that the proxy remains in the signaling path for the entire duration of the call. It also supports forking procedures, allowing users with multiple contacts to be reached in either sequential or parallel forking fashion Registrar/Location Server In the Registrar mode, the SIP Network Server provides an ODBC database interface to store/access Registration information for maintaining Location databases. The database interface is abstracted so that the back-end can be changed to any database preferred by the customer. The SIP Network Server also supports Digest Authentication schemes for secure access. 3.2 Transport Protocols The SIP Network Server supports the following transport protocols for SIP signaling:. User Datagram Protocol (UDP). Transport Control Protocol (TCP). Transport Layer Security (TLS) objects are defined to facilitate configuration of the SIP Server through SNMP. Support for SNMP has been developed using the emanate toolkit. These interfaces enable configuration and provisioning, performance statistics monitoring and fault management. 3.6 Debugging The SIP Network Server has error logging and tracing capabilities that allow system administrators to troubleshoot problems quickly. It supports various error levels (critical, major, minor etc) and the administrator can decide the type of errors that it should log. It also provides multiple levels and filters for tracing, which allow administrators to address problems without significantly degrading system performance. For example, if one user complains that his calls are not going through, the system administrator can set the filter to trace calls made by that particular user and determine the source of the problem. 3.7 Accounting The SIP Network Server provides text based CDRs for each transaction that it handles. It generates several types of CDRs, such as stateful CDRs, CPL CDRs, translation CDRs and registrar CDRs.These CDRs are stored in flat files and can be given to any mediation/billing system for billing purposes. The flat files can be rotated on a time basis or a number of record basis etc. This feature can be used to avoid creating a single, excessively large file. The format of the CDRs is also configurable (field separators, record separators etc.) for ease of integration with the billing system. 3.3 Routing. Static and dynamic registrations. DNS SRV Lookup. Prefix-based Routing 3.4 Security. Transport Layer Security (TLS). Access Control Lists (ACLs). Digest Authentication 3.5 Management The SIP Network Server contains the following interfaces:. Command Line Interface (CLI). Web based Graphical User Interface for remote management. SNMP Interface: The SIP Network Server supports SIP MIB objects as defined in draft-ietf-sip-mib-04.txt in the 2.1 release. In addition, MIB 8

Value Proposition o i o 4. Value Proposition SIP Network Server provides a feature-rich, carrier-class solution to ITSPs for VoIP service deployments.

1 Centrex An IP Centrex refers to a number of IP telephony solutions where Central Office Exchange Service (Centrex) is offered to a customer who transmits its voice calls to the network as

8 Value Proposition o i o 4. Value Proposition SIP Network Server provides a feature-rich, carrier-class solution to ITSPs for VoIP service deployments. It has several advanced features - such as Centrex services, per User CPL etc. - that give service providers the flexibility to provide focused, value-added services to various user segments. 4.1 Centrex An IP Centrex refers to a number of IP telephony solutions where Central Office Exchange Service (Centrex) is offered to a customer who transmits its voice calls to the network as packetized streams across a broadband access facility. Figure 3-1 depicts a typical network scenario with multiple dial plans. mechanisms to route the calls to other dial plans/pbxs (access codes) and off-net calls (outbound access codes). Any call originating from a given numbering plan is analyzed according to its dial plan to determine its destination. This facilitates the routing of the call to the correct destination. This basically brings the concept of user groups within the Network Server - a set of users can be grouped under a single private dial plan that controls the routing of calls within that group or to other groups. Within the SIP Network Server, a dial plan or a Numbering Plan (NP) is assigned unique NP codes. However, NP codes can be reused across different Network Servers. The NP code can be of variable length, as depicted in Figure 3-1. Similarly, the length of the extensions in the different NPs can be variable. For example, in Figure 3-1 the extensions in NP1 in NS2 are of length 4 and those in NP3 of NS2 are of length 3. The number of extensions in NPs may vary. These have to be configured in the dial plan. For example, in Figure 3-1, the number of extensions in NP1 of NS2 is 50, whereas in NP2 of NS2 there are 1000 extensions and in NP3 of NS2 there are 100 extensions. The length of the access codes, the extensions, and the number of extensions in each NP will be defined in the dial plan. The users belonging to an NP will register with the NS with 'NP Code + extension@nsx.com' as their E.164 alias. For example, user A with extension 1005 in NP1 of NS1 will register with NS1 as @NS1.com whereas user B with same extension 1005 belonging to NP2 of NS1 will register with NS1 as ' @NS1.com'. This ensures reusability of extension numbers across different NPs while maintaining the uniqueness of aliases in the NS and also facilitates the NS in identifying the NP to which the user belongs at the time of registration. Alternatively, as an example, an extension, 'abcd', from NP1 of NS1, can register itself as abcd@np1.ns1.com. Figure 4-1: Multiple dial plan configuration for SIP Network Server The Centrex feature (also referred to as the dial plan feature) allows the SIP Network Server to host users of multiple PBXs, representing multiple enterprises or even multiple groups within the same enterprise. Each of these PBXs is an entity that controls a set of extensions, including calls originating from and terminating at these extensions. Each PBX in the system can be associated with a dial plan. The dial plan defines the numbering scheme for the extensions in the PBX. It also defines Figure 4-2: Centrex - Multiple and re-usable dial plans 9 info.flextronicssoftware.com

4.1.1 Centrex features. Extension dialing - Provision for short number dialing, configurable on a per dial plan basis for any length of dialed digits (shorter than full number).

9 4.1.1 Centrex features. Extension dialing - Provision for short number dialing, configurable on a per dial plan basis for any length of dialed digits (shorter than full number).. Access codes - Facility to reach persons belonging to other dial plans using an access code.. Operator lines - Provision to map single digit numbers to full numbers for e.g. dialing 9 to reach the operator.. Class of service - Provision to access privileged services such as National Long Distance (NLD) and International Long Distance (ILD).. Call Blocking - Provision to prevent users from accessing premium services (service provider can specify the rejection response codes in the dial plan).. Direct Inward Dialing (DID) - Provision to directly reach users inside a Centrex by dialing the full number.. Intelligent routing - Provision to specify the next hop route for a call, based on caller and callee information.. Privilege handling - Provision to specify the necessary privileges associated with each number translation being performed in the dial plan. 4.2 Services The SIP Network Server uses Call Processing Language (CPL) for service representation. CPL is an XML-based language that can be used to describe and control Internet telephony services. The CPL implementation is based on the 'draft-ietf-iptel-cpl-06.txt' IETF draft specification. The CPL engine is provided on a per user basis. This allows every subscriber to configure his/her own CPL and use the various services provided by the CPL Call forwarding features. Call Forward Unconditional. Call Forward Busy. Call Forward No Answer. Time-of-day based Forwarding Call Screening. User Black list/white list Hunt Groups. Ability to host support services like helpdesk, customer care. User dials a single number, the calls is delivered to the free agent 4.3 Load Balancing The SIP Network Server has a load balancing architecture which enables it to achieve a very high level of scalability. It uses a load balancing server that distributes incoming requests between the multiple servers present in the farm. The SIP proxy servers are accessible through the load balancer (LB). The publicly known SIP server address for the domain is the address of the Load Balancer (LB). The load balancer monitors the load at each of the SIP proxy servers in the server farm. Incoming calls are routed by the LB to the SIP servers based on the load being handled by each server. The load balancer is also SIP-aware and ensures that all messages belonging to a transaction go to the same back-end server. It routes messages like a normal SIP proxy by adding Via headers to messages forwarded by it. The corresponding responses flow back to the caller through the load balancer. The managed SIP servers record the route, while the load balancer does not. This ensures that subsequent messages in the dialog bypass the LB, thereby improving performance. Figure 4-3: Load balancing and Hot Redundancy feature of SIP Network Server The load balancer receives periodic updates from the proxy servers indicating the load on them. New messages are routed based on the load on the servers. The allocation uses a weighted random selection; the weight used is inversely proportional to the load on the managed servers. 4.4 Redundancy Feature The SIP Network Server supports High Availability (HA for LB). The HA setup for LB supports the Hot Stand-by feature. The basic HA setup contains two instances of LB running over a sub-net, with one of them ACTIVE and the other in STAND-BY mode. The ACTIVE instance synchronizes with the STAND-BY by updating the message routing information whenever a new transaction path is established with the SIP servers. Role switchover happens between ACTIVE and STAND-BY in the following circumstances:. System crash. LB server process crash. Network Interface Card (NIC) hardware failure. Network connection failure to NIC 10

10 In all the above situations the STAND-BY system takes over the HA IP address and becomes the ACTIVE instance. Calls that are already established and in progress continue to be assigned to the same SIP servers by the role-switched ACTIVE instance. This ensures that transactions do not break in such situations. 4.5 Route Based Congestion Control The SIP Network Server is also capable of monitoring congestion on a per-route basis. On determining that a route is congested, the Network Server drops the message with a 5xx response. An external process called the Routing Engine monitors the Routes. Each SIP server in the farm queries the Routing Engine for congestion information before forwarding a Request. The Routing Engine determines the level of congestion for that Route and informs the SIP server of the same. 4.8 Configuration and Management. Web interface for configuration from remote location - HTTP interface for easy integration with portal for subscriber addition - Subscriber self provisioning applications. SNMP interface - Supports complete SIP MIB - Easy integration with OSS/BSS system. Command Line Interface 4.9 Carrier-class Performance. Upto 750, 000 subscribers (on ATCA multiple proxy farm configuration). Upto 2 million BHCA (on ATCA multiple proxy farm configuration) The Routes to be monitored are configurable at the Routing Engine and are indicated in a plain text file. 4.6 Emergency Calls The emergency-calling feature in the SIP Network Server enables administrators to configure URLs that represent emergency response centers. The Network Server handles the calls made to these numbers differently from regular calls. It identifies an emergency call by matching the request-uri of the request with the emergency locations that the administrator has specified in the configuration file. The SIP Network Server processes emergency calls with a higher priority than regular calls to enable them to be established with minimum delay. Emergency calls also have special routing procedures - for example, even when a server is blocked for maintenance work, emergency calls will be routed through. 4.7 Caller Identification and Privacy features The SIP Network Server supports the feature of providing authenticated identity of a subscriber. This identity will be made available to other SIP elements within a trusted domain and outside it, subject to the privacy restrictions of the user. The Network Server supports the definition of the Calling Line Identity Presentation/ Calling Line Identity Restriction (CLIP/ CLIR) feature as defined in the draft-ietf-sip-asserted-identity-02 and the draft-ietf-sipping-nai-reqs-02 IETF drafts. It also conforms to the draft-ietf-sip-privacy-general-01 IETF draft for providing the CLIP/ CLIR feature. 11 info.flextronicssoftware.com

11 Appendix p A References. 'SIP: Session Initiation Protocol', RFC 3261, Rosenberg et. al, June 'HTTP Authentication: Basic and Digest Access Authentication', RFC 2617, June 1999, Franks et. al.. 'SIP: Locating SIP Servers', draft-ietf-sip-srv-06.txt, August 'Management Information Base for Session Initiation Protocol', draft-ietf-sip-mib-04.txt, August 'Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks', RFC 3325, C Jennings, Nov 'Short Term Requirements for Network Asserted Identity', RFC 3324, M Watson, Nov 'A Privacy Mechanism for the Session Initiation Protocol (SIP)', RFC 3323, J Peterson, Nov 'URLs for Telephone Calls', RFC 2806, A Vaha-Sipila, April 'A Language for User Control of Internet Telephony Services', draft-ietf-iptel-cpl-06, Lennox and Schulzrinne, Jan

12 Flextronics Software Systems (formerly Hughes Software Systems-HSS) is a global end-to-end communications solutions provider with over 250 customers worldwide, in the telecom infrastructure and handsets, c ommunication service providers, systems integrators and independent software vendors space. It is a part of Flextronics, which has engineering, manufacturing and logistics operations in 32 countries spread over five continents. Flextronics Software Systems has development centers across India and Germany and associate companies in the Ukraine and South Africa. It also has sales offices in more than 10 locations worldwide. United States United Kingdom (301) Germany Japan India Flextronics Software Systems

ORACLE ENTERPRISE COMMUNICATIONS BROKER

ORACLE ENTERPRISE COMMUNICATIONS BROKER A CORE COMMUNICATIONS CONTROLLER KEY FEATURES Centralized dial plan management Centralized session routing and forking Multivendor UC protocol normalization SIP