On rare occasions, a customer will experience a problem where
a camera sending unicast packets performs flawlessly, but the
TBus transceivers “fail” to deliver multicast streams.
Because the TBus devices are delivering data amongst each
other in a distributed bus architecture, they need to be told
where to send which multicast streams. The TBus transceivers
count on the switch(es) to deliver that information.
Sometimes switches have been configured in a way that
assumes the TBus transceivers are edge devices (such as PCs
or IP cameras). In the interest of saving bandwidth, they do not
forward the IGMP control information. Without knowledge of
any request for a multicast stream, the TBus transceivers duti-
fully block that traffic.
Switches and routers (and NVT devices) do not routinely deliver
multicast traffic to all destinations. That could overload the net-
work. Instead they rely on a special control protocol to identify
and report which recipients (such as the VMS/NVR) are
requesting which multicast streams.
That protocol is called Internet Group Management Protocol
(IGMP).
How does IGMP Work?
A “Querier” control resource is implemented on one network
host, such as a switch or router. Virtually all routers and most
switches are equipped with this capability. If there are multiple
hosts, the one with the lowest IP address is elected to perform
this Querier function.
The Querier is responsible for sending IGMP Queries to the
entire network, typically once every three minutes. Any device,
such as the VMS/NVR, that wishes to receive a particular
multicast stream responds to this Query by generating an IGMP
Report that is sent in the direction of the camera. That Report
is monitored and passed on by switches and routers within the
network. That monitoring is called IGMP Snooping.
These switches and routers each keep their own Routing Table
and use it to determine which ports should and should not
receive each multicast stream. It would be inappropriate for the
switch to send a multicast stream everywhere, as it would clog
the network.
The TBus transceivers are not point-to-point devices. They join
together to function as a distributed switch. Like a switch, they
listen for IGMP Reports and block unknown multicast packets.
This is particularly important in a multi-camera environment, as
we do not want the stream from one camera being delivered to
all other cameras. That could generate too much traffic.
Switches and routers forward the IGMP Reports on to other
switches. However in the interest of not forwarding unneces-
sary traffic, many switches do not forward these reports to
‘Client Ports’, such as PCs.
If the TBus transceivers do not receive IGMP Reports,
then they will BLOCK UNKNOWN MULTICAST PACKETS,
and the multicast video will not pass through
.
Solutions
There are several ways to fix this: Running unicast only;
Influence the IT department to re-configure the switch; Operate
a separate “security” network; or manually populate the
NV-ER1816i Receiver hub’s table-entry list for multicast group
addresses. (See page 21.)
Contact NVT for more information.
LAN / WAN
Ethernet
Switch
Embedded
IGMP
Network
Querier
IGMP Query
IGMP Report
Blocked IGMP Report
X
Figure 2 - IGMP Multicast Control
Network
Video
Recorder
Firewall
Cat5
any wire
NV-ET1801
NV-ER1804
NV-ER1808i
NV-ER1816i
or
or
or
Routing Table
Routing Table
Cat5
≤328ft
(≤100m)
IP Camera
IP Camera
IP Camera
IP Camera
NV-ET1804
MULTICAST PACKET SUPPORT
Page 7 of 25
