Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Current »

Introduction

This document describes the recent Internet Telephony Service Provider (ITSP) interoperability successfully implemented between Sipxecs 4.6 update 9 and Primelink, a wholly-owned subsidiary of Champlain Telephone based out of Plattsburgh, New York. Primelink has been a leader in the implementation of Fiber to the Premise solutions which enables next generation broadband solutions to businesses and homes to regions traditionally served by telco DSL and cable networks.

The focus is on the configuration guidelines between Primelink’s Metaswitch infrastructure and the Sipxecs trunking gateway installed at a customer site to achieve ITSP connectivity for processing of PSTN incoming and outgoing calls. Configuration of phone profiles, dialplans, voicemail, autoattendant, and other Sipxecs services is beyond the scope of this document – please refer to other documentation located at wiki.sipfoundry.org for further information for configuring other Sipxecs services.

ITSP Interoperability Planning with Primelink

The attached diagram provides a simplified architectural view of the network topology used to perform interoperability between Primelink and Sipxecs:

Primelink uses Metaswitch's softswitch and session border controller (SBC) technologies for the delivery of IP-based telephony to business customers. Optical Line Terminals (OLT) at the Primelink central office terminates the fiber access from multiple customers and front-ends the Metaswitch voice switching infrastructure. The Metaswitch SBC acts as a Back-to-Back User Agent (B2BUA) for the softswitch as well as upstream IP-based long-distance carriers. Local and long-distance TDM-based PSTN traffic is converted to IP via media gateways connected to the Metaswitch softswitch.

At the customer premise, Primelink installs optical network terminals (ONT) that have several interface configurations depending on the customer requirements -.e.g. ONTs with PRI TDM interface to a legacy PBX, multiple Ethernet ports to the customer premises, etc.  For this interoperability effort, a Primelink-provided ONT with 4 analog ports and one Ethernet port was used. The analog ports on the ONT were connected to a legacy PBX that was being obsoleted.

The ONT Ethernet port was connected to a router WAN port with two southbound Ethernet interfaces – one interface was attached to the customer voice network to a VLAN-tagged port on a Power-over-Ethernet (POE) enabled layer 2 (L2) switch, and a second port used for data traffic was connected to an untagged port on the same L2 switch. The router is configured to only allow voice-based SIP and RTP traffic between the Primelink SBC and Sipxecs and IP Phones on the customer voice LAN.

An Ethernet cable runs from the L2 switch to the IP phone on each desk in the customer premise. A second Ethernet cable runs from the phone to the desktop computer for local network and Internet connectivity.

The Sipxecs server is connected to the voice VLAN on the customer L2 switch and provides DHCP and DNS services to the phones. The customer router provides DHCP and DNS services to the desktop computers and other data wireline as well as wireless appliances on the customer data network.

In order to bind multiple DIDs to one SIP trunk, the Metaswitch SBC must have one node where it will send all RTP traffic destined for Sipxecs endpoints (e.g. IP phones, media server) – this is similar in approach to the media server architecture for Microsoft Lync where the media server can send RTP traffic to only one endpoint. Given this, all phones in the customer network along with the Sipxecs server should be placed behind the customer router – this allows public IP address of the customer router to be defined in the Metaswitch SBC as the customer endpoint for the SIP trunk.

The default SIP port that the Sipxecs Sipxbridge internal SBC likes to receive signaling from the ITSP network is 5080 – in building the customer SIP trunk definition, the Metaswitch SBC specifies the public IP address of the customer router that it is sending SIP and voice RTP traffic to, port 5080 for outgoing SIP signaling, as well as an authentication userid corresponding to the billing number for the customer account.

Step 1 – Specifying the SIP Trunk Requirements to Primelink

Gather the following requirements for Primelink:

  • Public IP address assigned to the customer router attached to the Primelink ONT.
  • If the customer is an existing Primelink customer, it is recommended that a new SIP trunk with temporary DID numbers be created – this allows interoperability testing to be conducted in parallel to the existing voice network.
  • The SIP port provisioned in the Sipecs Sipxbridge SBC where incoming SIP signaling from Primelink’s SBC to Sipxecs will be sent. It is recommended that the default 5080 Sipxbridge port be used.

Primelink will use these parameters in building the customer SIP trunk on the Metaswitch SBC and provide the primary DID (or billing) number to be used for authenticating incoming calls from Sipxecs into Primelink.

Step 2 – Building the Trunk Gateway Profile in Sipxecs

Go to Devices > Gateways and select the option to build a SIP Trunk. From the Configuration menu provide the name of the gateway trunk, IP address of the Metaswitch SBC, SIP port and protocol to be used in sending SIP signaling traffic to Primelink.

In the Gateway > Caller ID menu, provision the default callerid to be used for outgoing calls. The Metaswitch SBC can be configured to make this callerid a DID not assigned to the SIP trunk – this can be useful when doing live testing of Sipxecs using temporary SIP trunks while leaving the existing PBX infrastructure in place.

Go the Gateway > ITSP Account menu and specify the authentication number (normally the billing number) provided by Primelink in the Username field. Leave the Register on Initialization radio button unchecked. Click on advanced settings, and coordinate the Session Timer Interval setting with Primelink – the session timer interval setting in the Sipxecs trunk gateway setting needs to match the setting defined in the Metaswitch SBC.

Step 3 – NAT Traversal Setting

Go to System > NAT menu,  and change to Nat traversal settings as follows:

  • Set NAT traversal address type to ‘Specify IP Address” from Stun
  • Set the Public IP Address to the IP address of Metaswitch SBC provided by Primelink

Step 4 – Validate Sipxbridge External Port Setting

Go to the Devices > Sipxbridge menu and ascertain that the external port setting for the internal Sipxbridge SBC is set to 5080.

Other Considerations

Primelink supports network-based call forwarding using *72xxxxxxxxxx to enable unconditional call forwarding and *73 to disable. If the existing customer’s PBX is on the Primelink network, then the Sipxecs server can be tested in a production network without removing the existing legacy PBX as follows:

  • Build and configure new SIP trunk using temporary DID numbers assigned by Primelink
  • Install Sipxecs and phones in the customer network in parallel with the legacy phone system.
  • From the legacy phone system, use *72  to unconditionally call forward the customer’s primary DIDs on the legacy PBX to the temporary numbers assigned to the SIP trunk on Sipxecs.

Porting of primary DID numbers from the legacy PBX to Sipxecs when all testing is completed is straight-forward but requires coordination with Primelink. The Primelink technician detaches the DIDs from the analog or PRI ports assigned to the ONT on the Metaswitch softswitch then attaches the DIDs to the SIP trunk – this process takes 10-15 minutes.

Finally, and although not directly related to Primelink interoperability with Sipxecs, it should be noted that the customer L2 POE-enabled switch used for interoperability had the IP Phones configured to the L2 switch as tagged traffic, and the PC daisy-chained off the IP Phone as untagged traffic. The L2 switch initially was configured with LLDP discovery to determine which DHCP server should be used to assign IP addresses to the phones – the LLDP worked intermittently as the IP Phone sometimes was assigned an IP address from the data network instead of Sipxecs and needed to be re-booted.

Provisioning the VLAN address in the Phone > Network configuration profile bypassed the switch LLDP discovery and resolved the issue.

  • No labels