Occasionally SIP message transactions are not found when they should be.
In the particular case an incoming INVITE transaction is CANCELed but the
INVITE transaction cannot be found so a 481 response is returned for the
CANCEL. The problematic calls have a '_' character in the Via branch
parameter.
The problem is in the pjproject PJ_HASH_USE_OWN_TOLOWER feature's code.
The problem with the "own tolower" code is that it does not calculate the
same hash value as when the pj_tolower() function is used. The "own
tolower" code will erroneously modify the ASCII characters '@', '[', '\\',
']', '^', and '_'. Calls to pj_hash_calc_tolower() can use the
PJ_HASH_USE_OWN_TOLOWER substitute algorithm when enabled. Calls to
pj_hash_get_lower(), pj_hash_set_lower(), and pj_hash_set_np_lower() call
find_entry() which never uses the PJ_HASH_USE_OWN_TOLOWER algorithm. As a
result you may not be able to find a hash tabled entry because the
calculated hash values would differ.
* Simply disable PJ_HASH_USE_OWN_TOLOWER.
ASTERISK-26490 #close
Change-Id: If89bfdb5f301b8b685881a9a2a6e0c3c5af32253
#define PJ_DEBUG 0
#define PJSIP_SAFE_MODULE 0
#define PJ_HAS_STRICMP_ALNUM 0
-#define PJ_HASH_USE_OWN_TOLOWER 1
+
+/*
+ * Do not ever enable PJ_HASH_USE_OWN_TOLOWER because the algorithm is
+ * inconsistently used when calculating the hash value and doesn't
+ * convert the same characters as pj_tolower()/tolower(). Thus you
+ * can get different hash values if the string hashed has certain
+ * characters in it. (ASCII '@', '[', '\\', ']', '^', and '_')
+ */
+#undef PJ_HASH_USE_OWN_TOLOWER
+
/*
It is imperative that PJSIP_UNESCAPE_IN_PLACE remain 0 or undefined.
Enabling it will result in SEGFAULTS when URIs containing escape sequences are encountered.