• V20: 3CX Re-engineered. Get V20 for increased security, better call management, a new admin console and Windows softphone. Learn More.

Microsoft Teams Direct Routing with 3CX

webstean

Customer
Joined
Jul 14, 2021
Messages
11
Reaction score
1
Hi All,

I've setup a kamailio (kamailio.org) as a registered SBC for Microsoft Direct Routing proxying into a 3CX instance. Both kamailio and 3CX are in the same private network (VNET) in Azure with acces to the Internet via NAT. 3CX was built with express.

So I can receive phone calls from Microsoft Teams in 3CX - which is great, except the RTP media setup fails, so the call it never answered.

So first questioin, is 3CX actually compatible with Microsoft Teams codecs - or do you need to transcode?

FYI: As the 3CX instance is in the cloud, I have 3CX SBCs at each site as Raspberry Pis.

BTW: All Direct Routing Microsoft Teams calls are encrypted RTP/SAVP and I have media bypass TURN OFF (the default).

I believe the firewall rules are correct - so that shouldn't be the issue

Some reference material:
https://www.3cx.com/docs/sip-trunk-codecs-sdp/
https://docs.microsoft.com/en-us/microsoftteams/direct-routing-plan

I'm having trouble understanding the above.

Any help suggestions/appreciated :)

Here's a sample invite:-

07/14/2021 11:06:17 AM - [CM500002]: Call(C:340): Info on incoming INVITE from Line:10001<<anonymous:
Invite-IN Recv Req INVITE from 10.0.0.6:58320 tid=6dfe.472527ab836ad1dad51c7dd997839cfc.0 Call-ID=6a99ca46cd2559eca7958b167f24f6c0:
INVITE sip:[email protected]:5061;user=phone;transport=tls SIP/2.0
Via: SIP/2.0/TLS 52.189.194.44:5061;branch=z9hG4bK6dfe.472527ab836ad1dad51c7dd997839cfc.0;received=10.0.0.6;i=f
Via: SIP/2.0/TLS 52.114.148.0:5061;rport=8513;branch=z9hG4bKf7244afb
Max-Forwards: 69
Record-Route: <sip:sip-du-a-us.pstnhub.microsoft.com:5061;transport=tls;lr>
Contact: <sip:api-du-c-auea.pstnhub.microsoft.com:443;x-i=53745319-775e-414f-a9f5-1da8b075b80e;x-c=6a99ca46cd2559eca7958b167f24f6c0/d/10/ba8234ca8f7f4aa091cb7c2c2b8f9a89>
To: <sip:[email protected]:5061;user=phone>
From: <sip:[email protected]>;tag=bb1454cf156d4b2b8923abbf5b03d699
Call-ID: 6a99ca46cd2559eca7958b167f24f6c0
CSeq: 1 INVITE
Session-Expires: 3600
Min-SE: 300
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, NOTIFY
Content-Type: application/sdp
Supported: timer
User-Agent: Microsoft.PSTNHub.SIPProxy v.2021.6.15.17 i.USWE2.7
Privacy: id
P-Asserted-Identity: <sip:[email protected]>
Content-Length: 1105

v=0
o=- 140019 0 IN IP4 127.0.0.1
s=session
c=IN IP4 52.114.192.162
b=CT:10000000
t=0 0
m=audio 52872 RTP/SAVP 104 9 103 111 18 0 8 97 101 13 118
c=IN IP4 52.114.192.162
a=rtcp:52873
a=ice-ufrag:XFX6
a=ice-pwd:ImzOTcSdXPjEAhwX+ZJiiAWr
a=rtcp-mux
a=candidate:1 1 UDP 2130706431 52.114.192.162 52872 typ srflx raddr 10.0.33.52 rport 52872
a=candidate:1 2 UDP 2130705918 52.114.192.162 52873 typ srflx raddr 10.0.33.52 rport 52873
a=candidate:2 1 tcp-act 2121006078 52.114.192.162 49152 typ srflx raddr 10.0.33.52 rport 49152
a=candidate:2 2 tcp-act 2121006078 52.114.192.162 49152 typ srflx raddr 10.0.33.52 rport 49152
a=label:main-audio
a=mid:1
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:RaqXOiKePBlncGJ5KzzcmIKtxU9zym7rfkkQINpc|2^31
a=sendrecv
a=rtpmap:104 SILK/16000
a=rtpmap:9 G722/8000
a=rtpmap:103 SILK/8000
a=rtpmap:111 SIREN/16000
a=fmtp:111 bitrate=16000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 RED/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:13 CN/8000
a=rtpmap:118 CN/16000
a=ptime:20
 
PS: Here is my version of 3CX:-
ProductProfessional Annual
Version Number18.0.1379
 
I remember that 3CX is considering implementing teams direct routing integration. You can wait for that. No need to use a third-party SBC.
 
  • Like
Reactions: ConceptsWeb
It wouldn't be hard, you have to handle the SIP OPTIONS pings and Route Headers as per Microsoft reqirements, which Kamailio does with ease.
The only argument against 3CX supporting it directly, is that generally it isn't the best security idea to have your senstive PABX exposed directly to the Internet, but to use a proxy (aka SBC for that) in front of it. Of course, 3CX mitigate a lot of the risks with functionality like blacklisting (a culturally insensitive term) repeating failed attempts.

