Joegen Nice post! I likely will not be of much value, but it sounds like you are trying to solve the generic problem where components of the sipXecs cluster could only be reachable by talking through a particular NIC - I.e. there is no routed connection between them otherwise.
The problem we have here might be easier and might not require solving the generic problem. Our main problem is that there is only one port 5060 on an interface, and therefore sipXproxy and sipXbridge cannot use it both. The typical config would be that sipXbridge connects into the DMZ for SIP trunking services (using NIC 1), and the proxy connects to the corporation's network on the inside using NIC 2. All internal destinations are then reachable through routing form NIC 2 and the other NIC (NIC 1) can be assigned to sipXbridge. Therefore, all we need to do is create the ability for each process to bind to a particular NIC (and only one), and make sipXconfig capable to configure it. The configuration for that is for the most part already in the process specific config files AFAIK. As a step one I would vote for the most simple solution to use the two NICs available on most servers for a config as described above. Make sense? --martin > -----Original Message----- > From: [email protected] [mailto:sipx-dev- > [email protected]] On Behalf Of Joegen Baclor > Sent: Tuesday, September 07, 2010 10:45 PM > To: [email protected] > Subject: [sipx-dev] Multi-NIC/Multi-homing support - call for > discussion > > Hi Everyone, > > First, I would like to thank this community for allowing me to > contribute to such a remarkable piece of open source software. Thank > you for letting me in. > > Now down to the real subject of this mail. I would like to get your > opinion on which is the best approach to make a multi-homed sipX-ecs a > reality. > > The good news is, sipXtacklib already supports multi-nics so the > primary > building blocks are already present. However, multi-NICing is just > half > of the entire puzzle. The real challenge is determining which route > each uac-transaction would take to correctly reach the target. Right > now, the SipUserAgent uses a pre-deduced value when attaching vias to > outgoing requests. Work needs to be done to make the generation of > vias > topology-aware. This would entail the introduction of a new router > code > that mirrors the actual topology of the network in real-time. I am > going to list the three most obvious solution for me as of the moment. > I would love to hear your opinion and input. > > 1. Manually parse the linux routing table (/proc/net/route) > 2. IPRoute2-style using rtnetlink API > 3. Let the user decide using fast but flexible embedded scripting > language > > - The defense for item 1 is that it's really simple and there is no > need to introduce new dependencies to sipXtacklib/sipXportlib > - The defense for item 2 is that rtnetlink could also fetch the > routing > table (already parsed) using kernel level calls and thus is fast and > reliable. On top of this, rtnetlink could also ask the kernel which is > the "best" route to take to reach a particular target without further > analyzing the route table. > > So 1 and 2 are the brute and the suave approach respectively. However > there is a limitation to both. IP routes do not automatically equate > to > SIP routes. A SIP service might be reachable via multiple interfaces > but the remote access list only allows SIP traffic from a particular > interface. In such cases, the deduced "best" route may not be > non-sip-routable. > > Thus, item 3 (let the user decide) gains merit because of the > aforementioned limitation. Scripting allows for a more > flexible/complex > SIP aware routing model. The downside is it will be a bit harder for > the sipXconfig team to support it. Below is a real-life implementation > of how a script (JavaScript) would look like taken from an actual > commercial SBC implementation. > > > if (this.sipMessage.hdrGet("user-agent") == "cool-ua" && > this.sipMessage.getSourceAddress() == "192.168.1.40") > { > this.setInterfaceAddress("192.168.1.28", "5060"); > this.setTargetDomain("192.168.1.20", false); > > this.sipMessage.setFromHostPort(this.sipMessage.getSourceAddress()); > this.setTargetAddress("udp", "192.168.1.20", "5060"); > return true; > } > > > Hoping to get some feedbacks. > > Joegen > > _______________________________________________ > sipx-dev mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-dev/ _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev/
