sr-users March 2016

sr-users@lists.kamailio.org

88 participants
128 discussions

Handling of messages with manipulated Event header.
by Christopher Vella 02 Mar '16

02 Mar '16

Hi, I apologise if this is not the correct venue for such a question... I am running kamailio v4.3.4 (x86_64/linux) on debian Jessie, sourced from; deb http://deb.kamailio.org/kamailio jessie main In my routing logic I am handling SUBSCRIBE requests and striping extra Event package parameters appended to "ua-profile" event types. i.e.; Event: ua-profile;model=somemodel;vendor=somevendor;profile-type=user becomes; Event: ua-profile This is done with this code; } else if( is_method("SUBSCRIBE")) { subst('/ua-profile.*/ua-profile/') ; handle_subscribe(); t_release(); However, in such conditions "search_event()" doesn't correctly find the event. Even though it looks like it is searching for the right event type; start event= [ua-profile/7] handle_subscribe(): unsupported presence event ua-profile --- Begin debug ---- ]3(7664) DEBUG: <core> [re.c:457]: subst_run(): matched (332, 79): [Event: ua-profile;model=somemodel;vendor=somevendor;profile-type=user] with [Event: ua-profile]extops.c:680]: subst_f(): textops: replacing at offset 376[Event: ua-profile;model=somemodel;vendor=somevendor;profile-type=user] 13(7664) debug: textops [textops.c:696]: subst_f(): lst was 0x7fb391fd0da8 13(7664) error: *** cfgtrace:request_route=[presence] c=[/etc/kamailio/kamailio.cfg] l=365 a=24 n=handle_subscribe 13(7664) debug: presence [event_list.c:348]: search_event(): start event= [ua-profile/7] 13(7664) notice: presence [subscribe.c:1092]: handle_subscribe(): unsupported presence event ua-profile 13(7664) debug: tm [t_lookup.c:1011]: t_check_msg(): debug: t_check_msg: msg id=1 global id=1 t start=0x7fb388763290 13(7664) debug: tm [t_lookup.c:1083]: t_check_msg(): debug: t_check_msg: t already found! 13(7664) debug: <core> [mem/shm_mem.c:101]: _shm_resize(): warning:vqm_resize: resize(0) called 13(7664) debug: tm [t_reply.c:1591]: cleanup_uac_timers(): debug: cleanup_uac_timers: retr/fr timers reset 13(7664) debug: <core> [tcp_main.c:2196]: tcpconn_send_put(): send from reader (7664 (13)), reusing fd 13(7664) debug: <core> [tcp_main.c:2430]: tcpconn_do_send(): sending... 13(7664) debug: <core> [tcp_main.c:2464]: tcpconn_do_send(): after real write: c= 0x7fb38875ecf8 n=368 fd=9 13(7664) debug: <core> [tcp_main.c:2465]: tcpconn_do_send(): buf= sip/2.0 489 bad event via: sip/2.0/tcp 127.0.1.1:5060;branch=z9hg4bk-2999-1-0;rport=34679;received=192.168.88.88 cseq: 1 subscribe call-id: 1-2999(a)127.0.1.1 from: <sip:c.vella@albourne.com>;tag=1 to: <sip:provisioning@albourne.com>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-811a --- End debug --- As a test, I send another message with clean "Event: ua-profile" and this works , event= [ua-profile/7] is found. --- Begin debug --- ]4(7665) DEBUG: <core> [re.c:457]: subst_run(): matched (332, 18): [Event: ua-profile ] with [Event: ua-profile]extops.c:680]: subst_f(): textops: replacing at offset 376 [Event: ua-profile 14(7665) DEBUG: textops [textops.c:696]: subst_f(): lst was 0x7fb391fd0da8 14(7665) ERROR: *** cfgtrace:request_route=[PRESENCE] c=[/etc/kamailio/kamailio.cfg] l=365 a=24 n=handle_subscribe 14(7665) DEBUG: presence [event_list.c:348]: search_event(): start event= [ua-profile/7] 14(7665) DEBUG: presence [subscribe.c:1161]: extract_sdialog_info_ex(): 'Expires' header found, value= 3600 14(7665) DEBUG: presence [subscribe.c:1195]: extract_sdialog_info_ex(): 'To' header ALREADY PARSED: <sip:provisioning@albourne.com> 14(7665) DEBUG: presence [subscribe.c:1266]: extract_sdialog_info_ex(): generating to_tag 14(7665) DEBUG: sl [sl.c:329]: get_reply_totag(): totag stateful mode (tm) 14(7665) DEBUG: presence [subscribe.c:1326]: extract_sdialog_info_ex(): subs->contact= sip:c.vella@192.168.88.179:59206;transport=tcp - len = 46 14(7665) DEBUG: presence [subscribe.c:1043]: handle_subscribe(): subscription status= active - inserted 14(7665) DEBUG: presence [subscribe.c:554]: update_subscription(): update subscription 14(7665) DEBUG: presence [notify.c:115]: printf_subs(): pres_uri: sip:c.vella@albourne.com 14(7665) DEBUG: presence [notify.c:116]: printf_subs(): watcher_user@watcher_domain: c.vella(a)albourne.com 14(7665) DEBUG: presence [notify.c:117]: printf_subs(): to_user@to_domain: provisioning(a)albourne.com 14(7665) DEBUG: presence [notify.c:118]: printf_subs(): from_user@from_domain: c.vella(a)albourne.com 14(7665) DEBUG: presence [notify.c:119]: printf_subs(): callid/from_tag/to_tag: 1-3002(a)127.0.1.1/1/a6a1c5f60faecf035a1ae5b6e96e979a-1030 14(7665) DEBUG: presence [notify.c:120]: printf_subs(): local_cseq/remote_cseq: 0/1 14(7665) DEBUG: presence [notify.c:121]: printf_subs(): local_contact/contact: sip:192.168.88.85:5060;transport=tcp/sip:c.vella@192.168.88.179:59206;transport=tcp 14(7665) DEBUG: presence [notify.c:122]: printf_subs(): record_route: 14(7665) DEBUG: presence [notify.c:123]: printf_subs(): sockinfo_str: tcp:192.168.88.85:5060 14(7665) DEBUG: presence [notify.c:125]: printf_subs(): event: ua-profile 14(7665) DEBUG: presence [notify.c:126]: printf_subs(): status: active 14(7665) DEBUG: presence [notify.c:127]: printf_subs(): reason: 14(7665) DEBUG: presence [notify.c:128]: printf_subs(): version: 1 14(7665) DEBUG: presence [notify.c:129]: printf_subs(): expires: 3600 14(7665) DEBUG: presence [notify.c:131]: printf_subs(): updated/updated_winfo: -1/-1 14(7665) DEBUG: presence [subscribe.c:629]: update_subscription(): subscription not in dialog 14(7665) DEBUG: presence [subscribe.c:634]: update_subscription(): inserting in shtable 14(7665) DEBUG: tm [t_lookup.c:1011]: t_check_msg(): DEBUG: t_check_msg: msg id=1 global id=1 T start=0x7fb388763290 14(7665) DEBUG: tm [t_lookup.c:1083]: t_check_msg(): DEBUG: t_check_msg: T already found! 14(7665) DEBUG: <core> [mem/shm_mem.c:101]: _shm_resize(): WARNING:vqm_resize: resize(0) called 14(7665) DEBUG: tm [t_reply.c:1591]: cleanup_uac_timers(): DEBUG: cleanup_uac_timers: RETR/FR timers reset 14(7665) DEBUG: <core> [tcp_main.c:2196]: tcpconn_send_put(): send from reader (7665 (14)), reusing fd 14(7665) DEBUG: <core> [tcp_main.c:2430]: tcpconn_do_send(): sending... 14(7665) DEBUG: <core> [tcp_main.c:2464]: tcpconn_do_send(): after real write: c= 0x7fb38875ecf8 n=399 fd=9 14(7665) DEBUG: <core> [tcp_main.c:2465]: tcpconn_do_send(): buf= SIP/2.0 202 OK Via: SIP/2.0/TCP 127.0.1.1:5060;branch=z9hG4bK-3002-1-0;rport=34680;received=192.168.88.88 CSeq: 1 SUBSCRIBE Call-ID: 1-3002(a)127.0.1.1 From: <sip:c.vella@albourne.com>;tag=1 To: <sip:provisioning@albourne.com>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-1030 Expires: 3600 Contact: <sip:192.168.88.85:5060;transport=tcp> --- End debug --- I suspect I am not understanding this correctly. Is there a proper way around this? I wonder if I am wrong to think that textops Module manipulates the actual request message? Thank you! Regards, -- Chris Vella Albourne Partners (Canada) Limited

