SNOM 370 Besetztlampenfeld, keine Anzeige der besetzten Leitung

  • (Gelöst)
    Moin,


    ich habe ein kleines Problem mit der SNOM BLF-Funktion bei zwei Benutzern, die sich in einem anderen Netz befinden, welches per S2S VPN (Lancom) ohne NAT gekoppelt ist. Die Tastenfunktionen wurden hier zwar übernommen und funktionieren auch, jedoch wird eine besetzte Leitung nicht mit blinkender LED angezeigt, wie bei den restlichen Snömchen im internen Netz, da funktioniert das alles wunderbar. Die Benutzer haben das Recht "Telefoniert mit". Alle anderen Telefoniefunktionen sind einwandfrei nutzbar.


    Wo kann ich hier ansetzen, um das Problem zu lösen?


    Liebe Grüße
    John

    4 Mal editiert, zuletzt von John ()

  • Hallo John,


    die Signalisierung an den Tasten wird über das SIP-Protokoll durchgeführt. D.h. das Telefon sendet SIP-Pakete vom Typ SUBSCRIBE für jede programmierte Taste an die STARFACE. Wenn nun ein Nutzer klingelt oder im Gespräch ist sendet die STARFACE an das Telefon ein SIP-Paket vom Typ NOTIFY und überträgt damit den Status dieser Taste. Diese Kommunikation läuft normalerweise über den Port 5060.
    Wenn du schreibst, dass die Tasten übernommen wurden, ist es dann möglich durch Tastendruck einen Kollegen anzurufen und funktionieren eingehende Anrufe auf die Geräte reibungslos?


    Vielleicht helfen dir diese Informationen bei der Fehlersuche weiter.


    Viele Grüße


    Marco

  • Hallo Kappie,


    jetzt stehe ich komplett auf dem Schlauch, dank Deiner Auflösung :o


    Wir haben bei SIP-Gesprächen generell die Initiierung und Anmeldung und was weis ich noch alles über UDP 5060, der Rest Sprache RTP ist dynamisch, UDP irgendwo nach Aushandlung. Dass da in SIP 5060 BLF LED auch mit drin hängt, habe ich einfach nicht realisiert. Hätte ich aber wissen müssen.


    Wenn ich also Gespräche initiieren kann, das ja alles richtig sauber funktioniert, in perfekter Sprachqualität, (Per Tastendruck auf die BLF Taste Kollegen anrufen, bzw. alles das, was Du angefragt hast), aber diese dummen LED's halt nicht,... dehä???


    Err - zu Deiner Frage: Ja, korrekt, es funktioniert alles, auch das Anrufen über "BLF-Taste" oder setzen von Umleitungen. Nur halt diese idiotischen BLF LED's nicht.


    Firewalls zwischen den Netzen auch mal testweise aus. Gleiches Problem.


    Wald. Bäume. Schlauch. Bahnhof.
    *kopfkratz*


    Auch viele Grüße
    John

    2 Mal editiert, zuletzt von John ()

  • Hi John,


    noch ein Tipp. Du kannst im Web-Interface des SNOM Telefons den PCAP-Trace aktivieren und damit den kompletten Netzwerkverkehr von dem Gerät mitschneiden und z.B. mit dem Tool Wireshark auswerten. So kannst du herausfinden, ob die SIP-Notify Pakete überhaupt an dem SNOM ankommen.


    Gruß Marco

  • Danke. Inzwischen hab' ich den Trace tatsächlich angeworfen bekommen, ist jedoch an einem Remotestandort ohne Server in der Nähe recht schwierig...
    Ich habe inzwischen eine Vermutung -> SIP-ALG...

  • Hallo Ihr lieben,


    inzwischen habe ich dank Eurer Tipps die Ursache gefunden. Es ist tatsächlich der SIP-ALG. Nach Deaktivierung des SIP-ALG's kann ich die BLF-Tasten wieder einwandfrei nutzen.


    Mit dem bitteren Beigeschmack: Der Lancom SIP-ALG kümmert sich nebst der Firewallkonfiguration auch um eine sehr gute QOS Zuordnung. Es gab an den Remotestandorten mit SIP-ALG eine absolut hervorragende Gesprächsqualität SNOM<->Starface. Jetzt muss ich einen Riesensatz an QOS-Regeln bereitstellen, den ich bis dato gehofft hatte, endgültig loszusein. Starface rät jedoch auch in den FAQ's, SIP-ALG zu deaktivieren, was sicherlich aus der Sicht von Starface korrekt ist.


    Jetzt hoffe ich, dass Lancom das Problem löst.


    Liebe Grüße
    John

  • Hallo John,


    auch wenn es mit dem SIP-ALG beim Lancom offenbar das beschriebene Problem gibt, meine Frage dazu:


    Welches LCOS ist denn (auf welchem Lancom) im Einsatz? Ich hatte das zuletzt mit LCOS 9.00 mal getestet und da funktionierte das hier überhaupt nicht.


    Beste Grüße,
    Ulf

  • Hallo Ulf,


    es funktionierte (bis auf BLF) absolut perfekt. Standorte äußerst bescheiden angebunden, PRO4S0 hat einen CoCo5M auch am 1781VA und die Snömchen am Remote S2S so irgendwas um die 5600 zu 250k. Das wohl auch erst mit dem neuen Modem vom LC, davor waren max. 4M zu 0,1 an diesem Standort in Timbuktu drin. Mit SIP-ALG ist die Gesprächsqualität bislang hervorragend gewesen. Ich brauche den SIP-ALG wirklich dringend, insbesondere für so hundsmiserabel angebundene Standorte, und nein, speziell auf die Standortauswahl von den Problemkindern hatte ich definitiv keinen Einfluss...


    2x Lancom 1781VA mit 9.04.84RU2 (zuvor ältere Versionen im Einsatz, jedoch nicht die 9.0.0 erstes Release, der VA macht u.A. auch WLC und Pubspot Option)
    1x Starface PRO4S0
    2x SNOM370 (je 1x letzte von Starface freigegebene, provisionierte Version und 1x aktuellste Firmware von SNOM)


    Gottseidank hab' ich die FW/QOS Konfig für die Lancoms früher schonmal aufgeschrieben und die Dinger werten DiffServ aus... -> KLICK

    10 Mal editiert, zuletzt von John ()

  • Hallo John,


    Danke für die Antwort. Ich habe hier (und bei Kunden) auch den 1781 im Einsatz, allerdings leider genau bei der LCOS-Version 9.00 aufgehört zu testen, nachdem da mit SIP-ALG so gar nichts (richtig) funktionierte. Insofern nehme ich mit Freude zur Kenntnis, dass ich wohl an der Stelle schlichtweg nur ein wenig zu früh aufgehört habe zu testen. Ich werde das natürlich gerne mal in Kürze nachholen, zumal das LCOS hier zwischenzeitlich auch bei 9.04 RU2 angekommen ist :)


    Jetzt muß ich mir erst mal den klasse Link reinziehen und auch da mal einige Zeit investieren - beim Überfliegen habe ich schon mal andere (ergänzende) Ansätze zum Lancom entdeckt.


    Beste Grüße,
    Ulf

  • Hallo,


    ich wollte nur kurz Sachstand melden, dass Lancom sich der Sache angenommen hat und offenbar schon einen Punkt getroffen hat.
    Ich kann bald mit einer geänderten SIP-ALG Version testen.


    Liebe Grüße
    John

  • Hallo,


    kurzer Wasserstand:


    Nach einigem Testen mit Debug-Firmware funktionieren leider auch einige Gigaset N510 an Remotestandorten nicht mehr. d.h. eingehende Anrufe werden signalisiert, die Abheben-Funktion ist jedoch nicht mehr möglich, komischerweise auch nicht mehr, wenn wir die Originalfirmware von Lancom verwenden. Es ist echt wie verhext.
    Das Problem BLF bei SNOM ist weiterhin akut.


    Gruß
    John

  • Warum tut Ihr Euch das auch an ?


    Lasst doch einfach die Finger von SIP-ALG; mehr wie Probleme werden damit nicht erreicht.

    Gruss
    Thomas


    hertli ¦ IT
    hertli Informatik+Treuhand


    eMail: mail ( a t ) hertli.ch
    Internet: www.hertli.ch


    Virtuelle Rechenzentren (IaaS, PaaS) mit Standorten in CH + DE, Managed Services, Security

  • *Update*
    Lancom bringt demnächst einen Fix für das BLF, das Problem wurde erkannt und wird in der nächsten, verfügbaren LCOS-Version bereitgestellt: "Bei der Übertragung des BLF fehlte (teilweise) das Request-Flag. Dadurch wurde die SUBSCRIBE-Message falsch zusammengebaut.". Ich werde berichten, ob das Problem damit behoben wurde.


    Offen bleibt mein Gigaset Problem, das wäre hier jedoch OT, bzw. die Config-GUI vom Gigaset N510 ist so laggy, dass ich echt Probleme habe, dort den richtigen "knopf" zu drücken. Ggf. werde ich noch einmal einen weiteren Thread aufmachen.


    //Bei der Bandbreite nicht anders möglich, wobei man hier nicht von Bandbreite sprechen kann.

  • Ich würde mich hier Thomas Hertli anschließen und von SIP-ALG die Finger lassen. Und was QoS angeht: Mehr als zwei Regeln zum Matchen des ToS-Felds sind das nicht. Alternativ die Protokolle SIP und RTP matchen.

  • *Update*


    Die Probleme mit der N510 IP sind - nicht - behebbar. Mit SIP-ALG gelöst über eine Starface Compact Anlagenverbund auf der schlecht angebundenen Seite. Da nur für eingehende Anrufe genutzt, ist auf der zentralen Starface iFMC auf die DECT-Geräte in der schlecht angebundenen Seite gesetzt. Das klappt jetzt wunderbar. Der Starface-Anlagenverbund stört sich offenbar nicht an SIP-ALG, dennoch wird die Bandbreite korrekt reserviert.


    Auf die Lancom 9.10 Firmware werden wir warten bis allgemein verfügbar, dann wären die Probleme auch behoben. Auf das Angebot einer Entwickler-Firmware haben wir Verzichtet, da momentan alle stark ausgelastet sind. Es gibt wohl noch einen Kunden, der ein technisch identisches Problem hat, mit jenem Lancom testen möchte.


    Wenn das Ergebnis mit der offiziellen 9.10 stimmt, bin ich sehr zufrieden mit der guten Unterstützung durch Lancom, die wirklich alles in die Wege geleitet haben, um das passabel hinzubekommen. Das kann ich von anderen leider nicht sagen. Gigaset hat es nicht einmal für notwendig erachtet, zu antworten. Gigaset ist halt nicht snom, die eigenständig Interesse bekunden und Kontakt zu uns aufnehmen. Diesen Unterschied behält man im Hinterkopf.



    Gruß
    John

  • Warum sollte sich Gigaset auch darum kümmern, wenn man entgegen jeder Empfehlung eine nachweislich kaputte Implementierung eines SIP-Proxies einsetzt und auf den Gateways eine Debugging-Firmware einsetzt?


    Um die allseits beliebten Analogien mit Autos zu verwenden: Es wird sich kein Hersteller darum kümmern, wenn der Motor nicht läuft, weil man Rosenwasser in den Tank füllt, nur weil es besser riecht.

  • Hallo Fabian,


    ... ganz so einfach ist es nicht. Gigaset ist schon etwas ... sagen wir mal (ohne "schimpfen" oder "abwerten" zu wollen) "speziell". Ich denke da an leidvolle Erfahrungen mit dem S650H dieser Firma - dort gab es auch für hauseigene Technik (N510 + S650H) keine brauchbare Hilfestellung und diese beiden Komponenten funktionieren beim Kunden brauchbar nur mit der letzten verfügbaren Gigaset-Beta(!)firmware ...). Letzteres musste ich dann noch selbst herausfinden - der Hersteller fand "kein Problem" und hatte trotz gezielter Nachfrage in die richtige Richtung auch gar keine Idee.


    Und nicht falsch verstehen: ich mag die Gigaset-Geräte eigentlich und empfehle die auch nach wie vor weiter, nur der direkte Gigaset-Kundenservice unterscheidet sich schon ein wenig von dem anderer Hersteller. Lancom ist da auch meiner Erfahrung nach durchaus rührig und macht im Supportbereich etwas mehr + kommuniziert besser.


    Was bestimmte Geräte- und Softwarekombinationen anbelangt, magst Du natürlich Recht haben, wenngleich auch in diesem Punkt Hersteller eine unterschiedliche Herangehensweise von Interesse am Funktionieren unter allen möglichen - auch, sagen wir mal: "ungewöhnlichen" - Szenarien bis hin zu völligen Desinteresse haben. Wie auch immer sollte man Antworten natürlich erwarten dürfen - auch wenn die gegebenenfalls abschlägig sind ...


    Woher Johns Empfinden kommt, ist jedenfalls nachvollziehbar.

  • Das Problem kann als gelöst betrachtet werden. Alle Infos befinden sich in meinen Beiträgen und an anderer Stelle im Netz.
    Weitere Kommentare dazu an dieser Stelle von meiner Seite nicht mehr.

  • und an anderer Stelle im Netz.


    Dann definiere doch bitte ...und an anderer Stelle im Netz.


    Wir sind leider keine Hellseher.

    Gruss
    Thomas


    hertli ¦ IT
    hertli Informatik+Treuhand


    eMail: mail ( a t ) hertli.ch
    Internet: www.hertli.ch


    Virtuelle Rechenzentren (IaaS, PaaS) mit Standorten in CH + DE, Managed Services, Security

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!