sr-users October 2017

sr-users@lists.kamailio.org

78 participants
108 discussions

by Andrew Paul

Hi all, We were using kamailio 4.4.5 and we enabled only for webrtc. We were observing two memory crashed in last two weeks. Oct 10 01:03:03 webrtc /usr/sbin/kamailio[18002]: ERROR: <core> [tcp_read.c:1321]: tcp_read_req(): ERROR: tcp_read_req: error reading - c: 0x7f21ea8f6198 r: 0x7f21ea8f6218 Oct 10 01:03:04 webrtc /usr/sbin/kamailio[18003]: ERROR: tls [tls_server.c:190]: tls_complete_init(): tls: ssl bug #1491 workaround: not enough memory for safe operation: shm=9926856 threshold1=9961472 Oct 10 01:03:04 webrtc /usr/sbin/kamailio[18003]: ERROR: <core> [tcp_read.c:1321]: tcp_read_req(): ERROR: tcp_read_req: error reading - c: 0x7f21ea8f6198 r: 0x7f21ea8f6218 Oct 10 01:03:05 webrtc /usr/sbin/kamailio[18004]: ERROR: tls [tls_server.c:190]: tls_complete_init(): tls: ssl bug #1491 workaround: not enough memory for safe operation: shm=9926856 threshold1=9961472 Oct 10 01:03:05 webrtc /usr/sbin/kamailio[18004]: ERROR: <core> [tcp_read.c:1321]: tcp_read_req(): ERROR: tcp_read_req: error reading - c: 0x7f21ea8f6198 r: 0x7f21ea8f6218 Is there any known issue for tls module in kamailio_4.4.5 ?. We are using default 64MB for shared memory and 8MB for private memory. Do we need to increase this ?. Regards Andrew

6 years, 11 months

pua.publish using RPC

by Alex Balashov

Hello, Is pua.publish strictly an MI function, or is it possible nowadays to call it via the RPC channel, and specifically, using jsonrpc_exec()? Thanks! -- Alex -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 (direct) / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

6 years, 11 months

[CFP] FOSDEM 2018, RTC devroom, speakers, volunteers neeeded

by FOSDEM RTC Team

FOSDEM is one of the world's premier meetings of free software developers, with over five thousand people attending each year. FOSDEM 2018 takes place 3-4 February 2018 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, - related events around FOSDEM, including the XMPP summit, - 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, 4th of February 2018. The lounge will be present for both days. To discuss the dev-room and lounge, please join the FSFE-sponsored Free RTC mailing list: https://lists.fsfe.org/mailman/listinfo/free-rtc 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 30th of November. 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/FOSDEM18/ 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/2018/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, 3rd 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 Related events - XMPP and RTC summits ===================================== The XMPP Standards Foundation (XSF) has traditionally held a summit in the days before FOSDEM. There is discussion about a similar summit taking place on the 2nd of February 2018 http://wiki.xmpp.org/web/Summit_22 - please join the mailing list for details: http://mail.jabber.org/mailman/listinfo/summit Social events and dinners ========================= The traditional FOSDEM beer night occurs on Friday, 2nd 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: https://lists.fsfe.org/mailman/listinfo/free-rtc 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: https://lists.fsfe.org/mailman/listinfo/free-rtc The dev-room administration team: Saúl Ibarra Corretgé <saghul(a)gmail.com> Iain R. Learmonth <irl(a)debian.org> Ralph Meijer <ralphm(a)ik.nu> Daniel-Constantin Mierla <miconda(a)gmail.com> Daniel Pocock <daniel(a)pocock.pro>

6 years, 11 months

no event received for call disconnection

by Aleksandar Sosic

