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.mailingli...@pernau.at>:
>
>
> 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<mico...@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@lists.sip-router.org
>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>
>>
>>
>
--
Carsten Bock
http://www.ng-voice.com
mailto:cars...@ng-voice.com
Schomburgstr. 80
22767 Hamburg
Germany
Mobile +49 179 2021244
Office +49 40 34927219
Fax +49 40 34927220
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
