Teams Dialplan

Einige Länder haben "komische" Vorwahlen und Teams Dialpläne sollen helfen diese Rufnummern in ein E.164-Format zu bringen. Manchmal stört aber die Intelligenz von Teams

Die Krux mit der Vorwahl

In Deutschland und Europa haben wir uns schon lange daran gewöhnt, dass wir nationale Gespräche in andere Ortsnetze mit einer "0" vor der Ortsvorwahl einleiten müssen und eine "00"+Ländercode für internationale Gespräche verwenden. In anderen Ländern ist das aber anders. So unterscheidet die USA anhand der Länge der gewählten Rufnummer (7 Stellig = lokal, 10 stellig=National) und erwartet eine "011" als internationale Vorwahl. In Australien müssen wiederum müssen Sie 0011<land><ortsnetz><teilnehmer> wählen. Und dann gibt es noch "Sonderfälle" wie Kuba (119), Belarus u.a. (810), Russland (8xx), die für uns Europäer so gar nicht in das Bild passen. So müssen Sie z.B. in Shanghai ein "0xx" einfügen, wobei "xx" der CallbyCall-Provider ist. Ich habe mal versucht eine Tabelle aufzustellen:

Von Nach Rufnummernformat E-164-Normalisierung Beschreibung

Deutschland

Lokal

<teilnehmer>

+49<ortsnetz><teilnehmer>

Wir wählen einfach die lokale Rufnummer, welche nie mit einer "0" beginnt. Die Rufnummern sind, anders als den USA, nicht immer gleich lang.

Deutschland

National

0<ortsnetz><teilnehmer>

+49<ortsnetz><teilnehmer>

Wenn wir eine "0" davor stellen, dann ist das die Ausscheidungsziffer für Verbindungen in ein anderes nationales Ortsnetz. Die Ortsnetzvorwahl ist auch nicht immer gleich lang. Große Städte wie Berlin (30), München (89), Frankfurt (69), Hamburg (40) haben 2-stellige Vorwahlen, damit die Teilnehmernummer länger sein kann während Ortsnetze mit weniger Anschlüssen eine längere Vorwahl (Paderborn 5251) haben.

Deutschland

International

00<land><ortsnetz><teilnehmer>

+<land><ortsnetz><teilnehmer>

Wenn wir "00" davor stellen, dann ist das die Ausscheidungsziffer für internationale Verbindungen, die mit dem Ländercode starten

USA

Lokal

<Teilnehmer> (7-stellig)

+1<area><teilnehmer>

"Ortsnetze" gibt es in den USA so nicht aber ca. 999 "Areacodes" mit 7 stelligen Rufnummern und die Areacodes wurden an Provider (ATT, Bell etc.) zugewiesen. Wenn ich eine 7-stellige Rufnummer wähle, dann ist der gerufene Teilnehmer im gleichen Area-Code.

USA

National

<Area><Teilnehmer>  (10-stellig)

+1<area><teilnehmer>

Eine 10-stellige Rufnummer ist dann immer eine "voll qualifizierte" Rufnummer innerhalb des US-Telefonsystems

USA

International

011<land><Teilnehmer>  (10-stellig)

+<land><teilnehmer>

Die "011" ist keiner lokale Area zugewiesen sondern die Ausscheidungsziffer für internationale Anrufe

Australien

International

0011<land><ortsnetz><teilnehmer>

+<land><ortsnetz><teilnehmer>

In Australien ist die "0011" die Ausscheidungsziffer für internationale Anrufe

Basierend auf einer solchen Logik oder Tabelle sollten Sie nun natürlich einen "Dialplan" pro Region erstellen, in der Sie über Normalisierungsregeln die Anwender dabei unterstützen, aus einer klassisch gewählten Rufnummer eine internationale E.164-Rufnummer zu machen.

Achtung:
Teams erlaubt (Stand Aug 2023) maximal 1000 Dialpläne pro Tenant. Das klingt viel aber ist es nicht, wenn Sie z.B. in sehr vielen Orten eigene Standorte haben. Interessanterweise können sie aber mehr als 8000 PSTN-Gateways konfigurieren.

