sr-users November 2018

sr-users@lists.kamailio.org

68 participants
88 discussions

by Dan Quinney

Hi all, I’m having some issues with ACK’s. Specifically, when an ACK reaches Kamailio from either Asterisk or an endpoint, Kamailio is adding a second Via header - which isn’t valid as per RFC 3261 (17.1.1.3); “The ACK MUST contain a single Via header field, and this MUST be equal to the top Via header field of the original request." Endpoints are registered with Kamailio but INVITES are routed via Asterisk for dial plan and media reasons. I’m running fairly bog-standard Kamailio and Asterisk installs. I’ve attached a sample PCAP for if anyone has any suggestions. Thanks. Dan

5 years, 4 months

Kamailio v5.2.0 Released - new major version is out

by Daniel-Constantin Mierla

Kamailio v5.2.0 is out – it comes with 6 new modules and a consistent group of improvements touching more than 100 existing modules. You can read detailed release notes at: * https://www.kamailio.org/w/kamailio-v5-2-0-release-notes/ Many thanks to all developers and community members that made possible this release. v5.2.0 brings more flexibility and optimizations for KEMI interpreters (including two new interpreters for Python3 and Ruby), major enhancements to load balancer and tls implementations, new variables and lots of other new features. Enjoy Kamailio v5.2.0! Thank you for flying Kamailio! Daniel -- Daniel-Constantin Mierla http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference 2019 - http://www.kamailioworld.com

5 years, 4 months

Response VIA Header

by Soltanici Ilie

Hi, We have a Kamailio Instance running on Public IP Address, one of our ISP cannot send ACK back to us because we are sending 100 Trying - without "received" parameter. Is there any way in Kamailio to force a "received" parameter in the via header for 100 Trying Message? SIP/2.0 100 trying -- your call is important to us Via: SIP/2.0/UDP X.X.X.X:5060;branch=z9hG4bK8tgchsfjaKJdf.1;rport=5060 Thank you.

5 years, 4 months

Forward() not handles Route headers

by Yuriy Gorlichenko

We are building some stateless solution and found that in case of using forward() kamailio sends traffic only via URI or $du variable. It never removes itself from route headers. Is this is the truth? Or I need to add some other module to handle it? (rr already added)

5 years, 4 months

KAMAILIO 4.2 - RTPPROXY config confirmation - error message from systemctl status kamailio.service -l (ERROR: <script>: NATMANAGE coee)

by yboujraf＠by-research.be

