The appdocsxml.dtd specifies that a "required" attribute in a parameter may
have a value of yes, no, true, or false. On some systems, specifying "False"
instead of "false" would cause a validation error. This patch fixes the casing
to explicitly match the DTD.
........
Merged revisions 407676 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@407677 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch brings CDR processing further in line with r407085. During some dial
operations, the application would not be locked to the Dial application and
would instead continue to show the previously known application. In particular,
this would occur when a Parked call would time out. This was due to a previous
snapshot already locking the application to Park - processing this in a Dial
Begin allows the Dial application to reassert its rightful place.
(CDRs. Ugh.)
But hooray for the Parked Call tests for catching this in the Asterisk Test
Suite.
........
Merged revisions 407166 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@407169 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes a number of small-ish problems that were noticed when
witnessing the records that the FreePBX dialplan produces:
(1) Mid-call events (as well as privacy options) have the ability to change the
overall state of the Dial operation after the called party answers. This
means that publishing the DialEnd event when the called party is premature;
we have to wait for the execution of these subroutines to complete before
we can signal the overall status of the DialEnd. This patch moves that
publication and adds handlers for the mid-call events.
(2) The AST_FLAG_OUTGOING channel flag is cleared if an after bridge goto
datastore is detected. This flag was preventing CDRs from being recorded
for all outbound channels that had a 'continue' option enabled on them by
the Dial application.
(3) The CDR engine now locks the 'Dial' application as being the CDR
application if it detects that the current CDR has entered that app. This
is similar to the logic that is done for Parking. In general, if we entered
into Dial, then we want that CDR to record the application as such - this
prevents pre-dial handlers, mid-call handlers, and other shenaniganry
from changing the application value.
(4) The CDR engine now checks for the AST_SOFTHANGUP_HANGUP_EXEC in more places
to determine if the channel is in hangup logic or dead. In either case, we
don't want to record changes in the channel.
(5) The default option for "endbeforehexten" has been changed to "yes". In
general, you don't want to see CDRs in the 'h' exten or in hangup logic.
Since the semantics of that option changed in 12, it made sense to update
the default value as well.
(6) Finally, because we now have the ability to synchronize on the messages
published to the CDR topic, on shutdown the CDR engine will now synchronize
to the messages currently in flight. This helps to ensure that all
in-flight CDRs are written before shutting down.
(closes issue ASTERISK-23164)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3154
........
Merged revisions 407084 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@407085 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When an 'ExtensionStatus' event was raised it included the status as a
numerical value, but did not include a text description of the status.
Added a 'StatusText' field to the event which is a string representation
of the extension status. Also added this to the 'Extension State' command
response.
(closes issue ASTERISK-23154)
Reported by: Jonathan Rose
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@406647 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The CEL data structures need to be protected during a configuration reload
and shutdown. Asterisk crashed during a shutdown because CEL events were
still in flight and the CEL data structures were already destroyed.
* Protected the cel_backends, cel_dialstatus_store, and cel_linkedids ao2
containers with a global ao2 object wrapper.
* Added NULL checks before use of the cel_backends, cel_dialstatus_store,
and cel_linkedids ao2 containers in case the CEL module is already
shutdown.
* Fixed overloading of the cel_linkedids held objects reference count.
During shutdown any held objects would be leaked.
* Fixed memory leak of cel_linkedids held objects if the LINKEDID_END is
not being tracked. The objects in the cel_linkedids container were not
removed if the LINKEDID_END event is not used.
* Added access protection to the cel_backends container during the CLI
"cel show status" command.
* Made cel_backends, cel_dialstatus_store, and cel_linkedids use the
standard ao2 callback templates for the hash and cmp functions.
* Eliminated unnecessary uses of RAII_VAR().
* Made ast_cel_engine_init() cleanup alocated resources on failure.
(closes issue AST-1253)
Reported by: Guenther Kelleter
Review: https://reviewboard.asterisk.org/r/3128/
........
Merged revisions 406417 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 406418 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 406465 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@406466 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Occasionally, the manager module would get an "INTERNAL_OBJ: bad magic
number" error on a "core restart gracefully" command if an AMI connection
is established.
* Added ao2_global_obj protection to the sessions global container.
* Fixed the order of unreferencing a session object in session_destroy().
* Removed unnecessary container traversals of the white/black filters
during session_destructor().
(closes issue AST-1242)
Reported by: Guenther Kelleter
Review: https://reviewboard.asterisk.org/r/3144/
........
Merged revisions 406341 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 406342 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@406343 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change adds improvements to support for allow=all in
pjsip.conf so that it functions as intended. Previously,
the allow/disallow socery configuration would set & clear
codecs from the media.codecs and media.prefs list, but if
all was specified the prefs list was not updated. Then a
call would fail when create_outgoing_sdp_stream() created
an SDP with no audio codecs.
A new function ast_codec_pref_append_all() is provided to
add all codecs to the prefs list - only those not already
on the list. This enables the configuration to specify a
codec preference, but still add all codecs, and even then
remove some codecs, as shown in this example:
allow = ulaw, alaw, all, !g729, !g723
Also, the display order of allow in cli output is updated
to match the configuration by using prefs instead of caps
when generating a human readable string.
Finally, a change to create_outgoing_sdp_stream() skips a
codec when it does not have a payload code instead of the
call failing.
(closes issue ASTERISK-23018)
Reported by: xrobau
Review: https://reviewboard.asterisk.org/r/3131/
........
Merged revisions 405875 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@405876 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Fixes typos of "transfered" instead of "transferred" in various code. Fixes incorrect gosub param help text for app_queue.
Fixes Asterisk man pages containing unquoted minus signs. Adds note about the "textsupport" option in sip.conf.sample.
(issue ASTERISK-23061)
(issue ASTERISK-23028)
(issue ASTERISK-23046)
(issue ASTERISK-23027)
(closes issue ASTERISK-23061)
(closes issue ASTERISK-23028)
(closes issue ASTERISK-23046)
(closes issue ASTERISK-23027)
Reported by: Eugene, Jeremy Laine, Denis Pantsyrev
Patches:
transferred.patch uploaded by Jeremy Laine (license 6561)
hyphen.patch uploaded by Jeremy Laine (license 6561)
sip.conf.sample.patch uploaded by Eugene (license 6360)
........
Merged revisions 405791 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 405792 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 405829 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@405830 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The per console verbose level feature as previously implemented caused a
large performance penalty. The fix required some minor incompatibilities
if the new rasterisk is used to connect to an earlier version. If the new
rasterisk connects to an older Asterisk version then the root console
verbose level is always affected by the "core set verbose" command of the
remote console even though it may appear to only affect the current
console. If an older version of rasterisk connects to the new version
then the "core set verbose" command will have no effect.
* Fixed the verbose performance by not generating a verbose message if
nothing is going to use it and then filtered any generated verbose
messages before actually sending them to the remote consoles.
* Split the "core set debug" and "core set verbose" CLI commands to remove
the per module verbose support that cannot work with the per console
verbose level.
* Added a silent option to the "core set verbose" command.
* Fixed "core set debug off" tab completion.
* Made "core show settings" list the current console verbosity in addition
to the root console verbosity.
* Changed the default verbose level of the 'verbose' setting in the
logger.conf [logfiles] section. The default is now to once again follow
the current root console level. As a result, using the AMI Command action
with "core set verbose" could again set the root console verbose level and
affect the verbose level logged.
(closes issue AST-1252)
Reported by: Guenther Kelleter
Review: https://reviewboard.asterisk.org/r/3114/
........
Merged revisions 405431 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 405432 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@405436 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In https://reviewboard.asterisk.org/r/3057/, applications and functions that
manipulate CDRs were made to interact over Stasis. This was done to
synchronize manipulations of CDRs from the dialplan with the updates the
engine itself receives over the message bus.
This change rested on a faulty premise: that messages published to the CDR
topic or to a topic that forwards to the CDR topic are synchronized with the
messages handled by the CDR topic subscription in the CDR engine. This is not
the case. There is no ordering guaranteed for two messages published to the
same topic; ordering is only guaranteed if a message is published to the same
subscriber.
Stasis was modified in r405311 to allow a publisher to synchronize on the
subscriber. This patch uses that API to synchronize the CDR publishers with
the CDR engine message router, which maintains the overall topic subscription.
(closes issue ASTERISK-22884)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3099/
........
Merged revisions 405312 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@405314 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds an API call to Stasis that allows a publisher to publish a
stasis message that will not return until a specific subscriber handles the
message. Since a subscriber can have their own forwarding topic which orders
messages from many topics, this allows a publisher who knows of that subscriber
to synchronize to that subscriber regardless of the forwarding relationships
between topics.
This is of particular use for dialplan applications that need to synchronize
on a particular subscriber's handling of a message.
(issue ASTERISK-22884)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3099/
........
Merged revisions 405311 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@405313 65c4cc65-6c06-0410-ace0-fbb531ad65f3
AMI action UserEvent event response would include the action header in its
keyvalue pairs list. Adjusted the start of the header loop to skip over the
action part.
(closes issue ASTERISK-22899)
Reported by: outtolunc
Patches:
svn_manager.c.skip_action.diff.txt uploaded by outtolunc (license 5198)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404832 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk does not support any of the transfer encodings specified in
HTTP/1.1, other than the default "identity" encoding.
According to RFC 2616:
A server which receives an entity-body with a transfer-coding it does
not understand SHOULD return 501 (Unimplemented), and close the
connection. A server MUST NOT send transfer-codings to an HTTP/1.0
client.
This patch adds the 501 Unimplemented response, instead of the hard work
of actually implementing other recordings.
This behavior is especially problematic for Node.js clients, which use
chunked encoding by default.
(closes issue ASTERISK-22486)
Review: https://reviewboard.asterisk.org/r/3092/
........
Merged revisions 404565 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404567 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Implements the following cli commands:
pjsip list aors
pjsip list auths
pjsip list channels
pjsip list contacts
pjsip list endpoints
pjsip show aor(s)
pjsip show auth(s)
pjsip show channels
pjsip show endpoint(s)
Also...
Minor modifications made to the AMI command implementations to facilitate
reuse.
New function ast_variable_list_sort added to config.c and config.h to implement
variable list sorting.
(issue ASTERISK-22610)
patches:
pjsip_cli_v2.patch uploaded by george.joseph (License 6322)
........
Merged revisions 404480 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404507 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch updates the log messages to include descriptive
names for event types. This is an improvement over having
only cryptic type numbers.
(closes issue ASTERISK-22909)
Reported by: outtolunc
Review: https://reviewboard.asterisk.org/r/3081/
Patches:
svn_security_events.c.names.diff.txt uploaded by outtolunc (license 5198)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404387 65c4cc65-6c06-0410-ace0-fbb531ad65f3
For the explanation, here is a copy-paste of the review board explanation:
Initially, it was discovered that performing an attended transfer of a
multiparty bridge with a PJSIP channel would cause a deadlock. A PBX thread
started a masquerade and reached the point where it was calling the fixup()
callback on the "original" channel. For chan_pjsip, this involves pushing a
synchronous task to the session's serializer. The problem was that a task ahead
of the fixup task was also attempting to perform a channel masquerade. However,
since masquerades are designed in a way to only allow for one to occur at a
time, the task ahead of the fixup could not continue until the masquerade
already in progress had completed. And of course, the masquerade in progress
could not complete until the task ahead of the fixup task had completed.
Deadlock.
The initial fix was to change the fixup task to be asynchronous. While this
prevented the deadlock from occurring, it had the frightful side effect of
potentially allowing for tasks in the session's serializer to operate on a
zombie channel.
Taking a step back from this particular deadlock, it became clear that the
problem was not really this one particular issue but that masquerades
themselves needed to be addressed. A PJSIP attended transfer operation calls
ast_channel_move(), which attempts to both set up and execute a masquerade. The
problem was that after it had set up the masquerade, the PBX thread had swooped
in and tried to actually perform the masquerade. Looking at changes that had
been made to Asterisk 12, it became clear that there never is any time now that
anyone ever wants to set up a masquerade and allow for the channel thread to
actually perform the masquerade. Everyone always is calling ast_channel_move(),
performs the masquerade itself before returning.
In this patch, I have removed all blocks of code from channel.c that will
attempt to perform a masquerade if ast_channel_masq() returns true. Now, there
is no distinction between setting up a masquerade and performing the
masquerade. It is one operation. The only remaining checks for
ast_channel_masq() and ast_channel_masqr() are in ast_hangup() since we do not
want to interrupt a masquerade by hanging up the channel. Instead, now
ast_hangup() will wait for a masquerade to complete before moving forward with
its operation.
The ast_channel_move() function has been modified to basically in-line the
logic that used to be in ast_channel_masquerade(). ast_channel_masquerade() has
been killed off for real. ast_channel_move() now has a lock associated with it
that is used to prevent any simultaneous moves from occurring at once. This
means there is no need to make sure that ast_channel_masq() or
ast_channel_masqr() are already set on a channel when ast_channel_move() is
called. It also means the channel container lock is not pulling double duty by
both keeping the container locked and preventing multiple masquerades from
occurring simultaneously.
The ast_do_masquerade() function has been renamed to do_channel_masquerade()
and is now internal to channel.c. The function now takes explicit arguments of
which channels are involved in the masquerade instead of a single channel.
While it probably is possible to do some further refactoring of this method, I
feel that I would be treading dangerously. Instead, all I did was change some
comments that no longer are true after this changeset.
The other more minor change introduced in this patch is to res_pjsip.c to make
ast_sip_push_task_synchronous() run the task in-place if we are already a SIP
servant thread. This is related to this patch because even when we isolate the
channel masquerade to only running in the SIP servant thread, we would still
deadlock when the fixup() callback is reached since we would essentially be
waiting forever for ourselves to finish before actually running the fixup. This
makes it so the fixup is run without having to push a task into a serializer at
all.
(closes issue ASTERISK-22936)
Reported by Jonathan Rose
Review: https://reviewboard.asterisk.org/r/3069
........
Merged revisions 404356 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404368 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change is in preparation for external MWI support.
Removed code from the system for normal mailbox handling that appends
@default to the mailbox identifier if it does not have a context. The
only exception is the legacy hasvoicemail users.conf option. The legacy
option will only work for app_voicemail mailboxes. The system cannot make
any assumptions about the format of the mailbox identifer used by
app_voicemail.
chan_sip and chan_dahdi/sig_pri had the most changes because they both
tried to interpret the mailbox identifier. chan_sip just stored and
compared the two components. chan_dahdi actually used the box
information.
The ISDN MWI support configuration options had to be reworked because
chan_dahdi was parsing the box@context format to get the box number. As a
result the mwi_vm_boxes chan_dahdi.conf option was added and is documented
in the chan_dahdi.conf.sample file.
Review: https://reviewboard.asterisk.org/r/3072/
........
Merged revisions 404348 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404350 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When Asterisk is shut down, the astdb_atexit() function releases
(finalize) the previously initiated (prepared) SQL statements in
sqlite3. Another thread making a subsequent request can cause a
crash in sqlite3. This patch eliminates that issue by resetting
the statement pointer after it is released/cleared. The sqlite3
code detects the null pointer, and aborts the operation cleanly.
(closes issue AST-1265)
Reported by: Alexander Hömig
(closes issue ASTERISK-22350)
Reported by: Birger "WIMPy" Harzenetter
Review: https://reviewboard.asterisk.org/r/3078/
........
Merged revisions 404344 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 404345 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404346 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When doing the rework of the CDR engine that pushed all of the logic into cdr.c
and made it respond to changes in channel state over Stasis, we knew that
accessing the CDR engine from the dialplan would be "slightly"
non-deterministic. Dialplan threads would be accessing CDRs while Stasis
threads would be updating the state of said CDRs - whereas in the past,
everything happened on the dialplan threads. Tests have shown that "slightly"
is in reality "very".
This patch synchronizes things by making the dialplan applications/functions
that manipulate CDRs do so over Stasis. ForkCDR, NoCDR, ResetCDR, CDR, and
CDR_PROP now all use Stasis to send their requests over to the CDR engine,
and synchronize on the channel Stasis topic via a subscription so that they
return their values/control to the dialplan at the appropriate time.
While going through this, the following changes were also made:
* DISA, which can reset the CDR when a user successfully authenticates, now
just uses the ResetCDR app to do this. This prevents having to duplicate
the same Stasis synchronization logic in that application.
* Answer no longer disables CDRs. It actually didn't work anyway - calling
DISABLE on the channel's CDR doesn't stop the CDR from getting the Answer
time - it just kills all CDRs on that channel, which isn't what the caller
would intend.
(closes issue ASTERISK-22884)
(closes issue ASTERISK-22886)
Review: https://reviewboard.asterisk.org/r/3057/
........
Merged revisions 404294 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404295 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Original commit message by mmichelson (asterisk 12 r403311):
"This adds channel locks around calls to create channel snapshots as well
as other functions which operate on a channel and then end up
creating a channel snapshot. Functions that expect the channel to be
locked prior to being called have had their documentation updated to
indicate such."
The above was initially committed and then reverted at r403398. The problem
was found to be in core_local.c in the publish_local_bridge_message function.
The ast_unreal_lock_all function locks and adds a reference to the returned
channels and while they were being unlocked they were not being unreffed when
no longer needed. Fixed by unreffing the channels.
Also in bridge.c a lock was obtained on "other->chan", but then an attempt was
made to unlock "other" and not the previously locked channel. Fixed by
unlocking "other->chan"
(closes issue ASTERISK-22709)
Reported by: John Bigelow
........
Merged revisions 404237 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404260 65c4cc65-6c06-0410-ace0-fbb531ad65f3
