Ich habe folgende Problematik entdeckt, die aus meiner Sicht nicht korrekt ist.
Die SIP Pakete die durch den Session Border Controller verschickt werden, haben im Contact die interne IP Adresse der Telefonanlage wie . z.B. 10.0.3.117 und nicht die Adresse der Schnittstelle zum Netzwerk wie z.B. 192.168.0.12.
Soll dass so sein?! Aus meiner Sicht nicht korrekt. Ich habe auch dass Gefühl das dass der Grund ist wieso mein Firewall Probleme mit eingehenderen SIP Paketen macht. Weil er sich denkt eine Netzwerk mit 10.0.3.117 habe ich nicht und somit leite ich das Paket nicht weiter.
Firewall ist ein Fortigate, mit SIP-ALG aktiv / SIP-Helper deaktiviert.
Das aktuelle Problem ist das eigehende SIP Pakete (nur BYE und INVITE) nicht weitergegeben werden.
Der Rest (Rufaufbau, Anruf) funktioniert tadellos. Ein entsprechender SupportCase ist auch bei Fortinet schon offen.
Das Thema ist ich brauche den SIP-ALG um den SIP Contact auf die öffentliche IP umzuschreiben, da der SIP Provider nur den SIP Contact in folgender Form akzeptiert. “Rufnummer:PublicIP@5060”. Mit einem reinen Routing funktioniert das nicht. Oder ich kriege den SIP Contact gleich korrekt aus der Pascom mit der öffentlichen IP. Dann würde es auch ohne SIP-ALG gehen. Was ja eben leider nicht der Fall ist.
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.
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.
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).
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
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.
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.
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?
