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.

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

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

As you know we have multiple call servers, including an "old" one that is used by a few customers that still use NAT or IAX.

There is a setting to control this which staff can adjust. It defines which call server you are using for a specific number.

Up until now this has not been checked for outgoing calls. However, the "old" call server cannot do the same level of checking as the new call server (e.g. IP address lockdown), and it looks like this has left a possible loophole allowing calls made using the "old" call server for numbers that are configured for the new server.

We have updated the system to disallow this. If you are set to use the new calls servers (as all new numbers are) then you will not be able to make use of the "old" call server.

Staff are monitoring the logs to see if this happens so they can contact customers. However, if you have problems making calls today please contact support.

We are starting to set warning emails based on VoIP usage. 

On the control pages, a VoIP number has a 'bill warning' amount set. When this amount is reached we'll email the email on the number and on the login it's associated to.

The default for new numbers is £10, for number who spent more than £10 in September we've set the level to 1.2 times Septembers level.

For more information on VoIP security please see this wiki page:

http://wiki.aaisp.net.uk/index.php/VoIP_Security

This feature does not cut the service off.

As I am sure you are aware, our control pages allow you to enter location details for use in the event of an emergency call (999/112).

To date this has been an issue with some of the number blocks we have, and the details have not been updated in to the BT database to pass to emergency services in all cases. Obviously we have made this clear to you on the control pages.

However, I am pleased to say that due to a sort of phone number NAT we are now able to do this for all numbers. Any numbers we cannot update are allocated a special additional number (at no charge) which is just for use with 999/112. It is what is sent if you call 999 or 112 and starts 0200.

We hope to resolve the underlying problem with updates on all number blocks eventually, but this is a practical interim solution to ensure location data can be passed.

I urge all users of our VoIP servcies that use the service from a fixed location to update your location details on the control pages. This could save your life one day.

We are keen to test IPv6 VoIP services, but initial testing has found a slight flaw in the logic!

Our SIP server handles IPv6, but it passes RTP between enpoints to negotiate for themselves. That works fine for codecs as we say customers have to support alaw and all carriers support alaw, so unless other preferences are agreed it is alaw.

However RTP pass-through does not work well for IPv6. In theory each end is told what to send to the other. And if one end says "send me IPv6" the other should. The problem is that the other end does not understand IPv6 and so the call fails. Sadly our call carriers are not IPv6 yet, so even if we support IPv6 and our customers support IPv6, it won't work.

To solve this we are working on a new generation of call server. It will have a simple back to back media gateway to allow IPv4/6 mapping. This may be a media forwarding box, or a special case of our firewall/routers creating customer mapping sessions. We have not decided yet.

However, we just want to re-assure customers we are commited to full IPv6 support for VoIP services.

It seems the default recording format for new numbers (voicemail and call recordings) was set to MP3 by mistake. It is now WAV for all new numbers.

The MP3 option is the lowest quality option, and not the smallest size, so we would suggest anyone using MP3 consider the options and change if they wish. We have added a new options as well.

The options are:-

WAV: This is the largest file, with 8KHz 8bit alaw mono (voicemail) or stereo (recording). It is the best quality and is directly the data from the telephone network.

ZIP: You can opt for the WAV file zipped (may save 40% of file size)

OGG: OGG/Vorbis is the best trade off for quality and size that we offer

MP3: Provides compatibility with many players and is a lot smaller than WAV, but not as good quality as OGG or WAV

http://aaisp.net.uk/news-2010-11-numbers.html

November 2010: A&A acquire Instant Telecom Ltd and now have UK telephone numbering for all of UK.

Instant Telecommunications Ltd (now Andrews & Arnold (numbers) Ltd) have a complete UK roll out of local numbers. The acquisition allows Andrews & Arnold Ltd to offer Voice over IP (VoIP) numbers in all UK area codes, including a full set of 028 Northern Ireland codes.

As a result we have now launched a new number ordering page allowing customers to select individual numbers; pairs of number; or blocks of 10 or more numbers in one or more area codes. Our system allows you to pick area codes and have numbers that are similar in those area codes - ideal for local marketing campaigns.

With four million new numbers we are also able to offer a number of really nice numbers to taxi firms in many areas of the UK - contact sales for details.

A new option that can be set per number is an IP lockdown.

