New to Lync is the handling of “analog extensions”: faxes, courtesy phones, modems, etc.

Prior to Lync, analog devices were typically created and managed through your voice gateways, perhaps with manual routing entries and no control over barring or means of cost recovery. It was far from elegant.

Now you can create the extensions themselves as Contacts in your AD, add a picture, dial them by name, apply Lync voice policies, and even collect CDR when they’re used – so they’re very much now an integral part of the Lync solution.

The process is relatively straightforward. I’ll show you how it’s done for a Quintum “Tenor” gateway – in this case an ASG400 running firmware P108-09-10. Provided you get your ports sorted out, most other basic gateways should be configured in much the same way…

 

1. Add the Tenor as a new PSTN gateway in your topology:

Note we’re using TCP for this basic gateway, and Port 5068.

2. Click “Add” and select to associate the Gateway to the Mediation Server:

3. Publish the topology.

4. Create the new extension’s contact entity in AD from the Lync Shell:

New-CsAnalogDevice -LineUri tel:+61212345678 -DisplayName "Name Goes Here" -RegistrarPool lync2010.contoso.com -AnalogFax $True -Gateway <Quintum’s IP/FQDN> -OU "ou=RTC Special Accounts,dc=contoso,dc=com"

Check the command executed correctly by running the command “Get-CsAnalogDevice”. Note that there’s no voice policy evident – I’ll come back to that in a separate post as it’s worth some explanation:

PS C:\> Get-CsAnalogDevice

Identity      : CN=<Name Goes Here>,OU=RTC Special Accounts,DC=contoso,DC=com 
VoicePolicy   : 
RegistrarPool : <lync2010-FQDN> 
Gateway       : 192.168.xx.yy 
AnalogFax     : True 
Enabled       : True 
SipAddress    : sip:<GUID>@contoso.com 
LineURI       : tel:+61212345678 
DisplayName   : <Name Goes Here> 
DisplayNumber :

BTW, because Lync doesn’t handle the T.38 fax protocol, you need to manually set “AnalogFax” to $true for all ports with a fax or modem on them. This forces all calls to/from that device to G.711.

5. Point the Gateway to the Mediation server (which in this example is also the FE):

Make sure the Primary SIP Server Port is set to 5068, or whatever alternate port you might have chosen in Step 1.

Also note that the Register Expiry Time is set to “-1” – it doesn’t register with the Front-End server.

6. Update the SIP UA to listen for calls from Lync on port 5068:

If you skip this step or specify the wrong port, you won’t be able to make calls to this extension/gateway.

7. Configure the extension on the port as an E.164 number. You don’t need the “+” in front of the Dialled Number (DN) – we’re taking care of that in a sec. Make sure the UA is set:

8. Setup the Quintum with an appropriate Dial Plan. The example here is for Sydney:

9. Set var_config as per normal:

The var_config file can’t be accessed though Telnet – you get to it through the Tenor’s Config Manager / Tools / var_config. “SipTransportDefault” forces the Gateway to TCP (where a 0 would make it UDP), whilst “SipPrependPlus” automatically handles the “+” we deliberately omitted in Step 7.

10. Done! Now Lync controls the routing of all calls coming from your analog gateway. You’re also able to name-dial to those ports and add them to your Lync contact lists:

Whilst it shows as “Offline” normally, Lync will still report correctly if the line is in use when called:

When you’re called by the analog extension, Lync correctly performs the Reverse Number Lookup:

---

Postscript:

My Dialogic gateway (my FXO interface to the outside world) didn’t want to accept outgoing PSTN calls that were coming from the Quintum.

The SIP invite for a successful call made by the user to the Gateway was presented as

FROM: “User Name”<sip:+61212345678@<Lync Server FQDN>

…whilst the call from the Quintum (even though it’s proxied by Lync) came through as :

FROM: “Analog Telephone”<sip:+61212345678@<sip domain>

The Inbound VoIP Rules in the Routing Table were looking to match on the server’s FQDN and not the SIP domain, so were rejecting the call. A 403 was returned to the caller and the Dialogic call logs reported “VoIP: Not Accepted”, which was also reflected in the Lync Logger traces.

The solution was to change the Originating VoIP Host Address in the Dialogic’s Config / Routing Table / Inbound VoIP Rules from an IP/FQDN to “*”.

Other gateways use might also be tricked into rejecting the call if they use some kind of host validation…

 

– G.