It's working now as expected.<br><br>Thanks<br><br><div class="gmail_quote">On Thu, Aug 13, 2009 at 12:59 PM, Bogdan-Andrei Iancu <span dir="ltr"><<a href="mailto:bogdan@voice-system.ro">bogdan@voice-system.ro</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">Hi Taner,<br>
<br>
Taner Sener wrote:<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi Bogdan,<div class="im"><br>
<br>
On Wed, Aug 12, 2009 at 3:56 PM, Bogdan-Andrei Iancu <<a href="mailto:bogdan@voice-system.ro" target="_blank">bogdan@voice-system.ro</a> <mailto:<a href="mailto:bogdan@voice-system.ro" target="_blank">bogdan@voice-system.ro</a>>> wrote:<br>
<br>
Hi Taner,<br>
<br>
Taner Sener wrote:<br>
<br>
Hi,<br>
<br>
I'm using Opensips 1.5.2 to distribute incoming calls to my<br>
clients using dispatcher module. I'm keeping my gateway list<br>
in db_mysql and use ds_select_dst("1", "4"); to select a<br>
gateway using round-robin algorithm. I have a few issues about<br>
the module behaviour.<br>
<br>
- The first one is about pinging. I've configured dispatcher<br>
to send ping requests every 20 seconds. But if destination is<br>
not available, ping requests are repeated every 4 seconds. I<br>
guess there is another module which repeats the unresponded<br>
sip messages. How can I prevent this and change the repeat<br>
timeout about this?<br>
<br>
there should be no second module to do the pinging, and there is<br>
no way the module can dynamically change the pinging interval.<br>
<br>
try enabling full debug (debug=6) and look for the log messages like:<br>
"probing set #n, URI xxxxxxxx "<br>
<br>
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.<br>
</div></blockquote>
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.<br>
<br>
You not control the retransmission interval via T1 and T2 params in TM (see <a href="http://www.opensips.org/html/docs/modules/1.5.x/tm.html#id228598" target="_blank">http://www.opensips.org/html/docs/modules/1.5.x/tm.html#id228598</a>), but note that this will have a global impact.<br>
<br>
Also you can configure how long the retransmission will be done via the fr_timer (see <a href="http://www.opensips.org/html/docs/modules/1.5.x/tm.html#id271112" target="_blank">http://www.opensips.org/html/docs/modules/1.5.x/tm.html#id271112</a>).<div class="im">
<br>
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
<br>
- The second issue is about selecting gateways. When I receive<br>
busy from one of the destinations I'm calling ds_next_dst()<br>
and this returns me a destination which is not alive and does<br>
not respond to ping requests. I'm expecting to have only<br>
destinations which are alive, and don't understand why it is<br>
returned. Another issue here is: I'm sending INVITE request to<br>
this dead destination and dead host is not responding as<br>
expected. After that, every 4 seconds INVITE request is<br>
repeated for this dead destination.<br>
<br>
you should call the ds_mark_dst() function from failure route,<br>
when you detect a destination as failed (and before the<br>
ds_next_dst() ). See:<br>
<br>
<a href="http://www.opensips.org/html/docs/modules/1.5.x/dispatcher.html#id271344" target="_blank">http://www.opensips.org/html/docs/modules/1.5.x/dispatcher.html#id271344</a><br>
<br>
<br>
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?<br>
</blockquote>
<br></div>
There are two ways to mark (as failed) a destination:<br>
<br>
1) from script, via ds_mark_dst() function, based on the negative replies you get when routing traffic to your destination.<br>
<br>
2) automatically, based on 408 replies received. You should see in logs debug like:<br>
OPTIONS-Request was finished with code XX (to xxxxxx, group xxxx)<br>
Setting the probing state failed (xx, group XX)<br>
<br>
<br>
<br>
Regards,<br><font color="#888888">
Bogdan<br>
<br>
</font></blockquote></div><br>