[jitsi-dev] What can be done about the zrtp negociation delay on Gtalk/XMPP calls


#1

Hello,

The zrtp negociation at the beginning of a call via xmpp/google talk can be confusing.
You have a call that is "connected" but you cannot hear the other or viceversa until the negociation is over. After 5 seconds or so most people probably decide that this isnt working. I even had 20 or more seconds delay until the secure connection was established (and in a very few cases it never did).

The issue basically is:

1. No visual reporting of whats going on while the negociation is under way;
2. Variable and sometimes long delay (usually more than 5 seconds in my case).

What can be done? I have a few ideas:

1: Make the GUI report the status of the negociation in tha call status, like "establishing secure connection" instead of "connected".
2: If the negociation cannot be made faster, i'd propose the implementation of some way of tackling the issue:

-first, implement a way of easily turn on/off zrtp that can be set from the account panel and be a per account setting - for people who want hassle-free quick access to the video/voice calls.
-second, make it absolutely sure the negociation to finish if it ever started (maybe cancel it if isnt working for some reason, making sure the establishment of the call, with or without zrtp?).

Just some ideas.

···

--
O zi buna,

Kertesz Laszlo


#2

Hey Kertesz,

I believe I've already explained this previously but here goes again:

ZRTP does not block communication during call establishment. You should
be able to very easily see that in a wireshark dump.

When you establish an XMPP call, ICE negotiation begins right after the
remote side picks up. This is the part that takes a while.

Once ICE negotiation completes, both parties start transmitting data
_including_ ZRTP.

What most likely happens during the 20" delays that you experience is
that for one reason or another ICE takes longer to complete. Once it
does, packets start flowing so both ZRTP and RTP become unblocked.

It would be interesting to look at the logs for one such session and see
why ICE took a while.

Cheers,
Emil

···

On 26.01.12 21:15, Kertesz Laszlo wrote:

Hello,

The zrtp negociation at the beginning of a call via xmpp/google talk can be confusing.
You have a call that is "connected" but you cannot hear the other or viceversa until the negociation is over. After 5 seconds or so most people probably decide that this isnt working. I even had 20 or more seconds delay until the secure connection was established (and in a very few cases it never did).

The issue basically is:

1. No visual reporting of whats going on while the negociation is under way;
2. Variable and sometimes long delay (usually more than 5 seconds in my case).

What can be done? I have a few ideas:

1: Make the GUI report the status of the negociation in tha call status, like "establishing secure connection" instead of "connected".
2: If the negociation cannot be made faster, i'd propose the implementation of some way of tackling the issue:

-first, implement a way of easily turn on/off zrtp that can be set from the account panel and be a per account setting - for people who want hassle-free quick access to the video/voice calls.
-second, make it absolutely sure the negociation to finish if it ever started (maybe cancel it if isnt working for some reason, making sure the establishment of the call, with or without zrtp?).

Just some ideas.

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

Emil,

since it appears that ICE negotiation can take some time and normal users will find
this difficult to understand, I suggest that a pop-up window as soon the remote side
picks-up should appear stating "ICE negotiation started, please wait". The word
"connected" should not appear until ICE and/or ZRTP negotiations are finished.

Another possibility would be
"Connection negotiations starting, please wait until connected." or
"Secure connection negotiations starting, please wait until connected."

It is like a plane or train that gets stuck or is late, people get very upset unless
they are informed. If they are informed, they accept a delay. Very simple.
This still permits people to complain on the mailing list and send in their logs
to find out what is happening.

Regards, Earl

···

On 1/27/2012 1:59 PM, Emil Ivov wrote:

Hey Kertesz,

I believe I've already explained this previously but here goes again:

ZRTP does not block communication during call establishment. You should
be able to very easily see that in a wireshark dump.

When you establish an XMPP call, ICE negotiation begins right after the
remote side picks up. This is the part that takes a while.

Once ICE negotiation completes, both parties start transmitting data
_including_ ZRTP.

What most likely happens during the 20" delays that you experience is
that for one reason or another ICE takes longer to complete. Once it
does, packets start flowing so both ZRTP and RTP become unblocked.

It would be interesting to look at the logs for one such session and see
why ICE took a while.

Cheers,
Emil

On 26.01.12 21:15, Kertesz Laszlo wrote:

Hello,

The zrtp negociation at the beginning of a call via xmpp/google talk can be confusing.
You have a call that is "connected" but you cannot hear the other or viceversa until the negociation is over. After 5 seconds or so most people probably decide that this isnt working. I even had 20 or more seconds delay until the secure connection was established (and in a very few cases it never did).

The issue basically is:

1. No visual reporting of whats going on while the negociation is under way;
2. Variable and sometimes long delay (usually more than 5 seconds in my case).

What can be done? I have a few ideas:

1: Make the GUI report the status of the negociation in tha call status, like "establishing secure connection" instead of "connected".
2: If the negociation cannot be made faster, i'd propose the implementation of some way of tackling the issue:

-first, implement a way of easily turn on/off zrtp that can be set from the account panel and be a per account setting - for people who want hassle-free quick access to the video/voice calls.
-second, make it absolutely sure the negociation to finish if it ever started (maybe cancel it if isnt working for some reason, making sure the establishment of the call, with or without zrtp?).

