Surface Hub – Skype for Business Login Failure

Excitement has grown around the Kloud office of late as each state waits with anticipation of a Surface Hub arriving to connect to our Skype for Business environment. The 84 inch Surface Hub destined for our Adelaide Boardroom which I nicknamed ‘Godzilla’ has had only one problem since installation, it fails to login to Skype for Business. Which makes this device go from a high end meeting room endpoint to a what I could only say is a giant tablet for games of tick tac toe, therefore this became my problem rather quickly. Everything seemed so pleasant following the initial steps from the out of box experience (OOBE). The Hub asked me questions, I responded politely with what I thought were all the right answers with a big smile on my face.

You could feel the electricity in the air.

This first date was going pretty smoothly I thought. Maybe the Hub caught wind of the nickname I was calling it around the water cooler in the office, because after our first date and the Hub launched into its standard meeting experience, an error was presented. Skype for Business would timeout and eventually say ‘login failure‘.

Oh dear!

A quick look around the Hub’s administrative settings I could see that the account configured for mail was saying ‘synced‘ and I could verify this with a quick white board and ‘send to email‘, which arrived promptly to my inbox. Furthermore with my laptop in toe I could successfully login to a Skype for Business soft client with the Hub’s credentials. What is unique to the Hub client is that its does some extra validation on the account over other SFB clients that I’m familiar with. I’ll explain..

The device account I had for the Hub was in the ‘hub@domain.com.au‘ SIP domain, but the Active Directory (AD) FQDN of the connected servers was different. In Kloud’s circumstance I didn’t think much of this issue as our Hub was logging in over an internet connection through the Edge Server that has an access FQDN of sip.domain.com.auwhich to me were the same domain. A quick login to the Edge Server logs didn’t present many results of an attempt of SIP from hub@domain.com.au. The Hub was using autodiscover to kick off the process of login to Lyncdiscover.domain.com.au I knew that much and must be failing. Using the Remote Connectivity Analyser (RCA) I could verify the login process for the account was successful and green ticks appeared against all lines. I thought to myself

What have I said to Godzilla to hurts its feeling so badly? That it deliberately wants to make my life hard

If you run a Skype for Business Autodiscover Web Service test on https://testconnectivity.microsoft.com the following process is attempted to the Autodiscover Web Service URL:

https://lyncdiscover.domain.com.au/Autodiscover/AutodiscoverService.svc/root.

  1. Attempting to resolve the host name lyncdiscover.domain.com.au in DNS.
  2. Testing TCP port 443 on host lyncdiscover.domain.com.au to ensure it’s listening and open
  3. Testing the SSL certificate to make sure it’s valid
  4. Host name lyncdiscover.domain.com.au was found in the Certificate Subject Alternative Name entry
  5. Testing HTTPS authentication methods for URL https://lyncdiscover.domain.com.au/Autodiscover/AutodiscoverService.svc/root/user.
    HTTP authentication methods successful.
  6. Testing HTTP content for URL https://lyncdiscover.domain.com.au/?sipuri=hub@domain.com.au has token=”User”.
  7. Found as expected token=”User” and confirmed anonymous access not allowed.
    HTTP Response Headers:
    Connection: Keep-Alive
    Pragma: no-cache
    X-MS-Server-Fqdn: AUSFBFE01.domain.local
    X-MS-Correlation-Id: 2147484240
    client-request-id: b6d465f4-f318-485e-8d3e-06b32524fd3d
    X-Content-Type-Options: nosniff
    Content-Length: 1047
    Cache-Control: no-cache
    Content-Type: application/vnd.microsoft.rtc.autodiscover+xml; v=1
    Date: Sat, 25 Mar 2017 11:49:23 GMT
    Expires: -1
    Elapsed Time: 127 ms.

In the above web request Lyncdiscover told the Hub that the registrar server its connecting to has a X-MS-Server-Fqdn with domain.local, which it did not automatically trust. Microsoft do state this in an article:

  • Multiple DNS suffixes – When your Skype for Business infrastructure has disjointed namespaces such that one or more servers have a DNS suffix that doesn’t match the suffix of the sign-in address (SIP) for Skype for Business.

followed by examples:

Tip

You can type multiple domain names, separated by commas.
For example: lync.com, outlook.com, lync.glbdns.microsoft.com

