[jitsi-dev] Jitsi's IP privacy


#1

Hi list,

I was wondering whether you could provide me with pointers regarding the IP
privacy offered by Jitsi or tell me a little bit about it. I'm aware that
Jitsi sometimes uses Jingle nodes to traverse NATs but it's unclear to me
exactly what properties Jitsi provides in terms of IP privacy.

All the best,
Stevens


#2

Hey Stevens,

Hi list,

I was wondering whether you could provide me with pointers regarding the
IP privacy offered by Jitsi or tell me a little bit about it.

If by IP privacy you mean a privacy mechanism that Jitsi implements at
the IP layer, then there's nothing specific to Jitsi. If you have things
like ipsec setup on a machine then those should just work with Jitsi too.

Jitsi does implement encryption and privacy mechanisms for RTP (voice
and video) and chats.

We use SRTP for secure voice and video transportation. We support ZRTP
and SDES as the key negotiation protocols.

We support OTR for chat protection.

I'm aware
that Jitsi sometimes uses Jingle nodes to traverse NATs but it's unclear
to me exactly what properties Jitsi provides in terms of IP privacy.

We do support Jingle nodes yes but I am not sure exactly how you see
this as being related to privacy. If you are wondering about
eavesdropping possibilities then it would be worth pointing out that
ZRTP is an end-to-end encryption mechanism so a Jingle Node Relay would
not be able to eavesdrop on media that it is relaying.

Hope this helps,
Emil

···

On 22.02.13, 14:46, Stevens Le Blond wrote:

All the best,
Stevens

--
https://jitsi.org


#3

Good morning Emil,

In fact, I was using the term "IP privacy" to mean "IP anonymity" (if there
is such a thing in existing VoIP communications). Sorry for the confusion.

We do support Jingle nodes yes but I am not sure exactly how you see

this as being related to privacy. If you are wondering about
eavesdropping possibilities then it would be worth pointing out that
ZRTP is an end-to-end encryption mechanism so a Jingle Node Relay would
not be able to eavesdrop on media that it is relaying.

Jingle nodes help in the context of IP anonymity because they conceal the
IP address of the communication partners from each others and from local
eavesdroppers. On the other end, they may also hurt IP anonymity because a
malicious jingle node may be able to find out which pairs of IP addresses
communicate with one another. I have a few specific questions:

- When exactly does Jitsi employ Jingle nodes? In particular, is the
motivation for using these nodes only to traverse NATs or were they
introduced also to provide some anonymity to Jitsi's users?

- Do you know the fraction of Jitsi calls that are relayed by Jingle nodes?
Relaying naturally increases the latency of VoIP calls which may hurt user
experience. I was also wondering whether you you had a sense of the
additional latency resulting from this relaying.

- How are Jingle nodes currently selected?

All the best,
Stevens


#4

Hey Stevens,

Good morning Emil,

In fact, I was using the term "IP privacy" to mean "IP anonymity" (if
there is such a thing in existing VoIP communications). Sorry for the
confusion.

OK, I see. Well ... there is such a thing but we don't currently do this
in Jitsi, we concentrate on protecting the data you exchange with your
peer, rather than hiding your IP address.

That said, it would be completely possible to add an option that only
allows conversations through a TURN server or a Jingle Node Relay.

    We do support Jingle nodes yes but I am not sure exactly how you see
    this as being related to privacy. If you are wondering about
    eavesdropping possibilities then it would be worth pointing out that
    ZRTP is an end-to-end encryption mechanism so a Jingle Node Relay would
    not be able to eavesdrop on media that it is relaying.

Jingle nodes help in the context of IP anonymity because they conceal
the IP address of the communication partners from each others and from
local eavesdroppers. On the other end, they may also hurt IP anonymity
because a malicious jingle node may be able to find out which pairs of
IP addresses communicate with one another. I have a few specific questions:

We currently use provider maintained Jingle Nodes only. Providers know
what who you are calling anyway and the Jingle Node doesn't really have
any other meaningful information.

- When exactly does Jitsi employ Jingle nodes? In particular, is the
motivation for using these nodes only to traverse NATs or were they
introduced also to provide some anonymity to Jitsi's users?

We currently only use Jingle Nodes (and TURN servers) as a last resort
in NAT traversal. We give higher priority to direct communication.

- Do you know the fraction of Jitsi calls that are relayed by Jingle
nodes?

