Jitsi security


#1

Hello,

Concerning the recent discussions on security, I think, that the open
source nature of Jitsi, encryption and - above all - being outside the
mainstream, makes Jitsi very secure.

However I dream of a communicator having no central authority, no
central servers.

Any central point can easily be destroyed or coerced into giving up
data.

Distributed database technology is there - I2P (Java!), Bitcoin, old
good Cademlia, etc.

If Jitsi would be capable of that, it would make it really unique (and
very much wanted) in the world.

Maybe there should be a light version having just one or two good audio
and video codecs, supporting just one or two protocols and being able
to work without central servers.

Greetings,

Adrian.

···

Benito Mussolini

“Fascism should
rightly be called Corporatism, as it is the merger of corporate and
government power.”


#2

Hey Adrian,

Hello,

Concerning the recent discussions on security, I think, that the open
source nature of Jitsi, encryption and - above all - being outside the
mainstream, makes Jitsi very secure.

However I dream of a communicator having no central authority, no
central servers.

Well ... you can get that by running your own XMPP server. The XMPP
world is federated and there is no main XMPP server.

Any central point can easily be destroyed or coerced into giving up data.

This is true and this is why we support end-to-end encryption mechanisms
like ZRTP where compromising a central point does not affect your call
security. At least not without the user seeing it.

Distributed database technology is there - I2P (Java!), Bitcoin, old
good Cademlia, etc.

If Jitsi would be capable of that, it would make it really unique (and
very much wanted) in the world.

Maybe there should be a light version having just one or two good audio
and video codecs, supporting just one or two protocols and being able to
work without central servers.

I am not sure what would be the point of a version that has less
protocols and less codecs. It certainly wouldn't impact performance or
size in a significant way. Did you have something else in mind?

Cheers,
Emil

···

On 28.05.12 12:08, Adrian wrote:

Greetings,
Adrian.

/“Fascism should rightly be called Corporatism, as it is the merger of
corporate and government power.”

*Benito Mussolini*

/

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
http://jitsi.org FAX: +33.1.77.62.47.31


#3

However I dream of a communicator having no central authority, no
central servers.
Any central point can easily be destroyed or coerced into giving up data.

This is doable now, depending on your version of "server."

Distributed database technology is there - I2P (Java!), Bitcoin, old
good Cademlia, etc.

Bitcoin has lots of central servers... The Bitcoin exchanges, for example. You can do direct exchanges, but you will need some way to find each other and pass the message. Often this is e-mail, which also has a lot of central servers...

If Jitsi would be capable of that, it would make it really unique (and
very much wanted) in the world.

Not really. Most SIP and similar clients can do it. It is just a bit of trouble, so most users do not.

Maybe there should be a light version having just one or two good audio
and video codecs, supporting just one or two protocols and being able to
work without central servers.

OK... I think you misunderstand a bit. Limiting color choice will not make cars faster... They have nothing to do with each other. So lets back up, and look at it...

Right now a Jitsi client can connect to another Jitsi client and communicate. It can also connect to a compatible client over a compatible protocol, like Xlite over SIP. You just need the other IP address and full and transparent connectivity... So, on a local LAN, this works perfectly. In a large company, you can "chat" with a person in the office two floors up, and IT would never know. But if you want to chat with Dave in Chicago at another company you have a different problem; firewalls and NAT.

This is where the "servers" come in. They are boxes outside the NAT ghetto, with reall IP addresses. They map clients so you can actually pass traffic. This is jit.si, or skype, or google messanger, or you own Astreisk box, or a VPN endpoint with a dedicated IP, or whatever. Note that that last one is often used in the ultimate p2p protocal, bittorrent...

      Lee

···

On 05/28/2012 05:08 AM, Adrian wrote:


#4

Isn' t there a feature to dial another SIP phone by IP number? like
200*35*220*18

FC

···

On Mon, May 28, 2012 at 7:08 AM, Adrian <adrian.worutowicz@wanadoo.fr>wrote:

Maybe there should be a light version having just one or two good audio
and video codecs, supporting just one or two protocols and being able to
work without central servers.

Greetings,
Adrian.


#5

I would only consider doing that as a last resort, for instance if Asterisk was down.
Ever thought of dialing by ip with an IPv6 address ;-))))

Hw

···

From: Fernando Cassia [mailto:fcassia@gmail.com]
Sent: Wednesday, May 30, 2012 10:21 PM
To: users@jitsi.java.net
Subject: [jitsi-users] Re: Jitsi security

On Mon, May 28, 2012 at 7:08 AM, Adrian <adrian.worutowicz@wanadoo.fr<mailto:adrian.worutowicz@wanadoo.fr>> wrote:
Maybe there should be a light version having just one or two good audio and video codecs, supporting just one or two protocols and being able to work without central servers.

Greetings,
Adrian.

Isn' t there a feature to dial another SIP phone by IP number? like 200*35*220*18

FC

______________________________________________________________________
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.


#6

Hi Emil,

Less protocols and less codecs means less development/maintenance/documentation work.

It means much simpler system, easier understood by a common user.

If such a basic thing like port usage, causes confusion among active users, it is a bad sign.

I 've been playing with Jitsi for a few months and for me the only reliable Jitsi feature is chat (and only via jit.si).

Audio often does not work (“ICE failed”). Video almost never works.

For the record, I am an IT professional.

I believe, that the problem is my lack of knowledge. A simple setup procedure + clear system messages (eg. “Direct connection impossible. Open port X.”) would be the solution.

About the central points. Even if the communication is encrypted end-to-end, the central server knows when I am online and when I am not. It knows my contacts. That’s damn a lot!

Not every private individual is willing/capable to run his own XMPP server, 24/24, 7/7.

Therefore a distributed system would be safe, convenient and reliable.

Best regards, Adrian.

···

:slight_smile:


#7

<snip>

Right now a Jitsi client can connect to another Jitsi client and
communicate. It can also connect to a compatible client over a
compatible protocol, like Xlite over SIP. You just need the other
IP address and full and transparent connectivity... So, on a
local LAN, this works perfectly. In a large company, you can
"chat" with a person in the office two floors up, and IT would
never know. But if you want to chat with Dave in Chicago at
another company you have a different problem; firewalls and NAT.

I'm curious as to how a direct client connect would work. Which
protocol would one use to establish such a connection? Does the
protocol matter? How does one go about establishing such a connection
via the program?

Thanks!
Anthony

···

On 5/30/2012 1:48 PM, Lee Sharp wrote:


#8

Hey Adrian,

Hi Emil,

Less protocols and less codecs means less
development/maintenance/documentation work.

Well, no, it does not. It actually means more maintenance and work. If
we spin a light version of Jitsi with fewer protocols and codecs, as you
suggest, we would still be maintaining and developing stuff for the
non-removed protocols and codecs because they would still be supported
by the full version. On the other hand we would need to maintain a new
branch with its own builds, versioning and downloads.

It means much simpler system, easier understood by a common user.

The only simplification that would reach users is that in the "protocol"
combo box when creating a new account. This may indeed be an advantage
for some but it, in our opinion, it would not be worth the effort of
maintaining one extra version.

If such a basic thing like port usage, causes confusion among active
users, it is a bad sign.

I lost you here. First of all I don't see how "port usage" is a basic
thing to users. It is a concept that may even be confusing to some IT
professionals. Secondly I am not sure why users should be exposed to
that concept. Jitsi does not normally require users to configure
anything port related.

There are of course cases where this may be necessary. We are already
doing some things to circumvent such problems and we have others (such
as TCP support for Jingle Nodes) scheduled for the future. We'll get
them eventually.

I 've been playing with Jitsi for a few months and for me the only
reliable Jitsi feature is chat (and only via jit.si).

Audio often does not work ("ICE failed"). Video almost never works.
For the record, I am an IT professional.

Well ... we'd be happy to hear about your individual problems and see if
we can do anything to address them.

