Status  >> VoIP

Order posts by limited to posts

11 Apr 2014 15:50:28
Details
11 Apr 2014 15:53:42
There is a problem with the C server and it needs to be restarted again after the maintenance yesterday evening. We are going to do this at 17:00 as we need it to be done as soon as possible. Sorry for the short notice.
Started 11 Apr 2014 15:50:28

07 Apr 2014 13:45:09
Details
07 Apr 2014 13:52:31
We will be carrying out some maintenance on our 'C' SIP server outside office hours. It will cause disruption to calls, but is likely only to last a couple of minutes and will only affect calls on the A and C servers. It will not affect calls on our "voiceless" SIP platform or SIP2SIM. We will do this on Thursday evening at around 22:30. Please contact support if you have any questions.
Update
10 Apr 2014 23:19:59
Completed earlier this evening.
Started 07 Apr 2014 13:45:09
Previously expected 10 Apr 2014 22:45:00

23 Mar 10:38:00
Details
23 Mar 09:51:01
We are investigating a problem with some incoming calls, our engineers are busy investigating this now. Apologise for the inconvenience.
Update
23 Mar 10:01:55
We have raised this with the carrier in question, they are investigating.
Update
23 Mar 10:04:39
The carrier have confirmed that they have a fault.
Update
23 Mar 10:09:20
Customers can call us on:
  • Sales: 05555 400 000
  • Support 05555 400 999
for the time being.
Update
23 Mar 10:12:32
Carrier say "Our engineers are working on this as a top priority"
Update
23 Mar 10:33:16
Carrier says: "initial investigations point to memory issues and we are investigating that further. As a temporary solution we are attempting to update our internal routing to mitigate the impacts."
Update
23 Mar 10:37:35
Incoming calls seem to be working ok now.
Resolution Calls working again. Fault was caused by upstream carrier and affected may VoIP services across the UK. The carrier has provided a 'Reason for Outage' document: http://www.aql.com/downloads/RFO_20150323_aql.pdf
Closed 23 Mar 10:38:00

12 Mar 18:30:05
Details
12 Mar 18:24:06
We allow users to provide address/location data to pass to emergency services in the event of a 999 calls.

This goes via BT and BT are being a pain at present. As we have explained the data is simply a matter of what customers provide. VoIP has no inherent way to provide an accurate geographic location of callers. But BT are unhappy with some of the data and seem to have blocked us sending updates this week.

They even suggested that they have to send OFCOM reports of incomplete and incorrect data as some sort of threat. We know a lot of people have multiple locations from which they make calls. We do this purely as a good will gesture and in the spirit of GC4, because we don't have location data in the first place. So if BT do not stop buggering about soon we'll be reporting BT to OFCOM instead.

Anyway, the upshot is that a few customers that have provided location data over that last few days are not yet updated to BT and hence the emergency services. We are working to resolve this and hope to have it working again soon.

The config pages for your VoIP set up show if there is an issue and you get an email once it is all confirmed. In the mean time, we do apologise for any concern this may cause.

None of our services are provided to be used in any "safety of life" circumstances, as per our standard terms.

Update
16 Mar 16:49:34
We are hoping to have this sorted, perhaps today.

It is likely that anyone with existing data registered may get a new email at some point confirming the data as we are planning to re-send everything from scratch just to be sure.

We would ask that customers review what they have entered and ensure it is as accurate as possible to assist emergency services in the event of a 999 call.

Update
18 Mar 17:40:37
Data is updating again to BT. We would recommend customers ensure accurate data on the control pages for 999 calls. We will review this over the next few days, and customers may still get update emails in due course.
Started 8 Mar
Previously expected 16 Mar

7 Mar 16:33:26
Details
7 Mar 16:33:26
We have been updating the systems that handle advising BT of location data for 999 calls, and this has resulted in a number of emails yesterday confirming previously entered details.

Sorry for any confusion caused.

Started 6 Mar
Previously expected 7 Mar

