I would also say that if a gateway that's in the target set is being
rejected due to blacklist, the debug messages at loglevel 3 should
reflect this somehow.
They don't:
[#7fc6f690c700/6535] [resolve_targets, resolver.cpp:1080] DEBUG:
sip_destination: 123.123.123.123:0/udp
[#7fc6f690c700/6535] [set_destination_ip, resolver.cpp:1005] DEBUG:
checking whether '123.123.123.123' is IP address...
[#7fc6f690c700/6535] [set_destination_ip, resolver.cpp:1063] DEBUG:
set destination to 123.123.123.123:5060
[#7fc6f690c700/6535] [debug, resolver.cpp:794] DEBUG: target list:
[#7fc6f690c700/6535] [debug, resolver.cpp:801] DEBUG:
123.123.123.123:5060/udp to target list
[#7fc6f690c700/6535] [send_request, trans_layer.cpp:1267] DEBUG:
send_request to R-URI <sip:3879#[email protected]>
[#7fc6f690c700/6535] [send_request, trans_layer.cpp:1280] DEBUG:
next_ip(): no more destinations! reply 500
It wasn't until we hunted down sip_target_set::get_next() that we were
able to figure out what was going on:
https://github.com/sipwise/sems/blob/master/core/sip/resolver.cpp#L780
If this is "maximum" debug log verbosity, perhaps it should be more
useful in illuminating reasons for nonobvious behaviour?
This gateway blacklist is a new feature in 1.6:
[root@csrpsemsus1 sems]# fgrep -HR default_bl_ttl . | grep -v Binary
./core/SipCtrlInterface.cpp: if (cfg.hasParameter("default_bl_ttl")) {
./core/SipCtrlInterface.cpp: trans_layer::default_bl_ttl =
./core/SipCtrlInterface.cpp: cfg.getParameterInt("default_bl_ttl",
./core/SipCtrlInterface.cpp:
trans_layer::default_bl_ttl);
./core/SipCtrlInterface.cpp: DBG("default_bl_ttl =
%u\n",trans_layer::default_bl_ttl);
./core/sip/trans_layer.cpp:unsigned int _trans_layer::default_bl_ttl =
DEFAULT_BL_TTL;
./core/sip/trans_layer.cpp: if(default_bl_ttl) {
./core/sip/trans_layer.cpp:
default_bl_ttl,"503");
./core/sip/trans_layer.cpp:
default_bl_ttl,"503");
./core/sip/trans_layer.cpp: if(default_bl_ttl) {
./core/sip/trans_layer.cpp:
default_bl_ttl,"503");
./core/sip/trans_layer.cpp: if(default_bl_ttl) {
./core/sip/trans_layer.cpp:
default_bl_ttl,
./core/sip/trans_layer.cpp: if(default_bl_ttl) {
./core/sip/trans_layer.cpp:
default_bl_ttl,"503");
./core/sip/trans_layer.h: static unsigned int default_bl_ttl;
[root@csrpsemsus1 sems]# git checkout 1.5
Switched to branch '1.5'
[root@csrpsemsus1 sems]# fgrep -HR default_bl_ttl . | grep -v Binary
[root@csrpsemsus1 sems]#
And, insidiously, it's on _by default_. Shouldn't one be able to somehow
become aware of it without reading C++?
-- Alex
On 12/08/2015 09:04 PM, Alex Balashov wrote:
In 1.6, this parameter has profound effects but is not documented or
represented in any sample configs:
[root@csrpsemsus1 sems]# fgrep -HR default_bl_ttl . | grep -v Binary
./core/SipCtrlInterface.cpp: if (cfg.hasParameter("default_bl_ttl")) {
./core/SipCtrlInterface.cpp: trans_layer::default_bl_ttl =
./core/SipCtrlInterface.cpp: cfg.getParameterInt("default_bl_ttl",
./core/SipCtrlInterface.cpp:
trans_layer::default_bl_ttl);
./core/SipCtrlInterface.cpp: DBG("default_bl_ttl =
%u\n",trans_layer::default_bl_ttl);
./core/sip/trans_layer.cpp:unsigned int _trans_layer::default_bl_ttl =
DEFAULT_BL_TTL;
./core/sip/trans_layer.cpp: if(default_bl_ttl) {
./core/sip/trans_layer.cpp: default_bl_ttl,"503");
./core/sip/trans_layer.cpp:
default_bl_ttl,"503");
./core/sip/trans_layer.cpp: if(default_bl_ttl) {
./core/sip/trans_layer.cpp: default_bl_ttl,"503");
./core/sip/trans_layer.cpp: if(default_bl_ttl) {
./core/sip/trans_layer.cpp: default_bl_ttl,
./core/sip/trans_layer.cpp: if(default_bl_ttl) {
./core/sip/trans_layer.cpp: default_bl_ttl,"503");
./core/sip/trans_layer.h: static unsigned int default_bl_ttl;
I think this is a big problem. We had to track it down in the source to
figure out why 90% of our calls were being rejected out of hand with
'500 No destination available'.
--
Alex Balashov | Principal | Evariste Systems LLC
303 Perimeter Center North, Suite 300
Atlanta, GA 30346
United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
_______________________________________________
Sems mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/sems
