Teams Direct Routing Cross Tenant Migration

 

Direct Routing – your own SBC with a PSTN Provider

Best option as usual is the Direct Routing. Where I will focus on in this blog article.


During migration, there might be other services using PSTN, like a PBX or even a Call Center. This is not part of this migration consideration, but with the described migration approach, it is separated from the Teams migration. This will provide you with more flexibility than the other PSTN interaction possible in Teams.

In general with any PSTN provider it is difficult or even impossible splitting PSTN number block along with your migration of users. Therefore another approach must be implemented.

Additionally the described process also eliminates the need of additional SBCs in your environment and protects your investment.

The idea and used method is called DUAL FORKING.

Dual forking is the possibility addressing a call to multiple destinations. In our case we want this dual forking happening between two Microsoft M365 Tenants.

 

How is a call established with the SIP protocol.

Phone System Direct Routing - Microsoft Teams | Microsoft Docs


We start with the generic understanding of SIP in Microsoft TEAMS.

The following illustration shows an incoming to the phone number 0049-89-1234-1000, which should be Bob’s Team phone number. It contains a Refer, which is not relevant for the further explanation of the migration solution.

Important is the process of INVITE, TRYING, RINGING, SESSION PROGRESS and OK, ACK. In the next illustration if simplify the call setup. But here you see the client involved, with is explained in detail within the MS DOC’s article.




The illustration in detail:

INVITE: Call is send from the SBC to the M365 SIP Proxy, where the phone number is identified for the called user.

100 TRYING: while M365 tries calling the users Teams Client

180 RINGING: if the user was found and the call is signaled to the respective client, the phone ringing is initiated

200 OK: The client will take the call

ACK: Taking the call is acknowledged

MEDIA: The media, talking takes place

BYE: here the caller ends the call

200 OK: The client/ M365 acknowledges the call ending


We assume now a user has been migrated, but the phone number is present in the number block assignment. Therefore the callee cannot be reached. Microsoft Teams well drop the call with a 404. This SIP 404 Not Found is the message send back to the SBC and the PSTN call will be dropped.


This are the two scenarios we need to understand on how SIP call establishment works.

If a user is migrated incl. his Teams PSTN number, a call send to the source tenant will be dropped due to 404 Not Found. In our migration we still want this call to be answered by the target tenant. This implies that we need to send a INVITE into it. We can do so with a  single SBC configured for Direct Routing.

The generic setup looks like the illustration below.

During the migration, a call is generally signaled into both, the source and the target tenant. We want this scenario. As if a users has been migrated, it doesn’t matter where the phone number is assigned. One of the both tenants will answer, while the tenant where the phone number isn’t present will drop the call.

This is amazing, as we do NOT need to individually configure any phone number on the SBC.

Some requirements are necessary here:

1.       Setup to INTERNET facing SIP Interfaces with different IP’s
This is a must, because Microsoft Teams SIP Proxy, cannot differentiate a call from a single IP for different tenants.

2.       Use if possible two different Certificates
(Note: SAN entries will still work, but you will later decommission the source tenant, best keep the new certificate for the target tenant as it is)

If you do not follow this advice, the Dual Forking will FAIL !

In this configuration, it is absolutely required that any 404 Not Found message must be DROPPED at the SBC.

The next illustration show’s the call drop to the user how is not assigned with a phone number in Teams. Say Bob is migrated and has a phone number in the target Teams tenant, signaling into the source will cause the 404 and established the call within the target tenant.

Opposite for Jane, who isn’t migrated and not present in the target tenant with a PSTN number assigned, the target tenant will answer with a 404 and the source tenant will stablish the call.



Now you understand how simple a Teams Enterprise Voice migration from the user perspective can be.

NOTE:

It is still required to consider Call Queues, as all users in a CQ must be migrated at the same time, including the Call Queue. Do not try splitting the users, CQ in this case is broken.

Comments

Popular posts from this blog

Skype for Business, Lync and Exchange Web Services (EWS) and different DNS Domains- Exchange crawling e.g. for presence

Teams Guest User Access via ADD management

Certificate Requirements Teams Direct Routing SBC