The FireBrick operates according to well established technical standards within specific design constraints
which allow it to operate efficiently handling thousands of calls.
- 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 -law in-band audio.
- Error responses to REGISTER/INVITE from non local devices are not normally sent - this is against
the SIP protocols but avoids issues with port scanning systems looking for VoIP platforms.
This can make diagnosis of incorrect settings harder.
The design is intended to work with all common VoIP handsets and carriers. If you experience any difficulty
with a carrier or a VoIP device, please contact the FireBrick support team, ideally with a full debug log.
Tip
It is possible to set different source IP addresses to be used per carrier - obviously, to work, these have to
be IP addresses that the FireBrick has, but it can be useful to force registration via specific addresses.
It is also possible to define a default IPv4 and IPv6 source address to be used for messages that can be
authenticated, thus allowing different source addresses to be used for messages to which a challenge must
be sent and those that do not expect a challenge. This can be useful when dealing with remote boxes that
have to decide on a challenge based on source address.
