[jitsi-dev] ICE failures


#1

...

Or should I make a new issue 'ICE failures'? Up to you.

Please can I have permission to make a new issue called 'ICE
failures'? I will then attach my logs to it every time I have an ICE
failure in a different scenario.

Thank you.
James.

···

On 12/02/2011, James Haigh <james.r.haigh@gmail.com> wrote:


#2

James,

На 14.02.11 23:00, James Haigh написа:

...

Or should I make a new issue 'ICE failures'? Up to you.

Please can I have permission to make a new issue called 'ICE
failures'? I will then attach my logs to it every time I have an ICE
failure in a different scenario.

I've been meaning to reply earlier but am running late on a significant
backlog. Sorry for that.

Note that an "ICE failure" is one possible outcome of every ICE
negotiation and not necessarily a problem of SIP Communicator. Unless
you are using a relay for example, an ICE failure is most likely to
indicate that your home gateway/NAT configuration does not allow for a
direct connection between you and your peer. If this is the case,
there's nothing we can do about it.

In order to determine whether this is indeed what's happening we'd need
to examine your logs. I believe you've already sent some here, if you
feel you need to send more (for example after using a service that
maintains a relay, like talkr.im) then please add them to the same thread.

We'll have a look as soon as we can.

Cheers,
Emil

···

On 12/02/2011, James Haigh <james.r.haigh@gmail.com> wrote:


#3

...

Note that an "ICE failure" is one possible outcome of every ICE
negotiation and not necessarily a problem of SIP Communicator. Unless
you are using a relay for example, an ICE failure is most likely to
indicate that your home gateway/NAT configuration does not allow for a
direct connection between you and your peer. If this is the case,
there's nothing we can do about it.

I doubt that this is the case. UPnP is definitely enabled on the
router. I have had success regarding NAT traversal when using
BitTorrent. I have successfully made exactly the same call using Gmail
Voice and Video Chat at both ends. However, 5 minutes in, the plugin
completely crashed my computer. I think the Linux version is very
buggy so I've uninstalled it.

In order to determine whether this is indeed what's happening we'd need
to examine your logs. I believe you've already sent some here, if you

Yes, I've renamed the thread. The logs are attached to this message:

http://java.net/nonav/projects/jitsi/lists/dev/archive/2011-02/message/84

feel you need to send more (for example after using a service that
maintains a relay, like talkr.im) then please add them to the same thread.

OK.

talkr.im looks interesting. I'll check this out. Thanks.

We'll have a look as soon as we can.

Thank you, I appreciate it.

···

On 14/02/2011, Emil Ivov <emcho@sip-communicator.org> wrote:

Cheers,
Emil


#4

Hey James,

As previously mentioned: we'll have a look at your logs as time permits
and will come back to you. Thanks for sending them!

A few more comments inline (nothing that important ... but just for the
record)

На 15.02.11 12:40, James Haigh написа:

...

Note that an "ICE failure" is one possible outcome of every ICE
negotiation and not necessarily a problem of SIP Communicator. Unless
you are using a relay for example, an ICE failure is most likely to
indicate that your home gateway/NAT configuration does not allow for a
direct connection between you and your peer. If this is the case,
there's nothing we can do about it.

I doubt that this is the case. UPnP is definitely enabled on the
router.

OK that's a good start indeed ... assuming of course your gateway is not
running behind a NAT itself and that UPnP is working as expected.

I have had success regarding NAT traversal when using
BitTorrent.

This doesn't really mean that much. Being able to download something
through bittorrent simply means you were able to connect to the users
that were sharing the specific content. It does not tell you anything
about your ability to establish a direct, bidirectional UDP stream with
the person you'd like to talk to.

I have successfully made exactly the same call using Gmail
Voice and Video Chat at both ends.

GoogleTalk use their own relaying mechanism so you may have been using
it during the session. You may want to fire up a WireShark and check
whether you are exchanging packets with your peer's public IP.

Cheers,
Emil

···

On 14/02/2011, Emil Ivov <emcho@sip-communicator.org> wrote:

However, 5 minutes in, the plugin
completely crashed my computer. I think the Linux version is very
buggy so I've uninstalled it.

In order to determine whether this is indeed what's happening we'd need
to examine your logs. I believe you've already sent some here, if you

Yes, I've renamed the thread. The logs are attached to this message:

http://java.net/nonav/projects/jitsi/lists/dev/archive/2011-02/message/84

feel you need to send more (for example after using a service that
maintains a relay, like talkr.im) then please add them to the same thread.

OK.

talkr.im looks interesting. I'll check this out. Thanks.

We'll have a look as soon as we can.

Thank you, I appreciate it.

Cheers,
Emil

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31


#5

...

OK that's a good start indeed ... assuming of course your gateway is not
running behind a NAT itself and that UPnP is working as expected.

I can remember the router's WAN IP address off-by-heart. It starts
with 84 so it is definitely a public address. Plusnet says that it's
dynamic and may change if the router reconnects, but it hasn't changed
since we signed up a few years ago, so I use it as if it were static.

The router is a Belkin with up-to-date firmware. I have successfully
used UPnP on this router for other purposes before. However, although
I'm not aware of any UPnP bugs, the factory firmware version was
/very/ buggy in general. The latest firmware seems far more stable but
like anything may still have some bugs hidden away.

...

GoogleTalk use their own relaying mechanism so you may have been using

Is this relaying mechanism accessible from SC?

it during the session. You may want to fire up a WireShark and check
whether you are exchanging packets with your peer's public IP.

I have uninstalled it and do not wish to reinstall it. It is buggy
proprietary crap that froze my computer within 5 minutes of use. I
much prefer FOSS like SC.

Unless this information is useful to you, however. If it is useful,
then I will collect this information for you the next time I can make
this call.

Thank you.
James.

···

On 15/02/2011, Emil Ivov <emcho@sip-communicator.org> wrote:


#6

BTW, James, Wireshark is FOSS because it is available under the GNU
General Public License version 2.

···

On Wed, Feb 16, 2011 at 2:59 AM, James Haigh <james.r.haigh@gmail.com> wrote:

I have uninstalled it and do not wish to reinstall it. It is buggy
proprietary crap that froze my computer within 5 minutes of use. I
much prefer FOSS like SC.


#7

I know Wireshark is FOSS, I've used it once or twice before for
something. I was referring to (or rather, meant to refer to) the
Google Voice and Video Chat plugin. Sorry, I was very ambiguous.

If Wireshark analysis of GV&VC is useful to you, I will indeed
reinstall GV&VC and collect this information for you.

···

On 16/02/2011, Lyubomir Marinov <lubo@sip-communicator.org> wrote:

On Wed, Feb 16, 2011 at 2:59 AM, James Haigh <james.r.haigh@gmail.com> > wrote:

I have uninstalled it and do not wish to reinstall it. It is buggy
proprietary crap that froze my computer within 5 minutes of use. I
much prefer FOSS like SC.

BTW, James, Wireshark is FOSS because it is available under the GNU
General Public License version 2.