For some reason it didn’t click with me as these are all domains used for Office 365 that are publicly accessible DNS zones. My logic was that we were connecting via edge ‘sip.domain.com.au‘ and I had a ‘hub@domain.com.au‘ I wouldn’t need anything added because my SIP Address = Edge FQDN domain, plus its bound to matching SAN entries in a publicly signed certificate. Kloud isn’t a hosting provider that services thousands of SIP domains like Office 365 which it cannot have in its edge certificate as Microsoft aren’t authoritative for. This is why Office 365 get customers to add CNAME’s to their endpoints and perform 80 to 443 port wizardry where possible, allowing clients to bind SSL to correct Microsoft service names.

What Microsoft are trying to say is

If your SFB SIP domain doesn’t match your Active Directory infrastructure domain name that your SFB servers are joined to, you need to add via the following

Add ‘domain.local‘ into the Hub via Settings -> This Device -> Calling

Lastly, this doesn’t matter if your logging the Hub in via the internet or internal LAN, you will get this mismatch with all domains that were created not matching the primary SIP/SMTP domain I would suggest.  Additionally, if your logging your Hub in via LAN you will most probably need to bundle up some certificates as the Hub will not trust your certificate authority used for signing Front End certificates that would include domain.local SANs which Public Certificate Authorities reject.

You’ll be happy to note that Godzilla and I are now on speaking terms again. We quite regularly have catch ups via Skype with colleagues and its all smiles once again.

A Closer Look at Amazon Chime

In news this quarter AWS have released a web conferencing cloud service to their existing ‘Business Productivity‘ services which already includes Amazon WorkDocs and Amazon WorkMail. So my thought was to help you gauge where this sits in relation to Skype for Business. I don’t want to put this into a Microsoft versus Amazon review but I do want you to understand the product names that ‘somewhat’ align with each other.

Exchange = WorkMail

SharePoint/OneDrive for Business  =  WorkDocs

Skype for Business  = Chime

The Microsoft products are reasonably well known in the world so I’ll give you a quick one liner about the Amazons products:

WorkMail “Hosted Email”

WorkDocs “Hosted files accessible via web, PC, mobile devices with editing and sharing capability”

So what is Chime?

Chime isn’t exactly a one-to-one feature set for Skype for Business so be wary of articles conveying this sentiment as they haven’t really done their homework. Chime can be called either a web meeting, online meeting, or online video conferencing platform. Unlike Skype for Business, Chime is not a PBX replacement. So what does it offer?

  • Presence
  • 1-1 and group IM
  • Persistent chat / chat rooms
  • Transfer files
  • Group HD video calling
  • Schedule meetings using Outlook or Google calendar
  • Join meeting from desktop or browser
  • Join meeting anonymously
  • Meeting controls for presenter
  • Desktop sharing
  • Remote desktop control
  • Record audio and video of meetings
  • Allow participants to dial-in with no Chime client (PSTN conferencing bridge)
  • Enable legacy H.323 endpoints to join meetings (H.323 bridge)
  • Customisable / personalised meeting space URL

The cloud hosted based products that I see are similar to Chime are WebEx, Google Hangouts, GoToMeeting and ReadyTalk to name just a few. As here at Kloud we are Microsoft Gold Partners and have a Unified Communication team that deliver Skype for Business solutions and not the other products I have previously mentioned, I will tell you a few things that differentiate SFB from Chime.

  • Direct Inward Dial (DID) user assignment
  • Call forwarding and voicemail
  • Automated Call Distribution (ACD)
  • Outbound PSTN dialling and route based on policy assignment
  • Integrated Voice Recording (IVR)
  • Hunt Groups / Call Pickup Groups
  • Shared Line Apperance
  • SIP IP-Phone compatibility
  • Attendant / Reception call pickup
  • On-premises, hybrid and hosted deployment models

Basically all things that replace a PBX Solution Skype for Business will do. Now this isn’t a cheap shot at Amazon, cause that isn’t where they are positioning their product. What I’ve hoped to have done is clarify any misconception about where the product sits in the market and how it relates to features in a well known product like Microsoft Skype for Business.

For the price that Amazon are offering Chime for in the online meeting market it is very competitive against some other hosted products. Their ‘rolls-royce’ plan is simply purchased for $15 USD per user per month. If you’re not invested in the Office 365 E3/E5 license ecosystem and you need a online meeting platform at a low cost, then Chime might be right for you. Amazon offer a 30 day free trial for free that is a great way to test it out.

