MSTEAMS: Multi-Level Sub-domains don't work

[mackhendricks]

We are getting reports that multi-level sub-domains don't work. Steps to reproduce:

Create a domain called:

*.mst.abcdomain.com

Then create a subdomain and add it to MSTeams and dSIPRouter:

sbc1.customer1.mst.abcdomain.com

Outcome:

Option messages to MSTeams will not work. Hence, inbound and outbound calls will not work

dSIPRouter currently is tested with one subdomain per the MS Documentation: https://docs.microsoft.com/en-us/microsoftteams/direct-routing-sbc-multiple-tenants#:~:text=Direct%20Routing%20supports%20configuring%20one,SBC)%20to%20serve%20multiple%20tenants.&text=This%20scenario%20is%20designed%20for,Microsoft%20Teams%20to%20their%20customers.

[reqlez]

Microsoft does have the "preferred" solution now, where you use "derived" trunks.

Basically, you create a domain: mst1.sip.provider.com Then, you register your trunk in MS Teams admin panel ( with New-CsOnlinePSTNGateway -fqdn mst1.sip.provider.com .... ) After that, any customers that you onboard, you do not ask them to add an SBC via Teams panel. What they do, is you create a subdomain for them ( in your DNS table only ) customer1.mst1.sip.provider.com add A record of the same teams server ( the root ) mst1.sip.provider.com then they verify the domain in their customer tenant ( you add the verification code they give you ).

After that, they still have to wait to create the domain, takes a few days sometimes ( in my case, took 5 days !!! ), they have to add an E3 / Business licensed user ( or E1 now as well ) with that new domain as the primary domain ( customer1.mst1.sip.provider.com ).

Then, after domain is fully provisioned, you can just add a ROUTE in their customer tenant versus adding the SBC like this: New-CsOnlineVoiceRoute -name mst1ProviderRoute -OnlinePstnGatewayList customer1.mst1.sip.provider.com -OnlinePstnUsages ProviderPSTN -NumberPattern "(.*)"

So I think if the project wants to see serious service providers get onboarded, we need to make this work for sure if it already is not. And need some documentation as well on how to make it work with dsiprouter.

[bcmike70]

I've gone through the process of creating domain mst.pbx.mydomain, and created an SBC for myself to test at sbc1.mst.pbx.mydomain which works fine.

So now to onboard a client I have to add a unique domain to their tenant right? So I add a subdomain of client.mst.pbx.mydomain to the client tenant. I verify that the client will work with the new domain Get-CsTenant | fl Tenantid,Domain*

So that's all set up I add the SBC to the client sbc1.client.mst.pbx.mydomain fine but Dsiprouter doesn't send or receive options messages

So you're saying I don't need to set up an SBC in the client tenant, just setup a voice policy that points to an A-record (which is a host in the client subdomain) that points to dsiprouter and it'll just work? So what has to happen in Dsiprouter? Do you just add the domain as usual?

[reqlez]

i'm saying with the derived trunks solution you do not, I do not know if this works with dsiprouter yet or not. Also you will have to have a *.mst.pbx.mydomain certificate installed on the dsiprouter for sure, to even begin to test. i haven't tested yet

But in a perfect world, yes, you would verify the client.mst.pbx.mydomain on their tenant and add the ROUTE only to client.mst.pbx.mydomain.

I noticed that you used sbc1.client.mst.pbx.mydomain I read somewhere this does not work confirmed, I think you might want to try to add client1.mst.pbx.mydomain or something

assuming you added your TRUNK in your tenant as "mst.pbx.mydomain" and added "mst.pbx.mydomain" to dsiprouter

[bcmike70]

Thanks for the feeedback. I do have the wildcard cert set up on Dsiprouter. sbc1 was just the host name, I can easily change it. I'll try this out ASAP and report back.

[reqlez]

well, now that i'm thinking about it... you would have to have for sure:

mst.pbx.mydomain in dsiprouter as WELL as client1.mst.pbx.mydomain in dsiprouter otherwise, how are you going to route calls to different customer domains, plus maybe needed for auth.

all i'm trying to say, is that the derived trunks idea, only thing it does, it saves you from having to add an SBC to each client tenant, and just add a route to client1.mst.pbx.mydomain instead. you still have to verify the client tenant domain "client1.mst.pbx.mydomain" inside the client tenant, and that can take several days it seems with MS servers being so slow.

I have 0 clue if this works with dsiprouter, experiment at your own risk ( of loss of time hahah ) ;-)

However, if we can get this to work, I think it will be very nice.

[bcmike70]

Ya I think we've circled around to the original issue, Dsiprouter won't listen for TLS on client.mst.pbx.mydomain.com.

[reqlez]

also i just saw something, Mack mentioned that you have to create a subdomain in dsiprouter called *.mst.pbx.mydomain not mst.pbx.mydomain, maybe he can confirm.

[reqlez]

okay and you have an A record obviously on client.mst.pbx.mydomain.com that points to IP of mst.pbx.mydomain.com I mean no disrespect, just confirming lol

[reqlez]

Just heads up. Ill be doing more testing on this once the 0.64 branch is fully fixed up with install issues, so that way I have an official "clean" install before I start testing on CentOS 8.2

[bcmike70]

Any idea when 0.64 will be ready for us to do an upgrade?

[reqlez]

Well, it is sort of ready ( almost ? ), there are just a few things to clean up I think from the tests i have done. I do not know the team's timelines and what they consider a "release".

If you ask me, I would not upgrade to 0.64 at least until I confirm that the install script is working. I have no idea if anybody even tested the upgrade part yet, i will leave that answer to somebody else.

[reqlez]

Any idea when 0.64 will be ready for us to do an upgrade?

By the way, the 0.64 install does work now on CentOS 8, I'm assuming 7 as well. Personally, have not tested Debian tho. However, there are a few more PRs going into 64 it seems, so maybe you want to wait for those? or u can test ?

again, have not tested upgrade script so about that I do not know. Maybe faster to just save your certificate files and do a fresh install if you have a snapshot handy for a clean system.

[bcmike70]

Thanks for the update. I'm running Debian so I might wait for a bit.

Back to the original issue I sort of got things to work, but not really. Here's what's going on: On my Disprouter the wildcard cert is *.mst.mydomain.com. For my client in their 0365 instance I've created nhs.mst.mydomain.com, verified for use with teams, etc, etc. I created an SBC; sbc1.nhs.mst.mydomain.com (direct routing requires a host name inf ront of the domain) . All the dns records are setup to point at the Dsiprouter. On the Dsiprouter I've created the domain nhs.mst.mydomain.com. Sip options are flowing in both directions and on the teams side its says that the SBC is good with both options and tls. Yay us! One big problem though, I can't send any calls to teams and I can't receive any calls from teams. I've double checked routing on both ends and can't find the issue. I'm thinking Dsiprouter might not know what to do with calls coming from sbc1.nhs.mst.mydomain.com, but I need some sort of visibility into the call to know what's going on. Of course it's all TLS so sngrep is no good. I've used ssldump to see that the handshake is actually occurring. I guess my latest question is does Dsiprouter support HEP, or more specifically HOMER so that we can take a look at the actual call? Or is there something else that would give us visibility?

[reqlez]

Thanks for the update. I'm running Debian so I might wait for a bit.

Back to the original issue I sort of got things to work, but not really. Here's what's going on: On my Disprouter the wildcard cert is *.mst.mydomain.com. For my client in their 0365 instance I've created nhs.mst.mydomain.com, verified for use with teams, etc, etc. I created an SBC; sbc1.nhs.mst.mydomain.com (direct routing requires a host name inf ront of the domain) . All the dns records are setup to point at the Dsiprouter. On the Dsiprouter I've created the domain nhs.mst.mydomain.com. Sip options are flowing in both directions and on the teams side its says that the SBC is good with both options and tls. Yay us! One big problem though, I can't send any calls to teams and I can't receive any calls from teams. I've double checked routing on both ends and can't find the issue. I'm thinking Dsiprouter might not know what to do with calls coming from sbc1.nhs.mst.mydomain.com, but I need some sort of visibility into the call to know what's going on. Of course it's all TLS so sngrep is no good. I've used ssldump to see that the handshake is actually occurring. I guess my latest question is does Dsiprouter support HEP, or more specifically HOMER so that we can take a look at the actual call? Or is there something else that would give us visibility?

Sorry, where did you read that Teams requires a hostname in front of the domain name to route calls? I had a working direct routing implementation with dsiprouter using the root A record of a domain added to Teams before... And I was working with another provider as well on their direct routing setup, and they also had the same setup using the root A record of a domain...

[reqlez]

Also, i tested by installing HOMER on the same host as the dsipserver ( okay I know, bad idea, but i did not want to spin up another VM ) and I am able to capture into HOMER just by running this on the dsiprouter host as root: ./heplify

I guess if you have another homer server somewhere else, you could do: ./heplify -hs homerserver.mytestlab.com:9060 -nt tls

I'm sure kamailio can be configured to forward to homer in the config files, since kamailio and homer are fairly integrated ( you can even use kamailio as homer SIP proxy ) however, this is easier and faster.

[bcmike70]

Thanks for the update. I'm running Debian so I might wait for a bit. Back to the original issue I sort of got things to work, but not really. Here's what's going on: On my Disprouter the wildcard cert is *.mst.mydomain.com. For my client in their 0365 instance I've created nhs.mst.mydomain.com, verified for use with teams, etc, etc. I created an SBC; sbc1.nhs.mst.mydomain.com (direct routing requires a host name inf ront of the domain) . All the dns records are setup to point at the Dsiprouter. On the Dsiprouter I've created the domain nhs.mst.mydomain.com. Sip options are flowing in both directions and on the teams side its says that the SBC is good with both options and tls. Yay us! One big problem though, I can't send any calls to teams and I can't receive any calls from teams. I've double checked routing on both ends and can't find the issue. I'm thinking Dsiprouter might not know what to do with calls coming from sbc1.nhs.mst.mydomain.com, but I need some sort of visibility into the call to know what's going on. Of course it's all TLS so sngrep is no good. I've used ssldump to see that the handshake is actually occurring. I guess my latest question is does Dsiprouter support HEP, or more specifically HOMER so that we can take a look at the actual call? Or is there something else that would give us visibility?

Sorry, where did you read that Teams requires a hostname in front of the domain name to route calls? I had a working direct routing implementation with dsiprouter using the root A record of a domain added to Teams before... And I was working with another provider as well on their direct routing setup, and they also had the same setup using the root A record of a domain...

No I was just following the tutorial video and notice the host name was put into place on Dsiprouter as opposed to teh domain name. On the teams side you need the hostname for sure as it won't let you enter the SBC without the hostname.

[bcmike70]

Also, i tested by installing HOMER on the same host as the dsipserver ( okay I know, bad idea, but i did not want to spin up another VM ) and I am able to capture into HOMER just by running this on the dsiprouter host as root: ./heplify

I guess if you have another homer server somewhere else, you could do: ./heplify -hs homerserver.mytestlab.com:9060 -nt tls

I'm sure kamailio can be configured to forward to homer in the config files, since kamailio and homer are fairly integrated ( you can even use kamailio as homer SIP proxy ) however, this is easier and faster.

My main goal here is to see whats happening between teams and dsiprouter. Do you have visibilty into this when your run ./heplify?

[reqlez]

Yes you can see all the traffic.

[devopsec]

Have not seen any movement on this issue in a long time.
Is this still an issue??