sr-dev

sr-dev@lists.kamailio.org

44307 discussions

by jh＠tutpro.com

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

14 years, 10 months

[tracker] Task opened: kamailio 3.0.x: segfault in carrierroute

by sip-router

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.

14 years, 10 months

git:master: topoh: free nbuf

by Daniel-Constantin Mierla

Module: sip-router Branch: master Commit: 198e468b7d83bb62d0761dd45e5c6820bc75a61a URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=198e468… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Wed Apr 7 22:56:46 2010 +0200 topoh: free nbuf - fixed leak due to no free of new buffer - reported by Libor Chocholaty --- modules/topoh/topoh_mod.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/modules/topoh/topoh_mod.c b/modules/topoh/topoh_mod.c index 7dd3ec6..a1f3fd2 100644 --- a/modules/topoh/topoh_mod.c +++ b/modules/topoh/topoh_mod.c @@ -184,7 +184,7 @@ int th_msg_received(void *data) { sip_msg_t msg; str *obuf; - char *nbuf; + char *nbuf = NULL; int direction; int dialog; @@ -256,6 +256,8 @@ int th_msg_received(void *data) obuf->s[obuf->len] = '\0'; done: + if(nbuf!=NULL) + pkg_free(nbuf); free_sip_msg(&msg); return 0; }

14 years, 10 months

how to define an infinite while loop?

by Ovidiu Sas

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

14 years, 10 months

git:master: modules/enum: enum_pv_query() modification

by Juha Heinanen

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] = '!';

14 years, 10 months

Quotes in $pn and $fn

by Jasmin Schnatterbeck

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

14 years, 10 months

Enum PV lookup

by Jasmin Schnatterbeck

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

14 years, 10 months

[tracker] Task changed: Extending TM timeout/408 handling

by sip-router

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.

14 years, 10 months

git:kamailio_3.0: utils/kamctl/kamctl. base added documentation of ps command

by Marius Zbihlei

Module: sip-router Branch: kamailio_3.0 Commit: 5266c7f5ed1e2f6364f646ece3828e259491a6ae URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=5266c7f… Author: Marius Zbihlei <marius.zbihlei(a)1and1.ro> Committer: Marius Zbihlei <marius.zbihlei(a)1and1.ro> Date: Tue Apr 6 16:21:35 2010 +0300 utils/kamctl/kamctl.base added documentation of ps command --- utils/kamctl/kamctl.base | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/utils/kamctl/kamctl.base b/utils/kamctl/kamctl.base index 79025c2..d15e8eb 100644 --- a/utils/kamctl/kamctl.base +++ b/utils/kamctl/kamctl.base @@ -323,12 +323,13 @@ DIALPLAN_ATTRS_COLUMN=attrs usage_base() { echo - mecho " -- command 'start|stop|restart'" + mecho " -- command 'start|stop|restart|ps'" echo cat <<EOF restart ............................ restart Kamailio start .............................. start Kamailio stop ............................... stop Kamailio + ps ................................. print Kamailio processes EOF }

14 years, 10 months

Feature request: sql row number, route-specific avps

by Jasmin Schnatterbeck

Hi list, while thinking about the idea to build a recursive code block in kamailio.cfg I noticed, that there are no route-specific avps available. Of course you can convert a recursion to an iteration, but you need something like a stack to save variables on it, which is not available also. Do you think it's reasonable to make route specific avps available in future releases? I also noticed, that it does not seem to be possible to get the number of result rows of avp_db_query - may (in the case of an successful query) can the function return the number of results for example? Thank you very much... Jasmin

14 years, 10 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev