sr-users February 2018

sr-users@lists.kamailio.org

90 participants
109 discussions

by Aidar Kamalov

Hello! I have kamailio 5.0.5 and some cisco spa 50x phones. Sometime phone can't register to kamailio. REGISTER packets with right nonce,reponse, etc gets to kamailio but it response 401 Unauthorized with code -3 (user not found). After some attempts(or time, phone send register every 1200 seconds) or after reboot phone it register succesfully Feb 13 11:20:02 sipchel /usr/sbin/kamailio[110432]: NOTICE: <script>: AUTH: REGISTER [a470211a-b7d8faa5(a)172.16.3.1] Feb 13 11:20:02 sipchel /usr/sbin/kamailio[110432]: NOTICE: <script>: AUTH: REGISTER FAILED (code: -5) fd=voip.xxxx.org, adu=<null>, aa=<null>, ar=<null>, au=<null>, ad=<null>, aU=<null>, Au=33855(a)voip.xxxx.org [ a470211a-b7d8faa5(a)172.16.3.1] Feb 13 11:20:02 sipchel /usr/sbin/kamailio[110433]: NOTICE: <script>: AUTH: REGISTER [a470211a-b7d8faa5(a)172.16.3.1] Feb 13 11:20:02 sipchel /usr/sbin/kamailio[110433]: NOTICE: <script>: AUTH: REGISTER FAILED (code: -3) fd=voip.xxxx.org, adu=sip:voip.xxxx.org, aa=MD5, ar=voip.xxxx.org, au=33855, ad=, aU=33855, Au=33855(a)voip.xxxx.org [ a470211a-b7d8faa5(a)172.16.3.1] Feb 13 11:20:02 sipchel /usr/sbin/kamailio[110431]: NOTICE: <script>: AUTH: REGISTER [a470211a-b7d8faa5(a)172.16.3.1] Feb 13 11:20:02 sipchel /usr/sbin/kamailio[110431]: NOTICE: <script>: AUTH: REGISTER FAILED (code: -3) fd=voip.xxxx.org, adu=sip:voip.xxxx.org, aa=MD5, ar=voip.xxxx.org, au=33855, ad=, aU=33855, Au=33855(a)voip.xxxx.org [ a470211a-b7d8faa5(a)172.16.3.1] -- Aydar A. Kamalov

6 years, 8 months

Issue starting with kamctl

by Ruben Lezama

Hi, I am having issues to start Kamailio using kamctl. root@kamailio2:/etc/systemd/system# kamctl restart INFO: Stopping Kamailio : ERROR: No PID file found (/var/run/kamailio.pid)! Kamailio probably not running INFO: check with 'ps axw | /bin/egrep kamailio' Using #Kamailio starts works. I can register peers and make calls between them. But I cannot update configuration. root@kamailio2:/var/log# kamailio Listening on udp: 127.0.0.1:5060 udp: 192.168.1.100:5060 tcp: 127.0.0.1:5060 tcp: 192.168.1.100:5060 Aliases: tcp: kamailio2:5060 tcp: localhost:5060 udp: kamailio2:5060 udp: localhost:5060 I would appreciate any help provided. Attached the syslog output Ruben

6 years, 8 months

KeepAlive Module

by Social Boh

Hello, I'm using keepalive module with drouting module... the event route works fine: NOTICE: <script>: Gateway up: OPTIONS sip:1.2.3.4 NOTICE: <script>: Gateway up: OPTIONS sip:5.6.7.8 but kamcmd command not: *kamcmd keepalive.list* foobar 42 foobar 42 { text: foobar number: 42 } { list: { nn: 17 nn: 22 } } { uri: sip:1.2.3.4 owner: drouting last checked: Wed Feb 21 11:20:12 2018 *last up: Wed Dec 31 19:00:00 1969* *last down: Wed Feb 21 11:20:13 2018* } { uri: sip:5.6.7.8 owner: drouting last checked: Wed Feb 21 11:20:12 2018 *last up: Wed Dec 31 19:00:00 1969* *last down: Wed Feb 21 11:20:12 2018* Thank you Regards... -- --- I'm SoCIaL, MayBe

6 years, 8 months

Strongswan on same Server in EC2 as kamailio 4.4

by Jonathan Hunter

Hi Guys, I have an issue with sending a BYE message back down a strongswan VPN tunnel on a server in the Amazon EC2 environment. To get the configuration working correctly I have the Public IP address bound to a loopback virtual interface, and I also have kamailio listening to it. Calls establish without issue, but when the called party send a BYE, I cant seem to force the SIP message down the correct interface. Due to client confidentiality I need to be careful what information I send but does anyone have a similar configuration set up, and working, I am just looking for reasons as to why force_socket and mhomed=1 doesnt appear to force the BYE message via the Public Interface but the private IP address on the server as its a NAT'd environment. So essentially call establishes; CLIENT---------(VIA IPSEC)-INVITE----->(UDP)KAMAILIO PUBLIC IP-------->(UDP)KAMAILIO PRIVATE IP(TCP)------------------------->CLIENT B | | | | |<---------(VIA IPSEC)-100 TRYING----|<----------100 TRYING---------------|<----------100 TRYING----------------------------| | | | | |<---------(VIA IPSEC)-180 RINGING---|<----------180 RINGING--------------|<----------180 RINGING---------------------------| | | | | |<---------(VIA IPSEC)-200OK --------|<----------200OK -------------------|<----------200OK --------------------------------| | | | | |----------(VIA IPSEC)-ACk---------> |-----------ACk--------------------->|-----------ACk---------------------------------->| How can I ensure the BYE is forced out via the PUBLIC IP? So I do this; CLIENT---------(VIA IPSEC)-INVITE----->(UDP)KAMAILIO PUBLIC IP-------->(UDP)KAMAILIO PRIVATE IP(TCP)------------------------->CLIENT B |<---------BYE (VIA IPSEC)----------------------|<----------BYE ----------------------------|<----------BYE -------------------| As it appears to be going from Private IP and not being pushed down the IPSEC tunnel CLIENT---------(VIA IPSEC)-INVITE----->KAMAILIO PUBLIC IP-------->KAMAILIO PRIVATE IP------------------------->CLIENT B |<---------BYE ----------------------<----------BYE ----------------------------|<----------BYE -------------------| on the BYE I have tried; force_send_socket(KAMAILIO PUBLIC IP); However doesnt appear to work, is this an issue for ip routing on the server to push the BYE correctly down the IPSEC tunnel? or is it configuration related? Any comments welcome if people have had this issue before. Many thanks Jon