Hi Everyone, we're trying to implement cgrates in our kamailio nodes. Everything is working fine except for the fact that kamailio is not signaling the call end to cgrates for prepaid users... The versions, logs and confs are: ``` # kamailio -v version: kamailio 5.0.3 (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 with gcc 5.3.1 ``` ``` # cgr-engine --version CGRateS 0.9.1~rc8 git+15a0793 (2017-10-23T12:15:40+02:00) ``` The kamailio conf regarding our problem is: ``` # Inform CGRateS about CALL_END (stop debit loops, perform accounting if desired in this way) route[CGR_CALL_END] { if $sht(cgrconn=>cgr) == $null { xlog("Charging controller unreachable"); exit; } $var(callDur) = $TS - $dlg(start_ts); evapi_relay("{\"event\":\"CGR_CALL_END\", \"callid\":\"$dlg(callid)\", \"from_tag\":\"$dlg(from_tag)\", \"cgr_reqtype\":\"$dlg_var(cgrReqType)\", \"cgr_tenant\":\"$dlg_var(cgrTenant)\", \"cgr_account\":\"$dlg_var(cgrAccount)\", \"cgr_destination\":\"$dlg_var(cgrDestination)\", \"cgr_answertime\":\"$dlg(start_ts)\", \"cgr_duration\":\"$var(callDur)\", \"cgr_supplier\":\"$dlg_var(cgrSupplier)\", \"cgr_disconnectcause\":\"$T_reply_code\"}"); } ``` The kamailio logs: ``` 17(114) ERROR: evapi [evapi_dispatch.c:707]: _evapi_relay(): failed to pass the pointer to evapi dispatcher 17(114) ERROR: evapi [evapi_mod.c:261]: w_evapi_relay(): failed to relay event: {"event":"CGR_CALL_END", "callid":"6gJ-ynyLm0-vS7StVQA3nMjwJ.YY257z", "from_tag":"Qf6tsQP.Js66FFOdCzv6QlEXomggf3gf", "cgr_reqtype":"*prepaid", "cgr_tenant":"evox.it", "cgr_account":"0409828030", "cgr_destination":"0039040123123", "cgr_answertime":"1509379822", "cgr_duration":"27", "cgr_supplier":"*any", "cgr_disconnectcause":"0"} 17(114) ERROR: evapi [evapi_dispatch.c:707]: _evapi_relay(): failed to pass the pointer to evapi dispatcher 17(114) ERROR: evapi [evapi_mod.c:261]: w_evapi_relay(): failed to relay event: {"event":"CGR_CALL_END", "callid":"6gJ-ynyLm0-vS7StVQA3nMjwJ.YY257z", "from_tag":"Qf6tsQP.Js66FFOdCzv6QlEXomggf3gf", "cgr_reqtype":"*prepaid", "cgr_tenant":"evox.it", "cgr_account":"0409828030", "cgr_destination":"0039040123123", "cgr_answertime":"1509379822", "cgr_duration":"27", "cgr_supplier":"*any", "cgr_disconnectcause":"0"} ``` Thanks for your help, -- Aleksandar Sosic mail: alex.sosic(a)timenet.it skype: alex.sosic cell: +385 91 2505 146

7 years

WebRTC error code 488 in iOS application

by Denys Pozniak