Just some ideas.


#4

(taking this back to dev)

Emil Ivov wrote:

Hey Kertesz,

I believe I've already explained this previously but here goes again:

ZRTP does not block communication during call establishment. You should
be able to very easily see that in a wireshark dump.

In practice only i hear the other side or noone hears anything - the
other side never hears me - after the beep everything works.

Yes and what I am saying is that whatever's blocking audio is also
blocking ZRTP. As soon as communication becomes possible, both audio
ZRTP packets start to flow so you hear both the beep and the other side.

Logs from such a session would help confirm the above.

It might be something on my side, but i have no idea, both instances of
Jitsi have exactly the same settings.

I think this is more likely related to network specifics rather than
Jitsi configuration. This doesn't mean that Jitsi can't do anything to
improve it though, but we'd need to know what the problem is so we'd
have to have a look at the logs first.

Cheers,
Emil

···

On 28.01.12 16:26, Kertesz Laszlo wrote:

When you establish an XMPP call, ICE negotiation begins right after the
remote side picks up. This is the part that takes a while.

Once ICE negotiation completes, both parties start transmitting data
_including_ ZRTP.

What most likely happens during the 20" delays that you experience is
that for one reason or another ICE takes longer to complete. Once it
does, packets start flowing so both ZRTP and RTP become unblocked.

It would be interesting to look at the logs for one such session and see
why ICE took a while.

Cheers,
Emil

On 26.01.12 21:15, Kertesz Laszlo wrote:

Hello,

The zrtp negociation at the beginning of a call via xmpp/google talk can be confusing.
You have a call that is "connected" but you cannot hear the other or viceversa until the negociation is over. After 5 seconds or so most people probably decide that this isnt working. I even had 20 or more seconds delay until the secure connection was established (and in a very few cases it never did).

The issue basically is:

1. No visual reporting of whats going on while the negociation is under way;
2. Variable and sometimes long delay (usually more than 5 seconds in my case).

What can be done? I have a few ideas:

1: Make the GUI report the status of the negociation in tha call status, like "establishing secure connection" instead of "connected".
2: If the negociation cannot be made faster, i'd propose the implementation of some way of tackling the issue:

-first, implement a way of easily turn on/off zrtp that can be set from the account panel and be a per account setting - for people who want hassle-free quick access to the video/voice calls.
-second, make it absolutely sure the negociation to finish if it ever started (maybe cancel it if isnt working for some reason, making sure the establishment of the call, with or without zrtp?).

Just some ideas.

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


#5

Hey Earl,

I think that's a good idea. We'll try to do that in the near future.

Cheers,
Emil

···

On 28.01.12 13:47, Earl wrote:

Emil,

since it appears that ICE negotiation can take some time and normal
users will find
this difficult to understand, I suggest that a pop-up window as soon the
remote side
picks-up should appear stating "ICE negotiation started, please wait".
The word
"connected" should not appear until ICE and/or ZRTP negotiations are
finished.

Another possibility would be
"Connection negotiations starting, please wait until connected." or
"Secure connection negotiations starting, please wait until connected."

It is like a plane or train that gets stuck or is late, people get very
upset unless
they are informed. If they are informed, they accept a delay. Very simple.
This still permits people to complain on the mailing list and send in
their logs
to find out what is happening.

Regards, Earl

On 1/27/2012 1:59 PM, Emil Ivov wrote:

Hey Kertesz,

I believe I've already explained this previously but here goes again:

ZRTP does not block communication during call establishment. You should
be able to very easily see that in a wireshark dump.

When you establish an XMPP call, ICE negotiation begins right after the
remote side picks up. This is the part that takes a while.

Once ICE negotiation completes, both parties start transmitting data
_including_ ZRTP.

What most likely happens during the 20" delays that you experience is
that for one reason or another ICE takes longer to complete. Once it
does, packets start flowing so both ZRTP and RTP become unblocked.

It would be interesting to look at the logs for one such session and see
why ICE took a while.

Cheers,
Emil

On 26.01.12 21:15, Kertesz Laszlo wrote:

Hello,

The zrtp negociation at the beginning of a call via xmpp/google talk can be confusing.
You have a call that is "connected" but you cannot hear the other or viceversa until the negociation is over. After 5 seconds or so most people probably decide that this isnt working. I even had 20 or more seconds delay until the secure connection was established (and in a very few cases it never did).

The issue basically is:

1. No visual reporting of whats going on while the negociation is under way;
2. Variable and sometimes long delay (usually more than 5 seconds in my case).

What can be done? I have a few ideas:

1: Make the GUI report the status of the negociation in tha call status, like "establishing secure connection" instead of "connected".
2: If the negociation cannot be made faster, i'd propose the implementation of some way of tackling the issue:

-first, implement a way of easily turn on/off zrtp that can be set from the account panel and be a per account setting - for people who want hassle-free quick access to the video/voice calls.
-second, make it absolutely sure the negociation to finish if it ever started (maybe cancel it if isnt working for some reason, making sure the establishment of the call, with or without zrtp?).

Just some ideas.

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