[jitsi-dev] ICE candidates

keith_bayer · 2018-05-30 06:25:30 UTC

Hi,

When connecting jitsi to an XMPP call service behind a nat, I only get
around a 50%
success rate. Looking into it, I noticed that jitsi always accepts the
first candidate
(which defines the local route) but sometimes ignores the second candidate
(which
defines the stun route).

It looks like TransportManagerGTalkImpl.startConnectivityEstablishment()
checks if component.getRemoteCandidateCount() is at least 1, then proceeds
to
allow connectivity establishment. However In my case, if the threshold is
set to 2,
then ICE is successful all of the time and the call proceeds.

The comment above the loop seems to indicate that this is what is expected:
            /*
             * Once again because the ICE Agent does not support adding
             * candidates after the connectivity establishment has been
started
             * and because multiple transport-info JingleIQs may be used to
send
             * the whole set of transport candidates from the remote peer
to the
             * local peer, do not really start the connectivity
establishment
             * until we have at least two remote candidates (i.e. local and
             * stun) per ICE Component.
             */
However, the threshold is only set to 1 for some reason. Is this a bug or
was it
set this way for some other reason?

thanks,
Keith

emcho · 2018-06-18 21:11:33 UTC

Hey Keith,

This should be working. The comment you quote is somewhat outdated.

Could you please send us the jitsi logs [0] for a session where this
happened to you?

Cheers,
Emil

[0] http://jitsi.org/faq/logs

На 01.11.11 18:05, keith bayer написа:

···

Hi,

When connecting jitsi to an XMPP call service behind a nat, I only get
around a 50%
success rate. Looking into it, I noticed that jitsi always accepts the
first candidate
(which defines the local route) but sometimes ignores the second
candidate (which
defines the stun route).

It looks like TransportManagerGTalkImpl.startConnectivityEstablishment()
checks if component.getRemoteCandidateCount() is at least 1, then
proceeds to
allow connectivity establishment. However In my case, if the threshold
is set to 2,
then ICE is successful all of the time and the call proceeds.

The comment above the loop seems to indicate that this is what is expected:
            /*
             * Once again because the ICE Agent does not support adding
             * candidates after the connectivity establishment has been
started
             * and because multiple transport-info JingleIQs may be used
to send
             * the whole set of transport candidates from the remote
peer to the
             * local peer, do not really start the connectivity
establishment
             * until we have at least two remote candidates (i.e. local and
             * stun) per ICE Component.
             */
However, the threshold is only set to 1 for some reason. Is this a bug
or was it
set this way for some other reason?

thanks,
Keith

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

keith_bayer · 2018-05-30 06:54:37 UTC

Sure. In the sip-communicator log, only the 10.0.0.X local address is
received
while the stun address never seems to be picked up (before ICE times out or
begins processing etc).

thanks,
Keith

logs.zip (11.9 KB)

···

On Tue, Nov 1, 2011 at 1:20 PM, Emil Ivov <emcho@jitsi.org> wrote:

Hey Keith,

This should be working. The comment you quote is somewhat outdated.

Could you please send us the jitsi logs [0] for a session where this
happened to you?

Cheers,
Emil

[0] http://jitsi.org/faq/logs

На 01.11.11 18:05, keith bayer написа:
> Hi,
>
> When connecting jitsi to an XMPP call service behind a nat, I only get
> around a 50%
> success rate. Looking into it, I noticed that jitsi always accepts the
> first candidate
> (which defines the local route) but sometimes ignores the second
> candidate (which
> defines the stun route).
>
> It looks like TransportManagerGTalkImpl.startConnectivityEstablishment()
> checks if component.getRemoteCandidateCount() is at least 1, then
> proceeds to
> allow connectivity establishment. However In my case, if the threshold
> is set to 2,
> then ICE is successful all of the time and the call proceeds.
>
> The comment above the loop seems to indicate that this is what is
expected:
> /*
> * Once again because the ICE Agent does not support adding
> * candidates after the connectivity establishment has been
> started
> * and because multiple transport-info JingleIQs may be used
> to send
> * the whole set of transport candidates from the remote
> peer to the
> * local peer, do not really start the connectivity
> establishment
> * until we have at least two remote candidates (i.e. local
and
> * stun) per ICE Component.
> */
> However, the threshold is only set to 1 for some reason. Is this a bug
> or was it
> set this way for some other reason?
>
> thanks,
> Keith
>

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

