Is the type of the 'rpid' column 'varchar'?
Odd data type incompatibility or client library version incompatibility
might explain it. I agree that it is bizarre.
Perhaps it would behoove you to turn on query logging on MySQL and
verify that the 'rpid' column is actually being selected in the query.
The only other thing I can think of would relate to one of the various
db_mode settings involved.
On 03/25/2010 06:08 PM, dotnetdub wrote:
Hi Alex,
I modified the script, same result. sip[8892]: INFO: <script>: [ROUTE-4
->] rpid test: <null> and the rpid is not being added.
Very odd..
Stephen.
On 25 March 2010 21:57, Alex Balashov <abalashov(a)evaristesys.com
<mailto:abalashov@evaristesys.com>> wrote:
On 03/25/2010 05:53 PM, dotnetdub wrote:
Attached:
if(is_uri_host_local()) {
if(!allow_trusted()) {
if(!proxy_authorize("",
"subscriber")) {
proxy_challenge("", "1");
exit;
}
else if(!check_from()) {
sl_send_reply("403",
"Forbidden");
exit;
}
}
else {
sl_send_reply("403", "Forbidden");
exit;
}
}
append_rpid_hf();
consume_credentials();
There is no guarantee that either append_rpid_hf() or
consume_credentials() runs if and only if proxy_authorize() was called.
Also, it is not clear why check_from() is at a relationship of
logical disjunction vis-a-vis to proxy_authorize(). While not
incorrect, it obfuscates the flow.
Try this and see if the problem continues:
if(is_uri_host_local()) {
if(!allow_trusted()) {
if(!proxy_authorize("", "subscriber")) {
proxy_challenge("", "1");
exit;
}
if(!check_from()) {
sl_send_reply("403",
"Forbidden");
exit;
}
append_rpid_hf();
consume_credentials();
}
else {
sl_send_reply("403", "Forbidden");
exit;
}
}
--
Alex Balashov - Principal
Evariste Systems LLC
Tel : +1 678-954-0670
Direct : +1 678-954-0671
Web :
http://www.evaristesys.com/
--
Alex Balashov - Principal
Evariste Systems LLC
Tel : +1 678-954-0670
Direct : +1 678-954-0671
Web :