I believe, that the problem is my lack of knowledge. A simple setup
procedure + clear system messages (eg. "Direct connection impossible.
Open port X.") would be the solution.

It seems that you already have completed all the necessary steps. All
you need to do in Jitsi is create an account (e.g. on jit.si) and start
using it. I assure you that, as a user, we are not expecting you to do
anything else.

If things fail for you it is not because you did not configure Jitsi
properly. Problems are most often due to overly restrictive firewalls,
issues that we may have with specific hardware (such as webcams), and of
course, the occasional Jitsi bug.

About the central points. Even if the communication is encrypted
end-to-end, the central server knows when I am online and when I am not.
It knows my contacts. That's damn a lot!

Not every private individual is willing/capable to run his own XMPP
server, 24/24, 7/7.
Therefore a distributed system would be safe, convenient and reliable.

Well, personally I am not aware of a mature and stable technology that
allows you to do this in a reliable and way. There are many efforts out
there (SIP Witch, P2PSIP, etc.) that provide various degrees of
distribution (note that central points are still often necessary) but I
am afraid that neither of them is in a stage that would allow for a
straightforward integration in Jitsi. They would all require a
substantial R&D effort and we currently have other priorities.

Hope this answers your question,
Emil

···

On 28.05.12 13:50, Adrian wrote:

Best regards,:slight_smile:
Adrian.

On 28/05/12 12:43, Emil Ivov wrote:

Hey Adrian,

On 28.05.12 12:08, Adrian wrote:
  

Hello,

Concerning the recent discussions on security, I think, that the open
source nature of Jitsi, encryption and - above all - being outside the
mainstream, makes Jitsi very secure.

However I dream of a communicator having no central authority, no
central servers.
    

Well ... you can get that by running your own XMPP server. The XMPP
world is federated and there is no main XMPP server.

Any central point can easily be destroyed or coerced into giving up data.
    

This is true and this is why we support end-to-end encryption mechanisms
like ZRTP where compromising a central point does not affect your call
security. At least not without the user seeing it.

Distributed database technology is there - I2P (Java!), Bitcoin, old
good Cademlia, etc.

If Jitsi would be capable of that, it would make it really unique (and
very much wanted) in the world.

Maybe there should be a light version having just one or two good audio
and video codecs, supporting just one or two protocols and being able to
work without central servers.
    

I am not sure what would be the point of a version that has less
protocols and less codecs. It certainly wouldn't impact performance or
size in a significant way. Did you have something else in mind?

Cheers,
Emil
  

Greetings,
Adrian.

/“Fascism should rightly be called Corporatism, as it is the merger of
corporate and government power.”

*Benito Mussolini*

/

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
http://jitsi.org FAX: +33.1.77.62.47.31


#9

Are your questions about VoIP protocols in general or about Jitsi in
particular? I'll assume the latter since the answer is shorter ;).

Calls through XMPP allow you to use Jitsi's ICE implementation. With it
we try a bunch of techniques to reach the other party directly (e.g.
your host addresses, native IPv6, STUN, UPnP),
pseudo-directly-but-actually-indirectly (e.g. tunnelled IPv6, VPN, etc.)
and if none of those work(and only then) will we fall back to using
relays such as TURN or Jingle Nodes.

All of this happens under the hood so all you have to do is just start a
call with XMPP (e.g. on jit.si).

Cheers,
Emil

···

On 30.05.12 21:23, Anthony Papillion wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 5/30/2012 1:48 PM, Lee Sharp wrote:
<snip>

Right now a Jitsi client can connect to another Jitsi client and
communicate. It can also connect to a compatible client over a
compatible protocol, like Xlite over SIP. You just need the other
IP address and full and transparent connectivity... So, on a
local LAN, this works perfectly. In a large company, you can
"chat" with a person in the office two floors up, and IT would
never know. But if you want to chat with Dave in Chicago at
another company you have a different problem; firewalls and NAT.

I'm curious as to how a direct client connect would work. Which
protocol would one use to establish such a connection? Does the
protocol matter? How does one go about establishing such a connection
via the program?


#10

Anthony Papillion wrote:

<snip>

Right now a Jitsi client can connect to another Jitsi client and
communicate. It can also connect to a compatible client over a
compatible protocol, like Xlite over SIP. You just need the other
IP address and full and transparent connectivity... So, on a
local LAN, this works perfectly. In a large company, you can
"chat" with a person in the office two floors up, and IT would
never know. But if you want to chat with Dave in Chicago at
another company you have a different problem; firewalls and NAT.

I'm curious as to how a direct client connect would work. Which
protocol would one use to establish such a connection? Does the
protocol matter? How does one go about establishing such a connection
via the program?

Ideally use a VPN solution. Openvpn for example works perfectly well and
its really stable. The nice thing that vpns provide easy routing so you
will have no firewall/NAT issues. It is also very secure (it is widely
used in companies).
The downside is that it has to be configured and that needs a bit of
knowledge.

Another, less secure method is opening/forwarding a port (5060 UDP for
SIP for example) in one side's router/firewall and connect from the
other side to it. This is simpler, but provides no supplementary
transport layer security, you are stuck with whatever Jitsi can provide
(zrtp is quite nice though).

ANY method requires 1 fixed point that can be reached from the internet
- either fixed external IP address or some kind of dynamic name
resolution (such as dyndns).

···

On 5/30/2012 1:48 PM, Lee Sharp wrote:

Thanks!
Anthony

--
O zi buna,
Kertesz Laszlo


#11

Since specific was done, I will do general... When you initiate a connection, you get to speciffy almost everything. To start, you get to specific the protocol, like SIP:// or jabber, or whatever... Once you connect to the other party, either a server or a client properly set up to answer anonymous connections, you offer the codec in the top of your list. If the other side has it, you use it. If no, you go to the next codec and so on...

      Lee

···

On 05/30/2012 02:23 PM, Anthony Papillion wrote:

I'm curious as to how a direct client connect would work. Which
protocol would one use to establish such a connection? Does the
protocol matter? How does one go about establishing such a connection
via the program?


#12

Like so many others in our Internet broadcasting circles, I am trying to find an
alternative to Skype. So far, jitsi is one of the two closest candidates. Our
tests, though, have not established that jitsi is suitable as a replacement.
Maybe I don't understand enough about it.

How does jisti determine which audio codec is going to be used in a
conversation? I understand that both ends of the conversation have to have the
same codecs, but how do I tell jitsi to pick speex/32000, for example, as the
first codec? Does jitsi start at the top of the list of codecs and continue
until the first match? If I disable all other codecs, isn't there the
possibility that other calls that may not have audio? Is it possible to FORCE
jitsi to use the same codec as Skype, which I think is SILK/24000?

Video quality, even with resolution set to 1280 by 720, is not as good as Skype.
(Bandwidth is not an issue for either side of the test calls.) Is the Skype
video codec better than the one that jitsi uses? Are there bandwidth limitations
(the maximum allowed bandwidth on our test clients is set to 1Mb) within jitsi?
Does the choice of SIP provider determine that maximum bandwidth that a call can
have?

You guys have done a fabulous job with jitsi. You are very close to being a
Skype replacement. There IS demand for very high quality audio and video. (G.722
is not considered high quality in broadcast circles.) I hope that the
limitations I'm seeing are problems with my understanding of how jitsi works.
Thanks for all you do.

MCG


#13

Emil, thank you for your answers.

May I at least suggest some extra system messages in Jitsi?

In the beginning� I’ve set up an account on jabber.org.

The audio/video/etc. buttons were grayed out and inactive.

No presence indication either. And no warning/error message at all!

Afterward I read something about relaying… and switched over to jit.si.

A system message - even very technical - would prevent much of the frustration and loss of time.

Even non-technical people would easily search for it on the web and find a solution quickly.

Best regards,

Adrian.

···

On 28/05/12 14:16, Emil Ivov wrote:


Hey Adrian, On 28.05.12 13:50, Adrian wrote:

Hi Emil, Less protocols and less codecs means less development/maintenance/documentation work.
Well, no, it does not. It actually means more maintenance and work. If we spin a light version of Jitsi with fewer protocols and codecs, as you suggest, we would still be maintaining and developing stuff for the non-removed protocols and codecs because they would still be supported by the full version. On the other hand we would need to maintain a new branch with its own builds, versioning and downloads.
It means much simpler system, easier understood by a common user.
The only simplification that would reach users is that in the "protocol" combo box when creating a new account. This may indeed be an advantage for some but it, in our opinion, it would not be worth the effort of maintaining one extra version.
If such a basic thing like port usage, causes confusion among active users, it is a bad sign.

I lost you here. First of all I don't see how "port usage" is a basic thing to users. It is a concept that may even be confusing to some IT professionals. Secondly I am not sure why users should be exposed to that concept. Jitsi does not normally require users to configure anything port related. There are of course cases where this may be necessary. We are already doing some things to circumvent such problems and we have others (such as TCP support for Jingle Nodes) scheduled for the future. We'll get them eventually.

I 've been playing with Jitsi for a few months and for me the only reliable Jitsi feature is chat (and only via jit.si). Audio often does not work ("ICE failed"). Video almost never works. For the record, I am an IT professional.
Well ... we'd be happy to hear about your individual problems and see if we can do anything to address them.
I believe, that the problem is my lack of knowledge. A simple setup procedure + clear system messages (eg. "Direct connection impossible. Open port X.") would be the solution.

It seems that you already have completed all the necessary steps. All you need to do in Jitsi is create an account (e.g. on jit.si) and start using it. I assure you that, as a user, we are not expecting you to do anything else. If things fail for you it is not because you did not configure Jitsi properly. Problems are most often due to overly restrictive firewalls, issues that we may have with specific hardware (such as webcams), and of course, the occasional Jitsi bug.

About the central points. Even if the communication is encrypted end-to-end, the central server knows when I am online and when I am not. It knows my contacts. That's damn a lot! Not every private individual is willing/capable to run his own XMPP server, 24/24, 7/7. Therefore a distributed system would be safe, convenient and reliable.

Well, personally I am not aware of a mature and stable technology that allows you to do this in a reliable and way. There are many efforts out there (SIP Witch, P2PSIP, etc.) that provide various degrees of distribution (note that central points are still often necessary) but I am afraid that neither of them is in a stage that would allow for a straightforward integration in Jitsi. They would all require a substantial R&D effort and we currently have other priorities. Hope this answers your question, Emil



Best regards,:-) Adrian. On 28/05/12 12:43, Emil Ivov wrote:

Hey Adrian, On 28.05.12 12:08, Adrian wrote:

Hello, Concerning the recent discussions on security, I think, that the open source nature of Jitsi, encryption and - above all - being outside the mainstream, makes Jitsi very secure. However I dream of a communicator having no central authority, no central servers.
Well ... you can get that by running your own XMPP server. The XMPP world is federated and there is no main XMPP server.
Any central point can easily be destroyed or coerced into giving up data.
This is true and this is why we support end-to-end encryption mechanisms like ZRTP where compromising a central point does not affect your call security. At least not without the user seeing it.

Distributed database technology is there - I2P (Java!), Bitcoin, old good Cademlia, etc. If Jitsi would be capable of that, it would make it really unique (and very much wanted) in the world. Maybe there should be a light version having just one or two good audio and video codecs, supporting just one or two protocols and being able to work without central servers.

I am not sure what would be the point of a version that has less protocols and less codecs. It certainly wouldn't impact performance or size in a significant way. Did you have something else in mind? Cheers, Emil

Greetings, Adrian. /�Fascism should rightly be called Corporatism, as it is the merger of corporate and government power.� *Benito Mussolini* /




#14

Does jitsi start at
the top of the list of codecs and continue until the first match?

Yep.

If I disable all other codecs, isn't there the possibility that
other calls that may not have audio?

