Posts by L0g333

    Hallo zusammen,

    vielen Dank für eure Antworten und entschuldigt die späte Rückmeldung. Komme momentan leider nicht dazu hier regelmäßig vorbeizuschauen

    L0g333: Ich würde WLAN also mal ausschalten und dann das Verhalten beobachten.

    Wie erwähnt haben wir das bereits getan. Die Probleme scheinen lt. Kundenaussage auch bei deaktiviertem WLAN auf dem Smartphone und durchgängig 4G / 5G Empfang im Home-Office nicht besser/schlechter zu sein.

    Aber richtig der Verweis insofern, dass diese Apps OPUS als Codec verwenden. Dieser kann ebenfalls auf STARFACE Anlagen aktiviert werden und führt zu einer höheren Robustheit der Verbindungen: https://knowledge.starface.de/display/SWD/Al…E+konfigurieren
    Das könnte bei den o.g. Themen ebenfalls helfen.

    Ebenfalls bereits aktiviert. Ich empfinde auch, dass es besser geworden ist. Aber nichts desto trotz gibt es regelmäßig Anrufe oder Verbindungen die nicht zustande kommen.


    Zuletzt gibt es natürlich immer auch die Möglichkeit, parallel Anrufe über ifmc per GSM zustellen zu lassen. ifmc einfach mit 10 Sekunden Verzögerung einstellen. Dann klingelt zuerst die App und man kann den Call dort annehmen. Sollte die App nicht aktiv sein oder die Daten-Verbindung gerade gestört sein, kommt der Call ein paar Sekunden später per GSM rein. So geht kein Call verloren.


    Das kann man machen. Erzeugt allerdings zusätzliche Kosten für eine ggfs. notwendige Erweiterung der Rufkanäle (Der Verweis auf STARFACE Connect ist hier auch nicht unbedingt hilfreich) und Gebühren für Anrufe ins Mobilfunknetz (falls keine Flat vorhanden ist).


    Insgesamt ist das Thema STARFACE App auf dem Smartphone ein für uns äußerst frustrierendes Thema. Wir haben bisher bei jedem Projekt, bei dem das Softphone in der STARFACE App ein "Must Have" Feature war, Probleme und geraten anschließend in Erklärungsnot. Unser Vertrieb weist hier mittlerweile darauf hin, dass die App ein Nice to Have Feature ist, aber keineswegs eine verlässliche Alternative für ein Tischtelefon oder das Softphone am Windows PC / MAC.

    Hallo Aaron

    Hallo L0g333,

    ich versuche hier an dieser Stelle etwas Kontext beizusteuern.

    Danke. Das sind für mich hilfreiche Infos! :)



    - die App für Android ist dauerhaft mit dem Server verbunden. Dadurch sind Daten- und Akkuverbrauch zwar höher, aber im Normalfall sollte der Aufbau eines Anrufs hier sehr schnell gehen. Hier gilt es im Ernstfall eher zu analysieren, ob die App den letzten Verbindungswechsel gut verkraftet hat.

    Die meisten unserer Kunden verwenden iPhones. Bei einem Kunden bei dem wir jedoch die schwerwiegendsten Probleme haben (24/7 medizinischer Notdienst), hat der Key User ein Samsung Galaxy Note 20 Ultra. Dort werden einfach 50% der Anrufe nicht signalisiert. Hierzu hatte ich auch schon ein Ticket beim Support (Call#6982458; damals noch mit SF 6.7) und nach ewigem Hin- und her, Log-Files, TCP Dumps etc. war das Ergebnis: Wir können nicht alle Handys supporten.

    Das Problem besteht leider weiterhin - auch ein halbes Jahr später mit der SF 7.1 (Server- wie Clientseitig). Der Anwender hat von mir auch die Empfehlung erhalten, nach einem Netzwechsel (Mobilfunk <-> WiFi) die App komplett zu beenden und neu zu starten bzw. sich ab- und anzumelden. Er hat beides jeweils alleine und auch in Kombination getestet. Die Probleme bleiben bestehen.


    In beiden Fällen ist aus Neugier (v.a. als Partner) ein Blick in das Log lohnenswert, Verbindungsfehler werden durch sehr gut sichtbare Exceptions protokolliert.

    Immer und jederzeit. Vielleicht hätte ich erwähnen sollen, dass ich die Logs schon mehrfach durchsucht habe, aber bisher noch nicht vorwärts gekommen bin. In keinem der genannten Problemfälle. Ich rolle mal einen Fall von heute auf.

    Ich bin heute im Home-Office und telefoniere bewusst nur mit der iPhone App. Nun hatte ich vorhin das Problem, dass ich mit einem Kollegen telefoniert hatte. Nach etwa 1 min war plötzlich das Gespräch weg (zuvor hatte ich problemlos diverse Telefonate bis zu 40 Min geführt). Mein iPhone XS Max (iOS 15, SF App 7.1.0) war durchgehend mit dem WLAN verbunden.
    Der Kollege hat anschließend nochmal angerufen. Ich nehme das Gespräch am iPhone an und es erscheint die Meldung "STARFACE Audio wird verbunden". Die STARFACE App unter Windows klingelt weiter. Nach 10 Sek. ist das Gespräch am iPhone weg. Windows klingelt weiter. Ich habe das Gespräch dort dann abgelehnt und die Logs auf dem iPhone exportiert.

    Aus dem Log geht nach meinem Verständnis nicht klar hervor warum

    Das erste Gespräch beendet wurde
    STARFACE Support-Log

    Code
    [2021-11-24 11:45:11,290] [ 0423 ] Hangup Request Event | SIP/1799.SFiphone-00000161 
    [2021-11-24 11:45:11,291] [ 0423 ] Hangup Cause: NORMAL_CLEARING | SIP/1799.SFiphone-00000161 
    [2021-11-24 11:45:11,292] [ 0423 ] Hangup Cause: NORMAL_CLEARING | SIP/1562.snomd785-0000015e

    Wirkt als würde das Gespräch vom iPhone beendet werden.

    iPhone Support Log

    Code
    2021-11-24 11:45:11.235 STARFACE [1915824] [I] [ProviderDelegate:1034].reportCall(with:endedAt:reason:) - UUID: 678A7067-A687-4F18-A609-1340D80AA818, reason: .remoteEnded
    2021-11-24 11:45:11.239 STARFACE [1915824] [D] [ProviderDelegate:988].removePairs(withCxCallId:) - [:]

    Wirkt als würde das Gespräch von der Gegenstelle und nicht vom iPhone beendet.


    Und auch nicht warum das zweite Gespräch nicht zustande kam
    STARFACE Support-Log

    Code
    [2021-11-24 11:45:15,685] [ 0429 ] Sending push request: for callId ec84192f-60d5-40e3-8694-cb29f440cb44 returns code 200 
    [2021-11-24 11:45:31,476] [ 0429 ] DialEnd with dialstatus BUSY | SIP/1562.snomd785-00000162 -> SIP/1360.snomd785-00000163

    Man sieht den Push Request und dann als ich nach 15 Sek auf dem PC das Gespräch abgelehnt habe. Vom iPhone aus scheint nix an der STARFACE anzukommen.


    iPhone Support Log

    Anruf wird signalisiert. Man sieht das Signal zum Annehmen des Anrufs. Nach 10 Sek "remoteEnded".

    Eine Exception habe ich leider nicht gefunden, auch nicht in dem Log ohne den _support Zusatz im Dateinamen.

    Anbei mal noch die beiden oben zitierten Logs mit den kompletten Gespräch. Wenn jemand etwas sieht, das ich übersehen habe, bin ich über jede Hilfe dankbar!


    Die Probleme mit der nicht-Signalisierung von Anrufen gibt es doch schon ewig..

    Für Kunden die unterwegs auf eine zuverlässige Vermittlung von Anrufen angewiesen sind (z.B. medizinischer Notdienst), ist die App mit Softphone also eigentlich nicht zu empfehlen. Am Ende hängt u.U. ein Menschenleben daran.


    Viele Grüße vom L0g.

    Hallo zusammen,

    wir haben sowohl bei uns, als auch bei nahezu allen Kunden immer wieder massive Probleme mit dem Softphone der STARFACE App auf Smartphones (Android wie iOS). Konkret geht es darum, dass es regelmäßig (aber nicht durchgehend) Probleme beim Verbindungsaufbau von Gesprächen gibt. Die Probleme treten sowohl bei uns selbst (STARFACE Compact, extern erreichbar) wie auch bei unseren Kunden in der STARFACE Cloud auf. Die Probleme bestanden bereits unter STARFACE 6.7 und haben sich auch mit der 7.0 und 7.1 und den jeweils aktuellen Apps bisher nicht verbessert.

    Das Ganze äußert sich auf unterschiedliche Art:

    • Anrufe werden am Smartphone über das Softphone signalisiert. Wenn man rangeht wird für etwa 10 Sekunden angezeigt "Verbindungsaufbau". Anschließend verschwindet der eingehende Anruf und das Smartphone zeigt wieder den Home- oder Lockscreen an. Auf anderen Telefonen (z.B. Tischtelefon) klingelt es weiter. Für den Anrufer wirkt es als ob niemand rangeht.
    • Anrufe werden gar nicht signalisiert (eher selten)

    Das seltsame in beiden Fällen ist, dass die Probleme nicht bei jedem Anruf auftreten. Dabei ist es unerheblich ob sich das Smartphone im WLAN (Firma, Home-Office z.B. hinter Fritz!Box) befindet oder über Mobile Daten (Telekom wie auch Vodafone) verbunden ist. Die Probleme treten in allen Konstellationen auf. Komisch ist auch, dass es mal bei einigen Anrufen funktioniert und kurz darauf (ohne Netzwechsel des Smartphones) plötzlich nicht mehr funktioniert und keine Verbindung mehr zustande kommt.

    Gerade für Kunden, die einen Bereitschafts- und oder Notdienst (Gesundheitswesen) anbieten ist das extrem frustrierend und kann am Ende auch Menschenleben gefährden. Der Support war hier bisher leider wenig hilfreich, zumal man aktuell ja über eine Woche auf die Bestätigungs-Mail für neue Tickets wartet, um überhaupt mal Log-Dateien durchschicken zu können. Anschließend dauert es 4-6 Wochen bis man mit einer ersten Reaktion rechnen kann. Die Fehlerursache wurde dann bisher auch meist aufs Endgerät geschoben ("Wir können bei der Masse verschiedener Smartphone-Modelle nicht alle Smartphones supporten").

    Mich würde hier mal die Erfahrung anderer Partner interessieren. Wie ist euere Erfahrung über die Zuverlässigkeit der STARFACE App? Gibt es noch irgendetwas das man am Handy beachten/einstellen sollte? Energiesparmodi sind bereits vollständig deaktiviert.

    Vielen Dank. Ich bin gespannt auf die Rückmeldungen!

    Guten Morgen Fabian,

    der Ablauf des Anrufs dürfte wie folgt sein:

    1. Modul "Blacklist" (Prüft ob die Anrufernummer in der konfigurierten Liste enthalten ist, wenn ja -> busy)
    2. Modul "Zeitgesteuerte Ansage vor Melden" -> Ablauf wie oben im Screenshot
    3. Modul Firma 1 - Öffnungszeiten (Zeitgesteuerte Umleitung) -> Greift Mo-Do 17:00-08:00, Fr 13:00-08:00 und Sa-So und leitet direkt auf eine Voicemail um ---> Hat im Logbeispiel des obigen Anrufs nicht gegriffen
    4. Modul Firma 2 - Öffnungszeiten (Zeitgesteuerte Umleitung) -> Greift Mo-Do 17:00-08:00, Fr 13:00-08:00 und Sa-So und leitet direkt auf eine Voicemail um ---> Hat im Logbeispiel des obigen Anrufs nicht gegriffen
    5. Modul "Ansage vor Melden" um die Wartemusik abzuspielen. Als Anrufer hört man nach der ersten Ansage für den letzten Warenversand für etwa 1 Sekunde die Wartemusik und erhält dann erneut die Ansage. Insofern vermute ich, dass das parken während dieses Modulablaufs geschieht und die Modulausführung "Ansage vor Melden" unterbrochen wird.


    Bzgl. Abspeichern der UUID: Für mich würde dann der CallChannel ja reichen oder? Sobald der Anruf durch ist, benötige ich die UUID ja nicht mehr.

    VG
    Christian

    Hallo Fabian,

    vielen Dank für deine Rückmeldung. Zwei Rückfragen:

    1. Wann wird der Anruf denn geparkt? Beim AvM Modul? Von Benutzerseite gab es im obigen Fallbeispiel keine Interaktion
    2. Wie könnte ich die CallUUID denn über die Modulausführung hinweg speichern? Gibt es globale Variablen die man dafür verwenden kann?

    Bin was den Modul-Designer angeht noch ziemlich unerfahren. Ist mein erstes Modul, an dem ich schraube.

    Viele Grüße

    Christian

    Hallo zusammen,

    einer unserer Kunden möchte seine Kunden bei jedem eingehenden Anruf darauf hinweisen, dass zwischen Weihnachten und 3 Könige kein Warenversand stattfindet und bis wann Bestellungen eingegangen sein müssen, um noch in diesem Jahr verschickt zu werden. Diese ansage soll bei JEDEM eingehenden Anruf gespielt werden, unabhängig der gewählten Rufnummer und der Uhrzeit. Die Ansage soll bis einschl. 06.01.2020 gespielt werden. Dann nicht mehr.

    Außerhalb der Geschäftszeiten wird mithilfe des Moduls "Zeitgesteuerte Umleitung" auf die Voicemail umgeleitet. Auch hier soll vor die Voicemail die zusätzliche Ansage geschaltet werden.

    Ansonsten gibt es noch eine Modulkonfiguration "Ansage vor Melden", damit anstelle des Freizeichens die Wartemusik gespielt wird.


    Wir haben hierfür ein kleines Modul entwickelt, dem der Zeitraum (12.12.2020 - 06.01.2021) mitgegeben und in dem eine Ansage hochgeladen werden kann. Das Modul prüft dann den Zeitraum und falls der Zeitraum passt, spielt es die Ansage ab. Anschließend wird das Modul über ein "exit" beendet. Das Modul läuft im Modus "Call Processing - on all incoming calls". Im Anhang noch Screenshots der Modul-Konfig und der Ausführungsreihenfolge.

    Ausführungsreihenfolge.pngModul-Konfig 1.jpgModul-Konfig 2.jpg

    Am Wochenende hatte das ganze auch noch wunderbar geklappt. Während der Öffnungszeiten scheint es aber nun Probleme mit dem AvM Modul zu geben, da die Ansage zweimal abgespielt wird: Bei einem eingehenden Anruf hört der Anrufer zunächst wie gewünscht die Ansage mit dem letzten Warenversand. Anschließend hört man den Beginn der Wartemusik, so als würde der Anruf zum Teilnehmer durchgestellt. Der Anrufer bekommt dann aber nach etwa 1 Sekunde erneut die Ansage über den letzten Warenversand. Erst danach kommt er zum Teilnehmer durch, jedoch mit einem normalen Wählton anstelle der Wartemusik.

    Unten außerdem noch das Log meines Moduls für den Anruf.

    Das Modul scheint demnach zweimal aufgerufen zu werden. Einmal VOR der AvM und einmal NACH der AvM. Ist das so gewollt? Wenn ja, wie kann ich das verhindern? Ich könnte das Modul natürlich Umstellen auf "on incoming calls to user/group", aber dann würde die Ansage außerhalb der Öffnungszeiten nicht mehr gespielt.

    Vielen Dank und viele Grüße!

    Hallo zusammen,

    ich stehe gerade vor einem ähnlichen Problem. Ich versuche mich auf das Webinterface eines Yealink T58a zu verbinden. Allerdings scheitert der Login mit Username or Password wrong. Ich habe das Telefon bereits zurückgesetzt und neu Autoprovisioniert. Ich kann über die Erweiterten Einstellungen der Starface ein neues Passwort setzen (Telefon rebootet dann auch). Aber das Webinterface verweigert den Login mit Benutzer "admin". Habe nun sogar über die Starface die default Werte (admin - admin) gesetzt, das Telefon meckert nach einem Neustart sogar, dass das default Passwort in gebrauch ist, und am Telefon komme ich damit auch in die Admin Einstellungen. Aber der Webinterface Login scheitert weiterhin.

    Hat jemand eine Idee woran das liegt, bzw. was ich falsch machen könnte!? Starface 6.6.0.20, Telefon-Firmware 58.83.150.2 (lt. Wiki wäre eigentlich 58.83.150.1 aktuell, habe aber definitiv eine Starface Firmware am Telefon).


    Edit: Lustig... Gerade fiel mir auf, dass ich per http und nicht https verbunden war. Per https kann ich mich mit dem Webinterface verbinden und auch einloggen :confused:
    Ich lasse den Beitrag mal so stehen, falls jemand mal ein ähnliches Problem haben sollte.

    Sind heute Abend noch spontan beim Kunden vorbeigefahren:

    Nachdem wir die Digibox Premium auf die V 11.01.02.100 aktualisiert haben (inkl. Werksreset und rekonfiguration), war zunächst keine Besserung zu sehen. Mit lokalem DNS eingetragen kam keine Registrierung der Leitungen zustande. Trägt man oben genannten DNS der Telekom oder die Google DNS Server (8.8.8.8 und 8.8.4.4) in die Starface ein, klappt die Registrierung.

    Wir haben dann mal den Google DNS in die Digibox eingetragen, Starface wieder auf Digibox als DNS und die Starface neugestartet. Jetzt scheint es zu funktionieren. Im DNS Cache der Digibox sind auch die entsprechenden DNS Einträge der eigentlichen SIP-Server zu finden. Komisch ist, dass wir die Google DNS Server gestern bereits in der Digibox eingetragen hatten, da hat es nicht funktioniert. Ob das jetzt am Firmwareupdate liegt kann ich nicht sagen. Hoffe, dass das jetzt persistent ist.

    Edit 15.06.2019
    Noch ein Hinweis: Es empfiehlt sich in der Digitalisierungsbox im Menü "Administrativer Zugang" die Fernkonfiguration der Telekom (TR-069) zu deaktivieren. Heute morgen waren die Google DNS Server nämlich plötzlich deaktiviert und die Telekom Server wieder eingetragen. Wahrscheinlich wurde da über Nacht ein Konfigurationscheck gemacht. Natürlich ging der SIP-Trunk dann plötzlich nicht mehr. :mad:

    Hallo,

    danke für deine Rückmeldung. Ja das habe ich eingestellt. Konkret muss man unter den Konfigurationsassistenten den "PBX im LAN" Assitenten durchführen. Damit wird die PBX Funktionalität der Digibox deaktiviert und sie reicht die SIP Pakete an die PBX weiter. Das klappt ja auch soweit. Telefonie funktioniert auch einwandfrei sobald ich in der Starface den Telekom DNS eintrage.

    Welche Firmware Version verwendest du denn? Es gab vor ein paar Tagen bzw. letzte Woche wohl ein großes Firmware Update der Digibox (V. 11). Gab ein großes Update der GUI und die ganzen Assistenten sind weggefallen. Damit hat die Interneteinwahl allerdings nicht funktioniert weswegen ich auf die Firmware von Februar mit der gewohnten GUI gedowngegradet habe... Vllt. muss ich das nochmal validieren.

    Kannst du mir evtl. mal die DNS Config von deiner Digibox schicken? Welche DNS Server werden verwendet und was ist sonst so eingestellt (v.a. in den "Mehr Anzeigen" Bereichen).

    Danke dir schonmal :)

    Hallo zusammen,

    ich versuche aktuell bei einem Kunden einen DeutschlandLAN SIP-Trunk hinter einer DigiBox Premium ans laufen zu kriegen. Die Leitung registriert sich allerdings nicht. Im PBX Log steht, dass der Outbound Proxy reg.sip-trunk.telekom.de nicht aufgelöst werden kann.
    Dazu habe ich nun diesen Thread hier gefunden: https://support.starface.de/forum/showthre…runk-telekom-de

    Also offenbar ein Problem mit den SRV Records.

    Ich habe dann mal einen SRV Lookup auf reg.sip-trunk.telekom.de gemacht und den zuständigen DNS Server den mir der nslookup zurückbringt (dns00.dns.t-ipnet.de -> 194.25.2.170) direkt als DNS Server in die Starface eingetragen.

    Zack -> Leitung springt auf grün und die Leitung funktioniert auch sofort.

    Muss also ein Problem in der DNS Resolution in Kombination mit der Digibox Premium sein. Ich habe nun testhalber mal den SIP-Trunk in der Digibox Premium eingetragen. Dort funktioniert er auch. Die Digibox kann die Einträge also selbst auflösen, hat aber Schwierigkeiten den Lookup zu forwarden. Ich habe in der Digibox entsprechend des Fehlerleitfadens (https://knowledge.starface.de/display/wiki64…+die+Verbindung) daher mal die DNS Server aktualisiert. Hat leider nichts gebracht. Die Telekom Navigationshilfe kann man nicht mehr deaktivieren, da die Telekom diesen Dienst ja im April einstellen musste.

    Zum Testen habe ich nun mal den 194.25.2.170er und auch die Google DNS Server in der Digibox eingetragen. Jeweils mit dem Resultat, dass sich die Starface nicht verbinden kann und den Proxy nicht auflöst.

    Was mir nun noch aufgefallen ist: Im DNS Cache der Digibox taucht reg.sip-trunk.telekom.de. nicht auf. Stattdessen aber reg.sip-trunk.telekom.de.domain.local. wobei domain.local das lokale DNS Suffix ist. Das Suffix ist sowohl im DNS Server der Digibox hinterlegt als auch im Hostnamen der Starface. Ich kann aber nicht nachvollziehen ob die Starface hier eine falsche Anfrage schickt, oder ob die Digibox nachdem der A-Lookup auf reg.sip-trunk.telekom.de. ins leere läuft einfach mal den Suffix noch mit dranhängt.


    Versuche ich via NSLOOKUP oder DIG direkt von der Starface die SRV Pointer für reg.sip-trunk.telekom.de bzw. _sip._tcp.reg.sip-trunk.telekom.de aufzulösen erhalte ich die korrekten Einträge von der Digibox zurück.

    Hat jemand eine Idee was ich noch probieren könnte? Mir gehen langsam die Ideen aus. Habe jetzt zunächst mal den Telekom DNS direkt in der Starface eingetragen. Wäre aber schöner wenn ich den lokalen DNS eintragen könnte, zwecks interner Namensauflösung.

    Vielen Dank schonmal :)


    PS: Bitte keine Grundsatzdiskussion warum ich keinen anderen Anbieter verwende. Telekom war Kundenvorgabe.

    Ich finds auch etwas schade.

    Bei Auerswald aber ähnlich. Dort habe ich vor zwei Jahren zum ersten mal nach SIP 302 gefragt. Ist nicht geplant. Vor einem Jahr wurde es dann für das FW Release 7.4 angekündigt. Aktuell war zu dem Zeitpunkt 7.1. Also Ende 2019, Anfang 2020 zu erwarten. Als ich im August die Release Notes von 7.2. durchgelesen habe, stand dann plötzlich dabei: Call Deflection. Auerswald hat es also mittlerweile auch drin. Still und Heimlich. Wurde wahrscheinlich von zu vielen Leuten angefragt jetzt wo ISDN Stück für Stück endgültig abgeschafft wird/wurde.

    Hallo Fragan,

    falls das für dich noch aktuell sein sollte: Aktuell ist meines Wissens nach eine RUL im Amt (also ohne zweiten Gesprächskanal) mit der Starface nicht möglich. Die Telekom unterstützt SIP 302 zwar, die Starface aber nicht. CLIP No Screening funktioniert aber einwandfrei.

    Falls das Feature für dich noch relevant sein sollte, ich habe hier neulich mal einen Feature Request für die Call Deflection aufgemacht, den du gerne "unterschreiben" darfst: https://starface.uservoice.com/forums/38708-f…tion-partial-re

    Grüße

    Hallo zusammen :)

    ich weiß nicht inwieweit das hier erwünscht oder erlaubt ist. Ich würde allerdings gerne auf einen Feature Request von mir aufmerksam machen, den ich als nicht ganz unrelevant einstufen würde. Mich würde ein baldige Umsetzung jedenfalls sehr freuen, da ich das Feature bereits bei einigen Kunden (allerdings mit Auerswald bzw. Bintec PBX) nutze, und doch auch immer wieder angefragt wird:

    https://starface.uservoice.com/forums/38708-f…tion-partial-re


    Quote from Feature Request

    Bei ISDN Anschlüssen gab es die Weiterleitung im Amt (Partial Rerouting). Die Telekom und einige andere Provider bieten hierfür mittlerweile einen Ersatz für VoIP: SIP 302: Moved Temporarily. Dem Provider wird damit signalisiert, dass der Teilnehmer zeitweise unter einer anderen Rufnummer erreichbar ist und dieser leitet den Anruf dann auf diese Nummer weiter (z.B. Handy). Das hat zwei Vorteile:
    1. Statt einen zweiten Gesprächskanal in der Anlage für die Rufumleitung zu besetzen, bleiben alle Kanäle der Anlage frei
    2. Auf dem Weitergeleiteten Gerät wird der A-Teilnehmer signalisiert und nicht die Rufnummer der Anlage. Hierfür wird dann kein CLIP No Screening mehr benötigt.

    Ich fände es sehr sinnvoll, wenn diese Funktion zeitnah in der Starface implementiert wird, da das gerade für Rufumleitungen aufs Handy sehr sehr praktisch ist. Die Konkurrenz unterstützt dieses Feature bereits teilweise (z.B. Auerswald).


    Falls es unerwünscht sein sollte, solche Feature Requests hier im Forum zu "bewerben" bitte löschen oder schließen.

    Danke und viele Grüße

    Hallo chrite,

    Das Problem mit der Durchwahl habe ich ebenfalls.

    Die R-KOM ist noch dran. Ich habe hier nur die Info, dass es wohl Probleme mit Servern bei Starface gäbe, gegen die die Interoperabilität getestet der Leitungskonfiguration wird. Sobald das gelöst ist, wird man schnellstmöglich das neue Profil zur Verfügung stellen.
    Wenn du mir mal per PN deine Kontaktdaten (E-Mail) weitergibst, dann kann ich das an die R-KOM weitergeben wenn du willst, und du wirst informiert sobald das neue Leitungsprofil zur Verfügung steht.
    Sobald ich was weiß, werde ich auch hier wieder reinschreiben.

    LG

    Ich habe mittlerweile herausgefunden, dass das nur bei Telefonaten passiert mit Leuten die einen Telekom VoIP Anschluss haben. Zwar nicht immer, aber in gefühlt 80-90% der Telefonate >= 15 min.
    Mit anderen Providern kein Problem... Werde mir aber wohl doch einen anderen Telefonanschluss über den lokalen Glasfaseranbieter (SIP-Trunk mit Clip No Screening) organisieren. Ich habe keinen Nerv mehr mich hier mit 1&1 rumzuschlagen. Kundenfeindliches Unternehmen das kein Interesse daran hat die Probleme seiner Kunden zu lösen oder auch nur darauf einzugehen...

    Die Ursache des Problems liegt vermutlich darin, dass nach 15 min ein RE-INVITE gesendet wird, der nicht richtig zugeordnet werden kann. Gerade wo ich diese Zeilen schreibe frage ich mich, ob das evtl. damit zusammenhängen kann, dass die Rufnummer gleichzeitig noch auf meiner Fritzbox (zuhause) registriert ist und die RE-INVITES kommen nicht da an wo sie hinsollen?! Evtl. würde es helfen die Nummer aus der Fritzbox rauszunehmen und nur noch auf der Starface zu haben. Nutzen tue ich die Nummer zuhause eh nicht. :confused:

    Nein. Ich hatte bisher noch niemanden aus der Technik am Telefon, da es ja zunächst mal mit der 6.4.3er funktioniert und man sich bei der R-KOM bereits um die Rezertifizierung kümmert. Meines Wissens nach erwartet der SIP-Trunk von R-KOM aber das Format 0 222 xxx (Siehe Profil aus 6.4.3 oben). Das ganze deckt sich auch mit den Einstellungen aus einer laufenden Auerswald TK-Anlage am R-KOM SIP-Trunk (siehe Screenshot).

    Mich würde vielmehr mal interessieren was sich genau hinter dem Feld "Typ" verbirgt. Da hier u.a. auch auch Typen hinterlegt sind wie "sipgate" wirkt das auf mich, als wäre das ein benutzerdefiniertes Wählformat, das der Provider über siptrunk.de zur Verfügung stellen muss und als wäre es versäumt worden für die "custom_100x" Profile einen Namen zu vergeben (z.B. custom_1005 = "r-kom"). Meines Wissens nach arbeitet die R-KOM mit dem P-Preferred-Identity Feld. In der Auerswald ist RFC3325 eingestellt. Werde das mal testen.

    Vielleicht kann mir mal noch jemand auf die Sprünge helfen und erklären woher die custom Profile kommen :)


    Nachtrag: Stelle ich den Typ auf RFC3325 funktioniert zwar CNS und ein- und ausgehende Anrufe kommen problemlos durch. Allerdings gehen alle Anrufe an die Durchwahl -0.

    Dass die Freischaltung für 6.5.1 fehlt haben wir auch erst durch siptrunk.de herausgefunden. Darauf hatte mich der Kollege aus dem Vertrieb des Providers aufmerksam gemacht. Um die Rezertifizierung bzw. Freigabe wird man sich dort in der Technik wohl relativ bald kümmern.

    Ich bin leider selbst noch recht neu bei Starface, deswegen war mir das mit dem Sync von siptrunk.de noch garnicht bewusst. Ich werde aber in naher Zukunft die Einsteigerschulung machen um da mal tiefer in die Materie einzusteigen.

    Leider funktioniert der Trunk unter 6.5.1 mit dem "kopierten" Profil aus der 6.4.3 nicht 100%. CNS klappt beispielsweise nicht. Liegt vermutlich daran, dass das Wählformat vom Typ "custom_1005" unter 6.5.1 nicht auswählbar ist. Leider habe ich bisher auch noch nicht herausgefunden was sich hinter den Custom Profilen verbirgt und ob sich das auf die 6.5.1 transferieren lässt. Kannst du hier etwas Licht ins Dunkel bringen Thomas? Oder hast evtl. einen Link wo ich weiter nachlesen kann?


    R-KOM bietet außerdem die Option "Call Deflection" (SIP 302 bzw. Partial Rerouting). Unterstützt die Starface die Umleitung per SIP-302? Das konnte ich in der 6.4.3 bisher auch nicht erfolgreich testen. Wäre klasse, wenn man darüber Anrufe umleiten kann ohne einen Gesprächskanal zu belegen und den Umweg über die TK-Anlage zu gehen.

    Hallo Zusammen,

    zusammen mit dem Support von R-KOM habe ich nun herausgefunden, dass der SIP-Trunk bisher nur für Starface 6.4.1 und 6.4.3 freigegeben wurde. Ich habe mir jetzt mal eine 6.4.3 als VM aufgesetzt und siehe da, hier ist das Profil vorhanden. Nachfolgend die Einstellungen aus der 6.4.3 falls nach mir nochmal jemand nach dem Profil suchen sollte.

    Viele Grüße

    Hallo Lukas,

    danke für deine Antwort. Mir ging es weniger darum, wie man ein neues Profil anlegt. ;) Ich war nur davon ausgegangen, dass es ein vorgefertigtes Profil seitens Starface geben müsste, wenn der SIP-Trunk "Starface Zertifiziert" ist.
    Mit einem neuen Profil habe ich mittlerweile auch schon etwas rumprobiert. Registriert kriege ich den Trunk. Eingehende Anrufe gehen auch durch. Allerdings dauert es ca 10 Sekunden bis die Voiceverbindung steht. Rauskommen tue ich leider gar nicht. Von der Firewall her habe ich dieselben Einstellungen wie bei einem meiner Kunden. Dort haben wir ebenfalls den R-KOM Siptrunk. Allerdings steht dort eine Anlage von Auerswald mit vorgefertigtem "R-KOM" Profil von Auerswald. Die nötigen Infos aus dem Auerswaldprofil rauszuziehen ist mir leider noch nicht gelungen. Bei Auerswald sieht die Config schon sehr anders aus im Vergleich.

    Aber dann werde ich mal auf die Antwort des Providers warten.

    Danke auf jeden Fall für deine Antwort! :)