2 2

kamailio 4.3.4 crash
by Rene Montilva 02 Mar '16

02 Mar '16

Hi list i've updated to kamailio 4.3.4 , i work with push wake up config, but kamailio now crash and display this messages ar 1 19:38:43 proxy6-2 /usr/sbin/kamailio[21630]: WARNING: tm [t_lookup.c:1476]: t_unref(): WARNING: script writer didn't release transaction Mar 1 19:38:43 proxy6-2 /usr/sbin/kamailio[21630]: WARNING: tm [h_table.c:130]: free_cell_helper(): removed cell 0x7ff059882448 is still linked in hash table (t_lookup.c:1486) Mar 1 19:38:43 proxy6-2 snmpd[2204]: Connection from UDP: [10.107.148.69]:52614->[10.107.148.66] Mar 1 19:38:44 proxy6-2 kernel: [6727397.951325] kamailio[21649]: segfault at 0 ip 00007ff0d92fbfb2 sp 00007fff15f54c90 error 6 in tm.so[7ff0d92a3000+eb000] Mar 1 19:38:44 proxy6-2 /usr/sbin/kamailio[21599]: WARNING: tm [h_table.c:130]: free_cell_helper(): removed cell 0x7ff0598719e8 is still linked in hash table (h_table.c:440) Mar 1 19:38:44 proxy6-2 /usr/sbin/kamailio[21599]: WARNING: tm [h_table.c:130]: free_cell_helper(): removed cell 0x7ff059877eb0 is still linked in hash table (h_table.c:440) i don't know what happend, but i guess is my push configuration, like the message display at "t_lookup.c". i got this in the configure file: route[PUSHJOIN] { if (!is_method("REGISTER")) return; $var(hjoin) = 0; lock("$tU"); $var(hjoin) = $sht(vtp=>join::$tU); $sht(vtp=>join::$tU) = $null; unlock("$tU"); if($var(hjoin)==0) return; $var(id_index) = $(var(hjoin){s.select,0,:}{s.int}); $var(id_label) = $(var(hjoin){s.select,1,:}{s.int}); xdbg("resuming trasaction [$var(id_index):$var(id_label)] $tU ($var(hjoin))\n"); xlog("L_INFO","resuming trasaction [$var(id_index):$var(id_label)] $tU ($var(hjoin))\n"); t_continue("$var(id_index)", "$var(id_label)","LL"); } route[LL] { lookup("location"); route(RELAY); }

