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/
