The bridge_native_rtp module did not properly handle the case where
a smart bridge operation occurs while a channel is suspended. In this
scenario the module would incorrectly set up local or remote RTP
bridging despite the media having to flow through Asterisk. The remote
endpoint would see two media streams and experience wonky audio.
The module has been changed so that it ensures both channels are
not suspended when performing the native RTP bridging and this
requirement has been documented in the bridge technology.
ASTERISK-26781
Change-Id: Id4022d73ace837d4a293106445e3ade10dbc7c7c
This change introduces an ast_read_stream function and callback in
the channel technology which allows reading frames from all streams
and not just the default streams.
The stream number has also been added to frames. This is to allow the
case where frames are queued onto the channel instead of being read
directly from the driver.
This change does impose a restriction on reading though: a chain of
frames can only contain frames from the same stream.
ASTERISK-26816
Change-Id: I5d7dc35e86694df91fd025126f6cfe0453aa38ce
This change adds an ast_write_stream function which allows
writing a frame to a specific media stream. It also moves
ast_write() to using this underneath by writing media
frames provided to it to the default streams of the channel.
Existing functionality (such as audiohooks, framehooks, etc)
are limited to being applied to the default stream only.
Unit tests have also been added which test the behavior of
both non-multistream and multistream channels to confirm that
the write() and write_stream() callbacks are invoked
appropriately.
ASTERISK-26793
Change-Id: I4df20d1b65bd4d787fce0b4b478e19d2dfea245c
Adds binaural synthesis to bridge_softmix (via convolution using libfftw3).
Binaural synthesis is conducted at 48kHz.
For a conference, only one spatial representation is rendered.
The default rendering is applied for mono-capable channels.
ASTERISK-26292
Change-Id: Iecdb381b6adc17c961049658678f6219adae1ddf
The "core show channel" CLI command will now output the streams
present on the channel with their details.
ASTERISK-26811
Change-Id: I9c95b57aa09415005f0677a1949a0feb07e4987a
This establishes the basic allocation/destruction of an SDP state
object, plus some of the simpler getter methods involved. Subsequent
tasks will deal with adding a state machine, creating SDPs from
capabilities and options, and merging SDPs into a joint SDP.
Change-Id: Ie3757ce186f04b65e9d1883f5aace53f24e53709
All of the realtime backends create artificial ast_categorys to pass
back into the core as query results. These categories have no filename
or line number information associated with them and the backends differ
slightly on how they create them. So create a couple helper macros to
help make things more consistent.
Also updated the call sites to remove redundant error messages about
memory allocation failure.
Note that res_config_ldap sets the category filename to the 'table name'
but that is not read by anything in the core, so I've dropped it.
Change-Id: I3a1fd91e0c807dea1ce3b643b0a6fe5be9002897
This creates the following:
* Asterisk's internal representation of an SDP
* An API for translating SDPs from one format to another
* An implementation of a translator for PJMEDIA
Change-Id: Ie2ecd3cbebe76756577be9b133e84d2ee356d46b
This is step one of adding an SDP API: defining some
configurable settings for SDPs. This is based on options
that are currently supported in Asterisk.
Change-Id: I1ede91aafed403b12a9ccdfb91a88389baa7e5d7
This patch fixes 2 original issues and more that those 2 exposed.
* When we send a NOTIFY, and the client either doesn't respond or
responds with a non OK, pjproject only calls our
pubsub_on_evsub_state callback, no others. Since
pubsub_on_evsub_state (which does the sub_tree cleanup) does not
expect to be called back without the other callbacks being called
first, it just returns leaving the sub_tree orphaned. Now
pubsub_on_evsub_state checks the event for PJSIP_EVENT_TSX_STATE
which is what pjproject will set to tell us that it was the
transaction that timed out or failed and not the subscription
itself timing our or being terminated by the client. If is
TSX_STATE, pubsub_on_evsub_state now does the proper cleanup
regardless of the state of the subscription.
* When a client renews a subscription, we don't update the
persisted subscription with the new expires timestamp. This causes
subscription_persistence_recreate to prune the subscription if/when
asterisk restarts. Now, pubsub_on_rx_refresh calls
subscription_persistence_update to apply the new expires timestamp.
This exposed other issues however...
* When creating a dialog from rdata (which sub_persistence_recreate
does from the packet buffer) there must NOT be a tag on the To
header (which there will be when a client refreshes a
subscription). If there is one, pjsip_dlg_create_uas will fail.
To address this, subscription_persistence_update now accepts a flag
that indicates that the original packet buffer must not be updated.
New subscribes don't set the flag and renews do. This makes sure
that when the rdata is recreated on asterisk startup, it's done
from the original subscribe packet which won't have the tag on To.
* When creating a dialog from rdata, we were setting the dialog's
remote (SUBSCRIBE) cseq to be the same as the local (NOTIFY) cseq.
When the client tried to resubscribe after a restart with the
correct cseq, we'd reject the request with an Invalid CSeq error.
* The acts of creating a dialog and evsub by themselves when
recreating a subscription does NOT restart pjproject's subscription
timer. The result was that even if we did correctly recreate the
subscription, we never removed it if the client happened to go away
or send a non-OK response to a NOTIFY. However, there is no
pjproject function exposed to just set the timer on an evsub that
wasn't created by an incoming subscribe request. To address this,
we create our own timer using ast_sip_schedule_task. This timer is
used only for re-establishing subscriptions after a restart.
An earlier approach was to add support for setting pjproject's
timer (via a pjproject patch) and while that patch is still included
here, we don't use that call at the moment.
While addressing these issues, additional debugging was added and
some existing messages made more useful. A few formatting changes
were also made to 'pjsip show scheduled tasks' to make displaying
the subscription timers a little more friendly.
ASTERISK-26696
ASTERISK-26756
Change-Id: I8c605fc1e3923f466a74db087d5ab6f90abce68e
This change adds the media stream topology definition and API for
accessing and using it.
Some refactoring of the stream was also done.
ASTERISK-26786
Change-Id: Ic930232d24d5ad66dcabc14e9b359e0ff8e7f568
In Asterisk 11, if the 'Originate' AMI command failed to connect the provided
Channel while in extension mode, a 'failed' extension would be looked up and
run. This was, I believe, unintentionally removed in 51b6c49. This patch
restores that behavior.
This also adds an enum for the various 'synchronous' modes in an attempt to
make them meaningful.
ASTERISK-26115 #close
Reported by: Nasir Iqbal
Change-Id: I8afbd06725e99610e02adb529137d4800c05345d
This change adds the media stream definition and API for
accessing and using it. Unit tests have also been written
which exercise aspects of the API.
ASTERISK-26773
Change-Id: I3dbe54065b55aaa51f467e1a3bafd67fb48cac87
A dialplan intercept routine is equivalent to an interrupt routine. As
such, the routine must be done quickly and you do not have access to the
media stream. These restrictions are necessary because the media stream
is the responsibility of some other code and interfering with or delaying
that processing is bad. A possible future dialplan processing
architecture change may allow the interception routine to run in a
different thread from the main thread handling the media and remove the
execution time restriction.
* Made res_agi.c:run_agi() running an AGI in an interception routine run
in DeadAGI mode. No touchy channel frames.
ASTERISK-25951
ASTERISK-26343
ASTERISK-26716
Change-Id: I638f147ca7a7f2590d7194a8ef4090eb191e4e43
There are several issues with deferring frames that are caused by the
refactoring.
1) The code deferring frames mishandles adding a deferred frame to the
deferred queue. As a result the deferred queue can only be one frame
long.
2) Deferrable frames can come directly from the channel driver as well as
the read queue. These frames need to be added to the deferred queue.
3) Whoever is deferring frames is really only doing the __ast_read() to
collect deferred frames and doesn't care about the returned frames except
to detect a hangup event. When frame deferral is completed we must make
the normal frame processing see the hangup as a frame anyway. As such,
there is no need to have varying hangup frame deferral methods. We also
need to be aware of the AST_SOFTHANGUP_ASYNCGOTO hangup that isn't real.
That fake hangup is to cause the PBX thread to break out of loops to go
execute a new dialplan location.
4) To properly deal with deferrable frames from the channel driver as
pointed out by (2) above, means that it is possible to process a dialplan
interception routine while frames are deferred because of the
AST_CONTROL_READ_ACTION control frame. Deferring frames is not
implemented as a re-entrant operation so you could have the unsupported
case of two sections of code thinking they have control of the media
stream.
A worse problem is because of the bad implementation of the AMI PlayDTMF
action. It can cause two threads to be deferring frames on the same
channel at the same time. (ASTERISK_25940)
* Rather than fix all these problems simply revert the API refactoring as
there is going to be only autoservice and safe_sleep deferring frames
anyway.
ASTERISK-26343
ASTERISK-26716 #close
Change-Id: I45069c779aa3a35b6c863f65245a6df2c7865496
mod_format.h: Note ast_filestream.fr holds a format ref.
translate.h: Note ast_trans_pvt.f holds a format ref.
Change-Id: I86bda354d725207b41e08920355d7c31b2d7f749
The mechanism used for detecting the maximum log level compiled into the
linked pjproject did not work. The API call simply stores the requested
level into an integer and does no range checking. Asterisk was assuming
that there was range checking and limited the new value to the allowable
range. To get the actual maximum log level compiled into the linked
pjproject we need to get and save off the initial set log level from
pjproject. This is the maximum log level supported.
* Get and save off the initial log level setting before altering it to the
desired level on startup. This has to be done by a macro rather than
calling a core function to avoid incorrectly linking pjproject.
* Split the initial log level warning messages to warn if the linked
pjproject cannot support the requested startup level and if it is too low
to get the pjproject buildopts for "pjproject show buildopts".
* Adjust the CLI "pjproject set log level" to check the saved max log
level and to generate normal output messages instead of a warning message.
ASTERISK-26743 #close
Change-Id: I40aa76653e2a1dece66c3f8734594b4f0471cfb4
The 'ari set debug' command has been enhanced to accept 'all' as an
application name. This allows dumping of all apps even if an app
hasn't registered yet. To accomplish this, a new global_debug global
variable was added to res/stasis/app.c and new APIs were added to
set and query the value.
'ari set debug' now displays requests and responses as well as events.
This required refactoring the existing debug code.
* The implementation for 'ari set debug' was moved from stasis/cli.{c,h}
to ari/cli.{c,h}, and stasis/cli.{c,h} were deleted.
* In order to print the body of incoming requests even if a request
failed, the consumption of the body was moved from the ari stubs
to ast_ari_callback in res_ari.c and the moustache templates were
then regenerated. The body is now passed to ast_ari_invoke and then
on to the handlers. This results in code savings since that template
was inserted multiple times into all the stubs.
An additional change was made to the ao2_str_container implementation
to add partial key searching and a sort function. The existing cli
code assumed it was already there when it wasn't so the tab completion
was never working.
Change-Id: Ief936f747ce47f1fb14035fbe61152cf766406bf
(cherry picked from commit 1d890874f3)
This change adds experimental support for providing RTCP
feedback information to codec modules so they can dynamically
change themselves based on conditions.
ASTERISK-26584
Change-Id: Ifd6aa77fb4a7ff546c6025900fc2baf332c31857
It was possible for a frame to be re-inserted into a jitter buffer after it
had been removed from it. A case when this happened was if a frame was read
out of the jitterbuffer, passed to the translation core, and then multiple
frames were returned from said translation core. Upon multiple frames being
returned the first is passed on, but sebsequently "chained" frames are put
back into the read queue. Thus it was possible for a frame to go back into
the jitter buffer where this would cause problems.
This patch adds a flag to frames that are inserted into the channel's read
queue after translation. The abstract jitter buffer code then checks for this
flag and ignores any frames marked as such.
Change-Id: I276c44edc9dcff61e606242f71274265c7779587
Function CHANNEL(rtcp,all_rtt) CHANNEL(rtcp,all_loss) CHANNEL(rtcp,all_jitter)
always return 0.0 due to wrong define of macro "AST_RTP_SATA_SET" and
"AST_RTP_STAT_STRCPY".
It should compare "combined" with "stat" not "current_stat".
ASTERISK-26710 #close
Reported-by: Aaron An
Tested-by: AaronAn
Change-Id: Id4140fafbf92e2db689dac5b17d9caa009028a15
Adds the ability for extensions to be registered to include filename and
line number so that dialplan show output can show the filename and line
number of a config file responsible for generating a given extension.
This only affects config modules that are written to use the new extension
registering functions. In this patch, that only includes pbx_config, so
extensions registered in extensions.conf and any included extension will
be shown in this manner. Extensions registered in this manner will show
the filename and line number *instead* of the registrar.
ASTERISK-26658 #close
Reported by: Jonathan R. Rose
Change-Id: Ieccc6abccdff34ed5c7da3511fd24972b8f2dd30
The PJSIPShowRegistrationsInbound AMI command was just dumping out
all AORs which was pretty useless and resource heavy since it had
to get all endpoints, then all aors for each endpoint, then all
contacts for each aor.
PJSIPShowRegistrationInboundContactStatuses sends ContactStatusDetail
events which meets the intended purpose of the other command and has
significantly less overhead. Also, some additional fields that were
added to Contact since the original creation of the ContactStatusDetail
event have been added to the end of the event.
For compatibility purposes, PJSIPShowRegistrationsInbound is left
intact.
ASTERISK-26644 #close
Change-Id: I326f12c9ecb52bf37ba03f0748749de4da01490a
The latest Release candidate fails to create RTP streams when IPv6
is not available. Due to the changes made in September the ast_sockaddr
structure passed around to create these streams is always of AF_INET6
type, causing failure when used for IPv4. This patch adds a utility
function to check for availability of IPv6 and applies such check
at startup to determine how to create the ast_sockaddr structures.
ASTERISK-26617 #close
Change-Id: I627a4e91795e821111e1cda523f083a40d0e0c3e
Use of the new logging is as simple as issuing the new CLI command or
setting the new pjproject.conf option.
Other options that can affect the logging are how you have the pjproject
log levels mapped to Asterisk log types in pjproject.conf and if you have
configured Asterisk to log the DEBUG type messages. Altering the
pjproject.conf level mapping shouldn't be necessary for most installations
as the default mapping is sensible. Configuring Asterisk to log the DEBUG
message type is standard practice for collecting debug information.
* Added CLI "pjproject set log level" command to dynamically adjust the
maximum pjproject log message level.
* Added CLI "pjproject show log level" command to see the currently set
maximum pjproject log message level.
* Added pjproject.conf startup section "log_level" option to set the
initial maximum pjproject log message level so all messages could be
captured from initialization.
* Set PJ_LOG_MAX_LEVEL to 6 to compile in all defined logging levels into
bundled pjproject. Pjproject will use the currently set run time log
level to determine if a log message is generated just like Asterisk
verbose and debug logging levels.
* In log_forwarder(), made always log enabled and mapped pjproject log
messages. DEBUG mapped log messages are no longer gated by the current
Asterisk debug logging level.
* Removed RAII_VAR() from res_pjproject.c:get_log_level().
ASTERISK-26630 #close
Change-Id: I6dca12979f482ffb0450aaf58db0fe0f6d2e5389
The sending codec is switched to the receiving codec and then
is switched back to the best native codec on EVERY receiving RTP packets.
This is because after call of ast_channel_set_rawwriteformat there is call
of ast_set_write_format which calls set_format which sets rawwriteformat
to the best native format.
This patch adds a new function ast_set_write_format_path which set
specific write path on channel and uses this function to switch
the sending codec.
ASTERISK-26603 #close
Change-Id: I5b7d098f8b254ce8f45546e6c36e5d324737f71d
Issue/patch ASTERISK-26587 was inspired by issue ASTERISK-22992
that requested ability to add callerid into app_originate.
Comments in that issue suggested that it was better solved by
adding an option to gosub prior to originating the call. The
attached patch implements this much like app_dial with two
options one to gosub on the originating channel and one to gosub
on the newly created channel and behaves just like app_dial.
I have tested this patch by adding callerid info to the new
channel and also SIPAddHeader (to e.g. add header to force auto
answer) and confirmed it works. Have also tested both 'exten'
and 'app' versions of app_originate.
Opened by: dkerr
Patch by: dkerr
Change-Id: I36abc39b58567ffcab4a636ea196ef48be234c57
Previously, a TLS server socket would only be restarted upon sip reload if the
bind address had changed. This commit adds checking for changes to TLS
parameters like certificate, ciphers, etc. so they get picked up without
requiring a reload of the entire chan_sip module. This does not affect open
connections in any way, but new connections will use the new TLS parameters.
The changes also apply to HTTP and Manager.
ASTERISK-26604 #close
Change-Id: I169e86cefc6dcd627c915134015a6a1ab1aadbe6
Responding to authentication challenges leaks PJSIP memory pools.
The leak was introduced with a pjproject 2.5.5 API change.
https://trac.pjsip.org/repos/ticket/1929 changed the API usage of
pjsip_auth_clt_init() to require the new API pjsip_auth_clt_deinit() to
clean up cached authentication allocations that get allocated with
pjsip_auth_clt_reinit_req().
ASTERISK-26516 #close
Change-Id: I4473141b8c3961d0dc91c382beb3876b3efb45c8
fopencookie/funclose is a non-standard API and should not be used
in portable software. Additionally, the way FILE's fd is used in
non-blocking mode is undefined behaviour and cannot be relied on.
This introduces internal abstraction for io streams, that allows
implementing the desired virtualization of read/write operations
with necessary timeout handling.
ASTERISK-24515 #close
ASTERISK-24517 #close
Change-Id: Id916aef418b665ced6a7489aef74908b6e376e85
During the development of Asterisk 14 the behavior of
the Command AMI action was altered such that the result
was returned on lines with a prefix of "Output: ". While
this was documented in the UPGRADE.txt file it is also
reasonable that this should bump the AMI version number.
ASTERISK-26556
Change-Id: Idf1bf01608e53f7bfdf43ddb4d0683e53f74ee42
In multi-party bridges, Asterisk currently supports two video modes:
* Follow the talker, in which the speaker with the most energy is shown
to all participants but the speaker, and the speaker sees the
previous video source
* Explicitly set video sources, in which all participants see a locked
video source
Prior to this patch, ARI had no ability to manipulate the video source.
This isn't important for two-party bridges, in which Asterisk merely
relays the video between the participants. However, in a multi-party
bridge, it can be advantageous to allow an external application to
manipulate the video source.
This patch provides two new routes to accomplish this:
(1) setVideoSource: POST /bridges/{bridgeId}/videoSource/{channelId}
Sets a video source to an explicit channel
(2) clearVideoSource: DELETE /bridges/{bridgeId}/videoSource
Removes any explicit video source, and sets the video mode to talk
detection
ASTERISK-26595 #close
Change-Id: I98e455d5bffc08ea5e8d6b84ccaf063c714e6621
This works the same as for AMI manager variables. Set
"channelvars=foo,bar" in your ari.conf general section, and then the
channel variables "foo" and "bar" (along with their values), will
appear in every Stasis websocket channel event.
ASTERISK-26492 #close
patches:
ari_vars.diff submitted by Mark Michelson
Change-Id: I5609ba239259577c0948645df776d7f3bc864229
Libedit 3.1 is not build with unicode on as a default and so the
prototype for the el_gets callback changed from expecting a char buffer
to accepting a wchar buffer. If ast_el_read_char isn't changed,
the cli reads garbage from teh terminal.
Added a configure test for (*el_rfunc_t)(EditLine *, wchar_t *) and
updated ast_el_read_char to use the HAVE_ define to detemrine whether
to use char or wchar.
ASTERISK-26592 #close
Change-Id: I9099b46f68e06d0202ff80e53022a2b68b08871a
Radcli is yet another RADIUS client library, generally compatible with
freeradius and radiusclient-ng.
This commit adds autoconf option for detecting it as well and changes
cdr_radius and cel_radius to use its header file in that case.
ASTERISK-26540 #close
Change-Id: I271f0715406334874865ffbce0b354b3a2ca148f
There are several places in Asterisk that have duplicated logic
for deferring important frames until later.
This commit adds a couple of API calls to facilitate this automatically.
ast_channel_start_defer_frames(): Future reads of deferrable frames on
this channel will be deferred until later.
ast_channel_stop_defer_frames(): Any frames that have been deferred get
requeued onto the channel.
ASTERISK-26343
Change-Id: I3e1b87bc6796f222442fa6f7d1b6a4706fb33641
Adds an identifier (with a getter and setter) to detect channels with
interleaved audio.
This is needed by the binaural bridge_softmix patch (ASTERISK-26292) and
was already discussed here:
http://lists.digium.com/pipermail/asterisk-dev/2016-October/075900.html
The identifier can be set during fmtp parsing (to be seen in the
res_format_attr_opus.c change).
ASTERISK-26292
Change-Id: I359801cc5f98c35671c48dabc81a7f4ee1183d63
The readdir_r function has been deprecated and should no longer be used. This
patch removes the readdir_r dependency (replaced it with readdir) and also moves
the directory search code to a more centralized spot (file.c)
Also removed a strict dependency on the dirent structure's d_type field as it
is not portable. The code now checks to see if the value is available. If so,
it tries to use it, but defaults back to using the stats function if necessary.
Lastly, for most implementations of readdir it *should* be thread-safe to make
concurrent calls to it as long as different directory streams are specified.
glibc falls into this category. However, since it is possible that there exist
some implementations that are not safe, locking has been added for those other
than glibc.
ASTERISK-26412
ASTERISK-26509 #close
Change-Id: Id8f54689b1e2873e82a09d0d0d2faf41964e80ba
Since adding all remaining rates of Signed Linear (ASTERISK-24274), SILK
(Gerrit 3136) and Codec 2 (ASTERISK-26217), no RTP Payload Type is left in the
dynamic range (96-127). RFC 3551 section 3 allows to reassign other ranges.
Consequently, when the dynamic range is exhausted, this change utilizes payload
types in the range between 35 and 63 giving room for another 29 payload types.
ASTERISK-26311 #close
Change-Id: I7bc96ab764bc30098a178b841cbf7146f9d64964
This patch adds three new CLI commands:
- ari show apps: list the registered ARI applications
- ari show app: show detailed information about an ARI application
- ari set debug: dump events being sent to an ARI application
Note that while these CLI commands live in the res_stasis module, we use
the 'ari' family for these commands. This was done as most users of
Asterisk aren't aware of the semantic differences between ARI and
res_stasis, and some 'ari' CLI commands already exist.
ASTERISK-26488 #close
Change-Id: I51ad6ff0cabee0d69db06858c13f18b1c513c9f5
PATH_MAX is not guaranteed to be defined. In parctice, all but the HURD
define it to a constant. It is indeed not safe to assume there won't be
longer paths and Asterisk generally does err safely on such cases.
So even for HURD we'll just pretend PATH_MAX is 4096.
ASTERISK-25070 #close
Change-Id: I53d10ba18c34c132bcb640a5fd8e0da1d9b22db3
Headers declare that memcpy does not accept NULL argument for the first
two parameters. Add a conditional block to prevent memcpy and ast_free
from running on vectors with NULL element array.
ASTERISK-26526 #close
Change-Id: I988a476bb5fcfcbd3f6d6c6b3e7769e4f9629b71
It is only safe to run ast_register_cleanup callbacks when all modules
have been unloaded. Previously these callbacks were run during graceful
shutdown, making it possible to crash during shutdown.
ASTERISK-26513 #close
Change-Id: Ibfa635bb688d1227ec54aa211d90d6bd45052e21
ASTERISK_REGISTER_FILE no longer has any purpose so this commit removes
all traces of it.
Previously exported symbols removed:
* __ast_register_file
* __ast_unregister_file
* ast_complete_source_filename
This also removes the mtx_prof static variable that was declared when
MTX_PROFILE was enabled. This variable was only used in lock.c so it
is now initialized in that file only.
ASTERISK-26480 #close
Change-Id: I1074af07d71f9e159c48ef36631aa432c86f9966
When channel format changes occurred as a result of an RTP
re-negotiation the bridge was not informed this had happened.
As a result the bridge technology was not re-evaluated and the
channel may have been in a bridge technology that was incompatible
with its formats. The bridge is now unbridged and the technology
re-evaluated when this occurs.
The chan_pjsip module also allowed asymmetric codecs for sending
and receiving. This did not work with all devices and caused one
way audio problems. The default has been changed to NOT do this
but to match the sending codec to the receiving codec. For users
who want asymmetric codecs an option has been added, asymmetric_rtp_codec,
which will return chan_pjsip to the previous behavior.
The codecs returned by the chan_pjsip module when queried by
the bridge_native_rtp module were also not reflective of the
actual negotiated codecs. The nativeformats are now returned as
they reflect the actual negotiated codecs.
ASTERISK-26423 #close
Change-Id: I6ec88c6e3912f52c334f1a26983ccb8f267020dc
ARI and AMI allow for an explicit channel ID to be specified
when originating channels. Unfortunately, there is nothing in
place to prevent someone from using the same ID for multiple
channels. Further complicating things, adding ID validation to channel
allocation makes it impossible for ARI to discern why channel allocation
failed, resulting in a vague error code being returned.
The fix for this is to institute a new method for channel errors to be
discerned. The method mirrors errno, in that when an error occurs, the
caller can consult the channel errno value to determine what the error
was. This initial iteration of the feature only introduces "unknown" and
"channel ID exists" errors. However, it's possible to add more errors as
needed.
ARI uses this feature to determine why channel allocation failed and can
return a 409 error during origination to show that a channel with the
given ID already exists.
ASTERISK-26421
Change-Id: Ibba7ae68842dab6df0c2e9c45559208bc89d3d06
Since the json library does not make the check function public we
recreate/copy the function in our interface module.
ASTERISK-26466
Reported by: Richard Mudgett
Change-Id: I36d3d750b6f5f1a110bc69ea92b435ecdeeb2a99
Adds libfftw3 to the build chain that is is going to be used for binaural
synthesis by bridge_softmix.
ASTERISK-26292
Change-Id: Iedc2f174e4ccb39ae5d9e698e339c6a17155867b
Small fix. It is necessary to double-check
the index that we just removed because there
is a new element.
ASTERISK-26453 #close
Change-Id: Ib947fa94dc91dcd9341f357f1084782c64434eb7
Fixed a memory leak. It removes only the first element.
Added a useful feature in vector.h to remove all items
under the CMP through a callback function / macro.
ASTERISK-26453 #close
Change-Id: I84508353463456d2495678f125738e20052da950
We use a lot res_calendar, we are very happy with that, especially
because you use libical, the almost alone opensource library that
supports really ical format with all types of recurrency.
Nevertheless, some features are missed for our business use cases.
This first patch adds a new option in calendar.conf:
fetch_again_at_reload. Be my guest for a better name.
If it's true, when you'll launch "module reload res_calendar.so",
Asterisk will download again the calendar.
The business use case is that we have a WebUI with a scheduler planner,
we know when the calendars are modified.
For now, we need to define 1 minute of timeout to have a chance that
our user doesn't wait too long between the modification and the real
test. But it generates a lot of useless HTTP traffic.
ASTERISK-26422 #close
Change-Id: I384b02ebfa42b142bbbd5b7221458c7f4dee7077
Added tests for bzip2, tar, patch, sed and nm to configure.ac.
Set DOWNLOAD_TO_STDOUT to a working command line regardless of
whether the download program is wget, curl or fetch.
Added a 'configure.m4' file to the third-party directory which takes
care of calling any third-party project setup. Had to move some
pjproject_bundled stuff up in configure.ac so it was called before
the third-party configure macro.
The pjproject tarball is now downloaded to the externals_cache_dir if
it was specified on the ./configure command line
Removed regeneration of the pjproject aconfigure file. It was only
needed for an old patch that no longer applies.
Converted the tests for symbols to explicit tests since we know that
they're now available in the bundled version. Saves a little time
during configure.
ASTERISK-26416 #close
Reported-by: Corey Farrell
Change-Id: Id1d94251c0155f8dd41b7de7067f35cfbaafbb9b
(cherry picked from commit e6b0053d75)
(cherry picked from commit a0d02f3832)
Asterisk only supports mono audio at the moment.
This patch adds interleaved two-channel audio to Asterisk's channels.
ASTERISK-26292
Change-Id: I7a547cea0fd3c6d1e502709d9e7e39605035757a
* Compile __ast_assert_failed unconditionally.
* Use __ast_assert_failed to log messages from log_bad_ao2
* Remove calls to ast_assert(0) that happen after log_bad_ao2 was run.
Change-Id: I48f1af44b2718ad74a421ff75cb6397b924a9751
This allows asterisk to compiled with LOW_MEMORY to load modules built
without LOW_MEMORY.
ASTERISK-26398 #close
Change-Id: I24b78ac9493ab933b11087a8b6794f3c96d4872d
Add Ogg/Opus playback support.
This uses libopusfile in order to be able to read .opus files and play
them back.
Writing/recording support is not present at this time.
ASTERISK-26409
Change-Id: I8815d23345108d8ca7c0bd640f6a1ce6b4f56955
(cherry picked from commit daee8bbd5209b4158bc1785eede845a26e6cbeaa)
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
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
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
This patch add config to pjsip by endpoint.
;preferred_codec_only=yes
; Respond to a SIP invite with the single most preferred codec
; rather than advertising all joint codec capabilities. This
; limits the other side's codec choice to exactly what we prefer.
ASTERISK-26317 #close
Reported by: AaronAn
Tested by: AaronAn
Change-Id: Iad04dc55055403bbf5ec050997aee2dadc4f0762
On heavy loaded system the TCP/TLS incoming calls could be
disconnected by pjproject while these calls are being
processed by asterisk which could use the session's memory pools.
If the session in the disconnected state then the session memory
pools were already freed, so we get segfault.
This patch adds a lifetime control on an INVITE session to pjproject.
The lifetime of the session is manipulated by calling
pjsip_inv_add_ref/pjsip_inv_dec_ref.
This patch uses these functions to inform pjproject that the
session is in use.
This patch adds check if the session state is not disconnected
and also checks if the memory pool is not NULL.
This patch also places tasks 'session_end' and 'session_end_completion'
into session's serializer to avoid race condition.
ASTERISK-26291 #close
Change-Id: I4d28b1fb3b91f0492a911d110049d670fdc3c8d7
Create an alternative to ast_sorcery_generic_alloc which uses astobj2
shared locking. Use this new method for the 'struct ast_sip_aor' allocator.
Change-Id: I3f62f2ada64b622571950278fbb6ad57395b5d6f
This allows standard ao2 functions to be used to release references to
an ast_named_lock. This change can cause less frequent locking of the
global named_locks container. The container is no longer locked when a
named_lock reference is being release except when this causes the
named_lock to be destroyed.
Change-Id: I644e39c6d83a153d71b3fae77ec05599d725e7e6
ast_channel_get_t38_state() calls ast_channel_queryoption() with
AST_OPTION_T38_STATE. If the passed in channel is a local channel then a
deadlock can happen if a channel lock is held when called.
* Made ast_channel_get_t38_state() callers not hold a channel lock before
calling.
* Update ast_channel_get_t38_state() doxygen to note that no channel locks
can be held when calling the function.
ASTERISK-26203 #close
Reported by: Etienne Lessard
ASTERISK-24822 #close
Reported by: David Brillert
ASTERISK-22732 #close
Reported by: Richard Mudgett
Change-Id: I49fd76fa9af628b4198009b5c0b82c8b03681214
ASTERISK-25980 added the FAXMODE channel variable to res_fax.c.
Unfortunately, it also introduced a deadlock potential because
set_channel_variables() which sets FAXMODE can be called during a
masquerade. The ast_channel_get_t38_state() which gets the value used to
set FAXMODE cannot be called with the channel locked. As a result, local
channels can deadlock because of how they must acquire the locks necessary
to operate.
The intent of FAXMODE is for dialplan to know how a fax was transferred
after the fax completes. However, the previous patch sets FAXMODE to the
channel's current T.38 state AFTER the fax has completed and where T.38
may have already disconnected.
* Set FAXMODE based upon T.38 negotiations exchanged either with the fax
applications or the fax framehooks.
ASTERISK-26203
Reported by: Etienne Lessard
ASTERISK-24822
Reported by: David Brillert
ASTERISK-22732
Reported by: Richard Mudgett
Change-Id: Id525747254b64c1efe8b1b5973d52ff9719c2ae1
MALLOC_DEBUG should not be used to check if debugging is actually
enabled, __AST_DEBUG_MALLOC should be used instead. MALLOC_DEBUG only
indicates that debugging is requested, __AST_DEBUG_MALLOC indicates it
is active.
Change-Id: I3ce9cdb6ec91b74ee1302941328462231be1ea53
Allocator functions that take file/line/func parameters are prefixed
with single-underscore when MALLOC_DEBUG is not defined,
double-underscore when it is defined. This change updates all
allocators that accept file/line/func to have the same prototype in
either ABI mode. The parameter order of __ast_vasprintf and
__ast_asprintf in utils.h have been changed to match that of astmm.h.
End-use allocator macro's have been removed from astmm.h and moved to an
unconditional part of utils.h.
Change-Id: I823bb6ce2b5675b3a4735948f10a3b420e9a023a
updated the uri handler to include the url prefix of the http server
this enables res_ari to add it to the uris when generating docs
Change-Id: I279335a2625261a8492206c37219698f42591c2e
(cherry picked from commit 6f448f32fe)
contact_user, when specified on an endpoint, will override the user
portion of the Contact header on outgoing requests.
Change-Id: Icd4ebfda2f2e44d3ac749d0b4066630e988407d4
The Exchanging Device and Mailbox States could not working
if the Entity ID (EID) is not set manually and can't be obtained
from ethernet interface.
This patch replaces debug message to warning
and addes missing description about option 'entityid' to
asterisk.conf.sample.
With this patch the asterisk also:
(1) decline loading the modules which won't work without EID:
res_corosync and res_pjsip_publish_asterisk.
(2) warn if EID is empty on loading next modules:
pbx_dundi, res_xmpp
Starting with v197 systemd/udev will automatically assign "predictable"
names for all local Ethernet interfaces.
This patch also addes some new ethernet prefixes "eno" and "ens".
ASTERISK-26164 #close
Change-Id: I72d712f1ad5b6f64571bb179c5cb12461e7c58c6
A patch made to the master branch (Now the 14 branch) inadvertently made
libsrtp a required dependency in order to compile Asterisk. Rather than
create dummy defines to substitute for the defines supplied by libsrtp
when libsrtp is not available, most of the code in sdp_srtp.c is moved
into res_srtp.c. This gets more code out of Asterisk's core that isn't
used when SRTP is not available. This also makes another inadvertent
required dependency on libsrtp by Asterisk's core unlikely.
ASTERISK-26253 #close
Reported by: Ben Merrills
Change-Id: I0a46cde81501c0405399c2588633ae32706d1ee7
If both channels which should be masqueraded
are in the same serializer:
1st channel will be locked waiting condition 'complete'
2nd channel will be locked waiting condition 'suspended'
On heavy load system a chance that both channels will be in
the same serializer 'pjsip/distibutor' is very high.
To reproduce compile res_pjsip/pjsip_distributor.c with
DISTRIBUTOR_POOL_SIZE=1
Steps to reproduce:
1. Party A calls Party B (bridged call 'AB')
2. Party B places Party A on hold
3. Party B calls Voicemail app (non-bridged call 'BV')
4. Party B attended transfers Party A to voicemail using REFER.
5. When asterisk masquerades calls 'AB' and 'BV',
a deadlock is happened.
This patch adds a suspension indicator to the taskprocessor.
When a session suspends/unsuspends the serializer
it sets the indicator to the appropriate state.
The session checks the suspension indicator before
suspend the serializer.
ASTERISK-26145 #close
Change-Id: Iaaebee60013a58c942ba47b1b4930a63e686663b
libunbound at version 1.4.20 (which CentOS still uses) declared all
of their string function parameters as as 'char *'. 1.4.21 changed
them all to 'const char *'. Thankfully 1.4.21 also introduced the
UNBOUND_VERSION_MAJOR define so configure now checks for that and
sets HAVE_UNBOUND_CONST_PARAMS. res_resolver_unbound then checks
that and casts away the 'const' if it's not set.
Tested compile and testsuite on CentOS6 (1.4.20), Ubuntu14 (1.4.22) and
Fedora24 (1.5.4). There are a few failing tests to be addressed though.
ASTERISK-26283 #close
Change-Id: Ib708b19b706c5d0ba7b7d5473e6df339d9ae4148
Modules must define AST_MODULE_SELF_SYM to be used as the name of a
generated function. This produces a friendly error when it's not
defined.
ASTERISK-26278 #close
Change-Id: Ib9d35a08104529c516d636771365e02c6e77a45b
The PJSIP taskprocessors could be overflowed on startup
if there are many (thousands) realtime endpoints
configured with unsolicited mwi.
The PJSIP stack could be totally unresponsive for a few minutes
after boot completed.
This patch creates a separate PJSIP serializers pool for mwi
and makes unsolicited mwi use serializers from this pool.
This patch also adds 2 new global options to tune taskprocessor
alert levels: 'mwi_tps_queue_high' and 'mwi_tps_queue_low'.
This patch also adds new global option 'mwi_disable_initial_unsolicited'
to disable sending unsolicited mwi to all endpoints on startup.
If disabled then unsolicited mwi will start processing
on next endpoint's contact update.
ASTERISK-26230 #close
Change-Id: I4c8ecb82c249eb887930980a800c9f87f28f861a
This ensures startup is canceled due to allocation failures from the
following initializations.
* channel.c: ast_channels_init
* config_options.c: aco_init
ASTERISK-26265 #close
Change-Id: I911ed08fa2a3be35de55903e0225957bcdbe9611
We can allow dangerous functions when adding a hint since altering
dialplan is itself a privileged activity. Otherwise, we could never
execute dangerous functions.
ASTERISK-25996 #close
Reported by: Andrew Nagy
Change-Id: I4929ff100ad1200a0198262d069a34f2296e77ba
Asterisk already supported iLBC 30. This change adds iLBC 20. Now, Asterisk
defaults to iLBC 20 but falls back to iLBC 30, when the remote party requests
this.
ASTERISK-26218 #close
ASTERISK-26221 #close
Reported by: Aaron Meriwether
Change-Id: I07f523a3aa1338bb5217a1bf69c1eeb92adedffa
This changes context switches from a linked list to a vector, makes
'struct ast_sw' opaque to pbx.c.
Although ast_walk_context_switches is maintained the procedure is no
longer efficient except for the first call (inc==NULL). This
functionality is replaced by two new functions implemented by vector
macros.
* ast_context_switches_count (AST_VECTOR_SIZE)
* ast_context_switches_get (AST_VECTOR_GET)
As with ast_walk_context_switches callers of these functions are
expected to have locked contexts. Only a few places in Asterisk walked
the switches, they have been converted to use the new functions.
Change-Id: I08deb016df22eee8288eb03de62593e45a1f0998
This adds support for tagging functions with the noreturn attribute.
If DO_CRASH is enabled then ast_do_crash never returns. If AST_DEVMODE
and DO_CRASH are enabled then failed assertions never return. This can
resolve a large number of false positives with static analyzers.
ASTERISK-26220 #close
Change-Id: Icfb61e5fe54574eced4c3e88b317244f467ec753
The fax detection timeout option did not work because basically the wrong
variable was checked in fax_detect_framehook(). As a result, the timer
would timeout immediately and disable fax detection.
* Fixed ignoring negative timeout values. We'd complain and then go right
on using the negative value.
* Fixed destroy_faxdetect() in the off-nominal case of an incomplete
object creation.
* Added more range checking to FAXOPT(gateway) timeout parameter.
ASTERISK-26214 #close
Reported by: Richard Mudgett
Change-Id: Idc5e698dfe33572de9840bc68cd9fc043cbad976
The new endpoint option allows the PJSIP channel driver's fax_detect
endpoint option to timeout on a call after the specified number of
seconds into a call. The new feature is disabled if the timeout is set
to zero. The option is disabled by default.
ASTERISK-26214
Reported by: Richard Mudgett
Change-Id: Id5a87375fb2c4f9dc1d4b44c78ec8735ba65453d
This changes context ignore patterns from a linked list to a vector,
makes 'struct ast_ignorepat' opaque to pbx.c.
Although ast_walk_context_ignorepats is maintained the procedure is no
longer efficient except for the first call (inc==NULL). This
functionality is replaced by two new functions implemented by vector
macros.
* ast_context_ignorepats_count (AST_VECTOR_SIZE)
* ast_context_ignorepats_get (AST_VECTOR_GET)
As with ast_walk_context_ignorepats callers of these functions are
expected to have locked contexts. Only a few places in Asterisk walked
the ignorepats, they have been converted to use the new functions.
Change-Id: I78f2157d275ef1b7d624b4ff7d770d38e5d7f20a
This changes context includes from a linked list to a vector, makes
'struct ast_include' opaque to pbx.c.
Although ast_walk_context_includes is maintained the procedure is no
longer efficient except for the first call (inc==NULL). This
functionality is replaced by two new functions implemented by vector
macros.
* ast_context_includes_count (AST_VECTOR_SIZE)
* ast_context_includes_get (AST_VECTOR_GET)
As with ast_walk_context_includes callers of these functions are
expected to have locked contexts. Only a few places in Asterisk walked
the includes, they have been converted to use the new functions.
const have been applied where possible to parameters for ast_include
functions.
Change-Id: Ib5c882e27cf96fb2aec67a39c18b4c71c9c83b60
This commit adds scaffolding in order to support the SILK audio format
on calls. Roughly, this is what is added:
* Cached silk formats. One for each possible sample rate.
* ast_codec structures for each possible sample rate.
* RTP payload mappings for "SILK".
In addition, this change overhauls the res_format_attr_silk file in the
following ways:
* The "samplerate" attribute is scrapped. That's native to the format.
* There are far more checks to ensure that attributes have been
allocated before attempting to reference them.
* We do not SDP fmtp lines for attributes set to 0.
These changes make way to be able to install a codec_silk module and
have it actually work. It also should allow for passthrough silk calls
in Asterisk.
Change-Id: Ieeb39c95a9fecc9246bcfd3c45a6c9b51c59380e
Since July 2014, TLS based protocols (SIP over TLS, Secure WebSockets, HTTPS)
support PFS thanks to ASTERISK-23905. In July 2015, the same feature was added
for DTLS. The source code from main/tcptls.c should have been re-used to ease
security audits. Therefore, this change rolls back the change from July 2015 and
re-uses the code from July 2014. This has the additional benefits to work under
CentOS 7 and enabling not just ECDHE but DHE based cipher suites as well.
ASTERISK-25659 #close
Reported by: StefanEng86, urbaniak, pay123
Tested by: sarumjanuch, traud
patches:
res_rtp_asterisk.patch submitted by sarumjanuch
dtls_centos_step_1.patch submitted by traud
dtls_centos_step_2.patch submitted by traud
Change-Id: I537cadf4421f092a613146b230f2c0ee1be28d5c
When res_corosync detects that a node leaves or joins, it currently is
informed of this via Corosync callbacks. However, there are a few
limitations with the information presented:
(1) While we have information that Corosync is aware of - such as the
Corosync nodeid - that information is really only useful inside of
Corosync or res_corosync. There's no way to translate a Corosync
nodeid to some other internally useful unique identifier for the
Asterisk instance that just joined or left the cluster.
(2) While res_corosync is notified of the instance joining or leaving
the cluster, it has no mechanism to inform the Asterisk core or
other modules of this event. This limits the usefulness of res_corosync
as a heartbeat mechanism for other modules.
This patch addresses both issues.
First, it adds the notion of a cluster discovery message both within the
Stasis message bus, as well as the binary event messages that
res_corosync uses to transmit data back and forth within the cluster.
When Asterisk joins the cluster, it sends a discovery message to the other
nodes in the cluster, which correlates the Corosync nodeid along with
the Asterisk EID. res_corosync now maintains a hash of Corosync nodeids
to Asterisk EIDs, such that it can map changes in cluster state with the
Asterisk instance that has that nodeid. Likewise, when an Asterisk
instance receives a discovery message from a node in the cluster, it now
sends its own discovery message back to the originating node with the
local Asterisk EID. This lets Asterisk instances within the cluster
build a complete picture of the other Asterisk instances within the
cluster.
Second, it publishes the discovery messages onto the Stasis message bus.
Said messages are published whenever a node joins or leaves the cluster.
Interested modules can subscribe for the ast_cluster_discovery_type()
message under the ast_system_topic() and be notified when changes in
cluster state occur.
Change-Id: I9015f418d6ae7f47e4994e04e18948df4d49b465
Updated the macro-set autoconf/ax_pthread.m4 to its latest upstream version.
ASTERISK-26046 #close
Change-Id: I11abc11d17acd2b6a8a5a5be8ae8e0949dab9cc7
The ASTERISK-25904 change-id I8fad8aae9305481469c38d2146e1ba3a56d3108f
patch introduced several regressions when the newly created "Updated"
state goes out for each endpoint registration refresh.
1) It restarted any OPTIONS RTT ping cycle.
2) It would interfere with a currently active ping and throw off that
ping's resulting RTT calculation.
3) It cleared the RTT time each time the endpoint was refreshed.
4) The cleared RTT time was sent out as a statsd update each time.
5) It created two AMI events for each update.
* Revert the original patch and reimplement it. Now the current contact
status state is re-sent instead of the state being momentarily toggled
every time the endpoint refreshes its registration. The statsd events are
not created for the re-sent refresh because they are sent after every
OPTIONS ping.
ASTERISK-26160 #close
Reported by: Matt Jordan
Change-Id: Ie072be790fbb2a8f5c1c874266e4143fa31f66d1
The func_odbc module was modified to ensure that the
previous behavior of using a single database connection
was maintained. This was done by getting a single database
connection and holding on to it. With the new multiple
connection support in res_odbc this will actually starve
every other thread from getting access to the database as
it also maintains the previous behavior of having only
a single database connection.
This change disables the func_odbc specific behavior if
the res_odbc module is running with only a single database
connection active. The connection is only kept for the
duration of the request.
ASTERISK-26177 #close
Change-Id: I9bdbd8a300fb3233877735ad3fd07bce38115b7f
If specified, incoming SUBSCRIBE requests will be searched for the matching
extension in the indicated context. If no "subscribe_context" is specified,
then the "context" setting is used.
ASTERISK-25471 #close
Change-Id: I3fb7a15f5bc154079bd348c08b7ad1cdd2d5e514
Updated the macro-set autoconf/libcurl.m4 to its latest upstream version. This
avoids a warning about an obsolete macro on AC_HELP_STRING, because Asterisk is
using AS_HELP_STRING everywhere else already.
ASTERISK-26046
Change-Id: I8299faf504ceaeee3e39930c59293809e116c631
Adding format_name even to the end of ast_codec caused issued with
binary codec modules because the pointer would be garbage in asterisk
when they registered. So, the ast_codec structure was reverted and an
internal_ast_codec structure was created just for use in codec.c. A new
internal-only API was also added (__ast_codec_register_with_format) so
that codec_builtin could register codecs with the format_name in a
separate parameter rather than in the ast_codec structure.
ASTERISK-26144 #close
Reported-by: Alexei Gradinari
Change-Id: I6df1b08f6a6ae089db23adfe1ebc8636330265ba
Removed the obsolete macro AC_TYPE_SIGNAL because Asterisk does not use K&R C
but requires ANSI C anyway.
ASTERISK-26046
Change-Id: I914c014385e1862102d90fe7650621def78db02e
The patch removes updating all Endpoints' status on startup.
Instead, only non-qualified aors with static contact
and non-qualified non-expired contacts are retrieved from the realtime to
update the endpoint status to ONLINE.
The endpoint name was added to the contact object to simply find the endpoint
that created this contact.
The status of endpoints with qualified aors will be updated by 'qualify'
functions.
ASTERISK-26061 #close
Change-Id: Id324c1776fa55d3741e0c5457ecac0304cb1a0df
A non-existent constraint was being referenced in the upgrade script.
This patch corrects the problem by removing the reference.
In addition, the head of the alembic branch referred to a non-existent
revision. This has been fixed by referring to the proper revision.
This patch fixes another realtime problem as well. Our Alembic scripts
store booleans as yes or no values. However, Sorcery tries to insert
"true" or "false" instead. This patch introduces a new boolean type that
translates to "yes" or "no" instead.
ASTERISK-26128 #close
Change-Id: I51574736a881189de695a824883a18d66a52dcef
Occasionally under load we'll attempt to send a final NOTIFY on a
subscription that's already been terminated and a SEGV will occur
down in pjproject's evsub_destroy function. This is a result of a
race condition between all the paths that can generate a notify
and/or destroy the underlying pjproject evsub object:
* The client can send a SUBSCRIBE with Expires: 0.
* The client can send a SUBSCRIBE/refresh.
* The subscription timer can expire.
* An extension state can change.
* An MWI event can be generated.
* The pjproject transaction timer (timer_b) can expire.
Normally when our pubsub_on_evsub_state is called with a terminate,
we push a task to the serializer and return at which point the dialog
is unlocked. This is usually not a problem because the task runs
immediately and locks the dialog again. When the system is heavily
loaded though, there may be a delay between the unlock and relock
during which another event may occur such as the subscription timer
or timer_b expiring, an extension state change, etc. These may also
cause a terminate to be processed and if so, we could cause pjproject
to try to destroy the evsub structure twice. There's no way for us to
tell that the evsub was already destroyed and the evsub's group lock
can't tolerate this and SEGVs.
The remedy is twofold.
* A patch has been submitted to Teluu and added to the bundled
pjproject which adds add/decrement operations on evsub's group lock.
* In res_pjsip_pubsub:
* configure.ac and pjproject-bundled's configure.m4 were updated
to check for the new evsub group lock APIs.
* We now add a reference to the evsub group lock when we create
the subscription and remove the reference when we clean up the
subscription. This prevents evsub from being destroyed before
we're done with it.
* A state has been added to the subscription tree structure so
termination progress can be tracked through the asyncronous tasks.
* The pubsub_on_evsub_state callback has been split so it's not doing
double duty. It now only handles the final cleanup of the
subscription tree. pubsub_on_rx_refresh now handles both client
refreshes and client terminates. It was always being called for
both anyway.
* The serialized_on_server_timeout task was removed since
serialized_pubsub_on_rx_refresh was almost identical.
* Missing state checks and ao2_cleanups were added.
* Some debug levels were adjusted to make seeing only off-nominal
things at level 1 and nominal or progress things at level 2+.
ASTERISK-26099 #close
Reported-by: Ross Beer.
Change-Id: I779d11802cf672a51392e62a74a1216596075ba1
Announcer channels were not being destroyed because the
stasis_app_control structure that referenced them was not being
destroyed. The control structure was not being destroyed because it was
not being unlinked from its container. It was not being unlinked from
its container because the after bridge callback for the announcer
channel was not being run. The after bridge callback was not being run
because the after bridge datastore was not being removed from the
channel on destruction. The channel was not being destroyed because the
hangup that used to destroy the channel was now only reducing the
reference count to one. The reference count of the channel was only
being reduced to one because the stasis_app_control structure was
holding the final reference...
The control structure used to not keep a reference to the channel, so
that loop described above did not happen.
The solution is to manually remove the control structure from its
container when the playback on a bridge is complete.
ASTERISK-26083 #close
Reported by Joshua Colp
Change-Id: I0ddc0f64484ea0016245800b409b567dfe85cfb4
Stasis subscriptions and message routers create taskprocessors to process
the event messages. API calls are needed to be able to set the congestion
levels of these taskprocessors for selected subscriptions and message
routers.
* Updated CDR, CEL, and manager's stasis subscription congestion levels
based upon stress testing. Increased the congestion levels to reduce the
potential for bursty call setup/teardown activity from triggering the
taskprocessor overload alert. CDRs in particular need an extra high
congestion level because they can take awhile to process the stasis
messages.
ASTERISK-26088
Reported by: Richard Mudgett
Change-Id: Id0a716394b4eee746dd158acc63d703902450244
Sorcery creates taskprocessors for object types to process object observer
callbacks. An API call is needed to be able to set the congestion levels
of these taskprocessors for selected object types.
* Updated PJSIP's contact and contact_status sorcery object type observer
default congestion levels based upon stress testing. Increased the
congestion levels to reduce the potential for bursty register/unregister
and subscribe/unsubscribe activity from triggering the taskprocessor
overload alert.
ASTERISK-26088
Reported by: Richard Mudgett
Change-Id: I4542e83b556f0714009bfeff89505c801f1218c6
When taskprocessors get backed up, there is a good chance that we are
being overloaded and need to defer adding new work to the system.
* Implemented a high/low water alert mechanism for modules to check if the
system is being overloaded and take appropriate action. When a
taskprocessor is created it has default congestion levels set. A
taskprocessor can later have those congestion levels altered for specific
needs if stress testing shows that the taskprocessor is a symptom of
overloading or needs to handle bursty activity without triggering an
overload alert.
* Add CLI "core show taskprocessor" low/high water columns.
* Fixed __allocate_taskprocessor() to not use RAII_VAR(). RAII_VAR() was
never a good thing to use when creating a taskprocessor because of the
nature of how its references needed to be cleaned up on a partial
creation.
* Made res_pjsip's distributor check if the taskprocessor overload alert
is active before placing a message representing brand new work onto a
distributor serializer.
ASTERISK-26088
Reported by: Richard Mudgett
Change-Id: I182f1be603529cd665958661c4c05ff9901825fa
We must continue using the serializer that the original INVITE came in on
for the dialog. There may be retransmissions already enqueued in the
original serializer that can result in reentrancy and message sequencing
problems.
Outgoing call legs create the pjsip/outsess/<endpoint> serializers for
their dialogs.
ASTERISK-26088
Reported by: Richard Mudgett
Change-Id: I24d7948749c582b8045d5389ba3f6588508adbbc
Incoming messages that are not part of a dialog or a recognized response
to one of our requests need to be sent to a consistent serializer. Under
load we may be queueing retransmissions before we can process the original
message. We don't need to throw these messages onto random serializers
and cause reentrancy and message sequencing problems.
* Created a pool of pjsip/distributor serializers that get picked by
hashing the call-id and remote tag strings of the received messages.
* Made ast_sip_destroy_distributor() destroy items in the reverse order of
creation.
ASTERISK-26088
Reported by: Richard Mudgett
Change-Id: I2ce769389fc060d9f379977f559026fbcb632407
A crash can occur in res_hep_pjsip or res_hep_rtcp if res_hep has not
loaded and does not have a configuration file. Previously when this
occurred, checks were put in to see if the configuration was loaded
successfully. While this is a good idea - and has been added to the
offending function in res_hep - the reality is res_hep_pjsip and
res_hep_rtcp have no business running if res_hep isn't also running.
As such, this patch also adds a function to res_hep that returns whether
or not it successfully loaded. Oddly enough, ast_module_check returns
"everything is peachy" even if a module declined its load - so it cannot
be solely relied on. res_hep_pjsip and res_hep_rtcp now also check this
function to see if they should continue to load; if it fails, they
decline their load as well.
ASTERISK-26096 #close
Change-Id: I007e535fcc2e51c2ca48534f48c5fc2ac38935ea
If you create a local channel and don't specify an originator channel
to take capabilities from, we automatically add all audio formats to
the new channel's capabilities. When we try to make the channel
compatible with another, the "best format" functions pick the best
format available, which in this case will be slin192. While this is
great for preserving quality, it's the worst for performance and
overkill for the vast majority of applications.
In the absense of any other information, adding all formats is the
correct thing to do and it's not always possible to supply an
originator so a new parameter 'formats' has been added to the channel
create/originate functions. It's just a comma separated list of formats
to make availalble for the channel. Example: "ulaw,slin,slin16".
'formats' and 'originator' are mutually exclusive.
To facilitate determination of format names, the format name has been
added to "core show codecs".
ASTERISK-26070 #close
Change-Id: I091b23ecd41c1b4128d85028209772ee139f604b
POSIX defines poll.h, sys/poll.h should not be used at is c-library
internal header which may or may not exist. Notable in musl it
generates warning of being incorrect. And add explict include of
sys/cdefs.h where needed.
Change-Id: I142930df53fe7585a06b854b6faddc5301e024be
This adds a new parameter to the end of a multicast RTP dialing string.
This parameter defines the following options:
* i: Set the interface from which multicast RTP is sent
* l: Set whether multicast packets are looped back to the sender
* t: Set the TTL for multicast packets
* c: Set the codec to use for RTP
ASTERISK-26068 #close
Reported by Mark Michelson
Change-Id: I033b706b533f0aa635c342eb738e0bcefa07e219
ARI dial had been implemented using the Dial API. This made great sense
when dialing was 100% separate from bridging. However, if a channel were
to be added to a bridge during the dial attempt, there would be a
conflict between the dialing thread and the bridging thread. Each would
be attempting to read frames from the dialed channel and act on them.
The initial attempt to make the two play nice was to have the Dial API
suspend the channel in the bridge and stay in charge of the channel
until the dial was complete. The problem with this was that it was
riddled with potential race conditions. It also was not well-suited for
the case where the channel changed which bridge it was in during the
dial.
This new approach removes the use of the Dial API altogether. Instead,
the channel we are dialing is placed into an invisible ARI dialing
bridge. The bridge channel thread handles incoming frames from the
channel. If the channel is added to a real bridge, it is departed from
the invisible bridge and then added to the real bridge. Similarly, if
the channel is removed from the real bridge, it is automatically added
back to the invisible bridge if the dial attempt is still active.
This approach keeps the threading simple by always having the channel
being handled by bridge channel threads.
ASTERISK-25925
Change-Id: I7750359ddf45fcd45eaec749c5b3822de4a8ddbb
As res_pjsip_nat rewrites contact's address, only the last Via header
can contain the source address of registered endpoint.
Also Call-Id header may contain the source address of registered
endpoint.
Added "via_addr", "via_port", "call_id" to contact.
Added new fields ViaAddress, CallID to AMI event ContactStatus.
ASTERISK-26011
Change-Id: I36bcc0bf422b3e0623680152d80486aeafe4c576
Invisible bridges function the same as normal bridges, but they have the
following restrictions:
* They never show up in CLI, AMI, or ARI queries.
* They do not have Stasis messages published about them.
Invisible bridges' main use is for when use of the bridging system is
desired, but the bridge should not be known to users of the Asterisk
system.
ASTERISK-25925
Change-Id: I804a209d3181d7c54e3d61a60eb462e7ce0e3670
The characters 0x80-0xFF were trimmed as well as 0x00-0x20 because of
a signed comparison.
ASTERISK-25669 #close
Reported by: Jesper
patches:
strings.curl.trim.patch submitted by Jesper (License 5518)
Change-Id: Ia51e169f24e3252a7ebbaab3728630138ec6f60a
This patch adds a new feature to ARI that allows a client to download
the media associated with a stored recording. The new route is
/recordings/stored/{name}/file, and transmits the underlying binary file
using Asterisk's HTTP server's underlying file transfer facilities.
Because this REST route returns non-JSON, a few small enhancements had
to be made to the Python Swagger generation code, as well as the
mustache templates that generate the ARI bindings.
ASTERISK-26042 #close
Change-Id: I49ec5c4afdec30bb665d9c977ab423b5387e0181
This change uses the newly added multi-user support for
outbound publish to publish to the specific user that an
extension state change is for.
This also extends the res_pjsip_outbound_publish support
to include the user specific From and To URI information in
the outbound publishing of extension state. Since the URI
is used when constructing the body it is important to ensure
that the correct local and remote URIs are used.
Finally the max string growths for the dialog-info+xml
body generator has been increased as through testing it has
proven to be too conservative.
ASTERISK-25965
Change-Id: I668fdf697b1e171d4c7e6f282b2e1590f8356ca1
Added a new multi_user option that when specified allows a particular
configuration to be used for multiple users. It does this by replacing
the user portion of the server uri with a dynamically created one.
Two new API calls have been added in order to make use of the new
functionality:
ast_sip_publish_user_send - Sends an outgoing publish message based on the
given user. If state for the user already exists it uses that, otherwise
it dynamically creates new outbound publishing state for the user at that
time.
ast_sip_publish_user_remove - Removes all outbound publish state objects
associated with the user. This essentially stops outbound publishing for
the user.
ASTERISK-25965 #close
Change-Id: Ib88dde024cc83c916424645d4f5bb84a0fa936cc
Many ARI applications will want to play multiple media files in a row to
a resource. The most common use case is when building long-ish IVR prompts
made up of multiple, smaller sound files. Today, that requires building a
small state machine, listening for each PlaybackFinished event, and triggering
the next sound file to play. While not especially challenging, it is tedious
work. Since requiring developers to write tedious code to do normal activities
stinks, this patch adds the ability to play back a list of media files to a
resource.
Each of the 'play' operations on supported resources (channels and bridges)
now accepts a comma delineated list of media URIs to play. A single Playback
resource is created as a handle to the entire list. The operation of playing
a list is identical to playing a single media URI, save that a new event,
PlaybackContinuing, is raised instead of a PlaybackFinished for each non-final
media URI. When the entire list is finished being played, a PlaybackFinished
event is raised.
In order to help inform applications where they are in the list playback, the
Playback resource now includes a new, optional attribute, 'next_media_uri',
that contains the next URI in the list to be played.
It's important to note the following:
- If an offset is provided to the 'play' operations, it only applies to the
first media URI, as it would be weird to skip n seconds forward in every
media resource.
- Operations that control the position of the media only affect the current
media being played. For example, once a media resource in the list
completes, a 'reverse' operation on a subsequent media resource will not
start a previously completed media resource at the appropiate offset.
- This patch does not add any new operations to control the list. Hopefully,
user feedback and/or future patches would add that if people want it.
ASTERISK-26022 #close
Change-Id: Ie1ea5356573447b8f51f2e7964915ea01792f16f
When 2d7a4a3357 was merged, it missed the fact that Verbose log messages
are formatted and handled by 'verbosers'. Verbosers are registered
functions that handle verbose messages only; they exist as a separate
class of callbacks. This was done to handle the 'magic' that must be
inserted into Verbose messages sent to remote consoles, so that the
consoles can format the messages correctly, i.e., the leading
tabs/characters.
In reality, verbosers are a weird appendage: they're a separate class of
formatters/message handlers outside of what handles all other log
messages in Asterisk. After some code inspection, it became clear that
simply passing a Verbose message along with its 'sublevel' importance
through the normal logging mechanisms removes the need for verbosers
altogether.
This patch removes the verbosers, and makes the default log formatter
aware that, if the log channel is a console log, it should simply insert
the 'verbose magic' into the log messages itself. This allows the
console handlers to interpret and format the verbose message
themselves.
This simplifies the code quite a lot, and should improve the performance
of printing verbose messages by a reasonable factor:
(1) It removes a number of memory allocations that were done on each
verobse message
(2) It removes the need to strip the verbose magic out of the verbose
log messages before passing them to non-console log channels
(3) It now performs fewer iterations over lists when handling verbose
messages
Since verbose messages are now handled like other log messages (for the
most part), the JSON formatting of the messages works as well.
ASTERISK-25425
Change-Id: I21bf23f0a1e489b5102f8a035fe8871552ce4f96
At one point in time, it seemed like a good idea to use the Asterisk
channel name as the HEP correlation UUID. In particular, it felt like
this would be a useful identifier to tie PJSIP messages and RTCP
messages together, along with whatever other data we may eventually send
to Homer. This also had the benefit of keeping the correlation UUID
channel technology agnostic.
In practice, it isn't as useful as hoped, for two reasons:
1) The first INVITE request received doesn't have a channel. As a
result, there is always an 'odd message out', leading it to be
potentially uncorrelated in Homer.
2) Other systems sending capture packets (Kamailio) use the SIP Call-ID.
This causes RTCP information to be uncorrelated to the SIP message
traffic seen by those capture nodes.
In order to support both (in case someone is trying to use res_hep_rtcp
with a non-PJSIP channel), this patch adds a new option, uuid_type, with
two valid values - 'call-id' and 'channel'. The uuid_type option is used
by a module to determine the preferred UUID type. When available, that
source of a correlation UUID is used; when not, the more readily available
source is used.
For res_hep_pjsip:
- uuid_type = call-id: the module uses the SIP Call-ID header value
- uuid_type = channel: the module uses the channel name if available,
falling back to SIP Call-ID if not
For res_hep_rtcp:
- uuid_type = call-id: the module uses the SIP Call-ID header if the
channel type is PJSIP and we have a channel,
falling back to the Stasis event provided
channel name if not
- uuid_type = channel: the module uses the channel name
ASTERISK-25352 #close
Change-Id: Ide67e59a52d9c806e3cc0a797ea1a4b88a00122c
With the old SIP module we can use IP access controls per peer.
PJSIP module missing this feature.
This patch added next configuration Endpoint options:
"acl" - list of IP ACL section names in acl.conf
"deny" - List of IP addresses to deny access from
"permit" - List of IP addresses to permit access from
"contact_acl" - List of Contact ACL section names in acl.conf
"contact_deny" - List of Contact header addresses to deny
"contact_permit" - List of Contact header addresses to permit
This patch also better logging failed request:
add custom message instead of "No matching endpoint found"
add SIP method to logging
ASTERISK-25900
Change-Id: I456dea3909d929d413864fb347d28578415ebf02
This migrates res_pjsip_pubsub over to using the newly
introduce common datastores management API instead of using
its own implementations for both subscriptions and
publications.
As well the extension state data now provides a generic
datastores container instead of a subscription. This allows
the dialog-info+xml body generator to work for both
subscriptions and publications.
ASTERISK-25999 #close
Change-Id: I773f9e4f35092da0f653566736a8647e8cfebef1
This change introduces a common container based datastores
management API. This has been done in a few places across
the tree but this consolidates all of the logic into one
place in a generic fashion.
ASTERISK-25999
Change-Id: I72eb15941dcdbc2a37bb00a33ce00f8755bd336a
The pjsua and pjsystest apps are now built only if TEST_FRAMEWORK is set.
The python bindings are now built only if TEST_FRAMEWORK is set and a
python development package is installed.
libresample was also disabled.
ASTERISK-25993 #close
Reported-by: Joshua Colp
Change-Id: If4e91c503a02f113d5b71bc8b972081fa3ff6f03
With the old SIP module AMI sends PeerStatus event on every
successfully REGISTER requests, ie, on start registration,
update registration and stop registration.
With PJSIP AMI sends ContactStatus only when status is changed.
Regarding registration:
on start registration - Created
on stop registration - Removed
but on update registration nothing
This patch added contact.updated event.
ASTERISK-25904
Change-Id: I8fad8aae9305481469c38d2146e1ba3a56d3108f
If the Asterisk system name is set in asterisk.conf, it will be stored
into the "reg_server" field in the ps_contacts table to facilitate
multi-server setups.
ASTERISK-25931
Change-Id: Ia8f6bd2267809c78753b52bcf21835b9b59f4cb8
Create PUBLISH messages to update a third party when an extension state
changes because of either a device or presence state change.
A configuration example:
[exten-state-publisher]
type=outbound-publish
server_uri=sip:instance1@172.16.10.2
event=presence
; Optional regex for context filtering, if specified only extension state
; for contexts matching the regex will cause a PUBLISH to be sent.
@context=^users
; Optional regex for extension filtering, if specified only extension
; state for extensions matching the regex will cause a PUBLISH to be sent.
@exten=^[0-9]*
; Required body type for the PUBLISH message.
;
; Supported values are:
; application/pidf+xml
; application/xpidf+xml
; application/cpim-pidf+xml
; application/dialog-info+xml (Planned support but not yet)
@body=application/pidf+xml
The '@' extended variables are used because the implementation can't
extend the outbound publish type as it is provided by the outbound publish
module. That means you either have to use extended variables, or
implement some sort of custom extended variable thing in the outbound
publish module. Another option would be to refactor that stuff to have an
option which specifies the use of an alternate implementation's
configuration and then have that passed to the implementation. JColp
opted for the extended variables method originally.
ASTERISK-25972 #close
Change-Id: Ic0dab4022f5cf59302129483ed38398764ee3cca
When starting the extension state publishers, check if the requested
message body generator is available. If not available give error message
and skip starting that publisher.
* res_pjsip_pubsub.c: Create new API if type/subtype generator
registered.
* res_pjsip_exten_state.c: Use new body generator API for validation.
ASTERISK-25922
Change-Id: I4ad69200666e3cc909d4619e3c81042d7f9db25c
A feature of chan_sip that service providers relied upon was the ability to
identify by the Authorization username. This is most often used when customers
have a PBX that needs to register rather than identify by IP address. From my
own experiance, this is pretty common with small businesses who otherwise
don't need a static IP.
In this scenario, a register from the customer's PBX may succeed because From
will usually contain the PBXs account id but an INVITE will contain the caller
id. With nothing recognizable in From, the service provider's Asterisk can
never match to an endpoint and the INVITE just stays unauthorized.
The fixes:
A new value "auth_username" has been added to endpoint/identify_by that
will use the username and digest fields in the Authorization header
instead of username and domain in the the From header to match an endpoint,
or the To header to match an aor. This code as added to
res_pjsip_endpoint_identifier_user rather than creating a new module.
Although identify_by was always a comma-separated list, there was only
1 choice so order wasn't preserved. So to keep the order, a vector was added
to the end of ast_sip_endpoint. This is only used by res_pjsip_registrar
to find the aor. The res_pjsip_endpoint_identifier_* modules are called in
globals/endpoint_identifier_order.
Along the way, the logic in res_pjsip_registrar was corrected to match
most-specific to least-specific as res_pjsip_endpoint_identifier_user does.
The order is:
username@domain
username@domain_alias
username
Auth by username does present 1 problem however, the first INVITE won't have
an Authorization header so the distributor, not finding a match on anything,
sends a securty_alert. It still sends a 401 with a challenge so the next
INVITE will have the Authorization header and presumably succeed. As a result
though, that first security alert is actually a false alarm.
To address this, a new feature has been added to pjsip_distributor that keeps
track of unidentified requests and only sends the security alert if a
configurable number of unidentified requests come from the same IP in a
configurable amout of time. Those configuration options have been added to
the global config object. This feature is only used when auth_username
is enabled.
Finally, default_realm was added to the globals object to replace the hard
coded "asterisk" used when an endpoint is not yet identified.
The testsuite tests all pass but new tests are forthcoming for this new
feature.
ASTERISK-25835 #close
Reported-by: Ross Beer
Change-Id: I30ba62d208e6f63439600916fcd1c08a365ed69d
This patch added new global pjsip option 'disable_multi_domain'.
Disabling Multi Domain can improve Realtime performance by reducing
number of database requests.
ASTERISK-25930 #close
Change-Id: I2e7160f3aae68475d52742107949a799aa2c7dc7
* changes:
test_message.c: Wait longer in case dialplan also processes the test message.
Manager: Short circuit AMI message processing.
manager.c: Eliminate most RAII_VAR usage.
You cannot reference the passed in features struct after calling
ast_bridge_impart(). Even if the call fails.
Change-Id: I902b88ba0d5d39520e670fb635078a367268ea21
softmix_bridge_join() failed because of an allocation failure. To address
this, the softmix bridge technology now checks if the channel failed to
join softmix successfully. In addition, the bridge now begins the process
of kicking the channel out of the bridge so we don't have channels
partially in the bridge for very long.
* Fix the test_channel_feature_hooks.c unit tests. The test channel must
have a valid codec to join the simple_bridge technology. This patch makes
joining a bridge more strict by not allowing partially joined channels to
remain in the bridge.
Change-Id: I97e2ade6a2bcd1214f24fb839fda948825b61a2b
Improve AMI message processing performance if there are no consumers
listening for the messages. We now skip creating the AMI event message
text strings.
Change-Id: I7b22fc5ec4e500d00635c1a467aa8ea68a1bb2b3
An earlier patch blocked the ast_bridge_impart() call until the channel
either entered the target bridge or it failed. Unfortuantely, if the
target bridge is stasis and the imprted channel is not a stasis channel,
stasis bounces the channel out of the bridge to come back into the bridge
as a proper stasis channel. When the channel is bounced out, that
released the block on ast_bridge_impart() to continue. If the impart was
a result of a transfer, then it became a race to see if the swap channel
would get hung up before the imparted channel could come back into the
stasis bridge. If the imparted channel won then everything is fine. If
the swap channel gets hung up first then the transfer will fail because
the swap channel is leaving the bridge.
* Allow a chain of ast_bridge_impart()'s to happen before any are
unblocked to prevent the race condition described above. When the channel
finally joins the bridge or completely fails to join the bridge then the
ast_bridge_impart() instances are unblocked.
ASTERISK-25947
Reported by: Richard Mudgett
ASTERISK-24649
Reported by: John Bigelow
ASTERISK-24782
Reported by: John Bigelow
Change-Id: I8fef369171f295f580024ab4971e95c799d0dde1
There are several places that do scheduled tasks or periodic housecleaning,
each with its own implementation:
* res_pjsip_keepalive has a thread that sends keepalives.
* pjsip_distributor has a thread that cleans up expired unidentified requests.
* res_pjsip_registrar_expire has a thread that cleans up expired contacts.
* res_pjsip_pubsub uses ast_sched directly and then calls ast_sip_push_task.
* res_pjsip_sdp_rtp also uses ast_sched to send keepalives.
There are also places where we should be doing scheduled work but aren't.
A good example are the places we have sorcery observers to start registration
or qualify. These don't work when changes are made to a backend database
without a pjsip reload. We need to check periodically.
As a first step to solving these issues, a new ast_sip_sched facility has
been created.
ast_sip_sched wraps ast_sched but only uses ast_sched as a scheduled queue.
When a task is ready to run, ast_sip_task_pusk is called for it. This ensures
that the task is executed in a PJLIB registered thread and doesn't hold up the
ast_sched thread so it can immediately continue processing the queue. The
serializer used by ast_sip_sched is one of your choosing or a random one from
the res_pjsip pool if you don't choose one.
Another feature is the ability to automatically clean up the task_data when the
task expires (if ever). If it's an ao2 object, it will be dereferenced, if
it's a malloc'd object it will be freed. This is selectable when the task is
scheduled. Even if you choose to not auto dereference an ao2 task data object,
the scheduler itself maintains a reference to it while the task is under it's
control. This prevents the data from disappearing out from under the task.
There are two scheduling models.
AST_SIP_SCHED_TASK_PERIODIC specifies that the invocations of the task occur at
the specific interval. That is, every "interval" milliseconds, regardless of
how long the task takes. If the task takes longer than the interval, it will
be scheduled at the next available multiple of interval. For exmaple: If the
task has an interval of 60 secs and the task takes 70 secs (it better not),
the next invocation will happen at 120 seconds.
AST_SIP_SCHED_TASK_DELAY specifies that the next invocation of the task should
start "interval" milliseconds after the current invocation has finished.
Also, the same ast_sched facility for fixed or variable intervals exists. The
task's return code in conjunction with the AST_SIP_SCHED_TASK_FIXED or
AST_SIP_SCHED_TASK_VARIABLE flags controls the next invocation start time.
One res_pjsip.h housekeeping change was made. The pjsip header files were
added to the top. There have been a few cases lately where I've needed
res_pjsip.h just for ast_sip calls and had compiles fail spectacularly because
I didn't add the pjsip header files to my source even though I never referenced
any pjsip calls.
Finally, a few new convenience APIs were added to astobj2 to make things a
little easier in the scheduler. ao2_ref_and_lock() calls ao2_ref() and
ao2_lock() in one go. ao2_unlock_and_unref() does the reverse. A few macros
were also copied from res_phoneprov because I got tired of having to duplicate
the same hash, sort and compare functions over and over again. The
AO2_STRING_FIELD_(HASH|SORT|CMP)_FN macros will insert functions suitable for
aor_container_alloc into your source.
This facility can be used immediately for the situations where we already have
a thread that wakes up periodically or do some scheduled work. For the
registration and qualify issues, additional sorcery and schema changes would
need to be made so that we can easily detect changed objects on a periodic
basis without having to pull the entire database back to check. I'm thinking
of a last-updated timestamp on the rows but more on this later.
Change-Id: I7af6ad2b2d896ea68e478aa1ae201d6dd016ba1c
In 13, the new ast_string_field_header structure had to be dynamically
allocated and assigned to a pointer in ast_string_field_mgr to preserve ABI
compatability. In master, it can be converted to being a structure-in-place in
ast_string_field_mgr to eliminate the extra alloc and free calls.
Change-Id: Ia97c5345eec68717a15dc16fe2e6746ff2a926f4
Contact expiration can occur in several places: res_pjsip_registrar,
res_pjsip_registrar_expire, and automatically when anyone calls
ast_sip_location_retrieve_aor_contact. At the same time, res_pjsip_registrar
may also be attempting to renew or add a contact. Since none of this was locked
it was possible for one thread to be renewing a contact and another thread to
expire it immediately because it was working off of stale data. This was the
casue of intermittent registration/inbound/nominal/multiple_contacts test
failures.
Now, the new named lock functionality is used to lock the aor during contact
expire and add operations and res_pjsip_registrar_expire now checks the
expiration with the lock held before deleting the contact.
ASTERISK-25885 #close
Reported-by: Josh Colp
Change-Id: I83d413c46a47796f3ab052ca3b349f21cca47059
Locking some objects like sorcery objects can be tricky because the underlying
ao2 object may not be the same for all callers. For instance, two threads that
call ast_sorcery_retrieve_by_id on the same aor name might actually get 2
different ao2 objects if the underlying wizard had to rehydrate the aor from a
database. Locking one ao2 object doesn't have any effect on the other even if
those objects had locks in the first place.
Named locks allow access control by keyspace and key strings. Now an "aor"
named "1000" can be locked and any other thread attempting to lock "aor" "1000"
will wait regardless of whether the underlying ao2 object is the same or not.
Mutex and rwlocks are supported.
This capability will initially be used to lock an aor when multiple threads may
be attempting to prune expired contacts from it.
Change-Id: If258c0b7f92b02d07243ce70e535821a1ea7fb45
This eliminates some casts that I made a note saying v10 and above
would no longer need them.
Better late than never :)
Change-Id: I346cdb3032b6478ceb40eb6fe732978b54035572
This adds a new ARI method that allows for you to dial a channel that
you previously created in ARI.
By combining this with the create method for channels, it allows for a
workflow where a channel can be created, manipulated, and then dialed.
The channel is under control of the ARI application during all stages of
the Dial and can even be manipulated based on channel state changes
observed within an ARI application.
The overarching goal for this is to eventually be able to add a dialed
channel to a Stasis bridge earlier than the "Up" state. However, at the
moment more work is needed in the Dial and Bridge APIs in order to
facilitate that.
ASTERISK-25889 #close
Change-Id: Ic6c399c791e66c4aa52454222fe4f8b02483a205
This change introduces the concept of autohints. These are hints
which are created as a result of device state changes occurring within
the core. When this happens a hint will be created (if it does not
exist already) using the device name as the extension.
For example if a device state change is received for "PJSIP/bob"
and autohints are enabled on a context then a hint will exist in
that context for "bob" with a device of "PJSIP/bob".
For virtual or custom device states the name after the type will
be used. For example if the device state of "Custom:bob" changes
then a hint will exist in that context for "bob" with a device of
"Custom:bob".
This functionality can be enabled in extensions.conf by placing
"autohints=yes" in a context.
ASTERISK-25881 #close
Change-Id: I7e444c7da41b7b7d33374420fec658beeb18584e
The Dial API takes responsiblity for creating an outbound channel when
calling ast_dial_append(). This commit adds a new function,
ast_dial_append_channel(), which allows us to create the channel outside
the Dial API and then to append the channel to the ast_dial structure.
This is useful for situations where the channel's creation and dialing
are distinct operations. Upcoming ARI early bridge work will illustrate
its usage.
ASTERISK-25889
Change-Id: Id8179f64f8f99132f80dead8d5db2030fd2c0509
String fields are great, except that you can't add new ones without breaking
ABI compatibility because it shifts down everything else in the structure.
The only alternative is to add your own char * field to the end of the
structure and manage the memory yourself which isn't ideal, especially since
you then can't use the OPT_STRINGFIELD_T type.
Background:
The reason string fields had to be declared inside the
AST_DECLARE_STRING_FIELDS block was to facilitate iteration over all declared
fields for initialization, compare and copy. Since AST_DECLARE_STRING_FIELDS
declared the pool, then the fields, then the manager, you could use the offsets
of the pool and manager and iterate over the sequential addresses in between to
access the fields. The actual pool, field allocation and field set operations
don't actually care where the field is. It's just iteration over the fields
that was the problem.
Solution: Extended String Fields
An extended string field is one that is declared outside the
AST_DECLARE_STRING_FIELDS block but still (anywhere) inside the parent
structure. Other than using AST_STRING_FIELD_EXTENDED instead of
AST_STRING_FIELD, it looks the same as other string fields. It's storage comes
from the pool and it participates in string field compare and copy operations
peformed on the parent structure. It's also a valid target for the
OPT_STRINGFIELD_T aco option type.
Implementation:
To keep track of the extended fields and make sure that ABI isn't broken, the
existing embedded_pool pointer in the manager structure was repurposed to be a
pointer to a separate header structure that contains the embedded_pool pointer
plus a vector of fields. The length of the manager structure didn't change and
the embedded_pool pointer isn't used in the macros, only the stringfields C
code. A side benefit of this is that changing the header structure in the
future won't break ABI.
ast_string_fields_init initializes the normal string fields and appends them to
the vector, and subsequent calls to ast_string_field_init_extended initialize
and append the extended fields. Cleanup, ast_string_fields_cmp, and
ast_string_fields_copy can now work on the vector instead of sequentially
traversing the addresses between the pool and manager.
The total size of a structure using string fields didn't change, whether using
extended fields or not, nor have the offsets of any structure members, either
inside the original block or outside. Adding an extended field to the end of a
structure is the same as adding a char *.
Details:
The stringfield C code was pulled out from utils.c and into stringfields.c.
It just made sense.
Additional work was done in ast_string_field_init and
ast_calloc_with_stringfields to handle the allocation of the new header
structure and the vector, and the associated cleanup. In the process some
additional NULL pointer checking was added.
A lot of work was done in stringfields.h since the logic for compare and copy
is there. Documentation was added as well as somne additional NULL checking.
The ability to call ast_calloc_with_stringfields with a number of structures
greater than 1 never really worked. Well, the calloc worked but there was no
way to access the additional structures or clean them up. It was agreed that
there was no use case for requesting more than 1 structure so an ast_assert
was added to prevent it and the iteration code removed.
Testing:
The stringfield unit tests were updated to test both normal and extended
fields. Tests for ast_string_field_ptr_set_by_fields and
ast_calloc_with_stringfields were also added.
As an ABI test, 13 was compiled from git and the res_pjsip_* modules, except
res_pjsip itself, saved off. The patch was then added and a full compile and
install was performed. Then the older res_pjsip_* moduled were copied over the
installed versions so res_pjsip was new and the rest were old. No issues.
contact->aor, which is a char * at the end of contact, was then changed to an
extended string field and a recompile and reinstall was performed, again
leaving stock versions of the the res_pjsip_* modules. Again, no issues with
the res_pjsip_* modules using the old stringfield implementation and with
contact->aor as a char *, and res_pjsip itself using the new stringfield
implementation and contact->aor being an extended string field.
Finally, several existing string fields were converted to extended string
fields to test OPT_STRINGFIELD_T. Again, no issues.
Change-Id: I235db338c5b178f5a13b7946afbaa5d4a0f91d61
The stasis_app_playback and stasis_app_recording structs need to have a
struct stasis_app_control ref. Other threads can get a reference to the
playback and recording structs from their respective global container.
These other threads can then use the control pointer they contain after
the control struct has gone.
* Add control ref to stasis_app_playback and stasis_app_recording structs.
With the refs added, the control command queue can now have a circular
control reference which will cause the control struct to never get
released if the control's command queue is not flushed when the channel
leaves the Stasis application. Also the command queue needs better
protection from adding commands if the control->is_done flag is set.
* Flush the control command queue on exit.
ASTERISK-25882 #close
Change-Id: I3cf1fb59cbe6f50f20d9e35a2c07ac07d7f4320d
res_pjsip_mwi was missing the chan_sip "vmexten" functionality which adds
the Message-Account header to the MWI NOTIFY. Also, specifying mailboxes
on endpoints for unsolicited mwi and on aors for subscriptions required
that the admin know in advance which the client wanted. If you specified
mailboxes on the endpoint, subscriptions were rejected even if you also
specified mailboxes on the aor.
Voicemail extension:
* Added a global default_voicemail_extension which defaults to "".
* Added voicemail_extension to both endpoint and aor.
* Added ast_sip_subscription_get_dialog for support.
* Added ast_sip_subscription_get_sip_uri for support.
When an unsolicited NOTIFY is constructed, the From header is parsed, the
voicemail extension from the endpoint is substituted for the user, and the
result placed in the Message-Account field in the body.
When a subscribed NOTIFY is constructed, the subscription dialog local uri
is parsed, the voicemail_extension from the aor (looked up from the
subscription resource name) is substituted for the user, and the result
placed in the Message-Account field in the body.
If no voicemail extension was defined, the Message-Account field is not added
to the NOTIFY body.
mwi_subscribe_replaces_unsolicited:
* Added mwi_subscribe_replaces_unsolicited to endpoint.
The previous behavior was to reject a subscribe if a previous internal
subscription for unsolicited MWI was found for the mailbox. That remains the
default. However, if there are mailboxes also set on the aor and the client
subscribes and mwi_subscribe_replaces_unsolicited is set, the existing internal
subscription is removed and replaced with the external subscription. This
allows an admin to configure mailboxes on both the endpoint and aor and allows
the client to select which to use.
ASTERISK-25865 #close
Reported-by: Ross Beer
Change-Id: Ic15a9415091760539c7134a5ba3dc4a6a1217cea
Asterisk uses separate UDP ports for RTP and RTCP traffic and RFC 5764
explicitly states:
There MUST be a separate DTLS-SRTP session for each distinct pair of
source and destination ports used by a media session
This means RTP keying material cannot be used for DTLS RTCP, which was
the reason why RTCP encryption would fail.
ASTERISK-25642
Change-Id: I7e8779d8b63e371088081bb113131361b2847e3a
rxcount, txcount, rxoctetcount and txoctetcount weren't being calculated
for bridged streams because the calulations were being done after the
bridged short-circuit. Actually, rxoctetcount wasn't ever being calculated.
Moved the calculations so they occur for all valid received packets and
all transmitted packets. Also added rxoctetcount and txoctetcount to
ast_rtp_instance_stat.
Change-Id: I08fb06011a82d38c3b4068867a615068fbe59cbb
There were a number of places in the res_pjsip stack that were getting
all endpoints or all aors, and then filtering them locally.
A good example is pjsip_options which, on startup, retrieves all
endpoints, then the aors for those endpoints, then tests the aors to see
if the qualify_frequency is > 0. One issue was that it never did
anything with the endpoints other than retrieve the aors so we probably
could have skipped a step and just retrieved all aors. But nevermind.
This worked reasonably well with local config files but with a realtime
backend and thousands of objects, this was a nightmare. The issue
really boiled down to the fact that while realtime supports predicates
that are passed to the database engine, the non-realtime sorcery
backends didn't.
They do now.
The realtime engines have a scheme for doing simple comparisons. They
take in an ast_variable (or list) for matching, and the name of each
variable can contain an operator. For instance, a name of
"qualify_frequency >" and a value of "0" would create a SQL predicate
that looks like "where qualify_frequency > '0'". If there's no operator
after the name, the engines add an '=' so a simple name of
"qualify_frequency" and a value of "10" would return exact matches.
The non-realtime backends decide whether to include an object in a
result set by calling ast_sorcery_changeset_create on every object in
the internal container. However, ast_sorcery_changeset_create only does
exact string matches though so a name of "qualify_frequency >" and a
value of "0" returns nothing because the literal "qualify_frequency >"
doesn't match any name in the objset set.
So, the real task was to create a generic string matcher that can take a
left value, operator and a right value and perform the match. To that
end, strings.c has a new ast_strings_match(left, operator, right)
function. Left and right are the strings to operate on and the operator
can be a string containing any of the following: = (or NULL or ""), !=,
>, >=, <, <=, like or regex. If the operator is like or regex, the
right string should be a %-pattern or a regex expression. If both left
and right can be converted to float, then a numeric comparison is
performed, otherwise a string comparison is performed.
To use this new function on ast_variables, 2 new functions were added to
config.c. One that compares 2 ast_variables, and one that compares 2
ast_variable lists. The former is useful when you want to compare 2
ast_variables that happen to be in a list but don't want to traverse the
list. The latter will traverse the right list and return true if all
the variables in it match the left list.
Now, the backends' fields_cmp functions call ast_variable_lists_match
instead of ast_sorcery_changeset_create and they can now process the
same syntax as the realtime engines. The realtime backend just passes
the variable list unaltered to the engine. The only gotcha is that
there's no common realtime engine support for regex so that's been noted
in the api docs for ast_sorcery_retrieve_by_fields.
Only one more change to sorcery was done... A new config flag
"allow_unqualified_fetch" was added to reg_sorcery_realtime.
"no": ignore fetches if no predicate fields were supplied.
"error": same as no but emit an error. (good for testing)
"yes": allow (the default);
"warn": allow but emit a warning. (good for testing)
Now on to res_pjsip...
pjsip_options was modified to retrieve aors with qualify_frequency > 0
rather than all endpoints then all aors. Not only was this a big
improvement in realtime retrieval but even for config files there's an
improvement because we're not going through endpoints anymore.
res_pjsip_mwi was modified to retieve only endpoints with something in
the mailboxes field instead of all endpoints then testing mailboxes.
res_pjsip_registrar_expire was completely refactored. It was retrieving
all contacts then setting up scheduler entries to check for expiration.
Now, it's a single thread (like keepalive) that periodically retrieves
only contacts whose expiration time is < now and deletes them. A new
contact_expiration_check_interval was added to global with a default of
30 seconds.
Ross Beer reports that with this patch, his Asterisk startup time dropped
from around an hour to under 30 seconds.
There are still objects that can't be filtered at the database like
identifies, transports, and registrations. These are not going to be
anywhere near as numerous as endpoints, aors, auths, contacts however.
Back to allow_unqualified_fetch. If this is set to yes and you have a
very large number of objects in the database, the pjsip CLI commands
will attempt to retrive ALL of them if not qualified with a LIKE.
Worse, if you type "pjsip show endpoint <tab>" guess what's going to
happen? :) Having a cache helps but all the objects will have to be
retrieved at least once to fill the cache. Setting
allow_unqualified_fetch=no prevents the mass retrieve and should be used
on endpoints, auths, aors, and contacts. It should NOT be used for
identifies, registrations and transports since these MUST be
retrieved in bulk.
Example sorcery.conf:
[res_pjsip]
endpoint=config,pjsip.conf,criteria=type=endpoint
endpoint=realtime,ps_endpoints,allow_unqualified_fetch=error
ASTERISK-25826 #close
Reported-by: Ross Beer
Tested-by: Ross Beer
Change-Id: Id2691e447db90892890036e663aaf907b2dc1c67
During stress testing, we have frequently seen crashes occur because a
CLI or AMI command attempts to access information that is in the process
of being destroyed.
When addressing how to fix this issue, we initially considered fixing
individual crashes we observed. However, the changes required to fix
those problems would introduce considerable overhead to the nominal
case. This is not reasonable in order to prevent a crash from occurring
while Asterisk is already shutting down.
Instead, this change makes it so AMI and CLI commands cannot be executed
if Asterisk is being shut down. For AMI, this is absolute. For CLI,
though, certain commands can be registered so that they may be run
during Asterisk shutdown.
ASTERISK-25825 #close
Change-Id: I8887e215ac352fadf7f4c1e082da9089b1421990
Older versions of PJSIP do not have the proto field on the TLS transport
setting structure. This change adds a configure check so even if it is
not present we will still be able to build.
Change-Id: Ibf3f47befb91ed1b8194bf63888baa6fee05aba9
Channel masquerading had a conflict with autochannel locking.
When locking autochannel->channel, the channel is fetched from the
autochannel and then locked. During the fetch, the autochannel -- which
has no locks itself -- can be modified by someone who owns the channel
lock. That means that the value of autochan->channel cannot be trusted
until you hold the lock.
In practice, this caused problems with Local channels getting
masqueraded away while the ChanSpy attempted to get info from that
channel. The old channel which was about to get removed got locked, but
the new (replaced) channel got unlocked (no-op). Because the replaced
channel was now locked (and would never get unlocked), it couldn't get
removed from the channel list in a timely manner, and would now cause
deadlocks when iterating over the channel list.
This change checks the autochannel after locking the channel for changes
to the autochannel. If the channel had been changed, the lock is
reobtained on the new channel.
In theory it seems possible that after this fix, the lock attempt on the
old (wrong) channel can be on an already destroyed lock, maybe causing
a crash. But that hasn't been observed in the wild and is harder induce
than the current deadlock.
Thanks go to Filip Frank for suggesting a fix similar to this and
especially to IRC user hexanol for pointing out why this deadlock was
possible and testing this fix. And to Richard for catching my rookie
while loop mistake ;)
ASTERISK-25321 #close
Change-Id: I293ae0014e531cd0e675c3f02d1d118a98683def
Refactor and created function ast_cli_print_timestr_fromseconds to print
seconds formatted: year(s) week(s) day(s) hour(s) second(s)
This function now is used in addons/cdr_mysql.c,cdr_pgsql.c, main/cli.c,
res_config_ldap.c, res_config_pgsql.c.
Change-Id: Ibeb8634102cd11d3f8623398b279cb731bcde36c
Per RFC3325, the 'From' header is now anonymized on outgoing calls when
caller id presentation is prohibited.
TID = trust_id_outbound
PRO = Set(CALLERID(pres)=prohib)
USR = endpoint/from_user
DOM = endpoint/from_domain
PAI = YES(privacy=off), NO(not sent), PRI(privacy=full) (assumes send_pai=yes)
Conditions |Result
--------------------|----------------------------------------------------
TID PRO USR DOM |PAI FROM
--------------------|----------------------------------------------------
Y Y abc def.ghi |PRI "Anonymous" <sip:abc@def.ghi>
Y Y abc |PRI "Anonymous" <sip:abc@anonymous.invalid>
Y Y def.ghi |PRI "Anonymous" <sip:anonymous@def.ghi>
Y Y |PRI "Anonymous" <sip:anonymous@anonymous.invalid>
Y N abc def.ghi |YES <sip:abc@def.ghi>
Y N abc |YES <sip:abc@<ip_address>>
Y N def.ghi |YES "Caller Name" <sip:<caller_exten>@def.ghi>
Y N |YES "Caller Name" <sip:<caller_exten>@<ip_address>>
N Y abc def.ghi |NO "Anonymous" <sip:abc@def.ghi>
N Y abc |NO "Anonymous" <sip:abc@anonymous.invalid>
N Y def.ghi |NO "Anonymous" <sip:anonymous@def.ghi>
N Y |NO "Anonymous" <sip:anonymous@anonymous.invalid>
N N abc def.ghi |YES <sip:abc@def.ghi>
N N abc |YES <sip:abc@<ip_address>>
N N def.ghi |YES "Caller Name" <sip:<caller_exten>@def.ghi>
N N |YES "Caller Name" <sip:<caller_exten>@<ip_address>>
ASTERISK-25791 #close
Reported-by: Anthony Messina
Change-Id: I2c82a5ca1413c2c00fb62ea95b0ae8e97af54dc9
It's possible for the transferer channel to get hung up early during the
attended transfer process. For instance, a phone may send a "bye" immediately
upon receiving a sip notify that contains a sip frag 100 (I'm looking at you
Jitsi). When this occurs a race begins between the transferer being hung up
and completion of the transfer code.
If the channel hangs up too early during a transfer involving stasis bridging
for instance, then when the created local channel goes to look up its swap
channel (and associated datastore) it can't find it (since it is no longer in
the bridge) thus it fails to enter the stasis application. Consequently, the
created local channel(s) hang up as well. If the timing is just right then the
bridging code attempts to add the message link with missing local channel(s).
Hence the crash.
Unfortunately, there is no great way to solve the problem of the unexpected
"bye". While we can't guarantee we won't receive an early hangup, and in this
case still fail to enter the stasis application, we can make it so asterisk
does not crash.
This patch does just that by locking the local channel structure, checking
that the local channel's peer has not been lost, and then continuing. This
keeps the local channel's peer from being ripped out from underneath it by
the local/unreal hangup code while attempting to set the stasis message link.
ASTERISK-25771
Change-Id: Ie6d6061e34c7c95f07116fffac9a09e5d225c880
Background here:
http://lists.digium.com/pipermail/asterisk-dev/2016-January/075266.html
From CHANGES:
* To help insure that Asterisk is compiled and run with the same known
version of pjproject, a new option (--with-pjproject-bundled) has been
added to ./configure. When specified, the version of pjproject specified
in third-party/versions.mak will be downloaded and configured. When you
make Asterisk, the build process will also automatically build pjproject
and Asterisk will be statically linked to it. Once a particular version
of pjproject is configured and built, it won't be configured or built
again unless you run a 'make distclean'.
To facilitate testing, when 'make install' is run, the pjsua and pjsystest
utilities and the pjproject python bindings will be installed in
ASTDATADIR/third-party/pjproject.
The default behavior remains building with the shared pjproject
installation, if any.
Building:
All you have to do is include the --with-pjproject-bundled option on
the ./configure command line (and remove any existing --with-pjproject
option if specified). Everything else is automatic.
Behind the scenes:
The top-level Makefile was modified to include 'third-party' in the
list of MOD_SUBDIRS.
The third-party directory was created to contain any third party
packages that may be needed in the future. Its Makefile automatically
iterates over any subdirectories passing on targets.
The third-party/pjproject directory was created to house the pjproject
source distribution. Its Makefile contains targets to download, patch
configure, generate dependencies, compile libs, apps and python bindings,
sanitized build.mak and generate a symbols list.
When bootstrap.sh is run, it automatically includes the configure.m4
file in third-party/pjproject. This file has a macro to download and
conifgure pjproject and get and set PJPROJECT_INCLUDE, PJPROJECT_DIR
and PJPROJECT_BUNDLED. It also tests for the capabilities like
PJ_TRANSACTION_GRP_LOCK by parsing preprocessor output as opposed to
trying to compile. Of course, bootstrap.sh is only run once and the
configure file is incldued in the patch.
When configure is run with the new options, the macro in configure.m4
triggers the download, patch, conifgure and tests. No compilation is
performed at this time. The downloaded tarball is cached in /tmp so
it doesn't get downloaded again on a distclean.
When make is run in the top-level Asterisk source directory, it will
automatically descend all the subdirectories in third_party just as it
does for addons, apps, etc. The top-level Makefile makes sure that
the 'third-party' is built before 'main' so that dependencies from the
other directories are built first.
When main does build, a new shared library (libasteriskpj) is created that
links statically to the pjproject .a files and exports all their symbols.
The asterisk binary links to that, just as it does with libasteriskssl.
When Asterisk is installed, the pjsua and pjsystest apps, and the pjproject
python bindings are installed in ASTDATADIR/third-party/pjproject. This
will facilitate testing, including running the testsuite which will be
updated to check that directory for the pjsua module ahead of the system
python library.
Modules should continue to depend on pjproject if they use pjproject APIs
directly. They should not care about the implementation. No changes to any
res_pjsip modules were made.
Change-Id: Ia7a60c28c2e9ba9537c5570f933c1ebcb20a3103
The channel is now going to get T.38 terminated when it leaves the
bridging system and the bridged peers are going to get T.38 terminated as
well.
ASTERISK-25582
Change-Id: I77a9205979910210e3068e1ddff400dbf35c4ca7
Local channel optimization could cause DTMF digits to be duplicated.
Pending DTMF end events would be posted to a bridge when the local channel
optimizes out and is replaced by the channel further down the chain. When
the real digit ends, the channel would get another DTMF end posted to the
bridge.
A -- LocalA;1/n -- LocalA;2/n -- LocalB;1 -- LocalB;2 -- B
1) LocalA has the /n flag to prevent optimization.
2) B is sending DTMF to A through the local channel chain.
3) When LocalB optimizes out it can move B to the position of LocalB;1
4) Without this patch, when B swaps with LocalB;1 then LocalB;1 would
settle an owed DTMF end to the bridge toward LocalA;2.
5) When B finally ends its DTMF it sends the DTMF end down the chain.
6) Without this patch, A would hear the DTMF digit end when LocalB
optimizes out and when B ends the original digit.
ASTERISK-25582
Change-Id: I1bbd28b8b399c0fb54985a5747f330a4cd2aa251
The 'reload' mechanism actually involves closing the underlying
socket and calling the appropriate udp, tcp or tls start functions
again. Only outbound_registration, pubsub and session needed work
to reset the transport before sending requests to insure that the
pjsip transport didn't get pulled out from under them.
In my testing, no calls were dropped when a transport was changed
for any of the 3 transport types even if ip addresses or ports were
changed. To be on the safe side however, a new transport option was
added (allow_reload) which defaults to 'no'. Unless it's explicitly
set to 'yes' for a transport, changes to that transport will be ignored
on a reload of res_pjsip. This should preserve the current behavior.
Change-Id: I5e759850e25958117d4c02f62ceb7244d7ec9edf
Pjproject has deprecated pjsip_dlg_create_uas in 2.5 and replaced it with
pjsip_dlg_create_uas_and_inc_lock which, as the name implies, automatically
increments the lock on the returned dialog. To account for this, configure.ac
now detects the presence of pjsip_dlg_create_uas_and_inc_lock and res_pjsip.c
has an #ifdef HAVE_PJSIP_DLG_CREATE_UAS_AND_INC_LOCK to decide whether to use
the original call or the new one. If the new one was used, the ref count is
decremented before returning.
ASTERISK-25751 #close
Reported-by Josh Colp
Change-Id: I1be776b94761df03bd0693bc7795a75682615ca8
FD_SET contains a conditional statement to protect against buffer
overruns. The statement was overly complicated and prevented use
of the last array element of ast_fdset. We now just verify the fd
is less than ast_FDMAX.
Change-Id: I41895c0b497b052aef5bf49d75c817c48b326f40
Attempting to load a transport from realtime was forcing asterisk into an
infinite recursion loop. The first thing transport_apply did was to do a
sorcery retrieve by id for an existing transport of the same name. For files,
this just returns the previous object from res_sorcery_config's internal
container, if any. For realtime, the res_sourcery_realtime driver looks in the
database and finds the existing row but now it has to rehydrate it into a
sorcery object which means calling... transport_apply. And so it goes.
The main issue with loading from realtime (apart from the loop) was that
transport stores structures and pointers directly in the ast_sip_transport
structure instead of the separate ast_transport_state structure. This patch
separates those items into the ast_sip_transport_state structure. The pattern
is roughly the same as res_pjsip_outbound_registration.
Although all current usages of ast_sip_transport and ast_sip_transport_state
were modified to use the new ast_sip_get_transport_state API, the original
items are left in ast_sip_transport and kept updated to maintain ABI
compatability for third-party modules. They are marked as deprecated and
noted that they're now in ast_sip_transport_state.
ASTERISK-25606 #close
Reported-by: Martin Moučka
Change-Id: Ic7a836ea8e786e8def51fe3f8cce855ea54f5f19
The SSL_OP_NO_TLSv1_1 and SSL_OP_NO_TLSv1_2 defines did not exist prior
to OpenSSL version 1.0.1. A recent commit attempts to, by default, set
these options, which can cause problems on systems with older OpenSSL
installations.
This commit adds a configure script check for those defines and will not
attempt to make use of those if they do not exist. We will print a
warning urging the user to upgrade their OpenSSL installation if those
defines are not present.
Change-Id: I6a2eb9a43fd0738b404d8f6f2cf4b5c22d9d752d
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
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
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
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
The xferfailsound was read from the channel at the beginning of the transfer,
and that value is "cached" for the duration of the transfer. Therefore, changing
the xferfailsound on the channel using the FEATURE() dialplan function does
nothing once the transfer is under way.
This makes it so the transfer code instead gets the xferfailsound configuration
options from the channel when it is actually going to be used.
This patch also fixes a potential memory leak of the props object as well as
making sure the condition variable gets initialized before being destroyed.
ASTERISK-25696 #close
Change-Id: Ic726b0f54ef588bd9c9c67f4b0e4d787934f85e4
Added new global option (regcontext) to pjsip. When set, Asterisk will
dynamically create and destroy a NoOp priority 1 extension
for a given endpoint who registers or unregisters with us.
ASTERISK-25670 #close
Reported-by: Daniel Journo
Change-Id: Ib1530c5b45340625805c057f8ff1fb240a43ea62
* changes:
Sorcery: Create human friendly serializer names.
Stasis: Create human friendly taskprocessor/serializer names.
taskprocessor.c: New API for human friendly taskprocessor names.
taskprocessor.c: Sort CLI "core show taskprocessors" output.
On a system with multiple ip addresses in the same subnet, if a
transport is bound to a specific ip address and endpoint/media_address
is set, the SIP/SDP will have the correct address in all fields but
the rtp stream MAY still originate from one of the other ip addresses,
most probably the "primary" ip address. This happens because
res_pjsip_sdp_rtp/create_rtp always calls ast_instance_new with
the "all" ip address (0.0.0.0 or ::).
The new option causes res_pjsip_sdp_rtp/create_rtp to call
ast_rtp_instance_new with the endpoint's media_address (if specified)
instead of the "all" address. This causes the packets to originate from
the specified address.
ASTERISK-25632
ASTERISK-25637
Reported-by: Olivier Krief
Reported-by: Dan Journo
Change-Id: I3dfaa079e54ba7fb7c4fd1f5f7bd9509bbf8bd88
* Add new API call to get a sequence number for use in human friendly
taskprocessor names.
* Add new API call to create a taskprocessor name in a given buffer and
append a sequence number.
Change-Id: Iac458f05b45232315ed64aa31b1df05b875537a9
Renamed global declaration:tv to dummy_tv_var_for_types,
which would oltherwise cause 'shadow' warnings when 'tv'
was declared as a local variable elsewhere.
Added comment to note that dummy_tv_var_for_types is never
really exported and only used as a place holder.
ASTERISK-25627 #close
Change-Id: I9a6e17995006584f3627efe8988e3f8aa0f5dc28
This is the sixth patch in a series meant to reduce the bulk of pbx.c.
This moves hangup handler management functions to their own source.
Change-Id: Ib25a75aa57fc7d5c4294479e5cc46775912fb104
This is the sixth patch in a series meant to reduce the bulk of pbx.c.
This moves dialplan application management functions to their own source.
Change-Id: I444c10fb90a3cdf9f3047605d6a8aad49c22c44c
This is the fifth patch in a series meant to reduce the bulk of pbx.c.
This moves ast_switch functions to their own source.
Change-Id: Ic2592a18a5c4d8a3c2dcf9786c9a6f650a8c628e