[SR-Users] dispatcher confusion

[Klaus Darilion]

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 at gmail.com>:
>> 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 at lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>
>
>
>