Technical Information Bulletin MC550 / NEC BX SBC Integration interop...MC550 / NEC BX SBC Integration - DRAFT Technical Information Bulletin. Step 4: Media Realms. Media Realms define

NEC Australia au.nec.com

NEC Technical Assistance Centre

Technical Information Bulletin

MC550 / NEC BX SBC Integration

Document ID: TIB-MC550 / NEC BX SBC Integration-0.1 NEC Australia Pty. Ltd. © 2015 2

Technical Information Bulletin MC550 / NEC BX SBC Integration - DRAFT

1 Revision history

Version

number Revision date Summary of changes Author

0.1 3 May 2016 Draft version James Cussen



2 Overview

Title Technical Information Bulletin

Product Category Unified Communications

Product MC550 / NEC BX SBC Integration

System Type / Application SV9500

Software Version Version 2.0

Distribution ☐ Internal Only ☐ External or General Release

General Information

Other supporting documentation

BX Session Border Controller (SBC) Installation Guide

BX Session Border Controller (SBC) User Guide

UC for Enterprise (UCE) Mobility (Univerge MC550) Installation Guide



Table of contents

1 Revision history ................................................................................................................................... 2

2 Overview ............................................................................................................................................. 3

3 Introduction .......................................................................................................................................... 5

4 Architecture Diagram ........................................................................................................................... 5

5 Software Version Tested ...................................................................................................................... 6

6 Service Conditions ............................................................................................................................... 6

7 Requirements ...................................................................................................................................... 7

8 BX Configuration................................................................................................................................ 10

8.1 Initial Installation ....................................................................................................................... 10

8.2 SBC Basic Configuration .......................................................................................................... 10

8.3 SBC Advanced Security Configuration ..................................................................................... 31

9 SV9500 / MC550 / UCE Configuration ............................................................................................... 41

9.1 SV9500 Configuration .............................................................................................................. 41

9.2 UCE Configuration .................................................................................................................... 49

9.3 Troubleshooting and Maintenance ............................................................................................ 54

Appendix 1 – Configuring CA Certificates for HTTPS ............................................................................... 61

Appendix 2 – Configuring SNTP Time Synchronisation ............................................................................ 68



3 Introduction

NEC’s BX SBC platform supports various integration scenarios between different types of SIP environments. One of the supported integration scenarios is connecting end user SIP devices from an external network into a corporate PBX environment. This integration method can be leveraged to allow NEC’s MC550 Standard SIP phone to connect into the network from an external location. This allows for remote workers to make and receive voice calls on their MC550 via a 3G/4G mobile data network. This document details the configuration of the NEC BX series SBC for allowing this scenario.

4 Architecture Diagram

The diagram below shows how an external MC550 client uses both the UCE and NEC BX SBC in the DMZ to connect into the system from the internet. This document is covering the configuration of the NEC BX9000 SBC component of the architecture and MC550 specific configuration. For complete information on configuring the UCE 2015 components, please refer to the UCE documentation.



5 Software Versions Tested

5.1.1.1 SBC

BX9000 Virtual Edition - 7.00A.063.003

5.1.1.2 SV9500

Virtual SV9500 Version:

+-------------+---------+-------+------------+

| Type | Version | Issue | Date |

+-------------+---------+-------+------------+

| MAIN | V02 | 02.08 | 08/18/2015 |

| MISCLIBS | V02 | 01.00 | 01/21/2015 |

| MPH | V02 | 01.00 | 02/23/2015 |

| PHD | V02 | 01.00 | 02/23/2015 |

| PHI | V02 | 01.00 | 02/23/2015 |

| B2BUA_MAIN | V02 | 01.00 | 02/23/2015 |

| SP_BOOT | V02 | 01.00 | 02/23/2015 |

| SIPSV_PHE | V02 | 01.00 | 02/23/2015 |

| SIPSV_SIP | V02 | 01.00 | 02/23/2015 |

| LIBCMN | V02 | 01.00 | 02/23/2015 |

| LIBFSMTL | V02 | 01.00 | 02/23/2015 |

| LIBOSIP | V02 | 01.00 | 02/23/2015 |

| SVSYSSUB | V02 | 01.00 | 10/09/2014 |

| 95SYS_SB_AU | V02 | 01.00 | 03/05/2015 |

| BASE_SYS | V02 | 01.01 | 06/25/2015 |

+-------------+---------+-------+------------+

5.1.1.3 UCE

Version: UCE 2015

Build: 14.0.353

Date: 9-29-2015

5.1.1.4 MC550

Version 2.1.2 (r1577) – Build 194

6 Service Conditions

The following conditions apply:

DTMF is not supported between MC550 and Standard SIP terminals. The MC550 sends DTMF via the UCE OAI connection (ie. MC550 does not use inband or RFC2833 DTMF).

There is no handover available between WiFi and Mobile Data networks when a user is on a MC550 call. If the MC550 mobile phone changes data bearer (WiFi -> Mobile Data or Mobile Data -> WiFi) during the call then the call will immediately be terminated by the MC550. The MC550 will then try and register with the SV9500 from its new IP Address. The SV9500 will reject this first registration with a 403 Forbidden message and will continue to do so until the far-end has hung up the original call. The MC550 will not be able to make a call again until it has registered successfully, which requires that the far-end has hung up original call. After receiving the initial 403 Forbidden the MC550 will wait 5 minutes before trying to register again. The user can manually intervene to force this re-registration by closing and opening (ie. exiting to the home screen and tapping the MC550 app again) the MC550 application which will cause it to register again.



7 Requirements

Server Requirements

The BX9000 SBC software can be installed in two configurations:

Low-capacity SBC: using 1-4 vCPU and 4-8 GB RAM. When using more than 1 vCPU, the remaining vCPUs are used for transcoding functionality. The combinations allowed:

• 1 vCPU without transcoding capabilities, 4-GB RAM • 2 vCPU with transcoding capabilities, 8-GB RAM • 4 vCPU with transcoding capabilities, 8-GB RAM

High-capacity SBC:

• VMware ESXi: 4 vCPUs and 8-GB RAM

Virtual Machine Specifications Resource

Specifications

Virtual CPU Low-capacity SBC: 1-4 vCPU (250 Sessions)

High-capacity SBC: 4 vCPUs (6000 Sessions)

Each vCPU must correspond to a physical CPU core fully reserved for the SBC VM.

Memory Low-capacity SBC: 4-8 GB

High-capacity SBC: 8-16 GB

Disk space At least 10 GB

Virtual Network Interfaces Two vNICs are recommended (for trusted / untrusted traffic), an additional vNIC is recommended for HA configurations

For details of configuration and requirements specific to each virtualisation platform please refer to the BX9000 Virtual Edition SBC Installation Manual.

Port Requirements

The MC550 backend server infrastructure requires the following ports to be open:

Source Service Source Port Destination

Service

Destination

Port

Protocol Comments

MC550 Server 1024-65535 PBX 60030 TCP Call Control

MC550 Web Site 1024-65535 MC550 Server 60052 TCP Call Control Requests

MC550 Web Site 1024-65535 MC550 Server 60053 TCP Presence Pushes

MC550 Server 1024-65535 SQL Server 1433 TCP and

UDP

SQL Discovery Port



MC550 Server 1024-65535 SQL Server 1434 TCP and

UDP

See Note

MC550 Server 1024-65535 OW5000 Platform 5690 TCP

MC550 Web Site 1024-65535 SQL Server 1433 TCP and

UDP

SQL Discovery Port

MC550 Web Site 1024-65535 SQL Server 1434 TCP and

UDP

See Note

MC550 Web Site 1024-65535 OW5000 Platform 5690 TCP

MC550 Web Site 1024-65535 NEC VM

Presence Service

8002 TCP Play/Download Voice

Mail

Client Device 1024-65535 MC550 Web Site 80 TCP

Telnet Client 1024-65535 MC550 Server 49232-49234 TCP Only for remote log

viewing

Note: If the SQL server is configured to use a named instance rather than the default instance then it will have a dynamic port assigned instead of 1434. The dynamic port can be found in SQL Server Configuration Manager > SQL Server Network Configuration > Protocols for <Named Instance> > TCP/IP > IP Address [Tab] > TCP Dynamic Ports

The MC550 client requires the following ports to be open:

Source Service Source

Port

Destination Service Destination

Port

Protocol Comments

MC550 Client 1024-65535 MC550 Web Site 443 TCP Web Services Connection

MC550 Client 1024-65535 NEC XMPP Server 5222 TCP MC550 Client IM

MC550 Client 1024-65535 BX SBC Internal /

External

5060 UDP SIP Traffic

MC550 Client 1024-65535 BX SBC External

Interface

<Media Realm

Range>

UDP RTP Traffic. Configured in SBC

Media Realm

All NEC Voice

Equipment

1024-65535 BX SBC Internal

Interface

<Media Realm

Range>


Media Realm

MC550 Server 1024-65535 NEC PushProxy

Server

(located on Internet)

