| Age | Commit message (Collapse) | Author |
|---|
|
The ill conceived chan_agent is no more. It is now replaced by
app_agent_pool.
Agents login using the AgentLogin() application as before. The
AgentLogin() application no longer does any authentication.
Authentication is now the responsibility of the dialplan. (Besides, the
authentication done by chan_agent did not match what the voice prompts
asked for.)
Sample extensions.conf
[login]
; Sample agent 1001 login
; Set COLP for in between calls so the agent does not see the last caller COLP.
exten => 1001,1,Set(CONNECTEDLINE(all)="Agent Waiting" <1001>)
; Give the agent DTMF transfer and disconnect features when connected to a caller.
same => n,Set(CHANNEL(dtmf-features)=TX)
same => n,AgentLogin(1001)
same => n,NoOp(AGENT_STATUS is ${AGENT_STATUS})
same => n,Hangup()
[caller]
; Sample caller direct connect to agent 1001
exten => 800,1,AgentRequest(1001)
same => n,NoOp(AGENT_STATUS is ${AGENT_STATUS})
same => n,Hangup()
; Sample caller going through a Queue to agent 1001
exten => 900,1,Queue(agent_q)
same => n,Hangup()
Sample queues.conf
[agent_q]
member => Local/800@caller,,SuperAgent,Agent:1001
Under the hood operation overview:
1) Logged in agents wait for callers in an agents holding bridge.
2) Caller requests an agent using AgentRequest()
3) A basic bridge is created, the agent is notified, and caller joins the
basic bridge to wait for the agent.
4) The agent is either automatically connected to the caller or must ack
the call to connect.
5) The agent is moved from the agents holding bridge to the basic bridge.
6) The agent and caller talk.
7) The connection is ended by either party.
8) The agent goes back to the agents holding bridge.
To avoid some locking issues with the agent holding bridge, I needed to
make some changes to the after bridge callback support. The after bridge
callback is now a list of requested callbacks with the last to be added
the only active callback. The after bridge callback for failed callbacks
will always happen in the channel thread when the channel leaves the
bridging system or is destroyed.
(closes issue ASTERISK-21554)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2657/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394417 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394402 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394397 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394370 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
When QUEUE_MEMBER is used and the member specified is not in the queue,
Asterisk provides an ERROR message that indicates that the option specified
is not valid. This patch now properly displays an ERROR message that the
member is not in the queue if an interface is specified.
(closes issue ASTERISK-21980)
Reported by: Avraam David
........
Merged revisions 394345 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394346 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Peter J Philipp pointed out that there are two checks that ensure that len is
not less than 0. If len is less than 0, the function returns. Having both of
them is clearly redundant.
This removes the second and attempts to clarify (slightly) the error condition.
(closes issue ASTERISK-21772)
Reported by: Peter J Philipp
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394305 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
It is not apparent to the average user that the PASSTHRU function should not
be passed as ${PASSTHRU(string)} but just as PASSTHRU(string) to functions
which take a variable name and not its contents.
This patch clarifies the behavior in the documentation and provides an example.
(closes issue ASTERISK-21717)
Reported by: Richard Miller
patches:
func_strings.diff uploaded by Richard Miller (license 5685)
........
Merged revisions 394302 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 394303 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394304 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This patch does the following:
* It simplifies the Dial handling in CDRs. As a rule, the caller in a dial
relationship is always the Party A. There was some logic present in the
handling of the dial message that could, conceivably, pick the caller
as Party A for the beginning of the dial and the peer as Party A for the
end of the dial. This shouldn't have happened if the code in the bridging
framework was doing its job; however, that was broken and it led to the
FRACK. As it is, this code was overly ocmplex and not needed: the caller,
if present, should always be Party A. Period.
* It properly checks to see if a channel will continue on in the dialplan.
ast_check_hangup - much like cake at the end - is a lie. It will tell
you that you are hungup when you are not. Do not believe it.
I would make this function tell the truth, but I'm nervous that we've been
depending on it sitting on its throne of lies for far too long, and it would
probably break lots of things. So I'm just checking the "internal" soft
hangup flags, like everyone else.
(closes issue ASTERISK-22060)
Reported by: Mark Michelson
(issue ASTERISK-21831)
Reported by: Matt Jordan
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394290 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Instead of formatting a NULL pointer into a "%s" format string (which is
usually not a good thing to do), we instead print "Unknown".
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394278 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
from mixing different variants or general MFC-R2 settings within the same E1 line.
Most users do not have a problem with this since MFC-R2 lines are usually fractional E1s, or
the whole E1 has the same country variant and R2 settings.
In Venezuela however is common to have inbound MFC-R2 and outbound DTMF-R2 within the same E1.
This fix now properly parses the chan_dahdi.conf file to generate a new openr2 context every
time a new channel => section is found and the configuration was changed.
(closes issue ASTERISK-21117)
Reported by: Rafael Angulo
Related Elastix issue: http://bugs.elastix.org/view.php?id=1612
........
Merged revisions 394106 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 394173 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394263 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
join a 2 party bridge.
(closes issue ASTERISK-21829)
Review: https://reviewboard.asterisk.org/r/2636/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394249 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
For more details about the race condition see the linked review
at the bottom of this commit
(closes issue ASTERISK-21882)
Reported by Matt Jordan
Review: https://reviewboard.asterisk.org/r/2663
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394232 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394216 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
The JSON test attempted an overly clever use of RAII_VAR to run code
at the beginning and end of each test, in order to validate that no
JSON objects were leaked during the test.
The problem is that the validation code would run during the initial
load, when the tests were initialized. This happens during startup,
when other parts of the system might actively be allocating and
freeing JSON objects.
This patch changes the RAII_VAR to use the new
ast_test_register_{init,cleanup} functions to run the validations
properly.
(closes issue ASTERISK-21978)
Review: https://reviewboard.asterisk.org/r/2669/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394203 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This rejects requests from any unknown origins.
(closes issue ASTERISK-21278)
Review: https://reviewboard.asterisk.org/r/2667/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394189 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
I'm looking at you, OS X.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394156 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Major changes are to pull all packet reading functions into skinny_session
and move timeout handling to scheduling arrangements. Thread cancelling is
now undertaken directly rather than waiting for the read to timeout
(cleanup is popped on thread cancel). Also added some keepalive timings in
debugging messages.
Keepalive timeout has been increased from 1.1 by keepalive to 3 times
keepalive. This seems to align (after keepalives stabilise) with when
devices reset after not receiving keepalives. Probably needs more work,
especially around the first and/or second keepalives that vary
significantly by device and firmware version.
Review: https://reviewboard.asterisk.org/r/2611/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394147 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
context.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394103 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
When I corrected the CEL test crash in r394037, I didn't quite pay attention
to how the globals and locals were being shuffled around in the cleanup
callback. I removed the nulling of the global variables, which caused them
to be double cleaned.
This patch puts the global nulling code back (since the vars are cleaned up
by RAII_VARs), and removes the explicit ao2_cleanup() (since they were no-ops,
because the variables had just been nulled).
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394089 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
When I initially wrote the configuration support for ARI users, I
determined the section type by a category prefix (i.e., [user-admin]).
This is neither idiomatic Asterisk configuration, nor is it really
that user friendly. This patch replaces the category prefix with a
type field in the section, which is much cleaner.
Review: https://reviewboard.asterisk.org/r/2664/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394076 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394065 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
The voicemail_api test had code like strncmp(a, b, sizeof(a)), but a was a
char pointer, instead of a literal or char array. This meant that sizeof was
the size of the pointer, not the length of the string.
Since the string is in a stringfield and should be null terminated, I just
changed it to a plain strcmp.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394050 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394037 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
** This script is in no way finished.
Started the initial "cut" at converting a sip.conf file to a res_sip.conf file.
Hopefully the bulk of the framework is in place and only a few minor adjustments
need to be made when an option mapping is added that "doesn't fit". This script
and supporting files should be executable against python version 2.5.
An OrderedDict class (backported from a newer version of python) is included.
A MultiOrderedDict class is implemented so options, when added, should be able
to be added in order and allowed to have multiple values.
Currently the scripts supports the majority of endpoint options found in
res_sip.conf. Support has also been added for Aor(s) and the ACL/security
sections. Inside the sip_to_res_sip.py file one can see a list of options
that still need to be mapped.
Also items that still need to be done: templates, includes, parsing '=>'
delimiter. Note that some code is hopefully in place already to support
templates (e.g. lookup/retrieving defaults from them). However, the
parsing of and adding of the section needs to be done.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394024 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
real response.
(closes issue ASTERISK-22064)
Reported by: Rusty Newton
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394004 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393987 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393968 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
The SLA code within app_meetme was written before asotbj2 had been
merged into Asterisk. Worse, support for reloads did not exist at first
and was added later as a bolt-on feature. I knew at the time that
reloading was not safe at all while SLA was in use, so the reload would
be queued up to execute when the system was idle. Unfortunately, this
approach was still prone to errors beyond the fact that this was the
only place in Asterisk where configuration was not reloaded
instantly when requested.
This patch converts various SLA objects to be reference counted objects
using astobj2. This allows reloads to be processed while the system is
in use. The code ensures that the objects will not disappear while one
of the other threads is using them. However, they will be immediately
removed from the global trunk and station containers so no new calls
will use them if removed from configuration.
Review: https://reviewboard.asterisk.org/r/2581/
........
Merged revisions 393928 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 393929 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393930 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This fixes an issue with requiring SCOPED_LOCK to be the last variable
declaration and removes duplicate code in the process.
Review: https://reviewboard.asterisk.org/r/2665/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393919 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393910 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
(closes issue ASTERISK-21947)
reported by Matt Jordan
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393897 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393896 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
(closes issue ASTERISK-22054)
Reported by: Rusty Newton
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393870 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393858 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
and the digest is not of the correct length.
(closes issue ASTERISK-22003)
Reported by: Rusty Newton
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393857 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393843 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393834 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
(closes issue ASTERISK-22017)
Reported by: Rusty Newton
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393833 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
when retrieving information.
(closes issue ASTERISK-21883)
Review: https://reviewboard.asterisk.org/r/2645/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393831 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393816 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
(closes issue ASTERISK-21877)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2656/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393815 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393807 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This allows for reading and writing of functions on channels.
(closes issue ASTERISK-21868)
Review: https://reviewboard.asterisk.org/r/2641/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393806 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This also shuffles the stasis system topic and related handling.
(closes issue ASTERISK-21488)
Review: https://reviewboard.asterisk.org/r/2631/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393804 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This patch does the following:
* It adds a virtual table of callbacks to core_unreal. These callbacks can be
supplied by concrete implementations of "unreal" channel drivers, which lets
the unreal channel driver call specific functionality when it performs some
action. Currently, this is done to notify implementations when an
optimization operation has begun, and when an optimization operation has
succeeded.
* It adds Stasis-Core messages for Local channel bridging and Local channel
optimization. Local channel optimization is now two events: a Begin and an
End. Some consumers of Stasis-Core may want to know when an operation is
beginning so that they can 'prepare' their information; others will be more
concerned about when the operation has completed, so that they can 'fix up'
information. Stasis-Core allows for both, as does AMI.
Review: https://reviewboard.asterisk.org/r/2552
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393801 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
* trust_id_outbound was required even when the caller ID was not marked
private. This is against intentions and documentation.
* We now check both name and number privacy instead of checking name privacy
twice.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393793 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This patch reorders certain actions that may raise Stasis messages in the
channel destructor such that they occur before the Stasis cache is cleared.
Once the Stasis cache is cleared, its rather a bad idea to be trying to
publish information about a channel.
(closes issue ASTERISK-22001)
Reported by: Jonathan Rose
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393785 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This patch does the following:
* It adds a new soft hangup flag AST_SOFTHANGUP_HANGUP_EXEC that is set when a
channel is executing dialplan hangup logic, i.e., the 'h' extension or a
hangup handler. Stasis messages now also convey the soft hangup flag so
consumers of the messages can know when a channel is executing said
hangup logic.
* It adds a new channel flag, AST_FLAG_DEAD, which is set when a channel is
well and truly dead. Not just a zombie, but dead, Jim. Manager, CEL, CDRs,
and other consumers of Stasis have been updated to look for this flag to
know when the channel should by lying six feet under.
* The CDR engine has been updated to better handle a channel entering and
leaving a bridge. Previously, a new CDR was automatically created when a
channel left a bridge and put into the 'Pending' state; however, this
way of handling CDRs made it difficult for the 'endbeforehexten' logic to
work correctly - there was always a new CDR waiting in the hangup logic
and, even if 'ended', wouldn't be the CDR people wanted to inspect in the
hangup routine. This patch completely removes the Pending state and instead
defers creation of the new CDR until it gets a new message that requires
a new CDR.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393777 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393768 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