There's a geographic factor in this and it depends a lot on the kind of
NATs you and your peers are using. In some parts of the worlds (like
France for example) use of relaying may be as low as 10%, in others it
may reach 50%.

Relaying naturally increases the latency of VoIP calls which may
hurt user experience. I was also wondering whether you you had a sense
of the additional latency resulting from this relaying.

Oh that really depends on where you are and where your peers are. In
theory it is possible to even have lower latency when using a relay
(although this is admittedly not a common case).

All in all, I'd say that the latency added from relaying is not going to
be perceptible to users in a majority of the cases. The real problem
with relays is the cost they add to infrastructure. The more you relay,
the more a provider needs to pay for bandwidth and server-side hardware.
This is even more of an issue with video (a lot more than it is with audio).

- How are Jingle nodes currently selected?

We just ask the provider to give us the addresses of whatever Jingle
Node relays it supports.

Cheers,
Emil

···

On 23.02.13, 11:05, Stevens Le Blond wrote:

--
https://jitsi.org


#5

Good morning Emil,

We currently use provider maintained Jingle Nodes only. Providers
know what who you are calling anyway and the Jingle Node doesn't really
have any other meaningful information.

Could you clarify what you refer to as a "provider" here?

All in all, I'd say that the latency added from relaying is not going to be

perceptible to users in a majority of the cases.

As you mentioned elsewhere in your reply, this is gonna depend a lot on the
latency between communication partners and their Jingle node. The latency
of speed of light between users located on opposite sides of the globe is
close to the maximum VoIP users can tolerate. In that case, I believe it is
critical to bias Jingle node selection to minimize the additional latency
due to relaying. Do you guys have empirical data that show the correlation
between call latency, bandwidth, jitter, packet loss, and user experience?

The real problem with relays is the cost they add to infrastructure. The

more you relay, the more a provider needs to pay for bandwidth and
server-side hardware. This is even more of an issue with video (a lot more
than it is with audio).

I may return to this when I know exactly who is the provider.

We just ask the provider to give us the addresses of whatever Jingle Node
relays it supports.

If I understand correctly, you select jingle nodes randomly among those
that are available, you do not optimize their selection, say to reduce call
latency. Is that correct?

All the best,
Stevens


#6

Hi,

in this sense I also noticed Jingle activity even I switched
it off in the configuration. Maybe the problem with not taking
configuration changes. In my network I also experience ICE difficulties
because Jitsi tries to connect to a local LAN IP (the private IP it got
from the opponent) and unfortunately keeps on trying on that IP. I can
see this in the firewall logs. From pinging etc. it is obvious that this
IP can not be reached.

Cheers,
Matt

···

Am 25.02.2013 08:59, schrieb Stevens Le Blond:

Good morning Emil,

    We currently use provider maintained Jingle Nodes only. Providers
    know what who you are calling anyway and the Jingle Node doesn't
    really have any other meaningful information.

Could you clarify what you refer to as a "provider" here?

    All in all, I'd say that the latency added from relaying is not
    going to be perceptible to users in a majority of the cases.

As you mentioned elsewhere in your reply, this is gonna depend a lot
on the latency between communication partners and their Jingle node.
The latency of speed of light between users located on opposite sides
of the globe is close to the maximum VoIP users can tolerate. In that
case, I believe it is critical to bias Jingle node selection to
minimize the additional latency due to relaying. Do you guys have
empirical data that show the correlation between call latency,
bandwidth, jitter, packet loss, and user experience?

    The real problem with relays is the cost they add to
    infrastructure. The more you relay, the more a provider needs to
    pay for bandwidth and server-side hardware. This is even more of
    an issue with video (a lot more than it is with audio).

I may return to this when I know exactly who is the provider.

    We just ask the provider to give us the addresses of whatever
    Jingle Node relays it supports.

If I understand correctly, you select jingle nodes randomly among
those that are available, you do not optimize their selection, say to
reduce call latency. Is that correct?

All the best,
Stevens


#7

Hey Stevens,

Good morning Emil,

    We currently use provider maintained Jingle Nodes only. Providers
    know what who you are calling anyway and the Jingle Node doesn't
    really have any other meaningful information.

Could you clarify what you refer to as a "provider" here?

