Re: SUMMARY STUN, Was: Re: [GnomeMeeting-devel-list] Again: STUN

[Damien Sandras <dsandras seconix com>]

Hi,


I hope I won't sound harsh, but...

> SUGGESTED SOLUTION
> The suggested solution for this problem was to introduce a kind of
> "secondary STUN server", which is used to double-check the NAT test
> result, in case the client gets "blocked" as result.
> For the argument "every service can fail" I have to answer, that STUN
> is not only some service, it's in this case a very critical service.
> Regardless of the possibilities to improve redundance on server-side, I
> stay at my position. In our case, it is similar critical to your one
> and only DNS server failing: everything is okay, the lines are up and
> running, you have the best broadband internet access you were able to
> find, but your functionality is near -273 degrees because somebody
> pulled the cable out of the DNS server.
> 

>From my point of view, STUN can fail. If we do not want it to fail, a
solution has to be found at the server-side, not at the program side. 

> OPINIONS, UNSORTED
> - keep everything like it is at the moment
> - if implemented, invisible for the user (and thus not configurable by
>   the user)
> - define a STUN server for each account

Doesn't make sense at all and would require much work in OPAL for a
patch that would be rejected by myself and probably also by Craig.

> 
> IDEAS OF IMPLEMENTATION, UNSORTED
> - hardcode a fallback STUN

Bad.

> - fallback STUN "hardconfigured" in the Ekiga config

Bad.

> - possibility, to enter more then one servers (e.g. comma separated)
>   into the UI (but allow also only one, that would allow to let it look
>   like it is now)

Bad.

> - the config druid or the preferences dialog should contain a list of
>   STUN servers, which can also hold user-defined STUN servers (similar
>   to the URL history functionality of a browser, user entry field and
>   a drop down list)

Bad.

> - (related to above) get a list of STUN servers from a DNS RR

Better.

> - add an entries "primary STUN", "secondary STUN" in the preferences
> 

Bad.



When you are running services, like a webserver, or a sip proxy, or
anything else, and when that service is critical, then you have to use
redundancy.

The best solution would be to change the DNS entry, and have a short TTL
for that entry.

The problem that we had now is that:
- Kilian moved the STUN server without warning us that it would be done.
So we couldn't take appropriate actions.
- The new STUN server stopped working, and Kilian stopped answering to
my e-mails and SMS'es just at the same time.

So I redirected the STUN server to another IP than ours.

If we had known that the STUN server would move, then we could have had
a better organization.
-- 
 _      Damien Sandras
(o-     
//\     Ekiga Softphone: http://www.ekiga.org/
v_/_    FOSDEM 2006    : http://www.fosdem.org/
        SIP Phone      : sip:dsandras ekiga net
                         sip:600000 ekiga net