[jitsi-users] New user and questions


#1

Hi,

Many thanks to the devs on Jitsi for a great project.

I'm testing Jitsi to use as a secure corporate tool for voice, chat, file and screen share.
We are testing a small model structure first, 7 users.
We may be a candidate to offer some dev funding if we succeed.

I have OpenFire current on a U.S. Server 2003 vps on our dedicated DC server.
I'm hoping to avoid the larger Jitisi Meet or Video bridge model for now.

We've had some success with XMPP

My question is on use / availability of SIP with or versus XMPP
Our server is single IP address public, standard windows firewall.
Hosting Jingle or Stun plugins seems to be out of reach for now.

We did test opening an account at jit.si, but SIP does not auth there.
(Jitsi simply replies with bad password) arrrg :frowning:

Logging in on jit.si as XMPP works.
We are finding some trouble with Nat traversal on some users.
Shared screen or voice calls tend to fail for ICE related.
Possibly due to voice hardware setup on Win7 (testing)

Q1) Does the jit.si account provide SIP via XMPP automatically?
Q2) Is there a way to use our OpenFire server but leverage jit.si SIP benefits?
Q3) Would VPN with registrarless allow us to equip global users with Jitsi native SIP or too slow?

Any suggestions welcome, again only voice, chat, file and screen share required.
Might add video later on with Video Bridge / Meet

Thanks for any suggestions or questions.

Mike


#2

Hi Mike,

Let me jump in by suggesting that if you want to play with setting up your
own SIP server inside the firewall, things couldn´t get easier than this:

http://pbxinaflash.com/community/index.php?threads/piaf-centos-7-incredible-pbx-news.15290/page-3#post-98849

This Virtualbox image (see above) allows you to easily set up Asterisk in a
contained VM, ready to run.

Hope this helps...
FC

···

On Wed, Apr 8, 2015 at 10:11 AM, <afpteam@sbcglobal.net> wrote:

My question is on use / availability of SIP with or versus XMPP
Our server is single IP address public, standard windows firewall.
Hosting Jingle or Stun plugins seems to be out of reach for now.

We did test opening an account at jit.si, but SIP does not auth there.
(Jitsi simply replies with bad password) arrrg :frowning:

--
During times of Universal Deceit, telling the truth becomes a revolutionary
act
Durante épocas de Engaño Universal, decir la verdad se convierte en un Acto
Revolucionario
- George Orwell


#3

Many thanks to the devs on Jitsi for a great project.

Thanks for your kind words!

I'm testing Jitsi to use as a secure corporate tool for voice, chat, file
and screen share.
We are testing a small model structure first, 7 users.
We may be a candidate to offer some dev funding if we succeed.

I have OpenFire current on a U.S. Server 2003 vps on our dedicated DC
server. I'm hoping to avoid the larger Jitisi Meet or Video bridge model
for now.

We've had some success with XMPP

My question is on use / availability of SIP with or versus XMPP
Our server is single IP address public, standard windows firewall.
Hosting Jingle or Stun plugins seems to be out of reach for now.

We did test opening an account at jit.si, but SIP does not auth there.
(Jitsi simply replies with bad password) arrrg :frowning:

Logging in on jit.si as XMPP works.
We are finding some trouble with Nat traversal on some users.
Shared screen or voice calls tend to fail for ICE related.
Possibly due to voice hardware setup on Win7 (testing)

Q1) Does the jit.si account provide SIP via XMPP automatically?

jit.si doesn't offer any SIP service, it is XMPP only.

Q2) Is
there a way to use our OpenFire server but leverage jit.si SIP benefits?

No, as jit.si doesn't offer any SIP service.

Q3) Would VPN with registrarless allow us to equip global users with
Jitsi native SIP or too slow?

Registrarless accounts only work on a network where no NAT and firewalls are involved and intended for experiments only.

Any suggestions welcome, again only voice, chat, file and screen share
required. Might add video later on with Video Bridge / Meet

OpenFire (or any other XMPP server) with a Jingle Nodes plugin should work just fine, even with only one IP address. You need to allow incoming UDP packets to OpenFire on a broad range (probably configurable in the Jingle Nodes plugin), as well as obviously some other required ports.

If you ever intend on performing calls to other networks (calling landlines, cell phones, incoming calls), I suggest you investigate setting up a SIP server like Asterisk for voice and use XMPP for chat and presence and combine them with CUSAX.

Thanks for any suggestions or questions.

Mike

Ingo


#4

Thanks Ingo,

I apparently have a misunderstanding of the SIP roll in Jitsi.

Given the concern of traversal affecting voice and screen share, doesn't adding a SIP provider account to Jitsi work to solve this?

Again we're seeing "ICE failures" on some users trying to start voice or screen share.
My thought was including a SIP provider might improve this inside Jitsi connectivity.

In the interim, I will look again at OpenFire's Jingle plugin to see why I thought it was out of scope for us.

[Quote Ingo:]
Registrarless accounts only work on a network where no NAT and firewalls are involved and intended for experiments only.
[End Quote]

I'm thinking VPN might provide that traversal transparency but then this is basically eliminating the problem if so and I "thought" would open the door to permit registrarless to operate over the web, unless the client then assumes higher connection which would stumble reliability. Make sense or no?

Thanks again,

Mike

···

