sr-dev June 2015

sr-dev@lists.kamailio.org

34 participants
273 discussions

Start a nNew thread

[kamailio] sipcapture README does not document sip_capture script function (#63)
by juha-h 24 Jan '16

24 Jan '16

--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/63

3 5

[kamailio] debugger: config test report (#8)
by Victor Seva 24 Jan '16

24 Jan '16

In testing environment It would be nice to be able to append sip headers `X-Kamailio-test` and `X-Kamailio-test-ID` as a way to identify a collection of request/responses related to a a single test. Be able to generate tests reports via debugger RPC command using the value of `X-Kamailio-test` as key. The content of report could be: * SIP message received * SIP messages sended * flow of config execution routes ( `start`, `end`, `exit` ) * list of the variable and its value --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/8

5 8

[kamailio] event on table location Duplicate entry for key 'ruid_idx' (#30)
by ovoshlook 24 Jan '16

24 Jan '16

Hello. We use 2 kamailio servers cluster and we have porblems with db. Database failed pecause of error: Could not execute Write_rows_v1 event on table production.location; Duplicate entry 'uloc-54aae947-86d-a67' for key 'ruid_idx', Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the event's master log FIRST, end_log_pos 380, Internal MariaDB error code: 1062 But a location table no row 'ruid_idx' and no entry uloc-54aae947-86d-a67. --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/30

5 13

[kamailio] Added modparam id_in_avp for carrierroute (#221)
by Thomas Boros 19 Jan '16

19 Jan '16

We have 2M lines in carrierroute, so we often need to get back the ID of the line from the DB from carrierroute. This commit creates a new modparam "id_in_avp" for the module carrierroute which may be 0 - 2 0 - no ID, only the description is saved in the avp 1 - ID and descrptiotion is saved in the AVP 2 - Only ID is saved in the AVP. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/221 -- Commit Summary -- * Added modparam id_in_avp for carrierroute so the ID may be returned to the AVP variable for easier debugging -- File Changes -- M modules/carrierroute/carrierroute.c (7) M modules/carrierroute/cr_db.c (61) -- Patch Links -- https://github.com/kamailio/kamailio/pull/221.patch https://github.com/kamailio/kamailio/pull/221.diff --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/221

2 10

[kamailio] Adding publish in registration functionality, sending "closed" NOTIFY when presense has expired (#177)
by barabasp 20 Nov '15

20 Nov '15

The commit contains pua_usrloc modifications, which simplifies the publish and regisration processes: in every REGISTER an implicit publish is built in. In this way, a device e.g. do not need to send two individual request towards kamailio (REGISTER, PUBLISH), it can be achieved in a single but extended REGISTER request. Another small fix is that if the publication is expired (due to broken TCP e.g.), a "closed" NOTIFY should be sent to the contacts. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/177 -- Commit Summary -- * Adding publish in registration functionality -- File Changes -- M modules/pua_usrloc/pua_usrloc.c (4) M modules/pua_usrloc/ul_publish.c (152) -- Patch Links -- https://github.com/kamailio/kamailio/pull/177.patch https://github.com/kamailio/kamailio/pull/177.diff --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/177

2 7

[kamailio] kex: per module memory debugging (#225)
by Stefan Mititelu 02 Nov '15

02 Nov '15

Kex module updated to also give some details about memory used by each module. Changed f_*, q_* and tlsf_* memory stubs to also include the module name. Added 2 new memory API functions(for each of the memory algos) which will iterate throughout the memory fragments and agregate the memory size used by each function in order to print it. Tested with MEMMNG=0,1,2 and MEMDBG=0,1. Use "kamcmd mem.stat mod_name pkg/shm/all" to test Updated doku. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/225 -- Commit Summary -- * kex: per module memory debugging -- File Changes -- M events.c (25) M events.h (4) M mem/f_malloc.c (135) M mem/f_malloc.h (47) M mem/mem.h (32) M mem/q_malloc.c (113) M mem/q_malloc.h (40) M mem/shm_mem.c (4) M mem/shm_mem.h (32) M mem/src_loc.h (2) M mem/tlsf.c (105) M mem/tlsf.h (32) M modules/ctl/binrpc_run.c (12) M modules/kex/doc/kex_admin.xml (76) M modules/kex/kex_mod.c (7) A modules/kex/mod_stats.c (288) A modules/kex/mod_stats.h (37) -- Patch Links -- https://github.com/kamailio/kamailio/pull/225.patch https://github.com/kamailio/kamailio/pull/225.diff --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/225

2 11

[kamailio] Proposed: Consolidate example kamailio.cfg files (#209)
by tuxd00d 20 Oct '15

20 Oct '15

- There are relatively few differences between the example configuration files. - The time needed to maintain three separate files doesn't match the benefit. - The power of the #!define and #!ifdef system negates the need for separate examples. - It is simple enough to remove #!ifdef sections if one wishes to slim down the file size. - I'll do a consolidation if no valid argument against it is raised. --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/209

3 6

Re: [sr-dev] Is there a sense in calling run_onsend() after the msg_send() function?
by Lucian Balaceanu 08 Sep '15

08 Sep '15

Hi Daniel, I must admit this run_onsend() patch for stateful replies creation was not quite a success story. However, I think it serves a practical purpose, for example in Homer tracing and could be useful for the community. Again, I propose my past solution, with some questions: 1. I am unsure if the place I introduced the run_onsend call is appropriate since the buf used for msg_send is constructed build_res_buf_from_sip_req and build_res_buf_from_sip_res calls. 2. Also, we can maybe unite these if call branches I created: send_res = msg_send(&uas_rb->dst, buf, res_len); send_res = SEND_PR_BUFFER( uas_rb, buf, res_len ); 3. Do you think a get_send_socket snippet as follows should be inserted before the /*if (onsend_route_enabled(SIP_REPLY)){*/ : if(dst.send_sock == NULL) { dst.send_sock=get_send_socket(msg, &dst.to, dst.proto); if (dst.send_sock==0){ LM_ERR("cannot forward reply\n"); } } Thank you, Lucian On 10/29/2014 02:15 PM, Daniel-Constantin Mierla wrote: > Hello Lucian, > > I applied your patch with some fixes. > > I haven't checked with stateful replies, at some point a function from > core should be used. You can go ahead and see if it works, if not, let > me know and I can look into it as well. You can follow the callbacks > for TMCB_RESPONSE_OUT or TMCB_RESPONSE_FWDED inside tm code, they > should lead to the place where a sip response is going to be sent out. > > Cheers, > Daniel > > On 27/10/14 12:51, Lucian Balaceanu wrote: >> Hello Daniel, >> >> I must admit I only saw your mail last Friday. Until the 10th of >> October I was also on vacation. I know that you actually committed >> some of the changes together with your comments on the 12th this month. >> >> I don't know if we can consider the topic of the patch closed. As far >> as I understand, the state-full replies have not been addressed, >> right? (There should be a change in the t_reply.c) I followed the >> code to the relay_reply but I did not yet come to find the send >> function. Should I pursue further? >> >> Thank you, >> Lucian Balaceanu >> >>> Hi Lucian, >>> >>> somehow I forgot to follow up on this. But we need to get sorted out >>> soon, before we release, so it works as expected with the new >>> version. See more comments inline. >>> >>> >>> On 17/09/14 18:09, Lucian Balaceanu wrote: >>>> Hi Daniel, >>>> >>>> Please forgive me for my delay in responding to your mail. >>>> Please find attached a second version of the onsend_route_reply >>>> patch (which again has some problems). As per your previous >>>> indications I did the following: >>>> >>>> *Issue1* >>>>> From performances point of view, there can be added a config >>>>> parameter to enable running of onsend_route for replies: >>>>> >>>>> onsend_route_reply = 0|1 >>>> >>>> Following >>>> http://www.asipto.com/pub/kamailio-devel-guide/#c08add_parameters I >>>> have tried to add onsend_route_reply parameter. The code compiles, >>>> but when trying to start kamailio with this parameter inside, the >>>> parsing fails with syntax errors signaling: >>>> >>>> / 0(1321) :<core> [cfg.y:3423]: yyerror_at(): parse error in config >>>> file kamailio-basic.cfg.4.1, from line 107, column 1 to line 108, >>>> column 0: syntax error >>>> 0(1321) : <core> [cfg.y:3423]: yyerror_at(): parse error in config >>>> file kamailio-basic.cfg.4.1, from line 107, column 1 to line 108, >>>> column 0: >>>> ERROR: bad config file (2 errors)/ >>> >>> The issue is: >>> >>> +<INITIAL>{ONSEND_RT_REPLY} { yylval.intval=atoi(yytext); >>> + yy_number_str=yytext; return NUMBER; } >>> >>> It should be: >>> >>> +<INITIAL>{ONSEND_RT_REPLY} { yylval.intval=atoi(yytext); >>> + yy_number_str=yytext; return ONSEND_RT_REPLY; } >>> >>>> >>>> *Issue2* >>>>> #define onsend_enabled(rtype) >>>>> (onsend_rt.rlist[DEFAULT_RT]?((rtype==SIP_REPLY)?onsend_route_reply:1):0) >>>> That is to say you see it best to take the chek for >>>> onsend_rt.list[DEFAULT_RT] from inside run_onsend() function and >>>> call this onsend_enabled(...) before the run_onsend()? >>> >>> This is to detect whether the onsend_route should be executed for >>> SIP replies. The condition being: >>> >>> - if is a sip reply and onsend_route is set and the >>> onsend_route_reply parameter is 1 >>>> >>>> *Issue3* >>>>> On the other hand, is onsend_route also executed for local >>>>> requests? I had in mind it is only for received requests that are >>>>> forwarded ... Iirc, on onsend_route, the sip message is the one >>>>> received, the outgoing content being accessible via $snd(buf). >>>>> >>>> I agree with you with taking out the locally generated requests and >>>> only left the run_onsend call in do_forward_reply function (inside >>>> forward.c). >>>> Could you point me to the reply relaying function that is called >>>> for state-full processing? >>> Stateful processing for replies is mainly done in t_reply.c from tm >>> module. At some point there should be a send buffer function call. >>> >>> Cheers, >>> Daniel >>>> >>>> Thank you and sorry again for my late answer, >>>> Lucian >>> >>> -- >>> Daniel-Constantin Mierla >>> http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda >>> >>> >> > > -- > Daniel-Constantin Mierla > http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda

2 6

[kamailio] core parsing of SIP message failed errors (#107)
by jcohn25 26 Aug '15

26 Aug '15

I finally got everything working but see to consistently receive the following 3 errors (see below) over and over when a call is being collected? Versions: Homer 3.6 kamailio 4.3.0-dev4 Captagent 4.2.0 Any assistance would be appreciated. Errors: Mar 8 22:04:47 ce-homer2 /usr/local/kamailio/sbin/kamailio[9921]: ERROR: <core> [parser/parse_fline.c:257]: parse_first_line(): parse_first_line: bad message (offset: 0) Mar 8 22:04:47 ce-homer2 /usr/local/kamailio/sbin/kamailio[9921]: ERROR: <core> [parser/msg_parser.c:688]: parse_msg(): ERROR: parse_msg: message=<HEP3#004>> Mar 8 22:04:47 ce-homer2 /usr/local/kamailio/sbin/kamailio[9921]: ERROR: <core> [receive.c:129]: receive_msg(): core parsing of SIP message failed (127.0.0.1:33264/1) Mar 8 22:04:47 ce-homer2 /usr/local/kamailio/sbin/kamailio[9922]: ERROR: <core> [parser/parse_fline.c:257]: parse_first_line(): parse_first_line: bad message (offset: 0) Mar 8 22:04:47 ce-homer2 /usr/local/kamailio/sbin/kamailio[9922]: ERROR: <core> [parser/msg_parser.c:688]: parse_msg(): ERROR: parse_msg: message=<HEP3#002Ü> Mar 8 22:04:47 ce-homer2 /usr/local/kamailio/sbin/kamailio[9922]: ERROR: <core> [receive.c:129]: receive_msg(): core parsing of SIP message failed (127.0.0.1:33264/1) --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/107

3 3

RTPEngine - REDIS Plugin
by Carsten Bock 25 Aug '15

25 Aug '15

Hi everyone, several months ago, we've implemented a plugin for RTPEngine to synchronize it with a REDIS-Database. This allows RTPEngine to operate in a HA, as you can restart RTPEngine and/or make a failover to another machine with the same IP (e.g. using Heartbeat or similar), WITHOUT LOOSING ACTIVE SESSIONS. This enhancement was originally implemented by Carlos Ruiz Diaz. Due to lack of time, it still requires RTPEngine 3.3 and needs an update, to work with later versions. It can be found here: https://github.com/ngvoice/rtpengine-redis-plugin If anyone is interested in contributing to this extension, please ping me and i will happily add you as a contributor. Thanks, Carsten -- Carsten Bock CEO (Geschäftsführer) ng-voice GmbH Schomburgstr. 80 D-22767 Hamburg / Germany http://www.ng-voice.com mailto:carsten@ng-voice.com Office +49 40 5247593-0 Fax +49 40 5247593-99 Sitz der Gesellschaft: Hamburg Registergericht: Amtsgericht Hamburg, HRB 120189 Geschäftsführer: Carsten Bock Ust-ID: DE279344284 Hier finden Sie unsere handelsrechtlichen Pflichtangaben: http://www.ng-voice.com/imprint/

5 8

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev June 2015