sr-users October 2016

sr-users@lists.kamailio.org

61 participants
97 discussions

Contacts replacing each other when registering

by Sebastian Damm

Hi, we are running a Registrar server with 4.4.3, the registrar module is configured with the following parameters: modparam("registrar", "max_contacts", 50) modparam("registrar", "use_path", 1) modparam("registrar", "path_mode", 0) modparam("registrar", "path_use_received", 1) modparam("registrar", "received_avp", "$(avp(i:801))") modparam("registrar", "default_expires", 600) modparam("registrar", "min_expires", 60) modparam("registrar", "max_expires", 600) modparam("registrar", "gruu_enabled", 0) A customer has configured 4 phones with the same username. Normally, all 4 phones would be visible in the location database, and incoming calls would fork out to all 4 phones. However, only one of the devices is always online, the others always replace each other on each registration. Client details: * All phones are snom 715 devices with the same firmware version. * All phones sit behind the same router. Registrations: client 1: * Via: SIP/2.0/UDP 192.168.208.91:35812;branch=z9hG4bK-4q0mmxgu6gm7;rport * Contact: <sip:1794388e3@192.168.208.91:35812;line=gicode6v>;reg-id=1;q=1.0;+sip.instance="<urn:uuid:0a14174a-77be-424c-864e-0004137F1C9D>" client 2: * Via: SIP/2.0/UDP 192.168.208.90:41331;branch=z9hG4bK-3cbxdvbmk0di;rport * Contact: <sip:1794388e3@192.168.208.90:41331;line=0j6veso8>;reg-id=1;q=1.0;+sip.instance="<urn:uuid:0a14174a-77be-424c-864e-0004137F1C9D>" client 3: * Via: SIP/2.0/UDP 192.168.208.92:5360;branch=z9hG4bK-4drsogakez94;rport * Contact: <sip:1794388e3@192.168.208.92:5360;line=0n7jfzih>;reg-id=1;q=1.0;+sip.instance="<urn:uuid:0a14174a-77be-424c-864e-0004137F1C9D>" client 4: * Via: SIP/2.0/UDP 192.168.208.93:5260;branch=z9hG4bK-1ci0qia3yxyl;rport * Contact: <sip:1794388e3@192.168.208.93:5260;line=mh9sgxa1>;reg-id=1;q=1.0 Only client 4 is reachable all the time. The other 3 clients replace other registrations. So after client 1 registers, the contacts returned in the 200 OK looks like this: Contact: <sip:1794388e3@192.168.208.91:35812;line=gicode6v>;q=1;expires=600;received="sip:1.2.3.4:6411";+sip.instance="<urn:uuid:0a14174a-77be-424c-864e-0004137F1C9D>";reg-id=1, <sip:1794388e3@192.168.208.93:5260;line=mh9sgxa1>;q=1;expires=303;received="sip:1.2.3.4:8923" And after client 2 registers, the contacts returned in the 200 OK looks like this: Contact: <sip:1794388e3@192.168.208.90:41331;line=0j6veso8>;q=1;expires=600;received="sip:1.2.3.4:49061";+sip.instance="<urn:uuid:0a14174a-77be-424c-864e-0004137F1C9D>";reg-id=1, <sip:1794388e3@192.168.208.93:5260;line=mh9sgxa1>;q=1;expires=301;received="sip:1.2.3.4:8923" So you see, one contact stays the same, the other one gets replaced. Does anybody know what could cause this kind of behavior? I think, it could be GRUU. I see that those three clients all send the same GRUU parameter. From my understanding, this UUID should be different from client to client. I don't know whether this is a bug in the snom firmware always sending the same GRUU UUID or whether som "intelligent" SIP aware router is putting this in the Contact header. However, since we have disabled gruu for the registrar module (see above), I think, Kamailio should ignore it. Ideas? Thanks in advance. Best Regards, Sebastian

8 years

