NethVoice Proxy: support static outbound port mapping for multi-tenant Vianova trunks

[Amygos]

Proposed Feature
Support for multi-tenant Vianova SIP trunks in NethVoice Proxy by enabling static outbound port mapping and slot management for proper trunk registration and call routing.

Purpose and Motivation
Currently, when configuring multiple Vianova trunks across different NethVoice instances behind the same proxy, only the first-registered instance can successfully make outbound calls. This limitation arises because Vianova enforces a security restriction: only one registration per unique source IP and port is accepted; subsequent registrations from the same IP/port tuple are rejected with a "403 forbidden" error. This prevents true multi-tenant support in environments where multiple NethVoice instances need to register trunks with the same provider via a shared proxy.

Implementing this feature is important to enable multiple tenants to reliably use Vianova trunks on a single proxy without registration conflicts, supporting proper scalability and tenant isolation.

Proposed Solution

• Kamailio statically allocates a configurable range of outbound ports ("slots"), with each slot assigned a unique name (e.g., slot1, slot2, ...). Slots are bound at startup for all protocols (UDP, TCP, TLS).
• Slot selection for each trunk is managed via a custom SIP header or a static mapping.
• New management actions are introduced:
  • NethVoice Proxy:
    • list-trunks-reserved-ports: lists available/reserved ports
  • NethVoice:
    • get-trunk-reserved-port: shows the port assigned to an instance
    • set-trunk-reserved-port: sets or updates the port for an instance
• During installation, NethVoice selects an available port from the list and sets it; ports can be changed later if needed.
• The assigned port must remain fixed and communicated to Vianova for correct trunk setup.
• Default behavior is preserved if no slot is specified in the dialplan (no explicit socket binding).
• The port range and number of slots are configurable; adding more slots requires a proxy restart.
• Port mapping should be consistently applied to all relevant SIP packets for provider compatibility and stability.

Alternative solutions

• Dynamic port allocation at runtime was considered but is not feasible due to Kamailio’s requirement to bind ports at startup.
• Shifting business logic entirely to Kamailio (managing all trunk/tenant mapping within the proxy) could be explored, but increases complexity and reduces integration flexibility with NethVoice.
• Using multiple IPs was ruled out, as most environments have access to only one external IP.

Additional context

• Vianova requires that each trunk registration comes from a unique source port/IP tuple. The port must remain static and be communicated to the provider during trunk setup.
• The solution must pre-allocate a sufficient number of ports (e.g., 10) for expected tenants; exceeding this would require a proxy restart to allocate more.
• All Kamailio bindings must be created for each protocol (UDP, TCP, TLS), multiplying process counts.
• See the related discussion threads and technical background in the Jira ticket (internal) and the Kamailio documentation for socket naming and binding.

See also

• Evoseed Jira ticket: https://evoseed.atlassian.net/servicedesk/customer/portal/5/EA-62
• Kamailio Core Cookbook