Perhaps a race? Some numbers work, others not

[ael-3]

Running ekiga on linux some numbers just silently disconnect while
others work. Calling the same numbers from my Grandstream ATA always
works.

This is using sound only: no video.

A simple example is calling the sipgate test number [hidden email].
That *always* works. In contrast calling [hidden email] (their
voicemail number) usually disconnects silently.

However if I set -d 4 for debug, [hidden email] almost always
works. Which is why I suspect a race.

I have managed after many attempts to capture a debug trace of
[hidden email] failing. I also captured a [hidden email]
debug trace working. A simple diff of the two cases wasn't useful (for
me: far too much noise, and the traces differed almost every where).

The two gzipped traces are 41K and 48K long so quite compact.
Any help with debugging these?

ael

_______________________________________________
ekiga-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/ekiga-list

[Eugen Dedu-2]

On 15/10/15 15:36, ael wrote:

> Running ekiga on linux some numbers just silently disconnect while
> others work. Calling the same numbers from my Grandstream ATA always
> works.
>
> This is using sound only: no video.
>
> A simple example is calling the sipgate test number [hidden email].
> That *always* works. In contrast calling [hidden email] (their
> voicemail number) usually disconnects silently.
>
> However if I set -d 4 for debug, [hidden email] almost always
> works. Which is why I suspect a race.
>
> I have managed after many attempts to capture a debug trace of
> [hidden email] failing. I also captured a [hidden email]
> debug trace working. A simple diff of the two cases wasn't useful (for
> me: far too much noise, and the traces differed almost every where).
>
> The two gzipped traces are 41K and 48K long so quite compact.
> Any help with debugging these?

Look in the logs at line starting with "INVITE sip:[hidden email]"
and lines afterwards if you can see an error/warning/fail.

If you send them to me/us I can take a glance to them, even if this is
surely not too useful, as the new release we are preparing has had too
many changes so that this race is surely fixed.

--
Eugen
_______________________________________________
ekiga-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/ekiga-list

[ael-3]

On Mon, Oct 19, 2015 at 05:59:49PM +0200, Eugen Dedu wrote:

> On 15/10/15 15:36, ael wrote:
> >Running ekiga on linux some numbers just silently disconnect while
> >others work. Calling the same numbers from my Grandstream ATA always
> >works.
> >
> >This is using sound only: no video.
> >
> >A simple example is calling the sipgate test number [hidden email].
> >That *always* works. In contrast calling [hidden email] (their
> >voicemail number) usually disconnects silently.
> >
> >However if I set -d 4 for debug, [hidden email] almost always
> >works. Which is why I suspect a race.
>
> Look in the logs at line starting with "INVITE sip:[hidden email]" and
> lines afterwards if you can see an error/warning/fail.
>

I have had a look at the debug trace for the failing 50000 call.
That looks as if it gets set up properly, but then I see a mysterious
interaction with another number:

2015/10/15 14:03:54.088   0:08.616          Pool:0x7f0bda3d5700 SIP     Changing
 SUBSCRIBE handler from Unsubscribed to Unsubscribing, target=sip:01993771nnn@si
pgate.co.uk;OPAL-local-id=sip:1049215%40sipgate.co.uk, id=18a833db-aa71-e511-802
c-80fa5b04ca96@shelf

I have changed the last three digits to nnn above. I did not call that
number. I am pretty sure that I have never called that 0199377... number from
ekiga. But it *is* the last number in my ekiga contacts list.

It looks as if it is sending a presence event to that number: perhaps that is
intended.

As far as I can tell, the call to 50000 is ended here:

015/10/15 14:03:54.146   0:08.674      OnRelease:...0bda1fe700 OpalCon Connecti
on Call[Cac0451611]-EP<pc>[P5bf68fff2] released
        Initial Time: Thu, 15 Oct 2015 14:03:53 +01:00
          SetUpPhase: 0.000
     ProceedingPhase: N/A
       AlertingPhase: N/A
      ConnectedPhase: 0.944
    EstablishedPhase: 0.944
     ForwardingPhase: N/A
      ReleasingPhase: 1.081
       ReleasedPhase: 1.081
     Call end reason: EndedByRemoteUser

On a quick scan, I couldn't see what reason was given for the remote
disconnection.

ael

_______________________________________________
ekiga-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/ekiga-list

[Eugen Dedu-2]

On 19/10/15 21:13, ael wrote:

> As far as I can tell, the call to 50000 is ended here:
>
> 015/10/15 14:03:54.146   0:08.674      OnRelease:...0bda1fe700 OpalCon Connecti
> on Call[Cac0451611]-EP<pc>[P5bf68fff2] released
>          Initial Time: Thu, 15 Oct 2015 14:03:53 +01:00
>            SetUpPhase: 0.000
>       ProceedingPhase: N/A
>         AlertingPhase: N/A
>        ConnectedPhase: 0.944
>      EstablishedPhase: 0.944
>       ForwardingPhase: N/A
>        ReleasingPhase: 1.081
>         ReleasedPhase: 1.081
>       Call end reason: EndedByRemoteUser
>
> On a quick scan, I couldn't see what reason was given for the remote
> disconnection.

After a quick look at the log, I see a BYE packet send by sipgate.  This
means it wants to close the connection, hence the reason you point
above: EndedByRemoteUser.

I see this for example when I call [hidden email]: this is an echo call,
i.e. I call, Ekiga.net *closes* the connection after 1-2 seconds, and
calls me afterwards.

--
Eugen
_______________________________________________
ekiga-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/ekiga-list

[ael-3]

On Mon, Oct 19, 2015 at 10:44:37PM +0200, Eugen Dedu wrote:
> On 19/10/15 21:13, ael wrote:
>
> After a quick look at the log, I see a BYE packet send by sipgate.  This
> means it wants to close the connection, hence the reason you point above:
> EndedByRemoteUser.

Thanks for looking. The trouble is that this should not be happening and
sipgate support just says "don't use ekiga" : well something like "use
another program". But as I say, I have now seen something similar on an
ATA (supplied by sipgate), so I am begining to think it is their
problem...

ael

_______________________________________________
ekiga-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/ekiga-list

[Eugen Dedu-2]

On 20/10/15 11:50, ael wrote:

> On Mon, Oct 19, 2015 at 10:44:37PM +0200, Eugen Dedu wrote:
>> On 19/10/15 21:13, ael wrote:
>>
>> After a quick look at the log, I see a BYE packet send by sipgate.  This
>> means it wants to close the connection, hence the reason you point above:
>> EndedByRemoteUser.
>
> Thanks for looking. The trouble is that this should not be happening and
> sipgate support just says "don't use ekiga" : well something like "use
> another program". But as I say, I have now seen something similar on an
> ATA (supplied by sipgate), so I am begining to think it is their
> problem...

I looked again and do not see what should be the problem, sorry.  The
only thing I would advise is to wait until the new Ekiga release appears
(I have no timeline for this, sorry!)

--
Eugen
_______________________________________________
ekiga-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/ekiga-list