Some users will be seeing problems with their SIP phones/devices not registering against registrar.aasip.co.uk - we are investigating this at the moment.

We may have tracked this down - phones should be able to register ok now and we're monitoring the situation.

VoIP does appear to be stable again now.

The service was stable over night, and has been fine today.

This problem just returned. Back now.

We're getting closer to finding the cause.

Service stable again now.

We currently have a call routing problem on our VOIP platform, caused by a change made this morning (that was tested first - this is unexpected).

The change is being rolled back now.

Sorry for any inconvenience.

This has now been resolved.

Some customers are experiencing audio breakup on VoIP calls through our VoIP service. This is being investigated at the moment.

This has been resolved.

Sending of SMSs is not working at the moment, either from our notification systems (eg when a line drops) or from customers sending via our website or 'curl'.

We believe we have fixed this, and are monitoring the situation now.

Phones registered to our 'C' server are losing registration once their registration times out. We're investigating.

Now fixed.

One of our upstream carriers for VoIP is having a network problem and we have 60% packetloss to them.

This will cause VoIP problems for some calls and customers.

We expect this to be resolved quickly

Back to normal now

Problem resolved on carriers network

Users on the A call server may need to re-register their phones.

This was due to a change made to fix a problem where password changes were not being applied to the A server without manual intervention. Although that problem has been fixed, it's had the side effect of invalidating existing registrations which, due to the nature of some phones, requires the users to re-register or reboot the phone themselves.

Sorry for any inconvenience.

Seems that some customers have had ongoing problems with registrations on the A server.

We're investigating.

This should be fixed now.

Seeing some issues so planning to reboot the primary call server dropping calls in progress.

Seeing some issues so planning to reboot the primary call server dropping calls in progress.

Some customers (specifically those with a few also rings) are getting delays on inbound calls.

We're investigating.

It's occasionally manifesting itself as a silent call - this is where the caller has already hung up by the time the call connects.

Should now be fixed.

It was related to last week's 999/112 address info changes.

New recorded calls were declined for a few minutes. It's now fixed.

Ongoing calls, and all calls without call recording enabled, don't appear to have been affected.

Our main SIP server had a brief problem with setting up recorded calls.

This resulted in new calls being dropped, although ongoing calls seemed unaffected.

Now fixed - sorry for any inconvenience.

We had a minor issue routing calls on our SIP platform a few minutes ago.

It should be back to normal now, but we're investigating.

We're rebooting c.speechless, our main SIP server.

Sorry for the inconvenience.

There were some further problems. Now fixed.

AQL, one of the carriers we use for routing VoIP calls, is having some problems this morning.

We have changed routing for outbound calls to route via a different carrier for the moment, but some inbound calls may still be affected.

They're working to fix the problem as soon as possible.

This problem has been resolved.

We've had a couple of moments this morning where VoIP calls had had problems. We are investigating and have clues as to what has been causing this. Calls are working at the moment and it's being monitored closely by staff.

We believe we have found the cause of the issue and have deployed a work around and active monitoring.

Voicemail greeting messages were broken briefly earlier (around 16:04), resulting in silence when a call got to voicemail. It has been fixed. We're investigating the cause. Sorry for any inconvenience.

We just had a problem with VoIP calls being unable to be made - this affected accounts that have call recording enabled. (This also happened earlier this morning too) The cause of the problem will be investigated by our developers, we do apologise.

This happened again just now for a few minutes. Calls are working again and we're investigating. Sorry for the inconvenience.

We are still seeing some issues today, but have an idea what may be causing it at last. We'll update this evening.

We have made a number of changes which should resolve the issue. We'll post another update if there are more problems.

We had a problem again at 10:45 - now resolved, but clearly still some issues.

The main problem with calls recordings being delayed seems fixed now, which is good, but we are hitting something new now.

Being investigated.

This happened again at around 15:25. We're still investigating.

We are monitoring the situation still. Seems OK all weekend.

A small percentage of call recordings do not seem to be gettign sent. We are not sure what is causing this yet but we have added more diagnostics to try and find the cause. In practice many of these are calls being sent much later rather than not sent at all, but a few seem to have been lost.

Some in-progress recorded calls may have just dropped. Apologise for that.

