Skip to content
Callaba
Product user guide

Active ports

See which module owns each listener or transport port, open the owner and safely release only stale allocations.

Find it in CallabaAdvanced → Active ports
What this module does

The port inventory prevents hidden listener conflicts. Release is a recovery action, not routine cleanup: identify and stop the owning resource first.

Continue this workflow in Callaba

Callaba self-hosted

The intended listener owns the port and accepts a verified connection without disrupting an unidentified live resource.

See how the product works

Before you start

  • Administrator access.

  • A confirmed maintenance window if the port may belong to a live resource.

Settings explained

These are the controls an operator needs to understand. Internal field names and implementation events are intentionally omitted.

Port inventory

Read ownership before taking action.

Port

Allocated network port.

Transport

TCP or UDP context associated with the allocation.

Owning module

Resource that reserved the port.

Open owner

Navigate to the module responsible for the allocation.

Release

Remove a stale port allocation.

Stop and verify the owner first; releasing a live listener can interrupt service.

Safe first workflow

  1. 01

    Locate the conflicting port and read its transport and owning module.

  2. 02

    Open the owner and confirm whether it is active or still required.

  3. 03

    Stop or remove the stale resource through its own module.

  4. 04

    Release the allocation only when the owner is inactive and the port remains stale.

  5. 05

    Create or restart the intended listener and verify the port now belongs to it.

Workflow examples

Use this when

Resolve an SRT listener conflict

A new SRT server cannot bind to the requested UDP port.

Requested portBind failure
Port inventoryFind owner
Owning resourceStop / correct
SRT serverBind + test
Animated workflow diagram: Resolve an SRT listener conflict

How to build it

  1. 1

    Find the UDP port in Active ports and open its owner.

  2. 2

    Confirm whether that resource is live, stale or misconfigured.

  3. 3

    Stop/remove the stale owner and release only the leftover allocation.

  4. 4

    Start the intended SRT server and connect a real client.

Use this when

Prepare a firewall change from the live port inventory

A self-hosted deployment needs a reviewed list of active TCP and UDP listeners before security-group or firewall work.

Port inventoryCurrent ownership
Module ownersRequired listeners
Firewall planApproved exposure
Client testsReachability proof
Animated workflow diagram: Prepare a firewall change from the live port inventory

How to build it

  1. 1

    Export or record each required port, transport and owning module without releasing it.

  2. 2

    Confirm the expected publisher, receiver or browser client for every externally reachable listener.

  3. 3

    Apply the smallest approved firewall rule set during a controlled window.

  4. 4

    Test each real client path and compare the active-port ownership with the pre-change inventory.

Verify the result

  • Every important listener has a recognizable owning module.
  • A released stale allocation disappears from the inventory.
  • The intended resource can bind and accept a real connection.

Troubleshooting

A released port immediately returns

Check
  • Check whether the owning resource is still active or restarting.
  • Inspect the module lifecycle state.
Then do this

Stop or reconfigure the real owner; repeated release cannot override an active listener.