A module trying to unload needs to wait for all serializers it creates and
uses to complete processing before unloading.
ASTERISK-24907
Reported by: Kevin Harwell
Change-Id: I8c80b90f2f82754e8dbb02ddf3c9121e5e966059
* handle_client_state_destruction() must always be passed a ref to
client_state because it will always unref client_state.
handle_registration_response() was not passing a client_state ref.
* Made the final un-REGISTER message get sent normally using the pjproject
register control structure in handle_client_state_destruction(). The
previous code attempted to short circuit the response handling for the
module to unload. That doesn't work for a couple reasons. One,
pjsip_regc_send() may call the registered callback before it returns and
unbalance the client_state ref count. Two, the registered callback
handles any authentication for the un-REGISTER message.
* Made the distinction between internal registration state and external
registration status with sip_outbound_registration_status_str(). This is
necessary to avoid altering documented AMI messages with internal
changes.
* Removed references to client_state->client outside of the serializer
thread. When handle_client_state_destruction() destroys the pjproject
register control structure that memory is freed and cannot be referenced
anymore. These accesses were to provide information for debug and
off-nominal warning messages.
* In sip_outbound_registration_timer_cb() you should not access entry->id
after unrefing client_state because the passed in entry is normally
pointing to the timer entry in the client_state object.
ASTERISK-24907
Reported by: Kevin Harwell
Change-Id: Ia7b446d8644b6b4550ef5bea49527671de65183f
The sorcery pjsip 'registration' config object needs to be destroyed on
module unload. Otherwise, a reload of res_pjsip could try to use
callbacks for a previously unloaded instance of the module provided by
ast_sorcery_object_register() or one of the variants. Also, if
res_pjsip_outbound_registration were subsequently reloaded, the sorcery
config field objects would be registered in sorcery twice.
ASTERISK-24907
Reported by: Kevin Harwell
Change-Id: I304fad13dece2604af48353f6c6d9d5c7b064697
Find and unlink the specified sorcery object type to complement
ast_sorcery_object_register(). Without this function you cannot
completely unload individual modules that use sorcery for configuration.
ASTERISK-24907
Reported by: Kevin Harwell
Change-Id: I1c04634fe9a90921bf676725c7d6bb2aeaab1c88
It is best if the loading code creates and initializes the module's
infrastructure before letting the system know of its existence. The
unloading code needs to reverse the actions of the loading code and in the
reverse order.
ASTERISK-24907
Reported by: Kevin Harwell
Change-Id: I5d151383e9787b5b60aa5e1627b10f040acdded4
Added checks when a unit test is registered to see that the summary and
description strings do not end with a new-line '\n' for consistency.
The check generates a warning message and will cause the
/main/test/registrations unit test to fail.
* Updated struct ast_test_info member doxygen comments.
Change-Id: I295909b6bc013ed9b6882e85c05287082497534d
Analyzing the code shows that the unit test summary and description
strings should not end with a new-line character. Where these strings are
used in the code a new-line is provided for output.
Change-Id: I129284f5e7ca93d82532334076da4c462d3d9fba
Currently when requesting a channel the native formats of the
calling channel are provided to the core for usage when dialing
the outbound channel. This occurs without holding the channel lock
or keeping a reference to the formats. This is problematic as
the channel driver may end up changing the formats during this time.
In the case of chan_sip this happens when an SDP negotiation
completes.
This change makes it so app_dial keeps a reference to the native
formats of the calling channel which guarantees that they will
remain valid for the period of time needed.
ASTERISK-25172 #close
Change-Id: I2f0a67bd0d5d14c3bdbaae552b4b1613a283f0db
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.
ASTERISK-25180 #close
Change-Id: Id847b47de4b8b3ab8858455ccc2f07b0f915f252
After completing an attended transfer the transfer target channel was not being
hung up after leaving the bridge. Added an explicit softhangup to hangup said
channel, but only if it was previously bridged.
ASTERISK-24782 #close
Reported by: John Bigelow
Change-Id: Idde9543d56842369384a5e8c00d72a22bbc39ada
On reload, previously allowed codecs were not removed. Therefore, it was not
possible to remove codecs while Asterisk was running. Furthermore, newly added
codecs got appended behind the previous codecs. Therefore, it was not possible
to add a codec with a priority of #1. This change removes the old capabilities
before the current ones are added.
ASTERISK-25182 #close
Reported by: Alexander Traud
patches:
asterisk_13_allow_codec_reload.patch uploaded by Alexander Traud (License 6520)
Change-Id: I62a06bcf15e08e8c54a35612195f97179ebe5802
Due to the use of stasis_unsubscribe_and_join in the peer destructor
it is possible for a deadlock to occur when an event callback is
occurring at the same time.
This happens because the peer may be destroyed while holding the
peers container lock. If this occurs the event callback will never
be able to acquire the container lock and the unsubscribe will
never complete.
This change makes it so the peers that have been removed from the
peers container are not destroyed with the container lock held.
ASTERISK-25163 #close
Change-Id: Ic6bf1d9da4310142a4d196c45ddefb99317d9a33
This resolves two observed race conditions.
First, a bit of background on what the Stasis application does:
1a Creates a stasis_app_control structure. This structure is linked into
a global container and can be looked up using a channel's unique ID.
2a Puts the channel in an event loop. The event loop can exit either
because the stasis_app_control structure has been marked done, or
because of some other factor, such as a hangup. In the event loop, the
stasis_app_control determines if any specific ARI commands need to be
run on the channel and will run them from this thread.
3a Checks if the channel is bridged. If the channel is bridged, then
ast_bridge_depart() is called since channels that are added to Stasis
bridges are always imparted as departable.
4a Unlink the stasis_app_control from the container.
When an ARI command is received by Asterisk, the following occurs
1b A thread is spawned to handle the HTTP request
2b The stasis_app_control(s) that corresponds to the channel(s) in the
request is/are retrieved. If the stasis_app_control cannot be
retrieved, then it is assumed that the channel in question has exited
the Stasis app or perhaps was never in Stasis in the first place.
3b A command is queued onto the stasis_app_control, and the channel's
event loop thread is signaled to run the command.
4b While most ARI commands do nothing further, some, such as adding or
removing channels from a bridge, will block until the command they
issued has been completed by the channel's event loop.
The first race condition that is solved by this patch involves a crash
that can occur due to faulty detection of the channel's bridged status
in step 3a. What can happen is that in step 2a, the event loop may run
the ast_bridge_impart() function to asynchronously place the channel
into a bridge, then immediately exit the event loop because the channel
has hung up. In step 3a, we would detect that the channel was not
bridged and would not call ast_bridge_depart(). The reason that the
channel did not appear to be bridged was that the depart_thread that is
spawned by ast_bridge_impart() had not yet started. That is the thread
where the channel is marked as being bridged. Since we did not call
ast_bridge_depart(), the Stasis application would exit, and then the
channel would be destroyed Then the depart_thread would start up and
try to manipulate the destroyed channel, causing a crash.
The fix for this is to switch from using ast_channel_is_bridged() to
checking the NULLity of ast_channel_internal_bridge_channel() to
determine if ast_bridge_depart() needs to be called. The channel's
internal bridge_channel is set when ast_bridge_impart() is called and
is NULLed by the call to ast_bridge_depart(). If the channel's internal
bridge_channel is non-NULL, then the channel must have been imparted
into the bridge and needs to be departed, even if the actual bridging
operation has not yet started. By departing the channel when necessary,
the thread that is running the Stasis application will block until the
bridge gives the okay that the depart_thread has exited.
The second race condition that is solved by this patch involves a leak
of HTTP handler threads. The problem was that step 2b would successfully
retrieve a stasis_app_control structure. Then step 2a would exit the
channel from the event loop due to a hangup. Steps 3a and 4a would
execute, and then finally steps 3b and 4b would. The problem is that at
step 4b, when attempting to add a channel to a bridge, the thread would
block forever since the channel would never execute the queued command
since it was finished with the event loop. This meant that the HTTP
handling thread would be leaked, along with any references that thread
may have owned (in my case, I was seeing bridges leaked).
The fix for this is to hone in better on when the channel has exited the
event loop. The stasis_app_control structure has an is_done field that
is now set at each point where the channel may exit the event loop. If
step 2b retrieves a valid stasis_app_control structure but the control
is marked as done, then the attempted operation exits immediately since
there will be nothing to service the attempted command.
ASTERISK-25091 #close
Reported by Ilya Trikoz
Change-Id: If66265b73b4c9f8f58599124d777fedc54576628
This event was added some time ago in order to clarify when a channel
took the place of another channel in a parking lot. However, there was
no XML documentation added for the event. This patch adds the XML
documentation.
ASTERISK-24900 #close
Reported by Rusty Newton
Change-Id: I4cfe7777c4b94bbff91c9221c6096a7a02a92eac
Some phones send g.726 audio packed for AAL2, which differs from what is
recommended by RFC 3351. If Asterisk receives audio formatted as such when
negotiating g.726 then it sounds a bit distorted. Added an option to
res_pjsip_endpoint that allows g.726 negotiated audio to be treated as g.726
AAL2 packed.
ASTERISK-25158 #close
Reported by: Steve Pitts
Change-Id: Ie7e21f75493d7fe53e75e12c971e72f5afa33615
The CDR_PROP function (as well as the NoCDR application) set the
'disable all' flag (AST_CDR_FLAG_DISABLE_ALL) on the current CDR. This
flag is supposed to be applied to all CDRs that are currently in the
chain, as well as all CDRs that may be created in the future. Currently,
however, the flag is only applied to the existing CDRs in the chain; new
CDRs do not receive the 'disable all' flag. In particular, this affects
parallel dials, which generate new CDRs for each pair of channels in
the dial attempt.
This patch carries over the 'disable all' flag when it is specified on a
CDR and a new CDR is generated for the chain.
ASTERISK-24344 #close
Change-Id: I91a0f0031e4d147bdf8a68ecd08304d506fb6a0e
When a parallel dial occurs, a new CDR will be created for each dial
attempt that is made. In most circumstances, the act of creating each
CDR in the chain will include a step that updates the Party A snapshot,
which causes the context/extension of the Party A to be copied onto the
CDR object.
However, when the Party A is in a subroutine, we explicitly do *not*
copy the context/extension onto the CDR. This prevents the Macro or
GoSub routine name from blowing away the context/extension that the
channel was originally executing in. For the original CDR, this is not a
problem: the original CDR already recorded the last known 'good' state
of the channel just prior to it going into the subroutine. However, for
newly generated CDRs in a chain, there is no context/extension set on
them. Since we are in a subroutine, we will never set the Party A's
context/extension on the CDR, and we end up with a CDR with no
destination recorded on it.
This patch updates the creation of a chained CDR such that it copies
over the original CDR's context/extension. This is the last known "good"
state of the CDR, and is a reasonable starting point for the newly
generated CDR. In the case where we are not in a subroutine, subsequent
code will update the location of the CDR from the Party A information;
in the case where we are in a subroutine, the context/extension on the
original CDR is the correct information.
ASTERISK-24443 #close
Change-Id: I6a3ef0d6e458d3b9b30572feaec70f2964f3bc2a
If a client sends and INVITE which is 401 rejected, then subsequently
sends a new INVITE with the auth info and uses a different fromtag
from the first INVITE, Asterisk will accept the new INVITE as part of
the original dialog - match_req_to_dialog() specifically ignores the
fromtag. However it does not update the stored dialog with the new
fromtag.
This results in Asterisk being unable to match future packets that are
part of this dialog (such as the ACK to the OK or the OK to the BYE),
and the call is dropped.
This problem was originally found when using an NEC-i SV8100-GE (NEC SIP
Card).
* After a successful match of a packet to the dialog, if the packet is
not a SIP_RESPONSE, authentication is present and the fromtags are
different, the stored fromtag is updated with the one from the recent
INVITE.
ASTERISK-25154 #close
Reported by: Damian Ivereigh
Tested by: Damian Ivereigh
Change-Id: I5c16cf3b409e5ef9f2b2fe974b6bd2a45a6aa17e
Prior to this patch, chan_pjsip was failing to pass the endpoint's
context and the desired extension to the ast_channel_alloc_* routine.
This caused a new channel snapshot to be issued without a context and
extension, which can cause some reporting issues for users of AMI, CEL,
and other APIs. The channel driver would later set the context and
extension on the channel such that the channel would start in the
correct location in the dialplan, but the information reported in the
initial event would be incorrect.
This patch modifies the channel driver such that it now passes the
context and extension directly into the allocation routine. This
provides the information in the new channel snapshot published over
Stasis.
ASTERISK-25156 #close
Reported by: cloos
Change-Id: Ic6f8542836e596db8f662071d118e8f934fdf25e
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.
ASTERISK-25157 #close
Reported by: Joshua Colp
Change-Id: Ibb8798184a1dab3ecd35299faecc420034adbf20
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.
ASTERISK-25087 #close
Reported by: Chet Stevens
Change-Id: I86052ea77307beddddba5279824d39dc0d593374
channels/chan_iax.c: Prevent the deadlock between iax2_hangup and send_lagrq/
send_ping. This deadlock happens because the scheduled task send_lagrq(or
send_ping) starts execution after the call hangup procedure starts but before
it deletes the tasks in the scheduler.
The solution is to delete scheduled lagrq (and ping) task asynchronously
(i.e. schedule AST_SCHED_DEL for these tasks); By this, AST_SCHED_DEL will
be called in a new context (doesn't have callno locked).
This commit also cleans up the procedure of sending LAGRQ and PING.
main/sched.c: Do not assert when deleting non existant entry from scheduler.
This assert seems to be the reason for a lot of awkward code to avoid it.
ASTERISK-24983 #close
Reported by: Y Ateya
Change-Id: I03bec1fc8faacb89630269e935fa667c6d6c080c
This patch fixes use-after-free bugs caught by AddressSanitizer.
1. PJSIP transport manager may decide to destroy transport on its own.
For example, when the contact registered via websocket has not renewed
its registration in time. The transport was destoyed, but the websocket
listener thread was still active until the socket closes, and then tried
to call transport_shutdown on transport that has been freed.
Also, the transport destructor accessed wstransport->rdata.tp_info.pool
right after freeing memory that contained wstransport itself.
This patch converts transport to an ao2 object, allowing it to be
refcounted, so that it is available until both websocket listener and
pjsip transport manager are finished with it.
2. The websocket listener deletes the last reference on websocket session
when the tcp connection is closed, and it gets destroyed, but
the transport manager may still use it, for example when disconnect
happens in the middle of a SIP transaction.
A new reference to websocket session has been added that is released
with the transport to prevent this.
ASTERISK-25096 #close
Reported by: Josh Kitchens
ASTERISK-24963 #close
Reported by: Badalian Vyacheslav
Change-Id: Idc0b63eb6e459c1ddfb2430127d34b3c4d8d373b
GCC 4.7 Manual:
http://gcc.gnu.org/onlinedocs/gcc-4.7.4/gcc/Function-Attributes.html
weakref ("target")
A weak reference is an alias that does not by itself require a definition
to be given for the target symbol.
ASTERISK-22559 #close
Reported by: Ibercom
Change-Id: I36a136cae947b65187a697533416f9ff9a0b8cdf
Although ast_context_find, ast_context_find_or_create and
ast_context_destroy perform locking of the contexts table,
any context pointer can become invalid at any time that the
contexts table is unlocked. This change adds locking around
all complete operations involving these functions.
Places where ast_context_find was followed by ast_context_destroy
have been replaced with calls ast_context_destroy_by_name.
ASTERISK-25094 #close
Reported by: Corey Farrell
Change-Id: I1866b6787730c9c4f3f836b6133ffe9c820734fa
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.
ASTERISK-25148 #close
reported by Mark Michelson
Change-Id: Id1a75ffc3d0eaa168b0b28188fb54d6cf9fc47a9
