sr-users

sr-users@lists.kamailio.org

37 participants
37511 discussions

Integration of Google Speech API V2
by Rahul MathuR 19 Jul '17

19 Jul '17

Hi, I'm trying to integrate Google cloud speech recognition v2 in it. I can get the audio recorded, have created Service key and API key but whenever I try to access it, I just get 403 access denied. I am at my wits end here. Has anybody tried it ? were you successful ? Could you please guide me how to do it ? I'll be grateful to you if this works ! -- Warm Regds. MathuRahul

2 1

Problem with IPv4-IPv6 media bridging using RTPengine
by Ismir Saljic 19 Jul '17

19 Jul '17

Hello, I've issue with bridging media between IPv4 and IPv6 clients. IPv4-IPv4 and IPv6-IPv6 calls are working without issues. I'm using kamailio 4.4.2 and configuration according to: http://kb.asipto.com/kamailio:kamailio-mixed-ipv4-ipv6 SIP signalling is working without issues,but media addresses in SDP are not rewritten correctly. The server is on amazon AWS and both kamailio and RTPengine are on the same server. RTPengine is running using these options: /usr/sbin/rtpengine --interface=privateIPv4!publicIPv4 --interface=GlobalIPv6 --listen-udp=127.0.0.1:22222 --tos=184 --pidfile=/var/run/rtpengine.pid --log-level=6 --log-facility=daemon In case of IPv4-IPv6 call, INVITE message contains correct IPv4 address but 200 OK response to the caller still contains IPv6 address of the callee in SDP body instead of IPv4 address of the server/RTPengine. This is the log during generation of the 200 OK response. Seems that RTPengine failed to parse IPv4 address from SDP body. Jul 19 08:02:42 /usr/local/sbin/kamailio[1691]: DEBUG: <core> [parser/msg_parser.c:618]: parse_msg(): SIP Reply (status): Jul 19 08:02:42 /usr/local/sbin/kamailio[1691]: DEBUG: <core> [parser/msg_parser.c:620]: parse_msg(): version: <SIP/2.0> Jul 19 08:02:42 /usr/local/sbin/kamailio[1691]: DEBUG: <core> [parser/msg_parser.c:622]: parse_msg(): status: <200> Jul 19 08:02:42 /usr/local/sbin/kamailio[1691]: DEBUG: <core> [parser/msg_parser.c:624]: parse_msg(): reason: <OK> Jul 19 08:02:42 /usr/local/sbin/kamailio[1691]: DEBUG: <core> [parser/parse_via.c:1254]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK5afe.c59aef39af345458e17940722ba0c70b.0>; state=6 Jul 19 08:02:42 /usr/local/sbin/kamailio[1691]: DEBUG: <core> [parser/parse_via.c:1254]: parse_via_param(): Found param type 234, <received> = <Server's GlobalIPv6>; state=6 Jul 19 08:02:42 /usr/local/sbin/kamailio[1691]: DEBUG: <core> [parser/parse_via.c:1254]: parse_via_param(): Found param type 236, <i> = <8>; state=16 Jul 19 08:02:42 /usr/local/sbin/kamailio[1691]: DEBUG: <core> [parser/parse_via.c:2642]: parse_via(): end of header reached, state=5 Jul 19 08:02:42 /usr/local/sbin/kamailio[1691]: DEBUG: <core> [parser/msg_parser.c:496]: parse_headers(): parse_headers: Via found, flags=2 Jul 19 08:02:42 /usr/local/sbin/kamailio[1691]: DEBUG: <core> [parser/msg_parser.c:498]: parse_headers(): parse_headers: this is the first via Jul 19 08:02:42 /usr/local/sbin/kamailio[1691]: DEBUG: <core> [receive.c:178]: receive_msg(): After parse_msg... Jul 19 08:02:42 /usr/local/sbin/kamailio[1691]: DEBUG: tm [t_lookup.c:1011]: t_check_msg(): DEBUG: t_check_msg: msg id=143 global id=142 T start=0xffffffffffffffff Jul 19 08:02:42 /usr/local/sbin/kamailio[1691]: DEBUG: <core> [parser/parse_via.c:1254]: parse_via_param(): Found param type 234, <received> = <178.165.130.177>; state=6 Jul 19 08:02:42 /usr/local/sbin/kamailio[1691]: DEBUG: <core> [parser/parse_via.c:1254]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK.BUIgttWpK>; state=6 Jul 19 08:02:42 /usr/local/sbin/kamailio[1691]: DEBUG: <core> [parser/parse_via.c:1254]: parse_via_param(): Found param type 235, <rport> = <2066>; state=16 Jul 19 08:02:42 /usr/local/sbin/kamailio[1691]: DEBUG: <core> [parser/parse_via.c:2642]: parse_via(): end of header reached, state=5 Jul 19 08:02:42 /usr/local/sbin/kamailio[1691]: DEBUG: <core> [parser/msg_parser.c:496]: parse_headers(): parse_headers: Via found, flags=62 Jul 19 08:02:42 /usr/local/sbin/kamailio[1691]: DEBUG: <core> [parser/msg_parser.c:509]: parse_headers(): parse_headers: this is the second via Jul 19 08:02:42 /usr/local/sbin/kamailio[1691]: DEBUG: <core> [parser/parse_addr_spec.c:172]: parse_to_param(): DEBUG: add_param: tag=2996330c Jul 19 08:02:42 /usr/local/sbin/kamailio[1691]: DEBUG: <core> [parser/parse_addr_spec.c:894]: parse_addr_spec(): end of header reached, state=29 Jul 19 08:02:42 /usr/local/sbin/kamailio[1691]: DEBUG: <core> [parser/msg_parser.c:173]: get_hdr_field(): DEBUG: get_hdr_field: <To> [59]; uri=[sip:user@domain.com] Jul 19 08:02:42 /usr/local/sbin/kamailio[1691]: DEBUG: <core> [parser/msg_parser.c:175]: get_hdr_field(): DEBUG: to body ["user"< sip:user@domain.com>] Jul 19 08:02:42 /usr/local/sbin/kamailio[1691]: DEBUG: <core> [parser/msg_parser.c:153]: get_hdr_field(): get_hdr_field: cseq <CSeq>: <21> <INVITE> Jul 19 08:02:42 /usr/local/sbin/kamailio[1691]: DEBUG: tm [t_lookup.c:888]: t_reply_matching(): DEBUG: t_reply_matching: hash 61349 label 0 branch 0 Jul 19 08:02:42 /usr/local/sbin/kamailio[1691]: DEBUG: tm [t_lookup.c:943]: t_reply_matching(): DEBUG: t_reply_matching: reply matched (T=0x7f7f95c19a10)! Jul 19 08:02:42 /usr/local/sbin/kamailio[1691]: DEBUG: tm [t_hooks.c:266]: run_trans_callbacks_internal(): DBG: trans=0x7f7f95c19a10, callback type 2, id 0 entered Jul 19 08:02:42 /usr/local/sbin/kamailio[1691]: DEBUG: acc [acc_logic.c:644]: tmcb_func(): acc callback called for t(0x7f7f95c19a10) event type 2, reply code 200 Jul 19 08:02:42 /usr/local/sbin/kamailio[1691]: DEBUG: tm [t_lookup.c:1080]: t_check_msg(): DEBUG: t_check_msg: msg id=143 global id=143 T end=0x7f7f95c19a10 Jul 19 08:02:42 /usr/local/sbin/kamailio[1691]: DEBUG: tm [t_reply.c:2160]: reply_received(): DEBUG: reply_received: org. status uas=180, uac[0]=180 local=0 is_invite=1) Jul 19 08:02:42 /usr/local/sbin/kamailio[1691]: DEBUG: <script>: incoming reply Jul 19 08:02:42 /usr/local/sbin/kamailio[1691]: DEBUG: <script>: BMX: FAIE Jul 19 08:02:42 /usr/local/sbin/kamailio[1691]: DEBUG: <core> [parser/msg_parser.c:187]: get_hdr_field(): DEBUG: get_hdr_body : content_length=559 Jul 19 08:02:42 /usr/local/sbin/kamailio[1691]: DEBUG: <core> [parser/msg_parser.c:89]: get_hdr_field(): found end of header Jul 19 08:02:42 /usr/local/sbin/kamailio[1691]: DEBUG: <core> [parser/sdp/sdp_helpr_funcs.c:504]: extract_mediaip(): located IP address [IPv6 of the callee] in `o=' field Jul 19 08:02:42 /usr/local/sbin/kamailio[1691]: DEBUG: <core> [parser/sdp/sdp_helpr_funcs.c:504]: extract_mediaip(): located IP address [IPv6 of the callee] in `c=' field Jul 19 08:02:42 /usr/local/sbin/kamailio[1691]: DEBUG: <core> [parser/sdp/sdp.c:574]: parse_sdp_session(): ignoring unknown type in a= line: `a=rtcp-fb:* nack#015#012a=rtcp-fb:* nack pli#015#012' Jul 19 08:02:42 /usr/local/sbin/kamailio[1691]: DEBUG: <core> [parser/sdp/sdp.c:574]: parse_sdp_session(): ignoring unknown type in a= line: `a=rtcp-fb:* nack pli#015#012' Jul 19 08:02:42 /usr/local/sbin/kamailio[1691]: DEBUG: rtpproxy [rtpproxy_funcs.c:148]: check_content_type(): type <application/sdp> found valid Jul 19 08:02:42 /usr/local/sbin/kamailio[1691]: DEBUG: <core> [parser/parse_addr_spec.c:172]: parse_to_param(): DEBUG: add_param: tag=aNfQNJz3e Jul 19 08:02:42 /usr/local/sbin/kamailio[1691]: DEBUG: <core> [parser/parse_addr_spec.c:894]: parse_addr_spec(): end of header reached, state=29 Jul 19 08:02:42 rtpengine[24330]: Got valid command from udp: 127.0.0.1:28152: 1691_12 LAEI6 dcMDMrNRhw IPv6 of the callee 58100 aNfQNJz3e;1 2996330c;1 Jul 19 08:02:42 rtpengine[24330]: [dcMDMrNRhw] Failed to parse a media stream: /IPv6 of the callee:58100 Jul 19 08:02:42 /usr/local/sbin/kamailio[1691]: DEBUG: rtpproxy [rtpproxy.c:2712]: force_rtp_proxy(): proxy reply: E8 Jul 19 08:02:42 /usr/local/sbin/kamailio[1691]: ERROR: rtpproxy [rtpproxy.c:2735]: force_rtp_proxy(): incorrect port 0 in reply from rtp proxy Jul 19 08:02:42 /usr/local/sbin/kamailio[1691]: DEBUG: tm [t_reply.c:1233]: t_should_relay_response(): ->>>>>>>>> T_code=180, new_code=200 Jul 19 08:02:42 /usr/local/sbin/kamailio[1691]: DEBUG: tm [t_reply.c:1751]: relay_reply(): DEBUG: relay_reply: branch=0, save=0, relay=0 icode=0 Jul 19 08:02:42 /usr/local/sbin/kamailio[1691]: DEBUG: <core> [msg_translator.c:2260]: generate_res_buf_from_sip_res(): old size: 1467, new size: 1319 Jul 19 08:02:42 /usr/local/sbin/kamailio[1691]: DEBUG: <core> [msg_translator.c:2278]: generate_res_buf_from_sip_res(): copied size: orig:164, new: 16, rest: 1303 msg=#012SIP/2.0 200 OK#015#012 Via: SIP/2.0/TCP 10.152.108.46:56401;received=X.X.X.X; branch=z9hG4bK.BUIgttWpK;rport=2066 Record-Route: <sip:[Server's IPv6];transport=tcp;r2=on;lr;nat=v46> Record-Route: <sip:X.X.X.X;transport=tcp;r2=on;lr;nat=v46> Contact: <sip:user@[IPv6 of the callee]:59335;rinstance= 836aa36a01097072;transport=tcp> To: "user"<sip:user@domain.com>;tag=2996330c From: "caller" <sip:caller@domain.com>;tag=aNfQNJz3e Call-ID: dcMDMrNRhw CSeq: 21 INVITE Allow: SUBSCRIBE, NOTIFY, INVITE, ACK, CANCEL, BYE, REFER, INFO, OPTIONS, MESSAGE Content-Type: application/sdp Supported: replaces User-Agent: Bria 5 release 5.0.0 stamp 85993 Content-Length: 559 v=0 o=- 241380314 3 IN IP6 IPv6 of the callee(should be IPv4 address of the server) s=Bria 5 release 5.0.0 stamp 85993 c=IN IP6 IPv6 of the callee (should be IPv4 address of the server) The same situation is in case of IPv6-IPv4 call. This is the part of the log in case of IPV6-IPv4 call when kamailio is creating INVITE to the IPv4 callee: Jul 19 08:04:52 /usr/local/sbin/kamailio[1691]: DEBUG: <script>: BMX: FAIE Jul 19 08:04:52 /usr/local/sbin/kamailio[1691]: DEBUG: <core> [parser/sdp/sdp_helpr_funcs.c:504]: extract_mediaip(): located IP address [IPv6 Address] in `o=' field Jul 19 08:04:52 /usr/local/sbin/kamailio[1691]: DEBUG: <core> [parser/sdp/sdp_helpr_funcs.c:504]: extract_mediaip(): located IP address [IPv6 Address] in `c=' field Jul 19 08:04:52 /usr/local/sbin/kamailio[1691]: DEBUG: rtpproxy [rtpproxy_funcs.c:148]: check_content_type(): type <application/sdp> found valid Jul 19 08:04:52 rtpengine[24330]: Got valid command from udp: 127.0.0.1:28152: 1691_13 UAEI6 85993YWVkNmQ4YTFmN2JkZWQ4NjIzMGYwMDBlM2RlOGY0ZDQ 2a03:f81:abcd:172:16:20:119:2 50168 1430094e;1 Jul 19 08:04:52 rtpengine[24330]: [85993YWVkNmQ4YTFmN2JkZWQ4NjIzMGYwMDBlM2RlOGY0ZDQ] Creating new call Jul 19 08:04:52 rtpengine[24330]: [85993YWVkNmQ4YTFmN2JkZWQ4NjIzMGYwMDBlM2RlOGY0ZDQ] Failed to parse a media stream: /IPv6:50168 Jul 19 08:04:52 /usr/local/sbin/kamailio[1691]: DEBUG: rtpproxy [rtpproxy.c:2712]: force_rtp_proxy(): proxy reply: E8 Jul 19 08:04:52 /usr/local/sbin/kamailio[1691]: ERROR: rtpproxy [rtpproxy.c:2735]: force_rtp_proxy(): incorrect port 0 in reply from rtp proxy Jul 19 08:04:52 /usr/local/sbin/kamailio[1691]: DEBUG: siputils [checks.c:97]: has_totag(): no totag Any help would be very appreciated! Thank you Kind regards

