Case Study: ER24 SIP Gateway

Transcription

1 Case Study: ER24 SIP Gateway Com.X SIP Gateways provide flexible, high availability Telco & SIP interconnect for multiple, legacy PBX s Version 1.0, 21 May Far South Networks (Pty) Ltd.

2 Document History Version Date Description of Changes 1 21/05/13 Document creation Far South Networks (Pty) Ltd.

3 Table of Contents 1 Introduction Overview Background SIP Gateway Requirements Client Brief ER24 PBX setup SIP Gateway platform architecture IP Telephony solution Solution design Network diagram Equipment list Network design PRI configuration Trunk configuration Call flow requirements Inbound Outbound Notes on capacity Installation instructions Physical unit installation and earthing Networking cabling Primary rate ISDN Configuration instructions Accessing the systems Trunk configuration Custom configurations (no-gui) Test report Functional testing Performance testing... 11

4 1 Introduction 1.1 Overview This document presents a case study of the design and installation of a Com.X2 SIP Gateway solution for ER24, Sunninghill, Gauteng, providing dynamic and flexible call routing between two on site, legacy PBX s, ensuring high availability and failover to Telkom PRI and (Activate Telecoms) SIP services. 1.2 Background Far South Networks was approached by Activate Telecoms (sales@activate- telecoms.co.za) to develop a SIP Gateway solution to the unique requirements of their client, ER24. Activate Telecoms are a Johannesburg based reseller of Far South IP PBX and SIP Gateway platforms Far South Networks (Pty) Ltd.

5 Com.X Administrator Guide Page 5 2 SIP Gateway Requirements 2.1 Client Brief ER24 wanted transparent voice connectivity independent of whether there was a network failure from their Telco providers. ER24 required SIP based connectivity across fibre as a primary out and inbound solution while maintaining Telkom PRI s as redundancy should Activate Telecoms SIP network be unavailable. 2.2 ER24 PBX setup The existing ER24, Sunninghill, Gauteng, office telephony infrastructure consisted of two on-site, legacy PBX s: 1. Emergency Call Centre PBX: Avaya PBX supporting 30 to 40 emergency call centre staff 2. General staff and administration: Samsung 7400 supporting 40 to 50 users Figure 1 below presents a diagram of the telecoms infrastructure setup at ER24. Figure 1 ER24 telephony infrastructure

6 3 SIP Gateway platform architecture 3.1 IP Telephony solution The proposed solution, as described in figure 2 below, consists of two Com.X2 SIP Gateway devices each with their own: SIP interconnect to Activate Telecom Telkom PRI connection In order to provide a flexible and dynamic, high availability interconnect between the existing PBX s and the available Telecom and IP networks, the following load balancing switch paths were provided: Traffic failover between each Activate Telecom SIP service Traffic failover between each Telkom PRI line Figure 2 Proposed, high-level telephony architecture Far South Networks (Pty) Ltd.

7 Com.X Administrator Guide Page 7 4 Solution design Network diagram The final platform network design diagram developed by Far South Networks is shown in Figure 3. Figure 3 Network solution diagram Equipment list The equipment list is indicated below: 1 x ita-3p codename 'Phoebe' 1 x ita-3p codename 'Ganymede' 1 x Com.X2 codename 'Phoebe' 1 x Com.X2 codename 'Ganymede' Com.X2 and ita power 10 x CAT-5 LAN cables Network design The network switch was partitioned into three partitions: Partition 1: ports 1-8 reserved for the Phoebe ita PRI ports

