Round Robin

Round Robin selection of logical interfaces (see also README, direction section)

The main purpose of this is to load-balance between rtpengine's logical interfaces. The round robin algorithm can be implemented in many ways:

• round robin of call_media -> will bind 2 ports (RTP+RTCP) on IP1 then go to next IP2..
• round robin of streams -> will bind 4 ports (media + other_media) on IP1 then go to next IP2..
• round robin of calls -> will bind 4 * nr_streams ports (audio + video) on IP1 then go to next IP2..

The last solution is implemented because it is easier to debug the bridgeports bindings of a call.

The number of ports needed for this call is calculated by counting how many stream legs (monologue/other_ml) have the direction="round-robin-calls" attribute. Each time __init_interface() is called, the round-robin-calls algorithm checks if needed ports are free on all local interfaces of the next logical interface to be selected. If yes, the logical interface is returned and used. If not, the next logical interface is tried. If no logical interface is found, the behaviour falls back to the defaut behaviour regardless if the ports are free or not.

To apply this behaviour rtpengine needs to receive direction=round-robin-calls attribute.

Main Use Case:

The main use case for this is:

• { ..., "direction": [ "round-robin-calls", "round-robin-calls" ], ... }.

This will load balance the established calls (e.g audio or audio+video):

• for audio calls; audio1 will go to log1, audio2 will go to log2 etc.
• for audio+video calls; audio1 + video1 will go to log1 and audio2 + video2 go to log2

Other Use Cases:

Other possible use cases(one can do this, but the purpose is questionable):

• { ..., "direction": [ "round-robin-calls", "pub1" ], ... }
• { ..., "direction": [ "pub1", "round-robin-calls" ], ... }
• { ..., "direction": [ "round-robin-calls", ], ... }

In the above scenarios the free ports checked for the next logical interface are:

• for audio calls; 2 ports
• for audio+video calls; 4 ports