[jitsi-dev] XMPP, REST, OpenFire and the Videobridge


#1

In trying to set up the XMPP interface I found that there is a ping function in the jitsi software. This fails with an exception if the host name is not specified for the XMPP server. (finding null as the name)

What I am getting at the moment is that a SEVERE error is reported in the console stating that ping cannot get through. The shared secret is the same and Openfire does report that the videobridge is functional (it also gives the correct session times). If openfire is not running the videobridge really complains (lots of stack traces in the console) and keeps trying to log in.

The failed ping does not seem particularly to matter, however.

I am making gradual progress getting the REST interface to work. I have not done low level coding on WebRtc before so I have a reasonable learning curve there as well. (I have used libraries written by other people).

I have (I think) established a peer connection to the videobridge via REST using javascript. I intend writing code in Java, but have started with javascript as this is all very fiddly and the change and test cycle with javascript is faster. It is also easier to run the videobridge in debug mode whilst also running the javascript in a browser.

The Videobridge console reports things like ICE state changed from running to completed and all sorts of things that look positive to me.

However, it does come up with:

WARNING: Unknown DTLS handshake message type: 62 (this number varies)

also

WARNING: Unable to load jnopenssl: ... no jnopenssl in java.library.path

Given that it is using bouncycastle I assume that this message does not matter.

Question 1. Should I worry about either of those?

It then closes down because nothing is being sent to it (which is probably because of my lack of detailed knowledge of WebRtc although I think I am attaching streams correctly), but I will look at that later.

I thought I would try running REST and XMPP at the same time. I therefore established an openmeet openfire video conference with three participants on the same class C network. That worked well as a video conference, but when I asked the videobridge what the conference id was it reported no conferences.

I took the videobridge down and the conference continued. I have not experimented with trying to run ofmeet without the videobridge. However, I assume for the moment it is not part of this although when I ran a packet sniffer on it yesterday it did seem to be doing something at least acting as a STUN server.

Question 2.

When does OpenFire use the videobridge as part of Ofmeet or does it have a separate instance of some form.

Question 3.

Are the lists of XMPP conferences and REST conferences as maintained in the videobridge separate or a joint list. If joint obviously I could patch into an XMPP conference via REST. Otherwise it will be a task not worth attempting.

Question 4.

Some other code not associated with Jitsi munges media line of the SDP for WebRtc to replace RTP/SAVF with UDP/TLS/RTP/SAVP

Is that still sensible, ill advised or not a matter of any import.


#2

Hi John,

Partial answer below.

In trying to set up the XMPP interface I found that there is a ping
function in the jitsi software. This fails with an exception if the
host name is not specified for the XMPP server. (finding null as the name)

What I am getting at the moment is that a SEVERE error is reported in
the console stating that ping cannot get through. The shared secret is
the same and Openfire does report that the videobridge is functional (it
also gives the correct session times). If openfire is not running the
videobridge really complains (lots of stack traces in the console) and
keeps trying to log in.

The failed ping does not seem particularly to matter, however.

I am making gradual progress getting the REST interface to work. I have
not done low level coding on WebRtc before so I have a reasonable
learning curve there as well. (I have used libraries written by other
people).

I have (I think) established a peer connection to the videobridge via
REST using javascript. I intend writing code in Java, but have started
with javascript as this is all very fiddly and the change and test cycle
with javascript is faster. It is also easier to run the videobridge in
debug mode whilst also running the javascript in a browser.

The Videobridge console reports things like ICE state changed from
running to completed and all sorts of things that look positive to me.

However, it does come up with:

WARNING: Unknown DTLS handshake message type: 62 (this number varies)

also

WARNING: Unable to load jnopenssl: ... no jnopenssl in java.library.path

Given that it is using bouncycastle I assume that this message does not
matter.

Question 1. Should I worry about either of those?

No. I don't know why the first one happens, but I think the agreement was that it does not cause any problems. For the second one -- you are correct, bc will be used. It is a bit slower, which is why the bridge tries to use openssl if available.

It then closes down because nothing is being sent to it (which is
probably because of my lack of detailed knowledge of WebRtc although I
think I am attaching streams correctly), but I will look at that later.

I thought I would try running REST and XMPP at the same time. I
therefore established an openmeet openfire video conference with three
participants on the same class C network. That worked well as a video
conference, but when I asked the videobridge what the conference id was
it reported no conferences.

I took the videobridge down and the conference continued. I have not
experimented with trying to run ofmeet without the videobridge.
However, I assume for the moment it is not part of this although when I
ran a packet sniffer on it yesterday it did seem to be doing something
at least acting as a STUN server.

Question 2.

When does OpenFire use the videobridge as part of Ofmeet or does it have
a separate instance of some form.

Question 3.

Are the lists of XMPP conferences and REST conferences as maintained in
the videobridge separate or a joint list. If joint obviously I could
patch into an XMPP conference via REST. Otherwise it will be a task not
worth attempting.

They are not separate (in fact REST is implemented with translation to the XML used by XMPP). I don't see why you couldn't mix XMPP and REST for the same conference, but I haven't tried.

Regards,
Boris

ยทยทยท

On 12/01/2017 08:30, John Hemming wrote: