10 Oct
2005
10 Oct
'05
2:30 p.m.
Hi Klaus,
Klaus Darilion wrote:
Bogdan-Andrei Iancu wrote:
I'm aware of these problems - the idea is to try to reduce their effect,
depending of their specific.
Hi Klaus,
that was a second idea :).
actually you do not have to do anything special to keep the CANCEL in
memory - it will be kept as transaction if you forward it statefully.
what I do not like in this approach is that for each INVITE you have
to search for a potential previous CANCEL - which is quite
consuming... I would prefer an approach with minimum impact on the
performance.
Hi Bogdan!
One one hand we care about fast transaction handling/matching, on the
other hand we have problem with external lookups which take a long
time (db, radius, DNS ...) compared to opensers internal processing.
For example: 4 clients send an INVITE to a domain with a broken
delegation. Thus, all threads are busy doing DNS. Thus, a SIP proxy
which can handle 1000000000 requests per second is oversized in real
life scenarios, were the external processing is the bottleneck (unless
we start 1000000000 threads).
for DNS, for example - try to reduce the timeout on your DNS server;
also we consider having DNS cache for OpenSER - some contribution ;)
Of course I'm happy that openser peforms quite well, but in my
scenarios performance problems are always external. And I really would
like a working INVITE/CANCEL which deals with these problems.
I will keep this is mind (if not, please remind me) and I will try to
fix it after the release ...in a way or another.
regards,
bogdan