Instead of simply failing after clicking OK when adding a contact,
validate the address/ID supplied by the user, show an error and
attempt to correct it.
RFC3261 deprecated this attribute:
[...] The use of "transport=tls" has consequently been
deprecated, partly because it was specific to a single hop
of the request. [...]
Closes#2
Because:
* Technically: addresses with spaces don't exist
* Functionally: a user may add an address with a space in it and wait for an
authorization that would never come
Since Office 2010, IM applications need to write to their own key
below IM Providers. Jitsi's setup was preparing this under HKLM for a
while, now write the actual state where it belongs.
https://msdn.microsoft.com/en-us/library/office/jj900715.aspx
* 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.
Some of our dependencies are already OSGi bundles. Copy them directly
in one target. At a later time, this will allow us to resolve them
with centrally from Maven instead of copying.
The project jitsi/jitsi started listing an explicit org.jitsi.libjitsi
artifact version in order to comply with our policy which was put into
effect in our other projects. Now jitsi/jitsi-universe does not have to
specify any default artifact version for org.jitsi.libjitsi.
We made an effort to support reproducible builds. That made us specify
explicit jitsi/libjitsi and jitsi/jitsi-universe (artifact) versions.
The jitsi Maven project is the only one which did not specify an
explicit jitsi/libjitsi version. However, jitsi/jitsi-videobridge
depends on jitsi/jitsi and, consequently, sees a mixture of
jitsi/libjitsi and jitsi/jitsi-universe versions during its build.