sr-dev

sr-dev@lists.kamailio.org

13 participants
44202 discussions

by Daniel-Constantin Mierla

Hello, anyone that still has to commit something on SVN branch 1.5 @sourceforge.net, please do it before 14:00GMT, afterwards will start releasing 1.5.2. Thanks, Daniel

15 years, 6 months

replacing k pvars with s selects

by jh＠tutpro.com

in order to clear lots of confusion and in order to simplify things, i'm suggesting that we replace k pvars with s selects. for example, $fd would become @from.uri.host. also, $avp(name) would simply become $name. -- juha

15 years, 6 months

SF.net SVN: openser:[5900] branches/1.5/ChangeLog

by Henning Westerholt

Revision: 5900 http://openser.svn.sourceforge.net/openser/?rev=5900&view=rev Author: henningw Date: 2009-07-14 13:30:28 +0000 (Tue, 14 Jul 2009) Log Message: ----------- - update changelog Modified Paths: -------------- branches/1.5/ChangeLog This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

15 years, 6 months

Re: [sr-dev] [Kamailio-Users] new module: mi_rpc

by Daniel-Constantin Mierla

On 13.07.2009 19:51 Uhr, Juha Heinanen wrote: > Daniel-Constantin Mierla writes: > > > here is what mi_rpc modules does: > > - it receives a rpc handler form the rpc interface in core > > - reads first parameter and then lookups MI command, if not found then > > returns error, if found: > > - reads all parameters as string and build internal MI tree > > ok, after andrei fixed some bug, i got stats working via mi_rpc and > xmlrpc module interface. > > all stats except "tm:", which is now implemented using tm.stats command. > > res = c.tm.stats() > > provides this kind of result: > > {'2xx': 0, 'created': 0, '5xx': 0, 'delayed_free': 0, 'current': 0, 'total_local': 0, 'waiting': 0, '6xx': 0, '4xx': 0, '3xx': 0, 'total': 0, 'replied_locally': 0, 'freed': 0} > > whereas mi based stat results look like this: > > ['200 OK\n', '+ :: core:rcv_requests = 3', '+ :: core:rcv_replies = 0', '+ :: core:fwd_requests = 0', '+ :: core:fwd_replies = 0', '+ :: core:drop_requests = 0', '+ :: core:drop_replies = 0', '+ :: core:err_requests = 0', '+ :: core:err_replies = 0', '+ :: core:bad_URIs_rcvd = 0', '+ :: core:unsupported_methods = 3', '+ :: core:bad_msg_hdr = 0'] > > would it be possible to get the result in same (preferable the former) > format in both cases? > you can try implementing a new command in the mi_rpc modulem say 'mix' (mi for xmlrpc) that will format the output as you want. However would be good to get a single command, but I do not know if is possible considering that MI reply trees have: - name for nodes - values for nodes - string or other nodes - attributes for nodes - string IIRC, Andrei proposed to put the value of the attributes in the value of the node. Now, the formating looks a bit strange, as I did it to regocnize the above elements, so: + means that the printed line corresponds to a node - means that the printed line corresponds to an attribute of the last printed node Within a node line: - what is before '::' is the name of node - what is after '::' is the value of node - tab indentation is used to show the depth of nodes and attributes All these are taken from mi_fifo. So, in case of statistics, the nodes have no name and the value has the format "stat = value". I can say it is pretty weird, but it is the current style with mi_fifo. As I am not a xmlrpc user, with mi_datagram I did text parsing. Cheers, Daniel

15 years, 6 months

git:master: tm: which_cancel renamed and takes more parameters

by Andrei Pelinescu-Onciul

