How does one go about resurrecting gateways that have been marked into "probing" mode back into the "active" set once they start replying to the pings that the dispatcher facility sends?
I see the OPTIONS pings going through, and I see the UAs generating replies to them whey come back up. But OpenSER does nothing in response to receipt of those replies to mark them as active again.
Because the OPTIONS request is not originated from script, there is no way to catch the replies in an ONREPLY-ROUTE, otherwise I would have tried to handle it that way and re-mark the gateways.
There seems to be no way to assign a FAILURE-ROUTE to be associated with the OPTIONS pings either, because the transactions are originated internally by the module and not accessible via the stateful tracking within script.
So, the question remains -- how do I make Kamailio notice that the gateway has come back up so that it can be marked as active in the destination set again?
Alex Balashov wrote:
How does one go about resurrecting gateways that have been marked into "probing" mode back into the "active" set once they start replying to the pings that the dispatcher facility sends?
I see the OPTIONS pings going through, and I see the UAs generating replies to them whey come back up. But OpenSER does nothing in response to receipt of those replies to mark them as active again.
Because the OPTIONS request is not originated from script, there is no way to catch the replies in an ONREPLY-ROUTE, otherwise I would have tried to handle it that way and re-mark the gateways.
Hello,
kamailio should automatically enable the gateway. The mechanism used is based n internal tm callbacks. If the gateway is not brought back, then there is something wrong with matching it when reply comes back.
Can you run on debug mode and send the messages along with sip trace?
Cheers, Daniel
On 09/24/08 12:29, Alex Balashov wrote:
There seems to be no way to assign a FAILURE-ROUTE to be associated with the OPTIONS pings either, because the transactions are originated internally by the module and not accessible via the stateful tracking within script.
So, the question remains -- how do I make Kamailio notice that the gateway has come back up so that it can be marked as active in the destination set again?
Alex Balashov wrote:
How does one go about resurrecting gateways that have been marked into "probing" mode back into the "active" set once they start replying to the pings that the dispatcher facility sends?
I see the OPTIONS pings going through, and I see the UAs generating replies to them whey come back up. But OpenSER does nothing in response to receipt of those replies to mark them as active again.
Because the OPTIONS request is not originated from script, there is no way to catch the replies in an ONREPLY-ROUTE, otherwise I would have tried to handle it that way and re-mark the gateways.
Hi Daniel,
Kamailio is most definitely not re-enabling the gateway. I will look into it as you suggest and pass along what I find.
As far as the "algorithm" used by ds_next_dst()/domain(), why is there not an algorithm implemented which simply uses the first gateway in the route set? Why do I have to resort to using an unnumbered algorithm ("X") for that:
Sep 24 13:07:55 [29155] WARNING:dispatcher:ds_select_dst: algo 256 not implemented - using first entry... Attempting to relay INVITE from 205.221.123.11 to 212.42.196.8
I don't want any hashing of any headers. And I don't want to use any hash algorithm which always hashes to one value, because I have no control over what that single value is.
I would think that using one gateway primarily, with a secondary as a standby, is a very, very common use case. What is the best way to do this with dispatcher?
Thanks,
-- Alex
Daniel-Constantin Mierla wrote:
kamailio should automatically enable the gateway. The mechanism used is based n internal tm callbacks. If the gateway is not brought back, then there is something wrong with matching it when reply comes back.
Can you run on debug mode and send the messages along with sip trace?
Hello Alex,
On 09/24/08 20:11, Alex Balashov wrote:
Hi Daniel,
Kamailio is most definitely not re-enabling the gateway. I will look into it as you suggest and pass along what I find.
ok
As far as the "algorithm" used by ds_next_dst()/domain(), why is there not an algorithm implemented which simply uses the first gateway in the route set? Why do I have to resort to using an unnumbered algorithm ("X") for that:
Sep 24 13:07:55 [29155] WARNING:dispatcher:ds_select_dst: algo 256 not implemented - using first entry... Attempting to relay INVITE from 205.221.123.11 to 212.42.196.8
I don't want any hashing of any headers. And I don't want to use any hash algorithm which always hashes to one value, because I have no control over what that single value is.
I would think that using one gateway primarily, with a secondary as a standby, is a very, very common use case. What is the best way to do this with dispatcher?
Add a new algorithm as you described, that is very simple, i will have it it mind.
Cheers, Daniel
Thanks,
-- Alex
Daniel-Constantin Mierla wrote:
kamailio should automatically enable the gateway. The mechanism used is based n internal tm callbacks. If the gateway is not brought back, then there is something wrong with matching it when reply comes back.
Can you run on debug mode and send the messages along with sip trace?
Daniel,
Daniel-Constantin Mierla wrote:
I would think that using one gateway primarily, with a secondary as a standby, is a very, very common use case. What is the best way to do this with dispatcher?
Add a new algorithm as you described, that is very simple, i will have it it mind.
I guess I was wondering why this algorithm was absent before, from a philosophical perspective.
The scenario I am describing is so simple and common (route to one gateway, and route to another if it fails) that I would have thought that if it was not built into dispatcher before, it is because dispatcher is conceptually intended for a different application.
On 09/24/08 22:58, Alex Balashov wrote:
Daniel,
Daniel-Constantin Mierla wrote:
I would think that using one gateway primarily, with a secondary as a standby, is a very, very common use case. What is the best way to do this with dispatcher?
Add a new algorithm as you described, that is very simple, i will have it it mind.
I guess I was wondering why this algorithm was absent before, from a philosophical perspective.
The scenario I am describing is so simple and common (route to one gateway, and route to another if it fails) that I would have thought that if it was not built into dispatcher before, it is because dispatcher is conceptually intended for a different application.
the algorithm is there (was there from beginning), just didn't get a number (yet) -- dispatcher purpose was for load balancing, so the focus was to find algorithms to send traffic across all available options.
Cheers, Daniel
Daniel-Constantin Mierla writes:
I would think that using one gateway primarily, with a secondary as a standby, is a very, very common use case. What is the best way to do this with dispatcher?
i haven't followed this thread, but is there a reason why you can't use lcr module for this? it allows you to assign priorities to gateways.
-- juha
Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
I would think that using one gateway primarily, with a secondary as a standby, is a very, very common use case. What is the best way to do this with dispatcher?
i haven't followed this thread, but is there a reason why you can't use lcr module for this? it allows you to assign priorities to gateways.
Aside from simplicity, no, I suppose there is not a particular reason for this. But the LCR module is a lot more complicated. Yes, that's a compelling reason for us little people.
Hello Alex,
The lcr module is not complicated compared with dispatcher module ... The complexity is pretty much the same. Please check the sample config file that I created for openser 1.3 version: http://voipembedded.com/resources/openser_dbtext_lcr.cfg This will give you exactly the behavior that you need.
Regards, Ovidiu Sas
On Thu, Sep 25, 2008 at 2:20 AM, Alex Balashov abalashov@evaristesys.com wrote:
Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
I would think that using one gateway primarily, with a secondary as a standby, is a very, very common use case. What is the best way to do this with dispatcher?
i haven't followed this thread, but is there a reason why you can't use lcr module for this? it allows you to assign priorities to gateways.
Aside from simplicity, no, I suppose there is not a particular reason for this. But the LCR module is a lot more complicated. Yes, that's a compelling reason for us little people.
-- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
You make a compelling point.
Then again, considering there are only two gateways involved at present, using a low inv_timer (tm) value and FAILURE-ROUTE will probably give me the behaviour I need too. :-)
Ovidiu Sas wrote:
Hello Alex,
The lcr module is not complicated compared with dispatcher module ... The complexity is pretty much the same. Please check the sample config file that I created for openser 1.3 version: http://voipembedded.com/resources/openser_dbtext_lcr.cfg This will give you exactly the behavior that you need.
Regards, Ovidiu Sas
On Thu, Sep 25, 2008 at 2:20 AM, Alex Balashov abalashov@evaristesys.com wrote:
Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
I would think that using one gateway primarily, with a secondary as a standby, is a very, very common use case. What is the best way to do this with dispatcher?
i haven't followed this thread, but is there a reason why you can't use lcr module for this? it allows you to assign priorities to gateways.
Aside from simplicity, no, I suppose there is not a particular reason for this. But the LCR module is a lot more complicated. Yes, that's a compelling reason for us little people.
-- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Both modules are doing this. The idea is to be able to do run time config changes.
On 9/25/08, Alex Balashov abalashov@evaristesys.com wrote:
You make a compelling point.
Then again, considering there are only two gateways involved at present, using a low inv_timer (tm) value and FAILURE-ROUTE will probably give me the behaviour I need too. :-)
Ovidiu Sas wrote:
Hello Alex,
The lcr module is not complicated compared with dispatcher module ... The complexity is pretty much the same. Please check the sample config file that I created for openser 1.3 version: http://voipembedded.com/resources/openser_dbtext_lcr.cfg This will give you exactly the behavior that you need.
Regards, Ovidiu Sas
On Thu, Sep 25, 2008 at 2:20 AM, Alex Balashov abalashov@evaristesys.com wrote:
Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
I would think that using one gateway primarily, with a secondary as
a
standby, is a very, very common use case. What is the best way to
do
this with dispatcher?
i haven't followed this thread, but is there a reason why you can't use lcr module for this? it allows you to assign priorities to gateways.
Aside from simplicity, no, I suppose there is not a particular reason for this. But the LCR module is a lot more complicated. Yes, that's a compelling reason for us little people.
-- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
-- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599
Ovidiu Sas wrote:
Both modules are doing this. The idea is to be able to do run time config changes.
Yep. The only real benefit from the modules in this setup is the fact that they provide an interface to dynamic and variable-length lists of gateways to cycle through according to certain parameters.
The essential "glue" that puts it all together must still be implemented by the script author, which is true of pretty much everything related to Kamailio, and is a good thing.
-
Alex Balashov -
Daniel-Constantin Mierla -
jh＠tutpro.com -
Ovidiu Sas