ast_store_realtime() is not NULL tolerant, so we need to initialize
the field values we pass to it to the empty string to avoid a crash.
ASTERISK-23739 #close
Reported by: Stas Kobzar
Change-Id: I756c5dd0299c77f4274368f7c99eb0464367466c
This commit adds support for
[AudioSocket](
https://wiki.asterisk.org/wiki/display/AST/AudioSocket),
a very simple bidirectional audio streaming protocol. There are both
channel and application interfaces.
A description of the protocol can be found on the above referenced
GitHub page. A short talk about the reasons and implementation can be
found on [YouTube](https://www.youtube.com/watch?v=tjduXbZZEgI), from
CommCon 2019.
ARI support has also been added via the existing "externalMedia" ARI
functionality. The UUID is specified using the arbitrary "data" field.
ASTERISK-28484 #close
Change-Id: Ie866e6c4fa13178ec76f2a6971ad3590a3a588b5
We allow for 'maxredirs' to be set, but this value is ignored when
followlocation is not enabled which, by default, it is not.
ASTERISK-17491 #close
Reported by: candrews
Change-Id: I96a4ab0142f2fb7d2e96ff976f6cf7b2982c761a
The QueueMemberPause AMI event includes two fields that return the
reason a member was paused.
* In release branches, deprecate Reason in favor of PausedReason.
* In master, remove the Reason field entirely.
ASTERISK-28349 #close
Reported by: Niksa Baldun
Change-Id: I01da58f2b0ab927baeee754870f62b51b7b3d296
ast_addressfamily_to_sockaddrize will determine the size that's
required, and ast_sockaddr_from_sockaddr then wraps this new function
and ast_sockaddr_copy_sockaddr to copy arbitrary sockaddr's (without
knowing the address family) into the ast_sockaddr structure.
Change-Id: Iee604e96e9096c79b477d6e5ff310cf0b06dae86
Signed-off-by: Jaco Kroon <jaco@uls.co.za>
Additionally alter the warning to mention that it was "beep" which could
not be streamed to give admins a better clue about what the warning
means.
ASTERISK-28682
Change-Id: If5aed21226a173117ed17589f44826dd1ba6576e
This patch fixes some wrongly formatted documentation for the AgentLogin
application. A couple of "see also" links should contain only the function
name, and no parameters.
Change-Id: I3f788b47dce3292e311f8a9856938d59a0bd0661
If you do a "make all" when building Asterisk the xml documentation
produced will be missing certain AMI events where their
documentation is located not at the top of the c source file but
embedded further down next to the event's manager_event()
registration call. See main/manager_mwi.c for an example.
"make full" does produce the correct documentation so we're changing
it in the build script. A separate commit/issue will address the
problem with "make all".
ASTERISK-28507
Reported by: David Lee
Change-Id: I4a22635d6eef99eacecc0efb69e28360eebdb86c
Some body generators, such as dialog-info+xml, require storing state
information which is then conveyed in the NOTIFY request itself. Up
until now there was no way for such body generators to persist this
information.
Two new API calls have been added to allow body generators to set and
get persisted data. This data is persisted out alongside the normal
persistence information and allows the body generator to restore
state information or to simply use this for normal storage of state.
State is stored in the form of JSON and it is up to the body
generator to interpret this as needed.
The dialog-info+xml body generator has been updated to take advantage
of this to persist the version number.
ASTERISK-27759
Change-Id: I5fda56c624fd13c17b3c48e0319b77079e9e27de
Adds source port matching support when IP matching is used:
[example]
type = identify
match = 1.2.3.4:5060/32, 1.2.3.4:6000/32, asterisk.org:4444
If the IP matches but the source port does not, we reject and search for
alternatives. SRV lookups are still performed if enabled (srv_lookups = yes),
unless the configured FQDN includes a port number in which case just a host
lookup is performed.
ASTERISK-28639 #close
Reported by: Mitch Claborn
Change-Id: I256d5bd5d478b95f526e2f80ace31b690eebba92
The change to add setting hangupsource to sig_pri_queue_hangup()
made in https://gerrit.asterisk.org/c/asterisk/+/12857 casued
deadlocks when a hangup request was received from the core at the
same time a hanguprequest was received from the remote end via the
D channel.
Although the PRI's channel private structure was being unlocked
before setting the hangupsource, the PRI's own lock was still being
held during the process. If channel actions were also coming from
the core, a deadlock on the PRI could result. This deadlock could
then escalate to the entire DAHDI subsystem via DAHDI's global
interface list lock, especially if someone used the PRI CLI commands.
Fix:
* We now unlock the PRI as well as the PRI's channel private
structure before setting the hangupsource, then relock both
afterwards.
ASTERISK-28605
Reported by: Dirk Wendland
Change-Id: Id74aaa5d4e3746063dbe9deed188eb65193cb9c9
Dialplan has to be careful about passing an empty device list or empty
positions in the list. As a result, dialplan has to check for these
conditions before using ChanIsAvail. Simplify dialplan by making
ChanIsAvail handle these conditions gracefully.
* Made tolerate empty positions in the device list.
* Simplified the code and eliminated some unnecessary indention.
ASTERISK-28638
Change-Id: I9e4b67e2cbf26b2417c2d03485b8568e898931d3
When a topic is created for an object, its name is only
<object>:<uniqueid>
For example:
bridge:cb68b3a8-fce7-4738-8a17-d7847562f020
When a topic is added to a pool, its name has the pool's topic
name prepended. For example:
bridge:all/bridge:cb68b3a8-fce7-4738-8a17-d7847562f020
The topic_pool_entry's name however, is only what was passed
in to stasis_topic_pool_get_topic which is
bridge:cb68b3a8-fce7-4738-8a17-d7847562f020
That's actually correct because the entry is qualified by the
pool that's in.
When you're ready to delete the entry from the pool, you retrieve
the tropic name from the object but since it now has the pool's
topic name prepended, it won't be found in the pool container.
Fix:
* Modified stasis_topic_pool_delete_topic() to skip past the
pool topic's name, if it was prepended to the topic name,
before searching the container for a pool entry.
ASTERISK-28633
Reported by: Joeran Vinzens
Change-Id: I4396aa69dd83e4ab84c5b91b39293cfdbcf483e6
* Made BridgeAdd not hangup the call if there is a problem.
* Reduced message level from warning to verbose for normal exception
cases.
* Added a loop safety check to BridgeAdd.
* Made BridgeAdd set BRIDGERESULT with the status when dialplan is
resumed.
Change-Id: I374d39b8a3edcc794eeb5c6b9f31a01424cdc426
Dialplan has to be careful about passing an empty destination list or
empty positions in the list. As a result, dialplan has to check for
these conditions before using Dial. Simplify dialplan by making Dial
handle these conditions gracefully.
* Made tolerate empty positions in the dialed device list.
* Reduced some message log levels from notice to verbose.
ASTERISK-28638
Change-Id: I6edc731aff451f8bdfaee5498078dd18c3a11ab9
Dialplan has to be careful about passing an empty destination list or
empty positions in the list. As a result, dialplan has to check for
these conditions before using Page. Simplify dialplan by making Page
handle these conditions gracefully.
* Made tolerate empty positions in the paged device list.
* Reduced some warnings associated with the 's' option to verbose
messages. The warning level for those messages really serves no purpose
as that is why the 's' option exists.
ASTERISK-28638
Change-Id: I95b64a6d6800cd1a25279c88889314ae60fc21e3
The Bridge application was inconsistent if the channel to bridge with is
not specified. If no parameters are given then a warning is issued and
the current channel is hung up. If options are given but no channel is
specified then a warning is issued and the current channel is not hung up.
* Made the Bridge application give a verbose message instead of a warning
if the channel to bridge with is not specified and made not hang up the
current channel. As a result dialplan no longer needs to check if a
channel name is passed before calling Bridge and simply needs to check the
BRIDGERESULT channel variable instead. This is something you likely want
your dialplan to do anyway.
* Fixed up L() option warning message. It is up to the caller to
determine if the channel is hung up because of the warning. Dial() hangs
up the current channel while Bridge() does not.
Change-Id: I44349a8dc3912397f28852777de04f19e7bb9c73
ast_sorcery_changeset_create() is not commutative and will fail to detect
differences between two variable lists depending on what changed, so switch to
ast_variable_lists_match().
ASTERISK-28492 #close
Reported by: Jean-Denis Girard
Change-Id: I7b3256983ddfaa2138d3de92a444a53b5193a4e1
When TLS is in use, checking the readiness of the underlying FD is insufficient
for determining if there is data available to be read. So before polling the
FD, check if there is any buffered data in the TLS layer and use that first.
ASTERISK-28562 #close
Reported by: Robert Sutton
Change-Id: I95fcb3e2004700d5cf8e5ee04943f0115b15e10d
This patch adds a new flag "inhibitConnectedLineUpdates" to the 'addChannel'
operation in the Bridges REST API. When set, this flag avoids generating COLP
frames when the specified channels enter the bridge.
ASTERISK-28629
Change-Id: Ib995d4f0c6106279aa448b34b042b68f0f2ca5dc
Sean Bright
Friendly Automation
Joshua Colp
Seán C McCord
Jaco Kroon
Corey Farrell
Kevin Harwell
George Joseph
Richard Mudgett
Jean Aunis