2 1

dns failover and branches
by Juha Heinanen 19 Jul '17

19 Jul '17

If Request-URI hostpart is a domain name with more than one SRV record, it appears that each SRV destination creates its own Kamailio branch. If branch route is set before t_relay(), it is executed only on the first SRV destination. If the first SRV destination fails, Kamailio tries automatically the second one, but any branch flags set in the branch route are lost. What is the simplest way to make Kamailio preserve the stuff set in the branch route for all SRV destinations? -- Juha

3 13

about rtpengine-[offer-answer] via-branch flag
by Juha Heinanen 18 Jul '17

18 Jul '17

rtpengine-offer function documentation tells this about via-branch flag: via-branch=... - Include the “branch” value of one of the “Via” headers in the request to the RTP proxy. Possible values are: “1” - use the first “Via” header; “2” - use the second “Via” header; “auto” - use the first “Via” header if this is a request, or the second one if this is a reply; “extra” - don't take the value from a header, but instead use the value of the “extra_id_pv” variable. This can be used to create one media session per branch on the RTP proxy. When sending a subsequent “delete” command to the RTP proxy, you can then stop just the session for a specific branch when passing the flag '1' or '2' in the “rtpengine_delete”, or stop all sessions for a call when not passing one of those two flags there. This is especially useful if you have serially forked call scenarios where the RTP proxy gets an “offer” command for a new branch, and then a “delete” command for the previous branch, which would otherwise delete the full call, breaking the subsequent “answer” for the new branch. Is the note about "serial forking" correct or should it be about "parallel forking" instead? In case of serial forking, it would not matter if the whole call is deleted, because a new offer would be issued for the next branch. Or perhaps I just don't understand the meaning of the note? -- Juha

