[OpenSIPS-Users] 1.5.2 dispatcher module behaviour

[Bogdan-Andrei Iancu]

Hi Taner,

Taner Sener wrote:
> Hi Bogdan,
>
> On Wed, Aug 12, 2009 at 3:56 PM, Bogdan-Andrei Iancu 
> <bogdan at voice-system.ro <mailto:bogdan at voice-system.ro>> wrote:
>
>     Hi Taner,
>
>     Taner Sener wrote:
>
>         Hi,
>
>         I'm using Opensips 1.5.2 to distribute incoming calls to my
>         clients using dispatcher module. I'm keeping my gateway list
>         in db_mysql and use ds_select_dst("1", "4"); to select a
>         gateway using round-robin algorithm. I have a few issues about
>         the module behaviour.
>
>         - The first one is about pinging. I've configured dispatcher
>         to send ping requests every 20 seconds. But if destination is
>         not available, ping requests are repeated every 4 seconds. I
>         guess there is another module which repeats the unresponded
>         sip messages. How can I prevent this and change the repeat
>         timeout about this?
>
>     there should be no second module to do the pinging, and there is
>     no way the module can dynamically change the pinging interval.
>
>     try enabling full debug (debug=6) and look for the log messages like:
>       "probing set #n, URI xxxxxxxx  "
>
>  
> I looked inside logs and found "DBG:dispatcher:ds_check_timer: probing 
> set #1, URI sip:" lines there. So i guess it means that timer has 
> expired and dispatcher is sending SIP OPTIONS at that time. But later 
> found that TM module was enabled in my configuration and it was TM 
> retransmitting SIP OPTIONS to dead destinations (with T2_timer which 
> is 4 seconds). I can increase T2_timer but it will effect other 
> messages, so I will leave it as is.
Aha....The dispatcher module uses TM support for sending the pings in a 
statefull manner - so, if there is no reply at all, the TM will do 
retransmission of the original request it send. It was not clear from 
your original email if new OPTIONS are fire (at each 2 secs) or what you 
are simply retransmissions (copies) of the pings that were already sent out.

You not control the retransmission interval via T1 and T2 params in TM 
(see http://www.opensips.org/html/docs/modules/1.5.x/tm.html#id228598), 
but note that this will have a global impact.

Also you can configure how long the retransmission will be done via the 
fr_timer (see 
http://www.opensips.org/html/docs/modules/1.5.x/tm.html#id271112).


>  
>
>
>
>         - The second issue is about selecting gateways. When I receive
>         busy from one of the destinations I'm calling ds_next_dst()
>         and this returns me a destination which is not alive and does
>         not respond to ping requests. I'm expecting to have only
>         destinations which are alive, and don't understand why it is
>         returned. Another issue here is: I'm sending INVITE request to
>         this dead destination and dead host is not responding as
>         expected. After that, every 4 seconds INVITE request is
>         repeated for this dead destination.
>
>     you should call the ds_mark_dst() function from failure route,
>     when you detect a destination as failed (and before the
>     ds_next_dst() ). See:
>
>      
>     http://www.opensips.org/html/docs/modules/1.5.x/dispatcher.html#id271344
>
>
> I thought that if a destination is not alive and not responding to 
> PING requests (in my case Destination Unreachable ICMP messages are 
> received), it is marked as failure route automatically, but it looks 
> like I must mark it by myself. At this point I want to ask if I can 
> listen for results of PING resuls. So if I receive REPLY I will mark 
> it as healthy and if PING timeout occurs I can mark it as dead. BTW 
> are Destination Unreachable ICMP messages identified by opensips?

There are two ways to mark (as failed) a destination:

    1) from script, via ds_mark_dst() function, based on the negative 
replies you get when routing traffic to your destination.

    2) automatically, based on 408 replies received. You should see in 
logs debug like:
             OPTIONS-Request was finished with code XX (to xxxxxx, group 
xxxx)
             Setting the probing state failed (xx, group XX)



Regards,
Bogdan