>> >>> On 4/2/2009 at 2:17 PM, in > message <[email protected] > m>, "Robert Joly" <[email protected]> wrote: >> >>> 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. > > > > >
In my own mind I was envisioning.... public IP sends all traffic for port 5050 and 30000-31000 to relay agent sends it to the appropriate agent depending on its message type. sipx 10.0.0.1 relay agent 10.0.02 itsp trunking agnet 10.0.0.2 remote user registration agent 10.0.0.3 In reality I know that it doesn't work this way now, and that the relay agent and trunking agent are the same, and I'm wondering if it's easier to add a second IP for remote users to accomplish a lot of things later on down the road, etc. It also occurred to me that the remote user will likely show the IP address the firewall (public) when registering, so it makes sense to me that the IP address is somewhat useless unless they are locally connected for any type of visual good vibes. I'm getting ready to try registering a remote user, which has proven to be more difficult than I care it to be. So I thought asking questions would be a good idea. I ask lots of questions, but my 7 year old asked me questions for 2.75 hours straight the other day (non-stop, that girl is good!), so it could be worse. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