Dear All, I am still using Kamailio 4.2 with Debian Jessie without any issues. RTPPROXY - CONFIG > # Defaults for rtpproxy > # The control socket. > #CONTROL_SOCK="unix:/var/run/rtpproxy/rtpproxy.sock" > # To listen on an UDP socket, uncomment this line: > CONTROL_SOCK=udp:127.0.0.1:7722 > # Additional options that are passed to the daemon. > > # log in /var/log/kamailio.log > EXTRA_OPTS="-l ip_public/192.168.40.101 -m 11000 -M 12000 -d DBUG:LOG_LOCAL0" WHEN I MAKE AN INVITE FROM 801 TO 803, I HAVE THIS ERROR MESSAGE : KAMAILIO SERVICE (ERROR: <SCRIPT>: NATMANAGE COEE) root@sipsecure:~# systemctl status kamailio.service -l ● kamailio.service - LSB: Start the Kamailio SIP proxy server Loaded: loaded (/etc/init.d/kamailio) Active: active (running) since Tue 2018-11-20 22:34:31 CET; 40s ago Process: 1820 ExecStop=/etc/init.d/kamailio stop (code=exited, status=0/SUCCESS) Process: 1830 ExecStart=/etc/init.d/kamailio start (code=exited, status=0/SUCCESS) CGroup: /system.slice/kamailio.service ├─1846 /usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg -P /var/run/kamailio/kamailio.pid -m 64 -M 8 -u kamailio -g kamailio ├─1848 /usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg -P /var/run/kamailio/kamailio.pid -m 64 -M 8 -u kamailio -g kamailio ├─1849 /usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg -P /var/run/kamailio/kamailio.pid -m 64 -M 8 -u kamailio -g kamailio ├─1850 /usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg -P /var/run/kamailio/kamailio.pid -m 64 -M 8 -u kamailio -g kamailio ├─1851 /usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg -P /var/run/kamailio/kamailio.pid -m 64 -M 8 -u kamailio -g kamailio ├─1852 /usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg -P /var/run/kamailio/kamailio.pid -m 64 -M 8 -u kamailio -g kamailio ├─1853 /usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg -P /var/run/kamailio/kamailio.pid -m 64 -M 8 -u kamailio -g kamailio ├─1854 /usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg -P /var/run/kamailio/kamailio.pid -m 64 -M 8 -u kamailio -g kamailio ├─1855 /usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg -P /var/run/kamailio/kamailio.pid -m 64 -M 8 -u kamailio -g kamailio ├─1856 /usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg -P /var/run/kamailio/kamailio.pid -m 64 -M 8 -u kamailio -g kamailio ├─1858 /usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg -P /var/run/kamailio/kamailio.pid -m 64 -M 8 -u kamailio -g kamailio ├─1860 /usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg -P /var/run/kamailio/kamailio.pid -m 64 -M 8 -u kamailio -g kamailio ├─1863 /usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg -P /var/run/kamailio/kamailio.pid -m 64 -M 8 -u kamailio -g kamailio ├─1865 /usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg -P /var/run/kamailio/kamailio.pid -m 64 -M 8 -u kamailio -g kamailio ├─1867 /usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg -P /var/run/kamailio/kamailio.pid -m 64 -M 8 -u kamailio -g kamailio ├─1869 /usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg -P /var/run/kamailio/kamailio.pid -m 64 -M 8 -u kamailio -g kamailio ├─1871 /usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg -P /var/run/kamailio/kamailio.pid -m 64 -M 8 -u kamailio -g kamailio ├─1873 /usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg -P /var/run/kamailio/kamailio.pid -m 64 -M 8 -u kamailio -g kamailio └─1875 /usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg -P /var/run/kamailio/kamailio.pid -m 64 -M 8 -u kamailio -g kamailio Nov 20 22:35:00 sipsecure /usr/sbin/kamailio[1853]: ERROR: <script>: NATMANAGE coee Nov 20 22:35:00 sipsecure /usr/sbin/kamailio[1854]: ERROR: <script>: NATMANAGE M=INVITE OU=<null> RURI=<null> RD=<null> F=sip:801@192.168.40.101;transport=UDP T=sip:803@192.168.40.101;transport=UDP NH=<null> IP=192.168.0.207 ID=fjpUwRGm0u--3RvvB4fZ7Q.. Nov 20 22:35:00 sipsecure /usr/sbin/kamailio[1854]: ERROR: <script>: NATMANAGE coee Nov 20 22:35:00 sipsecure /usr/sbin/kamailio[1855]: ERROR: <script>: NATMANAGE M=INVITE OU=<null> RURI=<null> RD=<null> F=sip:801@192.168.40.101;transport=UDP T=sip:803@192.168.40.101;transport=UDP NH=<null> IP=192.168.0.207 ID=fjpUwRGm0u--3RvvB4fZ7Q.. Nov 20 22:35:00 sipsecure /usr/sbin/kamailio[1855]: ERROR: <script>: NATMANAGE coee Nov 20 22:35:03 sipsecure /usr/sbin/kamailio[1852]: ERROR: <script>: NATMANAGE M=INVITE OU=<null> RURI=<null> RD=<null> F=sip:801@192.168.40.101;transport=UDP T=sip:803@192.168.40.101;transport=UDP NH=<null> IP=192.168.0.207 ID=fjpUwRGm0u--3RvvB4fZ7Q.. Nov 20 22:35:03 sipsecure /usr/sbin/kamailio[1852]: ERROR: <script>: NATMANAGE coee Nov 20 22:35:03 sipsecure /usr/sbin/kamailio[1852]: NOTICE: acc [acc.c:317]: acc_log_request(): ACC: transaction answered: timestamp=1542749703;method=INVITE;from_tag=4d488551;to_tag=2006d156;call_id=fjpUwRGm0u--3RvvB4fZ7Q..;code=200;reason=OK;src_user=801;src_domain=192.168.40.101;src_ip=192.168.0.229;dst_ouser=803;dst_user=803;dst_domain=192.168.0.207;user_agent=Z 5.2.19 rv2.8.99 Nov 20 22:35:03 sipsecure /usr/sbin/kamailio[1853]: ERROR: <script>: NATMANAGE M=ACK OU=sip:803@192.168.0.207:5060;alias=192.168.0.207:5060~1 RURI=sip:803@192.168.0.207:5060 RD=192.168.0.207 F=sip:801@192.168.40.101;transport=UDP T=sip:803@192.168.40.101;transport=UDP NH=192.168.0.207 IP=192.168.0.229 ID=fjpUwRGm0u--3RvvB4fZ7Q.. Nov 20 22:35:03 sipsecure /usr/sbin/kamailio[1853]: ERROR: <script>: NATMANAGE coee Don't understand why the error??? RTPPROXY SERVICE : (RTPPROXY IS DOING HIS JOB PERFECTLY AND GET AUDIO ON BOTH DIRECTION) root@sipsecure:~# systemctl status rtpproxy.service -l ● rtpproxy.service - LSB: RTP Proxy Loaded: loaded (/etc/init.d/rtpproxy) Active: active (running) since Tue 2018-11-20 22:13:58 CET; 22min ago Process: 443 ExecStart=/etc/init.d/rtpproxy start (code=exited, status=0/SUCCESS) CGroup: /system.slice/rtpproxy.service └─1137 /usr/bin/rtpproxy -s udp:127.0.0.1 7722 -u rtpproxy rtpproxy -p /var/run/rtpproxy/rtpproxy.pid -l 212.76.231.102 192.168.40.101 -m 11000 -M 12000 -d DBUG LOG_LOCAL0 Nov 20 22:34:31 sipsecure rtpproxy[1137]: DBUG:doreply: sending reply "1875_11 1 " Nov 20 22:35:00 sipsecure rtpproxy[1137]: DBUG:handle_command: received command "1853_8 USEEc106,9,3,111,0,8,97,110,112,98,101,100,99,102 fjpUwRGm0u--3RvvB4fZ7Q.. 192.168.0.229 11000 4d488551;1" Nov 20 22:35:00 sipsecure rtpproxy[1137]: INFO:handle_command: new session fjpUwRGm0u--3RvvB4fZ7Q.., tag 4d488551;1 requested, type strong Nov 20 22:35:00 sipsecure rtpproxy[1137]: INFO:handle_command: new session on a port 11496 created, tag 4d488551;1 Nov 20 22:35:00 sipsecure rtpproxy[1137]: INFO:handle_command: pre-filling caller's address with 192.168.0.229:11000 Nov 20 22:35:00 sipsecure rtpproxy[1137]: DBUG:doreply: sending reply "1853_8 11496 192.168.40.101 " Nov 20 22:35:03 sipsecure rtpproxy[1137]: DBUG:handle_command: received command "1852_8 LSEEc106,9,3,111,0,8,97,110,112,102,98,101,100,99 fjpUwRGm0u--3RvvB4fZ7Q.. 192.168.0.207 11112 4d488551;1 2006d156;1" Nov 20 22:35:03 sipsecure rtpproxy[1137]: INFO:handle_command: lookup on ports 11496/11402, session timer restarted Nov 20 22:35:03 sipsecure rtpproxy[1137]: INFO:handle_command: pre-filling callee's address with 192.168.0.207:11112 Nov 20 22:35:03 sipsecure rtpproxy[1137]: DBUG:doreply: sending reply "1852_8 11402 192.168.40.101 " ??? Question : for rtpproxy config, do I need to add the natted ip address (NAT 1:1) or the real public address (where ip phone needs to assign as domain)? I am confused. Thanks a lot in advance Best Regards, Youssef

