sr-users October 2016

sr-users@lists.kamailio.org

61 participants
100 discussions

Send SIP Info within a dialog using $uac_req(method)="INFO"
by Jonathan Hunter 07 Dec '16

07 Dec '16

Hi Guys, Is it still the case that when using uac_req_send, you cant send withing a specific dialog?I can modify call-id, but I presume tags may be more of a problem?See old post below from 2015; > I am familiar with uac_req_send. but how do I send it with in a > specific dialog and with data in the INFO req ? sending a new request inside a dialog is not possible with uac_req_send(). It is not easy over all because you change the sequence order (CSeq value). Practically, you need to track how many requests you sent from the middle to update (and restore in reply) when caller or callee sends a new request. dialog module can track changes in CSeq for requests sent to callee, being used now for authentication of INVITE to another provider, when Kamailio adds the credentials. But for more you would need to extend the dialog module. I just need to send a SIP info within an established dialog to stop some function up stream, so wondered if this is still a blocker? Many thanks Jon

2 40

[CFP] FOSDEM 2017, RTC devroom, speakers, volunteers neeeded
by FOSDEM RTC Team 15 Nov '16

15 Nov '16

FOSDEM is one of the world's premier meetings of free software developers, with over five thousand people attending each year. FOSDEM 2017 takes place 4-5 February 2017 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 Saturday, 4 February 2017. 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 17 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 devroom". https://penta.fosdem.org/submission/FOSDEM17/ 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/2017/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 31 October. 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. 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, 4 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 See the mailing list discussion for more details about volunteering: https://lists.fsfe.org/pipermail/free-rtc/2016-October/000285.html 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 2 and 3 February 2017 http://wiki.xmpp.org/web/Summit_21 - please join the mailing list for details: http://mail.jabber.org/mailman/listinfo/summit We are also considering a more general RTC or telephony summit, potentially in collaboration with the XMPP summit. Please join the Free-RTC mailing list and send an email if you would be interested in participating, sponsoring or hosting such an event. Social events and dinners ========================= The traditional FOSDEM beer night occurs on Friday, 3 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>

2 1

usrloc module expires column issues
by Grant Bagdasarian 10 Nov '16

10 Nov '16

Hello, When saving in the location table, the expires and last_modified columns contain the value 000-00-00 00:00:00 which causes issues when Kamailio is restarted and the preload modparam is set to load the location table from db in memory at startup. I've already upgraded Kamailio to 4.4.3, and used the dbtables script from version 4.4 to recreate the location table, but without success. Anyone else having this issue? Any resolution for it? Regards, Grant Bagdasarian CM

2 9

Contacts replacing each other when registering
by Sebastian Damm 08 Nov '16

08 Nov '16

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

2 4

Out of memory in UB 210: OOM killed process 12261 (kamailio) score 0 vm:1614768kB, rss:280200kB, swap:131408kB
by Jurijs Ivolga 08 Nov '16

08 Nov '16

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

3 25

Malformed To header, or?
by Tobias 04 Nov '16

04 Nov '16

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

3 13

Configuring/Integrating Kamailio Open IMS with FHoSS
by Olvera, Victor 04 Nov '16

04 Nov '16

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 13

Kamailio TLS client config selection
by Sergey Basov 02 Nov '16

02 Nov '16

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

2 3

/usr/sbin/kamailio - unresolvable destination error
by Ginti Saurabh 01 Nov '16

01 Nov '16

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

2 1

Terminating PCSCF unresolvable request URI (Kamailio IMS Websockets)
by Serhat Guler 01 Nov '16

01 Nov '16

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

2 1

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

2026

2025

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