We are pretty sure we have fixed this now - sorry for any inconvenience

We have had 2 instances today problems with calls resulting in our call server software needing to be restarted.

Staff are monitoring this and we'll update this post with more information when we have some.

Some inbound calls were dropped on the A SIP server.

This is due to a minor config change that was not expected to be service affecting.

Apologies for any inconvenience.

A couple of users have been reporting a problem with occasional audio drop-outs during calls. this looks like it may be related to a particular carrier. We are investigating, and have set outbound calls not to use this carrier at the moment.

Logs of audio problems and our monitoring of the carrier has matched, we have contacted the carrier and await an update. 

In the meantime, outgoing calls should now be OK.

Some incoming calls may still be affected by occasional audio loss. (The audio will return after a few seconds)

Our carrier are not reporting a problem at their end, but we are noticing IP routing issues which we are investigating now.

We believe we have got to the bottom of the routing problem causing this problem. We will carry on with our monitoring.

There's currently a problem with calls for some customers.

We're working to fix this as soon as possible.

The issue is specifically SIP phone registration. These are expiring one by one due to a database issue following the problems earlier. The database is being fixed now and this should bring all SIP phones back on line.

Database updated

This problem should now be resolved.

We are updating the VoIP control pages for managing your VoIP numbers this week. We are just completing internal testing of the changes now, and the are expected to  be live soon.

The new pages are a new layout that we are working on gradually for the control pages as a whole. The pages allow basically the same functions and controls but are presented differently. We think more clearly. They also allow more control over the new call server than the old pages (allowing more concurrent handling of incoming calls in different ways, for example).

We hope you like them. We'll be updating the on-line ordering for numbers as well soon.

Control pages are stalling a bit right now - seems a database issue with the new number control pages... Bear with us a few minutes.

OK, change over to new edit pages complete - any issues please talk to support.

We have a current problem with transferring of some calls -these are limited to numbers routed by one of our carriers. Audio is being lost when transferring calls. We are investigating this, and will update shortly.

Tracked down a remnant of the change from last Sunday. Looks OK now.

We have had a few niggles with calls this week. On Monday we had some outgoing calls dropping after 30 seconds. This was resolved quickly with a change of carrier. We have now made a more permanent fix.

We have had some issues this morning for a couple of minutes where calls could not be established. Calls in progress should not have been affected.

Also, some customers have reported some more vague problems over a longer period of time. There is a well known effect with any phone system changes that people look at every dropped call, every mis-dial, every race condition, and report problems even though they are quite normal. However, we are concerned that these reports may be genuine, and would ask customers that have any concrete examples to email support with a date and time and number and description so we can investigate.

Something not right - code being reverted now.

OK, the code had a minor change to fix a temporary fix done at the start of the week.

Somehow this has made things stable, and the code has been reverted to previous version while we get to the bottom of it.

Looking stable now.

In general the problem has related to calls being set up and not calls in progress. We are monitoring the situation closely.

OK, we have concluded that even with previous and very stable code there is still a problem, so we are checking packet logs to confirm what is breaking things now.

Looking stable now.

We have seen a few issues later in the day but extra diagnostics are showing up a likely cause which is being addressed now.

OK, a slight post mortem to follow.

We are currently investigating a problem whereby time profiles on VoIP accounts are not working correctly.

You may find your time profile is not switching over correctly - a short term workaround is to disable the Time Profile setting on the control pages, but setting the 'Incoming Calls' setting to '--Always--'

Sorry, false alarm! - this was just affecting our office profiles - other were unaffected!

Some problems with calls and registrations this morning. Some of the work preparing for the planned change at the weekend has had unexpected side effects and has been reversed.

The impact is on setting up calls. Calls in progress should not be affected and not billed either.

Sorry for any inconvenience.

One of our upstream carriers also experienced problems due to the same power outage in Telehouse North. This meant that incoming calls would have been broken for some numbers during the outage. This should be OK now.

If you are still having problems, please contact support.

Customers who have an 0800 number with us will be getting busy/engaged  when called. We are looking in to this and hope to have it resolved shortly.

Sorry for delay posting - this was quickly resolved. Sorry for inconvenience.

