Teams Direct Routing Cross Tenant Migration
Best option as usual is the Direct Routing. Where I will focus on in this blog article.
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
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.
We start with the generic understanding of SIP in Microsoft TEAMS.
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
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
1. Setup to INTERNET facing SIP Interfaces with different
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.
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.