The entity (person, company or other organisation) that maintains the
XMPP service and the Jingle Node Relay or TURN server. In the case of
jit.si that's us, the XSF are the provider for jabber.org and Google are
the one for gmail.com.

    All in all, I'd say that the latency added from relaying is not
    going to be perceptible to users in a majority of the cases.

As you mentioned elsewhere in your reply, this is gonna depend a lot on
the latency between communication partners and their Jingle node. The
latency of speed of light between users located on opposite sides of the
globe is close to the maximum VoIP users can tolerate. In that case, I
believe it is critical to bias Jingle node selection to minimize the
additional latency due to relaying.

Right ... but it can probably be best handled with conventional DNS
based geolocalisation services that would be transparent to the client.

Do you guys have empirical data that
show the correlation between call latency, bandwidth, jitter, packet
loss, and user experience?

Not that I am aware of.

    The real problem with relays is the cost they add to infrastructure.
    The more you relay, the more a provider needs to pay for bandwidth
    and server-side hardware. This is even more of an issue with video
    (a lot more than it is with audio).

I may return to this when I know exactly who is the provider.

    We just ask the provider to give us the addresses of whatever
    Jingle Node relays it supports.

If I understand correctly, you select jingle nodes randomly among those
that are available

A service would usually have just one. That's the case with jit.si for
example. I believe that, currently, if more than one were reported we'll
just take the first one.

, you do not optimize their selection, say to reduce
call latency. Is that correct?

Correct and again, I am not sure that the client should be heavily
involved in that choice.

Cheers,
Emil

···

On 25.02.13, 09:59, Stevens Le Blond wrote:

All the best,
Stevens

--
https://jitsi.org


#8

(c)2003-2011 Copyright jitsi.org

Could be renewed for the 2.0 release.


#9

Hey Matt,

Hi,

in this sense I also noticed Jingle activity even I switched
it off in the configuration. Maybe the problem with not taking
configuration changes.

Could be. What exactly was the Jingle activity you noticed? Can you
check your properties file and the value of the jingle-related
properties for the corresponding account there?

In my network I also experience ICE difficulties
because Jitsi tries to connect to a local LAN IP (the private IP it got
from the opponent) and unfortunately keeps on trying on that IP. I can
see this in the firewall logs. From pinging etc. it is obvious that this
IP can not be reached.

With ICE clients will always try all options, so the fact that you are
seeing these probes is perfectly normal. There's no way Jitsi can no
they don't work until it tries them out. Once it does, it will simply
pick the address candidates that worked over those that failed.

Cheers,
Emil

···

On 25.02.13, 12:29, Buddy Butterfly wrote:

Cheers,
Matt

Am 25.02.2013 08:59, schrieb Stevens Le Blond:

Good morning Emil,

    We currently use provider maintained Jingle Nodes only. Providers
    know what who you are calling anyway and the Jingle Node doesn't
    really have any other meaningful information.

Could you clarify what you refer to as a "provider" here?

    All in all, I'd say that the latency added from relaying is not
    going to be perceptible to users in a majority of the cases.

As you mentioned elsewhere in your reply, this is gonna depend a lot
on the latency between communication partners and their Jingle node.
The latency of speed of light between users located on opposite sides
of the globe is close to the maximum VoIP users can tolerate. In that
case, I believe it is critical to bias Jingle node selection to
minimize the additional latency due to relaying. Do you guys have
empirical data that show the correlation between call latency,
bandwidth, jitter, packet loss, and user experience?

    The real problem with relays is the cost they add to
    infrastructure. The more you relay, the more a provider needs to
    pay for bandwidth and server-side hardware. This is even more of
    an issue with video (a lot more than it is with audio).

I may return to this when I know exactly who is the provider.

    We just ask the provider to give us the addresses of whatever
    Jingle Node relays it supports.

If I understand correctly, you select jingle nodes randomly among
those that are available, you do not optimize their selection, say to
reduce call latency. Is that correct?

All the best,
Stevens

--
https://jitsi.org


#10

Good morning Emil,

Right ... but it can probably be best handled with conventional DNS based

geolocalisation services that would be transparent to the client.

Using several Jingle nodes with DNS GSLB to redirect clients to close-by
nodes would definitely help. However, depending on the DNS provider, GSLB
regions may be too coarse grain to yield optimal performance.

