Beiträge von DerGerät

Hallo Grabow

Bist du schon den Fehlerleitfaden durchgegangen?
https://knowledge.starface.de/pages/viewpage…?pageId=7864508

Beste Grüße und viel Erfolg
DerGerät

Hallo Ulf!

Ich habe gerade mal beherzt mein Modem abgeklemmt. Interne Funktionen der Starface waren soweit alle gegeben (Anrufe, Voicemail, Gruppen), sowohl mit Telefonen (DE900, Snom 375 und einigen manuell Angebundenen) als auch mit div. Softphones und dem UCC.
Nur ISDN kann ich mangels Anschluss nicht testen.

Meine Starface VM läuft auf der aktuellen 6.4.1.11.

Hast du mal bei dir die Logs gesichtet?

Viele Grüße
DerGerät

Fabian hat recht. Von einem Security-Standpoint sind 50.000 offene Ports nicht schlimmer als ein offener Port.
Der Listenerdaemon dahinter (asterisk) nimmt eh nur Pakete aus bestehenden, ausgehandelten SIP-Sessions an.

Ich poste mal meine laufende Konfiguration.
Bei DNAT das erstellen der Firewallregeln anhaken.

DNAT
2016-11-28 11_25_52-WebAdmin - User admin - Device gateway.janz.online.png

Definitionen
SIP(S)
sips.png

XMPP
xmpp.png

RTP
2016-11-28 11_31_46-WebAdmin - User admin - Device gateway.janz.online.png

Sonstiges
Network Protection -> VoIP unbedingt ausschalten.
Das ist ein SIP ALG was die Funktionsweise der STARFACE beeinträchtigt.

Port 443 ist durch einen Reverse Proxy (NGINX) belegt, der u.A. das Webinterface und die REST-API der STARFACE rausreicht.

Lieber dirk.

sachliche Kritik bringt man anders vor. Ich lese von dir von oben bis unten Bashing, unterbrochen von "ich hab's nicht so gemeint"-Posts.

Schön finde ich trotzdem deine Liste mit Kritikpunkten, einiges davon stößt auch mir bitter auf.
Insbesondere mangelndes IPMI auf eigenem Interface...

Vieles davon sind aber ganz einfach Infrastrukturthemen (DynDNS, FritzBox, ...). Es gibt viele Instanzen in denen es einfach sauber läuft.
Auch ich habe solche Installationen bereits vorgenommen, erfolgreich. Ganz ohne viertelmillionen Usenet-Posts

Zitat von fwolf

Als Modul verfügbar: http://starface.janz-einfach.net/doku.php/publi…es:let_sencrypt.

Leider nicht vollautomatisch. Du musst dir das Zertifikat an einem Webserver deiner Wahl herauslassen (bzw. dich Authentifizieren) bevor du es einspielen kannst.
Ich habe das über einen Reverse Proxy geregelt, welcher mir das Zertifikat regelmäßig erneuert.

Ist der Kollege eventuell mit deinem Benutzer am Telefon angemeldet?

Zitat von DanielH

Dieser spezielle Kunde nimmt fast jedes Gespräch mit seinen Klienten auf. Telefongespräche dauern seine Zeit. Platzverwaltung auf der Appliance wird immer mehr zum Thema...

Prinzipiell hindert dich bei einer Appliance niemand daran:

a) eine größere Festplatte zu verbauen (Userservicable Parts) oder
b) ein externes Medium (z.B. SFTP oder SMB-Share) in die Ordnerstruktur für die Voicemails zu mounten

Variante b) könnte STARFACE dir mit Sicherheit auch in der Cloud implementieren, gegen den Einwurf mittelgroßer Schein versteht sich.

Bei einer Appliance könnte ich dafür ein Tutorial erstellen.

Liebe Grüße

Zitat von Celeron

Hallo, auch bei uns versteht die Gegenstelle seit dem letzten Update auf 6.3.0.24 unsere Mitarbeiter kaum.

Handyanrufe sind ok.

Gibt es ein Update? Sehe nicht ein das wir in irgendwelchen Dateien manuelle Änderungen vornehmen sollten.

cu
Peter

