Adding a PLAR (automatic ring down) to Cisco SIP Phone with SideCar (Key Expansion Module)


For those of us that work in the financial sector with trading floors, it is common to find expensive turrets spread across trader’s desks. Traders love their turrets and features that come with them, especially the ability to have hundreds of PLAR or ringdown lines, dual handsets, and a bunch of other features. Sometimes a turret isn’t necessary, the features are overkill and/or there isn’t a way to justify the cost of a $3000-$6000 unit.

In most cases the turret is used to terminate broker lines and this is what traders typically use them for. PLARS can be terminated on a cisco phone if you already have them configured in Call Manager.

My previous article found here provides information on how to set up the PLARS in Cisco Call Manager

For this article we used a Cisco 8961 SIP Phone with a Key Expansion Module.

Adding a ringdown to a phone is simple enough by simply assigning the Directory Number to a button. Make sure you select the correct Route Partition and Calling Search Space. The problem we encountered was the ringdown(s) didn’t work whenever we hit the respective button. So you’re wondering what we did?

We created a SIP Dial Rule and selected ‘7940_7960_OTHER’

For the Dial Rule that we created, the first 5 lines are mapped to the 5 buttons on the 8961 phone, so you have to configure those lines to match whatever you have them set up for. For example the first three lines on our phones are set up with the users directory number. The other 2 are either not used or used when needed. Our directory numbers are 4 digits and start with ’16’ So the configuration looks like the following:

SIP Dial Rule

Now moving on to the Key Expansion Module. Depending on what buttons you want to assign, your SIP Dial Rule will have to be set up to match. In our case we used the next available lines in order 6, 7, 8, 9.

SIP Dial Rule PLAR

Now that you have the SIP Dial rule configured you should be able to hit the button and ring out to the distant end.

A couple of things to note. We are using a different directory number for voicemail so a button had to be programmed for that. We also found that if you don’t have ‘Always Use Prime Line’ set to ‘true’ a user can mistakenly go off hook on a  ringdown. Lets say for example they were tying to make a regular phone call, if the button that is selected on your phone (highlighted blue on the 8961) is a ringdown line, as soon as you pick up the handset it will ring the distant end so make sure to tell your users to select their own personal line before attempting to make a phone call.


Setting up an ARD (Automatic Ring Down) Cisco Unified Communication 8.x, Cisco Gateway Router, Speakerbus Turret

There a quite a few steps involved in setting up ARD circuits for a Cisco and Speakerbus deployment. I will outline the steps that are necessary to get this working in most environments. Some things may differ in your environment, and things may have to be tweaked slightly to get it working correctly.

I’ve provided a simple diagram to help you visualize how things are set up in our environment:

Voice Diagram Cisco Call Manager and Speakerbus

I’ll assume you already have your Speakerbus Turrets registered to your CallManger. If you don’t just make sure you upload all of the Speakerbus .cop files, and create a device profile for the unit before attempting to register. Hardware and software and Telco in our environment:

Our configuration

T1 Line Provided by IPC (we have more than one line for ringdowns but for this article we only need to provide configuration details for one) Cisco 2921 Voice gateway router running .H323 for communications with CallManager (or Cisco Unified Communications Manager CUCM) and a T1/E1 slot terminating our circuit from IPC  (Version 15.2(x)) Cisco Unified Communications Manager 8.6 Speakerbus iManager Speakerbus iD808 turret.

Steps that are involved:

1. Configure your gateway router to communicate with CallManager via the H323 protocol. 2. Setup your PLAR line on Cisco CallManager 3. Setup the Virtual Private Wire on Speakerbus iManager

Configure the H323 Gateway


Cisco CallManager

  1. Create the H323 Gateway by browsing to Device -> Gateway -> Add New.
    • Give you device a name (I use the IP address or the name of the router)


  2. Give it a description that will help other people understand what it is used for.
  3. Select your Device Pool (default in most cases)
  4. Call Classification (default in most cases)
  5. Location (default in most cases)
  6. Use Trusted Relay Point (default in most cases)
  7. Signaling Port (1720)
  8. Check the Media termination point required box.
  9. Check the PSTN access box


I came across an issue with barged calls on the turrets. For some reason when a user attempted to barge in on a shared virtual private wire from a Speakerbus turret, the existing call would drop or the voice quality would suffer terribly. It was fixed by checking the Media Termination Point Required checkbox on the H323 gateway.

