This change adds a basic res_sorcery_memory_cache module which implements
configuration option parsing, configuration file parsing for threading,
sorcery interface implementation, and unit tests.
Objects can be added, updated, deleted, and retrieved from the memory
cache. Automatic expiration and stale handling will be added in the
future.
Note that unit tests exist within the module itself in case the
threading done as a result of expiration results in asynchronous
actions (which it likely will). Providing access and a notification
mechanism for an external test module would be complicated and
not worth it.
Jonathan Rose [Thu, 2 Jul 2015 22:03:51 +0000 (17:03 -0500)]
app: Add functions to swap vm function table
This patch adds function-mocking methods for testing voicemail
features in external modules. It is being pulled over from r432556
on SVN because DPMA won't presently compile with TEST_FRAMEWORK
set in Asterisk 13.1 certified.
George Joseph [Wed, 22 Apr 2015 21:22:10 +0000 (15:22 -0600)]
res/res_corosync: Always decline module load, instead of failing
Returns a 'failure' from the module load routine indicates to Asterisk
that it should abort loading completely. This is rarely - in fact,
really, never - a good option. Aborting load of Asterisk from a dynamic
module implies that the core, and the rest of the dynamic modules, don't
matter: we should abandon all processing.
res_corosync is really not that important.
This patch updates the module such that, if it fails to load, it
politely declines (emitting ERROR messages along the way), and allows
Asterisk to continue to function.
Note that this issue was keeping Asterisk unit tests from running on
certain build agents.
Mark Michelson [Mon, 29 Jun 2015 17:45:02 +0000 (12:45 -0500)]
res_sorcery_realtime: Fix leak of sorcery object type.
This prevents a leak of a sorcery object type when realtime sorcery
objects are retrieved by fields or when multiple objects are retrieved.
The extent of this leak is that sorcery object types would be leaked.
These are allocated whenever an object type is registered with sorcery,
meaning that on module shutdown, these objects would be leaked. This
could be problematic if many reloads were performed, but it is not as
severe as if every sorcery object retrieved from realtime were being
leaked.
Mark Michelson [Fri, 26 Jun 2015 21:12:33 +0000 (16:12 -0500)]
res_pjsip_nat: Adjust when contact should be rewritten.
A previous change made the contact only get rewritten if the dialog's
route set was not marked frozen. Unfortunately, while the intent of this
is correct, the dialog's route set actually gets marked as frozen
earlier than expected, especially for UAS dialogs.
Instead, the idea is that the contact needs to not be rewritten if there
is a pre-existing route set on the dialog. This is now accomplished by
checking the dialog's route set list instead of checking if the route
set is frozen.
Doing this causes some broken tests to begin passing again.
res_pjsip_refer will attempt to add Referred-By or Replaces headers to
outbound INVITEs at times. If the INVITE gets challenged for
authentication, then we will resend the INVITE. Prior to this patch, the
Referred-By or Replaces header would be re-added to the outbound INVITE,
resulting in duplicated headers.
Mark Michelson [Tue, 23 Jun 2015 22:43:31 +0000 (17:43 -0500)]
res_pjsip_nat: Rewrite route set when required.
When performing some provider testing, the rewrite_contact option was
interfering with proper construction of a route set when sending an ACK
after receiving a 200 OK response to an INVITE.
The initial INVITE was sent to address sip:foo. The 200 OK had a Contact
header with URI sip:bar. In addition, the 200 OK had Record-Route
headers for sip:baz and sip:foo, in that order. Since the Record-Route
headers had the lr parameter, the result should have been:
* Set R-URI of the ACK to sip:bar.
* Add Route headers for sip:foo and sip:baz, in that order.
However, the rewrite_contact option resulted in our rewriting the
Contact header on the 200 OK to sip:foo. The result was:
* R-URI remained sip:foo.
* We added Route headers for sip:foo and sip:baz, in that order.
The result was that sip:bar was not indicated in the ACK at all, so the
far end never received our ACK. The call eventually dropped.
The intention of rewrite_contact is to rewrite the most immediate
destination of our SIP request to be the same address on which we
received a request or response. In the case of processing a SIP response
with Record-Route headers, this means that instead of rewriting the
Contact header, we should instead rewrite the bottom-most Record-Route
header. In the case of processing a SIP request with Record-Route
headers, this means we rewrite the top-most Record-route header.
Like when we rewrite the Contact header, we also ensure to update
the dialog's route set if it exists.
Joshua Colp [Wed, 17 Jun 2015 10:04:39 +0000 (07:04 -0300)]
res_pjsip_mwi: Set up unsolicited MWI upon registration.
The res_pjsip_mwi previously required a reload to set up the proper
subscriptions to allow unsolicited MWI to work. This change
makes it so the act of registering will also cause this to occur.
This is particularly useful if realtime is involved as no reload
needs to occur within Asterisk to cause the MWI information
to get sent.
Joshua Colp [Wed, 10 Jun 2015 23:28:26 +0000 (20:28 -0300)]
bridge: When performing a blonde transfer update connected line information.
When performing a blonde transfer the code uses the old masquerade
mechanism to move a channel around. As a result of this certain information,
such as connected line, is moved between the channels involved. Upon
completion of the move a frame is queued which is supposed to update the
connected line information on the channel. This does not occur as the
code considers it a redundant update since the masquerade operation
updated the channel (but did not inform it of the new connected line
information). The code also does not queue a connected line update
to be handled by the thread handling the channel. Without this any
other channel that may be loosely involved does not know it is
talking to a different caller.
This change does the following to resolve this:
1. The indicated connected line information is cleared upon
completion of the masquerade operation when doing a blonde transfer.
This prevents the connected line update from being considered
redundant.
2. A connected line update frame is now queued upon the completion
of the masquerade operation so any other channel loosely involved
knows that there is a different caller.
Richard Mudgett [Thu, 11 Jun 2015 19:39:45 +0000 (14:39 -0500)]
app_directory: Fix crash when using the alias option 'a'.
The voicemail.conf mailbox key/value pair is defined as:
<mailbox>=[<password>[,<full-name>[,<email>[,<pager>[,<options>]]]]]
Where all fields in the value including the field values are optional.
Since the parsing code for the mailbox key/value pair is sloppy, this
patch tightens the parsing for the directory information.
* Renamed the 'pos' and 'bufptr' variables to 'name' and 'options'
respectively in search_directory_sub(). Those names make more sense.
* Made sure that search_directory_sub() is dealing with the voicemail.conf
mailbox options field if it even exists when looking for the 'hidefromdir'
and 'alias' options.
* Fix crash if a voicemail.conf mailbox is just
<mailbox>=<password>,<name> when the 'a' option is used. If there were no
fields after the name then the 'options' pointer was not checked for NULL.
* Fix users.conf alias processing if the 'a' option is used. The wrong
variable was used.
Kevin Harwell [Mon, 8 Jun 2015 14:43:53 +0000 (09:43 -0500)]
AMI: Escape string values.
So this issue is a bit complicated. Since it is possible to pass values to AMI
that contain a '\r\n' (or other similar sequences) these values need to be
escaped. One way to solve this is to escape the values and then pass the escaped
values to the AMI variable parameter string building function. However, this
puts the onus on the pre-build function to escape all string values. This
potentially requires a fair amount of changes along with a lot of string
allocations/freeing for all values.
Surely there is a way to push this complexity down a level into the string
building function itself? This of course is possible, but ends up requiring a
way to distinguish between strings that need to be escaped and those that don't.
The best way to handle this is by introducing a new format specifier in the
format string. For instance a %s (no escape) and %S (escape). However, that is
a bit weird and unexpected.
So faced with those possibilities this patch implements a limited version of the
first option. Instead of attempting to escape all string values this patch only
escapes those values that make sense. This approach limits the number of changes
and doesn't suffer from the odd format specifier problem.
Mark Michelson [Wed, 3 Jun 2015 22:41:23 +0000 (17:41 -0500)]
res_pjsip: Prevent access of NULL channels.
It is possible to receive incoming requests or responses after the channel
on an ast_sip_session has been destroyed and NULLed out. Handlers of these
sorts of requests or responses need to be prepared for the possibility
that the channel is NULL or else they could cause a crash.
While several places have been amended to deal with NULL channels, there
were still a couple of places that needed updating.
res_pjsip_dtmf_info.c: When handling incoming INFO requests, we need to
return early if there is no channel on the session.
res_pjsip_session.c: When handling a 302 response, we need to stop the
redirecting attempt if there is no channel on the session.
Richard Mudgett [Tue, 17 Feb 2015 15:34:10 +0000 (15:34 +0000)]
res_pjsip_refer: Fix crash from a REFER and BYE collision.
Analyzing a one-off crash on a busy system showed that processing a REFER
request had a NULL session channel pointer. The only way I can think of
that could cause this is if an outgoing BYE transaction overlapped the
incoming REFER transaction in a collision. Asterisk sends a BYE while the
phone sends a REFER to complete an attended transfer.
* Made check the session channel pointer before processing an incoming
REFER request in res_pjsip_refer.
* Fixed similar crash potential for res_pjsip supplement incoming request
processing for res_pjsip_sdp_rtp INFO, res_pjsip_caller_id INVITE/UPDATE,
res_pjsip_messaging MESSAGE, and res_pjsip_send_to_voicemail REFER
messages.
* Made res_pjsip_messaging respond to a message body too large with a 413
instead of ignoring it.
Kevin Harwell [Mon, 6 Apr 2015 19:23:57 +0000 (19:23 +0000)]
res_pjsip: config option 'timers' can't be set to 'no'
When setting the configuration option 'timers' equal to 'no' the bit flag was
not properly negated. This patch clears all associated flags and only sets the
specified one. pjsip will handle any necessary flag combinations. Also went
ahead and did similar for the '100rel' option.
ASTERISK-24910 #close
Reported by: Ray Crumrine
Review: https://reviewboard.asterisk.org/r/4582/
........
Merged revisions 434131 from http://svn.asterisk.org/svn/asterisk/branches/13
Richard Mudgett [Tue, 26 May 2015 18:56:42 +0000 (13:56 -0500)]
res_pjsip_session: Fix in-dialog authentication.
When the remote peer requires authentication for in-dialog requests then
re-INVITEs to the peer cause the call to be disconnected and other
in-dialog requests to the peer like MESSAGE just don't go through.
* Made session_inv_on_tsx_state_changed() handle in-dialog authentication
for re-INVITEs and other methods. Initial INVITEs cannot be handled here
because the INVITE transaction must be restarted earlier.
* Pulled needed code from res/res_pjsip/pjsip_outbound_auth.c in
preparation for removing the file. The generic outbound authentication
code did not work as well as anticipated.
* Created outbound_invite_auth() to only handle initial outbound INVITEs.
Re-INVITEs cannot be handled here. The re-INVITE transaction is still in
progress and the PJSIP library cannot handle the overlapping INVITE
transactions. Other method types should not be handled here as this code
only works on outgoing calls and we need to handle incoming and outgoing
calls.
ASTERISK-25131 #close
Reported by: Richard Mudgett
Jonathan Rose [Tue, 12 May 2015 22:45:09 +0000 (17:45 -0500)]
app_voicemail: fix moving when old messages full
When completing voicemail playback of a message in the 'INBOX', the
message gets moved to the 'Old' messages folder. Without this patch, if
the 'Old' folder is already at its set limit, then the 'INBOX' message will
simply be deleted. With this patch, the flag to delete the message will be
removed if the save_to_folder function indicates that the message could
not be moved due to a full folder.
ASTERISK-25082 #close
Reported by: Jonathan Rose
Review: https://gerrit.asterisk.org/#/c/448/
Richard Mudgett [Tue, 12 May 2015 22:34:45 +0000 (17:34 -0500)]
chan_dahdi/sig_pri: Fix crash on ISDN call hangup collision.
If an ISDN call is hungup by both sides at the same time a crash could
happen.
* Added missing NULL checks for the owner channel after calling
pri_queue_pvt_cause_data() in two places. Code after those calls need to
check the owner channel pointer for NULL before use because
pri_queue_pvt_cause_data() needs to do deadlock avoidance to lock the
owner and the owner may get hung up.
ASTERISK-21893 #close
Reported by: Alexandr Gordeev
Kevin Harwell [Thu, 16 Apr 2015 15:51:50 +0000 (10:51 -0500)]
bridge.c: NULL app causes crash during attended transfer
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.
Joshua Colp [Wed, 6 May 2015 18:24:29 +0000 (15:24 -0300)]
res_pjsip_exten_state: Fix race condition between sending NOTIFY and termination
The res_pjsip_exten_state module currently has a race condition between
processing the extension state callback from the PBX core and processing
the subscription shutdown callback from res_pjsip_pubsub. There is currently
no synchronization between the two. This can present a problem as while
the SIP subscription will remain valid the tree it points to may not.
This is in particular a problem as a task to send a NOTIFY may get queued
which will try to use the tree that may no longer be valid.
This change does the following to fix this problem:
1. All access to the subscription tree is done within the task that
sends the NOTIFY to ensure that no other thread is modifying or
destroying the tree. This task executes on the serializer for the
subscriptions.
2. A reference to the subscription serializer is kept to ensure it
remains valid for the lifetime of the extension state subscription.
3. The NOTIFY task has been changed so it will no longer attempt
to send a NOTIFY if the subscription has already been terminated.
Joshua Colp [Mon, 19 Jan 2015 13:18:32 +0000 (13:18 +0000)]
res_pjsip / res_pjsip_multihomed: Use the correct transport and addressing information on UAS sessions.
The first thing this patch fixes is UAS dialogs. Previously if a transport was
configured on an endpoint and an inbound session was created there was no guarantee
that requests sent on the dialog would use the correct transport and address
information. This has now been fixed so an explicitly configured transport
is taken into account.
The second thing this patch fixes is res_pjsip_multihomed. The res_pjsip_multihomed
module attempts to determine what transport a message should go out on and what
addressing information should go into the message itself. In a scenario where
multiple transports exist bound to the same IP address but a different port the
code would incorrectly alter the transport and change the message to the wrong
transport. This change makes the res_pjsip_multihomed module smarter so it will
only change the transport and address information in the message when it is
possible and makes sense.
Joshua Colp [Mon, 4 May 2015 17:16:24 +0000 (14:16 -0300)]
stasis: Fix dial masquerade datastore lifetime
A recent change went into Asterisk which added reference counts to the
channels stored in a dial masquerade datastore. Unfortunately this
included a reference to the caller in a dialing operation. While all
of the dialed targets have the datastore removed from them upon dialing
completion this did not occur for the caller, causing it to have a
reference to itself that could go never go away (as it depended on
the destruction of the datastore which only happened when the channel
was destroyed). This resulted in the caller channel remaining on the
system despite it having hung up.
This change does the following to fix this issue:
1. The dial masquerade datastore is now removed from the caller upon
dialing completion, just like the dialed targets.
2. Upon destruction of the caller all the dialed targets are also
removed from the dial masquerade datastore (just in case).
3. The reference to the caller has been removed as it should not be
possible for the datastore to now be valid/useful after the lifetime
of the caller has ended.
Richard Mudgett [Wed, 29 Apr 2015 19:29:10 +0000 (14:29 -0500)]
chan_dahdi: Add the chan_dahdi.conf force_restart_unavailable_chans option.
Some telco switches occasionally ignore ISDN RESTART requests. The fix
for ASTERISK-19608 added an escape clause for B channels in the restarting
state if the telco ignores a RESTART request. If the telco fails to
acknowledge the RESTART then Asterisk will assume the telco acknowledged
the RESTART on the second call attempt requesting the B channel by the
telco. The escape clause is good for dealing with RESTART requests in
general but it does cause the next call for the restarting B channel to be
rejected if the telco insists the call must go on that B channel.
chan_dahdi doesn't really need to issue a RESTART request in response to
receiving a cause 44 (Requested channel not available) code. Sending the
RESTART in such a situation is not required (nor prohibited) by the
standards. I think chan_dahdi does this for historical reasons to deal
with buggy peers to get channels unstuck in a similar fashion as the
chan_dahdi.conf resetinterval option.
* Add the chan_dahdi.conf force_restart_unavailable_chans compatability
option that when disabled will prevent chan_dahdi from trying to RESTART
the channel in response to a cause 44 code.
ASTERISK-25034 #close
Reported by: Richard Mudgett
Mark Michelson [Thu, 30 Apr 2015 20:20:43 +0000 (15:20 -0500)]
Prevent potential crash on blond transfer.
Scenario:
Alice calls Bob. Bob performs a blond transfer to Carol. Carol rejects
the incoming call (or some other immediate circumstance causes Carol not
to answer the call)
What occurs in this case is that when the bridge between Alice and Bob
breaks, Alice is told to masquerade into Bob's channel that had placed
the call to Carol. The actual masquerade goes down without a hitch.
However, a channel fixup callback that attempts to publish dial events
over Stasis has a crash. The reason for this crash is that the datastore
on Bob's channel that placed the outbound call to Carol only had a bare
pointer to Carol's channel. Since Carol rejected the incoming call,
Carol's channel has been hung up and freed, meaning accessing her
channel results in a crash.
The fix here is simple. The dial fixup code has been altered to hold
references to the involved channels and to drop those references when
freeing data.
The Asterisk 13 version of the fix for outbound registration was missing
a key component that set the outbound authenticator's callback that
creates an authenticated request based on an old request. This was
picked up by some outbound registration tests failing in the testsuite.
res_pjsip_outbound_registration: Fix double unref on error return.
When the PJSIP pjsip_regc_send function is invoked and an error
status returned the caller currently decrements the reference count
of the client state that it just incremented, assuming the
registration callback would not have been invoked. In practice
this is not correct. If the failure happens after the transaction
has been set up the callback will still be invoked. This will
cause the reference count to be incorrectly decremented twice, once
by the registration callback and second by the caller of
pjsip_regc_send.
This change makes it so that whether the callback is invoked or
not is known by the caller of pjsip_regc_send. Depending on
this it can know whether it is responsible for decrementing the
reference count of the client state or not.
Mark Michelson [Mon, 27 Apr 2015 21:56:31 +0000 (16:56 -0500)]
res_pjsip_outbound_registration: Don't fail on delayed processing: 13.
This is the Asterisk 13 version of a change to master that allows for
registration responses to be processed successfully potentially after
the original transaction has timed out. The main difference between this
and the master change is that the master version has API changes that
are unacceptable for 13. For 13, this is worked around by adding a new
API call that the outbound registration code uses instead.
The following is the text from the master version of this commit:
Odd behaviors have been observed during outbound registrations. The most
common problem witnessed has been one where a request with
authentication credentials cannot be created after receiving a 401
response. Other behaviors include apparently processing an incorrect SIP
response.
Inspecting the code led to an apparent issue with regards to how we
handle transactions in outbound registration code. When a response to a
REGISTER arrives, we save a pointer to the transaction and then push a
task onto the registration serializer. Between the time that we save the
pointer and push the task, it's possible for the transaction to be
destroyed due to a timeout. It's also possible for the address to be
reused by the transaction layer for a new transaction.
To allow for authentication of a REGISTER request to be authenticated
after the transaction has timed out, we now also hold a reference to the
original REGISTER request instead of the transaction. The function for
creating a request with authentication has been altered to take the
original request instead of the transaction where the original request
was sent.
When problems occur regarding outbound registrations, it currently
is difficult to debug. Most off-nominal paths had warning messages,
but sometimes we want to know what's going on before hitting the
off-nominal path. This patch adds lots of debugging output that
should give a clearer picture of what is happening with regards
to outbound registrations.
Matthew Jordan [Sat, 11 Apr 2015 15:10:34 +0000 (15:10 +0000)]
res/res_pjsip_t38: Add missing initialization of t38faxmaxdatagram
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.
Mark Michelson [Thu, 23 Apr 2015 17:54:30 +0000 (12:54 -0500)]
res_pjsip_t38: Don't crash on authenticated reinvite after originated T.38 FAX.
When Asterisk originates a channel to an application, the channel is
hung up once the application finishes executing. When the application
in question is SendFax, the Asterisk PJSIP code will attempt to reinvite
the T.38 session to audio after the FAX completes. The hangup of the
channel happens in the midst of this reinvite transaction. In most
circumstances, this works out okay because the BYE is delayed until the
reinvite transaction can complete.
However, if the reinvite that Asterisk sends receives a 401/407
response, then Asterisk's attempt to re-send the reinvite with
authentication will fail. This is because the session supplement in
res_pjsip_t38 makes the assumption that the channel on the session will
always be non-NULL. Since the channel has been hung up, though, the
channel is now NULL. Attempting to operate on the channel causes a
crash.
This patch fixes the issue by ensuring that the channel on the session
is not NULL before attempting to mess with the T.38 framehook.
This patch also contains some corrections for comments that were
incorrect and really confused me when I first started looking at the
code.
Mark Michelson [Wed, 15 Apr 2015 15:38:02 +0000 (10:38 -0500)]
Detect potential forwarding loops based on count.
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
Matt Jordan [Mon, 13 Apr 2015 14:54:18 +0000 (09:54 -0500)]
build_tools/make_version: Update version parsing for Git migration
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.
Matt Jordan [Sun, 12 Apr 2015 17:59:22 +0000 (12:59 -0500)]
git migration: Remove support for file versions
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.
Matt Jordan [Sun, 12 Apr 2015 04:22:59 +0000 (23:22 -0500)]
.gitignore: Ignore tarballs (*.gz)
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.
res_pjsip_mwi: Send unsolicited MWI NOTIFY on startup and when endpoint registers.
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.
Jonathan Rose [Wed, 8 Apr 2015 18:19:26 +0000 (18:19 +0000)]
res_pjsip_t38: Fix FAX failures when using PJSIP with authentication
Without this patch, if a PJSIP endpoint with udptl enabled and authentication
set attempted to use sendFax, the FAX session would fail during setup. This
was because the invite issued in response to being auth challenged would cause
the PJSIP channel performing the FAX to receive a second T38 framehook and
this would cause frames to be consumed in an inappropriate manner.
ASTERISK-24933 #close
Reported by: Jonathan Rose
Review: https://reviewboard.asterisk.org/r/4577/
........
Merged revisions 434425 from http://svn.asterisk.org/svn/asterisk/branches/13
Jonathan Rose [Wed, 8 Apr 2015 17:24:23 +0000 (17:24 +0000)]
Security/tcptls: MitM Attack potential from certificate with NULL byte in CN.
When registering to a SIP server with TLS, Asterisk will accept CA signed
certificates with a common name that was signed for a domain other than the
one requested if it contains a null character in the common name portion of
the cert. This patch fixes that by checking that the common name length
matches the the length of the content we actually read from the common name
segment. Some certificate authorities automatically sign CA requests when
the requesting CN isn't already taken, so an attacker could potentially
register a CN with something like www.google.com\x00www.secretlyevil.net
and have their certificate signed and Asterisk would accept that certificate
as though it had been for www.google.com - this is a security fix and is
noted in AST-2015-003.
ASTERISK-24847 #close
Reported by: Maciej Szmigiero
Patches:
asterisk-null-in-cn.patch submitted by mhej (license 6085)
........
Merged revisions 434337 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 434338 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 434384 from http://svn.asterisk.org/svn/asterisk/branches/13
Outbound SIP MESSAGEs had the potential to be sent out
of order from how they were specified in a set of
dialplan steps.
This change creates a serializer for sending outbound
MESSAGE requests on. This ensures that the MESSAGEs are
sent by Asterisk in the same order that they were sent
from the dialplan.
Mark Michelson [Wed, 1 Apr 2015 20:32:52 +0000 (20:32 +0000)]
core: avoid possible asterisk -r crash from long id
When connecting to the remote console, an id string
is first provided that consts of the hostname, pid,
and version. This is parsed by the remote instance
using a buffer that may be too short, and can allow
a buffer overrun because it is not terminated. This
patch adds termination and a larger buffer.
Review: https://reviewboard.asterisk.org/r/4182/
AFS-254
........
Merged revisions 429223 from http://svn.asterisk.org/svn/asterisk/branches/13
Ashley Sanders [Tue, 31 Mar 2015 22:34:48 +0000 (22:34 +0000)]
stasis: set a channel variable on websocket disconnect error
When an error occurs while writing to a web socket, the web socket is
disconnected and the event is logged. A side-effect of this, however, is that
any application on the other side waiting for a response from Stasis is left
hanging indefinitely (as there is no mechanism presently available for
notifying interested parties about web socket error states in Stasis).
To remedy this scenario, this patch introduces a new channel variable:
STASISSTATUS.
The possible values for STASISSTATUS are:
SUCCESS - The channel has exited Stasis without any failures
FAILED - Something caused Stasis to croak. Some (not all) possible
reasons for this:
- The app registry is not instantiated;
- The app requested is not registered;
- The app requested is not active;
- Stasis couldn't send a start message
ASTERISK-24802
Reported By: Kevin Harwell
Review: https://reviewboard.asterisk.org/r/4519/
........
Merged revisions 433839 from http://svn.asterisk.org/svn/asterisk/branches/13
Mark Michelson [Fri, 27 Mar 2015 20:55:41 +0000 (20:55 +0000)]
Add stateful PJSIP response API call, and use it for out-of-dialog responses.
Asterisk had an issue where retransmissions of MESSAGE requests resulted in
Asterisk processing the retransmission as if it were a new MESSAGE request.
This patch fixes the issue by creating a transaction in PJSIP on the incoming
request. This way, if a retransmission arrives, the PJSIP transaction layer
will resend the response and Asterisk will not ever see the retransmission.
Richard Mudgett [Fri, 20 Mar 2015 19:57:58 +0000 (19:57 +0000)]
Audit ast_pjsip_rdata_get_endpoint() usage for ref leaks.
Valgrind found some memory leaks associated with
ast_pjsip_rdata_get_endpoint(). The leaks would manifest when sending
responses to OPTIONS requests, processing MESSAGE requests, and
res_pjsip supplements implementing the incoming_request callback.
* Fix ast_pjsip_rdata_get_endpoint() endpoint ref leaks in
res/res_pjsip.c:supplement_on_rx_request(),
res/res_pjsip/pjsip_options.c:send_options_response(),
res/res_pjsip_messaging.c:rx_data_to_ast_msg(), and
res/res_pjsip_messaging.c:send_response().
* Eliminated RAII_VAR() use with ast_pjsip_rdata_get_endpoint() in
res/res_pjsip_nat.c:nat_on_rx_message().
* Fixed inconsistent but benign return value in
res/res_pjsip/pjsip_options.c:options_on_rx_request().
Richard Mudgett [Tue, 17 Mar 2015 21:56:23 +0000 (21:56 +0000)]
Audit ast_sockaddr_resolve() usage for memory leaks.
Valgrind found some memory leaks associated with ast_sockaddr_resolve().
Most of the leaks had already been fixed by earlier memory leak hunt
patches. This patch performs an audit of ast_sockaddr_resolve() and found
one more.
* Fix ast_sockaddr_resolve() memory leak in
apps/app_externalivr.c:app_exec().
* Made main/netsock2.c:ast_sockaddr_resolve() always set the addrs
parameter for safety so the pointer will never be uninitialized on return.
The same goes for res/res_pjsip_acl.c:extract_contact_addr().
* Made functions that call ast_sockaddr_resolve() with RAII_VAR()
controlling the addrs variable use ast_free instead of ast_free_ptr to
provide better MALLOC_DEBUG information.
Kevin Harwell [Tue, 17 Mar 2015 18:44:48 +0000 (18:44 +0000)]
res_pjsip: Allow configuration of endpoint identifier query order
Updated some documentation stating that endpoint identifiers registered without
a name are place at the front of the lookup list. Also renamed register method
'ast_sip_register_endpoint_identifier_by_name' to
'ast_sip_register_endpoint_identifier_with_name'
ASTERISK-24840
Reported by: Mark Michelson
........
Merged revisions 433031 from http://svn.asterisk.org/svn/asterisk/branches/13
Kevin Harwell [Tue, 17 Mar 2015 18:43:03 +0000 (18:43 +0000)]
res_pjsip: Allow configuration of endpoint identifier query order
This patch fixes previously reverted code that caused binary incompatibility
problems with some modules. And like the original patch it makes sure that
no matter what order the endpoint identifier modules were loaded, priority is
given based on the ones specified in the new global 'endpoint_identifier_order'
option.
ASTERISK-24840
Reported by: Mark Michelson
Review: https://reviewboard.asterisk.org/r/4489/
........
Merged revisions 433028 from http://svn.asterisk.org/svn/asterisk/branches/13
In this collection of small patches to prevent
Valgrind errors are: fixes for reference leaks
in config hooks, evaluating a parameter beyond
bounds, and accessing a structure after a lock
where it could have been already free'd.
Review: https://reviewboard.asterisk.org/r/4407/
........
r433005 | rmudgett | 2015-03-17 11:10:39 -0500 (Tue, 17 Mar 2015) | 1 line
res_pjsip: Add reason comment.
........
Merged revisions 431583,433005 from http://svn.asterisk.org/svn/asterisk/branches/13
Kevin Harwell [Mon, 9 Mar 2015 16:44:31 +0000 (16:44 +0000)]
res_pjsip: Allow configuration of endpoint identifier query order
It's possible to have a scenario that will create a conflict between endpoint
identifiers. For instance an incoming call could be identified by two different
endpoint identifiers and the one chosen depended upon which identifier module
loaded first. This of course causes problems when, for example, the incoming
call is expected to be identified by username, but instead is identified by ip.
This patch adds a new 'global' option to res_pjsip called
'endpoint_identifier_order'. It is a comma separated list of endpoint
identifier names that specifies the order by which identifiers are processed
and checked.
ASTERISK-24840 #close
Reported by: Mark Michelson
Review: https://reviewboard.asterisk.org/r/4455/
........
Merged revisions 432638 from http://svn.asterisk.org/svn/asterisk/branches/13
Matthew Jordan [Wed, 4 Mar 2015 18:53:40 +0000 (18:53 +0000)]
translate: Prevent invalid memory accesses on fast shutdown
When a 'core restart now' or 'core stop now' is executed and a channel is
currently in a media operation, the translator matrix can be destroyed while a
channel is currently blocked on getting the best translation choice
(see ast_translator_best_choice). When the channel gets the mutex, the
translation matrix now has invalid memory, and Asterisk crashes.
This patch does two things:
(1) We now only clean up the translation matrix on a graceful shutdown. In that
case, there are no channels, and so there is no risk of this occurring.
(2) We also now set the __matrix and __indextable to NULL. In some initial
backtraces when this occurred, it looked as if there was a memory corruption
occurring, and it wasn't until we determined that something had restarted
Asterisk that the issue became clear. By setting these to NULL on shutdown,
it becomes a bit easier to determine why a crash is occurring.
Note that we could litter the code with NULL checks on the __matrix, but the
act of making the translation matrix cleaned up on shutdown should preclude
this issue from occurring in the first place, and this part of the code needs
to be as fast as possible.
Matthew Jordan [Mon, 2 Mar 2015 19:15:40 +0000 (19:15 +0000)]
res/res_pjsip_sdp_rtp: Revert portion of r432195
Unfortunately, while initial testing with ConfBridge did not reproduce the
audio problem alluded to in the comment in res_pjsip_sdp_rtp, further testing
did show that bridge_softmix and/or ConfBridge has a severe problem bridging
two or more participants at different sampling rates. Sometimes, it even picks
odd sampling rates that cause hideous audio problems.
This patch backs out the offending portion of the code until the issues in
the affected bridging modules can be more properly analyzed.
ASTERISK-24841
........
Merged revisions 432423 from http://svn.asterisk.org/svn/asterisk/branches/13
Matthew Jordan [Tue, 24 Feb 2015 22:01:09 +0000 (22:01 +0000)]
ARI/PJSIP: Apply requesting channel's format cap to created channels
This patch addresses the following problems:
* ari/resource_channels: In ARI, we currently create a format capability
structure of SLIN and apply it to the new channel being created. This was
originally done when the PBX core was used to create the channel, as there
was a condition where a newly created channel could be created without any
formats. Unfortunately, now that the Dial API is being used, this has two
drawbacks:
(a) SLIN, while it will ensure audio will flows, can cause a lot of
needless transcodings to occur, particularly when a Local channel is
created to the dialplan. When no format capabilities are available, the
Dial API handles this better by handing all audio formats to the requsted
channels. As such, we defer to that API to provide the format
capabilities.
(b) If a channel (requester) is causing this channel to be created, we
currently don't use its format capabilities as we are passing in our own.
However, the Dial API will use the requester channel's formats if none
are passed into it, and the requester channel exists and has format
capabilities. This is the "best" scenario, as it is the most likely to
create a media path that minimizes transcoding.
Fixing this simply entails removing the providing of the format capabilities
structure to the Dial API.
* chan_pjsip: Rather than blindly picking the first format in the format
capability structure - which actually *can* be a video or text format - we
select an audio format, and only pick the first format if that fails. That
minimizes the weird scenario where we attempt to transcode between video/audio.
* res_pjsip_sdp_rtp: Applied the joint capapbilites to the format structure.
Since ast_request already limits us down to one format capability once the
format capabilities are passed along, there's no reason to squelch it here.
* channel: Fixed a comment. The reason we have to minimize our requested
format capabilities down to a single format is due to Asterisk's inability
to convey the format to be used back "up" a channel chain. Consider the
following:
That is, we have PJSIP/A dialing a Local channel, where the Local;2 dials
PJSIP/B. PJSIP/A has native format capabilities g722,ulaw,alaw; the Local
channel has inherited those format capabilities down the line; PJSIP/B
supports only ulaw. According to these format capabilities, ulaw is
acceptable and should be selected across all the channels, and no
transcoding should occur. However, there is no way to convey this: when L;2
and PJSIP/B are put into a bridge, we will select ulaw, but that is not
conveyed to PJSIP/A and L;1. Thus, we end up with:
PJSIP/A <=> L;1 <=> L;2 <=> PJSIP/B
g g X u u
Which causes g722 to be written to PJSIP/B.
Even if we can convey the 'ulaw' choice back up the chain (which through
some severe hacking in Local channels was accomplished), such that the chain
looks like:
PJSIP/A <=> L;1 <=> L;2 <=> PJSIP/B
u u u u
We have no way to tell PJSIP/A's *channel driver* to Answer in the SDP back
with only 'ulaw'. This results in all the channel structures being set up
correctly, but PJSIP/A *still* sending g722 and causing the chain to fall
apart.
There's a lot of difficulty just in setting this up, as there are numerous
race conditions in the act of bridging, and no clean mechanism to pass the
selected format backwards down an established channel chain. As such, the
best that can be done at this point in time is clarifying the comment.
Review: https://reviewboard.asterisk.org/r/4434/
ASTERISK-24812 #close
Reported by: Matt Jordan
........
Merged revisions 432195 from http://svn.asterisk.org/svn/asterisk/branches/13
Kevin Harwell [Wed, 11 Feb 2015 18:04:09 +0000 (18:04 +0000)]
res_pjsip: dtls_handler causes Asterisk to crash
There have been a couple of times where a crash occurred in the dtls_handler
section of the code for res_pjsip. Unfortunately, in working this issue the
problem was unable to be reproduced. After looking at the backtraces and
through the code the current best guess as to why this happened might be due
to a reentrance problem and the strtok function. So, the current fix is to
convert the strtok function into the reentrant version of the function,
strtok_r.
Kevin Harwell [Wed, 11 Feb 2015 17:52:35 +0000 (17:52 +0000)]
res_http_websocket: websocket write timeout fails to fully disconnect
When writing to a websocket if a timeout occurred the underlying socket did not
get closed/disconnected. This patch makes sure the websocket gets disconnected
on a write timeout. Also a notice is logged stating that the websocket was
disconnected.
ASTERISK-24701 #close
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/4412/
........
Merged revisions 431669 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 431670 from http://svn.asterisk.org/svn/asterisk/branches/13
Richard Mudgett [Wed, 11 Feb 2015 17:48:10 +0000 (17:48 +0000)]
HTTP: Stop accepting requests on final system shutdown.
There are three CLI commands to stop and restart Asterisk each.
1) core stop/restart now - Hangup all calls and stop or restart Asterisk.
New channels are prevented while the shutdown request is pending.
2) core stop/restart gracefully - Stop or restart Asterisk when there are
no calls remaining in the system. New channels are prevented while the
shutdown request is pending.
3) core stop/restart when convenient - Stop or restart Asterisk when there
are no calls in the system. New calls are not prevented while the
shutdown request is pending.
ARI has made stopping/restarting Asterisk more problematic. While a
shutdown request is pending it is desirable to continue to process ARI
HTTP requests for current calls. To handle the current calls while a
shutdown request is pending, a new committed to shutdown phase is needed
so ARI applications can deal with the calls until the system is fully
committed to shutdown.
* Added a new shutdown committed phase so ARI applications can deal with
calls until the final committed to shutdown phase is reached.
* Made refuse new HTTP requests when the system has reached the final
system shutdown phase. Starting anything while the system is actively
releasing resources and unloading modules is not a good thing.
* Split the bridging framework shutdown to not cleanup the global bridging
containers when shutting down in a hurry. This is similar to how other
modules prevent crashes on rapid system shutdown.
* Moved ast_begin_shutdown(), ast_cancel_shutdown(), and
ast_shutting_down(). You should not have to include channel.h just to
access these system functions.
Kevin Harwell [Wed, 11 Feb 2015 16:19:35 +0000 (16:19 +0000)]
pjsip_options: Fix continued qualifies after endpoint/aor deletion
If you remove an endpoint/aor from pjsip.conf then do a core reload,
qualifies will continue even though the object are gone. This happens
because nothing clears out the qualify tasks.
This patch unschedules all existing qualify tasks before scheduling
new ones on reload.
Tested-by: George Joseph
Review: https://reviewboard.asterisk.org/r/4290/
........
Merged revisions 430064 from http://svn.asterisk.org/svn/asterisk/branches/13
Richard Mudgett [Fri, 30 Jan 2015 17:53:54 +0000 (17:53 +0000)]
app_agent_pool: Fix initial module load agent device state reporting.
When the app_agent_pool module initially loads there is a race condition
between the thread loading agents.conf and the device state internal
processing thread. If the device state internal processing thread handles
the agent creation state updates before the thread that loaded agents.conf
registers the device state provider callback then the cached agent state
is "Invalid". When a consumer module like app_queue asks for the agent state
it gets the cached "Invalid" state instead of the real state from the provider.
* Moved loading the agents.conf configuration to the last thing setup by
app_agent_pool in load_module(). Now the device state provider callback
is registered before the config is loaded so the agent creation state
updates are guaranteed to get the initial device state.
* Removed some now redundant config cleanup on error in load_config().
* Added lock protection when accessing the device state in
agent_pvt_devstate_get() and eliminated the RAII_VAR() usage.
Manager: Fix Manager Action ModuleLoad to give correct response when reloading
Prior to this patch, ModuleLoad would respond with an error indicating that
the requested module wasn't found in spite of finding and reloading the
module.
Mitigate possible HTTP injection attacks using CURL() function in Asterisk.
CVE-2014-8150 disclosed a vulnerability in libcURL where HTTP request injection
can be performed given properly-crafted URLs.
Since Asterisk makes use of libcURL, and it is possible that users of Asterisk may
get cURL URLs from user input or remote sources, we have made a patch to Asterisk
to prevent such HTTP injection attacks from originating from Asterisk.
Mark Michelson [Wed, 28 Jan 2015 21:30:40 +0000 (21:30 +0000)]
Fix file descriptor leak in RTP code.
SIP requests that offered codecs incompatible with configured values
could result in the allocation of RTP and RTCP ports that would not get
reclaimed later.
ASTERISK-24666 #close
Reported by Y Ateya
Review: https://reviewboard.asterisk.org/r/4323
AST-2015-001
........
Merged revisions 431300 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 431303 from http://svn.asterisk.org/svn/asterisk/branches/13
Performing a CLI "module reload" command when there are new pjsip.conf
registration objects defined frequently failed to load them correctly.
What happens is a race condition between res_pjsip pushing its reload into
an asynchronous task processor task and the thread that does the rest of
the reloads when it gets to reloading the res_pjsip_outbound_registration
module. A similar race condition happens between a reload and the CLI/AMI
show registrations commands. The reload updates the current_states
container and the CLI/AMI commands call get_registrations() which builds a
new current_states container.
* Made res_pjsip.c reload_module() use ast_sip_push_task_synchronous()
instead of ast_sip_push_task() to eliminate two threads processing config
reloads at the same time.
* Made get_registrations() not replace the global current_states container
so the CLI/AMI show registrations command cannot interfere with reloading.
You could never add/remove objects in the container without the
possibility of the container being replaced out from under you by
get_registrations().
* Added a registration loaded sorcery instance observer to purge any dead
registration objects since get_registrations() cannot do this job anymore.
The struct ast_sorcery_instance_observer callbacks must be used because
the callback happens inline with the load process. The struct
ast_sorcery_observer callbacks are pushed to a different thread.
* Added some global current_states NULL pointer checks in case the
container disappears because of unload_module().
* Made sorcery's struct ast_sorcery_instance_observer.object_type_loaded
callbacks guaranteed to be called before any struct
ast_sorcery_observer.loaded callbacks will be called.
* Moved the check for non-reloadable objects to before the sorcery
instance loading callbacks happen to short circuit unnecessary work.
Previously with non-reloadable objects, the sorcery instance
loading/loaded callbacks would always happen, the individual wizard
loading/loaded would be prevented, and the non-reloadable type logging
message would be logged for each associated wizard.
Kevin Harwell [Tue, 27 Jan 2015 23:02:42 +0000 (23:02 +0000)]
tcptls: Bad file descriptor error when reloading chan_sip
While running through some scenarios using chan_sip and tcp a problem would
occur that resulted in a flood of bad file descriptor messages on the cli:
tcptls.c:712 ast_tcptls_server_root: Accept failed: Bad file descriptor
The message is received because the underlying socket has been closed, so is
valid. This is probably happening because unloading of chan_sip is not atomic.
That however is outside the scope of this patch. This patch simply stops the
logging of multiple occurrences of that message.
ASTERISK-24728 #close
Reported by: Thomas Thompson
Review: https://reviewboard.asterisk.org/r/4380/
........
Merged revisions 431218 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 431219 from http://svn.asterisk.org/svn/asterisk/branches/13
Kevin Harwell [Tue, 27 Jan 2015 19:25:15 +0000 (19:25 +0000)]
chan_sip: stale nonce causes failure
When refreshing (with a small expiration) a registration that was sent to
chan_sip the nonce would be considered stale and reject the registration.
What was happening was that the initial registration's "dialog" still existed
in the dialogs container and upon refresh the dialog match algorithm would
choose that as the "dialog" instead of the newly created one. This occurred
because the algorithm did not check to see if the from tag matched if
authentication info was available after the 401. So, it ended up assuming
the original "dialog" was a match and stopped the search. The old "dialog"
of course had an old nonce, thus the stale nonce message.
This fix attempts to leave the original functionality alone except in the case
of a REGISTER. If a REGISTER is received if searches for an existing "dialog"
matching only on the callid. If the expires value is low enough it will reuse
dialog that is there, otherwise it will create a new one.
ASTERISK-24715 #close
Reported by: John Bigelow
Review: https://reviewboard.asterisk.org/r/4367/
........
Merged revisions 431187 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 431194 from http://svn.asterisk.org/svn/asterisk/branches/13
Richard Mudgett [Tue, 27 Jan 2015 17:52:09 +0000 (17:52 +0000)]
app_confbridge: Repeatedly starting and stopping recording ref leaks the recording channel.
Starting and stopping conference recording more than once causes the
recording channels to be leaked. For v13 the channels also show up in the
CLI "core show channels" output.
* Reworked and simplified the recording channel code to use
ast_bridge_impart() instead of managing the recording thread in the
ConfBridge code. The recording channel's ref handling easily falls into
place and other off nominal code paths get handled better as a result.
Joshua Colp [Tue, 27 Jan 2015 17:35:36 +0000 (17:35 +0000)]
bridge / res_pjsip_sdp_rtp: Fix issues with media not being reinvited during direct media.
This change fixes two issues:
1. During a swap operation bridging added the new channel before having the swap channel
leave. This was not handled in bridge_native_rtp and could result in a channel not getting
reinvited back to Asterisk. After this change the swap channel will leave first and the
new channel will then join.
2. If a re-invite was received after a session had been established any upstream elements
(such as bridge_native_rtp) were not notified that they may want to re-evaluate things.
After this change an UPDATE_RTP_PEER control frame is queued when this situation occurs
and upstream can react.
Matthew Jordan [Tue, 27 Jan 2015 17:18:46 +0000 (17:18 +0000)]
app_confbridge: Restore user's menu name to CLI output of 'confbridge list'
When issuing a 'confbridge list XXXX' CLI command, the resulting output no
longer displays the menu associated with a ConfBridge participant.
The issue was caused by ASTERISK-22760. When that patch was done, it removed
the copying of the menu name associated with the user from the actual user
profile.
This patch fixes the issue by copying the menu name over to the user profile
when the menu hooks are applied to the user. Since that function now does a
little bit more than just apply the hooks, the name of the function has been
changed to cover the copying of the menu name over as well.
In addition, there is a disparity between the menu name length as it is stored
on the conf_menu structure and the confbridge_user structure; this patch makes
the lengths match so that a strcpy can be used.
Review: https://reviewboard.asterisk.org/r/4372/
ASTERISK-24723 #close
Reported by: Steve Pitts
........
Merged revisions 431134 from http://svn.asterisk.org/svn/asterisk/branches/13
Joshua Colp [Tue, 27 Jan 2015 11:48:31 +0000 (11:48 +0000)]
res_parking: Fix crash due to race condition when unloading.
There is currently a race condition when unloading the res_parking
module. Depending on the will of the universe the subscription
invocation may occur AFTER the module is unloaded. This is because
the module does NOT use stasis_unsubscribe_and_join when terminating
the subscription. It merely uses stasis_unsubscribe.
This change makes it use stasis_unsubscribe_and_join which is documented
for usage in this exact scenario.
outbound_registration: Add 'pjsip send register' and update 'send unregister'
The current behavior of 'pjsip send unregister' is to send the unregister
(REGISTER with 0 exp) but let the next scheduled register proceed normally.
I don't think that's a good idea. If you unregister, it should stay
unregistered until you decide to start registrations again. So this patch
just adds a cancel_registration call to the current unregister_task to
cancel the timer.
Of course, now you need a way to start registration again so I've added
a 'pjsip send register' command that unregisters and cancels any existing
registration (the same as send unregister), then sends an immediate
registration and starts the timer back up again.
Both changes also ripple to AMI. There's a new PJSIPRegister command.
There's no harm in calling either command repeatedly. They don't care
about the actual state.
Tested-by: George Joseph
Review: https://reviewboard.asterisk.org/r/4301/
........
r430373 | gtjoseph | 2015-01-08 11:48:29 -0600 (Thu, 08 Jan 2015) | 25 lines
res_pjsip_outbound_registration: Fix several reload issues
There are 2 issues with reloading registrations...
1. The 'can_reuse_registration' test wasn't considering the intervals or
expiration in its determination of whether a registration changed or not so if
you changed any of the intervals or the expiration and reloaded, the object
would get reloaded but the actual timers wouldn't change.
can_reuse_registration now does a sorcery diff on the old and new objects
instead of discretely testing certain fields. Now if you change expiration for
instance, and reload, the timer is updated and re-registration will occur on the
new value.
2. If you mung up your password on an outbound registration you get a permanent
failure. If you fix the password (on the outbound_auth object) and reload,
nothing tells outbound_registration to try again because the registration itself
didn't change. This patch adds an observer on the "auth" object type and if any
auth changes, existing registration states are searched and those in a
REJECTED_PERMANENT state are retried.
Tested-by: George Joseph
Review: https://reviewboard.asterisk.org/r/4304/
........
r430395 | gtjoseph | 2015-01-08 15:37:42 -0600 (Thu, 08 Jan 2015) | 14 lines
Every time a registration started, sip_outbound_registration_response_cb bumps
the ref count on client_state then pushes a handle_registration_response task.
handle_registration_response never unreffed it though. So every time a
registration goes out, the ref count goes up by one.
This patch adds the unreffs to handle_registration_response.
Tested-by: George Joseph
Review: https://reviewboard.asterisk.org/r/4303/
........
Merged revisions 430223,430373,430395 from http://svn.asterisk.org/svn/asterisk/branches/13
Matthew Jordan [Wed, 21 Jan 2015 13:36:31 +0000 (13:36 +0000)]
channels/chan_sip: Fix registration leak during reload
When the SIP registrations were migrated to using ao2 in what was then trunk,
the explicit destruction of the registrations on module reload was removed and
not replaced with an ao2 equivalent. Debugging done by Stefan Engström, the
issue reporter, on ASTERISK-24673 confirmed that the reference in the
registry_list container was being leaked.
Since the purpose of cleanup_all_regs is to prep a registration for
destruction, this function now calls an ao2_callback function callback with the
OBJ_MULTIPLE | OBJ_NODATA | OBJ_UNLINK flags used to remove the registrations.
This cleans up each registration, and also removes it from the registration
container registry_list.
Review: https://reviewboard.asterisk.org/r/4355/
ASTERISK-24640 #close
Reported by: Max Man
ASTERISK-24673 #close
Reported by: Stefan Engström
Tested by: Stefan Engström
........
Merged revisions 430864 from http://svn.asterisk.org/svn/asterisk/branches/13
Matthew Jordan [Wed, 21 Jan 2015 13:11:48 +0000 (13:11 +0000)]
apps/app_dial: Don't publish DialEnd twice on unexpected GoSub/Macro values
The Dial application has some interesting options with the mid-call Macro (M)
and GoSub (U) options. If the MACRO_RESULT/GOSUB_RESULT returns specific
values, the Dial application will take some action upon the channels involved
in the dial operation (such as hanging up a particular party, etc.) The Dial
application ensures that a Stasis message is published in the event that
MACRO_RESULT/GOSUB_RESULT returns a value that kills the dial operation, so
that there is a corresponding DialEnd event published in AMI/ARI for the
DialBegin event that preceeded it.
A bug exists where that same DialEnd event will be published on Stasis even if
the value returned in MACRO_RESULT/GOSUB_RESULT is not one that the Dial
application cares about. This causes two DialEnd events to be published - one
with the MACRO_RESULT/GOSUB_RESULT and another with "ANSWERED" - which is all
sorts of wrong.
This patch fixes the bug by ensuring that we only publish a DialEnd message to
Stasis if the Dial application's mid-call Macro/GoSub returns something that
Dial cares about.
Review: https://reviewboard.asterisk.org/r/4336
ASTERISK-24682 #close
Reported by: Matt Jordan
........
Merged revisions 430842 from http://svn.asterisk.org/svn/asterisk/branches/13
projects / thirdparty / asterisk.git / log
