Fragen zu Queumon und SilverBullet
Sven Neukirchner
ich möchte den Monitor PeerMon oder auch QueueMon verstehen und dann auch in
der Funktionalität erweitern.
(z.B. für Agenten den Status "in Nacharbeit" oder "in Pause" sichtbar
machen)
So wie ich das sehe gibt, es den SilverBullet Daemon welcher sich mit dem
Asterisk Manager Interface verbindet um Events abzuhören.
Desweiteren gibt es den SilverBullet Client
(/opt/gemeinschaft/inc/sbclient.conf) welcher sich wiederum mit dem
SilverBullet Daemon auf Port 18771 verbindet.
Asterisk <-> SB Daeomon <-> SB Client
Der SilverBullet Daemon ließt Events über das Manager Interface, packt diese
dann in einen Binärstring und sendet die Daten dann wiederum an den
SilverBullet Client.
Das Datenpaket wird dann vom SilverBullet Client mittels php Funktion
unpack() wieder entpackt und die notwendigen Statusinformationen
herausgefiltert.
Ist meine Überlegung bis zu diesem Punkt richtig?
Kann man sich mittels Telnet und Port 18771 mit dem SilverBullet Daemon
verbinden um den Datenverkehr zu beobachten?
In der Klasse SBClient
https://github.com/amooma/GemeinschaftPBX/blob/master/opt/gemeinschaft/inc/s
bclient.php werden einige Variablen definiert:
private $PREAMBLE = 0x4953;
private $M_CLOSE = 0x00;
private $M_PING = 0x02;
private $M_EXTGROUPSET = 0x60;
private $M_EXTGROUPSTAT = 0x62;
private $M_QUEUEGROUPSET = 0x70;
private $M_QUEUEGROUPCALLS = 0x72;
private $R_NACK = 0x01;
private $R_ACK = 0x03;
private $R_EXTGROUPSET = 0x61;
private $R_EXTGROUPSTAT = 0x63;
private $R_QUEUEGROUPSET = 0x71;
private $R_QUEUEGROUPCALLS = 0x73;
Welche Bedeutung haben Diese für die Auswertung der Manager Events?
Vielleicht hat ja jemand ein kurzes Beispiel anhand eines Manager Events:?
Event: Unlink
Privilege: call,all
Channel1: SIP/gw_21_mediagateway-00000004
Channel2: SIP/10-00000005
Uniqueid1: 1288879005.4
Uniqueid2: 1288879005.5
CallerID1: anonymous
CallerID2: anonymous
Event: Hangup
Privilege: call,all
Channel: SIP/10-00000005
Uniqueid: 1288879005.5
CallerIDNum: anonymous
CallerIDName: [Support]
Cause: 16
Cause-txt: Normal Clearing
Danke Sven
Peter Kozak
On 11/04/2010 04:08 PM, Sven Neukirchner wrote:
> Asterisk<-> SB Daeomon<-> SB Client
das ist Korrekt.
> Der SilverBullet Daemon lie�t Events �ber das Manager Interface, packt diese
> dann in einen Bin�rstring und sendet die Daten dann wiederum an den
> SilverBullet Client.
Nicht ganz.
Der SB-Daemon liest die Events, speichert die enthaltene Information und
gibt sie auf Wunsch an einen Client weiter. Die Events werden also nicht
einfach 1:1 durchgereicht. Der Client fragt also nicht nach Events
sondern nach verarbeiteten Informationen, wie Extension-Status oder
Anzahl der Anrufer in einer Queue.
Der Ablauf ist dabei eigentlich recht simpel:
Der Client kann einfach z.B. �ber eine Anfrage vom Typ
M_EXTGROUPSET eine Gruppe (z.B mit der Nummer "1") von Extensions
definieren, deren Stati er abfragen m�chte.
Der Server antwortet dann mit der Message R_EXTGROUPSET und den Stati
der entsprechenden Extensions.
Eine n�chste Anfrage (innerhalb der Verbindung) kann vom Client danach
einfach mit M_EXTGROUPSTAT unter Angabe der Gruppennummer gemacht werden.
Der Server antwortet dann mit R_EXTGROUPSTAT und den Stati der Extensions.
Alternativ dazu kann der Client M_EXTGROUPSUBSCRIBE schicken, was den
Server veranlasst bei irgedeiner �nderung der Stati der Extensions in
der Gruppe die Info an den Client zu pushen.
> Kann man sich mittels Telnet und Port 18771 mit dem SilverBullet Daemon
> verbinden um den Datenverkehr zu beobachten?
Prinzipiell kann man sich nat�rlich verbinden, es ist ein bin�res
Protokoll, deshalb wird es in der Praxis schwierig was zu senden.
Zum eibfachen Belauschen des Datenverkehrs kann man wohl besser
Wireshark nehmen.
> Welche Bedeutung haben Diese f�r die Auswertung der Manager Events?
Keine. Wie schon oben erw�hnt, ist der SB Server kein einfacher
Manager-Proxy, die Events werden also nicht weitergegeben.
Die Variablen sind die "Message Types" mit denen Client und Server
kommunizieren.
Gruss
Peter
--
AMOOMA GmbH - Bachstr. 124 - 56566 Neuwied --> http://www.amooma.de
Gesch�ftsf�hrer: Stefan Wintermeyer, Handelsregister Montabaur B14998
B�cher: http://das-asterisk-buch.de - http://ruby-auf-schienen.de
Sven Neukirchner
>
> On 11/04/2010 04:08 PM, Sven Neukirchner wrote:
> > Asterisk<-> SB Daeomon<-> SB Client
>
> das ist Korrekt.
>
>
> packt diese
> > dann in einen Binärstring und sendet die Daten dann wiederum an den
> > SilverBullet Client.
>
> Nicht ganz.
>
> Der SB-Daemon liest die Events, speichert die enthaltene Information
> und
> gibt sie auf Wunsch an einen Client weiter. Die Events werden also
> nicht
> einfach 1:1 durchgereicht. Der Client fragt also nicht nach Events
> sondern nach verarbeiteten Informationen, wie Extension-Status oder
> Anzahl der Anrufer in einer Queue.
>
> Der Ablauf ist dabei eigentlich recht simpel:
>
> M_EXTGROUPSET eine Gruppe (z.B mit der Nummer "1") von Extensions
>
> Der Server antwortet dann mit der Message R_EXTGROUPSET und den Stati
> der entsprechenden Extensions.
>
> einfach mit M_EXTGROUPSTAT unter Angabe der Gruppennummer gemacht
> werden.
>
> Der Server antwortet dann mit R_EXTGROUPSTAT und den Stati der
> Extensions.
>
> Alternativ dazu kann der Client M_EXTGROUPSUBSCRIBE schicken, was den
> der Gruppe die Info an den Client zu pushen.
>
>
> > Kann man sich mittels Telnet und Port 18771 mit dem SilverBullet
> Daemon
> > verbinden um den Datenverkehr zu beobachten?
>
> Protokoll, deshalb wird es in der Praxis schwierig was zu senden.
>
> Zum eibfachen Belauschen des Datenverkehrs kann man wohl besser
> Wireshark nehmen.
>
>
>
> Keine. Wie schon oben erwähnt, ist der SB Server kein einfacher
> Manager-Proxy, die Events werden also nicht weitergegeben.
> Die Variablen sind die "Message Types" mit denen Client und Server
> kommunizieren.
Hallo Peter,
danke für die schnelle Antwort.
Ich habe mir mal den SB Daemon etwas genauer angeschaut.
Genau genommen werden von ihm nur zwei Manager Actions ausgeführt und die
Antworten ausgewertet:
"ExtensionState" und "QueueStatus"
Möchte ich jetzt andere Actions wie beispielsweise "QueuePause" auswerten
und im Monitor darstellen,
müsste man Änderungen am SB Client und SB Daemon vornehmen, was ohne Python
Kenntnisse nicht ganz einfach ist. :-(
Vieleicht ist es dann einfach besser den Status eines Agenten "in Pause"
oder "in Nacharbeit" einfach in eine extra Tabelle zuschreiben auszuwerten
und im Monitor darzustellen. Auch der Status Rufumleitung wird ja im Monitor
nicht über den Manager abgefragt sondern über die Datenbank.
Der Status der Rufumleitung wird aber momentan nicht automatisch
aktualisiert sonder geht nur über einen Webseitenrefresh.
Grüße Sven
Sascha Daniels
Sven Neukirchner schrieb:
> Der Status der Rufumleitung wird aber momentan nicht automatisch
> aktualisiert sonder geht nur �ber einen Webseitenrefresh.
Auch die Anzahl der Agenten pro Queue wird nur bei einem Refresh
aktualisiert.
Das funktioniert auch im Produktivbetrieb sehr gut, wenn man die etwas
hoch angesetzten Default Werte des Reload Intervals herunter setzt.
Gruss Sascha
--
Sascha Daniels
-Leiter Administration-
___________________________
WAVE Computersysteme GmbH
Philipp-Reis-Str. 9
35440 Linden
Tel.: +49 (0)6403 / 90508301
dan...@wave-computer.de
http://www.wave-computer.de
Gesch�ftsf�hrer: Carsten Kellmann
Registergericht Gie�en HRB 1823
Peter Kozak
> Ich habe mir mal den SB Daemon etwas genauer angeschaut.
> Antworten ausgewertet:
>
> "ExtensionState" und "QueueStatus"
Die Events werden eigentlich nur ausgef�hrt, wenn der Server l�ngere
Zeit keinen Status �ber Events bekommen hat (default 1 Minute) oder bei
der ersten Anfrage direkt nach dem Start des Servers.
Danach werden die Events ausgewertet, es wird also nicht jedes mal bei
Asterisk nachgefragt, wenn ein Client eine Anfrage stellt.
Wenn man sich das Asterisk-AMI-Modul "asterisk.py" ansiehst, sieht man
dass da eine ganze Menge an Events ausgewertet werden. Man k�nnte also
auch aktive Channels abfragen etc.
> M�chte ich jetzt andere Actions wie beispielsweise "QueuePause" auswerten
> und im Monitor darstellen,
> m�sste man �nderungen am SB Client und SB Daemon vornehmen, was ohne Python
> Kenntnisse nicht ganz einfach ist. :-(
Um eine Erweiterung des Servers wird man dabei sicher nicht herumkommen.
Python ist allerdings sehr einfach und verst�ndlich. :)
Wahrscheinlich m�sste man nur den Event "QueueMemberPaused" auswerten
und im entsprechenden "extstates" Array
z.B. als "self.extstates[exten][queuepause]" speichern. Bei der Abfrage
k�nnte man im Extension-Status ein entsprechendes Bit �bergeben.
> Vieleicht ist es dann einfach besser den Status eines Agenten "in Pause"
> oder "in Nacharbeit" einfach in eine extra Tabelle zuschreiben auszuwerten
> und im Monitor darzustellen. Auch der Status Rufumleitung wird ja im Monitor
> nicht �ber den Manager abgefragt sondern �ber die Datenbank.
Die Rufumleitungen etc. sind ja bereits in der Datenbank definiert,
deshalb holt sich der Monitor diese direkt aus der DB. Der Server m�sste
ja an dieser Stelle das gleiche tun, w�re also unsinnig.
Anders sieht es eben mit den Teilen aus, die in Asterisk abgefragt
werden. Dazu ist der Server da, man m�sste nur ggf. den Befehlsumfang
erweitern.