The while(1) loop in skinny_session wasn't checking for EOF so
a packet that was longer than a header but still truncated
would spin the while loop infinitely. Not only does this
permanently tie up a thread and drive a core to 100% utilization,
the call of ast_log() in such a tight loop eats all available
process memory.
Added poll with timeout to top of read loop
ASTERISK-26940 #close
Reported-by: Sandro Gauci
Change-Id: I2ce65f3c5cb24b4943a9f75b64d545a1e2cd2898
There are 2 places in app_queue.c that log EXITEMPTY event: one in
wait_our_turn, and another one in queue_exec in the loop trying to
call an agent after wait_our_turn.
In most cases it leads to logging EXITEMPTY twice.
ABANDON is also logged on two places, and in the rare case when an agent
and caller hang up simultaneously it's also possible to get duplicates
in queue_log.
This commit changes wait_our_turn to return -1 ("the caller should exit
the queue") instead of 0 ("the caller's turn has arrived") in case of
leaving when empty, so queue_exec skips the agent calling loop.
Also, leave_queue is now executed only once in this case, because 2nd
time is just a noop when the queue entry has already been removed.
Also, it sets qe->handled to -1 to indicate that the call was not
answered by an agent, but the necessary handling has already been done
in order to avoid logging an extra ABANDON entry.
ASTERISK-25665 #close
Reported by: Ove Aursand
Change-Id: I4578dd383bf2ac41589cf167865e8aaebcd4c11e
When manipulating flags on a channel the channel has to be
locked to guarantee that nothing else is also manipulating
the flags. This change introduces locking where necessary to
guarantee this. It also adds helper functions that manipulate
channel flags and lock to reduce repeated code.
ASTERISK-26789
Change-Id: I489280662dba0f4c50981bfc5b5a7073fef2db10
Retransmissions of an initial INVITE could be queued in the serializer
before we have processed the first INVITE message. If the first INVITE
message doesn't get completely processed before the retransmissions are
seen then we could try to setup the same call from the retransmissions. A
symptom of this is seeing a (key exists) message associated with an
INVITE. An earlier change attempted to address this kind of problem by
calculating a distributor serializer to use for unassociated messages.
Part of that change also made incoming calls keep using that distributor
serializer. (ASTERISK-26088) However, some leftover code was still
deferring the INVITE processing to the session's serializer even though we
were already in that serializer. This not only is unnecessary but would
cause the same call resetup problem.
* Removed the code to defer processing the initial INVITE to the session's
serializer because we are already running in that serializer.
ASTERISK-26998 #close
Change-Id: I1e822d82dcc650e508bc2d40d545d5de4f3421f6
This option was added to turn off notifying the progress details
on Blind Transfer. If this option is not set then the chan_pjsip
will send NOTIFY "200 OK" immediately after "202 Accepted".
Some SIP phones like Mitel/Aastra or Snom keep the line busy until
receive "200 OK".
ASTERISK-26333 #close
Change-Id: Id606fbff2e02e967c02138457badc399144720f2
This change uses the functions provided by OpenSSL to query
and better construct error messages for situations where
the connection encounters a problem.
ASTERISK-26606
Change-Id: I7ae40ce88c0dc4e185c4df1ceb3a6ccc198f075b
It is possible to initialize a valid config without a capath
or cafile definition. This will cause a crash on a reload.
This fix ensures capath is always allocated.
ASTERISK-26983 #close
Change-Id: I63ff715d9d9023427543a5b8a4ba7b0d82533c12
When a column is of type timestamp, the fraction part of the event
field's seconds was frequently parsed incorrectly especially if
there were leading zeros. For instance "2017-05-23 23:55:03.023"
would be parsed into an int as "23" then when the timestamp was
formatted again to be inserted into the database column it'd be
"2017-05-23 23:55:03.23" which is now 230 milliseconds instead of
23 milliseconds. "03.000001" would be transformed to "03.1", etc.
* If the event field is 'eventtime' and the db column is timestamp,
then existing processing has already correctly formatted the
timestamp so now we simply use it rather than parsing it and
re-printing it. This is the most common use case anyway.
* If the event field is other than 'eventtime' and the db column
is timestamp, we now parse the seconds, including the fractional
part into a double rather than 2 ints. This preserves the
magnitude and precision of the fractional part. When we print
it, we now print it as a "%09.6lf" which correctly represents the
input.
To be honest, why we parse the string timestamp into components,
test the components, then print the components back into a string
timestamp is beyond me. We should use parse it, test it, then if
it passes, use the original string representation in the database
call. Maybe someone thought that some implementations wouldn't
take a partial timestamp string like "2017-05-06" and decided to
always produce a full timestamp string even if an abbreviated one
was supplied. Anyway, I'm leaving it as it is.
ASTERISK-25032 #close
Reported-by: Etienne Lessard
Change-Id: Id407e6221f79a5c1120e1a70bc7e893bbcaf1938
This change adds the required logic to allow the SIP
Call-ID to be placed into the HEP RTCP traffic if the
chan_sip module is used. In cases where the option is
enabled but the channel is not either SIP or PJSIP then
the code will fallback to the channel name as done
previously.
Based on the change on Nir's branch at:
team/nirs/hep-chan-sip-support
ASTERISK-26427
Change-Id: I09ffa5f6e2fdfd99ee999650ba4e0a7aad6dc40d
All log messages go to a queue serviced by a single thread
which does all the IO. This setting controls how big that
queue can get (and therefore how much memory is allocated)
before new messages are discarded. The default is 1000.
Should something go bezerk and log tons of messages in a tight
loop, this will prevent memory escalation.
When the limit is reached, a WARNING is logged to that effect
and messages are discarded until the queue is empty again. At
that time another WARNING will be logged with the count of
discarded messages. There's no "low water mark" for this queue
because the logger thread empties the entire queue and processes it
in 1 batch before going back and waiting on the queue again.
Implementing a low water mark would mean additional locking as
the thread processes each message and it's not worth it.
A "test" was added to test_logger.c but since the outcome is
non-deterministic, it's really just a cli command, not a unit
test.
Change-Id: Ib4520c95e1ca5325dbf584c7989ce391649836d1
A regression was introduced in 12 where passing an empty value
to the CDR dialplan function was not longer allowed. This
change returns to the behavior of 11 where it is permitted.
ASTERISK-26173
Change-Id: I3f148203b54ec088007e29e30005a5de122e51c5
menu_template_handler wasn't properly accounting for the fact that
it might be called both during a load/reload (which isn't really
valid but not prevented) and by a dialplan function. In both cases
it was attempting to use the "pending" config which wasn't valid in
the latter case. aco_process_config is also partly to blame because
it wasn't properly cleaning "pending" up when a reload was done and
no changes were made. Both of these contributed to a crash if
CONFBRIDGE(menu,template) was called in a dialplan after a reload.
* aco_process_config now sets info->internal->pending to NULL
after it unrefs it although this isn't strictly necessary in the
context of this fix.
* menu_template_handler now uses the "current" config and silently
ignores any attempt to be called as a result of someone uses the
"template" parameter in the conf file.
Luckily there's no other place in the codebase where
aco_pending_config is used outside of aco_process_config.
ASTERISK-25506 #close
Reported-by: Frederic LE FOLL
Change-Id: Ib349a17d3d088f092480b19addd7122fcaac21a7
When using the Bridge AMI action on the same channel multiple times
it was possible for the channel to return to the wrong location in
the dialplan if the other party hung up. This happened because the
priority of the channel was not preserved across each action
invocation and it would fail to move on to the next priority in
other cases.
This change makes it so that the priority of a channel is preserved
when taking control of it from another thread and it is incremented
as appropriate such that the priority reflects where the channel
should next be executed in the dialplan, not where it may or may not
currently be.
The Bridge AMI action was also changed to ensure that it too
starts the channels at the next location in the dialplan.
ASTERISK-24529
Change-Id: I52406669cf64208aef7252a65b63ade31fbf7a5a
When a call gets put on hold RTP is temporarily stopped and Asterisk was
setting the remote RTCP address to NULL. Then when RTCP data was received
from the remote endpoint, Asterisk would be missing this information when
publishing the rtcp_message stasis event. Consequently, message subscribers
(in this case res_hep_rtcp) trying to parse the "from" field output the
following error:
"ast_sockaddr_split_hostport: Port missing in (null)"
This patch makes it so the remote RTCP address is no longer set to NULL when
stopping RTP. There was only one place that appeared to check if the remote
RTCP address was NULL as a way to tell if RTCP was running. This patch added
an additional check on the RTCP schedid for that case to make sure RTCP was
truly not running.
ASTERISK-26860 #close
Change-Id: I6be200fb20db647e48b5138ea4b81dfa7962974b
Many sound files don't have a full frame's worth of data at EOF, so the
warning messages were a bit too noisy. So we demote them to debug
messages.
Change-Id: I6b617467d687658adca39170a81797a11cc766f6
For outgoing TCP connections, Asterisk uses the first IP address of the
interface instead of the IP address we asked him to bind to.
ASTERISK-26922 #close
Reported-by: Ksenia
Change-Id: I43c71ca89211dbf1838e5bcdb9be8d06d98e54eb
There is a theoretical potential to deadlock in
ast_rtp_codecs_payloads_copy() because it locks two different
ast_rtp_codecs locks. It is theoretical because the callers of the
function are either copying between a local ast_rtp_codecs struct and a
RTP instance of the ast_rtp_codecs struct. Or they are copying between
the caller and callee channel RTP instances before initiating the call to
the callee. Neither of these situations could actually result in a
deadlock because there cannot be another thread involved at the time.
* Add deadlock avoidance code to ast_rtp_codecs_payloads_copy() since it
locks two ast_rtp_codecs locks to perform a copy.
This only affects v13 since this deadlock avoidance code is already in
newer branches.
Change-Id: I1aa0b168f94049bd59bbd74a85bd1e78718f09e5
A deadlock can happen between a channel lock and a pjsip session media
container lock. One thread is processing a reINVITE's SDP and walking
through the session's media container when it waits for the channel lock
to put the determined format capabilities onto the channel. The other
thread is writing a frame to the channel and processing the T.38 frame
hook. The T.38 frame hook then waits for the pjsip session's media
container lock. The two threads are now deadlocked.
* Made the T.38 frame hook release the channel lock before searching the
session's media container. This fix has been done to several other
frame hooks to fix deadlocks.
ASTERISK-26974 #close
Change-Id: Ie984a76ce00bef6ec9aa239010e51e8dd74c8186
There was no context info in this module's log messages so it was
impossible to toubleshoot.
Added endpoint or host to all messages and added the realms in the
challenge for the "No auth credentials for any realm" message.
Change-Id: Ifeed2786f35fbea7d141237ae15625e472acff9b
If you use ast_request to create a PJSIP channel but then hang it
up without causing a transaction to be sent, the session will
never be destroyed. This is due ot the fact that it's pjproject
that triggers the session cleanup when the transaction ends.
app_chanisavail was doing this to get more granular channel state
and it's also possible for this to happen via ARI.
* ast_sip_session_terminate was modified to explicitly call the
cleanup tasks and unreference session if the invite state is NULL
AND invite_tsx is NULL (meaning we never sent a transaction).
* chan_pjsip/hangup was modified to bump session before it calls
ast_sip_session_terminate to insure that session stays valid
while it does its own cleanup.
* Added test events to session_destructor for a future testsuite
test.
ASTERISK-26908 #close
Reported-by: Richard Mudgett
Change-Id: I52daf6f757184e5544c261f64f6fe9602c4680a9
It's possible for a name in a party id structure to be marked as valid, but the
name string itself be NULL (for instance this is possible to do by using the
dialplan CALLERID function). There were a couple of places where the name was
validated, but the string itself was not checked before passing it to functions
like 'strlen'. This of course caused a crashed.
This patch adds in a NULL check before attempting to pass it into a function
that is not NULL tolerant.
ASTERISK-25823 #close
Change-Id: Iaa6ffe9d92f598fe9e3c8ae373fadbe3dfbf1d4a
