In the previous blog article, we discussed the capabilities of Lync 2013 LBR that was introduced in CU1. This allows the prevention of PSTN Toll By-pass which is prohibited by government regulations in countries such as India. For example, Lync user A in Delhi can make a call to a local Delhi PSTN number using the PSTN Gateway in Delhi. But when the same user travels to Mumbai and tries to make a call back to a local Delhi PSTN number, LBR will not allow this user to use the same PSTN Gateway in Delhi via the Mumbai-Delhi WAN link. While this covers the Peer-2-Peer calling restrictions, it does not address conferencing scenarios. For example, Lync user A in Delhi first makes a call to a local Delhi PSTN number using the PSTN Gateway in Delhi, then adds Lync user B in Mumbai to create a 3 party AVMCU conference. If the conference is allowed, then User B is effectively using PSTN Toll-Bypass, and TRAI regulations also prohibit the mixing of VOIP and PSTN calls. To address this scenario, we need to configure and enable Conferencing LBR, which was introduced in Lync 2013 CU2. In this article we explore the configuration of Conferencing LBR and testing with Polycom CX600 phones. Below is the diagram of the test scenario:
We can think of Conferencing LBR as an enhancement to the original LBR, which means that LBR must first be properly configured. This includes the sites and subnets information, the new Voice Routing Policy and assigning it to the network site, the Trunk Configuration settings and enabling LBR on the global routing configuration. All these steps were covered in the previous article and thus will not be repeated here. Note that enabling Conferencing LBR will also apply location based routing restrictions to Consultative Call Transfers, but this requires a standalone Mediation Server to be deployed and a single Mediation Server should only be associated with a single PBX or PSTN Gateway. It's also worthwhile to note that Conferencing LBR does not apply to Dial-in conferencing and hence we should not provide conferencing access numbers in regions where LBR restrictions need to be enforced
Once LBR is configured correctly we can proceed to enable Conferencing LBR as per the TechNet guidance. We just need to enable the LBRouting application with the correct priority. We can discover the list of running apps with the Lync Management Shell cmdlet:
Get-CsServerApplication -Identity Service:Registrar:<Pool FQDN>
From the list of apps returned, the UdcAgent app will have a default priority of 2 while the DefaultRouting app has a priority of 9. We need to assign the LBRouting app a lower priority than UdcAgent but higher than DefaultRouting. So we can simply run the following cmdlet to enable the LBRouting app at a priority of 3:
New-CsServerApplication -Identity Service:Registrar:<Pool FQDN>/LBRouting -Priority 3 -Enabled $true -Critical $true -Uri http://www.microsoft.com/LCS/LBRouting
That's all that's needed to enable Conferencing LBR and we can proceed to test. We have a Lync user on CX600 (Brennon) makes a call to extension 3001 on the Asterisk PBX over the SIP Trunk that has LBR enabled. The call goes through as expected and below is the SIP Trace showing the call being routed through the Trunk to the Asterisk "PSTN Gateway":
Once LBR is configured correctly we can proceed to enable Conferencing LBR as per the TechNet guidance. We just need to enable the LBRouting application with the correct priority. We can discover the list of running apps with the Lync Management Shell cmdlet:
Get-CsServerApplication -Identity Service:Registrar:<Pool FQDN>
From the list of apps returned, the UdcAgent app will have a default priority of 2 while the DefaultRouting app has a priority of 9. We need to assign the LBRouting app a lower priority than UdcAgent but higher than DefaultRouting. So we can simply run the following cmdlet to enable the LBRouting app at a priority of 3:
New-CsServerApplication -Identity Service:Registrar:<Pool FQDN>/LBRouting -Priority 3 -Enabled $true -Critical $true -Uri http://www.microsoft.com/LCS/LBRouting
That's all that's needed to enable Conferencing LBR and we can proceed to test. We have a Lync user on CX600 (Brennon) makes a call to extension 3001 on the Asterisk PBX over the SIP Trunk that has LBR enabled. The call goes through as expected and below is the SIP Trace showing the call being routed through the Trunk to the Asterisk "PSTN Gateway":
Next, from the CX600 phone we select "Add User" to create a conference and choose the contact "Lionel" who is logged in on a PC Lync client on a different subnet. From the SIP trace we can see the conference starting up using the AVMCU:
The user Lionel receives a incoming call pop-up and when he tries to accept, he is unable to connect to the conference, while the connection between the CX600 and the PSTN user stays up. An error message appears on the PC Lync client (Lionel) showing "We couldn't connect you to the call because of regional policies":
Below is the SIP Trace that shows the LBRouting app rejecting the call:
Conclusion
In deploying Lync Enterprise Voice, in order to properly implement LBR for both P2P and Conferencing scenarios, we need to apply Lync Server 2013 CU2 and make sure we configure the components correctly. This will ensure that government telecom authority regulations are adhered to where required
In deploying Lync Enterprise Voice, in order to properly implement LBR for both P2P and Conferencing scenarios, we need to apply Lync Server 2013 CU2 and make sure we configure the components correctly. This will ensure that government telecom authority regulations are adhered to where required
RSS Feed