[Pascom 18] Interne IP der Telefonanlage in 'Contact' Information SIP Paket

Ah verstanden,

Okay und das Interface in der Pascom ist mit FQDN eingerichtet?
Oder ist das mit IP-Adresse eingerichtet?

Hallo Markus,

das Pascom Interface ist mit FQDN und Lets encrypt eingerichtet bzw. die Namensauflösung funktioniert auch korrekt.

Gruß Reinhard

Hm,

komisch dann sollte eigentlich der Kamailio (das Interface) die korrekte externe IP auflösen und diese in den Contact Header packen, dachte ich.

Hast Du denn Support bei Pascom?
Dann solltest Du da mal ein Ticket aufmachen oder anrufen.

Gruß Markus

Hallo Markus,

haben nur die BASIC Lizenz, deshalb meine Frage hier im Forum.

Gruß Reinhard

Hallo Reinhard,

welcher SIP-Anbieter ist das denn den du da hast?

Hallo Markus,

der Anbieter ist UPC Österreich.

Gruß Reinhard

Hallo Reinhard,

also gut und was hast du für eine Vorlage an der Anlage ausgewählt?
bzw kannst Du mal die Einstellungen im Tab Accounts posten?

Hallo Markus,

anbei die Einstellungen.
Die “Durchwahl reg.” entspricht der Rufnummer des Anschlusses.
Die Optionen entsprechen der Community Vorlage mit einem Unterschied das ich zusätzlich den registertimeout ergänzt habe entsprechend den Vorgaben von UPC.

Also versuche mal folgendes

Unter Appliance -> Systemeinstellungen eine neu Systemeinstellung hinzufügen.

sys.asterisk.configure.sip.file.externip und als Wert die externe IP von dir.

dann die Telefonie anwenden und mal nen Trace machen ob dann die richtige IP im Contact Header steht

Leider nein. Steht immer noch die 10.x.x.x Adresse drin.
Habe zusätzlich auch noch den Telefonserver neu gestartet bzw. den gesamten Server. Keine Veränderung im Verhalten.

Hallo @rinal13,

manche Provider munieren in der Tat die private IP an der Stelle, auch wenn wir die Information mit senden das die hier verwendete IP nicht gültig ist, sondern die des IP Headers (was bei den meisten Providern ja klappt).