28 Feb 14:11:01
Details
27 Feb 12:30:57
We're investigating a problem with VoIP audio problems, calls breaking up etc. This looks to be some packetloss somewhere between us and our carriers. We'll update this post again shortly.
Update
27 Feb 13:04:21
We have identified the cause of this packetloss and are looking in to fixing it.
Update
27 Feb 14:55:30
We're working closely with a 3rd party that is involved in a BGP traffic problem between us and them. This is taking longer to get to the bottom of that we first thought.
Update
27 Feb 15:22:14
As we and the other BGP peer have not been able to get to the root cause of the problem we have put in a temporary fix. This has brought traffic levels back down to normal.
Update
27 Feb 16:26:46
Surprisingly, the problem has come back even though peering has been disabled! Needless to say, we are investigating again!
Update
27 Feb 17:00:05
The problem has gone away again whilst it was being looked in to.
Update
27 Feb 17:04:04

It's worth us explaining the problem... We have a peer at LINX that is sending us lots of traffic. This traffic is not for us, but for someone completely different - a different country even. Even through we have stopped the peering to this 3rd party, the traffic is still being sent, intermittently. This is causing our links to be filled, and hence causes packet loss.

We have been in direct contact with the 3rd party all afternoon, and we and they are confused as to how this is happening. At the point in time, we suspect some kind of router memory corruption which is causing the router to send traffic to the wrong peer. This type of problem is difficult to prove, and so it is taking time to get to the bottom of it.

We are still in contact with the 3rd party and will work to resolve this with them.

Resolution We were able to stop the floods of traffic yesterday afternoon, as a temporary measure, but the underlying problem remained until 10am Saturday when the LINX facing card at the peer was reset after the issue was reported by other LINX members. It is a shame that this was not done yesterday. This does confirm that it was to just AAISP that was affected by this. We will be working on contingency plans to allow us to react more efficiently for something like this in future. Thank you all for your understanding.
Started 27 Feb 12:15:00
Closed 28 Feb 14:11:01

18 Mar 17:39:00
Details
26 Feb 18:07:10
We have a couple of minor changes to VoIP servers planned. At present we are testing these.

The changes are subtle but we hope will assist in working with customers with asterisk boxes. We have also updated the screen setting on Remote-Party-Id to reflect trust in the CLI.

The actual update is likely to be over the weekend after some testing tomorrow. Any issues, please let support know.

Update
27 Feb 13:57:41
Due to a number of other incidents today we have decided to delay testing of new features until next week with a roll out of the new features after that. Anyone wanting to test with asterisk, etc, please do let support know (ideally on irc).
Update
9 Mar 07:20:13
Hopefully this is going to be sorted this week.
Update
12 Mar 13:28:12
The "a" voiceless server is being upgraded later today. Any issues, please let us know.
Update
13 Mar 13:43:57
Planning update "b" voiceless this evening, as no issues reported yet...
Update
17 Mar 14:01:03
The upgrade worked with no problems in what was actually being changed (a feature to assist when working with asterisk boxes) but it caused an slight unexpected side effect. As such we expect to update again this evening.
Resolution Things seem fine, closing this status.
Started 28 Feb
Closed 18 Mar 17:39:00
Previously expected 14 Mar

27 Jan 12:07:56
Details
27 Jan 11:39:35
We have identified a problem on our VOIP platform where some calls are not being recorded, engineers are working on this now. Update to follow.
Update
27 Jan 12:11:32
The problem's fixed. We don't think it actually affected any customers, only staff, but please do contact support if you notice any problems.
Started 27 Jan 10:37:49
Closed 27 Jan 12:07:56
Previously expected 27 Jan 15:37:49

15 Jan 22:00:56
Details
14 Jan 14:28:23

Snom have released a security announcement regarding their phones having number of vulnerabilities:
http://wiki.snom.com/8.7.5.15_OpenVPN_Security_Update

We advise customers to upgrade their firmware. We have a wiki page with more information on this:
http://wiki.aa.org.uk/SNOM_Firmware_Updates

We will be emailing customers that are using our VoIP service with a Snom phone shortly.

