Hi Hank, Soon after I wrote that email I discovered the path module and t_replicate to replicate the REGISTERs with path information to all of the nodes in my cluster. Which allows a call to come in from the PSTN to _any_ node and be routed appropriately. Now my next issue is presence handling (which I just wrote a couple emails about to the list), which I hope I can get working.
-- James On Sat, Jan 29, 2011 at 8:50 PM, Henk Hesselink <opensips-us...@voipro.nl> wrote: > Hi James, > > You might want to look at the nat_traversal module plus the path module. > Run nat_traversal on your customer-facing boxes, it will take care of > NAT including all sorts of corner cases. Pass REGISTER requests to your > internal registrar servers after calling add_path/add_path_received. > On the registrar do save("p0v") and subsequent lookups on any of the > registrars will automatically go to the right NAT box. > > Regards, > > Henk > > > On 29-01-11 22:13, James Lamanna wrote: >> >> Hi Jeff& Bogdan, >> I'm looking into a setup very similar to this as well, essentially I >> want to have a cluster of OpenSIPS servers for registration and then a >> cluster of Asterisk Boxes for all the dialplan handling. >> I have the unfortunate problem that all of my clients are going to be >> behind NAT. >> My main issue I think is going to be dealing with NAT, and I'm looking >> for any ideas here. >> >> My initial idea is this: >> >> - Identify an OpenSIPS server as a "relay" between Asterisk Servers >> and the OpenSIPS Servers. >> - On an incoming call from PSTN/Asterisk, divert the call to the relay >> to lookup which OpenSIPS server the callee is registered on. >> - Redirect the INVITE to this OpenSIPS server, so that the call can be >> send back appropriately through NAT. >> >> That seems reasonable, however, what's the best way to lookup the >> socket column to determine which server the callee is registed on? (or >> is there another way) >> >> Thanks. >> >> -- James >> >> >> 2011/1/20 Jeff Pyle<jp...@fidelityvoice.com>: >>> >>> Bogdan, >>> >>> I think I've got it now. Details inline. >>> >>> On 1/20/11 3:44 PM, "Bogdan-Andrei Iancu"<bog...@opensips.org> wrote: >>> >>>> Jeff Pyle wrote: >>>>>>> >>>>>>> We're looking to add a second Opensips instance on a separate server >>>>>>> for failover. Or, from an operational perspective, it could be >>>>>>> described as "active-active" since both will be available at any one >>>>>>> time. We'll control the traffic flow to the proxies with the SRV >>>>>>> records used by the clients. >>>>>>> >>>>>>> Looking through the db tables used, it seems there may be some >>>>>>> conflict with the location and dialog tables. >>>>>>> >>>>>>> The usrloc module clearly saves the local socket used during the >>>>>>> registration. Is there a way to tell Opensips 1.6 to ignore this when >>>>>>> loading the record? >>>>>>> >>>>>> socket;s are discarded at load time if not local. >>>>>> >>>>> >>>>> I run db_mode=3 to keep everything current in the db. The performance >>>>> is >>>>> acceptable (MySQL cluster helps). If I understand you correctly: on a >>>>> shared table, if I save() a registration on Proxy A, but then load() it >>>>> into Proxy B, Proxy B will ignore it since the socket is non-local. >>>> >>>> the socket is ignored, not the record - the record will be used, but the >>>> socket info discarded >>> >>> Ah ha! So it will work on a shared table, and the default socket of >>> "Proxy B" will be used in the scenario I described. Excellent. >>> >>>> >>>>> Any >>>>> way to work around that within Opensips itself? If I ran separate >>>>> location tables on each, I might be able to work something up with >>>>> MySQL >>>>> triggers to push a saved registration from one table to the other at >>>>> save()-time, changing the socket field as it goes. That's a bit more >>>>> hackery than I was hoping to have to implement. >>>>> >>>>> >>>>>>> That way, either proxy can use records saved by either proxy. A force >>>>>>> socket option perhaps to the local IP? Clients are all public IPs >>>>>>> no >>>>>>> NAT. >>>>>>> >>>>>> depends on what db_mode you use for usrloc - if you use a DB mode >>>>>> involving caching, the DB is read only at startup (otherwise, at >>>>>> runtime, it is just written), so data will not be shared at all. Of >>>>>> course you completely disable the usrloc caching via DB_ONLY db_mode, >>>>>> but the performance penalty is high - maybe you should consider >>>>>> register >>>>>> replication at SIP level. >>>>>> >>>>> >>>>> Replication at the SIP level. That is, have the SIP client register >>>>> with >>>>> both proxies at once? >>>>> >>>> yes. UAC registers with P1 and P1 replicates to P2 (see the >>>> t_replicate() function in TM module). But again, this makes sense only >>>> if using cache for usrloc >>> >>> Indeed. I see now. Thanks. >>> >>> >>> - Jeff >>> >>> >>>> >>>> >>>> Regards, >>>> Bogdan >>>> >>>> -- >>>> Bogdan-Andrei Iancu >>>> OpenSIPS Event - expo, conf, social, bootcamp >>>> 2 - 4 February 2011, ITExpo, Miami, USA >>>> OpenSIPS solutions and "know-how" >>>> >>>> >>>> _______________________________________________ >>>> Users mailing list >>>> Users@lists.opensips.org >>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> _______________________________________________ >>> Users mailing list >>> Users@lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >> >> _______________________________________________ >> Users mailing list >> Users@lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > _______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users