aa.net.uk Broadband - Broadband you can work with

Skip to Navigation / Skip to Content

Telecoms New call server

SIP phoneWe are pleased to announce our new call server voiceless which is replacing the existing call servers. The new server is based on FireBrick VoIP and is actually a number of call servers in order to provide redundancy.

Using the new call server

To register your SIP phone on the new call server, simply set the registrar and domain to voiceless.aa.net.uk and use the same username and password as before. Voiceless is not actually a proxy so if your phone allows you to not use a proxy as such then we suggest not setting the proxy. This will register you on the new call server and force all call handling via the new server. If you change back to your previous settings this will switch you back to the old call server. Please do let support know of any issues you find.

We have help pages on our wiki which covers the features and help in configuring phones phone servers

We have more information about VoIP on our Wiki

Main changes

The FireBrick VoIP is a completely new VoIP platform, and so has a number of subtle differences when compared to the existing platform. There are, however, a few key points.

  • The new voice platform fully supports IPv6, relaying media between endpoints whether IPv6 or IPv4.
  • The new voice platform acts as an end point performing a back to back call routing function. This means that calls and media all come from and go to the new voice server only. This makes firewalling simpler.
  • The new voice platform supports NAT connected SIP devices, subject to the usual caveats on NAT and SIP working. Various tests have been done with NAT. This means we will be retiring the asterisk based old call server completely and dropping support for IAX.
  • Call log records are slightly simpler, but we have retained the logging of incoming calls and unanswered calls.
  • Recording/voicemail using FLAC has been added, and zipped WAV format removed.

Recording and voicemail

Call recordings and voicemails are sent by email, and can be one of WAV (stereo a-law), OGG, FLAC, or MP3. Voicemail is also stereo and records the outgoing message as well. The previous ZIP (zipped WAV) format is no longer supported and if selected is sent as unzipped WAV.


We have carried out a number of tests with SIP and NAT, and would welcome feedback from customers also testing. NAT is not officially supported, but generally can be made to work.

  • The technicolor broadband routers we supply with Home::1 provide a full SIP/NAT ALG which means they work such that neither the phone nor our call server know NAT is in use. This appears to be a well implemented ALG and just works.
  • Using a FireBrick FB2900 providing NAT has no ALG and does simple dynamic port forwarding of outgoing UDP connections with a default timeout of over 2 minutes. This also just works as the call server recognises the NAT and sends one minute keep-alive packets to hold the NAT session open, as well as sending symmetric RTP response packets.
  • Other cases where testing has been done have usually required one or other approach, and in some cases required "NAT assist" to be disabled on phones or routers to allow the correct operation.
  • SIP and NAT requires the call server, NAT device and phone to all play nicely and can still mean problems. There are a few specific cases we have tested and found reliable, but we cannot guarantee it will work in all cases or without some specific configuration settings.

Multiple servers

We operate multiple servers. These are configured using DNS and SRV records as well as A and AAAA records to ensure devices register and send calls via the currently active servers. We can change which servers are active from time to time.

Some devices will stick to one server after an initial DNS look up, so we may reject a registration if we are taking that server out of action, but we aim to do that after DNS has already changed. Such devices will then re-check DNS and connect to the current servers.

When taking a server out of action, we wait for all calls to complete on that server, obviously.

Multiple phones on the same number

It is possible to register multiple devices using the same number. This is not officially supported, but usually works. When each device registers we record the registration details and direct calls to the registered devices. We aim to send calls to the device from the server to which it last registered, automatically.

Do not mix some phones on the old call server and some on the new call server on the same number.

FireBrick technical features

The FireBrick has specific SIP implementation constraints designed to ensure the most reliable and best quality call connections.

  • SIP/2.0 UDP control messages using IPv4 or IPv6 are supported up to approximately 1900 bytes (fragmented if necessary).
  • The FireBrick always acts as an audio media endpoint, i.e. it is always in the media path. This minimises call routing and firewalling issues. The FireBrick uses the same IP for media and control messages on each call.
  • The FireBrick always acts as a SIP protocol endpoint and not as a relaying proxy. This minimises incompatibility between end devices being a party to a call as they do not see each others protocol messages.
  • Only RTP audio using a-law 20ms is supported. This is generally compatible with all carriers and devices and provides high quality audio.
  • Out of band DTMF is accepted using SIP INFO or RFC2833. DMTF can be sent using RFC2833 or generated a-law in-band audio.

Please bear in mind that some aspects of the service are not officially supported, so they may work or may not, and if they do not, then we may not be able to make them work for you. At the end of the day the VoIP service has no minimum term and if you are not happy you can terminate the service. Also, please remember that whilst we aim to ensure the service works all of the time, there is an agreed limit of liability if the service does not work (the amount we charged for the period it was not working).