[OpenSIPS-Users] Two Opensips proxies sharing the same DB

[Henk Hesselink]

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<jpyle at fidelityvoice.com>:
>> Bogdan,
>>
>> I think I've got it now.  Details inline.
>>
>> On 1/20/11 3:44 PM, "Bogdan-Andrei Iancu"<bogdan at 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 at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>