| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Change-Id: I9f424f5282ca7d833592f958d95f1b2bafb549b0
|
|
Change-Id: Ib59d7d2f2a4a822754628f2c48a308d6791a6e6e
|
|
ast_strings_match uses sscanf and checks for non-zero return to verify a
token was parsed. This is incorrect as sscanf returns EOF (-1) for errors.
ASTERISK-27318 #close
Change-Id: Ifcece92605f58116eff24c5a0a3b0ee08b3c87b1
|
|
Change-Id: I5ae2f316229f336eb90d99c7af7ed07a33097e68
|
|
ASTERISK-27289
Change-Id: I7a415948116493050614d9f4fa91ffbe0c21ec4c
|
|
When two channels were early bridged in a native_rtp bridge, the RTP description
on one side was not updated when the other side answered.
This patch forbids non-answered channels to enter a native_rtp bridge, and
triggers a bridge reconfiguration when an ANSWER frame is received.
ASTERISK-27257
Change-Id: If1aaee1b4ed9658a1aa91ab715ee0a6413b878df
|
|
ASTERISK-26606
Change-Id: I81a7268ef7ba012d4d80d44c70b6276d48e397fa
|
|
A new endpoint parameter "incoming_mwi_mailbox" allows Asterisk to
receive unsolicited MWI NOTIFY requests and make them available to
other modules via the stasis message bus.
res_pjsip_pubsub has a new handler "pubsub_on_rx_mwi_notify_request"
that parses a simple-message-summary body and, if
endpoint->incoming_mwi_account is set, calls ast_publish_mwi_state
with the voice-message counts from the message.
Change-Id: I08bae3d16e77af48fcccc2c936acce8fc0ef0f3c
|
|
If an error occurs during a bridge impart it's possible that
the "bridge_after" callback might try to run before
control_swap_channel_in_bridge has been signalled to continue.
Since control_swap_channel_in_bridge is holding the control lock
and the callback needs it, a deadlock will occur.
* control_swap_channel_in_bridge now only holds the control
lock while it's actually modifying the control structure and
releases it while the bridge impart is running.
* bridge_after_cb is now tolerant of impart failures.
Change-Id: Ifd239aa93955b3eb475521f61e284fcb0da2c3b3
|
|
In 2dee95cc (ASTERISK-27024) and 776ffd77 (ASTERISK-26879) there was
confusion about whether the transport_state->localnet ACL has ALLOW or
DENY semantics.
For the record: the localnet has DENY semantics, meaning that "not in
the list" means ALLOW, and the local nets are in the list.
Therefore, checks like this look wrong, but are right:
/* See if where we are sending this request is local or not, and if
not that we can get a Contact URI to modify */
if (ast_apply_ha(transport_state->localnet, &addr) != AST_SENSE_ALLOW) {
ast_debug(5, "Request is being sent to local address, "
"skipping NAT manipulation\n");
(In the list == localnet == DENY == skip NAT manipulation.)
And conversely, other checks that looked right, were wrong.
This change adds two macro's to reduce the confusion and uses those
instead:
ast_sip_transport_is_nonlocal(transport_state, addr)
ast_sip_transport_is_local(transport_state, addr)
ASTERISK-27248 #close
Change-Id: Ie7767519eb5a822c4848e531a53c0fd054fae934
|
|
ASTERISK-27225 #close
Reported by: Richard Kenner
Change-Id: I097b81734ef730f8603c0b972909d212a3a5cf89
|
|
An admin can configure app_minivm with an externnotify program to be run
when a voicemail is received. The app_minivm application MinivmNotify
uses ast_safe_system() for this purpose which is vulnerable to command
injection since the Caller-ID name and number values given to externnotify
can come from an external untrusted source.
* Add ast_safe_execvp() function. This gives modules the ability to run
external commands with greater safety compared to ast_safe_system().
Specifically when some parameters are filled by untrusted sources the new
function does not allow malicious input to break argument encoding. This
may be of particular concern where CALLERID(name) or CALLERID(num) may be
used as a parameter to a script run by ast_safe_system() which could
potentially allow arbitrary command execution.
* Changed app_minivm.c:run_externnotify() to use the new ast_safe_execvp()
instead of ast_safe_system() to avoid command injection.
* Document code injection potential from untrusted data sources for other
shell commands that are under user control.
ASTERISK-27103
Change-Id: I7552472247a84cde24e1358aaf64af160107aef1
|
|
There is a little known feature in app_controlplayback that will cause the
specified offset to be used relative to the end of a file if a ':end' is
detected within the filename.
This feature is pretty bad, but okay.
However, a bug exists in this code where a ':' detected in the filename
will cause the end pointer to be non-NULL, even if the full ':end' isn't
specified. This causes us to treat an unspecified offset (0) as being
"start playing from the end of the file", resulting in no file playback
occurring.
This patch fixes this bug by resetting the end pointer if ':end' is not
found in the filename.
ASTERISK-23608 #close
Reported by: Jonathan White
Change-Id: Ib4c7b1b45283e4effd622a970055c51146892f35
(cherry picked from commit 13efea24f7ce6ccc01d1a5a0603be2636d83a408)
|
|
* netsock2.c: Test the addr->len member first as it may be the only member
initialized in the struct.
* stun.c:ast_stun_handle_packet(): The combinded[] local array could get
used uninitialized by ast_stun_request(). The uninitialized string gets
copied to another location and could overflow the destination memory
buffer.
These valgrind findings were found for ASTERISK_27150 but are not
necessarily a fix for the issue.
Change-Id: I55f8687ba4ffc0f69578fd850af006a56cbc9a57
|
|
Use -Wno-format-truncation only if supported by compiler.
ASTERISK-27171 #close
Change-Id: Iac0aed7a5bcaa16c21b7d62c4e4678d244c4ccb6
|
|
GCC 7 has added capability to produce warnings, this fixes most of those
warnings. The specific warnings are disabled in a few places:
* app_voicemail.c: truncation of paths more than 4096 chars in many places.
* chan_mgcp.c: callid truncated to 80 chars.
* cdr.c: two userfields are combined to cdr copy, fix would break ABI.
* tcptls.c: ignore use of deprecated method SSLv3_client_method().
ASTERISK-27156 #close
Change-Id: I65f280e7d3cfad279d16f41823a4d6fddcbc4c88
|
|
|
|
This change adds VP9 as a known codec and creates a cached
"vp9" media format for use.
Change-Id: I025a93ed05cf96153d66f36db1839109cc24c5cc
|
|
The seconds and minutes files have always existed in the base language
directory of the Core package. So say.c has always been calling the wrong
location (under digits/) for those two files and in the case of second and
minute they didn't exist in the Core packages at all.
The 1.6 sounds release moves the second and minute files into Core from
Extra for the languages that already had them. A future release will include
the second and minute files for languages that didn't already have them.
This patch just changes all the target locations for second, seconds,
minute, and minutes that were under the digits subdir to be under the root of
sounds instead. Which is where the sounds will be for some languages after 1.6
sounds and for all languages after a future release.
ASTERISK-25810 #close
Change-Id: I05d9d4bee6a7237030530a46e7eb3df15f13f702
Reported-by: Nicolas Riendeau
|
|
This adds support for parsing timelen values from config files. This
includes support for all flags which apply to PARSE_INT32. Support for
this parser is added to ACO via the OPT_TIMELEN_T option type.
Fixes an issue where extra characters provided to ast_app_parse_timelen
were ignored, they now cause an error.
Testing is included.
ASTERISK-27117 #close
Change-Id: I6b333feca7e3f83b4ef5bf2636fc0fd613742554
|
|
|
|
Setting maxfiles (maximum number of open files) has no practical
effect on a remote asterisk (rasterisk, rasterisk -x).
It has an ill effect of printing an extra message, which
may be annoying in case of -x.
ASTERISK-27105 #close
Change-Id: Iaf9eb344e4b4b517df91b736b27ec55f6a6921a2
|
|
Messages like "fwrite() failed: Connection reset by peer" are no
help whatsoever, especially since they can be caused simply by a
client disconnecting.
* Make those WARNINGs DEBUGs.
* Check the return of the headers fprintf.
Change-Id: I17bd5f3621514152a7b2b263c801324c5e96568b
|
|
Change-Id: I9020ff9f2b3749904317c0c173f47a1bbed6f929
|
|
|
|
Invoking 'data get /asterisk/core/channeltypes' caused a crash because
of an assumption of a tech's capabilities to be non-NULL. The
'Surrogate' tech, however, does have a NULL capabilities member,
resulting in a crash.
ASTERISK-27108 #close
Change-Id: I2fbe7715681f43d5565d1e1599269468c26b0e0a
|
|
Clear channel flag AST_FLAG_END_DTMF_ONLY in ast_waitfordigit_full when
ast_read returns NULL.
ASTERISK-27100 #close
Change-Id: Id3039e9a4e74e0cb359f636c9fd0c9740ebf7d9d
|
|
unlocked" into 13
|
|
In an earlier version of Asterisk a local channel [un]lock all functions were
added in order to keep a crash from occurring when a channel hung up too early
during an attended transfer. Unfortunately, when a transfer failure occurs and
depending on the timing, the local channels sometime do not get properly
unlocked and deref'ed after being locked and ref'ed. This happens because the
underlying local channel structure gets NULLed out before unlocking.
This patch reworks those [un]lock functions and makes sure the values that get
locked and ref'ed later get unlocked and deref'ed.
ASTERISK-27074 #close
Change-Id: Ice96653e29bd9d6674ed5f95feb6b448ab148b09
|
|
If an attended transfer failed it was possible for some of the channels
involved to get "stuck" because Asterisk was not hanging up the transfer target.
This patch ensures Asterisk hangs up the transfer target when an attended
transfer failure occurs.
ASTERISK-27075 #close
Change-Id: I98a6ecd92d3461ab98c36f0d9451d23adaf3e5f9
|
|
|
|
unregistration." into 13
|
|
When a stasis channel is stolen by another app, the control
structure is unreffed but never unlinked from the app_controls
container. This causes the channel reference to leak.
Added OBJ_UNLINK to the callback in channel_stolen_cb.
Also added some additional channel lifecycle debug messages to
channel.c.
ASTERISK-27059 #close
Repoorted-by: George Joseph
Change-Id: Ib820936cd49453f20156971785e7f4f182c56e14
|
|
|
|
|
|
The ast_channel_suppress function wrongly decremented the
reference count of the underlying structure used to keep
track of what should be suppressed on a channel if the
function was called multiple times on the same channel.
This change cleans up the reference counting a bit so
this no longer occurs.
ASTERISK-27016
Change-Id: I2eed4077cb4916e6626f9f120b63b963acc5c136
|
|
|
|
Not easy to reproduce, but we have noticed deadlocks when unloading a module
while dialplan is handling a request.
The deadlock is between :
1) Dialplan execution: pbx_extension_helper() first taking conlock,
then pbx_findapp() [when called] asking for lock on apps list.
2) Application unregistration: ast_unregister_application() first taking lock
on apps list, then unreference_cached_app() [when called] asking for conlock.
As a protection, I suggest to modify ast_unregister_application(), so that it
anticipates the need of conlock, before taking the lock on apps list.
The side effect is a longer unavailability of conlock when unregistering an
application.
ASTERISK-27041
Change-Id: I0db0f1eb320da6a5758cce3a47d765be1face8e2
|
|
This change adds a deferred queue to bridging. If a bridge
technology determines that a frame can not be written and
should be deferred it can indicate back to bridging to do so.
Bridging will then requeue any deferred frames upon a new
channel joining the bridge.
This change has been leveraged for T.38 request negotiate
control frames. Without the deferred queue there is a race
condition between the bridge receiving the T.38 request
negotiate and the second channel joining and being in the
bridge. If the channel is not yet in the bridge then the T.38
negotiation fails.
A unit test has also been added that confirms that a T.38
request negotiate control frame is deferred when no other
channel is in the bridge and that it is requeued when a new
channel joins the bridge.
ASTERISK-26923
Change-Id: Ie05b08523f399eae579130f4a5f562a344d2e415
|
|
Add some #if defined checks which allow building against LibreSSL.
These patchess come from OpenBSD ports:
https://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/telephony/asterisk/patches/
ASTERISK-27043 #close
Reported by: OpenBSD ports
Change-Id: I2f6c08a5840b85ad4d2b75370b947ddde7a9a572
|
|
FreeBSD does not include a crypt.h include file. Definitions for
crypt() and crypt_r() are in unistd.h
ASTERISK-27042 #close
Change-Id: Ib307ee5e384870c6af50efa89fb73722dd0c3a7e
|
|
|
|
|
|
ASTERISK-26419 introduced a bug when calling ast_audiohook_write_list in
ast_write. It would free the frame given to ast_write if the frame returned
by ast_audiohook_write_list was different than the given one. The frame
give to ast_write should never be freed within that function. It is the
caller's resposibility to free the frame after writing (or when it its done
with it). By freeing it within ast_write this of course led to some memory
corruption problems.
This patch makes it so the frame given to ast_write is no longer freed within
the function. The frame returned by ast_audiohook_write_list is now subsequently
used in ast_write and is freed later. It is freed either after translate if the
frame returned by translate is different, or near the end of ast_write prior
to function exit.
ASTERISK-26973 #close
Change-Id: I463d4ac3b736ced95de986ee74a489c7c7ab103b
|
|
Before this patch, when a user hung up during a Background, we would
stuff 0xff into a char and attempt a dialplan lookup of it. This caused
problems for some realtime engines which interpreted the value as the
beginning of an invalid UTF-8 sequence.
ASTERISK-19291 #close
Reported by: Andrew Nowrot
Change-Id: I8ca6da93252d61c76ebdb46a4aa65e73ca985358
|
|
ASTERISK-27025
Change-Id: Id736b0aa4ec6b6b0f04663d64fa8d151f81fdbed
|
|
In review 4843 (ASTERISK-24858), we added a hack that forced a smoother
creation when sending signed linear so that the byte order was adjusted
during transmission. This was needed because smoother flags were lost
during the new format work that was done in Asterisk 13.
Rather than rolling that same hack into res_rtp_multicast, re-introduce
smoother flags so that formats can dictate their own options.
Change-Id: I77b835fba0e539c6ce50014a984766f63cab2c16
|
|
During the channel flag audit an incorrect change was
done. The flag should be cleared on the second channel.
ASTERISK-26469
Change-Id: I770c5a389550a2fb5a6ade942fccbb2e1d9199c8
|
|
|
