Age | Commit message (Collapse) | Author |
|
|
|
Some external packages have multiple variants that apply to different
builds of asterisk. The DPMA for instance has a "bundled" variant that
needs to be downloaded if asterisk was configured with
--with-pjproject-bundled.
There are 2 ways to specify variants:
If you need the user to make the decision about which variant to
download, simply create multiple menuselect "member" entries like so...
<member name="res_digium_phone" displayname="..snipped..">
<support_level>external</support_level>
<depend>xmlstarlet</depend>
<depend>bash</depend>
<defaultenabled>no</defaultenabled>
</member>
<member name="res_digium_phone-bundled" displayname="..snipped..">
<support_level>external</support_level>
<depend>xmlstarlet</depend>
<depend>bash</depend>
<defaultenabled>no</defaultenabled>
</member>
Note that the second entry has "-<variant>" appended to the name.
You can then use the existing menuselect facilities to restrict which
members to enable or disable. Youy probably don't want the user to
enable multiple at the same time.
If you want to hide the details of the variants, the better way to
do it is to create 1 member with "variant" elements.
<member name="res_digium_phone" displayname="..snipped..">
<support_level>external</support_level>
<depend>xmlstarlet</depend>
<depend>bash</depend>
<defaultenabled>no</defaultenabled>
<member_data>
<downloader>
<variants>
<variant tag="bundled"
condition='[[ "$PJPROJECT_BUNDLED" = "yes" ]]'/>
</variants>
</downloader>
</member_data>
</member>
The condition must be a bash expression suitable for use with an "if"
statement. Any environment variable can be used plus those available
in makeopts.
In this case, if asterisk was configured with --with-pjproject-bundled
the bundled variant will be automatically downloaded. Otherwise the
normal version will be downloaded.
Change-Id: I4de23e06d4492b0a65e105c8369966547d0faa3e
|
|
|
|
mailboxes" into 13
|
|
HANGUPCAUSE not return 'SIP 200 Ok' when dialed channel answered.
This patch change the call order of ast_queue_control_data
and ast_queue_control in chan_pjsip_incoming_response.
ASTERISK-26396 #close
Reported by: AaronAn
Tested by: AaronAn
Change-Id: Ide2d31723d8d425961e985de7de625694580be61
|
|
For the channel driver chan_sip, you specify externhost=example.com in sip.conf
when your Asterisk is behind a NAT and your IP address is assigned dynamically.
Or stated differently: You do not have a static IP address to use "externaddr"
directly. This NAT support is quite handy but just about IPv4. Previously,
Asterisk resolved "externhost" to any IP version. When the first DNS answer
resolved to an IPv6, Asterisk sent an IPv6 in SIP/SDP for origin (o=) and
connection (c=). This happened in outgoing SIP-REGISTER and while answering
SIP-INVITE. If the remote peer is IPv4-only, it might not handle o=/c= with an
IPv6. This change makes sure, no IPv6 is resolved anymore for "externhost".
ASTERISK-18232 #close
Reported by: Jacek Kowalski
Tested by: Alexander Traud
patches:
changes.patch submitted by Alessandro Crespi
Change-Id: If68eedbeff65bd1c1d8a9ed921c02ba464b32dac
|
|
Users upgrading from asterisk 13.5 to a later version and who use
realtime with peers that have mailboxes were experiencing runaway
situations that manifested as a continuous stream of taskprocessor
congestion errors, memory leaks and an unresponsive chan_sip.
A related issue was that setting rtcachefriends=no NEVER worked in
asterisk 13 (since the move to stasis). In 13.5 and earlier, when a
peer tried to register, all of the stasis threads would block and
chan_sip would again become unresponsive. After 13.5, the runaway
would happen.
There were a number of causes...
* mwi_event_cb was (indirectly) calling build_peer even though calls to
mwi_event_cb are often caused by build_peer.
* In an effort to prevent chan_sip from being unloaded while messages
were still in flight, destroy_mailboxes was calling
stasis_unsubscribe_and_join but in some cases waited forever for the
final message.
* add_peer_mailboxes wasn't properly marking the existing mailboxes
on a peer as "keep" so build_peer would always delete them all.
* add_peer_mwi_subs was unsubscribing existing mailbox subscriptions
then just creating them again.
All of this was causing a flood of subscribes and unsubscribes on
multiple threads all for the same peer and mailbox.
Fixes...
* add_peer_mailboxes now marks mailboxes correctly and build_peer only
deletes the ones that really are no longer needed by the peer.
* add_peer_mwi_subs now only adds subscriptions marked as "new" instead
of unsubscribing and resubscribing everything. It also adds the peer
object's address to the mailbox instead of its name to the subscription
userdata so mwi_event_cb doesn't have to call build_peer.
With these changes, with rtcachefriends=yes (the most common setting),
there are no leaks, locks, loops or crashes at shutdown.
rtcachefriends=no still causes leaks but at least it doesn't lock, loop
or crash. Since making rtcachefriends=no work wasnt in scope for this
issue, further work will have to be deferred to a separate patch.
Side fixes...
* The ast_lock_track structure had a member named "thread" which gdb
doesn't like since it conflicts with it's "thread" command. That
member was renamed to "thread_id".
ASTERISK-25468 #close
Change-Id: I07519ef7f092629e1e844f855abd279d6475cdd0
|
|
|
|
|
|
|
|
When retrieving presence state information there is no
guarantee that the subtype and message passed in are
set to NULL. This change ensures they are.
ASTERISK-26397 #close
Change-Id: I61f8187972d5d8bbd7d6b7f4daa4f4f7e8237b23
|
|
|
|
This changes the notice for the deprecation of the old
pooling options to point to the new option for doing
pooling. This gives a clearer direction as to what to
look into.
ASTERISK-26389 #close
Change-Id: I2ca9cdfdcd75aec170a7db9d5ff69a4cd25b7c10
|
|
|
|
* Make 'cdrzone=UTC' work properly.
* Fix the documentation of cdr_mysql.conf: it's cdrzone and not timezone
ASTERISK-26359 #close
Change-Id: I2a6f67b71bbbe77cac31a34d0bbfb1d67c933778
|
|
The pooling, shared_connection, limit, and idlecheck options
are no longer used in res_odbc.
ASTERISK-26389
Change-Id: I2fde7b467d01f9d1c82cc0a339bb4f7e1dd6bbe6
|
|
restart." into 13
|
|
Move the function outside the conditional block that excludes
LOW_MEMORY.
ASTERISK-26273 #close
Change-Id: Ic290fa128222c410c3531107e30efacabc8493b4
|
|
|
|
|
|
When logger.conf is missing or invalid we should be printing notices,
warnings and errors to the console. The logmask was incorrectly
calculated.
Change-Id: Ibaa9465a8682854bc1a5e9ba07079bea1bfb6bb3
|
|
sd_notify() is used to notify systemd of changes to the status of the
process. This allows the systemd daemon to know when the process
finished loading (and thus only start another program after Asterisk has
finished loading).
To use this, use a systemd unit with 'Type=notify' for Asterisk.
This commit also adds the function ast_sd_notify(), a wrapper around
sd_notify that does nothing if not built with systemd support.
Also adds support for libsystemd detection in the configure script.
Change-Id: Ied6a59dafd5ef331c5c7ae8f3ccd2dfc94be7811
(cherry picked from commit 07b95f7c65b7c083724f1af2b26f93cc22cad58c)
|
|
Without this change, a 'core restart' would kill the astcanary forever
if you're not running as root. Both with and without this patch, the
scheduling priority was still SCHED_RR after restart.
Additionally, the astcanary is now spawned if you start with high
priority and Asterisk doesn't get a chance to lower it. For example
through: `chrt -r 10 sudo -u asterisk asterisk -c`
Also reap killed astcanary processes on core restart.
ASTERISK-26352 #close
Change-Id: Iacb49f26491a0717084ad46ed96b0bea5f627a55
|
|
threads." into 13
|
|
|
|
into 13
|
|
Previously only the canary checking thread itself had its priority set
to SCHED_OTHER. Now all threads are traversed and adjusted.
ASTERISK-19867 #close
Reported by: Xavier Hienne
Change-Id: Ie0dd02a3ec42f66a78303e9c1aac28f7ed9aae39
|
|
If sysinfo() is available, but not sysctl() or swapctl() the
printing code for swap buffer sizes is incorrectly omitted.
The above condition happens with musl c-library.
Fix #if rule to consider defined(HAVE_SYSINFO). And also
remove the redundant || defined(HAVE_SYSCTL) which was
incorrectly there to start with. Now swap information is
displayed only if an actual libc function to get it is
available.
This also fixes warnings previously seen with musl libc:
[CC] asterisk.c -> asterisk.o
asterisk.c: In function 'handle_show_sysinfo':
asterisk.c:773:6: warning: variable 'totalswap' set but not used
[-Wunused-but-set-variable]
int totalswap = 0;
^~~~~~~~~
asterisk.c:770:11: warning: variable 'freeswap' set but not used
[-Wunused-but-set-variable]
uint64_t freeswap = 0;
^~~~~~~~
Change-Id: I1fb21dad8f27e416c60f138c6f2bff03fb626eca
|
|
Creating ODBC SQL queries resulted in queries too large to fit into the
supplied buffer. The resulting truncated buffer contained an invalid SQL
query.
* Made SQL query generation code use a thread storage buffer that can
increase in size as needed.
* Fixed bad multi-line warning messages.
ASTERISK-26263 #close
Reported by: Jeppe Ryskov Larsen
Change-Id: I23f3cdd43c2dac80bed3ded4dd77d18cb17f21ae
|
|
The res_pjsip_multihomed module determines what interface and transport
a request is going out on and updates the SIP message accordingly with
the address information. This currently incorrectly updates the Contact
header for connectionful protocols to the ephemeral connection port,
instead of the bound address for the listening socket which can actually
accept the connection back. If the remote side attempts to connect back on
the epehemeral port it will fail.
This change makes it so the port is updated to the bound port on
connectionful protocols and is maintained on UDP (as there can be
multiple of those).
ASTERISK-26374 #close
Change-Id: I50f8dab65b9f75117d73ba5f6bbcf6c9871854ab
|
|
A name server that returns "Server Failure" is indicating only that
the server couldn't process that particular request. We should NOT
assume that the name server is incapable of serving other requests.
Here's the scenario we've been encountering...
* 2 local name servers configured in resolv.conf.
* An OPTIONS request causes a request for A and AAAA records to go out
to both nameservers.
* The A responses both come back successfully resolved.
* Because of an issue at some upstream nameserver, the AAAA responses
for that particular query come back as "SERVFAIL" from both local
name servers.
* Both local servers are marked as bad and no further queries can be
sent until the 60 second ttl expires. Only previously cached results
can be used.
* In this case, 60 seconds is just enough time for another OPTIONS
request to go out to the same host so the cycle repeats.
We could set the bad ttl really low but that also affects REFUSED and
NOTAUTH which probably DO signal a real server issue. Besides, even
a really low bad ttl would be an issue on a pbx.
Although we use our own resolver in 14 and master and don't have this
issue there, Teluu has merged this patch upstream so it's appropriate
to cherry-pick to 14 and master to keep pjproject consistent.
Change-Id: Ie03ba902288e274aff23f9b9bb2786e1e8be09e0
|
|
seconds." into 13
|
|
|
|
|
|
|
|
Currently when receiving video over RTP we store only
a calculated samples on the frame. When starting the video
it can take some time for this calculation to actually yield
a value as it requires constant changing timestamps. As well
if a video frame passes over multiple RTP packets this calculation
will fail as the timestamp is the same as the previous RTP
packet and the number of samples calculated will be 0.
This change preserves the timestamp on the frame and allows
it to pass through the core. When sending the video this timestamp
is used instead of a new one being calculated.
ASTERISK-26367 #close
Change-Id: Iba8179fb5c14c9443aee4baf670d2185da3ecfbd
|
|
|
|
ASTERISK-26375 #close
Change-Id: I46496af5cae41413e76d44d2068a7431279f09dc
|
|
Change-Id I1cd33453c77c56c8e1394cd60a6f17bb61c1d957 Enable Session-Timers for
SIP over TCP (and TLS) also disables SIP retransmits in chan_sip for non-UDP
connections, allowing the TCP layer to handle the retransmits. Unfortunately,
this caused sessions to be terminated with a retransmit timeout becasue it
stopped at the point of the first retrans call.
This patch waits for the 64*T1 timer to expire instead.
ASTERISK-19968
Change-Id: I844f26801aada10bc94e9bebe6e151f0a8443204
|
|
|
|
|
|
The output of CLI "queue show" and AMI Queues action is truncated and
"failed to extend from 240 to 327" messages are generated if the queue
member and interface names are lengthy.
* Increase the string buffer size from 240 to 512 in order to accommodate
for more information fields added to the output since v1.8.
ASTERISK-26360 #close
Reported by: Richard Mudgett
Change-Id: Id99c03cf5362453b80491a4b3b0434cb67aa966d
|
|
|
|
Previously, the Contact was stored only on initial INVITE and on any
18X and 200. That meant that after re-INVITEs from *us* the Contact
could get updated, but after re-INVITEs from the *peer*, it did not.
This changeset fixes this inconsistency, properly allowing target
refreshes through re-INVITES (RFC3261, 12.2).
If your strictrtp setting allows it, this change allows you to switch
the source IP of a connected/calling device mid-call with a simple
re-INVITE from the new IP.
ASTERISK-26358 #close
Change-Id: Ibb8512054ab27c8c3d2514022568fde943bf2435
|
|
Map the sip.conf general section legacy_useroption_parsing to the
new pjsip.conf global ignore_uri_user_options.
ASTERISK-26316
Reported by: Kevin Harwell
Change-Id: I78108a31995db19d41f4e1a07b3324692c5363fc
|
|
This implements the chan_sip legacy_useroption_parsing option but with a
better name.
* Made the caller-id number and redirecting number strings obtained from
incoming SIP URI user fields always truncated at the first semicolon.
People don't care about anything after the semicolon showing up on their
displays even though the RFC allows the semicolon.
ASTERISK-26316 #close
Reported by: Kevin Harwell
Change-Id: Ib42b0e940dd34d84c7b14bc2e90d1ba392624f62
|
|
If you use the safe_asterisk script, it uses hardcoded defaults before
running configurable values from /etc/asterisk/startup.d. The hardcoded
default has TTY=9. Some containerized environments don't have such a
TTY, and safe_asterisk would stop.
The custom configuration from /etc/asterisk/startup.d/* isn't read until
after it stopped, so changing TTY in a custom config did not help.
This changeset changes safe_asterisk to continue if the TTY setting was
untouched and /dev/tty9 and /dev/vc/9 aren't found.
Change-Id: I2c7cdba549b77f418a0af4cb1227e8e6fe4148fc
|
|
The code was incorrectly invoking the unidentified logic when
an endpoint had actually been identified, causing log messages
to be output.
ASTERISK-26349 #close
Change-Id: Id8104fc9e3d138d5e8b6f6977ecc08765fd17d4f
|
|
In some scenarios dialog_initialize_rtp can be called multiple times on
the same dialog. This can cause RTP instances to be leaked along with
multiple file descriptors for each instance.
This change makes it so the existing RTP instances are destroyed and
not overwritten, stopping the memory leak.
ASTERISK-26272 #close
patches:
ASTERISK-26272-13.patch submitted by Corey Farrell (license 5909)
Change-Id: Id529de1184c68f2f4d254ab41a1f458dafdb5f73
|
|
The endpoint identification PJSIP module is intended to identify which
endpoint an incoming request is from. If an endpoint is not identified,
then an artificial endpoint is used in its place when proceeding.
The problem is that the ACK request type is an exception to the rule.
The artificial endpoint is not used when processing an ACK. This results
in the possibility of having a NULL endpoint being used further on.
The reason ACK is an exception is an attempt not to spam security logs
with unidentified requests. Presumably, you've already logged the
unidentified request on the preceeding INVITE.
Up until Asterisk 13.10, retrieving a NULL endpoint in this fashion
didn't cause an issue. A new change in 13.10 added endpoint ACL checking
shortly after endpoint identification. Because we are accessing a NULL
endpoint, this ACL check resulted in a crash.
The fix here is to be sure to retrieve the artificial endpoint for all
request types. ACKs still do not generate unidentified request security
events.
ASTERISK-26264 #close
Reported by nappsoft
AST-2016-006
Change-Id: Ie0c795ae2d72273decb972dd74b6a1489fb6b703
|