Yes. That is exactly what I mean. Perhaps those familiar with the relay code could shed some light? Is the relay multi-home capable presenting NIC 2 address in SDP offer to callee and NIC 1 to caller on SDP answer?
Joegen On Wednesday, 08 September, 2010 11:19 AM, Martin Steinmann wrote: > I think I am assuming that Nic 2 is not reachable from the DMZ as it would > have to go through a firewall. Sipxbridge does have two interfaces, an > external facing one (connecting to NIC 1) and an internal facing one > connecting to NIC 2. RTP relay is done by media relay attached to the proxy > and not part of sipXbridge. This is the same media relay that handles media > anchoring for remote workers. I guess what you are saying is that media > relay would have to bind to both NICs. > --martin > > >> -----Original Message----- >> From: Joegen Baclor [mailto:[email protected]] >> Sent: Tuesday, September 07, 2010 11:15 PM >> To: sipXecs developer discussions >> Cc: Martin Steinmann >> Subject: Re: [sipx-dev] Multi-NIC/Multi-homing support - call for >> discussion >> >> Hi Martin, >> >> IMHO, as I have hinted in some private conversations, I do not have any >> reason to believe that this is not doable right now as it is (assuming >> that both NICS are routable from the DMZ and the internal network that >> is). Are you presuming that NIC 2 is not reachable from the DMZ and >> thus effectively implying multi-homed topology? In this case, since >> the >> bridge needs to act as a gateway between internal and DMZ, then it >> needs >> to bind to both interfaces for RTP sockets. >> >> Joegen >> >> On Wednesday, 08 September, 2010 11:01 AM, Martin Steinmann wrote: >> >>> 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/ >>> >>> > > _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev/
