In order to retrieve an arbitrary sorcery instance from a dialplan function
(or any place else) there needs to be a registry of sorcery instances.
ast_sorcery_init now creates a hashtab as a registry.
ast_sorcery_open now checks the hashtab for an existing sorcery instance
matching the caller's module name. If it finds one, it bumps the
refcount and returns it. If not, it creates a new sorcery instance,
adds it to the hashtab, then returns it.
ast_sorcery_retrieve_by_module_name is a new function that does a hashtab
lookup by module name. It can be called by the future dialplan function.
res_pjsip/config_system needed a small change to share the main res_pjsip
sorcery instance.
tests/test_sorcery was updated to include a test for the registry.
(closes issue ASTERISK-22537)
Review: http://reviewboard.asterisk.org/r/3184/
........
Merged revisions 408518 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@408519 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When 'use_avpf' is set to True, inbound offers must use the AVPF/SAVPF RTP
profile. However, when 'use_avpf' is set to False, Asterisk will accept
both AVP/SAVP or AVPF/SAVPF RTP profiles in inbound offers. The documentation
previously implied that Asterisk would reject AVPF/SAVPF if 'use_avpf' was
set to False and a UA offered said profile in an INVITE request.
........
Merged revisions 408502 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@408503 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The sorcery astDB wizzard does not handle regex correctly if the pattern
begins with an anchor character.
This patch attempts to convert the anchored regex pattern to a prefix
pattern supported by astDB for performance reasons. If it is not able to
convert the pattern it falls back to getting all astDB members of the
family and doing a normal regex pattern matching on the retrieved records.
Review: https://reviewboard.asterisk.org/r/3161/
........
Merged revisions 408385 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@408386 65c4cc65-6c06-0410-ace0-fbb531ad65f3
It is highly unlikely, but - at least in Asterisk 12 - theoretically possible
to load Asterisk with no dialplan whatsoever. If that occurs, and some other
module (that is not a pbx module) attempts to merge its contexts into the
dialplan, the existing merge routine will crash. This is because it is not
insane, and rightly believes that you provided some sort of dialplan,
somewhere.
This patch will gracefully merge the contexts in such a case. Note that this
is highly unlikely to occur in 1.8/11, as features will most likely provide
some dialplan via parking. However, in Asterisk 12, parking is now provided
by res_parking, and hence may create its dialplan later.
(closes issue ASTERISK-23297)
Reported by: CJ Oster
Review: https://reviewboard.asterisk.org/r/3222
........
Merged revisions 408200 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 408201 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 408220 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@408227 65c4cc65-6c06-0410-ace0-fbb531ad65f3
URI's are supposed to be case sensitive and all
lower case. In practice some portions of URI's
in ARI are case insensitive and others are not,
such as TECH, which in one instance would match
a lower case name and in another would not. In
this patch, the ast_endpoint_lastest_snapshot()
function is modified to change the TECH portion
to full upper case before lookup. This resolves
the discrepancy noted by the reporter. However
I chose to avoid forcing the /ari prefix of the
URI's to be lower case for now. Except for the
two cases here, all URI's should be lower case,
unless they are part of a resource name or id.
Review: https://reviewboard.asterisk.org/r/3211/
Reported by: Zane Conkle
(closes issue ASTERISK-23125)
........
Merged revisions 408140 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@408141 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In ast_format_sdp_parse and ast_format_sdp_generate
the check checks for a valid interface and function
were potentially confusing, and hid an error in the
test of the presence of the function that is called
later. This patch clears up and corrects the test.
Review: https://reviewboard.asterisk.org/r/3208/
(closes issue ASTERISK-23098)
Reported by: marcelloceschia
Patches:
main_format.patch uploaded by marcelloceschia (license 6036)
ASTERISK-23098.patch uploaded by coreyfarrell (license 5909)
........
Merged revisions 408137 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 408138 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@408139 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch moves setting SIP_DEFER_BY_ON_TRANSFER prior to calling
ast_bridge_transfer_blind. This prevents a BYE from being sent prior to the
NOTIFY request that informs the transferor if the transfer succeeded or failed.
This patch also clears said flag from the off nominal NOTIFY paths in the
local_attended_transfer code, as once we've sent the NOTIFY request it is safe
to send by the BYE request.
This was caught by the blind-transfer-accountcode test in the Asterisk Test
Suite.
(closes issue ASTERISK-23290)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3214/
........
Merged revisions 408069 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@408070 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If an AOR has no permanent contacts, then the
permanent_contacts container is never allocated.
This makes the code safe in the face of NULLs.
I also changed the variable that counts contacts
from "num" to "total_contacts" since there are now
two variables that are indicate numbers of things.
........
Merged revisions 407988 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@407990 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The old code depended on undefined va_arg behaviour: calling a function
twice with the same va_list parameter and expecting it to continue where
it left off. The changed code behaves like the manpage says it should.
Also added a bunch of early returns to trap errors (e.g. OOM) instead of
crashing.
The problem was found by Julian Lyndon-Smith. The deviant behaviour on
the raspberry PI also uncovered another bug (fixed in r407875) in the
res_config_pgsql.so driver.
Reported by: jmls
Tested by: jmls
Review: https://reviewboard.asterisk.org/r/3201/
........
Merged revisions 407968 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@407970 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This is a first stab at tweaking the performance profile of the scheduler. Removing
the hashtab usage removes an extra memory allocation when scheduling something and
makes it so rescheduling does not incur any memory allocation at all.
Review: https://reviewboard.asterisk.org/r/3199/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@407958 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch tweaks the behaviour of POST /channels with channel variables such
that the variables are passed into the pbx.c routines that perform the
origination. This allows the variables to be assigned to the newly created
channels immediately upon their construction, as opposed to be assigned after
the originate has completed.
The upshot of this is that the variables are available on the channels if
they execute in the dialplan, as opposed to only being available once the
channels are answered.
Review: https://reviewboard.asterisk.org/r/3183/
........
Merged revisions 407937 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@407940 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Move route code to sip/route.c + sip/include/route.h
* Rename functions to sip_route_*
* Replace ad-hoc list code with macro's from linkedlists.h
* Create sip_route_process_header() to processes Path and Record-Route headers
(previously done with different code in build_route and build_path)
* Add use of const where possible
* Move struct uriparams, struct contact and contactliststruct from sip.h to
reqresp_parser.h. sip/route.c uses reqresp_parser.h but not sip.h, this was
a problem. These moved declares are not used outside of reqresp_parser.
* While modifying reqprep() the lack of {} caused me trouble. I added them.
* Code outside route.c treats sip_route as an opaque structure, using macro's
or procedures for all access.
(closes issue ASTERISK-22582)
Reported by: Corey Farrell
Review: https://reviewboard.asterisk.org/r/3173/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@407926 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Currently, when the first marked user enters the conference that
contains waitmarked users, a prompt is played indicating that the user
is being placed into the conference. Unfortunately, this prompt is
played to the marked user and not the waitmarked users which is not
very helpful.
This patch changes that behavior to play a prompt stating
"The conference will now begin" to the entire conference after adding
and unmuting the waitmarked users since the design of confbridge is not
conducive to playing a prompt to a subset of users in a conference in
an asynchronous manner.
(closes issue PQ-1396)
Review: https://reviewboard.asterisk.org/r/3155/
Reported by: Steve Pitts
........
Merged revisions 407857 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 407858 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@407859 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When formatting an optional IE, the value is, of course, optional. As such, it
is entirely appropriate for ast_json_object_get to return NULL. If that occurs,
we now simply skip the IE that was requested, as it was not provided by the
entity that raised the event.
Thanks to George Joseph (gtjoseph) for catching this and reporting it in
#asterisk-dev
........
Merged revisions 407750 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@407752 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change allows timing implementation data to be stored directly
on the timer itself thus removing the requirement for many
implementations to do a container lookup for the same information.
This means that API calls into timing implementations can directly
access the information they need instead of having to find it.
Review: https://reviewboard.asterisk.org/r/3175/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@407749 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When extracting timestamps that are parsed, time stamp values that are not set
(time values of 0.000000) should not actually result in a parsed string. The
value should be skipped, and the result of the CDR function should be an
empty string.
Prior to this patch, the result was fed to the time formatting, which would
result in an output of a date/time in 1969.
........
Merged revisions 407747 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@407748 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Establishing an IAX2 call between Asterisk v1.4 and v1.8 (or later)
results in an unexpected call disconnect. The problem happens because
newer values in the enum ast_control_frame_type are not consistent between
the branch versions of Asterisk.
For example:
1) v1.4 calls v1.8 (or later) using IAX2
2) v1.8 answers and sends a connected line update control frame. (on v1.8
AST_CONTROL_CONNECTED_LINE = 22)
3) v1.4 receives the control frame as an end-of-q (on v1.4
AST_CONTROL_END_OF_Q = 22)
4) v1.4 disconnects the call once the receive queue becomes empty.
Several things are done by this patch to fix the problem and attempt to
prevent it from happening again in the future:
* Added a warning at the definition of enum ast_control_frame_type about
how to add new control frame values.
* Made block sending and receiving control frames that have no reason to
go over the wire.
* Extended the connectedline iax.conf parameter to also include the
redirecting information updates.
* Updated the connectedline iax.conf parameter documentation to include a
notice that the parameter must be "no" when the peer is an Asterisk v1.4
instance.
(closes issue AST-1302)
Review: https://reviewboard.asterisk.org/r/3174/
........
Merged revisions 407678 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 407727 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 407729 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@407731 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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
If an enum had been previously created the alembic script would attempt to
re-create it and an error would be generated while running migrations for a
postgresql server. The work around for this is to use the ENUM object type
for postgres as opposed to the generic enum type used by sqlalchemy. Using
this type in the script seems to work properly for both postgres and mysql.
........
Merged revisions 407572 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@407574 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Adds identify, transport, and registration support to the PJSIP CLI.
* Creates three additional callbacks, one for an iterator, one for a
comparator, and one for a container. This eliminates the link dependency
from higher level modules to lower level ones.
* Eliminates duplicate sorting in PJSIP CLI commands.
* Cleans up PJSIP CLI output formatting.
* Pushes CLI command registration down to the implementing source file.
* Adds several ast_sip_destroy_sorcery functions to complement existing
ast_sip_sorcery_initialize functions. The destroy functions unregister
PJSIP CLI commands and PJSIP CLI formatters.
Reported by: George Joseph
Review: https://reviewboard.asterisk.org/r/3104/
........
Merged revisions 407568 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@407573 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The changes log was written with language that was a little too internal
Asterisk specific, so it's been changed to be more in the frame of reference
of an ARI user. Also, previously the AMI event changes were omitted from the
change log as well as the ability to include a bridge name in the ARI post
bridges command.
........
Merged revisions 407461 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@407462 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If the global section was not specified in pjsip.conf then the configuration
object does not exist in sorcery so when retrieving "debug" option it would
return NULL. Then the NULL result was passed to ast_false utils function
which would return false because it wasn't set to some representation of
false, thus enabling sip debug logging. Made it so if the global config object
does not exist then it will return a default of "no" for sip debugging.
(issue ASTERISK-23038)
Reported by: Rusty Newton
........
Merged revisions 407442 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@407443 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The code assumed that unregistering the alias would always succeed while in
practice this is not actually true. A common case is the "reload" command itself.
If the cli_aliases.conf configuration file was changed and reload executed the
command would fail to unregister and ultimately point to freed memory.
The reload process now checks whether unregistering succeeded or not and if not
the old CLI alias is retained.
(closes issue ASTERISK-19773)
Reported by: Joel Vandal
(closes issue ASTERISK-22757)
Reported by: Gareth Blades
........
Merged revisions 407205 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 407210 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 407213 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@407217 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Locking issues in skinny when picking up a call that doesn't exist. Cleaned
up sub locking by fully removing and using the chan lock instead. Also
changed ast_call_pickup to check whether chan was masq'd.
(closes issue ASTERISK-23249)
Reported by: wedhorn
Tested by: snuffy, myself
Patches:
skinny-locking01.diff uploaded by wedhorn (license 5019)
........
Merged revisions 407197 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@407198 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
