This change turns the bridge type field into a comma separated list of attributes.
These attributes include: mixing, holding, dtmf_events, and proxy_media. By setting
the various attributes a user can control the type of bridge created with the
behavior they need for their application.
(closes issue ASTERISK-23437)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3359/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@410904 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In the CDR core, every channel should either be filtered out (due to being an
'internal' channel used as an implementation detail, such as playing media
back into a bridge) or it should get a CDR. Even if that CDR ends up being
discarded, we still give the channel a CDR in case we end up needing it. If we
hit a situation where a channel does not have a CDR, we should blow up in
-dev-mode. Asserts are appropriate for that.
This patch adds those asserts, as they would have quickly caught the error
fixed by r410814.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@410861 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a request was received with a Content-type of json,
the body was sent for json parsing - even if it was zero
length. This resulted in ARI requests failing that were
valid, such as a channel DELETE with no parameters. The
code has now been changed to skip json parsing with zero
content length.
(closes issue SWP-6748)
Reported by: Samuel Galarneau
Review: https://reviewboard.asterisk.org/r/3360/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@410858 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change enables DNS client support within PJSIP. System
nameservers are automatically discovered using res_init or
res_ninit. If this fails then PJSIP will resort to using
gethostbyname for resolution.
By enabling this support we gain SRV support, failover, and
weight support.
(closes issue ASTERISK-23435)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3343/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@410795 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change makes the res_pjsip_multihomed module less aggressive when
changing the address in messages. It will now only occur if the transport
in use is bound to the any address OR if the system determined source
address matches the bound address of the transport in use.
Review: https://reviewboard.asterisk.org/r/3369/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@410793 65c4cc65-6c06-0410-ace0-fbb531ad65f3
These changes were still up for review and have not been approved
yet. I must have had the changes in my working copy when making
a different change.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@410696 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Playing back a file to a channel in an ARI bridge would attempt to wait until
the playback concluded before returning. The method used involved signaling the
waiting thread in the ARI custom playback function.
The problem with this is that there were some corner cases that were not accounted for:
* If a bridge channel could not be found, then we never would attempt the playback but
would still attempt to wait for the playback to complete.
* If the bridge playfile action failed to queue, we would still attempt to wait for the
playback to complete.
* If the bridge playfile action were queued but some circumstance caused the playback
not to occur (the bridge dies, the channel is removed from the bridge), then we would
never be notified.
The solution to this is to move the waiting logic into the bridge code. A new bridge
API function is added to queue a synchronous action on a bridge. The waiting thread
is notified when the queued frame has been freed, either due to an error occurring
or due to successful playback. As a failsafe, the waiting thread has a 10 minute
timeout just in case there is a frame leak somewhere.
Review: https://reviewboard.asterisk.org/r/3338
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@410673 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Events are sent to a connected ARI application based on the things that ARI
application cares about. These subscriptions can be set up implicitly - such
as when that ARI application creates a new object - or explicitly, via the
application resource's subscription operations. Debugging *why* something was
being sent to an application - or why something was not being sent to an
application - was a bit tricky, as there was no debug information for the
subscriptions.
This patch adds some debug level 3 statements that show the subscription counts
for applications. (Level 3 was chosen as it matches the verbose level 3
statements elsewhere)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@410650 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Realtime backends' update and store callbacks return the number of rows affected,
or -1 if there was a failure. There were a couple of issues:
* The config API was treating 0 as a successful return, and positive values as
a failure. Now the config API treats anything >= 0 as a success.
* res_sorcery_realtime was treating 0 as a successful return from the store
procedure, and any positive values as a failure. Now sorcery treats anything
> 0 as a success. It still considers 0 a "failure" since there is no change
to report to observers.
Review: https://reviewboard.asterisk.org/r/3341
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@410592 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The syncing thread sleeps for a second before waiting to be
told to attempt to sync again. If a signal were sent during this
sleeping period, we would end up having to wait until the next
sync signal occurred in order to sync up the astdb.
This code rearrangement also ensures that any pending transactions
will be synced prior to Asterisk shutting down.
Patches: db_sync.patch by John Hardin (License #6512)
........
Merged revisions 410556 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@410559 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This fixes an issue where a Stasis application running over ARI and
subscribed to ari/events could miss the ChannelEnteredBridge event
because it did not subscribe to the new bridge fast enough.
To accomplish this, it subscribes the application controlling the
channel to the new bridge before adding it to that bridge which
required the stasis_app_control structure to maintain a reference to
the stasis_app.
(closes issue ASTERISK-23295)
Review: https://reviewboard.asterisk.org/r/3336/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@410527 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Made res_musiconhold.c always post the MusicOnHoldStart/MusicOnHoldStop
events when it actually starts/stops the music streams. This allows the
events to always happen when MOH starts/stops. The event posting code was
moved to the MOH alloc/release routines.
* Made channel_do_masquerade() stop any MOH on the original channel before
masquerading so the original channel will get a stop event with correct
information.
* Cleaned up a couple odd codings in moh_files_alloc() and moh_alloc()
dealing with the music state variable.
(issue ASTERISK-23311)
Reported by: Benjamin Keith Ford
Review: https://reviewboard.asterisk.org/r/3306/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@410493 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change fixes a bug where the code which changes the transport did not check whether
the message is going out over UDP or not before changing it. For TCP and TLS transports
we don't need to change the transport as the correct one is already chosen.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@410471 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Due to how messages are handled within PJSIP it is not until a message is actually
sent that the destination is reliably known. This means that the addresses placed
within the message may not be of the interface the message is being sent out on.
This module determines what interface a message is being sent on and updates the
message to contain the correct address if applicable.
This module was tested by myself in a virtualized environment with multiple interfaces
and also by Kinsey Moore in the following configuration:
Networks:
* 10.24.16.0/21
** hard phone
** default gateway
* 10.24.64.0/21
** softphone with pjsip-based stack
Transport details:
bind address: 0.0.0.0
protocol: UDP
All endpoints were tested with explicitly configured transports and unconfigured transports.
This was tested with inbound and outbound calls, both of which were experiencing detrimental
effects from incorrect IP addresses in SIP messages. These effects were only experienced by the
soft phone on the 10.24.64.0 network since the messages to the hard phone on the 10.24.16.0
network had the correct IP address.
(closes issue ASTERISK-23020)
Reported by: xrobau
Review: https://reviewboard.asterisk.org/r/3102/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@410451 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Sending a HTTP request that is handled by Asterisk with a large number of
Cookie headers could overflow the stack.
Another vulnerability along similar lines is any HTTP request with a
ridiculous number of headers in the request could exhaust system memory.
(closes issue ASTERISK-23340)
Reported by: Lucas Molas, researcher at Programa STIC, Fundacion; and Dr. Manuel Sadosky, Buenos Aires, Argentina
........
Merged revisions 410380 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 410381 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@410383 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change allows chan_sip to avoid creation of the channel and
consumption of associated file descriptors altogether if the inbound
request is going to be rejected anyway.
(closes issue ASTERISK-23373)
Reported by: Corey Farrell
Patches:
chan_sip-earlier-st-1.8.patch uploaded by Corey Farrell (license 5909)
chan_sip-earlier-st-11.patch uploaded by Corey Farrell (license 5909)
........
Merged revisions 410308 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 410311 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@410329 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change removes the assumption that an outgoing request will always
have an endpoint and makes the authenticate_qualify option work once again.
(closes issue ASTERISK-23210)
Reported by: Joshua Colp
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@410306 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Created the 'pjsip show channel' and 'pjsip show contact' commands.
Refactored out the hated ast_hashtab. Replaced with ao2_container.
Cleaned up function naming. Internal only, no public name changes.
Cleaned up whitespace and brace formatting in cli code.
Changed some NULL checking from "if"s to ast_asserts.
Fixed some register/unregister ordering to reduce deadlock potential.
Fixed ast_sip_location_add_contact where the 'name' buffer was too short.
Fixed some self-assignment issues in res_pjsip_outbound_registration.
(closes issue ASTERISK-23276)
Review: http://reviewboard.asterisk.org/r/3283/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@410287 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Calling strlen on a NULL string is explosive. This patch checks whether or not
the passed in string is NULL or zero length before checking to see if the
string is too long.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@410274 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The config option help information has always parsed the <see-also> tags in the
XML documentation. Unfortunately, it just never bothered displaying them on
the CLI. With this patch, when you execute 'config show help [module] [obj]
[option]', it will display what other options are useful to you.
(closes issue ASTERISK-22008)
Reported by: Richard Mudgett
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@410209 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The one touch recording options have several see-also links between the
various configuration options. These were 'broken' by the snake casing
of those options. This patch corrects the see-also links such that they
reference the correct option names.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@410194 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In order to prevent confusion over the allow and disallow
list of codecs being the same an option for registering a
field as an alias is added. The alias field will be read
from the configuration file, but afterwards is not listed
as a known field. With disallow set as an alias, the CLI
command pjsip show endpoint # will list the allow= field,
but not the disallow field.
(closes issue ASTERISK-23092)
Review: https://reviewboard.asterisk.org/r/3193/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@410190 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When retrieving data from a database or other realtime backend, it's quite
possible to retrieve variables that Asterisk does not care about but that
are legitimate to exist. Asterisk does not need to throw a hissy fit when
these variables are encountered but rather just filter them out.
Review: https://reviewboard.asterisk.org/r/3305
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@410187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A stasis cache entry now contains more than a single message/snapshot. It
contains messages/snapshots for the local entity as well as any remote
entities that post to the cached item. In addition callbacks can be
supplied when the cache is created to compute and post the aggregate
message/snapshot representing all entities stored in the cache entry.
* All stasis messages now have an eid to indicate what entity posted it.
* The stasis cache enhancements allow device state to cache and aggregate
the device states from local and remote entities in a single operation.
The cached aggregate device state is available immediately after it is
posted to the stasis bus. This improves performance by eliminating a
cache dump and associated ao2 container traversals to calculate the
aggregate state.
(closes issue ASTERISK-23204)
Reported by: Mark Michelson
Review: https://reviewboard.asterisk.org/r/3281/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@410184 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Much needed was a way to assign id to objects on creation, and
much change was necessary to accomplish it. Channel uniqueids
and linkedids are split into separate string and creation time
components without breaking linkedid propgation. This allowed
the uniqueid to be specified by the user interface - and those
values are now carried through to channel creation, adding the
assignedids value to every function in the chain including the
channel drivers. For local channels, the second channel can be
specified or left to default to a ;2 suffix of first. In ARI,
bridge, playback, and snoop objects can also be created with a
specified uniqueid.
Along the way, the args order to allocating channels was fixed
in chan_mgcp and chan_gtalk, and linkedid is no longer lost as
masquerade occurs.
(closes issue ASTERISK-23120)
Review: https://reviewboard.asterisk.org/r/3191/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@410157 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a static realtime peer with qualify=yes is loaded, Asterisk will fail to
send an OPTIONS request due to the lastms being equal to 0. This results in
the peer being unable to receive calls from Asterisk because the status is
permanently UNKNOWN.
This patch allows an OPTIONS request to be sent during module load by
ignoring the lastms value on startup only.
Review: https://reviewboard.asterisk.org/r/3294/
(closes issue ASTERISK-17523)
Reported by: Maciej Krajewski
Tested by: wushumasters
patches:
realtime_fix_11.7.0.txt uploaded by Trevor Peirce (license 6112)
........
Merged revisions 410105 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 410106 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@410107 65c4cc65-6c06-0410-ace0-fbb531ad65f3
