Sprachübertragung teilweise nur einseitig

  • Bei den Tests haben die Kollegen von verschiedenen Providern (Connect, Vodafone und O2) auf der Leitung angerufen und konnten die Ansage des IVR hören. Soweit ich das aus dem Ticket herausgelesen haben, waren es "nur" ca. 8% der Telefonate die auf den Fehler gelaufen sind.

    Also muss es auch ein Stück weit mit dem Anrufer (Anlage, Provider, Carrier, etc.) selbst zu tun haben.


    Bedingt auf jeden Fall. Allerdings, als wir beim Live-Test die direkte Durchwahl angerufen haben, war die Sprache ausnahmslos immer da. Das Problem tritt nur auf, wenn das IVR angerufen wird. Dann kann es ja nicht am Carrier liegen, der einzige Unterschied ist doch, dass das IVR das Gespräch annimmt und kein Telefon auf einer Gegenstelle.

    Wir sehen auch im IVR Log, dass genau die Gespräche, wo die Sprache einseitig übertragen wird, wird keine Taste gedrückt. D.h. der Anrufer hört einfach die IVR Ansage nicht.

    Dass es nicht an Starface liegt können wir doch dahingehend ausschließen, dass die Gespräche auf Durchwahlen immer funktioniert. Der Fehler tritt nur auf, wenn das Gespräch über das IVR eingeht. Es ist ja dann immer dieselbe Konstellation, d. h. selber Anrufer, selbe Systeme. Einziger Unterschied das IVR.

  • Bei einem PlaybackResourceFile wird auch ein Answer ausgeführt.

    Ich kann auf den ersten Blick leider nicht sehen, was im PlaybackResourceFile genau passiert.

    PlaybackResourceFile benutzt die ModuleBusinessObject.playBackgroundAndGetDtmf funktion.

    Diese Verwendet wiederum die CallRoutingService.playBackGroundAndGetDtmf funktion, dort sehe ich leider nicht was passiert.

    Ich weiss nicht woher, aber ich mache immer Instinktiv ein Answer(1) vor meinen Playbacks, ich weiss nicht mehr woher ich diese Gewohnheit habe, ich weiss nur, dass ich es nicht ohne Grund mache.

    Eventuell ist der Delay beim Answer im PlaybackResourceFile 0, was heisst, das Playback beginnt sofort nach dem Abnehmen, was wäre, wenn dann irgendetwas mit dem Call noch nicht ausgehandelt wurde, und durch ein Answer(1) vor dem Playback genügend Zeit entsteht, den Anruf und RTP Streams fertig auszuhandeln?

    MfG

    Fabian

    SI-Solutions GmbH
    STARFACE Modul-Entwickler | STARFACE Excellence Partner
    Modul-Downloads | Wiki | Shop

    Edited once, last by FabianZ (October 30, 2023 at 5:02 PM).

  • hast du nicht auch ein IVR Modul gebaut?

    Ja, aber der Code ist komplett in Java Ausgelagert.

    Der Anfang von meinem Modul ist etwa so:

    Das IVR Einstufig beginnt so:

    2.png

    Ich hätte es aber so gemacht bzw. Meinard , die Version, welche ich dir geschickt habe, enthält diesen Fix. Ich wäre deshalb froh, wenn du sie testen könntest.

    3.png


    MfG


    Fabian

  • Hallo alle miteinander,

    ich habe mir einmal die Zeit genommen die einstufige IVR auf einer Testcloud mit Connect-Leitung zu testen. Dabei habe ich folgende Signalisierung feststellen können:

    Support Log

    [2023-10-30T16:47:23,084] [ ---- ] Incoming call from line STARFACE Connect(1029)

    [2023-10-30T16:47:23,084] [ ---- ] Found extension on line STARFACE Connect(1029) 0049XXXXXXXX20

    [2023-10-30T16:47:23,085] [ 0063 ] ********* Call created **********

    [2023-10-30T16:47:23,085] [ 0063 ] Starting call routing : SIP/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX-00000037 dial number 0049XXXXXXXXXX20 CallerId [number=0049XXXXXXXXXX]

    [2023-10-30T16:47:23,095] [ 0063 ] Routing call "CallerId [firstname=Privat, lastname=Admin, company=Starface, dialedNumber=0049XXXXXXXXX20, number=0049XXXXXXXXXXX]" to number 0049XXXXXXXX20 over service PluginSelectorService

    [2023-10-30T16:47:23,095] [ 0063 ] CallLeg: f0654420-f16d-4e29-ac11-1608efd9242c

    [2023-10-30T16:47:23,105] [ 0063 ] Relevance check in "Test_IVR" on callstage onPhoneNumberCalled

    [2023-10-30T16:47:23,378] [ 0063 ] Channelstate is UP | SIP/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX-00000037

    [2023-10-30T16:47:34,193] [ 0063 ] Starting call routing : SIP/XXXXXXXXXXXXXXXXXXXXXXXXXXXXX-00000037 dial number 12 CallerId [firstname=Privat Admin (Starface), number=0049XXXXXXXXXXXX]

    [2023-10-30T16:47:34,201] [ 0063 ] Routing call "CallerId [firstname=Privat Admin (Starface), dialedNumber=12, number=0049XXXXXXXXXXXX]" to number 12 over service UserService

    [2023-10-30T16:47:34,201] [ 0063 ] CallLeg: f0654420-f16d-4e29-ac11-1608efd9242c

    [2023-10-30T16:47:34,229] [ 0063 ] Dial | SIPXXXXXXXXXXXXXXXXXXXXXXXXXXXXX-00000037 -> SIP/1102.ylnkt46s-00000038

    [2023-10-30T16:47:34,354] [ 0063 ] Channelstate is RINGING | SIP/1102.ylnkt46s-00000038

    [2023-10-30T16:47:38,059] [ 0063 ] Hangup Request Event | SIP/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX-00000037

    [2023-10-30T16:47:38,060] [ 0063 ] DialEnd with dialstatus CANCEL | SIP/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX-00000037 -> SIP/1102.ylnkt46s-00000038

    [2023-10-30T16:47:38,060] [ 0063 ] Hangup Cause: NORMAL_CLEARING | SIP/1102.ylnkt46s-00000038

    [2023-10-30T16:47:38,062] [ 0063 ] Hangup Cause: NOTDEFINED | SIP/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX-00000037

    [2023-10-30T16:47:38,065] [ 0063 ] ********* Call finished *********

    [2023-10-30T16:47:38,066] [ 0063 ] Got dialstatus DialReturnCodes(hc=CALL_REJECTED, ds=CANCEL, cr=UNKNOWN)

    [2023-10-30T16:47:38,067] [ 0063 ] Module "IVR einstufig" instance "Test_IVR" has presumably modified the call


    dazu habe ich noch das SIP-Debug Level des Asterisk erhöht um die SIP-Pakete direkt abzugreifen:

    [2023-10-30 16:47:23,082] VERBOSE[1350949][C-000003bf] pbx.c: Executing [49XXXXXXXX20@calling:2] AGI("SIP/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX-00000037", "agi:async,,1029,,,,,,,,,,,,,,") in new stack

    [2023-10-30 16:47:23,182] VERBOSE[1350949][C-000003bf] res_agi.c: AGI Script Executing Application: (SIPRemoveHeader) Options: (privacy)

    [2023-10-30 16:47:23,182] VERBOSE[1350949][C-000003bf] res_agi.c: AGI Script Executing Application: (SIPRemoveHeader) Options: (P-Preferred-Identity)

    [2023-10-30 16:47:23,182] VERBOSE[1350949][C-000003bf] res_agi.c: AGI Script Executing Application: (SIPRemoveHeader) Options: (P-Asserted-Identity)

    [2023-10-30 16:47:23,183] VERBOSE[1350949][C-000003bf] res_agi.c: AGI Script Executing Application: (SIPRemoveHeader) Options: (X-UCI_ORIGINATE)

    [2023-10-30 16:47:23,183] VERBOSE[1350949][C-000003bf] res_agi.c: AGI Script Executing Application: (SIPRemoveHeader) Options: (X-UCI_CALLID)

    [2023-10-30 16:47:23,362] VERBOSE[1350949][C-000003bf] res_rtp_asterisk.c: 0x7efc84057030 -- Strict RTP switching to RTP target address 185.XXX.XXX.XXX:25376 as source

    [2023-10-30 16:47:23,377] VERBOSE[1350949][C-000003bf] res_agi.c: AGI Script Executing Application: (Background) Options: (/var/starface/module/instances/repo/2a597b7c-aae4-4470-95ae-d0ccb6c3785c/res/3f7e438d-b5d2-4ceb-8a16-2eae20128bca)

    [2023-10-30 16:47:23,377] VERBOSE[1350949][C-000003bf] chan_sip.c: Audio is at 14080

    [2023-10-30 16:47:23,377] VERBOSE[1350949][C-000003bf] chan_sip.c: Adding codec alaw to SDP

    [2023-10-30 16:47:23,377] VERBOSE[1350949][C-000003bf] chan_sip.c: Adding non-codec 0x1 (telephone-event) to SDP


    Jetzt kommt das OK - Anruf wird verbunden

    [2023-10-30 16:47:23,377] VERBOSE[1350949][C-000003bf] chan_sip.c:

    <--- Reliably Transmitting (NAT) to 37.XXX.XXX.XXX:5061 --->

    SIP/2.0 200 OK

    Via: SIP/2.0/TLS 37.XXX.XXX.XXX:5061;branch=z9hG4bK82d5.994eb0c780efede0dd8d2950a47a7c19.0;received=37.XXX.XXX.XXX;rport=5061

    Via: SIP/2.0/UDP 37.YYY.YYY.YYY:5070;received=37.YYY.YYY.YYY;branch=z9hG4bKRzwZZahl;rport=5070

    Record-Route: <sip:37.XXX.XXX.XXX:5061;transport=tls;r2=on;lr=on;ftag=4FFF76A6-653FD00B00011AC7-DD0D0700;mt;rm=1>

    Record-Route: <sip:37.XXX.XXX.XXX;r2=on;lr=on;ftag=4FFF76A6-653FD00B00011AC7-DD0D0700;mt;rm=1>

    From: +49XXXXXXXXXX <sip:+49XXXXXXXXXX@sf.starface-connect.com;user=phone>;tag=4FFF76A6-653FD00B00011AC7-DD0D0700

    To: +49XXXXXXXX20 <sip:+49XXXXXXXX20@sf.starface-connect.com;user=phone>;tag=as14261015

    Call-ID: 273F8BF2-653FD00B00011AC9-DD0D0700

    CSeq: 10 INVITE

    Server: STARFACE PBX

    Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE

    Supported: replaces, timer

    Contact: <sip:49XXXXXXXX20@212.XXX.XXX.XXX:5061;transport=tls>

    Content-Type: application/sdp

    Content-Length: 329

    v=0

    o=root 426181505 426181505 IN IP4 212.XXX.XXX.XXX

    s=STARFACE PBX

    c=IN IP4 212.XXX.XXX.XXX

    t=0 0

    m=audio 14080 RTP/SAVP 8 101

    a=crypto:7 AES_CM_128_HMAC_SHA1_80 inline:4uOfQe1+eYhXudAgdqo6gte57VcJpfghZkknqt2Wx4fQ

    a=rtpmap:8 PCMA/8000

    a=rtpmap:101 telephone-event/8000

    a=fmtp:101 0-16

    a=ptime:20

    a=maxptime:150

    a=sendrecv


    Wir führen ein technisches ANSWER aus und verbinden die Audiokanäle.

    Viele Grüße

    Dipl.-Ing. (FH)

    Richard Weigel

    Support Specialist

    Customer Care

    STARFACE GmbH | Adlerstraße 61 | 76137 Karlsruhe | https://www.starface.com

    Edited 3 times, last by Ritsch.io (October 30, 2023 at 8:29 PM).

  • [2023-10-30 16:47:23,362] VERBOSE[1350949][C-000003bf] res_rtp_asterisk.c: 0x7efc84057030 -- Strict RTP switching to RTP target address 185.XXX.XXX.XXX:25376 as source

    [2023-10-30 16:47:23,377] VERBOSE[1350949][C-000003bf] res_agi.c: AGI Script Executing Application: (Background) Options: (/var/starface/module/instances/repo/2a597b7c-aae4-4470-95ae-d0ccb6c3785c/res/3f7e438d-b5d2-4ceb-8a16-2eae20128bca)

    [2023-10-30 16:47:23,377] VERBOSE[1350949][C-000003bf] chan_sip.c: Audio is at 14080

    [2023-10-30 16:47:23,377] VERBOSE[1350949][C-000003bf] chan_sip.c: Adding codec alaw to SDP

    [2023-10-30 16:47:23,377] VERBOSE[1350949][C-000003bf] chan_sip.c: Adding non-codec 0x1 (telephone-event) to SDP

    Wir führen ein technisches ANSWER aus und verbinden die Audiokanäle.

    Danke fürs Feedback.

    Noch um Sicherzustellen, dass man mich nicht Missverstanden hat.

    Ich meinte der Baustein "Answer" wurde im Modul nie genutzt,, nicht dass nie ein SIP-Answer o.ä. ausgelöst wurde, denn die Audiochannels müssen ja fürs Playback stehen.

    Laut dem Log vergehen zwischen der Nachricht vom "Switchintg to RTP target Address" und dem AGI Befehl fürs Playback gerade mal 15 Milisekunden.

    Ich habe zu wenig Know how von der Asterisk AGI, aber nach meinem Verständnis können die AGI Befehle jederzeit in einem Call abgesetzt werden, auch wenn der Call zu dem Zeitpunkt den Befehl gar nicht verarbeiten kann.

    Das heisst zb., wenn ich per AGI Script ein Playback auf einem Channel auslöse, welcher noch gar keine RTP Streams aufgebaut hat, was macht das AGI Script dann?

    Warten bis die RTP Channels stehen, oder wirft es einen Fehler, oder sagt es einfach "Ja Playback läuft"?

    MfG

    Fabian

  • Hier mal der Vergleich zu einem Selbstbau-Modul mit ANSWER vor Playback:

    pasted-from-clipboard.png

    [2023-10-30 17:10:32,425] VERBOSE[1362749][C-000003c6] pbx.c: Executing [49XXXXXXXXXX@calling:2] AGI("SIP/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX-00000039", "agi:async,,1029,,,,,,,,,,,,,,") in new stack

    [2023-10-30 17:10:32,525] VERBOSE[1362749][C-000003c6] res_agi.c: AGI Script Executing Application: (SIPRemoveHeader) Options: (privacy)

    [2023-10-30 17:10:32,525] VERBOSE[1362749][C-000003c6] res_agi.c: AGI Script Executing Application: (SIPRemoveHeader) Options: (P-Preferred-Identity)

    [2023-10-30 17:10:32,525] VERBOSE[1362749][C-000003c6] res_agi.c: AGI Script Executing Application: (SIPRemoveHeader) Options: (P-Asserted-Identity)

    [2023-10-30 17:10:32,525] VERBOSE[1362749][C-000003c6] res_agi.c: AGI Script Executing Application: (Set) Options: (CALLERID(name)=0049XXXXXXXXXX : Privat Admin (Starface))

    [2023-10-30 17:10:32,526] VERBOSE[1362749][C-000003c6] res_agi.c: AGI Script Executing Application: (Answer) Options: ()

    [2023-10-30 17:10:32,526] VERBOSE[1362749][C-000003c6] chan_sip.c: Audio is at 11792

    [2023-10-30 17:10:32,526] VERBOSE[1362749][C-000003c6] chan_sip.c: Adding codec alaw to SDP

    [2023-10-30 17:10:32,526] VERBOSE[1362749][C-000003c6] chan_sip.c: Adding non-codec 0x1 (telephone-event) to SDP

    [2023-10-30 17:10:32,526] VERBOSE[1362749][C-000003c6] chan_sip.c:

    <--- Reliably Transmitting (NAT) to 37.XXX.XXX.XXX:5061 --->

    SIP/2.0 200 OK

    Via: SIP/2.0/TLS 37.XXX.XXX.XXX:5061;branch=z9hG4bKe689.77510be921c64cd4983ce593710a4909.0;received=37.XXX.XXX.XXX;rport=5061

    Via: SIP/2.0/UDP 37.YYY.YYY.YYY:5070;received=37.YYY.YYY.YYY;branch=z9hG4bK3KINHaPE;rport=5070

    Record-Route: <sip:37.XXX.XXX.XXX:5061;transport=tls;r2=on;lr=on;ftag=231B8D41-653FD5780006540D-01013700;mt;rm=1>

    Record-Route: <sip:37.XXX.XXX.XXX;r2=on;lr=on;ftag=231B8D41-653FD5780006540D-01013700;mt;rm=1>

    From: +49XXXXXXXXXX <sip:+49XXXXXXXXXX@sf.starface-connect.com;user=phone>;tag=231B8D41-653FD5780006540D-01013700

    To: +49XXXXXXXXXX <sip:+49XXXXXXXXXX@sf.starface-connect.com;user=phone>;tag=as236348f3

    Call-ID: 7ACF1B9A-653FD5780006540E-01013700

    CSeq: 10 INVITE

    Server: STARFACE PBX

    Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE

    Supported: replaces, timer

    Contact: <sip:49XXXXXXXXXX@212.XXX.XXX.XXX:5061;transport=tls>

    Content-Type: application/sdp

    Content-Length: 329

    v=0

    o=root 851448316 851448316 IN IP4 212.XXX.XXX.XXX

    s=STARFACE PBX

    c=IN IP4 212.XXX.XXX.XXX

    t=0 0

    m=audio 11792 RTP/SAVP 8 101

    a=crypto:7 AES_CM_128_HMAC_SHA1_80 inline:YradGxjVLtb6RyqR4ahfvgpas5ouVTAnljp0VT8VX7I

    a=rtpmap:8 PCMA/8000

    a=rtpmap:101 telephone-event/8000

    a=fmtp:101 0-16

    a=ptime:20

    a=maxptime:150

    a=sendrecv

    <------------>


    Also rein vom SIP-Protokoll am Asterisk sehe ich gerade keinen Unterschied der Varianten.

    Viele Grüße

    Dipl.-Ing. (FH)

    Richard Weigel

    Support Specialist

    Customer Care

    STARFACE GmbH | Adlerstraße 61 | 76137 Karlsruhe | https://www.starface.com

    Edited 2 times, last by Ritsch.io (October 30, 2023 at 8:29 PM).

  • Nochmal Herzlichen Dank an die viele Unterstützung.

    Aktuell haben wir die Audio Aufnahme beim Kunden neu Konvertiert in Wave 08 kHz 16 Bit und dies neu Hochgeladen.

    Dies hat etwas Verbesserung gebracht, aber noch keine endgültige Lösung.

    Die IVR Modul-Anpassungen haben leider auch nicht den gewünschten Erfolg gebracht.

    Wir gehen dies weiter mit dem Kunden durch und werden euch hier weiter auf den laufenden Halten.

  • Hallo Zusammen,

    wir haben jetzt zum weiteren Eingrenzen, da sich die Probleme wie im 1. Post beschrieben häufen, eine Leitung von easybell auf der Starface registriert und damit getestet. Wir haben reproduzierbar einen Anrufer, der das IVR Modul jeweils über die easybell- und Starface Connect-Leitung angerufen hat.


    Ergebnis: Auf der Connect Leitung hört der Anrufer nichtmal die IVR Auswahl-Ansage. Auf der easybell Leitung hört er das File ohne Probleme. Wir haben das mit verschiedenen Anrufern, die den Kunden auf der Connect Leitung nicht erreichen können nachgespielt und kommen immer zum selben Ergebnis.

    Das zeigt für uns eindeutig, dass es nicht an der Starface Cloud Anlage selbst liegt, sondern eindeutig ein Connect Leitungsproblem ist.

  • Ich schreibe hier nochmal wegen dem Problem ein kurzes Update. Wir haben bis heute verschiedenste Tests gemacht und sind zu dem folgenden Ergebnis gekommen:

    Sobald eine Starface Cloud Anlage mit IVR und Starface Connect Leitung involviert sind, hören manche Anrufer die IVR-Ansage nicht. Das nachfolgend aufgebaute Gespräch bleibt ebenso einseitig stumm. Sobald man das IVR weg schaltet und die Rufnummer auf eine Gruppe/Benutzer geht, tritt das Problem nicht auf.

    Wir haben heute testweise die Rufnummer der Kunden SF Connect Leitung auf unsere Starface onPrem Anlage mit SF Connect Leitung verschoben, hier funktioniert alles problemlos.

    Wir haben dann eine neue Starface Cloud Anlage mit neuer Connect Leitung aufgesetzt, die Nummer des Kunden darauf gelegt und ein IVR vorgeschaltet --> selbes Problem: Anrufer hört das IVR nicht, Sprachübertragung einseitig. Sobald man das IVR weg schaltet und die Rufnummer auf eine Gruppe/Benutzer geht, tritt das Problem nicht auf.

    Dabei tritt diese einseitige Sprachübertragung nur bei manchen Anrufern auf, die können providerseitig bei der Telekom, Vodafone, .... sein - das ist völlig egal. Wir haben das seit Firmware 7 bis heute, egal welche IVR Version, ....
    Auch haben wir das auf allen SF Cloud Anlagen mit Connect + IVR, da wir die Anrufe auch auf anderen Instanzen getestet haben.

    Zusammenfassend ist es also so:

    Sobald SF Cloud + SF Connect + IVR involviert sind, haben manche Anrufer das Problem. Wenn ich eine dieser Komponenten austausche, d.h . onPrem Anlage, easybell Leitung, kein IVR, tritt das Problem nicht auf.

  • Hallo Meinard,

    interessant, danke für die Infos. Eine Erklärung habe ich dafür spontan keine.

    Was aber zur weiteren Einkreisung vielleicht noch interessant wäre: Sind die betroffenen Clouds solche mit geteilter, oder dedizierter IP-Adresse? Oder sind ggf. beide Arten betroffen?

  • Hallo,

    da wir SF Connect verwenden, haben wir uns die dedizierte IP gespart. Starface wirbt ja damit, dass geteilte IPs mit Connect verwendet werden können. Wir warten aktuell noch auf Rückmeldung, wie man mit dem Fall weiter umgeht, da wir in das Ticket schon seit Monaten Zeit ohne Ende investieren, wobei sich nun herausgestellt hat (durch das ganze Ausschlussverfahren), dass es definitiv an den Cloud-Anlagen liegen muss.

  • da wir SF Connect verwenden, haben wir uns die dedizierte IP gespart. Starface wirbt ja damit, dass geteilte IPs mit Connect verwendet werden können.

    Danke für die Rückmeldung. Ja das passt so auch alles, wollte es nur gerne möglichst genau wissen. Habe die Info im Ticket hinterlegt. Weitere Bearbeitung dann via Ticket durch die Support-Kollegen.

  • Nochmal Herzlichen Dank an die viele Unterstützung.

    Aktuell haben wir die Audio Aufnahme beim Kunden neu Konvertiert in Wave 08 kHz 16 Bit und dies neu Hochgeladen.

    Dies hat etwas Verbesserung gebracht, aber noch keine endgültige Lösung.

    Die IVR Modul-Anpassungen haben leider auch nicht den gewünschten Erfolg gebracht.

    Wir gehen dies weiter mit dem Kunden durch und werden euch hier weiter auf den laufenden Halten.

    ist es denn auch Mono? Wurde geprüft, ob das aufgenommene Audio das Problem ist? Vielleicht ist da ja ein Fehler in der Codierung, z.B. es ist falsch komprimiert.

  • Also ich kann kein grundsätzliches Problem bestätigen. Ich habe IVR hinter Connect ohne dezidierte IP eingerichtet und egal über welchen Provider ich anrufe - es tut.

    Es muss sich - aus welchen Gründen auch immer - um einen Einzelfall handeln.

    Wurde versucht eine andere Nummer vor das IVR zu schalten? Sind andere Module im Spiel? Wie ist/war die Auslastung der Cloud?

  • Welches Rufnummernformat wird im IVR genutzt?

    Das gleiche Problem gabs vor Jahren schon mal.

    Falsches Rufnummernformat im IVR: Einseitige Verständigung. Beim Mitschnitt auf der Anlage waren beide Seiten zu hören.

    Richtiges Rufnummernformat im IVR: Funktioniert.

  • Also ich kann kein grundsätzliches Problem bestätigen. Ich habe IVR hinter Connect ohne dezidierte IP eingerichtet und egal über welchen Provider ich anrufe - es tut.

    Es muss sich - aus welchen Gründen auch immer - um einen Einzelfall handeln.

    Wurde versucht eine andere Nummer vor das IVR zu schalten? Sind andere Module im Spiel? Wie ist/war die Auslastung der Cloud?

    Wir haben einen Testanrufer, welcher bei der Telekom ist. Mit diesem konnten wir die Problematik jedes mal aufs neue reproduzieren. Es betraf auch nicht nur den einen Anrufer sondern zuletzt von 10 Anrufern waren 4 betroffen. egal welcher Provider. Immer in Verbindung mit Connect Leitung + IVR. Wir spielen seit August letzten Jahres daran herum. Wir haben alle möglichen Dinge ausgeschlossen, andere Rufnummer, keine andere Module, frische Anlage mit nur dem IVR Modul, frische Connect Leitung, ..... Mit einer easybell Leitung tritt das Problem nie auf, mit einer Connect Leitung ist das ganze reproduzierbar.

    Wir haben die Rufnummern des Kunden auf unsere Connect Leitung umgezogen und hier hatten wir dasselbe Problem. Somit konnten wir die Anlage, die Leitung des Kunden usw. ausschließen.

    Wir haben seit kurzem in der Cloud eine feste IP-Adresse bekommen, nachem wir das ganze eskaliert haben. Nach einem erneuten Test konnten wir bis jetzt keine Probleme mehr feststellen. Wir haben mit dem Anrufer getestet, mit dem wir das ganze jedes mal reproduzieren konnten. Die feste IP-Adresse in der Cloud hat nun offenbar das Problem gelöst, sofern wir vom Kunden in den nächsten 2 Wochen keine andere Aussage erhalten.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!