> 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,
On 11/3/11 12:47 PM, Asgaroth wrote:
Hi
On 03/11/2011 10:53, Daniel-Constantin Mierla wrote:
I discovered a copy&paste 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, tha
Hi
On 03/11/2011 10:53, Daniel-Constantin Mierla wrote:
>
> I discovered a copy&paste 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,
I discovered a copy&paste typo in previous commit for maintaining the
inactive state, try again with latest GIT master and let me know the
results.
Cheers,
Daniel
On 11/3/11 11:13 AM, Asgaroth wrote:
Hi
can you fetch the latest master branch from git and try with:
Trying with the f
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 02/11/2011 10:06, Daniel-Constantin Mierla wrote:
> 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
>
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, Asgarot
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
correc
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 c
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
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 f
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 ma
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 b
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 detect
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, D
Hello,
On 10/26/11 7:06 PM, Bruce McAlister wrote:
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
> 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 for gateway chages
> to AX (A
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,
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
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
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
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")
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
v3.2.0
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 de
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
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
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_IP
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,
DBG_QM_M
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
>
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,
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 example
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
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");
x
Hello,
I haven't read the archive, but you probably talk about what I am
thinking of. IIRC, at that time Carsten tried to explain how it works,
but overall looked confused indeed. As a result, dispatcher module in
3.2.0 has a different system for gateway states.
There are three of them:
- ac
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, SH
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...
Carst
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
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 Kamail
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 para
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.
IMO "probing" should only be a flag which indicates if OPTIONS should
sent or
40 matches
Mail list logo