| Age | Commit message (Collapse) | Author |
|---|
|
During ICE negotiation the IPs of the local interfaces are sent to the remote
peer as host candidates. In many cases Asterisk is behind a static one-to-one
NAT, so these host addresses will be internal IP addresses.
To help in hiding the topology of the internal network, this patch adds the
ability to override the host candidates by matching them against a
user-defined list of replacements.
Change-Id: I1c9541af97b83a4c690c8150d19bf7202c8bff1f
|
|
|
|
overflow." into 13
|
|
Sending UDPTL packets to Asterisk with the right amount of missing
sequence numbers and enough redundant 0-length IFP packets, can make
Asterisk crash.
ASTERISK-25603 #close
Reported by: Walter Doekes
ASTERISK-25742 #close
Reported by: Torrey Searle
Change-Id: I97df8375041be986f3f266ac1946a538023a5255
|
|
This change exposes the configuration of various aspects of the TLS
support and sets the default to the modern standards.
The TLS cipher is now set to the best values according to the
Mozilla OpSec team, different TLS versions can now be disabled, and
the cipher order can be forced to be that of the server instead of
the client.
ASTERISK-24972 #close
Change-Id: I0a10f2883f7559af5e48dee0901251dbf30d45b8
|
|
Setting the sip.conf timert1 value to a value higher than 1245 can cause
an integer overflow and result in large retransmit timeout times. These
large timeout times hold system file descriptors hostage and can cause the
system to run out of file descriptors.
NOTE: The default sip.conf timert1 value is 500 which does not expose the
vulnerability.
* The overflow is now detected and the previous timeout time is
calculated.
ASTERISK-25397 #close
Reported by: Alexander Traud
Change-Id: Ia7231f2f415af1cbf90b923e001b9219cff46290
|
|
test_dlinklists doesn't need to NOTICE everyone that every macro worked.
res_phoneprov doesn't need to VERBOSE everyone that a phoneprov extension or
provider was registered.
res_odbc was missing a newline at the end of one message.
Change-Id: I6c06361518ef3711821795e535acd439782a995e
|
|
|
|
asterisk's own ip." into 13
|
|
A regression was introduced where searching for realtime PJSIP objects
by regex by starting the regex with a leading "^" would cause no items
to be returned.
This was due to a change which attempted to drop the requirement for a
leading "^" to be present due to how some CLI commands formulate their
regexes. However, the change, rather than simply eliminating the
requirement, caused any regexes that did begin with "^" to end up not
returning the expected results.
This change fixes the problem by inspecting the regex and formulating
the realtime query differently depending on if it begins with "^".
ASTERISK-25702 #close
Reported by Nic Colledge
Patches:
realtime_retrieve_regex.patch submitted by Alexei Gradinari License #5691
Change-Id: I055df608a6e6a10732044fa737a9fe8dca602693
|
|
The module res_xmpp does not accept usernames in the form used in component
mode (XEP-0114). In component mode there is no @something in the name.
In component mode the connection is now not dropped anymore.
If the xmpp server sends out a "stream" tag before handshake is finished,
the connection gets dropped in res_xmpp. Now this tag will be ignored and
the connection will be established.
After connecting there will be an exchange of presence states. This does
not work as expected in component mode. The responsible function
"xmpp_pak_presence" is left before the states get sent out. Sending
presence states in component mode is now moved to the top of the function.
ASTERISK-25735 #close
Change-Id: I70e036f931c3124ebb2ad1e56f93ed35cfdd9d5c
|
|
|
|
Fix some warnings found with clang.
Change-Id: I5195b6189b148c2ee3ed4a19d015a6d4ef3e77bd
|
|
The "clean" target was attempting to clean res/ari from inside
the res directory which doesn't remove anything. Removed the res/
prefix.
Change-Id: Ib1a518d54efa81b9fd5a42742d43cc3767435bf6
|
|
A recent commit set qualify_timeout to Decimal which isn't supported.
This path corrects it to Float.
Change-Id: I038f5274ba8cb60f8518a5845ce448d49306aadf
|
|
When I ask asterisk to send a SIP NOTIFY message to a sip peer using either a)
AMI action: SIPnotify or b) cli command: sip notify <cmd> <peer>, I expect
asterisk to include the same value for its own ip in both cases a) and b),
but it seems a) produces a contact header like Contact:
<sip:asterisk@192.168.1.227:8060> whereas b) produces a contact header like
<sip:asterisk@127.0.0.1:8060>. 0.0.0.0:8060 is my udpbindaddr in sip.conf
My guess is that manager_sipnotify should call
ast_sip_ouraddrfor(&p->sa, &p->ourip, p) the same way sip_cli_notify does,
because after applying this patch, both cases a) and b) produce
the contact header that I expect: <sip:asterisk@192.168.1.227:8060>
Reported by: Stefan Engström
Tested by: Stefan Engström
Change-Id: I86af5e209db64aab82c25417de6c768fb645f476
|
|
Asterisk by default will create a single database connection and share
it among all threads that attempt to access the database. In previous
versions of Asterisk, this was tolerable, because the most used channel
driver, chan_sip, mostly accessed the database from a single thread.
With PJSIP, however, many threads may be attempting to perform database
operations, and there is the potential for many more database accesses,
meaning the concurrency is a horrible bottleneck if only one connection
is shared.
Asterisk has a connection pooling facility built into it, but the
implementation has flaws. For one, there is a strict limit on the number
of simultaneous connections that could be made to the database. Anything
beyond the maximum would result in a failed operation. Attempting to
predict what the maximum should be is nearly impossible even for someone
intimately familiar with Asterisk's threading model. In addition, use of
transactions in the dialplan can cause some severe bugs if connection
pooling is enabled.
This commit seeks to fix the concurrency problem by removing all
connection management code from Asterisk and leaving that to the
underlying unixODBC code instead. Now, Asterisk does not share a single
connection, nor does it try to maintain a connection pool. Instead, all
Asterisk ever does is request a connection from unixODBC and allow
unixODBC to either allocate those connections or retrieve them from a
pool.
Doing this has a bit of a ripple effect. For one, since connections are
not long-lived objects, several of the safeguards that previously
existed have been removed. We don't have to worry about trying to use a
connection that has gone stale. In every case, when we request a
connection, it has just been made and we don't need to perform any
sanity checks to be sure it's still active.
Another major player affected by this change is transactions.
Transactions and their respective connections were so tightly coupled
that it was almost pornographic. This code change moves
transaction-related code to its own file separate from the core ODBC
functionality. This way, the core of ODBC does not even have to know
that transactions exist.
In making this large change, I had to look at a lot of code and
understand it. When making this change, I discovered several places
where the behavior is definitely not ideal, but it seemed outside the
scope of this change to be fixing it. Instead, any place where I saw
some sort of room for improvement has had a XXX comment added explaining
what could be altered to improve it.
Change-Id: I37a84def5ea4ddf93868ce8105f39de078297fbf
|
|
missing" into 13
|
|
into 13
|
|
Change-Id: I915ea437936320393afde0e7552cf0a980a6b2e4
|
|
Change-Id: Ida5594e9f8d7c1fc18eeb733a11f8fb96326da51
|
|
* Added CONFBRIDGE_INFO(muted,) for querying the muted conference state.
* Added Muted header to AMI ConfbridgeListRooms action response list
events to indicate the muted conference state.
* Added Muted column to CLI "confbridge list" output to indicate the muted
conference state and made the locked column a yes/no value instead of a
locked/unlocked value.
ASTERISK-20987
Reported by: hristo
Change-Id: I4076bd8ea1c23a3afd4f5833e9291b49a0c448b1
|
|
Change-Id: Ic1f9e22ba1f2ff3b3f5cb017c5ddcd9bd48eccc7
|
|
ASTERISK-20987 #close
Reported by: hristo
Change-Id: Ic61a2b524ab3a4cfadf227fc6b3506527bc03f38
|
|
Since res_pjsip now depends on res_pjproject, this is now mentioned
in UPGRADE.txt and the basic-pbx modules.conf has been updated.
Change-Id: I42826597d5e10f08e518208860c44c96e52f1b2d
|
|
The Makefile only optionally includes makeopts so when goals like uninstall that
dont depend on anything else are run after a distclean, rules like
'rm -f "$(DESTDIR)$(ASTMODDIR)/"*' get run as 'rm -f ""/*' which attempts
to remove everything in the root directory.
Although there's a rule defined for makeopts which prints a message and does
an 'exit 1', since '-include makepopts' was specified (with the -), the exit
was ignored letting the rest of the rules run.
This patch makes makeopts required unless the goal has the string 'clean' in it.
ASTERISK-25730 #close
Reported-by: George Joseph
Change-Id: I1bce59a7ea4f48e7a468e22b2abbb13c63417ac7
|
|
|
|
The config options framework is strict in that configuration options must
be documented unless XML documentation support is not available. In
practice this is useful as it ensures documentation exists however in
off-nominal cases this can cause strange problems.
If it is expected that a config option has a non-zero or non-empty
default value but the config option documentation is unavailable
this reasonable expectation will not be met. This can cause obscure
crashes and weirdness depending on how the code handles it.
This change tweaks the behavior to ensure that the config option
is still allowed to register, apply default values, and be set when
devmode is not enabled. If devmode is enabled then the option can
NOT be set.
This also does not remove the initial documentation error message that
is output on load when registering the configuration option.
ASTERISK-25725 #close
Change-Id: Iec42fca6b35f31326c33fcdc25473f6fd7bc8af8
|
|
A recent change to queue channel variable setting to the Stasis control
queue caused a regression. When setting channel variables, it is
possible to give a NULL channel variable value in order to unset the
variable (i.e. remove it from the channel variable list). The change
introduced a call to ast_variable_new(), which is not tolerant of NULL
channel variable values.
This new change switches from using ast_variable to using a custom
channel variable struct that is lighter weight and NULL value-tolerant.
Change-Id: I784d7beaaa3c036ea936d103e7caf0bb1562162d
|
|
subscription." into 13
|
|
Core and extra sounds 1.5 was recently released! The tarballs contain
change descriptions however I figure more people will see this one so
I'll try to be a bit detailed. Approximately 60 sounds were moved from Extra
to Core for en, en_GB, fr and added for languages that didn't already
have Extra sound sets (it,ja,ru).
In addition all of the English and Russian sounds have been completely
re-recorded.
Sounds moved and added:
activated,added,all-circuits-busy-now,astcc-followed-by-pound
at-tone-time-exactly,call-forwarding,call-fwd-no-ans,call-fwd-on-busy
,call-fwd-unconditional,calling,call-waiting,cancelled,
cannot-complete-as-dialed,check-number-dial-again,conf-full,de-activated
,disabled,do-not-disturb,enabled,enter-num-blacklist,entr-num-rmv-blklist
,extension,feature-not-avail-line,for,from-unknown-caller,goodbye,hello
,if-correct-press,im-sorry,info-about-last-call,is,is-in-use,is-set-to
,location,number,number-not-answering,num-was-successfully,one-moment-please
,please-try-again,pls-hold-while-try,pls-try-call-later,pm-invalid-option
,privacy-to-blacklist-last-caller,removed,simul-call-limit-reached
,something-terribly-wrong,sorry,sorry-youre-having-problems,speed-dial
,speed-dial-empty,telephone-number,time,to-call-this-number,to-extension
,to-listen-to-it,to-rerecord-it,unidentified-no-callback,with,you-entered
,your
There were also a few random fixes here and there to file names for a few
of the languages.
ASTERISK-25068 #close
Change-Id: I2b594344ec585d7dfd922b40c1af43b1508828b3
|
|
A test recently uncovered that running an ill-timed AMI command to show
inbound subscriptions could cause a crash since Asterisk will try to
operate on a freed subscription.
The fix for this is to remove the subscription tree from the list of
subscriptions at the time that we are sending our final NOTIFY request
out. This way, as the subscription is in the process of dying, it is
inaccessible from AMI.
Change-Id: Ic0239003d8d73e04c47c12dd2a7e23867e5b5b23
|
|
sip_sipredirect uses sscanf to copy up to 256 characters to a stacked buffer
of 256 characters. This patch reduces the copy to 255 characters to leave
room for the string null terminator.
ASTERISK-25722 #close
Change-Id: Id6c3a629a609e94153287512c59aa1923e8a03ab
|
|
|
|
When queuing tasks onto the Stasis control queue, you can pass an
arbitrary data pointer and a function to free that data. All ARI
commands that use the Stasis control queue made the assumption that the
destructor function would be called in all paths, whether the task was
queued successfully or not. However, this was not correct. If a task was
queued onto a control structure that was already completed, the
allocated data would not be freed properly.
This patch corrects this by making sure that all return paths call the
data destructor.
Change-Id: Ibf06522094f8e5c4cce652537dc5d7222b1c4fcb
|
|
A crash occurred when attempting to set a channel variable on a channel
that had already been hung up. This is because there is a small window
between when a control is grabbed and when the channel variable is set
that the channel can be hung up.
The fix here is to queue the setting of the channel variable onto the
control queue. This way, the manipulation of the channel happens in a
thread where it is safe to be done.
In this change, I also noticed that the setting of bridge roles on
channels was being done outside of the control queue, so I also changed
those operations to be done in the control queue.
ASTERISK-25709 #close
Reported by Mark Michelson
Change-Id: I2a0a4d51bce6fba6f1d9954e40935e42f366ea78
|
|
The null terminator of the tail struct member was not being allocated
when no logger.conf config file is installed.
ASTERISK-25714 #close
Reported by: Badalian Vyacheslav
Change-Id: I45770fdd08af39506a3bc33ba279c4f16e047a30
|
|
|
|
case." into 13
|
|
* Add 'check-alembic' target to root Makefile.
* Create build_tools/make_check_alembic to do the actual checks.
ASTERISK-25685
Change-Id: Ibb3cae7d1202ac23dc70b0f3b5801571ad46b004
|
|
ASTERISK-25712 #close
Reported by: Richard Mudgett
Change-Id: I70634df24f8c6c3a2c66c45af61d021e4999253f
|
|
Make sure buf[res] is not accessed at res=-1 (buffer underrun).
Address Sanitizer will complain about this quite loudly.
ASTERISK-24801 #close
Change-Id: Ifcd7f691310815a31756b76067c56fba299d3ae9
|
|
Dump the res_pjsip endpt internals.
In non-developer mode we will not document or make easily accessible the
"details" option even though it is still available. The user has to know
it exists to use it. Presumably they would also be aware of the potential
crash warning below.
Warning: PJPROJECT documents that the function used by this CLI command
may cause a crash when asking for details because it tries to access all
active memory pools.
Change-Id: If2d98a3641c9873364d1daaad971376311aef3cb
|
|
into 13
* changes:
taskprocessor.c: Increase CLI "core ping taskprocessor" timeout.
taskprocessor.c: Fix some taskprocessor unrefs.
|
|
|
|
and billsec" into 13
|
|
res_pjproject" into 13
|
|
When CDRs were refactored, func_cdr's ability to report high precision values
for duration and billsec (the 'f' option) was broken. This was due to func_cdr
incorrectly interpreting the duration/billsec values provided by the CDR engine
in milliseconds, as opposed to seconds. Since the CDR engine only provides
duration and billsec in seconds, and does not expose either attribute with
sufficient precision to merely pass back the underlying value, this patch fixes
the bug by re-calculating duration and billsec with microsecond precision based
on the start/answer/end times on the CDR.
ASTERISK-25179 #close
Change-Id: I8bc63822b496537a5bf80baf6102c06206bee841
|
|
res_pjsip_log_forwarder has been renamed to res_pjproject
and enhanced as follows:
As a follow-on to the recent 'Add CLI "pjsip show buildopts"' patch,
a new ast_pjproject_get_buildopt function has been added. It
allows the caller to get the value of one of the buildopts.
The initial use case is retrieving the runtime value of
PJ_MAX_HOSTNAME to insure we don't send a hostname greater
than pjproject can handle. Since it can differ between
the version of pjproject that Asterisk was compiled against
and the version of pjproject that Asterisk is running against,
we can't use the PJ_MAX_HOSTNAME macro directly in Asterisk
source code.
Change-Id: Iab6e82fec3d7cf00c1cf6185c42be3e7569dee1e
|
|
into 13
|
