Automated Call Distribution for Cloud PBX

Microsoft’s Cloud PBX is well on its way to provide Office 365 customers PSTN calling ability in Skype for Business, if you’ve missed out my colleague Joel Neff has written a great blog about the start of Cloud PBX and the features it will offer the end user with call functionality. To put it very simply, they will get the same experience as a traditional Skype for Business Enterprise Voice user. This will enable you to have PSTN numbers assigned to your end users and will be sufficient for 1-1 and conferencing calling scenarios, but what happens with my public number entry points? Numbers that aren’t assigned to a user, but are really more important to get answered than Joe Bloggs desk phone.

What about call management needed for servicing business requirements through telephony?

Call Queue & Distribution

An enterprise telephony solution must have methods for routing calls not only to an individual, but a collective of individuals provided by rule based workflows, commonly known in the telephony world as Automated Call Distribution (ACD) or Hunt Groups. Cloud PBX will offer this capability that we are familiar with on-premises, allowing your main publicly listed numbers to come into a calling workflow to be processed with features such as:

  • Call Queues
    • Timeout Options (wait times)
    • Overflow Options (transfer, redirect, voicemail)
    • Max Queue Sizes (calls in waiting)
  • Agent Groups
    • Assigned users agents in Office 365 with E5
    • Assigned user agents with Enterprise Voice on-premises in a Hybrid environment
  • Distribution Methods
    • Attendant routing
    • Serial routing
    • Parallel routing
  • Toll-Free Number Services can be ported
  • Upload custom recorded greetings and menu options (wav, mp3, wma)
  • Agent Anonymity
  • Business and outside business hour times
  • No number call queues
    • Importantly having services with SIP addresses only (no PSTN number). Can be used to servicing down stream and internal call workflows

If you are familiar with Lync or Skype for Business Server on-premises these terms will be familiar to you as they are hosted on the Front End Server role.

So, what you’re really saying is there will be Response Groups and IVR’s available in the Cloud?

Yes is the answer, I’m very pleased to see that the workflow tooling that is fundamental to a enterprise voice rollout on-premises will be available in the cloud service.

Inbound Call Termination

To leverage this functionality you will need to port your service numbers to Office 365. It is my understanding that it won’t be possible in version 1 to have existing on-premises PSTN connectivity (via SIP/ISDN) with an existing deployment or Cloud Connector (CCE) and have that inbound call be serviced by an on-premises gateway to the mediation server and then routed to a workflow managed in Skype for Business Online Cloud PBX. The number will have to come directly into the Office 365 service and not through your existing deployment, this topology is commonly referred to as ‘Cloud PBX with PSTN Calling‘. I don’t see this as real issue, if you’re servicing your Cloud PBX via an on-premises gateway then you can run the workflow on the Front End server.

In my mind this really does complete the telephony platform if you looking to enable your business with E5 Cloud PBX in Office 365. Now its just a matter of time while we wait for it to be available in the datacenter that services your region. Tick Tock Microsoft.

 

 

Change ring tone behaviour with a Sonus SBC and SIP trunk provider

I recently had an issue with calls originating from a SIP trunk provider to Skype for Business Server(s) that needed to change who supplied the ring back tone. This would have been a much simpler process with ISDN, but SIP trunks are a much more involved PSTN connection. If you’re having problems with ring back this should help provide a quick troubleshooting step to expose a problem in this area. This article specifically describes what to change in Skype for Business and Sonus 1000/2000 SBC to get the desired outcome with a SIP trunk. “Ring-Ring, Ring-Ring!“.

A notable mention is that SIP Trunk Providers are not all created equal. The call setup could differ from this example.

My aim which led to this article was to change the ringtone generation from the SBC, to be supplied by the carrier. As I hunted through the SBC capture for the call setup information, I noticed the Mediation Server sends a 183 message with SDP back towards the SIP Trunk as seen in the below;

183 with SDP

I wanted to stop this behaviour of the Skype for Business Mediation Server sending 183 Session Progress messages to the carrier during inbound call setup. As this was contributing to whom was generating the ring back in my scenario. I’ll explain…

What are we looking at here?

The highlighted capture shows a 183 Progress going back towards the carrier in the setup of the call with a SDP. We are interested in this step because it has SDP which is leading towards whom/what is going to perform the ring tone generation.

