sr-users October 2018

sr-users@lists.kamailio.org

81 participants
121 discussions

DTLS HA redis-pacemaker-corosync
by Жан Базаров 10 Dec '18

10 Dec '18

Hello! Are there any ways to implement using DTLS in redis HA scenario? When I reboot the active RTPEngine server the system correctly fails over to the other server and, after only a small pause (~1s), incoming audio continues to arrive. However, approximately 15 seconds after this I hear nothing but silence. Thanks.

2 1

[CFP] FOSDEM 2019, RTC devroom, speakers, volunteers neeeded
by FOSDEM RTC Team 28 Nov '18

28 Nov '18

FOSDEM is one of the world's premier meetings of free software developers, with over five thousand people attending each year. FOSDEM 2019 takes place 2-3 February 2019 in Brussels, Belgium. https://fosdem.org This email contains information about: - Real-Time Communications dev-room and lounge, - speaking opportunities, - volunteering in the dev-room and lounge, - social events (the legendary FOSDEM Beer Night and Saturday night dinners provide endless networking opportunities), - the Planet aggregation sites for RTC blogs Call for participation - Real Time Communications (RTC) ======================================================= The Real-Time dev-room and Real-Time lounge is about all things involving real-time communication, including: XMPP, SIP, WebRTC, telephony, mobile VoIP, codecs, peer-to-peer, privacy and encryption. The dev-room is a successor to the previous XMPP and telephony dev-rooms. We are looking for speakers for the dev-room and volunteers and participants for the tables in the Real-Time lounge. The dev-room is only on Sunday, 3rd of February 2019. The lounge will be present for both days. To discuss the dev-room and lounge, please join the Free RTC mailing list: http://lists.freertc.org/mailman/listinfo/discuss To be kept aware of major developments in Free RTC, without being on the discussion list, please join the Free-RTC Announce list: http://lists.freertc.org/mailman/listinfo/announce Speaking opportunities ---------------------- Note: if you used FOSDEM Pentabarf before, please use the same account/username Real-Time Communications dev-room: deadline 23:59 UTC on 2nd of December. Please use the Pentabarf system to submit a talk proposal for the dev-room. On the "General" tab, please look for the "Track" option and choose "Real Time Communications devroom". https://penta.fosdem.org/submission/FOSDEM19/ Other dev-rooms and lightning talks: some speakers may find their topic is in the scope of more than one dev-room. It is encouraged to apply to more than one dev-room and also consider proposing a lightning talk, but please be kind enough to tell us if you do this by filling out the notes in the form. You can find the full list of dev-rooms at https://www.fosdem.org/2019/schedule/tracks/ and apply for a lightning talk at https://fosdem.org/submit Main track: the deadline for main track presentations is 23:59 UTC 3rd of November. Leading developers in the Real-Time Communications field are encouraged to consider submitting a presentation to the main track at https://fosdem.org/submit First-time speaking? -------------------- FOSDEM dev-rooms are a welcoming environment for people who have never given a talk before. Please feel free to contact the dev-room administrators personally if you would like to ask any questions about it. Submission guidelines --------------------- The Pentabarf system will ask for many of the essential details. Please remember to re-use your account from previous years if you have one. In the "Submission notes", please tell us about: - the purpose of your talk - any other talk applications (dev-rooms, lightning talks, main track) - availability constraints and special needs You can use HTML and links in your bio, abstract and description. If you maintain a blog, please consider providing us with the URL of a feed with posts tagged for your RTC-related work. We will be looking for relevance to the conference and dev-room themes, presentations aimed at developers of free and open source software about RTC-related topics. Please feel free to suggest a duration between 20 minutes and 55 minutes but note that the final decision on talk durations will be made by the dev-room administrators based on the number of received proposals. As the two previous dev-rooms have been combined into one, we may decide to give shorter slots than in previous years so that more speakers can participate. Please note FOSDEM aims to record and live-stream all talks. The CC-BY license is used. Volunteers needed ================= To make the dev-room and lounge run successfully, we are looking for volunteers: - FOSDEM provides video recording equipment and live streaming, volunteers are needed to assist in this - organizing one or more restaurant bookings (dependending upon number of participants) for the evening of Saturday, 2nd of February - participation in the Real-Time lounge - helping attract sponsorship funds for the dev-room to pay for the Saturday night dinner and any other expenses - circulating this Call for Participation to other mailing lists Social events and dinners ========================= The traditional FOSDEM beer night occurs on Friday, 1st of February. On Saturday night, there are usually dinners associated with each of the dev-rooms. Most restaurants in Brussels are not so large so these dinners have space constraints and reservations are essential. Please subscribe to the Free-RTC mailing list for further details about the Saturday night dinner options and how you can register for a seat: http://lists.freertc.org/mailman/listinfo/discuss Spread the word and discuss =========================== If you know of any mailing lists where this CfP would be relevant, please forward this email. If this dev-room excites you, please blog or microblog about it, especially if you are submitting a talk. If you regularly blog about RTC topics, please send details about your blog to the planet site administrators: All projects http://planet.freertc.org planet(a)freertc.org XMPP http://planet.jabber.org ralphm(a)ik.nu SIP http://planet.sip5060.net planet(a)sip5060.net (Español) http://planet.sip5060.net/es/ planet(a)sip5060.net Please also link to the Planet sites from your own blog or web site as this helps everybody in the free real-time communications community. Contact ======= For any private queries, contact us directly using the address fosdem-rtc-admin(a)freertc.org and for any other queries please ask on the Free-RTC mailing list: http://lists.freertc.org/mailman/listinfo/discuss The dev-room administration team: Saúl Ibarra Corretgé <s(a)saghul.net> Ralph Meijer <ralphm(a)ik.nu> Daniel-Constantin Mierla <miconda(a)gmail.com> Daniel Pocock <daniel(a)pocock.pro> Guus der Kinderen <guus.der.kinderen(a)gmail.com>