Out of memory in UB 210: OOM killed process 12261 (kamailio) score 0 vm:1614768kB, rss:280200kB, swap:131408kB

by Jurijs Ivolga

Hi, Our Kamailio server is crashing once per week, with following error: Oct 1 06:25:06 kamailio kernel: [26982632.803789] Out of memory in UB 210: OOM killed process 12261 (kamailio) score 0 vm:1614768kB, rss:280200kB, swap:131408kB Core dump was never created, probably it is because of my environment, but I will try to get it. Server constantly eats memory, maybe some kind of memory leak? Any help is highly appreciated! Jurijs

8 years

Malformed To header, or?

by Tobias

Hi! Having some issues with Kamailio 4.3 reporting a malformed header, but I cannot seem to figure out what's wrong. The problem seen is: Oct 27 13:48:56 /usr/sbin/kamailio[13765]: ERROR: <core> [parser/parse_addr_spec.c:678]: parse_addr_spec(): ERROR: parse_to : unexpected char [#015] in status 6: <<+123456789 <sip:123456789@127.0.0.1;tag=as4aa27bd0>> . Oct 27 13:48:56 /usr/sbin/kamailio[13765]: ERROR: <core> [parser/msg_parser.c:165]: get_hdr_field(): ERROR: get_hdr_field: bad to header Oct 27 13:48:56 /usr/sbin/kamailio[13765]: INFO: <core> [parser/msg_parser.c:338]: parse_headers(): ERROR: bad header field [To: +123456789 <si] Oct 27 13:48:56 /usr/sbin/kamailio[13765]: ERROR: tm [t_lookup.c:1050]: t_check_msg(): ERROR: reply cannot be parsed Oct 27 13:48:56 /usr/sbin/kamailio[13765]: ERROR: <core> [parser/parse_addr_spec.c:678]: parse_addr_spec(): ERROR: parse_to : unexpected char [#015] in status 6: <<+123456789 <sip:123456789@127.0.0.1;tag=as4aa27bd0>> . Oct 27 13:48:56 /usr/sbin/kamailio[13765]: ERROR: <core> [parser/msg_parser.c:165]: get_hdr_field(): ERROR: get_hdr_field: bad to header Oct 27 13:48:56 /usr/sbin/kamailio[13765]: INFO: <core> [parser/msg_parser.c:338]: parse_headers(): ERROR: bad header field [To: +123456789 <si] Oct 27 13:48:56 /usr/sbin/kamailio[13765]: ERROR: <core> [msg_translator.c:1457]: adjust_clen(): error parsing content-length Oct 27 13:48:56 /usr/sbin/kamailio[13765]: ERROR: <core> [msg_translator.c:2214]: generate_res_buf_from_sip_res(): error while adjusting Content-Length Oct 27 13:48:56 /usr/sbin/kamailio[13765]: ERROR: <core> [forward.c:760]: do_forward_reply(): building failed And the To header seen at this point is: To: +123456789 <sip:123456789@127.0.0.1>;tag=as24ed5606. version: kamailio 4.3.4 (x86_64/linux) flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, DBG_QM_MALLOC, 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 4.7.2 I obviously understand Kamailio views this To header as malformed, but what I cannot understand is why? Is it as simple as the number +123456789 is not enclosed with ", i.e. it should be sent as "+123456789"? A similar issue seen, which for some reason doesn't create an ERROR, is when Kamailio receives a reINVITE looking like this which it's supposed to proxy: To: +123456789 <sip:123456789@127.0.0.1>;tag=SD1sf9001--45026-530b969-77c7543f-530b969. which is rewritten into: To: +123456789 <sip:123456789@127*0-)'.:/)&7'...0;user=phone>;tag=SD1sf9001--45026-530b969-77c7543f-530b969. and sent out.. Thanks for your help, /Tobias

8 years

Configuring/Integrating Kamailio Open IMS with FHoSS

by Olvera, Victor