Update
15 Jan 22:00:56
Update 15th Jan 2015, 9pm: Snom have (yet again) updated their Security Update page. It is now stating that a firmware patch upgrade is not needed in most cases. We have advised customers to to upgrade, but it seems it is not as clear cut was it was earlier! We suggest people using Snom phones to review Snom's Security Update pages: http://wiki.snom.com/Security_update
Started 14 Jan 14:00:00

22 Oct 2014 14:45:53
Details
17 Oct 2014 16:43:25
Planning to do some work early Saturday and possible Sunday, before 8am. It should be virtually no disruption though. This is on the Maidenhead routers so any impact would be VoIP, colocation and Ethernet links from there. We have some slight tweaks to apply.
Started 18 Oct 2014
Previously expected 20 Oct 2014

Yesterday 14:17:06
Details
18 Aug 2014 10:48:39

Our legacy 'C' VoIP platform will be removed from service on March 2nd 2015.

This platform is now old, tired and we have a better VoIP platform: our FireBrick-based 'Voiceless' platform.

We have created a wiki page with details for customers needing to move platforms: http://wiki.aa.org.uk/VoIP_-_Moving_Platform

We will be contacting customers individually by email later in the year, but we'd recommend that customers start moving now. The wiki page above explains how to move, and in most cases it is simply changing the server details in your VoIP device. Please do contact Support for help though.

Started 18 Aug 2014 10:00:00 by AAISP Staff
Closed Yesterday 14:17:06
Previously expected 2 Mar 10:00:00

02 Aug 2014 12:02:18
Details
02 Aug 2014 12:02:18
We are planning an expansion of our VoIP services which will require the use of more IP addresses than we have told customers to allow through their firewalls, so have added additional IP ranges to the list.

We are not using these new IP ranges yet, but are giving advanced notice of the change to give customers time to update their firewall rules.

The list is at http://wiki.aa.org.uk/VoIP_Firewall

Started 02 Aug 2014 11:50:35

09 Jul 2014 15:50:00
Details
09 Jul 2014 15:27:03
We are experiencing problem with VoIP platform, this is affecting calls for customers. We are investigating.
Update
09 Jul 2014 15:38:20
Outgoing and 'internal' calls are OK - the problem is with inbound calls not working.
Update
09 Jul 2014 15:42:38
Actually - outbound and internal calls over IPv6 were working, but over IP4 failing.
Update
09 Jul 2014 15:43:10
The problem has been found. Calls should start working again shortly.
Resolution VoIP has been a bit off for a couple of days with two unrelated incidents. Not good. It looks like in both cases many incoming calls were failing. Yesterday was an issue with the code that steers calls - we made a change done in an emergency for a customer (who was trying to abuse SIP and not have to pay for lots of licence fees on his VoIP switch). The change worked for him, but broke many other customers (not all, and not our office). The testing done before this was deployed did not pick up the issue as the test calls were the type that worked (like calls to our office). It was spotted and fixed very quickly. We're trying to work out how we can create more comprehensive tests in future - we want to be agile and responsive to customer needs, but we need any changes to be robust and not cause problems. Today was very different. We noticed an issue on one called server impacting some SIP2SIM customers, so took it out of service to investigate. We have multiple call servers, and switching the active servers is a routine task that can be done in cases just like this to ensure service continues. Switching a call server out of service is done using a function on our control pages which has been tested many times in the past. Unfortuntely it pushes out the zone files for one of the domains as part of the process as it adjusts SRV records for the call servers. This is, again, normally quite safe. What has caught us out is that somehow the zone database was broken, missing some key records, so when it was pushed out the call servers vanished on IPv4. This caused yet more confusion as all of our test calls worked as they come from IPv6 equipment. This took several minutes to pin down and fix. We're now checking archives to try and find when and how the DNS records vanished. We're still investigating why the one call server is playing up, and hope to put it back in service later this evening.
Started 09 Jul 2014 15:20:00
Closed 09 Jul 2014 15:50:00

01 Jul 2014 17:44:07
Details
01 Jul 2014 17:44:07
We have been looking again in to CDRs. We have some new logic that should show correct I/C logs for calls to your number. The exception is where that is done as part of an also ring from another number that was called. It should also show calls to another A&A number (as free) with the exception of where this is an also ring from another number. I.e. the intermediate legs are not longer showing (they were not showing properly before). We believe the charging is correct.

As a separate issue, customers billed for use of BT lines we provide (which is only a few customers that have outgoing calls) have seen a lack of call bills for a few weeks. This should catch up (hopefully today) with any previously unbilled calls being billed.

Started 01 Jul 2014 17:30:00

27 Jun 2014 10:07:44
Details
27 Jun 2014 10:08:52
It looks like we have not been recording logs of incoming calls that have been answered in the CDRs on our VoIP service. These have no call cost implications obviously. This has now been fixed and the logs should now show such calls. Sorry for any concern this may have caused.
Started 23 Jun 2014 15:00:00
Closed 27 Jun 2014 10:07:44

23 Jun 2014 10:30:09
Details
23 Jun 2014 10:29:01
We have added some quite sensitive checks to try and detect VoIP attacks, i.e. where someone has compromised your call server or obtained your SIP details and is using them.

These types of attacks can cause rather large unexpected bills. They are quite rare for us as we have a default low call rate allowed on international calls, but some customers with these rates set higher have had some attacks lately.

The new measures should not cause any problems, but we are monitoring the situation closely. If your account is locked down you will get a recorded message when trying to make calls, and an email. You can unlock the account from our control pages without the need to contact us first.

Obviously, if you do get locked down and a warning, please do check the call records to confirm this is not an attack.

We are able to adjust the thresholds we have set if we find it is too sensitive.

As these new features are only on the new call server (voiceless) we recommend people move to the new server. Once you have moved to the new server you will not be able to make calls via the old call servers so that the new security measures cannot be bypassed.

Started 23 Jun 2014 10:00:00

10 Jun 2014 20:01:12
Details
10 Jun 2014 20:01:12
For customers on the current platform (voiceless) we are now sending emails when we see a new device (user agent) or IP address make use of your VoIP number credentials. This should help mitigate and detect fraud. You can change the setting to just check user agent (e.g. if using mobile or frequenctly changing IP) or disable it (though that is not recommended).

If you have an IP lock down, the warning is sent for any new IP/device that does not meet the IP lock down subnet but with a correct password, regardless of the warning settings.

Any questions please ask.

Started 10 Jun 2014 20:00:00

06 Jun 2014 18:33:22
Details
06 Jun 2014 18:33:22
Junk callers are getting smart and calling from "real" numbers. We don't have a very big list of these yet but we have added a new option on the call control pages to allow screening against known junk callers. The suppliments the existing anonymous call reject options that we offer. The plan is that the recording of a monologue with the junk caller will be emailed to the Information Commissioners Office automatically after each call (as per section 32 of the PECR). We are enabling this basic screening on all new numbers, so do log in and disable under the ACR section of you do not want this.
Started 06 Jun 2014 18:31:04

11 Nov 2014 09:15:25
Details
23 May 2014 12:07:01

Our legacy 'A' VoIP platform will be removed from service on November 10th 2014.

This platform is our original Asterisk based system; it is now old, tired and we have a better VoIP platform: our FireBrick based 'Voiceless' platform.

We have created a wiki page with details for customers needing to move platforms: http://wiki.aa.org.uk/VoIP_-_Moving_Platform

We will be contacting customers individually by email in the coming weeks.

Our Asterisk platform has historically been used by customers using IAX or who have phones behind NAT. Our current 'Voiceless' platform should work just as well for phones behind NAT. This does mean that we will no longer be providing a IAX service. The wiki pages have details on configuring asterisk to use SIP instead.

The feature set on Voiceless is the same (if not better) than on 'A' (apart from the IAX support).

Please see the wiki page for more information: http://wiki.aa.org.uk/VoIP_-_Moving_Platform

Update
19 Aug 2014 13:42:19
We are starting to email customers about this work this week.
Update
10 Nov 2014 09:06:41
The 'A' VOIP Platform is being shut down this morning. Please contact support if you have any questions.
Started 23 May 2014 12:00:00 by AAISP Staff
Closed 11 Nov 2014 09:15:25
Previously expected 10 Nov 2014 10:00:00

