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

[James Lamanna]

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-users at 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<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
>>
>