How does one configure Kamailio Open IMS and FHoSS? In other words, how does one configure IMS and FHoSS so that when soft calls are made they must be processed by the FHoSS before they go through the Open IMS server? Great regards, Victor Olvera

8 years

Kamailio TLS client config selection

by Sergey Basov

Hi Daniel. After some try to configure kamailio 4.4.3 to act as SPI TLS client for Cisco SIP TLS gateways I have found one issue. If I do client configuration for tls [client:10.1.23.19:5061] verify_certificate = yes ca_list = /etc/kamailio/CAs/ca1.pem [client:10.1.23.29:5061] verify_certificate = yes ca_list = /etc/kamailio/CAs/ca2.pem [client:default] verify_certificate = no require_certificate = no Kamailo always do default profile selection (I do configuration without server_name or server_id, with it kamailio works fine but there are some troubles to make selection of this parameters from config script, I need additional checks and queries) after some research in tls module source code I have added some debug information in file tls_server.c: if (c->flags & F_CONN_PASSIVE) { state=S_TLS_ACCEPTING; dom = tls_lookup_cfg(cfg, TLS_DOMAIN_SRV, &c->rcv.dst_ip, c->rcv.dst_port, 0, 0); } else { state=S_TLS_CONNECTING; sname = tls_get_connect_server_name(); srvid = tls_get_connect_server_id(); // ------------------------------------------------------------- DBG("Entered client config loockup (c->rcv.dst_port %d)\n", c->rcv.dst_port); DBG("Entered client config loockup (&c->rcv.dst_ip %s)\n", ip_addr2a(&c->rcv.dst_ip)); DBG("Entered client config loockup (c->rcv.src_port %d)\n", c->rcv.src_port); DBG("Entered client config loockup (&c->rcv.src_ip %s)\n", ip_addr2a(&c->rcv.src_ip)); // ------------------------------------------------------------- dom = tls_lookup_cfg(cfg, TLS_DOMAIN_CLI, &c->rcv.dst_ip, c->rcv.dst_port, sname, srvid); } After making Oct 26 09:23:56 sip1 /usr/sbin/kamailio[20712]: DEBUG: <core> [parser/msg_parser.c:597]: parse_msg(): method: <INVITE> Oct 26 09:23:56 sip1 /usr/sbin/kamailio[20712]: DEBUG: <core> [parser/msg_parser.c:599]: parse_msg(): uri: <sip:9098@10.1.23.19:5061;transport=TLS> Oct 26 09:23:56 sip1 /usr/sbin/kamailio[20712]: DEBUG: <core> [parser/msg_parser.c:601]: parse_msg(): version: <SIP/2.0> I see Oct 26 09:23:56 sip1 /usr/sbin/kamailio[20712]: DEBUG: <core> [ip_addr.c:229]: print_ip(): tcpconn_new: new tcp connection: 10.1.23.19 Oct 26 09:23:56 sip1 /usr/sbin/kamailio[20712]: DEBUG: <core> [tcp_main.c:985]: tcpconn_new(): on port 5061, type 3 Oct 26 09:23:56 sip1 /usr/sbin/kamailio[20712]: DEBUG: <core> [tcp_main.c:1295]: tcpconn_add(): hashes: 1394:0:0, 1 Oct 26 09:23:56 sip1 /usr/sbin/kamailio[20712]: DEBUG: tls [tls_server.c:197]: tls_complete_init(): completing tls connection initialization Oct 26 09:23:56 sip1 /usr/sbin/kamailio[20712]: DEBUG: tls [tls_server.c:160]: tls_get_connect_server_name(): xavp with outbound server name not found Oct 26 09:23:56 sip1 /usr/sbin/kamailio[20712]: DEBUG: tls [tls_server.c:140]: tls_get_connect_server_id(): xavp with outbound server id not found Oct 26 09:23:56 sip1 /usr/sbin/kamailio[20712]: DEBUG: tls [tls_server.c:219]: tls_complete_init(): Entered client config loockup (c->rcv.dst_port 40123) Oct 26 09:23:56 sip1 /usr/sbin/kamailio[20712]: DEBUG: tls [tls_server.c:220]: tls_complete_init(): Entered client config loockup (&c->rcv.dst_ip 10.1.23.23) Oct 26 09:23:56 sip1 /usr/sbin/kamailio[20712]: DEBUG: tls [tls_server.c:221]: tls_complete_init(): Entered client config loockup (c->rcv.src_port 5061) Oct 26 09:23:56 sip1 /usr/sbin/kamailio[20712]: DEBUG: tls [tls_server.c:222]: tls_complete_init(): Entered client config loockup (&c->rcv.src_ip 10.1.23.19) Where: &c->rcv.dst_ip 10.1.23.23 - it is my local kamailio tls socket ip address to make tls connect from c->rcv.dst_port 40123 - it is my local kamailio tls socket port &c->rcv.src_ip 10.1.23.19 - ip of my TLS device to make tls connection to c->rcv.src_port 5061 - port of my TLS device to make tls connection to so if I change line dom = tls_lookup_cfg(cfg, TLS_DOMAIN_CLI, &c->rcv.dst_ip, c->rcv.dst_port, sname, srvid); to dom = tls_lookup_cfg(cfg, TLS_DOMAIN_CLI, &c->rcv.src_ip, c->rcv.src_port, sname, srvid); I got correct client domain selection Oct 26 09:33:56 sip1 /usr/sbin/kamailio[20712]: DEBUG: tls [tls_server.c:233]: tls_complete_init(): Using initial TLS domain TLSc<10.1.23.19:5061> (dom 0x7fd2eefa3d68 ctx 0x7fd2ef7e70a8 sn []) Oct 26 09:33:56 sip1 /usr/sbin/kamailio[20712]: DEBUG: tls [tls_domain.c:703]: sr_ssl_ctx_info_callback(): SSL handshake started Can you look at this code? Thank you in advance. -- Best regards, Sergey Basov e-mail: sergey.v.basov(a)gmail.com tel: (+38067) 403-62-54

8 years

/usr/sbin/kamailio - unresolvable destination error

by Ginti Saurabh

Hi, Please help to sort the problem. Getting "Unresolvable destination" error in /var/log/messages.

8 years

Terminating PCSCF unresolvable request URI (Kamailio IMS Websockets)

by Serhat Guler

Dear all, I am trying to make a call between 2 webrtc clients(sipml5) using my kamailio IMS setup. The invite request fails at the terminating PCSCF with error code "Status: 478 Unresolvable destination (478/TM)". I have traced the packages and saw that the package that arrives at the terminating PCSCF has an unresolvable request URI due to the websocket connection. The package being sent from terminating ICSCF to SCSCF has the "Request-URI: sip:bob@net1.test" The package from terminating SCSCF to terminating PCSCF has the "Request-URI: sip:bob@df7jal23ls0d.invalid;rtcweb-breaker=yes;transport=ws" I guess the terminating SCSCF replaces the request URI with the one it stored during the registration process, but the terminating PCSCF cannot resolve the host name&port number; therefore, it reports back "Unresolvable destination". Is that really the case happening in here ? How can I get over this problem ? Any ideas are welcome. Cheers, Serhat

8 years

Server error for SIP client

by Hermann Norpois

Hello, if my SIP client tries to connect ... a server error occured (see below). Could you please help me to figure out the reason? Kamailio is installed on an amazon instance with an elastic IP (52.208.249.214, hostname: synth.ddns.net). Thanks Hermann ubuntu@ip-172-31-32-10:~sudo /etc/init.d/kamailio restart * Stopping Kamailio SIP Server: kamailio [ OK ] * Starting Kamailio SIP Server: kamailio loading modules under config path: /usr/lib/x86_64-linux-gnu/kamailio/modules/ Listening on udp: 127.0.0.1:5060 udp: 172.31.32.10:5060 tcp: 127.0.0.1:5060 tcp: 172.31.32.10:5060 Aliases: tcp: ip-172-31-32-10.eu-west-1.compute.internal:5060 tcp: localhost:5060 udp: ip-172-31-32-10.eu-west-1.compute.internal:5060 udp: localhost:5060 *: synth.ddns.net:* ubuntu@ip-172-31-32-10:~$ kamctl db show subscriber +----+----------+----------------+----------+---------------+----------------------------------+----------------------------------+------+ | id | username | domain | password | email_address | ha1 | ha1b | rpid | +----+----------+----------------+----------+---------------+----------------------------------+----------------------------------+------+ | 1 | Johanna | synth.ddns.net | 12345 | | 4fa26cedd456d7105c01a48742e71e42 | 1e249ac341d95701f855fce18bec0fba | NULL | ubuntu@ip-172-31-32-10:~$ sudo ngrep -d any -qt -W byline . port 5060 Via: SIP/2.0/UDP 172.31.32.10;received=52.208.249.214;branch=z9hG4bK533f.5ad567803b13610279818912da2fcd81.0. Via: SIP/2.0/UDP 172.31.32.10;received=52.208.249.214;branch=z9hG4bK533f.6a2baefed6cf4f6b6d34c7563d829e44.0. Via: SIP/2.0/UDP 172.31.32.10;received=52.208.249.214;branch=z9hG4bK533f.6d74cec9e5f5e46dd9cd67338143127f.0. Via: SIP/2.0/UDP 172.31.32.10;received=52.208.249.214;branch=z9hG4bK533f.a3a37d6bd0cd5d68fc786568f587f06e.0. Via: SIP/2.0/UDP 188.174.185.176:5060 ;received=188.174.185.176;rport=5060;branch=z9hG4bKPjAgF18hfvv20KOQ9H8G-fqfIPMjjcu9wq. From: <sip:Johanna@synth.ddns.net>;tag=vzlAJNNNES67ir6nsLMjvyFh5D0Thy6s. To: <sip:Johanna@synth.ddns.net>;tag=b27e1a1d33761e85846fc98f5f3a7e58.3300. Call-ID: 9Uj4TSeQAVwaMs3UHf8UKIhuoA4xBEZt. CSeq: 39586 REGISTER. Server: kamailio (4.3.6 (x86_64/linux)). Content-Length: 0. . U 2016/10/20 13:44:33.727161 52.208.249.214:5060 -> 172.31.32.10:5060 SIP/2.0 500 I'm terribly sorry, server error occurred (1/SL). Via: SIP/2.0/UDP 172.31.32.10;received=52.208.249.214;branch=z9hG4bK533f.2605d82fd11bd8f788cfad582884eb6d.0. Via: SIP/2.0/UDP 172.31.32.10;received=52.208.249.214;branch=z9hG4bK533f.e425ad98e0436abc4661d1452a49670d.0. Via: SIP/2.0/UDP 172.31.32.10;received=52.208.249.214;branch=z9hG4bK533f.2d047656fb9df0edfccd4a40d20237b7.0. Via: SIP/2.0/UDP 172.31.32.10;received=52.208.249.214;branch=z9hG4bK533f.f54ab9c35b22814b15acbe16bcae387f.0. Via: SIP/2.0/UDP 172.31.32.10;received=52.208.249.214;branch=z9hG4bK533f.db5960988332c2f4899a5e1c2b57e3c6.0. Via: SIP/2.0/UDP 172.31.32.10;received=52.208.249.214;branch=z9hG4bK533f.62f1191bd5af8480698ce118984536c0.0. Via: SIP/2.0/UDP 172.31.32.10;received=52.208.249.214;branch=z9hG4bK533f.5ad567803b13610279818912da2fcd81.0. Via: SIP/2.0/UDP 172.31.32.10;received=52.208.249.214;branch=z9hG4bK533f.6a2baefed6cf4f6b6d34c7563d829e44.0. Via: SIP/2.0/UDP 172.31.32.10;received=52.208.249.214;branch=z9hG4bK533f.6d74cec9e5f5e46dd9cd67338143127f.0. Via: SIP/2.0/UDP 172.31.32.10;received=52.208.249.214;branch=z9hG4bK533f.a3a37d6bd0cd5d68fc786568f587f06e.0. Via: SIP/2.0/UDP 188.174.185.176:5060 ;received=188.174.185.176;rport=5060;branch=z9hG4bKPjAgF18hfvv20KOQ9H8G-fqfIPMjjcu9wq. From: <sip:Johanna@synth.ddns.net>;tag=vzlAJNNNES67ir6nsLMjvyFh5D0Thy6s. To: <sip:Johanna@synth.ddns.net>;tag=b27e1a1d33761e85846fc98f5f3a7e58.3300. Call-ID: 9Uj4TSeQAVwaMs3UHf8UKIhuoA4xBEZt. CSeq: 39586 REGISTER. Server: kamailio (4.3.6 (x86_64/linux)). Content-Length: 0. 2) My logfile /var/log/kamailio/kamailio.log is empty though /etc/rsyslog.d/kamailio.conf exists with the entry: local0.* -/var/log/kamailio/kamailio.log And in /etc/kamailio/kamailio.conf: log_facility=LOG_LOCAL0 Why is the logfile empty? Thanks Herman

8 years

Store and add custom variables for sip registrations

by Markus Bönke

Hallo all, we want to use kamailio as registrar server in front of freeswitch. When a user registers we need to lookup and store some user variables. To every INVITE that is received from a registered user we want to add the variables as x sip headers before we relay them to freeswitch. The question is what is the best way to implement this? We tried to store the variables in a htable on register and then lookup and attach the variables on every INVITE from there. Is this the correct approach, one issue we see is that htable is not writing new inserts directly to the database. I’ve also seen that there is a table location_atts in the kamailio db which looks like that it is intended to store custom key value pairs for registrations, but the seems to be no module which writes to that table, or is there one? Thanks for any help or suggestions Markus

8 years

TSILO module use failure

by Igor Olhovskiy

Hi! I’m trying to implement scheme much like Federico Cabiddu is described here https://www.youtube.com/watch?v=4XIrR9bwUkM Done a bit modification to his script, cause it’s not fully correct on 4.4 version So, parts of config looks like …. route[REGISTRAR] { … if (!save("location")) { sl_reply_error(); } else { route(PUSHJOIN); } exit; …. } route[LOCATION] { if (!lookup("location")) { …… if (is_method("INVITE")) { send_reply("100", "Trying"); route(SUSPEND); } } else { if (is_method("INVITE")) { if (t_newtran()) { ts_store("sip:$tU@$fd"); } $sht(vtp=>stored::$rU) = 1; } } route(RELAY); } ….. route[SUSPEND] { if(!t_suspend()) { send_reply("501", "Unknown destination"); exit; } $sht(vtp=>join::$rU) = "" + $T(id_index) + ":" + $T(id_label); } # append branches or resume the transaction route[PUSHJOIN] { … #if was suspended - recover, if not - ts_append ….. ts_append(«location", "sip:$tU@$fd"); return; … t_continue("$var(id_index)", "$var(id_label)", "INVRESUME"); } # lookup and relay after resuming transaction route[INVRESUME] { lookup("location"); t_relay(); ts_store("sip:$tU@$fd"); $sht(vtp=>stored::$rU) = 1; } Branches on ts_store are saved in format (sip:username@domain) and also in this format they are added on ts_append. All regarding to routes working ok, except on ts_append I got ERROR: tm [t_append_branches.c:168]: t_append_branches(): ERROR: t_append_branch: failure to add branches (-1) Also, it’s a mixed environment, like wss + udp + tcp. Any idea why? Thanks. -- Best regards, Igor

8 years

← Newer
1
2
3
4
5
6
7
8
9
10
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 October 2016