[OpenSIPS-Users] 1.5.2 dispatcher module behaviour

[Taner Sener]

It's working now as expected.

Thanks

On Thu, Aug 13, 2009 at 12:59 PM, Bogdan-Andrei Iancu <
bogdan at voice-system.ro> wrote:

> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/users/attachments/20090825/ca56fee3/attachment.htm