Deutschland hat z.B. ca. 5200 Vorwahlen, während die USA mit ihren 7/10-stelligen Rufnummern genaugenommen nur 999 "Areacodes haben. Vielleicht kommt da ja auch die 1000er Grenzwert her.

Verzeichnis der Ortsnetze der Bundesrepublik Deutschland
https://www.bundesnetzagentur.de/SharedDocs/Downloads/DE/Sachgebiete/Telekommunikation/Unternehmen_Institutionen/Nummerierung/Rufnummern/ONVerzeichnisse/ONBVerzeichnis/D-InformationenONBVerzeichnis.pdf?__blob=publicationFile&v=2 

Teams Dialplan

In Microsoft Teams legen Sie daher für jeden Standort mit einer eigenen Kombination aus Land/Ortsnetz einen Dialplan an, der verschiedene Normalisierungsregeln enthält. Bei internationalen Firmen mit vielen Standorten kann die Liste schon etwas länger werden. Hier ein Auszug eines Kunden mit 43 individuellen Standorten.

Die Konfiguration ist natürlich auch per Teams PowerShell möglich und speziell bei vielen Standorten ist es auch ratsam, solche Regeln per Skript zu erstellen. Der entsprechende Dialplan muss natürlich den Benutzern direkt oder eine Gruppe dann auch zugwiesen werden.

Grant-CsTenantDialPlan `
   -Identity frank@msxfaq.de `
   -PolicyName DP_Paderborn

Wenn Sie keinen Dialplan zuweisen, dann kommt der "Global"-Plan zum Einsatz. Sie können überlegen, ob sie hier jegliche Rufnummer so umschreiben, dass der Anruf beim IT-Helpdesk ankommt. Dann bemerken Sie solche Konfigurationsfehler sehr schnell.

Zu jedem Dialplan gibt es dann eine Liste mit den Normalisierungen. Hier am Beispiel von Paderborn:

Ein Benutzer gibt eine Rufnummer ein und der Teams Client normalisiert die Rufnummer anhand der Reihenfolge. Sie sollten daher die Liste nach "nearest match first" aufbauen, d.h. die Abfrage nach "00" muss natürlich vor der "0" stehen, damit keine falsche Normalisierung erfolgt. Je spezifischer der reguläre Ausdruck ist, desto besser. Sie sollten auch immer ein paar "Testrufnummern" oben im Feld eingeben und dann sehen, welche Regel "matched" und wie das Ergebnis aussieht.

Achtung:
Sie können maximal 50 Normalisierungsregeln pro Dialplan konfigurieren. Für normale Anwendungsfälle reicht das aus aber wenn Sie viele Sonderfälle von nicht zusammenhängenden Blöcken behandeln müssen, dann kann es knapp werden

Client

Der einfachste Weg diese Regeln auf dem Client zu testen, ist die Nutzung des Dialpad. Sie geben oben einfach die Rufnummer ohne "+" ein und warten etwas ab, bis Teams die normalisierte Rufnummer darunter anzeigt. Es gibt aber einige Sonderfälle.

Szenario Bild Beschreibung

Interne Rufnummer (vollständig)

Die Normalisierungsregel "([6-8]\d{2}$" zeigt Teams an, dass jede 3-stellige Nummer, die mit 6,7, oder 8 beginnt, eine interne Rufnummer ist. Die Eingabe von 777 "matched" und wird korrekt in das passende E.164-Format umgesetzt.

Hier gibt es aber ein Risiko bei Firmen, die einen kompletten Rufnummernblock haben, d.h.wenn da jemand eine 110/112 wählen möchte, sollte dazu eine eigene Regel davor diese Nummern immer zur einer Notrufzentrale leiten. Sie können und sollten intern dann diese Sonderrufnummern nie an normale Teilnehmer geben.

Interne Rufnummer (unvollständig)

Wenn ich die Nummer unvollständig wähle und KEINE Regel matched, dann erfolgt keine Normalisierung.

Interne Rufnummer (match)

Wenn Teams die Rufnummer auf eine Person zuordnen kann, dann wird statt der E.164-Nummer der Name angezeigt.

Hinweis
Wenn Sie ihre eigene Rufnummer eingeben, dann wird weder ihr Name noch eine E.164-Nummer angezeigt.

Ortsnummer

Wähle ich eine Rufnummer in Paderborn, dann greift die Regel "Ortsbereich Paderborn" mit "^([1-9]\d{1}\d+)$". Die Regel ist nicht "genau", wenn sie passt schon bei 2 und 3-stelligen Nummern aber sie steht ja hinter der Regel "Intern 6xx-8xx".

National

Ein Anruf in ein anderes Ortsnetz wird normal mit einer "0" eingeleitet. Mit der passenden Regel entfernt Teams die 0 und addiert eine "+49".

Achten Sie mal darauf, wie der Teams Client die Rufnummern <land> <Ortsnetz> <Teilnehmer> aufsplittet

International

Es ist nun kein weiteres Hexenwerk, wie Teams eine "00" in Deutschland auf eine internationale Rufnummer umsetzt.

E.164 Nummer

Natürlich kann ich im Wählfeld auch eine E.164 Nummer eingeben. Wenn diese korrekt ist, dann wird sie 1:1 übertragen und ich brauche dazu noch nicht einmal eine Normalisierungsregel. Das war damals bei Skype for Business schon so, dass solche Rufnummern nicht angefasst werden.

Deutsche E.164 Nummer mit 0 oder 00 oder 000

Nun passiert es aber immer wieder, dass Menschen das mit der E.164-Nummer nicht ganz verstanden haben, und sich doch wieder die ein oder andere "0" in die Rufnummer verirrt. Hier hat Teams dann anscheinend eine "Intelligenz" eingebaut, um diese Fehler zu heilen.

Hinweis
Auch diverse Smartphones haben solche Funktionen, um offensichtlich falsche Nummern zu heilen.

Ich habe hier absichtlich einmal eine "0" und eine "00" addiert und beide Male entfernt Teams diese überzähligen Ziffern, ohne dass es eine passende Normalisierungsregel gibt.

Erst mit drei Nullen bleibt eine davon übrig.

US E164 mit 0

Ich habe dann die gleiche Thematik mit der USA nachgestellt. Eine +1 mit zusätzlichen Nullen hat aber ein anderes Verhalten an den Tag gelegt. Hier wurde nicht nur die "0" belassen sondern auch die Trennung der Ländervorwahl schon nach der erstellen Stelle vorgenommen.

3-stellige Ländervorwahl

Es gibt durchaus Länder, die sehr klein sind und eine 3-stellige Länderkennzahl haben. Ich habe exemplarisch Saint Helena und auch hier ist Teams so intelligent, dies zu erkennen.

Irgendwo muss im Teams Code also eine Liste der Ländervorwahlen und eingebaute Normalisierungsregel geben.

Sonderfall Shanghai

Diese "Bereinigung" von überzähligen "0"-Stellen kann aber auch zu Problemen führen. Die Ländervorwahl für China ist +86 und im Prinzip werden Rufnummern wie in Europa gewählt.


Quelle: https://en.wikipedia.org/wiki/%2B86

Man wählt einfach direkt die Nummer innerhalb des gleichen Vorwahlbereichs und eine "0" um eine Rufnummer in einem anderen Ortsnetz zu erreichen. Das Ausland erreicht man mit "00", wobei bei den Rufnummern auch Taiwan (+886), Hong Kong (+852) und Macau (+853) als Ausland zählen. Die Anwahl von Mobilfunkteilnehmern ähnelt auch der Logik in Deutschland, wo im D-Netz zuerst die Vorwahlen 0170,0172 genutzt wurden und später dann 0171, 0173, 0174, 0175 u.a. dazu gekommen sind.

In China werden Mobiltelefone über die "1nn" erreicht, wobei "nn" für eine zweistellige Rufnummer des jeweiligen Providers ist, der diese Nummerngasse verwaltet. Insofern wäre eine E.164-Nummer dann z.B. "+86nnxxxxxxxxxxx". Aber es gibt Sonderfälle und Shanghai ist ein solcher Fall, denn hier muss eine "0" zwischen die Ländervorwahl und die restlicher Rufnummer gesetzt werden. Aber mein chinesischer Ansprechpartner chattete mir folgende Beschreibung.

The right Dial plan.
1.length of digitals input = 12
2.first two digitals in ('01')
3.first three digitals not in ('010')
e.g.,if enter 018621xxxxxx then the final right result should be +86 018621xxxxxx, which worked from Feb 2022 to 2. Nov 22.

So ist anscheinend in Shanghai eine "0" erforderlich, wenn Sie aus Shanghai eine chinesische Mobilfunknummer anrufen wollen. Hier ein Dialplan eines Teams-Standort in Shanghai.

Allerdings kommt nun das Problem, dass irgendwo in Teams diese "Entfernung" von "überzähligen Nullen" codiert ist. Wenn nun ein chinesischer Mitarbeiter z.B.: die 0135xxx wählt, dann sollte eine +860135xxxx normalisiert und gerufen werden. Allerdings kommt beim SBC nur die Rufnummer ohne "0" an und Teams zeigt auch in der Vorschau bei verschiedenen Eingaben immer die Nummer ohne "null" an.

Im Anruffenster steht oben aber dann wieder die "richtige" Rufnummer, nur gewählt wird sie nicht.

Es gibt drei Optionen dieses "Problem" zu lösen:

  • Der Anwender wählt "000"
    Damit der Teams Client nur zwei "00" entfernt und damit eine "0" erhalten bleibt.
  • Der Anwender nutzt den Schnellzugriff statt das Dialplan
    Wenn Sie mit "/call" oder "/anruf" in der oberen Zeile eine E-164-Nummer eingeben, dann wird diese anscheinend nicht "bereinigt".
  • Der Administrator passt die Nummer auf dem SBC an
    Das geht natürlich nur in Verbindung mit Direct-Routing und wenn man genau erkennen kann, was der Wunsch des Anwenders ist, z.B. durch eine besondere VorVorwahl.

Allerdings sind alle drei Optionen nicht wirklich elegant, den der Anwender muss sein gewohntes Verhalten ändern.

Client Tracing Dialplan

Natürlich wollte ich etwas mehr über das Anrufverhalten von Teams erfahren. Zuerst habe ich mit den Dialplan zu meinem Benutzer im Teams Admin Center angeschaut, dass hier keine unterwarteten Einträge sind:

Soweit ist das erst mal nicht spektakulär und ich habe auf dem Client mit "CTRL-ALT-SHIFT-1" einen Trace generiert. In der Datei "MSTeams Diagnostics Log <dd>_<mm>_<yyyy>__<hh>_<mm>_<ss>.txt" finde ich mit einer Suche nach "DialPlanPolicy" sehr schnell den auf meinem Client aktiven Wählplan.

   "dialPlanPolicy": {
     "normalizationRules": [
       { "pattern": "^00(\\d*)$",                                            "translation": "+$1" },
       { "pattern": "^0(\\d*)$",                                             "translation": "+49$1"},
       { "pattern": "^([6-8]\\d{2})$",                                       "translation": "+495251304$1"},
       { "pattern": "^([2]\\d{2})$",                                         "translation": "$1"},
       { "pattern": "^([1-9]\\d{1}\\d+)$",                                   "translation": "+495251$1"},
       { "pattern": "^00(\\d+)$",                                            "translation": "+$1"},
       { "pattern": "^((\\+)?(\\d+))(;)?(ext|extn|EXT|EXTN|x|X)(=)?(\\d+)$", "translation": "$1;ext=$7"},
       { "pattern": "^0(\\d+)$",                                             "translation": "+49$1"}
     ],
     "optimizeDeviceDialing": true,
     "ituCountryPrefix": "49"
   },

Durch die Schreibweise in JSON muss man aus einem "\\d" eigentlich ein "\d" machen und auch ein "\\+" ist eigentlich ein "+"

