Einleitung
Herzlich willkommen zu einer weiteren Ausgabe der anynode-Lernvideos. In diesem Video, welches sich an fortgeschrittene anynode-User richtet, erfahren Sie mehr über die Möglichkeit, wie man mit Hilfe des SIP URI Processings die einzelnen Informationen einer SIP-Nachricht ausliest und zusammensetzt.
Um die Vorgänge beim SIP URI Processing besser zu verstehen, möchten wir uns kurz anschauen, wie anynode unter der Haube als SIP-to-SIP User Agent funktioniert.
Funktionsweise eines SIP-To-SIP User Agents
Hier kommunizieren zwei Endpunkte nicht direkt miteinander, sondern anynode terminiert jeweils die SIP-Nachrichten des Quell-Nodes und erstellt für den Ziel-Node neue und von dem Quell-Node völlig unabhängige SIP-Nachrichten. Quell- und Ziel-Endpunkt wissen also gar nichts voneinander, beide kennen nur anynode als Gegenstelle. Dadurch ist gewährleistet, dass keine dem Ziel-Endpunkt unbekannten SIP-Nachrichten zugestellt werden. Zusätzlich bleiben die interne SIP-Kommunikation sowie die Infrastruktur unsichtbar, wenn anynode als Session Border Controller zwischen einem externen und einem internen Netzwerk vermittelt.
pbx.anynode.com
Routing Domain
Pro Gegenstelle muss ein eigener Node in der anynode-Konfiguration angelegt werden. In den Node-Einstellungen werden neben den Transport-, SIP- und Medien-Parametern auch Möglichkeiten zur Anpassung von Rufnummern angeboten.
Die Verbindung zwischen den einzelnen Nodes wird über Routen-Tabellen hergestellt, die sogenannte Routing Domain.
Ein Ruf geht immer über einen eingehenden Node und einen ausgehenden Node. Diese Nodes sind immer über das Routing verbunden. Man erhält also 2 getrennte Rufe.
Routentscheidungen werden in den meisten Fällen anhand von Dial Strings getroffen. Die Dial Strings ergeben sich aus den dazugehörigen URIs, also Uniform Resource Identifier. Dabei wird anynode immer zur lokalen Seite für die Gegenstelle.
In unserer anynode-Konfiguration haben wir bereits zwei Nodes angelegt, eine Telefonanlage und einen VoIP-Provider.
Der Ruf kommt über die Netzwerkkarte rein. Als nächstes durchläuft der Ruf den SIP Transport. Hier können spezielle Transport Protokolle eingestellt werden, wie UDP, TCP und TLS. Bei Media Negotiation können Einstellungen zur Abhandlung der Medien vorgenommen werden, z. B. Codecs oder ob die Medien verschlüsselt oder nicht verschlüsselt übertragen werden sollen.
Im SIP User Agent werden die SIP-spezifischen Einstellungen vorgenommen.
Im SIP Node kann unter anderem eine Rufnummernmanipulation vorgenommen werden, an dieser Stelle möchten wir darauf hinweisen, dass es zu diesem Thema ein extra Lernvideo „Grundlagen Rufnummernmanipulation und Routing“ gibt.
Danach geht der Ruf in das Routing, wo anschließend ein ausgehender Ruf eingeleitet wird. Im ausgehenden Node durchläuft der Ruf jetzt die andere Reihenfolge.
SIP URI Processing im SIP User Agent
Jetzt möchten wir uns das SIP URI Processing genauer anschauen. Wie vorhin schon erwähnt, werden die Routenentscheidungen in den meisten Fällen anhand von Dial Strings getroffen. Die Dial Strings ergeben sich aus den dazugehörigen URIs. An dieser Stelle können wir bestimmen, aus welchen SIP-Headern einer eingehenden SIP-Nachricht URIs bezogen werden sollen. Durch das Setzen des Hakens können wir bei Bedarf von den Standard-Werten abweichen und mit dem Plus-Zeichen weitere Eingaben hinzufügen.
Für ausgehende Rufe kann man definieren, woher die SIP-Nachricht die Werte für die einzelnen Header nehmen soll.
Hier wird die local Signaling-URI definiert. Hierbei handelt es sich um die angerufene Adresse des anynode-Systems.
Die Destination URI ist die Zieladresse, die angerufen werden soll. In der Regel ist dies eine Telefonnummer und die Local Signaling URI entspricht der Destination URI. Daher ist als Standardeinstellung beim anynode für beide Fälle die Target URI, also die erste Zeile der SIP-Nachricht, eingestellt.
Die remote Signaling-URI stellt im Normalfall die Nummer dar, die den Ruf aufbaut, also die Absendernummer.
Die Asserted URI ist ein Platzhalter, den man flexibel nutzen kann. Der Platzhalter Referrer URI wird nur in seltenen Fällen benutzt, daher werden wir hier nicht genauer eingehen.
Diese Werte kann man jetzt für das Routing benutzen. Wenn der Ruf das Routing verlässt, kann man die Inhalte der folgenden Felder bei den ausgehenden SIP-Nachrichten bestimmen. Wichtig ist das Feld für den From-Header und für die Target-URI und außerdem auch noch das Feld für den TO-Header. Die Felder P-Asserted Identity und P-Preferred Identity können benutzt werden, falls dies der Provider erfordert.
Bei den URI-Werten der Eingabefelder muss man unbedingt beachten, dass nach dem Routing, also wenn der zweite Ruf aufgebaut wird, sich die URIs umdrehen.
Nach dem Routing wird nämlich die Remote Signaling URI bei dem rausgehenden Ruf zu der local Signaling URI. Die local Signaling URI wird zur Remote Signaling URI.
Die Remote Signaling-URI wird im SIP-Node zur Source Address.
Die Source Address beinhaltet wiederum unter anderem den Souce Dial String und den Source Display name. Der Source Dial String kann dann für das Routing verwendet werden.
Die Destination URI wird zur Destination Address. Die Destination Adress beinhaltet unter anderem den Destination Dial String und den Destination Display Name.
Behandlung der Tabellen
Die Eingaben in den Tabellen werden von unten nach oben abgearbeitet.
Wenn es den Header in der Tabelle gibt, dann wird er genommen. Falls nicht, wird der Nächsthöhere genommen. Wenn es keinen dieser Header gibt, wird bei den optionalen Feldern der SIP-Header auch nicht in die SIP-Nachricht eingefügt.
Praxisbeispiel: Username im To-Header
Jetzt möchten wir das SIP URI Processing anhand eines Praxisbeispiels richtig einstellen. In unserer anynode-Konfiguration haben wir bereits zwei Nodes angelegt, eine Telefonanlage und einen VoIP-Provider. Selbstverständlich kann sich diese Telefonanlage lokal oder in der Cloud befinden. In unserem Beispiel können beide Seiten E.164 Rufnummern unterstützen.
Es kommt ein Ruf vom Provider rein und soll zur Telefonanlage geroutet werden. Wir werfen einen Blick in den Monitor Mode und sehen, dass der Ruf zwar reinkommt, aber nicht geroutet werden kann, da in der Called Number ein Username zu sehen ist.
Eigentlich würden wir hier eine Rufnummer erwarten. Im Trace erhalten wir dazu genauere Analysemöglichkeiten. Dies haben wir bereits vorher mitlaufen lassen.
Wir sehen hier, dass in der obersten Zeile, also in der Target URI, der Username drin steht. Die Rufnummer, die angerufen wird, entdecken wir in dem To-Feld.
Wir gehen also zurück in die anynode-Konfiguration in den Provider-Node und finden dort das Eingabefeld für die Herleitung der Destination-URI. Wir vorhin schon erwähnt, wird die Destination URI standardmäßig aus dem Target Header genommen.
Daher fügen wir mit dem Plus (+) den To-Header hinzu und löschen mit dem Minus (-) die Target URI heraus.
Anschließend dürfen wir nicht vergessen, die Eingaben durch ein „Committ“ zu bestätigen. Nun kann die gewählte Zielrufnummer korrekt für das Routing benutzt werden.
Praxisbeispiel: keine Rufnummer im P-Asserted-Identity Header für die Provider-Identifikation
Jetzt machen wir einen Ruf in die andere Richtung, also zum Provider hin. Im Monitor Mode sehen wir, dass der Ruf in diese Richtung auch fehlschlägt. Wir haben vorher bereits ein Trace mitlaufen lassen und sehen, dass der Provider den Ruf mit „Decline“ ablehnt.
Im From-Header entdecken wir, dass unser Anmeldename, also AOR, zum Provider gesendet wird.
Wir möchten aber, dass dem Empfänger unsere richtige Absenderkennung übermittelt wird.
Nun schauen wir uns an, wie der From-Header derzeit in unserer Konfiguration zustande kommt.
Wir sehen, dass der From-Header aus der Transport Connection URI, also in unserem Fall der AOR, genommen wird. Das ist SIP-technisch zwar korrekt, aber in unserem Fall nicht zielführend. Also löschen wir die Zeile und dann wird die Local-Signaling-URI genommen, welche die richtige Absenderkennung enthält.
Jetzt testen wir das gleich wieder und sehen im Trace, dass die Zeile mit dem From-Header mit der richtigen Absenderkennung übermittelt wird.
Aber dennoch wird der Ruf vom Provider abgelehnt.
Unser Provider hat uns dazu in seinen Vertragsunterlagen informiert: Er verlangt unsere Stammnummer im P-Asserted Identity-Feld als Identifikation.
Wir müssen also das Feld P-Asserted Identity setzen. Wir legen nun fest, dass unsere Nummer aus der Local-Signaling-URI genommen wird, damit unsere Absendernummer dem Provider in dem P-Asserted Identity-Feld übermittelt wird.
Durch einen Klick auf Commit bestätigen wir unsere Eingaben endgültig.
Nun wird der Ruf vom Provider akzeptiert.
Im Trace ist die P-Asserted Identity richtig angegeben.
An dieser Stelle möchten wir noch mal auf einen besonderen Fall in der Konfiguration hinweisen, welcher in der Praxis durchaus öfters vorkommt: Nicht immer hat die local Signaling URI einen Wert, den der Provider akzeptiert.
Das passiert unter anderem, wenn man beliebig fremde Rufnummern verwenden möchte oder die Rufnummer gar nicht bei Rufnummernunterdrückung übertragen wird. In so einem Fall muss man eine feste voreingestellte Rufnummer im P-Asserted-Identity Header übermitteln. Im SIP-URI Processing fügen wir die Asserted URI hinzu und diese URI kann man im SIP-Node an dieser Stelle bestimmen.
Mit einem Klick auf „Edit“ können wir unsere Stammnummer unter „User Info“ eintragen und erhalten so unsere Asserted-URI.
Alternativ kann das auch, sofern eine Transport Connection verwendet wird, in der Transport Connection Asserted-URI eingestellt werden.
Wir gehen also unter Standard Transport Connection in das Eingabefeld für die Asserted URI. Auch hier kann man die Nummer unter „User Info“ eintragen. Der Vorteil der Eingabe in der Standard Transport Connection liegt darin, dass immer die richtige Stammnummer genommen und übermittelt wird, wenn mehrere Transport Connections eingerichtet sind.
Damit sind wir am Ende dieses Lernvideos angekommen und bedanken uns für die Aufmerksamkeit.