Re: [Ekiga-list] Perhaps a race? Some numbers work, others not

[ael <law_ence dev ntlworld com>]

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 10000 sipgate co uk 
> > That *always* works. In contrast calling 50000 sipgate co uk (their
> > voicemail number) usually disconnects silently.
> >
> > However if I set -d 4 for debug, 50000 sipgate co uk almost always
> > works. Which is why I suspect a race.
>
> Look in the logs at line starting with "INVITE sip:10000 sipgate co uk" 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