[SR-Users] Dialogs not removed from memory, and occasionally persistent in DB as well

[Timo Reimann]

Hey,


Am 18.01.2012 um 13:46 schrieb Øyvind Kolbu:

> On 2012-01-17 at 23:47, Timo Reimann wrote:
>> Hey Øyvind,
>> Am 17.01.2012 um 13:41 schrieb Øyvind Kolbu:
>>> 
>>> Then in the main route:
>>> 
>>>       if !allow_trusted() {
>>>               route(AUTH);
>>>       }
>>> 
>>>       if (is_method("INVITE")) {
>>>           setflag(3);
>>>           dlg_manage();
>>> 
>>>           if ($avp(s:f_uid) != $null) {
>>>               set_dlg_profile("busy","$avp(s:f_uid)");
>>>               get_profile_size("busy", "$avp(s:f_uid)",
> "$var(dlg_busy)");
>>>               xlog("L_INFO", "BUSY: f_uid: $avp(s:f_uid), dlg_busy:
> $var(dlg_busy)\n");
>>>           }
>>>       }
>>> 
>>> $avp(s:f_uid) is set in route(AUTH), so it will catch calls
> originating from one of
>>> our users.
>> 
>> Do you possibly start to track dialogs before they are authenticated and
>> reply to unauthenticated INVITEs with 407 statelessly? IIRC, that causes
>> dialogs to dangle in state 1 ("unconfirmed") because the module requires
>> statefulness to operate and conclude dialog tracking properly.
> 
> No, we only do dlg_manage() after route(AUTH), as seen above.
> 
> Our route[AUTH] is below, slightly redacted, if you can spot any errors.
> Worth mentioning is that both trusted calls, from our Nortel pbx, and calls
> initiated from voip phones get stuck in the dialog memory.

Looks good to me. I wouldn't expect to spot the error there anyway since it's not related to dialog tracking.

Another possible root cause: After calling dlg_manage() on an INVITE, you do not forward the request (e.g., by calling exit() instead). Could that be the case? If so, the solution would be (again) to defer dialog tracking unless you're sure the INVITE will be routed.

If not, the last thing I can think of to try is to do some tracing (using ngrep or tcpdump, for example) and attempt to catch a dialog that dangles. If you succeed at that, analyzing the trace will probably help in determining the issue.


Cheers,

--Timo



> 
> # Route AUTH - LDAP authentication for hardphones REGISTER and INVITE
> route[AUTH] {
>        # if (isflagset(1)) {
>                # xlog("L_INFO", "ROUTE AUTH: Au length $(aU{s.len}) \n");
>        # }
> 
>        $var(digauth) = $aU + "x";
>        if ($var(digauth) == "x") {
>                if (is_method("REGISTER")) {
>                        www_challenge("uio.no","1");
>                } else {
>                        proxy_challenge("uio.no","1");
>                }
>                exit;
>        }
> 
>        # ldap search to authenticate the request
>        $var(res) =
> ldap_search("ldap://ldapprod/cn=clients,cn=voip,dc=uio,dc=no?sipMacAddress,sipSecret,sipVoipAddressDN,uid?one?(&(objectclass=sipClient)(|(sipMacAddress=$aU)(uid=$aU)))");
>        if (!$var(res)) {
>                switch ($retcode) {
>                        case -1:
>                                # no LDAP entry found
>                                xlog("L_INFO", "LDAPAUTH: no ldap entry
> found for $aU\n");
>                                sl_send_reply("404", "User Not Found");
>                                exit;
>                        case -2:
>                                # internal error
>                                xlog("L_INFO", "LDAPAUTH: (ldap) internal
> server error\n");
>                                sl_send_reply("500", "Internal server
> error");
>                                exit;
>                        default:
>                                xlog("L_INFO", "LDAPAUTH: (ldap) found
> $var(res) entries\n");
>                }
>        }
> 
>        # Pick from the first entry
>        # First try hardphone
>        if (!ldap_result("sipMacAddress/$avp(s:username)")) {
>                ldap_result("uid/$avp(s:username)");
>        }
>        ldap_result("sipSecret/$avp(s:password)");
>        ldap_result("sipVoipAddressDN/$avp(s:voipdn)");
> 
>        if (is_method("INVITE")) {
>                $avp(s:f_uid) = $(avp(s:voipdn){param.value,uid});
>        }
> 
>        if (is_method("REGISTER")) {
>                if(!pv_www_authenticate("uio.no", "$avp(s:password)","0")) {
>                        xlog("L_WARN", "ROUTE AUTH: FAILED authentication
> on REGISTER for username: $avp(s:username)\n");
>                        www_challenge("uio.no","1");
>                        exit;
>                }
>                if (isflagset(1)) {
>                        xlog("L_INFO", "LDAPAUTH: Successful
> authentication. Username $avp(s:username)\n");
>                }
>                return(1);
>        }
>        if(!pv_proxy_authenticate("uio.no", "$avp(s:password)", "0")) {
>                proxy_challenge("uio.no","1");
>                exit;
>        }
>        append_hf("UIO-edge-auth-uid: $avp(s:username)\r\n");
>        /* Now, remove credentials before passing the message on */
>        consume_credentials();
> 
>        if (is_method("INVITE")) {
>                ldap_search("ldap://ldapprod/cn=uris,cn=voip,dc=uio,dc=no?voipExtensionUri,cn,voipE164Uri?one?(&(objectClass=voipAddress)(uid=$avp(s:f_uid)))");
>                ldap_result("voipExtensionUri/$avp(s:f_exten)");
>                ldap_result("cn/$avp(s:f_name)");
>                ldap_result("voipE164Uri/$avp(s:f_e164)");
>                $avp(s:f_num) = "sip:" +
> $(avp(s:f_e164){uri.user}{s.strip,3}) + "@uio.no";
>                append_hf("P-Asserted-Identity: $avp(s:f_name)
> <$avp(s:f_e164)>\r\n");
>                # append_hf("Remote-Party-ID: \"$avp(s:f_name)\"
> <$avp(s:f_exten)>;privacy=off;screen=no\r\n");
>        }
> }
> 
> 
>> If that's the case, you have two options: Either return 407's statefully,
>> or defer dialog tracking until dialogs are authenticated. The former may
>> impose a security risk, the latter may (depending on your situation)
>> limit your dialog tracking needs.
> 
> We don't need dialog tracking until either a call is authenticated or it
> trusted, so that is fine our situation.
> 
> Our Kamailio has a tendency to send double replies for a request, e.g. two
> 200 OK for a single REGISTER. Most likely this is relevant to the
> dialog-module
> being confused.
> 
> -- 
> Øyvind Kolbu