Posts by jochen

Als Ergänzung hier noch der Querverweis für die Leitung mit Router von Telefonica. Damit klappt es aktuell bei unserem Kunden:

https://support.starface.de/fo…1406&viewfull=1#post51406

Grüße
Jochen

Hi,

mit folgenden Einstellungen funktionieren die Umleitungen scheinbar erstmal:

o2 Einstellungen.png

Tech. Infos: o2/Telefonica stört sich scheinbar daran, dass nach dem Session Progress 183 im SIP kein Ringing kommt. Das wird mit Progressinband=Never erzwungen (macht in meinen Augen aber eigentlich keinen Sinn, aber die Provider sind halt verschieden). Es kann also immer noch passieren, dass eine Umleitung nicht klappt. Gerade wenn die Zeit zwischen 183 Progress und Ringing länger dauert (5-6 Sekunden). DTMF habe ich nicht getestet.

Grüße
Jochen

Danke für das Feedback. Haben ein Ticket aufgemacht.

Grüße
Jochen

Hi,

das heißt eventuell by design oder bug? Lohnt sich es da mal beim support durch zuklingeln und ein Ticket erstellen zu lassen? Oder eher "feature" Wunsch?

grüße
Jochen

Hi,

ja genau und das merkt das Modul ja auch und deswegen soll danach wieder ein Anruf rausgehen. Das macht das Modul aber nicht mehr. Zwischen Zeilen Versuch: X und Answered: false ist jeweils eigentlich ein Callphonenumber Block. Leider wird niemand angerufen.

Grüßen
Jochen

Hi Fabian,

das Log sagt leider nichts. Also keine Fehler oder ähnliches. Weder mein Log noch das modules.log. Das sollte in der Theorie aber schon so funktionieren oder habe ich dann einen kompletten Denkfehler?

Grüße

Jochen

Ps: Mein Log

[2019-08-07 14:59:59,604] INFO [NewFunction] Versuch: 1.0
[2019-08-07 15:00:05,771] INFO [NewFunction] Answered: true
[2019-08-07 15:00:05,772] INFO [NewFunction] Pressed:
[2019-08-07 15:00:05,772] TRACE [NewFunction] Allowed iterations: 9999
[2019-08-07 15:00:05,772] INFO [NewFunction] Versuch: 2.0
[2019-08-07 15:00:05,772] INFO [NewFunction] Answered: false
[2019-08-07 15:00:05,772] TRACE [NewFunction] Allowed iterations: 9998
[2019-08-07 15:00:05,772] INFO [NewFunction] Versuch: 3.0
[2019-08-07 15:00:05,772] INFO [NewFunction] Answered: false
[2019-08-07 15:00:05,774] TRACE [NewFunction] Allowed iterations: 9997
[2019-08-07 15:00:05,774] INFO [NewFunction] Versuch: 4.0
[2019-08-07 15:00:05,774] INFO [NewFunction] Answered: false
[2019-08-07 15:00:05,775] TRACE [NewFunction] Allowed iterations: 9996
[2019-08-07 15:00:05,775] INFO [NewFunction] Versuch: 5.0
[2019-08-07 15:00:05,775] INFO [NewFunction] Answered: false
[2019-08-07 15:00:05,775] TRACE [NewFunction] Allowed iterations: 9995
[2019-08-07 15:00:05,775] INFO [NewFunction] Versuch: 6.0
[2019-08-07 15:00:05,775] INFO [NewFunction] Answered: false
[2019-08-07 15:00:05,776] TRACE [NewFunction] Allowed iterations: 9994
[2019-08-07 15:00:05,776] INFO [NewFunction] Versuch: 7.0
[2019-08-07 15:00:05,776] INFO [NewFunction] Answered: false
[2019-08-07 15:00:05,779] TRACE [NewFunction] Allowed iterations: 9993
[2019-08-07 15:00:05,779] INFO [NewFunction] Versuch: 8.0
[2019-08-07 15:00:05,779] INFO [NewFunction] Answered: false
[2019-08-07 15:00:05,780] TRACE [NewFunction] Allowed iterations: 9992
[2019-08-07 15:00:05,780] INFO [NewFunction] Versuch: 9.0
[2019-08-07 15:00:05,780] INFO [NewFunction] Answered: false

pps STARFACE Modules.log

[2019-08-07 14:58:39,862] DEBUG de.vertico.starface.module.core.runtime.ModuleRuntime Calling module: CallPhoneNumberTest
[2019-08-07 14:58:39,862] TRACE de.vertico.starface.module.core.runtime.ModuleRuntime Entry point function called: d1291263-efb1-4470-8a9e-5ea8ffe43146(NewFunction)
[2019-08-07 14:58:49,319] INFO de.vertico.starface.module.core.runtime.functions.callHandling.audio.PlaybackResourceFile2 Call has already been completed.
[2019-08-07 14:58:49,334] TRACE de.vertico.starface.module.core.runtime.ModuleRuntime Execution of entry point function completed in 9472ms

Hi Fabian,

ich habe es auf 6.4, 6.6 und 6.7 versucht ;-(. In dem Beispiel ist auch so, dass nach jedem Versuch ein Hangup kommt. Es ist auch egal, ob das Modul durch Anruf gestartet wird oder ob die Funktion von einem Timer gestartet wird.

Grüße
Jochen

Hallo zusammen,

vielleicht hat hier schon jemand mal ein ähnliches Problem gehabt und einen Workaround oder Idee. Ich versuche mich gerade an einem Modul welches bis zu einer DTMF Bestätigung nach und nach verschiedene Rufnummern anruft. Soweit eigentlich kein Problem. ... Aber wenn das Modul jemand anruft und dieser abnimmt und dieser das Gespräch auflegt, dann läuft das Modul munter weiter und macht eigentlich auch was es soll. Nur beim nächsten erreichen eines Callphonenumber Blocks macht er es einfach nicht mehr. Keine Fehlermeldung im Log oder sonstiges. Das Problem habe ich auch nur wenn der Angerufene auflegt. Legt das Modul auf, weil keine Bestätigung erfolgt, dann geht der nächste Anruf über Callphonenumber ohne Probleme.

Muss ich hier die ganz große Keule rausholen und mit Fork arbeiten oder geht es auch anders? Hier noch Beispiel als Modul: CallPhoneNumberTest_v12.sfm

Grüße

Jochen

Hallo,

ich hätte auch gerne Zugriff, danke.

Grüße
Jochen

Hallo Daniel,

das hat auch leider erstmal weniger mit STARFACE zu tun sondern mit den eingesetzten Telefonen und deren Möglichkeiten. Wenn das Protokoll diese Möglichkeit nicht hergibt ist es einfach ein Problem welches sich nicht einfach lösen lässt. Wenn die Möglichkeit besteht, dann bin ich mir sicher wird es auch eingebaut.

Grüße
Jochen

Hi,

das SIP Packet wird dir nicht viel helfen. Interessanter ist was im Log drunter steht Also warum keine Antwort kommt. /var/log/asterisk/full

Grüße
Jochen

Kann ich nur bestätigen Ascom, ist sehr geil. Ein Nachteil gegenüber dem MiTel System sind die Firmware Updates der Handgeräte die nicht ohne weiteres über die Luft verteilt werden kann. Gerade die Qualität und Verarbeitung der Endgeräte ist gefühlt den anderen Herstellern überlegen. Über eine LDAP Replikation könnte man hier "relativ" einfach einen Sync ermöglichen. (Automatisches Anmelden der Telefone, Adressbuch und so weiter.)

Grüße
Jochen

Hi Beka,

Android: 6.0.1
Modell: Sony Z3 Compact (D5803)
Server: Aktuelle 6.4 Beta.

[offtopic]
"Willkommen in der Apple Welt ;-)"

Wenn ich über das Tastenfeld (manuelle Eingaber der Telefonnummer) oder die Kontakte gehe bietet mir der Client nur die Wahl übers Telefon oder Skype an. Bei den BLF werde ich gefragt ob es über SIP oder Rückruf wählen soll. Das ist sicher so nicht gewollt, oder fehlt dem Client hier noch ein Recht oder ähnliches? Screenshot_20160929-134638.jpg

Ich konnte es noch weiter eingrenzen. Es lag an der XMPP Domain. Diese hatte die interne IP als Wert. Auf extern geändert und die Anmeldung funktioniert.

Grüße
Jochen

Hallo,

das Problem mit Android (6.0.1) habe ich auch. Ich konnte es schon soweit eingrenzen, dass es nur von "Extern" nicht funktioniert. Bei einer Kontrolle über Wireshark konnte ich sehen, dass die Pakete gut durchkommen aber der XMPP Server entsprechend antwortet. Logs im Openfire (/opt/openfire) werden dafür leider nicht generiert.

Mit der internen IP über VPN funktioniert die Anbindung ohne Probleme. Ideen?

http(s)://<Server-IP>:50080/xmlInterface/menu/dnd?sipName=SIP/<Telefonname> ist auch nicht das XML Interface sondern der XML Browser für Telefone.

Bin mir nicht sicher, aber ich glaube die IP spielt eine Rolle für die Authentifizierung.

Hallo @all,

hatte ihr schon mal ein ähnliches Problem.

Folgender Aufbau:
1) Modul überprüft einmal die Minute ein Postfach auf neue Emails
2) Bei einer neuen E-Mail wird eine Rufnummer angerufen
3) Dann wird eine Rufnummer angerufen
4) angerufener quittiert dann mit DTMF den Anruf
5) jetzt soll noch eine E-Mail geschrieben werden, dass der Anruf quittiert wurde und wann.

In der Regel ist alles soweit ok, aber es kann vorgenommen, dass zwischen Schritt 4) und 5) 24 Stunden vergehen.

[2015-12-19 05:36:34,433] DEBUG [alarmUser] Ack in external System ok
[2015-12-19 05:37:01,638] DEBUG [checkForNewEmail] No new messages.
...
[2015-12-20 05:34:03,018] DEBUG [checkForNewEmail] No new messages.
[2015-12-20 05:35:01,757] INFO [checkMessage] User YYYY acknowledge alarm. Finished. Used Number: XXXXXXXXXX
[2015-12-20 05:35:01,757] DEBUG [checkMessage] Bugfix for utf8 in subject

Zwischen den Logmeldungen liegt ein Playback einer Ansage und Zuweisen von Variablen.

In dem Modules.Log sehe ich:

[2015-12-19 05:36:01,359] DEBUG de.vertico.starface.module.core.runtime.ModuleRuntime Calling module: Notfallalarmierung
[2015-12-19 05:36:02,082] INFO de.vertico.starface.module.core.runtime.functions.callHandling.call.Hangup Skiping function call de.vertico.starface.module.core.runtime.functions.callHandling.call.Hangup because of AGICall == null
[2015-12-19 05:37:01,350] DEBUG de.vertico.starface.module.core.runtime.ModuleRuntime Calling module: 3iMedia Ãœberwachungsanruf
[2015-12-19 05:37:01,352] DEBUG de.vertico.starface.module.core.runtime.ModuleRuntime Calling module: Notfallalarmierung

Vermutung:

Scheinbar ein Timeout bei hängenden Komponentenaufrufen von 24 Stunden.
Ich habe die Vermutung das irgendwie das Playback abgespielt wird und der Angerufene auflegt. Hier kommt es dann scheinbar zu einem Deadlock. Ich hatte das "Wait for User Input" auf 1 stehen. Dies habe ich mal auf 0 abgeändert. Vielleicht hilft das ja.

Grüße

Jochen