On Wed, Sep 8, 2010 at 11:09 AM, Tony Graziano <[email protected] > wrote:
> > > 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. > These would either need to be ip aliases or bound to a separate eth interface in the sipx system altogether. I have made this suggestion before but i was poo-poo'ed. > >> >> 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. > > -- ====================== 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/
