sr-users July 2015

sr-users@lists.kamailio.org

86 participants
150 discussions

by Kyle Kurz

I'm using allow_address function of the permissions module and I'm seeing strange behavior with network masks not divisible by 8. I have 172.16.0.0/12 in my address table and Kamailio is marking packets from 172.56.16.232 as being part of that local subnet. If I change the subnet to 172.16.0.0/16, I no longer have an issue. I know there was a bug several years ago related to this ( http://git.kamailio.org/gitlist/index.php/sip-router/commit/0ead7ab31bf0df6…), but that code is very different, so I'm wondering if a regression has crept in? I'm using Kam 4.1.6. Thanks, Kyle -- *Kyle Kurz* Digium, Inc. · Senior Software Engineer 9115 Brown Deer Rd · San Diego, CA 92121 · US direct +1 858.537.1166 Check us out at: http://digium.com · http://asterisk.org <http://www.asterisk.org/>

9 years, 5 months

dmq_replicate deserializing?

by Asgaroth

Hi All, I am playing with the new dmq_replicate module and am banging my head against an issue I have come accross. I can see the kamailio registrars sending the replication messages to the other node(s) in the dmq bus, and the payload looks to be of type json. However, on the recieving nodes, when I try to issue a kamctl ul show --brief, the output of the AOR's are garbled. I had a look at the dmq/dmq_ursloc moduled, and the dmq module docs mention that we may need to load our own deserializers, is this the case when using the dmq_usrloc module as well? I am only using dmq to replicate registration messages. Here is a sample of the dmq workers on a recieving node applying the update, and you can see that it thinks the contact to add is 'p÷#031#002', is was expecting the actual AOR of the subriber to show up here. Am I missing something simple here or is there something more sinister at play. Any pointers would be greatly appreciated. Kamailio Version: version: kamailio 4.3.0 (x86_64/linux) c6aa95 flags: STATS: Off, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, F_MALLOC, DBG_F_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: c6aa95 compiled on 16:14:27 Jun 23 2015 with gcc 4.4.7 Debug log below: Jul 1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: <core> [parser/msg_parser.c:606]: parse_msg(): SIP Request: Jul 1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: <core> [parser/msg_parser.c:608]: parse_msg(): method: <KDMQ> Jul 1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: <core> [parser/msg_parser.c:610]: parse_msg(): uri: <sip:usrloc@10.6.0.174:5060> Jul 1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: <core> [parser/msg_parser.c:612]: parse_msg(): version: <SIP/2.0> Jul 1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: <core> [parser/parse_via.c:1254]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK9b3c.fe993716000000000000000000000000.0>; state=16 Jul 1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: <core> [parser/parse_via.c:2642]: parse_via(): end of header reached, state=5 Jul 1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: <core> [parser/msg_parser.c:496]: parse_headers(): parse_headers: Via found, flags=2 Jul 1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: <core> [parser/msg_parser.c:498]: parse_headers(): parse_headers: this is the first via Jul 1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: <core> [receive.c:134]: receive_msg(): After parse_msg... Jul 1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: <core> [receive.c:177]: receive_msg(): preparing to run routing scripts... Jul 1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: tm [t_lookup.c:1011]: t_check_msg(): DEBUG: t_check_msg: msg id=450 global id=449 T start=0xffffffffffffffff Jul 1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: <core> [parser/parse_addr_spec.c:894]: parse_addr_spec(): end of header reached, state=10 Jul 1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: <core> [parser/msg_parser.c:173]: get_hdr_field(): DEBUG: get_hdr_field: <To> [30]; uri=[sip:usrloc@10.6.0.174:5060] Jul 1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: <core> [parser/msg_parser.c:175]: get_hdr_field(): DEBUG: to body [<sip:usrloc@10.6.0.174:5060>#015#012] Jul 1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: <core> [parser/msg_parser.c:153]: get_hdr_field(): get_hdr_field: cseq <CSeq>: <10> <KDMQ> Jul 1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: <core> [parser/msg_parser.c:187]: get_hdr_field(): DEBUG: get_hdr_body : content_length=471 Jul 1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: <core> [parser/msg_parser.c:89]: get_hdr_field(): found end of header Jul 1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: tm [t_lookup.c:466]: t_lookup_request(): t_lookup_request: start searching: hash=50105, isACK=0 Jul 1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: tm [t_lookup.c:424]: matching_3261(): DEBUG: RFC3261 transaction matching failed Jul 1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: tm [t_lookup.c:648]: t_lookup_request(): DEBUG: t_lookup_request: no transaction found Jul 1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: tm [t_lookup.c:1080]: t_check_msg(): DEBUG: t_check_msg: msg id=450 global id=450 T end=(nil) Jul 1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: dmq [message.c:53]: dmq_handle_message(): dmq_handle_message [KDMQ sip:usrloc@10.6.0.174:5060] [ ] Jul 1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: dmq [message.c:65]: dmq_handle_message(): dmq_handle_message peer found: usrloc Jul 1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil) Jul 1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil) Jul 1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23014]: DEBUG: dmq [worker.c:84]: worker_loop(): dmq_worker [0 23014] lock acquired Jul 1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil) Jul 1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23014]: DEBUG: <core> [parser/parse_addr_spec.c:172]: parse_to_param(): DEBUG: add_param: tag=390c95c339281829d3cea6f43c8512cb-7e62 Jul 1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23014]: DEBUG: <core> [parser/parse_addr_spec.c:894]: parse_addr_spec(): end of header reached, state=29 Jul 1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23014]: DEBUG: dmq_usrloc [usrloc_sync.c:250]: usrloc_dmq_handle_msg(): dmq message received from sip:usrloc@10.6.0.173:5060 Jul 1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23014]: DEBUG: dmq_usrloc [usrloc_sync.c:353]: usrloc_dmq_handle_msg(): Received DMQ_UPDATE. Update contact info... Jul 1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23014]: DEBUG: dmq_usrloc [usrloc_sync.c:60]: add_contact(): 'p÷#031#002' found in usrloc Jul 1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23014]: DEBUG: dmq_usrloc [usrloc_sync.c:62]: add_contact(): get_ucontact = 0 Jul 1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23014]: DEBUG: dmq_usrloc [usrloc_sync.c:72]: add_contact(): Found contact Jul 1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23014]: DEBUG: usrloc [ucontact.c:1688]: update_ucontact(): exists callback for type= UL_CONTACT_UPDATE Jul 1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23014]: DEBUG: usrloc [ul_callback.h:84]: run_ul_callbacks(): contact=0x7ffe86eabad8, callback type 2/15, id 0 entered Jul 1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23014]: DEBUG: dmq_usrloc [usrloc_sync.c:494]: dmq_ul_cb_contact(): Callback from usrloc with type=2 Jul 1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23014]: DEBUG: dmq_usrloc [usrloc_sync.c:517]: dmq_ul_cb_contact(): Contact recieved from DMQ... skip Jul 1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23014]: DEBUG: dmq_usrloc [usrloc_sync.c:85]: add_contact(): Release record Jul 1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23014]: DEBUG: dmq_usrloc [usrloc_sync.c:87]: add_contact(): Unlock udomain Jul 1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23014]: DEBUG: sl [sl.c:280]: send_reply(): reply in stateless mode (sl) Jul 1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil) Jul 1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23014]: DEBUG: <core> [msg_translator.c:158]: check_via_address(): (10.6.0.173, 10.6.0.173, 0) Jul 1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil) Jul 1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil) Jul 1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: <core> [xavp.c:446]: xavp_destroy_list(): destroying xavp list (nil) Jul 1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: <core> [receive.c:278]: receive_msg(): cleaning up Jul 1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23014]: DEBUG: dmq [worker.c:134]: worker_loop(): sent reply Jul 1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23014]: DEBUG: dmq [worker.c:82]: worker_loop(): dmq_worker [0 23014] getting lock

9 years, 5 months

SRTP to RTP with Kamailio

by Alberto Sagredo

Hi I have a Kamailio in front of an Asterisk Cluster and moved to rtpengine to give support for SRTP from rtpproxy What i want is to have SRTP on Kamailio-rtpengine leg but RTP inside network for Asterisk. I have found that config https://loadmultiplier.com/sites/default/files/kamailio/pcscf/kamailio.cfg But could not be able to make it work? Anyone did this scenareo and could give me some tips? I have enabled sdops and be able to remove SRTP and crypto lines but not be able to make it work as i mention Thanks in advanced Alberto

9 years, 5 months

IMS server with a core network

by test testt

hello, I posted a message in the kamailio forum but it wasn't in the good place, so I rebroadcast at this e-mail as it was say. Hello, I have installed Kamailio 4.2 and I would like to use it as IMS server but I don't have any ideas how to do this. I have a LTE core network which includes HSS ans PCRF. I saw on this page ( http://www.kamailio.org/w/2013/05/ims-kamailio/ ) that is apparently easy, just need to take the P-CSCF, S-CSCF and I-CSCF Kamailio and Diameter config files in the examples folder and run kamailio but I don't know how to use them and I didn't find any tutorials about it. Could you help me please ? Marc link: https://github.com/kamailio/kamailio/issues/227#issuecomment-118073500 I tried the 2 tutorials that it has given but it's not really working I am using ubuntu 15.04 Thanks Marc

9 years, 5 months

Dispatcher, Failure Route and fr_timeout

by Asgaroth

Hi All, I would like to reduce the time it takes for kamailio to timeout an initial message to a dispatcher destination so that it will select the next destination in the set, before, hopefully, a restransmission. In this case I am testing registration messages. I came accross the t_set_fr() function in the TM module documentation today and have been experimenting with it for some hours. I have an issue where a 408 timout is sent back to the UAC before the last destination in the dispatcher set is selected, I suspect I am hitting the timeout somewhere, but I cannot see where, I presume the fr_timeout is set every time I issue the t_set_fr() call and the associated t_relay. I'm just wondering if I am doing this correctly, if one of the guru's out there wouldnt mind casting an eyeball over this config and let me know if I am on the right track, or if I am going about this in the wrong way. Any suggestions are most welcome. What appears to be happening is, I have 3 destinations in the dispatcher set, it looks like the 1st 2 are tried, which correctly timeout and are set inactive-probing, but on the last destination, which is working, I appear to be getting a 408 timeout being sent back from kamailio. Here is a snip of my configuration: #!define NO_RESPONSE_TIMER 250 request_route { t_on_failure("DISPATCHER_FAILURE"); t_set_fr(0, NO_RESPONSE_TIMER); if(!ds_select_dst("1", "0")) { xlog("L_ERR", "No dispatcher destinations available for $ru\n"); sl_send_reply("500", "No destination available"); exit; } route("RELAY") } route[RELAY] { if (!t_relay()) { sl_reply_error(); } exit; } failure_route[DISPATCHER_FAILURE] { if (t_is_canceled()) { exit; } # select next destination only for local timeout if (t_branch_timeout() && !t_branch_replied()) { xlog("L_INFO", "route[DISPATCHER_FAILURE] : $rm : timeout and no reply ($si:$sp->$Ri:$Rp->$du)\n"); xlog("L_INFO", "route[DISPATCHER_FAILURE] : $rm : setting $du to probing state"); ds_mark_dst("ip"); if(ds_next_dst()) { xlog("L_INFO", "route[DISPATCHER_FAILURE] : $rm : next destination selected ($du)\n"); t_set_fr(0, NO_RESPONSE_TIMER); t_relay(); exit; } else { xlog("L_INFO", "route[DISPATCHER_FAILURE] : $rm : No destinations available for $rd"); send_reply("500", "No destination available"); exit; } } }

9 years, 5 months

How to configure Cx - diameter running on SCTP

by Jan Devai

Hi guys, I would like to configure Cx interface, i.e. Diameter on SCTP between I/S-CSCF and external HSS. Can somebody Guide me how to achieve it or if somebody who already did that, can he share his configurations files with me? Thank you Jan

9 years, 5 months

clarification on tcp keepalive

by Kelvin Chua

using kamailio 4.3 on ubuntu server 14.04 i noticed tcp socket will be killed by kamailio after around 11 minutes with or without tcp_keepalive=no. tcpdump shows that by default (tcp_keepalive=yes) there is indeed keepalive packets going back and forth. if set to no, there would be nothing in between. if i have clients who have registration timeout of 1700, they would send re-registration around half of that, or around 14 minutes after registration. then the socket would be long dead and they would be unreachable for 3 minutes. based on procfs, ubuntu have settings for 9 probes with 75 seconds interval so that means around 11 minutes of sending keepalives. so i tried changing these values, on procfs. and tried playing around with these kamailio cfg settings as well: tcp_keepcnt tcp_keepidle tcp_keepintvl whatever i do, the interval between keepalives are always 2 minutes and after 4-5 probes, kamailio will send a FIN to the client. i checked the source code tcp_main.c and it looks alright. could this be an ubuntu issue? anybody seen this before? I created a workaround by setting expire 900 for all registrations but this is not ideal. Kelvin Chua

9 years, 5 months

error in kamctlrc line 13 not sure of "CHROOTED DIRECTORY"

by Joseph Zimmer

Sorry, this is my problem: have included the kamctlrc, kamailio.cfg, and modus.lst files if that helps, run create command, not sure of path for chrooted directory in kamctlrc file so I have not been able to create my initial database. I know that is holding up creation of MySQL database. can you assist, sent contribution to this email address, could not find any other. thanks in advance, joe zimmer +1 703-957-0186 USA root@telephonepros:~# /usr/local/sbin/kamdbctl create /usr/local/etc/kamailio//kamctlrc: line 13: =/path/to/chrooted/directory: No such file or directory MySQL password for root: INFO: test server charset /usr/local/lib/kamailio//kamctl/kamdbctl.mysql: line 105: mysql: command not found /usr/local/lib/kamailio//kamctl/kamdbctl.mysql: line 106: mysql: command not found Usage: grep [OPTION]... PATTERN [FILE]... Try 'grep --help' for more information. /usr/local/lib/kamailio//kamctl/kamdbctl.mysql: line 112: [: =: unary operator expected INFO: creating database kamailio ... /usr/local/lib/kamailio//kamctl/kamdbctl.mysql: line 71: mysql: command not found ERROR: Creating database kamailio failed! root@telephonepros:~#

9 years, 5 months

DIAMETER based on TCP requires a FIXED I/S-CSCFSOURCE PORT in order to make Cx work towards a External HSS

by Jan Devai

Hi experts, from the current trace we can see that the I/S-CSCF always changes SOURCE port when contacting our eternal HSS. In order to make the Cx work HSS expects the Source port to be fixed on the TCP layer and in our I/S-CSCF configuration we did not find any setting for SOURCE Port. Can somebody help us please ;-) ? We appreciate your support, Br, Jan

9 years, 5 months

Looking for kamailio service supplier.

by ZhuYue Zhang

Hi Sir, This is a Chinese company from ABB group, We're looking for a VOIP system solution, As our understanding, kamailio is the best choice, Does any Chinese company take this business? Thank you and Best Regards. [cid:image001.png@01D02128.0536F2C0] Zhuyue.zhang ABB Genway Xiamen Electrical Equipment CO.,LTD 7F,NO.23 Wanghai Road,Software Park 2,Lvling Road Xiamen SEZ,Fujian,China 361008 Phone: (86)592-2954819 Mobile: (86)15260200863

9 years, 5 months

Jump to page:

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 July 2015