Hello! Probably this case is not connected Kamailio directly, but it can be somebody will point me in the correct direction :) We have VoIP solution: FreeSWITCH -> Kamailio + Rtpengine -> WebRTC Chrome. Everything works Ok except iOS application based on React Native WebRTC ( https://github.com/oney/react-native-webrtc) + JsSIP. It answers error 488 on incoming INVITE (wSDP): INVITE SDP to iOS: *......* *v=0* *o=FreeSWITCH 1508701860 1508701861 IN IP4 52.52.52.52* *s=FreeSWITCH* *c=IN IP4 52.52.52.52* *t=0 0* *m=audio 30028 RTP/SAVPF 0 8 102* *a=rtpmap:0 PCMU/8000* *a=rtpmap:8 PCMA/8000* *a=rtpmap:102 opus/48000/2* *a=fmtp:102 useinbandfec=1; maxaveragebitrate=14400; maxplaybackrate=8000; ptime=20; minptime=10; maxptime=40* *a=ptime:20* *a=sendrecv* *a=rtcp:30028* *a=rtcp-mux* *a=setup:actpass* *a=fingerprint:sha-1 97:1A:E9:FE:D6:65:98:E6:88:EE:D5:9F:20:A3:19:F8:86:E7:E0:E3* *a=ice-ufrag:9QBO8qg2* *a=ice-pwd:PPGPo35xGBAs6RnTdMYVM9I8fx* *a=candidate:KXENzrffZpQvwxdV 1 UDP 2130706431 52.52.52.52 30028 typ host* iOS console log: *11:55:23.670 browser.js:133 JsSIP:WebSocketInterface send() +10ms* *11:55:23.670 browser.js:133 JsSIP:RTCSession session progress +5ms* *11:55:23.671 browser.js:133 JsSIP:RTCSession emit "progress" +1ms* *11:55:23.671 webrtc.js:108 WebRTC.on progress: local* *11:55:23.679 browser.js:133 JsSIP:RTCSession emit "peerconnection" +8ms* *11:55:23.680 webrtc.js:89 WebRTC.on peerconnection* *11:55:23.680 browser.js:133 JsSIP:RTCSession emit "sdp" +1ms* *11:55:23.689 browser.js:133 JsSIP:Transport send() +20ms**11:55:23.689 browser.js:133 JsSIP:Transport sending message:* *SIP/2.0 488 Not Acceptable Here* *11:55:23.701 debug.js:115 JsSIP:ERROR:RTCSession emit "peerconnection:setremotedescriptionfailed" [error:Error: Failed to set remote offer sdp: Failed to create channels.* I found similar issue on thier git https://github.com/oney/react-native-webrtc/issues/293 and main solution is to struct SDP in way like: *a=group:BUNDLE audiom=audio PORT RTP/SAVPF N M Ka=mid:audio* How to modify SDP on Kamailio side (after Rtpengine modification) like below? *v=0* *o=FreeSWITCH 1508701860 1508701861 IN IP4 52.52.52.52* *s=FreeSWITCH* *c=IN IP4 52.52.52.52* *t=0 0* *a=group:BUNDLE audio* *m=audio 30028 RTP/SAVPF 0 8 102* *a=rtpmap:0 PCMU/8000* *a=rtpmap:8 PCMA/8000* *a=rtpmap:102 opus/48000/2* *a=fmtp:102 useinbandfec=1; maxaveragebitrate=14400; maxplaybackrate=8000; ptime=20; minptime=10; maxptime=40* *a=ptime:20* *a=sendrecv* *a=rtcp:30028* *a=rtcp-mux* *a=setup:actpass* *a=mid:audio* *a=fingerprint:sha-1 97:1A:E9:FE:D6:65:98:E6:88:EE:D5:9F:20:A3:19:F8:86:E7:E0:E3* *a=ice-ufrag:9QBO8qg2* *a=ice-pwd:PPGPo35xGBAs6RnTdMYVM9I8fx* *a=candidate:KXENzrffZpQvwxdV 1 UDP 2130706431 52.52.52.52 30028 typ host* BR, Denys

7 years

Mutual TLS with Skype for Business 2015

by Francisco Valentin Vinagrero

Hello, I'm trying to replace two old Audiocodes gateways (used to interconnect our Skype for Business infrastructure to the PSTN) with a new Kamailio cluster. I am having some trouble to get the TLS mutual authentication working with Kamailio. For the moment, I'm just trying to receive the incoming OPTIONS from SfB, but I get all the time certificate verification errors: ERROR: tls [tls_util.h:42]: tls_err_ret(): TLS accept:error:14089086:SSL routines:ssl3_get_client_certificate:certificate verify failed ERROR: <core> [tcp_read.c:1330]: tcp_read_req(): ERROR: tcp_read_req: error reading My tls.cfg is quite simple, with the same config for client and server (and one single listen=tls:<my IP>:5061 in the Kamailio.cfg file) [server:default] method = TLSv1+ verify_certificate = yes require_certificate = yes private_key = /usr/local/etc/kamailio/tls/key_gw_sfb.pem certificate = /usr/local/etc/kamailio/tls/cert_gw_sfb.pem # => This certificate's Subject is the DNS alias for the cluster, with all the kamailios in the cluster as Subject Alternative Names ca_list = /usr/local/etc/kamailio/tls/myca_and_sfbca.pem # => Kamailio and Skype for Business are signed by different CAs, so here I concatenated all intermediate and root CAs [client:default] method = TLSv1+ verify_certificate = yes require_certificate = yes private_key = /usr/local/etc/kamailio/tls/key_gw_sfb.pem certificate = /usr/local/etc/kamailio/tls/cert_gw_sfb.pem ca_list = /usr/local/etc/kamailio/tls/myca_and_sfbca.pem When I run Kamailio, I can see incoming OPTIONS from Microsoft Exchange Unified Messaging (UM), whose certificate I verify without any issues. UM presents a certificate issued for a single machine, so no Subject Alternative Names (SANs) are involved. The problem comes with the TLS handshake for the Skype Mediation pool. They have a certificate with Subject = DNS alias and all the physical machines that are behind the alias appear listed as Subject Alternative Names (SANs) in the certificate. As the only difference between UM and Skype's Mediation is the certificate's Subject, I think I am missing something on my configuration to validate the SANs instead of the subject. Is the TLS module doing any reverse DNS lookup to verify this? Thanks, Francisco.

7 years

Record-Route IP Value

by Soltanici Ilie

Hi All, Having the following Header: Record-Route: <sip:192.168.1.1;lr;did=637.07c7c2d7> How can i extract only IP value from this header? Thank You.

7 years

module version mismatch for /usr/local/lib64/kamailio/modules/kex.so

by Abdul Basit

Hi, My kamailio installation with 5.0.3 was working fine. I update kamailio source to 5.0.4 and make all; make install I started receiving error below: /etc/init.d/kamailio start [FAIL] Not starting Kamailio SIP Server: invalid configuration file! ... failed! failed! [....] 0(7426) ERROR: <core> [core/sr_module.c:431]: version_control(): module version mismatch for /usr/local/lib64/kamailio/modules/kex.so; core: kamailio 5.0.3 (x86_64/lin[FAILmodule: kamailio 5.0.4 (x86_64/linux) ... failed! failed! kamailio.cfg is same as earlier. I removed kamailio sources and modules folder /usr/local/lib64/kamailio/modules/ I also dropped old kamailio postgres database and created new one after fresh source install of version 5.0.4 from git. # git clone https://github.com/kamailio/kamailio kamailio # cd kamailio # git checkout -b 5.0 origin/5.0 But this error persists. Whats the resolution? Is this a bug? -- regards, abdul basit

7 years

Source comparisons by DNS hostname

by Alex Balashov

Hi, Is there a reasonable way, in Kamailio, to determine whether the source of a given SIP message is equivalent to the IP address to which a given DNS hostname resolves? i.e. if(src_ip == 'fqdn.domain.xyz') but not src_ip, obviously. I can't find any core keywords that would seem to fit the bill for a composite comparison. Any other options? -- Alex -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

7 years

Radius accounting and cdr's

by Jan Hazenberg

Hi all, I have a question regarding radius accounting. I would like to have a config where i store local cdr records (and not the ACC records) and send accounting to radius as well. I have the following config: # ----- acc params ----- /* General settings */ modparam("acc", "log_level", 0) modparam("acc", "log_facility", "LOG_LOCAL2") /* Enable cdr's */ modparam("acc", "cdr_enable", 1) modparam("acc", "cdr_log_enable", 1) modparam("acc", "cdr_start_on_confirmed", 0) modparam("acc", "cdr_facility", "LOG_LOCAL2") modparam("acc", "cdr_on_failed", 1) /* what special events should be accounted ? */ modparam("acc", "early_media", 0) modparam("acc", "report_ack", 0) modparam("acc", "report_cancels", 0) modparam("acc", "detect_direction", 1) /* Accounting triggers (flags) */ modparam("acc", "log_flag", FLT_ACC) modparam("acc", "log_missed_flag", FLT_ACCMISSED) modparam("acc", "failed_transaction_flag", FLT_ACCFAILED) modparam("acc_radius", "radius_flag", FLT_ACC) modparam("acc_radius", "radius_missed_flag", FLT_ACCMISSED) modparam("acc_radius", "radius_config", "/etc/radiusclient-ng/radiusclient.conf") This works but stores the raw accounting records as well. If i disable the acc log_flag it stops sending radius accounting records (while the acc_radius log_flag is still enabled). Is it possible to send only radius accounting records and disable the local logging of those records, but leave the cdr logging enabled? Or is there a option where i can set only the cdr_log_level so accounting records will only show up when i increase the debug level? Another option is to use a seperate log facility for accounting and cdr's, but it would be nice if it is possible to disable the logging of accounting records and only keep the cdr's. I'm running kamailio 5.0.3. Thanks, Jan

7 years

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 2017