Sebastien_Vincent · 2018-05-30 06:54:37 UTC

Hi Keith,

I see in the logs that you try to call echotest@araic.ignorelist.com/asterisk. Is it a public gtalk echo server (i.e. where we can run test against) ?

My first thought about the problem is that the echotest answers quickly (session-accept) before any candidates being sent from both sides. And it seems there is something that blocks Jitsi after the first candidate from echotest has been processed.

We are looking at this issue.

Regards,

···

--
Seb

Le 01/11/11 18:43, keith bayer a écrit :

Sure. In the sip-communicator log, only the 10.0.0.X local address is received
while the stun address never seems to be picked up (before ICE times out or
begins processing etc).

thanks,
Keith

On Tue, Nov 1, 2011 at 1:20 PM, Emil Ivov <emcho@jitsi.org > <mailto:emcho@jitsi.org>> wrote:

    Hey Keith,

    This should be working. The comment you quote is somewhat outdated.

    Could you please send us the jitsi logs [0] for a session where this
    happened to you?

    Cheers,
    Emil

    [0] http://jitsi.org/faq/logs

    На 01.11.11 18:05, keith bayer написа:
    > Hi,
    >
    > When connecting jitsi to an XMPP call service behind a nat, I
    only get
    > around a 50%
    > success rate. Looking into it, I noticed that jitsi always
    accepts the
    > first candidate
    > (which defines the local route) but sometimes ignores the second
    > candidate (which
    > defines the stun route).
    >
    > It looks like
    TransportManagerGTalkImpl.startConnectivityEstablishment()
    > checks if component.getRemoteCandidateCount() is at least 1, then
    > proceeds to
    > allow connectivity establishment. However In my case, if the
    threshold
    > is set to 2,
    > then ICE is successful all of the time and the call proceeds.
    >
    > The comment above the loop seems to indicate that this is what
    is expected:
    > /*
    > * Once again because the ICE Agent does not support
    adding
    > * candidates after the connectivity establishment
    has been
    > started
    > * and because multiple transport-info JingleIQs may
    be used
    > to send
    > * the whole set of transport candidates from the remote
    > peer to the
    > * local peer, do not really start the connectivity
    > establishment
    > * until we have at least two remote candidates
    (i.e. local and
    > * stun) per ICE Component.
    > */
    > However, the threshold is only set to 1 for some reason. Is
    this a bug
    > or was it
    > set this way for some other reason?
    >
    > thanks,
    > Keith
    >

    --
    Emil Ivov, Ph.D. 67000 Strasbourg,
    Project Lead France
    Jitsi
    emcho@jitsi.org <mailto:emcho@jitsi.org> PHONE: +33.1.77.62.43.30 <tel:%2B33.1.77.62.43.30>
    http://jitsi.org FAX: +33.1.77.62.47.31
    <tel:%2B33.1.77.62.47.31>

keith_bayer · 2018-05-30 07:00:05 UTC

Hi Sebastien,

You are correct that the answer happens immediately in the asterisk
dialplan. I added a 2 second delay and now get connected all the time.
I'll test a bit more today. Nice suggestion. I'm still curious about the
remote candidate count variable and why it shouldn't be set to 2 but
it seems to work fine so far on my end (with just the delay).

Thanks for the help!
Keith

···

On Wed, Nov 2, 2011 at 4:25 AM, Sebastien Vincent <seb@jitsi.org> wrote:

Hi Keith,

I see in the logs that you try to call
echotest@araic.ignorelist.com/asterisk. Is it a public gtalk echo server
(i.e. where we can run test against) ?

My first thought about the problem is that the echotest answers quickly
(session-accept) before any candidates being sent from both sides. And it
seems there is something that blocks Jitsi after the first candidate from
echotest has been processed.

We are looking at this issue.

Regards,
--
Seb

Le 01/11/11 18:43, keith bayer a écrit :

Sure. In the sip-communicator log, only the 10.0.0.X local address is
received
while the stun address never seems to be picked up (before ICE times out or
begins processing etc).

thanks,
Keith

On Tue, Nov 1, 2011 at 1:20 PM, Emil Ivov <emcho@jitsi.org> wrote:

Hey Keith,

This should be working. The comment you quote is somewhat outdated.

Could you please send us the jitsi logs [0] for a session where this
happened to you?

Cheers,
Emil

[0] http://jitsi.org/faq/logs

На 01.11.11 18:05, keith bayer написа:
> Hi,
>
> When connecting jitsi to an XMPP call service behind a nat, I only get
> around a 50%
> success rate. Looking into it, I noticed that jitsi always accepts the
> first candidate
> (which defines the local route) but sometimes ignores the second
> candidate (which
> defines the stun route).
>
> It looks like TransportManagerGTalkImpl.startConnectivityEstablishment()
> checks if component.getRemoteCandidateCount() is at least 1, then
> proceeds to
> allow connectivity establishment. However In my case, if the threshold
> is set to 2,
> then ICE is successful all of the time and the call proceeds.
>
> The comment above the loop seems to indicate that this is what is
expected:
> /*
> * Once again because the ICE Agent does not support adding
> * candidates after the connectivity establishment has been
> started
> * and because multiple transport-info JingleIQs may be used
> to send
> * the whole set of transport candidates from the remote
> peer to the
> * local peer, do not really start the connectivity
> establishment
> * until we have at least two remote candidates (i.e. local
and
> * stun) per ICE Component.
> */
> However, the threshold is only set to 1 for some reason. Is this a bug
> or was it
> set this way for some other reason?
>
> thanks,
> Keith
>

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

Sebastien_Vincent · 2018-05-30 07:03:16 UTC

Hi,

I added a fix in SVN revision 9080, and it should be available in build 3758 (currently baking).

Please test it when the buidl will be available and tell me if it works for you.

Regards,

···

--
Seb

Le 02/11/11 14:41, keith bayer a écrit :

Hi Sebastien,

You are correct that the answer happens immediately in the asterisk
dialplan. I added a 2 second delay and now get connected all the time.
I'll test a bit more today. Nice suggestion. I'm still curious about the
remote candidate count variable and why it shouldn't be set to 2 but
it seems to work fine so far on my end (with just the delay).

Thanks for the help!
Keith

On Wed, Nov 2, 2011 at 4:25 AM, Sebastien Vincent <seb@jitsi.org > <mailto:seb@jitsi.org>> wrote:

    Hi Keith,

    I see in the logs that you try to call
    echotest@araic.ignorelist.com/asterisk
    <mailto:echotest@araic.ignorelist.com/asterisk>. Is it a public
    gtalk echo server (i.e. where we can run test against) ?

    My first thought about the problem is that the echotest answers
    quickly (session-accept) before any candidates being sent from
    both sides. And it seems there is something that blocks Jitsi
    after the first candidate from echotest has been processed.

    We are looking at this issue.

    Regards,
    --
    Seb

    Le 01/11/11 18:43, keith bayer a écrit :

    Sure. In the sip-communicator log, only the 10.0.0.X local
    address is received
    while the stun address never seems to be picked up (before ICE
    times out or
    begins processing etc).

    thanks,
    Keith

    On Tue, Nov 1, 2011 at 1:20 PM, Emil Ivov <emcho@jitsi.org >> <mailto:emcho@jitsi.org>> wrote:

        Hey Keith,

        This should be working. The comment you quote is somewhat
        outdated.

        Could you please send us the jitsi logs [0] for a session
        where this
        happened to you?

        Cheers,
        Emil

        [0] http://jitsi.org/faq/logs

        На 01.11.11 18:05, keith bayer написа:
        > Hi,
        >
        > When connecting jitsi to an XMPP call service behind a nat,
        I only get
        > around a 50%
        > success rate. Looking into it, I noticed that jitsi always
        accepts the
        > first candidate
        > (which defines the local route) but sometimes ignores the
        second
        > candidate (which
        > defines the stun route).
        >
        > It looks like
        TransportManagerGTalkImpl.startConnectivityEstablishment()
        > checks if component.getRemoteCandidateCount() is at least
        1, then
        > proceeds to
        > allow connectivity establishment. However In my case, if
        the threshold
        > is set to 2,
        > then ICE is successful all of the time and the call proceeds.
        >
        > The comment above the loop seems to indicate that this is
        what is expected:
        > /*
        > * Once again because the ICE Agent does not
        support adding
        > * candidates after the connectivity
        establishment has been
        > started
        > * and because multiple transport-info
        JingleIQs may be used
        > to send
        > * the whole set of transport candidates from
        the remote
        > peer to the
        > * local peer, do not really start the connectivity
        > establishment
        > * until we have at least two remote candidates
        (i.e. local and
        > * stun) per ICE Component.
        > */
        > However, the threshold is only set to 1 for some reason.
         Is this a bug
        > or was it
        > set this way for some other reason?
        >
        > thanks,
        > Keith
        >

        --
        Emil Ivov, Ph.D. 67000 Strasbourg,
        Project Lead France
        Jitsi
        emcho@jitsi.org <mailto:emcho@jitsi.org> PHONE: +33.1.77.62.43.30 <tel:%2B33.1.77.62.43.30>
        http://jitsi.org FAX: +33.1.77.62.47.31
        <tel:%2B33.1.77.62.47.31>