8 Partition 2: ports 7-16 reserved for the Ganymede ita PRI ports Partition 3: ports reserved for LAN connectivity PRI configuration The PRI within each ita was configured as follows: phoebe PRI 1: Network mode, System timing, Drive clocking, E1 CRC-4, ETSI-ISDN, ISDN, 16ms+NLP echo cancellation phoebe PRI 2: Network mode, System timing, Drive clocking, E1 CRC-4, ETSI-ISDN, ISDN, 16ms+NLP echo cancellation phoebe PRI 3: Terminal mode, PRI priority 1 timing, E1 CRC-4, ETSI-ISDN, 16ms+NLP echo cancellation ganymede PRI 1: Not configured (future PRI to Avaya) ganymede PRI 2: Network mode, System timing, Drive clocking, E1 CRC-4, ETSI-ISDN, ISDN, 16ms+NLP echo cancellation ganymede PRI 3: Terminal mode, PRI priority 1 timing, E1 CRC-4, ETSI- ISDN, 16ms+NLP echo cancellation Trunk configuration Two SIP trunks, one per Com.X2 were configured to carry traffic to and from the Activate Telecom SIP service provider (Neotel1 and Neotel2). A SIP trunk was configured for load-balancing between the two Com.X2 s, dedicated to provisioning inbound Activate Telecom SIP traffic destined for the PRI connected to the Samsung system (lbtosamsung) A SIP trunk was configured for load-balancing between the two Com.X2s, dedicated to outbound Traffic fail-over between the two SIP services (lbsip) An IAX trunk was configured for load-balancing between the two Com.X2 Gateway s, dedicated to outbound Telkom traffic fail-over between the two Telkom PRIs (lbiax) On each system, a Flexpath was created for receiving calls on each trunk interface, routed to the correct associated outbound route. On each system, an outbound route was created for sending calls on each trunk interface. On each system, a Flexpath was created for each load-balance trunk for routing of fail-over calls to the appropriate destination interface. 4.2 Call flow requirements The following call flow requirements were agreed upon with Activate Telecom and was implemented in the Com.X2 systems' configurations and tested: Inbound All calls inbound on TELKOM 1 are routed to the Avaya via PRI Ex 1 Telkom All calls inbound on TELKOM 2 are routed to the Avaya via PRI Ex 2 Telkom Far South Networks (Pty) Ltd.

9 Com.X Administrator Guide Page 9 All calls inbound on Activate Telecom SIP with the Samsung 7400 DID range are routed to the Samsung 7400 via PRI 3 Ex ported Telkom All other calls inbound on Activate Telecom SIP are routed to the Samsung 7400 via PRI 3 Ex ported Telkom(to be handled by the office) Congestion on trunks in the inbound direction results in busy Outbound All calls originating from the Avaya on PRI 1 Ex Telkom are routed to Com.X 1.1 via Neotel SIP 40 Fail-over to Com.X 1.2 Neotel1 Fail-over to Com.X 1.1 TELKOM 1 Fail-over to Com.X 1.2 TELKOM 2 All calls originating from the Avaya on PRI 2 Ex Telkom are routed to Com.X 1.2 via Neotel1 Fail-over to Com.X 1.1 Neotel2 Fail-over to Com.X 1.2 TELKOM 2 Fail-over to Com.X 1.1 TELKOM 1 All calls originating from the Samsung 7400 on PRI 3 Ex Telkom are routed to Com.X 1.1 via Neotel1 Fail-over to Com.X 1.2 Neotel1 Fail-over to Com.X 1.1 TELKOM 1 Fail-over to Com.X 1.2 TELKOM Notes on capacity If SIP trunk congestion is encountered on a Com.X and fail-over results in capacity of the other Com.X SIP trunk being utilized, this in turn under load on the PRI trunks connected to the second Com.X might lead in the second Com.X in turn trying to fail over to SIP on the first Com.X, resulting in fail-over to the second Com.X's TELKOM trunk. I.e. an indicator that more SIP capacity is required on a given Com.X would be that that Com.X's TELKOM trunk monitoring consistently shows increased traffic. An indicator that the system's capacity as a whole is over-utilized would be when both Com.X TELKOM trunks consistently carry high load. Should SIP trunks or TELKOM trunks become unavailable, load-balance and fail-over should continue in the manner described above until all trunk options have been exhausted. Com.X 1.1 and 1.2 SIP trunks would be limited to match Activate Telecom SIP trunk capacity using the "maxchannels" configuration field. If SIP capacity is increased, this should be configured on the Com.X SIP trunk as well. 4.3 Installation instructions Physical unit installation and earthing Please refer to the standard Com.X and ita installation guides.

