Linked Servers - How do they work?

Linked servers communicate over a protocol called IAX2. The IAX2 protocol uses only one UDP port for both control and data traffic. Unlike SIP, this means if the control connection can be established an audio connection will always be established. Linked servers can be setup behind different firewalls or behind one firewall on the same subnet.

Linked server functionality

Linking two PBXtra systems together using a Linked Server license gives you the ability to:

• Call extension to extension - Extensions on Linked Server A can call extensions on Linked Server B. When provisioning linked servers, ensure that there is an independent extension number scheme per server to avoid extension overlap (see below).

• Administer all linked servers from a centralized location - From the Admin Panel (AP), you can easily switch between linked servers by using the drop-down box at the lower right-hand corner of the AP. Just select which server you would like to administer from the drop-down box, and you are automatically taken to that server's AP.

• Forward to remote extensions from a sub-menu - When adding a new sequence, you can choose 'Go to extension' or any of the 'Go to submenu/ext.' options to forward calls to an extension on a linked server.

• Forward to remote extensions from a sub-menu using a keypress - When adding a new keypress, your remote extensions are available in the drop-down box.

• Add linked server agents to local queues - When adding agents to a queue, you can select agents from any linked server to be queue members. The status of these agents shows as 'linked' in the 'View Queues' page.

• Create virtual extensions for remote sub-menus - By creating a new virtual extension and then setting the 'Call Forwarding' option in the 'View Extensions' page to a sub-menu on Linked Server A, you are able to reference that virtual extension from Linked Server B. This functionality can be used to create a sub-menu that forwards to a voicemail box, a conference bridge, a queue, or another sub-menu.

• Toll bypass - If you have a server in New York linked to a server in Los Angeles, you can set the dial plan on the New York server to dial out through the Los Angeles server for all calls to Los Angeles and vice versa.  This allows you to avoid long distance charges to particular area codes/prefixes.

Additional Linked Server Functionality with CP 5.0 and above

• Paging & Intercom - If you have either purchased or upgraded to the new CP 5.x version of Fonality Control Panel, paging and intercom will now function between linked servers and allow you to page or intercom extensions and groups with a simple key command from your phone.

Linked server limitations

Blast groups - You cannot add extensions from Linked Server A to the blast group on Linked Server B.

The most common cause of server linking issues...

The most common reason for a linked server setup to not function is a firewall blocking traffic on UDP port 4569. Verify this port is open on your firewall for both PBXtra servers. If you can only make calls on one direction (for instance, from server A to server B, but not server B to server A) then only one of the firewalls is blocking traffic. In the previous example, server A's firewall settings may not be configured properly. If your firewall settings are correct please contact FonalitySupport for troubleshooting.

----

CP version 4.x only (No longer applies for CP version 5.x)

Every linked server needs a unique extension numbering scheme...

By way of example, let's assume a customer has two linked servers. We will call them Server A and Server B. Server A and Server B should not share any similar numbering for extensions.

• Server A: 7XXX

• Server B: 6XXX

Do not mix and match.

And here's why...

Technically, FONcore searches for a matching extension within a file called 'external.conf' first.  If the matching extension exists, the extension lives on the same server as the caller.  If the extension does not exist, then FONcore searches through a file called link.conf for a dial plan-ish match.

exten => _6XXX,1,Dial(IAX2/c${ACCOUNT}i@cserverBi/${EXTEN}@external)

exten => _6XXX,2,Dial(IAX2/c${ACCOUNT}x@cserverBx/${EXTEN}@external)

Notice that for the purpose of explanation, we've written 'serverB' within each of the lines above.  Normally, 'serverB' would actually be the Server ID of the linked server (e.g. 1234).  You will also note that '6XXX' looks like a dial plan for a four-digit extension. 

So, if a user from Server A at extension 7000 wants to call a user on Server B at extension 6000, he/she dials 6000 which matches 6XXX (6 followed by any other three digits - in this case zeroes), and the server attempts to push the call to the linked server via the IAX2 protocol (Inter-Asterisk eXchange) using the internal IP Address of the linked server first (denoted by the 'i@' - 'i' for internal) followed by an attempt using the external IP Address (denoted by the 'x@' - x for external).

When you mix and match the extension numbers between linked servers, FONcore can become confused and the time FONcore needs to match your extension increases in proportion to the number of possibilities you create.

The best advice Fonality can provide is to come up with a new numbering scheme for each server.