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 <[email protected]> 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" : "[email protected]"}) > { "_id" : "[email protected]", "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:[email protected]:56401" > <sip:[email protected]:56401> } } } > > > db.userlocation.find({ "_id" : "[email protected]"}) > { "_id" : "[email protected]", "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:[email protected]:49396;ob" <sip:[email protected]: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 <[email protected]> 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 <[email protected]> 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 >>> [email protected] >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >> >> _______________________________________________ >> Users mailing >> [email protected]http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> _______________________________________________ >> Users mailing list >> [email protected] >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > > _______________________________________________ > Users mailing > [email protected]http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > _______________________________________________ > Users mailing list > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users >
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
