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
