Grundlegendes zum Dial String Rewriting: Das „Zwiebelpinzip“ von anynode

Um eine Dial String Rewriting-Regel für Rufe zum Provider an der richtigen Stelle einzurichten, empfehlen wir, sich das Zwiebelprinzip von anynode vor Augen zu führen.

In unserem vereinfachten Schaubild erhalten Sie einen Einblick in die Arbeitsweise von anynode. In diesem Beispiel sehen Sie vier Nodes: ein Provider, eine PBX, ein Microsoft Teams und eine XCAPI.
Das Zwiebelschalenprinzip verdeutlicht in der ersten, äußeren Schale die Anpassung, also die Modulation. Hier wird der Header so eingestellt, dass die Gegenseite die Sprache versteht. Das anynode kann je nach Einstellung die dazu notwendigen Informationen aus verschiedenen Headern herausnehmen.

Dann geht der Ruf in die zweite Zwiebelschale, nämlich in das Dial String Rewriting der Rufnummern, falls dazu eine Notwendigkeit besteht. Erst danach geht der Ruf in das Routing. In dem Routing wird entschieden, wo der Ruf hin gehen soll. Beispielsweise kommt ein Ruf vom Provider und im Routing wird entschieden, dass dieser zur PBX geschickt werden soll.

Das Umschreiben der Rufnummer sollte immer am Eingang eines Nodes mit Regeln durchgeführt werden, damit nachher im Routing nur mit einem einzigen Rufnummernformat gearbeitet wird.

Grundsätzlich bezieht sich das Dial String Rewriting nur auf eingehende und ausgehende SIP-Nachrichten und nicht auf die Rufe.

Einführung in den Rewrite Rule-Assistenten

[02:09 Video Time-Code]​

Der Rewrite Rule-Assistent kann im SIP Node-Menü aufgerufen werden und dient der Anpassung von Quell- und Zielrufnummer. Öffnen Sie das Register „Dial String Rewriting and Mapping“. Die Dial String Rewriting-Regeln können Sie getrennt nach eingehenden und ausgehenden SIP-Nachrichten eintragen. Bitte beachten Sie: „Incoming Dial String Rewrite Rules“ und „Outgoing Dial String Rewrite Rules“ sind immer aus der Sicht von anynode zu sehen.

Wenn also die PBX dem anynode eine Nachricht sendet, ist es immer eine „incoming message“. Wenn das anynode der Gegenseite eine Nachricht schickt, ist es immer eine „outgoing message“.

Drücken Sie „Add“, um den Rewrite Rule Assistant zu starten.

Momentan stehen fünf Dial String Rewriting-Arten zur Verfügung, von denen die oberen ersten beiden Typen am häufigsten verwendet werden. In diesem Video werden wir Ihnen auch nur diese beiden Typen vorstellen. Mit „Match and Modify“ und „Match and Branch“ können noch weitaus komplexere Rewriting-Regeln erstellt werden, auf die wir in diesem Video nicht eingehen.

Die Option “Show advanced settings in the dialogs below” schaltet erweiterte Funktionen frei, die aber nur in speziellen Fällen benötigt werden. Dazu gehört die Möglichkeit, Rufnummern mit Tags zu markieren, um diese später anhand des Tags auszuwerten. Auf diese Funktion werden wir in einem gesonderten Video eingehen.

Prefix/Suffix Rewrite
Über das Prefix/Suffix Rewrite wird zunächst ein Filter gesetzt, mit dem die Rufnummern definiert werden, auf die das Dial String Rewriting angewendet werden soll. Die Eingabemaske ist übersichtlich so aufgebaut, dass sich der Filter immer im oberen Bereich bearbeiten lässt und die Aktion dazu im unteren Bereich.

Prefix bezeichnet den Beginn einer Rufnummer, Suffix bezieht sich auf die Stellen am Ende der Rufnummer. Mit „Delete Leading“ kann eine zu bestimmende Anzahl Zeichen vom Anfang der Rufnummer entfernt werden, „Delete Trailing“ bezieht sich wiederum auf die Zeichen beginnend vom Ende der Nummer. Über „Add Prefix“ wird ein neues Präfix bestimmt, welches vor die ursprüngliche Rufnummer gesetzt wird, mit „Add Suffix“ kann ein neues Rufnummernende gesetzt werden. Später werden wir dazu ein Praxisbeispiel zeigen.

“Display Name” kann zum Beispiel benutzt werden, wenn man seinen Namen nicht an ausgehende Rufe rausschicken möchte. In diesem Fall ändert man die Standardeinstellung von „leave as is“ auf „clear“. Es besteht auch die Möglichkeit, mit „set to“ alle ausgehenden Rufe generell mit dem Firmennamen rauszuschicken.

