13 Sep
2013
13 Sep
'13
4:25 p.m.
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
--
www.sipcentric.com
Follow us on twitter @sipcentric <http://twitter.com/sipcentric>
Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered
office: Unit 10 iBIC, Birmingham Science Park, Holt Court South, Birmingham
B7 4EJ.
14 Sep
14 Sep
12:13 a.m.
New subject: Registrar lookup function - check for local socket before path
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
3:29 a.m.
New subject: Registrar lookup function - check for local socket before path
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(a)tutpro.com> wrote:
Charles Chance writes:
--
www.sipcentric.com
Follow us on twitter @sipcentric <http://twitter.com/sipcentric>
Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered
office: Unit 10 iBIC, Birmingham Science Park, Holt Court South, Birmingham
B7 4EJ.
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
3:43 a.m.
New subject: Registrar lookup function - check for local socket before path
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(a)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(a)tutpro.com> wrote:
--
www.sipcentric.com
Follow us on twitter @sipcentric <http://twitter.com/sipcentric>
Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered
office: Unit 10 iBIC, Birmingham Science Park, Holt Court South, Birmingham
B7 4EJ.
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
2:32 p.m.
New subject: Registrar lookup function - check for local socket before path
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
3:19 p.m.
New subject: Registrar lookup function - check for local socket before path
On 9/14/13 8:32 PM, Juha Heinanen wrote:
Charles Chance 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.
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 - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Trainings - Berlin, Oct 21-24; Miami, Nov 11-13, 2013
- more details about Kamailio trainings at http://www.asipto.com -
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.
3:29 p.m.
New subject: Registrar lookup function - check for local socket before path
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
3:31 p.m.
New subject: Registrar lookup function - check for local socket before path
On 9/14/13 9:29 PM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
ok, I overlooked that part. I
thought is shared db.
Cheers,
Daniel
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
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Trainings - Berlin, Oct 21-24; Miami, Nov 11-13, 2013
- more details about Kamailio trainings at http://www.asipto.com -
3:34 p.m.
New subject: Registrar lookup function - check for local socket before path
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
3:19 p.m.
New subject: Registrar lookup function - check for local socket before path
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(a)tutpro.com> wrote:
Charles Chance writes:
--
www.sipcentric.com
Follow us on twitter @sipcentric <http://twitter.com/sipcentric>
Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered
office: Unit 10 iBIC, Birmingham Science Park, Holt Court South, Birmingham
B7 4EJ.
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
15 Sep
15 Sep
3:33 a.m.
New subject: Registrar lookup function - check for local socket before path
14 sep 2013 kl. 20:32 skrev Juha Heinanen <jh(a)tutpro.com>om>:
Charles Chance writes:
Why?
/O
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.
4:15 a.m.
New subject: Registrar lookup function - check for local socket before path
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
3937
days inactive
3939
days old
11 comments
4 participants
participants (4)
-
Charles Chance -
Daniel-Constantin Mierla -
Juha Heinanen -
Olle E. Johansson