...

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)

...

• Must support RFC 3261
• Must support Re-INVITE (with and without SDP) for mid-call codec renegotiation.
• Must support Session Timer.
• Must support P-Asserted-Identity extension header to present correct caller ID during call forwarding and blind transfer operations and for anonymous calling.

SipXbridge has been tested for interoperability with several providers.

Here is a partial list of Interoperable Providers

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:

...

How to configure sipXbridge

...

...

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 sipXecs 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 SIPXECS 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.

Typically ITSPs do not handle certain types of SIP requests such as REFER which is used in Call Transfer operations. To implement call transfer, It is possible in versions 4.4 and later to allow sipxbridge to listen for inbound SIP trunking on port 5060 UDP while simultaneously listening for SIP Proxy requsts on 5060. This is done by enabling the bridge-proxy-relay setting in Server -> Services -> SIP Proxy.

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.

...

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 callthan 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.
4. No end to end encryption. Since sipXbridge is relaying media it breaks end to end encryption.
5. 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.

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.

HA Configuration

For HA Configuration each node of the HA system must have media relay ports that do not overlap with the other server. Otherwise media relaying will not work correctly
If you have enabled SIP trunking on more than one server, ITSP account configurations should not interfere with each other.

Trouble Shooting and Problem Reporting

See: Trouble shooting and problem reporting

Firewall/NAT Configuration

See Firewall and NAT Configuration

User Experiences

See User Experiences