| Commit message (Collapse) | Author | Age | Lines |
|
|
|
|
|
|
|
|
| |
This occurs when the user declines an incoming call transfer request,
due to the following path:
- recvd_refer_permission() acquires a read lock over lines_mtx
- move_releasing_lines_to_background() is called
- A write lock over lines_mtx is acquired
|
|
|
|
|
|
|
|
|
|
|
| |
This occurs when performing a consult transfer if the target does not
support the Replaces extension, due to the following path:
- refer() acquires a read lock over lines_mtx
- refer_consultation() is called
- A write lock over lines_mtx is acquired
Closes #118
|
|
|
|
|
|
|
|
|
|
| |
This can easily be triggered by starting a blind transfer, and hanging
up before the other end has accepted/rejected it, due to the following
path:
- recvd_notify() acquires a read lock on lines_mtx
- cleanup_dead_lines() is called
- A write lock on lines_mtx is acquired
|
|
|
|
|
|
|
|
|
| |
This occurs on reception of an INVITE with a Replaces header, due to the
following path:
- recvd_invite() acquires a read lock on lines_mtx
- recvd_initial_invite() is called
- A write lock over lines_mtx is acquired
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This converts t_rwmutex and t_rwmutex_guard into a read-write-update[*]
lock and guard, in an attempt to circumvent the various deadlocks that
were introduced with the addition of lines_mtx in 38bb6b7.
[*] For more details, see https://stackoverflow.com/a/18785300 and
http://lkml.iu.edu/hypermail/linux/kernel/0004.3/0117.html.
Note that this is not a real fix; this would require analyzing and
refactoring phone.cpp, which is well beyond my abilities. This is at
best a workaround that appears to conveniently dodge all the deadlocks
I've encountered so far.
(It would have been more proper to introduce a separate class for this
purpose, but this would have required modifying over 80 lines just to
change one type for another. As phone_users_mtx is the only other
instance of this class, the impact of subverting t_rwmutex directly is
minimal.)
|
|
|
|
| |
(Doing this ahead of time to simplify the next commit a bit.)
|
|
|
|
|
| |
These classes are about to get more complex, so let's move them ahead of
time into mutex.cpp.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`t_phone::mutex_3way` can be locked twice when hanging up a conference
call:
- `t_phone::cleanup_3way_state()` acquires a lock
- `t_audio_session::stop_3way()` is called
- `t_audio_session::get_peer_3way()` is called
- `t_phone::get_3way_peer_line()` is called
- which acquires another lock
Making that mutex recursive is a simple way to work around this issue.
|
|
|
|
|
| |
A write lock on `lines_mtx` has already been acquired at the beginning
of `end_call()`.
|
| |
|
|\
| |
| | |
Case insensivity in WWW-Authenticate header
|
|/ |
|
| |
|
|\
| |
| | |
audio: Fix parameter setting failure with alsa v1.1.7
|
|/ |
|
|\
| |
| | |
fix simple typo
|
|/ |
|
|\
| |
| | |
Update Russian translation
|
|/ |
|
|\
| |
| | |
fix Qt 5.11 build (issue #124)
|
|/
|
|
|
|
|
| |
Since Qt 5.11, generated ui_getprofilename.h no longer includes QHeaderView
which breaks the chain that included qvalidator.h in getprofilename.cpp.
As it feels rather fragile to rely on such indirect includes, let's include
<QRegExpValidator> explicitly in each file using QRegExpValidator class.
|
|\
| |
| | |
Fix spelling mistake
|
|/ |
|
|\
| |
| | |
Remove some remaining Qt 4 code
|
| | |
|
|/ |
|
|\
| |
| | |
Test various compiler versions and build options on Travis CI
|
|/ |
|
|\
| |
| | |
Adjustments to the list of packages installed on Travis CI
|
| | |
|
| |
| |
| |
| |
| | |
Twinkle has never actually used QtScript, as far as I can tell. Rather,
it uses embedded JavaScript in QML, which is all part of qtdeclarative.
|
|/
|
|
| |
Twinkle no longer uses QtQuick 1 (since 497c609).
|
|\
| |
| | |
Various additions to the list of build dependencies
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
There are only three Qt submodules which we actually need and check for
in CMakeLists, namely: base (Qt5Widgets), declarative (Qt5Quick) and
tools (Qt5LinguistTools).
|
|/ |
|
|\
| |
| | |
Disambiguate reference to ::bind()
|
|/
|
|
|
|
| |
There's a potential ambiguity between ::bind() and std::bind() if
<functional> happens to be included beforehand (as is the case with
libc++).
|
|\
| |
| | |
bugfix: Signal name was omitted in selectLocalAddress() emit
|
| | |
|
|\ \
| |/
|/| |
Don't require file(1) when checking for libmagic
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Attempting to compile Twinkle on a system where file(1) is not available
currently produces a confusing error message about libmagic not being
found.
The only reason to require file(1) was to obtain the libmagic version,
as the MAGIC_VERSION constant was apparently only introduced in 5.13.
But since we don't need any particular version, we might as well drop
this requirement.
Using find_program() instead of find_path() avoids picking
/usr/include/file by mistake, which resulted in a (harmless) empty
version string in the CMake output.
(Thanks to https://bro-tracker.atlassian.net/browse/BIT-1096 for
providing some of this information.)
|
|\
| |
| | |
PAI Header option
|
| | |
|
|\ \
| | |
| | | |
User-Determined User Busy (UDUB)
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When you reject a call, either
A. the forwarding rule for User-Busy kicks in,
like an answering machine or another extension (of a personal secretary or a deputy). Or
B. the caller hears normal ringing first, and then the busy tone.
To allow case A, a SIP user-agent client (UAC) has to return the status User-Busy (486). The same should happen in case B, because the caller shall hear a busy tone on rejection. 486 is mandated for SIP clients in mobile phones by the GSMA. Furthermore, other SIP-client creators give a 486 in that case as well; I tested Acrobits, Atlinks, Counterpath, Gigaset, Grandstream, RTX, Snom, Yealink, and Vtech.
Before this change, twinkle rejected a call with the SIP-Status 603. The class 6xx requires that *all* other registered phones stop to ring. Furthermore, some SIP user-agent servers (UAS) follow RFC 3398 and map a status 603 to the cause-code 21, which is mapped back to status 403 (Forbidden). Cisco and Digium Asterisk do this. For example in Asterisk, after you rejected the call in twinkle, the caller did not get 603 or 486, but 403. However, in case of 403, the original caller is allowed to re-try the call setup. For example, I have a Nokia Symbian/S60 based phone which tries via IPv4 first, then after it received the 403, that phone tries again via IPv6. Consequently, a user of twinkle had to reject the call twice when 603 was returned.
|
| | |
|
|/ |
|