[jitsi-dev] Google Talk routing issues


#1

Hello,

I did some testing with calls via Google Talk and i may have found the cause to the issues i reported with the zrtp negociation not completing and only one-sided audio.

I got the remote side's call info. Turns out the zrtp negociation works in a blink if both sides have the same routes.
Because most of the time they dont.

My Jitsi is the culprit for some reason. The remote side's route discovery works as expected every single time and fast.

Now, the facts:

Both computers are on the same VPN and can reach each other:

192.168.5.192 (mine)
192.168.5.99 (remote side)

Now, i call the other side and open the information window (via VNC), it populates in an instant with all data (ports differ a bit sometimes, but the ip addresses are the same, every single time):

Try 1:
Remote side:
ICE candidate extended type : host
Local host IP / Port : 192.168.5.99/5028
Remote host IP / Port : 192.168.5.192/5004

My side:
ICE candidate extended type : stun server reflexive
Local host IP / Port : 192.168.100.100/5008
Local reflexive IP / Port : [MY_REAL_IP_ADDRESS]/1094
Remote reflexive IP / Port : [REMOTE_REAL_IP_ADDRESS]/11322

Try 2:

My side:
ICE candidate extended type : stun server reflexive
Local host IP / Port : 192.168.5.192/5004
Local reflexive IP / Port : [MY_REAL_IP_ADDRESS]/1081
Remote host IP / Port : 192.168.5.99/5028

Remote side:
ICE candidate extended type : host
Local host IP / Port : 192.168.5.99/5028
Remote host IP / Port : 192.168.5.192/5004

The other side has every single time the addresses from the VPN.
If both sides "got it right" (actually my Jitsi gets it right and sadly it happens fewer times) by using host type candidate type, we have the connection established in an instant with zrtp negociation completed and all.

My computer has 1 real and 4 or more virtual interfaces:

eth0 192.168.100.100 - real interface
tap99 10.8.0.1 - a listening VPN interface (this vpn is hosted on my computer)
tap0 192.168.5.192 - VPN interface, connected to the same VPN the other computer is.
vboxnet0 - VirtualBox interface (i have a running VM in background).

Additionally, i have a few more VPNs i occasionally connect to.

Below are the info copy-pasted from the information windows. The remote side has only one, it is about the same each time, i had te chance to copy only this one.

Note: i edited the info by removing the real ip addresses and the google address of my peer.

Call information : Identity : laszlo.kertesz@gmail.com (Google Talk) Signalling call transport : TLS [OTHER]@gmail.com/jitsi- lshl503ABB76 : Call duration : 00:00:27 Audio info : Media stream transport protocol : UDP / RTP Codec / Frequency : opus / 48000 Hz ICE candidate extended type : stun server reflexive Local host IP / Port : 192.168.100.100/5008 Local reflexive IP / Port : [MY_REAL_IP_ADDRESS]/1094 Remote reflexive IP / Port : [REMOTE_REAL_IP_ADDRESS]/11322 Bandwith : ↓ 0 Kbps ↑ 59 Kbps Loss rate : ↓ 0% ↑ 0% Packets decoded with FEC : 0 Packets currently being discarded : 0% Total number of discarded packets : 0 Jitter : ↓ 0 ms ↑ 0 ms ICE Processing State : Completed Total harvesting time : 981 ms (for 2 harvests) Harvesting time GoogleTurnCandidateHarvester : 152 ms (for 2 harvests) Harvesting time GoogleTurnSSLCandidateHarvester : 946 ms (for 2 harvests) Harvesting time HostCandidateHarvester : 27 ms (for 4 harvests) Harvesting time JingleNodesHarvester : 325 ms (for 1 harvests) Harvesting time StunCandidateHarvester : 127 ms (for 2 harvests) Harvesting time TurnCandidateHarvester : 152 ms (for 2 harvests)

Call information : Identity : laszlo.kertesz@gmail.com (Google Talk) Signalling call transport : TLS [OTHER]@gmail.com/jitsi-lshl503ABB76 : Call duration : 00:00:58 Audio info : Media stream transport protocol : UDP / RTP Codec / Frequency : opus / 48000 Hz ICE candidate extended type : stun server reflexive Local host IP / Port : 192.168.5.192/5004 Local reflexive IP / Port : [MY_REAL_IP_ADDRESS]/1081 Remote host IP / Port : 192.168.5.99/5028 Bandwith : ↓ 29 Kbps ↑ 58 Kbps Loss rate : ↓ 0% ↑ 0% Packets decoded with FEC : 0 Packets currently being discarded : 5% Total number of discarded packets : 83 Jitter : ↓ 18 ms ↑ 0 ms ICE Processing State : Completed Total harvesting time : 987 ms (for 2 harvests) Harvesting time GoogleTurnCandidateHarvester : 145 ms (for 2 harvests) Harvesting time GoogleTurnSSLCandidateHarvester : 941 ms (for 2 harvests) Harvesting time HostCandidateHarvester : 33 ms (for 4 harvests) Harvesting time JingleNodesHarvester : 373 ms (for 1 harvests) Harvesting time StunCandidateHarvester : 127 ms (for 2 harvests) Harvesting time TurnCandidateHarvester : 145 ms (for 2 harvests)

Call information : Identity : [OTHER]@gmail.com (Google Talk) Signalling call transport : TLS laszlo.kertesz@gmail.com/laptop235DB95C : Call duration : 00:00:41 Audio info : Media stream transport protocol : UDP / RTP Codec / Frequency : opus / 48000 Hz ICE candidate extended type : host Local host IP / Port : 192.168.5.99/5028 Remote host IP / Port : 192.168.5.192/5004 Bandwith : ? 0 Kbps ? 24 Kbps Loss rate : ? 0% ? 0% Packets decoded with FEC : 0 Packets currently being discarded : 0% Total number of discarded packets : 0 Jitter : ? 0 ms ? 0 ms ICE Processing State : Completed Total harvesting time : 2270 ms (for 2 harvests) Harvesting time GoogleTurnCandidateHarvester : 2254 ms (for 2 harvests) Harvesting time GoogleTurnSSLCandidateHarvester : 714 ms (for 2 harvests) Harvesting time HostCandidateHarvester : 6 ms (for 4 harvests) Harvesting time JingleNodesHarvester : 12 ms (for 1 harvests) Harvesting time StunCandidateHarvester : 2232 ms (for 2 harvests) Harvesting time TurnCandidateHarvester : 2254 ms (for 2 harvests)

···

--
O zi buna,
Kertesz Laszlo


#2

So. I just wrote this to confirm that these issues seem to be gone in
the latest nightlies - now 1.1.4382.10205 on both sides (i assume the
RTP related patches did the trick?).

All of the last 4 Google Talk sessions i had worked perfectly.
Voice and video were both working well. The connection (with zrtp) was
established instantly after the remote side pressed the answer button.
The cameras were activated run time, went well also, zrtp kicked in
instantly.

Good work.

···

On 11/07/2012 06:23 PM, Kertesz Laszlo wrote:

Hello,

I did some testing with calls via Google Talk and i may have found the
cause to the issues i reported with the zrtp negociation not completing
and only one-sided audio.

--
O zi buna,

Kertesz Laszlo