Now more and more enterprises choose Unified Communications and SIP-based VoIP phone systems as their communication solutions. Meanwhile, the connection issues in complex networking like multi-locations and remote working, or the interoperability issues between different networks, SIP endpoints and SIP servers, IP PBXs are still their headaches. Session border controller SBC, as an critical component of VOIP networks, is designed to resolve the problems of connectivity and interoperability, ensure the stability of your IP telephony systems and your business continuity.

In this article, we will share with you how SBC can perfectly resolve the problems of enterprises NAT Traversal, cross-network communications and compatibility of different terminals and various SIP Servers.

Session Boarder Controller——SBC，as an important component of VoIP business in the new Telecom era, is specially designed to resolve the problems of Network Security, NAT/Firewall Traversal, QoS Guarantee and interconnection of various SIP server platforms in the VoIP world!

In this doc, we are pleased to share how Dinstar SBC can perfectly resolve the problems of enterprises NAT Traversal, cross-network communications and compatibility of different terminals and various SIP Servers.

Challenges of SIP-based Audio/Video communication

NAT/Firewall Signaling(SIP)Traversal NAT/FirewallMedia (RTP)Traversal Detection and process of abnormal packets Compatibility of different SIP endpoints / terminals Compatibility of different SoftSwitch Platforms Conversion of different protocol and codecs

How does SBC solve road blockers above

A great feature of SIP protocol is its openness, it gives different manufacturers room for customizations and flexibilities based on the SIP specifications. Unfortunately, it also brings compatibility problems in the interconnections of various SoftSwitch, IP PBXs and different SIP Endpoints from various venders. Furthermore, the complexities in enterprise networking, such as NAT traversal, Firewall, could lead to failures of SIP signaling and media while crossing these networks.

SBC is designated as a back-to-back user agent (B2BUA), which is located at the network borders. It can perfectly complete the traversal of various NATs and firewalls in call services. Like doctor's scalpel, it can perform traffic control, monitoring, identification, SIP headers modification or even discarding, and manipulation of the media info in the SDP of SIP signaling session, achieve the smooth establishment of sessions between various terminals, interconnection of signaling and media, completion of various call services, and quality-assured VoIP services.

What magic tricks does Dinstar SBC have?

1. NAT/Firewall traversal of SIP signaling and media

NAT Traversal of SBC

SBC as Media Proxy in Multi-NAT Networks

1.1 Local NAT feature

In the scenario that the SBC is deployed behind the enterprise firewall and communicates with the outside world through mapping, it could happen that the SBC fails to receive the messages sent by the external network.

Dinstar SBC solution

The “Local NAT” feature will ensure that the SBC behind the firewall can normally receive the SIP signaling and RTP media stream from the external network users or the SIP Trunk service providers. You can enable the local NAT configuration in the SBC's access network or the Trunk: Set the firewall public IP; SIP signaling NAT listening port; RTP media NAT port range. With local-end NAT enabled, SBC uses the configured NAT public IP and port in the SIP contact header, as well as SDP media info. By this means, it accomplishes NAT signaling and media traversal.

See configuration screenshot below for detail:

1.2 Auto-Adaptive Signaling/Media feature

Due to the deployment of the firewall DMZ/NAT in the call services, the address in VIA/FROM/TO/Contact/SDP of SIP messages from SoftSwitch of the intranet or the far-end SIP terminations could be inconsistent with the actual IP address. Plus, possible changes or refresh of media information during the call, could result in an incorrect address or invalid port for signaling and media interaction, and eventually lead to the failure of the call establishment.

Dinstar SBC solution

With the “Auto-Adaptive Media/Signaling” feature: Unlock Media and signaling address Support remote media refresh, Dinstar SBC will automatically learn the media path of the NAT network of the peer side, thus ensure the intercommunication of signaling/media between the two parties.

2. Process of SIP abnormal packets

2.1 SIP signaling traffic control

SBC can dynamically check the received SIP signaling messages in real-time. If it detects abnormal signaling messages from a certain IP or account, it can block or even add it to blacklist according to the configured threshold and criteria.

