- sr-users - kamailio.org

Siremis Multi domain
by Annus Fictus 20 Jan '17

20 Jan '17

Hi, I think Siremis not work correctly in a multi domain scenario if the extension number are the same for two domains. I explain a little more. I have two extension: 1 200(a)sip1.domain.org 2 200(a)sip2.domain.org On the Siremis I create the user 200 with the SIPuser role. When I login with this user, and go to subscriber data i can see bots extensions. I think is relate to this select on kamailio database: .....SELECT T0.id, T0.username, T0.domain, T0.password, T0.email_address, T0.ha1, T0.ha1b, T0.rpid FROM `subscriber` T0 WHERE T0.username='200' LIMIT 10 Any hint? Regards

2 7

UAC authentication
by anfecora 20 Jan '17

20 Jan '17

can someone please guide me where to find the usage of auc module, thanks in advance. I am registering the uac in one end then i want to forward that registration to an external registrar, if i use $du some domain, some of the ipv6 info is going to be forwarded, i need to make it look more like an a b2bua than a outbound proxy therefore i need to use the auc module(also i need to cover all ipv6 info since i am proxying from ipv4 to ipv6). i am able to register the client to kamailio, then kamailio send the registration to the external registrar, but when the registrar sends back the challenge uac does not reply, any ideas how can achieve this. uac(linphone etc) --registration--->kamailio(registrar module)------register(uac)--->SBC sbc----invite---->kamailio(lookup)---------invite---->uac(linphone etc) this is the code i am using. # Handle SIP registrations route[REGISTRAR] { xlog("REGISTERING "); if (is_method("REGISTER")) { if(isflagset(FLT_NATS)) { setbflag(FLB_NATB); # uncomment next line to do SIP NAT pinging ## setbflag(FLB_NATSIPPING); } if(af==INET6) setbflag(FLB_IPV6); xlog("IT IS IPV6"); if (!save("location")) sl_reply_error(); route(REGSBCFWD); exit; } } route[REGSBCFWD]{ xlog("CREATING OTHER LEG TO THE SBC"); if(!is_method("REGISTER")) { return; } xlog("CREATING PACKAGE $si -- $fU-- $au--$du-- $tU --$ru"); $var(rip) = "sip.somedomain.com"; $uac_req(method)="REGISTER"; $uac_req(ruri)="sip:" + $var(rip) + ":" + "5060"; $uac_req(furi)="sip:" + $tU + "@" + $var(rip); $uac_req(turi)="sip:" + $tU + "@" + $var(rip); $uac_req(hdrs)="Contact: <sip:" + $tU + "@" + "10.0.0.222" + ":" "5060" + ">\r\n"; if($sel(contact.expires) != $null) $uac_req(hdrs)= $uac_req(hdrs) + "Expires: " + $sel(contact.expires) + "\r\n"; else $uac_req(hdrs)= $uac_req(hdrs) + "Expires: " + $hdr(Expires) + "\r\n"; uac_req_send(); } REGISTER sip:sip.somedomain.com:5060 SIP/2.0. Via: SIP/2.0/UDP 10.0.0.222:5060 ;branch=z9hG4bK285f.13a7f0c0000000000000000000000000.0. To: <sip:14052423@sip.somedomain.com>. From: <sip:14052423@sip.somedomain.com >;tag=a82eaf71666096790d1397845fbd3254-ebaa. CSeq: 10 REGISTER. Call-ID: 357e21ae51d8416d-26605(a)10.0.0.222. Max-Forwards: 70. Content-Length: 0. User-Agent: kamailio (4.4.4 (x86_64/linux)). Contact: <sip:140524@10.0.0.222:5060>. Expires: 3600. . SIP/2.0 401 Unauthorized. Via: SIP/2.0/UDP 10.0.0.222:5060 ;branch=z9hG4bK4b53.ad842757000000000000000000000000.0. To: <sip:14052423@sip.somedomain.com>. From: <sip:14052423@sip.somedomain.com >;tag=a82eaf71666096790d1397845fbd3254-37da. Call-ID: 357e21ae51d8416d-26603(a)10.0.0.222. CSeq: 10 REGISTER. WWW-Authenticate: Digest realm="sip.somedomain.com", nonce="f5831435-3e69-4b78-ab6d-dcb0897e477b", algorithm=MD5, qop="auth". User-Agent: somedomain.com Host:some proxy. Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE. Content-Length: 0. .

2 3

Return body/string from Perl library
by David Cunningham 20 Jan '17

20 Jan '17

Hello, We are using Kamailio's perl module and want our custom library to set the body on a SIP message. Is it possible to set a SIP message body from within Perl, or can we return a string to the Kamailio configuration to then use with set_body()? Thanks for any advice. -- David Cunningham, Voisonics http://voisonics.com/ USA: +1 213 221 1092 Australia: +61 (0) 2 8063 9019

2 3

Re: [SR-Users] Kamailio not processing SIP TCP
by JR Richardson 19 Jan '17

19 Jan '17

root@homer02:~# netstat -altp Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 homer02.xxxxx.xxx:sip *:* LISTEN 16018/kamailio tcp 0 0 homer02.xxxxx.xxx:5066 *:* LISTEN 16018/kamailio Thanks. JR > If you use netstat, what is in the recv queue for tcp packets on sip ports? > > netstat -altp > > Cheers, > Daniel > > > On 18/01/2017 16:43, JR Richardson wrote: >> Yes, this is a sipcapture node. I'm listening on a switch port that is >> set to mirror my VoIP traffic. I see all SIP UDP/TCP packets on the >> mirror port and the Ethernet port of the host node. Just don't see any >> TCP packets process in kamailio, debug 3. UDP packets are processed as >> expected. >> >> My config is using port mirror for the capture parameters: >> >> modparam("sipcapture", "capture_on", 1) >> modparam("sipcapture", "hep_capture_on", 0) >> modparam("sipcapture", "raw_ipip_capture_on", 0) >> modparam("sipcapture", "raw_moni_capture_on", 1) >> >> modparam("sipcapture", "raw_sock_children", 4) >> modparam("sipcapture", "raw_interface", "eth1") >> modparam("sipcapture", "raw_socket_listen", "10.99.99.99:5060-5070") >> modparam("sipcapture", "promiscious_on", 1) >> modparam("sipcapture", "raw_moni_bpf_on", 1) >> >> Is there a method I could diagnose if the SIP TCP Packets are getting >> from the kernel network process and the kamailio process? >> >> # ngrep -d eth1 -W byline host x.x.x.x | /var/run/kamailio/kamailio.pid >> >> Or pipe to kamailio local unix socket? >> >> I don't know, I'm just guessing. >> >> Thanks. >> >> JR >> >> >>> Somehow is not clear for me how you have the configuration there ... >>> before commenting further, this needs to be clarified. >>> >>> The node you presented the config is a sipcapture instance, right? What >>> is sending traffic to it? Is another kamailio with siptrace module? Or >>> the sipcature agent? Or you have a port mirroring in the router? >>> >>> Cheers, >>> Daniel >>> >>> >>> On 17/01/2017 16:37, JR Richardson wrote: >>>>> 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. >>>>> >>>> Interesting. Are you referring to handshaking on the network stack or >>>> SIP TCP TLS handshaking? I guess I can see it two ways. >>>> >>>> 1) if your talking about TCP/IP handshake, even though the SIP packet >>>> comes into the mirror port on the host node, the kernel processing the >>>> TCP packet is not establishing a valid connection due to no TCP >>>> handshake because its only a monitor port, no transmit back, then the >>>> kernel network stack does not pass the SIP TCP packet to the kamailio >>>> process for capture because it drops the packet due to no valid >>>> handshake? >>>> >>>> 2) the kernel network stack is passing the SIP TCP packet to the >>>> kamailio process, but since kamailio cannot handshake back it drops >>>> the packet and does not process through the sipcapture module. This >>>> kinda breaks the whole capture ability for homer with SIP TCP. Using >>>> ngrep, I see all SIP TCP packets, invite -->, trying <--, session >>>> progress <--, request timeout <--, ack -->, etc... >>>> >>>> So how would I diagnose if the network stack is the culprit? Debugging >>>> kamailio is pretty straight forward, setup and listening for SIP TCP, >>>> but never see any processing of any TCP packets. >>>> >>>> Thanks. >>>> >>>> JR >

