Re: [SR-Users] Expect the kamailio's sip account is unregistered state when the client app is shutdown
Hi Xuefeng, did you do set any other module parameters? I can't get it to work.. My UAs uregister only because of expire=300, that means that they go offline after 5 minutes. Usually UAs have much higher expire=3600, does that mean they would go offline in 1 hour? I hoped, that when I set #!define WITH_NAT #!define WITH_NATSIPPING # - nathelper params - modparam(nathelper, natping_interval, 10) # modparam(nathelper, ping_nated_only, 1) modparam(nathelper, sipping_bflag, FLB_NATSIPPING) modparam(nathelper, sipping_from, sip:pin...@kamailio.org) modparam(nathelper, keepalive_timeout, 40) and # - presence params - modparam(presence, db_url, DBURL) modparam(presence, clean_period, 10) modparam(presence, db_update_period, 10) that my UAs will get offline as soon as in 40 seconds.. Where did I go wrong? Thanks. On 22.04.2015 04:21, xuefeng zhang wrote: Hi all, I add the WITH_NAT and WITH_NATSIPPING and it works ok.The account will unregister after 3 minutes. Thank you very much. Xuefeng Zhang 2015-04-21 17:43 GMT+08:00 Daniel-Constantin Mierla mico...@gmail.com mailto:mico...@gmail.com: Hello, On 21/04/15 07:07, Mickael Marrache wrote: Hi, IIR means If I Remember. indeed, thanks for completing -- it was a result of incomplete typing as I wanted to use IIRC (if i remember correctly), which is more standard acronym out there. Xuefeng: sending keepalives is done via nathelper module, by seeting sipping branch flag when processing REGISTER requests - see: - http://kamailio.org/docs/modules/4.2.x/modules/nathelper.html#nathelper.p.sipping_bflag For a proper example of usage, see the default kamailio.cfg for v4.2 - it has this feature inside, easy to enable with defines: #!define WITH_NAT #!define WITH_NATSIPPING Add those lines somewhere at the beginning of kamailio.cfg -- also, read the comments at the top of the kamailio.cfg, some notes about this are made there. Cheers, Daniel Are you also using keepalives sent by clients? I often read that NATs don't refresh their mapping on incoming traffic, you may want to take a look at client keepalives. Mickael On 21 באפר 2015, at 07:38, xuefeng zhang zhangxuefeng1...@gmail.com mailto:zhangxuefeng1...@gmail.com wrote: Hi Daniel, I understand your reply.The kamailio can set the IIR to send the OPTIONS packets period. But I don't found out the knowledge of the IIR. Would you give me some things how to do it. Thanks! Xuefeng Zhang 2015-04-20 18:10 GMT+08:00 Daniel-Constantin Mierla mico...@gmail.com mailto:mico...@gmail.com: IIR, the keepalives are sent stateless, so no transactions are create for them. Just OPTIONS packets sent out, resulting in less load on kamailio (well, comparing with normal transactional forwarding). The mechanism behind detecting offline users with keepalives is based on a counter kept in memory for the location record, which is reset if the reply to OPTIONS comes back. If there are three (or so) keepalives sent out and none was replied, then the record is removed. Practically there is no retransmission for those keepalive requests, no special states, just this counter in memory per location record. Given this, (again iirc), this feature doesn't work with db_mode set to database only. Cheers, Daniel On 20/04/15 10:46, Mickael Marrache wrote: Didn't know about that, it's interesting. I'm curious about the load impact of this feature, since keepalives are generally sent every 30 sec. -Original Message- From: sr-users [mailto:sr-users-boun...@lists.sip-router.org mailto:sr-users-boun...@lists.sip-router.org] On Behalf Of Daniel Grotti Sent: Monday, April 20, 2015 11:40 AM To: sr-users@lists.sip-router.org mailto:sr-users@lists.sip-router.org Subject: Re: [SR-Users] Expect the kamailio's sip account is unregistered state when the client app is shutdown Hi, you may want to use: http://www.kamailio.org/docs/modules/4.2.x/modules/nathelper.html#nathelper. p.keepalive_timeout -- Daniel Grotti VoIP Engineer Sipwise GmbH Europaring F15 | 2345 Brunn am Gebirge, Austria | www.sipwise.com http://www.sipwise.com On 04/20/2015 10:34 AM, Filip Malenka wrote: Thank you for information.. What can Kamailio do about clients, that exit abnormally
Re: [SR-Users] Roadmap for next major release v4.3.0
Hello, last day of coding new features for next major release 4.3. In more details, freezing timeline is 23:59 Kamailian timezone (aka Hawaii), in other words, North and South America should have also full day available for pushing new features. The mark will be effectively the change of the version from 4.3.0-devX in 4.3.0-pre-0 and it will be announced to mailing lists explicitly. Cheers, Daniel On 20/04/15 09:27, Daniel-Constantin Mierla wrote: Hello, start of the week reminder, by end of upcoming Wednesday, development for v4.3.0 will be frozen. If there are branches to be merged or other new features to be pushed in master branch, consider doing it before. Enjoy the week, Daniel On 16/04/15 10:39, Daniel-Constantin Mierla wrote: Hello, a reminder that in one week the development will be frozen. Anyone that has new features intended to be in 4.3 has to hurry up. I noticed 3 new modules in various branches and another one was discussed on github tracker, it would be good to merge them before starting the testing period. Cheers, Daniel On 30/03/15 11:25, Daniel-Constantin Mierla wrote: Hello, it is time to nail down the roadmap to the next major release. We discussed during the last IRC devel meeting, proposing to get it out by beginning of June. Given we need to have at least one month of testing, I propose the next milestones: - freezing the development: Wednesday, April 22, 2015 - if testing goes smooth, then branching 4.3 after about one month: During the week starting May 18 - test more in beta phase, prepare packaging, etc. and release after 2-3 weeks: One of the days between June 4 and 11 Other suggestions or adjustments are welcome! Send them to mailing list to discuss further. Cheers, Daniel -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015 Berlin, Germany - http://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] rtpengine and security
On 21/04/15 10:40 PM, GG GG wrote: By port closed, I mean that ports are normally closed, but when rtpengine send the first rtp packets to the client, it opens a pinhole in the firewall, and the matching incoming packets from the client will make the connection established,related in iptables. I think symmetric nat permits that. Yes, but rtpengine doesn't send any RTP or RTCP by itself. It only forwards RTP and RTCP, and in order to forward it, it first must receive it. If all ports are closed then nothing can ever be received and nothing can ever be forwarded or sent. Cheers ___ 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: MI Command: 'trusted_dump' and 'trusted_reload'
I know this is an old thread, but I'm having a strange issue like this with
trustedDump and trustedReload in permissions module.
I compiled latest git:
git clone git://git.sip-router.org/kamailio
I can only reload trusted data by restart kamailio
and when I do trustedDump command, i get strange output like:
root@ua01-proxy01:~# kamctl kamcmd permissions.trustedDump
{
table: 27
item: {
ip: 10.10.5.112úæ¼
proto: 0
pattern: NULL
tag: peer
}
table: 31
item: {
ip: 10.10.1.112(‘¹‚÷m»‚jÉUŠ´'æ
-_-+-: 0
-a++e_+: NULL
+ag: -ee_
}
+ab+e: 48
i+e+: {
i-: 192.168.159.10
-_-+-: 0
-a++e_+: NULL
+ag: -ee_
}
+ab+e: 70
i+e+: {
i-: 192.168.157.10
-_-+-: 0
-a++e_+: NULL
+ag: -ee_
}
+ab+e: 74
i+e+: {
i-: 192.168.101.154
-_-+-: 0
-a++e_+: NULL
+ag: f_01
}
+ab+e: 75
i+e+: {
i-: 192.168.101.155
-_-+-: 0
-a++e_+: NULL
+ag: f_02
}
}
with reload i get:
root@ua01-proxy01:~# kamctl kamcmd permissions.trustedReload
error: 500 - Reload failed.
and kamailio log shows:
Apr 22 10:16:21 ua01-proxy01 /usr/sbin/kamailio[20252]: ERROR: permissions
[trusted.c:78]: reload_trusted_table(): no connection to database
Apr 22 10:16:25 ua01-proxy01 /usr/sbin/kamailio[20252]: ERROR: permissions
[trusted.c:78]: reload_trusted_table(): no connection to database
I'm using postgres (not sure if that matters).
Can someone test this and see if it's not just me?
Thanks,
V
On Fri, Jun 21, 2013 at 6:56 AM, Sergey Okhapkin s...@sokhapkin.dyndns.org
wrote:
Hmm... trusted_dump and trusted_reload work OK to me. Kamailio compiled
from
git a week ago.
On Friday 21 June 2013 10:59:54 José Luis Millán wrote:
Hi,
I'm using 'allow_trusted()' from Permissions module without a problem in
a
Kamailio 4.0 routing logic. It does just work, but the MI command
'trusted_dump' tells me that the module is not in use:
'''
server:/home/jmillan# kamctl fifo trusted_dump
500 Trusted-module not in use
'''
Doing a 'trusted_reload' does neither make any query to database to
retrieve the data.
Other MI commands of same module do work correctly. ie: 'address_reload'
or
'address_dump'
Note: I have tested in a Kamailio 1.5 and the result is the same.
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
___
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] Problems with git.kamailio.org server?
Hello, is there actually a problem with the git.kamailio.org server? If I try the command git clone --depth 1 git://git.kamailio.org/kamailio kamailio or git clone --depth 1 git://git.sip-router.org/kamailio kamailio I got the message fatal: read error: connection reset by peer. Perhaps it is a problem of my setup? Best regards, Kai Ohnacker ___ 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] Problems with git.kamailio.org server?
Hello, thanks for reporting, I restarted the git daemon and now all seems ok. Let us know if works for you now. Cheers, Daniel On 22/04/15 10:20, kai.ohnac...@cbc.de wrote: Hello, is there actually a problem with the git.kamailio.org server? If I try the command / / /git clone --depth 1 git://git.kamailio.org/kamailio kamailio/ /or/ /git clone --depth 1 git://git.sip-router.org/kamailio kamailio/ / / I got the message “fatal: read error: connection reset by peer”. Perhaps it is a problem of my setup? Best regards, Kai Ohnacker ___ 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 http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015 Berlin, Germany - http://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] Unauthorized register with persistence PostgreSQL
Hello, First, thank you for your quick answer! When you say it’s a password problem, do you talk about the password of the user that kamailio use to connect my database? Because it doesn’t seem to be a connection problem between PostgreSQL and Kamailio. I think the connection is established between those two because I’m able to see the result of my “kamctl db show subscriber” command. Indeed, I saw what sip contacts are registered in the database. They are the ones I added with the kamctl add command. (By the way, if I finally make my configuration working, sip phones will be seeable in this command results?) If you talk about sip phones password, I know that when I add manually a new sip contact with kamctl add (and it’s registered in the database), I have to set a password. But before I change the basic config of Kamailio, when sip-phones registered on it (and they’ve been in its cache), no password was needed (at least, this was what I thought). Is it still wright with my new configuration? So, I follow your advice and set debug=3. In Kamailio log, I can see that the REGISTER is correctly received and parse. But I can see this line and I don’t really know what to think about it: Apr 22 08:20:28 host-sipr /usr/sbin/kamailio[26616]: DEBUG: tm [t_lookup.c:485]: matching_3261(): DEBUG: RFC3261 transaction matching failed And this line inquires me too : Apr 22 08:20:28 host-sipr /usr/sbin/kamailio[26616]: DEBUG: auth_db [authorize.c:196]: get_ha1(): no result for user '1001@' “1001” is the ID of one of my sip-phones. And I don’t understand why there is nothing after the @... I did the same test with a jitsi client and I still have the sale “ID@” and nothing after. Here is a more complete extract of the Kamailio log, if it helps: Apr 22 08:20:28 host-sipr /usr/sbin/kamailio[26614]: DEBUG: core [xavp.c:448]: xavp_destroy_list(): destroying xavp list (nil) Apr 22 08:20:28 host-sipr /usr/sbin/kamailio[26614]: DEBUG: core [receive.c:298]: receive_msg(): receive_msg: cleaning up Apr 22 08:20:28 host-sipr /usr/sbin/kamailio[26616]: DEBUG: core [parser/msg_parser.c:623]: parse_msg(): SIP Request: Apr 22 08:20:28 host-sipr /usr/sbin/kamailio[26616]: DEBUG: core [parser/msg_parser.c:625]: parse_msg(): method: REGISTER Apr 22 08:20:28 host-sipr /usr/sbin/kamailio[26616]: DEBUG: core [parser/msg_parser.c:627]: parse_msg(): uri: sip:sipr.domain Apr 22 08:20:28 host-sipr /usr/sbin/kamailio[26616]: DEBUG: core [parser/msg_parser.c:629]: parse_msg(): version: SIP/2.0 Apr 22 08:20:28 host-sipr /usr/sbin/kamailio[26616]: DEBUG: core [parser/parse_via.c:1284]: parse_via_param(): Found param type 232, branch = z9hG4bK-8141f9e3; state=16 Apr 22 08:20:28 host-sipr /usr/sbin/kamailio[26616]: DEBUG: core [parser/parse_via.c:2672]: parse_via(): end of header reached, state=5 Apr 22 08:20:28 host-sipr /usr/sbin/kamailio[26616]: DEBUG: core [parser/msg_parser.c:513]: parse_headers(): parse_headers: Via found, flags=2 Apr 22 08:20:28 host-sipr /usr/sbin/kamailio[26616]: DEBUG: core [parser/msg_parser.c:515]: parse_headers(): parse_headers: this is the first via Apr 22 08:20:28 host-sipr /usr/sbin/kamailio[26616]: DEBUG: core [receive.c:154]: receive_msg(): After parse_msg... Apr 22 08:20:28 host-sipr /usr/sbin/kamailio[26616]: DEBUG: core [receive.c:197]: receive_msg(): preparing to run routing scripts... Apr 22 08:20:28 host-sipr /usr/sbin/kamailio[26616]: DEBUG: core [parser/parse_addr_spec.c:898]: parse_addr_spec(): end of header reached, state=10 Apr 22 08:20:28 host-sipr /usr/sbin/kamailio[26616]: DEBUG: core [parser/msg_parser.c:190]: get_hdr_field(): DEBUG: get_hdr_field: To [26]; uri=[sip:1001@sipr.domain] Apr 22 08:20:28 host-sipr /usr/sbin/kamailio[26616]: DEBUG: core [parser/msg_parser.c:192]: get_hdr_field(): DEBUG: to body [sip:1001@sipr.domain#015#012] Apr 22 08:20:28 host-sipr /usr/sbin/kamailio[26616]: DEBUG: core [parser/msg_parser.c:170]: get_hdr_field(): get_hdr_field: cseq CSeq: 53896 REGISTER Apr 22 08:20:28 host-sipr /usr/sbin/kamailio[26616]: DEBUG: maxfwd [mf_funcs.c:85]: is_maxfwd_present(): value = 70 Apr 22 08:20:28 host-sipr /usr/sbin/kamailio[26616]: DEBUG: core [parser/msg_parser.c:204]: get_hdr_field(): DEBUG: get_hdr_body : content_length=0 Apr 22 08:20:28 host-sipr /usr/sbin/kamailio[26616]: DEBUG: core [parser/msg_parser.c:106]: get_hdr_field(): found end of header Apr 22 08:20:28 host-sipr /usr/sbin/kamailio[26616]: DEBUG: core [parser/parse_addr_spec.c:176]: parse_to_param(): DEBUG: add_param: tag=f10d25c01b845303o0 Apr 22 08:20:28 host-sipr /usr/sbin/kamailio[26616]: DEBUG: core [parser/parse_addr_spec.c:898]: parse_addr_spec(): end of header reached, state=29 Apr 22 08:20:28 host-sipr /usr/sbin/kamailio[26616]: DEBUG: sanity [mod_sanity.c:255]: w_sanity_check(): sanity checks result: 1 Apr 22 08:20:28 host-sipr /usr/sbin/kamailio[26616]: DEBUG: siputils [checks.c:103]: has_totag(): no totag Apr 22 08:20:28 host-sipr
Re: [SR-Users] Possible bug in TM module
Hello, On 22/04/15 11:26, Mickael Marrache wrote: Hi, I just got the following issue when stopping kamailio. kamailio[7279]: NOTICE: core [main.c:682]: handle_sigs(): Thank you for flying kamailio!!! kamailio[7279]: ERROR: ctl [ctl.c:369]: mod_destroy(): ERROR: ctl: could not delete unix socket /tmp/kamailio_ctl: Operation not permitted (1) kamailio[7279]: : core [mem/f_malloc.c:586]: fm_free(): BUG: fm_free: bad pointer 0x4f2dec62 (out of memory block!), called from tm: h_table.c: free_cell(138) - aborting I always get the first ERROR when I stop kamailio, I need to look at the permissions. However, the next one is a bug. the first one should be fixed with the new release. With old versions, ctl module doesn't inherits the user/group set by the core, you would have to set it in the ctl module via params. The second can happen in very rare cases -- if there was a transaction in the process of freeing, then signal interrupted it. Parts of the transaction structure that were freed could have been allocated already and value overwritten. But the transaction itself was not removed from the list, so the main process will attempt a cleanup at shutdown, ending in some invalid pointer data. If you get it every time, then is likely a bug. If you get it very rare, then it can be the above case. Perhaps we can add a flag saying it is shutdown where to be more flexible in handling these situations. Cheers, Daniel -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015 Berlin, Germany - http://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] Iterative DNS resolution by enum module ?
Hello everyone, Do you know if the kamailio enum module is able to process 'recursives' dns requests in case of CNAME or NS response, until a NAPTR answer is returned ? Thanks in advance! Jy ___ 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] Possible bug in TM module
Hi, For now, I got it only once, I will keep an eye on it. Thanks, Mickael From: sr-users [mailto:sr-users-boun...@lists.sip-router.org] On Behalf Of Daniel-Constantin Mierla Sent: Wednesday, April 22, 2015 12:37 PM To: Kamailio (SER) - Users Mailing List Subject: Re: [SR-Users] Possible bug in TM module Hello, On 22/04/15 11:26, Mickael Marrache wrote: Hi, I just got the following issue when stopping kamailio. kamailio[7279]: NOTICE: core [main.c:682]: handle_sigs(): Thank you for flying kamailio!!! kamailio[7279]: ERROR: ctl [ctl.c:369]: mod_destroy(): ERROR: ctl: could not delete unix socket /tmp/kamailio_ctl: Operation not permitted (1) kamailio[7279]: : core [mem/f_malloc.c:586]: fm_free(): BUG: fm_free: bad pointer 0x4f2dec62 (out of memory block!), called from tm: h_table.c: free_cell(138) - aborting I always get the first ERROR when I stop kamailio, I need to look at the permissions. However, the next one is a bug. the first one should be fixed with the new release. With old versions, ctl module doesn't inherits the user/group set by the core, you would have to set it in the ctl module via params. The second can happen in very rare cases -- if there was a transaction in the process of freeing, then signal interrupted it. Parts of the transaction structure that were freed could have been allocated already and value overwritten. But the transaction itself was not removed from the list, so the main process will attempt a cleanup at shutdown, ending in some invalid pointer data. If you get it every time, then is likely a bug. If you get it very rare, then it can be the above case. Perhaps we can add a flag saying it is shutdown where to be more flexible in handling these situations. Cheers, Daniel -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015 Berlin, Germany - http://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] Iterative DNS resolution by enum module ?
Subject: [SR-Users] Iterative DNS resolution by enum module ? Date: Wed, Apr 22, 2015 at 11:36:56AM +0200 Quoting jyaim (jya...@gmail.com): Hello everyone, Do you know if the kamailio enum module is able to process 'recursives' dns requests in case of CNAME or NS response, until a NAPTR answer is returned ? For NS, any recursive resolver does that. For CNAME, beware. CNAME is dominant; on a node in the DNS tree where there is a CNAME, no other record can be present. Of course, it is entirely possible to have: fancy.domain.tel. CNAME standard.domain.tel. and then put for instance: standard.domain.tel. NAPTR 10 0 S SIP+D2U _sip._udp.telco.tel What is explicitly forbidden is this: fancy.domain.tel. IN SOA strowger.axe.tel. root.tel. 17 fancy.domain.tel. IN CNAME lame.web.host. www.fancy.domain.tel. IN CNAME lame.web.host. Look here for something that does work: $ dig fancy.sub.besserwisser.org NAPTR ; DiG 9.8.4-rpz2+rl005.12-P1 fancy.sub.besserwisser.org NAPTR ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 2322 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;fancy.sub.besserwisser.org.IN NAPTR ;; ANSWER SECTION: fancy.sub.besserwisser.org. 27 IN CNAME simple.sub.besserwisser.org. simple.sub.besserwisser.org. 27 IN NAPTR 10 0 S SIP+D2U _sip._udp.boring.sub.besserwisser.org. ;; AUTHORITY SECTION: sub.besserwisser.org. 27 IN NS primary.se. If you query for NAPTR but the resolver encounters a CNAME, it will attempt to follow the redirection and then presents whatever answer or lack thereof back. There is no need to do any resolver functionality in the application layer; the answers are there. Perhaps the code handling the response from the system resolver needs to be updated, but that is another thing. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Look! A ladder! Maybe it leads to heaven, or a sandwich! signature.asc Description: Digital signature ___ 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] Possible bug in TM module
Hi, I just got the following issue when stopping kamailio. kamailio[7279]: NOTICE: core [main.c:682]: handle_sigs(): Thank you for flying kamailio!!! kamailio[7279]: ERROR: ctl [ctl.c:369]: mod_destroy(): ERROR: ctl: could not delete unix socket /tmp/kamailio_ctl: Operation not permitted (1) kamailio[7279]: : core [mem/f_malloc.c:586]: fm_free(): BUG: fm_free: bad pointer 0x4f2dec62 (out of memory block!), called from tm: h_table.c: free_cell(138) - aborting I always get the first ERROR when I stop kamailio, I need to look at the permissions. However, the next one is a bug. Thanks, Mickael ___ 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] Problems with git.kamailio.org server?
Hello, ok, perfect! For sake of information, in the future, if git.kamailio.org is not responding, one can use the github repository: - https://github.com/kamailio/kamailio Anyhow, always report here if git.kamailio.org is not responding, it has to be fixed. Cheers, Daniel On 22/04/15 10:54, kai.ohnac...@cbc.de wrote: Hello, now it works! J Thank you. Best regards, Kai Ohnacker *Von:*sr-users [mailto:sr-users-boun...@lists.sip-router.org] *Im Auftrag von *Daniel-Constantin Mierla *Gesendet:* Mittwoch, 22. April 2015 10:28 *An:* Kamailio (SER) - Users Mailing List *Betreff:* Re: [SR-Users] Problems with git.kamailio.org server? Hello, thanks for reporting, I restarted the git daemon and now all seems ok. Let us know if works for you now. Cheers, Daniel On 22/04/15 10:20, kai.ohnac...@cbc.de mailto:kai.ohnac...@cbc.de wrote: Hello, is there actually a problem with the git.kamailio.org server? If I try the command / / /git clone --depth 1 git://git.kamailio.org/kamailio kamailio/ /or/ /git clone --depth 1 git://git.sip-router.org/kamailio kamailio/ / / I got the message “fatal: read error: connection reset by peer”. Perhaps it is a problem of my setup? Best regards, Kai Ohnacker ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org mailto:sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users -- Daniel-Constantin Mierla http://twitter.com/#!/miconda http://twitter.com/#%21/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015 Berlin, Germany - http://www.kamailioworld.com -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015 Berlin, Germany - http://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] Problems with git.kamailio.org server?
Hello, now it works! :) Thank you. Best regards, Kai Ohnacker Von: sr-users [mailto:sr-users-boun...@lists.sip-router.org] Im Auftrag von Daniel-Constantin Mierla Gesendet: Mittwoch, 22. April 2015 10:28 An: Kamailio (SER) - Users Mailing List Betreff: Re: [SR-Users] Problems with git.kamailio.org server? Hello, thanks for reporting, I restarted the git daemon and now all seems ok. Let us know if works for you now. Cheers, Daniel On 22/04/15 10:20, kai.ohnac...@cbc.demailto:kai.ohnac...@cbc.de wrote: Hello, is there actually a problem with the git.kamailio.org server? If I try the command git clone --depth 1 git://git.kamailio.org/kamailio kamailio or git clone --depth 1 git://git.sip-router.org/kamailio kamailio I got the message fatal: read error: connection reset by peer. Perhaps it is a problem of my setup? Best regards, Kai Ohnacker ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.orgmailto:sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015 Berlin, Germany - http://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] db_mongodb get columns error
Hi, After restarting Kamailio, I got the following errors during the startup: kamailio[12614]: ERROR: db_mongodb [mongodb_dbase.c:381]: db_mongodb_get_columns(): field [caller_sock] not found in result iterator kamailio[12614]: ERROR: db_mongodb [mongodb_dbase.c:739]: db_mongodb_store_result(): failed to set the columns kamailio[12614]: ERROR: db_mongodb [mongodb_dbase.c:918]: db_mongodb_query(): failed to store result kamailio[12614]: ERROR: db_mongodb [mongodb_dbase.c:927]: db_mongodb_query(): failed to do the query kamailio[12614]: ERROR: dialog [dlg_db_handler.c:257]: select_entire_dialog_table(): Error while querying database What may be causing the issue? I should always have a caller_sock in every dialog document. Thanks, Mickael ___ 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
