In a typical sipXecs deployment, sipXecs is connected to the enterprise LAN. The enterprise LAN usually has a firewall and/or Network Address Translator (NAT) that translates global public addresses to private (non-routable) addresses. To be able to communicate between the PBX and the public network, we need an application level gateway or bridge. The sipXbridge internal SBC provides this application level gateway functionality.

The sipXbridge application is fully integrated into sipXecs and managed through sipXconfig. This makes it very simple for the admin to configure one or several accounts with Internet Telephony Service Providers (ITSPs) for the purpose of SIP trunking. The sipXbridge service can be installed on the same physical server as all the other sipXecs components, or it can be deployed on separate hardware. The choice is based on the need for scalability. In such a distributed setup several sipXbridge components can be added to sipXecs, each on its own physical server.

The sipXbridge service is a Back To Back User Agent (B2BUA) that enables NAT traversal and connectivity to an Internet Telephony Service Provider (ITSP). It anchors media and provides rewriting of the SIP / SDP headers so that packets can pass through the firewall / NAT and be routed from an ITSP to the sipXecs server via a NAT and vice versa.

Interoperable Internet Telephony Service Providers (ITSPs)

Following are the minimal requirements for interoperability :

Functional Description

The sipXbridge service is designed to be as flexible as possible when it comes to accommodating differences between ITSPs. It turns out that ITSPs still have significant variability in how things work and also adherence to the SIP standard varies. The capabilities offered by sipXbridge are designed to maximize flexibility. The following lists some of the currently available features:

ITSP Registrations: Registers with ITSPs and keeps Registrations fresh. Dialog based authentication trunks.

Message size reduction and topology hiding: sipxBridge reduces message size by stripping any state that is not relevant to the ITSP (but may be relevant to sipXcom). These include route headers and other headers that are specific to sipXcom.

Near end NAT traversal requirements: Can operate behind a NAT. However, sipXbridge requires that there is no NAT between itself and the sipXcom proxy. Supports both dynamic and static NATs. sipXbridge re-writes SIP/SDP headers in the call setup signaling as needed by the ITSP. Keeps NAT bindings alive using periodic outbound signaling if needed (for example use empty packets for RTP keepalive and CR-LF sequences for SIP keepalive). Does not, in general, assume that the ITSP provides hosted NAT compensation.

Is configurable with sipXconfig: All aspects of SIP trunking are plug & play configurable

Has good media performance: sipXbridge anchors media and is implemented as an efficient media relay service. A single sipXrelay instance can comfortably handle 250 concurrent calls within acceptable limits of jitter and delay without becoming a bottleneck.

Media (codec) agnostic.

Supports concurrent multi-ITSP configurations: A single sipXbridge instance can support multiple ITSP accounts with multiple DIDs per ITSP and can concurrently process the call setup signaling and media needed by these accounts.

Handles NAT/ITSP reboots: If the NAT reboots and comes back to life, sipXbridge will re-REGISTER with the ITSP. It relies upon session inactivity timers to clean up media resources that are allocated for the call in case of session inactivity and it uses periodic STUN global address re-discovery if configured to do so.

Works with commonly used phones and ITSPs: Exports all the necessary configuration options to allow such deployments and assumes no NAT traversal capabilities in the phone.

Supports call transfers locally: Call transfers are supported without sending the REFER to the ITSP. Therefore, it can handle both blind and consultative transfers and it is possible to transfer in or outbound calls via an ITSP back out to the ITSP (hair-pinned transfers).

Can be configured to play music on hold during the transfer.

Provides logging support: sipXbridge provides logging of messages and signaling in the syslog format expected by the sipXcom trace viewing (sipXviewer) tool.

Interoperates with the other sipXcom services (for example the conferencing service).

Integrated with sipXcom alarms: Provides administrator notification using the alarm facility of sipXcom.

How to configure sipXbridge

Make sure that SIP Trunking is enabled for the server

Click on System > Servers, then select 'Telephony Services' from the left side menu. 

