[Problem] Grandstream UCM6102 PBX 1und1 Voip registrierung

[EnerGeht]

Spannende Idee mit der Registrierung auf beiden Servern … so gedacht ist das eigentlich überhaupt nicht. Aber, wenn es geht, klasse Tipp!

Nunja, ich bin mir nicht ganz sicher ob das so gedacht ist oder nicht. Bei Business-Telefonanlagen (z.B. Cisco Callmanager) ist es bspw. durchaus üblich, dass sich die Endgeräte gleichzeitig an zwei Servern registrieren, das gehört dort zum Redundanzkonzept. Sobald einer der Server wegbricht, übernimmt der andere die SIP-Session zu dem Endgerät, das geht i.d.R. sogar ohne Auswirkungen auf das Telefonat (RTP-Traffic wird ja i.d.R. sowieso nicht zum Registrar geschickt). Natürlich setzt das voraus, dass die Server im Backend eine Synchronisation über alle offenen Sessions machen, davon würde ich bei 1und1 jetzt mal nicht ausgehen. Mir geht es aber an der Stelle ja auch nicht um Redundanz, sondern um das Firewall-Traversal ankommender Anrufe, welches durch die ausgehende Verbindung LAN-->WAN möglich wird.

Was genau ist das Problem mit den Ports: Musst Du für jede Rufnummer an beide SIP-Registrare mit dem selben Quell-Port angemeldet sein?

Ich hoffe es ist okay, wenn ich mal ganz kurz aushole und das Konzept eingehe nach dem diese "Hardware-Firewalls" funktionieren (oder "integrierten Firewalls" oder wie auch immer der Routerhersteller das bezeichnen möchte). Ich will auf keinen Fall den Oberlehrer spielen, mir geht es lediglich darum, dass wir ein gleiches Verständnis haben, vielleicht übersehe ich auch etwas oder bin völlig auf dem Holzweg und kann noch dazu lernen (was sowieso die Grundidee hinter diesem Experiment ist). Ich bitte außerdem um Verzeihung für manche flapsige oder untechnische Formulierung.

Grundidee
Hinter dem ganzen Thema Firewall steht grundsätzlich die Annahme der größte Teil des Internet sei böse und will dem Nutzer schaden. Leider braucht der Nutzer aber den Teil des Internets, der nicht böse ist für irgendwelche Dinge. Also: Alles was das Internet vom Nutzer will soll bitte nicht funktionieren, aber alles was der Nutzer vom Internet will muss gehen.
(Den Punkt, dass ein Endgerät des Nutzers böse Dinge tut, weil es kompromittiert wurde, schlechte Software enthält, von Apple/Google/Microsoft/"hier beliebigen gehassten Hersteller einsetzen" ist, betrachten wir hier nicht)

Damit haben wir eigentlich schon die grundsätzliche Kommunikationsbeziehung erklärt: Vom LAN ins WAN (= Public Internet) darf erst mal alles durch, vom WAN ins LAN bitte gar nichts.

Die Herausforderung
Nun ist es ja nicht so, dass der Nutzer ständig nur die letzten Bilder in die Wolkenwelt hochlädt (also nur Dinge ins Internet schickt), sondern i.d.R. will er sich ja auch über das Wetter informieren, muss also Dinge (Filme, Fotos, Webseiten etc. pp.) doch aus dem Internet ins LAN herunterladen. Das Problem ist wir sagten zuvor: WAN nach LAN is nich!

Die Lösung
Hier kommt nun die "stateful" Firewall ins Spiel: Diese erkennt, dass der User eine Anforderung ans Internet gestellt hat (LAN nach WAN), nehmen wir der Einfachheit mal an, es wäre ein simpler http-Aufruf (Zielport 80) auf meinetwegen 172.217.16.131 (google.de). Die Firewall merkt sich nun in ihrer Session Table diesen Aufruf

Quelle	Quellport	Ziel	Zielport
PC im LAN (192.168.1.15)	40789	(google.de) 172.217.16.131	80

Für die Antwort wird die Kommunikationsbeziehung dann einmal umgedreht, heißt:

Quelle	Quellport	Ziel	Zielport
(google.de) 172.217.16.131	80	PC im LAN (192.168.1.15)	40789

Die Firewall ist nun in der Lage, diese eingehende "Anfrage" (=Antwort) dem ursprünglichen Aufruf zuzuordnen und lässt diesen Zugriff zu, da er ja der Grundidee (LAN-->WAN) entspricht und eine Antwort aus dem Internet (WAN-->LAN) angefordert wurde.

Mit diesem Hintergrund wird die Herausforderung bei SIP wohl recht plakativ: Eingehende Anrufe kommen konzeptbedingt immer aus "dem bösen Internet" (WAN-->LAN) und sind damit erst einmal "verboten". Daher war meine Idee: Wenn sich der SIP-Client an beiden 1und1-IP-Adressen gleichzeitig registriert, dann kennt die Firewall diese gewollte Kommunikation und lässt eingehende Anrufe zu.
Dazu müssten aber zur Kommunikation mit beiden 1und1-Servern immer dieselben Ports verwendet werden, denn 1und1 schickt die SIP-Pakete für die jeweilige Rufnummer immer an den Port der als Quellport zur Registrierung verwendet wurde, die Quell-IP von 1und1 aber mehr oder weniger zufällig aus den beiden ausgewählt wird.

Das Grandstream verhält sich nun leider aber so:
SIP-Account 1 --> Quellport 5060
SIP-Account 2 --> Quellport 5062
SIP-Account 3 --> Quellport 5064
SIP-Account 4 --> Quellport 5066
usw.

D.h. ich kann niemals zwei unterschiedliche Registrare mit demselben Quellport ansprechen. SIP-Account 1 würde für sein Ziel (z.B. 1und1-Server 1) den Quellport 5060 nutzen, eingehende Anrufe von 1und1-Server 2 sind aber über 5060 nicht möglich, da SIP-Account 2 (selbe Rufnummer, anderer Registrar) den Quellport 5062 nutzt. Technisch wäre das machbar, aber die Implementierung von Grandstream verhindert dies leider. Ich postuliere: Es wäre sogar denkbar, dass mehrere Rufnummern beim selben Registrar über denselben Port registriert werden, denn die Unterscheidung für welche Rufnummer der eingehende Anruf erfolgt nicht auf IP-Ebene (Layer 3), sondern wird im SIP-Header übertragen.

Ich bin gespannt auf eure ehrliche Meinung zu meinen Ausführungen! Wie bereits erwähnt: Vielleicht bin ich auch völlig auf dem Holzweg und sollte überlegen, mich von Computern besser fernzuhalten

 

[sonyKatze]

Ahh. Du meinst, dass die eingehenden SIP-INVITE sich trotz der zwei Registrierungen nicht an die Quell-Ports halten. Das beutetet, dass Server 1 auch mal mit Quell-Port für Server 2 aufschlägt. Das wird dann von der Firewall verworfen, weil die nur Doppel-Tupel aus Entfernt(IP:Port):Lokal(IP:Port) bildet. Puh. Daher möchtest Du nur einen UDP-Port für beide UDP-Verbindungen aufmachen = die Verbindungen werden dann nicht bereits auf der Ebene UDP sondern erst auf der Ebene SIP zugeordnet, also eine Art SIP-Multiplexing. Puh. Ob das geht? Meine Tipps:
a) anderen VoIP/SIP-Provider holen (kenne Keinen außer 1&1 die das „so“ machen), oder
b) andere Firewall holen (oder dort die beiden IPs/Ports statisch erlauben/mappen), oder
c) probier mal in Grandstream → Account → SIP → Basic → Local SIP Port beide auf 5060 zu setzen und unter General → Settings → Use Random Port auszuschalten.
Ob Letzteres überhaupt geht, habe ich noch nicht probiert. Die Web-Oberfläche schluckt es, aber es ob im Hintergrund dann auch so tut … Wenn das nicht klappt, würde ich an Deiner Stelle einen neuen Thread aufmachen und genau das fragen, also wie man 1&1 eingehend irgendwie in den Griff bekommt und/oder ob irgendein SIP-Client überhaupt so ein SIP-Multiplexing kann. Edit: Hast Du bereits getan …

