Re: [SR-Users] dbtext module issue
ser -- that should be really old release. What is the exact version (ser
-V)?
Cheers,
Daniel
On 13/01/2017 19:50, Satish Patel wrote:
> Any thought?
>
> Sent from my iPhone
>
>> On Jan 12, 2017, at 3:51 PM, Satish Patel wrote:
>>
>> I am trying use dbtext module instead of mysql and following is my
>> configuration. We are using old SER version because of custom written
>> module. Do you think following config looks good.
>>
>> # -- permissions params --
>> modparam("permissions", "db_url", "dbtext:///etc/ser/dbtext")
>> modparam("permissions", "db_mode", 0)
>> modparam("permissions", "trusted_table", "trusted")
>>
>>
>> In function
>>
>> if ( !allow_trusted() &&
>>!search ("^User-Agent:.*Some Perl client.*") ) {
>>xlog("L_WARN", "Drop if User-Agent isn't Perl client");
>>drop;
>>break;
>> };
>>
>>
>> My dbtest contents
>>
>> $ cat /etc/ser/dbtext/trusted
>> src_ip(str) proto(str) from_pattern(str)
>> 10.0.2.20:any:.*
>>
>>
>> When i run ser in fork=no mode i am seeing following
>>
>> ser -f ser.cfg
>>
>> Content of result
>> table_version(int)
>> 2
>>
>> Content of [trusted]
>> src_ip(str) proto(str) from_pattern(str)
>> 10.0.2.20:any:.*
>>
>> Content of result
>> proto(str) from_pattern(str)
>> "any" ".* "
>>
>> Content of result
>> proto(str) from_pattern(str)
>> "any" ".* "
>>
>>
>> it look like it read dbtext file and load data but when i use sipp to
>> generate some call then i am seeing following result only, that means
>> its not loading IP address from table, why its extracting two field
>> but not src_ip ?
>>
>> Content of result
>> proto(str) from_pattern(str)
>> "any" ".* "
> ___
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users@lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Kamailio segfault on TM module
Hello, try to see if you get anything with addr2line tool as suggested at: - http://stackoverflow.com/questions/2549214/interpreting-segfault-messages Cheers, Daniel On 13/01/2017 16:45, José Seabra wrote: > Hi there, > I have noticed a segfault on my kamailio server but as i have > coredumps disabled and i don't know how i can reproduce it, i can't > provide that kind of information. > Anyway i don't know if anyone of you can help with the following > information: > > segfault at 600 ip 7f5cb97af1ea sp 7ffed96b8d60 error 6 in > tm.so[7f5cb9718000+11d000] > > ERROR: tm [t_reply.c:533]: _reply_light(): ERROR: _reply_light: can't > generate 404 reply when a final 200 was sent out > ERROR: sl [sl.c:269]: send_reply(): failed to reply stateful (tm) > WARNING: db_postgres [km_dbase.c:281]: db_postgres_submit_query(): > postgres query command failed, connection status 1, error [no > connection to the server#012] > ALERT: [main.c:739]: handle_sigs(): child process 2048 exited > by a signal 11 > CRITICAL: [pass_fd.c:275]: receive_fd(): EOF on 14 > ALERT: [main.c:742]: handle_sigs(): core was not generated > INFO: [main.c:754]: handle_sigs(): terminating due to SIGCHLD > INFO: [main.c:809]: sig_usr(): signal 15 received > INFO: [main.c:809]: sig_usr(): signal 15 received > INFO: [main.c:809]: sig_usr(): signal 15 received > INFO: [main.c:809]: sig_usr(): signal 15 received > INFO: [main.c:809]: sig_usr(): signal 15 received > INFO: [main.c:809]: sig_usr(): signal 15 received > INFO: [main.c:809]: sig_usr(): signal 15 received > INFO: [main.c:809]: sig_usr(): signal 15 received > INFO: [main.c:809]: sig_usr(): signal 15 received > INFO: [main.c:809]: sig_usr(): signal 15 received > INFO: [main.c:809]: sig_usr(): signal 15 received > INFO: [main.c:809]: sig_usr(): signal 15 received > INFO: [main.c:809]: sig_usr(): signal 15 received > INFO: [main.c:809]: sig_usr(): signal 15 received > INFO: [main.c:809]: sig_usr(): signal 15 received > INFO: [main.c:809]: sig_usr(): signal 15 received > INFO: [main.c:809]: sig_usr(): signal 15 received > INFO: [main.c:809]: sig_usr(): signal 15 received > INFO: [main.c:809]: sig_usr(): signal 15 received > INFO: [main.c:809]: sig_usr(): signal 15 received > INFO: [main.c:809]: sig_usr(): signal 15 received > INFO: [main.c:809]: sig_usr(): signal 15 received > INFO: [main.c:809]: sig_usr(): signal 15 received > INFO: [main.c:809]: sig_usr(): signal 15 received > INFO: [main.c:809]: sig_usr(): signal 15 received > INFO: [main.c:809]: sig_usr(): signal 15 received > INFO: [main.c:809]: sig_usr(): signal 15 received > INFO: [main.c:809]: sig_usr(): signal 15 received > INFO: [main.c:809]: sig_usr(): signal 15 received > INFO: [main.c:809]: sig_usr(): signal 15 received > INFO: [main.c:809]: sig_usr(): signal 15 received > INFO: [main.c:809]: sig_usr(): signal 15 received > INFO: [main.c:809]: sig_usr(): signal 15 received > INFO: [main.c:809]: sig_usr(): signal 15 received > INFO: [main.c:809]: sig_usr(): signal 15 received > INFO: [main.c:809]: sig_usr(): signal 15 received > INFO: [main.c:809]: sig_usr(): signal 15 received > INFO: [main.c:809]: sig_usr(): signal 15 received > INFO: [main.c:809]: sig_usr(): signal 15 received > > > Database server was down during this segfault, but the segfault was on > TM module not on database module. > > Thank you > > Regards > José Seabra > > > ___ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > sr-users@lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users -- Daniel-Constantin Mierla www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Kamailio not processing SIP TCP
Hello,
is it this about a sipcature node? If yes, then it receives the packets
over HEP, meaning that is not going to the normal processing path.
Kamailio detects it is not a SIP packet, executes some callbacks for
non-sip packets registered by modules (in this case sipcapture). The
module detecting it's a packet for it, can execute the request_route
once it builds a local sip packet.
To troubleshoot further, run with debug=3 in kamailio.cfg and see what
you get in the logs.
Cheers,
Daniel
On 13/01/2017 16:33, JR Richardson wrote:
> Iptables is not blocking, but it was worth a check.
>
> Thanks.
>
> JR
>
>
> I assume you have ruled out firewall? It's something that can nab even
> experienced people:
>
> # iptables -Ln
>
> -- Alex
>
> On Thu, Jan 12, 2017 at 03:25:27PM -0600, JR Richardson wrote:
>
>> Hi All,
>>
>> Just enabled SIP TCP on a homer capture server, I can see the SIP TCP
>> Sessions on the server with ngrep, just like all the UDP traffic. I
>> have Kamailio listening on TCP ports but its not capturing any TCP
>> traffic.
>>
>> kamailio.cfg:
>>
>> #disable_tcp=yes
>> listen=tcp:10.99.99.99:5060#monitor port
>> listen=udp:10.99.99.99:5060 #monitor port
>>
>> loadmodule "pv.so"
>> loadmodule "db_mysql.so"
>> loadmodule "sipcapture.so"
>> loadmodule "textops.so"
>> loadmodule "rtimer.so"
>> loadmodule "xlog.so"
>> loadmodule "sqlops.so"
>> loadmodule "htable.so"
>> loadmodule "sl.so"
>> loadmodule "siputils.so"
>>
>>
>> modparam("sipcapture", "capture_on", 1)
>> modparam("sipcapture", "hep_capture_on", 0)
>> modparam("sipcapture", "raw_socket_listen", "10.99.99.99:5060-5070")
>> modparam("sipcapture", "raw_interface", "eth1")
>> modparam("sipcapture", "raw_ipip_capture_on", 0)
>> modparam("sipcapture", "table_name", "sip_capture")
>> modparam("sipcapture", "raw_sock_children", 4)
>> modparam("sipcapture", "db_insert_mode", 0)
>> modparam("sipcapture", "raw_moni_capture_on", 1)
>> modparam("sipcapture", "promiscious_on", 1)
>> modparam("sipcapture", "raw_moni_bpf_on", 1)
>> modparam("sipcapture", "capture_node", "homer02")
>> modparam("sipcapture", "authorization_column", "authorization")
>>
>>
>> ## logging all INVITES top of the [route] block
>> if (is_method("INVITE|REGISTER")) {
>> xlog("L_INFO", "Received INVITE \"$fU\" to \"$rU\"
>> from \"$si\"\n");
>>
>> Logging reports all SIP UDP traffic to logs fine, but no TCP traffic.
>>
>> root@homer02:~# netstat -al
>> Active Internet connections (servers and established)
>> Proto Recv-Q Send-Q Local Address Foreign Address State
>> tcp0 0 homer02.me.com:sip*:* LISTEN
>>
>>
>> I don't think this is a homer issue because logging invites is prior
>> to any homer processing. I'm thinking this is something simple I'm
>> overlooking, any help is much appreciated.
>>
>> Thanks.
>>
>> JR
>> --
>> JR Richardson
>> Engineering for the Masses
>> Chasing the Azeotrope
>>
>> ___
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> sr-users@lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
> ___
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users@lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] Planning the release of v4.4.5
Hello, I am considering to release v4.4.5 with latest fixes from branch 4.4 later this week, on Wednesday or Thursday (Jan 19 or 20). As usual, if anyone has fixes that were not backported yet, do it if you are a developer or write to sr-dev to be sure it is not missed. Sumbit also the new issues you are ware of and they are not on the bug tracker. Cheers, Daniel -- Daniel-Constantin Mierla www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] usrloc module with dbmode=2 does not insert records to database
The record you add via rpc is creating a new contact in memory or it's
updating an existing one?
Can you dump the record after you add it over rpc and send it over to
mailing list to see what attributes it has?
Cheers,
Daniel
On 14/01/2017 16:25, Vik Killa wrote:
> resolution update --
> we found that setting
> `modparam("usrloc", "db_check_update", 1)`
>
> fix the issue by inserting missing rows on re-reg
>
> Thanks!
>
>
> On Fri, Jan 13, 2017 at 9:30 AM, Vik Killa > wrote:
>
> Hi Daniel,
> RPC flush is not setting the flag, but im not sure that is where
> the issue is, as I stated, we are not setting any memory-only
> flags with save()
>
> But here is the flush function (FL_MEM not set)
>
> static void ul_rpc_flush(rpc_t* rpc, void* ctx)
> {
> synchronize_all_udomains(0, 1);
> return;
> }
>
> Any ideas?
> Thanks,
> /V
>
>
> On Fri, Jan 13, 2017 at 9:24 AM, Vik Killa > wrote:
>
> Hi,
> We have tried using these flags:
>
> save("location")
> save("location", "0x00")
> save("location", "0x04")
>
> And still memory does not get flushed to DB.
> I will test the RPC command.
> Thanks,
> /V
>
>
> On Fri, Jan 13, 2017 at 9:12 AM, Daniel-Constantin Mierla
> mailto:mico...@gmail.com>> wrote:
>
> Hello,
>
> that flag is used to mark a contact for storage only in
> memory. The save() function has a parameter with flags
> where this kind of storage can be set. Can you check the
> RPC command is setting this flag?
>
> Cheers,
> Daniel
>
>
> On 13/01/2017 15:06, Vik Killa wrote:
>> following up here
>> i found if we comment out a single line of code, kamcmd
>> ul.flush works
>>
>> here is the git diff
>>
>>
>>
>> diff --git a/src/modules/usrloc/ucontact.c
>> b/src/modules/usrloc/ucontact.c
>> index 47f3c2f..633ca81 100644
>> --- a/src/modules/usrloc/ucontact.c
>> +++ b/src/modules/usrloc/ucontact.c
>> @@ -474,7 +474,7 @@ int db_insert_ucontact(ucontact_t* _c)
>> int nr_cols;
>>
>> if (_c->flags & FL_MEM) {
>> - return 0;
>> + //return 0;
>> }
>> if(unlikely(_c->ruid.len<=0)) {
>> LM_ERR("invalid ruid for aor: %.*s\n",
>>
>>
>>
>>
>>
>> I don't quite understand the logic in that code.
>> Does anyone have an idea of why `if (_c->flags &
>> FL_MEM) {` returns?
>>
>> Thanks,
>> /V
>>
>>
>> On Thu, Jan 12, 2017 at 4:34 PM, Vik Killa
>> mailto:vipki...@gmail.com>> wrote:
>>
>> Hello,
>> we've noticed that the usrloc module does not "sync"
>> all the records from memory into the database.
>> I use a bash script to generate in-memory AoRs
>> (http://paste.debian.net/plain/908521
>> )
>> then i perform
>> kamcmd ul.flush
>> and no records are inserted.
>> We have tried various usrloc parameters but none seem
>> to work
>> Here is our basic setup
>>
>> # - usrloc params -
>> modparam("usrloc", "db_url", DBURL)
>> modparam("usrloc", "db_mode", 2)
>> modparam("usrloc", "use_domain", 1)
>> modparam("usrloc", "timer_interval", 120)
>> modparam("usrloc", "timer_procs", 4)
>>
>> We are using postgresql.
>> are we missing something?
>>
>> Thanks
>> /V
>>
>>
>>
>>
>> ___
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
>> mailing list
>> sr-users@lists.sip-router.org
>>
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>
>
> --
> Daniel-Constantin Mierla
> www.twitter.com/miconda --
> www.linkedin.com/in/miconda
>
> Kamailio World Conference - May 8-10, 2017 -
> www.kamailioworld.com
>
> ___ SIP
> Express Router (SER) and Kamailio (OpenSER) - sr-users
> mailing list sr-users
Re: [SR-Users] Remove/Append headers in 200 canceling and 200 ok to BYE
The 200ok for CANCEL generated by Kamailio doesn't get inside the
onreply_route -- this block is only for SIP replies received by kamailio.
However, the 200ok for CANCEL should have limited (minimal) number of
headers. Which ones besides the Server do you want to remove?
Cheers,
Daniel
On 13/01/2017 19:00, Diego Nadares wrote:
> Thanks Sergey! It works like a charm for BYEs.
>
> Is it working for you on 200cancelling generated by Kamailio?
>
> I tried the same work around with no success.
>
> if (is_method("CANCEL")) {
> if (t_check_trans()) {
> if(!t_is_set("onreply_route"))
>
> t_on_reply("MANAGE_REPLY_ON_CANCEL");
> route(RELAY);
> }
> exit;
> }
>
>
> Thanks again,
>
> Diego
>
>
>
> 2017-01-13 13:27 GMT-03:00 Sergey Basov >:
>
> Hi All.
>
> I have similar task. But i have to remove server and user-agent
> headers from all request an replyes.
>
> You can try:
>
>
> I have added route:
> # Fix user-agent and server
> route[RemoveHeader] {
> remove_hf("server");
> remove_hf("user-agent");
> return;
> }
>
>
> I use it form
> request_route {
>
> route(RemoveHeader);
> .
> }
>
> failure_route[--- all what i have ---] {
>
> route(RemoveHeader);
> .
> }
>
> branch_route[MANAGE_BRANCH]{
>
> route(RemoveHeader);
> .
> }
>
> onreply_route[MANAGE_REPLY] {
>
> route(RemoveHeader);
> .
> }
>
> failure_route[MANAGE_FAILURE] {
>
> route(RemoveHeader);
> .
> }
>
> Seems all is fine It removes headers in all packets except 200 OK
> on BYE
> After debugging script I does not seen in which route this 200 Ok
> goes..
> But if I adding next to
> route[RELAY] {
>
> if (is_method("BYE")) {
> xlog("L_INFO","route RELAY method BYE \n");
> if(!t_is_set("onreply_route"))
> t_on_reply("MANAGE_REPLY_ON_BYE");
> }
> ...
> }
>
> and adding route
> onreply_route[MANAGE_REPLY_ON_BYE] {
> route(RemoveHeader);
> xlog("L_INFO","route MANAGE_REPLY_ON_BYE entered \n");
> }
>
> this 200 Ok successfully goes to MANAGE_REPLY_ON_BYE route and headers
> are removed.
>
>
>
> 13 янв. 2017 г. 4:59 PM пользователь "Diego Nadares"
> mailto:dnada...@gmail.com>> написал:
>
> If you need any additional data please let me know.
>
> Cheers,
>
> Diego
>
> 2017-01-12 15:04 GMT-03:00 Diego Nadares >:
>
> Hi Daniel!
>
> Thanks for your answer. The idea is to show only a few
> headers. In BYE works great. I'm removing and adding the
> following hdrs:
> *
> *
> *User-Agent: Kamailio. <---I will try what you said*
> *Supported:.*
> *Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, NOTIFY, INFO.*
> *Accept: application/sdp, application/gtd.*
>
> For example in following messages ( Kamailio is 172.16.213.38)
>
> #
> U 2017/01/12 14:51:10.593782 172.16.200.159:57270
> -> 172.16.213.38:5060
>
> BYE sip:127.0.0.8:5060;line=sr-9879879879798** SIP/2.0.
> Via: SIP/2.0/UDP 172.16.200.159:5060;branch=z9hG4bK12B9605ED.
> From: xx >;tag=95E7E4A4-23F2.
> To: xxx >;tag=SDmmb7201-as0518eb07.
> Date: Thu, 12 Jan 2017 17:51:05 GMT.
> Call-ID: SDmmb7201-f5ded6cf4cd5d84736b088e39277e8db-c540dl1.
> User-Agent: Cisco-SIPGateway/IOS-12.x.
> Max-Forwards: 15.
> Route:
> .
> Timestamp: 1484243470.
> CSeq: 101 BYE.
> Reason: Q.850;cause=16.
> Content-Disposition: signal;handling=optional.
> Content-Type: application/gtd.
> Content-Length: 26.
> .
> .
> .
>
> #
> U 2017/01/12 14:51:10.647164 172.16.213.38:5060
> -> 172.16.50.41:5060
>
> BYE sip:xxx@172.16.50.41:5060
> ;transport=udp SIP/2.0.
> Via: SIP/2.0/UDP
>
> 172.16.213.38;branch=z9hG4bKdcf6.f898feef02d601e36a22d26bf3ae5e4a.0.
> Via: SIP/2.0/UDP 127.0.0.8;branch=z9hG4bKsr-asdfasdfF.
> From: xx >;tag=95E7E4A4-23
Re: [SR-Users] Remove/Append headers in 200 canceling and 200 ok to BYE
Hi Daniel,
With the minimal it's great. The headers are the ones that we can show. Now
we are using the server_header and with this it's complete.
Thanks!
Diego.
2017-01-16 5:31 GMT-03:00 Daniel-Constantin Mierla :
> The 200ok for CANCEL generated by Kamailio doesn't get inside the
> onreply_route -- this block is only for SIP replies received by kamailio.
>
> However, the 200ok for CANCEL should have limited (minimal) number of
> headers. Which ones besides the Server do you want to remove?
>
> Cheers,
> Daniel
> On 13/01/2017 19:00, Diego Nadares wrote:
>
> Thanks Sergey! It works like a charm for BYEs.
>
> Is it working for you on 200cancelling generated by Kamailio?
>
> I tried the same work around with no success.
>
> if (is_method("CANCEL")) {
> if (t_check_trans()) {
> if(!t_is_set("onreply_route"))
> t_on_reply("MANAGE_REPLY_ON_
> CANCEL");
> route(RELAY);
> }
> exit;
> }
>
>
> Thanks again,
>
> Diego
>
>
>
> 2017-01-13 13:27 GMT-03:00 Sergey Basov :
>
>> Hi All.
>>
>> I have similar task. But i have to remove server and user-agent headers
>> from all request an replyes.
>>
>> You can try:
>>
>>
>> I have added route:
>> # Fix user-agent and server
>> route[RemoveHeader] {
>> remove_hf("server");
>> remove_hf("user-agent");
>> return;
>> }
>>
>>
>> I use it form
>> request_route {
>>
>> route(RemoveHeader);
>> .
>> }
>>
>> failure_route[--- all what i have ---] {
>>
>> route(RemoveHeader);
>> .
>> }
>>
>> branch_route[MANAGE_BRANCH]{
>>
>> route(RemoveHeader);
>> .
>> }
>>
>> onreply_route[MANAGE_REPLY] {
>>
>> route(RemoveHeader);
>> .
>> }
>>
>> failure_route[MANAGE_FAILURE] {
>>
>> route(RemoveHeader);
>> .
>> }
>>
>> Seems all is fine It removes headers in all packets except 200 OK on
>> BYE
>> After debugging script I does not seen in which route this 200 Ok goes..
>> But if I adding next to
>> route[RELAY] {
>>
>> if (is_method("BYE")) {
>> xlog("L_INFO","route RELAY method BYE \n");
>> if(!t_is_set("onreply_route"))
>> t_on_reply("MANAGE_REPLY_ON_BYE");
>> }
>> ...
>> }
>>
>> and adding route
>> onreply_route[MANAGE_REPLY_ON_BYE] {
>> route(RemoveHeader);
>> xlog("L_INFO","route MANAGE_REPLY_ON_BYE entered \n");
>> }
>>
>> this 200 Ok successfully goes to MANAGE_REPLY_ON_BYE route and headers
>> are removed.
>>
>>
>>
>> 13 янв. 2017 г. 4:59 PM пользователь "Diego Nadares"
>> написал:
>>
>> If you need any additional data please let me know.
>>
>> Cheers,
>>
>> Diego
>>
>> 2017-01-12 15:04 GMT-03:00 Diego Nadares :
>>
>>> Hi Daniel!
>>>
>>> Thanks for your answer. The idea is to show only a few headers. In BYE
>>> works great. I'm removing and adding the following hdrs:
>>>
>>> *User-Agent: Kamailio. <---I will try what you said*
>>> *Supported:.*
>>> *Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, NOTIFY, INFO.*
>>> *Accept: application/sdp, application/gtd.*
>>>
>>> For example in following messages ( Kamailio is 172.16.213.38)
>>>
>>> #
>>> U 2017/01/12 14:51:10.593782 172.16.200.159:57270 -> 172.16.213.38:5060
>>> BYE sip:127.0.0.8:5060;line=sr-9879879879798** SIP/2.0.
>>> Via: SIP/2.0/UDP 172.16.200.159:5060;branch=z9hG4bK12B9605ED.
>>> From: xx ;tag=95E7E4A4-23F2.
>>> To: xxx ;tag=SDmmb7201-as0518eb07.
>>> Date: Thu, 12 Jan 2017 17:51:05 GMT.
>>> Call-ID: SDmmb7201-f5ded6cf4cd5d84736b088e39277e8db-c540dl1.
>>> User-Agent: Cisco-SIPGateway/IOS-12.x.
>>> Max-Forwards: 15.
>>> Route: .
>>> Timestamp: 1484243470.
>>> CSeq: 101 BYE.
>>> Reason: Q.850;cause=16.
>>> Content-Disposition: signal;handling=optional.
>>> Content-Type: application/gtd.
>>> Content-Length: 26.
>>> .
>>> .
>>> .
>>>
>>> #
>>> U 2017/01/12 14:51:10.647164 172.16.213.38:5060 -> 172.16.50.41:5060
>>> BYE sip:xxx@172.16.50.41:5060;transport=udp SIP/2.0.
>>> Via: SIP/2.0/UDP 172.16.213.38;branch=z9hG4bKdc
>>> f6.f898feef02d601e36a22d26bf3ae5e4a.0.
>>> Via: SIP/2.0/UDP 127.0.0.8;branch=z9hG4bKsr-asdfasdfF.
>>> From: xx ;tag=95E7E4A4-23F2.
>>> To: xxx ;tag=SDmmb7201-as0518eb07.
>>> Call-ID: SDmmb7201-f5ded6cf4cd5d84736b088e39277e8db-c540dl1.
>>> Max-Forwards: 14.
>>> CSeq: 101 BYE.
>>> Content-Type: application/gtd.
>>> Content-Length: 26.
>>> *User-Agent: Kamailio.*
>>> *Supported:.*
>>> *Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, NOTIFY, INFO.*
>>> *Accept: application/sdp, application/gtd.*
>>> .
>>> ..
>>>
>>> But in ok I can't
>>>
>>> #
>>> U 2017/01/12 14:51:10.653701 172.16.50.41:5060 -> 172.16.213.38:5060
>>> SIP/2.0 200 OK.
>>> Via: SIP/2.0/UDP 172.16.213.38;branch=z9hG4bKdc
>>> f6.f898feef02d601e36a22d26bf3ae5e4a.0.
>>> Via: SIP/2.0/UDP 127.0.0.8;branch=z9hG4bKsr-sadfasdf.
>>> From: xx ;tag=95E7E4A4-23F2.
>>> To: xxx ;tag=SDmmb7201-as0518eb07.
>>> Call-ID: SDmmb7201-f5ded6cf4cd5d84736b088e39277e8db-c540dl1.
>>> CSeq
Re: [SR-Users] usrloc module with dbmode=2 does not insert records to database
The record we added via RPC was first creating a new contact (and inserting
into the db), this was working fine. But we found that if we cleared the
database, any "updates" would fail. Adding that parameter caused the record
to get inserted if an update failed (re-register)
On Mon, Jan 16, 2017 at 3:28 AM, Daniel-Constantin Mierla wrote:
> The record you add via rpc is creating a new contact in memory or it's
> updating an existing one?
>
> Can you dump the record after you add it over rpc and send it over to
> mailing list to see what attributes it has?
>
> Cheers,
> Daniel
>
> On 14/01/2017 16:25, Vik Killa wrote:
>
> resolution update --
> we found that setting
> `modparam("usrloc", "db_check_update", 1)`
>
> fix the issue by inserting missing rows on re-reg
>
> Thanks!
>
>
> On Fri, Jan 13, 2017 at 9:30 AM, Vik Killa wrote:
>
>> Hi Daniel,
>> RPC flush is not setting the flag, but im not sure that is where the
>> issue is, as I stated, we are not setting any memory-only flags with save()
>>
>> But here is the flush function (FL_MEM not set)
>>
>> static void ul_rpc_flush(rpc_t* rpc, void* ctx)
>> {
>> synchronize_all_udomains(0, 1);
>> return;
>> }
>>
>> Any ideas?
>> Thanks,
>> /V
>>
>>
>> On Fri, Jan 13, 2017 at 9:24 AM, Vik Killa wrote:
>>
>>> Hi,
>>> We have tried using these flags:
>>>
>>> save("location")
>>> save("location", "0x00")
>>> save("location", "0x04")
>>>
>>> And still memory does not get flushed to DB.
>>> I will test the RPC command.
>>> Thanks,
>>> /V
>>>
>>>
>>> On Fri, Jan 13, 2017 at 9:12 AM, Daniel-Constantin Mierla <
>>> mico...@gmail.com> wrote:
>>>
Hello,
that flag is used to mark a contact for storage only in memory. The
save() function has a parameter with flags where this kind of storage can
be set. Can you check the RPC command is setting this flag?
Cheers,
Daniel
On 13/01/2017 15:06, Vik Killa wrote:
following up here
i found if we comment out a single line of code, kamcmd ul.flush works
here is the git diff
diff --git a/src/modules/usrloc/ucontact.c
b/src/modules/usrloc/ucontact.c
index 47f3c2f..633ca81 100644
--- a/src/modules/usrloc/ucontact.c
+++ b/src/modules/usrloc/ucontact.c
@@ -474,7 +474,7 @@ int db_insert_ucontact(ucontact_t* _c)
int nr_cols;
if (_c->flags & FL_MEM) {
- return 0;
+ //return 0;
}
if(unlikely(_c->ruid.len<=0)) {
LM_ERR("invalid ruid for aor: %.*s\n",
I don't quite understand the logic in that code.
Does anyone have an idea of why `if (_c->flags & FL_MEM) {`
returns?
Thanks,
/V
On Thu, Jan 12, 2017 at 4:34 PM, Vik Killa wrote:
> Hello,
> we've noticed that the usrloc module does not "sync" all the records
> from memory into the database.
> I use a bash script to generate in-memory AoRs (
> http://paste.debian.net/plain/908521)
> then i perform
> kamcmd ul.flush
> and no records are inserted.
> We have tried various usrloc parameters but none seem to work
> Here is our basic setup
>
> # - usrloc params -
> modparam("usrloc", "db_url", DBURL)
> modparam("usrloc", "db_mode", 2)
> modparam("usrloc", "use_domain", 1)
> modparam("usrloc", "timer_interval", 120)
> modparam("usrloc", "timer_procs", 4)
>
> We are using postgresql.
> are we missing something?
>
> Thanks
> /V
>
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
listsr-us...@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierlawww.twitter.com/miconda --
www.linkedin.com/in/miconda
Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com
___ SIP Express Router
(SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org http://lists.sip-router.org/cg
i-bin/mailman/listinfo/sr-users
>>>
>>> ___
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
> listsr-us...@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
> --
> Daniel-Constantin Mierlawww.twitter.com/miconda -- www.linkedin.com/in/miconda
> Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com
>
>
> ___
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users@lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-
Re: [SR-Users] usrloc module with dbmode=2 does not insert records to database
You should not delete the record only from database via a db client
There is a rpc command to delete it, which will take care of removing it
from memory as well as from database (depending on the db_mode module
parameter for usrloc).
Cheers,
Daniel
On 16/01/2017 14:46, Vik Killa wrote:
> The record we added via RPC was first creating a new contact (and
> inserting into the db), this was working fine. But we found that if we
> cleared the database, any "updates" would fail. Adding that parameter
> caused the record to get inserted if an update failed (re-register)
>
>
> On Mon, Jan 16, 2017 at 3:28 AM, Daniel-Constantin Mierla
> mailto:mico...@gmail.com>> wrote:
>
> The record you add via rpc is creating a new contact in memory or
> it's updating an existing one?
>
> Can you dump the record after you add it over rpc and send it over
> to mailing list to see what attributes it has?
>
> Cheers,
> Daniel
>
>
> On 14/01/2017 16:25, Vik Killa wrote:
>> resolution update --
>> we found that setting
>> `modparam("usrloc", "db_check_update", 1)`
>>
>> fix the issue by inserting missing rows on re-reg
>>
>> Thanks!
>>
>>
>> On Fri, Jan 13, 2017 at 9:30 AM, Vik Killa > > wrote:
>>
>> Hi Daniel,
>> RPC flush is not setting the flag, but im not sure that is
>> where the issue is, as I stated, we are not setting any
>> memory-only flags with save()
>>
>> But here is the flush function (FL_MEM not set)
>>
>> static void ul_rpc_flush(rpc_t* rpc, void* ctx)
>> {
>> synchronize_all_udomains(0, 1);
>> return;
>> }
>>
>> Any ideas?
>> Thanks,
>> /V
>>
>>
>> On Fri, Jan 13, 2017 at 9:24 AM, Vik Killa
>> mailto:vipki...@gmail.com>> wrote:
>>
>> Hi,
>> We have tried using these flags:
>>
>> save("location")
>> save("location", "0x00")
>> save("location", "0x04")
>>
>> And still memory does not get flushed to DB.
>> I will test the RPC command.
>> Thanks,
>> /V
>>
>>
>> On Fri, Jan 13, 2017 at 9:12 AM, Daniel-Constantin Mierla
>> mailto:mico...@gmail.com>> wrote:
>>
>> Hello,
>>
>> that flag is used to mark a contact for storage only
>> in memory. The save() function has a parameter with
>> flags where this kind of storage can be set. Can you
>> check the RPC command is setting this flag?
>>
>> Cheers,
>> Daniel
>>
>>
>> On 13/01/2017 15:06, Vik Killa wrote:
>>> following up here
>>> i found if we comment out a single line of code,
>>> kamcmd ul.flush works
>>>
>>> here is the git diff
>>>
>>>
>>>
>>> diff --git a/src/modules/usrloc/ucontact.c
>>> b/src/modules/usrloc/ucontact.c
>>> index 47f3c2f..633ca81 100644
>>> --- a/src/modules/usrloc/ucontact.c
>>> +++ b/src/modules/usrloc/ucontact.c
>>> @@ -474,7 +474,7 @@ int
>>> db_insert_ucontact(ucontact_t* _c)
>>> int nr_cols;
>>>
>>> if (_c->flags & FL_MEM) {
>>> - return 0;
>>> + //return 0;
>>> }
>>> if(unlikely(_c->ruid.len<=0)) {
>>> LM_ERR("invalid ruid for aor: %.*s\n",
>>>
>>>
>>>
>>>
>>>
>>> I don't quite understand the logic in that code.
>>> Does anyone have an idea of why `if
>>> (_c->flags & FL_MEM) {` returns?
>>>
>>> Thanks,
>>> /V
>>>
>>>
>>> On Thu, Jan 12, 2017 at 4:34 PM, Vik Killa
>>> mailto:vipki...@gmail.com>> wrote:
>>>
>>> Hello,
>>> we've noticed that the usrloc module does not
>>> "sync" all the records from memory into the
>>> database.
>>> I use a bash script to generate in-memory AoRs
>>> (http://paste.debian.net/plain/908521
>>> )
>>> then i perform
>>> kamcmd ul.flush
>>> and no records are inserted.
>>> We have tried various usrloc parameters but none
>>> seem to work
>>> Here is our basic setup
>>>
>>> # - usrloc params -
>>> modparam("usrloc", "db_url", DBURL)
>>> modparam("usrloc", "db_mode", 2)
>>> modparam("
Re: [SR-Users] Remove/Append headers in 200 canceling and 200 ok to BYE
Hello,
ok -- good that you could get what you need.
As extra details that might be useful for you or others.
Removing headers from received requests or replies can be done in two
places:
- inside request_route { ... } for requests
- inside reply_route { ... } for replies
The replies generated by Kamailio should have only required headers by
SIP, if you want to add more, you have to use append_to_reply() function
from textops module.
Cheers,
Daniel
On 16/01/2017 13:56, Diego Nadares wrote:
> Hi Daniel,
>
> With the minimal it's great. The headers are the ones that we can
> show. Now we are using the server_header and with this it's complete.
>
> Thanks!
>
> Diego.
>
> 2017-01-16 5:31 GMT-03:00 Daniel-Constantin Mierla >:
>
> The 200ok for CANCEL generated by Kamailio doesn't get inside the
> onreply_route -- this block is only for SIP replies received by
> kamailio.
>
> However, the 200ok for CANCEL should have limited (minimal) number
> of headers. Which ones besides the Server do you want to remove?
>
> Cheers,
> Daniel
>
> On 13/01/2017 19:00, Diego Nadares wrote:
>> Thanks Sergey! It works like a charm for BYEs.
>>
>> Is it working for you on 200cancelling generated by Kamailio?
>>
>> I tried the same work around with no success.
>>
>> if (is_method("CANCEL")) {
>> if (t_check_trans()) {
>> if(!t_is_set("onreply_route"))
>>
>> t_on_reply("MANAGE_REPLY_ON_CANCEL");
>> route(RELAY);
>> }
>> exit;
>> }
>>
>>
>> Thanks again,
>>
>> Diego
>>
>>
>>
>> 2017-01-13 13:27 GMT-03:00 Sergey Basov > >:
>>
>> Hi All.
>>
>> I have similar task. But i have to remove server and
>> user-agent headers from all request an replyes.
>>
>> You can try:
>>
>>
>> I have added route:
>> # Fix user-agent and server
>> route[RemoveHeader] {
>> remove_hf("server");
>> remove_hf("user-agent");
>> return;
>> }
>>
>>
>> I use it form
>> request_route {
>>
>> route(RemoveHeader);
>> .
>> }
>>
>> failure_route[--- all what i have ---] {
>>
>> route(RemoveHeader);
>> .
>> }
>>
>> branch_route[MANAGE_BRANCH]{
>>
>> route(RemoveHeader);
>> .
>> }
>>
>> onreply_route[MANAGE_REPLY] {
>>
>> route(RemoveHeader);
>> .
>> }
>>
>> failure_route[MANAGE_FAILURE] {
>>
>> route(RemoveHeader);
>> .
>> }
>>
>> Seems all is fine It removes headers in all packets except
>> 200 OK on BYE
>> After debugging script I does not seen in which route this
>> 200 Ok goes..
>> But if I adding next to
>> route[RELAY] {
>>
>> if (is_method("BYE")) {
>> xlog("L_INFO","route RELAY method BYE \n");
>> if(!t_is_set("onreply_route"))
>> t_on_reply("MANAGE_REPLY_ON_BYE");
>> }
>> ...
>> }
>>
>> and adding route
>> onreply_route[MANAGE_REPLY_ON_BYE] {
>> route(RemoveHeader);
>> xlog("L_INFO","route MANAGE_REPLY_ON_BYE entered \n");
>> }
>>
>> this 200 Ok successfully goes to MANAGE_REPLY_ON_BYE route
>> and headers
>> are removed.
>>
>>
>>
>> 13 янв. 2017 г. 4:59 PM пользователь "Diego Nadares"
>> mailto:dnada...@gmail.com>> написал:
>>
>> If you need any additional data please let me know.
>>
>> Cheers,
>>
>> Diego
>>
>> 2017-01-12 15:04 GMT-03:00 Diego Nadares
>> mailto:dnada...@gmail.com>>:
>>
>> Hi Daniel!
>>
>> Thanks for your answer. The idea is to show only a
>> few headers. In BYE works great. I'm removing and
>> adding the following hdrs:
>> *
>> *
>> *User-Agent: Kamailio. <---I will try what you said*
>> *Supported:.*
>> *Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, NOTIFY, INFO.*
>> *Accept: application/sdp, application/gtd.*
>>
>> For example in following messages ( Kamailio is
>> 172.16.213.38)
>>
>> #
>> U 2017/01/12 14:51:10.593782 172.16.200.159:57270
>> -> 172.16.213.38:5060
>>
>> BYE sip:127.0.0.8:5060;line=sr-9879879879798** SIP/2.0.
>>
Re: [SR-Users] usrloc module with dbmode=2 does not insert records to database
We did not purposely delete the records. But we were dealing with a setup
where the db was "out-of-sync" with memory. The reason I deleted them
during our tests was to replicate the issue we had in production.
The param we enabled fixed the issue within 30minutes by inserted when an
update failed.
On Mon, Jan 16, 2017 at 9:27 AM, Daniel-Constantin Mierla wrote:
> You should not delete the record only from database via a db client There
> is a rpc command to delete it, which will take care of removing it from
> memory as well as from database (depending on the db_mode module parameter
> for usrloc).
>
> Cheers,
> Daniel
>
> On 16/01/2017 14:46, Vik Killa wrote:
>
> The record we added via RPC was first creating a new contact (and
> inserting into the db), this was working fine. But we found that if we
> cleared the database, any "updates" would fail. Adding that parameter
> caused the record to get inserted if an update failed (re-register)
>
>
> On Mon, Jan 16, 2017 at 3:28 AM, Daniel-Constantin Mierla <
> mico...@gmail.com> wrote:
>
>> The record you add via rpc is creating a new contact in memory or it's
>> updating an existing one?
>>
>> Can you dump the record after you add it over rpc and send it over to
>> mailing list to see what attributes it has?
>>
>> Cheers,
>> Daniel
>>
>> On 14/01/2017 16:25, Vik Killa wrote:
>>
>> resolution update --
>> we found that setting
>> `modparam("usrloc", "db_check_update", 1)`
>>
>> fix the issue by inserting missing rows on re-reg
>>
>> Thanks!
>>
>>
>> On Fri, Jan 13, 2017 at 9:30 AM, Vik Killa wrote:
>>
>>> Hi Daniel,
>>> RPC flush is not setting the flag, but im not sure that is where the
>>> issue is, as I stated, we are not setting any memory-only flags with save()
>>>
>>> But here is the flush function (FL_MEM not set)
>>>
>>> static void ul_rpc_flush(rpc_t* rpc, void* ctx)
>>> {
>>> synchronize_all_udomains(0, 1);
>>> return;
>>> }
>>>
>>> Any ideas?
>>> Thanks,
>>> /V
>>>
>>>
>>> On Fri, Jan 13, 2017 at 9:24 AM, Vik Killa wrote:
>>>
Hi,
We have tried using these flags:
save("location")
save("location", "0x00")
save("location", "0x04")
And still memory does not get flushed to DB.
I will test the RPC command.
Thanks,
/V
On Fri, Jan 13, 2017 at 9:12 AM, Daniel-Constantin Mierla <
mico...@gmail.com> wrote:
> Hello,
>
> that flag is used to mark a contact for storage only in memory. The
> save() function has a parameter with flags where this kind of storage can
> be set. Can you check the RPC command is setting this flag?
> Cheers,
> Daniel
>
>
> On 13/01/2017 15:06, Vik Killa wrote:
>
> following up here
> i found if we comment out a single line of code, kamcmd ul.flush works
>
> here is the git diff
>
>
>
> diff --git a/src/modules/usrloc/ucontact.c
> b/src/modules/usrloc/ucontact.c
> index 47f3c2f..633ca81 100644
> --- a/src/modules/usrloc/ucontact.c
> +++ b/src/modules/usrloc/ucontact.c
> @@ -474,7 +474,7 @@ int db_insert_ucontact(ucontact_t* _c)
> int nr_cols;
>
> if (_c->flags & FL_MEM) {
> - return 0;
> + //return 0;
> }
> if(unlikely(_c->ruid.len<=0)) {
> LM_ERR("invalid ruid for aor: %.*s\n",
>
>
>
>
>
> I don't quite understand the logic in that code.
> Does anyone have an idea of why `if (_c->flags & FL_MEM) {`
> returns?
>
> Thanks,
> /V
>
>
> On Thu, Jan 12, 2017 at 4:34 PM, Vik Killa wrote:
>
>> Hello,
>> we've noticed that the usrloc module does not "sync" all the records
>> from memory into the database.
>> I use a bash script to generate in-memory AoRs (
>> http://paste.debian.net/plain/908521)
>> then i perform
>> kamcmd ul.flush
>> and no records are inserted.
>> We have tried various usrloc parameters but none seem to work
>> Here is our basic setup
>>
>> # - usrloc params -
>> modparam("usrloc", "db_url", DBURL)
>> modparam("usrloc", "db_mode", 2)
>> modparam("usrloc", "use_domain", 1)
>> modparam("usrloc", "timer_interval", 120)
>> modparam("usrloc", "timer_procs", 4)
>>
>> We are using postgresql.
>> are we missing something?
>>
>> Thanks
>> /V
>>
>
>
>
> ___
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
> listsr-us...@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
> --
> Daniel-Constantin Mierlawww.twitter.com/miconda --
> www.linkedin.com/in/miconda
> Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com
>
> ___ SIP Express Router
> (SER) and Kamailio (OpenSER) - sr-
Re: [SR-Users] Kamailio not processing SIP TCP
Hey Daniel,
Yes, I'm familiar with the methods sipcapture uses, I don't use HEP,
using raw socket capture, I think this may be a sipcapture issue,
debuging kamailio shows normal startup and processing of UDP SIP
packets, but does not show any activity with TCP packets. I have
enabled/disabled the different capture methods and no TCP SIP packets
are processed. Also, I didn't mention before I'm testing on 2
different instances, one is a Homer 3.5 (Kamailio 4.1.2) and another
is Homer 5.0 (Kamailio 4.4.0). I'll post to the Homer list and see
what they say.
Thanks.
JR
> is it this about a sipcature node? If yes, then it receives the packets
> over HEP, meaning that is not going to the normal processing path.
> Kamailio detects it is not a SIP packet, executes some callbacks for
> non-sip packets registered by modules (in this case sipcapture). The
> module detecting it's a packet for it, can execute the request_route
> once it builds a local sip packet.
>
> To troubleshoot further, run with debug=3 in kamailio.cfg and see what
> you get in the logs.
>
> Cheers,
> Daniel
>
> On 13/01/2017 16:33, JR Richardson wrote:
>> Iptables is not blocking, but it was worth a check.
>>
>> Thanks.
>>
>> JR
>>
>>
>> I assume you have ruled out firewall? It's something that can nab even
>> experienced people:
>>
>> # iptables -Ln
>>
>> -- Alex
>>
>> On Thu, Jan 12, 2017 at 03:25:27PM -0600, JR Richardson wrote:
>>
>>> Hi All,
>>>
>>> Just enabled SIP TCP on a homer capture server, I can see the SIP TCP
>>> Sessions on the server with ngrep, just like all the UDP traffic. I
>>> have Kamailio listening on TCP ports but its not capturing any TCP
>>> traffic.
>>>
>>> kamailio.cfg:
>>>
>>> #disable_tcp=yes
>>> listen=tcp:10.99.99.99:5060#monitor port
>>> listen=udp:10.99.99.99:5060 #monitor port
>>>
>>> loadmodule "pv.so"
>>> loadmodule "db_mysql.so"
>>> loadmodule "sipcapture.so"
>>> loadmodule "textops.so"
>>> loadmodule "rtimer.so"
>>> loadmodule "xlog.so"
>>> loadmodule "sqlops.so"
>>> loadmodule "htable.so"
>>> loadmodule "sl.so"
>>> loadmodule "siputils.so"
>>>
>>>
>>> modparam("sipcapture", "capture_on", 1)
>>> modparam("sipcapture", "hep_capture_on", 0)
>>> modparam("sipcapture", "raw_socket_listen", "10.99.99.99:5060-5070")
>>> modparam("sipcapture", "raw_interface", "eth1")
>>> modparam("sipcapture", "raw_ipip_capture_on", 0)
>>> modparam("sipcapture", "table_name", "sip_capture")
>>> modparam("sipcapture", "raw_sock_children", 4)
>>> modparam("sipcapture", "db_insert_mode", 0)
>>> modparam("sipcapture", "raw_moni_capture_on", 1)
>>> modparam("sipcapture", "promiscious_on", 1)
>>> modparam("sipcapture", "raw_moni_bpf_on", 1)
>>> modparam("sipcapture", "capture_node", "homer02")
>>> modparam("sipcapture", "authorization_column", "authorization")
>>>
>>>
>>> ## logging all INVITES top of the [route] block
>>> if (is_method("INVITE|REGISTER")) {
>>> xlog("L_INFO", "Received INVITE \"$fU\" to \"$rU\"
>>> from \"$si\"\n");
>>>
>>> Logging reports all SIP UDP traffic to logs fine, but no TCP traffic.
>>>
>>> root@homer02:~# netstat -al
>>> Active Internet connections (servers and established)
>>> Proto Recv-Q Send-Q Local Address Foreign Address State
>>> tcp0 0 homer02.me.com:sip*:* LISTEN
>>>
>>>
>>> I don't think this is a homer issue because logging invites is prior
>>> to any homer processing. I'm thinking this is something simple I'm
>>> overlooking, any help is much appreciated.
>>>
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Kamailio not processing SIP TCP
On Mon, Jan 16, 2017 at 10:29:39AM -0600, JR Richardson wrote: > Yes, I'm familiar with the methods sipcapture uses, I don't use HEP, > using raw socket capture, I think this may be a sipcapture issue, > debuging kamailio shows normal startup and processing of UDP SIP > packets, but does not show any activity with TCP packets. I never used HOMER sofar but when I saw your first message my thoughts was that this can't work in a simple way since for TCP you need to complete a 4 way handshake before you can start to send data. ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] LCR module dont_strip_or_tag_flag
Hello,
I'm trying LCR module and dont_strip_or_tag_flag parameter.
If I use this line in the module configuration:
modparam("lcr", "dont_strip_or_tag_flag", 10)
and then restart kamailio, i receive this error:
ERROR: [modparam.c:141]: set_mod_param_regex(): parameter
of type <2> not found in module
I'm using 4.4.4 version
Any hint?
Thank you
Regards
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] LCR module dont_strip_or_tag_flag -> dont_strip_or_prefix_flag
Annus Fictus :
> modparam("lcr", "dont_strip_or_tag_flag", 10)
>
> and then restart kamailio, i receive this error:
>
> ERROR: [modparam.c:141]: set_mod_param_regex(): parameter
> of type <2> not found in module
Hi
Looks like that parameter is now¹ called dont_strip_or_prefix_flag
but module documentation was just not updated.
[1] Change was committed in 2010
https://github.com/kamailio/kamailio/commit/8c0501bfaa27acab9721953e8c1551687c96edf2
--
Mikko
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] LCR module dont_strip_or_tag_flag -> dont_strip_or_prefix_flag
Thnak you...
With dont_strip_or_prefix_flag working.
Regards
El 16/01/2017 a las 15:31, Mikko Lehto escribió:
Annus Fictus :
modparam("lcr", "dont_strip_or_tag_flag", 10)
and then restart kamailio, i receive this error:
ERROR: [modparam.c:141]: set_mod_param_regex(): parameter
of type <2> not found in module
Hi
Looks like that parameter is now¹ called dont_strip_or_prefix_flag
but module documentation was just not updated.
[1] Change was committed in 2010
https://github.com/kamailio/kamailio/commit/8c0501bfaa27acab9721953e8c1551687c96edf2
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