2.2 SIP packets format detection

SBC will check the content format of all received SIP packets, and automatically discard the packets with missing key fields, garbled content, incorrect “call-id”, incorrect “to tag”, incorrect Cseq and all other malformed format.

3. UDP/TCP/TLS Interworking

SBC is at the edge of different networks, and connected to different VoIP service providers. The transmission protocols used by different networks may be inconsistent. SBC can convert communication protocols such as UDP to TCP, UDP to TLS conversion, ensure the connection of sessions between the different networks, enterprises and service providers.

4. WebRTC Gateway

Dinstar SBC is also a WebRTC to SIP gateway, delivers seamless connections between WebRTC clients and enterprise unified communications system. More details about WebRTC will be discussed in our following article.

5. IPv4 and IPv6 Interworking

Users may face the issues like LAN with IPv4, and WAN with IPv6. Dinstar SBC supports IPv4 and IPv6 interworking for media and signaling. Different SIP endpoints or SIP servers with no matter IPv4 or IPv6 addresses can be seamlessly connected with the help of SBC.

6. Protocol conversion

The principle working mode of SBC is B2BUA (back-to-back proxy). For example, some clients use TLS encryption, and some clients use WebRTC protocol, but the enterprise core network server only supports UDP protocol. SBC can then convert different protocols to well establish the session communication between enterprises and different clients.

7. Voice codec transcoding and video transparent transmission

7.1 Voice transcoding

In the actual call service, different SIP terminals and SIP server/IP PBX/SoftSwitch platforms could use different codecs. SBC will automatically do codecs transcoding if the voice codecs negotiated by the terminal equipment are different, to the codecs supported by the core server (For example, G.711 to G.729 codec). Thus, ensure the successful interaction of voice calls.

7.2 DTMF transcoding

SBC automatically detects the DTMF mode of the call negotiation on both sides. If the two parties are using different DTMF mode, for example, the calling party sends DTMF signals through Inband, but the called party only supports rfc2833. SBC will automatically do the transcoding between Inband mode and RFC2833 mode. Thus, ensure successful business interaction with different DTMF modes.

7.3 Video transparent transmission

SBC supports video calls. After enabling this function, it can automatically forward the video information from both parties and have video call services worked.

8. SIP compatibility processing methods

8.1 SIP headers forwarding

The SIP protocol has strong scalability to connect different SIP servers and different service types. Some manufacturers may add some extension header fields to implement special services. SBC can transparently forward the SIP headers or discard them based on specific designated services (e.g., History-Info, user-agent headers).

8.2 SIP methods compatibility

If the request methods supported by both sides are different, SBC can use the B2BUA mode to implement single-side signaling interaction to ensure normal communication. (e.g., PRACK/Session Timer/REFER/UPDATE/Re-INVITE/SUBCRIBE/NOTIFY etc.)

8.3 Oversize SIP message process

Some SIP messages sent by the server carry a lot of unnecessary content (such as the large SDP of a video conference), which causes the message to be too large and the other party cannot support it. SBC can filter unnecessary headers and SDP media resource information. Thus reduce the message length to normal size.

8.4 Business model compatibility

Compatible with platforms such as IMS/Huawei/Avaya/Cisco/Genesys, including call on hold, call transfer, call parking, tripartite conference, and other services.

8.5 URI domain forwarding

Some core SIP servers require users registered and call must carry the specified domain name in the request line /FROM/TO header, which is used for the authentication of the registration and call messages (e.g. IMS platform). SBC can add the specific domain name in the SIP trunk and pass it to the core network.

8.6 SIP headers manipulation

The content of SIP messages sent by some SIP servers and terminal devices is not standard. Or special values are required in connection with some SoftSwitch/IP PBX/SIP server platforms. For that scenario, SBC can modify/delete the header fields of the SIP message or the content of the SDP message body.

You may want to know

Click to know more details about our Session Border Controllers

Click to learn more about Why do you need an SBC?

What is a Session Border Controller (SBC)? Part III: High Availability

What is a Session Border Controller (SBC)? Part I: Enhanced VoIP/SIP Security.