Currently the res_pjsip_mwi module only sends an unsolicited MWI NOTIFY upon
a mailbox state change (such as a new message being left, or one being deleted).
In practice this is not sufficient to keep clients aware of the current MWI status.
This change makes the module send unsolicited MWI NOTIFY on startup so that
clients are guaranteed to have the most up to date MWI information. It also makes
clients receive an unsolicited MWI NOTIFY upon registration so if they are unaware
of the current MWI status they receive it.
ASTERISK-24982 #close
Reported by: Joshua Colp
Change-Id: I043f20230227e91218f18a82c7d5bb2aa62b1d58
Fix a crash that could occur in __ast_channel_internal_alloc if
ao2_alloc fails.
ASTERISK-24991 #close
Change-Id: I4ca89189eb22f907408cb87d0a1645cfe1314a90
When SUBSCRIBE dialogs were established, we never associated
the endpoint that created the subscription with the dialog
we end up creating. In most cases, this ended up not causing
any problems.
The actual bug that was observed was that when a device that
was behind NAT established a subscription with Asterisk, Asterisk
would end up sending in-dialog NOTIFY requests to the device's
private IP addres instead of the public address of the NAT router.
When Asterisk receives the initial SUBSCRIBE from the device,
res_pjsip_nat rewrites the contact to the public address on which the
SUBSCRIBE was received. This allows for the dialog to have its target
address set to the proper public address. Asterisk then would send a 200
OK response to the SUBSCRIBE, then a NOTIFY with the initial
subscription state. The device would then send a 200 OK response to
Asterisk's NOTIFY.
Here's where things went wrong. When the 200 OK arrived, res_pjsip_nat
did not rewrite the address in the Contact header. Then, when the PJSIP
dialog layer processed the 200 OK, PJSIP would perform a comparison
between the IP address in the Contact header and its saved target
address for the dialog. Since they differed, PJSIP would update the
target dialog address to be the address in the Contact header. From this
point, if Asterisk needed to send a NOTIFY to the device, the result was
that the NOTIFY would be sent to the private address that the device
placed in the Contact header.
The reason why res_pjsip_nat did not rewrite the address when it
received the 200 OK response was that it could not associate the
incoming response with a configured endpoint. This is because on a
response, the only way to associate the response to an endpoint is by
finding the dialog that the response is associated with and then finding
the endpoint that is associated with that dialog. We do not perform
endpoint lookups on responses. res_pjsip_pubsub skipped the step of
associating the endpoint with the dialog we created, so res_pjsip_nat
could not find the associated endpoint and therefore couldn't rewrite
the contact.
This commit message is like 50x longer than the actual fix.
ASTERISK 24981 #close
Reported by Mark Michelson
Change-Id: I2b963c58c063bae293e038406f7d044a8a5377cd
The chan_dahdi channel driver is a very old driver. The ability for it to
support ISDN was added well after the initial analog support. Setting the
softhangup flags is a carry over from the original analog code. The
driver was not updated to call ast_queue_hangup() which will post the AMI
HangupRequest event.
* Changed sig_pri.c to call ast_queue_hangup() instead of setting the
softhangup flag when the remote party initiates a hangup.
ASTERISK-24895 #close
Reported by: Andrew Zherdin
Change-Id: I5fe2e48556507785fd8ab8e1c960683fd5d20325
Contact status rtt is an int64_t and needs the PRId64 macro to
properly create the format specifier on 32-bit systems.
Change-Id: I4b8ab958fc1e9a179556a9b4ffa49673ba9fdec7
The "Add qualify_timeout processing and eventing" patch introduced
an issue where contacts that had qualify_frequency set to 0 were
showing Unavailable instead Unknown. This patch checks for
qualify_frequency=0 and create an "Unknown" contact_status
with an RTT = 0.
Previously, the lack of contact_status implied Unknown but since
we're now changing endpoint state based on contact_status, I've
had to add new UNKNOWN status so that changes could trigger the
appropriate contact_status observers.
ASTERISK-24977: #close
Change-Id: Ifcbc01533ce57f0e4e584b89a395326e098b8fe7
When a PBX registrar is unloaded, it will fail to remove its extension from
the context root_table if a dialplan application used by that extension is
still loaded. This can be the case for AGI, which can be unloaded after several
of the standard PBX providers. Often, this is harmless; however, if the
extension's priorities are removed during the failed unloading *and* the
dialplan application later unregisters, it leaves a ticking timebomb for the
next PBX provider that attempts to iterate over the extensions. When that
occurs, the peer_table pointer on the extension will already be set to NULL.
The current code does not check to see if the pointer is NULL before passing
it to a hashtab function this is not NULL tolerant.
Since it is possible for the peer_table to be NULL when we normally would not
expect that to be the case, the solution in this patch is to simply skip over
processing an extension's priorities if peer_table is NULL.
Prior to this patch, the tests/pbx/callerid_match test would crash during
module unload. With this patch, the test no longer crashes after running.
ASTERISK-24774 #close
Reported by: Corey Farrell
Change-Id: I2bbeecb7e0f77bac303a1b9135e4cdb4db6d4c40
Three fax related tests started failing as a result of changes made for
ASTERISK-24841:
tests/fax/pjsip/gateway_t38_g711
tests/fax/sip/gateway_mix1
tests/fax/sip/gateway_mix3
Historically, ast_channel_make_compatible() did nothing if the channels
were already "compatible" even if they had a sub-optimal translation path
already setup. With the changes from ASTERISK-24841 this is no longer
true in order to allow the best translation paths to always be picked. In
res_fax.c:fax_gateway_framehook() code manually setup the channels to go
through slin and then called ast_channel_make_compatible(). With the
previous version of ast_channel_make_compatible() this was always a
no-operation.
* Remove call to ast_channel_make_compatible() in fax_gateway_framehook()
that now undoes what was just setup when the framehook is attached.
* Fixed locking around saving the channel formats in
fax_gateway_framehook() to ensure that the formats that are saved are
consistent.
* Fix copy pasta errors in fax_gateway_framehook() that confuses read and
write when dealing with saved channel formats.
ASTERISK-24841
Reported by: Matt Jordan
Change-Id: I6fda0877104a370af586a5e8cf9e161a484da78d
When DEBUG_THREADLOCALS is enabled it causes the threadlocal cleanup to be
called as a function. This causes a compile error with raw threadstorage as
it uses NULL for cleanup. This fix uses a macro that provides NULL when
DEBUG_THREADLOCALS is disabled, and replaces the call to "c_cleanup(data);"
with "{};" when DEBUG_THREADLOCALS is enabled.
ASTERISK-24975 #close
Reported by: Ashley Sanders
Change-Id: I3ef7428ee402816d9fcefa1b3b95830c00d5c402
A potential problem that can arise is the following:
* Bob's phone is programmed to automatically forward to Carol.
* Carol's phone is programmed to automatically forward to Bob.
* Alice calls Bob.
If left unchecked, this results in an endless loops of call forwards
that would eventually result in some sort of fiery crash.
Asterisk's method of solving this issue was to track which interfaces
had been dialed. If a destination were dialed a second time, then
the attempt to call that destination would fail since a loop was
detected.
The problem with this method is that call forwarding has evolved. Some
SIP phones allow for a user to manually forward an incoming call to an
ad-hoc destination. This can mean that:
* There are legitimate use cases where a device may be dialed multiple
times, or
* There can be human error when forwarding calls.
This change removes the old method of detecting forwarding loops in
favor of keeping a count of the number of destinations a channel has
dialed on a particular branch of a call. If the number exceeds the
set number of max forwards, then the call fails. This approach has
the following advantages over the old:
* It is much simpler.
* It can detect loops involving local channels.
* It is user configurable.
The only disadvantage it has is that in the case where there is a
legitimate forwarding loop present, it takes longer to detect it.
However, the forwarding loop is still properly detected and the
call is cleaned up as it should be.
Address review feedback on gerrit.
* Correct "mfgium" to "Digium"
* Decrement max forwards by one in the case where allocation of the
max forwards datastore is required.
* Remove irrelevant code change from pjsip_global_headers.c
ASTERISK-24958 #close
Change-Id: Ia7e4b7cd3bccfbd34d9a859838356931bba56c23
This is the second follow-on to https://reviewboard.asterisk.org/r/4572/ and the
discussion at
http://lists.digium.com/pipermail/asterisk-dev/2015-March/073921.html
The basic issues are that changes in contact status don't cause events to be
emitted for the associated endpoint. Only dynamic contact add/delete actions
update the endpoint. Also, the qualify timeout is fixed by pjsip at 32 seconds
which is a long time.
This patch makes use of the new transaction timeout feature in r4585 and
provides the following capabilities...
1. A new aor/contact variable 'qualify_timeout' has been added that allows the
user to specify the maximum time in milliseconds to wait for a response to an
OPTIONS message. The default is 3000ms. When the timer expires, the contact is
marked unavailable.
2. Contact status changes are now propagated up to the endpoint as follows...
When any contact is 'Available', the endpoint is marked as 'Reachable'. When
all contacts are 'Unavailable', the endpoint is marked as 'Unreachable'. The
existing endpoint events are generated appropriately.
ASTERISK-24863 #close
Change-Id: Id0ce0528e58014da1324856ea537e7765466044a
Tested-by: Dmitriy Serov
Tested-by: George Joseph <george.joseph@fairview5.com>
Due to a race condition there was a chance that during an attended transfer the
channel's application would return NULL. This, of course, would cause a crash
when attempting to access the memory. This patch retrieves the channel's app
at an earlier time in processing in hopes that the app name is available.
However, if it is not then "unknown" is used instead. Since some string value
is now always present the crash can no longer occur.
ASTERISK-24869 #close
Reported by: viniciusfontes
Review:
Change-Id: I5134b84c4524906d8148817719d76ffb306488ac
This change makes the send_notify of the sub_tree
not happen when the sub_tree has been deleted due
to the notify call failing, which avoids a crash.
ASTERISK-24970 #close
Change-Id: I1f20ffc08b192f59c457293b218025a693992cbf
This is the first follow-on to https://reviewboard.asterisk.org/r/4572/ and the
discussion at
http://lists.digium.com/pipermail/asterisk-dev/2015-March/073921.html
Since we currently have no control over pjproject transaction timeout, this
patch pulls the pjsip_endpt_send_request function out of pjproject and into
res_pjsip/endpt_send_transaction in order to implement that capability.
Now when the transaction is initiated, we also schedule our own pj_timer with
our own desired timeout.
If the transaction completes before either timeout, pjproject cancels its timer,
and calls our tsx callback where we cancel our timer and run the app callback.
If the pjproject timer times out first, pjproject calls our tsx callback where
we cancel our timer and run the app callback.
If our timer times out first, we terminate the transaction which causes
pjproject to cancel its timer and call our tsx callback where we run the app
callback.
Regardless of the scenario, pjproject is calling the tsx callback inside the
group_lock and there are checks in the callback to make sure it doesn't run
twice.
As part of this patch ast_sip_send_out_of_dialog_request was created to replace
its similarly named private function. It takes a new timeout argument in
milliseconds (<= 0 to disable the timeout).
ASTERISK-24863 #close
Reported-by: George Joseph <george.joseph@fairview5.com>
Tested-by: George Joseph <george.joseph@fairview5.com>
Change-Id: I0778dc730d9689c5147a444a04aee3c1026bf747
Currently when Asterisk starts initial qualifies of contacts are spread out
randomly between 0 and qualify_timeout to prevent network and system overload.
If a contact's qualify_frequency is 5 minutes however, that contact may be
unavailable to accept calls for the entire 5 minutes after startup. So while
staggering the initial qualifies is a good idea, basing the time on
qualify_timeout could leave contacts unavailable for too long.
This patch adds a new global parameter "max_initial_qualify_time" that sets the
maximum time for the initial qualifies. This way you could make sure that all
your contacts are initialy, randomly qualified within say 30 seconds but still
have the contact's ongoing qualifies at a 5 minute interval.
If max_initial_qualify_time is > 0, the formula is initial_interval =
min(max_initial_interval, qualify_timeout * random(). If not set,
qualify_timeout is used.
The default is "0" (disabled).
ASTERISK-24863 #close
Change-Id: Ib80498aa1ea9923277bef51d6a9015c9c79740f4
Tested-by: George Joseph <george.joseph@fairview5.com>
Added .pyc and .sha1 to the top-level .gitignore.
Change-Id: I7dfc4f554d54d22947b38140d3305007503cc16a
Tested-by: George Joseph <george.joseph@fairview5.com>
The LOG_ERROR has reference to CDR instead of CEL for LENGTHEN_BUF1 and
LENGTHEN_BUF2.
ASTERISK-24965 #close
Reported by: Rodrigo Ramirez Norambuena
Change-Id: Icc818697d7d66d34bfe3048cdd15ca2b06c89744
The Makefile claims that you can set default menuselect options by creating
~/.asterisk.makeopts or /etc/asterisk.makeopts, but those files have never
been respected in Asterisk 11 or 13. This changes the comment to accurately
reflect that these files are not automatically used by the build system.
ASTERISK-13721 #close
Reported by: pj
Change-Id: Ibde804ff196283def49ccb9432fbf224a22586e2
The command always showed the usage information.
* Fix the error in command validation for CLI_SHOWUSAGE.
ASTERISK-24959 #close
Reported by: Rodrigo Ramirez Norambuena
Change-Id: I584f0936bb01001336a468a55c1d05d79fe795d5
(cherry picked from commit 23a180cade)
During the mass code deletion for clang support, a stray backslash was
left behind that was causing utils to fail to compile.
Change-Id: I60e5fa58c9a5b248bde23aaada79ff663f87a2a1
External systems - such as the Asterisk Test Suite - require knowledge of the
upstream branch. Unfortunately, after moving to Git, the Asterisk version
currently consists of only a 'GIT" prefix followed by an object blob,
e.g., GIT-as08d7. This makes it difficult for such systems to know what
features are available in a particular check out of Asterisk.
This patch fixes this by hardcoding the branch in a variable in the
make_version script. Since the mainline branches are not changed often -
typically only once a year - this is a reasonable approach to solving
the problem, and is more reliable than parsing the output of 'git branch
-vv'. Branches that track off of an upstream primary branch will then get the
benefit of knowing which mainline branch they are currently based off
of.
ASTERISK-24954 #close
Change-Id: I8090d5d548b6d19e917157ed530b914b7eaf9799
Git does not support the ability to replace a token with a version
string during check-in. While it does have support for replacing a
token on clone, this is somewhat sub-optimal: the token is replaced
with the object hash, which is not particularly easy for human
consumption. What's more, in practice, the source file version was often
not terribly useful. Generally, when triaging bugs, the overall version
of Asterisk is far more useful than an individual SVN version of a file.
As a result, this patch removes Asterisk's support for showing source file
versions.
Specifically, it does the following:
* main/asterisk:
- Refactor the file_version structure to reflect that it no longer
tracks a version field.
- Alter the "core show file version" CLI command such that it always
reports the version of Asterisk. The file version is no longer
available.
* main/manager: The Version key now always reports the Asterisk version.
* UPGRADE: Add notes for:
- Modification to the ModuleCheck AMI Action.
- Modification of the "core show file version" CLI command.
Change-Id: Ia932d3c64cd18a14a3c894109baa657ec0a85d28
OPTIONAL_API has conditionals to define AST_OPTIONAL_API and
AST_OPTIONAL_API_ATTR differently based on if AST_API_MODULE is defined.
Unfortunately this is inside the include protection block, so only the
first status of AST_API_MODULE is respected. For example res_monitor
is an optional API provider, but uses func_periodic_hook. This makes
func_periodic_hook non-optional to res_monitor.
ASTERISK-17608 #close
Reported by: Warren Selby
Change-Id: I8fcf2a5e7b481893e17484ecde4f172c9ffb5679
This patch updates the root .gitignore file to ignore files with a .gz
extension. This will cause git to ignore downloaded sound tarballs in
the the sounds/ directory.
Change-Id: I1e42fbfa02a8884231507b683e8e49ac3e278aaa
Add the .gitignore and .gitreview files to the asterisk repo.
NB: You can add local ignores to the .git/info/exclude file
without having to do a commit.
Common ignore patterns are in the top-level .gitignore file.
Subdirectory-specific ignore patterns are in their own .gitignore
files.
Change-Id: I4c8af3b8e3739957db545f7368ac53f38e99f696
Tested-by: George Joseph
........
main/event: Remove unnecessary assignment of negative value to enum
When cleaning up some clang compiler warnings, the comparison of a negative
value to an unsigned enum was removed. However, the initial assignment of a
negative value to said enum remained in the variable declaration. This patch
removes that assignment.
Thanks to ibercom in #asterisk-bugs for pointing it out.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@434709 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to this patch, the far_max_datagram value on the UDPTL structure would
remain -1 if the remote endpoint fails to provide the SDP media attribute
T38FaxMaxDatagram. This can result in the INVITE request being rejected. With
this patch, we will now properly initialize the value with either the default
value or with the value provided by pjsip.conf's t38_udptl_maxdatagram
parameter.
Review: https://reviewboard.asterisk.org/r/4589
ASTERISK-24928 #close
Reported by: Juergen Spies
Tested by: Juergen Spies
patches:
pjsipT38patch20150331.txt submitted by Juergen Spies (License 6698)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@434688 65c4cc65-6c06-0410-ace0-fbb531ad65f3
With this patch, chan_pjsip/res_pjsip now sets the native formats to the
codecs negotiated by a call.
* The changes in chan_pjsip.c and res_pjsip_sdp_rtp.c set the native
formats to include all the negotiated audio codecs instead of only the
initial preferred audio codec and later the currently received audio
codec.
* The audio frame handling in channel.c:ast_read() is more streamlined and
will automatically adjust to changes in received frame formats. The new
policy is to remove translation and pass the new frame format to the
receiver except if the translation was to a signed linear format. A more
long winded version is commented in ast_read() along with some caveats.
* The audio frame handling in channel.c:ast_write() is more streamlined
and will automatically adjust any needed translation to changes in the
frame formats sent. Frame formats sent can change for many reasons such
as a recording is being played back or the bridged peer changed the format
it sends. Since it is a normal expectation that sent formats can change,
the codec mismatch warning message is demoted to a debug message.
* Removed the short circuit check in
channel.c:ast_channel_make_compatible_helper(). Two party bridges need to
make channels compatible with each other. However, transfers and moving
channels among bridges can result in otherwise compatible channels having
sub-optimal translation paths if the make compatible check is short
circuited. A result of forcing the reevaluation of channel compatibility
is that the asterisk.conf:transcode_via_slin and codecs.conf:genericplc
options take effect consistently now. It is unfortunate that these two
options are enabled by default and negate some of the benefits to the
changes in channel.c:ast_read() by forcing translation through signed
linear on a two party bridge.
* Improved the softmix bridge technology to better control the translation
of frames to the bridge. All of the incoming translation is now normally
handled by ast_read() instead of splitting any translation steps between
ast_read() and the slin factory. If any frame comes in with an unexpected
format then the translation path in ast_read() is updated for the next
frame and the slin factory handles the current frame translation.
This is the final patch in a series of patches aimed at improving
translation path choices. The other patches are on the following reviews:
https://reviewboard.asterisk.org/r/4600/https://reviewboard.asterisk.org/r/4605/
ASTERISK-24841 #close
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/4609/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@434671 65c4cc65-6c06-0410-ace0-fbb531ad65f3
After the "progressinband" value setting of "never" was updated to never send a
183 this separated its use from the "no" value. Since "never" was the default,
but most users probably expect "no" this patch updates the default for the
"progressinband" setting to "no."
ASTERISK-24835 #close
Reported by: Andrew Nagy
Review: https://reviewboard.asterisk.org/r/4606/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@434654 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds support for automatically detecting the type of DTMF that a
PJSIP endpoint supports. When the 'dtmf_mode' endpoint option is set to 'auto',
the channel created for an endpoint will attempt to determine if RFC 4733
DTMF is supported. If so, it will use that DTMF type. If not, the DTMF type
for the channel will be set to inband.
Review: https://reviewboard.asterisk.org/r/4438
ASTERISK-24706 #close
Reported by: yaron nahum
patches:
yaron_patch_3_Feb.diff submitted by yaron nahum (License 6676)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@434637 65c4cc65-6c06-0410-ace0-fbb531ad65f3
While investigating other unload issues I realized that the load/unload process
for the config wizard was pretty ugly so I've refactored it as follows...
When the res_pjsip sorcery instance is created the config_wizard bumps it's own
module reference to prevent it from unloading while the sorcery instance is
still active. When res_pjsip unloads and it's sorcery instance is destroyed,
the config wizard unrefs itself which then allows itself to unload cleanly.
Since the config wizard now can't load after res_pjsip or unload before it
(which should have been the correct behavior all along), I was able to remove
the chunks of code in both load_module and unload_module that handled that case.
Ran the testsuite tests to insure there were no functional changes and REF_DEBUG
to insure that Asterisk was shutting down cleanly with no FRACKs or leaks.
Tested-by: George Joseph
Review: https://reviewboard.asterisk.org/r/4610/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@434619 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Given a source capability of h264 and ulaw, a destination capability of
h264 and g722 then ast_translator_best_choice() would pick h264 as the
best choice even though h264 is a video codec and Asterisk only supports
translation of audio codecs. When the audio starts flowing, there are
warnings about a codec mismatch when the channel tries to write a frame to
the peer.
* Made ast_translator_best_choice() only select audio codecs.
* Restore a check in channel.c:set_format() lost after v1.8 to prevent
trying to set a non-audio codec.
This is an intermediate patch for a series of patches aimed at improving
translation path choices for ASTERISK-24841.
This patch is a complete enough fix for ASTERISK-21777 as the v11 version
of ast_translator_best_choice() does the same thing. However, chan_sip.c
still somehow tries to call ast_codec_choose() which then calls
ast_best_codec() with a capability set that doesn't contain any audio
formats for the incoming call. The remaining warning message seems to be
a benign transient.
ASTERISK-21777 #close
Reported by: Nick Ruggles
ASTERISK-24380 #close
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/4605/
........
Merged revisions 434614 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@434615 65c4cc65-6c06-0410-ace0-fbb531ad65f3