Configure SIP Trunk

Navigate to Devices > Gateways. To get to this screen :

 

Select "SIP trunk" from the 'Add new gateway...' drop down menu.

 

Click on 'Apply' and additional menu items will appear on the left as shown in the next screen shot.

The public port in this page is the port that is exposed to the public network through your firewall setting. If your firewall restricts inbound traffic, you must open this port on your firewall to allow inbound signaling from the ITSP. The external port in the screen above is the port that is a port on the machine that sipxbridge runs on. It "faces" the firewall. It is associated with the public port on the firewall. Hence the firewall must be configured to send packets from the the public port to the external port. If you leave the public port blank, the external port is assumed to be the same as the public port (i.e. the mapping is assumed to be symmetric). If your firewall filtering rules allow inbound traffic from those destinations to which outbound traffic has previously been sent and if your ITSP provides "hosted NAT compensation", you do not need to reconfigure any firewall rules.

SipXbridge runs on port 5080 (not 5060). You can change port on which it receives signaling. However, if you change the sipXbridge port, be careful of causing port conflicts with other sipXcom components that are co-located on the same platform that bind to the same IP address. The port where sipXbridge expects to receive signaling has nothing to do with where the ITSP expects to receive its signaling. The ITSP can continue to receive its signaling at port 5060.

If your ITSP does IP address provisioning (i.e. ITSP registers your public address and signals that public address), they will probably default to signal sipXbridge on port 5060. If you do a straight through mapping on your firewall (i.e. external port maps to identical internal port) and open up port 5060, the signaling from the ITSP would bypass SipXbridge and go directly to the sipXcom Proxy server and hence SipXbridge would not work. Please contact your ITSP and provision their system to signal port 5080 on your public address and open up port 5080 on your firewall (recommended) or use appropriate firewall rules to map external port 5060 to port 5080. If you chose to do the latter (not recommended - especially if you are also configuring remote workers), you would need to specify what port on the firewall you have mapped in the screen above. This note does not apply to ITSPs that function by Registration.

Dialog Based Authentication SIP Trunk

If the ITSP supports Dialog Based authentication (login with user / password) the inbound SIP port is negotiated. Keepalives should keep ports open in the firewall. This is by far the easiest to configure method of SIP Trunking. To setup your username and passsword, on the Gateway click on ITSP Account on the left side menu and you'll be able to add your username and SIP password as provided by the ITSP.

Click OK when completed.

ITSP Notes

Typically ITSPs do not handle certain types of SIP requests such as REFER which is used in Call Transfer operations. To implement call transfer, SipXbridge does signaling translation, converting a REFER request to an INVITE request to the call transfer target. Consequently, a ringing tone will not be heard at the calling phone during call transfers when the call is routed through SipXbridge.

Enable Music On Hold (MOH)on this page if you would like to hear music for blind transfers. If you do not do this, you will hear silence during the time a call is being transferred blind.

You are recommended to turn MOH off for your phone when MOH is turned ON on sipXbridge as certain signaling race conditions may occur, resulting in garbled MOH.

Most ITSPs only need for you to specify a proxy domain, user name and password. User Name is mandatory for accounts that require Registration with the ITSP.

Many ITSPs allow web access to set up your account. The password on this screen is your SIP password and not your web account password.

Some ITSPs may require advanced settings. To enter these settings, you can navigate to the ITSP Account settings from the gateway screen. For example, the Asserted-Identity field may be specialized. Click on the Advanced link to change these settings.

Whether the ITSP requires Registration or not, The P-Asserted-Identity header is a required header for most ITSPs that allow anonymous calling. It is used to compute the identity of the caller for account identification so that the From: header can be used for the caller-ID. The asserted identity field is also typically used for call forwarding to the ITSP. If the ITSP does not recognize this field and uses the From header for account identification, these features may not work as expected. if you select to "use default asserted identity", you must specify a user name so that the default Asserted Identity may be computed. If you elect to override the default Asserted Identity you must specify a valid entry (i.e. username@domain ) in the Asserted identity field. If you elect to specify an Asserted Identity, and if the asserted identity field is left blank or if you select the default and the user name is left blank, then none will be inserted into the call setup request bound for the ITSP.

If your ITSP does not support the P-Asserted-Identity (P-A-I) header and relies, instead, upon the From: header for SIP account identification, de-select the "use default asserted identity" check box in the screen above and leave the asserted identity field blank. With these settings, signaling directed towards the ITSP will not contain the P-Asserted-Identity header and the From header will contain what the P-A-I header would normally contain. If you configure things this way, the caller-Id presented to the called party when the call is forwarded will not be that of the calling party but rather, it will be the identity of the registered user from the PBX – which is, of course, incorrect. Hence, this is not a preferred configuration. You should try to find an ITSP that supports P-Asserted-Identity to have things work as you would expect.

For ITSPs with Hosted NAT Traversal (HNT) capabilities, you usually need to set up to use private addressing and turn on RTP keep alive in order for call forwarding to the ITSP to work. However, if your ITSP allows it, turn off hosted NAT traversal at the ITSP. SipXrelay already relays media for bridged calls. If you do not turn off HNT, you will get needless double relaying of media and hence poor voice quality.

Configure NAT Traversal

Navigate to System > Settings > NAT Traversal. This will take you to a page where you can configure your NAT traversal service settings.

Click on the server name to configure the NAT Configuration. You'll see that STUN is enabled by default. It's more reliable to select 'Static' and then enter your server's public address here vs. trying to use STUN to make it happen automatically. A relay service (known as SipXrelay) manages a range of ports which defaults to the range 30000 to 31000. This setting must be a contiguous range of free ports.

If your server is running behind a NAT you must also explicitly declare that. Go over to System -> Settings -> NAT Traversal -> Settings (left side menu) and select ensure that Enable NAT Traversal and the Server Behind NAT boxes are both checked. If you use an external Session Border Controller (recommended), you would typically not need the 'Enable NAT Traversal' box to be checked. Likewise, you'd probably also not be using sipXbridge for trunking, but instead the SBC.

If you plan to configure remote workers you should also enable NAT traversal on this page.

Configure Internet Calling

Click on System -> Settings -> Internet Calling. These are the settings that are used by the Media Relay (sipXrelay) service.

Ensure that your server's IP address is in 'Intranet Subnets'. It's best practice to only have IP's of your internal phones and servers listed here.

Configure a Dial Plan

Navigate to System -> Dialing -> Dial Plans.

Select a dial plan to modify, typically Local or Long Distance. If you are relying on 10 digit dialing pick Long Distance.

In the Gateways section drop down list, select the 'More actions...' drop-down list and pick the gateway we already configured above. After you are done adding the Gateway, you must select the "Enabled" check box in the screen above. Click on OK to back out of this screen.

Most ITSPs only need for you to specify a proxy domain, user name and password. User Name is mandatory for accounts that require Registration with the ITSP.

Many ITSPs allow web access to set up your account. The password on this screen is your SIP password and not your web account password.

Some ITSPs may require advanced settings. To enter these settings, you can navigate to the ITSP Account settings from the gateway screen. For example, the Asserted-Identity field may be specialized. Click on the Advanced link to change these settings.

Whether the ITSP requires Registration or not, The P-Asserted-Identity header is a required header for most ITSPs that allow anonymous calling. It is used to compute the identity of the caller for account identification so that the From: header can be used for the caller-ID. The asserted identity field is also typically used for call forwarding to the ITSP. If the ITSP does not recognize this field and uses the From header for account identification, these features may not work as expected. if you select to "use default asserted identity", you must specify a user name so that the default Asserted Identity may be computed. If you elect to override the default Asserted Identity you must specify a valid entry (i.e. username@domain ) in the Asserted identity field. If you elect to specify an Asserted Identity, and if the asserted identity field is left blank or if you select the default and the user name is left blank, then none will be inserted into the call setup request bound for the ITSP.

If your ITSP does not support the P-Asserted-Identity (P-A-I) header and relies, instead, upon the From: header for SIP account identification, de-select the "use default asserted identity" check box in the screen above and leave the asserted identity field blank. With these settings, signaling directed towards the ITSP will not contain the P-Asserted-Identity header and the From header will contain what the P-A-I header would normally contain. If you configure things this way, the caller-Id presented to the called party when the call is forwarded will not be that of the calling party but rather, it will be the identity of the registered user from the PBX – which is, of course, incorrect. Hence, this is not a preferred configuration. You should try to find an ITSP that supports P-Asserted-Identity to have things work as you would expect.

For ITSPs with Hosted NAT Traversal (HNT) capabilities, you usually need to set up to use private addressing and turn on RTP keep alive in order for call forwarding to the ITSP to work. However, if your ITSP allows it, turn off hosted NAT traversal at the ITSP. SipXrelay already relays media for bridged calls. If you do not turn off HNT, you will get needless double relaying of media and hence poor voice quality.

Caller ID settings

From the Gateway page click on the Caller ID left side menu item. Select the advanced checkbox. Enter the caller-Id for the account. The caller Id is what appears in the From: header of the outbound request for non-anonymous calls. Usually, accounts that are provisioned by public address have the caller Id set to user-name@public-address. Accounts that are provisioned by SIP Registration, usually have user-name@itsp-domain. Variations are possible. Please check with your ITSP. On this screen, the domain
does not necessarily have to be a DNS Domain name. Some ITSPs may require that you have to use an IP address here.
Note that the settings on this screen affect all calls that are routed via the given trunking gateway to the ITSP.

If you want to specify a per-user caller ID ( for example the DID that is assigned to the user to appear as that user's caller-ID ) here is how to proceed :

#Do not specify a caller-id in the trunking gateway configuration screen below(leave all fields blank).

  1. Specify a per-user caller ID when configuring the user.

Configure any required Dial Prefixes in your Dial plan

From the Gateway configuration page navigate to the Dial Plan page. Set up any dial prefixes (for example +1. This is usually country dependent. )

If you use Dialog Based SIP Trunk ensure that it is registered Properly

Click on Diagnostics -> SIP Trunk Statistics and your trunk should show as 'Authenticated'. If not, check all of the prior settings mentioned above and ensure that you have the right settings from your ITSP.

Known limitations

  1. For outbound calling, you cannot have more than one ITSP account per ITSP domain. However, you can have multiple accounts for a given ITSP for inbound calling, assuming that your ITSP allows multiple accounts to be registered from the same IP address and port.
  2. No end to end encryption. Since sipXbridge is relaying media it breaks end to end encryption.
  3. To simplify the design, media is always relayed through sipxrelay when a call passes through sipXbridge. The bridge avoids hairpinning the media path however, so there is only one relay for a given end to end call and the same relay is used throughout the call.
  4. sipXcom's media relay only works with non-ha clusters. If you have an HA cluster you'll need to utilize a Session Border Controller.

Tricks

By default sipxbridge/sipxrelay will ALWAYS anchor media.

There is a flag which is not supported via sipxconfig ( i.e. experimental flag ) which will allow you to remove the media anchor for forwarded calls.

It is called <always-relay-media> Look in the sipxbridge.xsd file for a description. By default that flag is true and it is hidden. You can set it to false by editing sipxbridge.xml and if you do so, then for hairpinned forwarded or blind transferred calls, the media relay will be removed from the media path AFTER transfer.

Trouble Shooting and Problem Reporting

See: Trouble shooting and problem reporting

Firewall

Inbound for SIP trunking you'll need to open 5080 UDP (SIP signaling for sipXbridge) and 30000-31000 UDP (RTP).

The firewall needs to allow 5060 UDP Outbound and 30000-31000 UDP Outbound.

See Firewall

User Experiences

See User Experiences