Sorry guys, I'm kind of lost in here. Can someone elaborate on what is it with the ports + remote workers + ITSPs?
-MM On Thu, Apr 2, 2009 at 3:48 PM, Scott Lawrence <[email protected]> wrote: > On Thu, 2009-04-02 at 13:03 -0500, Tony Graziano 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. > > and... > >> 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. > > They already can be, since they go the proxy directly. > > I don't actually see the value of the dual-address model you describe. > > Addressing is a poor way to tag traffic. > > I very much doubt that any otherwise-good ITSP could not use whatever > port you asked them to use for traffic to the PBX. > > >> 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. > > There's no straightforward way to get HA for NATed remote users without > significant new functionality in the phone. The problem is that the NAT > mapping will only be to the one IP address of the proxy that it uses to > register. One of the things the new NAT support does is ensure that > anything bound for that contact goes through the proxy it is using to > register so that it will work. > > > _______________________________________________ > sipx-dev mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-dev > Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev > _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