2 2

Info: business directory
by Daniel-Constantin Mierla 18 Jul '17

18 Jul '17

Hello, for those new in the community as well as a reminder for the others: if you offer Kamailio-related services or products, you can get listed at: - https://www.kamailio.org/w/business-directory/ Besides that, also in the case if you just use Kamailio for RTC/VoIP services, you can add yourself in Used By directory: - https://www.kamailio.org/w/used-by/ The website has very good traffic and can increase your visibility in the market. Cheers, Daniel -- Daniel-Constantin Mierla www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - www.asipto.com Kamailio World Conference - www.kamailioworld.com

1 0

rtpengine: Failed to open UDP control connection port
by David Cunningham 17 Jul '17

17 Jul '17

Hello, We're using Kamailio 4.2.1 with rtpengine 5.1.2.1 on Ubuntu 16.04. When running rtpengine we get this error: [1500263405.711288] ERR: FAILED TO CREATE KERNEL TABLE 0 (File exists), KERNEL FORWARDING DISABLED [1500263405.712367] CRIT: Fatal error: Failed to open UDP control connection port The first line I think is not important, but the second appears to be. It's being run as root with these options: /usr/sbin/rtpengine --interface=xx.xx.xx.xx --listen-ng=7724 --timeout=60 --silent-timeout=3600 --pidfile=/var/run/rtpengine.pid --port-min=45000 --port-max=50000 --table=0 Running "netstat -lnp | grep 7724" does not report anything listening on port 7724 already. Has anyone any ideas? Thanks in advance. -- David Cunningham, Voisonics Limited http://voisonics.com/ USA: +1 213 221 1092 Australia: +61 (0) 2 8063 9019

