PBX Network Topology
PBX Dial Plan
When you replace a PBX with Lync Server 2013 no doubt you will have to deal with Analogs. There are several types of Analogs you should be on the look out for when you are gathering documentation on the PBX environment.
- Analog extensions
- Fax machines
- Fax servers
- Credit Card machines
- Postage machines
- Door phones
- Gate phones
- Cordless phones
- Paging systems
I'll talk about each of these and how to handle each of them effectively.
Analog extensions/Cordless phones
These are probably the easiest of all the analogs to handle. Analog Extensions and Cordless phones are just straight voice extensions that use an analog port on a FXS gateway. Although you can handle Analog extensions completely outside of Lync Server 2013, I recommend that you use the Lync Server Analog Device feature.
Using the Analog Device feature serves two purposes. The first, is to a Lync user it appears as any other Lync user/device/common area phone. When created, it has a contact created in Active Directory and is assigned a Tel URI. This also will allow calls from the Analog device to appear in Monitoring Server reports. The second purpose is to be able to control with Voice Policies what numbers the Analog Extension can dial. This is important in situations where an analog phone is required, like an intrinsically safe enclosure for hostile environments, but still needs to have controls as to what numbers can be dialed.
At some point I plan to do a detailed blog on setting up Lync Server Analog Devices and all the pieces that need to be put in place for it to work as designed.
Fax machines are a bit more of a problem. On the surface the Analog Device feature of Lync gives us the impression we can handle faxes in a similar manner to Analog extensions. There is some limitations to handling Faxes through Lync that ultimately, in my opinion, makes it a non starter.
First of all, when you create an Analog device with the Fax attribute enabled to true, all this does is immediately send the call directly back to the Gateway the Fax call originated from. There is no way to send this call to any other Gateway.
When the Gateway receives the call from Lync Server it follows the routing tables that in turn directs it to the appropriate port. If you have a lot of fax machines for a location, you are limited to the number of Fax ports the Gateway connected to the PSTN can support.
Next issue, in order to send the call through Lync, the codec for the originating call to the Lync Server can not use T.38 or any other Fax specific protocol. The Gateway can only be configured to use G.711 only. If any other codec is sent to the Mediation Server the call will fail.
In theory G.711 protocol should be okay for Fax transmission, but in my experience it is flaky and customers tend to complain when things don't work consistently.
My recommendation is to handle Fax machines outside of Lync Server. Allow the Gateway to route the call to the appropriate port whether that is on the originating Gateway or a different Gateway elsewhere. This will allow the use of T.38 or any other Fax specific protocol and give a more consistent experience.
Fax servers can only be handled through Gateway routing outside of Lync Server. These servers typically only support T.38 and there is no way for the Fax implementation in Lync to send these calls to a Fax server using the Analog Device feature.
I would not under any circumstance route these through Lync to Exchange UM and then over to the Fax server. Even if you did get it to work, I doubt it would work consistently because T.38 is cut out of the picture.
Modems/Credit Card machines/Postage machines
There is no way to handle Modems and Modem like devices within Lync Server. Because of this you will need to use the Gateway routing feature the send these calls to the appropriate Analog port on an FXS Gateway. Depending on the Gateway manufacturer there may be specific codecs that are more appropriate for modems. If this is the case the modem negotiation will be detected once the call is answered and the codec will be renegotiated.
Door phones/Gate phones
These can be setup like an Analog Extension within Lync Server, but they will never receive a call. They only make a call, usually to a specific number. This specific number can be a Response Group or to a receptionist. What makes these devices unique is that they listen for certain DTMF tones to activate a relay to remotely open a door or gate. Sometimes a door phone might be PBX specific and will need to be replaced with an analog equivalent (that might require a professional installation).
Lync Server does not provide any native ability to do paging. There have been third party developed solutions for this, but as far as the theme of this blog post goes I'm going to stick to talking about overhead paging systems. The first thing to determine is what type of paging interface the PBX has. If it is an analog interface then your job will be easy. If it is some sort of relay (dry loop for instance) then you will need to acquire a paging adapter such as a Valcom V-200X series. An adapter like a Valcom will accept an analog connection and interface to the paging equipment.
Once you have a Valcom like adapter, or a paging system that accepts an analog connection, you can again setup a Lync Analog device to direct calls to the appropriate Gateway and then using the Gateway routing tables deliver the call to the appropriate port.
One of the techniques I use with Paging systems in Lync is to normalize a dialing shortcut to reach the paging system. If the PBX accessed the paging system by dialing a feature code like 200 then I might do a normalization rule of *200 and normalize to the TEL URI of the Analog Device I created. Unfortunately not all PBXs work like this and sometimes you just have to ask the customer what they want to dial to reach the paging system.
Nice read, for your door phone and gate phone what vendor are you using. We have tried several. CyberData works well, but you need a Sonus, AudioCodes or Patton Gateway. We bought this one recentlyReplyDelete
Yea we usually try to work with what the customer already has and hook that up to some sort of Analog gateway. Can't really remember a time where I needed to install one new for a customer.ReplyDelete