Bitfocus AS
logo
logo
Bitfocus AS
logo
logo
Sign upSign in

Loading...

Bitfocus

Subscribe to our newsletter

The latest news, articles, and resources, sent to your inbox.

FacebookInstagramGitHubYouTubeLinkedIn

Products

  • Buttons
  • Companion

Integrations

  • Supported Devices
  • Developer Community
  • Connection Development

Support

  • Support Overview
  • Documentation
  • Video Tutorials
  • Community Forum

Sales

  • Resellers & Integrators
  • Buttons Pricing

Updates

  • Case Studies
  • Events & Trade Shows
  • Press Releases
  • Product Updates
  • Webinars

Legal

  • Legal Overview
  • Privacy Policy
  • Buttons EULA
  • Terms & Cookie Policy

Company

  • About us
  • Press kit
  • Careers

© 2026 Bitfocus AS. All rights reserved.

Manage NMOS multicast addresses
Docs for
Overview
Getting started
What is Bitfocus Buttons?
Install Buttons and get started
Manage your Buttons license
Activate Buttons offline
Find your way around Buttons
Create your first backup
Add an ATEM connection
Choose a control method
Choose an installation path
Install Buttons on Debian or Ubuntu
Understand HA clustering
Kubernetes HA
Update or remove Buttons
Positions
Understand positions
Create a position
Add controls and sections to a position
Create your first button
Use a connection's presets
Build more capable button actions
Add more feedback to a button
Organize controls in a section
Shift Section
Organize controls with a Folder Section
Add a Popover Section
Build and reuse a Shared Section
Build a Router Section
Understand Custom Routers
Custom Router panel
Surfaces
Surface compatibility
Add and attach a surface
Device orientation
Connections
Update a connection's module safely
Monitor and troubleshoot a connection
Router integrations
VideoHub and AJA KUMO
Utah Scientific BPS
Generic SW-P-08
Nevion VideoIPath
Arkona BLADE//runner
Routing
Physical routing
Configure ports and labels
Take a physical route
Understand route status
Topology graph
Routing Presets
Get started with virtual routing
Configure Nested Shapes
Reverse routing
Tielines
Routing Projects
Routing settings
Troubleshoot a route
Tally
Understand the Tally system
Send ATEM tally and labels to a UMD
Interpret Active Tally state
TSL/UMD connections
Diagnose tally problems
NMOS
Understand NMOS in Buttons
Connect Buttons to an NMOS Registry
Built-in Registry Server
Configure NMOS connections
Discover and adopt
Browse the NMOS inventory
Manage NMOS multicast addresses
Diagnose NMOS problems
Understand Cuelists
Build a Cuelist
Read and advance a running Cuelist
Control a Cuelist from a Position
Workflows
Understand workflows
Build your first workflow
Reuse a group of workflow nodes safely
Troubleshoot a workflow
Recipes
Sequence a timed automation
Call an HTTP endpoint from a workflow
REST endpoint
Use variables
Understand variable scope
Understand nested variables
Update expressions for v1.8
Plan and use Tags
Access
Create and manage users
Create roles and assign permissions
Grant access to specific resources
Show different controls by role
Sessions
Set up PIN and NFC sign-in
SSO
Get started with SSO
Connect a generic OIDC provider
Connect LDAP or Active Directory
Map identity claims to roles
Secure a Buttons deployment
Integrations
External control
Connect to Bitfocus Listener
USB Relay
Install USB Relay on Windows
Install USB Relay on macOS
Install USB Relay on Linux
Install USB Relay on a Raspberry Pi
Get started with the Control API
Secure and monitor the Control API
Control API reference
API reference
Administration
Enable and manage installable features
Services and health
Configure and monitor scheduled backups
Restore a backup and verify it
Export or import Buttons configuration
Store and rotate connection secrets
Replace the HTTPS certificate
HA backup and recovery
Settings
Collect support information
Reference
Glossary
Button Inspector reference
Network ports reference
Expressions
Internal actions reference
Routing Presets panel reference
Startup configuration reference
Workflow nodes
Connection workflow nodes
Workflow workflow nodes
Internal workflow nodes
Position workflow nodes
API workflow nodes
Utility workflow nodes

Loading...

Previous
← Browse the NMOS inventory
Next
Diagnose NMOS problems →
Contact support →
You are viewing documentation for Buttons 1.8.See the docs for Buttons 1.6
Buttons/NMOS/Manage NMOS multicast addresses

Manage NMOS multicast addresses

Multicast Address Management can help you assign NMOS sender addresses from defined pools without reusing a managed combination of address, destination port, and stream leg. Instead of tracking each sender manually, you define pools and the feature records each allocation.
Category-specific pools can also help your network orchestrator identify each stream's media class and reserve the corresponding bandwidth. For example, an address from a range reserved for HD video can trigger the orchestrator's HD video bandwidth policy. Multicast Address Management assigns the address; the network orchestrator applies the bandwidth reservation.
This guide configures one system-wide auto-assignment profile for a non-production HD video sender. The v1.8 web interface exposes system-wide profiles; Registry- and connection-specific profile overrides are not covered.

Tip

Use dedicated ranges when possible so manually assigned addresses do not overlap with managed allocations.

Before you begin#

You need:
  • The NMOS feature enabled in Buttons.
  • A Pro or Enterprise license.
  • System administration access for NMOS settings.
  • An adopted NMOS node with a sender whose SDP and source port are available to Buttons.
  • A multicast address range and destination port for the sender category.
  • When network orchestration uses ranges to classify streams, a corresponding range-to-media-class mapping.
  • Access to the NMOS sender and network monitoring needed to confirm the resulting stream.
Enabling auto-assignment updates eligible senders through IS-05 and activates the change immediately. Start with a non-production sender.

Why manage addresses centrally#

A multicast sender needs a destination address and port before receivers can subscribe to its stream. When these values are assigned manually across many senders, two senders can unintentionally receive the same address, port, and primary or secondary leg.
Multicast Address Management provides one allocation record for managed senders:
  • Profiles divide address pools by media category.
  • Each allocation is recorded before it is applied to the sender.
  • The next sender receives the first available address rather than reusing a managed allocation.
  • Current allocations shows which sender holds each managed address.
  • Stable category ranges let an external network orchestrator map an address to a stream class and apply the bandwidth policy configured for that class.
The allocation record covers addresses managed here, not addresses assigned manually or by another controller. The external orchestrator uses its own range-to-stream-class mapping to apply bandwidth policy.

How address selection works#

The sender is classified from its NMOS flow and source metadata. Available profile categories include specific formats such as Video HD, Video 4K HDR, and Audio Stereo, plus fallback categories such as Any Video, Any Audio, and Any.
When a network orchestrator uses the assigned range to choose a bandwidth policy, align each profile with the orchestrator's stream-class mapping.
For a classified sender, profiles are considered in this order:
  1. The sender's specific category, such as Video HD.
  2. The matching media fallback, such as Any Video.
  3. Any.
The first unallocated address in the matching profile's inclusive range is selected. An address is considered occupied when an existing allocation uses the same primary or secondary leg and destination port.
A secondary range is optional. Add one only for senders with two interface bindings that use SMPTE ST 2022-7 redundancy. Both legs are assigned together; if the required secondary address is unavailable, the sender's previous managed allocations remain instead of applying only the primary leg.

Add a profile for HD video#

In this example, the network orchestrator maps the HD video range to its HD bandwidth policy. Configure that mapping in the orchestrator when your network uses range-based classification.
  1. Open Settings → Multicast.
  2. Under Auto-assignment profiles, select Add Profile.
  3. Set Category to Video HD.
  4. Enter the inclusive range in Primary Start IP and Primary End IP, such as 239.100.10.100 to 239.100.10.199.
  5. Enter the destination Port. The initial value is 5004.
  6. Select Add Profile.
The new Video HD card shows the primary range and destination port. The form rejects an address outside 224.0.0.0–239.255.255.255, a range whose end precedes its start, an incomplete secondary range, or a port outside 1–65535.

Enable automatic assignment#

The profile defines which addresses are available. The NMOS behavior determines whether they are assigned automatically.
  1. Open Settings → NMOS.
  2. Find NMOS Controller Behavior.
  3. Enable Auto-Assign Multicast Address.
  4. Select Save.
