sr-users November 2009

sr-users@lists.kamailio.org

80 participants
108 discussions

[Kamailio-Users] i want to get user defined header value

by RAJNIKANT VANZA

Hi friends, i want to get user-defined header value. e.g. i have create header name : TEST and its value : vtec in asterisk. then how can i get this value from this header in kamailio. -- Thanks and Regards Rajnikant Vanza

14 years, 5 months

[Kamailio-Users] how can i get sip header value

by RAJNIKANT VANZA

Hi Friends, i am a new user for kamailio. let me know, how can i get sip header value ? -- Thanks and Regards Rajnikant Vanza

14 years, 5 months

[Kamailio-Users] [kamailio-users] Read SIP Header from call request

by Chandrakant Solanki

Hi I am using kamailio 1.5.0.2 How can i read SIP Header in kamailio for every sip request. Is there any method / function which will help to read SIP Header...?? -- Regards, Chandrakant Solanki

14 years, 5 months

[Kamailio-Users] TCP problem/question

by Torben Friese

Hi all, I need a hint regarding TCP handling. I want to receive messages as TCP and relay or forward them as UDP. This is realized with dispatcher module. A explicit entry with sip:IP;transport=udp in the dispatcher list. Receiving via TCP works fine, but the proxy send the request also via TCP out. Any ideas where I can search or how to debug the problem ? best regards Torben

14 years, 5 months

[Kamailio-Users] ERROR:mi_fifo:mi_fifo_server: fifo command must begin with :: early_dialogs (1.5 rev 5834)

by Iñaki Baz Castillo

Hi, I use the Munin plugin I did in various servers running Kamailio 1.5 (Debian 64 bits). The munin plugins performs the Mi command: kamctl fifo get_statistics inuse_transactions In one of them the installed revision is 5834 and the plugin works perfectly, no errors in 3 months with high traffic. However in the other server (revision 5925) there are no traffic yet but the plugin fails sometimes (maybe once each 2-3 days). Sometimes it gets an error: ERROR:mi_fifo:mi_fifo_server: fifo command must begin with :: early_dialogs and sometimes it gets wrong value: kamctl fifo get_statistics inuse_transactions => 2819624 (with no traffic !!!) In the second case the Munin grapsh gets corrupted due to so high value. Could it be a bug in dialog module? Should I upgrade to revision 5939 in which I see a change for modules/dialog/dlg_handlers.c: ------------------------------------------------------------------------------------------------------------------------- ~# svn diff -r HEAD modules/dialog/dlg_handlers.c Index: modules/dialog/dlg_handlers.c =================================================================== --- modules/dialog/dlg_handlers.c (revisión: 5939) +++ modules/dialog/dlg_handlers.c (copia de trabajo) @@ -824,14 +824,13 @@ if(dlg->toroute>0 && dlg->toroute<RT_NO) { + dlg_set_ctx_dialog(dlg); fmsg = faked_msg_next(); if (exec_pre_req_cb(fmsg)>0) { - dlg_set_ctx_dialog(dlg); LM_DBG("executing route %d on timeout\n", dlg->toroute); set_route_type(REQUEST_ROUTE); run_top_route(rlist[dlg->toroute], fmsg); - dlg_set_ctx_dialog(0); exec_post_req_cb(fmsg); } } ------------------------------------------------------------------------------------------------------------------------ I see some differences between the dialog module versions running in both servers, but I think the main difference is a bug fix for the case in which there is empty Record-Route in the response (Kamailio crashed before the fix): ----------------------------------------------------------------------------------------------------------------------- # svn diff -r 5834:5925 modules/dialog/dlg_handlers.c Index: modules/dialog/dlg_handlers.c =================================================================== --- modules/dialog/dlg_handlers.c (revisión: 5834) +++ modules/dialog/dlg_handlers.c (revisión: 5925) @@ -163,10 +163,10 @@ int populate_leg_info( struct dlg_cell *dlg, struct sip_msg *msg, struct cell* t, unsigned int leg, str *tag) { - unsigned int skip_recs; - str cseq; - str contact; - str rr_set; + unsigned int skip_recs = 0; + str cseq = {0, 0}; + str contact = {0, 0}; + str rr_set = {0, 0}; /* extract the cseq number as string */ if (leg==DLG_CALLER_LEG) { @@ -184,48 +184,41 @@ /* extract the contact address */ if (!msg->contact&&(parse_headers(msg,HDR_CONTACT_F,0)<0||!msg->contact)){ LM_ERR("bad sip message or missing Contact hdr\n"); - goto error0; + } else { + if ( parse_contact(msg->contact)<0 || + ((contact_body_t *)msg->contact->parsed)->contacts==NULL || + ((contact_body_t *)msg->contact->parsed)->contacts->next!=NULL ) { + LM_ERR("bad Contact HDR\n"); + } else { + contact = ((contact_body_t *)msg->contact->parsed)->contacts->uri; + } } - if ( parse_contact(msg->contact)<0 || - ((contact_body_t *)msg->contact->parsed)->contacts==NULL || - ((contact_body_t *)msg->contact->parsed)->contacts->next!=NULL ) { - LM_ERR("bad Contact HDR\n"); - goto error0; - } - contact = ((contact_body_t *)msg->contact->parsed)->contacts->uri; - /* extract the RR parts */ if(!msg->record_route && (parse_headers(msg,HDR_RECORDROUTE_F,0)<0) ){ LM_ERR("failed to parse record route header\n"); - goto error0; - } - - if (leg==DLG_CALLER_LEG) { - skip_recs = 0; } else { - /* was the 200 OK received or local generated */ - skip_recs = dlg->from_rr_nb + - ((t->relaied_reply_branch>=0)? - (t->uac[t->relaied_reply_branch].added_rr):0); - } + if (leg==DLG_CALLEE_LEG) { + /* was the 200 OK received or local generated */ + skip_recs = dlg->from_rr_nb + + ((t->relaied_reply_branch>=0)? + (t->uac[t->relaied_reply_branch].added_rr):0); + } - if(msg->record_route){ - if( print_rr_body(msg->record_route, &rr_set, leg, - &skip_recs) != 0 ){ - LM_ERR("failed to print route records \n"); - goto error0; + if(msg->record_route){ + if( print_rr_body(msg->record_route, &rr_set, leg, + &skip_recs) != 0 ){ + LM_ERR("failed to print route records \n"); + } } - } else { - rr_set.s = 0; - rr_set.len = 0; } if(leg==DLG_CALLER_LEG) dlg->from_rr_nb = skip_recs; LM_DBG("route_set %.*s, contact %.*s, cseq %.*s and bind_addr %.*s\n", - rr_set.len, rr_set.s, contact.len, contact.s, - cseq.len, cseq.s, + rr_set.len, (rr_set.len)?rr_set.s:"", + contact.len, (contact.len)?contact.s:"", + cseq.len, (cseq.len)?cseq.s:"", msg->rcv.bind_address->sock_str.len, msg->rcv.bind_address->sock_str.s); ----------------------------------------------------------------------------------------------------------------------- Perhaps a regression in rev 5925 so I should upgrade? Thanks. -- Iñaki Baz Castillo <ibc(a)aliax.net>

