February 2017 - sr-users

Kamailio + Asterisk with multidomain
by Tomas Zanet 07 Feb '17

07 Feb '17

Hello, thanks to this guide http://kb.asipto.com/asterisk:realtime:kamailio-4.0.x-asterisk-11.3.0-astdb I successfully installed Asterisk 11.6 and Kamailio 4.4.4 on the same machine. Everything works fine. Right now I would like to extend this scenario adding MULTIDOMAIN support, which is not enabled by default Do you see any problems / technical limitations to add multidomain support in this scenario? Before enhancing Kamailio cfg file and Asterisk configuration I would like to know: is this possible? As far as I know Kamailio works fine with multidomain support but I don’t know if Asterisk or both processes can support it. Thanks in advance Regards, T. Tomas Zanet Software Design Department tzanet(a)came.com CAME S.p.A.

2 1

DMQ Cluster - hosts loose network connectivity
by José Seabra 07 Feb '17

07 Feb '17

Hello there, My DMQ cluster has 4 nodes and by some reason 2 of them lost the network connectivity for long time(~ 4 hours), after the network of these 2 nodes come back they didn't get connected on DMQ cluster automatically, i had to restart kamailio to get them again on DMQ list. My doubts here are: - Is this an expected behavior of DMQ module? - Is there any way of put them again on DMQ bus without need restart kamailio? Thank you Best Regards José Seabra

3 5

Kamailio parse failed message
by Hai Bui Duc Ha 07 Feb '17

07 Feb '17

Hi all, I have problem when make call with my Android mobile use PJSIP library. Scenario: my client -> Kamailio -> Freeswitch (media server) -> another client (soft phone on Windows) my client: + use Bluestack + Capture via Wireshark + use Wifi Issue: The call will be drop after ~ 30 second. I see the error on Kamailio: *Jan 5 16:08:59 ab-kz-02 kamailio[6343]: ERROR: <core> [parser/parse_fline.c:257]: parse_first_line(): parse_first_line: bad message (offset: 13)* *Jan 5 16:08:59 ab-kz-02 kamailio[6343]: ERROR: <core> [parser/parse_fline.c:257]: parse_first_line(): parse_first_line: bad message (offset: 13)* *Jan 5 16:08:59 ab-kz-02 kamailio[6343]: ERROR: <core> [parser/msg_parser.c:690]: parse_msg(): ERROR: parse_msg: message=<p:8 PCMA/8000#015#012a=rtpmap:101 telephone-event/8000#015#012a=fmtp:101 0-16#015#012ACK sip:buiduchahai@125.212.212.36:11000;transport=tcp SIP/2.0#015#012Via: SIP/2.0/TCP 10.0.2.15:57735;rport;branch=z9hG4bKPjlgc13AjrUrFJHq60vWhGqsUaGXi2F98Z;alias#015#012Max-Forwards: 70#015#012From: "Phap Huynh" <sip:huynhngocphap@happy.anttel-pro.ab-kz-02.antbuddy.com <sip%3Ahuynhngocphap(a)happy.anttel-pro.ab-kz-02.antbuddy.com>>;tag=zJBNvD67y3E.1I5Y5ZrRI4JmP5JKeNWO#015#012To: <sip:buiduchahai@happy.anttel-pro.ab-kz-02.antbuddy.com <sip%3Abuiduchahai(a)happy.anttel-pro.ab-kz-02.antbuddy.com>>;tag=2SF4D790Zy6Kj#015#012Call-ID: ftMudIpIQeKWwP8kQDi2z1S0D1sV3KaB#015#012CSeq: 29055 ACK#015#012Route: <sip:125.212.212.40;transport=tcp;lr;ftag=zJBNvD67y3E.1I5Y5ZrRI4JmP5JKeNWO>#015#012Content-Length: 0#015#012#015#012>* *Jan 5 16:08:59 ab-kz-02 kamailio[6343]: ERROR: <core> [receive.c:129]: receive_msg(): core parsing of SIP message failed (49.156.54.54:50785/2 <http://49.156.54.54:50785/2>)* Seem to the server error when parse (on INVITE SDP) *a=rtpmap:8 PCMA/8000a=rtpmap:101 telephone-event/8000a=fmtp:101 0-16* (on new ACK message) *ACK sip:buiduchahai@125.212.212.36:11000;transport=tcp SIP/2.0* *Via: SIP/2.0/TCP 10.0.2.15:57735;rport;branch=z9hG4bKPjlgc13AjrUrFJHq60vWhGqsUaGXi2F98Z;alias* *Max-Forwards: 70* *From: "Phap Huynh" <sip:huynhngocphap@happy.anttel-pro.ab-kz-02.antbuddy.com <sip%3Ahuynhngocphap(a)happy.anttel-pro.ab-kz-02.antbuddy.com>>;tag=zJBNvD67y3E.1I5Y5ZrRI4JmP5JKeNWO* *To: <sip:buiduchahai@happy.anttel-pro.ab-kz-02.antbuddy.com <sip%3Abuiduchahai(a)happy.anttel-pro.ab-kz-02.antbuddy.com>>;tag=2SF4D790Zy6Kj* *Call-ID: ftMudIpIQeKWwP8kQDi2z1S0D1sV3KaB* *CSeq: 29055 ACK* *Route: <sip:125.212.212.40;transport=tcp;lr;ftag=zJBNvD67y3E.1I5Y5ZrRI4JmP5JKeNWO>* *Content-Length: 0* I think the SIP message is fragmented but when resume package is not correct. Do you have any advice ? Thank you for watching ! Regards, Hai Bui -- Hai Bui VoIP engineer, Cvoice team, HTK-HCM Office Mobile: +84-165-618-9876