Module: sip-router Branch: master Commit: 79edcdf278ff95b17b08f44affa636ec7a40aa40 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=79edcdf… Author: Andrei Pelinescu-Onciul <andrei(a)iptel.org> Committer: Andrei Pelinescu-Onciul <andrei(a)iptel.org> Date: Tue Jul 14 14:44:21 2009 +0200 tm: which_cancel renamed and takes more parameters - which_cancel() renamed to prepare_to_cancel() to better reflect its real purpose. - which_cancel_f renamed to prepare_to_cancel_f - tm_binds which_cancel member renamed to prepare_to_cancel - should_cancel_branch() renamed to prepare_cancel_branch(). - prepare_to_cancel() takes now an extra parameter (skip_branches) which contains a bitmap of the branches that should be skipped (not canceled). --- modules/tm/t_cancel.c | 38 ++++++++++++++++++++++++++------------ modules/tm/t_cancel.h | 24 +++++++++++++++++++----- modules/tm/t_fwd.c | 8 ++++---- modules/tm/t_reply.c | 14 +++++++------- modules/tm/timer.c | 2 +- modules/tm/tm_load.c | 2 +- modules/tm/tm_load.h | 3 ++- 7 files changed, 60 insertions(+), 31 deletions(-) Diff: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commitdiff;h=79e…

15 years, 6 months

git:master: tmx(k): updated to the which_cancel change

by Andrei Pelinescu-Onciul

Module: sip-router Branch: master Commit: 1a43484b132393a10f1530f7e71cc190eacaf56a URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=1a43484… Author: Andrei Pelinescu-Onciul <andrei(a)iptel.org> Committer: Andrei Pelinescu-Onciul <andrei(a)iptel.org> Date: Tue Jul 14 14:49:05 2009 +0200 tmx(k): updated to the which_cancel change - updated to the which_cancel name change - use the new prepare_to_cancel skip_branches parameter to skip the current branch when generating the CANCEL, instead of the previous unsafe way (in sr which_cancel/prepare_to_cancel is lockless and so it's not safe to directly manipulate the cancel buffers even if the reply lock is held). --- modules_k/tmx/tmx_mod.c | 14 +++++++------- 1 files changed, 7 insertions(+), 7 deletions(-) diff --git a/modules_k/tmx/tmx_mod.c b/modules_k/tmx/tmx_mod.c index c84cff7..5b8cd9c 100644 --- a/modules_k/tmx/tmx_mod.c +++ b/modules_k/tmx/tmx_mod.c @@ -232,11 +232,9 @@ static int t_cancel_branches(struct sip_msg* msg, char *k, char *s2) switch(n) { case 1: LOCK_REPLIES(t); - _tmx_tmb.which_cancel(t, &cb); - if(t->uac[idx].local_cancel.buffer==BUSY_BUFFER) - t->uac[idx].local_cancel.buffer=NULL; + /* prepare cancel for every branch except idx */ + _tmx_tmb.prepare_to_cancel(t, &cb, 1<<idx); UNLOCK_REPLIES(t); - cb &= ~(1<<idx); case 2: if(msg->first_line.u.reply.statuscode>=200) break; @@ -244,10 +242,12 @@ static int t_cancel_branches(struct sip_msg* msg, char *k, char *s2) break; default: LOCK_REPLIES(t); - _tmx_tmb.which_cancel(t, &cb); - UNLOCK_REPLIES(t); if (msg->first_line.u.reply.statuscode>=200) - cb &= ~(1<<idx); + /* prepare cancel for every branch except idx */ + _tmx_tmb.prepare_to_cancel(t, &cb, 1<<idx); + else + _tmx_tmb.prepare_to_cancel(t, &cb, 0); + UNLOCK_REPLIES(t); } LM_DBG("canceling %d/%d\n", n, (int)cb); if(cb==0)

15 years, 6 months

TLS core parameters

by Klaus Darilion

Hi! there are various TLS parameters in core: tls_ca_list tls_certificate tls_handshake_timeout tlslog tls_method tls_port_no tls_private_key tls_require_certificate tls_send_timeout tls_verify Are they still needed? IIRC TLS is now configured by a separate config file, thus it would make sense to remove them. regards klaus

15 years, 6 months

xmlrcp request takes very long time

by jh＠tutpro.com

i wrote in python a simple text that sends domain_reload command over s xmlrpc interface to sr: --------------------------------------------------------------- import xmlrpclib XMLRPC_PROTOCOL = 'http' XMLRPC_SERVER = '127.0.0.1' XMLRPC_PORT = 6060 server_path = XMLRPC_PROTOCOL + '://' + XMLRPC_SERVER + \ ':' + str(XMLRPC_PORT) c = xmlrpclib.ServerProxy(server_path) erg = c.domain_reload() ---------------------------------------------------------------- when i execute the program, ngrep immediately prints what one would expect: T 2009/07/04 17:20:02.455028 127.0.0.1:33418 -> 127.0.0.1:6060 [AP] POST /RPC2 HTTP/1.0..Host: 127.0.0.1:6060..User-Agent: xmlrpclib.py/1.0.1 ( by www.pythonware.com)..Content-Type: text/xml..Content-Length: 107.... ## T 2009/07/04 17:20:02.455358 127.0.0.1:33418 -> 127.0.0.1:6060 [AP] <?xml version='1.0'?>.<methodCall>.<methodName>domain_reload</methodName>.< params>.</params>.</methodCall>. ## T 2009/07/04 17:20:02.455718 127.0.0.1:6060 -> 127.0.0.1:33418 [AP] HTTP/1.0 200 OK..Via: SIP/2.0/TCP 127.0.0.1:33418..Server: SIP Route r (2.99.0-dev01-serk (i386/linux))..Content-Length: 274....<?xml version="1 .0"?>.<methodResponse>.<fault>.<value>.<struct>.<member>.<name>faultCode</n ame>.<value><int>500</int></value>.</member>.<member>.<name>faultString</na me>.<value><string>Method Not Found</string></value>.</member>.</struct>.</ value>.</fault>.</methodResponse> however, python client program does not terminate until after more than 2 minutes. then it finally prints: Traceback (most recent call last): File "sr-xmlrpc.py", line 15, in <module> erg = c.domain_reload() File "/usr/lib/python2.5/xmlrpclib.py", line 1147, in __call__ return self.__send(self.__name, args) File "/usr/lib/python2.5/xmlrpclib.py", line 1437, in __request verbose=self.__verbose File "/usr/lib/python2.5/xmlrpclib.py", line 1201, in request return self._parse_response(h.getfile(), sock) File "/usr/lib/python2.5/xmlrpclib.py", line 1340, in _parse_response return u.close() File "/usr/lib/python2.5/xmlrpclib.py", line 787, in close raise Fault(**self._stack[0]) xmlrpclib.Fault: <Fault 500: 'Method Not Found'> i also tested with a php xmlrcp client with same result. any idea why it takes so long and why parsing of response fails? is something missing from the response? -- juha

15 years, 6 months

trusted_reload fails

by jh＠tutpro.com

mi trusted_reload fails like this: srctl> mi trusted_reload error: 400 - Trusted table reload failed and syslog shows these error messages: Jul 14 11:21:56 localhost /usr/sbin/sip-router[11658]: ERROR: <core> [db.c:422]: invalid parameter value Jul 14 11:21:56 localhost /usr/sbin/sip-router[11658]: ERROR: permissions [trusted.c:76]: failed to use trusted table -- juha

15 years, 6 months

CVS:commitlog: sip_router/parser msg_parser.c

by Andrei Pelinescu-Onciul

andrei 2009/07/14 09:40:17 CEST SER CVS Repository Modified files: parser msg_parser.c Log: core: parse_headers flags fix Restore original flags after parse_headers was called with "next" (without restoring them, if parse_headers doesn't find again all the requested headers it will leave their flags cleared although they might be present in the message). Revision Changes Path 1.62 +8 -3 sip_router/parser/msg_parser.c http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/parser/msg_parser.…

15 years, 6 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev