[jitsi-users] making zrtp work


#1

I read the ZRTP FAQ at http://www.jitsi.org/index.php/Documentation/ZrtpFAQ#faqWhere
but it doesn't actually clarify much about using Jitsi.

There is a "where to find it" question, but does that mean that ZRTP won't work
at all out of the box? If there is an additional download, where does it have
to be put in the Jitsi install?

In Preferences, there are "Standard" and "Mandatory" buttons and "SAS Signature Processing"
checkbox and "SAS Types". What am I supposed to do with those?

How do you ensure that only zrtp protected calls are made?

Does it all work along with audio conferencing?

-mda


#2

FBI is not going to record your call:)

Envoyé de mon iPhone

···

Le 19 juil. 2011 à 08:56, "Mark D. Anderson" <mda@discerning.com> a écrit :

I read the ZRTP FAQ at http://www.jitsi.org/index.php/Documentation/ZrtpFAQ#faqWhere
but it doesn't actually clarify much about using Jitsi.

There is a "where to find it" question, but does that mean that ZRTP won't work
at all out of the box? If there is an additional download, where does it have
to be put in the Jitsi install?

In Preferences, there are "Standard" and "Mandatory" buttons and "SAS Signature Processing"
checkbox and "SAS Types". What am I supposed to do with those?

How do you ensure that only zrtp protected calls are made?

Does it all work along with audio conferencing?

-mda


#3

Hello,

Zrtp isnt always enabled by default. I found that i have to manually tick everything except "trusted mitm" under Options -> security -> call (all tabs and all options under it).
Make sure both ends have them enabled.

By default every option was off and i couldnt establish a zrtp call (i couldnt establish a call at all because one side had the zrtp options on and the other didnt).

I posted about this a while ago, but the devs said that by default zrtp should work. It didnt for me on 2 installs.
So maybe the defaults are wrong.

···

On Tue, 19 Jul 2011 10:56:03 +0300, Mark D. Anderson <mda@discerning.com> wrote:

I read the ZRTP FAQ at http://www.jitsi.org/index.php/Documentation/ZrtpFAQ#faqWhere
but it doesn't actually clarify much about using Jitsi.

There is a "where to find it" question, but does that mean that ZRTP won't work
at all out of the box? If there is an additional download, where does it have
to be put in the Jitsi install?

In Preferences, there are "Standard" and "Mandatory" buttons and "SAS Signature Processing"
checkbox and "SAS Types". What am I supposed to do with those?

How do you ensure that only zrtp protected calls are made?

Does it all work along with audio conferencing?

-mda

--
O zi buna,

Kertesz Laszlo

Using Opera's revolutionary email client: http://www.opera.com/mail/


#4

thank you very much for clarifying this. Very, very useful explanation.
Best regards

···

On Tue, Jul 19, 2011 at 10:07 AM, Kertesz Laszlo <laszlo.kertesz@gmail.com> wrote:

Hello,

Zrtp isnt always enabled by default. I found that i have to manually tick
everything except "trusted mitm" under Options -> security -> call (all tabs
and all options under it).
Make sure both ends have them enabled.

By default every option was off and i couldnt establish a zrtp call (i
couldnt establish a call at all because one side had the zrtp options on and
the other didnt).

I posted about this a while ago, but the devs said that by default zrtp
should work. It didnt for me on 2 installs.
So maybe the defaults are wrong.

On Tue, 19 Jul 2011 10:56:03 +0300, Mark D. Anderson <mda@discerning.com> > wrote:

I read the ZRTP FAQ at
http://www.jitsi.org/index.php/Documentation/ZrtpFAQ#faqWhere
but it doesn't actually clarify much about using Jitsi.

There is a "where to find it" question, but does that mean that ZRTP won't
work
at all out of the box? If there is an additional download, where does it
have
to be put in the Jitsi install?

