jodost

Damit: 
https://www.mirage-systems.de/de

In der Trunk group gibt es einstellmöglichkeiten, wie die Rufnummern signalisiert werden. Da musst du dann kanonisch. Ohne plus auswählen

Du kannst ein CallRouting bei jedem User anlegen "wenn Anruf von zentrale, dann: zustellen auf eigentliches Ziel" und das in der Reihenfolge vor den Umleitungen platzieren.
 
Alternativ, weil es sich vielleicht einfacher automatisieren lässt: Für jeden betroffenen User eine 1-Mann-Gruppe anlegen und die anrufen lassen. Für Gruppenrufe greifen keine CallRoutings (Umleitungen)

Meine erste Empfehlung waren auch die WebExtensuins, ja.
 
Funktionsweise:
- Du definierst eine Art "iframe"-Bereich innerhalb deiner Skin
 
- Du definierst verschiedene Trigger, wann da was passieren soll. Z.B. bei ankommenden Anrufen, bei abgehenden, beim bloßen Abheben einer Leitungstaste, beim Auflegen (das beantwortet Deine Frage), ... 
 
Anwendungszwecke zB:
 
- Anzeige von Infos zum Anrufer aus einem CRM (welcher Kunde ist das etc)
 
- oder aus einem internationalen Firmen-Adressbuch (UN Campus in Bonn hatte in deren SwyxIt dann das weltweite UN-Adressbuch eingebunden)
 
- Zentrales Sekretariat bekommt angezeigt, was sie zur gerufenen Nummer wissen müssen (also mit welchem Firmennamen sie sie melden sollen etc)
 
- neben den Besetztlampen wird auch ein Statustableau einer Zeiterfassung eingeblendet, so dass man nicht nur sieht, ob ein(e) Kollege/in erreichbar ist, sondern auch zB warum nicht (Feierabend, Mittagspause)
 
- Tracking. Der Webserver bekommt ja jedes Event mit und kann zB erfassen, welcher Mitarbeiter an welchen Anruf rangegangen ist,  wie lange der Anruf gedauert hat usw und so direkt ein CRM füllen
 
Nachteil der WebExtension:
- die Darstellung ist manchmal etwas zickig bzgl aktuellen Webtechniken
 
- funktioniert nur auf dem Windows-Client 
 
- und darum auch "unklare Zukunft"
 
 
Vorteil der WebExtension:
 
- erfordert nur minimales Swyx-KnowHow, ist aber ansonsten eine Standard-Anwendung (Web-Anzeige dürfte wohl mit das einfachste sein, was ein CRM-Anbieter kann)
 
- entsprechend ist es auch vergleichsweise unkompliziert anzupassen, wenn Ihr mal das CRM wechselt
 
- oder umgekehrt, wenn man von der Swyx mal irgrndwann weggeht - URL aufrufen können andere Telefonanlagen auch, d.h. auch hier ist es halbwegs unkompliziert 

Ah Mist, zu langsam.
 
Gruppenanrufe auf Mobiltelefone kannst Du elegant nur lösen über CTI+-mit-externer-Rufnummer oder den alten Mobile Extension Manager (Mobile Erweiterung, im gleichen Dialog wie der Parallelruf). Erfordert aber beides zusätzliche Lizenzen
 

Du müsstest es mit dieser Variable abfragen können: 
 
 
(Und die dann einfach vergleichen, wenn sie nicht gleich 49 ist wurde offenbar was anderes gewählt).
 
Allerdings bin ich irritiert, dass es bei diesem Kollegen klingelt. Denn beim wählen mit f11 wird doch immer die amtsgrenze vorgewählt, das heißt er müsste 0- 49221... wählen, oder nicht?
 
Und wenn das der Fall ist, kannst du versuchen, die Täter in einen Standort zu verschieben, bei dem du als ortsvorwahl 00 einträgst. Wenn die das dann so wählen, hält die Swyx das für ein ortsgespräch nach 49221, setz die Vorwahl des Ortes, also 00 davor, und wenn du Glück hast wäre er dann sogar richtig.

Ich muss halb zurückrudern und halb dir eine andere Lösung anbieten
 
Ich habe gerade noch mal nachgelesen, was ich bei einem Kunden in Erinnerung hatte. Da ruft das SwyxIT keine Kommandozeilen-Aufrufe auf, sondern einen speziellen keasy://-URL-Handler, den die Software registriert hat. 
 
Das müsste aber auch mit Powershell möglich sein - https://stackoverflow.com/questions/40596463/custom-protocol-handler-via-powershell-script
 
Dann registrierst du dir das protocol busylight für dein Powershell Script und rufst dann in der WebExtension auf: busyligz://on oder busylight://off
 
Alternativ bin ich beim googlen nach keasy auf folgendes gestoßen, was ohne Skins auskommt - vielleicht kannst du damit was basteln (aus dem VBScript heraus Systemaufrufe - und damit auch PS - sollten ja kein Problem sein): 
 
 
 

Genau. Aber auf dem Privatrechner den RemoteConnector verwenden (ggf zuvor serverseitig konfigurieren lassen), damit kann sich das SwyxIT auch ohne VPN verbinden.
 
 
Auch dafür gibt es etwas besseres: CTI+ (setzt evtl. zusätzliche Lizenz voraus) mit externer Rufnummer. Ist im Prinzip wie eine Rufumleitung, nur dass wirklich alles umgeleitet wird und du das Gespräch weiterhin im SwyxIT steuern kannst.
 

Mein o.g. Tool ist schon was älter und war in der Form nicht mehr nutzbar. (Das lag weniger am Tool, sondern daran, dass das auf unserer Firmenseite mit https-only war, und die aktuellen Browser sich querstellen, von einer https-Webseite aus per http Kontakt mit den Unify-Geräten aufzunehmen.
 
Ich habe es daher mal umgebaut, so dass es wieder funktioniert. Und direkt mit einer Kindersicherung (man braucht ein Passwort, das man aber als Swyx-Partner kennen wird) versehen, so dass ich der Einfachheit halber den neuen Link poste:
https://vollzeitnerd.de/tools/unify-firmware
 
 

Vielleicht hilft es ja jemanden:
 
Wir haben inzwischen auf unseren Swyx-Installationen ein kleines Script, das als scheduled task 1x am Tag bei allen neu hinzugekommenen Nutzern ein RemoteConnector-Zertifikat anlegt. Einerseits ist das lästig, dass das nicht direkt beim Anlegen des Users abgefragt wird - Kunden vergessen das das schon mal gerne, wenn sie selbst User anlegen. Andererseits haben wir Installationen, wo die Kunden das Zertifikats-Passwort gar nicht kennen (sollen), aber trotzdem User anlegen. Beides ist jetzt kein Problem mehr, das Zertifikat kommt automatisch:
 
Import-Module IpPbx Connect-IpPbx $securestring = ConvertTo-SecureString -AsPlainText "XXXHierDasPasswortEintragenXXX" -Force $user = get-ippbxUser foreach ($u in $user) { if ($u.CertificateThumbprint.length -lt 3 ) { Write-Host $u.name "bekommt ein neues Zertifikat:" $cert = New-IpPbxClientCertificate -UserEntry $u -RootPassword $securestring -Confirm:$false echo $cert.Thumbprint } else { Write-Host $u.name "in Ordnung" } } Disconnect-IpPbx  

Dein erstes Problem war ja, dass du die Telefone mit SIP Firmware bekommen hast, aber für die Swyx HFA brauchst. Diesen Firmware-Tausch kann die SwyxPhone-Suche nicht, und per DHCP geht das m.W. auch nicht. Am sinnvollsten wäre also, du würdest die Telefon zukünftig mit HFA Firmware bestellen - wenn das nicht möglich ist, melde dich gegebenenfalls PN, ich habe da eine Lösung.
 
Den reinen Swyx-Server kannst du per DHCP ausrollen (m.W. geht das noch), ebenso wie den NTP. Dann sollte der Rest von selber gehen.
 
Wenn Du das nicht möchtest und die Telefone unbedingt in deinem Labor vorbereiten willst: Telefon dort anschließen, SwyxPhone-Suche auf das IP-Netz dort starten, fertig. Dann bringst du das Telefon zum eigentlichen Standort, dort bekommt es alle lokalem Parameter (IP, DNS, Gateway) per DHCP und alle unternehmensweiten Parameter (z.b. SwyxServer) bleiben ja erhalten.
 
Letzter Vorschlag: Wir haben für uns eine Art SwyxPhone-Suche, Autoprovisioning, Firmware von SIP auf HFA oder zurück uvam selbst programmiert (für unsere VPN-losen Produktvarianten des Swyx-Hostings, wo dann unify mit SIP zum Einsatz kommt). Das Know-how ist da, ich kann dir also gerne auch ein für Dich angepasstes Tool bauen, wo du nur mit einem Klick den jeweiligen Standort auswählst und der sucht das dortige Netz ab, ändert die Firmware von SIP auf HFA und konfiguriert das Ding. Machbar ist das und der Aufwand hält sich wahrscheinlich auch in Grenzen, aber um das klar zu sagen: Nötig ist das nicht.

As far as I know, you need to setup a session border controller that helps the device connecting from outside.
 
The only "new" thing compared to older versions is
 
- that Yealink uses SIP, where the unify devices use CorNet.IP (I do not know about any session border controller that can handle CorNet.IP)
 
- that with SwyxWare 12.1, they only use port 5060 (Yealink connected to SwyxWare 11.x also uses port 65012 for uaCSTA) that makes SBC configuration a bit easier.
 
But anyway, it is far away from "plug and play" or worth calling it a feature.
 
And, to be honest, I would really think about using inexpensive VPN components instead. If you configure your SBC to use port 5060 into the internet, your SwyxServer will be INVITEd into fraudulent calls within hours, so don't forget to configure security features like fail2ban, geo-IP-blacklists, .... If you want to change the port to somewhere else, this may collide with the AutoProvisioning of Swyx - once you change any account setting on the Yealink manually, the device will not longer accept account settings via AutoProvisioning any more. There are some ugly ways to force Swyx' AutoProvisioning to deploy your own settings, but they are ugly ways and nothing officially supported. So in both ways, you will get in trouble if you update the server to a newer version and Swyx has changed everything (like they did on 12.0->12.1) without giving any information to the partners.
 
If you keep all of this in mind, I does work. We use this on our HostedPBX VPNless-offer, but the work we spend to figure out all all problems, bugs, ... is nothing I want to do if you are just talking about one single PBX.
 
Hope this helps

You have chosen the right way, this is how I use it in some setups 
 
Please check SIP settings on the door phone, maybe you can configure/allow "inband" as DTMF transportation type.
 
Second way is some kind of http Api request to the door phone, some vendors (e.g. my preferred one, Doorbird) allow this.

The SwyxIT! Client has different line keys. You can configure them (by clicking the right mouse key) to handle inbound calls, e.g. first line = personal DDI, second line = group 123, third line = group 234 (or also "all group calls").
 
Once this is done, you can right-click the line and lock or unlock it. No incoming calls will arrive on a locked line, and if there is no line left where the group call can arrive (because all other lines are configured to other numbers), it won't ring.

Ich will nicht mal ausschließen, dass man die inzwischen vielleicht doch weglassen kann ... aber wir setzen die seit >10 Jahren sonst geht nix.
 
 
Vielleicht bekommst Du es ja hin, dass der Zugriff auf dem RemoteConnector-Host intern geroutet wird?
 
 
Da bin ich jetzt auswendig überfragt wonach Du filtern musst - aber mit klassischem SIP Filter wirst du da nicht weit kommen...

stimmt, jetzt wo ich Deine Aussage lese, kommt mir die 13 auf einmal bekannt vor. Da bin ich bei Dir.
 
Ändert am Zeitrahmen nichts, 2. Halbjahr. Aber je nach Lizenztyp natürlich relevant wg. Update-Lizenzen.

$User = get-ippbxuser | ForEach-Object { add-member -MemberType NoteProperty -Name "DeviceList" -InputObject $_ -Value($adminfacade.GetCurrentUserDevices($_.UserID)) -PassThru } | select -Property Name -ExpandProperty Devicelist | select -Property Name, strName, strIPAddress, strMACAddress, dLoginTime

Was genau möchtest Du jetzt hören? Ja ich weiss von Kunden, dass sie das so benutzen - ich habe es dann jeweils nur kurz gesehen, aber da in diese Richtung seit Jahren keine Probleme gemeldet werden, scheint das  wohl zu funktionieren.

$User = get-ippbxuser | ForEach-Object { add-member -MemberType NoteProperty -Name "DeviceList" -InputObject $_ -Value($adminfacade.GetCurrentUserDevices($_.UserID)) -PassThru } | select -Property Name -ExpandProperty Devicelist | select -Property Name, strName, strIPAddress, strMACAddress, dLoginTime