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?
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?
On Tue, Sep 7, 2010 at 11:24 PM, Joegen Baclor <[email protected]
<mailto:[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]
<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:[email protected]> [mailto:sipx-dev-
<mailto:sipx-dev->
>>>> [email protected]
<mailto:[email protected]>] On Behalf Of Joegen Baclor
>>>> Sent: Tuesday, September 07, 2010 10:45 PM
>>>> To: [email protected]
<mailto:[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]
<mailto:[email protected]>
>>>> List Archive: http://list.sipfoundry.org/archive/sipx-dev/
>>>>
>>>>
>>> _______________________________________________
>>> sipx-dev mailing list
>>> [email protected] <mailto:[email protected]>
>>> List Archive: http://list.sipfoundry.org/archive/sipx-dev/
>>>
>>>
>
>
_______________________________________________
sipx-dev mailing list
[email protected] <mailto:[email protected]>
List Archive: http://list.sipfoundry.org/archive/sipx-dev/
--
======================
Tony Graziano, Manager
Telephone: 434.984.8430
sip: [email protected]
<mailto:[email protected]>
Fax: 434.984.8431
Email: [email protected] <mailto:[email protected]>
LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: [email protected]
<mailto:[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/
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev/