----- Original Message ----- From: "Ingo Bauersachs" <ingo@jitsi.org>
To: <afpteam@sbcglobal.net>; "'Jitsi Users'" <users@jitsi.org>
Sent: Wednesday, April 08, 2015 9:38 AM
Subject: RE: [jitsi-users] New user and questions

Many thanks to the devs on Jitsi for a great project.

Thanks for your kind words!

I'm testing Jitsi to use as a secure corporate tool for voice, chat, file
and screen share.
We are testing a small model structure first, 7 users.
We may be a candidate to offer some dev funding if we succeed.

I have OpenFire current on a U.S. Server 2003 vps on our dedicated DC
server. I'm hoping to avoid the larger Jitisi Meet or Video bridge model
for now.

We've had some success with XMPP

My question is on use / availability of SIP with or versus XMPP
Our server is single IP address public, standard windows firewall.
Hosting Jingle or Stun plugins seems to be out of reach for now.

We did test opening an account at jit.si, but SIP does not auth there.
(Jitsi simply replies with bad password) arrrg :frowning:

Logging in on jit.si as XMPP works.
We are finding some trouble with Nat traversal on some users.
Shared screen or voice calls tend to fail for ICE related.
Possibly due to voice hardware setup on Win7 (testing)

Q1) Does the jit.si account provide SIP via XMPP automatically?

jit.si doesn't offer any SIP service, it is XMPP only.

Q2) Is
there a way to use our OpenFire server but leverage jit.si SIP benefits?

No, as jit.si doesn't offer any SIP service.

Q3) Would VPN with registrarless allow us to equip global users with
Jitsi native SIP or too slow?

Registrarless accounts only work on a network where no NAT and firewalls are involved and intended for experiments only.

Any suggestions welcome, again only voice, chat, file and screen share
required. Might add video later on with Video Bridge / Meet

OpenFire (or any other XMPP server) with a Jingle Nodes plugin should work just fine, even with only one IP address. You need to allow incoming UDP packets to OpenFire on a broad range (probably configurable in the Jingle Nodes plugin), as well as obviously some other required ports.

If you ever intend on performing calls to other networks (calling landlines, cell phones, incoming calls), I suggest you investigate setting up a SIP server like Asterisk for voice and use XMPP for chat and presence and combine them with CUSAX.

Thanks for any suggestions or questions.

Mike

Ingo


#5

Hey Mike,

Thanks Ingo,

I apparently have a misunderstanding of the SIP roll in Jitsi.

Given the concern of traversal affecting voice and screen share, doesn't
adding a SIP provider account to Jitsi work to solve this?

I am not sure I understand your question. If you mean: adding a sip
provider as opposed to doing registrarless, then yes, this generally
helps as most SIP providers provide hosted NAT traversal. You have to
make sure you actually use it though.

Again we're seeing "ICE failures" on some users trying to start voice or
screen share.

First, just so you know, ICE is only supported with XMPP, so if you
are seeing this you are not using SIP. Second, an ICE failure means
there was no possible path between you and your peer. There can be
various reasons for this.

My thought was including a SIP provider might improve this inside Jitsi
connectivity.

It can. Only if the SIP provider has Hosted NAT Traversal though *and*
if your network allows for UDP packets to come and go.

In the interim, I will look again at OpenFire's Jingle plugin to see why I
thought it was out of scope for us.

[Quote Ingo:]
Registrarless accounts only work on a network where no NAT and firewalls are
involved and intended for experiments only.
[End Quote]

I'm thinking VPN might provide that traversal transparency but then this is
basically eliminating the problem if so and I "thought" would open the door
to permit registrarless to operate over the web, unless the client then
assumes higher connection which would stumble reliability. Make sense or
no?

We really discourage people from using RegistrarLess accounts as they
are only there for experimentational purposes.

That said, if you try it and it works for you then ... cool I guess :slight_smile:

Emil

···

On Wed, Apr 8, 2015 at 4:08 PM, <afpteam@sbcglobal.net> wrote:

Thanks again,

Mike

----- Original Message ----- From: "Ingo Bauersachs" <ingo@jitsi.org>
To: <afpteam@sbcglobal.net>; "'Jitsi Users'" <users@jitsi.org>
Sent: Wednesday, April 08, 2015 9:38 AM
Subject: RE: [jitsi-users] New user and questions

Many thanks to the devs on Jitsi for a great project.

Thanks for your kind words!

I'm testing Jitsi to use as a secure corporate tool for voice, chat, file
and screen share.
We are testing a small model structure first, 7 users.
We may be a candidate to offer some dev funding if we succeed.

I have OpenFire current on a U.S. Server 2003 vps on our dedicated DC
server. I'm hoping to avoid the larger Jitisi Meet or Video bridge model
for now.

We've had some success with XMPP

My question is on use / availability of SIP with or versus XMPP
Our server is single IP address public, standard windows firewall.
Hosting Jingle or Stun plugins seems to be out of reach for now.

We did test opening an account at jit.si, but SIP does not auth there.
(Jitsi simply replies with bad password) arrrg :frowning:

Logging in on jit.si as XMPP works.
We are finding some trouble with Nat traversal on some users.
Shared screen or voice calls tend to fail for ICE related.
Possibly due to voice hardware setup on Win7 (testing)

Q1) Does the jit.si account provide SIP via XMPP automatically?

jit.si doesn't offer any SIP service, it is XMPP only.