keith_bayer · 2018-05-30 07:05:22 UTC

Hi Sebastien,
Works great! No answer delay needed anymore.
Thanks,
Keith

···

On Wed, Nov 2, 2011 at 9:45 AM, Sebastien Vincent <seb@jitsi.org> wrote:

Hi,

I added a fix in SVN revision 9080, and it should be available in build
3758 (currently baking).

Please test it when the buidl will be available and tell me if it works
for you.

Regards,
--
Seb

Le 02/11/11 14:41, keith bayer a écrit :

Hi Sebastien,

You are correct that the answer happens immediately in the asterisk
dialplan. I added a 2 second delay and now get connected all the time.
I'll test a bit more today. Nice suggestion. I'm still curious about the
remote candidate count variable and why it shouldn't be set to 2 but
it seems to work fine so far on my end (with just the delay).

Thanks for the help!
Keith

On Wed, Nov 2, 2011 at 4:25 AM, Sebastien Vincent <seb@jitsi.org> wrote:

Hi Keith,

I see in the logs that you try to call
echotest@araic.ignorelist.com/asterisk. Is it a public gtalk echo server
(i.e. where we can run test against) ?

My first thought about the problem is that the echotest answers quickly
(session-accept) before any candidates being sent from both sides. And it
seems there is something that blocks Jitsi after the first candidate from
echotest has been processed.

We are looking at this issue.

Regards,
--
Seb

Le 01/11/11 18:43, keith bayer a écrit :

Sure. In the sip-communicator log, only the 10.0.0.X local address is
received
while the stun address never seems to be picked up (before ICE times out
or
begins processing etc).

thanks,
Keith

On Tue, Nov 1, 2011 at 1:20 PM, Emil Ivov <emcho@jitsi.org> wrote:

Hey Keith,

This should be working. The comment you quote is somewhat outdated.

Could you please send us the jitsi logs [0] for a session where this
happened to you?

Cheers,
Emil

[0] http://jitsi.org/faq/logs

На 01.11.11 18:05, keith bayer написа:
> Hi,
>
> When connecting jitsi to an XMPP call service behind a nat, I only get
> around a 50%
> success rate. Looking into it, I noticed that jitsi always accepts the
> first candidate
> (which defines the local route) but sometimes ignores the second
> candidate (which
> defines the stun route).
>
> It looks like
TransportManagerGTalkImpl.startConnectivityEstablishment()
> checks if component.getRemoteCandidateCount() is at least 1, then
> proceeds to
> allow connectivity establishment. However In my case, if the threshold
> is set to 2,
> then ICE is successful all of the time and the call proceeds.
>
> The comment above the loop seems to indicate that this is what is
expected:
> /*
> * Once again because the ICE Agent does not support adding
> * candidates after the connectivity establishment has been
> started
> * and because multiple transport-info JingleIQs may be
used
> to send
> * the whole set of transport candidates from the remote
> peer to the
> * local peer, do not really start the connectivity
> establishment
> * until we have at least two remote candidates (i.e.
local and
> * stun) per ICE Component.
> */
> However, the threshold is only set to 1 for some reason. Is this a bug
> or was it
> set this way for some other reason?
>
> thanks,
> Keith
>

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

