Re: [OpenSIPS-Devel] [opensips] Add listen interface (socket) checking to db based natping. (#127)
@wdoekes , what about a different approach on this matter - instead of keep filtering per IP each time we want to ping, what about using a server ID and each usrloc should be marked with such ID representing the server which did handle that register ? So, at the end, whatever number of interfaces we have, we do a select/filter based on a numerical ID --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/pull/127#issuecomment-61607251___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] Add listen interface (socket) checking to db based natping. (#127)
That would suit my needs indeed; and make more sense than the awkward query that we do now. Thinking out loud here: where do we get this ID from? Do we add a `server_id` integer parameter to `usrloc`? Or should we generate one automatically? If we use a parameter and default it to `1`, we get current behaviour (backwards compatible), but that means that we don't have a guarantee that the server_id is unique (perhaps we want that constraint later). --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/pull/127#issuecomment-61616955___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] Add listen interface (socket) checking to db based natping. (#127)
@wdoekes , I'm seeing this from a larger perspective - we are working on the specs/description for a cluster module - to ensure registration and call exchange (in a transparent way) between several opensips instances. So, we will define a server ID for each opensips (an ID inside the cluster), in a similar way you in mysql for replication... --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/pull/127#issuecomment-61768489___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] Add listen interface (socket) checking to db based natping. (#127)
For the record. This should probably be improved to handle in-memory contacts as well, since this can now be binary-replicated (right?) 16:28 lirakis bogdan_vs, if there was a smart nat ping ... then i think you could do distributed usrloc out of the box with replication, path headers, and a smart nat ping ... 16:31 wdoekes lirakis: smart nat ping? do you mean: https://github.com/OpenSIPS/opensips/pull/127 ? 16:32 lirakis wdoekes, yes 16:33 lirakis was ... this merged? 16:33 wdoekes no 16:33 lirakis but yeah 16:34 lirakis i mean ... we do this already with our own custom usrloc stuff 16:34 lirakis im just saying for out of the box functionality 16:34 lirakis i think that would be the only thing missing that i can think of 16:34 wdoekes one could poke razvan to get it merged 16:35 lirakis razvan ... poke 16:35 lirakis he he 16:35 wdoekes =) 16:35 lirakis so .. you are actually just changing usrloc to return only local contacts from get_all_u_contacts ? 16:36 lirakis but ... are you actually stlil getting contacts on other servers when you do a lookup ? 16:36 lirakis b/c i would still wan that behavior 16:36 lirakis so you can use path headers to route from an adjecent proxy to the home proxy 16:36 lirakis wdoekes, not sure if im being clear 16:38 wdoekes it's only the get_all that is affected 16:38 wdoekes and then only the db-version 16:38 wdoekes so for your binary replication, we may need to improve the patch 16:39 lirakis ah 16:39 lirakis ok 16:39 wdoekes the get_all is only called from nathelper (afaics) 16:39 lirakis right 16:39 lirakis vs lookup 16:39 wdoekes correct 16:39 lirakis cool 16:40 wdoekes I don't store users in mem, so I didn't need that. but I see how that could be an improvement 16:41 wdoekes (and probably, the get_all_ should be renamed to get_all_local or something) ... 16:41 lirakis but again - im just thinking about generic out of the box functionality --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/pull/127#issuecomment-43891801___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] Add listen interface (socket) checking to db based natping. (#127)
@@ -130,6 +131,18 @@ static int get_all_db_ucontacts(void *buf, int len,
unsigned int flags,
LM_DBG(buf: %p. flags: %d\n, buf, flags);
+ if (sockaddr_list_str.s) {
+ i = snprintf(query_socket, sizeof(query_socket), and socket
in (%.*s),
I can't find the spec itself, but according to all pages that reference the
spec., IN belongs in the core SQL.
Example:
http://www.postgresql.org/docs/7.4/static/features.html
http://developer.mimer.com/standard/features/core-sql-features.tml
In both cases they are listed as core sql. Look for `IN predicate with list of
values`.
---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/pull/127/files#r12183049___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] Add listen interface (socket) checking to db based natping. (#127)
@@ -130,6 +131,18 @@ static int get_all_db_ucontacts(void *buf, int len,
unsigned int flags,
LM_DBG(buf: %p. flags: %d\n, buf, flags);
+ if (sockaddr_list_str.s) {
+ i = snprintf(query_socket, sizeof(query_socket), and socket
in (%.*s),
Is this IN operator compliant with all SQL standards (Postgres, MySQL, etc.)?
Or should we convert it to a standard format like ... AND (socket = IP1 or
socket = IP2 ...)?
---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/pull/127/files#r12153160___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
