o Juha Heinanen on 05/19/2011 08:07 PM:
Stefan Sayer writes:
are you sure you picked the right commit? I'm testing here with
ann_b2b (which essentially does the same), and it sends the reinvite
to next_hop_ip:next_hop_port which is 192.168.5.106:5062 in my case.
it must have been the right commit, because sems does not complain about
next_hop_ip and next_hop_port in sems.conf. also
it would not complaing about anything unknown in there...
# strings /usr/sbin/sems | egrep next_hop_ip
Invalid next_hop_ip '%.*s'
that's from transaction layer, was in there before; I get another
next_hop_ip string from the config.
can you PM/post me a debug log of the same region?
i'll do that in private email.
in your case, trans_layer::set_next_hop is called, which means the
next hop is definitely not set. Can you please apply this small debug
info output and run again? I would definitely like to know how
next_hop_ip is reset in your case, as there's no place in the code
that touches it.
diff --git a/core/AmSipDialog.cpp b/core/AmSipDialog.cpp
index 04ed18a..561c8b1 100644
--- a/core/AmSipDialog.cpp
+++ b/core/AmSipDialog.cpp
@@ -1032,6 +1032,10 @@ int AmSipDialog::sendRequest(const string& method,
req.body = body;
}
+ DBG("next_hop=%s:%u\n", next_hop_ip.c_str(), next_hop_port);
+ DBG("AmConfig::NextHopIP:Port = %s:%u\n",
+ AmConfig::NextHopIP.c_str(), AmConfig::NextHopPort);
+
if (SipCtrlInterface::send(req, next_hop_ip,
next_hop_port,outbound_interface))
return -1;
stefan
_______________________________________________
Semsdev mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/semsdev