2 1

RTPengine: shouldn't SDP <sess-version> be incremented when SDP is updated in-dialog?
by George Diamantopoulos 20 Nov '18

20 Nov '18

Hello all, I have the following issue (I think) with RTP engine. An INVITE comes in, and rtpengine will rewrite the SDP accordingly, as configured in kamailio.cfg. After some time a reINVITE is sent out in the opposite direction, for session refresh purposes. As I use rtcp-mux-offer in kamailio.cfg for this direction, RTPengine will inject the rtcp-mux parameter, and this reINVITE is forwarded to the UAC that sent the original INVITE. However, the SDP in the reINVITE is exactly the same as the SDP in the 200 OK to the original INVITE, with the exception of the rtcp-mux parameter. Since the SDP offered from the same end has changed, shouldn't session version be incremented as well? Does this sound like something that should be reported as a bug to rtpengine? Or am I missing something here? Thanks! Best regards, George Diamantopoulos

3 4

siptrace module doesn't close db connections
by Roman Dissauer 12 Nov '18

12 Nov '18

Hi, it seems that siptrace module doesn’t close db connections. I’m on Kamailio 5.1.4 from official debian stretch repository with postgresql db module enabled. siptrace config: modparam("siptrace", "db_url", DBURL) modparam("siptrace", "duplicate_uri", "sip:193.32.51.189:9060") modparam("siptrace", "hep_mode_on", 1) modparam("siptrace", "hep_version", 3) modparam("siptrace", "hep_capture_id", 1001) modparam("siptrace", "trace_mode", 1) Here you can see the open connections from the kamailio host: # select client_addr, state, query from pg_stat_activity where client_addr = '10.23.101.61'; client_addr | state | query --------------+-------+---------------------------------------------------------------- 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' (31 Zeilen) another example, other installation with same kamailio version 5.1.4: # select client_addr, state, query from pg_stat_activity where client_addr = '10.23.102.1'; client_addr | state | query -------------+-------+---------------------------------------------------------------- 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' (39 Zeilen) Thanks Roman

2 2

Crash ims_diameter_server
by Iman Mohammadi 03 Nov '18

03 Nov '18

