[SR-Users] Bug in LDAP module?
Daniel-Constantin Mierla
miconda at gmail.com
Tue Dec 28 11:50:22 CET 2010
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:
>> 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 at 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 at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20101228/3d902fe1/attachment.htm>
More information about the sr-users
mailing list