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
Related
I'm studying for a test next week and we're learning about microcontrollers. We just did a sample code with interrupts and it told them temperature in F and C when we pushed a button (interrupted). how can C and F be accessed from both
main and the IRQ() functions?
The most simple way to share a variable between IRQ handlers and the main thread on any bare metal system:
Make sure that the variable type is one
which the CPU can atomically read and write.
Make the variable global and declare it volatile, so that
the generated machine code cannot optimize away accesses to
the shared variable.
To read a value, use something like const atomic_type local_copy = shared_variable; and work with that local copy. An expression like shared_variable * shared_variable might use different values for shared_variable.
Make sure that only one IRQ handler (which must only run once
at the same time), or only the main thread writes to the shared variable.
All other parts of the code are only allowed to read the shared
variable.
If the data you want to communicate between IRQ handler and main thread does not fit inside an atomic type, have fun with complex locking protocols.
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 *.
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.
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.