Neben der von Markus erwähnten externip benötigst du noch ein weiteres Setting sys.asterisk.configure.sip.file.localnet mit Wert 10.0.3.0/255.255.255.0 damit der Asterisk weiß wann er die externip zu setzen hat (nämlich wenn mit Hosts/Peers außerhalb des localnet kommuniziert wird.

Was hier vielleicht etwas missverständlich ist/war, ist das die Kommunikation zum SIP Provider aktuell noch nicht über den SessionBorderController bzw InterfaceContainer abläuft sondern vom Asterisk im Telfonie Container direkt über über den pascom Host (mit SourceNAT/Masquerading) aufgebaut wird.
Bei externip ist deswegen auch die IP des pascom Hosts selbst (am primären/ersten Interface) gemeint, nicht die öffentliche WAN IP am Router (also z.B. 192.168.0.12).

Grüße,
Steve

Hallo @Steve,

mit den Einstellungen bekommen ich nun die interne IP Adresse im contact Feld korrekt.
Da aber mein Provider zwingend die öffentliche IP sehen will “muss” ich trotzdem den ALG des Firewall nutzen,
der jedoch bei der Kommunikation wie beschrieben Probleme macht.
Gibt es irgendeine Möglichkeit das die Pascom 18 trotzdem die öffentliche IP mitgibt. Dies sollte ja über dem SessionBorderController möglich sein.
Somit wäre es auch möglich den Firewall ohne ALG zu betreiben

Hi,

das sollte eigentlich das ALG des Routers dann übernehmen. Du kannst aber als externip auch die WAN IP eintragen. Wie erwähnt wird der SBC für die Ämter aktuell noch nicht verwendet.

Grüße,
Steve

Hallo Zusammen.

Ich möchte hier kurz einige Dinge klar stellen:

  • die Interface Einstellungen gelten ausschließlich für Endpunkte, nicht für Trunks
  • ein Trunk wird generell aus der Instanz heraus über das Management-Interface ge-NATed. Das Verhalten ist dann sehr ählinch wie in deiner pascom Classic.
  • Trunk Traffic wird mit “loose Routing” gerouted. Die IP Adressen in den Paketen spielen keine Rolle solange der Provider den “;lr” Parameter unterstützt und der Router ein sauberes Connection-Tracking macht.

Zu dem ALG Problem:

  • wenn das Interface auf TLS gesetzt ist, kommunizieren alle Endpunkte per SSL und Deine Firewall kann kein ALG machen (das ist gut!)
  • Dein Trunk Traffic ist nicht TLS sondern sicher TCP oder gar UDP und somit “darf” der Router ALG darauf anwenden.
  • Nun kann es sein das das Router-ALG-Modul kein “;lr” kennt und den IP Adressen im SIP Paket vertraut. Somit versanden dann Replies.

Wir werden in der kommenden 18.03 release auch ein ALG Modul für das Management Interface mitbringen. Die SIP Pakete werden dann die IP Nummern des Management Interfaces zeigen, was ggf. in Deinem Fall das Verhalten verbessert. Du hättest dann 2x ALG: Instance-zu-Host und Host-zu-Router.

Du kannst Dich beim Support melden und ggf. vorher schon testen.

Gruß,

Thomas

Hallo @Steve,

die SIP Kommunikation funktioniert erst nachdem ich noch den Parameter “autodomain = yes” gesetzt habe. Dadurch wird die extenip auch in die Liste der domains automatisch aufgenommen und somit werden auch SIP Pakete akzeptiert die von der öffentlichen IP Adresse kommen.

Trotzdem werden aber die RTP Pakete welche von der öffentlichen IP Adresse kommen nicht akzeptiert. Eine Idee was hier eventuell noch freizuschalten ist. Eventuell besteht hier eine Blockade vom Management Interface zur Asterisk Instanz?

Gruß Reinhard

Hallo Reinhard,

kommt der RTP Stream denn überhaupt am pascom Host an? Innerhalb der SIP Pakete (Invite/Progress) in dem SDP (Session Description Protokoll) wird ja die IP und der Port mitgeteilt von dem der RTP Traffic kommt bzw an den die Anlage den RTP Traffic schickt. Ich würde eher vermuten das man hier schon nichts ankommen sieht, da ggf. doch SIP ALG zwischen Host und Provider im Einsatz ist.

Dadurch wird die extenip auch in die Liste der domains automatisch aufgenommen und somit werden auch SIP Pakete akzeptiert die von der öffentlichen IP Adresse kommen.

Das verstehe ich leider nicht ganz, die externip im Asterisk sollte entweder die IP des pascom Hosts oder die WAN IP über die die Pakete der Anlage dem Provider übermittelt werden, nicht aber die IP des Providers beispielsweise.

Grüße,
Steve

Hallo Steve,

das ist natürlich korrekt, aber im SIP Paket des Providers wird die externe IP als Ziel angeben, und somit akzeptiert Asterisk, so scheint es, nur mit der autodomain Option auch SIP Pakete die an die extenip adressiert sind.

Die RTP Pakete kommen an dem Port und der IP Adresse an, welche im SDP Paket durch die Pascom definiert wurden, jedoch die Pascom antwortet mit einem IMCP Paket “Port nicht verfügbar”?!

Gruß Reinhard

Hallo Reinhard,

leider weiß ich nicht warum du autodomain=on benötigen solltest, das sollte glaube ich wenn überhaupt nur dann benötigt werden, wenn sich andere peers am Asterisk registrieren. Bei insecure=invite sollte dem asterisk die domain in in den from/to/contact Headern relativ egal sein, wichtig ist das der Call eingehend über die IP des peers oder ausgehend die Antwort der Verbindung(Source/Destiantion-Port/IP)+CallID zugeordnet werden kann.
Ich nehme an du registriert dich ja bei UPC, das heißt es gibt keine inital von UPC aufgebaute Verbindung (eingehende Calls gehen ja auch über die bestehende Verbindung nach dem Register ein).
Man müsste sich das ganze in einem Packettrace mit den Log Meldungen des Asterisk zusammen ansehen. Aus persönlicher Erfahrung kann ich jedoch nur von UPC abraten, ich würde dir eher peoplefone.at anraten.

Grüße,
Steve

Hallo Steve,

die SIP Communication ist nicht wirklich mehr die Thematik, diese funktioniert korrekt,
jedoch scheint durch die extenip Einstellung, dass die Ports für die RTP Pakete zur Asterisk Instanz nicht richtig geöffnet werden. Das Kuriose dabei ist, bei eingehende Anrufen funktioniert die Aushandlung des RTP Streams ohne Probleme.

UPC ist leider an dieser Stelle gesetzt, aus verschwenden Gründen, die Ich hier nicht weiter ausführen möchte.
Deshalb muss ich hier zu einer funktionierenden Lösung kommen.
Eventuell ist auch die Version 18.03 mit der integrierten ALG die Lösung.

Gruß Reinhard

Zusammenfassend die finale Lösung der Anbindung an den SIP Trunk von UPC Austria.

  1. Asterisk: Einstellen des SIP Trunk Ports auf 5060
  2. Aktivierung des ALG am Pascom Interface (gewährleistet die korrekte Öffnung der entspr. RTP Ports
    und die Annahme der SIP Pakete von außen)
  3. Durch den Einsatz des ALG werden die Pakete aber vom Port 1024 versendet
  4. Erstellung eines SNAT von Port 1024 auf Port 5060 für die SIP Pakete am Firewall,
    da UPC zwingend verlangt dass die SIP Pakete von Port 5060 gesendet werden