SNOM D785 registriert nicht mehr bei Telekom

[gehtdoch]

@sonyKatze
Ja, glaube ich Dir sehr gerne. Fakt ist aber auch, dass das Telefon von @Joachim_1 die beiden von mir weiter oben genannten Fehler wirft (aus dem Log) beim eingehenden Call. Unter der Annahme, dass dieser Fehler korrekt und kein Bug ist (nur davon kann ich ausgehen), liegt das Problem daran, dass er mit den Codecs im SDP des Invite nicht klarkommt. Das kann natürlich mehrere Gründe haben: entweder das Telefon kennt keinen der angebotenen Codecs (was ich nicht glaube, weil da die 0815-Codecs enthalten sind, von denen ich ausgehe, dass die auch im Telefon erlaubt sind) oder es unterstützt keine Verschlüsselung, was die Telekom jedoch erzwingt. Das Ende vom Lied ist "488 Not acceptable" - "No supported media type found" wenn an der Stelle was nicht passt.

Ein Session- / Registrierungsthema kann es aus meiner Sicht nicht sein, weil sonst eine andere Fehlermeldung kommen sollte und es dann gar nicht mehr zur Auswertung des SDPs kommen dürfte. Da SNOM mit dem line-Parameter operiert (den die Telekom auch mitschickt im Invite), sollte es nicht zuordbare Calls sowieso gleich verwerfen. Da käme es dann auch nicht mehr zur Auswertung des SDPs (wenn man ordentlich programmiert zumindest).

Unabhängig davon könnte es ja trotzdem zielführend sein, den Account mal komplett neu aufzusetzen - vielleicht hat er ja eine Konfigurationseinstellung nicht richtig gefressen (-> wäre dann aber auch ein Bug). Oder mal durchbooten?

 

[Joachim_1]

Hallo, vielen Dank für die Gedanken zu meinem Problem.
Inzwischen sieht es so aus:

Du musst RTP Verschlüsselung aktivieren - sonst wird das nichts!

Nachdem ich die RTP-Verschlüsselung eingeschaltet und neu gestartet habe, gingen Anrufe zuerst nur auf Identität 1 ein, irgendwann dann auch auf Identität 2.
Allerdings steht immer noch "Registrierend unter beiden Identitäten.
Was könnte ich noch tun, damit sich das Tel wieder richtig registriert?
Im Anhang sind Screenshots von meiner Identität 1. Vielleicht kann man da noch was erkennen.
Ich nehme nicht an, dass das relevant ist, aber meine 2. Identität ist im Telefon Identität 3 und Identität 2 ist gelöscht.

Das heißt es hat geleuchtet oder sogar geklingelt?

Vorher hat es weder geleuchtet noch geklingelt. Der einzige Hinweis auf einen eingehenden Anruf war das Log-File.

Das Snom hat einen Software-Bug, der sich jetzt erst durch eine Änderung bei der Telekom offenbart hat.

Das kann ich mir jetzt auch vorstellen. Hoffentlich gibt es bald eine neue Firmware. Direkt an SNOM kommt man, glaube ich, schlecht ran, um sowas zu melden.

 

[gehtdoch]

Sehr schön. Schalt mal den langen SIP Contact ab (RFC 3840). Das interessiert niemanden bei der Telekom. Evtl. wartet Dein Telefon da auf eine Reaktion. "Status veröffentlichen beim Start" würde ich auch deaktivieren.

 

[Joachim_1]

Schalt mal den langen SIP Contact ab

Status veröffentlichen beim Start" würde ich auch deaktivieren

Hab ich beides gemacht: Keine Änderung, beide Identitäten sind immer noch registrierend.

 

[gehtdoch]

Hast Du durchgestartet? Sonst ziehen die alten Registers noch. Ach ja, bitte auch den SIP im Register dazu prüfen - ich zweifle nämlich mittlerweile dran, dass das, was man da einstellt, auch tatsächlich umgesetzt wird.

 

[Joachim_1]

Ich starte eigentlich immer neu nach Änderungen.
Habe die Werte noch mal kontrolliert. Scheint alles zu stimmen.

 

