Not finished
Multicast is a mechanism to send a single stream to multiple destinations at once. The network decides where to duplicate packets in order to get them t each destination. Where it is possible a single stream is transmitted. This makes multicast a bandwidth-efficient mechanism for streaming the same content to multiple destinations.
This page explains some considerations for applying multicast for live IP video.
Advantages:
- Bandwidth efficient
- Low latency
Drawbacks:
- Requires support from the network. At least IGMP snooping in small systems, and a whole lot more in large systems
- Difficult to setup in larger networks
- Transport limited to UDP
- Secure streaming not widely supported
- In general not well understood by IT people and software vendors
There seem to be more drawbacks than advantages, but a lot depends on the usecase. With a well-designed network and presence of sufficient IT expertise the drawbacks will not be so prevalent. That's typically the case in higher-end setups. In smaller systems the benefits may not outweigh the drawbacks. A multi-unicast scenario will then be more cost efficient, especially with cameras capable of transmitting a mediastream multiple times efficiently (as they encode it only once).
When does multicast make sense?
- Large systems. When a lot of streams are involved the bandwidth saving will be considerable
- High end systems. These are likely to have the capacity to manage and maintain the network configuration
Multicast groups
Multicast builds on a special range of IP addresses.
Edge side of multicast: IGMP
In small networks, multicast is simple. The only thing involved is Internet Group Management Protocol. Many managed level-2 switches (the ones having an IP address and having their own management pages) come with a feature called 'IGMP snooping'. This means the switch listens to the IGMP announcements of the connected devices and take appropriate action. Switches must have this feature before multicast can be considered. If it doesn't have the snooping function, mandated behaviour is to broadcast the multicast packets on all ports. This is obviously counterproductive.
Network side of multicast: PIM
The common way of managing multicast on networkside is Protocol Independent Multicast. Being not familiar on the network configuration side of things I should express myself prudently. The caveat is in the word 'Independent' as this means it leaves a lot of work to other protocols. A PIM setup requires a carefull tuning of multiple protocols. A deep understanding is required to make the individual bits work in concert. This is the reason multicast can only be done in projects of size where having this expertise can be justified.
An interesting alternative method of managing multicast is Shortest Path Bridging (SPB). It is supported by Extreme Networks, former Avaya, as Fabric Connect. It frees the administrator to think rendez-vous points, sparse or dense configurations etcetera. Though I lack practical experience (edge person), especially for greenfield scenarios I think this is a method to consider to keep thing cost-effective.
Managing multicast groups
RTSP
Always multicast
The term 'Always multicast' is borrowed from the name of the feature on Axis cameras.It refers to a scenario where a source unconditionally multicasts a mediastream, independent of receivers requesting it. As long as there are no listeners the first switch will drop the traffic so the load on the network is negligable. An advantage of this scenario is that a listener/destination doesn't need to know the address of the source. It is not even necessary for the destination to be able to reach the source, adding a certain level of security.
Sounds good, but it's old fashioned. The big drawback is that a source does not know when a new listener joins the group, so it can't take special action like it can when an RTSP negotiation takes place first. The special action would be: insert an I-frame so that the new receiver can immediately start to decode the stream. Always multicast used to work well in MPEG-2 days with short GOPs. The receiver would join the multicast group, receive data and see a decodeable I-frame withing a fraction of a second. For H.264 the situation is more difficult:
- Longer GOP. With a gop of 62 frames and 30 frames per second, it may take more than two seconds before data is received that is decodeable. 'Smart codecs' may dynamically increase the GOP length to several hundreds of frames. When a source is also capable of lowering the framerate when the scene is idle it may take minutes before decoding can commence.
Mitigating this limitation by configuring short GOPs defies the purpose of saving bandwidth. When the number of receivers is limited this may be less efficient compared to a multiple-unicast scenario.
- Absence of picture parameter set (SPS/PPS). A decoder needs this information to be able to process the stream. It obtains this information typically from the SDP or from the first frame in the stream. Some devices by default send this data only once because it is needed only once, it is a waste of bandwidth to repeat it. But then a receiver will not have this information and can't process the data.
To mitigate the receiver must have the SDP data in advance, which is a configuration management nightmare or, much better, SPS/PPS must be repeated with every I-frame. This is a configuration item on the source that needs to done only once.