2 1

Phone number formats per country
by Daniel-Constantin Mierla 19 Jan '17

19 Jan '17

Hello, slightly off-topic, but related to voip -- does anyone have a link that can quickly share to a site with up to date details about phone numbering plans for as many country as possible? Ideally to include the toll and premium number prefixes, the split between mobile and fixed lines if it is the case. Cheers, Daniel -- Daniel-Constantin Mierla www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com

4 6

ds_is_from_list and NAPTR / SRV
by Björn Bylander 19 Jan '17

19 Jan '17

Hello, I’m trying to resolve an issue with the ds_is_from_list function from the dispatcher module. I’m calling it as follows: ds_is_from_list(”42”, "3", "sip:sip.foo.bar”) This makes Kamailio log an error: ERROR: dispatcher [dispatch.c:2327]: ds_is_addr_from_list(): could not resolve sip.foo.bar sip.foo.bar doesn’t have any A records but there are NAPTR and SRV records: $ host -t naptr sip.foo.bar sip.foo.bar has NAPTR record 20 0 "s" "SIP+D2T" "" _sip._tcp.sip.foo.bar. sip.foo.bar has NAPTR record 10 0 "s" "SIP+D2U" "" _sip._udp.sip.foo.bar. $ host -t srv _sip._tcp.sip.foo.bar _sip._tcp.sip.foo.bar has SRV record 10 0 5060 sip1.foo.bar. _sip._tcp.sip.foo.bar has SRV record 10 0 5060 sip2.foo.bar. $ host -t srv _sip._udp.sip.foo.bar _sip._udp.sip.foo.bar has SRV record 10 0 5060 sip2.foo.bar. _sip._udp.sip.foo.bar has SRV record 10 0 5060 sip1.foo.bar. $ host sip1.foo.bar. sip1.foo.bar has address 10.47.11.1 $ host sip2.foo.bar. sip2.foo.bar has address 10.47.11.2 The following DNS options are set: dns_srv_lb = yes dns_try_naptr = yes dns_naptr_ignore_rfc = no The Kamailio version is 4.2.8 (installed from the Debian binary package) on Debian Wheezy. Shouldn’t ds_is_from_list be able to resolve the NAPTR and SRV records? Can I change anything to be able to use ds_is_from_list with the specified domain? Thanks, Björn Bylander

2 1

Upgrade from 4.3 to 4.4
by Laura 18 Jan '17

18 Jan '17

Dear list, I'm planning the upgrade fromn 4.3.6 tree to 4.4.x version on Debian distribution. Can i run the apt-get update and upgrade without problem.. or is possible that i will found some error during upgrade ? Is the db schema upgraded or not from 4.3 up to 4.4 ? Regards Laura

2 1

Please explain : t_relay() vs t_relay_to_udp()
by Abdoul Osséni 18 Jan '17

18 Jan '17

hello all, I want to use kamailio like as a proxy SIP (outbound proxy) to transcode tls to udp like us: call flow is: Softphone --> tls --> Kamailio server (kamailio listen on 443 port) --> udp --> Asterisk server (asterisk listen on 5060 port) I know Kamailio can convert tls to udp. According tm documentation http://kamailio.org/docs/modules/devel/modules/tm.html, I think I must use t_relay_to_udp(). Do you confirm I must replace t_relay() function by t_relay_to_udp() function? Thank for your help. Regards Abdoul.

2 2

Re: [SR-Users] Kamailio not processing SIP TCP
by JR Richardson 18 Jan '17

18 Jan '17

Yes, this is a sipcapture node. I'm listening on a switch port that is set to mirror my VoIP traffic. I see all SIP UDP/TCP packets on the mirror port and the Ethernet port of the host node. Just don't see any TCP packets process in kamailio, debug 3. UDP packets are processed as expected. My config is using port mirror for the capture parameters: modparam("sipcapture", "capture_on", 1) modparam("sipcapture", "hep_capture_on", 0) modparam("sipcapture", "raw_ipip_capture_on", 0) modparam("sipcapture", "raw_moni_capture_on", 1) modparam("sipcapture", "raw_sock_children", 4) modparam("sipcapture", "raw_interface", "eth1") modparam("sipcapture", "raw_socket_listen", "10.99.99.99:5060-5070") modparam("sipcapture", "promiscious_on", 1) modparam("sipcapture", "raw_moni_bpf_on", 1) Is there a method I could diagnose if the SIP TCP Packets are getting from the kernel network process and the kamailio process? # ngrep -d eth1 -W byline host x.x.x.x | /var/run/kamailio/kamailio.pid Or pipe to kamailio local unix socket? I don't know, I'm just guessing. Thanks. JR > Somehow is not clear for me how you have the configuration there ... > before commenting further, this needs to be clarified. > > The node you presented the config is a sipcapture instance, right? What > is sending traffic to it? Is another kamailio with siptrace module? Or > the sipcature agent? Or you have a port mirroring in the router? > > Cheers, > Daniel > > > On 17/01/2017 16:37, JR Richardson wrote: >>> 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. >>> >> Interesting. Are you referring to handshaking on the network stack or >> SIP TCP TLS handshaking? I guess I can see it two ways. >> >> 1) if your talking about TCP/IP handshake, even though the SIP packet >> comes into the mirror port on the host node, the kernel processing the >> TCP packet is not establishing a valid connection due to no TCP >> handshake because its only a monitor port, no transmit back, then the >> kernel network stack does not pass the SIP TCP packet to the kamailio >> process for capture because it drops the packet due to no valid >> handshake? >> >> 2) the kernel network stack is passing the SIP TCP packet to the >> kamailio process, but since kamailio cannot handshake back it drops >> the packet and does not process through the sipcapture module. This >> kinda breaks the whole capture ability for homer with SIP TCP. Using >> ngrep, I see all SIP TCP packets, invite -->, trying <--, session >> progress <--, request timeout <--, ack -->, etc... >> >> So how would I diagnose if the network stack is the culprit? Debugging >> kamailio is pretty straight forward, setup and listening for SIP TCP, >> but never see any processing of any TCP packets. >> >> Thanks. >> >> JR > -- JR Richardson Engineering for the Masses Chasing the Azeotrope

2 1

Kamailio v4.4.5 Released
by Daniel-Constantin Mierla 18 Jan '17

18 Jan '17

Hello, Kamailio SIP Server v4.4.5 stable release is out. This is a maintenance release of the latest stable branch, 4.4, that includes fixes since the release of v4.4.4. There is no change to database schema or configuration language structure that you have to do on previous installations of v4.4.x. Deployments running previous v4.x.x versions are strongly recommended to be upgraded to v4.4.5. For more details about version 4.4.5 (including links and guidelines to download the tarball or from GIT repository), visit: * https://www.kamailio.org/w/2017/01/kamailio-v4-4-5-released/ RPM, Debian/Ubuntu packages will be available soon as well. Many thanks to all contributing and using Kamailio! Cheers, Daniel -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

1 0

Planning the release of v4.4.5
by Daniel-Constantin Mierla 18 Jan '17

18 Jan '17

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

1 1

Record-Route Header Question
by Andres 17 Jan '17

17 Jan '17

Hi, I am troubleshooting some strange call setup problems using an Edgewater Networks SBC. A couple of Polycom phones sit behind the SBC and they connect to a SIP Server in the cloud. The SBC is in passthrough mode. What I see that I am not sure about is: INVITE from SIP Server to SBC IP (no Record-Route header...so far no surprise here) INVITE from SBC to Phone (Record-Route header inserted by SBC but with the IP of the SIP Server) I do not think the SBC is supposed to add a Record-Route header with the IP of the remote SIP Server. I think It should only be allowed to add Record-Route headers with its own IP. Does that sound right? The RFC lists the usage as: "20.30 Record-Route The Record-Route header field is inserted by proxies in a request to force future requests in the dialog to be routed through the proxy." It says nothing about being able to arbitrarily force future requests to go through a remote IP. Please advise. Thanks, -- Technical Support

2 2

Re: [SR-Users] Kamailio not processing SIP TCP
by JR Richardson 17 Jan '17

17 Jan '17

> 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. > Interesting. Are you referring to handshaking on the network stack or SIP TCP TLS handshaking? I guess I can see it two ways. 1) if your talking about TCP/IP handshake, even though the SIP packet comes into the mirror port on the host node, the kernel processing the TCP packet is not establishing a valid connection due to no TCP handshake because its only a monitor port, no transmit back, then the kernel network stack does not pass the SIP TCP packet to the kamailio process for capture because it drops the packet due to no valid handshake? 2) the kernel network stack is passing the SIP TCP packet to the kamailio process, but since kamailio cannot handshake back it drops the packet and does not process through the sipcapture module. This kinda breaks the whole capture ability for homer with SIP TCP. Using ngrep, I see all SIP TCP packets, invite -->, trying <--, session progress <--, request timeout <--, ack -->, etc... So how would I diagnose if the network stack is the culprit? Debugging kamailio is pretty straight forward, setup and listening for SIP TCP, but never see any processing of any TCP packets. Thanks. JR -- JR Richardson Engineering for the Masses Chasing the Azeotrope

