[jitsi-users] again: Unable to launch jitsi in JRE 7


#1

Hi all,
         I am unable to launch Jitsi rev 3562 in Archlinux x86_64
using Oracle's x86_64 bibary of Java RE 7 build 147 (
http://mailman.archlinux.org/pipermail/arch-general/2011-June/020654.html
) (Package at https://aur.archlinux.org/packages.php?ID=48928 ). I get
these errors http://pastebin.com/PJf48570 . What do they mean and how
do i correct there errors. Also it was mentioned by some users that
jitsi has a hard-coded dependency on OpenJDK 6 and does not work well
with Binary Sun/Oracle JRE versions. Is this true? Is that causing the
errors I see now. Other java apps in my system are working properly
with Java RE 7. Thanks in advance.

Regards.

Keshav

···

-----Original Message-----
From: KESHAV P.R. [mailto:skodabenz@gmail.com]
Sent: Friday, July 01, 2011 10:26 PM
To: users@jitsi.java.net
Subject: [jitsi-users] Unable to launch jitsi in JRE 7

-----Original Message-----

Hi,

Re-issuing this...
a) couple of weeks ago the fellows from Oracle stated that people should move over. Help with the transition towards java-7 was free-for-the-time-being as in: 2013Q1. Neither support nor the possibility to download java-6 (free) later on.
b) some distro's are only shipping openjdk7, no openjdk6 anymore.

So what are the rough plans for leaping towards openjdk7 ?

Hans

______________________________________________________________________
Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten.

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.


#2

Hey

I am unable to launch Jitsi rev 3562 in Archlinux x86_64
using Oracle's x86_64 bibary of Java RE 7 build 147 (
http://mailman.archlinux.org/pipermail/arch-general/2011-June/020654.html
) (Package at https://aur.archlinux.org/packages.php?ID=48928 ). I get
these errors http://pastebin.com/PJf48570 . What do they mean and how do

The paste ID doesn't exist any longer.

i correct there errors. Also it was mentioned by some users that jitsi
has a hard-coded dependency on OpenJDK 6 and does not work well with
Binary Sun/Oracle JRE versions. Is this true? Is that causing the errors
I see now. Other java apps in my system are working properly with Java
RE 7. Thanks in advance.

Regards.

Keshav

Hi,

Re-issuing this...
a) couple of weeks ago the fellows from Oracle stated that people should move
over. Help with the transition towards java-7 was free-for-the-time-being as
in: 2013Q1. Neither support nor the possibility to download java-6 (free)
later on.
b) some distro's are only shipping openjdk7, no openjdk6 anymore.

So what are the rough plans for leaping towards openjdk7 ?

Hans

Jitsi already ships with JRE7 on Windows, so the Java version alone shouldn't be the issue. Could you provide your logs [1] and any console output you see before someone needs to setup ArchLinux?

Regards,
Ingo

[1] https://jitsi.org/index.php/Documentation/FAQ#logs

···

-----Original Message-----


#3

Hi Ingo,

···

-----Original Message-----

Hi,

Re-issuing this...
a) couple of weeks ago the fellows from Oracle stated that people should move
over. Help with the transition towards java-7 was free-for-the-time-being as
in: 2013Q1. Neither support nor the possibility to download java-6 (free)
later on.
b) some distro's are only shipping openjdk7, no openjdk6 anymore.

So what are the rough plans for leaping towards openjdk7 ?

Hans

Jitsi already ships with JRE7 on Windows, so the Java version alone shouldn't be the issue

-----Original Message-----
Excuse me,
Perhaps joining in on the old message was a bit confusing, although the question is 100% identical.

I do refer to:
https://jitsi.org/index.php/Documentation/RetrievingAndBuildingTheSources
Where it says (snipped):
"In order to build and run the SIP Communicator, all you need is a recent JDK and ANT.
JDK: Download the latest version on java.sun.com website"

1) It is wonderful to notice that the jitsi-bin for windows includes a proper working java environment.

2) If (!!) this is sun/oracle-JAVA, will jitsi not get into problems? As it is not allowed anymore to ship sun/oracle-java along with any product (this is why distro's stopped doing it)

3) It might be helpful to do the same for other platforms, as end-users will not be able to get it themselves.
Whatever JRE jitsi needs (no matter how old or strange sub-branch it might be), ship it along, or present that particular version...

Latest distro version of both Fedora and OpenSUSE, and also the upcoming OpenSUSE_12.3 contain _only_ openJDK-7.
Yes I know about the confusing numbering plan:
https://blogs.oracle.com/darcy/entry/openjdk_6_genealogy
I know, this generates all sorts of problems for any products that rely strictly on openjdk6 or SUN's-JRE.

Hence my question regarding openjdk-7....

Kind regards, Hans

______________________________________________________________________
Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten.

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.


#4

Hey

Re-issuing this... a) couple of weeks ago the fellows from Oracle
stated that people should move over. Help with the transition towards
java-7 was free-for-the-time-being as in: 2013Q1. Neither support nor
the possibility to download java-6 (free) later on. b) some distro's
are only shipping openjdk7, no openjdk6 anymore.

So what are the rough plans for leaping towards openjdk7 ?

Hans

Jitsi already ships with JRE7 on Windows, so the Java version alone shouldn't
be the issue

Excuse me,
Perhaps joining in on the old message was a bit confusing, although the
question is 100% identical.

I do refer to:
https://jitsi.org/index.php/Documentation/RetrievingAndBuildingTheSources
Where it says (snipped): "In order to build and run the SIP
Communicator, all you need is a recent JDK and ANT. JDK: Download the
latest version on java.sun.com website"

This page is aimed at developers. Users wanting to build from source can so as well, but then it's up to them what JDK they use.

1) It is wonderful to notice that the jitsi-bin for windows includes a proper
working java environment.

2) If (!!) this is sun/oracle-JAVA, will jitsi not get into problems? As it
is not allowed anymore to ship sun/oracle-java along with any product (this
is why distro's stopped doing it)

No. See this excerpt from Oracle's JRE7 Readme [1]:

"To run your application, a user needs the Java SE Runtime Environment,
which is freely available from Oracle. Or, you can redistribute the
Java SE Runtime Environment for free with your application, according
to the terms of the Oracle Binary Code License Agreement for the Java
SE Platform Products."

3) It might be helpful to do the same for other platforms, as end-users will
not be able to get it themselves.
Whatever JRE jitsi needs (no matter how old or strange sub-branch it might
be), ship it along, or present that particular version...

On Linux, this is the job of the package-manager, and on Mac the installer checks for Java, installs it through the system-wide installer and later lets it up to the OS to keep it up to date. (I don’t use a Mac so other devs might correct me on this one).

Latest distro version of both Fedora and OpenSUSE, and also the upcoming
OpenSUSE_12.3 contain _only_ openJDK-7. Yes I know about the confusing
numbering plan: https://blogs.oracle.com/darcy/entry/openjdk_6_genealogy
I know, this generates all sorts of problems for any products that rely
strictly on openjdk6 or SUN's-JRE.

Hence my question regarding openjdk-7....

Are you actually having an issue? If so, we'd really need so see your logs. If not, then I don't see anything what we should do right now?

Kind regards, Hans

Regards,
Ingo

[1] http://www.oracle.com/technetwork/java/javase/jre-7-readme-430162.html


#5

Hello.

I have installed jitsi on two machines - a win 7 and a kubuntu. Registered both with gtalk and voip.ms (no balance).

It seemed logical to then test having the softphones call each other.

Eventually I figured to add an account with no '@' in the name, using hostnames, and try calling <sip id>@<internal ip address>, where, in my case, sip id = hostname. (Registrarless SIP.]

However, when I do so the call is attempted, and upon answering, I get windows saying 'call failed' on both ends. The initiator gets 'Not Acceptable Here', and the receiver gets 'permillis'.

What steps do I need to do to make a jitsi to jitsi call? [i.e. First thing I need to know is what to do and what to expect.]

Could this be added to the web site's FAQ?
(Seems a logical step to test one's client software before adding complexity, such as with a registrar. Perhaps installation should default with such an account using <hostname>?)

If this is already explained on the site, a link would be gratefully appreciated.

TIA.


#6

I believe making calls like this has been disabled due to security concerns.

···

--
Sent from my mobile device

On Jan 10, 2013, at 7:25 AM, "B. S." <bs27975@gmail.com> wrote:

Hello.

I have installed jitsi on two machines - a win 7 and a kubuntu. Registered both with gtalk and voip.ms (no balance).

It seemed logical to then test having the softphones call each other.

Eventually I figured to add an account with no '@' in the name, using hostnames, and try calling <sip id>@<internal ip address>, where, in my case, sip id = hostname. (Registrarless SIP.]

However, when I do so the call is attempted, and upon answering, I get windows saying 'call failed' on both ends. The initiator gets 'Not Acceptable Here', and the receiver gets 'permillis'.

What steps do I need to do to make a jitsi to jitsi call? [i.e. First thing I need to know is what to do and what to expect.]

Could this be added to the web site's FAQ?
(Seems a logical step to test one's client software before adding complexity, such as with a registrar. Perhaps installation should default with such an account using <hostname>?)

If this is already explained on the site, a link would be gratefully appreciated.

TIA.


#7

Hey B. S.,

Hello.

I have installed jitsi on two machines - a win 7 and a kubuntu.
Registered both with gtalk and voip.ms (no balance).

It seemed logical to then test having the softphones call each other.

Eventually I figured to add an account with no '@' in the name, using
hostnames, and try calling <sip id>@<internal ip address>, where, in my
case, sip id = hostname. (Registrarless SIP.]

RegistrarLess accounts are only meant for testing purposes and we
generally try to discourage users from creating them.

Can you try making your calls through a SIP service?

Emil

···

On 10.01.13, 14:24, B. S. wrote:

However, when I do so the call is attempted, and upon answering, I get
windows saying 'call failed' on both ends. The initiator gets 'Not
Acceptable Here', and the receiver gets 'permillis'.

What steps do I need to do to make a jitsi to jitsi call? [i.e. First
thing I need to know is what to do and what to expect.]

Could this be added to the web site's FAQ?
(Seems a logical step to test one's client software before adding
complexity, such as with a registrar. Perhaps installation should
default with such an account using <hostname>?)

If this is already explained on the site, a link would be gratefully
appreciated.

TIA.

--
https://jitsi.org


#8

Hey B. S.,

Hello.

I have installed jitsi on two machines - a win 7 and a kubuntu.
Registered both with gtalk and voip.ms (no balance).

It seemed logical to then test having the softphones call each other.

Eventually I figured to add an account with no '@' in the name, using
hostnames, and try calling <sip id>@<internal ip address>, where, in my
case, sip id = hostname. (Registrarless SIP.]

RegistrarLess accounts are only meant for testing purposes and we
generally try to discourage users from creating them.

How, then, do I accept direct calls? From, for example, another voip client, such as jitsi, within the house? [Let's me test hardware, audio, speakers, microphone, etc., first - before I start blaming the provider. (-: ]

The answer to "How, then, do I accept direct calls?" or a similar test regimen, would also be worthy of a web page FAQ entry.

Can you try making your calls through a SIP service?

Not at the moment. Seems not worth the effort, yet. i.e. I'm in the process of setting up for voip.ms - installing jitsi was the first part of that process. Once I complete that stuff (including an ata), and put money into the account, I'll be able to try that, then. (So, seems pointless to fire up a free service if I'm going to get to a non-free service eventually, anyways - I'll run those tests, then. Let alone additional complexity, at this point, of a second service.) Echo test to voip.ms certainly works, if that's a useful bit of info.

···

On 13-01-11 07:33 AM, Emil Ivov wrote:

On 10.01.13, 14:24, B. S. wrote:

However, when I do so the call is attempted, and upon answering, I get
windows saying 'call failed' on both ends. The initiator gets 'Not
Acceptable Here', and the receiver gets 'permillis'.

What steps do I need to do to make a jitsi to jitsi call? [i.e. First
thing I need to know is what to do and what to expect.]

Could this be added to the web site's FAQ?
(Seems a logical step to test one's client software before adding
complexity, such as with a registrar. Perhaps installation should
default with such an account using <hostname>?)

If this is already explained on the site, a link would be gratefully
appreciated.

TIA.


#9

That's my call to make, not the software's. (Not to say appropriate warnings aren't prudent, nor that it default to such, but it should be able to be turned off.)

It seems an obvious first testing step, it doesn't make sense to disable it.

To the developers: One vote for re-enabling it, please.

I tried disabling encryption on both sides, unsuccessfully, if that has a bearing.

In the mean time ... is this a configuration change I can dig down and modify?

TIA

···

On 13-01-11 11:41 AM, Anthony Papillion wrote:

I believe making calls like this has been disabled due to security
concerns.

On Jan 10, 2013, at 7:25 AM, "B. S." <bs27975@gmail.com> wrote:

Hello.

I have installed jitsi on two machines - a win 7 and a kubuntu.
Registered both with gtalk and voip.ms (no balance).

It seemed logical to then test having the softphones call each other.

Eventually I figured to add an account with no '@' in the name, using
hostnames, and try calling <sip id>@<internal ip address>, where, in
my case, sip id = hostname. (Registrarless SIP.]

However, when I do so the call is attempted, and upon answering, I get
windows saying 'call failed' on both ends. The initiator gets 'Not
Acceptable Here', and the receiver gets 'permillis'.

What steps do I need to do to make a jitsi to jitsi call? [i.e. First
thing I need to know is what to do and what to expect.]

Could this be added to the web site's FAQ?
(Seems a logical step to test one's client software before adding
complexity, such as with a registrar. Perhaps installation should
default with such an account using <hostname>?)

If this is already explained on the site, a link would be gratefully
appreciated.

TIA.


#10

That's my call to make, not the software's. (Not to say appropriate
warnings aren't prudent, nor that it default to such, but it should be
able to be turned off.)

It seems an obvious first testing step, it doesn't make sense to disable

it.

It not at all obvious. Registrarless-accounts requires your local firewall
to be configured in a way a server-based account doesn't need.

To the developers: One vote for re-enabling it, please.

There's nothing to re-enable as we didn't disable anything with regard to
registrarless-accounts.

I tried disabling encryption on both sides, unsuccessfully, if that has
a bearing.

It shouldn't be necessary to touch the encryption settings at all.

In the mean time ... is this a configuration change I can dig down and
modify?

No, because of above.

If the echo-test of your provider works then everything should be fine.

Regards,
Ingo


#11

That's my call to make, not the software's. (Not to say appropriate
warnings aren't prudent, nor that it default to such, but it should be
able to be turned off.)

It seems an obvious first testing step, it doesn't make sense to disable

it.

It not at all obvious. Registrarless-accounts requires your local firewall
to be configured in a way a server-based account doesn't need.

Um, entirely obvious. No firewall involved. Well, ok, win firewall for those clients, but it comes up asking to open the hole.

To the developers: One vote for re-enabling it, please.

There's nothing to re-enable as we didn't disable anything with regard to
registrarless-accounts.

Sorry, I must misunderstand something. An earlier message said the ability to make jitsi to jitsi calls had been disabled.

I tried disabling encryption on both sides, unsuccessfully, if that has
a bearing.

It shouldn't be necessary to touch the encryption settings at all.

Thanks. Good to know. That why I asked for the steps involved in making such a call. i.e. Self-detection of stupid mistakes.

In the mean time ... is this a configuration change I can dig down and
modify?

No, because of above.

If the echo-test of your provider works then everything should be fine.

Which is entirely beside the point. e.g. any and all sip to sip calls. Say, direct between family members without involving a registrar, or any other such pair of people.

Thought of this later ... given the statement it was disabled ... even re-disabling it at program start would be acceptable.

···

On 13-01-11 03:45 PM, Ingo Bauersachs wrote:


#12

If the echo-test of your provider works then everything should be fine.

Which is entirely beside the point. e.g. any and all sip to sip calls.
Say, direct between family members without involving a registrar, or any
other such pair of people.

If you want to call other people without a registrar outside of your local
network, you'd need to know their IP address. If NAT is involved on either
side, you'd need to know the public IP address of the router, the signaling
ports need to be forwarded from the router to the client PC and more or less
all UDP ports need to be forwarded (as they are random for the audio/video
data).

Registrarless accounts are just useless outside the local network. Inside,
you can just setup SIP accounts on two computers:
PC 1 (192.168.0.1): File->Add account: Network=SIP, ID=local (don't enter an
@ sign!), click Add
PC 2 (192.168.0.2): File->Add account: Network=SIP, ID=remote (don't enter
an @ sign!), click Add
To call from PC 1 to PC 2 enter remote@192.168.0.2 into the dial field.

Ingo


#13

If the echo-test of your provider works then everything should be fine.

Which is entirely beside the point. e.g. any and all sip to sip calls.
Say, direct between family members without involving a registrar, or any
other such pair of people.

If you want to call other people without a registrar outside of your local
network,

Per the given test use scenario, they are on the local network.

you'd need to know their IP address.

Or you've set up your router with dyndns or equivalent.

If NAT is involved on either
side, you'd need to know the public IP address of the router, the signaling
ports need to be forwarded from the router to the client PC and more or less
all UDP ports need to be forwarded (as they are random for the audio/video
data).

All well and good - so, for those who can do so, let them.

(And, as I now see below, you do. Thanks for that.)

Registrarless accounts are just useless outside the local network. Inside,
you can just setup SIP accounts on two computers:
PC 1 (192.168.0.1): File->Add account: Network=SIP, ID=local (don't enter an
@ sign!), click Add
PC 2 (192.168.0.2): File->Add account: Network=SIP, ID=remote (don't enter
an @ sign!), click Add
To call from PC 1 to PC 2 enter remote@192.168.0.2 into the dial field.

Perfect. Thank you very much.

Per my original message, that's what I did, and got the problems as initially reported. In my case I used my statically assigned DHCP numbers for the ip address name (i.e. ping by name works) and the hostname of each computer. The call is attempted, but clicking answer returns as in the OP.

>> However, when I do so the call is attempted, and upon answering, I
>> get windows saying 'call failed' on both ends. The initiator gets
>> 'Not Acceptable Here', and the receiver gets 'permillis'.

Thoughts?

And, thanks again.

···

On 13-01-11 05:58 PM, Ingo Bauersachs wrote:


#14

Registrarless accounts are just useless outside the local network.
Inside, you can just setup SIP accounts on two computers: PC 1
(192.168.0.1): File->Add account: Network=SIP, ID=local (don't enter an
@ sign!), click Add PC 2 (192.168.0.2): File->Add account: Network=SIP,
ID=remote (don't enter an @ sign!), click Add To call from PC 1 to PC 2
enter remote@192.168.0.2 into the dial field.

Perfect. Thank you very much.

Per my original message, that's what I did, and got the problems as
initially reported. In my case I used my statically assigned DHCP
numbers for the ip address name (i.e. ping by name works) and the
hostname of each computer. The call is attempted, but clicking answer
returns as in the OP.

However, when I do so the call is attempted, and upon answering, I
get windows saying 'call failed' on both ends. The initiator gets
'Not Acceptable Here', and the receiver gets 'permillis'.

Thoughts?

Sounds like the two cannot agree on a common codec. However that would be
strange if you didn't change anything there. Please send us your complete
logs [1] (with the .pcap) after a fresh start and an attempted call.

And, thanks again.

You're welcome.

Ingo

[1] https://jitsi.org/index.php/Documentation/FAQ#logs


#15

[...]

If you want to call other people without a registrar outside of your local
network, you'd need to know their IP address. If NAT is involved on either
side, you'd need to know the public IP address of the router, the signaling
ports need to be forwarded from the router to the client PC and more or less
all UDP ports need to be forwarded (as they are random for the audio/video
data).

About this topic, once upon a time, Skype stated
that the communication connection was always p2p,
the server was only used to bring the partners
together. I understand this with NAT too.

Is this possible? With NAT? How?

BTW, this was also sold as "security feature",
since in this way there was no possibility, it
was claimed, of eavsdropping at server side.

Thanks,

bye,

···

On Fri, Jan 11, 2013 at 11:58:22PM +0100, Ingo Bauersachs wrote:

--

piergiorgio


#16

Thank you for the instructions. I added an explanation and more details on the website. Please review:
https://jitsi.org/Documentation/RegistrarlessSIPAccount

Also could someone with the necessary permission levels delete the following page for me:
https://jitsi.org/Documentation/RegistrarlessSIPAccounts

Thanks,

David

···

On 1/11/2013 4:58 PM, Ingo Bauersachs wrote:

Registrarless accounts are just useless outside the local network. Inside, you can just setup SIP accounts on two computers: PC 1 (192.168.0.1): File->Add account: Network=SIP, ID=local (don't enter an @ sign!), click Add PC 2 (192.168.0.2): File->Add account: Network=SIP, ID=remote (don't enter an @ sign!), click Add To call from PC 1 to PC 2 enter remote@192.168.0.2 into the dial field. Ingo


#17

[...]

If you want to call other people without a registrar outside of your local
network, you'd need to know their IP address. If NAT is involved on either
side, you'd need to know the public IP address of the router, the signaling
ports need to be forwarded from the router to the client PC and more or less
all UDP ports need to be forwarded (as they are random for the audio/video
data).

About this topic, once upon a time, Skype stated
that the communication connection was always p2p,
the server was only used to bring the partners
together. I understand this with NAT too.

Is this possible? With NAT? How?

No, it's not possible if both endpoints are behind (different) symmetric NATs. I thought Skype used "super nodes" as relays when needed. (Google it :wink:

BTW, this was also sold as "security feature",
since in this way there was no possibility, it
was claimed, of eavsdropping at server side.

It was news to me. I would thought it was the end-to-end encryption which would be sold as a security feature. Of course nowadays you can't know for sure if a call is lawfully intercepted or not.

/Mikael

···

On 01/12/2013 03:04 PM, Piergiorgio Sartor wrote:

On Fri, Jan 11, 2013 at 11:58:22PM +0100, Ingo Bauersachs wrote:

Thanks,

bye,


#18

Registrarless accounts are just useless outside the local network.
Inside, you can just setup SIP accounts on two computers: PC 1
(192.168.0.1): File->Add account: Network=SIP, ID=local (don't enter
an @ sign!), click Add PC 2 (192.168.0.2): File->Add account:
Network=SIP, ID=remote (don't enter an @ sign!), click Add To call
from PC 1 to PC 2 enter remote@192.168.0.2 into the dial field. Ingo

Thank you for the instructions. I added an explanation and more details
on the website. Please review:
https://jitsi.org/Documentation/RegistrarlessSIPAccount

Thanks a lot David, your effort is much appreciated!

The instructions are correct. Maybe it would be worthwhile to mention that
the local firewall needs to be open for this to work (UDP 5060 (for SIP
signaling) and above (for media)).

Also could someone with the necessary permission levels delete the
following page for me:
https://jitsi.org/Documentation/RegistrarlessSIPAccounts

Done, but I think you have that permission as well. It's just a bit an
awkward way to do so:
http://www.pmwiki.org/wiki/PmWiki/DeletingPages

Thanks,
David

Regards,
Ingo

···

On 1/11/2013 4:58 PM, Ingo Bauersachs wrote:


#19

Hello, will it work from outside lan if ports are correctly opened, and if i use remote@<remote ip with correct port forwarded> ?

-----Message d'origine-----

···

From: Ingo Bauersachs

Sent: Tuesday, January 22, 2013 9:35 AM
To: users@jitsi.java.net
Subject: [jitsi-users] Re: How to make a jitsi to jitsi call?

On 1/11/2013 4:58 PM, Ingo Bauersachs wrote:

Registrarless accounts are just useless outside the local network.
Inside, you can just setup SIP accounts on two computers: PC 1
(192.168.0.1): File->Add account: Network=SIP, ID=local (don't enter
an @ sign!), click Add PC 2 (192.168.0.2): File->Add account:
Network=SIP, ID=remote (don't enter an @ sign!), click Add To call
from PC 1 to PC 2 enter remote@192.168.0.2 into the dial field. Ingo

Thank you for the instructions. I added an explanation and more details
on the website. Please review:
https://jitsi.org/Documentation/RegistrarlessSIPAccount

Thanks a lot David, your effort is much appreciated!

The instructions are correct. Maybe it would be worthwhile to mention that
the local firewall needs to be open for this to work (UDP 5060 (for SIP
signaling) and above (for media)).

Also could someone with the necessary permission levels delete the
following page for me:
https://jitsi.org/Documentation/RegistrarlessSIPAccounts

Done, but I think you have that permission as well. It's just a bit an
awkward way to do so:
http://www.pmwiki.org/wiki/PmWiki/DeletingPages

Thanks,
David

Regards,
Ingo


#20

Knowing little about firewalls and ports, I did my best to add a "Troubleshooting" section to the bottom of the page explaining these details.

David

···

On 1/22/2013 2:35 AM, Ingo Bauersachs wrote:

  Please review:
https://jitsi.org/Documentation/RegistrarlessSIPAccount

The instructions are correct. Maybe it would be worthwhile to mention that
the local firewall needs to be open for this to work (UDP 5060 (for SIP
signaling) and above (for media)).