In Preferences, there are "Standard" and "Mandatory" buttons and "SAS
Signature Processing"
checkbox and "SAS Types". What am I supposed to do with those?

How do you ensure that only zrtp protected calls are made?

Does it all work along with audio conferencing?

-mda

--
O zi buna,

Kertesz Laszlo

Using Opera's revolutionary email client: http://www.opera.com/mail/


#5

Freeswitch do zrtp
Cheers!

Envoyé de mon iPhone

···

Le 19 juil. 2011 à 10:05, Emil Ivov <emcho@jitsi.org> a écrit :

Hey all,

ZRTP _is_ enabled by default and as long as your server allows the ZRTP
handshake packets to go through it _will_ automatically kick in.

Unless you know exactly what you are doing you should not be fiddling
with the ZRTP settings at all and leave them as they were during the
installation. There is a rendering bug in the ZRTP configuration form
that displays all properties unchecked by default. This is not the case.
Everything _is_ activated. However, if you save the form in that state
they will all be saved as unchecked (Kertesz, is it possible that this
is what happened to you?). So again, best leave those untouched after
installation. We'll be fixing this bug of course and we are also
planning on moving all ZRTP configuration behind a "ZRTP Ninja" button
or something similar.

The only place where a Jitsi user should care about ZRTP is the SAS
string verification once a call starts.

Now, you should also keep in mind that servers like Asterisk would not
allow ZRTP packets to go through so you won't be able to secure calls
that are connected via Asterisk. The same is valid for any B2BUA that
would behave this way.

Cheers,
Emil

На 19.07.11 10:19, Andrea Gavians написа:

thank you very much for clarifying this. Very, very useful explanation.
Best regards

On Tue, Jul 19, 2011 at 10:07 AM, Kertesz Laszlo >> <laszlo.kertesz@gmail.com> wrote:

Hello,

Zrtp isnt always enabled by default. I found that i have to manually tick
everything except "trusted mitm" under Options -> security -> call (all tabs
and all options under it).
Make sure both ends have them enabled.

By default every option was off and i couldnt establish a zrtp call (i
couldnt establish a call at all because one side had the zrtp options on and
the other didnt).

I posted about this a while ago, but the devs said that by default zrtp
should work. It didnt for me on 2 installs.
So maybe the defaults are wrong.

On Tue, 19 Jul 2011 10:56:03 +0300, Mark D. Anderson <mda@discerning.com> >>> wrote:

I read the ZRTP FAQ at
http://www.jitsi.org/index.php/Documentation/ZrtpFAQ#faqWhere
but it doesn't actually clarify much about using Jitsi.

There is a "where to find it" question, but does that mean that ZRTP won't
work
at all out of the box? If there is an additional download, where does it
have
to be put in the Jitsi install?

In Preferences, there are "Standard" and "Mandatory" buttons and "SAS
Signature Processing"
checkbox and "SAS Types". What am I supposed to do with those?

How do you ensure that only zrtp protected calls are made?

Does it all work along with audio conferencing?

-mda

--
O zi buna,

Kertesz Laszlo

Using Opera's revolutionary email client: http://www.opera.com/mail/

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


#6

Hey all,

ZRTP _is_ enabled by default and as long as your server allows the ZRTP
handshake packets to go through it _will_ automatically kick in.

Unless you know exactly what you are doing you should not be fiddling
with the ZRTP settings at all and leave them as they were during the
installation. There is a rendering bug in the ZRTP configuration form
that displays all properties unchecked by default. This is not the case.
Everything _is_ activated. However, if you save the form in that state
they will all be saved as unchecked (Kertesz, is it possible that this
is what happened to you?). So again, best leave those untouched after
installation. We'll be fixing this bug of course and we are also
planning on moving all ZRTP configuration behind a "ZRTP Ninja" button
or something similar.

The only place where a Jitsi user should care about ZRTP is the SAS
string verification once a call starts.

