24 Sep
2008
24 Sep
'08
11:10 a.m.
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.
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (706) 338-8599
24 Sep
24 Sep
11:29 a.m.
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.
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (706) 338-8599
11:51 a.m.
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:
--
Daniel-Constantin Mierla
http://www.asipto.com
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.
7:11 p.m.
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?
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (706) 338-8599
9:17 p.m.
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:
--
Daniel-Constantin Mierla
http://www.asipto.com
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?
9:58 p.m.
Daniel,
Daniel-Constantin Mierla wrote:
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.
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (706) 338-8599
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.
10:31 p.m.
On 09/24/08 22:58, Alex Balashov wrote:
Daniel,
Daniel-Constantin Mierla wrote:
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
http://www.asipto.com
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.
25 Sep
25 Sep
8:13 a.m.
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
8:20 a.m.
Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
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
> 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. 
10:45 p.m.
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(a)evaristesys.com> wrote:
Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
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(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
> 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.
11:28 p.m.
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(a)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(a)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
11:48 p.m.
Both modules are doing this. The idea is to be able to do run time
config changes.
On 9/25/08, Alex Balashov <abalashov(a)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(a)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(a)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
26 Sep
26 Sep
12:16 a.m.
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
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (706) 338-8599
5706
days inactive
5707
days old
12 comments
4 participants
participants (4)
-
Alex Balashov -
Daniel-Constantin Mierla -
jh＠tutpro.com -
Ovidiu Sas