When the below format is sent from rest , kamailio crashes List[{ List[{ List[{ ]} ]} ]} (Json with 3 nested lists), With 2 lists it works properly, When diameter is translated to json with 3 lists by this module it also works properly, Json format is correct too. gdb: gdb) bt full #0 0x00007f5e23c4a11e in diameterserver_add_avp (m=0x0, d=0x7f5e1b5c2240 "", len=12, avp_code=431, flags=64, vendorid=0, data_do=2, func=0x7f5e23c51d6c <__FUNCTION__.20148> "parselist") at avp_helper.c:208 avp = 0x7f5e1b5c3bd0 __FUNCTION__ = "diameterserver_add_avp" #1 0x00007f5e23c4d0c8 in parselist (response=0x0, list=0x7fff9f21a8d0, item=0x11b67d0, level=2) at avp_helper.c:309 i = 1 flags = 64 x = "p\250!\237" avp_list = {head = 0x0, tail = 0x0} avp_list_s = {s = 0x7f5e1b5c2240 "", len = 12} __FUNCTION__ = "parselist" #2 0x00007f5e23c4cffc in parselist (response=0x7f5e1b5c3ab8, list=0x0, item=0x11b6550, level=1) at avp_helper.c:304 subitem = 0x11b67d0 i = 0 flags = 64 x = "\000\000\000" avp_list = {head = 0x0, tail = 0x0} avp_list_s = {s = 0x7fff9f21a8f0 "@\251!\237\377\177", len = 600070897} __FUNCTION__ = "parselist" #3 0x00007f5e23c4db3a in addAVPsfromJSON (response=0x7f5e1b5c3ab8, json=0x7f5e23e53950 <responsejson>) at avp_helper.c:349 subitem = 0x11b6550 i = 4 __FUNCTION__ = "addAVPsfromJSON" root = 0x11b4210 #4 0x00007f5e23c3fbdb in callback_cdp_request (request_in=0x7f5e1b5c19b0, param=0x0) at ims_diameter_server.c:193 fmsg = 0xab7840 <_faked_msg> backup_rt = 1 ctx = {rec_lev = 0, run_flags = 0, last_retcode = 1, jmp_env = {{__jmpbuf = {1, -5713032302318786866, 7971288, 7971288, 140042162528420, 0, -5713032302339758386, 5712822384154044110}, __mask_was_saved = 0, __saved_mask = {__val = { 140735863172072, 127, 0, 140042162532340, 140042389578761, 4222451713, 140042162532340, 140042162532340, 140042162532340, 140042162532340, 140042162532358, 140042162532467, 140042162532340, 140042162532467, 0, 0}}}}} response = 0x7f5e1b5c3ab8 __FUNCTION__ = "callback_cdp_request" #5 0x00007f5e24a705c0 in api_callback (p=0x7f5e1b598f50, msg=0x7f5e1b5c19b0, ptr=0x0) at api_process.c:83 t = 0x7f5e1b598f50 auto_drop = 32767 h = 0x7f5e1b5b3358 ---Type <return> to continue, or q <return> to quit--- x = {type = (unknown: 2669784000), handler = {requestHandler = 0x7f5e23c3eed1 <callback_cdp_request>, responseHandler = 0x7f5e23c3eed1 <callback_cdp_request>}, param = 0x3ee9f21ac10, next = 0x7f5e1b5988b8, prev = 0x19f210069} type = REQUEST_HANDLER rsp = 0x7f5e1b5c19b0 __FUNCTION__ = "api_callback" #6 0x00007f5e24a857d7 in worker_process (id=5) at worker.c:346 t = {p = 0x7f5e1b598f50, msg = 0x7f5e1b5c19b0} cb = 0x7f5e1b59df30 r = 128 __FUNCTION__ = "worker_process" #7 0x00007f5e24a62a8e in diameter_peer_start (blocking=0) at diameter_peer.c:242 pid = 0 k = 5 p = 0x36 __FUNCTION__ = "diameter_peer_start" #8 0x00007f5e24a559bc in cdp_child_init (rank=0) at cdp_mod.c:243 __FUNCTION__ = "cdp_child_init" #9 0x0000000000547e54 in init_mod_child (m=0x7f5e28656fb8, rank=0) at core/sr_module.c:943 __FUNCTION__ = "init_mod_child" #10 0x0000000000547b16 in init_mod_child (m=0x7f5e28657c38, rank=0) at core/sr_module.c:939 __FUNCTION__ = "init_mod_child" #11 0x0000000000547b16 in init_mod_child (m=0x7f5e28658010, rank=0) at core/sr_module.c:939 __FUNCTION__ = "init_mod_child" #12 0x0000000000547b16 in init_mod_child (m=0x7f5e28658790, rank=0) at core/sr_module.c:939 __FUNCTION__ = "init_mod_child" #13 0x0000000000547b16 in init_mod_child (m=0x7f5e28658d68, rank=0) at core/sr_module.c:939 __FUNCTION__ = "init_mod_child" #14 0x00000000005481e6 in init_child (rank=0) at core/sr_module.c:970 No locals. #15 0x00000000004250f5 in main_loop () at main.c:1701 i = 8 pid = 1964 si = 0x0 si_desc = "udp receiver child=7 sock=10.25.5.23:5060\000y\000\000\000\000\000x\333i(^\177\000\000@\264!\237\377\177", '\000' <repeats 18 times>, "`\263!\237\377\177\000\000\347L\340(^\177\000\000\360\260!\237\377\177\000\000\060\000\000\000\060\000\000\000\260\261!\237\377\177\000\000\350\226i(^\177\000" nrprocs = 8 ---Type <return> to continue, or q <return> to quit--- woneinit = 1 __FUNCTION__ = "main_loop" #16 0x000000000042b99b in main (argc=13, argv=0x7fff9f21b448) at main.c:2638 cfg_stream = 0x111c020 c = -1 r = 0 tmp = 0x7fff9f21bf69 "" tmp_len = 32606 port = 693647725 proto = 0 options = 0x74cd90 ":f:cm:M:dVIhEeb:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:x:X:Y:" ret = -1 seed = 898203166 rfd = 4 debug_save = 0 debug_flag = 0 dont_fork_cnt = 0 n_lst = 0x7fff9f21b300 p = 0x7fff9f21b4b8 "\207\277!\237\377\177" st = {st_dev = 15, st_ino = 13240, st_nlink = 2, st_mode = 16877, st_uid = 110, st_gid = 116, __pad0 = 0, st_rdev = 0, st_size = 60, st_blksize = 4096, st_blocks = 0, st_atim = {tv_sec = 1540797448, tv_nsec = 544589798}, st_mtim = {tv_sec = 1540797905, tv_nsec = 662909589}, st_ctim = {tv_sec = 1540798045, tv_nsec = 563947001}, __glibc_reserved = {0, 0, 0}} __FUNCTION__ = "main" (gdb) (gdb) Where is problem? Thanks