We experienced a power failure which resulted in the new call server going off line however it is now coming back online.

We will move the server to place with better power supply redundancy.

Note, calls in progress should not have been affected unless being recorded.

There will be planned work shortly to relocate the new call server.

We have changed a number of lines to the new call server. This should be seamless but it seems that it is not the case for all of the lines. Support can change you back if needed but the issues need to be addressed anyway in the longer term.

The main issues are :-

1. Configuration. Customers using <number>.call.me.uk as the registrar will have correctly changed to the new IP 81.187.30.119. However, some customers have 81.187.30.110 or a.speechless.aaisp.net.uk hard coded and have not changed. You can still register and route calls via the old call server and calls should reach you as normal, however we'll be contacting people still on the old server to update config.

2. Registration firewalls. Customers correctly registering on the new server may have firewalls not allowing replies. The reply comes from port 2002. You really need to allow all UDP from our call servers to your SIP devices.

3. Invite firewalls. Incoming calls now come from 81.187.30.119 but many people have locked the firewall to just one IP. We have 81.187.30.110-119 for our call servers, and have used 110, 111 and 112 in the past. Please allow UDP SIP from all of our call server addresses.

4. SIP forwarding. Where we forward calls to you by SIP, the call comes from 81.187.30.119 now. Some people have firewalls allowing this but configurations that are not accepting the call from the new call server. The config needs to allow calls from any of our call servers.

5. RTP firewall. The actual audio traffic is carrier by UDP. It is often symmetric so does not have firewall issues. The new call server negotiates end to end RTP so the audio can come from anywhere on the internet. We suggest allowing all UDP to you SIP devices.

Anyone with these issues this morning can have the call server changes back to the old server. However, configuration and firewalling issues need to be solved in the longer term and some issues (like SIP forwarding) will remain for calls that start on the new server.

In order to scale up our operation and make it more robust and reliable we have to be able to set up multiple servers and have calls reach you from more than one IP address.

Calls to numbers in international format (starting +) were failing - this has been fixed now.

This seems to have gone more seamlessly than I expected. Just a few people with issues so far.

Any issues - please do contact support.

Apologies for a slight glitch on phone call handling just before 9am this morning. We are doing ongoing work on the phone systems to integrate the new call server and the existing call server. We'll do more over the weekend.

We have changed the text handling to the new database this morning, and that seems to be working, please do let support know if you have any issues.

Some ongoing VoIP calls would have dropped at 10:05 due to a phone system problem at our end.

The system automatically recovered immediately.

Apologies for any inconvenience.

We are already planning a replacement/upgrade to the system in question. If you have any questions, please contact support.

It is probably worth mentioning that we are planning a major upgrade and change of the VoIP services with more servers, and so on - partly because of the new mobile services and partly to beef it up and sort these occasional glitches once and for all. We'll announce any planned work at the time.

We currently have a minor issue with our VoIP service.

It is being worked on at the moment.

This should now be fixed.

Looks like an issue with main call server affecting VoIP, and also causing some issues with transit in maidenhead (so ethernet customers may have been affected).

We think we see the cause so we can fix properly shortly.

Our VoIP server a.speechless dropped calls and SIP registrations at 15:44

It recovered immediately.

Sorry for any inconvenice.

We had to restart the VoIP service as calls locked up. Service is now resumed and we appoligise for the disruption.

There were a couple of subsequent issues during the day as well.

Most VoIP calls would have dropped at around 10:52 today.

Sorry for the inconvenience.

We are trying to track down the cause of this outage, but all appears to be OK at the moment.

I seems some issue is afceting some, maybe all, outbound calls this evening. We are not sure what or why yet. Both of the carriers we use appear to be failing, suggesting a more general issue. We don't yet know the cause.

This is clearly not a transient issue and we have restarted the call server. We are chasing with carriers now.

One of the carriers is looking in to this already.

OK, one of the carriers is working again now. That looks like some sort of administration error.

The other is still investigating.

But it means calls are working again, though there is a slight delay in initial connection.

The other carrier is also working now - no explanation for outage just yet.

Well, calls have been working all day, but some times with extra delay at the start. We, and the carrier, are looking in to this still.

Issue has been tracked down to a firewall configuration at their end.