Experimental SIP trunking support

[lminiero]

This PR adds experimental SIP trunking support to the SIP plugin. It's an effort that I presented at Kamailio World a few months ago:

• Slides: https://www.slideshare.net/slideshow/sip-trunking-in-janus-kamailio-world-2024/267350704
• Video: https://www.youtube.com/watch?v=_e0fWnWWOeY&t=3855s

You can find more information in the presentation, but in a nutshell, it allows you to create a shared stack in the SIP plugin that can establish an IP-based trunk with a SIP proxy. Notice that, at the moment, it doesn't support any form of authentication or encryption: it's just an IP-based pair trunk. My hope is that, by having people test it, more requirements will emerge to improve it and make it more usable.

To create a trunk, you need to do it in the janus.plugin.sip.jcfg configuration file. The PR comes with verbose comments on how to fill that in, but an example is the following:

sip_trunk = {
	local = "0.0.0.0:5090"
	peer = "1.2.3.4:5060"
}

In this case, the SIP plugin will bind to port 5090 for its own side of the trunk, and establish a pair with the provided address in the peer property. As I said, nothing happens when you do that, except that we create a Sofia SIP stack bound at that address, and that we'll only accept incoming messages from the peer address: messages coming from other addresses are all rejected with a 403. The peer address is also configured automatically as outbound proxy, so that all messages we'll send ourselves will go there.

In order to allow users of the plugin to use the trunk, they need to set type: "trunk" when using the register method in the SIP plugin API. This works pretty much as the guest mode does, meaning that no SIP register will actually be sent: unlike guest mode, though, the trunk mode will allow those users to receive incoming calls even if no registration was sent, since the plugin will intercept incoming INVITE messages from the trunk peer. The way the code works right now, we check the username part of the URI they set in the register request: if an incoming INVITE from the trunk peer matches that, we pass the call to that user.

This is it in a nutshell. I've marked the PR as a draft since it's not really complete (is no authentication on the trunk ok, or do we need one? what about matching rules for incoming calls?), and most importantly I've done very little testing with it. If you're interested in this functionality, please test and do provide feedback, so that we can get it to a mergeable status soon.

PS: in the future, I also plan to make the management of trunks more dynamic. At the moment, you can only create one, and only at startup (config file). It may be interesting to have ways to dynamically create more than one using the SIP plugin API. Besides, we probably need ways to locally "authenticate" users of a trunk (locally as in the SIP plugin, and not via SIP), and ways to send push events to external backends when we get incoming calls for addresses that we don't have a user for yet (which would allow for dynamically adding a SIP plugin trunk user only when we get a call for a specific address).