savoirfairelinux issueshttps://git.jami.net/groups/savoirfairelinux/-/issues2021-12-28T20:54:37Zhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/681sipvoiplink, crash on exit2021-12-28T20:54:37ZSébastien Blinsipvoiplink, crash on exit# Scenario
Quit jami
# trace (in rare case)
```
Thread 42 "jami-qt" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fff1e7fc700 (LWP 1129330)]
__GI___pthread_mutex_lock (mutex=0x30) at ../nptl/pthread_mutex_lock.c...# Scenario
Quit jami
# trace (in rare case)
```
Thread 42 "jami-qt" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fff1e7fc700 (LWP 1129330)]
__GI___pthread_mutex_lock (mutex=0x30) at ../nptl/pthread_mutex_lock.c:67
67 ../nptl/pthread_mutex_lock.c: No such file or directory.
(gdb) bt
#0 __GI___pthread_mutex_lock (mutex=0x30) at ../nptl/pthread_mutex_lock.c:67
#1 0x00007fffe8674c5d in __gthread_mutex_lock(__gthread_mutex_t*) (__mutex=0x30) at /usr/include/x86_64-linux-gnu/c++/9/bits/gthr-default.h:749
#2 0x00007fffe8683b1e in std::mutex::lock() (this=0x30) at /usr/include/c++/9/bits/std_mutex.h:100
#3 0x00007fffe8687466 in std::lock_guard<std::mutex>::lock_guard(std::mutex&) (this=0x7fff1e7f8380, __m=...) at /usr/include/c++/9/bits/std_mutex.h:159
#4 0x00007fffe89a089c in jami::SipTransportBroker::addTransport(pjsip_transport*) (this=0x0, t=0x555556184de8) at ./sip/siptransport.cpp:248
#5 0x00007fffe8987fa3 in jami::transaction_request_cb(pjsip_rx_data*) (rdata=0x7ffea8001bc8) at ./sip/sipvoiplink.cpp:274
#6 0x00007fffe8c7b3cb in pjsip_endpt_process_rx_data () at /home/sblin/ring-project/daemon/src/.libs/libring.so.0
#7 0x00007fffe8c7b606 in endpt_on_rx_msg () at /home/sblin/ring-project/daemon/src/.libs/libring.so.0
#8 0x00007fffe8c82633 in pjsip_tpmgr_receive_packet () at /home/sblin/ring-project/daemon/src/.libs/libring.so.0
#9 0x00007fffe8c85136 in udp_on_read_complete () at /home/sblin/ring-project/daemon/src/.libs/libring.so.0
#10 0x00007fffe8cc94d7 in ioqueue_dispatch_read_event () at /home/sblin/ring-project/daemon/src/.libs/libring.so.0
#11 0x00007fffe8ccaf3b in pj_ioqueue_poll () at /home/sblin/ring-project/daemon/src/.libs/libring.so.0
#12 0x00007fffe8c7b118 in pjsip_endpt_handle_events2 () at /home/sblin/ring-project/daemon/src/.libs/libring.so.0
#13 0x00007fffe898b644 in jami::SIPVoIPLink::handleEvents() (this=0x555555b86bc0) at ./sip/sipvoiplink.cpp:813
#14 0x00007fffe8989ce4 in jami::SIPVoIPLink::<lambda()>::operator()(void) const (__closure=0x555556153848) at ./sip/sipvoiplink.cpp:739
#15 0x00007fffe8991e0a in std::__invoke_impl<void, jami::SIPVoIPLink::SIPVoIPLink()::<lambda()> >(std::__invoke_other, jami::SIPVoIPLink::<lambda()> &&) (__f=...)
at /usr/include/c++/9/bits/invoke.h:60
#16 0x00007fffe8991dbf in std::__invoke<jami::SIPVoIPLink::SIPVoIPLink()::<lambda()> >(jami::SIPVoIPLink::<lambda()> &&) (__fn=...) at /usr/include/c++/9/bits/invoke.h:95
#17 0x00007fffe8991d6c in std::thread::_Invoker<std::tuple<jami::SIPVoIPLink::SIPVoIPLink()::<lambda()> > >::_M_invoke<0>(std::_Index_tuple<0>) (this=0x555556153848)
at /usr/include/c++/9/thread:244
#18 0x00007fffe8991d42 in std::thread::_Invoker<std::tuple<jami::SIPVoIPLink::SIPVoIPLink()::<lambda()> > >::operator()(void) (this=0x555556153848) at /usr/include/c++/9/thread:251
#19 0x00007fffe8991d26 in std::thread::_State_impl<std::thread::_Invoker<std::tuple<jami::SIPVoIPLink::SIPVoIPLink()::<lambda()> > > >::_M_run(void) (this=0x555556153840)
at /usr/include/c++/9/thread:195
#20 0x00007fffea6a3de4 in () at /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#21 0x00007fffea449609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#22 0x00007fffea36e293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb)
```https://git.jami.net/savoirfairelinux/jami-packaging/-/issues/31packaging-release .repo should contains dl.jami.net/stable2021-12-28T21:15:48ZSébastien Blinpackaging-release .repo should contains dl.jami.net/stablecf https://dl.jami.net/stable/fedora_30/ring-nightly.repo (contains -nightly)cf https://dl.jami.net/stable/fedora_30/ring-nightly.repo (contains -nightly)https://git.jami.net/savoirfairelinux/jami-project/-/issues/1371packaging-release .repo should contains dl.jami.net/stable2021-12-28T21:24:35ZSébastien Blinpackaging-release .repo should contains dl.jami.net/stablecf https://dl.jami.net/stable/fedora_30/ring-nightly.repo (contains -nightly)cf https://dl.jami.net/stable/fedora_30/ring-nightly.repo (contains -nightly)https://git.jami.net/savoirfairelinux/jami-packaging/-/issues/85Fedora stable repository serves nightly builds2021-12-28T21:25:34ZFedora stable repository serves nightly buildsThe stable repository for Fedora serves nightly builds instead of stable release builds.
https://dl.jami.net/stable/fedora_31/The stable repository for Fedora serves nightly builds instead of stable release builds.
https://dl.jami.net/stable/fedora_31/Maxim CournoyerMaxim Cournoyerhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/662Support DTMF2021-12-29T17:07:16ZSébastien BlinSupport DTMFTo be definedTo be definedBackloghttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/636pjnath/turn_session: Bad TURN session state2021-12-29T17:08:23ZOlivier Dionpjnath/turn_session: Bad TURN session stateIn pjnath/turn_session.c:
```c
1192 PJ_ASSERT_RETURN(sess->state == PJ_TURN_STATE_READY, PJ_EINVALIDOP);
```
w...In pjnath/turn_session.c:
```c
1192 PJ_ASSERT_RETURN(sess->state == PJ_TURN_STATE_READY, PJ_EINVALIDOP);
```
where `sess->state` has the value `PJ_TURN_STATE_DESTROYING`.
Discovered by: agent's scenario `make-call`
Passive agent log: [passive.log.gz](/uploads/1b52269e24d286d04eb48eec9a9c99b5/passive.log.gz)
Active agent log: [make-call.log.gz](/uploads/00bf082f046739ccb6bbc43ef2430684/make-call.log.gz)
Backtrace trace, see Thread 51: [active-bt.txt](/uploads/7de8e0588d863186f39824c2dd721e30/gdb.txt)
Tested on 07804eb312350a1ec896c7f271464ca2b3475869Backloghttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/606Split JamiAccount: rewrite setAccountDetails.2021-12-29T17:09:32ZSébastien BlinSplit JamiAccount: rewrite setAccountDetails.Account's config should be in a separated class
setAccountDetails should only change what is in the map, not all settings.Account's config should be in a separated class
setAccountDetails should only change what is in the map, not all settings.Backloghttps://git.jami.net/savoirfairelinux/jami-client-qt/-/issues/629Do not call CallAdapter::fillParticipantData on resize2021-12-29T17:10:13ZSébastien BlinDo not call CallAdapter::fillParticipantData on resize# Scenario
+ Do a call (confernece)
+ resize
# Expected
Do not call "CallAdapter::fillParticipantData" every time
# Current
"CallAdapter::fillParticipantData" is called everytime# Scenario
+ Do a call (confernece)
+ resize
# Expected
Do not call "CallAdapter::fillParticipantData" every time
# Current
"CallAdapter::fillParticipantData" is called everytimeBackloghttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/616ICE/TURN - assertion failure in PJNATH2021-12-29T17:10:58ZMohamed ChibaniICE/TURN - assertion failure in PJNATHAssertion failure in pjnath (pj_assert) when calling pj_ice_strans_init_ice. See back trace in the comments. The error seems to be caused by a failure of TURN allocation. \
Note that the assertion is only enabled in debug mode. In releas...Assertion failure in pjnath (pj_assert) when calling pj_ice_strans_init_ice. See back trace in the comments. The error seems to be caused by a failure of TURN allocation. \
Note that the assertion is only enabled in debug mode. In release mode, the error might not be noticeable, ICE session will succeed/fail depending on the other candidates of the impacted component. \
Might be related to https://github.com/pjsip/pjproject/pull/2525Backloghttps://git.jami.net/savoirfairelinux/jami-libclient/-/issues/487addSwarmConversation incorrect mode2021-12-29T17:12:40ZSébastien BlinaddSwarmConversation incorrect mode`conversation::to_mode(details["mode"].toInt());` does an assumption from the daemon which is not true.
A mode is unknown when syncing, it will be ok after conversationReady`conversation::to_mode(details["mode"].toInt());` does an assumption from the daemon which is not true.
A mode is unknown when syncing, it will be ok after conversationReadyBackloghttps://git.jami.net/savoirfairelinux/jami-client-macos/-/issues/294Conference: add participants split2021-12-29T17:14:06ZAline Gondim SantosConference: add participants splitBackloghttps://git.jami.net/savoirfairelinux/jami-client-qt/-/issues/412UI fluidity is coupled with the load of the daemon2021-12-29T17:15:09ZMaxim CournoyerUI fluidity is coupled with the load of the daemon## Describe your environment
Please specify the following:
- OS: Guix System
- Jami version: jami-qt 20210326.1.cfba013
- What build you are using: as packaged in Guix
## Steps to reproduce
Note: Better the scenario is, better we wil...## Describe your environment
Please specify the following:
- OS: Guix System
- Jami version: jami-qt 20210326.1.cfba013
- What build you are using: as packaged in Guix
## Steps to reproduce
Note: Better the scenario is, better we will be able to reproduce and debug.
- Can you reproduce the bug: at will
- Steps:
1. Disable video acceleration to ensure high load in the daemon.
2. Join a video conference (rendezvous point)
- Actual result:
The UI elements are very slow to refresh. Having the overlay display, for example to make the mute button appear, may take several seconds. Opening the chat view may show a blank square for a long time before its content appear.
- Expected result:
The UI should remain fluid, running asynchronously from the daemon, like the GNOME client, which doesn't suffer from this problem.
## Additional information
Here's a screenshot of the chat view failing to refresh (it took several minutes for it to display its content!):
![chat](/uploads/0652a89288a7050627aa483c38c1a9dc/chat.png)Backloghttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/540Analyze opened files2021-12-29T17:16:32ZSébastien BlinAnalyze opened filesWe need to check how many opened files and what files are opened
+ per account
+ per calls
+ per calls with 10 participants
+ per calls with 20 participants
+ per calls with 30 participants
+ per calls with 40 participantsWe need to check how many opened files and what files are opened
+ per account
+ per calls
+ per calls with 10 participants
+ per calls with 20 participants
+ per calls with 30 participants
+ per calls with 40 participantsBackloghttps://git.jami.net/savoirfairelinux/jami-packaging/-/issues/92Add raspbian (armhf/arm64) packages2021-12-29T17:18:40ZAmin BandaliAdd raspbian (armhf/arm64) packagesWe do not provide a raspbian package anymore due to complications with cross-building our Qt package (`libqt-jami`), now used for building both the client library (`lrc`) and the Qt client (`jami-qt`). Since `lrc` is also built using `l...We do not provide a raspbian package anymore due to complications with cross-building our Qt package (`libqt-jami`), now used for building both the client library (`lrc`) and the Qt client (`jami-qt`). Since `lrc` is also built using `libqt-jami`, we cannot continue providing a `jami-gnome` raspbian package either.Backloghttps://git.jami.net/savoirfairelinux/jami-client-qt/-/issues/375video lag during screen sharing (and call)2021-12-29T18:50:22ZGuillaume Hellervideo lag during screen sharing (and call)Scenario:
- do call between 2 participants
- participant A on linux qt, other participant B shares his screen
- after few minutes, there is a delay in the video seen by A (no audio delay)Scenario:
- do call between 2 participants
- participant A on linux qt, other participant B shares his screen
- after few minutes, there is a delay in the video seen by A (no audio delay)Backloghttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/517Remove hacky underlyingIce()2021-12-29T18:52:33ZSébastien BlinRemove hacky underlyingIce()underlyingIce() is hacky. This method should not exists and the chain should be clean.
However this issue is quite complex, because the socket can be cut pretty everywhere in the chain and it should correctly close all the layer.
The m...underlyingIce() is hacky. This method should not exists and the chain should be clean.
However this issue is quite complex, because the socket can be cut pretty everywhere in the chain and it should correctly close all the layer.
The most hacky part is in TlsSocketEndpoint::ImplBackloghttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/501UPNP-NATPMP - Add a unit test with minimal validation2021-12-29T18:57:47ZMohamed ChibaniUPNP-NATPMP - Add a unit test with minimal validationBackloghttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/494Recheck all APIs2021-12-29T19:03:54ZSébastien BlinRecheck all APIs+ Remove unnecessary APIs
+ Homogeneize file naming
+ definitions URI/ids
+ Split ConfigurationManager+ Remove unnecessary APIs
+ Homogeneize file naming
+ definitions URI/ids
+ Split ConfigurationManagerBackloghttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/471UPnP - Make port ranges configurable2021-12-29T19:05:09ZMohamed ChibaniUPnP - Make port ranges configurableThe port ranges (TCP and UDP) used by upnp to port mapping allocation must be configurable (currently they are hard-coded).
A new API must be added to allow a user to set the ranges for both UDP and TCP ports. If not set, default values ...The port ranges (TCP and UDP) used by upnp to port mapping allocation must be configurable (currently they are hard-coded).
A new API must be added to allow a user to set the ranges for both UDP and TCP ports. If not set, default values be used.
Might be related to https://git.jami.net/savoirfairelinux/ring-daemon/-/issues/417Backloghttps://git.jami.net/savoirfairelinux/jami-client-ios/-/issues/122GNU/Linux->iOS send file after call (to confirm)2021-12-29T19:06:48ZSébastien BlinGNU/Linux->iOS send file after call (to confirm)# Scenario
+ GNU/Linux call iOS
+ iOS just let ringing
+ GNU/Linux hangup
+ GNU/Linux send a file immediately after (will fail, cause iOS will cut the socket)# Scenario
+ GNU/Linux call iOS
+ iOS just let ringing
+ GNU/Linux hangup
+ GNU/Linux send a file immediately after (will fail, cause iOS will cut the socket)Backlog