2 11

FOSDEM 2017
by Daniel-Constantin Mierla 07 Feb '17

07 Feb '17

Hello, another edition of FOSDEM is approaching, about 2 weeks left: - https://fosdem.org/2017/ Couple of devs and many Kamailio friends will be around. Like past year, there is a Realtime Communications devroom, this edition on Sunday. Very interesting presentation for our ecosystem: Olle giving a presentation about IPv4/IPv6, Inaki introducing its SFU media server project, Jose talking about JsSIP, Daniel debating about fundraising FreeRTC, Lorenzo with Janus SIP-WebRTC gateway, the other Lorenzo with Homer Sipcature, Saul with Jitsi, Dan with cgrates, Matt with Asterisk, Giovanni with FreeSwitch... Schedule at: - https://fosdem.org/2017/schedule/track/real_time_communications/ On Sunday morning, part of Lua devroom, I will present about using Lua for building RTC services with Kamailio: - https://fosdem.org/2017/schedule/track/lua/ - https://fosdem.org/2017/schedule/event/luartcserviceskamailio/ During the past editions we organized a dinner on Saturday evening. Shall we attempt to do it again in advance this year? Or should we do it on spot based on the weather and mood at the end of Saturday? Cheers, Daniel -- Daniel-Constantin Mierla www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Mar 6-8 (Europe) and Mar 20-22 (USA) - www.asipto.com Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com

7 13

kamailio proxy behind firewall
by JBF 07 Feb '17

07 Feb '17

