The contact header field was stored in a member varialbe of Jami/SIP
accounts. There was a condition in which the contact header could
be concurrently accessed by multiple threads. This typically happens
when terminating calls in batch (when calling hangupCalls() for
instance).
Managment of SIP contact header in Jami and SIP accounts was
reworked to prevent such race.
Gitlab: #633
Change-Id: Ib9295070a5295969bf114ec29e66e36b1c5c5e03
The agent will be written in Guile Scheme instead of C++ in
order to give maximum flexibility to developers of scenarios.
Thus, bindings will be added for the public Jami interface.
In other words, the agent will be a client of yet another
Jami's bindings.
Change-Id: Ic2cd333007d0b1aad56c02b116ea708b56e96cc5
Hardware decoding will still be used even if the codec level is unknown
or higher than the hardware's reported supported level.
From FFmpeg: "It's generally a good idea to pass this flag unless you
have a specificreason not to, as hardware tends to under-report
supported levels."
Change-Id: I83614b0eab6166a42973f062e666783c2a8e7627
If UPNP is enabled by the user, the UPNP controller must registered
only if the account is enabled.
Gitlab: #639
Change-Id: I993b50ea37fafa847460650d901ac3c3d5039718
After removing and re-adding a contact, the second conversation
will be deleted and the first conv will be recloned. However,
some text messages can be present. In this case, we can re-add
them.
Change-Id: I7cafcf76b5d36769ea939729a2fbf6730853cafb
cancel a file from the user should removes the file from the
waiting map to avoid to relaunch the download on the next sync.
Change-Id: I0696364d0131c8dde563b97b8b965e99d1f5686a
For now, the daemon doesn't handle the profile of the account nor
the compression. However, it does handle sendTrustRequest, which uses
the DHT to transmit requests. DHT values must be small, else it will
not be sent. So, this patch cache the compressed payload generated
by the client and removes it as soon as the confirmation is received.
This allow the daemon to retry to send request with the payload sent
originally.
Change-Id: I3fac542c6a53febdb7f1d0c516ec2d9ff5b317be
This is only to avoid to return weird states from the daemon to the
client. But if a conversation is added through addContact,
removeContact should be called to removes it. However, if
removeConversation() is called, the conversationId in contact's
details MUST be updated.
Same for acceptConversationRequest, this should removes related
trust requests
Change-Id: I4b273075862cdcdffc7f13c1b5e581a2eebc411d
While waiting for ICE initialization, the call state may change
and also the ICE instance. This patch handle a race between
ICE initiliazation and call removal
Gitlab: #619
Change-Id: I4a18a9901ddbd35969b85cf0b17213b1ac277b02
Instantiation and initialization of ICE are done in a single
stage (in the class constructor).
To initialize the ICE instance, connection information must
first be gathered asynchronously.
However, when sharing ICE media instance between subcalls,
it's better to have a valid ICE instance as soon as possible
(even if not fully initialized) to proceed with the call
initialization process, then wait for ICE initialization to start
the call.
Thus, the ICE instantiation will be performed synchronously as
soon as the parent (main) call is created, then it will be
initialized asynchronously when the connection info are ready.
Gitlab: #619
Change-Id: I9c97516238f1a690603975ec968c8c6733155d4a
Currently, when making an outgoing call to a Jami account with
multiple registered devices, a new ice media instance is created
for each subcall. This is not necessary, because all ice instances
will be similar until the peer answers (and provide its candidates)
But when the answer is received from the peer, all ice instances are
destroyed except the instance of the successful subcall, which will
be used to negotiate the media path.
Instead, only one instance will be created for the parent call, and
shared amongst the attached subcalls.
Gitlab: #619
Change-Id: I001c27f69d21b3ea640b189aea401e43c3f6bdef
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
