sr-users March 2009

sr-users@lists.kamailio.org

92 participants
149 discussions

Re: [Kamailio-Users] HOWTO rewrite to: header

by alexander merkulov

thats work for invite nice, but not work fro cancel even this (very simple form) not change cancel if (method == "BYE" || method == "CANCEL") { # xlog("bye\n");a xlog("L_INFO", "CANCEL - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); if(t_check_trans()){ xlog("triing to rewrite"); if ( subst('/192/aaa/ig') ) {}; t_relay(); exit; }else{ xlog("no trans"); exit; } 2009/3/4 alexander merkulov <arheops(a)gmail.com> > unfortanly it not work after > location() > known limitation: use non-rewrited message. > > 2009/3/4 Ovidiu Sas <osas(a)voipembedded.com> > > Take a look at textops module: >> http://www.kamailio.net/docs/modules/1.5.x/textops.html#id2467719 >> >> Regards, >> Ovidiu Sas >> >> On Wed, Mar 4, 2009 at 4:20 PM, alexander merkulov <arheops(a)gmail.com> >> wrote: >> > here is correct reqwest and reqwest via kamailio >> > >> > is there any way to rewrite To: field in kamailio >> > because now it nto work >> > >> > correct reqwest(asterisk) >> > RECEIVING FROM: 69.70.173.195:5060 >> > CANCEL sip:34249@193.110.78.12:8484 SIP/2.0 >> > Via: SIP/2.0/UDP 192.168.1.180:5060;branch=z9hG4bK4c97bd4a >> > From: "Unknown" <sip:Unknown@voip1.bravotelecom.com<sip%3AUnknown(a)voip1.bravotelecom.com> >> >;tag=as366a0ba0 >> > To: <sip:34249@193.110.78.12:8484> >> > Call-ID: 322db75c71be4ba45a61c7666b93e6be(a)voip1.bravotelecom.com >> > CSeq: 102 CANCEL >> > User-Agent: Asterisk PBX >> > Max-Forwards: 70 >> > Content-Length: 0 >> > >> > incorrect reqwest(multi-homed kamailio, asterisk originate to internal >> eth) >> > >> > RECEIVING FROM: 69.70.173.195:5060 >> > CANCEL sip:34249@193.110.78.12:8484 SIP/2.0 >> > Via: SIP/2.0/UDP 69.70.173.195;branch=z9hG4bK1b1b.3c42cea6.0 >> > From: "Unknown" <sip:Unknown@69.70.173.195<sip%3AUnknown(a)69.70.173.195> >> >;tag=as6075df60 >> > Call-ID: 4d784fa972c4e9c9795032417f46cb26(a)voip1.bravotelecom.com >> > To: <sip:34249@192.168.2.170 <sip%3A34249(a)192.168.2.170>> >> > CSeq: 102 CANCEL >> > Max-Forwards: 70 >> > asterisk >> > Content-Length: 0 >> > >> > -- >> > Merkulov Alexander >> > >> > _______________________________________________ >> > Kamailio (OpenSER) - Users mailing list >> > Users(a)lists.kamailio.org >> > http://lists.kamailio.org/cgi-bin/mailman/listinfo/users >> > http://lists.openser-project.org/cgi-bin/mailman/listinfo/users >> > >> > > > > -- > Merkulov Alexander > -- Merkulov Alexander

15 years, 8 months

[Kamailio-Users] Redundancy and fault-tolerance

by Uriel Rozenbaum

Hi gentlemen, I'm trying to find a suitable topology to deploy on our SIP network. We started testing UCARP, but it seems it's not going to do for us. Our topology involves 2 servers with physical IPs on them and 2 floating IPs (to balance load 50% on each). The balancing is manual, we are going to point half our servers (measured in load) to one floating IP and so on. When a server fails, the other will handle the load assuming the other floating IP. We found an issue managing IPs, if we have to make Kamailio listen to a floating IP we have to set: listen=0.0.0.0 and then record_route will just pass that IP on the record route headers, making destination servers not to respond. If we try to use record_route_preset() there, when server A fails, all responses come with the "wrong" IP on record_route when server B assumes A's IP. I'd like to know if some of you found a tidier solution and would like to share some topology and implementation tips. DNS SRV is also on our list, but maybe there is something out there that can help us with this. Thanks in advance, Uriel

15 years, 8 months

[Kamailio-Users] How to send a to-tag in a CANCEL request generated by carrierroute?

by mayamatakeshi

Hello, I'm using the module carrierroute. I'm setting the carrierfailureroute table to try a second route if the first one times out. The first route is a GW that sends 183 Ringing with SDP and to-tag. But when the failure_route is called due to timeout and the second route is resolved I see kamailio sending a CANCEL without a to-tag and the GW replies with "481 Call Leg/Transaction Does No Exist". So, This fails to cancel the first request. How can I make kamailio send the to-tag in the CANCEL request? Also, I noticed kamailio sends the INVITE to the second route before sending the CANCEL to the first one. Was this coded on purpose? (I believe this doesn't go against the RFC, but it is something curious). If you bother to look at my cfg, here's the relevant parts: route { .........some stuff ..... DOMAIN_AVP = ""; if (!cr_route("CARRIER_AVP", "DOMAIN_AVP", "$rU", "$rU", "call_id", "HOST_AVP")) { sl_send_reply("404", "No Route"); exit; } t_on_failure("ROUTE_FIRST_ATTEMPT_FAILURE"); if (subst_uri('/(sip:.*);nat=yes/\1/')) { setbflag(NAT_BFLAG); } if (isbflagset(NAT_BFLAG)) { fix_nated_contact(); if (is_method("BYE|CANCEL")) { unforce_rtp_proxy(); } else if (is_method("INVITE")) { force_rtp_proxy("cfr"); } search_append('Contact:.*sip:[^>[:cntrl:]]*', ';nat=yes'); } t_on_reply("ONREPLY"); if (!t_relay()) { sl_reply_error(); } } failure_route[ROUTE_FIRST_ATTEMPT_FAILURE] { if (isbflagset(NAT_BFLAG)) { unforce_rtp_proxy(); } revert_uri(); if (!cr_next_domain("CARRIER_AVP", "DOMAIN_AVP", "$rU", "HOST_AVP", "$T_reply_code", "DOMAIN_AVP")) { exit; } if (!cr_route("CARRIER_AVP", "DOMAIN_AVP", "$rU", "$rU", "call_id", "HOST_AVP")) { exit; } t_on_failure("ROUTE_SECOND_ATTEMPT_FAILURE"); append_branch(); route(RELAY_REQUEST); } failure_route[ROUTE_SECOND_ATTEMPT_FAILURE] { if (isbflagset(NAT_BFLAG) ) { unforce_rtp_proxy(); } }

15 years, 8 months

[Kamailio-Users] htable question

by Klaus Darilion

Hi! Sorry for not knowing how hash table works, thus my questions may be a bit stupid: How many items can be stored in hashtable? Is it limited to "size" parameter, e.g. 10 means max. 1024 entries? Or is it as much as memory is available (what for is the size parameter in this case)? How can I delete a key from htable? Example: I want to track concurrent calls (lets pretend there is no dialog module :-): # pseudo language if INVITE $sht(a=>$ci) = $ts; ... elseif BYE $avp(s:duration) = $ts - $avp(s:duration); # how to delete this key now from the htable? Is it possible to iterate over all entries in the htable? thanks klaus

15 years, 8 months

Re: [Serusers] Need easiest way to set/clear a flag and refer to it later in same call session

by Miklos Tirpak

Please read the getting started documentation from http://www.iptel.org/doc. This is a bit old, and I strongly suggest to use ser 2.x instead of 0.9.x, therefore some additional documents might be also useful: http://www.iptel.org/ser/doc/010whatsnew. Regards, Miklos p.s. Please post all the questions/answers to the serusers list, others might be interested as well. On 03/03/2009 08:35 PM, Martin Lane wrote: > Where can I learn the syntax or regexp format of the ser config file? > > On Thu, Feb 26, 2009 at 3:50 AM, Miklos Tirpak <miklos(a)iptel.org> wrote: > >> Hello, >> >> for simple and very fast boolean checks you can use the flags: >> >> - declare the flag(s) at the beginning of the config: >> >> flags >> FLAG_FOO, >> FLAG_BAR; >> >> - Call the setflag(FLAG_FOO) and resetflag(FLAG_FOO) functions to set and >> clear the flag when the INVITE is processed. >> - Use "if (isflagset(FLAG_FOO)) {...}" to check the state of the flag in >> the reply route. >> >> For storing integer or string values you can use AVPs: >> >> # during INVITE processing >> $foo = "myvalue"; >> $bar = 2; >> >> # in reply_route: >> if ($foo == "myvalue") {...} >> if ($bar) {...} >> >> Have a look at etc/ser-oob.cfg for examples. The values are attached to the >> transaction in both cases, therefore you need to forward the request with tm >> module. >> >> Miklos >> >> >> On 02/24/2009 06:40 AM, Frank Durda IV wrote: >> >>> I need a simple way to set either a boolean flag (or integer >>> value) during the INVITE of a given call in ser.cfg, and test >>> that value via "if" elsehere in ser.cfg during the 183/200 >>> response messages for that same call. >>> This would be a data object unique to a given call, >>> which should disappear/lose persistence/end scope when >>> a given call ends. Not global, no need to write the >>> value to disk, doesn't need to survive a restart of SER, etc. >>> >>> The various SER documents describe a number of things that >>> could do this, but most seem overly complex, storing the object >>> in a MYSQL database on disk or something, and these all seem >>> so excessive. There also appear to be a few built-in flags, >>> but the documentation suggests that all are actually there >>> for specific uses and so use for other things might not work. >>> >>> I simply want to make a determination of something during >>> the INVITE for call 12345, and be able to refer to that >>> flag or integer value later on when the various response >>> messages for the same call (#12345) are coming back >>> through. I can't make the same determination on each >>> message after the INVITE because the original src_ip >>> address value where the INVITE came from doesn't seem >>> to be in a testable variable when handling reply >>> messages, or at least not in one that is clearly >>> documented. >>> >>> >>> I've chased a number of possible ways this might be done, >>> but tire of being referred away from the doc that came with >>> the source and over to web sites that tell me this or that module >>> that might do part of what I need is deprecated and to use >>> this other module, but the web site for the other module says >>> that the first module is better suited to what I want to >>> do (a circle), doesn't show how the set value can actually >>> be tested, or the web page just doesn't work anymore. >>> >>> So, assuming there is a simple way to do this, I need a >>> quick code snip showing how to set/clear/assign a value to such >>> a beast within INVITE handling, and a quick code snip of how >>> to test it in an "if" statement during 183/200/110 type >>> response messages. Whatever it is, the value set, cleared >>> or being tested in one call should not affect any other >>> call. >>> >>> >>> Thanks in advance! >>> >>> >>> _______________________________________________ >>> Serusers mailing list >>> Serusers(a)lists.iptel.org >>> http://lists.iptel.org/mailman/listinfo/serusers >>> >> _______________________________________________ >> Serusers mailing list >> Serusers(a)lists.iptel.org >> http://lists.iptel.org/mailman/listinfo/serusers >> >

15 years, 8 months

[Kamailio-Users] how to suppr a SDP param

by BERGANZ François

Hello, In my SDP, I have Media Attribute (a): silenceSupp:off - - - - How can I suppr it ?because, I have a phone wich have error when it have that! Thank you Cordialement, BERGANZ François P Pensez à l'Environnement, n'imprimez ce mail que si nécessaire.

15 years, 8 months

[Kamailio-Users] Trixbox>openser is this possible?

by carl Lougher

Howdy, Is it possible to connect a trixbox trunk to openser and then flick the cdr to another box and allow rtp streams to go direct from customer trixbox to sip provider? What cdr billing methods are best from openser? I would like to dump in a mysql database if poss? Thanks, Taff..

15 years, 8 months

[Kamailio-Users] Kamailio (OpenSER) v1.5.0 Released

by Daniel-Constantin Mierla

Hello, Kamailio (OpenSER) 1.5.0 has been released. It represent the major version with the biggest new features boost since project was started back in 2005. Release 1.5.0 comes after a shorter development period than usual - about five months of coding and more than one month of extensive testing, but brings lot of new features and improvements, with special care to stability, performance, security and flexibility. A short summary of what the release brings out: * configuration file caching system - generic storage engine in memory via htable module allowing to share data between processes and reduce SQL operations by storing results in cache * execute SQL queries against multiple databases and access the results in a fast and natural fashion * execute config file route blocks on timer * send SIP requests from config file * perform HTTP queries from config file - integration with web service * dialog info presence support - RFC4235 * support for TLS server_name extension (aka SNI=server name indication) * support for non-blocking logging * many enhancements to least cost routing (LCR), load balancing (dispatcher) and carrier routing (carrierroute) * access in config file to both request or reply during transaction processing * perl-like regular expression support (PCRE library) * sanity check of SIP message structure * protection against SIP reply attack * twelve new modules * code restructuring in core - slimmer and less exposed to issues * web management interface - SIREMIS - http://siremis.asipto.com You can download the tarball of the released sources at * http://www.kamailio.org/pub/kamailio/latest/src/ Binary packages for several distributions you can find at * http://www.kamailio.org/pub/kamailio/latest/bin/ * http://www.kamailio.org/pub/kamailio/latest/packages/ Packages will be uploaded as soon as they are submitted. Documentation: * modules' documentation: http://www.kamailio.org/docs/modules/1.5.x/ * migration guide: http://www.kamailio.org/dokuwiki/doku.php/install:1.4.x-to-1.5.0 Full release notes at: * http://www.kamailio.org/mos/view/Kamailio-OpenSER-v1.5.0-Release-Notes Many thanks to all that made this release possible: the management board, developers, testers and community. Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

15 years, 8 months

[Kamailio-Users] Carrierrout issue

by Ali Jawad

Hi I do use carrieroute to balance calls to 3 servers and those 3 servers do use a2billing and they forward calls to my pstn gw. I do have a graph that has the active calls on them randomly and it does not depend on the load at hand the calls spike up on all 3 servers together. And most of those calls are in ringing state but with no callerID. Normally in the log for carrieroute I have something like this: Mar 3 13:39:10 [4288] INFO:carrierroute:cr_do_route: uri xxxxxxxxxxxxx was rewritten to sip:xxxxxxxxxxxxxx ACC: transaction answered: timestamp=1236087551;method=INVITE;from_tag=rMciw2o;to_tag=as7761f5cf;ca ll_id=c745983c;code=200;reason=OK ACC: request acknowledged: timestamp=1236087551;method=ACK;from_tag=rMciw2o;to_tag=as7761f5cf;call_ id=c745983c;code=200;reason=OK Mar 3 13:39:11 [4286] INFO:carrierroute:cr_do_route: uri xxxxxxxxxxxxx was rewritten to sip:xxxxxxxxxxxxxxx Mar 3 13:39:12 [4287] INFO:carrierroute:cr_do_route: uri xxxxxxxxxxxx was rewritten to sip:xxxxxxxxxxxxxx ACC: transaction answered: timestamp=1236087552;method=INVITE;from_tag=yJ+hSWA;to_tag=as26649b96;ca ll_id=a1c42904;code=183;reason=Session Progress ACC: transaction answered: timestamp=1236087552;method=INVITE;from_tag=CAJpAXg;to_tag=as5d24ff4f;ca ll_id=a35563d5;code=183;reason=Session Progress ACC: transaction answered: timestamp=1236087552;method=INVITE;from_tag=7i2kutG;to_tag=as6c125d0e;ca ll_id=2739b561;code=183;reason=Session Progress Mar 3 13:39:12 [4285] INFO:carrierroute:cr_do_route: uri xxxxxxxxxxxxxx was rewritten to sip:xxxxxxxxxxxxxxxxxx ACC: transaction answered: timestamp=1236087553;method=INVITE;from_tag=tMs9y8M;to_tag=as18b7f087;ca ll_id=7d65d34b;code=183;reason=Session Progress However when this problem happens the log screen only has the something like the below and as said the calls are in ringing state with no caller ID: Mar 3 13:39:11 [4286] INFO:carrierroute:cr_do_route: uri xxxxxxxxxxxxx was rewritten to sip:xxxxxxxxxxxxxxx Mar 3 13:39:12 [4287] INFO:carrierroute:cr_do_route: uri xxxxxxxxxxxx was rewritten to sip:xxxxxxxxxxxxxx

15 years, 8 months

[Kamailio-Users] preparing 1.5.0 release

by Daniel-Constantin Mierla

Hello, preparations for 1.5.0 release starts. Any developer that has to commit any code, please do it quickly. Branch will be created very soon. Many thanks for those helping with development and testing. Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

15 years, 8 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 March 2009