10 4.3.2 Networking cabling Connect the 3x phoebe ita LAN ports to the first block of 8 ports on the Tenda TEH1226G switch (ports 2,4,6) Connect the 2x ganymede ita LAN ports to the first block of 8 ports on the Tenda TEH1226G switch (ports 12,14) Connect the phoebe X2's LAN 1 (the LAN port closest to the X2 power supply) to the third block of 8 ports on the Tenda TEH1226G switch (port 18) Connect the ganymede X2's LAN 1 to the third block of 8 ports on the Tenda TEH1226G switch (port 20) Connect the switch port 22 to the local LAN switch at the client site. Connect the phoebe X2's LAN 2 to block 1 on the switch (port 8) Connect the ganymede X2's LAN 2 to block 2 on the switch (port 16) Connect the phoebe X2's LAN 3 to the Neotel router (right-most LAN port) Connect the ganymede X2's LAN 3 to the Neotel router (right-most LAN port) Connect the ganymede X2's LAN 4 to the phoebe X2's LAN 4 (LAN4 is just left of LAN 3) Primary rate ISDN Connect the phoebe ita's PRI port 1 to Avaya Connect the phoebe ita's PRI port 2 to Samsung Connect the phoebe ita's PRI port 3 to Telkom Leave ganymede's ita port 1 open (future PRI) Connect the ganymede ita's PRI port 2 to Avaya Connect the ganymede ita's PRI port 3 to Telkom 4.4 Configuration instructions Accessing the systems Both X2s can be accessed via serial console, or via their default IPs on the interfaces Note that moving from the X2 power socket to the right, the LAN ports are numbered as follows: 1, 2, 4, 3. Note also that LAN 1 (eth0) is configured as a DHCP client by default. Note also that LAN 4 (eth3) is reserved for load-balance connectivity nectivity between the Com.X2s and its configuration is specific and not the default Trunk configuration (Mandatory) On both X2 systems, configure the Activate Telecom VPN as appropriate on LAN3. (Mandatory) On both X2 systems, configure the Activate Telecom ecom trunks' maxchannels as required to enable load-balancing Far South Networks (Pty) Ltd.

11 Com.X Administrator Guide Page 11 (Optional) On both X2 systems, configure LAN1 with static IPs on the client's LAN (or determine the DHCP allocated IPs) Custom configurations (no-gui) In /etc/asterisk/extensions_comma.conf cause code 27 was mapped to cause code 20 to facilitate trunk fail-over on PRIs where the Com.X2 plays the network role. 4.5 Test report Functional testing The following functional tests were successfully performed (please refer to Figure 3): Calls inbound on TELKOM 1 routed to the Avaya via PRI Ex 1 Telkom Calls inbound on TELKOM 2 routed to the Avaya via PRI Ex 2 Telkom Calls inbound on Com.X 1.1 Neotel SIP routed to the Samsung 7400 via PRI 3 Ex ported Telkom Calls inbound on Com.X 1.2 Neotel SIP routed to the Samsung 7400 via PRI 3 Ex ported Telkom via load-balance trunk Congestion on TELKOM 1 trunks in the inbound direction results in busy Congestion on TELKOM 2 trunks in the inbound direction results in busy Congestion on Neotel 1 in the inbound direction results in busy Congestion on Neotel 2 in the inbound direction results in busy Calls originating from the Avaya on PRI 1 Ex Telkom routed to Com.X 1.1 via Neotel SIP 40 o Fail-over to Com.X 1.2 Neotel SIP 30 o Fail-over to Com.X 1.1 TELKOM 1 o Fail-over to Com.X 1.2 TELKOM 2 Calls originating from the Avaya on PRI 2 Ex Telkom are routed to Com.X 1.2 via Neotel SIP 30 o Fail-over to Com.X 1.1 Neotel SIP 40 o Fail-over to Com.X 1.2 TELKOM 2 o Fail-over to Com.X 1.1 TELKOM 1 Calls originating from the Samsung 7400 on PRI 3 Ex Telkom are routed to Com.X 1.1 via Neotel SIP 40 o Fail-over to Com.X 1.2 Neotel SIP 30 o Fail-over to Com.X 1.1 TELKOM 1 o Fail-over to Com.X 1.2 TELKOM 2 PRI trunk disconnection fail-over tested on all trunks Neotel trunk maxchannels capacity fail-over on both Neotel trunks Performance testing Successfully placed > 82,000 calls over a 15 hour period at a rate of 1.5 calls / second.