If the SQL UPDATE statement changes nothing then SQLRowCount returns 0.
This value should be treated as success.
But the function sorcery_realtime_update treats it as failed.
This bug was found using stress tests on PJSIP.
If there are 2 consecutive SIP REGISTER requests with the same contact data
during 1 second then res_pjsip_registrar adds contact location on 1st request
and tries to update contact location on 2nd.
The update fails and res_pjsip_registrar even removes correct contact location.
The test "object_update_uncreated" was removed from test_sorcery_realtime.c
because it's now a valid situation.
This patch also adds missing debug of extra SQL parameter.
ASTERISK-26172 #close
Change-Id: I05a7f3051455336c9dda29efc229decf86071303
It is possible in a hypothetical situation for a session refresh to be
invoked on a PJSIP when the negotiatior on the INVITE session has not
yet been established. While this shouldn't occur with existing uses of
ast_sip_session_refresh, the crashes that occur due to improperly
calling PJSIP functions that expect a non-NULL negotiatior are
avoidable. PJSIP will create the negotiator in pjsip_inv_reinvite; this
means that simply checking for the presence of the negotiator before
passing it to other PJSIP functions that use it is allowable. As such,
this patch adds checks for the presence of the negotiator before calling
PJSIP functions that assume it is non-NULL.
Change-Id: I1028323e7e01b0a531865e5412a71b6f6ec4276d
When something very sad and wrong occurs, it's challenging sometimes to
figure out why. This patch adds some additional debug statements on
off-nominal paths to try and make debugging easier.
Change-Id: I7bffb73cc733b6f80193a23340881db4a102b640
When res_corosync detects that a node leaves or joins, it currently is
informed of this via Corosync callbacks. However, there are a few
limitations with the information presented:
(1) While we have information that Corosync is aware of - such as the
Corosync nodeid - that information is really only useful inside of
Corosync or res_corosync. There's no way to translate a Corosync
nodeid to some other internally useful unique identifier for the
Asterisk instance that just joined or left the cluster.
(2) While res_corosync is notified of the instance joining or leaving
the cluster, it has no mechanism to inform the Asterisk core or
other modules of this event. This limits the usefulness of res_corosync
as a heartbeat mechanism for other modules.
This patch addresses both issues.
First, it adds the notion of a cluster discovery message both within the
Stasis message bus, as well as the binary event messages that
res_corosync uses to transmit data back and forth within the cluster.
When Asterisk joins the cluster, it sends a discovery message to the other
nodes in the cluster, which correlates the Corosync nodeid along with
the Asterisk EID. res_corosync now maintains a hash of Corosync nodeids
to Asterisk EIDs, such that it can map changes in cluster state with the
Asterisk instance that has that nodeid. Likewise, when an Asterisk
instance receives a discovery message from a node in the cluster, it now
sends its own discovery message back to the originating node with the
local Asterisk EID. This lets Asterisk instances within the cluster
build a complete picture of the other Asterisk instances within the
cluster.
Second, it publishes the discovery messages onto the Stasis message bus.
Said messages are published whenever a node joins or leaves the cluster.
Interested modules can subscribe for the ast_cluster_discovery_type()
message under the ast_system_topic() and be notified when changes in
cluster state occur.
Change-Id: I9015f418d6ae7f47e4994e04e18948df4d49b465
If specified, incoming SUBSCRIBE requests will be searched for the matching
extension in the indicated context. If no "subscribe_context" is specified,
then the "context" setting is used.
ASTERISK-25471 #close
Change-Id: I3fb7a15f5bc154079bd348c08b7ad1cdd2d5e514
When an answer SDP is invalid we were disconnecting the outgoing call and
sending two BYE requests. The first BYE was sent by PJPROJECT because of
the invalid SDP answer. The second BYE was sent by Asterisk because it
thought the canceled call was the result of the RFC5407 section 3.1.2 race
condition.
* Made not send the BYE on a canceled session if the SDP negotiation is
incomplete because PJPROJECT has already sent a BYE for the failed
negotiation.
ASTERISK-25772 #close
Reported by: Dmitriy Serov
Change-Id: I44ad0bd0605e8eeb7035c890d6f97a1331f1a836
When an incoming call defers SDP negotiation and then sends us an invalid
SDP in the ACK, we need to send a BYE to disconnect the call. In this
case SDP negotiation has failed and we don't have valid media streams
negotiated.
ASTERISK-25772
Change-Id: Ia358516b0fc1e6c4c139b78246f10b9da7a2dfb8
Registering the PJMEDIA error codes allows errors found when parsing an
incoming SDP to be easier to figure out.
"Missing SDP rtpmap for dynamic payload type (PJMEDIA_SDP_EMISSINGRTPMAP)"
is much easier to understand than "Unknown error 220030".
ASTERISK-25772
Change-Id: I44b2dcea656fedd7593171be9e845880a2c70ca0
pjsip_inv_end_session() is documented as being able to return the
passed in tdata parameter set to NULL on success.
Change-Id: I09d53725c49b7183c41bfa1be3ff225f3a8d3047
This change removes hardcoded SDP parsing and generation for
Siren7 and Siren14 from chan_sip and moves it to format attribute
modules so it can also be used by chan_pjsip.
With this the fmtp lines for both are added with the bitrate
information.
ASTERISK-26021
Change-Id: Ibb004eda37a14c0a35ef0613f6237977fc800037
fax_v21_session_new created a session details object but only released
the allocation reference during error conditions. fax_session_new adds
it's own reference to details if needed so the caller is always
responsible for cleaning it's own reference.
ASTERISK-26141 #close
Change-Id: Ie7fc52a83b6596ce9ce2d5a2bd9f3e204f48fc88
gcc 6 caught a previously unidentified self-comparison in
ice_candidate_cmp. Fixed it and re-ordered the predicates for better
short-circuiting.
ASTERISK-26140 #close
Change-Id: I3da713c568e24064430257b3502fbdafd35af7a7
A non-existent constraint was being referenced in the upgrade script.
This patch corrects the problem by removing the reference.
This patch fixes another realtime problem as well. Our Alembic scripts
store booleans as yes or no values. However, Sorcery tries to insert
"true" or "false" instead. This patch updates Sorcery to use "yes" and
"no"
ASTERISK-26128 #close
Change-Id: I366dbbf91418a9cb160b3ca74b0e59b5ac284bec
The patch removes updating all Endpoints' status on startup.
Instead, only non-qualified aors with static contact
and non-qualified non-expired contacts are retrieved from the realtime to
update the endpoint status to ONLINE.
The endpoint name was added to the contact object to simply find the endpoint
that created this contact.
The status of endpoints with qualified aors will be updated by 'qualify'
functions.
ASTERISK-26061 #close
Change-Id: Id324c1776fa55d3741e0c5457ecac0304cb1a0df
Occasionally under load we'll attempt to send a final NOTIFY on a
subscription that's already been terminated and a SEGV will occur
down in pjproject's evsub_destroy function. This is a result of a
race condition between all the paths that can generate a notify
and/or destroy the underlying pjproject evsub object:
* The client can send a SUBSCRIBE with Expires: 0.
* The client can send a SUBSCRIBE/refresh.
* The subscription timer can expire.
* An extension state can change.
* An MWI event can be generated.
* The pjproject transaction timer (timer_b) can expire.
Normally when our pubsub_on_evsub_state is called with a terminate,
we push a task to the serializer and return at which point the dialog
is unlocked. This is usually not a problem because the task runs
immediately and locks the dialog again. When the system is heavily
loaded though, there may be a delay between the unlock and relock
during which another event may occur such as the subscription timer
or timer_b expiring, an extension state change, etc. These may also
cause a terminate to be processed and if so, we could cause pjproject
to try to destroy the evsub structure twice. There's no way for us to
tell that the evsub was already destroyed and the evsub's group lock
can't tolerate this and SEGVs.
The remedy is twofold.
* A patch has been submitted to Teluu and added to the bundled
pjproject which adds add/decrement operations on evsub's group lock.
* In res_pjsip_pubsub:
* configure.ac and pjproject-bundled's configure.m4 were updated
to check for the new evsub group lock APIs.
* We now add a reference to the evsub group lock when we create
the subscription and remove the reference when we clean up the
subscription. This prevents evsub from being destroyed before
we're done with it.
* A state has been added to the subscription tree structure so
termination progress can be tracked through the asyncronous tasks.
* The pubsub_on_evsub_state callback has been split so it's not doing
double duty. It now only handles the final cleanup of the
subscription tree. pubsub_on_rx_refresh now handles both client
refreshes and client terminates. It was always being called for
both anyway.
* The serialized_on_server_timeout task was removed since
serialized_pubsub_on_rx_refresh was almost identical.
* Missing state checks and ao2_cleanups were added.
* Some debug levels were adjusted to make seeing only off-nominal
things at level 1 and nominal or progress things at level 2+.
ASTERISK-26099 #close
Reported-by: Ross Beer.
Change-Id: I779d11802cf672a51392e62a74a1216596075ba1
Do not use DTLSv1_method() but DTLS_method() when available in OpenSSL of the
underlying platform. This change enables DTLS 1.2 since OpenSSL 1.0.2, for
WebRTC (DTLS-SRTP via SIP-over-WebSockets). This change enables AEAD-based
cipher-suites.
ASTERISK-26130 #close
Change-Id: I41f24448d6d2953e8bdb97c9f4a6bc8a8f055fd0
The receipt of a SIP MESSAGE may occur over any transport including TCP
and TLS. When the message is received, the original URI is added to the
message in the field PJSIP_RECVADDR, but this is insufficient to ensure
a reply message can reach the originating endpoint. This patch adds the
PJSIP_TRANSPORT field populated with the transport type.
ASTERISK-26132 #close
Change-Id: I28c4b1e40d573a056c81deb213ecf53e968f725e
When shutting down res_pjsip_session will get unloaded before res_pjsip.
The act of unloading unregisters all the PJSIP services and sets
their module IDs to -1. In some cases it is possible for a timer to
occur after this happens which calls into res_pjsip_session. The
res_pjsip_session module can then try to get the session from the
INVITE session using the module ID. Since the module ID is now -1
this fails.
This change stores a copy of the module ID and uses it for the timer
callback scenario. If the module ID is -1 the callback immediately
returns but if the module ID is valid then it continues as normal.
This works as the original ID of the module is guaranteed to still
be valid when used with the INVITE session.
ASTERISK-26127 #close
Change-Id: I88df72525c4e9ef9f19c13aedddd3ac4a335c573
Announcer channels were not being destroyed because the
stasis_app_control structure that referenced them was not being
destroyed. The control structure was not being destroyed because it was
not being unlinked from its container. It was not being unlinked from
its container because the after bridge callback for the announcer
channel was not being run. The after bridge callback was not being run
because the after bridge datastore was not being removed from the
channel on destruction. The channel was not being destroyed because the
hangup that used to destroy the channel was now only reducing the
reference count to one. The reference count of the channel was only
being reduced to one because the stasis_app_control structure was
holding the final reference...
The control structure used to not keep a reference to the channel, so
that loop described above did not happen.
The solution is to manually remove the control structure from its
container when the playback on a bridge is complete.
ASTERISK-26083 #close
Reported by Joshua Colp
Change-Id: I0ddc0f64484ea0016245800b409b567dfe85cfb4
* In unload_module(), reordered destroying things to minimize the window
that the global transports container could be used by other threads on
shutdown. When shutting down you need to stop things in the opposite
order of creation.
* Put the global transports container into an AO2_GLOBAL_OBJ_STATIC to
eliminate the crash potential by other threads using the container on
shutdown.
* Made struct monitored_transport.sip_received not use
ast_atomic_fetchadd_int() since it is used as a boolean value that is only
set TRUE. It was previously incremented for every received SIP message
and could theoretically overflow.
* In monitored_transport_state_callback(), allocated the monitored
transport object without a lock since the lock was unused.
* In keepalive_global_loaded(), removed releasing the transports container
if the keepalive_thread could not be started. I set it up to be tried
again if the user reloads the configuration.
Change-Id: I8d12d16ef564290fa6d25a32334bb5ce8fdf87ff