ich bin mir nicht ganz sicher ob das so gedacht ist oder nicht

1&1 macht eine nicht-transparente Lastverteilung (Load Balancing). Die Idee dahinter ist, dass kein Server überlastet wird. Denen geht es nicht um Redundanz für Dich sondern für Die. Daher ist der Ansatz sich gleich zweimal zu registrieren das komplette Gegenteil von dem was sich 1&1 dabei gedacht hat. Die Ausfallsicherheit, die Du mit Redundanz ansprichst (Fail Over), erfolgt normalerweise erst bei Neu-Registrierung. Also wenn ein Server sich tot stellt, dann wird eine neue Regsitrierung zu dem anderen Server aufgebaut. Dass man zwei Registrierungen gleichzeitig zu einem VoIP/SIP-Anbieter am Leben erhält, habe jedenfalls ich bisher noch bei keiner Installation gesehen. Ist aber auch egal. Deine Idee war spitze! Klappt nur nicht, weil 1&1 sich auch noch nicht an den Quell-Port hält.

 

[EnerGeht]

Ahh. Du meinst, dass die eingehenden SIP-INVITE sich trotz der zwei Registrierungen nicht an die Quell-Ports halten. Das beutetet, dass Server 1 auch mal mit Quell-Port für Server 2 aufschlägt. Das wird dann von der Firewall verworfen, weil die nur Doppel-Tupel aus Entfernt(IP:Port):Lokal(IP:Port) bildet.

Absolut korrekt wiedergegeben, das entspricht meiner Analyse

Puh. Daher möchtest Du nur einen UDP-Port für beide UDP-Verbindungen aufmachen = die Verbindungen werden dann nicht bereits auf der Ebene UDP sondern erst auf der Ebene SIP zugeordnet, also eine Art SIP-Multiplexing. Puh. Ob das geht?

Nunja... generell besteht die Möglichkeit ja schon, je Ziel-IP denselben Quellport zu verwenden, da wie von dir erwähnt erstmal das Tupel (respektive Doppel-Tupel) ausschlaggebend ist. Mir wäre das sogar ziemlich wurscht, wenn das Grandstream dann wiederum für jeden SIP-Account mit demselben Profil einen weiteren Port aufmacht (also quasi Profil1 - Account 1: 5060, Profil 1 - Account 2: 5062, Profil 2 - Account 1: 5060, Profil 2 - Account 2: 5062). Wichtig wäre an der Stelle: Die Firewall muss ausgehende Anfragen an beide Registrare:5060 mit jeweils denselben Quellports sehen, damit es funktioniert. Von welchem SIP-Account ist dem Ding dann ja schlussendlich wieder ziemlich wurscht! Da es UDP ist, besteht ja sowieso grundsätzlich keine Session und die Verbindung wird nur auf der Firewall "zusammengereimt" (der Timeout sind hier glaub 60s oder sogar weniger).

Ich weiß, dass meine Ideen schon eher aus der Kategorie "Verarsch die Firewall" und auch nicht wirklich schön sind. Ich finds trotzdem noch besser als Port-Forwarding, das möchte ich aktuell so gut es geht vermeiden.

Meine Tipps:
a) anderen VoIP/SIP-Provider holen (kenne Keinen außer 1&1 die das „so“ machen), oder
b) andere Firewall holen (oder dort die beiden IPs/Ports statisch erlauben/mappen), oder
c) probier mal in Grandstream → Account → SIP → Basic → Local SIP Port beide auf 5060 zu setzen und unter General → Settings → Use Random Port auszuschalten.
Ob Letzteres überhaupt geht, habe ich noch nicht probiert. Die Web-Oberfläche schluckt es, aber es ob im Hintergrund dann auch so tut …

