sr-dev July 2015

sr-dev@lists.kamailio.org

26 participants
302 discussions

[kamailio] Added modparam id_in_avp for carrierroute (#221)
by Thomas Boros 19 Jan '16

19 Jan '16

We have 2M lines in carrierroute, so we often need to get back the ID of the line from the DB from carrierroute. This commit creates a new modparam "id_in_avp" for the module carrierroute which may be 0 - 2 0 - no ID, only the description is saved in the avp 1 - ID and descrptiotion is saved in the AVP 2 - Only ID is saved in the AVP. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/221 -- Commit Summary -- * Added modparam id_in_avp for carrierroute so the ID may be returned to the AVP variable for easier debugging -- File Changes -- M modules/carrierroute/carrierroute.c (7) M modules/carrierroute/cr_db.c (61) -- Patch Links -- https://github.com/kamailio/kamailio/pull/221.patch https://github.com/kamailio/kamailio/pull/221.diff --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/221

2 10

[kamailio] Textops and Multipart Body - adding ISUP segfaults Kamailio (#240)
by andreikabeliy 12 Dec '15

12 Dec '15

Hi, I am using Kamailio version: kamailio 4.3.0 (x86_64/linux) c6aa95 on CentOS 6 I am trying to encapsulate ISUP in the INVITE: ``` ... if(has_body("application/sdp")) { set_body_multipart(); if(msg_apply_changes()) { $var(isup) = "7e Od 04 55 75 69 20 4d 61 6b 65 43 61 6c 6c"; append_body_part("$var(isup)","application/isup; version=itu-t92+","signal; handling=optional"); xlog("L_INFO", "ISUP Changes Applied Succesfully"); } } ds_select_dst("2","8"); ... ``` And getting the following error: ``` kamailio: DEBUG: <core> [msg_translator.c:1691]: get_boundary(): boundary is <--unique-boundary-1> ... kamailio: DEBUG: <core> [msg_translator.c:1808]: check_boundaries(): last bondary without -- at the end kamailio: DEBUG: <core> [msg_translator.c:1612]: replace_body(): old size body[365] actual[534] kamailio: CRITICAL: <core> [data_lump.c:463]: free_lump(): non free-able lump: 0x7f7a33d5ae40 flags=1 ``` and then Kamailio crashes. DEBUG: ``` Jul 9 15:21:56 kamailiohost kamailio: DEBUG: <core> [msg_translator.c:1808]: check_boundaries(): last bondary without -- at the end Jul 9 15:21:56 kamailiohost kamailio: DEBUG: <core> [msg_translator.c:1612]: replace_body(): old size body[365] actual[513] Jul 9 15:21:56 kamailiohost kamailio: CRITICAL: <core> [data_lump.c:463]: free_lump(): non free-able lump: 0x7fc340edc270 flags=1 ``` Can you please recommend? p.s. as per: http://lists.sip-router.org/pipermail/sr-users/2015-July/089018.html Thanks, Andrei --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/240

4 22

[kamailio] app_python: Missing documentation (#249)
by Olle E. Johansson 03 Dec '15

03 Dec '15

The App_python README has too many sections with just "TBD" as documentation. Needs to be fixed. http://kamailio.org/docs/modules/4.3.x/modules/app_python.html --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/249

3 4

[kamailio] Adding publish in registration functionality, sending "closed" NOTIFY when presense has expired (#177)
by barabasp 20 Nov '15

20 Nov '15

The commit contains pua_usrloc modifications, which simplifies the publish and regisration processes: in every REGISTER an implicit publish is built in. In this way, a device e.g. do not need to send two individual request towards kamailio (REGISTER, PUBLISH), it can be achieved in a single but extended REGISTER request. Another small fix is that if the publication is expired (due to broken TCP e.g.), a "closed" NOTIFY should be sent to the contacts. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/177 -- Commit Summary -- * Adding publish in registration functionality -- File Changes -- M modules/pua_usrloc/pua_usrloc.c (4) M modules/pua_usrloc/ul_publish.c (152) -- Patch Links -- https://github.com/kamailio/kamailio/pull/177.patch https://github.com/kamailio/kamailio/pull/177.diff --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/177

2 7

[kamailio] kex: per module memory debugging (#225)
by Stefan Mititelu 02 Nov '15

02 Nov '15

Kex module updated to also give some details about memory used by each module. Changed f_*, q_* and tlsf_* memory stubs to also include the module name. Added 2 new memory API functions(for each of the memory algos) which will iterate throughout the memory fragments and agregate the memory size used by each function in order to print it. Tested with MEMMNG=0,1,2 and MEMDBG=0,1. Use "kamcmd mem.stat mod_name pkg/shm/all" to test Updated doku. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/225 -- Commit Summary -- * kex: per module memory debugging -- File Changes -- M events.c (25) M events.h (4) M mem/f_malloc.c (135) M mem/f_malloc.h (47) M mem/mem.h (32) M mem/q_malloc.c (113) M mem/q_malloc.h (40) M mem/shm_mem.c (4) M mem/shm_mem.h (32) M mem/src_loc.h (2) M mem/tlsf.c (105) M mem/tlsf.h (32) M modules/ctl/binrpc_run.c (12) M modules/kex/doc/kex_admin.xml (76) M modules/kex/kex_mod.c (7) A modules/kex/mod_stats.c (288) A modules/kex/mod_stats.h (37) -- Patch Links -- https://github.com/kamailio/kamailio/pull/225.patch https://github.com/kamailio/kamailio/pull/225.diff --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/225

2 11

[kamailio] Proposed: Consolidate example kamailio.cfg files (#209)
by tuxd00d 20 Oct '15

20 Oct '15

- There are relatively few differences between the example configuration files. - The time needed to maintain three separate files doesn't match the benefit. - The power of the #!define and #!ifdef system negates the need for separate examples. - It is simple enough to remove #!ifdef sections if one wishes to slim down the file size. - I'll do a consolidation if no valid argument against it is raised. --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/209

3 6

[kamailio] UAC module - registration stuck in ONGOING state (does not retry) (#255)
by AndyJRobinson 14 Sep '15

14 Sep '15

I was finally able to catch an occurrence of the issue where a registration was getting stuck in the ONGOING state and not being retried. This is with 4.3.0. Here's an example of a successful registration from the logs: Sat Jul 18 23:03:40 2015 local0.debug /usr/sbin/kamailio[25189]: DEBUG: tm [uac.c:249]: t_uac_prepare(): DEBUG:tm:t_uac: next_hop=<sip:callcentric.com> Sat Jul 18 23:03:40 2015 local0.debug /usr/sbin/kamailio[25189]: DEBUG: <core> [dns_cache.c:537]: _dns_hash_find(): (_sip._udp.callcentric.com(25), 33), h=428 Sat Jul 18 23:03:40 2015 local0.debug /usr/sbin/kamailio[25189]: DEBUG: <core> [dns_cache.c:537]: _dns_hash_find(): (alpha19.callcentric.com(23), 1), h=201 Sat Jul 18 23:03:40 2015 local0.debug /usr/sbin/kamailio[25189]: DEBUG: <core> [forward.c:174]: get_out_socket(): socket determined: 0x7751b8e4 Sat Jul 18 23:03:40 2015 local0.debug /usr/sbin/kamailio[25189]: DEBUG: tm [uac.c:150]: dlg2hash(): DEBUG: dlg2hash: 42513 Sat Jul 18 23:03:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [parser/msg_parser.c:616]: parse_msg(): SIP Reply (status): Sat Jul 18 23:03:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [parser/msg_parser.c:618]: parse_msg(): version: <SIP/2.0> Sat Jul 18 23:03:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [parser/msg_parser.c:620]: parse_msg(): status: <407> Sat Jul 18 23:03:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [parser/msg_parser.c:622]: parse_msg(): reason: <Proxy Authentication Required> Sat Jul 18 23:03:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [parser/parse_via.c:1254]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK116a.65ec1863000000000000000000000000.0>; state=16 Sat Jul 18 23:03:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [parser/parse_via.c:2642]: parse_via(): end of header reached, state=5 Sat Jul 18 23:03:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [parser/msg_parser.c:496]: parse_headers(): parse_headers: Via found, flags=2 Sat Jul 18 23:03:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [parser/msg_parser.c:498]: parse_headers(): parse_headers: this is the first via Sat Jul 18 23:03:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [receive.c:134]: receive_msg(): After parse_msg... Sat Jul 18 23:03:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: tm [t_lookup.c:1011]: t_check_msg(): DEBUG: t_check_msg: msg id=16741 global id=16740 T start=0xffffffff Sat Jul 18 23:03:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [parser/parse_addr_spec.c:894]: parse_addr_spec(): end of header reached, state=10 Sat Jul 18 23:03:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: uac [auth_hdr.c:402]: build_authorization_hdr(): hdr is <Proxy-Authorization: Digest username="removed", realm="callcentric.com", nonce="75a3bdc28a8d7f8bd7531ec41ac9ea25", uri="sip:callcentric.com", response="f8dc5c3d85280da5972c1a7ef0b53f08", algorithm=MD5 Sat Jul 18 23:03:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [parser/parse_addr_spec.c:172]: parse_to_param(): DEBUG: add_param: tag=2afe4db221460197112d59bc9a08ee82-bb3d Sat Jul 18 23:03:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [parser/parse_addr_spec.c:894]: parse_addr_spec(): end of header reached, state=29 Sat Jul 18 23:03:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: tm [uac.c:249]: t_uac_prepare(): DEBUG:tm:t_uac: next_hop=<sip:callcentric.com> Sat Jul 18 23:03:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [dns_cache.c:537]: _dns_hash_find(): (_sip._udp.callcentric.com(25), 33), h=428 Sat Jul 18 23:03:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [dns_cache.c:537]: _dns_hash_find(): (alpha19.callcentric.com(23), 1), h=201 Sat Jul 18 23:03:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [forward.c:174]: get_out_socket(): socket determined: 0x7751b8e4 Sat Jul 18 23:03:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: tm [uac.c:150]: dlg2hash(): DEBUG: dlg2hash: 42514 Sat Jul 18 23:03:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: tm [t_reply.c:1589]: cleanup_uac_timers(): DEBUG: cleanup_uac_timers: RETR/FR timers reset Sat Jul 18 23:03:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil) Sat Jul 18 23:03:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil) Sat Jul 18 23:03:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil) Sat Jul 18 23:03:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil) Sat Jul 18 23:03:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil) Sat Jul 18 23:03:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil) Sat Jul 18 23:03:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [xavp.c:446]: xavp_destroy_list(): destroying xavp list (nil) Sat Jul 18 23:03:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [receive.c:278]: receive_msg(): cleaning up Sat Jul 18 23:03:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [parser/msg_parser.c:616]: parse_msg(): SIP Reply (status): Sat Jul 18 23:03:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [parser/msg_parser.c:618]: parse_msg(): version: <SIP/2.0> Sat Jul 18 23:03:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [parser/msg_parser.c:620]: parse_msg(): status: <200> Sat Jul 18 23:03:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [parser/msg_parser.c:622]: parse_msg(): reason: <Ok> Sat Jul 18 23:03:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [parser/parse_via.c:1254]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK216a.928c6026000000000000000000000000.0>; state=16 Sat Jul 18 23:03:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [parser/parse_via.c:2642]: parse_via(): end of header reached, state=5 Sat Jul 18 23:03:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [parser/msg_parser.c:496]: parse_headers(): parse_headers: Via found, flags=2 Sat Jul 18 23:03:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [parser/msg_parser.c:498]: parse_headers(): parse_headers: this is the first via Sat Jul 18 23:03:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [receive.c:134]: receive_msg(): After parse_msg... Sat Jul 18 23:03:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: tm [t_lookup.c:1011]: t_check_msg(): DEBUG: t_check_msg: msg id=16742 global id=16741 T start=0xffffffff Sat Jul 18 23:03:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [parser/parse_addr_spec.c:894]: parse_addr_spec(): end of header reached, state=10 Sat Jul 18 23:03:41 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: tm [t_reply.c:2053]: local_reply(): DEBUG: local transaction completed Sat Jul 18 23:03:41 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: tm [t_hooks.c:266]: run_trans_callbacks_internal(): DBG: trans=0x76abc580, callback type 1024, id 0 entered Sat Jul 18 23:03:41 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: uac [uac_reg.c:723]: uac_reg_tm_callback(): completed with status 200 [uuid: removed+uac] Sat Jul 18 23:03:41 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [parser/msg_parser.c:187]: get_hdr_field(): DEBUG: get_hdr_body : content_length=0 Sat Jul 18 23:03:41 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [parser/msg_parser.c:89]: get_hdr_field(): found end of header Sat Jul 18 23:03:41 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: tm [t_reply.c:1589]: cleanup_uac_timers(): DEBUG: cleanup_uac_timers: RETR/FR timers reset Sat Jul 18 23:03:41 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil) Sat Jul 18 23:03:41 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil) Sat Jul 18 23:03:41 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil) Sat Jul 18 23:03:41 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil) Sat Jul 18 23:03:41 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil) Here's where the registration got stuck (I added the "ONGOING flag still set" message myself to help capture when this occurred). I see the 200 Ok response to the REGISTER with the Proxy-Authorization header, but don't see uac_reg_tm_callback being invoked. Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25189]: DEBUG: tm [uac.c:249]: t_uac_prepare(): DEBUG:tm:t_uac: next_hop=<sip:callcentric.com> Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25189]: DEBUG: <core> [dns_cache.c:537]: _dns_hash_find(): (_sip._udp.callcentric.com(25), 33), h=428 Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25189]: DEBUG: <core> [dns_cache.c:537]: _dns_hash_find(): (alpha17.callcentric.com(23), 1), h=135 Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25189]: DEBUG: <core> [forward.c:174]: get_out_socket(): socket determined: 0x7751b8e4 Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25189]: DEBUG: tm [uac.c:150]: dlg2hash(): DEBUG: dlg2hash: 42871 Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [parser/msg_parser.c:616]: parse_msg(): SIP Reply (status): Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [parser/msg_parser.c:618]: parse_msg(): version: <SIP/2.0> Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [parser/msg_parser.c:620]: parse_msg(): status: <407> Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [parser/msg_parser.c:622]: parse_msg(): reason: <Proxy Authentication Required> Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [parser/parse_via.c:1254]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK777a.be9fe760000000000000000000000000.0>; state=16 Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [parser/parse_via.c:2642]: parse_via(): end of header reached, state=5 Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [parser/msg_parser.c:496]: parse_headers(): parse_headers: Via found, flags=2 Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [parser/msg_parser.c:498]: parse_headers(): parse_headers: this is the first via Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [receive.c:134]: receive_msg(): After parse_msg... Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: tm [t_lookup.c:1011]: t_check_msg(): DEBUG: t_check_msg: msg id=16764 global id=16763 T start=0xffffffff Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [parser/parse_addr_spec.c:894]: parse_addr_spec(): end of header reached, state=10 Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: uac [auth_hdr.c:203]: parse_authenticate_body(): <stale>="TRUE" state=4 Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: uac [auth_hdr.c:203]: parse_authenticate_body(): <algorithm>="MD5" state=7 Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: uac [auth_hdr.c:402]: build_authorization_hdr(): hdr is <Proxy-Authorization: Digest username="removed", realm="callcentric.com", nonce="b281825597a5ca2370701bd5a71d0f7b", uri="sip:callcentric.com", response="eae092a16bc01ac1333d922d088293a5", algorithm=MD5 Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [parser/parse_addr_spec.c:172]: parse_to_param(): DEBUG: add_param: tag=2afe4db221460197112d59bc9a08ee82-5239 Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [parser/parse_addr_spec.c:894]: parse_addr_spec(): end of header reached, state=29 Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: tm [uac.c:249]: t_uac_prepare(): DEBUG:tm:t_uac: next_hop=<sip:callcentric.com> Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [dns_cache.c:537]: _dns_hash_find(): (_sip._udp.callcentric.com(25), 33), h=428 Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [dns_cache.c:537]: _dns_hash_find(): (alpha17.callcentric.com(23), 1), h=135 Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [forward.c:174]: get_out_socket(): socket determined: 0x7751b8e4 Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: tm [uac.c:150]: dlg2hash(): DEBUG: dlg2hash: 42872 Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: tm [t_reply.c:1589]: cleanup_uac_timers(): DEBUG: cleanup_uac_timers: RETR/FR timers reset Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil) Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil) Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil) Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil) Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil) Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil) Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [xavp.c:446]: xavp_destroy_list(): destroying xavp list (nil) Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [receive.c:278]: receive_msg(): cleaning up Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [parser/msg_parser.c:616]: parse_msg(): SIP Reply (status): Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [parser/msg_parser.c:618]: parse_msg(): version: <SIP/2.0> Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [parser/msg_parser.c:620]: parse_msg(): status: <200> Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [parser/msg_parser.c:622]: parse_msg(): reason: <Ok> Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [parser/parse_via.c:1254]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK877a.1f487c81000000000000000000000000.0>; state=16 Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [parser/parse_via.c:2642]: parse_via(): end of header reached, state=5 Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [parser/msg_parser.c:496]: parse_headers(): parse_headers: Via found, flags=2 Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [parser/msg_parser.c:498]: parse_headers(): parse_headers: this is the first via Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [receive.c:134]: receive_msg(): After parse_msg... Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: tm [t_lookup.c:1011]: t_check_msg(): DEBUG: t_check_msg: msg id=16765 global id=16764 T start=0xffffffff Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [parser/parse_addr_spec.c:894]: parse_addr_spec(): end of header reached, state=10 Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [parser/msg_parser.c:173]: get_hdr_field(): DEBUG: get_hdr_field: <t> [35]; uri=[sip:removed@callcentric.com] Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [parser/msg_parser.c:175]: get_hdr_field(): DEBUG: to body [<sip:removed@callcentric.com> Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [parser/msg_parser.c:153]: get_hdr_field(): get_hdr_field: cseq <CSeq>: <11> <REGISTER> Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: tm [t_lookup.c:888]: t_reply_matching(): DEBUG: t_reply_matching: hash 42872 label 0 branch 0 Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: tm [t_lookup.c:943]: t_reply_matching(): DEBUG: t_reply_matching: reply matched (T=0x76abc580)! Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: tm [t_lookup.c:1080]: t_check_msg(): DEBUG: t_check_msg: msg id=16765 global id=16765 T end=0x76abc580 Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: tm [t_reply.c:2136]: reply_received(): DEBUG: reply_received: org. status uas=0, uac[0]=0 local=2 is_invite=0) Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: tm [t_reply.c:1230]: t_should_relay_response(): ->>>>>>>>> T_code=0, new_code=200 Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: tm [t_reply.c:2016]: local_reply(): DEBUG: local_reply: branch=0, save=0, winner=0 Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: tm [t_reply.c:2053]: local_reply(): DEBUG: local transaction completed Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: tm [t_reply.c:1589]: cleanup_uac_timers(): DEBUG: cleanup_uac_timers: RETR/FR timers reset Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil) Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil) Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil) Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil) Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil) Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil) Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [xavp.c:446]: xavp_destroy_list(): destroying xavp list (nil) Sat Jul 18 23:18:40 2015 local0.debug /usr/sbin/kamailio[25184]: DEBUG: <core> [receive.c:278]: receive_msg(): cleaning up Sat Jul 18 23:24:40 2015 local0.err /usr/sbin/kamailio[25189]: ERROR: uac [uac_reg.c:935]: uac_reg_update(): ONGOING flag still set --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/255

2 12

Re: [sr-dev] Is there a sense in calling run_onsend() after the msg_send() function?
by Lucian Balaceanu 08 Sep '15

08 Sep '15

Hi Daniel, I must admit this run_onsend() patch for stateful replies creation was not quite a success story. However, I think it serves a practical purpose, for example in Homer tracing and could be useful for the community. Again, I propose my past solution, with some questions: 1. I am unsure if the place I introduced the run_onsend call is appropriate since the buf used for msg_send is constructed build_res_buf_from_sip_req and build_res_buf_from_sip_res calls. 2. Also, we can maybe unite these if call branches I created: send_res = msg_send(&uas_rb->dst, buf, res_len); send_res = SEND_PR_BUFFER( uas_rb, buf, res_len ); 3. Do you think a get_send_socket snippet as follows should be inserted before the /*if (onsend_route_enabled(SIP_REPLY)){*/ : if(dst.send_sock == NULL) { dst.send_sock=get_send_socket(msg, &dst.to, dst.proto); if (dst.send_sock==0){ LM_ERR("cannot forward reply\n"); } } Thank you, Lucian On 10/29/2014 02:15 PM, Daniel-Constantin Mierla wrote: > Hello Lucian, > > I applied your patch with some fixes. > > I haven't checked with stateful replies, at some point a function from > core should be used. You can go ahead and see if it works, if not, let > me know and I can look into it as well. You can follow the callbacks > for TMCB_RESPONSE_OUT or TMCB_RESPONSE_FWDED inside tm code, they > should lead to the place where a sip response is going to be sent out. > > Cheers, > Daniel > > On 27/10/14 12:51, Lucian Balaceanu wrote: >> Hello Daniel, >> >> I must admit I only saw your mail last Friday. Until the 10th of >> October I was also on vacation. I know that you actually committed >> some of the changes together with your comments on the 12th this month. >> >> I don't know if we can consider the topic of the patch closed. As far >> as I understand, the state-full replies have not been addressed, >> right? (There should be a change in the t_reply.c) I followed the >> code to the relay_reply but I did not yet come to find the send >> function. Should I pursue further? >> >> Thank you, >> Lucian Balaceanu >> >>> Hi Lucian, >>> >>> somehow I forgot to follow up on this. But we need to get sorted out >>> soon, before we release, so it works as expected with the new >>> version. See more comments inline. >>> >>> >>> On 17/09/14 18:09, Lucian Balaceanu wrote: >>>> Hi Daniel, >>>> >>>> Please forgive me for my delay in responding to your mail. >>>> Please find attached a second version of the onsend_route_reply >>>> patch (which again has some problems). As per your previous >>>> indications I did the following: >>>> >>>> *Issue1* >>>>> From performances point of view, there can be added a config >>>>> parameter to enable running of onsend_route for replies: >>>>> >>>>> onsend_route_reply = 0|1 >>>> >>>> Following >>>> http://www.asipto.com/pub/kamailio-devel-guide/#c08add_parameters I >>>> have tried to add onsend_route_reply parameter. The code compiles, >>>> but when trying to start kamailio with this parameter inside, the >>>> parsing fails with syntax errors signaling: >>>> >>>> / 0(1321) :<core> [cfg.y:3423]: yyerror_at(): parse error in config >>>> file kamailio-basic.cfg.4.1, from line 107, column 1 to line 108, >>>> column 0: syntax error >>>> 0(1321) : <core> [cfg.y:3423]: yyerror_at(): parse error in config >>>> file kamailio-basic.cfg.4.1, from line 107, column 1 to line 108, >>>> column 0: >>>> ERROR: bad config file (2 errors)/ >>> >>> The issue is: >>> >>> +<INITIAL>{ONSEND_RT_REPLY} { yylval.intval=atoi(yytext); >>> + yy_number_str=yytext; return NUMBER; } >>> >>> It should be: >>> >>> +<INITIAL>{ONSEND_RT_REPLY} { yylval.intval=atoi(yytext); >>> + yy_number_str=yytext; return ONSEND_RT_REPLY; } >>> >>>> >>>> *Issue2* >>>>> #define onsend_enabled(rtype) >>>>> (onsend_rt.rlist[DEFAULT_RT]?((rtype==SIP_REPLY)?onsend_route_reply:1):0) >>>> That is to say you see it best to take the chek for >>>> onsend_rt.list[DEFAULT_RT] from inside run_onsend() function and >>>> call this onsend_enabled(...) before the run_onsend()? >>> >>> This is to detect whether the onsend_route should be executed for >>> SIP replies. The condition being: >>> >>> - if is a sip reply and onsend_route is set and the >>> onsend_route_reply parameter is 1 >>>> >>>> *Issue3* >>>>> On the other hand, is onsend_route also executed for local >>>>> requests? I had in mind it is only for received requests that are >>>>> forwarded ... Iirc, on onsend_route, the sip message is the one >>>>> received, the outgoing content being accessible via $snd(buf). >>>>> >>>> I agree with you with taking out the locally generated requests and >>>> only left the run_onsend call in do_forward_reply function (inside >>>> forward.c). >>>> Could you point me to the reply relaying function that is called >>>> for state-full processing? >>> Stateful processing for replies is mainly done in t_reply.c from tm >>> module. At some point there should be a send buffer function call. >>> >>> Cheers, >>> Daniel >>>> >>>> Thank you and sorry again for my late answer, >>>> Lucian >>> >>> -- >>> Daniel-Constantin Mierla >>> http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda >>> >>> >> > > -- > Daniel-Constantin Mierla > http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda

2 6

[kamailio] kamctl ul show/xmlrpc ul.lookup not find valid AOR (Kamailio v4.3.1) (#264)
by 00Asgaroth00 03 Sep '15

03 Sep '15

For some registered users the kamctl ul show subscriber@domain does not find the AOR, however in a full listing it shows up, the ul.lookup rpc method has the same issue. Kamailio version is 4.3.1 For example, here is a full listing: ``` Domain:: location table=1024 records=4 max_slot=1 AOR:: subscriber1(a)domain.com Contact:: sip:subscriber1@192.168.1.238:32989;alias=212.2.160.202~37476~1;rinstance=5e040b71a89dace0;transport=UDP Q= Expires:: 45 Callid:: Q9tQDalSnHzw78gSlpDC6g.. Cseq:: 783 User-agent:: Z 3.7.30891 r30851 Received:: sip:212.2.160.202:37476 Path:: <sip:10.7.0.109;lr;received=sip:212.2.160.202:37476> State:: CS_NEW Flags:: 0 Cflag:: 64 Socket:: udp:10.7.0.175:5060 Methods:: 5087 Ruid:: uloc-55b11002-2df0-82a2 Reg-Id:: 0 Last-Keepalive:: 1437721166 Last-Modified:: 1437721166 AOR:: subscriber2(a)domain.com Contact:: sip:subscriber2@172.16.0.110:5060;alias=78.143.152.30~21183~1 Q= Expires:: 107 Callid:: 7c5fd25f-c2583f1d63761b4f099e0080f0d14465(a)172.16.0.110 Cseq:: 7 User-agent:: BFH_IE_Panasonic_KX-UT133X/01.278 (0080F0D14465) Received:: sip:78.143.152.30:21183 Path:: <sip:10.7.0.109;lr;received=sip:78.143.152.30:21183> State:: CS_NEW Flags:: 2 Cflag:: 64 Methods:: 6815 Ruid:: uloc-55b10ff9-1f87-45 Reg-Id:: 0 Last-Keepalive:: 1437721228 Last-Modified:: 1437721228 ``` if I lookup subscriber1, then kamctl ul show works: ``` # kamctl ul show subscriber1(a)domain.com Contact:: <sip:subscriber1@192.168.1.238:32989;alias=212.2.160.202~37476~1;rinstance=5e040b71a89dace0;transport=UDP>;q=;expires=21;flags=0x0;cflags=0x40;state=0;socket=<udp:10.7.0.175:5060>;methods=0x13DF;received=<sip:212.2.160.202:37476>;user_agent=<Z 3.7.30891 r30851>;path=<<sip:10.7.0.109;lr;received=sip:212.2.160.202:37476>>;reg-id=0 ``` However, if I lookup sibscriber2, then it cannot find it: ``` # kamctl ul show subscriber2(a)domain.com 404 AOR not found ``` I have masked the subscriber information, but if it is of use for you, I can send the actual data directly to you. --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/264

2 17

[kamailio] core parsing of SIP message failed errors (#107)
by jcohn25 26 Aug '15

26 Aug '15

I finally got everything working but see to consistently receive the following 3 errors (see below) over and over when a call is being collected? Versions: Homer 3.6 kamailio 4.3.0-dev4 Captagent 4.2.0 Any assistance would be appreciated. Errors: Mar 8 22:04:47 ce-homer2 /usr/local/kamailio/sbin/kamailio[9921]: ERROR: <core> [parser/parse_fline.c:257]: parse_first_line(): parse_first_line: bad message (offset: 0) Mar 8 22:04:47 ce-homer2 /usr/local/kamailio/sbin/kamailio[9921]: ERROR: <core> [parser/msg_parser.c:688]: parse_msg(): ERROR: parse_msg: message=<HEP3#004>> Mar 8 22:04:47 ce-homer2 /usr/local/kamailio/sbin/kamailio[9921]: ERROR: <core> [receive.c:129]: receive_msg(): core parsing of SIP message failed (127.0.0.1:33264/1) Mar 8 22:04:47 ce-homer2 /usr/local/kamailio/sbin/kamailio[9922]: ERROR: <core> [parser/parse_fline.c:257]: parse_first_line(): parse_first_line: bad message (offset: 0) Mar 8 22:04:47 ce-homer2 /usr/local/kamailio/sbin/kamailio[9922]: ERROR: <core> [parser/msg_parser.c:688]: parse_msg(): ERROR: parse_msg: message=<HEP3#002Ü> Mar 8 22:04:47 ce-homer2 /usr/local/kamailio/sbin/kamailio[9922]: ERROR: <core> [receive.c:129]: receive_msg(): core parsing of SIP message failed (127.0.0.1:33264/1) --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/107

3 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev July 2015