[Problem] Telefone nach einigen Stunden/Tagen nicht mehr von außen erreichbar

[schneckenpost]

Hallo Forum,

ich habe ein Problem mit meinem VoIP-Setup: Hier läuft lokal ein Linux-Router, der für das LAN NAT macht. Provider fürs Internet ist KabelBW, für VoIP bin ich bei PersonalVoip registriert.

Im LAN hatte ich ein Paar Grandstream GXP-2020 und GXP-2000 laufen. Die sind mittlerweile alle ausgemustert und stattdessen setze ich ein Android Softphone (CSipSimple) ein. Alle Telefone zeigten und zeigen noch dasselbe Fehlerbild: Telefonieren geht zunächst einwandfrei, aus- und eingehende Anrufe funktionieren prima.

Aber nach ein Paar Stunden, manchmal erst nach Tagen, ist die Verbindung von extern nicht mehr erreichbar. Personal-VoIP registriert mir dann einen Fehlercode 500 für den eingegangenen Anruf und ich bekomme es gar nicht mit (klingelt nicht). Wenn ich dann die App neu starte oder die Verbindung aus- und anschalte, geht es auch von extern wieder. Bin mir ziemlich sicher, dass es nicht an der App liegt, weil wiegesagt die Grandstream Telefone exakt dasselbe Fehlerbild zeigten (nach einem Neustart waren die dann auch wieder erreichbar).

Das Problem ist, dass ich keinerei Indikation habe, wann mein Telefon die Verbindung "verliert" und es sich auch extrem schlecht debuggen lässt, weil ich nicht weiß, wie ich den Fehler provozieren kann und weshalb der überhaupt auftritt.

Falls es was hilft, hier sind ein Paar Eckpunkte die ich in der Konfiguration angegeben habe (ich habe meine Kundennummer immer durch 123456 ersetzt):
Konto-ID: <sip:[email protected]>
URL Registrierung: sipersonal-voip.de
Realm: *
Benutzername: 123456
Datentyp: Klartextpasswort
Protokoll erzwingen: UDP
Standard-URI-Schema: sip
Verwende IPv6: Nein
Publish enabled: Nein
Register Timeout: 240 sec
Erlaube Contact-Rewrite: Nein
Erlaube Via-Rewrite: Nein
Versuche, die Register zu löschen: Ja
Proxy: sip:sip.personal-voip.de
SRTP-Modus: Standard
STUN for SIP: Standard
STUN Server: stun.personal-voip.de

Ich glaube nicht dass es an PersonalVoip liegt, hatte vorher Sipgate (mit den Grandstream Phones) und da war exakt dasselbe Problem vorhanden.