Danke für deine Tipps, auch hier schätze ich den Austausch sehr. Daher meine Gedanken dazu:
a) Hm, ich hab fünf Rufnummern bei meinem DSL-Vertrag "gratis" mit dabei oder anders gesagt: Ich hab noch keinen Vertrag gefunden bei dem die Telefonie nicht mit dabei ist. Andere Accounts würden zusätzlich monatlich Geld kosten, aktuell bin ich nicht gewillt das Geld für mein "Jugend-forscht"-Projekt auszugeben. Mir gefällt daran der Bastelfaktor und das Verstehen der Mechanik
b) Da sollte ich mich wirklich mal weiterentwickeln. Ums mal weniger diffus zu machen: Aktuell ist die Firewall ein OpenWrt-Router, sprich iptables. Das funzt recht gut und bietet mir an der Stelle die Chance sich auch mit iptables mal intensiv zu befassen (bin aber ehrlich gesagt noch nicht über die LuCi-GUI raus )
b.2) Ja, ein manuelles/statisches Mapping hatte ich auch schon im Sinn, aber ich bin immer noch kein Fan von Portforwarding, weil ich aktuell nicht glaube das Know-How zu besitzen dies möglichst risikoarm umsetzen zu können.
c) Gute Idee und das hat ursprünglich auch funktioniert! In beiden Accounts (SIP-Registrar 1 und SIP-Registrar 2) habe ich die entsprechenden Ports eingetragen und zufällige Ports deaktiviert. Dann war das Verhalten genau wie ich es ursprünglich beschrieben habe (Profil1 - Account 1: 5060, Profil 1 - Account 2: 5062, Profil 2 - Account 1: 5060, Profil 2 - Account 2: 5062 etc.), bis nach einem Sonnensturm, Neumond, kosmischem Strahlungsausbruch oder was auch immer... auf einmal verhält sich das nicht mehr so und zählt die Ports fortlaufend hoch.

1&1 macht eine nicht-transparente Lastverteilung (Load Balancing). Die Idee dahinter ist, dass kein Server überlastet wird. Denen geht es nicht um Redundanz für Dich sondern für Die. Daher ist der Ansatz sich gleich zweimal zu registrieren das komplette Gegenteil von dem was sich 1&1 dabei gedacht hat. Die Ausfallsicherheit, die Du mit Redundanz ansprichst (Fail Over), erfolgt normalerweise erst bei Neu-Registrierung. Also wenn ein Server sich tot stellt, dann wird eine neue Regsitrierung zu dem anderen Server aufgebaut.

Das sehe ich genauso, man muss sich vor Augen halten, dass 1und1 immer noch Enduser (hauptsächlich Privatkunden und kleine Businesskunden) mit dieser Lösung bedient und da ist ein abgebrochenes Gespräch bei Ausfall eines Registrars sicherlich verschmerzbar, insofern ist denen "meine" Redundanz sicherlich völlig wumpe.
In einem Punkt habe ich aber eine etwas abweichende Meinung: 1und1 kann meinem SIP-Client nicht vorschreiben bei welcher der beiden SIP-IPs (oder eben sogar bei beiden) er sich registrieren soll, insofern zieht deren Load Balancing nur für Anrufe von deren Server zu meinem Client - und das ist ja genau was ich sehe: Die Anrufe kommen mal von der .130 und mal von der .129.

Dass man zwei Registrierungen gleichzeitig zu einem VoIP/SIP-Anbieter am Leben erhält, habe jedenfalls ich bisher noch bei keiner Installation gesehen. Ist aber auch egal.

Wie bereits geschrieben: Ich kenne das aus professionellen Umgebungen so, allerdings sind das immer SIP-Clients an einer internen SIP-Telefonanlage. Ob das auch für Provider zutrifft, mag ich bezweifeln, weil hier in der Regel SIP-Trunks gebaut werden, was doch nochmal ein mittelgroßer Unterschied ist.

Deine Idee war spitze! Klappt nur nicht, weil 1&1 sich auch noch nicht an den Quell-Port hält.

Danke für die Blumen Ich möchte aber nochmals erwähnen, dass ich da nicht ganz von alleine drauf gekommen bin, weil ich das Verhalten bei meinen Tests mit der Yealink SIP-DECT-Lösung bereits so gesehen habe und bei dem Grandstream einfach auch gerne genutzt hätte. Wi(n)tziges Detail am Rande: 1und1 hält sich an den Quellport den sie bei der Registrierung gelernt haben, aber nicht an den Quellserver!

 

