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 |
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 |
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 |
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 |
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 |
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 |
Free forum by Nabble | Edit this page |