Microsoft Teams Phone Hotline (Bling) Feature

Microsoft released a new feature for Teams Phone! The feature is called Hotline or PLAR (Private Line Auto Ringdown – for those that must have an obscure acronym for a feature that already has the perfect name). The feature is very simple, but will certainly help with Common Area Phone deployments. In some cases, you just want a phone to do one job and that is to ring to one specific location when it’s picked up. This allows you to mount the phone in a public place and not worry about people using it to call another people within your organisation (or even worse, to make an expensive external call).

Requirements

• The Teams Phone device must be running at least version: 1449/1.0.94.2023082303 of the Teams Phone software.
• The phone account must be a given a Microsoft Teams Shared Devices license. This feature does not exist for a personal login from a regular user. 

• The hotline can be set up to ring either a contact or a phone number (both options are described below).
• The Advanced Calling feature must be turned off in order to use the Hotline feature.
• From my experience, configuration profiles only get pushed to devices at the time they are added to the device or when you update a setting(s) in a configuration profile that is already assigned to a device. If you go and manually assign settings on the phone and then later update the Configuration Profile that is assigned to the device, the manual setting will be overridden by the policy.

 

Configuration

The feature is inbuilt in the Teams Phone software. There are two methods for getting the configuration on to the device. The first is to configure it directly on the device via the settings screen. The second is to push the configuration to the device using a Configuration Profile within the Teams Admin Centre. I will explain both below:

 

Option 1. Configuration on Device:

On the Device go to Settings > Device settings > Admin only > Calling > Hotline

 

Within the settings you get an Enable toggle and the contact that you want the Hotline to ring to. When you switch on the enable toggle, the phone reboots, so it's best if you first configure the contact information before enabling hotline:

When you enter the Configured Contact area you will see a Contact Picker dialog. From here you can type in Contact Names:

Or, if you type in a phone number that the system can normalise, it will allow you to select it also:

Add a Display Name that will make sense to the user that's using the hotline phone, because this name is displayed on the screen of the device when in it's idle mode:

Once it’s added, you will just see the Display Name in the Configured Contact area and not the number or contact that it's actually going to call (so when you're troubleshooting this config in the future, it's always good to open the configured contact to make sure it's going to the place you expect): 

The phone will now restart and you should see the following on the screen. (Note, the last word "emergency" is the display name you configured):

 

Option 2. Configuration via the Teams Admin Centre:

You can find the settings for phone devices under the Teams Devices > Phones area within the Teams Admin Centre:

In this setting you turn on the Hotline toggle and then enter a contact and a Display Name:

If you want to dial an external number you need to make sure that when you click on the "Search for a Contact" field you click the very difficult to see Configure Contact Manually “button” at the bottom of the drop down:

When you do this the Admin Centre will allow you to create a contact object with a phone number associated with it that will become the destination of the hotline:

Now you can save your Configuration profile and go and assign it to the Common Area Phone. From the All Phones tab, select the phone you want to assign the profile to and click the Assign Configuration button:

A fly out window will now appear from the right of screen that ask you to type in the profile name. (You need to  remember at least the first 3 characters of the name you assigned). Select the profile from the list it provides as you type:

 Apply the setting. As a tip, if you want to know which configuration profile is assigned to your phones, you have to scroll to the far right of the device list (it’s not really obvious that these additional columns are hidden over there). You will see, in this case, that the Common Area phone has the "Hotline" profile I assigned:

 

Note: After assigning a configuration policy you may have to wait for 15 mins or more for it to be pushed out to the device. You can see in the device history area that the update is queued. Once it’s complete, the device history will show the status as Successful:

 

Here’s an example of the feature working on the phone:

Note: This GIF is made with my Teams Phone Screen Capture tool: https://www.myteamslab.com/2020/10/teams-phone-screen-capture-tool.html

 Notice in the animation above, when the call is answered the caller doesn't get any features like Hold or Transfer. However, the person answering the call still gets these options in case they want to transfer to someone else, etc.

The Wrap Up

Whilst this process is simple enough, there are steps that aren’t particularly intuitive. Hopefully this has clarified things for you and you can get on with your Hotline Bling.

Read more →

Teams Survivable Branch Appliance (SBA) Logging Issue

