| Age | Commit message (Collapse) | Author |
|---|
|
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.
ASTERISK-25165 #close
Reported by Corey Farrell
Change-Id: I625c3b50eee4576670b7eeb013c81ad043b4b4f8
|
|
|
|
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.
Change-Id: I252249e81fb9b1a68e0da873f54f47e21d648f0f
|
|
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.
ASTERISK-25196
Reported by Mark Michelson
Change-Id: I525ab251fd40a52ede327a52a2810a56deb0529e
|
|
The client_state objects contain a serializer used to send the outbound
REGISTER messages. Once all those message transactions are complete then
the module can shutdown.
ASTERISK-24907 #close
Reported by: Kevin Harwell
Change-Id: Ibb2fe558f98190f2a06da830e0fadfa25516f547
|
|
|
|
handle_client_state_destruction() refs" into 13
|
|
ast_sorcery_object_unregister() API" into 13
|
|
|
|
unload_module()." into 13
|
|
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.
ASTERISK-25204 #close
Reported by Mark Michelson
Change-Id: I59fb5c08b4d253c0dba9ee3d3950b5025358222d
|
|
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.
ASTERISK-25196 #close
Reported by Mark Michelson
Change-Id: I9702157c3603a2d0bd8a8215ac27564d366b666f
|
|
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
|
|
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
|
|
|
|
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
|
|
Change-Id: I39ae612746d892d2dbe86f3ff2d7027fa1da57f7
|
|
Change-Id: I399cb9d61bbba706b48c98e0bf75e98984cd9a9e
|
|
* Break some long lines.
* Fix doxygen comment.
Change-Id: I8f12ba6822f84d5e7bb575280270cd7e2fefb305
|
|
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
|
|
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
|
|
|
|
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
|
|
contact_apply_handler calls ast_res_pjsip_find_or_create_contact_status
to force the creation of a contact_status object whenever a new
contact is added but it didn't unref the returned object.
Added an ao2_cleanup(status) to plug the leak.
ASTERISK-25141
Change-Id: Icc1401cae142855a1abc86ab5179dfb3ee861c40
Reported-by: Corey Farrell
|
|
* Add some type casting so tv_usec can really be a long, instead of
some strange platform specific type.
* Add some .dylib style files to .gitignore.
* Switch from using -Xlinker to -Wl,. For [reasons unknown][], newer
versions of GCC, when compiling the Homebrew formula for Asterisk,
are not properly passing the -Xlinker options to the linker. Given
that -Wl, does exactly the [same thing][], and does it properly, this
patch changes the -Xlinker options to use -Wl, instead.
[reasons unknown]: http://bit.ly/1SUbEYx
[same thing]: https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html
Change-Id: Id5e6b3c6cc86282ea5fca630dc3991137c5bf4dd
|
|
|
|
The loop to find the first available contact of an endpoint grabbed
contact from the iterator, then checked for offline state. This
caused the first contact after the state was found to leak a reference.
ASTERISK-25141
Change-Id: Id0f1d87410fc63742db0594eb4b18b36e99aec08
|
|
When permanent_uri_handler was creating the contact status
object for each contact, it wasn't unreffing it at the
end of the loop.
ASTERISK-25141 #close
Reported-by: Corey Farrell
Change-Id: I7bb127994677bb3d459f87952f8425c9b9967b12
|
|
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
Change-Id: I12bdd7ddccc819b4ce4b091e826d1e26334601b0
|
|
Add a new ContactStatus AMI event.
Publish the following status/state changes:
Created
Removed
Reachable
Unreachable
Unknown
Contact URI, new status/state, aor and endpoint names, and the
last qualify rtt result are included in the event.
ASTERISK-25114 #close
Change-Id: Id25aae5f7122facba183273efb3e8f36c20fb61e
Reported-by: George Joseph <george.joseph@fairview5.com>
Tested-by: George Joseph <george.joseph@fairview5.com>
|
|
|
|
Incoming SIP packets larger than PJSIP_MAX_PKT_LEN were themselves
truncated before passing to pjsip_tpmgr_receive_packet, but the length
was passed unaltered, thus causing memory corruption and segfault.
ASTERISK-25122 #close
Change-Id: I608a6b6b7f229eacc33a0a7d771d18e27e5b08ab
|
|
Many uses of stasis_unsubscribe in modules can be reached through unload.
These have been switched to stasis_unsubscribe_and_join.
Some subscription callbacks do nothing, for these I've created a noop
callback function in stasis.c. This is used by some modules that monitor
MWI topics in order to enable cache, since the callback does not become
invalid after dlclose it is safe to use stasis_unsubscribe on these, even
during module unload.
ASTERISK-25121 #close
Change-Id: Ifc2549fbd8eef7d703c222978e8f452e2972189c
|
|
for RLS" into 13
|
|
|
|
In addition to specifying lists of 'presence' and 'message-summary',
users can also create lists of type 'dialog'. These should be treated in
the same fashion as 'presence'.
Change-Id: I583bb69cd9f88b0b29bf09ddaddeac4e84189f6e
|
|
When a SUBSCRIBE request is made to a dialplan hint that doesn't exist,
the current NOTICE message informing users of this swaps the context and
extension parameters. This can cause a bit of confusion.
Thanks to CptBurger in #asterisk for helping to point this out.
Change-Id: Ie584d1a58ae217385c87a450ca25b55ca0e36e43
|
|
|
|
Prior to this patch, when a WebSocket connection is made, ARI would not
be informed of the connection until after the WebSocket layer had
accepted the connection. This created a brief race condition where the
ARI client would be notified that it was connected, a channel would be
sent into the Stasis dialplan application, but ARI would not yet have
registered the Stasis application presented in the HTTP request that
established the WebSocket.
This patch resolves this issue by doing the following:
* When a WebSocket attempt is made, a callback is made into the ARI
application layer, which verifies and registers the apps presented in
the HTTP request. Because we do not yet have a WebSocket, we cannot
have an event session for the corresponding applications. Some
defensive checks were thus added to make the application objects
tolerant to a NULL event session.
* When a WebSocket connection is made, the registered application is
updated with the newly created event session that wraps the WebSocket
connection.
ASTERISK-24988 #close
Reported by: Joshua Colp
Change-Id: Ia5dc60dc2b6bee76cd5aff0f69dd53b36e83f636
|
|
|
|
|
|
This patch refactors the transaction timeout processing to eliminate
calling the lower level public pjsip functions and reverts to calling
pjsip_endpt_send_request again. This is the result of me noticing
a possible incompatibility with pjproject-2.4 which was causing
contact status flapping.
The original version of this feature used the lower level calls to
get access to the tsx structure in order to cancel the transaction
when our own timer expires. Since we no longer have that access,
if our own timer expires before the pjsip timer, we call the callbacks
and just let the pjsip transaction take it's own course. When the
transaction ends, it discovers the callbacks have already been run
and just cleans itself up.
A few messages in pjsip_configuration were also added/cleaned up.
ASTERISK-25105 #close
Change-Id: I0810f3999cf63f3a72607bbecac36af0a957f33e
Reported-by: George Joseph <george.joseph@fairview5.com>
Tested-by: George Joseph <george.joseph@fairview5.com>
|
|
When an inbound call is received the To header is checked
for the "line" option. Some remote servers will place this
in the request URI instead. This adds an additional check for
the option in the request URI.
ASTERISK-25072 #close
Reported by: Dmitriy Serov
Change-Id: Id4e44debbb80baad623b914a88574371575353c8
|
|
Use ast_manager_register_xml for res_mwi_external_ami manager
actions. This ensures the module is held open while any of
the actions are being run.
ASTERISK-25117 #close
Reported by: Corey Farrell
Change-Id: Iececfdc2da498b2c32b9e09042f5f12292007ac7
|
|
This patch updates http_websocket and its corresponding implementation
with a pre-session established callback. This callback allows for
WebSocket server consumers to be notified when a WebSocket connection is
attempted, but before we accept it. Consumers can choose to reject the
connection, if their application specific logic allows for it.
As a result, this patch pulls out the previously private
websocket_protocol struct and makes it public, as
ast_websocket_protocol. In order to preserve backwards compatibility
with existing modules, the existing APIs were left as-is, and new APIs
were added for the creation of the ast_websocket_protocol as well as for
adding a sub-protocol to a WebSocket server.
In particular, the following new API calls were added:
* ast_websocket_add_protocol2 - add a protocol to the core WebSocket
server
* ast_websocket_server_add_protocol2 - add a protocol to a specific
WebSocket server
* ast_websocket_sub_protocol_alloc - allocate a sub-protocol object.
Consumers can populate this with whatever callbacks they wish to
support, then add it to the core server or a specified server.
ASTERISK-24988
Reported by: Joshua Colp
Change-Id: Ibe0bbb30c17eec6b578071bdbd197c911b620ab2
|
|
The config wizard was always pulling the first occurrence of
a variable from an ast_variable list but this gets the template
value from the list instead of any overridden value. This patch
creates ast_variable_find_last_in_list() in config.c and updates
res_pjsip_config_wizard to use it instead of
ast_variable_find_in_list. Now the overridden values, where they
exist, are used instead of template variables.
Updated test_config to test the new API.
ASTERISK-25089 #close
Reported-by: George Joseph <george.joseph@fairview5.com>
Tested-by: George Joseph <george.joseph@fairview5.com>
Change-Id: Ifa7ddefc956a463923ee6839dd1ebe021c299de4
|
