20 Jan
2012
20 Jan
'12
5:32 p.m.
Hey,
Am 18.01.2012 um 13:46 schrieb Øyvind Kolbu:
On 2012-01-17 at 23:47, Timo Reimann wrote:
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
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.
# 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}) + "(a)uio.no"o.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