Now, you should also keep in mind that servers like Asterisk would not
allow ZRTP packets to go through so you won't be able to secure calls
that are connected via Asterisk. The same is valid for any B2BUA that
would behave this way.

Cheers,
Emil

На 19.07.11 10:19, Andrea Gavians написа:

···

thank you very much for clarifying this. Very, very useful explanation.
Best regards

On Tue, Jul 19, 2011 at 10:07 AM, Kertesz Laszlo > <laszlo.kertesz@gmail.com> wrote:

Hello,

Zrtp isnt always enabled by default. I found that i have to manually tick
everything except "trusted mitm" under Options -> security -> call (all tabs
and all options under it).
Make sure both ends have them enabled.

By default every option was off and i couldnt establish a zrtp call (i
couldnt establish a call at all because one side had the zrtp options on and
the other didnt).

I posted about this a while ago, but the devs said that by default zrtp
should work. It didnt for me on 2 installs.
So maybe the defaults are wrong.

On Tue, 19 Jul 2011 10:56:03 +0300, Mark D. Anderson <mda@discerning.com> >> wrote:

I read the ZRTP FAQ at
http://www.jitsi.org/index.php/Documentation/ZrtpFAQ#faqWhere
but it doesn't actually clarify much about using Jitsi.

There is a "where to find it" question, but does that mean that ZRTP won't
work
at all out of the box? If there is an additional download, where does it
have
to be put in the Jitsi install?

In Preferences, there are "Standard" and "Mandatory" buttons and "SAS
Signature Processing"
checkbox and "SAS Types". What am I supposed to do with those?

How do you ensure that only zrtp protected calls are made?

Does it all work along with audio conferencing?

-mda

--
O zi buna,

Kertesz Laszlo

Using Opera's revolutionary email client: http://www.opera.com/mail/

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


#7

Hello,

I just installed Jitsi on th eother computer, configured the accounts + codecs in the same order i had on my machine (Google talk accounts).
Wanted to make a call and nothing happened, if i remember correctly the calling window just hang there without doing anything.
So i went in the settings and saw that everything was unticked under security. Ticked everything except "trusted mitm" (as was on my machine) and everything worked perfectly from that moment on.
Exactly that happened when i rinstalled Jitsi from scratch on my laptop.
Maybe you should make Jitsi have a default set of zrtp (based on best security options) and detect the other sides settings and automatically adjust its options if called with different ones that are locally set (if that is possible, that is).

PS I know about the SIP Asterisk issue, i have an account in our SIP server and zrtp doesnt work with it.

···

On Tue, 19 Jul 2011 12:05:04 +0300, Emil Ivov <emcho@jitsi.org> wrote:

Hey all,

ZRTP _is_ enabled by default and as long as your server allows the ZRTP
handshake packets to go through it _will_ automatically kick in.

Unless you know exactly what you are doing you should not be fiddling
with the ZRTP settings at all and leave them as they were during the
installation. There is a rendering bug in the ZRTP configuration form
that displays all properties unchecked by default. This is not the case.
Everything _is_ activated. However, if you save the form in that state
they will all be saved as unchecked (Kertesz, is it possible that this
is what happened to you?). So again, best leave those untouched after
installation. We'll be fixing this bug of course and we are also
planning on moving all ZRTP configuration behind a "ZRTP Ninja" button
or something similar.

The only place where a Jitsi user should care about ZRTP is the SAS
string verification once a call starts.

Now, you should also keep in mind that servers like Asterisk would not
allow ZRTP packets to go through so you won't be able to secure calls
that are connected via Asterisk. The same is valid for any B2BUA that
would behave this way.

Cheers,
Emil

На 19.07.11 10:19, Andrea Gavians написа:

thank you very much for clarifying this. Very, very useful explanation.
Best regards

On Tue, Jul 19, 2011 at 10:07 AM, Kertesz Laszlo >> <laszlo.kertesz@gmail.com> wrote:

Hello,

Zrtp isnt always enabled by default. I found that i have to manually tick
everything except "trusted mitm" under Options -> security -> call (all tabs
and all options under it).
Make sure both ends have them enabled.

By default every option was off and i couldnt establish a zrtp call (i
couldnt establish a call at all because one side had the zrtp options on and
the other didnt).

I posted about this a while ago, but the devs said that by default zrtp
should work. It didnt for me on 2 installs.
So maybe the defaults are wrong.

On Tue, 19 Jul 2011 10:56:03 +0300, Mark D. Anderson >>> <mda@discerning.com> >>> wrote:

I read the ZRTP FAQ at
http://www.jitsi.org/index.php/Documentation/ZrtpFAQ#faqWhere
but it doesn't actually clarify much about using Jitsi.

There is a "where to find it" question, but does that mean that ZRTP won't
work
at all out of the box? If there is an additional download, where does it
have
to be put in the Jitsi install?

In Preferences, there are "Standard" and "Mandatory" buttons and "SAS
Signature Processing"
checkbox and "SAS Types". What am I supposed to do with those?

How do you ensure that only zrtp protected calls are made?

Does it all work along with audio conferencing?

-mda

--
O zi buna,

Kertesz Laszlo

Using Opera's revolutionary email client: http://www.opera.com/mail/

--
O zi buna,

Kertesz Laszlo

Using Opera's revolutionary email client: http://www.opera.com/mail/


#8

На 19.07.11 11:55, Kertesz Laszlo написа:

Hello,

I just installed Jitsi on th eother computer, configured the accounts +
codecs in the same order i had on my machine (Google talk accounts).
Wanted to make a call and nothing happened, if i remember correctly the
calling window just hang there without doing anything.

I see. There must have been a problem preventing media to flow between
the two computers. And the same problem must have prevented ZRTP from
kicking in. There is nothing in ZRTP that would prevent a call from
happening.

So i went in the settings and saw that everything was unticked under
security.

Yes, this is the rendering bug that I talked about. ZRTP is enabled even
though this is not visible. I know Yana is planning on looking at this
issue today or tomorrow.

Ticked everything except "trusted mitm" (as was on my machine)
and everything worked perfectly from that moment on.
Exactly that happened when i rinstalled Jitsi from scratch on my laptop.
Maybe you should make Jitsi have a default set of zrtp (based on best
security options) and detect the other sides settings and automatically
adjust its options if called with different ones that are locally set (if
that is possible, that is).

This is exactly what we do! If there's something preventing packets to
flow between your computers, it is definitely not ZRTP related and I
find it unlikely that ticking the checkboxes would have a direct
relationship to the fact that they start working after that.

Could you please delete your .jitsi (or .sip-communicator) folders, then
try a few calls with a fresh installation, with no modification on ZRTP,
and send us the logs?

Cheers,
Emil

···

PS I know about the SIP Asterisk issue, i have an account in our SIP
server and zrtp doesnt work with it.

On Tue, 19 Jul 2011 12:05:04 +0300, Emil Ivov <emcho@jitsi.org> wrote:

Hey all,

ZRTP _is_ enabled by default and as long as your server allows the ZRTP
handshake packets to go through it _will_ automatically kick in.

Unless you know exactly what you are doing you should not be fiddling
with the ZRTP settings at all and leave them as they were during the
installation. There is a rendering bug in the ZRTP configuration form
that displays all properties unchecked by default. This is not the case.
Everything _is_ activated. However, if you save the form in that state
they will all be saved as unchecked (Kertesz, is it possible that this
is what happened to you?). So again, best leave those untouched after
installation. We'll be fixing this bug of course and we are also
planning on moving all ZRTP configuration behind a "ZRTP Ninja" button
or something similar.

The only place where a Jitsi user should care about ZRTP is the SAS
string verification once a call starts.

Now, you should also keep in mind that servers like Asterisk would not
allow ZRTP packets to go through so you won't be able to secure calls
that are connected via Asterisk. The same is valid for any B2BUA that
would behave this way.

Cheers,
Emil

На 19.07.11 10:19, Andrea Gavians написа:

thank you very much for clarifying this. Very, very useful explanation.
Best regards

On Tue, Jul 19, 2011 at 10:07 AM, Kertesz Laszlo >>> <laszlo.kertesz@gmail.com> wrote:

Hello,

Zrtp isnt always enabled by default. I found that i have to manually
tick
everything except "trusted mitm" under Options -> security -> call
(all tabs
and all options under it).
Make sure both ends have them enabled.

By default every option was off and i couldnt establish a zrtp call (i
couldnt establish a call at all because one side had the zrtp options
on and
the other didnt).

I posted about this a while ago, but the devs said that by default zrtp
should work. It didnt for me on 2 installs.
So maybe the defaults are wrong.

On Tue, 19 Jul 2011 10:56:03 +0300, Mark D. Anderson >>>> <mda@discerning.com> >>>> wrote:

I read the ZRTP FAQ at
http://www.jitsi.org/index.php/Documentation/ZrtpFAQ#faqWhere
but it doesn't actually clarify much about using Jitsi.

There is a "where to find it" question, but does that mean that ZRTP
won't
work
at all out of the box? If there is an additional download, where does
it
have
to be put in the Jitsi install?

In Preferences, there are "Standard" and "Mandatory" buttons and "SAS
Signature Processing"
checkbox and "SAS Types". What am I supposed to do with those?

How do you ensure that only zrtp protected calls are made?

Does it all work along with audio conferencing?

-mda

--
O zi buna,

Kertesz Laszlo

Using Opera's revolutionary email client: http://www.opera.com/mail/

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

Thanks Emil for your clarifications.
It is consistent with my experience, which is that a "vanilla" Jitsi was
working better with ZRTP than a Jitsi in which I fooled with the preferences.

Are there any known issues with Jitsi and Freeswitch being compatible?
I did see this message:
  http://lists.freeswitch.org/pipermail/freeswitch-users/2011-May/072515.html
with no clear resolution.

I'm trying to set up a secure audio conferencing system. I can see two
approaches:
1. Jitsi only, with one Jitsi user running the conference.
2. Jitsi + Freeswitch, with Freeswitch running the conference and being a trusted MITM.

For the "Jisti only" solution I could imagine there being some problems with the
host user running out of bandwidth, and/or having problems doing direct peer-to-peer
connections to other users through their NAT.

For the "Jitsi + Freeswitch" solution, I guess all ZRTP and SAS checkboxes in the Preferences
have to be selected (including trusted MITM). The benefit of this approach is that it is
only outgoing connections for users, and only the server has to have bandwidth for multiple
connections. The downside is greater setup complexity and possible compatibility issues.

Any comments/suggestions on the best no hassle way to a secure audio conference?
This would be for < 10 users.

-mda


#10

Hey Mark,

На 19.07.11 21:44, Mark D. Anderson написа:

Thanks Emil for your clarifications.
It is consistent with my experience, which is that a "vanilla" Jitsi was
working better with ZRTP than a Jitsi in which I fooled with the preferences.

Are there any known issues with Jitsi and Freeswitch being compatible?

None that I am aware of. I've never personally used it though.

I did see this message:
  http://lists.freeswitch.org/pipermail/freeswitch-users/2011-May/072515.html
with no clear resolution.

I'm trying to set up a secure audio conferencing system. I can see two
approaches:
1. Jitsi only, with one Jitsi user running the conference.

Yes. This is the most painless approach since it doesn't require
anything on the server (other than free transit for the media streams).
It does however, place a requirement on minimum CPU and bandwidth
availability at the conference host.

2. Jitsi + Freeswitch, with Freeswitch running the conference and being a trusted MITM.