Apply To
Alle Dial String Rewriting Arten schließen mit „Apply to“ab. Hier kann bestimmt werden, auf welchen Dial String das Rewriting angewendet werden soll. Für ein effektives Umschreiben der Rufnummern empfehlen wir, die Standardeinstellung zu belassen und das Rewriting auf alle Dial Strings anzuwenden.
In der Standardeinstellung bezieht sich eine Dial String Rewriting-Regel also auf die Zielnummer und gleichzeitig auf die Quellnummer. Dies erspart die extra Eingabe von Regeln für Ziel- und Quellrufnummern.
Weitere Möglichkeiten sind:
Anwendung des Rewritings auf:
• All source (caller-side) dial strings: Alle Quellrufnummern der Anrufer-Seite
• All destination (callee-side) dial strings: Alle Zielrufnummern der Seite des Angerufenen

Die letzte Einstellung ist nur für spezielle Fälle vorgesehen.

Further Rules
Bei der Standardeinstellung ist die Funktion „Skip all further rewrite rules“ aktiviert. Es werden also alle weiteren Rewriting-Regeln übersprungen, sobald eine Regel greift und der Umschreibe-Prozess beendet.

Es besteht die Möglichkeit, weitere Rewriting-Regeln mit „process further rewrite rules“ zu berücksichtigen, wenn diese Regel angewendet worden ist. Dies ist aber in der Regel nicht empfehlenswert, da die die Gefahr besteht, dass sich Umschreibeprozesse verschachteln.

Name
Der „Name“ hilft dabei, die Regel später zu identifizieren und ist frei wählbar. Klicken Sie auf „Finish“, um die Regel einzutragen.

Übersicht der Dial String Rewriting-Regeln
In der Übersicht werden nun alle eingetragenen Regeln für Rufnummernumschreibungen (Rewritings) angezeigt. In der oberen Tabelle befinden sich die Regeln für eingehende SIP-Nachrichten und in der unteren Tabelle die Regeln für ausgehende SIP-Nachrichten.

Die eingerichteten Regeln werden nun von oben nach unten durchgegangen. Sobald es eine Übereinkunft mit einer Regel gibt, wird die Nummer entsprechend der Regel umgeschrieben. Sofern, wie vorher angegeben, „skip all further rewrite rules“ bei allen Regeln aktiviert wurde, wird für diese Nummer nun keine weitere Regel mehr aus dieser Liste angewendet.

Wir werfen nun noch mal einen Blick auf die weiteren Arten des Dial String Rewritings:

Wildcard Pattern Rewrite
Das Dial String Rewriting über ein Wildcard Pattern ermöglicht die gleichen Rewriting-Varianten wie zuvor erläutert, allerdings wird hier als Suchfilter nicht ein bestimmtes Prefix oder Suffix abgefragt, sondern man kann einen flexiblen Filter mit vordefinierten Wildcard-Zeichen festlegen.

Die folgenden Wildcards stehen zur Verfügung:

• 0-9 Eine bestimmte Ziffer, die vorkommen muss.
• X Eine beliebige Ziffer zwischen 0 und 9.
• ! Eine oder mehrere Ziffern zwischen 0 und 9.
• ? Ändert das vorherige Muster so, dass es beliebig oft vorkommen kann, einschließlich Null.
• + Trifft auf eine oder mehrere Wiederholungen des vorherigen Musters zu. Wenn der Ausdruck mit + beginnt, wird dieses Zeichen nicht als Wildcard, sondern als Zeichen + interpretiert.
• . Alle vorherigen Zeichen werden verworfen, die Ziffern nach dem Punkt werden übernommen.
• (Backslash) \+ Trifft auf das Zeichen + zu.
• [ 33 ] (Eckige Klammer links und eckige Klammer rechts] Hiermit wird ein Ziffernbereich festgelegt, z.B. [135]. Eine beliebige der Ziffern in diesem Bereich erfüllt die Bedingung.
Es kann anstelle von einzelnen Ziffern auch ein Bereich angegeben werden, z.B. [3−5]. Um die Bedeutung des Filters umzudrehen und die Ziffern auszuschließen, wird ein Zirkumflex am Anfang in den Klammern eingetragen: [^1-3].

Routing Domain und Route Assistant

[08:46 Video-Time-Code]

