Hi
can you fetch the latest master branch from git and try with:
Trying with the following version:
# ./kamailio -V
version: kamailio 3.3.0-dev1 (i386/linux) 26364a
flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS,
DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP,
Hi
On 03/11/2011 10:53, Daniel-Constantin Mierla wrote:
I discovered a copypaste typo in previous commit for maintaining the
inactive state, try again with latest GIT master and let me know the
results.
That change works as expected now, thanks for all the work done to get
this going :)
Hello,
On 11/3/11 12:47 PM, Asgaroth wrote:
Hi
On 03/11/2011 10:53, Daniel-Constantin Mierla wrote:
I discovered a copypaste typo in previous commit for maintaining the
inactive state, try again with latest GIT master and let me know the
results.
That change works as expected now,
ok,
ok, thanks for testing!
No problemo, glad I could help in some way :)
I'll do the backporting to 3.2 branch soon.
Thanks, appreciated :)
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
Hello,
can you fetch the latest master branch from git and try with:
ds_probing_mode = 2
This should keep inactive gateways in probing mode, if you set the
probing mode when switching in trying/inactive state, until it gets back
to active state.
Cheers,
Daniel
On 10/28/11 12:33 PM,
Hi Daniel,
Thanks for the explanation. I've been doing some testing and I've come
accross the following situation:
ds_probing_threshold = 1
ds_probing_mode = 0
in failure route (when timeout occurs) I do:
ds_mark_dst(ip)
State changes from active to inactive and mode set to probing is
Hello,
I just pushed to remote GIT repository in master branch a bit of
refactoring about the states and ds_mark_dst().
Since with 3.2 seemed that it was lost capability to go inactive after a
certain number of failures (ds_probing_threshold), there is a new state
'trying' that can be used
Hi Daniel,
On 27/10/2011 15:57, Daniel-Constantin Mierla wrote:
Hello,
I just pushed to remote GIT repository in master branch a bit of
refactoring about the states and ds_mark_dst().
Thanks, I will test the dev branch in a short while and get back to you.
Since with 3.2 seemed that it
Hello,
On 10/27/11 5:30 PM, Asgaroth wrote:
Hi Daniel,
[...]
Since with 3.2 seemed that it was lost capability to go inactive after
a certain number of failures (ds_probing_threshold), there is a new
state 'trying' that can be used for it. Means that you can set a
destination in trying state
Hi Daniel,
On 26/10/2011 04:47, Daniel-Constantin Mierla wrote:
the purpose with three states (active, inactive and disabled) was not
to relate probing to selection of gateways, as one may want to have
even active gateways in probing mode to detect when they go down. So,
in other words, if
Hi Daniel,
On 26/10/2011 04:44, Daniel-Constantin Mierla wrote:
If I do a ds_mark_dst(i) and then right after ds_mark_dst(p), a
log is printed saying that you cannot put a destination into probing
state when it is marked as inactive.
are you sure you run the devel version? There is no such
On 26/10/2011 10:47, Asgaroth wrote:
Assuming ds_probing_mode = 0 (Only send ping requests when
destination is in probing state)
AP (Active-Probing)
[*] Used by ds_select_* in gateway selection
[*] Ping probes sent to destination
[*] When reply to ping probe is recieved, state
Hello,
if you tried with 3.2.x, it was the case, since I just backported from
master branch the commit I did to sort out better the behaviour based on
probing state. Try again now with latest 3.2 branch.
Cheers,
Daniel
On 10/26/11 11:59 AM, Asgaroth wrote:
Hi Daniel,
On 26/10/2011 04:44,
Hello,
On 10/26/11 11:47 AM, Asgaroth wrote:
Hi Daniel,
On 26/10/2011 04:47, Daniel-Constantin Mierla wrote:
the purpose with three states (active, inactive and disabled) was not
to relate probing to selection of gateways, as one may want to have
even active gateways in probing mode to
On 26/10/2011 10:47, Asgaroth wrote:
Assuming ds_probing_mode = 0 (Only send ping requests when
destination is in probing state)
IX (Inactive)
[*] Not used by ds_select_* in gateway selection
[*] No ping probes sent to destination
IP (Inactive-Probing)
[*] Not used by
Hi Daniel,
On 26/10/2011 18:17, Daniel-Constantin Mierla wrote:
if you tried with 3.2.x, it was the case, since I just backported from
master branch the commit I did to sort out better the behaviour based
on probing state. Try again now with latest 3.2 branch.
Thanks, the changes you made
Hello,
the probing state is no longer related to selection of the gateways. It
is unclear in the previous version what is the role of it in selection
of an address, since some time, a gw in probing was wanted to be
selected and some time not.
So probing is a state related to whether to send
Hi Daniel,
Thanks for the clarrification,
On 25/10/2011 16:30, Daniel-Constantin Mierla wrote:
4.6. |ds_mark_dst(s)|
Mark the last used address from destination set as inactive
(i/I/0), active (a/A/1) or probing (p/P/2). With
this function, an automatic detection of failed gateways
Hi Daniel,
I'm wondering if the change you made to the dev branch for setting the
state via fifo command is what could be causing this issues (just
guessing, I am more than likely worng :)), see my subsequent testing below:
Just a little further digging on this, seems to show that kamailio
Hello,
On 10/25/11 5:52 PM, Asgaroth wrote:
Hi Daniel,
Thanks for the clarrification,
On 25/10/2011 16:30, Daniel-Constantin Mierla wrote:
4.6. |ds_mark_dst(s)|
Mark the last used address from destination set as inactive
(i/I/0), active (a/A/1) or probing (p/P/2). With
this
Hello,
On 10/25/11 10:09 PM, Asgaroth wrote:
Hi Daniel,
I'm wondering if the change you made to the dev branch for setting the
state via fifo command is what could be causing this issues (just
guessing, I am more than likely worng :)), see my subsequent testing
below:
the purpose with three
Hi Daniel,
Just a reminder for this issue, to backport to 3.2.0 :)
Thanks
On 21/10/2011 10:53, Asgaroth wrote:
Hi Daniel,
It appears the change you made has fixed the issue. Below are my tests:
# kamailio -V
version: kamailio 3.3.0-dev0 (i386/linux) 25bedc
flags: STATS: Off, USE_IPV6,
Hello,
yes, I will do it. Just happens to travel these days, but when I get the
time for it, I will do it.
Btw, did you test also the load balancing functionality? Was it affected
or all is ok when you change the states? I mean when you disable/make
inactive a gateway, is no longer used for
Thanks Daniel, I will do some testing of the development version and get
back to you.
On 20/10/2011 22:54, Daniel-Constantin Mierla wrote:
Hello,
indeed the setting of active state via MI command was wrong. Should be
fixed now in master branch. Can you test it and see if works ok now (I
had
Hi Daniel,
It appears the change you made has fixed the issue. Below are my tests:
# kamailio -V
version: kamailio 3.3.0-dev0 (i386/linux) 25bedc
flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS,
DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC,
Thanks Daniel, I will try 3.2.0 shortly.
Just another quick question, I have the following failure route defined
for dispatcher:
if (t_branch_timeout() !t_branch_replied())
{
xlog(route[TO_SBC] : $rm : timeout and no reply
($si:$sp-$Ri:$Rp-$du)\n);
Hello,
On 10/20/11 1:13 PM, Bruce McAlister wrote:
Thanks Daniel, I will try 3.2.0 shortly.
Just another quick question, I have the following failure route defined
for dispatcher:
if (t_branch_timeout() !t_branch_replied())
{
xlog(route[TO_SBC] : $rm : timeout and
Hi All,
Just been doing some testing with Kamailio 3.2 and the dispatcher
module, and have some strange behaviour, can we confirm if it is
expected behaviour or a bug of some sort.
It appears that I can only set the dspatcher state via fifo command
once, and not reset it again, here is an
Hello,
indeed the setting of active state via MI command was wrong. Should be
fixed now in master branch. Can you test it and see if works ok now (I
had no option to test it myself yet). If all goes fine with your tests,
then I will backport.
Guidelines to install master branch can be found
Hi All,
I'd like to clear something up with the diapatcher module and it's
probing parameters:
First things first:
./kamailio -V
version: kamailio 3.1.5 (i386/linux) 76fff5
flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS,
DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM,
Hi,
i have just changed the functionality in the master branch: If we get
a positive reply from the OPTIONS-Request and the destination has been
deactivated, it should now no longer become active again, only the
error-counter will be set to zero.
I will do some tests in the next few days...
Hi everyone,
the idea behind the probing mode was, to have three states for a gateway:
- Active
- In-Active: Administratively disabled
- Probing (Active, but currently not responding)
If you disable a gateway when it is in probing mode, it may end up
with being enabled again due to some of
On 02.03.2011 11:52, Carsten Bock wrote:
Hi everyone,
the idea behind the probing mode was, to have three states for a gateway:
- Active
- In-Active: Administratively disabled
- Probing (Active, but currently not responding)
So, inactive should be the same as the newly introduced disabled
Hello,
On 2/28/11 5:29 PM, Klaus Darilion wrote:
Hi!
Every time I use the dispatcher(k) module I am confused again. Sometimes
it seems that probing is a dedicated state, sometimes it seems that
probing is done also in active state, but never in inactive state.
if you set the global parameter
34 matches
Mail list logo