[sonyKatze]

1&1 kann meinem SIP-Client nicht vorschreiben bei welcher der beiden SIP-IPs (oder eben sogar bei beiden) er sich registrieren soll …

Ja, das geht nicht. Aber deren ist Idee ist es nicht es vorzuschreiben sondern die bestehenden Implementierungen auszunutzen. Habe ich das auch richtig in Erinnerung, dass bei 1&1 immer die letzte Registrierung gewinnt, also man gar nicht mehrfach angemeldet sein kann? Puh, müsste ich jetzt nochmals prüfen … kannst Du mal schnell schauen?

Aber wie der Zufall will, flatterte am Samstag ein Grandstream GRP in mein Haus – und dort wird diese Strategie mit zwei Registrierungen gleichzeitig bei selbem VoIP/SIP-Provider (aber jeweils anderer IP-Adresse) in der Dokumentation explizit beschrieben … sowas habe ich bei „normalen“ VoIP/SIP-Telefonen bisher nicht (oder über-) sehen. Auch geht das mit unserem DP75x nicht – jedenfalls sehe ich den Menüpunkt nicht.

 

[KunterBunter]

Habe ich das auch richtig in Erinnerung, dass bei 1&1 immer die letzte Registrierung gewinnt, also man gar nicht mehrfach angemeldet sein kann?

Mehrfachregistrierung geht schon bei 1&1 für gehende Anrufe, ankommende Anrufe werden dagegen nur an der letzten Registrierung signalisiert.

 

[EnerGeht]

Ja, das geht nicht. Aber deren ist Idee ist es nicht es vorzuschreiben sondern die bestehenden Implementierungen auszunutzen.

Auch da sind wir uns einig. Ich denke aber dennoch, dass die meisten Implementierungen stupide die erste IP-Adresse der DNS-Anfrage verwenden werden und die wenigsten Comsumer-SIP-Geräte tatsächlich SRV-Records abfragen. Aber kann natürlich sein, dass ich mich hier irre...

Aber wie der Zufall will, flatterte am Samstag ein Grandstream GRP in mein Haus – und dort wird diese Strategie mit zwei Registrierungen gleichzeitig bei selbem VoIP/SIP-Provider (aber jeweils anderer IP-Adresse) in der Dokumentation explizit beschrieben … sowas habe ich bei „normalen“ VoIP/SIP-Telefonen bisher nicht (oder über-) sehen. Auch geht das mit unserem DP75x nicht – jedenfalls sehe ich den Menüpunkt nicht.

Das ist mal ein Zufall, aber cool, dass du die doppelte Registrierung jetzt auch mal als "Feature" gesehen hast Schade, dass das bei Grandstream derart vom Endgerät abhängig ist... vermutlich werden die Firmwares von unterschiedlichen Teams entwickelt, bei deinem Telefon ist ja sogar die Weboberfläche anders designed... Hast du ne Idee, wie man das als Feature-Request für die DP750er Serie vorschlagen kann? Ich habe gelesen, dass deren Support nicht unbedingt so toll sein soll.

-- Zusammenführung Doppelpost gemäß Boardregeln by stoney

Unnötiges Vollzitat von darüber gemäß Boardregeln entfernt by stoney

Bist du dir sicher? Ich meine mich zu erinnern, dass es wäre möglich dieselbe Rufnummer mehrfach zu registrieren und dann auch auf allen Rufnummern eingehende Anrufe signalisiert werden. Ich werds die Tage mal via Fritzbox und parallel im Mobilfunknetz mit nem SIP-Client ausprobieren.

 

[koyaanisqatsi]

Moinsen


SIP Protokolle der REGISTER/INVITE dürften auch spannend sein.
Achte in einer REGISTER Antwort von 1&1 auf die Reihenfolge und unterschiedlichen IPs in Contact:
...bis zu Drei, ab dann: To many Contacts
...oder so ähnlich.

 

[EnerGeht]

Unnötiges Vollzitat von darüber gemäß Boardregeln entfernt by stoney