anynodes Routing Domains erlauben eine Vielfalt an Möglichkeiten, auf eingehende Rufe zu reagieren. Wenn man den Scenario Wizard für besonders häufige vorkommende Szenarien benutzt, werden hier automatisch vom Wizard die Routen angelegt. Auf der linken Seite befindet sich immer die Quelle des Rufes und auf der rechten Seite ist das Ziel des Rufes festgelegt. Die Routentabelle wird von anynode immer von oben nach unten abgearbeitet. Routen können mit den „Up“ und „Down“ Schaltflächen nach oben oder nach unten geschoben werden. Als nächstes schauen wir uns den Route Assistant genauer an. Dieser kann mit „Add“ geöffnet werden.

Eine Route besteht prinzipiell aus zwei wichtigen Teilen: Einmal der Filter, der definiert, ob eine Route genommen wird oder nicht. Der zweite Teil ist das Establishment, hier wird definiert, was mit diesem Ruf passieren soll. Bei der Konfiguration sollte zunächst immer mit der Definition des Filters begonnen werden.

Route Assistant: Filters
Der Route Assistant beginnt mit der Abfrage nach dem Filter. Das wird in den meisten Fällen gewünscht sein. Falls kein Filter gewünscht sein soll, kann „unconditional routing“ ausgewählt werden und die Filter-Eingabe wird übersprungen. Wenn kein Filter definiert ist, wird diese Route bedingungslos genommen, wenn alle vorhergehenden Routen nicht in Frage kommen.

Im Routenassistent ist es bei der Quelle möglich, eine Mehrfachauswahl zu tätigen. Man kann eine oder mehrere Quellen auswählen. Die Standardeinstellung erlaubt alle Nodes. Es dürfen dann alle Quellen diese Route benutzen. Öffnet man das Schloss bei „Restrict the set of source nodes“, kann eine Auswahl bestimmter Nodes festgelegt werden.

Rufe können beispielsweise geroutet werden anhand der folgenden Möglichkeiten:

Route Assistant: Filters: Source Dial String
Bei „Source Dial String“ können wir definieren, welche Bedingungen erfüllt sein müssen, damit der Filter und damit die Route zieht. Hier kann eine Abhängigkeit basierend auf der anrufenden Quellnummer (Source Dial String) erstellt werden. Bei dem Typ der Übereinstimmung kann das mit „Match Always“ jeder Nummer erlaubt werden. Dies ist auch die Standardeinstellung. Weitere Möglichkeiten der Auswahl von zutreffenden Dial Strings sind:

• MatchAlways (alle Nummern werden erlaubt),
• MatchNever (keine Nummern werden erlaubt),
• MatchPrefixandSuffix (erlaubte Rufnummern anhand der Ziffern am Anfang oder Ende der Nummer definieren)
• Match Wildcard Pattern (ein flexibler Filter mit vordefinierten Wildcard-Zeichen, was vorhin schon erklärt worden ist)
• Extension Range (ein bestimmter Bereich an Rufnummern)
• Match Distinct Dial Strings (eine Liste an verschiedenen Dial Strings)
• Match List (hier können mehrere Bedingungen in einer Liste oder sogar verschachtelt definiert werden)

Route Assistant: Filters: Destination Dial String
Bei „Destination Dial String“ können wir eine Regel basierend auf der Zielrufnummer einrichten. Wir empfehlen, im Routing immer mit den vollqualifizierten Rufnummern zu arbeiten.

Route Assistant: Filters: Asserted Dial String
Der Asserted Dial String wird oft verwendet, um die Nummer zu transportieren, die im P-Asserted Identity Header übermittelt wird. Der P-Asserted Identity Header wird zwischen vertrauenswürdigen SIP-Gegenstellen verwendet, um die Identität des Benutzers zu übermitteln.

Route Assistant: Filters: First Diversion Dial String, Last Diversion Dial String
Sollte die Notwendigkeit bestehen, auf umgeleitete Anrufe zu reagieren, besteht die Möglichkeit, eine Regel über „First Diversion Dial String“ oder „Last Diversion Dial String“ einzurichten. In diesem Fall wird eine Liste mit einem ersten Eintrag und einem letzten Eintrag gepflegt. Nun kann eine Regel basierend auf dem ersten Eintrag in dieser Liste greifen. Genauso kann eine Regel basierend auf dem letzten Eintrag in dieser Liste unter „Last Diversion Number Directory“ eingerichtet werden.

Route Assistant: Filters: Transferrer Dial String
In der Praxis könnte man den Transferrer Dial String beispielsweise nutzen, wenn bei einem Telefonat ein Gesprächspartner das Gespräch weiterverbinden möchte. In diesem Fall greift dann eine Regel, basierend auf der Nummer desjenigen, der das Gespräch weiterverbunden hat.

