[Problem] BLF-Probleme mit Fonial und Snom

[epistates]

Ich habe genau das gleiche Problem wie in diesem Thread beschrieben. Apparate sind snom D385 mit aktueller Firmware. Als Telefonieanbieter kommt Fonial zum Einsatz.

Ich habe es mit dem Heruntersetzen der hier beschriebenen Einstellungen versucht, also

• user_subscription_expiry von 3600 auf 300 s gesenkt
• und retry_after_failed_subscribe von 600 auf 60 s gesetzt.

Leider behebt es das hier beschriebene Problem mit den Besetztlampenfeldern (BLF) nicht.

Hat jemand diesbezüglich eine Idee?

 

[sonyKatze]

Hat Dir Fonial bereits geantwortet? Wenn ja, was?

Das Problem ist, dass in diesem Thread der Telefonie-Anbieter nicht wie bei Dir Fonial sondern die Übergangsbox be.IP plus vom Hersteller Bintec-Elmeg ist. Folglich hast Du zwar die gleichen Symptome aber mit einer anderen Gegenstelle, Umfeld bzw. Umgebung. Die Frage könnte nur jemand beantworten, der Snom und Fonial nutzt. Solche Leute lädt die aktuelle Thread-Überschrift hier nicht ein. Daher mein Tipp: Post selbst melden und bitten, dass ein neuer Thread daraus gebildet wird. Der Thread kann dann auf das hier verlinken (gleiche Symptome) aber bekommt dann eine einladende Überschrift.

Ich persönlich habe zwar die be.IP plus und Snom aber kein Fonial. Sollte niemand mit Fonial vorbeikommen, wäre mein Tipp die SIP-Pakete mitzuschneiden. Vielleicht siehst Du dort, dass die Aushandlung der Timeouts genauso fehlschlägt, und vielleicht siehst Du so, welchen Timeout Du in Deinem Fall nehmen müsstest. Aber vielleicht ist es auch eine ganz andere Ursache. Weißt Du, wie man mitschneidet bzw. Wireshark-Traces interpretiert? Wenn nicht einfach sagen, dann helfen wir dabei.

 

[DM41]

Post selbst melden und bitten, dass ein neuer Thread daraus gebildet wird

Ist geschehen.

 

[epistates]

Hat Dir Fonial bereits geantwortet? Wenn ja, was?
[...]
Ich persönlich habe zwar die be.IP plus und Snom aber kein Fonial. Sollte niemand mit Fonial vorbeikommen, wäre mein Tipp die SIP-Pakete mitzuschneiden. Vielleicht siehst Du dort, dass die Aushandlung der Timeouts genauso fehlschlägt, und vielleicht siehst Du so, welchen Timeout Du in Deinem Fall nehmen müsstest. [...]

Fonial hat zugestanden das es gelegentlich passieren kann, dass eine BLF Taste nicht aktualisiert wird, da diesbezüglich Unmengen an Datenpaketen verschickt werden. Sie meinen aber wenn dies häufiger auftritt, das es auf ein Netzwerkproblem hindeuten kann. Am Telefon hat der Support aber eingeräumt das das Problem wohl mehrere Kunden haben.

Pinge ich einen der snom-Apparate an habe ich keine Paketverluste.
Ein Router-/Firewall-Problem kann ebenfalls ausgeschlossen werden, da speziell für die Telefonie ein Port Forwarding eingerichtet wurde. Leider hat das das Problem mit den Besetztlampenfeldern auch nicht gelöst ... sprich es bestand davor und auch danach.
Timeouts hochsetzen hat es auch nicht gebracht.

Ich könnte mir vorstellen das es vielleicht einfach nur eine Fehlkonfiguration in den snom Telefonen ist. Die sind zwar autoprovisioniert, aber damit ist ja nicht jede Einstellung abgedeckt. So waren beispielsweise falsche Codecs priorisiert, was zu abgeschnittenem Gesprächsbeginn bei Telefonaten führte.

Ein PCAP-Trace habe ich mal gemacht und in Wireshark eingelesen. Richtig schlau werde ich daraus aber nicht. Wie erkennt man denn da mögliche Fehlerquellen? Problematisch finde ich dabei auch, das ja die BLF nicht immer ohne Gespräche blinken oder dauerhaft leuchten. Mitschneiden müsste man ja wenn diese Irrläufer stattfinden oder kann man gezielt danach suchen? Bei längeren Telefonaten haben wir zudem festgestellt, das das BLF nach einer gewissen Gesprächsdauer bei anderen Teilnehmern erlischt.

Edit DM41: Vollzitat aufs Wesentliche gekürzt, siehe Forenregeln

 

[sonyKatze]

zugestanden […] eingeräumt

Die haben Dir Geschichten erzählt, aber nichts gemacht.

speziell für die Telefonie ein Port Forwarding eingerichtet wurde

Normalerweise sollte kein Port-Forwarding nötig sein. Das sollte man sogar nur einrichten, wenn man weiß, dass es nicht anders geht. Welchen Router (und Firmware-Version) benutzt Ihr?

Bei längeren Telefonaten haben wir zudem festgestellt, das das BLF nach einer gewissen Gesprächsdauer bei anderen Teilnehmern erlischt.

Das ist doch ein Szenario, dass man mal mitschneiden könnte.

Wireshark […] Richtig schlau werde ich daraus aber nicht

Wie BLF funktioniert, steht beispielsweise hier …
Wenn Du ein langes Telefonat führst, müsste ein Re-SUBSCRIBE erfolgen (siehe in der Erklärung den Abschnitt zu „Expires: 3600“). Die Frage ist, wie Fonial das dann beantwortet. Das steht im PCAP-Trace und siehst Du anhand der Zeitstempel dann auch in Wireshark.

 

[epistates]

Zyxel-Router hinter einer Watchguard.
Eben hatte ich das Phänomen wieder. Obwohl alleine im Büro, leuchten irgendwelche BLFs auf als ob Gespräche stattfinden.
Nach welchem Ausdruck sucht man denn idealerweise in Wireshark?
Ein "Expires: 0" finde ich schon mal nicht im SIP-Trace und deswegen bleibt wohl auch die SIP-Message mit dem Statuscode 200 aus.

 

[sonyKatze]

Nach welchem Ausdruck sucht man denn idealerweise in Wireshark?

Erstmal allgemein nach „sip“. Ist das zuviel, grentzt Du ein nach „sip && !sip.CSeq.method == REGISTER“. Ist das immer noch zuviel, kannst Du gezielt auf „sip.CSeq.method == SUBSCRIBE || sip.CSeq.method == NOTIFY || sip.CSeq.method == INVITE“ gehen.

Expires: 0

Das wäre auch schlecht, weil sich dann eines der Geräte vom SUBSCRIBE abmeldet. Die Frage ist eher, welche Antwort Du auf das letzte SUBSCRIBE bekamst, also ob es ein SIP-Status 200 (OK) war und wieviele Sekunden dessen „Expires“ lang ist.

Obwohl alleine im Büro, leuchten irgendwelche BLFs auf als ob Gespräche stattfinden.

Die Frage ist, was auf der Ebene SIP genau zu diesem Zeitpunkt passiert ist, also ob

a) eine eingehende Nachricht das ausgelöst hat,​

b) eine abgehende Nachricht nicht beantwortet wurde oder​

c) ein virtueller Zähler (von einer vorherigen Nachricht) ablief.​

Zyxel-Router hinter einer Watchguard.

Du meinst nicht hinter sondern vor? Welcher Router genau?

Auf jeden Fall klingt das nach einem Doppel-NAT. Selbst ohne Doppel, jedes NAT fährt Timeouts bezüglich IP-Verbindungen. Und leider nennt das jeder Hersteller anders. Beispiel: Eine FRITZ!Box macht eine UDP-Verbindung bereits nach fünf Minuten zu. Wenn das Telefon innerhalb dieser Zeit sein SUBSCRIBE nicht erneuert, dann wird ein NOTIFY seitens Fonial nicht mehr durch das NAT bzw. die Firewall durchgelassen. Daher frage ich, weil es ideal wäre, wenn Du vor jedem NAT bzw. Firewall zusätzlich mitschneiden könntest, mindestens auf dem WAN. Dann wüssten wir nämlich, ob NOTIFYs zwar von Fonial geschickt werden, aber nicht am Telefon ankommen (was dann alles durcheinander bringt).

 

[epistates]

Und schon fündig geworden. Dem SUBSCRIBE folgt ein 401 Unauthorized. Mehrmals.
Die Firewall blockiert nichts von Fonial.

 

[sonyKatze]

401 ist erstmal nichts Ungewöhnliches, weil das eine Challenge-Response-Authentifizierung ist. Nur wenn auf das 401 ein SUBSCRIBE folgt, und danach statt einem OK immer wieder ein 40x, dann wäre etwas nicht in Ordnung. Also bitte weitersuchen.

Die Firewall blockiert nichts von Fonial.

OK. Woher weißt Du das so genau? Port-Weiterleitung eingerichtet?

 

[epistates]

Ja genauso ist es ja:

SUBSCRIBE...
401...
SUBSCRIBE...
401...
SUBSCRIBE...
401...

Laut aufgezeichnetem PCAP-Trace während eines kurzen Testtelefonats.

WIr haben das Log der Firewall geprüft, deswegen weiß ich das so genau. In der Firewall ist zudem s.o. ein Port-Forwarding eingerichtet.

 

[sonyKatze]

In der Firewall ist zudem s.o. ein Port-Forwarding eingerichtet.

Das ist contra-produktiv. Bitte erstmal ausschalten – außer wir stellen fest, dass es wegen irgendeinem Grund doch nötig ist.

immer wieder ein 40x, dann wäre etwas nicht in Ordnung

Dann kommen wir der Sache näher.

1. Vor dem Test-Telefonat hat ein SUBSCRIBE mal funktioniert, also 200/OK zurückgeliefert. Richtig? Weil sonst BLF gar nicht ginge.
2. Enthalten die 401 den SIP-Header WWW-Authenticate?
3. Enthalten das zweite SUBSCRIBE (und Folgende) den SIP-Header Authorization?

 

[epistates]

Das beschriebene Phänomen tritt mit und ohne Port-Forwarding auf.

zu 1.) ja.
zu 2.) nein.
zu 3.) ja.

 

[sonyKatze]

Enthalten die 401 den SIP-Header WWW-Authenticate? Nein.

Wie bitte … wenn die Antworten des Server kein WWW-Authenticate enthalten, dann weiß ich gar nicht, wie der Header Authorization gebildet wird. Oder wer schickt diese 401? Fonial oder ein anderes Snom? Eine schöne Zusammenfassung findet sich auch hier … irgendwer müsste sich den Wireshark-Trace genauer anschauen.

 

[epistates]

Als Source für den 401 gibt Wireshark eine IP von Fonial (genauer eine des Mutterkonzerns Plusnet a.k.a. QSC) an.

 

[sonyKatze]

OK. Dann müsste man sich mit Fonial tiefer mit auskennen. Ein SIP-Status 401 ohne WWW-Authenticate halte ich für eine Protokoll-Verletzung. Wie der Ablauf auszusehen hat, siehst Du am Beispiel REGISTER … bemerkenswert, dass das Snom überhaupt weiter macht.

Sehe wenig, was wir machen könnten. Mein Tipp: Mit diesen neuen Kenntnissen Fonial kontaktieren und einen Bug-Report eintüten, am besten mit einem einfachsten Szenario in dem man ein Status 401 ohne WWW-Authenticate reproduzieren kann. Irgendwas bringt deren Systeme aus dem Tritt. Aber das blind zu erraten, ist ein wenig viel von Dir/uns verlangt.