For example, WhisperSystems' RedPhone combines DNS GSLB with a simple
client-side mechanism. First, a client resolves a global hostname into a
subset of nodes located in their "area." At this stage, African RedPhone
users may still be given nodes as distant as the UK. Second, the client
initiates TCP connections to the nodes that were returned and selects the
first node to connect. The client-side heuristic is very simple to
implement yet, it seems to do a good job at selecting the closest node:

http://www.whispersystems.org/blog/low-latency-switching/

> Do you guys have empirical data that show the correlation between call
latency, bandwidth, jitter, packet loss, and user experience?

Not that I am aware of.

Would you be interested to collect anonymized data to perform this
analysis? I have read a lot of anecdotal evidences on this topic but not a
single rigorous evaluation. Knowing the exact trade-offs between these
metrics and user experience may lead to better VoIP designs.

All the best,
Stevens


#11

Hi Emil,

I planned to wait for the next release for filing bugs.
Today I stopped a phone call but only the window was
closed and the call stayed open. Had to kill Jitsi.

I will try and check the stuff with the configuration
in the settings files. But it probably is also better
to wait for the release.

The issue with the ICE was not the trial of the different
offers it got from Jingle, but it happened after connection
was established but there were no sound. I continuesly saw
then a "flood" of connections to this local IP. So, it
showed an established phone connection (via Jingle) but there
were no sound because the local IP was used.

Cheers,
Matt

···

Am 25.02.2013 15:51, schrieb Emil Ivov:

Hey Matt,

On 25.02.13, 12:29, Buddy Butterfly wrote:

Hi,

in this sense I also noticed Jingle activity even I switched
it off in the configuration. Maybe the problem with not taking
configuration changes.

Could be. What exactly was the Jingle activity you noticed? Can you
check your properties file and the value of the jingle-related
properties for the corresponding account there?

In my network I also experience ICE difficulties
because Jitsi tries to connect to a local LAN IP (the private IP it got
from the opponent) and unfortunately keeps on trying on that IP. I can
see this in the firewall logs. From pinging etc. it is obvious that this
IP can not be reached.

With ICE clients will always try all options, so the fact that you are
seeing these probes is perfectly normal. There's no way Jitsi can no
they don't work until it tries them out. Once it does, it will simply
pick the address candidates that worked over those that failed.

Cheers,
Emil

Cheers,
Matt

Am 25.02.2013 08:59, schrieb Stevens Le Blond:

Good morning Emil,

    We currently use provider maintained Jingle Nodes only. Providers
    know what who you are calling anyway and the Jingle Node doesn't
    really have any other meaningful information.

Could you clarify what you refer to as a "provider" here?

    All in all, I'd say that the latency added from relaying is not
    going to be perceptible to users in a majority of the cases.

As you mentioned elsewhere in your reply, this is gonna depend a lot
on the latency between communication partners and their Jingle node.
The latency of speed of light between users located on opposite sides
of the globe is close to the maximum VoIP users can tolerate. In that
case, I believe it is critical to bias Jingle node selection to
minimize the additional latency due to relaying. Do you guys have
empirical data that show the correlation between call latency,
bandwidth, jitter, packet loss, and user experience?

    The real problem with relays is the cost they add to
    infrastructure. The more you relay, the more a provider needs to
    pay for bandwidth and server-side hardware. This is even more of
    an issue with video (a lot more than it is with audio).

I may return to this when I know exactly who is the provider.

    We just ask the provider to give us the addresses of whatever
    Jingle Node relays it supports.

If I understand correctly, you select jingle nodes randomly among
those that are available, you do not optimize their selection, say to
reduce call latency. Is that correct?

All the best,
Stevens


#12

Hey Steve,

Good catch! This localised string existed in a lot of translations. I believe they're all updated now and after we commit them everything should be ok.

Thanks,
Yana

···

On Feb 25, 2013, at 1:01 PM, Steve <stevebell@gulli.com> wrote:

(c)2003-2011 Copyright jitsi.org

Could be renewed for the 2.0 release.


#13

Hey Stevens,

Good morning Emil,

    Right ... but it can probably be best handled with conventional
    DNS based geolocalisation services that would be transparent to the
    client.

Using several Jingle nodes with DNS GSLB to redirect clients to close-by
nodes would definitely help. However, depending on the DNS provider,
GSLB regions may be too coarse grain to yield optimal performance.

