Teams Direct Routing with an AudioCodes SBC

Introduction

Last Updated: 31/01/19

Microsoft has released Direct Routing for Microsoft Teams. This is one of the big steps — in my opinion — of making parity with Skype Online.

Direct Routing effectively allows you to connect up existing PSTN connectivity (e.g. SIP trunks) into a certified SBC and route directly to Teams. This differs from the Skype Online method of doing this, in that you no longer need any hardware (on-premises Skype for Business Server or a CCE) other than an SBC.

In this post, I’ll go over how to do this with an AudioCodes SBC and SIP trunks. I shan’t go into too much detail as the documentation from Microsoft and AudioCodes is pretty good:

Plan Direct Routing

Configure Direct Routing

AudioCodes Documentation

Pre-requisites

Before you begin configuration, you need to make sure you have (or will have) everything needed in place:

AudioCodes SBC:

  • An AudioCodes SBC running at least version 7.20A.204.015 or above and the following licenses installed:
    • Microsoft Teams License (Part SW/MSTEAMS) – this enables the SBC for Teams Direct Routing and enables the audio codecs SILK and OPUS. Before release 7.20A.250.xxx you didn’t need this license for Direct Routing to work. If your SBC is 7.20A.250 or above you will need this!
    • SBC sessions – same as any other AudioCodes SBC configuration using SIP-SIP, it will consume SBC sessions – each call consumes 1 SBC session.
    • (Optional) Transcoding – if your SIP carrier doesn’t support a codec you want to use e.g G.711 for Teams Direct Routing e.g. SILK – you would require transcoding to convert between the two.
    • Note: The trial license that runs on an unlicensed SBC doesn’t currently include the Teams license, so if trialling – either deploy an earlier build than 7.20.A.250 or ask your AudioCodes rep for a trial license with it included.The SBC has a “WAN” interface with a public IP address assigned (or NAT’d through) to the “WAN” interface. It is common to also have a “LAN” interface for management but it’s not a requirement.
  • A SIP trunk or PSTN trunk configured on the SBC – I won’t cover this off as it could be configured in a million different ways.
  • An A record created that points to the public IP address of the SBC. This can be part of any domain that is in the Office 365 tenant (except the onmicrosoft.com domain). An example could be sbc.domain.com if domain.com is a verified domain on your tenant.
  • A publicly issued certificate with the A record/FQDN of the SBC in the common name or SAN. You can also use a wildcard, but I’ve not tried that. Microsoft does not trust all public CAs, so make sure it is on their list. Examples of trusted CAs are DigiCert, GlobalSign, Go Daddy.
  • Communication is allowed through any firewalls that the SBC uses. The following ports need to be allowed:
    Traffic From To Source Port Destination Port Description
    SIP/TLS Teams SIP Proxy* SBC 1024-65535 TCP Defined on SBC SIP signalling from Teams to your SBC, the destination port is dependant on what you configure the TLS SIP Interface to be. (Default is 5067 TCP)
    SIP/TLS SBC Teams SIP Proxy* Defined on SBC 5061 TCP SIP signalling from your SBC to Teams. I would most likely allow all source ports (1024-65535 TCP) to destination port 5061.
    UDP/SRTP Teams Media Processor** SBC 49152-53247 UDP Defined on SBC Media from Teams to your SBC. The destination port is dependant on what is configured in the media realm on the SBC.
    UDP/SRTP SBC Teams Media Processor** Defined on SBC 49152-53247 UDP Media from your SBC to Teams. The source port is dependant on what is configured in the media realm on the SBC.

    * Teams SIP Proxy IPs are currently: 52.114.148.0 (yes, .0), 52.114.132.46, 52.114.75.24, 52.114.76.76, 52.114.7.24 and 52.114.14.70
    ** Teams Media Processor IPs are currently defined as 52.112.0.0/14

    For latest IP addresses in use, check here: https://docs.microsoft.com/en-us/microsoftteams/direct-routing-plan#sip-signaling-fqdns-and-firewall-ports

Office 365:

  • Access to the tenant via Skype Online PowerShell.
  • Users who will use Direct Routing are:
    • Homed on Skype Online (not on-premises).
    • Teams Upgrade Policy is either Islands or UpgradeToTeams
    • Licensed correctly with the following licenses:
      • Skype Online (Plan 2) – Part of E3, E5 etc.
      • Microsoft Phone System – Can be bought standalone or part of E5.
      • Microsoft Teams – Part of E3, E5 etc.
      • Microsoft Audio Conferencing – Not technically required to make and receive calls, but needed if adding participants to meetings etc. Can be bought standalone or part of E5.

Configure SBC

At this stage you should have an SBC:

  • Running version 7.20A.200.055 or above and licensed.
  • Setup the PSTN e.g. SIP trunk
  • A “WAN” side interface with a public IP address (assigned or NAT’d)
  • Created an A record for the SBC and it should be pointing at the SBC’s public IP address.

