[jitsi-dev] .properties accumulating DISCO/Cap Entries


#1

Hi All,

I've been using and developing on Jitsi (high level UI tweaking/baked in
configuration and such: if I do anything interesting I'll contribute it
back) and I've noticed that my sip-communicator.properties file has a
fair few entries of the pattern

`net.java.sip.communicator.impl.protocol.jabber.extensions.caps.EntityCapsManager.CAPS.http\://jitsi.org\#sha-1\#{{HASH}}\=={{DISCO
XML}}`

My issue is that I am trying to provision to users a given configuration
for STUN/TURN/Multimedia support, and these keys seem to be the relevant
ones. But interestingly they do not seem to be getting wiped. I have
been using both Stock Jitsi and "Smith Chat" (my fork) and they are
running off the same .properties file (as intended: my changes are
purely cosmetic).

I have attached these entries and the bizarre thing is that they refer
to both `Jitsi2.2.4603.9615` (my current version) and `SmithChat1.0.0`,
`SmithChat1.0.2` and `SmithChat1.0.3`. I am only using a single XMPP
account to connect, so shouldn't these replace each other as I move
between versions? And where exactly does the hash come from?

I apologise if this is a known and often-asked question about Jitsi
provisioning, but I've scoured the internet and couldn't find any
details beyond the DISCO specification, which explains what the messages
are. I guess I just need to be aware of how that SHA1 hash is generated
and whether or not it's possible to provision users with the correct
configs. I should be fine composing the body of the XML myself, but I am
unclear on how to make sure my exact config remains the one that is used.

Additionally if this accumulation of CAPS messages is not desired
behaviour, I guess I am reporting it as a possible bug. It seems like
it's just not wiping the old ones, which kind of makes sense.

Thanks as always for your help.

DISCO_entries.properties (16.7 KB)

···

----
Toby Pinder
Software Developer
Smith Electric Vehicles


#2

Hello,

Hi All,

I've been using and developing on Jitsi (high level UI tweaking/baked in
configuration and such: if I do anything interesting I'll contribute it
back) and I've noticed that my sip-communicator.properties file has a
fair few entries of the pattern

`net.java.sip.communicator.impl.protocol.jabber.extensions.caps.EntityCapsManager.CAPS.http\://jitsi.org\#sha-1\#{{HASH}}\=={{DISCO
XML}}`

My issue is that I am trying to provision to users a given configuration
for STUN/TURN/Multimedia support, and these keys seem to be the relevant
ones. But interestingly they do not seem to be getting wiped. I have
been using both Stock Jitsi and "Smith Chat" (my fork) and they are
running off the same .properties file (as intended: my changes are
purely cosmetic).

I have attached these entries and the bizarre thing is that they refer
to both `Jitsi2.2.4603.9615` (my current version) and `SmithChat1.0.0`,
`SmithChat1.0.2` and `SmithChat1.0.3`. I am only using a single XMPP
account to connect, so shouldn't these replace each other as I move
between versions? And where exactly does the hash come from?

I am not quite sure I understand what you are trying to do, so I
apologize if the following is offtopic and doesn't help.

The EntityCapsManager properties are not used to configure the local
client. They are used to cache often used disco#info answers and avoid
having to use disco#info.

The specification is here: http://xmpp.org/extensions/xep-0115.html

Short story: when a client sends a presence IQ, it attaches to it a hash
of the features it supports. When we want to know if a remote client
supports a given feature, we check if we have the hash that it sent to
us in our cache. If we do, we use it. Otherwise, we use disco#info (and
then add an entry in the cache). So it is normal for the properties to
accumulate.

Regards,
Boris

···

On 9/24/13 6:35 PM, Toby Pinder wrote:


#3

I see. I've clearly gotten the wrong end of the stick then. My apologies, and thanks for your help.

Hello,

Hi All,

I've been using and developing on Jitsi (high level UI tweaking/baked in
configuration and such: if I do anything interesting I'll contribute it
back) and I've noticed that my sip-communicator.properties file has a
fair few entries of the pattern

`net.java.sip.communicator.impl.protocol.jabber.extensions.caps.EntityCapsManager.CAPS.http\://jitsi.org\#sha-1\#{{HASH}}\=={{DISCO
XML}}`

My issue is that I am trying to provision to users a given configuration
for STUN/TURN/Multimedia support, and these keys seem to be the relevant
ones. But interestingly they do not seem to be getting wiped. I have
been using both Stock Jitsi and "Smith Chat" (my fork) and they are
running off the same .properties file (as intended: my changes are
purely cosmetic).

I have attached these entries and the bizarre thing is that they refer
to both `Jitsi2.2.4603.9615` (my current version) and `SmithChat1.0.0`,
`SmithChat1.0.2` and `SmithChat1.0.3`. I am only using a single XMPP
account to connect, so shouldn't these replace each other as I move
between versions? And where exactly does the hash come from?

I am not quite sure I understand what you are trying to do, so I
apologize if the following is offtopic and doesn't help.

The EntityCapsManager properties are not used to configure the local
client. They are used to cache often used disco#info answers and avoid
having to use disco#info.

The specification is here: http://xmpp.org/extensions/xep-0115.html

Short story: when a client sends a presence IQ, it attaches to it a hash
of the features it supports. When we want to know if a remote client
supports a given feature, we check if we have the hash that it sent to
us in our cache. If we do, we use it. Otherwise, we use disco#info (and
then add an entry in the cache). So it is normal for the properties to
accumulate.

Regards,
Boris

···

On 25/09/13 09:37, Boris Grozev wrote:
On 9/24/13 6:35 PM, Toby Pinder wrote:

--
Toby Pinder | Telemetry Software Engineer

Switchboard +44 (0)845 077 9077
Office Phone: + 44 191 419 7135
Mobile Phone: + 44 (0)7821 036 600

E. toby.pinder@smithelectric.com<mailto:ross.cooney@smithelectric.com>
W. www.smithelectric.com<http://www.smithelectric.com/>

[cid:part4.08070608.09020401@smithelectric.com]

This email and any attachments thereto may contain private, confidential, and privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.