6 years, 8 months

Planing next Kamailio releases - v4.4.7 v5.0.6 and v5.1.2

by Daniel-Constantin Mierla

Hello, I am considering to do releases from last three stable branches during next week. v4.4.7 is going to be released out of latest code in branch 4.4 to mark the end of official maintenance for series v4.4.x. The version 4.4.0 was released in March 2016, so it had more or less two years of maintenance. Commits can still go in 4.4 branch if developers wants to push there, end of official maintenance means that there is no plan to do packaging and release another version from the branch in the future, so you will have to build it from sources or generate packages yourself. v5.0.6 and v5.1.2 are the usual minor releases we do from the last two stable branches. If there are any issues you are aware of and not reported on bug tracker, create the items as soon as possible to get a better chance to review and eventually fix. Cheers, Daniel -- Daniel-Constantin Mierla www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - March 5-7, 2018, Berlin - www.asipto.com Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com

6 years, 8 months

Siremis and kamailio 5.x.x

by Olli Attila

Hello, Question about Kamailio web GUI (Siremis): I believe the Siremis updates are still a ongoing work or has there been any updates when the new Siremis update (compatible with Kamailio 5.x.x) will be released? https://www.kamailio.org/w/2017/07/siremis-ongoing-updates/ Cheers, Olli

6 years, 8 months

Kamailio ims with TCP

by Amar Tinawi

Hello list For some reason i couldn't register on kamailio ims when i use only TCP protocols between nodes, the error was solved when i enabled UDP between I-CSCF and S-CSCF is it mandatory for those two nodes to talk over UDP only ? or i'm missing something ? and in general for sip protocol which is better ? UDP or TCP ? Regards,

6 years, 8 months

Trunks with registration

by Володимир Іванець

Hello all! I was testing Registration capability of UAC module and have two questions that hopefully someone have answers to: - Is it possible to tell Kamailio which transport protocol to use other than by configuring auth_proxy column of uacreg table with domain name that has SRV record? - What are the priorities of different transport protocols in SRV record when it is used? Thanks a lot!

6 years, 8 months

Changing contact header

by Cibin Paul

Hello, In my setup, Kamailio acts as a registration server and route the calls to different asterisk boxes. The clients using IPV6 private ip and IPV4 public ip address are rejected by the asterisk server. On printing the contact header, I am getting the private ip (ipv6). Is there a way to change the contact header with public ip in all scenarios. I tried updating the contact header as below and unfortunately not working. Is there a better way to handle the scenario. As of now we don/t have a plan to implement ipv6 network. $var(p1) = "<sip:"; $var(p2) = "@"; $var(p3) = ":"; $var(p4) = ";ob>"; $var(x) = "" + $var(p1) + $fU + $var(p2) + $si + $var(p3) + $sp + $var(p4); remove_hf("Contact"); append_hf("Contact: $var(x)\r\n”); Thanks & Regards Cibin

6 years, 8 months

Question on contribution of documentation improvements

by Floimair Florian

Hi guys! While reading through documentation I realized there are a lot of typos (typing errors) and some misspellings so I decided to try to correct them. I dit this in all of Kamailios module and lib documentation (the xml in the doc folders) and they turned out to be quite a lot. Right now this sits on my fork of kamailo on github, but I would like to get this back into the main repository. What's puzzling me though, is how to most effectively get this in via a pull request due to the following: For now I have made a single commit for each module I touched. Therefore quite a lot of commits have accumulated. Actually 152 commits in modules and 4 commits in lib. Since most of the commits in modules are rather small (ranging from 1 line changed to 4) with only a few having more, I am not sure if that's the way to go to have a single commit for each module. Therefore I am unsure if a squashed version would be more appropriate. Therefore I created a second branch on my forked repository. Unsquashed: https://github.com/ffloimair/kamailio/tree/wip-fix-typos Squashed: https://github.com/ffloimair/kamailio/tree/wip-fix-typos In total a diff --stat to master results in 205 files changed, 521 insertions(+), 521 deletions(-) So please let me know what would be the wanted (and most efficient) way to proceed. With best regards Florian Floimair Innovation - Software-Development COMMEND INTERNATIONAL GMBH A-5020 Salzburg, Saalachstraße 51 Tel: +43-662-85 62 25 Fax: +43-662-85 62 26 http://www.commend.com Security and Communication by Commend FN 178618z | LG Salzburg

6 years, 8 months

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