If you plan on deploying a Teams Survivable Branch Appliance (SBA) for a larger site you need to be aware of the amount of logging that the Teams SBA service will do to disk. The amount of free space on an SBA can be very limited so it’s important to keep an eye on the logs being generated. 

Here’s an example of a Virtual SBA from AudioCodes that only has 40GB of HDD space to begin with:

Based on this limited amount of space you can’t really expect to be doing a massive amount of logging on the server. Before you go into production you need to be ready for how large the log files are going to be.

Here’s an example of the logging folder from a Teams SBA with over 1000 users connected it. You can see that the main SBA log file rolls once and hour and that each file takes up about 30 MB of space:

If you do some math that’s 24 x 30MB per day of logs being generated on an SBA with 1000 users on it. That adds up to 792 MB per day… Now multiple that by how many days the SBA service logs for by default (30 days!). That’s about 23.7GB of log data that will be stored on the SBA with 1000 users. If you’re wondering what happens when the HDD completely fills up; the SBA service can crash and stop operating. Hot tip: you should try and avoid this.

In order to avoid this issue, you need to tune the number of days that the SBA service will store data on the Teams SBA server. This setting is hidden away in the SBA settings file stored here:

  C:\Program Files\Microsoft\Microsoft SBA\sbasettings.json

Within the file there’s a setting called MaxArchiveDays which you will see defaults to 30 days. All you need to do is reduce this to a value that will work for your available HDD space:

  "Sba": {

    "Identity": "teamssba01.domain.com",

    "TenantId": "523fsdfa-d630-2331-a231-d17123fdc377c",

    "Logger": {

      "Directory": null,

      "Level": "Info",

      "MaxArchiveDays": 30

    }

  },

 

Once you edit this setting the service will pick up the change in real time and prune the existing files down to the new number of days. Crisis averted!

 

The Wrap Up

 

Be good to your SBA, treat it well, have some empathy for the machine. I hope this saved you a nasty surprise. Cheers!

Read more →

Microsoft Teams Survivable Branch Appliance (SBA) is “410 Gone”

When configuring a Microsoft Teams Direct Routing Survivable Branch Appliance the other day I ran into an error. It was an interesting one that I think others will likely run into at some point too, so here is a blog post to save you wasting any more time than you need to thinking about it. After setting up the Teams SBA, I found that I could get users connected to it to send calls outbound to the PSTN, however, when I tried to send calls to the users in the other direction they would fail. Looking closer at the logging from the SBC I could see the error response was “410 Gone”… Gone Baby Gone…  

The 410 Gone error from a Teams SBA looked like this:

SIP/2.0 410 Gone

FROM: <sip:+61399992000@10.0.0.25>;tag=1c1327591735

TO: <sip:+61388886201@sbc01.mym365lab.us>;tag=703d3577eb1a468bbcdb34a0a78c690f

CSEQ: 1 INVITE

CALL-ID: 530796863134202353123@sbc01.domain.com

VIA: SIP/2.0/TLS sbc01.mym365lab.us:5067;branch=z9hG4bKac1432917422

REASON: Q.850;cause=22;text="c586066f-ceb5-4d83-8803-400791d033de;MediaOfferError"

CONTACT: <sip:teamssba01.domain.com:5061;transport=tls;x-i=c586066f-ceb5-4d83-8803-400791d033de;x-c=9baa3cbe22ec46ffb8ac39fffce08f20>

CONTENT-LENGTH: 0

ALLOW: INVITE,ACK,OPTIONS,CANCEL,BYE,NOTIFY

SERVER: Microsoft.Teams.SIPSBA v.2022.6.14.1

 

"Gone" is not a SIP error that I have seen very often in the wild and kind of sounds like it might be related to the user not being connected to the SBA properly. However, after looking more closely at the error, I saw that there was a REASON attribute included in the message that said “MediaOfferError” which then made me further consider what was happening on the media side of things… From most traditional SIP Stacks, I would usually expect a “488 Not Acceptable Here” message response for an SDP refusal scenario, but this is the Teams SBA, so why expect anything that makes sense :)

When I looked at the INVITE that was being sent to the SBA from the SBC, it looked legit:

INVITE sip:+61388886201@sbc01.mym365lab.us SIP/2.0

