OfficeMaster Gate (Virtual) Enterprise Session Border Controller for Microsoft Lync Server. Quick Start Guide

(1)

OfficeMaster Gate

(Virtual) Enterprise Session Border

Controller for Microsoft Lync Server

Quick Start Guide

(2)

Copyright and Legal Notice

Copyright © 2013 Ferrari electronic AG. All rights reserved. No part of this document may be copied, in any way, without written approval from Ferrari electronic AG. All trademarks mentioned are registered

(3)

1.3 OfficeMaster Gate as a virtual or physical SBC ... 2

2 Quick Start ... 3

2.1 Preparing OfficeMaster Gate as an SBC ... 3

2.2 Configuring external network for SIP trunks ... 5

2.3 Using SIP trunks with registration from internal network ... 6

2.4 The SIP2SIP Concept ... 7

2.5 Configuring calls from SIP trunk to Lync ... 7

2.6 Configuring calls from Lync to SIP trunk ... 9

3 Troubleshooting and monitoring ... 12

3.1 Using OfficeMaster Syslog service and “Syslog Analyzer” tool ... 12

3.2 Monitoring via Web-Interface ... 12

(4)

(5)

1 Introduction

1.1 What is a Session Border Controller?

Session Border Controllers (SBCs) are typically installed between different SIP entities like trunks, PBXs or UC systems. They provide a broad set of features but not all of them are used in every situation. Typical functions available are:

Interoperability

SIP is used for VoIP with many variations in detail. Some providers require specific use of optional SIP headers while UC systems and IP-PBXs may have a different focus in their environments, e.g. support of media bypass and encryption. Often SIP trunks only support SIP over UDP while internally TCP or TLS is required. Also media translation may be necessary, either between RTP and SRTP or between difference Codecs. All of these adaptations can be handled by SBCs. Session border controllers act as SIP back to back user agents (B2BUA) where a VoIP call uses separate SIP sessions on each side.

Security

When SBCs are used at the border between public and private networks, they have to ensure that no attacks are possible from the internet. No IP communication should be routed between both sides and only the desired VoIP traffic must be allowed.

Enhanced usages

In addition to connecting VoIP sessions between two SIP endpoints SBCs may offer other communication features. They could handle fax calls separately by routing them to

different endpoints using fax pass-through or T.38 protocol conversion. OfficeMaster Gate even goes one step further: It can send or receive faxes autonomously using T.30 or T.38 to offload real-time operation from fax servers.

In addition SBCs may support analog devices through FXS ports or the support of external analog adapters (SIP ATAs).

Finally SBCs even can provide ISDN interfaces to connect legacy PBXs to the outside world during migration to UC and SIP.

High availability

Enterprises still strongly rely on telephony, therefore SBCs play a critical role and must be able to provide high availability. They should support failover and load balancing both with SIP trunks and UC systems. They could also offer additional TDM/PRI based PSTN connections to be used in case of IP connectivity problems.

(6)

Page 2 OfficeMaster Gate SBC Ferrari electronic AG

1.2 Using SBCs with Microsoft Lync

There are different kinds of SIP trunks connecting to Microsoft Lync server:  Trunks from telephony providers not qualified for Lync

 Trunks qualified for Lync via “Open Interoperability Program” (OIP)  SIP connections to PBX systems

PBX vendors usually do not invest in Lync interoperability and qualification – most of them see Lync as a threat because it more and more replaces traditional PBX systems.

Therefore only limited SIP compatibility is given and in most situations there are several restrictions when using a direct SIP connection to a PBX. Important features like media bypass, encryption, REFER support and many others are often only supported by using a qualified SBC between PBX and Lync systems.

Many SIP trunks from telephony providers are not compatible with Lync for several reasons, a typical one is the missing support of SIP over TCP or TLS. In addition these providers often require the use of special SIP headers or even registration using separate credentials. In all those cases a Lync qualified SBC deployed on premises will enable the use of such trunks together with Lync.