What is a 183 Message?

Wiki has me covered here.

183 Session in Progress: This response may be used to send extra information for a call which is still being set up

Versus standard 180 Ringing

180 Ringing: Destination user agent received INVITE, and is alerting user of call
Thanks Wiki! Therefor the message we are looking at above has a 183 with SDP. We know two things;
  • The call is still being setup
  • and there is still codec information being arranged.

Some important details I note about SDP

How do I know a message has Session Description Protocol (SDP) information?
Content-Type: application/sdp
I know its an audio profile equalling RTP Audio Video Profile (RTP/AVP):
m=audio 30190 RTP/AVP 8 0 97
I know some of the codecs being sent for media. We are sending standard G.711 audio codecs used in PSTN calls:
G.711 A-Law 
rtpmap:8 PCMA/8000/1
G.711 µ-Law
rtpmap:0 PCMU/8000/1

So what’s going to happen?

The default behaviour for a Sonus SBC is to allow 183 Session Progress messages (why wouldn’t it!), which leads to Early Media during the initial call setup. Simply, the sequence of these messages sent to SIP Trunk with a 183 Session Progress messages with SDP information makes the SBC decide to generate the ring back internally.

Okay, we know why its happening. How can we stop this behaviour? I want to make the carrier work for their money.

I figured I could achieve this via stopping 2 things:

  1. Disable the Early Media message from the SIP Trunk Provider to the SBC and onward
  2. Remove the 183 Session Progress messages with SDP from the Mediation Server heading back to the trunk

Disable the Early Media message from the SIP Trunk Provider passing through

On the Signalling Group that connects the carrier and the SBC. Disable Early 183.

Early 183

Remove the 183 Session Progress messages with SDP from the Mediation Server

There isn’t a way to disable this natively in Lync/SFB Server so this is why we want to do it on the SBC. We are going to manipulate packets coming from the Mediation Server back to the SBC before it gets sent to the carrier.

Under the Settings Tab > Telephony Mapping Tables > Message Translation. Create Message Translation Table

Remove SDP Translation

Key notes from above:

Incoming criteria to match:

  1. Looking for 183 Progress Messages
  2. Includes SDP information

Outgoing result:

  1. Change the Message Type to 180
  2. Remove the SDP

(If I was to leave the outgoing message type as 183 but strip the SDP portion, the call will progress with no ring back and the inbound caller will experience silence throughout this time).

Apply this Message Translation to the Call Route Table from the SIP trunk. This is what makes the translation active on all proceeding inbound calls. The resulting call setup;

180 Ringing

Ring-Ring, Ring-Ring” says the carrier.

Block Inbound/Outbound Calls on Sonus SBC 1000/2000

At Kloud we had an interesting chat amongst the UC group on how to best implement call blocking/screening on a Sonus Session Border Controller 1000/2000. We proceeded to trial various methods including a well documented ‘Action Set’ scenario, which proved to be unreliable in our implementation. It was from this we looked to a simpler method that I will share with you in this article.

The process to block a call will be to use a Call Route Type with ‘deny’ action as the destination type, rather than the standard process of the destination being a FXS, FXO or SIP signalling group. Sounds simple enough.

The high level tasks are:

  • Create a Transformation Table
  • Create a Call Route Entry
  • Assign the Transformation Table to the Call Route Entry
  • Assign the Call Route Entry to a Route Table

Create a Transformation Table
Create a Transformation Table, this will be populated with either calling or called address that you wish to block based on your scenario. I’ve created a table that will match a known calling address that is to be blocked. The basis of my table logic is if a call is matched set a value to equal 1. Once the call has finished the logic in the table sequence and the value is 1 then a mandatory match is made and the table becomes true/successful.

Update: My good friend Greig and I had a conversation about this table and we agreed that you don’t need this third line entry. I had the third line to make the call logging simple when searching for the specific string for the value 2 ‘Block’. Really I could remove it.

If a Transformation Table only contains multiple entries for a single Input Field Type (e.g. Calling Number above), and all of entries have a Match Type of Optional, then the table is true if any one of the transformations succeed.