In dem Fall solltest du ein Support-Ticket eröffnen:
http://www.starface.de/de/support/ticket.php?btn=1

Beschreibe den Fehler so genau wie möglich:

• Von welcher Version du geupdated hast,
• welche Anrufe betroffen sind (interne oder externe Anrufe, ein oder ausgehend),
• wie du in's Amt angebunden bist (welcher Provider, VoIP oder ISDN (in dem Fall: welche ISDN-Karte),
• welche Endgeräte betroffen sind.

Als Bonus würde ich noch einen tcpdump beilegen:

• per SSH auf die Anlage verbinden,
• folgenden Befehl starten:
  tcpdump -i any -w /tmp/rxgain.cap portrange 5060-5061 or portrange 10000-20000
• den Fehler nachstellen,
• den tcpdump mit CTRL + C beenden,
• den Netzwerkmitschnitt komprimieren:
  zip /tmp/rxgain.cap.zip && rm /tmp/rxgain.cap
• die Datei (/tmp/rxgain.cap.zip) per SFTP von der Anlage herunterladen,
• per Mail als Antwort auf die Bestätigungsmail des o.g. Formulares einsenden.

Zitat von D.Woehrl

Ich habe diese Woche ernste Probleme meine Anlagen auf die 6.3.0.19 zu aktualisieren.

Bei verschiedenen Kunden mit verschiedenen DSL Zugängen und auch verschiedenen Routern/Firewalls lädt das Update zum teil nur mit 8 kbps. Ab und an ist es ein bisschen mehr drin so 134 kbps.
Somit bin ich nach 3 Stunden gerade mal bei 430 MB.
Die Zugänge der Kunden kann ich komplett ausschließen. 16.000 DSL über die nichts anderes geht.
Andere Downloads sogar von den Starface Appliances gehen zackig.

Außer Stress mit dem Starface Quellservern fällt mir hier zu nicht viel ein.

Jemand anderes ne Idee wo ich ansetzen kann?

mfg Dennis

Hallo Dennis!

Ich habe da eine Theorie:
http://www.starface-cdn.de führt dich zu Cloudflare:
niklas@NB010 ~ $ dig www.starface-cdn.de

[...]

;; ANSWER SECTION:
http://www.starface-cdn.de. 191 IN CNAME http://www.starface-cdn.de.cdn.cloudflare.net.
http://www.starface-cdn.de.cdn.cloudflare.net. 212 IN A 104.25.15.34
http://www.starface-cdn.de.cdn.cloudflare.net. 212 IN A 104.25.14.34

Der Server der dich dann von dort bedient wird per Geolocation ausgewählt.
Jetzt ist es so, das sich die DTAG Peering in Rechenzentren fürstlich bezahlen lässt:

Zitat

Im Bezug zur deutschen Telekom (dtag), haben wir lange und intensiv verhandelt, um einen direkten Netzzugang zu den DSL-Kunden der Telekom zu erhalten. Aber nachdem die Kostensituation für uns immer nachteiliger wurde, haben wir uns letztendlich schweren Herzens dazu entschlossen, auf eine direkte Netzanbindung zur dtag zu verzichten.

- https://wiki.hetzner.de/index.php/Double_Paid_Traffic

Ich könnte mir gut vorstellen das nicht jede Cloudflarenode über direktes Peering mit den Telekom-Netzen verfügt.

Als Gegentest könntest du direkt von den Quellservern herunterladen:

niklas@NB010 ~ $ dig starface-cdn.de

; <<>> DiG 9.10.3-P4-Ubuntu <<>> starface-cdn.de
[...]
;; ANSWER SECTION:
starface-cdn.de. 3599 IN A 217.160.122.151

Also statt http://www.starface-cdn.de/starface/ISOS/…0038_x86_64.iso http://starface-cdn.de/starface/ISOS/…0038_x86_64.iso.
Das hilft zumindest bei mir, der dank einem Reseller ebenfalls beim Magenta-Riesen gelandet ist.

<RANT>
Das passiert wenn die Monopolstellung eines Providers Staatlich fördert.
Ich seh' schon vor meinem geistigen Auge einen mkoenig in diesem Thread vorbeischlawinern und etwas in die Richtung "Ja aber die DTAG ist ja Inovationsmotor!" kommentieren.

Nein. Einfach nur nein.
Oder zumindest wenn man es als Invation betrachtet, einem gealterten Rennfperd (Kupferinfrastruktur) die gebrochenen Beine mit Panzertape zu flicken.
Zwischen der Peering-Erpressung (s.O.), den laufenden Angriffen auf Netzneutralität und dem Verhökern von direktem Netzzugriff an die NSA ist dieser Verein in meinen Augen einfach nur widerwärtig und ein Fall für die Staatsanwaltschaft.
</RANT>

Zitat von Ulf

Diesen Effekt habe ich zufälligerweise gestern bei einem Kunden mit SF 6.2.0.15 auch beobachten können - allerdings in der Form, das sowohl die Leitung als nicht verfügbar und auch nicht registriert angezeigt wurde und trotzdem ein- wie ausgehend telefoniert werden konnte. Ein Diensteneustart hat dann die Leitungen wieder komplett "ergrünen" lassen

Hallo Ulf,

Diensteneustart half bei mir nicht. Umbenennen der Leitung schon.

Zitat von Ulf

Ein grundsätzliches Problem der Beta 6.3.x ist das wohl eher nicht (die haben wir hier testweise auf 2 Anlagen laufen und das so noch nie beobachtet) - wenn, wäre es schon vorher so gewesen und nur ganz selten auftretend (ich habe das gestern das erste Mal in dieser Form gesehen).

Auch gut zu wissen, habe es halt wegen dem auftreten direkt nach einem Update der 6.3 zugeschrieben.

Hallo liebe Community,

ich habe meine SF von 6.2.0.15 auf 6.3.0.6 geupdated.
Wenn ich mir meine Leitungen im Webinterface ansehe gibt es da eine kleine Inkonsistenz:

leitungen_privacy.png

Der Haken ist grün, Status ist lt. WebUI allerdings "Not Registered".

Registry im asterisk:
peerstates_privacy.jpg

Telefonie ist möglich.

Bug oder Feature?

Grüße
Niklas

Hallo Schubbie,

nach dem Update auf die 6.3 hat's mich auch erwischt.
Ich geh dem mal nach...

Hallo osite,

bitte mach mal folgendes:
aktiviere SIP debugging im Asterisk für deinen Softphone Peer.
Angenommen dein Peer lautet 1234.WinClient, dann aktiviere es wie folgt:

SSH zur STARFACE

rasterisk

sip set debug peer 1234.WinClient

(Tip: die Befehle in der Asterisk CLI lassen sich mit Tab autocompleten)

Dann tätige einen Anruf, und schau im SDP dach der Media-Adress (c= Attribut), z.B.

INVITE sip:xxx.ip.des.ucc:1137;transport=TLS SIP/2.0
Via: SIP/2.0/TLS xxx.ip.der.starface:5061;branch=z9hG4bK67e3388f;rport
Max-Forwards: 70
From: "click2dial: +49angerufeneNummer" <sip:+49angerufeneNummer@xxx.ip.der.starface>;tag=as27851aad
To: <sips:1234.WinClient@xxx.ip.des.ucc:1138;transport=TLS;ob>;tag=d74307a775ca43a5a4db1ee5213bc483
Contact: <sip:+49angerufeneNummer@xxx.ip.der.starface:5061;transport=TLS>
Call-ID: xxxx
CSeq: 103 INVITE
User-Agent: STARFACE PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
P-Asserted-Identity: "DerGerät" <sip:0angerufeneNummer@xxx.ip.der.starface>
Content-Type: application/sdp
Content-Length: 338


v=0
o=root 2005064831 2005064832 IN IP4 xxx.ip.der.starface
s=STARFACE PBX
[U][COLOR='#FF0000'][B]c=IN IP4 xxx.ip.der.starface[/B][/COLOR][/U]
t=0 0
m=audio 13362 RTP/SAVP 9 101
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:5MivmhsAr4sKlT2Xd16vJbiM1oWDP7H64zbMFkDP
m=video 0 RTP/SAVP 99

Dort müsste die externe IP der STARFACE erscheinen.

Hallo Alex,

