Every morning, between about 07:15 and 07:40, Voipfone stops responding
to registration requests from my Sipura 2100 ATA. I have conducted
continuous traces of registration and network activity, and the failure
is consistently repeating at around these times every day. There is no
problem at any other time.

I know that at least one other person is experiencing the same problem,
but Voipfone insists it is not on their end.

Is anyone else here experiencing the same problem? If you use Voipfone,
try picking up the phone from time to time between about 07:15 and
07:40. Is the line dead?

--
Ian

Mark wrote:
Meanwhile there is new 2100 firmware on the Sipura web site - but
you'll need a TFTP server as they put the wrong loader program in the
upgrade package.

Another way is just to put the firmware image file on a webserver. Then
paste the URL into the upgrade_rule box on the provisioning tab.

Tim

In message , Mark
writes

Meanwhile there is new 2100 firmware on the Sipura web site - but
you'll need a TFTP server as they put the wrong loader program in the
upgrade package.

Mark, I'm not sure I understand that. (I do understand what TFTP is).

Are you saying that the TFTP client in the ATA cannot talk to the TFTP
server at Sipura for some reason? What exactly is broken? Can you please
explain.

--
Ian

news wrote:
In message , Mark
writes


Meanwhile there is new 2100 firmware on the Sipura web site - but
you'll need a TFTP server as they put the wrong loader program in the
upgrade package.


Mark, I'm not sure I understand that. (I do understand what TFTP is).

Are you saying that the TFTP client in the ATA cannot talk to the TFTP
server at Sipura for some reason? What exactly is broken? Can you please
explain.


The Sipura firmware you download from the site comes with a small app to
load the firmware to the adaptor/phone. I guess he's saying the app
supplied with the current 2100 firmware is broken, which it might be
I've not tried it. You can use a TFTP or a HTTP server to upload the
file too, put the link to the file in the upgrade rule in the
provisioning tab of the Sipura.

Paul.

In message , Mark
writes

Monday: No, line not dead, dialtone available and ATA working fine.

Today (Tuesday): Yes, no dialtone.

I was not around at 0700 onwards yesterday or today to check.


I then enabled full logging to a
syslog server and that kicked the ATA into life once more.

I have found that after the ATA has tried unsuccessfully to register for
about 15 minutes, it then goes to sleep for 20 minutes before attempting
to register again (usually successfully). If you had left your ATA alone
for about 20 minutes I suspect it would then have sprung back into life
of its own accord.

Hmmm.

Indeed!

--
Ian

In message , Mark
writes
On Mon, 16 Jan 2006 15:14:36 +0000, Paul Hayes
wrote:

The Sipura firmware you download from the site comes with a small app to
load the firmware to the adaptor/phone. I guess he's saying the app
supplied with the current 2100 firmware is broken, which it might be
I've not tried it. You can use a TFTP or a HTTP server to upload the
file too, put the link to the file in the upgrade rule in the
provisioning tab of the Sipura.

Correct. It's completely the wrong app in the zipfile.

Now I am really confused. I looked at the Sipura site yesterday for the
latest 2100 firmware zip (spa2100-3.2.5d), and saw that it only
contained a .bin file. No sign of any loader program.

Also, why do they bother to zip the file? The zipped file is only a few
bytes shorter than the unzipped version. Instead, they could just post
the .bin file, which would then be directly downloadable to the ATA. Or
have I missed the point?


To their credit, Sipura's online support was absolutely excellent and
responded really quickly to my query. They pointed me to a suitable
free TFTP server (from solarwinds.net) and the .bin file flashed with
no problem.

So I guess I have to install the TFTP server on my WinXP PC, then tell
the ATA to talk to the server, giving the location on my PC of the
Sipura .bin file which I have already downloaded?

--
Ian

news wrote:
In message , Mark
writes

On Mon, 16 Jan 2006 15:14:36 +0000, Paul Hayes
wrote:


The Sipura firmware you download from the site comes with a small app to
load the firmware to the adaptor/phone. I guess he's saying the app
supplied with the current 2100 firmware is broken, which it might be
I've not tried it. You can use a TFTP or a HTTP server to upload the
file too, put the link to the file in the upgrade rule in the
provisioning tab of the Sipura.


Correct. It's completely the wrong app in the zipfile.


Now I am really confused. I looked at the Sipura site yesterday for the
latest 2100 firmware zip (spa2100-3.2.5d), and saw that it only
contained a .bin file. No sign of any loader program.

Also, why do they bother to zip the file? The zipped file is only a few
bytes shorter than the unzipped version. Instead, they could just post
the .bin file, which would then be directly downloadable to the ATA. Or
have I missed the point?


To their credit, Sipura's online support was absolutely excellent and
responded really quickly to my query. They pointed me to a suitable
free TFTP server (from solarwinds.net) and the .bin file flashed with
no problem.


So I guess I have to install the TFTP server on my WinXP PC, then tell
the ATA to talk to the server, giving the location on my PC of the
Sipura .bin file which I have already downloaded?


Perhaps they've just completely removed the broken loader program from
the 2100 firmware download then? Normally you'll find a few files in
that zip file. Yes you can install a TFTP server, any should do I seem
to remember you have to fill in a load of forms to download the
Solarwinds one but I could be getting it mixed up with something else.
You can also use a webserver in the same way if that's easier or you
already have one.

In message , Mark
writes

1. Disconnect the WAN-side RJ45 cable and any phone leads.
2. Install TFTP server on a PC on the same local subnet as the SPA.
Make sure you give the TFTP server the right permissions, or the file
transfer process will fail.
3. Put the firmware upgrade "spa.bin" file in the tftp root directory
of the active TFTP server. I renamed the long file from the ZIP file
to avoid typing errors.
4. Find the IP address of the powered-up SPA
5. Request the upgrade via a web browser. If the TFTP server is
running on the same computer: assuming a.b.c.d is the SPA IP address,
http://a.b.c.d/upgrade?/spa.bin
If the tftp server is on a different computer (a.b.c.d is the SPA
address, a.b.c.z is the tftp server address), use the following URL:
http://a.b.c.d/upgrade?tftp://a.b.c.z/spa.bin
6. SPA will get the firmware from the TFTP server and reboot.

HTH


It does indeed help. Thanks Mark.

--
Ian

Hi,
Managed to wake up in time to catch things misbehaving!
Please forgive me for thinking out loud at the moment, wanted to report
my findings ASAP.
It looks like the phone is trying to register between 4 and 7 times
with the voipfone server, before getting a reply back, sometimes it
gets a reply back that is reported as no state.
Sometimes the phone manages to stay registered other times things
break completely and the phone becomes unregistered.
This seems to start about 6.30 AM through to 7.30 AM every morning.
Below, later half of log from router when the phone lost registration
this morning.

All started working OK at 7.38 and has been fine since.

1, Snom 360 connected to Intertex IX66 router using Virgin broadband.

I will give it more time later in the day hopefully!! And compare the
phone log also.
Hopefully these notes are of help in trying to resolve this strange
problem.

Regards
John

