UKVoIPTalk.com

Ivor Jones wrote:[color=blue]
> "PhilT" <newsnet@gmail.com> wrote in message
> news:1157994927.745878.126390@h48g2000cwc.googlegroups.com
>[color=green]
> > the variability of the service is too great for robust
> > testing.[/color]
>
> How so..? It works fine here and has done almost 100% since the server
> upgrades in April.[/color]

"almost 100%" may be the problem, I am looking for something for
"robust testing". You say yourself that you don't make many calls, so
maybe your sample is statistically challenged.

My reality was that having configured an ATA to use Sipgate it failed
to register for a good while, so I started messing with settings and
poking the firewall looking for solutions to the problem in order to
get a dial tone. Meantime I setup logging that showed the ATA trying to
register and failing - did I have the wrong password ? After a while I
took a break from it and came back later to discover that it had
registered, so the succession of failures followed by a success were
due to something other than my settings - the server wasn't responding.

Having got it up and running some of the calls to BT lines had no ring
tone, note *some* of the calls. Hardly ideal if trying to demonstrate
it to someone new to VoIP "this isn't ringing" "it is but there isn't a
ring tone this time" "yeah, right".

Later on I noticed the ATA had disappeared from the status indicator,
presumably a registration failure again.

I haven't managed to dial into the geo number and have the ATA respond,
I will go and test this on another known working setup first in order
to be sure that the service is working properly - once bitten twice
shy.

I set a friend up with Sipgate several months ago, she is on a wireless
network and the service sometimes works and sometimes doesn't. As the
network and the ATA settings are constant through this I am drawn to
the conclusion that Sipgate is the variable element.

Another guy I know has an asterisk server with a sipgate account on it
and he regularly sees authentication failures and other issues with
servers not responding.

So I conclude that if something doesn't work and Sipgate is the
provider then there's a greater than 50/50 chance that Sipgate is the
problem and not the end user's setup.

Phil

apologies for replying to myself, but it just failed again :-

060912|08:35:57 [0]REGISTER Retry 0
060912|08:35:57 [0]Reg Resp 401; Unauthorized
060912|08:35:57 [0]REGISTER Retry 0
060912|08:35:58 [0]Reg Resp 200; OK

got it the second time, but why "Unauthorized" the first time ?

Phil

PhilT wrote:[color=blue]
> Ivor Jones wrote:[color=green]
>> "PhilT" <newsnet@gmail.com> wrote in message
>> news:1157994927.745878.126390@h48g2000cwc.googlegroups.com
>>[color=darkred]
>>> the variability of the service is too great for robust
>>> testing.[/color]
>> How so..? It works fine here and has done almost 100% since the server
>> upgrades in April.[/color]
>
> "almost 100%" may be the problem, I am looking for something for
> "robust testing". You say yourself that you don't make many calls, so
> maybe your sample is statistically challenged.
>[/color]
Even Gradwell doesn't work 100% of the time. (or BT for that matter).

Thomas Kenyon wrote:
[color=blue]
> Even Gradwell doesn't work 100% of the time. (or BT for that matter).[/color]

true, but BT is probably 99.999% (five nines) whereas sometimes it
feels like Sipgate is nine fives.

Phil