Create a Call Route Entry
This step is where the magic happens and I will admit I have never toggled this drop down menu until this process. You can create a call route destination type with a ‘deny’, generally speaking as a voice consultant we are trying to complete calls not stop. Create a Call Route Entry that has the following specific settings:

  • Transformation Table = Block Calls (table from above step)
  • Destination Type = Deny
  • Q.850 Cause Code = 21: Call Rejected

Assign the Transformation Table to a Route Table
Assign the Transformation Table to the Route Table that the call originates from:

Testing

The logic of the transformation table is as follows;

  1. The table gets processed for an inbound call session
  2. A Calling Number (tfCallingNumber) field gets matched via regex we have assigned in a line entry
    1. IF TRUE – The output field User Value 1 (tfSGUserValue1) gets updated to the value ‘1’
  3. A mandatory entry of User Value (tfSGUserValue1) equals 1 is matched in a line entry
    1. IF TRUE – The output field User Value 2 (tfUserValue2) is now ‘Block’
  4. Table is successfully matched based on mandatory assignment with User Value 1
  5. Process the session with Route Table Entry ‘Block Calls’
  6. The session will be denied with code 21 Rejected in the session info

Below is a trace of an inbound call session using the LX logging tool (above steps highlighted below)

Line 280: com.sonus.sbc.route.libcommon DEBUG (AFSessionManagementLayer.cpp:650) - SMConnection: Received REQ: id=12:47657/32769/0 session bit=1 moredata bit=0 message=MSG_CR_ROUTE
 
Line 281: com.sonus.sbc.route INFO (callrouter.cpp:2199) - Handling route request.
 
Line 282: com.sonus.sbc.route INFO (callrouter.cpp:2278) - Using table From PSTN (2) to route call.
 
Line 283: com.sonus.sbc.route INFO (callrouter.cpp:2354) - Rule Block Calls (2.1(3)) being tested for selection.
 
Line 284: com.sonus.sbc.route DEBUG (translation.cpp:1416) - Performing OPTIONAL transformation using entry User Value 0 (9.1(3)).
 
Line 285: com.sonus.sbc.route DEBUG (translation.cpp:704) - Successful regex match of "tfCallingNumber" field for "(.*)" (updated "(.*)") with input of "411111111"
 
Line 286: com.sonus.sbc.route DEBUG (translation.cpp:749) - Regex replacement output of "tfSGUserValue1" field is "0"
 
Line 287: com.sonus.sbc.route DEBUG (translation.cpp:1416) - Performing OPTIONAL transformation using entry Block ID (9.2(1)).
 
Line 288: com.sonus.sbc.route DEBUG (translation.cpp:704) - Successful regex match of "tfCallingNumber" field for "411111111" (updated "411111111") with input of "411111111"
 
Line 289: com.sonus.sbc.route DEBUG (translation.cpp:749) - Regex replacement output of "tfUserValue1" field is "1"
 
Line 290: com.sonus.sbc.route DEBUG (translation.cpp:1416) - Performing OPTIONAL transformation using entry Block ID (9.3(2)).
 
Line 291: com.sonus.sbc.route DEBUG (translation.cpp:700) - Failed regex match of "tfCallingNumber" field for "881111111" (updated "881111111") with input of "411111111"
 
Line 292: com.sonus.sbc.route DEBUG (translation.cpp:1416) - Performing MANDATORY transformation using entry User Value 1 True (9.4(4)).
 
Line 293: com.sonus.sbc.route DEBUG (translation.cpp:704) - Successful regex match of "tfUserValue1" field for "1" (updated "1") with input of "1"
 
Line 294: com.sonus.sbc.route DEBUG (translation.cpp:749) - Regex replacement output of "tfUserValue2" field is "Block"
 
Line 295: com.sonus.sbc.route INFO (translation.cpp:1493) - Transformation table(Block Calls:9) is a SUCCESS
 
Line 296: com.sonus.sbc.route INFO (callrouter.cpp:2412) - Successful route request with entry Block Calls (2.1(3))
 
Line 297: com.sonus.sbc.route.libcommon DEBUG (AFSessionManagementLayer.cpp:1984) - Sending RSP: state=1 session id=12:47657/32769/0 message=MSG_CR_ROUTE_ACK msg len=557 end session=0 sessions={lvl=1}<parent>0x11000023|0x16721c-[this]0x11013650|0x12f140. Process ID 5912
 
