* ice4j: v1.0
* jain-sip-api: move to FLOSS version from Opentelecoms (v1.2)
* jain-sdp-api: move to FLOSS version from Opentelecoms (v1.0)
* jain-sip-ri:
jitsi branch with oss-only components, based on 1.2.279
(tag v1.2.279-jitsi-oss1)
* sdp-nist-bridge: v1.1
These libraries are used as released on Maven Central.
* Update OSGi manifests
Now that jain-sip and ice4j are no longer directly bundled,
import the required packages.
Neither the IM nor the server stored account info capabilities of the
account are related to the presence capabilities. Add the support to
the provider even if presence is disabled.
Closes#215
The conversion was done with the script provided by @champtar on a
linux
machine:
find -name '*.java' | xargs file | grep 'CRLF, LF' | cut -d ':' -f1 |
xargs -n1 dos2unix
This fixes the Presence TreeSet's Comparator. If the comparator can't
determine a greater or less than relationship, it will sort by the name
of the resources lexicographically.
A (mathematical) set is a collection of distinct objects. A TreeSet's
compare function determines relation of two objects. It also determines
equality and since this is a Set it would effectively replace the old
one in the set, if the function returns 0. This method wasn't fully
equals consistent, meaning different objects were deemed equal by the
comparator. That lead to an inconsistency in the representation of
presence objects and resources that contact has connected. The resources
not represented in this TreeSet would no longer be able to let the
contact appear as Online.
We should still use the old implementation for checking offline contacts
capabilities. This will give us the 'offline capabilities' e.g.
messaging offline contacts.
This reintroduces some old code in order to give the user the option to
switch between those two behaviours.
It also prevents the removal of all caps nodes (and thusly breaking the
new detection) when a rogue offline presence event comes in. This is
such an event in which a contact is falsely assumed as offline, if the
preferred resource of two or more same prioritised resources goes
offline. We are checking this by looking whether it is a
"resourceChanged"-event. This should probably be changed again, after
those offline presence updates have been fixed.
This changes the behaviour from "last connected resource" or "highest
priority resource" to "most capable resource" regarding the display of
buttons next to this contact. We now check every resource the contact
has connected and we will consider the one with the most capabilities.
This elimates the very frustrating scenario in which the call
capabilites are disabled on a contact who connected additionally a
non-jingle client.
Note that there exists separate issue in which the contact logs off from
only one resource, but gets displayed as completely offline. In that
case the buttons are still displayed wrong, if the contact connects a
non-jingle client on afterwards.