3 4

Store TLS handshake date from Kamailio to an external DB
by Toffi Bossol 02 Nov '18

02 Nov '18

Dear community, I am new in Kamailio hence the following question: Does any one know how to tell Kamailio to store the TLS session data in an external DB? Many Thanks in advance! BR; Toffi

3 7

Parse Header error when send Register to P-CSCF using ims-pcscf
by Hưng Nguyễn Tiến 02 Nov '18

02 Nov '18

Hi, i'm newbie in kamailio, I tried installed ims kamailio from ng-repository packages, Then when I tried to send register to SIP server using SIPp, I received this log [Proxy-CSCF][28505]: ERROR: <core> [core/parser/msg_parser.c:331]: parse_headers(): bad header field [(null)] [Proxy-CSCF][28500]: ERROR: <core> [core/parser/msg_parser.c:331]: parse_headers(): bad header field [(null)] [Proxy-CSCF][28496]: WARNING: <core> [core/receive.c:192]: receive_msg(): parsing relevant headers failed [Proxy-CSCF][28505]: message repeated 2 times: [ WARNING: <core> [core/receive.c:192]: receive_msg(): parsing relevant headers failed] [Proxy-CSCF][28492]: ERROR: <core> [core/parser/msg_parser.c:675]: parse_msg(): ERROR: parse_msg: message=<#002#020#002#021#023�#023��z'��z'#006��[%�#007> Thank you -- Nguyễn Tiến Hưng

2 1

Diversion headers access and message too long error
by Joan Salvatella 01 Nov '18

01 Nov '18

Hello, We are working on a project that's using a Twilio SIP trunk that diverts calls from the PSTN to our cluster that is hosting two active-active Kamailio 5.1 instances that redirect traffic to several Asterisk 15.4 instances. On this setup we are facing 2 issues: - *Diversion headers access: *Currently, Kamailio only supports access to the last diversion header but since we are receiving traffic from Twilio (it sets the last Diversion header) we are unable to see if the caller was diverted to our SIP trunk. Is there a workaround for this? Any external module that would support this use case? - *Message Too Long Error:* Since Twilio uses long URIs to define its resources, the SIP messages being handled by Kamailio are sometimes too big and generate a "Message Too Long error". I have been able to temporarily patch this removing unused headers using remove_hf_re and remove_hf but it still fails from time to time. Is there a way to split the UDP packet to mitigate this issue? or what other options could be considered? Thanks and regards,

3 5

Topos on high load
by Igor Olhovskiy 01 Nov '18

01 Nov '18

Hi! We’ve run into really interesting issue while testing Kamailio with sipp (15 CPS, 300 calls - 1 failed call, more CPS - more failed calls) with topos involved. And at some point Kamailio starts to send 2 packets on received INVITE. 1 - with topos applied, 1 - with not. Main problem is to collect logs at this point, cause load is really high. Is it possible some internal race condition while topos involved? PCAP is attached. I’ve made a picture to illustrate a bit an issue Regards, Igor

2 2

Determine destination address family
by Isaac 31 Oct '18

31 Oct '18

Hello, How can I determine the address family (IPv6 or IPv4) of a destination? The destination in this case is a hostname. I'd like to set a flag if the destination is IPv6 but not sure how to go about it. Thanks, Isaac

2 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users October 2018