[SR-Users] Dispatcher stops working

Daniel-Constantin Mierla miconda at gmail.com
Mon Oct 12 15:38:49 CEST 2020


If you are not sure that keepalives are configured properly or next hop
gateways can reply promptly to OPTIONS keepalives, then just let
dispatcher route calls anyhow to gateways and set a low value for
retransmission timeout (see t_set_fr() from tm module). I noticed some
old gateways forget to send reply to OPTIONS from time to time.

You can also add event_route[...] blocks exposed by dispatcher module in
kamailio.cfg and trigger alerts when a destination is detected
inactive/back-active, making it easier to monitor what happens there.

Cheers,
Daniel

On 08.10.20 15:29, Sergio Charrua wrote:
> Sorry for the late reply....
>
> the dispatcher is set as follows:
>
> # ----- dispatcher params -----
> modparam("dispatcher", "list_file", DS_LIST)
> modparam("dispatcher", "flags", 2)
> modparam("dispatcher", "dst_avp", "$avp(AVP_DST)")
> modparam("dispatcher", "grp_avp", "$avp(AVP_GRP)")
> modparam("dispatcher", "cnt_avp", "$avp(AVP_CNT)")
> modparam("dispatcher", "sock_avp", "$avp(AVP_SOCK)")
> modparam("dispatcher", "ds_hash_size", 9)
> modparam("dispatcher", "dstid_avp", "$avp(dsdstid)")
> modparam("dispatcher", "ds_ping_latency_stats", 1)  
>
> I think it is correct, though what I wish is to set dispatcher on Load
> Balancing mode. 
>
> This is my dispatcher.list :
> 1 sip:10.19.XXX.YYY:5060 0 1 duid=sipgw01;maxload=100
> 1 sip:10.19.XXX.YYY:5060 0 2 duid=sipgw02;maxload=100
> 1 sip:10.19.XXX.YYY:5060 0 3 duid=sipgw03;maxload=100
> 1 sip:10.19.XXX.YYY:5060 0 4 duid=sipgw04;maxload=100
>
> This is my dispatch routes:
> # Dispatch requests
> route[DISPATCH] {
>         
>         if(!ds_select_dst("1", "10","4"))
>         {
>                 xlog("L_INFO","no destination selected from dispatcher
> list!");
>                 send_reply("404", "No destination");
>                 exit;
>         }
>
>         xlog("L_INFO","going to <$ru> via <$du>\n");
>
>         t_on_failure("RTF_DISPATCH");
>         route(RELAY);
>
>         exit;
>
> }
>
> Any clue? 
>
> *Sérgio Charrua*
>
> *
> *
>
> *www.voip.pt <http://www.voip.pt/>*
> Tel.: +351  <callto:+351+91+104+12+66>21 130 71 77
>
> Email : *sergio.charrua at voip.pt <mailto:sergio.charrua at voip.pt>*
>
> This message and any files or documents attached are strictly
> confidential or otherwise legally protected. 
>
> It is intended only for the individual or entity named. If you are not
> the named addressee or have received this email in error, please
> inform the sender immediately, delete it from your system and do not
> copy or disclose it or its contents or use it for any purpose. Please
> also note that transmission cannot be guaranteed to be secure or
> error-free.
>
>  
>
>  
>
>
>
>
>
> On Thu, Sep 17, 2020 at 3:49 AM Arsen Semenov <arsperger at gmail.com
> <mailto:arsperger at gmail.com>> wrote:
>
>
>     Hi Sergio,
>
>     Make sure your dispatcher probing parameters are set correctly.
>     (reply codes as well).
>
>     And if it happens again you can catch OPTIONS traffic with sngrep
>      "CSeq: [0-9]+ OPTIONS"
>     and see what happens on this level.
>     Whether Kamailio does send pings, whether replies from gw are the
>     same as expected, etc.  
>
>
>     Regards,
>
>     On Wed, Sep 16, 2020 at 5:55 PM David Villasmil
>     <david.villasmil.work at gmail.com
>     <mailto:david.villasmil.work at gmail.com>> wrote:
>
>         Hello 
>
>         I would start by looking at the logs when that happens. The
>         gateway would only get marked "ip" when there is no reply by
>         the gateway or when it replies with 500. Also OPTIONs not
>         being replied promptly.
>         Maybe add some logging right before ds_mark_dst("ip").
>
>         Hope that helps,
>
>         Regards,
>
>         David Villasmil
>         email: david.villasmil.work at gmail.com
>         <mailto:david.villasmil.work at gmail.com>
>         phone: +34669448337
>
>
>         On Wed, Sep 16, 2020 at 11:40 AM Sergio Charrua
>         <sergio.charrua at voip.pt <mailto:sergio.charrua at voip.pt>> wrote:
>
>             Hello,
>
>             Using Kamailio 5.1.6 for load balancing & failover, 
>             I noticed that from time to time, and very rarely, the
>             dispatcher module stops dispatching to the Asterisk servers. 
>             I have to execute a "kamcmd dispatcher reload" for it to
>             (re)start working.
>
>             This is my dispatcher.list :
>             1 sip:10.19.XXX.YYY:5060 0 1 duid=sipgw01;maxload=100
>             1 sip:10.19.XXX.YYY:5060 0 2 duid=sipgw02;maxload=100
>             1 sip:10.19.XXX.YYY:5060 0 3 duid=sipgw03;maxload=100
>             1 sip:10.19.XXX.YYY:5060 0 4 duid=sipgw04;maxload=100
>
>             This is my dispatch routes:
>             # Dispatch requests
>             route[DISPATCH] {
>                     
>                     if(!ds_select_dst("1", "10","4"))
>                     {
>                             xlog("L_INFO","no destination selected
>             from dispatcher list!");
>                             send_reply("404", "No destination");
>                             exit;
>                     }
>
>                     xlog("L_INFO","going to <$ru> via <$du>\n");
>
>                     t_on_failure("RTF_DISPATCH");
>                     route(RELAY);
>
>                     exit;
>
>             }
>
>             # Sample failure route
>             failure_route[RTF_DISPATCH] {
>                     if (t_is_canceled()) {
>                             exit;
>                     }
>                     xlog("L_INFO", "Media server $du failed to answer,
>             selecting other one!");
>                     # next DST - only for 500 or local timeout
>                     if ( t_check_status("500") || (t_branch_timeout()
>             && !t_branch_replied()) )
>                     {
>                             #mark the destination Inactive and Probing
>                             ds_mark_dst("ip");
>                             if(ds_next_dst())
>                             {
>                                     t_on_failure("RTF_DISPATCH");
>                                     route(RELAY);
>                                     exit;
>                             }
>                     }
>             }
>
>             I suspect that the ds_mark_dst("ip") command in
>             RTF_DISPACTH is the cause. 
>             Is there any think I can improve on this? Or any know bug
>             with the dispatcher in Kamailio 5.1.6 version?
>
>             Thanks in advance,
>
>             *Sérgio Charrua*
>
>
>             _______________________________________________
>             Kamailio (SER) - Users Mailing List
>             sr-users at lists.kamailio.org
>             <mailto:sr-users at lists.kamailio.org>
>             https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>             <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
>
>         _______________________________________________
>         Kamailio (SER) - Users Mailing List
>         sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
>         https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>         <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
>
>
>
>     -- 
>     Arsen Semenov
>
>     _______________________________________________
>     Kamailio (SER) - Users Mailing List
>     sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
>     https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>     <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201012/4038bffc/attachment.htm>


More information about the sr-users mailing list