Ich werde das in der nächsten Spielrunde mal genauer ansehen, du hast mich neugierig gemacht!

 

[sonyKatze]

Die Web-Oberfläche der DP75x- oder der GRP-Serie sind jetzt nicht so unterschiedlich. Allerdings verhalten sich diese beiden Modell-Serien schon ein wenig anders; wobei das auf mich eher nach Weiterentwicklung wirkt. Die eine Serie ist aus dem Jahr 2019, die andere aus dem Jahr 2016. Du kannst über das Grandstream Ticket-System Deinen Verbesserungsvorschlag machen. Allerdings kannte der Support bei mir nur drei Dinge: Immer weitere Informationen anfordern, Problem verzetteln und einen Niedermachen. Ich bin Grandstream auf eine Messe hinterher geflogen, habe gewartet bis der Product-Manager am Messestand auftauchte, meine Tickets ausgedruckt in die Hand gedrückt … und wenige Monate später war fast alles repariert.

Allerdings wärst Du besser beraten, denen diesen Trick mit „Keep-Alive an alle aufgelösten IP-Adressen“ zu erzählen. Denn das löst Dein Problem. 1&1 (oder war es doch wer anderes?) erlaubt keine mehrfachen Registrierungen; immer nur die letzte zählt.

die wenigsten Comsumer-SIP-Geräte tatsächlich SRV-Records abfragen

DNS-SRV?
Bei 1&1 machst Du normalerweise DNS-A auf sip.1und1.de. Dort sind bereits beide IP-Adressen hinterlegt. Wenn Du ein Cleverchen bist, dann machst Du natürlich DNS-SRV auf 1und1.de, also _sip._udp.1und1.de. Auch dann bekommst Du am Ende zwei IP-Adressen. Hier bei mir rotieren die Ergebnisse. So erhält man eine Lastverteilung, egal wie die IP-Adresse aufgelöst wurde. Nebenbei: Jeder, wirklich jeder SIP-Client kann inzwischen DNS-SRV. Auch weil ein paar VoIP/SIP-Anbieter offiziell gar nicht anders erreichbar wären. Ja, gibt tatsächlich noch Telefon-Hersteller, die den Schuss noch nicht gehört haben und kein DNS-SRV bieten. Aber die kann ich inzwischen an einem Finger abzählen.

 

[EnerGeht]

@sonyKatze Darf ich fragen, was dein Antrieb ist, dem Product-Manager aufzulauern? Ist das noch privat getrieben oder bist du beruflich auf Messen unterwegs? Bitte nicht falsch verstehen - ich bewundere deinen Idealismus, aber bislang hatte ich bei derlei Anforderungen nicht das Durchhaltevermögen derart konsequent auf den Hersteller einzuwirken um einen - absolut gerechtfertigten - Erfolg zu erreichen.
Du hast tatsächlich recht mit DNS-Round-Robin, ich hatte bislang jedes Mal die gleiche Antwort, wenn ich sip.1und1.de abgefragt habe, aber gerade eben habe ich zum ersten Mal die round gerobbte Antwort bekommen.

 

[sonyKatze]

Mehrfachregistrierung geht schon bei 1&1 für gehende Anrufe, ankommende Anrufe werden dagegen nur an der letzten Registrierung signalisiert.

Aufgrund der Formulierung habe ich mir das mal selbst angeschaut. Zwei Grundlagen:

1. Bei abgehenden Telefonaten schicke ich ein SIP-INVITE an 1&1. Dies will 1&1 authentifiziert haben (49 OKNZ Rufnummer = Benutzername + Passwort), sonst könnte ja jeder auf meine Rechnung telefonieren. Hierbei findet keine Registrierung sondern lediglich eine Authentifizierung statt. Theoretisch könnte ich so beliebig viele Anrufe starten – von beliebig vielen Telefonen, von beliebig vielen Plätzen auf der Welt. Aber 1&1 hat hier Beschränkungen. Welche das sind, habe ich jetzt nicht auf dem Schirm, war auch nicht die Frage.