2 1

Using the auth_ephemeral module
by Hemanshu Vadehra 17 Jan '17

17 Jan '17

I'm involved in setting up a Kamailio instance and was hoping to make use of the auth_ephemeral module for authentication. But the module documentation doesn't quite make clear how exactly the module is to be employed or the web service set up. Does anyone have a working example? Regards, Hemanshu Vadehra hemanshu.v(a)directi.com

5 8

usrloc module with dbmode=2 does not insert records to database
by Vik Killa 17 Jan '17

17 Jan '17

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

2 11

Info: github template for reporting issues
by Daniel-Constantin Mierla 17 Jan '17

17 Jan '17

Hello, yesterday I added a template for opening new issues on github.com bug tracker. You can see it in action at: - https://github.com/kamailio/kamailio/issues/new Its bare text can be seen at: - https://raw.githubusercontent.com/kamailio/kamailio/master/.github/ISSUE_TE… More about the issue templates for github can be found at: - https://help.github.com/articles/creating-an-issue-template-for-your-reposi… Beside informing about this addition, I would like to get also feedback about it. Do you find it useful or you think it's going to be a hassle? If it should be kept, is anything that you think it should be added or removed? Cheers, Daniel -- Daniel-Constantin Mierla www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com

1 0

LCR module dont_strip_or_tag_flag
by Annus Fictus 17 Jan '17

17 Jan '17

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: <core> [modparam.c:141]: set_mod_param_regex(): parameter <dont_strip_or_tag_flag> of type <2> not found in module <lcr> I'm using 4.4.4 version Any hint? Thank you Regards

3 3

Re: [SR-Users] Kamailio not processing SIP TCP
by JR Richardson 16 Jan '17

16 Jan '17

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 >>> tcp 0 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. >>>

2 1

Remove/Append headers in 200 canceling and 200 ok to BYE
by Diego Nadares 16 Jan '17

16 Jan '17

Hi List, I'm trying to add and remove some headers in 200 canceling and 200 ok to BYEs with no success. I don't know in which route to add my remove_hf and append_hf. It seems that I can't catch it on reply either on request route. I tried adding it in event_route[tm:local-response] { xlog("L_ERR", "TM LOCAL REPONSE!"); route(MANAGE_HEADERS); } This is my route to manage hdrs: route[MANAGE_HEADERS]{ xlog("L_ERR", "MANAGE HDRS !"); keep_hf("TH"); # for topoh append("AHDR1:asdf\r\n"); return; } I suppose SERVER HDR should be removed but: U 2017/01/12 12:45:41.566733 172.16.213.38:5060 -> 172.16.50.41:5060 SIP/2.0 200 canceling. Via: SIP/2.0/UDP 172.16.50.41:5060;branch=z9hG4bKgg8ekd3080braugkm700.1. CSeq: 102 CANCEL. From: <sip:xx@172.16.50.41>;tag=SD7b10b01-as5ba5e269. To: <sip:xxx@172.16.213.38>;tag=4a86e96addfb27a943bc86e1872032b6-0a8b. Call-ID: SD7b10b01-6a7d1089793bda79481f25cf88c023ed-c540dl1. Server: kamailio (4.4.4 (x86_64/linux)). Content-Length: 0. Any help will be very appreciated. Thanks in advance! Diego

3 9

Re: [SR-Users] Kamailio not processing SIP TCP
by JR Richardson 16 Jan '17

16 Jan '17

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 > tcp 0 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(a)lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

3 2

Kamailio segfault on TM module
by José Seabra 16 Jan '17

16 Jan '17

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 00007f5cb97af1ea sp 00007ffed96b8d60 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: <core> [main.c:739]: handle_sigs(): child process 2048 exited by a signal 11 CRITICAL: <core> [pass_fd.c:275]: receive_fd(): EOF on 14 ALERT: <core> [main.c:742]: handle_sigs(): core was not generated INFO: <core> [main.c:754]: handle_sigs(): terminating due to SIGCHLD INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [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

2 1

dbtext module issue
by Satish Patel 16 Jan '17

16 Jan '17

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" ".* "

2 2

comma as param.count delimiter produces parse error
by Juha Heinanen 15 Jan '17

15 Jan '17

Parameter list transformation param.count produces parse error when delimiter is comma (,) character. >From document: {param.value,name[, delimiter]} 'delimiter' allows you to specify a single character to use as the parameter delimiter. For example, when parsing HTTP URL query strings use '&'. When I have in config statement: $var(count) = $(var(servers){param.count,,}); I get to syslog: Jan 13 07:48:15 lohi sip-proxy[18000]: 0(18050) ERROR: pv [pv_trans.c:2645]: tr_parse_paramlist(): invalid separator in transformation: count,,} Jan 13 07:48:15 lohi sip-proxy[18000]: 0(18050) ERROR: <core> [core/pvapi.c:1629]: tr_lookup(): error parsing [{param.count,,}] Jan 13 07:48:15 lohi sip-proxy[18000]: 0(18050) ERROR: <core> [core/pvapi.c:1010]: pv_parse_spec2(): bad tr in pvar name "var" Jan 13 07:48:15 lohi sip-proxy[18000]: 0(18050) ERROR: <core> [core/pvapi.c:1036]: pv_parse_spec2(): invalid parsing in [$(var(servers){param.count,,})] at (4) Jan 13 07:48:15 lohi sip-proxy[18000]: 0(18050) : <core> [core/cfg.y:3407]: yyerror_at(): parse error in config file /etc/sip-proxy/sip-proxy.cfg, line 6426, column 19-48: Can't get from cache: $(var(servers){param.count,,}) Jan 13 07:48:15 lohi sip-proxy[18000]: ERROR: bad config file (1 errors) -- Juha

2 2

Kamailio not processing SIP TCP
by JR Richardson 12 Jan '17

12 Jan '17

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 tcp 0 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

2 1

C++ module
by Patrick 12 Jan '17

12 Jan '17