5 years, 4 months

Issue sending SIP OPTIONS request to multiple contacts

by Dan Quinney

Hi, When using Kamailio v5.2.0-rc2 (x86_64/linux) 9e729b and setting the below nathelper module parameters it appears only the first contact is sent a SIP OPTIONS request. modparam("nathelper", "natping_interval", 15) modparam("nathelper", "ping_nated_only", 0) modparam("nathelper", "sipping_bflag", FLB_NATSIPPING) modparam("nathelper", "sipping_from", "sip:ping@mydomain <sip:ping@mydomain>.com") modparam("nathelper", "keepalive_timeout", 90) Reading the release notes for v5.2 what I’m doing *should* be possible, but as the functionality has been recently added I’m assuming that it might be a bug. Any assistance on this would be great. Thanks, Dan

5 years, 4 months

Releasing Kamailio v5.2.0

by Daniel-Constantin Mierla

Hello, I am consider to release v5.2.0 (the first stable version out of branch 5.2) next week, likely on Wednesday, Nov 28, 2018. It still allows a bit more than a week of testing as well as well time to prepare the online resources for it (documentation, wiki pages, upgrade guidelines, etc...). If there is any issue you are of and not yet reported to github bug tracker, do it as soon as possible to give it a chance to be fixed in time for the next major release. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference -- www.kamailioworld.com Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com

