> >> >>> On 4/2/2009 at 1:42 PM, in > > message > <[email protected] > > m>, "Robert > Joly" <[email protected]> wrote: > > > > I'm trying to understand the current method used to send > a register > > > request. > > > > > > What I think i'd like to see long term is a 2nd ip address bound > > > simply to the remote register function, and see the register > > > requests forward to that (private) ip and allow the > traffic between > > > trunking and remote users become better segregated at > some point in > > > the future. I would think that the second address scheme > would also > > > lend itself to being able to blend it into HA more easily. > > > > > > Does this make sense to anyone else? > > > > Let me play it back to test my understanding... You would like for > > sipXecs to have two private IP addresses - one to be used > by users and > > the other to be used by ITSPs, right? If that is the case, > could you > > expand on the value that this arrangement will bring? > > > > Hence all user and trunk traffic can be pointed to the same > public IP address and port. This makes a lot of sense to me, > but maybe just me. Registers forwarded off to a separate > component address so registrations are able to be observered > independently of trunking traffic.
That is what I suspected. The question is then the following. How do you setup your port forwarding rules in your non-SIP-aware NAT/firewall so that the ITSP traffic arriving at 5060 gets routed to the 'sipXbridge private IP' and the user traffic arriving at 5060 gets routed to the 'sipXproxy private IP'? You could do that by making the forwarding rules dependent on the source IP:port but that would require you to configure the public IPs of the ITSPs and all remote workers in your firewall. In most cases, this will not be possible either because the IP addresses may not be determined in advance (someone connecting remotely from a hotel room for example) or because they are not guaranteed to be static. Having said that, it is acknowledged that the general problem you raise is valid and XECS-2432 has been created for it. > > Then I started wondering if this would help bring HA into the > picture for remote users, and well, maybe I should have had > that awful coffee this morning. > > _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