[gehtdoch]

Bitte zeige uns die SIP-Messages zum Register nach den beiden oben genannten Anpassungen. Ich möchte sehen, dass das, was Du gemacht hast, auch wirklich umgesetzt wurde! Die Info "geht nicht" genügt nicht!

Bei @sonyKatze hat es doch funktioniert - er hat es doch an einem SNOM schon getestet. Also muss bei Dir ein Konfigurationsproblem vorliegen (unter der Annahme dass Dein Telefon nicht defekt ist).

Vielleicht kann ja @sonyKatze mal den erfolgreichen Register hier im kompletten Ablauf reinhängen - dann können wir den mit dem Ablauf bei Deinem Telefon vergleichen. Inkl. konkretes Telefon und Firmwareversion (um sicherzustellen, dass wir hier nicht Äpfel mit Birnen vergleichen).

 

[Joachim_1]

Hallo, im Anhang ist ein SIP-Protokoll seit dem Anschalten heut morgen und ein Anruf vom Handy auf das Telefon.
Wie gesagt, das funktioniert jetzt wieder, aber auf dem Display rödelt das Icon ständig.
Außerdem Speicherinfos. Vielleicht kann man ja da etwas erkennen.
Und der Screenshot vom SIP-Register.

 

[gehtdoch]

Die Anpassung der Einstellungen wurde übernommen - sieht soweit schonmal gut aus.

Aus den SIP-Informationen geht nach wie vor hervor dass, der Register einwandfrei war. Die Telekom bestätigt den ganz klar. Was man auch dadurch erkennt, dass eingehende Anrufe zum Telefon geroutet werden - hätte der Register nicht funktioniert, kämen eingehende Anrufe nicht an.
Im Vergleich zum Ablauf bei Asterisk kann ich auch in der Response formal keinen Unterschied erkennen.

Da keine Zeitstempel in den SIP-Traces zu sehen sind (welchen Sinn macht ein Trace ohne Zeitstempel?) kann ich jetzt nur weiter vermuten:
Passend zur Anzeige glaubt das Telefon nicht, dass die Registrierung erfolgreich war (warum auch immer) und versucht es immer wieder.

Ich konnte sehen, dass die beiden Nummern mit der gleichen TCP-Verbindung durchgeführt werden. Das ist soweit technisch vollkommen ok - die Frage ist, wird das vom Telefon korrekt umgesetzt, verstanden?

Daher mal eine Bitte an Dich:
Kannst Du mal testweise nur einen Account registrieren (d.h., den anderen deaktivieren)? Aus den Screenshots habe ich entnommen, dass man das kann und daher sollte der Test recht einfach sein. Was passiert dann? Funktioniert es dann evtl? Bitte im SIP-Trace pürfen, dass auch wirklich nur eine Nummer registriert wird.

 

[wari1957]

@gehtdoch
"Sent to Tls:217.0.146.197:5061 from Tls:192.168.2.101:47935 at Dec 11 05:51:54.306 (565 bytes):"
"Received from Tls:217.0.146.197:5061 on Tls:192.168.2.101:47935 at Dec 11 05:51:54.639 (725 bytes):"

Sind das keine Zeitstempel?

 

[Joachim_1]

Hallo,

Da keine Zeitstempel in den SIP-Traces zu sehen sind

Es gibt pro Block einen Zeitstempel in der ersten Zeile hinten:
Sent to Tls:217.0.146.197:5061 from Tls:192.168.2.101:36434 at Dec 11 08:17:46.287 (565 bytes)

Im Anhang das SIP-PRotokoll mit nur einer Identität.
Auch auf dem Display sehe ich jetzt nur noch eine. Es steht aber immer noch "registrierend" da.

Eigentlich habe ich ja drei Telefon-Nummern. Die Dritte ist einem Gigaset mit Go-Box 100 zu geordnet und hat ja dann wohl nichts mit dem IP-Telefon SNOM zu tun, oder etwa doch?

 

[gehtdoch]