Route Assistant: Filters: Elin Dial String
Auch die Emergency Location Identification Number, kurz „ELIN“ genannt, die bei Notrufen mit übermittelt wird, kann in den Filter mit aufgenommen werden.

Die ELIN Nummer wird hauptsächlich im US-amerikanischen Raum verwendet, kann aber auch in Produkten wie Microsoft Teams auch in anderen Regionen mitverwendet werden.

Route Assistant: Filters: Conditions

Bei Conditions können rufübergreifende Bedingungen als Routenfilter ausgewählt werden. Bitte beachten Sie, dass diese hier nur verfügbar sind, wenn eine Condition unter Conditions im Hauptbaum bereits angelegt worden ist.

Route Assistant: Filters: Directory

In sämtlichen Dialstring-Filtern können außerdem Rufe anhand eines Directorys, z. B. eines Azure Dial String Directories geroutet werden. Die Auswahlmöglichkeit befindet sich immer im unteren Bereich.

Establishment: Select Action

Nachdem die Filterbedingungen angelegt wurden, wird als dritter Schritt die eigentliche Aktion festgelegt, die durch diese Regel ausgeführt werden soll.

Für jede Aktion können weitere Parameter festgelegt werden:

Route Call: Hier wird zunächst der Node ausgewählt, über den der Ruf verbunden werden soll. Weiterhin stehen noch Routing Forward Profile zur Auswahl, mit denen unter anderem bestimmt wird, wie die Medien der beiden Rufe verbunden werden sollen. Abschließend kann über das Dial String Rewriting noch die Quell- und Ziel-Rufnummer angepasst werden. Wir empfehlen, dieses hier an dieser Stelle nur in Ausnahmefällen durchzuführen und das Dial String Rewriting in den Nodes direkt vorzunehmen. Daher werden wir das Dial String Rewriting hier auch überspringen.

Reject Call: hier kann ein Ablehngrund definiert werden, der der anrufenden Gegenstelle signalisiert wird.

Establish Parallel Calls: Hier wird die gewünschte Anzahl an Parallelrufen zunächst der Liste hinzugefügt, anschließend werden die einzelnen Ziel-Rufnummern festgelegt. Die Vorgehensweise entspricht dem Dial String Rewriting von Rufnummern auf Node-Ebene.

Redirect Call: hier wird als Parameter angegeben, an welches Ziel der Ruf umgelenkt werden soll. Es kann also anhand der Quell- oder Ziel-Rufnummer eine neue Zielrufnummer erstellt werden, an die der Ruf umgelenkt werden soll.

Ignore Call: da hiermit eingehende Rufe völlig ignoriert werden, können keine weiteren Parameter definiert werden.

Praxisbeispiel: Rewritings eintragen

[15:07 Video-Time-Code]

Unser Praxisbeispiel möchten wir mit einer typischen Konstellation zwischen einem VoIP-Provider, einer herkömmlichen PBX mit internen Durchwahlen, Microsoft Teams mit E.164-Rufnummern, und anynode als vermittelnder Instanz zwischen den Anlagen durchführen. Wir möchten darauf hinweisen, dass wir in diesem Beispiel der Einfachheit halber Notrufnummern nicht berücksichtigen.

Wir empfehlen, als optimales Vorgehen und Best Practice vor dem Routen alles auf das internationalisierte E.164-Format zu überführen. Nach dem Routen werden die Rewritings so gesetzt, dass die anzurufende Gegenstelle das Format versteht. Die Manipulationsrichtung incoming und outgoing ist immer aus der Richtung des anynodes zu verstehen.

Hier wird bei eingehenden Rufen die Quell- und Ziel-Rufnummer aus dem Format des Providers in das internationalisierte E.164-Format überführt.
Microsoft Teams verwendet Rufnummern in der internationalen E.164-Formatierung, während die PBX nicht mit dem E.164 Format kompatibel ist und nur die Stammnummer mit Teilnehmernummer unterstützt und auch nur die Stammnummer mit der Teilnehmernummer an das anynode liefert.

Im PBX Node würde das Dial String Rewriting für die Absenderkennung bei den outgoing Dial String Rewritings so aussehen, damit die PBX damit kompatibel ist: Rufe aus dem Ausland, hier z. B. Österreich, würden mit für die PBX kompatibler Absenderkennung auf den Endgeräten angezeigt.

