Aktueller Inhalt von epistates

Als LDAP-Filter habe ich (|(givenName=%*)(sn=%*)) gesetzt. So steht es auch im snom Wiki: https://service.snom.com/display/wiki/What+is+the+syntax+of+the+LDAP+filter+on+the+M300%2CM700%2CM900 Das Globale Telefonbuch zeigt mir aber nur Vornamen mit einem Komma an, also Vorname, und darunter die...

Gleiches Problem hier mit korrekten Uhrzeiten auf dem Display aber falschen Uhrzeiten im Journal des Web-UI der Firmwareversion snomD385-SIP 10.1.73.16. Mit dem Update auf https://service.snom.com/display/wiki/10.1.84.12+Release ist das Phänomen bei unseren snom D385 behoben.

Auch mit deaktivierter Auto-Provisionierung findet keine Änderung des Phänomens statt. Und nun? Das scheint mir aber auch kein explizites snom-Phänomen zu sein. Wenn ich mit meinem klassischen o2-Festnetz meine Fonial-Nummer in der SIP-App anrufe tritt das Phänomen ebenfalls auf. Und das ist ja...

m=audio 31052 RTP/AVP 9 8 0 101 13 Dort ohne SIP-Status... ...Davor und danach SIP/2.0 200 Ok Betrifft sowohl eingehende wie ausgehende Telefonate. -- Zusammenführung Doppelpost gemäß Boardregeln by stoney Mit der neuen Einstellung: pcma,telephone-event Sieht es jetzt so aus: Ein IINVITE...

Provisionierungstemplates war das Stichwort welches ich gesucht habe. Und ja, auf Nachfrage beim Support: die gibt es, aber sie schalten die nur ungern für Kunden frei, da dies in der Praxis gern mal zu Schwierigkeiten führt, wenn falsche Einstellungen gesetzt werden etc. Aber jetzt habe ich...

Die Autoprovisionierung von Fonial setzt im snom bei codec_priority_list folgendes: g722,pcmu,pcma wenn ich das wie hier empfohlen abändere auf: pcma,g722,pcmu bringt dies leider keine Besserung. Wir haben in etlichen Tests nach wie vor einen abgehackten Gesprächsbeginn. Daher habe ich im...

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

Es sieht so aus, als ob das Snom die Einstellungen überschreibt: Jul 28 11:28:08.385 [INFO ] PHN: ProvisioningReplacements: URL >https://downloads.snom.com:443/fw/10.1.73.16/bin/snomD385-10.1.73.16-SIP-r.bin< Jul 28 11:28:08.386 [DEBUG0] PHN: Uri Replace >{mac}< in...

Das beschriebene Phänomen tritt mit und ohne Port-Forwarding auf. zu 1.) ja. zu 2.) nein. zu 3.) ja.

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.

Gemäß den Angaben in diesem Thread habe ich die codec_priority_list im snom D385 von: g722,pcmu,pcma geändert auf: pcma,g722,pcmu um den abgehackten Gesprächsbeginn zu unterbinden. Was auch sehr gut funktioniert. Leider wird nach einem Neustart des snom Apparates der Wert wieder...

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

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...

Im Vergleich mit Easybell ist Fonial deutlich teurer. Das stimmt. Aber Fonial bietet weitaus mehr Features. Am Ende ist es natürlich auch abhängig vom Nutzerszenario.

Vielen Dank für diesen Tipp! In unseren snom Apparaten war Nordamerika priorisiert (Vgl. Einstellung codec_priority_list). Seit Umstellung auf PCMA gibt es keinen abgehackten Gesprächsbeginn mehr.