Danke für den Wink mit dem Zaunpfahl - habe ich übersehen! Schaue mir das jetzt mal hinsichtlich des zeitlichen Verlaufs nochmal an.

Damit ist das Thema "einfache Registrierung" auch ausgeschlossen, wenn das Problem da auch auftritt.

Die reRegistrierungen werden zufällig nach 4:30 bzw. 5:24 (in der ausgewählten Stichprobe) durchgeführt. Eigentlich sollten das über 10 Minuten sein (expire: 660).

Aus dem 200 Ok der Telekom für einen Register:

Contact: <sip:+49******[email protected]:47935;transport=Tls;line=3l48ppud;ob>;expires=660;+sip.instance="<urn:uuid:yyyyyyyy-xxxx-xxx-xxxx-xxxxxxxxxxxxx>";q=1.0;reg-id=1

Für mich sieht es daher so aus, dass er mit der 200 Ok Antwort der Telekom nicht klarkommt - die wird scheinbar nicht ordentlich geparsed. Neu hinzugekommen im Vergleich zu vorher ist seitens der Telekom der Parameter +sip.instance. Warum allerdings das SNOM von @sonyKatze damit keinen Stress hat, kann ich mir nicht erklären. Irgendwo muss da noch ein Unterschied sein!

Es kann auch sein, dass er mit einem anderen Header / Parameter vom 200er der Telekom ein Problem hat und daher das Ok nicht zuordnen kann (und nach wie vor darauf wartet, obwohl es schon längst da ist). Ich wüsste allerdings nicht, warum. Die anderen Header / Parameter sehen vollkommen unverdächtig aus und sind aus meiner Sicht genauso, wie sie sein sollen. Auf Basis der korrekten Call-ID müsste er in der Lage sein, die Response zuzuordnen.

Deine 3. Nummer auf einem anderen Device ist davon unabhängig. Da Du da keine Probleme meldest, gehe ich davon aus, dass die Go-Box funktioniert.


Ergänzung:
Gemäß RFC 4028 ist es "RECOMMENDED", nach der Hälfte der expire time einen (in diesem Fall) reRegister zu machen. "Recommended" heißt, dass man auch davon abweichen kann, wenn man weiß, was man tut (flapsig übersetzt).
In diesem Sinne verstanden, hat das SNOM die Registrierung durchaus verstanden, weil die reRegistrierung grob im Rahmen der (unteren) Hälfte der expire-Zeit liegt.
Da es insgesamt ja auch funktioniert, wie es soll, würde ich mich an der offensichtlich falschen Anzeige im Display einfach nicht weiter stören. Es wäre also zu klären, warum die Anzeige im Display nicht den tatsächlich vorhandenen Status widerspiegelt.

 

[Joachim_1]

Ich werde mich an die Icons gewöhnen. Wss ich in diesem Zustand allerdings nicht kann, ist die Identität am Telefon zu wechseln. Die Hoch- und Runter Tasten funktionieren nicht.
Die Identität lässt sich aber übers Web-Interface wechseln.

Vielen Dank für die Unterstützung an alle in diesem tollen Forum und eine tolle Weihnachtszeit!

 

[gehtdoch]

Das ist dann natürlich schon blöd. Hast Du evtl. mal versucht, einen Firmwarereset zu machen und komplett von vorne anzufangen? Vielleicht hilft das ja? Was mich eben wundert, ist, dass es bei @sonyKatze funktioniert - dann kann es ja eigentlich kein grundsätzliches Problem sein.
Wahrscheinlich sind die reReigsters, die man sieht, nicht wirklich reRegisters sondern schlicht retrys aufgrund des fälschlicherweise angenommenen Fehlers und das ganze "funktioniert" nur deshalb, weil der expire der Telekom erheblich länger ist als die fehlerbedingten Retryzyklen.

 

[sonyKatze]

Wird irgendeine SIP-Zeile sein. Ich werde die Tage (wie damals bei Cisco) mal meinen Emulator anwerfen und das Zeile für Zeile auseinandernehmen. Kann aber auch was spezifisch zu dem Modell sein, also das das D785 irgendwas anders macht. @Joachim_1 Du bekommst immer noch den Log-Alert mit „SIP: Received 200 Ok on REGISTER without expiry indication, assuming 0s“?

