sr-dev June 2015

sr-dev@lists.kamailio.org

34 participants
274 discussions

RTPEngine - REDIS Plugin
by Carsten Bock 25 Aug '15

25 Aug '15

Hi everyone, several months ago, we've implemented a plugin for RTPEngine to synchronize it with a REDIS-Database. This allows RTPEngine to operate in a HA, as you can restart RTPEngine and/or make a failover to another machine with the same IP (e.g. using Heartbeat or similar), WITHOUT LOOSING ACTIVE SESSIONS. This enhancement was originally implemented by Carlos Ruiz Diaz. Due to lack of time, it still requires RTPEngine 3.3 and needs an update, to work with later versions. It can be found here: https://github.com/ngvoice/rtpengine-redis-plugin If anyone is interested in contributing to this extension, please ping me and i will happily add you as a contributor. Thanks, Carsten -- Carsten Bock CEO (Geschäftsführer) ng-voice GmbH Schomburgstr. 80 D-22767 Hamburg / Germany http://www.ng-voice.com mailto:carsten@ng-voice.com Office +49 40 5247593-0 Fax +49 40 5247593-99 Sitz der Gesellschaft: Hamburg Registergericht: Amtsgericht Hamburg, HRB 120189 Geschäftsführer: Carsten Bock Ust-ID: DE279344284 Hier finden Sie unsere handelsrechtlichen Pflichtangaben: http://www.ng-voice.com/imprint/

5 8

git:master:9c3ea838: dialog: re-entrant mutex for dialogs hash table slots
by Daniel-Constantin Mierla 10 Aug '15

10 Aug '15

Module: kamailio Branch: master Commit: 9c3ea838b31039ac067e17d519df67b64b0dada1 URL: https://github.com/kamailio/kamailio/commit/9c3ea838b31039ac067e17d519df67b… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: 2015-06-16T15:18:27+02:00 dialog: re-entrant mutex for dialogs hash table slots - changed from a lock set usage to per slot lock field --- Modified: modules/dialog/dlg_hash.c Modified: modules/dialog/dlg_hash.h --- Diff: https://github.com/kamailio/kamailio/commit/9c3ea838b31039ac067e17d519df67b… Patch: https://github.com/kamailio/kamailio/commit/9c3ea838b31039ac067e17d519df67b…

2 4

