ricardo,
in situation where you see higher priority valued gateway group selected first, do you know if the lower priority valued group would be used if none of the gateways in the higher priority valued gateway group can serve the request? if it is used, then both exist in the hash table. the list in the hash table is sorted by prefix length and priority.
-- juha
Hello Juha. I was doing a few more tests and a more weird thing happened. I was trying to replicate the problem with another prefix, and was using the "id's" 132 and 133, correlative, however the problem persists. Maybe I'm missing something in all this scenario. If I have more than 130 routes in the lcr table do need to set something else? Maybe the lcr_hash_size?? By the way.. I'm using the phpmyadmin module to make the changes...
Regards, Ricardo.-
-----Mensaje original----- De: users-bounces@lists.kamailio.org [mailto:users-bounces@lists.kamailio.org] En nombre de Juha Heinanen Enviado el: jueves, 22 de octubre de 2009 8:17 Para: users@lists.kamailio.org Asunto: [Kamailio-Users] LCR problem with "id" column and match priorities
ricardo,
in situation where you see higher priority valued gateway group selected first, do you know if the lower priority valued group would be used if none of the gateways in the higher priority valued gateway group can serve the request? if it is used, then both exist in the hash table. the list in the hash table is sorted by prefix length and priority.
-- juha
_______________________________________________ Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
Ricardo Martinez writes:
I was trying to replicate the problem with another prefix, and was using the "id's" 132 and 133, correlative, however the problem persists.
id numbers should not have anything to do with this, because nowhere in the module is id column used. the only thing that might matter is the order in which the records are returned from database.
if you have more than 128 routes, it would be advisable to increase the size of the lcr hash table. you can do that by changing the value of constant
#define DEF_LCR_HASH_SIZE 128
in lcr_mod.c
in your case, you could use 256 instead of 128.
-- juha
Juha. Can i change the lcr_has_size from the configuration file with the parameter?
modparam("lcr", "lcr_hash_size", 1024)
Another thing. Looking at the lcr_mod.c file there is a parameter called MAX_NO_OF_GWS defined as follows :
#define MAX_NO_OF_GWS 128
Can I increase this value too? Maybe 256 ?
Thanks, Ricardo.-
-----Mensaje original----- De: Juha Heinanen [mailto:jh@tutpro.com] Enviado el: jueves, 22 de octubre de 2009 12:41 Para: Ricardo Martinez CC: users@lists.kamailio.org Asunto: RE: [Kamailio-Users] LCR problem with "id" column and match priorities
Ricardo Martinez writes:
I was trying to replicate the problem with another prefix, and was
using
the "id's" 132 and 133, correlative, however the problem persists.
id numbers should not have anything to do with this, because nowhere in the module is id column used. the only thing that might matter is the order in which the records are returned from database.
Maybe I'm missing something in all this scenario. If I have more
than
130 routes in the lcr table do need to set something else? Maybe the lcr_hash_size??
if you have more than 128 routes, it would be advisable to increase the size of the lcr hash table. you can do that by changing the value of constant
#define DEF_LCR_HASH_SIZE 128
in lcr_mod.c
in your case, you could use 256 instead of 128.
-- juha
I modified the MAX_NO_OF_GWS to 256 And the lcr_has_size to 256 and I'm still have the problem. Do you have the chance to reproduce the problem with kamailio 1.5.2 ?
Ricardo.-
-----Mensaje original----- De: Juha Heinanen [mailto:jh@tutpro.com] Enviado el: jueves, 22 de octubre de 2009 13:14 Para: Ricardo Martinez CC: users@lists.kamailio.org Asunto: RE: [Kamailio-Users] LCR problem with "id" column and match priorities
Ricardo Martinez writes:
yes, you can do that.
Another thing. Looking at the lcr_mod.c file there is a parameter called
MAX_NO_OF_GWS
yes, you can increase that too, but there is no config variable for it. so you need to recompile the module.
-- juha
Ricardo Martinez writes:
i just tried with latest 1.5 version and priorities worked fine. i'm thus unable to reproduce your problem. either you need to add more debugging into the source or email me your gw and lcr tables.
-- juha
El Jueves, 22 de Octubre de 2009, Juha Heinanen escribió:
Hi Juha, as this limitation is not present in the module documentation, and the module doesn't notify it when starting, it could create serious issues if an admin adds more than 128 gateways and he doesn't inspect the module source (really should he do that to realize of this limitation?).
So I propose two things:
1) Add this information to the module documentation in a clear way.
2) Add a check during module startup. The module could perform a "SELET COUNT(*) FROM gw" and raise an error if the result is greater than MAX_NO_OF_GWS.
Regards.
Hi all,
I'm working on improving my TCP support and go some issue related to TCP connections and lifetime/persistence.
1-> I'm able to have kamailio to keep opened the TCP connection by sending CRLFCRLF keepalive within my application: this solve the issue.
2-> With (or without) SO_KEEPALIVE option, kamailio discard/close the connection 50 seconds after my intial SIP message and 30 seconds after my last SIP message. My registration is using 500 seconds and I got default lifetime paratemer, which is 120 in the tcp_main.c code.
My problem is that I'm supposed to send CRLFCRLF with a frequency advised between 95 seconds and 120 seconds (outbound draft keep alive). However, kamailio has already closed the connection and it only works for lower value.
Did I made a mistake somewhere...
-Note that for mobile device, the interval is supposed to be between 840 and 672 seconds.-
Tks for your help,
Aymeric MOIZARD / ANTISIP amsip - http://www.antisip.com osip2 - http://www.osip.org eXosip2 - http://savannah.nongnu.org/projects/exosip/
El Viernes, 23 de Octubre de 2009, Aymeric Moizard escribió:
Are you doing that in Kamailio's TM module? Please take into account that for Kamailio next version SIP-Router TM module will be used, which has received LOT of love for TCP (i.e: non blocking).
On Fri, 23 Oct 2009, Iñaki Baz Castillo wrote:
Sorry that I missed to put the version of kamailio: I'm using branch 1.5 svnversion gives 5868M ChangeLog last line is: ===================== 2009-04-29 Kamailio v1.5.1 released =====================
Seems like you are misunderstooding me: I'm working on my SIP stacks against kamailio with no change. I'm not working "on" the tm module.
Tks, Aymeric MOIZARD / ANTISIP amsip - http://www.antisip.com osip2 - http://www.osip.org eXosip2 - http://savannah.nongnu.org/projects/exosip/
Hi Aymeric!
Kamailio does not support SIP outbound. It should close TCP connection after the timeout. The timeout can be specified with http://www.kamailio.org/dokuwiki/doku.php/core-cookbook:1.5.x#tcp_connection...
So, do I get it right that this does not work (TCP connection closed after 50 seconds by Kamailio although the default value is 120 seconds)?
(For outbound support probably the default value should be increased).
Further, usually the lifetime should be extended to the value of the registration expiration. This can be done by using http://www.kamailio.org/docs/modules/1.5.x/registrar.html#id2477171
regards klaus
Aymeric Moizard schrieb:
On Fri, 23 Oct 2009, Klaus Darilion wrote:
Hi Aymeric!
Kamailio does not support SIP outbound.
No issue there.
That's right. I got feedback from other where it's behaving well: lifetime is 120.
(For outbound support probably the default value should be increased).
It shouldn't! This is a correct value that comply with 95 to 120sec from the outbound draft for TCP.
I understood this. I wish to solve the issue and make sure there is no bug in kamailio. ;)
So the question is: kamailio is setup to have lifetime=120 but is closing my connection much earlier: 50 seconds after the connection was made and 30seconds after the last SIP message.
Aymeric
Some additionnal information:
I tried several value for tcp_connection_lifetime!
tcp_connection_lifetime = 120 -> close TCP conn after 50 seconds tcp_connection_lifetime = 300 -> close TCP conn after 90 seconds tcp_connection_lifetime = 600 -> close TCP conn after 160 seconds
Do I have "tick" issue? Any idea?
I think I'm close to find either a bug or an issue with my kernel?
I got a timer running a route[] for statistics computation, in case that would change something?
I'm using rtimer module: could this have an impact?
Aymeric MOIZARD / ANTISIP amsip - http://www.antisip.com osip2 - http://www.osip.org eXosip2 - http://savannah.nongnu.org/projects/exosip/
On Fri, 23 Oct 2009, Klaus Darilion wrote:
Hi Aymeric!
I justed tested on one of my proxies (kamailio 1.5) and with the default setting (120s) it closes TCP connection always after 131 seconds - strange.
If I set to 30, the connection will be closed after 41 seconds. If I set to 300, the connection will be closed after 311 seconds.
Looks like in my case there are always 11 seconds added (maybe some other timeouts before the connection enters the "idle" state in the TCP handler).
Anyway, that does not answer the problems you are experiencing.
regards klaus
Klaus Darilion schrieb:
On Fri, 23 Oct 2009, Klaus Darilion wrote:
modparam("rtimer", "timer", "name=tst;interval=300;mode=1;")
Using this, my timer is called every 75 seconds ;(
My linux is a standar ovh kernel "2.6.28.4-xxxx-std-ipv4-32 #2 SMP". I already got issue with the SIP NAT module statically linked into the kernel that I couldn't remove... and once more, the kernel...
I will try another kernel after some backup.
Right. But I'm getting closer!
Aymeric MOIZARD / ANTISIP amsip - http://www.antisip.com osip2 - http://www.osip.org eXosip2 - http://savannah.nongnu.org/projects/exosip/
El Viernes, 23 de Octubre de 2009, Aymeric Moizard escribió:
I also have a OVH server. What do you mean with "SIP NAT module statically linked into the kernel"? I've never detected a SIP issue in my server (in which I run lot of SIP stuff :)
On Fri, 23 Oct 2009, Iñaki Baz Castillo wrote:
With some old kernel, the masquerading module was dropping my 200 ok answers for re-INVITE. This was happening to me may be a year or 2 ago.
Tks, Aymeric MOIZARD / ANTISIP amsip - http://www.antisip.com osip2 - http://www.osip.org eXosip2 - http://savannah.nongnu.org/projects/exosip/
I guess I found my issue:
*2009-07-13 12:40 Carsten Bock, <carsten at bock dot info> * * * [r5899] timer.c: * Fix double increase of jiffy-value. * - As noticed by Daniel.
I'll update and see if it fixes all!
Tks, Aymeric MOIZARD / ANTISIP amsip - http://www.antisip.com osip2 - http://www.osip.org eXosip2 - http://savannah.nongnu.org/projects/exosip/
On Sat, 24 Oct 2009, Aymeric Moizard wrote:
last input,
I confirm that upgrading to latest svn 1.5 branch fix all my jiffies/timer issue. I was guilty to use a *pretty* old version...
I now have 131 seconds delay for a lifetime of 120 and my statistics are computed every 300 to 301 seconds (as expected). It probably means the timer are working nicely but the lifetime algo has some minor issue. That would not affect anything if this value is kept higher than 120 seconds anyway!
Tks for all, Aymeric MOIZARD / ANTISIP amsip - http://www.antisip.com osip2 - http://www.osip.org eXosip2 - http://savannah.nongnu.org/projects/exosip/
On Sat, 24 Oct 2009, Aymeric Moizard wrote:
Iñaki Baz Castillo writes:
inaki,
there is this piece of code in reload_gws_and_lcrs() function:
if (RES_ROW_N(res) + 1 > MAX_NO_OF_GWS) { LM_ERR("too many gateways\n"); goto gw_err; }
what do you mean by "the module doesn't notify it when starting"?
i can also add info about the limit in module documentation.
-- juha
El Viernes, 23 de Octubre de 2009, Juha Heinanen escribió:
I didn't know that.
what do you mean by "the module doesn't notify it when starting"?
IMHO Kamailio shouln't start if there are more gateways than MAX_NO_OF_GWS. This is, lcr module should give an error. Does it? (I've not tryed it).
It would be nice :)
El Sábado, 24 de Octubre de 2009, Juha Heinanen escribió:
Yes, I read it in the commits :) Thanks.
-
Aymeric Moizard -
Iñaki Baz Castillo -
jh＠tutpro.com -
Klaus Darilion -
Ricardo Martinez