Bug#538738: ekiga: Can not register (timeout) on 3.2.1~git20090515.9d0263-1

[Eugen Dedu]

ael wrote:
> Eugen Dedu wrote:
>> ael wrote:
>>> Package: ekiga
>>> Version: 3.2.1~git20090515.9d0263-1
>>> Severity: grave
>>> Justification: renders package unusable
>>>
>>> Ekiga 3.2.1 cannot register with my several sip providers.
>>> The accounts window shows: "Could not register (Timeout)"
>>>
>>> Using another machine running ekiga 2.0.11 IIRC on the same network 
>>> and so
>>> behind the same router/firewall, all is well.
>>>
>>> Previous versions of ekiga on the machine now running 3.2.1 also 
>>> worked properly.  The sip servers failing are ekiga, sipgate and 
>>> voip. All of this
>>> seems to strongly suggest a 3.2.1 problem.
>>
>> Hi,
>>
>> Could you please get a debug output from ekiga v2 so that we can 
>> compare the outputs?  It is strange that for ekiga.net the two 
>> versions act differently...
>>
> 
> Just tried again with 3.2.1 and it worked :-(
> 
> So I am now wondering about whether previous registrations had not 
> expired. In at least one case, (sipgate) I can log in and see current 
> registrations. I explicitly deregistered the previous tests and logged 
> into to sipgate to confirm that they had gone. So it can't be quite 
> straightforward. Nevertheless, I think I have previously encoutered 
> similar problems when I have had to wait an hour or more between tests 
> before getting a successful registration, even when ekiga confirmed 
> successful deregistration. These long waits make testing so much harder :-(
> 
> So I guess this bug report needs to be downgraded to less than grave.
> Nevertheless, ekiga does become unusable for an hour or more without any 
> warning. Sipgate, at least, enforce a minimum registration period of 1 
> hour, so just setting a small timeout in ekiga doesn't work - at least 
> in earlier versions.

This is a known issue: http://bugzilla.gnome.org/show_bug.cgi?id=579938

> I guess you don't need the diff with a v2 debug now in the light of this 
> new info.
> 
> An oddity just now on registering with sipgate was no less than 3 
> registrations:
> ------------------------------------------------------------------------
> 
> Device type      Expire         IP                               SIP-ID
> -----------     ------             --                            ------
>  Ekiga/3.2.1     26.07.2009 22:43h     192.168.0.3:5062     1049215
> 
>  Ekiga/3.2.1     26.07.2009 22:43h     86.3.134.70:16965     1049215
> 
>  Ekiga/3.2.1     26.07.2009 22:43h     86.3.134.70:5062     1049215
> 
> ------------------------------------------------------------------------
> 
> One of these is the local net address 192.168.*.*. I saw these addresses 
> on the "contacts" line for registration on the debug output, which is 
> presumably how the info was passed. But I normally only see a single 
> entry with ekiga v2, so something seems astray?

In ekiga v3 you can contact people in your network (LAN), through avahi. 
  According to my limited ekiga knowledge, ekiga v3 starts registration 
on all the interfaces.  However, the SIP server should have retained 
only one (again, I might be wrong, I do not know much of SIP).

> In passing, the use of port 5062 above is deliberate and is the same for 
> earlier versions of ekiga. It should have no bearing on the bug.
> 
> This bug report is getting fuzzy. Sorry.
> 
> Additional data point: I can deregister and then register again with 
> sipgate & ekiga.net without waiting at the moment. So even the 1 hour 
> wait is not reproducible
> 
> Summary: I am confused. Things seem to be working just now apart from 
> the use of 3 addresses rather than 1. {I saw q=? against each of them in 
> the debug output and guess these indicated an order of preference.}

So what is bug now?  Is it that upon changing version, ekiga should be 
started twice?

-- 
Eugen