When listing a container, we now print the number of objects
in the container at the end of the list.
Change-Id: I791cbc3ee9da9a2af9adc655164b5d32953df812
When ast_config_load() fails with CONFIG_STATUS_FILEINVALID, it has
already destroyed the ast_config struct for us. Trying to do it again
results in a crash.
Change-Id: If6a5c0ca718ad428e01a1fb25beb209a9ac18bc6
The realtime framework allows for components to look up values using a
LIKE clause with similar syntax to SQL's. pbx_realtime uses this
functionality to search for pattern matching extensions that start with
an underscore (_).
When passing an underscore to SQL's LIKE clause, it will be interpreted
as a wildcard matching a single character and therefore needs to be
escaped. It is (for better or for worse) the responsibility of the
component that is querying realtime to escape it with a backslash before
passing it in. Some RDBMs support escape characters by default, but the
SQL92 standard explicitly says that there are no escape characters
unless they are specified with an ESCAPE clause, e.g.
SELECT * FROM table WHERE column LIKE '\_%' ESCAPE '\'
This patch instructs 3 backends - res_config_mysql, res_config_pgsql,
and res_config_sqlite3 - to use the ESCAPE clause where appropriate.
Looking through documentation and source tarballs, I was able to
determine that the ESCAPE clause is supported in:
MySQL 5.0.15 (released 2005-10-22 - earliest version available from
archives)
PostgreSQL 7.1 (released 2001-04-13)
SQLite 3.1.0 (released 2005-01-21)
The versions of the relevant libraries that we depend on to access MySQL
and PostgreSQL will not work on versions that old, and I've added an
explicit check in res_config_sqlite3 to only use the ESCAPE clause when
we have a sufficiently new version of SQLite3.
res_config_odbc already handles the escape characters appropriately, so
no changes were required there.
ASTERISK-15858 #close
Reported by: Humberto Figuera
ASTERISK-26057 #close
Reported by: Stepan
Change-Id: I93117fbb874189ae819f4a31222df7c82cd20efa
There were two specific issues resolved here:
1) The code that iterated over the required fields
(via ast_realtime_require) was broken for the RQ_INTEGER1 field
type. Iteration would stop when the first RQ_INTEGER1 (0) field
was encountered.
2) sqlite3_changes() was used to try and count the number of rows
returned by a SELECT statement. sqlite3_changes() only counts
affected rows, so this was always returning the value from the
most recent data modification statement. We now separate read-only
queries from data modification queries and count rows appropriately
in both cases.
ASTERISK-23457 #close
Reported by: Scott Griepentrog
Change-Id: I91ed20494efc3fcfbc2a96ac7646999a49814884
This patch fixes 2 original issues and more that those 2 exposed.
* When we send a NOTIFY, and the client either doesn't respond or
responds with a non OK, pjproject only calls our
pubsub_on_evsub_state callback, no others. Since
pubsub_on_evsub_state (which does the sub_tree cleanup) does not
expect to be called back without the other callbacks being called
first, it just returns leaving the sub_tree orphaned. Now
pubsub_on_evsub_state checks the event for PJSIP_EVENT_TSX_STATE
which is what pjproject will set to tell us that it was the
transaction that timed out or failed and not the subscription
itself timing our or being terminated by the client. If is
TSX_STATE, pubsub_on_evsub_state now does the proper cleanup
regardless of the state of the subscription.
* When a client renews a subscription, we don't update the
persisted subscription with the new expires timestamp. This causes
subscription_persistence_recreate to prune the subscription if/when
asterisk restarts. Now, pubsub_on_rx_refresh calls
subscription_persistence_update to apply the new expires timestamp.
This exposed other issues however...
* When creating a dialog from rdata (which sub_persistence_recreate
does from the packet buffer) there must NOT be a tag on the To
header (which there will be when a client refreshes a
subscription). If there is one, pjsip_dlg_create_uas will fail.
To address this, subscription_persistence_update now accepts a flag
that indicates that the original packet buffer must not be updated.
New subscribes don't set the flag and renews do. This makes sure
that when the rdata is recreated on asterisk startup, it's done
from the original subscribe packet which won't have the tag on To.
* When creating a dialog from rdata, we were setting the dialog's
remote (SUBSCRIBE) cseq to be the same as the local (NOTIFY) cseq.
When the client tried to resubscribe after a restart with the
correct cseq, we'd reject the request with an Invalid CSeq error.
* The acts of creating a dialog and evsub by themselves when
recreating a subscription does NOT restart pjproject's subscription
timer. The result was that even if we did correctly recreate the
subscription, we never removed it if the client happened to go away
or send a non-OK response to a NOTIFY. However, there is no
pjproject function exposed to just set the timer on an evsub that
wasn't created by an incoming subscribe request. To address this,
we create our own timer using ast_sip_schedule_task. This timer is
used only for re-establishing subscriptions after a restart.
An earlier approach was to add support for setting pjproject's
timer (via a pjproject patch) and while that patch is still included
here, we don't use that call at the moment.
While addressing these issues, additional debugging was added and
some existing messages made more useful. A few formatting changes
were also made to 'pjsip show scheduled tasks' to make displaying
the subscription timers a little more friendly.
ASTERISK-26696
ASTERISK-26756
Change-Id: I8c605fc1e3923f466a74db087d5ab6f90abce68e
pjsip limits the total number of ICE candidates to PJ_ICE_MAX_CAND,
which is a compile-time constant. Instead of hard-coding 16 when we
enumerate local interfaces, use PJ_ICE_MAX_CAND so that we can
potentially collect more interfaces if the compile time options are
changed.
Tangentially related to ASTERISK~24464
Change-Id: I1b85509e39e33b1fed63c86261fc229ba14bbabd
* app_minivm: Use built-in completion facilities to complete optional
arguments.
* app_voicemail: Use built-in completion facilities to complete
optional arguments.
* app_confbridge: Add missing colons after 'Usage' text.
* chan_alsa: Use built-in completion facilities to complete optional
arguments.
* chan_sip: Use built-in completion facilities to complete optional
arguments. Add completions for 'load' for 'sip show user', 'sip show
peer', and 'sip qualify peer.'
* chan_skinny: Correct and extend completions for 'skinny reset' and
'skinny show line.'
* func_odbc: Correct completions for 'odbc read' and 'odbc write'
* main/astmm: Use built-in completion facilities to complete arguments
for 'memory' commands.
* main/bridge: Correct completions for 'bridge kick.'
* main/ccss: Use built-in completion facilities to complete arguments
for 'cc cancel' command.
* main/cli: Add 'all' completion for 'channel request hangup.' Correct
completions for 'core set debug channel.' Correct completions for 'core
show calls.'
* main/pbx_app: Remove redundant completions for 'core show
applications.'
* main/pbx_hangup_handler: Remove unused completions for 'core show
hanguphandlers all.'
* res_sorcery_memory_cache: Add completion for 'reload' argument of
'sorcery memory cache stale' and properly implement.
Change-Id: Iee58c7392f6fec34ad9d596109117af87697bbca
This change adds the media stream topology definition and API for
accessing and using it.
Some refactoring of the stream was also done.
ASTERISK-26786
Change-Id: Ic930232d24d5ad66dcabc14e9b359e0ff8e7f568
The original return value corresponded to AST_SIP_AUTHENTICATION_CHALLENGE
but we have no authenticator registered to create the challenge.
Change-Id: I62368180d774b497411b80fbaabd0c80841f8512
In Asterisk 11, if the 'Originate' AMI command failed to connect the provided
Channel while in extension mode, a 'failed' extension would be looked up and
run. This was, I believe, unintentionally removed in 51b6c49. This patch
restores that behavior.
This also adds an enum for the various 'synchronous' modes in an attempt to
make them meaningful.
ASTERISK-26115 #close
Reported by: Nasir Iqbal
Change-Id: I8afbd06725e99610e02adb529137d4800c05345d
This reverts commit 6492e91392.
The change in question was intended to prevent the need to reload in
order to update qualifies on contacts when an AOR changes. However, this
ended up causing a deadlock instead.
Change-Id: I1a835c90a5bb65b6dc3a1e94cddc12a4afc3d71e
The adding and removing of device state subscriptions did not protect
fully against simultaneous manipulation. In particular the subscribe
case allowed a small window where two subscriptions could be added for
the same device state instead of just one.
This change makes the code hold the subscriptions lock for the entirety
of each operation to ensure that two are not occurring at the same time.
ASTERISK-26770
Change-Id: I3e7f8eb9d09de440c9024d2dd52029f6f20e725b
A dialplan intercept routine is equivalent to an interrupt routine. As
such, the routine must be done quickly and you do not have access to the
media stream. These restrictions are necessary because the media stream
is the responsibility of some other code and interfering with or delaying
that processing is bad. A possible future dialplan processing
architecture change may allow the interception routine to run in a
different thread from the main thread handling the media and remove the
execution time restriction.
* Made res_agi.c:run_agi() running an AGI in an interception routine run
in DeadAGI mode. No touchy channel frames.
ASTERISK-25951
ASTERISK-26343
ASTERISK-26716
Change-Id: I638f147ca7a7f2590d7194a8ef4090eb191e4e43
Prior to this change, qualifies would only update in the following
cases:
* A reload of res_pjsip.so was issued.
* A dynamic contact was re-registered after its AOR's qualify_frequency
had been changed
This does not work well if you are using realtime for your AORs. You can
update your database to have a new qualify_frequency, but the permanent
contacts on that AOR will not have their qualifies updated. And the
dynamic contacts on that AOR will not have their qualifies updated until
the next registration, which could be a long time.
This change seeks to fix this problem by making it so that whenever AOR
configuration is applied, the contacts pertaining to that AOR have their
qualifies updated.
Additions from this patch:
* AOR sorcery objects now have an apply handler that calls into a newly
added function in the OPTIONS code. This causes all contacts
associated with that AOR to re-schedule qualifies.
* When it is time to qualify a contact, the OPTIONS code checks to see
if the AOR can still be retrieved. If not, then qualification is
canceled on the contact.
Alterations from this patch:
* The registrar code no longer updates contact's qualify_frequence and
qualify_timeout. There is no point to this since those values already
get updated when the AOR changes.
* Reloading res_pjsip.so no longer calls the OPTIONS initialization
function. Reloading res_pjsip.so results in re-loading AORs, which
results in re-scheduling qualifies.
Change-Id: I2e7c3316da28f389c45954f24c4e9389abac1121
There are some error cases in PJSIP when sending a request that will
result in the callback for the request being invoked. The code did not
handle this case and assumed on every error case that the callback was not
invoked.
The code has been changed to check whether the callback has been invoked
and if so to absorb the error and treat it as a success.
ASTERISK-26679
ASTERISK-26699
Change-Id: I563982ba204da5aa1428989a11c06dd9087fea91
Before Asterisk 13, signed linear was converted into network byte order by a
smoother before being sent over the network. We restore this behavior by
forcing the creation of a smoother when slinear is in use and setting the
appropriate flags so that the byte order conversion is always done.
ASTERISK-24858 #close
Reported-by: Frankie Chin
Change-Id: I868449617d1a7819578f218c8c6b2111ad84f5a9
The escalator works by creating a set of startup commands in cli.conf
that set up logger channels and issue the debug commands for the
subsystems specified. If asterisk is running when it is executed,
the same commands will be issued to the running instance. The original
cli.conf is saved before any changes are made and can be restored by
executing '$prog --reset'.
The log output will be stored in...
$astlogdir/message.$uniqueid
$astlogdir/debug.$uniqueid
$astlogdir/dtmf.$uniqueid
$astlogdir/fax.$uniqueid
$astlogdir/security.$uniqueid
$astlogdir/pjsip_history.$uniqueid
$astlogdir/sip_history.$uniqueid
Some minor tweaks were made to chan_sip, and res_pjsip_history
so their history output could be send to a log channel as packets
are captured.
A minor tweak was also made to manager so events are output to verbose
when "manager set debug on" is issued.
Change-Id: I799f8e5013b86dc5282961b27383d134bf09e543
This change adds a missing unreference of the hostname when resolving and
also cleans up the iterator.
ASTERISK-26735
Change-Id: Ic012ebaf3d89e714eec340b7b0c5e63c66af857a
Marking an object as stale in a memory cache is supposed to prime the
cache so that the next time the item is retrieved, the stale item is
deleted from the cache and a background task is run to re-populate the
cache with a fresh version of the object.
The problem is, there are some object types out there for which there is
no natural reason that they would be retrieved from the backend with any
regularity. Outbound PJSIP registrations are a good example of this. At
startup, they are read, and an object-specific state is created that
refers to the initially-retrieved object for all time.
Adding the "reload" option to the CLI/AMI commands gives the cache the
opportunity to manually re-retrieve the object from the backend, both
storing the new object in the cache and applying the new object's
configuration to the module that uses that object.
Change-Id: Ieb1fe7270ceed491f057ec5cbf0e097bde96c5c8
* channel.c:ast_sendtext(): Fix T.140 SendText memory leak.
* format_compatibility.c: T.140 RED and T.140 were swapped.
* res_rtp_asterisk.c:rtp_red_init(): Fix ast_format_t140_red ref leak.
* res_rtp_asterisk.c:rtp_red_init(): Fix data race after starting periodic
scheduled red_write().
* res_rtp_asterisk.c: Some other minor misc tweaks.
Change-Id: Ifa27a2e0f8a966b1cf628607c86fc4374b0b88cb
When configuring a match using a netmask the error variable was
not defaulting to 0. For some people this would cause the code
to think an error occurred when adding the match when in reality
it added perfectly fine.
ASTERISK-26693
Change-Id: I850c250813742bddde65c84e739093c9e01dfe56
The mechanism used for detecting the maximum log level compiled into the
linked pjproject did not work. The API call simply stores the requested
level into an integer and does no range checking. Asterisk was assuming
that there was range checking and limited the new value to the allowable
range. To get the actual maximum log level compiled into the linked
pjproject we need to get and save off the initial set log level from
pjproject. This is the maximum log level supported.
* Get and save off the initial log level setting before altering it to the
desired level on startup. This has to be done by a macro rather than
calling a core function to avoid incorrectly linking pjproject.
* Split the initial log level warning messages to warn if the linked
pjproject cannot support the requested startup level and if it is too low
to get the pjproject buildopts for "pjproject show buildopts".
* Adjust the CLI "pjproject set log level" to check the saved max log
level and to generate normal output messages instead of a warning message.
ASTERISK-26743 #close
Change-Id: I40aa76653e2a1dece66c3f8734594b4f0471cfb4
zuul
George Joseph
Sean Bright
Joshua Colp
Richard Mudgett
Mark Michelson