Direct Routing Konfiguration
Am 15. Mai wurde die Funktion "Direct Routing" als Public Preview frei gegeben. Damit kann nun jeder mit einem Office 365 Tenant im Rahmen einer Evaluierung einen SIP-Trunk zu Microsoft Teams in Office 365 einrichten. Ich beschreibe hier die erforderlichen Schritte, um mit einem direkten SIP-Trunk von einem lokalen Session Border Controller und Microsoft Teams zu telefonieren. Das Feature wurde auf der Enterprise Connect im April 2018 angekündigt.
Teams On Air: Ep. 65 Direct Routing
for enterprise voice in Microsoft Teams
https://www.youtube.com/watch?v=VAF4iFB24Mo
PDF-Datei mit den Zusammenhängen von
Polices, Routen u.a.
http://aka.ms/mtvr
Unterstützung durch
Net at Work:
Sie wollen keinen SBC selbst betreiben
aber nicht auf
Operator
Connect setzen?. Dann lassen sie doch die SBC-Funktion
betreiben.
https://www.netatwork.de/managed-sbc/
- 29. Jun 2018: Direct Routing ist General
Available
http://aka.ms/dr - Direct Routing NOW in Public Preview
https://techcommunity.microsoft.com/t5/Microsoft-Teams-Blog/Direct-Routing-NOW-in-Public-Preview/ba-p/193915 - Quick Start Guides
https://aka.ms/CallingGuidance - Plan Direct Routing
https://aka.ms/drplandirectrouting - Configure Direct Routing
https://aka.ms/drconfiguredirectrouting - deep dive recording
https://aka.ms/dr-training -
Checklisten
Eine Übersicht aller Checklisten der MSXFAQ
Umgebung und Vorarbeiten
Technisch ist die Anbindung per Direkt Routing ein einfacher SIP-Trunk, wie er zu tausenden schon zur Anbindung von TK-Anlagen und Amtsleitungen genutzt wird. Es wird ja auch "nur Sprache" übermittelt. Microsoft nutzt auch hier die aus Skype for Business und Lync bekannten Ports:
- Kommunikation per SIP/TLS über Port 5067
- Media zwischen den SBCs über UDP 49152-65535
- Media von Clients zum SBC über 50.000-50.019 als Quellport beim Client
Insofern ist das auch für die Firewall-Administratoren eine überschaubare Konfiguration:
Natürlich muss bei der Signalisierung noch auf das ein oder andere geachtet werden, d.h. die Rufnummernformate sind vorgeschrieben und auch zusätzliche Felder wie P-AssertedID u.a. müssen von der lokalen SBC richtig verarbeitet und gesetzt werden. Die Konfigurationsmöglichkeiten in Teams sind da doch beschränkt. Hier eine Checkliste, ob Sie schon für Direct Routing bereit sind.
Checkliste | Status |
---|---|
Office 365 Tenant und LizenzenAuch wenn es eigentlich jedem klar sein sollte. Sie benötigen schon einen Office 365 Tenant. Die Dataregion oder Sprache des Tenant ist ebenso unwichtig wie die Verwaltung der Anwender (z.B. AADConnect) und die Authentifizierung. Allerdings muss der Tenant natürlich auch "Teams" beheimaten, d.h. Sie benötigen die passenden Lizenzen für die Anwender. In der DE Cloud - die deutsche Microsoft Cloud wird meines Wissens "Teams" noch nicht unterstützt. |
|
Zertifizierte SBCsMicrosoft hat die Anbindung nur für ausgewählte SBCs dokumentiert.
Dazu gehören:
Ich bin aber sicher, dass sehr bald auch die anderen Hersteller offiziell zertifiziert sind. Aktuell habe ich von Ferrari Electronic und Anynode entsprechende Tweets gelesen, dass deren SBCs schon funktionieren. |
|
FQDN und Public-IP für die SBCDie SBC muss später von Office 365 erreichbar sein. Daher muss der Service über die entsprechenden Port (SIP/TLS 5067) und RTP 49152/UDP – 65535/UDP erreichbar sein. Das sind die Ports, mit denen Office 365 RTP annimmt und mit denen es Sendet. ihre lokalen Ports können andere sein. Idealerweise hat die SBC direkt die IP-Adresse. Ich kann mir aber auch vorstellen, dass die SBC hinter einer Firewall mit 1:1 NAT-Umsetzung betrieben werden kann. Die SBC muss dann aber die NAT-IP in den Kandidaten der SDP-Liste addieren. Der FQDN ist fast frei wählbar. Er muss zu einer ihrer in Office 365 registrierten Domäne gehören und kann nicht in der Domäne "%tenantname%.onmicrosoft.com" sein. Wenn also "msxfaq.net" meine Office 365-Domäne ist, dann wäre "sbc.msxfaq.de" schon mal möglich. Eine Subdomäne wie "sbc.teams.msxfaq.net" erfordert, dass ich auch "teams.msxfaq.net" in Office 365 schon registriert habe. |
|
Öffentliches ZertifikatDie Verbindung zu Teams erfolgt per SIP/TLS über Port 5067. Entsprechend muss der SBC ein Zertifikat haben. Microsoft unterstützt hier aktuell folgende Stammzertifizierungsstellen:
Das Zertifikat kann den FQDN des SBCs enthalten oder alternativ kann auch ein Wildcard-Zertifikat genutzt werden, welches die exakte Domain beinhaltet. ein "*.msxfaq.net" deckt also auch teamssbc.msxfaq.net ab aber kein sbc.teams.msxfaq.net. |
|
Lizenz pro BenutzerDamit die Teams-Anwender mit Direct Routing telefonieren können, benötigen Sie folgende Lizenzen:
Anwender benötigen keinen "Microsoft Calling Plan", also Minutenpakete, wenn Sie mit Direct Routing telefonieren. Sie können diese Funktion aber weiterhin zusätzlich nutzen. Die Hauptnummer kommt dann natürlich von Microsoft aber die Anwender können bestimmte Anrufe dann über die Direkt Routing fahren um z.B. Gegenstellen der lokalen TK-Anlage anzusprechen. Wenn der Anwender Audiokonferenzen mit einer Einwahl über die Microsoft Nummern unterstützen soll, dann braucht er natürlich noch eine "Audio Conferencing"-Lizenz.
|
|
Namensauflösung und VerbindungDer SBC muss eine Verbindung zu Microsoft aufbauen können. Dazu hat Microsoft mehrere DNS-Namen veröffentlicht. Hinweis: Die Auflösungen hier sind vom März 2018 und in Deutschland gemacht worden. Die Ergebnisse können je nach Provider und Land anders aussehen.
Achtung: Dieser Name sollte nicht mehr genutzt werden. Mit Mitteilung vom 21.12.2021 wird Microsoft diese Namen zum 1. März 2022 abschalten. C:\>nslookup sip-all.pstnhub.microsoft.com Name: sip-all.pstnhub.akadns.net Addresses: 52.114.76.76 52.114.148.0 52.114.132.46 52.114.14.70 52.114.7.24 52.114.75.24 Aliases: sip-all.pstnhub.microsoft.com
C:\>nslookup sip.pstnhub.microsoft.com Name: sip-du-a-euno.northeurope.cloudapp.azure.com Address: 52.114.76.76 Aliases: sip.pstnhub.microsoft.com sip.pstnhub.trafficmanager.net
C:\>nslookup sip2.pstnhub.microsoft.com Name: sip-du-a-uswe2.westus2.cloudapp.azure.com Address: 52.114.148.0 Aliases: sip2.pstnhub.microsoft.com sip2.pstnhub.akadns.net sip-du-a-us.pstnhub.trafficmanager.net
C:\>nslookup sip3.pstnhub.microsoft.com Name: sip-du-a-asea.eastasia.cloudapp.azure.com Address: 52.114.7.24 Aliases: sip3.pstnhub.microsoft.com sip3.pstnhub.akadns.net sip-du-a-as.pstnhub.trafficmanager.net |
|
ZertifikateDa alle Kommunikation per SIP über TLS erfolgt, sollten Sie sicherstellen, dass der SBC den von Microsoft gelieferten Zertifikate bzw. genauer der RootCA vertraut. Hardware-Gateways haben im Gegensatz zu Windows () keine eingebaute Funktion, um Stammzertifikate automatisch nachzuladen. Auch müssen Sie darauf achten, dass das von ihrem SBC genutzte Zertifikat auch von Microsoft vertraut wird. Microsoft vertraut nicht allen RootCAs. Hier kann es auch Änderungen geben, d.h. überwachen Sie für ihren Tenant das Microsoft 365 Message Center
|
|
Die Folie von Microsoft ist hier etwas oberflächlicher:
Quelle: Teams On Air: Ep. 65 Direct Routing
for enterprise voice in Microsoft Teams
https://www.youtube.com/watch?v=VAF4iFB24Mo
Einrichtung SBC On-Premises
Die Einrichtung in der Cloud habe ich hinter die aufwändigere lokale Einrichtung gestellt. Denn ohne einen lokalen zertifizierten Session Border Controller (SCB), der auch noch aus der Cloud erreichbar ist, geht erst mal nichts. Er muss mit einer öffentlichen IP-Adresse verstehen Sein und SIP/TLS mit einem von Microsoft als vertrauenswürdigen Zertifikat sprechen. Per Default kommt der SIP-Port 5067 zum Einsatz. Zusätzlich sind natürlich noch größere UDP-Ports für die Übertragung von Audio und Video freizuschalten.
Aktuell ist meine Anbindung über denen Mediant 1000 realisiert, welcher eine öffentliche IP-Adresse hinter einer Firewall hat. Achten Sie darauf, dass
- Nur Verbindungen per TLS mit einem "Trusted
Zertifikat" möglich sind.
Das verhindert schon einmal die Zugriffe von anonymen SIP-Angreifern ohne passendes Zertifikate - Beschränken Sie die IP-Adressen
Microsoft veröffentlicht die IP-Adressen, über die Office 365 einen "INVITE" an ihren SBC sendet. Ansonsten können Sie auch hier den Namen im Zertifikat als Filter nutzen - Wählregeln
Ihr SBC darf unter keinen umständen anonyme INVITES annehmen und Sie sollten über Filter auch steuern, welche Rufnummern jemand erreichen kann. Gerade am Anfang macht es durchaus Sinn, die "teurer" Premium-Nummern zu blockieren. - Logging
Aktivieren Sie auf jeden Fall eine Protokollierung der Anrufe. Zum Einen is ein CDR-Logging zur Dokumentation der erfolgten Anrufe sinnvoll aber auch ein Syslog-Trace der SIP-Kommunikation ist durchaus für einige Tage interessant, um Missbrauch oder Fehler nachvollziehen zu können. Solche Dateien können und sollten aber auch nach einigen Tagen (Datenschutz) wieder gelöscht werden. Wenn möglich können Sie auch ein Monitoring auf "Anrufe pro Stunde" o.ä. einrichten um sehr schnell reagieren zu können, wenn ungewohnt hohe Anrufzahlen auftreten.
Es wäre schon sehr ungeschickt, wenn die "War-Dialer" aus den frühen Zeiten über ihre Telefonanbindung kostenfrei telefonieren können. Ärgerlicher ist es, wenn hohe Kosten auflaufen oder sogar Straftaten mit verschleierter Rufnummer möglich wäre. Es gelten also die Reglen zur Sicherung eines SBC mit Verbindung aus dem Internet.
- Microsoft Azure Datacenter IP Ranges
https://www.microsoft.com/en-us/download/details.aspx?id=41653 -
SBC
Absicherung
Wenn ihr SBC zu freizügig ist, telefonieren andere auf ihre Kosten
Unterstützung durch
Net at Work:
Sie wollen keinen SBC selbst betreiben
aber nicht auf
Operator
Connect setzen?. Dann lassen sie doch die SBC-Funktion
betreiben.
https://www.netatwork.de/managed-sbc/
Office 365: Skype for Business PowerShell einrichten
Mittlerweile kann die Konfiguration über die Teams PowerShell erfolgen. Für Direct Routing sind folgende Commandlets interessant.
- Using Windows PowerShell to manage Skype for Business Online
https://technet.microsoft.com/library/dn362831.aspx - Lync PowerShell
- Office 365 - PowerShell
-
Connecting to Skype for Business Online by using Windows
PowerShell
https://technet.microsoft.com/en-us/library/dn362795.aspx -
Using Windows PowerShell in a hybrid deployment with Skype for
Business Online
https://technet.microsoft.com/en-us/library/dn362835.aspx
In meinem Testtenant konnte ich im August 2023 nur 1000 Dialpläne mit maximal 50 Normalisierungsregeln anlegen aber nachdem ich 16.000 CSOnlinePSTNGateways anlegen konnte, habe ich nicht weiter nach der Obergrenze gesucht.
Teams: Gateway einrichten
Ob sie die Funktion in ihrem Tenant nutzen können, sollten Sie über folgenden Befehl prüfen:
Get-Command *-CSOnlinePSTNGateway* CommandType Name Version Source ----------- ---- ------- ------ Function Get-CsOnlinePSTNGateway 1.0 tmp_kcdowxp3.zfk Function New-CsOnlinePSTNGateway 1.0 tmp_kcdowxp3.zfk Function Remove-CsOnlinePSTNGateway 1.0 tmp_kcdowxp3.zfk Function Set-CsOnlinePSTNGateway 1.0 tmp_kcdowxp3.zfk
Entsprechend habe ich mein Gateway eingerichtet.
New-CsOnlinePSTNGateway ` -Fqdn sipgw.uclabor.de ` -SipSignallingPort 5067 ` -MaxConcurrentSessions 5 ` -Enabled $true Identity : sipgw.uclabor.de Fqdn : sipgw.uclabor.de SipSignallingPort : 5067 CodecPriority : SILKWB,SILKNB,PCMU,PCMA ExcludedCodecs : FailoverTimeSeconds : 10 ForwardCallHistory : False ForwardPai : False SendSipOptions : True MaxConcurrentSessions : 5 Enabled : True MediaBypass : False
Sie sehen hier auch gleich alle Parameter, die für das Gateway relevant sind. Sie sehen, dass Sie neben dem FQDN auch den SIP-Port vorgeben können. Sie sind also nicht auf 5067 festgelegt. Interessant ist auch die Reihenfolge der Codecs. RTAUDIO kommt nicht mehr vor und wenn Microsoft SILK zuerst anbietet, dann ist wohl davon auszugehen, dass auch die SBCs diesen Codec unterstützen sollten. Die Vorgabe eines Session-Limits ist wichtig, damit nicht mehr Verbindungen zu ihnen gesendet werden, als Sie über diesen SBC auch bedienen können.
Ich möchte natürlich auch die Information, wer den Ruf initiiert und schalte daher PAI und CallHistory wie folgt ein:
Set-CsOnlinePSTNGateway ` -identity sipgw.uclabor.de ` -ForwardPAI $True ` -ForwardCallHistory $True
Nun sollte die Cloud schon versuchen eine Verbindung zu ihrem Gateway aufzubauen. Sie sollten entsprechende "OPTION"-Requests finden.
- Teams Direct Routing with an AudioCodes
SBC
https://www.lee-ford.co.uk/teams-direct-routing-with-an-audiocodes-sbc/
Teams: Routing einrichten
Beim Routing muss man wissen, dass Phone System den "Next Hop" für ausgehende Anrufe nur anhand der Zielnummer oder anhand der Zielnummer und des Anrufers ermittelt. Dazu brauchen wir aber einige Einstellungen. Wer bislang schon Skype for Business On-Premises installiert hat, wird Ähnlichkeiten nicht leugnen können:
- Voice Routing Policy
Es kann mehrere Voice Routing Policies geben, von denen ein Anwender aber immer nur genau eine Policy haben kann. Per Default gibt es genau eine Voice Routing Policy ohne Einträge. Damit kommen wir natürlich erst einmal nicht weiter und ich würde diese Policy auch nicht ändern, denn ansonsten würde jeder Anwender diese Rechte bekommen, wenn keine andere Richtlinie zugewiesen wurde.
Get-CsOnlineVoiceRoutingPolicy Identity : Global OnlinePstnUsages : {} Description : RouteType :
- PSTN Usages
Das ist einfach nur ein "Text", den Sie natürlich beschreibend wählen sollten um eine Voice Routing Policy mit einer Voice route zu verbinden. Auch hier gibt es erst mal nur einen Eintrag.
Get-CsOnlinePstnUsage Identity : Global Usage : {}
- Voice Routes
Die Voice Route verbindet nun ein Rufnummernmuster mit einem PSTN Gateway für all die User, die die entsprechende "PSTN Usage" haben
Get-CsOnlineVoiceRoute Identity : LocalRoute Priority : 0 Description : NumberPattern : ^(\+1[0-9]{10})$ OnlinePstnUsages : {} OnlinePstnGatewayList : {} Name : LocalRoute
- Online PSTN Gateway
Diesen Eintrag kennen Sie ja schon, seit dem Sie das erste Gateway selbst angelegt haben - CsOnlineVoicemailPolicy
Microsoft hat auch hier einige Defaults vorgegeben, mit denen die Funktion "VoiceMail" gesteuert werden kann. Sie können einem Benutzer immer genau eine Policy zuweisen
Get-CsOnlineVoicemailPolicy | ft identity,Enabletranscription,sharedata,enabletranscriptionprofanitymasking Identity EnableTranscription ShareData EnableTranscriptionProfanityMasking -------- ------------------- --------- ----------------------------------- Global True Defer False Tag:Default True Defer False Tag:TranscriptionDisabled False Defer False Tag:TranscriptionProfanityMaskingEnabled True Defer True
Sie müssen also wieder die Einträge miteinander kombinieren
Der Eintrag der letztlich genommen wird ermittelt sich aus:
- Hole den User
- Finde die dem Benutzer zugewiesene VoiceRoutingPolicy
- Hole davon die PSTN-Usages
- Prüfe, welche CSOnlineVoiceRoute auf die
Rufnummer passt und die entsprechende PSTN-Usage
des Anwenders hat
Wenn keine passt dann nutzt Phone System den Microsoft plan, wenn der Benutzer diesen noch hat. - Rufe über eines der Gateways der gefundenen Policy oder Microsoft Calling Plan an.
Entsprechend gibt es noch ein paar Aussagen
- Failover zwischen Gateways in der
gleichen VoiceRoute
Wenn in einer CSOnlineVoiceRoute mehrere Gateways eingetragen sind, dann werden diese genutzt. Wenn ein Gateway nicht online ist, wird das nächste Gateway genutzt. - Failover zwischen VoiceRoute
Wenn alle Gateways der ersten zutreffenden VoiceRoute offline sind, dann wird die nächstniedrige zutreffende Voice Route versucht. - Wenn keine VoiceRoute passt aber der
Benutzer einen Calling Plan hat, dann wird
der Anruf über die Microsoft Topologie
vermittelt
Allerdings muss dazu der Cloud-Anwender eine Rufnummer von Microsoft als primäre Nummer eingetragen haben. - Ansonsten wird der Anruf abgebrochen.
Für das folgende Beispiel gehe ich von einer Firma mit einem Standort in Deutschland und einem zweiten Standort in Frankreich aus. Jeder Standort hat eine eigene TK-Anlage und einen SBC mit externer Erreichbarkeit und eigenem Namen. Ich gehe nun mal davon aus, dass ein deutscher Teilnehmer nicht über die französische Rufnummer hinausrufen darf, da die abgehende Rufnummer "CLIP noScreening" nicht genutzt werden kann, ist auch "Least Cost Routing" hier kein Thema.
Ehe ich die CSOnlineVoiceRoute anlegen kann, muss ich erst einmal PSTNUsages addieren. Für die Funktion würden auch genau zwei PSTNUsages gereicht. Eine für das Gateway in FR und eine für das Gateway in DE. Aber nur weil jemand ein Gateway nutzen darf, bedeutet das ja noch nicht dass er jeden anrufen darf. "Amtsberechtigungen" werden zwar aufgrund von "Flat"-Abrechnungen immer weniger nachgefragt aber sind ein gutes Beispiel um die Nutzung von Rufnummern zu steuern. Spätestens wenn man "Premium-Nummern" (0900 u.a.) schon im Phone System behandeln will und nicht erst auf dem SBC abriegelt.
Set-CsOnlinePstnUsage -Identity Global -Usage @{Add="DEINTERN"} Set-CsOnlinePstnUsage -Identity Global -Usage @{Add="DELOCAL"} Set-CsOnlinePstnUsage -Identity Global -Usage @{Add="DENAT"} Set-CsOnlinePstnUsage -Identity Global -Usage @{Add="DEWORLD"} Set-CsOnlinePstnUsage -Identity Global -Usage @{Add="DEPREMIUM"} Set-CsOnlinePstnUsage -Identity Global -Usage @{Add="FRINTERN"} Set-CsOnlinePstnUsage -Identity Global -Usage @{Add="FRLOCAL"} Set-CsOnlinePstnUsage -Identity Global -Usage @{Add="FRNAT"} Set-CsOnlinePstnUsage -Identity Global -Usage @{Add="FRWORLD"} Set-CsOnlinePstnUsage -Identity Global -Usage @{Add="FRPREMIUM"}
Danach kann ich dann die Voice Route anlegen. Allerdings lösche ich zuerst die "Local Route". Das muss man nicht machen, da ohne PSTN-Usage und ohne PSTNGateway die Route eh nicht wirksam wird aber
Get-CsOnlineVoiceRoute | Remove-CsOnlineVoiceRoute New-CsOnlineVoiceRoute ` -Identity DE-PB-NATIONAL ` -Priority 4 ` -NumberPattern "^(\+49\d*)$" ` -OnlinePstnGatewayList sipgw.uclabor.de ` -OnlinePstnUsages DENAT New-CsOnlineVoiceRoute ` -Identity DE-PB-WORLD ` -Priority 2 ` -NumberPattern "^(\+\d*)$" ` -OnlinePstnGatewayList sipgw.uclabor.de ` -OnlinePstnUsages DEWorld
In den Name stecke ich gerne den Standort des Datacenter mit rein, da es dort ja auch mehrere Gateways geben kann. Die Liste gebe ich absteigend sortiert, da die höchste Priorität auch zuerst ausgewertet wird.
Get-CsOnlineVoiceRoute ` | sort priority -descending ` | ft Priority,Identity,NumberPattern,OnlinePstnUsages,OnlinePstnGatewayList -AutoSize Priority Identity NumberPattern OnlinePstnUsages OnlinePstnGatewayList -------- -------- ------------- ---------------- --------------------- 4 DE-PB-NATIONAL ^(\+49\d*)$ {DENAT} {sipde.uclabor.de} 3 FR-PB-NATIONAL ^(\+31\d*)$ {FRNAT} {sipfr.uclabor.de} 2 DE-PB-WORLD ^(\+\d*)$ {DEWorld} {sipde.uclabor.de} 1 FR-PB-WORLD ^(\+\d*)$ {FRWorld} {sipfr.uclabor.de}
Wobei hier bei der Reihenfolge primär auf die Rufnummer geachtet werden muss. Nicht berücksichtigt habe ich nun Least Cost Routing, Hochverfügbarkeit oder eine Steuerung nach Zielregion (Local, National, International, Emergency). Es kann also durchaus noch etwas komplexer werden.
Zuletzt muss ich natürlich noch eine Policy erstellen, die ein oder mehrere PSTNUsages zusammenfasst.
New-CsOnlineVoiceRoutingPolicy "DEStandard" -OnlinePstnUsages "DENAT","DEWORLD" Identity : Tag:DEStandard OnlinePstnUsages : {DENAT, DEWORLD} Description : RouteType : BYOT
Auch hier sind weitere Policies möglich, wenn Sie verschiedene PSTNUsages kombinieren müssen.
Teams: Benutzer konfigurieren
Wenn Sie einen Benutzer für Phone System mit einem lokalen Gateway einrichten wollen, dann müssen Sie folgende Dinge durcharbeiten:
- Benutzer mit einer "Phone System"-Lizenz versehen
- Rufnummer zuweisen und dann Enterprise-Voice und Voicemail freischalten
Seit 2022 konfigurieren Sie die Rufnummern über Set-CsPhoneNumberAssignment und Remove-CsPhoneNumberAssignment
- Set-CsPhoneNumberAssignment
https://docs.microsoft.com/en-us/powershell/module/teams/set-csphonenumberassignment?view=teams-ps - Remove-CsPhoneNumberAssignment
https://docs.microsoft.com/en-us/powershell/module/teams/remove-csphonenumberassignment?view=teams-ps - Get-CsPhoneNumberAssignment
https://docs.microsoft.com/en-us/powershell/module/teams/get-csphonenumberassignment?view=teams-ps
Eine ausführlichere Beschreibung zu Teams und Rufnummern finden Sie auf:
Nur aus historischen Gründen führe ich noch auf wie dies früher erfolgt ist.
# Code heute nicht mehr nutzbar Set-CsUser ` -Identity "<User name>" ` -EnterpriseVoiceEnabled $true ` -HostedVoiceMail $true ` -OnPremLineURI "tel:+495251304775"
Damals gab es noch ein Skype for Business Online Control Panel.
Dieses Portal ist heute auch nicht mehr vorhanden und die Verwaltung erfolgt im Teams Admin Center.
- Policies zuweisen
Grant-CsOnlineVoiceRoutingPolicy ` -Identity sip:User1uslabor.de ` -PolicyName "DEStandard"
Aktuell muss für den Benutzer noch eingestellt werden, dass er Anwender "CallingDefaultClient to SfB" eingestellt hat. Es gibt acht CsTeamsInteropPolicy-Einträge, von denen einer die Einstellung hat und so diese Einstellung erzwingt
Get-CsTeamsInteropPolicy Tag:DisallowOverrideCallingSfBChatSfB Identity : Tag:DisallowOverrideCallingSfBChatSfB AllowEndUserClientOverride : False CallingDefaultClient : SfB ChatDefaultClient : SfB
Diese Policy muss natürlich dem Benutzer zugewiesen werden.
Grant-CsTeamsInteropPolicy ` -PolicyName "DisallowOverrideCallingSfBChatSfB" ` -Identity User@uclabor.de
Reporting
Wenn Sie schon mal in der PowerShell sind, können Sie ja auch schnell mal den aktuellen Status sich anzeigen lassen.
get-csonlineUser ` -Filter {(enterprisevoiceenabled -eq $true) -and(HostingProvider -eq "sipfed.online.lync.com")} ` | ft sipaddress,HostedVoicemailPolicy,OnlineVoiceRoutingPolicy,lineuri -AutoSize SipAddress HostedVoicemailPolicy OnlineVoiceRoutingPolicy LineURI ---------- --------------------- ------------------------ ------- sip:fcarius.admin@fcarius.onmicrosoft.com BusinessVoice tel:+4952579459901 sip:adm-cloehr@fcarius.onmicrosoft.com BusinessVoice sip:hg_eded3f1354fb423b9d645b24a4419020@uclabor.de sip:adm-sjunghahn@UCLABOR.DE BusinessVoice tel:+495251304797 sip:cloudus1@uclabor.de BusinessVoice sip:adm-dwulhorst@fcarius.onmicrosoft.com BusinessVoice sip:User1@uclabor.de BusinessVoice DEWORLD tel:+495251304775 sip:user1@UCLABOR.DE BusinessVoice tel:+495251304774
Natürlich können Sie diese Liste auch als HTML-Datei speichern, als CSV-Datei exportieren oder anderweitig ihrem Helpdesk zur Verfügung stellen. Auch pro Benutzer gibt es einige Commandlets und Einstellungen
Get-CsOnlineVoiceUser -Identity directcallUser1 | fl * Name : DirectCallUser1 SipDomain : DataCenter : Number : 495251304795 LicenseState : Licensed Location : PSTNConnectivity : On-Premises UsageLocation : DE EnterpriseVoiceEnabled : True
Get-CsUserPstnSettings directcallUser1@uclabor.de | fl * UserPrincipalName : DirectCallUser1@uclabor.de SipAddress : sip:DirectCallUser1@uclabor.de AllowInternationalCalls : True HybridPstnSiteName : HybridPstnSiteFqdn : ap.uclabor.de
Die "CsOnlineVoiceRoutingPolicy" finden Sie allerdings beim CSOnlineUser:
Get-CSOnlineUser ` -Filter {(enterprisevoiceenabled -eq $true) -and(HostingProvider -eq "sipfed.online.lync.com")} ` | ft sipaddress,HostedVoicemailPolicy,OnlineVoiceRoutingPolicy,lineuri -AutoSize
Sonderfall: Anonyme Anrufe
Phone System unterstützt auch den Sonderfall, dass Personen zwar ausgehend anrufen sollen aber deren direkte Durchwahl nicht erkennbar sein soll. Natürlich lässt sich das mit einem lokalen SBC auch dort läsen und sogar über entsprechende "Vorwahlen" durch den Anwender steuern. Aber ich möchte dennoch nicht den Weg unterschlagen, wie die in Phone Systeme möglich ist. Es ist für die Personen wichtig, die über die Microsoft Pläne telefonieren.
#Anonyme Calls erlauben #Neue Vorlage für CallineLineIdentity anlegen New-CsCallingLineIdentity ` -Identity Anonymous ` -Description "Anonymous policy" ` -CallingIDSubstitute Anonymous ` -EnableUserOverride $false ä Diesen Eintrag zuweisen Grant-CsCallingLineIdentity ` -Identity "User2@uclabor.de" ` -PolicyName Anonymous
Sie können natürlich auch eine Rufnummer zuweisen, z.B. um alle Personen im Servicecenter über eine Zentralnummer arbeiten zu lassen, die ansonsten in einer Call Queue landet.
New-CsCallingLineIdentity ` -Identity "CalLQueueZentrale" ` -CallingIdSubstitute "Service" ServiceNumber "+495251304600" ` -EnableUserOverride False -Verbose Grant-CsCallingLineIdentity ` -Identity "User3@uclabor.de" ` -PolicyName "CalLQueueZentrale"
Der erste eingehende Ruf
Auf eine noch nicht vergebene Rufnummer antwortet Teams mit einem 404:
Der Anrufer bekommt dann in der Regel ein "Besetzteichen", welches aber nicht von Microsoft geliefert wird, sondern SIP-Typisch eben vom Endgerät des Anrufers oder seiner nächsten TK-Technik generiert wird. Bei einem erfolgreichen Anruf kommt dann ein 200OK mit dem üblichen ICE-Handshake und Kandidaten.
Media Flow
Ich habe meinem Anwender in Skype for Business Online also eine Rufnummer verpasst und als "Preferred Client" in Teams auch den Teams-Client eingetragen. Wenn Sie dies nicht machen, dann landen eingehende Anrufe tatsächlich auch beim Skype for Business-Client. Allerdings können wir nicht vom Skype for Business Client Anrufe in das Festnetz über den SIP-Trunk initiieren. Skype for Business Online kennt die Route nicht und sie kann auch nicht eingerichtet werden. Sie müssen also den Teams-Client nutzen, um mit Direct Routing zu telefonieren.
Die Kommunikation zwischen Teams Client und Office 365 Backend ist natürlich verschlüsselt. Über den Taskmanager/Ressourcenmanager können Sie aber recht einfach sehen, welche Kommunikationspartner mit welcher Bandbreite Daten übertragen.
Mein Client ist zwar im gleichen Subnetz wie der SBC aber dennoch gehen meine Audio-Daten aktuell noch zum Mediarelay in der Cloud und dort über einen Art "Mediationserver" und den SBC von Office 365 wieder zu meinem lokalen SBC. Aufgrund der Bandbreite dürfte mein Client die Sprache mit dem SILK-Codec komprimiert haben. Das lässt sich auch über Wireshark sehen:
Damit stellen sich natürlich die Frage wie:
- EarlyMedia
Baut der Teams-Client die Audio-Verbindung schon vor dem Connect auf? -
Direct Routing und Media Bypass
Es ist mittlerweile möglich, dass die lokalen Kandidaten des SBC durchgereicht werden und damit 1:1 Gespräche komplett lokal bleiben. (Siehe "Plan for media bypass with Direct Routing" https://docs.microsoft.com/en-us/microsoftteams/direct-routing-plan-media-bypass) Allerdings müssen dann schon noch einige Dinge gelöst werden:- SBC intern und Extern
Der SBC meldet zu Office 365 natürlich die öffentlichen IP-Adressen als RTP-Kandidaten. Er müsste dann zumindest auch die internen Adressen melden oder die Clients müssten die externe Adresse erreichen. - Konferenz Eskalation
Wenn aus einem 1:1 Call dann doch eine "Team-Konferenz" wird, müsste der lokale Call zur CloudMCU umgeroutet werden. Das ist sicherlich per REFER möglich aber fehleranfälliger, als wenn RTP eh schon über die Media-Relays in der Cloud laufen. - Encryption
Natürlich sollte die Audio/Video-Übertragung verschlüsselt sein. Alle modernen Gateway verstehen natürlich SRTP aber oft wird genau dies dann doch wieder "intern" deaktiviert. - G.711 Codec
Ich weiß eigentlich gar nicht genau, ob der Teams-Client überhaupt noch G.711 als Codec unterstützt. Es gibt schon Gateways, die SILK sprechen. Microsoft könnte dies einfach als Voraussetzung für die Zertifizierung vorschreiben. Viele SIP-Trunks machen aber immer noch G.711
- SBC intern und Extern
- QoS
Im Internet gibt es natürlich keine Priorisierung auf Basis von QoS-Kennzeichnungen. Intern könnte das aber schon bereit gestellt werden.
Ich werde diese Seite also zukünftig noch um weitere Analysen erweitern. Das die gesamte Funktion mittlerweile aber "Public Preview" ist, sollte die Funktion langsam sich verfestigen und nicht mehr so viele Veränderungen zu erwarten sein. Es ist aber wieder mal schön zu sehen, wie Microsoft in der Cloud Funktionen sehr früh als Beta-Version ausgewählten Tenants zur Verfügung stellt und dann über einen Public Preview auch einem größeren Kreis öffnet. Wenn sich dann hier keine Probleme, Fehler oder Skalierungsthemen zeigen, dann sollte die Funktion auch in naher Zukunft zum regulären Funktionsumfang gehören.
Direct Routing ist aus meiner Sicht ein großer Schritt voran um die Kommunikation mit Office 365 auf ein neues Level zu heben.
Testen mit Test-CSOnlineUserVoiceRouting.ps1
Lee Ford hat mal eben schnell ein kleines PowerShell-Script geschrieben, mit dem Sie testen können, welche Route ein Anruf einer Person an eine Nummer gehen wird
- Test-CSOnlineUserVoiceRouting: Test a User’s Online Voice Routing Policy for Teams
Direct Routing
https://www.lee-ford.co.uk/test-csonlineUservoicerouting-test-a-Users-online-voice-routing-policy-for-teams-direct-routing/
Weitere Links
- Teams und Telefonie
- Direct Routing - Telefonie mit eigener SIP-Anbindung
- Direct Routing und Media Bypass
- Teams Rufnummern
- Direct Routing, REFER und TLS
-
SBC Absicherung
Wenn ihr SBC zu freizügig ist, telefonieren andere auf ihre Kosten -
Checklisten
Eine Übersicht aller Checklisten der MSXFAQ -
List of Session Border Controllers certified for Direct Routing
https://docs.microsoft.com/en-us/MicrosoftTeams/direct-routing-border-controllers - Direct Routing NOW in Public Preview
https://techcommunity.microsoft.com/t5/Microsoft-Teams-Blog/Direct-Routing-NOW-in-Public-Preview/ba-p/193915 - Quick Start Guides
https://aka.ms/CallingGuidance - Plan Direct Routing
https://aka.ms/drplandirectrouting - Configure Direct Routing
https://aka.ms/drconfiguredirectrouting - deep dive recording
https://aka.ms/dr-training - Cloud ment
https://docs.microsoft.com/en-us/MicrosoftTeams/cloud-voice-deployment - Microsoft Azure Datacenter IP Ranges
https://www.microsoft.com/en-us/download/details.aspx?id=41653 - Announcing updated practical guidance for Audio Conferencing
and Phone System in Teams
https://techcommunity.microsoft.com/t5/Microsoft-Teams-Blog/Announcing-updated-practical-guidance-for-Audio-Conferencing-and/ba-p/173271 - Microsoft Teams Direct Routing explained
https://msunified.net/2018/05/27/microsoft-teams-direct-routing-explained/ - Monitor and troubleshoot Direct Routing
https://docs.microsoft.com/en-us/MicrosoftTeams/direct-routing-monitor-and-troubleshoot - Plan for media bypass with Direct Routing
https://docs.microsoft.com/en-us/microsoftteams/direct-routing-plan-media-bypass - Teams Direct Routing with an AudioCodes SBC
https://www.lee-ford.co.uk/teams-direct-routing-with-an-audiocodes-sbc/ - Fix External Call forwarding in Direct Routing with
Microsoft Teams – AudioCodes Mediant SBC with SIP Trunk
https://thamaraw.com/2018/10/17/fix-external-call-forwarding-in-direct-routing-with-microsoft-teams-audiocodes-mediant-sbc-with-sip-trunk/ - Using On-Premises PSTN numbers for Call Queues and Auto
Attendant for Cloud Connector Edition
https://thamaraw.com/2018/09/10/using-On-Premises-pstn-numbers-for-call-queues-and-auto-attendant-for-cce/ - Microsoft Teams Call Queue no audio with SWe Lite Direct
Routing
https://ucgeek.co/2019/07/microsoft-teams-call-queue-no-audio-with-swe-lite-direct-routing/ - Don’t forget the REFER – Microsoft Teams Direct Routing with
SWe Lite
https://ucgeek.co/2019/07/dont-forget-the-refer-microsoft-teams-direct-routing-with-swe-lite/ - Deploying Direct Routing for Microsoft Teams
https://www.ucit.blog/post/deploying-direct-routing-for-microsoft-teams