In der Routing Domain wird versucht, eine Route zu finden, die auf die Kriterien des eingehenden Rufs zutrifft. In der Grafik sind 3 Routen dargestellt. Es wird geprüft, ob der Destination Dial String passt und dann wird das eingestellte Establishment mit der Aktion, also der Route Call zu dem entsprechendem Node durchgeführt. Das Routing anhand des Destination Dial Strings hat den großen Vorteil, dass Benutzer der PBX auch Microsoft Teams Teilnehmer anrufen können und umgekehrt.

In unserem Beispiel kommt der Ruf vom Provider und es wurde der Destination Dial String vom Microsoft Teams-Teilnehmer gewählt, also wird Route 1 genommen und der Ruf wird zu dem Microsoft Teams Teilnehmer geroutet.

Jetzt möchten wir unser Praxisbeispiel im anynode Frontend umsetzen.
Wir beginnen mit der Eintragung der Dial String Rewritings.

Wir gehen in den Node des VoIP Providers und starten bei den eingehenden SIP-Nachrichten den Assistenten. Wir möchten ein Prefix and Suffix Rewriting durchführen und tragen ein, dass ein 00 durch ein + ersetzt wird. Der Assistent erkennt die Anzahl der zu löschenden Ziffern automatisch. Das Dial String Rewriting soll für den Destination und Source Dial String gelten und das Dial String Rewriting soll nach dieser Regel enden. Ein Klick auf „Finish“ trägt das Dial String Rewriting ein.

Die zweite Regel bei den Incoming Dial String Rewritings soll sein, dass eine 0 durch ein +49 ersetzt wird.

Jetzt legen wir in der selben Vorgehensweise in den ausgehenden SIP-Nachrichten fest, dass Dial Strings wieder in das für den Provider kompatible Format gewandelt werden. In diesem Fall soll +49 wieder in eine 0 gewandelt werden und ein + in ein 00.

Die Routentabelle sieht jetzt so aus:

Jetzt bringen wir im Node der PBX die Rufnummern in das für die Gegenstelle kompatible Format.
Wir beginnen mit den eingehenden SIP-Nachrichten und hier führen wir ebenfalls ein Prefix and Suffix Dial String Rewriting durch.

Ein ankommendes 00 soll durch ein + ersetzt werden.

In der zweiten Regel soll eine 0 durch ein +49 ersetzt werden.

In der dritten Regel soll ein +49 5363 hinzugefügt werden, da nur die Stammnummer von der PBX geliefert wird.

Bei den outgoing Dial String Rewritings im PBX-Node lauten die Regeln so:
Die Stammnummer +49 5363 soll komplett gelöscht werden, aber durch nichts ersetzt werden.

In der zweiten Regel wird ein +49 durch eine 0 ersetzt.

In der dritten Regel wird ein + in eine 00 gewandelt. Die Routentabelle sieht anschließend so aus:

Anschließend sollten wir nicht vergessen, die Konfiguration mit einem Klick auf „Commit“ endgültig abzuspeichern.

Praxisbeispiel: Routen anlegen

Schauen wir uns jetzt an, wie wir im Routing Assistant Route 1 anlegen.

Wir übernehmen den Standardwert, allen Nodes diese Route zu erlauben.

Jetzt legen wir den Destination Dial String fest. Der Match Type soll Prefix and Suffix sein und der Suffix 999 ist der Microsoft Teams Teilnehmer. Jetzt können wir schon auf „Finish“ klicken.

Im Establishment wird jetzt die Aktion festgelegt, nämlich „Route Call“. Der Destination Node ist Microsoft Teams. Den Rest benötigen wir nicht und können an dieser Stelle schon auf „Finish“ klicken.

Bei der Route 2 gehen wir ähnlich vor und legen im Destination Dial String die 888 als Suffix fest und das der Ruf dann zur PBX geroutet werden soll.

Die dritte Route soll genommen werden, wenn die beiden ersten Routen nicht in Frage kommen. Wenn der Ruf also von der PBX oder von Microsoft Teams kommt, wird der Ruf zum VoIP-Provider geroutet.

Auch hier müssen wir die Konfiguration durch einen Klick auf „Commit“ endgültig abspeichern. Die Routentabelle sieht jetzt so aus:

Ruftest

[23:15 Video-Time-Code]

Um die Konfiguration und die Dial String Rewritings zu überprüfen, können wir einen schnellen Blick in den Monitor Mode werfen.

Wir sehen hier, dass der Ruf vom VoIP Provider reinkam und in das E.164 Format gewandelt und anschließend zu Microsoft Teams geroutet wurde. Die Anzeige hier und in der Call History zeigt immer den Zustand der Rufnummern an, wenn der Ruf in das Routing geht. Diese Rufnummern sind also schon alle umgewandelt.