The FireBrick includes a Voice over IP (VoIP) gateway feature based on the standard SIP protocol. This is the protocol normally used by commercial VoIP providers and VoIP phones.
Typical usage is an FB2900 in a small office or home acting as a local SIP gateway and using VoIP phones within the home/office to make and received calls. The FireBrick connects to a commercial VoIP provider on the Internet and relays the calls.
In essence, the FireBrick is acting as a simple PABX (telephone switch) for the home/office. Advanced features like voicemail would be provided by the commercial VoIP provider.
The larger *FireBrick 6000 series also provide a large scale SIP switch which can be used by a commercial VoIP provider, but is not described here.
*The FB6000 series is due to be replaced in Q1 or Q2 of 2021, by the FB9000 series. A few improvements include a more powerful CPU, more RAM & Ten SFP ports (Two at 10Gbit/s & eight at 1Gbit/s). Please contact us or periodically check our News page for updates on features & availability of the new FB9000 series.
Basic concept
The FireBrick acts as a back to back gateway for SIP calls. It means calls are made to and from the FireBrick, and the FireBrick is responsible for joining the calls together. Neither end knows of the final connection. This means the FireBrick can translate between IPv4 and IPv6, between local IP addresses and public IP addresses, and even handle DTMF (tone dialling) issues.
If you are using private addresses and NAT (Network Address Translation) you should use PPPoE for the link to your ISP so as to ensure the FireBrick has a public IP address. This then removes the usual issues of NAT and SIP.
Typically stand-alone VoIP phones on desks are registered on the FireBrick and given (short) extension numbers. You can then call between phones using these extension numbers, and transfer calls, etc.
If you call an outside number then the call is routed to a call carrier over the Internet. Similarly, incoming calls coming from the Internet can be routed to one or more extension numbers.
Carriers and users
Configuring carriers
A carrier is a commercial VoIP provider connecting you to the public telephone network. Outgoing calls can be made via a carrier and incoming calls can be received from a carrier.
You may need one or more carrier definitions, and may need a separate carrier definition for each number you have, depending on the how the carrier works. The FireBrick operates using SIP/2.0/UDP with PCMA/8000 audio and is compatible with most commercial VoIP carriers.
Outgoing registration
One of the simplest carrier configurations is where the FireBrick acts like a SIP phone, registering with the carrier.
You define the registrar which is the hostname or IP address of the carriers registration service. You will usually need to define username and password as well, and you may have to set a from address for the registration, depending on the carrier.
The expires time defines the preferred re-registration time. The FireBrick will register at start-up and periodically as needed.
For inbound calls, the carrier connects to the registered contact which the FireBrick provided. You will need to define extn as the internal extension number that is being called when a call comes from this carrier. This can, of course, be a ring group.
Authenticated inbound calls
Some carriers will not require or accept registration from the FireBrick but will expect to send calls to the FireBrick on a pre-defined IP address or host name that reaches the FireBrick.
To allow such calls you set the toattribute which can be the complete To header value expected or can simply be @hostname which is expected.
In the latter case, the incoming-format can be used to define numbering that is presented before the ‘@’ or set extn to send all incoming calls to a specific extension.
In some cases, a carrier may be able to send authenticated calls, in which case define username and password which are checked when the calls come in.
If not authenticating calls, or even if you are, you may want to define allow to cover the IP addresses from which the call is permitted to arrive.
Direct inbound calls
You may want to publish a SIP URL to allow calls to you directly from anywhere on the Internet. This can be set up as above configuring a defined to address, and extn to which calls are sent. We recommend setting trust-cli to false in such cases as the call could claim to be from any number.
Outbound calls
When using a carrier for outbound calls, you can configure the proxy to use. If the username and password are defined then these will be used to authenticate outgoing calls.
You can define the outgoing-format to use for numbering of external calls to the carrier. Each telephone user can be set to use a preferred carrier else one will be picked.
Carriers work in different ways for handling withheld numbers. If you are making a withheld call the default is not to send your number, and indicate that it is withheld in the headers.
However, your carrier may know the number and send it anyway.
If your carrier has a prefix to indicate withheld calls you can define withheld. E.g. in the UK, some carriers use 141 as a prefix for this. In this case, the number is sent in the headers but the prefix is used to tell the carrier it is withheld.
We recommend you test withheld number calling with each new carrier you set up to ensure it works as you expect.
Configuring telephone users
Telephone users are internal extensions. They are typically locally connected SIP phones. They could be remote SIP phones. The SIP phone registers with the FireBrick. Do not use telephone definitions for calls from a carrier.
To define a user, set a name which is the part before the ‘@’ in the registration or From header for calls. You can also define username and password to force authentication on calls and registrations from the phone.
You should define an extn which is the internal number for calls to and from the phone, and you may like to define a ddi which is the external public number to be used. See numbering section above.
By default SIP users must be on a local subnet, but for external users, you can define local-only false. We recommend setting the allow IP range if you can to restrict login attempts to certain source IP addresses.
Allowing a remote user from the Internet can be dangerous, and you should always ensure a good password is used.
Even with a good password, it is likely your FireBrick will come under attack if it allows registration attempts from anywhere on the Internet, so we strongly recommend using the allow restrictions if possible.
If the IP address of a phone is likely to change a lot, you may want to set a shorter expires time, but normally this does not need to be changed.
Feature overview
Pickup/steal
A prefix can be defined for telephones to pick up or steal a call, default is *.
- Using pickup with the extn of a ring group will take (pickup) the call ringing at the head of the queue.
- Using pickup with the extn of a telephone that has a call ringing will take (pickup) that call.
- Using pickup with the extn of a telephone that has a call in progress will steal that call.
To ensure this is not abused a telephone or ring group can have a list of extensions which are allowed to pick up. If not set then any extensions are allowed.
Busy Lamp
Some phones, e.g. SNOM, have busy lamp functions. Simply set BLF mode and the extension number to monitor. You can monitor a group extension number or a telephone extensions number.
You can also monitor using the pickup prefix – this is useful as the button will usually dial the number you are monitoring, so this is ideal if monitoring a ring group as pressing the button picks up the ringing call.
Call groups
A call group allows one number to call multiple numbers, either all together or in a sequence and allows queuing of calls. The simplest group is to ring a set of numbers all at once until one answers.
What numbers are rung
The initial set of numbers to call is defined in the ring attribute, but if a profile is defined and inactive then the out-of-hours attribute is used instead. If this initial set is empty then the group fails as busy.
After a defined period of time at the head of the queue, the list of numbers is extended to include the overflow attribute as well.
Ring pattern
There are a number of options for how the numbers are rung. Each number is only tried once, but in the case of an internal number, it is not tried if the telephone is known to have other calls or within its wrap-up time – but this only applies where the number is exactly the extn of a telephone. This means that if someone is on the phone, and then hangs up, they can then get a call from the ring group even if it is already ringing other phones.
All Ringing all numbers at once is the simplest to understand. This can create a two-stage ringing process with the overflow being added after a defined delay. In this case, the order attribute does not matter.
Sequence This means trying one phone at a time. After a configured progress-time the call is cancelled and the next phone tried, in order. Once all the phones in the initial set have been tried then the overflow set is tried even if not yet time.
Cascade This is the same as above except the existing calls are not cancelled as the cycle progressed, causing more and more phones to ring.
Ring order
Except when ringing all phones at once, the order the phones are rung can be important, and there are a number of options. The ordering only works for the first 64 numbers, once they are all tried the rest are rung together.
StrictThis is the simplest as it means the phones are tried in the order they are defined in the config, with overflow added to the end.CycleThis is the same as strict, but for each call, the sequence continues from where it left off in the previous call. The order the phones are tried is random.
The order the phones are tried is based on which phone has not had a call for the longest time. This only works where the number matches the extn of a telephone. Any that do not (e.g. external calls) are tried last.
Queued calls
Ring groups allow queuing. This means more calls can be waiting. As soon as a second call is queued the ring type of the first call changes to all so that it is answered more quickly and the second call can get to the front of the queue.
You can limit how many calls are allowed in the queue.
The caller does not know they are in a queue, and if they are left ringing too long they may hang up, or their phone carrier may time out the call. To avoid this, if not answered after answer-time the call is answered anyway and a queue tone (different ringing tone by default) played.
Tones
There are a number of standard tones built into the FireBrick – these are used wherever possible to ensure consistent tones heard rather than tones generated by local devices. Without this, you will find different VoIP handsets generate different tones, especially ring tone which you hear while calling someone.
All of the tones can be re-configured to your requirements, but it is recommended you use the standard tones.
Note that where the far end provides tones, these are used, so calling some numbers, and international numbers will have the original tones.
It is also possible to arrange for numbers dialled to go to a specific tone, and for tones to be injected into a call in some cases.
Many tones are not normally played, as the call ends with an error code (e.g. Busy). However, there is an option to ensure tones are played for several seconds before clearing the call. This is useful where a specific handset generates silly tones for some errors.
| progress | Whilst waiting for a called number to start ringing | Silence |
| ring | Whilst waiting for a called number to answer | 1000ms 400ms@400Hz-3dB+450Hz-3dB 200ms 400ms@400Hz-3dB+450Hz-3dB 1000ms |
| hold | Whilst on hold | TBA |
| busy | Called number is busy | 375ms@400Hz 375ms |
| unobtainable | Called number is not valid | 400Hz |
| error | Any other call error | 400ms@400Hz-6dB 350ms 225ms@400Hz 525ms |
Syntax of tone plans
The tone plan is either a single tone definition (i.e. continuous tone) or a series of duration and tone definitions for a sequence separated by spaces.
The duration is digits followed by ms, e.g. 1000ms. It can be used on its own as duration of silence, or immediately followed by an @ and a tone definition.
The tone definition is a frequency/level definition which may be immediately followed by + and a second frequency/level definition where two tones are required at once.
At the end of the tone definition can be ^ meaning that the tone is to be amplitude shaped at the start and end of the tone to sound nicer.
The frequency/level definition is digits followed by Hz and may be immediately followed by – digits and dB, e.g. 500Hz or 400Hz-3dB.
As an example 1000ms 400ms@400Hz-3dB+450Hz-3dB 200ms 400ms@400Hz-3dB+450Hz-3dB 1000ms means the 3 second cycle of:-
- 1 second (1000ms) of silence
- 400ms of a mixture of 400Hz at -3dB and 450Hz at -3dB
- 200ms of silence
- 400ms of a mixture of 400Hz at -3dB and 450Hz at -3dB
- 1 second (1000ms) of silence
There are limits on the tone plan string length and the duration of the tone itself.
Technical
The FireBrick operates on a subset of the SIP 2.0 specification, handling the features usually required. Only UDP SIP control messages are supported. Only 8KHz alaw audio is supported, though out of band DTMF using telephone-events is supported and translated to audio where required. The development team welcome feedback of any examples where support for additional features is required.
If a US variations of the FireBrick is required, please contact sales – we can make a US variant that operates on ulaw not alaw but it is a separate code variant.