Was ist ein Vodafone NGN Trunk? #

Zur Ersatz unseres alten ISDN Anlagenanschluss (also einen Firmenanschluss mit Durchwahlen) wurde uns in 2021 von Vodafone nahegelegt, auf einen sogenannten VoIP Anschluss umzustellen. Inzwischen habe ich - durch intensive Suche nach Hilfe im Internet - gelernt, das es da ziemlich viele verschiedene Varianten von Anschlüssen und entsprechenden Konfigurations-Schemata aus der langen Geschichte von Vodafone und Arcor und Unitymedia und wasweissich gibt, die alle durch das Internet geistern.

Was ich hier habe, ist etwas, das man im Internet am ehesten als NGN Trunk bezeichnet (Next Generation Network). Ein Trunk bezeichnet bei Telefonanlagen immer einen Anschluss eines Netzbetreibers (also die Asterisk-Verbindung nach draussen ins Telefonnetz.) Im Grunde meint NGN hier wohl so etwas wie einen VoIP-Anschluss auf Speed. Die Telefongesellschaft bietet (angeblich) erweiterte Quality of Service, die einem Festnetzanschluss vergleichbar sein soll, das Übertragungsverfahren ist aber letztlich eine ganz normale SIP-Verbindung (wie bei VoIP üblich). Wie man so liest, dient das letztlich auch dazu, mit jedem Telefonanschluss direkt einen Internetanschluss mitzuverkaufen...

In den mir von Vodafone zugesandten Anschlussdaten steht auch eine SIP-Domain, die auf ngn.vodafone.de endet. Das scheint mir ein aktuelles charakteristisches Merkmal dieser Art von Anschluss zu sein.

Welche Unterschiede ergeben sich daraus für Asterisk? #

Allerdings ist die Konfiguration nun auch etwas anders. Dank dem sehr guten Buch Asterix - The Definitive Guide habe ich erst verstanden, das es Provider gibt, die im Business-Bereich Anschlüsse einsetzen, die sich etwas anders verhalten als das, was man normalerweise in Anleitungen über SIP-Anschlüsse so liest:

• Der Anschluss wird über die IP-Adresse authentifiziert. Man kann also nur und ausschließlcih von einer einzigen festen IP-Adresse aus mit dem Vodafone-SBC (also deren Anschlusspunkt, sozusagen die Vermittlungsstelle) kommunizieren.
• Folglich gibt es auch keine Authentifizierung über Benutzernamen und Passwort.
• Außerdem wird die Anlage auch nicht Registriert. Normale Verbindungen beginnen mit einer REGISTER Nachricht, wodurch der Provider informiert wird, das ich jetzt da bin, das ich authentifiziert bin und das ich jetzt Anrufe entgegennehmen kann. Diese Registrierung entfällt bei NGN Anschlüssen: Sie ergibt sogar eine Fehlermeldung, was mich so ungefähr eine Woche meines Lebens gekostet hat.
• Die Registrierung ergibt sich mit dem ersten ausgehenden Telefonat. Also muss man nach dem Start des Asterisk einmal raustelefonieren, um anschliessend reintelefonieren zu können. (Ich bin sicher, das das auch anders gehen muss, aber bisher habe ich nicht rausgefunden, wie).

konkrete Konfigurationsdateien #

Wie können SIP-Geräte in Asterisk konfiguriert werden und wie mache ich das hier? #

Im Laufe der Entwicklung von Asterisk hat sich die Konfiguration von SIP-Anschlüssen stark gewandelt. Hier habe ich viel gelernt...

sip.conf #

In klassischen Asterisk-Versionen gab es ein SIP-Modul, das durch eine Datei namen sip.conf recht einfach konfiguriert werden konnte. Hier gab es immer genau einen Konfigurations-Eintrag für einen Anschluss (also für jeden internen Endpunkt wie ein SIP-Telefon und für den Trunk nach draussen ins Telefonnetz).

pjsip.conf #

Aber natürlich gibt es kein Stück Software, das man nicht verbessern und ersetzen kann und mit einer viel komplizierteren Konfiguration noch viel flexibler, mächtiger und schwieriger machen kann. Also wurde in neueren Asterisk-Versionen auf das neuere PJSIP-Modul umgestellt, das durch die Datei pjsip.conf konfiguriert wird. sip.conf ist inzwischen deutlich deprecated, obwohl es natürlich noch viele Anleitungen im Internet (das ja bekanntlich nichts vergisst) hierzu gibt.

In der Datei pjsip.conf ist die Konfiguration auf verschiedene Entitäten aufgeteilt, so das Geräte, Endpunkte, Authentifizierung, Registrierung etc. eigene Einträge haben, die sich dann jeweils aufeinander beziehen, so das sich eine funktionierende Einstellung ergibt. So mache ich das hier in meinem Beispiel.