JAN 17 07:35:39:t5:info:send sf 212.187.162.178: REGISTER
sip:voipfone.co.uk SIP/2.0
JAN 17 07:35:39:tSip:info:recv 192.168.0.35: REGISTER
sip:voipfone.co.uk SIP/2.0
JAN 17 07:35:43:t5:info:send sf 212.187.162.178: REGISTER
sip:voipfone.co.uk SIP/2.0
JAN 17 07:35:47:t5:info:send sf 212.187.162.178: REGISTER
sip:voipfone.co.uk SIP/2.0
JAN 17 07:35:51:t5:info:send sf 212.187.162.178: REGISTER
sip:voipfone.co.uk SIP/2.0
JAN 17 07:35:53:tSip:info:SIP registration expired
, 3009****).
JAN 17 07:35:55:t5:info:send sf 212.187.162.178: REGISTER
sip:voipfone.co.uk SIP/2.0
JAN 17 07:35:55:tSip:info:recv 192.168.0.35: REGISTER
sip:voipfone.co.uk SIP/2.0
JAN 17 07:35:55:tSip:info:recv 192.168.0.35: REGISTER
sip:voipfone.co.uk SIP/2.0
JAN 17 07:35:56:tSip:info:recv 192.168.0.35: REGISTER
sip:voipfone.co.uk SIP/2.0
JAN 17 07:35:57:tSip:info:recv 192.168.0.35: REGISTER
sip:voipfone.co.uk SIP/2.0
JAN 17 07:35:59:tSip:error:No answer from destination
212.187.162.178:5060
JAN 17 07:35:59:tSip:info:No destination SIP server(s) left to fall
back to.
JAN 17 07:35:59:t1:info:send sf 192.168.0.35: SIP/2.0 408 Request
Timeout
JAN 17 07:36:59:tSip:info:recv 192.168.0.35: REGISTER
sip:voipfone.co.uk SIP/2.0
JAN 17 07:36:59:t5:info:send sf 212.187.162.178: REGISTER
sip:voipfone.co.uk SIP/2.0
JAN 17 07:36:59:tSip:info:recv 192.168.0.35: REGISTER
sip:voipfone.co.uk SIP/2.0
JAN 17 07:37:00:t5:info:send sf 212.187.162.178: REGISTER
sip:voipfone.co.uk SIP/2.0
JAN 17 07:37:00:tSip:info:recv 192.168.0.35: REGISTER
sip:voipfone.co.uk SIP/2.0
JAN 17 07:37:00:tSip:info:recv 212.187.162.178: SIP/2.0 100 Trying
JAN 17 07:37:00:tSip:info:recv 212.187.162.178: SIP/2.0 401
Unauthorized
JAN 17 07:37:00:t1:info:send sf 192.168.0.35: SIP/2.0 401 Unauthorized
JAN 17 07:37:01:tSip:info:recv 192.168.0.35: REGISTER
sip:voipfone.co.uk SIP/2.0
JAN 17 07:37:01:t5:info:send sf 212.187.162.178: REGISTER
sip:voipfone.co.uk SIP/2.0
JAN 17 07:37:01:tSip:info:recv 192.168.0.35: REGISTER
sip:voipfone.co.uk SIP/2.0
JAN 17 07:37:01:tSip:info:recv 212.187.162.178: SIP/2.0 100 Trying
JAN 17 07:37:01:tSip:info:recv 212.187.162.178: SIP/2.0 200 OK
JAN 17 07:37:01:t1:info:send sf 192.168.0.35: SIP/2.0 200 OK
JAN 17 07:37:31:tSip:info:recv 192.168.0.35: REGISTER
sip:voipfone.co.uk SIP/2.0
JAN 17 07:37:31:t5:info:send sf 212.187.162.178: REGISTER
sip:voipfone.co.uk SIP/2.0
JAN 17 07:37:32:tSip:info:recv 192.168.0.35: REGISTER
sip:voipfone.co.uk SIP/2.0
JAN 17 07:37:32:t5:info:send sf 212.187.162.178: REGISTER
sip:voipfone.co.uk SIP/2.0
JAN 17 07:37:33:tSip:info:recv 192.168.0.35: REGISTER
sip:voipfone.co.uk SIP/2.0
JAN 17 07:37:34:t5:info:send sf 212.187.162.178: REGISTER
sip:voipfone.co.uk SIP/2.0
JAN 17 07:37:35:tSip:info:recv 192.168.0.35: REGISTER
sip:voipfone.co.uk SIP/2.0
JAN 17 07:37:38:t5:info:send sf 212.187.162.178: REGISTER
sip:voipfone.co.uk SIP/2.0
JAN 17 07:37:39:tSip:info:recv 192.168.0.35: REGISTER
sip:voipfone.co.uk SIP/2.0
JAN 17 07:37:42:t5:info:send sf 212.187.162.178: REGISTER
sip:voipfone.co.uk SIP/2.0
JAN 17 07:37:46:t5:info:send sf 212.187.162.178: REGISTER
sip:voipfone.co.uk SIP/2.0
JAN 17 07:37:47:tSip:info:recv 192.168.0.35: REGISTER
sip:voipfone.co.uk SIP/2.0
JAN 17 07:37:50:t5:info:send sf 212.187.162.178: REGISTER
sip:voipfone.co.uk SIP/2.0
JAN 17 07:37:54:t5:info:send sf 212.187.162.178: REGISTER
sip:voipfone.co.uk SIP/2.0
JAN 17 07:37:57:tSip:info:recv 212.187.162.178: SIP/2.0 100 Trying
JAN 17 07:37:57:tSip:info:recv 212.187.162.178: SIP/2.0 401
Unauthorized
JAN 17 07:37:57:t1:info:send sf 192.168.0.35: SIP/2.0 401 Unauthorized
JAN 17 07:37:57:tSip:info:recv 192.168.0.35: REGISTER
sip:voipfone.co.uk SIP/2.0
JAN 17 07:37:57:t5:info:send sf 212.187.162.178: REGISTER
sip:voipfone.co.uk SIP/2.0
JAN 17 07:37:57:tSip:info:recv 192.168.0.35: REGISTER
sip:voipfone.co.uk SIP/2.0
JAN 17 07:37:58:t5:info:send sf 212.187.162.178: REGISTER
sip:voipfone.co.uk SIP/2.0
JAN 17 07:37:58:tSip:info:recv 192.168.0.35: REGISTER
sip:voipfone.co.uk SIP/2.0
JAN 17 07:37:58:tSip:info:recv 212.187.162.178: SIP/2.0 100 Trying
JAN 17 07:37:58:tSip:info:recv 212.187.162.178: SIP/2.0 200 OK
JAN 17 07:37:58:t1:info:send sf 192.168.0.35: SIP/2.0 200 OK
JAN 17 07:37:59:tSip:info:recv 212.187.162.178: SIP/2.0 100 Trying
JAN 17 07:37:59:tSip:notice:SIP 100 response from 212.187.162.178
rejected, no state
JAN 17 07:37:59:tSip:info:recv 212.187.162.178: SIP/2.0 200 OK
JAN 17 07:37:59:tSip:notice:SIP 200 response from 212.187.162.178
rejected, no state
JAN 17 07:38:28:tSip:info:recv 192.168.0.35: REGISTER
sip:voipfone.co.uk SIP/2.0
JAN 17 07:38:28:t5:info:send sf 212.187.162.178: REGISTER
sip:voipfone.co.uk SIP/2.0
JAN 17 07:38:29:tSip:info:recv 212.187.162.178: SIP/2.0 100 Trying
JAN 17 07:38:29:tSip:info:recv 212.187.162.178: SIP/2.0 401
Unauthorized
JAN 17 07:38:29:t1:info:send sf 192.168.0.35: SIP/2.0 401 Unauthorized
JAN 17 07:38:29:tSip:info:recv 192.168.0.35: REGISTER
sip:voipfone.co.uk SIP/2.0
JAN 17 07:38:29:t5:info:send sf 212.187.162.178: REGISTER
sip:voipfone.co.uk SIP/2.0
JAN 17 07:38:29:tSip:info:recv 212.187.162.178: SIP/2.0 100 Trying
JAN 17 07:38:29:tSip:info:recv 212.187.162.178: SIP/2.0 200 OK
JAN 17 07:38:29:t1:info:send sf 192.168.0.35: SIP/2.0 200 OK
JAN 17 07:38:59:tSip:info:recv 192.168.0.35: REGISTER
sip:voipfone.co.uk SIP/2.0
JAN 17 07:38:59:t5:info:send sf 212.187.162.178: REGISTER
sip:voipfone.co.uk SIP/2.0
JAN 17 07:38:59:tSip:info:recv 212.187.162.178: SIP/2.0 100 Trying
JAN 17 07:38:59:tSip:info:recv 212.187.162.178: SIP/2.0 401
Unauthorized
JAN 17 07:38:59:t1:info:send sf 192.168.0.35: SIP/2.0 401 Unauthorized
JAN 17 07:38:59:tSip:info:recv 192.168.0.35: REGISTER
sip:voipfone.co.uk SIP/2.0
JAN 17 07:38:59:t5:info:send sf 212.187.162.178: REGISTER
sip:voipfone.co.uk SIP/2.0
JAN 17 07:38:59:tSip:info:recv 212.187.162.178: SIP/2.0 100 Trying
JAN 17 07:38:59:tSip:info:recv 212.187.162.178: SIP/2.0 200 OK
JAN 17 07:38:59:t1:info:send sf 192.168.0.35: SIP/2.0 200 OK
JAN 17 07:39:29:tSip:info:recv 192.168.0.35: REGISTER
sip:voipfone.co.uk SIP/2.0
JAN 17 07:39:29:t5:info:send sf 212.187.162.178: REGISTER
sip:voipfone.co.uk SIP/2.0

"RJHN *1JOD" wrote in message
oups.com...
Hi,
Managed to wake up in time to catch things misbehaving!
Please forgive me for thinking out loud at the moment, wanted to report
my findings ASAP.
It looks like the phone is trying to register between 4 and 7 times
with the voipfone server, before getting a reply back, sometimes it
gets a reply back that is reported as no state.
Sometimes the phone manages to stay registered other times things
break completely and the phone becomes unregistered.
This seems to start about 6.30 AM through to 7.30 AM every morning.
Below, later half of log from router when the phone lost registration
this morning.

All started working OK at 7.38 and has been fine since.


Maybe they do their backups every day at 6.30AM and don't realise how much
system resources it uses up or something. Just an idea.