Hi Andy! Another problem: nathelper uses the in memory location table to ping natted clients. Thus, also nathelper would have to query the database and we need a process to watch the expires and delete outdated entries. regards, klaus Greger V. Teigre wrote: > Hi Andreas, > You are probably one of the people on the list with the most > experience with replication. AFAIK, you are correct on all > statements below. I assume you have SERs on different locations > since TCP connect timeout is a problem? > But I'm not sure why removing the cache would help you?! Unless > you want to move to a cluster or DB layer replication? > > IMHO, there are only two valid paths for replication in SER: Either > develop a SIP-layer replication with guaranteed deliveries, queue, > non-blocking etc (which ends up being proprietary SER) or patch up > SER to better be able to handle DB-based replication. > I lean towards DB-based replication. Two prominent things that must > be handled: Storing the Path information for proper routing of > messages to UAs behind NAT and a cache that checks the DB if > location is not found in memory. > > I would be very interested in patches for this in the experimental > CVS module ;-) > > g-) > > Andreas Granig wrote: > >> Hi all, >> >> we use DNSSRV balancing and forward_tcp() to replicate registrations >> from one SER to the other SERs in the system. >> >> Now when one machine completely crashes, all other SER processes on >> all other machines hang when processing a REGISTER until tcp-connect >> times out, leading to a system load of ~16 per machine assuming 16 >> child processes per SER, and no other messages can be processed. >> >> I understand that replicating using UDP would solve this issue, but >> then replicated registrations get lost every now and then because of >> unreliable transmission, and as far as I found out t_replicate() can >> only be used for replicating to *one* other SER. >> >> This really gets me thinking about patching out the internal >> location cache and lookup every location from memory, because this >> additional lookup really doesn't hurt because of ~10 other DB >> queries per call. IMHO in systems with more than two SERs this cache is >> just a big >> pain. Andy >> >> _______________________________________________ >> Serusers mailing list >> serusers(a)lists.iptel.org >> http://lists.iptel.org/mailman/listinfo/serusers > > > _______________________________________________ > Serusers mailing list > serusers(a)lists.iptel.org > http://lists.iptel.org/mailman/listinfo/serusers

For me (and I think a lot of other people, like Paul, who mentioned it too in the above thread) the performance won due to the cache lookup is so minimal in combination with my 10-15 other mysql queries and 1-2 enum queries per call, that I really don't care, especially when thinking about the advantages of a consistend location table in the backend DB:

Well, I have to do some uri mangling depending on the From-header and I use quiet a few modules which rely on a database backend (group, lcr, some own, just to name a few) so I don't think it makes sense to switch to radius (please correct me if I'm wrong).

Juha Heinanen wrote: I just came across this posting from you (well, a little bit outdated) while digging in Path header documentation, where you argue the same way I did (that one more additional query doesn't matter): http://www1.ietf.org/mail-archive/web/sip/current/msg04087.html Now you say that this all can be done using radius. I don't know much of radius, but looking at auth_radius and uri_radius modules I just see the xxx_authorize() and radius_does_uri_exists() methods and don't see a way how these could help me (except writing a own modules for authentication which stores the additional attributes in avp which I could query subsequently). Beside that the URI could be altered by some kind of call-forwarding-lookups after some basic checks (call barring and such), where checks against this rewritten URI have to be made again, which requires additional queries. Are you willing to share your experience doing this things with radius? Thanks, Andy _______________________________________________ Serusers mailing list serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

Klaus Darilion writes: you could also return these from radius as results of authorize or does_uri_exists checks.

So theoretically one could also return the contacts of the R-URI in radius_does_uri_exist() without the need of modifying the registrar module (ignoring nathelper module for now)? Then there would be no performance impact when loading the contacts from DB for each initial request...

I just came across this posting from you (well, a little bit outdated) while digging in Path header documentation, where you argue the same way I did (that one more additional query doesn't matter): http://www1.ietf.org/mail-archive/web/sip/current/msg04087.html

Now you say that this all can be done using radius. I don't know much of radius, but looking at auth_radius and uri_radius modules I just see the xxx_authorize() and radius_does_uri_exists() methods and don't see a way how these could help me (except writing a own modules for authentication which stores the additional attributes in avp which I could query subsequently).

Beside that the URI could be altered by some kind of call-forwarding-lookups after some basic checks (call barring and such), where checks against this rewritten URI have to be made again, which requires additional queries.

Are you willing to share your experience doing this things with radius?

I see your point. However, SER has many different uses and many different deployment scenarios. In some scenarios the focus is on high through-put of 20K users (who are divided across registrars), DNS SRV is used, and Linux HA is used for failover. Relying on a database lookup for every single lookup("location") will reduce performance quite a lot.

Greger, Klaus, Interesting thoughts. I still don't have the overall overview of the cache and where exactly it is used, but I already thought this won't be that easy. However, I'll start writing my diploma thesis the next weeks, and it will target SIP clusters using SER, because there's rather few work done which is available for the public. The basic idea is to use one SER pair (let's say sip1.foo.bar) as some kind of session border controller secured with some failover protocol (carp/vrrp/...) which does the NAT ping and SIP balancing stuff. When this border proxy reaches it's max. capacity, you can just add another pair (sip2.foo.bar) and propagate it to new customers.

Behind that border proxy you can dynamically add/remove the proxies which do the routing. They all have a database cluster behind them which they use for location lookup and other stuff. After experimenting a lot with SIP replication I think it's best to delegate this to the DB system where a lot of work is done in this area for years now.

I'm fully aware that all this sounds much easier than it is, but IMHO this is the way to go, because it's the only solution I can think of which scales and is also able to handle NAT. Well, we'll see where this all leads us (or me) to ;o) Andy

Klaus Darilion wrote: Right, and this is also a reason why I want to go for a single location table inside a DB cluster instead of using the cache. But I'll have to lookup the discussion with Jan about the new cache pointed out by Greger first. I currently favour the Path header over rewriting the Contact, because that's what the Path header is designed for, isn't it? (haven't fully read the RFC yet). Andy