Voice Gateway router

  1. If your router is not configured or maybe partially configured you can copy and paste, however if you are in a production environment and your router is already configured please take some caution in modifying your config. I will try to highlight all of the required parts.
    • voice service voip
       no ip address trusted authenticate
       allow-connections h323 to h323 // make sure to allow h323
       allow-connections h323 to sip
       allow-connections sip to h323
       allow-connections sip to sip
       no supplementary-service h450.2
       no supplementary-service h450.3
       supplementary-service h450.12
       fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none
       h323 // don't forget this
        bind control source-interface <your interface>
        bind media source-interface <your interface>
    • controller T1 0/0/3 <specify your interface> // this is where you break up the t1 into 24 channels.
       cablelength long 0db
       ds0-group 0 timeslots 1 type e&m-immediate-start
       ds0-group 1 timeslots 2 type e&m-immediate-start
       ds0-group 2 timeslots 3 type e&m-immediate-start // this is the port that is being used.
       ds0-group 3 timeslots 4 type e&m-immediate-start
       ds0-group 4 timeslots 5 type e&m-immediate-start
       ds0-group 5 timeslots 6 type e&m-immediate-start
       ds0-group 6 timeslots 7 type e&m-immediate-start
       ds0-group 7 timeslots 8 type e&m-immediate-start
       ds0-group 8 timeslots 9 type e&m-immediate-start
       ds0-group 9 timeslots 10 type e&m-immediate-start
       ds0-group 10 timeslots 11 type e&m-immediate-start
       ds0-group 11 timeslots 12 type e&m-immediate-start
       ds0-group 12 timeslots 13 type e&m-immediate-start
       ds0-group 13 timeslots 14 type e&m-immediate-start
       ds0-group 14 timeslots 15 type e&m-immediate-start
       ds0-group 15 timeslots 16 type e&m-immediate-start
       ds0-group 16 timeslots 17 type e&m-immediate-start
       ds0-group 17 timeslots 18 type e&m-immediate-start
       ds0-group 18 timeslots 19 type e&m-immediate-start
       ds0-group 19 timeslots 20 type e&m-immediate-start
       ds0-group 20 timeslots 21 type e&m-immediate-start
       ds0-group 21 timeslots 22 type e&m-immediate-start
       ds0-group 22 timeslots 23 type e&m-immediate-start
       ds0-group 23 timeslots 24 type e&m-immediate-start
    • voice-port 0/0/3:2 // this is the voice port that gets created once you channelize the t1
       auto-cut-through // you may or may not need this. It doesn't hurt anything to have it.
       define Tx-bits idle 1111 
       define Tx-bits seize 0000
       define Rx-bits idle 1111
       define Rx-bits seize 0000
       timeouts wait-release 3
       timing hookflash-in 150
       connection plar 1083 // The DN we created for the phones
       station-id number 1033 // The DN we created for the route pattern
    • dial-peer voice 1033 pots // This maps the port to the DN
       destination-pattern 1033
       port 0/0/3:2
    • dial-peer voice 1 voip
       description INBOUND DP from CUCM
       incoming called-number ^10..$ // I used wildcards because I have a bunch of ringdowns with 10..
       dtmf-relay h245-alphanumeric
       codec g711ulaw
       no vad
      dial-peer voice 2 voip
       description OUTBOUND to CUCM
       destination-pattern ^10..$ // I used wildcards because I have a bunch of ringdowns with 10..
       session target ipv4:x.x.x.x // ip address of your call manager
       dtmf-relay h245-alphanumeric
       codec g711ulaw
       no vad
  2. Notes:
    1. You can create individual dial peers should you need to. My example just eliminates the need to create a single entry for every ringdown that I have.