2 2

Kamailio as a front-end proxy
by Anton Tonev 02 Mar '16

02 Mar '16

Hello everybody, I am a new user of Kamailio (4.3.1), I am working with it since 1-2 months. The thing that I'm trying to do is to build the following system: same LAN 192.168.0.1 Alice proprietary SIP Server [Public_IP_X] ------------ [Public_IP_Y] Kamailio [172.26.0.1] ---------- [172.26.0.1] with 192.168.0.1 registrar Bob Obviously Kamailio has to translate the local addresses of Alice and Bob, e.g. to use the Nathelper module. The module is doing well its job because the Contact headers are replaced with the Public_IP_X when a REGISTER message is sent by Alice's or Bob's sip phones (I am using Linphone and Zoiper as clients). Once the incoming sip register was treated by Kamailio it is sent to the proprietary SIP Server. The server sends 200 OK to Kamailio and the proxy relays the message to the clients. So the sip registration for me it is OK. But when it comes to initiate a call from Alice to Bob the things are not as I expect it. The initial request INVITE sent from Alice goes to the sip server but then the server instead of sending the INVITE for Bob through Kamailio, it sends the message directly to Bob's device. Does anyone knows how to "tell" to the sip server, using the SIP protocol, that it must use the proxy? The only thing I have in mind is to force Kamailio to replace the contact of Alice and more precisely the host/ip address by the proxy's host/ip address. I tested this idea and the sip server did what I was expecting but for me this is not a proper solution. To do that I used this discussion - http://opensips.org/pipermail/users/2010-October/014873.html Thank you in advance for your attention ! Best regards, Anton

6 7

LCR Commands Kamctl
by Alberto Sagredo 02 Mar '16

02 Mar '16

I have just edited kamctl in order to make lcr commands work. Hope that helps someone. Using Kamailio 4.3.0 Please find kamctl attached also ### LCR management # lcr() *{* *case* $1 *in* show_gws) # merr "command disabled" # exit 1 require_dbengine mecho "lcr gateways" QUERY="select * FROM lcr_gw ORDER BY id; " $DBROCMD "$QUERY" ;; show_routes) # merr "command disabled" # exit 1 require_dbengine mecho "lcr routes" QUERY="select * FROM lcr_rule ORDER BY id;" $DBROCMD "$QUERY" ;; reload) # merr "command disabled" # exit 1 kamcmd lcr.reload ;; dump_gws) # merr "command disabled" # exit 1 kamcmd lcr.dump_gws ;; dump_routes) # merr "command disabled" # exit 1 kamcmd lcr.dump_rules *exit* 1 ;; eval_weights) *shift* $AWK 'BEGIN { if (ARGC < 2) { printf("Usage: lcr eval_weights <list of weights (integers 1-254)>\n"); exit; } iters = 100000; for (i = 1; i < ARGC; i++) { counts[i] = 0; } for (i = 1; i <= iters; i++) { for (j = 1; j < ARGC; j++) { elem[j] = ARGV[j] * rshift(int(2147483647 * rand()), 8); } at = 1; max = elem[at]; for (j = 2; j < ARGC; j++) { if (elem[j] > max) { max = elem[j]; at = j; } } counts[at] = counts[at] + 1; } for (i = 1; i < ARGC; i++) { printf("weight %d probability %.4f\n", ARGV[i], counts[i]/iters); } }' $@ ;; *) usage_lcr *exit* 1 *esac* *}*