Hello, we have the following Configuration for our kamailio installation (we are using TLS and not udp) (1) F5 Firewall (configured as message fowarding), opening a TLS server on the outside (2) SIP proxy, with a TLS server accessed by the F5 . The SIP proxy doesnt see the F5 TLS server (3) SIP registrar REGISTER works find We have the following issue on INVITE: A sends an INVITE to B. The Registrar patches the R-URI with the content of location, which contains the publi ip of the Device (because the device used stun) we force the routing from registrar to proxy by using t_relay (SIP_PROXY_IP) /The proxy tries to route to this R-URI, which is not visible/ I am not sure how to fix that: Record Route is for a true sip proxy, but the Firewall does not have an server facing the SIP proxy: the sip proxy needs to find the proper client socket opened at register to route the INVITE We have arranged for the Firewall to add its own Via, but if i understand correctly, this is used for replies, and here we are dealing with a request forwarding, and t_relay uses the r-ruri to route requests. IT might be why REGISTER works correctly (ie the 200 OK is routed correctly from proxy to firewall) I could arrange for the location table to contain the private ip and port of the firewall connection (through the use of the received/rport info inserted in the Via by the proxy ) That would mean, however that the contact of the user will contain the private interface of the F5 which i found weird. How do you think i should proceed ? any advices are welcome Thank you -- View this message in context: http://sip-router.1086192.n5.nabble.com/kamailio-proxy-behind-firewall-tp15… Sent from the Users mailing list archive at Nabble.com.

2 3

RTPEngine disable/enable crash kamailio
by Sergey Basov 07 Feb '17

07 Feb '17

Hi All. I ave just try to temporary disable 1 of 2 RTPEngines. It was disabled successfully all media dialogs was finished. But when I have try to enable it I have kamailio crashed with error: CRITICAL: <core> [pass_fd.c:277]: receive_fd(): EOF on 121 Does anyone have such issue? kamailio 4.4.5 on RHEL 7.2 x86_64 rtpengine 4.4.0 on RHEL 7.2 x86_64 # kamctl fifo nh_show_rtpp all which: no gdb in (/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin:/) udp:10.1.23.24:2223:: set=0 index:: 0 disabled:: 0 weight:: 1 recheck_ticks:: 0 udp:10.1.23.25:2223:: set=0 index:: 1 disabled:: 0 weight:: 1 recheck_ticks:: 0 after # kamctl fifo nh_enable_rtpp udp:10.1.23.25:2223 0 it was successfully disabled with media going on after # kamctl fifo nh_enable_rtpp udp:10.1.23.25:2223 1 I got kamailio crash with error CRITICAL: <core> [pass_fd.c:277]: receive_fd(): EOF on 121 sorry I does not have coredump, it is production system. my config regarding rtpengine: modparam("rtpengine", "rtpengine_allow_op", 1) modparam("rtpengine", "rtpengine_sock", "udp:10.1.23.24:2223 udp:10.1.23.25:2223") Thank you. -- Best regards, Sergey Basov e-mail: sergey.v.basov(a)gmail.com

5 12

execute config route by ctp command?
by Juha Heinanen 07 Feb '17

07 Feb '17

Is there a way to execute a named config route, such as an event_route, by an rpc command? -- Juha

3 4

Re: [SR-Users] Spurious dialog timeouts
by Pranathi Venkatayogi 07 Feb '17

07 Feb '17