Line 305: com.sonus.sbc.route.libcommon DEBUG (AFSessionManagementLayer.cpp:1016) - SMConnection (0x167208): Received INFO: session id=12:47657/0/0 message=MSG_CR_CALLREPORT end session=1, moredata=0

Job Done

This is a very simple approach to an annoyance that we all could face at some stage. I’m sure there are many other ways to implement a call scenario like this, but I do enjoy the beauty in this simplicity. By using the standard call route logic of the Sonus we haven’t introduced anything new to the call flow procedure. I’d estimate that a implementation like above would take about 10-15 minutes once you know what you would like to block.

Polycom VVX Phone – Call Transfer Options

During the pilot phase of a Skype for Business Enterprise Voice rollout it is standard practice to get some IP handsets in and do testing on functionality. Its important to try match feature sets between old and new handset functionality to make sure adoption of the new handset is simple.

How did you do it before? Here is how you do it now.

The longest conversation I have with this phase of testing is which transfer type will the business adopt as a default for all phones. There are 3 types of transfer that I like to discuss in Skype for Business;

  1. Blind Transfer – Transfer happens immediately
  2. Consultative Transfer – Transfer happens after a consult with the transferring recipient
  3. Safe Transfer – Returns the call on a blind transfer if the recipient doesn’t answer

The Polycom VVX Business Media phone range is what I prefer to deploy in organisations adopting Skype for Business. Polycom offer flexibility in how you configure the phone. This is done via in-band provisioning process built in by Polycom for a configuration file download. The configuration file allows for a default transfer type to be associated with the transfer soft and hard key in a standard call scenario. Two options are available;

call.DefaultTransferType="Blind"
call.DefaultTransferType="Consultative"

Having a singular transfer type isn’t always optimal, especially when in conversations with workers that do high call volume for a public interfacing number i.e. Receptionist/Admin workers. These users quite often will give me the response when asked the question about which transfer they use in their job pre Skype for Business;

“Sometimes I like blind and other times I like consultative, it all depends on the calling party and how comfortable I feel with the requester in each call”.

This seems like a fair statement but not easily achieved with a VVX phone. I would tend towards default being blind and if the user wanted to do an ad-hoc consultative we would say to put the calling party on hold while you liased with the destination party and stich the call together after. Not perfect. Another method is to create a different configuration file for special cases where the user needed consultative as their default. Once again, not perfect.

My idea was to make soft keys on the ‘in call’ window on the phone for both blind and consultative transfer in my customized configuration file. This is achievable but I never sat down for long enough to pilot the process in its entirety. Older versions of the firmware I believe had consultative as default, during a call you had the option of transferring using the Blind method via a softkey but it wasn’t always on the first page of soft keys. Users wouldn’t always have the time or patience to go find the Blind key on the second page under the ‘more’ button.

But alas, Polycom have come to the rescue with UC 5.3.+ software now available for the VVX range that includes the simplest change in detail of the user guide that got me excited about an addition in functionality. User Guide (Page 46 or below)

To transfer a call:

  1. During a call, do one of the following
    1. Press Transfer to use the default transfer type
    2. Press and hold Transfer and select a transfer type.
  2. Dial a number or choose a contact from the call list or directory.
    1. If the transfer type is set to Blind, the call is transferred immediately.
  3. If the transfer type is set to Consultative, press Transfer after speaking with your contact.

Well there you have it, a very simple method of selecting a transfer method during a call. In some ways almost comical that I never once tried to hold down the transfer key. Now I do it by design. This is definetly something I’ve updated in my ‘how-to’ guides for end users adoption as it was the most common question I get in regards to VVX IP phones.

Skype for Business Online to On-Premises Migration

Okay guys – you’ve been told “lets move everyone back from the cloud! We need Enterprise Voice for our users” This will go against most Microsoft sales materials as we should be looking towards cloud.

If you are part of an organisation that has been birthed out of Skype for Business Online (SFBO) as part of your Office 365 subscription, it would make sense that you would have never had on-premises Lync or SFB servers in your Active Directory domain. Very little configuration is needed in SFBO and a busy administrators would have loved enabling the license SKU for SFBO for each users and then wiped their hands of it. Its just that easy, enable and forget.

