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
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
ChanSpy was creating its audiohook with the flags AST_AUDIOHOOK_TRIGGER_SYNC
and AST_AUDIOHOOK_SMALL_QUEUE, which caused audio frames to be lost when
queues grow too large or when read and write queues go out of sync.
Now these flags are set conditionally:
- AST_AUDIOHOOK_TRIGGER_SYNC is not set if the option "o" is set
- a new option "l" is created: if set, AST_AUDIOHOOK_SMALL_QUEUE will not
be set on the audiohook
ASTERISK-25866
Change-Id: I9c7652f41d9fa72c8691e4e70ec4fd16b047a4dd
The first available transport of the appropriate type is used now.
This patch adds new config option 'transport' for outbound-publish.
If transport is set then outbound PUBLISH requests will use this transport.
ASTERISK-25901 #close
Change-Id: Ib389130489b70e36795b0003fa5fd386e2680151
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 adds a new ARI method to the channels resource that allows for the
creation of a new channel. The channel is created and then placed into
the specified Stasis application.
This is different from the existing originate method that creates a
channel, dials it, and then places the answered channel into the
dialplan or a Stasis application. This method does not attempt to call
the channel at all. Dialing is left as a later step after channel
creation. This allows for pre-dialing channel manipulation if desired.
ASTERISK-25889
Change-Id: I3c96a0aba914b08e39f6256371a5bd4c92cbded8
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
Added the ability to show channel statistics to chan_pjsip (cli_functions.c)
Moved the existing 'pjsip show channel(s)' functionality from
pjsip_configuration to cli_functions.c. The stats needed chan_pjsip's
private header so it made sense to move the existing channel commands as well.
Now using stasis_cache_dump to get the channel snapshots rather than retrieving
all endpoints, then getting each one's channel snapshots. Much more efficient.
Change-Id: I03b114522126d27434030b285bf6d531ddd79869
Blind transfers to a recognized parking extension need to use the parker's
channel variable values to create the dynamic parking lot. This is
because there is always only one parker while the parkee may actually be a
multi-party bridge. A multi-party bridge can never supply the needed
channel variables to create the dynamic parking lot. In the multi-party
bridge blind transfer scenario, the parker's CHANNEL(parkinglot) value and
channel variables are inherited by the local channel used to park the
bridge.
* In park_common_setup(), make use the parker instead of the parkee to
supply the dynamic parking lot channel variable values. In all but one
case, the parkee is the same as the parker. However, in the recognized
parking extension blind transfer scenario for a two party bridge they are
different channels. For consistency, we need to use the parker channel.
* In park_local_transfer(), pass the CHANNEL(parkinglot) value to the
local channel when blind transferring a multi-party bridge to a recognized
parking extension.
* When a local channel starts a call, the Local;2 side needs to inherit
the CHANNEL(parkinglot) value from Local;1.
The DTMF one-touch parking case wasn't even trying to create dynamic
parking lots before it aborted the attempt.
* In parking_park_call(), add missing code to create a dynamic parking
lot.
A DTMF bridge hook is documented as returning -1 to remove the hook.
Though the hook caller is really coded to accept non-zero. See the
ast_bridge_hook_callback typedef.
* In feature_park_call(), don't remove the DTMF one-touch parking hook
because of an error.
ASTERISK-24605 #close
Reported by: Philip Correia
Patches:
call_park.patch (license #6672) patch uploaded by Philip Correia
Change-Id: I221d3a8fcc181877a1158d17004474d35d8016c9
This patch allows applications/APIs that access media through the core file
APIs to play media in the media cache. Prior to determining if a 'filename'
exists, the filename is passed to the media cache's retrieve API call. If
that call succeeds, the local file specified passed back by the API is
opened for streaming. When used in this fashion, the 'filename' is actually
a URI that the media cache process and understand.
ASTERISK-25654 #close
Change-Id: I73b6e2e90c3e91b8500581c45cdf9c0dc785f5f0
This patch adds a bucket backend for the core media cache that interfaces to a
remote HTTP server. When a media item is requested in the cache, the cache will
query its bucket backends to see if they can provide the media item. If that
media item has a scheme of HTTP or HTTPS, this backend will be invoked.
The backend provides callbacks for the following:
* create - this will always retrieve the URI specified by the provided
bucket_file, and store it in the file specified by the object.
* retrieve - this will pull the URI specified and store it in a temporary
file. It is then up to the media cache to move/rename this file
if desired.
* delete - destroys the file associated with the bucket_file.
* stale - if the bucket_file has expired, based on received HTTP headers from
the remote server, or if the ETag on the server no longer matches
the ETag stored on the bucket_file, the resource is determined to be
stale.
Note that the backend respects the ETag, Expires, and Cache-Control headers
provided by the HTTP server it is querying.
ASTERISK-25654
Change-Id: Ie201c2b34cafc0c90a7ee18d7c8359afaccc5250
This patch adds a write option to the CURL dialplan function, allowing it to
CURL files and store them locally. The value 'written' to the CURL URL
specifies the location on disk to store the file. As an example:
same => n,Set(CURL(http://1.1.1.1/foo.wav)=/tmp/foo.wav)
Would retrieve the file foo.wav from the remote server and store it in the
/tmp directory.
Due to the potentially dangerous nature of this function call, APIs are
forbidden from using the write functionality unless live_dangerously is set
to True in asterisk.conf.
ASTERISK-25652 #close
Change-Id: I44f4ad823d7d20f04ceaad3698c5c7f653c41b0d
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
Previous chan_sip behavior:
Before this patch chan_sip would always strip any quotes from an incoming
reason and pass that value up as the REDIRECTING(reason). For an outgoing
reason value, chan_sip would check the value against known values and
quote any it didn't recognize. Incoming 480 response message reason text
was just assigned to the REDIRECTING(reason).
Previous chan_pjsip behavior:
Before this patch chan_pjsip would always pass the incoming reason value
up as the REDIRECTING(reason). For an outgoing reason value, chan_pjsip
would send the reason value as passed down.
With this patch:
Both channel drivers match incoming reason values with values documented
by REDIRECTING(reason) and values documented by RFC5806 regardless of
whether they are quoted or not. RFC5806 values are mapped to the
equivalent REDIRECTING(reason) documented value and is set in
REDIRECTING(reason). e.g., an incoming RFC5806 'unconditional' value or a
quoted string version ('"unconditional"') is converted to
REDIRECTING(reason)'s 'cfu' value. The user's dialplan only needs to deal
with 'cfu' instead of any of the aliases.
The incoming 480 response reason text supported by chan_sip checks for
known reason values and if not matched then puts quotes around the reason
string and assigns that to REDIRECTING(reason).
Both channel drivers send outgoing known REDIRECTING(reason) values as the
unquoted RFC5806 equivalent. User custom values are either sent as is or
with added quotes if SIP doesn't allow a character within the value as
part of a RFC3261 Section 25.1 token. Note that there are still
limitations on what characters can be put in a custom user value. e.g.,
embedding quotes in the middle of the reason string is silly and just
going to cause you grief.
* Setting a REDIRECTING(reason) value now recognizes RFC5806 aliases.
e.g., Setting REDIRECTING(reason) to 'unconditional' is converted to the
'cfu' value.
* Added missing malloc() NULL return check in res_pjsip_diversion.c
set_redirecting_reason().
* Fixed potential read from a stale pointer in res_pjsip_diversion.c
add_diversion_header(). The reason string needed to be copied into the
tdata memory pool to ensure that the string would always be available.
Otherwise, if the reason string returned by reason_code_to_str() was a
user's reason string then the string could be freed later by another
thread.
Change-Id: Ifba83d23a195a9f64d55b9c681d2e62476b68a87
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 '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
Previously you could add [!dnid] to the SIP dial string to alter the To:
header. This change allows you to alter the From header as well.
SIP dial string extra options now look like this:
[![touser[@todomain]][![fromuser][@fromdomain]]]
INCOMPATIBLE CHANGE: If you were using an exclamation mark in your To:
header, that is no longer possible.
ASTERISK-25803 #close
Change-Id: I2457e9ba7a89eb1da22084bab5a4d4328e189db7
Warnings and errors in the pjproject libraries are generally handled by
Asterisk. In many cases, Asterisk wouldn't even consider them to be warnings
or errors so the messages emitted by pjproject directly are either superfluous
or misleading. A good exampe of this are the level-0 errors pjproject emits
when it can't open a TCP/TLS socket to a client to send an OPTIONS. We don't
consider a failure to qualify a UDP client an "ERROR", why should a TCP/TLS
client be treated any differently?
A config file for res_pjproject has bene added (pjproject.conf) and a new
log_mappings object allows mapping pjproject levels to Asterisk levels
(or nothing). The defaults if no pjproject.conf file is found are the same
as those that were hard-coded into res_pjproject initially: 0,1 = LOG_ERROR,
2 = LOG_WARNING, 3,4,5 = LOG_DEBUG<level>
Change-Id: Iba7bb349c70397586889b8f45b8c3d6c6c8c3898
A new command (pjsip export config_wizard primitives) has been added that
will export all the pjsip objects it created to the console or a file
suitable for reuse in a pjsip.conf file.
ASTERISK-24919 #close
Reported-by: Ray Crumrine
Change-Id: Ica2a5f494244b4f8345b0437b16d06aa0484452b
* changes:
app_confbridge: Add ability to get the muted conference state.
app_confbridge.c: Update CONFBRIDGE and CONFBRIDGE_INFO documentation.
app_confbridge: Make non-admin users join a muted conference muted.
During ICE negotiation the IPs of the local interfaces are sent to the remote
peer as host candidates. In many cases Asterisk is behind a static one-to-one
NAT, so these host addresses will be internal IP addresses.
To help in hiding the topology of the internal network, this patch adds the
ability to override the host candidates by matching them against a
user-defined list of replacements.
Change-Id: I1c9541af97b83a4c690c8150d19bf7202c8bff1f
* Added CONFBRIDGE_INFO(muted,) for querying the muted conference state.
* Added Muted header to AMI ConfbridgeListRooms action response list
events to indicate the muted conference state.
* Added Muted column to CLI "confbridge list" output to indicate the muted
conference state and made the locked column a yes/no value instead of a
locked/unlocked value.
ASTERISK-20987
Reported by: hristo
Change-Id: I4076bd8ea1c23a3afd4f5833e9291b49a0c448b1
Add time when started a the last pause for a queue member for
QueueMemberStatus ami event.
Also show accumulate time in seconds when started a pause for a queue
member to CLI command 'queue show'.
ASTERISK-16394 #close
Change-Id: I4b12aa3b2efa8d02939db3e13712510b4879865c
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
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
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
The menuselect conflict between app_voicemail and res_mwi_external
makes it hard to package 1 version of Asterisk. There no actual
build dependencies between the 2 so moving this check to runtime
seems like a better solution.
The ast_vm_register and ast_vm_greeter_register functions in app.c
were modified to return AST_MODULE_LOAD_DECLINE instead of -1 if there
is already a voicemail module registered. The modules' load_module
functions were then modified to return DECLINE instead of -1 to the
loader. Since -1 is interpreted by the loader as AST_MODULE_LOAD_FAILURE,
the modules were incorrectly causing Asterisk to stop so this needed
to be cleaned up anyway.
Now you can build both and use modules.conf to decide which voicemail
implementation to load.
The default menuselect options still build app_voicemail and not
res_mwi_external but if both ARE built, res_mwi_external will load
first and become the voicemail provider unless modules.conf rules
prevent it. This is noted in CHANGES.
Change-Id: I7d98d4e8a3b87b8df9e51c2608f0da6ddfb89247
This patch adds a new module, res_pjsip_history, that provides a slightly
better way of debugging SIP message traffic on a busy Asterisk system. The
existing mechanisms all rely on passively dumping a SIP message to the CLI.
While this is perfectly fine for logging purposes and well controlled
environments, on many installations, the amount of SIP messages Asterisk
receives will quickly swamp the CLI. This makes it difficult to view/capture
those messages that you want to diagnose in real time.
This patch provides another way of handling this. When enabled, the module
will store SIP message traffic in memory. This traffic can then be queried
at leisure.
In order to make the querying useful, a CLI command has been implemented,
'pjsip show history', that supports a basic expression syntax similar to
SQL or other query languages. A small number of useful fields have been
added in this initial patch; additional fields can easily be added in
later improvements. Those fields are:
- number: The entry index in the history
- timestamp: The time the message was recieved
- addr: The source/destination address of the message
- sip.msg.request.method: The request method
- sip.msg.call-id: The Call-ID header
Note - this is a resurrection of the module initially proposed on Review Board
here: https://reviewboard.asterisk.org/r/4053/
Change-Id: I39bd74ce998e99ad5ebc0aab3e84df3a150f8e36
This change introduces the configuration option 'full_backend_cache'
which changes the cache to be a full mirror of the backend instead
of a per-object cache. This allows all sorcery retrieval operations
to be carried out against it and is useful for object types which
are used in a "retrieve all" or "retrieve some" pattern.
ASTERISK-25625 #close
Change-Id: Ie2993487e9c19de563413ad5561c7403b48caab5
This reverts commit f42d22d3a1.
Unfortunately, using a bridge to manage T.38 state will cause severe deadlocks
in core_unreal/chan_local. Local channels attempt to reach across both their
peer and the peer's bridge to inspect T.38 state. Given the propensity of
Local channel chains, managing the locking situation in such a scenario is
practically infeasible.
Change-Id: I932107387c13aad2c75a7a4c1e94197a9d6d8a51
When 4875e5ac32 was merged, it fixed several issues with a direct media bridge
transitioning to handling a T.38 fax. However, it uncovered a race condition
caused by the bridging core. When a channel involved in a T.38 fax leaves a
bridge, the frame queued by the channel driver that should inform the far side
that it is no longer in a T.38 fax may not make it across the bridge. The
bridging framework is *extremely* aggressive in tearing down the bridge, and
control frames that are currently in flight *may* get dropped.
This patch adds a new module to the bridging framework, bridge_t38. This module
maintains some notion of the T.38 state for the two channels in a bridge. When
the bridge detects that it is being torn down or when one of the two channels
leaves, it informs the respective channel(s) that they should stop faxing. This
ensures that channels switch back to audio if they survive and are ejected out
of a bridge while faxing.
ASTERISK-25582
Change-Id: If5b0bb478eb01c4607c9f4a7fc17c7957d260ea0
This patch adds a module that emits StatsD statistics about Asterisk
endpoints. This includes:
* A GAUGE statistic for endpoint states, tracking how many endpoints are in
a particular state.
* A GAUGE statistic for each endpoint, counting the number of channels
currently associated with an endpoint.
ASTERISK-25572
Change-Id: If7e1333c5aeda8d136850b30c2101c0ee1c97305
This patch adds the ability to send StatsD statistics related to the
state of PJSIP contacts. This includes:
* A GUAGE statistic measuring the count of contacts in a particular state.
This measures how many contacts are reachable, unreachable, etc.
* The RTT time for each contact, if those contacts are qualified. This
provides StatsD engines useful time-based data about each contact.
ASTERISK-25571
Change-Id: Ib8378d73afedfc622be0643b87c542557e0b332c
This patch adds outbound registration statistics for StatsD. This includes
the following:
* A GUAGE metric for the overall count of outbound registrations.
* A GUAGE metric for each state an outbound registration can be in. As the
outbound registrations change state, the overall count of how many
outbound registrations are in the particular state is changed.
These statistics are particularly useful for systems with a large number of
SIP trunks, and where measuring the change in state of the trunks is useful
for monitoring.
ASTERISK-25571
Change-Id: Iba6ff248f5d1c1e01acbb63e9f0da1901692eb37
To be able to barge into a call by dialling a prefix+extension that maps
to the extensions device.
Senario is that DECT headset users may be away from their desks and need
to transfer the call, the goal is that from any phone they dial a prefix
then their extension and are added to the bridge that they are in, from
there they can drop the headset call, as it's also on the handset,
and transfer the caller.
The dialplan would look like, where prefix=73, extension = 8512;
exten => _738512,1,BridgeAdd(SIP/cisco0001)
ASTERISK-25551 #close
Reported By: Alec Davis
Change-Id: I8eb5096a02168dcc8d7aeea416ef36ba4ed10540
This option adds the ability to specify a timeout, in seconds, for a
participant in a ConfBridge. When the user's timeout has been reached,
the user is ejected from the conference with the CONFBRIDGE_RESULT
channel variable set to "TIMEOUT".
The rationale for this change is that there have been times where we
have seen channels get "stuck" in ConfBridge because a network issue
results in a SIP BYE not being received by Asterisk. While these
channels can be hung up manually via CLI/AMI/ARI, adding some sort of
automatic cleanup of the channels is a nice feature to have.
ASTERISK-25549 #close
Reported by Mark Michelson
Change-Id: I2996b6c5e16a3dda27595f8352abad0bda9c2d98
