Hi John,
In this case you use the wrong tool for the job. If the servers do not
need/want to share the contacts, better they should not share the table
neither.
Best regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
OpenSIPS Bootcamp 2017, Houston, US
http://opensips.org/training/OpenSIPS_Bootcamp_2017.html
On 06/07/2017 07:51 PM, John Quick wrote:
Hi Bogdan,
The main reason to want to use the standard location table for both servers is
so we can keep the original database schema.
Keeping to the original schema makes upgrades smoother. Upgrade tools you provide expect
to find one location table, called "location"
To overcome problems, we have now created one location table per site and
therefore had to give the new tables a new name. So when we upgrade, there will
be extra work.
Sorry, but I cannot see how it is a benefit for OpenSIPS to retrieve an
unfiltered list of contacts and have no easy mechanism to filter it. It
probably depends how the multiple OpenSIPS servers are working together - how
they are cooperating. If they are load sharing and every server is identical to
the next, then there may be a benefit although I cannot see immediately how you
overcome the problem that each OpenSIPS server has a unique IP address and that
UA's behind restricted cone NAT will not be contactable except from the IP
address where they registered.
The architecture we have is dual Data Centre - for resilience, not load
sharing; UA's may register once only at each DC; the DC's operate as
Active-Active; each OpenSIPS server is on a different IP address (in fact on
different subnets). The database is a distributed high availability solution
but appears as a single entity to both data centres. Maybe we should be using a
different database for each data centre, but a lot of the data are common (e.g.
user credentials, trusted address list) so admin is much easier with just one
database.
John Quick
Smartvox Limited
-----Original Message-----
From: Bogdan-Andrei Iancu [mailto:bog...@opensips.org]
Sent: 07 June 2017 15:45
To: john.qu...@smartvox.co.uk; 'OpenSIPS users mailling list'
<users@lists.opensips.org>
Subject: Re: [OpenSIPS-Users] Location table - how to use socket
Hi John,
Sorry, my bad, $fs, not $si :)
There is something I mis here - all the downsides you list are actually benefits of a
shared location table :). So, if you want each server to "read" only its own
registered contact, why do you use shared location ?
Best regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
OpenSIPS Bootcamp 2017, Houston, US
http://opensips.org/training/OpenSIPS_Bootcamp_2017.html
On 06/06/2017 08:58 PM, John Quick wrote:
Hi Bogdan,
Surely $si is the IP source address of the request. It would show me where the
INVITE came from, not the socket for the current R-URI wouldn't it?
The main problem with shared location table is reading back and using contacts
that are relevant on the local server. I don't want to read back registrations
that happened on the other server OR if I have to work with a complete list of
all contacts then I need simple way to filter and use them sensibly. Possible
cases were:
- User registered on this server
- User registered on the other server
- User registered on both servers
- User is not registered on either server The lookup() function
returns true for all of the first three cases. You then need to determine how many
branches are there and then check if the socket for the R-URI and for the branch (if
present) matches a local socket - allowing for socket to be tls or udp or, as often
happened, <null> - then remove the non-local contact if present and relay the
INVITE OR decide that the contact was non-local and return 302. Consequently, this
involved a lot of messy code and I never got it working.
Another issue was the limit for maximum contacts. I was using save("location", "fc2") when it was a
single site solution. When we changed to dual site with a shared location table, it had to be changed to
save("location", "fc3") because the save function counts all contact records for that user
irrespective of socket. The relaxation required to allow registration on both servers would also allow two
registrations on one server which I don't want to allow. [btw, fc2 limits to one record per user and fc3 limits to 2 -
curious].
John Quick
Smartvox Limited
-----Original Message-----
From: Bogdan-Andrei Iancu [mailto:bog...@opensips.org]
Sent: 06 June 2017 18:11
To: john.qu...@smartvox.co.uk; 'OpenSIPS users mailling list'
<users@lists.opensips.org>
Subject: Re: [OpenSIPS-Users] Location table - how to use socket
Hi John,
Use $si to read/write the "send socket" associated with the RURI.
Now, the discussion deviated and touched several topics, but trying to understand the
"There were too many problems with sharing one location table for two different
sites" - besides the socket aspect, is there anything else in there ?
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
OpenSIPS Bootcamp 2017, Houston, US
http://opensips.org/training/OpenSIPS_Bootcamp_2017.html
On 06/06/2017 07:19 PM, John Quick wrote:
Hi Bogdan,
The problem could be from setting db_mode to 3. As you said earlier, this is
always required when using a shared location table.
My DB table would have two records - one where the socket is for server A and
the other with the socket for server B.
It is possible that when the lookup() function loads matching contacts into
memory, the first contact has a local socket and the second one has non-local.
My log statement would only print the socket info for the first branch. Perhaps
it should print the info for the main R-URI but I was not sure how to get to
that item of data.
The order that is used to load contacts into memory would be somewhat random -
sometimes it might be the local contact first and sometimes not. I could use Q
to force a consistent load order, but it would still be wrong on one site and
right on the other. I would prefer that there was an option to only load
contacts where the socket was a local one. That would be *much* more useful
than loading the contact and discarding its socket data. Could you add this to
the road map please?
Frankly, this is all a bit academic now. I have changed to use a location table
per site and have also changed db_mode back to 1. There were too many problems
with sharing one location table for two different sites.
So this discussion is only relevant if you and the other developers want to
rationalise the usrloc module so it can be used in the scenario where two
different OpenSIPS servers (both active) can share a single location table.
Perhaps you just need to add a few notes to the documentation to warn users
that this is not a recommended scenario. I am writing a new knowledgebase
article that covers this topic. I will attempt to explain the problems there in
more detail.
John Quick
Smartvox Limited
-----Original Message-----
From: Bogdan-Andrei Iancu [mailto:bog...@opensips.org]
Sent: 06 June 2017 16:51
To: john.qu...@smartvox.co.uk; 'OpenSIPS users mailling list'
<users@lists.opensips.org>
Subject: Re: [OpenSIPS-Users] Location table - how to use socket
John,
I tested with 2.4 (dev branch) having:
modparam("usrloc", "db_mode", 2)
It might be from the DB mode 3.....are you sure that the socket info
you have in DB is local to the OpenSIPS loading the record ?
otherwise the socket info may be discarded when the OpenSIPS is
loading the record in memory (during the lookup(location) )
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
OpenSIPS Bootcamp 2017, Houston, US
http://opensips.org/training/OpenSIPS_Bootcamp_2017.html
On 06/06/2017 05:51 PM, John Quick wrote:
Hi Bogdan,
Thanks for testing that. However, something must be different between your test
and mine. I didn't make this up!
Were you using db_mode=3? Were you using v2.2.x ?
By the way, I have moved on with this problem by creating a location table for each site.
This works well, but I had to add a record to the 'version' table for each new location
table as otherwise OpenSIPS fails during module initialisation with "wrong table
version". It must be pre-scanning the script, looking at the argument passed to the
save and lookup functions - how else could it know the name of the location table during
initialisation.
Another observation, but of little importance: Some records in the old location
table were not deleted when they expired. Does OpenSIPS internally create a
timer task (to clear expired records) at run-time when the save() function is
called? As I say, this is out of curiosity only and is not important.
John Quick
Smartvox Limited
-----Original Message-----
From: Bogdan-Andrei Iancu [mailto:bog...@opensips.org]
Sent: 06 June 2017 15:25
To: john.qu...@smartvox.co.uk; 'OpenSIPS users mailling list'
<users@lists.opensips.org>
Subject: Re: [OpenSIPS-Users] Location table - how to use socket
Hi John,
I just tried your logic and it seems to work. I had 2 phones registered under
super_t...@opensips.org and made a call to that account:
Jun 6 16:20:19 voip opensips_proxy[2584]: test - 1 branches found while
routing INVITE to sip:super_t...@opensips.org Jun 6 16:20:19 voip
opensips_proxy[2584]: test - R3 IN:
Req.type=INVITE
R-URI=sip:super_test@10.0.0.30:59565;rinstance=f5b110f9258cd910;tran
s
p
ort=UDP
Br.cnt=1 Sock[0]=udp:172.16.36.74:5060 Sock[1]=<null>
Call-ID=313439363735383831383130383437-mw5gjx27ee3d
The first registration was uploaded directly into the SIP msg (as
RURI, DURI, etc), while the additional one was pushed as branch (see
the "test
- 1 branches found" log). Printing the Sock[0] seems to provide the correct
value.
Best regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
OpenSIPS Bootcamp 2017, Houston, US
http://opensips.org/training/OpenSIPS_Bootcamp_2017.html
On 05/31/2017 01:01 PM, John Quick wrote:
Hello Bogdan,
Here is the code I used to check $(branch(socket)[N]):
if (lookup("location")) {
set_count("$branch(uri)", "$var(brcnt)");
if ($var(brcnt) > 0) {
# More than one contact - not possible to check socket data
xlog("L_WARN", " R3 IN: Req.type=$rm R-URI=$ru
Br.cnt=$var(brcnt) Sock[0]=$(branch(socket)[0]) Sock[1]=$(branch(socket)[1]) Call-ID=$ci\n");
} else ...
And here is the log file output when I have two registrations on
the same username
R3 IN: Req.type=INVITE R-URI=sip:01NNNNNN@12.34.56.245:5060
Br.cnt=1 Sock[0]=<null> Sock[1]=<null>
Call-ID=41d17a02...@sip1.mysipdomain.com
The records in the location table both have data in the socket field.
This is running on version 2.2.4 of OpenSIPS
John Quick
Smartvox Limited
Tel: 01727-221221
-----Original Message-----
From: Bogdan-Andrei Iancu [mailto:bog...@opensips.org]
Sent: 29 May 2017 11:32
To: john.qu...@smartvox.co.uk; 'OpenSIPS users mailling list'
<users@lists.opensips.org>
Subject: Re: [OpenSIPS-Users] Location table - how to use socket
Hi John,
the only way to share records via DB is to use DB only - the other modes are
using the DB just for restart persistence reason (they do not read from DB at
runtime, only once, at startup). In DB-only mode, all reads and writes (related
to contacts) are done against the DB.
In regards to $(branch(socket)[N]) - do you use it after a
lookup(location) ? are you sure that the N'th branch exists and have a socket ?
You may consider saving some extra attributes next to the contact (
see
http://www.opensips.org/html/docs/modules/2.2.x/registrar.html#idp5
5
6
8
288) to identify the pop/host which produced that record.
Best regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
OpenSIPS Bootcamp 2017, Huston, US
http://opensips.org/training/OpenSIPS_Bootcamp_2017.html
On 05/26/2017 07:38 PM, John Quick wrote:
Hi Bogdan,
Yes. I tried with db_mode=1 and it behaved very strangely so I changed it to
db_mode=3 (DB only).
Also tried $(branch(socket)[N]) to read the socket data within my script, but it
always returns <null>.
I am now thinking it will be necessary to have one location table per site, but
perhaps you could consider adding options in future releases to allow the
lookup function to only select contacts where the socket matches one that this
server is listening on.
John Quick
Smartvox Limited
-----Original Message-----
From: Bogdan-Andrei Iancu [mailto:bog...@opensips.org]
Sent: 26 May 2017 17:30
To: john.qu...@smartvox.co.uk; OpenSIPS users mailling list
<users@lists.opensips.org>
Subject: Re: [OpenSIPS-Users] Location table - how to use socket
Hi John,
I suppose you are using usrloc with DB-only to share registrations between
multiples sites, otherwise the socket filter will not make sense, right ?
Best regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
OpenSIPS Bootcamp 2017, Huston, US
http://opensips.org/training/OpenSIPS_Bootcamp_2017.html
On 05/25/2017 06:16 PM, John Quick wrote:
The socket field in the location table sometimes contains very
useful information such as:
- to see which server received the Registration in a dual site
scenario
- to see if the UA registered over UDP, TCP or TLS
However, there does not seem to be any mechanism for using the
socket information in the USRLOC or REGISTRAR modules.
For example, it is not possible to call lookup and filter for
contacts made on the local server's socket or for contacts that used TLS.
Please could the developers look at options to leverage this
useful data, especially for the lookup function.
Are there any tricks I could employ to achieve the same result.
For example, if I set a branch flag to indicate which site
received this registration would it then be possible to filter
the results returned by lookup and extract the registrations
received at site A while discarding those received at site B?
To give a practical example: Dual site; Shared location table;
User's device is registered at site B; Call arrives at site A so
I want to use 302 redirect to send it over to site B, but I
cannot tell from the results of a lookup whether the registration
was made at A or B even though the data is there in the socket field.
John Quick
Smartvox Limited
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