This is a single iP address which, if set, will not allow registration or calls originating from any other IP.

This is useful for users with a SIP phone on fixed IP and a call server on fixed IP.

Obviously this is no protection against your call server of phone being compromised and making calls, but it can help prevent calls using your credentials from other sources on the internet.

You are reminded that it is still your responsibility to secure your phone equipment and keep your passwords secret.

Sorry, this is single IP match only. I am not expanding it to a range of IPs or a list of IP ranges. We need to keep it simple and easy to manage and support.

This also only works if using the new server, not the old one, so not IAX.

It would appear we have been making a loss on some calls to specific foreign mobiles, such as Taiwan and Palau. We are reviewing this and will be making a number of rate changes at the start of this week. The changes are mainly in the area codes classified as mobiles in some countries.

Our rates table on the web site is always current for calls, so check this before calling if you have any concerns.

An immediate change we have made today is that our system will not route a call if we are making a loss. You might thing that is obvious, but it is more complex than that.

For example, we have one carrier that charges the same for the whole of a country, but another that charges one rate generally and another for specific codes within that country such as mobiles.

What was happening is that we would try routing via one carrier and it would fail so we would try the other carrier. This was done in the best interests of our customers to ensure the call gets through, obviosuly.

In most cases that is fine - the carrier of choice gives us more margin that the other one, but both make something for us. So we are still doing this for "normal" calls where either carrier makes us a margin.

However, in these odd cases with foreign mobiles we were getting cases where one carrier was blocking some numbers - possibly related to tripping abuse alarms in their systems - which meant that we were using the other carrier at a significant loss.

So the change today means that some numbers may not work rather than costing more. We are monitoring this in case it causes any problems. The fix is simply for us to set up the higher rate for the more expensive numbers which we are doing during the week.

I hope that makes sense...

We've changed the rate for 0845 calls.

Calls to 0845 numbers now have a 3p connection charge.

This month's telephone bills included (for most people) two separate sets of itemised bills for each numbers. One is the old call server and one is the new call server.

No calls are duplicated so the total amount is right, but the two sections have different layout.

In some cases the time periods overlap as some people had incoming calls on one server and outgoing on another.

We have moved all call routing and logging to the new call server now, so next bills should be tidier.

We have also made a few tweaks today to the way the itemised bills are presented for the new call server. This change is in the PDF layout so you can re-load the PDF from the accounts system to see the newer format for the existing bill if you wish.

The main changes are for number formatting - replacing +44xxxx and 44xxxx UK numbers with the more conventional national number format. We have also added spaces to area codes to make the numbers more readable. In the case of calls which are forwarded on to another number, this is now showing where the call was forwarded on to as well, so as to make the bill cleaer.

We aim to make the bills clearer over time.

We are seeing an increasing number of cases where customer equipment is used to make VoIP calls. This is typically where users have opened their VoIP system to the internet and had silly password (e.g. user name and password of 101).

Please be careful with passwords and firewalls. Support can help with firewalling rules, but the main problem seems to be silly passwords.

Well, junk callers are calling honey pot numbers... I'll post any good ones we get.

Next step is making four million new numbers live and trapping junk callers to them too. If we can tie up enough of their operatives time we reduce the number of innocent victims of their criminal activity.

Public notice: If you call an A&A unallocated number your call may be recorded and posted on the internet for comedy purposes... As well as used as evidence in criminal and civil action against you if you are one of these junk callers.

Some recordings on www.me.uk

New feature (on new call sever).

ACR (anonymous call reject) normally provides a polite message, non-charged, and hangs up.

A new "nasty" ACR option now handles withheld and unavailable callers, answers the call, tells them they are a coward for not releasing their number and repeats until they hang up. It also sends a tone/DTMF digit 2 to tie up an operator for the typical junk caller.

You also have a new *113 code to record a customised ACR message (for standard and nasty mode). Note, no prompt on this - just a beep. Test by calling 141 and your own number.

Bear in mind people can genuining call wrong numbers and international callers are often calling as unavailable (hits the "nasty" mode). Young kids can hit keys on phones too, so do not be too rude.

We're interested to hear comments from customers.

Junk callers are becoming a real problem - we are getting an average of one every 90 seconds to our office DDI block alone now.

Extra option called "Honey" is a honny trap message which goes on and on and on... Lets try and trap the criminals...

