This is not, unfortunately, an answer to your question. More a question from me.
I would like to know why you want to use Licode for broadcasting. Personally I think that using something like Icecast2 is a much, much more viable solution.
With Icecast2 it is easy to set up a solution with proper load balancing and practically unlimited scalability. An example of a proven technology.
When you are providing a broadcast, then you expect proper ordering of packages and no loss of data. No loss of quality at all (use TCP, of course). But that is not suitable for real-time interaction. In real-time (low-latency) situations you just have to accept lost data and problems with quality (UDP does not promise that your packet reaches the destination in time).
Licode is, IMHO, very good when you are dealing with real-time (low latency) situations. But I would not consider Licode (or any other webrtc-based solution) for broadcasting. The situation is different both in the sense of use cases and the technological constraints.
I have set up quite a few events in which the low-latency use-cases are handled with Licode. The broadcasting situations were handled with Icecast2 (Icecast2 scales very well and is extremely easy to set up). Apparently the streams were converted to suitable formats for broadcasting.
But you should expect over 20 second latency in broadcasting. In many cases the actual latency is at least 60-120 seconds or even more, which is useless for low-latency use cases.
In other words: Licode is very, very good with low-latency use-cases. But I would not consider it a tool for broadcasting (i.e. for situations in which the latency is not a problem).
The aims for using tools like Licode and Icecast2 are quite different, IMHO. Even in the case that the streams are the same (meaning that they have the same content).