The Sansay VSXi is a session border controller (SBC) available in both software (virtualized) and bare-metal form. Service providers use it to secure the border between their internal VoIP core and the outside world – enforcing policy on which SIP traffic is allowed in, performing NAT traversal for subscriber devices behind firewalls, interconnecting with other carriers via SIP peering (NNI), and manipulating SIP headers to resolve interoperability problems between different networks.

Sansay has been a significant player in the peering SBC market for many years and has more recently expanded into the access/registration side of the market. The Sansay VSXi platform is known for offering high session capacity at a competitive price point and for its GUI-driven configuration, which lowers the barrier to entry compared to platforms with proprietary CLI interfaces.

In a peering deployment, the Sansay VSXi sits between the service provider's core call server and an external carrier or wholesale partner. Traffic flows as SIP trunks between fixed, known IP addresses – no SIP registration is involved.

In an access deployment, the VSXi faces subscriber devices (SIP phones, ATAs, hosted PBXs) that register from dynamic or NATted IP addresses. The VSXi manages hosted NAT traversal (HNT), enforces registration rate limits, and handles the keep-alive register cycle to maintain NAT pinholes.

Many service providers run separate VSXi pairs for these two functions to keep the security policy and configuration clean on each side.

SMC rules – also called SIP manipulation rules – allow the Sansay VSXi to modify SIP headers and parameters as messages pass through the platform. Common uses include rewriting the URI host domain to match what the downstream network expects, adding or removing parameters like phone-context or P-Asserted-Identity, normalizing E.164 digit formats, and translating between different header conventions used by different vendors.

SMC rules are typically needed when two SIP endpoints disagree on header formatting and it's impractical to reconfigure either endpoint. The risk is that SMC rules accumulate over time – one rule added for each new customer or carrier – and the resulting set becomes difficult to maintain and troubleshoot.

LCR on the Sansay VSXi directs outbound calls to the least expensive available route based on configurable routing profiles and SIP peering trunk priorities. The platform can evaluate multiple SIP servers (carriers) for a given destination, rank them by cost or preference, and attempt the next option if the preferred route fails.

The routing decision is visible in the CDR output, including which trunk was selected and what digits were presented to it. Troubleshooting LCR problems on the VSXi typically involves reading the CDR alongside the routing profile configuration to determine why a call went to the trunk it did.

ECG starts with thorough documentation of existing call paths – what trunks are active, what SIP manipulation is in place, what the registration architecture looks like, and what downstream servers expect to receive. We then map that to the Sansay VSXi configuration model, identifying where direct translation is possible and where the migration requires new design decisions.

Migration is executed in phases – typically peering trunks first, then registration subscriber batches – with validation at each step using CDR review and SIP trace analysis. Rollback procedures are defined before any cutover begins. The goal is that the first time a subscriber notices the migration has happened is never.

Yes. The Sansay VSXi is available as a software SBC that runs in virtualized and cloud environments alongside the bare-metal hardware option. Running the VSXi virtualized introduces questions about resource allocation, network interface configuration, and performance that don't exist for bare-metal deployments.

Getting the iNX and MST3 sizing right for a given call load – and ensuring the hypervisor configuration doesn't introduce media latency or jitter – requires operational experience beyond reading the vendor data sheet. ECG has deployed Sansay VSXi platforms in both physical and virtualized environments and can advise on sizing, network design, and performance tuning for your specific deployment model.

Hosted NAT Traversal is how the Sansay VSXi handles SIP registration from subscriber devices behind NAT firewalls – a common situation for SIP phones, ATAs, and hosted PBXs deployed at customer premises. HNT allows the VSXi to maintain the NAT pinhole open by managing the SIP registration keep-alive cycle, ensuring that incoming calls can reach devices that initiated outbound registrations.

The HNT access realm configuration includes trust levels, blacklisting policies, and registration rate limits that protect core servers from registration storms while ensuring legitimate subscribers maintain reliable service.

Identifying which chassis is active, reading system-wide call stats correctly, understanding the intervals behind those stats, and correlating CDR data with actual call behavior are all non-trivial on the Sansay VSXi.

Operational teams without deep platform knowledge often make support decisions on incomplete information. ECG can establish the right operational practices, document the platform's normal behavior under your specific traffic patterns, and train your team on what the VSXi is actually telling them – so HA pair status, call statistics, and alarm output translate into confident operational decisions.