14 years, 5 months

change from header in branches works strange

by Andres Moya

Hi, it is me again. I gave up on uac_replace_from, and trying with subst('/^From:(.*)sip:[^@]*@[a-zA-Z0-9\.]+(.*)$/From:\1sip:$avp(i:21)@$avp(i:24)\2/i'); first time it substitute ok, on next branch i got result: From: <sip:andres.moya4@sipdiscount.com;transport=UDP>;tag=ee12f132.sip:andres.moya4@sipdiscount.com Something really strange, looks like there is no way i can authenticate to different SIP providers in one transaction :( Anyone know how i can hack From field actually?

14 years, 5 months

crazy uac_replace_from

by Andres Moya

Hi, not sleeping second night. I am trying to authenticate to sequence of SIP provider, if one fail - another. I am calling uac_replace_from for each. uac_replace_from("sip:$avp(i:21)@$avp(i:24)"); first time it set ok: From: <sip:andres.moya4@sipdiscount.com>;tag=572ac509. second time i am getting From: <sip:andres.moya4@sipdiscount.comsip:21100036838@terrasip.net>;tag=572ac509. grrrr.... is it a joke :) Someone ... please help

14 years, 5 months

[Kamailio-Users] No free TCP receiver

by luis.guaman＠interlancompu.com

14 years, 5 months

[Kamailio-Users] Dialog timed calls

by Jason Penton

Hi All, Has anyone else noticed the significant inaccuracy of the timeout in the dialog module? We are using: modparam("dialog", "timeout_avp", "$avp(i:10)") However, the actual call is torn down a NUMBER of seconds past the timeout supplied. In some instances, for long calls, it is out by 30seconds or more....? For shorter calls it is accurate with a second or so. Anyone have any input, ideas? Cheers Jason

14 years, 5 months

[Kamailio-Users] How to configure alias_db_lookup in config script

by JR Richardson

Hi All, I have a real simple load balancer proxy setup using the dispatcher module, works great. I want to do an alias lookup before I send the calls through to the dispatcher, but I can't seem to find a good example of how that should be setup in the config script. I've tried different things, the aliase_db_lookup is working but if a user is not in the database, the call loops and does not continue on to the dispatcher. Here is my current route script (this does not work): route{ # initial sanity checks -- messages with # max_forwards==0, or excessively long requests if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); exit; }; if (msg:len >= 2048 ) { sl_send_reply("513", "Message too big"); exit; }; alias_db_lookup("dbaliases"); t_on_failure("1"); t_relay(); ds_select_dst("1", "4"); t_on_failure("1"); t_relay(); } failure_route[1] { ds_next_dst(); forward(); } I think there should be an 'if' 'then' or 'if' 'else' separating the alias_db_lookup and the ds_select functions, but I'm not sure of the syntax and where the curly brackets need to be. Thanks. JR -- JR Richardson Engineering for the Masses

14 years, 5 months

← Newer
1
2
3
4
5
6
7
8
9
10
11
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 November 2009