Q2) Is
there a way to use our OpenFire server but leverage jit.si SIP benefits?

No, as jit.si doesn't offer any SIP service.

Q3) Would VPN with registrarless allow us to equip global users with
Jitsi native SIP or too slow?

Registrarless accounts only work on a network where no NAT and firewalls are
involved and intended for experiments only.

Any suggestions welcome, again only voice, chat, file and screen share
required. Might add video later on with Video Bridge / Meet

OpenFire (or any other XMPP server) with a Jingle Nodes plugin should work
just fine, even with only one IP address. You need to allow incoming UDP
packets to OpenFire on a broad range (probably configurable in the Jingle
Nodes plugin), as well as obviously some other required ports.

If you ever intend on performing calls to other networks (calling landlines,
cell phones, incoming calls), I suggest you investigate setting up a SIP
server like Asterisk for voice and use XMPP for chat and presence and
combine them with CUSAX.

Thanks for any suggestions or questions.

Mike

Ingo

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

--
https://jitsi.org


#6

Thanks Emil,

I think you and ingo have me closing in on this, finally.

If I'm understanding, an account for each user on our XMPP server plus each user with account to the same SIP provider, creates a viable combination for both accounts in Jitsi, given configurations and porting are sorted to make use of both as a corporate structure supporting our dedicated remote users. This means finding a SIP provider or two that play nice with Jitsi, if there is a current list available by chance you might reference?

Previously it was suggested to use Jingle Nodes to help. After some research I found Jingle was failing to find the public facing IP addy on this 2003 VPS, (assuming multi-homed) under the hypervisor. Supports on the web suggest Jingle on server 2003 "should" not be case sensitive to naming as it affects Nix users, but WILL need identical naming of Openfire environment versus Host name as a FQDN structure in the Openfire server configuration. In this case the FQDN is "myhost.example.com". When I try to rename the windows server in the server configuration panel it rejects the presence of the dot character and forces the name back to simply "example" with a "dot" Windows appends to the end. I can of course update the host file to include the FQDN but I'm uncertain this will suffice the issue to patch back to Jingle in Openfire if it needs to match up the DNS name proper and all it has is matching "example".

Any chance you have heard of a workaround on this? Understandably not a Jitsi issue, but affecting Jitsi downstream all the same if Jingle would be a benefit.

Past these two things, we're finding Jitsi to be a very desirable tool for the dedicated efforts put to it. I will eventually move our corporate services to Debian, so a lot of these issues will be gone at that point.

Thank you again for the timely responses on user-list.

Mike

···

----- Original Message ----- From: "Emil Ivov" <emcho@jitsi.org>
To: <afpteam@sbcglobal.net>; "Jitsi Users" <users@jitsi.org>
Sent: Wednesday, April 08, 2015 11:56 AM
Subject: Re: [jitsi-users] New user and questions

Hey Mike,

On Wed, Apr 8, 2015 at 4:08 PM, <afpteam@sbcglobal.net> wrote:

Thanks Ingo,

I apparently have a misunderstanding of the SIP roll in Jitsi.

Given the concern of traversal affecting voice and screen share, doesn't
adding a SIP provider account to Jitsi work to solve this?

I am not sure I understand your question. If you mean: adding a sip
provider as opposed to doing registrarless, then yes, this generally
helps as most SIP providers provide hosted NAT traversal. You have to
make sure you actually use it though.

Again we're seeing "ICE failures" on some users trying to start voice or
screen share.

First, just so you know, ICE is only supported with XMPP, so if you
are seeing this you are not using SIP. Second, an ICE failure means
there was no possible path between you and your peer. There can be
various reasons for this.

My thought was including a SIP provider might improve this inside Jitsi
connectivity.

It can. Only if the SIP provider has Hosted NAT Traversal though *and*
if your network allows for UDP packets to come and go.

In the interim, I will look again at OpenFire's Jingle plugin to see why I
thought it was out of scope for us.

[Quote Ingo:]
Registrarless accounts only work on a network where no NAT and firewalls are
involved and intended for experiments only.
[End Quote]

I'm thinking VPN might provide that traversal transparency but then this is
basically eliminating the problem if so and I "thought" would open the door
to permit registrarless to operate over the web, unless the client then
assumes higher connection which would stumble reliability. Make sense or
no?

We really discourage people from using RegistrarLess accounts as they
are only there for experimentational purposes.

That said, if you try it and it works for you then ... cool I guess :slight_smile:

Emil

Thanks again,

Mike

----- Original Message ----- From: "Ingo Bauersachs" <ingo@jitsi.org>
To: <afpteam@sbcglobal.net>; "'Jitsi Users'" <users@jitsi.org>
Sent: Wednesday, April 08, 2015 9:38 AM
Subject: RE: [jitsi-users] New user and questions

Many thanks to the devs on Jitsi for a great project.

Thanks for your kind words!

I'm testing Jitsi to use as a secure corporate tool for voice, chat, file
and screen share.
We are testing a small model structure first, 7 users.
We may be a candidate to offer some dev funding if we succeed.

I have OpenFire current on a U.S. Server 2003 vps on our dedicated DC
server. I'm hoping to avoid the larger Jitisi Meet or Video bridge model
for now.

We've had some success with XMPP

My question is on use / availability of SIP with or versus XMPP
Our server is single IP address public, standard windows firewall.
Hosting Jingle or Stun plugins seems to be out of reach for now.

