[SR-Users] Dispatcher Confusion (v3.2.0)

Asgaroth 00asgaroth00 at gmail.com
Sat Oct 22 15:42:43 CEST 2011


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, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS,
> DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC,
> DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE,
> USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
> MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB
> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
> id: 25bedc
> compiled on 09:18:41 Oct 21 2011 with gcc 4.1.2
>
> Here we have the dispatcher state as loaded from db on startup in
> kamailio memory.
>
> # kamctl dispatcher dump
> SET_NO:: 2
> SET:: 1
>         URI:: sip:1.1.1.1:10001 flags=AX priority=0 attrs=
>         URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
> SET:: 2
>         URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
>         URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
>
> Now try set state for destination to inactive (Worked)
>
> # kamctl fifo ds_set_state i 1 sip:1.1.1.1:10001
> # kamctl dispatcher dump
> SET_NO:: 2
> SET:: 1
>         URI:: sip:1.1.1.1:10001 flags=IX priority=0 attrs=
>         URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
> SET:: 2
>         URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
>         URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
>
> Now try set state for destination to active (Worked)
>
> # kamctl fifo ds_set_state a 1 sip:1.1.1.1:10001
> # kamctl dispatcher dump
> SET_NO:: 2
> SET:: 1
>         URI:: sip:1.1.1.1:10001 flags=AX priority=0 attrs=
>         URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
> SET:: 2
>         URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
>         URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
>
> Now try set state for destination to inactive-probing (Worked)
>
> # kamctl fifo ds_set_state ip 1 sip:1.1.1.1:10001
> # kamctl dispatcher dump
> SET_NO:: 2
> SET:: 1
>         URI:: sip:1.1.1.1:10001 flags=IP priority=0 attrs=
>         URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
> SET:: 2
>         URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
>         URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
>
> I waited for OPTIONS/INFO message and checked state (Worked), changed
> state from IP -> AX
>
> # kamctl dispatcher dump
> SET_NO:: 2
> SET:: 1
>         URI:: sip:1.1.1.1:10001 flags=AX priority=0 attrs=
>         URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
> SET:: 2
>         URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
>         URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
>
> Now try set state to active-probing (Worked)
>
> # kamctl fifo ds_set_state ap 1 sip:1.1.1.1:10001
> # kamctl dispatcher dump
> SET_NO:: 2
> SET:: 1
>         URI:: sip:1.1.1.1:10001 flags=AP priority=0 attrs=
>         URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
> SET:: 2
>         URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
>         URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
>
> I waited for OPTIONS/INFO message and checked state (Worked), changed
> state from AP -> AX
>
> # kamctl dispatcher dump
> SET_NO:: 2
> SET:: 1
>         URI:: sip:1.1.1.1:10001 flags=AX priority=0 attrs=
>         URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
> SET:: 2
>         URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
>         URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
>
> Now try set state to disabled (Worked). At this point no pinging occured
> as destination is admin down.
>
> # kamctl fifo ds_set_state d 1 sip:1.1.1.1:10001
> # kamctl dispatcher dump
> SET_NO:: 2
> SET:: 1
>         URI:: sip:1.1.1.1:10001 flags=DX priority=0 attrs=
>         URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
> SET:: 2
>         URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
>         URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
>
> Now try set state to inactive-probing again, from disabled state (Worked)
>
> # kamctl fifo ds_set_state ip 1 sip:1.1.1.1:10001
> # kamctl dispatcher dump
> SET_NO:: 2
> SET:: 1
>         URI:: sip:1.1.1.1:10001 flags=IP priority=0 attrs=
>         URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
> SET:: 2
>         URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
>         URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
>
> I waited for OPTIONS/INFO message and checked state (Worked), changed
> state from IP -> AX
>
> # kamctl dispatcher dump
> SET_NO:: 2
> SET:: 1
>         URI:: sip:1.1.1.1:10001 flags=AX priority=0 attrs=
>         URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
> SET:: 2
>         URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
>         URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
>
> Thanks.
>
> 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 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 at:
>> https://www.kamailio.org/wiki/install/devel/git
>>
>> Cheers,
>> Daniel
>>
>>
>> On 10/20/11 7:52 PM, Asgaroth wrote:
>>> 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:
>>>
>>> version: kamailio 3.2.0 (i386/linux) 94d3b8
>>> 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_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE,
>>> USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
>>> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
>>> MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB
>>> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
>>> id: 94d3b8
>>> compiled on 12:34:43 Oct 20 2011 with gcc 4.1.2
>>>
>>>
>>> Here we start with the dispatcher list as it was pulled from the
>>> database and currently loaded in memory.
>>>
>>> # kamctl dispatcher dump
>>> SET_NO:: 2
>>> SET:: 1
>>>          URI:: sip:1.1.1.1:10001 flags=AX priority=0 attrs=
>>>          URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
>>> SET:: 2
>>>          URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
>>>          URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
>>>
>>> Now  I try to set one gateway inactive:
>>>
>>> # kamctl fifo ds_set_state i 1 sip:1.1.1.1:10001
>>> # kamctl dispatcher dump
>>> SET_NO:: 2
>>> SET:: 1
>>>          URI:: sip:1.1.1.1:10001 flags=IX priority=0 attrs=
>>>          URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
>>> SET:: 2
>>>          URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
>>>          URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
>>>
>>> All normal so far, now if I try to set the same gateway active again,
>>> the state still stays inactive, i dont seem to be able to change the
>>> state back to active. The same thing happens if I attempt to set this
>>> state to disabled and then try to set it back to active afterwards. The
>>> state does not change from what the first attempt was.
>>>
>>> # kamctl fifo ds_set_state a 1 sip:1.1.1.1:10001
>>> # kamctl dispatcher dump
>>> SET_NO:: 2
>>> SET:: 1
>>>          URI:: sip:1.1.1.1:10001 flags=IX priority=0 attrs=
>>>          URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
>>> SET:: 2
>>>          URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
>>>          URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
>>>
>>> Now I can try to set the state to inactive probing, that works.
>>>
>>> # kamctl fifo ds_set_state ip 1 sip:1.1.1.1:10001
>>> # kamctl dispatcher dump
>>> SET_NO:: 2
>>> SET:: 1
>>>          URI:: sip:1.1.1.1:10001 flags=IP priority=0 attrs=
>>>          URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
>>> SET:: 2
>>>          URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
>>>          URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
>>>
>>> Now if I try to disable the same destination:
>>>
>>> # kamctl fifo ds_set_state d 1 sip:1.1.1.1:10001
>>> # kamctl dispatcher dump
>>> SET_NO:: 2
>>> SET:: 1
>>>          URI:: sip:1.1.1.1:10001 flags=IP priority=0 attrs=
>>>          URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
>>> SET:: 2
>>>          URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
>>>          URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
>>>
>>> State still stays in Inactive/Probing mode.
>>>
>>> Now if I try to set the same gateway to active/probing mode, I cant:
>>>
>>> # kamctl fifo ds_set_state ap 1 sip:1.1.1.1:10001
>>> # kamctl dispatcher dump
>>> SET_NO:: 2
>>> SET:: 1
>>>          URI:: sip:1.1.1.1:10001 flags=IP priority=0 attrs=
>>>          URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
>>> SET:: 2
>>>          URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
>>>          URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
>>>
>>> The only way for me to get the state back to active after the above is
>>> to do a reload on the dispatch table:
>>>
>>> # kamctl dispatcher reload
>>> # kamctl dispatcher dump
>>> SET_NO:: 2
>>> SET:: 1
>>>          URI:: sip:1.1.1.1:10001 flags=AX priority=0 attrs=
>>>          URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs=
>>> SET:: 2
>>>          URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs=
>>>          URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs=
>>>
>>> Is the dispatcher expected to behave as above?
>>>
>>> I'm still trying to understand the different states assuming the
>>> following options are set in the configuration file:
>>>
>>> modparam("dispatcher", "ds_ping_interval", 10)
>>> modparam("dispatcher", "ds_probing_threshhold", 1)
>>> modparam("dispatcher", "ds_probing_mode", 0)
>>>
>>> AX = Active/No Probing
>>>      (*) Gateway is used in ds_select_*, ds_next_*
>>>      (*) No OPTIONS/INFO messages are sent to destination to check alive
>>> state
>>>
>>>      This appears to be the normal operating state with no issues
>>> detected.
>>>
>>> AP = Active/Probing
>>>      (*) Gateway is NOT used in ds_select_*, ds_next_*
>>>      (*) OPTIONS/INFO messages ARE sent to destination to check alive
>>> state
>>>
>>>      This appears to be the state taken when a gateway times out and
>>> ds_mark_dst("p") is set in failure route, the gateway is "pinged" while
>>> down and set into AX mode once a response is recieved.
>>>
>>> IX = Inactive/No Probing
>>>      (*) Gateway is NOT used in ds_select_*, ds_next_*
>>>      (*) No OPTIONS/INFO messages sent to destination
>>>
>>>      This appears to be the state taken when a gateway times out and if
>>> ds_mark_dst("i") is set in failure route, this gateway is set inactive
>>> and no "pinging" is performed.
>>>
>>> IP = Inactive/Probing
>>>      (*) Gateway is NOT used in ds_select_*, ds_next_*
>>>      (*) OPTIONS/INFO messages ARE sent to destination
>>>
>>>      I'm not sure when this state would be reached unless it is set by
>>> fifo command. The ds_mark_dst function only allows "a","i" or "p". So
>>> the probing method would only become active is ds_probing_mode = 1. In
>>> my case it is 0, so I'm not sure if I would ever reach this state unless
>>> I forced it. What would happen here is the gateway came back alive once
>>> in "IP" state, would it go back to "AX" state?
>>>
>>> DX = Disabled/No Probing
>>>      (*) Gateway is administratively set to down
>>>
>>>      This is where manual intervention has occured and the destination
>>> has been set to administrativly down, for example, work being carried
>>> out on the destination gateway.
>>>
>>> All these states make sense, for the most part, I'm a little unsure of
>>> how IP/IX is meant to work unless you manually set it to "inactive" in
>>> your failure route.
>>>
>>> The main concern though is the the fifo commands dont appear to be
>>> working as expected, I can only set the state for a destination manually
>>> once, and not again after that, unless I perform a dispatcher reload.
>>>
>>> Has anyone else experienced this behaviour?
>>>
>>> Any comments/suggestions explanations are most welcome.
>>>
>>> Thanks
>>>
>>> _______________________________________________
>>> 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
>
> _______________________________________________
> 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
>
>




More information about the sr-users mailing list