Even with Lync qualified SIP trunks a separate SBC provides additional benefits, like:  Support for analog and other legacy devices

 Fax support – either with dedicated fax machines or using a fax server

 Media bypass – this can eliminate the need to install separate mediation servers which alone may pay for the investment in an SBC!

1.3 OfficeMaster Gate as a virtual or physical SBC

“OfficeMaster Gate (Virtual Edition)” is qualified as a session border controller for Lync 2013. It can be deployed as a virtual machine on Windows Hyper-V hosts or VMware vSphere platforms. For evaluation or training purposes it even may be run on desktop virtualization solutions.

Instead of running it in a virtual machine, the same software can also be installed directly on physical server hardware from Fujitsu Technology Solutions or other vendors (a list of supported hardware can be obtained from Ferrari electronic AG). This kind of deployment is useful when higher scalability is required which not always can be guaranteed in virtual deployments.

(7)

2 Quick Start

2.1 Preparing OfficeMaster Gate as an SBC

OfficeMaster Gate products need a SIP2SIP license to be used as an E-SBC. Depending on the hardware platform there may not be a second network interface available – in that case only addresses in the same subnet can be used for SIP trunks and Lync connectivity. In virtual deployments a second network adapter can be easily configured and used if necessary. The following instructions apply to all kinds of OfficeMaster Gate products which are intended to work as an SBC via the SIP2SIP option.

To create a new virtual (or physical) OfficeMaster Gate SBC an ISO boot image can be downloaded to deploy the product. In addition the configuration tool and a Syslog service should be downloaded from the “Ferrari electronic Download Center”…

http://www.ferrari-electronic.de/en/service/download-center.html?tx_magdownloadcenter_pi1%5Bpath%5D=fileadmin%2Fdownload_center%2 FOfficeMasterHardware

…and installed locally. The Syslog service should be run on a system which is available all the time to record logs from the gateway. This is a rotating log which can be configured to use a maximum number of log files and a maximum size of each file to avoid filling up disk space. The configuration tool can be installed on any Windows PC in the local network. Via “Help” the UI language of the configuration tool can be switched between German and English.

Download and installation instructions for the SBC OS are available in a separate

(8)

“Gateway/mixed”:

Also “Configuration Mode” should be set to “Advanced”:

For troubleshooting purpose syslog settings should point to the address where the syslog service is installed. This is done via Edit  Logging:

(9)

2.2 Configuring external network for SIP trunks

The SIP trunk side is normally using a separate public or private address or subnet (See Using SIP trunks with registration from internal network for an alternate method of

connecting to SIP trunks). The example in this document is based on the following sample environment:

Local network (Interface 1 – eth0) where Lync server and clients are located  SBC internal IP Address 192.168.2.44

 Subnet Mask 255.255.255.0  Default Gateway 192.168.2.2  DNS Server 192.168.2.41

 SBC listens on 5060 for UDP/TCP (and on 5061 for TLS)

 Lync Collocated Mediation Server FQDN “se.rtm.lan”, TCP, Port 5068

External network (Interface 2 – eth1) where SIP trunk is located  SBC external IP Address 192.168.1.56

 Subnet Mask 255.255.255.0

 SIP Trunk IP Address 192.168.1.55

Network interface 1 will be configured for the local network. This is done by clicking

(10)

Note: DNS server and Default gateway settings are global and cannot be configured twice.

2.3 Using SIP trunks with registration from internal network

Some SIP providers work without authorization via a public IP address. Instead they can be reached from inside the local network and require the use of registration and digest authorization. Through the use of symmetric UDP (sending UDP packets from a source port which is also the destination port for the reverse direction) and sending REGISTER requests in short intervals most firewalls with allow bidirectional traffic for SIP via UDP and RTP.

(11)

2.4 The SIP2SIP Concept

The SIP2SIP feature is an option for all OfficeMaster Gate products. Essentially it is a SIP “Back to Back User Agent” (B2BUA) based on a simple but very powerful technology: Inside the system there is a virtual PSTN with SIP  PSTN call legs on both sides.