RTP-Verschlüsselung eingeschaltet

Ja, das ist der Menü-Punkt den @IEEE in Post #17 ansprach.
Hast (oder willst) Du den aus, müsstest Du das Telefon zwingen, DNS-NAPTR zu ignorieren …
Ganz nebenbei: Ich würde „MediaSec“ noch einschalten und „RTP/SAV“P von Aus auf Zwingend ändern.

 

[Joachim_1]

Wenn ich MediaSec aktiviere, ist die entsprechende IDentität nach Neustart gar nicht mehr registriert.
Also hab ichs wieder aus geschaltet.
Im Anhang ein Auszug auis dem Log, immer noch mit den von dir angefragten Meldungen.

 

[sonyKatze]

Web-Oberfläche → Erweitert → (Reiter) SIP/RTP → GRUU anbieten (RFC 5627)

Wenn das ausgeschaltet ist, dann erhalte ich Deinen Log-Alert. Die Identität ist tatsächlich in der Telefon-Oberfläche nicht registriert. Wenn Du GRUU einschaltest, klappt es dann auch bei Dir? Ab Werk ist das eingeschaltet. Daher bitte wie @gehtdoch empfohlen hat, überlegen, ob Du nicht das ganze Telefon zurücksetzt und von Vorne beginnst.

Technisch bist Du auf zwei Software-Fehler gestoßen:

1. Snom müsste den Parameter Expires auch dann auslesen, wenn das Snom mit dem folgenden Parameter nicht umgehen kann (hier: +sip.instance), also wenn GRUU abgeschaltet ist. Das dürfte gar nicht an der Länge des Headers Contact oder einem zu kleinen Zwischenpuffer liegen, sondern ein echt derber Parser-Fehler sein.
2. Telekom Deutschland dürfte eigentlich gar nicht mit +sip.instance antworten, weil das Snom (bei ausgeschaltetem GRUU) dann kein gruu im Header Supported anbietet. Vielleicht kann @Meester Proper dazu was sagen.

Wenn ich MediaSec aktiviere […]

Das schaue ich mir dann demnächst irgendwann an.

 

[gehtdoch]

Hallo @sonyKatze - super, jetzt habe ich mich auch mal mit GRUU auseinandergesetzt - hatte bisher noch keine Gelegenheit dazu, weil das asterisk und auch pjsip nicht supporten. So ganz klar ist mir der Sinn auch noch nicht geworden, welches Problem GRUU löst, das man ohne GRUU hat.

Nach Deinen Ausführungen zusammen mit dem Verhalten des Telefons, habe ich den starken Verdacht, dass der Fehler eher darin liegt, dass das Telefon fälschlicherweise auf die GRUU an dieser einen Stelle anspringt (obwohl der GRUU-Support deaktiviert ist und sie daher zu ignorieren wäre) und es daher logischerweise auch nicht funktionieren kann - der Anfang fehlt ja!

Die vermeintlichen "reRegisters" sind dann Folge dessen, dass das Telefon ja meint, es sei nicht registriert - was ja aber falsch ist und sich daher zyklisch immer wieder von neuem registriert (also Folge des Errorhandlings), was zufällig innerhalb des Expires der Telekom liegt. Daher funktionieren dann die Calls am Ende des Tages, weil die ja an sich weitgehend unabhängig von der Registrierung sind.

Das Telefon sollte die GRUU an der Stelle schlicht und ergreifend ignorieren (bei deaktiviertem GRUU-Support) und so arbeiten, wie es auch vor dem Telekomchange gearbeitet hat, als es keine GRUU gab. Dann würde es funktionieren.

In soweit ist es für mich auch nicht wirklich relevant, ob die Telekom an der Stelle eine GRUU mitschickt - das darf einen UA nie und nimmer aus dem Tritt bringen aus meiner Sicht. Was er nicht kennt (und daher auch nicht supported) muss er eben ignorieren. Ähnliche Parameter kommen ja auch im Contact vom Inivte mit (Bsp.):

