By Simon Woodhead
We’re delighted to let you know that those in our carrier services beta programme now have access to Teams Operator Connect (OC). Meanwhile, to avoid confusion new Teams Direct Routing (DR) trunks can no longer be added.
The set-up for DR is just horrid and given it requires steps by the end-user, really doesn’t lend itself to use in a carrier services environment. It has proved to be a large support sink given the steps and waiting involved in setting it up, which we cannot improve any more. Existing configured trunks will continue to work but new ones cannot be added, and those using DR are encouraged to migrate to OC for a much more pleasant experience and some enhanced Simwood-side functionality. However, if you come across volume edge-cases which require DR do please talk to us as we have the capability where it is necessary.
When it comes to OC, we’ve decided to re-architect things to give far greater flexibility. The idea of a ‘Teams’ trunk type as we had for DR made sense at the time, but in the world of the Potato, is a bit odd. For OC, assisted by the much nicer workflow from Microsoft, a given Teams tenant (your customer) can be linked entirely from the Simwood portal/API, and numbers pushed to Teams. This creates a Teams tenant which is completely abstracted from trunks or any level of routing (account, trunk or number-specific), and obviously, you can have as many Teams tenants (your customers) as you like. You’ll need to associate numbers and users within the Teams environment although we’ll have pushed any numbers there that you’ve asked us to.
Outbound calls from the Teams environment will, by default, use your default trunk but you can associate any tenant with a Simwood trunk and pick up the settings therein instead. However, the astute amongst you will spot a further option there: SIP. Yes, with this, we’ll receive calls from the Teams environment and relay them to your chosen endpoint using our usual URI templating options. If you’re a UCaaS provider who wants to offer Teams to your users, this is the way to hairpin the calls through your own platform, even if you eventually send them back to us for PSTN termination. Pricing on this TBC.
Inbound calls from other sources, let’s say the PSTN or SIP for example, will pick up the routing in exactly the same way as they do for other transports, i.e. will use your account-level config, or a trunk-level config if a trunk is linked, or a per-number config if there is one. Therefore, if you want inbound calls to be routed to Teams you’ll need to add Teams to the routing plan. This is the difference to how we did DR – your Teams tenants can now be used in routing anywhere, just like SIP and other transports..
So yes, you can route to Teams but fall back to SIP, or route to Teams during office hours and a PSTN fall-back thereafter. Oh, and yes, if the trunk concerned has other features such as call recording enabled, these will apply to your Teams calls too. This is the power of the Potato!
Before you ask – yes, this will be coming to Sipcentric/Hosted soon: early Q3.