For example, WhisperSystems' RedPhone combines DNS GSLB with a simple
client-side mechanism. First, a client resolves a global hostname into a
subset of nodes located in their "area." At this stage, African RedPhone
users may still be given nodes as distant as the UK. Second, the client
initiates TCP connections to the nodes that were returned and selects
the first node to connect. The client-side heuristic is very simple to
implement yet, it seems to do a good job at selecting the closest node:

http://www.whispersystems.org/blog/low-latency-switching/

Sounds interesting.

    > Do you guys have empirical data that show the correlation between
    call latency, bandwidth, jitter, packet loss, and user experience?

    Not that I am aware of.

Would you be interested to collect anonymized data to perform this
analysis? I have read a lot of anecdotal evidences on this topic but not
a single rigorous evaluation. Knowing the exact trade-offs between these
metrics and user experience may lead to better VoIP designs.

What kind of data do you have in mind exactly?

In most cases I believe providers would be better suited to obtain such
information. Let's not forget that Jitsi is just a client while
geolocation is mostly about placing servers appropriately.

For these reasons a server is probably also the best place to gather
such statistics.

Cheers,
Emil

···

On 26.02.13, 11:05, Stevens Le Blond wrote:

All the best,
Stevens

--
https://jitsi.org


#14

Hey Matt,

Hi Emil,

I planned to wait for the next release for filing bugs.
Today I stopped a phone call but only the window was
closed and the call stayed open. Had to kill Jitsi.

I will try and check the stuff with the configuration
in the settings files. But it probably is also better
to wait for the release.

The issue with the ICE was not the trial of the different
offers it got from Jingle, but it happened after connection
was established but there were no sound. I continuesly saw
then a "flood" of connections to this local IP. So, it
showed an established phone connection (via Jingle) but there
were no sound because the local IP was used.

Can you tell us exactly what options you disabled? If you did it all
through the user interface (rather than manually modifying the config
file) then you've probably just disabled ICE, in which case Jitsi would
indeed just blindly use its host addresses even when they are not valid
(without ICE there would be no way to know this).

Cheers,
Emil

···

On 25.02.13, 21:12, Buddy Butterfly wrote:

Cheers,
Matt

Am 25.02.2013 15:51, schrieb Emil Ivov:

Hey Matt,

On 25.02.13, 12:29, Buddy Butterfly wrote:

Hi,

in this sense I also noticed Jingle activity even I switched
it off in the configuration. Maybe the problem with not taking
configuration changes.

Could be. What exactly was the Jingle activity you noticed? Can you
check your properties file and the value of the jingle-related
properties for the corresponding account there?

In my network I also experience ICE difficulties
because Jitsi tries to connect to a local LAN IP (the private IP it got
from the opponent) and unfortunately keeps on trying on that IP. I can
see this in the firewall logs. From pinging etc. it is obvious that this
IP can not be reached.

With ICE clients will always try all options, so the fact that you are
seeing these probes is perfectly normal. There's no way Jitsi can no
they don't work until it tries them out. Once it does, it will simply
pick the address candidates that worked over those that failed.

Cheers,
Emil

Cheers,
Matt

Am 25.02.2013 08:59, schrieb Stevens Le Blond:

Good morning Emil,

    We currently use provider maintained Jingle Nodes only. Providers
    know what who you are calling anyway and the Jingle Node doesn't
    really have any other meaningful information.

Could you clarify what you refer to as a "provider" here?

    All in all, I'd say that the latency added from relaying is not
    going to be perceptible to users in a majority of the cases.

As you mentioned elsewhere in your reply, this is gonna depend a lot
on the latency between communication partners and their Jingle node.
The latency of speed of light between users located on opposite sides
of the globe is close to the maximum VoIP users can tolerate. In that
case, I believe it is critical to bias Jingle node selection to
minimize the additional latency due to relaying. Do you guys have
empirical data that show the correlation between call latency,
bandwidth, jitter, packet loss, and user experience?

    The real problem with relays is the cost they add to
    infrastructure. The more you relay, the more a provider needs to
    pay for bandwidth and server-side hardware. This is even more of
    an issue with video (a lot more than it is with audio).

I may return to this when I know exactly who is the provider.

    We just ask the provider to give us the addresses of whatever
    Jingle Node relays it supports.

If I understand correctly, you select jingle nodes randomly among
those that are available, you do not optimize their selection, say to
reduce call latency. Is that correct?

All the best,
Stevens

--
https://jitsi.org


#15

Thanks not a huge bug, nonetheless thanks a lot for fixing it. :slight_smile:

···

Am 25.02.2013 um 21:42 schrieb Yana Stamcheva <yana@jitsi.org>:

Hey Steve,

Good catch! This localised string existed in a lot of translations. I believe they're all updated now and after we commit them everything should be ok.

Thanks,
Yana

On Feb 25, 2013, at 1:01 PM, Steve <stevebell@gulli.com> wrote:

(c)2003-2011 Copyright jitsi.org

Could be renewed for the 2.0 release.


#16

Hi Emil,

What kind of data do you have in mind exactly?

A good start would be to collect time series for the RTT, jitter, packet
loss, and bandwidth, and then at the end of a call, associate this data
with users feedbacks.

In most cases I believe providers would be better suited to obtain

such information. Let's not forget that Jitsi is just a client
while geolocation is mostly about placing servers appropriately. For these
reasons a server is probably also the best place to gather such statistics.

I agree that the simplest would be to perform the data collection at the
server. A drawback is that it would only allow to measure relayed calls but
that's okay. Could you comment on the possibility of precisely
measuring RTT, jitter, packet loss, and bandwidth at the server without
client modifications?

Another concern is that one would also need to associate these
data with users feedback indicating the quality of the call. I'm not sure
whether Jitsi clients can already generate such feedbacks.

All the best,
Stevens


#17

Hi Emil,

yes, I used the GUI to set the settings.

ICE configuration:

x : Use ICE
x : Use Google's Jingle....
x : Use Jingle Nodes
x : Auto discover Jingle Nodes relays

All others are disabled.
And I have set my own STUN Server and Jingle Node.

Cheers,
Matt

···

Am 25.02.2013 20:21, schrieb Emil Ivov:

Hey Matt,

On 25.02.13, 21:12, Buddy Butterfly wrote:

Hi Emil,

I planned to wait for the next release for filing bugs.
Today I stopped a phone call but only the window was
closed and the call stayed open. Had to kill Jitsi.

I will try and check the stuff with the configuration
in the settings files. But it probably is also better
to wait for the release.

The issue with the ICE was not the trial of the different
offers it got from Jingle, but it happened after connection
was established but there were no sound. I continuesly saw
then a "flood" of connections to this local IP. So, it
showed an established phone connection (via Jingle) but there
were no sound because the local IP was used.

Can you tell us exactly what options you disabled? If you did it all
through the user interface (rather than manually modifying the config
file) then you've probably just disabled ICE, in which case Jitsi would
indeed just blindly use its host addresses even when they are not valid
(without ICE there would be no way to know this).

Cheers,
Emil

Cheers,
Matt

Am 25.02.2013 15:51, schrieb Emil Ivov:

Hey Matt,

On 25.02.13, 12:29, Buddy Butterfly wrote:

Hi,

in this sense I also noticed Jingle activity even I switched
it off in the configuration. Maybe the problem with not taking
configuration changes.

Could be. What exactly was the Jingle activity you noticed? Can you
check your properties file and the value of the jingle-related
properties for the corresponding account there?

In my network I also experience ICE difficulties
because Jitsi tries to connect to a local LAN IP (the private IP it got
from the opponent) and unfortunately keeps on trying on that IP. I can
see this in the firewall logs. From pinging etc. it is obvious that this
IP can not be reached.

With ICE clients will always try all options, so the fact that you are
seeing these probes is perfectly normal. There's no way Jitsi can no
they don't work until it tries them out. Once it does, it will simply
pick the address candidates that worked over those that failed.

Cheers,
Emil

Cheers,
Matt

Am 25.02.2013 08:59, schrieb Stevens Le Blond:

Good morning Emil,

    We currently use provider maintained Jingle Nodes only. Providers
    know what who you are calling anyway and the Jingle Node doesn't
    really have any other meaningful information.

Could you clarify what you refer to as a "provider" here?

    All in all, I'd say that the latency added from relaying is not
    going to be perceptible to users in a majority of the cases.

As you mentioned elsewhere in your reply, this is gonna depend a lot
on the latency between communication partners and their Jingle node.
The latency of speed of light between users located on opposite sides
of the globe is close to the maximum VoIP users can tolerate. In that
case, I believe it is critical to bias Jingle node selection to
minimize the additional latency due to relaying. Do you guys have
empirical data that show the correlation between call latency,
bandwidth, jitter, packet loss, and user experience?

    The real problem with relays is the cost they add to
    infrastructure. The more you relay, the more a provider needs to
    pay for bandwidth and server-side hardware. This is even more of
    an issue with video (a lot more than it is with audio).