5 years, 4 months

Error opening Kamailio's FIFO

by Markus

Hi list, when I run "/usr/sbin/kamctl address reload" I get: ERROR: Error opening Kamailio's FIFO /tmp/kamailio_fifo ERROR: Make sure you have the line 'modparam("mi_fifo", "fifo_name", "/tmp/kamailio_fifo")' in your config ERROR: and also have loaded the mi_fifo module. In /etc/kamailio/kamailio.cfg I have: loadmodule "mi_fifo.so" # ----- mi_fifo params ----- modparam("mi_fifo", "fifo_name", "/tmp/kamailio_fifo") But there's no fifo in /tmp. What am I doing wrong? kamailio-4.4.4-1.1.x86_64 on CentOS Linux release 7.2.1511 (Core). Thank you! Markus

5 years, 4 months

[CFP] FOSDEM 2019, 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 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>

5 years, 4 months

Dialiog and dispatcher

by David Villasmil

Hello guys, I'm testing the dispatcher with the dialog module. After making several test calls, which are properly routed, the number of dialogs stay there for a while, preventing new calls from going to those destinations: "SET": { "ID": 101, "TARGETS": [{ "DEST": { "URI": "sip:1.2.3.4:5080", "FLAGS": "AP", "PRIORITY": 0, "ATTRS": { "BODY": "weight=100;maxload=10;duid=bedd39c7-6c73-4477-ae7d-77f8cdc96797", "DUID": "bedd39c7-6c73-4477-ae7d-77f8cdc96797", "MAXLOAD": 10, "WEIGHT": 100, "RWEIGHT": 0, "SOCKET": "" }, "RUNTIME": { "DLGLOAD": 10 } } }] The calls have been down for several seconds, but the "DLGLOAD" parameter doesn't go down, even though /usr/local/kamailio5/sbin/kamctl', 'dialog', 'show Output the correct amount of dialogs. I set the dialog handler just before relaying out: t_on_failure("RTF_DISPATCH"); set_dlg_profile("gateways","$du"); route(RELAY); And the module is supposed to remove them automatically. Am i doing something wrong? Regards, David Villasmil email: david.villasmil.work(a)gmail.com phone: +34669448337 ᐧ

5 years, 5 months

← Newer
1
2
3
4
5
6
7
8
9
Older →

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 November 2018