28 Feb
2011
28 Feb
'11
6:29 p.m.
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 not. If probing is successful, then the state should be
"active". If probing is unsuccessful, then the state should be
"inactive".
Current behavior is very strange (ds_probing_mode(0)):
--> startup state: A --> no probing
kamctl fifo ds_set_state i 1 sip:....
--> state: I --> no probing
kamctl fifo ds_set_state a 1 sip:....
--> state: A --> no probing
calling 3 times ds_mark_dst("p")
--> state: P --> probing (and dst is still loaded as last value into the
dst_avp, why?)
kamctl fifo ds_set_state i 1 sip:....
--> state: I --> still probing
kamctl fifo ds_set_state a 1 sip:....
--> state: P (???) --> probing
Thus, "ds_set_state a ..." does not set active, but probing if it was
probing before. Strange.
And as "inactive" does not stop probing when dst was in probing mode,
the destination becomes automatically "active" if the probing succeeds.
And why is a destination in probing mode loaded into the dst_avp? Very
weird.
Is there a reason for this behavior?
Thanks
Klaus
28 Feb
28 Feb
10:46 p.m.
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 for probing, then no
matter the state,
the pinging is done for all addresses.
If the module parameter is not set, only the destinations marked as
"probing" should be pinged.
In devel version I tried to sort out a bit these states, so we should
make it more sane and clear.
IMO "probing" should only be a flag which
indicates if OPTIONS should
sent or not. If probing is successful, then the state should be
"active". If probing is unsuccessful, then the state should be
"inactive".
Current behavior is very strange (ds_probing_mode(0)):
--> startup state: A --> no probing
kamctl fifo ds_set_state i 1 sip:....
--> state: I --> no probing
kamctl fifo ds_set_state a 1 sip:....
--> state: A --> no probing
When ds_probing_mode==0, only if you set P flag
to address will be pinged.
calling 3 times ds_mark_dst("p")
--> state: P --> probing (and dst is still loaded as last value into the
dst_avp, why?)
kamctl fifo ds_set_state i 1 sip:....
--> state: I --> still probing
kamctl fifo ds_set_state a 1 sip:....
--> state: P (???) --> probing
Thus, "ds_set_state a ..." does not set active, but probing if it was
probing before. Strange.
And as "inactive" does not stop probing when dst was in probing mode,
the destination becomes automatically "active" if the probing succeeds.
inactive and probing are different flags. In devel I introduced new
state 'disabled' for cases when you want to "remove" an address from
destination list.
And why is a destination in probing mode loaded into
the dst_avp? Very
weird.
If it is just probing and not inactive, then it is loaded as new dst.
Is there a reason for this behavior?
IIRC, I
think Carsten developed most of the probing mode, maybe there
was a reason behind current behavior.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com
2 Mar
2 Mar
12:52 p.m.
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 Kamailio's internals: The
"OPTIONS"-Request being sent out is handled by the TM-Module, which
will generate Retransmits for quite a long time (2 minutes?). Upon a
successful reply for the OPTIONS-Request, it will set the destination
to active again. I will change this behaviour later this week or next
week in GIT-Trunk, so an administratively disabled destination stays
inactive, even upon a delayed positive reply for an
OPTIONS-Request....
Carsten
2011/2/28 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
Hello,
On 2/28/11 5:29 PM, Klaus Darilion wrote:
--
Carsten Bock
Schomburgstr. 80
22767 Hamburg
Germany
Mobile +49 179 2021244
Home +49 40 34927217
Büro (Verl) +49 5246 801427
Fax +49 40 34927218
mailto:carsten@bock.info
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 for probing, then no matter the state, the
pinging is done for all addresses.
If the module parameter is not set, only the destinations marked as
"probing" should be pinged.
In devel version I tried to sort out a bit these states, so we should make
it more sane and clear.
IMO "probing" should only be a flag
which indicates if OPTIONS should
sent or not. If probing is successful, then the state should be
"active". If probing is unsuccessful, then the state should be
"inactive".
Current behavior is very strange (ds_probing_mode(0)):
--> startup state: A --> no probing
kamctl fifo ds_set_state i 1 sip:....
--> state: I --> no probing
kamctl fifo ds_set_state a 1 sip:....
--> state: A --> no probing
When ds_probing_mode==0, only if you set P flag to address will be pinged.
calling 3 times ds_mark_dst("p")
--> state: P --> probing (and dst is still loaded as last value into the
dst_avp, why?)
kamctl fifo ds_set_state i 1 sip:....
--> state: I --> still probing
kamctl fifo ds_set_state a 1 sip:....
--> state: P (???) --> probing
Thus, "ds_set_state a ..." does not set active, but probing if it was
probing before. Strange.
And as "inactive" does not stop probing when dst was in probing mode,
the destination becomes automatically "active" if the probing succeeds.
inactive and probing are different flags. In devel I introduced new state
'disabled' for cases when you want to "remove" an address from
destination
list.
And why is a destination in probing mode loaded into the dst_avp? Very
weird.
If it is just probing and not inactive, then it is loaded as new dst.
Is there a reason for this behavior?
IIRC, I think Carsten developed most of the probing mode, maybe there was a
reason behind current behavior.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
2:03 p.m.
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"
state?
Maybe it would be better to separate the "should" state from the
"real"
state, and probing is just a flag which may happen in all states.
Eg:
should state:
disabled: administratively down (never probing)
enabled: administratively up (probing if activated)
real sate:
disabled: should-state is disabled (destination will NOT be used in
dispatching)
up: everthing is fine (destination will be used in dispatching)
failure: probing failed for threshold times (destination will NOT be
used in dispatching)
regards
Klaus
If you disable a gateway when it is in probing mode, it may end up
with being enabled again due to some of Kamailio's internals: The
"OPTIONS"-Request being sent out is handled by the TM-Module, which
will generate Retransmits for quite a long time (2 minutes?). Upon a
successful reply for the OPTIONS-Request, it will set the destination
to active again. I will change this behaviour later this week or next
week in GIT-Trunk, so an administratively disabled destination stays
inactive, even upon a delayed positive reply for an
OPTIONS-Request....
Carsten
2011/2/28 Daniel-Constantin Mierla<miconda(a)gmail.com>om>:
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 for probing, then no matter the state, the
pinging is done for all addresses.
If the module parameter is not set, only the destinations marked as
"probing" should be pinged.
In devel version I tried to sort out a bit these states, so we should make
it more sane and clear.
IMO "probing" should only be a flag
which indicates if OPTIONS should
sent or not. If probing is successful, then the state should be
"active". If probing is unsuccessful, then the state should be
"inactive".
Current behavior is very strange (ds_probing_mode(0)):
--> startup state: A --> no probing
kamctl fifo ds_set_state i 1 sip:....
--> state: I --> no probing
kamctl fifo ds_set_state a 1 sip:....
--> state: A --> no probing
When ds_probing_mode==0, only if you set P flag to address will be pinged.
calling 3 times ds_mark_dst("p")
--> state: P --> probing (and dst is still loaded as last value into the
dst_avp, why?)
kamctl fifo ds_set_state i 1 sip:....
--> state: I --> still probing
kamctl fifo ds_set_state a 1 sip:....
--> state: P (???) --> probing
Thus, "ds_set_state a ..." does not set active, but probing if it was
probing before. Strange.
And as "inactive" does not stop probing when dst was in probing mode,
the destination becomes automatically "active" if the probing succeeds.
inactive and probing are different flags. In devel I introduced new state
'disabled' for cases when you want to "remove" an address from
destination
list.
And why is a destination in probing mode loaded into the dst_avp? Very
weird.
If it is just probing and not inactive, then it is loaded as new dst.
Is there a reason for this behavior?
IIRC, I think Carsten developed most of the probing mode, maybe there was a
reason behind current behavior.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
7 Mar
7 Mar
10:45 p.m.
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...
Carsten
2011/3/2 Klaus Darilion <klaus.mailinglists(a)pernau.at>at>:
On 02.03.2011 11:52, Carsten Bock wrote:
--
Carsten Bock
http://www.ng-voice.com
mailto:carsten@ng-voice.com
Schomburgstr. 80
22767 Hamburg
Germany
Mobile +49 179 2021244
Office +49 40 34927219
Fax +49 40 34927220
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"
state?
Maybe it would be better to separate the "should" state from the
"real"
state, and probing is just a flag which may happen in all states.
Eg:
should state:
disabled: administratively down (never probing)
enabled: administratively up (probing if activated)
real sate:
disabled: should-state is disabled (destination will NOT be used in
dispatching)
up: everthing is fine (destination will be used in dispatching)
failure: probing failed for threshold times (destination will NOT be used
in dispatching)
regards
Klaus
If you disable a gateway when it is in probing mode, it may end up
with being enabled again due to some of Kamailio's internals: The
"OPTIONS"-Request being sent out is handled by the TM-Module, which
will generate Retransmits for quite a long time (2 minutes?). Upon a
successful reply for the OPTIONS-Request, it will set the destination
to active again. I will change this behaviour later this week or next
week in GIT-Trunk, so an administratively disabled destination stays
inactive, even upon a delayed positive reply for an
OPTIONS-Request....
Carsten
2011/2/28 Daniel-Constantin Mierla<miconda(a)gmail.com>om>:
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 for probing, then no matter the state,
the
pinging is done for all addresses.
If the module parameter is not set, only the destinations marked as
"probing" should be pinged.
In devel version I tried to sort out a bit these states, so we should
make
it more sane and clear.
IMO "probing" should only be a flag
which indicates if OPTIONS should
sent or not. If probing is successful, then the state should be
"active". If probing is unsuccessful, then the state should be
"inactive".
Current behavior is very strange (ds_probing_mode(0)):
--> startup state: A --> no probing
kamctl fifo ds_set_state i 1 sip:....
--> state: I --> no probing
kamctl fifo ds_set_state a 1 sip:....
--> state: A --> no probing
When ds_probing_mode==0, only if you set P flag to address will be
pinged.
calling 3 times ds_mark_dst("p")
--> state: P --> probing (and dst is still loaded as last value
into the
dst_avp, why?)
kamctl fifo ds_set_state i 1 sip:....
--> state: I --> still probing
kamctl fifo ds_set_state a 1 sip:....
--> state: P (???) --> probing
Thus, "ds_set_state a ..." does not set active, but probing if it was
probing before. Strange.
And as "inactive" does not stop probing when dst was in probing mode,
the destination becomes automatically "active" if the probing succeeds.
inactive and probing are different flags. In devel I introduced new state
'disabled' for cases when you want to "remove" an address from
destination
list.
And why is a destination in probing mode loaded into the dst_avp? Very
weird.
If it is just probing and not inactive, then it is loaded as new dst.
Is there a reason for this behavior?
IIRC, I think Carsten developed most of the probing mode, maybe there was
a
reason behind current behavior.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
5009
days inactive
5016
days old
4 comments
3 participants
participants (3)
-
Carsten Bock -
Daniel-Constantin Mierla -
Klaus Darilion