Probably the larger "issue" is supporting more modern audio codecs: SILK (used by Teams) and things like OPUS. They would have to working on OPUS, as Fanvil (their preferred handset vendor) has made a big deal about supporting OPUS will their latest handsets.

Forgetting anything technical, why would 3CX support teams directly? It's a competitor. It is also expensive competitor. Microsoft only support Direct Routing via "approved" SBC vendors, so if 3CX added the "direct routing" capability, to be supported by Microsoft who knows what hoops they would need jump through. Why would Microsoft be interested in helping a competitor? Would 3CX be interested in delivering a capability that was not explicitly approved/supported by Microsoft. Maybe not.
 
We built our own SBC for Teams direct routing that works just fine with 3CX, biggest complaint is that presence is not shared. Also it is very expensive from Microsoft once you start adding a decent amount of users.

Here is our guide: https://voxtelesys.com/tutorial/teams-vox-sbc-setup
FYI there are other vendors out there as well but I think we are one of the few that are selling it similar to the 3CX model (simultaneous calls and not per user). All said and done 3CX is way better and soft clients work great.
 
Thanks Kevin, does your SBC transcode the codecs in order to work?
 
Thanks Kevin, does your SBC transcode the codecs in order to work?
I believe so, I know MS uses a different codec and we handle the translation in our SBC. I can ask an engineer on my end to confirm.
 
I believe so, I know MS uses a different codec and we handle the translation in our SBC. I can ask an engineer on my end to confirm.
Great - look forward to your reply
 
Has it been said how the 3CX Teams SBC is hosted? Translations managed? Our support team is upgrading a test system now to try it out but was curious on how that will be handled.
 
There is no in-between hardware or software, each 3CX installation communicates directly with the Teams servers.
 
  • Like
Reactions: Alphabetic
Does 3CX support of native Teams Direct Routing require running 3CX under Windows?

"Step 3: Configure dial plan and run script" indicates "Start Windows Powershell as Administrator".
Where does this need to be run?
 
Does 3CX support of native Teams Direct Routing require running 3CX under Windows?

"Step 3: Configure dial plan and run script" indicates "Start Windows Powershell as Administrator".
Where does this need to be run?
On a Windows PC that has PowerShell. That's it.

The PBX OS is irrelevant here.
 
  • Like
Reactions: NickD_3CX
Some things to keep in mind:-
  • 3CX is acting as a SBC as Microsoft call it, but they only support "certified" SBC vendors, so Microsoft could decline to support you.
  • 3CX currently require a "real" $$ certificate, but the free let's encrypt certificates definately work. So would be nice, if 3CX could support creating that certificate and handling the renewal.
 
3CX currently require a "real" $$ certificate, but the free let's encrypt certificates definately work. So would be nice, if 3CX could support creating that certificate and handling the renewal.

MS might also decline you support if you do not use one of those certificates...
Unlike 3CX domains, we are not able to create this cert in LE for you as it is outside of our managed domain.
ACME validation would require port 80/443 for an HTTP(s) validation call, however, we have this domain (of the "SBC") only on a SIP port (5061 or 5062) exposed. Lastly, the cert is only valid from LE for 90 days, so who will do manual cert update work every 90 days?

Let's face it, one user only with the MS Phone System add-on cost you already 80$ per year.
In comparison is a 1y certificate less than this. Therefore not worth the discussion about the cert.
 
  • Like
Reactions: ConceptsWeb
Does 3CX support of native Teams Direct Routing require running 3CX under Windows?

"Step 3: Configure dial plan and run script" indicates "Start Windows Powershell as Administrator".
Where does this need to be run?

You can run the script from any platform which can run PowerShell commands. You need to be able to instal the Teams Power-Shell add-on (cmdlet). For this, on windows, Admin rights are needed. On other platforms, I cannot tell you how to run power shell in order to install this cmdlet
 
MS might also decline you support if you do not use one of those certificates...
Unlike 3CX domains, we are not able to create this cert in LE for you as it is outside of our managed domain.
ACME validation would require port 80/443 for an HTTP(s) validation call, however, we have this domain (of the "SBC") only on a SIP port (5061 or 5062) exposed. Lastly, the cert is only valid from LE for 90 days, so who will do manual cert update work every 90 days?

Let's face it, one user only with the MS Phone System add-on cost you already 80$ per year.
In comparison is a 1y certificate less than this. Therefore not worth the discussion about the cert.
It's the host inside the Microsoft domain, that needs the certificate, for example:
sbc.myoffice365.com
So 3CX could simply host that name, provided the customer point their Microsoft managed DNS at it, that way you'd be able to handle the ACME validation and renewing every 90 days wouldn't be a problem.

Your point around the cost of the Phone System is valid, but BTW it's half that price for Non-for-Profits - who are trying to save every single cent.

I hope you guys are working on Teams transfer functionality, since it confuses the heck out of users, when they try and trasfer a call and it doesn't work.
 
Get 3CX - Absolutely Free!

Link up your team and customers Phone System Live Chat Video Conferencing

Hosted or Self-managed. Up to 10 users free forever. No credit card. Try risk free.

3CX
A 3CX Account with that email already exists. You will be redirected to the Customer Portal to sign in or reset your password if you've forgotten it.