What are SIP Trunk PBX?
The SIP Trunk PBX module allows a user to connect telephone lines from Omnivigil to a third-party PBX Systems such as Asterisk PBX, Grandstream, Avaya Office IP and others. The SIP Trunking service uses SIP (RFC3261) to deliver basic telephone services to a customer premise equipment. It provides only the most basic services to the PBX such as the phone lines themselves, basic 9-1-1 service and call recordings (additional fees may apply). SIP Trunk PBX provides an advantage over copper pairs as it handles media and signaling separately. Customers looking to add lines to a customer premise PBX should use this service.
What is SIP Trunk PBX? Who should use it? Why would I want to use it?
The SIP PBX service is at its most basic telephone lines delivered using SIP/RTP to customer premise equipment. This module exists to handle cases where the customer may already have a PBX system and is unwilling or unable to move to a new system. The integration typically requires SIP Trunking support on the PBX itself, although it is possible to connect ATAs (such as the Cisco SPA122) to the module to deliver the lines as copper pairs.
Service and billing concerns
When the SIP PBX service is activated, the module ‘SIP PBX’ will appear in the customer’s account. Telephone numbers assigned to the account must be set with the usage ‘PBX’. Numbers being migrated from faxing or hosted voice services must be deprogrammed (in customer’s account) and reconfigured for PBX use (by service) before they are available for use in a SIP PBX.
Configuration of the SIPTrunkPBX service
Configuration of the service is easy and can be achieved by opening the module in the configuration portal. The module appears in the left-hand menu and can be configured in minimum number of clicks. In order to interact with the SIP PBX module, you will need the permission Telephony Level 3. The configuration is very easy:
- Open SIP PBX Module
- Click ‘New’
- Select the phone number to be configured
- Select the appropriate 911 address
- If there are no more numbers, hit ‘save’
- If there are more numbers, hit ‘save and add another’ and repeat from step 3.
Note: It is recommended to have one SIP PBX node per e.164 number configured, however in order to accommodate less flexible equipment, it *is* possible to configure multiple dids on a single registration.
This will create one entry for each phone number. It is needed to have one node for each phone number if you wish to be able to distinguish inbound calls based on the dialed number. The module allows for multiple phone numbers on the same node, however if you do this, all inbound calls will always be routed to the first number that is selected on the node.
Consider the following node:
DIDs : +14185551234, +14185554321 and +15145551234
911 Address : 123 Fake Street. X0X 0X0
In this scenario, if any of the three numbers are dialed, the PBX will always be told that the first number was dialed (418-555-1234). For customers who have multiple phone numbers that all have the same action, this configuration is acceptable. However, if we consider the case where a customer may want to route calls differently based on the dialed number, this configuration will not work.
Configuration information for PBX equipment
Once the SIP PBX nodes have been created, you will need the credentials to setup your equipment. The basic fields needed are username, password, domain and outbound proxy. The username will always be the first number on the PBX node, so if you change the first number on the PBX node, you will need to reconfigure the SIP PBX itself. The password is randomly generated and can be found along with the username. Typically, the domain will be a sub-domain of sip.omnity.net. The outbound proxy is an extremely important field and tells the PBX where the Omnivigil Edge Proxy can be located.
To see the information, you can consult the ‘SIP Trunk’ action which is in the menu on each PBX node.
Here is a sample :
- Generic SIP Trunk Information :
- SIP User Name
- SIP Auth Id
- SIP Password
- Proxy / SIP Server
- DTMF Transmission Method
In this case, the entry sipproxy.omnity.net is the outbound proxy
The configuration of the PBX will vary from one system to the other, but the basics always stay the same. Username, password, domain and outbound proxy.
For each SIP PBX node created, it is expected that the customer equipment sends a REGISTER to the designated outbound proxy in order to establish the call path to the PBX. Each register is tied to a single identity (i e.164 number).
The SIP PBX module uses SIP REGISTER to identify the location of the customer PBX equipment. The SIP registrations can easily traverse sane NAT routers with minimal configuration. This makes it simple to configure as port forwarding are not always possible on customer equipment. Each SIP PBX node will require a corresponding SIP registration.
Configuring foss Asterisk
Customers using the popular Free and Open-Source Asterisk(tm) can select the ‘Asterisk’ option from the SIP PBX menu and it will provide the same configuration parameters as ‘SIP Trunk’ action, except that they will be preformatted to be readable by Asterisk.
Debugging of PBX equipment & Sample SIP INVITE
Modern PBXs provide means to inspect and debug any inter-connect issues (asterisk users should be familiar with ‘sip set debug on’). When debugging, you must ensure that the From/Auth Domain are listed as the domain from the configuration provided by Omnitotal. The domain in the Request-URI must contain the service domain as well. The To domain *should* contain the service domain as well. When debugging connectivity issues, remember that the password is sent as a digest challenge and cannot be retrieved from the SIP itself. If you see a 401 answer to a SIP REGISTER containing the correct Authorization header, there may be an issue with the username, password or the service domain.
Cisco ATAs SPA122
It is possible to use analog telephone adapters (ATAs) to connect to much older PBXs that do not support modern protocols like SIP. This option requires understanding of electrical signaling and will require specialized hardware to extract the caller id information from the call itself. Use of ATAs will create extra delay on inbound calls before they ring as the caller Id information is typically sent between the first and second ring cycle. This means that if using an ATA, the PBX will need to absorb 2 ring cycles before routing the call to any menu or user in order to extract the caller id information.
When connecting any equipment to telephone lines, the installer has a responsibility to ensure that the customer equipment is fully secure. This means that the installer must insure that *nobody* can gain access to the connected telephone lines without proper authorization. Customer equipment must be protected against weak passwords, easy to guess passwords, poorly implemented dialing plans, etc… Insecure PBXs are the #1 cause of fraudulent calls in the Omnitotal network. If a PBX is found to be making fraudulent calls, the customer will be responsible for paying for these calls. There are automated systems in place that will automatically suspend calls for suspected fraudulent activity, however there is no guarantee these will catch all fraud, and even if they do, the customer will be responsible for any fees incurred. If you are unsure how to configure a secure PBX that is resistant to script kiddies and hackers, it would be unadvisable to use this service.
Do you have any questions, or would you like to learn more?