[kamailio] Run event_route[dialog:end] on dialog terminated by dlg.end_dlg (#190)
by Andrey Utkin 18 Jul '15

18 Jul '15

We want it for CDR fields setting. Currently CDR is written or such forcefully terminated calls, but it lacks some post-processing which we have in event_route[dialog:end]. Whoever is going to work on this - please leave your wallet info (e.g. paypal) for my thanksgiving. --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/190

2 2

[kamailio] http_query causes memory corruption with AVPs (#212)
by scottgrim 18 Jul '15

18 Jul '15

I have found an instance where using an avp or xavp as the response variable for http_query will cause a segfault later in t_relay(). When I change the variable to a $var instead of an avp, there is no segfault. I can only recreate it with a specific URL. If I try to reproduce it by simply sending a plain text response from a static page, it does not segfault. The http_query command is as follows: http_query("http://cnam.dashcs.com/?companyId=XXXXX&password=XXXXXXX&number=$avp(from_p…", "$avp(cnam)"); version: kamailio 4.3.0 (x86_64/linux) c6aa95 flags: STATS: Off, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, F_MALLOC, DBG_F_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: c6aa95 compiled on 13:39:06 Jun 10 2015 with gcc 4.8.2 --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/212

2 16

[kamailio] UAC trouble with REGISTER to provider (#140)
by ovoshlook 15 Jul '15

15 Jul '15

Hello. We use UAC for RGISTER some trunks After fiew days normally work we have an issue that UAC not respond to 401 reply with WWW-Authenticate with reREGISTER with WWW. We have only 2 packets- REGISTR and 401. IP 10.0.1.12.5068 > 1.2.3.4.5060: UDP, length 467 E.......@..F ...............REGISTER sip:provider.com SIP/2.0 Via: SIP/2.0/UDP my.service.com:5068;branch=z9hG4bKdb22.edd7eac5000000000000000000000000.0 To: <sip:login@provider.com> From: <sip:login@provider.com>;tag=6a39af2190f8b2c99cc63bfeb3a3959c-bfba CSeq: 10 REGISTER Call-ID: 5e171580088d170a-9952(a)10.0.1.12 Max-Forwards: 70 Content-Length: 0 User-Agent: kamailio (4.3.0-dev5 (x86_64/linux)) Contact: <sip:login@my.service.com:5068> Expires: 360 IP 1.2.3.4.5060 > 10.0.1.12.5068: UDP, length 571 Q.......-. ........C.NSIP/2.0 401 Unauthorized Via: SIP/2.0/UDP my.service.com:5068;branch=z9hG4bKdb22.edd7eac5000000000000000000000000.0;received=23.100.24.250 From: <sip:login@provider.com>;tag=6a39af2190f8b2c99cc63bfeb3a3959c-bfba To: <sip:login@provider.com>;tag=as1550511c Call-ID: 5e171580088d170a-9952(a)10.0.1.12 CSeq: 10 REGISTER Server: FastTel SoftSwitch Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH Supported: replaces WWW-Authenticate: Digest algorithm=MD5, realm="provider.com", nonce="109104dc" Content-Length: 0 We have another trunk and reREGISTER is correctly REGISTER sip:another_prov.com SIP/2.0 Via: SIP/2.0/UDP my.service.com:5068;branch=z9hG4bK7fd1.3d7c2fd7000000000000000000000000.0 To: <sip:login_to_another_prov@another_prov.com> From: <sip:login_to_another_prov@another_prov.com>;tag=6a39af2190f8b2c99cc63bfeb3a3959c-f8ba CSeq: 10 REGISTER Call-ID: 5e171580088d1edd-9952(a)10.0.1.12 Max-Forwards: 70 Content-Length: 0 User-Agent: kamailio (4.3.0-dev5 (x86_64/linux)) Contact: <sip:login_to_another_prov@my.service.com:5068> Expires: 360 IP another_prov.com.5060 > 10.0.1.12.5068: UDP, length 544 E..<F...$. .6... ........(..SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP my.service.com:5068;branch=z9hG4bK7fd1.3d7c2fd7000000000000000000000000.0;rport=5068;received=23.100.28.126 To: <sip:login_to_another_prov@another_prov.com>;tag=04e2a294d0728b89107e081a19babab4.d569 From: <sip:login_to_another_prov@another_prov.com>;tag=6a39af2190f8b2c99cc63bfeb3a3959c-f8ba CSeq: 10 REGISTER Call-ID: 5e171580088d1edd-9952(a)10.0.1.12 WWW-Authenticate: Digest realm="another_prov.com", nonce="VTifD1U4neNLMSYRoxNlOpD7hPSu3ET3" Server: kamailio (4.2.1 (x86_64/linux)) Content-Length: 0 IP 10.0.1.12.5068 > another_prov.com.5060: UDP, length 690 E...uT..@... ...6...........REGISTER sip:another_prov.com SIP/2.0 Via: SIP/2.0/UDP my.service.com:5068;branch=z9hG4bK8fd1.ea73d070000000000000000000000000.0 To: <sip:login_to_another_prov@another_prov.com> From: <sip:login_to_another_prov@another_prov.com>;tag=6a39af2190f8b2c99cc63bfeb3a3959c-f8ba CSeq: 11 REGISTER Call-ID: 5e171580088d1edd-9952(a)10.0.1.12 Max-Forwards: 70 Content-Length: 0 User-Agent: kamailio (4.3.0-dev5 (x86_64/linux)) Contact: <sip:login_to_another_prov@my.service.com:5068> Expires: 360 Authorization: Digest username="login_to_another_prov", realm="another_prov.com", nonce="VTifD1U4neNLMSYRoxNlOpD7hPSu3ET3", uri="sip:another_prov.com", response="2ee14a437173700e88056279b854749f", algorithm=MD5 --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/140

2 3

[kamailio] Unquoted IPv6 Contact header alias parameter causes issues with Asterisk (PJSIP) & TOPOH module (#120)
by Anthony Messina 15 Jul '15

15 Jul '15

When using Kamailio from the master branch, I'm encountering an issue where IPv6 contact address aliases that are added via ```set_contact_alias()``` for WebSocket connections (for example) are unquoted and create problems for Asterisk: ``` pjsip:0 <?>: sip_transport. Error processing 3633 bytes packet from UDP 10.0.0.1:5060 : PJSIP syntax error exception when parsing 'Request Line' header on line 11 col 129: ``` and TOPOH garbles the Request-URI when processing the ACK: ``` WARNING: sanity [sanity.c:236]: check_ruri_scheme(): failed to parse request uri [�a�{1me▒s�na@50�9��1.�8:�2v0;i��a��=11>7�n7x>10O�2v0~1] ``` I have tested this with CSipSimple nightly branch (PJSIP) Asterisk 13.2.0 (PJSIP), Google Chrome 41.0.2272.118, and Firefox 37 and all fail to handle the Contact alias parameter properly. An example of an invite that shows this issue follows (this INVITE is without TOPOH on). ``` INVITE sip:testuser@example.com SIP/2.0 Record-Route: <sip:10.0.0.1;r2=on;lr=on;ftag=t5r2736hf9;nat=yes> Record-Route: <sip:[2001:db8::98]:5061;transport=ws;r2=on;lr=on;ftag=t5r2736hf9;nat=yes> Via: SIP/2.0/UDP 10.0.0.1;branch=z9hG4bKa3e8.2bb6508fbc0cf8cc55c1eb6c0eca0b38.0 Via: SIP/2.0/WSS 2e6orc23ptjv.invalid;rport=43691;received=2001:db8::99;branch=z9hG4bK450538 Max-Forwards: 69 To: <sip:testuser@example.com> From: "WS Test User 1" <sip:wstest1@example.com>;tag=t5r2736hf9 Call-ID: uugmpjgjpoklrnf0um56 CSeq: 7244 INVITE Contact: <sip:wstest1@example.com;gr=urn:uuid:2e54e8a2-66e4-433a-a024-b57f3665a44b;alias=[2001:db8::99]~43691~6> Allow: ACK,CANCEL,BYE,OPTIONS,INFO,NOTIFY,INVITE Content-Type: application/sdp Supported: gruu,outbound User-Agent: SIP.js/0.6.4 Content-Length: 2768 v=0 o=- 867554869709517848 2 IN IP4 10.0.0.1 s=- t=0 0 a=msid-semantic: WMS livWfUwMWQJMemgnFyBQDf1VXUo9Q0AXwHnH m=audio 30158 RTP/SAVP 111 103 104 9 0 8 106 105 13 126 c=IN IP4 10.0.0.1 a=rtpmap:111 opus/48000/2 a=fmtp:111 minptime=10; useinbandfec=1 a=rtpmap:103 ISAC/16000 a=rtpmap:104 ISAC/32000 a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:106 CN/32000 a=rtpmap:105 CN/16000 a=rtpmap:13 CN/8000 a=rtpmap:126 telephone-event/8000 a=maxptime:60 a=ssrc:1444733772 cname:CuBdEZ9bIWQc1sE+ a=ssrc:1444733772 msid:livWfUwMWQJMemgnFyBQDf1VXUo9Q0AXwHnH ebd0066b-73b9-467c-b696-36e0fa7d72b7 a=ssrc:1444733772 mslabel:livWfUwMWQJMemgnFyBQDf1VXUo9Q0AXwHnH a=ssrc:1444733772 label:ebd0066b-73b9-467c-b696-36e0fa7d72b7 a=sendrecv a=rtcp:30159 a=rtcp-mux a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:/fmyETo1BwAlupltb64sy5Za6e37BW0p5jMmvqHU a=setup:actpass a=fingerprint:sha-1 76:27:60:1E:64:94:B4:6E:8A:64:72:2D:41:2C:B8:F3:FF:4C:1D:56 a=ice-ufrag:U4XlaM4U a=ice-pwd:HqnTPTU5DY3j1yB4XVEL9rs1tn a=candidate:vVzo18e51E8EXCNy 1 UDP 2130706431 10.0.0.1 30158 typ host a=candidate:vVzo18e51E8EXCNy 2 UDP 2130706430 10.0.0.1 30159 typ host a=candidate:xCpWH2paVucFSQXn 1 UDP 2130706175 2001:db8::1 30158 typ host a=candidate:xCpWH2paVucFSQXn 2 UDP 2130706174 2001:db8::1 30159 typ host m=video 30196 RTP/SAVP 100 116 117 96 c=IN IP4 10.0.0.1 a=rtpmap:100 VP8/90000 a=rtcp-fb:100 ccm fir a=rtcp-fb:100 nack a=rtcp-fb:100 nack pli a=rtcp-fb:100 goog-remb a=rtpmap:116 red/90000 a=rtpmap:117 ulpfec/90000 a=rtpmap:96 rtx/90000 a=fmtp:96 apt=100 a=ssrc-group:FID 616715905 3177427003 a=ssrc:616715905 cname:CuBdEZ9bIWQc1sE+ a=ssrc:616715905 msid:livWfUwMWQJMemgnFyBQDf1VXUo9Q0AXwHnH bb5df7ec-28a9-4e94-89a3-2ebb45a9f5bb a=ssrc:616715905 mslabel:livWfUwMWQJMemgnFyBQDf1VXUo9Q0AXwHnH a=ssrc:616715905 label:bb5df7ec-28a9-4e94-89a3-2ebb45a9f5bb a=ssrc:3177427003 cname:CuBdEZ9bIWQc1sE+ a=ssrc:3177427003 msid:livWfUwMWQJMemgnFyBQDf1VXUo9Q0AXwHnH bb5df7ec-28a9-4e94-89a3-2ebb45a9f5bb a=ssrc:3177427003 mslabel:livWfUwMWQJMemgnFyBQDf1VXUo9Q0AXwHnH a=ssrc:3177427003 label:bb5df7ec-28a9-4e94-89a3-2ebb45a9f5bb a=sendrecv a=rtcp:30197 a=rtcp-mux a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:qQRmOwum0YFHgKKzt2dRX0uAQhSwlmxscI3P3JUI a=setup:actpass a=fingerprint:sha-1 76:27:60:1E:64:94:B4:6E:8A:64:72:2D:41:2C:B8:F3:FF:4C:1D:56 a=ice-ufrag:ISaptX08 a=ice-pwd:mxP343kHexU8SwtbCeRj4WyMNI a=candidate:vVzo18e51E8EXCNy 1 UDP 2130706431 10.0.0.1 30196 typ host a=candidate:vVzo18e51E8EXCNy 2 UDP 2130706430 10.0.0.1 30197 typ host a=candidate:xCpWH2paVucFSQXn 1 UDP 2130706175 2001:db8::1 30196 typ host a=candidate:xCpWH2paVucFSQXn 2 UDP 2130706174 2001:db8::1 30197 typ host ``` I believe that the Contact header alias parameter might need quotes in order to properly handle the bracketed IPv6 alias address, something like the following, but unfortunately I haven't been able to find evidence to be certain that this is the fix, though I do notice that parameters in headers with special characters like brackets are often quoted. ``` Contact: <sip:wstest1@example.com;gr=urn:uuid:2e54e8a2-66e4-433a-a024-b57f3665a44b;alias="[2001:db8::99]~43691~6"> ``` --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/120

2 7

[kamailio] Errors work BLF modules pua and presence (#104)
by klistrod 15 Jul '15

15 Jul '15

Errors work BLF modules pua and presence: loadmodule "presence.so" loadmodule "presence_xml.so" loadmodule "presence_dialoginfo.so" loadmodule "pua.so" loadmodule "pua_dialoginfo.so" modparam("presence", "db_url", DBURL) modparam("presence_xml", "db_url", DBURL) modparam("presence_xml", "force_active", 1) modparam("presence_dialoginfo", "force_single_dialog", 1) 5(18085) ERROR: presence [publish.c:139]: msg_presentity_clean(): event not found 5(18085) ERROR: db_mysql [km_dbase.c:123]: db_mysql_submit_query(): driver error on query: Duplicate entry 'a.1425449702.18081.57.5---' for key 'pua_idx' 5(18085) ERROR: <core> [db_query.c:335]: db_do_update(): error while submitting query 5(18085) ERROR: pua [pua.c:1079]: db_update(): while updating in database --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/104

2 3

[kamailio] 4.3 compiler warnings (#185)
by juha-h 15 Jul '15

15 Jul '15

I'm getting the following new (compared to k 4.2 on Debian Wheezy) compiler warnings when I build k 4.3 on Debian Jessie. It would be nice to get rid of them, because otherwise it gets hard to find real issues appearing during build. Same applies to 'old' tls module warnings. -- Juha ------------------------------------------------------------------------------------------------------------------------------ CC (gcc) [sip-proxy] mem/tlsf.o mem/tlsf.c:583:24: warning: 'block_trim_free_leading' defined but not used [-Wunused-function] static block_header_t* block_trim_free_leading(control_t* control, block_header_t* block, size_t size) ^ ... CC (gcc) [sip-proxy] cfg/cfg_ctx.o cfg/cfg_ctx.c: In function 'cfg_set_now': cfg/cfg_ctx.c:485:5: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] group_inst = (cfg_group_inst_t *)translate_pointer((char *)new_array, ^ cfg/cfg_ctx.c:489:5: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] CFG_GROUP_META(block, group)->array = new_array; ^ cfg/cfg_ctx.c:559:4: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] if (block && (CFG_GROUP_META(block, group)->array != CFG_GROUP_META(*cfg_global, group)->array)) ^ cfg/cfg_ctx.c:559:4: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] cfg/cfg_ctx.c:560:5: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] new_array = CFG_GROUP_META(block, group)->array; ^ cfg/cfg_ctx.c:579:5: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] replaced[i] = CFG_GROUP_META(*cfg_global, group)->array; ^ cfg/cfg_ctx.c: In function 'cfg_commit': cfg/cfg_ctx.c:1120:5: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] if (!(CFG_GROUP_META(block, group)->array = ^ cfg/cfg_ctx.c:1128:5: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] replaced[replaced_num] = CFG_GROUP_META(*cfg_global, group)->array; ^ cfg/cfg_ctx.c:1180:5: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] && (CFG_GROUP_META(block, changed->group)->array != CFG_GROUP_META(*cfg_global, changed->group)->array) ^ cfg/cfg_ctx.c:1180:5: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] cfg/cfg_ctx.c:1185:5: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] replaced[replaced_num] = CFG_GROUP_META(*cfg_global, group)->array; ^ cfg/cfg_ctx.c:1220:4: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] if (CFG_GROUP_META(block, group)->array ^ cfg/cfg_ctx.c:1221:5: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] && (CFG_GROUP_META(block, group)->array != CFG_GROUP_META(*cfg_global, group)->array) ^ cfg/cfg_ctx.c:1221:5: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] cfg/cfg_ctx.c:1223:5: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] shm_free(CFG_GROUP_META(block, group)->array); ^ cfg/cfg_ctx.c: In function 'cfg_add_group_inst': cfg/cfg_ctx.c:1577:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] CFG_GROUP_META(block, group)->array = new_array; ^ cfg/cfg_ctx.c:1578:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] CFG_GROUP_META(block, group)->num++; ^ cfg/cfg_ctx.c:1580:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] if (CFG_GROUP_META(*cfg_global, group)->array) { ^ cfg/cfg_ctx.c:1589:3: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] replaced[0] = CFG_GROUP_META(*cfg_global, group)->array; ^ cfg/cfg_ctx.c: In function 'cfg_del_group_inst': cfg/cfg_ctx.c:1673:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] CFG_GROUP_META(block, group)->array = new_array; ^ cfg/cfg_ctx.c:1674:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] CFG_GROUP_META(block, group)->num--; ^ cfg/cfg_ctx.c:1676:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] if (CFG_GROUP_META(*cfg_global, group)->array) { ^ cfg/cfg_ctx.c:1687:5: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] && (*(char **)(group_inst->vars + var->offset) != NULL) ^ cfg/cfg_ctx.c:1705:6: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] && (*(char **)(group_inst->vars + var->offset) != NULL) ^ cfg/cfg_ctx.c:1707:6: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] replaced[num] = *(char **)(group_inst->vars + var->offset); ^ cfg/cfg_ctx.c:1713:3: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] replaced[num] = CFG_GROUP_META(*cfg_global, group)->array; ^ ... CC (gcc) [L libsrutils.so.1.0] sha256.o sha256.c: In function 'SHA256_Final': sha256.c:613:3: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] *(sha2_word64*)&context->buffer[SHA256_SHORT_BLOCK_LENGTH] = context->bitcount; ^ sha256.c: In function 'SHA512_Last': sha256.c:930:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] *(sha2_word64*)&context->buffer[SHA512_SHORT_BLOCK_LENGTH] = context->bitcount[1]; ^ sha256.c:931:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] *(sha2_word64*)&context->buffer[SHA512_SHORT_BLOCK_LENGTH+8] = context->bitcount[0]; ^ --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/185

3 4

[kamailio] Core crashed, EOF on 23 (#158)
by Jay J 14 Jul '15

14 Jul '15

``` kamailio 4.3.0-pre0 (x86_64/linux) e1d68c flags: STATS: Off, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, F_MALLOC, DBG_F_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: e1d68c ``` Hi, Today everything was business as usual, when this happened: ``` May 13 03:40:32 Kamailio2 kamailio[7104]: CRITICAL: <core> [pass_fd.c:275]: receive_fd(): EOF on 23 May 13 03:40:32 Kamailio2 kamailio[7064]: ALERT: <core> [main.c:728]: handle_sigs(): child process 7066 exited by a signal 11 May 13 03:40:32 Kamailio2 kamailio[7064]: ALERT: <core> [main.c:731]: handle_sigs(): core was generated May 13 03:40:32 Kamailio2 kamailio[7064]: INFO: <core> [main.c:743]: handle_sigs(): terminating due to SIGCHLD May 13 03:40:32 Kamailio2 kamailio[7068]: INFO: <core> [main.c:794]: sig_usr(): signal 15 received ``` Needless to say, Kamailio crashed (thankfully after hours). No more related logs, unfortunately. Was wondering if you can tell anything just by the excerpt above. Thanks. --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/158

3 9

[kamailio] core: clean previous routename (#224)
by Victor Seva 06 Jul '15

06 Jul '15

fix c44685cbcefb8f6ecfa6f11369699906db832c39 routename is not been reset when no name is use like on main or reply route You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/224 -- Commit Summary -- * core: clean previous routename in order to get the correct default_routename -- File Changes -- M cfg.y (8) -- Patch Links -- https://github.com/kamailio/kamailio/pull/224.patch https://github.com/kamailio/kamailio/pull/224.diff --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/224

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev June 2015