443 TCP iPhone Push Notifications. It is

also used for Call Control

notifications from MC550

server.

MC550 Server 1024-65535 NEC XMPP server 5222 TCP PBX Call notifications for

MC550 iPhone and Android

clients



The SBC requires the following Internal / External firewall ports to be opened for an MC550 deployment:

Source Service Source Port Destination

Service

Destination

Port

Protocol Comment

Internal Web

Browser

1024-65535 SBC Web Interface 80/443 TCP Web Interface Connection

MC550 Client 1024-65535 BX SBC Internal /

External


SBC 5060 SV9500 – SIP

Handler IP Address


MC550 Client 1024-65535 BX SBC External

Interface

<Media

Realm

Range>


Media Realm

SBC Internal

Interface

<Media Realm

Range>

Internal Voice

Equipment

1024-65535 UDP RTP Traffic. Configured in SBC

Media Realm

All NEC Voice

Equipment

1024-65535 BX SBC Internal

Interface

<Media

Realm

Range>


Media Realm

SBC External

Interface

<Media Realm

Range>

External MC550

Clients

1024-65535 UDP RTP Traffic. Configured in SBC

Media Realm

Internal/External

SBC Interface

1024-65535 SNTP Server 514 UDP Simple Network Time Protocol

Internal SBC

Interface

1024-65535 Syslog Server 123 UDP Syslog – Open for debugging

purposes

SSH Client 1024-65535 Internal SBC

Interface

22 TCP The SSH connection give

remote user access to the

command line interface

Multiple Interface Rules

BX SBC Interface table configuration must adhere to the following rules:

Multiple Control and Media interfaces can be configured with overlapping IP addresses and subnets.

The prefix length must have a value of 0-30 for IPv4 addresses and a value of 0-64 for IPv6 addresses.

One OAMP interface must be configured and this must be an IPv4 address. This OAMP interface can be combined with Media and Control.

At least one Control interface must be configured.

At least one Media interface must be configured.

Multiple Media and/or Control interfaces can be configured with an IPv6 address.

The network interface types can be combined.

Each network interface can be configured with a Default Gateway. The address of the Default Gateway must be in the same subnet as the associated interface. Additional static routing rules can be configured in the Static Route table.

The interface name must be configured (mandatory) and must be unique for each interface.

For IPv4 addresses, the 'Interface Mode' column must be set to IPv4 Manual. For IPv6 addresses, this column must be set to IPv6 Manual or IPv6 Manual Prefix.



8 BX Configuration

8.1 Initial Installation

The initial installation procedure for the BX will depend on the BX type being used. Please refer to the Installation Guide appropriate to the device being used. For the BX9000 Virtual SBC follow the appropriate installation for your chosen virtualisation platform and then follow the “Reconfiguring Default IP Address to Match Network Settings” to put IP Addressing into the SBC. After this the SBC should be accessible via the web interface for the rest of the configuration (Access to TCP port 80 or 443 on the SBC will need to be accessible to get to the Web Interface).

8.2 SBC Basic Configuration

Basic Configuration Flow Diagram

The diagram below is a visual representation of the configuration of the BX SBC:

IP Group

(Step 8) • Proxy Sets

(Step 6)

IP Profile (Step 7)

Ethernet Group (Step 1)

Ethernet Device (Step 2)

IP Interface (Step 3)

Media Realm (Step 4)

Classification (Step 9)

Internal External

SIP Interface (Step 5)

IP to IP Routing Table

(Step 10)

IP Address

Application Type Default Gateway / DNS

Port range

TCP/UDP/TLS port Application Type SIP Security

User-Agent Pass-through

SIP Server IP address

By IP address / SIP Interface

IP Group

(Step 8)

Ethernet Device (Step 2)

IP Interface (Step 3)

Media Realm (Step 4)

Virtual BX SBC Ethernet Group (Step 1)

SIP Interface (Step 5)



When configuring the SBC via the web interface, ensure that the Advanced radio button is selected. This ensures that all configuration sections are visible in the configuration menu. Some settings will not be visible in Basic mode.

SBC Basic Configuration

In this example configuration the following configuration will be implemented. In this example ports 40000-45000 have been selected for media sessions. The media port range can be selected as required. The BX SBC requires 5 ports per session, for example, the 40000-45000 allows for 1000 sessions.

Note: Whilst it is not mandatory for this configuration, it can be useful to configure the BX SBC to sync it’s time and date settings off a SNTP server. See appendix 2 for details of this configuration.

Step 1: Ethernet Groups

The example implements physical Ethernet port separation between the Internal and External networks. Therefore, you first need to assign your ports to groups (called Ethernet Groups).

Internal: Ethernet GROUP_1 with ports GE_1

External: Ethernet GROUP_2 with ports GE_2

To assign ports to Ethernet Groups:

1. Open the Ethernet Group Settings table (Configuration tab > VoIP menu > Network > Ethernet Groups Table).

2. Assign the ports to Ethernet Groups:



Step 2: Assign VLAN IDs to Ethernet Groups

The example employs a regular switch (not a VLAN-aware switch) connected to the SBC, and therefore, to separate Internal and External traffic in the SBC, you need to first assign untagged VLANs to your ports (Ethernet Groups):

Internal: VLAN ID 1 (Untagged) assigned to Ethernet GROUP_1

External: VLAN ID 2 (Untagged) assigned to Ethernet GROUP_2

Note: These VLAN IDs are configured as Untagged. So do not confuse the VLAN ID number with the Tagged VLAN number.

To assign VLANs to Ethernet Groups:

1. Open the Ethernet Device table (Configuration tab > VoIP menu > Network > Ethernet Device Table).

2. Assign the VLANs to the Ethernet Groups (InternalDEV and ExternalDEV):

Step 3: Add Logical IP Network Interfaces for Internal and External

In the example, you need to add two logical IP network interfaces:

Internal: IP address 10.20.1.165

External: IP address 10.20.2.166

The example assumes that the OAMP network interface is also used for the Internal interface, which is already set up. It is recommended to always have the OAMP address only on the internal interface and never on the external interface for security reasons.



In addition, to applying your physical, Ethernet port separation between Internal and External traffic (configured previously), you need to assign the VLANs (Underlying Device) that you configured in Step 2, to the network

interfaces, where:

VLAN 1 (Device InternalDEV) is assigned to the Internal interface

VLAN 2 (Device ExternalDEV) is assigned to the External interface

To add the logical IP network interfaces:

1. Open the Interface table (Configuration tab > VoIP menu > Network > IP Interfaces Table).

2. Configure Internal and External interfaces with Application Types (Internal: “OAMP + Media + Control”, External:

“Media + Control”), IP Addresses and Default Gateway Addresses:

Note: If DNS names are used to represent the SV9500 (in Step 6) then DNS server(s) IP Address should also be allocated per interface. A DNS server can be configured per interface and proxy set names will be resolved using the DNS server associated with the IP Interface/IP Group of the outbound traffic. If the nslookup command is used within the SBC to check DNS names, the OAMP interfaces DNS server will be used to resolve the name.

Application Type can be defined as follows:

Control: Call control signaling traffic (ie. SIP traffic)

Media: RTP traffic

Operations, Administration, Maintenance and Provisioning (OAMP): Management (ie. Web, CLI, and SNMP based management)

Maintenance: This interface is used in HA mode when two devices are deployed for redundancy, and represents one of the LAN interfaces or Ethernet groups on each device used for the Ethernet connectivity between the two devices.

Note: Each network interface can be configured with a Default Gateway. The address of the Default Gateway must be in the same subnet as the associated interface.

Below is a diagram for the settings above:

Note: If multiple gateways are required per interface then additional Static Routes can be entered in the Static Route table.



Step 4: Media Realms

Media Realms define a port range for media (RTP) traffic on a specified network interface. Therefore, you need to configure Media Realms for the Internal (SV9500) and External (MC550 users) interfaces. You will later apply the

Media Realms to your VoIP network by assigning them to SIP Interfaces.

To add Media Realms:

1. Open the Media Realm table (Configuration tab > VoIP menu > VoIP Network > Media Realm Table).

2. Add a Media Realm for the LAN interface. You can use the default Media Realm (Index 0), but modify it as shown

below. Media Realm for the Internal interface:

3. Add a Media Realm for the External interface:

Start of port range

Number of Sessions supported through the

SBC.

Realm Name

Select External Interface

None: The End port will auto-fill with:

Start Range + (5 x Number of Sessions)

Start of port range

Number of Sessions supported through the

SBC.

Realm Name

Select External Interface

None: The End port will auto-fill with:

Start Range + (5 x Number of Sessions)



The end result should look like this:

Step 5: Add SIP Interfaces for Internal and External

The SIP Interface defines the listening port for SIP signaling traffic on a specific network interface. The SIP Interface also determines the port and network interface for media (Media Realm, configured in Step 4). Therefore, you need to add a SIP Interface for the Internal and External interfaces.

To add SIP Interfaces:

1. Open the SIP Interface table (Configuration tab > VoIP menu > VoIP Network > SIP Interface Table).

2. Add a SIP Interface for the Internal interface. You can use the default SIP Interface (Index 0), but modify it as

shown below:

Make TCP/TLS ports 0. This will close them and

reduce open ports.



3. Add a SIP Interface for the External interface:

The end result should look like this:

Step 6: Add Proxy Sets for IP PBX and SIP Trunk

The Proxy Set defines the actual address of SIP server entities in your network. Therefore, you need to add a Proxy Set for the following entities:

Internal: SV9500 with address 192.168.169.32 (Assign the SV9500 Internal SIP Handler IP Address [LAN1 ACT2] here)

You will later apply the Proxy Sets to your VoIP network by assigning them to IP Groups, which represent these entities.

To add Proxy Sets:

1. Open the Proxy Sets table (Configuration tab > VoIP menu > VoIP Network > Proxy Sets Table).

See Advanced Security section for more details

on these settings

Make TCP/TLS ports 0. This will close them and

reduce open ports.



2. Add a Proxy Set for the Internal SIP Interface. You can use the default Proxy Set (Index 0), but modify it as shown below:

a. Add the Proxy Set:

b. Select the table row of the Proxy Set that you added, and then click the Proxy Address Table link located below

the table.

c. Add the IP address of the SV9500:

Note: If the system uses a non-default SIP port (ie. not 5060) then you need to specify the port after the IP Address in the Proxy Address (eg. 192.168.169.32:5070)



Step 7: Configure IP Profiles

Allow User-Agent field Pass-through in SIP messages from the MC550 to the SV9500. This is done by configuring an IP Profile for the Internal IP Group.

1. Open the IP Profile settings page (Configuration tab > VoIP menu > Coders and Profiles > IP Profile Settings).

2. Select Add button to create a new IP Profile. 3. Give the IP Profile a Name and set Keep User-Agent Header -> Enabled.

Step 8: Add IP Groups for SV9500, and External MC550 Users

IP Groups define what type of device is connecting to the SBC. This can be a Server (eg. a PBX) or User (eg. individual phone devices such as the MC550).

Configuration

The IP Group represents the SIP entity. In the example, you need to add an IP Group for the following entities:

SV9500 PBX (server-type IP Group)

MC550 users (user-type IP Group)

For the server-type IP Groups, you need to assign their respective Proxy Sets, which define their addresses. You also need to enable the SBC to classify incoming calls to the IP Groups, based on their source IP address (i.e., Proxy Set).

For the External users, a Proxy Set is not used and thus, classification by Proxy Set needs to be disabled.

To add IP Groups:

1. Open the IP Group table (Configuration tab > VoIP menu > VoIP Network > IP Group Table).

2. Add an IP Group for the SV9500:



3. Add an IP Group for the MC550s (No Proxy Set is configured):

Type Setting Details:

User Type - Represents a group of users such as IP phones and softphones where their location is dynamically obtained by the device when REGISTER requests are sent through the SBC.



Typically, this IP Group is configured with a Serving IP Group that represents an IP-PBX, Application or Proxy server that serves this User-type IP Group. Each SIP request sent by a user of this IP Group is proxied to the Serving IP Group. For registrations, the device updates its registration database with the Address of Record (AOR) and contacts of the users.

To route a call to a registered user, a rule must be configured in the SBC IP-to-IP Routing table. The device searches the dynamic database (by using the Request-URI) for an entry that matches a registered AOR or Contact. Once an entry is found, the IP destination is obtained from this entry and a SIP request is sent to the destination.

Step 9: Add Classification for MC550 Users

For the SBC to identify calls from MC550 users (ie. Users connecting through an IP Group with User type) and classify them to their IP Group, a classification rule must be added. Remember that for the SV9500, a Proxy Set was used (which basically means that the SV9500 is classified by the IP Address specified in the Proxy Set and doesn’t require any additional classification rules).

In the example, calls received on the External SIP interface, will be identified as MC550 users and assigned to IP Group "IPGroupExternalUsers".

To add a classification rule for MC550 users:

1. Open the Classification table (Configuration tab > VoIP menu > SBC > Routing SBC > Classification Table).

2. Add a Classification rule:

Source Username Prefix – This setting should be set include all the phone numbers of the external MC550 clients. The simplest way to achieve this is using the “x” and “#” symbols in indicate number of digits in the phone numbers of the MC550. For example: for a range of numbers between 1100-1199 you could use “11xx#” as the Source Username Prefix. Below is a table explaining in more detail the notions available:

See below for

details

See Advanced Security Section: Allow Calls Only with Specific SIP User-Agent Header Value



Notation Description

x (letter "x") Wildcard that denotes any single digit or character.

# (pound symbol) When used at the end of a prefix, it denotes the end of a number. For

example, 54324# represents a 5-digit number that starts with the digits

54324.

When used anywhere else in the number (not at the end), it is part of the

number (pound key). For example, 3#45 represents the prefix number 3#45.

To denote the pound key when it appears at the end of the number, the

pound key must be enclosed in square brackets. For example, 134[#]

represents any number that starts with 134#.

[n-m] or (n-m) Represents a range of numbers.

Examples:

To depict prefix numbers from 5551200 to 5551300:

[5551200-5551300]#

To depict prefix numbers from 123100 to 123200:

123[100-200]#

To depict prefix and suffix numbers together:

03(100): for any number that starts with 03 and ends with 100.

[100-199](100,101,105): for a number that starts with 100 to 199 and

ends with 100, 101 or 105.

03(abc): for any number that starts with 03 and ends with abc.

03(5xx): for any number that starts with 03 and ends with 5xx.

03(400,401,405): for any number that starts with 03 and ends with 400

or 401 or 405.

Notes:

The value n must be less than the value m.

Only numerical ranges are supported (not alphabetical letters).

For suffix ranges, the starting (n) and ending (m) numbers in the range

must include the same number of digits. For example, (23-34) is

correct, but (3-12) is not.

[n,m,...] or (n,m,...)

Represents multiple numbers. The value can include digits or characters.

Examples:

To depict a one-digit number starting with 2, 3, 4, 5, or 6: [2,3,4,5,6]

To depict a one-digit number ending with 7, 8, or 9: (7,8,9)

Prefix with Suffix: [2,3,4,5,6](7,8,9) - prefix is denoted in square brackets;

suffix in parenthesis

For prefix only, the notations d[n,m]e and d[n-m]e can also be used:

To depict a five-digit number that starts with 11, 22, or 33:

[11,22,33]xxx#

To depict a six-digit number that starts with 111 or 222: [111,222]xxx#

Message Condition - This setting allows for the policing of fields in the inbound REGISTER messages sent from external devices. In this case we have configured a special User-Agent condition for the MC550 phones. Refer to the



Advanced Security section (Allow Calls Only with Specific SIP User-Agent Header Value) for more detail about this configuration.

Step 10: Add IP-to-IP Call Routing Rules

For call routing between the SIP entities, you need to add IP-to-IP routing rules for the following call directions:

Calls from the SV9500 to the MC550 Users.

Calls from the MC550 users to the SV9500.

The call routing rules use the IP Groups of these entities to denote the source and destination of the call.

To add IP-to-IP call routing rules:

1. Open the IP-to-IP Routing table (Configuration tab > VoIP menu > SBC > Routing SBC > IP-to-IP Routing Table).

Note: This example has the most basic routing rules that can be implemented. It allows all calls with any source and destination phone number to be sent directly in both directions. If the SBC has multiple PBXs or various groups of external Users that need their signalling routed to different locations then more complex rules will need to be defined in this step. The Source and Destination Username Prefix settings can be used to route based on source or destination number. The format of these fields follows the notation rules documented in Step 9 (eg. setting Source Username Prefix as 1xxx# will only allow SIP INVITEs from endpoints in the 1000-1999 range to be sent through the SBC).

Add a rule to route calls from MC550 users to the SV9500:



Add a rule to route calls from the SV9500 to the MC550 users:

Once you have configured the IP-to-IP routing rules, the IP-to-IP Routing table should appear populated as shown below:

IP Group. When the 'Destination Type' parameter is configured to IP Group, the outbound SIP Interface is

determined as follows:

Server-type IP Groups: SIP Interface that is assigned to the Proxy Set associated with the IP Group.

User-type IP Groups: The Address of Record of each User will be assigned to the IP Group with a matching classification rule at the time of registration.

Step 11: Write Configuration from RAM to Disk

The BX SBCs will save all configuration changes to running memory (ie. RAM). In order for the configuration to survive a system reboot it needs to be written to disk. This is done by clicking the Burn button:



An additional dialog will be displayed to confirm the burn operation. Select OK:

Ensure that this process has been done after any configuration changes have been made, as data that has not been “Burnt” will be lost after a system reboot.

NAT Traversal Configuration

Far End NAT Detection (Required for MC550)

Far end NAT is when the MC550 device is connecting to the SBC through a NAT that has changed its source IP Address (ie. the MC550 has been source NATed so that the receiving device does not know the MC550’s true source IP Address). This most commonly happens if a user is connected through their home WiFi via an ISP. These type of connections are almost always NATed out to the public internet.

In scenarios where the remote user agent (ie. MC550) resides behind a NAT router, it’s possible that the SBC (if not specially configured for NAT traversal) will send the media (RTP and RTCP) streams to an invalid IP address / UDP port (ie. private IP address:port of MC550 and not the external NATed public address). When the MC550 is located behind a NAT, although the MC550 sends its private IP address:port in the original SIP message (INVITE), the device receives the subsequent media packets with a source address of a public IP address:port (ie. allocated by the NAT router). Therefore, to ensure that the media reaches the MC550, the device must send it to the public IP address.

In the diagram below the signalling and media from the MC550 cross a NAT before they make it onto the Internet. As a result, when the SIP packets make it to the BX SBC the Private IP Address will still appear in the Session Description Protocol portion of the SIP message. This will normally cause the SBC to send the media stream to the wrong IP Address and the media will not make it to the MC550.



Fortunately, the BX SBC has a special operating mode where it can ignore the incorrect Private IP Address presented in the SDP message (as depicted above) and instead respond directly to the source IP of the incoming packets. The SBC identifies whether the external user (ie. MC550) is located behind NAT, by comparing the source IP address of the first received media packet, with the IP address and UDP port of the first received SIP message (INVITE) when the SIP session was started. This is done for each media type (RTP, RTCP and T.38) and therefore, they can have different destination IP addresses and UDP ports than one another.

To configure Far-End NAT detection, configure the following:

1. Open the General Settings page (Configuration Tab > VoIP menu > Media > General Media Settings). 2. Set the 'NAT Mode' parameter (NATMode) to Auto-Detect:

This way NAT will only be performed if necessary. If the UA is identified as being located behind NAT, the device sends the media packets to the public IP address:port obtained from the source address of the first media packet received from the MC550. Otherwise, the packets are sent using the IP address:port obtained from the address in the first received SIP message. Note, if the SIP session is established (ACK) and the device (not the MC550) sends the first packet, it sends it to the address obtained from the SIP message and only after the device receives the first packet from the UA, does it determine whether the MC550 is behind NAT.

By default the SBC is configured to detect Far-End NATing via SIP message processing. Ensure that this setting remains enabled:

3. SIP NAT Detection - This setting enables the device to detect whether the incoming INVITE message is sent from an endpoint located behind NAT.

Configuration Tab > VoIP menu > SIP Definitions > Advanced Parameters > SIP NAT Detection = Enable (default)

Near End NAT Configuration (Only Configure if required)

Two different streams traverse through NAT - signaling and media. An SBC located behind a NAT by default will tell the external MC550 its private IP Address for media which will not be routable from the Internet. Therefore, the SBC must inform the MC550 to send the media to the public NAT address instead of its private address.



To resolve this NAT problem, the SBC can be told to put the external (post NATed) address in the SIP message so that the external user gets told the correct IP Address to send the media stream to.

Note: This method requires a 1-to-1 port forwarding on the external firewall for the media port range of the SBC. So the external port numbers always maps consistently to the same internal SBC port for media.

The NAT Translation table lets you configure up to 32 network address translation (NAT) rules for translating source IP address ranges per VoIP interface (SIP control and RTP media traffic) into NAT IP addresses (global - public), when the device is located behind NAT. The SBC’s NAT traversal mechanism replaces the source IP address of SIP messages sent from a specified VoIP interface to a public IP address. Each IP network interface, configured in the Interface table, can be associated with a NAT rule, translating the source IP address and port of the outgoing packet into the NAT address (IP address and port range).

The following procedure describes how to configure NAT translation rules through the Web interface.

To configure NAT translation rules:

1. Open the NAT Translation table (Configuration tab > VoIP menu > VoIP Network > NAT Translation Table).

2. Click Add; the following dialog box appears:

3. Configure a NAT translation rule according to the parameters described in the table below.

Note: You must configure port forwarding on the edge router to forward messages from the WAN to the SBC. Based on the example scenario, for SIP signaling you need to set the SIP Interface port to 5070.

Parameter Description

Index

Defines an index number for the new table row.

Note: Each row must be configured with a unique index.

Source Interface

Assigns an IP network interface to the rule. Outgoing packets sent from the specified

network interface are NAT'ed.

Target IP Address

Defines the global (public) IP address. The device adds the address to the SIP Via

header, Contact header, 'o=' SDP field, and 'c=' SDP field, in the outgoing packet.

Source Start Port

Defines the optional starting port range (1-65536) of the IP interface, used as

matching criteria for the NAT rule. If not configured, the match is done on the entire

port range. Only IP addresses and ports of matched source ports will be replaced.

Source End Port

Defines the optional ending port range (1-65536) of the IP interface, used as matching

criteria for the NAT rule. If not configured, the match is done on the entire port range.



Only IP addresses and ports of matched source ports

Target Start Port

Defines the optional starting port range (1-65536) of the global address. If not

configured, the ports are not replaced. Matching source ports are replaced with the

target ports. This address is set in the SIP Via and Contact headers, as well as in the

o= and c= SDP fields.

Target End Port

Defines the optional ending port range (1-65536) of the global address. If not

configured, the ports are not replaced. Matching source ports are replaced with the

target ports. This address is set in the SIP Via and Contact headers, as well as in the

o= and c= SDP fields.

Example:

In the following example the external Public IP Address is 147.76.52.45 and the range of media ports that have been forwarded on the external firewall are 40000-40010 (note, in practice a 10 port range will only support 2 sessions, so the media range is likely to be much larger than this in practice).

Codec Selection

The codecs used between devices can be limited using the SV9500 Location/Voice Control feature. This allows for flexible codec selection without requiring changes or codec list manipulation on the SBC. All the MC550 phones that are connecting from external will send media to the SV9500 from media addresses that appear to be the internal IP Address of the SBC. As a result, the SBC internal IP Address will be used in location data as the destination Location address for MC550s requiring specific codec selection. The diagram below shows how to configure Location settings in the SV9500:



ALOCL Configuration Example:

In this example Location 2 has been configured as being the internal interface IP Address of the BX SBC. Make sure that all internal subnets where terminals and PBX equipment reside are defined within ALOCL. In the example above the SV9500 is configured as Location 0 and terminal subnet is defined as Location 1.

Note: if the SV system has IP-PADs then they are defined by IP Address range 0.0.0.0.

AIVCL Configuration Example (Configuring G.729 for MC550):

In the example, calls between Location 1 and Location 2 are prioritised to support the G.729 codec first. To do this the AIVCL command is used and the setting of payload is configured to priorities G.729 as first priority and G.722/G.711 as lower priorities. It is important to still leave G.722/G.711 on the list as a fall back in case there are terminals somewhere on the network that do not support G.729.



Note: The codecs with Forward Error Correction (eg. G.711A-law (FEC) and G.711u-law (FEC)) codecs are not supported by MC550. If you select these codecs the call will fail to set up.

QoS Settings

The QoS Settings page (VoIP -> Network -> QoS Settings) lets you configure Layer-3 Quality of Service (QoS). Differentiated Services (DiffServ) is an architecture providing different types or levels of service for IP traffic. DiffServ (according to RFC 2474), prioritizes certain traffic types based on priority, accomplishing a higher-level QoS at the expense of other traffic types. By prioritizing packets, DiffServ routers can minimize transmission delays for time-sensitive packets such as VoIP packets.

In the BX SBC DiffServ is assigned by default in the following four categories:

VoIP > Network > QoS Settings



By default these categories map to the following applications:

Application Traffic / Network Types Class-of-Service (Priority)

Debugging interface Management Bronze

Telnet Management Bronze

DHCP Management Network

Web server (HTTP) Management Bronze

SNMP GET/SET Management Bronze

Web server (HTTPS) Management Bronze

RTP traffic Media Premium media

RTCP traffic Media Premium media

T.38 traffic Media Premium media

SIP Control Premium control

SIP over TLS (SIPS) Control Premium control

Syslog Management Bronze

SNMP Traps Management Bronze

In this case the RTP/RTCP and SIP traffic are the flows that we care about. By default, the RTP/RTCP traffic will get tagged as DSCP 46 (EF) and the SIP traffic will be tagged as DSCP 40. If these settings do not align with your customers QoS implementation then change these settings accordingly.



8.3 SBC Advanced Security Configuration

This section contains security related settings for hardening the SBC against potential external attacks. This is important because the external facing side of the SBC in a remote user scenario involves the external interface having open ports directly on the internet. The advanced techniques in this section cover administrator access, SIP message filtering, session management, and intrusion detection.

System Management Configuration

BX SBC Login / Password

Web user accounts define users for the Web interface and CLI. User accounts permit login access to these interfaces as well as different levels of read and write privileges. Thus, user accounts prevent unauthorized access to these interfaces, permitting access only to users with correct credentials (ie. username and password).

By default, the device is pre-configured with the following two Web user accounts:

Access Level Username (Case-

Sensitive)

Password (Case-Sensitive)

Security Administrator (Default)

Admin Admin

Monitor (Default) User User

Each user account is based on the following:

Username and password: Credentials that enable authorized login access to the Web interface.

User level (user type): Access privileges specifying what the user can view in the Web interface and its read/write privileges.

To configure new users or edit existing users open the following page:

Open the Web User Accounts page (Configuration tab > System menu > Web User Accounts).

The table below describes the different types of Web user account access levels:

User Level Numeric

Representatio

n in RADIUS

Privileges

Security

Administrator

200 Read / write privileges for all pages. It can create all user types and is

the only one that can create the first Master user.

Note: At least one Security Administrator user must exits.

Master 220 Read / write privileges for all pages. Can create all user types, including

additional Master users and Security Administrators. It can delete all

users except the last Security Administrator.

Administrator 100 Read / write privileges for all pages, except security-related pages

(read-only).

Monitor 50 No access to security-related and file-loading pages; read-only access



to all other pages.

No Access 0 No access to any page.

Note: This access level is not applicable when using advanced Web

user account configuration in the Web Users table.

Note: LDAP (eg. Active Directory) can also be used as the authenticating users. Refer to section “17.4.10 319BLDAP-

based Login Authentication Example” of the BX User’s Manual for details of this configuration.

Secure Web Interface Connection via HTTPS

The SBC can be locked down to only allow HTTPS connections by setting the following:

To configure secure Web access:

1. Open the Web Security Settings page (Configuration tab > System menu > Management > Web Security

Settings).

2. From the 'Secured Web Connection (HTTPS)' drop-down list, select HTTPS Only.

3. Click Submit, and then reset the device with a burn-to-flash for your settings to take effect.

Using a Certificate Authority for HTTPS

By default the SBC is configured to allow HTTP and HTTPS access via a web browser. Connections via HTTPS will connect via a Self-Signed certificate that ships in the SBC. Self-Signed certs will not automatically be trusted by your browser and as a result you will see a warning message when connecting via HTTPS.

Below is an example of the error received when connecting to the SBC via HTTPS with a Self-Signed certificate:

If you select “Continue to this website” you will be allowed access to the Web Interface, however the browser window will display a Certificate error in the address bar:



To remove this warning message (and to know you’re not connecting to a rouge third party) you need to use a certificate that is signed by a Certificate Authority (CA) that the client has a Trusted Root Certificate for. The CA can be either a private or public authority. Microsoft’s domain based private CA’s (common in enterprise) will automatically push their Root Certificates out to PCs when they are joined to the domain. However, if you are not joined to the domain, you will need to manually install the Root Certificate of the CA on your PC. If a public CA is used the Root Certificates should automatically be trusted because they are shipped within the PC operating system. See Appendix 1 - Configuring CA Certificates for HTTPS for details on how to generate Certificate Signing Requests (CSR), sign it with a Microsoft CA, and then import the signed certificate back into the SBC. This same methodology can be used with any CA, however, the signing steps will be different depending on the CA being used.

SIP Security Configuration

Allow Calls Only with Specific SIP User-Agent Header Value

The SIP User-Agent header contains information about the User Agent Client (UAC) initiating the SIP dialog request. This information is unique to the SIP Client and therefore, it is recommended to configure the SBC so that it only accepts registrations that have a specified User-Agent header value. This is configured by adding a Message Condition rule (in the Message Condition table) for this SIP header type and then assigning it to a Classification rule (in the Classification table).

The figure below shows a Message Condition rule in the Message Condition table:

Configuration tab > VoIP > SBC > Routing SBC > Message Condition Table

User Agent Field:

Condition: header.user-agent contains 'NEC MC550'

To apply the Message Condition rule, assign it to the Classification rule in the Classification table:

Configuration tab > VoIP > SBC > Routing SBC > Classification Table:



Note: The source Username Prefix can also be locked down to the MC550 phone number range (eg. 11xx#) as shown in this example to further limit external attackers from being able to brute force attack the SBC.

Classification Error Response Type This configuration setting is very important for preventing Denial of Service (DoS) and brute force attacks that are typically initiated from the internet. Malicious attackers frequently use SIP scanners to detect ports used by SIP devices. These scanners scan devices by sending UDP packets containing a SIP request to a range of specified IP addresses, listing those that return a valid SIP response. Once the scanner finds a device that supports SIP, it extracts information from the response and identifies the type of device (IP address and name) and can execute DoS or brute force attacks. A way to defend the device against such attacks is to not send SIP responses to these unclassified "call attempts" so that the attacker assumes that no device exists at such an IP address and port.

In the SIP interface configuration there is a setting called Classification Failure Response Type that defines the SIP response code that the device sends if a received SIP request (OPTIONS, REGISTER, or INVITE) fails the SBC Classification process. The valid value can be a SIP response code from 400 through 699, or it can be set to 0 to not send any response at all. The default response code is 500 (Server Internal Error).

Configuration tab > VoIP menu > VoIP Network > SIP Interface Table (External) > Classification Failure Response Type = 0

Note: The parameter is applicable only if the device is set to reject unclassified calls. This is configured using the 'Unclassified Calls' parameter on the General Settings page (Configuration tab > VoIP menu > SBC > General Settings).



Allow only calls from Registered Users

Ensure that calls from unregistered users are blocked (rejected) and that calls from only registered users are allowed. If a user that is not Registered tries to send an Invite through the SBC it will be rejected with a 403 forbidden message.

Configuration tab > VoIP menu > VoIP Network > SIP Interface Table > Block Unregistered Users = Yes

In normal operation scenarios in which a SIP proxy (registrar) server is available, the SBC forwards REGISTER requests from new users to the proxy, and if authenticated by the proxy (ie. SBC receives a success response) the SBC adds the user to its registration database. However, if the proxy becomes unavailable at any time (eg. due to network connectivity loss), the REGISTER requests cannot therefore be authenticated. In such scenarios, make sure that the SBC is configured to reject such unauthenticated REQUEST messages from new users. Note that the SBC does accept registration refreshes from users already in its database.

Configuration tab > VoIP menu > VoIP Network > SIP Interface Table > Enable Un-Authenticated Registrations = Disable

Limit SBC Registered Users Interface

It is recommended that you define a maximum number of allowed registered users per SIP Interface (on the External SIP Interface specifically). This ensures that only the expected number of users can register with the system. This can be configured in the SIP Interface table (also at the IP Group if required), by using the 'Max. Number of Registered Users' parameter.

The example below shows a maximum of 25 users being allowed to register per SIP Interface:

(Configuration tab > VoIP > VoIP Network > SIP Interface Table > Max. Number of Registered Users = <Value>

The SBC will respond with a 500 Internal Server Error SIP message in response to registrations if the maximum number of registrations has been reached.



Define Max Call Duration

It is recommended to define maximum call duration (in minutes) to prevent calls from utilizing valuable device resources that could otherwise be used for additional new calls. If a call exceeds this duration, the device terminates the call.

This is configured on the Advanced Parameters page

Configuration tab > VoIP > SIP Definitions > Advanced Parameters > Max Call Duration = <No of Minutes>

In this example, calls will only be allowed to run for 2 hours, after which they will be cut off. This should be configured to a call length that’s appropriate for the customer requirements.

Implement Dynamic Blacklisting of Malicious Activity (IDS)

The BX SBC’s Intrusion Detection System (IDS) feature is used to allow the device to detect malicious attacks targeted on the SBC (eg. DoS, SPAM, and Theft of Service). It is crucial to be aware of any attacks to ensure the legitimate call service is maintained at all times. If any user-defined attacks are identified, the device can do the following:

Block (blacklist) remote hosts (IP addresses / ports) considered as malicious. The device automatically blacklists the malicious source for a user-defined period after which it is removed from the blacklist.

Log and Send SNMP traps to notify of the malicious activity and/or whether an attacker has been added to or removed from the blacklist.

The IDS configuration is based on IDS Policies, where each policy can be configured with a set of IDS rules. Each rule defines a type of malicious attack to detect and the number of attacks (alarm threshold) during an interval (threshold window) before an SNMP trap is sent. Each policy is then applied to a target under attack (SIP Interface) and/or source of attack (Proxy Set and/or subnet address).

For configuring IDS, use the tables under the Intrusion Detection and Prevention menu (Configuration tab > VoIP menu > Security > Intrusion Detection and Prevention):

Global Parameters – enables IDS

Policy Table – defines IDS Policies and rules

Match Table – assigns the IDS Policies to targets under attack (SIP Interface) and/or source of attacks (Proxy Set and/or subnet address)

Thresholds

Defines the type of intrusion attack (malicious event).

Connection abuse

(Default) TLS authentication failure.

Malformed message

Message exceeds a user-defined maximum message length (50K)

Any SIP parser error

Message Policy match (see ''Configuring SIP Message Policy Rules'')

Basic headers not present



Content length header not present (for TCP)

Header overflow

Note: The MC550 will occasionally send a malformed (empty) SIP packet to the system. Which is an empty packet with just a carriage return and line feed in it on the SIP port. This is logged as a parser error in the SBC. So you need to ensure that you don’t put very strict limits on this setting. Error looks like this is log: “[ERROR] AcSIPParser [SIP Message Headers] Parse error: "Unexpected symbol '?'. Expected token"”

Authentication failure

Local authentication ("Bad digest" errors)

Remote authentication (SIP 401/407 is sent if original message includes authentication)

Dialog establish failure

Classification failure

Routing failure

Other local rejects (prior to SIP 180 response)

Remote rejects (prior to SIP 180 response)

Abnormal flow

Requests and responses without a matching transaction user (except ACK requests)

Requests and responses without a matching transaction (except ACK requests)

Setting Description

Threshold Scope Defines the source of the attacker to consider in the device's detection

count.

Global - All attacks regardless of source are counted together during

the threshold window.

IP - Attacks from each specific IP address are counted separately

during the threshold window.

IP+Port - Attacks from each specific IP address:port are counted

separately during the threshold window. This option is useful for NAT

servers, where numerous remote machines use the same IP address

but different ports. However, it is not recommended to use this option as

it may degrade detection capabilities.

Threshold Window Defines the threshold interval (in seconds) during which the device counts

the attacks to check if a threshold is crossed. The counter is automatically

reset at the end of the interval.

The valid range is 1 to 1,000,000. The default is 1.

Minor-Alarm

Threshold

Defines the threshold that if crossed a minor severity alarm is sent.

The valid range is 1 to 1,000,000. A value of 0 or -1 means not defined.

Major-Alarm

Threshold

Defines the threshold that if crossed a major severity alarm is sent.


Critical-Alarm

Threshold

Defines the threshold that if crossed a critical severity alarm is sent.


Deny Threshold Defines the threshold that if crossed, the device blocks (blacklists) the

remote host (attacker).

The default is -1 (ie, not configured).



Note: The parameter is applicable only if the 'Threshold Scope' parameter

is set to IP or IP+Port.

Deny Period Defines the duration (in sec) to keep the attacker on the blacklist.

The valid range is 0 to 1,000,000. The default is -1 (ie, not configured).

Example Configuration:

Open the IDS Match table (Configuration tab > VoIP menu > Security > Intrusion Detection and Prevention > Global Parameters).

Note: This setting requires a reset of the SBC. So it’s important that you do this during an agreed outage window.

Open the IDS Match table (Configuration tab > VoIP menu > Security > Intrusion Detection and Prevention > Policy Table).

Create a NEW policy table:

Add a new IDS Rule Table to the new Policy:

Add new Malformed Message Failure, Authentication Failure, Abnormal Flow and Dialog Establishment Failure

rules to the table with the following settings:



Note: These settings will allow for the gradual escalation of alarms logged by the system when malicious activity is detected. When the threshold hits a critical level then packets from the offending client will be blocked for 60 seconds. This allows for a non-destructive mechanism for limiting access to devices that are behaving incorrectly. If you do not want the SBC to blacklist clients you can set Deny Threshold and Deny Period settings to 0.

Open the IDS Match table (Configuration tab > VoIP menu > Security > Intrusion Detection and Prevention > Match Table). Add a new match entry and specify the SIP Interface number that is used for External User access:

Monitoring Intrusion Detection Threshold Breaches

The alarms output by IDS can be viewed within the Status & Diganostics > System Status > Carrier-Grade Alarms > Active Alarm / Alarm History section of the web interface. These alarms are displayed in a colour coded table as

shown below:



Hosts that are currently Blacklisted can be seen by running the following command in the CLI:

# show voip security ids blacklist active

Active blacklist entries:

10.33.5.110(NI:0) remaining 00h:00m:10s in blacklist

Note: You cannot see the Blacklist directly from the Web Interface so it is recommended to set the Critical Threshold to same setting as the Blacklist Threshold. That way when the Active Alarm list shows a Critical user in it you will know that the user is also blacklisted.



9 SV9500 / MC550 / UCE Configuration

The MC550 uses a combination of signalling protocols to allow it to make calls. These include a web services connection that it maintains with the UCE which it uses to make and receive call signalling, a XMPP server connection that it uses for text messaging, and a SIP connection that it uses for setting up and tearing down media connections. Whilst this document is focused on getting the SIP and media portions to work externally, the MC550 will not work without these other components. This section covers the important configuration components for making MC550 work via the SBC, for more information and advanced features (including Pickup Groups) refer to the UC for Enterprise Mobility (Univerge MC550) Installation Guide.

9.1 SV9500 Configuration

Configure SIP Handler

Ensure that the system has a Standard SIP Handler configured. The configuration for this feature can be found in the Business Feature manual S-167 SIP Handler - SIP Terminal.

Confirm if the Standard SIP Handler is configured and running with the DMOS command:



System Data

Configure the SV9500 system data to the following:

ASYD SYS 1

Index 47

Bit 4: 1 - Enable SCF Tone Control (Enable for MC550)

ASYDL SYS 1

Index 1382

Bit 0: 0 - Enable SIP Digest Authentication

Note: It is strongly recommended to set bit 0 = 0 to enable SIP digest Authentication.

Index 1188 - Calling party number selection function with SCF and extended function of SCF (FN=128)

Bit 0: 1 - Enable Advanced SCF128 for OAI (Enable for MC550) – Must be enabled or MC550 will not be able to

make call.

Bit 1: 1 - Enable SCF128 for OAI (Enable for MC550)

Index 1024

Bit 0: 1 - Send original Caller ID on Tandem Calls (Send Caller ID for MC550)

Index 869

Bit 0: 1 - Name data in SMFN enabled (Enable for MC550)

Index 803

Bit 1: 1 - Consultation Hold Release is in service

Index 1382

Bit 0: Receiving digits operation of the SIP Handler Controlled SIP terminal when a called station is busy (while

receiving a Busy Tone (BT) generated by IP-DTG).

0 = Step Call

1 = Going switch hook flash (Receiving a Special Dial Tone (SPDT))

Note: When Bit 0 = 1 (Out of Service) is selected, Pressing any digit key while hearing a Busy Tone (BT) enables operations of features in the Busy state.



ASLG - Specify the Tone Data used per system.

[FIRST] tab - Basic Data Setting

IP-DTG generates tones compliant with the Country Code assigned with the system data.

AUACN – SIP Registration Configuration

UA – “NEC MC550”

Note: The UA setting needs to match a portion of the User-Agent string from the register message of the MC550. This is the reason that the SBC was configured to pass through the User-Agent string from the MC550 using an Internal IP Profile.

Register Expires – 900 Name Display – 1 Tone [0] – FE Tone [1] – 7F

Example:



AOKC - Desk Phone OAI Key

Assign an OAI Key to use for the Move Call button for the user’s desk phone. An OAI key needs to be assigned for

the Desk Phone to use to move calls between the Desk Phone and the MC550.

Example:



This setting relates to the following UCE configuration. Under the Applications > MC550 Server menu:

AKYD – Desk Phone Key Assignment

Assign OAI key (Move Call button) to each MC550 user’s desk phone. The key number of the OAI key relates to the UCE LED Number setting shown above.

Example:

This is the OP-CODE assigned in AOKC

Set the LED Number that the MC550 Move function lights

when active on the Dterm. This data directly relates to the KEY-CODE assigned in the AOKC

command on the SV9500



Note: The OAI key assigned in this section is for the Desk Phone and not the MC550 number.

AMNO/L/N

TN: 1 AMNO: XXXX (must be a valid station level number defined in ANPD/L/N and ASPA/L/N) NMI: YYYY (a new unused NMI for this application. Use LMNO to verify that no duplications exist.) MFC: 0

Do not check the “Follow the UCD When Monitor Status is not requested from AP” check box.

Note: The MC550 must have at least one monitored number for operation.

Example:



This AMNO number needs to be configured in the UCE server under Systems > PBX > PBX Management > Reserved Numbers:

Note: The OW5000 will configure the phone number for each MC550 user to have a Call Forward All configured to point to the Mobile Client monitor number. This configuration is done automatically by the OW5000 and is required because the UCE controls all of the MC550’s operation via OAI. This is also why the new SIP handler must be used for MC550 numbers, because it supports OAI operations for Standard SIP devices.

Per MC550 Device Configuration SV9500

The MC550 uses the new Standard SIP Handler within the SV9500.

AISTL - Assign IP Station data.

TN: Tenant Number IP STN: IP Station Number (Maximum 5 digits) KIND: DtermIP TEC:12 - Dterm RSC: Route Restriction Class (0-15) SFC: Service Feature Restriction Class (0-15) LENS: Line Equipment Numbers

AKYD - Single Line Mode

TN: Tenant Number STN: Station Number (Maximum 5 digits) PR: 0 PL TN: Prime Line Tenant Number PL STN: Prime Line Station Number S: 0 - OG from Prime Line is not restricted MWD: 0 - MW data display on the top line LN PRE: 0 - Standard data of Line Preference TP: 0 - 4/8/16-button type Desktop terminal KYN1

KYI: 2: Multi-line KD: 0: Line TN: My Line Tenant Number STN: My Line Station Number RG: Ring Information for My Line

KYN2 KYI: 1: Function Key FKY:131: Disconnect Key



ALGSL/ALGSN - Assign a telephone number to a station number used for MC550.

Note: Telephone number must be assigned for SIP Handler Controlled SIP terminals. (Needed for MC550)

Configure Complex SIP Registration Passwords within the SV9500

Ensure that all SIP stations on the system have complex passwords assigned to them. It is highly recommended to use 10 digit passwords to ensure the most security from external parties attempting brute force registration attacks. If the default password is left for a station then it may be guessed by external attackers that are looking to exploit the system. So it is imperative that all SIP stations are configured with complex passwords to avoid such attacks.

ASYDL – System Data

System Data 1382

Bit 1: 0 - In Service (default) – Ensure that the SIP Handler is configured to support SIP Authentication.

A maximum of 10 digits can be entered for password. A password can contain 0-9, * and #. The maximum digits that

can be used for a password follows Maximum Number of Digits assigned by the AMND command.

AMND - Assign the Maximum Necessary Digit Data for the password assigned by the ASPW command.

TN: 0 (Fixed) DC: Destination Code (Assign the 1st digit of all passwords.) MND: Assign 10 for a 10 digit password. This is recommended to reduce the probability of an external party guessing the registration. TOLL: 0 AN: 0 RATE: 0 A/D: 0

ASPW

Assign the password for each SIP Station within the ASPW command. It is recommended that a complex 10 digit password is configured to make external brute force registrations attacks very improbable.

Note: This password must be assigned on the OW5000 admin page for this station as the Softphone Password.



9.2 UCE Configuration

Split domain naming must be implemented in order for the MC550 to work on both internal WiFi networks as well as external 3G/4G mobile data networks. What this means is that the same domain name will be used on both internal and external networks for connecting to the PBX. However, there will be different IP Addresses resolved for the DNS name depending on whether the MC550 is internal or external. On the internal network the SV9500’s SIP Interface will be the specified IP Address. On the external network the IP Address of the external SBC interface will be specified. Below is an example of split DNS:

Example:

DNS Server Hostname Host A Record

Internal SV9500SIP.<domain name> 192.168.169.32

External SV9500SIP.<domain name> 10.20.2.166

The OW5000 needs to have the SIP Registration setting for the SV9500 set as a DNS name, as shown below: Systems > SIP Registration Server



Each MC550 user needs a Softphone login and password configured. The password entered here in the UCE must match the password set in ASPW for the MC550.

This will be the Password configured

in ASPW for the Standard SIP station

Select the Standard SIP Registrar Server. Ensure DNS name is

used.

This domain name must exist in the internal and external DNS servers. The internal DNS will resolve to the SV9500 and the external to the

SBC external IP Address.



The MC550 also connects to the XMPP server within the UCE. The configuration for this is in the Platform->XMPP Server section of the OW5000:

XMPP Domain name. This should be the same as the Active Directory domain.

This is the server that clients will connect to when using on Mobile data. This

can be the same as the internal name as long as the external DNS server points to an externally

accessible IP Address. An alternate external DNS

name can be specified here if required.

This is the server that clients will connect to

when on WiFi. This will be an internal IP

Address.



MC550 Softphone Configuration

The MC550 needs to have the SoftPhone function enabled within the mobile client. This setting can be found in the following location More -> Settings -> Softphone->SoftPhone Enabled. Once this Softphone function is enabled the “Allow over Cellular Network” should also be enabled to allow for the MC550 to use the mobile data connection for SIP and media connections (if this is not enabled the client will not register over mobile data).

Note: When the system is configured correctly the SoftPhone status should be “Ready to use” with “SIP: [SIP 200: OK]” and “XMPP: OK”. If there is an error shown here then there is a problem with the MC550 registering to the system.

For outbound calling to work the MC550 must be configured to select the Smart Device as its dial device (Profile -> Dial Device: Smart Device):

If this setting is not set then the MC550 will show the following registration error:



MC550 Dual Ringing

In order for the MC550 to ring at the same time as the desk phone the user can configure dual ringing within their UC700 client. Below is an example of a dual ringing configuration:

For outbound calling the Dial Device must be configured to

be “Smart Device”

Configure the Primary Extension first (must be first in list) and the Smart Device as the second device in the list



MC550 DTMF Operation

The MC550 uses the UCE for generating and sending DTMF to other NEC Terminals and NEC Gateways. The flow of this messaging is as follows:

MC550 -> HTTPS -> UCE -> OAI -> SV System Generates H245/SIP Notify Message and sends to endpoint

This method for DMTF is not supported by other Standard SIP terminals. So DTMF cannot be sent from the MC550 to other Standard SIP devices (including other MC550). This method is supported by all NEC terminals and NEC Gateways (including MG-SIP).

9.3 Troubleshooting and Maintenance

SSH Access

It is recommended to allow remote command line access to the SBC via SSH. This will give administrators full access to the command line via an encrypted channel. Any SSH client can be used to connect to the interface. A common SSH client is called Putty and can be downloaded for free from the internet. SSH can be enabled with the following settings:

System > Management > Telnet/SSH Settings

1. Set Enable SSH Server to Enable 2. Configure an Admin Key.



Backing Up SBC Configuration

The SBC can be backed up to an “INI” file that can be reloaded in the case of system recovery. To backup the configuration select the Save Configuration File option from the Device Actions menu:

Select the Save INI File from the Configuration File options:

Network Ping and Trace Route

The BX SBC has the ability to send outbound Ping messages. This can be very useful when confirming that the devices interfaces are connected to the right network segments. First try pinging the Default Gateways for both interface and then try outside IP Addresses.

UNIVERGE BX9000> ping <IP Address>



If you would like to see the route that is being used by the BX SBC to get to another location you can use the traceroute command.

UNIVERGE BX9000> traceroute <IP Address>

Registration Database

When an MC550 user registers through the SBC to the BX SBC the user’s Address of Record will be added to the SBC’s registration database. This is how the SBC knows where to route return traffic to the MC550 clients. The SBC’s registration database can be viewed via the web interface:

SAS/SBC Registered Users page:



Status & Diagnostics tab > VoIP Status menu > SAS/SBC Registered Users

Example:

Syslog Configuration

The following procedure describes how to configure the Syslog server's address to where the device sends the Syslog messages.

To configure the address of the Syslog server:

1. Open the Syslog Settings page (Configuration tab > System menu > Syslog Settings). 2. In the 'Syslog Server IP Address' field, define the IP address of the Syslog server. 3. In the 'Syslog Server Port' field, define the port of the Syslog server. 4. Click Submit.

To enable Syslog:

1. Open the Syslog Settings page (Configuration tab > System menu > Syslog Settings). 2. From the 'Enable Syslog' drop-down list, select Enable. 3. Click Submit.

Example:

Note: Syslog will send messages on UDP port 514, so you must ensure that any firewall between the SBC and the syslog server allow UDP port 514.

Configure Syslog Level

The level of the messages sent to Syslog can be controlled by configuring Logging Setting Filters in under:

System > Logging > Logging Filters Table

Example – To see all SIP Messages traversing the system use the following settings:



The Filter Type field can limit the syslog capture down to only show message for specific (eg. Trunk Group, IP-to-IP Routing, User, SIP Interface) which can be useful for reducing the amount of noise in the log.

Filter Type Settings:

Any (default)

IP Group - Filters log according to an IP Group.

SRD - Filters log according to an SRD.

Classification - Filters log according to a Classification rule. Note: Applicable only to the SBC BX9000.

IP-to-IP Routing - Filters log according to an IP-to-IP routing rule.

For configuring IP-to-IP routing rules, see Configuring SBC IP-to-IP Routing Rules on page 466. Note: Applicable only to the SBC application.

User - Filters log according to a user. The user is defined by username or username@hostname in the Request-URI of the SIP Request-Line. For example, "[email protected]", which represents the

following INVITE: INVITE sip:1100@domain;user=phone SIP/2.0

IP Trace - Filters log according to an IP network trace, Wireshark like expression. For more information on configuring IP traces.

SIP Interface - Filters log according to SIP Interface. For configuring SIP Interfaces.

You can use the index number or string name to specify the configuration entity for the following 'Filter Types': IP Group, SRD, Classification, IP-to-IP Routing, or SIP Interface. For example, to specify IP Group at Index 2 with the name "SIP Trunk", configure the parameter to either "2" or "SIP Trunk" (without apostrophes).

Syslog via Web Interface

The BX SBC provides an embedded Syslog server, which is accessed through the Web interface (Status & Diagnostics tab > System Status menu > Message Log). This provides limited Syslog server functionality.



To stop and clear the Message Log, close the Message Log page by accessing any another page in the Web interface.

Note: It's not recommended to keep a Message Log session open for a prolonged period. This may cause the device to overload. For prolonged (and detailed) debugging, use an external Syslog server.

Activity Log

The BX SBC has an activity log that can be used to track high level access and changes made to the system. It is recommended to enable the logging of parameters in the Activity Types section. This will allow the tracking of changes to configuration, device resets, non-authorised access, etc:

Configuration tab > System menu > Syslog Settings



The logs for these setting are shown under the Status & Diagnostics tab > System Status > Activity Log as shown below:



Appendix 1 – Configuring CA Certificates for HTTPS

Using a CA Signed Certificate for Web Page HTTPS Access

In order to replace the existing Self Signed certificate with a Certificate Authority (CA) Signed certificate a Certificate Signing Request (CSR) will need to be created on the SBC which must be signed by the CA. The following example shows how to create a CSR and submit it to a Microsoft Server CA and then import it back into the SBC.

Open the System -> TLS Context page. From here you can choose to use the default TLS context or to create a new

context. For this example the default context will be used:

Select TLS Context Certificate:

Type in the Subject Name (Note: if you are using a DNS name to connect to the SBC then this must be used as the Subject Name. If you are connecting via an IP Address then this will be the Subject Name, however, it’s usually recommended to use DNS names.). Fill in the other fields with values appropriate for the organisation. Then click the Create CSR button:

A Base 64 encoded CSR string will now be created and displayed. Copy this text to the clipboard and send it to the Certificate Authority administrator for signing:



The following example will show how to sign the CSR with a Microsoft Certificate Authority. In the CA web interface, select Request a certificate:

Select the Advanced certificate request options:

Select the Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file option:

Copy this text and send it to the Certificate Authority for signing.



Now paste the CSR that was generated by the SBC and select a Web Server Certificate Template:



Download the certificate as a Base 64 encoded certificate (this is the format supported by the SBC for import):

In addition to the certificate that has been generated in the previous steps, the SBC will also need to trust the Root Certificate of the Certificate Authority. This needs to be supplied in Base 64 format. In a Microsoft Certificate authority this can be accessed via the Certificate Services front page by selecting Download a CA certificate, certificate chain, or CRL:

Select the Base 64 format and Download CA certificate:



Upload the Device Certificate:

Now that the certificates have been generated they can be imported into the SBC. From the System -> TLS Contexts page, select the TLS Context Certificate option:

Upload the file by clicking the Browse button in the Device Certificate section:

Note: Check that the file you are uploading is in Base 64 format. To check this you can open the file in Notepad and the format should look similar to this:

-----BEGIN CERTIFICATE-----

MIIDgzCCAmugAwIBAgIQKunykP5E9Z9LKwRmsUe3KjANBgkqhkiG9w0BAQUFADBU

MRMwEQYKCZImiZPyLGQBSDisdhFtMRkwFwYKCZImiZPyLGQBGRYJbXlseW5jbGFi

MSIwIAYDVSDFsditeWx5bmNsYWItMjAxM0VOVERDMDAxLUNBMB4XDTEyMTAyOTA0



MzIwN1oXDTIyMTAyOTA0DHisnhdDisdhSKEGCgmSJomT8ixkARkWA2NvbTEZMBcG

CgmSJomT8ixkARSDfishdfDnY2xhYjEiMCAGA1UEAxMZbXlseW5jbGFiLTIwMTNF

-----END CERTIFICATE-----

Once the file is uploaded you will see the “File <cert name> was successfully loaded into the device” written underneath the Send File button.

This certificate should now be displayed in the main TLS Contexts page, for the context that it was imported for,

under the Certificate Information heading:

Upload the Root Certificates:

Upload the Root Certificate (or certificates if there is a chain) by first selecting TLS Context Trusted Root Certificates in the TLS Contexts page:

Click the Import button:

Select the Base 64 encoded PEM file:



Note: the content of this file should be in plain text format and look something like this:

-----BEGIN CERTIFICATE-----

MIIDgzCCAmugAwIBAgIQKunykP5E9Z9LKwRmsUe3KjANBgkqhkiG9w0BAQUFADBU

MRMwEQYKCZImiZPyLGQBSDisdhFtMRkwFwYKCZImiZPyLGQBGRYJbXlseW5jbGFi

MSIwIAYDVSDFsditeWx5bmNsYWItMjAxM0VOVERDMDAxLUNBMB4XDTEyMTAyOTA0

MzIwN1oXDTIyMTAyOTA0DHisnhdDisdhSKEGCgmSJomT8ixkARkWA2NvbTEZMBcG

CgmSJomT8ixkARSDfishdfDnY2xhYjEiMCAGA1UEAxMZbXlseW5jbGFiLTIwMTNF

-----END CERTIFICATE-----

Once imported the Root Certificate will show up in the Trusted Certificates list:

Now when connecting to the SBC via HTTPS there should be no Certificate Error and the certificate used should be the one that was imported:

Note: The PC that you are accessing the Web Browser from needs to also trust the Root Certificate of the Certificate Authority that created the certificate. If a public certificate authority was used then it should already trust this Root CA. However, if it was a private CA then you may have to manually import the certificate into your Trusted Root Certificate Authorities folder within the Certificates MMC.



Appendix 2 – Configuring SNTP Time Synchronisation

Setting the time and date for a standard MC550 deployment is not required. However, it can be useful for correct time stamps in log messages, etc. Also, time synchronisation is required when dealing with TLS connections, so it’s good practice to configure the SBC to synchronise it’s time with a time source.

To configure SNTP using the Web interface:

1. Open the Time and Date page (Configuration tab > System menu > Time And Date), and then scroll down to the 'NTP Sever' section. Enter the IP Address of an NTP server, this will commonly be a local domain controller or internet based time server.

Note: STNP uses UDP Port 123 for connection to the time server. So if the SBC is deployed in a DMZ then the internal or external firewall will need to allow these ports (depending on if an internal or external server is being used).

Configure the NTP server address:

In the 'Primary NTP Server Address' field, configure the primary NTP server's address (IP or FQDN).

In the 'Secondary NTP Server Address' field, configure the secondary NTP server.

3. In the 'NTP Updated Interval' field, configure the period after which the date and time of the device is updated. This will usually be once a day (ie. 24 hours).

3. In the Time Zone settings configure the UTC Offset for your location (eg. Melbourne is +10 hours).

4. If your location follows Daylight Savings Time then Enable the Dayligh Savings Time settings and configure the Start Time and End Time Values (eg. for Melbourne Daylight Savings Start on the first Sunday in October at 2am and Ends on the first Sunday in April at 3am).

Example:

Note: If you use an FQDN for NTP you must have a DNS server defined in the SBC.

The SNTP application by default is bound to the OAMP interface. However, it can be moved off the OAMP interface by changing the following setting within the systems ini file:

1 = OAMP (default)

0 = Control (This will bind the SNTP application to the control interface with the lowest Interface ID)

Note: For the parameter to take effect, a device reset is required.

For more information, visit au.nec.com, email [email protected] or call 131 632

Australia Corporate Headquarters (Japan) North America (USA) Asia Pacific (AP) Europe (EMEA)

NEC Australia Pty Ltd NEC Corporation NEC Corporation of America NEC Asia Pacific NEC Enterprise Solutions

au.nec.com www.nec.com www.necam.com sg.nec.com www.nec-enterprise.com

About NEC Australia Pty Ltd. NEC Australia is a leading technology company, delivering a complete portfolio of ICT solutions and services to large enterprise, small business and government organisations. We deliver innovative solutions to help customers gain greater business value from their technology investments.

NEC Australia specialises in information and communications technology solutions and services in multi-vendor environments. Solutions and services include: IT applications and solutions development, unified communications, complex communications solutions, network solutions, display solutions, identity management, research and development services, systems integration and professional, technical and managed services.

NEC Australia Pty Ltd reserves the right to change product specifications, functions, or features, at any time, without notice. Please refer to your local NEC

representatives for further details. Although all efforts have been made to ensure that the contents are correct, NEC shall not be liable for any direct, indirect,

consequential or incidental damages resulting from the use of the equipment, manual or any related materials. The information contained herein is the property of NEC

Australia Pty Ltd and shall not be reproduced without prior written approval from NEC Australia Pty Ltd.

Copyright © 2015 NEC Australia Pty Ltd. All rights reserved. NEC, NEC logo, and UNIVERGE are trademarks or registered trademarks of NEC Corporation that may

be registered in Japan and other jurisdictions. All other trademarks are the property of their respective owners. All rights reserved. Printed in Australia. Note: This

disclaimer also applies to all related documents previously published.


Documents

Technical Information Bulletin MC550 / NEC BX SBC Integration interop...MC550 / NEC BX SBC Integration - DRAFT Technical Information Bulletin. Step 4: Media Realms. Media Realms define