Hello.
I’m looking for a way to mix the features of LCR and a counter to keep track of the used resource of a gateway. Let me explain.
Let’s suppose that I’m using LCR module to route the calls to all my gateways, in particular I have the calls with prefix 55 routed to the group “55” which are 3 gateways :
GW1, GW2 and GW3. Let’s suppose also that each gateway is connected to digital E1 with 30 channels. At certain time of the day one of the gateways is at full capacity using the 30 channels. This is what I wanted to do : can I have a variable with the maximum channels available for a certain gateway, and for each call going to that gateway a counter?. When the counter reach the maximum, can I remove the gateway from the LCR choosing algorithm until it has capacity again?
Can I have some thoughts about this idea?
Is there a way to achieve this ?
Thanks in advance.
Regards,
Ricardo.-
Ricardo Martinez writes:
GW1, GW2 and GW3. Let’s suppose also that each gateway is connected to digital E1 with 30 channels. At certain time of the day one of the gateways is at full capacity using the 30 channels. This is what I wanted to do : can I have a variable with the maximum channels available for a certain gateway, and for each call going to that gateway a counter?. When the counter reach the maximum, can I remove the gateway from the LCR choosing algorithm until it has capacity again?
there is function defunct_gw(period) that you can use to defunct a full gateway for some period of time.
for what you propose, you would need to use dialog module to keep track of dialogs to each gateway and that way manage your counters. then after calling next_gw(), you could check if its counter allows you to actually use it.
i'm not myself a believer of dialogs in sip proxy.
-- juha
Hello Juha. Thanks for your answer. I will try something like that. Question. The defunct_gw() function works with the gateway selected with the next_gw() function??
Another question. How would be the logic to mark a gateway down automatically in the LCR?. I mean trying to emulate the "ping" function from the 1.5 version.
Thanks Regards, Ricardo.-
-----Mensaje original----- De: sr-users-bounces@lists.sip-router.org [mailto:sr-users-bounces@lists.sip-router.org] En nombre de Juha Heinanen Enviado el: martes, 28 de diciembre de 2010 12:53 Para: Ricardo Martinez CC: sr-users@lists.sip-router.org Asunto: [SR-Users] LCR and gateways resource.
Ricardo Martinez writes:
GW1, GW2 and GW3. Let’s suppose also that each gateway is connected to digital E1 with 30 channels. At certain time of the day one of the gateways is at full capacity using the 30 channels. This is what I wanted to do : can I have a variable with the maximum channels available for a certain gateway, and for each call going to that gateway a counter?. When the counter reach the maximum, can I remove the gateway from the LCR choosing algorithm until it has capacity again?
there is function defunct_gw(period) that you can use to defunct a full gateway for some period of time.
for what you propose, you would need to use dialog module to keep track of dialogs to each gateway and that way manage your counters. then after calling next_gw(), you could check if its counter allows you to actually use it.
i'm not myself a believer of dialogs in sip proxy.
-- juha
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Ricardo Martinez writes:
Thanks for your answer. I will try something like that. Question. The defunct_gw() function works with the gateway selected with the next_gw() function??
yes.
Another question. How would be the logic to mark a gateway down automatically in the LCR?. I mean trying to emulate the "ping" function from the 1.5 version.
there is no such thing in 3.1. it is now up to the script to decide what to do if a gw cannot serve the request. set your timeout to a small value, such as 3 seconds, and then decide based on the response code what to do.
-- juha