THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
A user has added themself to the list of users assigned to this task.
FS#61 - more user friendly module function fixup system
User who did this - Juha Heinanen (jh)
http://sip-router.org/tracker/index.php?do=details&task_id=61
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
another possibility to make fixups scalable would be to specify the
argument of the fixup function, something like
{"test", (cmd_function)test, generic_fixup, "pvar,str,spve", REQUEST_ROUTE |
FAILURE_ROUTE},
then it would be easy to write this generic fixup function that would
accept a list of known parameter types as the argument.
now that functions can have more than two args, the fixup system must be
fixed in order to make writing of modules easier. i would be trivial
for me to clean the enum module functions if the fixup system would be
more user friendly.
-- juha
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
A new Flyspray task has been opened. Details are below.
User who did this - Ovidiu Sas (osas)
Attached to Project - sip-router
Summary - kamailio 3.0.x: segfault in carrierroute
Task Type - Bug Report
Category - Module
Status - Unconfirmed
Assigned To -
Operating System - All
Severity - Critical
Priority - Normal
Reported Version - Development
Due in Version - Undecided
Due Date - Undecided
Details - If a cr_route is called via PVs and the carrier pv is pointing to a non existing carrier, it segfaults.
from the config file:
xlog("L_INFO","[$mi] cr_route(\"$avp(i:707)\", \"$var(domain)\");\n");
if (cr_route("$avp(i:707)", "$var(domain)", "$rU", "$rU", "call_id")) {
And the logs shows:
INFO: <script>: [1] cr_route("3", "1");
ALERT: <core> [main.c:722]: child process 4152 exited by a signal 11
There's no carrier 3 in my routes, but this should not crash the server.
Here's the backtrace:
(gdb) bt
#0 0x00a0c16a in strnlen () from /lib/libc.so.6
#1 0x009dba0d in vfprintf () from /lib/libc.so.6
#2 0x00a6a236 in __vsyslog_chk () from /lib/libc.so.6
#3 0x00a6a43a in syslog () from /lib/libc.so.6
#4 0x0051d917 in cr_do_route (_msg=0x82a74d0, _carrier=0x82a16a0, _domain=0x82a2968, _prefix_matching=0x82a29f0, _rewrite_user=0x82a2a58, _hsrc=shs_call_id, _halg=alg_crc32,
_dstavp=0x0) at cr_func.c:102
#5 0x0051e5c0 in cr_route5 (_msg=0x82a74d0, _carrier=0x82a16a0, _domain=0x82a2968, _prefix_matching=0x82a29f0, _rewrite_user=0x82a2a58, _hsrc=shs_call_id) at cr_func.c:684
#6 0x08057d81 in do_action (h=0xbfb38fe8, a=0x8288d00, msg=0x82a74d0) at action.c:911
#7 0x0805a8bd in run_actions (h=0xbfb38fe8, a=0x8288d00, msg=0x82a74d0) at action.c:1293
#8 0x080dad54 in rval_get_int (h=0xbfb38fe8, msg=0x947368, i=0xbfb38954, rv=0x94762b, cache=0x0) at rvalue.c:897
#9 0x080dfcfb in rval_expr_eval_int (h=0xbfb38fe8, msg=0x82a74d0, res=0xbfb38954, rve=0x8289028) at rvalue.c:1837
#10 0x08056db7 in do_action (h=0xbfb38fe8, a=0x828bd60, msg=0x82a74d0) at action.c:834
#11 0x0805a8bd in run_actions (h=0xbfb38fe8, a=0x82889e0, msg=0x82a74d0) at action.c:1293
#12 0x08057340 in do_action (h=0xbfb38fe8, a=0x828ca88, msg=0x82a74d0) at action.c:1131
#13 0x0805a8bd in run_actions (h=0xbfb38fe8, a=0x8287868, msg=0x82a74d0) at action.c:1293
#14 0x08056e15 in do_action (h=0xbfb38fe8, a=0x828e960, msg=0x82a74d0) at action.c:849
#15 0x0805a8bd in run_actions (h=0xbfb38fe8, a=0x827e5e0, msg=0x82a74d0) at action.c:1293
#16 0x0805ac24 in run_top_route (a=0x827e5e0, msg=0x82a74d0, c=0x0) at action.c:1341
#17 0x080c4072 in receive_msg (
buf=0x825c4e0 "INVITE sip:123@192.168.2.108 SIP/2.0\r\nVia: SIP/2.0/UDP 192.168.2.105:62392;branch=z9hG4bK-d8754z-a372283e165cdf75-1---d8754z-;rport\r\nMax-Forwards: 69\r\nContact: <sip:282@192.168.2.105:62392>\r\nTo: \"123\""..., len=751, rcv_info=0xbfb391f8) at receive.c:196
#18 0x0814e031 in udp_rcv_loop () at udp_server.c:520
#19 0x0809a9a1 in main_loop () at main.c:1447
#20 0x0809bc02 in main (argc=1, argv=0xbfb39484) at main.c:2251
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=60
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
If I define an infinite loop like this:
while( true ) {
...
}
the following warning is reported:
WARNING: <core> [cfg.y:3307]: warning in config file
/etc/kamailio/kamailio.cfg, line 4, column 9-12: constant value in
while(...)
The config file used for testing:
#!KAMAILIO
route{
while( true ) {
exit;
}
exit;
}
How can I define a simple infinite loop without getting a warning in the logs.
I don't want to define a variable just for the while loop and test it.
$var(true) = 1;
while ($var(true)) {
...
}
Is there a specific PV like '$null' or a specific keyword?
Thanks,
Ovidiu Sas
Module: sip-router
Branch: master
Commit: 5ab5c7ff6954661de9efe84136f5fa42784ef2b9
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=5ab5c7f…
Author: Juha Heinanen <jh(a)tutpro.com>
Committer: Juha Heinanen <jh(a)tutpro.com>
Date: Wed Apr 7 09:24:44 2010 +0300
modules/enum: enum_pv_query() modification
- enum_pv_query() now applies NAPTR regex to E.164 number given in its
pv argument. Earlier NAPTR was applied to E.164 number in Request URI
user part.
---
modules/enum/README | 3 +--
modules/enum/doc/enum_admin.xml | 3 +--
modules/enum/enum.c | 24 ++----------------------
3 files changed, 4 insertions(+), 26 deletions(-)
diff --git a/modules/enum/README b/modules/enum/README
index 24f727c..1585dbe 100644
--- a/modules/enum/README
+++ b/modules/enum/README
@@ -116,8 +116,7 @@ Chapter 1. Admin Guide
you may wish to route based on something else. The function
enum_pv_query mimics the behavior of the enum_query function except the
E.164 number in its pseudo variable argument is used for the enum
- lookup instead of the user part of the RURI. Obviously the user part of
- the RURI is still used in the NAPTR regexp.
+ lookup instead of the user part of the RURI.
Enum query returns 1 if the current Request URI was replaced and -1 if
not.
diff --git a/modules/enum/doc/enum_admin.xml b/modules/enum/doc/enum_admin.xml
index 8560049..0c031c6 100644
--- a/modules/enum/doc/enum_admin.xml
+++ b/modules/enum/doc/enum_admin.xml
@@ -77,8 +77,7 @@
<function moreinfo="none">enum_pv_query</function> mimics the behavior
of the <function moreinfo="none">enum_query</function> function except the
E.164 number in its pseudo variable argument is used for the enum lookup instead of the user
- part of the RURI. Obviously the user part of the RURI is still used in the
- NAPTR regexp.
+ part of the RURI.
</para>
<para>
Enum query returns 1 if the current Request URI was replaced
diff --git a/modules/enum/enum.c b/modules/enum/enum.c
index ba4fc48..695beaf 100644
--- a/modules/enum/enum.c
+++ b/modules/enum/enum.c
@@ -3,7 +3,7 @@
*
* Enum and E164 related functions
*
- * Copyright (C) 2002-2008 Juha Heinanen
+ * Copyright (C) 2002-2010 Juha Heinanen
*
* This file is part of Kamailio, a free SIP server.
*
@@ -999,7 +999,6 @@ int enum_pv_query_3(struct sip_msg* _msg, char* _sp, char* _suffix,
char new_uri[MAX_URI_SIZE];
unsigned int priority, curr_prio;
qvalue_t q;
- char tostring[17];
struct rdata* head;
struct rdata* l;
struct naptr_rdata* naptr;
@@ -1014,25 +1013,6 @@ int enum_pv_query_3(struct sip_msg* _msg, char* _sp, char* _suffix,
service = (str*)_service;
/*
- * Get R-URI user to tostring
- */
- if (parse_sip_msg_uri(_msg) < 0) {
- LM_ERR("R-URI parsing failed\n");
- return -1;
- }
-
- if (is_e164(&(_msg->parsed_uri.user)) == -1) {
- LM_ERR("R-URI user is not an E164 number\n");
- return -1;
- }
-
- user_s = _msg->parsed_uri.user.s;
- user_len = _msg->parsed_uri.user.len;
-
- memcpy(&(tostring[0]), user_s, user_len);
- tostring[user_len] = (char)0;
-
- /*
* Get E.164 number from pseudo variable
*/
if (sp && (pv_get_spec_value(_msg, sp, &pv_val) == 0)) {
@@ -1112,7 +1092,7 @@ int enum_pv_query_3(struct sip_msg* _msg, char* _sp, char* _suffix,
/* Avoid making copies of pattern and replacement */
pattern.s[pattern.len] = (char)0;
replacement.s[replacement.len] = (char)0;
- if (reg_replace(pattern.s, replacement.s, &(tostring[0]),
+ if (reg_replace(pattern.s, replacement.s, &(string[0]),
&result) < 0) {
pattern.s[pattern.len] = '!';
replacement.s[replacement.len] = '!';
Hello list,
while using from/p-preferred-identity display names in kamailio.cfg I
noticed, that $pn and $fn contain the beginning and ending double quotes
("<display name>") supplied by the UAC.
As those quotes not part of the display name (at least I think so - e.g.
they are also not shown by end user devices) I suggest to remove them
from $pn and $fn, because otherwise you have to remove them manually
with pv transformations/substr, which may takes much more performance...
Best Regards
Jasmin
Hello list,
currently I am trying to use the enum_pv_query function of the enum
module but I always get an error: the R-Uri-User is not an e164-Number.
That's true, but not important (and must not result in a failed lookup),
because the function should use a pv for the lookup, not the R-Uri-User.
In enum.c I discovered in function enum_pv_query_3 :
/*
* Get R-URI user to tostring
*/
if (parse_sip_msg_uri(_msg) < 0) {
LM_ERR("R-URI parsing failed\n");
return -1;
}
if (is_e164(&(_msg->parsed_uri.user)) == -1) {
LM_ERR("R-URI user is not an E164 number\n");
return -1;
}
user_s = _msg->parsed_uri.user.s;
user_len = _msg->parsed_uri.user.len;
memcpy(&(tostring[0]), user_s, user_len);
tostring[user_len] = (char)0;
/*
* Get E.164 number from pseudo variable
*/
if (sp && (pv_get_spec_value(_msg, sp, &pv_val) == 0)) {
if (pv_val.flags & PV_VAL_STR) {
if (pv_val.rs.len == 0 || pv_val.rs.s == NULL) {
LM_DBG("Missing E.164 number\n");
return -1;
}
} else {
LM_DBG("Pseudo variable value is not string\n");
return -1;
}
} else {
LM_DBG("Cannot get pseudo variable value\n");
return -1;
}
if (is_e164(&(pv_val.rs)) == -1) {
LM_ERR("pseudo variable does not contain an E164 number\n");
return -1;
}
user_s = pv_val.rs.s;
user_len = pv_val.rs.len;
memcpy(&(string[0]), user_s, user_len);
string[user_len] = (char)0;
As you can see, the function always tries to read the uri for lookup
from the R-Uri, whether "sp" (which is needed to be true for using pv)
is defined or not. Why do you need sp? I recognized, that enum_query()
(without pv) uses a separate function anyway...
I would suggest to remove the lines in this function, which try to use
the R-URI for enum lookup...
Thanks
Jasmin
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has been changed. The changes are listed below. For full information about what has changed, visit the URL and click the History tab.
FS#55 - Extending TM timeout/408 handling
User who did this: Iñaki Baz Castillo (ibc)
Task details edited:
-------
Hi, let's suppose the following case:
SR receives an INVITE and performs serial or parallel forking to gw1 and gw2.
Three cases:
case a)
- gw1 replies 480.
- gw2 replies 408.
case b)
- gw1 replies 480.
- gw2 replies 180 and fr_inv_timer expires so a local 408 is generated.
case c)
- gw1 replies 480.
- gw2 replies nothing and fr_timer expires so a local 408 is generated.
In any case, after the transaction fails I handle the winning response in failure_route in which I get a 408. But there is no way to determine which of the above 3 cases took place.
For cases "a" and "b" the 408 could be a good choice (also the 480) but in case "c" I'd strongly prefer using the 480. But there is no way, in failure_route, to determine if our case is "a", "b" or "c".
A non reliable pseudo-workaround is setting a transaction flag(RINGIN_RECEIVED) so when inspecting the 408 in failure_route we can "determine" if fr_timer expired (case "c") or not (cases "a" or "b"). This is not reliable as the flag could be set by other branch in which 1XX was received.
Possible solutions:
SOLUTION 1)
When fr_timer expires a new status code is locally generated, i.e. 478 "No response received at all". Such code would have lowest priority. The admin could choose to send a 500 error upstream if the final chosen response is a 478 (which just makes sense for the server), or perhaps the server itself could automatically map a final 487 response to a 500 (as it does with 503).
Using this approach the above cases would choose the following final response:
a) 408
b) 408
c) 480
SOLUTION 2)
Generate local 503 if fr_timer expires. According to RFC 3261 there are two posibilities if the transport layer fails:
- Timeout, no response, so 408 is locally generated.
- Transport error so 503 is locally generated. Transport error can occur in both TCP and UDP:
In TCP a transport error means that the TCP connection failed.
In UDP a transport error means that the UAC received a ICMP indicating "UDP port 5060 unreachable".
The transport error for UDP is not handled by TM as it doesn't rely on the received ICMP. Also it seems that such ICMP mechanism is not interoperable between different TCP/IP stacks.
Anyhow, I would suggest that when fr_timer expires (in UDP) a locally generated 503 could make sense. Why not? If there is no response at all for a transaction then there is some kind of network issue or perhaps the remote server is down/congested. 503 seems suitable for me, even if RFC 3261 doesn't state it.
PS: As far as I know, other SIP stacks uses internal codes (like 7XX) to indicate such kind of errors (transport error, transport timeout...). I think something like that is a real need even if RFC 3261 didn't consider it (as they didn't consider NAT).
Using this approach the above cases would choose the following final response:
a) 408
b) 408
c) 480
Opinions?
-------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=55
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