We did test opening an account at jit.si, but SIP does not auth there.
(Jitsi simply replies with bad password) arrrg :frowning:

Logging in on jit.si as XMPP works.
We are finding some trouble with Nat traversal on some users.
Shared screen or voice calls tend to fail for ICE related.
Possibly due to voice hardware setup on Win7 (testing)

Q1) Does the jit.si account provide SIP via XMPP automatically?

jit.si doesn't offer any SIP service, it is XMPP only.

Q2) Is
there a way to use our OpenFire server but leverage jit.si SIP benefits?

No, as jit.si doesn't offer any SIP service.

Q3) Would VPN with registrarless allow us to equip global users with
Jitsi native SIP or too slow?

Registrarless accounts only work on a network where no NAT and firewalls are
involved and intended for experiments only.

Any suggestions welcome, again only voice, chat, file and screen share
required. Might add video later on with Video Bridge / Meet

OpenFire (or any other XMPP server) with a Jingle Nodes plugin should work
just fine, even with only one IP address. You need to allow incoming UDP
packets to OpenFire on a broad range (probably configurable in the Jingle
Nodes plugin), as well as obviously some other required ports.

If you ever intend on performing calls to other networks (calling landlines,
cell phones, incoming calls), I suggest you investigate setting up a SIP
server like Asterisk for voice and use XMPP for chat and presence and
combine them with CUSAX.

Thanks for any suggestions or questions.

Mike

Ingo

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

--
https://jitsi.org


#7

Hey Mike,

Thanks Emil,

I think you and ingo have me closing in on this, finally.

If I'm understanding, an account for each user on our XMPP server plus each
user with account to the same SIP provider, creates a viable combination for
both accounts in Jitsi, given configurations and porting are sorted to make
use of both as a corporate structure supporting our dedicated remote users.

The combination of SIP and XMPP is also possible and something that
we've worked on:

https://tools.ietf.org/html/rfc7081

here's how to set it up in Jitsi:

https://jitsi.org/cusax

This means finding a SIP provider or two that play nice with Jitsi, if there
is a current list available by chance you might reference?

Personally, I normally recommend ippi.com. sip2sip.info and iptel.org
are also nice. An actual CUSAX deployment would require you to have
control on your SIP server though.

Previously it was suggested to use Jingle Nodes to help. After some
research I found Jingle was failing to find the public facing IP addy on
this 2003 VPS, (assuming multi-homed) under the hypervisor. Supports on the
web suggest Jingle on server 2003 "should" not be case sensitive to naming
as it affects Nix users, but WILL need identical naming of Openfire
environment versus Host name as a FQDN structure in the Openfire server
configuration. In this case the FQDN is "myhost.example.com". When I try
to rename the windows server in the server configuration panel it rejects
the presence of the dot character and forces the name back to simply
"example" with a "dot" Windows appends to the end. I can of course update
the host file to include the FQDN but I'm uncertain this will suffice the
issue to patch back to Jingle in Openfire if it needs to match up the DNS
name proper and all it has is matching "example".

Any chance you have heard of a workaround on this? Understandably not a
Jitsi issue, but affecting Jitsi downstream all the same if Jingle would be
a benefit.

Sorry, I didn't understand this part at all so I am afraid I have no solutions.

Past these two things, we're finding Jitsi to be a very desirable tool for
the dedicated efforts put to it. I will eventually move our corporate
services to Debian, so a lot of these issues will be gone at that point.

Thank you again for the timely responses on user-list.

Our pleasure!

Emil

···

On Wed, Apr 8, 2015 at 6:44 PM, <afpteam@sbcglobal.net> wrote:

----- Original Message ----- From: "Emil Ivov" <emcho@jitsi.org>
To: <afpteam@sbcglobal.net>; "Jitsi Users" <users@jitsi.org>
Sent: Wednesday, April 08, 2015 11:56 AM
Subject: Re: [jitsi-users] New user and questions

Hey Mike,

On Wed, Apr 8, 2015 at 4:08 PM, <afpteam@sbcglobal.net> wrote:

Thanks Ingo,

I apparently have a misunderstanding of the SIP roll in Jitsi.

Given the concern of traversal affecting voice and screen share, doesn't
adding a SIP provider account to Jitsi work to solve this?

I am not sure I understand your question. If you mean: adding a sip
provider as opposed to doing registrarless, then yes, this generally
helps as most SIP providers provide hosted NAT traversal. You have to
make sure you actually use it though.

Again we're seeing "ICE failures" on some users trying to start voice or
screen share.

First, just so you know, ICE is only supported with XMPP, so if you
are seeing this you are not using SIP. Second, an ICE failure means
there was no possible path between you and your peer. There can be
various reasons for this.

My thought was including a SIP provider might improve this inside Jitsi
connectivity.

It can. Only if the SIP provider has Hosted NAT Traversal though *and*
if your network allows for UDP packets to come and go.

In the interim, I will look again at OpenFire's Jingle plugin to see why
I
thought it was out of scope for us.

[Quote Ingo:]
Registrarless accounts only work on a network where no NAT and firewalls
are
involved and intended for experiments only.
[End Quote]

I'm thinking VPN might provide that traversal transparency but then this
is
basically eliminating the problem if so and I "thought" would open the
door
to permit registrarless to operate over the web, unless the client then
assumes higher connection which would stumble reliability. Make sense or
no?

We really discourage people from using RegistrarLess accounts as they
are only there for experimentational purposes.

That said, if you try it and it works for you then ... cool I guess :slight_smile:

Emil

Thanks again,

Mike

----- Original Message ----- From: "Ingo Bauersachs" <ingo@jitsi.org>
To: <afpteam@sbcglobal.net>; "'Jitsi Users'" <users@jitsi.org>
Sent: Wednesday, April 08, 2015 9:38 AM
Subject: RE: [jitsi-users] New user and questions

Many thanks to the devs on Jitsi for a great project.

Thanks for your kind words!

I'm testing Jitsi to use as a secure corporate tool for voice, chat,
file
and screen share.
We are testing a small model structure first, 7 users.
We may be a candidate to offer some dev funding if we succeed.

I have OpenFire current on a U.S. Server 2003 vps on our dedicated DC
server. I'm hoping to avoid the larger Jitisi Meet or Video bridge model
for now.

We've had some success with XMPP

My question is on use / availability of SIP with or versus XMPP
Our server is single IP address public, standard windows firewall.
Hosting Jingle or Stun plugins seems to be out of reach for now.

We did test opening an account at jit.si, but SIP does not auth there.
(Jitsi simply replies with bad password) arrrg :frowning:

Logging in on jit.si as XMPP works.
We are finding some trouble with Nat traversal on some users.
Shared screen or voice calls tend to fail for ICE related.
Possibly due to voice hardware setup on Win7 (testing)

Q1) Does the jit.si account provide SIP via XMPP automatically?

jit.si doesn't offer any SIP service, it is XMPP only.

Q2) Is
there a way to use our OpenFire server but leverage jit.si SIP benefits?

No, as jit.si doesn't offer any SIP service.

Q3) Would VPN with registrarless allow us to equip global users with
Jitsi native SIP or too slow?

Registrarless accounts only work on a network where no NAT and firewalls
are
involved and intended for experiments only.

Any suggestions welcome, again only voice, chat, file and screen share
required. Might add video later on with Video Bridge / Meet

OpenFire (or any other XMPP server) with a Jingle Nodes plugin should
work
just fine, even with only one IP address. You need to allow incoming UDP
packets to OpenFire on a broad range (probably configurable in the Jingle
Nodes plugin), as well as obviously some other required ports.

If you ever intend on performing calls to other networks (calling
landlines,
cell phones, incoming calls), I suggest you investigate setting up a SIP
server like Asterisk for voice and use XMPP for chat and presence and
combine them with CUSAX.

Thanks for any suggestions or questions.

Mike

Ingo

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

--
https://jitsi.org

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

--
https://jitsi.org


#8

Hi,

Testing on sip2sip, looking to confirm if presence via https://xcap.sipthor.net/xcap-root/ got sorted.

When configuring under Account > Presence some note past issues fail.

Seeing same here, Error in SIP contact storage ".../xcap-root/scap-caps/global/index. For null"

Is there a config guide jitsi / sip2sip?
Is this possibly configuration dns proxy?
Enable presence simple?
Force peer-to-peer?

Seeemed simple unless the process never got sorted, but some reported it was working for them.

Thank you,

Mike


#9

Thanks for your work on the above,and providing the pointers, Emil!.
Always a pleasure lurking on this list.... :o)

FC

···

On Thu, Apr 9, 2015 at 3:06 AM, Emil Ivov <emcho@jitsi.org> wrote:

The combination of SIP and XMPP is also possible and something that
we've worked on:

https://tools.ietf.org/html/rfc7081

here's how to set it up in Jitsi:

https://jitsi.org/cusax

--
During times of Universal Deceit, telling the truth becomes a revolutionary
act
- George Orwell


#10

Thanks Emil, for the CUSAX reference.

I'm looking into it.

Just to clarify...

[Quote: Emil]

Sorry, I didn't understand this part at all so I am afraid I have no solutions.

[Quote]

Openfire has two variables in config jingle needs to see match,
Actually so does Openfire as far as that goes...

A) Openfire's server name ...
and
B) Host name, derived by reading the Windows "Computer Name".

Openfire doesn't let us alter the "Host Name" read during config.
The windows "computer name" does not adhere to FQDN standards.
Hence, there is no way to configure Openfire to satisfy Jingle.
Without this alignment, Jingle cannot confirm multihomed scenarios.
As such, jingle fails to initiate.
This is a windows only issue, left unresolved in Jingle / Openfire.

Openfire and Jingle should permit the user to override and store these values manually rather than trying to "allocate" during configuration, since computer name allocation in windows is so broken. In VPS scenarios where the machine is deemed "multi-homed" this becomes especially problematic as jingle needs to know it's associating a virtual machine's public facing IP addy separate of it's hypervisor control IP addy.

There is probably a solution to be found in altering the Openfire / jingle config and / or Host file alias after installations, but then you have to maintain a hack through updates which is ridiculous. Worse, Openfire doesn't seem to be interested in maintaining or improving this aspect of their server design or the Jingle plugin basis which appears to be unmaintained at this point.

Thanks for the CUSAX reference.
I'm looking into it.

Mike

···

----- Original Message ----- From: "Emil Ivov" <emcho@jitsi.org>
To: <afpteam@sbcglobal.net>; "Jitsi Users" <users@jitsi.org>
Sent: Thursday, April 09, 2015 2:06 AM
Subject: Re: [jitsi-users] New user and questions

