The memory corruption could happen if the [section](+) is the last section
in the file with trailing comments. In this case process_text_line() has
left *last_cat is set to newcat and newcat is destroyed.
Change-Id: I0d1d999f553986f591becd000e7cc6ddfb978d93
An #include right after a [section](+) would associate any variable
assignments before a new section in the #include with the wrong section.
* Fix section association by setting the current section to the appended
section.
* Fix '+' and '!' section flag interaction corner case depending upon
which flag came first. If the '!' came first then it would be ignored.
If the '!' came after then it would affect the appended section. The '!'
will now no longer be ignored.
ASTERISK-25461 #close
Reported by: Sean Pimental
Change-Id: Ic9d3191c8758048e2cbce6432f854b32531731c3
Return AST_PRESENCE_NOT_SET when CustomPresence AstDB key does not
exist, i.e. when a new CustomPresence is added in the dialplan.
ASTERISK-25400 #close
Reported by: Andrew Nagy
Change-Id: I6fb17b16591b5a55fbffe96f3994ec26b1b1723a
When we decide we will no longer schedule an RTCP write, we remove the
reference to the RTP instance, then assign -1 to the stored scheduler ID
in case something else comes along and wants to see if anything is scheduled.
That scheduler ID is on the RTP instance. After 60a9172d7e was merged to
fix the regression introduced by 3cf0f29310, this improper assignment on a
potentially destroyed object started getting tripped on the build agents.
Frankly, this should have been crashing a lot more often earlier. I can only
assume that the timing was changed just enough by both changes to start
actually hitting this problem.
As it is, simply moving the assignment prior to the ao2 deference is sufficient
to keep the RTP instance from being referenced when it is very, truly,
aboslutely dead.
(Note that it is still good practice to assign -1 to the scheduler ID when we
know we won't be scheduling it again, as the ao2 deref *may* not always destroy
the ao2 object.)
ASTERISK-25449
Change-Id: Ie6d3cb4adc7b1a6c078b1c38c19fc84cf787cda7
If a Via header containes an IPv6 address and a port number is ommitted,
as it is the standard port, we now leave the port empty and to not set it
to the value after the first colon of the IPv6 address.
ASTERISK-25443 #close
Change-Id: Ie3c2f05471cd006bf04ed15598589c09577b1e70
When 5c713fdf18 was merged, it allowed for scheduled items to have an ID of
'0' returned. While this was valid per the documentation for the API, it was
apparently never returned previously. As a result, several users of the
scheduler API viewed the result as being invalid, causing them to reschedule
already scheduled items or otherwise fail in interesting ways.
This patch corrects the users such that they view '0' as valid, and a returned
ID of -1 as being invalid.
Note that the failing HEP RTCP tests now pass with this patch. These tests
failed due to a duplicate scheduling of the RTCP transmissions.
ASTERISK-25449 #close
Change-Id: I019a9aa8b6997584f66876331675981ac9e07e39
When GetConfigJSON was introduced back in 1.6, it returned each
section as an array of strings: ["key=value", "key2=value2"].
Afterwards, it was changed a few times and became
["key": "value", "key2": "value2"], which is not a correct JSON.
This patch fixes that by constructing a JSON object {} instead of
an array [].
ASTERISK-25391 #close
Reported by: Bojan Nemčić
Change-Id: Ibbe93c6a227dff14d4a54b0d152341857bcf6ad8
In practice the set_role API callback can be invoked even
when no ICE is present on an RTP instance. This can occur
if ICE has not been enabled on it.
ASTERISK-25438 #close
Change-Id: I0e17e4316f0f0d7f095c78c3d4fd73a913b6ba69
Currently, NewCallerid is sent only when pointers to number or name
strings change, which is not always the case. The newly allocated string
may use the same memory, so pointers match, while the content
is different. As a result, Caller ID updates are often not reported.
With this patch, actual strings are compared, not the pointers.
ASTERISK-25427 #close
Reported by: Ivan Poddubny
Change-Id: I2a1ac3a842f0e092c6058d1cd3e35443bece1b36
Currently, Asterisk will log to the last configured syslog
channel in logger.conf. This is due to the fact that the
final call to openlog() supersedes all of the previous calls.
This commit removes the call to openlog() and passes the
facility to ast_log_vsyslog(), along with utilizing the
LOG_MAKEPRI macro to ensure that the message is routed to
the correct facility and with the correct priority.
ASTERISK-25407 #close
Reported by: Elazar Broad
Tested by: Elazar Broad
Change-Id: Ie2a2416bc00cce1b04e99ef40917c2011953ddd2
The RECORDED_FILE variable is empty unless a '%d' is specified in the filename.
This patch makes it so the variable is always set to the filename.
ASTERISK-25410 #close
Change-Id: I4ec826d8eb582ae2ad184e717be8668b74d37653
When changing a hint extension without removing the hint first the
device state and presence state is not updated. This causes the state
of the hint to be that of the previous extension and not the current
one. This state is kept until a state change occurs as a result of
something (presence state change, device state change).
This change updates the hint with the current device and presence
state of the new extension when it is changed. Any state callbacks
which may have been added before the hint extension is changed are
also informed of the new device and presence state if either have
changed.
ASTERISK-25394 #close
Change-Id: If268f1110290e502c73dd289c9e7e7b27bc8432f
The CALLERID(num) and CALLERID(name) and other info are placed into the
`char from[256]` in initreqprep. If the name was too long, the addr-spec
and params wouldn't fit.
Code is moved around so the addr-spec with params is placed there first,
and then fitting in as much of the display-name as possible.
ASTERISK-25396 #close
Change-Id: I33632baf024f01b6a00f8c7f35c91e5f68c40260
When Asterisk translates between codecs each with a different frame size (for
example between iLBC 30 and Speex-WB), too large frames were created by
ast_trans_frameout. Now, ast_trans_frameout is called with the correct frame
length, creating several frames when necessary. Affects all transcoding modules
which used ast_trans_frameout: GSM, iLBC, LPC10, and Speex.
ASTERISK-25353 #close
Change-Id: I84b59f7a745955820f10e20f5999eb69495a68b9
It has been observed that on long-running busy systems, a scheduler
context can eventually hit INT_MAX for its assigned IDs and end up
overflowing into a very low negative number. When this occurs, this can
result in odd behaviors, because a negative return is interpreted by
callers as being a failure. However, the item actually was successfully
scheduled. The result may be that a freed item remains in the scheduler,
resulting in a crash at some point in the future.
The scheduler can overflow because every time that an item is added to
the scheduler, a counter is bumped and that counter's current value is
assigned as the new item's ID.
This patch introduces a new method for assigning scheduler IDs. Instead
of assigning from a counter, a queue of available IDs is maintained.
When assigning a new ID, an ID is pulled from the queue. When a
scheduler item is released, its ID is pushed back onto the queue. This
way, IDs may be reused when they become available, and the growth of ID
numbers is directly related to concurrent activity within a scheduler
context rather than the uptime of the system.
Change-Id: I532708eef8f669d823457d7fefdad9a6078b99b2
Add ProgressIndicator IE with inband info present to Progress and
Alerting Q.931 message
ASTERISK-25227 #close
Reported by: Alexandr Dranchuk
Change-Id: I326ad13cb1db9a72b3fd902bafed3c28a3684203
In working through a recent ICE negotiation bug, I found the debug
logging in res_rtp_asterisk to be lacking. This patch adds a number of
debug and warning statements that were helpful.
Change-Id: I950c6d8f13a41f14b3d6334b4cafe7d4e997be80
Call ast_rtp_instance_stop on ooh323_destroy to free resources
allocated by rtp instance
ASTERISK-25299 #close
Report by: Alexandr Dranchuk
Change-Id: I455096bd7da016b871afe90af86067c2c7c9f33f
We were passing the wrong count into pj_ice_sess_create_check_list(),
causing the create to fail if we ever received more than PJ_ICE_MAX_CAND
candidates.
Change-Id: I0303d8e1ecb20a8de9fe629a3209d216c4028378
The call pickup implementation in chan_sip currently sets the channel
hangup cause to "normal clearing" if call pickup is successfully
performed. This action overwrites the "answered elsewhere" hangup cause
set by the call pickup code and can result in the SIP device in
question showing a missed call when it should not.
This change sets the hangup cause to "normal clearing" as a
default initially but allows the call pickup to change it as
needed.
ASTERISK-25346 #close
Change-Id: I00ac2c269cee9e29586ee2c65e83c70e52a02cff
Asterisk needs the sqlite 3 library, which is package
sqlite-devel in CentOS. By adding this package to the
script, a problem with configure failing is resolved.
ASTERISK-25331 #close
Reported by: Kevin Harwell
Change-Id: I90efaf6a01914fea03f21e5cdbd91c348f44b0ec
* Extract set_queue_member_pause() from set_member_paused() for simpler
and more consistent code.
* Extract set_queue_member_ringinuse() from
set_member_ringinuse_help_members() for simpler code.
NOTE: This may fix a consistency issue with realtime ringinuse
because the ordering of things was backported from v13. It is
similar to how set_member_paused() treats realtime for paused.
Change-Id: Iecc1f4119c63347341d7ea6b65f5fc4963706306
Setting the 'paused' and 'ringinuse' options on a queue member using the
dialplan function QUEUE_MEMBER did not behave the same way as the
equivalent dialplan applications or AMI actions.
* Made queue_function_mem_write() call the set_member_paused() and
set_member_value() for the 'paused' and 'ringinuse' options respectively.
A beneficial side effect is that the queue name is now optional and sets
the value in all queues the interface is a member.
NOTE: This may fix a consistency issue with the realtime paused setting
since how the value is set is controlled by set_member_paused() which
treats realtime a little better.
* Update QUEUE_MEMBER XML documentation.
* Fix error checking in QUEUE_MEMBER() write.
ASTERISK-25215 #close
Reported by: Lorne Gaetz
Change-Id: I3a016be8dc94d63a9cc155295ff9c9afa5f707cb
In chan_sip, after handling an incoming invite a security event is raised
describing authorization (success, failure, etc...). However, it was doing
a lookup of the peer by extension. This is fine for register messages, but
in the case of an invite it may search and find the wrong peer, or a non
existent one (for instance, in the case of call pickup). Also, if the peers
are configured through realtime this may cause an unnecessary database lookup
when caching is enabled.
This patch makes it so that sip_report_security_event searches by IP address
when looking for a peer instead of by extension after an invite is processed.
ASTERISK-25320 #close
Change-Id: I9b3f11549efb475b6561c64f0e6da1a481d98bc4
Pressing DTMF digits on a phone to go out on a DAHDI channel can result in
the digit not being recognized or even heard by the peer.
Phone -> Asterisk -> DAHDI/channel
Turns out the DAHDI behavior with DTMF generation (and any other generated
tones) is exposed by the "buffers=" setting in chan_dahdi.conf. When
Asterisk requests to start sending DTMF then DAHDI waits until its write
buffer is empty before generating any samples for the DTMF tones. When
Asterisk subsequently requests DAHDI to stop sending DTMF then DAHDI
immediately stops generating the DTMF samples. As a result, the more
samples there are in the DAHDI write buffer the shorter the time DTMF
actually gets sent on the wire. If there are more samples in the write
buffer than the time DTMF is supposed to be sent then no DTMF gets sent on
the wire. With the "buffers=12,half" setting and each buffer representing
20 ms of samples then the DAHDI write buffer is going to contain around
120 ms of samples. For DTMF to be recognized by the peer the actual sent
DTMF duration needs to be a minimum of 40 ms. Therefore, the intended
duration needs to be a minimum of 160 ms for the peer to receive the
minimum DTMF digit duration to recognize it.
A simple and effective solution to work around the DAHDI behavior is for
Asterisk to flush the DAHDI write buffer when sending DTMF so the full
duration of DTMF is actually sent on the wire. When someone is going to
send DTMF they are not likely to be talking before sending the tones so
the flushed write samples are expected to just contain silence.
* Made dahdi_digit_begin() flush the DAHDI write buffer after requesting
to send a DTMF digit.
ASTERISK-25315 #close
Reported by John Hardin
Change-Id: Ib56262c708cb7858082156bfc70ebd0a220efa6a
There is a window of opportunity for DTMF to not go out if an audio frame
is in the process of being written to DAHDI while another thread starts
sending DTMF. The thread sending the audio frame could be past the
currently dialing check before being preempted by another thread starting
a DTMF generation request. When the thread sending the audio frame
resumes it will then cause DAHDI to stop the DTMF tone generation. The
result is no DTMF goes out.
* Made dahdi_write() lock the private struct before writing to the DAHDI
file descriptor.
ASTERISK-25315
Reported by John Hardin
Change-Id: Ib4e0264cf63305ed5da701188447668e72ec9abb
The res_http_websocket module will currently attempt to close
the WebSocket connection if fatal cases occur, such as when
attempting to write out data and being unable to. When the
fatal cases occur the code attempts to write a WebSocket close
frame out to have the remote side close the connection. If
writing this fails then the connection is not terminated.
This change forcefully terminates the connection if the
WebSocket is to be closed but is unable to send the close frame.
ASTERISK-25312 #close
Change-Id: I10973086671cc192a76424060d9ec8e688602845
We don't have a compatability function to fill in a missing htobe64; but
we already have one for the identical htonll.
Change-Id: Ic0a95db1c5b0041e14e6b127432fb533b97e4cac
A change recently went in which enabled perfect forward secrecy for
DTLS in res_rtp_asterisk. This was accomplished two different ways
depending on the availability of a feature in OpenSSL. The fallback
method created a temporary instance of a key but did not free it.
This change fixes that.
ASTERISK-25265
Change-Id: Iadc031b67a91410bbefb17ffb4218d615d051396
This will add ECDH support to Asterisk. It will
detect auto ECDH support in OpenSSL
(1.0.2b and above) during ./configure. If this is
available, it will use it,
otherwise it will fall back to prime256v1 (this
behavior is consistent with
other projects such as Apache and nginx).
This fixes WebRTC being broken in Firefox 38+ due
to Firefox now only supporting
ciphers with perfect forward secrecy.
ASTERISK-25265 #close
Change-Id: I8c13b33a2a79c0bde2e69e4ba6afa5ab9351465b
A test agent was continuously failing all ARI tests when run against
Asterisk 13. As it turns out, the reason for this is that on those test
runs, for some reason we decided to use the super extended 64 bit
payload length for websocket text frames instead of the extended 16 bit
payload length. For 64-bit payloads, the expected byte order over the
network is
7, 6, 5, 4, 3, 2, 1, 0
However, we were sending the payload as
3, 2, 1, 0, 7, 6, 5, 4
This meant that we were saying to expect an absolutely MASSIVE payload
to arrive. Since we did not follow through on this expected payload
size, the client would sit patiently waiting for the rest of the payload
to arrive until the test would time out.
With this change, we use the htobe64() function instead of htonl() so
that a 64-bit byte-swap is performed instead of a 32 bit byte-swap.
Change-Id: Ibcd8552392845fbcdd017a8c8c1043b7fe35964a
Commit 54b25c80c8 solved an issue where a
specific scenario involving local channels and a native local RTP bridge
could result in ringback still being heard on a calling channel even
after the call is bridged.
That commit caused many tests in the testsuite to fail with alarming
consequences, such as not sending DialBegin and DialEnd events, and
giving incorrect hangup causes during calls.
This commit reverts the previous commit and implements and alternate
solution. This new solution involves only passing AST_CONTROL_RINGING
frames across local channels if the local channel is in AST_STATE_RING.
Otherwise, the frame does not traverse the local channels. By doing
this, we can ensure that a playtones generator does not get started on
the calling channel but rather is started on the local channel on which
the ringing frame was initially indicated.
ASTERISK-25250 #close
Reported by Etienne Lessard
Change-Id: I3bc87a18a38eb2b68064f732d098edceb5c19f39
Richard Mudgett
Ivan Poddubny
Matt Jordan
Florian Sauerteig
Joshua Colp
Elazar Broad
Kevin Harwell
Walter Doekes
Alexander Traud
Mark Michelson
Alexander Anikin
David M. Lee
Guido Falsi
Scott Griepentrog
Mark Duncan