Via: SIP/2.0/TLS sbc01.domain.com:5067;alias;branch=z9hG4bKac1432917422

Max-Forwards: 69

From: <sip:+61399992000@10.0.0.25>;tag=1c1327591735

To: <sip:+61388886201@sbc01.domain.com>

Call-ID: 530796863134202353123@sbc01.mym365lab.us

CSeq: 1 INVITE

Contact: <sip:+61399992000@sbc01.domain.com:5067;transport=tls;ob>

Supported: norefersub,100rel,timer,replaces,sdp-anat

Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS

Session-Expires: 1800

Min-SE: 90

User-Agent: Mediant SW/v.7.40A.250.265

Content-Type: application/sdp

Content-Length: 287

 

v=0

o=- 419722796 1831657774 IN IP4 10.0.0.25

s=media

b=AS:84

t=0 0

a=X-nat:0

m=audio 50012 RTP/AVP 0 8 96

c=IN IP4 10.0.0.25

b=TIAS:64000

a=rtcp:50013 IN IP4 10.0.0.25

a=sendrecv

a=rtpmap:0 PCMU/8000

a=rtpmap:8 PCMA/8000

a=rtpmap:96 telephone-event/8000

a=fmtp:96 0-16

 

The keen eyed folk in the audience may have noticed though that the SDP portion of the SIP message is in the regular format and not the fancy ICE format that includes a candidate list. The even more keen eyed may be thinking, "yeah, but the Teams Direct Routing service supports this format for SDP, so what's the problem?". Well, unfortunately, the problem is that the SBA only supports ICE formatted SDP lists (which may be because calls are technically media bypassing the SBA). I could see this catching out production deployments where the traditional SDP format is being used for calls to Teams Direct Routing (because this does work). Just keep in mind that the same settings pointing to the SBA will fail dismally.

The Fix

In order to fix this on an AudioCodes SBC you need to make sure that the IP Profile assigned to the SBA has ICE Mode set to “Lite”:

After enabling ICE Lite Mode, the INVITE messages that go to the SBA will be formatted with candidate information, which looks like this:

INVITE sip:+61398736201@sbc01.domain.com SIP/2.0

Via: SIP/2.0/TLS sbc01.domain.com:5067;alias;branch=z9hG4bKac11041617

Max-Forwards: 69

From: <sip:+61399992000@10.0.0.25>;tag=1c200843402

To: <sip:+61388886201@sbc01.domain.com>

Call-ID: 431229997134202354040@sbc01.mym365lab.us

CSeq: 1 INVITE

Contact: <sip:+61399992000@sbc01.domain.com:5067;transport=tls;ob>

Supported: norefersub,100rel,timer,replaces,sdp-anat

Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS

Session-Expires: 1800

Min-SE: 90

User-Agent: Mediant SW/v.7.40A.250.265

Content-Type: application/sdp

Content-Length: 900

 

v=0

o=- 617366211 1969606384 IN IP4 10.0.0.25

s=media

b=AS:84

t=0 0

a=X-nat:0

a=ice-lite

m=audio 50004 RTP/SAVP 0 8 96

c=IN IP4 10.0.0.25

b=TIAS:64000

a=rtcp:50005 IN IP4 10.0.0.25

a=sendrecv

a=rtpmap:0 PCMU/8000

a=rtpmap:8 PCMA/8000

a=rtpmap:96 telephone-event/8000

a=fmtp:96 0-16

a=ice-ufrag:IE15BCMtIoIFC4S8

a=ice-pwd:VYGaTzCfX9gdvnfd9CuDiHuw

a=candidate:128566170 1 udp 2130706431 10.0.0.25 50004 typ host

a=candidate:128566170 2 udp 2130706430 10.0.0.25 50005 typ host

a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:UKAS7+0XGSZeXGFreZWWQU0vuf0D1D/F97dVtVLs|2^31

a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:2kuctHvNudt69PR8gxX/SPcX8LLWGsqdD+uecRxe|2^31

a=crypto:3 AES_256_CM_HMAC_SHA1_80 inline:L0E/e24PTtJ9mUwwWdb3QlCQBtd4WdSuSZvVi45ZkkyhqhnwGTuZGbXjcWJ6dc==|2^31