17 May 2014 17:00:00
Details
17 May 2014 12:02:10
We are running in to some problems calling some mobiles. This is be being worked on.
Update
17 May 2014 15:00:27
A work around was deployed on the current call server (voiceless) shortly after posting, and has now been deployed on the old call servers as well.
Started 17 May 2014 12:00:00
Closed 17 May 2014 17:00:00

17 May 2014 12:01:25
Details
17 May 2014 11:26:59
Our old call server (due to be deprecated soon) has had some sort of issue this morning, and is being rebooted to try and clear the problem. Some customers reported they were unable to get incoming calls.
Resolution Restart completed quickly.
Closed 17 May 2014 12:01:25

11 May 2014 17:34:54
Details
06 Apr 2014 11:43:17
We are working on changes to the source IP addresses used for SIP messages we send where we have authentication details to provide. The reason is that asterisk boxes cannot easily be configured to tell "peers" from "users" in order to decide if a challenge is needed. This has caused problems for customers using VoIP unauthenticated from our IPs and SIP2SIM authenticated as a user. The first stage of the change has been done today, and involves the source IPv6 addresses. For all authenticated IPv6 messages (i.e. those for which we expect a challenge) we are sending from 2001:8b0:0:30::5060:a000/116 whilst any unauthenticated are from 2001:8b0:0:30::5060::/116 As this is within the 2001:8b0:0:30::5060::/112 block we have advised for VoIP use, this should not need any firewall changes or config changes, but we are interested in any feedback on any issues encountered. The change for IPv4 will take a bit longer - as we are unsure if to try and free up space in the 81.187.30.110-119 range previously advised, or to allocate a new range for this. This only affects calls originating from the new "voiceless" servers, which includes all SIP2SIM, but affects all authenticated messages whether SIP2SIM or otherwise. Please let us know of any issues.
Started 06 Apr 2014 11:00:00

11 May 2014 17:34:19
Details
14 Apr 2014 20:10:20
Work on the billing system has resulted in interim data and call usage bills today. These will have normal payment terms, and obviously mean lower charges on your next bill. If any customers need extra time to pay because these are interim bills, please contact accounts who can extend the terms on this occasion.
Update
14 Apr 2014 20:20:46
We have extended the terms on these interim invoices by two weeks for those otherwise due this month.
Update
15 Apr 2014 07:55:13
For the technically minded - what we were attempting to do was sort an issue where a SIM gets suspended on the date of the last bill, and so the suspend date and the billed-to date are the same but some usage has not been billed for that day. We had customer complaints about this and the fact that up to a day's worth of calls and usage were not billed. The fix was a tad overzealous. We think we have this sorted now though. I do apologise for any concern this has caused.
Started 14 Apr 2014 20:09:03
Previously expected 15 Apr 2014 00:09:03

12 Apr 2014 08:42:39
Details
11 Apr 2014 08:50:44
Customers using our VoIP services will be aware that we have reserved 10 IPv4 addresses for all of our VoIP control traffic. For our current platform "Voiceless" these are also used for the media (RTP) traffic. This makes firewalling simpler, etc. Customers using asterisk will know that the config for these can be somewhat complex, listing 10 hostnames each for IPv4 and IPv6 as the way asterisk works is to look up an IP for a hostname, pick the first, and check that against the request IP address. Asterisk really needs fixing. For voiceless we have been using two addresses 81.187.30.111 and 81.187.30.112 as well as IPv6 addresses 2001:8b0:0:30::5060::1 and 2001:8b0:0:30::5060::2. We recently tried a slight change on the IPv6 addresses, and this caused some issues. What we are planning to do now, for the "voiceless" call servers is use two addresses per server for each of IPv4 and IPv6. These shall be 81.187.30.111 and 81.187.30.113 for the A server and 81.187.30.112 and 81.187.30.114 for the B server. You do not need to know if A or B. The additional two addresses will be used as "source" addresses for any request from these servers to you that need authentication. This allows asterisk to be configured separately for authenticated and unauthenticated requests. Requests may also come from other addresses within the published block when test servers are used, etc. We are also making the corresponding change to IPv6 addresses using :1 and :3 for the A server and :2 and :4 for the B server. We may adjust which IPs are which server at a future date as we also have to consider how we expand beyond the two servers in use currently. These IPs will be accessible via DNS as a.voiceless.aa.net.uk and a.auth.voiceless.aa.net.uk, and so on. If your existing asterisk config is working as per the recommendations, no changes will be needed. The wiki will be updated to explain how you can use these changes.
Update
12 Apr 2014 08:44:38