This is indeed a valid option but I have no personal experience with it
so I can't really comment.

For the "Jisti only" solution I could imagine there being some problems with the
host user running out of bandwidth, and/or having problems doing direct peer-to-peer
connections to other users through their NAT.

Our SIP support does not currently use ICE and relies entirely on
transparent server-side relaying / latching. I wouldn't expect any NAT
traversal issues since most SIP servers do this properly.

We do have ICE with XMPP so you can also use that for conferencing.
You'd have to host a Jingle Nodes relay or a TURN server but you'd still
be handling less server-side traffic than with ICE-less SIP.

For the "Jitsi + Freeswitch" solution, I guess all ZRTP and SAS checkboxes in the Preferences
have to be selected (including trusted MITM). The benefit of this approach is that it is
only outgoing connections for users, and only the server has to have bandwidth for multiple
connections. The downside is greater setup complexity and possible compatibility issues.

Correct.

Any comments/suggestions on the best no hassle way to a secure audio conference?
This would be for < 10 users.

Most modern PCs and broadband subscriptions should be enough for hosting
Jitsi managed conf calls for < 10 users.

Hope this helps,
Emil


#11

> I'm trying to set up a secure audio conferencing system. I can see two
> approaches:
> 1. Jitsi only, with one Jitsi user running the conference.

Yes. This is the most painless approach since it doesn't require
anything on the server (other than free transit for the media streams).
It does however, place a requirement on minimum CPU and bandwidth
availability at the conference host.

Not sure which "server" you mean, but in general, there would be no media server at all,
right? Each participant does a register with some SIP registrar like getonsip.com,
and then the SRTP media streams go direct between participants, not through
any central media server at all.

The only required server is for the SIP, not for media streams.
Though of course some participants (particularly in corporate networks) might have a far
more complicated setup within their own intranet.

> 2. Jitsi + Freeswitch, with Freeswitch running the conference and being a trusted MITM.

This is indeed a valid option but I have no personal experience with it
so I can't really comment.

> For the "Jisti only" solution I could imagine there being some problems with the
> host user running out of bandwidth, and/or having problems doing direct peer-to-peer
> connections to other users through their NAT.

Our SIP support does not currently use ICE and relies entirely on
transparent server-side relaying / latching. I wouldn't expect any NAT
traversal issues since most SIP servers do this properly.

Here I assume by "server" you mean the SIP registrars such as getonsip.com or whatever each participant
is using.

We do have ICE with XMPP so you can also use that for conferencing.
You'd have to host a Jingle Nodes relay or a TURN server but you'd still
be handling less server-side traffic than with ICE-less SIP.

But we'd also give up the security of ZRTP, right?

Most modern PCs and broadband subscriptions should be enough for hosting
Jitsi managed conf calls for < 10 users.

For a "Jitsi only" SIP conference, which codec will they negotiate, with no settings changes?
What is the (symmetric) bandwidth required for media per call with that codec?

-mda


#12

Hey Mark,

На 20.07.11 19:23, Mark D. Anderson написа:

I'm trying to set up a secure audio conferencing system. I can see two
approaches:
1. Jitsi only, with one Jitsi user running the conference.

Yes. This is the most painless approach since it doesn't require
anything on the server (other than free transit for the media streams).
It does however, place a requirement on minimum CPU and bandwidth
availability at the conference host.

Not sure which "server" you mean, but in general, there would be no media server at all,
right?

I mean your SIP or XMPP server. The one you connect to when you create
your account. Whether or not it also behaves as a media server depends
on the implementation and my point was that a Jitsi-only conference
removes that dependency and would work even with servers that don't have
any media features.

Each participant does a register with some SIP registrar like getonsip.com,
and then the SRTP media streams go direct between participants, not through
any central media server at all.

Not necessarily. Depending on the types of the NATs that users are
behind their RTP streams may need to be relayed. The way our SIP
implementation currently works, this would happen almost unconditionally
with SIP. I believe this is also how onsip's servers would work.

