Hi,
We currently use a slightly modified version of the registrar module which works well in our own setup, but I wondered whether it made sense to make available for everyone.
We have distributed registrars with no proxies in front, so registrations are handled directly at the edge by any server (we then rely on DNS for load balancing/failover). All share the same DB/table and when a register is received, we add Path header manually, before saving.
Each server can handle an invite to any subscriber - it simply performs lookup and then relays the request (Path determines through which server to relay). Our custom version of lookup function checks to see whether the received socket in the location record is one of its own and if it is, ignores the Path and continues as if it were not present - i.e. checks for Received, forces outgoing socket etc. The invite is then sent out directly to the subscriber instead of looping to itself first.
Could this be useful to others? Of course, it would be enabled by a parameter which would be set to disabled by default.
Regards,
Charles
Charles Chance writes:
We have distributed registrars with no proxies in front, so registrations are handled directly at the edge by any server (we then rely on DNS for load balancing/failover). All share the same DB/table and when a register is received, we add Path header manually, before saving.
question: why don't you make the system more reliable by each registrar having its own db table?
-- juha
Hi Juha,
Yes, we could use a separate table for each registrar and replicate registrations to all of them. But we still need to add Path to ensure invites etc go via the server each client used to register (due to client NAT). And if that is local to the lookup, it still makes sense to ignore the path as it is itself.
I must admit, it would be better to compare the path IP:Port to the local ones, instead of the socket.
Cheers,
Charles On 14 Sep 2013 05:13, "Juha Heinanen" jh@tutpro.com wrote:
Charles Chance writes:
We have distributed registrars with no proxies in front, so registrations are handled directly at the edge by any server (we then rely on DNS for load balancing/failover). All share the same DB/table and when a register is received, we add Path header manually, before saving.
question: why don't you make the system more reliable by each registrar having its own db table?
-- juha
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Please note, the question here is not how to configure Kamailio - it's already working for us. The question is, would this addition be useful to others, or is our particular configuration unlikely to be used elsewhere?
Cheers,
Charles On 14 Sep 2013 08:29, "Charles Chance" charles.chance@sipcentric.com wrote:
Hi Juha,
Yes, we could use a separate table for each registrar and replicate registrations to all of them. But we still need to add Path to ensure invites etc go via the server each client used to register (due to client NAT). And if that is local to the lookup, it still makes sense to ignore the path as it is itself.
I must admit, it would be better to compare the path IP:Port to the local ones, instead of the socket.
Cheers,
Charles On 14 Sep 2013 05:13, "Juha Heinanen" jh@tutpro.com wrote:
Charles Chance writes:
We have distributed registrars with no proxies in front, so
registrations
are handled directly at the edge by any server (we then rely on DNS for load balancing/failover). All share the same DB/table and when a
register
is received, we add Path header manually, before saving.
question: why don't you make the system more reliable by each registrar having its own db table?
-- juha
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Charles Chance writes:
Yes, we could use a separate table for each registrar and replicate registrations to all of them. But we still need to add Path to ensure invites etc go via the server each client used to register (due to client NAT). And if that is local to the lookup, it still makes sense to ignore the path as it is itself.
load_contacts() automatically prioritizes contacts so that one without path has higher priority. so, no changes are needed to current code.
-- juha
On 9/14/13 8:32 PM, Juha Heinanen wrote:
Charles Chance writes:
Yes, we could use a separate table for each registrar and replicate registrations to all of them. But we still need to add Path to ensure invites etc go via the server each client used to register (due to client NAT). And if that is local to the lookup, it still makes sense to ignore the path as it is itself.
load_contacts() automatically prioritizes contacts so that one without path has higher priority. so, no changes are needed to current code.
From what I understood, all records in location will have a Path header, added with the local IP of the server that handled the REGISTER. So load_contacts() priority on non-path records doesn't help.
The concept could be useful in some cases, maybe the patch should be sent here or on the tracker and if it doesn't add to complexity, can be incorportated and a module option.
Cheers, Daniel
Daniel-Constantin Mierla writes:
From what I understood, all records in location will have a Path header, added with the local IP of the server that handled the REGISTER. So load_contacts() priority on non-path records doesn't help.
my point was that if you have two registrars each having its own location table, then it makes sense to include path only when registration is forwarded from the other registrar. and if it is done like that, load_contacts() always favors contact w/o path.
this was just a discussion. it is ok with me to add whatever to any module that i'm myself not responsible for.
-- juha
On 9/14/13 9:29 PM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
From what I understood, all records in location will have a Path header, added with the local IP of the server that handled the REGISTER. So load_contacts() priority on non-path records doesn't help.
my point was that if you have two registrars each having its own location table, then it makes sense to include path only when registration is forwarded from the other registrar.
ok, I overlooked that part. I thought is shared db.
Cheers, Daniel
and if it is done like that, load_contacts() always favors contact w/o path.
this was just a discussion. it is ok with me to add whatever to any module that i'm myself not responsible for.
-- juha
Juha Heinanen writes:
my point was that if you have two registrars each having its own location table, then it makes sense to include path only when registration is forwarded from the other registrar. and if it is done like that, load_contacts() always favors contact w/o path.
i would also like to add, that what i proposed works fine also when the ua registers with both registrars.
-- juha
Yes, you are right...thank you :)
I guess my reasoning only applies if using shared table, no replication and therefore always adding path.
Charles On 14 Sep 2013 19:32, "Juha Heinanen" jh@tutpro.com wrote:
Charles Chance writes:
Yes, we could use a separate table for each registrar and replicate registrations to all of them. But we still need to add Path to ensure invites etc go via the server each client used to register (due to client NAT). And if that is local to the lookup, it still makes sense to ignore the path as it is itself.
load_contacts() automatically prioritizes contacts so that one without path has higher priority. so, no changes are needed to current code.
-- juha
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
14 sep 2013 kl. 20:32 skrev Juha Heinanen jh@tutpro.com:
Charles Chance writes:
Yes, we could use a separate table for each registrar and replicate registrations to all of them. But we still need to add Path to ensure invites etc go via the server each client used to register (due to client NAT). And if that is local to the lookup, it still makes sense to ignore the path as it is itself.
load_contacts() automatically prioritizes contacts so that one without path has higher priority. so, no changes are needed to current code.
Why?
/O
Olle E. Johansson writes:
load_contacts() automatically prioritizes contacts so that one without path has higher priority. so, no changes are needed to current code.
because in the scheme that i described, local contacts do not have path field set.
-- juha
-
Charles Chance -
Daniel-Constantin Mierla -
Juha Heinanen -
Olle E. Johansson