We have made changes this morning - these are slightly different to planned so as to allow for future expansion.

A.voiceless 81.187.30.111 and 2001:8b0:0:30::5060:1

A.Auth.voiceless 81.187.30.112 and 2001:8b0:0:30::5060:2

B.voiceless 81.187.30.113 and 2001:8b0:0:30::5060:3

B.Auth.voiceless 81.187.30.114 and 2001:8b0:0:30::5060:4

I believe all of the necessary DNS changes have been made to match and allow existing configs to work.

Update
12 Apr 2014 17:56:53
We have seen some issues with calls to registered phones coming from the auth'd address and this is being looked in to now.
Update
12 Apr 2014 18:46:08
We tracked it down - and was a slight error in this mornings config. IPv4 was all coming from the auth address even if no authentication required. This would have had an impact on some calls to some devices not working properly during today.
Started 12 Apr 2014
Closed 12 Apr 2014 08:42:39
Previously expected 14 Apr 2014

10 Feb 2014 14:00:00
Details
10 Feb 2014 13:36:59
Some customers are experiencing problems making and receiving calls, this is being investigated.
Update
10 Feb 2014 14:07:47
A particular type of VoIP configuration looks to be the cause of this. We are working on a fix.
Update
10 Feb 2014 14:41:12
The affected configuration has been changed. The VoIP service should be back to normal, but we are monitoring the situation.
Closed 10 Feb 2014 14:00:00

01 Nov 2013 11:00:00
Details
01 Nov 2013 10:44:13
We're experiencing problems with the C server. Ongoing calls should continue, but registrations will break which requires phones to log in again. This also affects the A server, as A routes calls through C. We're investigating.
Update
01 Nov 2013 11:18:03
Rebooting the C server. Ongoing calls through this server will be cut off. Sorry!
Update
01 Nov 2013 11:22:44
Now looking better. We are monitoring, but please let support know if you have any problems.
Started 01 Nov 2013 10:00:00
Closed 01 Nov 2013 11:00:00

07 Feb 2014 16:10:16
Details
07 Feb 2014 16:06:27
One of our VoIP servers is having problems with calls. This is being looked in to and is affecting some customers from making and receiving calls.
Update
07 Feb 2014 16:07:10
The callserver has been restarted
Update
07 Feb 2014 16:10:38
Calls are working again now. We'll investigate the cause of this.
Started 07 Feb 2014 16:00:00
Closed 07 Feb 2014 16:10:16

14 Dec 2013 17:00:00
Details
07 Dec 2013 11:16:12
During the coming week we are making a number of minor changes to our VoIP systems. These changes include both the call servers themselves (voiceless) and the back end database call routing servers and even changes on the control pages (clueless). None of these changes should impact existing VoIP customers, they are to allow a new service which we hope to launch next year. We are currently testing on our trial systems, which involves several levels of voice servers and database call routing servers which are not part of the live platform. The next step is testing on our office VoIP platform. This puts calls to/from our offices at risk from Monday, but is an important step before deploying on live systems. When we are happy with all of the changes we will introduce in to the live VoIP platform, one server at a time, in such that we can easily fall back to the old version if there are problems.
Started 07 Dec 2013
Closed 14 Dec 2013 17:00:00
Previously expected 14 Dec 2013

04 Nov 2013 16:56:16
Details
04 Nov 2013 12:13:28
We're investigating a problem with calls on the A and C VoIP server.
Update
04 Nov 2013 12:41:04
We have identified that the fault is being caused by VoIP software crashing by an obscure call set up configuration. Another update is due shortly.
Update
04 Nov 2013 12:51:59
We've pinned this down to a the actual Number that is triggering this problem, and are in the process of changing the config.
Update
04 Nov 2013 13:24:55
The config has been changed, but we are still investigating the underlying problem.
Update
04 Nov 2013 16:56:16
Service had been stable this afternoon, we're still investigating the root cause.
Started 04 Nov 2013 12:00:00
Closed 04 Nov 2013 16:56:16