In case you missed it - the honey pot got front page on the register yesterday and top story on slashdot today...

Customers with blocks of numbers have had some slightly incorrect billing this month. We are working through these correcting them now. This means some credit notes and new invoices.

The issues are:-

(a) Calls before late June had not been billed

(b) Calls for 1st July have been billed on today (2nd) and the system would be billing every day as it happens at present, so this is being fixed.

OK, the correction means you will get a credit note for the £1/month charges for the blocks of numbers, and the call charges billed on 1st, and the call charges billed on 2nd. You then get a new invoice withe the £1/month line charges and call charges up to and including the 1st.

This will happen during the day as we have to go through and check and credit and re-bill each affected account manually.

Sorry for the confusion.

I am pleased to say that most of the customers with blocks of 10 and 100 are using them for incoming calls only and so very few accounts have had to be adjusted.

We are changing the billing for calls to make use of the new call server.

Most customers will be on old or new call server, but in some cases you may have some calls that are on one server and some calls on the other.

The two call servers generate billing data separately and so both sets are separately itemised on the bill during the transition from old to new. No calls should be billed twice, obviously.

The new bill format has new XML and new PDF (printable) format which we are working on now ready for the end of month billing.

The billing also changes the way we charge for blocks of numbers. We charge the per number now, but will allow numbers to be reserved rather than live at a lower price. Only customers with blocks of numbers will see any difference. Contact us if you are in that situation and need to change some numbers to reserved status.

Any queries, let us know.

A slight unexpected side effect for those customers on 4 weekly billing (billed today) is that instead of being billed for 4 weeks at 27p/week totalling £1.08, you have been billed 0.92 months at £1.18/month totalling £1.09. This will go back to the per week pricing from next bill.

A further part of the change is that numbers are shown on the main bill as international format, i.e. starting +44. We may change this to a prettier format in due course.

A further aspect of the new call server is that calls are timed to 0.01 second precision, and charges worked out per call to 0.0001 pence precision (rounded to nearest whole penny for total charge for the number).

Voice over IP working via Network Address Translation systems is tricky at the best of times. And it sort of works on the old call server. This is a combination of the VoIP handset, the gateway/router doing NAT, the call server, possibly a STUN server, the specific configuration and a lot of luck.

We moved several lines over to the new call server last week, thinking they were not-NAT (based on information from asterisk). We expected no real problems. However, it seems some were using NAT. Some have just worked on the new call server, which is good. Some have not, and we have moved them back to the old call server.

Over the coming weeks we will be investigating each number on the old call server. It may be that it can just move. It may need slight firewall adjustments. It may need more investigation. The plan is to find exactly what we have to do in each case to get things working.

The long term plan is to no longer need the old call server at all. NAT is a big issue to tackle. We also have to address IAX for a few customers as well, but this will be tackled later.

Support staff will be in touch if you are still on the old call server. This process may take some time. Anyone wanting to try the new call server sooner - contact support.

We will be adding new features to the new call server over time.

We will be adding new features to the new call server.

These will only apply to calls going via the new call server, and we plan to move everyone over eventually.

First of these is a bit of fun - syslog caller display - you can set a syslog host to get syslog messages for all incoming calls to the number.

This works for group rings and so on - all numbers on the new server, even if you are busy or DND, etc. It advises your number, the caller number, and caller name if known.

Simple, but useful. The web site www.boris.org.uk has a windows syslog popup app if you want to have incoming calls pop up on windows.

The new call server has had a few issues with call transfer - typically some calls were getting one-way audio or just dropping.

We are pretty sure we have this sorted now.

We have tested every combination of :-

1. Calls coming direct to new call server from one carrier

2. Calls coming direct to new call server from the other carrier

3. Calls coming to new call server via the old call server

And we have tested with :-

1. Transfer before answering

2. Answer and blind transfer (un announced)

3. Answer, hold, transfer before final party answers

4. Answer, hold, call 3rd party, answer, talk, and then transfer

All 12 combinations work and have 2 way audio correctly.

Sorry for the inconvenience. This proved to be a lot trickier than expected.

Calls to 01/02/03 numbers at weekends are now 1p/min including VAT.

This means that calling from A&A mobiles to 01/02/03 numbers at the weekend is now below 4p/min including VAT.

We have switched over many SIP registered users on the old call server to the new call server this evening.