Any clue on this? Or to work around this, can someone shed light on how to differentiate when “Dialog:end” is called due to actual call drop - Bye vs some timeout. I need to do some special logic only on call drop. Relevant snippet from the logs are: 7719 Feb 3 21:41:20 labsip00 /usr/sbin/kamailio[11323]: exec: *** cfgtrace:local_route=[dialog:end] c=[//etc/kamailio//routing.cfg] l=490 a=16 n=if 7720 Feb 3 21:41:20 labsip00 /usr/sbin/kamailio[11323]: exec: *** cfgtrace:local_route=[dialog:end] c=[//etc/kamailio//routing.cfg] l=481 a=24 n=is_known_dlg 7721 Feb 3 21:41:20 labsip00 /usr/sbin/kamailio[11323]: exec: *** cfgtrace:local_route=[dialog:end] c=[//etc/kamailio//routing.cfg] l=482 a=63 n=assign 7722 Feb 3 21:41:20 labsip00 /usr/sbin/kamailio[11323]: exec: *** cfgtrace:local_route=[dialog:end] c=[//etc/kamailio//routing.cfg] l=489 a=16 n=if 7723 Feb 3 21:41:20 labsip00 /usr/sbin/kamailio[11323]: exec: *** cfgtrace:local_route=[dialog:end] c=[//etc/kamailio//routing.cfg] l=485 a=26 n=xlog 7724 Feb 3 21:41:20 labsip00 /usr/sbin/kamailio[11323]: INFO: <script>: Translation: Dialog ended for sip:agent2@translation.sms-test.cyracom.com. Marking free 7725 Feb 3 21:41:20 labsip00 /usr/sbin/kamailio[11323]: exec: *** cfgtrace:local_route=[dialog:end] c=[//etc/kamailio//routing.cfg] l=486 a=63 n=assign 7726 Feb 3 21:41:20 labsip00 /usr/sbin/kamailio[11323]: exec: *** cfgtrace:local_route=[dialog:end] c=[//etc/kamailio//routing.cfg] l=487 a=63 n=assign 7727 Feb 3 21:41:20 labsip00 /usr/sbin/kamailio[11323]: WARNING: dialog [dlg_handlers.c:1515]: dlg_ontimeout(): timeout for dlg with CallID '1478097bad2847cfaa60a768d76044b0' and tags '57315e78d6514251876bd5a9e32347d2' '00a1eac150f04e2592527372412f059e' ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ -----Original Message----- From: Pranathi Venkatayogi Sent: Friday, February 03, 2017 2:29 PM To: 'Kamailio (SER) - Users Mailing List' <sr-users(a)lists.sip-router.org> Subject: Spurious dialog timeouts Hi, I have two kamailio proxies between the customer and agent. Cust -> proxy1 -> proxy2 -> agent. The dialogs are successfully established and remain undeleted within the customer / agent client. However in Proxy2 I am seeing spurious dialog timeout. I am attaching kamailio log trace below. Also attached is the siptrace on the agent/customer side. Question: How is this dlg_ontimeout() generated despite dialog being successfully established and undelete? How to avoid it. Kamailio (proxy2) log: 7719 Feb 3 21:41:20 labsip00 /usr/sbin/kamailio[11323]: exec: *** cfgtrace:local_route=[dialog:end] c=[//etc/kamailio//routing.cfg] l=490 a=16 n=if 7720 Feb 3 21:41:20 labsip00 /usr/sbin/kamailio[11323]: exec: *** cfgtrace:local_route=[dialog:end] c=[//etc/kamailio//routing.cfg] l=481 a=24 n=is_known_dlg 7721 Feb 3 21:41:20 labsip00 /usr/sbin/kamailio[11323]: exec: *** cfgtrace:local_route=[dialog:end] c=[//etc/kamailio//routing.cfg] l=482 a=63 n=assign 7722 Feb 3 21:41:20 labsip00 /usr/sbin/kamailio[11323]: exec: *** cfgtrace:local_route=[dialog:end] c=[//etc/kamailio//routing.cfg] l=489 a=16 n=if 7723 Feb 3 21:41:20 labsip00 /usr/sbin/kamailio[11323]: exec: *** cfgtrace:local_route=[dialog:end] c=[//etc/kamailio//routing.cfg] l=485 a=26 n=xlog 7724 Feb 3 21:41:20 labsip00 /usr/sbin/kamailio[11323]: INFO: <script>: Translation: Dialog ended for sip:agent2@translation.sms-test.cyracom.com. Marking free 7725 Feb 3 21:41:20 labsip00 /usr/sbin/kamailio[11323]: exec: *** cfgtrace:local_route=[dialog:end] c=[//etc/kamailio//routing.cfg] l=486 a=63 n=assign 7726 Feb 3 21:41:20 labsip00 /usr/sbin/kamailio[11323]: exec: *** cfgtrace:local_route=[dialog:end] c=[//etc/kamailio//routing.cfg] l=487 a=63 n=assign 7727 Feb 3 21:41:20 labsip00 /usr/sbin/kamailio[11323]: WARNING: dialog [dlg_handlers.c:1515]: dlg_ontimeout(): timeout for dlg with CallID '1478097bad2847cfaa60a768d76044b0' and tags '57315e78d6514251876bd5a9e32347d2' '00a1eac150f04e2592527372412f059e' 7728 Feb 3 21:41:20 labsip00 /usr/sbin/kamailio[11323]: exec: *** cfgtrace:local_route=[dialog:end] c=[//etc/kamailio//routing.cfg] l=490 a=16 n=if 7729 Feb 3 21:41:20 labsip00 /usr/sbin/kamailio[11323]: exec: *** cfgtrace:local_route=[dialog:end] c=[//etc/kamailio//routing.cfg] l=481 a=24 n=is_known_dlg 7730 Feb 3 21:41:20 labsip00 /usr/sbin/kamailio[11323]: exec: *** cfgtrace:local_route=[dialog:end] c=[//etc/kamailio//routing.cfg] l=482 a=63 n=assign 7731 Feb 3 21:41:20 labsip00 /usr/sbin/kamailio[11323]: exec: *** cfgtrace:local_route=[dialog:end] c=[//etc/kamailio//routing.cfg] l=489 a=16 n=if 7732 Feb 3 21:41:20 labsip00 /usr/sbin/kamailio[11323]: exec: *** cfgtrace:local_route=[dialog:end] c=[//etc/kamailio//routing.cfg] l=485 a=26 n=xlog 7733 Feb 3 21:41:20 labsip00 /usr/sbin/kamailio[11323]: INFO: <script>: Translation: Dialog ended for sip:agent5@translation.sms-test.cyracom.com. Marking free 7734 Feb 3 21:41:20 labsip00 /usr/sbin/kamailio[11323]: exec: *** cfgtrace:local_route=[dialog:end] c=[//etc/kamailio//routing.cfg] l=486 a=63 n=assign 7735 Feb 3 21:41:20 labsip00 /usr/sbin/kamailio[11323]: exec: *** cfgtrace:local_route=[dialog:end] c=[//etc/kamailio//routing.cfg] l=487 a=63 n=assign 7736 Feb 3 21:41:20 labsip00 /usr/sbin/kamailio[11323]: WARNING: dialog [dlg_handlers.c:1515]: dlg_ontimeout(): timeout for dlg with CallID '04d924dc160d4e0c9366d4699f579793' and tags '9b107772c82148c0a09182dc86804c51' '44b0a200438a42f8a6ac931ed72f795a' Thanks for your input, Pranathi

1 0

SIP message order
by Andy Chen 06 Feb '17

06 Feb '17

Hello sr-users, First of all, I'm new to this forum so any help would be greatly appreciated as my Kamailio knowledge is somewhat limited. Thanks for your patience. So to the question at hand. If the originator of the SIP method sends SIP messages out of order, does the Kamailio put them back in order before relaying it to the destination device? I'm seeing where the 200 OK was sent first before the SIP UPDATE within the same CSeq number. The reason I'm asking is because I'm seeing this behavior now with UDP transport protocol and I'm trying to justify why we don't need to switch to TCP to fix this issue. Thanks. --Andy

2 1

Kamailio 4.2.3-3.1 Segfaulting - Need debuginfo RPM for kamailio-4.2.3-3.1.x86_64
by Peter DiSanto 06 Feb '17

06 Feb '17

Our Kamailio 4.2.3 recently began seg-faulting in production. I ran a bt full, but without the debuginfo I presume it isn't much use. We cannot locate the original RPMs for this version to be able to obtain the debuginfo RPM. We are running the kamailio-4.2.3-3.1.x86_64 RPM for CentOS6. Anybody have it or can help us find the debug, or offer other advice?

2 1