Hey Mike,

On Wed, Apr 8, 2015 at 6:44 PM, <afpteam@sbcglobal.net> wrote:

Thanks Emil,

I think you and ingo have me closing in on this, finally.

If I'm understanding, an account for each user on our XMPP server plus each
user with account to the same SIP provider, creates a viable combination for
both accounts in Jitsi, given configurations and porting are sorted to make
use of both as a corporate structure supporting our dedicated remote users.

The combination of SIP and XMPP is also possible and something that
we've worked on:

https://tools.ietf.org/html/rfc7081

here's how to set it up in Jitsi:

https://jitsi.org/cusax

This means finding a SIP provider or two that play nice with Jitsi, if there
is a current list available by chance you might reference?

Personally, I normally recommend ippi.com. sip2sip.info and iptel.org
are also nice. An actual CUSAX deployment would require you to have
control on your SIP server though.

Previously it was suggested to use Jingle Nodes to help. After some
research I found Jingle was failing to find the public facing IP addy on
this 2003 VPS, (assuming multi-homed) under the hypervisor. Supports on the
web suggest Jingle on server 2003 "should" not be case sensitive to naming
as it affects Nix users, but WILL need identical naming of Openfire
environment versus Host name as a FQDN structure in the Openfire server
configuration. In this case the FQDN is "myhost.example.com". When I try
to rename the windows server in the server configuration panel it rejects
the presence of the dot character and forces the name back to simply
"example" with a "dot" Windows appends to the end. I can of course update
the host file to include the FQDN but I'm uncertain this will suffice the
issue to patch back to Jingle in Openfire if it needs to match up the DNS
name proper and all it has is matching "example".

Any chance you have heard of a workaround on this? Understandably not a
Jitsi issue, but affecting Jitsi downstream all the same if Jingle would be
a benefit.

Sorry, I didn't understand this part at all so I am afraid I have no solutions.

Past these two things, we're finding Jitsi to be a very desirable tool for
the dedicated efforts put to it. I will eventually move our corporate
services to Debian, so a lot of these issues will be gone at that point.

Thank you again for the timely responses on user-list.

Our pleasure!

Emil

----- Original Message ----- From: "Emil Ivov" <emcho@jitsi.org>
To: <afpteam@sbcglobal.net>; "Jitsi Users" <users@jitsi.org>
Sent: Wednesday, April 08, 2015 11:56 AM
Subject: Re: [jitsi-users] New user and questions

Hey Mike,

On Wed, Apr 8, 2015 at 4:08 PM, <afpteam@sbcglobal.net> wrote:

Thanks Ingo,

I apparently have a misunderstanding of the SIP roll in Jitsi.

Given the concern of traversal affecting voice and screen share, doesn't
adding a SIP provider account to Jitsi work to solve this?

I am not sure I understand your question. If you mean: adding a sip
provider as opposed to doing registrarless, then yes, this generally
helps as most SIP providers provide hosted NAT traversal. You have to
make sure you actually use it though.

Again we're seeing "ICE failures" on some users trying to start voice or
screen share.

First, just so you know, ICE is only supported with XMPP, so if you
are seeing this you are not using SIP. Second, an ICE failure means
there was no possible path between you and your peer. There can be
various reasons for this.

My thought was including a SIP provider might improve this inside Jitsi
connectivity.

It can. Only if the SIP provider has Hosted NAT Traversal though *and*
if your network allows for UDP packets to come and go.

In the interim, I will look again at OpenFire's Jingle plugin to see why
I
thought it was out of scope for us.

[Quote Ingo:]
Registrarless accounts only work on a network where no NAT and firewalls
are
involved and intended for experiments only.
[End Quote]

I'm thinking VPN might provide that traversal transparency but then this
is
basically eliminating the problem if so and I "thought" would open the
door
to permit registrarless to operate over the web, unless the client then
assumes higher connection which would stumble reliability. Make sense or
no?

We really discourage people from using RegistrarLess accounts as they
are only there for experimentational purposes.

That said, if you try it and it works for you then ... cool I guess :slight_smile:

Emil

Thanks again,

Mike

----- Original Message ----- From: "Ingo Bauersachs" <ingo@jitsi.org>
To: <afpteam@sbcglobal.net>; "'Jitsi Users'" <users@jitsi.org>
Sent: Wednesday, April 08, 2015 9:38 AM
Subject: RE: [jitsi-users] New user and questions

Many thanks to the devs on Jitsi for a great project.

Thanks for your kind words!

I'm testing Jitsi to use as a secure corporate tool for voice, chat,
file
and screen share.
We are testing a small model structure first, 7 users.
We may be a candidate to offer some dev funding if we succeed.

I have OpenFire current on a U.S. Server 2003 vps on our dedicated DC
server. I'm hoping to avoid the larger Jitisi Meet or Video bridge model
for now.

We've had some success with XMPP

My question is on use / availability of SIP with or versus XMPP
Our server is single IP address public, standard windows firewall.
Hosting Jingle or Stun plugins seems to be out of reach for now.

We did test opening an account at jit.si, but SIP does not auth there.
(Jitsi simply replies with bad password) arrrg :frowning:

Logging in on jit.si as XMPP works.
We are finding some trouble with Nat traversal on some users.
Shared screen or voice calls tend to fail for ICE related.
Possibly due to voice hardware setup on Win7 (testing)

Q1) Does the jit.si account provide SIP via XMPP automatically?

jit.si doesn't offer any SIP service, it is XMPP only.

Q2) Is
there a way to use our OpenFire server but leverage jit.si SIP benefits?

No, as jit.si doesn't offer any SIP service.

Q3) Would VPN with registrarless allow us to equip global users with
Jitsi native SIP or too slow?

Registrarless accounts only work on a network where no NAT and firewalls
are
involved and intended for experiments only.

Any suggestions welcome, again only voice, chat, file and screen share
required. Might add video later on with Video Bridge / Meet

OpenFire (or any other XMPP server) with a Jingle Nodes plugin should
work
just fine, even with only one IP address. You need to allow incoming UDP
packets to OpenFire on a broad range (probably configurable in the Jingle
Nodes plugin), as well as obviously some other required ports.

If you ever intend on performing calls to other networks (calling
landlines,
cell phones, incoming calls), I suggest you investigate setting up a SIP
server like Asterisk for voice and use XMPP for chat and presence and
combine them with CUSAX.

Thanks for any suggestions or questions.

Mike

Ingo

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

--
https://jitsi.org

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

--
https://jitsi.org


#11

[Quote: Emil]

Sorry, I didn't understand this part at all so I am afraid I have no
solutions.

[Quote]

Openfire has two variables in config jingle needs to see match,
Actually so does Openfire as far as that goes...

A) Openfire's server name ...
and
B) Host name, derived by reading the Windows "Computer Name".

Openfire doesn't let us alter the "Host Name" read during config.
The windows "computer name" does not adhere to FQDN standards.
Hence, there is no way to configure Openfire to satisfy Jingle.
Without this alignment, Jingle cannot confirm multihomed scenarios.
As such, jingle fails to initiate.
This is a windows only issue, left unresolved in Jingle / Openfire.

The only difference the Jingle Nodes plugin makes between Windows and Linux is the IP binding of the relay channels: on Linux it binds on all interfaces, while on Windows it only uses the configured or detected public IP address.

Openfire and Jingle should permit the user to override and store these
values manually rather than trying to "allocate" during configuration, since
computer name allocation in windows is so broken. In VPS scenarios where
the machine is deemed "multi-homed" this becomes especially problematic as
jingle needs to know it's associating a virtual machine's public facing IP
addy separate of it's hypervisor control IP addy.

I really don't know what you're talking about here. Windows' computer name allocation is not broken in any way. You give the host a name, and a hostname can't have dots in it. If you want to configure an FQDN, set a DNS suffix.

Openfire does not care about the hostname. All that matter is the XMPP domain name, and you can freely configure that during the setup. Independent of the hosts name or its FQDN.

While I don't use Jingle Nodes myself, a glance at the plugin's source code doesn't indicate that it relies on a hostname anywhere. All you need to do is to configure your public IP in the plugin's configuration. Given that AFAIK the Jingle only uses ip/port pairs, this is no surprise.

There is probably a solution to be found in altering the Openfire / jingle
config and / or Host file alias after installations, but then you have to
maintain a hack through updates which is ridiculous. Worse, Openfire doesn't
seem to be interested in maintaining or improving this aspect of their
server design or the Jingle plugin basis which appears to be unmaintained at
this point.

Thanks for the CUSAX reference.
I'm looking into it.

Mike

Ingo


#12

Hi ingo,

[quote ingo:]
Openfire does not care about the hostname.

The only difference the Jingle Nodes plugin makes between Windows and Linux is the IP binding of the relay channels: on Linux it binds on all interfaces, while on Windows it only uses the configured or detected public IP address.

[/quote]

I thought so too.

I won't dispute the Computer name method in Windows "works", until you step into VMs having host names auto indexed on deployment for independant users assigning names. The vm's domain name registration becomes an independant issue of the "assigned" computer name mismatching the VM host name declaration and then host file alias alignment. Once the Openfire is installed and jingle identifies the correct public facing IP, jingle SHOULD NOT return a response of --- "Nodes Requires a Public IP for Internet Calling. Public IP Found: NONE"--- while showing jingle KNOWS the correct VM public IP address and no further output I could find in logs. Telling jingle to update and accept the ip address showing does nothing of course, it's already correct.

It was then suggested the problem was attributable to the xmpp server name versus host name in Openfire not matching.

Admittedly after renaming the VM and matching up the host file before installing Openfire to make sure the server and host name matched in Openfire, jingle STILL refused to come online with the same indication. The issue has several community queries with nobody as maintainer, so most queries to the issue dead end.

There has to be more to it than Openfire matching server name as host name or simply a matter of IP/port pairs. Actually it seems to me xmpp server name and host name should NOT match if the Openfire server is to have assignable independence from the domain / sub domain structure and end up properly associated with a DNS structure.

While I don't use Jingle Nodes myself, a glance at the plugin's source code doesn't indicate that it relies on a hostname anywhere. All you need to do is to configure your public IP in the plugin's configuration. Given that AFAIK the Jingle only uses ip/port pairs, this is no surprise.

Again, public facing ip of the vm is showing "correct", all ports are unrestricted during testing, but the plugin complains with no further indication.

I'm simply trying to increase potential traversal options using jingle, so I apologize huge we're drifting off topic.

