[jitsi-users] Can someone confirm this for me?


#1

I'm trying to help a friend troubleshoot some connection issues. I
deleted the Jitsi log and them called him on XMPP. The attached log is
ONLY a log of my initial connection to the servers then my attempted
call to him.

- From what I can tell, it looks like what's actually failing may be
audio codec negotiation and ICE. Can anyone take a look at these logs
and confirm or am I reading them wrong?

Thanks!
Anthony

- --
Anthony Papillion
Phone: 1.918.533.9699
SIP: 17772098750@in.callcentric.com
XMPP: cypherpunk@patts.us

www.cajuntechie.org

jitsi0.log.0 (29.9 KB)


#2

Hello,

···

On 8/1/13 2:23 AM, Anthony Papillion wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

I'm trying to help a friend troubleshoot some connection issues. I
deleted the Jitsi log and them called him on XMPP. The attached log is
ONLY a log of my initial connection to the servers then my attempted
call to him.

- From what I can tell, it looks like what's actually failing may be
audio codec negotiation and ICE. Can anyone take a look at these logs
and confirm or am I reading them wrong?

Yes, it's an ICE failure.

Regards,
Boris


#3

Many thanks. That gives a starting point to dig into. So I'm assuming
that the audio related failures we see in the log wouldn't stop the
connection, right? We aren't even getting to the codec negotiation
when ICE fails, correct?

Thanks!
Anthony

- --
Anthony Papillion
Phone: 1.918.533.9699
SIP: 17772098750@in.callcentric.com
XMPP: cypherpunk@patts.us

www.cajuntechie.org

···

On 08/01/2013 06:41 AM, Boris Grozev wrote:

Hello, On 8/1/13 2:23 AM, Anthony Papillion wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512

I'm trying to help a friend troubleshoot some connection issues.
I deleted the Jitsi log and them called him on XMPP. The attached
log is ONLY a log of my initial connection to the servers then my
attempted call to him.

- From what I can tell, it looks like what's actually failing may
be audio codec negotiation and ICE. Can anyone take a look at
these logs and confirm or am I reading them wrong?

Yes, it's an ICE failure.


#4

Hello,

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hello, On 8/1/13 2:23 AM, Anthony Papillion wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512

I'm trying to help a friend troubleshoot some connection issues.
I deleted the Jitsi log and them called him on XMPP. The attached
log is ONLY a log of my initial connection to the servers then my
attempted call to him.

- From what I can tell, it looks like what's actually failing may
be audio codec negotiation and ICE. Can anyone take a look at
these logs and confirm or am I reading them wrong?

Yes, it's an ICE failure.

Many thanks. That gives a starting point to dig into. So I'm assuming
that the audio related failures we see in the log wouldn't stop the
connection, right? We aren't even getting to the codec negotiation
when ICE fails, correct?

After a quick look at the code, it seems to me that if no mutual codec was found, we would fail before we try to do ICE. I haven't tested or looked thoroughly, though.

Something weird I noticed in the logs (which might be normal, I'm again uncertain): a relayed local candidate is found (line 203), but there aren't any timeouts for a pair with this candidate.

Regards,
Boris

···

On 8/1/13 2:44 PM, Anthony Papillion wrote:

On 08/01/2013 06:41 AM, Boris Grozev wrote:


#5

Hello, On 8/1/13 2:44 PM, Anthony Papillion wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512

Hello, On 8/1/13 2:23 AM, Anthony Papillion wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512

I'm trying to help a friend troubleshoot some connection
issues. I deleted the Jitsi log and them called him on XMPP.
The attached log is ONLY a log of my initial connection to
the servers then my attempted call to him.

- From what I can tell, it looks like what's actually failing
may be audio codec negotiation and ICE. Can anyone take a
look at these logs and confirm or am I reading them wrong?

Yes, it's an ICE failure.

Many thanks. That gives a starting point to dig into. So I'm
assuming that the audio related failures we see in the log
wouldn't stop the connection, right? We aren't even getting to
the codec negotiation when ICE fails, correct?

After a quick look at the code, it seems to me that if no mutual
codec was found, we would fail before we try to do ICE. I haven't
tested or looked thoroughly, though.

I see. OK, I will take a look at what's happening at codec negotiation
and work from there. Perhaps sitting Wireshark on this connection
again may shed some light on what is going on. It's really odd as is
detailed in my "An Interesting Problem" post from yesterday/today.

Something weird I noticed in the logs (which might be normal, I'm
again uncertain): a relayed local candidate is found (line 203),
but there aren't any timeouts for a pair with this candidate.

Hmm, okay. I'm not totally sure what that means but I'm sure we'll
pursue that too. I guess the message here is "keep digging". I'm sure
something is bound to turn up. It can't hide forever!

Thanks again for your insight. Much appreciated.

Anthony

- --
Anthony Papillion
Phone: 1.918.533.9699
SIP: 17772098750@in.callcentric.com
XMPP: cypherpunk@patts.us

www.cajuntechie.org

···

On 08/01/2013 07:05 AM, Boris Grozev wrote:

On 08/01/2013 06:41 AM, Boris Grozev wrote:


#6

Hello,

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hello, On 8/1/13 2:23 AM, Anthony Papillion wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512

I'm trying to help a friend troubleshoot some connection issues.
I deleted the Jitsi log and them called him on XMPP. The attached
log is ONLY a log of my initial connection to the servers then my
attempted call to him.

- From what I can tell, it looks like what's actually failing may
be audio codec negotiation and ICE. Can anyone take a look at
these logs and confirm or am I reading them wrong?

Yes, it's an ICE failure.

Many thanks. That gives a starting point to dig into. So I'm assuming
that the audio related failures we see in the log wouldn't stop the
connection, right? We aren't even getting to the codec negotiation
when ICE fails, correct?

After a quick look at the code, it seems to me that if no mutual codec
was found, we would fail before we try to do ICE. I haven't tested or
looked thoroughly, though.

Something weird I noticed in the logs (which might be normal, I'm again
uncertain): a relayed local candidate is found (line 203), but there
aren't any timeouts for a pair with this candidate.

This is a great catch and it could explain a number of issues. If this is ithe case it sounds like a problem with the nomination strategy.

Let's try to look at this at some point this week.

Emil

···

On 01.08.13, 14:05, Boris Grozev wrote:

On 8/1/13 2:44 PM, Anthony Papillion wrote:

On 08/01/2013 06:41 AM, Boris Grozev wrote:

Regards,
Boris

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

--
https://jitsi.org