Multicasting Surveillance Tutorial

The report says Avigilon doesn't support Multicast but there is settings to enable Multicast in the cameras. This allows redundant recording to multiple servers.

"However, in larger deployments, where a larger number of cameras are viewed by a large number of clients, multicast may be critical. In municipal or corporate command centers, for example, half a dozen clients may be connected 24/7, with additional occasional users. Client usage may spike during critical events, as well."

That bolded sentence is a really big deal, imo - and I don't think most appreciate the significance.

It is a universal truth that in 'most' surveillance applications, multicasting is an unused - and unneeded - option.  Why?  Because there are very few real world security applications where there are large numbers of simultaneous client connections required.

Are there large security applications that require multicasting to facilitate simultaneous client machine requests for video?  absolutely.

But what about those applications that see no value in multicasting for day to day operations - ignoring the aforementioned potential spike?  When the excrement hits the fan, the 'day to day' solution can fail miserably to provide the needed data to a distributed response team. 

We worked on a campus design a few years ago.  The consultant (and perhaps the client's IT department) would not allow multi-casting, stating that the odds were that multiple clients would most likely not need to observe the same camera(s) simultaneously.

We brought forth the same argument, as noted by Undisclosed #1, that, in the event of an active shooter or other emergency situation, all eyes would be on the nearest cameras, possibly resulting in poor or no images to some.  The argument was rejected, and they have been lucky so far.

As mentioned, not every manufacturer supports multicast.

As a multi-cast consumer or multi-cast producer or both?

So four viewers requesting a 2 Mbps stream will only use 2 Mbps of bandwidth, instead of the 8 Mbps used in a unicast network.

Though that is completely true only if the four viewers also plug into the same physical switch.  If some viewers are on different switches that can negate the gain.

For instance, consider 4 different 2Mbps camera streams being distributed to 4 viewers with each viewer on their own switch.

Each switch will see 8Mbps of traffic, regardless of whether it is configured as multicast or unicast.

It would be great to see a table that identifies the capabilities of each manufacturer that supports multicast. As I understand it some only support server to client, some are capable of camera directly to client bypassing servers all together and as Michael pointed out there are others as well. 

What is the impact of firewalls om multicast? Are there special considerations in that regard?

42 comments already, I have to weed through these comments.  But:

1.)  Level 3 switches do not exist but LAYER 3 switches do.  Routers can also perform the necessary function.  No, a L3 switch is NOT a router, some may interchange them but there are differences.

2.) Multicast works at Layer 2 and Layer 3.  IGMP Snooping is run at the L2 level to listen for requests and broadcasters.  At L3, they run PIM, it gets the job done but it's UGLY in larger designs.  WATCH your CPU levels on your L3 switch!  [Warning: Self-Promotion] Really if you get to this level, please call us (Dijkstra Solutions), if done wrong you can melt down networks.

3.) Software can have the function to listen and/or send multicast.  If it can listen then it can view OR record a stream independently of others.  If it can send then it will either send to other (multiple) viewers or recorders.

4.) Check if the software also supports IPv6 Multicast.  For large deployments, this can be very important, although there are work-arounds.

I have been told that some switches perform the multi-casting function better than others, based on whether there is a dedicated processor for the IGMP snooping, or just a software process.  Evidently, large video (data) streams can tax the switch.  Is this true?

IGMP is L2 and usually not the problem, it's L3 and PIM.

PIM is really just ancient and as legacy as spanning tree.  IGMP simply listens for people wanting content or sending content and notifies others.  PIM knows how to send it across VLAN or broadcast networks.

99% of the time PIM is the problem, not IGMP.

Most switches will not have bandwidth issues these days, that is not a 100% rule, on a really busy switch, that is where the bigger vendors can do much better typically.  However, these days it not usually about bandwidth as per design requirement (vs. as required because of a vendor's architecture).

The reason why I say it that way, is because, for example, Cisco Nexus.  They have a FEX switch which is an extension from it's spine.  It needs a master switch connection.  In this design I could kill uplinks because of bandwidth saturation (all switching is done on the master switch, not the FEX.  The FEX are just ports...which is kind of dumb).

I hope I didn't over answer the question too much.

Boys ... this is the best comment stream in a year for me ....  I am learning a ton! Keep it technical and respectful and keep it going !!

rbl

Article should have covered  type of multicast in details i.e how is  the support for audio video metadata for VMS/ Camera

Enough surprise to surprise.
From Japan.

Mitsubishi NVR and camera are pure multicast in Japan.
It was far from every standard.
We are the oldest Genetec distributor in the world. (2001 nDVR OEM by Genetec)
We have built a lot of multicast systems.
1)
Wide area network camera stream is Unicast.
WiFi also Unicast by TCP.
Redirected to Multicast with Omnicast server.
This was a necessity item.
2)
The general all-multicast construction itself does not change much from Unicast.

The difficult one is the L3 / L2 switch.
Maximum multicast group management is 300 cameras in 256 L2.
I do disturbing action.

Unstable even 1000 cameras to 1024 compatible switches.
If you change the manufacturer of the switch, immediate OK

Happy new year.

We Actually have has this set up in place for over 9 years and found many quarks in the process 

Mainly when we change or add solutions or upgrade cameras to newer versions 

added or changed network switch's and Poe switchs

The old with the New creates issues, all solvable , but requires lots of time to troubleshoot and think thru process's  

Started with 3 server's ( EV ) 

40 cameras all 1.3 mpxl ,all ACTI,  split between 3 nvrs with 4 different monitor out puts and multiple view stations or clients to review data and history

as we add new and replace the old it creates its own set of issues and needed upgrades  

very challenging 

splitting the out puts of cameras , changing from Jpeg, To Mpeg outputs, adjusting from variable to fixed out puts and changing from constant to variable record rates 

found that many of the cameras would not play well together and we added 

Vivotech, Panasonic, Arecont, Hikvision to the mix. 

Always challenging to see what , why, how to fix issues created by change or upgrade. 

Still have a few Analog HD or 480 line cameras that still work 

some to factory spec's and some being creative to fix quarky issues , not to spec 

But that s how we keep thing s up so as to go to 3-5 mpxl and still keep the old in place. 

still on Cat 5 e and still running thru high grade Switchs for maximum continuity only now with 65 cameras instead of 25 as in beginning