3 4

Kamilio new user - help get going
by Kenneth Knudsen 17 Jul '17

17 Jul '17

Hi I have been watching numerous videos on youtube in search of how to configure Kamilio ! I know we I need the Sip Server, but don't know how to get it configured. The installation is obvious with the commands as a root user. Brief description of the project: Have quite a few customers we want to move from PSTN (AT&T primarily) to a Voip/Sip solution. So instead of setting up 1 FreePBX and 1 public ip, we would rather use 1 public IP to many FreePBX servers on the backend. I haven't been able to find one video on how to configure this SIP server, and was hoping somebody here might have some clues to lead me in the right direction. I found one company that would help us, but they said at least 20 hours just to configure the first customer/freePBX installation. If we could get help setting up the first we should be able to figure out the ones to come later. Any help would be appreciated... We know the product is awesome, we have the keys but don't know how to run the thing or even get it started !! Kind regards, Kenneth Knudsen

6 11

Clarification on redis_cmd in ndb_redis module
by vivek＠advaitamtech.com 17 Jul '17

17 Jul '17

Hi, Am using redis_cmd in kamailio.cfg to perform redis operations. I would like to know if redis_cmd() creates new connection everytime I call it in kamailio.cfg?. Since am using redis_cmd() multiple times to access few data's. Also, is calling redis_free() necessary to avoid connections being open? I am facing an error of number of open files exceeded. This error is caused by ndb_redis module. But cannot confirm due to which part of redis. Thanks, Vivek