Certificates

The first thing to do is setup certificates so Teams and the SBC trust each other and encrypt all traffic. Under Setup > IP Network >Security >TLS Contexts, create a new TLS Context specifically for Teams. It needs to be given an arbitrary name and set to use TLS version to 1.0, 1.1 and 1.2.

Next, under the new TLS Context, go to Change Certificate. I would recommend you change the private key size to 2048 first.

Once the new key has been generated complete the CSR. As mentioned earlier, the SBC FQDN needs to be in the common name or SAN.

Create the CSR (I had to generate a 2048 bit private key first). It should generate a CSR underneath. Copy this and raise with your public Certificate Authority (making sure its supported as per the list).

Once the certificate is issued, upload it as a device certificate in the same location you generated the CSR:

If you now go back the TLS context, under Certificate Information, you should have the issued certificate:

Now the certificate is installed, you will need to install any root or intermediates that are in the chain of the certificate. In addition, you need to install the root certificate Teams SIP Proxy is using – this can be downloaded here. Still under the TLS context, go to Trusted Root Certificates and import the root and intermediate certificates. In my case I have a GlobalSign root and an Alpha SSL intermediate for my certificate and a Baltimore root so that the Teams SIP Proxy is trusted:

Note: the SBC will only accept certificates in Base64 format, not DER.

Media Realms

A Media Realm is a definition of UDP ports to use for media on an SBC interface. Navigate to Setup > Signaling and Media > Core Entities > Media Realms. If there isn’t a Media Realm assigned to your “WAN” interface, create one. Base the Media Session Legs on how many SBC sessions you are likely to have and double it to leave headroom. Make a note of the “WAN” interface port range as this is the defined SBC media range for the firewall rules mentioned earlier.

SIP Interface

A SIP interface is similar to a Media Realm, it defines what ports and protocols are used for each SBC interface. Navigate to Setup > Signaling and Media > Core Entities > SIP Interfaces. Click New and create a new SIP Interface. You will need to do the following:

  • Give it an arbitrary name e.g. Teams.
  • Network Interface to be the “WAN” interface.
  • Set UDP and TCP Port to 0.
  • Set the TLS Port to whatever port you want the SBC to listen on externally. Make a note of this as this makes up the defined SBC signalling port for the firewall rules and you need to specify it in Skype Online PowerShell later.
  • Enable TCP Keepalive.
  • Media Realm to the one created for the “WAN” interface.
  • TLS Context Name to the one created for Teams.
  • Enable TLS Mutual Authentication.
  • Set the Classification Response to 0 (SBC will not respond to failures, useful in DoS attacks).

Proxy Set

A Proxy Set is a definition of IP addresses or hostnames the SBC will use to communicate with, in this case, Teams. Navigate to Setup > Signaling and Media > Core Entities > Proxy Sets. Add one for Teams by clicking New. Set up as:

  • Give it an arbitrary name e.g. Teams.
  • SBC IPv4 SIP Interface as the one you just created.
  • TLS Context Name to the Teams one you created.
  • Proxy Keepalive to Using OPTIONS.
  • Proxy Hot Swap to Enabled.
  • Proxy Load Balancing Method to Random Weights.
  • DNS Resolve Method to SRV.

Once the Proxy Set is created, you need to click Proxy Addresses at the bottom of the Proxy Set:

Add teams.local as the only Proxy Address and set the transport type to TLS:

(Don’t worry, I know teams.local doesn’t resolve to anything – all will become apparent later).

Coder Group

A Coder Group is a list of codecs to use for each SIP trunk. Navigate to Setup > Signaling and Media > Coders and Profiles > Coder Groups. Here, you need to an define an unused group what codecs will be used when communicating with Teams:

Don’t forget to save at the bottom.

Note: for SILK, you will need the SILK codec license.

IP Profile

IP Profile defines the SIP behaviour of the SBC based on what is set in the IP Profile. Navigate to Setup > Signaling and Media > Coders and Profiles > IP Profiles. Click New and add one like so:

  • Give it an arbitrary name e.g. Teams.
  • SBC Media Security Mode to SRTP.
  • Extension Coders Group to the one you just created.
  • Remote Update Support to Not Supported
  • Remote re-INVITE to Supported only with SDP
  • Remote Delayed Offer Support to Not Supported
  • Remote REFER Mode to Handle Locally
  • Remote Hold Format to Inactive
  • ICE Mode to Lite (if using Media Bypass)

IP Group

IP Groups are what ties what you’ve already done together. Navigate to Setup > Signaling and Media > Core Entities > IP Group. Now, set one up for Teams. You need to set up like below:

  • Give it an arbitrary name e.g. Teams.
  • Topology Location to Up
  • Proxy Set to the one you created for Teams.
  • IP Profile to the one you just created.
  • Media Realm to the one assigned to the “WAN” interface.
  • Classify By Proxy Set to Disable (as the Proxy Set address is set as teams.local, so that wouldn’t match the actual incoming addresses from Teams).
  • Local Host Name to the SBC FQDN/A record. This is then used in Contact and VIA headers.
  • Always Use Src Address to Yes.
  • DTLS Context to the Teams one you set up.
  • Proxy Keep-Alive using IP Group settings to Enable (this is only available in later 7.2 builds, so if not seen, upgrade your SBC to the latest 7.2 build to set this).