The main limitation around SFBO is the need for an IP-PBX and/or PSTN connectivity. The time may have come for your organisation to leverage your Microsoft agreement even further and look to your existing technology/application catalogue and see that Skype for Business can fill the requirements of your aging PBX. This trigger point is usually when the PBX asset has reached capacity and there is a cost trade off;

  • Throw more money at the dusty old PBX box for extra expanision cards and possibly cabling to terminal
  • Spend the money to start new in the world of VOIP, but look to an existing technology that can provide this functionality (and hopefully more) before looking elsewhere

Telephones have been around for a long time, its nothing new. Picking up, making, transferring calls is all pretty standard stuff we have been doing for few decades now. If I’m going to invest money in something I should be asking for more! more! more! How do I make sure that my choice keeps my organisation staying relevant in the way it communicates for the next chapter?

Hello Skype for Business as PBX replacement.

That’s enough of ramble. You have come here to understand the process of moving users back from the cloud because there is less documented about this procedure than too the cloud.

Current Environment

  • On-premises Domain Services
  • DirSync/AADSync Server
  • Office 365 Tenant
    • Skype for Business Online SKU enabled
  • DNS for my domain.com.au
    • Lyncdiscover.domain.com CNAME webdir.online.lync.com
    • SIP.domain.com. CNAME sipdir.online.lync.com
    • _sipfederationtls._tcp.domain.com SERVICE sipfed.online.lync.com
    • _sip._tls.domain.com SERVICE sipdir.online.lync.com

Current_Environment

In this scenario we will look at the steps needed to specifically enable Hybrid and move users back to on-premises.

  1. Add on-premises infrastructure
  2. Connect Hybrid SFB with Office 365 and on-premises
  3. Move Enterprise Voice users back

Add On-premises Infrastructure

  • Add your Front End, Edge and Reverse Proxy Infrastructure
    1. Build the Servers as per TechNet, but leave the SIP Address’s DNS zones to not effect internal and external clients just yet
    2. All discover records should still point to Microsoft (sipdir, webdir etc)
  • Confiure your Edge and Reverse Proxy with Public Certificates
    1. Test the port authentication as best you can;
      1. Telnet to Edge Ports
      2. Test Reverse Proxy URLs
      3. Remote Connectivity Analyzer for Edge
  • Configure Edge for Federation
    1. Assign your Edge as the Federation Route in your Topology Builder
    2. Configure Edge Specific Configuration
Set-CSAccessEdgeConfiguration -AllowOutsideUsers 1 -AllowFederatedUsers 1 -UseDnsSrvRouting -EnablePartnerDiscovery $true
  • Recreate Allowed Federated Domains in On-premises
    1. If you do a get-csalloweddomain in Office 365 you may not get all the correct information specific for your tenant back to you.
      1. If you have federation with only allowed/block lists, you may need to recreate these as there is no nice way of piping the cmdlets from ‘get’ to ‘new’.
      2. Allow open federation to accommodate for all traffic is the simplist approach for migration
  • Set the Global Remote Access and Federation User Policy to Allow
Get-CsExternalAccessPolicy -Identity Global | Set-CsExternalAccessPolicy -EnableFederationAccess $True -EnableOutsideAccess $True

 

Connect Hybrid Skype for Business

  • Remove existing Lync/Skype for Business Hosting Rule
Get-CSHostingProvider -Identity <SFB/Lync Online> | Remove-CSHostingProvider
  • Recreate the Provider with Hybrid Specific Configuration
New-CSHostingProvider -Identity SFBOnline -ProxyFqdn "sipfed.online.lync.com" -Enabled $true -EnabledSharedAddressSpace $true -HostsOCSUsers $true -VerificationLevel UseSourceVerification -IsLocal $false -AutodiscoverUrl https://webdir.online.lync.com/Autodiscover/AutodiscoverService.svc/root
  • Update External/Public DNS Records
    1. Remember that only updating external DNS records means that your internal users can functions ‘as-is’ until your happy with the progress
      1. Edge Names (SIP Access/Web Conference/ AV  FQDNs)
      2. External Web Services FQDN
      3. Dialin FQDN
      4. Meeting FQDN
      5. LyncDiscover FQDN
      6. SRV _sipfederationtls._tcp.domain.com
      7. SRV _sip._tls.domain.com
    2. Remote users that aren’t previously authenticated could have an issue logging in at the time of the change