RTP relaying itself has no impact on security - it's basically packet
forwarding.

The only required server is for the SIP, not for media streams.
Though of course some participants (particularly in corporate networks) might have a far
more complicated setup within their own intranet.

2. Jitsi + Freeswitch, with Freeswitch running the conference and being a trusted MITM.

This is indeed a valid option but I have no personal experience with it
so I can't really comment.

For the "Jisti only" solution I could imagine there being some problems with the
host user running out of bandwidth, and/or having problems doing direct peer-to-peer
connections to other users through their NAT.

Our SIP support does not currently use ICE and relies entirely on
transparent server-side relaying / latching. I wouldn't expect any NAT
traversal issues since most SIP servers do this properly.

Here I assume by "server" you mean the SIP registrars such as getonsip.com or whatever each participant
is using.

Yes.

We do have ICE with XMPP so you can also use that for conferencing.
You'd have to host a Jingle Nodes relay or a TURN server but you'd still
be handling less server-side traffic than with ICE-less SIP.

But we'd also give up the security of ZRTP, right?

Absolutely not. ZRTP operates almost entirely on the RTP level and it
hence works with both XMPP and SIP.

Most modern PCs and broadband subscriptions should be enough for hosting
Jitsi managed conf calls for < 10 users.

For a "Jitsi only" SIP conference, which codec will they negotiate, with no settings changes?
What is the (symmetric) bandwidth required for media per call with that codec?

They'd most probably use G.722 (HD). I don't have it's exact bandwidth
requirements lying around but you can easily find them over the Internet.

Cheers,
Emil

···

-mda

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


#13

Thanks again Emil.
Some more follow-ups....

1. Is it possible to have an audio conference across multiple networks?
Right now the "Create a conference call" window has a "Call via" choice,
which is just one network.
Is that done by doing "Create a conference call" a second time for the
other network, and then both are mixed together?
For example, if there are some SIP users and some XMPP users.
Presumably the host has to have an account on every network used by any
of the participants.

2. I just had an odd experience trying out the secure calls from a PC and a
Mac in the house. Both were upgraded to latest version as of today.
The PC was the host, and called the Mac, using SIP.
The caller side had the "Compare with partner: d83o" message with a lock.

However, the corresponding window on the callee side had no such message or
lock. There was a quick warning that popped up in the lower-right corner
of the screen. It said something about SAS but unfortunately the text was
clipped, and I couldn't find a way to scroll the text, or to see a history
of past warnings after dismissing. I also can't find a way to examine the
technical status (codec, encryption, etc.) of any active call.

-mda


#14

Thanks again Emil.
Some more follow-ups....

1. Is it possible to have an audio conference across multiple networks?
Right now the "Create a conference call" window has a "Call via" choice,
which is just one network.
Is that done by doing "Create a conference call" a second time for the
other network, and then both are mixed together?
For example, if there are some SIP users and some XMPP users.
Presumably the host has to have an account on every network used by any
of the participants.

2. I just had an odd experience trying out the secure calls from a PC and a
Mac in the house. Both were upgraded to latest version as of today.
The PC was the host, and called the Mac, using SIP.
The caller side had the "Compare with partner: d83o" message with a lock.

However, the corresponding window on the callee side had no such message or
lock. There was a quick warning that popped up in the lower-right corner
of the screen. It said something about SAS but unfortunately the text was
clipped, and I couldn't find a way to scroll the text, or to see a history
of past warnings after dismissing. I also can't find a way to examine the
technical status (codec, encryption, etc.) of any active call.

I should add that this happened to me when initiating a conference call
(between just the two parties). When making a direct call, i got something
closer to what I expected (both parties saw the SAS string).

-mda

···

On Thu, 21 Jul 2011 19:44 -0700, "Mark D. Anderson" <mda@discerning.com> wrote:

-mda