The verification check for missing or anonymous callerid was happening before
the endpoint's profile was retrieved which meant that the failure_action
parameter wasn't available. Therefore, if verification was enabled and there
was no callerid or it was "anonymous", the call was immediately terminated
instead of giving the dialplan the ability to decide what to do with the call.
* The callerid check now happens after the verification context is created and
the endpoint's stir_shaken_profile is available.
* The check now processes the callerid failure just as it does for other
verification failures and respects the failure_action parameter. If set
to "continue" or "continue_return_reason", `STIR_SHAKEN(0,verify_result)`
in the dialplan will return "invalid_or_no_callerid".
* If the endpoint's failure_action is "reject_request", the call will be
rejected with `433 "Anonymity Disallowed"`.
* If the endpoint's failure_action is "continue_return_reason", the call will
continue but a `Reason: STIR; cause=433; text="Anonymity Disallowed"`
header will be added to the next provisional or final response.
Resolves: #1112
(cherry picked from commit 71551013c4)
Between ast_ari_channels_external_media(), external_media_rtp_udp(),
and external_media_audiosocket_tcp(), the `variables` structure being passed
around wasn't being cleaned up properly when there was a failure.
* In ast_ari_channels_external_media(), the `variables` structure is now
defined with RAII_VAR to ensure it always gets cleaned up.
* The ast_variables_destroy() call was removed from external_media_rtp_udp().
* The ast_variables_destroy() call was removed from
external_media_audiosocket_tcp(), its `endpoint` allocation was changed to
to use ast_asprintf() as external_media_rtp_udp() does, and it now
returns an error on failure.
* ast_ari_channels_external_media() now checks the new return code from
external_media_audiosocket_tcp() and sets the appropriate error response.
Resolves: #1109
(cherry picked from commit 5267c17645)
Introduce a ChannelTransfer event and the ability to notify progress to
ARI. Implement emitting this event from the PJSIP channel instead of
handling the transfer in Asterisk when configured.
Introduce a dialplan function to the PJSIP channel to switch between the
"core" and "ari-only" behavior.
UserNote: Call transfers on the PJSIP channel can now be controlled by
ARI. This can be enabled by using the PJSIP_TRANSFER_HANDLING(ari-only)
dialplan function.
(cherry picked from commit 71eb8a262f)
This process was a bit different than the others because everything
is in the same file, there's an array that contains the command
names and their handler functions, and the last command was created
over 15 years ago.
* Dump a `git blame` of res/res_agi.c from BEFORE the handle_* prototypes
were changed.
* Create a command <> handler function xref by parsing the the agi_command
array.
* For each entry, grep the function definition line "static int handle_*"
from the git blame output and capture the commit. This will be the
commit the command was created in.
* Do a `git tag --contains <commit> | sort -V | head -1` to get the
tag the function was created in.
* Add a single since/version element to the command XML. Multiple versions
aren't supported here because the branching and tagging scheme changed
several times in the 2000's.
(cherry picked from commit f1df1cacf6)
Also updates the 'since' of applications/functions that existed before
XML documentation was introduced (1.6.2.0).
(cherry picked from commit b4156fecf0)
When an incoming request can't be matched to an endpoint, the "artificial"
auth object is used to create a challenge to return in a 401 response and we
emit a "No matching endpoint found" log message. If the client then responds
with an Authorization header but the request still can't be matched to an
endpoint, the verification will fail and, as before, we'll create a challenge
to return in a 401 response and we emit a "No matching endpoint found" log
message. HOWEVER, because there WAS an Authorization header and it failed
verification, we should have also been emitting a "Failed to authenticate"
log message but weren't because there was a check that short-circuited that
it if the artificial auth was used. Since many admins use the "Failed to
authenticate" message with log parsers like fail2ban, those attempts were not
being recognized as suspicious.
Changes:
* digest_check_auth() now always emits the "Failed to authenticate" log
message if verification of an Authorization header failed even if the
artificial auth was used.
* The verification logic was refactored to be clearer about the handling
of the return codes from verify().
* Comments were added clarify what return codes digest_check_auth() should
return to the distributor and the implications of changing them.
Resolves: #1095
An issue in config_auth.c:ast_sip_auth_digest_algorithms_vector_init() was
causing double allocations for the two supported_algorithms vectors to the
tune of 915 bytes. The leak only happens on startup and when a reload is done
and doesn't get bigger with the number of auth objects defined.
* Pre-initialized the two vectors in config_auth:auth_alloc().
* Removed the allocations in ast_sip_auth_digest_algorithms_vector_init().
* Added a note to the doc for ast_sip_auth_digest_algorithms_vector_init()
noting that the vector passed in should be initialized and empty.
* Simplified the create_artificial_auth() function in pjsip_distributor.
* Set the vector initialization count to 0 in config_global:global_apply().
* Do a git blame on the embedded XML application or function element.
* From the commit hash, grab the summary line.
* Do a git log --grep <summary> to find the cherry-pick commits in all
branches that match.
* Do a git patch-id to ensure the commits are all related and didn't get
a false match on the summary.
* Do a git tag --contains <commit> to find the tags that contain each
commit.
* Weed out all tags not ..0.
* Sort and discard any .0.0 and following tags where the commit
appeared in an earlier branch.
* The result is a single tag for each branch where the application or function
was defined.
The applications and functions defined in the following files were done by
hand because the XML was extracted from the C source file relatively recently.
* channels/pjsip/dialplan_functions_doc.xml
* main/logger_doc.xml
* main/manager_doc.xml
* res/res_geolocation/geoloc_doc.xml
* res/res_stir_shaken/stir_shaken_doc.xml
(cherry picked from commit 85a4ab8390)
* Do a git blame on the embedded XML managerEvent elements.
* From the commit hash, grab the summary line.
* Do a git log --grep <summary> to find the cherry-pick commits in all
branches that match.
* Do a git patch-id to ensure the commits are all related and didn't get
a false match on the summary.
* Do a git tag --contains <commit> to find the tags that contain each
commit.
* Weed out all tags not ..0.
* Sort and discard any .0.0 and following tags where the commit
appeared in an earlier branch.
* The result is a single tag for each branch where the application or function
was defined.
The events defined in res/res_pjsip/pjsip_manager.xml were done by hand
because the XML was extracted from the C source file relatively recently.
Two bugs were fixed along the way...
* The get_documentation awk script was exiting after it processed the first
DOCUMENTATION block it found in a file. We have at least 1 source file
with multiple DOCUMENTATION blocks so only the first one in them was being
processed. The awk script was changed to continue searching rather
than exiting after the first block.
* Fixing the awk script revealed an issue in logger.c where the third
DOCUMENTATION block contained a XML fragment that consisted only of
a managerEventInstance element that wasn't wrapped in a managerEvent
element. Since logger_doc.xml already existed, the remaining fragments
in logger.c were moved to it and properly organized.
(cherry picked from commit a47b8e2d40)
This should resolve the Prometheus error:
> Error scraping target: non-compliant scrape target
sending blank Content-Type and no
fallback_scrape_protocol specified for target.
Resolves: #1075
(cherry picked from commit fa286641fb)
Most of the configObjects and configOptions that are implemented with
ACO or Sorcery now have `<since>/<version>` elements added. There are
probably some that the script I used didn't catch. The version tags were
determined by the following...
* Do a git blame on the API call that created the object or option.
* From the commit hash, grab the summary line.
* Do a `git log --grep <summary>` to find the cherry-pick commits in all
branches that match.
* Do a `git patch-id` to ensure the commits are all related and didn't get
a false match on the summary.
* Do a `git tag --contains <commit>` to find the tags that contain each
commit.
* Weed out all tags not <major>.<minor>.0.
* Sort and discard any <major>.0.0 and following tags where the commit
appeared in an earlier branch.
* The result is a single tag for each branch where the API was last touched.
configObjects and configOptions elements implemented with the base
ast_config APIs were just not possible to find due to the non-deterministic
way they are accessed.
Also note that if the API call was on modified after it was added, the
version will be the one it was last modified in.
Final note: The configObject and configOption elements were introduced in
12.0.0 so options created before then may not have any XML documentation.
(cherry picked from commit a22dc33057)
The return code fom digest_check_auth wasn't explicitly being initialized.
The return code also wasn't explicitly set to CHALLENGE when challenges
were sent. When optimization was turned off (DONT_OPTIMIZE), the compiler
was setting it to "0"(CHALLENGE) which worked fine. However, with
optimization turned on, it was setting it to "1" (SUCCESS) so if there was
no incoming Authorization header, the function was returning SUCCESS to the
distributor allowing the request to incorrectly succeed.
The return code is now initialized correctly and is now explicitly set
to CHALLENGE when we send challenges.
(cherry picked from commit 317b830c1e)
* channels/pjsip/dialplan_functions_doc.xml: Added xmlns:xi to docs element.
* main/bucket.c: Removed XML completely since the "bucket" and "file" objects
are internal only with no config file.
* main/named_acl.c: Fixed the configFile element name. It was "named_acl.conf"
and should have been "acl.conf"
* res/res_geolocation/geoloc_doc.xml: Added xmlns:xi to docs element.
* res/res_http_media_cache.c: Fixed the configFile element name. It was
"http_media_cache.conf" and should have been "res_http_media_cache.conf".
(cherry picked from commit 3b53152624)
* Added the "since" element to the XML configObject and configOption elements
in appdocsxml.dtd.
* Added the "Since" section to the following CLI output:
```
config show help <module> <object>
config show help <module> <object> <option>
core show application <app>
core show function <func>
manager show command <command>
manager show event <event>
agi show commands topic <topic>
```
* Refactored the commands above to output their sections in the same order:
Synopsis, Since, Description, Syntax, Arguments, SeeAlso
* Refactored the commands above so they all use the same pattern for writing
the output to the CLI.
* Fixed several memory leaks caused by failure to free temporary output
buffers.
* Added a "since" array to the mustache template for the top-level resources
(Channel, Endpoint, etc.) and to the paths/methods underneath them. These
will be added to the generated markdown if present.
Example:
```
"resourcePath": "/api-docs/channels.{format}",
"requiresModules": [
"res_stasis_answer",
"res_stasis_playback",
"res_stasis_recording",
"res_stasis_snoop"
],
"since": [
"18.0.0",
"21.0.0"
],
"apis": [
{
"path": "/channels",
"description": "Active channels",
"operations": [
{
"httpMethod": "GET",
"since": [
"18.6.0",
"21.8.0"
],
"summary": "List all active channels in Asterisk.",
"nickname": "list",
"responseClass": "List[Channel]"
},
```
NOTE: No versioning information is actually added in this commit.
Those will be added separately and instructions for adding and maintaining
them will be published on the documentation site at a later date.
(cherry picked from commit 3e28ddce78)
* Refactored pjproject code to support the new algorithms and
added a patch file to third-party/pjproject/patches
* Added new parameters to the pjsip auth object:
* password_digest = <algorithm>:<digest>
* supported_algorithms_uac = List of algorithms to support
when acting as a UAC.
* supported_algorithms_uas = List of algorithms to support
when acting as a UAS.
See the auth object in pjsip.conf.sample for detailed info.
* Updated both res_pjsip_authenticator_digest.c (for UAS) and
res_pjsip_outbound_authentocator_digest.c (UAC) to suport the
new algorithms.
The new algorithms are only available with the bundled version
of pjproject, or an external version > 2.14.1. OpenSSL version
1.1.1 or greater is required to support SHA-512-256.
Resolves: #948
UserNote: The SHA-256 and SHA-512-256 algorithms are now available
for authentication as both a UAS and a UAC.
(cherry picked from commit 1933548d41)
Added a new option "qualify_2xx_only" to the res_pjsip AOR qualify
feature to mark a contact as available only if an OPTIONS request
returns a 2XX response. If the option is not specified or is false,
any response to the OPTIONS request marks the contact as available.
UserNote: The pjsip.conf AOR section now has a "qualify_2xx_only"
option that can be set so that only 2XX responses to OPTIONS requests
used to qualify a contact will mark the contact as available.
(cherry picked from commit 85f5a047c1)
Whenever a slot is freed up due to a failed connection, wake up a waiter
before failing.
In the case of a dead connection there could be waiters, for example,
let's say two threads tries to acquire objects at the same time, with
one in the cached connections, one will acquire the dead connection, and
the other will enter into the wait state. The thread with the dead
connection will clear up the dead connection, and then attempt a
re-acquire (at this point there cannot be cached connections else the
other thread would have received that and tried to clean up), as such,
at this point we're guaranteed that either there are no waiting threads,
or that the maxconnections - connection_cnt threads will attempt to
re-acquire connections, and then either succeed, using those
connections, or failing, and then signalling to release more waiters.
Also fix the pointer log for ODBC handle %p dead which would always
reflect NULL.
Signed-off-by: Jaco Kroon <jaco@uls.co.za>
(cherry picked from commit 89ffbb5de7)
Added a new option "unknown_tn_attest_level" to allow Identity
headers to be sent when a callerid TN isn't explicitly configured
in stir_shaken.conf. Since there's no TN object, a private_key_file
and public_cert_url must be configured in the attestation or profile
objects.
Since "unknown_tn_attest_level" uses the same enum as attest_level,
some of the sorcery macros had to be refactored to allow sharing
the enum and to/from string conversion functions.
Also fixed a memory leak in crypto_utils:pem_file_cb().
Resolves: #921
UserNote: You can now set the "unknown_tn_attest_level" option
in the attestation and/or profile objects in stir_shaken.conf to
enable sending Identity headers for callerid TNs not explicitly
configured.
(cherry picked from commit 90cf13acd8)
The suppress_moh_on_sendonly endpoint option should have been
defined as OPT_BOOL_T in pjsip_configuration.c and AST_BOOL_VALUES
in the alembic script instead of OPT_YESNO_T and YESNO_VALUES.
Also updated contrib/ast-db-manage/README.md to indicate that
AST_BOOL_VALUES should always be used and provided an example.
Resolves: #995
Normally, when one party in a call sends Asterisk an SDP with
a "sendonly" or "inactive" attribute it means "hold" and causes
Asterisk to start playing MOH back to the other party. This can be
problematic if it happens at certain times, such as in a 183
Progress message, because the MOH will replace any early media you
may be playing to the calling party. If you set this option
to "yes" on an endpoint and the endpoint receives an SDP
with "sendonly" or "inactive", Asterisk will NOT play MOH back to
the other party.
Resolves: #979
UserNote: The new "suppress_moh_on_sendonly" endpoint option
can be used to prevent playing MOH back to a caller if the remote
end sends "sendonly" or "inactive" (hold) to Asterisk in an SDP.
(cherry picked from commit badf203203)
The tenantid field was originally added to the ast_sip_endpoint
structure at the end of the AST_DECLARE_STRING_FIELDS block. This
caused everything after it in the structure to move down in memory
and break ABI compatibility. It's now at the end of the structure
as an AST_STRING_FIELD_EXTENDED. Given the number of string fields
in the structure now, the initial string field allocation was
also increased from 64 to 128 bytes.
Resolves: #982
(cherry picked from commit be8f3a3fa4)
The key used for transport monitors was the remote host name for the
transport and not the remote address resolved for this domain.
This was problematic for domains returning multiple addresses as several
transport monitors were created with the same key.
Whenever a subsystem wanted to register a callback it would always end
up attached to the first transport monitor with a matching key.
The key used for transport monitors is now the remote address and port
the transport actually connected to.
Fixes: #932
(cherry picked from commit 2ee258b0fc)
There's really no point in spamming logs with a verbose message
for every unsupported crypto suite an older client may send
in an SDP. If none are supported, there will be an error or
warning.
(cherry picked from commit 50bd50d798)
Adds res_pjsip_config_sangoma as an external module that can be
downloaded via menuselect. It lives under the Resource Modules section.
(cherry picked from commit b8d818bd3c)
When a transport is disconnected, several events can arrive following
each other. The first event will be PJSIP_TP_STATE_DISCONNECT and it
will trigger the destruction of the transport monitor object. The lookup
for the transport monitor to destroy is done using the transport key,
that contains the transport destination host:port.
A reconnect attempt by pjsip will be triggered as soon something needs to
send a packet using that transport. This can happen directly after a
disconnect since ca
Subsequent events can arrive later like PJSIP_TP_STATE_DESTROY and will
also try to trigger the destruction of the transport monitor if not
already done. Since the lookup for the transport monitor to destroy is
done using the transport key, it can match newly created transports
towards the same destination and destroy their monitor object.
Because of this, it was sometimes not possible to monitor a transport
after one or more disconnections.
This fix adds an additional check on the transport pointer to ensure
only a monitor for that specific transport is removed.
Fixes: #923
(cherry picked from commit 6763dda90f)
This reverts commit cb5e3445be.
The original change from 16 to 15 bit sequence numbers was predicated
on the following from the now-defunct libSRTP FAQ on sourceforge.net:
> *Q6. The use of implicit synchronization via ROC seems
> dangerous. Can senders and receivers lose ROC synchronization?*
>
> **A.** It is possible to lose ROC synchronization between sender and
> receiver(s), though it is not likely in practice, and practical
> steps can be taken to avoid it. A burst loss of 2^16 packets or more
> will always break synchronization. For example, a conversational
> voice codec that sends 50 packets per second will have its ROC
> increment about every 22 minutes. A network with a burst of packet
> loss that long has problems other than ROC synchronization.
>
> There is a higher sensitivity to loss at the very outset of an SRTP
> stream. If the sender's initial sequence number is close to the
> maximum value of 2^16-1, and all packets are lost from the initial
> packet until the sequence number cycles back to zero, the sender
> will increment its ROC, but the receiver will not. The receiver
> cannot determine that the initial packets were lost and that
> sequence-number rollover has occurred. In this case, the receiver's
> ROC would be zero whereas the sender's ROC would be one, while their
> sequence numbers would be so close that the ROC-guessing algorithm
> could not detect this fact.
>
> There is a simple solution to this problem: the SRTP sender should
> randomly select an initial sequence number that is always less than
> 2^15. This ensures correct SRTP operation so long as fewer than 2^15
> initial packets are lost in succession, which is within the maximum
> tolerance of SRTP packet-index determination (see Appendix A and
> page 14, first paragraph of RFC 3711). An SRTP receiver should
> carefully implement the index-guessing algorithm. A naive
> implementation can unintentionally guess the value of
> 0xffffffffffffLL whenever the SEQ in the packet is greater than 2^15
> and the locally stored SEQ and ROC are zero. (This can happen when
> the implementation fails to treat those zero values as a special
> case.)
>
> When ROC synchronization is lost, the receiver will not be able to
> properly process the packets. If anti-replay protection is turned
> on, then the desynchronization will appear as a burst of replay
> check failures. Otherwise, if authentication is being checked, then
> it will appear as a burst of authentication failures. Otherwise, if
> encryption is being used, the desynchronization may not be detected
> by the SRTP layer, and the packets may be improperly decrypted.
However, modern libSRTP (as of 1.0.1[1]) now mentions the following in
their README.md[2]:
> The sequence number in the rtp packet is used as the low 16 bits of
> the sender's local packet index. Note that RTP will start its
> sequence number in a random place, and the SRTP layer just jumps
> forward to that number at its first invocation. An earlier version
> of this library used initial sequence numbers that are less than
> 32,768; this trick is no longer required as the
> rdbx_estimate_index(...) function has been made smarter.
So truncating our initial sequence number to 15 bit is no longer
necessary.
1. 0eb007f0dc/CHANGES (L271-L289)
2. 2de20dd9e9/README.md (implementation-notes)
(cherry picked from commit f3138af519)
Calls to `ast_replace_sigchld()` and `ast_unreplace_sigchld()` must be
balanced to ensure that we can capture the exit status of child
processes when we need to. This extends to functions that call
`ast_replace_sigchld()` and `ast_unreplace_sigchld()` such as
`ast_safe_fork()` and `ast_safe_fork_cleanup()`.
The primary change here is ensuring that we do not call
`ast_safe_fork_cleanup()` in `res_agi.c` if we have not previously
called `ast_safe_fork()`.
Additionally we reinforce some of the documentation and add an
assertion to, ideally, catch this sooner were this to happen again.
Fixes#922
(cherry picked from commit 243f20a78d)
asterisk.c, manager.c: Increase buffer sizes to avoid truncation warnings.
config.c: Include header file for WIFEXITED/WEXITSTATUS macros.
res_timing_kqueue: Use more portable format specifier.
test_crypto: Use non-linux limits.h header file.
Resolves: #916
(cherry picked from commit b8b21b3f00)
In dtls_srtp_handle_timeout(), when DTLSv1_get_timeout() returned
success but with a timeout of 0, we were stopping the timer and
decrementing the refcount on instance but not resetting the
timeout_timer to -1. When dtls_srtp_stop_timeout_timer()
was later called, it was atempting to stop a stale timer and could
decrement the refcount on instance again which would then cause
the instance destructor to run early. This would result in either
a FRACK or a SEGV when ast_rtp_stop(0 was called.
According to the OpenSSL docs, we shouldn't have been stopping the
timer when DTLSv1_get_timeout() returned success and the new timeout
was 0 anyway. We should have been calling DTLSv1_handle_timeout()
again immediately so we now reschedule the timer callback for
1ms (almost immediately).
Additionally, instead of scheduling the timer callback at a fixed
interval returned by the initial call to DTLSv1_get_timeout()
(usually 999 ms), we now reschedule the next callback based on
the last call to DTLSv1_get_timeout().
Resolves: #487
(cherry picked from commit 7db8ae296c)
When using the speech recognition module, crashes can occur
sporadically due to a "double free or corruption (out)" error. Now, in
the section where the audio stream is being captured in a loop, each
time after releasing fr, it is set to NULL to prevent repeated
deallocation.
Fixes#772
(cherry picked from commit 2d676c7560)
attest_level, send_mky and check_tn_cert_public_url weren't
propagating correctly from the attestation object to the profile
and tn.
* In the case of attest_level, the enum needed to be changed
so the "0" value (the default) was "NOT_SET" instead of "A". This
now allows the merging of the attestation object, profile and tn
to detect when a value isn't set and use the higher level value.
* For send_mky and check_tn_cert_public_url, the tn default was
forced to "NO" which always overrode the profile and attestation
objects. Their defaults are now "NOT_SET" so the propagation
happens correctly.
* Just to remove some redundant code in tn_config.c, a bunch of calls to
generate_sorcery_enum_from_str() and generate_sorcery_enum_to_str() were
replaced with a single call to generate_acfg_common_sorcery_handlers().
Resolves: #904
verification.c had an include for jansson.h left over from previous
versions of the module. Since res_stir_shaken no longer has a
dependency on jansson, the bundled version wasn't added to GCC's
include path so if you didn't also have a jansson development package
installed, the compile would fail. Removing the stale include
was the only thing needed.
Resolves: #889
* If the call to ast_config_load() returns CONFIG_STATUS_FILEINVALID,
check_for_old_config() now returns LOAD_DECLINE instead of continuing
on with a bad pointer.
* If CONFIG_STATUS_FILEMISSING is returned, check_for_old_config()
assumes the config is being loaded from realtime and now returns
LOAD_SUCCESS. If it's actually not being loaded from realtime,
sorcery will catch that later on.
* Also refactored the error handling in load_module() a bit.
Resolves: #884
For both attestation and verification, we now check whether they've
been disabled either globally or by the profile before validating
things like callerid, orig_tn, dest_tn, etc. This prevents useless
error messages.
Resolves: #879
(cherry picked from commit 7773327546)
When Asterisk sends an offer to Bob that includes 48K and 8K codecs with
matching 4733 offers, Bob may want to use the 48K audio codec but can not
accept 48K digits and so negotiates for a mixed set.
Asterisk will now check Bob's offer to make sure Bob has indicated this is
acceptible and if not, will use Bob's preference.
Fixes: #847
(cherry picked from commit ac673dd14e)
* A static array of security mechanism type names was created.
* ast_sip_str_to_security_mechanism_type() was refactored to do
a lookup in the new array instead of using fixed "if/else if"
statments.
* security_mechanism_to_str() and ast_sip_security_mechanisms_to_str()
were refactored to use ast_str instead of a fixed length buffer
to store the result.
* ast_sip_security_mechanism_type_to_str was removed in favor of
just referencing the new type name array. Despite starting with
"ast_sip_", it was a static function so removing it doesn't affect
ABI.
* Speaking of "ast_sip_", several other static functions that
started with "ast_sip_" were renamed to avoid confusion about
their public availability.
* A few VECTOR free loops were replaced with AST_VECTOR_RESET().
* Fixed a meomry leak in pjsip_configuration.c endpoint_destructor
caused by not calling ast_sip_security_mechanisms_vector_destroy().
* Fixed a memory leak in res_pjsip_outbound_registration.c
add_security_headers() caused by not specifying OBJ_NODATA in
an ao2_callback.
* Fixed a few ao2_callback return code misuses.
Resolves: #845
(cherry picked from commit ca60f7db8f)
PR #700 added a preferred_format for the struct ast_rtp_codecs,
but when set the preferred_format it leaks an astobj2 ast_format.
In the next code
ast_rtp_codecs_set_preferred_format(&codecs, ast_format_cap_get_format(joint, 0));
both functions ast_rtp_codecs_set_preferred_format
and ast_format_cap_get_format increases the ao2 reference count.
Fixes: #856
(cherry picked from commit 95fadcf6db)
Add dialplan application PJSIPNOTIFY to send either pre-configured
NOTIFY messages from pjsip_notify.conf or with headers defined in
dialplan.
Also adds the ability to send pre-configured NOTIFY commands to a
channel via the CLI.
Resolves: #799
UserNote: A new dialplan application PJSIPNotify is now available
which can send SIP NOTIFY requests from the dialplan.
The pjsip send notify CLI command has also been enhanced to allow
sending NOTIFY messages to a specific channel. Syntax:
pjsip send notify <option> channel <channel>
(cherry picked from commit e7ca7aa881)
This patch introduces a new identifier for channels: tenantid. It's
a stringfield on the channel that can be used for general purposes. It
will be inherited by other channels the same way that linkedid is.
You can set tenantid in a few ways. The first is to set it in the
dialplan with the Set and CHANNEL functions:
exten => example,1,Set(CHANNEL(tenantid)=My tenant ID)
It can also be accessed via CHANNEL:
exten => example,2,NoOp(CHANNEL(tenantid))
Another method is to use the new tenantid option for pjsip endpoints in
pjsip.conf:
[my_endpoint]
type=endpoint
tenantid=My tenant ID
This is considered the best approach since you will be able to see the
tenant ID as early as the Newchannel event.
It can also be set using set_var in pjsip.conf on the endpoint like
setting other channel variable:
set_var=CHANNEL(tenantid)=My tenant ID
Note that set_var will not show tenant ID on the Newchannel event,
however.
Tenant ID has also been added to CDR. It's read-only and can be accessed
via CDR(tenantid). You can also get the tenant ID of the last channel
communicated with via CDR(peertenantid).
Tenant ID will also show up in CEL records if it has been set, and the
version number has been bumped accordingly.
Fixes: #740
UserNote: tenantid has been added to channels. It can be read in
dialplan via CHANNEL(tenantid), and it can be set using
Set(CHANNEL(tenantid)=My tenant ID). In pjsip.conf, it is recommended to
use the new tenantid option for pjsip endpoints (e.g., tenantid=My
tenant ID) so that it will show up in Newchannel events. You can set it
like any other channel variable using set_var in pjsip.conf as well, but
note that this will NOT show up in Newchannel events. Tenant ID is also
available in CDR and can be accessed with CDR(tenantid). The peer tenant
ID can also be accessed with CDR(peertenantid). CEL includes tenant ID
as well if it has been set.
UpgradeNote: A new versioned struct (ast_channel_initializers) has been
added that gets passed to __ast_channel_alloc_ap. The new function
ast_channel_alloc_with_initializers should be used when creating
channels that require the use of this struct. Currently the only value
in the struct is for tenantid, but now more fields can be added to the
struct as necessary rather than the __ast_channel_alloc_ap function. A
new option (tenantid) has been added to endpoints in pjsip.conf as well.
CEL has had its version bumped to include tenant ID.
(cherry picked from commit 3841fa814e)
Previously, on command execution, the control thread was awoken by
sending a SIGURG. It was found that this still resulted in some
instances where the thread was not immediately awoken.
This change instead sends a null frame to awaken the control thread,
which awakens the thread more consistently.
Resolves: #801
(cherry picked from commit bdee743cd4)
When the endpoint dtmf_mode is set to auto, a SIP request is sent to the UAC, and the SIP SDP from the UAC does not include the telephone-event. Later, the UAC sends an INVITE, and the SIP SDP includes the telephone-event. In this case, DTMF should be sent by RFC2833 rather than using inband signaling.
Resolves: asterisk#826
(cherry picked from commit 6cf6856080)