https://chime.aws

 

Skype for Business Mac Client – General Availability

I currently run a MacBook Pro for my daily driver, it’s the ‘spice of life’ I say! A MacBook Pro, a Google Pixel phone and the Microsoft Office 365 collaboration suite is what makes up my toolset. Now more then ever collaboration and data is becoming more accessible via a device flavour that you prefer. Running Mac OSX while working with the Microsoft stack presents two issues I’ve had to endure to this point as an end user and adminstrator:

  1. I want to leverage the full capability of Kloud’s Skype for Business platform while in OSX
  2. I want to execute PowerShell CLI natively in OSX

I’ve marked October 26th in my calendar as the day where I get to put a line through one of my wish list items. Skype for Business Mac client has become generally available and free to download here. I noticed while I can download the client from Microsoft.com, I’m yet to have it available to me in the Office 365 portal where I’m still offered my very old friend Lync 2011 to install.

This software isn’t all that new to me personally, I’ve been on versions of the preview client for a while now with mixed emotions. That being said, that’s what a preview program is all about! For those wondering what you will get with this first release (16.0.0.3638) here is a closer look.

Installation

The installation package will ask you to shutdown Safari and once you have hit ‘next‘  or ‘continue‘ the correct amount of times you will be presented with the login splash screen.

office-mac-2

Once you have logged in successfully with your credentials you will receive the ‘run-once‘ welcome wizard. Which probably gives away most of the capability you will have so I won’t double up.

It’s not my intention to turn this into one of those ‘unboxing videos‘ you see on youtube, but here are some key features that I feel you will need to know about since either using the preview or being a first time consumer of Skype for Business on Mac.

All the normal and expected features are here:

  • Instant Message
  • Tabbed Conversations
  • Audio Call
  • Video Call
  • Multi-Party Instant Message, Audio and Video
  • Share Desktops
  • Join Meetings
  • Dial PSTN Numbers
  • Receive PSTN Calls
  • Listen to Voicemails
  • View conversation, IM and call history

Preview to General Availability

Voice users, you get the very important advanced calling options in preferences which wasn’t in the preview. This includes:

  • Call Forwarding Behaviour
  • Dialin Conferencing Pin/Settings Link
  • Voicemail Greeting Option

office-mac-pref-calls

A dial pad and/or a field to paste a number prior to dialling in the GUI was missing, not any more:

office-mac-dialpad

When you click to join a Skype for Business meeting from a URL in a calendar item you will be prompted to trust the ‘Skype for Business Meeting Join Plug-in‘ allowing native meeting join into the Skype for Business application from a Hyperlink:

office-mac-meeting-plugin

What things are missing? And,….will I really need them?

I’ll let you be the judge if these are things that you just can’t live without. Here’s a few notable mentions I can see:

  1. Team Call / Delegates options (was available in Lync 2011)
  2. Audio Test Call Service
  3. Ability to share desktop while in 1-1 window (was available in Lync 2011)
    1. Workaround: You must ‘Meet Now’ and invite the user, desktop share is then available
  4. Ability to send files in 1-1 or meeting windows (was available in Lync 2011)
  5. Unanswered call delay and procedure options (Call timer and forward)
  6. Meeting Recording settings

Final thoughts

At the end of the day if its stable, its a win. The preview was problematic for me, with breaks in network connection and re-connection being my main issue. Microsoft have advised that there is server cumulative updates to install to the backend for best compatibility which could aid experience. From a client perspective they advise that you uninstall all previous clients (Lync 2011 or Skype for Business Preview). All these ‘need to know‘ fine print can be found in the ‘Details‘ section of the client download.

Happy downloading.

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.

Office 365 – AADSTS50008: SAML token is invalid

If you’ve made it to this post because you are troubleshooting your AD FS sign in with Office 365 due to “AADSTS50008: SAML token is invalid” I still recommend you do all the standard troubleshooting steps provided in this article below the image:

AADSTS50008https://support.microsoft.com/en-us/kb/3015526

Generally speaking, if you’re getting issued a token from your AD FS server and Microsoft’s STS is stopping you from logging in, it would be because of your token signing certificate:

Has your Token-Signing Certificate changed since you last told Microsoft?

 