Test Process

Join On-premises Pilot User with Online Account

This makes your on-premises deployment aware of active directory accounts that are currently cloud enabled.

  • Run the following cmdlet in SFB Management Shell connected to on-premises servers to test a user
Enable-CsUser -Identity &lt;accountname&gt; -SipAddress "sip:<sipaddress>" -HostingProviderProxyFqdn "sipfed.online.lync.com" -verbose
  • Synchronise AADSync/DirSync
    1. Login to Directory Sync Server
    2. Run >  Delta Import And Delta Sync on the Active Directory Connector
    3. You will see an update count that includes your object

Move a Pilot Users back

This step will actually move the user from SFB Online back to your on-premises pool with contact lists intact. This is initiated from the on-premises server and will need authentication for the Office 365 tenant to perfom the task.

  • Run the following cmdlet in Powershell connected to both on-premises and online sessions
Import-Module LyncOnlineConnector
$credential = Get-Credential
$session = New-CsOnlineSession -Credential $credential
Import-PSSession $session -AllowClobber
  • Get the Online Admin URL for your tenant
    1. Log into Office 365 Portal
    2. Check the URL presented in the address bar, will be admin0x. Where x = a letter specific for you
  • Move the User back
Move-CsUser -Identity <UPN> -Target <FE Pool Name> -Credential $cred -HostedMigrationOverrideURL https://admin0f.online.lync.com/HostedMigration/hostedmigrationservice.svc

Enable All Users

If the above to Pilot Tests worked we need to scale up our migration batches. We need to mass produce the following cmdlet in SFB Management Shell connecting on-premises user accounts to the corresponding online account;

Enable-CsUser -Identity <accountname> -SipAddress "sip:&lt;sipaddress&gt;" -HostingProviderProxyFqdn "sipfed.online.lync.com" -verbose

To do this practically I used the UPN value which I knew that would resolve to the correct users values in on-premises and Office 365 because they are synced from the source. I also could then understand the logic that the users UPN is in this case the primary SMTP/Mail value and therefor matching SIP Address for Skype for Business that I needed.

  • Get all the Office 365 users that are enabled for Skype for Business
Get-CSOnlineUser | ? {$_.SipAddress -notlike $Null} | Select SipAddress, DisplayName | Export-CSV -Path C:\temp\OnlineUsers.csv -NoTypeInformation
  1. This will give you a list of ‘real’ SFBO users that are licensed but are also registered SFB logins
  2. Review the list for deleted users that haven’t been removed properly, there SIPAddress will include GUID style login, these lines can be removed as we do not wish to migrate them.

Lets leverage this list of known online users and enable their joining in on-premises with a ForEach loop example below;


$Users = Import-Csv C:\updates\OnlineUsers.csv

ForEach($User in $Users)
{
$SipAddress = $user.sipaddress
$UPN = $SipAddress.replace("sip:", "")
$Enable = Enable-CsUser -Identity $UPN -SipAddress $SipAddress -HostingProviderProxyFqdn "sipfed.online.lync.com"
}
  • Update Azure Active Directory of the changes by another AADSync/DirSync > Delta Import & Delta Sync
  • Update Internal DNS to point all associated SFB records to on-premises Skype for Business Server(s)
    1. SRV _sipinternaltls._tcp.domain.com.au
    2. Lyncdiscoverinternal.domain.com.au
    3. SIP.domain.com.au
  • Add Additional A Records
    1. Meet.domain.com.au
    2. Dialin.domain.com.au
    3. Pool Name
    4. SFB Web Service URL Names
    5. Admin URL

Visual Indication of Success

Log into your on-premises SFB Admin Control Panel and run a blank user search to discover all users. Noticed the ‘Homed’ field should say ‘SFBOnline’ 

Move All Users

Leveraging the same list of users, run the move cmdlet like the example;


