[OpenSIPS-Users] need some help using opensips 3.0 cluster module .

Tue Jul 30 02:57:39 EDT 2019

I will provide full DEBUG logs for dialing "sip3" . Before that I have a
query . May be its silly .

When we are saying federated clustering , it means every node has their own
data in the memory and the meta data in the cache db .
So when call comes to 1 node then it routes the call to the appropriate
node through which the number get registered seeing the metadata from the
cacheDB .   Till now this is understood .

When we say "restart_persistency : sync_from_cluster" . How this will work
with federated clustering ?

 If I am not wrong , then to achieve this I have to run the cluster with HA
.  As for my understanding without HA , restart_persistency is not possible
in federated clustering . Do let me know if I am wrong .

Rest of the two model "full_charing" and "full_sharing_cachedb"
restart_persistency is achieved as in earlier case the memory of each node
is synced with each other and in the latter case the data in common cacheDB
.

*Thanks & Regards*
*Sasmita Panda*
*Senior Network Testing and Software Engineer*
*3CLogic , ph:07827611765*

On Mon, Jul 29, 2019 at 4:30 PM Liviu Chircu <liviu at opensips.org> wrote:

> Can you provide full DEBUG level logs on the server while you are dialing
> "sip3"?  Thanks!
>
> Liviu Chircu
> OpenSIPS Developerhttp://www.opensips-solutions.com
>
> On 29.07.2019 13:01, Sasmita Panda wrote:
>
> Thank you Liviu ,
>
> I got your explanation .  fullsharing and fullsharing_cachedb , these two
> works when there is no NAT between the user and opensips node .  This is
> clear now .
>
> I am facing another problem . May be I am doing any silly mistake .
>
> > db.userlocation.find({ "_id" : "sip3 at opensips-local.com"})
> { "_id" : "sip3 at opensips-local.com", "aorhash" : 101148538, "contacts" :
> { "c2lwOnNpcDNAMTk" : { "attr" : null, "sip_instance" : null, "methods" :
> 5888, "sock" : "udp:192.168.0.1:5508", "path" : null, "received" : null,
> "cflags" : "", "last_mod" : NumberLong(1564393280), "ua" : "WebAstra",
> "flags" : 0, "cseq" : 34914, "callid" : "ad275697703", "q" : 100, "expires"
> : 1564393580, "contact" : "sip:sip3 at 192.168.0.x:56401"
> <sip:sip3 at 192.168.0.x:56401> } } }
>
> > db.userlocation.find({ "_id" : "5656 at opensips-local.com"})
> { "_id" : "5656 at opensips-local.com", "aorhash" : 1015579193, "contacts" :
> { "c2lwOjU2NTZAMT" : { "attr" : null, "sip_instance" : null, "methods" :
> 8063, "sock" : "udp:192.168.0.2:5508", "path" : null, "received" : null,
> "cflags" : "", "last_mod" : NumberLong(1564392892), "ua" :
> "MicroSIP/3.15.10", "flags" : 0, "cseq" : 29098, "callid" :
> "5355813986f94a2", "q" : -1, "expires" : 1564393192, "contact" :
> "sip:5656 at 192.168.0.x:49396;ob" <sip:5656 at 192.168.0.x:49396;ob> } } }
>
> I have 2 user sip3 , 5656  . The contact exists in the cachedb also . But
> when I am dialing 5656 (configure in a softphone )call goes to that user .
> But when I am dialing sip3 (username of 1 agent)  then opensips gives "404
> Not Found" .
> Why so ? Both the contact in the cache looks similar . Still why call wont
> go to sip3 .  In other mode of clustering also this thing happens . What
> mistake  am I doing ?
>
>
>
> *Thanks & Regards*
> *Sasmita Panda*
> *Senior Network Testing and Software Engineer*
> *3CLogic , ph:07827611765*
>
>
> On Thu, Jul 25, 2019 at 4:03 PM Liviu Chircu <liviu at opensips.org> wrote:
>
>> Hi Sasmita,
>>
>> As I have written with bold font in the docs of each cluster parameter:
>>
>> *This parameter will get overridden if either working_mode_preset
>> <https://opensips.org/html/docs/modules/3.0.x/usrloc.html#param_working_mode_preset> or db_mode
>> <https://opensips.org/html/docs/modules/3.0.x/usrloc.html#param_db_mode> is
>> set.*
>>
>> If you want some low-level configuration for your usrloc cluster (and not
>> the defaults),
>> do not set the "working_mode_preset".  It's job is to make it easy to get
>> everything
>> working.
>>
>> Regarding 2): the default of "full-sharing-cluster" is to sync from
>> cluster.  That's why
>> you get no data in MySQL.  Just remove "working_mode_preset", and change
>> the persistency
>> to "sync-from-sql", so it starts writing the data over there.
>>
>> An architecture comment regarding 2): you are doing full sharing (any
>> node should be able
>> to take over any contact), so make sure your network topology supports
>> this.  A
>> front-end SIP entity that's balancing traffic to this cluster + SIP path
>> headers is needed
>> here before it can logically work, otherwise you'll run into NAT issues
>> (only the home server
>> will be able to route back to the phone, rather than any node which has
>> the data)
>>
>> Regarding 3): same architectural issue as in 2).  You are attempting to
>> builkd a homogeneous cluster,
>> yet this is not true, because of all sort of NAT limitations, restraining
>> traffic to be only
>> sent from a certain node at a time.
>>
>> Conclusion:  we didn't make these multiple modes just for fun, each of
>> them serves its purpose :)
>> And I agree that for your current needs, it seems like the "federated"
>> clustering is the way to go.
>>
>> Best regards,
>>
>> Liviu Chircu
>> OpenSIPS Developerhttp://www.opensips-solutions.com
>>
>> On 25.07.2019 13:05, Sasmita Panda wrote:
>>
>> I need some clarification on cluster_mode and working_mode_preset
>> parameter .
>>
>> modparam("usrloc", "location_cluster", 1)
>> modparam("usrloc", "working_mode_preset", "federation-cachedb-cluster")
>> modparam("usrloc", "cluster_mode", "federation-cachedb")
>> modparam("usrloc", "restart_persistency", "sync-from-cluster")
>> *1. metadata in mongoDB and exact AOR in opensips memory through which
>> user is registered  .  call work fine even when both registered through
>> different node .*
>>
>> modparam("usrloc", "working_mode_preset", "full-sharing-cluster")
>> modparam("usrloc", "cluster_mode", "full-sharing")
>> modparam("usrloc", "restart_persistency", "sync-from-cluster")
>> *2. no metadata in mongoDB . AOR of user in opensips memory oly and
>> synced with each node . So call wont work when 2 user register through
>> different node . *
>>
>> modparam("usrloc", "working_mode_preset", "full-sharing-cachedb-cluster")
>> modparam("usrloc", "cluster_mode", "full-sharing-cachedb")
>> *3. exact AOR in mongoDB . nothing exist in the opensips memory . This
>> even wont work when both user registered through different node . *
>>
>> I was assuming things will work fine in every condition . but its not
>> working . Am I missing anything in the config so that its not working for
>> me in 2nd and 3rd scenario ?
>>
>> In any of above case the data is not getting saved in the mysql DB . I
>> think it wont even get saved in mysql DB . when we use working_mode_preset
>> we cant use db_mode .
>>
>> I think the 1st option is only preferable .  Is the 2nd and 3rd option
>> has this limitations ? Or I have to add something in the config as well to
>> make this work ?
>>
>>
>>
>> *Thanks & Regards*
>> *Sasmita Panda*
>> *Senior Network Testing and Software Engineer*
>> *3CLogic , ph:07827611765*
>>
>>
>> On Wed, Jul 24, 2019 at 6:32 PM Liviu Chircu <liviu at opensips.org> wrote:
>>
>>> On 24.07.2019 15:33, Sasmita Panda wrote:
>>>
>>> Questions :
>>> 1. In user location of mongo db , it saves the data of the user with the
>>> node IP . Its not the actual AOR of the user . Where does the actual AOR
>>> get saved ? Is that saved in the memory of opensips node only?
>>>
>>> Correct: the MongoDB only holds metadata, showing where the user is
>>> reachable from to all nodes.  The actual AoR is saved
>>> in OpenSIPS memory, which is then sync'ed to the local MySQL "location"
>>> table, for restart persistency purposes.  See
>>> the restart_persistency [1] modparam for more details.
>>>
>>>  2. As the cluster info is in the mysql DB  , If 1 node will get down ,
>>> then I have to update the DB immediately and restart the service ? OR that
>>> node will be disabled automatically no need of service restart ?
>>>
>>> No need to edit anything.  The cluster detects when a node is down and
>>> acts accordingly.
>>> The cluster nodes will keep sending "probing" pings, to detect when it
>>> comes back online.
>>>
>>> Regards,
>>> [1]:
>>> https://opensips.org/html/docs/modules/3.0.x/usrloc.html#param_restart_persistency
>>>
>>> Liviu Chircu
>>> OpenSIPS Developerhttp://www.opensips-solutions.com
>>>
>>>
>>>
>>> <https://opensips.org/html/docs/modules/3.0.x/usrloc.html#param_restart_persistency>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>
>> _______________________________________________
>> Users mailing listUsers at lists.opensips.orghttp://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 listUsers at lists.opensips.orghttp://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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20190730/a3d43088/attachment-0001.html>