a=crypto:4 AES_256_CM_HMAC_SHA1_32 inline:z2WjgpGD1HC2HR0+3NZVEfuwEVJ8u0CyHAKuEZAIbMtnHCNw0ieSE22XVCQ39s==|2^31

 

Once you’ve done this, calls from the PSTN to the Teams Client via the SBA should work.

 

The Wrap Up

 

There you have it, more madcapped craziness from the world of Microsoft Teams. Till next time, I’m “410 Gone”. Catch ya later!

Read more →

Microsoft Teams Location Based Bandwidth Control (Network Roaming Policy)

Microsoft Teams now has the ability to limit the network bandwidth used by calls/meetings based on the network location of the user. This uses a feature called Network Roaming Policy. I have found the documentation relating to this feature to be a bit lacking from Microsoft, so I’ve put together this post to go into some more detail about how the policy works.

This feature is an extension of the existing Meeting Policy settings that have always been available for Teams. I wrote an extensive post about how Meeting Policy bandwidth control works  over at this post (https://www.myteamslab.com/2019/10/microsoft-teams-bandwidth-usage-deep.html). The Network Roaming policy has the same effect on the Teams client. However, it's now dynamically implemented by the client based on its location, rather than it always being on in the previous Meeting Policy implementation. This means that if you have a specific site that you know has low bandwidth constraints, then you can limit the maximum bandwidth per call and also restrict video usage for this site location only.

 

How Does the Policy Work?

The Network Roaming Policy is based on network IP Addressing of the client machine and the NATed IP Address of the client as it access the Internet. This relies on the configuration of both the Trusted IP Address ranges and Network Site subnets within the Teams Admin Centre. The client will compare both its local subnet and its public IP address (NATed address that it accesses the Internet through, e.g. Type “What's my IP” into Google) in order to know if it will implement the Network Roaming policy. The diagram below shows two different sites with different LAN Address ranges as well as different internet egress IP Addresses through the Internet facing firewall:

Note: The policy is not just based on the IP Address of the user because you could have multiple sites with the same internal private IP Address range. The Trusted IP (Public IP) must also match for the policy to be implemented by the client.

In the configuration example we will configure a Network Roaming policy for the "Low Bandwidth Site" on the left hand side of the diagram. The site on the right hand side will not be configured and will fall back to having the default bandwidth settings used for Teams.

Importantly, the only clients that currently support the Network Roaming policy at the moment are the Windows and MacOS desktop clients. So don’t expect this to work with Teams Phones, MTRs, or Linux clients. 

 

Configuration of Network Roaming Bandwidth Policy

Note: In classic cloud style, you will usually need to wait about 24 hours before this policy takes effect. As a result, make sure you're not in any kind of rush when setting this up.

Network Roaming Policy is configured under the Locations > Network Topology section of the Teams Admin Centre: 

The Network Topology section consists of 3 tabs - Network Sites, Trusted Sites and Roaming Policy. You will need to configure all of these areas in order for Network Roaming Policy to work.  For this example we will configure a policy that will limit the Teams client to only use a maximum of 300kbps worth of bandwidth for its Audio and Video streams.

Step 1. Start by creating a Network Roaming Policy from the Roaming Policy tab, select Add:

Step 2. Configure the policy with the required bandwidth per call and whether or not video will be supported (for more details about how much bandwidth is used for video calls, see my previous post here: https://www.myteamslab.com/2019/10/microsoft-teams-bandwidth-usage-deep.html):

Step 3. Select the Trusted IPs tab and click the Add button:

Step 4. The trusted IP Address is the external facing NATed IP address that Office 365 will see as the source address coming from your client connection. If you search for “What's my IP” on Google from the location it will tell you what this IP Address is. In the case of connecting to Office 365 there are likely a range of IP Addresses used here, so you need to get the Network Mask correct.  

 Step 5. In the network sites tab you need to create a new site, click the Add button:

 In the new Site policy you select the Network Roaming Policy that was created in Step 1:

Each subnet that is used internally at the site should be added to the Site by clicking the Add Subnets button:

Step 6: In addition to the Network Location configuration above, you also need to turn on Network Configuration Lookup in Meeting Policy:

Within the Meeting policy you need to ensure that the following setting is enabled:

The Microsoft Docs (https://learn.microsoft.com/en-us/microsoftteams/network-roaming-policy) say the following:

“To enable the network roaming policy for users who are not enterprise voice enabled, you must also enable the AllowNetworkConfigurationSettingsLookup setting in TeamsMeetingPolicy. This setting is off by default.”

So really, it’s best that you always turn this on if you want the Network Roaming Policy to take effect for everyone.

 

 

How do you know if the policy is working?

 

The client doesn’t display anything to the user to inform them that this policy is in use. The only way you can really tell is by looking into the Teams Client logs. You can get the client to output the logs by pressing the Ctrl + Alt + Shift + 1 keys on your keyboard. When this is done the client will output log files to your Downloads folder. From here you open up the following file:

Downloads\MSTeams Diagnostics Log <Date>\web\ MSTeams Diagnostics Log <Date>_calling.txt

This file contains information about if the client has matched any of the existing policies.

 

When the policy is not being applied you will find something like this indicating that the default policy is in use:

" networkRoamingPolicy": {

" allowIPVideo " : true ,

"mediaBitRateKb" : 50000,

"policyDocument ": "Default "

 

When the Network Roaming policy has been successfully deployed you should see the Network Roaming Policy section of the file display information about the policy that the client is implementing.  Importantly, the trustedIpMatchInfo and siteMatchInfo sections must say that they have "Matched" one of the policies.

 

Current MT location response:

{

  "emergencyCallingPolicy": {

    "policyDocument": "Default"

  },

  "emergencyCallRoutingPolicy": {

    "emergencyNumbers": [],

    "policyDocument": "Default"

  },

  "networkRoamingPolicy": {

    "allowIPVideo": true,

    "mediaBitRateKb": 300,

    "policyDocument": "TeamsNetworkRoamingPolicy=Tenant:300kbps"

  },

  "endpointNetwork": "Trusted",

  "networkSiteId": "Low Bandwidth Site",

  "enableLocationBasedRouting": false,

  "siteAddress": "Low Bandwidth Site",

  "subnetId": "10.1.0.0",

  "debugInfo": {

    "ncsDebugInfo": {

      "trustedIpMatchInfo": {

        "publicIp": "50.1.2.100",

        "trustedIpAddress": "50.1.2.100",

        "maskBits": 24,

        "reason": "Matched",

        "_comment": "Match Client Public IP to Tenant Trusted IP"

      },

      "siteMatchInfo": {

        "ipv4": "10.1.0.180",

        "subnetLengthIPv4": "24",

        "subnetId": "10.1.0.0",

        "maskBits": 24,

        "networkSiteId": "Low Bandwidth Site",

        "enableLocationBasedRouting": false,

        "reason": "Matched",

        "_comment": "Used to match endpoint subnet to Tenant site if trustedIpMatchInfo matches"

      },

      "networkLocationMatchInfo": {

        "bssid": "74-ac-b9-2e-f3-b3",

        "ipv4": "10.1.0.180",

        "reason": "NotMatched",

        "_comment": "Used to find emergency address,against Tenant Location Network Information (LIS), otherwise against Client Geo Location Information (CLS) if available"

      }

    },

    "mtDebugInfo": {

      "isDirectRoutingOnlyUser": true,

      "emergencyCallingPolicyTag": "Default",

      "emergencyCallRoutingPolicyTag": "Default",

      "networkRoamingPolicyTag": "TeamsNetworkRoamingPolicy=Tenant:300kbps",

      "emergencyCallingPolicyAssignedTo": "Tenant or Host Global",

      "emergencyCallRoutingPolicyAssignedTo": "Tenant or Host Global",

      "networkRoamingPolicyAssignedTo": "Network Site",

      "ncsResponseReceived": true,

      "correlationId": "1DEF3C2C47D64C1EB7060657876ECE95"

    }

  }

}

   

The Wrap Up

Awesome - now you can walk up to random people on the street and tell them about how you know all about Teams Network Roaming Policy. Believe me, they will be thrilled to hear all the details. Especially the bit about the AllowNetworkConfigurationSettingsLookup setting. That one really cracks them up. Cheers, Enjoy!

Read more →