Sebastien_Vincent · 2018-05-30 07:06:45 UTC

Hi Keith,

Glad to hear that works. Thanks for feedback!

Regards,

···

--
Seb

Le 03/11/11 14:45, keith bayer a écrit :

Hi Sebastien,
Works great! No answer delay needed anymore.
Thanks,
Keith

On Wed, Nov 2, 2011 at 9:45 AM, Sebastien Vincent <seb@jitsi.org > <mailto:seb@jitsi.org>> wrote:

    Hi,

    I added a fix in SVN revision 9080, and it should be available in
    build 3758 (currently baking).

    Please test it when the buidl will be available and tell me if it
    works for you.

    Regards,
    --
    Seb

    Le 02/11/11 14:41, keith bayer a écrit :

    Hi Sebastien,

    You are correct that the answer happens immediately in the asterisk
    dialplan. I added a 2 second delay and now get connected all the
    time.
    I'll test a bit more today. Nice suggestion. I'm still curious
    about the
    remote candidate count variable and why it shouldn't be set to 2 but
    it seems to work fine so far on my end (with just the delay).

    Thanks for the help!
    Keith

    On Wed, Nov 2, 2011 at 4:25 AM, Sebastien Vincent <seb@jitsi.org >> <mailto:seb@jitsi.org>> wrote:

        Hi Keith,

        I see in the logs that you try to call
        echotest@araic.ignorelist.com/asterisk
        <mailto:echotest@araic.ignorelist.com/asterisk>. Is it a
        public gtalk echo server (i.e. where we can run test against) ?

        My first thought about the problem is that the echotest
        answers quickly (session-accept) before any candidates being
        sent from both sides. And it seems there is something that
        blocks Jitsi after the first candidate from echotest has been
        processed.

        We are looking at this issue.

        Regards,
        --
        Seb

        Le 01/11/11 18:43, keith bayer a écrit :

        Sure. In the sip-communicator log, only the 10.0.0.X local
        address is received
        while the stun address never seems to be picked up (before
        ICE times out or
        begins processing etc).

        thanks,
        Keith

        On Tue, Nov 1, 2011 at 1:20 PM, Emil Ivov <emcho@jitsi.org >>> <mailto:emcho@jitsi.org>> wrote:

            Hey Keith,

            This should be working. The comment you quote is
            somewhat outdated.

            Could you please send us the jitsi logs [0] for a
            session where this
            happened to you?

            Cheers,
            Emil

            [0] http://jitsi.org/faq/logs

            На 01.11.11 18:05, keith bayer написа:
            > Hi,
            >
            > When connecting jitsi to an XMPP call service behind a
            nat, I only get
            > around a 50%
            > success rate. Looking into it, I noticed that jitsi
            always accepts the
            > first candidate
            > (which defines the local route) but sometimes ignores
            the second
            > candidate (which
            > defines the stun route).
            >
            > It looks like
            TransportManagerGTalkImpl.startConnectivityEstablishment()
            > checks if component.getRemoteCandidateCount() is at
            least 1, then
            > proceeds to
            > allow connectivity establishment. However In my case,
            if the threshold
            > is set to 2,
            > then ICE is successful all of the time and the call
            proceeds.
            >
            > The comment above the loop seems to indicate that this
            is what is expected:
            > /*
            > * Once again because the ICE Agent does
            not support adding
            > * candidates after the connectivity
            establishment has been
            > started
            > * and because multiple transport-info
            JingleIQs may be used
            > to send
            > * the whole set of transport candidates
            from the remote
            > peer to the
            > * local peer, do not really start the
            connectivity
            > establishment
            > * until we have at least two remote
            candidates (i.e. local and
            > * stun) per ICE Component.
            > */
            > However, the threshold is only set to 1 for some
            reason. Is this a bug
            > or was it
            > set this way for some other reason?
            >
            > thanks,
            > Keith
            >

            --
            Emil Ivov, Ph.D. 67000 Strasbourg,
            Project Lead France
            Jitsi
            emcho@jitsi.org <mailto:emcho@jitsi.org> PHONE: +33.1.77.62.43.30 <tel:%2B33.1.77.62.43.30>
            http://jitsi.org FAX:
            +33.1.77.62.47.31 <tel:%2B33.1.77.62.47.31>