This certainly is not a jitsi issue to fight with and I truly appreciate efforts offered here, not wanting to trash up the jitsi user-list. :frowning:

Mike

···

----- Original Message ----- From: "Ingo Bauersachs" <ingo@jitsi.org>
To: "'Jitsi Users'" <users@jitsi.org>
Cc: <afpteam@sbcglobal.net>
Sent: Thursday, April 09, 2015 6:50 AM
Subject: RE: [jitsi-users] New user and questions

[Quote: Emil]

Sorry, I didn't understand this part at all so I am afraid I have no
solutions.

[Quote]

Openfire has two variables in config jingle needs to see match,
Actually so does Openfire as far as that goes...

A) Openfire's server name ...
and
B) Host name, derived by reading the Windows "Computer Name".

Openfire doesn't let us alter the "Host Name" read during config.
The windows "computer name" does not adhere to FQDN standards.
Hence, there is no way to configure Openfire to satisfy Jingle.
Without this alignment, Jingle cannot confirm multihomed scenarios.
As such, jingle fails to initiate.
This is a windows only issue, left unresolved in Jingle / Openfire.

The only difference the Jingle Nodes plugin makes between Windows and Linux is the IP binding of the relay channels: on Linux it binds on all interfaces, while on Windows it only uses the configured or detected public IP address.

Openfire and Jingle should permit the user to override and store these
values manually rather than trying to "allocate" during configuration, since
computer name allocation in windows is so broken. In VPS scenarios where
the machine is deemed "multi-homed" this becomes especially problematic as
jingle needs to know it's associating a virtual machine's public facing IP
addy separate of it's hypervisor control IP addy.

I really don't know what you're talking about here. Windows' computer name allocation is not broken in any way. You give the host a name, and a hostname can't have dots in it. If you want to configure an FQDN, set a DNS suffix.

Openfire does not care about the hostname. All that matter is the XMPP domain name, and you can freely configure that during the setup. Independent of the hosts name or its FQDN.

While I don't use Jingle Nodes myself, a glance at the plugin's source code doesn't indicate that it relies on a hostname anywhere. All you need to do is to configure your public IP in the plugin's configuration. Given that AFAIK the Jingle only uses ip/port pairs, this is no surprise.

There is probably a solution to be found in altering the Openfire / jingle
config and / or Host file alias after installations, but then you have to
maintain a hack through updates which is ridiculous. Worse, Openfire doesn't
seem to be interested in maintaining or improving this aspect of their
server design or the Jingle plugin basis which appears to be unmaintained at
this point.

Thanks for the CUSAX reference.
I'm looking into it.

Mike

Ingo


#13

[quote ingo:]
Openfire does not care about the hostname.

The only difference the Jingle Nodes plugin makes between Windows and Linux
is the IP binding of the relay channels: on Linux it binds on all
interfaces, while on Windows it only uses the configured or detected public
IP address.

[/quote]

I thought so too.

I won't dispute the Computer name method in Windows "works", until you step
into VMs having host names auto indexed on deployment for independant users
assigning names. The vm's domain name registration becomes an independant
issue of the "assigned" computer name mismatching the VM host name
declaration and then host file alias alignment.

I still can't follow you. Again, the hostname has absolutely nothing to do with Openfire.

Once the Openfire is
installed and jingle identifies the correct public facing IP, jingle SHOULD
NOT return a response of --- "Nodes Requires a Public IP for Internet
Calling. Public IP Found: NONE"--- while showing jingle KNOWS the correct VM
public IP address and no further output I could find in logs. Telling
jingle to update and accept the ip address showing does nothing of course,
it's already correct.

Yes, that is the unfortunate effect of an unmaintained plugin. Although it shows NONE, the entered address will still be used and you can ignore it.

It was then suggested the problem was attributable to the xmpp server name
versus host name in Openfire not matching.

Wherever that came from, to best of my knowledge, it is nonsense.

Admittedly after renaming the VM and matching up the host file before
installing Openfire to make sure the server and host name matched in
Openfire, jingle STILL refused to come online with the same indication. The
issue has several community queries with nobody as maintainer, so most
queries to the issue dead end.

What you mean as the "Server Name" in Openfire is actually the XMPP domain. Say you want your users to have john.wayne@example.org as their User ID, enter example.org as the Server Name. Or if you want to do regional names, e.g. john.wayne@europe.example.org, then set europe.example.org as the Server Name. The actual Openfire FQDN(s) can be e.g. xmpp-srv1.hq.us.example.net. They're completely unrelated.

There has to be more to it than Openfire matching server name as host name
or simply a matter of IP/port pairs. Actually it seems to me xmpp server
name and host name should NOT match if the Openfire server is to have
assignable independence from the domain / sub domain structure and end up
properly associated with a DNS structure.

While I don't use Jingle Nodes myself, a glance at the plugin's source code
doesn't indicate that it relies on a hostname anywhere. All you need to do
is to configure your public IP in the plugin's configuration. Given that
AFAIK the Jingle only uses ip/port pairs, this is no surprise.

Again, public facing ip of the vm is showing "correct", all ports are
unrestricted during testing, but the plugin complains with no further
indication.

I'm simply trying to increase potential traversal options using jingle, so I
apologize huge we're drifting off topic.

This certainly is not a jitsi issue to fight with and I truly appreciate
efforts offered here, not wanting to trash up the jitsi user-list. :frowning:

Mike

Ingo