Internal SRV Table

Navigate to Setup > IP Network > DNS > Internal SRV. Remember setting teams.local SRV as the proxy address earlier? Well, this is where it comes in to play. Effectively, the SBC has the teams.local SRV record resolve to all 3 Teams SIP Proxy addresses in its own DNS table and has them weighted in order. Set them as below:

Note: The three addresses here are the primary and two standby Teams SIP Proxy addresses. It’s quite clever in that depending on where you are in the world each address will resolve to the nearest entry point in order. In the EU for example, sip.pstnhub.microsoft.com would be the EU entry point, sip2.pstnhub.microsoft.com would be the US entry point and sip3.pstnhub.microsoft.com would be the APAC entry point. In the US and APAC it would be a different order.

SRTP

Navigate to Setup > Signaling and Media > Media > Media Security and make sure Media Security is Enabled and the Media Security Behaviour is set to Preferable – Single Media (Use SRTP when you can).

Message Condition Rule

Navigate to Signalling and Media > Message Manipulation > Message Conditions. Here you need to create a condition that only accepts SIP messages that contain ‘pstnhub.microsoft.com’ in the Contact Header. Click New and give it a Name e.g. Teams Contact and the condition should be header.contact.url.host contains ‘pstnhub.microsoft.com’

Classification Rule

Navigate to Signalling and Media > SBC > Classification. In here, using the Message Condition you just created, you can classify traffic coming from Teams as the Teams IP groups. This is needed as the incoming Contact Header from Teams won’t match the ‘teams.local’ address set in the Proxy Set. Configure as below:

  • Give it an arbitrary name e.g. Teams.
  • Source SIP Interface will be the Teams SIP Interface you created.
  • Destination Host will be the SBC FQDN (not in single quotes this time).
  • Message Condition to the one you just created.
  • Action Type to Allow.
  • Source IP group to the Teams IP group you created.

IP-to-IP Routing

Navigate to Setup > Signaling and Media > SBC > Routing > IP-to-IP Routing. Here, you need to create 4 routing rules, in this order:

  • Terminate OPTIONS between IP groups. This keeps OPTIONS local to the SBC and does not proxy them.
  • REFER rule that allows Teams to transfer calls correctly.
  • Route calls from Teams IP group to your SIP trunk IP group (in my case – COLT).
  • Route calls from your SIP trunk IP group (in my case – COLT) to your Teams IP group. If you were running co-existence with Skype for Business, you could change the Destination Username to route only a certain DDI/range.

You should now have 4 routes defined:

Verify Connection to Teams

That’s it! – you should now have enough configuration to connect to Teams. If you look at Monitor > VOIP Status > Proxy Set Status it should show as online for all 3 regions:

Configure Office 365

Connect to Skype Online using the Skype Online PowerShell connector.

Add SBC as a PSTN Gateway

Once connected, you should now have some new cmdlets:

Then, run New-CSOnlinePSTNGateway cmdlet:

New-CsOnlinePSTNGateway -Fqdn <SBC FQDN> -SipSignallingPort <SBC TLS Port Defined in SIP Interface> -MaxConcurrentSessions <Amount of SBC sessions you are licensed for> -Enabled $true

You can see there are some extra parameters than can be set:

  • CodecPriority – You can set it to prefer G711 before SILK etc.
  • FailoverTimeSeconds – How long to wait for the SBC to respond. If it doesn’t respond, failover to another SBC (if there is one).
  • SendSipOptions – Teams will send SIP OPTIONS. Disabling this will remove it from alerts and monitoring.
  • MediaBypass – Reserved for future use, when Media Bypass becomes generally available.
  • MaxConcurrentSessions – used to set the capacity of the SBC. Useful when multiple SBCs are in use, as Teams can use a different SBC if the SBC is at capacity.
  • Enabled – Useful if you need to take the SBC from the useable list whilst performing maintenance.

If you check the Syslog of the SBC, you can see incoming requests from the Teams SIP Proxy:

Enable User(s) for Calling

For each user make sure they have the correct licenses assigned e.g. E3 with Phone System. Then, run the following command to enable them for calling:

Set-CsUser -Identity "<User name>" -EnterpriseVoiceEnabled $true -HostedVoiceMail $true -OnPremLineURI tel:<E.164 Tel Number>

Configure Voice Routing

Much like on-premises Skype for Business, you have number normalisation, policies, PSTN usages and routes. Like on-premises, this can get quite complex, but essentially calls are based on permissions (Online Voice Routing Policies) and the number called (Online Voice Routes).

