• Home
• News
• About FireBrick
• Products

• FireBrick FB2900
• FireBrick FB6000

• Legacy Products
• Buy FireBrick
• Contact Us
• Support
• Reseller Area
• Press Information

FireBrick FB2900

Voice over IP services

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.

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

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.

Numbering

The system works on dialled telephone numbers, just like a typical PABX. The number dialled is processed as follows:-

• If the number is one of the configured emergency numbers (default 112 and 999), no further processing is done and the call is routed to a carrier.
• If the number started with the withheld (default 141) or release (default 1470) prefix, then the prefix is removed and the number withhold setting overridden.
• If the number is one of the telephone extension numbers, or call group extension numbers, then the call is routed to that. Each number in the call group is processed in the same way.
• If the number starts with the international prefix (default 00) then it is replaced with + to make a full international number.
• If the number starts with the national prefix (default 0) then it is replaced with + and the country code to make a full international number.
• If the number does not start with national or international prefix then it is prefixed with +, the country code, and the area code to make a full international number.

When dialling a full international number, the users direct dial numbers are checked first, and if they match then it is a call to that user. Otherwise the call is sent to a carrier. The carrier may have a preferred way to present called numbers, and the international number is reformatted as configured for that carrier.

For incoming calls, the carrier may be configured to be calling one number, an extension number, which is checked against telephone users and call groups. If the carrier is not so configured, the incoming number is used, and checked against the telephone users direct dial (ddi) number too. In any case, an incoming call never maps directly to an outgoing call, i.e. a carrier cannot bounce a call off the FireBrick. To do this you can use call groups, or have your VoIP phone provide a redirect.

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 a 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 to attribute 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 your are making a withheld call the default is not to send your number, and indicate that it is withheld in the headers. However, you 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 in 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.

Pickup/steal

A prefix can be defined for telephones to pickup 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.

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.

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 in to 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 in to 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.

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 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 seconds (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 seconds (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.