I may return to this when I know exactly who is the provider.

    We just ask the provider to give us the addresses of whatever
    Jingle Node relays it supports.

If I understand correctly, you select jingle nodes randomly among
those that are available, you do not optimize their selection, say to
reduce call latency. Is that correct?

All the best,
Stevens


#18

Hey Stevens,

Hi Emil,

    What kind of data do you have in mind exactly?

A good start would be to collect time series for the RTT, jitter, packet
loss, and bandwidth, and then at the end of a call, associate this data
with users feedbacks.

    In most cases I believe providers would be better suited to obtain
    such information. Let's not forget that Jitsi is just a client
    while geolocation is mostly about placing servers appropriately. For
    these reasons a server is probably also the best place to
    gather such statistics.

I agree that the simplest would be to perform the data collection at the
server. A drawback is that it would only allow to measure relayed calls
but that's okay.

Given that your point is about optimizing relay placement, isn't this
the only type of calls that would be relevant?

Could you comment on the possibility of precisely
measuring RTT, jitter, packet loss, and bandwidth at the server without
client modifications?

You should be able to make the same calculations.

Another concern is that one would also need to associate these
data with users feedback indicating the quality of the call. I'm not
sure whether Jitsi clients can already generate such feedbacks.

No, we do not currently do this.

If generation such statistics is to be contributed to Jitsi we would
probably accept them. Obviously users would need to opt-in before we
enable them.

Cheers,
Emil

···

On 27.02.13, 16:54, Stevens Le Blond wrote:

--
https://jitsi.org


#19

Good morning Emil,

Given that your point is about optimizing relay placement, isn't this the

only type of calls that would be relevant?

How to optimize relay placement is one of the important questions but not
necessary the only one worth answering. One problem I can think of with
measuring only relayed calls is that it would produce relatively few data
points for very low-latency calls so it may be hard to establish the cost
of relaying through close-by relays (as compared to direct calls). As I
said, it's probably okay though.

Could you give me an idea of the size of Jitsi's user-base, its
geographical distribution, and the number of calls relayed by your server
on a daily basis?

No, we do not currently do this. If generation such statistics is to be

contributed to Jitsi we would probably accept them. Obviously users would
need to opt-in before we enable them.

Great! I'm not sure how the server-side measurement would work
though. Modifying the Jingle code wouldn't be a problem but who would run
the instrumented version of the server?

All the best,
Stevens


#20

Hey Stevens,

Good morning Emil,

    Given that your point is about optimizing relay placement, isn't
    this the only type of calls that would be relevant?

How to optimize relay placement is one of the important questions but
not necessary the only one worth answering. One problem I can think of
with measuring only relayed calls is that it would produce relatively
few data points for very low-latency calls so it may be hard to
establish the cost of relaying through close-by relays (as compared to
direct calls). As I said, it's probably okay though.

OK

Could you give me an idea of the size of Jitsi's user-base, its
geographical distribution, and the number of calls relayed by your
server on a daily basis?

We don't have these readily available but even if we did, they would not
be related. The Jitsi user base is connecting to a myriad of servers out
there that we have no affiliation with. The jit.si user base (which
represents a tiny fraction of the Jitsi user base) is something that we
could probably pull some stats from but again, we don't currently have them.

    No, we do not currently do this. If generation such statistics is to
    be contributed to Jitsi we would probably accept them. Obviously
    users would need to opt-in before we enable them.

Great! I'm not sure how the server-side measurement would work
though. Modifying the Jingle code wouldn't be a problem but who would
run the instrumented version of the server?

I suppose, whoever's interested in getting the data. Presumably a
provider. As I said Jitsi is just a client but we are open to
suggestions (and code contributions). I suppose it's reasonable to
assume that if we were to provide the measurement tools, people may
start running them.

As far as we at Jitsi are concerned, we'd be happy to first discuss and
then integrate an extension that would improve relay selection for the
case when multiple relays are available. This way, if providers
determine they need geo localisation, they would be able to use this
mechanism.

Cheers,
Emil

···

On 28.02.13, 10:29, Stevens Le Blond wrote:

All the best,
Stevens

--
https://jitsi.org