Re: [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 <
bog...@voice-system.ro> wrote:

> Hi Taner,
>
> Taner Sener wrote:
>
>> Hi Bogdan,
>>
>> On Wed, Aug 12, 2009 at 3:56 PM, Bogdan-Andrei Iancu <
>> bog...@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   "
>>
>>  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.
>>
> AhaThe 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 xx, group
> )
>Setting the probing state failed (xx, group XX)
>
>
>
> Regards,
> Bogdan
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [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 
> mailto:bog...@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   "
>
>  
> 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.
AhaThe 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 xx, group 
)
 Setting the probing state failed (xx, group XX)



Regards,
Bogdan


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] 1.5.2 dispatcher module behaviour

[Taner Sener]

Hi Bogdan,

On Wed, Aug 12, 2009 at 3:56 PM, Bogdan-Andrei Iancu  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   "


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.


>
>
>> - 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?

Thanks,
Taner


>
>
>
> Regards,
> Bogdan
>
>>
>>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] 1.5.2 dispatcher module behaviour

[Bogdan-Andrei Iancu]

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   "
>
> - 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



Regards,
Bogdan
>
> How can I fix these issues?
>
> Thanks,
>
> 
> modparam("dispatcher", "db_url", 
> "mysql://opensips:opensip...@localhost/opensips")
> modparam("dispatcher", "table_name", "dispatcher")
> modparam("dispatcher", "setid_col", "setid")
> modparam("dispatcher", "destination_col", "destination")
> modparam("dispatcher", "flags_col", "flags")
> modparam("dispatcher", "flags", 3)
> modparam("dispatcher", "force_dst", 1)
> modparam("dispatcher", "ds_ping_method", "OPTIONS")
> modparam("dispatcher", "ds_ping_from", "sip:dispatc...@10.210.154.201 
> ")
> modparam("dispatcher", "ds_ping_interval", 20)
> modparam("dispatcher", "ds_probing_threshhold", 1)
> modparam("dispatcher", "ds_probing_mode", 1)
> #modparam("dispatcher", "use_default", 0)
> modparam("dispatcher", "dst_avp", "$avp(i:271)")
> modparam("dispatcher", "grp_avp", "$avp(i:272)")
> modparam("dispatcher", "cnt_avp", "$avp(i:273)")
> 
> t_on_failure("11");
>  
> ds_select_dst("1", "4");
>
> xlog("L_INFO","ds_dispatcher $avp(i:271) $avp(i:272) $avp(i:273)");
> xlog("L_INFO","ds_dispatcher Trying first route $dd $od $rd $td $br");
>  
> t_relay();
> 
> failure_route[11] {
> xlog("L_INFO","ds_dispatcher First route failed. Trying second");
> if(t_check_status("408") ){
>  if (ds_next_dst()){
>  xlog("L_INFO","ds_dispatcher $avp(i:271) $avp(i:272) 
> $avp(i:273)");
>  t_on_failure("11");
>  t_relay();
> } else {
> xlog("L_INFO","ds_dispatcher Can not select the second 
> one");
> }
> } else if (t_check_status("486")) {
>  if (ds_next_dst()){
>  xlog("L_INFO","ds_dispatcher $avp(i:271) $avp(i:272) 
> $avp(i:273)");
>  t_on_failure("11");
>  t_relay();
> } else {
> xlog("L_INFO","ds_dispatcher Can not select the second 
> one");
> }
> } else {
> xlog("L_INFO","ds_dispatcher Run out of servers in 
> dispatcher.list");
> }
> }
>
>
> 
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>   


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] 1.5.2 dispatcher module behaviour

[Taner Sener]

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?

- 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.

How can I fix these issues?

Thanks,


modparam("dispatcher", "db_url", "mysql://opensips:opensip...@localhost
/opensips")
modparam("dispatcher", "table_name", "dispatcher")
modparam("dispatcher", "setid_col", "setid")
modparam("dispatcher", "destination_col", "destination")
modparam("dispatcher", "flags_col", "flags")
modparam("dispatcher", "flags", 3)
modparam("dispatcher", "force_dst", 1)
modparam("dispatcher", "ds_ping_method", "OPTIONS")
modparam("dispatcher", "ds_ping_from",
"sip:dispatc...@10.210.154.201
")
modparam("dispatcher", "ds_ping_interval", 20)
modparam("dispatcher", "ds_probing_threshhold", 1)
modparam("dispatcher", "ds_probing_mode", 1)
#modparam("dispatcher", "use_default", 0)
modparam("dispatcher", "dst_avp", "$avp(i:271)")
modparam("dispatcher", "grp_avp", "$avp(i:272)")
modparam("dispatcher", "cnt_avp", "$avp(i:273)")

t_on_failure("11");

ds_select_dst("1", "4");

xlog("L_INFO","ds_dispatcher $avp(i:271) $avp(i:272) $avp(i:273)");
xlog("L_INFO","ds_dispatcher Trying first route $dd $od $rd $td $br");

t_relay();

failure_route[11] {
xlog("L_INFO","ds_dispatcher First route failed. Trying second");
if(t_check_status("408") ){
 if (ds_next_dst()){
 xlog("L_INFO","ds_dispatcher $avp(i:271) $avp(i:272)
$avp(i:273)");
 t_on_failure("11");
 t_relay();
} else {
xlog("L_INFO","ds_dispatcher Can not select the second
one");
}
} else if (t_check_status("486")) {
 if (ds_next_dst()){
 xlog("L_INFO","ds_dispatcher $avp(i:271) $avp(i:272)
$avp(i:273)");
 t_on_failure("11");
 t_relay();
} else {
xlog("L_INFO","ds_dispatcher Can not select the second
one");
}
} else {
xlog("L_INFO","ds_dispatcher Run out of servers in
dispatcher.list");
}
}
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users