I write a wallboard for asterisk queue system. The document says that when a call is transferred away by an agent an ATTENDEDTRANSFER (or BLINDTRANSFER) event log should be added to the queue_log file automatically. Unfortunately there is no line for any transferred calls in the log file (queue_log in my case). Is there any setting to be changed to let the system to log them properly ?
When I check the CEL files, I see the transfer logs. So the system is logging correctly for CEL but not for queue_log.
I tried to transfer the call to another agent, to an IVR and to another user who is not an agent for any queue. The result is the same, no log for the transfer process.
Any suggestions ?
I use the following:
Asterisk Version: 13.22.0
Freepbx 14.0.5.25
All trunks and clients are connected via SIP
If your phone do transfer via internal features - no log entries.
You have parse AMI events for needed info.
Write your own queue wallboard is VERY hard task. Queue module have really alot of issues.
Can recommend read some already written modules like https://www.asternic.net or queuemetric
Related
In all Diameter implementations I saw, the messages originating from the server is always sent towards the DNS resolved IP address of whats in the Destination-Host AVP. But, in commercial servers, we see an option to configure a DRA or a DEA which takes in all the messages and routes them.
Thus, when it comes to the mobicents diameter stack, this approach is sometimes hard to do. I can anyway re-configure the hosts file so that the message ends up in a DRA/DEA, yet, its a pain. I see no option to send these messages to a central diameter agent which will take care of all the dirty work for me.
The next issue is, if I plan to create such a DRA/DEA, the stack does not accept messages to a different host. Where, the message's Destination-Host parameter might contain a different hostname than ours. (which would be the ultimate destination it needs to go)
Is there a hack to achieve this without meddling with the internals of the jdiameter code and RA code?
If you change jdiameter's config to something like this:
<Network>
<Peers>
<Peer name="aaa://127.0.0.1:21812" attempt_connect="false" rating="1" />
<Peer name="aaa://CUSTOM_HOST:4545" attempt_connect="false" rating="1" />
</Peers>
<Realms>
<Realm name="custom.realm" peers="CUSTOM_HOST" local_action="LOCAL" dynamic="false" exp_time="1">
<ApplicationID>
...
</ApplicationID>
</Realm>
</Realms>
</Network>
In your sbb, then you'll need to create a client session providing your custom realm using this method:
DiameterCCAResourceAdaptor.CreditControlProviderImpl.createClientSession(DiameterIdentity destinationHost, DiameterIdentity destinationRealm)
Example:
ccaRaSbb.createClientSession(null, "custom.realm")
where ccaRaSbb is a CreditControlProvider instance (resource adaptor interface)
finally, when creating your CCR, the method CreditControlClientSession.createCreditControlRequest() will use the session' realm to find an available peer previously configured.
Let me know if this makes sense to you
Posting the method I used to solve this problem.
As it turns out its not possible out of the box to send a diameter message towards a peer which is not configured in the stack's jdiameter-config.xml file.
For me, the option to alter the stack in this case was also not feasible. So I devised a workaround for the problem by co-operating with the DRA we have. (most DRA's should be able to handle this method)
I added two custom AVPs to the outgoing request, namely Ultimate-Destination-Host and Ultimate-Destination-Realm.
In the DRA, I asked the admin to delete my Destination-Host and Destination-Realm AVPs and replace them with the ones created in step 1.
Now, whenever I send a packet destined to other diameter peers outside the configured peer, I target them towards the DRA and set these 'Ultimate' destination AVPs.
Ours is an Oracle DSR which is capable of doing this AVP manipulation. Most commercial ones should be able to handle it. Hope someone who wanted an answer for this question found this useful.
I've setup a radius server in our local network (using freeradius3), and now the clients are successfully login and send their accounting requests to the radius server.
What I need to accomplish is to pass the Accounting Requests (and their attributes) to an external program to process or filter some information. the external program however does not need to return anything to the radius server or change the normal workflow in the radius, so simply a copy of accounting requests has to be sent to the external program.
Couldn't find anything useful on web, so could you please point me to a tutorial or explain how would you implement that ?
Thank you
See the exec module config. The key thing is to set wait to no this means FreeRADIUS will not wait for the program to return.
You can then use the exec module instance as detailed in the header of that file i.e.
"%{exec:<path to program> '%{<attribute>}' '%{<attribute>}'}"
I am trying to configure syslog-ng destination path to use unix-stream sockets for Inter process communication. I have gone throgh this documentation http://www.balabit.com/sites/default/files/documents/syslog-ng-ose-3.3-guides/en/syslog-ng-ose-v3.3-guide-admin-en/html/configuring_destinations_unixstream.html .
My syslog.conf(only part of it) for the same is as follows:
source s_dxtcp { tcp(ip(0.0.0.0) port(514)); };
filter f_request {program("dxall");};
destination d_dxall_unixstream {unix-stream("/var/run/logs/all.log");};
log {source(s_dxtcp); filter(f_request); destination(d_dxall_unixstream);};
When I restart my syslog-ng server, I have got the following message:
Connection failed; fd='11', server='AF_UNIX(/var/run/logs/all.log)',
local='AF_UNIX(anonymous)', error='Connection refused (111)'
Initiating connection failed, reconnecting; time_reopen='60'
What this error signifies? How can I use unix sockets with syslog-ng? Could any one help me out.
Till now I am not able to create a Unix Domain Socket for inter process communication. But I got a way around it. All I want is a one way communication to send data created at syslog-ng to a running java program(a process, I can say). This I achieved with Using Named Pipes in Syslog-ng. Documents for achieving is http://www.balabit.com/sites/default/files/documents/syslog-ng-ose-3.4-guides/en/syslog-ng-ose-v3.4-guide-admin/html-single/index.html#configuring-destinations-pipe .
Reading from Named Pipe is same as reading from a normal file. One important point to note is that Reader process(here the Java program) should be started before Syslog-ng, (Writer, that writes log messages to the Named pipe).
Reason, Writer will block until there is a Reader. Absence of Reader will lead to loss of some messages, that got accumulated before Reader Started. And there should be only one instance of Reader. If there are multiple readers, the second reader will get null pointer exception, as the message it want to read is already read by the first Reader. Kindly note that this is from my experience. Let me know, If I am wrong.
I'm reading the perlipc perldoc and was confused by the section entitled "Interactive Client with IO::Socket". It shows a client program that connects with some server and sends a message, receives a response, sends another message, receives a response, ad infinitum. The author, Tom Christiansen, states that writing the client as a single-process program would be "much harder", and proceeds to show an implementation that forks a child process dedicated to reading STDIN and sending to the server, while the parent process reads from the server and writes to STDOUT.
I understand how this works, but I don't understand why it wouldn't be much simpler (rather than harder) to write it as a single-process program:
while (1) {
read from STDIN
write to server
read from server
write to STDOUT
}
Maybe I'm missing the point, but it seems to me this is a bad example. Would you ever really design an client/server application protocol where the server might suddenly think of something else to say, interjecting characters onto the terminal where the client is in the middle of typing his next query?
UPDATE 1: I understand that the example permits asynchronicity; what I'm puzzled about is why concurrent I/O between a CLI client and a server would ever be desirable (due to the jumbling of input and output of text on the terminal). I can't think of any CLI app - client/server or not - that does that.
UPDATE 2: Oh!! Duh... my solution only works if there's exactly one line sent from the server for every line sent by the client. If the server can send an unknown number of lines in response, I'd have to sit in a "read from server" loop - which would never end, unless my protocol defined some special "end of response" token. By handling the sending and receiving in separate processes, you leave it up to the user at the terminal to detect "end of response".
(I wonder whether it's the client, or the server, that typically generates a command prompt? I'd always assumed it was the client, but now I'm thinking it makes more sense for it to be the server.)
Because the <STDIN> read request can block, doing the same thing in a single process requires more complicated, asynchronous handling of the input/output functions:
while (1) {
if there is data in STDIN
read from stdin
write to server
if there is data from server
read from server
write to STDOUT
}
Is there any way to purge an outgoing queue. It doesn't appear that I can do it with the MMC snap-in and when i try to purge it in code i get an error Format name is invalid the computer it's sending the messages to does not exist, so they will never be sent, however the queues filled up the max storage space for MSMQ so everytime my application tries to send another message i get the insufficient resources exception.
I've tried the following formats and they all fail with the exception format name is invalid
DIRECT=OS:COMPUTER\private$\queuename
OS:COMPUTER\private$\queuename
COMPUTER\private$\queuename
You should be able to purge it manually from the MMC snap-in. MSMQ gets very stingy when it reaches its storage limits, so a lot of operations will fail with "permission denied" and things like that.
The long-term solution obviously is to modify the configuration so there is enough storage space for your particular usage patterns.
Edit: You might be running into a limitation in the managed API related to admin capabilities and remote queues. Take a look at this article by Ingo Rammer. It even includes a p-invoke example.
it is possible use managed code to purge an outgoing queue:
using (var msgQueue = new MessageQueue(GetPrivateMqPath(queueName, remoteIP), QueueAccessMode.ReceiveAndAdmin))
{
msgQueue.Purge();
}
in which GetPrivateMqPath is:
if (!string.IsNullOrEmpty(remoteIP))
return String.Format("FORMATNAME:DIRECT=TCP:{0}\\private$\\{1}", remoteIP, queueName);
else
return #".\private$\" + queueName;
QueueAccessMode.ReceiveAndAdmin points to outgoing queue.
You could try FORMATNAME:DIRECT=OS:computer\PRIVATE$\queuename.