wie mein Vorposter auch ungetestet:
/etc/asterisk/features.conf anpassen und vor "callmonitor" ein Semikolon setzen (auskommentieren).
Asterisk reloaden:

/etc/init.d/asterisk reload

Damit hast du das *1 Feature abgestellt.

Hallo Peter!

Ich baue derzeit eine Home-Automation mittels Home Assistant, die unterstützen SONOS:
https://home-assistant.io/components/media_player.sonos/

Ich setze persönlich auf Kodi mit folgendem Konstrukt:
SF (Modulhooks: "On all incoming / outgoing calls" -> REST API von Home Assistant -> KODI Wiedergabe pausieren.

Wiederaufnehmen muss man die Wiedergabe allerdings händisch, zB. über das Home Assistant Webinterface.

Hoffe dir einen Anstoß gegeben zu haben.

Zitat von bs2000

Nachtrag:
Gestern kam ein Techniker der Telekom und tauschte die beiden ca. 10 Jahre alten NTBAs aus. Nun sind keine Fehler mehr bzgl. `` Detected alarm on channel 1: Red Alarm`` im Log ersichtlich

Das ist schön zu hören.
Mir ist diese Fehlermeldung im Zusammenhang mit Stromgespeisten NTBAs bekannt. Meist hilft hier die NTBAs von der Stromversorgung zu trennen.

Zitat von bs2000

Nachtrag:
Heute kamen Reklamationen von externen Gesprächspartnern, dass sie kaum ein Wort verstehen würden, da es viel zu leise sei. Kann dies mit dem Codec g722 zusammen hänen? Soll ich mal

Eher nicht. Einen Versuch ist es wert, aber ich bin da skeptisch das der Codec die Lautstärke senkt.
Hast du das Problem nur extern?
Falls ja: überprüfe die Verkabelung zwischen NTBA und SF, tausch am besten Mal die Kabel.

Zitat von slu

Die Leitung geht bei mir ~ 1 Minute, dann nicht mehr.
Inzwischen hab ich mal zum testen ein Port Forwarding von 10000-50000 UDP eingerichtet, laut Firewall Log kommen nämlich von 5060 -> 41xxx UDP Verbindungen.

Mach nicht den Fehler und verwechsele Source- und Destination-Port.

Lösung: Grub neuinstallieren.

Step-By-Step:
http://starface.janz-einfach.net/doku.php/publi…leshooting:grub

Zitat von fwolf

2.) Aktivierne der manuellen Leitungskonfiguration für die SIP-Leitung. Im -incoming-Kontext der SIP-Leitung gibt es ein "Goto(xxx,${EXTEN},1)". Das xxx kann dabei durch den Namen des -incoming-Kontexts der vorherigen Leitung ersetzt werden.

[...]

Vorteil 1: Das Vorgehen dauert keine 2 Minuten.
Vorteil 2: Die Rufnummernkonfiguration bleibt erhalten.
Vorteil 3: Es sind keine gefährlichen Datenbankanpassungen notwendig.
Vorteil 4: Die alte Leitung ist immer noch vorhanden, falls man wieder zurück möchte.
Nachteil: Die alte Leitung dümpelt vielleicht unnötigerweise weiter in der Leitungskonfiguration herum.

Die CDRs und dementsprechend die Auswertung werden dann allerdings nicht passen, befürchte ich.
Aber gut. Die Vorteile überwiegen deutlich. ¯\_(ツ)_/¯

Puuuhhh... Das ist definitiv kein Browserproblem.

Meld dich mal beim STARFACE Support, ASAP:
http://www.starface.de/de/support/index.php

Ich denke das ist was größeres.

Schick am besten direkt die vollständigen Logdateien mit:
https://github.com/sf-janz/sf-debug

Coole Sache.

Drei Anregungen:

• Gruppen haben auch Rechte, sind aber idR nicht interessant. Hier dein SELECT ohne Gruppen:
  http://pastebin.com/yLuDZxcq
• Kennst du die Postrgre-Funktion COPY WITH CSV?
  Beispiel: http://pastebin.com/BKDB0n28
• "Programmausgabe per Copy&Paste in eine lokale CSV-Datei kopieren und diese in der Tabellenkalkulation importieren." Pipen?