Any problems and you can be switched back while we resolve them - but all should work with no problems.

Please be aware of firewalling rules.

SIP (UDP) from us can come from any 81.187.30.110 to 119 and typically to you on port 5060. May be from any port our end.

RTP UDP can come from anywhere.

We suggest allowing all UDP to SIP devices.

You can now request call recordings are encrypted. Ask support if you need help. You need to enter your PGP key ID on the control pages and have the key matching that ID and your email address on public key servers.

The recording is encrypted and emailed immediately at the end of the call and not kept on our call servers. Only you can then decrypt the recording and associated information.

Have fun.

We are pleased to say that testing on the new call server is going well - the key functionality is now in place and we have switched mobile originated calls to go via it now.

This means the SIP2SIM feature is fully working allowing a mobile to act as a direct SIP extension off your own or a thrid party call server.

Thanks to all those that are helping with the testing.

We are working on a new call router. It will be SIP only with all of the current call routing and control features and more. There will be a number of subtle changes that improve the existing features and we will be documenting it better as well.

Changing to SIP only is big step, and we will be contacting IAX connected customers and discussing options. We are not ruling out keeping a legacy box for IAX but we'll see how it goes. We are changing the way blocks of numbers are sold as well which will make reserving blocks cheaper. We will also be making the billing a lot clearer.

The changes are tied in with the new mobile servcies as well and these need new features the existing call server cannot provide. The new server will also address some slight reliability concerns allowing us to run multiple servers in fall-back and load-balancing modes.

The new box will undergo a lot of testing along side the existing systems, and we will be looking for people using SIP as clients and servers for calls to/from us for us to test the new system against.

More details will follow as we progress with the development.

We are still working on the few key points necessary to get mobiles in to beta testing - sorry it is taking so long. Only a few days now I am told.

It looks like full data services will take a bit longer but it also looks like the carrier has agreed that L2TP is sensible so we should eventually have full control over IPs and IPv6 and so on. One of the key features I have insisted on for beta testing is some sort of internet access on the voice SIMs, so data will work.

In the mean time we are working on moving VoIP services to a new platform that will allow much more capacity and reliability. This is something we are going to start with on the mobiles and gradulally work through in to the mainstream VoIP services over the coming weeks or months. A few customers may have to change configuration but we'll talk this through individually at the time.

We are also working on a much better ordering system that will allow easier choice of numbers as well as reserving numbers. The plan is to change the commercial arrangements on blocks of numbers as well, but we expect that this will reduce prices for those few customers that have blocks now and allow much more flexibility for people wanting to reserve blocks.

We also plan to provide much better documentation of the existing and new VoIP and mobile features.

We are taking this very carefully, one step at a time with lots of testing. The plan is no changes needed at all for most customers, just extra features and better reliability.

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

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.

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

The restore has been completed.

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.

This was completed successfully.

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.

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

All done. Calls testing and working.

Sorry for any disruption.

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 have reports of issues with incoming and outgoing calls and are investigating now.

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

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.

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

Calls are working now

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

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

There is a major issue with one of our carriers affecting some incoming calls and text messaging. They are working on the issue now.

Engineers are on site now.

OK switch in place but some things still to be finished.

Looks like things are working now.

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.

One of our telephony carriers had a network problem this afternoon which affected some VoIP calls and mobile SIM services.

The problem has been resolved (sorry for the delay in us posting this), and their initial investigation looks to be some kind of DDOS attack.

We have a list of minor niggles that has built up and we are planning to work on these this weekend. Most of the work will, of course, be on out test platform, but as we complete each stage we will be loading on the live VoIP system for final customer testing and confirmation.

This should not cause any problems, obviously. But there is a risk of issues arrising.

In general, the way the new VoIP system works, if there are problems then calls in progress continue but don't get charged.

Part of this work is testing IPv6 VoIP phones.

Work has been done today on the test and backup server. We plan to apply these changes to the live server this evening.

The main changes have been down to slight quirks in the operation. e.g. voicemail not working unless call recoridng email also set; calls from some types of gigaset not gving right ring tone; Quirks when two simultaneous voicemails apply on one call; and such things.

Tomorrows work is going to be related to IPv6 interworking.

OK minor change to the syslog caller display format.

We were unabkle to complete the IPv6. We will be testing some IPv6 work on the test server during the week.

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.