It’s never a bad idea to re-run the following:

Update-MsolFederatedDomain -DomainName [verified domain]

Executing this MSOL cmdlet will get Microsoft’s STS service to check your Metadata, which in turn will update any certificate changes you may have made. If you’re really clever you can go to your WS-Federation Metadata and check what you’re telling the world is your public token signing certificate.

  1. Navigate to https://<AD FS Namespace>.com.au/federationmetadata/2007-06/federationmetadata.xml in Internet Explorer.
  2. Search for KeyDescriptor use=”signing” in the metadata document.
  3. If you copy the raw certificate data from <X509Certificate> into a text file and save with extension ‘cer‘ you can validate it matches what’s in your AD FS console > Service > Certificates > Token-Signing

Good, we have that under control. I experienced an issue the other day where I still got the error post running this cmdlet and performing the above nifty check….. Head scratches. Firstly, I know that my AD FS services has processed my sign on attempt and given me the required information to take to Office 365 and log in. Secondly, I know that my signing certificate is correct. Still the error remains;

We received a bad request.
Additional technical information:
Correlation ID: 82121251-3634-4afb-8014-fb5298d6f2c9
Timestamp: 2016-03-04 00:25:35Z
AADSTS50008: SAML token is invalid

My issue was a little unique but worth a notable mention on the internet. In my scenario, If I left my browser page up with the error shown above for a length of time, suddenly if my browser refreshed I would get dropped into whatever it was I was trying to authenticate to. So my authentication was successful with Microsoft after a point in time. I highlight those words cause I literally had to say them out loud to myself before I found the fix. Looking at the AD FS servers where my token is issued from, I took a quick look at the time. I then took a look at the time on the AD workstation I was trying from, they both seemed to be in synchronisation with each other.  What about from my BYOD Surface that I use at Kloud which uses a internet time source?

Great Scott! 7 minutes difference!

My token was being accepted by Office 365, but only once Microsoft had caught up to the future from which I had came from. This isn’t unreasonable from Microsoft to not allow my issued token until that time had actually happened in Microsoft cloud land. This wasn’t an issue that showed its face as easily with internal applications as all domain controllers and workstations were following orders from the time source in the domain. The problem was that the domain couldn’t synchronise with a internet time source at the time master. So it was slowly but surely sneaking ahead. Once we had come back from the future, the issue with ‘AADSTS50008: SAML token is invalid’ was resolved and authentication was instantaneous on the first attempt once again.

I don’t want to put the fear of the ‘internet time gods’ on you, I believe that there is some kind of threshold that Microsoft will allow. Just not in 10 minutes time or maybe tomorrow, in the future.  Possibly the magic number for token timestamp issuance is plus or minus 5 minutes. Once I rolled the AD FS servers time back within a couple of minutes/seconds of the internet time gods, tokens were accepted. Now over to the AD and Network teams to restore order on a wider scale.

Delegate Mailbox Access using Groups in Exchange Online

A common misconception about granting mailbox access rights in Exchange Online is that you can only add access to the individual and not a group. You may have opened the Exchange Administrator Center (EAC), found the mailbox you wanted and looked at the delegated access tab. Only to be provided with a list of eligible user identity’s, but none of your on-premises security groups that have been created. Fear not, the on-premises groups just need a little remediation to the correct flavour to be seen in the picker and then applied.
The key settings of a group to assign mailbox access in Exchange Online are:
  1. Universal Security
  2. Mail Enabled
Things in your environment may have gotten this way over time as legacy on-premises Exchange Server versions weren’t as picky with your selection and would allow the permission to be granted to any kind of group you threw at it. Moving to Exchange Online has more sophisticated taste that needs to be catered for due to its Evergreen state with all the latest Exchange trends.
If you migrate on-premises mailboxes with these slightly incorrect permissions to Exchange Online they will be lost forever. So if you remedy the existing on-premises mailboxes before initiating a remote move request to Exchange Online, no further action will be required at completion.

The Process

Update the group to universal:
Get-Group $Name | Set-Group -Universal
Mail enable the group:
Enable-DistributionGroup -identity $Name
Finally, not compulsory but if you want the group to be hidden from your Exchange Address Book:
Get-DistributionGroup -identity $Name | Set-DistributionGroup -HiddenFromAddressListsEnabled:$True
Force a synchronisation of your group modifications with Azure Active Directory and you should find that the group will be available in the Office 365 Exhange Administrator Center. On the Azure AD Connect Server:
CD C:\Program Files\Microsoft Azure AD Sync\Bin\
.\DirectorySyncClientCmd.exe delta
So my final note that I would like to re-iterate is that if you tidy this stuff up before migrating to Office 365 you will have a lot less problems when the mailbox becomes active in Office 365. A mailbox that has been migrated with a faulty group type will have permissions assigned on the object, but will not resolve to an object and therefore only show SID information. Firstly the permissions fail, but secondly, it makes it very difficult to find out what the group was previously to add post migration. (see first permissions below)

 Hot Tip

Fix the issue with your groups before you start the synchronisation of the mailbox to Exchange Online and the permissions will be stamped correctly during the initial phases of the move request and once finalised, will work as expected.

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.

Federated User – Presence Unknown

Here at Kloud we have just been busy updating our Skype for Business Public Certificate before it expired. Our SAN certificate provided by GoDaddy is used on our Edge Server and Reverse Proxy for all external communication to be encrypted with TLS or HTTPS.

After updating our certificate and restarting services to make the certificate take effect, we started to get some feedback from Kloudies (Kloud Employees) of federated contacts showing up with ‘Presence Unknown’ in their contacts list. These were contacts which they had previously been communicating with prior to the certificate change. The head scratcher was that it wasn’t all federated partner domains.

Here is some of the findings and troubleshooting we performed to get to the resolution of the issue.

First thing to always test is the inbuilt PowerShell cmdlets on your server itself.

Test-CsFederatedPartner -Domain contoso.com -TargetFqdn kloudedge.kloud.local

Successful domains appear with the following lines:
Target Fqdn   : kloudedge.kloud.local
Result        : Success
Latency       : 00:00:00
Error Message :
Diagnosis     :

While domains that had the issue would have the following output:
Diagnosis:
ErrorCode=1047,Source=sip.kloud.com.au,Reason=Failed to complete TLS negotiation with a federated peer server,fqdn=SIP.Contoso.COM:5061,peer-type=FederatedPartner,winsock-code=10054,ip-address=xx.xx.xx.xx,winsock-info=The peer forced closure of the connection

From the above message we could see that the peer’s (being the federated partner) Access Edge server was actively closing the connection from our server.

But why?? We haven’t done anything wrong….

This can become a hard thing to troubleshoot if you don’t have access or know the SFB administrator at the partner organisation. Lucky for us this isn’t the case for at least one of our troubled SIP domains.

Investigating the Partner Edge Server we did the following:

  1. Start > Run mmc.
  2. File > Add/Remove Snap-in… > Add… > Certificates (Add) > Service Account  > Skype for Business Server Access Edge (Finish) > Close > OK.
  3. In the mmc, navigate to RtcSrv\Accepted Certificates > Certificates.
  4. Look for the certificate named “sip.kloud.com.au”

What we found was still a copy of the certificate that had just been expired, but no new certificate with the up to date expiration. We wanted to give this Edge Server a little helping hand and investigate why it would potentially not have added the new certificate into this store. Upon copying the new sip.kloud.com.au.cer file to a location on the server and opening the certificate for viewing, we assessed the path of certificate. Bingo! The certificate path was not validated.

The server was missing the GoDaddy Intermediates that are associated with our new certificate. Upon adding the new GoDaddy intermediate certificates to the intermediate store location and restarting the Acess Edge Service to make certificate settings take effect, instant success. The new sip.kloud.com.au certificate was downloaded from our Kloud Edge Server into the Accepted Certificates store of this Edge Server whom we were talking with and presence was restored both ways.

So now we have made the assumption of knowing all the federated partners we associate with that don’t patch their Edge Server with Windows Update. I hope I’m not talking about you.

Edge Servers can easily be the servers that you forget to put in a patching cycle due to being in a DMZ restrict zone, also they are workgroup machines so they won’t take the default group policy settings from WSUS. But here is a prime example of how it could have negative impact on your company if you don’t. So the only way to fix the issue is to spread the word. I don’t have access to everyone. Until they read this blog I can’t chat with them online. The moral of the story;

Patch your Edge Server so they can have up to date certificate information or get left behind while the rest of the Skype for Business world keeps moving on