ForEach($User in $Users)
{

$Displname = $user.displayname
$SipAddress = $user.sipaddress
$UPN = $SipAddress.replace("sip:", "")
$Move = Move-CsUser -Identity $UPN -Target &amp;amp;amp;amp;amp;amp;lt;FE Pool Name&amp;amp;amp;amp;amp;amp;gt; -Credential $credential -HostedMigrationOverrideURL https://admin0f.online.lync.com/HostedMigration/hostedmigrationservice.svc -Confirm:$false
if($Move -eq $False)
{
Write-host "User $SipAddress didn't move!!"
}
}

Status

To get visual status while you move all the users, log into your Office 365 Skype for Business Administration Portal and view the details. Continually refresh the page to see the value for “users synced and homed online” go down as each user becomes enabled on-premises.

SFB_User_Stats

 

 

 

Log into your on-premises SFB Admin Control Panel and run a blank user search with a additional filter for Homed or Registrar Pool / is equal to / <registrar server name>.

Client Experience

The client should be unknowning of your changes being made in Office 365 and on-premises until you perform the move-csuser request for their account. During this period a redirect message will be sent to the client with a new registrar server FQDN and a automated logout and login will happen. If the user doesn’t have their client in the forground of their desktop, then this will happen silently in the background. The redirect in my move request had the users logged out and back in within about 1-2 seconds.

Lync IP Phones – VVX Media Phone Alternative

=========================================================
Updated 16 July 2014: The new 5.1.1b VVX Firmware has been released by Polycom and can be found here
=========================================================

The Polycom VVX Media Phones offer an additional option for Lync Enterprise Voice customers over the traditional consumer choice of ‘Optimized for Lync’ Aries phones running Lync Phone Edition firmware. I recently came back in touch with these devices and this blog post is some of my latest observations.

Microsoft extended support for the Aries phone firmware till 2023 which shows Microsoft’s commitment to traditional telephony devices and to vendors of Lync IP phones continuing sales for some time into the future. The firmware has certainly been refined since its introduction with Lync Server 2010, but the UX has had minimal change or needed any feature enhancement. If you’re looking for an alternative to the Aries phone then Polycom’s VVX Media Phone series is it. The VVX phones have to constantly play catch up to get to firmware feature parity with its purpose built brother. It can offer a different look and feel for customers looking for something closer to an ‘all-in-one’ media phone. Before you go and jump in two feet forward it’s hopefully worth noting a few things from this post.

Basic Functionality

In my view, Polycom have worked tirelessly to release feature updates to these phones on a consistent basis, but we must remember that they had to start from scratch and turn this Polycom SIP generic handset into an operating Lync handset. With the recent releases of Polycom’s UCS 5.0.x versions of firmware they have pushed out some functionality that the phone couldn’t have lived without. Such as –

  • Enhanced Presence – 11/04/2014
  • BToE (Better Together over Ethernet) – 6/9/2013
  • Lync Address Book Web Query – 6/9/2013
  • Call Park – 6/9/2013

These all sound like great features but something the Aries phones have had since instalment of Lync Phone Edition in Lync Server 2010.

Environment Readiness

The VVX devices need some changes and updates to get them ready for your Lync infrastructure which are as follows –

  1. DHCP Scope Updates
  2. FTP Server Installation
  3. Firmware Upgrades
  4. Configuration File Customization

DHCP

The VVX phones look for standard DHCP scope option to find their firmware and configuration settings on each boot. DHCP Scope Option 160 will need to be configured in phone IP ranges:

FTP Server

Create a FTP Server accessible from the phone’s IP subnets. Putting it on a Front End server is probably the easiest. This FTP site is used to make available the firmware and configuration that we specified above in DHCP. Configure a FTP User as follows –

Username: PlycmSpIp

Password: PlycmSpIp

Point the home directory of the group to the root directory of your firmware folder.

Firmware Updates

Firmware can come in two types –

  • Sip.ld (Older versions are for FTP download installation)

     

  • Cab files (Lync server device updates)

     

The phones I received came with old 4.x version (sip.ld) of the firmware which will require me to step up to release 5.0.2 (sip.ld) via the FTP server and from this release I could then leverage the included Lync device updates feature on the phone to get to the current ‘N’ release.

Configuration File Customization

