Virikas

Most Valued Users
  • Content count

    383
  • Joined

  • Last visited

  • Days Won

    34

Virikas last won the day on August 2

Virikas had the most liked content!

Community Reputation

31 Excellent

About Virikas

  • Rank
    Advanced Member

Profile Information

  • Gender
    Male

Recent Profile Visitors

1,253 profile views
  1. Swyx in eigener DMZ installieren

    --> https://www.swyx.de/produkte/support/wissensdatenbank/artikel-details/swyxknowledge/kb4498.html Neuere Version habe ich auf die schnelle nicht gefunden. Doch geht sie, sofern notwendig. Wo es nicht notwendig ist ergibt sich das automatisch aus dem Protokoll. Genannt in dem PDF sind immer die Listening Ports des jeweiligen Systems (bzw. Prozesses). Wenn der SwyxServer (Dienst) also auf für Audio auf Port 51000-51499 UDP hört(!) ist damit eben klar, dass Clients die Audio zum SwyxServer senden eben mit Destination Port 51000-51499 senden. Da nimmst du nun den Client dazu und findest SwyxIT mit Port 60000-60100 UDP als listening Port für Audio. Anderes Beispiel: SwyxIT registriert sich aktiv per SIP (u.a.) am SwyxServer. Ergo ist die initiale Verbindungsrichtung logischerweise SwyxIT --> SwyxServer (Dienst) Das ist sicherlich nicht optimal dargestellt in Textform und eine Netzskizze wäre vermutlich übersichtlicher, aber die nötigen Infos sind alle öffentlich verfügbar. Ich gebe hierbei aber nochmal zu bedenken, dass Swyx nach wie vor der Ansicht ist, dass eine Firewall zwischen Swyx Client (Hard wie Softphone) und SwyxServer (Diensten) kein supportetes Szenario ist. Swyx macht es sich hier halt einfach und sagt "wenn Firewall dazwischen dein Problem". Genau dasselbe wie mit der hoffnungs veralteten Ansicht "kein Virenscanner auf dem Swyxserver", der aber nach wie vor von Swyx so propagiert wird (IMHO ist das eigentlich schon Anstiftung zu einer kriminellen Handlung ) Falsch. Du vergisst einen Call SwyxIT <-> SwyxPhone bei dem du dank Mediarelease einen direkten RTP Stream zwischen den beiden Voice Endpunkten hast. Lokales AD für den Swyxserver aufsetzen --> OneWay Trust zur eigentlichen Domäne (swyx.local vertraut mycompany.de) Euer IT Sicherheitskonzept ist ziemlich veraltet und sollte überarbeitet werden. Physikalische Trennung ist selbst im Bankensektor ein wenig 2000
  2. Systemtelefon-Lizenzen

    Wie viele findest du im Serverlog (suche nach LicensePrintCount) oder per Perfmon im Serverdienst. Für das "welche" gibt es keine mir bekannte Möglichkeit.
  3. CallControl, Verschlüsselung

    korrekt.. Wenn du nur in der Swyx Konfiguration die Verschlüsselung per User oder global deaktivierst bezieht sich das nur auf RTP. Daher ja auch "undokumentierte Registry Keys" mit denen das gehen könnte. Halte ich für das gegebene Ziel zwar für den falschen Ansatz, aber nun gut, der OP möge tun, was der OP tun will. Ist ja sein System
  4. CallControl, Verschlüsselung

    SwyxConnect <-> Swyx ist SIP Allerdings macht das Ding ggf. lokales Mediarelease, so dass du hinsichtlich Trunkrecording dann auf der Swyx wieder nichts davon siehst, da der Media Stream zwischen Client und Swyxconnect läuft. Zum Thema TLS abschalten, gäbe es vermutlich "undokumentierte Registry Schlüssel". Hätte da sogar eine konkrete Idee. Die sind aber wie gesagt undokumentiert Heisst wenn du sie haben willst, wende dich dazu an deinen Swyx Distri. Alternativ schmeiss das ISDN gelumpe Weg und geh auf einen SIP Trunk. Dann hast du zumindest die externen Calls die über den Server laufen.
  5. CallControl, Verschlüsselung

    Und wo steht da was von "nur bei physischem Swyx Server"? Und weiterhin: Was spricht gegen SwyxReord auf Trunkebene, außer dass es logischerweise nur bei externen Rufen funktioniert?
  6. CallControl, Verschlüsselung

    Call Control ist TLS verschlüsselt. An den private Key der Verschlüsselung kommst du nicht ran (somit kein decodieren in Wireshark möglich). Abschalten geht ebenfalls nicht. Du kannst dir aber sehr detailiert ansehen, was zwischen Telefon und Server passiert. Die PhoneMgr Tracelog Datei ist dein Freund an dieser Stelle. Die Konfiguration "Verschlüsselung" bezieht sich ausschließlich auf RTP.
  7. Warte/Haltemusik pro Standort ?

    Kurze Antwort: Nein, geht nicht
  8. SwyxWare und SIP (PJSIP) ... Geht nur ab und zu

    Aufgrund der ganzen anonymisierungen die du Vorgenommen hast, ist es etwas schwer das zu lesen. Dein PJSIP Client ist 10.10.10.10 mit User Zabbix? Wer ist die 21 die gerufen wird? Ein Callrouting User? Da das 404 vom Swyxserver (123.123.123.123) gesendet wird, solltest du es aber zumindest das im IPPbxSrv Trace finden.
  9. HIDE NUMBER

    Is your provider within the list of tested/certified Swyx SIP providers? In that case you might file a support request to your Swyx distributor, so that he can doublecheck what's going on. If your SIP providers is not tested, you will have to find out what your Swyx configuration does differently from what your provider expects. This can only be done via looking on both sides and therefore you'll need to talk to your provider.
  10. Web Extension und Google Maps

    Du kannst die verwendete Version des embedded Internet Explorer per Applikation steuern. Standard ist IE 7, du kannst aber bis IE 11 hochgehen. HKEY_CURRENT_USER\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION bzw. HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION Da einen DWORD mit dem Namen der .exe für die du eine andere Version brauchst anlegen und mit dem passenden Wert hinterlegen. Quelle: https://msdn.microsoft.com/en-us/library/ee330730(v=vs.85).aspx#browser_emulation Value Description 11001 (0x2AF9 Internet Explorer 11. Webpages are displayed in IE11 edge mode, regardless of the declared !DOCTYPE directive. Failing to declare a !DOCTYPE directive causes the page to load in Quirks. 11000 (0x2AF8) IE11. Webpages containing standards-based !DOCTYPE directives are displayed in IE11 edge mode. Default value for IE11. 10001 (0x2711) Internet Explorer 10. Webpages are displayed in IE10 Standards mode, regardless of the !DOCTYPE directive. 10000 (0x02710) Internet Explorer 10. Webpages containing standards-based !DOCTYPE directives are displayed in IE10 Standards mode. Default value for Internet Explorer 10. 9999 (0x270F) Windows Internet Explorer 9. Webpages are displayed in IE9 Standards mode, regardless of the declared !DOCTYPE directive. Failing to declare a !DOCTYPE directive causes the page to load in Quirks. 9000 (0x2328) Internet Explorer 9. Webpages containing standards-based !DOCTYPE directives are displayed in IE9 mode. Default value for Internet Explorer 9. Important In Internet Explorer 10, Webpages containing standards-based !DOCTYPE directives are displayed in IE10 Standards mode. 8888 (0x22B8) Webpages are displayed in IE8 Standards mode, regardless of the declared !DOCTYPE directive. Failing to declare a !DOCTYPE directive causes the page to load in Quirks. 8000 (0x1F40) Webpages containing standards-based !DOCTYPE directives are displayed in IE8 mode. Default value for Internet Explorer 8 Important In Internet Explorer 10, Webpages containing standards-based !DOCTYPE directives are displayed in IE10 Standards mode. 7000 (0x1B58) Webpages containing standards-based !DOCTYPE directives are displayed in IE7 Standards mode. Default value for applications hosting the WebBrowser Control.
  11. vom admin blockiert ...Meldung

    Und um diese (falsche) Antwort zu posten holst du einen Thread aus Ende 2016 wieder hervor? Ich bin verwirrt
  12. Ruf vom Admin untersagt ist hier leider swyxseitig mehrdeutig belegt. Das offensichtliche "keine Auslandscalls auf Swyx erlaubt" hast du schon abgedeckt. Weniger offensichtlich ist, dass auch "not allowed" Meldungen auf der SIP Trunk Seite vom Provider kommend gern mal von Swyx in exakt dieselbe Fehlermeldung übersetzt werden. Das findest du nur heraus, indem du dir für den betreffenden Call das LinkMgr Tracefile ansiehst und guckst, was da an Fehlermeldung vom SIP Trunk Provider kommt.
  13. [Frage] Swyx ConfRoom

    Ohne Gewähr, aber ich meine gehört zu haben, dass es sich um handelt. Falls dem so sein sollte, dann gilt natürlich das, was in obigem Thread gesagt wurde. Falls nicht, hab ich nix gesagt
  14. Aktive Rufe

    Bei uns 100% SIP mit eigenen SIP Trunks, von daher kann ich für uns ISDN ausschließen.
  15. Aktive Rufe

    Klappt nur leider in längst nicht allen Fällen. Hängt scheinbar auch ein wenig daran wie lang genau die Calls da schon festhängen. Dazu gibt es auch noch den Fall, dass Calls nur in der Adminkonsole hängen, aber im Server selbst nicht bekannt sind. Weder in den Perfon Statistiken noch in den Servertraces....