Hallo,
gibt es hier schon Neuigkeiten?
Würde mich auch interessieren.
Wir haben ebenfalls das Problem, dass Namen aus dem Privaten Telefonbuch nicht angezeigt werden.
Bei uns ist es sogar so, dass Namen aus Kontakten von Outlook teilweise nicht angezeigt werden.
Konnten die anderen die dieses Problem auch hatten es irgendwie beheben?
Die Anlage und Telefone befinden sich in einem eigenen Vlan, getrennt vom restlichen Netzwerk. Telefon-->Starface-->Firewall
Hallo Fabian
Ich habe es gerade in Wireshark getestet.
bei den erfolgreichen Versuchen höre ich mich und die Gegenstelle.
Bei dem fehlgeschlagenen Versuch hört man nur die Gegenstelle.
MfG
merkurfrucht
1. Anruf ohne Probleme
2. Anruf keiner der Teilnehmer kann den anderen hören
In diesem Fall ist es eine Gruppe in der iFMC zu besonderen Zeiten genutzt wird.
Es betrifft aber auch einzelne Benutzer, weshalb ich iFMC, Gruppenzugehörigkeit oder auch Modul als Ursache ausschließen würde.
Ich muss die Aussage "beim ersten Versuch wird die Verbindung mit abnehmen des Hörers unterbrochen", korrigieren.
Die Verbindung scheint zu bestehen nur kann weder der Anrufer noch der Angerufene den anderen nicht hören.
Beim zweiten Versuch, direkt nach dem auflegen gibt es keine Probleme.
Die Frage ist wird das überhaupt als Fehler erkannt und als solcher protokolliert.
Hallo Kreuzer,
hier ist ein Auszug aus dem Support-Log.
[2020-10-05 09:44:44,108] [1600] ********* Call created *********
[2020-10-05 09:44:44,108] [1600] Starting call routing : SIP/+******-000014b2|1601883884.5357 dial number ****** CallerId <******>
[2020-10-05 09:44:44,108] [1600] Incoming call from line TelekomSIP(2019)
[2020-10-05 09:44:44,109] [1600] Found extension on line TelekomSIP(2019) ******
[2020-10-05 09:44:44,114] [1600] Relevance check in "******" on callstage onAllIncomingCalls
[2020-10-05 09:44:44,114] [1600] Relevance check in "******" on callstage onAllIncomingCalls
[2020-10-05 09:44:44,114] [1600] Relevance check in "******" on callstage onAllIncomingCalls
[2020-10-05 09:44:44,114] [1600] Relevance check in "******" on callstage onAllIncomingCalls
[2020-10-05 09:44:44,114] [1600] Relevance check in "******" on callstage onAllIncomingCalls
[2020-10-05 09:44:44,115] [1600] Relevance check in "******" on callstage onAllIncomingCalls
[2020-10-05 09:44:44,115] [1600] Relevance check in "******" on callstage onAllIncomingCalls
[2020-10-05 09:44:44,115] [1600] Relevance check in "******" on callstage onAllIncomingCalls
[2020-10-05 09:44:44,116] [1600] Routing call " <******>" to number ****** over service RingAllGroupService
[2020-10-05 09:44:44,116] [1600] CallLeg 3a316bcb-b7ef-4103-91ff-d1ff6527a266
[2020-10-05 09:44:44,147] [1600] Sending push request: {"service":"apns","token":"9cfba29a7adbb2f42020cc7b0b97c552b99628a60c6d1acf4958e0b115f8554b","callId":"7258550b-40de-4505-8b3e-252c42497e40","content":"l8AnsM88RXiCbJWZL2Lb2w==:tSFAD1kbLyQGrz3tevGiozHxa8pATLUfATx/CLT4tttqyHJqeP+/AcyPpL3NJvQ6Y8ubNHiUVmHBple3HOnII76VjXgIqhVX+1hBXsMGZdU="}
[2020-10-05 09:44:44,150] [1600] Sending push request: {"service":"","token":"","callId":"80ec4b11-4c93-41a3-84c4-978dd04bb152","content":"+A3nA0Dp529GlKKDpLXVTw==:vkedercBymm6dPcmcPCrAjH0dX/9dd8MRrUFatY2L2PTX2JOcpPrVf9vIHyTz3CCT6lS3JPYSj5JiAFuqf0s+jgnW6igTRrFLpGYUuclVZo="}
[2020-10-05 09:44:44,203] [1600] Sending push request: {"service":"","token":"","callId":"80ec4b11-4c93-41a3-84c4-978dd04bb152","content":"+A3nA0Dp529GlKKDpLXVTw==:vkedercBymm6dPcmcPCrAjH0dX/9dd8MRrUFatY2L2PTX2JOcpPrVf9vIHyTz3CCT6lS3JPYSj5JiAFuqf0s+jgnW6igTRrFLpGYUuclVZo="} returns code 400
[2020-10-05 09:44:44,203] [1600] Removing dial request
[2020-10-05 09:44:44,218] [1600] Dial SIP/+******-000014b2 to SIP/224.******.ylnkt46s-000014b3
[2020-10-05 09:44:44,219] [1600] Dial SIP/+******-000014b2 to SIP/225.******.ylnkt46s-000014b4
[2020-10-05 09:44:44,220] [1600] Dial SIP/+******-000014b2 to SIP/1073.******-000014b5
[2020-10-05 09:44:44,220] [1600] Dial SIP/+******-000014b2 to SIP/223.******.ylnkt46s-000014b6
[2020-10-05 09:44:44,220] [1600] Dial SIP/+******-000014b2 to SIP/229.******.ylnkt46s-000014b7
[2020-10-05 09:44:44,221] [1600] Dial SIP/+******-000014b2 to SIP/227.******.ylnkt46s-000014b8
[2020-10-05 09:44:44,221] [1600] Dial SIP/+******-000014b2 to SIP/228.******.ylnkt46s-000014b9
[2020-10-05 09:44:44,222] [1600] Dial SIP/+******-000014b2 to SIP/221.******.ylnkt46s-000014ba
[2020-10-05 09:44:44,260] [1600] SIP/229.******.ylnkt46s-000014b7 Channelstate is Ringing
[2020-10-05 09:44:44,278] [1600] SIP/224.******.ylnkt46s-000014b3 Channelstate is Ringing
[2020-10-05 09:44:44,279] [1600] SIP/225.******.ylnkt46s-000014b4 Channelstate is Ringing
[2020-10-05 09:44:44,283] [1600] SIP/223.******.ylnkt46s-000014b6 Channelstate is Ringing
[2020-10-05 09:44:44,285] [1600] SIP/228.******.ylnkt46s-000014b9 Channelstate is Ringing
[2020-10-05 09:44:44,285] [1600] SIP/227.******.ylnkt46s-000014b8 Channelstate is Ringing
[2020-10-05 09:44:44,288] [1600] SIP/221.******.ylnkt46s-000014ba Channelstate is Ringing
[2020-10-05 09:44:44,357] [1600] Sending push request: {"service":"apns","token":"9cfba29a7adbb2f42020cc7b0b97c552b99628a60c6d1acf4958e0b115f8554b","callId":"7258550b-40de-4505-8b3e-252c42497e40","content":"l8AnsM88RXiCbJWZL2Lb2w==:tSFAD1kbLyQGrz3tevGiozHxa8pATLUfATx/CLT4tttqyHJqeP+/AcyPpL3NJvQ6Y8ubNHiUVmHBple3HOnII76VjXgIqhVX+1hBXsMGZdU="} returns code 200
[2020-10-05 09:44:45,317] [1600] SIP/1073.******-000014b5 Channelstate is Ringing
[2020-10-05 09:44:50,474] [1600] SIP/227.******.ylnkt46s-000014b8 Channelstate is Up
[2020-10-05 09:44:50,474] [1600] SIP/224.******.ylnkt46s-000014b3 Hangup Cause: Answered elsewhere
[2020-10-05 09:44:50,475] [1600] SIP/225.******.ylnkt46s-000014b4 Hangup Cause: Answered elsewhere
[2020-10-05 09:44:50,476] [1600] SIP/1073.******-000014b5 Hangup Cause: Answered elsewhere
[2020-10-05 09:44:50,477] [1600] SIP/223.******.ylnkt46s-000014b6 Hangup Cause: Answered elsewhere
[2020-10-05 09:44:50,479] [1600] SIP/229.******.ylnkt46s-000014b7 Hangup Cause: Answered elsewhere
[2020-10-05 09:44:50,480] [1600] SIP/228.******.ylnkt46s-000014b9 Hangup Cause: Answered elsewhere
[2020-10-05 09:44:50,480] [1600] SIP/221.******.ylnkt46s-000014ba Hangup Cause: Answered elsewhere
[2020-10-05 09:44:50,481] [1600] SIP/+******-000014b2 Channelstate is Up
[2020-10-05 09:44:50,481] [1600] SIP/227.******.ylnkt46s-000014b8 Link SIP/+******-000014b2
[2020-10-05 09:44:55,508] [1600] SIP/227.******.ylnkt46s-000014b8 Unlink SIP/+******-000014b2
[2020-10-05 09:44:55,508] [1600] SIP/227.******.ylnkt46s-000014b8 Link SIP/+******-000014b2
[2020-10-05 09:44:57,407] [1600] SIP/227.******.ylnkt46s-000014b8 HangupRequestEvent
[2020-10-05 09:44:57,407] [1600] SIP/227.******.ylnkt46s-000014b8 Unlink SIP/+******-000014b2
[2020-10-05 09:44:57,409] [1600] SIP/227.******.ylnkt46s-000014b8 Hangup Cause: Normal Clearing
[2020-10-05 09:44:57,410] [1600] Got dialstatus DialReturnCodes(hc=NORMAL_CLEARING, ds=ANSWER, cr=UNKNOWN)
[2020-10-05 09:44:57,426] [1600] SIP/+******-000014b2 Hangup Cause: Normal Clearing
[2020-10-05 09:44:57,426] [1600] ********* Call finished *********
-------------------------------------------------------------------------------------------------------------------------------------------------------------
Hallo,
wir haben seit nun mehreren Wochen das Problem, dass eingehende Anrufe von extern erst bei dem zweiten Versuch verbunden werden.
Das Problem tritt nahezu bei jedem Anruf auf, beim ersten Versuch wird die Verbindung mit abnehmen des Hörers unterbrochen.
Ruft der selbe Teilnehmer erneut an, wird das Gespräch normal Verbunden.
Im Call-Routing log taucht folgender Eintrag auf:
[2020-09-30 15:59:54,527] INFO [AGI xxxxxxx-SIP/+xxxxxxxx-0000d521] AsyncAgi d7d154cf-4774-417f-99d3-aa915d1cc20e Dial SIP/1073.N720&SIP/224.xxx.ylnkt46s&SIP/221.xxxx.ylnkt46s&SIP/223.xxxxx.ylnkt46s&SIP/229.xxxxxx.ylnkt46s&SIP/225.xxxxx.ylnkt46s&SIP/228.xxxxx.ylnkt46s&SIP/227.xxxxx.ylnkt46s,15,wWtT
[2020-09-30 15:59:55,756] WARN [AMI HangupEvent] HangupCause Unknown HangupCause with id=26
[2020-09-30 15:59:55,757] WARN [AMI HangupEvent] HangupCause Unknown HangupCause with id=26
[2020-09-30 15:59:55,758] WARN [AMI HangupEvent] HangupCause Unknown HangupCause with id=26
[2020-09-30 15:59:55,759] WARN [AMI HangupEvent] HangupCause Unknown HangupCause with id=26
[2020-09-30 15:59:55,760] WARN [AMI HangupEvent] HangupCause Unknown HangupCause with id=26
[2020-09-30 16:00:04,088] INFO [AGI xxxxxxxx-SIP/+xxxxxxx-0000d521] AsyncAgi execBlocking (d7d154cf-4774-417f-99d3-aa915d1cc20e): of command EXEC Dial "SIP/1073.N720&SIP/224.xxxxx.ylnkt46s&SIP/221.xxxxx.ylnkt46s&SIP/223.xxxxx.ylnkt46s&SIP/229.xxxxxx.ylnkt46s&SIP/225.xxxx.ylnkt46s&SIP/228.xxxx.ylnkt46s&SIP/227.xxxxx.ylnkt46s,15,wWtT" returned -1
[2020-09-30 16:00:04,088] INFO [AGI xxxxxx-SIP/+xxxxxxx-0000d521] AsyncAgi getChannelVariable (d7d154cf-4774-417f-99d3-aa915d1cc20e): HANGUPCAUSE -> null
Wir wären für jeden Tipp dankbar.
Hallo,
seit dem letzten Update gibt es nun die Mögloichkeit ein Häckchen zu setzen bei "Chat-Status auf 'Abwesend' stellen, wenn ich einen Termin in Outlook geplant habe".
Leider sehen diesen Eintrag viele unserer User nicht.
Auf meinem Client kann ich diesen Punkt sehen, bei vielen anderen gib es diesen Eintrag nicht.
Wir haben alle den aktuellsten UCC Client 6.7.11.194 drauf.
Tragisch ist das erst mal nicht, weil sich die Einstellung auch über den Expertenmodus ändern lässt, aber seltsam finde ich dies dennoch.
Hat hierzu jemnd eine Erklärung?
Das hab ich überlesen.
Danke für die Antwort
Gibt es für Version 6.7.1.x schon ein Releasedatum?
Für uns ist das Outlook Plugin dadurch erst mal nicht nutzbar, was echt schade ist.
Die Frage ist, warum diese Abfrage eine so große CPU Last auf dem Exchange verursacht?
Läuft da der UCC Client in einen Fehler oder was kann dafür verantwortlich sein das es diese massenhaften Einträge im Logfile C:\Program Files\Microsoft\Exchange Server\V15\Logging\MapiHttp\Mailbox gibt?
Könnte es was bringen den Kalender aufzuräumen oder pfüft das Plugin ohnehin nur den aktuellen Tag?
Könnte es dammit zusammenhängen, dass eininge Benutzer mit einem geeminsamen Postfach arbeiten und teilweise auch mit mehreren Postfächern verbunden sind?
Hat hier irgendjemand noch eine Idee oder einen Tipp?
Danke Wolfgang, das ist ein guter Hinweis.
Kann man dieses Verhalten unterbinden?
Es bringt also nichts wenn der Harken bei "Chat Status auf Abwesend stellen, wenn ich einen Termin in Outlook gespeichert habe" im UCC Client entfernt wird?
Hallo,
Seit unserer Umstellung von Exchange 2010 auf Exchange 2016 verursacht der Prozess w3wp.exe auf dem Exchange 2016 alle 15 Minuten eine hohe CPU Last.
Teilweise ist die Last so hoch, dass bei den Anwender Outlook 2016 hängt und nicht mehr bedienen lässt. *
In diesem Zeitraum schreibt der Prozess w3wp.exe massenhaft Einträge in die Logfiles unter C:\Program Files\Microsoft\Exchange Server\V15\Logging\MapiHttp\Mailbox.
Wir haben das Add-In "Starface Outlook Connector" in Outlook deaktiviert und die CPU Spitzen der w3wp.exe waren nicht mehr zu sehen.
Hat jemand schon ähnliche beobachtungen gemacht und kann uns jemand ein Tipp geben wie wir das in den Griff bekommen?
Wir würden den Connector gerne wieder aktivieren, aber mit diesem Verhalten ist das für die Anwender leider nicht zumutbar.
Bei uns im Einsatz Starface Server Version 6.7.0.22, UCC Client Version 6.7.0.180, Office 2016, Windows 10, Citrix unter Windows Server 2016.
Das Problem war auch schon mit älteren Versionen vom Starface Server und UCC Clietn vorhanden.
Wir wären für jeden Tipp dankbar.
Hallo,
Dieses Problem können wir bestätigen.
Bei uns tritt das oben beschreibenen Verhalten leider auch auf.
Unsere Mitarbeiter werden morgens aus dem Bett geklingelt, obwohl Sie die Telefon Funktion in der iOS App am Abend davor deaktiviert hatten.
Hallo zusammen,
wollte mal nachfragen wie es bei euch mittlerweile mit diesem Prioblem aussieht.
Wir haben diese schwierigkeiten unter Android mit dem aktuellen Mobile Client nämlich noch immer.
Die App hängt sich immer wieder in unregelmäßigen abständen auf, ist inaktiv obwohl haken gesetzt sind.
Wir müssen mehrmals täglich die App beenden und wieder starten damit sie wieder funktioniert.
Der Mobiel Client macht uns aktuell unter Android keinen Spaß.
Ist das bei euch auch so, oder ist da auf unserem System noch irgendwo der Wurm drin?
Danke für euer Feedback.
Schon mal ganz gut zu wissen das wir nicht die einzigen mit diesem Problem sind.
Das Problem tritt bei uns selten auf und es ist schwer irgendeine parallele zu entdecken.
Wir hatten das Problem aber mittlerweile sowohl auf den Iphones als auch auf Android.
Wir hatten es bei internen wie auch externen Gesprächen.
Ein Wechsel des APs kann ich eigentlich so gut wie sicher ausschließen (Sitze im Großraumbüro und bin immer mit dem selben AP verbunden)
Habt Ihr noch Ideen was wir tun können um die Ursache dieses Problems zu finden?
Hallo zusammen,
wenn der Benutzer einen Anruf bekommt klingelt sowohl das Tischtelefon (Yealink T46S) als auch das Mobiltelefon über Mobile Client.
Wenn das Gespräch über das Tischtelefon angenommen wird, klingelt gelegentlich das Mobiltelefon einfach weiter bis der Anruf am Tischtelefon wieder beendet wird.
Handelt es sich hierbei um ein Bekanntes Problem?
Konnte bisher keinen entsprechenden Eintrtag im Forum finden und hoffe das ich hier Tipps bekomme was ich machen kann.
Unsere Umgebung:
Starface Server: 6.6.0.10
Mobile Client Version: 6.6.0.26 Bild 298
Android Version 9.0
Bin für jede Hilfe dankbar.