To keep things simple, in my scenario I have one Online Voice Routing Policy, one PSTN usage, one Voice Route and one SBC.

Note: It can be confusing as there are “Voice Policies” (Used with Calling Plans) and “Online Voice Routing Policies” (Direct Routing). You need to use “Online Voice Routing Policies”.

Create a PSTN Usage – Here you add a PSTN Usage to the Global list using Set-CSOnlinePSTNUsage:

Set-CsOnlinePstnUsage -Identity Global -Usage @{Add="<PSTN Usage Name>"}

In my scenario, I’ve added a PSTN usage for the UK. You could add a PSTN usage for each country or for a particular type of call e.g. International.

Create an Online Voice Route – Now you add an Online Voice Route. This is effectively a regex pattern to match. If it matches, it sends the call to the defined SBC(s):

New-CSOnlineVoiceRoute -Identity "<Route Name>" -NumberPattern "<Regex>" -OnlinePstnGatewayList <SBC FQDN> -Priority <Num> -OnlinePstnUsages "<PSTN Usages>"

In my scenario, I’ve routed all calls via a single SBC. You could list more than one SBC and all would be used. Another example route could be:

In this route only calls with a UK (+44) number would use this route. Notice the priority that is set, if you are using multiple routes it is critical you put the more specific routes higher.

Create an Online Voice Routing Policy – Using the PSTN Usage(s) and their defined Online Voice Route(s), you can create an Online Voice Routing Policy. It is effectively a list of allowed telephone number patterns and routes (and their priority) for a User:

New-CSOnlineVoiceRoutingPolicy "<Name>" -OnlinePstnUsages "<PSTN Usages>"

I’ve created an Online Voice Routing Policy for UK users and have assigned the “UK” PSTN Usage to it.

Grant Voice Routing Policy for each user – With the newly created policy – assign it to each user:

Grant-CsOnlineVoiceRoutingPolicy -Identity <User> -PolicyName <Policy>

Note: It is common for this to fail with “Policy <name> is not a user policy” if assigning just after creating it. Leave it an hour or so and it should work.

Once this is setup the call flow works like this:

  1. A user makes a call.
  2. Based on the Online Voice Routing Policy a list of PSTN Usages is returned.
  3. The Online Voice Routes that are tied to the PSTN Usages are checked to see if the number matches any. If it does, the call is sent to the SBC(s) in the Online Voice Route with the highest priority.
  4. If for whatever reason the call cannot be routed via the Online Voice Route (e.g. SBC(s) offline), then the remaining matching Online Voice Routes in that PSTN Usage are used.
  5. If there are no working Online Voice Routes found and the user has a Calling Plan assigned, this is used as a last resort.

Assign a Teams Upgrade Policy – Each user will need to have a Teams Upgrade Policy assigned that uses Teams for calling. This would either need to be “UpgradeToTeams” (Teams Only) or “Islands” (Teams and SfB):

If the policy needs to be changed for the user, it can be done by running:

Grant-CSTeamsUpgradePolicy -Identity <User> -PolicyName <Policy>

Note: If the Global Policy is Islands or UpgradeToTeams, you may not need to assign the policy to the user.

Wrap up

And that should be it. It is thankfully fairly straight forward. By the end, you will have a SIP connection established to Teams and be able to route calls to and from Teams.