Yep2.

Is it possible to FORCE jitsi
to use the same codec as Skype, which I think is SILK/24000?

Dono.

Video quality, even with resolution set to 1280 by 720, is not as
good as Skype. (Bandwidth is not an issue for either side of the
test calls.) Is the Skype video codec better than the one that
jitsi uses? Are there bandwidth limitations (the maximum allowed
bandwidth on our test clients is set to 1Mb) within jitsi? Does
the choice of SIP provider determine that maximum bandwidth that a
call can have?

You can't compare skype & jitsi, one is a big corpo that can pay
dozens of people to enhance the software, when jitsi have a small
team (but, hey, look at what they are capable of!)
Time will surely improve the video quality:)

JY

···

On Mon, 28 May 2012 09:09:13 -0400 Mediacast Guy <mediacastguy@gmail.com> wrote:
--
The only one of your children who does not grow up and move away
is your husband.


#15

Hey there,

Does jitsi start at
the top of the list of codecs and continue until the first match?

Yep.

Confirmed.

If I disable all other codecs, isn't there the possibility that
other calls that may not have audio?

Yep2.

To be precise, if both sides do not have compatible codecs, there would
be no call at all. That is, users will see an error message (i.e. rather
than have a call with no audio).

That's probably what you meant but I thought I'd clarify.

Is it possible to FORCE jitsi
to use the same codec as Skype, which I think is SILK/24000?

Dono.

Putting Silk/24000 at the top of the list would ensure that Jitsi would
pick it up any time you call someone who also supports it.

If other people call you, Jitsi would pick up the first codec in their
list that we support (which may be different).

The closest we have to forcing is un-checking all other codecs which, as
mentioned above, would increase the risk of call failure when you call
other clients which do not have Silk.

Video quality, even with resolution set to 1280 by 720, is not as
good as Skype. (Bandwidth is not an issue for either side of the
test calls.) Is the Skype video codec better than the one that
jitsi uses? Are there bandwidth limitations (the maximum allowed
bandwidth on our test clients is set to 1Mb) within jitsi? Does
the choice of SIP provider determine that maximum bandwidth that a
call can have?

You can't compare skype & jitsi, one is a big corpo that can pay
dozens of people to enhance the software, when jitsi have a small
team (but, hey, look at what they are capable of!)

Thank you for your kind words! Rally appreciate it! :slight_smile:

Emil

···

On 28.05.12 15:19, Bzzz wrote:

On Mon, 28 May 2012 09:09:13 -0400 > Mediacast Guy <mediacastguy@gmail.com> wrote:

Time will surely improve the video quality:)

JY


#16

Emil, thanks for your responses. For clarification, does the choice of SIP
providers (like sip2sip.info) determine or have any effect on the maximum
available bandwidth for a call?

Regarding comparing jitsi to Skype, I believe the jitsi team is a LOT more
concerned about its user than Skype will ever be. Skype started small and grew
to enormous. The sky is the limit for jitsi, too.

MCG

···

On 5/28/2012 9:32 AM, Emil Ivov wrote:

Video quality, even with resolution set to 1280 by 720, is not as
good as Skype. (Bandwidth is not an issue for either side of the
test calls.) Is the Skype video codec better than the one that
jitsi uses? Are there bandwidth limitations (the maximum allowed
bandwidth on our test clients is set to 1Mb) within jitsi? Does
the choice of SIP provider determine that maximum bandwidth that a
call can have?

You can't compare skype & jitsi, one is a big corpo that can pay
dozens of people to enhance the software, when jitsi have a small
team (but, hey, look at what they are capable of!)

Thank you for your kind words! Rally appreciate it! :slight_smile:


#17

Hey there,

Video quality, even with resolution set to 1280 by 720, is not as
good as Skype. (Bandwidth is not an issue for either side of the
test calls.) Is the Skype video codec better than the one that
jitsi uses? Are there bandwidth limitations (the maximum allowed
bandwidth on our test clients is set to 1Mb) within jitsi? Does
the choice of SIP provider determine that maximum bandwidth that a
call can have?

You can't compare skype & jitsi, one is a big corpo that can pay
dozens of people to enhance the software, when jitsi have a small
team (but, hey, look at what they are capable of!)

Thank you for your kind words! Rally appreciate it! :slight_smile:

Emil, thanks for your responses. For clarification, does the choice of SIP
providers (like sip2sip.info) determine or have any effect on the maximum
available bandwidth for a call?

In theory, it could be. It would relay all Jitsi SIP calls (which is a
good think since we only have ICE for XMPP) and its available
bandwidth would hence be important. In practice however it is not
necessarily the most likely culprit for possible problems. If you'd
like to rule it out, try having an XMPP call using jit.si.

Hope this helps,
Emil

···

On Mon, May 28, 2012 at 3:39 PM, Mediacast Guy <mediacastguy@gmail.com> wrote:

On 5/28/2012 9:32 AM, Emil Ivov wrote:

Regarding comparing jitsi to Skype, I believe the jitsi team is a LOT more
concerned about its user than Skype will ever be. Skype started small and grew
to enormous. The sky is the limit for jitsi, too.

MCG


#18

Providers have nothing to do w/ B.W., it is the CODECs they accept
or not that determine it.

JY

···

On Mon, 28 May 2012 09:39:58 -0400 Mediacast Guy <mediacastguy@gmail.com> wrote:

Emil, thanks for your responses. For clarification, does the
choice of SIP providers (like sip2sip.info) determine or have any
effect on the maximum available bandwidth for a call?

--
'Course, that doesn't work when 'a' contains parentheses.
    -- Larry Wall in <199710211647.JAA17957@wall.org>


#19

We just completed some test calls. It was great to be able set the codec to be
used and to confirm that it was actually being used. The first codec was
speex/32000. The wideband audio quality (compared with Skype) was not nearly as
good. It has some scratchiness to it. The next codec was the SILK/24000. It was
pretty good, but there were discontinuities in the audio. The quality was pretty
good, but still not a Skype replacement.

I'm pretty sure you don't write these codecs, so I don't think the problem is
jitsi. My guess (and it is a guess) is that we have to wait for codec
improvements. Maybe SILK Version 3 would perform better.

By the way, when we both selected DVI4/16000, the call would not connect. When
we went back to speex, all was well.

Again, thanks for your hard work and support. You're getting really close to
being a replacement for Skype. I realize that most people don't need or even
understand true wideband audio, but it is encouraging to see development
trending in that direction.

(If you want to see true wideband audio, take a look at the specs on
http://audiocompass.com. 44KHz 16-bit stereo with no compression.)

···

On 5/28/2012 9:44 AM, Emil Ivov wrote:

In theory, it could be. It would relay all Jitsi SIP calls (which is a
good think since we only have ICE for XMPP) and its available
bandwidth would hence be important. In practice however it is not
necessarily the most likely culprit for possible problems. If you'd
like to rule it out, try having an XMPP call using jit.si.