2 1

Need help to send INVITE to multiple client based on REGISTRATION status
by amit Kumar 15 Jul '17

15 Jul '17

Hi All, Following are the requirement which we want to achieve through Kamailio. Our "voip client" will not be register in advance.When Kamailio get INIVITE request for particular "voip client"(multiple client), we send push notification to make "voip client"(multiple client) alive and get it register for to Kamailio. Meanwhile INIVITE request will wait. the moment, "voip client" get register, Kamailio will send INIVITE to all the client despite their *registration time/status*.for example - if first client get register with in T+1 second,that should also get INVITE and another client get register in T+2 second that should also get INVITE. Could you please help me if this is possible in Kamailio. I have done some code walk through and have the basic idea to save the INVITE transaction(similar to suspend and continue), later point of time when i get the register request, I will use functionality like t_lookup_request and and lookup(which in turn append_branch) and call the t_realy () again. Please let me know if this is correct approach or if there is some other way to solve this. Thanks, Amit

2 1

Database connection handles vs. processes
by Alex Balashov 13 Jul '17

13 Jul '17

Hi, By way of illustration, I have one server with children=8, a single UDP listener, and 23 processes total: -- 21117 attendant 21118 udp receiver child=0 sock=xxx.xxx.xxx.xxx:5060 21119 udp receiver child=1 sock=xxx.xxx.xxx.xxx:5060 21120 udp receiver child=2 sock=xxx.xxx.xxx.xxx:5060 21121 udp receiver child=3 sock=xxx.xxx.xxx.xxx:5060 21122 udp receiver child=4 sock=xxx.xxx.xxx.xxx:5060 21123 udp receiver child=5 sock=xxx.xxx.xxx.xxx:5060 21124 udp receiver child=6 sock=xxx.xxx.xxx.xxx:5060 21125 udp receiver child=7 sock=xxx.xxx.xxx.xxx:5060 21126 slow timer 21127 timer 21128 MI FIFO 21129 ctl handler 21130 RTIMER USEC EXEC 21131 RTIMER USEC EXEC 21132 RTIMER USEC EXEC 21133 RTIMER USEC EXEC 21134 RTIMER USEC EXEC 21135 RTIMER USEC EXEC 21136 RTIMER USEC EXEC 21137 Dialog KA Timer 21138 Dialog Clean Timer 21139 tcp main process # kamcmd -s /tmp/kamailio_ctl ps | wc -l 23 -- This appears to result in 23 total database connections to the Postgres server: -- # lsof -n | grep -i '^kam' | grep IPv4 | grep TCP | grep -i :postgres | wc -l 23 -- But I have another Kamailio server that has three listeners, two UDP and one TCP, and children=24, i.e. -- children=24 listen=udp:xxx.xxx.xxx.xxx:5060 listen=udp:yyy.yyy.yyy.yyy:5060 listen=tcp:zzz.zzz.zzz.zzz:5060 -- I am given to understand that the total number of worker processes there will be (children_setting * listeners), i.e. 72 in this case, plus some number of rtimer and supervisory processes, as in my case. And true enough: -- # kamcmd -s /tmp/kamailio_ctl ps | wc -l 86 # kamcmd -s /tmp/kamailio_ctl ps | sed 's/65.254.44.195/yyy.yyy.yyy.yyy/g' | sed 's/65.254.44.194/zzz.zzz.zzz.zzz/g' 22065 main process - attendant 22069 udp receiver child=0 sock=zzz.zzz.zzz.zzz:5060 22070 udp receiver child=1 sock=zzz.zzz.zzz.zzz:5060 22071 udp receiver child=2 sock=zzz.zzz.zzz.zzz:5060 22073 udp receiver child=3 sock=zzz.zzz.zzz.zzz:5060 22074 udp receiver child=4 sock=zzz.zzz.zzz.zzz:5060 22076 udp receiver child=5 sock=zzz.zzz.zzz.zzz:5060 22079 udp receiver child=6 sock=zzz.zzz.zzz.zzz:5060 22080 udp receiver child=7 sock=zzz.zzz.zzz.zzz:5060 22082 udp receiver child=8 sock=zzz.zzz.zzz.zzz:5060 22085 udp receiver child=9 sock=zzz.zzz.zzz.zzz:5060 22086 udp receiver child=10 sock=zzz.zzz.zzz.zzz:5060 22089 udp receiver child=11 sock=zzz.zzz.zzz.zzz:5060 22091 udp receiver child=12 sock=zzz.zzz.zzz.zzz:5060 22093 udp receiver child=13 sock=zzz.zzz.zzz.zzz:5060 22095 udp receiver child=14 sock=zzz.zzz.zzz.zzz:5060 22097 udp receiver child=15 sock=zzz.zzz.zzz.zzz:5060 22099 udp receiver child=16 sock=zzz.zzz.zzz.zzz:5060 22100 udp receiver child=17 sock=zzz.zzz.zzz.zzz:5060 22103 udp receiver child=18 sock=zzz.zzz.zzz.zzz:5060 22105 udp receiver child=19 sock=zzz.zzz.zzz.zzz:5060 22107 udp receiver child=20 sock=zzz.zzz.zzz.zzz:5060 22109 udp receiver child=21 sock=zzz.zzz.zzz.zzz:5060 22111 udp receiver child=22 sock=zzz.zzz.zzz.zzz:5060 22113 udp receiver child=23 sock=zzz.zzz.zzz.zzz:5060 22115 udp receiver child=0 sock=yyy.yyy.yyy.yyy:5060 22117 udp receiver child=1 sock=yyy.yyy.yyy.yyy:5060 22119 udp receiver child=2 sock=yyy.yyy.yyy.yyy:5060 22121 udp receiver child=3 sock=yyy.yyy.yyy.yyy:5060 22123 udp receiver child=4 sock=yyy.yyy.yyy.yyy:5060 22125 udp receiver child=5 sock=yyy.yyy.yyy.yyy:5060 22127 udp receiver child=6 sock=yyy.yyy.yyy.yyy:5060 22129 udp receiver child=7 sock=yyy.yyy.yyy.yyy:5060 22131 udp receiver child=8 sock=yyy.yyy.yyy.yyy:5060 22132 udp receiver child=9 sock=yyy.yyy.yyy.yyy:5060 22135 udp receiver child=10 sock=yyy.yyy.yyy.yyy:5060 22137 udp receiver child=11 sock=yyy.yyy.yyy.yyy:5060 22139 udp receiver child=12 sock=yyy.yyy.yyy.yyy:5060 22141 udp receiver child=13 sock=yyy.yyy.yyy.yyy:5060 22143 udp receiver child=14 sock=yyy.yyy.yyy.yyy:5060 22145 udp receiver child=15 sock=yyy.yyy.yyy.yyy:5060 22147 udp receiver child=16 sock=yyy.yyy.yyy.yyy:5060 22149 udp receiver child=17 sock=yyy.yyy.yyy.yyy:5060 22151 udp receiver child=18 sock=yyy.yyy.yyy.yyy:5060 22153 udp receiver child=19 sock=yyy.yyy.yyy.yyy:5060 22155 udp receiver child=20 sock=yyy.yyy.yyy.yyy:5060 22156 udp receiver child=21 sock=yyy.yyy.yyy.yyy:5060 22159 udp receiver child=22 sock=yyy.yyy.yyy.yyy:5060 22161 udp receiver child=23 sock=yyy.yyy.yyy.yyy:5060 22163 slow timer 22165 timer 22167 secondary timer 22168 ctl handler 22169 RTIMER USEC EXEC 22170 RTIMER USEC EXEC 22172 RTIMER USEC EXEC 22173 RTIMER USEC EXEC 22175 Dialog Clean Timer 22176 TIMER NH 22177 TIMER NH 22178 TIMER NH 22179 tcp receiver (generic) child=0 22180 tcp receiver (generic) child=1 22182 tcp receiver (generic) child=2 22184 tcp receiver (generic) child=3 22186 tcp receiver (generic) child=4 22188 tcp receiver (generic) child=5 22190 tcp receiver (generic) child=6 22192 tcp receiver (generic) child=7 22194 tcp receiver (generic) child=8 22196 tcp receiver (generic) child=9 22198 tcp receiver (generic) child=10 22200 tcp receiver (generic) child=11 22202 tcp receiver (generic) child=12 22204 tcp receiver (generic) child=13 22206 tcp receiver (generic) child=14 22208 tcp receiver (generic) child=15 22210 tcp receiver (generic) child=16 22212 tcp receiver (generic) child=17 22214 tcp receiver (generic) child=18 22216 tcp receiver (generic) child=19 22218 tcp receiver (generic) child=20 22220 tcp receiver (generic) child=21 22223 tcp receiver (generic) child=22 22225 tcp receiver (generic) child=23 22227 tcp main process -- But, for some reason, the number of database connections to Postgres seems to be considerably higher than the number of total processes: -- # lsof -n | grep '^kam' | grep TCP | grep IPv4 | grep ':postgres' | wc -l 114 -- This is not due to orphaned/unterminated Kamailio processes. There's only one process lineage: -- |-kamailio(22065)-+-kamailio(22069) | |-kamailio(22070) | |-kamailio(22071) | |-kamailio(22073) | |-kamailio(22074) | |-kamailio(22076) | |-kamailio(22079) | |-kamailio(22080) | |-kamailio(22082) | |-kamailio(22085) | |-kamailio(22086) | |-kamailio(22089) | |-kamailio(22091) | |-kamailio(22093) | |-kamailio(22095) | |-kamailio(22097) | |-kamailio(22099) | |-kamailio(22100) | |-kamailio(22103) | |-kamailio(22105) | |-kamailio(22107) | |-kamailio(22109) | |-kamailio(22111) | |-kamailio(22113) | |-kamailio(22115) | |-kamailio(22117) | |-kamailio(22119) | |-kamailio(22121) | |-kamailio(22123) | |-kamailio(22125) | |-kamailio(22127) | |-kamailio(22129) | |-kamailio(22131) | |-kamailio(22132) | |-kamailio(22135) | |-kamailio(22137) | |-kamailio(22139) | |-kamailio(22141) | |-kamailio(22143) | |-kamailio(22145) | |-kamailio(22147) | |-kamailio(22149) | |-kamailio(22151) | |-kamailio(22153) | |-kamailio(22155) | |-kamailio(22156) | |-kamailio(22159) | |-kamailio(22161) | |-kamailio(22163) | |-kamailio(22165) | |-kamailio(22167) | |-kamailio(22168) | |-kamailio(22169) | |-kamailio(22170) | |-kamailio(22172) | |-kamailio(22173) | |-kamailio(22175) | |-kamailio(22176) | |-kamailio(22177) | |-kamailio(22178) | |-kamailio(22179) | |-kamailio(22180) | |-kamailio(22182) | |-kamailio(22184) | |-kamailio(22186) | |-kamailio(22188) | |-kamailio(22190) | |-kamailio(22192) | |-kamailio(22194) | |-kamailio(22196) | |-kamailio(22198) | |-kamailio(22200) | |-kamailio(22202) | |-kamailio(22204) | |-kamailio(22206) | |-kamailio(22208) | |-kamailio(22210) | |-kamailio(22212) | |-kamailio(22214) | |-kamailio(22216) | |-kamailio(22218) | |-kamailio(22220) | |-kamailio(22223) | |-kamailio(22225) | `-kamailio(22227) -- Yet, for some reason, some of the processes have two established DB connections from different ports: -- kamailio 22220 root 3u IPv4 189895303 0t0 TCP 127.0.0.1:46550->127.0.0.1:postgres (ESTABLISHED) kamailio 22220 root 86u IPv4 189895067 0t0 TCP 127.0.0.1:46458->127.0.0.1:postgres (ESTABLISHED) kamailio 22223 root 3u IPv4 189895315 0t0 TCP 127.0.0.1:46556->127.0.0.1:postgres (ESTABLISHED) kamailio 22223 root 86u IPv4 189895067 0t0 TCP 127.0.0.1:46458->127.0.0.1:postgres (ESTABLISHED) kamailio 22225 root 3u IPv4 189895321 0t0 TCP 127.0.0.1:46560->127.0.0.1:postgres (ESTABLISHED) kamailio 22225 root 86u IPv4 189895067 0t0 TCP 127.0.0.1:46458->127.0.0.1:postgres (ESTABLISHED) kamailio 22227 root 86u IPv4 189895067 0t0 TCP 127.0.0.1:46458->127.0.0.1:postgres (ESTABLISHED) -- ... while others don't ... -- kamailio 22111 root 3u IPv4 189894820 0t0 TCP 127.0.0.1:46326->127.0.0.1:postgres (ESTABLISHED) kamailio 22113 root 3u IPv4 189894828 0t0 TCP 127.0.0.1:46332->127.0.0.1:postgres (ESTABLISHED) kamailio 22115 root 3u IPv4 189894834 0t0 TCP 127.0.0.1:46334->127.0.0.1:postgres (ESTABLISHED) kamailio 22117 root 3u IPv4 189894842 0t0 TCP 127.0.0.1:46338->127.0.0.1:postgres (ESTABLISHED) kamailio 22119 root 3u IPv4 189894848 0t0 TCP 127.0.0.1:46340->127.0.0.1:postgres (ESTABLISHED) -- So, this gives rise to two questions in my mind: 1. I don't seem to understand the relationship between the number of database connection handles and the total number of child processes. I had always assumed that only SIP workers and other processes specialised into a role with possible "database involvement" (e.g. rtimer, async workers, etc.) would hold database connections. 2. What's going on in the second scenario such that some processes have two connections? Both servers running: -- # kamcmd -s /tmp/kamailio_ctl core.version kamailio 4.4.6 (x86_64/linux) becbde -- Insights much appreciated! -- Alex -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

5 12

Jump to page:

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