Call Queues using hybrid or Cloud Connector Edition PSTN numbers

Call Queues provide a simple way to distribute calls between users in Office365, in a similar fashion to the historic Response Groups in Lync/Skype. When they were first introduced by Microsoft you could only assign them service numbers provided by Microsoft, which was ok unless you were unable to port the number to Office365.

Late in 2017 it was announced that it would be possible to access call queues (and Attendants) using SIP addresses, this opened up the opportunity for using on-premises numbers via CCE or Hybrid.

If you’re using directory synchronisation after creating your call queue you’ll receive a warning to tell you that the Active Directory object is missing and are provided with a powershell command to create it. Unfortunately, this powershell command is included in a Skype for Business management tools update so is of no use if you don’t have a Skype Hybrid environment, for example if you’re using Cloud Connector Edition (CCE) appliances you’re unlikely to have the correct powershell module.

The solution, originally highlighted but now removed in the post, is to create the object manually with a upn that matches the sip address and then assign the required attributes, this can be done using the following powershell for Call Queues:

$OU = “ou=,dc=,dc=”
$displayname = “Queue Name”
$lineuri = “tel:+123456789
$guid = [guid]::NewGuid()
$sipaddress = “
$name = “{” + $guid.Guid + “}”
$objurn = “urn:trustedonlineplatformapplication:11cd3e2e-fccb-42ad-ad00-878b93575e07”
$deploc = “”
$cn = “CN=” + $name
$dn = $cn + “,” + $ou
$upn = $sipaddress.replace(“sip:”,””)
New-ADObject -type User -Path $ou -Name $name -DisplayName $displayname
Set-ADObject -Identity $dn -Add @{“msRTCSIP-ApplicationOptions”=256;”msRTCSIP-ArchivingEnabled”=0;”msRTCSIP-DeploymentLocator”=$deploc;”msRTCSIP-OptionFlags”=384;”msRTCSIP-OwnerUrn”=$objurn;”msRTCSIP-PrimaryUserAddress”=$sipaddress;”msRTCSIP-UserEnabled”=$TRUE;”UserPrincipalName”=$upn;”msRTCSIP-Line”=$lineuri}

The process is the same for auto attendants except you require the trusted application to be: “urn:trustedonlineplatformapplication:ce933385-9390-45d1-9512-c8d228074e07”

To route PSTN calls using CCE to a Call Queue requires rewriting the destination sent from the SBC to become the SIP address rather than the E.164 number as is usually expected. Upon making this change I discovered that the CCE mediation server was rejecting the call due to an unknown server error.

The solution suggested in the comments was to add ;ms-skip-rnl at the end of the translated address and sure enough this worked in my case too and inbound calls to the Call queue from the CCE succeeded,  further comments suggest that this isn’t always the case so it is worth lots of testing prior to production.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s