I would like to have pre-emption calls in Asterisk. I think there is no Asterisk support for this feature so i'm trying to implement it following a simliar algorithm like the one showed in this thread: Asterisk - Pre-emption calls
So I'm having problems in this step:
check if B in call with lower priority caller( ASTDB or REALTIME or fastagi script).
I know how to check if B is in a call using for example DEVICE_STATE(device) cmd, but i can't achieve to know who is the other caller in order to see his priority.
So, How can I know if one users is in a call and who is the other caller inside this call?
Thanks a lot.
You can read variables of any channel using
SHARED(varname[,channel])
-= Info about function 'SHARED' =-
[Synopsis]
Gets or sets the shared variable specified.
[Description]
Implements a shared variable area, in which you may share variables between
channels.
The variables used in this space are separate from the general namespace
of the channel and thus ${SHARED(foo)} and ${foo} represent two completely
different variables, despite sharing the same name.
Finally, realize that there is an inherent race between channels operating
at the same time, fiddling with each others' internal variables, which is
why this special variable namespace exists; it is to remind you that variables
in the SHARED namespace may change at any time, without warning. You should
therefore take special care to ensure that when using the SHARED namespace,
you retrieve the variable and store it in a regular channel variable before
using it in a set of calculations (or you might be surprised by the
result).
Sure you have set variables first.
You can set in variables or in ASTDB name of current speaking channel using in-call macro
General complexity of any solution like you want is above average, need person with at least 1-2 year of extensive experience with *.
Related
Is it possible to get a state of another channel. For example: In my dialplan I want to know the state of channel: SIP/provider/0612345678 and it should return, INVITE or ANSWERED etc
Is this possible?
Yes, you can use function SHARED.
core show function SHARED
-= Info about function 'SHARED' =-
[Synopsis]
Gets or sets the shared variable specified.
[Description]
Implements a shared variable area, in which you may share variables between
channels.
The variables used in this space are separate from the general namespace
of the channel and thus ${SHARED(foo)} and ${foo} represent two completely
different variables, despite sharing the same name.
Finally, realize that there is an inherent race between channels operating
at the same time, fiddling with each others' internal variables, which is
why this special variable namespace exists; it is to remind you that variables
in the SHARED namespace may change at any time, without warning. You should
therefore take special care to ensure that when using the SHARED namespace,
you retrieve the variable and store it in a regular channel variable before
using it in a set of calculations (or you might be surprised by the
result).
[Syntax]
SHARED(varname[,channel])
[Arguments]
varname
Variable name
channel
If not specified will default to current channel. It is the complete
channel name: 'SIP/12-abcd1234' or the prefix only 'SIP/12'.
For answered you have check variable DIALSTATUS
If I'm running the same binary (which implies the same architecture) on multiple nodes of a Beowulf cluster in an MPI configuration, is it safe to pass function pointers via MPI as a way of telling another node to call a function? Under what circumstances, if any, can the same function in the same binary have different virtual addresses on different machines or different instances?
Passing any kind of pointers other than the one shared file pointer per collective MPI_FILE_OPEN (which MPI maintains) to other processes is meaningless. Separate address spaces mean that the pointer value is useless in any process other than the one that generated it.
On the other hand, you could pass around the information about which function you want each process to call, or make each one decide individually. That depends on what your code is doing, of course.
Simply create array of functions filled with known order and pass functions's ID.
I have an asterisk server set up as a telephone exchange. I have, on it, a 100 extensions, from 00 - 99. I am running specific functions on each of those extensions. Some of these functions may need the extension on which the call was received to be available. How can I access the same? For example,
Say a call comes in on extension 55.
55 has a function associated with it. That function must take in 55 as an input parameter. How do I do this?
I have tried the following:
exten => 0,n,Verbose(1, "Call on ${EXTEN}-${CHANNEL}")
Output is : Call on 0-DAHDI/20-1
Thanks,
Sriram Shankar.
The answer you are looking for is dependent upon the path that the call is taking through your system. The easiest way to determine the answer to your question is to place the call and then run the following commands from within the Asterisk CLI:
> core show channels
This will show you what channels are active. Find the channel name of your call.
core show channel [channel-name]
This will output an array of channel details, including different variables that are set and their corresponding values. Look for the extension number you are trying to grab in the value fields and then look to see what the corresponding variable name is. It could be ${CALLERID(num)}, ${CALLERID(dnid)}, something under the ${CDR} variable, or even elsewhere.
If you don't find it in the output produced by "core show channel [channel-name]", you may have to trace the dialplan path that the call is taking and try setting the variable early on when the DID information is still available.
So we can use isObservable to work with some systems but I wonder If we can make tham show staps or do something like that. Is that possible?
I'm supposing that you are actually referring to the Observable and Controllable commands which are part of the DynamicSystems package.
Some Maple routines have so-called userinfo messages, which are optionally displayed and which can show partial steps. Those would typically be enabled with a call like infolevel[DynamicSystems]:=6 where 6 is the highest level of detail. With a lower value less detail might be displayed. Unfortunately, these particular DynamicSystems routines don't seem to have any userinfo messages in them. So this won't help directly in your case.
Sometimes one package calls another. The routine LinearAlgebra:-Rank is called, at some point, when Controllable is called. I'm guessing that you don't wish to see userinfo messages in Rank, which would be enabled by issuing infolevel[LinearAlgebra]:=n for some n between 1 and 6.
An alternative is to set printlevel high. But doing so will make all Maple internal calls also be verbose. The resulting output of setting, say, printlevel:=20 is overwhelming. I doubt that you'd find this approach useful.
Another alternative is to set certain routines as option trace. Sometimes doing so entails knowing the names of the appropriate internal routines. And this is made more complicated by the fact that not all non-exported module locals are visible by default. You could try first issuing the call, trace(DynamicSystems::ControllableSS): before invoking Controllable on your system. That shows some intermediary results, but those might not make much sense to you unless you know what source lines are generating those results. You can see the source by issuing the command, showstat(DynamicSystems::ControllableSS);
Here's an example,
restart:
with( DynamicSystems ):
aSys := StateSpace( <<1,2>|<3,4>>, <<2,3>>, <<1,0>|<0,1>>, <<0,0>> ):
aSys:-a, aSys:-b, aSys:-c:
trace(DynamicSystems::ControllableSS):
Controllable( aSys );
showstat(DynamicSystems::ControllableSS);
By looking at the source of the ControllableSS routine, you can deduce that it calls DynamicSystems:-StaircaseTransformation when the staircase method is specified. So here too you could issue showstat(DynamicSystems::StaircaseTransformation) to see the source of that internal (local) routine. Or you could trace that routine as well.
As a general rule, you can refer to exports of a module or package using the :- notation. And you can pass such names to trace and showstat using the :: notation instead of :-, unless you have first set kernelopts(opaquemodules=false). If an inner submodule member has more than one :- in its name then you'd have to use round-bracket delimiters to refer to it with the :: syntax. Sorry, that that's not so easy to express.
Is size of _POSIX_PATH_MAX is same for all unix flovors(linux,solaris)..
No, it's not even necessarily the same for given instances of the exact same version of the kernel. In most kernel's its a configurable parameter. It will often require a kernel recompile or relink to change, but it can change without having a whole new kernel.
On some (I think most nowadays) systems that macro doesn't translate into an integer literal, it translates to a system call that returns an integer. So if the kernel allows the system to be reconfigured at runtime it will return the current value for the parameter.
I would simply assume that it can't change during the lifetime of your program. If you assume it can change at any time you end up with race conditions where the value changes in between the time you read it and the time you use it. If you just explicitly state that your program assumes it never changes during the lifetime of the program, then system admins who run it will have to adopt the practice they should be adopting anyway and only change the kernel parameter at startup.
There are three POSIX specified calls that will interest you here:
pathconf and fpathconf
sysconf
I would recommend hunting down other sources as well to get a good feel for which variables are widely supported and which aren't.