Re: [SR-Users] dispatcher - ds_mark_dst("i"); is inactive only few seconds
Hello, On 2/2/11 5:51 PM, Thomas Baumann wrote: Dear sr-users, I use this straight forward dispatcher config. In the failure route I am calling this function: ds_mark_dst("i"); Also this action is logged: Feb 2 17:20:31 node5 /openser/sbin/kamailio[15945]: INFO: : FAIL_ONE:time [Wed Feb 2 17:20:31 2011] destination sip:10.12.19.31:5060 marked as inactive The gateway is inactive: [root@node5 ~]# kamctl 'fifo' ds_list URI:: sip:10.12.19.31:5060 flag=I priority=0 attrs=test1=123;test2=456 URI:: sip:10.12.19.21:5060 flag=A priority=0 attrs=test1=123;test2=456 Few seconds later the gateway is active again (there is still now response to SIP-OPTIONS) [root@node5 ~]# kamctl 'fifo' ds_list URI:: sip:10.12.19.31:5060 flag=A priority=0 attrs=test1=123;test2=456 URI:: sip:10.12.19.21:5060 flag=A priority=0 attrs=test1=123;test2=456 Does anybody have a idea why ? The next parameter will make all the addresses from dispatcher to be pinged periodically: modparam("dispatcher", "ds_probing_mode", 1) Are you sure the OPTIONS keepalive wasn't sent and replied? With the latest version I added a new state per gateway, that can disable it and no keepalive will be sent when in that state. What you can do is to run it with high debug value and watch the logs: log_stderror=yes debug=3 You can send me the output if it needs to be analyzed. Cheers, Daniel regards, Thomas DB: mysql> select * from dispatcher -> ; ++---+--+---+--+-+-+ | id | setid | destination | flags | priority | attrs | description | ++---+--+---+--+-+-+ | 1 | 1 | sip:10.12.19.21:5060 | 0 | 0 | test1=123;test2=456 | AS 1 | | 2 | 1 | sip:10.12.19.31:5060 | 0 | 0 | test1=123;test2=456 | AS 2 | ++---+--+---+--+-+-+ CONFIG: #!KAMAILIO ### Defined Values # #!define WITH_MYSQL #!define WITH_IPAUTH # *** Value defines - IDs used later in config #!ifdef WITH_MYSQL # - database URL - used to connect to database server by modules such # as: auth_db, acc, usrloc, a.s.o. #!define DBURL "mysql://openser:openserrw@10.12.18.51/openser" #!endif debug=2 log_stderror=no memdbg=5 memlog=5 log_facility=LOG_LOCAL0 fork=yes children=4 /* uncomment the next line to disable TCP (default on) */ #disable_tcp=yes /* uncomment the next line to disable the auto discovery of local aliases based on reverse DNS on IPs (default on) */ auto_aliases=no /* add local domain aliases */ alias="m-lab-ca805-sig.kd-lab.de:5060" alias="m-lab-ca805-sig.kd-lab.de" alias="10.12.19.51" /* uncomment and configure the following line if you want Kamailio to bind on a specific interface/port/proto (default bind on all available) */ listen=udp:10.12.19.51:5060 listen=tcp:10.12.19.51:5060 /* port to listen to * - can be specified more than once if needed to listen on many ports */ port=5060 ### Modules Section # set paths to location of modules mpath="/usr/local/kamailio-3.1/lib/kamailio/modules_k/:/usr/local/kamailio-3.1/lib/kamailio/modules/" # -- module loading -- loadmodule "mi_fifo.so" loadmodule "kex.so" loadmodule "tm.so" loadmodule "tmx.so" loadmodule "sl.so" loadmodule "rr.so" loadmodule "pv.so" loadmodule "maxfwd.so" loadmodule "textops.so" loadmodule "siputils.so" loadmodule "xlog.so" loadmodule "sanity.so" loadmodule "ctl.so" loadmodule "mi_rpc.so" loadmodule "acc.so" loadmodule "dialplan.so" loadmodule "avpops.so" loadmodule "dispatcher.so" #!ifdef WITH_IPAUTH loadmodule "permissions.so" #!endif #!ifdef WITH_MYSQL loadmodule "db_mysql.so" #!endif # - setting module-specific parameters --- # - tm params - # auto-discard branches from previous serial forking leg modparam("tm", "failure_reply_mode", 3) # default retransmission timeout: 30sec modparam("tm", "fr_timer", 3) # default invite retransmission timeout after 1xx: 120sec modparam("tm", "fr_inv_timer", 12) # - dispatcher params - #modparam("dispatcher", "list_file", "/openser/etc/kamailio/dispatcher.list") modparam("dispatcher", "db_url", DBURL) modparam("dispatcher", "table_name", "dispatcher") modparam("dispatcher", "ds_ping_interval", 30) modparam("dispatcher", "ds_probing_threshhold", 10) modparam("dispatcher", "ds_ping_reply_codes", "class=2;class=4") modparam("dispatcher", "ds_probing_mode", 1) modparam("dispatcher", "ds_ping_from", "sip:l...@m-lab-ca805-sig.kd-lab.de") modparam("dispatcher", "flags", 2) modparam("dispatcher", "dst_avp", "$avp(dsdst)") modparam("dispatcher", "grp_avp", "$avp(dsgrp)") modparam("dispatcher", "cnt_avp", "$avp(dscnt)") modparam("dispatcher", "attrs_avp", "$avp(dsattrs)") # - mi_fifo params - modparam("mi_fifo", "fifo_name", "/tmp/kamailio_fifo") # - permissions params - #!ifdef WITH_IPAUTH modparam("permiss
Re: [SR-Users] dispatcher - ds_mark_dst("i"); is inactive only few seconds
Hi Daniel, thanks for the hints, with debug_level they are some hints what happened. Normal Operation: 5(20410) DEBUG: dispatcher [dispatch.c:2305]: probing set #1, URI sip:10.12.19.31:5060 5(20410) DEBUG: dispatcher [dispatch.c:2305]: probing set #1, URI sip:10.12.19.21:5060 4(20409) DEBUG: dispatcher [dispatch.c:2250]: OPTIONS-Request was finished with code 200 (to sip:10.12.19.21:5060, group 1) 3(20407) DEBUG: dispatcher [dispatch.c:2250]: OPTIONS-Request was finished with code 200 (to sip:10.12.19.31:5060, group 1) Service is stopped at 10.12.19.21, the next INVITE with timeout will trigger ds_mark_dst("i"); This event will enable the Gateway again: 5(20410) DEBUG: dispatcher [dispatch.c:2250]: OPTIONS-Request was finished with code 408 (to sip:10.12.19.21:5060, group 1) But the funny part is that this 408 does not belong to a OPTION-Request. It was an reply to an INVITE. I disabled the parameter modparam("dispatcher", "ds_ping_reply_codes", "class=2;class=4") in the config, now the gateway remains inactive until a 200 ok is received for an option. I don't understand why this 408 matched. Why I need to trigger always ds_mark_dst("i"); , OPTIONS are send out anyway. Disabling the gateway could be done in the background, or maybe I missed something in the documentation. regards, Thomas ___ Empfehlen Sie WEB.DE DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.web.de ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] dispatcher - ds_mark_dst("i"); is inactive only few seconds
Hello, On 2/3/11 7:07 PM, Thomas Baumann wrote: Hi Daniel, thanks for the hints, with debug_level they are some hints what happened. Normal Operation: 5(20410) DEBUG: dispatcher [dispatch.c:2305]: probing set #1, URI sip:10.12.19.31:5060 5(20410) DEBUG: dispatcher [dispatch.c:2305]: probing set #1, URI sip:10.12.19.21:5060 4(20409) DEBUG: dispatcher [dispatch.c:2250]: OPTIONS-Request was finished with code 200 (to sip:10.12.19.21:5060, group 1) 3(20407) DEBUG: dispatcher [dispatch.c:2250]: OPTIONS-Request was finished with code 200 (to sip:10.12.19.31:5060, group 1) Service is stopped at 10.12.19.21, the next INVITE with timeout will trigger ds_mark_dst("i"); This event will enable the Gateway again: 5(20410) DEBUG: dispatcher [dispatch.c:2250]: OPTIONS-Request was finished with code 408 (to sip:10.12.19.21:5060, group 1) But the funny part is that this 408 does not belong to a OPTION-Request. It was an reply to an INVITE. it is very unlikely that a reply for an INVITE will match a keepalive OPTIONS request. Can you grap SIP trace for such case, along with debug messages? I disabled the parameter modparam("dispatcher", "ds_ping_reply_codes", "class=2;class=4") in the config, now the gateway remains inactive until a 200 ok is received for an option. I don't understand why this 408 matched. Why I need to trigger always ds_mark_dst("i"); , OPTIONS are send out anyway. Disabling the gateway could be done in the background, or maybe I missed something in the documentation. You have to trigger ds_marck_dst("i") if you want that the gw becomes inactive immediately, otherwise will be set inactive at next keepalive round. Cheers, Daniel regards, Thomas ___ Empfehlen Sie WEB.DE DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.web.de -- Daniel-Constantin Mierla http://www.asipto.com ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] dispatcher - ds_mark_dst("i"); is inactive only few seconds
Hello Daniel, I have checked the behavior again, without any load on the system I can see the 408 responses: OPTIONS-Request was finished with code 408 I guess this is the standard behavior if no answer is received from the gateway. regards, Thomas -Ursprüngliche Nachricht- Von: "Daniel-Constantin Mierla" Gesendet: 03.02.2011 21:38:49 An: "Thomas Baumann" Betreff: Re: [SR-Users] dispatcher - ds_mark_dst("i"); is inactive only few seconds Hello, On 2/3/11 7:07 PM, Thomas Baumann wrote: > Hi Daniel, > > thanks for the hints, with debug_level they are some hints what happened. > > Normal Operation: > > 5(20410) DEBUG: dispatcher [dispatch.c:2305]: probing set #1, URI > sip:10.12.19.31:5060 > 5(20410) DEBUG: dispatcher [dispatch.c:2305]: probing set #1, URI > sip:10.12.19.21:5060 > 4(20409) DEBUG: dispatcher [dispatch.c:2250]: OPTIONS-Request was finished > with code 200 (to sip:10.12.19.21:5060, group 1) > 3(20407) DEBUG: dispatcher [dispatch.c:2250]: OPTIONS-Request was finished > with code 200 (to sip:10.12.19.31:5060, group 1) > > Service is stopped at 10.12.19.21, the next INVITE with timeout will trigger > ds_mark_dst("i"); > > This event will enable the Gateway again: > > 5(20410) DEBUG: dispatcher [dispatch.c:2250]: OPTIONS-Request was finished > with code 408 (to sip:10.12.19.21:5060, group 1) > > But the funny part is that this 408 does not belong to a OPTION-Request. It > was an reply to an INVITE. it is very unlikely that a reply for an INVITE will match a keepalive OPTIONS request. Can you grap SIP trace for such case, along with debug messages? > I disabled the parameter modparam("dispatcher", "ds_ping_reply_codes", > "class=2;class=4") in the config, now the gateway remains inactive until a > 200 ok is received for an option. > > I don't understand why this 408 matched. Why I need to trigger always > ds_mark_dst("i"); , OPTIONS are send out anyway. Disabling the gateway could > be done in the background, or maybe I missed something in the documentation. You have to trigger ds_marck_dst("i") if you want that the gw becomes inactive immediately, otherwise will be set inactive at next keepalive round. Cheers, Daniel > regards, > > Thomas > > > > > > > > > ___ > Empfehlen Sie WEB.DE DSL Ihren Freunden und Bekannten und wir > belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.web.de -- Daniel-Constantin Mierla http://www.asipto.com ___ WEB.DE DSL Doppel-Flat ab 19,99 €/mtl.! Jetzt mit gratis Handy-Flat! http://produkte.web.de/go/DSL_Doppel_Flatrate/2 ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] dispatcher - ds_mark_dst("i"); is inactive only few seconds
Hello Thomas, On 2/4/11 6:21 PM, Thomas Baumann wrote: Hello Daniel, I have checked the behavior again, without any load on the system I can see the 408 responses: OPTIONS-Request was finished with code 408 I guess this is the standard behavior if no answer is received from the gateway. yes, it is a local generated 408 (timeout). This one is not seen on the network. If you want to enable back for some 4xx code but not for 408, then you have to use a list of code=4xx instead of class=4 in the dispatcher ds_ping_reply_codes parameter. Cheers, Daniel regards, Thomas -Ursprüngliche Nachricht- Von: "Daniel-Constantin Mierla" Gesendet: 03.02.2011 21:38:49 An: "Thomas Baumann" Betreff: Re: [SR-Users] dispatcher - ds_mark_dst("i"); is inactive only few seconds Hello, On 2/3/11 7:07 PM, Thomas Baumann wrote: Hi Daniel, thanks for the hints, with debug_level they are some hints what happened. Normal Operation: 5(20410) DEBUG: dispatcher [dispatch.c:2305]: probing set #1, URI sip:10.12.19.31:5060 5(20410) DEBUG: dispatcher [dispatch.c:2305]: probing set #1, URI sip:10.12.19.21:5060 4(20409) DEBUG: dispatcher [dispatch.c:2250]: OPTIONS-Request was finished with code 200 (to sip:10.12.19.21:5060, group 1) 3(20407) DEBUG: dispatcher [dispatch.c:2250]: OPTIONS-Request was finished with code 200 (to sip:10.12.19.31:5060, group 1) Service is stopped at 10.12.19.21, the next INVITE with timeout will trigger ds_mark_dst("i"); This event will enable the Gateway again: 5(20410) DEBUG: dispatcher [dispatch.c:2250]: OPTIONS-Request was finished with code 408 (to sip:10.12.19.21:5060, group 1) But the funny part is that this 408 does not belong to a OPTION-Request. It was an reply to an INVITE. it is very unlikely that a reply for an INVITE will match a keepalive OPTIONS request. Can you grap SIP trace for such case, along with debug messages? I disabled the parameter modparam("dispatcher", "ds_ping_reply_codes", "class=2;class=4") in the config, now the gateway remains inactive until a 200 ok is received for an option. I don't understand why this 408 matched. Why I need to trigger always ds_mark_dst("i"); , OPTIONS are send out anyway. Disabling the gateway could be done in the background, or maybe I missed something in the documentation. You have to trigger ds_marck_dst("i") if you want that the gw becomes inactive immediately, otherwise will be set inactive at next keepalive round. Cheers, Daniel regards, Thomas ___ Empfehlen Sie WEB.DE DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.web.de -- Daniel-Constantin Mierla http://www.asipto.com ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users