Setting Up an External Plar (Cisco CallManager)

  1. Setup an external PLAR line (Private Line Automatic Ringdown – Cisco Terminology) that both the Cisco and iTurret phones can share.
    • First you start off by creating a Route Partition. This can be done under Call Routing -> Class of Control ->Partition. Give it a descriptive name so you can identify it when needed. I.E. “PLAR_BRKR1” Try to keep it as short as possible as there is a known limitation per Cisco.
    • 2013-05-06_14-25-32
    • Secondly create the Calling Search Space. This can be done under Call Routing -> Class of Control -> Calling Search Space. I give it the same name as the Route Partition. “PLAR_BRKR1_CSS“. Make sure to select the Route Partition you just created.
    • 2013-05-06_14-29-47
  2. Create a null or blank translation pattern. You will be using the Route Partition and Calling Search Space you just created in the previous Step. To create the blank translation pattern, browse to Call Routing -> Translation Pattern. When creating the translation pattern, leave the translation pattern blank, select the Partition and Calling Search Space you created in the previous step. One of the most important steps to remember is assigning the DN that will be configured on your gateway router. In my case I assigned PLAR_UBS a DN of 1033. When we get to the router configuration step this is the DN that will be used.
    • 2013-05-06_14-41-36
  3. Now create a route pattern for the DN you just assigned to the Route Translation. In our case it was 1033.  This can be done under Call Routing -> Route/Hunt -> Route Pattern -> Add New. Set your route pattern, partition, and gateway route list. Make sure “Route this Pattern is selected”.
    • 2013-05-06_14-50-14
  4. Now create a DN (Directory Number) that will be used to assign to the phones and turrets. Under Call Routing-> Directory Number-> Add New. I used 1083 as the DN number for informational purposes. Assign the directory number, select the Route Partition and make sure to set the Calling Search Space to the values you just created.
    • 2013-05-06_14-58-29
  5. This part of the configuration is now complete. Once the DN has been created you can assign it to any turret. Things to note when assigning the PLAR: Make sure the busy trigger is set to 1. If you want to assign it to a cisco sip phone button or side car there are some additional steps involved. I will be writing a separate article about this.
    • 2013-05-07_07-58-41

Setting up the Virtual Private Wire in Speakerbus’ iManager console

  1. Create the Virtual Private Wire. Under Call Servers ->PBX Appearances ->New. Select PBX (you should have already defined your Cisco CallManager PBX) and type VPW (for Virtual Private Wire). The rest of the details are listed in the picture down below. Note that the Address and Destination address should match the DNs you created in the previous steps.
    • 2013-05-07_07-29-46
  2. Once you’ve created the VPW you can assign it to a device. Under users highlight the user you want to edit and select iTurret Layout to manage the phone template.
    • 2013-05-07_07-47-09


If you have questions or comments, feel free to post them below, or if you need assistance getting some of this set up, I’m happy to do so at the rate of $125 an hour.

Speakerbus Turrets

If you work for a financial company, more specifically a trading floor within the financial company, you are probably familiar with the term ‘Turrets’. Turrets are defined as:

Trading turrets, unlike typical phone systems, have a number of features, functions and capabilities specifically designed for the needs of financial traders. Trading turrets enable users to visualize and prioritize incoming call activity from customers or counter-parties and make calls to these same people instantaneously by pushing a single button to access dedicated point-to-point telephone lines (commonly called Ringdown circuits). In addition, many traders have dozens or hundreds of dedicated speed dial buttons and large distribution hoot-n-holler or Squawk box circuits which allow immediate mass dissemination or exchange of information to other traders within their organization or to customers and counter-parties. Due to these requirements many Turrets have multiple handsets and multi-channel speaker units, generally these are shared by teams (for example: equities, fixed income, foreign exchange) or in some cases globally across whole trading organizations.

Unlike standard Private Branch Exchange telephone systems (PBX) designed for general office users, Trading turret system architecture has historically relied on highly distributed switching architectures that enable parallel processing of calls and ensure a “non-blocking, non-contended” state where there is always a greater number of trunks (paths in/out of the system) than users as well as fault tolerance which ensures that any one component failure can not affect all users or lines. As processing power has increased and switching technologies have matured, voice trading systems are evolving from digital time-division multiplexing (TDM) system architectures to Internet Protocol (IP) server-based architectures. IP technologies have transforming the communications for traders by enabling converged, multimedia communications that includes, in addition to traditional voice calls, presence-based communications that include: unified communications and messaging, instant messaging (IM), chat and audio/video conferencing.

Speakerbus Turrets are provided by Speakerbus Group plc which is a privately owned communications technology developer and manufacturer headquartered in the UK with offices across Europe, the U.S. and Asia.

The SIP based iD808 turret is designed and certified to work with Cisco and Avaya based telephony systems.

iTurret - iD808

In the next article we will highlight a recent task of implementing Ringdown circuits between Cisco Unified Communications 8.6 and Speakerbus iD808 turrets.


1 2 3