+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-serve.ims.icsi.mmtel"

Damit muss ein UA klarkommen!


Dass die ganze Nummer mit aktiviertem Mediasec nicht funktioniert wundert mich nicht - die neuen SIP-Server der Telekom - darum handelt es sich hier ja - unterstützen bzw. erfordern kein Mediasec mehr. Wenn das Telefon nun aber darauf besteht, weil es aktiviert ist, wundert es mich nicht, dass es nicht geht, wenn der SIP-Server Mediasec ignoriert.

 

[Joachim_1]

Hallo,

Zwar verstehe ich nur einige wenige Worte der letzten beiden Beiträge, aber seit ich "GRUU anbieten" aktiviert habe, sind beide Identitäten wieder registriert! Unglaublich!
Eigentlich hatte ich vor, zwischen Weihnachten und Neujahr das Telefon von Grund auf neu auf zu setzen, aber das werde ich jetzt wohl nicht mehr tun.
Zum Beispiel weiß ich nicht, wie ich das Telefonbuch hätte wieder einspielen können. Seit dem letzten Update der Firmware kann ich nämlich nur im XML-Format speichern und Laden geht nur im cvs-Format.
Jedenfalls danke ich SonyKatze, gehtdoch und allen, die sich um mein Problem gekümmert haben sehr für ihre Untersützung.
Wenn ich aber noch einen Test druch führen soll, so sagt Bescheid.

 

[sonyKatze]

Zwar verstehe ich nur einige wenige Worte der letzten beiden Beiträge

Da kann ich Dich beruhigen, ich auch nicht. Man müsste zwischen Fakten und Vermutungen unterscheiden. Aber das kann man Closed-Software quasi nicht. Daher muss man schon etwas fit in Informatik und in Logik sein, wann man etwas Schlussfolgern kann. Trotzdem bedeutet das bei Closed-Software leider wahnsinnig viel ausprobieren.

Um es kurz zu machen: Du hast zwei Software-Bugs gefunden, die einzeln nie aufgefallen sind, aber in Kombination nun ein Problem darstellen. Das Snom wertet den SIP-Header Contact aus, aber sieht dort die Zahl hinter Expires nicht. Dadurch denkt das Snom, es sei nicht registriert. Dadurch registriert es sich laufend neu. Schaltest Du GRUU ein, klappt es.

Mein Fehler war anfangs, dass ich nur die Antworten der Telekom angeschaut hatte. Diese waren bei uns gleich. Die Lösung lag in den Anfragen des Snom. Hier sah ich, dass bei Dir GRUU aus war, also Dein Telefon in einem anderen Zustand war als meines. Das habe ich dann nachgebaut. Und so konnte ich das Verhalten nachstellen (Anzeige in Telefon-Oberfläche und Alert im Log).

Grund auf neu auf zu setzen

Solltest Du trotzdem tun. Man weiß nicht, was noch alles schief ist. Dass sowohl GRUU als auch RTP-Verschlüsselung bei Dir aus waren, ist schon seltsam.

wie ich das Telefonbuch hätte wieder einspielen können. Seit dem letzten Update der Firmware kann ich nämlich nur im XML-Format speichern und Laden geht nur im cvs-Format.

Mein Tipp: Neuen Thread aufmachen, nur mit dem Thema.

[sinngemäß:] Welches Problem löst GRUU?

Mein Tipp: Neuen Thread aufmachen (oder in Deinem Telekom-Änderungs-Thread fragen). Vielleicht erklärt es dort dann jemand Anderes. Ich habe gerade nicht die Zeit, dass prägnant zu beschreiben. Als Tipp: 1TR114 Kapitel GRUU (aktuell Kapitel 4.2.9). Jedenfalls versucht die Telekom dort zu erklären, wozu sie es braucht. Edit: Im Telekom-Hilft ist bereits eine nette Erklärung … wenn die nicht ausreicht, einfach neuer Thread.