60 thoughts on “Teams Direct Routing with an AudioCodes SBC

  • 21st June 2018 at 3:45 PM
    Permalink

    Nice write up. Quite a bit of work, but nothing like it used to be. Was pointed here by Audiocodes and we’re (SureVoIP) looking at these SBC’s

    Reply
  • 21st June 2018 at 3:52 PM
    Permalink

    They should be smart. I’ll mention it. Also looking at Ribbon solutions.

    Reply
    • 21st June 2018 at 4:55 PM
      Permalink

      Not seen much of the Ribbon offering. For Direct Routing they seem fairly similar. One person did tell me that the AudioCodes SBC can support multiple 365 tenants but the Ribbon cannot – I haven’t confirmed this, mind.

      Reply
      • 24th July 2018 at 6:28 PM
        Permalink

        The Ribbon Core SBC can support multiple tenants today.

        Reply
  • 21st June 2018 at 4:51 PM
    Permalink

    Thanks Gavin. Yeah back in the bad old days configuring an SBC or GW a big task. With the SBC config wizard you can configure quite easily. If AudioCodes are smart they will add support for Teams using the wizard.

    Reply
    • 21st June 2018 at 4:02 PM
      Permalink

      Coming soon 🙂

      Reply
      • 21st June 2018 at 8:53 PM
        Permalink

        Awesome. Keep me posted – keen to try that out!

        Reply
  • 26th June 2018 at 10:52 AM
    Permalink

    When i try and assign the voice policy in office 365 i get the message “Policy “UK_POLICY” is not a user policy. You can assign only a user policy to a specific user.” Any idea what this could be, gone back through this guide and the one Microsoft themselves posted and still the same.

    Reply
    • 26th June 2018 at 9:05 PM
      Permalink

      Hi Joel,

      I had the same myself. I left it for an hour or so – re run the same command and it worked. Could you try that?

      Thanks,
      Lee

      Reply
  • 1st July 2018 at 7:38 PM
    Permalink

    Hi Matt,

    That’s great – thanks for pointing it out. Looks like now it’s GA they moved it from SfB docs to Teams docs.

    Thanks again,
    Lee

    Reply
  • 16th July 2018 at 4:30 PM
    Permalink

    Configured this all but not getting the “Calls” button on Teams! Anyone experienced the same?

    Reply
    • 17th July 2018 at 10:41 AM
      Permalink

      Hi Mario,

      Can’t say I have – just checking if the Grant-CsOnlineVoiceRoutingPolicy completed without errors. On this command, it errored initially for me. Went back a few hours later and re-ran it and all was well that time.

      I’m guessing you also assigned an Interop Policy to allow calling within Teams?

      Thanks,
      Lee

      Reply
  • 24th July 2018 at 9:35 AM
    Permalink

    Hi Lee,
    Thank you for this significant amount of work here. Seems like a basic question – but in the details above you have assumed in a few areas that we have already entered SIp trunk details.
    Given this might be a new interface for a few users, and the SIp trunk formats differing between providers – is there any documentation you can reference regarding the setup of a basic sip trunk into the SBC?
    Many thanks,
    R

    Reply
    • 25th July 2018 at 9:32 AM
      Permalink

      Thanks Ryan,

      AudioCodes do write guides for specific SIP trunk providers. Do you have a specific one in mind? If not, let me see what I can find on a generic SIP trunk.

      Reply
      • 25th July 2018 at 9:38 AM
        Permalink

        Thanks Lee – I doubt that AudiCodes will have written a guide for this provider, it is a niche ISP in New Zealand. Yes, a generic SIP trunk guide would be great!

        The basic details I have from the ISP are:
        Realm: sipserver.host.co.nz
        username: username
        password: password
        DDI Assigned: +6498884444 (not a real number)

        Is there any additional info that I need?

        Reply
  • 25th July 2018 at 10:41 AM
    Permalink

    The easiest way of setting up an AudioCodes SBC is to use the ‘SBC Wizard’. This is a small application or part of the SBC web GUI that has built-in templates for all of the SIP Trunk providers and PBXs that have been tested with the SBC. The wizard asks a few questions about your setup, PBX type, SIP Trunk provider, IP addresses, etc then builds the configuration for you. You can then easily adapt this by adding a connection to Teams following Lee’s information above.

    Reply
  • 25th July 2018 at 11:20 AM
    Permalink

    Thanks John. Appreciate the input – I just thought I would make clear for anyone reading this that the Wizard will overwite all configuration, so perhaps try it before following the instructions above, not after…

    Reply
    • 25th July 2018 at 11:24 AM
      Permalink

      very good point 🙂

      Reply
  • 2nd August 2018 at 4:35 PM
    Permalink

    How’s AudioCodes support multi tenant?
    Does direct routing hosting mode is for support multi tenant ?
    How about single tenant multi domain? Does it all add domain with SAN and change the contact header?

    Reply
  • Pingback:Direct Routing in Azure using AudioCodes Mediant SBC Azure Edition – Part 2 – Lee Ford's Blog

  • 10th August 2018 at 12:20 PM
    Permalink

    Hi Lee,
    Thank you for your reply. I have follow your step to setup with Public IP is success.
    But We I set it on behind NAT with DMZ IP, it doesn’t work.

    I go to NAT translation and add a rules for WAN interface and Target IP Address is “Public IP”, Port start and stop leave it empty.

    Gateway General Settings- > NAT IP Address ” Public IP”

    I’ve trace the Firewall is 1 : 1 mapping and I’ve tested on another SBC working fine for same rules.

    Any advise?

    Reply
    • 10th August 2018 at 1:58 PM
      Permalink

      Hi John,

      You shouldn’t need the Gateway NAT address, so I would remove that first.

      Failing that, I would on up Syslog trace from SBC and make sure the public IP address is being used e.g. CONTACT header?

      Thanks,
      Lee

      Reply
      • 10th August 2018 at 4:09 PM
        Permalink

        OK, I deleted the Gateway NAT Address, I can see the outgoing SIP Contact header have Public IP.
        Contact:
        SIPAppMngr::GetControlIPAddress – Near NAT translation found for SIP Interface 1. Translated IP Address Public IP:5068

        sometime the call can’t be made, but once the call can established the call will drop after 30 seconds, Firewall rules inbound and outbound are running normal on Souns direct routing with behind NAT. so the firewall rules should be correct.

        It’s look like media firewall issue?
        recv

        Reply
        • 10th August 2018 at 4:50 PM
          Permalink

          When the call ends who sends the BYE? Is it Teams or the Audiocodes? What is the termination reason?

          Reply
          • 12th August 2018 at 1:28 PM
            Permalink

            Local send bye to Teams.
            Reason: SIP ;cause=400 ;text=”local, RTP Broken Connection”

            Thanks.

          • 13th August 2018 at 9:11 PM
            Permalink

            Hmmm sounds like the RTP stream isn’t being established. If you want to blank out the sensitive details of a call on the syslog, I can have a quick look for you. Email is lee at lee-ford dot co dot uk.

  • Pingback:Direct Routing in Azure using AudioCodes Mediant SBC Azure Edition – Part 1 – Lee Ford's Blog

  • 17th September 2018 at 4:13 AM
    Permalink

    Is the AWS Mediant SE with it’s trial license capable of testing SIP/Teams? I’m trying to get this working with 1x Twilio SIP trunk and Direct Routing/Teams. I can get SBC > Twilio test dials OK, and SBC > Teams test dials OK. But I can’t get Twilio to route to Teams or visa versa.

    My trial license says; should this be enough for an end-to-end test?

    Key features:
    Board Type: Mediant SW
    Max SW Ver: 9.80
    Channel Type: DspCh=0
    HA
    Security: IPSEC MediaEncryption StrongEncryption EncryptControlProtocol
    DSP Voice features:
    DATA features:
    Coders: G723 G729 G728 NETCODER GSM-FR GSM-EFR AMR EVRC-QCELP G727 ILBC EVRC-B AMR-WB G722 EG711 MS_RTA_NB MS_RTA_WB SILK_NB SILK_WB SPEEX_NB SPEEX_WB OPUS_NB OPUS_WB
    Control Protocols: MGCP SIP SBC=3 MSFT
    Default features:
    Coders: G711 G726

    Reply
    • 17th September 2018 at 2:33 PM
      Permalink

      Hi Michael,

      Licenses look ok. Can you see anything in a syslog trace at all?

      Thanks

      Reply
  • 1st October 2018 at 1:42 PM
    Permalink

    Hello there,

    any idea on how troubleshooting “Connection to Teams”? It says OFFLINE
    Cheers beppe

    Reply
    • 13th March 2019 at 2:37 PM
      Permalink

      Me sucede lo mismo, los puntos de conexión de MS no responden.

      Reply
  • 9th October 2018 at 9:54 PM
    Permalink

    I have a quick question – what’s the point of the options routing, the first IP-to-IP routing rule?

    Reply
    • 10th October 2018 at 9:07 AM
      Permalink

      Hi,

      It’s used to stop the SBC forwarding OPTIONS between IP groups. So for example, if you get OPTIONS requests from Teams, it will reply from the SBC only instead of forwarding that options request on to the SIP trunk IP group and relaying that response back to Teams.

      By doing this, each IP Group/Proxy set has it own independant OPTIONS responses.

      Thanks,
      Lee

      Reply
  • 10th December 2018 at 3:06 PM
    Permalink

    Hi Lee,

    I’m getting the following error in Syslog, I configured the certificate correctly, why am i getting the error. I’m using wild card certificate from Godaddy ”

    15:02:00CTlsSocket::ContinueHandshake TLS handshake. i=0, err=336134278, errstr=error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed [Time:[email protected]:02:00.787]

    15:02:00CTlsSocket::ContinueHandshake TLS handshake. i=0, err=336134278, errstr=error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed [Time:[email protected]:02:00.912]

    15:02:01CTlsSocket::ContinueHandshake TLS handshake. i=0, err=336134278, errstr=error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed [Time:[email protected]:02:01.161]

    15:02:01CTlsSocket::ContinueHandshake TLS handshake. i=0, err=336134278, errstr=error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed [Time:[email protected]:02:01.878]”

    Kindly assist.

    Thanks

    Reply
  • 11th December 2018 at 11:57 AM
    Permalink

    Hello,

    I figured out the issue already. It was the Baltimore trusted root certificate.

    Reply
    • 11th December 2018 at 3:45 PM
      Permalink

      Hi,

      You beat me to it! Was going to ask to make sure the root and intermediates of your on and Teams SIP Proxy was installed.

      Glad it’s all working.

      Reply
  • 12th December 2018 at 12:04 AM
    Permalink

    Hi Lee,

    Thanks for your prompt response. I’ve been able to pair the SBC on Azure with Teams. I also have my SIP trunk registered but when I try to make calls, it keeps dropping and doesn’t connect. Syslog shows this “00:58:55OPTIONS sip:sbc.re.com:5067;transport=tls SIP/2.0 FROM: ;tag=d01729df-4079-4def-a08a-13fc58d3cd16 TO: CSEQ: 1 OPTIONS CALL-ID: e7c94216-d3c4-414d-9802-a97f5638b6d2 MAX-FORWARDS: 70 VIA: SIP/2.0/TLS 10.0.0.7:5061;branch=z9hG4bKd19b080 CONTACT: CONTENT-LENGTH: 0 USER-AGENT: Microsoft.PSTNHub.SIPProxy v.2018.12.10.3 i.EUNO.3 ALLOW: INVITE ALLOW: ACK ALLOW: OPTIONS ALLOW: CANCEL ALLOW: BYE ALLOW: NOTIFY [Time:[email protected]:58:55.360]”

    Kindly assist.

    Thank you

    Reply
    • 12th December 2018 at 6:47 PM
      Permalink

      Hi,

      That excerpt looks to be a SIP OPTIONS message from Teams. Do you see any INVITE messages?

      Lee

      Reply
  • 12th December 2018 at 8:23 PM
    Permalink

    Hi Lee,

    I cant see any INVITE Messages and the calls doesn’t connect.

    Reply
  • 13th December 2018 at 12:02 PM
    Permalink

    Hi Lee,

    Yes i’m seeing the Invite Messages. The call now rings on teams but doesn’t ring on the mobile number. Please see below:

    12:57:09.516 168.63.38.219 local0.notice INVITE sip:[email protected];user=phone SIP/2.0
    Via: SIP/2.0/UDP 10.0.0.4:5060;branch=z9hG4bKac1277635367
    Max-Forwards: 69
    From: “” ;tag=1c560830424
    To:
    Call-ID: [email protected]
    CSeq: 1 INVITE
    Contact:
    Supported: sdp-anat
    Allow: INVITE,ACK,OPTIONS,CANCEL,BYE,NOTIFY
    User-Agent: Mediant VE SBC/v.7.20A.202.204
    P-Asserted-Identity:
    Content-Type: application/sdp
    Content-Length: 589

    Any hints??

    Reply
    • 13th December 2018 at 5:04 PM
      Permalink

      Hi,

      Try adding the IP address of the SIP trunk to the SIP Group Name in the SIP trunk IP group.

      Lee

      Reply
  • 13th December 2018 at 3:56 PM
    Permalink

    Hi Lee,

    Sorry to bother you. on the SBC CDR history, it shows no answer and on teams, it rings for long but it doesn’t ring on the phone number I’m calling. Any hint as I’m stucked here.

    Please assist.

    Thank you,

    Reply
  • Pingback:Shawn Harry | Sipgate SIP (PSTN) trunk with Microsoft Teams Direct Routing via an Audiocodes SBC in Azure

  • 14th February 2019 at 1:29 AM
    Permalink

    Hi,

    I’m having issues with the Proxy Set connections (the image from the top of this guide). It picks up all the addresses in the SRV table, but status is “OFFLINE” with a number of failure counts. Teams interface is not behind a firewall and is connectd directly to the WAN. What can be the issue?

    Thanks.

    Reply
    • 14th February 2019 at 7:20 PM
      Permalink

      Hi David,

      Do you have a certificate issued and installed on the interface that connects to Teams?

      Thanks,
      Lee

      Reply
      • 12th March 2019 at 5:40 PM
        Permalink

        Yes, I have a godaddy cert issued and applied to the interface as instructed in the guide. What is the best way to identify the reason of the failure?

        Thanks.

        Reply
        • 14th March 2019 at 1:40 PM
          Permalink

          Hi,

          Are you able to connect to the SBC using Syslog and take a look – it should provide a reason e.g. timeout.

          Lee

          Reply
  • 20th February 2019 at 3:32 AM
    Permalink

    This is an outstanding write up. Trying to put a BOM together for a 100 session Mediant 500. I understand I need to order/purchase session capacity, but not clear if there’s an upcharge for SW/TEAMS licence? If so, is that licence charged by the SBC (i.e. 1 per SBC) or by the session? Are there any other hidden charges for TEAMS? Thanks all.

    Reply
    • 20th February 2019 at 10:09 AM
      Permalink

      Hi David,

      Thanks for the kind words.

      You will need a single “SW/TEAMS” license per AudioCodes SBC. This essentially enables the Teams compatibility for the SBC, irrespective of model or SBC session totals.

      If you’re not already aware, but you will also need to purchase the Software Assurance to go along with the licenses – this is for support.

      Are you planning to transcode your media between the SIP trunks and Teams (I suspect not)? If you are, you will transcoding licenses (and you may find 100 transcoded sessions might be too much for a 500)

      Thanks,
      Lee

      Reply
      • 20th February 2019 at 11:49 AM
        Permalink

        To add to Lee’s reply, the 500 (and its smaller brother the 500L) are optimised for a standard SIP to SIP role and need an additional license to enable connection to Microsoft solutions (this is in addition to the Teams license that Lee mentions). So its often more cost-effective to use the M800 which has the Microsoft license built-in (but still needs the Teams license). It also has higher capacity so gives more room for growth and supports Transcoding if required so is the recommended solution for SME connections to SfB or Teams. So I’d suggest that you look at both options. If you need more info please ping us at uksales ‘at’ audiocodes.com and we can give you a bom for both solutions that you can take to your reseller for pricing.

        Reply
  • 20th February 2019 at 12:19 PM
    Permalink

    Thanks John/Lee… very helpful. So the SW/TEAMS is per SBC. Got it. A couple more clarifications…

    I think the additional “Microsoft Licence” John mentions (“MSFT” – saw it in AUDC licence note) is also per SBC correct for the 500? Nominal charge or per session?

    Lastly, on support, is the “Software Assurance” support in addition to standard support? I understand AUDC and MSFT have a joint support process (which is good), but wondering if there’s an additional for it.

    Thanks again.

    Reply
  • 20th February 2019 at 12:39 PM
    Permalink

    The Microsoft License is per SBC, tho its not particularly nominal I’m afraid, we can give you guideline pricing if you ping us. I think Lee means standard support by ‘Software assurance’. As you said we do have a joint support process with MSFT which is partly funded by the two licences.

    Reply
    • 20th February 2019 at 1:52 PM
      Permalink

      John, I’ll be reaching out to the uksales soon to get a config. You piqued my interest though in the M800. You say the MSFT licence is built in. You mean included in the general SIP session capacity licence cost? Where the 500 there’s an upcharge?

      Reply
  • 20th February 2019 at 4:34 PM
    Permalink

    The M800 (and all bigger GW and SBC including the Virtual SBCs) has the Microsoft license included, so it applies to gateways as well as SBCs so isn’t tied to the SIP licenses as such. So on the M500 and M500L whether used as a GW or SBC you will need the Microsoft license. And in common with all the other GW and SBCs if you want to connect to Teams you need the Teams license as well.

    Reply
  • 5th March 2019 at 4:24 PM
    Permalink

    Hi, Can anyone help me? I’ve followed this guide and it seems that I can receive incoming calls perfectly, but outbound calls do not even get to the MS tenancy, neither does the bye request after I terminate the inbound call. So the outbound call leaves the handset, and doesn’t reach the MS tenancy (and doesn’t get as far as the SBC so as we can check the syslogs).

    Code on powershell done below(I’ve taken out he numbers and unique identifiers)

    SfB Online Powershell cmdlts done:
    Import-Module SkypeOnlineConnector
    $userCredential = Get-Credential
    $sfbSession = New-CsOnlineSession -Credential $userCredential
    Import-PSSession $sfbSession
    New-CsOnlinePSTNGateway -Fqdn sbc.xxxxxxxxx.com -SipSignallingPort 5067 -MaxConcurrentSessions 3 -Enabled $true
    Set-CsUser -Identity “[email protected]” -EnterpriseVoiceEnabled $true -HostedVoiceMail $true -OnPremLineURI tel:+44203
    Set-CsUser -Identity “[email protected]” -EnterpriseVoiceEnabled $true -HostedVoiceMail $true -OnPremLineURI tel:+44203
    Set-CsUser -Identity “[email protected]” -EnterpriseVoiceEnabled $true -HostedVoiceMail $true -OnPremLineURI tel:+44203
    Set-CsOnlinePstnUsage -Identity Global -Usage @{Add=”UK”}
    New-CSOnlineVoiceRoute -Identity “All” -NumberPattern “.” -OnlinePstnGatewayList sbc.teamsglemnet.com -Priority 1 -OnlinePstnUsages “UK”
    New-CSOnlineVoiceRoutingPolicy “UK” -OnlinePstnUsages “UK”
    Grant-CsOnlineVoiceRoutingPolicy -Identity [email protected] -PolicyName UK
    Grant-CsOnlineVoiceRoutingPolicy -Identity [email protected] -PolicyName UK
    Grant-CsOnlineVoiceRoutingPolicy -Identity [email protected] -PolicyName UK

    Reply
    • 5th March 2019 at 4:41 PM
      Permalink

      Hi Paul,

      I think the number pattern needs to be “.*” – “.” will match just a single digit. There could be other issues too, but that’s the first thing I would check.

      Lee

      Reply
  • 12th March 2019 at 11:19 PM
    Permalink

    Hi Lee,
    When I do Get-CsOnlinePSTNGateway – FQDN sbc.xxx.xxx
    In the output the CodePriority is blank. how can I set G711A .
    FYI, The output of this command shows that its pair with my SBC and I can see option is responded by 200OK on AudioCodes syslogs.
    Thank you
    Mas

    Reply
    • 13th March 2019 at 9:46 AM
      Permalink

      Hi,

      I believe the codec priority has now been removed. To force a certain codec to be used, you would need to only specify that in the SBC’s Coder Group. Warning: If you were to specify a codec for Teams that is different from the SIP trunk, you may need to transcode (licenses/hardware required).

      Thanks,
      Lee

      Reply

Leave a Reply