I added a C++ module to kamalio at some point, and now I am trying to integrate that module with another C++ internal library, but I'm getting all sorts of headaches when trying to compile. The latest problem is during the "make install" part of the build - it seems like the objects from the module are "infecting" the link line of the internal library it's dependent on. Here is the Makefile for the module. At the time, the only way I figured to link in the C++ object was adding them to the LIBS. Now, i think this interferes with the 'make install' dependencies. Any thoughs on how to do this properly would be great! Thanks *Module Makefile* # # db_cassandra module makefile # # # WARNING: do not run this directly, it should be run by the master Makefile include ../../Makefile.defs CXX=g++ LD=g++ auto_gen= NAME=db_arl.so ifeq ($(CROSS_COMPILE),) CURL_BUILDER=$(shell \ if pkg-config --exists libcurl; then \ echo 'pkg-config libcurl'; \ else \ which curl-config; \ fi) endif DEFS+=-DKAMAILIO_MOD_INTERFACE -DRTC_COMMON_TRACE *LIBS += db_arl_base.o jsoncpp.o* -lcurl -pthread CXXFLAGS=$(CFLAGS:-Wno-deprecated option=) CXXFLAGS+= -Wno-write-strings -Wno-deprecated -Wno-unused-function -Wno-sign-compare -Wno-strict-aliasing CXXFLAGS+= -I ${COL_LOCAL_BUILDS_ROOT}/ExternalLibs/boost/V1.60.0_27/ CXXFLAGS+= -I ./jsoncpp-dist/ SERLIBPATH=../../lib SER_LIBS+=$(SERLIBPATH)/srdb2/srdb2 SER_LIBS+=$(SERLIBPATH)/srdb1/srdb1 *SER_LIBS+=$(SERLIBPATH)/rtctrace/rtctrace* include ../../Makefile.modules jsoncpp.o: jsoncpp-dist/jsoncpp.cpp @echo COL_LOCAL_BUILDS_ROOT=${COL_LOCAL_BUILDS_ROOT} @echo "Compiling $<" $(CXX) $(CXXFLAGS) $(CFLAGS) $(C_DEFS) $(DEFS) -c $< -o $@ db_arl_base.o: db_arl_base.cpp db_arl_base.h @echo COL_LOCAL_BUILDS_ROOT=${COL_LOCAL_BUILDS_ROOT} @echo "Compiling $<" $(CXX) $(CXXFLAGS) $(CFLAGS) $(C_DEFS) $(DEFS) -c $< -o $@ db_arl.so: db_arl_base.o jsoncpp.o During 'make install' the objects in *red* have no business in the link line for the internal library /opt/rh/devtoolset-4/root/usr/bin/g++ -fPIC -DPIC -g -funroll-loops -Wcast-align -m64 -minline-all-stringops -falign-loops -ftree-vectorize -fno-strict-overflow -mtune=opteron -Wall -I/home/pshea/_localbuilds/RTC/Common/2.0.0_247//Applications_rhel6_x64_dts4_pic/include -DNAME='"kamailio"' -DVERSION='"4.2.4"' -DARCH='"x86_64"' -DOS='linux_' -DOS_QUOTED='"linux"' -DCOMPILER='"gcc 4.4.7"' -D__CPU_x86_64 -D__OS_linux -DSER_VER=4002004 -DCFG_DIR='"/usr/local/etc/kamailio/"' -DPKG_MALLOC -DSHM_MEM -DSHM_MMAP -DDNS_IP_HACK -DUSE_MCAST -DUSE_TCP -DDISABLE_NAGLE -DHAVE_RESOLV_RES -DUSE_DNS_CACHE -DUSE_DNS_FAILOVER -DUSE_DST_BLACKLIST -DUSE_NAPTR -DWITH_XAVP -DF_MALLOC -DDBG_F_MALLOC -DMEM_JOIN_FREE -DUSE_TLS -DTLS_HOOKS -DUSE_CORE_STATS -DSTATISTICS -DMALLOC_STATS -DWITH_AS_SUPPORT -DFAST_LOCK -DADAPTIVE_WAIT -DADAPTIVE_WAIT_LOOPS=1024 -DCC_GCC_LIKE_ASM -DHAVE_GETHOSTBYNAME2 -DHAVE_UNION_SEMUN -DHAVE_SCHED_YIELD -DHAVE_MSG_NOSIGNAL -DHAVE_MSGHDR_MSG_CONTROL -DHAVE_ALLOCA_H -DHAVE_TIMEGM -DHAVE_SCHED_SETSCHEDULER -DUSE_RAW_SOCKS -DHAVE_EPOLL -DHAVE_SIGIO_RT -DSIGINFO64_WORKARROUND -DUSE_FUTEX -DHAVE_SELECT -std=c++0x -I/home/pshea/_localbuilds/RTC/Common/2.0.0_247//Applications_rhel6_x64_dts4_pic/include -c rtctrace.c -o rtctrace.o -MMD -MP /opt/rh/devtoolset-4/root/usr/bin/g++ -shared -m64 -Wl,-O2 -Wl,-E -Wl,-soname,librtctrace.so.1 rtctrace.o * db_arl_base.o jsoncpp.o* -lcurl -pthread -L/home/pshea/_localbuilds/RTC/Common/2.0.0_247//Applications_rhel6_x64_dts4_pic/lib -lrtccommon -L/home/pshea/_localbuilds/ExternalLibs/boost/V1.60.0_22/Server_Linux26_x64_dts4_pic/lib -lboost_system -lboost_thread -lpthread -o librtctrace.so.1.0 *g++: error: db_arl_base.o: No such file or directory* *g++: error: jsoncpp.o: No such file or directory*

2 7

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users