2. Für ankommende Telefonate schicke ich ein SIP-REGISTER an 1&1. Dies will 1&1 authentifiziert haben (49 OKNZ Rufnummer = Benutzername + Passwort), sonst könnte jeder meine Rufnummer kapern. Das nennt sich Registrierung. 1&1 schickt dann an diese Registrierung die eingenden Anrufe, wieder als INVITE, aber diesmal von 1&1 aus. Um dieses Verhalten geht es hier:

1&1 antwortet:
SIP/2.0 403 Nicht unterstuetzte IP im Contact-Header

Wenn ich mich registriere, dann achtet 1&1 auf den SIP-Header Contact. 1&1 verlangt dort eine öffentlich erreichbare IP-Adresse. SIP-Clients hinter dem NAT – innerhalb Deines Heimnetzes – kennen diese öffentliche Adresse nur dann automatisch, wenn sie über IPv6 angebunden sind. Bei IPv4 sind Hilfsmittel nötig, zum Beispiel:
a) STUN oder
b) Header Via Parameter received und rport (RFC 3581) aus der Antwort auf das erste, falsche REGISTER
Ist die IP-Adresse im Contact endlich eine Öffentliche, erlaubt 1&1 die Registrierung. Yuppi. Aber 1&1 nutzt aus diesem Header nicht nur die IP-Adresse sondern auch den Port. Manche SIP-Clients schicken hier einen falschen Port (immer 5060, 3478 oder so ähnlich statt dem Tatsächlichen). Wenn ein Anruf rein kommt, dann schickt 1&1 an die IP-Adresse und Port aus meinem Header Contact aus meinem Befehl REGISTER. Nebenbei: So ein REGISTER hat in der Welt von 1&1 immer eine Gültigkeit (Parameter expires) von genau zwei Sunden = 7200 Sekunden.

1&1 antwortet:
SIP/2.0 403 Contact User und Anrufernummer verschieden

Außerdem verlangt 1&1, dass im User-Part der URI Deine Rufnummer im Format „49 OKNZ Rufnummer“ steht. In Digium Asterisk ersetzt Du die Extension „s“ mit der Rufnummer. In manch anderen SIP-Client wie der von Nokia Symbian/S60, geht das nicht. Solche Client sind dann inkompatibel.

1&1 antwortet:
SIP/2.0 503 Service Unavailable
…
P-Registrar-Error: Too many registered contacts

Jene Fehlermeldung erschien mir, beim Versuch einer fünften Registrierung. Was passiert bei solchen Mehrfach-Registrierungen:
a) Wird die letzte Registrierung angerufen?
b) Werden alle noch gültigen Registrierungen angerufen?

Nach meinen Tests weder noch. 1&1 nutzt Load-Balancing teils transparent, teils nicht-transparent. Wenn ich den SIP-Registrar von 1&1 über DNS auflöse erhalte ich aktuell zwei IP-Adressen. Ein ankommendes Telefonat kann von beiden IP-Adressen stammen. Wie das die AVM FRITZ!Box im Modus IP-Client bzw. die Gigaset GO-Box 100 gelöst haben, ohne dass man extra ein Port-Forwarding einrichten muss, hat unser User EnerGeht bereits analysiert. Das behandelt die Situation einer Registrierung.

Hat man mehrere gültige Registrierungen, dann kommt es darauf an auf welchem Server der Anruf bei 1&1 intern aufschlug. Und die IP-Adresse:Port wird dann angerufen. Beispiel: Ich hatte mich über die erste IP-Adresse 212.227.124.129 dreimal registriert. In der Antwort seitens 1&1 sehe ich am Ende aber nur zwei aktive Contacts. Meine erstes REGISTER war auf einem anderen internen (für mich unsichtbaren) Server gelandet. Jetzt ruft mich wer an. Zwei INVITEs erreichen mich von der zweiten IP-Adresse 212.227.124.130. Erneut ruft mich wer an. Ein INVITE erreicht mich von der 212.227.124.130.

Folglich werden die noch gültigen Registrierungen auf dem jeweiligen Server bei 1&1 kontaktiert, auf dem der Anruf aufschlug. Weil ich nicht sehe bzw. kontrollieren kann auf welchen Server (intern bei 1&1) meine Registrierung landet, ist es Zufall auf welcher IP-Adresse:Port der Anruf aufschlägt. Folglich macht man sich bei einer Mehrfach-Registrierung für zwei Stunden den Anschluss kaputt, weil es Zufall ist, auf welcher IP-Adresse:Port das INVITE aufschlägt.

Folglich gleicht 1&1 neue Registrierungen nicht über alle seine Server hinweg ab. Aber vermutlich – anders kann ich es mir nicht vorstellen – löscht 1&1 über alle Server hinweg. Beispiel: Ich hatte auf einem Server drei Registrierungen geschafft. Eine Registrierung lag auf einem anderen Server. Nach der Löschung einer Registrierung war alle Registrierungen auch dem anderen Server bekannt.

Lange Rede, kurzer Sinn:
Erreichbarkeit bei 1&1 mit einem handelsüblichen VoIP/SIP-Client ist schwer. Wenn man das Wagnis eingehen will, bleibt einem quasi nichts anderes übrig, als eine Port-Freigabe für diesen Client einzurichten. Daher (auch) mein Tipp: Solche VoIP/SIP-Clients lieber in einer FRITZ!Box anmelden, und dann die FRITZ!Box bei 1&1 anmelden.

 

[sonyKatze]

Nachtrag … wer meine Beobachtungen widerlegen bzw. nachvollziehen will: Mittels dem SIP-Tester SIPp habe ich drei Szenarien gebastelt:

1. Remove All Bindings bzw. Cancellation of Registration
   dadurch kannst Du Deine Rufnummer selbst wieder freischalten und musst keine zwei Stunden bzw. 7200 Sekunden warten.
2. Fetching Bindings bzw. Request for Current Contact List bzw. REGISTER-Fetch
   dadurch listest Du alle Deine bestehenden Registrierungen auf; zu welcher IP-Adresse, Port und wie lange gültig.
3. Adding Bindings bzw. Successful New Registration
   dadurch kannst Du Deinen Anschluss lahm legen oder zusammen mit diesem Skript testen, was Deine Firewall so macht.

Du brauchst ein relativ aktuelles SIPp. Wenn Du SIPp nicht selbst bauen sondern das fertige Package Deiner Distribution nehmen willst, bedeutet das z.B. mindestens Debian 10 (Buster) bzw. mindestens Ubuntu 20.04 LTS. Aufgerufen werden die Szenarien durch:
sipp sip.1und1.de -m 1 -sf "./bindings-remove-all.txt" -s "49 + Ortsvorwahl + Rufnummer" -ap "Dein Passwort"
genau wie 1&1 das erklärt. Wer IPv4 verwenden will/muss … keine Ahnung siehe nächsten Post

Weil Du die XML-Dateien mit jedem Text-Editor anpassen kannst, siehst Du so (in der App Wireshark) direkt Deine Veränderungen. Zum Beispiel mit dem Text-Editor jEdit → Menüleiste → Plugins → Manager → (Reiter) Install → JTidy → (Taste) Install. Benenne die TXT-Dateien zurück in XML (in kann hier nur TXT hochladen). Danach legst Du die Datei sipp.dtd ins selbe Verzeichnis wie die XML-Dateien. Voilà!

 

[sonyKatze]

Wer IPv4 verwenden will/muss …

Aus gegebenen Anlass, habe ich die XML-Dateien für IPv4 erweitert. Beim Unilateral-Self-Address-Fixing (UNSAF) habe ich mich für das vergleichsweise neue – 18 Jahre alte – rPort entschieden. Dadurch funktionieren diese XML-Dateien hier in diesem Post sowohl in IPv4 als auch IPv6 – ohne etwas ändern zu müssen. Obwohl rPort nur für UDP erlaubt ist, wird es nach meinen Tests auch bei vielen (allen?) TCP-Verbindungen stillschweigend akzeptiert. Und obwohl ich fast keinen SIP User-Agent kenne, der Dank rPort auch den SIP-Header Contact umschreibt, sind meine Tests ganz gut verlaufen. Viel Spaß damit!