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

Mon Jul 29 06:01:50 EDT 2019

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" } } }

> 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" } } }

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20190729/322d157e/attachment-0001.html>