As this is a phone that can supports multiple IP-PBX vendors, you will need to pull configuration files down to the phones to make them Lync aware and behave properly with your Lync Infrastructure. The configuration file can be edited via a XML editor and placed on the root directory of the FTP Server ready for phone provisioning. The phones will need to be configured for things like –

  • Setting device profile to Lync
  • Date and Time zone
  • Power saving settings
  • BToE enabled/disabled
  • Soft key Arrangement
  • Tone configuration
  • And maybe disabling some things that aren’t ‘Lync’ applicable

The configuration files are –

  • 000000000000.cfg (Master configuration file)
  • Shared.cfg (Settings file we define)

Find out about configurable line objects to update in the Shared.cfg here from the Polycom UC Administrator’s Guide.

Between the multiple steps to get to current firmware release and the fine-tuning needed of the configuration files, expect a few days to disappear before you’re happy with how these phones operate.

The high level process I performed is below –

New Features

With the upcoming release of UCS 5.1.x Polycom offer connectivity again with their Colour Expansion Module (previously worked on 4.1.6.4835 only) this offers an additional 84 speed dials/favourites to the Lync interface on the phone. Don’t be fooled, the expansion module isn’t a replacement for the reception style attendant. Lync only needs a single incoming line on the phone and the expansion module won’t display the incoming call queue on the respective line or call park, so it’s more of an extensive list of contacts for calling.

To configure the expansion module to show Lync contacts you must add users to your favourite’s list in the soft client. The phone has 15 (16-1 for line display) grid positions to fill before it will move across to the expansion module. Which means that your favourites list could be getting extensive before one pop’s up on the other side. You may want to move the start of your Lync contacts to be line 17 which isn’t a bad idea if you have any custom branding for your phone background. This can be done like below –

Note that ‘lineKey.reassignment.enabled=1‘ must be set before your custom layout will take effect. Have fun as you copy/paste down to ‘lineKey.100.category‘ to make sure you have categories set to the end of the third page of the expansion module. If you have deployed a mix of VVX phones with and without expansion modules you will have to create custom files for each device that needs it. The VVX phones will look for a master configuration file in the form of their mac address before using the default 000000000000.cfg. Specifying an additional configuration file can mean that the phone gets the ‘shared.cfg‘ with the addition of the expansion module layout like below –

What’s the Value Add for Lync 2013?

The phones premium feature would look to be video calling but currently they don’t share a common codec with Lync 2013. This is still planned for future releases but not for UCS 5.1.0 as far as I know.

Currently attempting a standard SIP call on a VVX600 to another Lync user, the handset will try to negotiate both audio and video media streams which is its default behaviour. The destination recipient will receive a toast pop up for a video call invite like below –

This experience can be confusing to the users as the intended media delivery isn’t achieved. Therefor I disabled video which can only be done via the phones configuration file. Thankfully I guessed right on the line entry –

video.enable=”0″

The result is the incoming SIP INVITE wont attempt to negotiate a video codec anymore and the toast pop up will reflect this as seen below –

I’d like to add while some VVX phones can offer a built-in camera, Aries devices with USB ‘Better Together’ leverage your PC/Laptop webcam for video. So in this situation it’s really a choice between starting/receiving a video call and staring at your IP phone handset for the conversation or looking at your PC. Include some other collaboration features into that conversation like desktop/application sharing and having your eye’s firmly planted on the PC screen for both could be of more benefit. Once Polycom include the VVX 1500 my opinion may change with its large display, the device may be useful for VIP users or small meeting room devices.

Overall

If you believe I’m telling you stay away from the VVX phones, I’m not. Polycom’s commitment to these phones will mean soon they could far excel their Aries brothers. What I am hinting at is plan your deployments carefully. These devices take some configuration and strategic planning before implementation. An Aries phone can almost be unboxed and ‘desk dropped’ the same day. It’s best to keep track of the current firmware release notes that Polycom provide for UCS firmware before purchase to see what features are currently available and what is still in the pipeline. You may find they meet your requirements or if not, keep a closer eye on the support site for the next update. Polycom’s vested interested in Microsoft Lync will mean these handsets will probably offer more than the Aries can deliver in the distant future. Whatever you decide for your handsets, Polycom can easily become the vendor that provides your whole unified communication range with Aries and VVX handsets, conferencing units, telepresence and round table cameras that increase your collaboration experience with Microsoft Lync.