aufbereitete History via XML-RPC / REST?

[s.boehm]

Hallo liebes Starface Forum,

ich würde gerne unsere Anrufer History mit diversen anderen Daten anreichern und visualisieren.
Die Daten die aus "Asuwertung -> Verbindungsdaten exportieren" als CSV herausfallen wären dafür ideal.
Allerdings möchte ich nur ungern ständig händisch CSV Tabellen exportieren und wo anders importieren.

Die Dokus zur XML-RPC Schnittstelle und REST Api habe ich mir angesehen.
Wenn ich das richtig sehe, ist eine Abfrage der callerhistory via REST nicht möglich, korrekt?

Die Daten aus der XML-RPC "Queue.getHistoryData" sind scheinbar nicht "aufbereitet", damit meine ich dass der gesamte caller trace rausfällt und noch mal aufbereitet werden müssten.

Kleiner vergleich:
CSV Daten, eine Zeile (Caller ID 51941), interessant für mich vor allem Felder wie "answered", "duration" und "login"

81666   51941   0   c7372363-e529-4010-a73f-2858101fad62    [...] true    2166    635

XML-RPC, insg. 5 Arrays mit gleicher callId und unterschiedlicher Daten (incomig, callLegUUID:

[0] => Array
   (
       [callId] => 51941
       [incoming] => 
       [callLegUUID] => c7372363-e529-4010-a73f-2858101fad62
       [agentId] => 635
       [...]
   )

[1] => Array
   (
       [callId] => 51941
       [incoming] => 1
       [callLegUUID] => c7372363-e529-4010-a73f-2858101fad62
       [agentId] => 635
       [...]
   )

[2] => Array
   (
       [callId] => 51941
       [incoming] => 1
       [callLegUUID] => 48f26092-af6a-4e80-bcf4-b6c01c998c6b
       [agentId] => 635
       [...]
   )

[3] => Array
   (
       [callId] => 51941
       [incoming] => 1
       [callLegUUID] => 7cfcbc55-7942-4a0b-84ee-79dd71f4500a
       [agentId] => 635
       [...]
   )

[4] => Array
   (
       [callId] => 51941
       [incoming] => 1
       [callLegUUID] => 7cfcbc55-7942-4a0b-84ee-79dd71f4500a
       [agentId] => 635
       [...]
   )

Bei einem Test für den gleichen Zeitraum habe ich ~300 Einträge in der CSV und über 2200 über die XML-RPC.

Gibt es eine Möglichkeit über eine der Schnittstellen automatisiert "aufbereitete" Daten abzufragen?
Ist sowas ggf. geplant oder soll mit in die REST Schnittstelle intgeriert werden?
Falls nicht anders möglich: Hat jemand - oder gibt es - einen "parser" (php, js, ...) um die Daten aus der XML Queue.getHistoryData passend zu mergen dass ein Array mit den gewünschten Infos rausfällt?

Vielen lieben Dank für jede Info,
Stefan

[nucom]

Hallo Stefan

Eventuell hilft die die DB-Tabelle "CDRSummary" weiter:

SELECT id, callid, callleguuid, cdraccountid, calleraccountid, callercallerid, 
       callernumber, callername, calledaccountid, calledcallerid, callednumber, 
       calledname, serviceid, starttime, ringingtime, linktime, callresulttime, 
       callresult, callresultcausedby, lineid, linename, dialednumber, 
       callbacknumber, answeredelsewhere, incoming, answered, hasvoicemail, 
       hasmonitor, hasfax, deleted, privatecall, callbacknumberextern, 
       duration
  FROM cdrsummary;

Ergebnis:

1;13;"5d666b23-f9db-40df-86cb-be44f54f43b8";1001;1001;"821 821 821";"";"";0;"0041123456789";"";"";3;1456216064234;;1456216069502;1456216075276;"CONNECTED";;1012;"SIP/[ENTFERNT]";"";"0041123456789";"";f;t;f;f;f;f;f;t;5
2;14;"82cfee62-b8fb-40e0-8e01-cb21ae0a4973";1001;1001;"821 821 821";"";"";0;"0041123456789";"";"";3;1456216126266;;1456216131909;1456216136508;"CONNECTED";;1012;"SIP/[ENTFERNT]";"";"0041123456789";"";f;t;f;f;f;f;f;t;4
3;15;"2853352d-0615-48dd-8b22-7b72119831d5";1001;1001;"821 821 821";"";"";0;"0041123456789";"";"";3;1456216197036;;1456216202363;1456216206749;"CONNECTED";;1012;"SIP/[ENTFERNT]";"";"0041123456789";"";f;t;f;f;f;f;f;t;4
4;16;"338b4b92-9e55-4861-a85b-324485eb1a4f";1001;1001;"821 821 821";"";"";0;"0041123456789";"";"";3;1456223229105;;1456223236043;1456223241249;"CONNECTED";;1012;"SIP/[ENTFERNT]";"";"0041123456789";"";f;t;f;f;f;f;f;t;5
5;17;"688cb365-ec3d-4819-bd25-d1ca2d75c16e";1001;1001;"821 821 821";"";"";0;"0041123456789";"";"";3;1456241103047;;1456241110524;1456241120636;"CONNECTED";;1012;"SIP/[ENTFERNT]";"";"0041123456789";"";f;t;f;f;f;f;f;t;10
6;25;"e424f26a-c849-49b5-8981-894a9a39d833";1000;1000;"100";"";"";0;"004171271818";"";"";3;1457421990237;;0;1457421996817;"NOT_CONNECTED";;1012;"SIP/[ENTFERNT]";"";"004171271818";"";f;f;f;f;f;f;f;t;0
7;26;"31d560cb-ee67-4210-add6-e27630da59be";1023;0;"0041123456789";"";"";1023;"5102630 : HRN 630";"";"";2;1457422095762;1457422096038;1457422100532;1457422095675;"CONNECTED";;1012;"SIP/[ENTFERNT]";"";"0041123456789";"";t;t;f;f;f;f;f;t;5
8;26;"525dfd12-f37a-420a-9c42-65cd45515c4e";1000;0;"0041123456789";"";"";1023;"5102630 : HRN 630";"";"";2;1457422095762;1457422096038;1457422100532;1457422105756;"CONNECTED";;1012;"SIP/[ENTFERNT]";"";"0041123456789";"";t;t;f;f;f;f;f;t;5

Es könnte aber sein, dass die Tabelle "CDRSummary" die gleichen nicht Aufbereiteten Daten enthält, wie du via Rest erhälst.

MfG

Fabian

[s.boehm]

Hallo Fabian,

vielen Dank für die Info, das schau ich mir an!

[andreas.stein]

Es könnte aber sein, dass die Tabelle "CDRSummary" die gleichen nicht Aufbereiteten Daten enthält, wie du via Rest erhälst.

'cdrsummary' enthält exakt die gleichen Daten wie der CSV-Export.

Um daraus valide Statistiken generieren zu können, muss aber noch einiges gefiltert werden. In der Liste tauchen z.B. angenommene Gespräche an Gruppen doppelt auf - einmal als Anruf an die Gruppe, einmal als Anruf an denjenigen, der das Gespräch angenommen hat. Verpasste Anrufe an Gruppen tauchen dann noch öfter auf. (1x für jeden Nutzer in der Gruppe und 1x für die Gruppe selbst). Weiter geht's dann mit Anrufen, die weitergeleitet wurden nach Zeitüberschreitung, durch Voicemail angenommene Gespräche, Faxe, Konferenzen, usw. usw. ... Ich bin da auch gerade dran und hab 2 Tage gebraucht, eine sinnvolle Ausgabe aller ein- und ausgehenden Anrufe zu generieren. Jetzt kann ich aber loslegen mit Statistiken generieren :-)

[s.boehm]

Hi Andreas,

auch hierfür vielen herzlichen Dank!
Wenn bei mir was brauchbares zusammen kommt, lass ich es Euch wissen.

Viele Grüße, Stefan

[s.boehm]

Hallo Forum,

ich habe mir die Tabellen und insb. die cdrsummary genauer angeschaut, die ist schon mal ganz hilfreich.
Dabei sind jetzt zwei grundlegende Fragen aufgetaucht:
1.: die auf unserer Anlage laufende PostgreSQL Version ist 8.4.20 ist seit July 2014 EOL, siehe https://www.postgresql.org/support/versioning/. Gehört das so? IMHO In Sachen Sicherheits-, Performance- und Featureaspekten problematisch. Kann die aktualisiert werden ohne was kaputt zu machen, gibt es eine Roadmap zur Aktualisierung?

2.: die Spalten für die Zeiten (Beispiel starttime) sind bigints mit Milisec unixtime. Gib es da einen wichtigen Grund für? Als spaltentyp timestamp wäre das sehr viel performanter und einfacher zu handlen was Datumsoperationen (Auswertung innerhabl bestimmter Zeiträume, Gruppieren nach Zeiträumen etc.) angeht.
Mich würde auch hier interessieren ob eine Änderung geplant ist.

Viele Grüße, Stefan

[404notfound]

Hallo zusammen, ich könnte einen Tipp zum Aufbereiten der Daten gebrauchen.
Ich möchte die Zeit berechnen, wie lange das Telefon desjenigen der dran gegangen ist geklingelt hat und die gesamte Wartezeit des Kunden, bevor jemand dran gegangen ist.
Die Dauer des Telefonats ist ja einfach "callresulttime" - "linktime", doch mit den beiden anderen Sachen komme ich nicht ganz zurecht.

In folgender Tabelle mal ein Beispiel (habe es schon ein bisschen um das reduziert)

callId	callStepId	callLegUUID	cdrAccountId	callerAccountId	callerCallerId	calledAccountId	calledCallerId	starttime	ringingtime	linktime	callresultTime	callResult	callResultCausedBy	lineId	lineName	callbackNumber	answeredElsewhere	incoming	answered	hasVoicemail	hasMonitor	callbackNumberExtern
557514	0	1c7da34f-523e-4858-aca4-f524d03fd640	2585	0	211 : 0049123456789	2585	211 : Gruppe1 211	1520496153789	1520496163641	1520496166920	1520496248113	CONNECTED	2026	1229	SIP/01234567890	49123456789		1	1	0	0	1
557514	0	5e0ec12e-2319-4b24-a09a-b29d285f81d1	2026	0	211 : 0049123456789	2585	211 : Gruppe1 211	1520496163564	1520496163641	1520496166920	1520496248111	CONNECTED	0	0		49123456789		1	1	0	0	1

Die Anrufdauer sind etwa 81 Sekunden. Die Abweichungen im Timestamp sind da ja marginal.
Doch wie lange hat das Telefon beim annehmenden geklingelt und wie lange hing der Anrufer in der Schleife?

Waren es 3 Sek, 10 Sek oder 13? Wie muss ich das rechnen und welche der beiden Zeilen muss ich für die Berechnung nehmen?

Liebe Grüße

[fwolf]

1.: die auf unserer Anlage laufende PostgreSQL Version ist 8.4.20 ist seit July 2014 EOL, siehe https://www.postgresql.org/support/versioning/. Gehört das so? IMHO In Sachen Sicherheits-, Performance- und Featureaspekten problematisch. Kann die aktualisiert werden ohne was kaputt zu machen, gibt es eine Roadmap zur Aktualisierung?

Es gibt keine Roadmaps und eine Aktualisierung bringt die Anlage in einen nicht supporteten Zustand. Das muß halt klar sein...

2.: die Spalten für die Zeiten (Beispiel starttime) sind bigints mit Milisec unixtime. Gib es da einen wichtigen Grund für? Als spaltentyp timestamp wäre das sehr viel performanter und einfacher zu handlen was Datumsoperationen (Auswertung innerhabl bestimmter Zeiträume, Gruppieren nach Zeiträumen etc.) angeht.

Zumindest was die Performance angeht, gibt es gegenteilige Messungen bzgl. indizierter timestamp- und bigint-Felder:
https://www.postgresql.org/message-i...omeiberica.com

Ich habe es nicht nachgeprüft, aber wenn die Angaben dort stimmen, dauert ein SELECT über timestamp-Felder mit Auswahl von Zeiträumen knapp drei mal so lang, wie über bigint-Felder.
Wenn man den Thread weiter verfolgt, so gibt es zwar Zweifel an den Messwerten, aber ein int8-Vergleich soll der schnellstmögliche sein. Timestamp hat einen kleinen Overhead...
Die Speicherung erfolgt intern in beiden Fällen als 8-byte Integer.

Was die Handhabung angeht, so gebe ich dir Recht. Aber innerhalb der STARFACE wird das ohnehin von Frameworks erledigt.