If you configure kamailio to listen on a multicast address (eg. `224.0.1.75`) it _auto_ selects the interface that joins the multicast group. The selection happens on what the kernel thinks the multicast IP address is active on. This is decided by the kernel route table since you cannot configure a multicast address on your interface. In the default scenario this would mean the default route interface will be selected to join the multicast group. In case you want to select another interface this is possible by altering the route for that particular multicast address to the interface you desire. This is a workable solution but it has the following downsides:
- need to add route manually to specify interface - multicast for 1 specific address only possible on 1 interface
I would like to propose a solution by adding a config parameter to kamailio (eg. `mcast_interface`) which could then be defined before each `listen` directive that is a multicast address. This would allow for selecting an interface per listen socket in the same way as you can specify the amount of workers for an interface. In this scenario there is no need for manually adding a route to specify the interface.
Please let me know if this is a feature that is of interest to kamailio. If so I'd be willing to work on this myself, but somebody else can also do it.
If something isn't clear or needs more explanation don't hesitate to ask.
You are welcome to work and propose a patch (pull request), definitely it will be considered and merged if doesn't break other things -- I think this extra option is useful.
As an alternative to the idea of having a parameter before the listen like with the workers, could be specified inline like the alias, eg:
``` listen=proto:addr:port alias addrx:portx mcast xyz ```
Anyhow, whatever you prefer, it's fine.
Eventually, in the future (if nobody wants to do it right now) we can consider adding another structure-like to group the attributes for a socket and make it more clear where they are applied (so the order doesn't matter that much anymore), something like:
``` socket { listen=proto:addr:port alias addrx:portx workers=4 mcast=xyz } ```
I went with putting `mcast` on a separate line. See #815
I really like the idea of being able to group socket information, perhaps even with a name (like routes) which you then could use as a variable in your script. But I think that makes for a separate issue :-)
Closed #813.
-
Daniel-Constantin Mierla -
Timmo Verlaan