3 2

Fwd: [kamailio]: Querie on ratelimit module
by Prashant Desai 02 Mar '16

02 Mar '16

Hi Kamailio, We are using Kamailio V4.2.3 for our project and we are trying to address the performance requirement. We have following queries and need some inputs from Kamailio. *Requirement :* CPU Utilization Limit to 70%, If the limit is crossed Kamailio has to reject the Request. And If it is within the limit Kamailio has to Process the Requests. (i.e. Kamailio has to dynamically set and reset the policy based on CPU Load). *Our Findings* : We have come across ratelimit module in Kamailio, we tried using the same to address the requirement but we see it is not dynamically setting and resetting the policy (once if it starts rejecting then every time it rejects it, only if we restart the kamailo it works) *What we Need*: We need to know 1. Are we using the right module to address the above requirement ? 2. We are only using ratelimit, module, do we have to include any other module along with ratelimit? 3. We are using FEEDBACK algorithm, is that OK ? 4. Setting “ modparam("ratelimit", "pipe", "3:FEEDBACK:70") “ , is this correct ? 5. In ratelimit.c , function static int pipe_push(struct sip_msg * msg, int id) { *case* *PIPE_ALGO_FEEDBACK*: *LM_DBG(**"drop_rate [%d],hash[*pipes[id].counter][%d]\n"**,*drop_rate, hash[*pipes[id].* *counter**])*; ret = (hash[*pipes[id].counter % 100] < *drop_rate) ? -1 : 1; } We are not able to understand the above line ( hash[*pipes[id].counter % 100]). Could you please elaborate. 6. Where are we lagging ? Regards, Prashanth ------------------------------ ============================================================================================================================ Disclaimer: This message and the information contained herein is proprietary and confidential and subject to the Tech Mahindra policy statement, you may review the policy at http://www.techmahindra.com/Disclaimer.html externally http://tim.techmahindra.com/tim/disclaimer.html internally within TechMahindra. ============================================================================================================================

2 2

RFC: Kamailio 5.0
by Daniel-Constantin Mierla 01 Mar '16

01 Mar '16

Hello, at Fosdem and other events this year, while meeting many of Kamailio devs, the topic of what's next for Kamailio came into discussions, with suggestions that after 4.4 it may be time for some major leap to 5.0. I created a page where I collected the main ideas put on table so far - rather unpolished draft, but eventually a good starting point: * https://www.kamailio.org/wiki/devel/kamailio-5.0-design Everyone is invited to add suggestions to the wiki page and/or discuss here on mailing lists, what should be there in 5.0, what is good (to keep) or bad (to remove) with current version, what is missing and it is "must have", ... Not to have a single long tread, for each new idea, start a new email thread with subject prefixed by Kamailio 5.0. I think this impacts users, not only devs, and their contribution is useful as well, so it should be fine to discuss the ideas/concepts on sr-users. When it gets to real implementation discussions, then it can be on sr-dev. Cheers, Daniel -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Training, Berlin, March 7-9, 2016 - http://www.asipto.com

1 0

catching lost websocket ua
by Juha Heinanen 01 Mar '16

01 Mar '16

I have done some more digging on websocket:closed event route. In DB_ONLY mode, easy deregistration of a websocket UA at connection close would require access in the event route to connection_id of the closed connection. The function that is run at the close has ws_connection_t argument: static void wsconn_run_route(ws_connection_t *wsc) ws_connection_t record has these two fields: int id; /* id and id_hash are identical to the values */ unsigned id_hash; /* for the corresponding TCP/TLS connection */ Is id the same thing as what is stored in connection_id field of location table? If it is, may be its value could be made available to the event route in a pseudo variable. -- Juha

2 8

(no subject)
by Loïc Boissy 01 Mar '16

01 Mar '16

Hello, We have detected a problem on the increment of CSeq in the SIP header from kamailio. In a session SIP subscribe / notify, we notice that there is a notify that has the same CSeq than the last. As an attachment capture wireshard to clarify our remarks. Is that you can check where is the problem? Best regards. Loïc -- Visit Digigram Booth N3534 <http://www.mapyourshow.com/shows/index.cfm?Show_ID=nab16&exhid=1436&booth=N…> at the NAB Show in Las Vegas April 18-21! Check out our showroom click here <http://nab16.mapyourshow.com/7_0/exhibitor_details.cfm?exhid=1436>! Use our Guest Pass code LV6965 <https://registration.experientevent.com/showNAB161/default.aspx?Tracking=WB…> for your free pass www.nabshow.com

3 5

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 March 2016