Hat irgendjemand eine Idee, wie ich das so hinkriege, dass es konsistent funktioniert? Ich bin für jeden Tipp dankbar, bin super verzweifelt :-(

Vielen Dank und viele Grüße,
Theo

 

[koyaanisqatsi]

Abend

Idee!

Das...
Verwende IPv6: Nein
...hat mich zu der Überlegung geführt,
dass deine öffentliche IPv4 sich ändert, oder nicht mehr gültig ist.
Kann, glaub ich, passieren bei DS-Lite (IPv6 mit Tunnel).

 

[andiling]

Das passiert bei Inaktivität. Und die Geräte werden es nicht spannen, weil sich wohl die CNAT Adresse nicht ändert.

Versuch es mal neben register timeout noch mit keep alive (evtl. musst Du auch noch partial wakelock aktivieren).

 

[schneckenpost]

Abend
Das...
Verwende IPv6: Nein
...hat mich zu der Überlegung geführt,
dass deine öffentliche IPv4 sich ändert, oder nicht mehr gültig ist.
Kann, glaub ich, passieren bei DS-Lite (IPv6 mit Tunnel).

Hmmmm, halte ich aber irgendwie für nicht so plausibel. Mein Kabelmodem gibt meinem Router per DHCP eine Adresse, und zwar ausschließlich eine (öffentliche) IPv4 Adresse. Ich kann also gar nicht IPv6 nach außen routen :-(

Das passiert bei Inaktivität. Und die Geräte werden es nicht spannen, weil sich wohl die CNAT Adresse nicht ändert.

Versuch es mal neben register timeout noch mit keep alive (evtl. musst Du auch noch partial wakelock aktivieren).

DNAT und SNAT kenne ich, CNAT sagt mir jetzt gerade nichts. Ich habe gerade in der CSipSimple App geschaut, da sind tatsächlich Keepalive-Intervalle definiert. Für UDP im WLAN ist das auf 80 Sekunden eingestellt, für TCP+WLAN auf 180 Sekunden, TLS+WLAN (sollte nicht genutzt werden) auf 180 Sekunden.

Allerdings habe ich gerade mal den tcpdump angeworfen und ich sehe da keine Keepalives. Muss ich die noch irgendwo extra aktivieren?

Alle 30 Sekunden sehe ich aller allerdings

23:06:07.716767 IP (tos 0x0, ttl 51, id 1757, offset 0, flags [DF], proto UDP (17), length 32)
    #.#.#.#.5060 > 192.168.2.7.55103: [udp sum ok] SIP, length: 4
	\0x00\0x00\0x00[|sip]

Also auf dem Sprachkanal irgendeine Art Keepalive, aber serverseitig geschickt. Der Sprachkanal scheint aber ja auch nicht der problematische zu sein, weil ja schon die Signalisierung schief geht (klingelt gar nicht).

Vielleicht muss ich echt in den sauren Apfel beißen und mal ein Paar Wochen loggen. Problematisch ist halt immer rauszufinden, ob das Problem gerade auftritt oder nicht :-(

Viele Grüße,
Theo

 

[PeterPawn]

Also auf dem Sprachkanal irgendeine Art Keepalive, aber serverseitig geschickt. Der Sprachkanal scheint aber ja auch nicht der problematische zu sein, weil ja schon die Signalisierung schief geht (klingelt gar nicht).

Wie kommst Du darauf, daß das SIP-Paket etwas mit dem Sprachkanal (ich nehme mal an, Du meinst die RTP-Verbindung) zu tun hat ?

Ich denke mal, die Suche nach speziellen Keepalive-Paketen ist zum Scheitern verurteilt. I.d.R. wird bei SIP ein OPTIONS-Request (manchmal auch ein weiteres REGISTER) als Keepalive verwendet, was erstens die NAT-Verbindungen offenhalten kann und zweitens bei einer Antwort die Frage nach dem Gegenüber und seinem Gesundheitszustand auch hinreichend klären kann.

Allerdings bin ich mir irgendwie sicher, daß das zitierte Paket eine Antwort des Servers ist und Du irgendwie nur die Hälfte des Traffics geloggt hast (oder es hier bei der Anzeige unterschlägst), denn eine Server-Antwort ohne Frage des Clients ist schon eher ungewöhnlich.

 

[andiling]

Ändert sich denn die öffentliche IPv4?

 

[schneckenpost]

Wie kommst Du darauf, daß das SIP-Paket etwas mit dem Sprachkanal (ich nehme mal an, Du meinst die RTP-Verbindung) zu tun hat ?

Du hast Recht, ich habe das völlig durcheinandergeworfen. Bitte ignorieren, klar, SIP ist ja das Signalisierungsprotokoll.

Ich denke mal, die Suche nach speziellen Keepalive-Paketen ist zum Scheitern verurteilt. I.d.R. wird bei SIP ein OPTIONS-Request (manchmal auch ein weiteres REGISTER) als Keepalive verwendet, was erstens die NAT-Verbindungen offenhalten kann und zweitens bei einer Antwort die Frage nach dem Gegenüber und seinem Gesundheitszustand auch hinreichend klären kann.

Hm, okay. Also ich habe jetzt mal die Nacht geloggt. Ich sehe in unregelmäßigen Abständen sowohl REGISTER als auch SUBSCRIBE. SUBSCRIBE teiilweise 240, manchmal 280, meistens 300 Sekunden. Jedes zweite oder dritte SUBSCRIBE hat vorher zwei REGISTER (das erste wird mit 401 beantwortet, das zweite mit 200).

Alle SUBSCRIBE werden mit 400 Bad Request beantwortet. Das sieht für mich als Laien schonmal seltsam aus.

Allerdings bin ich mir irgendwie sicher, daß das zitierte Paket eine Antwort des Servers ist und Du irgendwie nur die Hälfte des Traffics geloggt hast (oder es hier bei der Anzeige unterschlägst), denn eine Server-Antwort ohne Frage des Clients ist schon eher ungewöhnlich.

Ja, ist natürlich nur die Antwort (sonst würde es ja auch nicht zurück ge-NAT-ted werden, das zählt ja in der Firewall als related Paket). Aber es ist schon so, dass der Server deutlich öfter Pakete schickt. Das sieht i.d.R. so aus:

-> SUBSCRIBE
<- 400 Bad Request
<- \x00\x00\x00\x00
-> \r\n
<- \x00\x00\x00\x00
<- \x00\x00\x00\x00
<- \x00\x00\x00\x00
-> \r\n
<- \x00\x00\x00\x00
<- \x00\x00\x00\x00
<- \x00\x00\x00\x00
[...]

Bis zum nächsten REGISTER oder SUBSCRIBE. Abstand zwischen den 4 Bytes 0x00 jeweils 30 Sekunden.

EDIT: Hier mal der Dump der 400er Antworten auf SUBSCRIBE. Alles anonymisiert, IP-Adressen und alle tags/branches/nonces/IDs.

SUBSCRIBE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 184.143.188.101:55103;rport;branch=g4jV3pUImBHGaIU.X8246KzexOmEXPOd5TstwwZ6U
Max-Forwards: 70
From: <sip:[email protected]>;tag=8Qb4630-k11sESU8pafiP5kY3QJDHOB-
To: <sip:[email protected]>
Contact: <sip:[email protected]:55103;ob>
Call-ID: e1bdwDXhj3YI2rWhThO8Qus4q3qyG.wL
CSeq: 24484 SUBSCRIBE
Route: <sip:sip.personal-voip.de;transport=udp;lr>
Event: message-summary
Expires: 3600
Supported: replaces, 100rel, timer, norefersub
Accept: application/simple-message-summary
Allow-Events: presence, message-summary, refer
User-Agent: CSipSimple_wiko-19/r2330
Content-Length:  0


SIP/2.0 400 Bad Request
Via: SIP/2.0/UDP 184.143.188.101:55103;received=184.143.188.101;rport=55103;branch=g4jV3pUImBHGaIU.X8246KzexOmEXPOd5TstwwZ6U
From: <sip:[email protected]>;tag=8Qb4630-k11sESU8pafiP5kY3QJDHOB-
To: <sip:[email protected]>;tag=353e0ff09f78841d9252e48455ac54ed.bbe4
Call-ID: e1bdwDXhj3YI2rWhThO8Qus4q3qyG.wL
CSeq: 24484 SUBSCRIBE
Server: PBX-Server/1
Content-Length: 0

 

[schneckenpost]

Ändert sich denn die öffentliche IPv4?

Nein, die ändert sich bei uns i.d.R. einmal im Monat (Kabel BW, Kabelmodem). Die letzten Zeitpunkte waren (ich logge das mit):

2014-05-13 02:00:03
2014-06-29 18:25:01
2014-07-17 04:45:02
2014-08-22 05:25:01
2014-10-07 03:00:02

Wenn ich absichtlich eine IP-Neuvergabe im Kabelmodem anstoße, dann merkt das Telefon das aber auch und ist weiterhin erreichbar.

 

[PeterPawn]

Jedes zweite oder dritte SUBSCRIBE hat vorher zwei REGISTER (das erste wird mit 401 beantwortet, das zweite mit 200).

Dann macht das CSipSimple offenbar das Keepalive mit REGISTER. Das erste REGISTER ist (eigentlich immer) eines, das keine Authentifizierung enthält. Darauf antwortet der Server mit 401 und schickt dabei dann einen "nonce" als eine Art Salt für die Authentifizierung mit. Dann nimmt der Client diesen Einmalwert und authentifiziert sich im nächsten REGISTER-Request ordentlich.

Der Server muß seinerseits keine SUBSCRIBE-Events unterstützen, damit meldet sich ein Client ja nur als "Listener" für bestimmte Ereignisse an. Wenn der Server das nicht will (das spart ihm bei irgendwelchen Events das Abklappern der Subscriber-Queue), unterstützt er es eben nicht. Damit gehen dann solche Sachen wie eine serverseitige Mailbox und eine MWI schlechter bis gar nicht ... das braucht man für die reine Lehre beim Telefonieren aber ohnehin nicht. Die Signalisierung eines Anrufs erfolgt seitens des Servers mit einem INVITE-Request, dafür braucht es kein SUBSCRIBE.

Was der SIP-Server da in den kurzen Abständen schickt, weiß ich auch nicht ... sieht schon merkwürdig aus. Ich könnte mir nur ein serverseitiges "Offenhalten" einer UDP-NAT-Session vorstellen, aber wenn das der Server für alle bei ihm registrierten SIP-Clients mit UDP-Protokoll machen will, dürfte er bei einer ausreichenden Anzahl von Clients ganz schön ins Schwitzen geraten. Das kann ich mir irgendwie nicht vorstellen ... andererseits machen Pakete mit 4 NUL-Bytes alle 30 Sekunden auch nicht sehr viel Sinn. Da müßtest Du dann schon mal ein komplettes Paket samt Header preisgeben, sonst ist das alles nur spekulativ.