Change-Id: I2753c58c12d167ee5f7454e5a2ed893991c90e24

Change-Id: I6b84270da276a91ea6f455ad477e73d04e601ea5

Change-Id: I8b9e25f99da5945684e265d3923b74065c8ef8eb

ovari authored 6 months ago and ovari committed 6 months ago

8+3 filename → 8.3 filename
be ware → beware
{cannot, can not, cant, can't, could not, couldn't} → unable to
conpleted → completed
file name → filename
imcomplete → incomplete
informations → information
trying to → attempting to
wrong password → incorrect password

GitLab: jami-client-qt#1730

Change-Id: Ia7757efafd2c06af978db02c65b40b1b77c393f8

Sébastien Blin authored 1 year ago and Adrien Béraud committed 1 year ago

Change-Id: I829473d42b2b90f26ed2d93bbde063a21ce0952c

Change-Id: I8502119ce7ff540275c9a273b6896cbbedaf9cbb

as per RFC-8839 describe in section 5.4:

    The "ice-pwd" and "ice-ufrag" attributes can appear
    at either the session-level or media-level.

This seems to be the case on Asterisk servers with ICE enabled (no
ICE at session-level, only in media-level). Note that technically
we can have a SDP with multiple ufrag/pwd and multiple ICE sessions,
but this would need other changes. For now, we can at least handle
the case were ufrag/pwd is at media-level.

Change-Id: If92d8e6194fac2b71185ddf934a6c3a78e3463c0

Adrien Béraud authored 1 year ago and Sébastien Blin committed 1 year ago

Change-Id: Ib53b7e170df59f873fbd85f6e7d4bf338d04cb9c

This distinction between informations from the backend and user
preferences on the codec is not really useful and introduces some
useless complexity.

GitLab: #804
Change-Id: Ieff85e748c635941b1a5efed77b023be41c91b4b

Change-Id: I4e3a230b82c1545a248b05033089b82d8284f22f

Change-Id: Ia80fc12ba65b1abd516af205e6664261ae2e33fe

As a measure of refactorization of the code and to prepare to the
development of dhtnet, the following changes aims at seperating
jami-specific code to connectivity-specific code.

GitLab: #778
Change-Id: Iaa08100f7d61c80292f039a5aae66819cc85b0e9

Change-Id: Ic01845c26653338719b76410878aece456ac93cc

+ Bump deamon version to enable multistream
+ use signal for recorder to check if file stopped
+ answerMediaChangeRequest pass isRemote for tests

Change-Id: I396b8246264cb7826350f75e74f20f05b864f384

Sébastien Blin authored 2 years ago and Adrien Béraud committed 2 years ago

This patch makes the daemon able to negotiate more than 2 medias
for a call. Basically, this patch includes some major changes:

1. reportMediaNegotiationStatus is also called for conference, so
the client is able to update the mediaList of the conference to
use it later if it needs to change the medias. And the medias
can be retrieven with currentMediaList
2. The conference object correctly updates the video mixer on
media changes, and video inputs are restarted if removed then
re-added.
3. Because previous versions of the daemon only supports two medias,
only negotiate more medias with compatible peers. If the daemon is
not compatible, the medias will not be negotiated anyway.

jami-project#1429

Change-Id: I55701d9e6e53b05c9a58adad4e8ea90303e6b9e7

GitLab: #694
Change-Id: I74e430b89db2831979b45a56a566d496e0b7936b

Current pjproject's configuration only allow the daemon to negotiate
two medias streams. Which is not enough for multistream.
Modify this limit to 32 streams (2**5) and avoid any potential
crash if the remote tries to negotiate more streams.
Also, fix some loops.

Note: This may not be the best solution for what we want to achieve.
Another approach may be to use a video mixer, mixing all the
medias we want and always negotiate 2 media streams. However, this
patch will not block the other approach and fix some loops.

jami-project#1429

Change-Id: I71ff3088bbf5908945656d02872755226f452fc5

Mute/un-mute audio is done only locally, i.e. without requesting
a media change (re-invite) as done for the video, thus the media
direction in the SDP must not change for the audio stream.

Gitlab: #688

Change-Id: I3775a29f6c566a159d5b9269b4d9462ab4e3c36f

Mohamed Chibani authored 3 years ago and Sébastien Blin committed 3 years ago

When muting/un-muting the video, a re-invite is performed
leading to a full media renegotiation and restart,  including
ICE session if used.
With these changes, the mute/unmute video will still require
a re-invite (a new SDP to indicate the new media directions), but
the ICE session is re-used and only the video is stopped/started
accordingly.
The behavior improves the UX by avoiding unnecessary audio disruptions
and is more compliant with SIP/ICE specs (see RFC-5245 section 9.1.1.1
for example)

Gitlab: #671

Change-Id: I13caf9a965af1d76e922fe5f6b86d5332b3296d6

Change-Id: I795e3f2f69c07349bf84c87dbcafb502dc8490f8

Mohamed Chibani authored 3 years ago and Sébastien Blin committed 3 years ago

Currently, the media attribute in the SDP is always set to
'sendrecv' regardless of the mute state of the media.
In this patch, media direction will be set according to mute
state of the media.
Note that this only applies if the mute/unmute requires media
renegotiation (SIP re-invite with new SDP session). Currently,
this only the case for video media. For audio, mute/unmute is
done locally without SIP re-invite.

References:
RFC-3264
RFC-4317 (non-normative)

Gitlab: #645

Change-Id: I604331255bd25dfe732e192039a673a0980105fa

Change-Id: I1a9e5c02d5678c6c9057dbfd372c636406593f3f

When requesting destruction of ice session and stream
transport instances from PJNATH, some operation will be
done asynchronously through scheduled timers. If not
properly handled, the timer heap will still contain
timer entries when the timer heap and the IO queueu are
destroyed.
Now, the timer heap is given more time to flush the
remaining timer entries before the IO queue and the
timer heap are destructed.
The timer heap may still contain timer entries if
PJNATH does not process all the timers within the
givent max time (currently set to 3s).

Gitlab: #637

Change-Id: I5ef2fe9d824e8b57191a51fac8f9e53e0e626fcd

Change-Id: Ia220b318c6995a97157b5d3f122ae58d71d5ceb1

Olivier Dion authored 3 years ago and Sébastien Blin committed 3 years ago

Change-Id: I790b47971c6c202f7efeeb8c10db00ef430ca39c

RTCP default address might not be provided by peer in the
received SDP, leading to misconfiguration of RTCP ICE
socket. Now, when the RTCP default address is not present,
the RTP address will be used instead.
Note when ICE is used, the RTP/RTCP default addresses are
only needed to identify the underlying ICE socket.

Gitlab: #587

Change-Id: Ia16eb7d25407e67b6ab5a29c18fc3c56e6fc15aa

Set the security (SRTP) flag for media using account settings

Gitlab #556

Change-Id: I657c054625c37e3a3baa576efe27a67ea16bcff6

Handle and test generation and processing of SIP INVITEs without
media offers (no SDP)
Also add basic call scenario for SIP accounts

Gitlab: #556

Change-Id: I4967a821936e7c33cf4d7e7bdd7ee96718db285e

Media direction attribute in the SDP should be set to "sendonly"
when the call is put on-hold.

Gitlab: #553

Change-Id: Iad82bf1fcac703bd275e857f28d1a4aa7323cc0d

Mohamed Chibani authored 3 years ago and Aline Gondim Santos committed 3 years ago

Modify the CallSignal::MediaNegotiationStatus signal to report
the list of negotiated media in addition to the status event.

Gitlab: #564

Change-Id: I9ac77656f4f268317ddd87b085f1581ceac0b5b9

Mohamed Chibani authored 3 years ago and Andreas Traczyk committed 3 years ago

If multi-stream is disabled and a re-invite is received, the
re-invite answer must use the current media list instead of
creating a new one.
Also, report MediaNegotiationStatus event using the parent
call ID if it's a subcall.

Gitlab: #445

Change-Id: I33cdc5cd4ed8a394d60d8ffb5d506a279fde0b3f

The ICE component IDs are numbered relative to the SDP session, i.e.,
starts from 1 and incremented for each component.
However, RFC-5245 requires that the ICE component IDs are numbered
relative to the media stream, e.g., component IDs 1 and 2 for audio
and component IDs 1 and 2 for video.
This patch allows parsing ICE components IDs in format specified by
the RFC and in the current format.
This patch also allows generating component IDs compliant with
RFC-5245. The generation is disabled by default, and can be enabled
per account on runtime.

Gitlab: #516

Change-Id: I40c0fa54a64b7d729f714c9769ea36335568f4c9

Mohamed Chibani authored 4 years ago and Adrien Béraud committed 3 years ago

Currently, an incoming call is always assumed to have either audio
and video media or only audio media.
This assumption was removed and the incoming call are reported with
the list of included media with some of their attributes as found in
the call invite (SDP). This will allow to process calls with an
arbitrary number of media.
It will also allow to add new media to a call by requesting a media
change using a SIP re-invite (with new SDP). For instance, add video
to an audio-only call. The peer will receive the new offer and may
choose to accept or not the new media.
Not all media change requests require validation from the user/client.
Meaning that for instance, if a new SDP (media change request) is
received to notify that the peer muted it's audio, the media change
request can be processed without requiring validation from the
user/client.

Gitlab: #445

Change-Id: Ibc2b2501a3ec7e2c22f4e9d47cec3eda3dd43fef

Adrien Béraud authored 3 years ago and Sébastien Blin committed 3 years ago

Change-Id: Ia6df7343576af586ed1beff8f6600a9b9af34e2a

Add APIs to set a list of desired media to included when making
outgoing calls.
Also add APIs to update the media of an ongoing call. The update
can be used for example to "mute/un-mute" a media, or to add a new
media (add video to an audio-only call).

Gitlab: #380

Change-Id: Iab32a72547f3a0a2328408aadc6a7656c971a7b0

Sébastien Blin authored 4 years ago and Adrien Béraud committed 4 years ago

Change-Id: Ib53fa87efdbbbc6b7561e3b37f27d7a8d51af163

* use std::to_string for single number-to-string conversions
* use specialized std::istringstream or std::ostringstream if possible

Change-Id: I840615c24ce7757d5db6e864940fcf8049ded047

Sébastien Blin authored 4 years ago and Adrien Béraud committed 4 years ago

Change-Id: If0fa3dd862404b19d024c08814292b5bba846569
GitLab: #355

Sébastien Blin authored 4 years ago and Adrien Béraud committed 4 years ago

Remove all addTask() calls. We can use callbacks now.

Change-Id: Ib0c8de5db57baa142aa094e915b46cf9ed7a06ad
GitLab: #355

Change-Id: If2db06d2c0a6c407c1416cc6953be133eea0f10f