09 Oct 2013 11:51:18
Details
05 Jun 2013 14:10:38

We are looking for more testers for the new VoIP platform. Eventually we'll move everyone over but we need people to test the new platform as much as possible before we do that. We have tested with a range of phones and the various features we offer.

http://aa.net.uk/telecoms-voiceless.html


26 Sep 2013 09:50:00
Details
26 Sep 2013 09:33:01
Customers are experiencing some VoIP calls failing. Were are investigating this.
Update
26 Sep 2013 09:57:46
This was affecting some customers on our A and C VoIP servers and has now been resolved. Customers on our new V servers were unaffected. More details about our new V server can be found here: http://aa.net.uk/telecoms-voiceless.html
Started 26 Sep 2013 09:15:00
Closed 26 Sep 2013 09:50:00

14 Sep 2013 09:33:21
Details
14 Sep 2013 09:30:29
We have seen some issues in the last few minutes that may have caused calls to drop. The matter is being investigated.
Resolution We found the underlying cause, and it was affecting some outgoing calls. This has been rectified now.
Started 14 Sep 2013 09:17:00
Closed 14 Sep 2013 09:33:21

13 Aug 2013 15:14:13
Details
13 Aug 2013 14:55:16
Some calls are failing at the moment on our voip platform. We are investigating.
Update
13 Aug 2013 15:14:04
The problem has been found, and calls are working as normal now.
Closed 13 Aug 2013 15:14:13

11 Jul 2013 19:06:07
Details
25 Jun 2013 12:55:49

We're investigating a problem with one of our call servers.

Resolution

This has been fixed by fire-walling a remote attacker which our usual monitoring did not pick up and block automatically.

Started 25 Jun 2013 12:50:00

27 Jun 2013 09:59:48
Details
27 Jun 2013 09:54:00

There have been a few cases this morning with some call drops, we believe we have identified the issue. Sorry for any inconvenience.

Resolution

This looks to be sorted now.

Started 27 Jun 2013 09:00:00
Closed 27 Jun 2013 09:59:48

19 May 2013 09:37:11
Details
19 May 2013 09:40:24

A database issue this morning has affected incoming calls due to registration timeouts. This has been corrected and registrations are now working correctly.

Started 19 May 2013 08:12:10
Closed 19 May 2013 09:37:11

11 May 2013 21:31:24
Details
11 May 2013 21:30:30

We have changed centrex dialling such that calls to 101 and 111 will no longer be recognised as centrex dialling.

I.e. if you have three digit local (centrex) dialling, and extensions 111 and 101, we suggest you reassign these internal numbers.

101 and 111 now route to a carrier for non emergency police and HNS direct.

As you know, you cannot use extensions 112 or 999 for internall calling anyway (emergency services numbers).

Sorry for any inconvenience caused.

Started 11 May 2013 21:28:48

07 Mar 2013 11:13:11
Details
07 Mar 2013 11:13:11

We recently added a box on our Telephony price page where you can put in a phone number and it will look up the cost when calling via our VoIP service. See: http://aa.net.uk/telecoms-prices.html

Started 07 Mar 2013 11:00:00

20 Feb 2013 12:14:17
Details
20 Feb 2013 12:05:15

There has been an issue with the main VoIP call routing database which means we have had to restore the database from a copy taken early this morning.

Any changes to call routing, or other settings on VoIP numbers made today will need to be checked and reentered.

We apologise for any invonvenience caused.

Update
20 Feb 2013 12:08:48

While this is updating, some people may not get call recordings or voicemails emailed. The restore should be complete in a moment.

Resolution

The restore has been completed.

Started 20 Feb 2013 12:00:00
Closed 20 Feb 2013 12:14:17

05 Feb 2013 22:38:18
Details
05 Feb 2013 14:08:00

