On Wed, Sep 8, 2010 at 10:49 AM, Joegen Baclor <[email protected]> wrote:
> Hi Tony, > > inline ... > > > > On 09/08/2010 05:44 PM, Tony Graziano wrote: > > As I recall, there is no code to prevent the proxy to bind to all > interfaces present on a system. This is where the problems begin, because > this WILL affect HA systems. This is the problem with the sipxtacklib code, > and why turning off all other nic's is suggested. > > > > From what I understand from the code, you can bind the proxy to a specific > ip address even if other NICS are active. Giving it and address 0.0.0.0 > will force it to bind to all available interfaces. Can you elaborate how it > breaks HA? > > OK, maybe I remembered something wrong. If it didnt glom onto all the interfaces it wouldnt affect HA. I may have been remembered back a bit farther on that issue. > > > > > Does it sound easier to add a "more robust" SBC application and bind it to > all "other" interfaces except the main sipx interface, and to limit the > "glom'ing" of the sipx services (i.e. proxy, etc.) to the single interface > and configure the SBC from sipxconfig in lieu of sipxbridge? > > If this were the case, I could see sipxrelay as "non-essential" and > sipxbridge becoming sipxsbc to handle the media relay, nat and trunking > capabilities. I can also see where it would not affect HA systems in this > fashion. > > > > Might be easier but scary since a new SBC also results to a rewind in terms > of interoperability testings, new bugs etc. Although I agree 100% that the > idea is the way to go for the long term. I think for now, what Martin > intends is to address the most urgent basic issues such as to 5060/5080 > dillema. I don't have the complete picture yet how this will be done but I > am leaning towards having all routing in the proxy and have the bridge sit > behind it. > > If we are to preserve the current components, what do you think is the best > way to map both the bridge and the proxy to port 5060 in the firewall? > > > I would use two different internal ip addresses for the sbc. One for remote users to be picked up via sipxrelay and the other for trunking, but both using port 5060. > > > On Tue, Sep 7, 2010 at 11:24 PM, Joegen Baclor <[email protected]> wrote: > >> 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/ >> > > > > -- > ====================== > Tony Graziano, Manager > Telephone: 434.984.8430 > sip: [email protected] > Fax: 434.984.8431 > > Email: [email protected] > > LAN/Telephony/Security and Control Systems Helpdesk: > Telephone: 434.984.8426 > sip: [email protected] > Fax: 434.984.8427 > > Helpdesk Contract Customers: > http://www.myitdepartment.net/gethelp/ > > Why do mathematicians always confuse Halloween and Christmas? > Because 31 Oct = 25 Dec. > > > _______________________________________________ > sipx-dev mailing [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-dev/ > > > -- ====================== Tony Graziano, Manager Telephone: 434.984.8430 sip: [email protected] Fax: 434.984.8431 Email: [email protected] LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 sip: [email protected] Fax: 434.984.8427 Helpdesk Contract Customers: http://www.myitdepartment.net/gethelp/ Why do mathematicians always confuse Halloween and Christmas? Because 31 Oct = 25 Dec.
_______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev/
