27 Dec
2010
27 Dec
'10
6:03 p.m.
Hello,
We are using kamailio 1.5 and we have the following problem with ldap_search:
A call comes in. If it is to a VOIP user, it will be routed to kamailio, and eventually go
to the ldap lookup route: route[10] to look up the user.
This is always successful (LDAP can connect).
It will then look up user preferences (call forwarding etc.) from SQL in route[12] and
route based on this result in route[13].
If the result is "CFU (call forward unconditional) = on", the URI is changed and
route[10] (LDAP lookup) is called again.
This is always successful (LDAP can connect).
If the result is "CFB (call forward busy) = on" and the user is busy, the URI is
changed and route[10] (LDAP lookup) is called again.
This is also always successful (LDAP can connect).
If the result is "CFNR (call forward no reply) = on", the timeout is changed and
the call is delivered to the phone through route[14] (location) and route[15] (relay).
If the user does not answer, the URI is changed in failure_route[1] and route[10] is
called.
For some unknown reason, ldap_search always fails in this scenario with the messages:
"ldap_session not found", "couldn't get ldap session" and then
"no LDAP entry found".
Why?
And why does this result in the -1 return code and not the -2 return code for
ldap_search?
The only differences I can think of is that the unsuccessful scenario comes from
FAILURE_ROUTE instead of REQUEST_ROUTE, and that longer time has passed since the original
invite.
Here's a sample log:
NOTE the three ERROR lines, the INFO line and the ROUTE 10 line.
Dec 27 13:31:55 [3373]: INVITE received from sip:<CALLER>@<SBC_IP> <source
IP: <SBC_IP>> to sip:<CALLEE>@<KAM_IP>:
Dec 27 13:31:55 [3373]: ERROR:ldap:ldap_reconnect: [ldapprod]: LDAP reconnect successful
Dec 27 13:31:55 [3373]: ROUTE 10: LDAP returned: UID = <UID>, voipSipPrimaryUri =
<PRIMARY_URI>, voipExtensionUri = sip:<CALLEE>@<DOMAIN>
Dec 27 13:31:55 [3373]: ROUTE 12: Effective user properties for UID <UID>: CFU: off
<FORWARDTO>, CFB: off <FORWARDTO>, CFNR: on:25 <FORWARDTO>, CFNC: off
<FORWARDTO>, VM: <CALLEE>, busy_level: 1, DBrows: 1
Dec 27 13:31:55 [3373]: -------------------- Calling sip:<CALLEE>@<DOMAIN> for
25 seconds. --------------------
Dec 27 13:31:55 [3373]: ROUTE 15: Sending 105 INVITE from
sip:<CALLER>@<SBC_IP> to sip:<CALLEE>@<CALLEE_IP> (via
<<null>>)
Dec 27 13:31:55 [3383]: Response 100 Trying to Cseq 102 INVITE received from
<PROTO>:<CALLEE_IP>:<PORT>
Dec 27 13:31:55 [3385]: Response 180 Ringing to Cseq 102 INVITE received from
<PROTO>:<CALLEE_IP>:<PORT>
Dec 27 13:32:20 [3388]: FAILURE_ROUTE 1: Timeout for: 104 INVITE from <CALLER> ->
<CALLEE>
Dec 27 13:32:20 [3388]: -------------------- Forwarding on no reply to <FORWARDTO>
--------------------
Dec 27 13:32:20 [3388]: ERROR:ldap:get_connected_ldap_session: [ldapprod]: ldap_session
not found
Dec 27 13:32:20 [3388]: ERROR:ldap:lds_search: [ldapprod]: couldn't get ldap session
Dec 27 13:32:20 [3388]: INFO:ldap:ldap_search_impl: no LDAP entry found
Dec 27 13:32:20 [3388]: ROUTE 11: Number lookup results for <FORWARDTO>: Node:
VOIP.
Dec 27 13:32:20 [3388]: CONFIG ERROR: VOIP number not found in LDAP. Hanging up.
Dec 27 13:32:20 [3373]: Response 487 Request Cancelled to Cseq 102 INVITE received from
<PROTO>:<CALLEE_IP>:<PORT>
Here's the ldap config file:
[ldapprod]
ldap_server_url = "ldap://ldap.<DOMAIN>"
ldap_network_timeout = 500
ldap_client_bind_timeout = 500
kamailio config snippets (in case you need them):
# LDAP lookup for UID and primary URI
route[10] {
...
ldap_search("ldap://ldapprod/<DN>?uid,voipSipPrimaryUri,voipExtensionUri?one?(&(objectClass=voipAddress)(|(voipSipUri=sip:$rU@uio.no)(|(voipSipUri=$var(uri))(voipSipUri=$var(e164uri)))))");
if ($retcode < 1) {
switch ($retcode) {
case -1:
# no LDAP entry found
route(11);
return(1);
case -2:
# internal error
sl_send_reply("500", "Internal server error");
exit;
}
}
ldap_result("uid/$avp(s:uid)");
$avp(s:exten) = null;
if (!ldap_result("voipExtensionUri/$avp(s:exten)")) {
xlog("L_INFO", "voipExtensionUri not found.\n");
}
if (!ldap_result("voipSipPrimaryUri/$avp(s:p-uri)")) {
xlog("L_WARN", "voipSipPrimaryUri not found.\n");
#exit here?
}
if (isflagset(1)) {
xlog("L_INFO", "ROUTE 10: LDAP returned: UID = $avp(s:uid),
voipSipPrimaryUri = $avp(s:p-uri), voipExtensionUri = $avp(s:exten)\n");
}
if $avp(s:exten) != null {
$ru=$avp(s:exten);
} else {
$ru=$avp(s:p-uri);
}
route(12);
}
}
# Number lookup. Non-VoIP URI's go here.
route[11] {
...
}
# Database lookup for call forwarding.
route[12] {
...
}
# Call forwarding logic
route[13] {
if (is_method("INVITE")) {
$avp(s:uio_timer_avp) = "300";
if ($avp(s:cfu_status) == "on") {
# Forward immediately
xlog("L_INFO", "-------------------- $rU forwarded unconditionally to
$avp(s:cfu_number). --------------------\n");
$rU = $avp(s:cfu_number);
route(10);
}
...
if ( $var(dlg_busy) >= $avp(s:busy_level) ) {
if ($avp(s:cfb_status) == "on") {
xlog("L_INFO", "-------------------- $rU has $var(dlg_busy) active
calls. Treshold $avp(s:busy_level). Forwarding on busy to $avp(s:cfb_number)
--------------------\n");
$rU = $avp(s:cfb_number);
route(10);
}
...
else if ($avp(s:cfnr_status) == "on") {
# Forward to phone with timeout then to $avp(s:cfnr_number).
# t_set_fr($avp(s:cfnr_timeout) + "000"); # Recommended method in 3.1.
Function does not exist in 1.5. Using old method (avp).
$avp(s:uio_timer_avp) = $avp(s:cfnr_timeout);
xlog("L_INFO", "-------------------- Calling $ru for
$avp(s:uio_timer_avp) seconds. --------------------\n");
route(14);
}
...
}
failure_route[1] {
...
if $avp(s:cfnr_status) == "on" {
if (isflagset(1)) {
xlog("L_INFO", "FAILURE_ROUTE 1: Timeout for: $mi $rm from $fU ->
$rU\n");
}
revert_uri();
$rU = $avp(s:cfnr_number);
xlog("L_INFO", "-------------------- Forwarding on no reply to $rU
--------------------\n");
route(10);
}
...
}
With kind regards,
Pan
28 Dec
28 Dec
12:28 p.m.
Hello,
looking in the sources, at least for 3.x, ldap module does not connect
to server from timer process, the one that executes failure route for
local timeout.
I will fix it.
Cheers,
Daniel
On 12/27/10 5:03 PM, Pan B. Christensen wrote:
Hello,
We are using kamailio 1.5 and we have the following problem with
ldap_search:
A call comes in. If it is to a VOIP user, it will be routed to
kamailio, and eventually go to the ldap lookup route: route[10] to
look up the user.
This is always successful (LDAP can connect).
It will then look up user preferences (call forwarding etc.) from SQL
in route[12] and route based on this result in route[13].
If the result is "CFU (call forward unconditional) = on", the URI is
changed and route[10] (LDAP lookup) is called again.
This is always successful (LDAP can connect).
If the result is "CFB (call forward busy) = on" and the user is busy,
the URI is changed and route[10] (LDAP lookup) is called again.
This is also always successful (LDAP can connect).
If the result is "CFNR (call forward no reply) = on", the timeout is
changed and the call is delivered to the phone through route[14]
(location) and route[15] (relay).
If the user does not answer, the URI is changed in failure_route[1]
and route[10] is called.
For some unknown reason, ldap_search always fails in this scenario
with the messages: "ldap_session not found", "couldn't get ldap
session" and then "no LDAP entry found".
Why?
And why does this result in the -1 return code and not the -2 return
code for ldap_search?
The only differences I can think of is that the unsuccessful scenario
comes from FAILURE_ROUTE instead of REQUEST_ROUTE, and that longer
time has passed since the original invite.
Here's a sample log:
NOTE the three ERROR lines, the INFO line and the ROUTE 10 line.
Dec 27 13:31:55 [3373]: INVITE received from sip:<CALLER>@<SBC_IP>
<source IP: <SBC_IP>> to sip:<CALLEE>@<KAM_IP>:
Dec 27 13:31:55 [3373]: ERROR:ldap:ldap_reconnect: [ldapprod]: LDAP
reconnect successful
Dec 27 13:31:55 [3373]: ROUTE 10: LDAP returned: UID = <UID>,
voipSipPrimaryUri = <PRIMARY_URI>, voipExtensionUri =
sip:<CALLEE>@<DOMAIN>
Dec 27 13:31:55 [3373]: ROUTE 12: Effective user properties for UID
<UID>: CFU: off <FORWARDTO>, CFB: off <FORWARDTO>, CFNR: on:25
<FORWARDTO>, CFNC: off <FORWARDTO>, VM: <CALLEE>, busy_level: 1,
DBrows: 1
Dec 27 13:31:55 [3373]: -------------------- Calling
sip:<CALLEE>@<DOMAIN> for 25 seconds. --------------------
Dec 27 13:31:55 [3373]: ROUTE 15: Sending 105 INVITE from
sip:<CALLER>@<SBC_IP> to sip:<CALLEE>@<CALLEE_IP> (via
<<null>>)
Dec 27 13:31:55 [3383]: Response 100 Trying to Cseq 102 INVITE
received from <PROTO>:<CALLEE_IP>:<PORT>
Dec 27 13:31:55 [3385]: Response 180 Ringing to Cseq 102 INVITE
received from <PROTO>:<CALLEE_IP>:<PORT>
Dec 27 13:32:20 [3388]: FAILURE_ROUTE 1: Timeout for: 104 INVITE from
<CALLER> -> <CALLEE>
Dec 27 13:32:20 [3388]: -------------------- Forwarding on no reply to
<FORWARDTO> --------------------
Dec 27 13:32:20 [3388]: ERROR:ldap:get_connected_ldap_session:
[ldapprod]: ldap_session not found
Dec 27 13:32:20 [3388]: ERROR:ldap:lds_search: [ldapprod]: couldn't
get ldap session
Dec 27 13:32:20 [3388]: INFO:ldap:ldap_search_impl: no LDAP entry found
Dec 27 13:32:20 [3388]: ROUTE 11: Number lookup results for
<FORWARDTO>: Node: VOIP.
Dec 27 13:32:20 [3388]: CONFIG ERROR: VOIP number not found in LDAP.
Hanging up.
Dec 27 13:32:20 [3373]: Response 487 Request Cancelled to Cseq 102
INVITE received from <PROTO>:<CALLEE_IP>:<PORT>
Here's the ldap config file:
[ldapprod]
ldap_server_url = "ldap://ldap.<DOMAIN <ldap://ldap.%3CDOMAIN>>"
ldap_network_timeout = 500
ldap_client_bind_timeout = 500
kamailio config snippets (in case you need them):
# LDAP lookup for UID and primary URI
route[10] {
...
ldap_search("ldap://ldapprod/<DN>?uid,voipSipPrimaryUri,voipExtensionUri?one?(&(objectClass=voipAddress)(|(voipSipUri=sip:$rU@uio.no)(|(voipSipUri=$var(uri))(voipSipUri=$var(e164uri
<ldap://ldapprod/%3CDN%3E?uid,voipSipPrimaryUri,voipExtensionUri?one?%28&%28objectClass=voipAddress%29%28%7C%28voipSipUri=sip:$rU@uio.no%29%28%7C%28voipSipUri=$var%28uri%29%29%28voipSipUri=$var%28e164uri>)))))");
if ($retcode < 1) {
switch ($retcode) {
case -1:
# no LDAP entry found
route(11);
return(1);
case -2:
# internal error
sl_send_reply("500", "Internal server error");
exit;
}
}
ldap_result("uid/$avp(s:uid)");
$avp(s:exten) = null;
if (!ldap_result("voipExtensionUri/$avp(s:exten)")) {
xlog("L_INFO", "voipExtensionUri not found.\n");
}
if (!ldap_result("voipSipPrimaryUri/$avp(s:p-uri)")) {
xlog("L_WARN", "voipSipPrimaryUri not found.\n");
#exit here?
}
if (isflagset(1)) {
xlog("L_INFO", "ROUTE 10: LDAP returned: UID = $avp(s:uid),
voipSipPrimaryUri = $avp(s:p-uri), voipExtensionUri = $avp(s:exten)\n");
}
if $avp(s:exten) != null {
$ru=$avp(s:exten);
} else {
$ru=$avp(s:p-uri);
}
route(12);
}
}
# Number lookup. Non-VoIP URI's go here.
route[11] {
...
}
# Database lookup for call forwarding.
route[12] {
...
}
# Call forwarding logic
route[13] {
if (is_method("INVITE")) {
$avp(s:uio_timer_avp) = "300";
if ($avp(s:cfu_status) == "on") {
# Forward immediately
xlog("L_INFO", "-------------------- $rU forwarded unconditionally
to $avp(s:cfu_number). --------------------\n");
$rU = $avp(s:cfu_number);
route(10);
}
...
if ( $var(dlg_busy) >= $avp(s:busy_level) ) {
if ($avp(s:cfb_status) == "on") {
xlog("L_INFO", "-------------------- $rU has $var(dlg_busy)
active calls. Treshold $avp(s:busy_level). Forwarding on busy to
$avp(s:cfb_number) --------------------\n");
$rU = $avp(s:cfb_number);
route(10);
}
...
else if ($avp(s:cfnr_status) == "on") {
# Forward to phone with timeout then to $avp(s:cfnr_number).
# t_set_fr($avp(s:cfnr_timeout) + "000"); # Recommended method in
3.1. Function does not exist in 1.5. Using old method (avp).
$avp(s:uio_timer_avp) = $avp(s:cfnr_timeout);
xlog("L_INFO", "-------------------- Calling $ru for
$avp(s:uio_timer_avp) seconds. --------------------\n");
route(14);
}
...
}
failure_route[1] {
...
if $avp(s:cfnr_status) == "on" {
if (isflagset(1)) {
xlog("L_INFO", "FAILURE_ROUTE 1: Timeout for: $mi $rm from $fU ->
$rU\n");
}
revert_uri();
$rU = $avp(s:cfnr_number);
xlog("L_INFO", "-------------------- Forwarding on no reply to $rU
--------------------\n");
route(10);
}
...
}
With kind regards,
Pan
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla
Kamailio (OpenSER) Advanced Training
Jan 24-26, 2011, Irvine, CA, USA
http://www.asipto.com
12:50 p.m.
On 12/28/10 11:28 AM, Daniel-Constantin Mierla wrote:
Hello,
looking in the sources, at least for 3.x, ldap module does not connect
to server from timer process, the one that executes failure route for
local timeout.
I will fix it.
Seemed to be a feature -- ldap module had it this way from its
beginning. I committed the update that should create connection to Ldap
server from timer processes, so the functions should work now in failure
route in all cases.
The patch was committed on svn branch 1.5 as well, you need to fetch the
latest version from there and reinstall in order to try it.
Let me know if all works fine now.
Daniel
Cheers,
Daniel
On 12/27/10 5:03 PM, Pan B. Christensen wrote:
--
Daniel-Constantin Mierla
Kamailio (OpenSER) Advanced Training
Jan 24-26, 2011, Irvine, CA, USA
http://www.asipto.com
Hello,
We are using kamailio 1.5 and we have the following problem with
ldap_search:
A call comes in. If it is to a VOIP user, it will be routed to
kamailio, and eventually go to the ldap lookup route: route[10] to
look up the user.
This is always successful (LDAP can connect).
It will then look up user preferences (call forwarding etc.) from SQL
in route[12] and route based on this result in route[13].
If the result is "CFU (call forward unconditional) = on", the URI is
changed and route[10] (LDAP lookup) is called again.
This is always successful (LDAP can connect).
If the result is "CFB (call forward busy) = on" and the user is busy,
the URI is changed and route[10] (LDAP lookup) is called again.
This is also always successful (LDAP can connect).
If the result is "CFNR (call forward no reply) = on", the timeout is
changed and the call is delivered to the phone through route[14]
(location) and route[15] (relay).
If the user does not answer, the URI is changed in failure_route[1]
and route[10] is called.
For some unknown reason, ldap_search always fails in this scenario
with the messages: "ldap_session not found", "couldn't get ldap
session" and then "no LDAP entry found".
Why?
And why does this result in the -1 return code and not the -2 return
code for ldap_search?
The only differences I can think of is that the unsuccessful scenario
comes from FAILURE_ROUTE instead of REQUEST_ROUTE, and that longer
time has passed since the original invite.
Here's a sample log:
NOTE the three ERROR lines, the INFO line and the ROUTE 10 line.
Dec 27 13:31:55 [3373]: INVITE received from sip:<CALLER>@<SBC_IP>
<source IP: <SBC_IP>> to sip:<CALLEE>@<KAM_IP>:
Dec 27 13:31:55 [3373]: ERROR:ldap:ldap_reconnect: [ldapprod]: LDAP
reconnect successful
Dec 27 13:31:55 [3373]: ROUTE 10: LDAP returned: UID = <UID>,
voipSipPrimaryUri = <PRIMARY_URI>, voipExtensionUri =
sip:<CALLEE>@<DOMAIN>
Dec 27 13:31:55 [3373]: ROUTE 12: Effective user properties for UID
<UID>: CFU: off <FORWARDTO>, CFB: off <FORWARDTO>, CFNR: on:25
<FORWARDTO>, CFNC: off <FORWARDTO>, VM: <CALLEE>, busy_level: 1,
DBrows: 1
Dec 27 13:31:55 [3373]: -------------------- Calling
sip:<CALLEE>@<DOMAIN> for 25 seconds. --------------------
Dec 27 13:31:55 [3373]: ROUTE 15: Sending 105 INVITE from
sip:<CALLER>@<SBC_IP> to sip:<CALLEE>@<CALLEE_IP> (via
<<null>>)
Dec 27 13:31:55 [3383]: Response 100 Trying to Cseq 102 INVITE
received from <PROTO>:<CALLEE_IP>:<PORT>
Dec 27 13:31:55 [3385]: Response 180 Ringing to Cseq 102 INVITE
received from <PROTO>:<CALLEE_IP>:<PORT>
Dec 27 13:32:20 [3388]: FAILURE_ROUTE 1: Timeout for: 104 INVITE from
<CALLER> -> <CALLEE>
Dec 27 13:32:20 [3388]: -------------------- Forwarding on no reply
to <FORWARDTO> --------------------
Dec 27 13:32:20 [3388]: ERROR:ldap:get_connected_ldap_session:
[ldapprod]: ldap_session not found
Dec 27 13:32:20 [3388]: ERROR:ldap:lds_search: [ldapprod]: couldn't
get ldap session
Dec 27 13:32:20 [3388]: INFO:ldap:ldap_search_impl: no LDAP entry found
Dec 27 13:32:20 [3388]: ROUTE 11: Number lookup results for
<FORWARDTO>: Node: VOIP.
Dec 27 13:32:20 [3388]: CONFIG ERROR: VOIP number not found in LDAP.
Hanging up.
Dec 27 13:32:20 [3373]: Response 487 Request Cancelled to Cseq 102
INVITE received from <PROTO>:<CALLEE_IP>:<PORT>
Here's the ldap config file:
[ldapprod]
ldap_server_url = "ldap://ldap.<DOMAIN <ldap://ldap.%3CDOMAIN>>"
ldap_network_timeout = 500
ldap_client_bind_timeout = 500
kamailio config snippets (in case you need them):
# LDAP lookup for UID and primary URI
route[10] {
...
ldap_search("ldap://ldapprod/<DN>?uid,voipSipPrimaryUri,voipExtensionUri?one?(&(objectClass=voipAddress)(|(voipSipUri=sip:$rU@uio.no)(|(voipSipUri=$var(uri))(voipSipUri=$var(e164uri
<ldap://ldapprod/%3CDN%3E?uid,voipSipPrimaryUri,voipExtensionUri?one?%28&%28objectClass=voipAddress%29%28%7C%28voipSipUri=sip:$rU@uio.no%29%28%7C%28voipSipUri=$var%28uri%29%29%28voipSipUri=$var%28e164uri>)))))");
if ($retcode < 1) {
switch ($retcode) {
case -1:
# no LDAP entry found
route(11);
return(1);
case -2:
# internal error
sl_send_reply("500", "Internal server error");
exit;
}
}
ldap_result("uid/$avp(s:uid)");
$avp(s:exten) = null;
if (!ldap_result("voipExtensionUri/$avp(s:exten)")) {
xlog("L_INFO", "voipExtensionUri not found.\n");
}
if (!ldap_result("voipSipPrimaryUri/$avp(s:p-uri)")) {
xlog("L_WARN", "voipSipPrimaryUri not found.\n");
#exit here?
}
if (isflagset(1)) {
xlog("L_INFO", "ROUTE 10: LDAP returned: UID = $avp(s:uid),
voipSipPrimaryUri = $avp(s:p-uri), voipExtensionUri = $avp(s:exten)\n");
}
if $avp(s:exten) != null {
$ru=$avp(s:exten);
} else {
$ru=$avp(s:p-uri);
}
route(12);
}
}
# Number lookup. Non-VoIP URI's go here.
route[11] {
...
}
# Database lookup for call forwarding.
route[12] {
...
}
# Call forwarding logic
route[13] {
if (is_method("INVITE")) {
$avp(s:uio_timer_avp) = "300";
if ($avp(s:cfu_status) == "on") {
# Forward immediately
xlog("L_INFO", "-------------------- $rU forwarded unconditionally
to $avp(s:cfu_number). --------------------\n");
$rU = $avp(s:cfu_number);
route(10);
}
...
if ( $var(dlg_busy) >= $avp(s:busy_level) ) {
if ($avp(s:cfb_status) == "on") {
xlog("L_INFO", "-------------------- $rU has $var(dlg_busy)
active calls. Treshold $avp(s:busy_level). Forwarding on busy to
$avp(s:cfb_number) --------------------\n");
$rU = $avp(s:cfb_number);
route(10);
}
...
else if ($avp(s:cfnr_status) == "on") {
# Forward to phone with timeout then to $avp(s:cfnr_number).
# t_set_fr($avp(s:cfnr_timeout) + "000"); # Recommended method in
3.1. Function does not exist in 1.5. Using old method (avp).
$avp(s:uio_timer_avp) = $avp(s:cfnr_timeout);
xlog("L_INFO", "-------------------- Calling $ru for
$avp(s:uio_timer_avp) seconds. --------------------\n");
route(14);
}
...
}
failure_route[1] {
...
if $avp(s:cfnr_status) == "on" {
if (isflagset(1)) {
xlog("L_INFO", "FAILURE_ROUTE 1: Timeout for: $mi $rm from $fU ->
$rU\n");
}
revert_uri();
$rU = $avp(s:cfnr_number);
xlog("L_INFO", "-------------------- Forwarding on no reply to $rU
--------------------\n");
route(10);
}
...
}
With kind regards,
Pan
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla
Kamailio (OpenSER) Advanced Training
Jan 24-26, 2011, Irvine, CA, USA
http://www.asipto.com
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users 
14 Jan
14 Jan
7:08 a.m.
On Tue, Dec 28, 2010 at 11:50:22AM +0100, Daniel-Constantin Mierla wrote:
Seemed to be a feature -- ldap module had it this way
from its
beginning. I committed the update that should create connection to Ldap
server from timer processes, so the functions should work now in failure
route in all cases.
The patch was committed on svn branch 1.5 as well, you need to fetch the
latest version from there and reinstall in order to try it.
Let me know if all works fine now.
Hi Pan
Do you have comment on the above patch by Daniel-Constantin?
I plan to use ldap module soon and would like to hear if this issue
you reported is now non existent.
Thanks!
--
Mikko
18 Jan
18 Jan
6:44 p.m.
----- Original Message -----
From: "Mikko Lehto" <mikko.lehto(a)setera.fi>
To: "Pan B. Christensen" <pan(a)ibidium.no>
Cc: <sr-users(a)lists.sip-router.org>
Sent: Friday, January 14, 2011 6:08 AM
Subject: Re: [SR-Users] Bug in LDAP module?
Hi Pan
Do you have comment on the above patch by Daniel-Constantin?
I plan to use ldap module soon and would like to hear if this issue
you reported is now non existent.
Thanks!
--
Mikko
Unfortunately, I havn't been able to test it yet, and probably won't be for
a long time.
The customer has gone into production, and they have a fairly complicated /
non-standard installation. They didn't want to do a new compile at this
time.
I did compile it on the new test rig, but I can't start that instance until
the customer gets their PGSQL server for that rig up and running.
For now, I just made a workaround with a loop check which does the
following:
If LDAP lookup returns nothing, the call should not be to a voip user.
My original code would then check the number database to see where the
number should be routed (one of the old Nortel PBXes or to PSTN if not
found). If the answer is VoIP, I would normally log a line about config
error and terminate the call because this should not happen. I edited this
so that if the X-LDAPLOOP header is not present, add it and do not change
$rd. If the header is present, terminate the call.
$rU was changed in failure_route before attempting to call the LDAP lookup
route (10). By not changing $rd in this scenario, the new INVITE will be
sent to self. The new call (INVITE from Kamailio to Kamailio) will do LDAP
lookup just fine. It's ugly, but it works.
Here's some code snippets:
route[10] {
...
ldap_search("ldap://...");
}
if ($retcode < 1) {
switch ($retcode) {
case -1:
# no LDAP entry found
route(11);
return(1);
...
}
route[11] {
...
sql_query("data1","select ...", "num");
if ($dbr(num=>rows) > 0) {
$avp(s:num_node)=$dbr(num=>[0,0]);
if (isflagset(1)) {
xlog("L_INFO", "ROUTE 11: Number lookup
results for $rU: Node: $avp(s:num_node).\n");
}
if $avp(s:num_node)=="VOIP" {
# VOIP number not found in LDAP. This should
not happen. - With new workaround for LDAP bug.
if (is_present_hf("X-UIO-LDAPLOOP")) {
xlog("L_WARN", "CONFIG ERROR: VOIP
number still not found in LDAP after workaround. Hanging up.\n");
sl_send_reply("404", "Not
found");
sql_result_free("num");
exit;
}
xlog("L_INFO", "VOIP number not in LDAP.
LDAP bug? Relaying to self as workaround.\n");
append_hf("X-UIO-LDAPLOOP: 1\r\n");
}
...
}
The idea is to send to self in this scenario, and when that new transaction
(from self) is processed the driver will perform just fine.
With kind regards,
Pan B. Christensen
Senior technician
Ibidium AS
http://www.ibidium.no/
26 Apr
26 Apr
4:46 p.m.
----- Original Message -----
From: "Mikko Lehto" <mikko.lehto(a)setera.fi>
On Tue, Dec 28, 2010 at 11:50:22AM +0100,
Daniel-Constantin Mierla wrote:
Hello Mikko and Daniel,
I'm happy to report that I've now finally been able to test the fix, and
that it works as intended. LDAP queries can now be carried out also from
failure route.
With kind regards,
Pan B. Christensen
--------------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.449 / Virus Database: 271.1.1/3376 - Release Date: 01/12/11
19:34:00
Seemed to be a feature -- ldap module had it this
way from its
beginning. I committed the update that should create connection to Ldap
server from timer processes, so the functions should work now in failure
route in all cases.
The patch was committed on svn branch 1.5 as well, you need to fetch the
latest version from there and reinstall in order to try it.
Let me know if all works fine now.
Hi Pan
Do you have comment on the above patch by Daniel-Constantin?
I plan to use ldap module soon and would like to hear if this issue
you reported is now non existent.
4959
days inactive
5079
days old
5 comments
3 participants
participants (3)
-
Daniel-Constantin Mierla -
Mikko Lehto -
Pan B. Christensen