Nethvoice: Vianova trunk

[Amygos]

Proposed Feature
Support for Multiple Vianova Trunks on a Single Proxy Using Dynamic Port
Bindings

Purpose and Motivation
Currently, when configuring multiple Vianova trunks (each with its own number
and user extension) on separate instances behind the same proxy, outbound calls
only work from the instance that first registers with the provider. The
provider (Vianova) restricts registration such that only the first client using
a given IP:port pairing succeeds; subsequent attempts from the same IP and port
for different clients are rejected with "403 forbidden". This limitation arises
because Vianova identifies trunks by their unique IP and source port
combinations. As a result, it is currently not possible to operate more than
one Vianova trunk per external IP address, limiting the ability to serve
multiple tenants from the same server/infrastructure.

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.
• 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

• Example Kamailio listen directives:

  listen=udp:10.0.0.10:5071 name "slot1"
  listen=udp:10.0.0.10:5072 name "slot2"
  ...
  

• Reference: Kamailio Core Cookbook
• Provider requires prior communication of allocated ports for trunk
  configuration on their platform: “The signaling port can be freely chosen per
  trunk, but must be fixed and communicated in advance for correct
  configuration.”
• 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 Also

• Private Mattermost chat: https://mattermost.nethesis.it/nethesis/pl/d1r9ag5od7doz8wyqeys1pzaka
• Evoseed ticket: https://evoseed.atlassian.net/servicedesk/customer/portal/5/EA-62