Wenn ich das mit dem Dialplan im Teams Admin Center vergleiche, fallen aber drei weiteren Zeilen am Ende auf, die im Dialplan selbst nicht vorhanden sind. Zudem hat Teams irgendwo mir die "49" als "ituCountryPrefix" zugewiesen.

Das "ituCountryPrefix" wird aus der "Office 365 UsageLocation" und nicht aus der Spracheinstellung oder zugewiesenen Rufnummer des Anwender abgeleitet.

Auch dies konnte im gleichen Logfile gesehen werden, wenn Sie nach der Rufnummer oder "voiceAdminSettings" suchen. Sie sehen auch, dass der Benutzer auch Enterprise Voice-aktiviert ist und die Einstellung auch beim Client angekommen ist.

    "voiceAdminSettings": {
      "value": {
        "phoneNumber": "435251304613",
        "isEvEnabled": true,
        "isSipEnabled": true,
        "isSfbCloud": true,
        "adminSettings": {
          "isEvEnabled": true,
          "isSipEnabled": true
        },

Ich habe dann meinem Benutzer einfach mal einen "leeren" Dialplan zugewiesen und nach einiger Wartezeit habe ich im Client-log auch folgende Zeilen gefunden:

2022-11-06T10:43:49.723Z Inf   myPhoneNumberService: Phone number successfully fetched from voiceSettingsStore [phonenumber]
2022-11-06T10:43:49.723Z Inf   myPhoneNumberService: Phone number updated: +495251304613, formatted as 05251 304613 [phonenumber]
2022-11-06T10:43:49.712Z Inf   PoliciesService: [hasDialPlans] User has a dialPlanPolicyAssigned but there are no normalization rules defined in the policy.
2022-11-06T10:43:49.712Z Inf   PoliciesService: [hasDialPlans] User has a dialPlanPolicyAssigned but there are no normalization rules defined in the policy.
2022-11-06T10:43:49.712Z Inf   myPhoneNumberService: Added prefix '+' to phone number to conform to e164 format [phonenumber]

Interessant war aber auch dann, dass es einige "normalizationRules" gibt, die dennoch immer angefügt werden.

  "dialPlanPolicy": {
    "normalizationRules": [
      {"pattern": "^00(\\d+)$",                                            "translation": "+$1" },
      {"pattern": "^((\\+)?(\\d+))(;)?(ext|extn|EXT|EXTN|x|X)(=)?(\\d+)$", "translation": "$1;ext=$7"},
      {"pattern": "^0(\\d+)$",                                             "translation": "+49$1" }
    ],
    "ituCountryPrefix": "49"
  },

Microsoft hat hier wohl eine eigene Logik eingebaut, die pro Land hinterlegt ,wie eine Rufnummer normalisiert wird, wenn der Administrator keine eigene Regeln angewendet hat. Hier mal die Ausdrücke für Shanghai, wenn der Dialplan leer ist:

  "dialPlanPolicy": {
    "normalizationRules": [
      {"pattern": "^00(\\d+)$",                                            "translation": "+$1" },
      {"pattern": "^((\\+)?(\\d+))(;)?(ext|extn|EXT|EXTN|x|X)(=)?(\\d+)$", "translation": "$1;ext=$7"},
      {"pattern": "^0(\\d+)$",                                             "translation": "+86$1"}  
    ],
    "ituCountryPrefix": "86"
  },

Microsoft hat anscheinend schon für die meisten Szenarien entsprechende Normalisierungsregeln angelegt und

Client Tracing Normalisierung

In der Datei "MSTeams Diagnostics Log <dd>_<mm>_<yyyy>__<hh>_<mm>_<ss>.txt" finde ich aber auch Details zu Anrufen und die Normalisierung der gewählten Rufnummern.

Hinweis
Die Logdateien sind "falsch herum", d.h. die aktuellste Zeile ist oben und die älteste Zeile unten. Sie sehen das auch gut am Zeitstempel am Anfang

Hier ein Anruf von mir auf mein Mobiltelefon (Nummer unkenntlich gemacht).

2022-11-06T21:47:11.931Z Inf   Module callingMultiWindowService: [showIntent] #callpopout Will show intent [windowingActionId=e27a9c18-dc39-495e-8e9d-798840246246, intentId=e2054fbe-5a62-44a7-98a9-84d3210487c4, context=CentralDataLayer, windowType=call]
2022-11-06T21:47:11.930Z Inf   CallingUserActionService: placeCall: opening call in new window, intentId = e2054fbe-5a62-44a7-98a9-84d3210487c4
2022-11-06T21:47:11.913Z Inf   CallingUserActionService: placeCall: new conversationid is = 19:preview-ada49408-3fec-4dda-84e0-4e5b68e2f689 [call]
2022-11-06T21:47:11.845Z Inf   CallingUserActionService: placeCall: current conversationid is = 19:preview-ada49408-3fec-4dda-84e0-4e5b68e2f689 [call]
2022-11-06T21:47:11.839Z Inf   [Scenario]calling_intent start
2022-11-06T21:47:11.818Z Inf   [Scenario]people_pstn_rnl [step](1)stop (6ms/6ms)
2022-11-06T21:47:11.815Z Inf   PstnNumberService: [generateMriForPstn] Generated MRI: 4:+49160906xxxxx for dialOutNumber: +49160906xxxxx 
2022-11-06T21:47:11.815Z Inf   PstnNumberService: [normalizeIfPstnMri] Generating MRI for normalized number +49160906xxxxx
2022-11-06T21:47:11.812Z Inf   PstnNumberService: [normalizeIfPstnMri] Received mri: 4:+49160906xxxxx
2022-11-06T21:47:11.812Z Inf   [Scenario]people_pstn_rnl start
2022-11-06T21:47:11.812Z Inf   PstnNumberService: [formatPhoneNumber] isValid? true
2022-11-06T21:47:11.806Z Inf   PstnNumberService: [formatPhoneNumber] isInternalExtension? undefined
2022-11-06T21:47:11.806Z Inf   PstnNumberService: [formatPhoneNumber] cleaned_formatting
2022-11-06T21:47:11.748Z Inf   PstnNumberService: [generateMriForPstn] Generated MRI: 4:+49160906xxxxx for dialOutNumber: +49160906xxxxx 
2022-11-06T21:47:11.748Z Inf   PstnNumberService: [normalizeIfPstnMri] Generating MRI for normalized number +49160906xxxxx
2022-11-06T21:47:11.743Z Inf   PoliciesService: [normalize] [0160906xxxxx] was normalized into [+49160906xxxxx] using rule 3 of 3: ruleExpression=[/^0(\d+)$/] translation=[+49$1] isInternalExtension=[undefined].
2022-11-06T21:47:11.743Z Inf   PstnNumberService: [normalizeIfPstnMri] Received mri: 4:0160906xxxxx
2022-11-06T21:47:11.743Z Inf   EmergencyService: [e911][getMappedEmergencyNumber] [0160906xxxxx] did not map to any emergencyNumber in the emergencyDictionary=[{}]
2022-11-06T21:47:07.771Z Inf  PstnNumberService: [formatPhoneNumber] isValid? true
2022-11-06T21:47:07.765Z Inf   PstnNumberService: [formatPhoneNumber] isInternalExtension? undefined
2022-11-06T21:47:07.765Z Inf   PstnNumberService: [formatPhoneNumber] cleaned_formatting
2022-11-06T21:47:07.765Z Inf   PstnNumberService: [generateMriForPstn] Generated MRI: 4:+49160906xxxxx for dialOutNumber: +49160906xxxxx 
2022-11-06T21:47:07.765Z Inf  PstnNumberService: [formatPhoneNumber] isValid? true
2022-11-06T21:47:07.745Z Inf   PstnNumberService: [formatPhoneNumber] isInternalExtension? undefined
2022-11-06T21:47:07.745Z Inf   PoliciesService: [normalize] [0160906xxxxx] was normalized into [+49160906xxxxx] using rule 3 of 3: ruleExpression=[/^0(\d+)$/] translation=[+49$1] isInternalExtension=[undefined].
2022-11-06T21:47:07.745Z Inf   PstnNumberService: [formatPhoneNumber] cleaned_formatting
2022-11-06T21:47:07.745Z Inf   PoliciesService: [normalize] [0160906xxxxx] was normalized into [+49160906xxxxx] using rule 3 of 3: ruleExpression=[/^0(\d+)$/] translation=[+49$1] isInternalExtension=[undefined].
2022-11-06T21:47:07.744Z Inf   [Scenario]people_remote_search start

Von unten nach oben sehen Sie gut, die eingegeben Rufnummer 0160906xxxxx, die dann durch die Regel 3 des Dialplan auf eine E.164-Nummer umgesetzt wurde.

Ich finde aber auch hier nichts, wie und warum Teams aus einem +4905251034613 oder +49005251034613 ein +495251034613 macht.

Sonderfall Extension Dialing

In Deutschland ist das Verfahren mit "Extensions" eigentlich unüblich aber in den USA und einigen anderen Ländern ist dies ein gängiges Verfahren um eine Durchwahl zum Teilnehmer zu erlauben. Anders als ein Deutschland haben Firmen in den USA nicht immer einen Rufnummernblock. Sie können also nicht jeder Nebenstelle auch eine externe Nummer zuweisen. Ein Anruf landet auf einer zentralen Rufnummer, die dann von einem Mensch oder einer Software, (Siehe Exchange Auto Attendant oder Teams Auto Attendant) bedient wird. Der Anrufer wählt die Hauptrufnummer und wartet, bis auf der Gegenseite abgehoben wird. Erst dann wählt er die Nebenstelle durch eine Nachwahl.

Technisch bedeutet das natürlich, dass die Teilnehmer alle erst einmal die gleiche Rufnummer hätten. Erst durch die Schreibweise wird in Teams und Skype for Business diese Funktion umgesetzt. Eine Rufnummer bei den Benutzern kann dann also so aussehen.

Jon Doe    +1 555 1234567;ext=12
Jane Doe   +1 555 1234567;ext=13
Mike Maus  +1 555 1234567;ext=14

Damit erklärt sich dann aber auch eines der Patterns in den Dialplänen, die Microsoft automatisch an die von Administratoren vorgegeben Regeln hinten anhängt:

   { "pattern": "^((\\+)?(\\d+))(;)?(ext|extn|EXT|EXTN|x|X)(=)?(\\d+)$",      "translation": "$1;ext=$7"},

Wenn ein Anwender in den Rufnummern irgendwas mit "(ext|extn|EXT|EXTN|x|X)" eingibt dann trennt der Dialplan dies in eine Stammrufnummer und der Extension entsprechend auf.

Zwischenstand

Ich hoffe, ich konnte etwas Licht in die Teams Rufnummernnormalisierung bringen und dass die meisten Firmen vielleicht gar keinen ausgefeilten Dialplan mehr anlegen müssen. Zumindest können die Regeln für nationale und internationale Calls in der Schublade bleiben wenn die Anwender direkt E.164-Nummern im Format "+<land><ortsnetz><teilnehmer>" wählen oder z.B. in Deutschland mit "0" oder "00" so tun, als würden Sie einen normalen Amtsanschluss nutzen. Nur wer bisher schon eine TK-Anlage hatte und quasi eigene Ziffern für eine  "Amtsholung" hinterlegt hat, sollte die internen Rufnummern mit einer Regel für die Anwender abhandeln.

Ich konnte aber bislang nicht klären, warum Teams eine "0" oder "00" direkt nach dem "ituCountryPrefix" auf dem Client entfernt. Das dürfte zwar ein ganz ganz seltener Sonderfall sein, aber unerwartet ist es schon. Nur gut, dass in der Vorschau dies schon angezeigt wird und ein Anwender in im Direkt-Feld oben auch ein Anruf mit "/anruf <E.164-Nummer>" starten kann.

Weitere Links