jami-daemon issueshttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues2021-02-22T21:57:03Zhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/346Use outbound proxy server address when it is specified2021-02-22T21:57:03ZMing Rui ZhangUse outbound proxy server address when it is specifiedCurrently, the proxy address in the SIP client does not have an impact,
when the user specifies that, it should use that address as the destination addressCurrently, the proxy address in the SIP client does not have an impact,
when the user specifies that, it should use that address as the destination addressIteration 23Ming Rui ZhangMing Rui Zhanghttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/339When the Jami android app uses a "DHT proxy" host-name different than the def...2020-11-25T15:59:10ZCarloWhen the Jami android app uses a "DHT proxy" host-name different than the default one it does not connect.Bug report
---------------
## Test environment
Android mobile setup:
- Ring version: 20190706-01
- Device model:
- Android version: 7.0
- What build you are using: Play Store
## Steps to reproduce
- Can you reproduce the...Bug report
---------------
## Test environment
Android mobile setup:
- Ring version: 20190706-01
- Device model:
- Android version: 7.0
- What build you are using: Play Store
## Steps to reproduce
- Can you reproduce the bug: yes at will.
The Jami app default/preset proxy server connection string is "dhtproxy.jami.net:[80-100]", with [80-100] being a range of possible service ports .
- Steps:
1. The current IP address of of dhtproxy.jami.net resolved with nslookup is 54.36.178.20 .
2. Enabling the use of "dhtproxy.jami.net:[80-100]" the jami account goes online correctly.
3. Making a traceroute --resolve-hostnames dhtproxy.jami.net, on a Linux host, I get at the end of the trace list a name alias of the same ip (54.36.178.20) "ns3102173.ip-54-36-178.eu". I can make the same using an app ("Ping & Net") directly on the mobile and I obtain the same results.
4. Using nslookup I verify that the two host names dhtproxy.jami.net and ns3102173.ip-54-36-178.eu resolve to the same ip : 54.36.178.20 . Also on the Android mobile I obtain the same results using the app "Ping & Net".
5. If on the android mobile I point Firefox to the url http://dhtproxy.jami.net or to http://ns3102173.ip-54-36-178.eu I get the same dhtproxy report JSON text: this means that the two host names can be used to open at least the same port 80 \`web page\`.
6. In the Jami application I substituted the dafault/preset host namedhtproxy.jami.net with it's alias ns3102173.ip-54-36-178.eu, I obtain the connection string "ns3102173.ip-54-36-178.eu:[80-100]"; doing so the Jami account no more connects. It seems quite that "the application" is not resolving the IP address for the new host name or it cuts out any other server name to use/resolve different than dhtproxy.jami.net.
7. Using directly the ip address in the connection string makes Jami to connect : "54.36.178.20:[80-100]" .
- Actual result: the Jami Android OS app does not connect to a "DHT proxy" string that has a literal hostname different than "dhtproxy.jami.net". It does connect if the "DHT proxy" is identified using its IP address .
- Expected result: the the Jami Android OS app should connect with any "DHT proxy" using in the connection string its DNS name to be resolved.
## Additional information
I encountered this bug verifying the connection to an OpenDHT (dhtnode) instance I setup; using this setup the Jami app connects to the "DHT proxy" from the Internet only when using the the IP host number in the connection string.
OpenDHT instance, compiled from source baseline version 1.10.0 (https://github.com/savoirfairelinux/opendht.git), running on Linux OS.Iteration 23Sébastien BlinSébastien Blinhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/343multi device & file transfer.2020-11-10T20:48:59ZSébastien Blinmulti device & file transfer.# Scenario
+ A got 2 devices
+ B sends a file to A
# Expected
A should receives the file on both devices
# Current
One device is cut when the other one received the whole file# Scenario
+ A got 2 devices
+ B sends a file to A
# Expected
A should receives the file on both devices
# Current
One device is cut when the other one received the whole fileIteration 22Sébastien BlinSébastien Blinhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/341Still some ice nego failures2020-11-09T17:10:15ZSébastien BlinStill some ice nego failuresIteration 22Sébastien BlinSébastien Blinhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/338Add DRing API to control conference moderators2020-11-12T15:45:46ZAdrien BéraudAdd DRing API to control conference moderatorsIteration 22Pierre LespagnolPierre Lespagnolhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/265video_mixer: do not use camera resolution as width/height2020-11-03T23:46:21ZSébastien Blinvideo_mixer: do not use camera resolution as width/height# Reproduce steps
1. Set camera to low resolution (160x120)
2. Create a conference with high res medias
# Expected result
The conference should get a correct video
# Actual result
The whole grid is 160x120, resulting in hideous videos# Reproduce steps
1. Set camera to low resolution (160x120)
2. Create a conference with high res medias
# Expected result
The conference should get a correct video
# Actual result
The whole grid is 160x120, resulting in hideous videosIteration 22Sébastien BlinPierre LespagnolSébastien Blinhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/273Sound & Conference: If one member is in hold, the sound is cut for the others...2020-08-12T14:53:30ZSébastien BlinSound & Conference: If one member is in hold, the sound is cut for the others participants# Reproduce Steps
Do a conference between 3 devices
A participant switch the conference in hold
# Expected result
The others should be able to speak together
# Current result
No sound for the other participant# Reproduce Steps
Do a conference between 3 devices
A participant switch the conference in hold
# Expected result
The others should be able to speak together
# Current result
No sound for the other participantItération 20Sébastien BlinSébastien Blinhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/272Sound & Conference: Adding somebody cut the sound during 2/3 seconds2020-08-12T14:53:31ZSébastien BlinSound & Conference: Adding somebody cut the sound during 2/3 seconds# Reproduce steps
+ Add someone in the conference
# Expected result
The sound should continue
# Current result
Sometimes, during a few seconds the sound is cut# Reproduce steps
+ Add someone in the conference
# Expected result
The sound should continue
# Current result
Sometimes, during a few seconds the sound is cutItération 20Sébastien BlinMohamed ChibaniSébastien Blinhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/271Sound & Conference: jerky sound when mixing2020-07-29T18:06:13ZSébastien BlinSound & Conference: jerky sound when mixing**TODO** I am investigating this to understand what's the real problem**TODO** I am investigating this to understand what's the real problemItération 20Sébastien BlinSébastien Blinhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/269[POC] Account with mixing options2020-08-13T17:33:01ZSébastien Blin[POC] Account with mixing options2 users, 1 leave = freeze
mixer hears everything2 users, 1 leave = freeze
mixer hears everythingItération 20Sébastien BlinSébastien Blinhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/266Add RTP packet pacer2020-09-04T19:14:39ZMohamed ChibaniAdd RTP packet pacerExperiments showed that some network links are sensitive to transmission bursts which cause packet losses. Currently, encoded media (audio/video) are sent on the network as soon as they are delivered by the encoders. For instance, when a...Experiments showed that some network links are sensitive to transmission bursts which cause packet losses. Currently, encoded media (audio/video) are sent on the network as soon as they are delivered by the encoders. For instance, when a video encoder delivers key-frames, the RTP sender will typically receive many RTP packets representing a single frame, which will cause a transmission burst if sent as they arrive.
The purpose of this item is to design and implement a transmission pacer to flatten the bitrate curve in order to reduce packet losses caused by transmission bursts. The pacer will limit the rate at which the RPT packets are sent. The pacer will obviously add some delay but its impact should not be noticeable.Itération 20Pierre LespagnolPierre Lespagnolhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/239[daemon/ios]iPad stuck during long minutes2020-09-04T19:09:50ZSébastien Blin[daemon/ios]iPad stuck during long minutesRelated to https://git.jami.net/savoirfairelinux/ring-daemon/issues/227
# Observations
Making calls to an ipad device. The connection is generally made without issue. But sometimes, the device is just not answering to any request durin...Related to https://git.jami.net/savoirfairelinux/ring-daemon/issues/227
# Observations
Making calls to an ipad device. The connection is generally made without issue. But sometimes, the device is just not answering to any request during 10/15 minutes. Then it works like before
# Hypotheses
+ Don't receive anything from the proxy during X minutes?
+ Daemon locked?Itération 20Kateryna KostiukKateryna Kostiukhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/262Received pictures are not displayed - Android Beta 20200703-012020-07-09T00:50:06ZCyrille BéraudReceived pictures are not displayed - Android Beta 20200703-01Iteration 19Adrien BéraudPierre DucheminAdrien Béraudhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/259File transfer and multi device, "already accepted" + cancelled2020-07-17T14:25:42ZSébastien BlinFile transfer and multi device, "already accepted" + cancelled# Reproduce step
+ Account B got 2 devices connected to account A
+ A sends a file
+ B receives the file request on both devices, but A cancels the transfer# Reproduce step
+ Account B got 2 devices connected to account A
+ A sends a file
+ B receives the file request on both devices, but A cancels the transferIteration 19Sébastien BlinSébastien Blinhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/258No way to use a custom turn server port2020-07-16T18:48:33ZBrando TovarNo way to use a custom turn server port**Evironment details:**
* OS: Ubuntu 20.04
* Jami version: Jami from jami.net for ubuntu 20.04
**Steps to reproduce**
* Set your own turn server using these instructions: https://git.jami.net/savoirfairelinux/ring-project/wikis/technica...**Evironment details:**
* OS: Ubuntu 20.04
* Jami version: Jami from jami.net for ubuntu 20.04
**Steps to reproduce**
* Set your own turn server using these instructions: https://git.jami.net/savoirfairelinux/ring-project/wikis/technical/3.6-Setup-your-own-TURN-server
* Update turn configuration on Jami advance settings with: IPOfTurnServer:customPort
* Then trying to make a call using turn only will not work and the logs will show this line: `[ice] added turn server 'IPOfTurnServer', port 3478`
The solution is to use 3478 as the listening port on the turnserver.conf than everything will work as intended.Iteration 19Brando TovarBrando Tovarhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/256Stuck in Connecting: Some negotiations are blocked2020-07-16T18:48:37ZSébastien BlinStuck in Connecting: Some negotiations are blockedRelated to https://git.jami.net/savoirfairelinux/ring-daemon/issues/227
# Observation
The ice become complete too soon with no valid pairs:
@@@ Updating States
@@@ on_ice_complete
[1593797289.007|37053|manager.cpp :243 ] 13:28...Related to https://git.jami.net/savoirfairelinux/ring-daemon/issues/227
# Observation
The ice become complete too soon with no valid pairs:
@@@ Updating States
@@@ on_ice_complete
[1593797289.007|37053|manager.cpp :243 ] 13:28:09.007 sip:1018943881119817 ...ICE process complete, status=Success
[1593797289.007|37053|manager.cpp :243 ] 13:28:09.007 sip:1018943881119817 ...Valid list
(called a second time after that when negotiation is done
# Reproduce steps
still unknownIteration 19Sébastien BlinSébastien Blinhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/249Stuck in Searching: Listen on Call ICE is not responding2020-07-09T20:19:50ZSébastien BlinStuck in Searching: Listen on Call ICE is not respondingRelated to https://git.jami.net/savoirfairelinux/ring-daemon/issues/227
# Reproduce steps
Unknown
# Observations
+ Device A calls device B with the bug
+ device B answer its ICE for the PeerConnection request, but not for the DHT ICE...Related to https://git.jami.net/savoirfairelinux/ring-daemon/issues/227
# Reproduce steps
Unknown
# Observations
+ Device A calls device B with the bug
+ device B answer its ICE for the PeerConnection request, but not for the DHT ICE candidates request
+ First call is failing. No fallback done because we are still in the SEARCHING state. Second call will succeed. Because the Peer negotiation is done without issue. However all first calls to device B will failIteration 19Sébastien BlinSébastien Blinhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/248Stuck in Connecting/Searching: timeout duration2020-07-02T20:06:29ZSébastien BlinStuck in Connecting/Searching: timeout durationRelated to https://git.jami.net/savoirfairelinux/ring-daemon/issues/227
Actually ICE_NEGOTIATION_TIMEOUT is 60 seconds. This is pretty long and the user will close the window before thisRelated to https://git.jami.net/savoirfairelinux/ring-daemon/issues/227
Actually ICE_NEGOTIATION_TIMEOUT is 60 seconds. This is pretty long and the user will close the window before thisIteration 19Sébastien BlinSébastien Blinhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/247Stuck in Searching/Connecting: Resolve the two requests mystery2020-07-02T20:06:32ZSébastien BlinStuck in Searching/Connecting: Resolve the two requests mysteryRelated to https://git.jami.net/savoirfairelinux/ring-daemon/issues/227
# Reproduce steps
1. device B cut its connectivity
2. device A calls device B (with the connecting lock, cf https://git.jami.net/savoirfairelinux/ring-daemon/issue...Related to https://git.jami.net/savoirfairelinux/ring-daemon/issues/227
# Reproduce steps
1. device B cut its connectivity
2. device A calls device B (with the connecting lock, cf https://git.jami.net/savoirfairelinux/ring-daemon/issues/243)
3. device A is blocked in "Searching"
4. after a while, device B is back online
5. device A receives 2 ICE response
# Expected results
Only one answer should be received (the one from the fallback request)Iteration 19Sébastien BlinSébastien Blinhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/246Stuck in Searching/Connecting: Improve logs2020-07-07T17:49:52ZSébastien BlinStuck in Searching/Connecting: Improve logsEverything is in the title. The negotiation of a call can be quite complex to understand and logs should be understandable, moreover if the call fails.
Related to https://git.jami.net/savoirfairelinux/ring-daemon/issues/227Everything is in the title. The negotiation of a call can be quite complex to understand and logs should be understandable, moreover if the call fails.
Related to https://git.jami.net/savoirfairelinux/ring-daemon/issues/227Iteration 19Sébastien BlinSébastien Blin