The virtual PSTN is visible as two interfaces PCM1 and PCM2 which are internally

interconnected. SIP calls are handled through a rule set at “Calls to ISDN” on one side and immediately appear as incoming calls on the other side (“Calls from ISDN”) where they can be directed to a SIP destination using another set of rules.

This concept has several advantages over traditional IP to IP translation:

 Security: Each side has its own SIP call leg and there is no IP communication between them

 The same configuration steps and troubleshooting tools already known for SIP to PSTN connections are used - existing know-how from traditional PSTN gateway deployments can be utilized

 Other types of destination can be reached depending on phone numbers or extensions (analog ports, fax servers, ISDN ports etc.)

2.5 Configuring calls from SIP trunk to Lync

Handling inbound calls is done with two call processing rules: on one side the call is sent to the virtual PSTN via “Calls to ISDN”, on the other side of the virtual PSTN the same call is received from the virtual PSTN and forwarded to the desired Lync destination.

In this document we associate Lync with the left side (PCM1) and the SIP trunk with the right side (PCM2). To accept INVITES from the SIP trunk we need to select “PCM2” and “Calls to ISDN” to create a rule via clicking “Add”:

OfficeMaster Gate SBC

Virtual PSTN

PCM1 PCM2

Calls to ISDN

Calls to ISDN Calls from ISDN

(12)

This rule takes all calls from any SIP source which start with a digit in the destination number. This separates SIP trunk calls from Lync calls since numbers from Lync should start with a “+” sign. Another way to distinguish between these sources is to enter a source “IP Address” as an additional condition. In that case the regular expression “(.*)” would be sufficient for the “Called Party Number” selection.

In this example called numbers are signaled as national numbers starting with “0”, followed by area code and remaining digits, e.g. “030987654” where “030” is Berlin and “987654” is the subscriber number.

(13)

This rule takes everything but the leading “0” and prefixes it with +49 to create a full E.164 destination number. The call is sent to “se.rtm.lan” via TCP and port 5068.

Not shown here are translation rules to change calling numbers to E.164. These are rules of type “Replacement” and they must appear before the final routing rule (all rules are evaluated top down). After these rules are added the list of rules is:

Caller numbers starting with “00” (international numbers) are changed by replacing “00” with “+” and national numbers are changed by replacing “0” with “+49” therefore getting E.164 representation for all caller numbers. To verify correct operation of the rules created clicking on “Test” opens a window where the processing of sample numbers can be tested.

2.6 Configuring calls from Lync to SIP trunk

(14)

(15)

We also would need to convert caller numbers from E.164 to the format expected by the SIP trunk, e.g.:

With this basic configuration all inbound and outbound calls should work. Additional rules could be added for different purposes:

 Handling inbound calls to fax machines via SIP ATA  Transferring calls to a local fax server

 Changing outbound calling numbers for some callers to hide their DID extension  Forwarding some inbound numbers to a test lab

Also it is possible to add failover routes for inbound calls to reach more than one mediation server (or by using DNS load balancing):

(16)

3 Troubleshooting and monitoring

This chapter gives a short overview on tools available to monitor the SBC and troubleshoot in case of problems. This is documented in details in the separate hardware manual.

3.1 Using OfficeMaster Syslog service and “Syslog Analyzer” tool

The gateway/SBC sends important logging information to the syslog server where it is recorded in the configured directory (default: “c:\ProgramData\FFUMS\omgatecfg\syslogs”:

The file ending with “-1.olg” is the file currently being written. Double clicking a log file opens “Syslog Analyzer” (syslogwin.exe) which can be used to watch what’s going on and to filter information using either predefined sets…

…or by entering individual words, strings or regular expressions.

3.2 Monitoring via Web-Interface

(17)

4 Advanced Settings and Usages

Additional settings are out of scope for this quick start manual, e.g. NTP settings, Firewall, configuration of analog devices/ATA, connection to fax servers etc.