pjsip.conf auf verschiedene Dateien aufgeteilt #

Durch die Fähigkeit Asterisks, das man #include Befehle verwendet, um andere Dateien mit einzulesen, kann man diese Konfiguration nun aufteilen. Da viele INstallationen von Asterisk mit irgendeiner graphischen Oberfälche oder einem sonstigen Generator für die Konfiguration laufen, kann man so die Einstellungen auf verschiedene, automatisch generierte und getrennt zu verwaltende Dateien aufdröseln. Daher ist es auch schon mal üblich, das es Dateien wie pjsip_trunks.conf oder pjsip_endpoints.conf oder gar pjsip_endpoints.d/*.conf oder so gibt. Das ist letztlich eine Frage, wie man das installiert und aufbaut. Wer sich in bestehenden Anleitungen oder laufenden Installationen umschaut, sollte das aber schonmal gehört haben.

pjsip.conf in einer Datenbank #

Letztlich geht die Aufteilung aber noch viel weiter. In den aktuelleren Asterisk-Versionen ist es möglich (und wird in vielen neueren Anleitungen, z.B. auch in o.g. Buch, auch standardmäig verwendet), alle diese Einstellungen in einer Datenbank abzulegen. Es gibt dann also eine Tabelle für Endpoints, die sozusagen die Datei pjsip_endpoints.conf ersetzt. Ich selber habe damit noch nicht gearbeitet, freue mich aber, da auch irgendwann mit herumzuspielen. Blöd an dieser Lösung ist, das die Konfiguration für ein einfaches Problem (Anschluss Vodafone) sehr kompliziert über mehrere Befehle und Tabellen verteilt wird und hinterher nicht mehr an einem Platz zu finden ist.

Meine pjsip.conf #

Hier seht ihr nun mein Beispiel für eine pjsip.conf Datei zum Anschluss eines Vodafone NGN Trunks. Alle Namen und Adressen habe ich anonymisiert, aber als Beispiel sollte das klar sein.

  [general]
  language=de
  _
  [transport-udp]
  type=transport
  protocol=udp
  bind=192.168.1.5
  _
  [transport-tcp]
  type=transport
  protocol=tcp
  bind=12.34.56.78
  _
  [vodafone_aor]
  type = aor
  contact = sip:021514555990@2.207.165.114:5060
  _
  [vodafone_identity]
  type = identify
  endpoint = vodafone
  match = 2.207.165.114
  _
  [vodafone]
  type = endpoint
  context = vodafone-in
  dtmf_mode = rfc4733
  disallow = all
  allow = alaw
  ;allow=g722,ulaw,alaw,gsm,g726
  timers = yes
  ; Wird from_user hier angegeben, wird das immer als Absender verwendet
  ; und es kann keine andere CallerID mehr angegeben werden.
  ;from_user = 021514555990
  from_domain = thomasbayen.ngn.vodafone.de
  language = de
  aors = vodafone_aor
  transport=transport-tcp

Hierbei habe ich folgende Bemerkungen notiert:

• 021514555990 ist die Hauptrufnummer, unter der ich immer erreicht werden kann. Innerhalb des aor Elements gibt sie an, wie ich den Anschluss gegenüber Vodafone benenne (Ich weiss jetzt nicht mehr ganz genau, wie diese Information in der SIP-Nachricht landet). Das ist aber nicht unbedingt die Nummer, die einem angerufenen angezeigt wird. Diese sogenannte CallerID kann entweder im Dialplan bei jedem Anruf gesetzt werden (was bei einer Nebenstellenanlage durchaus Sinn macht, um die Durchwahlen nach außen zu kommunizieren). Ich habe aber festgestellt, das man sie auch hier im from_user Feld angeben kann, womit die Angabe einer CallerID komplett überlagert wird. Das wird keiner wollen, könnte aber in einfachen Umgebungen auch interessant sein, um sich das dann im Dialplan zu sparen.
• 2.207.165.114 ist die von Vodafone angegebene Adresse ihres SBC (Session Border Controller), also ihrer Vermittlungsstelle.
• ENDPOINT ist sozusagen der wichtigste Eintrag. Er bezeichnet einen Anschluss.
• AOR (address of record) bezeichnet sowas wie den Namen, unter dem ein Anschluss dem Provider gegenüber dargestellt wird. Das grenzt sich, wenn ich das richtig verstanden habe, von einem Endpoint ab, indem es unterschiedliche Endpoints geben könnte, wenn z.B. Vodafone einen Hochverfügbarkeitsanschluss einrichtet mit zwei oder mehr SBC-Adressen - oder ich habe zwie verschiedene Asterisk-Server. Dann hätte ich mehrere Endpoints unter derselben Anschluss-Identität. Diese wird durch den AOR-Eintrag festgelegt.
• IDENTIFY legt fest, wie eingehende Pakete einem Endpoint zugeordnet werden. In unserem Fall geschieht das ausschließlich per IP-Adresse. Denkbar wäre auch, das man dafür den in der Nachricht angegebenen Usernamen verwendet, dann braucht man keine identify-Sektion. Dafür ist dann aber wohl eine andere Art der Authentifizierung (AUTH) angesagt.
• Mit disallow und allow kann man verschiedene Codecs für die Sprachübermittlung angeben. So richtig ist mir bisher noch nicht klar, was da eine gute Einstellung ist. Vielleicht kann ja ein fleissiger Leser was dazu sagen.
• Der Transport ist eine weitere Besonderheit des Vodafone NGN Anschlusses. Im Schreiben mit den Zugangsparametern haben die mir mitgeteilt, das sie Daten per TCP übertragen (und man das auf Wunsch umstellen lassen kann). Andererseits ist das ganze Internet voll mit Anleitungen, die besagen, das SIP quasi immer mit UDP-Paketen arbeitet. Warum die das jetzt anders machen, kann ich auch nicht erklären. In obiger Konfiguration habe ich zwei verschiedene transports definiert und damit dafür gesorgt, das tcp nur an meine öffentliche IP-Adresse bindet (12.34.56.78) und UDP nur an die interne, an der die Telefone hängen (192.168.1.5). Das erscheint mir so ganz sinnvoll zu Absicherung, wobei das natürlich keine Identify-Einträge und keine Firewall ersetzt.

Netzwerkkonfiguration #

Nachdem ich extrem grosse und langwierige Schwierigkeiten bei der Konfiguration hatte, habe ich irgendwann entschieden, alle theoretischen Probleme mit dem Netzwerkrouting und NAT aus dem Weg zu räumen und die Asterisk-Maschine sozusagen direkt mit eigener IP-Adresse ins Internet gestellt. Wie man das am besten macht, liegt an der Konfiguration des Routers und übersteigt das Thema dieses Artikels hier.

Au jeden Fall habe ich eine virtuelle Maschine mit zwei Netzwerkschnittstellen erzeugt, die mit einer Schnittstelle direkt auf der Adresse 12.34.56.78 im Internet ist und mit der zweiten Schnittstelle im lokalen Netz hängt.

Firewall #

Auch die Einrichtung einer Firewall geht über das Thema dieses Artikels hinaus. Ich möchte aber die Details, die ich hier in meine nftables-Konfiguration eingebaut haben, kurz anreissen:

  table ip filter {       
     chain input {                
        type filter hook input priority 0; policy drop;
        ct state established,related accept 
        meta iifname ens3 ip saddr {192.168.1.1-192.168.1.255} ip daddr 192.168.1.5 counter accept
        ...
     }
     chain output {               
        type filter hook output priority 0; policy drop;
        meta oifname ens3 ip daddr {192.168.1.1-192.168.1.255} ip saddr 192.168.200.5 counter accept
        meta oifname ens9 ip saddr 12.34.56.78 ip daddr 2.207.165.114 counter accept
        meta oifname ens3 tcp dport {80,443} counter accept
        ...
     }
  }

Und was hat die meisten Probleme gemacht? #

Noch so zum Ende der Geschichte ein Schmankerl, über das ich zuerst gar nicht lachen konnte...: Nachdem ich tatsächlich ungefähr 6 Wochen lang immer wieder gekämpft und konfiguriert und getrackt und geloggt und recherchiert und neu konfiguriert hatte und immer wieder Mails mit einem (technisch eher unbedarften, sehr freundlichen und manchmal sogar antwortenden) Servicemitarbeiter ausgetauscht habe, hat der dann irgendwann endlich einen echten Techniker angeschrieben, der auch geantwortet hat. Juhu! Der hat dann geschrieben, das sich wohl ein paar Wochen zuvor der SBC aufgehängt hat (er meinte, vielleicht durch meine ersten Versuche mit falschen Nachrichten - meine Theorie ist ja, der hatte noch nie gelaufen) und er den mal neu konfiguriert und neu gestartet hätte. Und Zack! ab dem Moment ging's problemlos... Wenn das mal keine typische Lösung ist. Seufz!

Auf jeden Fall hat mich das so viele Nerven gekostet und ich habe so wenig Beispiele für diesen konkreten Fall gefunden und ich habe so viel Sachen dabei gelernt, das ich dann geschworen habe, das in diesem Artikel hier mal alles richtig zu erklären.