Eligible senders are reevaluated when the behavior or multicast profile configuration changes and when changed sender SDP is read. An HD sender receives the first free address in the Video HD profile, and the address and destination port are applied through IS-05.
Open the NMOS Inventory page's Multicast allocations tab (linked from Settings → Multicast's own Current allocations section). The assigned sender appears with its Source (Pool for an auto-assigned address, alongside Manual and Adopted: see Override or renew a sender's address), Category, address, and leg, plus an on-wire check against the sender's own SDP so drift between the recorded allocation and what the device actually announces is visible at a glance. A single-leg sender appears as Primary. This record keeps the managed address and port from being assigned to another sender on the same leg.
Confirm that the expected non-production stream is active at the listed address and port. When an external orchestrator uses range-based classification, its monitoring should show the HD video bandwidth policy applied to the stream.

Add a fallback profile#

A specific profile is preferred over a fallback. For example, a Video HD sender uses the Video HD profile even when Any Video and Any profiles also exist.
A fallback gives a broader group of senders access to one pool when their metadata does not match a specific category. Choose Any Video, Any Audio, or Any according to the streams the pool should support.
If no profile matches, no new address is assigned. Review the NMOS logs for a missing-rule warning, then add the appropriate profile or correct the sender's NMOS metadata.

Add a secondary ST 2022-7 range#

For a sender with two interface bindings, you can allocate separate primary and secondary addresses:
  1. Open Settings → Multicast.
  2. Add a profile for the required category.
  3. Enter the Primary Start IP, Primary End IP, and Port.
  4. Select Add secondary range (ST 2022-7).
  5. Enter the Secondary Start IP and Secondary End IP.
  6. Select Add Profile.
When both legs are required, Current allocations shows separate Primary and Secondary rows for the sender. Both legs use the same destination port.

Override or renew a sender's address#

The Multicast allocations tab on the NMOS Inventory page lets you step outside the automatic pool assignment for a specific sender when you need to:
  • Override an address: select a sender's row, choose Override address for the primary or secondary leg, and enter a specific multicast address and port. A manual override is kept across rule changes and forced re-syncs until you clear it; the device is re-staged immediately. The override is rejected (with the reason shown inline) if the address and port are already named by a static SDP, already carried by another live sender, or already allocated to another sender on that leg.
  • Renew an address: select one or more senders and choose Assign new available addresses to release their current allocation (auto-assigned, manual, or adopted) and draw a fresh one from the matching profile.
  • Clear an override: returns a manually-overridden sender to normal pool assignment.
Each of these offers an Update receivers with the new SDP option: on, every receiver currently taking that sender is re-staged with the new address once the device's SDP announces it (up to 15 seconds), regardless of the receiver's own reconnect-on-SDP-change behavior; off, receivers pick up the change on their own next SDP read instead.

If you get stuck#

What you see
What to try
Multicast is missing from Settings.
Confirm that NMOS is enabled in Settings → Features and that the system has a Pro or Enterprise license.
No allocation appears after you save.
Confirm that the sender is adopted, exposes a source port and readable SDP, has Auto-Assign Multicast Address enabled through its behavior configuration, and matches a configured category or fallback. Review the NMOS logs for no matching rule, range exhaustion, or IS-05 staging failures.
A redundant sender receives no new allocation.
Confirm that both the primary and secondary ranges have a free address. A partial new assignment is not kept when a required secondary allocation fails.
The allocation appears, but the stream is unavailable.
Check the sender's IS-05 state, multicast network, orchestrator bandwidth reservation, and receiver subscription.
The network reserves the wrong bandwidth class.
Confirm that the sender's NMOS flow metadata selected the intended profile and that the external orchestrator maps the assigned range to the same stream class.

Release an allocation#

The Multicast allocations tab lets you select one or more rows and choose Release. Releasing removes the managed record and makes the address available for a future allocation. It does not disable the sender or change its transport parameters, so release the record after the sender has stopped using the address.

Warning

Release takes effect immediately, with no confirmation step. Confirm the sender has actually stopped using the address before releasing its record: otherwise a future allocation could reuse the same address while the original sender is still transmitting to it.

Deleting a profile asks first: the confirmation dialog reports how many active address reservations that profile holds and offers Delete and keep reservations (the profile is removed, but its senders' current addresses stay reserved and cannot be reused) or Delete and release reservations (the same immediate-reuse risk as releasing an allocation directly, described above: confirm those senders have actually stopped using their addresses first).

Was this helpful?

Was this helpful?

0 of 0 users found this page helpful