We'll be rebooting our core VoIP server this evening. It shouldn't be down long, although it'll break calls in progress when it happens.

We will try and make sure that there are no calls in progress when we do this, but if not possible we'll do it around 22:30.

Update
05 Feb 2013 22:38:49

This was completed successfully.

Started 05 Feb 2013 14:04:44 by AAISP Staff
Closed 05 Feb 2013 22:38:18

31 Jan 2013 18:21:35
Details
31 Jan 2013 18:21:35

We have reduced rates to major UK mobile networks to 5p/min (+VAT)

Started 31 Jan 2013 18:00:00

20 Nov 2012 15:10:41
Details
19 Nov 2012 22:11:16

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.

Update
19 Nov 2012 22:25:38

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

Update
19 Nov 2012 22:36:29

VoIP does appear to be stable again now.

Update
20 Nov 2012 14:31:55

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

Update
20 Nov 2012 15:10:21

This problem just returned. Back now.

We're getting closer to finding the cause.

Update
20 Nov 2012 15:10:41

Service stable again now.

Started 19 Nov 2012 22:00:00
Closed 20 Nov 2012 15:10:41

23 Nov 2012 09:00:00
Details
20 Nov 2012 14:31:12

In light of last night's problems with VoIP, we have made changes to our SIP platform to make debugging easier in future.

The changes require a full restart to go live, so we will be carrying out this restart out of hours on Thursday evening at 23:00.

This affects all of our call routing too, so will drop calls made through the 'A' server and via IAX2 as well as SIP. Phones will need to re-register.

The outage is not expected to last longer than a couple of minutes, and if anything goes wrong we will roll back the changes.

Sorry for the short notice.

Update
22 Nov 2012 23:07:00

Restart is going to be a little later than anticipated. Sorry, won't be long.

Update
22 Nov 2012 23:29:57

All done. Calls testing and working.

Sorry for any disruption.

Started 22 Nov 2012 23:00:00
Closed 23 Nov 2012 09:00:00
Previously expected 23 Nov 2012 09:00:00

17 Nov 2012 12:00:00
Details
17 Nov 2012 11:19:25

We have reports of issues with incoming and outgoing calls and are investigating now.

Update
17 Nov 2012 11:23:40

Not sure of cause yet, but services started working again after restarting processes.

Started 17 Nov 2012 09:45:45
Closed 17 Nov 2012 12:00:00

14 Sep 2012 11:00:18
Details
14 Sep 2012 10:46:44

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.

Update
14 Sep 2012 11:00:39

This has now been resolved.

Started 14 Sep 2012 10:40:00
Closed 14 Sep 2012 11:00:18
Previously expected 14 Sep 2012 10:50:00

13 Aug 2012 15:32:41
Details
13 Aug 2012 15:26:43

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

Update
13 Aug 2012 15:34:30

This has been resolved.

Started 13 Aug 2012 15:15:35
Closed 13 Aug 2012 15:32:41

06 Mar 2012 14:50:16
Details
06 Mar 2012 14:47:17

We are currently looking in to a problem with VoIP calls not being routed. This is affecting inbound and outbound calls.

Update
06 Mar 2012 14:50:30

Calls are working now

Resolution

We're not yet sure what caused this, but will continue to look through our logs etc.

Started 06 Mar 2012 14:47:16
Closed 06 Mar 2012 14:50:16

14 Feb 2012 20:42:34
Details
14 Feb 2012 19:21:44

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'.

 

Update
14 Feb 2012 20:42:34

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

Started 14 Feb 2012 19:18:18
Closed 14 Feb 2012 20:42:34

14 Feb 2012 13:05:28
Details
14 Feb 2012 12:35:43

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

Update
14 Feb 2012 13:05:34

Now fixed.

Closed 14 Feb 2012 13:05:28

17 Jan 2012 14:55:00
Details
17 Jan 2012 14:55:47

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

Update
17 Jan 2012 15:00:19

Back to normal now

Resolution

Problem resolved on carriers network

Started 17 Jan 2012 14:50:00 by AAISP Staff
Closed 17 Jan 2012 14:55:00