sr-dev July 2018

sr-dev@lists.kamailio.org

17 participants
230 discussions

[kamailio/kamailio] Issues with PUA_REGINFO module (#1579)
by Lars Olsson 22 Aug '18

22 Aug '18

### Description While testing to implement an IMS AS, I used the PUA_REGINFO module to receive details about the SIP registration. PUA_REGINFO module uses PUA and USRLOC modules. However, a couple of issues was found including a crash: 1) Crash when processing SIP Notify with registration terminated info. 2) Randomly fails storing data to USRLOC, (entries already exists) 3) Saves corrupt data to database use_domain is set in usrloc but domain not provided in Notify request ### Troubleshooting I am pretty new to Kamailio, but my findings are the following in notify.c 1) PUA_REGINFO modules, deletes the record with "ul.delete_urecord(...)" and later down in the code calls "if (ul_record) ul.release_urecord(ul_record);". Crashes on the release_urecord call. My assumption without knowing to much about userloc is that release can not be called on a deleted record. Hence it should be enough to set ul_record = NULL after calling "ul.delete_urecord(...)" to not call release_urecord later on. 2) It looks like there is an issue handling parallell request. Without knowing too much, it replacing sruid_next(..) with sruid_next_safe() resolves the issue. Also, the static variable of type ucontact_info_t should probably become local as well. 3) Maybe incorrect to set use_domain to 1 when using the module, however I think it should be failsafe and not store garbage data in to database. Not looked into this issue. #### Reproduction Send Notify request with REGINFO body for registration and unregistration and forward it to the module according to the documentation of PUA_REGINFO. #### Debugging Data Attaching SIPp scenario. Changing code according to 1) and 2) make the SIPp script runs and no critical issues seen. (Have too less experience to ensure that no memleaks are introduced or still present in the module code) <?xml version="1.0" encoding="ISO-8859-1" ?> <scenario name="notify"> <send retrans="500"> <![CDATA[ NOTIFY sip:[remote_ip] SIP/2.0 Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch] From: <sip:[field0]@[field1]>;tag=[call_number] To: <sip:[field0]@[field1]> Call-ID: [call_id] CSeq: 1 NOTIFY Contact: sip:[field0]@[local_ip]:[local_port] Max-Forwards: 70 Expires: 1800 Event: reg User-Agent: SIPp/Linux Subscription-State: active;expires=6888 Content-Type: application/reginfo+xml Content-Length: [len] <?xml version="1.0"?> <reginfo xmlns="urn:ietf:params:xml:ns:reginfo" version="2" state="full"> <registration aor="sip:[field0]@mnc001.mcc001.3gppnetwork.org" id="0x7feff71118f8" state="active"> <contact id="0x7feff7126e58" state="active" event="registered" expires="595" q="0.500"> <uri>sip:[field0]@192.168.55.103:21061;ob;alias=192.168.55.103~21061~1</uri> <unknown-param name="+g.3gpp.smsip"></unknown-param> <unknown-param name="q">"0.5"</unknown-param> </contact> </registration> </reginfo> ]]> </send> <recv response="202" rtd="true"> </recv> <pause milliseconds="1000"/> <send retrans="500"> <![CDATA[ NOTIFY sip:[remote_ip] SIP/2.0 Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch] From: <sip:[field0]@[field1]>;tag=[call_number] To: <sip:[field0]@[field1]> Call-ID: [call_id] CSeq: 2 NOTIFY Contact: sip:[field0]@[local_ip]:[local_port] Max-Forwards: 70 Expires: 1800 User-Agent: SIPp/Linux Event: reg Subscription-State: active;expires=6888 Content-Type: application/reginfo+xml Content-Length: [len] <?xml version="1.0"?> <reginfo xmlns="urn:ietf:params:xml:ns:reginfo" version="3" state="full"> <registration aor="sip:[field0]@mnc001.mcc001.3gppnetwork.org" id="0x7feff71118f8" state="terminated"> <contact id="0x1" state="terminated" event="expired" expires="0" q="0.000"> <uri>sip:[field0]@192.168.55.103:21061;ob;alias=192.168.55.103~21061~1</uri> </contact> </registration> </reginfo> ]]> </send> <recv response="202" rtd="true"> </recv> </scenario> #### Log Messages #### SIP Traffic ### Possible Solutions See troubleshooting. ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` 5.1.4 ``` * **Operating System**: ``` Debian 8.11 ``` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/1579

6 15

[kamailio/kamailio] Append_to_reply does not work for XHTTP responses (#1548)
by Olle E. Johansson 21 Aug '18

21 Aug '18

Tried append_to_reply from textutils in event_route[xhttp:request] - which is not a documented usage. It did not generate an error about a bad route, but did not seem to append the header to the response. This may be a feature request, but wouldn't it be cool if it worked? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/1548

2 10

[kamailio/kamailio] [sipcapture]：parse_headers error. (#1582)
by aleczmw 20 Aug '18

20 Aug '18

Hello, Could you please help check below question about parse_headers error. Look like it cannot find a '\n' from the header body to the end of message. Is it possible? code: match=q_memchr(tmp, '\n', end-tmp); if (match){ match++; }else { ERR("bad body for <%s>(%d)\n", hdr->name.s, hdr->type); /* abort(); */ tmp=end; goto error; } Log: ^[[0;39;49m^[[0;31;49m 5(23) ERROR: [parser/msg_parser.c:329]: parse_headers(): bad header field [Route: <sip:pcsf-aut] ^[[0;39;49m^[[0;31;49m 5(23) ERROR: sipcapture [sipcapture.c:1209]: sip_capture_prepare(): cannot parse headers ^[[0;39;49m^[[0;31;49m 5(23) ERROR: [parser/msg_parser.c:329]: parse_headers(): bad header field [Route: <sip:pcsf-aut] ^[[0;39;49m^[[0;31;49m 5(23) ERROR: [parser/parse_ppi_pai.c:124]: parse_pai_header(): Error parsing PAI header ^[[0;39;49m^[[0;31;49m 5(23) ERROR: [parser/msg_parser.c:253]: get_hdr_field(): bad body for <Route: sip:pcsf-aut1.imsgroup0-000.qa41c.imsate.lucentlab.com;lr;ottag=ue_term;bidx=12;ac(9) ^[[0;39;49m^[[0;31;49m 5(23) ERROR: [parser/msg_parser.c:329]: parse_headers(): bad header field [Route: <sip:pcsf-aut] ^[[0;39;49m^[[0;31;49m 5(23) ERROR: [parser/parse_ppi_pai.c:171]: parse_ppi_header(): Error parsing PPI header ^[[0;39;49m^[[0;31;49m 4(22) ERROR: [parser/msg_parser.c:253]: get_hdr_field(): bad body for <P-Asserted-Identity: sip:+(50) ^[[0;39;49m^[[0;31;49m 4(22) ERROR: [parser/msg_parser.c:329]: parse_headers(): bad header field [P-Asserted-Identity:] ^[[0;39;49m^[[0;31;49m 4(22) ERROR: sipcapture [sipcapture.c:1209]: sip_capture_prepare(): cannot parse headers ^[[0;39;49m^[[0;31;49m 4(22) ERROR: [parser/msg_parser.c:253]: get_hdr_field(): bad body for <P-Asserted-Identity: sip:+(50) ^[[0;39;49m^[[0;31;49m 4(22) ERROR: [parser/msg_parser.c:329]: parse_headers(): bad header field [P-Asserted-Identity:] ^[[0;39;49m^[[0;31;49m 4(22) ERROR: [parser/parse_ppi_pai.c:124]: parse_pai_header(): Error parsing PAI header ^[[0;39;49m^[[0;31;49m 4(22) ERROR: [parser/msg_parser.c:253]: get_hdr_field(): bad body for <P-Asserted-Identity: sip:+(50) ^[[0;39;49m^[[0;31;49m 4(22) ERROR: [parser/msg_parser.c:329]: parse_headers(): bad header field [P-Asserted-Identity:] ^[[0;39;49m^[[0;31;49m 4(22) ERROR: [parser/parse_ppi_pai.c:171]: parse_ppi_header(): Error parsing PPI header ^[[0;39;49m^[[0;31;49m 3(20) ERROR: [parser/msg_parser.c:253]: get_hdr_field(): bad body for <P-Asserted-Identity: sip:+17053200002(50) ^[[0;39;49m^[[0;31;49m 3(20) ERROR: [parser/msg_parser.c:329]: parse_headers(): bad header field [P-Asserted-Identity:] ^[[0;39;49m^[[0;31;49m 3(20) ERROR: sipcapture [sipcapture.c:1209]: sip_capture_prepare(): cannot parse headers ^[[0;39;49m^[[0;31;49m 3(20) ERROR: [parser/msg_parser.c:253]: get_hdr_field(): bad body for <P-Asserted-Identity: sip:+17053200002(50) ^[[0;39;49m^[[0;31;49m 3(20) ERROR: [parser/msg_parser.c:329]: parse_headers(): bad header field [P-Asserted-Identity:] ^[[0;39;49m^[[0;31;49m 3(20) ERROR: [parser/parse_ppi_pai.c:124]: parse_pai_header(): Error parsing PAI header ^[[0;39;49m^[[0;31;49m 3(20) ERROR: [parser/msg_parser.c:253]: get_hdr_field(): bad body for <P-Asserted-Identity: sip:+17053200002(50) ^[[0;39;49m^[[0;31;49m 3(20) ERROR: [parser/msg_parser.c:329]: parse_headers(): bad header field [P-Asserted-Identity:] ^[[0;39;49m^[[0;31;49m 3(20) ERROR: [parser/parse_ppi_pai.c:171]: parse_ppi_header(): Error parsing PPI header Thanks in advance. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/1582

3 5

[kamailio/kamailio] getting an error while install kamailio5.1 on ubntu 18.4 (#1602)
by limitall 14 Aug '18

14 Aug '18

flex -o core/lex.yy.c core/cfg.lex CC (gcc) [kamailio] core/lex.yy.o CC (gcc) [kamailio] core/cfg.tab.o LD (gcc) [kamailio] kamailio CC (gcc) [M db_mysql.so] km_val.o CC (gcc) [M db_mysql.so] my_fld.o In file included from my_fld.c:22:0: my_fld.h:37:2: error: unknown type name ‘my_bool’ my_bool is_null; ^~~~~~~ ../../Makefile.rules:100: recipe for target 'my_fld.o' failed make[2]: *** [my_fld.o] Error 1 Makefile:511: recipe for target 'modules' failed make[1]: *** [modules] Error 1 make[1]: Leaving directory '/usr/local/src/kamailio-5.1/kamailio/src' Makefile:27: recipe for target 'all' failed make: *** [all] Error 2 -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/1602

5 6

[kamailio/kamailio] topos: adding param contact_hostname (#1596)
by Julien Chavanton 14 Aug '18

14 Aug '18

2 8

Security announcement related to Kamailio
by Henning Westerholt 04 Aug '18

04 Aug '18

Hello, I want to highlight that the last stable versions (for the two maintained series: 5.0 and 5.1) include fixes for an security issues that can crash a running instance of Kamailio, therefore it is strongly recommended to upgrade. Details: There exists a security vulnerability in the Kamailio SIP server related to "To" header processing. A specially crafted SIP message with double "To" header and an empty "To" tag causes a segmentation fault and crashes Kamailio. The reason is missing input validation in the "build_res_buf_from_sip_req" core function. If an attacker sends many of this messages this would lead to a Denial of Service of the attacked infrastructure. This is especially critical as no authentication for the remote source is needed. You find all the details including a proof of concept code in the published security announcement in my blog: https://skalatan.de/blog/advisory-hw-2018-05 A CVE report for this issue is going to be created as well in the near future. The issues were found some months ago and were fixed quickly. The code related to the reported issues is rather old and there are no known incidents of exploiting these issues so far. However, once the CVE report becomes public, there could be a higher risk of exploitation. Please address any detailed technical questions related to this to the developer list at sr-dev(a)lists.kamailio.org . In case of confidential remarks related to this or other security issues, please address them to the Kamailio Management. Best regards, Henning Westerholt -- Henning Westerholt https://skalatan.de/blog/

1 1

[kamailio/kamailio] ims_ipsec_pcscf: sec-agree implementation for IMS (#1605)
by Tsvetomir Dimitrov 02 Aug '18

02 Aug '18

#### Pre-Submission Checklist    - [X] Commit message has the format required by CONTRIBUTING guide - [X] Commits are split per component (core, individual modules, libs, utils, ...) - [X] Each component has a single commit (if not, squash them into one commit) - [X] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated) #### Type Of Change - [ ] Small bug fix (non-breaking change which fixes an issue) - [X] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality) #### Checklist:  - [ ] PR should be backported to stable branches - [X] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description  This is an implementation of sec-agree used in IMS with IPSec. It's not a complete sec-agree implementation, only the flows used by IMS. The code is usable, but needs a few improvements, which I plan to push in the near future. **My work is based on the implementation in OpenIMSCore.** For IPSec implementation the XFRM framework from the Linux kernel is used. Security association (SA) and Policies creation/removal is performed via netlink messages. For this reason the module depends on libmnl (a minimalistic netlink library). As XFRM is Linux specific, the code is not portable and can't be used on operating system different from Linux. The code will not compile on *BSDs too. However all platform specific code resides in ipsec.c so support for other OSes/IPSec implementations can be added relatively easy. The README file, which is commited is generated from docs dir with xsltproc. Issues I still work on: - Kamailio must be run as root in order to be able to send netlink messages and create XFRM SAs and Policies. - SAs and Policies are not deleted on Kamailio startup and shutdown. - According to the current contact implementation in the PCSCF modules (adn the 3GPP specs) the IPSec tunnel should be created on two steps. Initial parameters should be saved in security_tmp and on confirmation - in security. At the moment everything remains in security. As this is my first more serious contribution to the project, all kinds of feedback is highly appreciated :) You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/1605 -- Commit Summary -- * ims_ipsec_pcscf: sec-agree implementation for IMS -- File Changes -- A src/modules/ims_ipsec_pcscf/Makefile (20) A src/modules/ims_ipsec_pcscf/README (244) A src/modules/ims_ipsec_pcscf/cmd.c (585) A src/modules/ims_ipsec_pcscf/cmd.h (6) A src/modules/ims_ipsec_pcscf/doc/Makefile (4) A src/modules/ims_ipsec_pcscf/doc/ims_ipsec_pcscf.xml (88) A src/modules/ims_ipsec_pcscf/doc/ims_ipsec_pcscf_admin.xml (231) A src/modules/ims_ipsec_pcscf/ims_ipsec_pcscf_mod.c (227) A src/modules/ims_ipsec_pcscf/ipsec.c (386) A src/modules/ims_ipsec_pcscf/ipsec.h (24) A src/modules/ims_ipsec_pcscf/run_spi_list_tests.sh (4) A src/modules/ims_ipsec_pcscf/spi_gen.c (87) A src/modules/ims_ipsec_pcscf/spi_gen.h (16) A src/modules/ims_ipsec_pcscf/spi_list.c (123) A src/modules/ims_ipsec_pcscf/spi_list.h (29) A src/modules/ims_ipsec_pcscf/spi_list_tests.c (292) -- Patch Links -- https://github.com/kamailio/kamailio/pull/1605.patch https://github.com/kamailio/kamailio/pull/1605.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/1605

3 6

[kamailio/kamailio] Update dlg_cb.c (#1607)
by kosza 01 Aug '18

01 Aug '18

2 2

[kamailio/kamailio] Fix no cdr after restart (#1606)
by kosza 01 Aug '18

01 Aug '18

Hello! I am using kamailio 5.1.4. version: kamailio 5.1.4 (x86_64/linux) flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, 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: unknown compiled on 15:11:36 Jul 20 2018 with gcc 7.3.0 The problem is that if kamailio is restarted during a call the cdr would not be created. The run_load_callbacks() should be call after acc module is loaded. The acc module will setup DLGCB_LOADED type callback. So run_load_callbacks() should be delayed and run only once, the child_init(PROC_MAIN) is perfect for it.   #### Pre-Submission Checklist    - [ ] Commit message has the format required by CONTRIBUTING guide - [ ] Commits are split per component (core, individual modules, libs, utils, ...) - [ ] Each component has a single commit (if not, squash them into one commit) - [ ] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated) #### Type Of Change - [ ] Small bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality) #### Checklist:  - [ ] PR should be backported to stable branches - [ ] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description  You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/1606 -- Commit Summary -- * Fix no cdr after restart bug -- File Changes -- M src/modules/dialog/dialog.c (5) -- Patch Links -- https://github.com/kamailio/kamailio/pull/1606.patch https://github.com/kamailio/kamailio/pull/1606.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/1606

2 3

[kamailio/kamailio] crash in ims_usrloc_scscf.so (#1600)
by Sergey Zyrianov 01 Aug '18

01 Aug '18

### Description IMS reregistration triggers core dump on 5.1.4. 1) Create IMS registration 2) Put IMS terminal offline 3) Put it back online to update IMS registration 4) Register requests time out on s-cscf ### Troubleshooting This seems to be related to the cleaning up contacts during registration/re-registration. Related to the https://github.com/kamailio/kamailio/pull/1562. This PR did not make it to 5.1.4 but affected code was clearly involved according to the logs. #### Reproduction #### Debugging Data #### Log Messages ``` Jul 24 07:21:00 scscf scscfXXXYYY-ecs[798]: 1(6) DEBUG: ims_usrloc_scscf [impurecord.c:451]: process_impurecord(): There are 2 contacts to expire/unlink Jul 24 07:21:00 scscf scscfXXXYYY-ecs[798]: 1(6) DEBUG: ims_usrloc_scscf [impurecord.c:454]: process_impurecord(): expiring contact 0: [sip:XXXYY4000013362@10.110.1 Jul 24 07:21:00 scscf scscfXXXYYY-ecs[798]: 1(6) DEBUG: ims_usrloc_scscf [impurecord.c:1237]: unlink_contact_from_impu(): asked to unlink contact [0x7f7141cf29a0] => [sip:XXXYY4000 Jul 24 07:21:00 scscf scscfXXXYYY-ecs[798]: 1(6) DEBUG: ims_usrloc_scscf [impurecord.c:1106]: remove_impucontact_from_list(): deleting mid list Jul 24 07:21:00 scscf scscfXXXYYY-ecs[798]: 1(6) DEBUG: ims_usrloc_scscf [usrloc_db.c:1130]: db_unlink_contact_from_impu(): DB: un-linking contact to IMPU Jul 24 07:21:00 scscf scscfXXXYYY-ecs[798]: 1(6) DEBUG: <core> [db_res.c:120]: db_new_result(): allocate 56 bytes for result set at 0x7f714ba6e620 Jul 24 07:21:00 scscf scscfXXXYYY-ecs[798]: 1(6) DEBUG: <core> [db_res.c:79]: db_free_columns(): freeing 0 columns Jul 24 07:21:00 scscf scscfXXXYYY-ecs[798]: 1(6) DEBUG: <core> [db_res.c:138]: db_free_result(): freeing result set at 0x7f714ba6e620 Jul 24 07:21:00 scscf scscfXXXYYY-ecs[798]: 1(6) DEBUG: ims_usrloc_scscf [usrloc_db.c:1155]: db_unlink_contact_from_impu(): Delete query success Jul 24 07:21:00 scscf scscfXXXYYY-ecs[798]: 1(6) DEBUG: ims_usrloc_scscf [udomain.c:852]: unref_contact_unsafe(): decrementing ref count on contact [sip:XXXYY4000013362@10.110.1.69 Jul 24 07:21:00 scscf scscfXXXYYY-ecs[798]: 1(6) DEBUG: ims_usrloc_scscf [udomain.c:855]: unref_contact_unsafe(): contact [sip:XXXYY4000013362@10.110.1.69:5060;alias=10.110.1.69~50 Jul 24 07:21:00 scscf scscfXXXYYY-ecs[798]: 1(6) DEBUG: ims_usrloc_scscf [impurecord.c:1263]: unlink_contact_from_impu(): unlinking contact [0x7f7141cf29a0] => [sip:XXXYY4000013362 Jul 24 07:21:00 scscf scscfXXXYYY-ecs[798]: 1(6) DEBUG: ims_usrloc_scscf [impurecord.c:454]: process_impurecord(): expiring contact 1: [sip:XXXYY4000013362@10.110.1 Jul 24 07:21:00 scscf scscfXXXYYY-ecs[798]: 1(6) DEBUG: ims_usrloc_scscf [impurecord.c:1237]: unlink_contact_from_impu(): asked to unlink contact [0x7f7141cfc878] => [sip:XXXYY4000 Jul 24 07:21:00 scscf scscfXXXYYY-ecs[798]: 1(6) DEBUG: ims_usrloc_scscf [impurecord.c:1103]: remove_impucontact_from_list(): **deleting tail** Jul 24 07:22:21 scscf scscfXXXYYY-ecs[798]: 15(20) DEBUG: ims_registrar_scscf [save.c:840]: update_contacts(): updating contacts in RE-REGISTRATION state Jul 24 07:22:21 scscf scscfXXXYYY-ecs[798]: 15(20) DEBUG: ims_registrar_scscf [save.c:519]: update_contacts_helper(): updating the contacts for IMPU <sip:XXXYY4000013362@ims.mnc006. Jul 24 07:22:21 scscf scscfXXXYYY-ecs[798]: 15(20) DEBUG: <core> [ims_getters.c:812]: cscf_get_sos_uri_param(): cscf_get_sos_uri_param: searching through the uri parameters:alias=10 Jul 24 07:22:21 scscf scscfXXXYYY-ecs[798]: 15(20) DEBUG: <core> [ims_getters.c:823]: cscf_get_sos_uri_param(): cscf_get_sos_uri_param:name: alias body: 10.110.1.71~5060~1 Jul 24 07:22:21 scscf scscfXXXYYY-ecs[798]: 15(20) DEBUG: ims_registrar_scscf [save.c:137]: calc_contact_expires(): Calculated expires for contact is 600000 Jul 24 07:22:21 scscf scscfXXXYYY-ecs[798]: 15(20) DEBUG: ims_registrar_scscf [save.c:548]: update_contacts_helper(): Need to update contact: <sip:XXXYY4000013362@10.110.1.71:5060;a Jul 24 07:22:21 scscf scscfXXXYYY-ecs[798]: 15(20) DEBUG: ims_registrar_scscf [save.c:550]: update_contacts_helper(): packing contact information Jul 24 07:22:21 scscf scscfXXXYYY-ecs[798]: 15(20) DEBUG: ims_registrar_scscf [save.c:556]: update_contacts_helper(): adding/updating contact based on prior existence Jul 24 07:22:21 scscf scscfXXXYYY-ecs[798]: 15(20) DEBUG: ims_usrloc_scscf [impurecord.c:748]: get_scontact(): looking for contact [sip:XXXYY8000099992@10.110.1.71:5060;alias=10.110 Jul 24 07:22:21 scscf scscfXXXYYY-ecs[798]: 15(20) DEBUG: ims_registrar_scscf [save.c:562]: update_contacts_helper(): inserting new contact Jul 24 07:22:21 scscf scscfXXXYYY-ecs[798]: 15(20) DEBUG: ims_usrloc_scscf [impurecord.c:562]: insert_scontact(): INSERTing ucontact in usrloc module Jul 24 07:22:21 scscf kernel: traps: kamailio[7186] general protection ip:7f7146511000 sp:7ffc9f3719a0 error:0 in ims_usrloc_scscf.so[7f71464e7000+8f000] ``` #### SIP Traffic ![image](https://user-images.githubusercontent.com/1636682/43138556-8dc89988-8f4f-11e8-887a-53c4fb7805e1.png) ``` (paste your sip traffic here) ``` ### Possible Solutions ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.1.4 (x86_64/linux) ``` * **Operating System**: ``` Linux scscf 4.14.48-coreos-r2 #1 SMP Thu Jun 14 08:23:03 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux ``` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/1600

2 4

← Newer
1
...
5
6
7
8
9
10
11
...
23
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev July 2018