sr-dev September 2014

sr-dev@lists.kamailio.org

33 participants
376 discussions

patch - usrloc module insert contact
by Luis Azedo 08 Sep '14

08 Sep '14

Hi Daniel, the insert contact sets the columns for which there is not info to null. i propose not to include those columns in the insert. this way is compatible with dbtext module. Best diff --git a/modules/usrloc/ucontact.c b/modules/usrloc/ucontact.c index eeee451..3bfdb65 100644 --- a/modules/usrloc/ucontact.c +++ b/modules/usrloc/ucontact.c @@ -476,131 +476,125 @@ return -1; } - keys[0] = &user_col; - keys[1] = &contact_col; - keys[2] = &expires_col; - keys[3] = &q_col; - keys[4] = &callid_col; - keys[5] = &cseq_col; - keys[6] = &flags_col; - keys[7] = &cflags_col; - keys[8] = &user_agent_col; - keys[9] = &received_col; - keys[10] = &path_col; - keys[11] = &sock_col; - keys[12] = &methods_col; - keys[13] = &last_mod_col; - keys[14] = &ruid_col; - keys[15] = &instance_col; - keys[16] = &reg_id_col; - keys[17] = &domain_col; + keys[0] = &user_col; vals[0].type = DB1_STR; vals[0].nul = 0; vals[0].val.str_val.s = _c->aor->s; vals[0].val.str_val.len = _c->aor->len; + keys[1] = &contact_col; vals[1].type = DB1_STR; vals[1].nul = 0; vals[1].val.str_val.s = _c->c.s; vals[1].val.str_val.len = _c->c.len; + keys[2] = &expires_col; vals[2].type = DB1_DATETIME; vals[2].nul = 0; vals[2].val.time_val = _c->expires; + keys[3] = &q_col; vals[3].type = DB1_DOUBLE; vals[3].nul = 0; vals[3].val.double_val = q2double(_c->q); + keys[4] = &callid_col; vals[4].type = DB1_STR; vals[4].nul = 0; vals[4].val.str_val.s = _c->callid.s; vals[4].val.str_val.len = _c->callid.len; + keys[5] = &cseq_col; vals[5].type = DB1_INT; vals[5].nul = 0; vals[5].val.int_val = _c->cseq; + keys[6] = &flags_col; vals[6].type = DB1_INT; vals[6].nul = 0; vals[6].val.bitmap_val = _c->flags; + keys[7] = &cflags_col; vals[7].type = DB1_INT; vals[7].nul = 0; vals[7].val.bitmap_val = _c->cflags; + keys[8] = &user_agent_col; vals[8].type = DB1_STR; vals[8].nul = 0; vals[8].val.str_val.s = _c->user_agent.s; vals[8].val.str_val.len = _c->user_agent.len; - vals[9].type = DB1_STR; - if (_c->received.s == 0) { - vals[9].nul = 1; - } else { - vals[9].nul = 0; - vals[9].val.str_val.s = _c->received.s; - vals[9].val.str_val.len = _c->received.len; + nr_cols = 9; + + if (_c->received.s ) { + keys[nr_cols] = &received_col; + vals[nr_cols].type = DB1_STR; + vals[nr_cols].nul = 0; + vals[nr_cols].val.str_val.s = _c->received.s; + vals[nr_cols].val.str_val.len = _c->received.len; + nr_cols++; } - vals[10].type = DB1_STR; - if (_c->path.s == 0) { - vals[10].nul = 1; - } else { - vals[10].nul = 0; - vals[10].val.str_val.s = _c->path.s; - vals[10].val.str_val.len = _c->path.len; + if (_c->path.s) { + keys[nr_cols] = &path_col; + vals[nr_cols].type = DB1_STR; + vals[nr_cols].nul = 0; + vals[nr_cols].val.str_val.s = _c->path.s; + vals[nr_cols].val.str_val.len = _c->path.len; + nr_cols++; } - vals[11].type = DB1_STR; if (_c->sock) { - vals[11].val.str_val = _c->sock->sock_str; - vals[11].nul = 0; - } else { - vals[11].nul = 1; + keys[nr_cols] = &sock_col; + vals[nr_cols].type = DB1_STR; + vals[nr_cols].val.str_val = _c->sock->sock_str; + vals[nr_cols].nul = 0; + nr_cols++; } - vals[12].type = DB1_BITMAP; - if (_c->methods == 0xFFFFFFFF) { - vals[12].nul = 1; - } else { - vals[12].val.bitmap_val = _c->methods; - vals[12].nul = 0; + if (_c->methods != 0xFFFFFFFF) { + keys[nr_cols] = &methods_col; + vals[nr_cols].type = DB1_BITMAP; + vals[nr_cols].val.bitmap_val = _c->methods; + vals[nr_cols].nul = 0; + nr_cols++; } - vals[13].type = DB1_DATETIME; - vals[13].nul = 0; - vals[13].val.time_val = _c->last_modified; + keys[nr_cols] = &last_mod_col; + vals[nr_cols].type = DB1_DATETIME; + vals[nr_cols].nul = 0; + vals[nr_cols].val.time_val = _c->last_modified; + nr_cols++; - nr_cols = 14; if(_c->ruid.len>0) { + keys[nr_cols] = &ruid_col; vals[nr_cols].type = DB1_STR; vals[nr_cols].nul = 0; vals[nr_cols].val.str_val = _c->ruid; - } else { - vals[nr_cols].nul = 1; + nr_cols++; } - nr_cols++; if(_c->instance.len>0) { + keys[nr_cols] = &instance_col; vals[nr_cols].type = DB1_STR; vals[nr_cols].nul = 0; vals[nr_cols].val.str_val = _c->instance; - } else { - vals[nr_cols].nul = 1; + nr_cols++; } - nr_cols++; + keys[nr_cols] = &reg_id_col; vals[nr_cols].type = DB1_INT; vals[nr_cols].nul = 0; vals[nr_cols].val.int_val = (int)_c->reg_id; nr_cols++; if (use_domain) { + keys[nr_cols] = &domain_col; vals[nr_cols].type = DB1_STR; vals[nr_cols].nul = 0;

2 5

git:master: usrloc: don't add columns without values in the sql query
by Daniel-Constantin Mierla 08 Sep '14

08 Sep '14

Module: sip-router Branch: master Commit: 1e84aeb91cf8e7a79a9ac9091ed993be944a667b URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=1e84aeb… Author: Luis Azedo <luis.azedo(a)factorlusitano.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Mon Sep 8 17:07:11 2014 +0200 usrloc: don't add columns without values in the sql query - works better with db_text as well as the resulted query is smaller --- modules/usrloc/ucontact.c | 100 +++++++++++++++++++++------------------------ 1 files changed, 47 insertions(+), 53 deletions(-) diff --git a/modules/usrloc/ucontact.c b/modules/usrloc/ucontact.c index ead8e40..f426c27 100644 --- a/modules/usrloc/ucontact.c +++ b/modules/usrloc/ucontact.c @@ -480,131 +480,125 @@ int db_insert_ucontact(ucontact_t* _c) return -1; } - keys[0] = &user_col; - keys[1] = &contact_col; - keys[2] = &expires_col; - keys[3] = &q_col; - keys[4] = &callid_col; - keys[5] = &cseq_col; - keys[6] = &flags_col; - keys[7] = &cflags_col; - keys[8] = &user_agent_col; - keys[9] = &received_col; - keys[10] = &path_col; - keys[11] = &sock_col; - keys[12] = &methods_col; - keys[13] = &last_mod_col; - keys[14] = &ruid_col; - keys[15] = &instance_col; - keys[16] = &reg_id_col; - keys[17] = &domain_col; + keys[0] = &user_col; vals[0].type = DB1_STR; vals[0].nul = 0; vals[0].val.str_val.s = _c->aor->s; vals[0].val.str_val.len = _c->aor->len; + keys[1] = &contact_col; vals[1].type = DB1_STR; vals[1].nul = 0; vals[1].val.str_val.s = _c->c.s; vals[1].val.str_val.len = _c->c.len; + keys[2] = &expires_col; vals[2].type = DB1_DATETIME; vals[2].nul = 0; vals[2].val.time_val = _c->expires; + keys[3] = &q_col; vals[3].type = DB1_DOUBLE; vals[3].nul = 0; vals[3].val.double_val = q2double(_c->q); + keys[4] = &callid_col; vals[4].type = DB1_STR; vals[4].nul = 0; vals[4].val.str_val.s = _c->callid.s; vals[4].val.str_val.len = _c->callid.len; + keys[5] = &cseq_col; vals[5].type = DB1_INT; vals[5].nul = 0; vals[5].val.int_val = _c->cseq; + keys[6] = &flags_col; vals[6].type = DB1_INT; vals[6].nul = 0; vals[6].val.bitmap_val = _c->flags; + keys[7] = &cflags_col; vals[7].type = DB1_INT; vals[7].nul = 0; vals[7].val.bitmap_val = _c->cflags; + keys[8] = &user_agent_col; vals[8].type = DB1_STR; vals[8].nul = 0; vals[8].val.str_val.s = _c->user_agent.s; vals[8].val.str_val.len = _c->user_agent.len; - vals[9].type = DB1_STR; - if (_c->received.s == 0) { - vals[9].nul = 1; - } else { - vals[9].nul = 0; - vals[9].val.str_val.s = _c->received.s; - vals[9].val.str_val.len = _c->received.len; + nr_cols = 9; + + if (_c->received.s ) { + keys[nr_cols] = &received_col; + vals[nr_cols].type = DB1_STR; + vals[nr_cols].nul = 0; + vals[nr_cols].val.str_val.s = _c->received.s; + vals[nr_cols].val.str_val.len = _c->received.len; + nr_cols++; } - vals[10].type = DB1_STR; - if (_c->path.s == 0) { - vals[10].nul = 1; - } else { - vals[10].nul = 0; - vals[10].val.str_val.s = _c->path.s; - vals[10].val.str_val.len = _c->path.len; + if (_c->path.s) { + keys[nr_cols] = &path_col; + vals[nr_cols].type = DB1_STR; + vals[nr_cols].nul = 0; + vals[nr_cols].val.str_val.s = _c->path.s; + vals[nr_cols].val.str_val.len = _c->path.len; + nr_cols++; } - vals[11].type = DB1_STR; if (_c->sock) { - vals[11].val.str_val = _c->sock->sock_str; - vals[11].nul = 0; - } else { - vals[11].nul = 1; + keys[nr_cols] = &sock_col; + vals[nr_cols].type = DB1_STR; + vals[nr_cols].val.str_val = _c->sock->sock_str; + vals[nr_cols].nul = 0; + nr_cols++; } - vals[12].type = DB1_BITMAP; - if (_c->methods == 0xFFFFFFFF) { - vals[12].nul = 1; - } else { - vals[12].val.bitmap_val = _c->methods; - vals[12].nul = 0; + if (_c->methods != 0xFFFFFFFF) { + keys[nr_cols] = &methods_col; + vals[nr_cols].type = DB1_BITMAP; + vals[nr_cols].val.bitmap_val = _c->methods; + vals[nr_cols].nul = 0; + nr_cols++; } - vals[13].type = DB1_DATETIME; - vals[13].nul = 0; - vals[13].val.time_val = _c->last_modified; + keys[nr_cols] = &last_mod_col; + vals[nr_cols].type = DB1_DATETIME; + vals[nr_cols].nul = 0; + vals[nr_cols].val.time_val = _c->last_modified; + nr_cols++; - nr_cols = 14; if(_c->ruid.len>0) { + keys[nr_cols] = &ruid_col; vals[nr_cols].type = DB1_STR; vals[nr_cols].nul = 0; vals[nr_cols].val.str_val = _c->ruid; - } else { - vals[nr_cols].nul = 1; + nr_cols++; } - nr_cols++; if(_c->instance.len>0) { + keys[nr_cols] = &instance_col; vals[nr_cols].type = DB1_STR; vals[nr_cols].nul = 0; vals[nr_cols].val.str_val = _c->instance; - } else { - vals[nr_cols].nul = 1; + nr_cols++; } - nr_cols++; + keys[nr_cols] = &reg_id_col; vals[nr_cols].type = DB1_INT; vals[nr_cols].nul = 0; vals[nr_cols].val.int_val = (int)_c->reg_id; nr_cols++; if (use_domain) { + keys[nr_cols] = &domain_col; vals[nr_cols].type = DB1_STR; vals[nr_cols].nul = 0;

1 0

Re: [sr-dev] accessing database from a child forked proces
by Luis Azedo 08 Sep '14

08 Sep '14

Hi Daniel, well, i think its not needed but wouldn't we all benefit from it ? binding the internal structure to the result instead of connection? Thanks On Mon, Sep 8, 2014 at 3:37 PM, <sr-dev-request(a)lists.sip-router.org> wrote: > Send sr-dev mailing list submissions to > sr-dev(a)lists.sip-router.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev > or, via email, send a message with subject or body 'help' to > sr-dev-request(a)lists.sip-router.org > > You can reach the person managing the list at > sr-dev-owner(a)lists.sip-router.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of sr-dev digest..." > > > Today's Topics: > > 1. Re: accessing database from a child forked proces > (Daniel-Constantin Mierla) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 08 Sep 2014 16:37:21 +0200 > From: Daniel-Constantin Mierla <miconda(a)gmail.com> > To: Luis Azedo <luis.azedo(a)factorlusitano.com> > Cc: "Kamailio $SER$ - Development Mailing List" > <sr-dev(a)lists.sip-router.org> > Subject: Re: [sr-dev] accessing database from a child forked proces > Message-ID: <540DBF21.8070802(a)gmail.com> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > Hello, > > On 08/09/14 15:29, Luis Azedo wrote: > > Hi Daniel, > > > > all problems solved with presence! i was not running child_init and > > now there is no need for the proposed patch to presence. > ok. Given this, would the db_text patch still be required, as there > should be no database connection sharing? > > Cheers, > Daniel > > > > Thank you > > > > > > > > On Mon, Sep 8, 2014 at 2:13 PM, Luis Azedo > > <luis.azedo(a)factorlusitano.com <mailto:luis.azedo@factorlusitano.com>> > > wrote: > > > > Hi Daniel, > > > > this is the way we are creating the child processes (1 manager and > > n workers) > > the problem is with the workers. > > the worker will call a event-route and in the script config we try > > to call pres_refresh_watchers and that's where we get the pa_db = > > NULL. > > > > as i understand from your email, if we change PROC_NOCHLDINIT and > > let the child_init execute for the forked process then it will > > also execute child_init in other modules ? it makes sense. > > > > going to try this. > > > > > > static int mod_child_init(int rank) > > { > > int pid; > > int i; > > > > fire_init_event(rank); > > > > if (rank==PROC_MAIN) { > > pid=fork_process(PROC_NOCHLDINIT, "AMQP Manager", 1); > > if (pid<0) > > return -1; /* error */ > > if(pid==0){ > > kz_amqp_manager_loop(0); > > } > > else { > > for(i=0; i < dbk_consumer_processes; i++) { > > pid=fork_process(PROC_NOCHLDINIT, "AMQP Consumer", 1); > > if (pid<0) > > return -1; /* error */ > > if(pid==0){ > > mod_consumer_proc(i+1); > > } > > } > > } > > } > > > > return 0; > > } > > > > > > > > On Mon, Sep 8, 2014 at 1:11 PM, Daniel-Constantin Mierla > > <miconda(a)gmail.com <mailto:miconda@gmail.com>> wrote: > > > > Hello, > > > > the database connection should not be shared beween processes, > > because it can bring unexpected results in may places. > > > > Right now, the rule is to have one connection per process, > > shared by all modules in that process. > > > > To achieve that, at mod_init each module opens database > > connection and closes it before ending the function. Then in > > child_init() the connection is opened again. Another module > > that will have to open in child_init() will get the same > > connection now. > > > > When you create a new process, you tell the type of child and > > based on that child_init() from the other modules are executed. > > > > What is the function do you use for creating a new process? > > Maybe you can paste it here exactly how you do it and I can > > see if something can be done. > > > > Cheers, > > Daniel > > > > > > On 03/09/14 12:09, Luis Azedo wrote: > >> Hi Jason, > >> > >> thanks for the reply. > >> > >> the last 2 statements in presence module mod_init close the > >> connection and set pa_db to NULL. when my module main process > >> forks the extra processes the pa_db in presence is NULL, so > >> when it calls pres_refresh_watchers it fails because pa_db is > >> NULL. > >> i commented these last statements in presence mod_init and i > >> got it to work. > >> > >> // pa_dbf.close(pa_db); > >> // pa_db = NULL; > >> > >> does this have any implications on how the module works ? is > >> it ok to merge this change ? > >> > >> Thank you > >> > >> > >> > >> > ---------------------------------------------------------------------- > >> > >> Message: 1 > >> Date: Sun, 31 Aug 2014 09:40:49 +0200 > >> From: Jason Penton <jason.penton(a)gmail.com > >> <mailto:jason.penton@gmail.com>> > >> To: "Kamailio (SER) - Development Mailing List" > >> <sr-dev(a)lists.sip-router.org > >> <mailto:sr-dev@lists.sip-router.org>> > >> Subject: Re: [sr-dev] accessing database from a child > >> forked process > >> Message-ID: > >> > >> < > CALoGXNWvHhCAO91Tfa0w8W3eYQRvfV7Qkgte7dBnD+ciNr_Kpg(a)mail.gmail.com > >> <mailto: > CALoGXNWvHhCAO91Tfa0w8W3eYQRvfV7Qkgte7dBnD%2BciNr_Kpg(a)mail.gmail.com>> > >> Content-Type: text/plain; charset="utf-8" > >> > >> To confirm exactly what processes are being used, maybe > >> check the log file > >> and take note of process id at each log event. For > >> example you could check > >> the process id of the messages showing you the connection > >> is null. Then run > >> kamcmd ps to show the process list with a description of > >> each Kamailio > >> process. That will probably point you in the correct > >> direction. > >> > >> Cheers > >> Jason > >> > >> > >> On Fri, Aug 29, 2014 at 3:53 PM, Luis Azedo > >> <luis.azedo(a)factorlusitano.com > >> <mailto:luis.azedo@factorlusitano.com>> > >> wrote: > >> > >> > Hi, > >> > > >> > i have a module that creates 1 extra process where it > >> processes stuff in a > >> > loop. > >> > on some condition i fire a route_event with a fakemsg > >> and its up to the > >> > user of the module to take action, it tries to work > >> like dispatcher module > >> > or htable (mod-init) events. > >> > > >> > the problem that i have is that, if i call some > >> function on some module > >> > that performs a database action, the connection is null > >> when it calls > >> > use_table. > >> > > >> > in this case i'm making this call > >> > event_route[my_module:my_event] > >> > { > >> > $var(my_uri) = <<result of some operations>>; > >> > pres_refresh_watchers("$var(my_uri)", "dialog", 1); > >> > } > >> > presence module makes the call to use_table but this > >> call fails because > >> > the connection is null. presence module is working fine > >> besides this. > >> > > >> > if i make this call inside > >> event_route[dispatcher:dst-up] it works. > >> > > >> > i think that dispatcher fires the event inside a > >> callback from a > >> > registered timer, so, i think (may be wrong) that it > >> comes from a different > >> > process ? > >> > > >> > i wonder if i'm missing something from child_init ? > >> need to register > >> > something ? > >> > > >> > thanks for your help. > >> > > >> > > >> > > >> > > >> > > >> > > >> > _______________________________________________ > >> > sr-dev mailing list > >> > sr-dev(a)lists.sip-router.org > >> <mailto:sr-dev@lists.sip-router.org> > >> > > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev > >> > > >> > > >>

2 1

[tracker] Comment added: our Record-Route is doubled on subsequent branches (Attachment added)
by sip-router 08 Sep '14

08 Sep '14

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#466 - our Record-Route is doubled on subsequent branches User who did this - Andrew Pogrebennyk (marduk) ---------- Here is the proxy log with debug=3. ---------- One or more files have been attached. More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=466#comment1611 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.

1 0

[tracker] Task opened: our Record-Route is doubled on subsequent branches
by sip-router 08 Sep '14

08 Sep '14

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - Andrew Pogrebennyk (marduk) Attached to Project - sip-router Summary - our Record-Route is doubled on subsequent branches Task Type - Bug Report Category - Module Status - Unconfirmed Assigned To - Operating System - All Severity - Low Priority - Normal Reported Version - Development Due in Version - Undecided Due Date - Undecided Details - I think I need some help understanding how the record_route() works. I have two kamailio instances running here, one on 127.0.0.1:5060 and another one which is the proxy on 127.0.0.1:5062, UAS on 127.0.0.1:5080. The proxy receives the INVITE which already has the RR of the lb instance on :5060 and sends it to the UAS, this is fine: Sep 8 16:32:04 sp1 proxy[16687]: DEBUG: <core> [parser/parse_rr.c:380]: print_rr_body(): current rr is <sip:127.0.0.1;lr=on;ftag=17519SIPpTag001;ngcplb=yes;socket=udp:127.0.0.1:5060> Sep 8 16:32:04 sp1 proxy[16687]: DEBUG: <core> [parser/parse_rr.c:405]: print_rr_body(): skipping 0 route records Sep 8 16:32:04 sp1 proxy[16687]: DEBUG: <core> [parser/parse_rr.c:443]: print_rr_body(): out rr [<sip:127.0.0.1;lr=on;ftag=17519SIPpTag001;ngcplb=yes;socket=udp:127.0.0.1:5060>] Sep 8 16:32:04 sp1 proxy[16687]: DEBUG: <core> [parser/parse_rr.c:444]: print_rr_body(): we have 1 records ... #### U 2014/09/08 16:32:04.179882 127.0.0.1:5062 -> 127.0.0.1:5080 INVITE sip:testuser1003@127.1.0.1:50604 SIP/2.0. Record-Route: <sip:127.0.0.1:5062;lr=on;ftag=17519SIPpTag001;did=5ad.f301;mpd=ii;ice_caller=strip;ice_callee=strip;aset=50;rtpprx=yes;vsf=NHBnWA4TKgQiEwV5cQgZDg1NRXslXhM9PTE->. Record-Route: <sip:127.0.0.1;lr=on;ftag=17519SIPpTag001;ngcplb=yes;socket=udp:127.0.0.1:5060>. Via: SIP/2.0/UDP 127.0.0.1:5062;branch=z9hG4bK9dda.7e4b118bbf12c6fc683081d44c680ec9.0. Route: <sip:lb@127.0.0.1;lr;socket=sip:127.0.0.1:5060>. Via: SIP/2.0/UDP 127.0.0.1;branch=z9hG4bK9dda.c7a81cd777225e671c9471d1394c1865.0. Via: SIP/2.0/UDP 127.126.0.1:50602;rport=50602;branch=z9hG4bK-17519-1-5. From: <sip:4311002@spce.test>;tag=17519SIPpTag001. To: <sip:testuser1003@spce.test>. Call-ID: 1-17519(a)127.126.0.1. CSeq: 2 INVITE. Contact: sip:testuser1002@127.126.0.1:50602. Max-Forwards: 9. Content-Type: application/sdp. Content-Length: 176. P-Caller-UUID: 074e2a60-4910-4123-88d4-31e2fb88323a. P-Callee-UUID: 9d655469-e443-48a0-beb3-3e6ddd774e22. P-Asserted-Identity: <sip:4311002@spce.test>. P-Called-Party-ID: <sip:testuser1003@spce.test>. P-App-Param: ;aleg_sst_enable=no;sst_enable=no. P-App-Name: sbc. P-NGCP-Caller-Info: <sip:testuser1002@spce.test>;ip=127.126.0.1;port=50602. P-NGCP-Callee-Info: <sip:testuser1003@spce.test>;ip=127.0.0.1;port=5060. P-D-Uri: sip:lb@127.0.0.1;lr;socket=sip:127.0.0.1:5060. . v=0. o=user1 53655765 2353687637 IN IP4 192.168.51.16. s=-. c=IN IP4 192.168.51.16. t=0 0. m=audio 30230 RTP/AVP 8. a=rtpmap:8 PCMA/8000. a=ptime:50. a=sendrecv. a=rtcp:30231. The UAS responds with a 404: # U 2014/09/08 16:32:04.183998 127.0.0.1:5080 -> 127.0.0.1:5062 SIP/2.0 404 Not Found. Record-Route: <sip:127.0.0.1:5062;lr=on;ftag=17519SIPpTag001;did=5ad.f301;mpd=ii;ice_caller=strip;ice_callee=strip;aset=50;rtpprx=yes;vsf=NHBnWA4TKgQiEwV5cQgZDg1NRXslXhM9PTE->. Record-Route: <sip:127.0.0.1;lr=on;ftag=17519SIPpTag001;ngcplb=yes;socket=udp:127.0.0.1:5060>. Via: SIP/2.0/UDP 127.0.0.1:5062;branch=z9hG4bK9dda.7e4b118bbf12c6fc683081d44c680ec9.0;received=127.0.0.1. Via: SIP/2.0/UDP 127.0.0.1;branch=z9hG4bK9dda.c7a81cd777225e671c9471d1394c1865.0. Via: SIP/2.0/UDP 127.126.0.1:50602;rport=50602;branch=z9hG4bK-17519-1-5. From: <sip:4311002@spce.test>;tag=17519SIPpTag001. To: <sip:testuser1003@spce.test>;tag=3B4CEA2F-540DBDE40002BFF2-AB22A700. Call-ID: 1-17519(a)127.126.0.1. CSeq: 2 INVITE. Content-Length: 0. after which we set an alternative destination and call append_branch(): Sep 8 16:32:04 sp1 proxy[16683]: NOTICE: <script>: Fallback from E164 number to user - R=sip:testuser1003@spce.test ID=1-17519(a)127.126.0.1 after that the proxy on :5062 sends the new INVITE to the UAS. This new INVITE has two record-routes belonging to the proxy: ### U 2014/09/08 16:32:04.271489 127.0.0.1:5062 -> 127.0.0.1:5080 INVITE sip:testuser1003@127.1.0.1:50604 SIP/2.0. Record-Route: <sip:127.0.0.1:5062;lr=on;ftag=17519SIPpTag001;did=5ad.f301;mpd=ii;ice_caller=strip;ice_callee=strip;aset=50;rtpprx=yes;vsf=NHBnWA4TKgQiEwV5cQgZDg1NRXslXhM9PTE->. Record-Route: <sip:127.0.0.1:5062;lr=on;ftag=17519SIPpTag001>. Record-Route: <sip:127.0.0.1;lr=on;ftag=17519SIPpTag001;ngcplb=yes;socket=udp:127.0.0.1:5060>. Via: SIP/2.0/UDP 127.0.0.1:5062;branch=z9hG4bK9dda.7e4b118bbf12c6fc683081d44c680ec9.1. Route: <sip:lb@127.0.0.1;lr;socket=sip:127.0.0.1:5060>. Via: SIP/2.0/UDP 127.0.0.1;branch=z9hG4bK9dda.c7a81cd777225e671c9471d1394c1865.0. Via: SIP/2.0/UDP 127.126.0.1:50602;rport=50602;branch=z9hG4bK-17519-1-5. From: <sip:4311002@spce.test>;tag=17519SIPpTag001. To: <sip:testuser1003@spce.test>. Call-ID: 1-17519(a)127.126.0.1. CSeq: 2 INVITE. Contact: sip:testuser1002@127.126.0.1:50602. Max-Forwards: 9. Content-Type: application/sdp. Content-Length: 176. P-Caller-UUID: 074e2a60-4910-4123-88d4-31e2fb88323a. P-Callee-UUID: 9d655469-e443-48a0-beb3-3e6ddd774e22. P-Asserted-Identity: <sip:4311002@spce.test>. P-Called-Party-ID: <sip:testuser1003@spce.test>. P-App-Param: ;aleg_sst_enable=no;sst_enable=no. P-App-Name: sbc. P-NGCP-Caller-Info: <sip:testuser1002@spce.test>;ip=127.126.0.1;port=50602. P-NGCP-Callee-Info: <sip:testuser1003@spce.test>;ip=127.0.0.1;port=5060. P-D-Uri: sip:lb@127.0.0.1;lr;socket=sip:127.0.0.1:5060. . v=0. o=user1 53655765 2353687637 IN IP4 192.168.51.16. s=-. c=IN IP4 192.168.51.16. t=0 0. m=audio 30230 RTP/AVP 8. a=rtpmap:8 PCMA/8000. a=ptime:50. a=sendrecv. a=rtcp:30231. ... Sep 8 16:32:04 sp1 proxy[16684]: DEBUG: <core> [parser/parse_rr.c:380]: print_rr_body(): current rr is <sip:127.0.0.1:5062;lr=on;ftag=17519SIPpTag001;did=5ad.f301;mpd=ii;ice_caller=strip;ice_callee=strip;aset=50;rtpprx=yes;vsf=NHBnWA4TKgQiEwV5cQgZDg1NRXslXhM9PTE-> Sep 8 16:32:04 sp1 proxy[16684]: DEBUG: <core> [parser/parse_rr.c:380]: print_rr_body(): current rr is <sip:127.0.0.1:5062;lr=on;ftag=17519SIPpTag001> Sep 8 16:32:04 sp1 proxy[16684]: DEBUG: <core> [parser/parse_rr.c:380]: print_rr_body(): current rr is <sip:127.0.0.1;lr=on;ftag=17519SIPpTag001;ngcplb=yes;socket=udp:127.0.0.1:5060> Sep 8 16:32:04 sp1 proxy[16684]: DEBUG: <core> [parser/parse_rr.c:405]: print_rr_body(): skipping 3 route records Sep 8 16:32:04 sp1 proxy[16684]: DEBUG: <core> [parser/parse_rr.c:443]: print_rr_body(): out rr [] Sep 8 16:32:04 sp1 proxy[16684]: DEBUG: <core> [parser/parse_rr.c:444]: print_rr_body(): we have 3 records I know that this happens only if I call record_route after t_newtran(), if I create the transaction first it's all fine. But there are reasons why I prefer to do it the way it is. Questions: 1) Is this an incorrect usage or rr module? To me it seems like more a bug in kamailio, because if RR is kept on private memory it should be discarded after failure route, but if the RR persists it should not be added 2nd time. 2) Is there an easy way to check if the RR header has been already added? More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=466 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.

1 0

Re: [sr-dev] accessing database from a child forked proces
by Luis Azedo 08 Sep '14

08 Sep '14

Hi Daniel, all problems solved with presence! i was not running child_init and now there is no need for the proposed patch to presence. Thank you On Mon, Sep 8, 2014 at 2:13 PM, Luis Azedo <luis.azedo(a)factorlusitano.com> wrote: > Hi Daniel, > > this is the way we are creating the child processes (1 manager and n > workers) > the problem is with the workers. > the worker will call a event-route and in the script config we try to call > pres_refresh_watchers and that's where we get the pa_db = NULL. > > as i understand from your email, if we change PROC_NOCHLDINIT and let the > child_init execute for the forked process then it will also execute > child_init in other modules ? it makes sense. > > going to try this. > > > static int mod_child_init(int rank) > { > int pid; > int i; > > fire_init_event(rank); > > if (rank==PROC_MAIN) { > pid=fork_process(PROC_NOCHLDINIT, "AMQP Manager", 1); > if (pid<0) > return -1; /* error */ > if(pid==0){ > kz_amqp_manager_loop(0); > } > else { > for(i=0; i < dbk_consumer_processes; i++) { > pid=fork_process(PROC_NOCHLDINIT, "AMQP Consumer", 1); > if (pid<0) > return -1; /* error */ > if(pid==0){ > mod_consumer_proc(i+1); > } > } > } > } > > return 0; > } > > > > On Mon, Sep 8, 2014 at 1:11 PM, Daniel-Constantin Mierla < > miconda(a)gmail.com> wrote: > >> Hello, >> >> the database connection should not be shared beween processes, because it >> can bring unexpected results in may places. >> >> Right now, the rule is to have one connection per process, shared by all >> modules in that process. >> >> To achieve that, at mod_init each module opens database connection and >> closes it before ending the function. Then in child_init() the connection >> is opened again. Another module that will have to open in child_init() will >> get the same connection now. >> >> When you create a new process, you tell the type of child and based on >> that child_init() from the other modules are executed. >> >> What is the function do you use for creating a new process? Maybe you can >> paste it here exactly how you do it and I can see if something can be done. >> >> Cheers, >> Daniel >> >> >> On 03/09/14 12:09, Luis Azedo wrote: >> >> Hi Jason, >> >> thanks for the reply. >> >> the last 2 statements in presence module mod_init close the connection >> and set pa_db to NULL. when my module main process forks the extra >> processes the pa_db in presence is NULL, so when it calls >> pres_refresh_watchers it fails because pa_db is NULL. >> i commented these last statements in presence mod_init and i got it to >> work. >> >> // pa_dbf.close(pa_db); >> // pa_db = NULL; >> >> does this have any implications on how the module works ? is it ok to >> merge this change ? >> >> Thank you >> >> >>> >>> ---------------------------------------------------------------------- >>> >>> Message: 1 >>> Date: Sun, 31 Aug 2014 09:40:49 +0200 >>> From: Jason Penton <jason.penton(a)gmail.com> >>> To: "Kamailio (SER) - Development Mailing List" >>> <sr-dev(a)lists.sip-router.org> >>> Subject: Re: [sr-dev] accessing database from a child forked process >>> Message-ID: >>> < >>> CALoGXNWvHhCAO91Tfa0w8W3eYQRvfV7Qkgte7dBnD+ciNr_Kpg(a)mail.gmail.com> >>> Content-Type: text/plain; charset="utf-8" >>> >>> To confirm exactly what processes are being used, maybe check the log >>> file >>> and take note of process id at each log event. For example you could >>> check >>> the process id of the messages showing you the connection is null. Then >>> run >>> kamcmd ps to show the process list with a description of each Kamailio >>> process. That will probably point you in the correct direction. >>> >>> Cheers >>> Jason >>> >>> >>> On Fri, Aug 29, 2014 at 3:53 PM, Luis Azedo < >>> luis.azedo(a)factorlusitano.com> >>> wrote: >>> >>> > Hi, >>> > >>> > i have a module that creates 1 extra process where it processes stuff >>> in a >>> > loop. >>> > on some condition i fire a route_event with a fakemsg and its up to the >>> > user of the module to take action, it tries to work like dispatcher >>> module >>> > or htable (mod-init) events. >>> > >>> > the problem that i have is that, if i call some function on some module >>> > that performs a database action, the connection is null when it calls >>> > use_table. >>> > >>> > in this case i'm making this call >>> > event_route[my_module:my_event] >>> > { >>> > $var(my_uri) = <<result of some operations>>; >>> > pres_refresh_watchers("$var(my_uri)", "dialog", 1); >>> > } >>> > presence module makes the call to use_table but this call fails because >>> > the connection is null. presence module is working fine besides this. >>> > >>> > if i make this call inside event_route[dispatcher:dst-up] it works. >>> > >>> > i think that dispatcher fires the event inside a callback from a >>> > registered timer, so, i think (may be wrong) that it comes from a >>> different >>> > process ? >>> > >>> > i wonder if i'm missing something from child_init ? need to register >>> > something ? >>> > >>> > thanks for your help. >>> > >>> > >>> > >>> > >>> > >>> > >>> > _______________________________________________ >>> > sr-dev mailing list >>> > sr-dev(a)lists.sip-router.org >>> > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev >>> > >>> > >>>

2 1

dispatcher module changes
by Luis Azedo 08 Sep '14

08 Sep '14

Hi Daniel, your changes to dispatcher module are great but consider these changes that i attached. 4.6. ds_is_from_list([groupid [, mode [, uri] ] ]) take 0,1,2 or 3 params for me, it does make sense to move the mode prior to uri and allow to call it separately like if( ds_is_from_list(2, 3) ) { ..... } Best

2 1

RTPengine iptables chain case sensitive?
by Peter Villeneuve 08 Sep '14

08 Sep '14

Hi, I compiled and installed deb packages as per the sipwise guide here https://github.com/sipwise/rtpengine. After running modprobe xt_MEDIAPROXY and iptables -I INPUT -p udp -j MEDIAPROXY --id 0 the new chain created is mediaproxy (lower case). Isn't iptables case sensitive? I'm not sure that it is working properly since it seems the mediaproxy chain (lowercase) sends all UDP packets through the MEDIAPROXY (uppercase) chain, which apparently didn't get created. How can I check to make sure that indeed RTPengine is relaying the streams properly? Thanks Here's what my iptables looks like after running modprobe xt_MEDIAPROXY and iptables -I INPUT -p udp -j MEDIAPROXY --id 0 *ncoming packets (INPUT) - Only applies to packets addressed to this host* Select all. <https://securvoice.eu:9998/firewall/index.cgi?table=0#> | Invert selection. <https://securvoice.eu:9998/firewall/index.cgi?table=0#> * <https://securvoice.eu:9998/firewall/index.cgi?table=0#>**Action <https://securvoice.eu:9998/firewall/index.cgi?table=0#>**Condition <https://securvoice.eu:9998/firewall/index.cgi?table=0#>**Move <https://securvoice.eu:9998/firewall/index.cgi?table=0#>**Add <https://securvoice.eu:9998/firewall/index.cgi?table=0#>*Jump to chain MEDIAPROXY <https://securvoice.eu:9998/firewall/edit_rule.cgi?table=0&idx=0>If protocol is *UDP* <https://securvoice.eu:9998/firewall/edit_rule.cgi?table=0&chain=INPUT&new=1…> <https://securvoice.eu:9998/firewall/edit_rule.cgi?table=0&chain=INPUT&new=1…>Select all. <https://securvoice.eu:9998/firewall/index.cgi?table=0#> | Invert selection. <https://securvoice.eu:9998/firewall/index.cgi?table=0#> Accept Drop Userspace Exit chain ------------------------------ *Forwarded packets (FORWARD) - Only applies to packets passed through this host* *There are no rules defined for this chain.* Accept Drop Userspace Exit chain ------------------------------ *Outgoing packets (OUTPUT) - Only applies to packets originated by this host* *There are no rules defined for this chain.* Accept Drop Userspace Exit chain ------------------------------ *Chain mediaproxy* Select all. <https://securvoice.eu:9998/firewall/index.cgi?table=0#> | Invert selection. <https://securvoice.eu:9998/firewall/index.cgi?table=0#> * <https://securvoice.eu:9998/firewall/index.cgi?table=0#>**Action <https://securvoice.eu:9998/firewall/index.cgi?table=0#>**Condition <https://securvoice.eu:9998/firewall/index.cgi?table=0#>**Move <https://securvoice.eu:9998/firewall/index.cgi?table=0#>**Add <https://securvoice.eu:9998/firewall/index.cgi?table=0#>*Jump to chain MEDIAPROXY <https://securvoice.eu:9998/firewall/edit_rule.cgi?table=0&idx=1>If protocol is *UDP*

2 1

Re: [sr-dev] accessing database from a child forked proces
by Luis Azedo 08 Sep '14

08 Sep '14

Hi Jason, thanks for the reply. the last 2 statements in presence module mod_init close the connection and set pa_db to NULL. when my module main process forks the extra processes the pa_db in presence is NULL, so when it calls pres_refresh_watchers it fails because pa_db is NULL. i commented these last statements in presence mod_init and i got it to work. // pa_dbf.close(pa_db); // pa_db = NULL; does this have any implications on how the module works ? is it ok to merge this change ? Thank you > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 31 Aug 2014 09:40:49 +0200 > From: Jason Penton <jason.penton(a)gmail.com> > To: "Kamailio (SER) - Development Mailing List" > <sr-dev(a)lists.sip-router.org> > Subject: Re: [sr-dev] accessing database from a child forked process > Message-ID: > < > CALoGXNWvHhCAO91Tfa0w8W3eYQRvfV7Qkgte7dBnD+ciNr_Kpg(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > To confirm exactly what processes are being used, maybe check the log file > and take note of process id at each log event. For example you could check > the process id of the messages showing you the connection is null. Then run > kamcmd ps to show the process list with a description of each Kamailio > process. That will probably point you in the correct direction. > > Cheers > Jason > > > On Fri, Aug 29, 2014 at 3:53 PM, Luis Azedo <luis.azedo(a)factorlusitano.com > > > wrote: > > > Hi, > > > > i have a module that creates 1 extra process where it processes stuff in > a > > loop. > > on some condition i fire a route_event with a fakemsg and its up to the > > user of the module to take action, it tries to work like dispatcher > module > > or htable (mod-init) events. > > > > the problem that i have is that, if i call some function on some module > > that performs a database action, the connection is null when it calls > > use_table. > > > > in this case i'm making this call > > event_route[my_module:my_event] > > { > > $var(my_uri) = <<result of some operations>>; > > pres_refresh_watchers("$var(my_uri)", "dialog", 1); > > } > > presence module makes the call to use_table but this call fails because > > the connection is null. presence module is working fine besides this. > > > > if i make this call inside event_route[dispatcher:dst-up] it works. > > > > i think that dispatcher fires the event inside a callback from a > > registered timer, so, i think (may be wrong) that it comes from a > different > > process ? > > > > i wonder if i'm missing something from child_init ? need to register > > something ? > > > > thanks for your help. > > > > > > > > > > > > > > _______________________________________________ > > sr-dev mailing list > > sr-dev(a)lists.sip-router.org > > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev > > > > >

2 2

pres_refresh_watchers
by Luis Azedo 08 Sep '14

08 Sep '14

Hi Daniel, the issue that i'm having with calling pres_refresh_watchers (invalid connection when it calls get_p_notify_body) from a forked process from my module disappears if i comment the lines 411 e 412 in presence.c 411 // pa_dbf.close(pa_db); 412 // pa_db = NULL; i can achieve the desired result if i leave these lines intact and add these lines to pres_refresh_watchers if(pa_db == NULL && library_mode == 0) { pa_db = pa_dbf.init(&db_url); } the first change is more global and will keep me from adding the same lines in (2) to other functions like update_watchers_status. i would like to see either of these changes merged in master and ready for 4.2. with these changes and the db_text that i submitted earlier, i can then ask to merge the main module db_kazoo into master. Best

2 1

← Newer
1
...
25
26
27
28
29
30
31
...
38
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev September 2014