Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Queue Calls | Error 500 #4

Open
ebstefan6 opened this issue Jul 18, 2022 · 7 comments
Open

Queue Calls | Error 500 #4

ebstefan6 opened this issue Jul 18, 2022 · 7 comments

Comments

@ebstefan6
Copy link

Hi,

war haben heute die zammad bridge mit V18 eingerichtet. Personalisierte Anrufe kommen auch entsprechend im Zammad an, aber bei Calls aus Warteschleifen:

2022/07/18 15:06:31 Call with ID Inbound was hangup
2022/07/18 15:06:31 Error unexpected response (HTTP 500):

<title>500: Something went wrong</title>

500: We're sorry, but something went wrong.

We're sorry, but something went wrong.

Die Digits für Trunk und co passen so.

Jemand eine Idee, was das sein könnte?

@EtienneBruines
Copy link
Contributor

Gibt es auf dem Server weitere Infos/Logs, die mehr Infos zu den den HTTP 500 geben?

@ebstefan6
Copy link
Author

Ich wüsste spontan nicht, wie ich daran kommen sollte. Der call wird ja von der Bridge ausgelöst, korrekt?

@ebstefan6
Copy link
Author

Wenn ich den Call annehme oder es Klingelt aus der Warteschleife, taucht im Log gar nichts auf, der Fehler kommt erst beim anlegen. Kann es damit zusammenhängen, dass die WS gar nicht in der Gruppe ist, die gemonitored wird?

@EtienneBruines
Copy link
Contributor

Ich wüsste spontan nicht, wie ich daran kommen sollte.

Wird wohl irgendwann im Zammad Error Log auftauchen. 🤔

Der call wird ja von der Bridge ausgelöst, korrekt?

Genau, die HTTP Abfrage wird von der Bridge ausgelöst.

Kann es damit zusammenhängen, dass die WS gar nicht in der Gruppe ist, die gemonitored wird?

Da muss ich sagen, bin ich überfragt.

@ebstefan6
Copy link
Author

ebstefan6 commented Jul 18, 2022

I, [2022-07-18T09:14:30.391293 #452-388880] INFO -- : Started POST "/api/v1/cti/3v0eSnXXXX" for 185.244XX at 2022-07-18 09:14:30 -0400
I, [2022-07-18T09:14:30.397077 #452-388880] INFO -- : Parameters: {"event"=>"hangup", "from"=>"XXXX4360", "to"=>"010", "direction"=>"in", "call_id"=>"", "callid"=>"", "cause"=>"normalClearing", "answeringNumber"=>"010", "token"=>"3v0eSnUFo8GZxAG3Ni6PpZPi7JU"}
app/models/cti/log.rb:428:in process' app/models/cti/driver/base.rb:43:in process'
app/controllers/integration/cti_controller.rb:13:in event' app/controllers/application_controller/handles_transitions.rb:16:in handle_transaction'
I, [2022-07-18T09:14:30.441815 #452-388880] INFO -- : Completed 500 Internal Server Error in 45ms (Views: 1.5ms | ActiveRecord: 16.8ms | Allocations: 7419)
I, [2022-07-18T09:14:44.047378 #452-460380] INFO -- : Started GET "/api/v1/http_logs/cti?limit=50&=1658149051770" for 46.83.113.14 at 2022-07-18 09:14:44 -0400
I, [2022-07-18T09:14:44.056480 #452-460380] INFO -- : Parameters: {"limit"=>"50", "
"=>"1658149051770", "facility"=>"cti"}
I, [2022-07-18T09:14:44.098310 #452-460380] INFO -- : Completed 200 OK in 42ms (Views: 15.8ms | ActiveRecord: 6.6ms | Allocations: 15097)
I, [2022-07-18T09:14:53.156836 #452-389020] INFO -- : Started POST "/api/v1/cti/3v0eSnUFo8XXXX" for 185.244.XXX at 2022-07-18 09:14:53 -0400
I, [2022-07-18T09:14:53.162278 #452-389020] INFO -- : Parameters: {"event"=>"hangup", "from"=>"XXX360", "to"=>"010", "direction"=>"in", "call_id"=>"", "callid"=>"", "cause"=>"normalClearing", "answeringNumber"=>"010", "token"=>"3v0eSnUFo8GZxAG3Ni6PpZPi7JU"}
app/models/cti/log.rb:428:in process' app/models/cti/driver/base.rb:43:in process'
app/controllers/integration/cti_controller.rb:13:in event' app/controllers/application_controller/handles_transitions.rb:16:in handle_transaction'
I

@ebstefan6
Copy link
Author

Ich vermute, das ist das gleiche, was #2 beschreibt.

@EtienneBruines
Copy link
Contributor

Wenn ich den Call annehme oder es Klingelt aus der Warteschleife, taucht im Log gar nichts auf, der Fehler kommt erst beim anlegen. Kann es damit zusammenhängen, dass die WS gar nicht in der Gruppe ist, die gemonitored wird?

Das Monitoren bezieht sich nur darauf, ob etwas mit dem Anruf passiert. Es wird aus der Gruppe eine Liste erstellt, welche Rufnummern verwendet werden - und an Zammad werden nur Anrufe von/zu Rufnummern aus dieser Liste übertragen. Das heißt, ist die WS nicht in der Queue, wird der Anruf während dieser Zeit ignoriert. Sobald diese dann von jemand angenommen wird, gibt es (hoffentlich) eine Zuordnung zu eine Rufnummer aus der erstellte Liste und wird es damit an Zammad übertragen.

Solange der Anruf aber nicht verknüpft ist mit jemand aus dieser erstellte Liste, wird der auch nicht an Zammad übermittelt - auch nicht als „jemand ruft gerade an“.

Der Log-Eintrag Call with ID was hangup bedeutet dass der Anruf früher ein Gespräch war (eine Ansage vorab, gehe ich mal eben von aus) und jetzt der Anruf aber nicht mehr von 3CX übermittelt wird. Weshalb ein Anruf nicht von 3CX als activeCalls übermittelt wird, weiß ich allerdings nicht. Könnte bestimmt mit einer der Einstellungen der 3CX Instanz zu tun haben. Wer weiß, vielleicht hat er von 3CX eine neue ID bekommen - das wäre auch doof.

Bei dem Anruf würde dann aber schon anfangs New call (Talking) with ID ... from .. to ... geloggt werden. Ist das auch hier der Fall gewesen? Oder fängt der direkt an mit Call with ID Inbound was hangup?

Fällt mir jetzt aber auch auf: Call with ID <uuidv4> Inbound was hangup, da hätte noch eine UUIDv4 stehen müssen. War der Log-Eintrag tatsächlich ohne UUIDv4? (Und dann wahrscheinlich mit doppelte Leerzeilen zwischen ID und Inbound.)

Habe nun https://github.com/qmexnetworks/3cx-zammad-bridge/releases/tag/v0.5 ausgebracht mit Verbose Logging (mit -v), vielleicht dass das hilft, einige weitere Informationen herauszufinden.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants