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

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 Lizenzen

Auch 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 SBCs

Microsoft hat die Anbindung nur für ausgewählte SBCs dokumentiert.

Dazu gehören im ersten Schwung:

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 SBC

Die 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 Zertifikat

Die Verbindung zu Teams erfolgt per SIP/TLS über Port 5067. Entsprechend muss der SBC ein Zertifikat haben. Microsoft unterstützt hier aktuell folgende Stammzertifizierungsstellen:

  • AddTrust External CA Root
  • Baltimore CyberTrust Root
  • Class 3 Public Primary Certification Authority
  • DigiCert Global Root CA
  • Verisign, Inc.
  • Symantec Enterprise Mobile Root for Microsoft
  • Thawte Timestamping CA

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 denkt also auch teamssbc.msxfaq.net ab aber kein sbc.teams.msxfaq.net

Lizenz pro Benutzer

Damit die Teams-Anwender mit Direct Routing telefonieren können, benötigen Sie folgende Lizenzen:

  • Skype for Business Online (Plan 2)
    Diese Lizenz ist auch in E3  und höher enthalten
  • Microsoft Phone System
    Diese Lizenz ist erst in E5 enthalten, kann aber einzeln nachlizenziert werden
  • Microsoft Teams
    Diese Lizenz ist auch in E3 und höher enthalten

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 Verbindung

Der 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

  • sip-all.pstnhub.microsoft.com
    Hinter dem Namen verbergen sich alle SIP-Server.
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
  • sip.pstnhub.microsoft.com
    Dieser Eintrag sollte immer zuerst genutzt werden. Er wird auf den geografisch nächsten Zugang geroutet. Für deutsche Kunden ist das EMEA
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
  • sip2.pstnhub.microsoft.com
    Wenn das erste System nicht erreichbar ist, dann kann der SBC auf diesen Eintrag als Failover schwenken. Für europäische Kunden ist das dann US
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
  • sip3.pstnhub.microsoft.com
    Für den hoffentlich seltenen Fall, dass EMEA und US nicht erreichbar sind, bleibt unter dem Namen für Europäer noch der Zugang in Asien.
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

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.

Office 365: Skype for Business PowerShell einrichten

Auch wenn es schon im Teams geht, erfolgt die Konfiguration noch über die Skype for Business Online Powershell. Für Direct Routing sind folgende Commandlets interessant

Hier noch mal die Befehle zum Start der Online PowerShel

$credential = Get-Credential
$session = New-CsOnlineSession -Credential $credential -Verbose
Import-PSSession $session -AllowClobber

Die Angabe von "-allowClobber" ist erforderlich, wenn Sie auf dem Computer auch eine normale Skype for Business PowerShell installiert haben, denn leider folgen nicht alle Befehle dem Schema "*-csonline*. Nur mit "-AllowClobber" werden gleichnamige Befehle dann überlagert.

Teams: Gateway einrichten

Ob sie die Funktion in ihrem Tenant nutzen können, sollten Sie über folgenden Befehl prüfen:

Get-Command *-*onlinePSTNGateway*

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: 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

  1. Hole den User
  2. Finde die dem Benutzer zugewiesene VoiceRoutingPolicy
  3. Hole davon die PSTN-Usages
  4. 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.
  5. 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 einrichten

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
Set-CsUser `
   -Identity "<User name>" `
   -EnterpriseVoiceEnabled $true `
   -HostedVoiceMail $true `
   -OnPremLineURI "tel:+495251304775"

Der Benutzer wird dann sogar im Skype for Business Control Panel sichtbar:

  • 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:adm-fcarius@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       : OnPremises
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 Medarelay in der Cloud und dport ann ü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?
  • MediaBypass
    Wird es irgendwann möglich sein, dass die lokalen Kandidaten des SBC durchgereicht werden und damit 1:1 Gespräche komplett lokal bleiben? Allerdings müssen dann schon 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 ehsc 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
  • 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

Weitere Links